Possible bug in DrizzleIntegration?

[johnpane]

I am getting horizontal color anomalies when I run DrizzleIntegration. The following example comes from the center of an integration of 59 color subframes of the Leo Triplet. The subframes were taken both before and after meridian flip and there was also some rotation due to polar alignment error, so all but the reference frame underwent significant coordinate transformation prior to integration.

All of the following examples come from a small region in the center of the image.

In the first image, the standard integration result shows signs of atmospheric dispersion but otherwise the stars look reasonably good.

In the second image, a drizzle integration with scale=1 and dropshrink=0.9, the horizontal anomalies appear.

In both of the above, after integration I ran PhotometricColorCalibration and then ArcsinhStretch.

The following shows a single star, a) RGB immediately after integration with unlinked STF, b) separate red, green and blue channels with STF, and c) RGB after PCC and AsinhStretch. This is also available for download.

The problem in the drizzle integration is particularly evident in the blue channel: in the monochrome blue image note the sawtooth patten. In the stretched color image, note the two very blue rows at the bottom separated by a more neutral row, and a similar pair near the top where there are two bluer rows separated by a redder row.

I did not notice this problem until recently. One thing that changed for me is that I began using a higher resolution one-shot-color camera with dimensions 9576x6388. It occurred to me that this might be some kind of rounding error with coordinates, but if so it seems evident only in the smaller (vertical) dimension and only in the blue channel.

It is challenging to see how this can be operator error but I would be happy to be corrected.

John

 

[Juan Conejero]

Hi John,

This result is compatible with different combinations of all or some of the following factors:

- Registration errors. Did you apply distortion correction in StarAlignment (thin-plate model with local distortion corrections)? If you have meridian-flipped frames, accurate local distortion correction is normally necessary to register different regions of the focal plane. The same applies to field rotation. This is particularly important with CFA raw data.

- Insufficient dithering. I don't know if this can be part of the problem in your case, but I've seen similar results with data sets where dithering has been performed by nearly integer pixel displacements, and/or with not enough dispersion to sample the PSF of the image accurately in a data set. This is compatible with the fact that you are now using a camera with much smaller pixels, where dithering is much more critical. Seeing is also an important factor here.

- You are using a one-shot color camera, which involves CFA raw data. On one hand, getting much smoother results from a normal image integration is always expected because it works with calibrated, demosaiced and registered data, while drizzle does not perform any interpolation and works directly on the calibrated CFA raw frames. This means two versus zero interpolations. I assume you have selected the Enable CFA drizzle option in DrizzleIntegration. On the other hand, since the red and blue Bayer CFA components have 50% more black pixels, the red and blue channels will always have much lower SNR (especially the blue channel in most cases) as a result of the inherent lack of data. Some artifacts in these channels should also be expected with drizzle as a result of the lack of spatial coverage. To overcome these limitations one has to acquire more well dithered frames.

Of course, bugs can always exist, but I doubt we have a coordinate interpolation bug in our drizzle implementation, since it would be generating many problems, mostly catastrophic ones, that we are not observing. However, to say more I'd need to work with the original set of calibrated CFA frames.

 

[johnpane]

Thank you Juan.

I did some further experimentation.

1. I used thin plate spines with local distortion correction in ImageRegistration. Previously I had turned this off because it seemed an unnecessary use of computational resources for my narrow field images; that may have been a poor decision on my part. The result of turning this on is a bit more interpolation but the issue persists.

2. I cropped a 1024x1024 region at the center of the subframes. The results are slightly different but the issue persists.

3. I rotated the cropped subframes by 180 and 90 degrees and used BGGR and GRBG cfa patterns, respectively. After integration I rotated the results back to the original position. The results are virtually identical to the unrotated version.

These seem to imply the problem is unrelated to the large image dimensions from my camera, and may rule out coordinate interpolation issues.

The problem must exist in the raw files or be introduced during calibration.

To answer your question, yes, I do have Enable CFA drizzle turned on.

The resolution of my camera is 1.15 arcsec per pixel. The average FWHM of the 59 subframes is 3.8 arcsec. This seems consistent with my informal measure of the pixel values in the star I have highlighted here. It is obvious that several pixels of each color around the center of this star are illuminated.

More importantly, it seems necessary to ensure that each color is projected onto each destination pixel. Although I am currently unable to dither during image acquisition due to equipment limitations, I believe that the meridian flip and drift from imperfect polar alignment are a imperfect form of dithering that should help ensure that the projection of each color covers the output image. This imperfect dithering might not eliminate fixed pattern noise, but having these horizontal color bands across all the stars in the image does not seem likely to be residual fixed pattern noise.

Of course, as you noted, red and blue are the most susceptible to problems. If there is insufficient dithering, why would this show up only in blue (not red) and only in one dimension? Generally, the red and green images of this star approximate a smooth 2d gaussian distribution, but in blue alternate rows are shifted right or left, resulting in comb patterns on the left and right. In row n, there is a bright extension to the right, in row n+1 to the left, row n+2 to the right, etc. Why would such a pattern occur only in blue?

The calibrated CFA subframes are in this Dropbox folder.

One final note is that I observed this same issue with 141 subframes of M81 and M82 a couple weeks earlier.

 

[Juan Conejero]

Hi John,

Thank you for uploading the data, as well as for the investigative work.

In my opinion, your result with local distortion correction is basically perfect. I don't see any issues but just a normal result of drizzle with CFA data. If you prefer a somewhat smoother result, you can try with drop shrink = 1. By increasing the drop shrink parameter your image will receive larger 'drops', which is more or less equivalent to using a larger convolution filter. This parameter is very sensitive, so a 10% increment is significant.

Anyway, I'll work with your data tomorrow and will get back here with my results.

 

[johnpane]

Juan, I very much appreciate your attention to this. I agree that the version with local distortion correction is the best among my tests, but I am still dissatisfied.

In particular, every single star in this section near the center of the image has a blue stripe near the bottom. I have not been able to fully eliminate this with ChannelMatch despite extensive attempts.

 

[johnpane]

Hi Juan,

I am following up again, this time in regards to your suggestion to use dropshrink=1 along with the thin plate splines and local distortion correction. I do not see substantial benefit from this approach -- shown in the second row of this matrix -- versus thin plate splines and dropshrink=0.9 in row 4.

Even this latest drizzle integration seems substantially inferior to the regular integration of deBayered files in row 1.

I'm am trying to this experience with a comment you made on this forum in 2019:

The only recommended way to generate integrated color images from CFA raw data, be it data acquired with digital cameras or single-shot CCD cameras, is DrizzleIntegration (i.e., CFA drizzle, AKA Bayer drizzle). The only exception may be if you have just a marginal number of raw frames, where drizzle may not be applicable.

John

 

[Juan Conejero]

Hi John,

I still haven't found the time necessary to work on your images. Right now I am working hard on the next 1.8.8-8 version of PixInsight, which is almost ready for release and requires my full attention. I hope to be able to work on this problem soon.

Anyway, the problem here is that I prefer the result that you are showing on the last row of the table (drizzle with distortion correction). It is much better IMHO than the result of a normal integration, shown on the first row. As expected, drizzle preserves existing small-scale structures much better because it does not apply any interpolation to the original raw data. Actually, you can get basically the same result as a normal integration if you apply a convolution with a Gaussian filter to the drizzle result.

It is true that the drizzle integration result shows more noise, and in some cases (without distortion correction) visible patterns, but this result is much more accurate and true to the data. A different question is which one you prefer. If you prefer to work with a smoothed image, then a normal integration is best.

 

[johnpane]

Thank you, Juan. I certainly understand you have other priorities. I will look forward to if/when you do have time to look deeper into this.

 

[johnpane]

One thing that continues to nag me about this is that only the blue channel has a jagged "comb" appearance, and only in one dimension. If this were due to undersampling in the Bayer sensor, I would expect it to occur both horizontally and vertically.

If this is indeed correct and precisely what is to be expected, my next thought is to try to anti-alias the undersampled blue and red channels. Would it make sense to offer the user an option to use a different dropshrink for those channels when using DrizzleIntegration on cfa images? For example, the user might specify 0.9 for green and 1.8 for red and blue.

 

[Juan Conejero]

Would it make sense to offer the user an option to use a different dropshrink for those channels when using DrizzleIntegration on cfa images?

Certainly yes. This is a very good idea that I'll try to implement soon, thank you!

 

[johnpane]

Is it possible the issues I was seeing here are related to this?

[Disregard; they probably are unrelated. This entire thread preceded PI 1.8.8-9 when the separate CFA channel alignment feature was introduced.]