4.7 MultiDrizzle Details: Example Application
to the Tadpole Galaxy
By default, MultiDrizzle uses the world coordinate system (WCS) information in the image headers to align the images. While dithers applied to a target within a single visit of HST are usually accurately reflected by the WCS, this is not the case for multiple visits which normally require guide star re-acquisitions and may utilize different guide stars. Even for nominally back-to-back exposures that are part of a CR-SPLIT association, offsets large enough to degrade final combinations do sometimes occur. As a result, it is essential to accurately determine image-to-image shifts, and possibly rotations, before running MultiDrizzle.
These (delta) shifts may be determined by separately drizzling each image onto a common WCS frame. This is performed by the 'driz_separate' task in step 3. Object lists derived for each drizzled image may then be matched and fit to derive a single shift for each image. More details on this topic and a description of the shift file formats are given in Section 4.6.
Once the shifts have been determined, MultiDrizzle must be rerun from the beginning with the shift file specified in the 'shiftfile' parameter. MultiDrizzle will update the association table to reflect these 'delta' offsets and will now use both the header WCS information plus the shift file to appropriately align images.
This example describes the combination of six ACS/WFC images of the "Tadpole Galaxy" UGC 10214 which formed part of the ACS Early Release Observations (EROs) from program 8992. These images were acquired in two visits, with a significant shift between visits, as noted by the target RA and Dec, and with small dithers within each visit. The images were taken with the F606W filter and have the exposure times listed in Table 4.4. Prior to attempting this example, we assume that users have worked through the examples in the previous sections and are familiar with using association tables and shift files.
The ERO images are available from the HST archive for anyone wishing to repeat this example. A new capability has been developed in the StarView archive interface, allowing the user to request FLT files only. The FLT files are the output from CALACS and have been corrected for bias, dark current and flat fielding. They are not corrected for distortion and still contain numerous cosmic rays. They form the input for MultiDrizzle.
Figure 4.12 shows chip 1 for one of these FLT files, j8cw54ovq_flt[sci,2], which still contains numerous cosmic ray events, hot pixels, and other artifacts. The rectangular, rather than 'rhombus' shaped image is a clear indicator that the geometric distortion has not yet been corrected.
Table 4.4: ERO datasets used in the accompanying MultiDrizzle example. The two sets of images were taken at different epochs and have a significant shift between epochs. Within a given epoch, small POS-TARG offsets are specified in accordance with the ACS-WFC-DITHER-LINE pattern which spans the WFC interchip gap.
| Dataset |
Date-Obs |
RA (deg), Dec (deg) |
POS- TARG1 |
POS- TARG2 |
Exposure Time (sec) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 4.12: A single, calibrated FLT file, j8cw54orq_flt.fits[sci,2], which still contains numerous cosmic rays, hot pixels, and other artifacts.
First, the appropriate calibrated FLT files and the geometric distortion reference table (IDCTAB) should be placed on the user's local disk. Next the 'jref' directory should be defined, PyRAF started, and the dither package loaded. To run MultiDrizzle, the parameters may be edited in the standard way using the "epar" facility.
The MultiDrizzle software has an extensive set of parameters, but the default values should allow the task to process nearly any set of images for an initial review. The parameters are separated according to the processing step they control, making it easier to interpret them.
In this example, we describe the parameters for each step in succession, though in practice, the user would set all relevant parameters at once. While the majority of relevant parameters are discussed here, a help document describing all parameters and tasks can be accessed by typing 'help multidrizzle' from within PyRAF.
The only required parameter is the rootname for the 'output' drizzled product. By default, MultiDrizzle will look for all files in the working directory with the FLT extension. The user may modify the 'suffix' parameter to include some other extension or may specify a subset of images via the 'filelist' parameter. Using the images specified, MultiDrizzle calls PyDrizzle which uses the 'buildAsn' task (see Section 4.8) to create an association table named 'output_asn.fits'. This association will be used to define the data set. The header WCS information from the entire set is used to define a common WCS output frame, and MultiDrizzle sets the drizzle parameters appropriately. If user defined shifts are available, these may be specified in the 'shiftfile' parameter, and the association table will be updated accordingly. However, a shift file is not usually available until after step 3, separately drizzling the images onto a common WCS, has been performed and objects matched.
Initial Setup
| Parameters |
Default |
Description |
|
|
List of input files |
|
|
List of input filesRootname for output drizzled products |
|
|
Reference image with desired output WCS |
|
|
File for logging the script commands |
|
|
Parameter allowing processing to resume at a given step |
|
|
Use header-based distortion coefficients? (header, none) |
|
|
Create context image during final drizzle? |
|
|
Remove temporary files? |
|
|
Extension or group to be drizzled |
|
|
Integer mask bit values considered good (sep. drizzle) |
|
|
Integer mask bit values considered good (final drizzle) |
|
|
right ascension output frame center |
|
|
declination output frame center |
|
|
Create multi-extension output file? |
|
|
Shift file for improving WCS registration |
A reference image which has the desired output WCS may be specified, and the input images will be drizzled to match the WCS of this image. Alternately, the central RA and Dec (ra, dec) of the reference pixel and the dimensions of the output frame (outnx, outny) may be specified, if desired, though reasonable values will be automatically determined from the images' WCS if these parameters are left blank. While the central RA and Dec are specified in the initial setup parameters listed above, the output image dimensions are specified in both the 'driz_separate' and 'driz_combine' parameters in steps 3 and 7, respectively.
The 'bits' parameter is defined as the integer sum of all bit values from the input images' DQ array that should be considered 'good' when building the weighting mask. Because MultiDrizzle was designed for use with multiple instruments, the default value is set to zero. For ACS data, the recommended default value is 8578. (For more information on selecting the appropriate bits for your data, refer to Section 4.4.3.) Information from the DQ array for each chip is used in combination with the 'bits' parameter to create temporary mask files called '*_inmask?.fits'. Pixels which were flagged in the DQ array and which were not specified as good via the bits parameter are assigned the value 0. All other pixels are set to 1 in the mask.
The distortion reference file is read from the image header via the IDCTAB keyword which specifies the name and location of the appropriate file. The distortion coefficients for each chip are written to temporary ascii files named '*_coeffs?.dat'. If the user wishes to retain these files, the parameter 'clean' should be set to 'no'.
In general, the default MultiDrizzle parameters will work well for most data. When setting up the Tadpole images, for example, we have specified only the following non-default parameters: output='example', 'bits=8578', 'combine_nhigh=2', and 'driz_cr_snr=4.0 3.0'. The choice of these last two parameters is explained in the sections that follow. In default mode, MultiDrizzle performs each of its 7 steps in order. In this example, however, we perform some of the steps and examine the intermediate products before final drizzle combination is performed. Approximately 5GB of free disk space is required for this example when intermediate products are not removed. An outline of the entire process is described below:
- Run only steps 1 through 3 to create sky-subtracted, separately drizzled images which are based on a common WCS.
|
pyraf> multidrizzle *_flt.fits output='example' driz_sep_bits=8578 static+ skysub+ driz_separate+ median- blot- driz_cr- driz_comb-
|
- Measure the positions of stars in the separately drizzled images and derive a shift file which defines the residual offsets.
- Rerun step 3 using the derived 'shiftfile' to create new separately drizzled images. Also turn on step 4 to create a well-aligned median image.
|
pyraf> multidrizzle *_flt.fits output='example' driz_sep_bits=8578 shiftfile='shifts' static- skysub- driz_separate+ median+ combine_nhigh=2 blot- driz_cr- driz_comb-
|
- Examine the median image to ensure that the PSF is 'round' and 'narrow' and that cosmic-rays and other artifacts are appropriately rejected.
- Run steps 5 through 7 to transform the median image back to the reference frame of each of the original input images and to derive cosmic ray masks. Using these new masks, perform the final drizzle combination.
|
pyraf> multidrizzle *_flt.fits output='example' driz_sep_bits=8578 final_bits=8578 shiftfile='shifts' static- skysub- driz_sep- median- blot+ driz_cr+ driz_cr_snr='4.0 3.0' driz_comb+
|
Once the optimal set of parameters and the optional shift file is derived, as described in the outline above, MultiDrizzle may be executed in a single pass by turning all steps on and by specifying any desired non-default parameters:
|
pyraf> multidrizzle output='example' driz_sep_bits=8578 final_bits=8578 shiftfile='shifts' static+ skysub+ driz_sep+ median+ combine_nhigh=2 blot+ driz_cr+ driz_cr_snr='4.0 3.0' driz_comb+
|
While MultiDrizzle may be executed from the command line, as shown in the above examples, it may also be run from the 'epar' facility which allows the user to see all parameters at once and to turn particular steps on and off. We recommend that beginners use the 'epar facility' to become familiar with all steps and parameters before running MultiDrizzle from the command line.
1. Creating the 'Static' Bad-Pixel Mask
| Parameters |
Default |
Description |
|
|
Create static bad-pixel mask from data? |
|
|
Name of (optional) input static bad-pixel mask |
|
|
Sigma*rms below mode to clip for static mask |
| Output Files |
Modified DQ arrays in the original input files |
When 'static=yes', this step goes through each of the input images, calculates the rms value for each chip, and identifies pixels that are below the median value by more than 'static_sig' times the rms. It is aimed at identifying pixels that may have high values in the dark frame, which is subtracted during calibration, but may not necessarily have high values in the images, and thus subtraction gives them strongly negative values. Such pixels are not always flagged in the DQ file, and this step allows them to be identified. Sometimes such pixels fall on bright objects so instead of being negative, they would be positive but lower than surrounding pixels. If the images are dithered, then they should land on blank sky at least some of the time, in which case they will appear negative and will be flagged.
For the Tadpole Example, we have left the 'StaticMask' parameters to their default values. After this step is performed, the image DQ arrays are updated with the static mask, and new flagged pixels are set with bit 4096. The '*_inmask?.fits' files are subsequently updated during further processing.
2. Performing Sky Subtraction
| Parameters |
Default |
Description |
|
|
Perform sky subtraction? |
|
|
Bin width for sampling sky statistics (in sigma) |
|
|
Sky correction statistics parameter (median, mode, mean) |
|
|
Lower limit of usable data for sky (always in electrons) |
|
|
Upper limit of usable data for sky (always in electrons) |
|
|
Number of clipping iterations |
|
|
Lower side clipping factor (in sigma) |
|
|
Upper side clipping factor (in sigma) |
|
|
KEYWORD for sky subtraction value if done by user |
When 'skysub=yes', this task will subtract the sky from each input exposure. Two important parameters to consider are the upper and lower values for data that will be used to estimate the sky value. These should be set to include most pixels in the sky (so substantially more than the FWHM of the sky distribution) but not so large as to include a substantial amount of power from objects or cosmic rays.
The 'SkySub' task will update the header keyword defined by the parameter 'skyname' with the derived sky value for each chip and will subtract the sky from the original exposures prior to the final drizzle combination. Note that the FLT images themselves are not modified when MultiDrizzle completes, although the sky value is stored in the images headers as the MDRIZSKY keyword. Sky subtraction is recommended for effective cosmic-ray flagging and removal, but only if sufficient blank sky is available to perform an accurate determination.
Great care must be taken when choosing to implement sky subtraction, because if sufficiently blank sky is not available, sky subtraction will produce erroneous results. In the case of the Tadpole images, adequate blank sky is available for each WFC chip to allow an accurate sky determination. The sky is calculated independently for the two chips, and the lowest value is taken to represent the sky on both detectors. Since the bright emission from the Tadpole generally only dominates one of the chips, the sky value from the other chip is used for both, with satisfactory results.
3. Drizzling to Separate Output Images
| Parameters |
Default |
Description |
|
|
Drizzle to separate output images? |
|
|
Size of x-axis for separate output frame |
|
|
Size of y-axis for separate output frame |
|
|
Shape of kernel function (square, point, gaussian, turbo, tophat, lanczos3) |
|
|
Weighting factor for input data image |
|
|
Linear size of output pixels (relative to input) |
|
|
Linear size of drop in input pixels |
|
|
Rotation of input image to be applied (degrees anti-clockwise) |
|
|
Value assigned to undefined output pixels |
|
|
DQ mask bit values that are to be considered good |
| Output Files |
Images= '*_single_sci.fits', '*_single_wht.fits' |
When 'driz_separate=yes', the input images are corrected for geometric distortion and drizzled onto separate output frames which have a common WCS. Any shifts, rotations, or scale changes are calculated from the image headers. The output image dimensions are calculated on-the-fly and the pixel scale is taken from the column 'scale' from the IDCTAB, where the default values are 0.05 arcsec/pix for the WFC and 0.025 arcsec/pix for the HRC. The drizzled images are in units of electrons/sec.
By default, this step uses the 'turbo' drizzle kernel, 'pixfrac=1', and an output scale equal to the input scale. For more information on setting these parameters, refer to the HST Dither Handbook (Koekemoer et al. 2002). These parameters can be changed; for example, masks can be substantially improved by specifying a smaller value of scale (e.g., 0.5 or 0.66), with the primary trade-off being much larger images (their size increases as the inverse square of the value of 'scale') and increased computation time.
In the Tadpole example, we have left the 'driz_separate' parameters to their default values. While the final drizzled image would contain 3 extensions in a single file (the science, weight, and context images), the 'driz_separate' products are separate science and weight images named '*_single_sci.fits' and '*_single_wht.fits'. No context image is created.
One of the singly drizzled FLT images, 'j8cw54ovq_flt_single_sci.fits', is shown in Figure 4.13. This image still contains numerous cosmic ray events, hot pixels, and other artifacts. The 'rhombus' shape is a result of correcting the geometric distortion. The corresponding weight image, 'j8cw54ovq_flt_single_wht.fits', is shown in Figure 4.14, where white indicates pixels with zero weight. Due to the effects of distortion and varying pixel area in the FLT images, the weight image changes gradually across the detector. Because the association table was used to define a common WCS for all images, the drizzled image is 'padded' with zeros outside the boundary of the original array. The weight image is set to zero in these regions, allowing these pixels to be rejected during median combination.
The separately drizzled science images may be used to improve the image registration prior to final drizzle combination. In this example, the images form two groups of three. While the WCS information for images within a single group (visit) are adequate to align them, there is a small residual offset between visits. Shifts which are determined from separately drizzling images onto a common WCS are by definition 'delta' shifts (see Section 4.6 for details), and will be applied in addition to any offsets from the WCS when a 'shiftfile' is provided. Because no additional scale or rotation was applied to the singly drizzled images, the shifts are in the 'input' frame of reference.
In this example, unsaturated stars in the short exposures (j8cw04abq and j8cw54oiq) were used to derive the offsets between the two groups of images. Shifts were measured to the nearest 0.1 pixel and are listed below in the form of a shift file. Refined shifts within a given visit may also be determined, but these are typically less than a tenth of a pixel, and accuracy at this level is not as critical for extended sources as it may be for point sources.
|
#units: pixels
#frame: input
#form: delta
j8cw04abq_flt 0.0 0.0
j8cw04c2q_flt 0.0 0.0
j8cw04c7q_flt 0.0 0.0
j8cw54oiq_flt -5.6 -0.3
j8cw54orq_flt -5.6 -0.3
j8cw54ovq_flt -5.6 -0.3
|
When the 'driz_separate' step is run for the second time, but with a 'shiftfile' specified, the association table for the data set will be automatically updated. To confirm that the new separately drizzled images are appropriately registered, the position of stars should again be examined. It is also useful to create a median image and examine the width and shape of the PSF over the entire FOV to look for any effects of mis-registration. Median combination is performed in Step 4 of MultiDrizzle.
Figure 4.13: The singly drizzled FLT image 'j8cw54ovq_flt_single_sci.fits' from the MultiDrizzle example.
Figure 4.14: The weight image 'j8cw54ovq_flt_single_wht.fits' corresponding to the singly drizzled image in Figure 4.13 where white indicates zero weight.
4. Creating the Median Image
| Parameters |
Default |
Description |
|
|
Create median image? |
|
|
Create new masks when doing the median? |
|
|
Type of combine operation (average, median, sum, minmed) |
|
|
Significance for accepting min instead of median |
|
|
minmax: Number of low pixels to reject |
|
|
minmax: Number of high pixels to reject |
|
|
Lower threshold for clipping input pixels |
|
|
Upper threshold for clipping input pixels |
|
|
Radius (pixels) for neighbor rejection |
| Output Files |
Images= 'output_med.fits' |
When 'median=yes', this step creates a median image from the separate drizzled input images, allowing a variety of combination and rejection schemes. If 'combine_type' is set to 'median' or 'average', then the routine carries out a similar calculation to the standard IRAF task imcombine, with equivalent behavior for the parameters 'combine_nlow' and 'combine_nhigh' (the number of low and high pixels to reject), and 'combine_grow' (the amount by which flagged pixels can grow). All imcombine parameters other than those specified above are reset to their default values.
If 'combine_type=minmed', a more sophisticated algorithm is used to combine images. The basic concept is that each pixel in the output combined image will be either the median or the minimum of the input pixel values, depending on whether the median is above the minimum by more than n times sigma. An estimate of the "true" counts is obtained from the median image (after rejecting the highest-valued pixel), while the minimum is actually the minimum unmasked ("good") pixel. This algorithm is designed to perform optimally in the case of combining only a few images (3 or 4), where triple-incidence cosmic rays often pose a serious problem for more simplified median combination strategies. The 'minmed' algorithm performs the following steps:
- Create median image, rejecting the highest pixel and applying masks.
- Use this median to estimate the true counts, and thus derive an rms.
- If the median is above the lowest pixel value by less than the first value in 'combine_nsigma', then use the median value, otherwise use the lowest value.
- If 'combine_grow' > 0, repeat the above 3 steps for all pixels around those that have already been chosen as the minimum, this time using a lower significance threshold specified as the second value in 'combine_nsigma'.
The last step is very successful at flagging the lower signal-to-noise "halos" around bright cosmic rays which were flagged in the first pass.
If 'median_newmasks=yes', then the singly drizzled weight maps ('*_single_wht.fits') are used to create pixel masks for each image, based on the pixel flag information originally present in the DQ arrays. These masks will then be used when combining images, in order to prevent bad pixels from adversely affecting the median.
If 'median_newmasks=no', this task will use whatever masks are specified by the user (and which are created offline) in the 'BPM' header keyword of each image. In general, however, it is recommended that the pixel masks which are generated by default are used instead.
Selecting the best parameters for the median step can be an iterative process and should always involve examination of the clean, combined product to verify that the majority of cosmic-rays and other artifacts are successfully removed. The rejection algorithm which is ultimately chosen depends largely on the number of datasets being combined and the amount of overlap between dithered images.
In this example, we have chosen the default parameters 'combine_type=median', 'combine_reject=minmax', 'combine_nlow=0'. Instead of the default value, we have set 'combine_nhigh=2' so that hot pixels are rejected in the outer portions of the image, which have only 3 input images contributing to the median calculation, and for which 2 of the 3 images are at the same dither position. Thus, at least 1 valid pixel is retained in the outer portion of the median image. In the central regions of the image, six images have contributed to the median, but two high images are rejected, so up to 4 valid pixels would be retained. The six separately drizzled images are combined using the bad pixel masks and the rejection parameters specified above to create a single clean median image named 'example_med.fits'. This median image is shown in Figure 4.15.
Figure 4.15: The cleaned median image created using the 6 separately drizzled Tadpole images and their bad pixel masks.
5. Blotting Back the Median Image
| Parameters |
Default |
Description |
|
|
Blot the median back to the input frame? |
|
|
Interpolant (nearest,linear,poly3,poly5,sinc) |
|
|
Scale if sinc kernel is used (ignored otherwise) |
| Output Files |
Images= '*_sci?_bl.fits' |
When 'blot=yes', this task takes the median image and uses the Pyraf blot task to apply the geometric distortion and to transform ('reverse drizzle') it back to the reference frame of each of the original individual input images. This involves reversing the shifts and reapplying the geometric distortion that had been removed in step 3. In addition, the median image is resampled to the pixel scale of the original images and is trimmed to match the dimensions of each input image. This step is done in preparation for subsequent cosmic-ray rejection in step 6. The blotted frames are named '*_sci?_blt.fits'.
If desired, the user may wish to display the input images and blink them with their 'blotted' counterparts. The 'blotted' images should align perfectly with their respective input images and should be reasonably similar in appearance, except for the fact that they should be cleaned of cosmic rays and other defects.
6. Creating Cosmic Ray Masks
| Parameters |
Default |
Description |
|
|
Perform CR rejection with deriv and driz_cr? |
|
|
Create CR cleaned _cor file and a _crmask file? |
|
|
Driz_cr.SNR parameter |
|
|
Pixel width to 'grow' around CRs for 2nd pass |
|
|
Length to convolve in CTE direction for 2nd pass |
|
|
Driz_cr.scale parameter |
| Output Files |
Images= '*_sci?_blt_deriv.fits', '*sci?.fits', '*_sci?_crderiv.pl', '*_sci?_cor.fits' |
When 'driz_cr=yes', this step uses the original input images, the blotted median images, and the derivative of the blotted images (which it creates using the deriv task) to create a cosmic ray mask for each input image (using the driz_cr task).
First, the deriv task uses the blotted median images ('*_sci?_bl.fits') from step 5 to calculate the absolute value of the difference between each pixel and its four surrounding neighbors. For each pixel, the largest of these four values is saved in an output image, '*_sci?_bl_deriv.fits', which represents an effective gradient or spatial derivative.
These derivative images are used by the task driz_cr when comparing the original and blotted images. First, the original FLT images for each chip are copied to files named '*_sci?.fits' which are the required input for the driz_cr task. These images are compared with the corresponding blotted median image '*_sci?_bl.fits' and its absolute derivative '*_sci?_bl_deriv.fits' to create a mask of cosmic rays (and other blemishes, like satellite trails). Where the difference is larger than can be explained by noise statistics, or the flattening effect of taking the median, or perhaps an error in the shift (the latter two effects are estimated using the image derivative), the suspect pixel is masked. Cosmic rays are flagged using the following rule:
|data_image - blotted_image| > scale*deriv_image + SNR*noise
where 'scale' is the user supplied driz_cr parameter listed above and is defined as the multiplication factor applied to the derivative before determining if the difference between the data image and the blotted image is sufficiently great to require masking. 'Noise' is calculated using a combination of the detector read noise and the poisson noise of the blotted median image plus the sky background.
The user must specify a cut-off signal-to-noise (SNR) value for determining whether a pixel should be masked. Actually, two cut-off signal-to-noise ratios are needed, one for detecting the primary cosmic ray, and a second for masking lower-level bad pixels adjacent to those found in the first pass. After the first pass through the image, the procedure is thus repeated on pixels that are adjacent to previously masked pixels using a lower SNR threshold, since cosmic rays often extend across several pixels.
A second-pass CR rejection can be carried out in a larger region 'grown' around the CRs initially identified (using the 'driz_cr_grow' parameter). The second-pass iteration can also be done along the CTE direction by convolving the CR mask with the 'driz_cr_ctegrow' parameter; 10 - 20 pixels yields good results for removing faint CTE trails from CRs.
The final cosmic ray mask is stored in the DQ array of the original input FLT files, using the value specified for the 'crbit' parameter; if this left blank then a default value of 4096 is used. One of the resulting masks for chip 1 is shown in Figure 4.16 and should be blinked with the original image j8cw54orq_flt[sci,2] from Figure 4.12 (or the equivalent j8cw54orq_flt_sci2.fits file) to visually ascertain that all cosmic rays were flagged. If it appears that the central pixels of some stars were unnecessarily masked, the 'driz_cr_scale' parameter should be increased. If not enough cosmic rays were masked out, this parameter should be decreased. In this example, the default 'driz_cr_snr' values "3.0 2.5" were too stringent and resulted in flagging the centers of stars and the core of the Tadpole galaxy. Instead, we have increased the default SNR values to "4.0 3.0" to create ideal cosmic ray masks for this data set.
The driz_cr task can also create a '*_sci?_cor.fits' image, where flagged pixels are replaced with pixels from the blotted median image. The cosmic ray mask files are then multiplied by the bad pixel masks (which are a combination of the image DQ array and the static masks) to create a final CR mask for each input image, stored in the DQ array of the FLT files (default bit 4096), which will be used during final drizzle combination.
Figure 4.16: A single cosmic ray mask 'j8cw54orq_flt_sci2_crderiv.pl'. This mask should be blinked with the original image 'j8cw54orq_flt[sci,2]' from Figure 4.12 or the equivalent 'j8cw54orq_flt_sci2.fits' output file to assure that optimal parameters were chosen in the driz_cr task.
7. Performing the Final Drizzle Combination
| Parameters |
Default |
Description |
|
|
Perform final drizzle image combination? |
|
|
EXP |
|
|
Size of FINAL output frame x-axis |
|
|
Size of FINAL output frame y-axis |
|
|
Shape of kernel function (square, point, gaussian, turbo, tophat, lanczos3) |
|
|
Linear size of output pixels (relative to input) |
|
|
Linear size of drop in input pixels |
|
|
Rotation of input image to be applied (degrees anti-clockwise) |
|
|
Value given to undefined output pixels |
|
|
DQ mask bit values to be considered good |
| Output Files |
Images= output_drz.fits (multi-extension) |
When 'driz_combine=yes', this step takes the original input images, together with the final cosmic ray masks, and drizzles them all onto a single output image. The standard drizzle parameters kernel, scale, pixfrac, and rot can be specified by the user, if desired. By default the scale of the output image is 1.0, but the user is encouraged to experiment with other options (e.g. scale=0.5 and pixfrac=0.7 yields a sharper output PSF).
When the following initial setup parameters are set: 'build=yes' (default) and 'context=yes' (non-default), the final MultiDrizzle output image will be a single multi-extension FITS file named 'example_drz.fits'. This file contains the science image in extension 1, the weight image in extension 2, and the context image in extension 3. When 'build=no', these files will be written to separate output files. When the default value 'context=no' is used, no context image is created.
The first extension of the drizzled product contains the science (SCI) image which is corrected for distortion and which is dither-combined (or mosaiced), if applicable. The drizzled SCI image derived from the Tadpole example is presented in Figure 4.17 and is in units of electrons/sec. All pixels have equal area on the sky and equal photometric normalization across the field of view, giving an image which is both photometrically and astrometrically accurate for both point and extended sources. The dimensions of the output image are computed on-the-fly by MultiDrizzle and the default output plate scale is read from the 'scale' column in the IDCTAB. These parameters, however, may be chosen by the user to best suit the actual data.
The second extension of the output image contains the weight (WHT) image. This image gives the relative weight of the output pixels and, in standard processing using the MultiDrizzle defaults, it can be considered an effective exposure time map, if the default value of 'final_wht_type' is set to 'EXP'. The weight image from the example is shown in Figure 4.18, where darker areas have higher weight. The chip edges and gaps are clearly visible, as are column defects and cosmic ray features. The bulk of the image is "dark gray" corresponding to the overlap of all six inputs. In this area the weight value is ~3140, equal to the sum of the exposure times of the six images which contribute. There is also a smooth variation across the image due to the variation of the pixel area on the sky caused by the distortion.
The output weight image can also be specified to be in units of inverse variance, calculated using the error arrays initially present in the FLT file, by setting 'final_wht_type' = 'ERR'. This would include all sources of error, including read-noise, dark current, as well as the background sky and all the object photons. Finally, if 'final_wht_type' = 'IVM', then MultiDrizzle will look for inverse variance files provided by the user (for example, to include all sources of noise except those related to photons from objects in the field). These would be specified by giving all the input FLT files to MultiDrizzle in an ASCII file list, with each line containing just two filenames, namely the name of the FLT file and its corresponding IVM file. the IVM file should have a similar structure as the FLT file, except that the inverse variance values are stored in an extension that is called [IVM]. However, typically we recommend specifying 'final_wht_type' = 'ERR' which automatically takes care of calculating all the inverse variance files using the correct noise sources, and requires no additional input files.
The third extension of the MultiDrizzle output image contains the context (CTX) image which encodes information about which input image contributes to a specific output pixel. This is done using a bitmask for each output pixel, where 'bit set' means that the image, in the order it was combined, contributed with non-zero weight to that output pixel. The context image starts as a single 32-bit integer image but is extended as a cube with additional 32-bit deep planes as required to handle all the input images. The context image for the Tadpole example is shown in Figure 4.19. As there are six input images, each with two chips which are treated separately, this image has 12 bit planes which may be set. The darkest area shown corresponds to the [sci,2] chip from all six inputs and hence has all the following even bits set: 2+8+32+128+512+2048=2730. Cosmic ray hits or other defective pixels contribute to the appropriate bit plane with zero weight and hence appear as lighter spots.
Figure 4.17: The science (SCI) extension of the drizzled product from the MultiDrizzle example. This image has been corrected for distortion and drizzled onto a single mosaic using the six images in the dither pattern.
Figure 4.18: The corresponding weight (WHT) extension of the drizzled product from the example.
Figure 4.19: The corresponding context (CTX) extension of the drizzled product from the example.