[KimDaBa] KimDaBa 2.0 is released.
jedd at progsoc.org
Tue Oct 19 16:37:13 BST 2004
On Tue, 19 Oct 2004 11:01 am, Robert L Krawitz wrote:
] I find it particularly valuable with over 5000 images and growing
] fairly rapidly (on vacation I typically average about 100 shots per
] day, although I had one event this summer where I was the official
] photographer when I shot over 600 images in an evening).
I only averaged 52 shots a day on my last holiday. But they *were*
all 3-4mb images .. which should make up for the shortcoming. :)
] images from the cameras and convert the raw images to jpeg's for
] indexing. I also mirror the images to a second computer for safety.
] Although most of the time I don't actually need it, having the folder
] system is very helpful in some cases.
Do you do all photography in the camera's raw format? What do you
do for colour spaces? My camera gives raw's, tiff's, or jpegs .. and the
bother with the first two, and the quality of the best jpeg setting,
convinced me of the merit of taking photos in the format that I'm going
to ultimately keep them. I used to use PNG's for all my scanned photos,
but the lack of EXIF data and the comparable quality/space ratio for
low-compression jpeg's turned me off those, too.
As to folders .. historically I've stored them in sub-directories based
on the size of CD's, and later DVD's .. to make archiving easier. It's
still an effective system since it's inherently date-based, and it's a
system I adopted some time after I started using KimDaBa .. for all
my older images (plus those shared by friends) I keep them in something
like a 'yyyy month dd - verbose text description' folder structure.
I also run a script over all new images to force file time-stamps to match
the exif time stamp .. useful back when KimDaBa preferred to trust file
times .. and still occasionally useful now.
] 1) Export preserves folder layout. This would be very helpful for
] exporting a set of images for purpose of mirroring them, or for
] backing them up to DVD's in a form that I could easily use to
] restore them later. The scenario would be that I would select all
] images not previously backed up (by means of a keyword) and export
] them preserving layout, and dump the exported tree to DVD. This
] would combine very nicely with the export by (hard) link patch that
] I've submitted.
I think the backup aspect of this would be better left with the genuine
archival utilities out there. Certainly exporting, and keeping structure,
would be a nice feature .. you sure the drag-n-drop features don't provide
something like this already, even indirectly? (I haven't played with the
export functions much -- haven't had the need yet.)
] 2) Hierarchical folders, that would emulate the actual file storage.
You mean hierarchical groups .. ? I'm still trying to get my head around
what my actual problem is with the existing group system. In some cases
I want an automatic forcing of group membership for some sub-groups,
but there's no elegant way to identify these things ahead of time. The
extra optional groups are inelegant, only insofar as they're not visually
seamless in KimDaBa yet, but go some way to resolving the problems of
'keyword' being an effectively miscellaneous catch-all .. that unavoidably
gets bloated. As someone pointed out recently it's easy to get duplicates
in there .. and quite hard to find them.
Perhaps the auto-completion aspect needs to drop down a list of partial
matches, much like a konq window does .. but perhaps be even smarter
about it and show partial matches that don't necessarily rely upon the
match being at the *start* of the string. That way typing 'flower' would
show me everything that starts with flower, as well as where I've not put
the adjective after the noun in a category description.
Or if not a drop-down box, then a dynamic resorting of the entries in
that category .. so that all the matches appear at the top of the listing.
The only problem with that approach .. is that it defeats the 'most
commonly/recently used' algorithm currently in use, plus it makes it
difficult to visually identify where the potential matches end.
] 3) A way to associate raw files with jpeg's (and then be able to
] export both). This would need a bit more knowledge of cameras.
Do you have both formats right next to each other in the same directory
structure? Can I ask why ..? (As I say, I use jpeg's now, but don't know
if I'm missing something fundamental about going down this path ..
other than saving 14mb of space per image.)
] 4) Find all images with changed checksums (rather than merely
] recompute the checksum). Again, this would help identify images
] requiring backup.
You mean on images that you've modified and then inserted back into
the system .. ? Yeah, I think I've done that once, and tried to work out
an elegant approach for resolving that .. but it's a tricky thing that'll
likely involve manual work no matter how you approach it. Just because
a filename's the same and the checksum's different, doesn't mean it's
the same image. Particularly with digi image names. So a human is going
to have to tell KimDaBa what to do in that circumstance anyway.
More information about the Kphotoalbum