(download)

Click here to download:

Colored_Optic_Flow.m4v (32.31 MB)

I’ve got every algorithm implemented that I feel is worth the time at this point, and I've made my selections. 

I think, stylistically, the Horn-Schunck (HS) algorithm is the coolest (this video right here). The Lucas-Kanade (LK) algorithm, however, when set up properly, gives what look like the more precise results (which I’ll show in another video later this week). So, I'll use HS for artsy-fartsy electro pop shows, and I'll use LK at work, for SCIENCE.

Music: “Near Dark” by Burial.

EDIT: I've posted the code, for those interested, on the cinder forums.

A labmate is working on how the brain processes movement via the visual system, and was working on ways to calculate "optic flow", or calculating how fast things are moving, in what direction, in particular regions of video stream. I figured that was good enough reason to learn about different methods of calculating optic flow, so I whipped up this little video (accompanied by the first track of Moby's new album! Turns out, that's the only track I like off the whole thing...). 

(download)

Click here to download:

Optic_Flow.m4v (32.67 MB)

So, what are you seeing in the video? White is movement, black is stillness. Specifically, the luminosity is the square of left-right and up-down components of movement (so, technically, I do have information about direction of movement, but I don't use it here).

I'm using the Horn & Schnunck algorithm for computing optic flow, and the various weird changes of the feel of the images that occurs throughout the movie is me tinkering with some of the parameters of the algorithm. Specifically, I modulate the degree of blurring of the input image, before optic flow calculation, and then I also change the size of the Lagrangian multiplier of the HS algorithm. The blur, well, blurs the image, and the Lagrangian term affects how "noisy" the image looks, and how sensitive the algorithm is to small movements near the noise floor. There's always going to be "fake" movement, as a result of compression artifacts in the video stream, and the blurrier the image and the smaller the Lagrangian, the less sensitive the output is to that. However, the bigger the blur and larger the Lagrangian, the less sensitive the output is to actual movement.

Neat! This is pretty fun stuff, and once you start to wrap your head around how OpenCV wants you to think, not too terribly difficult (I do have the Cinder library to thank for making a lot of the bookkeeping much simpler, though).

On another note, I've just picked up and hooked up a Microsoft Kinect, but haven't yet begun doing anything super rad with it, besides getting raw depth-field shown on my screens. I'd like to do limb-angle tracking with people bodies, and then little mice bodies, but that'll have to proceed as free time allows.

Oh! If you're interested in the code, do get in touch with me (I'm not terribly hard to track down), and I'll hook you up, straight up. It's comfortably under 250 lines, but it does depend on a lot of other libraries.

In an impromptu Hi-Rise Café discussion with Vaughn T, it was revealed that we are both notebook nerds, and share, among other things, a seething rage for imperfection and laziness with regards to all things printed and/or bound. One thing more surprising than this shared emotional orientation is that he is a former printer and binder. A multi-talented continental gentleman, without a doubt. He uses this printing skill set for good, and not for evil. Whereas I get generally peeved and stomp around trashing my mediocre notebook collection, he has contracted several companies in East Asia to make him his own custom notebook line.

Reactions — 

1) RAD. Rad rad rad.
2) That is so damned rad.
3) I want one. Or ten.

We talked a little bit longer, and developed some ideas that should come to fruition over the next couple months (Vaughn is a doer, and he does he he says he'll do).

1) Have dots, instead of grids or lines, as guides on the pages. These dots would be a little off-blue, so they wouldn't be picked up by photocopiers, and could easily be removed in image software. You'd be able to write and draw with precision, but the guides would be invisible when you wanted them to be.

2) User paper that doesn't suck. Enough of this 50lb paper maché humbledy-mumbledy. Get some real stiff stock in there. Paper you can write on, paper that makes you feel like what you're writing is important and will last.

3) Add unique identifiers for each notebook and each page, on every notebook and page. Of course, each page would have a pagenumber, but each page would also have a bit.ly-style alphanumeric code, uniquely identifying the notebook. This way, if you were to scan in or snap a picture of any notebook page, OCR software would be able to automatically index the notebook ID and page where you wrote or drew something.

4) Develop software to make searching through it all super easy. Of course, some software that would be able to take images of a page in this notebook, and OCR the text, vectorize the line-drawings, and store everything nicely. I'm all over this like hipsters on fixies.

5) Use proper binding, so the notebook actually lasts. Enough of this Moleskine bullshit. They use terrible, brittle glue, the pockets in the back torque the spine terribly if you put more than a receipt in it, and the whole thing usually falls apart after a month in a back pants pocket. Miquelrius knows how to bind a notebook, and he'll likely follow in their footsteps.

6) None of the extraneous crap. No bookmark thread, no elastic band to hold it shut, no shitty pocket, no faux-leather cover. The essentials.

Maybe we'll get the new laser etching shop in Central square (by the good folks from seriousbusiness) to mark 'em up with some cool designs, or something of the like.

(download)

Click here to download:

Screen_Recording_3.mov (33.41 MB)

After a couple days of intense searching for an appropriate 3D library, I settled on Panda3D. It's an open-source game library, written in C++ but with a full suite of Python bindings (I love Python bindings!), which means you can quickly write code that runs quickly. What were the other alternatives that I nixxed?

- Quake. The engine is open-source now, and there's a level editor called Quark that lets you build arbitrary maps. Other folks have done mouse VR, and this is the engine that they used. I recently emailed an author on a published mouse VR study, and he said, essentially, if he were to do it all again, he wouldn't use this engine. That's reason enough for me.

- Unity3D. I used to work a little at NoiseBridge in San Francisco, and there was a hacker or two there making first-person games with Unity, aiming to deploy them on the PC, PS3, Xbox and iPhone. They ranted and raved about how great Unity3D was, about how easy it was to create complex interactions, about how great the engine looked, etc. It is a great platform, but I'll eventually need to integrate the rendering code into some low-level code talking with hardware outside of the computer. In order to do this, you need what Unity calls its "plug-in" functionality, which basically means the ability to call out to arbitrary system C code. This plug-in functionality only comes with the non-free pro version of the app. And by non-free, I mean $1500. Don't need all that power. Next.

- Minecraft. I'd get style points, that's for sure, and my project would be the envy of all the Macbook Air-toting, plaid-wearing hipster coders. But, the modding environment just isn't ready. There's planned support, but I don't want to base an entire project around a hack.

There were a couple other engines I briefly considered, but I stumbled randomly across Panda3D, and it seemed relatively complete. Disney had been using it for "VR Rides" for some time, it's actively maintained by Carnegie-Mellon, the last major release was in February of this year, and the example code is really extensive. That's all I need. When things are a little more complete, I'll post the code.