[digiKam-users] 7.2 (beta) Face detection feedback
Thomas D
sdktda at gmail.com
Tue Oct 27 10:40:56 GMT 2020
One more thing:
15:
Regarding Settings --> Face Accuracy.
It is unclear if this setting affects "Detect faces" or "Recognize faces"
or both.
[image: image.png]
16:
A suggestion: In the Tags section, write the number of new items with a
different color to more easily distinguish it from the other number.
Example:
[image: image.png]
It might even be possible to write both numbers within the same pair of
parentheses.
Example:
Instead of writing (265) (133 new), maybe it would be better to write:
(265, 133 new)
Not sure. But maybe this would be a bit easier to read.
What do you think?
Den tir. 27. okt. 2020 kl. 08.44 skrev Thomas D <sdktda at gmail.com>:
> Hi,
>
> I do not think that it is color labels. I do not use these (knowingly).
> You mention that it might be something that comes from the camera. So I
> tried checking color labels by rightclick --> Assign Labels --> Color. Then
> I checked if any color is selected. It does not seem to be. See the
> attached screenshot.
>
>
> [image: image.png]
>
>
>
>
>
> Den man. 26. okt. 2020 kl. 22.07 skrev Mike Morrison <mike at mikemorr.com>:
>
>> I think the outer border is a color tag or flag. Some photos I imported
>> from one camera came with the color tags already applied; I don't know why.
>>
>> +1 to all your feedback, by the way.
>>
>>
>> On Mon, Oct 26, 2020, 3:24 PM Thomas D <sdktda at gmail.com> wrote:
>>
>>> Some more feedback:
>>>
>>> 14:
>>> How are colored borders to be interpreted?
>>> I figure that green borders immediately around image means that it is a
>>> match but unconfirmed.
>>> But then I noticed some photos have a different colored border around
>>> the thumbnail frame. This other color can be yellow or red (and maybe other
>>> colors?). Example here:
>>> [image: image.png]
>>>
>>>
>>> What does this mean?
>>> The outer border does not seem to go away when the image has been
>>> confirmed.
>>>
>>>
>>>
>>>
>>> Den man. 26. okt. 2020 kl. 11.07 skrev Thomas D <sdktda at gmail.com>:
>>>
>>>> Some more feedback:
>>>> 13:
>>>> When applying a lot of face tags, a progress bar is shown in the bottom
>>>> left corner with the text "Processing items".
>>>> This progress bar behaves strangely. Instead of starting at 0 % and
>>>> progressing to 100 % it seems to start at 100 % and progress to 0 %.
>>>> If this is to be a progress bar, it should probably be reversed. If it
>>>> instead is meant as "this many items in the queue to be processed" then it
>>>> should probably be shown as that somehow. Maybe just by changing the text
>>>> to "Processing items: 42 og 117 remaining..." or something like that.
>>>>
>>>> [image: image.png]
>>>>
>>>>
>>>> Den man. 26. okt. 2020 kl. 09.04 skrev Thomas D <sdktda at gmail.com>:
>>>>
>>>>>
>>>>> Still working on tagging photos. I must say that I am very impressed
>>>>> by this and DK in general!
>>>>> I have encountered one more thing:
>>>>>
>>>>> 12:
>>>>> When tagging faces I sometimes accidentally tag a face with the wrong
>>>>> name. This could be that I accidentally hit Enter too early when typing in
>>>>> the name or I click the wrong name in the drop down menu by accident. When
>>>>> this happens I have a difficult time finding how to easily undo this
>>>>> mistake. What is the correct way to undo this?
>>>>> Would it be possible to have an Undo action like most other programs
>>>>> mapped to Ctrl+Z or something like that?
>>>>> Maybe it is already there and I just cannot find it?
>>>>>
>>>>>
>>>>>
>>>>> Den søn. 25. okt. 2020 kl. 21.03 skrev Thomas D <sdktda at gmail.com>:
>>>>>
>>>>>> One more suggestion:
>>>>>>
>>>>>> When clicking a person, it should be possible to toggle
>>>>>> confirmed/unconfirmed in the Thumbnails view.
>>>>>>
>>>>>> Den søn. 25. okt. 2020 kl. 21.59 skrev Thomas D <sdktda at gmail.com>:
>>>>>>
>>>>>>>
>>>>>>> I have a suggestion based on my previous:
>>>>>>> > Bonus: If there would be shown some kind of "confidence score"
>>>>>>> indicating how sure DK is that this is indeed the matched person.
>>>>>>>
>>>>>>> The more I use this face detection feature the more I think this is
>>>>>>> really helpful. I also think it would be really beneficial if DK would show
>>>>>>> the three or five best matches for any matches below a certain (high)
>>>>>>> threshold. For example, I have a hunch that DK *almost* detects correctly
>>>>>>> and maybe its second guess would be right. So then when I am going through
>>>>>>> Unconfirmed, I can quickly click one of these options. Of course I should
>>>>>>> still be able to write in the input field in case it is way off.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Den søn. 25. okt. 2020 kl. 20.59 skrev Thomas D <sdktda at gmail.com>:
>>>>>>>
>>>>>>>> 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/20201027/ff9cc324/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/20201027/ff9cc324/attachment-0008.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/20201027/ff9cc324/attachment-0009.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/20201027/ff9cc324/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2816 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201027/ff9cc324/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4523 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201027/ff9cc324/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19719 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201027/ff9cc324/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4566 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201027/ff9cc324/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5329 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20201027/ff9cc324/attachment-0015.png>
More information about the Digikam-users
mailing list