Bug 265022 - UI's handling of People tags is confusing
Summary: UI's handling of People tags is confusing
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Workflow (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-31 23:55 UTC by Adam Spiers
Modified: 2019-12-23 15:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Spiers 2011-01-31 23:55:25 UTC
Version:           2.0.0 (using KDE 4.5.5) 
OS:                Linux

The People tags can be used in two ways:

(1) manual tagging of photos in the same way that any other
    (non-People) tags are used

(2) tagging by the face detection/recognition code

Clearly the backend makes a distinction between these uses - I think
I'm right in saying that basically (1) is governed by the ImageTags
table, whereas (2) is governed by the TagProperties and
ImageTagProperties tables which use person/kfaceId and
tagRegion/autodetectedFace properties respectively.

However, the way this is presented in the UI is confusing.  The Tags
sidebar corresponds to (1), but when you use the People sidebar you
get a mix of (1) and (2): the image counts shown in parentheses
correspond to the number of photos with that manual tag as per (1),
but if you click on that tag, the preview pane in the middle only
shows photos matching that tag as per (2).

So for example if you manually tag 50 photos with 'People/Joe' before
you do any face recognition, and then via face recognition tag a
further 10, you will see 'Joe (50)' in the People sidebar, and if you
click on it, you will only see 10 photos in the middle pane.  This is
difficult for a normal user to understand.

I'm not sure what the best UI solution for this is, but ideally it
should allow some way of showing any of the following:

  - all photos which have a tagRegion corresponding to Joe

  - all photos which have a tagid corresponding to Joe but no
    tagRegion - this could be useful for example prior to exporting to
    facebook to ensure that any photos containing Joe would be
    properly tagged in facebook (which requires a tag region)

  - all photos which have a tagRegion corresponding to Joe but no
    normal tagid (although it looks like digikam automatically adds a
    tagid when setting a kfaceId/tagRegion? in which case this case is
    not needed)

Do we have any UI design experts who could help?

Reproducible: Always
Comment 1 Adam Spiers 2011-02-01 00:20:15 UTC
See also bug 265025 for other face tagging usability issues.
Comment 2 Marcel Wiesweg 2011-02-01 20:28:58 UTC
Can we agree there is a bug that the counter in the People sidebar is showing the wrong number?
It's quite simple - there is special handling missing/unimplemented for this case, so you just get the default behavior. It's no design decision ;-)
Comment 3 Adam Spiers 2011-02-01 21:28:12 UTC
(In reply to comment #2)
> Can we agree there is a bug that the counter in the People sidebar is showing
> the wrong number?

Sure :)

> It's quite simple - there is special handling missing/unimplemented for this
> case, so you just get the default behavior. It's no design decision ;-)

OK :)  So fixing the counter would be great.  But it would also be extremely useful to implement the second use case I listed - "all photos which have a tagid corresponding to Joe but no tagRegion".  (The first use case is the current behaviour, and the third one is probably not needed.)

Does export to facebook include the tagRegion already?  If not, I will file an enhancement bug for that ;-)  Thanks!
Comment 4 Marcel Wiesweg 2011-07-11 17:03:39 UTC
Ok, the counter is fixed by now (in some other bug report).
Remains the wish to list tags with no tag region assigned. It's not really 
difficult in the backend, but I dont know where to put this into the UI.
Comment 5 caulier.gilles 2011-12-14 14:05:29 UTC
Adam,

it still valid using digiKam 2.4 ?

Gilles Caulier
Comment 6 caulier.gilles 2014-08-24 12:03:39 UTC
Adam,

This entry still valid using last digiKam 4.2.0 ?

Gilles Caulier
Comment 7 caulier.gilles 2015-06-28 09:41:15 UTC
New digiKam 4.11.0 is available :

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

Can you reproduce the problem with this release ?

Gilles Caulier
Comment 8 caulier.gilles 2015-08-22 06:37:25 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 9 caulier.gilles 2016-07-14 06:02:57 UTC
This file still valid using last stable 5.0.0 release ?
Gilles Caulier
Comment 10 caulier.gilles 2016-07-14 09:05:19 UTC

*** This bug has been marked as a duplicate of bug 265025 ***
Comment 11 caulier.gilles 2019-12-23 15:27:13 UTC
Not reproducible using 7.0.0-beta1