Home > Krita, Open Source > Krita and Metadata

Krita and Metadata

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.

And thanks to the recent release of XMP under BSD by Adobe, the possibility to use XMP in an open source application has become a near future reality. So I recently rewrote the metadata engine of Krita to more or less follow the capabilities of XMP.

And I also worked on a metadata editor. The goal was to have something extensible and customizable (like shown in Step 4 of Adobe’s XMP presentation), so this is done by using one possibility of Qt : load ui files created by the Designer at run time without the need to build it. Associated with an XML file which associates tags to widget of the ui file, and you have what I call “a metadata editor skin”.

So currently, the new metadata framework in Krita goes beyond what was offered in the 1.x series, as it supports Exif and IPTC in Jpeg, it comes with an editor, and is a great base for the future.

A lot of work still need to be done, for instance to save and load metadata in other fileformat (PNG, TIFF, OpenEXR) and also finally saving and loading to XMP (but for that I intend to wait a little bit, as no solution is mature enough for now and next Krita release is still far away). And in the editor, I am a little bit annoyed by how some of the Exif value are displayed, like for instance in the above screenshot for the “Max aperture” tag which should appears as “f / 2.8” and not “280 / 100”. And it’s currently unable to edit list of tags, like a list of authors. Currently, metadata is associated to a layer, and it raises two questions whether image should also have their metadata (and if for instance the author field should be automatically edited when adding a new layer with an author metadata tag) and their is also the problem of merging two layers, what should happen to the metadata tags ?

  1. madpuppy
    21 June, 2007 at 23:33

    work on Krita, I am impressed with the quality of the program as a whole and prefer the more sane layout in the UI over something like the Gimp, not saying the Gimp is a superior or inferior app. just that I perfer the layout to Krita more. looking forward to checking out the fruits of your labor.

  2. prokoudine
    22 June, 2007 at 01:09

    So, did you actually use part of Adobe’s SDK?

  3. Cyrille Berger
    22 June, 2007 at 06:33

    Just to correct a little misunderstanding, the saving and loading to XMP file isn’t done yet. But Krita won’t use directly the Adobe SDK, especially because there are compilation problem on linux that I leave to other to fix 🙂 For now the only real solution to save/load XMP on linux is to use Exempi, but I have talk with Gilles Caulier who told me that Exiv2 (that Krita allready use for Exif and IPTC) was very likely to get XMP support soon, which has the advantage for me (in comparison to Exempi) to limit the number of dependency of Krita and also that the XMP API will be similar to the Exif/IPTC one, which is a big advantage, on the other hand it is not yet available, but as I have no hurry, I am ready to wait.

  4. Bruce
    22 June, 2007 at 12:40

    I’m a little bothered to be seeing the free software world uncritically embracing XMP. Just to be clear, the XMP metadata model and syntax is a subset of RDF as it existed around 2000. So while XMP is valid RDF, a whole lot of RDF is not valid XMP. In short, Adobe (the sole controller and maintainer of the XMP spec) severely constrains how you can model your data, and uses a lot of outdated RDF structures. By contrast, OpenDocument will soon be getting similar RDF-based metadata support that does not put such restrictions on the RDF. That said, because we will not put any restrictions on what kind of RDF you may use, XMP will also be allowed.I just wish we could get Adobe to open up the XMP spec; donate it, for example, to the W3C and have their semantic web group bring it up to contemporary standards.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: