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

[Marcel Wiesweg]

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