Pattern in Integrated H-alpha image with Pixinsight

Minh Lết:
This is due to the interpolation algorithym in Star alginment module. You can change the interpolation method to b cubic spline or change the snapping threshold to fix this.

Interesting, I didn't know that the alignment could cause that. I will re-run the data tonight and see if that helps.

Thank you for your input!

And if you stack only 20-second frames or only 180-second frames, do you still have strips?

20 and 180 seconds with a ccd camera and narrow band filter seems rather short. Are you sure this isn't just the read pattern of your sensor? I'm not at my computer right now, so I can't check your files, but this would be my first guess. Have you had this issue before with the same settings, or is it just now?

cs, 

Wim

I had this same problem before.
It was solved by increasing the dither to a higher number of pixels.

Worth trying.

Marcel

Marcel Noordman:
I had this same problem before.
It was solved by increasing the dither to a higher number of pixels.

Worth trying.

Marcel

the problem was simple. It comes from the interpolation of star alignment process. The subpixel translations do not interpolate very well and create these artifacts. Solving this is either by adjusting the interpolation parameter. Dithering further (and reduce sub pixel translations) might help but it's not gurantteed, the best solution is still the software one.

for me it is a calibration issue. Did you take the lights with the same power source as your calibration frames? It may result strange but it would not be the first time I see this pattern due to a noise ripple introduced by a bad power brick

Daniel Carter:

Chris White- Overcast Observatory:
Looks like a dithering issue. Either insufficient dither scale or infrequent enough dithers. 

Interpolation artifacts generally produce a waffle pattern.

I dithered between every subframe. The lens is a 135 Canon lens so I'm wondering if the dither amount was enough movement. I had thought interpolation patterns looked more like a weave or waffle pattern like you mentioned. I'll try longer subframes to see if it is just part of the read noise. Since this was a camera lens at roughly f/3.3 I was taking only 180s exposures. I guess I am so used to CMOS cameras I didn't consider that CCD cameras need longer exposures.

I'll try the other solutions mentioned to see if I can salvage the data i currently have.

Was the lens wide open or stopped down?  I'm not familiar with your camera here, but if your lens is wide open I doubt signal is an issue.  What were your dither settings? 

I wonder if adding a max pedestal could help? 

@Neven Krcmarek trick with using the canon debanding script is a clever solution.

Hi
I faced the same problem when stacking narrow band data. In my case, I was stacking images shot before and after meridian, which caused a similar pattern to appear. To solve the problem, I just stacked them separately and then stacked the two resulting frames, and the banding dissappeared.

HTH

Carlos

Neven Krcmarek:
You still have some linear pattern banding on the far right but that's something you can fix with Linear Defect detection and Cosmetic Correction. This will help: https://www.youtube.com/watch?v=YCIi8uBaXNM

I was facing similar issues in Pixinsight, and, as @Neven Krcmarek  said, it was caused by "Linear Defect detection" option in PixInsight (my thread in CN):

In my case, after disabling this feature, all issues were gone

This kind of sinusoidal artifact that perfectly aligns with the with the sensor is most likely coming from the sensor itself—as a number of folks have said.  Using banding correction is an effective way to fix this problem as Neven demonstrated.

It is unlikely that this effect is caused by the interpolation algorithm.  Interpolation errors often happen with faint NB data.  When you work with very faint NB data, the signal level of the background can be quite low (particularly during new moon.) That means that when you do the flat correction, some pixels may be driven to have zero or negative values (after subtracting bias,) which PI clamps to zero. This can be caused by old bias data that may not provide sufficient offset to avoid having the data to cross into negative values when the flat correction calculation is done. Those zero values cause problems with the PI interpolation algorithm when you register the images. You'll know that you've run into this issue when you see a Moire pattern in the registered data. The problem is worse for images that require rotation and it looks like a 2D semi-rectangular or circular Moire pattern. The frequency of the Moire varies with the amount of rotation required. More rotation produces a higher spatial frequency pattern.

The fix for this type of problem is to add an offset to the calibrated data. If you look at the calibration dialog in PI, you'll see an option for "Output pedestal (DN)" under the "Output Files" tab. That's what that option does and that's why it's there. In this case, I had to add an additional 30 DN offset to the O3 and S2 signals to avoid this problem. Getting the offset adjusted to remove the zero pixel values completely fixes the problem. Just be sure to check the box to subtract the offsets when you stack the results. On possible side effect is that with an offset, the low-level statistical stacking filter can be affected and you may not reject data that would normally be tossed out. That may cause another side effect that seems to affect how local normalization data is computed. In that case, it may produce a very mottled background. Simply reverting to "additive with scaling" should solved that issue.

John

Here is a very simple solution:

Don't use bias frames in your integration !

I used to have similar background patterns in my images. I started doing integration without bias frames and it resoled it instantly! Have not taken any bias frames since.

I have however, continued to take Dark for Flats frames to calibrate my flats. These are different from bias frames.

François