Bug 265025

Summary: usability issues with tagging unknown faces
Product: [Applications] digikam Reporter: Adam Spiers <kde-bugs>
Component: Faces-WorkflowAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, rene, simon
Priority: NOR    
Version: 2.0.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 5.8.0

Description Adam Spiers 2011-02-01 00:15:40 UTC
Version:           2.0.0 (using KDE 4.5.5) 
OS:                Linux

The new face tagging code is tantalisingly close to being awesome!  However I am experiencing several glitches and UI issues when tagging unknown faces:

(1) If there is more than one unknown face on a photo, if I enter one
and then hit the Enter key, sometimes (but not always) it
automatically advances to the next photo even before I have tagged the
other unknown faces in that photo.

(2) There seems to be no way of starting to type without first having
to click the mouse on the 'Who is this?' text.  Requiring the use of
the mouse for every single photo makes the whole process MUCH slower -
this could be the difference between 30 minutes and 2 hours if you
have a lot of photos!  Please make this possible via the keyboard.

(3) After focusing on the 'Who is this?' text and typing a substring
of the person's name, the dropdown which appears has several problems:

  (a) It's not wide enough so I only see 'Create New Tag "...'

  (b) It actually displays 'Create New Tag "...' twice - once at the
      top and once at the bottom, and due to the truncation it's not
      clear if there is a good reason for having both.

  (c) Even if there is a good reason for having both, they should
      always appear at the bottom, so that hitting Enter defaults to
      applying the matching tag rather than creating a new one, since
      it's far more common that you will want to do the former than
      the latter.

  (d) Clicking on an item in the dropdown merely makes the dropdown
      vanish rather than selecting it.

Hope this usability feedback is useful.  Thanks for listening!

(See also bug 262574 for a related face tagging UI issue.)

Reproducible: Always
Comment 1 Adam Spiers 2011-02-01 00:29:54 UTC
Sorry, I found some more:

(4) When viewing thumbnails in the album view, if I hover the mouse
    over the thumbnail of a photo with unknown faces, it superimposes
    three things over the text underneath thumbnail: a "Who is this?"
    text entry field, and (I think) two icons; however the height of
    all three is squashed to a fraction of what it should be, and I'm
    not convinced there's enough room there to superimpose anything
    usefully anyway.  Perhaps this behaviour should be disabled?

(5) When viewing thumbnails via the 'People' sidebar, it seems to
    cleverly auto-zoom to the face region.  However this auto-zoom
    doesn't always work right when there is more than one region.
Comment 2 Marcel Wiesweg 2011-02-01 20:46:59 UTC
> (1) If there is more than one unknown face on a photo, if I enter one
> and then hit the Enter key, sometimes (but not always) it
> automatically advances to the next photo even before I have tagged the
> other unknown faces in that photo.

I see the problem. It requires a very small fix, I need to find out where.

> (2) There seems to be no way of starting to type without first having
> to click the mouse on the 'Who is this?' text.  Requiring the use of
> the mouse for every single photo makes the whole process MUCH slower -
> this could be the difference between 30 minutes and 2 hours if you
> have a lot of photos!  Please make this possible via the keyboard.

There are quite a few problems with the way this widget is implemented, one of them you mention here. I am currently, though, a bit "uninspired" how to solve all this convincingly.


> (3) After focusing on the 'Who is this?' text and typing a substring
> of the person's name, the dropdown which appears has several problems:
> 
>   (a) It's not wide enough so I only see 'Create New Tag "...'

That never was a problem for me, but I see now that the tag name is in German the third of the four words, in English it's the last, so it is cut. Line break is needed I guess.

>   (b) It actually displays 'Create New Tag "...' twice - once at the
>       top and once at the bottom, and due to the truncation it's not
>       clear if there is a good reason for having both.

One creates a toplevel tag, the other in "People/". Isnt it visible like this:
http://img406.imageshack.us/i/plasmadesktopqr2170.png/

> 
>   (c) Even if there is a good reason for having both, they should
>       always appear at the bottom, so that hitting Enter defaults to
>       applying the matching tag rather than creating a new one, since
>       it's far more common that you will want to do the former than
>       the latter.

Then creating a new tag will be a worst-case scenario in case there are many preexisting tags with the same first letters. Creating a new tag should be visible.

> 
>   (d) Clicking on an item in the dropdown merely makes the dropdown
>       vanish rather than selecting it.

There are three drop-downs:
- icon view, when typing
- preview view, when typing
- preview view, when clicking the arrow
Which are affected?

> (4) When viewing thumbnails in the album view, if I hover the mouse
>     over the thumbnail of a photo with unknown faces, it superimposes
>     three things over the text underneath thumbnail: a "Who is this?"
>     text entry field, and (I think) two icons; however the height of
>     all three is squashed to a fraction of what it should be, and I'm
>     not convinced there's enough room there to superimpose anything
>     usefully anyway.  Perhaps this behaviour should be disabled?

Should look like that:
http://img407.imageshack.us/i/plasmadesktoprf2170.png/

Which Qt/KDE version and style?

> 
> (5) When viewing thumbnails via the 'People' sidebar, it seems to
>     cleverly auto-zoom to the face region.  However this auto-zoom
>     doesn't always work right when there is more than one region.

There is only the face region directly from the database available as data, and the image is then cropped when generating the thumbnail. I have not seen this problem since the early days of face detection.

> 
> Hope this usability feedback is useful.  Thanks for listening!

Yes it is!
Comment 3 rene 2011-02-03 01:20:32 UTC
here is another one:
(6) allow for "mass tagging": if i work on large collections, it would be nice to be able to assign the same person to many faces at once. Even the fact that the last used tag is prefilled in the entry field does not save me from clicking each face one by one.
Comment 4 simon 2011-02-03 10:58:14 UTC
one more:

with beta2 i have just one "create new tag" option in the scan result window. When typing a name and pressing enter the tag is created as top level one and not under People.

it would perhaps make sense to allow the user to choose which branch of the tag tree should be the "people" tag root
Comment 5 Marcel Wiesweg 2011-03-07 19:06:18 UTC
Git commit 784e195c333d4778c3a74ac9129a64b69a1e70ff by Marcel Wiesweg.
Committed on 07/03/2011 at 19:03.
Pushed by mwiesweg into branch 'master'.

Implement operation on all selected images for the face overlays.
The pipeline that does the work is now moved to the view, so that
both overlays can connect to it via signals and share it.

CCBUG: 265025

M  +17   -9    digikam/items/assignnameoverlay.cpp     
M  +4    -2    digikam/items/assignnameoverlay.h     
M  +33   -20   digikam/items/digikamimageview.cpp     
M  +5    -5    digikam/items/digikamimageview.h     
M  +0    -1    digikam/items/digikamimageview_p.cpp     
M  +2    -2    digikam/items/digikamimageview_p.h     
M  +12   -1    digikam/items/facerejectionoverlay.cpp     
M  +3    -1    digikam/items/facerejectionoverlay.h     
M  +1    -1    libs/widgets/common/imagedelegateoverlay.cpp     

http://commits.kde.org/digikam/784e195c333d4778c3a74ac9129a64b69a1e70ff
Comment 6 Marcel Wiesweg 2011-03-08 22:20:08 UTC
Git commit 92ffcf96c647a370b36dc580c5316d643b58f58c by Marcel Wiesweg.
Committed on 08/03/2011 at 22:18.
Pushed by mwiesweg into branch 'master'.

Some work to stay on the same photo if one of the faces is removed,
unfortunately not sufficient yet.

CCBUG: 265025

M  +34   -0    digikam/items/imagecategorizedview.cpp     
M  +1    -0    digikam/items/imagecategorizedview.h     
M  +22   -0    libs/models/imagemodel.cpp     
M  +2    -0    libs/models/imagemodel.h     
M  +32   -13   libs/widgets/common/dcategorizedview.cpp     
M  +7    -0    libs/widgets/common/dcategorizedview.h     

http://commits.kde.org/digikam/92ffcf96c647a370b36dc580c5316d643b58f58c
Comment 7 Marcel Wiesweg 2011-07-11 17:03:03 UTC
Git commit 08fcf12475b3a213f4cbd67edac4f8a011648b70 by Marcel Wiesweg.
Committed on 09/07/2011 at 18:35.
Pushed by mwiesweg into branch 'master'.

Inherit the AssignNameOverlay from PersistentWidgetDelegateOverlay
to improve the behavior of this overlay, which is more than one-click.

CCBUG: 265025

M  +42   -18   digikam/items/assignnameoverlay.cpp     
M  +3    -2    digikam/items/assignnameoverlay.h     

http://commits.kde.org/digikam/08fcf12475b3a213f4cbd67edac4f8a011648b70
Comment 8 Marcel Wiesweg 2011-07-11 17:03:03 UTC
Git commit a632cd5257487dbeaa19dbd858d7bf53a96e30b0 by Marcel Wiesweg.
Committed on 09/07/2011 at 18:33.
Pushed by mwiesweg into branch 'master'.

Add a class PersistentWidgetDelegateOverlay with some additional behavior for overlays
which provide user interaction and keyboard focus
- when a "persistent" mode is entered, the overlay stays on its index and
  is not moved by mouse hover to other places or hidden
- when an overlay widget had focus, it is restored

CCBUG: 265025

M  +207  -5    libs/widgets/common/imagedelegateoverlay.cpp     
M  +78   -0    libs/widgets/common/imagedelegateoverlay.h     

http://commits.kde.org/digikam/a632cd5257487dbeaa19dbd858d7bf53a96e30b0
Comment 9 caulier.gilles 2011-12-14 13:48:05 UTC
Adam,

A lots of commits have been done by Marcel here.

This file still valid using digiKam 2.4 ?

Gilles Caulier
Comment 10 caulier.gilles 2014-06-24 13:44:39 UTC
We need feedback using last git/master code where a lots of improvements have be done (see next 4.1.0 release)

Gilles Caulier
Comment 11 caulier.gilles 2015-06-29 17:46:48 UTC
New digiKam 4.11.0 is available with official PKG installer for OSX.

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier
Comment 12 caulier.gilles 2015-08-22 06:40:49 UTC
digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.
Comment 13 caulier.gilles 2016-07-14 06:02:35 UTC
This file still valid using last stable 5.0.0 release ?
Gilles Caulier
Comment 14 caulier.gilles 2016-07-14 09:05:19 UTC
*** Bug 265022 has been marked as a duplicate of this bug. ***
Comment 15 caulier.gilles 2016-11-21 16:09:28 UTC
We need feedback with last digiKam AppImage Linux Bundle:

https://drive.google.com/open?id=0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 16 caulier.gilles 2016-11-26 10:34:36 UTC
This problem still reproducible using digiKam AppImage bundle 5.4.0 pre release
?

It available at this url :

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 17 caulier.gilles 2017-04-16 20:12:57 UTC
digiKam 5.5.0 is released officially

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

...and new 5.6.0 pre-release as bundle is available here :

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Please check if this problem still reproducible with these versions.

Thanks in advance

Gilles Caulier
Comment 18 caulier.gilles 2017-06-22 21:39:24 UTC
digiKam 5.6.0 is now release and available as bundle for Linux, MacOS and Windows.

Can you check if problem still exists with this version ?

Thanks in advance

Gilles Caulier
Comment 19 caulier.gilles 2017-11-30 09:31:04 UTC
Please update this entry from bugzilla with current 5.8.0 pre-release bundle to see if problem remain.

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

Thanks in advance

Gilles Caulier
Comment 20 caulier.gilles 2018-01-07 16:14:56 UTC
No feedback since a very long time in this file with a lots of commits done in source code. I close this file now. Reopen if
necessary.

Gilles Caulier