Metadata changes to selection is only written back to last image in selection

[hluxem]

I hope I didn't overlook an already filed bug report. This may be similar to below solved bug report.
I'm using the latest 2023.1.8 version.

Add or modify author's name does not work for multiple files (photools.com)

While cleaning up location data I realized that changes reverted back when saving meta data for files changed. I created a small test database to make sure it's not a problem of the existing database.

Steps to reproduce:

• Select multiple images with location data as shown in first screen shot.
• Select State/Province {File.MD.Composite\MWG-State\State\0} in Metadata panel and change value from Maine to New Hampshire. Commit change with green checkmark. As shown in attached 2nd screen shots, new values are shown in Metadata panel and thumbnails.
• After write back the changes, only the last selected image has the new values.

I know there has been another issue with the mapping of location tags, but that should be consistent with all files. I did another test with the Author tag and the changes stick with all files when written back. The Country {File.MD.Composite\MWG-Country\Country\0} shows the same issue as the state tag.

[Mario]

This has been resolved for IMatch 2023.1.10
It was caused by the use of a Composite tag and the way IMatch maps Composite tags to their "real" tags during write-back.
State is a composite tag that maps to three other tags during write-back.

I frankly don't recall the details anymore (need to check my docs from 10 years ago ) why I used Composite tags in these standard layouts. Probably because ExifTool maps them during write-back.
But then there was probably a problem with some Composite tags or some mapping and IMatch was modified to map (some) Composite tags to the real XMP/EXIF/IPTC tags during write-back, and then write those instead.

This is not really satisfying.
I shall have a deep think (once I have time to do some deep thinking again) and make some experiments.
I'd prefer users to use the structured LocationShown and LocationCreated (in the corresponding "IPTC Location" MD Panel Layout) in the future. But, since this is metadata, and location data involves EXIF, XMP and legacy IPTC, there will be some pitfalls and a 100 yards of barbed wire to cross.

[hluxem]

Thanks for fixing that so fast! 

I guess the problem starts with too many redundant tags, I wondered more than ones which one too use.

Heiner

[Mario]

Metadata has evolved over time, a lot. Formats, schemata etc. have been extended, modified and deprecated. New segments were added, new namespaces. All of this, and also trying to stay compatible with things like legacy IPTC (which IMatch does not create, but has to maintain when it exists in a file) complicate things even further. And the fact that some values must be written to multiple tags in multiple standards.

Anyway, I've recently had the change to see the metadata mayhem produced by a popular "DAM" software and which does cross-device synching, cloud storage and all that. They have very good marketing, I have to admit. Hopefully none of their users will ever need their metadata in other software, or there will be tears...

[axel.hennig]

I'd prefer users to use the structured LocationShown and LocationCreated (in the corresponding "IPTC Location" MD Panel Layout) in the future.

I would also prefer to use these tags, but if (for example) one changes the Lat/Lon for an image via Map-Panel (by clicking on the Apply target maker button) AND does not write-back immediately, then the updated Lat/Lon does not appear in LocationShown or LocationCreated because these are filled during write-back and the database just updates the corresponding XMP::exif tags.

By the way: Even when using write-back, LocationShown or LocationCreated are not updated. One has to additionally apply Reverse-Geocoding and write-back to get LocationShown or LocationCreated to be updated. This is related to the following bug-report I wrote.