New script for denoising linear monochannel images

[mschuster]

Hi Jim,

Thanks for posting! Here are my thoughts: I would expect for the F16M a gain of ~1.5 e-/DN and a Gaussian noise ~7 DN assuming a read noise of ~10 e-. In general, if you see denoising artifacts like these, the cause may be one or more of these setting problems: gain is too low, Gaussian noise is too high, variance scale is too high. Any of these things can (will) cause the script to overestimate noise. If possible, please post fits/xisf of integration, two darks, two biases, and the ImageIntegration log in dropbox and I will investigate further.

Thanks,
Mike

[chris.bailey]

Jim

Just a thought but are those images cropped with any sort of rotation applied to the crop selection?

Chris

[jkmorse]

Mike & Chris,

No, just straight clips, no rotation.

Let me do some further testing before I send you samples, Mike.  Based on your note, it looks like I still may have the Gaussian noise set too high at 10 and need to test at ~7.  I also want to retest using two bias frames rather than the dark frames.

I will report back.

Best,

Jim 

[jkmorse]

Mike,

I have a side question about how scripts work generally.  Unlike regular process tools, when the script is open you lose the ability to manipulate other controls.  For example, when doing testing with Mure on a preview, I cannot use the undo button and instead have to close Mure, hit undo and then reopen the script.  This is not limited to Mure but seems to happen across the board (for example I see the same thing with SHO_AIP). 

Is there something fundamental to the difference between processes and scripts that causes that?

Thanks,

Jim 

[mschuster]

Unlike regular process tools, when the script is open you lose the ability to manipulate other controls. ... Is there something fundamental to the difference between processes and scripts that causes that?

Yes, this modal nature is expected for scripts. The PixInsight scripting environment prevents access to other controls when a script dialog is open.

Also, andor.com lists F16M read noise at 22e-. This is ~2x higher that I expected, and also ~2x higher that other 16803 vendors claim. Maybe this includes noise from anti-RBI IR preflash?

Thanks,
Mike

[jkmorse]

Mike,

I suspect but don't know that its a bust in the Andor/Apogee publication.  Not the first time I have seen that.  Following your advice I dropped the  Gaussian Noise and found the sweet spot for my F16M at 0.8.  I combined that with variance scale of 0.85 to get my best results, however to optimize the noise reduction I had to drop my gain from 1.5 to 0.8.  That produced superb results without any loss of detail or blockiness (I just made up a new word  ).  All in all, I am more than happy to accommodate numbers that don't seem to add up when I get these kinds of results  .

Now, having seen that your tool is supremely versatile, I am going to play with it on a drizzle integrated image.  Ya just never know until you try.  I will obviously report back.

Best,

Jim

[Tromat]

Hi,

the script works very nice on CFA images but the problem is that it requires a lot of work and the result is not ok.
I'm using a DSLR and tried to split the raw files with SplitCFA so I have splitted darks, flats, biases and light, then I made all the preprocessing for each CFA list of files (4 of them so). On the stellar registration part I used the same original image so the bayer array is at the right position.
I then merged the 4 integrations to get the final color picture but there's many bayer artifacts. I tried the script on each CFA image, it works nice, but as the merging leaves many artefacts it's not usable :/

Did I make something wrong or the script cannot be used on DSLR pictures ?

Here's what it looks like on the merge image (2:1 ratio).

[mschuster]

Did I make something wrong or the script cannot be used on DSLR pictures ?

Hi Tromat,

Thank you for posting. DSLR denoising should be possible, but remains untested. I may have overlooked a big issue that prevents the script's use.

I would suggest trying your entire workflow without denoising to see if you can recover a good image. If not, then a workflow problem or maybe this separate channel calibration, registration, and integration workflow is flawed and simply cannot work. If so, then some unforeseen problem prevents separate channel denoising from working properly. I wish I could say more but I don't have any experience with DLSR.

Thanks,
Mike

[pengsloth]

I just used this process last night for a set of DSLR (caon 6d) images. After registering the files I split the image into RGB and then did the process over each of them and then put them back together. It worked really well I think.

[pfile]

right - that seems like the right place to do the split, after the master is made, rather than up front before calibration...

rob

[mschuster]

Rob and pengsloth, thank you for this information.

The new MureDenoise Version 1.10 is available in the head post.

The denoising quality is improved on average combinations. The improvement follows from a better covariance hypothesis that compensates for the correlation introduced by the registration process.

Thanks,
Mike

[Tromat]

I would suggest trying your entire workflow without denoising to see if you can recover a good image.

The whole workflow doesn't really work actually, that's the point, the resulting picture suffers of bayer artifacts even without noise reduction.

After registering the files I split the image into RGB and then did the process over each of them and then put them back together. It worked really well I think.

The problem is that each channel is "corrupted" by the interpolation, it doesn't seems to be the most clean way to denoise. I should try with Bayerdrizzled images.

[mschuster]

Hi Tromat,

You are correct on both points. I apologize for my mistake in suggesting an OSC workflow that does not work.

MureDenoise does not support DLSR and OSC detectors, neither traditional debayer nor bayer drizzle. There is no workaround. MureDenoise lacks a model for the interpolation involved.

Thanks,
Mike

Update: I will modify the head post to indicate this limitation shortly. The script documentation will be updated on the next release.

[pfile]

superpixel debayering should be an option for OSC, i don't see why not.

rob

[mschuster]

superpixel debayering should be an option for OSC, i don't see why not.

Yet another form of interpolation not properly modeled by the script. I am working on monocolor detector drizzle support, maybe 50/50 chance of it working out. If this does work then maybe bayer drizzle support is possible. Don't know yet. On the other hand, for traditional debayer support, little chance, not working on it.

Thanks,
Mike