Noise evaluation problems

[Nocturnal]

OK, that's good to know.

We'll discuss the merits of PCL open sourcing in a different thread

[ruediger]

Keep in mind, that one side we talk about "algorithms" and on the other side about an implementation of an algorithm. Some of the algorithms are patented, which might be a bigger problem to deal with than with the license type of the eLynx implementations. It's a pity, that most of the reference links to the original papers within the eLynx source codes are broken. But the description of the basic ideas behind a demosaicking algorithms is often sufficient for deriving an independent implementation on your own.

However, so far I didn't find "the one and only algorithm" for astronomical purposes. Most algorithms focus on dailight pictures and how to deal with gradients. Dealing with noise or the fact, that after demosaicking we align and stack pictures, is not covered.

My Hamilton Adams implementation is fast enough even in JavaScript (which surprises me) -- around 1 Megapixel/second, i.e. 15 seconds for a 500D-RAW, and I will take it as a basis for some more experiments. Removing salt and pepper noise directly after demosaicking with a 3x3 3-way median filter looks good. Maybe some time I get the noise from my 500D under control... or give up and buy a cooled monochrome astrocamera instead... 

Regards,
 Rüdiger

[Nocturnal]

Yes, I know the difference between code and algorithm In any case the debayer algorithm needs to be made thread aware like the bilinear and super pixel ones I already did. When I wrote it I just needed the capability to debayer OSC frames for 'look and see', not to stack. PI didn't have stacking capabilities yet. Now that it does it is perhaps time to revisit.

I would rather not do noise reduction during the debayer step. That should be done purposely in a separate step so you have better control. I also still don't understand why one debayer method would result in more noise than another unless a filter is applied. Different debayer methods attempt to present better colors but that's not to say they produce different levels of noise.

[Juan Conejero]

I also still don't understand why one debayer method would result in more noise than another unless a filter is applied.

The main problems here are aliasing artifacts and interpolation of patterned/oriented image features. One of the documents referenced in the page Rüdiger has linked above, namely:

http://www.ece.gatech.edu/research/labs/MCCL/pubs/dwnlds/p5.pdf

describes this very well and puts some excellent examples. As you can see, AHD is (IMO) the overall best interpolation debayering algorithm from all that have been analyzed in this document. I think I'll change the default setting in the DSLR_RAW module from bilinear to AHD in the next version.

[Nocturnal]

I use AHD in DSS by default but mostly because it sounds fancy

[pfile]

how does setting the default to AHD in DSLR_RAW really help? we all have to calibrate our images and so are usually using DSLR_RAW in bayer mode...

since sander only implemented superpixel and bilinear in BatchDebayer, that's what we're stuck with for now.

or am i missing something here?

[ruediger]

http://www.ece.gatech.edu/research/labs/MCCL/pubs/dwnlds/p5.pdf

describes this very well and puts some excellent examples. As you can see, AHD is (IMO) the overall best interpolation debayering algorithm from all that have been analyzed in this document. I think I'll change the default setting in the DSLR_RAW module from bilinear to AHD in the next version.

In this comparison, POCS (Color plane interpolation using alternating projections) performed best regarding to lowest average mean square error, but fails on the subjective appearance of some of the test images, which are scanned slides from a Kodak Photo CD.
POCS performs incredibly good on artificial star fields, as can be tested out here with user supplied images (reference implementation with source code also available from this site):
http://www.ipol.im/pub/algo/g_gunturk_ap_demosaicking/
An even better algorithm for artificial star fields is this one:
http://www.ipol.im/pub/algo/g_demosaicking_with_contour_stencils/

But I still have no idea which algorithm deals better with noise. According to [1] the performance of adaptive algorithms (like AHD) "degrades significantly as noise increases".

At least I was able to compare a bilinear debayered stacked result with a Hamilton Adams (HA) debayered stacked result. Keep in mind, that HA is quite a simple algorithm and is often only used as an initial preparation step in more advanced algorithms.

But HA renders small white points (stars) better than the bilinear algorithm, so it was not that big surprise to me, that faint stars (mag 13..15) are turning out visibly smaller and somewhat brighter. Attached is a screenshot of a 30x3min stack where the HA integrated result shows sharper stars and even clearly shows two stars as separated (left to the NGC 4132 galaxy) where the bilinear method baked them together.

But since the thread is actually about noise evaluation: After replacing the batch debayer script with my HA version noise is evaluated without problems so far. The weights for "noise evaluated" stacking look OK to me. But I really don't know how to interpret the SNR increments. I stack 30 images and expect sqrt(30) ~ 5.5, but not values above 8?!

Reference SNR increments:
??s0R = 4.5578
??s0G = 8.8960
??s0B = 9.0716

Average SNR increments:
??sR = 4.6774
??sG = 8.1588
??sB = 8.6586

Regards,
 Rüdiger

[1] "A case for denoising before demosaicking color filter array data"; Sung Hee Park, Hyung Suk Kim, Steven Lansel, Manu Parmar, and Brian A. Wandell http://graphics.stanford.edu/~shpark7/projects/demden/Asilomar09_cfadenoise.pdf