3.58
#...
·
·
1
like
|
|---|
|
Okay...I have run into a wall and I cannot figure out why I am getting these bands in my integrated h-alpha light. It is not showing up on my broadband images - just my h-alpha. I have a sample posted below with and without stars. I think it has to do with the calibration but I am not 100% certain. I have re-taken flats and darks and I still run into this issue. I am using WBPP with the defaults on registration and integration. I have tried different methods of registration and integration but the pattern is still present. This leads me to believe it has to do with the calibration. Any help would be appreciated. Here is a link to Dropbox (Dropbox Link) with the master bias, dark and flat and the full size integrated file. Images were taken with a STL-11000M CCD camera. I am stacking 20-180s H-alpha images. I've added 20 more and I still get the same pattern. I see some of that banding in the subframes which is another reason I think the calibration is not taking care of it and making it more prominent.   |
2.11
#...
·
·
3
likes
|
|---|
| 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. |
|
3.58
#...
·
·
1
like
|
|---|
Minh Lết: 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! |
|
2.11
#...
·
·
2
likes
|
|---|
Daniel Carter:Minh Lết: It's not the alignment it self but the interpolation that done to the images after alignment that cause these patterns. |
0.00
#...
·
|
|---|
| And if you stack only 20-second frames or only 180-second frames, do you still have strips? |
0.00
#...
·
·
2
likes
|
|---|
|
There is a fix you can Apply. Rotate the image so the pattern is horizontal. Then go to Scripts/Utilities/CanonBandingReduction and apply default options. As you see below I've edited your Ha image. Of course use ABE/DBE before or after because you might have problems with the gradient around the nebula. 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  |
1.91
#...
·
·
1
like
|
|---|
|
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 |
1.81
#...
·
|
|---|
|
Do you Dither? This seems like something that Dithering might eliminate. |
0.00
#...
·
·
1
like
|
|---|
|
I had this same problem before. It was solved by increasing the dither to a higher number of pixels. Worth trying. Marcel |
0.90
#...
·
·
1
like
|
|---|
|
Hello ! Examinating the data, I agree with other people. This pattern is actually part of your data; it's due to the sensor. You didn't miss anything in WBPP. The CanonBandingReduction script does un pretty good job; plus you can use the "Normalize" option when you do the DBE. Finally, keep in mind that you won't probably display the image as bright and that's why, when you'll stretch your data, you'll naturally reduce the visibility of this pattern. (Parts that will be tricky is where your signal is really close the background.) Hope this help; can't wait for your final result  |
|
2.11
#...
·
|
|---|
Marcel Noordman: 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. |
20.43
#...
·
|
|---|
|
Looks like a dithering issue. Either insufficient dither scale or infrequent enough dithers. Interpolation artifacts generally produce a waffle pattern. |
1.43
#...
·
|
|---|
| 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 |
|
3.58
#...
·
|
|---|
Chris White- Overcast Observatory: 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. |
|
20.43
#...
·
|
|---|
Daniel Carter:Chris White- Overcast Observatory: 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. |
|
3.58
#...
·
|
|---|
| @Chris White- Overcast Observatory, it is a Sigma 135mm f/1.8 that has stop down rings that bring it down to about f/3.3. It is located in Australia and I'm renting a setup that happened to have this lens and camera in a tandem arrangement. If I recall, the dither was set to be 20 pixels in NINA. I did try a max pedastal with several values but it didn't appear to be helping. I will try increasing the value to something very high to see if it will fix the problem and then i could adjust down accordingly. I am using the H-alpha to add to an RGB image so if i cant get it worked out it wont be a complete waste. I still have all of the RGB data and it looks really good. It is only the H-alpha data that is generating the pattern. I am definitely going to check out @Neven Krcmarek solution. I agree...that is something i dont think I would have figured out on my own. I am spoiled by CMOS sensors. CCD cameras are work horses and will create some great images but i have had more issues working with data from the 8300 on the main scope and now this data from the STL11000M! |
0.00
#...
·
|
|---|
|
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 |
|
0.00
#...
·
·
1
like
|
|---|
Daniel Carter: I had some data from the same camera, and all RGB master lights plus LUM were having the same issue. (120s exp). Interpolation change didn't help the outcome so I remembered that Canon had similar patterns so one thing led to another and Canon banding script helped a lot. |
0.00
#...
·
·
2
likes
|
|---|
Neven Krcmarek: 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  |
|
0.00
#...
·
·
1
like
|
|---|
David Ávila: Yes, I think that option is turned off by default because it's reserved only for CCD cameras. But sometimes it does not get rid of all defects so PI has additional options to get rid of that nasty ones. Scripts/PatternCorrection/LinearDefectDetection and LinearDefetcSubstraction and you can use the defect map in CosmicCorrection. That's how the guy from the YT video was able to get rid of the lines. |
22.40
#...
·
·
4
likes
|
|---|
|
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 |
8.78
#...
·
·
2
likes
|
|---|
| John actually beat me to it... the first thing I'd do with something like this is add 100 to the pedestal. If it's a correction/calibration or bias subtraction issue, it should likely go away. If it's actually in the data, it should stay. |
1.91
#...
·
|
|---|
|
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 |
15.85
#...
·
|
|---|
Minh Lết: I just wanted to say thank you for posting this! I had a little bit of banding on a couple images, both NB and BB images, and this change fixed my issue! I also tested this in APP, and it worked as well! The BB data still had a very little left, but it definitely helped. I don't know why it wouldn't work as well in my BB data as the NB but at least it reduced it. Thanks! Dale |
|
1.91
#...
·
|
|---|
|
Dale, I used to have banding as well in my processed images until I stopped processing with bias frames. I found out that they were responsible for the banding. I still however take and use dark-for-flat frames and calibrate the flats. That is not the same thing. The bias were a must for the old CCD cameras. Not really necessary for modern CMOS sensors. Francois |
