[Digikam-devel] Marking the persons on pictures with Digikam

[Adrien BUSTANY]

Hi,
first of all thanks for your feedback. I'm not a Digikam user (I'm 
actually coming from the GNOME world :-p) so I'm very interested in the 
way Digikam is used.
Arnd Baecker a écrit :
> Hi,
>
> On Fri, 20 Jun 2008, Gilles Caulier wrote:
>
>   
>> Adrien, Marcel,
>>
>> I fork this mail to devel mailing list. please, we will continue in
>> this room. I would to have the viewpoint from others guy about this
>> subject.
>>
>> Best
>>
>> Gilles Caulier
>>
>> 2008/6/20 Adrien BUSTANY <madcat at mymadcat.com>:
>>     
>>> Hi,
>>> I've been thinking about the different ways to make Digikam "people aware",
>>> ie. to enable the user to tell Digikam who's on the picture.
>>>       
>
> I am not sure what you mean by this. Are you thinking of
> face detection/face recognition, as in
> https://bugs.kde.org/show_bug.cgi?id=146288 ?
>
> More modestly, tags associated with a region of an image, see
> https://bugs.kde.org/show_bug.cgi?id=146337, added manually
> would allow a fine grained description for that.
>
> Currently I just use a hierarchy of tags to mark people in images.
> Apart from the usual effort needed for tagging,
> this works very well.
>
>   
Yes, I'm talking about marking a region of the picture, not face 
detection. IIRC face detection was a summer of code subject for fspot 
some years ago, I don't know if it led to something.
Why do you use the hierarchy for your people tags ? To classify for 
example family -> uncles ? You could do that with the "people tag" 
system, you'd have a "family" tag (classical one) with people tags 
inside. The advantage is that you can specify the region. I'm also 
planning to do a "smart" selection system : If for example you marked 
three people of your family, then the system will put other members of 
the family group at the top of the "available people" list.
The point here is not only to make Digikam people aware, but also to 
make it Nepomuk aware (I think I didn't mention it).
>>> Gilles is not sure kipi is the way to go, since the database access is quite
>>> limited if we go that way. We could enhance kipi to give a broader access to
>>> the database, but it'd add some constraints about the database for the other
>>> programs which use kipi.
>>> Anyway, whatever the way wo do it, we have to think about the storage part.
>>> My proposition is to add a new table to the database, named "people" or
>>> something like that. It wouldn't break the compatibility with other versions
>>> : recent versions will just have to check and add the table if it's missing,
>>> older versions will ignore it.
>>> The structure and usage of the table would be very similar to the ones of
>>> the "tags" database (without the hierarchy part).
>>>       
>
> Hmm, personally I would very much like to keep the
> possibility of a hiearchy....
>
>   
I keep note of that.
>>> We need a unique id, and
>>> either a name or a uid which identifies the person in KDE's address book.
>>> Akonadi is a central storage in KDE 4 for PIM information, and we could use
>>> it. However, it add a dependency on Akonadi. To compensate that we could
>>> make this feature an option, as for geolocalisation.
>>>
>>> What do you guys think about that ?
>>>       
>
> So your aim is to connect information about people
> (i.e. KDE's address book) with images, right?
>   
More generally with any information in the Nepomuk repository. It can 
even be networked as Nepomuk is network capable.
> Maybe one can add a kind of "link" to a given tag
> which points into the address book?
> I.e. each tag would get an additional property.
> (Additional properties for tags, like comments, see
>   https://bugs.kde.org/show_bug.cgi?id=149372
> would be useful for different purposes)
> This would allow both a hierarchy of tags, but
> also the connection to the address book.
>   
For now I'm planning on a people table along the tags table, I see it as 
a "cleaner" way to do it (and it doesn't break compatibility with the 
current schema). Of course that's open to discussion, as I'm neither a 
Digikam nor a database guru.
> Just some thoughts ....
>   
Again, these are very valuable for me
> Best, Arnd
>   

Cheers
Adrien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20080621/455e17c1/attachment.html>