Using Acquia Drupal as an image processor?

pipeline_in_trench.jpgCatching up on some blog reading today I picked up on a thread Dave Winer's been writing about. He's using ImageMagick to resize images and produce thumbnails. Throughout the thread I kept thinking this sounds a lot like a standalone version of the Drupal imagecache module. Perhaps, I thought, the answer could be setting up a Drupal site to do the conversion. Nah that's too much I said to myself.

However, the more I thought about it the more sense it made. Then I got to today's post where Winer mentions a small web server for doing the work. "I'm still bugged that: 1. It seems slower than it should be. 2. A window flashes every time it creates a thumbnail," Winer says in the post. OK this is the prefect situation for building a one-off clone of imagecache. The next paragraph says, however, that he doesn't want to build it in PHP as it's another language to pick up.

While heating up some naan for my lunch the plan came together. Build a small website using Acquia Drupal and have imagecache do the work for you. The beauty of the solution is that it doesn't take learning PHP. It is a PHP-based solution of course, but one with no coding necessary. So why use Acquia Drupal specifically? It has a couple of advantages in having the necessary modules already bundled with it. The modules are all available on but for somebody who hasn't setup a Drupal site before having them all together is handy. There's also a good Getting Started guide that makes it easy for users to get a site setup.

imagecache-options.pngIsn't there a lot of overhead in setting up Drupal to just be an image processor? Well maybe but it's not as much as one might think and it has some other advantages. So there is the overhead of installing Drupal and having Apache configured to work with it. Until Drupal 7 brings SQLite support there is also the need to have MySQL setup as a database even though it's not going to be used for very much. On the upside there is the ability to have a system that is run primarily from a web interface. With the imagecache administrative interface it would be trivial to decide to add a second or third size of image to each of the images in the directory. Should one want to have both a square and a rectangular version of each image that's not hard at all. Because of the way imagecache handles the files Drupal is only involved in processing each image once. After that it's simply Apache (or whichever webserver) passing out the file.

There are also some advantages to this model when it comes to scaling. It would be easy to setup on an EC2 instance, for example, that runs only part of the day. Or having it on the local desktop to absorb some extra cycles overnight would be simple. And the directories, both for input and the resized images could readily be used by any client anywhere. Having some other system add and view images would be simple since it is just a matter of knowing the file name. Of course if one wanted to go further and have Drupal itself generate RSS feeds of the pictures, galleries, etc. that would be a pretty simple task as well.



Limited to defined presets

Does imagecache still require you to define the presets in advance? For resizing and cropping, couldn't it be opened up to be completely RESTful? If you could serialize all the preset parameters as GET parameters you could custom order all of the rotations, crops, resizes etc. just by manipulating the URL. That would be cool!

lets crack it

and its not even hard to do, just implement a service for the services module that provides an imagecache toolkit. i was talking to dopry about it in April when I was in Koeln, i think i'll give it a shot next week.

That would be cool

Yes it does but you're right that would be very cool and shouldn't be too hard to do and make it RESTful.