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.
Posted 4 years ago
Good catch, I didn't notice the different GUIDs, thanks.
So this issue now falls into the same category as the other JPEG format issue: http://feedback.photoshop.com/photosh.... While technically conforming to the industry standard, the atypical layout of the XMP information, surely not intended by the developers, will cause LR's users significant practical problems:
1. Software like Google Photos/Picasa chokes on the XMP metadata and refuses to show any metadata at all. If Exiftool, the widely acknowledged authority on metadata, didn't properly handle LR's layout of XMP metadata, what's the likelihood of the typical mediocre software app handling it properly?
2. Duplicating the XMP-crs information twice can add a lot of bloat to files containing lots of adjustment-brush strokes. For example, it could take 1.5 MB or more to represent the strokes in a photo that's had a lot of brush work. This bug causes that to be duplicated, adding another 1.5 MB to the file size needlessly. This could be significant when publishing Web-quality photos. E.g. a high-quality 2400-wide JPEG might take 1 MB without metadata; with the XMP metadata stored properly, that would expand to 2.5 MB; with the XMP metadata stored by LR 6, it would expand a further 60% to 4 MB. Telling a user not to export any metadata isn't always an option, because she may well want EXIF camera info, keywords, captions etc. exported, and LR natively doesn't provide any mechanism for easily suppressing the develop settings only.
So this issue now falls into the same category as the other JPEG format issue: http://feedback.photoshop.com/photosh.... While technically conforming to the industry standard, the atypical layout of the XMP information, surely not intended by the developers, will cause LR's users significant practical problems:
1. Software like Google Photos/Picasa chokes on the XMP metadata and refuses to show any metadata at all. If Exiftool, the widely acknowledged authority on metadata, didn't properly handle LR's layout of XMP metadata, what's the likelihood of the typical mediocre software app handling it properly?
2. Duplicating the XMP-crs information twice can add a lot of bloat to files containing lots of adjustment-brush strokes. For example, it could take 1.5 MB or more to represent the strokes in a photo that's had a lot of brush work. This bug causes that to be duplicated, adding another 1.5 MB to the file size needlessly. This could be significant when publishing Web-quality photos. E.g. a high-quality 2400-wide JPEG might take 1 MB without metadata; with the XMP metadata stored properly, that would expand to 2.5 MB; with the XMP metadata stored by LR 6, it would expand a further 60% to 4 MB. Telling a user not to export any metadata isn't always an option, because she may well want EXIF camera info, keywords, captions etc. exported, and LR natively doesn't provide any mechanism for easily suppressing the develop settings only.
Yes, if you don't do step 6 (remove all the XMP-crs metadata), then you can't see any of the EXIF metadata in Google Photos.
David Franzen, Employee
Thanks -- I sort of misread your original post.
Thanks David for looking into this. And thanks again John for your work pin-pointing this situation. Hope this gets corrected soon.
Same problem! Thought I was going mad! My website relies on the EXIF data of uploaded images and it displays garbled up and useless information since the update to Lighroom 6! This needs to be fixed ASAP as it's a KEY feature for most Photographers to have accurate EXIF data in their images!
Some examples:
Camera Make (Manufacturer) : Empty (used to display NIKON CORPORATION)
Camera Model: CORPORATION (used to display NIKON D750)
Photographer: xx xx:xx:xx (used to display Photographer's name)
Copyright: shows Photographer's last name from field above (used to display camera copyright text)
Some examples:
Camera Make (Manufacturer) : Empty (used to display NIKON CORPORATION)
Camera Model: CORPORATION (used to display NIKON D750)
Photographer: xx xx:xx:xx (used to display Photographer's name)
Copyright: shows Photographer's last name from field above (used to display camera copyright text)
John R. Ellis, Champion
I suspect you're encountering a different problem. Does this problem occur for photos that don't have a lot of brush strokes from the adjustment brush? If so, then it's the other problem: http://feedback.photoshop.com/photosh....
Thanks, didn't realise there were two bugs! That other link looks more likely as there are no brush strokes used here, just standard adjustments.
John R. Ellis, Champion
John R. Ellis, Champion
John R. Ellis, Champion
John R. Ellis, Champion
Thank you so much John for all your help and hard work.
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!
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!
John R. Ellis, Champion
Well, I'm glad you have a workaround.
David Franzen, Employee
John,
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.
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.
John R. Ellis, Champion
Agreed, it appears that Google Photos does correctly show the EXIF fields for that example photo (and a couple of new ones created with the same recipe).
However, the most recent desktop Picasa for Mac (3.9.139.218) and for Windows (3.9.139.218) still trip up on them. (I don't think Google is very actively maintaining Picasa?)
I don't have access to Android devices and thus can't test out whether they've fixed the issue in Google's Android gallery (which I think some people were complaining about).
Note that LR CC 2015.1 is still writing the XMP-crs info twice into the file, adding an extra megabyte or two for extensive brush strokes.
Thanks.
However, the most recent desktop Picasa for Mac (3.9.139.218) and for Windows (3.9.139.218) still trip up on them. (I don't think Google is very actively maintaining Picasa?)
I don't have access to Android devices and thus can't test out whether they've fixed the issue in Google's Android gallery (which I think some people were complaining about).
Note that LR CC 2015.1 is still writing the XMP-crs info twice into the file, adding an extra megabyte or two for extensive brush strokes.
Thanks.
Just to report back, I have both Google's Android Gallery 5.0.1 "Lollipop" (the most up-to-date version) & 4.4.2 "Kitkat" (the previous version). Both still have the problem I described a month ago with its slideshow function. Also, many other Android photo apps (e.g., Phorganizer) I think use the same "parts" (data structure, shared code, ... ) that Gallery uses to read the .jpg file meta data so they will and do error out too. And I guess these Android apps could eventually update their code to conform with LR 6.x's .jpg meta data.
But more importantly, does Adobe considers this to be a problem with LR 6.x that needs to be fixed and will fix it? Or are we just out of luck and just need to live with it & find workarounds? My hope is that Adobe will implement a fix soon (maybe a check box within export to write the meta data like LR 5.7.1.)
Frank
But more importantly, does Adobe considers this to be a problem with LR 6.x that needs to be fixed and will fix it? Or are we just out of luck and just need to live with it & find workarounds? My hope is that Adobe will implement a fix soon (maybe a check box within export to write the meta data like LR 5.7.1.)
Frank
David Franzen, Employee
John,
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
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
David Franzen, Employee
John -- nevemind. I've found a way to reproduce the problem. Thanks.
John R. Ellis, Champion
OK, good.
David Franzen, Employee
One workaround for now would be to go back to your original file and re-export a new JPEG. That new JPEG might have extended XMP (based on the amount of metadata and the metadata export options), but it should not have duplicate copies. After export, do not make any additional metadata edits to the exported file, if it contains extended XMP.
Same here. Problems with Exif data in various forums and websites, including my own Wordpress site with Exif plugin installed (tried all available through WP repository). Simply seems the 'industry standard' is not so standard if every plugin under the sun used online does not conform to it. Back to old version, 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. If a third party LR plugin can solve, or at least circumvent the problem, why is it such a big deal to push a hotfix addressing the issue?
"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.
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.
I totally agree. The silence from Adobe is "deafening".
Steve Sprengel, Champion
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.
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.
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.
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.
Steve Sprengel, Champion
The Adobe employee's exact phrase, above, is:
"I've found a way to reproduce the problem."
"I've found a way to reproduce the problem."
If they can reproduce the problem, then they're also working to solve the problem.
Thank you Chris for your official acknowledgement. Hopefully we'll see this problem fixed in LR6.2.
John R. Ellis, Champion
