Feature #1154

Read XMP and IPTC data from Exif Data in JPEGs

Added by Robin Mills almost 6 years ago. Updated over 5 years ago.

Target version:
Start date:
15 Jan 2016
Due date:
% Done:


Estimated time:


This has been extensively discussed in #1081

The XML/Embedding Specification is quite explicit about how XMP (and IPTC) is to be embedded in a JPEG.
Page 75 of XMPSpecificationPart3.pdf states:

4.3.1 Metadata storage in JPEG files
JPEG files, including Exif JPEG, use a mixture of native marker segments, TIFF tags, and Photoshop image resources.

Metadata can be found in 3 APPn marker segments:

Table 47 — APPn marker segments containing XMP metadata
Marker Signature, including NULLs Usage
APP1 "Exif\0\0” TIFF and Exif (2 NULLs)
APP1 "\0” XMP
APP13 "Photoshop 3.0\0” Photoshop image resources

The TIFF in the Exif APP1 marker segment should not contain tag 700 (XMP), tag 33723 (IPTC), or tag 34377 (Photoshop image resources). There should be only one copy of the IPTC in a JPEG file, in Photoshop image resource 1028 (ignoring the possible Mac OS ANPA 10000 resource).

RawTherappee has a bug in its metadata handling code. The conversion CR2 to JPEG exhibits this fault and is extensively analysed in #1081. Test files have been added to testdata/trunk/

Our current code (through v0.26) correctly ignores the Exif encoded XMP and IPTC data and issues a warning.

Alan thinks that we should forgive this error and process the file with/without warning. I am very reluctant to do this - although I believe it can be implemented within the -pR code in a couple of hours. I think exiftool respects this data. I'd like input from other team members before adding this to our code. I'd also like to see RawTherappee address this issue and get there code to implement the specification correctly.

Related issues

Related to Exiv2 - Bug #1081: Read XMP values from CR2 raw file when stored in XMLPacketClosed15 May 2015


Associated revisions

Revision 4185 (diff)
Added by Robin Mills almost 6 years ago

#1154 Test Files



Updated by Robin Mills almost 6 years ago

  • Tracker changed from Bug to Feature

Updated by Eric Mesa almost 6 years ago

Thank you for opening the feature request. It'd been almost a year since I put the bug in so I'd forgotten that, yes, RawTherapee was the guilty party. I also see that you've commented in their github bug report at

Thanks again!


Updated by Robin Mills almost 6 years ago

You're welcome, Eric. The original issue (#1081) was reported when I was away from the project dealing with another part of my life. Alan did a very good job in the analysis. And he's the one who realised "there's no bug here, this is a feature request". So Alan's the hero of #1081.

I'm a retired Adobe Engineer and that explains my reluctance to add code to exiv2 to ignore RawTherapee's spec violation.


Updated by Alan Pater over 5 years ago

My reasoning for being tolerant of data errors is that exiv2 is not a police force with the duty to enforce standards. Exiv2 exists to help users get at their metadata, whether it complies with the specs or not.

At least that is my interpretation and/or desire of the exiv2 mission.


Updated by Robin Mills over 5 years ago

That's a very convincing argument, Alan. readMetadata() could forgive this error and writeMetadata() could rectify it. Something to think about when we get round to working on this issue.

Also available in: Atom PDF