Skip to main content
Known Participant
May 2, 2015

P: Invalid XMP metadata written to exported JPEGs, tripping up reading software

  • May 2, 2015
  • 46 replies
  • 2004 views

Lightroom 6 often writes invalid XMP metadata in exported JPEGs, including for photos containing lots of brush strokes made with the adjustment brush. This trips up Google Photos, preventing it from showing any of the EXIF metadata. It may well trip up other software.

To reproduce:

1. Start with any image.

2. Use a small adjustment brush with Exposure = 100.

3. Make lots and lots of brush strokes (see the example pic below).

4. Export the image as a JPEG, including all metadata.

5. Load the image to Google Photos and observe that it doesn't show any EXIF metadata.

6. Delete all of the XMP develop settings with:

exiftool -xmp-crs:all= file.jpg

7. Upload that modified file to Google Photos and observe that it now shows the EXIF metadata.

Here's an example pic exported from step 4:

https://dl.dropboxusercontent.com/u/2...

If you extract the XMP metadata with:

exiftool -a -m -b -xmp file.jpg

you'll see that LR has recorded all of the develop settings twice, including all the brush strokes.

Worse, if you examine the file layout with:

exiftool -m -htmldump file.jpg > file.htm

you'll see that the APP1 Extended XMP segments recording the second copy of the develop settings have incorrect segment offsets, with the first segment of the duplicate settings having offset 0, and the following segments with offsets based on that. That's not allowed by the XMP standard, which requires all the segments to have linearly increasing offsets with no gaps. It's easy to imagine how this might trip up a program trying to read the metadata.

This topic has been closed for replies.

46 replies

Participating Frequently
August 1, 2015
Did a quick test. Looks like it's fixed. Thanks
Participating Frequently
August 1, 2015
Great, thanks John! I'll try it out once I get a chance.
johnrellis
Genius
July 31, 2015
This problem appears to be fixed in LR 6.1.1 / CC 2015.1.1.
Participating Frequently
July 24, 2015
Thank you Chris for your official acknowledgement. Hopefully we'll see this problem fixed in LR6.2.
Inspiring
July 24, 2015
If they can reproduce the problem, then they're also working to solve the problem.
ssprengel
Inspiring
July 24, 2015
The Adobe employee's exact phrase, above, is:

"I've found a way to reproduce the problem."
Participating Frequently
July 24, 2015
This bug is not a minor inconvenience but something that trips up pretty much everything outside of LR6, including our clients' software. If you're a photographer with little technical skill or not willing to fiddle with EXIFtools this is a show stopper.

All I was saying was that I see this issue as serious enough to warrant at least an acknowledgement ("yes it's a bug not feature") and confirmation this is worked on... or a "no sorry it's not getting fixed go elsewhere".

All we got in the past *three months* was "oh yes, the software does behave as you guys say it does". I expect more from a tool marketed as one for professionals who depend on it in their job.
ssprengel
Inspiring
July 24, 2015
On July 7 an Adobe employee said he could reproduce the problem.

That is as much feedback as you'll probably get until the next release.

It is not disrespectful to us customers if we aren't privy to Adobe's internal project management and bug tracking systems.
Participating Frequently
July 24, 2015
I totally agree. The silence from Adobe is "deafening".
Participating Frequently
July 24, 2015
"though I frankly find it unacceptable considering we're now essentially paying for something that fails to deliver a very basic functionality for photographers on the premiss that Adobe does it right, and everyone else should readjust"

Could not agree more. I see this plus silence on the issue (i.e. "yes this is a bug we're going to fix it in the next point release" or "sorry we are not fixing this stick to LR5") as both disrespectful of users.