Tags written by GeoSetter into DNG not compatible with Adobe XMP Toolkit

[lintujuh]

I have a straight out of camera DNG files that don't contain geolocation, but the corresponding JPG does. I use GeoSetter to copy-paste the geolocation and also to fine tune the positions as pictures taken at the same place might have slightly different coordinates. Internally GeoSetter uses exiftool for updating the metadata. I use also a DAM solution that utilizes "under the hood" Adobe's XMP Toolkit. After geotagging the file in GeoSetter, the DAM solution cannot write XMP tags into the DNGs. I have verified with the DAM vendor that the problem is in a corrupted/non-Adobe compliant XMP block. If I delete the XMP block with exiftool -xmp:all= file, I can update the metadata normally and it will be written into the file. Also, if I have first assigned an XMP-tag with exiftool, e.g. title, GeoSetter doesn't cause any problems later.

I have attached the command line that GeoSetter says it is sending to exiftool. The original DNG file is without any XMP block (checked with exiftool -a -G). I can share an example DNG file, if needed.

I'm running the latest exiftool (12.36) on Win10.

[Phil Harvey]

Unfortunately this doesn't give me anything to go on.  You will have to do more tests to see what your DAM doesn't like.  Try starting with something like this and working up to your full command:

exiftool -xmp:all= -xmp:subject=test FILE

- Phil

[lintujuh]

I have pinpointed the problematic statement to line 71 (-XMP:Description=) in the attached args file. I executed a command:

exiftool -@ ./exifcommand.args -common_args IMG_20211024_131137.dng

and searched the row where it breaks. Executing up to and including line 70, the result was compatible, but when I including the line 71 the result was not compatible. (I tested also with some combinations where there I executed some lines after line 71 and the result was also not compatible.)

I hope this gives some additional pointers.

I have sent you the DNG file in email.

[Phil Harvey]

This does narrow it down a bit.  It is the XMP content, and not the placement in the file or the XMP packaging that is the problem.

I have seen a similar problem in the past where Adobe software wouldn't load an image if the time zone in any XMP date/time tag was set to +00:00.  It is hard to understand how they could have a weird bug like this, but they eventually fixed it.  Removing the XMP-dc:Description from this file shouldn't be a problem.  The only thing I can think of is the software is trying to validate the XMP content somehow, and is failing internally while trying to do this.  I can pretty much guarantee that this isn't an ExifTool problem.

- Phil

[lintujuh]

Do you have any recommendations what I could do? I don't have control on the command file that GeoSetter generates for exiftool, so I cannot remove the offending line. I got the command line when I had removed exiftool from the path and the application generated an error report. Also, I think I would need more evidence that Adobe would take my bug report seriously.

[Phil Harvey]

Good question.  I tried to reproduce your symptoms here using Adobe LR5, but it didn't have any problem with the file I generated from your sample and the command you gave, either reading or writing metadata.

I don't understand how adding XMP-dc:Title beforehand could make any difference.  We should investigate that.  Try runnning the same file through your workflow twice, except add Title to one of them.  If I understand correctly, you when you add Title before Geosetter then your DAM accepts the file.  But the command you posted deletes XMP:Title in the second phase, so both output files should be the same.  If one works and one doesn't, send me the files and I'll analyze the differences.

- Phil

[StarGeek]

What version of exiftool do you have in the Geosetter directory?  It might be in the same directory as Geosetter or it might be in %appdata%\GeoSetter

[lintujuh]

I did some additional tests. If I define the title in the command file, the behavior is the same: errors when updating. If I define the title first, before I invoke GeoSetter, I get slightly different command file for exiftool. See the attachment. If I run this command file, I don't have issues with my DAM.

@StarGeek A good point, but I have already updated also that copy to the latest version.

[lintujuh]

Oops. I forgot the attachment.

[Phil Harvey]

Could you send me the two resulting DNG files (the one that works after you first wrote Title, and the one that doesn't) so I can compare them?

Thanks.

- Phil

[Phil Harvey]

I got the files.  Again, the overall file structure is the same for both the working and non-working files.  (You called the non-working file "corrupt", but I don't think it is.)

The two commands executed by Geosetter are very different, and the resulting XMP is also very different.  But simply changing the XMP content shouldn't cause problems for any reasonable XMP reader.  It is still valid XMP, although it may contain some irrelevant/unnecessary information such as image dimensions and bit depth, etc.  You can try this command to see if it is just the XMP content that is the problem:

exiftool -tagsfromfile IMG_20211024_131137_noncorrupt.dng -xmp IMG_20211024_131137_corrupt.dng

If the resulting file works in your DAM, then it was definitely the XMP causing the problem.  If so, you really need to go back to your DAM people because it is valid XMP.  (Just for fun, I also ran the "corrupt" XMP through both the RDF validator https://www.w3.org/RDF/Validator/ and the PDF/A XMP validator https://www.pdflib.com/pdf-knowledge-base/xmp/free-xmp-validator/ and neither showed any problems.)

But if it doesn't work, the other difference is that the "noncorrupt" file also contains IPTC.  If this happens, run this command on the new "corrupt" file from the last command:

exiftool -tagsfromfile IMG_20211024_131137_noncorrupt.dng -iptc:all IMG_20211024_131137_corrupt.dng

If this now works with your DAM but the previous version didn't, then the difference is the IPTC.  Again, the IPTC is technically fine.  But due to tests you have run earlier, I suspect the the XMP is the source of the difficulty.

- Phil

[lintujuh]

Thank you Phil for your efforts.

Copying the xmp information from the working file to the non-working file (corrected the terminology ) is working with the DAM. I have replied to the DAM support, that they have the problem and pointed to this thread.

As the DAM database contains the valid tagging information and I don't know which of the tags are written into the files, I guess the best thing to do is to delete the xmp block from the DNG files and use DAM to write the tags from database to the files. Or do you have any other suggestion?

exiftool -xmp:all= DNG-files

[Phil Harvey]

If the XMP doesn't contain information that is useful for you, then go ahead and delete it.  However, I'm sure there is something specific in the XMP that is causing problems with your DAM, and a better solution would be to selectively delete the offending tag(s), but this would require some effort to determine what these were.  Of course, the best solution is to fix the DAM.

- Phil

[lintujuh]

The problematic tag looks like to be XMP-tiff:ImageDescription, even (or maybe because) it doesn't contain any value.

...
---- XMP-tiff ----
Bits Per Sample                 : 16
Compression                     : Uncompressed
Copyright                       :
Image Description               :
Image Height                    : 2976
Image Width                     : 3968
Make                            : HUAWEI
...

When I executed commands

exiftool -@ ./exifcommand.args -common_args IMG_20211024_131137.dng   /* execute the original GeoSetter commands */
exiftool -XMP-tiff:imagedescription= IMG_20211024_131137.dng

DAM could handle the file nicely. Also, when DAM updated the metadata, it deleted the whole XMP-tiff family. I have also placed the updated dng in Google Drive.

[Phil Harvey]

Interesting.  Good sleuthing.  It does make a bit of sense if it is an empty value that causes the problem.  While empty values in XMP are allowed, they really don't serve any useful purpose.  You can run this command to remove the imagedescription only if it is empty (ie. it won't change the file if it has a non-empty imagedescription):

exiftool -xmp-tiff:imagedescription-= FILE

- Phil