Exiv2

Obviously it has changed the file contents - it removed the redundant xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" line. But it didn't update the Xmp.xmp.CreateDate value.

I've found I need to delete both Xmp.xmp.CreateDate and Exif.Photo.DateTimeDigitized before setting Xmp.xmp.CreateDate to achieve the desired result:

jim@brains:~$ exiv2 -v -M"del Xmp.xmp.CreateDate" -M"del Exif.Photo.DateTimeDigitized" -M"set Xmp.xmp.CreateDate XmpText 2017-06-07T12:00:00+01:00" test.xmp
File 1/1: test.xmp
Del Xmp.xmp.CreateDate
Del Exif.Photo.DateTimeDigitized
Set Xmp.xmp.CreateDate "2017-06-07T12:00:00+01:00" (XmpText)
jim@brains:~$ cat test.xmp

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:xmp="http://ns.adobe.com/xap/1.0/"
xmp:CreateDate="2017-06-07T13:24:34+02:00"/>
</rdf:RDF>
</x:xmpmeta>


Jim

What a curious matter. Exiv2 delegates almost everything concerning XMP to the Adobe XMPsdk which is embedded in libexiv2. At the moment, I'm working hard to enable different versions of Adobe's library to be used by exiv2. I'll build and try the 2013, 2014, 2016 versions and get back to you.

I'm planning to release Exiv2 v0.26.1 to include support for Adobe XMPsdk, Visual Studio 2017, C++11 and bug fixes. I hope to achieve RC1 this month and GM in December.

Robin

Jim

I've reproduced your issue with the 2016 version of Adobe XMPsdk.

1) Removing the photoshop namespace

I've hardly ever looked into the Adobe code, however I believe the XMP/xml from the file is stored by Adobe in an RDF model in memory. When we rewrite the metadata, the model is serialised into XMP/xml which Exiv2 stores in the file. As you are not using the photoshop namespace, XMPsdk has correctly omitted it from the rewritten XMP/xml file.

2) Not modifying xmp:CreateData

I suspect the Exiv2 convertor functions are causing this behaviour. Exiv2 reads the XMP from file and passes it to Adobe/XMPsdk. The "convertor" functions "invented" Exif.Photo.DateTimeDigitized. Before we ask Adobe to serialise the XMP, the "convertor" functions push that value back into the XMP and overwrite your modified data with the original value! When you explicitly delete Exif.Photo.DataTimeDigitized, the modified value of xmp.CreateDate is correctly serialised to output.

I didn't write Exiv2 and don't know the origin of the "convertor" functions, however I wish they could be uninvented as they have caused trouble such as #1122. I'd prefer Exiv2 to be "deterministic" and confine activity to solid data. The convertors have unintended side-effects such as this.

I have opened an Issue #1313 to track this matter. As you have a work-around, I don't feel urgency about fixing this. I don't want to break from my work on Exiv2 v0.26.1 to attend to this. If you feel this has higher priority, please update #1313. Future discussion about this should continue on #1313.

Robin,

I agree your number 1 is not a problem, it's desirable and expected behaviour. Sorry if my message suggested otherwise.

I agree with you about the convertor functions. In my opinion, MWG compliance is "program" logic, not "library" logic. One may wish to use libgexiv2 in a program written to interface to an old, non-MWG compliant, program (or data files).

I've found a workaround in my application program, so there is no urgency. Thanks for looking into this.

libgexiv2? I thought that was a wrapper to connect KDE and Gnome products to libexiv2. How does this fix the issue when the convertors are run by the library?

Your comment about the file being rewritten sounded like "well, I know you have rewritten my file". So I documented the reason. You and I have agreement that removing the namespace is not an issue. My focus was totally on the date which is the title you gave to this topic.

My Python application is using the libgexiv2 wrapper around libexiv2. The exiv2 command line tool uses the same library (confirmed by ldd). (In my comment I actually meant to write libexiv2 where I wrote libgexiv2 - I think the point stands though.)

As I understand it the convertors are part of the library. My program can read invented tags such as Exif.Photo.DateTimeDigitized from a pure XMP file.

Ah, right. I understand. I thought you were implying that libgexiv2 has special magic to deal with this.

The fix I figured out for #1122 involved inspecting and messing with metadata values. I wish this were not so. Exiv2 should have no knowledge of the meaning of metadata. It should be an engine to read/write/modify metadata. I'm glad you have a way to deal with this in your application.

Robin