Hi Wei-Hao,
On the other hand, for Bayer Drizzle here, you did not instruct to do so.
I forgot to mention it. Yes, the ImageIntegration tool must always update the .drz files with rejection and normalization data, so the
generate drizzle data option has to be enabled also in the case of Bayer drizzle. Note that ImageIntegration enables this option automatically when you select drizzle files (by clicking the Add Drizzle Files button), so in general one doesn't need to care about this.
what this "generate drizzle data" actually does
A drizzle data file (with the .drz suffix) stores all the data required to perform a drizzle integration process:
1. The full file path of the
source drizzle image (calibrated, de-Bayered, but not registered). This is the image that will be integrated with DrizzleIntegration.
2. The full file path of the
registration target image (calibrated, de-Bayered and registered). This is the image that should be integrated with ImageIntegration to compute normalization parameters, image weights, and pixel rejection data. This image will not be used in the final drizzle integration process.
3. The geometry of the reference registration image. This defines the geometry of the final drizzle-integrated image (multiplied by the drizzle output scale).
4. The geometrical transformations necessary to register the image. This may include a projective transformation matrix and/or surface spline control points and parameters, if local distortion correction is being used. These transformations are applied by DrizzleIntegration to compute the geometry of each 'drop' that 'rains' over the drizzle-integrated image
5. The coordinates of each rejected pixel. In the next version of the ImageIntegration module this will be more complex, since we'll implement a fuzzy-logic rejection feature. For now, rejection is a purely binary process (rejected/not_rejected).
6. Image normalization parameters, including estimates of statistical location and scale.
7. Image weighting parameters. These are normally based on noise estimates computed during the image calibration phase (and stored as XISF properties and FITS keywords in the image), but can also be generated from statistical parameters or image properties/keywords by ImageIntegration.
Drizzle data files are created by the StarAlignment process with items 1, 2, 3 and 4. The ImageIntegration process updates drizzle files with items 5, 6 and 7.
In the case of Bayer drizzle, the trick consists of replacing item 1 with the path to the calibrated Bayer image, that is, the image after calibration but *before* applying the de-Bayering process. However, drizzle cannot use the monochrome CFA data directly (mainly because color planes would get intermixed without sense), so the CFA must be split into three separate R, G and B planes, with black pixels replacing the lacking data in each plane, and conveniently packed as an RGB image. This is what we call a
separate RGB Bayer image. Then the drizzle process can be applied unmodified, as if it was working with a normal RGB image. The BatchPreprocessing script does this automatically, including generation of separate RGB Bayer data under the hood. The same task can also be implemented manually, with the help of Nikolay's SplitCFA tool to automate part of the process, but it is somewhat tedious.
Right now the Bayer drizzle method can only be implemented as an automatic process using the BatchPreprocessing script. An optimal implementation of Bayer drizzle requires a tight integration with a preprocessing pipeline, such as BPP. This will also be implemented outside BPP, probably as a standalone tool, but we have other priorities at present.
Hope this clarifies what this drizze data stuff is all about.
