Tumblr repost

For some reason a photo I posted to Flickr a few years ago has been reposted like crazy on Tumblr.

I only found out via the stats after a few people faved it on Flickr.

Interestingly, it’s been on Flickr for four years and in that time received 29 favo(u)rites.

Once it was posted to Tumblr It managed 336 likes/reblogs in about a week (not sure how I can check that timespan but it was certainly pretty short).

More grist to the mill for the “Flickr is dying” meme (or I’m just not very popular on Flickr).

Automatically adding photos to Flickr photosets

I’m quite lazy when it comes to organising my photos into photosets on Flickr.

The whole process has always been a bit too manual for my liking.

It’s been on my todo list to find a way of automating it so this weekend I tried to do just that.

My thinking was to somehow link my photosets to the tags I already use for my photos. These are set when I upload from my photo database (photodb).

I know Flickr Set Manager already does this but I wanted something integrated into my photo database.

I’d already decided I didn’t want to store details of the photosets in my database as it would be a maintenance pain if I removed a set.

Plus I’d need to write some code and web pages for managing it all.

As I was pondering alternatives I had the idea to add some metadata to a photoset description on Flickr then parse and match on that in my app.

Cluttering up my set description with such metadata was a little messy but as you can’t add tags to sets it seemed the simplest way.

The basic plan then was to load all my photosets from Flickr when I chose to upload a photo.

Then parse the set descriptions for my metadata and match that against my photo’s tags.

This would then pre-select those sets in a multi-choice select box displayed on my upload page.

I could then de-select any incorrect choices and choose additional sets too.

Once I had knocked together a little prototype it occurred to me that as I store lots of other metadata about my photos I could automatically add to sets based on all sorts of criteria.

So I set about feeding location data, camera and film information into it too.

The really nice part about this solution is that if I want to create a new set based on a particular location or new camera I just need to add an entry into the set description and it all “just works”.

I mentioned above my plan to use a multiple choice select box – I forgot to mention how much I hate them though. Luckily for me I’m not the only one who hates them.

This article talks about various alternatives – the best one for me being the jquery-asmselect plugin which provides a clean and elegant solution to the problem.

Of course; all this only works for newly added photos. What about the 2000+ photos I already have on Flickr?

I need some sort of batch process to re-organise my existing photos.

Fortunately I’ve already written something similar for tagging photos which I can re-use.

Finally, here’s how it looks on screen.



If you click through to the photo on Flickr you’ll see notes I’ve added to explain things in more detail.

Machine tags on Flickr

A friend recently alerted me to this post about machine tagging for film photos.

He suggested I might want to add similar tagging to FilmDev.

I did want to add machine tags to FilmDev (other than the obvious one it uses to link recipes to photos), but I was more interested in adding them to my own Flickr photos.

Because I always add my photos via the photo database webapp that I developed (photodb) it makes it fairly easy for me to add any style of machine tags I want to my photos.

Also, because I always store the Flickr photo id after uploading it makes it easy to re-tag all my existing Flickr photos too.

So I set about implementing it.

Using the really useful flickr machine tag browser (by Paul Mison) I was able to quickly determine the most sensible tags to add to my photos.

I have a mixture of film and digital photos on Flickr so had to come up with tags for both types of photos.

I ended up with this for digital photos:


camera:model=Canon EOS 20D
lens:make=Canon
lens:model=Canon17-85f/4.0-5.6
photodb:id=8429

I didn’t bother with tags for apertures and shutter speeds (even though I hold that information in photodb) as it seemed overkill for my uses.

I’ll come back to the photodb:id tag shortly.

For film photos I have something like:


camera:model=Olympus XA3
film:brand=Agfa
film:name=Agfa Vista 100
film:iso=100
film:format=35mm
photodb:id=15303

I don’t necessarily know what lens I used for a particular photo so I don’t record that and many of my film cameras don’t have interchangeable lenses anyway.

As I mentioned above I hold the Flickr photo id in photodb whenever I upload a photo so I am theoretically able to re-tag all my photos.

To do this I wrote the back-end code to set tags on a photo (photodb is written in Java) then hooked up an Ajax action to it.

I dug around for something I could use to show me the status of my re-tagging action (I had about 1700 photos to tag) and found JQuery PeriodicalUpdater so I wired that up to give me a countdown.

The last thing to mention is the photodb:id machine tag – predictably enough it refers to the id of the photo in photodb.

I hacked together a quick greasemonkey script to check for this tag and generate a link to that photo in photodb.

This makes it super-easy to link between the two websites (the ability to do that has been on my todo list for ages).

Oh yeah, as to the request to add them to FilmDev that prompted all this, I am still working on that (along with a bunch of other features).

Unlike photodb, real people use FilmDev so I can’t just hack together any old crap. 🙂

Sidebar feeds

I did a minor blog re-design the other day.

Some cosmetic font tweaks and removal of a lot of the sidebar content.

I also added a left-hand sidebar (previously there was only one on the right).

This makes the content easier to read as the middle column is narrower and it also gives me an excuse to pull in content from Flickr and Twitter for the new sidebar.

Both Flickr and Twitter offer “badges” which give you a bunch of HTML and Javascript to put on your site and they then pull content in automatically.

They’re great but have one fundamental flaw – if Flickr or Twitter are down then they don’t work.

So, I’ve decided to adopt a more robust approach.

I’ve been pulling in links from my del.icio.us account to make a linkblog for a while so will follow a similar approach for Flickr and Twitter.

This post explains the theory behind it – the only new thing was the XSL stylesheets I used.

The Flickr stylesheet is fairly straightforward, it uses some CSS styles (below) to display the photos in two columns.


.right-box-img
{
float: left;
}
.right-box-clear
{
clear: both;
}

The Twitter stylesheet is a little more complex.

It automatically filters out Twitter replies and strips the username from the text also.

Anyway, feel free to grab them for your own usage – leave feedback about them in the comments below.

Programmer’s Diary (part four)

For my app, I had planned to cache some data from the Flickr API in a database (hence the need for Hibernate).

But I was eager to do a “proof of concept” thing and make sure everything I wanted to do could be done before I wrapped my head around Hibernate.

So I’ve decided to compromise by caching stuff in the session for now.

I had to tweak more Flickrj code to make sure everything I wanted to store in the session implemented Serializable though.

So, having got Flickrj working, and stuff cached in the session to ease the load on the Flickr API I started writing the interesting code that actually does stuff.

This part took less time than all the other fiddling around (always the way) so after only a few hours I had a simple prototype app that pretty much proved the concept.

There’s no design or look and feel work yet, just black text on a white background and no navigation other than a link to the home page.

So, it needs a bit of tarting up.

But it works, which is kind of fundamental really.

Next steps are to test everything and do some look and feel work.

At some point I’ll even send it live.

Programmer’s Diary (part three)

Robustification*

I want to ensure the app is pretty robust.

By which I mean that it shouldn’t crash (much).

This obviously involves writing proper code.

It also involves dealing with user input and the Flickr API in a sensible manner.

It’s reasonable to state that no user input should cause the app to crash.

To achieve this aim I will be treating all user input with extreme prejudice.

By user input I don’t just mean forms on the site.

I also mean any form of “URL hacking” too.

I also need to look at all the possible error conditions that the Flickr API can throw at me and deal with them gracefully.

Errors from Flickr will either be network errors (come back later when it’s better), invalid XML (will need to be investigated to see if I can work around it) or one of its published error codes (should be the easiest to deal with).

* Robustify is a word some shit contractor used in a CVS commit message after I slagged off his toString method.

I think it’s an awful word so therefore I enjoy using it in an ironic manner.

And now, for some gratuitous photos.

Empty shop
Empty shop
Candy Chinatown style
Candy Chinatown style

Programmer’s Diary (part two)

So, as discussed previously I’ll be coding against the Flickr API.

I’ve done this before and back then I wrote my own code to do it.

This was fair enough, I was only calling about 4 API methods.

But as I’ll be making a lot more use of the API this time I’m going to use Flickrj instead.

Flickrj is simply a Java wrapper around the Flickr API.

It seems to cover all the stuff that I want to do so no point writing my own interface.

The first thing that I usually do when using any new Java library is to get a copy of the Javadocs onto my local Web server and get a copy of the source code onto my machine.

I then set up Vim and ctags so that I can browse and jump to the source code from within Vim (sorta like an IDE, only not as good).

Having done that I started getting to grips with Flickrj.

Unfortunately the first thing I needed to do was to authenticate against Flickr.

Flickr’s authentication system is complicated but it’s also clever. A person can authenticate against Flickr via my site without providing me with any details about themselves. Clever.

It also works in slightly different ways depending on what type of app you are writing, Web, mobile or desktop.

Flickrj didn’t seem to be set up for Web authentication and I’m writing a Web app.

Time to start hacking on the Flickrj source code.

I moved the source for Flickrj into my project so it sat alongside my own – this way I could compile once and pick up any changes to both sets of code.

Once I had done this and added the method that I needed I got it to authenticate.

I then found a number of minor bugs in Flickrj, so I had to fix them too.

I then emailed the lead developer to ask if he wanted me to send him some patches, but I haven’t had a reply yet.

Right, that’s enough for now, next time I’ll talk about “robustifying” my app.

To go on with though, here are some random photos that I’ve taken in London these last few weeks.

Covent Garden
Covent Garden
Lunchtime photography wander (2)
Lunchtime photography wander (2)
Millenium Silhouettes
Millenium Silhouettes
Sunset throught the trees
Sunset throught the trees

Programmer’s Diary (part one)

I’m going to keep a programmer’s diary for my next project.

It’s a Web app that will use the Flickr API.

I’m not going to say what it does yet, but I’ll post my progress here.

I’ve decided to do it in Java as that’s what I know.

I’m too impatient to start learning something like Ruby or Python now, I want to crack on and get coding.

I will try to learn something new though and that will be Hibernate.

Previously I’ve used a basic system for database access; code generation using XSLT and a thin layer for caching frequently accessed data. It’s OK but a bit clunky and restrictive.

For the rest I’ll carry on with the current Web framework that I’ve been using for a few years (an “in-house” one).

I also feel that I should have a crack at using Eclipse as an IDE.

I’m not really an IDE person (I normally use Vim) but I suppose I should at least see what I am missing out on (I used it briefly at work, it’s a bit of a monster but having a debugger is nice).

Next time I’ll talk about coding against the Flickr API.

City Hall photographers

City Hall was open to the public on the weekend so I went along on Saturday.

Whilst there I saw many people with cameras so kept my eye out for any fellow Flickr people.

I didn’t see anyone from Flickr, but did bump into one of my friends from work.

Today though a friend sent me a link to a photo on Flickr.

Someone who I had never met had taken a photo of me and posted it to Flickr.



Cool Flickr coincidence.

And here are the photos that I took.

My digital workflow

I was listening to the Tips from the Top Floor podcast and there was an interview with Randal L. Schwartz (of Learning Perl fame) and he was talking about his digital workflow.

Randal is of course a geek, so his digital workflow is typically geeky, lots of custom scripts and use of Unix tools to automate stuff etc.

After he’d described it all I realised that my workflow was quite geeky too.

So I thought I’d describe it here for fun.

It can be broken down into 4 stages.

Transferring photos, post production, Web processing and Flickr interface.

Also, some of it is done on Linux, some on Windows and some on the Web.

Stage 1: Transferring photos (Linux).

I use a Canon EOS 20D which in turn uses Compact Flash. To get photos onto my camera I have a short script that copies files from a compact flash card reader onto the PC. The only interesting thing that it does is to create date-stamped directories and store photos according to the date of their timestamp.

It also simplifies an otherwise fiddly task.

Stage 2: Post production (Windows).

Once all the photos are copied across, I can access them from Windows via a samba share.

As I shoot RAW, the first step is to convert them into a universal format.

For this I use Capture One.

I quickly go through the images, deleting any that are obvious rubbish.

I tend to keep the majority of what I shoot though.

Then I run through in more detail and fix any exposure and white balance issues. Capture One makes this very simple and allows me to do stuff in batch mode too.

Lastly I convert them all to TIFF format.

For any that I want to do some further work on I open the TIFF in Photoshop and do some additional work there.

Stage 3: Web processing (Linux).

I then process the images for displaying on the Web.

Firstly I use an app called Exiftool that generates thumbnails from the RAW files.

The reason I do this is that Exiftool maintains all the Exif data from the images – (Capture One loses any Canon-specific tags).

The next step involves a perl script that creates 3 JPEGs for each image (small, medium and large) then copies the files to this Web server.

Once the files uploaded I can then import them into my Photo database (a custom Web app written in Java).

First it display the thumbnails on screen where I can set location info and add any tags or titles to the photos.

Next it imports the photo information (made up of the Exif data and file sizes) into the database.

Stage 4: Flickr interface (Web).

The final (optional) step is uploading photos to Flickr.

As Flickr provides a comprehensive API it’s straightforward to code my app to upload photos to it.

I decided against using flickrj as it was more fun to roll my own code and learn the Flickr API.

The API also lets me set the tags, title and description that will be used on Flickr.

One of the nice things about doing it this way is that I can read some of the Exif data and set it as tags on Flickr. Stuff like the camera and lens used and location information is all picked up from my database and automatically added to my Flickr tags when I upload.

So all I do is view a photo in the Web app then click “Upload to Flickr”.

It appears in my Flickr photostream a few seconds later.

So, there it is; convoluted, idiosyncratic, geeky in the extreme and probably only of interest to me.

Enjoy!

Couple in Richmond Park
Couple in Richmond Park
Winter Walk in Richmond Park
Winter Walk in Richmond Park
Tree in Richmond Park
Tree in Richmond Park
Richmond Park
Richmond Park