Whenever questions of rig stability come up, one of the first suggestions that’s made is to shoot some video and watch it. If the rig is doing something that’s causing image blur, this is a great way to see it. Picavet rigs like to yaw back and forth. Pendulum rigs like to pitch fore and aft around an axis perpendicular to the kite line. Both kinds of suspension will sway side to side about the kite line if the kites have any side to side stability issues. The video makes it easy to spot all of these motions. But it can’t tell you how fast the rig is actually moving, or how many degrees of sway the rig is undergoing.
Or can it?
As it turns out it can. One of the best solutions for unstable video is to run it through a video stabilizer. My favorite is still Video Deshaker by Gunnar Thalin. It’s a filter that runs inside of Virtual Dub, a free video editing program. Video Deshaker does a good job of taking out rotation in all three axes. But more important for our purposes, it creates a log file that says what those rotations are.
The Video Deshaker log file saves, on a frame-by-frame basis, the pitch and yaw in pixels, and the roll in degrees. If you know the focal length of your lens and the physical size of your detector, it’s possible to calculate a pixels-per-degree coefficient and convert pitch and yaw to degrees as well. Even sampling at 30 frames per second, this provides a rich data set from which to analyze camera motion. 60 frames per second is even better. A thousand frames is enough to do some real statistics on, and it takes less than a minute to acquire all the data you need.
The Video Deshaker web page describes the format of the log file. The log file is a comma delimited ASCII file, which can be read into just about any spreadsheet or mathematical analysis package. For this example I’m using Excel, but most of these statistics could be done with Open Office, Matlab, MathCAD, IDL, or even simple UNIX command-line tools like awk. (I know… I’ve done it.) The only real trick is getting the data into the program of your choice. Once it’s there, it’s time to play.
There are a couple of statistics of interest:
The first is the maximum absolute value of motion in each axis. This gives you your maximum rate of change during the entire session. Be careful, though. I found that the act of holding my camera and pushing the button to start the video often produces the highest velocities the camera sees. I chop off the first ten and last ten seconds of the video before processing to avoid this.
The next is the mean absolute value of motion in each axis. This gives you an idea of what your typical rig motion looks like. It’s important with both of these to take the absolute value of your rotation rates before calculating the mean. If your rig is pointing in one direction for the duration, the average rotations should come out close to zero since the rig swings away, and then swings back toward the original pointing. But take the absolute value first and then calculate the average, and you have your average angular velocity.
The third statistic you want is the standard deviation of the motion in each axis. This tells you how good your data is. It also provides a really good metric to measure how choppy a flight is. If the camera is moving all over the place, the standard deviation of the velocities is all over the place, too.
The fourth statistic of interest is to integrate the angular rates to get the angular position as a function of time. This sounds awful, but all it means is you pick a starting point and keep adding on the rotations on a frame-by-frame basis. The result is a table of values telling you where your camera was pointing as a function of time. You can run statistics on this set similar to the ones you ran on the velocities: mean direction, standard deviation, etc. One that is interesting is to measure the maximum and minimum in each axis. This tells you how far the camera swung in each axis.
Before going further, let’s take a look at that last one: One of the common misconceptions with camera stabilization is that it’s sufficient to make the angular excursions small. What this means is that the camera won’t swing too far off its subject, even if the motion itself around the subject is quite rapid. This is quite patently false. In terms of image blur, it’s more important to keep the rates small, even if the camera wanders significantly off the subject. In the case of the former the composition will be consistent, but the images will all be blurry. In the case of the latter, the compositions will vary from image to image, but they will all be sharper than in the former case. Of course the worst case is if the camera is swinging wildly and rapidly in all three axes. In that case the composition and blur is unacceptable.
There’s one last bit of information that can be extracted from all this data. It’s also one of the most useful measurements you can have when looking at the stability of a dynamic system: the power spectral density, or PSD.
When you have a time sequence, as we have for the motion in each of the three axes of our camera, it’s possible to convert the data from the time domain to the frequency domain using a Fourier transform. The easiest way to do this is using a Fast Fourier Transform, or FFT. Most analysis packages include FFT routines, including Excel and I believe Open Office. Other tools like Matlab and MathCAD also include FFT routines, but since these aren’t common tools I won’t go into them.
One of the best tutorials I’ve seen for doing an FFT in Excel is Larry Klingenberg’s 2005 paper, “Frequency Domain Using Excel”. The FFT component of the spreadsheet I built for doing camera motion analysis was built using his instructions.
The result of an FFT on our data set is a new set of data that tells you how much of the motion of the camera is coming from a given frequency. The range of frequencies covered by the FFT is a function of how fast you can take the data. At 24 frames per second, you can measure frequencies from zero (uncoordinated motion) to 12Hz. At 30 frames per second, that range is from 0 to 15Hz. At 60fps you can measure from 0 to 30Hz.
In the next installment I’ll go through some test videos I made that demonstrate various aspects of this method, and start to apply it to a real KAP rig.