115 Messages
•
1.6K Points
Sat, May 2, 2015 4:52 AM
Solved
Lightroom 6: Invalid XMP metadata written to exported JPEGs, tripping up reading software
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.
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.
Problems
•
Updated
5 years ago
6
26
Helpful Widget
How can we improve?
Tags
exif
Responses
John_R_Ellis
Champion
•
5.5K Messages
•
97.2K Points
6 years ago
I just did a quick test, and LR 6's export does preserve fractional seconds in capture time. Note that the EXIF and XMP capture-time fields can store fractional seconds, but IPTC cannot. So when you export a photo whose capture time has fractional seconds, LR will properly set EXIF:DateTimeOriginal, EXIF:SubSecOriginal, and XMP:DateCreated to have the fractional seconds. But it will set IPTC:TimeCreated to omit the fractional seconds.
0
0
frank_chan_7216538
47 Messages
•
640 Points
6 years ago
Never-the-less, once I get a chance, I think I have a test in mind to verify the sequencing in Android's Gallery Slideshow. I'll upgrade one of my smaller LR 5.7.1 catalogs to LR 6. Run an LR 6 export with the Limit File Size workaround. Then see if Android's Gallery Slideshow sequences the same sub-second photos the same way as photos exported with LR 5.7.1.. I hope to do this test next week, maybe Thursday or Friday. I'll get back to you with my result.
0
0
frank_chan_7216538
47 Messages
•
640 Points
6 years ago
0
0
John_R_Ellis
Champion
•
5.5K Messages
•
97.2K Points
6 years ago
0
0
frank_chan_7216538
47 Messages
•
640 Points
6 years ago
But instead of me spending a lot of time trying to find the exact cause for my Android Gallery Slideshow app sequencing issue and going crazy doing it, I found a better Android app to do my customer slideshows. So I changed my workflow to use the Android QuickPic Gallery app. (I really didn't want to change my workflow, but all-in-all this change is the best option for my situation.) This app allows me to easily select, in a number of ways within a folder, a slideshow's sequencing order and the by "file name" is the selection I'm using. (You would think that the Android Gallery app would have a by file name order option, but it doesn't.). And since my file names are already named by yyyy-mm-dd-hh-mm-ss and trailing sub-second suffix if needed for uniqueness, I'm "home free" and in control of the slideshow's order no matter when this LR6 XMP issue is fixed.
Never-the-less, hope Adobe fixes this LR6 XMP issue for you soon. Good Luck!
1
0
david_franzen
111 Messages
•
2.3K Points
6 years ago
Can you try again to reproduce your original issue: no Exif appearing in Google Photos? I tried to today with your "example from step 4" photo today and it displays the basic Exif information. Perhaps Google Photos has fixed support for extended XMP on their end.
2
0
david_franzen
111 Messages
•
2.3K Points
6 years ago
I have not been able to reproduce the problem of the XMP repeated twice. With the step 4 JPEG I do see that the JPEG has several extended JPEG blocks. It might help me if you could post a raw, DNG or JPEG file from step 3 in your original steps, but without those adjustments applied to the image yet and "baked into" the pixels. Then I could try exporting that file to see if the export produces a JPEG with multiple copies if the XMP. So far I've not seen that happen, but if you have a file that, when exported, consistently produces the result when doing an export, that would help.
Thanks,
David
3
0
david_hovi
1 Message
•
60 Points
5 years ago
7
0
John_R_Ellis
Champion
•
5.5K Messages
•
97.2K Points
5 years ago
0
frank_chan_7216538
47 Messages
•
640 Points
5 years ago
0
0
frank_chan_7216538
47 Messages
•
640 Points
5 years ago
0