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

[Julien Narboux]

Hi,

Maybe it would be easier to write this list on a wiki ?
Here are some other field which may be useful:

Gilles Caulier a écrit :
>
>
> 2007/8/29, Marcel Wiesweg <marcel.wiesweg at gmx.de 
> <mailto: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
>
+ numerisation date : for digital cameras creation date = numerisation 
date, but not if one scans film.
>
>     - 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
>
- the type of lens when it is available.
>
>     - exposure time
>     - exposureMode
>     - exposureProgram
>     - sensitivity
>     - flash
>     - whiteBalance
>

- macro
- focus mode
- stabilization
- pixel binding or not
- measure mode
- color or bw
>
> => 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)
>
- picture taken in panorama mode or not (can be extracted from exif at 
least for canon cameras)
- picture is hidden or not : maybe this fonctionnality could be added to 
digikam in the future.
- quantity of blur : maybe this fonctionnality could be added in the 
future, there exists some algorithm to measure blur. It would be nice to 
have it to compare a bunch a picture and eliminate those which are out 
of focused
>
>     - 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
>
>
- tilt (nb of degrees with regard to horizontal)
- orientation (compass)

> + 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
>
- the md5sum of the uncompressed picture to be able to detect identic 
tiff and png for example
- the id of the pile of pictures it belongs to
- the id of the picture if it is a copy of some other picture (if the 
copy has been produced using digikam)

>     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

And what about comments about a region of the image ?

Maybe a comment could have the following fields (think of a photo agency 
which has to manage many many pictures taggd by different peoples):
- text
- author id (name and possibly email or ip address...)
- creation date
- modification date
- region of the picture
- language
- parent comment

Tags could also contain language information, this would allow to search 
modulo synonymous or to search using another language thants to a 
dictonnary.

My 2 cents,

Julien