[digiKam-users] either face recognition screen is buggy or I still don't understand it - at least I can say that more convenient bulk change of face tags (no auto refresh / set faces via context menu) is neccessary #V5.9.0 Windows Feb 27 2018

[PackElend]

Hallo,

I have no clue what I do wrong but by tagging some faces I noticed the following:

1. When I do face recognition and change and/or confirm a recognized face it disappear immediately from the Unconfirmed collection (same in other collection). As digiKam takes a moment to refresh the collection and thumbnails moving up and down until all non relevant photos are disappeared I've already confirmed some face tags accidentally although the tag is wrong. It's getting really nasty to find wrongly tagged faces again and again
   
   
2. Adding tags via right click context menu or the captions sidebar adds only a general tag, not a face tag with corresponding rectangular  
   
   
3. Making a tag a face tag is done via the context menu, a tag doesn't need to be below People necessarily to become a face tag.
   
   
4. Counts in the People Tags sidebar doesn't match in the Filter side bar, that is properly related to 2.
   
   
5. Only if I change the suggested face tag it is accepted as real face tag and the counter of the corresponding face tag is incremented

In order do make assigning face tags easier I would love to have the option to:

1. prevent refreshing the list of recognized faces after you confirm a suggested face tag
2. an option to order this list by suggested face tag and location etc, basically allow tags to be dragged&dropped onto the column bar in the table view to be added as column.
3. Allow to confirm suggested face tags in the table view
4. Allow to change face tag via context menu and drag&drop selected pictures on a face tag in either sidebar 

I try to show these behavior by the screenshots below:

1. set  face tags via context menu or side bar
1. set via sidebar 
   
   
   
2. set via context menu
   
   
   
3. count is correct and faces can be filtered but counter on the left and on the right don't match. If filter in albums view even more picture show up. 
   
   
   
2. Location of face tag
1. setting  as face tag
   
   
   
2. can lead to several face branches:
   
   

[woenx]

Sorry for hijacking your thread, but since you brought it up, what is the
difference between tags that are within the "People" category and those that
are not?

I imported my photo collection from another picture manager, including
tagged faces, and some appear as a first-level keyword, others inside
"People" (I don't remember creating it) and some appear in both places at
the same time.

It's quite confusing and I'm scared of touching anything in case I lose my
tagged faces.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

I have been also playing with the face tagging feature, and I think that
there are still a few rough edges that could be improved:

- For instance, it is not intuitive to scan just one folder. There should be
an option to right click an album -> "Scan for faces" or similar. Right now,
you have to go to the "People" menu on the left -> "Scan for faces", expand
the "options" menu, and check those folders you want to explore (among
potentially hundreds of folders, which makes them quite difficult to find)

- Once the scan finishes, apparently nothing happened. It took me a while to
notice that there was an "Unknown" tag within "People" in the face list. I
think it should appear on top of the list, or in a distinct formatting or
section, so you don't have to scroll among lots of faces (I currently have
800-900 face tags) in order to find the "unknown" ones.

- By the way, a "tag" called "da" appeared within the "Unknown" person tag
and all unknown people appeared there. It is still there even when all
people have been correctly tagged. Is this normal/expected?

- Once you start tagging the unrecognized photos, if digikam thinks another
photo corresponds to the person you just tagged, it will assign that face to
that person's face tag, without telling you. That's ok, but in many cases
Digikam is not a 100% sure and makes a few false positives. The only way to
find them is going person by person and check if there are wrong faces
assigned to them.

- Related to the previous point, when browsing a specific person's face
tags, digikam will ask for confirmation for those tags which it is not sure
that they belong to that person. However, there's no possible way to
distinguish them from "confirmed" face tags unless you hover over it with
your mouse. There should be some distinctive formatting on those tags, so
you can see which ones are confirmed and which ones aren't. For instance,
Picasa places an orange mark on unconfirmed tags, places them at the end of
that person's face list, and includes a mark on the list of people so you
can see which persons have unconfirmed tags right away from the list.

- Also, as I mentioned in the post above. Some people end up as a
first-level list element, and some are placed inside a "People". I have no
idea what does it mean or why it is this way.

- Another possible improvement to the face recognition feature would be
grouping unknown faces. So if digikam doesn't know whose face it is, but it
is sure a group of 5 pictures correspond to the same person, they could
appear as a group so you only need to write their name once for all the
group.


Thanks for your time. Please, don't take these suggestions as a critic, but
as suggestions on how to improve usability. Even with these minor hiccups,
Digikam is one of the best photo managers out there and you're doing a great
work.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[AndriusWild]

Please make sure to submit your suggestion in KDE bugzilla as a wishlist. In that case if a new developer joins the project he/she will be able to find it and implement it if the suggestion is in the scope of the planned work.

Sent from my Samsung Galaxy smartphone.

-------- Original message --------

From: woenx <[hidden email]>

Date: 2018-03-05 5:01 AM (GMT-07:00)

To: [hidden email]

Subject: Re: [digiKam-users] either face recognition screen is buggy or I still don't understand it - at least I can say that more convenient bulk change of face tags (no auto refresh / set faces via context menu) is neccessary #V5.9.0 Windows Feb 27 2018

I have been also playing with the face tagging feature, and I think that
there are still a few rough edges that could be improved:

- For instance, it is not intuitive to scan just one folder. There should be
an option to right click an album -> "Scan for faces" or similar. Right now,
you have to go to the "People" menu on the left -> "Scan for faces", expand
the "options" menu, and check those folders you want to explore (among
potentially hundreds of folders, which makes them quite difficult to find)

- Once the scan finishes, apparently nothing happened. It took me a while to
notice that there was an "Unknown" tag within "People" in the face list. I
think it should appear on top of the list, or in a distinct formatting or
section, so you don't have to scroll among lots of faces (I currently have
800-900 face tags) in order to find the "unknown" ones.

- By the way, a "tag" called "da" appeared within the "Unknown" person tag
and all unknown people appeared there. It is still there even when all
people have been correctly tagged. Is this normal/expected?

- Once you start tagging the unrecognized photos, if digikam thinks another
photo corresponds to the person you just tagged, it will assign that face to
that person's face tag, without telling you. That's ok, but in many cases
Digikam is not a 100% sure and makes a few false positives. The only way to
find them is going person by person and check if there are wrong faces
assigned to them.

- Related to the previous point, when browsing a specific person's face
tags, digikam will ask for confirmation for those tags which it is not sure
that they belong to that person. However, there's no possible way to
distinguish them from "confirmed" face tags unless you hover over it with
your mouse. There should be some distinctive formatting on those tags, so
you can see which ones are confirmed and which ones aren't. For instance,
Picasa places an orange mark on unconfirmed tags, places them at the end of
that person's face list, and includes a mark on the list of people so you
can see which persons have unconfirmed tags right away from the list.

- Also, as I mentioned in the post above. Some people end up as a
first-level list element, and some are placed inside a "People". I have no
idea what does it mean or why it is this way.

- Another possible improvement to the face recognition feature would be
grouping unknown faces. So if digikam doesn't know whose face it is, but it
is sure a group of 5 pictures correspond to the same person, they could
appear as a group so you only need to write their name once for all the
group.


Thanks for your time. Please, don't take these suggestions as a critic, but
as suggestions on how to improve usability. Even with these minor hiccups,
Digikam is one of the best photo managers out there and you're doing a great
work.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

Ok, I will.

(I just didn't want to seem pushy, since these are mostly usability
improvements, not technical bugs, and I am not the one doing the actual work
here).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[AndriusWild]

When you submit a bug there is an importance  level you can set. You may select "wishlist " from the dropdown list so the devs will know it is not a bug it is a wish 

Sent from my Samsung Galaxy smartphone.

-------- Original message --------

From: woenx <[hidden email]>

Date: 2018-03-05 6:45 AM (GMT-07:00)

To: [hidden email]

Subject: Re: [digiKam-users] either face recognition screen is buggy or I still don't understand it - at least I can say that more convenient bulk change of face tags (no auto refresh / set faces via context menu) is neccessary #V5.9.0 Windows Feb 27 2018

Ok, I will.

(I just didn't want to seem pushy, since these are mostly usability
improvements, not technical bugs, and I am not the one doing the actual work
here).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[PackElend]

Hoi Marc,

thank you for hijacking my thread but I'm not able to answer your question. I'm still hoping that some else can answer those questions.
It is just one thing among others I noticed (as you).

I agree that face detection is till quite confusing and I'm scared of touching anything. I'm always afraid that there are some false face assignments due to the fiddle process and I need to go person by person and check if there are wrong faces.
It is quite a threshold using digikam as THE photo management tool.

Looking forward to your suggestion on bugzilla, please share the entry so that we may could add some point.

regards

stefan

On 05.03.2018 14:47, Andrey Goreev wrote:

When you submit a bug there is an importance  level you can set. You may select "wishlist " from the dropdown list so the devs will know it is not a bug it is a wish 

Sent from my Samsung Galaxy smartphone.

-------- Original message --------

From: woenx [hidden email]

Date: 2018-03-05 6:45 AM (GMT-07:00)

To: [hidden email]

Subject: Re: [digiKam-users] either face recognition screen is buggy or I still don't understand it - at least I can say that more convenient bulk change of face tags (no auto refresh / set faces via context menu) is neccessary #V5.9.0 Windows Feb 27 2018

Ok, I will.

(I just didn't want to seem pushy, since these are mostly usability
improvements, not technical bugs, and I am not the one doing the actual work
here).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

Ok, just one question (to whom is more familiarized with submitting bugs).
Would it be more appropriate to submit a single bug/wishlist report for this
topic, or one for every separate issue regarding face detection and
recognition?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[PackElend]

Good morning Marc,

I would suggest to open one wishlist bug what list each singel wishlist report. That allows to focus on each single wish and the reports remain clean. If you put all in one report that thing gets messy.
I suggesting a overhead report to keep track of all single reports otherwise it is likely that some wishes get lost.

Good morning all others,

could you comment the initial (my) email?

It is driving me crazy.

Thank you

Stefan

2018-03-05 17:41 GMT+01:00 woenx <[hidden email]>:

Ok, just one question (to whom is more familiarized with submitting bugs).
Would it be more appropriate to submit a single bug/wishlist report for this
topic, or one for every separate issue regarding face detection and
recognition?

--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[PackElend]

Good evening everyone,

as face tags are a frequent topic, is there still hope that someone is able to answer the initiating email of this discussion? 

@woenx, have you created the the wish reports yet?

2018-03-08 9:30 GMT+01:00 Stefan Mueller <[hidden email]>:

Good morning Marc,

I would suggest to open one wishlist bug what list each singel wishlist report. That allows to focus on each single wish and the reports remain clean. If you put all in one report that thing gets messy.
I suggesting a overhead report to keep track of all single reports otherwise it is likely that some wishes get lost.

Good morning all others,

could you comment the initial (my) email?

It is driving me crazy.

Thank you

Stefan

2018-03-05 17:41 GMT+01:00 woenx <[hidden email]>:

Ok, just one question (to whom is more familiarized with submitting bugs).
Would it be more appropriate to submit a single bug/wishlist report for this
topic, or one for every separate issue regarding face detection and
recognition?

--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

No yet (I was a bit busy at that moment), but I will now.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

Ok, these are the bug reports corresponding to face management bugs and
improvements as discussed in this thread (and other related threads), in
case anyone wants to follow them:

- Scan single image for faces: https://bugs.kde.org/show_bug.cgi?id=275671
- Inconsistent behavior of "People" Tag:
https://bugs.kde.org/show_bug.cgi?id=392008
- Face recognition assigns faces to people without confirmation, leading to
false positives: https://bugs.kde.org/show_bug.cgi?id=392010
- Metadata explorer does not show XMP face rectangles:
https://bugs.kde.org/show_bug.cgi?id=392013
- Show "Unknown" faces in a more visible and preeminent place in the
"People" list: https://bugs.kde.org/show_bug.cgi?id=392015
- Face tags and regular tags are mixed together and cannot be told apart:
https://bugs.kde.org/show_bug.cgi?id=392007
- Confirmed and unconfirmed faces look the same in a person's face list:
https://bugs.kde.org/show_bug.cgi?id=392016
- Merging, renaming and removing face tags:
https://bugs.kde.org/show_bug.cgi?id=392017
- No possible way of knowing which pictures within a regular tag have been
face-tagged: https://bugs.kde.org/show_bug.cgi?id=392020
- Weird automatic subtag within "Unknown people" called "da":
https://bugs.kde.org/show_bug.cgi?id=392009
- Position of a face tag appears on top or bottom of the list, instead of
being sorted alphabetically: https://bugs.kde.org/show_bug.cgi?id=392022
- Feature request: add "Ignored" group of faces:
https://bugs.kde.org/show_bug.cgi?id=392023
- Feature request: group similar faces in "Unknown" faces:
https://bugs.kde.org/show_bug.cgi?id=392024

PackElend, I didn't report the bug you explained in your first post since I
didn't fully understand the problem. I think it should be better if you
wrote a bug report yourself.

And that's it. If all of these were solved, face detection and recognition
would be just perfect (apart from the matter of accuracy, of course).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[PackElend]

Great work 

Will go through them as soon as I can spare some time 

On Sun, 18 Mar 2018, 21:58 woenx, <[hidden email]> wrote:

Ok, these are the bug reports corresponding to face management bugs and
improvements as discussed in this thread (and other related threads), in
case anyone wants to follow them:

- Scan single image for faces: https://bugs.kde.org/show_bug.cgi?id=275671
- Inconsistent behavior of "People" Tag:
https://bugs.kde.org/show_bug.cgi?id=392008
- Face recognition assigns faces to people without confirmation, leading to
false positives: https://bugs.kde.org/show_bug.cgi?id=392010
- Metadata explorer does not show XMP face rectangles:
https://bugs.kde.org/show_bug.cgi?id=392013
- Show "Unknown" faces in a more visible and preeminent place in the
"People" list: https://bugs.kde.org/show_bug.cgi?id=392015
- Face tags and regular tags are mixed together and cannot be told apart:
https://bugs.kde.org/show_bug.cgi?id=392007
- Confirmed and unconfirmed faces look the same in a person's face list:
https://bugs.kde.org/show_bug.cgi?id=392016
- Merging, renaming and removing face tags:
https://bugs.kde.org/show_bug.cgi?id=392017
- No possible way of knowing which pictures within a regular tag have been
face-tagged: https://bugs.kde.org/show_bug.cgi?id=392020
- Weird automatic subtag within "Unknown people" called "da":
https://bugs.kde.org/show_bug.cgi?id=392009
- Position of a face tag appears on top or bottom of the list, instead of
being sorted alphabetically: https://bugs.kde.org/show_bug.cgi?id=392022
- Feature request: add "Ignored" group of faces:
https://bugs.kde.org/show_bug.cgi?id=392023
- Feature request: group similar faces in "Unknown" faces:
https://bugs.kde.org/show_bug.cgi?id=392024

PackElend, I didn't report the bug you explained in your first post since I
didn't fully understand the problem. I think it should be better if you
wrote a bug report yourself.

And that's it. If all of these were solved, face detection and recognition
would be just perfect (apart from the matter of accuracy, of course).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[PackElend]

Hello there,
it has been a while since the last activity in this thread but I've installed digiKam 6 beta this week and checked if I still have the same troubles.
Before I start I may clarify a few things and would like to make some suggestion to ease the face tag / other tags discussion.

Prior this, I have to mention I try to avoid to use the word tag, as it used inflationary. All metadata records are stored in fields (see e.g. photometadata.org) which also often called tags (of the metadata), so a tag is anything what is used in digiKam to filter or search for images, e.g. keywords, colour label, star rating etc... Thus there  is to much space for interpretation what leads to all these questions due to irritations caused by the use of the word tag.

In order to lower the entry hurdle into the world of tagging I would suggest to be consistent with the offical wording, thus new users won't be confused by this. That means that the text for the tag will be named keyword, so on the source selection pane on the left will be Keywords and in filter pane on the right it will say Keywords Filter. The description shall rather say close to digiKam deals with metadata, grouped in (tags of): keywords, label, date and location.

First of all, Scan for Faces lists the results in the people view windows, see digiKam docs, where the user can confirm or correct the assumed names of the algorithm of the person in the image.
So far so good. As soon as a name is confirmed digiKam writes the data to the MP and MWG namespace of the XMP records, it sets a name and area.

More Details about those namespaces can be found here:

• Microsoft MP Tags (ExifTool)
  
• Microsoft MP Tags (Exif2.org)
• MWG Regions Tags (ExifTool)
  
• MWG Regions Tags (Exif2.org)

as Apple and Adobe write their information in the MWG namespace, it I would say that MWG is the leading namespace but inconsistent may lead to unexpected behaviour of the applications what reads them.

In my understanding these information should also be written to the IPTC Person structure as mentioned in the IPTC Photo Metadata User Guide (Persons Depicted in the Image), but is not. May someone can explain why?

In order to make images findable by a person's name, the name shall also be written to the keywords field of multiple namespaces, IPTC Photo Metadata User Guide (Persons Depicted in the Image) recommends caption and keywords. I cannot tell all relevant fields/namespaces. My research tells me that should be at least those:

• IPTC ⇒ Keywords, see: iptc.org
• XMP acdsee (ACD Systems) Tags ⇒ catergories, see: ExifTool / Exif2.org
• XMP digiKam Tags ⇒ Tag List, see: ExifTool / Exif2.org
• XMP dc (Dublin Core) Tags ⇒ Subject, see: ExifTool / Exif2.org
• XMP lr (Lightroom) Tags ⇒ hierarchicalSubject, see: ExifTool / Exif2.org
  
• XMP MediaPro Tags ⇒ Catalog Sets, see: ExifTool / Exif2.org
  
• Microsoft XMP Tags ⇒Las Keyword XMP, see: ExifTool / Exif2.org
• MWG Keywords Tags: ExifTool / Exif2.org

 has a field but ignored by digiKam, why?

• XMP prism Tags ⇒ Keyword: ExifTool
  

but to be exclude are:

• XMP xmp Tags, as it says non-standard: ExifTool
  
• XMP xmpMM Tags as it says undocumented: ExifTool
  
• XMP pdf Tags: ExifTool-> only for Adobe PDF
  

I reckon there isn't any leading field as a mismatch could lead to inconsistent search result, depending heavily on the used application.

I mentioned that, since as far as I know that content of person related metadata fields are not taken into account when you search or filter a collection by certain keywords. Thus, in order to make the names findable by digiKam, the name has to be added to the keywords related metadata fields to make the magic happen.

If I'm correct, what is the source of the list of the people pane on the left? In my opinion there are three options.

1. First, these are the keywords listed below the hierarchy level persons in the keyword list. If the user selects an name it filters images based on the keywords and shows the face area as described in the person related metadata field.
2. Second, digiKam reads the information given in the person related fields of the metadata of each image in this particular case . Afterwards it uses this data to populate the person pane. That would be quite of workload on the CPU and isn't very likely.
3. Third, it stores the information given in person related fields of the metadata of each image in the database recognition.db. Based on the information stored there digiKam knows which images are to be shown. In this case, are the face thumbnails are stored in this database as well or are they derived from each image, based on the region information?

The last question in this regard. What happens to unknown/unconfirmed faces? Are they stored immediately to the database but metadata isn't written until face is confirmed? That would explain, why they appear again, when you open the left people pane, after restart of digiKam. In addition that would indicate that my third theory above is the right one. 

In case the data in the left person pane isn't based on the keywords, as assumed before, the person tag shall be a classed differently, means it shall have a different symbol. That would help to distinguish easily between face tags and keyword tags. It would also the simplify the progress of understanding how tagging and face recognition work in digiKam.

In addition I would like to see some changes in regard to the unkown faces thumbnails.

Those wishes are most likely discussed in other bug reports. For convenience I listed those created by woenx and mine again.

As you see most wishes are still unresolved and mine will mostly a duplicate of presents ones I'll list them anyway in order to highlight their necessity.

I would like to be able to

1. stop auto refresh of the thumbnails to avoid confirming a wrong face accidentality. It is a pain in the arse to undo such accidents 
2. sort them at least by guessed faced.
   It would be preferred if sorting in any view is possible by any property what can be used to filter items
3. drag and drop selected faces over an Person Name
4. assign Person Name via right click menu as possible for tags
5. group similar faces in "Unknown" faces

what do you think before I put new ones in wish reports?

digikam Bug List - Component: Faces-Recognition Status: REPORTED, CONFIRMED, ASSIGNED, REOPENED
digikam Bug List - Component: Faces-Workflow Status: REPORTED, CONFIRMED, ASSIGNED, REOPENED

1. Bugs

   1. Bug 392013: Metadata explorer does not show XMP face rectangles
   2. Bug 392017: Merging, renaming and removing face tags
   3. Bug 392009: Weird automatic subtag within "Unknown people" called "da"
   4. Bug 392008: Inconsistent behaviour of "People" Tag

2. Wishes

   1. Wish 275671: Scan single image for faces
   2. Wish 392015: Show "Unknown" faces in a more visible and preeminent place in the "People" list
   3. Wish 392007: Face tags and regular tags are mixed together and cannot be told apart
   4. Wish 392016: Confirmed and unconfirmed faces look the same in a person's face list
   5. Wish 392020: No possible way of knowing which pictures within a regular tag have been face-tagged
   6. Wish 392022: Position of a face tag appears on top or bottom of the list, instead of being sorted alphabetically
   7. Wish 392023: Feature request: add "Ignored" group of faces:
   8. Wish 392024: Feature request: group similar faces in "Unknown" faces
      ⇒ Wish 384396: Wish: display faces sorted by similarity (pre-grouped) instead of album/time/..
   9. Wish 386291: only refresh found face list/pane upon user request
   10. Wish 254099: SCAN : refresh collection with a script in commandline

Am 19.03.2018 um 06:16 schrieb Stefan Mueller:

Great work 

Will go through them as soon as I can spare some time 

Sent from a fair mobile

On Sun, 18 Mar 2018, 21:58 woenx, <[hidden email]> wrote:

Ok, these are the bug reports corresponding to face management bugs and
improvements as discussed in this thread (and other related threads), in
case anyone wants to follow them:

- Scan single image for faces: https://bugs.kde.org/show_bug.cgi?id=275671
- Inconsistent behavior of "People" Tag:
https://bugs.kde.org/show_bug.cgi?id=392008
- Face recognition assigns faces to people without confirmation, leading to
false positives: https://bugs.kde.org/show_bug.cgi?id=392010
- Metadata explorer does not show XMP face rectangles:
https://bugs.kde.org/show_bug.cgi?id=392013
- Show "Unknown" faces in a more visible and preeminent place in the
"People" list: https://bugs.kde.org/show_bug.cgi?id=392015
- Face tags and regular tags are mixed together and cannot be told apart:
https://bugs.kde.org/show_bug.cgi?id=392007
- Confirmed and unconfirmed faces look the same in a person's face list:
https://bugs.kde.org/show_bug.cgi?id=392016
- Merging, renaming and removing face tags:
https://bugs.kde.org/show_bug.cgi?id=392017
- No possible way of knowing which pictures within a regular tag have been
face-tagged: https://bugs.kde.org/show_bug.cgi?id=392020
- Weird automatic subtag within "Unknown people" called "da":
https://bugs.kde.org/show_bug.cgi?id=392009
- Position of a face tag appears on top or bottom of the list, instead of
being sorted alphabetically: https://bugs.kde.org/show_bug.cgi?id=392022
- Feature request: add "Ignored" group of faces:
https://bugs.kde.org/show_bug.cgi?id=392023
- Feature request: group similar faces in "Unknown" faces:
https://bugs.kde.org/show_bug.cgi?id=392024

PackElend, I didn't report the bug you explained in your first post since I
didn't fully understand the problem. I think it should be better if you
wrote a bug report yourself.

And that's it. If all of these were solved, face detection and recognition
would be just perfect (apart from the matter of accuracy, of course).



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

As the one who opened some of these bug reports, I wholeheartedly agree with
your post.

I hope that the face tagging process keeps improving, as I think the current
usability is not the best for the final user.

I'll be glad to do some testing on my own if necessary as features are
implemented. I wish I had enough skills to work on the code myself, but I am
afraid of breaking something at this point.

PS: Are some of these issues something that could be addressed using
plugins?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Le sam. 2 févr. 2019 à 01:32, woenx <[hidden email]> a écrit :

As the one who opened some of these bug reports, I wholeheartedly agree with
your post.

I hope that the face tagging process keeps improving, as I think the current
usability is not the best for the final user.

I'll be glad to do some testing on my own if necessary as features are
implemented. I wish I had enough skills to work on the code myself, but I am
afraid of breaking something at this point.

PS: Are some of these issues something that could be addressed using
plugins?

Well, not really. In fact this is nothing done as plugin for face management. 

One piece of code which can be open as plugin is the recognition modules. API is already designed to be modular, but not exported.

This can be done through this GSoC 2019 project :

https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module

For all other problems listed here, in fact it's the Face management workflow which need to be review again and improved. In the current implementation, i separated well all the classes previously grouped as a huge common implementation. This will help to maintain and improve face management in the future...

Gilles Caulier

[PackElend]

Hello Woenx, Bonjour Gilles

thanks for those quick answer, at least we agree than some refurbishment is necessary ;-)

One piece of code which can be open as plugin is the recognition modules. API is already designed to be modular, but not exported.

This can be done through this GSoC 2019 project :

https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module

that would mean, when it will get done during GSoC 2019, we can write your own face recognition plug-in, what fulfils all these requirements, we desire?

We won't need to understand the face recognition process in detail, don't we? All what would happen to create an customize interface/GUI, wouldn't it?

the only option to make some changes now, to work on the digiKam source code and send a pull request, isn't it?

Any chance that anything will done before the GSoC 2019?

Could keep us posted in this thread if anything in this matter is going to be tackled?
I could port this to pixl.us for a more convenient way of discussion. 

This will help to maintain and improve face management in the future...

so there is hope :-D

What about my suggestion in regard of the wording philosophy in digiKam?

Stefan

Am 02.02.2019 um 10:22 schrieb Gilles Caulier:

Le sam. 2 févr. 2019 à 01:32, woenx <[hidden email]> a écrit :

As the one who opened some of these bug reports, I wholeheartedly agree with
your post.

I hope that the face tagging process keeps improving, as I think the current
usability is not the best for the final user.

I'll be glad to do some testing on my own if necessary as features are
implemented. I wish I had enough skills to work on the code myself, but I am
afraid of breaking something at this point.

PS: Are some of these issues something that could be addressed using
plugins?

Well, not really. In fact this is nothing done as plugin for face management. 

One piece of code which can be open as plugin is the recognition modules. API is already designed to be modular, but not exported.

This can be done through this GSoC 2019 project :

https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module

For all other problems listed here, in fact it's the Face management workflow which need to be review again and improved. In the current implementation, i separated well all the classes previously grouped as a huge common implementation. This will help to maintain and improve face management in the future...

Gilles Caulier

[Gilles Caulier-4]

Le sam. 2 févr. 2019 à 12:47, Stefan Müller <[hidden email]> a écrit :

Hello Woenx, Bonjour Gilles

thanks for those quick answer, at least we agree than some refurbishment is necessary ;-)

One piece of code which can be open as plugin is the recognition modules. API is already designed to be modular, but not exported.

This can be done through this GSoC 2019 project :

https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module

that would mean, when it will get done during GSoC 2019, we can write your own face recognition plug-in, what fulfils all these requirements, we desire?

yes, but i'm talking about a customized face recognition engine as 4 existing yet here :

https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition

We won't need to understand the face recognition process in detail, don't we? All what would happen to create an customize interface/GUI, wouldn't it?

The engine and the GUI are separated, as expected of course. The GUI to tag face is mostly implemented here :

* https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement => assignnamewidget.cpp/.h

Note : the rest of classes in this directory are relevant of the workflow : communication with the face engines (detection/recognition) and the face database to store face histogram.

* https://cgit.kde.org/digikam.git/tree/core/app/items/delegate => faceitemdelegate.cpp/.h 

* https://cgit.kde.org/digikam.git/tree/core/app/items/overlays => assignnameoverlay.cpp/.h and facerejectionoverlay.cpp/.h

 

the only option to make some changes now, to work on the digiKam source code and send a pull request, isn't it?

Not al all. It's a possible way, but, i'm always in favor to only use bugzilla as the main Agile project management tool. You have a file to create or already created, you build a patch against current implementation, and you attach file. It's simple, archived, and follow all QA requirement.

A pull request is a feature add by KDE team to try to recrut more contributors. But there is no link with bugzilla. If you have a bugzilla file to close with a PR, you need to manage both tools entries at the same time. This is a waste of time, and as i already said more than one time in the past, the time is precious.

PR can help visually to review and comment patch, but all can be done also with bugzilla.

So for me PR is so far not necessary and don't improve the project management workflow.

Bugzilla has the project story since the beginning (2001). And there i would not change this in the future...

Any chance that anything will done before the GSoC 2019?

No. Personalty, i must for 6.1.0

1/ Finalize the internal plugins API for Genric, Editor, and BQM.

2/ Document the API

3/ Export the API for external contribution. Currently all plugins are inside digiKam project.

4/ Prepare the rooms for the new students.

Later 6.1.0 :

1/ Prepare new plugins interface as :

 * BQM export tools : this is the prior step to do. We will have a student working on this topic (i hope). We have plenty of bugzilla entries relevant of this feature.

Typically, the hard-coded Batch Queue setting view to store processed files will be extended with many target as Collection (one already implemented), Local drive, FTP, SFTP, and or course the remote web-services through the unified API which have been already available since summer 2018 but not yet fully finalized. Typically, you prepare a list of files, you assign a piece of tools (resize, border, NR, sharp, ex), and at end, files will be automatically exported somewhere (as Flickr for ex).

 * Raw engine : the internal one based on libraw, one with RawTherapee (for ex), one with DarkTable (for ex). This will be a big step and require to separate well all implementation to be versatile. The code is already separated for libraw engine, but nothing was done to manage this feature with plugins.

 * Maintenance : All tools are hardcoded, and started in a specific order. It can be managed as modules, but code is not yet designed in this way.

 * Database : We have already a tool named migration which can be a good candidate, but plenty of new ones can be written : backup, export, etc. Do not ask me to make the database engine as module yet, it's a tedious project.

Voilà

Gilles Caulier

[J Albrecht]

Have you no shame? 

I cringe every time that I read about Facial Recognition software. You developers are like a bunch of giddy Manhattan Project nerds, gleefully and obliviously participating in the acceleration of our collective doom. You people are contributing to the development of scary, scary stuff. You’re not alone; Consider yourself members of a club which includes Custer Bomb Designers and Genome Modifiers. Like you, they see absolutely nothing wrong with what they’re doing because after all, they’re only building and promoting innocuous technology which will benefit “us”. Yeah, right. Tell that to the Uyghers…   …and to your children.

On 2 Feb 2019, at 08:31, Gilles Caulier <[hidden email]> wrote:

Le sam. 2 févr. 2019 à 12:47, Stefan Müller <[hidden email]> a écrit :

Hello Woenx, Bonjour Gilles

thanks for those quick answer, at least we agree than some refurbishment is necessary ;-)

One piece of code which can be open as plugin is the recognition modules. API is already designed to be modular, but not exported.

This can be done through this GSoC 2019 project :

https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module

that would mean, when it will get done during GSoC 2019, we can write your own face recognition plug-in, what fulfils all these requirements, we desire?

yes, but i'm talking about a customized face recognition engine as 4 existing yet here :

https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition

We won't need to understand the face recognition process in detail, don't we? All what would happen to create an customize interface/GUI, wouldn't it?

The engine and the GUI are separated, as expected of course. The GUI to tag face is mostly implemented here :

* https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement => assignnamewidget.cpp/.h

Note : the rest of classes in this directory are relevant of the workflow : communication with the face engines (detection/recognition) and the face database to store face histogram.

* https://cgit.kde.org/digikam.git/tree/core/app/items/delegate => faceitemdelegate.cpp/.h 

* https://cgit.kde.org/digikam.git/tree/core/app/items/overlays => assignnameoverlay.cpp/.h and facerejectionoverlay.cpp/.h

 

the only option to make some changes now, to work on the digiKam source code and send a pull request, isn't it?

Not al all. It's a possible way, but, i'm always in favor to only use bugzilla as the main Agile project management tool. You have a file to create or already created, you build a patch against current implementation, and you attach file. It's simple, archived, and follow all QA requirement.

A pull request is a feature add by KDE team to try to recrut more contributors. But there is no link with bugzilla. If you have a bugzilla file to close with a PR, you need to manage both tools entries at the same time. This is a waste of time, and as i already said more than one time in the past, the time is precious.

PR can help visually to review and comment patch, but all can be done also with bugzilla.

So for me PR is so far not necessary and don't improve the project management workflow.

Bugzilla has the project story since the beginning (2001). And there i would not change this in the future...

Any chance that anything will done before the GSoC 2019?

No. Personalty, i must for 6.1.0

1/ Finalize the internal plugins API for Genric, Editor, and BQM.

2/ Document the API

3/ Export the API for external contribution. Currently all plugins are inside digiKam project.

4/ Prepare the rooms for the new students.

Later 6.1.0 :

1/ Prepare new plugins interface as :

 * BQM export tools : this is the prior step to do. We will have a student working on this topic (i hope). We have plenty of bugzilla entries relevant of this feature.

Typically, the hard-coded Batch Queue setting view to store processed files will be extended with many target as Collection (one already implemented), Local drive, FTP, SFTP, and or course the remote web-services through the unified API which have been already available since summer 2018 but not yet fully finalized. Typically, you prepare a list of files, you assign a piece of tools (resize, border, NR, sharp, ex), and at end, files will be automatically exported somewhere (as Flickr for ex).

 * Raw engine : the internal one based on libraw, one with RawTherapee (for ex), one with DarkTable (for ex). This will be a big step and require to separate well all implementation to be versatile. The code is already separated for libraw engine, but nothing was done to manage this feature with plugins.

 * Maintenance : All tools are hardcoded, and started in a specific order. It can be managed as modules, but code is not yet designed in this way.

 * Database : We have already a tool named migration which can be a good candidate, but plenty of new ones can be written : backup, export, etc. Do not ask me to make the database engine as module yet, it's a tedious project.

Voilà

Gilles Caulier

[Gilles Caulier-4]

Le sam. 2 févr. 2019 à 15:52, J Albrecht <[hidden email]> a écrit :

Have you no shame? 

I cringe every time that I read about Facial Recognition software. You developers are like a bunch of giddy Manhattan Project nerds, gleefully and obliviously participating in the acceleration of our collective doom. You people are contributing to the development of scary, scary stuff. You’re not alone; Consider yourself members of a club which includes Custer Bomb Designers and Genome Modifiers. Like you, they see absolutely nothing wrong with what they’re doing because after all, they’re only building and promoting innocuous technology which will benefit “us”. Yeah, right. Tell that to the Uyghers…   …and to your children.

You talking to me ???

If yes, thanks for the noise and to help the project in a constructive way... It's always a pleasure to read this kind of words in an open source community.

Gilles Caulier