New Version of BatchPreprocessing Script with Bayer Drizzle Support

Juan Conejero

PixInsight Staff
Staff member
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.

bpp-bayer-drizzle.jpg

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:

Code:
<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.

Code:
<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 
Code:
<output-dir>/registered
directory.

5. Click the Add Drizzle Files button and select the .drz files on the
Code:
<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
Code:
<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.
 
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
 
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
 

Attachments

  • comparison.JPG
    comparison.JPG
    452.4 KB · Views: 305
almost seems like something went wrong with the bayer drizzle case? looks completely 'undebayered'?

rob
 
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
 
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
 
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
 
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
 
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
 
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.
 
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.
 
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

 

Attachments

  • comparison.JPG
    comparison.JPG
    259.5 KB · Views: 238
  • comparison_saturated.JPG
    comparison_saturated.JPG
    228.9 KB · Views: 208
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.

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

Attachments

  • drizzle.JPG
    drizzle.JPG
    63.8 KB · Views: 308
Ignacio said:
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.
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?

Hi,

Let me comment on this one.  Unless something is fundamentally wrong in the data processing, images
(drizzle or not) made with the same amount of raw data should contain the same amount of information and noise.  The result that you see slightly lower noise level in the non-Bayer-drizzle version is caused by the interpolation, which acts like blurring the image a little bit.  In other words, the lower noise in the interpolated image is just an artifact or dilution.  You Bayer-drizzled image is as good as the other one.

Cheers,
Wei-Hao
 
georg.viehoever said:
Here is my attempt with 72 wide field shots. Not sure if I see any significant difference between Bayer Drizzle and traditional integration...
Georg

I don't see any difference too. Have you tried to substract one from the other?
 
I got a similar result with my widefield shots. Couldn't tell the difference. What is interesting though is that when I choose scale of 2 I couldn't tell the difference either except it is twice as big of course. Is drizzle more about fancy upscaling (i.e. larger output) rather than higher resolution (i.e. more detail revealed) or am I missing something because my data aren't sufficient to reveal the power of the tool?
 
whwang said:
Ignacio said:
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.
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?

Hi,

Let me comment on this one.  Unless something is fundamentally wrong in the data processing, images
(drizzle or not) made with the same amount of raw data should contain the same amount of information and noise.  The result that you see slightly lower noise level in the non-Bayer-drizzle version is caused by the interpolation, which acts like blurring the image a little bit.  In other words, the lower noise in the interpolated image is just an artifact or dilution.  You Bayer-drizzled image is as good as the other one.

Cheers,
Wei-Hao

I concur that debayer interpolation acts as a low-pass filter, and I was not surprised to see higher noise on the bayer-drizzle sample. What was a bit disconcerting was the slightly better FWHM, and the much worse color noise when saturated. This may have to do with specifics of VNG interpolation.

In any case, this is very good news to me, because what I was looking for most of all with this new approach, was to avoid the color bleeding I get in stars when doing the standard workflow. I still have to fully process the Omega Cen bayer-drizzle data, but I like what I saw so far.

Ignacio
 
NGC7789 said:
I got a similar result with my widefield shots. Couldn't tell the difference. What is interesting though is that when I choose scale of 2 I couldn't tell the difference either except it is twice as big of course. Is drizzle more about fancy upscaling (i.e. larger output) rather than higher resolution (i.e. more detail revealed) or am I missing something because my data aren't sufficient to reveal the power of the tool?

NGC7789 said:
I got a similar result with my widefield shots. Couldn't tell the difference. What is interesting though is that when I choose scale of 2 I couldn't tell the difference either except it is twice as big of course. Is drizzle more about fancy upscaling (i.e. larger output) rather than higher resolution (i.e. more detail revealed) or am I missing something because my data aren't sufficient to reveal the power of the tool?

Hi,

I don't have a PI example yet, as I have been too busy since the release of
the PI drizzle tools.  However, I hope my DSS example here can convince you
that Bayer drizzle is not just a fancy but useless thing.  It does help to bring out
the high resolution an image is supposed to have.
(original TIFF is here:http://www.asiaa.sinica.edu.tw/~whwang/misc/fig20-2.2.tif)

Of course, to achieve this, your image really has to be very sharp from the
beginning. 

Cheers,
Wei-Hao
 

Attachments

  • fig20-2.2.jpg
    fig20-2.2.jpg
    222.7 KB · Views: 296
Back
Top