The good news is that the overnight analysis run last night worked out great: the program even found a few more Leonids than the previous version! But a new twist on an old problem appeared. Consider the following sequence of closeups of a Leonid passing by a star:
The Leonid is the slanted blob moving from upper right to lower left. The star (upsilon Draconis) is the small square blob just right of center. The early problem arose when a Leonid image, like this one, merged with a star’s image. My algorithm masks out stars so that they aren’t mistaken for Leonids. So what happens when a Leonid image merges with a star’s image? Initially, the Leonid image was lost and the algorithm would lose the Leonid. I wrote a correction that gets around this problem. But here we have a different problem. Note the red dots: each red dot marks the “center of luminance” of the Leonid -- that is, the point that best represents the exact center of the Leonid. Notice how that red dot is “attracted” by the star. Here’s a superposition of the five frames with the red dots enhanced:
See how the red dots are concentrated around the star? The problem is especially serious in the fourth frame, when the red dot ends up halfway between the Leonid and the star (because the algorithm treats the Leonid and the star as a single very long Leonid). This means that the jump from the fourth red dot to the fifth red dot is too long; the algorithm knows how far the Leonid should jump from frame to frame and this jump is too long -- so the algorithm loses the Leonid. Curses!
How to fix this problem? I can’t separate the two images directly, because the algorithm has to be generous enough to permit some jitter in the star’s image. I tried a number of approaches until I finally came up with something that worked: whenever I detected a Leonid close to a star, I cheated by substituting the expected position for the actual position of the image. In other words, the image of the Leonid was hopelessly mixed up with the image of the star. My algorithm is smart enough to predict where the image of the Leonid should be -- that’s what I use to discover and track Leonids. When a Leonid merges with a star, I cheat and pass it along with the expected coordinates. This approach has one flaw: if a Leonid dies out just as it reaches a star, my algorithm will give it an extra frame of life that it didn’t really have. But in such a situation, it’s impossible to say with certainty that the Leonid really did die out before it reached the star: how do we know that it reached the star and THEN died out, with nothing beyond the star? Since there’s no way of answering this question, I think that my cheat is acceptable.
Welcome to the real world of science, where things are never so clean as to permit absolute, ironclad empiricism.
That night: it might have been acceptable, but it didn’t work. It turned out that there were two stars at the same position relative to each other as we might see with a passing Leonid. If any random flare of brightness appeared upstream of the upper one, it automatically qualified for a free pass from that star, and then another free pass from the same star a bit further downstream, then a free pass from the second star, and so on. This pair of stars was generating lots of false Leonids! There went that idea! To correct it, I cut in half the maximum distance that a Leonid could be from a star to get the free pass. I’m now running another test to see if this corrects the problem; I might have to reduce that maximum distance even more.