DB-based collection feature

Hello,

I know there's some work in progress to store some image (meta)data
inside the images so that a user can find it from gqview (sorry, when
I read about it I found it insufficient (for me) and can't find the
details anymore...).
I have a different approach which I'd like to realize and I'm looking
for comments, ideas and maybe coders. 
Maybe my desired approach is completly wrong, as I haven't found
this feature in any image viewer for X yet (haven't searched a lot - I
like gqview).

Background:
As of today, many people have digicams, and take a lot of pictures.
Many pictures means a lot of information, which needs to be managed
properly. 
Managing this huge amount of information by name and date(i.e.
creating directories by date and giving each picture a describing
name) is not sufficient, if the user wants to see images which match a
certain criteria (e.g. show me all pictures taken in Sweden since Jan
31, 2004, or, show me all images taken with the aperture 2.0).
This means gqview should offer a method to find images by the data the
images are carrying in the EXIF part and by some additional
information the user adds to an image.

Idea:
Gqview offers a feature called 'collection', where a user can create
and load a collection of images. So far a collection has to be
created manually and is stored as a list of paths to images on the
filesystem. A user can load a collection and view the images it is
pointing to.
This feature can be modified so that a collection is not created
manually anymore, but created from a database query output instead,
depending on the data a user enters into an input mask. The output
should be in the same format as a collection is used at the present -
a list of paths to files.

Technical details:
As the collection feature already has bindings to the displaying
parts of the gqview code one would only need to create new menuitems
for the gui and replace the file load routines with the database
access routines - this is pretty straightforward.
The database shouldn't store the images themselves, only the paths to
them and the image data + metadata (I think the database should store
the EXIF data + the additional information added by the user -
retrieving EXIF data in realtime might? slow down the query process
significanly)
User interaction would happen in two ways:
In SQL terms a user would need a SELECT mask to search for images
matching a certain criteria. Here, most of the values could be
hardcoded (e.g. date or aperture). The user should be able to select
them from dropdown menus.  There also needs to be a metadata
input field (image description field) which should accept a number of
keywords describing the image.
The second way is the INPUT mask. It should extract the EXIF data
from the image (if there is any) and fill in the proper fields (which
might not be always that easy due to the known EXIF format problems)
automatically, or allow the user to input the information.
Additionally there needs to be a field to allow the user to enter
metadata about the image.

In both masks all fields should be optional.
A query without any input should return a collection of all images in
the database.

I'm sure there are a lot of other features which could be added (e.g.
a 'private' checkbox which doesn't include images unless a 'private'
checkbox is checked in the SELECT mask -> images could be marked as
prive in order to hide them from 'public' dia shows) but this is not a
subject of the general design.

Conclusion:
Work which needs be done includes:
- General design definition - implementation through the collections
  feature is just one idea
- Useful query attributes
- DB communication - is quite straightforward mysql/postgres (maybe
  even a generic db interface?))
- Creation of the INSERT mask (probably the biggest work - next/prev
buttons'n'stuff (a lot can be copied from image properties code))
- SELECT mask (should be straightforward, too)

Misc:
- I'd be happy if anyone would do the GUI stuff - my gtk days are over
since 1.2.10 :)

Anyway, I hope someone out there likes the idea - it'd be cool if this
got added to the main source tree (once it gets coded). I'm going to
code against 1.4.3. 

bye,
Martin Novak

-- 
alais alias=alais


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click