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.
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:
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.
Pieces of a Richard Serra sculpture driving toward the George Washington Bridge...
Finally getting things to line up... but the perspective is not quite right. It looks fine on the top half of the mountain, but the horizontal trail should be much lower; in fact, part of it is behind the camera, which just ain't right...
This is the same view with placemarkers drawn in: the green cross is the GPS peak of Blackhead, which is the point where the photo is inserted. The red cross is the camera position (with compass and XYZ directions drawn in), and the pink cross is the peak of Black Dome mountain. There enlies the problem-
And this is where I think the trail should be:
This is Blackhead Mountain in the Catskills, from a lookout on Black Dome, and somewhere in the middle is the trail that links the two. If I can figure out the scale of the photo, and the direction that the camera is pointing, I can use my GPS log to draw the trail.
3D view
Elevation vs. Time
This is the overhead 2D map view. Latitude vs. Longitude. Pretty simple. And now that I finally have some interesting altitude data, I started working on the third (and, inadvertently, fourth) dimension to my program-
