Too Many Geo-Location Tags ...

[PandDLong]

One of the advantages of iMatch is that it keeps tags that should have the same data synchronized so the metadata in the file is consistent.  This is no small task with the multitude of repetitive tags and my appreciation grows for this over time.

I have stumbled across a situation where some geo-location data gets "out-of-sync".  I don't know if this is a bug or the MWG standards at work or just one of those things.

For context:
    - By Geo-Location tags I mean those for country code, country name, state, city and sublocation (and in the case of the IPTC Extension, I mean the Location Shown set of tags). 
    - For updating of the tags, I used the GPS Details metadata panel that comes with iMatch (updates IPTC Extension Location Shown tags)
    - I complete a write-back before looking at the various tags
    - I use the metadata panel browser to look at the tags.

First, country code. 
It is a bit unique as there is no composite tag for it.  It lives in the IPTC Core and IPTC Extension groups.  If one populates geo-locations from a reverse geo-code or assigning an iMatch Location, the two fields are synchronized.    If one updates either tag manually - they stay different.     Doing a reverse geo-code fixes the issue  (note that updating the code in the reverse geo-code dialog without doing a lookup doesn't do it).

Also, if one only enters the code manually in a metadata panel for the IPTC Extension, it never populates the IPTC Core which then means the File.MD.countrycode is also unpopulated.

   *** My assumption is that as it is not a composite tag and there are only two tags (how would iMatch pick one over the other?), it is a user task to keep them the same (including any initial populating of the IPTC Core tag).


Now the other tags.   
Country name, state and city live in the IPTC Extension and the Photoshop groups.   Sublocation is in the IPTC Extension and the IPTC Core.   They are always in-sync after the first write-back, but then if I change an IPTC Extension field in the metadata panel, the change is not always synchronized to the other tags.  This behavior is situational, and I tried out the following five scenarios:

    1. If one only completes the text fields (ie. no GPS), they stay in-sync
    2. If one manually adds GPS values, they stay in-sync
    3. If one assigns GPS and an iMatch Location, they won't stay synchronized
    4. If one assigns GPS through the Map Panel and then manually enters the tags, they stay in-sync
    5. If one assigns GPS through the Map Panel and does a reverse geo-code lookup, they won't stay synchronized

Interestingly (to me), in scenarios 3 & 5 where the Photoshop and IPTC Core tags keep their old values, the Composite tags show up in the Browser with the updated values from IPTC Extension (country name, city, sublocation and state).   I also found the difference between scenarios 4 & 5 surprising  (but perhaps there was a flaw in my testing).

As I said, not sure if this is a bug or just one of those oddities of metadata.  Not sure if this behaviour occurs in exiftool or iMatch itself.

    *** Now that I know this, I can easily keep them synchronized by picking one set of tags as my source of truth and running a template to keep the tags synchronized.   



Not a big item but thought it useful to share.

Michael

[Mario]

The tags shown in the "Default" Metadata Panel layout for location are the ones to fill.
Do a reverse geo-coding and see which tags IMatch fills.

[PandDLong]

So I spent way too much time trying to figure out exactly what was happening.  I created a further 8 test scenarios - and I won't bore the reader with the details of each.

What I learned may be somewhat useful to others (I am making a slight change to my workflow based on it).

The difference in behaviour of a geo-location tag staying synchronized as changes are made versus not staying synchronized appears to be caused by using the Composite tag to update in a write-back (the tag has the pen icon).   

Using City as an example:

1. There are two tags for it in the XMP metadata that are stored in the file - IPTC Extension\LocationShownCity and Photoshop\City.  If one updates the LocationShown tag, then this change is copied to the Photoshop tag on a write-back.   The Composite tag (and the File.MD.city iMatch variable) also show this value (but they are virtual - ie. not stored in the file).  One can make ongoing changes to the LocationShown tag and it all stays synchronized.    (I did not test this using the Photoshop tag as the one to edit).

2. If one updates the Composite City tag in iMatch, the change is copied to the two XMP tags on write-back.   Do that once and changes to the LocationShown City tag will no longer synchronize and the two physical tags get out-of-sync - however the Composite tag will display the LocationShown value on a read back.  This is true on a field-by-field case - ie. the other geo-location tags will continue to synchronize only the tag that was updated by the Composite (even if only once) can now be out-of-sync.   

3. Updating City via the Composite tag in iMatch always work to keep everything - physically and virtually synchronized.


In my original scenario where doing a Reverse Geo-code (or assigning an iMatch Location), iMatch updates both the Composite tags and the LocationShown tags in the database (both sets get the pen icon),  Therefore the composite tags should always be used to make updates to the geo-location tags as situation 2 above has been triggered.     This is true before or after doing a write-back - ie. after a reverse geo-code, going in and changing a LocationShown tag does not get synchronized to the Photoshop tag on write-back.

Where one gets fooled (or at least I did), is that on the read-back of the file, the Composite tags show the LocationShown values so it all looks right.  But a deeper look shows the physical tags are out of sync.   This would never matter if one always looks at the same tags, but share a file (or maybe use different software) and the Photoshop tags may take priority by the viewer or software.


I expect this is all driven by exiftool behaviour and is likely true for all composite tags.  My MWG preference is set to 'Yes' perhaps 'No' produces a different result but I am not going to spend time to find out.  I know enough now to be confident in how I handle this behaviour.


Mario - Perhaps the GPS Details metadata panel that comes with iMatch is setup for the Location Shown information to map to the Composite tags (as the 'Default' panel does) or there is some note about "be careful" on that panel (or help system).  That panel was my go-to for updating the geo-location tags and I am going to change it based on the above.

[Mario]

I'm not sure that I follow.

I start with a fresh image with no GPS data.
I set a coordinate and a location shown and do a reverse geo-code.

This fills the tags listed in the GPS Details Metadata Panel layout, which are all XMP, except for the composite field GPS Position which lists lat and lon.

I write back, this fills the GPS/Location-related tags in IPTCExt (and the Location tag in IPTCCore - from LocationShown\SubLocation when it exists, else from Location\SubLocation).
Composite tags are virtual and produced by ExifTool when IMatch uses it to import metadata.

When I open the file in Photoshop, it shows the correct data for both XMP IPTC and IPTCEx (IPTC Extension page) and the "location shown" data on the "IPTC" page.
The GPS page shows the correct location created and location shown GPS coordinates.

[PandDLong]

I did write up a lot of information, so a bit of twisted road to follow.


If you now change that image's Location Shown SubLocation using the GPS Details Metadata Panel layout and complete a write-back, the XMP IPTC Core Location tag will have the original value and the IPTC Extension tag will have the updated value.   That is what I see in the Metadata Browser (I don't open it in different software).

At least that is what happens for me.

Michael

[Mario]

There is no mapping between these tags.
When I change loc shown sublocation, the XMP-iptcCore is not updated.
When I change loc created sublocation, the XMP-iptcCore is not updated.

So this seems to be a side effect of using the composite MWG tags, which apparently internally perform the extra mapping into the XMP-iptcCore tag.
Reverse geo-coding sets these tags:

Composite   MWG-Location
Composite   MWG-State
Composite   MWG-City
Composite   MWG-Country
XMP::exif   GPSTimeStamp
XMP::exif   GPSDestLatitude
XMP::exif   GPSLatitude
XMP::exif   GPSDestLongitude
XMP::exif   GPSLongitude
XMP::exif   GPSAltitudeRef
XMP::exif   GPSImgDirection
XMP::exif   GPSDestDistance
XMP::exif   GPSAltitude
XMP::iptcCore   CountryCode
XMP::iptcExt   LocationCreatedSublocation
XMP::iptcExt   LocationCreatedGPSLatitude
XMP::iptcExt   LocationShownGPSLatitude
XMP::iptcExt   LocationShownGPSLongitude
XMP::iptcExt   LocationCreatedGPSLongitude
XMP::iptcExt   LocationCreatedProvinceState
XMP::iptcExt   LocationShownProvinceState
XMP::iptcExt   LocationShownSublocation
XMP::iptcExt   LocationCreatedCity
XMP::iptcExt   LocationShownCity
XMP::iptcExt   LocationCreatedCountryName
XMP::iptcExt   LocationShownCountryName
XMP::iptcExt   LocationCreatedGPSAltitude
XMP::iptcExt   LocationShownGPSAltitude
XMP::iptcExt   LocationCreatedCountryCode
XMP::iptcExt   LocationShownCountryCode
XMP::iptcExt   LocationCreatedWorldRegion
XMP::iptcExt   LocationShownWorldRegion
XMP::Lightroom   hierarchicalSubject

and i think the silent, behind the curtain tag mapping inside XMP is performed by the MWG / Composites.
Changing the Composite City in the browser layout sets two locations, in iptcCore and iptcExt, maybe due to the MWG flag or by some intrinsic logic in the Compote tags themselves.

IMatch has no influence on this behavior.
It has also no logic for "when user changes tag X also changes tag N", except for keywords, which has been hard-coded to refuse confusions for users who change hierarchical keywords but show flat XMP or IPTC keywords somewhere (before the write back).

If ExifTool has the logic in the comp tag, it should have the same mapping when the XMP tag is written. Probably.
Else IMatch would have to re-implement the Composite tag feature or introduce complex compound tags and related logic.
I'm sure I have considered this in the design of IMatch 5, but it was never needed so far.

If you directly want to manipulate locations that way, either set the composite tag or change all "linked" tags.
Feel free to add a feature request for this substantial change so I can consider it if there are a sufficient number of users with the same problem.
I'm really not "in" this topic right now, I have not looked at all this logic and composite / MWG effects for years. Maybe ExifTool has changed something under the hood at some point, I don't know.

The MWG Composite tag location alone sets these tags, according to the ExifTool web site:

IPTC:Sub-location
XMP-iptcCore:Location
XMP-iptcExt:LocationShownSublocation
CurrentIPTCDigest
IPTCDigest

This is probably why I picked the MWG Composite tags for this purpose and use them in the Default Metadata Panel layout for display and input, IMatch locations and reverse geo-coding.

[PandDLong]

I came to the same conclusion that this is exiftool behaviour - although my conclusion included much more speculation than your view.   

The surprise in exiftool is that if one doesn't use a composite tag, exiftool will treat an update to one of the underlying tags the same as the composite and synchronize the XMP tags.  Using your example - if you didn't do a reverse geo-code and just entered all the fields in the GPS Details Metadata Panel layout, all future changes would continue to synchronize between the IPTC Core and IPTC Extension fields.
Use a composite tag and this treatment by exiftool changes - for that image.    This inconsistency is what caught me as sometimes I use reverse geo-code and sometimes I don't - then my subsequent edits to geo-location tags were coming out differently.   


There is no need for a feature request.


A good guideline is for a user to be consistent - if one uses a composite tag to update a data point, always use the composite tag.    As iMatch - rightly - uses composite tags in reverse geo-coding, one should use the composite tags to make any edits or changes for those geo-location fields.


Thanks for your review of my findings and confirmation of the source of the issue.

Michael

[Mario]

The surprise in exiftool is that if one doesn't use a composite tag, exiftool will treat an update to one of the underlying tags the same as the composite and synchronize the XMP tags.

I don't understand this sentence.
If you don't use the location composite tag, ExifTool sets exactly the one iptcExt location tag (not also mapping to the loosely-coupled iptcCore tag).
The special mirroring logic applies only to the MWG Composite tags, as far as I understand.
Frankly, the last time I've looked into this was with IMatch 5, I believe. And why I chose to use composite tags for these few tags, over the usually preferred XMP tags.
Maybe swapping the one or two XMP tags in the "GPS Details" layout with the MWG Composite tags (like I've used in the Default Metadata Panel layout) would avoid potential problems (unless the user uses Metadata Templates, external applications, apps or the Metadata Mechanic to set these tags outside the control of IMatch)...

[PandDLong]

I don't understand this sentence.

The sentence is confusing as the behaviour is surprising - I don't understand why ExifTool does this - it seems a bit inconsistent - but it is a comprehensive tool so I am sure there are good reasons.

If one takes a fresh image (with or without GPS), and only manually edits the LocationShown tags in the GPS Details Metadata Panel layout, on write-back ExifTool will update those loosely coupled tags in IPTC Core and Photoshop.  With additional changes this "synchronization" of tags on write-back continues.     Use a composite tag as the update mechanism and from that point forward this "synchronization" stops when updating a LocationShown tag.

It is a bit odd but it is what it is.

Maybe swapping the one or two XMP tags in the "GPS Details" layout with the MWG Composite tags

Exactly, I will change the Metadata Panel layout to update the Composite tags - for me that will be enough (and a one-time run of Metadata Template to synchronize the geo-location tags of my existing images). 

Michael

[Mario]

My findings are also inconclusive.
It seems MWG Composite Location sets the IPTC Core location only when it has the same value as the Comp Tag or is empty.
Same for the IPTC Ext tags, which also sets the IPTC Core tag on write-back, but only if it is empty.

There are reasons why I chose the 4 MWG tags for the default layout.
And I switched the default "GPS Details" layout to use the MWG comp tags to. This will affect only new installations or when you re-import the layouts in IMatch 2021.
Or just swap the four country, city, state location for "shown" to use the MWG Comp tags for your installation if you plan to continue setting them manually in that layout.

[PandDLong]

Unfortunately, that wasn't a perfect solution.

I catalogued a couple hundred pictures.  This included doing a reverse geo-code and then manually updating some of the sublocation and city tags (which I now do by updating the composite tags in a metadata panel).   After write-back, my manual updates were effectively gone.   Deeper inspection showed that my updates were residing in the "loosely" coupled tags - IPTC Core Location and Photoshop City - so I used a metadata template to copy them over to the Location Shown and Composite tags and all is well.

It made me look back at my earlier tests and I redid some but this time focused on understanding the list of metadata tags to be written for each test as we had concluded earlier it is not an iMatch issue but an ExifTool behaviour.


I think I now understand what is happening.  Using Location as the example (and assuming no legacy IPTC data):

1. Updating the Composite tag, ExifTool will update the LocationShown and IPTC Core tags.

2. Updating directly one of the two tags there is some different behaviours which seem to centre around a tag being empty or not and if the two tags were the same before the update or not.  But I think it is not necessary to fully document these various cases here.

3. When reading metadata and setting the Composite tag value, if the two tags are both populated and different, the Composite tag takes the value of the LocationShown tag.  Composite will take the IPTC Core tag if the LocationShown tag is empty.


So, what is my conclusion?   If the metadata changes to be written includes the Composite and LocationShown tags (which is always true after a reverse geo-code), then the LocationShown and IPTC Core tags are updated when ExifTool processes the Composite tag update but then the LocationShown tag update will overwrite it for that specific tag.   Then on read and update; the LocationShown value shows up for the Composite value.

The changes made to the GPS Details layout to use the Composite tags instead of LocationShown tags works well unless the user wants to change the result from a Reverse Geo-code in the metadata panel before doing a write-back.  Note that making the change in the Reverse Geo-Code dialog does work as it updates both the Composite and the LocationShown tags.

For me, I often use a metadata panel as I will update a geo-tag for multiple photos at one-time.

I hope that all makes sense.


I will take my findings and try to write-up a simple feature request(s) to manage this behaviour of ExifTool.

Michael

[Mario]

I recommend you use the location tags in the Metadata Panel and reverse geocoding to set the GPS data.
This will work out of the box. If you set arbitrary tags here and there, your changes may be wiped during the write-back mapping.
This is complex stuff and MWG and other rules must be applied. Which ExifTool does, when the composite tags are used. This is why IMatch is using them.

[PandDLong]

I am using the tags in a metadata panel which are the same as out-of-the-box.

To be sure, I just upgraded to the latest version (I was on iMatch2020) and then:

   1. Indexed a fresh picture that had GPS co-ordinates
   2. Completed a reverse geo-code
   3. Used the '1 Default' metadata panel to update City and Location  (which correspond to the composite tags)
   4. Completed a Write back

My manual changes are gone and what is displayed is the results from the Geocode. 


Based on the above not even sure this is about a feature request, it seems more like a bug. 

I will start a fresh thread to get rid of all the clutter from my earlier posts where I was looking at a million things trying to sort out what was happening.

Michael

[Mario]

I tried that.

Set a GPS location for a fresh file.
Reverse geocode in IMatch.
Write back.
=> Data saved correctly.

Modify the name of the city and location in the Metadata Panel, default layout.
Write back.
=> Data saved correctly.

XMP, IPTCExt and Photoshop data updated as required and showing the changes both in the database and in the file.

Have you perhaps changed the Default layout at some time, using some wrong tags?
Maybe re-import the layouts (from C:\ProgramData\photools.com\IMatch6\Presets\system.immdl)?

[PandDLong]

Yes, that sequence will work.  Repeat the same test but don’t complete the write-back after the reverse geo-code.  Just do the one write-back at the end.

Michael

[Mario]

I have identified the source of this particular "problem".

As an example, consider the Composite\MWG-City tag. This is the tag used in the Default Metadata Panel layout.
The tag is implicitly linked to XMP-iptcExt:LocationShownCity and XMP-photoshop:City and IPTC:City.
When you change this tag, all these tags are updated during write-back.

When you do a reverse geocode, IMatch sets the Composite\MWG-City and the XMP-iptcExt:LocationShownCity these tags with the data returned by the geocoding service.
When you now change the composite City in the Metadata Panel before writing back, the existing value in XMP-iptcExt:LocationShownCity overrides your change (it seems ExifTool prefers it during write-back).

The solution for this would be to not set the Country, City, State, Location in XMP "Location Shown" during reverse geocoding and rely solely on the composite tags doing the job when the user writes-back the file. Assuming MWG is enabled (if the MWG flag is not set for ExifTool, other things happen).

But in this case, the LocationShown XMP tag visible in IMatch (MD Panel, variables, etc.) will not match the Composite City tag until the user has written back.
I'm not sure if this will cause other problems.

Yet another solution would be to re-implement the internal logic ExifTool uses for these Composite tags in IMatch and synchronizing changes in the database when the user modifies one of these linked tags anywhere in IMatch, from the Metadata Panel to Metadata Templates to the Metadata Mechanic or apps. Not sure if I want to go there just to solve this particular issue.

A simple "After performing a reverse geocoding we suggest you write back all affected files to ensure that all linked metadata tags are synchronized" in the help (and maybe a corresponding message shown to the user when he uses reverse geocoding (with a don't show again option)) is much faster and as effective.

[PandDLong]

I went through the same options.  Not setting the LocationShown tags on reverse geo-code sounds elegant but would make a mess of many user's workflows, panels, templates etc as you would effectively remove existing functionality.  It could be an option in Preferences - but iMatch already has many options and this doesn't seem like high value.

Implementing the composite tool logic in iMatch would be a bad idea (in my opinion) - lots of work with little value and likely to create new issues as metadata standards evolve.  I really like your approach of relying on ExifTool to do this type of work and you can do more valuable things (like face recognition, etc).  Unfortunately, sometimes ExifTool will do things that are unexpected as it is serving a very wide audience and is independent.

Your message idea in the help is a good simple solution - it alerts the user to the potential issue.    It may even be good to add a sentence or two in the metadata help about composite tags in general and that if one updates a composite tag and an underlying tag with different values, results may be unexpected.


This issue has had me do lots of digging and experimenting and I have one other thought that may solve this and some other metadata "weirdness".  I'll put it in a new topic so it is focused.

Thanks for your attention.

Michael

Michael

[jmsantos]

I come to this thread looking for information about the same problem (I guess, because I'm not sure I understood everything).

The thing is that I've imported some photos in IMatch, I enter basic metadata about authorship, copyright, etc. Then I place them in the Map Panel, do reverse geocode and write back. All in order. Now I make a modification in Sublocation and write back. Then the location disappears from photoshop:City and other IPTC Core location tags, but remain in IPTC Ext.

What have I missed, has there been any solution? As I say, I'm not sure I understood the whole thread.

[Mario]

You make a change to which tag and where? What is the exact tag key?
I recall a sub-location field in legacy IPTC data, but none named like that in XMP  metadata. Do you attempt to write a legacy IPTC tag?

How did you determine that some tags are emptied? When are they emptied and by which of your actions?

There more details you provide, the better.
For example, check the ExifTool output panel to see which tags are written because of your changes.

Do you use any non-standard metadata settings?
Does the file you write to has legacy IPTC metadata?

Metadata issues affected only one user (apparently) are often caused by non-standard metadata settings or the existing metadata in the written file or metadata propagation rules configured by the user or attempts to modify non-XMP tags which then get wiped/overwritten during write-back and metadata mapping.

I recommend to update only the tags shown in the GPS section in the Default metadata panel layout, or via the Map panel or reverse geo-coding.
Note that mapping between XMP and other metadata formats like legacy IPTC takes place during write-back only.

[jmsantos]

All data was entered in the Metadata Panel "Default" and Reverse Geocode. I try to repeat the steps that gave rise to that problem.

I think the source of the problem was when copying data between images with Copy-Paste attributes and data. In fear of not selecting all the metadata, I think I left some necessary things unchecked. It seems to me that this dialogue is not very unintuitive, it is not known specifically what is being copied. Perhaps a window similar to that of Lightroom and (I think) Photomechanic would be clearer for synchronizing metadata between images.

[Mario]

Copying metadata between files with Copy / Paste Attributes should be a rarely used operation. Especially if you are not sure what to copy.
The copy operation (if metadata is copied) is carried out by writing back the source file if needed and then running ExifTool to copy the tags and groups you have selected in the dialog. Plus mapping if required.

Usually you would use this to copy things like title, description, keywords and suchlike.
Complex tag combinations like GPS coordinates and location tags which require 10 or 20 tags to be copied make things more difficult. Copying XMP data only is usually safe, copying EXIF ore native GPS data should be avoided, since these are set from XMP anyway during write-back.

You can easily selected metadata tags between files in the Metadata Panel or ensure that all selected files have the same value(s) for specific tags (pen icon).

If you often copy the same tag combinations, create a Metadata Panel layout containing these tags, and then use plain copy & paste to copy the values show in your layout to any number of other files.
See Tips for Copying Metadata and Copying Selected Tag Values between Files for starters. You can create any number of these see/copy metadata panel layouts, to copy different combinations of tags as you see fit.

This does what you would do in Lr with the Copy Metadata dialog where you can scroll down a list of pre-defined fields and use check boxes for each tag to indicate which one you want to copy.
I guess this is what you refer to in your comment about Lightroom?

[jmsantos]

This does what you would do in Lr with the Copy Metadata dialog where you can scroll down a list of pre-defined fields and use check boxes for each tag to indicate which one you want to copy.
I guess this is what you refer to in your comment about Lightroom?

If something like. Although instead of copy, select fields and paste, I was referring to "Sync Metadata".

The dialog is the same, the difference is that I can synchronize the data of the focused photo with other selected photos, selecting only the data that I check. Also, in that dialog I see the data that is already in each selected field. It also indicates if any is marked but has no data, to add in that same dialog window.

I think it's much more intuitive than creating a metadata panel for every combination of tags you might need at any given time. Creating a metadata panel has many more options, I don't doubt it. But it is not as easy a task as checking or unchecking a field to copy or not between multiple photos.

[Mario]

When you select multiple files, the MD panel shows which files have the same value as the focused file, or different values.
Clicking the pen in front of the values you want to sync applies the value of the focused file to all selected files when you click save of pres Ctrl+S.



To sync multiple tags, just click multiple pens.
Not sure if the Lr approach is so much easier or intuitive.

Did you know about this feature? If not, it is explained in the Metadata Panel help: Synching Metadata between Files

[jmsantos]

Thanks Mario.

Yes, I knew about this pen option. It's easy and I've been using it ever since I discovered it in the help. I only see one problem: when selecting several photos I no longer see the content when they are different values. In the screenshot that I put before you can see the data of the focused file. It's just a small difference, but sometimes it can be important. That's why I was looking for an alternative.

I do not intend to make a comparison with LR. But recently in LR it was also added the possibility to see in the metadata panel the metadata content of the focused file when the data is different from the selected files.

I will study the option of using the metadata panel layout, but it seems too cumbersome and cryptic for this function. I have no doubt that once you have created a layout it is very easy to copy and paste data. However, checking a metadata field is not the same as selecting a tag from a long list and having to choose between "Composite\MWG-City" or "XMP-photoshop:City", for example.

[Mario]

I don't follow.

If you click the pen, you see the tag value for the focused file. If you click the pen again, you switch back to "Multiple Values"  (aka "don't sync).
So, if you click to sync, you see the value that will be synced before it will be synched.

Adding yet another mode like "If there are files with multiple values for a tag, somehow indicate that the values are different but still show the value of the focused tag" would be doable, but I don't see much of a benefit.
If you decide to sync a tag by clicking the pen, you see the value that will be synched. You can exclude the tag again from synching by clicking the pen again.
If you have 10 or 50 files selected, each file can have a different value. So we should actually see 10 or 50 values for the tag?

Not sure if your need to sync 5 or 50 tags for your files or how often.
That's a workflow I have so far never encountered. Sync yes, but quite rarely needed.

Not sure what your workflow is of why you have to sync metadata between files often.
I'm simple, I add the metadata when I process my files, and then never look back.
Except when I see a typo.
Then I select all affected files and enter the correct value in the MD panel. The value will then be written to all files.
Or I click the file with the correct value last (to make it the focused file) and click the pen. This saves typing.

In my experience, most people copy/sync the same tags all the time - if they need to copy/sync tags at all.
Creating a layout that holds all the tags to sync is a one time effort, and quite manageable. Unless you need to many sync different sets of tags to many different files, but I assume this is quite rare...?

If you have to sync many different tags for many different files so often that this becomes a burden, your workflow is maybe quite special.
When neither the easy sync feature in the MD panel nor a custom layout nor the Copy/Paste Attributes command can do what you want, feel free to open a feature request, explain your workflow, what change you would like to see etc. Other users can then comment and let me know if they have similar problems.

[sinus]

...
 I only see one problem: when selecting several photos I no longer see the content when they are different values.
...

This is the only "problem", what I do also running from time to time.
But I do not seen, how this can be solved in a clever way.

I click in such cases several images until it the metadata-panel shows "multiple values" and then I know, they before are the same.
Because in my case this is mostly in the headline or description I can see differences quite good in the File Window, because I made there the headline and desc quite big, so I see differences quite good.