[BBD] Propagation Issues - Faces (and Dot/Pins)

[PandDLong]

Note: I have not yet upgraded to IMatch 2025, if this issue could be fixed in the upgrade, let me know and I will bring forward my planned upgrade and test it.


I have the situation where I index a "better" copy of an image which is already in the database with metadata. Based on a recommendation in another thread, I have setup a file relation which will propagate metadata from the master to the version so I make the "better" copy a version of the existing image and do a write-back of the master.

The file relation is setup as:

  - Manual version
  - Select the following to propagate:
     - Dot, Pins, Rating and Label
     - All XMP Data

Faces doesn't really work:

1. The metadata for the regions is visible in the MWG segment
2. Running the Compare & Sync Metadata tool shows only a few differences which are expected (eg. GPS segment)
3. The annotation icon is not showing on the version
4. Opening the viewer does not show the face annotations (but it does for the Master)
5. Doing a write-back of the version, the region metadata is deleted


BUT, when I use the Exiftool Command Processor with standard preset 'list metadata' on the version right after propagation and then close the ECP, there is a pause in the File Window, both Master and Version darken for a few seconds and then the annotations icon appears on the version.  Opening the version in the Viewer, all of the Face annotations are visible and they stay through a write-back.

This behaviour is the same whether or not I select to propagate annotations in the versioning dialogue.

On a more minor note, the dot and pins do not propagate unless I change them in the Master after the relationship is established.  (Perhaps this is related, perhaps not).


Let me know if you need more info (or it tested in IMatch 2025).

Michael

[Mario]

I have never considering users trying to propagate face data this way.
What happens if you just write back the file so IMatch has to re-import it? It should find the face regions and import them into face annotations.

Or, maybe this is a "post write-back", IMatch does not do the face regions because it thinks they were created by itself during the write back, from face annotations it holds in the database - this is the usual scenario.

I'm sure when you do a forced rescan or a reload metadata it will work.
This is what IMatch does when you close the ECP, because it has no idea what you did in it.

Maybe IMatch should a forced face region import after each propagation / write-back, in case the user did what you did. But that could probably cause other issues I'm not aware of yet. I wonder how other software deals with all this complexity - just kidding. They don't bother.

[PandDLong]

As there is a propagation option for 'Don't copy XMP Regions (Face Data)', I had assumed that choosing XMP All Data would bring across Face Data (perhaps that option needs a slightly different label or tip).  

Should propagating Annotations help with this or does that have a different purpose?

Doing a write-back deletes the region metadata entirely (maybe because IMatch doesn't have annotations in the database?).

If I do a 'Force Update' rescan of the version right after propagation, it does create the face annotations in the database.  The 'Reload Metadata' and 'Normal Rescan' options did not.

A strange thing is that my workaround to open the ECP and run the List Metadata option stopped working to create face annotations (I had restarted IMatch in between my two posts).  


The Force Update rescan looks to be the reliable fix.

Michael

[Mario]

There are annotations to propagate (most of them are not faces, faces are just a specialty). There is XMP data to propagate, which does or does not propagate face regions. There is a write back, which causes a special "post write-back" re-import of metadata. During write-back, IMatch creates face regions from face annotations, but which don't exist in your case - because you did not create them. You just copied XMP metadata between files. But copying metadata between master and versions happens during write-back, and does not create annotations in the database.

Also, if you propagate face regions between images with different dimensions or crops, they will all be wrong. Which is why propagating face regions is not a good idea, unless you have a very controlled environment and workflow.

Not even IMatch can handle all the complexity and things users come up with. And I cannot make IMatch always "do all" or anticipate any workflow, propagation, metadata template, AutoFill or whatever users come up with. Users are way more creative than I am.

Keeping things simple and let face recognition run on each image. Which creates the annotations in the database, which creates face regions during write-back, with the correct dimensions and sizes.

IMatch cannot import face regions which don't exist. because they are creating during write-back by your setup - but without having actual face annotations in the database. Maybe propagate annotations and XMP, did you consider that? Not sure if this works. There is a limit, even for IMatch.

Feel free to add a feature request to support your specific scenario. If this is something other users have to deal with, they can like your request to let me know.

I prefer to keep things simple, not adding complexity to handle a specific problem one or maybe a handful of users encounter. Metadata handling is mindbogglingly complex, and piling even more special cases on top of it will do no good. Other software out there does not even get XMP right, and still sells tons of copies to happy users.

[PandDLong]

The options of what people will do is endless.   Now that I know a Forced Update recreates the face annotations, all is good. I agree that adding complexity on top of already very complex logic is not a good idea unless necessary - which in this case, it isn't.

These are vintage photos that are retouched/restored so the face annotations are still a good fit (and, if needed, it is easier and faster to move the annotations than to run face recognition and then confirm/assign people).

As part of my testing, I did select to propagate 'Annotations' but it made no difference to the outcome whether it was selected or not (perhaps that is related to the Dot/Pins issue - for which I may start a different thread later after I do more testing).

I truly appreciate the functionality and features of IMatch - it is an awesome product.  Some of the people I share my catalogued photos with are very impressed with what the software can do - I am still waiting on at least one of them to buy it though...

Michael

[Mario]

As part of my testing, I did select to propagate 'Annotations' but it made no difference to the outcome

I've created a manual version rule (for simplicity) and set it to propagate dots, pins, flags, rating, label and annotations.


1.
I create a version set of two files.
I run face recognition on the master image. A face is detected and a person is assigned.
The version receives the same face annotation and person.
OK.

2. I create a version set from two files. The master already has a face annotation.
The version does not change, which is expected.
Propagation takes place when the master is changed or written back.
So I select the master and press <F4>, <P>to explicitly propagate.
The version now has the face annotations.
OK.

3. For the version set of 2. I move the face annotation of the master slightly. The annotation of the version is updated accordingly.
OK.

4. Same set, I delete the face annotation in the master. The face annotation in the version is also deleted.
OK.

5. Same set. I select the master and run face annotation. The version also has the face annotation.
OK.

6. No issues at all with propagating rating, label, pins, dots or flags. The collections are in-database only and not affected by metadata at all.

Now, you mention that you also propagate all XMP metadata. Which complicates things considerably. All XMP metadata also contains face regions, obviously. Metadata is propagated only during write-back (except for some exceptions like rating and label).

7. I start with a fresh set. The master has a face annotation, the version has none.
I add a headline and description to the master.
This triggers in-memory propagation and the version now has the same face annotation!
It does not have headline and description, since XMP metadata is propagated during master write-back.
I write back the master.

The version still has the face annotation and now has the same headline and description as the master! OK.
Looking at the metadata of the version, it has a full set of XMP regions. OK.

This makes me believe that this works fine in general.
Repeat my tests and see if and when you find a difference in outcome. Then start from there.

I see no separate thread about dots and pins? Link?

[Tveloso]

As part of my testing, I did select to propagate 'Annotations' but it made no difference to the outcome

I've created a manual version rule (for simplicity) and set it to propagate dots, pins, flags, rating, label and annotations.

1.
I create a version set of two files.
I run face recognition on the master image. A face is detected and a person is assigned.
The version receives the same face annotation and person.
OK.
.
.
  <details of Mario's other tests removed from this quote>
.
.
This makes me believe that this works fine in general.

I can confirm that propagating Annotations is working fine for me also.  Perhaps using the option to  propagate all XMP is what's causing this to not work for Michael?

These are vintage photos that are retouched/restored so the face annotations are still a good fit (and, if needed, it is easier and faster to move the annotations than to run face recognition and then confirm/assign people).

The particular Version Set where I do propagate Annotations, is very much analogous to this.

Mine are iPhone images, where the "Portrait Mode" has been used, resulting in two files with identical pixel dimensions.  The Original becomes the Master, and the "in-Phone Edit" (which has a fake bokeh effect applied to it) becomes the Version.  The Version Rule that governs this set is configured to propagate Annotations (and a few specific XMP Tags), and is working fine.

Also, if you propagate face regions between images with different dimensions or crops, they will all be wrong. Which is why propagating face regions is not a good idea, unless you have a very controlled environment and workflow.

I added an FR some time ago:

https://www.photools.com/community/index.php/topic,14379.msg100965.html#msg100965

...that I think could be helpful in this scenario. 

That FR only has one like so far, so I thought I'd mention here.  It asks to have an option to propagate Face Annotations as Face Links, which would allow these types of Versions to "receive" the Master's Face Data without the need to run Face Recognition separately on the Version.

[PandDLong]

This is all very helpful.

I will carve out some time and test the dot, pins and annotations propagation more thoroughly.   

In the original post, I made a reference to the dots/pins not propagating unless I change them in the Master,  but it was just an observation at the time.  I don't like to start a thread until I have done some purposeful testing and different scenarios.  Which I will do in the next couple of days now that I have some examples of what should work.

Michael

[Mario]

In the original post, I made a reference to the dots/pins not propagating unless I change them in the Master,

1. Propagation is performed when you change something in the master (e.g. adding/changing a dot).
2. During write-back for metadata
3. When you force propagation by selecting the master and pressing <F4>,<P>.

[Mario]

Perhaps using the option to  propagate all XMP is what's causing this to not work for Michael?

I tried this and it still works. I used the same settings as the OP for my tests.

[PandDLong]

In the original post, I made a reference to the dots/pins not propagating unless I change them in the Master,

1. Propagation is performed when you change something in the master (e.g. adding/changing a dot).
2. During write-back for metadata
3. When you force propagation by selecting the master and pressing <F4>,<P>.

Well, this is embarrassing. 

I missed the need to run that command <F4>,<P> to get an initial propagation of the database elements.  I had thought it was supposed to auto-magically do that initial alignment when I established the relationship between master and version.

Works perfect as designed.

Thanks so much.

Michael

[Mario]

IMatch does not force a write-back of the master when a new version is added to it (which would also force a write-back of all existing versions). Users would complain and there would be words.

[PandDLong]

I understand not forcing a write-back - there would be many, many words!

i just thought the database elements (eg. dot and pins) would auto-magically propagate - I had no reason to think that way (I do read the Help constantly - it is always open) so totally my issue.

All good.

Michael

[Mario]

i just thought the database elements (eg. dot and pins) would auto-magically propagate - I had no reason to think that way (I do read the Help constantly - it is always open) so totally my issue.

Just tested this. For a master with a bookmark, red dot, green pin, rating = 3 and a red label, I create a new version in Windows Explorer.

When I rescan the folder, the new version is found, linked to the master and the new version gets the same rating, label, bookmark, dot and pin as the master.

[PandDLong]

That's interesting.

I do all of my versions manually, perhaps I should set them up with detection rules - that should save me a step (or two).

Choices, choices - one of the great things of IMatch is that not only can it do so much, there is usually more than one way and the user can choose whatever works best for their workflow.

Michael

[Mario]

Manual versions are special.
When a new version is found during import, IMatch internally triggers a write-back of the master and a very complex propagation operation in the database (think about, e.g., version chains where links are masters of other files).

Doing all that when the user creates a manual relation was too much complexity.
The user can always do a <F4>,<P> (Propagate to versions in the context menu) on the master if he wants to propagate the data right now, not waiting for the next write-back.

I have improved this a bit for the next release by triggering a propagation of non-metadata items (collections) and rating/label when the user creates a manual version link. Other metadata is propagated at write-back of the master, as with any other versions.