Exiv2

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

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?

What do I think? Honestly? sidecar files are a bodge. I believe the purpose of XMP sidecar files is:

1. To hold metadata about files which cannot embed XML (e.g. BMP)
2. To make it easy to update metadata in large files without rewriting the whole file
3. 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.

I'm setting Target = 1.0 because it will be considered with #941 which has Target == 1.0.