Bug #8534

XMP sidecar shouldn't contain the xpacket

Added by hfiguiere - almost 9 years ago. Updated about 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git development version
hardware architecture:


XMP sidecar should contain the xpacket (that part that starts with

Related issues

Related to darktable - Bug #8403: XMP sidecar: xpacket/xml format, filename, overwritingDuplicate

Associated revisions

Revision acd83186 (diff)
Added by Tobias Ellinghaus about 5 years ago

Fix #8534: Don't add xpacket to sidecar files

Revision 7c1d8905 (diff)
Added by Tobias Ellinghaus about 5 years ago

Fix #8534: Don't add xpacket to sidecar files

(cherry picked from commit acd831861253aaf8ffda9aa9b219aba6781f13da)


#1 Updated by Tobias Ellinghaus almost 9 years ago

If I understand the XMP specifications correctly writing the xpacket is at least not wrong. Why do you want to not have it?

#2 Updated by hfiguiere - almost 9 years ago

Here is the short introduction of what the xpacket is in the XMP specification:

"The XMP packet wrapper can enable the use of embedded XMP by software that does not understand the format of the file. The packet wrapper is not the sole aspect of embedding XMP in a file. The entire XMP packet must still be placed in the file as an appropriate component of the file’s structure."

The XMP sidecar is not "embedding in a format". So the xpacket has no reason to be. That's not what the other app that conform to the standard do either.

#3 Updated by Tobias Ellinghaus almost 9 years ago

If google is to be trusted then that's not the case for all apps (at least a few years ago):

However, I have no opinion on that subject. Iff there are (important) applications choking on the xpacket and there are no (important) applications which need it, then we should remove it.

#4 Updated by hfiguiere - almost 9 years ago

Ligthroon, Aperture, Bridge, they all generate the XMP files without the xpacket.

#5 Updated by rjo - over 8 years ago

The xpacket is plain wrong. The blog post you cite is wrong. Bridge CS2 was wrong. Just read the spec. See also #8403.

The xmp spec (at least since 2005) mandates the xml declataion (i.e. ) for external metadata storage. The xpacket declaration and the xml declaration are mutually exclusive. The former is only used if the metadata is embedded in the file. Embedding is what xpacket is designed for. page 36

"Write the external file as a complete well-formed XML document, including the leading XML declaration."

#6 Updated by Simon Spannagel almost 8 years ago

  • Affected Version set to git development version
  • Status changed from New to Closed: upstream

Who does our XMP writing? It's exiv2 I guess.
So best would be to file a bug upstream.
Closing this as upstream problem.

#7 Updated by Tobias Ellinghaus almost 8 years ago

  • % Done changed from 0 to 20
  • Target version changed from --- to Future
  • Status changed from Closed: upstream to Triaged

We are not sure we use exiv2 correctly, so set to Triaged.

#8 Updated by Michael Zabel about 7 years ago

This issue is easy to fix with a small change in the xmp write function dt_exif_xmp_write in the file Just use the flag omitPacketWrapper and write the XML header first:

    // serialize the xmp data and output the xmp packet
    if (Exiv2::XmpParser::encode(xmpPacket, xmpData, Exiv2::XmpParser::useCompactFormat | Exiv2::XmpParser::omitPacketWrapper) != 0)
      throw Exiv2::Error(1, "[xmp_write] failed to serialize xmp data");
    std::ofstream fout(filename);
      fout << "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"; // write XML header
      fout << xmpPacket;
    return 0;

#9 Updated by Tobias Ellinghaus about 5 years ago

  • % Done changed from 20 to 100
  • Status changed from Triaged to Fixed

Also available in: Atom PDF

Go to top