For a multigroup drizzle-combined image, input images' header keywords are stored in the fourth extension.
The PyRAF task tprint can be used to see the keywords.
--> import pyfits
--> tab = pyfits.getdata('final_drc.fits',ext=4)
--> print tab['rootname'],tab['asn_id'],tab['mdrizsky']
['j9irw3fwq' 'j9irw3fwq' 'j9irw4b1q' 'j9irw4b1q' 'j9irw5kaq' 'j9irw5kaq']
['NONE' 'NONE' 'J9IRW4040' 'J9IRW4040' 'NONE' 'NONE']
[ 32.22661209 32.22661209 30.62865639 30.62865639 45.03836441 45.03836441]
6. How do I skip the sky subtraction step in AstroDrizzle?
Sky subtraction in AstroDrizzle is generally recommended because it enables optimal flagging and removal of cosmic rays. Therefore, for most image modes, AstroDrizzle pipeline processing performs sky subtraction (skysub set to True). The computed sky value for an image array, a non-zero number, is stored in the flt.fits/flc.fits image group header keyword MDRIZSKY. For observing modes that produce images with very low background, such as UV and narrow-band filters, AstroDrizzle pipeline processing sets skysub to False.
We strongly urge against turning off sky subtraction unless it's the option of last resort.
Images may be reprocessed using AstroDrizzle without sky subtraction, using the following two steps
For the input flt.fits/flc.fits images, manually set the header keywords MDRIZSKY to 0.0. In this example, the PyRAF command hedit is used.
--> hedit *flt.fits MDRIZSKY 0.0
--> hedit *flt.fits MDRIZSKY 0.0
Run AstroDrizzle with sky subtraction turned off; sky values will not be calculated and written to the MDRIZSKY keywords that were set to zero in step 1.
--> import drizzlepac
--> from drizzlepac import astrodrizzle
--> astrodrizzle.AstroDrizzle('*flt.fits', skysub=False, \
(Backslash symbol continues the command on the next line.)
If sky subtraction is turned off, the final_pixfrac parameter should be set to 1. Otherwise, variations in sky between images will add noise to the data.
Note: this text excerpt from page 70 of the PDF version of the DrizzlePac Handbook, Section 4.2.3, “Perform Sky Subtraction,” is incorrect:
However, for some science applications where the sky should not be removed, the final drizzle
step can be performed with no sky subtraction (skysub set to False in AstroDrizzle).
Please disregard this and use the procedure described above for turning off sky subtraction. A correction will be made in the next handbook.
7. Can I independently determine sky values in the flt.fits/flc.fits images?
Yes. There are situations where default pipeline settings will not work, for instance, when there is a bright
object in one of several image groups. User-determined sky values are also useful for images with large
extended objects, some mosaics, and varying backgrounds that are sometimes seen in Continuous Viewing
Zone (CVZ) images.
For each flt.fits/flc.fits science image extension, measure the sky value using a method that you
think best estimates the sky. Then, pick the lowest sky value to use in the procedures outlined below.
There are two ways to apply user-determined sky values in AstroDrizzle:
If the sky value has already been subtracted from the flt.fits/flc.fits science arrays, create a
new image group header keyword called SKYUSER, and assign the previously-determined sky value
to it using a task like hedit.
Then, when running AstroDrizzle, be sure to set the skysub parameter to
No so AstroDrizzle does not calculate its own sky value. (Note: there is a mistake in the
DrizzlePac Handbook, Section 4.2.3 regarding sky subtraction: please refer to FAQ item 5 for details.)
If sky values have been determined for each input image, but not subtracted from the flt.fits/flc.fits
images, the sky values can be written to a text file and provided as input to AstroDrizzle. The file should be
formatted to have two columns: image filename in column one; sky value in column two. This file name should
be specified in the AstroDrizzle parameter, skyfile (more information is available at the
DrizzlePac Handbook, Section 4.2.3).
In determining sky values, please keep this in mind:
- Sky values should be in the units of the flt.fits/flc.fits file. (This is also the units for the MDRIZSKY value.)
- For a set of images used to create a mosaic, there may be bright sources in some frames. Sky subtraction,
in those cases, can be done as follows:
- Determine the sky value in sections of the images that have sky.
- Pick the lowest sky value of all the images.
- Subtract that lowest sky value from the sky value of each of the other images (except that one image that
gave you the lowest sky value).
8. TweakReg doesn't find enough sources for a good fit because cosmic rays dominate over point sources.
If all images are in the same visit, the WCS information in each image header is usually enough to create a good
drizzle-combined image (however, be sure to verify this by closely inspecting images when blinking back and forth on the display.
If the images are across several visits, they must be aligned.
In sparse fields, cosmic rays that are mistaken for sources will create bad alignment solutions. One way to get around it is to
eliminate the cosmic rays. This can be done, albeit coarsely, by running AstroDrizzle to create cosmic ray-free images where
parameters are set such that pixels identified as cosmic rays in each image are replaced by the value from the median image.
An example of
this technique is available at the DrizzlePac web page.
For cases where there are no point sources, but enough small extended sources, SExtractor may be used to create a source catalog.
An example will soon be available at the DrizzlePac Examples page.
9. How do I align WFPC2 data when the chips have different plate scales?
The PC1 scale is 0.046"/pixel. WF2, 3, and 4 are 0.1"/pixel.
TweakReg was designed to account for these scale differences. By default, it adopts the PC1 scale. For the best image
alignment, use all four image groups so more objects can be included in the alignment solution. Alternately, a reference
image may be specified so that TweakReg can adopt its plate scale and reference position.
When you're satisfied with the alignment solution derived by TweakReg, there are several ways to drizzle the images,
depending on your science goals. If the object of interest is only in the PC, that chip image may be drizzled alone.
If the image extends over all four chips, the drizzling strategy would depend on your science. For precise photometric
information, it is best to drizzle each chip separately because each detector has a unique sensitivity, given by the
keyword PHOTFLAM. When more than one image group is drizzle-combined (i.e., like drizzling WF2 and WF3 chips
together), the PHOTFLAM value of the output image is an average of the input chip PHOTFLAM values.)
An example of running AstroDrizzle on WFPC2 data will soon be available at the
DrizzlePac Examples page.
10. How do I align images from two different detectors in TweakReg?
Note: when aligning images taken with different filters, some sources appear in one image but not the other.
It's useful to transform the catalog created in (b) using the DrizzlePac task, PixToPix, and overlay it on the second image
set to only select objects that appear in both images.
11. How do I deal with CTE in my TweakReg solutions?
You first need to decide on the common plate scale that will be adopted for both detector images. That, in turn,
depends on how much resolution you could get from drizzle-combining an image set without compromising
data quality. The drizzled-combined image set that gives the lower resolution should be adopted for the
alignment of both detector image sets. For example, let’s say one image set is an ACS/WFC 4-point sub-pixel dither, with a native scale of
0.05”/pix). The second image set could be the same source imaged in WFPC2 using a 4-point dither.
It may be possible to create a drizzle-combined WFPC2 image with a
final_scale of 0.08”/pixel (in comparison, the WF native scale is 0.1”/pixel).
Therefore, to align the image taken in these two different detectors, use the larger of the
two scales, final_scale=0.08 since the WF resolution cannot be reduced any further.
For one image set, create a “master image” by drizzle-combining all the images for that detector,
using a decided-upon final_scale, as discussed in (a). If the images in that set were taken over
several visits, they should first be aligned using TweakReg to a common WCS (and when those images are
subsequently drizzled, make sure the AstroDrizzle parameter updatewcs is set to No
or AstroDrizzle will overwrite the WCS created in TweakReg).
Create a “master source list” from the master image created in (b), using source-finding software
like daofind or SExtractor. (Alternately, if TweakReg had been run to align the images, it may be possible
to use one of the source catalogs that it generated, in units of RA and Dec. in degrees. These files have the suffix sky_catalog.coo.)
Run TweakReg on the second image set so that it aligns with the master image created in (a). Set the parameters as
you normally would for that detector, except set the parameters refimage and refcat
to the previously-created master image created in (a) and master source list created in (b), respectively. TweakReg
will compute a new WCS that's aligned with the other detector, and will update the image headers of the second
detector with that new information.
Drizzle-combine the second set of images, setting AstroDrizzle parameter final_wcs=Yes, and
specify the master image created in (a) in the parameter final_refimage.
CTE sometimes manifests as a discontinuity in the dy vs y TweakReg plots. As long as sources are evenly
distributed over the field of view, the effect will average out. Alternately, you could adjust the threshold
parameter in ImageFindPars (a task associated with TweakReg) so that only bright sources are used.
For ACS/WFC, flc.fits images, which have CTE trails removed, may be used instead of flt.fits images.
12. My TweakReg fit RMS is larger than 0.1 pixels. Is it okay?
For ACS/WFC and WFC3/UVIS, the fit RMS should be below 0.1 pixels, ideally around 0.03 pixels. Since WFC3/IR has
a larger pixel scale, its target RMS can be a little larger. For WFPC2, the default pixel scale is that of the PC, but in many
cases, most objects will be in the WF chips. Therefore, a TweakReg RMS of about 0.2 pixels is the equivalent of 0.1 pixels
at the WF scale.
High RMS values may occur if (1) there are insufficient objects for the alignment solution, (2) there are too many cosmic
rays identified as sources, (3) drizzling is done to a non-native detector scale, (4) you're aligning images across detectors,
and (5) the data is undersampled.
13. How do I evaluate the quality of my drizzled images, to make sure that the final_pixfrac
and final_scale I’ve selected have not degraded my image?
If there are insufficient objects for the alignment solution:
In ImageFindPars, reduce the threshold value, but do it cautiously; if it is too low, TweakReg will
pick up warm pixels and other artifacts as sources.
If it's absolutely necessary, slightly reduce the number of objects in TweakReg’s minobj
parameter. Be sure to check that the objects are evenly distributed across the field and not concentrated in one area.
If TweakReg is not picking up real targets, which often happens when there are too many cosmic rays, create your own
catalog of objects for each image, make a list of those catalogs to a file, and enter the name of that file to the TweakReg
parameter catfile. Each line of this file will contain the name of an input image in the first column, and
the remaining columns will provide the names of the source catalogs for each chip in order of the science extension numbers.
If there are too many cosmic rays identified as sources, try using cosmic ray-free images in TweakReg. This technique
is explained in example 6
at the DrizzlePac web site.
Drizzling to a non-native detector scale or aligning images across detectors: this is done if sub-pixel dithered images are
drizzled to a smaller scale, or when images are drizzled to a larger scale (such as drizzling UVIS images to the IR scale for
aligning images). Try different values for the final_scale and final_pixfrac parameters,
depending on the sub-pixel dither pattern and number of images.
For undersampled data, use a smaller value for conv_width in ImageFindPars. Determine that value by
measuring the FWHM of a point source in an image and multiplying it by 2.
Drizzle-combined images with unsuitably low final_pixfrac and final_scale values
show degraded PSFs and noisy images.
As a general guideline, statistics of the drizzled weight image in the regions of interest should have a RMS value
(standard deviation) that is less than 20% of the median (mid-point) value. This threshold balances the benefits of
improving image resolution at the expense of increasing noise in the background. However, weight image statistics
alone are not enough; also look for large deviations in weight image values as this could indicate a processing problem.
If there are point sources in the image, check the quality of the PSF. In the median image, verify that the images were
properly registered. PSF width and shape should appear “round” and “narrow” over the
field of view.
Inspect the overall image appearance. If final_pixfrac is too small, the image will have holes where
there was little or no flux contribution from the input images. A similar effect is also seen when driz_sep_bits
and final_bits are set to 0, meaning that any pixel with a DQ flag greater than zero is treated as a
bad pixel. Unless you are combining a very large number of images, flagging every pixel greater than zero as bad pixels
is overly aggressive because not all DQ-flagged pixels are bad.
For sub-pixel dithered images, AstroDrizzle can provide improved sampling of the PSF relative to the individual input
images. This is especially important for wide field HST cameras such as ACS, WFC3/UVIS, and WFC3/IR, where the size
of a native pixel is comparable to the PSF’s full width at half maximum (FWHM). Ideally, if there are enough
sub-pixel dithered images processed with appropriate final_pixfrac and final_scale
values in AstroDrizzle, a PSF FWHM of about 2 to 2.5 indicates the data is well-sampled. Please see
Example 2 at the
DrizzlePac web site for more information about optimizing AstroDrizzle parameters to improve spatial resolution.
14. Which data quality flags should I use in AstroDrizzle?
AstroDrizzle is part of the On-The-Fly Reprocessing (OTFR) system. If your images are part of an association—like
a dither pattern—the HST calibration pipeline will drizzle-combine those images. During this processing stage,
cosmic rays identified by AstroDrizzle are recorded in the flt.fits/flc.fits image data quality (DQ) arrays with the
bit value 4096. As a result, the Archive delivers a drizzle-combined product (drz.fits/drc.fits), as well as
flt.fits/flc.fits images that have cosmic ray flags in their DQ arrays.
During reprocessing with AstroDrizzle, you may choose to use parameters that are different from those used in OTFR
pipeline processing (those values are stored in the MDRIZTAB reference file). In some cases, you may wish to use
TweakReg to improve image alignment. Some of these changes will affect how cosmic rays are identified. Therefore, we
recommend that the cosmic ray flag (4096) in the original Archive flt.fits/flc.fits image DQ arrays be reset as
good pixels (0) so they can be re-identified as cosmic rays under alternate AstroDrizzle parameter settings, or after
realigning the input images. This is done by setting the parameter resetbits to 4096 (default value).
Depending on the instrument, dither pattern, and number of images to be drizzled, there may be other DQ flags that
you may also wish to treat as “good” pixels. These are set using the AstroDrizzle parameters driz_sep_bits
For ACS and WFC3 CCDs, the pipeline default parameter values (which are stored in the MDRIZTAB reference file) for
driz_sep_bits and final_bits are 96. It is the sum of two DQ bit values: 64 for warm
pixels, and 32 for CTE tails (for a more detailed definition of these flags, please refer to the respective instrument
Note, however, that the AstroDrizzle task in the DrizzlePac package, used for reprocessing, has different default values
from the instrument-specific defaults stored in the MDRIZTAB reference file. The task used for reprocessing has
parameter values that generally cover as many scenarios as possible, and may not be optimal for your data. This is why
we recommend that MDRIZTAB reference file values be used as a starting point for reprocessing. For instance, in the callable
AstroDrizzle task, driz_sep_bits and final_bits are set to 0, meaning that any pixel
with a DQ flag greater than zero is treated as a bad pixel. Unless you are combining a very large number of images,
flagging every pixel greater than zero is over-aggressive because not all the DQ-flagged pixels are bad.
Note: the stsci.tools module has a task to unravel summed bit values. For example, to find the individual bit value flags for 352:
--> import stsci.tools
[32, 64, 256]
Here, the value 352 represents bit values 64, 32, and 256, for warm pixels, CTE tails, and saturation, respectively.
These are some suggested settings for driz_sep_bits and final_bits.
Values in parenthesis depend on the imaging mode, data analysis goals, and image aesthetics.
15. How do I deal with saturated objects?
- ACS CCDs: 64 for repaired warm pixels; 32 for CTE tails; (256 for saturated pixels).
- WFC3/IR: 64 for warm pixels; 512 for the ‘blob’ feature; (256, if saturation occurs in the
first read, as determined by calwfc3).
- WFC3/UVIS: 64 for warm pixels; 32 for CTE tails; (256 for saturated pixels)
- STIS/CCD: (256 for saturated pixels)
- WFPC2: 1024 for repaired warm pixels; (8 for saturated pixels)
- NICMOS: 16 for ‘grot’; (64 for saturated pixels)
Saturated objects are flagged in the data quality file. For the cosmic ray mask steps, we recommend not
entering the saturation bit value (256, for ACS and WFC3/UVIS) in the parameter driz_sep_bits
so that the saturated pixels will be included in the median image. That will make it easier to distinguish
them from cosmic rays during AstroDrizzle’s cosmic ray mask creation.
In the final image combination step, if you want the saturated pixels to remain in the final combined image,
set the final_bits parameter to 256 (the saturation bit flag for ACS and WFC3/UVIS,
but for WFPC2 the saturation flag is 8) to tell AstroDrizzle to treat saturated pixels as good pixels. If this flag
is not entered in final_bits, be sure to set the final_fillval value to a
very negative number, like -9999, so that saturated pixels are easily identifiable in the final drizzle-combined image.
A note about saturated pixels: in ACS, WFC3 and WFPC2 CCDs, in certain configurations, counts can still
accumulate in a highly linear manner, making it possible to do photometry on saturated stars when using a
gain that samples the full well depth. (See the instrument data handbooks for more information.) Therefore,
depending on your observations, you may wish to consider saturated pixels as “good” pixels
that will not be rejected in AstroDrizzle. For such a scenario, for WFC3 and ACS images, driz_sep_bits
and final_bits could be set to “352” or “64,32,256” so that
warm pixels, CTE tails, and saturation, respectively, are treated as good pixels in AstroDrizzle. (For WFPC2
images, the saturation flag is 8.)
16. What are the units of my data?
For ACS and WFC3, the units for drizzled data (drz.fits/drc.fits) is recorded in the header keyword
BUNIT. By default, the data is in electrons/sec.
Units for the final drizzle-combined image are set in the parameter final_units.
The choices are cps (counts per second, the default) or counts.
The type of ‘count’ is set by the parameter proc_units--its default value,
native is the image units specified by the header keyword BUNIT in the input
flt.fits/flc.fits images; for ACS and WFC3, BUNIT is set to electrons, for WFPC2 c0m.fits
files, that keyword is set to DN (Data Number).
17. Each dithered image in my association has the same long exposure times. But I also included
one very short exposure to get an unsaturated image of bright stars because they’re saturated in
the long exposure images. How do I combine long exposures with the very short exposure?
Drizzle-combining exposures of very different lengths is generally not recommended, especially when
the AstroDrizzle parameter, final_wht_type is set to EXP (so the
final drizzle-combined image is weighed by exposure time). For such combined images, where
AstroDrizzle tries to use a portion of the input short exposure and portions of the input long exposures,
the PSF boundary in the output drizzled image shows a discontinuity. This is due to the short exposure
being underweighed by AstroDrizzle, compared to the long exposures. As a result, it is very difficult
to model the PSF because the radial profile is compromised, and it makes the flux too low at the boundary
In some cases, depending on the instrument configuration, saturated stars will provide accurate
measurable flux values; please refer to item 14 in the FAQ for additional information.
Our general recommendation is that only exposures of similar lengths, different within less than 10%
of exposure time, be drizzled-combined. In such cases, a weighting based on final_wht_type
set to ERR, instead of EXP, would yield better results
(see Section 4.2.8 of the DrizzlePac handbook
for details about this parameter).
If there is a short exposure image (or several short images) within an association for a dither pattern,
the short exposure image(s) can be drizzled to create a separate short exposure product. If an object
saturates in a long exposure image, it’s likely to produce good quality photometry in the short
exposure drizzled image However, if the image has to be enhanced for cosmetic purposes (not for
science measurements), saturated pixels in the long exposure drizzled image can be replaced with
pixels from the short exposure-drizzled image using a PyRAF task like imreplace.
18. What do I do about bad pixels in the final image, those pixels that have no “good”
contributions from all the input images?
“Bad” pixels in a final-drizzled image have a weight of zero, meaning that all the input image
contributions to them were also bad pixels. If the image is used for data analysis, select a
driz_sep_fillval and final_fillval value that is a large negative number,
like -99999. That way, if the object is measured using automated photometry software, anomalous results from
the high negative number can be easily clipped out. For aesthetics, like an image for a press release, use the
value none for final_fillval so that the output pixel has a value that
assumes a non-zero weight.
19. Can TweakReg combine multi-epoch images of a crowded field (like the core of 47 Tuc), spaced
over long periods of time, with WCS differences as much as 100 pixels?
There are a couple of ways to do this, but try method (1) first.
20. My image looks terrible! It’s noisy, still has cosmic rays, and the object appear multiple times.
Set the search radius to a large value, like 10 arcsec, based on what you think is the biggest offset.
TweakReg uses a 2-D histogram method for finding a common shift for sources. For images with a large
number of sources, it can be quite effective at excluding random sources (cosmic rays) and spurious
objects (false detections along diffraction wings).
Use only bright unsaturated stars by setting upper and lower flux limits for the object searches, using
the ImageFindPars parameters peakmin and peakmax.
If the image is noisy, check the weight image to see if the RMS of the mean weight value is under 20%
at areas of interest in the science image. If it’s not, you may have picked final_pixfrac
and final_scale values that are two small, causing output pixel gaps where there are no
contributions from any input images. Try re-drizzling with higher final_pixfrac and
If there are a lot of cosmic rays in a small set of input images, some sources may be misidentified as cosmic rays,
resulting in those PSFs having chopped-off peaks. Try adjusting the combine_nsigma,
combine_nlow and combine_nhigh AstroDrizzle parameter values to get
more optimal cosmic ray rejection parameter values for your images.
Badly aligned images can cause bad cosmic ray flags. Use TweakReg to align the images.
Incorrectly-applied sky subtraction, if sky levels are quite different within an image with two or more detectors,
also create false cosmic ray flags. In those circumstances, run AstroDrizzle without sky subtraction or use
manually-measured values. More about doing this is available in item 6 of the FAQ.
21. Astrodrizzle is crashing because there is not enough memory.
If there is limited RAM on your machine, as is often the case for laptops, set the AstroDrizzle parameters
build to no and context to no to
reduce memory use. This will create the science and weight arrays as separate images, and the context image
will not be created. If this doesn't help, you'll have to use a machine with more memory.