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:

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
geo-coded.

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
suitable).

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
dcraw.

On the middle by Digikam in 16 bits colour depth using libkdcraw with
a dedicated auto-gamma and auto-white-balance performed in Digikam
core.

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.

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.

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.

> 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.

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?).

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.

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 ;)

"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.

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 :)

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.

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)

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.

"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).

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.

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 :)

... 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.)

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