Framed and Exposed: Better Image Automation Through Scripting
Windows users, please bear with me this week while I discuss a Mac-only technology.
Whether you run a complex Web or print production workflow, or you’re a professional photographer who needs to manage 1,000-image shoots, or you’re a hobbyist photographer drowning in media, workflow automation can be an essential concern for achieving your end goal — whether it be a Web site, magazine, or simple high-quality print. Digital photography workflow and workflow automation will be a subject that we will return to repeatedly in this column, but this week we’re looking at the digital photography applications of the AppleScript language that’s built into the Mac OS and, specifically, the image processing routines that are built into OS X 10.3.
AppleScript was introduced with version 7 of the OS, way back in the early ’90s, and Apple wisely migrated the technology to OS X. AppleScript is a scripting language with all of the elements and structures that you would expect of a modern programming language. There’s nothing particularly special about AppleScript as a programming language — in fact, there are a lot of things about AppleScript that are really annoying. What makes AppleScript so useful and powerful are Apple Events — messages and commands that can be sent from application to application, and which you can control through the use of AppleScript.
An application must have Apple Events support built-in before you can control it with Applescript, but these days almost all major graphics and design applications are scriptable, as are the Macintosh OS and Finder.
A quick summary for those of you who’ve never fiddled with AppleScript before: AppleScript is part of the standard OS installation and so is available on any Mac. In your Applications > AppleScript folder you’ll find a copy of ScriptEditor, a simple application for writing and compiling scripts.
In addition to saving simple scripts that can be run from a script editing application like ScriptEditor, AppleScript allows you to create standalone, double-clickable applications, droplet applications, or scripts that can be attached to folders or other applications.
The AppleScript language itself is somewhat similar to Apple’s old HyperTalk language (the native language of HyperCard) and follows a similar English-like syntax. This is both a blessing and a hindrance. Its English-like feel is less intimidating to beginning scripters, but the vagaries of English grammar — as well as the existence of so many synonymous terms — means it can be difficult to remember the precise AppleScript syntax that you need for a particular command.
Here’s a sample AppleScript script that shows a typical automation routine. This script (called PhotoRenamer, which you can download from my Web site) creates a droplet, an application that processes any files dropped on top of it. Digital cameras, of course, produce files with rather useless, meaningless names. When you drop a folder on top of this droplet, it builds a new filename for each file inside. The resulting files will be named <foldername> <date the file was created>_<a sequential number>.<the file’s original extension>.
The script itself is fairly simple. It first checks to make sure that what was dropped was a folder. If it was, the script then collects a list of the contents of the folder into a variable called theFiles. The Repeat loop cycles through all of the items in that list. By examining the info for each file, the script is able to extract the date the file was created, convert it into a filename-friendly format, and then assemble the variable newName from the folder name, date, and a stepping variable called fileCounter. Finally, the file is renamed.
As you can see, AppleScript includes a lot of built-in functions that make this sort of operation very simple. It’s good at handling lists of objects, can easily gather up info for the types of objects you tend to want to manipulate, and can speak directly to applications to manipulate their unique data types and structures.
Obviously, a detailed AppleScript tutorial is way beyond the scope of this article. However, with AppleScript’s easy readability, you should be able to determine if the concepts we’re going to discuss here might be of use in your workflow. (If you want to know more about Applescript, you can read online tutorials here and here.)
Image Events with Photoshop
Adobe Photoshop is fully AppleScriptable, which means you can automate almost all of your Photoshop operations. However, for simple tasks — resizing, changing image formats, cropping — it can be a somewhat slow process, as AppleScript must launch Photoshop. To facilitate speedier automation, Apple built a suite of graphics processing routines into OS X 10.3. These routines are contained in an application called Image Events, which has no interface of its own; it can only be controlled via AppleScript.
Image Events has some important implications for workflow automation. First, using it is much quicker than using a full-blown app, so your automation scripts perform much faster. Second, because it’s free you can set up an automation workstation without having to pay for another license of Photoshop. Thanks to AppleScript and Image Events, any inexpensive iMac can serve as a preflighting station, or graphics munger.
Obviously, Image Events’ feature set is far smaller than what you would find in Adobe Photoshop or another scriptable graphics app, however, it does provide most of the basic components that you need to create useful graphics automations.
This droplet (called Picture Munger, which can be downloaded here) provides an overview of all of the commands supplied by Image Events. Drag and drop any number of image files onto the application, and you can batch process them according to the specs you configure in the program’s main dialog box (see Figure 1). (Sorry, this version won’t process folders. You have to drop image files.)
Figure 1: The Picture Munger application provides a simple overview of the graphics processing routines included in Image Events.
As you can see, Image Events provides the following graphics processing operations:
- Rotate (Image Events can actually rotate by any degree. For the sake of simplicity, I limited this app’s rotate feature to 90° increments.)
- Pad, which pads an image with black pixels, up to the given dimensions
- Scale, which can be specified by percentage, or by length of one axis. Image Events automatically scales proportionally.
- Varied file format support. Image Events can open and save JPEG, JPEG2, TIFF, GIF, Photoshop, PICT, BMP, and PNG files.
In addition, Image Events can read an image’s bit depth, color space, dimensions, file type and resolution. Though these aren’t particularly high-end features, you can combine them into fairly sophisticated automation routines. For example, you could easily build a pre-flighting script that automatically ensures that your images are in the correct color space, resolution, and format. Alhough Image Events can’t perform color space changes, you can easily tag, move, or shuttle offending images off to Photoshop on a local or remote machine.
Image Events scripting is very simple. First, because Image Events is an actual application, you much launch it and get its attention just like any other AppleScriptable application. Next, you use Image Events’ Open command to obtain a reference to the file you want to process.
So, to create a script that opens an image, flips it vertically, resizes it by 50%, and saves it as a JPEG on the Desktop, you would do the following:
Image Events’ other commands follow a similarly simple syntax:
- To rotate an image 90°
- To pad an image to 800 x 600 pixels
- To crop an image to 640 x 480 pixels
- To scale to 640 width, with proportional height
You can easily read an image’s properties using the following:
Image Events never displays the file that it opens (though if your script terminates without closing the file, the file will automatically open in the Preview application). What’s more, Image Events provides no progress mechanisms, so there’s no way to provide feedback as to how long a particular option will take.
(Note too that the thumbnail images displayed in the Picture Munger dialog box are also generated by Image Events. Picture Munger opens each image, uses Image Events to create a small thumbnail, and saves it in a temporary file. In this way, Image Events can also be a handy tool for improving the interfaces of your graphics processing scripts and applications.)
As another example of Image Events’ power, check out Gallery Monger which you can download here. Written completely in AppleScript, it uses nothing more than Image Events. Gallery Monger creates web galleries from folders of images, iPhoto Selections, or selections made in iView Media Pro. Gallery Monger’s galleries are based on template files that you can create yourself using any text editor. Because it’s template-based, you can easily control exactly what Gallery Monger’s output galleries will look like. If you’ve been frustrated by the limited web gallery options provided by programs like iPhoto, Gallery Monger provides a simple solution.
Image processing-wise, the application is very simple, using nothing more than the types of commands shown in previous examples. The bulk of the code serves to handle the program’s interface, which was created using AppleScript Studio, Apple’s AppleScript development environment that is included in their free Xcode development system (https://developer.apple.com/tools/macosxtools.html).
Image Events with Other Apps
Though Image Events (and AppleScript) are somewhat limited in terms of their built-in functionality, where these technologies really shine is when they are combined with other applications. When you find you need a particular operation, you can simply find a scriptable application that provides that functionality, and figure out how to work it into your script.
As a simple example, this droplet (called Resize and Mail, which can be downloaded here) automatically resizes all images that you drop on it, saves them to the Desktop, and then attaches them to a new message in Apple’s Mail program. You can see the complete, commented code by opening the script in Script Editor.
Obviously, this is a very simple example of inter-application scriptability. Where this capability really shines is in scripting more complex workflows. As mentioned previously, Adobe’s entire Creative Suite is thoroughly scriptable. So, in addition to scripting image editing operations in Photoshop, you can automate complex processes such as moving bitmap files from Photoshop into Illustrator, and pour the output into an InDesign layout.
Though Image Events provides a lot of power, there are still some basic functions that digital photographers will miss. There’s no facility for reading an image’s EXIF metadata, and — no surprise — there’s no support for the Raw camera format. In addition, although the program can tell you if an image is RGB or CMYK (by reading the Color Space property) it can’t perform color space conversions for you. And, although it can read layered Photoshop files, it can’t flatten them, nor can it perform 16- to 8-bit conversions.
Obviously, you can work around many of these problems by incorporating additional apps into your scripting workflow. However, bear in mind that every time you have to launch another app or open an image in another program, you’re slowing down your overall workflow. Try to organize your scripts so that you do as much as possible in each app, with each Open command.
Another alternative is to use additional AppleScript libraries for performing some of the tasks that Image Events can’t handle. We’ll be looking in detail at some of these libraries, as well as at the image processing options that are available from the OS X command line (and yes, the command line is fully scriptable) in a future column.
In the meantime, if you haven’t considered AppleScript as a workflow manager, it’s worth taking a look at now. If you’re a seasoned AppleScripter but have never investigated Image Events, you may find that it allows you to improve many of your existing graphics workflow scripts.
Read more by Ben Long.