SUMMARY When a selection of people is done, using Shift+click, there is no action offered on the last people thumbnail. See attached video capture. STEPS TO REPRODUCE 1. In the people/unconfirmed area 2. Select the 1st thumbnail 3. Shift + select the last thumbnail to create a selection. You now have a bunch of people selected. 4. Keep your mouse over the last thumbnail. OBSERVED RESULT 4. there is no action menu offered. No "Confirm" nor "Reject" nor "Ignore"... EXPECTED RESULT 4. There should be these actions "Confirm" nor "Reject" nor "Ignore". SOFTWARE/OS VERSIONS digiKam: 8.6.0 KDE Frameworks: 6.10.0 Qt: Using 6.8.1 and built against 6.8.1 Windows 10 Version 22H2 Build ABI: x86_64-little_endian-llp64 Kernel: winnt 10.0.19045 ADDITIONAL INFORMATION Workaround : move the mouse outside the thumbnail, then go back in. The actions are back.
Well, the overlay is only displayed when a focus event occurs. Make sure you don't mark multiple people, as this will result in incorrect assignments. Only confirm/ignore the same person at once. Maik
Thank you Maik. This limitation seems weird to me, as it slows down a lot the confirmation process. Best regards. -----Original Message----- From: Maik Qualmann <bugzilla_noreply@kde.org> Sent: mardi 18 mars 2025 12:45 To: alexandre.belz@live.fr Subject: [digikam] [Bug 501690] People : Missing contextual actions on the last thumbnail of a Shift-created selection https://bugs.kde.org/show_bug.cgi?id=501690 Maik Qualmann <metzpinguin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |metzpinguin@gmail.com --- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> --- Well, the overlay is only displayed when a focus event occurs. Make sure you don't mark multiple people, as this will result in incorrect assignments. Only confirm/ignore the same person at once. Maik -- You are receiving this mail because: You reported the bug.
The problem is that some users correct the name in the first item and expect this correction to be applied to all selected items (old behavior). We changed this and promptly received a bug report. We can't determine what the user wants: correct multiple entries or confirm multiple entries. Therefore, we've retained the "old" behavior for now. Maik
I'm not expert of digiKam code, but could it be possible to call the "focus event" function once the last people thumbnail of a selection is selected ? (as I Shift+clicked on it, I would expect this function to be called).
Thank you Maik for your support. > Make sure you don't mark multiple people, as this will result in incorrect assignments. Only confirm/ignore the same person at once. Well... for a few validation, I would understand. But here I have 3000 unconfirmed faces to review, and going 1 by one would be very tedious. Moreover, It happen several times that I confirmed a single face and rapidly confirmed the next good ones... but in the meanwhile, digiKam took the decision to re-arrange the faces, in such a way that my mouse click applied to an unwanted face. That is really frustrating. It's even worth if a face detection process is running in the background : faces get added/rearranged under my mouse even if I don't review anything, making it difficult (random/risky) to review faces. To be 100% safe, it seems digiKams needs me to 1) stop any background face detection process I may have launched 2) go into Unconfirmed faces, review 1 single face. 3) wait a few seconds that digiKam faces process stabilizes. loop 2,3. No need to say that 3000 faces will need years of review at this rythme. I intensively used face assignment in Picasa years ago, and I don't remember having such issue reviewing the "Unconfirmed" faces, even when background face detection was running. Maybe Picasa did not rearranged dynamically the unconfirmed faces, I'm not sure. Anyway, Picasa was build in a way that I was able to quickly review/assign people unconfirmed faces, in a stable and safe manner. Do you think that digiKam could get to this reliability point ? Could we imagine something stronger / faster / safer ? 1) support multiple (unconfirmed) face selection and then Confirm / Reject / Ignore/ Rename ? with no risk to get the selection modified/broken of course. 2) imagine a way for face thumbnails to stay in place until the manual review is finished. For instance when a people assignment is done, lock the arrangement, just remove the green rectangle. Update the display only if a manual Refresh is called. 3) more difficult, find a way to allow a safe (unconfirmed) people review while a face detection is running in the background. This means that detecting new faces would NOT change the face thumbnail arrangement. Maybe removing the people grouping and just adding the newly detected faces at the end, like a pile. Is there a sorting mode that I could configure to get to this point in the current version ? Warmest regards.
Hi @Maik, I think I better understand your sentence below : "Make sure you don't mark multiple people, as this will result in incorrect assignments. Only confirm/ignore the same person at once." I should restrict myself to "confirm/ignore" the same person at once ; I'm still authorized to select multiple thumbnails using SHIFT. But even with that, the issue in this ticket remains valid : after doing the SHIFT selection, I miss the confirm/ignore pop-up menu, that I expect to see on the last selected thumbnail (because it is the last focused thumbnail). Do you agree ?
Yes, you can select multiple (identical) people; that's no problem. As it stands, there's no focus-in event as long as the Shift key is held down. We probably won't get any feedback. I'll take a closer look when I have time. However, I don't think it's a problem to reposition the mouse cursor after selecting so that the overlay appears. Maik
Git commit 7cd0b91e4e18e7d513e941f80007bffb66bb08b8 by Michael Miller. Committed on 02/04/2025 at 17:45. Pushed by michmill into branch 'master'. Work/michmill/facebackgroundprocess - A new recognize only face scan is started whenever the face training data is modified. - Added logic to ensure incompatible face scan types do not run at the same time Related: bug 444394 M +6 -4 core/app/items/views/digikamitemview.cpp M +7 -2 core/app/main/digikamapp.cpp M +13 -2 core/app/main/digikamapp_tools.cpp M +23 -16 core/app/views/sidebar/peoplesidebarwidget.cpp M +26 -42 core/app/views/stack/itemiconview_search.cpp M +10 -2 core/libs/album/treeview/albumselectiontreeview.cpp M +6 -15 core/libs/facesengine/recognition/faceclassifier.cpp M +7 -2 core/libs/facesengine/recognition/faceclassifier.h M +5 -1 core/libs/facesengine/widgets/facescansettings.cpp M +28 -1 core/libs/facesengine/widgets/facescansettings.h M +9 -8 core/libs/mlfoundation/mlpipelinefoundation.cpp M +1 -0 core/libs/mlfoundation/mlpipelinefoundation.h M +2 -2 core/libs/mlfoundation/mlpipelinemacros.h M +1 -1 core/libs/tags/autoassignment/pipelines/object/autotagspipelineobject.cpp M +3 -0 core/utilities/facemanagement/CMakeLists.txt A +221 -0 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.cpp [License: GPL(v2.0+)] A +61 -0 core/utilities/facemanagement/backgroundprocesses/facebackgroundrecognition.h [License: GPL(v2.0+)] M +1 -1 core/utilities/facemanagement/pipelines/detectrecognize/facepipelinedetectrecognize.cpp M +5 -5 core/utilities/facemanagement/pipelines/recognize/facepipelinerecognize.cpp M +1 -1 core/utilities/facemanagement/pipelines/reset/facepipelinereset.cpp M +1 -1 core/utilities/facemanagement/pipelines/retrain/facepipelineretrain.cpp M +1 -0 core/utilities/maintenance/main/maintenancedlg_settings.cpp M +13 -3 core/utilities/maintenance/manager/maintenancemngr.cpp M +161 -18 core/utilities/maintenance/tools/facesmanagement/facesengine.cpp M +4 -4 core/utilities/maintenance/tools/facesmanagement/facesengine.h M +1 -1 project/bundles/homebrew/config.sh https://invent.kde.org/graphics/digikam/-/commit/7cd0b91e4e18e7d513e941f80007bffb66bb08b8
Hi, The 8.7.0 pre-release Windows installer from today have been rebuilt from scratch with Qt 6.8.3, KDE 6.12, OpenCV 4.11 + CUDA support, Exiv2 0.28.5, ExifTool 13.27, ffmpeg 7, all image codecs updated to last version (jxl, avif, heif, aom, etc.). Please try with this version to see if your problem still reproducible... https://files.kde.org/digikam/ Thanks in advance Best regards Gilles Caulier
Hello, Yes, this bug is still present in latest version 8.7.0 (20250514T170134).