7.3 Inspecting Drizzled Products after User Reprocessing

Are the reprocessing task parameters optimal?

The same set of checks discussed for Archival data should be performed for reprocessed data. 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 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 under-sampled.

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 (DQ) 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.

Examine the Drizzled Science Image

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 False 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 is set to True, 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., *drz.fits[sci,1] or *drc.fits[sci,1]) with the science array derived during reprocessing (i.e., *drz_sci.fits or *drc_sci.fits). Look over the below set of questions which are addressed above:

• Do the new drizzled products look "clean"?
• Are there any irregularities (or discontinuities) in the sky background?
• Are the PSFs "bound" and "narrow", as expected?
• Are there unusual patterns or clusters of bright pixels repeated across the image?
• Does the MDRIZSKY header keyword seem correct?
• Did AstroDrizzle flag excessive numbers of pixels as cosmic rays? 

A further question about the new reprocessed drizzled data: 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. 

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

Examine the Reprocessed Drizzled Weight Image

Similar to the questions above for the pipeline processed archival *drz.fits or *drc.fits images: 

• Is the mean value of the weight image roughly equal to the total exposure time?
• Does there appear to be an imprint of the target in the weight image? 

Further, for the reprocessed images, is the RMS of the weight image (near the target of interest) less than 20% of the mean (or mode)? 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 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 for situations when only a few input images are being combined. The two bits parameters indicate 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 a final_pixfrac value that is too aggressive. For routine observations containing several dithered images, the pixfrac or "drop" size, should be between 0.5 and 1.0 all 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 sub-pixel 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 and a more routine and conservative use of pixfrac and final_scale is usually in order.