Feature #1154

Read XMP and IPTC data from Exif Data in JPEGs

Added by Robin Mills over 1 year ago. Updated over 1 year ago.

Status:NewStart date:15 Jan 2016
Priority:NormalDue date:
Assignee:-% Done:


Target version:1.0


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 "http://ns.adobe.com/xap/1.0/\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 XMLPacket Closed 15 May 2015

Associated revisions

Revision 4185
Added by Robin Mills over 1 year ago

#1154 Test Files


#1 Updated by Robin Mills over 1 year ago

  • Tracker changed from Bug to Feature

#2 Updated by Eric Mesa over 1 year 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 https://github.com/Beep6581/RawTherapee/issues/2307

Thanks again!

#3 Updated by Robin Mills over 1 year 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.

#4 Updated by Alan Pater over 1 year 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.

#5 Updated by Robin Mills over 1 year 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

Redmine Appliance - Powered by TurnKey Linux