Is it possible the MWG::Regions\RegionInfo structure is referenced accidentally?

[Tveloso]

There have been a few times when I've seen IMatch starting a Face Reclustering at an unexpected time.  I was certain that nothing was in the background processing queue, and a change I made to a File's data appeared to cause an unexpected Face Matching operation.  I'm sure there are probably instances when Face Reclustering is needed, following some seemingly unrelated user activity, but during these past instances, where I was surprised that IMatch was doing it, I couldn't understand why.

Today, I noticed that for a handful of files, where I had made changes to a few GPS Dest tags, the MWG::Regions\RegionInfo structure was among the tags that were now pending for Write-Back for those files:

    You cannot view this attachment.

These files were not previously pending Write-Back, and I changed only these 5 tags for them (clearing their values):

    XMP::iptcExt\LocationShownGPSLatitude\LocationShownGPSLatitude\0
    XMP::iptcExt\LocationShownGPSLongitude\LocationShownGPSLongitude\0
    XMP::iptcExt\LocationShownGPSAltitude\LocationShownGPSAltitude\0
    XMP::exif\GPSImgDirection\GPSImgDirection\0
    XMP::exif\GPSImgDirectionRef\GPSImgDirectionRef\0

...yet the ToolTip for the Writeback pen included the MWG Regions structure (as shown above).

I know that a great deal of work went into changing the treatment of Location Data when the new 6 IPTC Location MD Panel Layout was introduced.  That Layout includes the World Region Tag, in both the Shown and Created groups:

    {File.MD.XMP::iptcExt\LocationCreatedWorldRegion\LocationCreatedWorldRegion\0}
    {File.MD.XMP::iptcExt\LocationShownWorldRegion\LocationShownWorldRegion\0}

Is it possible that when changes are made in that area, and IMatch must manage mapping the Location data into all of the other places it must be synched with, that somewhere in the code, an inadvertent reference is made to MWG Regions (simply because both sets of tags include the word "region", so it was inadvertently included)?...

I know this is a pretty nebulous question (and is based on some pretty wild conjecture), but I thought I should ask it anyway.

[Mario]

I have no idea. If you want me to investigate, please open a bug report. This helps me with keeping track and planning.

Fuzzy things like this which happen for one user only, and probably only with your database, metadata settings, existing metadata in the file and database, workflow, maybe version propagation and all that can take hours or even days to analyze, often without any result. I have about 10 of similar "one user only, non-repro issue" in my pipeline at the moment. I process them as they come in, on prio 2, since it can take so long to analyze them, and often the result is "no repro".

If you open the bug report, please include information like
+ Your Metadata and Metadata 2 settings (screen shot)
+ Details about file versions and propagation settings (detailed)
+ Where/How you have changed the tags (Metadata Panel, by other means)
and everything else that may allow me to reproduce this.

I see no real harm in this, anyway. The file is marked as write-back, and IMatch will write the XMP block anyways. Writing a few tags more does not count or slow things down.

[Tveloso]

I see no real harm in this, anyway. The file is marked as write-back, and IMatch will write the XMP block anyways. Writing a few tags more does not count or slow things down.

Makes perfect sense, and the MWG Regions data looked proper following the write-back.  I was just wondering if, since MWG Regions might be being included accidentally in this case, that it could possibly have some other implications elsewhere in IMatch.

I was going to go ahead and open a bug report as you suggested, just in case it could help to identify something that was maybe really a bug, but I could not reproduce the behavior with the file I tested with today. 

So I went back and checked the files that this was happening with yesterday (files from 2023), and there, I could re-produce it reliably.  But when I checked other files that were not part of the group where I was seeing this (photos taken just a few days later), I again could not repro it.

Given that I can only reproduce this with a specific set of files, it's probably not worth your time to look into it, and I'll forgo posting the bug report.  But just for completeness, here are the repro steps that produce this behavior in the offending files:

In a file that is currently not pending writeback:

    You cannot view this attachment.

...and contains GPS Lat, Long, and Altitude (but no Dest values) in the GPS section of the 1 Default MD Panel Layout:

    You cannot view this attachment.

...set GPS Image Direction Ref to True North (this is one of the values I originally cleared for the file):

    You cannot view this attachment.

The File now becomes pending for write-back, but instead of just that one tag, the MWG Regions group is included:

    You cannot view this attachment.

But again, if I do the same for other files, the "issue" does not happen.  So it's only a specific set of (maybe 100 or so) files that this is happening for...

[Mario]

Maybe there was an upgrade / change in IMatch since you've last written the files? When preparing the write-back data IMatch notices something out-of-version in the metadata, upgrades it on-the-fly when preparing the data for write-back and then pushes everything out. This can happen occasionally. Most users would not even notice when some extra tags are marked as pending when this happens, or don't bother when they do.

IMatch is constantly evolving and I see several changes to how regions are filled over the years.

[axel.hennig]

As Tveloso wrote this happens to him just to a subset of his files.

I've tried to reproduce this (just with one jpg-image), but wasn't able.

When I changed "{File.MD.XMP::exif\GPSImgDirectionRef\GPSImgDirectionRef\0}" from "nothing" to "True North" only that tag needed to be written (and not the MWG Regions group). Same if I changed the file back again to "nothing" and then again to "True North".

[Tveloso]

Thank you for checking Axel.

It must be as Mario wrote, that changes to how regions are filled, that have taken place over time in the IMatch code base, might be somehow triggering this behavior for these particular files.

The thing is, for any one of them, the "extra" pending tags (the MWG Regions) are consistently included as pending, each time I change that Image Direction Ref tag for the same file.

I might try some more testing tomorrow with a file that this happens for.

1.) Maybe try updating something other than a location-related tag, to see if MWG Regions still gets included (to see if the notion that changing location data, which might then cause a reference to World Region tag(s), which then inadvertently brings along MWG Regions, is even a thing - it's a pretty weird notion, I know)
2.) Try moving the Face Annotations slightly in the Viewer, so the faces are recreated (to see if the "issue" then goes away).

But all of that just for the sake of curiosity.  I'm perfectly happy to let this lie, since it seems to only be happening in my IMatch installation (and only for a few files therein).

[Mario]

The thing is, for any one of them, the "extra" pending tags (the MWG Regions) are consistently included as pending, each time I change that Image Direction Ref tag for the same file.

Open a bug report and provide that file (or more, if you have more). 
Provide the steps you perform, e.g. where and how you change the tag.

As a first test:

If you remove the file from the database (after writing back) using the "Remove from Database" command in the context menu of the File Window, and then rescan the folder to bring the file back into the database, is the problem still reproducible? In that case it's caused by something in the image metadata in combination with your metadata settings. This could be a reproducible case.

If I can reproduce it, I can look into it for a future IMatch version. I don't consider this harmful, so this has a low priority. I will look into it. I have never experienced this, no other user has reported this, it only happens with some of your files, etc. 

[Tveloso]

As a first test:

If you remove the file from the database (after writing back) using the "Remove from Database" command in the context menu of the File Window, and then rescan the folder to bring the file back into the database, is the problem still reproducible? In that case it's caused by something in the image metadata in combination with your metadata settings.

Mario, I set out to do that this morning, but had to leave before I could actually complete it.  I'm away for the weekend, the files in question are on a NAS, and I didn't have the forethought to copy them local before leaving.  I'll post the bug report as you requested on Tuesday, and will send a sample file.

But while I was working on this this morning, I came across what might be? a (maybe?) related bug.  I'll post that one later tonight...

[Tveloso]

But while I was working on this this morning, I came across what might be? a (maybe?) related bug.  I'll post that one later tonight...

I was mistaken about this.

I'll post the bug report for the original "issue" on Tuesday.

Thank you Mario.

[Tveloso]

As a first test:

If you remove the file from the database (after writing back) using the "Remove from Database" command in the context menu of the File Window, and then rescan the folder to bring the file back into the database, is the problem still reproducible? In that case it's caused by something in the image metadata in combination with your metadata settings.

The behavior remained after removing the file, and rescanning to bring it back into the database.

I also tried changing other Metadata for the file (I changed Description and Headline), and this too caused MWG Regions to become pending, along with those changed tags.  So this had nothing to do with Location Data as I was speculating.

I then tried moving the Face Annotations slightly in the Viewer (to see if that might "reset things", and remove this behavior).  But the behavior remained.

Then I discovered that there were other files within this group of files that I originally thought all exhibited this behavior, that did not.  So it was actually much fewer than the hundred or so files I was suspecting. 

With further inspection, I discovered that all of the files with this behavior, were governed by a Relation Rule that propagates Face Annotations:

    You cannot view this attachment.

I was working only with Masters (or files not part of a Version Set) during my testing, and I found that:

• Files not part of a version set did not have the behavior
• Master Files governed by rules that did not propagate Annotations did not have the behavior
• Only Masters governed by the rule that propagates Annotations have the behavior

So in the end, I'm quite sure that this is a "works as designed".

I'm so sorry Mario, to have wasted your time on this, by being such an inquisitive nut.

[Mario]

You're welcome.

Versioning and metadata propagation is a very powerful feature. And very useful.
But, as I mention in the help, it is possible to shoot yourself in the foot. Or both feet. Big time.
By propagating e.g. native EXIF metadata without understanding what this may cause. Or, as in your case, propagating annotations. Or copying all XMP data, including Lightroom XMP editing data to a different file. So many potential pitfalls...

Metadata is a complex matter (believe me, I've spent a lot of time with this). And that the "standard" is interpreted in different ways by different applications and that many, even professional, applications out there have really crappy metadata support adds to the complexity.

A recent example: I open a PNG file produced by an AI to make some small corrections in a renowned image editor. The AI has dutifully recorded the prompt and settings in PNG metadata (very helpful!). After saving the image, this metadata is gone. No explanation, no warning, just gone. Why a commercial product (not from Adobe!) just wipes metadata when re-saving a lossless format like PNG escapes me.

This should not happen in 2025.

But they just don't care. And no "reviewer" in the press or YouTube ever considers how good metadata handling and processing is...it's always all about filters and sharpening and noise reduction and AI, never about how safe your metadata is with these applications.

Luckily, from experience, I use a metadata template in IMatch which copies the relevant data from PNG tags into the XMP Instruction tag for safekeeping. I run this before editing. Even if the other application wipes the PNG metadata on save, IMatch has it in the database and keeps it safe.