Bug 423113

(In reply to Kartik from comment #0)
> SUMMARY
> If a user accidentally confirms a face, and then to correct it, deletes the
> face, still Facial Recognition uses information from the confirm operation.
> 
> STEPS TO REPRODUCE
> 1. Confirm an Unknown Face to a newly created face.
> 2. Delete this face, using the Rejection Overlay (cross button)
> 3. Run Facial Recognition
> 
> Here's a video showing this in action : https://imgur.com/a/sYX3cgF
> 
> I assume this is happening because the Face is being deleted without
> removing the association of the Tag Region and the Face Tag. I personally
> don't think this is desirable, as it forces the Algorithm to operate on
> incorrect information. Please try to reproduce this bug, as it may be
> possible that this is just a problem in my branch.
> 
> Kartik

[Correction]
1. Confirm an Unknown Face to a newly created Face Tag.

Yes, the behavior is as described. In principle, it is even desirable. It is only problematic when a face is changed, but there is an option in the maintenance tool to rebuild the training database based on the currently confirmed faces. This should be done from time to time to ensure good recognition. The incorrect identity is then removed. Normally, a face should not be forgotten when you delete an image, for example. The face should be found again later, so there is no deletion in the face database.

Maik

Hi Maik, rebuilding the training database is certainly a good idea to avoid this error. I wasn't aware that feature existed.

It's certainly desirable for Faces to remain in the database, if an Image is deleted. However, if the User presses (x) on a Face, then he does want to Delete that face (not delete the Image). If the user is implying that this is not a face, then why is it being used as Training Data?

Apologies for any inconvenience.

Kartik

(In reply to Kartik from comment #3)
> Hi Maik, rebuilding the training database is certainly a good idea to avoid
> this error. I wasn't aware that feature existed.
> 
> It's certainly desirable for Faces to remain in the database, if an Image is
> deleted. However, if the User presses (x) on a Face, then he does want to
> Delete that face (not delete the Image). If the user is implying that this
> is not a face, then why is it being used as Training Data?
> 
> Apologies for any inconvenience.
> 
> Kartik

Hi Kartik,

Yes, I think it should delete the face embedding of a deleted face. Maybe we can add a reference counter to delete the registered identity as well when there isn't any face left? 

Could you point me to the code of the deleting button so that I can have a better understanding of the workflow here?

Nghia

Hi Nghia,

The Top Level Connections for the Deleting button are done in DigikamItemView. The Delete Button forms part of a FaceRejectionOverlay, and the signal for pressing the delete button is set here: https://invent.kde.org/graphics/digikam/-/blob/master/core/app/items/views/digikamitemview.cpp#L342.

The removeFaces(https://invent.kde.org/graphics/digikam/-/blob/master/core/app/items/views/digikamitemview.cpp#L411) method then delegates deletion to a FacePipeline. I think you might be familiar with FacePipeline functionality. DatabaseWriter works with the FacePipeline and picks up the package (when its time for being processed arrives), and then calls the FaceUtils method for actual removal of the Image-Tag association:

See this connection for DatabaseWriter with FaceUtils: https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/facemanagement/workers/databasewriter.cpp#L142.

There's multithreaded implementations that lead to DatabaseWriter picking up the package sent via FacePipeline, however it isn't necessary to worry about that in my opinion.

Kartik

(In reply to Kartik from comment #5)
> Hi Nghia,
> 
> The Top Level Connections for the Deleting button are done in
> DigikamItemView. The Delete Button forms part of a FaceRejectionOverlay, and
> the signal for pressing the delete button is set here:
> https://invent.kde.org/graphics/digikam/-/blob/master/core/app/items/views/
> digikamitemview.cpp#L342.
> 
> The
> removeFaces(https://invent.kde.org/graphics/digikam/-/blob/master/core/app/
> items/views/digikamitemview.cpp#L411) method then delegates deletion to a
> FacePipeline. I think you might be familiar with FacePipeline functionality.
> DatabaseWriter works with the FacePipeline and picks up the package (when
> its time for being processed arrives), and then calls the FaceUtils method
> for actual removal of the Image-Tag association:
> 
> See this connection for DatabaseWriter with FaceUtils:
> https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/
> facemanagement/workers/databasewriter.cpp#L142.
> 
> There's multithreaded implementations that lead to DatabaseWriter picking up
> the package sent via FacePipeline, however it isn't necessary to worry about
> that in my opinion.
> 
> Kartik

Thanks,

As I see it, FaceUtils only manage face tag and retrieve identity, and FacePipelineFaceTagsIface doesn't hold the information of the registered face embedding. Therefore in order to delete the face embedding in the database, we have to add an additional association between face item and face embedding. If I do it now, it will add up more conflicts to our projects. Therefore I will find a way to do it after the 2 projects merged.

Nghia

Kartik, Nghia,

Both projects are now merged back to git/master. The road is now open to go to 7.2.0...

Best regards

Gilles

(In reply to caulier.gilles from comment #7)
Thank Gilles,

Is there any conflicts that worth noticing?

Best,
Nghia

Hi Nghia,

No conflict at all. All compile fine.

I currently review all code step by step...

In the digikam-devel@kde.org, an user has already tested the new code (just after i merge the branches this morning) and has a question for you. Look here :

http://digikam.1695700.n4.nabble.com/Digikam-7-2-faces-updates-td4713606.html

Gilles

Maik,

I suppose that file is now fixed since a while no ?

Gilles

No, we are not currently deleting face vectors from the face database. A rebuild of the training database with the maintenance tool is still necessary.

Maik

Yes, as Maik says, you need to rebuild the training database using the maintenance tool.  I'm planning to fix this issue when I rewrite the entire facial recognition system after then 8.5.0 release.

Git commit c003f95327d1239378241226140f9098b989e52e by Maik Qualmann, on behalf of Michael Miller.
Committed on 02/11/2024 at 22:56.
Pushed by mqualmann into branch 'master'.

closing tickets
Related: bug 469329, bug 431797, bug 415782, bug 472031, bug 464266, bug 444160, bug 436544
FIXED IN: 8.5.0

M  +8    -8    NEWS

https://invent.kde.org/graphics/digikam/-/commit/c003f95327d1239378241226140f9098b989e52e