[Digikam-devel] What do we want to store in the database?
kde at sbothe.de
Tue Sep 11 13:43:01 CEST 2007
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
> 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)
> - 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
> (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
> - And what about to Tag Album as well (to replace "collection"
> properties?) :
> - ImageInformation or ImageMetadata (?):
> - technical quality tags
> - 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.
> - Table ImageMetadata:
> - lens type (focal range in 35mm equivalent is available in Makernotes)
> - focus mode
> - macro
> - stabilization
> - focus point (can be quite camera dependent)
> - 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
>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)
> 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:
> - Action lists:
> (presumably some more bugs ...)
> Best, Arnd
> Digikam-devel mailing list
> Digikam-devel at kde.org
More information about the Digikam-devel