Aperture Assistant and Aperture 3 - The Good, the Bad and the Mildly Ugly

Sun, 2 May, 2010

Aperture Assistant - the Good the Bad and the Mildly Ugly

Aperture 3 has now been out for several months, but Aperture Assistant doesn’t work with it - by design. There are a number of reasons for this, but it’s not going to stay that way...

The Bad

I’ll start with the bad news. The first bit of bad news is that until two weeks ago I’ve not had time to look at updating Aperture Assistant to work with Aperture 3.

The rest of the bad news is how to get information out of Aperture - there are several different ways to do this:

One is AppleScript, Apple’s scripting language, which Aperture supports quite well. Another is to make an app that works ‘within’ Aperture by building an editing or export plugin and making calls to Aperture through the plug-in framework.
A third is to read information directly from the SQLite3 databases that Aperture uses for day to day storage of information.

Aperture Assistant uses a mix of AppleScript and SQLite calls to get information, with AppleScript to then pass information back. Technically it would be possible to write directly to the database but this would be a great way to mess up the Library as the information wouldn’t propagate out to the XML files that Aperture also uses - rebuild the Library and all those changes would be lost.

Aperture 3 locks all those databases whenever it is running, making them unreadable to other apps. OK, you say, why don’t you go back to using AppleScript to retrieve all the information that ApAssist requires? Well, it’s roughly a hundred times slower and a lot of the information that ApAssist requires isn’t actually available via AppleScript - things like the location of Previews and Thumbnails, file sizes of all the Master files (needed for duplicate searches etc.), Master locations (needed for Burn Folder creation for Masters) and a few other things.

At this point, Ap Assist was dead in the water - any version I made would have to drop major export and duplicate search features and would be quite slow in comparison. Oh dear. A rewrite in Cocoa as a plug-in would be a fix for the speed (albeit with the delay of learning a new language and development environment), but still wouldn’t get me some of the required information.

The Good

Aperture 3.0.3 no longer locks the databases when running. Huzzah!

This means that I can now get Aperture Assistant working with Aperture 3 in a cost-effective manner.

Beyond an upgrade actually being feasible again, Aperture 3 adds quite a lot of potential new ideas for Aperture Assistant:

Presets can be applied via scripting - that could mean an ApAssist workflow where you use decision nodes to choose what preset to apply, for instance different amounts of vignetting depending on the lens and aperture settings.

Aperture uses three sizes of thumbnail internally, changes to the way the smaller sizes are stored means that ApAssist should be able to access them for exporting.

The move from exported Projects to exported Libraries mean that every exported Library contains the relevant databases for the included images - a limited number of ApAssist features could work directly with a Library without Aperture being on the machine, for example exporting Thumbnails or metadata. Potentially it would be possible to write a Library viewer similar to Marc Rothkind’s LRViewer.

Another good thing - the internal layout of the databases has been improved in Aperture 3, often taking 2-3 fewer calls to get a specific bit of information.

The Mildly Ugly

The internal databases have been split up into several separate databases with new layouts. Yes, I know I just said that was one of the good things, but it also means development time working out the new layouts.

Aperture’s internal organisation has gone fully virtual - in Aperture 1, 1.5 and 2, the structure Projects, Folders and Albums in the Projects pane was replicated within the Aperture Library as Project packages, Finder folders and XML files, making it quite easy to work out the structure programatically. Now, all types of container within Aperture are stored at roughly the same level in the Finder - working out the organisational structure will require pulling all the parent-child relationships from the database and recreating the structure appropriately.

Time, of course, is the ugly bit - rewriting ApAssist to fully support Aperture 3 will take some time.

The initial plan is to put out a version that works for exports and for metadata-based work which will be a free update for all current users. What won’t be included in this version will be duplicate searches or the ability to pick containers - all workflows will have to work from the currently-selected images in Aperture.

Once this stop-gap version is available, work will start on ApAssist 3 (yes, I’m bypassing version 2 entirely) which is where the fun begins. There are a whole bunch of ideas I have for improving the user experience for ApAssist, it’s integration with Aperture and a few new features while hopefully avoiding feature-creep.

Interesting times ahead...