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 ?

This entry was posted in Krita, Open Source and tagged , , , . Bookmark the permalink.

4 Responses to Krita and Metadata

  1. madpuppy says:

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

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

  3. Cyrille Berger says:

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

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>