Aperture Users Network

I spent some time today catching up on some Lightroom reading. I have to admit, I don’t spend a whole lot of time reading the various Lightorom blogs, but I do like to browse for the highlights every once in a while. Usually I will find a new trick that might apply to my Aperture based workflow, and on occasion I see something that LR photographers are doing that is just really cool.

But this time I was a little shocked to see an article by the LR Project Manager himself, Tom Hogarty. Tom has written a post on his Lightroom Journal blog entitled “Plug-In or External Editor?” The post, which begins as a pretty benign, and interesting discussion about some of Adobe’s concepts regarding plugins, turns into a downright “slam” of Apple’s new plugin SDK which recently added Edit plugins to the fray.

Hogarty’s main point is that an Aperture Edit Plugin is nothing more than Lightroom’s external editor functionality. This couldn’t be further from the truth. He goes on to claim that it is a bear on developers to have to rewrite their applications to work within the Aperture SDK, and that in many cases it is simply easier to export your image to Photoshop.

I read through the comments on the post and was just sort of taken aback. Next, I decided to peruse the “Google” to see if anyone else had written anything having to do with this post. To my somewhat mild surprise, Adobe’s very own John Nack had written up a summary on his own blog! Nack makes a number of bullet points including one that I just couldn’t believe: “Pound for pound & click for click, "external editor presets" in Lightroom 2 and "plug-ins" in Aperture are the same thing.”

First, let me just say there is nothing that drives me more insane these days than an Aperture vs. Lightroom discussion. However, once in a while, it just can’t be avoided. I have written on this subject plenty of times in the past, and every time I say the words “ I don’t want this to turn into another Aperture vs. Lightroom battle,” it does anyway.

Second, I have the utmost respect for the Adobe Lightroom team. I think LR 2.0 is an amazing leap forward and it is a really powerful product. I still prefer Aperture, for many reasons that I won’t get into at the moment, but LR 2.0 is definitely just as cutting edge as Aperture is when it comes to this whole new way of dealing with digital files. Just have a look at David’s article about what the pros are using at the Olympics this year. It pains me to hear of people opening up dozens of images at a time in Photoshop, making edits, saving as Jpeg and shipping them out. I used to do that, when I didn’t know any better.

That said, I think what Hogarty and Nack are saying here is a little outlandish. Some of their “blanket” remarks are simply untrue and not backed up with any supporting evidence or information.

Hogarty writes, “When photographers think of plug-ins it typically brings to mind very unique or specific filters designed to adjust the appearance of an image.”

This is the second sentence in his post, and I couldn't agree less. I am a photographer, and when I think of plug-ins, I think of the native app exposing some of its infrastructure so that third party apps can take advantage of what is already there.

For example, Nik Software’s Viveza and Picture Code’s recently released Noise Ninja are both Edit plugins for Aperture that take advantage of the fact that within the Aperture SDK a third party plugin can write data back into the Aperture database. This can become incredibly useful later if for example, you need to do a search for images that you have already processed through Noise Ninja. The ability for developers to have access to this wealth of metadata creates an extremely tightly integrated environment between Aperture and the plugin.

This type of functionality has existed in the Aperture SDK since it was first released for Export plugins. One great example of its use is in Connected Flow’s FlickrExport. This plugin writes the flickr ID tag and URL to the images metadata using a custom metadata field in Aperture. I have personally found this very useful in my own work as a blogger whenever I want to post an image that I may have already uploaded to flickr. Instead of searching through my pictures via the flickr website I can simply look through my Aperture database and find the image with its corresponding flickr URL.

So what else can the Aperture SDK do that a simple round trip to an external editor cannot?

Access To Metadata -- In addition to accessing existing metadata the Aperture SDK can write back to the Aperture database, inserting keywords or custom metadata fields into an image’s metadata. A number of plugins are already doing this, giving users the option to add a custom keyword such as “edited” once their images have been processed by the plugin

Batch processing -- This is built into the plug-in API and allows a series of processes/adjustments/filters to be applied to an entire batch of selected images at once. This simply is not the way external editors work. As we all know batch processing is a big deal when it comes to workflow, and the Aperture SDK has embraced this concept. So much for “click for click.”

RAW Processing -- The Aperture SDK can pass the actual RAW data to the plugin. This means that the third party developer can apply any RAW processing that they can dream up. There is no need for Aperture to create a rendered TIFF or PSD document before doing this. Of course the SDK can render a TIFF or PSD on its own but this behavior is left entirely up to the developer.

Control Over Aperture Objects - The Aperture SDK allows developers to do things like group images in Stacks, delete Versions, and much much more. This allows third party plugins to really manipulate the Aperture library, opening up a myriad of possibilities.

Hogarty continues, “In Lightroom 2 we've added the ability to define as many external editors as you want.*And you don't have to wait for software manufactures to create a custom "plug-in" for Lightroom, just utilize the existing standalone application like the one available for Noise Ninja.”

Yes it’s true, a third party developer must create a custom plugin for their software to work within Aperture, and yes, this does involve some extra development time, but none of these additional features would be possible without this requirement.

That said, in my dealings with plugin developers, and due to Apple’s use of a Cocoa based SDK it seems that software companies are turning out their plugins very quickly. Not only is the development time very reasonable, but the language is the same, and because its all Cocoa based, developers can take advantage of everything the Mac platform has to offer. This includes all sorts of pre-built image processing libraries like Core Image, the image processing routines found in Python and much, much more. A developer starting from scratch can build something very rapidly using these existing frameworks.

Hogarty concludes, “This is an incredibly powerful link between the raw and rendered workflow and half measures with marketing spin labeled as "plug-ins" are not the highest priority for the Lightroom team.”

This is the one that really got me. Why would one of the two companies on the leading edge in digital imaging, decide to make something as powerful and useful to their users as extending the functionality of their application “not the highest priority?” I don’t think Apple is trying to put “spin” on their marketing to make their users believe that these plug-ins are something that they are not. They work as advertised, and they add a wealth of options and extensibility to an already very rich and thorough application.

Photographers want “best of the breed” technology in their Aperture workflow. Plug-ins make this possible immediately. Perhaps Apple may add non-destructive plug-ins in the future, but whether they do or not, the point is: photographers have been exporting images from LR or Aperture in order to use things like Noise Ninja, and Apple's plug-ins have made these steps easier and smarter.