The Herd Of Kittens Python -- EXIF

Kimdaba Flickr SYNC

Kimdaba (now called KPhotoAlbum, but kimdaba was a much better name) is a smoothly interactive KDE-based photo tagging gallery that is much closer to what I want than anything I've used, or even anything I've written. It keeps data in a single large but accessible XML file, and I will be writing converters to move information back from bins and the other captioning tools you see below. (skip history)

Flickr is of course a widely known public photo tagging gallery site.

Kimdaba has an existing KDE plugin channel, called "kipi", shared with "digikam" and a few other apps, and there's a "Flickr Exporter" in the latest kipi-plugins (later than Ubuntu Breezy, at least.) However, while it lets you drill down to a set and then pick individual pictures to upload and tag - it's very much a one-shot-upload tool, and not useful for maintaining a correspondence.

I needed an excuse to play with the new python "elementtree" XML libraries, and with a small amount of effort I was able to pick bits out of the Kimdaba index.xml. Thus, the kimdaba_album module, which lets you select images via set inclusion and exclusion, add single keywords to existing images, and actually find the default XML file from the KDE configuration.

Given that interface, it was a small step to come up with a one-way-sync algorithm: Any image tagged (in Kimdaba) with "flickr" but not tagged with "flickd" should get uploaded. When said upload succeeds, add the "flickd" tag to the original. This is implemented in the kimdaba_flickr module, the "push_images" function just does the work directly.

Then, all I needed was a way to actually upload those images. The Flickr API pages have lots of detail, and pointers to existing toolkits. Python is all about modular reuse, so I hoped to use one of them, but none quite went down to the level I was looking for - instead, they had other features on top that got in the way of the abstractions I wanted to use:

• uploadr 2005-10 is specifically about syncing a directory, but is written in a way that "owns" the problem - tags are module-globals, not parameters, for example. I've used this before, and it was useful for comparison in my later debugging - it just doesn't fit the abstraction I wanted.
• flickrapi v7 is interesting in that it lets you create functions by using them, so it doesn't have to stay up to date - but at the same time, it doesn't have any checking of those interfaces, and leaves you with potentially as much debugging as you would have if you were using "xmlrpclib" directly - not my style either.

• FlickrClient 0.2 is fine for poking at the various simple functions, but doesn't implement upload at all - it was mostly interesting in that it inspired flickrapi. (Also, it uses xmltramp, which isn't in Ubuntu Breezy - not a big deal, but worth a casual mention.)

• flickr.py v24 didn't have upload support either - and it also hadn't been updated for the new "auth-token" login mechanism. It did have a more photo-as-object design than the others had, which is worth a look for writing flickr-browsing apps.

So, I spent some quality time with the Flickr API docs and came up with flickr_post which has both a script-friendly commandline interface (want to upload a single file, with a set of tags, a privacy setting, title, description, and rotation - at the end of a find|xargs pipeline? This might be what you're looking for) and a straightforward "upload_one" function that fit in the hole I left in kimdaba_flickr...

Note that these are still a little noisy. --register is implemented but hasn't been tested by anyone else. I have flickr_post itself end-to-end, and it does exactly what I wanted.

TODO list:

• see if anyone wants two-way sync and what they actually mean by it. (I don't, personally...)
• update metadata for already-uploaded pictures
• actually confirm that rotation is the same direction :-)

Download

Pieces to download:

• kimdaba_album
• kimdaba_flickr
• flickr_post

Dependencies:

• python 2.4 (it's in Debian sarge, noone else has an excuse. 2.3 support might not be hard, and if you manage it let me know, but life is too short to tolerate ugly code so I won't actually take any ugly changes.)
• elementtree or cElementTree (developed with the former, then switched to the latter for speed. You could probably make flickr_post itself work without either of them and switch back to using regexps to parse some of the responses, but that would be ugly and elementtree will be an "included battery" python 2.5 anyhow, so you might as well start with it now. Also, it's in Debian sarge, see above.)
• Unix. I use os.path.expanduser, slashes in filenames, and \n. It's not like you're going to have kimdaba around on anything else. (Mac OS X counts as Unix - if someone points me at an OS X kimdaba build, I'll test this there too.)

Newest features:

• uses cElementTree for speed, with fallback to ElementTree [20060227]
• --register, --check
• keyword groups are now expanded before uploading
• friendsonly and familyonly kimdaba tags become flickr privacy flags

auto_album

Simple album-generator, for taking a description and keyword pattern for an album and generating scaled sizes and html.

• auto_album.py the main code
• flat_image_list.kid template for the master index of this result set.
• one_image.kid template for one picture at one scale

I use it for simple albums that should grow as new things show up which match their keywords:

album = auto_album.album()
album.include_keywords("work", "whiteboard")
album.sizes(auto_album.origsize, (800,600))
album.title("Office Whiteboard Captures")
album.description("Whiteboards from meetings")

album.generate(os.path.expanduser("~/work/static/whiteboards/"))

EXIF

EXIF is a tagging format used on digital cameras to add metadata to JPEG files. EXIF.py is a nice package for dealing with the raw tags; my work is primarily using it to handle various picture-database operations.

Not that anyone is actually using this -- but you should go look at Kimdaba instead. If you do have data in bins fields, you might find capt_to_kimdaba useful, with a little personal tweaking...

For now, this is mostly interface tools that adapt my usage to what BINS expects. This includes a new "caption" markup, which is

• simple RFC822 tags in a .capt file associated with each image
• capt-to-bins which updates the BINS .xml files from the .capt files.
• bins.el which uses emacs21 as a captioning tool.
• pygimage.py which is a PyGame based captioning tool - stunningly fast paging through images, achieved by (1) cranking up the autorepeat rate (2) only painting the captions after a brief idle time. Compatible with bins.el, also uses .toenail (large thumbnail) files.