[KimDaBa] Wishes, bugs, or both .. and a bit of EXIF
jedd at progsoc.org
Mon Feb 16 07:59:41 GMT 2004
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.
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 ... ?
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. 
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
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.
 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.
More information about the Kphotoalbum