If you’ve read this blog for very long you’ll know that I am a big fan of Photoshop scripting and procedural graphics. Toxin, the iPhone game I’ve been working on, uses procedural art and animated image processing effects extensively. I don’t think the game would be possible without Photoshop scripting.

However, Photoshop’s scripting system is far from perfect. You cannot access pixel data from within scripts, nor can you draw lines or circles or anything like that. These limitations have become really frustrating to me.

For example, on the day I started work on Toxin, I needed to draw an ellipse with precise dimensions. The whole game takes place inside an ellipse, you see. I couldn’t do it in Photoshop by clicking and dragging, it was too inaccurate, so I wrote a C program using the Allegro game library to create the precise shapes I needed. These were then loaded into Photoshop and used as guides while I created the game artwork.

Later I discovered Processing, which is much quicker to develop in than C. I soon developed a workflow where I would go back and forth between Photoshop and Processing, generating procedural content then processing it or running it through scripts until I got the desired result.

Processing, however has some frustrating quirks of its own. As a simplified front end to Java, you often get Java errors that are incomprehensible without digging into the underlying platform. Also, it cannot effectively save semi-transparent PNGs which means that the anti-aliased sprites I was creating all had a solid background which had to be removed. I ended up redesigning my workflow and using the excellent Ghost and AntiGhost plugins from Flaming Pear to overcome these problems.

From graphics app to graphics platform

All these issues got me thinking about what I really want from a high end graphics program. What I want is something like a programmable, graphical Lisp Machine; a powerful graphics programming platform with the UI of an art application, not an art application with a bolted-on scripting system.

I want the ability to programmatically control every aspect of Photoshop from both external scripts and from a real-time REPL inside Photoshop that works like the command line used in some CAD programs.

I want to be able to type line(10,10,100,100) and have a line appear on my presently selected image. I want to be able to open the REPL and assign my current selection to a variable which I can later re-select with a simple command. I want to be able to access the pixel data in my images, and write my own filters in Javascript within the scripting system itself. I think anyone in high-end graphics or scientific imaging would love something like this.

A true graphics platform like I have described would likely have to be written from the ground up with programmability built in. Nevertheless I did spend some time finding out how far I could go with Photoshop’s native capabilities.

I had the idea of writing a Photoshop plugin that contained a number of drawing functions which could be called from scripts via a Javascript library that integrates with the Photoshop document model. So you could write PSDraw.line(10,10,100,100); in ExtendScript Toolkit, and my Javascript library would construct a call to the plugin which would draw the line.

Unfortunately, it’s not possible to get information from a plugin back to the Photoshop script thats running it, so it wouldn’t be possible to do a getPixel() or anything like that. At best, this plugin/script combo would give us a somewhat clunky way of drawing programmatically but little else that would justify the effort involved. (have you ever seen the Photoshop plugin API?)

As a secondary option I thought about actually embedding V8 inside a plugin which would contain an editor and debugger. Besides the ugliness of having 2 distinct Javascript engines running in the same app, the plugin architecture put paid to this idea. Photoshop plugins are one-shot operations. Load the plugin, set the parameters, perform the operation, then shutdown. My idea would only be effective if the plugin was a persistent part of the Photoshop environment.

So the only options then, would be for Adobe to integrate scripting more completely, or for someone else to start making what would be a true sucessor to Photoshop.