I am just about at the end of my rope on dealing with this damned noisy, jiggling, moving imagery. I am trying one last trick: shifting from arithmetic means to geometric means. To explain the difference, let me show you some frame shots; the first is a typical frame from this camera:
To help clean up the imagery and make star identification a little easier, I was using not the image itself, but the averaged value of two adjacent frames. That is, for each and every pixel, I added together the brightness value for each of the two adjacent frames, then divided by two to get an average value for the pair of frames. Here’s what that looked like for the entire frame:
This is, as you can see, a little cleaner, a little easier to work with. But just recently I discovered a new technique. In photo manipulation programs, it’s called multiply blending: the values of the corresponding pixels of two different images are multiplied together to produce a new image. Here’s what multiply blending does to the two images used in the averaging example above:
Quite a difference, isn’t it? The stars really stand out sharply in this version. That’s because the noisy pixels all tend to cancel each other out, leaving only the signal pixels -- the ones representing stars -- standing out starkly. So I rewrote the core algorithm to use multiplication instead of averaging. However, this generated a few problems that I won’t go into here. That’s when I hit upon the idea of using the geometric mean of the two pixel values. Perhaps you already know what a geometric mean is. Just in case you don’t, here are the formulas for arithmetic and geometric means:
Arithmetic mean of x and y = (x + y) / 2
Geometric mean of x and y = square root (x * y)
I hope you can see the symmetry here: they both do exactly the same thing, but the first does so additively, while the second does so multiplicatively. (Can you say “multiplicatively”? I knew you could!)
As I write this, I am running the acid test of the new algorithm. So far it is working splendidly. The program is spitting out diagnostic values for a single star as it runs, and it has that star nailed down solidly. It has already gone through over 10,000 frames without losing its lock on the star even once. But we’re approaching the moment when the airplane starts to turn, sending the image sliding up, to the right, then down. The crowd is hushed... here it comes... you can cut the tension here with a knife... 11,000 frames and the lock is still solid... 12,000 frames... geometric integrity at 6 milliradians (that’s about a third of a degree)... 13,000 frames, steady at 7 milliradians... we just went through the jump... DAMN! we lost the lock!
Postmortem: the new lock held for only nine frames, and then suddenly jumped over 200 pixels. Why? The geometric integrity worsened by about 50% just before the jump -- again, why? The frames themselves show no oddities that would cause such a dramatic development. I have two diagnostic options at this point: see if the lock can hold as the airplane turns, or closely investigate the precise cause of the lost lock. I’ll start the first option and let it run for now. I’ll go to bed and see what is has accomplished in the morning.
Back to the drawing board...