[KimDaBa] KimDaBa 2.0 is released.

[jedd]

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.

 Jedd.