What do we want to store in the database?
Locked
123
123
Re: What do we want to store in the database?
 
|
Julien Narboux wrote:
>> ((To me this example just highlights that it would be nice >> to allow for easy additions of new fields in the >> database in the future, i.e. withouth the need to wait for >> a 0.9 to 0.10 transition ...)) >> > I think you are raising the right question. I am not a specialist of > databases. > Currently, It seems to me that changing the database format is something > the developpers do not want to do too often and they rather want to wait > for major releases. > That is why I proposed some field which may be useful only in a far > future. I understand as Gilles said that some fields are currently hard > to extract because in Makernote. But maybe one day these fields will be > in new version of the exif standard... > Should these fields already be on the database right now even if they > are not filled by Digikam and the corresponding features are not yet > implemented ? > Would it be easier to add some fields during minor release (10.1 -> > 10.2) by adding tables (picture_id, new_field) ? > > My naive questions, > > Julien Correct me, if I'm wrong, but I think, that fields should be stored in table like Fields (with cols: field_id, name, description?) and there will be separate table FieldValues (image_id, field_id, value). To have the ability to store some fields as numbers, int_value column can be added to FieldValues and maybe some flag column to Fields table, to mark that this field is numerical. For fields that require many-to-many relationship (multiple comments) there will be more entries with same image_id and field_id but different value. So this thread, as I understand it, is about default rows in Fields table. Tags use almost same db schema now - they could be merged and tags can be viewed as user defined fields with no value and tree structure (in separate table representing tree relations). (and as I have proposed few days before, albums & groups can be treated same way). Tibor Blenessy _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Colin Guthrie-6
On Thu, 30 Aug 2007, Colin Guthrie wrote: > Marcel Wiesweg wrote: > > Currently I have these fields on my list: > > > > - comment > > I think Multiple Comments is essential. But also comments need to be > qualified more than just a simple text stream. Gilles mentioned 4 > strings to be stored but I'm not sure what they all are. My suggestion > would be: > * Source > * Who/Author > * Language > * Comment > > Here the Source would 99.99% of the time be "Digikam" but hopefully this > interface can be exposed via e.g. Facebook/Flickr via Kipi plugin and > under these circumstances the Source would be set accordingly. Language > I think should be optional seeing as external comments may not have this > information associated with them. Just to add one more wish, I think it would be nice to have comments associated to a tag (and maybe also to an album). I filed a wish for this at http://bugs.kde.org/show_bug.cgi?id=149372 Best, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
2007/8/30, Arnd Baecker <[hidden email]>:
Why not... (and maybe also to an album). This is already implemented. Look in Album Properties dialog. The only one field which is not yet stored in DB is Collection. This last one must be imported in DB as Tag for Albums. The Setup Collection page must be removed and a new Albums tags setup dialog added. Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Gilles Caulier-4
On Thursday, 30. August 2007, Gilles Caulier wrote:
[...] > > > > > I'm also in favor of putting this list onto the wiki If changes to the wiki page can be posted to digikam-devel as diff it would be a big help (like svn-commit msg). So one can discuss 'controveral' changes here and in the end remove modify keep the change in the wiki. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [hidden email] _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Marcel Wiesweg
Here's my personal summary after reading the thread:
o keep it simple, so digikam for KDE4 is not delayed forever. There's much going on in meta data handling for KDE4 and it's easier to help enhance it if stuff is missing instead of trying to solve it (again). o Generic fields. I'm implies for me that that fields are self describing so one can write a generic browser (e.g. 'old' ldap comes to my mind here). o kipi metadata interface. IMHO they don't belong into digikam's database. They should be accessible by every kipi application. Or better by every KDE application -> meta data interfaces in KDE4 Just my 2 cents, Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [hidden email] _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Bugzilla from ach@mpe.mpg.de
2007/8/30, Achim Bohnet <[hidden email]>: On Thursday, 30. August 2007, Gilles Caulier wrote: Or better Achim, is to have the list on svn and published on the wiki automaticly... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Arnd Baecker
2007/8/30, Arnd Baecker <[hidden email]>:
> one more remark: > > On Thu, 30 Aug 2007, Julien Narboux wrote: > > > - picture is hidden or not : maybe this fonctionnality could be added to > > digikam in the future. > > Maybe this could be realized by Tags getting an additional attribute > (visible/hidden)? This might be even more flexible? An additional tag attribute I'd like to have is Private/Public, with only public tags writen in file. That special selections, eg. for each batch of files sent out for print, for dedicated slideshows, ... Regards, Loïc _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Bugzilla from Julien.Narboux@inria.fr
> I think you are raising the right question. I am not a specialist of
> databases. > Currently, It seems to me that changing the database format is something > the developpers do not want to do too often and they rather want to wait > for major releases. > That is why I proposed some field which may be useful only in a far > future. I understand as Gilles said that some fields are currently hard > to extract because in Makernote. But maybe one day these fields will be > in new version of the exif standard... > Should these fields already be on the database right now even if they > are not filled by Digikam and the corresponding features are not yet > implemented ? > Would it be easier to add some fields during minor release (10.1 -> > 10.2) by adding tables (picture_id, new_field) ? Changing database schema will be easier in the future. I sent a mail to this list some time ago describing that we will have automatic upgrade like Amarok, and Amarok has had about 30 database schema changes, so things like this do work. So I would vote that if we dont know really what we will do in the future, there is no value in creating empty table right now, rather wait what we need when the supporting code is written. It's a matter of policy when schema changes happen; I would vote for major versions only (0.10 -> 0.11) but that is not a technical problem. > > My naive questions, > > Julien _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Tibor Blenessy
> Correct me, if I'm wrong, but I think, that fields should be stored in
> table like Fields (with cols: field_id, name, description?) and there > will be separate table FieldValues (image_id, field_id, value). To have > the ability to store some fields as numbers, int_value column can be > added to FieldValues and maybe some flag column to Fields table, to mark > that this field is numerical. > > For fields that require many-to-many relationship (multiple comments) > there will be more entries with same image_id and field_id but different > value. What you describe is - thought to its end - just what strigi/nepomuk are doing: storing of triples of information, and ontology to describe what can and shall be stored for a type of file. This is a very general approach. For digikam, I see the database more as a tool that we use rather than a general description of the data, so we know what we store, what format it has, and where it is stored. We must keep complexity low! > > So this thread, as I understand it, is about default rows in Fields > table. Tags use almost same db schema now - they could be merged and > tags can be viewed as user defined fields with no value and tree > structure (in separate table representing tree relations). (and as I > have proposed few days before, albums & groups can be treated same way). > > Tibor Blenessy _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Bugzilla from ach@mpe.mpg.de
> Here's my personal summary after reading the thread:
> > o keep it simple, so digikam for KDE4 is not delayed forever. > There's much going on in meta data handling for KDE4 and > it's easier to help enhance it if stuff is missing instead > of trying to solve it (again). Yes!! I fully agree > > o Generic fields. I'm implies for me that that fields are > self describing so one can write a generic browser (e.g. > 'old' ldap comes to my mind here). Sounds like strigi/nepomuk > > o kipi metadata interface. IMHO they don't belong into digikam's > database. They should be accessible by every kipi application. > Or better by every KDE application -> meta data interfaces > in KDE4 You are right we do not want to duplicate nepomuk here. You know there are ambitions for an integration of nepomuk with digikam. That is a different story for know than choosing the fields we want to store in the db. We dont want to compete with nepomuk, that would be a waste of efforts. We have an application that is specialized in digital photos, and we want to do some things the way we do it. For some fields we have much more fine-grained support than any generic framework would ever want to have, and we have functionality that knows the meaning of certain fields. > > Just my 2 cents, > Achim _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
> Dnia środa 29 sierpień 2007, Marcel Wiesweg napisał:
> > Hi, > > > > It is a long-planned task for the next release to store more information > > than currently in the database. > > We are currently collecting which fields exactly we want to add. > > > > To qualify for inclusion, IMO a field should fulfill one of these two > > criteria: > > - the field can be of interest in connection with the image it belongs > > to - searching for the field is a considerable feature > > AND this criterion: > > - the information is usually available for images in a common usage > > pattern of digikam > > I think we can split all data about image in 3 parts: > > - information about file > - information about image ("hardware") > - metadata, here I think the best choice (as industry standard) is "IPTC > Core" > > > Currently I have these fields on my list: > > > > - comment > > - rating > > - creation date > > - modification date > > - size ( dimensions in pixels) > > - color depth (8, 16) > > - color model (RGB, CMYK, ...) > > - If px size is included why not weight (size in KB/MB)? I know it can > be read from filesystem but putting info in db could make some queries > faster Yes I think about it. It comes together with modification date. Both need to be updated after edits. Makes sense. > - all path related things (Album path, name of file) That was implied ;-) > > > - make of the camera > > - model of the camera > > - aperture > > - focal length > > - focalLength as for 35mm film > > - exposure time > > - exposureMode > > - exposureProgram > > - sensitivity > > - flash > > - whiteBalance > > - orientation > > - metering mode > - focus mode > - file number (although it can have different formats so its usefulness > can be questionable) Are these available from libkexiv2? Will someone want to search for the file number, will it ever be displayed in the "Properties" sidebar tab (or only in the metadata tab?) > Big question is handling of metadata. I'd like to see whole IPTC Core > put into database... For fast querying of those items and making it > independent of actual images. How many fields does that make? > > m. > > ps. Disclaimer: I work in photo department of big museum in Poland > and my primary responsibility is dealing with management of > digital photographs and digital versions of analog materials. > Usually my comments, wishes, etc. are biased from that > perspective. This is very much justified. > I'd really like to use Digikam in my work :) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Gilles Caulier-4
> > Hi,
> > > > Another thing which may be important to store in the database is > > information concerning backups. > > For each picture it would be interesting to now if it has been backed > > up, when and the name of the backup... > > But maybe this information should be OS general and not specific to > > Digikam. Nepomuk often comes as a metadata storage, but in the end this is a far too narrow view, because "semantic desktop" is all about relations. I still need to put some thought in this. > > Agree. A backup flags need to be added for the future. Backup/restore tool > is one other part to do in the future. > > > Another thing which may be important to store in the database is > > > information concerning movies: > > length, frame number of the thumnail used, .... I dont want to store this in our db, we are specialized in photos. We can always use the KDE-wide storage for this. > > Marcel ? > > > This raise the question of where to stop adding things. And is it > > > possible to share some infrastructure with amarok ? > > With nepomuk it will be possible. But it's one other KDE4 part which still > under developement and not yet tested/finalized/stabilized. This is for a > more far future.. > > Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Marcel Wiesweg
2007/8/31, Marcel Wiesweg <[hidden email]>: Gilles> Dnia środa 29 sierpień 2007, Marcel Wiesweg napisał: Yes and no. This is depand where data are store : in standard Exif or in Makernotes. Standard Exif is not a problem to extract. Tags name and value are define in Exif spec. http://www.exiv2.org/metadata.html Makernotes is a big problem. A lots of code need to be written to check all possibilities. Nothing is standardized. This is why i recommend to host only the Exif Standard tags in a first time, and progressivly to add Makernotes. Look my previous post for details. Will someone want to search for the file number, will it ever be displayed in It's bigger. Look here : http://www.exiv2.org/iptc.html We need to choose the most important. Unforget than the new standard is XMP, which remplace IPTC. In general we found a lots of tags IPTC in XMP, but few have been removed, and new have been added. I recommend to use XMP as ref. http://www.iptc.org/IPTC4XMP/ _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Marcel Wiesweg
Dnia piątek 31 sierpień 2007, Marcel Wiesweg napisał:
> > - metering mode > > - focus mode > > - file number (although it can have different formats so its > > usefulness can be questionable) > > Are these available from libkexiv2? > Will someone want to search for the file number, will it ever be > displayed in the "Properties" sidebar tab (or only in the metadata tab?) These may be Makernotes. Understand if they will not be included (although I think they are invaluable as learning tool). > > Big question is handling of metadata. I'd like to see whole IPTC Core > > put into database... For fast querying of those items and making it > > independent of actual images. > > How many fields does that make? http://www.iptc.org/std/Iptc4xmpCore/1.0/specification/Iptc4xmpCore_1.0-spec-XMPSchema_8.pdf 33: IPTC Subject-NewsCodes IPTC Scene-NewsCodes Country Code Creator's Contact Info Contact Info-City Contact Info-Country Contact Info-Address Contact Info-Postal Code Contact Info-State/Province Contact Info-Email Contact Info-Phone Contact Info-Web URL Intellectual Genre Location IPTC Scene IPTC Subject Code Creator Caption/Description Copyright Notice Keywords Title City Country Creator's Jobtitle Date Created Caption/Description writer Headline Instructions Job Identifier Provider Source Province/State Rights Usage Terms Note: several of them are of type - Lang Alt which means there can be several fields: Copyright Notice, Description, Rights Usage Terms, Title m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Arnd Baecker
> > >> - picture is hidden or not : maybe this fonctionnality could be added
> > >> to digikam in the future. > > > > > > Maybe this could be realized by Tags getting an additional attribute > > > (visible/hidden)? This might be even more flexible? > > > > If you do it with tags you have the problem of i18n and typos, what if I > > type "hiden" or "caché" (hidden in French)... > > What happens if I tag a picture using the word "hidden treasure" ... > > Obviously the user interface should hide hidden photos. Having the user > > interface depends on tags seems to me to be not a good idea. > > Sorry, I wasn't clear enough - I was thinking of an additional > boolean flag (not a string), associated with each tag. Are you talking about hiding the _tag_ or the _image_? I think this is confused here. - Hiding images: There are reason to hide an image if e.g. there is an edited version and the original is hidden. The easy solution is one boolean flag. Hiding an image in one context (tag) and not in another is complex, just do the combinatorics. - Hiding tags: I understand there is some interest that not all tags are included when tags are written to metadata. I am CC'ing Daniel Bauer here who has in the past had similar interest. But IMO it is not property of the tag if it is written but of the context, so a "metadata writing context" has to know which tags it writes. This is not a db schema issue then. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Colin Guthrie-6
> I think Multiple Comments is essential. But also comments need to be
> qualified more than just a simple text stream. Gilles mentioned 4 > strings to be stored but I'm not sure what they all are. My suggestion > would be: > * Source > * Who/Author > * Language > * Comment Gilles, was that what you meant with 4, a table for multiple comments with four columns like the ones above? > > Here the Source would 99.99% of the time be "Digikam" but hopefully this > interface can be exposed via e.g. Facebook/Flickr via Kipi plugin and > under these circumstances the Source would be set accordingly. Language > I think should be optional seeing as external comments may not have this > information associated with them. > > > - rating > > Tags, (as Gilles also pointed out). With the addition of a "region" > attribute (simple rect is probably sufficient here c.f. Facebook - > simplicity wins) as per http://bugs.kde.org/show_bug.cgi?id=146337 > > > And another new one for you: > - key/value pairs > > Some form of generic key/value pair storage system for every image, > album and tag. This would be to allow 3rd party plugins via kipi store > important information/configuration paramaters. Actually, possibly more > sensible is a blob of data instread, in which we can store an XML > kconfig dump although this would not allow easy searching... (e.g. it > would be quite useful for a kipi plugin to say "give me all images with > foo = 42". > > This needs more discussion but I've often mentioned it in the past so > not a bolt from the blue. We already have a table for this. If libkipi required a method to store String/String pairs for an image, it would be easy to provide. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
> > > Big question is handling of metadata. I'd like to see whole IPTC Core
> > > put into database... For fast querying of those items and making it > > > independent of actual images. > > > > How many fields does that make? > > http://www.iptc.org/std/Iptc4xmpCore/1.0/specification/Iptc4xmpCore_1.0-spe >c-XMPSchema_8.pdf 33: > > IPTC Subject-NewsCodes > IPTC Scene-NewsCodes > Country Code > Creator's Contact Info > Contact Info-City > Contact Info-Country > Contact Info-Address > Contact Info-Postal Code > Contact Info-State/Province > Contact Info-Email > Contact Info-Phone > Contact Info-Web URL > Intellectual Genre > Location > IPTC Scene > IPTC Subject Code > Creator > Caption/Description > Copyright Notice > Keywords > Title > City > Country > Creator's Jobtitle > Date Created > Caption/Description writer > Headline > Instructions > Job Identifier > Provider > Source > Province/State > Rights Usage Terms > > Note: several of them are of type - Lang Alt which means there can be > several fields: Copyright Notice, Description, Rights Usage Terms, Title So it is clear that there won't be a table with 33 columns but rather a table with key/value pairs. Like the ImageProperties table that already exists. Or do we need extra language information? Of course, the work for supporting IPTC core would have to be done on the UI side. Like with so many features wished in this thread... We could need some Google Summer of Code students next year ;-) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
On Fri, 31 Aug 2007, Marcel Wiesweg wrote:
> We could need some Google Summer of Code students next year ;-) Actually, this is a very good idea and planning for this should start early to get good students for the job! Of course one needs to define reasonable tasks which are doable in the given time (eg. like google-earth integration ;-). _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Marcel Wiesweg
Dnia piątek 31 sierpień 2007, Marcel Wiesweg napisał:
> > Big question is handling of metadata. I'd like to see whole IPTC Core > > put into database... For fast querying of those items and making it > > independent of actual images. > > How many fields does that make? > To be frank (through clenched teeth ;) I should mention about second contender to description of metadata: Dublin Core. Simplified version is... simple. Only 15 elements: title creator subject description publisher contributor date type format identifier source language relation coverage rights But full version is much, much longer: http://dublincore.org/documents/dcmi-terms/ Several points against DC: 1. Simplified version is really simple and doesn't cover some specific to photography things (eg. difference between photo and subject on it, location) 2. Full version is really, really long and complicated. 3. Another thing against DC is weak support for it in Adobe applications while IPTC Core is AFAIK complete - and IPTC is directly part of XMP. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
In reply to this post by Marcel Wiesweg
2007/8/31, Marcel Wiesweg <[hidden email]>: > I think Multiple Comments is essential. But also comments need to be I thinking 4 (more if you want) different comments as UTF-8 strings. Nothing special about that. We can use like we want, for example to store text in many language, or text come different photographers. You course this still to define more. What the advantage to use a table we host all strings against 4 separate strings ? > Colin, you will be happy to implemente it (:=))) Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |