GNOME Bugzilla – Bug 572424
Prefer xmp metadata over the other types (exif, iptc).
Last modified: 2009-06-05 12:35:17 UTC
Jpeg images can store embedded metadata in (at least) three different formats: exif, iptc and xmp. The exif metadata is typically written by the digital camera and records image taking conditions. Iptc data is usually used to describe the image content (descriptions, keywords, copyright, etc). But both type of metadata formats are slowly getting replaced by xmp metadata (which can hold both the legacy exif and iptc data). Because of that, I think gthumb should default to saving the metadata to xmp, and not one of the other formats. This would also increase compatibility with other (gnome) software, such as eog and f-spot. I'm not really sure about f-spot, but eog will only display xmp and exif, but not iptc. So at the moment (some) metadata stored by one application does not show up in another one. Gthumb tries to obtain metadata values from all similar keys, which is of course a very good thing. But the key used for writing is kind of picked random. Therefore I propose to assign the highest priority to the Dublic Core xmp namespace (Xmp.dc.*), then XMP-IPTC , and so on. At least for the keywords, comments, etc. BTW, it might also be worth changing the xml based comment files to xmp sidecar files. Editing metadata will remain non-destructive, but the modifications will also be usable by other xmp sidecare aware applications.
Created attachment 129069 [details] [review] Prefer Xmp.dc.subject for keywords (improving compatibility with eog)
OK by me. Committed. Is there is a better location tag too? The sidecar idea is a really good one that had not occurred to me before. I can't remember if the code supports sidecar writing currently, but it shouldn't be hard to add. How exactly would you decide when to write in-file metadata versus sidecar data? - Mike
For the location tag, I don't think there is a better one (currently Xmp.iptc.Location). For the comment, I would use Xmp.dc.description (currently Exif.Photo.UserComment) to be consistent. For the date, I'm not really sure what would be the best one. There is a Xmp.dc.data key, but I'm not really sure that's the one we want to use. Personally, I interested in the exif date (as stored by my camera), and other than correcting an incorrectly set clock, I don't have any use for modifying its value. But the other ones are often use for organizing images. And cross application compatibility is of course a huge win there. All the other ones can stay in the Exif.Photo.* namespace. Almost all camera's (and applications) are still reading (and writing) photographic info to the exif metadata. I'm not aware of any cameras that does support writing xmp.exif.* metadata.
Created attachment 129073 [details] [review] Prefer Xmp.dc.description for comments.
Jef, I like the idea of preferring Xmp.dc.description, but if you apply your patch and add a comment, 'lang = "x-default"' gets prefixed to any comment. Some additional filtering is needed, I guess. - Mike
I never noticed this problem because my comments were stored in the xml files only. I'm not really familiar with the exiv2 api, but I would be surprised if there was no way to ignore the language prefix.
Fixed in trunk.