[Digikam-devel] What do we want to store in the database?
marcel.wiesweg at gmx.de
Sun Oct 7 15:23:24 CEST 2007
> Hi Marcel,
> I went through all the messages in this thread
> and tried to compare with your DBSCHEMA.ODS
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)
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
> (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
Yes I want that. but see above.
> - And what about to Tag Album as well (to replace "collection"
> properties?) :
> - ImageInformation or ImageMetadata (?):
> - technical quality tags
Seems to me this needs quite a bit of research still
> - Associate a region in an image with a tag:
> 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.
> 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)
> - 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
>lay or make use of gipfel
> - 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
> Generell points:
> - Only include displayable files in the database:
This should already be implemented in trunk.
> - Action lists:
> (presumably some more bugs ...)
Later, as said above.
> Best, Arnd
> Digikam-devel mailing list
> Digikam-devel at kde.org
More information about the Digikam-devel