Digikam Plans for KDE 4

Readers of the KDE Commit-Digest have probably noticed that Gilles Caulier is again on top with number of commits. On what does he work so furiously? Gilles is the main developer of Digikam which is under transition from KDE 3 to KDE 4 whilst simultaneously adding new features. Read more to know more about the future of advanced digital photo management for KDE and Linux.

There are many improvements including a cleaner user interface, improved performance, a new thumbnail bar, XMP support, ability to run on Mac OS X, GPS tagging using Google Maps, multiple album collections supporting collections on network shares and removable media, and auto gamma and white balance with RAW. Digikam is also the first open source photography tool with 16-bit colour depth support. Gilles Caulier tells all.

We have plans to release 0.10.0 in September, if all goes well.

Regression tests will take a while. I would not provide a "stable"
release full of bugs.

As you can see, porting of Qt 3/KDE 3 application like Digikam, K3B or
Amarok to Qt 4/KDE 4 is not a simple task. Because changes in the API are huge, all elements must be tested, and some parts even re-written. The advantage of this approach is review of all old code with refactorisation,
simplification and various other improvements.

Digikam 0.10 is still in alpha. I advise against use of it in
production, at least until the first release candidate.

There are also kipi-plugins
and all shared libraries where Marcel and me are working hard to port to
native QT 4/KDE 4:

  • libkdcraw (including new 16 bits color depth auto-gamma/auto white
  • libexiv2 (including new full XMP metadata support)
  • libkipi (partially re-written and cleaned).
  • 7 kipi-plugins fully ported by me (SendImages, RAWConverter,
    JPEGLossLess, FlashExport, TimeAdjust, MetadataEdit, and

I present here a few screenshots of Digikam for KDE 4 in action.

As you can see, a lot of work has been done to design a clean
interface, moving away from the traditional dialog requiring to build a search
step-by-step with comboboxes, and towards a page which offers the available
options at a glance, at the same time retaining the ability to create
complex searches. With this approach we hope to create something more
user friendly. It is not finished yet, the UI in the screenshot can be
considered a preview, but we want to finalise this interface for the Beta 1 release.

The need to redesign the search interface came with the rewrite and
improvement of our database schema. Now, much more photo metadata
information will be stored and will be available for searching. For
example, GPS information will now be stored in the database, which means
that read-only files (think of your RAW images) can as well be

In Digikam for KDE 4, thumbnail kio-slave disappears. All thumbnail images are now generated using multi-threading (another part implemented by Marcel)
If you have already played with Showfoto, you have certainly seen
a thumbbar. The KDE 3 implementation used kioslaves without a memory cache
mechanism. It was slow. The new mechanism is faster and can be included everywhere in Digikam without a decrease in performance. I have
included the thumbbar in the Image Editor (F4) and in the AlbumGUI with Preview mode (F3). The same cache is used everywhere.

In KDE 4, XMP is fully supported. I have improved the Metadata Editor
kipi-plugin and rewritten all dialog pages to be more user friendly, and
to be more similar to other tools available under Mac OS X or Windows.

Gustavo Boiko, have ported some parts of Digikam to compile as a native
application under Mac OS X.

For KDE 4, I have fixed libkipi to become a pure image collection
interface: no widgets, no dialogs, no translations. All GUI components
have to be re-implemented in kipi-host using the right model/view
implementation. For Digikam, I have already implemented all of them. The
advantage is really visible here: the tree view used for all
physical/virtual albums in Digikam can be used as well with all
kipi-plugins (KDE 3 only provide a flat albums list, which is not really

For KDE 4, I have also implemented a new tool to edit a GPS track list of
several images at the same time. This tool uses Google Maps, but there are plans to use Marble if necessary, especially when the user does not have
network access.

With KDE 4, multiple root album paths are supported, including
removable media and network repositories. There will be no problems with using Digikam with a NFS server to host your images.

Full colour theme interface: this was also backported to KDE 3. Now
colour schemes are applied everywhere within the GUI. With dark themes (my
preferred scheme), Digikam looks similar to professional software available commercially.

This is a very important feature: auto-gamma and auto-white balance
with all RAW file format using 16-bit colour depth! Before, 16-bit
colour depth support required use of colour management to have a suitable
image in the editor. Without colour management, the user would see only a black hole image. This is due to limitations of the dcraw library, which does not provide a homogenous interface between 8-bit and 16-bit colour depth workflow.

In these screenshots, you can compare the same RAW image decoded:

  • On the left by dcraw in 8 bits colour depth and converted to PNG.
    Auto-gamma and auto white balance is performed automatically by
  • On the middle by Digikam in 16 bits colour depth using libkdcraw with
    a dedicated auto-gamma and auto-white-balance performed in Digikam
  • On the right by the LightZone... As you can see, Digikam is
    not bad!

Digikam is now able to play with all RAW images in 16-bit colour depth
without to use complex colour management settings: in your workflow RAW
pictures can be handled like JPEG files. This is a very productive and fast
method: for example, LightZone uses this style of workflow. Note that this feature was also backported to KDE 3.

I would like to remind to everyone that Digikam has been the first suitable
open source photo-management program with support for 16-bit colour depth
pictures as well! Even GIMP or F-Spot do not support it! Cinepaint can do it, but seriously, who will use it to play with pictures? Of course we have
Krita to also work with layers. We want Digikam with Krita to be considered the perfect photo suite.

On a final note, we would like Digikam to take part in Google Summer of Code: here is a list of potential projects.

Dot Categories: 


by John (not verified)

> I would not provide a "stable" release full of bugs.

looks like some KDE devs didn't like the 4.0 release full of bugs either :)

by Caulier Gilles (not verified)

Absolutely (:=)))

Gilles Caulier

by Aaron Seigo (not verified)

the irony is that a little further below you complain (rightfully) about how it wasn't possible to develop against the always moving libs from last summer (pre-4.0). 4.0 specifically, purposefully addressed that issue by getting the core functionality moved to "stabilize! complete features!" rather than "more new developments!". the expectation was that this would allow application developers such as yourself to get your efforts on track instead of being continuously held up by a never ending library development party.

by Anon (not verified)

4.0 is not a stable release. It is a development release. 4.1 will be the first stable release.

by Gilles Caulier (not verified)

And what about printing interface ???

In digiKam for KDE4 i have disable all KDEPrint support because all api become obsolete/unmaintened (fix me i'm wrong)

KDE 4.1 will re-enable it or find alternative (using QT 4.4 for ex.)

Can you said than KDE 4.1 will be the first release ready to use in production if printing interface cannot be used ?

Gilles Caulier

by Aaron Seigo (not verified)

printing already works in trunk/, so there's no need to wonder idly anymore. it uses the printing support from Qt 4.4 and it's progressing rather nicely.

by Gilles Caulier (not verified)

Thanks for the info Aaron. I wil review digiKam printing code in this case.

Gilles Caulier

by Erunno (not verified)

Well, then why is KDE filed under the "Stable" section on kde.org? And why does the release annoucement for 4.0 not contain any warning about this being a relase targeted mainly at developers? Not that I intend to beat a dead horse but I'm also somewhat allergic to revisionism. And I don't count developer ramblings on obscure blogs and mailings lists. kde.org being the main internet portal for KDE is as official as it gets. And it states that 4.0 was stable although reality disagreed on a regular basis.

Anyway, 4.1 looks like it's going to be a solid release and with 4.2 most applications should be finally ported.

by Gilles Caulier (not verified)

When i have started to port digiKam to KDE4 at July 2007, i have seen imediately several problem in core libraries. I don't speak about full desktop which for me have been unsuitable at the date.

This duing a lots of major changes in API. For big a big library as KDE, the list of regression tests is simply huge...

This is why is have never planed to try to plan digiKam 0.10.0 for the first KDE 4.0 release. It been impossible to have a stable appplication.

You have right. KDE 4.1 will be better, and certainly KDE 4.2 the first release which can be used in production.

This is not a critic. It's just the reallity. And if you look into the pass, the same situation have been seen with KDE 2.x to KDE 3.x transition.

Gilles Caulier

by Aaron Seigo (not verified)

> For big a big library as KDE, the list of regression tests is simply huge...

thankfully the number of real regressions has been rather small. there are some important ones, mostly that we knew about already due to technical issues we ran into (the ssl and proxy issues are good examples o those).

> It been impossible to have a stable appplication.

it may have impossible for digikam, i can see that, but dozens of apps shipped for 4.0 and were quite stable.

that said, you're quite right about "chasing a moving API" being a major blocker for application developers. getting 4.0 out the door was a vitally important step for addressing that and increasing the stability / lowering the regression counts in the core libs. this happens best when drastic new changes aren't happening any more, more applications stress it and more users do different things with it. it's far more pleasant and realistic to develop apps against the kde4 libs at this point.

as such, i think we'll see a bloom of applications in the 4.1-4.2 timeframe, digikam being a good example of that with it's release date of september.

by Martin Fitzpatrick (not verified)

Reading the note about the Google Maps/Marble integration made me think - is there an underlying system (one of the new KDE4 backends) that handles map integration? It would be better if the choice of map 'server' was determined system wide and applications queried through a single API.

That way any application needing to show map information, positioning etc. could do it in a simple unified way - and this could be easily configured to individual (or local) preferences.

Also, a more general question - is there a KDE4 API for access to any other data sources like these?

btw. Digikam looks very nice... as does the KDE4/dark theme (where is this available?).

Keep up the good work!

by Sebastian Kuegler (not verified)

Having a "Map Application" is already quite a step forward. As Marble supports the KML format (the one that's also used by GoogleEarth), it can probably be integrated with other "Map Applications" as well.

One step at a time, though :-)

by Martin Fitzpatrick (not verified)

Hah of course :) I like what I see - it just set my mind whirring!

I really like the way that KDE4 has moved towards abstracting data services to the applications, opens up a lot of possibilities. It would be nice if there were some kind of subsystem which could accept plugins/data sources and present them to applications. Maybe there already is... I'll be the first to admit I don't really know what I'm talking about ;)

But, yes, patience... patience..

by Gilles Caulier (not verified)

Here, i have started to play with marble widget integration in digiKam right side-bar for geolocation of photo :


Gilles Caulier

by sebas (not verified)


I would imagine the following use cases for this:

- tagging a series of photos with geolocations
- selecting an area in marble and show all the photos that have been tagged with that area

by Gilles Caulier (not verified)


This will be the second pass : to have a Search GUI based on marble to be able to find a photo using a map. It's in my TODO list...

Gilles Caulier

by sebas (not verified)

Thanks. That's actually a possible usecase I've used while presenting Marble. Of course it's something I'd love to use. Awesome to see you're planning to implement this. :-)

by Gilles Caulier (not verified)

Marble integration in digiKam right side bar is now complete on my computer. I will polish the code and commit this evening.

The screenshot have been updated:


Next stage is to build an interface to "Search photo on a map"...

Gilles Caulier

by Gilles Caulier (not verified)

Done in svn with Rev. 793334.

Gilles Caulier

by Gilles Caulier (not verified)

New blog entry about marble geolocation in digiKam have been created:


Gilles Caulier

by Fri13 (not verified)

"btw. Digikam looks very nice... as does the KDE4/dark theme (where is this available?)."

If im correct, that isn't a KDE4 color schema, it's Digikam own. Last stable version Digikam has supported limited color schemas, where user could select only a preview background, selected/non-selected image background and foreground and text effects for special text (labels and tags and rating).

But now Digikam has new theme possibilities what allow to change digikam window color to anykind you like, without effecting to other KDE applications.
Example, you can have blue-white color schema on KDE but then make a own color schema with digikam own theme tool and apply it so digikam window is using colors what you selected, not blue-white what is applyid from KDE control panel. This is very important feature to bring digikam as a professional application because colors should be so much middle gray as possible and this has be impossible.

by Martin Fitzpatrick (not verified)

"If im correct, that isn't a KDE4 color schema, it's Digikam own."

Thanks for the info, had never occurred to me that this would be useful in photo/image apps, but looking at the screenshots I can see why. I guess if it's just colour changes I can apply them through the normal KDE appearance settings as well. My eyes are going to be very grateful I think... (although the browser is going to look weird :)

Thanks again.

by Fri13 (not verified)

Middle gray is 127, 127, 127 (RGB 0-255 settings) but because it's computer monitor what has backlight and not gray-card what reflects light, it might be better to have 64, 64, 64 colors.

Middle gray is needed because other wise other surrounded colors affecst the photograph colors and it's "developing" is harder.

I were once in a great studio where was own room for Photograph manipulation, there were 15 PC's in that room, whole big room was painted with middle gray, all stuff there was middle gray and there were special lighting what were calibrated once a week and few times a week every monitor were calibrated (all monitors were those 10-14bit and not normal 8bit monitors). And then admins allowed normal users to use wallpaper what user liked.

And users were having photoshops etc open and their MacOSX default Blue background really were a shiny blue DOT in that room and I was shocked that they didn't understand that one of new students problem to have too warm images was simple as that, WRONG WALLPAPER in color controlled room :-D

With middle gray, all colors will be seen much easier and neutral as possible.

by Kevin Kofler (not verified)

What's the point of such an abstraction? Why not just use Marble directly and drop support for the proprietary Google Maps (now that we have a Free alternative in KDE)?

by Gilles Caulier (not verified)

Resolution of maps in Marble are limited. If you want more details, we need advanced tool. googlemaps is fine.

Gilles Caulier

by Anon (not verified)

Does anybody know where openSUSE (11.0 factory) users can find the new digikam? It seems neither to be available as single package nor in some extragear-RPM.

This is strange, as for any other KDE4 package than Digikam (and, equally unfortunately, k3B) openSUSE offers superb support and up to date packages., even of development versions.

Only for these two apps, my favorites beside Amarok, you can't use a KDE4 version.

by Emmanuel Lepage... (not verified)

They are still in alpha state, it is not very common (for any distribution) to provide alpha quality software by default. You can create a kde-devel account and compile them from svn everyday, like I do. That not hard at all, and you have cutting edge apps everyday.

By the way, three more screenshot I took from digikam (compiled today)


by Gilles Caulier (not verified)

Whow, nice photos...

and i can see than i'm not alone to love black color scheme theme (:=))))

Gilles Caulier

by Fri13 (not verified)

There is again new suggestion for selecting files, currently i use double click mode and i like ctrl+shift modes because those works for everything else too, on SVG editing, image editing and text editing, not just file management.

It's just very dificult way to get something better when there is so many posibilies what use one way but cant work with others.


by nice (not verified)

you rock, n1 photos !!!

by Anon (not verified)

"They are still in alpha state, it is not very common (for any distribution) to provide alpha quality software by default."

Obviously you have either not used openSUSE or not read my posting ;). openSUSE DOES provide quite commonly a wide rande of KDE4-and-apps-RPMs, mostly unstable development versions (e.g. a pretty usable KDE4.1 snapshot repository, updated every few days). That means the average openSUSE user does NOT have to use a SVN account, nor to compile any program, but must only add a "KDE:UNSTABLE" repository to the system.
See http://download.opensuse.org/repositories/KDE:/KDE4:/UNSTABLE:/

However, while there are lots of other software pieces, from pretty usable to "crashing all the time" state in this repo, I cannot find neither Digikam nor K3B (which is told to be quite usable already).

by Fri13 (not verified)

"I have included the thumbbar in the Image Editor (F4) and in the AlbumGUI with Preview mode (F3). The same cache is used everywhere."

Is there still possible to use current view style and not thubbar? I mean that old where are thumbnails and when user double clicks image, it gets open to editor or big preview?

I like this new thubbar but I like current style too :-)

by Gilles Caulier (not verified)

Yes, in editor, View/Show Thumbnails menu option.

In Algum GUI, i have forget to add this option. I will fix it. Of course, you can reduce to minimal size the widget separator betview icon view and thumbbar.

Gilles Caulier

by Gilles Caulier (not verified)

Done in svn with rev. #793002

Gilles Caulier

by Fri13 (not verified)

Nice! DigiKam just looks more and more very professional application, it has be very pro as in usage but now it looks too!

by Joergen Ramskov (not verified)

Looks like Digikam is going to ROCK when it arrives for KDE4.

by Gilles Caulier (not verified)

Here you can see more screenshots of new Advanced Search dialog.


Gilles Caulier

by LB (not verified)

I really love Digikam, thanks!!!

by DanaKil (not verified)

hi :)
any plan to use Phonon for the embeded video preview ?

by Gilles Caulier (not verified)

Already done in svn...

Gilles Caulier

by Anon (not verified)

What about going from version 0.9.0 to 1.0.0 instead of 0.10.0? I would reflect the mature state that DigiKam is in, so it would definitely be justified. Just like K3b - time was overdue.
I know that version numbers are controversial sometimes and that some will criticize your chosen number as hype-driven and being purely for marketing reasons if you put the number too high. (Well some people will always nag if you don't prefix with two zeros and have an -alpha appendix if they experience a crash and if you don't have the feature list of commercial alternatives).

And at release time it certainly would give you extra marketing - big version jump instead of simple port is more newsworthy for many more sites. You could surely reach more photographers and increase your userbase, especially if you have a Mac/Windows port ready, and with the KDE4 port I'm sure that the codebase is ready for that. And you could show people that they can trust the app and that basic features are not a problem. Not only that, with so many pro level features that stage is long behind.

by Gilles Caulier (not verified)

This subject have been already discuted on digiKam mailing list. I'm not favorable to toogle now to 1.0.0 version... A fondamental feature is not yet implemented : a powerfull backup/restore tool.

Gilles Caulier

by Vide (not verified)

With all the respect due, and even if others "pro" apps on other platform have this fuction, I don't think this is what makes Digikam a 1.0 program or just a 0.10. Backup/restore policies should be something outside the scope of a user program and should be part of the "operating system".
What's my point? That Digikam is such a great program and that the KDE4 port will be a gigantic leap that deserve a 1.0 version in any case :)

by kwilliam (not verified)

... for Joes like me, I'd rather see the tagging GUI improved. Using the mouse to click checkboxes is so slow! It would be better to have a good autocompletion feature so tagging could be done entirely from the keyboard.

Also, I'd like to see tagging where tags correspond to an actual X,Y location on the photo. (Obviously that would require the mouse, but for just one click it's worth the time.) If that was supported, it would be possible to upload directly to Flickr or Facebook from Digicam! It's frustrating to have to tag everything locally AND on online, so for large albums I usually don't bother tagging them locally. The Facebook API is all there (http://developers.facebook.com/documentation.php?v=1.0&doc=photoupload) we just need to support X,Y coordinates for tags. Any Google Summer of Coder's want to take that on? (I'm already invested in another idea this summer.)

by DanaKil (not verified)

I agree that, at least double-click on a tag (or maybe even single clic) could check/uncheck a tag in the tags treeview (yep, the checkbox is small)

Another idea : a shortcut that can apply the last applied tag to the current picture

by Gilles Caulier (not verified)

Same here. I work currently on keyboard shortcut to assign tags on image (like kmail do with folder assignement)

Gilles Caulier

by DanaKil (not verified)

you could add a button at the bottom of the tags treeview with something like "Set a shortcut for the current selection of tags" (so I can choose some tags for a picture, assign a shortcut for this set of tags and then easily apply all these tags in one shortcut)

just an other idea (I know dot.kde is not bugzilla but well...) : when I tags a lot of picture, I often works in thumbnails mode and select all pictures that I wants to be tagged with a particular set of tags. And often, I release "ctrl" for the multiple selection and lose all my selected images (and then I cry).

Maybe you can add in the Edit menu a mode to easily select multiples pictures : no need to keep ctrl pressed, when you click a picture, it is added to the selection, if you click on it again, it is substracted from the selection

by jospoortvliet (not verified)

Maybe the way Dolphin does allow you to select several items by using a small icon overlaying the item might be a solution.

by Gilles Caulier (not verified)

Yes, there is an entry in digiKam bugzilla. Marcel will take a look when he port all icon view to Qt4 model/view (this part still use Qt3 transition classes). It's planed later than 0.10.0 release

Gilles Caulier

by Gilles Caulier (not verified)

I'm currenty working on, for KDE3 and KDE4 version.

Look this entry :


On the "Caption and Tags right sidebar, there is a new fied where you can type tags hierarchies (yes, more than one at the same time) using only keyboard. Auto-completion is supported :


The Tag Edit dialog have been improved in the same way. Look here :


Gilles Caulier