Intelligent frame averaging.

[Borodog]

Under the FX menu, there is the option to average frames. This could be a very useful feature but it could be much more useful if it were implemented in a different way.

Currently, when this feature is on, it slows the display frame rate by a factor equal to the number of frames averaged. So if you are averaging 30 frames, it stores up 30 frames, averages them, and then displays this. This makes it pretty much impossible to use this feature for something like collimation, where you are trying to average away the noise and seeing but still see a smooth response on screen to changes to the collimation.

Moving Average Using a Frame Buffer
There are a number of ways to rectify this. First, SharpCap has a frame buffer. One thing that could be done is to hold a running number of frames in the frame buffer, and a running average frame for display. If the number of frames being averaged is, for example, 30, the frame buffer holds 30 frames. Each new frame that comes in is added to the running average frame with a weight of 1/30, and the oldest frame in the frame buffer is subtracted with a weight of 1/30. The running average frame is initialized simply with the first frame that comes in, so it would take a full cycle of the frame buffer to really get going.

The frames in the frame buffer need not be moved around; the first frame is written to position 1, the second to position 2, etc. until the n+1 frame comes in (for a buffer of n frames), which is then written to frame 1. Hence a new frame is always added (by weight) to the average frame and then written to the slot where the old frame is subtracted (again by weight) from the average frame. Hence, only a pointer to the current slot needs to be incremented.

This would allow for display of averaged frames without loss of frame rate.

Exponential Smoothing (no frame buffer required)
Another method is even simpler and requires no frame buffer at all. It only requires a single parameter that the user can set, the smoothing parameter alpha, which can be anything from 0 to 1. As a new frame f comes in, it is added to the exponentially smoothed frame F_n to yield the next exponentially smoothed frame F_n+1:

F_n+1 = alpha * f + (1-alpha) * F_n

Again, the exponentially smoothed frame is simply initialized to be equal to the first frame recorded.

You can see that this method requires no complex frame buffer at all. By selecting alpha, you can tune how much weight each new frame is given, and how far back in time the averaging occurs.

Interaction with "planet" stabilization
Ideally, either of these methods are implemented AFTER "planet" stabilization if that feature is turned on, so that the averaging is being done with the COG stabilized.

Use for collimation
Such a tool would be extremely useful for collimation. And I do mean "extremely" in the most extreme sense of the word. Currently what I have to do is get my collimation as close as I can, make a quick recording of the collimation star, stack the SER file in Autostakkert, look at the resulting image in external image software with a non-linear curve to see the diffraction rings, make an adjustment to the collimation screws, go back to SharpCap, recenter the star, refocus the star, and repeat. With a tool like this and the display stretch, the diffraction rings could be seen immediately, even in mediocre seeing with no loss of frame rate, and everything could be done much more quickly completely in SharpCap.

Of the two methods, I think the frame buffered moving average would yield better results, but the exponential smoothing approach is much simpler to implement and would also yield acceptable results. Of the two, I would probably go for the latter because it is pretty low hanging fruit to implement.

I really hope this gets implemented. It would be a game changer for collimation in SharpCap in my opinion.

Thanks for your time and consideration.

[admin]

Hi,

thanks for the suggestions and useful discussion.

The exponential approach is simpler and doesn't require a large amount of memory to store previous frames (worst case I can think of would be 62 megapixels at 2 bytes per pixel = 124Mb per frame!). However, if the exponential tailoff is short you give a lot of weight to the most recent frame. If it's long then it takes a long time for old data to be forgotten - that might make it challenging to get a good balance. I will have to have a think and probably experiment!

cheers,

Robin

[Borodog]

On my imaging laptop, it holds something like 750 full frames of my 20 megapixel AS183MC in the frame buffer.* But I think the easiest way to go is the exponential smoothing.

I think alpha should be left as a parameter that the user can choose. Let them experiment and see what works best for them.

* That is 8 bit mode. I don't think you would ever need to be in 16 bit mode for collimation.

[Borodog]

Just as a little added incentive, a couple of nights ago I spent a good hour dialing in my collimation on Vega. It was hard because seeing was not very good (at least for Vega; when I finally finished and swung over to Jupiter the seeing looked great).

It was laborious. I had to continually bounce back and forth between SharpCap and Autostakkert and Astra Image. I shot more than 20 short collimation videos that then had to be stacked in Autostakkert and viewed externally. This high-speed frame averaging feature would completely eliminate that. No captures need be made, no stacking, no opening the resulting images, nothing. I am convinced it would radically reduce the time to collimate.

There is actually one advantage that Autostakkert has in this procedure, and I think it would greatly help in SharpCap as well, which is the option to view not just the running average or exponentially smoothed frame, but also a sharpened version thereof. In Autostakkert, you can click a checkbox to produce a sharpened version of the stack. What it does is run the raw stack through a simple convolution matrix:

Code: Select all

-2 -3 -3 -3 -2
-3 -1 -2 -1 -3
-3 -2 60 -2 -3
-3 -1 -2 -1 -3
-2 -3 -3 -3 -2

This really does help a lot during collimation (it's also the basis of virtually all of my post processing for planetary and lunar; most of my sharpening is a second pass on the Autostakkert sharpening).

So I guess this is a secondary request, to be able to view a sharpened version of the running average or exponentially smoothed frame (I doubt this feature would be much use by itself on un-averaged frames, as the result would be too noisy).

[Borodog]

Robin,

Check your email.

Thanks,

Mike

[admin]

Hi Mike,

thanks, yes, received your email and will get back to you later (probably going to try to get today's update out first).

cheers,

Robin