Feature #1154
Read XMP and IPTC data from Exif Data in JPEGs
0%
Description
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).
http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart3.pdf
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
Associated revisions
History
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 https://github.com/Beep6581/RawTherapee/issues/2307
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.
#1154 Test Files