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.1 Inspecting the Drizzled Products from MAST

Should the images be reprocessed? Are the pipeline drizzled products adequate for the science goals?
Should the images be reprocessed? Are the pipeline drizzled products adequate for the science goals?
In general, pipeline drizzled products should only be used as “quick-look” products. Reprocessing is highly recommended to achieve the most scientifically accurate data products. Four main areas for improvement include: (1) image alignment, (2) sky subtraction, (3) cosmic ray rejection, and (4) final image resolution.
AstroDrizzle ties together a substantial set of algorithms, each designed to accomplish a different task, and as such has a large parameter set. Pipeline products have been created using a default set of parameters that will work for a wide range of data. These default settings, however, will not produce the optimum science data quality for most programs, and those images will require post-pipeline processing. Additionally, MAST only creates drizzled products for images obtained in a single visit, so additional visits may only be combined together by reprocessing.
While single visit data with small POS TARG dithers (like the 4-point dither box) are usually aligned to better than 0.1 pixels, the drizzled products are created using the native detector plate scale, and with a drop size or “pixfrac” of 1.0. In these cases, the resolution of the drizzled products can be improved by fine-tuning the final_scale and final_pixfrac parameters.
Single visit data with large POS TARG dithers (for example, to create mosaics), on the other hand, usually have residual offsets of a few tenths of a pixel (and small rotations of a few thousandths of a degree.) When combining data from different visits (via manual reprocessing), tweaks to the image alignment are usually necessary since different sets of guide star pairs may have been used. Offsets of the same target at different rolls are typically ~0.3 to 0.5 arcseconds. For more information, see Appendix B:HST Pointing Accuracy and Stability.
Poor alignment can lead to poor cosmic ray rejection, and when astronomical sources are flagged as cosmic rays, photometric accuracy of the final data products will be compromised. Additionally, a poor estimate of the sky background, for example in images where a bright target fills the frame, may also impact the accuracy of cosmic ray rejection, and in turn, the resulting photometry.
Listed below are some problems that users may encounter, and suggestions on how to address these issues during reprocessing. For more discussion, please also refer to Section 8.3.
Do the drizzled products look “clean?”
The science extension “image_drz.fits[sci,1]” from the drizzled MAST data products should be inspected for any obvious anomalies and compared with the calibrated data products, “image_flt.fits” which are used as input to the astrodrizzle task. For any anomalies which are not addressed in this chapter, please contact the STScI Help Desk (
Are there any irregularities (or discontinuities) in the sky background?
A discontinuity in the sky could be caused by improper sky subtraction near a bright target when a large dither has been obtained as part of an associated data product. Alternately, when the target fills the field of view and there is no “blank” sky to use for determining the sky background, the sky may be over-subtracted. In such instances, it may be necessary to adjust the sky determination parameters during reprocessing, or to instruct astrodrizzle to use a keyword containing an independently-determined sky value. For more details, please refer to Section 6.3.1.
Are the PSFs “round” and “narrow,” as expected?
Elongated PSFs in drizzled images may indicate that the alignment needs to be improved. A powerful new task called tweakreg (part of the drizzlepac package) can be used to improve the image alignment for data taken within a single visit or across multiple visits. Alternately, slightly elongated PSFs may be a result of the actual telescope focus at the time of observation. To view the focus history for your observations, users are encouraged to use the HST Focus Model Tool.
More information about the WFC3 PSF may be found in Sections 6.6.1 and 7.6 of the Wide Field Camera 3 Instrument Handbook for Cycle 20. Information about the ACS PSF may be found in Section 5.6 of the Advanced Camera for Surveys Instrument Handbook for Cycle 20.
Are there unusual patterns or clusters of bright pixels repeated across the image?
These are usually due to hot pixels which are not properly rejected. When the observer has made use of a standard dither pattern (i.e., a 4-point dither box), these artifacts will show up in the same pattern. To remedy this, it may be necessary to reprocess the data, changing the driz_sep_bits and final_bits parameter settings. For more details, please refer to Section 6.3.4.
Were the observations dithered?
Archival drizzled products are created using a conservatively-selected set of parameters, which include drizzling to the detector’s native plate scale and using a drop size where final_pixfrac=1.0.
When dithering was part of the observation strategy, the resolution of the drizzled products can often be improved by fine-tuning the final_scale and final_pixfrac parameters in the final astrodrizzle step. This is especially true when one of the standard HST pixel dither patterns was chosen to subsample the PSF. For more information, please see Section 6.3.4 and the examples in Sections 7.2 and 7.4 which describe how to improve image sampling for dithered observations.
Were observations obtained in multiple visits?
Tweaks to the image alignment are usually necessary when combining data from different visits (via manual reprocessing). Offsets of the same target at different rolls, and using different guide stars have typically been ~0.3 to 0.5 arcseconds. For more information on relative WCS alignment between visits, see “Updating the WCS Header Information”.
Using tweakreg to improve the image alignment will result in much better cosmic ray rejection. Even data taken in the same visit may often be improved by using the tweakreg task to sharpen the alignment since small changes in pointing can occur with guide star reacquisitions from orbit to orbit. In other less common instances, a loss of lock on a guide star(s) may introduce a small drift or roll which will need to be corrected.
Why is there a Moiré pattern in the sky background?
Correlated noise patterns are most often seen when just a few images are being drizzled or a small “pixfrac” has been used. These patterns are seen when the amount of correlated noise varies strongly between pixels. (Pixels with highly correlated noise tend to look less noisy than uncorrelated pixels.) For more details, refer to Section 2.3.
The best way to mitigate this effect is to acquire the observations using a dither pattern, or to use astrodrizzle to combine more frames from overlapping observations so that the correlated noise becomes out-of-phase and cancels out in the combined output frame.ハ
If the data is not dithered and more frames are not available for combination, users can try the lanczos3 kernel in the final drizzle step, which can help suppress correlated noise. Note that this option does not perform well in the presence of artifacts such as hot pixels and cosmic rays. If too few images are available for combining the frames to reject such artifacts, some “ringing” (a halo of negative pixels) may be seen around the sharp edges of these artifacts.
Does the MDRIZSKY header keyword seem correct when compared to an independent estimate using other software tools?
During pipeline processing, the sky background is estimated using a default set of parameters and is written to the image header in the science extensions [1] and [4] of the flt.fits image in the header keyword MDRIZSKY.
Many astronomical fields of view cover portions of the sky devoid of large objects, and as a result, the default sky subtraction parameters are sufficient. For observations of targets that fill the field of view, however, sky background may be overestimated. An inaccurate sky subtraction may compromise the accuracy of the cosmic ray rejection, and this in turn may impact the resulting photometry.
Two important parameters to consider when reprocessing are the lower and upper values for pixels that will be used to estimate the sky value. These should be set large enough to include the majority of pixels in the sky (substantially more than the FWHM of the sky distribution) but not so large as to include substantial signal from objects or cosmic rays.
If the user instead wishes to compute the sky using an alternate method outside of astrodrizzle, the skyuser parameter can be set to point to a keyword in the image header which gives a user-defined sky value. astrodrizzle will then assume that this sky value has already been removed from the flt.fits images prior to processing.
Did the pipeline flag excessive numbers of pixels as 4096 (cosmic ray DQ flag)?
Users are encouraged to blink the science array of the calibrated flt.fits images with its corresponding data quality array. Cosmic rays flagged during pipeline processing are assigned a flag value of 4096, and the accuracy of these flags should be inspected. For more details, refer to the example in Section 7.1. If primarily astronomical sources are being flagged, this could indicate a slight misalignment of the images. The WCS information can be corrected to account for these small offsets by processing the images with tweakreg.
If a regular “pattern” of cosmic ray flags is apparent over the entire image, this could be caused by improper sky subtraction. Instead of cosmic rays, the algorithm may be picking up noise in the sky background. For an example of this effect, see the example in Section 7.5.
Reprocessing will correct the problem of excessive or imperfect cosmic ray flagging when the resetbits parameter is set to 4096 (default). This parameter will reset those flags in the DQ array so that cosmic ray flags can be recomputed by the user during reprocessing.
Is the mean value of the weight image approximately equal to the total exposure time?
The weight image in pipeline-drizzled products (i.e., image_drz.fits[wht,1]) are weighted by the total exposure time of each pixel (final_wht_type=EXP), and the weight extension of the drizzled image can be considered an effective exposure time map. Regions of the image with drastically different weight values may indicate that only a fraction of the original images contributed to the final product. In this case, reprocessing is highly recommended. Other weighting methods (ERR, IVM) may be preferable for reprocessed data, depending on the science goals. For more information, see Section 4.2.12.
Does there appear to be an imprint of the target in the weight image?
In general, the weight extension of the drizzled product should contain a random distribution of pixels with lower weight, reflecting detector artifacts and cosmic rays which were excluded. When the sources themselves are flagged as cosmic rays, this often indicates a problem with the cosmic ray rejection, due either to an improper sky subtraction or to misalignment between input frames.
WFC3/IR images are the exception to this rule. IR data has an additional 5th extension (TIME) that contains the effective integration time associated with each corresponding science image pixel value. For calibrated datasets, the TIME array contains the combined exposure time of the valid readouts that were used to compute the final science image pixel value, after rejection of cosmic rays and saturated pixels from the intermediate data. When drizzled images are weighted by the total exposure time, the weight image will reflect the reduced exposure time in pixels which saturated in one or more samples. These often fall in the cores of bright stars and galaxies, resulting in an imprint of the target in the final weight image. This effect does not mean that reprocessing is required; it is simply a feature of WFC3/IR data, showing pixels where the detector was saturated.

Table of Contents Previous Next Index Print