[KimDaBa] Wishes, bugs, or both .. and a bit of EXIF

[jedd]

 Howdi,

 Firstly, Jesper, thanks for a superb program.  I'm still in the experimental
 part of the process with kimdaba, so some of the following issues are
 quite likely to be things that I just don't understand yet.

 Debian (unstable) package
 I think this is slightly borked -- it has a reliance on components of KDE 3.2
 which aren't in the unstable branch of Debian .. yet.  I think 3.2's schedule
 to be in Debian-unstable within a fortnight.

 Multiple XML files
 I don't like this idea either.  In fact I'd like to have the XML file (s) for a
 particular tree located outside that tree -- because I'd like to have my pics
 stored in a read-only structure.  Vaguely related, it'd be nice to tell kimdaba
 to not create any ThumbNails at all -- they clog up my otherwise pristine
 directory structure.  One of the things that really attracted me to kimdaba
 when I first found it was that it doesn't feel the need to frig around with my
 perfectly sensible (to me!) directory structure.

 Renaming files
 The MD5 approach seems to work well, but I'm at a loss how you can
 tell kimdaba how to 'forget' a bunch of files that it can't see locally anymore.
 I don't use offline stuff, but respect that others do, and that this complicates
 the issue of retiring files that you don't have anymore.  I'm not sure how best
 to do this -- perhaps a 'Scan and remove entries for obsolete files' menu item
 that asks you "Are you really really sure?" a few times.

 Bug -- Off by One
 When I start kimdaba with a new images structure, it says that there's
 1 image in each of Keywords, Locations, and Persons - but in fact there's
 none.  When I attach a single person's ID to a single photo, 'Persons' then
 asserts '2 images' .. et cetera.  'None' is a handy thing to search for (see
 next point) but the logic of  0 + 1 = 2 is a bit misleading. ;)

 Wishlist / Confusion-Reduction-Request
 When I add new directories to the database later, is there a straightforward
 way of identifying those new / un-annotated pictures so you can then apply
 keywords & confirm dates associated with those new files only?  I'm guessing
 the 'None' keyword search above, looking for empty Location AND Persons
 AND Keywords is the recommended approach ... ?

 Sorting
 Perhaps related to that last problem, are there options with sorting the
 files?  When I replicated a sub-dir full of images with the same directory
 name appended with a '-a', that appeared right at the end of the raw
 image list (in lots of 100).  Because my sub-directories have either a
 date-string (yyyymmdd) or incremental number sequence in them, I'd
 be happy for kimdaba to sort based on directory names rather than what
 ever it uses currently.

 EXIF  and date-time handling
 I've got a hybrid collection of files - some (1200) scanned in film photos
 in PNG format that have way wrong date-stamps on the files, some (6500)
 photos from friends that may or may not have reliable date-stamps but were
 put in sub-dirs that reflected the dates of the events, and a few (1700) pics
 taken with my digital camera, that therefore have accurate EXIF date fields.

 With the first set, the primary problem is that PNG doesn't cope with EXIF
 tags, so I'm happy to set the time-stamps on the files themselves (this is
 relatively easy to script).  I'm paranoid about losing those timestamps, though,
 and am toying with converting the files to TIF's just to get EXIF data into
 them.  The exif tools aren't particularly friendly, however, but this does
 answer an earlier question about what's available out there.  [1]

 It does mean that I need to set the date/time stamps on all those files before
 I start to create the 'real' index.xml file, because I only want to set the date
 information once -- at a file system level -- and not have to revisit it within
 kimdaba later.  UNLESS .. there's a way to re-acquire the dates of a set of
 files within kimdaba?

 The second set (some digital, some not) just presents the same problem,
 and it's infeasible to programmatically acquire the date from a directory
 name -- everyone has their own unique nomenclature.

 BUT it would be relatively easy to apply dates to a set of files within
 kimdaba, based upon what directory they're in.  Identifying where a file
 really lives, within kimdaba's interface, is certainly easier now that its
 URI appears in the status bar.  Without this it used to be very confusing
 for me because I had 0x320 and 0x800 subdirectories in every directory
 that contains 320p and 800p wide thumb nails, and there was no way to
 tell kimdaba to ignore certainly sub-directories (as duplicates, or for
 whatever reason).

 With the third set -- my digital camera pics -- kimdaba seems to prefer
 to take the date-stamp of the file over the EXIF data, so the solution there
 [again] is to fix up those date-stamps (probably using exif tools) before
 creating the ultimate index.xml.

 How have other people approached these kinds of problems ?

 Btw, Jesper -- gqview (my preferred image browser as opposed to cataloger)
 can show EXIF data -- this may be of use as it's released under the GPL.  I'd
 expect that it should be relatively painless, a subjective assessment I know,
 to rip that code out of gqview and use it to acquire the EXIF Date for kimdaba.

 Cheers,
 Jedd.


 [1] The Exif tools are pseudo-shareware of sorts, and are available in
 command-line form for GNU/Linux boxen at  http://www.hugsan.com/
 exifedit can ostensibly insert EXIF fields into an image file, and exifdate
 can modify the date/time EXIF fields, including the neat feature of taking
 the time-stamp of the file and putting that into the EXIF area.



-- 
 jedd == jedd at progsoc dot org
 "The unemployment queue is no longer just for philosophy
 majors - useful people are now being affected too."
			  -- Kent Brockman, The Simpsons.