Today, after 5 weeks of intensive work to port source code (and one million of commits on svn), digiKam compile fine now under QT4/KDE4.



Of course, port still uncomplete. Duing indeep changes in new KDE4 and QT4 API, few crash must be fixed in new implementation. It still unstable and not suitable as well.But it's just a question of time...

Today, Vardhman Jain has added a new kipi-plugin into svn to export picture collections to PicasaWeb internet service.



This is a first beta release of this plugin which compile with KDE3. Features include are Uploading photos, Creating Albums, support Tags, and resize images.Some more GUI improvements would be done soon. All

The computer magazine c't compares different photo management suites for Linux in issue 14/2007. The focus is on organizing photos and the most important image editing features, like color correction, sharpening, noise reduction or effect filters. Compared to KPhotoalbum, f-spot, picasa and GThumb, digiKam was the only program that recieved the highest rating (++) for searching and image editing. Moreover, import/export, photo management and presentation were rated as (+). It is worth pointing out, that digikam could win this review just with its basic features, while the professional aspects of digikam 0.9.2 like 16bit/color, advanced raw handling, color management, geo-data handling or the new light table comparison tool were not taken into account.
This review is stimulation for the whole team which is in the process of porting the program to KDE4.

This week end, Marcel has fixed the libkdcraw library to port implementation as pure Qt4. Today I have processed all regression tests with Showfoto under KDE4 with sucess.



Next stage is to update dcraw program in libkdcraw core. Currently dcraw 8.60 is used and we need an upgrate to last 8.76 to support all recent camera RAW files.

So I arrived today in Glasgow, a little bit in advance for the Akademy, but there was two reasons for that, a less expensive ticket and that leave me sometime to visit the city. So here is a first glance:

Ok I am a bit unfair, but that factory stroked me the first time I saw it, I was looking at a nice view, some trees in the background, a brick house in the foreground, and then I walked further, and among the trees there was that factory. And somehow I like that picture, and it's possibly a good summary of Glasgow, a mix of traditionalism and industrialism.

Troy asked us in a general questionnaire about Krita if we had any good image made with Krita, which reminds me that I haven't taken the time to do any real playing with Krita since so long that I can't remember when. So, instead of doing more usefull work (like a summary for an article, cleaning my apartment, and walking outside in the sun). I took one of the last comic I bought (Orbital for the french among you, very good stuff, the background of the universe is a little bit cliché, but the story is quiet good) with really gorgeous drawing. In other word, really good stuff if I want a decent end result.

This is an answer to a comment from Bruce on my previous post, and the reason why I favor more XMP than RDF; at least at the moment. I will start by saying no decision have been taken on whether Krita should be "limited" to XMP (or RDF), or whether OpenRaster will be using XMP instead of RDF.

XMP is subset of RDF

So XMP is a subset of RDF and doesn't support all the features of RDF, and it's using an older version of RDF. I can understand that it makes it harder to use a RDF parser to manipulates XMP data, but from my point of view it's hardly a problem, as long as XMP allows to do everything I want to do in metadata in Krita. Then, I would add that supporting XMP is important because it's quiet well established in the graphic world.

Images are not pixels alone, they include metadata. Whether they are automatically generated by a system, for instance every digital camera saves information about the condition under which a picture has been taken, some other metadata are created by the user, including, for instance, a description of the content of the image so that it is then easy to find it again in a search engine (think about Strigi or/and Nepomuk).

It might sounds like I am telling banalities, but today one of my fellow Krita developer asked me what I was doing those days, and then after I answered that I was, among other things, working on KisMetaData, he was a little bit puzzled by what the use case could be, the second thing is that metadata in Krita has always been less than suboptimal, we were more or less trying our best to not lose them, but even at that we were failing (for instance IPTC tags in Jpeg, and most metadata information in PNG or TIFF, sometimes because of lack of real standardization and/or lack of support in the files libraries). And an other problem of metadata in 1.6 is that the engine was closely related to Exif, even if it was extensible beyond what Exif supports.

Dear digiKam users,the digiKam team is happy to announce a new release of the
advanced digital photo management application for linux.In addition to various bug-fixes and improvements,
several new features have been added. Some important improvements/changes are:

• a light-table to quickly compare similar images side by side
• Thumbnail size in the album view can be adjusted continuously, details.
• Image Editor: reorganized menu structure
• Image Editor: new pan tool
• Image Editor: new Sharpness Editor (replacing Unsharp Mask, Refocus, Sharpen)