[digiKam-users] 7.2 (beta) Face detection feedback

Sun Oct 25 19:59:03 GMT 2020

I have one more:

11: When people have a long name that is too long to fit in the input
filed it appears that Digikam scrolls to the end of the name in the input
field. Example here:
[image: image.png]

The problem is, that when you have lots of photos of people within the same
family they tend to all have the same last names. So it becomes difficult
to verify that DK detected the person correctly when showing only the end
of the name. And in order to see the first part of the name you have to do
this:
a) Hover the image with the mouse
b) Click the input field
c) Press Home button or press left arrow a bunch of times (taking several
seconds)

I would suggest something like this instead: Each group presented is
instead various persons. And there could be a button to confirm the
detection for the entire group and a button to confirm  selected images in
that group.
Bonus: If there would be shown some kind of "confidence score" indicating
how sure DK is that this is indeed the matched person.

[image: image.png]

Den søn. 25. okt. 2020 kl. 20.27 skrev Thomas D <sdktda at gmail.com>:

> Hi,
>
> Just want to say that I love digikam and use it extensively and have used
> it for over a decade. Keep up the good work!
>
> I also experience frequent crashes with face detection.
> Please let me know if there is anything I can do in order to help
> troubleshoot or debug this.
>
>
> I *think* I agree with the suggestion in #2 below. Although, I have read
> it twice and am not entirely sure I understand it.
>
> I have one addition: On my computer (modern 6 core i7 CPU, 32 GB RAM, 1 TB
> NVMe SSD) DigiKam is almost unusable while "Detect faces" or "Recognize
> faces" processes are running. These processes run for a very long time.
> Thus, it would be really helpful if they did not influence the UI while
> running.
>
>
> Regarding #3: I am also hosting my photo collection on a NAS (samba share)
> and using DK on a Win10 client. I have the digikam database, thumbnail
> database, etc. stored locally on my C:-drive. I think this works OK. Can't
> you do the same in order to fix your problem? Or am I missing something?
>
> I would also be very interested in  some guidelines regarding #5.
>
>
> I have some more points here:
>
>
> (continuing numbering from previous list)
>
> 6: When going through Unconfirmed faces the UI is a bit confusing:  there
> seems to be two buttons that does the exact same judging by the help
> text/mouse hover hint text. These buttons are seen in the screenshot here.
> The red X in the upper right cornor and the "minus button" at the bottom
> right. Both say: "If this is not a face, click to reject it".
> I think it is confusing that there are two buttons that does the same with
> very different symbols. Also I am in doubt: Do they actually do the same?
> If so, I think one should be left out. Also I am really missing an
> operation here. The operation I am missing a button for is this: Lets say
> that DK detected a face. This face is just some random person in the crowd
> of a concert or something. This is not a person I know or am interested in
> tagging. I do not want to "train" DK's ML model that it is not a face, so
> clicking "this is not a face" would be wrong. Because it IS a face. I just
> want to *ignore* this face as unintesting.
> I could, of course, create a person called UNKNOWN or John Doe or
> something like that and tag all faces like this as this pseudo-person.
> However, this is probably not a good idea, because then I will train DK's
> ML that this is actually a person that has many different faces. And I
> guess this will screw the ML up over time so that it will start to
> recognize a whole bunch of people as this unknown person.
> [image: image.png]
>
> 7: Another thing regarding the screenshot above. What does the minus
> button in the upper left corner do? In my version of DK, it does not seem
> to have any textual hint when hovering.
>
> 8: When tagging/confirming faces, it is a bit cumbersome to actually
> verify the face detection because you have to hover each image to see who
> DK detected it as. Instead, I think it should show the name directly on
> each face. This is almost the only relevant information to show except for
> the actual face image. I mean, stuff like file name, date, image
> resolution, size, etc. are much less important when doing face detection.
>
>
> 9: I have noticed that for some people I may only have a single photo or
> two of them. In these cases DK seems to find a LOT of spurious matches on
> these persons. Maybe this is something that could be tuned?
>
> 10: In my photo collection, I have photos of my children and other family
> members from back when they were babies and some of them are adult now. So
> I have *many* photos of the same persons in very different ages. However,
> DK seems to be confused by this. For example, when I have tagged a person
> as when they were baby, suddenly a lot of other babies become matched to
> this person. Is there any fix for this?
>
>
>
>
>
> Den søn. 25. okt. 2020 kl. 08.01 skrev <bryan at gillson.net>:
>
>> A few comments and questions on 7.2 beta and face detection:
>>
>>
>>
>>    1. I’m still suffering from occasional crashes, though they are more
>>    intermittent than 7.1. I know the Digikam team is already tracking these
>>    down as a priority, but let me know if logs would help.
>>    2. A suggestion for a UX change: After face detection, I multiselect
>>    thumbnails and confirm “unconfirmed” faces and manually tag others.
>>    Selecting the proper name causes the selected thumbnails to disappear, then
>>    reappear, then disappear (one at a time) as they’re processed. This shifts
>>    the remaining thumbnails around, making it difficult to multiselect another
>>    set of faces without error. I would prefer that faces “in process” simply
>>    stay hidden after selecting the name, and only appears again in the
>>    appropriate category (either “Confirmed” or in the proper People tag). This
>>    way I could continue “queueing up” new faces to process while KD works on
>>    the others.
>>    3. The face recognition workflow on a NAS-based setup really
>>    reinforces the need to separate thumbs.db into a local database.
>>    Performance is abysmal when refreshing thumbnails, and makes working over
>>    even a gigabit LAN very frustrating. Bug 297299 (
>>    https://bugs.kde.org/show_bug.cgi?id=297922) covers this feature
>>    request. Is it in the plan to address this?
>>    4. While on the topic of performance, are any bottlenecks being
>>    investigated to increase speed when using a network DB (MariaDB)? Neither
>>    CPU, network, database, nor disk statistics show high use during the
>>    recognition process. I would expect the database and network to be getting
>>    hit hard when retrieving pictures, then seeing the RAM and CPU spike during
>>    recognition. Instead, everything just goes at a trickle.
>>    5. Finally, is there any documentation on how to optimize the
>>    Detection process? What is more effective: confirming faces in the
>>    Unconfirmed tag? Correcting incorrectly recognized faces in a specific
>>    People tag? Adding new pics to known faces that are in Unknown, to better
>>    train the AI? Is it better to tag many samples of a person’s face, or a
>>    few? How frequently should I re-run “Recognize faces” after
>>    adding/correcting/confirming faces? Given the significant time investment
>>    in tagging and recognizing, guidance on the above could save dozens of
>>    hours of effort.
>>
>>
>>
>> I love Digikam, and truly appreciate all the effort. Please don’t take
>> the above as criticism or complaints, but questions/suggestions to make a
>> great product better.
>>
>>
>>
>> Thank you.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201025/51a384ed/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9857 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201025/51a384ed/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4095 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201025/51a384ed/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 50434 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201025/51a384ed/attachment-0005.png>