Strange 'waffle' pattern in the blue channel - Forums

Topic starter

Jun 10, 2023

Hi,

I'm getting this strange pattern when I stretch my stacked image, but only in the blue channel. The red and the green seem fine.

The camera is a ZWO ASI533MM Pro cooled to -10 degrees.

This is the result of a stack of 10 images, each of 300 seconds with the gain set to 300. The stacking was done in Siril where I also did Background Extraction and Photometric Colour Calibration.

The pattern emerges when I start doing Histogram Stretch and Asinh Transformation.

Any ideas what this is?? Why is it only showing in the Blue??

cheers

Jeremy

Well Written Engaging

Brian Puhl

IOTD Staff

Jun 10, 2023 · Edited: Jun 10, 2023

This typically happens when there is rotation between the image channels during the stacking process and not enough integration time. I can't explain it any better. I think it has something to do with ransac.

It's happened to me once, only because I rotated. Once I knew not to do that, it's never happened again.

andrea tasselli

Frequent contributor

Jun 10, 2023

Newtonian interference fringes (?)

Jeremy Taylor

Topic starter

Jun 10, 2023

I forgot to mention the scope used (mainly because I can't see how it is relvant, given that this is only appearing in the blue channel, the red and green are fine).

It's a Meade 8" SCT.

The rotation is an interesting idea. But the camera/scope wasn't moved during the session and this is the second image that has shown this problem from different nights.

This is just the blue channel from the combined rgb which I used Siril to combine.

I am wondering if this is something about the sensor and the blue wavelengths. The blue subs are much noisier than the red and green.

Maybe I should take the blue stack and stretch that on its own to see if the noise is there….

Helpful Insightful Respectful Engaging

Jeremy Taylor

Topic starter

Jun 10, 2023

Yeah, I have now checked the original Blue FIT file and stretched it and the noise is not there.

Nor is it in the colors_00001.fit file (which is the blue channel when using the RGB_Composition script in Siril)

But it is in the r_colors_00001.fit file which is after Siril has rotated and registered the three colours.

So Siril's registration process seems to be introducing this noise pattern.

Are there any other ways to combine RGB fit files that I can try instead?

Well Written Concise

Brian Puhl

IOTD Staff

Jun 10, 2023

Jeremy Taylor:
I forgot to mention the scope used (mainly because I can't see how it is relvant, given that this is only appearing in the blue channel, the red and green are fine).

It's a Meade 8" SCT.

The rotation is an interesting idea. But the camera/scope wasn't moved during the session and this is the second image that has shown this problem from different nights.

This is just the blue channel from the combined rgb which I used Siril to combine.

I am wondering if this is something about the sensor and the blue wavelengths. The blue subs are much noisier than the red and green.

Maybe I should take the blue stack and stretch that on its own to see if the noise is there....

The data is properly calibrated with flats and bias correct? Let's rule that out. Maybe try stacking without.

I'm sure/hoping someone else will pipe in here soon though.

Jeremy Taylor

Topic starter

Jun 10, 2023

Yeah - flats, darks and biases all applied in the Siril stacking process.
What seems to be adding the noise is when I take the R, G and B final images and use the Siril RGB_Composition script. This script is great because it registeres the three images nicely, which I've found to be a real pain to do manually!

But it seems to be adding this noise….

andrea tasselli

Frequent contributor

Jun 10, 2023

I'm sure/hoping someone else will pipe in here soon though.

I did. Its interference fringes, slight wedge in the filters can lead to that.

Brian Puhl

IOTD Staff

Jun 10, 2023

Jeremy Taylor:
Yeah - flats, darks and biases all applied in the Siril stacking process.
What seems to be adding the noise is when I take the R, G and B final images and use the Siril RGB_Composition script. This script is great because it registeres the three images nicely, which I've found to be a real pain to do manually!

But it seems to be adding this noise....

I'm a pix guy, I know nothing of siril, does siril align the channels for you during stacking? If not, this may be where things are going wrong.

Jeremy Taylor

Topic starter

Jun 10, 2023

In Siril I align and stack each channel separately so that I end up with three file R, G and B. These are not aligned with each other at this point.
The Siril "RGB_Composition" script then uses the same registration and alignment algorithms to align the R,G and B and produce the single RGB.fit.

It is this shift/rotate that seems to be introducing the pattern.

So - are there any other programs I can use to align the R, G and B images?
DSS can align them if I hit the 'Register Checked Images', but there doesn't seem to be a way to save each rotated/shifted image as a new file - although it happily tells me the offsets and rotations it has calculated.

If I can just get the three aligned/rotated then I can use Siril to combine them and hopefully it will find that there is no rotation/shift needed - and therefore no noisy pattern (I hope!).

Helpful

Brian Puhl

IOTD Staff

Jun 10, 2023 · Edited: Jun 10, 2023

Jeremy Taylor:
In Siril I align and stack each channel separately so that I end up with three file R, G and B. These are not aligned with each other at this point.
The Siril "RGB_Composition" script then uses the same registration and alignment algorithms to align the R,G and B and produce the single RGB.fit.

It is this shift/rotate that seems to be introducing the pattern.

So - are there any other programs I can use to align the R, G and B images?
DSS can align them if I hit the 'Register Checked Images', but there doesn't seem to be a way to save each rotated/shifted image as a new file - although it happily tells me the offsets and rotations it has calculated.

If I can just get the three aligned/rotated then I can use Siril to combine them and hopefully it will find that there is no rotation/shift needed - and therefore no noisy pattern (I hope!).

In DSS you can right click, select reference frame after you've registered your images. Pick the frame with the best score (which channel doesn't really matter) Put each filter in it's own tab with it's calibration frames. You will stack each channel separately under the tabs, but each channel will be aligned to the reference frame. It's worth a shot.

I still think there's some rotation or distortion between the channels, you may not notice it, if you had pixinsight, I'd say blink the frames. I don't know if that's an option for siril.

Joe Linington

Jun 10, 2023

You can do an alignement while stacking if you modify your script (or do some manual steps). What I sometimes do is take all of the calibrated lights (pp_lights) and put them in folders by colour, chose a green or Ha if NB frame to use as a reference and place that one file in each folder. In each channel, generate the new sequence, open the list of images, choose the ref frame as the reference and then perform the registration. All of the subs will now align with the green ref frame. Go back into the frame selector, deselect the ref frame and then stack. It helps to rename the ref frame 001….. before creating the sequence so that it is always the first frame in the r_pp_lights stack. This should get the alignment pretty bang on and more than close enough to tweak the alignment in the RGB_comb tool.

Helpful

Yungshih Lee

Jun 10, 2023

A similar situation happened to me before although I am not sure if it's the same cause. This type of pattern can happen when your lights are being over-corrected by the flats, meaning the calibration process removed too much value by the flats and cause negative values on your light frames, and those will show as dark patches.

The fix is to add pedestal value before calibration. In PixInsight you can add it in WBPP. I am not familiar with Siril but perhaps there is somewhere to put it? The value (I typically use 200 DN, I believe Adam Block suggested 400 or so) is to give it enough extras to prevent negative values from happening. This usually happens on narrowband images, but the light frame you show seems to have a very low SNR and that may have contributed to it.

I think, and I am just guessing here, if you stack more lights or use longer exposure for each frame to raise the SNR, this issue may go away. (BTW, if you are using a color camera, the blue channel is normally the weakest in the signal.)

Helpful Insightful Respectful Engaging Supportive

Jeremy Taylor

Topic starter

Jun 10, 2023

Thanks for the tip, Yungshih.

It's a mono camera but yes, I have noticed the blue channel is always the weakest.

I don't think it can be due to over correction from the flats though, as the stacked blue channel doesn't show the problem. Only after alignment for RGB combination does it appear.

Well Written

John Dziuba

IOTD Staff

Jun 10, 2023

Hi. Yungshih is correct above in his assement. I am guessing that you are in a nice dark sky location with little sky glow? Adding a pedestal in preprocessing will solve the issue. In Pixinsight I would start with a value of 400. I am not familiar with your software.

CS JD

Taras_M

Jun 10, 2023

As already mentioned, it must be overcorrecting, that makes your subs with negative pixel's value. Add a pedestal and it goes away

GalacticRAVE

Jun 10, 2023

These Moiré patterns are typically occur during registration of slightly rotated frames with noisy data. It is an artefact of the interpolation routine used in registration. work arounds are to play with the interpolation formula or to dither your data (with n=1 when you are already well sampled). Matthias

Helpful Insightful Concise

Jeremy Taylor

Topic starter

Jun 10, 2023

As already mentioned, it must be overcorrecting, that makes your subs with negative pixel's value. Add a pedestal and it goes away

***

Thanks for the advice, but I don't think this is the problem as the stacked blue channel image does not have the problem. It only appears when the final blue image is rotated ready to be combined with the red and green.

Well Written

Brian Puhl

IOTD Staff

Jun 10, 2023

I was thinking about it. A subtle rotation could be caused by poor polar alignment. Something to keep in mind.

Jeremy Taylor

Topic starter

Jun 10, 2023

John Dziuba:
Hi. Yungshih is correct above in his assement. I am guessing that you are in a nice dark sky location with little sky glow? Adding a pedestal in preprocessing will solve the issue. In Pixinsight I would start with a value of 400. I am not familiar with your software.

CS JD

***
Not dark at all. I'm in London!

It's not flats over correction because the stacked, corrected image doesn't have the issue. It's only when it gets rotated to register with the red and green that the pattern emerges.

Jeremy Taylor

Topic starter

Jun 10, 2023

Joe Linington:
You can do an alignement while stacking if you modify your script (or do some manual steps). What I sometimes do is take all of the calibrated lights (pp_lights) and put them in folders by colour, chose a green or Ha if NB frame to use as a reference and place that one file in each folder. In each channel, generate the new sequence, open the list of images, choose the ref frame as the reference and then perform the registration. All of the subs will now align with the green ref frame. Go back into the frame selector, deselect the ref frame and then stack. It helps to rename the ref frame 001….. before creating the sequence so that it is always the first frame in the r_pp_lights stack. This should get the alignment pretty bang on and more than close enough to tweak the alignment in the RGB_comb tool.

***
Wow, complicated! But I get the idea....very clever.

I'll give it a try.

Thanks

Joe Linington

Jun 10, 2023

Jeremy Taylor:
Joe Linington:
You can do an alignement while stacking if you modify your script (or do some manual steps). What I sometimes do is take all of the calibrated lights (pp_lights) and put them in folders by colour, chose a green or Ha if NB frame to use as a reference and place that one file in each folder. In each channel, generate the new sequence, open the list of images, choose the ref frame as the reference and then perform the registration. All of the subs will now align with the green ref frame. Go back into the frame selector, deselect the ref frame and then stack. It helps to rename the ref frame 001….. before creating the sequence so that it is always the first frame in the r_pp_lights stack. This should get the alignment pretty bang on and more than close enough to tweak the alignment in the RGB_comb tool.

***
Wow, complicated! But I get the idea....very clever.

I'll give it a try.

Thanks

I have found that as I try more advanced things with Siril, I use a script to get corrected lights and then manipulate the data manually. Siril has a lot of capability that isn’t fully utilized.

Anne-Maree McComb

Jun 11, 2023 · Edited: Jun 11, 2023

I've had this problem with a lot of my images over the past 12 months or so with the ZWOASI1600mm and my 250mm reflector. Before that time, I never had an issue. I searched high and low for answers and eventually managed to fix the problem after reading somebody's comment about the background not being dark enough, or too light ?? (or something like that). The suggestion, and in my case, the resolution, was to add "output pedestal settings" Literal Value = 1 in weighted batch pre processing script in pixinisight. I recall that the suggestion was to use a literal value of 100 but I find 1 works beautifully. I would bet that if you severely stretched your red and green that they would have a similar problem. Some of my images that I thought looked ok were also suffering from this as well. I also wonder if its something to do with offset in the first place, although I have used the same settings for the past 4 years. Unfortunately I don't know anything about Siril.

Helpful

Chris White- Overcast Observatory

Jun 11, 2023

I didn't read through so maybe you have already figured it out.

This is likely am interpolation artifact from registration.

Not sure what software you use, but try an alternate registration algorithm.

For example, in PI if you get this using lanczos-5, a slightly less sharp algorithm like cubic b spline won't show it.

Helpful Concise

Victor Van Puyenbroeck

Jun 11, 2023

To me this also looks like an interpolation artefact after a very small rotation. Right now you are aligning (and interpolating) data twice; once for each filter stack, and then again to register all 3 stacks to each other.

Instead of registering the stacks from each filter to each other, try registering subs from all your filters to a single reference frame first, and then stack each channel separately.

This is the default method in many programs such as DSS and PixInsight WBPP. Which Siril script are you using for preprocessing the mono data?

Well Written Helpful Insightful Concise