Removing Noise from an Image

[BobinBend]

The attached image NGC 6543 (in JPG format) was taken under less than best conditions. Consequently it contains a lot of noise in the background (primarily red dots). I've attempted to use a number of noise reduction processes to remove the noise but to no success. I calibrated it with about 40 darks, 20 fresh flats, and 40 bias frames using DSS and PI's BatchProcessing script. Both produce similar noise issues. Is there a process in PI that can remove the red dots of noise without affecting the nebula? Or do I have to retake the image which I intend to do anyway.
Thanks for your suggestions, Bob

[kolec]

Try:

https://adamblockstudios.com/categories/Free_Content

Color blip removal

kolec

[ngc1535]

Hi Kolec,

Thanks for the recommendation!
The Blip Removal technique is more for isolated and scattered blips that are too numerous to otherwise deal with- but are not really a noise source- instead they are likely due to some calibration problem.
I think in this case though, the issue is a bit different. There really is a uniform noisiness to the image, mostly in red (but I think that is just happenstance).


I could not figure out if this was a monochrome or OSC chip. If it was the former, I would highly recommend MURE denoise on the combined channels before creating a color image.

Otherwise, it certainly can be the case this is an acquisition problem where the subexposures are simply not long enough to beat the read noise.  So... maybe  a longer exposure would help in addition to many more images (which again we do not have information on). Basically there isn't enough information in the original post to help quite yet.

-adam

[GJL]

You can weaken the noise, but you can't get rid of it, it's too dominant relative to the structures. I think the total exposure time is clearly too short. 
If there are R,G,B channels, denoise before ChannelCombinaton, as Adam said.
Otherwise my way: inverted Lum Mask to protect stars and nebulae, Curves Transformation and at R, possibly also S, decrease intensity.
Then denoise, e.g. MLT, k-sigma tresholding. It is important to preserve the weak fog structures. At the latest, however, if you set the background to a normal level, it will be difficult to display them clearly.
More exposure time!

Gerhard

[STEVE333]

Hi Bob - That is some nasty noise!

Because I live with fairly high LP I'm used to working with noise. When I used to process with Photoshop there were tutorials by Doug German, and, one of them was on what he called "Surface Blur Noise Reduction". It isn't noise reduction in the normal sense, but, more of a "smart black clipping" technique. However, it does actually remove noise. The tricky part is to remove the noise without removing the faint nebulosity associated with the target(s).

I've adapted the technique to implement it in PI. If you are interested I can post a before and after version of your image showing what this technique can do.

Steve

[BobinBend]

First of all thanks for all your inputs. I should have been more clear about the JPG file, which was converted from a raw stacked image for the purpose of posting it on this forum. Also I failed to mention that I took 41 lights at 300 sec exposures, which is about 3.4 hrs, so I'm thinking that the exposure time is long enough. (Let me know if I'm wrong in my thinking.)

I also took the images on June 3rd which was a new moon condition. The temperature that night was about 17C or 62F here in Bend OR, so it wasn't too warm. My image camera is a Canon 60D so it's an OSC chip. I know it's somewhat noisy but I've captured many good images before with a lot less noise.

Adam, I've never used the MURE Denoise script so I'll give it a try. Thanks
Kolec, I'll try the color blip removal tool you referred to. Thanks

Steve333 I'll send the raw stacked image and let you take a crack at it. I'm looking forward to what you will come up with. Thanks!

Bob

[STEVE333]

Steve333 I'll send the raw stacked image and let you take a crack at it. I'm looking forward to what you will come up with. Thanks!

Bob

Bob - I already downloaded your jpg image and worked on that. The Surface Blur Noise Reduction works on stretched images, so, I've attached the "noise reduced" image.

The process has removed a bit of the low-level nebulosity (the price to remove most of the noise), but, the noise has been significantly reduced/eliminated.

Steve

[ngc1535]

Unfortunately you will not be able to take advantage of MURE Denoise with the OSC.
Since I did not have the information on your data...I didn't know.

You might consider breaking the RGB image into it component channels and applying various noise reduction techniques.
This will allow you to apply a different degree (or even process) to the channels (say the red channel) as necessary.

It is curious that there is a red bias. It might be a different kind of issue dealing with your background neutralization (which I assume you did??).
A slightly biased background in one color will certainly show more "noise" since you will have a potentially raised pedestal brightness.

Regarding the exposure time- you will not do any harm by trying to double the exposure time. (There may be a good argument it will not help...but not harm).
41 averaged frames really should not give you that kind of pixelated noise (I think).

Finally using pixel math to identify the red pixels will certainly work ...but I still wonder if there is something else going on that is more fundamental that you might want to track down.

-adam

[BobinBend]

Steve,
Thanks for running this image through the Surface Blur noise reduction process. I haven't used this but will experiment with it.

Adam, Thanks for your additional input. I'll review my capture and preprocessing steps again to see if there's another culprit for the increased noise.

Bob

[STEVE333]

Steve,
Thanks for running this image through the Surface Blur noise reduction process. I haven't used this but will experiment with it.
Bob

You're welcome Bob. Below is a link to a previous post (in this forum) where the technique is explained.

https://pixinsight.com/forum/index.php?topic=11199.0

Hope it helps.

Steve

[BobinBend]

I thought I would take a closer look at my capture procedure and discovered (I should have caught this sooner) a Meridian flip about 30 subs into the capture sequences. Although all the images on both sides of the flip appeared to look ok both DSS or PI's BatchProcessing seemed to add a noise into the background of the image. I'm not sure why. When I used DSS to stack the largest set of images before the flip the background noise was greatly reduced. I then used PI to process the image through completion. I'm not satisfied with the image but the seeing and transparency conditions were far from ideal.
I've attached a copy of the final image.
Bob

[ngc1535]

I believe we have seen this problem before.
If your acquisition software automatically rotates your image after a flip...and you apply a dark frame it will not subtract properly.
Your images before and after flip should be *rotated* 180 degrees (unless you are using a rotator at the back of your telescope).
If you images appear in the same orientation post-flip (or you rotated them before dark subtraction)... the image is being rotated (by something) and when you run your calibration of darks- all software programs will give you the same poor results answer.
-adam

[STEVE333]

I believe we have seen this problem before.
If your acquisition software automatically rotates your image after a flip...and you apply a dark frame it will not subtract properly.
Your images before and after flip should be *rotated* 180 degrees (unless you are using a rotator at the back of your telescope).
If you images appear in the same orientation post-flip (or you rotated them before dark subtraction)... the image is being rotated (by something) and when you run your calibration of darks- all software programs will give you the same poor results answer.
-adam

Very clever Adam - so it is the acquisition software that is rotating the images! That explains everything.

Maybe there is a way to stop the acquisition software from automatically rotating the images after a flip. The stacking software will always rotate them, so, the rotation by the acquisition software is unnecessary. Of course the rotated images could be "un-rotated" manually, but, a bit of a bother.

Thanks for sharing the explanation.

Steve

[bulrichl]

I believe we have seen this problem before.
If your acquisition software automatically rotates your image after a flip...and you apply a dark frame it will not subtract properly.

This would be a strange and unexpected behavior of the acquisition software.

However, some DSLR cameras have the function to present an upright image depending on the rotation of the camera in the moment of releasing the exposure (0, 90, 180 or 270°). In PixInsight, it can be configured whether the output will be rotated accordingly or not ('RAW format preferences', option 'No image flip'). This option should always be enabled for the processing of astro images.

@Bob:
What camera did you use? If it's not a DSLR camera I would also like to know which acquisition software was used and whether you can turn off the rotation in that software.

Bernd

[BobinBend]

Adam, Interesting situation. Thanks for the explanation.

Bernd, I'm using a Canon 60D unmodified as my primary camera. Where in PI can I set the 'enabled' option for no image flip?
I'm using SGPro to capture the images and will have to check my settings. I did notice that 2/3s of my raw images where one way and after the flip the other 1/3 images were flipped 180 degrees.

I could manually flip the last third back then attempt to stack all of them to see what I get.
Bob