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 <[hidden email]>: > 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. > 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). 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 ? > > Cheers > > Adrien BUSTANY > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
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 <[hidden email]>: > > 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. > > 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.... > > 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? 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. Just some thoughts .... Best, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
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 : 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.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 [hidden email]: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. 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). I keep note of that.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.... More generally with any information in the Nepomuk repository. It can even be networked as Nepomuk is network capable.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? 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.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. Again, these are very valuable for meJust some thoughts .... Best, Arnd Cheers Adrien _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Arnd Baecker
Arnd,
Look my recent post in ML. Adrien talk a book region from image where people can be see and link these info with nepomuk. Gilles 2008/6/20 Arnd Baecker <[hidden email]>: > 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 <[hidden email]>: >> > 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. > >> > 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.... > >> > 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? > > 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. > > Just some thoughts .... > > Best, Arnd > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Adrien BUSTANY
Hi Adrien,
to keep the context I have cut the message pretty strongly as somehow the quoting of who wrote what got lost in the exchange ... ;-) On Sat, 21 Jun 2008, Adrien BUSTANY wrote: [...] > > 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. Yes, something like this sounds very good. The reason why I use a hierarchy is similar: usually only a subset of all people is present (;-); e.g. one meets some of them only during one holiday or only a couple of times a year, while others (closest family) will be present all the time. By using a (very flat) hierarchy: - People - family - friends 1 - friends 2 etc. with entries in each group, collapsing the not-needed trees allows for faster tagging. Ultimately, we might need something even better for faster tagging: Usually tags will come in clusters: Consider one foto session, stored in one album/folder. If a tag is associated to one image, it quite often will also be associated with other images as well. Overall one will get a bunch of tags which correspond to this one session. If one then considers a different session, and associates one tag, one could automatically try to figure out, which other tags most likely will be associated as well. Hmm, this description is not that precise, but hopefully you get the idea... > 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). I am not familiar with nepomuk, but making this information available seems like a good idea. About setting up the schema etc., I can't comment much, and leave that for Marcel and Gilles ... ;-) Best, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |