M81 & M82: decon problems and more

[ecuador]

Here is a stack of 125 x 32 sec exposures of M81 & M82 (along with a couple of NGC galaxies at the edges) taken at 500mm focal length (80mm ED doublet) from my light-polluted backyard through a CLS-CCD filter with a Canon 600D mod: https://drive.google.com/file/d/0B1c3jz ... sp=sharing. I can't get results I like with ST and have specific problems especially with the Decon module.
Binning made it worse, so since this is 125 frames at a low focal length, I instead tried just cropping around the two big galaxies without binning. The Decon module does bring out detail, however it fills the image with random little white speckles and oversharpens some stars that are not masked-out.
For the first issue (which also appeared in my binned full-frame attempt):

Before Decon

Screen Shot 2016-03-01 at 1.11.31 PM.png (250.07 KiB) Viewed 8691 times

After Decon

Screen Shot 2016-03-01 at 1.11.25 PM.png (358.62 KiB) Viewed 8691 times

As you can see, Decon brings out detail, but there are these white speckles. Also, the auto-mask does not find all stars and I could not find settings that could select all the stars and avoid the DSOs themselves.

Then, although I tried Wipe with aggressive settings I could not do better than this final result after final NR:

M81-125ST.jpg (425.32 KiB) Viewed 8691 times

Now, this result apart from the background glow/noise that I could not reduce more and the rather pastel colors also have some black dots appearing. Is that normal? I couldn't see how to remove them in final NR.

So, what can you guys do better with such an input? Are the white speckles of the Decon module a bug? At least in my case it prevented me from using it, while it could give good results.

[ecuador]

Hmm, I am also wondering whether saving from DSS as 16bit FITS (directly from stack of course, no changes on it) is not a good way to save my data. But the 32-bit TIFF file generated automatically (I like to keep it at TIFF since I can preview it easily) cannot open by StarTools directly (perhaps support could be added?). Here it is in any case: https://drive.google.com/file/d/0B1c3jz ... sp=sharing

[Burly]

What's your workflow process

[ecuador]

What's your workflow process

In the above example I think I did Autodev, crop, Wipe, Autodev, HDR, Contrast, Sharp, Finish with NR. I tried Decon after wipe or HDR if I remember correctly (and did not keep due to white speckles).

[admin]

Hi,

Firstly, I've been working hard to fix the white dot / speckle issue (see this thread). Could you give the latest version (1.4.315) and see if that solves this particular issue?

Second, if you find that decon "oversharpens" (which I take as the generation of ringing artifacts) smaller (which I take are stars that do not have an overexposed core) stars, then your setting for the radius parameter is too high.

Third, you should be able to remove the dark speckles by increasing the read noise compensation parameter in the denoise routine.

Finally, your data would stand to gain a lot by dithering (e.g. slightly moving the target) between frames; pattern noise is causing elongated streaky artifacts/noise areas (causing a fairly uneven background) along the direction of the sky's drift.

Hope this helps & let me know if this makes sense and solves your problems.

[ecuador]

Hi,

Firstly, I've been working hard to fix the white dot / speckle issue (see this thread). Could you give the latest version (1.4.315) and see if that solves this particular issue?

Second, if you find that decon "oversharpens" (which I take as the generation of ringing artifacts) smaller (which I take are stars that do not have an overexposed core) stars, then your setting for the radius parameter is too high.

Third, you should be able to remove the dark speckles by increasing the read noise compensation parameter in the denoise routine.

Finally, your data would stand to gain a lot by dithering (e.g. slightly moving the target) between frames; pattern noise is causing elongated streaky artifacts/noise areas (causing a fairly uneven background) along the direction of the sky's drift.

Hope this helps & let me know if this makes sense and solves your problems.

Thanks, I'll try your suggestions. I think I did try the read noise compensation without effect on the black dots, but I will try it again.
Although I don't think dithering applies here, it was an unguided session where the overall movement from the start to the end was perhaps a few dozen pixels, so it is "dithered" already, right? Anything else that you think might cause such artifacts? And you don't see a problem with the 16 bit FITS save compared to the 32 bit TIFF auto-save, right?

[admin]

Thanks, I'll try your suggestions. I think I did try the read noise compensation without effect on the black dots, but I will try it again.

You might want to use the latest alpha version (1.4.x) which has improved noise reduction routines.

Although I don't think dithering applies here, it was an unguided session where the overall movement from the start to the end was perhaps a few dozen pixels, so it is "dithered" already, right?

Actually, no. Dithering involves physically moving the camera (not waiting for the subject to move). Spiralling out is optimal, but just slight random movements will do as well. The idea is that you give different pixels on the sensor the chance to capture the same detail. Doing so, you start canceling out the inherent error in those sensor pixels. If you don't do that, such errors will show up as streaks like in your data.

And you don't see a problem with the 16 bit FITS save compared to the 32 bit TIFF auto-save, right?

You might be better off saving as 32-bit Integer FITS to be on the safe side. Especially when stacking many subs with faint detail and/or during high light pollution skies it can really start making a difference.

Hope this helps!

[ecuador]

First of all, today I tried the latest alpha and did not see the problems (white pixels) with the Decon module, so you might have fixed that

Actually, no. Dithering involves physically moving the camera (not waiting for the subject to move). Spiralling out is optimal, but just slight random movements will do as well. The idea is that you give different pixels on the sensor the chance to capture the same detail. Doing so, you start canceling out the inherent error in those sensor pixels. If you don't do that, such errors will show up as streaks like in your data.

Well, I meant tracking was not that good, so the camera (with telescope) was in fact moving compared to the target, so many pixels on the sensor got their chance with everything... It was not a spiral, but sort of an arc.
But I found the problem! In DSS's FITS/RAW settings there is a "Set the black point to 0" which is recommended when you use Bias. However, when I click on it the preview shows all my RAW files as pink, so I had it unchecked. And yet checking it gives me a stack without those weird vertical lines. I have no idea if it is supposed to work like that...

Also, a question. StarTools is supposed to open 32bit TIFF, right? And yet it does not open the ones that DSS automatically creates. Is that normal?

[admin]

First of all, today I tried the latest alpha and did not see the problems (white pixels) with the Decon module, so you might have fixed that

Yes, I really hope so - it came back from the dead one more time (like very good/bad horror movie), but then I slayed the bug for good.

Actually, no. Dithering involves physically moving the camera (not waiting for the subject to move). Spiralling out is optimal, but just slight random movements will do as well. The idea is that you give different pixels on the sensor the chance to capture the same detail. Doing so, you start canceling out the inherent error in those sensor pixels. If you don't do that, such errors will show up as streaks like in your data.

Well, I meant tracking was not that good, so the camera (with telescope) was in fact moving compared to the target, so many pixels on the sensor got their chance with everything... It was not a spiral, but sort of an arc.

It will still show unfortunately, as long as each frame left off where the previous frame finished.

But I found the problem! In DSS's FITS/RAW settings there is a "Set the black point to 0" which is recommended when you use Bias. However, when I click on it the preview shows all my RAW files as pink, so I had it unchecked. And yet checking it gives me a stack without those weird vertical lines. I have no idea if it is supposed to work like that...

Glad you found the cause! DSS can be a mystery unfortunately...

Also, a question. StarTools is supposed to open 32bit TIFF, right? And yet it does not open the ones that DSS automatically creates. Is that normal?

StarTools should be able to open 32-bit TIFFs provided they're not compressed (DSS used a funky type of compression that was only available in libTIFF-based applications - I'm not sure if that is still the case...). That said, 32-bit integer FITS files are your best bet.

[ecuador]

Oh, one last question. DSS instructions warn us that we need one of the two background calibration options if we want to use sigma kappa clipping. But StarTools instructions warn against using background calibration. So, are you recommending we stay away from sigma kappa clipping?