Mure Denoise Settings

[rdryfoos]

I Love Mure Denoise!!!  But I am unsure of the noise estimate number.  I used 2 darks in the Noise estimator (can use 2 biases or 2 darks) and it came up with an estimate of 27.43.  Out of 33 darks, no matter which 2 I chose, I got the same estimate. Since I used the same darks for all of the subs in the image--I used 27.43 for the noise estimation for all stacks.  Is this reasonable?  Is it possible to have a noise setting too low and run Mure twice?  or Also, if nearest neighbor is not used in star alignment, one is supposed to get the noise from the star alignment noise estimation log and use that in the setting where nearest neighbor is input.  Where is this log?  Nd how is it used?  Its of interest that nearest neighbor is the less accurate way of aligning so is it better to use Auto and use the value from the alignment log? 

Mure Denoise has worked wonders for my images--but sometimes there are artifacts, and I am never quite sure I have the noise estimate correct.  Overdoing it is just as bad as not using it so I really want to get it right.  Any one know?

Thanks,
Rodd

[mschuster]

Hi Rodd,

Thank you.

To estimate Gaussian noise, I recommend the DarkBiasNoiseEstimator script. Open two good darks or two good biases, and run the script. If you use darks, the noise estimate will include dark current noise, otherwise not. Usually dark current noise is small, and so using biases is typically fine.

As a sanity check for your noise estimate, take the read noise value in e- from the camera manufacture, divide this value by gain in e-/DN, you should get a value similar to your noise estimate in DN. This sanity check accounts for read noise but not dark current noise.

Never use noise estimates obtained from a single frame, as those estimates will include pattern noise, which is removed during calibration.

Never run MureDenoise twice.

Artifacts in the denoised result may be due to several things. Read the requirements in the documentation. Your Gaussian noise estimate could be too high. The Gain estimate could be too low. Or the frame might have been processed or otherwise violate the requirements.

Thanks,
Mike

PS Gaussian noise is not affected by star alignment method (don't use related noise estimates, I don't think there are any anyway). But whatever alignment method you choose, just be sure to enter the chosen method in MureDenoise. If you choose Auto, look in the console log for the actual method used by the alignment process and use that.

[rdryfoos]

Hi Rodd,

Thank you.

To estimate Gaussian noise, I recommend the DarkBiasNoiseEstimator script. Open two good darks or two good biases, and run the script. If you use darks, the noise estimate will include dark current noise, otherwise not. Usually dark current noise is small, and so using biases is typically fine.

As a sanity check for your noise estimate, take the read noise value in e- from the camera manufacture, divide this value by gain in e-/DN, you should get a value similar to your noise estimate in DN. This sanity check accounts for read noise but not dark current noise.

Never use noise estimates obtained from a single frame, as those estimates will include pattern noise, which is removed during calibration.

Never run MureDenoise twice.

Artifacts in the denoised result may be due to several things. Read the requirements in the documentation. Your Gaussian noise estimate could be too high. The Gain estimate could be too low. Or the frame might have been processed or otherwise violate the requirements.

Thanks,
Mike

PS Gaussian noise is not affected by star alignment method (don't use related noise estimates, I don't think there are any anyway). But whatever alignment method you choose, just be sure to enter the chosen method in MureDenoise. If you choose Auto, look in the console log for the actual method used by the alignment process and use that.

  Thanks--where is the console log?  I did not know where to look for this.  I do not have a problem with aligning with nearest neighbor method, but I read somewhere that this was the least accurate alignment method.  Is that true?

[mschuster]

Console log - just the scrolling list of output you see in the Process Console View. The interpolation method used will be listed.

I like nearest neighbor for my undersampled setup for ~20 or more dithered subs. Avoids loss of FWHM, avoids ringing artifacts, avoids blurring, avoids noise covariance, and negligible aliasing as long as there are enough dithered subs.

Mike

[rdryfoos]

Console log - just the scrolling list of output you see in the Process Console View. The interpolation method used will be listed.

I like nearest neighbor for my undersampled setup for ~20 or more subs. Avoids loss of FWHM, avoids ringing artifacts, avoids blurring, avoids noise covariance, and negligible aliasing as long as there are enough subs.

Mike

  I try to read the log but it dissapears to fast.  How can I go back to that read the info?  Also--how about for 15 or so subs.  Presently I am making a mosaic with 30 min subs and 15 subs is 7.5 hours per filter per panel--enough.  What alignment would you use--keep in mind I am using Mure Denoise so maybe Nearest Neighbor IS nest?  By the way--The PI method of stitching mosaics is GREAT!!!  First one tried and there is no line visible at all.  Just need clear sky to finish!

[mschuster]

Set Edit > Global Preferences > Miscellaneous Process Settings > Maximum number of console lines to 1000. You should then be able to scroll through previous lines.

Use whatever alignment method looks best to you, as long as it is one of the ones supported by the denoiser, it will work OK. Be sure to set the method used and the # of frames correctly. If those are wrong you probably won't get good results.

Mike

[rdryfoos]

Set Edit > Global Preferences > Miscellaneous Process Settings > Maximum number of console lines to 1000. You should then be able to scroll through previous lines.

Use whatever alignment method looks best to you, as long as it is one of the ones supported by the denoiser, it will work OK. Be sure to set the method used and the # of frames correctly. If those are wrong you probably won't get good results.

Mike

  Thanks--I will give it a try. 

[jerryyyyy]

Hi,

Found this is a very useful post and thought I would add a couple questions.  I am working on a project involving M67 and have 74 HA and 91 O-III images in addition to 20 each RGB for stars.  The HA comes out well and we realize the O-III is a weaker signal but are managing to just see the outer ring (3rd one). Mure definitely helps and I have appreciated that the stacking uses Lanczros 3 from thge auto setting of BPP.  I assume there is a reason BPP decides to use this.  My images are WEIGHTed in subframe selector. 

I also noted watching the BPP run that the noise levels for the individual frames runs 7-8 e-04.  Does this relate in any way to the Gaussian Noise setting?  I am running an STT 8300M and in the past we have used 30.36.  Gain is 0.4.

This all reminds me I need to change out those Baader filters for Astrodons.... 

[mschuster]

I also noted watching the BPP run that the noise levels for the individual frames runs 7-8 e-04.  Does this relate in any way to the Gaussian Noise setting?

No. Use DarkBiasNoiseEstimator script. BPP noise typically is too large. 7-8 e-04 corresponds to a noise of about 20 e- (using 0.4 e-/DN gain). That's way too big as a detector read noise estimate.

Regards,
Mike

[jerryyyyy]

Thanks for the help.  I have used that other methods, hard to figure out the exact settings.  Seems a bit of trial and error for fine tuning. 

[Pompey Monkey]

Hi,

Found this is a very useful post and thought I would add a couple questions.  I am working on a project involving M67 and have 74 HA and 91 O-III images in addition to 20 each RGB for stars.  The HA comes out well and we realize the O-III is a weaker signal but are managing to just see the outer ring (3rd one). Mure definitely helps and I have appreciated that the stacking uses Lanczros 3 from thge auto setting of BPP.  I assume there is a reason BPP decides to use this.  My images are WEIGHTed in subframe selector. 

I also noted watching the BPP run that the noise levels for the individual frames runs 7-8 e-04.  Does this relate in any way to the Gaussian Noise setting?  I am running an STT 8300M and in the past we have used 30.36.  Gain is 0.4.

This all reminds me I need to change out those Baader filters for Astrodons....

Apologies for resurrecting the dead:

Normalising the noise estimate to the range of the sensor gives me very good results every time. .

I.e. multiplying the integration Gaussian noise estimate (or that from the noise estimate script) by the discretisation level of the sensor.

E.g. 1.1798e-04 (noise) *2^16 (16 bit sensor) = 7.73 DN

This number varies for each integration.

[mschuster]

Pompey Monkey, if what you say works, OK, but not something I recommend.

Noise measurements of lights usually include contributions from shot noise and detector noise, both present in exposed pixels. Moreover, in a properly exposed wideband light (ie sky limited) the noise is in fact dominated by shot noise, detector noise is effectively buried in all pixels.

MureDenoise's detector Gaussian noise parameter is designed to specify detector noise. Shot noise contributions in lights are estimated via the detector gain parameter.

To find Gaussian noise, I recommend the DarkBiasNoiseEstimator script. You supply two biases or two darks. The script uses robust methods to estimate Gaussian noise, for example, cosmic rays in darks are effectively rejected from the results. This script works well for binned frames also.

Example: For my 40 min 3nm Ha exposures (not sky limited, so detector noise contributes significantly in dim areas), I use matching 40 min darks. These darks contain dark current noise, something which detector read noise specifications normaly exclude. DarkBiasNoiseEstimator gives a reasonable way of estimating the total detector Gaussian noise.