[CREATE] OpenRaster metadata

[Cyrille Berger Skott]

On Tuesday 19 October 2010, Luka Čehovin wrote:
> > As far as I remember, the goal was to be a bit more generic than that.
> > Like allowing different type of metadata.
> 
> What would be the benefit of that? Is XMP not powerful enough? Because
> this would only mean supporting more options ... therefore more work.
> Why not simply stick to one standard? Or do you mean something else
> with "different types of metadata"?
No I meant exactly that.

There are several reasons:
1) not all values of EXIF can be converted to XMP, mainly the content of 
makernotes, in Krita we save the makernotes as a blob inside the XMP, but 
several people have expressed, in the past, reservations about the ideas
2) and more important, it is future proof, you have to consider that XMP is 
currently a proprietary format, as long as Adobe develop it in a way that is 
acceptable and sufficient for our purposes, it remains ok, but who knows what 
happen in the future.

So I would suggest to be more generic, but to only allows XMP for the moment. 
So that we are not tied to it.

> > Well currently Krita saves the XMP metadata (and IPTC/Exiv as well...)
> > inside the PNG files.
> 
> Hm ... whats the rationale behind that? Why cannot we settle on one
> place to store metadata and one format to do it? Well of course that
> can also mean storing it in PNGs but I always thought that PNG is just
> a nice raster container in ORA and nothing more.

Several reasons:
1) Ora does not have any other way to store XMP yet, and PNG has
2) Krita uses the same code to saves PNG to files or to ORA, and by default 
always saves the metadata
3) it might no be such a bad idea. Remember that ORA are essentially zip 
files, so one can do "unzip myfile.ora" and get the PNGs with its metadata

Currently what is missing for krita is to save the XMP for the image itself 
(but if I remember correctly we don't yet have a metadata storage for the 
image, only for layers, so that might explain it :) ).

> > Yes it is complicated, but to be honest, the alternative is "pure" RDF
> > which is even more complicated. And if you want to achieve flexibility,
> > you need something complicated :)
> 
> Well as long as I do not have to parse the original storage format I
> am happy ... however I would still like to provide a nice interface
> for metadata in libora and for that I have to understand the
> organization ... I have to print some Adobe documents regarding XMP I
> guess :)

I would simply read the spec from Adobe. As for the API itself, you might want 
to think about what kind of usuage.

-- 
Cyrille Berger Skott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/create/attachments/20101019/89352cb3/attachment.html>