Pattern in Integrated H-alpha image with Pixinsight Pleiades Astrophoto PixInsight · Daniel Carter · ... · 28 · 2159 · 4

dgj 0.00
...
· 
·  Share link
John Hayes:
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

I encountered a similar problem with a set of Ha data for a very faint nebula.  I saw strange crisscross bands in the background of the final integrated Ha image.  I think John is correct that it is important to employ a pedestal when setting up WBPP.  But in my case the solution to the problem went a bit deeper. 

At first I tried to change settings in Staralignment, but no matter what I tried the problem persisted.  I do not think it is an image registration problem.  So, I looked more closely at Imageintegration.  I noticed that when I ran Imageintegration, the low pixel rejection map showed bands on it.  This suggests that the bands produced in the integrated image were resulting from this low pixel rejection.  I looked more closely at the settings for low pixel rejection.  There is a box called "Clip low range" and according to the drop down help dialog, this box should be checked for "optimal performance" under "normal conditions" with the Range low value set to zero.  With the Clip low range box checked,  pixels with values less than or equal to zero should be rejected.  This seems reasonable, and most of the time I think you want that to happen.  But, I tried unchecking the "Clip low range" box and, lo and behold, the weird crisscross pattern vanished and the nebula looked normal.  (I used the global normalization "Additive with scaling" and "Scale plus zero offset" for pixel rejection(1) and the ESD algorithm.  I used PSF Signal Weight for weights.  I checked the box to subtract the pedestal.)  

I think all this is a result of very low signal inherent in my Ha data.  In any case, if Mr. Carter cares to revisit this issue with his data, it would be worth trying my suggestion concerning image integration.

Incidentally, with my data I had no success with local normalization.  The background banding issue was not evident, but the nebula in the Ha integrated image had a strange pasty/pixelated appearance that was clearly not acceptable.  I have ideas, but am not entirely sure why this happened.

Denis
Like
macnenia 5.87
...
· 
·  1 like
·  Share link
Denis Janky:
John Hayes:
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

I encountered a similar problem with a set of Ha data for a very faint nebula.  I saw strange crisscross bands in the background of the final integrated Ha image.  I think John is correct that it is important to employ a pedestal when setting up WBPP.  But in my case the solution to the problem went a bit deeper. 

At first I tried to change settings in Staralignment, but no matter what I tried the problem persisted.  I do not think it is an image registration problem.  So, I looked more closely at Imageintegration.  I noticed that when I ran Imageintegration, the low pixel rejection map showed bands on it.  This suggests that the bands produced in the integrated image were resulting from this low pixel rejection.  I looked more closely at the settings for low pixel rejection.  There is a box called "Clip low range" and according to the drop down help dialog, this box should be checked for "optimal performance" under "normal conditions" with the Range low value set to zero.  With the Clip low range box checked,  pixels with values less than or equal to zero should be rejected.  This seems reasonable, and most of the time I think you want that to happen.  But, I tried unchecking the "Clip low range" box and, lo and behold, the weird crisscross pattern vanished and the nebula looked normal.  (I used the global normalization "Additive with scaling" and "Scale plus zero offset" for pixel rejection(1) and the ESD algorithm.  I used PSF Signal Weight for weights.  I checked the box to subtract the pedestal.)  

I think all this is a result of very low signal inherent in my Ha data.  In any case, if Mr. Carter cares to revisit this issue with his data, it would be worth trying my suggestion concerning image integration.

Incidentally, with my data I had no success with local normalization.  The background banding issue was not evident, but the nebula in the Ha integrated image had a strange pasty/pixelated appearance that was clearly not acceptable.  I have ideas, but am not entirely sure why this happened.

Denis

Hi Denis,

Thanks you for this excellent work to determine the cause of the criss cross pattern that clearly a number of us have encountered. I had used the auto-pedestal which for my 17 Ha images had generated pedestal ADU values from 12 to 140, but the pattern was still in evidence. I tried a blanket value of 200 ADU for the pedestal with the same result. After researching the issue and reading your analysis, I had a look to see if WBPP has such a "Clip low range" tickbox and it does not. I tried reducing the Percentile Low from 0.2 to 0.0 in the WBPP Image Integration dialogue box, but that still produced the criss cross pattern. Eventually I went back to the ImageIntegration process in PixInsight and, as you suggested"unticked the "Clip low range" tick box and the problem disappeared.
Incidentally, previously I had trialled various interpolation algorithms during the registration process and I found that using Bi-cubic B-Spline instead of Lanczos-3 also eliminates the problem, but results in a much noisier image. Your solution eliminates the pattern and gives a much smoother image.

Niall
Like
Alexn 12.25
...
· 
·  Share link
I would like to point out if it has not already been advised - 180s subs with an STL11k is GROSSLY under exposing the sensor, and your data is likely going to be swamped in read noise which will result in all manner of issues.

The STL-11000M sensor REQUIRES 10 minute subs in Ha to make reasonable images… When I was imaging with the STL11K, and more recently a STT8300 and STX16200, I would not run less than a 900s sub in Ha, and 1200s subs are absolutely not uncommon. 

Its an easy thing to do these days, to assume that because everyone is running 180s subs by average, that that is the 'correct' exposure duration… Coming from someone who started imaging in the days of CCDs, when I first moved to a CMOS camera, I immediately went directly to trying to run 15 minute Ha exposures, and was struggling to create a reasonable image as I felt the camera was very limited in well depth. 

CMOS cameras behave very differently to CCDs, and with a CCD, (ESPECIALLY THE STL11000 with its terribly low ~30% QE in Ha light) you are FAAAAR better off to stack 9x1200s (3h) subs, than 60x180s (3h) subs…. 

Having to drag the data up from such short exposures through that bias/read noise floor is going  to result in all kinds of artefacts in your images. 

You need to let that KAI11002M sensor stretch its legs…
Like
macnenia 5.87
...
· 
·  1 like
·  Share link
Alex Nicholas:
I would like to point out if it has not already been advised - 180s subs with an STL11k is GROSSLY under exposing the sensor, and your data is likely going to be swamped in read noise which will result in all manner of issues.

The STL-11000M sensor REQUIRES 10 minute subs in Ha to make reasonable images... When I was imaging with the STL11K, and more recently a STT8300 and STX16200, I would not run less than a 900s sub in Ha, and 1200s subs are absolutely not uncommon. 

Its an easy thing to do these days, to assume that because everyone is running 180s subs by average, that that is the 'correct' exposure duration... Coming from someone who started imaging in the days of CCDs, when I first moved to a CMOS camera, I immediately went directly to trying to run 15 minute Ha exposures, and was struggling to create a reasonable image as I felt the camera was very limited in well depth. 

CMOS cameras behave very differently to CCDs, and with a CCD, (ESPECIALLY THE STL11000 with its terribly low ~30% QE in Ha light) you are FAAAAR better off to stack 9x1200s (3h) subs, than 60x180s (3h) subs.... 

Having to drag the data up from such short exposures through that bias/read noise floor is going  to result in all kinds of artefacts in your images. 

You need to let that KAI11002M sensor stretch its legs...

I use an SBIG 16803 CCD camera and the exposures are 1800 secs. I am getting the hatching/ criss cross artefact with that.
Like
 
Register or login to create to post a reply.