Space Telescope Science Institute
DrizzlePac 2012 Handbook
Table of Contents Previous Next Index Print

The DrizzlePac Handbook > Chapter 8: Data Quality Checks and Troubleshooting Problems > 8.3 Inspecting Drizzled Products after Reprocessing

Are the reprocessing task parameters optimal?
Are the reprocessing task parameters optimal?
The same set of checks discussed for Archival data should be performed for reprocessed data. For more details, refer to Section 8.1. These checks include examining the quality of the sky subtraction, inspecting the cosmic ray masks, and looking for unusual patterns of artifacts or correlated noise in the science array. The PSF should be inspected (using a task like IRAF’s imexamine) over the entire field of view. If dithering was part of the observation strategy, the resolution of the drizzled products can usually be improved by experimenting with the final drizzle parameters, especially for HST detectors which are significantly undersampled.
The weight images should be carefully examined to get an idea of how many input pixels contributed to each output pixel. When the weight image has a significant number of “holes” where no valid input pixel was available, the data quality array of the input frames should be inspected and the value for the final_bits parameter adjusted. Alternately, this may indicate that the final_pixfrac parameter was too small for the dataset, based on the number of images and the dithering pattern used. (More information about this will be covered in Sections 8.3.1 and 8.3.2, below.)
A detailed discussion of running astrodrizzle with HST data is presented in Chapter 7. Instructions for inspecting the intermediate data products and for optimizing various parameters are addressed in these examples, as well as suggestions for troubleshooting.
Drizzled products from MAST are single multi-extension FITS (MEF) files with the science image, the weight image, and the context image in extensions one, two, and three, respectively. During reprocessing, the parameter build is set to no by default so the science, weight, and context images are written to separate output files. The choice of this parameter is purely a matter of convenience; reprocessed images can be generated using build=yes, if that option is preferred. (Separate data products may be more convenient for users working with already-large mosaics, where smaller files may be preferable for electronically sharing with collaborators, or when users have disk space limitations and need to move various sets of data products to alternate locations.)
Compare the science array of the drizzled pipeline product (i.e., image_drz.fits[sci,1]) with the science array derived during reprocessing (i.e., image_drz_sci.fits).
Does the MDRIZSKY header keyword seem correct?
Did astrodrizzle flag excessive numbers of pixels as cosmic rays?
The questions above are addressed in Section 8.1. Additionally,
Is there a correlated noise pattern in the sky background that resembles a “screen door” pattern? This type of correlated noise can be caused in two ways: by shrinking the “pixfrac” too small, or by failing to subtract the sky background. For details on each of these effects, please refer to the example in Section 7.2.
Maintaining a larger final_pixfrac ensures overlap between pixels and less correlated noise in the drizzled science array. When final_pixfrac has been shrunk too far, a “beating pattern” can be seen in the sky. While this pattern may look alarming to the eye, it does not significantly impact the photometric integrity of the drizzled products. In general, final_pixfrac values in the range 0.7 to 0.9 are usually optimal when the observations have been dithered (see Section 8.3.2 for details.). If a gain in resolution is not important for the program’s science goals, then final_pixfrac=1 will suffice.
As a general guideline, the sky subtraction step should be turned on. This step is necessary for optimal flagging of cosmic rays. Additionally, failure to remove the sky will lead to correlated noise in the drizzled images. (The size of this effect depends primarily on the variation in sky levels from one exposure to the next.) For details, please refer to the example Section 7.2. While some external software packages (such as daophot) may expect the sky level to be present, it should be removed for drizzle processing to avoid correlated noise and then (optionally) added back later, if so desired.
The questions above are addressed in Section 8.1 Additionally,
As a rule of thumb, statistics performed on the drizzled weight image in the region of interest should yield an RMS value (standard deviation) that is less than 20% of the median value. This threshold is a balance between the benefits of improving the image resolution at the expense of increasing noise in the background. The final_pixfrac value should be small enough to avoid degrading the final drizzle-combined image, but large enough that when all images are “dropped” onto the final frame, coverage of the output frame is fairly uniform. In general, final_pixfrac should be slightly larger than the final output scale to allow some “spillover” to adjacent pixels. This will help avoid “holes” in the final product when a given pixel has been flagged as bad in several frames.
Are there “holes” in the final weight image?
“Holes” in the weight image, regions with no valid input pixels, may indicate that the user should rethink which flt.fits DQ flags should be treated as good pixels. Because astrodrizzle was designed for reprocessing with multiple instruments, the default value for the “bits” parameter is set to “0” in driz_sep_bits and final_bits. This is generally an over-aggressive approach if only a few input images are being combined. The “bits” parameters indicates which suspect pixels to keep, and the user can decide which strategy is best based on the number of input frames and the dither pattern used. Ultimately, one wants to avoid having too many pixels with no good input pixel in the stack. For more information on selecting the appropriate DQ bits values, refer to Section 6.3.3.
On the other hand, “holes” may indicate that the user has chosen too aggressive a value for final_pixfrac. For routine observations containing several dithered images, the “pixfrac,” or “drop” size, should be between 0.5 and 1.0, depending on the number of input images and the dither pattern. In general, values in the range 0.7 to 1.0 are optimal, but the user should experiment to see what is best for the combination of data in hand and the desired science to be obtained from it. In some cases, pushing the envelope a bit further may yield more beneficial results. In rare cases such as the HUDF, an extremely large number of images were very well-dithered in subpixel space, and this allowed the use of a point kernel (final_pixfrac=0), but this is an extremely rare case. Most observers will have far fewer images than this, however, and a more routine and conservative use of “pixfrac” and “scale” is usually in order. For more information, see Section 6.3.3, as well as the examples in Sections 7.2 and 7.4.

Table of Contents Previous Next Index Print