New script for denoising linear monochannel images

pfile said:
still, it sounds like the median of the LN stack was for some reason abnormally low? i understand that Mure has problems with the low median but it seemed like you were saying the low median is in itself a problem.
Click to expand...

I now think the low median is not itself a problem. It might remain a problem if LN gave a low median result for a high median reference, as that might indicate LN is not operating as we expect it should. But I am guessing that this did not happen, probably the LN reference had a low median.

For MureDenoise, the new metadata I am proposing will provide more info on what LN actually did. That will help a lot.
 
New version MureDenoise 1.26 should appear soon as an auto update. Change log:
  • Improved undo/redo/reset support when the denoising process is aborted.
  • Added support for interpolation method Lanczos-5.
  • Improved documentation and tooltips.
IMO one of the strengths of MureDenoise is that it has little if any impact on star FWHM and eccentricity. Here is data that shows an example of this. This test project consists of 28 3nm Ha frames, 18.7 hours, from my undersampled, portable setup. The table below shows median FWHM and eccentricity for the frames, the integration, the denoised result, and the final processed image.

ImageFWHM (pixels)    Eccentricity
28 frames0.94 +/- 0.020.40 +/- 0.01
Integration    1.060.43
Denoised1.050.43
Processed1.680.47
 
Thanks for the update Mike. I look forward to it. I have never found a noticeable FWHM increase due to MureDenoise and your data confirms that.
 
Hello Mike,

Is it ok to use MD on stacked images even if they are LN'ed ? I will give it a try but wanted to have your word on the subject as well.

Thanks
 
Hello Sedat,

It is OK to try, you might be able to get an acceptable result by adjusting Variance scale. But officially LN is not supported.

Work to support LN has started, but it is not yet complete. I need Juan's help to add additional metadata and he is very busy with other higher priority tasks.

Thanks,
Mike
 
Here are examples of the denoised results produced by the new option Include gradient classifier on several of my projects.

Notes:
  • Please widen your browser window enough so that the integrated and denoised crops appear side by side, left and right.
  • All crops shown with boosted stretch.
  • The integrations range from 12 to 20 hours, the frames are 40 minute, 3nm Ha, undersampled exposures. Each pair of crops is from a different integration.
  • In the dark nebula areas, about half of the total noise is measurement noise from the detector, the other half is photon counting noise.
  • The images were denoised with Variance scale set to the default of one.
  • Safari on my Retina 5k monitor smooths the displayed images slightly, the visual differences between the crops are larger when viewed from within PixInsight.

2012_06_c.png
 
2012_06_d.png


2012_09_c.png
 
2012_09_d.png


2013_06_c.png
 
2013_06_d.png


2013_08_c.png
 
2013_08_d.png


2013_11_c.png
 
2013_11_d.png
 
Sedat said:
Looks great to me! Thanks!

Can you please broadly tell what this new parameter does actually ?
Click to expand...

Thank you Sedat.

The Include gradient classifier option increases denoising accuracy by incorporating additional local gradient magnitude (ie, local intensity change) information into the denoising process.

Local regions of the image at each multiresolution scale are classified by the value of the local Gradient squared magnitude estimate to local Noise variance estimate Ratio (GNR).

This classification helps the denoising process to better optimize the compromise between noise suppression and signal preservation. Generally at each scale, local regions with small GNR have improved noise suppression while local regions with large GNR have improved signal preservation.

The improved denoising accuracy comes at a cost of 50% more processing time.
 
Thank you Mike.

The increase in processing time is a small price to pay if the result justifies the time spent and looking at your above images this looks to be the case.

What cycle-spin count are you using ? Is the default 8 enough for most of the cases ? I noticed that you increased the max count to 48 recently and thought there must be a reason for this.
 
Sedat said:
Thank you Mike.

The increase in processing time is a small price to pay if the result justifies the time spent and looking at your above images this looks to be the case.

What cycle-spin count are you using ? Is the default 8 enough for most of the cases ? I noticed that you increased the max count to 48 recently and thought there must be a reason for this.
Click to expand...

On these examples I used 32. The change from 8 to 32 is measurable as a pixelwise difference, but hard to see, if at all. 48 is for testing.
 
Hi I am curious to try this script. For gain and noise input parameters should I use the detectorparameterscript that comes with the main script? Should the two flats and darks have same exposure/gain/offset? Also is the output from the script ready for the MURE even though the camera (ASI1600) has a 12bit ADC? Thank you
 
niccoc1603 said:
Hi I am curious to try this script. For gain and noise input parameters should I use the detectorparameterscript that comes with the main script? Should the two flats and darks have same exposure/gain/offset? Also is the output from the script ready for the MURE even though the camera (ASI1600) has a 12bit ADC? Thank you
Click to expand...

Yes, use the detector setting script, and all frames should have the same camera settings, with exposures the same for each pair of frames. 12bit works. Some frame capture software scales up 12bit to 16bit, other software does not. Either works, but all frames should be captured the same way.
 
Thank you. ZWO drivers scale up the images to 16bit. Soif I understand correctly I just input the two darks and two flats in the detector settings script and use the calculated values as input for the MURE script.
One more question, what about interpolation? I always leave it to Auto for image registration.
 
niccoc1603 said:
One more question, what about interpolation? I always leave it to Auto for image registration.
Click to expand...

Auto uses Lanczos-3, assuming all frames have the same pixel resolution (the script won't work if frame resolutions differ). You can double check the method choice by running a couple of frames in StarAlignment and looking in the process log.
 
I cant get the script to work on my latest image - I was trying gain 300 and going for lots of short exposures, this is with my ZWO ASI1600mono. For Gain I used 0.1 (since you cant put in 0) and for noise I used the calculation provides earlier and did 1.25 / 0.1 = 12.5  I used this page to get the figures: https://astronomy-imaging-camera.com/wp-content/uploads/1600-Gain-RN-DR-FW-vs-gain1.jpg
 
blinky said:
I cant get the script to work on my latest image - I was trying gain 300 and going for lots of short exposures, this is with my ZWO ASI1600mono. For Gain I used 0.1 (since you cant put in 0) and for noise I used the calculation provides earlier and did 1.25 / 0.1 = 12.5  I used this page to get the figures: https://astronomy-imaging-camera.com/wp-content/uploads/1600-Gain-RN-DR-FW-vs-gain1.jpg
Click to expand...

Sorry for the trouble. It is hard to read the chart accurately at camera gain 300. The ZWO driver scales 12-bit data to 16-bit, so detector gain in e-/DN is actually 16 times less than the chart indicates. Extremely small detector gain values can't be specified accurately enough in the script with only 3 digits to the right of the decimal point. Also, using such a small gain risks easy saturation and clipping in your frames.

To use MureDenoise, I suggest camera gain 150. Accounting for the driver, detector gain in e-/DN is about 1/16 = 0.062 e-/DN and detector Gaussian noise in DN is about 1.7/0.062 = 27 DN.

For better accuracy, use the script MureDenoiseDetectorSettings. You supply two flat frames and two bias frames, and it gives detector settings that take in to account your camera's actual configuration and performance.
 
Hi,

I've tried using this a few times and I have got some amazing noise reduction. However if I do it before DBE then try and do DBE the resultant DBE is obscene. Are there any special considerations that I've been missing regarding DBE after mure denoise?

Also does the mure denoise work on the whole image i.e. are masks advisable?

Many thanks

Nick
 
Hi Nick,

On DBE, I don't know what to suggest. In my testing, DBE on the denoised image gives basically the same type of result as on the original image. My testing used the automatic sample generation. Note my testing of this has not been in depth, so maybe I am missing something.

The script is designed to work on the whole image, and to not need a mask. If a mask is set, the script ignores it and then goes on to denoise the entire image. As a workaround, if needed, you could use PixelMath to mix the original and the denoised result, using the mask as a mixing parameter. But this takes a bit of math and might not be easy to do.

Mike
 
what do you mean by "the resultant DBE is obscene"? do you mean that the corrected image looks terrible? if so it's likely STF just overstretching the image based on its own noise analysis. if you apply the pre-DBE STF to the DBE'd image it would look fine.

rob
 
You must log in or register to reply here.
Back
Top