November 2nd, 2000
Flying the mission was the easy part of the job; once we got home, there was data reduction to do. During the mission, I had the strong feeling that we were missing a lot of meteors, making a lot of mistakes, but that it was the best job that could be done. Afterwards, looking at the videotapes, I had a hunch that a computer analysis could do a better job. During one of our post-mortem meetings, I voiced my hunch. One of the team members happens to be an expert on computer detection of objects buried in noise, as he does defense software work. He advised me that the problem had been attempted before and nobody was even close to solving it. He himself had done some work, and he believed that the best that could be done was about 80% as good as the human eye could do. However, he seemed to be talking about real-time detection of meteors, and he was attempting to solve the general problem of identifying any and all meteors. It seemed to me that, by taking lots of extra CPU time with a non-real-time analysis, and by zeroing in on Leonids, specifically, I could improve the sensitivity of the software. So I set to work.
My efforts proceeded in fits and starts, as I was also working on several other projects. My first problem was simply identifying the stars in the field of view, a task that turned out to be vastly more difficult than I had imagined. There were just enough inaccuracies and distortions in the video image to ruin all the obvious geometric algorithms. It took me two months to come up with a combination of algorithms that reliably identified the stars in the star field.
Next, I set to work actually recognizing Leonids. This turned out to be tricky, as there were plenty of gotchas to worry about. The greatest of the problems, of course, was the high level o noise in the image. Here is a sample image showing two average Leonids buried in the noise. I have provided 400% blowups in the corners.
Now, the standard approach to this problem is to clean up the noise, then look for whatever is left over after noise elimination. I took a different tack: I decided to use the noise itself as the basis of my search. I built a profile of the behavior of each and every pixel on the screen, measuring both its average brightness and the standard deviation of its brightness -- the degree to which that brightness bounced up and down from frame to frame. This gave me a precise way of measuring the likelihood that a bright flare is merely a statistical fluctuation. In other words, if the computer sees a flare covering a dozen adjacent pixels, it can ask for each pixel, what is the probability that this pixel would randomly appear to be this bright? Combining the probabilities for all the pixels in the flare gives an idea of the overall probability of the flare. Done properly, this gives me a reliable way to look deep into the noise and extract tiny flares that actually are Leonids.
Of course, the actual data required lots of adjustment and polishing before it worked reliably. I didn’t actually get these algorithms wrapped up until September, and the final result involved a combination of factors: the number of images making up the track, the elongation of those images, the speed and direction of the possible Leonid, its brightness, and so on. But by October 1st, I had a system that could detect Leonids so faint that the human eye had a hard time recognizing them: you had to single-step backwards and forwards through the video to see that there really was a meteor there. My software was also proficient at weeding out meteors that weren’t Leonids.
Then came the problem of automatically controlling the camcorder. Now, controlling a video device from a computer is a common problem, and there are plenty of boxes on the market that will permit a computer to run video equipment. Unfortunately, all of these boxes come with their own software, and I needed something that I could custom-program to fit into my analyzer program. The boxes might work just fine, but if you don’t know all the sneaky-special tricks that the programmers used to talk to them, you’re out of luck. This is what I discovered in my own attempts. I started off by purchasing a Sony VBox, a device that Sony built to control its own equipment. Unfortunately, the VBox requires some very tricky programming, and Sony never bothered to make available the full documentation necessary to write such programs. I gathered a bunch of information on the web and tried my damndest to get the VBox working, but after a month of effort, I had accomplished nothing. I found a vendor of a newer, better box, and asked him for help. He told me that the VBox was junk, almost impossible to program for, but for $100, he would sell me his own box, called an Addendum, guaranteed to work. OK, I gave it a whirl. After another month, I still couldn’t get his box working. I emailed him my source code, asking him what I had done wrong. He told me that he couldn’t read programs written in C. I was out of luck. So I contacted another guy, who assured me that the Addendum box was junk, and that for only $250, he’d sell me his box, which was absolutely certain to solve my problem. This time I balked; I had had enough of trying to figure out other people’s solutions. I was going to make my own damn solution.
A solenoid is a simple electrical device: when you turn it on, a rod inside it pushes forward with some force. I mounted three solenoids on a piece of Corian, pushing against some moveable chunks of Corian mounted on hinges. When the solenoid pushed, the Corian piece pushed downward onto the pushbutton on the camcorder. It looked like this:
I set up a little computer-on-a-board called a BASIC STAMP II to control the solenoids, pushing them for the correct durations and in the correct sequence. It looked like this:
The whole thing, then, can best be imagined as a high-tech computer-controlled set of fingers to push the damn buttons on the damn camcorder.
One small problem remained: how does the Macintosh tell the BASIC STAMP when to push the buttons? Normally this would be done through the standard RS-232 connection that you normally connect your modem to. I set up the software to handle this, but after two hours it still refused to work. "Screw this noise", I snapped. I knew there were faster ways to solve this problem. I rummaged around in my parts box and found a cadmium sulfide photocell. This is basically a photoresistor: a resistor whose resistance falls with more light. The BASIC STAMP has a simple command for measuring resistance. I scrounged around in my wife’s art supplies and found a plastic suction cup for attaching pretty glass things to windows to catch the light. I attached the photocell to the suction cup, and the suction cup to the monitor like so:
Then I wrote a few lines of code for the BASIC STAMP to read the resistance of the photocell and interpret it as a signal to start; a few more lines of code on the Mac permitted it to darken a spot on the screen to trigger the photocell. Voila! My Mac could now tell the BASIC STAMP when to do its thing, and the whole task took less than an hour. Ha! Why should we waste time screwing around with other people’s impenetrable operating systems when we can get the job done ourselves?
But now I’m stuck on another idiotic problem: the Macintosh system for handling video digitization refuses to let me digitize multiple snippets of video. I can handle a single snippet, but as soon as I attempt to load the next snippet, it digs its heels in like a stubborn ass. No matter what I try, it insists that it cannot take the next step. I am therefore contemplating further chewing-gum-and-bailing-wire solutions. Stay tuned.