Exiv2

For any image "test.jpg" that contains XMP metadata, the following sequence of commands will corrupt the XMP:

exiv2 -eX test.jpg
exiv2 -iX test.jpg

This happens with all image formats in exiv2-trunk as well as exiv2-0.21.1, and older versions. The problem is that these commands make different assumptions about the exact file format of the XMP sidecar file "test.xmp".

The first command "exiv2 -eX" reads the XMP metadata and modifies it before writing to "test.xmp". That is, it removes the beginning and trailing processing instructions, and prepends an processing instruction instead. (It also adds metadata from IPTC to XMP, but this seems to be irrelevant for this issue.)

The second command "exiv2 -iX", however, embeds the "test.xmp" file as is, without restoring the processing instructions. Thus, the "test.jpg" will contain invalid XMP metadata.

In summary, "exiv2 -iX" expects "test.xmp" to be identical to the XMP block in the image file:

<?xpacket begin=...?>
<x:xmpmeta ...>
  ...
</x:xmpmeta>
<?xpacket end="w"?>

while "exiv2 -eX" produces a slightly modified format:

<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta ...>
  ...
</x:xmpmeta>

Shouldn't both commands agree on one file format? This would avoid unpleasant surprises.

Note that the corrupted file is usually still readable with Exiv2, but technically incorrect because of the missing processing instructions. This may lead to problems with other tools, as well as problems with the upcoming EPS support, which will depend on valid processing instructions as specified in the XMP spec.

Currently, the only workaround is to embed the XMP metadata via "exiv2 -ix" instead of "exiv2 -iX". However, it would be much better if the produced XMP sidecar file would be directly usable by "exiv2 -iX".