View source for Krita/Metadata

= Metadata specifications =
== metadata specification ==
* [http://www.exif.org/ exif]
* [http://www.iptc.org/IIM/ iptc]
* [http://www.adobe.com/devnet/xmp/ xmp]
* [http://dublincore.org/ dublin core]

== libraries ==
* [http://libexif.sourceforge.net/ libexif] currently in use by krita
* [http://www.exiv2.org/  libexiv] currently in use by digikam and libkexiv
* [http://www.adobe.com/devnet/xmp/ 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 =
[http://nepomuk.semanticdesktop.org/xwiki/ Nepomuk] is a European project on The Social Semantic Desktop, and there is an implementation of the idea for KDE4 : [http://nepomuk.semanticdesktop.org/xwiki/bin/view/Main1/Nepomuk-Kde 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&amp;)"
                propertyName = "text" />
    <EntryEditor editorName = "editPublisher"
                schemaUri = "http://purl.org/dc/elements/1.1/"
                entryName = "publisher"
                editorSignal = "textEdited(const QString&amp;)"
                propertyName = "text" />
    <EntryEditor editorName = "editRights"
                schemaUri = "http://purl.org/dc/elements/1.1/"
                entryName = "rights"
                editorSignal = "textEdited(const QString&amp;)"
                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&amp;)"
                propertyName = "text" />
    <EntryEditor editorName = "editDescription"
                schemaUri = "http://purl.org/dc/elements/1.1/"
                entryName = "description"
                editorSignal = "textChanged()"
                propertyName = "plainText" />
 </MetaDataEditor>

=== Categories ===
Metadata should be split in various category for editing and display.

Common categories:

* description
** title <=> dc:title
** shorttitle <=> xmp:Nickname
** rating <=> xmp:Rating
** author <=> dc:creator
** contributors <=> dc:contributor
** description <=> dc:description
** source (as work use as derivative) <=> dc:source
** type of the work <=> dc:type ("Picture", "Watercolor", ...)

* rights management
** licence/rights <=> dc:rights or xmpRights:UsageTerms and cc::licence (for creative common licences)
** URL to the licence file <=> xmpRights:WebStatement
** certificate <=> xmpRights:Certificate
** owner <=> xmpRights:owner

* dates <=> dc:date
** original create date <=> dc:createdate

* history (read only) <=> xmpMM:History (does it belongs here ? and if it does read only)

* Media Management
** only display or also edit ? Krita isn't really intended for Media Management

* internationalization
** langues <=> dc:language

Optional categories:
* raw metadata (see XMP spec for a full list)
* photography metadata (comes from exif)
* location
** GPS
** Country/City/Street... (address of where the data is associated, it's defined in the photoshop namespace, I don't see an)

== 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" ?

= Other links =

* [http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html XMP tag names, including those not explained in the XMP specification]