2 posts tagged “photos”

As I've already said, I've moved a bunch of my old photos across to Flickr. I've also picked off another of the scripting chores mentioned there: I went back to the files on disk, looked up the ordering, and applied it within the sets. I've also ordered the sets by reverse date, and I have a bunch of handy .flickr files so that I can find the ID on Flickr given just the filename on husk.org.

You'd think I'd be done, but my quest for perfect organisation (which will be apparent to anyone who's seen my music collection's metadata- although I have to admit there are niggling holes there too) means that I have further problems.

Replicating heirarchy: sets vs tags

On stem, my old photo album, there was a heirarchy of directories, although I didn't really use it that much. Mainly, sets fell into five categories: "trips", "walks/wanders", "walks/crisps", "people" and "random".

Flickr doesn't (yet?) have a feature that allows you to put sets into other sets, so I can see three ways of retaining this information:

• set titles - at the moment things are called eg "Trips - New York"
• multiple sets - add all photos that were in Trips to a huge "Trips" set, so that the heirarchy is visible in what Flickr calls "context"
• tags - as well as my existing "stem" tag, use a psuedo-triple* like "stem:random"

I think I'm probably going to use the latter, since it feels most Flickr-y, but it does mean I'm going to have to do a bit more scripting to apply the tag across.

Re-uploading

In my previous post I mentioned that a lot of my photos are overcompressed. They also generally have had the EXIF stripped (because I edited them using Photoshop 5.5 - how retro).

In theory, finding the photos which do have EXIF is straightforward- find the photo (using the .flickr files above, that's easy), find its date, and then find it either on the filesystem (reasonably easy) or with iPhoto (which is proving annoyingly hard**). This is also useful for photos I've uploaded in the last year- I don't always have a record of which local file I uploaded to Flickr, and I may want to replace images with their full-res version at some point for printing.

However, for those with no EXIF data, the problem is much harder. One sensible thing I did with stem was to put the date in every folder name, and I've copied this across to Flickr's photo date properties, but it only gives me day resolution. This means that I may have 40 photos on Flickr, and another 400 at home, and have to find the smaller set in the larger. Even worse, the photos on Flickr may be cropped or colour-corrected (again, in Photoshop).

I suspect the only solution is to take the local files, and the original iPhoto images for that day, and use a script based on something like Image::Seek, a Perl library based on imgSeek, to try and find similarites and save me doing so. I haven't really started poking at code, though, so this might all fail horribly. We'll see.

Organising ... and is it worth it?

Finally, there's tidying up the photos before publication; fixing titles (which were previously limited in both length and by what's sensible in filenames), maybe adding descriptions, and definitely adding tags

However, by this point I'm wondering if it's even worth going through all this faff. Is it worth bothering will all this coding and organising? Already, just with day resolution and the old title metadata, I'm finding it easy to look for images. Perhaps I should just call it a day, make everything public, and change my attention to another app - sourcing stem from Flickr.

If anybody has any thoughts, though, I'd love to hear them.

* Inspired, I think, by the geotaggers, I use tags like "lens:50mm" rather than the (much) more common pair of "lenstagged canonef50f1.8". I'm well aware that Flickr doesn't really do anything useful with the colon to turn them into real triples, but I still think I might do some time, and if pressed I'll argue that the tags are for my use, not yours, so I stick with them. If I ever really care I'll batch change them.

** Unfortunately I've come to expect that from scriptable applications. In theory iPhoto (and iTunes) should be able to be fast object databases, queryable on anything you like, including date, name, artist and so on. In practice, sadly, they're not; the timeouts I was getting from iPhoto last night either mean I'm doing something horribly wrong or that it's doing linear searches for date properties. Oh well. I must admit this is a niche activity.

Hilton Hotel, Park Lane, London

I finally did something that I've been thinking about for months: migrating all the photos from my homebrew photo gallery into Flickr. As a result, instead of the usual 100-so uploads, this month I've managed 3000 (although you can't see them; they're all private*).

Of course, given this was a one-shot script, I managed to make a few mistakes. I haven't preserved the order of the images, or the sets, and I don't have a handy lookup table, so I can't yet do anything clever like serve the HTML on my own site but the pages from Flickr (or, for that matter, set up redirects; I care about old URLs working, especially because Google seems to like my site enough that I get the odd referrer).

Still, it's nice to have got a small bit of integration out of the way, although, like Tom I still have a bit of tension between signing my life over to other people and handling it myself.

* I'm not entirely sure why, though. After all, they're all visible on my site. Perhaps it's because I want to make sure I don't suddenly flood anyone's RSS feed, and that's best achieved - according to Phil Gyford, anyway - by uploading some other photos after the import. There's also the issue that the images have little metadata, and I'd like to add some tags. Even more time-consumingly, I'm thinking of replacing the old images, which have been resized down from the originals and have no EXIF. I think those are good reasons. I'm not sure though.