[Digikam-users] IPTC: Person Shown / PersonInImage [Take 2]

Jack Tummers jack at jacktummers.nl
Tue Apr 16 10:30:24 BST 2013


@Jean-François,

This sounds all very reasonable and I agree with you totally.
Perhaps I can convince my client to stop using PersonInImage, for future 
sake :) That would solve my problem too.




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

-- 
Met vriendelijke groet,

*Jack Tummers*

Fotografie, websites, ontwerp en idee
www.jacktummers.nl <http://www.jacktummers.nl>
013 467 22 38 / 06 419 20 764


------------------------------------------------------------------------



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20130416/c092203a/attachment.html>


More information about the Digikam-users mailing list