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.

Comments

Since you discussed a new database schema and more metadata, I was wondering if this is all being stored (and searchable) using Nepomuk and Strigi or if Digikam is maintaining its own database? It would be great if all metadata in Digikam, including tags, ratings, as well as camera information, could be shared with the rest of the desktop. For example, Dolphin now has tags and ratings for files. For pictures, this should be the same ratings you see in Digikam, or whatever other photo application one might be using.

I'm actually wondering the same thing about Amarok. This is the kind of integration I look forward to seeing throughout KDE 4.

I'm sorry to hear that. Please reconsider as it is one of KDE's key features to offer broad integration. It is one of the features what makes it shine compared to other Desktops. Database applications like DigiKam should promote this feature as soon as possible. DigiKam on the other hand will only gain in importance, insight, influence and momentum.

I dont see reason to horry nepomuk integration. I think digiKam has great handling with photographs with it's own ratings and tags. Later nepomuk support would be nice but now I dont see any reason for it. Because I dont see Digikam as a tool for "normal joe" who just browse wallpapers and other images what avarage joe downloads from internet. DigiKam is for professional/hobby photographers , who keeps digikam running anyway when needed to handle big amounts of photographs and easily to manage those.
Later that nepomuk integration can be nice but.... Mayby I'm just wrong person to judge that with my photograph library what includes tens of thousands of photos and browsing those with nepomuk sounds bad because I need to have tags and comments on photos and albums what I dont want to find when doing desktop search.

I'm totally agree with this viewpoint. There is not urgency to include Nepomuk support for 0.10.0 release. Of course, later, when new digiKam core Database interface will be stabilized, something can be done to connect digiKam database to nepomuk. But in all case, later 0.10.0 relesase...

As for Nepomuk integration, I'm really waiting for that as well, because I understand that it will not only offer the infrastructure to do the indexing (tagging) and allows for the same lightspeed categrization and search we are used to with digiKam, but also allows tight integration with other apps in the platform: marble with the GPS -data, akonadi integration etc. So far my major reason for not using digiKam to its full capacity has been the problem, that its not se well integrated with the desktop.

For example, I have some 6,000 photos, for which digiKam is great editor, but I'd like integrate a hoard of non-photos with slightly different needs to the same system. And I want to tag them all, and I want to tag audiofiles and keynotes in the same system. Somehow I just don't see why I should manage my .mp3 and .xcf -files with digiKam. And if I have to tag these all, why use digiKam. It's a fine editor but lacking integration keeps me from using it more.

I would think that from the developer's perspective using existing tools is a good idea, because then one can concentrate on the essential. From the user point of view being able to swicth from one tool - digiKam - that is great for one thing, to another, say Dolphin, Marble or Gwenview, which has different strenghts, is a motivation to use the stuff.

At the moment the issue seems to be that XMP is malformed RDF, and thus 1-10% of the XMP metadata is in danger of being lost in conversion to RDF. The sooner we get a uniform access to the metadata, the better. Therefore I really look forward to integrating all these great new digiKam features into the wider desktop, so that I can keep on using it when the stable KDE4 release comes out in the fall.

Also, digiKam support rating since many year (:=))). We don't need neopumuk for that...

Note : i sync KDE3 and KDE4 version when it's possible. 0.9.4 version will come before this summer with a lots of improvements like simpler entry of tags, or a new time-line tool. See my blog entry for details :

The #1 thing I'd like to see in Digikam is some form of version control, that lets you go crazy and touch up your pictures while preserving, at least, the original picture. These issues were discussed at length here[1], but all that came out of that particular bug was a confirmation dialog when saving an image from the image editor.

Don't laugh now, but this is the most important thing that is keeping me from migrating my parents to Linux. Here is the scenario, that would apply not just to parents but to any user lacking very strong self-discipline: They find a picture that they like, so they fix it up a little. Apply red eye. Crop it. Tweak the colors and contrast. Make it look better on the screen. That's what Digikam invites you to do. Now they decide that they *really* like the picture, so they ask me to come over and help them make the most of it for printing. And then it is ruined, because of the sloppy, lossy editing that they already did. And that's not their fault, imho, but that of the software that is too unforgiving.

Honestly, if you guys need RAW users to jump onto digikam, then you need to learn why on earth one uses RAW. The way digikam works on RAW files is plain wrong. You are planning all this for the average shooter, but the average user doesn't use RAW, because he/she just doesn't need the overhead of work and diskspace.

Those that do use RAW, honestly, don't do autowhitebalance. One ofthe main purposes of RAW is precisely being able to manually correct white balance when the camera's autowhitebalance goes wrong, being able to fix highlights and shadows, curves... without loosing quality "thanks" to the camera's extra processing.

First, I read "it's not bad!". Well, it is bad, real bad. The left shots from digikam are washed out,flat, not contrasty at all. Lightzone one looks properly exposed and all lines are rather defined, contrasty.

Then, I wonder why you had hidden the righthand toolbar from lightzone. I'd love to know how you are comparing results, ie, what you exactly did to them, why Lightzone gets it right and why showfoto didn't.

So the issue is only about accuracy? No.
Then, what's wrong? digikam's workflow to process RAWs is all wrong, and anyone using RAW workflows should possibly know why. I give a couple hints in the following lines:

1) Digikam opens the raw photo applying the _settings_ found n the digikam menu.
If you, like most photographers do, are processing 800 shots and each requires a different setting, you can't go and change the digikam settings in the menu each time you want to open a file, it's toooooo slow.

You can't just apply a default white balance and then set white balance _again_ in showfoto. You are doubly processing the image and thus loosing quality.

2) When tweaking raw files, precission is also important. One needs to tweak images once and again until one gets it right... apply sharpness 1, 1.1, no, 0.9... if I wanted to do this in showfoto, it would require me to process->undo->process->undo->process->undo each time, and each time opening and closing the dialog from the menu. Really slow.

3) It'd take me a whole month to process 100 shots using digikam/showfoto's procedure shown on the previous comment. The average raw shooter takes around 1000 shots for a session and needs to process those in a single day, not spend a whole month on it. it's about fast batch processing. If it were this slow with any other apps, people would end up using jpeg instead.

So honestly, if you want to do RAW, you guys need to learn what RAW is for, and how real users use it. Showfoto coders seem to ignore users here, unlike other opensource projects around.

Sometimes coders just forget that they need to approach their customers/users to check what they really neeed...

"Then, what's wrong? digikam's workflow to process RAWs is all wrong, and anyone using RAW workflows should possibly know why. I give a couple hints in the following lines:"

I would like to see rawstudio ideas taken to DigiKam's RAW editor, where you can have thubbar (already) showing all images and then make a three different versions from one image and fast switch them to see if one is better than other. And let this window/application to mark those good versions and then apply it to images what are in database.

I like the idea that first user just imports images to database, add's few info like albumb name, and then from database, is started the real RAW processing where user open all images and can set one setting for all or process everyone with own custom settings.

Mayby biggest "flaw" what i can find from digikam is it's editing window, possibilities are GREAT but own window for every edit function and preview window is small by default etc. Mayby i would do somekind mockup for it. If would be possible to get showfoto work so it's editing goes in it's own window, or is it somekind technical limit?

>I would like to see rawstudio ideas taken to DigiKam's RAW editor, where you
>can have thubbar (already) showing all images and then make a three different
>versions from one image and fast switch them to see if one is better than
>other.

> First, I read "it's not bad!". Well, it is bad, real bad. The left shots from >digikam are washed out,flat, not contrasty at all. Lightzone one looks >properly exposed and all lines are rather defined, contrasty.

>==> the preview of JPEG image embeded in RAW file. No auto gamma/Wb are set here. The image is displayed as well.

okay, this was confusing. Certainly embedded jpeg files cannot be compared to a processed image.

>2/ a slow way using color management where users can adjust all (gamma, WB, etc..)

Even slower?? The process about processing RAW is slow by itself. The point is making it fast by applying a proper workflow. Btw, I tried that plugin, I hope you get it right, since it wasn't doing anything last time I gave it a test.

>And you forget than i'm _also_ a photographer and i _always_ use RAW format
>to take pictures.

If you are using RAW on a daily basis, you sure noticed the way digikam works with RAW files isn't usable. I was questioning you guys on why you follow this way of coding. You know (since you use RAW often), that it's not comfortable. Just too slow for a daily usage. Right now there are much better free alternatives like rawtherapee, ufraw or rawstudio for this task.

I myself even, and other coders (yes, I do code, and I have done code for digikam), have addressed at you issues in the past and even offered code for doing a proper RAW workflow. But you seem to ignore all of us. Why so?

If you really want to promote RAW in digikam, maybe some tweaks must be done and help from others offered in the past accepted.

>If you are using RAW on a daily basis, you sure noticed the way digikam works >with RAW files isn't usable

It perhaps unsuitable for you, not for me...

> I myself even, and other coders (yes, I do code, and I have done code for >digikam), have addressed at you issues in the past and even offered code for >doing a proper RAW workflow. But you seem to ignore all of us. Why so?

Really. I don't remember somebody like you to post patch or any coding help. Try again...

Have you asked KDE e.V. for sponsorship? And if the e.V. board declined (and if so, I really want to know why!), the LGM organizers themselves? They are now holding a big donation drive to be able to sponsor as man developers as possible: http://pledgie.com/campaigns/613.

Please clear it up. Maybe even a separate Amarok update post. I'd rather see false rumors floating around Amarok.
A lot, and I mean A LOT of people are waiting and looking forward to this great change that is Amarok 2.0.

Quite a few people on campus are predicting that it will be BIGGER THAN WINAMP used to be before AOL let Winamp fall by the wayside.

what are the plans on gallery integration plugin ?
what i would ideally like to see, a complete sync of digikam/gallery, so any changes in digikam can be synced to gallery instance, any comments in gallery can be synced to digikam etc ;)

Well, I've had a hard time of it of late and there has been little progress. I apologise for that.

It's still somewhat in flux to be honest.

With KDE4 there are so many new techniques and technologies that I'm really struggling to work out the most appropriate way to do this.

I've raised a couple of questions to other developers in the past about the use of such techniques but I've not had a huge response (not that I've really pushed it hard as I have not got the time right now to do much about it anyway).

My current lines of thinking are such.

1) I want a nice sync framework that goes beyond Gallery and applies to other web services e.g. Facebook, Flickr etc. etc. as well as e.g. a file or a CD ROM for achieve. The principle is in itself applicable to a lot of things.

2) Other approaches are out there and I want to make sure myself (or others) pick the right model for this with regards to Digikam/KIPI and (more widely) KDE4. A good example of this is Conduit. It is a separate program aimed mostly at Gnome (although there is some vestiges of a Konduit project, it's pretty hard to find out any info about). It integrates to libopensync and can upload FSpot pictures to e.g. Flickr and Facebook etc. I quite like this approach and it may be worth doing.

3) Nepomuk. To me this is the biggest interest but I'm not fully appreciative about what is is capable of at present, but I have a "feeling" this is the right way to go. However, this is a *huge* change IMO and not one that is likely to happen overnight. To explain:

Nepomuk is a PIM (personal information management) abstraction in KDE4. It's designed such that you can build e.g. contact systems and email clients on top of Nepomuk and it makes your personal data available via predefined interfaces. This allows lots of interesting things to be done in applications and with e.g. plasmoids etc. too. I attended the Nepomuk talk at Akademy and was quite impressed by the principles. The talk focused on the traditional PIM information like contacts and emails. I asked a question enquiring where the developers saw the boundaries of this API as it could be applied to applications such as Amarok or Digikam. They devs responsed saying that indeed this was possible, but they've not targetted these apps at the moment as it was early days. I'm pleased to say that the Amarok crowd now have a GSoC project that aims to build in Nepomuk support there so things are happening along the lines I envisaged (hopefully this project will be a success!)

In my mind we could create a Nepomuk profile for "Images and Videos". We could then impelment a Filesystem backend for this and retarget Digikam to use this. In theory Digikam could then have "accounts" (just like an email application has multiple IMAP accounts) and you could plug in a Nepomuk backend for Facebook, Gallery etc. etc. This would be IMO the holy grail implementation and it's this dream that's (in part) causing me not to progress with the work done to date.

Hopefully I'll find time to explore the options properly with the main devs, but this approach changes a lot of the fundamentals of Digikam and KIPI as a whole and I feel I'm certainly not qualified or capable (both technically and time wise) to push this approach.

Hopefully some of the core devs will take up some of the ideas and either implement them or blow them clean out of the water. Either way it would let me move on!!

Thanks very much for this - looks much more powerful than f-spot! Just wondering, is it possible to replace the sidebars with the weird text rotated 90 degrees with something better, like an okular-style sidebar? Other than that, the new interface is fantastic!

Is it now possible to scale a small image to fit the screen (with anti-aliasing) by default? The gwenview guys seem to not know how this is done and you have to zoom in yourself at every image (very annoying considering collection of >10000 pics) and even so, only at fixed intervals (150%, 200%). THIS IS UNACCEPTABLE. You can add all the maps in the world and still not achieve your core functionality of displaying the damn inages WELL.

Second, the tone of your comment is unacceptable. Nobody will want to spend their free time implementing things you shout for, which means you will have to offer your own time to implement it. And, given your incivility, you will then have a hard time finding people prepared to interact with you enough to accept your patch.

Are you always this rude to people who give you things for free? Seriously, what personality disorder do you suffer from, precisely, that makes you think this is a) acceptable behaviour, full stop and b) behaviour likely to endear you to the developers you are entreating?