It’s been almost 6 months since we posted about Shiffman’s Most Pixels Ever processing library, but that doesn’t mean there’s been no progress.

Recently he’s left the lab and ensconced himself in front of the IAC Video Wall, bringing Most Pixels Ever to the screen with the most pixels to give.

Run Lola Run Lola Run Lola Run Lola Run from shiffman and Vimeo.

A little technical detail, with an announcement:

Each cell of video is 60×45 pixels. The entire system is run by 3 Mac Pros each pumping out 2720×768 (totaling 8160×768 for the entire wall.) I’m going to be releasing the Processing library/framework this week! Stay tuned!

Releasing the library? You mean this library?

The site is still a little lean, but early adopters can download the Alpha version and read a little about running it with processing.

Bouncy bouncy!

Jaymis is getting ready to go on tour with a rockstar, and I’m dreaming of geeky OpenGL implementations for 3D eye candy. Don’t worry; we’ll make the two worlds fit together eventually.

Here’s the latest from OpenGL land. First, perhaps the days of Java lagging in OpenGL implementation are done. The updated 1.1.0 JOGL bindings support OpenGL 2.1 and NVIDIA GeForce 8800 extensions, for groovy geometry shaders and other good stuff. Let’s see, that puts Java’s OpenGL bindings well ahead of OpenGL 2.1 implementation on Mac OS X, which isn’t due until the fall. (Just a binding, but still.) And you should be able to experiment with OpenGL 2.1 and the NVIDIA extensions from within Processing.

And Vista? OpenGL runs just fine on Vista, according to the Khronos OpenGL ARB Working Group. (Hey, aren’t they the ones cloning the President’s nose? Sorry, Woody Allen reference.) It’s compatible. It benefits from Vista, somehow. And it’s competitive with XP. Of course, all of this is in theory; in practice, drivers from NVIDIA in particular seem … not so fresh, performance and stability wise, at least in my experience. I expect this situation may improve over coming months.

Enough geekiness. Simple translation: Java for OpenGL rocks! OpenGL will run well on Vista on all drivers someday.

One notable problem with Java (and thus Processing) is that, on its own, it’s not the best solution for doing the pixel-by-pixel processing and computer vision / motion tracking / video analysis, as it’s not as efficient for those kind of tasks as C/C++. The motion tracking / computer vision library for processing JMyron is actually written in C++ and wrapped in Java, for instance — though it’s important to note that the ability to wrap C/C++ code in Java is very nice. (And once you’ve done the basic analysis, you can get away with some iterating through pixels in Java/Processing, and it is fast for some related tasks like doing the actual animation.)

But C++ can be a bit unfriendly. There are libraries that are very helpful for doing this kind of work, but you have to track them down. Chris O’Shea of Pixelsumo writes about a new solution that could bring some of the basic ease of use of Processing’s integrated libraries to C++ work, in the form of Zach Lieberman’s new C++ library “OpenFrameWorks”:

OpenFrameWorks at Ars Electronica [Pixelsumo]

I’d keep a close eye on this, as Lieberman’s extensive experience building work that uses these techniques means he knows a lot about what’s needed in the way of performance. But there are some major caveats that mean this isn’t quite “Processing for C++”: