<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div dir="ltr">Hello there,<br>
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.<br>
Before I start I may clarify a few things and would like to make
some suggestion to ease the face tag / other tags discussion.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Prior this, I have to mention I try to avoid to use
the word <i>tag</i>, as it used inflationary. All metadata
records are stored in fields (see e.g. <a moz-do-not-send="true"
href="http://photometadata.org/META-Resources-Field-Guide-to-Metadata#Keywords">photometadata.org</a>)
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.
<div dir="ltr">In order to lower the entry hurdle into the world
of tagging I would suggest to be consistent with the <i>offical
</i>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 <i>Keywords</i> and
in filter pane on the right it will say Keywords Filter. The
description shall rather say close to <i>digiKam deals with
metadata, grouped in (tags of): keywords, label, date and
location</i>. </div>
<div dir="ltr"> <br>
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. <br>
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.</div>
<div dir="ltr">
<div dir="ltr">More Details about those namespaces can be found
here:</div>
<div dir="ltr">
<ul>
<li><font size="-1"><a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Microsoft.html#MP"
moz-do-not-send="true">Microsoft MP Tags (ExifTool)</a>
<br>
</font> </li>
<font size="-1"> </font>
<li><font size="-1"><a moz-do-not-send="true"
href="http://www.exiv2.org/tags-xmp-MP.html">Microsoft
MP Tags (Exif2.org)</a></font></li>
<font size="-1"> </font>
<li><font size="-1"><a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/MWG.html#Regions"
moz-do-not-send="true">MWG Regions Tags (ExifTool)</a>
<br>
</font> </li>
<font size="-1"> </font>
<li><font size="-1"><a moz-do-not-send="true"
href="http://www.exiv2.org/tags-xmp-mwg-rs.html">MWG
Regions Tags (Exif2.org)</a></font> </li>
</ul>
<p>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. <br>
</p>
<p>In my understanding these information should also be
written to the <a
href="https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#person-structure"
moz-do-not-send="true">IPTC Person structure</a> as
mentioned in the <a
href="https://www.iptc.org/std/photometadata/documentation/userguide/index.htm#!Documents/personsdepictedintheimage.htm"
moz-do-not-send="true">IPTC Photo Metadata User Guide
(Persons Depicted in the Image)</a>, but is not. May
someone can explain why?<br>
</p>
</div>
</div>
<div dir="ltr">In order to make images findable by a person's
name, the name shall also be written to the keywords field of
multiple namespaces, <a
href="https://www.iptc.org/std/photometadata/documentation/userguide/index.htm#!Documents/personsdepictedintheimage.htm"
moz-do-not-send="true">IPTC Photo Metadata User Guide (Persons
Depicted in the Image)</a> recommends caption and keywords. I
cannot tell all relevant fields/namespaces. My research tells me
that
should be at least those: <br>
</div>
<div dir="ltr">
<ul>
<ul>
</ul>
</ul>
<ul>
<li>IPTC ⇒ Keywords, see: <a
href="https://iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#keywords"
moz-do-not-send="true">iptc.org</a></li>
<li>XMP acdsee (<a moz-do-not-send="true"
href="https://www.acdsystems.com/">ACD Systems</a>) Tags ⇒
catergories, see: <a
href="http://www.exiv2.org/tags-xmp-acdsee.html">ExifTool</a>
/ <a href="http://www.exiv2.org/tags-xmp-acdsee.html">Exif2.org</a></li>
<li>XMP digiKam Tags ⇒ Tag List, see: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#digiKam"
moz-do-not-send="true">ExifTool</a> / <a
href="http://www.exiv2.org/tags-xmp-digiKam.html">Exif2.org</a></li>
<li>XMP dc (<a moz-do-not-send="true"
href="http://dublincore.org/">Dublin Core</a>) Tags ⇒
Subject, see: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#dc"
moz-do-not-send="true">ExifTool</a> / <a
href="http://www.exiv2.org/tags-xmp-dc.html">Exif2.org</a></li>
<li>XMP lr (Lightroom) Tags ⇒ hierarchicalSubject, see: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#Lightroom"
moz-do-not-send="true">ExifTool</a> / <a
moz-do-not-send="true"
href="http://www.exiv2.org/tags-xmp-lr.html">Exif2.org</a><br>
</li>
<li>XMP <a moz-do-not-send="true" href="MediaPro">MediaPro </a>Tags
⇒ Catalog Sets, see: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#MediaPro"
moz-do-not-send="true">ExifTool</a> / <a
moz-do-not-send="true"
href="http://www.exiv2.org/tags-xmp-mediapro.html">Exif2.org</a><br>
</li>
<li><a moz-do-not-send="true"
href="https://docs.microsoft.com/en-us/windows/desktop/wic/-wic-codec-metadatahandlers">Microsoft
XMP</a> Tags ⇒Las Keyword XMP, see: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Microsoft.html#XMP"
moz-do-not-send="true">ExifTool</a> / <a
moz-do-not-send="true"
href="http://www.exiv2.org/tags-xmp-MP.html">Exif2.org</a></li>
<li><a moz-do-not-send="true" href="metadataworkinggroup.com">MWG</a>
Keywords Tags: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/MWG.html#Keywords"
moz-do-not-send="true">ExifTool</a> / <a
moz-do-not-send="true"
href="http://www.exiv2.org/tags-xmp-mwg-kw.html">Exif2.org</a></li>
</ul>
has a field but ignored by digiKam, why?</div>
<div dir="ltr">
<ul>
<li>XMP <a moz-do-not-send="true"
href="http://www.prismstandard.org/">prism</a> Tags ⇒
Keyword: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#prism"
moz-do-not-send="true">ExifTool</a> <br>
</li>
</ul>
but to be exclude are:<br>
<ul>
<li>XMP <a moz-do-not-send="true"
href="https://www.adobe.com/devnet/xmp.html">xmp</a> Tags,
as it says <i>non-standard</i>: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#xmp"
moz-do-not-send="true">ExifTool</a> <br>
</li>
<li>XMP xmpMM Tags as it says <i>undocumented</i>: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#xmpMM"
moz-do-not-send="true">ExifTool</a> <br>
</li>
<li>XMP pdf Tags: <a
href="https://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#pdf"
moz-do-not-send="true">ExifTool</a>-> only for Adobe
PDF <br>
</li>
</ul>
</div>
<div dir="ltr">I reckon there isn't any leading field as a
mismatch could lead to inconsistent search result, depending
heavily on the used application.<br>
</div>
<div dir="ltr"> <br>
</div>
<div dir="ltr"> 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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. <br>
<ol>
<li> First, these are the keywords listed below the hierarchy
level <i>persons</i> 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. </li>
<li>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. </li>
<li>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?</li>
</ol>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. <br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.<br>
</div>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">In addition I would like to see some changes in
regard to the <i>unkown </i>faces thumbnails.<br>
<div dir="ltr">Those wishes are most likely discussed in other bug
reports. For convenience I listed those created by woenx and
mine again.</div>
<div dir="ltr">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. <br>
</div>
<div dir="ltr">I would like to be able to </div>
<div dir="ltr">
<ol>
<li>stop auto refresh of the thumbnails to avoid confirming a
wrong face accidentality. It is a pain in the arse to undo
such accidents </li>
<li> sort them at least by guessed faced.<br>
It would be preferred if sorting in any view is possible by
any property what can be used to filter items</li>
<li>drag and drop selected faces over an <i>Person Name</i></li>
<li>assign <i>Person Name</i> via right click menu as
possible for tags</li>
<li>group similar faces in "Unknown" faces </li>
</ol>
<div dir="ltr">what do you think before I put new ones in wish
reports?<br>
</div>
<div dir="ltr"><br>
<ol>
<a
href="https://bugs.kde.org/buglist.cgi?bug_status=__open__&component=Faces-Recognition&list_id=1583144&product=digikam"
moz-do-not-send="true">digikam Bug List - Component:
Faces-Recognition Status: REPORTED, CONFIRMED, ASSIGNED,
REOPENED</a> <br>
<a
href="https://bugs.kde.org/buglist.cgi?bug_status=__open__&component=Faces-Workflow&list_id=1583148&product=digikam"
moz-do-not-send="true">digikam Bug List - Component:
Faces-Workflow Status: REPORTED, CONFIRMED, ASSIGNED,
REOPENED</a>
<li>
<p>Bugs</p>
<ol>
<li><del><a
href="https://bugs.kde.org/show_bug.cgi?id=392013"
moz-do-not-send="true">Bug 392013</a></del>:
Metadata explorer does not show XMP face rectangles</li>
<li><del><a
href="https://bugs.kde.org/show_bug.cgi?id=392017"
moz-do-not-send="true">Bug 392017</a></del>:
Merging, renaming and removing face tags</li>
<li><del><a
href="https://bugs.kde.org/show_bug.cgi?id=392009"
moz-do-not-send="true">Bug 392009</a></del>: Weird
automatic subtag within "Unknown people" called "da"</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392008"
moz-do-not-send="true">Bug 392008</a>: Inconsistent
behaviour of "People" Tag</li>
</ol>
</li>
<li>
<p>Wishes</p>
<ol>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=275671"
moz-do-not-send="true"><del>Wish 275671</del></a>:
Scan single image for faces </li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392015"
moz-do-not-send="true">Wish 392015</a>: Show
"Unknown" faces in a more visible and preeminent place
in the "People" list</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392007"
moz-do-not-send="true">Wish 392007</a>: Face tags
and regular tags are mixed together and cannot be told
apart</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392016"
moz-do-not-send="true">Wish 392016</a>: Confirmed
and unconfirmed faces look the same in a person's face
list</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392020"
moz-do-not-send="true">Wish 392020</a>: No possible
way of knowing which pictures within a regular tag
have been face-tagged</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392022"
moz-do-not-send="true">Wish 392022</a>: Position of
a face tag appears on top or bottom of the list,
instead of being sorted alphabetically</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392023"
moz-do-not-send="true">Wish 392023</a>: Feature
request: add "Ignored" group of faces: </li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=392024"
moz-do-not-send="true">Wish 392024</a>: Feature
request: group similar faces in "Unknown" faces <br>
⇒ <a
href="https://bugs.kde.org/show_bug.cgi?id=384396"
moz-do-not-send="true">Wish 384396</a>: Wish:
display faces sorted by similarity (pre-grouped)
instead of album/time/..</li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=386291"
moz-do-not-send="true">Wish 386291</a>: only refresh
found face list/pane upon user request </li>
<li><a
href="https://bugs.kde.org/show_bug.cgi?id=254099"
moz-do-not-send="true">Wish 254099</a>: <span
id="summary_container"><span
id="short_desc_nonedit_display">SCAN : refresh
collection with a script in commandline</span></span></li>
</ol>
</li>
</ol>
<p> </p>
<div bgcolor="#FFFFFF"><br>
<br>
<p><br>
</p>
<div class="gmail-m_9026140557679506384moz-cite-prefix">Am
19.03.2018 um 06:16 schrieb Stefan Mueller:<br>
</div>
<blockquote type="cite">
<div dir="auto">Great work
<div dir="auto">Will go through them as soon as I can
spare some time <br>
<br>
<div dir="auto">Sent from a fair mobile </div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sun, 18 Mar 2018, 21:58 woenx, <<a
href="mailto:marcpalaus@hotmail.com" target="_blank"
moz-do-not-send="true">marcpalaus@hotmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Ok, these are the
bug reports corresponding to face management bugs and<br>
improvements as discussed in this thread (and other
related threads), in<br>
case anyone wants to follow them:<br>
<br>
- Scan single image for faces: <a
href="https://bugs.kde.org/show_bug.cgi?id=275671"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=275671</a><br>
- Inconsistent behavior of "People" Tag:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392008"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392008</a><br>
- Face recognition assigns faces to people without
confirmation, leading to<br>
false positives: <a
href="https://bugs.kde.org/show_bug.cgi?id=392010"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392010</a><br>
- Metadata explorer does not show XMP face rectangles:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392013"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392013</a><br>
- Show "Unknown" faces in a more visible and
preeminent place in the<br>
"People" list: <a
href="https://bugs.kde.org/show_bug.cgi?id=392015"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392015</a><br>
- Face tags and regular tags are mixed together and
cannot be told apart:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392007"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392007</a><br>
- Confirmed and unconfirmed faces look the same in a
person's face list:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392016"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392016</a><br>
- Merging, renaming and removing face tags:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392017"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392017</a><br>
- No possible way of knowing which pictures within a
regular tag have been<br>
face-tagged: <a
href="https://bugs.kde.org/show_bug.cgi?id=392020"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392020</a><br>
- Weird automatic subtag within "Unknown people"
called "da":<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392009"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392009</a><br>
- Position of a face tag appears on top or bottom of
the list, instead of<br>
being sorted alphabetically: <a
href="https://bugs.kde.org/show_bug.cgi?id=392022"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392022</a><br>
- Feature request: add "Ignored" group of faces:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392023"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392023</a><br>
- Feature request: group similar faces in "Unknown"
faces:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=392024"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://bugs.kde.org/show_bug.cgi?id=392024</a><br>
<br>
PackElend, I didn't report the bug you explained in
your first post since I<br>
didn't fully understand the problem. I think it should
be better if you<br>
wrote a bug report yourself.<br>
<br>
And that's it. If all of these were solved, face
detection and recognition<br>
would be just perfect (apart from the matter of
accuracy, of course).<br>
<br>
<br>
<br>
--<br>
Sent from: <a
href="http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html</a><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>