Bug 496131 - Face Tagging multiple incorrectly suggested unconfirmed faces do not move to the corrected person.
Summary: Face Tagging multiple incorrectly suggested unconfirmed faces do not move to ...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Workflow (show other bugs)
Version: 8.5.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-11 15:25 UTC by E T
Modified: 2024-11-15 21:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description E T 2024-11-11 15:25:03 UTC
SUMMARY

When correcting the auto tagging of unconfirmed people that do not belong in the suggested person's tag, the images still end up tagged as the suggested incorrect person

STEPS TO REPRODUCE
1.  run the face tagging so a multiple unconfirmed faces are suggested for person 'X', but multiple faces are incorrectly tagged belong to Person 'Y' are also suggested for 'X' 
2. select the faces and approve the tags for person 'X' (click the Check button for the selected images), the images are tagged properly and show correctly in the 'confirmed' section
3. Select the multiple images that belong to person 'Y',
4. Change the name from 'X' to 'Y'
5. Click the Approve check button for the selected multiple images

OBSERVED RESULT
Images identified for person 'Y' show tagged as person 'X' in X's Confirmed list of tagged images

EXPECTED RESULT
Images confirmed tagged as person 'Y' should show in Y's album tagged properly as 'Y'

SOFTWARE/OS VERSIONS
digiKam-8.5.0-20241109T170114-Qt6-x86-64.appimage

ADDITIONAL INFORMATION
Comment 1 Maik Qualmann 2024-11-11 15:35:23 UTC
The behavior has been changed, only correct a single person. If several people are selected, the suggestion is used. Since with the current face engine and current training database, there are hardly any incorrect people. Switch to SFace for face recognition.

Maik
Comment 2 E T 2024-11-11 15:59:56 UTC
I should have noted that setting in the report. I am using SFace. I have also cleared and rerun the detection (YuNet) and the recognition on these images (SFace). 

I also have numerous people who look very very similar (twins, other siblings) and it would still be helpful to batch assign.  in my latest run from yesterday I still have 16 consecutive images who are tagged incorrectly to a sibling that I would appreciate being able batch assign them to the correct person.

Even though the SFace is MUCH better than previous versions. I had recently rerun the whole process on a small portion of my album. out of 4700 images tagged to user X, about 1000 were still incorrectly tagged to multiple other people and it would be great to move them in batch and not individually. I do not understand why the software would have a highly useful tool removed. the face tagging tool itself can still be wrong.
Comment 3 E T 2024-11-11 16:29:01 UTC
also, if this is the new functionality, it should not let me believe I am tagging multiple images to a new person and then ignore that new value and proceed to use the tag it believes is right. it is difficult to manually search through albums with thousands of images to find those incorrectly tagged people and manually fix them.

the tool should either stop letting the user select multiple and change the name, or provide a warning that the new tag will be ignored and it will continue to be saved under the incorrect tag.
Comment 4 Maik Qualmann 2024-11-11 16:56:01 UTC
Up until now, faces could not be confirmed across groups of people; they were then assigned incorrectly. We cannot distinguish between the two scenarios when confirming.
What level of accuracy have you set for face recognition?

Maik
Comment 5 E T 2024-11-11 17:04:17 UTC
(In reply to Maik Qualmann from comment #4)
> Up until now, faces could not be confirmed across groups of people; they
> were then assigned incorrectly. We cannot distinguish between the two
> scenarios when confirming.
> What level of accuracy have you set for face recognition?
> 
> Maik

80 for both SFace and YuNet
Comment 6 Michael Miller 2024-11-14 01:18:08 UTC
(In reply to E T from comment #5)
> 80 for both SFace and YuNet

If your setting is "80", then you're using an older pre-release 8.5.0 version.  More recent pre-release versions changed the scale to 1-10.  Can you reproduce the issue with a new build?

Cheers,
Mike
Comment 7 E T 2024-11-14 16:58:59 UTC
(In reply to Michael Miller from comment #6)
> (In reply to E T from comment #5)
> > 80 for both SFace and YuNet
> 
> If your setting is "80", then you're using an older pre-release 8.5.0
> version.  More recent pre-release versions changed the scale to 1-10.  Can
> you reproduce the issue with a new build?
> 
> Cheers,
> Mike

I reran detection yesterday using build digiKam-8.5.0-20241113T110059-Qt6-x86-64.appimage
The settings are 8 for both. Detection is Yunet at medium size. and recognition is SFace

my top 3 faces detected that came back:
Person 1: 1409 tagged, 651 were incorrect. (this is a female child who had faces detected from a decade before they were born up to their current age of 12, faces detected had a wide range of male, female, ages up to 80+ year old and a wide range of skin tones)
Person 2: 951 tagged, 49 incorrect. (an adult female)
Person 3: 618 tagged, 81 incorrect. (an adult male)

my issue is still the breaking of a tool that lets a user bulk fix tagging without having to do it singularly considering I believe the tool worked fine in previous versions, without a warning that the use of said tool can make the experience worse for the user and their data.

If we want to continue to troubleshoot face detection that's one thing and I am willing to help (and should probably be a new ticket). 

As happy as i believe we all are with the improved accuracy of detection and recognition, I don't believe we've be having this discussion if it wasn't for the inability to bulk fix mis-tagged faces, and I believe we are going down a tangent. You have the utmost confidence in the improvement of the tagging, but it can still be wrong and still needs a tool to manually correct it. fixing faces singularly is not practical for large corrections and I stand by that the ability to correct multiple faces in bulk is still necessary. I also don't want to keep clicking the 'Reject this suggestion' button and rerun the detection and hope it gets it right the next time especially when I know who it is and would rather just select all the same person, change the name once and click Confirm for the selected batch.
Comment 8 Maik Qualmann 2024-11-14 18:42:31 UTC
Git commit 55dadc4694ade7bd54d9afd8673ba9cd54764f48 by Maik Qualmann.
Committed on 14/11/2024 at 18:40.
Pushed by mqualmann into branch 'master'.

Revert "fix confirmation of different faces"
Restore old face confirmation behavior.
FIXED-IN: 8.5.0

M  +1    -11   core/app/items/views/digikamitemview.cpp

https://invent.kde.org/graphics/digikam/-/commit/55dadc4694ade7bd54d9afd8673ba9cd54764f48
Comment 9 Maik Qualmann 2024-11-14 18:49:10 UTC
@Michael, this means that only faces with the same name can be confirmed. I don't think it's logical either, but at the moment I can't see any other option if long-term users are used to it. Based on the facial data from the model, we can't distinguish what the user actually wants to have confirmed in the batch. One idea would be to ask for a key when confirming (shift, control or alt). What do you think about this?

Maik
Comment 10 E T 2024-11-15 21:13:42 UTC
(In reply to Maik Qualmann from comment #8)
> Git commit 55dadc4694ade7bd54d9afd8673ba9cd54764f48 by Maik Qualmann.
> Committed on 14/11/2024 at 18:40.
> Pushed by mqualmann into branch 'master'.
> 
> Revert "fix confirmation of different faces"
> Restore old face confirmation behavior.
> FIXED-IN: 8.5.0
> 
> M  +1    -11   core/app/items/views/digikamitemview.cpp
> 
> https://invent.kde.org/graphics/digikam/-/commit/
> 55dadc4694ade7bd54d9afd8673ba9cd54764f48

this change has reverted the behavior back to what I am expecting.

thank you