New script for denoising linear monochannel images

[blinky]

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

[mschuster]

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

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.

[nm303]

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

[mschuster]

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

[pfile]

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

[nm303]

Thanks Mike- I guess I'll just try a few more times. Good to know that there is no point using a mask.

Thanks Rob- The resultant DBE image has massive blotches over it and is unusable. This remains even if I press the nuclear button, the undo nuclear and redo nuclear. Obviously a picture is worth a thousand words so I'll post one in a day or two (I'm presuming with Valentine's day I may be precocupied- here's hoping).

Thank you both.

[pfile]

the nuclear button is the STF auto-stretch i was referring to. most likely all that's happening is STF is way overstretching the image based on the new noise profile.

rob

[mschuster]

Nick, you might try Image > Screen Transfer Functions > Use 24-bit STF LUTs. This might solve the problem. On my tests, the background model image in particular sometimes appears to be posterized with normal STF, but this is just an normal STF quantization issue. 24-bit LUTs typically solves this type of problem. Occasionally 24-bit LUTs fixes display problems on processed integrations themselves. So this might be something to try.

An alternative to 24-bit LUTs is to simply apply the STF via HistogramTransformation, which uses a high precision algorithm and avoids this problem.

Mike

[Geoff]

Rob has it right. If you denoise and then autostretch you get a terrible looking image because of an overstretch. Nothing to do with dbe. Just try denoising and  then apply autostretch again before you do anything else—you will get a crappy looking picture.
Geoff

[mschuster]

Oh yes, running the script does not change the STF. So the result could look OK immediately after the script but then bad after a subsequent auto STF that overstretched.

[nm303]

Hi all and thanks for your inputs,

Tried the 24-bit STF- same poor image.
Tried the STF after MURE but before DBE and it all looks fine.
The below screenshot shows (left to right) all using the nuclear button (clicked several times, cancelled, clicked again :-) ).

Left is untouched, middle is post MURE, right is post MURE-DBE.
2nd screenshot is just zooms of the above.

It does seem partially alleviated if I ignore the nuclear result and do it manually with histogram transformation (screenshot 3). I'm not sure if it is maybe because I'm so used to moving the skyfog peak into the 33% across position and this maybe is not necessary now I have so little noise in the black. Is it because the script is so good I have to recalibrate my brain?

[nm303]

It's not letting me post the jpegs for some reason.

[nm303]

maybe a zip file will work??

[mschuster]

Ok, lossy jpgs add confusion. Can you post a zip containing the 3 xisf's and screen shot of the MureDenoise script settings? If zip too big, maybe a link to a zip in dropbox?

[nm303]

Yes, Sorry about that.
Here is a link. Thank you.

https://www.dropbox.com/s/2dp0s9l95x5zij4/red_MURE_DBE.zip?dl=0