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

Mon Feb 16 08:34:26 GMT 2004

jedd <jedd at progsoc.org> writes:

|  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.
I'll leave this for Achim to answer.

|  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 solution so far is to make a shadow tree with symlinks, I know this
wont do in the very long run, but it has to do for now, as there are much
more important things on the TODO.

|  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.
maintenance | Display Images not on disk, and then delete those images.

|  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. ;)
Actually that's because it count the "None" group as one. I could easily
decrement the count by one, but then someone would claim that there were 1
item in the listbox more than what the count said ;-)

| 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 ... ?
Here is what I do (and one day I'll make a tip out of this, damn let me do
that now...)
Here it is:
When you bring new images to your collection, you might not have time
right away to categorize them (i.e specify Persons, Locations
etc.). Therefore, you might later want to find those images which has not
yet been categorized. Here is what I do: 
I use the <tt>keyword</tt> <tt>OK</tt>, which I set on images, once I've
categorized them. (i.e. just like you may have a keyword for <tt>Summer
Party</tt> or <tt>Interrail trip 1990</tt>, you now have a keyword
<tt>OK</tt>). To find uncategorized images, I choose the
<tt>Search</tt> item from the browser, and in the keywords line edit, I
type <tt>!OK</tt>. This will find all images which do not have the
<tt>OK</tt> item.

|  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.
It uses most recently used. please see other mail of today.

|  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?
No KimDaBa do not support that you later ask it to read the dates of files,
sorry.

|  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).
Later version of KimDaBa will include a browse option for directories too,
just like you can browse persons and locations now. But I guess that is
little help for you now.

|  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.
KimDaBa will use date stamp from files only if it doesn't find valid EXIF
information in the image.

|  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,
As stated above KimDaBa is capable of reading EXIF information, so if it
doesn't work for your images, then please mail me one of those images in a
private mail.

KimDaBa tries to solved the problem with scaned images by having the
possibility not to trust images - see Settings | configure KimDaBa -> Trust
image dates.

So maybe you should load in images into KimDaBa depending on whether they
have a valid time or not (load into KimDaBa here means tell KimDaBa to use
a given directory, and copy the images into that directory in turn)

Cheers
Jesper.