<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
@Jean-François,<br>
<br>
This sounds all very reasonable and I agree with you totally.<br>
Perhaps I can convince my client to stop using PersonInImage, for
future sake :) That would solve my problem too.<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Op 16-04-13 11:13, Jean-François
Rabasse schreef:<br>
</div>
<blockquote
cite="mid:alpine.LNX.2.00.1304161108260.8208@azrael.victoria.net"
type="cite">
<br>
<br>
Hello Jack,
<br>
<br>
I'd like to add a few comments to Simon's post.
<br>
<br>
<br>
On Tue, 16 Apr 2013, Simon Cropper wrote:
<br>
<br>
<blockquote type="cite">What Erik is describing is an alternative
approach used by many
<br>
on this list -- the use of Keyword Tags to flag who is in the
<br>
picture.
<br>
<br>
Essentially you can create a Keyword Tag for each unique entity
<br>
and check these Keyword Tags if the person is seen in the
<br>
picture (see manual on how to create tags). These Keyword Tags
<br>
can also be easily used to filter your collection to show,
<br>
say all photos with your Mum in it.
<br>
</blockquote>
<br>
Definitely right !
<br>
But I think important to add that this is not just an alternative
<br>
because Digikam lacks Person in Image edition. Using (structured)
<br>
tags is a more natural and efficient way of documenting persons
<br>
(and other properties) for several reasons stated below.
<br>
<br>
And it's not only a Digikam issue, same problem has often been
<br>
discussed on Adobe forums and some Lightroom users prefer to use
<br>
the Lightroom tags system than the Person in Image field.
<br>
<br>
The reasons :
<br>
<br>
1. Tags (in Digikam or Lightroom) have a structured organisation
<br>
that allow names aliases without confusion. E.g. you can tag
<br>
images showing your friend David with "Persons/Friends/David" (or,
<br>
in Lightroom syntax, with "Persons|Friends|David"), and showing
<br>
your nephew David with "Persons/Family/David". The name is the
<br>
same but it's two different tags, and persons. Person in Image is
<br>
a single text field that would allow you to define two times
<br>
"David, David".
<br>
<br>
2. Tags are internal database entities and you can edit the text
<br>
label afterwards. Considering Simon's example, it's possible to
<br>
tag an image with "Persons/Celebrities/Mr Periwinkle". Some time
<br>
later, you wish to edit this tag label because you know the first
<br>
name of the guy. It's easy to select the tag, edit properties
<br>
(mouse right click on the tag) and replace "Mr Periwinkle" with
<br>
"Hieronymus Periwinkle". It takes a few seconds and your hundreds
<br>
of tagged images remain Ok.
<br>
<br>
With a system like Person in Image, you need to re-edit text for
<br>
all your already tagged images.
<br>
<br>
3. (And this is probably the most important reason) Persons
<br>
appearing on images are *lists*. You can have from one person (an
<br>
artistic portrait) to many (images of a social event, a wedding or
<br>
such) on an image.
<br>
Tags (Digikam or Lightroom) are implemented in lists,
<br>
using the XMP/RDF standard. As IPTC is an older standard,
<br>
lists didn't exist and the Person in Image field is a single text
<br>
field, not a variable length array. It's possible to define
<br>
several persons, using comma separated names, but this is not an
<br>
intrinsic and this raises many problems when you want to add or
<br>
remove data.
<br>
<br>
Back to Simon's example :
<br>
<br>
<blockquote type="cite">exiv2 -M"add Xmp.iptcExt.PersonInImage Mr
Periwinkle" image.jpg
<br>
</blockquote>
<br>
Definitely correct, and your image metadata contains the proper
<br>
data field. But now, if you add someone else :
<br>
<br>
<blockquote type="cite">exiv2 -M"add Xmp.iptcExt.PersonInImage Mrs
Dandelion" image.jpg
<br>
</blockquote>
<br>
You've overwritten previous data:-(
<br>
<br>
Scalar data fields are expected to be set only and have no support
<br>
for append or remove operations. Managing lists is thus very
<br>
complicated and requires dedicated software: you first need to
<br>
read existing text value, break into components using comma or
<br>
semicolon separators, add or remove a component, rebuild the full
<br>
list with separators and update the data field.
<br>
<br>
And this has to be done for every image. With tags, you just have
<br>
to select target images and add a tag "Persons/Celebrities/Mrs
<br>
Dandelion", whatever existing persons tags already exist. Add or
<br>
remove are natural operations.
<br>
<br>
The conclusion :
<br>
<br>
Especially wrt point 3, above, it sounds that an images
<br>
organisation system should probably avoid using things like Person
<br>
in Image and prefer organised tags (Digikam:TagsList or
<br>
LightRoom:hierarchicalSubject), this for greater flexibility for
<br>
now and future.
<br>
<br>
<br>
But, this doesn't solve your initial problem :
<br>
<br>
On Tue, 16 Apr 2013, Jack Tummers wrote:
<br>
<br>
<blockquote type="cite">Thanks for the suggestions and
explanation! I'll use exiv2 for
<br>
now because my client uses PersonInImage in their image
<br>
database. But of course I hope Digikam will let me add this tag
<br>
in the future.
<br>
</blockquote>
<br>
Of course, if you use applications that expect such or such
<br>
metadata field, that field must exist:-)
<br>
<br>
However, it's probably not the client programs that should master
<br>
images collections organisation, but the reverse. Organising
<br>
images, defining keywords, tags, documentation, etc., is work done
<br>
for a long period of time. Running client software is shorter,
<br>
one can use such program, then use another one the next year, etc.
<br>
<br>
So, perhaps, the reliable strategy is to be able, at a moment,
<br>
to translate or convert required data with dedicated small tools,
<br>
e.g. a script using command line tools such as exiv2 or exiftool
<br>
to extract tags (in Digikam format or Lightroom format) and build
<br>
a comma separated list to feed a PersonInImage value to client
<br>
programs that look at that.
<br>
<br>
It's nothing but my opinion...
<br>
<br>
Regards,
<br>
Jean-François
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Digikam-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Digikam-users@kde.org">Digikam-users@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/digikam-users">https://mail.kde.org/mailman/listinfo/digikam-users</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font color="333333">Met vriendelijke groet,<br>
<br>
<strong>Jack Tummers</strong><br>
<br>
Fotografie, websites, ontwerp en idee<br>
<a href="http://www.jacktummers.nl">www.jacktummers.nl</a><br>
013 467 22 38 / 06 419 20 764</font><br>
<br>
<br>
<hr><br>
<br>
<br>
</div>
</body>
</html>