Option to defer Face Matching when working with Face Manager

[Tveloso]

When using Face Manager to "mass confirm" new faces for several persons, the background Face Matching process that starts following the first Face Manager session, seems to interfere with subsequent sessions, and results in Face Manager then becoming very slow to respond to user actions while that process is underway (and each Face Manager session queues a new instance of that Matching process - so Face Manager remains slow following the first execution).

Would it be possible to defer the Face Matching process (using either some timeout period - which resets if the user continues to launch Face Manager for other persons - or to not perform the Face Matching at all, while the People View is the active View)?

It seems that the Viewer already does something like this - it remains very responsive as we confirm/add faces in multiple files, and the Face Matching process does not start until we exit the Viewer.

[Mario]

It seems that the Viewer already does something like this - it remains very responsive as we confirm/add faces in multiple files, and the Face Matching process does not start until we exit the Viewer.

The Viewer restricts face matching to the files currently loaded in the Viewer. When you close it, face matching is done in the background for the entire database.

This ensures that faces of images currently loaded in the Viewer are dynamically updated as you confirm persons or change persons assigned by the AI.

When you make changes in the Face Manager (e.g. confirming or training faces) for person A, this may/will impact the state of unconfirmed faces for person A. Faces currently assigned to the person may be re-assigned to different persons. Faces not yet assigned to the person may, since the training data has changed.

What you see in Face Manager's unconfirmed / all faces ... sections to be wrong - unless the background update has completed. Delaying that until you close the Face Manager will make you work with "stale" or even wrong data, seeing probably wrong faces,  not seeing faces what you would see when the background update is finished.

I have never found this to be an issue. But that of course depends on the database size you work with, the number of persons and faces. And the performance of the computer you're working with. More details needed.

[Tveloso]

I suspect that the performance impact the Face Matching process has on Face Manager, is due to the number of Unconfirmed Faces I still have (nearly 6K):

    PersonManager Stats:
        Files with faces: 30252
        Persons: 398
        Faces: 74818
        Confirmed: 67571
        Unconfirmed: 5802
        Unassigned: 1445

...so I should probably work on getting those cleaned up.

But based on Mario's explaination:

It seems that the Viewer already does something like this - it remains very responsive as we confirm/add faces in multiple files, and the Face Matching process does not start until we exit the Viewer.

The Viewer restricts face matching to the files currently loaded in the Viewer. When you close it, face matching is done in the background for the entire database.

This ensures that faces of images currently loaded in the Viewer are dynamically updated as you confirm persons or change persons assigned by the AI.

...I tried launching Face Manager from the Viewer (instead of going to the People View first),  and I found that:

• Unconfirmed Faces shown in that Face Manager Session, are only those from the files loaded into the Viewer
• Face Manager remains responsive in each subsequent session when launched from the Viewer (F4)

...and that's exactly what I need.

Previously, after indexing a new batch of files, and running Face Recognition on them, I would first go to People View to confirm all faces for the people I knew were in those photos.  Now I'll proceed directly to the Viewer, and launch Face Manager from there (which is a much better way to work!).  Once again, I've learned something new in IMatch (or rather, learned the proper application, of a known feature), so I don't see a need for this FR now.

Thank you Mario.

[Mario]

The number of unconfirmed faces has a huge impact on face matching - because faces confirmed are ignored. The less unconfirmed faces you have, the faster the process is.

Performance also depends on the number of faces of course, and the number of persons to choose from when figuring out the best match for a face.

All this basically runs "in" the database, with special extensions I have written that are called by the database during this process. It's not easy to parallelize since there are many factors to consider.

I have reworked the entire background processing system for IMatch 2024/2025, to better utilize the large number of processor cores available in modern PCs.I expect substantiall improvements for indexing, metadata reading and face recognition performance from that. It just "flies" a lot better now. Still work to do, though.
I'm also looking into ways to make face matching faster, but that's very fast already.