Thursday, March 10, 2016

Grad School

What I've been up to - some of my academic work at NYU, for the Master's in Scientific Computing(MS) program in the Courant Institute for Mathematical Sciences-

Some highlights:

Computer Vision with Davi Geiger (and upcoming thesis in Stereo Matching)
Early Result from Stereo Matching/Depth Finding

Original Left/Right Images courtesy of the Middlebury College 2014 Stereo Datasets


Computer Graphics with Ken Perlin

"Marble Maze" - Final Project, using ThreeJS and CannonJS



Monday, February 20, 2012

Fight or Flight: Hello, Cinder.

I am trying to learn Cinder, the more advanced (meaning complicated) C++ version of Processing, so I can port my GPS program to it and hopefully get it to run a bit faster. In the mean time, I am messing around with the tutorials and came up with an idea to model pedestrian traffic as a way to learn Cinder's particle engine.

In the process, I stumbled upon what I think may be a significant milestone in the machine learning and artificial intelligence fields: I have created a behavior model for the most basic of human instincts: panic.

In the first shot, two "pedestrian" particles approach each other, and collide, because they fail to adapt to the situation as time unfolds. In the second shot, they are programmed to "turn right" if they sense an oncoming collision and feel threatened. However, I neglected to provide them a means of relief, and lacking a "fight" instinct, they are doomed to perpetual "flight".


I feel this way quite often on the streets of New York City...

Sunday, January 8, 2012

Hanging out in Rumney

After leading nothing below 5.10 all weekend, Giuseppe attempts the upside-down second pitch of Giant Man (5.12 b/c) in Rumney's Hinterlands...
The nice thing about sport crags is that there's bolts everywhere - perfect for setting up photo ops. Here is our protagonist looking good on the approach:
Behind the scenes exclusive:

And hanging out, looking for the move...

Sunday, November 6, 2011

Calculus and Christmas Lights (or, the flicker problem)

This is a problem that I was wrestling with a little over year ago, building an LED prop for a friend's movie. That was before I started taking math classes...

To simplify it, many "efficient" light sources are efficient because they flicker- they are not constantly "on" like incandescent lights. Filmmakers love incandescent lights because they don't flicker (see note).* More efficient sources like HMI's are very carefully engineered to flicker in sync with the camera shutter, so that the camera doesn't notice the flicker. And most LED light sources are battery powered with a constant DC voltage, so there is absolutely no flicker.

This is where we come to the problem of LED Christmas lights- long strings of LED lights in series, that plug into AC power. LED's don't normally run on AC power because the voltage is too high, and LED's are at their hearts, diodes, which means they only pass current in one direction. Most LED circuits you plug into your wall go through both a transformer, to step down the voltage to a safe level, and a rectifier, to invert the negative half of the AC wave, and provide a constistent DC power supply.

But LED Christmas lights are an ingenious solution to this problem... almost. They take 60-70 LED bulbs, and wire them in series. LED's tend to drop about 1.2-2.0 volts individually, but put 60 in series, and you've got yourself a circuit that can drop 120v. That eliminates the transformer (wall wart) from the equation. However, it does not adequately address the flicker problem. LED's are still diodes, and if you have 60 of them, all pointing in the same direction, they will only be "on" when the AC wave is positive. That means, they will only be on for half of the AC wave.

You may notice this flicker if you look with the corner of your eye. The first time I noticed this was rigging on the set of a pretty big movie that will go unnamed. If you can see a light source flicker with your eye, a movie camera will definitely pick it up, and possibly ruin the shot (I wonder how much it cost to fix that...).

That's because movie cameras generally shoot at 24 frames per second, and the shutter speed is 1/48 of a second. That means that the camera only sees HALF of the time you're filming (they say half of every movie is darkness), and the camera ONLY sees things 1/48 of a second at a time. This being a film camera with a mechanical shutter. Digital cameras (and digital shutters) make things even weirder.

Hence, some math:


I've approximated the 60Hz AC power with the red sine wave, and the 24 fps camera shutter with the green sine wave. The LED's are only on when the red wave is positive, and shutter is only open when the green wave is positive (shutter speed is calculated from when the shutter is half-open to half-closed, probably because it's constantly moving).

So each positive half-wave of the green curve is one frame in the movie. The exposure (brightness) of the LED's in each frame would be equal to the intersected area beneath both curves, when both are positive. Keep in mind there are 24 frames per second:


This is done by adding up piecewise integrals. A1 is the "brightness" of the first frame, and A2 is the "brightness" of the second frame, which is slightly more than the first. Keep in mind these are abstracted, and don't actually correlate to any real measure of brightness. However, the proportions should be accurate, and Frame 2 is 18% brighter than Frame 1. That's not good.


Another interesting thing is that 5 AC power cycles = 2 camera shutter cycles. The waves line up every 2 frames, or 5 flickers. So all the even frames are the same, and all the odd frames are the same- which means every other frame is 18% brighter than the one before it. There's your flicker!

Thanks to Maple for doing the heavy lifting for me. I need to figure out how to code in Maple. It would make my life much easier...

*Note: Incandescent lights also "flicker" because they are on AC power, but they are so hot (read: inefficient) that the flicker is negligible.

Wednesday, August 24, 2011

RoboRadar

Working on making a radar type sensor with a Parallax rangefinder mounted on top of a servo motor. Left is raw distance data (2-300 cm), drawn in polar coordinates, and right is *supposed* to be corrected into rectangular coordinates. But they look eerily similar so I'm not sure that's working yet.

But the big accomplishment is the beginnings of an object detection system, as note by the white boxes. Basically if the points are close enough together, there must be an object there.

The problem is figuring out how close is close enough. As you can see, there are lots of tiny boxes that should probably be combined into one big box, as well as really big boxes that are overlapping smaller discrete objects.

Too many little boxes are a problem for memory & speed (right now it's sensing over 4,000 objects, but there are only 90 dots!). It would make more sense to combine them into one "wall" object, with the same effect.

The really big box is a problem, because the robot would see that entire area as an object, and avoid it; it would never move forward.

The moral of the story: weak object detection makes for slow, paranoid robots. Smarter = faster = more risk tolerance = more exploration!

Tuesday, August 23, 2011

Richard Serra Driving

Pieces of a Richard Serra sculpture driving toward the George Washington Bridge...

Finally, some art in the suburbs...

Thursday, July 28, 2011

Inspecting the Internet Plumbing

Ever wondered how a website gets from there to here? Me too.

Especially when "there" is halfway around the world...


The Black Dot is Brooklyn (because Brooklyn is too cool for silly colors). The white dots in the upper right are a website in Italy. The other white dots are the servers in between that the website had to travel through to get to me.

The signal went from New York to New Jersey (which are so close they overlap), to California out left, and then magically to Italy.

Pay no attention to the line going straight through the Earth. I actually have no idea how the signal got from California to Italy. Must be either a satellite or an underwater cable... but an underwater cable wouldn't go direct to Italy... very curious indeed.

Also, the white dot on the lower right is an anomaly. It actually represents the IP 0.0.0.0, which is a dummy IP (which I believe is my computer talking to my router). Since it's a dummy IP, it was assigned (0,0) as a location, and so it pops up at the intersection of the Prime Meridian and the Equator.

Other points of note are Greenwich, England (green dot on the Prime Meridian), and the Magnetic North Pole (yellow dot on the yellow meridian). The rest are cities around the world.

At some point I will have to figure out how to add continents and draw arcs around the world rather than tunnel straight through it... however convenient that might be. For some reason my problems keep coming back to moving things around spheres...