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.
- 117 Posts
- 12 Reply Likes
Posted 5 years ago
- 117 Posts
- 12 Reply Likes
- 117 Posts
- 12 Reply Likes
Choose the option to remove the XMP "crs" block (which contains the develop settings).
- 10 Posts
- 1 Reply Like
This is causing me a bug problem and I hope it gets fixed quickly; a DAM application generating invalid XMP metadata is unacceptable.
- 47 Posts
- 5 Reply Likes
Hope Adobe fixes this soon!
- 13 Posts
- 1 Reply Like
- 9 Posts
- 1 Reply Like
Crazy thing to see such an important aspect of the software goofed up. Hoping for a point release sometime soon!
- 12 Posts
- 1 Reply Like
"The GUID is also stored in the StandardXMP as the value of the xmpNote:HasExtendedXMP property. This allows detection of mismatched or modified ExtendedXMP. A reader must incorporate only ExtendedXMP blocks whose GUID matches the value of xmpNote:HasExtendedXMP"
The GUID of the second extended XMP doesn't match, so technically it should be ignored. ExifTool doesn't ignore it though.
- Phil
- 117 Posts
- 12 Reply Likes
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.
- 117 Posts
- 12 Reply Likes
David Franzen, Employee
- 103 Posts
- 24 Reply Likes
- 47 Posts
- 5 Reply Likes
- 47 Posts
- 5 Reply Likes
- 5 Posts
- 0 Reply Likes
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
- 4642 Posts
- 1248 Reply Likes
- 5 Posts
- 0 Reply Likes
John R. Ellis, Champion
- 4734 Posts
- 1291 Reply Likes
http://feedback.photoshop.com/photosh...
I've tried a couple of exports and it seems to work.
- 47 Posts
- 5 Reply Likes
So I tried some cursory tests with this Limit File Size workaround. Now the Android Gallery Slideshow function seems to work better. But still there are some photos that are out of sequence when they were taken within the same second (used to sequence down to Sec./100 I think, no time to research this in detail right now). Also, now one export process runs at 100% CPU. I used to run three parallel exports to use up CPU and still had a little CPU left. Now it's too frustrating getting LR6 to respond quickly enough so I can get the other exports started.
Unfortunately, I don't have the time to do more in-depth research and testing on this. I need to get my work out the door and don't want to redesign/change my work flow processes because of this LR 6 issue. So I back to using LR 5.7.1 even though it doesn't support my GPU & 4K monitor well. Nevertheless, it would be nice to have LR 6 working like LR 5.7.1 EXIF data wise.
John R. Ellis, Champion
- 4734 Posts
- 1291 Reply Likes
LR 6 uses all your processors to do an export, making each export go faster, so you don't need to split a large export into smaller pieces and fire them off manually, which is what people used to do in LR 5. But I've seen a lot of reports that LR is unusable during an export now, which suggests it's being too aggressive at using all available CPU for the export.
- 47 Posts
- 5 Reply Likes
However, since realizing the EXIF data problem a month ago (which messed up my work flow processes with my customers), I haven't been using LR 6 at all. There is much less risk running LR 5.7.1 for my production work since I know it works within my work flow.
Moreover, using the "Limit File Size" workaround, any ideas about photos taken within the same second? I think the IPTC "Date Created" goes out to 1/100 sec. and maybe LR 6 is truncating the 1/100 sec. part (haven't had time to looking to this). Any help would be appreciated.
All in all, I would love to use LR 6 for its use of my GPU and increasing its response when using my 4K monitor. But right now, I can't trust it for my production work.
Anyway, Adobe should hire you. You are great. Thanks again!
Frank
John R. Ellis, Champion
- 4734 Posts
- 1291 Reply Likes
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.
- 47 Posts
- 5 Reply Likes
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.
- 47 Posts
- 5 Reply Likes
John R. Ellis, Champion
- 4734 Posts
- 1291 Reply Likes
- 47 Posts
- 5 Reply Likes
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
- 4695 Posts
- 1270 Reply Likes
David Franzen, Employee
- 108 Posts
- 28 Reply Likes
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
- 4710 Posts
- 1277 Reply Likes
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.
- 47 Posts
- 5 Reply Likes
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
- 108 Posts
- 28 Reply Likes
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
- 108 Posts
- 28 Reply Likes
David Franzen, Employee
- 108 Posts
- 28 Reply Likes
- 1 Post
- 0 Reply Likes
- 9 Posts
- 1 Reply Like
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.
- 47 Posts
- 5 Reply Likes
Steve Sprengel, Champion
- 2672 Posts
- 347 Reply Likes
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.
- 9 Posts
- 1 Reply Like
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
- 2672 Posts
- 347 Reply Likes
"I've found a way to reproduce the problem."
- 20280 Posts
- 842 Reply Likes
- 47 Posts
- 5 Reply Likes
John R. Ellis, Champion
- 4734 Posts
- 1291 Reply Likes
- 47 Posts
- 5 Reply Likes
- 47 Posts
- 5 Reply Likes
Related Categories
-
Lightroom Classic
- 14816 Conversations
- 3713 Followers