[Digikam-devel] What do we want to store in the database?

Sebastian Bothe kde at sbothe.de
Tue Sep 11 13:43:01 CEST 2007

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..

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
> 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
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel

More information about the Digikam-devel mailing list