[KimDaBa] Need input on RAW files

[William Holland]

On Friday 25 Nov 2005 17:04, havoc wrote:
> Robert L Krawitz wrote:
> > 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


I also really like the idea of this.  

I also agree that the data handling would be the most tricky part of it, so 
the options for this (as I see it) are as follows:

1. Dialog box.
After I have imported my original, I can attach other images to it by clicking 
on the original (parent), and finding the child.
- Time consuming, so not good for when a batch operation has generated many 
children of many parents.

2. Naming convention for files (probably all kept in the original directory).
Automatch Original.raw to Original.jpg and Original_email.jpg etc
- Means that you must keep the original Name throughout.
- Difficult if you want to have child in different location from parent (as 
you will have to make sure that everything has a unique name)

3. Separate trees
Same name, same location in tree, but different roots.
- Again problem with naming convension (you must have one).


To Me, Option 1 will cover any funny cases, where something has happened in a 
hand-crafted way, and I probably don't mind the overhead of linking it back.

Options 2 and 3 will cover the Batch generation process.

Personally I keep my originals in a separate directory tree from my viewing 
versions, and my Edited versions, so I would generally be working in modes 1 
and 3.

As far as the data handling internal to Kimdaba goes, I rember suggesting that 
there were simply multipe <file> tags within one image, with one selected as 
'original', and probably one selected as 'thumbnail' if it couldn't be 
extracted properly, however someone else suggested that they should all be 
independantly taggable, which sounded like a very good idea, so I think that 
images should have an extra tag available:
<parent> none </parent>
which either refers to nothing, or to the index of the parent, which then 
leaves the question, do I return all 'children' when searching for a parent, 
or do I do a join, so I don't need to actually repeat the tags from the 
parent into the child, but still allow the child to have it's own.
I suppose when updating a parent's tag, it could automatically update the 
children, but not vice versa.
We could also have two modes of operation for searches:
1. treat every image in it's own right
(return all versions of an image if the parent matches)
2. treat every image though it's parent
(return the parent, and filter the children available, when the parent is 
clicked on)
3. return the child only if the parent doesn't match, and return the parent 
only if it does match.

We will need some configurablility as to if once a parent is found, that not 
all the children are displayed if they don't match (or perhaps people would 
prefer all the children to be displayed if only one child matches)

Sorry for my wild ramblings,

I hope that i've made some sence, or at least thrown in a few ideas  that can 
be worked with/shot down.

Will
  --

PS for my workflow, which basically consists of generating smaller images that 
can be worked with a bit quicker, keeping the originals safe, and when 
required saving an original, and cropping (to various aspect ratios), and to 
keep track of the images, I have one index.xml which is soft linked into 
several trees, where I can search my 3x5 tree to find the 3x5 version of a 
file that I'm working with.

It would however be nicer to see only the images that I have a  3x5 version 
of, but since these are only in the region of about 100 images, I'm fairly 
safe just loading them all into xzgv and thumbing through them if I can't 
rember if I've generated that version (yes I know I should tag things, but I 
get lazy sometimes and forget :( )