No convergence in MRS noise evaluation routine

[ruediger]

This should not happen in version 1.8, unless the images are basically lacking any signal. So we perhaps have a bug here that we have not found with any of our test datasets during the stress tests we have conducted before the RC3 release.

I uploaded three calibrated DSLR images IMG_8065_c.fit, IMG_8066_c.fit, IMG_8067_c.fit to folder ruediger/NoiseEvaluation_DSLR.
When bilinear debayering file 8066, I get:

Debayer: Processing view: IMG_8066_c
Bilinear debayering: done
MRS noise evaluation: done
Gaussian noise estimates:
s0 = 9.230e-004, n0 = 1.000 (K-Sigma)
s1 = 5.810e-004, n1 = 0.014 (MRS)
s2 = 3.727e-004, n2 = 1.000 (K-Sigma)

This also happens on the uncalibrated CR2-file, so it's not a problem with my master calibration files.
Using VNG as debayering method leads to MRS on all channels in this particular case, but in the past (with PixInsight 1.7) I've seen random k-sigma fallbacks on VNG debayered files also, but much less frequent. But I try to avoid VNG because there is still an open issue (http://pixinsight.com/forum/index.php?topic=4017.msg27963#msg27963). Should I post a separate bug report for this issue?

The other two files have noise estimates with MRS on all channels. During integration, the following weights would be used:
Weight 8065:     1.00000    1.00000    1.00000
Weight 8066:     0.51100    1.07360    0.52917
Weight 8067:     1.00808    1.00118    1.00851

The R- and B-weight of IMG_8066 is only about half of the value it should be, this is the real (end-user) problem.

Rüdiger

[ruediger]

But the noise estimates inside the RGB-fits after the debayering stage are lost in the channel extraction process (and the BatchChannelExtraction utliity script), so I can't take advantage from the early noise evaluation. Maybe this is easy to fix.

Yes, it should be rather easy. I'll try to release an update today or early tomorrow. Sorry for the inconvenience.

Thanks!    .... and sorry for reporting this on a sunday not giving you a minute's rest... :-)

[cs_pixinsight]

In my DSLR workflow, when using wide angle lenses, I extract the R/G/B channels after debayering and align them separately against the reference frame. This allows compensation of chromatic abberation without the need for first aligning and stacking RGB-frames, than extracting R and B-channels and aligning them against G in a separate step.

Regards,

Rüdiger

Rudiger, I image with an astrotrac and wide angle camera lenses.  With my wide-angle images, I have been integrating to a master and then register the R and B channels with the G.  This seems to be the exact opposite of your method.  Can you explain your workflow in a bit more detail and how you decided on this route?  I choose my workflow because I thought the channel extraction, registering and then recombining of all the individual subs seemed extreme, but maybe you have tested both options and your method returned a (much) better result.

I don't want to hijack this thread, so feel free to have me start a new thread for this discussion.
Craig

[Juan Conejero]

Hi Rüdiger,

Thank you for the images. I have reproduced the problem.

This happens because bilinear interpolation is applying a low-pass filter to your image, especially to the red and blue channels (because these channels have one half of the data in the green channel). It is basically as if you applied a Gaussian blur filter to the image. The MRS algorithm fails because it does not find any noise. MRS sees the whole image as if it were covered by significant structures. In fact, after bilinear interpolation there is basically no low-scale noise in R and B, so this is not a bug in MRS, but just how this algorithm works. With VNG interpolation this does not happen because the image is much sharper.

Now let me make a few comments on your problem with VNG interpolation:

in the past (with PixInsight 1.7) I've seen random k-sigma fallbacks on VNG debayered files also

Forget about 1.7 in this regard. It had a number of bugs that have been fixed in 1.8, and the implementation of MRS is almost completely new. There should be no problems with VNG now.

But I try to avoid VNG because there is still an open issue (http://pixinsight.com/forum/index.php?topic=4017.msg27963#msg27963)

The dark artifacts that you are getting with VNG and other algorithms are undershoot artifacts, aka ringing. They cannot happen with bilinear interpolation, but other algorithms that apply nonlinear functions with negative lobes (as local gradient functions) will generate them for linear data. The same happens with the bicubic and Lanczos interpolations, for example, when applied to image resampling. These artifacts, provided that you dither your images, shouldn't be a practical problem because they should be rejected during integration.

By using bilinear interpolation you are losing resolution, which is much worse than the VNG artifacts (which, as I have noted above, shouldn't be a problem if you dither your images).

By the way, your implementation of other debayering algorithms looks very interesting.

One (apparent, but bad) solution to the MRS failing problem could be a new option in the ImageCalibration and Debayer tools to use K-Sigma noise evaluation instead of MRS. The same option would also be added to the BatchPreprocessing script. Since K-Sigma "cannot fail", this would at least provide consistent (although inaccurate) noise estimates in critical cases. What do you think?

[ruediger]

Hello Juan,

thanks for the response and explanation. I was aware that the bilinear method blurs the red and blue channels, but I always hoped the MRS algorithm could be "tweaked" somehow to always give a result. At least it does so in about 90% of all cases.

The dark artifacts that you are getting with VNG and other algorithms are undershoot artifacts, aka ringing. They cannot happen with bilinear interpolation, but other algorithms that apply nonlinear functions with negative lobes (as local gradient functions) will generate them for linear data. The same happens with the bicubic and Lanczos interpolations, for example, when applied to image resampling. These artifacts, provided that you dither your images, shouldn't be a practical problem because they should be rejected during integration.

If the VNG implementation is correct and the red spots are ringing artifacts, then they don't get rejected properly during integration, at least not for AstroTrac stacks because with this device a controlled dithering is not possible, instead there is a more or less constant (sub-pixel) movement from picture to picture.
Comparing a bilinear debayered stacked result with a VNG one, the halos of bright stars in the VNG result don't look rotationally symmetric anymore, see screenshot (a stack of 81 frames). But this is indeed only a problem for widefield shots where bright stars clearly show blue or red halos, i.e. the star discs have different diameters across the color planes.

Also I see the need for still using bilinear debayering, namely when using narrowband filters with bayer matrix chips. With H-Alpha e.g. no cross-colorplane assumptions of the more advanced debayering algorithms are possible and the dominant green channel contains only noise.

One (apparent, but bad) solution to the MRS failing problem could be a new option in the ImageCalibration and Debayer tools to use K-Sigma noise evaluation instead of MRS. The same option would also be added to the BatchPreprocessing script. Since K-Sigma "cannot fail", this would at least provide consistent (although inaccurate) noise estimates in critical cases. What do you think?

This is the best solution IMHO. Right now I have to build groups, stack them separately with "noise weighting" scheme to get comparable weights and later combine the sub-stacks. It doesn't happen too often where I notice a mixture of MRS and K-Sigma within one stack. Normally the same algorithm applies for all channels and all frames can be integrated at once with correct weights.

Rüdiger

[ruediger]

Rudiger, I image with an astrotrac and wide angle camera lenses.  With my wide-angle images, I have been integrating to a master and then register the R and B channels with the G.  This seems to be the exact opposite of your method.  Can you explain your workflow in a bit more detail and how you decided on this route?  I choose my workflow because I thought the channel extraction, registering and then recombining of all the individual subs seemed extreme, but maybe you have tested both options and your method returned a (much) better result.

Hello Craig,
I started using the BatchChannelExtraction script when dealing with narrowband DSLR data, i.e. throwing away unneeded green and blue from H-Alpha and SII data, or, in the case of OIII data, putting the blue and green channel into the same stack. For RGB data, registering R/G/B separately against a single master theoretically should give a better result than registering first the whole RGB and later registering the channels R and B again against G. But the benefit is minimal.

The major reason why I split the channels before registration and integration has to do with the topic of this thread, the (MRS) noise evaluation and weighting. In PixInsight 1.7 noise was evaluated during ImageIntegration and it was never clear what algorithm (MRS/k-sigma) was used on which channel. The console output often looked like this:
Reading FITS: 32-bit floating point, 3 channel(s), 4770x3178 pixels: 100%
MRS noise evaluation: |
** Warning: No convergence in MRS noise estimation routine - using k-sigma noise estimate.
Scale factors   :   1.05222  1.04846  1.09050
[...]
Splitting the channels helps to sort this out, building groups (if necessary) and choosing the appropriate Integration parameters for the separate channels.

Rüdiger

[cs_pixinsight]

Rudiger, thank you for the response.  That console output is all too familiar as I see the same issues as you.  I just went forward with the integration anyway.  I will have to give your workflow a try to see if I get better results or not.  I'm just not looking forward to registering 3 times the number of images 

Craig

[mschuster]

Debayer: Processing view: IMG_8065_c
Bilinear debayering: done
MRS noise evaluation: done
Gaussian noise estimates:
s0 = 6.055e-004, n0 = 0.308 (MRS)
s1 = 5.529e-004, n1 = 0.017 (MRS)
s2 = 2.468e-004, n2 = 0.315 (MRS)
29.99 s

Rüdiger, something else to check out. Note the different n numbers. Big changes in n values indicates different number of noise measurement layers. Cross channel diffs like these are not an issue, but on the same channel across all subs it would be IMO. Again not a "bug", MRS is trying to do its best and just has to switch layers sometimes. This happens rarely but is something to check for IMO, as relative weights might be compromised if it happens.

Mike

[Juan Conejero]

I have just released two updates with new versions of the ImageCalibration and Debayer tools. These tools have now a parameter to select a noise evaluation algorithm. MRS evaluation is selected by default, but you can force the iterative k-sigma algorithm. Tomorrow I'll release a new version of the BatchPreprocessing script, which (along with bug fixes) gives access to these parameters.

I hope this will solve these issues. Let me know if it works as expected.

[ruediger]

This is unbelievable fast... thanks very much; of course I will test and report --- but I need more time than you :-)

Because the debayer algorithm has influence on the noise evaluation, today I tried a small trick:
debayer all files twice (bilinear and vng) and use the maximum of the two results for further processing:
- MRS does not fail on these files
- the stacked result has the same sharpness on very small (uncolored) stars as a pure VNG stack
- bright star's halos are smoother than in a pure VNG stack, because the undershoot artifacts from VNG debayering are replaced in the max(bilinear,vng) operation

Rüdiger

[ruediger]

I made some tests using both K-Sigma and MRS on VNG debayered DSLR files and compared the Integration weights and final noise of the stacked results. Both weights and the overall resulting quality are very comparable, so I tend to prefer K-Sigma because it runs about 50% faster than the MRS routine.

Here are the weights for R/G/B channels for a 20 image stack. Another, larger stack showed similar results.


IMG_2439_c_r.fit        MRS:     1.00000    1.00000    1.00000  K-Sigma:     1.00000    1.00000    1.00000
IMG_2416_c_r.fit        MRS:     2.54952    2.28444    1.37386  K-Sigma:     2.73903    2.70034    1.64400
IMG_2417_c_r.fit        MRS:     2.09038    1.88849    1.20303  K-Sigma:     2.26161    2.24144    1.45147
IMG_2418_c_r.fit        MRS:     1.78545    1.61791    1.11230  K-Sigma:     1.94072    1.93260    1.34841
IMG_2419_c_r.fit        MRS:     1.35723    1.24735    0.94507  K-Sigma:     1.49350    1.52995    1.17226
IMG_2420_c_r.fit        MRS:     1.10311    1.02747    0.83339  K-Sigma:     1.22510    1.26132    1.04133
IMG_2421_c_r.fit        MRS:     0.93060    0.88027    0.79038  K-Sigma:     1.02534    1.06901    0.97380
IMG_2422_c_r.fit        MRS:     0.92199    0.87930    0.80331  K-Sigma:     1.01880    1.06873    0.98779
IMG_2423_c_r.fit        MRS:     0.93053    0.87200    0.79361  K-Sigma:     1.02063    1.05741    0.97388
IMG_2424_c_r.fit        MRS:     0.93046    0.87375    0.81410  K-Sigma:     1.02190    1.05723    0.99283
IMG_2426_c_r.fit        MRS:     0.92657    0.86854    0.80334  K-Sigma:     1.01842    1.04985    0.98294
IMG_2427_c_r.fit        MRS:     0.93248    0.86605    0.80222  K-Sigma:     1.01849    1.03971    0.97668
IMG_2428_c_r.fit        MRS:     0.94464    0.87879    0.82006  K-Sigma:     1.03152    1.05114    0.99459
IMG_2431_c_r.fit        MRS:     0.91210    0.83581    0.79937  K-Sigma:     1.00506    0.99952    0.97057
IMG_2432_c_r.fit        MRS:     0.93417    0.84318    0.81203  K-Sigma:     1.01292    1.00438    0.97796
IMG_2434_c_r.fit        MRS:     0.95799    0.86348    0.83101  K-Sigma:     1.03562    1.02269    0.99545
IMG_2435_c_r.fit        MRS:     0.92335    0.84145    0.81482  K-Sigma:     1.00276    0.99597    0.97849
IMG_2436_c_r.fit        MRS:     0.94320    0.85955    0.83743  K-Sigma:     1.02248    1.01447    0.99900
IMG_2437_c_r.fit        MRS:     0.93955    0.84926    0.83476  K-Sigma:     1.00516    1.00339    0.99787
IMG_2438_c_r.fit        MRS:     0.99931    0.99243    0.99946  K-Sigma:     1.00126    0.99821    0.99750


The resulting noise of the stacked result is as follows (Script->Image Analysis->Noise Evaluation):


MRS
Calculating noise standard deviation...
sR = 4.055e-004, N = 756772 (4.99%), J = 3
sG = 3.288e-004, N = 1079487 (7.12%), J = 3
sB = 2.994e-004, N = 1548160 (10.21%), J = 3

K-Sigma
Calculating noise standard deviation...
sR = 4.052e-004, N = 757587 (5.00%), J = 3
sG = 3.295e-004, N = 1085345 (7.16%), J = 3
sB = 2.996e-004, N = 1554309 (10.25%), J = 3


During my tests, I stumpled over the following:

- Both noise evaluation methods get "distracted" by small well illuminated objects like trees or leaves, which are totally removed after stacking. These objects must be clone stamped to black , otherwise the weights are much too high. See screenshot with IMG 2439,2416 and 2420.

- MRS still fails on integrated results that have black borders. After choosing a reference frame for star alingment, I often add a black border around it so I have the total uncropped imaged area available after stacking, even in cases where I have a large dither pattern or displaced images from several nights. See second screenshot.

These minor things are proably nothing that must be (or could be) fixed. At least we have to know about it.

Rüdiger