Face Arrangement

[hluxem]

The Imatch standard categories shows the following for face arrangement {File.Faces.Arrangement.Type}:


The category "No Face" does contain images with face annotations. I can't find anything in the help about type "No Face", what does the type "No Face" stand for?  

Thanks,

Heiner

[hluxem]

Screenshot attached

[Mario]

This is a data-driven category anf the "No face" is the "Other" element.
It uses the {File.Faces.Arrangement.Type} variable.
What does the variable return for the files in the "No Faces" category and why? Use the VarToy app to check.
You can disable the Other element for the category.

[hluxem]

Checked the data driven properties as well as the variable with var toy before posting. See Screenshots attached. I have 96 files in the "No Faces" category out of ~ 88000 in the data driven category. About 464K files in the database.

The files in the "No Face" category have between 1 and 3 faces, normal annotations or manual annotations. I will run a diagnosis next, maybe that changes something. 

I can send you a file if that helps. But I guess you will see in the variable definition when the variable returns "No Faces".

What does the variable return for the files in the "No Faces" category and why? Use the VarToy app to check.

It returns "No Face". For files without a face annotation nothing is returned.

This is a data-driven category anf the "No face" is the "Other" element.

The definition says not to use the other element, "No Face" is returned from the variable.

[Mario]

Run a database diagnosis to see if there anything wrong.
The face arrangement attributes for files are produced when a file is analyzed during face recognition and stored in the database. The variable uses that information. Which means that, apparently, something for these files has been analyzed wrong or stored wrong. Or face recognition was not run on these files?

See if you can reproduce this issue by

1) copying one of the files into an empty folder while IMatch is not running (Windows Explorer).
2) adding the folder to the database.
3) run face recognition if it is not set to auto
4) test the variable in VarToy for the file. Is the result correct?

If not, it's something with the file, which gives me a chance to try it out here.

Anything that's different with the wrongly analyzed files?

[hluxem]

Run a database diagnosis to see if there anything wrong.

Everything good

1) copying one of the files into an empty folder while IMatch is not running (Windows Explorer).
2) adding the folder to the database.

After adding the files, the variable showed the right values like "One Face" ect.

Which means that, apparently, something for these files has been analyzed wrong or stored wrong.

That seems to be the issue.

The solution for me is to delete all face annotations for each file. No write back so the person tags remain in the file. A rescan with "Forced Update" will then read the face tags in the file. After this the variable shows the right values. 

Just rescan with the option "Reload Metadata" is not enough, I believe this will not read the person related metadata. It's also important to delete the face annotations before the forced rescan, just a forced rescan will not correct the issue.

what does the type "No Face" stand for?  

I guess the answer is that there is something wrong with the file. 

[Mario]

IMatch does not re.import XMP face data when a file already has face annotations. Which is why you have to delete the face annotations before re-importing the metadata.

Good that you found a solution. Seems to be a rather unique case and what has caused this is unknown.

[philburton]

What about the situation where existing photos have had a Facial Recognition scan in Lightroom?  Are those results used by iMatch?  Do they need to be deleted (in Lightroom) before the photos are imported into iMatch?

[Mario]

Are those results used by iMatch

Yes. Also faces stored by Picasa and other DAM systems.

See Working with XMP Face Regions

[Tveloso]

I see this here as well.

I have over 300 Files that contain Faces, but are in the No Faces child Category, of the Face Arrangement Category.

The vast Majority of them are Versions, that have had Face Annotations propagated to them from their Masters (but a few are not part of a Version Set).  So perhaps propagating Face Annotations plays a role?

I took one of these files, and tried deleting the Annotations, and doing a Forced Update, as discussed here, but for me the {File.Faces.Arrangement.Type} variable returned "No Faces" again afterwards.

The following was true for the Sample File:

• It contained two "normal" Face Annotations
• The {File.Faces.Arrangement.Type} variable was returning "No Faces"
• The Person Records for the two Persons had generated three Keywords for the file (and these were the only Keywords for the file)
• The File was not Pending Writeback

After deleting the Face Annotations via the Viewer (Ctrl+A, and Delete), the following was true:

• Variable {File.Faces.Arrangement.Type} now returned nothing
• File became pending for writeback (for XMP::Lightroom\HierarchicalSubject, XMP::dc\Subject, and XMP::iptcExt\PersonInImage)

After a Force Update:

• Variable {File.Faces.Arrangement.Type} returned "No Faces" again
• File was no longer Pending Writeback (I was surprised by this - I expected those three tags to still call for a Writeback, since they had now changed from no value to having values)

[Mario]

After a Force Update:

• Variable {File.Faces.Arrangement.Type} returned "No Faces" again
• File was no longer Pending Writeback (I was surprised by this - I expected those three tags to still call for a Writeback, since they had now changed from no value to having values)

When you force an update, you wipe everything from the database and then reload the file. If IMatch does not produce "new" tags or values (e.g. Date Subject Created) this is normal.

Can you repeat this by copying the file into a new folder outside of IMatch and then adding that folder.
If this is caused by a particular file, I have something to work with.

I will check if propagating face annotations can somehow cause issues with the face arrangement data.
But even moving a face annotation slightly in the Viewer or removing and re-creating it also re-creates the face arrangement data.

[Tveloso]

Can you repeat this by copying the file into a new folder outside of IMatch and then adding that folder.
If this is caused by a particular file, I have something to work with.

Unfortunately, when a folder containing a copy of the file was newly indexed, the {File.Faces.Arrangement.Type} variable returned the correct value ("Two Faces") for that file (while the original continued to show "No Faces").

Just for completeness, I report the following (but this can probably be disregarded):

When the copy of the file was first indexed, no Face Annotations were created (even though the file contained Face Regions), so the variable returned nothing.  This is because I have the Import of Face Regions turned off:

   

So for the test described in Post #9 above, the Face Annotations would not have been loaded from the file (but the Force Update operation must have caused them to be propagated again from the Master - because they were there, following the Force Update).

I turned the Import of XMP Face Regions on momentarily for the sake of this test here (then turned it off again).

My case might be a slight departure from that of hluxem, since I cannot "fix" the "No Faces" condition as he can, and probably the versioning I have in place adds another wrinkle...but it definitely seems related, so hopefully the behavior I'm seeing can give a clue as to what's happening.  I noticed something new with this, related to the Master File...

The Master of the Version File that I manipulated for the test in Post #9 became pending for WriteBack also (even though it was not touched), showing the following to be in need of WriteBack:

   

So I did that WriteBack in order to put things back the way they were, then repeated the original test (with the Version File) while the Master and Version were both in a Result Window.

The initial state was:

Master

• Contained two "normal" Face Annotations
• {File.Faces.Arrangement.Type} returned "Two Faces"
• The expected Keywords (from Person records) were present
• The File was not Pending Writeback

Version

• Contained two "normal" Face Annotations (created via propagation, not face recognition)
• {File.Faces.Arrangement.Type} returned "No Faces"
• The expected Keywords (from Person records) were present
• The File was not Pending Writeback

I deleted the two Annotations from the Version File in the Viewer, and afterwards:

Master
Unchanged

Version

• Annotations were now gone
• {File.Faces.Arrangement.Type} returned nothing
• No Keywords
• Pending Writeback for for HierarchicalSubject, dc\Subject, and PersonInImage

Following a Force Update of the Version File:

Master

• Still contained the same Annotations and Keywords
• Now pending Writeback for RegionInfo and InstanceID

Version

• Contained two "normal" Face Annotations (created via propagation, not face recognition)
• {File.Faces.Arrangement.Type} returned "No Faces"
• The expected Keywords (from Person records) were present
• The File was not Pending Writeback

So the Version returned to the initial state following the Force Update, and the Master was updated to be in need of Writeback. 

Since the option to Import XMP Face Regions was off during the Force Update of the Version, they must have been propagated again from the Master (and this somehow caused the Master to now be in need of WriteBack)

After Writing Back the Master, both files went to the original state

[hluxem]

since I cannot "fix" the "No Faces" condition as he can

Unfortunately, I fixed all my files so can't test anymore.

After deleting the Face Annotations via the Viewer (Ctrl+A, and Delete), 

If I understand this correct, you delete the face annotation in the viewer. I used right click - Face Annotation & People - Delete Faces - Delete All Faces. It's easier as you can select multiple images and it may be different than deleting the face annotation squares.
You may also want to see if you can fix the versions by temporary pausing the relation rule.

[Mario]

The Master of the Version File that I manipulated for the test in Post #9 became pending for WriteBack also (even though it was not touched), showing the following to be in need of WriteBack:

How can this happen? IMatch does not modify face regions in a master when you propagate versions.
The MWG::RegionInfo is the ExifTool name for the XMP face regions, and when these are modified, I wonder by what.

Following a Force Update of the Version File:

With"forced update" you mean you used Shift+Ctrl+F5 and forced IMatch to wipe out all metadata for the version in the database and then re-import what's in the file?

This breaks metadata propagated from the master in the database. To set things straight afterwards you need to manually propagate from the master to the "forced update" version manually.

Does the version in your case contain XMP face regions? Is the import of XMP face regions enabled in E > P > Metadata 2 (default). In that case IMatch will re-import the face regions from the XMP in version during the forced update and maybe this does not update the previously wiped face arrangement data?

I tried that here and the face arrangement data was still correct. Even removing a file from the database and adding it again (XMP face region import enabled) restored the correct face annotation info.

When you slightly move a face annotation in the version, does the variable correct itself?

Since thew master (!) metadata changed when you forced an update of the version, it seems that there are some issues with your file relations - e.g. the master sometimes becoming the version?

I don't see how face regions in a master can change when you perform a forced update on a version.

[Tveloso]

If I understand this correct, you delete the face annotation in the viewer. I used right click - Face Annotation & People - Delete Faces - Delete All Faces. It's easier as you can select multiple images and it may be different than deleting the face annotation squares.
You may also want to see if you can fix the versions by temporary pausing the relation rule.

Thank you.  I tried this, and the "No Faces" condition was fixed once I disabled the Relation Rule.

I first tried deleting the Faces via the File Window Delete All Faces command (without making any other changes), and following the Force Update, the File returned to its "No Faces" State.  But After I disabled the Relation Rule, and set Import XMP Face Regions to Yes, another Delete All Faces, followed by a Force Update now had the variable reporting "Two Faces"

Interestingly, after I reactivated the Relation Rule (and did an F4,R on the Master to re-establish the Version set), a forced propagation from the Master (F4,P) once again changed the Version to reporting "No Faces".  So it does seem that propagation is one cause of this.

Following a Force Update of the Version File:

With"forced update" you mean you used Shift+Ctrl+F5 and forced IMatch to wipe out all metadata for the version in the database and then re-import what's in the file?

Yes, exactly right.  It is at this point that the Master is set to needing a Write-Back.  The Pencil appears on the Master immediately - even while the Version is still being processed by the Shift+Ctrl+F5, Force Update.

Does the version in your case contain XMP face regions? Is the import of XMP face regions enabled in E > P > Metadata 2 (default).

The Version File does contain Face Regions (as originally written by IMatch), but I keep Import XMP Face Regions set to No in E > P > Metadata 2...(I turned it on momentarily, only during the first test described in Post #11).

When you slightly move a face annotation in the version, does the variable correct itself?

Yes, moving even just one of the face annotations slightly causes the variable to now return "Two Faces".  If I propagate again from the Master, the Version returns to reporting "No Faces".

Since thew master (!) metadata changed when you forced an update of the version, it seems that there are some issues with your file relations - e.g. the master sometimes becoming the version?

I hope that's not the case...I feel like my File Relations have been working well.

I don't see how face regions in a master can change when you perform a forced update on a version.

It does seem that this is definitely happening though.  Doing a Force Update on the Version (even without first deleting the Face Annotations there), causes the master to be set to needing Writeback.

I recorded a Debug Log while I was performing the subsequent tests in Post #11, and sent that to the support email.  So hopefully there will be something there that will explain how the Master gets updated that way.

[Mario]

When this depends (apparently in some way) on propagation, what do you propagate, exactly?
And from which to what, with which file name patterns?
This will help me to setup the same for testing.

Also:
- State of XMP Face Region import (E > P > Metadata 2) for this test?
- Automatic face recognition enabled?

Face regions are part of XMP and IMatch writes them.
When you propagate XMP, faces will be propagated from the master to versions.
In your case, you say the master becomes pending, with the XMP face region tags when you do a force-rescan of a version! But this process has no impact on other files, until they are a version.

If a version comes new into the database (or a forced update is done), IMatch must  propagate from the master to the new version to ensure the data in the version is correct. This involved the master being written, then data being propagated from the master to versions. Maybe a side effect of this.

You also disable XMP face region import - why?
This is on by default so IMatch can use work done by smart phones or other software. It also ensures that faces are restored ween an image is re-added after having been removed from the database - or after the user does a force update for some reason. Or after a propagation of XMP data from master to version!

I guess this is somehow caused by face annotations being propagated, XMP face region import being disabled or something. There are always combinations of things to propagate and options people choose that I have never anticipated or which would be to complex to support.

Maybe I can reproduce this somehow using your setup.

[Tveloso]

When this depends (apparently in some way) on propagation, what do you propagate, exactly?
And from which to what, with which file name patterns?
This will help me to setup the same for testing.

I included a ScreenShot of the Relation Rue for this Version set in the email I sent, but it didn't show everything that's Checked to propagate (and only showed that propagation of Annotations was selected).  The following items are checked in the What to propagate list:

• Annotations
• Rating
• Label
• XMP Title
• XMP Description
• XMP Headline
• XMP Author
• XMP Keywords
• XMP Location Data

The FileName Patterns are:

    Master Expression . . . : ^(img_)*[0-9_-]+.(jpg|jpeg|heic)$
    Replacement Expression  : <empty>
    Link Expression . . . . : {name}_v0\.(jpg|jpeg|heic)$

The FileNames I have been testing with are (I included these files in the email as well):

    Master . . . : 2024-07-05_112223_620_01.HEIC
    Version  . . : 2024-07-05_112223_620_01_v0.HEIC

(*Note: the Master Expression includes zero or more instances of the string "img_", because these files start out with FileNames of the form IMG_nnnn.HEIC and IMG_nnnn_v0.HEIC when they're first indexed, and I want them to be detected as a version set both before and after they have been processed by the Renamer)

Also:
- State of XMP Face Region import (E > P > Metadata 2) for this test?
- Automatic face recognition enabled?

Import XMP Face Regions and Automatic Face Recognition were both No during the test.

You also disable XMP face region import - why?
This is on by default so IMatch can use work done by smart phones or other software. It also ensures that faces are restored ween an image is re-added after having been removed from the database - or after the user does a force update for some reason. Or after a propagation of XMP data from master to version!

I have had this off since the early days of Face Recognition in IMatch...it used to be just one flag that controlled whether or not IMatch "processed" existing Face Regions, and at some point early on, you separated the options for Import and Export of the Region Data - and I have had the Import side disabled ever since.

I did this because I didn't like the Annotations that my iPhone had created, and preferred Annotations created by IMatch's Face Recognition.  In many cases the Phone-created Annotations were just too large, and when there were two faces very close together, it was sometimes hard to tell exactly which face a given annotation was actually enclosing.

But I guess I can achieve the same results if I let the iPhone Regions get imported, and then if I don't like them, run Face Recognition in IMatch, and uncheck the Ignore Images with Existing Face Annotations option.

So I'll turn that option back on...(it's been a few years since I have tried letting the original iPhone Annotations into the Database - so maybe things are better there now)...

[Mario]

You propagate annotations, but no XMP face regions.
You don't import XMP face regions and automatic face recognition is off.

This probably causes several issues,since copying annotations does not necessarily recreate all the info and metadata that is produced when IMatch performs face recognition or imports existing face regions. One of the combinations of propagation rules and disabled features that I never anticipated. Maybe I can reproduce this here and decide whether or not I support your specific combination or just require to have import for face regions on and/or automatic face recognition enabled to make this work.
I'm against piling special case on top of special case, and a note and warning in the help for propagation is written quickly.

I'll post again when I've had time to analyze this. I'll move it to bug reports and give this a medium / low rating, since it seems to affect one user only.

[Mario]

I could already fix the "Face Arrangement" issue.
IMatch was clever enough to determine that a face annotation is propagated and it copied the face and all that. It even called the routine that re-evaluates the face arrangement for a file. But it used the wrong number and so the face arrangement of the file receiving the new face annotation during propagation was not updated.
As you maybe can imagine, this stuff is complex.

As for the other issue with the master getting takes marked as pending when a version is force-updated, I'll look into sometime later. Force-updating a version causes propagation, which causes a write-back of the master and some other operations. Since annotations are propagated, they might be re-applied to the master and this causes face regions to be rewritten or something.
Propagating annotations is probably something not many users do.

[Tveloso]

Thank you so much Mario!

As you maybe can imagine, this stuff is complex.

I have no doubt about that!

As for the other issue with the master...I'll look into sometime later.
...
Propagating annotations is probably something not many users do.

And Force Updating a Version File in a version set, even less so.  So this is absolutely an edge case that should have a low priority.

Thanks again

[Mario]

I've fixed the "master becomes marked as pending write-back" too..