<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans Mono'; font-size:9pt; font-weight:400; font-style:normal;"> 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</body></html>