Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mschuster

Pages: [1] 2 3 ... 70
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:

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.

General / Re: impact of "negative" dark in the BPP script?
« on: 2020 January 08 21:54:20 »
It is easy to answer this question by running a test.

Create three frames bias, dark, and light using pixelmath "1024/65535", "990/65535", and say "2048/65535". That is, the same pixel value everywhere in each of the frames.

Then setup a ImageCalibration instance with the master frames and calibrate options set as you wish. Try various combinations and look at the resulting value in the light_c frame.

One more question, what about interpolation? I always leave it to Auto for image registration.

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.

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

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.

Wish List / Re: selection of MureDenoise script parameters
« on: 2020 January 02 19:11:03 »
Thank you Dmitry for your comments and suggestions. Unfortunately the script's current denoising technology is based on a limited noise model. If the noise statistics differ from the model, the results are undefined. In this situation (ie, the results of several of your processes) I know of no way to pick parameters to meet a desired criteria, other than basically what you are doing: trial, error, and subjective evaluation. I do have a plan to support LocalNormalization, beyond that however the situation remains an open problem.

Chris, I am sorry you are correct, MureDenoise does not work with CFA images (nor drizzle images for the same reason).


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.

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.

Looks great to me! Thanks!

Can you please broadly tell what this new parameter does actually ?

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.

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

  • 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.






Announcements / Re: Some unfair comments
« on: 2019 December 19 11:05:45 »
Anyway, I'm going to think on your advice of releasing public betas, or release candidate versions. This would probably increase the involvement of our users in PixInsight as a dynamic development project. I'll think on how to implement this.

Thanks Juan. If possible, please allow installation of candidate without removal of the prior working version. To allow for testing, yet still be able to easily switch to the prior version to get work done if necessary.

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.


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

General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 13:28:25 »
Thank you jlodge.

The two flat darks also appear to be scaled up by 16. This is good, as if any frame scaling is done, all frames should to be scaled likewise to avoid PI pre-processing havoc.

Given your flat and flat dark frames, MureDenoiseDetectorSettings report gain 0.061 e-/DN and Gaussian noise 27.71 DN. Both are what I would expect for this camera with 16x frame scaling. These are the values to use in MureDenoise as long as your light frames were also scaled 16x, which I am guessing is very likely.

Regarding why the update was downloaded and but not installed, I do not know.

*EDIT* I have managed to add it through feature scripts and pointing it at Pixinsight/src/scripts/mschuster. Should it not add itself automatically?

Yes, I think it should have been.

General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 12:22:50 »
Thank you Juan.

jlodge, those flats do appear to be scaled up by 16, as all pixel values are multiples of 16. Had they not been scaled up, measured gain would be 16 times larger, about 1 e-/DN (as expected for the camera).

If you cannot resolve your update problem (you need other 1.8.8-2 PI updates also), here is a link to the MureDenoiseDetectorSettings script. Here is how to install it manually:

Unzip to a folder
Script > Feature Scripts...
Select the folder

General / Re: MURE Denoise with ASI1600MM
« on: 2019 December 08 09:49:12 »
Those repositories are correct. I don't know why an auto update has not appeared.

I will post a link later today which you can apply manually.

Pages: [1] 2 3 ... 70