Temporarily not use a person in face detection

Started by WebEngel, June 19, 2023, 09:28:27 PM

Previous topic - Next topic

WebEngel

Use case: Kids have friends, but they don't meet one former friend anymore.  The friendship may be revived at some point in time.

Assume there was Max who was on several birthday parties.  However, for the last two years, Max has not been around anymore.  Nevertheless, Imatch frequently assigns pictures to Max, and I need to reassign them for every occurence.  Had Imatch less faces to choose from, there would be fewer misassignments.

I guess I could enter a death date for Max, but then I cannot delete the death date at a later point in time, so I cannot use Max at all anymore.  (Yes, I can understand the programming logic behind this: Resurrections are not common, and for the only reported case in the last 3000 years, there are no pictures unfortunately)

Any other ideas?

mastodon

I have similar problem with face recog. Maybe we would give a definitve list of persons for an event (a batch if recognition) to choose from.

Mario

Basically an per-person property/switch to exclude that person from being assigned to faces?

This would be doable, but could potentially cause performance issues in the sensitive recluster person task that runs after each face assignment / addition / movement to find matching persons. Because instead of finding the best match for a face, the process would have to consider an exclusion list. Not sure if this would make a small or huge difference in performance.

WebEngel

Quote from: Mario on June 20, 2023, 09:44:50 AMBasically an per-person property/switch to exclude that person from being assigned to faces?

This would be doable, but could potentially cause performance issues ...
That would be great.

Any performance issue would by far be outweighed by the time saved for not going thru 20 former friends every other day and find new pics assigned to them.

hluxem

I think that would be great!

I would have thought it makes it easier for the face recognition when less people need to be considered, but I maybe to old to understand how this all works.

Heiner

Damit

This is similar to the feature request found here: https://www.photools.com/community/index.php/topic,13551.0.html, where I suggested a similar solution to the one Mario posited above.

PandDLong


I have this challenge as well.

A work-around I have chosen is to not create entries in the People database for individuals who will only exist for a few photos.  I have incorporated their information through the use of other tags and a metadata template - but it is a little complex.

A more elegant solution would be welcome.

Michael


PandDLong

Quote from: cg on September 24, 2023, 06:59:21 PMI run into this problem all the time.

The solution I've found is to turn off all trained faces for people I don't expect to ever have to identify again, and they no longer show up as suggestions.



From the other thread, this solution from CG makes a lot of sense and seems very reasonable and easily managed by the user.

Mario - does this effectively solve the problem identified at the beginning of this thread?   


Michael

Mario

Should to the trick.
As I wrote in the original post (I guess) I have thought about this but implementing it could cause performance issues since face recognition and reclustering is optimized to the hilt and runs 95% directly in the database kernel with the help of some in-database functions IMatch provides.

Changing this to exclude one or more persons could negatively impact performance and may cause an increase in runtime. Maybe even drastically, like a runtime that doubles or triples...

I have this on my to-do list, but demand seems low and implementation could cause performance issues. So this simmers on level 3. I may spend a day when I have one to see how this could be implemented and how it would affect performance. Maybe for IMatch 2024/2025...
Because, adding a "don't assign this person to faces" check box in the person editor would of course be comfortable to the users.

PandDLong


I am thinking that if not having any trained faces for a given person effectively takes that person out of the face recognition process, then you don't need to consider making a potentially complex change to iMatch.  

Add a tip to the People and Face sections of the online help - and you've got this situation covered.

Should I add a post to the Online Help section of the forum with this suggestion?

Michael

Mario


QuoteShould I add a post to the Online Help section of the forum with this suggestion?

Always.


Damit

Quote from: Mario on March 05, 2024, 07:26:59 PMChanging this to exclude one or more persons could negatively impact performance and may cause an increase in runtime. Maybe even drastically, like a runtime that doubles or triples...

I have this on my to-do list, but demand seems low and implementation could cause performance issues. So this simmers on level 3. I may spend a day when I have one to see how this could be implemented and how it would affect performance. Maybe for IMatch 2024/2025...
Because, adding a "don't assign this person to faces" check box in the person editor would of course be comfortable to the users.
I too had a similar request: https://www.photools.com/community/index.php/topic,12874.msg90896.html#msg90896

I am glad it is possibly taking some traction.  It would be helpful to also be able to tell I match which faces exist in a set of photos.  If you do a photoshoot of one person you can instruct Imatch to only match that person to faces in the set of pictures.

Mario

Quoteable to tell I match which faces exist in a set of photos.
 If you do a photoshoot of one person you can instruct Imatch to only match that person to faces in the set of pictures.
Wouldn't that be super tedious?
Why not just use manual face links instead or just assign the right person to the face annotation?
This takes a few seconds and is surely a lot faster than first telling IMatch that "this file contains Mary" and then letting IMatch search for the face and assign the person when a face is found.