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
(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