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
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:
> exiftool ~/Desktop/JZB09344.JPG -validate -warning
Validate : 1 Warning (minor)
Warning : [minor] Non-standard ExifIFD tag 0x882a TimeZoneOffset
- Phil
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?
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.)
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
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.)
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?
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
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/
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/
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
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
For what it's worth, Adobe Bridge also has problems writing to some of these files.
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?
This problem cropped up again, but a solution was found this time: See this thread. (https://exiftool.org/forum/index.php?topic=13056.0)
This problem just turned up for me on Lightroom Classic 12.3 with some 10-year-old TIFF files of prints made on an Epson scanner with Silverfast.
The fix for me was turning on 'Automatically write changes into XMP' which seems to do something different from the menu command 'write metadata to file'.
I had tried saving/reading metadata in several ways and used the exiftool analysis to try and find a difference between very similar TIFFs that were saveable or not saveable but had the same origin. I could not identify any bad tags or any differences in working/non-working TIFFs.
I had resorted to stripping the XMP completely from some of the files, which 'works' at the expense of any Develop settings etc.
I then noticed that the Catalog Settings...> Metadata panel did not have 'Automatically write changes into XMP' checked, which historically I have done. Simply checking that box made every 'down arrow' on hundreds of files disappear with no further action, and editing the files then proceeded normally also without new 'down arrows'.
Presumably this hinges on some difference between the Lightroom menu command 'Save Metadata to file' and setting 'auto-writing of metadata into XMP' checkbox.
I took this opportunity to convert the TIFFS into DNGs.
FYI: Lightroom database on Mac Mini 2018 i7 32GB RAM running MacOS Ventura 13.3.1, Lightroom Classic 12.3, image files stored on a TrueNAS SMB server accessed over wired Ethernet local network.
The Adobe XMP parser isn't very robust. I've seen it fail on perfectly good XMP in the past, and when it does the Adobe software may fail to load the image. But they will fix the problems if you can isolate them and report them.
- Phil
Thanks. Oh, and even when LR said it could not save the metadata to the files and showed a 'down arrow' in the corner of the image's grid view, actually running exiftool on the file I could see that any changes in metadata (key words, description etc) were getting saved by the command 'save metadata to file'.