Last May, as I reported in this post , I started looking into ways to implement nonstandard image processing algorithms in Photoshop. I found a workaround for the May problem, but that didn’t stop me from looking for ways to make my own algorithms.
Pixel Bender sounded like a good platform, but that Adobe’s withdrawal of support made that a nonstarter; there’s nothing worse than spending hours and hours, or weeks and weeks, developing code and then finding that your platform is obsolete.
In the 1990s, I did a lot of image processing algorithm development using Smalltalk, but that language, even with today’s much faster computers, is too slow for exhibition-sized images. The reason is that it is almost completely interpreted, to the point of being essentially written in itself. This really helps the learning process – if you want to see how a built-in method operates, you can just look at the code – but slows down execution.
I considered C++ and Java. I hate the C++ object-oriented syntax, especially compared to the elegant construction of Smalltalk, and Java borrowed it, but I could get over that. I find working in an interpreted environment to be more productive than using a compiler, so that tilted the scales toward Java. However, I didn’t find a good image processing toolbox for Java, and I certainly didn’t want to write my own from scratch. There are probably appropriate Java toolboxes out there, but I stumbled into a program called Matlab while looking around, and decided to use it.
Originally created for mathematical, scientific, and engineering programming, Matlab splits the difference on interpretation versus compilation. The object-oriented syntax is in the C++/Java mold. (It’s like the QWERTY keyboard; once a bad design becomes standard, it’s really hard to get rid of it) All user code is interpreted, but the many built-in functions are compiled. Execution speed ends up somewhere in the middle between interpreted and compiled languages. Just about everything in Matlab is a matrix – the name is a contraction of “matrix laboratory”, after all – and images fit right into that paradigm. A standard RGB image is a three-dimensional matrix, of dimensions number of pixels in a row, number of pixels in a column, and the three color planes. Matlab has an extensive image processing toolbox, with generalized functions for many algorithms. It has limited support for ICC profiles: you can read or write images with various standard profiles, and convert between the color spaces of those profiles, but there’s no support for creating your own profiles.
The implementation is rock solid, and it had better be, since the program is expensive. There are free programs that are similar, like MIT’s Octave, and one called R.
It took me a couple of weeks to learn the language well enough to be productive and to write a little image processing toolkit for myself on top of the Matlab one. Now I’m experimenting. Stay tuned for the results.
Dave Kosiur says
Have you looked at ImageJ (http://rsb.info.nih.gov/ij/) as a possible alternative? I’ve only glanced at it briefly and am considering it to try a few algorithms for image processing. Between the initial app and the number of plugins that are available, it’s pretty powerful.
Jim says
Dave,
Thanks for the tip. I hadn’t seen the ImageJ material. It looks interesting, and probably capable of faster processing than Matlab. If you use ImageJ, the natural place to end up is with a customized image editor, with you in control of the customizations.
With Matlab, unless you want to go to the trouble of writing a GUI, the natural place to end up is with a class library that you build on top of the Matlab image toolbox, and running the image processing from scripts that you write.
ImageJ has the undeniable advantage of being free. If I were starting over I’d look hard at it. But I’ve already bought Matlab, and invested weeks in learning it. I’ll just soldier on for a while, and see what happens.
Jim