SUMMARY When assigning names to identified faces, there appears to be a display error or confusion for the end user. Matched faces disappear and reappear after a while. It then takes some time for the queue to be processed and the associated images to disappear. For illustration (https://drive.google.com/file/d/1bEOzwkCY5jLE2E_I6VwB5AMLc112Geo2/view?usp=sharing): IMG_8086.cr3, IMG_8087.cr3 ... IMG_8177.cr3 are accepted (up to second 6). At second 8, IMG_8086.cr3 etc. reappear. After the queue has been processed, they disappear correctly (not in the video). As it is so easy to make a mistake, it would be desirable if they did not reappear. STEPS TO REPRODUCE 1. Accept the assignment of a recognised name to an image 2. Repeat this several times to fill the internal queue OBSERVED RESULT The images disappear. They will reappear a short time later, and you can accept or reject them again (you don't have to). After a while, if the image has been processed according to the internal queue, it will disappear again (whether or not you have done anything with it since it reappeared) and be written to the database. EXPECTED RESULT The images disappear and the mapping is written to the database. SOFTWARE/OS VERSIONS Windows: 11
@Maik, Can you please take a look at the FacePipelineEdit::Writer method to see I'm doing something wrong that might be causing this? Cheers, Mike
Git commit 7c337af7de3e1c70de1bb489f49bda843d1f5af1 by Maik Qualmann. Committed on 27/01/2025 at 11:32. Pushed by mqualmann into branch 'master'. first try to remove the items from the view M +23 -32 core/app/items/views/digikamitemview.cpp https://invent.kde.org/graphics/digikam/-/commit/7c337af7de3e1c70de1bb489f49bda843d1f5af1
We will see if the behavior is better now with this commit. It is more of a timing problem depending on the processing speed. I will also try to fix the fact that the view sometimes jumps uncontrollably to another item; the cause is actually clear. Maik
Git commit dbc2c6e3d39af958a8c955831fe382f54466bbc9 by Maik Qualmann. Committed on 27/01/2025 at 20:05. Pushed by mqualmann into branch 'master'. move to next face in the list M +70 -5 core/app/items/views/digikamitemview.cpp https://invent.kde.org/graphics/digikam/-/commit/dbc2c6e3d39af958a8c955831fe382f54466bbc9
Thanks a lot. I will test it next week and let you know. In this context, I will check out if this problem is fixed as well: https://drive.google.com/file/d/1oXEI_lYaN8pL1dRDPl49DMW6rkSNDByO/view?usp=sharing An accepted face identification is coming back and not getting accepted. The face was manual added. DebugView: https://drive.google.com/file/d/1a9wy_tzRKXnyWMGF0QNJ2o9hhVgILqJb/view?usp=sharing
Git commit 3dc7f619c8d4f659c3ddf0d6d1846f21fbdc08c7 by Maik Qualmann. Committed on 29/01/2025 at 19:32. Pushed by mqualmann into branch 'master'. do not scroll to the next item M +0 -5 core/app/items/views/digikamitemview.cpp https://invent.kde.org/graphics/digikam/-/commit/3dc7f619c8d4f659c3ddf0d6d1846f21fbdc08c7
My original problem seems to have been solved. It also seems to have drastically increased the speed of assigning. Thank you very much. My comment 5 seems to be a different problem. The face still came back. I could no longer see view jumps to a completely different image. However, there are some small jumps that I cannot reproduce to describe a procedure so far. The result is that sometimes after ignoring or accepting a face, the row (of the edited face) is aligned at the top or bottom of the current view.
Git commit 8531a9915702a3fa09c01f9bbcb2c9989b01a8f5 by Michael Miller. Committed on 31/01/2025 at 14:18. Pushed by michmill into branch 'master'. check image and extracted face cv::Mat FIXED-IN: 8.6.0 Comment #5 M +1 -1 core/libs/facesengine/recognition/opencv-dnn/dnnsfaceextractor.cpp M +28 -15 core/utilities/facemanagement/pipelines/facepipelinebase.cpp https://invent.kde.org/graphics/digikam/-/commit/8531a9915702a3fa09c01f9bbcb2c9989b01a8f5
comment 5 is fixed with version of 2025-02-07. However, the original issue came back. Maybe the timing issue is more prominent than I thought. It seems to happen more often when the storage is heavily used