What do we want to store in the database?
Locked
123
123
Re: What do we want to store in the database?
 
|
2007/8/31, Mikolaj Machowski <[hidden email]>: Dnia piątek 31 sierpień 2007, Marcel Wiesweg napisał: This list is better. If we really need to add more in the future, it's always possible... 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/31, Arnd Baecker <[hidden email]>: On Fri, 31 Aug 2007, Marcel Wiesweg wrote: yes, but this is for the next year (:=))) Also, we need somebody to prepare some text when the right moment will come to propose a subject for google code... 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]>: > > > Big question is handling of metadata. I'd like to see whole IPTC Core What do want to mean by "extra language info" exactly ? 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?
|
|
> > 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? > > What do want to mean by "extra language info" exactly ? It sounded as if there could be one description in say English and one in German. Than this could not easily be stored in a key/value table. > > 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
Am Freitag 31 August 2007 schrieb Gilles Caulier:
> 2007/8/31, Marcel Wiesweg <[hidden email]>: > > > 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? > > 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 ? Ok, in this case we will store each comment in its own row in a table like this: imageid INTEGER description TEXT value TEXT Colin suggested to store (instead of "description" above) source, author and language for each comment. _______________________________________________ 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/31, Marcel Wiesweg <[hidden email]>: Am Freitag 31 August 2007 schrieb Gilles Caulier: This is what i think in a first time Colin suggested to store (instead of "description" above) source, author and This is different. It's a Comments with properties. We need to check if something exist in XMP schema to get inspiration. No need to re-invent the wheel. 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
Marcel Wiesweg wrote:
>> 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! Now I more understand, your approach, thanks for explanation. But still I don't see any advantage from it. If nepomuk is doing the same, it will be great to define digikam ontology and use nepomuk for it. That way it will be much more future-proof. Other tools will be able to use digikam's tags for processing, ... To known what we store, format and where it's stored - this info can be hardcoded in digikam src (in stl map or something similar). Nowadays it is hardcoded in SQL strings, so it's almost the same. Tibor Blenessy ps. maybe I don't understand it, because I don't understand digikam code, if that's true, reply rtfc (like rtfm, but c for code), and I'll be quiet :) _______________________________________________ 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
Gilles Caulier wrote:
> > > 2007/8/31, Marcel Wiesweg <[hidden email] > <mailto:[hidden email]>>: > > Am Freitag 31 August 2007 schrieb Gilles Caulier: > > 2007/8/31, Marcel Wiesweg > <[hidden email] > <mailto:[hidden email]>>: > > > > 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? > > > > 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 ? > > Ok, in this case we will store each comment in its own row in a > table like > this: > imageid INTEGER > description TEXT > value TEXT > > > This is what i think in a first time Without giving it too much thought, I think a date may be a useful field to store too (thinking ahead to comments pulled in from external sources. I'd go for a table along the following lines: imageid INTEGER date DATETIME (optional) lang TEXT (optional) source TEXT (optional) author TEXT (optional) comment TEXT > Colin suggested to store (instead of "description" above) source, > author and > language for each comment. > > > This is different. It's a Comments with properties. We need to check if > something exist in XMP schema to get inspiration. No need to re-invent > the wheel. Yes I agree, if there is something close in the specs then obviously it makes sense to work within that general framework. Still, I guess digikam can be cleverer than what eventually goes into the file itself as metadata. Col _______________________________________________ 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
Am Thursday 30 August 2007 um 10:10:35 schrieb Julien Narboux:
> Another thing which may be important to store in the database is > information concerning movies: > length, frame number of the thumnail used, .... The backup media is also important, so a "rw", "ro" flag and a "removable", "permanent" flag, so digikam does not sort out photos that are on a detached removable media. Otherwise if the removable media is attached and the photo can not be found digikam can remove it from the database. Another question is, what kind of service/help this semantic desktop stuff in KDE4 can do(?) Bye Thorsten _______________________________________________ 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
> My first proposal to Marcel by IRC is to make an OpenOffice sheet (:=))).
> > To resume : I would to have a document where we can found what is stored in > DB, including full description of each field. Like we will host a lots of > informations, this is important for the future... I have updated the wiki page trying to integrate some of the suggestions here on this list. It's a long thread... When this has settled down I can make a beautiful OpenOffice document with details on the schema, no problem. > > 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 Bugzilla from thorsten.schnebeck@gmx.net
> > Another thing which may be important to store in the database is
> > information concerning movies: > > length, frame number of the thumnail used, .... > > The backup media is also important, so a "rw", "ro" flag and > a "removable", "permanent" flag, so digikam does not sort out photos that > are on a detached removable media. > Otherwise if the removable media is attached and the photo can not be found > digikam can remove it from the database. Solid knows if a media is "removable" or "hot-pluggable" and we will use this information. Solid information is parsed, and then album roots are marked if they are available or not. Only available roots are scanned. It is crucial that images are not removed from db if the media is currently not mounted. > > Another question is, what kind of service/help this semantic desktop stuff > in KDE4 can do(?) I cannot answer this at the moment. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: What do we want to store in the database?
|
|
Hi Marcel,
I went through all the messages in this thread and tried to compare with your DBSCHEMA.ODS http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log I have found a few points which are not listed (very likely on purpose ;-), but let me still mention them here (note that this list partially contains verbatim copies from the original messages): - Table Tags: - comments for tags (This would for example allow to provide additional information about a person, or animal, or landscape, ... I.e., something which would not make sense to add to the comment of each of the corresponding images, because it is just the same/generally applicable) http://bugs.kde.org/show_bug.cgi?id=149372 - additional boolean flag: visible/hidden (i.e. all images tagged by a tag marked hidden are not shown, i.e. private images etc.) - Grouping of images http://bugs.kde.org/show_bug.cgi?id=121310 (Coming from panoramae, or bracketed shots for HDR). Within a group it should be possible to select which images are visible (i.e also more than one). This would also allow to group JPG and RAWs together http://bugs.kde.org/show_bug.cgi?id=147427 - And what about to Tag Album as well (to replace "collection" properties?) : http://bugs.kde.org/show_bug.cgi?id=133011 - ImageInformation or ImageMetadata (?): - technical quality tags http://bugs.kde.org/show_bug.cgi?id=128333 - Associate a region in an image with a tag: http://bugs.kde.org/show_bug.cgi?id=146337 Note that such a region should not be a property of a tag, but a property of an image. Example: If there are several persons on one image, one can first add the Person's names as tags to that image (as right now). In addition, one may mark the region of the face and associate it with the tag. Image: Tags: - Name1 - Name2 - Name3 Regions: - Region1 --> Tag Name1 - Region2 --> Tag Name2 Not sure how to put this in the database scheme ... To specify the region: the simplest are rectangles, but one should also think of more complicated shapes (circle, ellipse, general svg paths) in the longer run. So it might be good to keep this in mind already when setting up the database scheme. - Table ImageMetadata: - lens type (focal range in 35mm equivalent is available in Makernotes) - focus mode - macro - stabilization - focus point (can be quite camera dependent) http://bugs.kde.org/show_bug.cgi?id=138704 - panorama mode - perhaps few original informations from pictures taken from camera as org. size, org. date, org. filename, cmaera serial number, UUID of media, etc. to perform detection of already downloaded pictures for camera gui. This way is under discussion... - Table GPS data - orientation (compass) - tilt (nb of degrees with regard to horizontal) - roll (I.e. to fully specify the position of an image in space, horizontal and vertical FOV have to be known, which can be obtained from the lense properties. and three angles for the direction and the two possible directions to tilt a camera in space. This can then be used to create photoverlays with googleearth http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photooverlay or make use of gipfel http://www.ecademix.com/JohannesHofmann/gipfel.html - not sure about this one: Without giving it too much thought, I think a date may be a useful field to store too (thinking ahead to comments pulled in from external sources. I'd go for a table along the following lines: imageid INTEGER date DATETIME (optional) lang TEXT (optional) source TEXT (optional) author TEXT (optional) comment TEXT - Another thing which may be important to store in the database is information concerning movies: length, frame number of the thumnail used, .... Generell points: - Only include displayable files in the database: http://bugs.kde.org/show_bug.cgi?id=145743 - Action lists: http://bugs.kde.org/show_bug.cgi?id=125387 http://bugs.kde.org/show_bug.cgi?id=103350 (presumably some more bugs ...) 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?
|
|
Hello together,
I just read this mail.. Perhaps it would be a good Idea to allow some parts of information to have a 1:n relation in the database- I mean 1 picture n times the info for it.. For example it could be useful to "sync" the rating for a picture out of a internet gallery for the same picture back to digikam. Same could be useful for tags and so on.. Just a thought.. Sebastian On Tuesday 11 September 2007 08:48:43 Arnd Baecker wrote: > Hi Marcel, > > I went through all the messages in this thread > and tried to compare with your DBSCHEMA.ODS > http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=lo >g > > I have found a few points which are not listed > (very likely on purpose ;-), but let me still mention them here > (note that this list partially contains verbatim copies > from the original messages): > > - Table Tags: > - comments for tags > (This would for example allow to provide additional information > about a person, or animal, or landscape, ... > I.e., something which would not make sense to > add to the comment of each of the corresponding > images, because it is just the same/generally applicable) > http://bugs.kde.org/show_bug.cgi?id=149372 > - additional boolean flag: visible/hidden > (i.e. all images tagged by a tag marked > hidden are not shown, i.e. private images etc.) > > - Grouping of images > http://bugs.kde.org/show_bug.cgi?id=121310 > (Coming from panoramae, or bracketed shots for HDR). > Within a group it should be possible to select > which images are visible (i.e also more than one). > > This would also allow to group JPG and RAWs together > http://bugs.kde.org/show_bug.cgi?id=147427 > > - And what about to Tag Album as well (to replace "collection" > properties?) : > http://bugs.kde.org/show_bug.cgi?id=133011 > > - ImageInformation or ImageMetadata (?): > - technical quality tags > http://bugs.kde.org/show_bug.cgi?id=128333 > > - Associate a region in an image with a tag: > http://bugs.kde.org/show_bug.cgi?id=146337 > > Note that such a region should not be a property of a tag, > but a property of an image. Example: > If there are several persons on one image, one can > first add the Person's names as tags to that image (as right now). > In addition, one may mark the region of the face > and associate it with the tag. > Image: > Tags: - Name1 > - Name2 > - Name3 > Regions: - Region1 --> Tag Name1 > - Region2 --> Tag Name2 > > Not sure how to put this in the database scheme ... > To specify the region: the simplest are rectangles, > but one should also think of more complicated shapes > (circle, ellipse, general svg paths) in the longer run. > So it might be good to keep this in mind already when setting > up the database scheme. > > - Table ImageMetadata: > - lens type (focal range in 35mm equivalent is available in Makernotes) > - focus mode > - macro > - stabilization > - focus point (can be quite camera dependent) > http://bugs.kde.org/show_bug.cgi?id=138704 > - panorama mode > - perhaps few original informations from pictures taken from camera as > org. size, org. date, org. filename, cmaera serial number, UUID of > media, etc. to perform detection of already downloaded pictures for > camera gui. This way is under discussion... > > - Table GPS data > - orientation (compass) > - tilt (nb of degrees with regard to horizontal) > - roll > (I.e. to fully specify the position of an image in space, > horizontal and vertical FOV have to be known, which > can be obtained from the lense properties. > and three angles for the direction and the two possible directions > to tilt a camera in space. > This can then be used to create photoverlays with googleearth > > http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photoover >lay or make use of gipfel > http://www.ecademix.com/JohannesHofmann/gipfel.html > > - not sure about this one: > > Without giving it too much thought, I think a date may be a useful field > to store too (thinking ahead to comments pulled in from external sources. > > I'd go for a table along the following lines: > imageid INTEGER > date DATETIME (optional) > lang TEXT (optional) > source TEXT (optional) > author TEXT (optional) > comment TEXT > > - Another thing which may be important to store in the database is > information concerning movies: > length, frame number of the thumnail used, .... > > Generell points: > - Only include displayable files in the database: > http://bugs.kde.org/show_bug.cgi?id=145743 > > - Action lists: > http://bugs.kde.org/show_bug.cgi?id=125387 > http://bugs.kde.org/show_bug.cgi?id=103350 > (presumably some more bugs ...) > > 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 |
Re: What do we want to store in the database?
|
|
In reply to this post by Arnd Baecker
> Hi Marcel,
> > I went through all the messages in this thread > and tried to compare with your DBSCHEMA.ODS > http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=lo > Arnd the reply is late but your message did not go unnoticed ;-) Rather it reached me just in time for my holidays. > > I have found a few points which are not listed > (very likely on purpose ;-), but let me still mention them here > (note that this list partially contains verbatim copies > > >from the original messages): > > - Table Tags: > - comments for tags > (This would for example allow to provide additional information > about a person, or animal, or landscape, ... > I.e., something which would not make sense to > add to the comment of each of the corresponding > images, because it is just the same/generally applicable) > http://bugs.kde.org/show_bug.cgi?id=149372 I have not changed anything in tabs and albums so far. All the other ideas like grouping, stored actions etc. have to wait I fear if we want to get out digikam 0.10 in a timely manner. At least, currently I am struggling to get everything right for image-specific fields in the db. > - additional boolean flag: visible/hidden > (i.e. all images tagged by a tag marked > hidden are not shown, i.e. private images etc.) Same as above. > > - Grouping of images > http://bugs.kde.org/show_bug.cgi?id=121310 > (Coming from panoramae, or bracketed shots for HDR). > Within a group it should be possible to select > which images are visible (i.e also more than one). > > This would also allow to group JPG and RAWs together > http://bugs.kde.org/show_bug.cgi?id=147427 Yes I want that. but see above. > > - And what about to Tag Album as well (to replace "collection" > properties?) : > http://bugs.kde.org/show_bug.cgi?id=133011 idem > > - ImageInformation or ImageMetadata (?): > - technical quality tags > http://bugs.kde.org/show_bug.cgi?id=128333 Seems to me this needs quite a bit of research still > > - Associate a region in an image with a tag: > http://bugs.kde.org/show_bug.cgi?id=146337 > > Note that such a region should not be a property of a tag, > but a property of an image. Example: > If there are several persons on one image, one can > first add the Person's names as tags to that image (as right now). > In addition, one may mark the region of the face > and associate it with the tag. > Image: > Tags: - Name1 > - Name2 > - Name3 > Regions: - Region1 --> Tag Name1 > - Region2 --> Tag Name2 > > Not sure how to put this in the database scheme ... > To specify the region: the simplest are rectangles, > but one should also think of more complicated shapes > (circle, ellipse, general svg paths) in the longer run. > So it might be good to keep this in mind already when setting > up the database scheme. Yes. At least points. Later! > > - Table ImageMetadata: > - lens type (focal range in 35mm equivalent is available in Makernotes) This is from Makernote? > - focus mode = MeteringMode or ExposureProgram? We'll have both in db > - macro We will have SubjectDistanceRange > - stabilization > - focus point (can be quite camera dependent) > http://bugs.kde.org/show_bug.cgi?id=138704 > - panorama mode What is this? Any exif keys? > - perhaps few original informations from pictures taken from camera as > org. size, org. date, org. filename, cmaera serial number, UUID of > media, etc. to perform detection of already downloaded pictures for > camera gui. This way is under discussion... Yes! This is in the works > > - Table GPS data > - orientation (compass) > - tilt (nb of degrees with regard to horizontal) > - roll From where do I get these values? Can these be mapped to Exif GPS data? Or where do you get this information from? Second, storage format: Is a double floating point number ok? > (I.e. to fully specify the position of an image in space, > horizontal and vertical FOV have to be known, which > can be obtained from the lense properties. > and three angles for the direction and the two possible directions > to tilt a camera in space. > This can then be used to create photoverlays with googleearth > > http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photoover >lay or make use of gipfel > http://www.ecademix.com/JohannesHofmann/gipfel.html > > - not sure about this one: > > Without giving it too much thought, I think a date may be a useful field > to store too (thinking ahead to comments pulled in from external sources. > > I'd go for a table along the following lines: > imageid INTEGER > date DATETIME (optional) Date is in the comments table now. > lang TEXT (optional) > source TEXT (optional) > author TEXT (optional) > comment TEXT > > - Another thing which may be important to store in the database is > information concerning movies: > length, frame number of the thumnail used, .... -> I want to concentrate and specialize in images. I hope to get such info from strigi/nepomuk > > Generell points: > - Only include displayable files in the database: > http://bugs.kde.org/show_bug.cgi?id=145743 This should already be implemented in trunk. > > - Action lists: > http://bugs.kde.org/show_bug.cgi?id=125387 > http://bugs.kde.org/show_bug.cgi?id=103350 > (presumably some more bugs ...) Later, as said above. > > 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 |
Re: What do we want to store in the database?
|
|
2007/10/7, Marcel Wiesweg <[hidden email]>: > Hi Marcel, agree. At least, currently I am struggling to get everything right for image-specific focal Length info, is avaialble from standard Exif : ==> Exif.Photo.FocalLength Rational The actual focal length of the lens, in mm. Conversion is not made to the focal length of a 35 mm film camera. ==> Exif.Photo.FocalLengthIn35mmFilm Short This tag indicates the equivalent focal length assuming a 35mm film camera, in mm. A value of 0 means the focal length is unknown. Note that this tag differs from the <FocalLength> tag. but _not_ lens type witch is stored by Makernotes. Problem is than all camera maker use a dedicaced way to provide this info. For ex.: ==> Exif.Nikon3.LensType Byte Lens type ==> Exif.Minolta.LensID Long ==> Exif.CanonCs.Lens Short 'long' and 'short' focal length of lens (in 'focal units') and 'focal units' per mm In other words, this will be infernal to get this info easily. But... Xmp provide has a tag to simplify this task : ==> Xmp.Aux.Lens Text A description of the lens used to take the photograph. For example, "70-200 mm f/2.8-4.0" This will be the ultimate solution... when we will have implemented in Exiv2 core (not libkexiv2) a wrapper to import Exif (and Iptc) to Xmp ( and vis-versa) This is not yet done, but it's planed. This is why i recommend to delay all Makernotes informations extraction dedicaced to fill the new DB contents. Note : XMP support all standard Exif/Iptc tags as well (more and better), but not Makernotes in standard. Yes, in this case all metadata will be duplicated but Xmp will become the full replacement of Exif and Iptc. > - focus mode ==> Makernote. > - focus point (can be quite camera dependent) ==> Makernote. > http://bugs.kde.org/show_bug.cgi?id=138704 ==> Makernote. What is this? Any exif keys? From standard Exif : Exif.GPSInfo.GPSImgDirection Rational Indicates the direction of the image when it was captured. The range of values is from 0.00 to 359.99. Second, storage format: Is a double floating point number ok? yes, certainly... > (I.e. to fully specify the position of an image in space, Marcel, Standard Exif + Makernotes + standard IPTC tags are listed and described at this url : http://www.exiv2.org/metadata.html Supported Xmp tags are not yet listed in this page. Look into this file for details : http://dev.robotbattle.com/~cvsuser/cgi-bin/ns_viewcvs.cgi/exiv2/trunk/src/properties.cpp?rev=1251&view=auto 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 |