[KimDaBa]

[Robert Krawitz]

From: Robert L Krawitz <rlk at alum.mit.edu>
To: blackie at blackie.dk
CC: kimdaba at klaralvdalens-datakonsult.se, rlk
In-reply-to: <200407181741.38859.blackie at blackie.dk>
Subject: Re: Kimdaba ideas
References: <200407122221.i6CML1WW020220 at dsl092-065-009.bos1.dsl.speakeasy.net> <200407181741.38859.blackie at blackie.dk>

   From: "Jesper K. Pedersen" <blackie at blackie.dk>
   Date: Sun, 18 Jul 2004 17:41:38 +0200

   Please direct questions/comments/ideas etc to the mailing list.

Sure.  How do I subscribe?

   On Tuesday 13 July 2004 00:21, Robert L Krawitz wrote:
   | For the past week, I've been on vacation.  Part of that has included
   | being official photographer for a convention I've been attending, and
   | to date I've shot 2000 images.  I'm going to have to create some DVD's
   | for people from these, so I've had a lot of time to play with kimdaba.
   |
   | 1) Export a textual list of image files matching a given set of
   |    criteria (a new entry on the File or File->Export menu).  The
   |    purpose of this would be to permit building a CD-R or DVD of images
   |    from a list of filenames, or many other potential uses.  This is
   |    very high priority, as there is really no way to do this.

   I've got no plans to do this in kimdaba. You may very easy make a
   plugin for this yourself if you want (and use KimDaBa from CVS or
   snapshot from today).  As always I'm open for doing such extensions
   for money if it is important for your business, and I find it a
   worthy extension to KimDaBa. Ask me for an offer if interested.

I'll probably do a plugin for this myself, then.  I think it's a
useful thing for a lot of general purposes (the example of building a
CD or DVD was just that -- an example), but I don't imagine it would
be too hard to do.

   KimDaBa in CVS includes a KIPI plugin for creating cds, btw.

   | 2) Export a .kim package by means of hard links next to the images
   |    rather than actual copies.  This saves space and time during the
   |    export phase.  I actually implemented this; it's really quite
   |    trivial.

   And how would that work if you copy the resulting files to another
   machine?

It would "just work" if you're simply copying the files.  If you want
to preserve links, an archiver like tar or afio will do that.
	     
	     hmm maybe that would not be a big issue.  Please send me
   a patch if you already got this working.

OK, once I get out from under the big system upgrade I've been doing.

   | 3) Add an option to export to preserve the directory structure (maybe
   |    this should even be the default).  What happens right now if there
   |    are two files with the same name in different directories?

   Files are renamed if there are duplicates. I did consider keeping
   the structure, but that doesn't really make much sense in the
   receiving end, does it, I mean what would my directory structure
   help you? In any case the receiving end can change the structure on
   his disk, and KimDaBa will recognize it and update its database.

At least my camera saves images in folders of 100 images each;
preserving the structure makes importing future images more easily.

   | 4) Enable right click (context menu) in category view.  I currently
   |    have almost 2000 images in one of the categories, and I'd like to
   |    be able to apply an operation to all of them rather than having to
   |    go through them 100 at a time (setting the images per page to 2000
   |    makes the X server consume wildly excessive amounts of memory).

   This is something we are looking at for KIPI. Which operations did
   you have in mind here? stuff like setting properties for a bunch of
   images?

Yes.

   | 5) Allow selection on other criteria, such as EXIF rotation.
   | This would permit applying a command, such as convert, in order
   | to rotate all of the rotated images, since other apps don't deal
   | with EXIF info.  This may not be the best way to do what I'm
   | thinking of...

   I've considered this a number of times, it is indeed not gonna be
   easy to implement in kimdaba, so its still postponed, I believe
   there are more important issues.

That's fine.  Perhaps a more general thing that would be useful would
be an ability to filter on the output or exit status of an external command.

   | 7) Thumbnail generation is very slow, a few seconds each from a 6
   |    megapixel file.  This was extremely unpleasant when adding 600
   |    images.

   I need a more specific bug report, esp one made using "kimdaba -demo" 
   thumbnail creating is much faster in currect CVS version btw.

I'll have to retry this with the CVS.

   | 8) It sometimes seems when generating thumbnails that 256 pixel
   |    thumbnails are always generated in addition to the size I'm using.
   |    This of course means that thumbnail generation is even slower than
   |    it would be otherwise.  I usually generate thumbnails at 64, 128,
   |    256, and 512 pixels to enable me to see the thumbnails at different
   |    resolutions.

   This is for the previews you can get using Ctrl-T - thats a feature
   not a bug, go have some coffee, after all, its only a one time
   thing.

It's hardly a feature if the 256 pixel thumbnails are regenerated for
each of the other sizes.

   | 9) Perhaps certain thumbnail sizes should be offered as standards that
   |    can be selected from the menu bar rather than in the configuration
   |    menu.
   | 10) A tool to import images from a camera or flash card into the image
   |    directory would be useful.  Currently I'm using tar to do it; I'm
   |    thinking of writing an expect script to do it, too.  But this would
   |    be useful in kimdaba for photographers who frequently have to add
   |    lots of images to the database.

   There are a plugin for this, I'm not sure how it works tho.

OK.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton