Lightroom cannot save to JPG modified by exiftool

[ricebucket]

As stated in the title, Lightroom cannot save metadata to a file that's been modified by exiftool. I looked over the FAQ but it's very dense and I do not know where to start to debug this issue. In particular, I looked at question 3c, but do not know what I should be looking for in the printout.

To reproduce:
1) Import affected file into lightroom
2) Make some metadata changes in Lightroom
3) Right click image in lightroom, in context menu select "Metadata" -> "Save Metadata to File"
4) Lightroom attempts to write to file, but fails with error: "Could not write metadata. Unknown file format."

A sample image is linked below:
https://ricebucket.dreamhosters.com/geosetter/JZB09344.JPG

Lightroom can read the file just fine, and can make develop changes or export. As long as I don't write to the original file (via save metadata), it works.

Any help is appreciated.
Thanks

[Phil Harvey]

What version of LightRoom and ExifTool are you using?  Also, what was the exact ExifTool command you used?

Adobe products have been known to be picky and buggy about the metadata they read.  In the past, they would not load images if the time zone in any XMP tag was set to +00:00, but they have since fixed this.  For your file, the only non-standard thing I see is this:

Code Select Expand

> exiftool ~/Desktop/JZB09344.JPG -validate -warning
Validate                        : 1 Warning (minor)
Warning                         : [minor] Non-standard ExifIFD tag 0x882a TimeZoneOffset

- Phil

[ricebucket]

Thank you for the response Phil.

I created the file using the Geosetter tool (https://geosetter.de/en/main-en/) so I'm not sure what's the command called by the program.

Lightroom and Geosetter and Exiftool are the newest versions, but this problem has occurred for at least two years. (This particular example file is from two years ago, but I see the same problem on new files created using the same workflow.)

I tried removing the TimeZoneOffset tag with the following:
exiftool -TimeZoneOffset= JZB09344.JPG

Loaded the file into lightroom, and the same problem still occurs. So I don't think TimeZoneOffset is the problem.

I can think of two ways to tackle this problem, if there's only 1 bad tag that is causing the issue:
1) is there a way to binary search this? Remove half of the tags at once, then import into lightroom, try saving, and repeat... Not sure if there's an easy way to remove half of the tags with exiftool. (Can actually speed this up by generating both branches and importing into lightroom at once)
2) Could also try just removing the location tags one by one. I think there's around 250 tags, so if we can automate this and generate 250 variations of the file, each missing a single tag, then we can import all 250 into lightroom at once, and save all of them and see which one succeeds. Not sure what's the best way to script this with exiftool
to generate the variations.

#2 might actually be the fastest approach since I can just import everything into lightroom at once in one go.

Any other suggestions on what to try?

[ricebucket]

Just one more data point:

I tried stripping all tags with -all= and Lightroom was able to save the file just fine.

I think this proves that the problem is with the metadata, and not with my particular system (disks, etc.)

[Phil Harvey]

OK.  Try each of these commands to see which metadata types are causing the problem:

1. exiftool -exif:all= FILE

2. exiftool -xmp:all= FILE

3. exiftool -photoshop:all= FILE

Then once you know which one is causing the problem, try this:

exiftool -PROBLEM:all= -tagsfromfile @ -PROBLEM:all FILE

If this fixes it, then send me this file and the original and I'll take a look at what changed.  (Although if the photoshop information was bad, then this last command won't preserve it like the other two metadata types.)

- Phil

[ricebucket]

Thanks for the help.

You can find all of the files I refer to in this post here:
https://ricebucket.dreamhosters.com/geosetter/

Turns out XMP is the culprit. The version without xmp generated by
exiftool -xmp:all= JZB09344.JPG 
which I named "noxmp_original.jpg" works fine. The version after saving by lightroom is named "noxmp_savedbylightroom.jpg"

But I'm a bit confused about your last instruction.

I ran
exiftool -xmp:all= -tagsfromfile @ -xmp:all JZB09344.JPG
on the original file (I assume you meant replacing PROBLEM with xmp).

The resulting file, which I named "problem.jpg", still cannot be saved by LR. I'm not sure what the previous command does as I don't understand the syntax.

(Note that I'm running ExifTool 12.16 on this Mac to generate these variants, which I know is not the newest. But from what I've seen, this problem occurs even on newer builds of exiftool, which I use with geosetter on my windows pc.)

[ricebucket]

It seems there's only about 10 XMP tags in the given image. Should I just go about removing each one and test? What's the best way to do this?

[Phil Harvey]

Sure, try that.  Also, could you send the the problem file so I can try some things when I get a chance.  My email is philharvey66 at gmail.com

- Phil

[ricebucket]

Which file do you mean is the problem file?

This folder has all of the files I mentioned, except for the original image out of camera (before geosetter save):
https://ricebucket.dreamhosters.com/geosetter/

[ricebucket]

This is now really puzzling:

I tried removing the tags one by one, and none of the resulting files could be saved by LR.

I then tried removing all of the xmp tags by specifying the tags individually with the -XXX= syntax:
exiftool -State= -Country= -Location= -CountryCode= -XMPToolkit= -Creator= -Rights= -DateTimeDigitized= -DateCreated= 7.jpg
And this file (7.jpg) still didn't work, even though it should have none of the xmp tags!

Since I knew that the file generated by -xmp:all= could be saved by LR,
exiftool -xmp:all= noxmp_original.jpg

I tried to diff the tags output from 7.jpg and noxmp_original.jpg:
diff `exiftool -s 7.jpg` `exiftool -s noxmp_original.jpg`

And aside from the difference in File* tags, the output is odd in that the City and GPSLatitudeRef and GPSLongitudeRef tags seem to have reordered:

186a187,188
> GPSLatitudeRef                  : North
> GPSLongitudeRef                 : West
202a205
> City                            : Tularosa
209d211
< City                            : Tularosa
216c218
< MPImageStart                    : 3580259
---
> MPImageStart                    : 3573620
243,244d244
< GPSLatitudeRef                  : North
< GPSLongitudeRef                 : West


But otherwise exiftool is not showing any significant differences between the tags of these two files. Yet one works (noxmp_original.jpg) and one doesn't (7.jpg).

As before, all of the mentioned files are here:
https://ricebucket.dreamhosters.com/geosetter/

[Phil Harvey]

OK.  I'll take a look when I get a chance.

But with your tests, it seems like the problem is the location of the XMP in the file, not the content of the XMP.

- Phil

[Phil Harvey]

Sorry for taking so long to look at this, but as you may imagine analyzing problems in other software is fairly low on my list of priorities.

Unfortunately I can't reproduce this problem with my version of LightRoom.  LR5 writes metadata with no trouble to the problem files using the technique you described.  I suggest filing a bug report with Adobe and sending them one of the problem files.  In the past I have had good success getting Adobe to fix problems like this (in fact, this is why I own the legal copy of LR5 -- Adobe gifted it to me so I could analyze some metadata problems they were having), but I don't have as much time nowadays to chase down problems in their software.

- Phil

[StarGeek]

For what it's worth, Adobe Bridge also has problems writing to some of these files.

[ricebucket]

Posted on the adobe feedback page here:
https://feedback.photoshop.com/conversations/lightroom-classic/lightroom-classic-cannot-write-to-some-jpgs-saved-by-exiftool/60d2a3fd82a9b026190c29ac

I hope this is the right place?

[Phil Harvey]

This problem cropped up again, but a solution was found this time:  See this thread.