[KimDaBa] Need input on RAW files

[havoc]

Robert L Krawitz wrote:
>    From: "Jesper K. Pedersen" <blackie at blackie.dk>
>    Date: Fri, 25 Nov 2005 11:03:06 -0500
> 
>    Yes I know we have been through this before, but I'd rather start a
>    fresh discussion than reading mail archives :-o
> 
>    Previously people have asked for kimdaba to store jpg files and raw
>    files side by side. So kimdaba would show and use the jpg file, but
>    have the raw file handy for further processing.
> 
>    I'm currently reading a book on SLR cameras and photo techniques, and it
>    suggest cropping images to get a more powerful picture. That makes a lot of
>    sense to me. I have, however, always been reluctant in doing so, since it
>    would throw away information.
> 
>    So here it might also make sense to have the concept of an original
>    image, that, and an actual (cropped or converted or manipulated in
>    other ways view).
> 
>    The input I'd like from you is, how should this look and feel from
>    the KimDaBa user interface?
> 
> How about each image being a container that actually stores one or
> more associated images (including the original unmanipulated image)?
> 
> I've seen icons that look like a stack or deck of documents, something
> like this:
> 
> 
> ---------
> |       |
> | ---------
> | |    	  |
> | | ---------
> |_| |  	    |
>   | |	    |
>   |_|	    |
>     |	    |
>     |_______|
> 
> Each image that has more than one related images would have this icon
> associated with it.  If you click on this icon, you get a preview view
> of all of the associated images.
> 
> Why something like this?  You might want to try multiple edits to a
> single image to see what works well, or you might have multiple crops
> to different aspect ratios, or some such.  This is all akin to the
> concept of a negative (which you always preserve) and
> prints/manipulations of the result (which you create and destroy
> freely).
> 

I really like the direction this is going, but I can see that it might
be a bit difficult to do the back-end stuff to keep the images 'tied'
together when the variations are being spawned from disparate
applications (some straight from Bibble, others manipulated in the Gimp,
etc).

if you can do the data handling, this would be an extremely elegant way
to manage variations, but I don't relish the job of the programmers!

I would like to be able to attach separate notes on each of the
variations, and the creation date of the original image as well as the
creation date of the variation would both be important data to maintain.

jody
-- 
http://www.RealizationSystems.com/ -- start communicating
http://www.GalacticSlacker.com/ -- read it and weep