Metadata specifications

metadata specification

libraries

libexif currently in use by krita
libexiv currently in use by digikam and libkexiv
xmptoolkit xmptoolkit from Adobe recently released as bsd

Current status of Metadata in Krita

Krita only support exif throught an unextensible framework which maps exif data to an internal representation.

Metadata, Layers and Image

Currently, metadata are associated with each layers, and they are removed when merging two layers. And images (in fact KisDocs) are associated with the limited KoDocumentInfo of KOffice2.

Two things for the future:

images should have their own metadata
merging two layers don't need to erase all metadata, merging should be made possible

Merging mechanism

A lot of the merging can be done automatically : authors lists, etc... licence as well, for instance merging of a GPL document with LGPL gives a GPL licence (GPL and LGPL are bad licences for images but that those I know the better ;) ), camera information can also easily be kept if the merged pictures come from the same camera.

But some things can't be automerged, and user input is required, for instance if nothing is known about licences, or what to do with picture information (like exposure) ?

Merging strategy might be different in function of the type of metadata.

Different strategies:

addition personal information (like list of authors)
only keep identical metadata
priority of one set over the other one

Conflicts in right management

Using the licence tag in right management, check can be done if importing an external image into the current document isn't violating someone's copyright.

Metadata and Nepomuk

Nepomuk is a European project on The Social Semantic Desktop, and there is an implementation of the idea for KDE4 : nepomuk-kde. It's mostly about finding and creating association between metadata to link two different ressources together, here are a few examples of what could be done with Nepomuk and images:

<picture A> <depicts> <person B> where <person B> is related to a contact resource in the addressbook
<pictureA> <is located at> <gps coordinate> and then I can get the name of the location, country and so on from a database
<pictureB> <depcits> <an old greek temple> and then I can find other images of greek temples (usefull when doing a photomontage)

Metadata Framework in Krita2

Krita needs to be able to load and write from the various specifications, which means the future implementation need to be independent of any specification. But as OpenRaster is likely to use XMP for MetaData and it's also the more flexible and wide, the API will be designed to match XMP.

Metadata

It's composed of:

a name
a value
a property qualifiers, they add informations to the metadata (example taken from XMP spec: an author field is an array of author, and for each author) and (only simple values are allowed in XMP)

Types of values

XMP defines the following types :

simple types (string, boolean, real numbers, integers, choice (==enums) )
structures contains various field with different values types
arrays (it's basically a structure whose fields name are integers) either unordered, ordered or alternative (usefull for internationalization, and of course a property qualifiers is associated with each entry and the language)
binary data, some exif information are stored as binary junk, some of them have been reversed engineered and could be stored normally, but that's no reason not to attempt to keep them all

Filters

Filters are some sort of "programs" applied to modify metadata, especially before saving.

Examples:

annonymizer, I have often receive the complaint that Krita was saving information about authors when exporting files, so the anonymizer filter would be charged to remove those information
to set date of the last modification, or the name of the software
to set the image information

Various classes

KisMetaDataStore it's basically a list of KisMetaDataCategory and call for saving/loading and holds a hash with the entries and a merging mechanism
KisMetaDataEntry a pair of key (identifiant and user visible name) and KisMetaDataValue
KisMetaDataValue a QVariant + a list of "property qualifiers" (which might as well be a KisMetaDataEntry)
KisMetaDataImportExportPlugin with two functions, one for saving and one for loading, this class will be in charge of exporting/importing metadata to the various specifications

UI

Requirements

UI should provide a list of categories, and for each categories a few fields to edit the values.

the UI needs to be easily extensible.

Solution

The metadata editor is a KPageDialog whose each page are called "skins" which can either be shipped by default with Krita or added in the ~/.kde/share/apps directory. Skins are composed of an UI file and an XML file which associates widgets (and its properties and signals) to metadata entries. Here is an example of the XML file:

<MetaDataEditor name="Dublin Core" uiFile="dublincore.ui" >
   <EntryEditor editorName = "editCreator"
               schemaUri = "http://purl.org/dc/elements/1.1/"
               entryName = "creator"
               editorSignal = "textEdited(const QString&)"
               propertyName = "text" />
   <EntryEditor editorName = "editPublisher"
               schemaUri = "http://purl.org/dc/elements/1.1/"
               entryName = "publisher"
               editorSignal = "textEdited(const QString&)"
               propertyName = "text" />
   <EntryEditor editorName = "editRights"
               schemaUri = "http://purl.org/dc/elements/1.1/"
               entryName = "rights"
               editorSignal = "textEdited(const QString&)"
               propertyName = "text" />
   <EntryEditor editorName = "editDate"
               schemaUri = "http://purl.org/dc/elements/1.1/"
               entryName = "date"
               editorSignal = "editingFinished()"
               propertyName = "date" />
   <EntryEditor editorName = "editTitle"
               schemaUri = "http://purl.org/dc/elements/1.1/"
               entryName = "title"
               editorSignal = "textEdited(const QString&)"
               propertyName = "text" />
   <EntryEditor editorName = "editDescription"
               schemaUri = "http://purl.org/dc/elements/1.1/"
               entryName = "description"
               editorSignal = "textChanged()"
               propertyName = "plainText" />
</MetaDataEditor>

Metadata templates

Avoid the user to reenter all his name, contact, copyright information, licence information, etc... He just create a template, and then can apply it easily to his images.

It's also usefull for someone who scan his pictures, with a template he can fill the missing exif tag for his camera.

Stuff to think about

what happen in case of conflicting tags ? Due to its extensibility, two metadata entries might define the same "property" and have conflicting value. For instance, I have noted at least three tags related to the licence of the file, what happen if one says "GPL", one "Commercial : pay 30$ per use" and the CC tag say : "Creative Commons Attribution 2.0" ?

Krita/Metadata

Metadata specifications