Martin Klapetek's blog

DigiKam has migrated to git

Thanks to the marvelous job of our KDE sysadmins, digiKam is another project to join the git repository. All the code (digiKam, kipi-plugins) that lived in the SVN is no more accessible through SVN and all is part of git now. DigiKam and its dependencies live in several repos, but thanks to Marcel Wiesweg, you can use a nice small script, that will get you going:

1) Edit your ~/.gitconfig as given in
2) git clone digikam-sc
Enter the directory
3) Execute ./download-repos

We're planning to release one more version from 1.x branch in about two weeks, the last one, version 1.9.0. After that, all focus will go to the new 2.0 branch, which features new non-destructive editing with versioning support, face detection & recognition, extended geo-location features and scripting support. Second beta of this branch is already out and you're all more than welcome to join the testing!

DigiKam team

KDE Imaging Coding Sprint 2010


Last week, from 27th to 29th August, developers of KDE Imaging group met for their third coding sprint organized by digiKam lead developer, Gilles Caulier in his hometown, the beautiful southern French city Aix-en-Provence. The time was shortly after the end of Google Summer of Code, in which digiKam participated this year with three students. It was therefore a perfect timing for us GSoC students to get to know our mentors in person and get to work with them side-by-side.


On Thursday morning, I met Andreas Huggel, who flew down from Malaysia. Andreas is Exiv2 developer and is working closely with Gilles on metadata support for digiKam. We went together for lunch during which we found out that it was the first event like this for both of us. A few hours later, we met two indian guys having absolved a 24 hour flight, Aditya Bhatt and Kunal Ghosh. Aditya is a GSoC student working on face detection and recognition for digiKam and Kunal is a Summer of Kode developer integrating an ECMAScript support into digiKam.

In the Thursday evening, we met Michael G. Hansen and Marcel Wiesweg at the Maison des Associations Tavans, where we attended local the Linux User Group's meeting, watching Gilles giving a talkabout digiKam. Shortly after that, Gabriel Voicu, another GSoC student working on geotagging features for digiKam, was dropped by bus near Aix-en-Provence, no idea about his whereabouts, he sent us his GPS coordinates and we looked him up using Google Maps, so Gilles could pick him up by car.


On Friday morning, we all met at hotel Paul's breakfast. We could finally put real faces to all the email addresses and IRC nicks. Any social barriers were very shortly overcome and chatty discussions were started, about cultural and national differencies, about our lives, school, work and of course KDE and digiKam. A very lively discussion continued during our way through the really nice city back to the Maison des Associations Tavans, which was also our "coding place". Friday was very hot and dry in Aix. But also very fruitful- in terms of work as well as in terms of awesome fruit markets.

Kunal was working with Gilles on improving the scripting support in digiKam. The main idea is to add a new script interface for digiKam, based on QtScript API. This interface will provide a simple way to manage a list of custom scripts, dedicated to add new tools in Batch Queue Manager. The digiKam API will be exported and available to customized scripts. A settings widget have been designed by Kunal to setup scripts in Batch Queue Manager. Gilles and Kunal have reviewed GUI and current implementation to patch Batch Queue Manager with a new script view, assignable to items to process. This will be available in the upconimg 2.0 version.


Aditya was improving the face detection/recognition stuff, together with Marcel and Michael a discussion about ways to store face tags in metadata was begun. Aditya then worked hard with Marcel on polishing the face detection, debugging the database code, implementing the use of using internal tags, which are not visible to users, for storing face scanning related data. We also checked how other projects work, especially Apple's iPhoto with Andreas' MacBook. Aditya then also discussed the possibility of having a unified batch task manager. "Currently, most of the batch jobs in digiKam run in the GUI thread and make the UI slow, such as the fingerprint generator, metadata read/write, etc. We should have proper multithreading for this (my batch face detector partially implements this), and have a nice unified batch task manager, as one place to control all batch jobs.", he adds. Last but not least, Aditya did a lot of bugfixing in libraries used by face detection/recognition in digiKam - libface and libkface. All the code was then stress-tested on Gilles's whole photo collection. "It works pleasantly well, but also giving us a few directions for debugging (read: crashes)" says Marcel.

In the noon lunch-break, Gilles' wife and son joined us and we all enjoyed a fine French cuisine with Gilles explaining to us what food is what. "Then came the surprise, a menu card which I couldn't read and the menu which consisted of mainly non-vegetarian food. Well my bet on the lunch order paid off and I had a pleasant meal and also identified food I should keep away from :)", says Kunal. As work was waiting for us, we didn't stay too long and soon headed back to coding.

Andreas, besides a lot of coding on Exiv2 project, also discussed with Gilles support of new types of metadata for video files. Then with Marcel he analysed an issue with the algorithm to distinguish images and also got a first-hand update of the current metadata process flow in digiKam. "It was interesting to realize how pronounciation of words becomes important when you talk to each other face-to-face as opposed to exchanging emails and how much a bit of gesturing and scribbling on the black board helps to convey a message.", says Andreas.


Friday evening was in the light of italian cuisine with the menu in Italian (not that it would make much of a difference from French to me). This was a great evening with great amount of talking about KDE and related stuff, but also Gnome, Linux, Microsoft, Android, computers, phones...and all that what you would expect from a bunch of developers. Also Laurent Espitalier, who drove down from Isére, France, joined us that evening.

Saturday we started again at hotel Paul with breakfast, during which we again discussed everything and nothing. Me and Aditya were stoked on FotoWall's animated GUI and we discussed some animation possibilities inside digiKam. We both agreed, that digiKam could use some more "live" UI. I've already started looking into Qt Animations framework and I have a few places in digiKam in mind, which were like directly created for animations. But first things first.


I continued my work on image versioning support for digiKam and managed to extend the functionality of the 'Revert' button in the image editor. Now you can revert to the last saved version, and if this is a subversion of some original image, you can then revert to the original as well. With Marcel we solved hiding/showing all image versions except the current version using internal tags, we redefined the versioning concept a little bit and solved lots of bugs too. I found out, that even though it works ok on my computer, Gilles had some rather severe issues with it on his computer, so this brought me to lookup through the whole code, do lots of cleanups and create a simpler and more flexible design.

Michael worked together with Gabriel on improving the new search UI in the map views. During discussions with Marcel, these three seemed to solve the question of an intuitive workflow for searching, selecting, filtering, zooming and panning on the map, a functionality currently exposed by 12 buttons in a row. Together they came to a UI mockup and an intended workflow where a click willl usually do what the user may expect and images do not disappear, but are greyed out if filtered or unselected. "We're pretty confident that we found a good solution, so Gabriel and I talked about implementation details and Gabriel started coding on it.", says Michael. He also added two new things into GPSSync - a split map view, which shows off the model-view capabilities and a new configuration dialog. With Gilles, Michael got into discussion about how sidecar files should be handled.

In Saturday's noon-break, we went to discover the local markets, with plenty of colorful fruit and vegetables, beautiful flowers, crispy bread and baguettes, souvenirs, and piles of other stuff too - old vinyl and cassette music, historic newspaper from 1894, bars of soaps, silver cutlery, glass, dresses, hunting name it. During our walks through the city, we all took many pictures of this really beautiful city and its offerings, which you can find on flickr. After quick lunch, we headed back and did more coding and polishing. Luckily it was quite windy that day, so the temperature wasn't as high as friday.


Laurent Espitallier uses and promotes digiKam at his work with one French government agency, where they use Nikon Project software for managing photos taken by team of photographers and which are later used in documentations. With digiKam, he's working on database import from this Nikon software, but also from applications such as iPhoto, Picasa or Aperture. Laurent and Gilles also discussed the importance of XMP sidecar files support for all read-only image formats, for example RAW files. With Nikon Project to digiKam migration, the goal is to be able to patch digiKam database with all Nikon
keywords tree-view and all virtual folders created (in Nikon, Tags and Virtual folders are separated concepts). Only the first feature can be easily achieved when pictures are back-ported without a need to write a specific Nikon database parser. The images are just exported from Nikon collection using right options and then imported in digiKam.


During the day, we had a refreshment in form of the famous Czech beer, which I brought with me and for which Gilles provided proper cooling. Also I can't forget the great French wines we tried during dinners. The Saturday's dinner was really great. We settled in a small quiet and very nice restaurant and as everybody was really enjoying it, no one felt any need to go back to sleep even though the time has advanced very close to the midnight.

I was leaving on Sunday, shortly before noon, so I didn't have much chance to do any coding, but the rest, except Gabriel, who already left during the night, stayed and kept working. It was hard to say goodbye to such a great team after all that awesome time we spent together. I am really glad and very thankful that we could meet each other in person, for which I'd like to use Andreas' words: "It will make future team work easier and more fun". It is most certainly true and this would not be possible if it wasn't for KDE and especially KDE e.V. The most biggest thanks to the e.V. for making this happen. Thank you!

GSoC: How is digiKam's non-destructive editing? (This time with pictures!)

Hi everybody,

long time no blogging. Time to fix this bug.

So...without any long prologues - (hold your breath now) - it's working! (Say WOW™). But how well does it work you ask? Pretty good! Ok ok, let's get some overview.

You open some image in digiKam's image editor, you add some filters, do some transformations, use some color-altering-stuff untill you're satisfied with your creativity. Then you simply close the editor, autosaving kicks in, and bam, you have new version of your original image, which stayed completely untouched. Available versions can be then viewed/switched in the new sidebar widget (see pic below). The sidebar allows you to display all the available versions either as a simple list or as a tree, which is basically the same list with padded entries to reflect the relations between the images. Later it will also be possible to do some file operations in the sidebar, like Copy/Move/Remove etc. In the main view with thumbnails, (sub)versions are now marked by an (ugly) icon as you can see in the screenshot below, but I'm looking forward to hear your ideas about how to mark them in some better way (of course it will be on/off switchable). Let us hear your ideas or see your mockups!


You can set in the options to have only the latest selected version visible in the main digiKam view, or to have all of them visible and viewable all the time. In the first case, you select the image, then in the sidebar you select which version do you want to see/edit/work with and the pics get switched. Simple as that. They are all physically in the same folder, with the same filename but with "_v1" appended for the first version, "_v2" for second etc. So yes, the versions are complete images, just like in F-Spot versioning. The image's versions are saved in the original image format, except RAW (of course) - format for storing RAW versions is settable in the Settings, for now it's possible to do the saving in PNG or JPG.


Next new thing is list of all used filters/transformations/effects on a particular image. This is part of the new right sidebar tab. So you can see what modifications you did to the selected image. This comes very handy in the Image editor. You apply some filter, it will show up in the new sidebar. When you press undo, the last entry will get a 'disabled' look, so you know what was undo-ed. Also when you press redo, the entries will get 'enabled' accordignly. Then when you have a bunch of disabled entries and you apply some new tool, the disabled entries will get lost and they will be replaced by the new applied tool, just as you would expect. So in short, in image editor this list presents a visualised undo/redo list. In the future I'd like it to be able to dynamically switch any entries on or off to see how would the image look and also to change the used values for particular filters. Basic foundations for this are already layed down. This will later also allows you to take one set of modifications and apply it to any other images.


In the image editor, the 'Save' button is now replaced by 'New version' button. By default, when you're editing again some already created version, not the original image, the changes are saved back to that version. The new version file is created only in case you're editing the original. So, when you're editing some version of the original image and you want to have the changes in a new image (and preserve the old version), that's what the 'New version' button is for. It will create a 'subversion' of the current version. Another use is to open the original, modify, click 'New version', click 'Revert', do another set of changes, click again 'New version' and this way you can quickly create several versions off of the original image and after closing the Image editor, see them all next to each other.

And now you probably ask "When can I get all of this?" Currently it's all in KDE's svn repository along with Aditya Bhatt's Face recognition and Gabriel Voicu's Geotagging features and you can 'svn co'-it and build it yourself, but it's moreless an alpha quality code. This GSoC branch will be based on the soon-to-be-released 1.4 version and will be tagged as a 2.0 version around this Christmas.

We have a KDE-Imaging Coding sprint ahead of us in Aix en Provence, which I'm attending and very looking forward to. We'll discuss & work on the whole GSoC work, on some new ideas for digiKam and do improvements here and there. If you have some ideas, mockups, patches or simply something worth discussing during the sprint, just join the digiKam devel mailing list and shout :)

KDE-Imaging Coding Sprint logo

GSoC: explaining digiKam's non-destructive editing concept

Hi digiKamers, hi KDErs, hi planet,

few days ago I blogged about the progress of non-destructive editing in digiKam. According to your comments, I take it that there is some misunderstaning in the whole concept. So let me explain it to you :)

The non-destructive editing will be done in such way, that if (and only if) you do some edit to some image, there is automatically created new file, which is a copy of the original with applied changes and with list of edits you've made saved in metadata. Next edit you do, is again applied to the same already-created version and the list of edits in metadata is updated. This is done for example for you to be able to edit the edited file with some external app, let's say GIMP. If there would be only the list of edits stored somewhere, you wouldn't be able to edit it with nothing else until you'd export it from digiKam.

However, when you do some non-reproducible changes, like using some effect, which uses random values for initialization, we need to preserve this exact output, because it can't be reproduced in the same way (thanks for the randomness), so this gets saved again to the same file, but next edit you'll do, will need to go to new file. This will still be presented as one version in digiKam. But there is some ideas about adjusting the nondeterministic filters in such way, that even those could be reproduced when the proper values are stored. This approach would be much better, but I'm not sure if that could be done. But we'll definitely look into it.

About the "Originals" folder. As I wrote, this is supposed to be fully customizable. Think about some photos you take, you pull out the card from your camera, stick it to your PC/notebook/netbook/whatever, do some changes in your digiKam and then you want to fly away with the card to give some presentation. But you want to show only the better versions (the edited ones) and not go through three almost-same pictures in presentation again and again. That's why there will be this option, to move the originals into some other folder, so you can still have them present, but they won't get in your way when not using digiKam. Also think about mobile phones. You connect your phone to your PC, do some changes and then you want to show your friends some photos you take, but again, you don't want to show the originals, you want to show only the better versions. Think about having 100 pictures and that you'll do some edits (autolevels for example) to 50 of them. Then you would have 150 images in your mobile gallery and you would show every second picture twice. Again, that's what the "Originals" folder is for. And again again, it will be customizable. Or optional if you want. So you can just turn it off completely and your images will stay all in the same place.

Then there is the version management. Every edit you do to the original file, will create another version. If you edit the already edited version, the it's simply saved to the already created version file. Only when editing the original you'll get a new version. Or you'll have a possibility to 'fork' it to manually to create a new version. So for example you do several crops to your images. You simply open the original, do one crop, new version is there, saved, ready for other operations. You switch back to the original, you do different crop and another version gets created, again, every other edit you'll do will be saved in this same file with updated metadata. No one-effect-one-file-thing. Then you should be able to display all your versions along. Something like virtual album. So you can see all your cropped images next to them. But not only cropped, imagine you do some color changes or some other effects. Then you can see all your versions next to each other and pick up the best.

Next thing is GUI. There will be some kind of indicator, that you have more than one version, or that you have done some edits and you're able to revert them. The looks of this is not clear yet. But we're open to any proposals or mockups you may have. Also, with every opened version, you'll see a list of changes you've made and you should be able to remove any edit in the list. It would be cool if you could simply change the edit's values and have it reapplied, but that will probably take some more time to accomplish. But I'd like to see that happened.

And if you're thinking about buttons in the editor GUI, Save As... definitely won't disappear. Probably Save button could go away as it will be automatically saved after each applied (meaning you click Ok) effect. Instead of Save button there could be a Fork button, which would create completely new version (copy of the current edited version). Other changes in the UI haven't been decided yet. I'm focusing on the foundation right now, GUI will come later (but soon;)

That's basically how the non-destructive editing will be done in digiKam. Hopefully it's much clearer now to all of you :)


GSoC: update on digiKam's non-destructive image editing

Hi all,

little update about the progress that has been made. So far, there are no visible changes to the user yet (if you don't count tons of new debug stuff on console), all work has been done under the hood. The good news is, that the basics for non-destructive editing has already landed in the codebase. You can now use Brightness/Contrast/Gamma tool and the Autolevels tool in such way, that it will automatically create new version of the edited image, apply the changes on the new version, move the original version to "Originals" folder located in original image's path (will be fully configurable) and save the new version as {originalImageName}_v1.{originalImageFormatExtension}.

There is no GUI yet, which would be able to manipulate with versions and used filters on them, but that's all on plan and I believe, that some basic GUI for reverting the image to its original state could be done at the end of next week. You will find it as a next tab in the right sidebar in digiKam's Image Editor, although the exact appereance of this UI is still a work-in-progress. But as soon as there will be something usable, I promise to bring you some screenshots ;)

Stay tuned,

Oh yeah and to answer the question "What about editing done with other programs?" - well, this is kinda tricky. It will definitely be possible to revert back to the original image when you edit some of the versions and not the original itself, it should also be possible to just revert this one change. But if you edit the image, that has no version present (and thus not backuped the original, ie. you edit THE original), there's no way to revert back unless we duplicate all of your images, which is rather unwanted. It could be possible to do so, when you open the image in some external app from digiKam, but most probably not if you open it directly.

GSoC: Non-destructive image editing for digiKam

Hello to all the great KDE people and especially digiKam fans!

My full name is Martin Klapetek, but everyone calls me Marty and I can be found on most services like IM or IRC by the name mck182. I'm 22 and I'm from Czech republic and ever since I started with Linux, I immediately become a huge fan of KDE (3.5 back then). I'm a terrible musician (playing guitar, bass guitar, sometimes even piano [you don't want to be there]), promising art painter and hopefully-soon-to-be graduated college student with bachelor's degree in Computer Science.

I've been accepted to this year's Google Summer of Code with project to enable non-destructive image editing and image versioning for digiKam.

I'm very keen on taking photos and I've been using Google's Picasa for organizing the quantum of pictures I've taken. But the Linux version was more and more unusable lately for me, mainly because problems with multilibs (I'm running 64bit system and Picasa needs 32bit Qt libs and I'm using non-official-distro Qt packages, so there were some conflicts) and also because I hate it's wine-ish look & feel (& speed) and non-integrationess. So I've decided to use something more KDE fashioned and the sight was set on digiKam.

I like Picasa's possibility to edit your images in any way and then anytime you come back and feel like it's not good enough, you can simply reset the image to its original state and start over. This is the feature I'd like to bring to digiKam during this summer. This will go along with feature for having multiple versions with different modifications of one image and easily switching between them.

The non-destructive editing will work fully automatized. Now when you do some changes eg. use some filters or adjust levels, you need to save your image first and if you just save, you lose the original. With the non-destructive editing, it will automatically create new version from the original and it will store all the changes there, all without bothering user about saving the image and without actually touching the original. Every time you switch to the original and start new modifications, it will create another version alongside with the first one. Each version will also be manually forkable to another new version.

That's in short my project for GSoC 2010. I'm very excited to finally do some real work for KDE and to contribute to the world of open source. I'm looking forward to work with the already-shown-to-be-awesome people from digiKam team and especially with Marcel Wiesweg, my mentor :)

I wish happy coding and lots of fun to all the accepted students. Let's make KDE proud of us :)


PS: More detailed posts will come when the real work will start ;)

Syndicate content