[KPhotoAlbum] General interfacing (was Re: Configuration dialog RFE/annoyance)
Robert L Krawitz
rlk at alum.mit.edu
Sat Mar 4 22:52:32 GMT 2006
Date: Sat, 4 Mar 2006 16:18:53 -0500
From: "Mark Eichin" <eichin at gmail.com>
On 3/4/06, Robert L Krawitz <rlk at alum.mit.edu> wrote:
> I have yet to find a better tool for organizing photographs. My
> wife uses iPhoto, which is dreadfully slow and doesn't really
> seem to offer much of anything that KPhotoAlbum doesn't.
> KPhotoAlbum is blazingly fast; much of it seems to be limited by
> disk/filesystem performance more than anything else.
Indeed, I've tried to use iphoto a number of times - and usually
with each new major release, I find that it just can't handle my
collection size. (Even if it could, I probably wouldn't *like* it
because it's not very keyboard-friendly - I run kimdaba under
ratpoison, and so far I have 3000 photos in it and it just cooks
along...)
I'm at around 11,000 photos right now. We've had a lot of discussion
on the list here about the importance of scaling to 50,000 or more.
Every now and then I try playing around with f-spot or digikam or
whatnot, and I never find it very satisfactory.
> One thing that would be handy (and probably very simple) would be to
> integrate it with PhotoPrint. That's a Gutenprint client that one of
> our developers has put together (see
> http://www.blackfiveservices.co.uk/PhotoPrint/About.shtml). Currently
> I have to export photographs to a directory and then run PhotoPrint;
> it would be very neat to have some kind of integration.
While gutenprint should probably get directly integrated (is
gutenprint isolated enough that the fact that one is GTK and the other
is KDE likely to not matter?) it occurs to me that I should elaborate
on the strategy I used for flickr-sync, even if it isn't quite ready
for primetime:
http://www.thok.org/intranet/python/exif/index.html
(Copying Alastair Robinson, the PhotoPrint author)
Gutenprint itself is just a library of printer drivers, albeit with an
API that permits building user interfaces around it. PhotoPrint is
based on GTK+, but it's possible to pass in a list of images via the
command line.
The key discovery is that (1) python cElementTree is well-suited to
the flavor of XML kimdaba uses, and is very fast (2) "I want to do
this" is a valid meaning for a tag, beyond the usual "this is in
this picture" or "this picture is about this".
If I'm reviewing pictures and decide I want to put one up on
flickr, I just add "flickr" as a tag. After saving/exiting
kimdaba, I run the tool, which parses the XML, finds all pictures
tagged with flickr, and uploads them. Once the upload works, it
adds *another* tag to the picture, "flickd"; next time around it
filters those out when looking for things to upload. [An alternate
strategy would be to delete the "flickr" tag but I happen to like
knowing which pictures I've already uploaded.] While uploading, it
includes all of the other tags as well.
This strategy could be used for other programs; you could drill
down to a subset, use c-2 to mass-tag them, and then run the
standalone tool. Alternatively, you could set up "standing orders"
- for example, I take a lot of pictures for work, including
pictures of whiteboards for-the-record; by tagging those with work
+ whiteboard, currently I can manually select them and generate an
album, but ultimately I want to have an automatic tool do that. (I
haven't found a Kimdaba "batch mode" or I'd have already done it -
instead I'll probably end up using kid templates for an album
builder... Back in the day, I did this with some perl scripts and
BINS (sautret.org) but it had scaling issues too...)
This does rely on the index.xml format not changing much, but if it
stores the same data it probably isn't going to ever end up *too*
different.
More information about the Kphotoalbum
mailing list