Editing existing XMP properties in XMP sidecars does not work
|Status:||New||Start date:||14 Jun 2009|
XMP sidecar converts xmp to exif and iptc on read and back on write. Changes done
directly in XMP are overwritten.
For example calling this on a file that already has Xmp.tiff.Orientation=1 has no effect:
exiv2 -M"set Xmp.tiff.Orientation 4" test.xmp
This is related to bug #601
#1 Updated by Alan Pater over 3 years ago
- Status changed from New to Assigned
- Assignee set to Alan Pater
- Target version set to 0.25
I am wondering if we really have a bug here. My testing indicates that if we set the orientation via the exif tag, rather then the xmp property, it works. The MWG guidelines indicate that this field is set through the exif tag, not the xmp property.
Working set of commands:
$ exiv2 -M"set Exif.Image.Orientation 4" test.xmp $ exiv2 -iX test.jpg $ exiv2 -g Orientation test.jpg Exif.Image.Orientation Short 1 bottom, left Xmp.tiff.Orientation XmpText 1 bottom, left
#3 Updated by Alan Pater over 3 years ago
- Assignee changed from Alan Pater to Robin Mills
Right. What happens is that IF the XMP property in question is one of those mapped in convert.cpp then it can't be modified directly in the XMP sidecar. Instead one needs to modify the mapped EXIF or IPTC tag.
The mapped XMP property can be set initially in the sidecar if it does not yet exist. But once it does exist there, the EXIF or IPTC tags take precedence.
For properties which are not mapped in the conversion tables, modifying them in the XMP sidecar works. For example:
$ exiv2 -M"set Xmp.dc.identifier bug1717" test.xmp $ exiv2 -g identifier test.xmp Xmp.dc.identifier XmpText 6 bug1717 $ exiv2 -M"set Xmp.dc.identifier bug639" test.xmp $ exiv2 -g identifier test.xmp Xmp.dc.identifier XmpText 6 bug639
Robin, what do you think? What is there in convert.cpp that blocks modifying these properties?
#4 Updated by Robin Mills over 3 years ago
- Assignee changed from Robin Mills to Andreas Huggel
- Target version changed from 0.25 to 0.26
What do I think? Honestly? sidecar files are a bodge. I believe the purpose of XMP sidecar files is:
- To hold metadata about files which cannot embed XML (e.g. BMP)
- To make it easy to update metadata in large files without rewriting the whole file
- To enable other tools to index and search resources.
And these are very desirable features.
The problem however is that there is data duplicated between the sidecar and the resource - resolution, color space, pixel format, orientation, width, height and other stuff. And of course the XMP can be out of sync when embedded. However it's doubly troublesome in an external sidecar file.
I feel we should do nothing further about this and focus on releasing v0.25. I hope that v0.26 will link Adobe's XMPsdk as an external library (#941). So, I've assigned this one to Andreas to consider as part of #941. I've set the target version to 0.26.