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

[Sebastian Bothe]

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