So instead I decided to write my own exporting tool, you can see the end result at http://photos.tyr.org.uk the default view is a match of the project/folder/album structure within my Aperture library and the ‘quilt’ view (see top right) is just for fun.  To export photos to the website I just tag them with the ‘Web’ keyword then run the export/sync script, it couldn’t be quicker and certainly much less hastle than maintaining two libraries.

Read on if you want to know more about how it was put together

The project consists of two parts. Firstly a method to get information out of Aperture and secondly some method of displaying the exported photos to the end user. I’ll cover the process I used to extract the metadata and images from Aperture in some detail in the hope it is useful to others wanting to achieve the same thing, the end user web front end is more specific to my requirements so I won’t go into it in so much depth but I’ll give some pointers to some tools used.

The functionaility I wanted to achieve with the export was to export all images tagged with a specific keyword and create metadata describing the folder/album structure and the image metadata. After much playing about with the inbuilt Aperture export tools I couldn’t find anything that would do this for me.

However all is not lost as Aperture uses a SQLite database to store it’s catalogue. Whilst it is not inteded to be accessed directly it is possible to open it up and take a look inside and figure out what is going on. However the layout of the database is not published publically not is it likelly to be stable between Aperture releases, in fact much of this code was originally written for Aperture 1.5 and had to be rewritten when 2.0 was released.

The first step to using the data in the database was to figure out what it all means. I used SQLite Database Browser to interrogate the database. The database itself is called ‘Library.apdb’ and can be found within your Aperture library, to browse into the library option-click on it and choose ‘Show Package Contents’. You can then open up the Library.apdb in the database browser.

I wrote the data extraction script in Perl, handily OS X ships with the appropriate SQLite libraries for Perl DBI so opening up the database is easy.

my $dbh = DBI->connect ( "dbi:SQLite:Library.apdb") || die "Cannot connect: $DBI::errstr";

All keywords in Aperture are identified by a UUID called a ZUUID, so the first step is to extract the ZUUID associated with the Keyword, eg

select ZUUID from ZRKKEYWORD where ZNAME = 'Web'

Photos in Aperture consist of a ‘Master’ image, each of which can have multiple ‘Versions’. We are interesting in extracting the versions that have the assocated keyword, we can find the UUID’s for these versions like this

select ZVERSIONUUID from ZRKXKEYWORDVERSION where ZKEYWORDUUID = '$keyZUUID'

Each of these versions will be extracted and published on the web site. We need to find out two pieces of information for each image, its location in the library and its individual metadata.

As part of this design we assume that all tagged images are part of an album, we’re not allowing for images that exist only in the top level of a project. We can find the albums a version is a member of like so

select ZALBUMUUID from ZRKWALBUMVERSION where ZVERSIONUUID = '$versionUUID'

Note that a version can belong in multiple albums. At this point we just build a list of albums and the ZVERSIONUUID’s of the versions each album.

The metadata for each version is stored in two places. The most significant data is stored in ZRKVERSION which contains one row per version, the less significant information such as EXIF data is stored in a huge table called  ZRKSEARCHABLEPROPERTY, this contains one row per property, as such it can contain 30 rows or so per version.

Firstly the information from ZRKVERSION is extracted

select ZVERSIONID, ZFILENAME, ZPROCESSEDWIDTH, ZPROCESSEDHEIGHT
from ZRKVERSION
where ZUUID = '$ZVERSIONUUID'

With this query we get the filename of the image and its processed width and height (so we can determine orientation) and als the ZVERSIONID, this is a different ID to the ZVERSIONUUID and we need the ZVERSIONID to extract the metadata for the image.

Now we can extract the bulk of the metadata for the image. This is held in ZRKSEARCHABLEPROPERTY and can be extracted like this

select ZPROPERTYIDENTIFIERUUID, ZVALUETYPE, ZPROPERTYSPECIFICNUMBER, ZPROPERTYSPECIFICSTRING
from ZRKSEARCHABLEPROPERTY
where ZVERSIONID = $ZVERSIONID"

Each property is either a string or a number, only one of ZPROPERTYSPECIFICSTRING and ZPROPERTYSPECIFICNUMBER contains a value, if ZVALUETYPE is ‘3′ then it’s a string otherwise it can be assume to be a number of some sort, floating point or integer.

The type of property is identified by it’s ZPROPERTYIDENTIFIERUUID. The data to convert this into a human redable property description is found in ZRKPROPERTYIDENTIFIER. To enable this to work efficiently I extracted all the data from this table into a lookup hash. eg

select ZPROPERTYKEY, ZUUID from ZRKPROPERTYIDENTIFIER

Where the ZUUID in ZRKPROPERTYIDENTIFIER matches the ZPROPERTYIDENTIFIERUUID in ZRKSEARCHABLEPROPERTY.

That completes the data extraction for the individual photos. The last thing to do is to extract the folder/album structure. For each album its name and its containting folder can be found like this

select ZFOLDERUUID, ZNAME from ZRKPERSISTENTALBUM where ZUUID = '$ZALBUMUUID'

Then for each folder its name and containing folder can be found from ZRKFOLDER like this

select Z_PK, ZNAME, ZPARENTFOLDERUUID from ZRKFOLDER where ZUUID = '$ZFOLDERUUID'

This data can be merged together to give you the full tree structure.

Now all the data had been gathered it’s just a matter of spitting out some XML. One file called library.xml contains the library structure, i.e. references  to all the folders/albums and photos. Then for each photos a ’sidecar’ xml file is created, this contains the exif and other metadata for the photo [example]. This ’sidecar’ is then loaded when the user displays the photo, this increases performance and reduces the amount of data required for an initial load of the library to just a skeleton.

Now we can extract the photo itself from Aperture. Since Aperture can resize images on export we’ll use that functionality to create an image that’s suitable for display to the end user. Aperture can be scripted using AppleScript so we take advantage of that functionality, this can be accessed from a shell call via ‘osascript’ for example

/usr/bin/osascript -e '
   tell application "Aperture"
       set exportFolder to "MacDrive:Users:username:Documents:WebExport"
       export {image version id "$imageUUID"} using "JPEG - Web - Display" to alias exportFolder
   end tell
'

It should be noted in the above that the value set for ‘exportFolder’ is the old Classic style of directory naming with colons rather than slashes.
You must create an export profile within Aperture with the name you use here, in this case ‘JPEG – Web – Display’.

Now we can rsync the images and the XML up to the server leaving just one final step and that is to create some thumbnails.

I wanted nice square thumbnails that didn’t change the aspect ratio of the image. Imagine the largest square you could create entirely within a full size photo then shrink that to a 50×50 thumbnail. This ImageMagick magic sorted it out. I don’t have ImageMagick on my Mac so this was run on the server that serves the images.

convert $sourceFile -thumbnail x200 -resize '200x< ' -resize 25% -gravity center -crop 50x50+0+0 +repage -quality 90 $destFile

And that completes the extraction and upload process. Finally we’ll take a quick look at the actual display side of things.

The idea behind the web design was to create something nice and simple that presented the photos in a non-fussy but easy to navigate way. I used the Yahoo User Interface Library (YUI) to build the interface. The main advantage in using this library is that it hides most of the browser incompatibilities out there, for example YAHOO.util.Connect.asyncRequest provides an AJAX function.

Particularly usefully you can assign a single ‘onclick’ hander to the folder browser div, then using  YAHOO.util.Event.getTarget you can find the object that was actually clicked. This makes it much more efficient than having onclick handlers all over the place.

The ‘quilt’ view does some simple fadein/fadeout animation. This was achieved using the YUI: Effects Widgets from davglass.com. This creates a nice affect as the imgaes are swapped in the quilt.

If you’re interested you can browse the javascript on the site; [main page], or [quilt].

I hope the above info was interesting or useful, post a comment if you’ve got any queries.