Noise with SLive, Infinity and ImageJ summing

[Hibou]

I have been trying to work out what exactly SX-Live and Atik-Infinity are doing with noise compared with simply summing the frames with eg imageJ. There are surprisingly big differences in the noise when I stack the exact same frames :-(

I used SL to collect 3x120s dark frames from a new SX2 mono camera, stacking them (sum) within the application. It is great that the individual frames are automatically saved as 16-bit FITS files (but not so great that the sum is saved only as an 8-bit PNG :-) With such a long exposure, SL stacks using the hot pixels as "stars". That's what I wanted. Actually I would like an option in SL where "maximum pixel displacement" set to 0 would simply stack without trying to register on stars - useful when there aren't any stars :-) The SL sum is the first image below.

I used Infinity to stack the same 3 frames as if they had been recorded with the Atik Infinity (which I don't have yet). Unfortunately Infinity software won't live stack with other Atik cameras - in fact it just freezes horribly if it finds one plugged in :-( Again Infinity has a nice manual telling you how to use it, but not telling you what it is actually doing, apart from mentioning some special "magic" to reduce noise. Indeed it does do that very effectively, even if "magic" is of no use to me without some explanation. The Infinity sum is the second image below. I adjusted the dynamic range to try to show the remaining noise.

Now I used imageJ to write the 3 images to a stack, and then to sum that stack. When imageJ sums 16-bit files, happily it uses a 32-bit TIFF file for the results, so all the information including noise is preserved. ImageJ doesn't do magic :-) The imageJ sum is the third image below. I have adjusted the dynamic range to show all the noise.

Finally, if I want to get rid of the noise, I can apply ImageJ's "Despeckle" filter, which just replaces individual hot pixels by the mean of surrounding pixels. ImageJ can do more sophisticated outlier removal, or dark frame subtraction, but the simple "Despeckle" routine is enough for my kind of imaging, and much easier than dark frames. The original PHD1 can despeckle, and it would be good if was an option for SL. Anyway, that is the fourth image below - no magic and no noise.

The first conclusion is that SL doesn't do magic either :-) The noise is preserved, but because the PNG sum is only 8-bit and not 32-bit or even 16-bit, you just can't see some of it.

The second conclusion is that the Infinity magic is impressive. If only I could understand it, I might trust it :-) All this might seem a little academic if you only want nice images and don't need to know the details, but if you have read this far and have any comment, I would be grateful. 

[Martin Meredith]

I for one am interested in this kind of analysis, so thanks. I prefer no magic where possible. Ideally, the image stacking, dark subtraction etc should do just that. If I want noise reduction then I'll collect more photons ;-)

I think it is worth qualifying the term 'noise' here. As far as I can see you're looking at hot pixels, which are a particular form of outlier noise that might be susceptible to certain noise reduction processes, but I imagine your aim is to look at real images at some point?  It would be interesting to see if the Infinity magic applies everywhere or just to really strong outliers.

Martin

[Paul81]

Interesting experiment! It is curious what the 'Magic' is too! Will also be interesting to see what it does when a galaxy or nebula is in the frame.

For info, the latest work in progress code has an option to save the current stack to 16-bit FITS.

I have also been tweaking the stacking algorithm, and one area I have started work on is a hot pixel removal to remove the need for darks to squash hot pixels to avoid the stacking algorithm registering on them. I have also been improving the star classifier to also filter them out.

Will consider the option when max displacement is set to 0 - this parameter does more in my latest work in progress code so this wouldn't be a big change to implement.

[Dom543]

The "magic" referenced in the post reminds me of the noise reduction technique in some Nikon and now also Sony cameras that is commonly called the "star eating algorithm".

http://www.cloudynights.com/topic/394106-nikon-d300s-a-star-eater-or-not/?p=5046387
http://www.cloudynights.com/topic/498339-sony-a7s-star-eater-algorithm/?p=6557447
http://www.cloudynights.com/topic/505754-another-real-world-example-of-sonys-star-eater-problem/?hl=+star +eating

--Dom

[Astrojedi]

There are many different kinds of noise. Hot pixels are actually the easiest to fix.

There is no magic here. They (Atik) are likely running a hot pixel detection algorithm. Stars and hot pixels are very different.

A hot pixel is usually limited to a single pixel and a consistent luminosity where as a star has a PSF which means the intensity is spread across more than one pixel (a Gaussian filter can easily detect this). Also with a hot pixel there is a quite abrupt change in luminosity vs. surrounding pixels so much easier to separate from say a nebulae or galaxy (all objects will have a spread vs. a hot pixel). The challenge is when you are oversampling to an extent that the star is contained within one pixel. But rare in practice.

Deep Sky Stacker uses a similar approach to removing hot pixels when registering.

[Astrojedi]

Sorry meant to say 'undersampling' not 'oversampling'.

[Hibou]

Martin, Astrojedi: Yes, by "noise" I meant hot pixels (outliers), the first and easiest noise to remove. Of course there is still white noise that requires cooling, slower readout etc... rather than software. Indeed it's still not clear that I should spend $1000 for a camera and then not spend another $200 to cool it. Or spend 10s integrating an almost stationary image, and then not wait another 1s for slower less noisy readout :-) Yes, the objective is real images with the best S/N, but while signal is fairly easy to predict from the (limited) choice of chip, noise depends on cooling, electronics, software etc. and that is where we have some choice.

Paul: it is great that you will output 16-bit FITS stacks in the next version, and perhaps have an option to remove hot pixels without the need for optional dark frames. An option to simply switch off star registration with displacement=0 would also be good for those of us who don't track stars but do like your live stacking. Infinity's idea of post-observation stacking is also a good one, if not a first priority.

Dom and Astrojedi: By "magic" I mean anything I can't understand :-) Clearly some well defined algorithm is used, probably to detect hot pixels and replace them by the mean of surrounding pixels, but I would like to be told what, and to be able to switch it off. I don't like black boxes, especially ones that take over the whole screen and then freeze up requiring Ctrl-Alt-Delete :-) But it's early days, and progress is rapid.

Finally, it would be good to compare the readout noise of the UltraStar and the Infinity eg a 10s raw dark field at 20C from people who have those cameras. 

[Hibou]

Just to report that I have now tested a pre-release version of the next version of Infinity Capture, which addresses my initial concerns. 

1) It no longer freezes if it finds another Atik camera

2) Double clicking in the header reduces the display to a re-sizeable window

3) You can switch off calculation of the image movement, such that successive frames are averaged without the need to track stars.

4) The interface is more intuitive in that hovering the mouse over a specific control displays tool tips for that control.

5) Stacking low light images produces the same result as averaging individual frames with imageJ, a nice confirmation that the math works.

etc...

I was pleased to see how quickly these questions were addressed, and Infinity now looks like a great option. Thanks to Chris and Steve at Atik.