SUMMARY When working through face recommendations, if there is a wrong face you can click the thumbnail and type a name. If you then click the correct name with the mouse, only the current photo is tagged. If you use the arrow keys and hit enter on the correct name, both the current photo and the next photo are tagged with the selected name. Results: Photos get tagged with the wrong person STEPS TO REPRODUCE 1. Using recent weekly build digiKam-8.6.0-20250209T190112-Qt6-x86-64-debug.appimage on Debian 2. Run face recognition, have recommended results for an existing person tag with mixed correct and incorrect suggestions. 3. Click a wrong suggestion and click into the name search text box. Type until you see the name you want 4a - (BUG PATH) Use the arrow keys to select the name, hit Enter to approve it 4b - (WORK AROUND) Use the mouse to click the name OBSERVED RESULT When using the Enter key to approve the selected name the current photos is tagged and the next photo is also tagged. Both are tagged with the selected name. EXPECTED RESULT Only the currently selected photo should have its recommended face tag approved. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2 Kernel Version: 6.11.10-amd64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5700G with Radeon Graphics Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3070/PCIe/SSE2 ADDITIONAL INFORMATION 20 second video of issue here: https://www.youtube.com/watch?v=W3Blj0JVbeE * First I choose a different name with the mouse (only one thumbnail disapears) * Then I choose a different name with the keyboard (two names disapear)
In a quick test I can't reproduce it here under Windows. Is your Enter key bouncing? Maik
How strange. I can't reproduce the issue right now so I can't test it any more. I don't think it was a bouncing key, I didn't notice any extra returns when programming or writing the last few days. I saw the issue across several digiKam restarts yesterday and today, but just now I couldn't reproduce it any more. I guess this could be closed and if it happens again I can gather more info. Thanks for looking at it!
Thanks for the feedback. I close it now, don't hesitate to re-open if necessary...
I have seen this same issue under linux with the nightly builds. Usually, the next image to the right is the one that is included and tagged incorrectly. I have not been able to reproduce it reliably. but it tends to happen while digikam is processing images at the same time or just after it has finished or while it is still loading a large library. it doesn't seem to happen as often when digikam has sat idle for a while. it happens with a single face that I am changing the name of, or multiple consecutively in a row, but when it behaves erratically, it's always the next image to the right of the last image selected.
Git commit d857b6e333d6387e3a19d2d553aaa506034f2208 by Maik Qualmann. Committed on 11/02/2025 at 19:24. Pushed by mqualmann into branch 'master'. try without QProcessEvents M +0 -5 core/app/items/views/digikamitemview.cpp https://invent.kde.org/graphics/digikam/-/commit/d857b6e333d6387e3a19d2d553aaa506034f2208
I have been unable to recreate this issue with the latest 2025-02-12/13 nightly builds. bulk reassigning face has not moved any unselected faces with it in my tests. thank you
I stand corrected, using the nightly build digiKam-8.6.0-20250217T110102-Qt6-x86-64.appimage. I was correcting a face tagged as Face X to be Face Y. I selected the single face with my mouse started to type in the new name after a few characters I used the keyboard arrow keys to select the correct name. when I hit 'Enter' it, and the next face to the right was tagged as Face Y. Digikam was not under load and was idle at that moment.
I understand that 2 are confirmed at the same time? I can't reproduce any malfunction here. Maik
(In reply to Maik Qualmann from comment #8) > I understand that 2 are confirmed at the same time? > I can't reproduce any malfunction here. > > Maik yes, both faces were confirmed to 'Face Y' at the same time, though I had only selected the single face on the left. it's rare and I have not been able to reliably reproduce it. I have probably fixed about 50 or so Face Tags the same way since 2025-2-12 until this malfunction hit me today. the frequency of malfunctions has noticeably dropped since the change on 2025-2-11. Prior to 2-11 I was paying much more attention to tagging circumstances because of the frequency of failures, it was a chore to load the new face and search through the images to identify the mistagged face. (and under a related note, are there plans to have an 'undo' option, or a feature to display a history of edited images to easily find and fix recent mistakes?)
As I said, I can't reproduce it. @Gilles, can you comment on these comments and why selectedIndexes() is not trusted, I would definitely change the code. https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/widgets/itemview/itemdelegateoverlay.cpp?ref_type=heads#L103 https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/widgets/itemview/itemdelegateoverlay.cpp?ref_type=heads#L151 Maik
Hi Maik, Perhaps due to the Q_FOREACH to C++17::for() port: https://invent.kde.org/graphics/digikam/-/commit/9b6a67b4c1a309c899d7fcda3859fc7207a31d06#450f1ab26003a9fc323fd89c7192e33dd776530a ...in line 155 from core/libs/widgets/itemview/itemdelegateoverlay.cpp ??? Gilles
I also tried to reproduce the dysfunction here, without success (Qt6 version, Linux KUbuntu 24.04) Gilles
Git commit 515cee44b791e6a27301cc6445f16cdadabe1e72 by Maik Qualmann. Committed on 19/02/2025 at 11:28. Pushed by mqualmann into branch 'master'. restore almost previous behavior when confirming faces Related: bug 500363 M +33 -33 core/app/items/views/digikamitemview.cpp https://invent.kde.org/graphics/digikam/-/commit/515cee44b791e6a27301cc6445f16cdadabe1e72