Bug 380336 - Suggested improvements of Face Tagging
Summary: Suggested improvements of Face Tagging
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Workflow (show other bugs)
Version: 7.0.0
Platform: Appimage Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-30 00:50 UTC by Andrius
Modified: 2020-01-27 21:31 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrius 2017-05-30 00:50:13 UTC
Hello,

Right now manual face tagging workflow looks like this:
- Click on "Add Face Tag" button (mouse)
- Draw a face region (mouse)
- Entry field shows up right after you released the mouse button. The field already has "Unknown" in it and it allows you to start typing a name. After you start typing a drop down list pops up and the search results narrow down while you typing. 
https://youtu.be/s6KtrKTkwWE
The issue is that the last step requires keyboard entry. There is a button on the right side of the entry field that you can click on but that drop down window, first, seem to have an inconsistent size (try to open and close it few times) and, second, clicking on a name in that list does not do anything (try it).
Since we use mouse for first two steps it would be nice to be able to finish the last step using the mouse too. We would need the window with names from people sidebar to drop down automaticaly right after you finished drawing the face region and released the button. The size of that window should depend on the length of the list or at least be no shorter than 5-7 lines. Also, recently used names should show up on top of the list.

What do you think?
Comment 1 Andrius 2017-10-20 04:49:58 UTC
Wanted to add that there are few things that could be improved in how digikam behaves after you added a face region.

1. If you click on the icon to drop down the list of names for some reason the list starts from the bottom (Unconfirmed) - suggestion: start from the most used or from the last used at least (ideally in future: start from the suggested tag for the face)
2. The size of the pop-up window is too small (3 lines only) - suggestion: expand it to 5-7 lines
3. First line is taken by "Tags", the second one "People" - suggestion: do not show "Tags" and "People" at all, just list the names (people)
4. Natural reaction to scroll the list up or down is to use the mouse scroll wheel. digikam instead scroll the whole image up and down (if zoomed in) - suggestion: lock the image while the people pop-up window is open and scroll the list up/down despite the location of the mouse cursor
5. After you scrolled the image up and down the people pop-up window gets blocked and does not show up again (face region is being shown at the time though). Reopening of the image helps so does switching to previous/next and go back - suggestion: fix that 
6. If you selected a name from the list and clicked on it you still need to click on "confirm" after. If you don't do that digikam does not remember the name you picked. Suggestion: Do not ask to confirm after user clicked on a name from the list
7. The list starts from "Unknown" as mentioned above. If you use the scroll bar to scroll up and then accidentally moved the mouse down it scrolls the list down. Moving the mouse up does not scroll the list up. Suggestion: either make the behavior work for scrolling both ways (up and down) or disable it at all.
8. Sometimes mouse wheel does scroll the list up and down however it starts scrolling the image after it reaches the end of the list. Suggestion: same as above - lock the image and scroll only within the pop-up people window while it is open
Comment 2 Andrius 2017-10-20 04:58:53 UTC
Another suggestion:
After user added a face region and when the field "Who is this?" shows up it would be great to be able to hover the mouse over the "who is this" field and use the wheel to scroll through the people list up and down and then digikam would remember the selection without needing to click on "confirm"
Comment 3 Andrius 2017-10-20 05:01:57 UTC
I mentioned below that "Tags" and "People" being shown. Clicking on "People" actually saves a face tag "People" which should not have happened.
Comment 4 caulier.gilles 2019-03-20 15:16:08 UTC
After 3 weeks of work, i finally completed the compilation of AppImage using Qt
5.11.3 + QWebkit 5.212.

New 6.1.0 pre-release AppImage bundle can be found here (64 bits only for the
moment) :

https://files.kde.org/digikam/

Please check if this bugzilla entry still valid.

Thanks in advance

Gilles Caulier
Comment 5 caulier.gilles 2019-12-23 15:32:31 UTC
7.0.0-beta1 is out with new Face Recognition algorithm based on Deep
Learning/Neural Network API from OpenCV

https://download.kde.org/unstable/digikam/

Please test and give us a feedback

Thanks in advance
Gilles Caulier
Comment 6 caulier.gilles 2019-12-26 17:37:59 UTC
Git commit 05b9a534d89234b7571d5dade8067c490ab896cf by Gilles Caulier.
Committed on 26/12/2019 at 17:30.
Pushed by cgilles into branch 'master'.

Faces Workflow simplication and improvements: remove face scan dialog and embed Face scan settings in People left sidebar.
disable settings view while a face job is running.
Catch face detector tool complete/cancelled signal to re-enable settings view.
By this way, this will prevent to run 2 concurrent face jobs at the same time.
Related: bug 398376, bug 412168

M  +45   -31   core/app/views/sidebar/leftsidebarwidgets.cpp
M  +1    -0    core/app/views/sidebar/leftsidebarwidgets.h
M  +1    -1    core/utilities/facemanagement/CMakeLists.txt
R  +15   -45   core/utilities/facemanagement/widgets/facescanwidget.cpp [from: core/utilities/facemanagement/widgets/facescandialog.cpp - 089% similarity]
R  +9    -11   core/utilities/facemanagement/widgets/facescanwidget.h [from: core/utilities/facemanagement/widgets/facescandialog.h - 079% similarity]
R  +8    -11   core/utilities/facemanagement/widgets/facescanwidget_p.h [from: core/utilities/facemanagement/widgets/facescandialog_p.h - 090% similarity]
M  +1    -1    core/utilities/maintenance/facesdetector.cpp
M  +3    -3    core/utilities/maintenance/facesdetector.h
M  +1    -0    core/utilities/maintenance/maintenancetool.cpp
M  +11   -3    core/utilities/maintenance/maintenancetool.h

https://invent.kde.org/kde/digikam/commit/05b9a534d89234b7571d5dade8067c490ab896cf
Comment 7 Andrius 2019-12-27 02:05:07 UTC
I gave the 7.0.0 beta1 a quick spin Windows. I haven't noticed any improvements in the face tagging interface unfortunately. I will try to record a screencast tomorrow to describe the issue a little bit.
Comment 8 Maik Qualmann 2019-12-27 20:25:15 UTC
Git commit 3d56943b33495a1374e3d185844ffb80eb99cbdf by Maik Qualmann.
Committed on 27/12/2019 at 20:23.
Pushed by mqualmann into branch 'master'.

try with set combobox max view items to 10
Related: bug 413923

M  +1    -0    core/libs/tags/widgets/addtagscombobox.cpp

https://invent.kde.org/kde/digikam/commit/3d56943b33495a1374e3d185844ffb80eb99cbdf
Comment 9 Andrius 2020-01-27 21:06:11 UTC
Hello,
I tried to show what I mean in this video:
https://youtu.be/rITxoesL9pQ

digikam 7.0.0 latest daily build
When I click on the drop down button there is still a collapsed list of "People" shown. I think it would make sense to show an expanded list of names right away.
I would not want to see People, BalooTags, etc.
What do you think?
Comment 10 MarcP 2020-01-27 21:31:07 UTC
Just chiming in, there is an issue here that tagged faces can exist outside the "People" tree dir. Animals, for example. So hiding anything but "People" doesn't seem like a good idea at first. 

Also, if pictures with faces are imported, and that other person used Digikam in another language, instead of "People" it would be the equivalent in their language. So, for instance, you would see "People", and "Personnes", both containing faces.

I personally believe that People shouldn't be part of the general tag tree, but maybe a separate list, and it the word "People" shouldn't be a tag in itself, in order to to avoid what I just mentioned with the language. But I don't think that would be easy to achieve. 

Bug 392008 is related to this.