XMP::iptcExt\PersonInImage is "Pending Metadata Write-back", but no pen icon

[mlavicka]

PersonInImage is imported after a reload of the database, and IMatch incorrectly sets it to pending metadata writeback, even though it has not changed.  Also, the pen icon does not display, which may be further indication that it is the same value.  Here are my steps:
0) Ensure all metadata is written to files in existing DB and also export People json file.
1) I delete existing DB and create new empty DB.
2) I import previously exported IMatch_People.json file so IMatch can match up the people when reloading images
3) I reload images and compact DB
4) Everything looks good with the photos, but somehow all of the files with PersonInImage are marked as "Pending Metadata Write-back".  The viewer does not show the pen icon, and the Metadata values all match what is in actual files.
Preferences:
  - Protect "unwritten metadata", "Rating and Label", & "existing XMP" all set to "No"
  - "Import XMP Face Regions" set to "Yes"
  - "Import IPTC PersonInImage" set to "Import tag value as-is"

[Mario]

Also, the pen icon does not display,

No pen in the File Window?

files with PersonInImage are marked as "Pending Metadata Write-back".

where do you see that, when there is no pen icon shown? In the collection?

Do you have automatic face recognition enabled?
Do the files have XMP face regions from a previous write-back?
In that case IMatch imports the regions, parses the tags, maps them to persons and sets the PersonInImage tag I guess (not worked on that for a while). I think it does not check the previous contents of the tag to find out if it is filled or has the same content IMatch tries to write. IMatch just sets it as part of the face recognition / import. It should also set other tags, like timestamps, XMP instance ids and suchlike.

Is PersonInImage the only tag that needs to be written? But to figure that out, you'll need the write-back pen tooltip, but you say it's not showing?

[Mario]

Any info to share? I'm not sure I understand the problem.
I've had a look at the code, and the PersonInImage seems to be only written when there is an actual change.
Maybe the order or persons has changed by your quite particular workflow with re-import from XMP and that's why the tag was updated and marked for write-back? Can you check that and let me know?
If a face is not detected, PersonInImage may differ. Or the face recognition runs, which means that PersonInImage will be updated multiple times. The order in which faces detection also plays a role, since PersonInImage is ordered by face order. Many variables at play here.

[mlavicka]

where do you see that, when there is no pen icon shown? In the collection?
- Yes I see that there is pending writebacks by looking at the collection of pending writebacks, but no pen icon is displayed.

Do you have automatic face recognition enabled?
- I do not have automatic face recognition enabled.  I only want to use the face data that is read in from the file.

Do the files have XMP face regions from a previous write-back?
  - All XMP face regions were created by iMatch from a previous write-back

I think it does not check the previous contents of the tag to find out if it is filled or has the same content IMatch tries to write. IMatch just sets it as part of the face recognition / import. It should also set other tags, like timestamps, XMP instance ids and suchlike.
- Yes it sets other tags, but those other tags don't cause it to appear in the pending writebacks collection.

Is PersonInImage the only tag that needs to be written? But to figure that out, you'll need the write-back pen tooltip, but you say it's not showing?
- Right, it is not showing.  To see what is causing it to be pending, I change some other metadata for the pen icon and tool tip to show up.  Then I see that it thinks this field has changed.

I've had a look at the code, and the PersonInImage seems to be only written when there is an actual change.
- My theory is that since I start with a fresh empty DB, and first re import the person json file, then when the PersonInImage is set there is some internal identifier that is different, even though the name is the same.

Maybe the order or persons has changed by your quite particular workflow with re-import from XMP and that's why the tag was updated and marked for write-back? Can you check that and let me know?
- There is no change to order of persons or number of persons tagged in the photo.  I literally do a writeback of all metadata, export the person json, start with clean db, import the person json. and then load in my photos
- I ensure that my settings do not do any automatic face recognition, so they should only get the face data from the imported file.
- This occurs whether there is one person, or multiple people tagged in the photo.  All my photos are regular jpgs with no sidecars files.

[Mario]

I only want to use the face data that is read in from the file.

When I recall correctly, this requires face recognition to be on. IMatch has to create an actual face fingerprint from the XMP region to make all the related features work.

Yes I see that there is pending writebacks by looking at the collection of pending writebacks, but no pen icon is displayed.

Show us a screen shot, that would be helpful.
If the "Pending Writeback" collection shows files, they are pending. Maybe you have switched to a File Window layout that does not show icons? Try the "Default" layout.

Please use the quote function as I did here (Se the toolbar at the top of the post editor). Or at least make the text you quote from somewhere in a different color. Else your posts are very hard to read and to see what you copied from where. I might have missed some answers or questions in your reply because of that. Very hard to see on a smart phone.

I have verified that PersonInImage is only set / marked as modified when IMatch stores a different value (different person names, different order of persons in the image).

When I remove and re-add an image with XMP face regions, the PersonInImage is validated, but not set or marked as modified. IMatch detects that there is no change. IMatch with default settings, face recognition on.

This means that your particular workflow with disabled face recognition in combination with XMP region import somehow causes this. This is not a common scenario and I have never tested this.

What does the PersonInImage tag show when you look at it in the Metadata Panel (e.g. in Browser Mode) or by using this variable in VarToy:

{File.MD.XMP::iptcExt\PersonInImage\PersonInImage\0}

Empty? Person names correct? Same order as in the file (Use the ExifTool Command Processor with "List Metadata" to see the face regions in the metadata of the image)...?

Please enable face recognition when you want the XMP face region import to work. The regions only contain a rectangle and a tag, no face data. But IMatch needs face data to work with faces.

Why do you only want to import XMP face regions and disable face recognition?
What is the purpose of your workflow? What do you want to achieve?

[mlavicka]

When I recall correctly, this requires face recognition to be on. IMatch has to create an actual face fingerprint from the XMP region to make all the related features work.

I have "Automatic Face Recognition = No".  I only want to have face regions for images where I have identified a face.

Show us a screen shot, that would be helpful. If the "Pending Writeback" collection shows files, they are pending. Maybe you have switched to a File Window layout that does not show icons? Try the "Default" layout.

Here is screen shot of corner of default layout showing pending metadata writeback.  The pen icons are included and do show if I change the metadata.

I have verified that PersonInImage is only set / marked as modified when IMatch stores a different value (different person names, different order of persons in the image).

I have verified that PersonInImage is the same, but maybe there is some internal identifier or hash that you are comparing that is different? Or maybe extraneous characters like space or CR?

When I remove and re-add an image with XMP face regions, the PersonInImage is validated, but not set or marked as modified. IMatch detects that there is no change. IMatch with default settings, face recognition on.

Yes. But the problem only comes when I start a new database and import the old people json file first.

What does the PersonInImage tag show when you look at it in the Metadata Panel (e.g. in Browser Mode) or by using this variable in VarToy:

It shows the same text, but I don't know about other ASCII characters like CR or space.

Why do you only want to import XMP face regions and disable face recognition?
What is the purpose of your workflow? What do you want to achieve?

I have 50,000 images in my DB and I find that managing faces becomes too unwieldly if I automatically perform face recognition.  I like to manually control which images will have faces identified.  My photos are stored on Onedrive, while my IMatch DB is on local storage.  I like to always write everything back to the actual files, so I can always recreate the DB.  I often switch between using my laptop for an extended period of time when I travel, and my desktop.  So instead of trying to keep the DB on a shared drive (which has its own complications), I just recreate it on my laptop when I travel, and then recreate it on my desktop when I return home.

[Mario]

I have "Automatic Face Recognition = No".  I only want to have face regions for images where I have identified a face.

I've tested this scenario this morning.

Automatic face recognition off. XMP face region import on.
An image with two faces and face annotations.
Write back. Check XMP face regions, tag and PersonInImage in the file. All correct.
Remove the image from the database.
Add the image again to the database again.
The regions and tags are imported, mapped to existing persons.

PersonInImage is checked but not marked as modified, since it matches the face annotations.

But, the file shows in the Write-back collection.
This does not happen when automatic face recognition is enabled, which verifies my initial theory.

So, this minor glich is only caused in this particular situation.
Importing XMP regions when face recognition is enabled probably shorts something that would usually remove the file from the collection after face recognition has run and found the metadata and annotations correct. Since IMatch is prevented by you from doing this, the file remains in the collection, but shows no pen.
I shall look into this for one of the next IMatch updates.

[Mario]

I have looked into this and fixed the problem.
The file is now correctly marked as pending, matching the contents of the Pending Writeback collection.
This was caused when the metadata of the file was imported and the region import. The region import deletes existing regions in the database and resets the PersonInImage tag. It set the file as pending, but a copy of the file record was cached and not updated and when written later, the pending flag was removed.

All this runs in parallel. Metadata import runs, then file import runs, then face recognition / face region into annotation import runs etc. All of this is staged and IMatch runs this in 8, 12, 24, 32 and more parallel threads for performance reasons.

The PersonInImage tag is filled when the region import / face recognition task is performed, which can be much later than the initial metadata import. So the tag is empty when the face regions are imported, marking the file as write-back.
The collection had it right, but the file pen had it not. This has been fixed.

For your particular use case: the files added to the new database or re-added to an existing database will show a pen, since PersonInImage has been dropped and re-built after the XMP region import and face recognition task is performed.

This behavior is by design. When it imports face regions, IMatch no longer "knows" that the file on disk may have XMP face regions. When XMP face regions are found, the existing PersonInImage data is dropped and, at some later time, recreated. Changing this behavior would be quite complex and "expensive". Since this is a rather rare issue caused by specific workflows only, I'll keep it that way. Maybe I have a good idea at some later point in time.