« This Week in Photoshop | Main | This Week In Photoshop: Backup, Aperture... Netscape? »
February 21, 2006
Photoshop + Xgrid = RAW Processing Power!
[EDIT: added link to shell script]
[EDIT: added download link for code bundle]
[EDIT: Now available in Russian , apparently...]
[EDIT: we are now in the official xgrid FAQ .]
For one of my long-term clients, a large e-commerce company, I do a lot of processing and workflow work. They have 1-4 sets going, all day, every day, each spitting out gigs and gigs of 22 megapixel leaf files. It's my job to process them and dispatch them to retouchers. They had me set up on a nicely equipped dual-2.0Ghz G5 with all 8GB of RAM, connected via ethernet to the XServe where all the files are stored. But I was finding that I was still spending a lot of my time waiting for files to process using Image Processor or custom actions running via Batch. Getting a second machine and running batches on that machine worked for a while, but I work in a very small room with poor ventilation, and having two 500W machines cranking away next to my legs was, er, rather unpleasant.
So, hacker that I am, I decided to see if I could use Xgrid to distribute the load among the other machines in the studio and in the retouching room.
Weeks later, and several key Xgrid mailing list posts later, I had myself a render farm!
Here's the way it works:
If you're not familiar with the basic architecture of Xgrid, see here for a brief overview.
Each agent is set up with an account named "xgrid" and the same password. This has to be a real user account, because using Photoshop requires access to the WindowServer, and only the logged-in user can do so. Unfortunately, that means that for now, each agent must be dedicated to the grid. Other users may use these machines, but when they are on the grid they are render nodes exclusively.
Each machine has Photoshop CS2 installed, and a syncronized copy of all Adobe prefs and color settings. Particularly important are the camera raw defaults and workflow settings! SSHd must be turned on. In com.apple.xgrid.agent.plist, I have added the value "MaximumTaskCount = 1", since Xgrid assumes each CPU to be able to handle one task. We're not quite up to that task yet (see my TODOs at the end of the article).
Some sort of shared network file storage is necessary. Here I happen to have an Xserve + Xserve RAID hosting 1.3TB of image data (this holds just over 1 season of data for us-- I have to cycle off to archive servers and tape 4 times a year!).
Now, to the processing! On my machine, which happens to serve as the controller, I have written a couple of applescript droplets. These take the input files, and a chosen output directory, all on the server, and spits out a plist with one job consisting of multiple tasks. Then it submits the job to the controller via the xgrid command line.
The shell script that is the actual job does a few things. It writes a few sub-scripts to /tmp, to be called momentarily. It launches an expect script, which logs in to the agent via SSH (as the user "xgrid" which we previously set up and logged in on each agent), and spawns an applescript via osascript. This applescript then makes sure we're connected to the network, opens photoshop, opens and processes the file, and writes the result to the destination directory on the network. The whole process is monitored using the Xgrid Admin tool.
The end result, while somewhat cumbersome to set up, is remarkably speedy. I can process 100 22-megapixel Leaf raw files in under 6 minutes (with 4 agents in the grid)!
I also use the grid to trim and flatten retouched PSDs to web-sized TIFs (yes, TIFs-- long story, but we support zooming on the site so things get uploaded at a relatively high resolution).
Obviously the bottleneck here is network I/O, but the organization has definitively decided against rolling out gigabit to the desktop, so I can't test that hypothesis further. As it is, the agents are connected via switched 100Mbit to a GigE backplane.
TODOs:- get the agent to launch tasks as the logged-in user, or
- get the agent to access the WindowServer via Fast User Switching, so I can harvest CPU cycles from more machines in the company
- more than one CPU/agent (this is a function of the applescript I'm using)
- start and stop the agent via LoginHook and LogoutHook (haven't had time to really debug this, it's a production cluster now)
If there's enough interest, I'll post the code I use for the applescript droplets and the shell scripts that make it all work... post in comments below. done.
DOWNLOAD (4k zip)
*NOTE: applescript droplet requires Satimage XML osax.*
Posted by Joshwa at February 21, 2006 10:19 PM
Comments
Great site love the thought of processing 100 veaf22 pics in 6minutes. Cant believe your managing that over 100Mbit ethernet imagine over gigaBit. Does your technique rely on using default ACR settings? would it be possible to make batch changes to settings then drop them into another folder/or once they are given a specific label color the grid processes them out?
Posted by: Rick | March 29, 2006 03:01 AM
Hi, Rick,
I do rely somewhat on having default ACR settings already set on the agents-- but if you apply custom settings in .xmp files, as opposed to the centralized camera raw database, those settings are applied when they are processed by the grid. I use this for white balance, exposure, curves, etc.
The other important settings not modifiable except via ACR prefs on each agent are the workflow settings-- resolution, color space, and bit depth. Until Bridge and ACR are directly scriptable via Applescript, those must be set on each agent (though I can imagine a more complicated scheme where the script writes new prefs and relaunches photoshop).
Again, the unscriptability of Bridge via Applescript does not allow for watching for the application of color labels-- in Bridge. You could, though, watch for Finder's color labels. I think using the droplet is probably more efficient.
Posted by: Josh Wand | March 29, 2006 08:40 AM