The XMP sidecar file that digikam produces should not contain the XMP packet wrapper. In regard to the specification it should produce a "well formed XML file" including a XML header. You can see a similar bug report and discussion for darktable here: https://redmine.darktable.org/issues/8534 Michael Zabel
Both Application use Exiv2 in backgroud to generate sidecar. Report this problem as UPSTREAM bug to Exiv2 team. Gilles Caulier
(In reply to caulier.gilles from comment #1) > Both Application use Exiv2 in backgroud to generate sidecar. Report this > problem as UPSTREAM bug to Exiv2 team. > > Gilles Caulier This is not an Exiv2 bug. As I wrote some years ago in the mentioned darktable bug report (please see the provided link above) you can decide how to generate the xmp file using the flag Exiv2::XmpParser::omitPacketWrapper. Just use this flag if you want to write to a sidecar file and write a XML header first (please see the provided code example in the link). BTW, darktable fixed this 2 years ago. And if I remember right, digikam did it right in some former versions. Regards, Michael
Maik, What do you think about this old entry ? Why we need to generate xmp sidecar without XML packet description ? What the gain ? What's about the interoperability with other application ? Removing XML definition can reduce compatibility after all. For me this file must be resolved as WONT FIX... Gilles
(In reply to caulier.gilles from comment #3) > Maik, > > What do you think about this old entry ? Why we need to generate xmp sidecar > without XML packet description ? What the gain ? What's about the > interoperability with other application ? > > Removing XML definition can reduce compatibility after all. For me this file > must be resolved as WONT FIX... > > Gilles Gilles, please don't mix up XMP packet wrappers and XML headers. These are two different things. Unfortunately, the Exiv2 documentation for the flag omitPacketWrapper is wrong in this regard ('Omit the XML packet wrapper.'). This flag omits the XMP packet wrapper (there is no XML packet wrapper). A XMP packet wrapper is intended for embedding XMP data into binary files and starts with: <?xpacket begin= For XMP sidecar files you should omit this wrapper and write a XML header instead - before writing the XMP data: <?xml version="1.0" encoding="UTF-8"?> This XML header is missing in the current digiKam release. Michael
If I see that correctly, Exiv2 does not write the "<?xml version="1.0" encoding="UTF-8"?>" Header, but Darktable. The option Exiv2::XmpParser::omitPacketWrapper only prevents an XMP packet wrapper from being created, but only in the Exiv2::XmpParser::encode() function. And that's exactly the difference between digiKam and Darktable, we create an Exiv2::Image of the Exiv2::ImageType::xmp type ==> sidecar. We cannot set the Exiv2::XmpParser::omitPacketWrapper at all. Darktable uses Exiv2::XmpParser::encode() to copy the XMP metadata into a string and then write it to a file. I think our Xmp creation is the right way provided by Exiv2. Maik Maik
If I create a sidecar with "exiv2 -eX image.jpg", the format is identical to digiKam. In addition, we have to use an Exiv2::Image so that Exif and IPTC metadata can also be mapped to XMP via the internal Exiv2 conversion table. For me, the Darktable sidecar is an XML file to map the history of the image processing. Maik
Maik, that's not correct in my opinion. A XMP sidecar file should start with a XML header. If Exiv2 doesn't write this header that's IMHO a bug. Please have a look at the XMP specification from Adobe, Part 3, Storage in files: https://www.adobe.com/devnet/xmp.html On page 7 in section "External storage of metadata" you will find this topic: "Write the external file as a complete, well-formed XML document, including the leading XML declaration." Michael
You forget that we are writing an Exiv2::Image of type XMP. Yes, it's XML formatted, but the packet wrapper is one of it. The best test is to test it with ExifTool. ExifTool also writes a packet wrapper and not an XML header! <?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?> <x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 12.13'> <rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'> Maik
I know that ExifTool writes a packet wrapper for sidecar files. But for my understanding of the XMP specification this is not correct. I think the specification should be more relevant than the output of a certain application or library. But Darktable does it right in my opinion. Michael
Here is an example of a sidecar file in the Wikipedia: https://en.wikipedia.org/wiki/Extensible_Metadata_Platform Maik
I don't see an example of a sidecar file. I only see an example for embedded XMP data in a JPEG file ("This is an example XML document for serialized XMP metadata in a JPEG photo"). As I wrote before a packet wrapper must be used for serializing or embedding XMP data in binary files, but not for external sidecar files. Why you don't refer to the original specification from Adobe? Michael
I already wrote that we are using the API to save an Exiv2 "image" in XMP format. We cannot change this behavior, the way Darktable does it is not applicable to digiKam. The problem would have to be discussed again on the part of Exiv2 and ExifTool. I also found ExifTool's thread on this topic, Phil doesn't want to change it either at the moment. When searching for XMP files from Photoshop, I only found older files that also contain the paket wrapper. How Photoshop is currently handling it would have to be tested. From my side, this bug report is in the wrong place at digiKam. Maik
Hi Maik, For me this entry a nothing to do in the digiKam bugzilla. All this technical questions must be posted in Exiv2 and/or ExifTool bugzilla. As all work as expected in the viewpoint of interroperability with other photo management application. I close this file now. Gilles