Since Roman has offered to improve the metadata handling in GIMP, Svenasked me to document what my plans were for the metadata editor and theJPEG plug-in. Well, these plans are best summarized in the mail that Isent last year: http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/018992.html http://article.gmane.org/gmane.comp.video.gimp.devel/12503/ Basically, every single line of that message is still relevant today.So I will not quote the whole message again, but I encourage those whoare interested in metadata to read it entirely. This follow-up message may also be interesting, regarding which Exiftags should be updated automatically by GIMP and why GIMP should neverask the user if an image should be rotated automatically or not: http://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/019100.html http://article.gmane.org/gmane.comp.video.gimp.devel/12610/ That's about it for the plans. You should stop reading now if youare not interested in the details. :-) ---------- scary details below this line ---------- Maybe a few points from the first message (2.6 roadmap) should beclarified a bit. In that message, I wrote:> + migrate some parts of the metadata core to a library that can be> used by the main app. as well as some plug-ins Currently, the metadata is stored in an XMP packet inside a GIMPparasite attached to the image. While XMP is a good format forstorage in files, it is not ideal for manipulation (updates andqueries). It would be better it the metadata tree could remain inmemory while the image is open, instead of being converted to/from XMPall the time. Also, by having this tree attached to the image andaccessible directly by the core for updates and queries, it would bepossible to have the metadata updated in real-time whenever the imageis modified by some tools or plug-ins. This would allow some of themetadata to be displayed in the image info window, or maybe in thestatus bar of the image (more and more programs are doing that). Currently, the metadata tree is only available inside the metadataeditor, which is implemented as a plug-in. This results in severalround-trips via the PDB whenever something must be updated. Forexample, assuming that Exif would now be handled correctly, thecurrent implementation would lead to the following scenario when aJPEG image is saved: - the JPEG plug-in calls "plug-in-metadata-set" to update some metadata- this is passed to GIMP- GIMP starts the metadata editor plug-in- the metadata editor asks GIMP to get the parasite attached to the image- the parasite (XMP) is parsed and stored in a tree- the tree is updated according to what was requested- the tree is encoded into a parasite (XMP)- the metadata editor asks GIMP to attach the parasite to the image, then it exits- (if there is some window currently displaying the metadata associated with that image, it is *not* updated)- the JPEG plug-in is informed that the operation was successful- the JPEG plug-in calls "plug-in-metadata-encode-exif" in order to get an Exif block from the updated metadata- this is passed to GIMP- GIMP starts the metadata editor plug-in again- the metadata editor asks GIMP to get the parasite attached to the image- the parasite (XMP) is parsed and stored in a tree- the metadata editor updates some metadata that must be updated when an image is saved- the updated tree is encoded into a parasite (XMP)- the metadata editor asks GIMP to attach the updated parasite- (if there is some window currently displaying the metadata associated with that image, it is *not* updated)- the contents of the tree are encoded in Exif- the metadata editor returns an array with the Exif block and exits- GIMP returns the array to the JPEG plug-in- the JPEG plug-in can now save the file with the Exif block, then exit- (if there is some window currently displaying the metadata associated with that image, the user must remember to refresh the view) And here is what would happen if the metadata tree could be managed bythe GIMP core, but we still assume that the conversion to/from Exif isdone by an external plug-in: - the JPEG plug-in calls "gimp-metadata-set" to update some metadata- this is passed to GIMP, which updates the metadata attached to the image- (if there is some window currently displaying the metadata associated with that image, it *will be* updated)- the JPEG plug-in is informed that the operation was successful- the JPEG plug-in calls "gimp-metadata-encode-exif" in order to get an Exif block from the updated metadata- GIMP updates some metadata that must be updated when an image is saved- (if there is some window currently displaying the metadata associated with that image, it *will be* updated)- GIMP starts the metadata editor plug-in- the metadata editor makes several calls to "gimp-metadata-get" in order to retrieve the parts of the metadata that are relevant for Exif- GIMP returns the requested data (from its internal tree)- the metadata editor encodes that information in an Exif block- the metadata editor returns an array with the Exif block and exits- GIMP returns the array to the JPEG plug-in- the JPEG plug-in can now save the file with the Exif block, then exit Furthermore, here is what would happen if the metadata tree could bemanaged by the GIMP core and some common metadata operations (such asthe conversion to/from Exif) would be in a "libgimp-metadata" librarylinked directly with the file plug-ins that need it: - the JPEG plug-in calls "gimp-metadata-set" to update some metadata- this is passed to GIMP, which updates the metadata attached to the image- (if there is some window currently displaying the metadata associated with that image, it *will be* updated)- the JPEG plug-in is informed that the operation was successful- the JPEG plug-in calls "gimp-update-metadata-for-save" in order tell GIMP that the image is about to be saved- GIMP updates some metadata that must be updated when an image is saved- (if there is some window currently displaying the metadata associated with that image, it *will be* updated)- the JPEG plug-in makes several calls to "gimp-metadata-get" in order to retrieve the parts of the updated metadata that are relevant for Exif- the JPEG plug-in calls the library functions for encoding that metadata into an Exif block (the previous step could even be performed by the library functions so that the JPEG plug-in would not have to care).- the JPEG plug-in can now save the file with the Exif block, then exit Sorry for the long details, but using an example like this is probablythe best way to explain why it would make sense to have some parts ofthe metadata handling performed by a library, and why it would bebetter if the metadata tree could be managed by the GIMP core insteadof being constantly converted to/from XMP and stored in a parasite. In my message from last year, I also wrote:> + convert EXIF to XMP> + convert XMP to EXIF The initial goal of the code that I started writing (and never finished)for the conversion to/from Exif was to get rid of the dependency onlibexif. That library had caused several severe stability problems inthe past and most developers (including myself) wanted to replace it bysome code that was more stable. However, the known bugs in libexif have now been fixed (some updates havenot been released yet, but that's another issue) and after studying howsome people (and the programs they use) are using the Exif data, I am nowconvinced that preserving the Exif MakerNotes is very important. This isthe trickiest part of Exif and this is where most of the time was spentin libexif or other libraries (exiv2, etc.). Since parsing and updatingMakerNotes is a difficult task, I think that it is better to leave thatjob to libexif instead of re-inventing the wheel. So contrary to what Ioriginally planned, I think that the code for converting to/from Exifshould be based on that library. This will also make our code smallerand easier to maintain. -Raphaël_______________________________________________Gimp-developer mailing listGimp-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
