What do we want to store in the database?

[Marcel Wiesweg]

Hi,

It is a long-planned task for the next release to store more information than
currently in the database.
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
- 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
- orientation

- GPS:
 - latitude
 - longitude
 - altitude

- similarity searching with a Haar-like algorithm matrix


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)

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

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

If you have remarks and additions, now is the time!

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/29, Marcel Wiesweg <[hidden email]>:

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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia środa 29 sierpień 2007, Marcel Wiesweg napisał:

> Hi,
>
> It is a long-planned task for the next release to store more information
> than currently in the database.
> 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

I think we can split all data about image in 3 parts:

- information about file
- information about image ("hardware")
- metadata, here I think the best choice (as industry standard) is "IPTC
  Core"

>
> Currently I have these fields on my list:
>
> - comment
> - rating
> - creation date
> - modification date
> - size ( dimensions in pixels)
> - color depth (8, 16)
> - color model (RGB, CMYK, ...)

- If px size is included why not weight (size in KB/MB)? I know it can
  be read from filesystem but putting info in db could make some queries
  faster
- all path related things (Album path, name of file)

> - make of the camera
> - model of the camera
> - aperture
> - focal length
> - focalLength as for 35mm film
> - exposure time
> - exposureMode
> - exposureProgram
> - sensitivity
> - flash
> - whiteBalance
> - orientation

- metering mode
- focus mode
- file number (although it can have different formats so its usefulness
  can be questionable)

>
> - GPS:
>  - latitude
>  - longitude
>  - altitude
>
> - similarity searching with a Haar-like algorithm matrix
>
>
> 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)
>
> There was a discussion about multiple comments; what is the status about
> this?
>
> Do we want to store make/model as strings for each entry, or use a
> dedicated table "Cameras"?
>
> If you have remarks and additions, now is the time!

Big question is handling of metadata. I'd like to see whole IPTC Core
put into database... For fast querying of those items and making it
independent of actual images.

m.

ps. Disclaimer: I work in photo department of big museum in Poland
    and my primary responsibility is dealing with management of
    digital photographs and digital versions of analog materials.
    Usually my comments, wishes, etc. are biased from that
    perspective. I'd really like to use Digikam in my work :)

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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 <[hidden email]
> <mailto:[hidden email]>>:
>
>     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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/30, Julien Narboux <[hidden email]>:

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 <[hidden email]
> <mailto:[hidden email]>>:
>
>     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

=> Makernote information. Complex to extract.  

- focus mode

=> Makernote information. Complex to extract.

- stabilization

=> Makernote information. Complex to extract. 

- pixel binding or not

??? 

- measure mode

==> std. Exif. easy to do.

- color or bw

==> redondant with color mode information. 

>
> => 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)

=> Makernote information. Complex to extract.  

- picture is hidden or not : maybe this fonctionnality could be added to
digikam in the future.

Agree with this one
 

- 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

=> Makernote information. Complex to extract.
 
In general, storing Standard Exif informations is easy to do because all values are properly defined in Exif spec. It's easy to make an interface to seach these values in DB.

With Makernotes, it's the hell. Each constructor use a private spec to define values. It's complex to make a search interface. I propose to include all Makernotes informations in a second time.

>

>     - 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)

Why not ? But currently, GPSSync plugin do not extract these informations from GPX files.
 

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

On Thu, 30 Aug 2007, Julien Narboux wrote:

> Hi,
>
> Maybe it would be easier to write this list on a wiki ?

Marcel already started a wiki some time ago
http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion

Marcel, should we add all the thoughts there as well
(including comments ?)

> Here are some other field which may be useful:

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

This is an interesting idea (funnily, I thought about this
recently as well ;-): There is on "problem": sometimes
only a small region (e.g. a flower, insect, ...) of an image
is sharp and all  the rest will be blurred.
This one get a large value for blur, while it still
might be a perfect 5-star shot. So essentially
a local blur indicator might be needed.
This would require some interestings tests on algorithms ...
Do you have already some reference to the algorithms to
measure blur?

((To me this example just highlights that it would be nice
to allow for easy additions of new fields in the
database in the future, i.e. withouth the need to wait for
a 0.9 to 0.10 transition ...))

> >
> >     - 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)

Yes, this would be nice (Though I am not 100% sure, if this
has to be searchable?)
Additional remark:
This is useful for the KML 2.2 Photoverlay,
to precisely specify the region to which the photo
corresponds to, see
http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photooverlay
http://code.google.com/apis/kml/documentation/photos.html
http://www.gearthblog.com/blog/archives/2007/08/new_photo_viewer_wit.html

Also, this is of interest in the context of
gipfel, http://www.ecademix.com/JohannesHofmann/gipfel.htmlexternal link
which allows for finding the names of mountains
or points of interest on a picture.
(This uses: View direction, Nick angle, Tilt angle, Focal Length,
Visibility)

> Gilles wrote:
> > + 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.

What additional information is provided in the strings?

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tibor Blenessy]

Marcel Wiesweg wrote:

> Hi,
>
> It is a long-planned task for the next release to store more information than
> currently in the database.
> 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
> - 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
> - orientation
>
> - GPS:
>  - latitude
>  - longitude
>  - altitude
>
> - similarity searching with a Haar-like algorithm matrix
>
>
> 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)
>
> There was a discussion about multiple comments; what is the status about this?
>
> Do we want to store make/model as strings for each entry, or use a dedicated
> table "Cameras"?
>
> If you have remarks and additions, now is the time!
>
> Marcel

Hi,

I would like to have title of photo as special kind of short comment.
Having multiple comments would be also nice.


Tibor Blenessy


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

one more remark:

On Thu, 30 Aug 2007, Julien Narboux wrote:

> - picture is hidden or not : maybe this fonctionnality could be added to
> digikam in the future.

Maybe this could be realized by Tags getting an additional attribute
(visible/hidden)? This might be even more flexible?

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gerhard Kulzer]

Am Wednesday 29 August 2007 schrieb Marcel Wiesweg:

> Hi,
>
> It is a long-planned task for the next release to store more information
> than currently in the database.
> 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
> - creation date
> - modification date
> - size ( dimensions in pixels)
> - color depth (8, 16)
> - color model (RGB, CMYK, ...)
>
> - make of the camera
> - model of the camera

lens type (focal range in 35mm equivalent is available in Makernotes)
> - aperture
> - focal length
> - focalLength as for 35mm film
> - exposure time
> - exposureMode
> - exposureProgram

scene mode (Landscape, Portait, etc.)

> - sensitivity
> - flash
> - whiteBalance
> - orientation
>
> - GPS:
>  - latitude
>  - longitude
>  - altitude
>
> - similarity searching with a Haar-like algorithm matrix
>
>

I'm also in favor of putting this list onto the wiki

Gerhard


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/30, Arnd Baecker <[hidden email]>:

On Thu, 30 Aug 2007, Julien Narboux wrote:

> Hi,
>
> Maybe it would be easier to write this list on a wiki ?

Marcel already started a wiki some time ago
http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion

Marcel, should we add all the thoughts there as well
(including comments ?)

> Here are some other field which may be useful:

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

This is an interesting idea (funnily, I thought about this
recently as well ;-): There is on "problem": sometimes
only a small region (e.g. a flower, insect, ...) of an image
is sharp and all  the rest will be blurred.
This one get a large value for blur, while it still
might be a perfect 5-star shot. So essentially
a local blur indicator might be needed.
This would require some interestings tests on algorithms ...
Do you have already some reference to the algorithms to
measure blur?

((To me this example just highlights that it would be nice
to allow for easy additions of new fields in the
database in the future, i.e. withouth the need to wait for
a 0.9 to 0.10 transition ...))

This informations come from Makernotes. Look my previous comments about 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
> >
> >
> - tilt (nb of degrees with regard to horizontal)
> - orientation (compass)

Yes, this would be nice (Though I am not 100% sure, if this
has to be searchable?)
Additional remark:
This is useful for the KML 2.2 Photoverlay,
to precisely specify the region to which the photo
corresponds to, see
http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#photooverlay
http://code.google.com/apis/kml/documentation/photos.html
http://www.gearthblog.com/blog/archives/2007/08/new_photo_viewer_wit.html

Also, this is of interest in the context of
gipfel, http://www.ecademix.com/JohannesHofmann/gipfel.htmlexternal link
which allows for finding the names of mountains
or points of interest on a picture.
(This uses: View direction, Nick angle, Tilt angle, Focal Length,
Visibility)

> Gilles wrote:
> > + 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.

What additional information is provided in the strings?

Like the GPS device have a map (this is a road mapping guide device ), the GPX trace give me the GPS position of course + a string given informations about the place, for ex. "near the beach Foo", "At north of Eiffel Tower", or "At 100m of Foo station". Of course this stings can be backported as a comment (for ex. IPTC as a location description string).

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Arnd Baecker a écrit :

> one more remark:
>
> On Thu, 30 Aug 2007, Julien Narboux wrote:
>
>  
>> - picture is hidden or not : maybe this fonctionnality could be added to
>> digikam in the future.
>>    
>
> Maybe this could be realized by Tags getting an additional attribute
> (visible/hidden)? This might be even more flexible?
>
> Best, Arnd
>  

If you do it with tags you have the problem of i18n and typos, what if I
type "hiden" or "caché" (hidden in French)...
What happens if I tag a picture using the word "hidden treasure" ...
Obviously the user interface should hide hidden photos. Having the user
interface depends on tags seems to me to be not a good idea.

Best,

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/30, Gerhard Kulzer <[hidden email]>:

Am Wednesday 29 August 2007 schrieb Marcel Wiesweg:

> Hi,
>
> It is a long-planned task for the next release to store more information
> than currently in the database.
> 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
> - creation date
> - modification date
> - size ( dimensions in pixels)
> - color depth (8, 16)
> - color model (RGB, CMYK, ...)
>
> - make of the camera
> - model of the camera

lens type (focal range in 35mm equivalent is available in Makernotes)

==> look my previous comments about Makernotes.
 

> - aperture
> - focal length
> - focalLength as for 35mm film
> - exposure time
> - exposureMode
> - exposureProgram
scene mode (Landscape, Portait, etc.)

idem.

> - sensitivity
> - flash
> - whiteBalance
> - orientation
>
> - GPS:
>  - latitude
>  - longitude
>  - altitude
>
> - similarity searching with a Haar-like algorithm matrix
>
>
I'm also in favor of putting this list onto the wiki

Agree, but as a simple sheet of DB structure. I don't know if it possible to do easily with wiki.

My first proposal to Marcel by IRC is to make an OpenOffice sheet (:=))).

To resume : I would to have a document where we can found what is stored in DB, including full description of each field. Like we will host a lots of informations, this is important for the future...

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/30, Julien Narboux <[hidden email]>:

Arnd Baecker a écrit :

> one more remark:
>
> On Thu, 30 Aug 2007, Julien Narboux wrote:
>
>
>> - picture is hidden or not : maybe this fonctionnality could be added to
>> digikam in the future.
>>
>
> Maybe this could be realized by Tags getting an additional attribute
> (visible/hidden)? This might be even more flexible?
>
> Best, Arnd
>

If you do it with tags you have the problem of i18n and typos, what if I
type "hiden" or "caché" (hidden in French)...
What happens if I tag a picture using the word "hidden treasure" ...
Obviously the user interface should hide hidden photos. Having the user
interface depends on tags seems to me to be not a good idea.

Agree, a simple boolean flag need to be used for that.

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

> ((To me this example just highlights that it would be nice
> to allow for easy additions of new fields in the
> database in the future, i.e. withouth the need to wait for
> a 0.9 to 0.10 transition ...))
>  
I think you are raising the right question. I am not a specialist of
databases.
Currently, It seems to me that changing the database format is something
the developpers do not want to do too often and they rather want to wait
for major releases.
That is why I proposed some field which may be useful only in a far
future. I understand as Gilles said that some fields are currently hard
to extract because in Makernote. But maybe one day these fields will be
in new version of the exif standard...
Should these fields already be on the database right now even if they
are not filled  by Digikam and the corresponding features are not yet
implemented ?
Would it be easier to add some fields during minor release (10.1 ->
10.2) by adding  tables (picture_id, new_field) ?

My naive questions,

Julien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Hi,

Another thing which may be important to store in the database is
information concerning backups.
For each picture it would be interesting to now if it has been backed
up, when and the name of the backup...
But maybe this information should be OS general and not specific to Digikam.

Another thing which may be important to store in the database is
information concerning movies:
length, frame number of the thumnail used, ....

This raise the question of where to stop adding things. And is it
possible to share some infrastructure with amarok ?

Best,

Julien


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/30, Julien Narboux <[hidden email]>:

> ((To me this example just highlights that it would be nice
> to allow for easy additions of new fields in the
> database in the future, i.e. withouth the need to wait for
> a 0.9 to 0.10 transition ...))
>
I think you are raising the right question. I am not a specialist of
databases.
Currently, It seems to me that changing the database format is something
the developpers do not want to do too often and they rather want to wait
for major releases.
That is why I proposed some field which may be useful only in a far
future. I understand as Gilles said that some fields are currently hard
to extract because in Makernote. But maybe one day these fields will be
in new version of the exif standard...

I have never said than i won't to store few Makernotes info in DB. I just want to define the priority.

In first all info witch are easy to extract must be store. Others can be done later, because it's require more devel. time, especially about to parse all Makernotes cases.

About a future Exif 3.0 version, this sound like a vaporware. try to find Exif 3.0 information with Google, you will be surprised.

Of course, i'm agree with you than Exif spec must be improved, but this is not a simple task. Currently all makers use makernotes area to store unsupported tags by Exif 2.2. Perhaps than camera makers stand a new format to store data, for ex. XMP (:=))) But i'm not sure...

Should these fields already be on the database right now even if they
are not filled  by Digikam and the corresponding features are not yet
implemented ?

Yes, it's possible. Marcel your viewpoint ?
 

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

On Thu, 30 Aug 2007, Julien Narboux wrote:
> Arnd Baecker a écrit :
> > On Thu, 30 Aug 2007, Julien Narboux wrote:
> >
> >> - picture is hidden or not : maybe this fonctionnality could be added to
> >> digikam in the future.
> >
> > Maybe this could be realized by Tags getting an additional attribute
> > (visible/hidden)? This might be even more flexible?

> If you do it with tags you have the problem of i18n and typos, what if I
> type "hiden" or "caché" (hidden in French)...
> What happens if I tag a picture using the word "hidden treasure" ...
> Obviously the user interface should hide hidden photos. Having the user
> interface depends on tags seems to me to be not a good idea.

Sorry, I wasn't clear enough - I was thinking of an additional
boolean flag (not a string), associated with each tag.

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Colin Guthrie-6]

Marcel Wiesweg wrote:
> Currently I have these fields on my list:
>
> - comment

I think Multiple Comments is essential. But also comments need to be
qualified more than just a simple text stream. Gilles mentioned 4
strings to be stored but I'm not sure what they all are. My suggestion
would be:
 * Source
 * Who/Author
 * Language
 * Comment

Here the Source would 99.99% of the time be "Digikam" but hopefully this
interface can be exposed via e.g. Facebook/Flickr via Kipi plugin and
under these circumstances the Source would be set accordingly. Language
I think should be optional seeing as external comments may not have this
information associated with them.


> - rating

Tags, (as Gilles also pointed out). With the addition of a "region"
attribute (simple rect is probably sufficient here c.f. Facebook -
simplicity wins) as per http://bugs.kde.org/show_bug.cgi?id=146337


And another new one for you:
- key/value pairs

Some form of generic key/value pair storage system for every image,
album and tag. This would be to allow 3rd party plugins via kipi store
important information/configuration paramaters. Actually, possibly more
sensible is a blob of data instread, in which we can store an XML
kconfig dump although this would not allow easy searching... (e.g. it
would be quite useful for a kipi plugin to say "give me all images with
foo = 42".

This needs more discussion but I've often mentioned it in the past so
not a bolt from the blue.

Col

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/8/30, Julien Narboux <[hidden email]>:

Hi,

Another thing which may be important to store in the database is
information concerning backups.
For each picture it would be interesting to now if it has been backed
up, when and the name of the backup...
But maybe this information should be OS general and not specific to Digikam.

Agree. A backup flags need to be added for the future. Backup/restore tool is one other part to do in the future.
 

Another thing which may be important to store in the database is
information concerning movies:
length, frame number of the thumnail used, ....

Marcel ?
 

This raise the question of where to stop adding things. And is it
possible to share some infrastructure with amarok ?

With nepomuk it will be possible. But it's one other KDE4 part which still under developement and not yet tested/finalized/stabilized. This is for a more far future..
 

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Colin Guthrie-6]

Colin Guthrie wrote:
> And another new one for you:
> - key/value pairs
>
> Some form of generic key/value pair storage system for every image,
> album and tag. This would be to allow 3rd party plugins via kipi store
> important information/configuration paramaters.

Reading some other comments on this thread I'm beginning to like a
key/value system over a kconfig one.

We've already mentioned two specific flags - "backup" and "hidden" that
are suggested as additions to the database. Can we just use a more
flexible solution for this that would not require the database schema to
change?

e.g. what if key names, by convension, were namespaced:

 * digikam.backup = ".mypic.jpg.orig"
 * hostapp.hidden = "true"
 * kipi.sync.sink = "Colin's Gallery 2"

etc.

Would that be sensible? Would mean that extra simple values could be
added on in the future without any schema changes provided the utility
SQL generation code was written correctly.

Just an idle thought.

Col

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel