Thursday, August 20, 2009

Aperture: scripting takes you where automator doesn't

Like some unfortunate people, I've suffered from data loss. Mainly by distraction and a trigger-happy finger on the delete key. So I've embraced backup strategies, and my last acquisition was a Western Digital MyBook World Edition with 1TB hard disk inside. I keep it connected to my router, so it's always available from a wireless laptop in the house. I'm happy and comfortable with the setup, so the next step is, no surprise, figure out what I'm going to put there. And, most importantly, how I'm going to do that.


My first use case was my photography collection. I've recently started using Apple's Aperture to handle my pretty basic photography sets. I don't own a SLR, yet, but I have a Canon Powershot S50, which allows to manually configure the machine to take some interesting photos. And it shoots RAWs (albeit in a Canon proprietary CRW format, that can be batch-translated to DNG using the freeware converter from Adobe). So after my photo workflow I end up with an hierarchy with folders (for project types like "Trips and Events", "Experimentations", "Personal", "Work", etc), inside which i have projects.


What I wanted to achieve was a threefold backup: Save the project itself (so that i may open it in other aperture libraries, both on my macbook pro and my desktop mac); Save the masters, raw files; Save the versions, in JPEG. I figured I'd try Apple's little Marvin, the Automator, to help me easily do it. I got excited to see that there were some export actions available for use in workflows! That, however, proved to be insufficient, as there is no action to get the currently selected project. This was the first applescript i used on the workflow, to get just that, and place in a variable to pass on later. The code looks something like this:

tell application "Aperture"


-- identify currently selected image(s) project

set x to selection

set x to item 1 of x

tell library 1

set ap_proj to (get value of other tag "MasterProject" of x)

end tell

end tell

I was pleased with the result, as the MasterProject tag on the currently selected image would tell us the project id, not its name (like we would get if we selected from the entire project list on aperture). But then i found out two drawbacks:There's no way to export a project bundle directly via an action. There's also no way to get the project name to pass as input to the export versions/masters actions, as they require a list of images. So after a visit to the Aperture dictionary on Script Editor (just open the application with it, and browse around), i found out i could export a project bundle via applescript (great), and produce a list of the images in it (also great). But not everything is that easy, as I found out that not only the Export actions don't like to accept input from a "run applescript" action (they require a variable to be set and then got, for them to receive data flow), but when the script is saved (or exported to a plugin), the flow is broken and the export actions cease to work!

I ended up giving up the entire workflow, and scripted the whole thing. I only kept the automator workflow file so that i could easily add stuff like growl warnings. You can download it from here and give it a try. Oh, and if you know an easy way to find out the folder a project is in, to put the bundle in that directory, please, leave a comment or tweet me!
With this script (with a small adaptation) it's also easy for me to loop through all projects and perform a complete backup of the library. This sure beats the workflow-actions way, as there's no amount of variables and loops that can make you run through a list of projects. For these reasons, I believe Automator needs a 3.0 update. Maybe Marvin could take some anti-depressives, and leave the paranoia behind? :)

blog comments powered by Disqus