New Version of BatchPreprocessing Script with Bayer Drizzle Support

[Juan Conejero]

Hi all,

Today I have released version 1.36 of the BatchPreprocessing script with support for the Bayer drizzle algorithm. New versions of the Debayer, ImageCalibration, ImageIntegration and ImageRegistration modules have also been released with bug fixes and improvements to support this feature.

Bayer drizzle was devised by David Coffin, the author of dcraw. It is just a drizzle integration process, but applied to CFA (Color Filter Array) data. This applies to frames acquired with DSLR and one-shot color CCD cameras. The idea behind Bayer drizzle is pretty straightforward: with a sufficient number of dithered frames, the drizzle integration algorithm can be applied to fill the existing holes in the red, green and blue channels of multiple CFA Bayer images to form a demosaiced RGB color image directly from calibrated raw data without interpolation. Note that this process is very different from demosaicing algorithms such as VNG, AHD, etc., which interpolate CFA frames to generate RGB pixel sample values.

For detailed information on the DrizzleIntegration tool and some interesting discussions about drizzle and Bayer drizzle, see the original announcement thread. With the newly released tools and scripts, this is an outline of the procedure to perform a Bayer drizzle integration in PixInsight:

1. Use the BatchPreprocessing script to calibrate your raw data as usual. On the Lights page of BatchPreprocessing, select:

- Generate Bayer drizzle data on the Image Registration section.
- Bayer drizzle on the DeBayer section.

2. Run the BatchPreprocessing script.

3. On the script's output directory you'll find two new sub-directories with the data required to perform a Bayer drizzle process:

<output-dir>/calibrated/light/bayer

This directory contains the FITS files that the DrizzleIntegration tool will use to generate the final drizzled image. These files are RGB images with the CFA components split in separate channels. These images are calibrated (and optionally cosmetized) raw data; they have not been demoisaiced or registered.

<output-dir>/registered/bayer

This directory contains the .drz files that you'll have to use with the ImageIntegration tool to prepare the Bayer drizzle process, as described in the following steps.

4. After BatchPreprocessing, open the ImageIntegration tool and add the registered images that you have on the  <output-dir>/registered directory.

5. Click the Add Drizzle Files button and select the .drz files on the <output-dir>/registered/bayer directory (see step 3)

6. Carry out your integration as usual: Optimize pixel rejection parameters to achieve the necessary rejection of spurious features with a minimal impact on the final SNR improvement.

7. After ImageIntegration, open the DrizzleIntegration tool. Select the same .drz files on the <output-dir>/registered/bayer directory. Unless you have a really huge amount of data available, set scale = 1 and drop shrink = 1.0. Execute globally and carefully inspect the result.

Keep in mind that you really need many and dithered images to apply Bayer drizzle. Say a minimum of 20 - 30 images, the more the better of course. This is because CFA images lack data as a result of the Bayer pattern: a 75% of the data is missing on the red and blue channels, while a 50% of pixels are pure black on the green channel. The drizzle algorithm will attempt to fill all of these gaps by projection of many different, well dithered images. If you've got good data, the result will be a naturally demosaiced image without any interpolation.

[Ignacio]

Great, Juan! I will give it a try right away on my recent Omega Cent data (22 dithered frames), and post comparisons of regular integration, drizzled 2x, and bayer drizzle.

I tried to do this process manually, but got stuck in what you mean by CFA, separate RGB channel, image format (after calibration). Could you elaborate on that? Are these RGB images with the three separate color panes with lots of zeros in them?

Thanks again,
Ignacio

[whwang]

Is it possible to integrate all these into a one-step script?

[Ignacio]

Ok, so I did a first try on the Omega Cent data (22 frames, reasonably dithered), and compared standard vs drizzle 2x vs bayer drizzle 1x. The image attached, is the same small crop of the frame, in that order. Note the obvious better smoothness of star edges  in the drizzle 2x case, but a somewhat loss of contrast (due higher noise and auto STF).

The bayer drizzle case shows strong color pixelation. In fact, if one looks at the histogram, the R and B curves are all spread out, while the G looks fairly good. This must be a result of the sparsity of the R and B color samples.

It seems to me, that there is need for some form of normalization step at the end, like a pixel level equalization depending on how much color information ends up in that final pixel location.  For instance, in the extreme case that a pixel, by chance ends up with no R data, then one could interpolate that data from neighboring R pixels (and maybe from luminance too) to fill the information hole.  This is the extreme case, but it applies to every case.

I know this sound like going back to debayering interpolation, and in a way it is, but at a stage where there is better SNR to carry it out. Am I making any sense?

Ignacio

[pfile]

almost seems like something went wrong with the bayer drizzle case? looks completely 'undebayered'…

rob

[Ignacio]

If you look at each color channel of the final stack, all pixels have non-zero values in all channels, so it seems that the algorithm did its job, by correctly registering each undebayered color pane from each sub, and stacking them.

Also, I would expect that the algorithm contemplates partial projection of pixels on the final grid, right?

Ignacio

[whwang]

Hi,

I do think that image normalization may have something to do with this.
This is indeed quite common for the Bayer-drizzle produced by DSS.
I often encounter this when the images are taken under variable condition
(i.e., variability in background brightness).  You can imaging that in a
2x2 pixel grid, one pixel may contain data that come from images with
higher background brightness (on average) while another pixel may contain
data from images with lower background brightness.  This produces what
you see.

This will not happen on normal de-Bayered images, since all the pixels
are interpolated.  So this is indeed the signature of Bayer drizzle.  To make
it go away, very careful image normalization is required.  Indeed, the same
can happen on standard drizzle of gray-scale images too, if the images
were taken under variable sky condition.

Cheers,
Wei-Hao

[Ignacio]

Changing sky conditions may contribute to this, but I think is a second order effect. There is something about how the average of the pixel on the final grid is computed, based on the amount of data samples on each color that projects on that pixel.

I don't know the internals of the implementation, but I will through an idea: given a color channel, any given pixel on the final grid may receive a bunch of partial sample contributions from different subs. The number representing that amount of samples must be real, not integer, due to partial projections, and always smaller or equal to the total number of subs. An it should vary from pixel to pixel. Is this the number used to compute the stack average for each pixel? If the number of dithered subs is very large, then this denominator will be very similar for all pixels in a given color channel. But when that number is in the 20-30 range, my guess is that this effect will be noticeable.

Ignacio

[NGC7789]

For what it's worth, I see the same grid pattern in my first attempt. I have 80 subs in my stack. I don't know if that counts as "very large" but it's more than 20-30. I haven't had time to play with setting much though.

-Josh

[whwang]

Hi,

With no disrespect, I think the need of "many" dithered exposures is exaggerated here.

In the most ideal case, where we can accurately control the position of each dither, we will
only need 4 exposures to fill the holes in the Bayer CFA.  For G, even just 2 exposures
will be sufficient.  Of course, in amateur astrophotography, accurately controlling the dither
positions is usually not possible and the dither steps are usually random.  However, even
given this random nature, we still don't need much more exposures than 4.

In my experience, with either DSS's Bayer drizzle or my own drizzle program for CCD images,
8 exposures are quite sufficient.  I can even get away with just 4 exposures from time to time.
(When there are just 4 exposures, and when the result doesn't look good, it is usually because
of the lack of exposure time (low S/N), not because of insufficient number of exposures and
the drizzle-related artifact).

Cheers,
Wei-Hao

[Juan Conejero]

For what it's worth, I see the same grid pattern in my first attempt. I have 80 subs in my stack.

The current version of the DrizzleIntegration tool (released yesterday as an update) has a little bug that is causing this problem. I am preparing an update with a bug fix for all platforms right now. It should be ready in ten minutes. Sorry for the trouble.

[Juan Conejero]

Bug fix released. Bayer drizzle should work perfectly now. And yes, with 20 - 30 dithered images the result should be quite good. Even with 10 images or so the results are pretty decent.

Thank you for your help.

[Ignacio]

Ok, Juan, I tried the new version and it worked very well! Attached is the comparison crop of standard, drizzle 2x, and bayer drizzle 1x. This is what I have found so far, looking at this particular case:

Comparing Standard Integration (using VNG during debayering) with Bayer Drizzle 1x Integration (no debayering):

Both integration files were color calibrated and linearly fitted against each other.

1. Noise levels as reported by NoiseEvaluation script were 50-60% higher for the bayer drizzle R and B channels, and 25% for the G channel.
2. CBNR for the luminance was almost identical in both cases.
3. Median FWHM was 7% wider with bayer drizzle. But upon visual inspection, star edges look more natural.
4. Upon several iterations of color saturation (Curve S), the bayer drizzle integration behaves a lot better, showing much less color noise visually than the standard integration (see attached image). I find this hard to reconcile with the numerical noise estimates. Juan?

Ignacio

[Tromat]

Hi,

and thanks for that new wonderful tool. A while ago I tried bayer drizzle with DSS but it wasn't successful as I had always the bayer pattern visible. It was the same with the first realease of the bayder drizzle implementation in PI but now it works like a charm

I managed to bayer drizzle a picture with only 10 DSLR subs. The background noise appears to be thiner, almost like a mono CCD noise. I still have to see how this behave with a full process, especially after TGVNoise reduction. I guess that the noise will be easier to manage.

[georg.viehoever]

Here is my attempt with 72 wide field shots. Not sure if I see any significant difference between Bayer Drizzle and traditional integration...
Georg