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

[Gilles Caulier]

2007/8/29, Marcel Wiesweg <marcel.wiesweg at gmx.de>:
>
> Hi,
>
> It is a long-planned task for the next release to store more information
> than
> currently in the database.


And certainly the most important...


We are currently collecting which fields exactly we want to add.
>
> To qualify for inclusion, IMO a field should fulfill one of these two
> criteria:
> - the field can be of interest in connection with the image it belongs to
> - searching for the field is a considerable feature
> AND this criterion:
> - the information is usually available for images in a common usage
> pattern of
> digikam
>
> Currently I have these fields on my list:
>
> - comment
> - rating
>

(And Tags of course)

- creation date
> - modification date
> - size ( dimensions in pixels)
> - color depth (8, 16)
> - color model (RGB, CMYK, ...)
>
> - make of the camera
> - model of the camera
> - aperture
> - focal length
> - focalLength as for 35mm film
> - exposure time
> - exposureMode
> - exposureProgram
> - sensitivity
> - flash
> - whiteBalance


=> WB bool Manual/Auto flag from std. Exif
=> WB value (double) in °K from Makernote (method in likexiv2 to extract
this value not yet implemented. I'm waiting than Exiv2 API provide a new
method for that)

- orientation


==> as the same value  than Exif orientation flag

B.K.O about to find image by photo info is :
http://bugs.kde.org/show_bug.cgi?id=146337

- GPS:
> - latitude
> - longitude
> - altitude


+ GPS position description as string. My GPS device (Tom Tom one) generate a
GPX file with this informations for each point in trace. I will improve
GPSSync plugin to extract this srtings, this can be usefull.

+ Copyright/Author/Credits/etc. strings from IPTC/XMP

http://bugs.kde.org/show_bug.cgi?id=139283

- similarity searching with a Haar-like algorithm matrix


http://bugs.kde.org/show_bug.cgi?id=147961

+ your MD5 sum to identify picture ?

http://bugs.kde.org/show_bug.cgi?id=125736

Not included is compression, as no real information for this is availabe
> from
> the low-level libs for most image formats (nothing for jpeg, nothing for
> png)


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


There was a discussion about multiple comments; what is the status about
> this?


Yes, it's important. The question is how many different stings we need to
store in DB as UTF-8. I propose 4. There are 2 entries in B.K.O:

http://bugs.kde.org/show_bug.cgi?id=98462
http://bugs.kde.org/show_bug.cgi?id=135476

There is another one to store Tags about a region of image. Look in B.K.O :

http://bugs.kde.org/show_bug.cgi?id=146337

And what about to Tag Album as well (to remplace "collection" properties?) :

http://bugs.kde.org/show_bug.cgi?id=133011

Others feature is to tag automaticly an image :

http://bugs.kde.org/show_bug.cgi?id=128333

And another to tag an image for future batch processing :

http://bugs.kde.org/show_bug.cgi?id=139465

Do we want to store make/model as strings for each entry, or use a dedicated
> table "Cameras"?


Make and Model separatly. strings will be extracted from Exif and always
encoded as ASCII-Latin1.

Thanks for this review Marcel...

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070829/9c78960e/attachment.html>