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

[StarGeek]

Also, when DAM updated the metadata, it deleted the whole XMP-tiff family.

You haven't mentioned what your DAM is, but based upon this behavior, I'm guessing Lightroom?  I've seen LR do that in the past.

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

Related, you can remove all empty XMP entries with
exiftool -XMP:All-= FILE

It's been a while since I checked but I faintly remember trying to use -All:All-= at one point but it added a noticeable amount of extra run time.  Using the more precise -XMP:All-= worked better.

[lintujuh]

Thank you Phil for your support.

I have reported my findings to the DAM vendor, and asked if they could verify my conclusions and report the bug to Adobe.

Now I know what I have to do with my old images, and what to do to avoid the problems in the future.

[lintujuh]

You haven't mentioned what your DAM is, but based upon this behavior, I'm guessing Lightroom?  I've seen LR do that in the past.

No, it's not Lightroom, it is Daminion. But it uses Adobe's toolkit library, so I guess the behavior is the same. 

I need to think, which approach I'll take, because I cannot trust that the image files have the correct information, so I need to trust my DAM database and push the information into the images. I think I will take either your approach @StarGeek and remove all empty XMP tags or I'll delete all XMP-tiff tags empty or not, as that family will be deleted in any case when I force-write the tags from database to the images.

[lintujuh]

When I started to describe the issue to GeoSetter, and to ask that the XMP-tiff tags wouldn't be created, if not needed, I found a similar issue with JPGs and Lightroom. https://geosetter.de/mantis/view.php?id=2122

When I searched this forum with the word Lightroom, I didn't find a post that corresponds to ricebucket's problem, so (s)he probably hasn't reported it here.

[Phil Harvey]

As I said, I have no problem with Lightroom.  I followed the steps in the Geosetter bug report and I can save metadata to the file with LightRoom 5.7.1, so this bug is version dependent.

And yes, LR does delete all XMP-exif and XMP-tiff metadata when updating the metadata.

But I noticed a different problem with Geosetter/ExifTool when analyzing the output:  Geosetter is writing EXIF:GPSTimeStamp with a value of "10.11.37".  However, ExifTool currently accepts floating point values for hours, minutes and seconds, so this is interpreted as 10.11 hours, 0.37 minutes and 0 seconds.  I don't know why Geosetter uses decimals as separators, but I can see that ExifTool's behaviour is not as one would expect.  I will look into changing this so floating point values are only accepted for seconds.

- Phil

[lintujuh]

In German the standard separator between his and minutes is colon ( or dot (.).

[ricebucket]

I actually had reported this problem in this forum earlier:
https://exiftool.org/forum/index.php?topic=12580.0

But thanks for figuring out the answer, which we failed to do in my thread. I will try to test your solution on my machine later.

Re: the EXIF:GPSTimeStamp problem. Are you on a German locale? or does the problem occur to all locales because the author of GeoSetter is German?

[lintujuh]

Are you on a German locale?

No, on Finnish, but we have the same separator, so I cannot say, if is it because GeoSetter is German or not.

[ricebucket]

I finally got a chance to try running:

exiftool -xmp-tiff:imagedescription-= *.JPG

on a folder of images with the write problem. The response was disheartening:

    0 image files updated
  219 image files unchanged

And as expected, opening up Lightroom to try to write to the files still doesn't work.

In my earlier thread, I tried to debug by removing each tag individually, and none worked. So it makes sense that the above doesn't work because I think I would have found the solution earlier.

Seems that my problem is different from that of the OP.