4.6 Refining the Shifts: Manually and with Tweakshifts
The ability of MultiDrizzle to properly align dithered observations relies on the accuracy of the header WCS information. Unfortunately, there are times when those WCS values may be slightly inaccurate, resulting in a mis-alignment of the final drizzled product. For example, one might wish to combine observations taken in different visits. If the visits were separated by a substantial time interval, then the telescope probably used different guide stars. Due to limitations in the intrinsic accuracy of the Guide Star Catalog, this can lead to WCS coordinates that differ by up to 1-2" between visits, and up to 1" between visits when using Guide Star Catalog 2. Also when all exposures that one wishes to combine were taken in a single visit, it might still be important to correct for relative shifts between images. Even in two-star fine-guiding mode, thermal effects on the telescope can cause slow drifts that can build up to ~50 mas over a few orbits (or in rarer occasions within a single orbit). This corresponds approximately to 1 WFC pixel or 2 HRC pixels. Such shifts between exposures can degrade image quality and corrupt cosmic-ray rejection when left uncorrected.
By deriving shifts based on the position of objects in the data, the user may refine the shifts computed from the WCS header information to create a precisely-aligned drizzled product. Many observers have developed their own methods of comparing images and computing offsets. We are also developing an automated script, Tweakshifts, to perform these tasks, which is available as a prototype and is summarized in Section 4.6.5. The conventions described here should support the majority of users, making it a simple matter to incorporate shift computations into MultiDrizzle.
4.6.1 Delta Shifts
A delta shift is defined as the residual shift required to align sources, after applying the offsets implied by the header WCS. Delta shifts may be determined by separately drizzling images onto a common WCS frame with the same central RA/Dec. This is performed in the 'driz_separate' step of MultiDrizzle or by setting the PyDrizzle parameter 'single=yes'. Object lists derived for each drizzled image may then be matched and fit to derive a single delta shift for each image.
Delta shifts are defined to be in the 'input' frame of reference when the distortion-corrected, drizzled image has the same orientation and scale as the distorted image. Shifts will be in the 'output' frame of reference if any rotation or scaling was applied while drizzling. When the shifts are given in the 'output' frame of reference, MultiDrizzle requires the specification of the reference image to properly account for any orientation and scale changes.
4.6.2 Absolute Shifts
An absolute shift, on the other hand, is the total shift between two images and includes offsets implied by the header WCS. Absolute shifts may be determined by separately drizzling images to their own unique WCS frame. MultiDrizzle will use the header information to optimally place the drizzled image in the frame.
To derive absolute shifts in the 'input' frame of reference, each distorted image is drizzled separately, and MultiDrizzle uses the unique WCS information from each frame to choose the central RA/Dec, the image orientation and final image size. No additional rotation or scaling is applied while drizzling. (Alternately, the user may catalogue sources in each distorted image and then apply the distortion model to the X/Y positions. The new task TRAN has been developed for the STSDAS DITHER package and will perform coordinate transformations back forth between distorted and undistorted space.
Absolute shifts in the 'output' frame of reference may be computed by separately drizzling each distorted image, with the same rotation and scaling, onto a unique WCS frame. Target lists in each drizzled image may then be matched to derive the absolute shifts.
Figure 4.10: Delta Shifts in the 'input' and 'output' frame of reference.
Figure 4.11: Absolute Shifts in the 'input' and 'output' frame of reference. The direction of north is indicated by the bold arrows.
4.6.3 Constructing the 'shiftfile'
MultiDrizzle is capable of interpreting shifts in units of pixels or arcseconds. A pixel shift is the difference in the X/Y pixel position of a source in a given image compared to the reference image. The shifts are interpreted with respect to each image's X/Y pixel reference position and require the specification of 'input' or 'output' frame of reference.
An arcsecond shift is the difference in the RA/Dec coordinates of a source in a given image compared to the reference image. Object coordinates must be derived after correcting for distortion. These shifts are not angular offsets on the sky, rather they are changes in the RA/Dec of the reference pixel and do not require any 'cos(Dec)' adjustment. Arcsecond shifts are a natural result of using the RA/Dec coordinates of image sources. They eliminate any ambiguity with the chosen reference frame since RA/Dec coordinates are fixed on the sky. Arcsecond shifts are interpreted as offsets in the direction of increasing RA and Dec.
Sign Conventions
The shifts are defined in terms of how the targets in the image need to move, rather than on how the telescope would need to move, to allow precise registration. PyDrizzle assumes that the shifts were computed as 'image - reference'. For example, when using geomap to cross-correlate two source lists, the reference image coordinates will be in the first two columns and the input image coordinates will be in the last two columns.
Use of Shifts in Association Tables
The shift file is an ASCII file containing the user-computed shifts for a set of images and is used for updating the offsets in the association table. Observers may use either the ASN table delivered by the pipeline or create/modify their own table as described in Section 4.8. MultiDrizzle uses the buildasn task to incorporate information from the shift file into the association table. The shift file uses the following format:
|
# units: pixels Values: pixels (default), arcseconds
# frame: input Values: input (default), output
# form: absolute Values: absolute (default), delta
# reference: <filename> Only required when 'frame = output'
filename1 xshift1 yshift1 [rotation1]
filename2 xshift2 yshift2 [rotation2]
|
The first three lines specify the units, the frame of reference, and the form of the shifts, and only those lines with non-default values are necessary. While the '#' symbol is required, the 'Values:' comments are not. When shifts are given in the 'output' frame of reference, it is necessary to specify the name of the reference image used.
The following is an example of a shift file in units of pixels, measured in the 'input' frame of reference, with the form specified as 'delta' shifts. An x and y shift and a rotation (in degrees) is specified for each dataset. If only a simple shift is required, then the rotation column need not be specified.
|
#units: pixels
#frame: input
#form: delta
j8c0b1skq_flt -2.4 -1.2 -0.002
j8c0b1snq_flt -4.3 -2.3 0.001
j8c0b1sqq_flt -6.9 -3.5 0.003
|
Using this shiftfile as input, the buildasn task will update the ASN table as indicated in Table 4.3.
Table 4.3: Association table updated with user-defined shifts.
| MEMNAME |
MEMTYPE |
XOFF- SET |
YOFF- SET |
XDELTA |
YDELTA |
ROTATION |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The shift file can contain shifts for files other than those contained in the ASN table. In that case, only those entries found in the ASN table will be used to update the table. Thus, a single shift file can be generated for a whole set of observations which are represented by multiple association tables.
Association (ASN) tables can support either delta shifts or absolute shifts in units of pixels or arcseconds. Absolute shifts are stored in columns 'XOFFSET' and 'YOFFSET', while delta shifts are stored in columns 'XDELTA' and 'YDELTA'. The 'ROTATION' column is also available if a simple shift does not produce ideal registration and indicates how much should be added to the image's ORIENTAT to get proper alignment.
If absolute offsets are provided in the shift file, PyDrizzle will populate the OFFSET columns in the association and fill the DELTA values with zeroes. Similarly, if delta shifts are provided, those values will be used to populate the DELTA columns and the OFFSET columns will be zero. If shifts are given in both the OFFSET and DELTA columns, the OFFSET column will be applied and the DELTA columns will be ignored. This convention used by buildasn eliminates any ambiguity as to which values are applied to the data. Editing the ASN table directly will then allow the user to further update the offsets using either delta or absolute shifts.
4.6.4 Example 5: Improving the Image Registration for Different Visits
'Delta Shifts' in the 'Input Frame'
For observations with large dithers or for images which were taken at nominally the same pointing but during different visits, users may wish to fine-tune the image registration, improving on the world coordinate system in the image header. In this case, the images must be separately drizzled and the position of stars cross-correlated. The derived shifts may then be used to update the image association prior to drizzling the final product. More generally, if the drizzle combined product of multiple exposures have PSFs that are not round or as sharp as expected, a likely culprit is the need for improved shifts.
The following example uses WFC observations from separate visits in program 9018: visit 61, exposure 02 (j8c061020_asn.fits) on 19April 2002 and visit C1, exposure 01 (j8c0c1010_asn.fits) on 09May2002. Each observation is CR-SPLIT with an exposure time of 45 seconds in F606W. The images are at the same pointing, use the same guide stars, and are at the same ORIENT. We describe the steps required to register the calibrated CRJ products from separate visits. However, the individual FLT files could be alternatively used if improved registration of each CRJ image is desired.
- First, we use the CRJ images from visits 61 and c1 to create a new association table with the suffix 'v61c1'. We advise using the tprint task to verify the contents of the association.
|
pyraf> import buildasn
pyraf> buildasn f606w_v61c1 suffix='crj.fits'
pyraf> tprint f606w_v61c1_asn.fits
# MEMNAME MEMTYPE MEMPRSNT XOFF YOFF XDELTA YDELTA ROTATION
j8c061021 EXP-DTH yes 0. 0. 0. 0. 0.
j8c0c1011 EXP-DTH yes 0. 0. 0. 0. 0.
f606w_v61c1 PROD-DTH no 0. 0. 0. 0. 0.
|
- Next, we separately drizzle the images onto a common output WCS. This is achieved by setting the MultiDrizzle parameter 'driz_separate'=yes. Any differences in the aperture RA and Dec, any POS-TARG offsets, or any orientation differences will be automatically accounted for by MultiDrizzle which uses the header WCS to transform the images. The drizzled CRJ products are appended with the suffix '_single_sci.fits'.
|
pyraf> multidrizzle f606w_v61c1_asn.fits static- skysub+ driz_separate=yes driz_sep_bits=96 median- blot- driz_cr- driz_combine-
|
- Using point sources in each image, we create and cross correlate coordinate lists from each visit. For example, we used daofind to create star lists for each DRZ product separately. Then we used xyxymatch to match the coordinate lists within a user specified tolerance. Finally, we use geomap with the matched coordinate list to compute the transformation required to map the reference coordinate system to the input coordinate system, allowing for a shift and/or rotation. We create the following "shiftfile", a simple ascii table called 'shift.txt', using the derived offsets. The shifts were derived in units of pixels and are in the 'input' frame of reference since no additional rotation or scale terms were introduced while drizzling. The derived shifts using the above methods are delta shifts because the images were drizzled onto a common WCS.
|
#units: pixels
#frame: input
#form: delta
j8c061021_crj 0.00 0.00 0.000
j8c0c1011_crj 24.46 -56.54 0.001
|
- Next, we delete and rebuild the previous association table, this time specifying the derived offsets via the shiftfile. To verify that the association has been correctly populated, we use the tprint command. Note that the delta shifts appear in the
DELTA columns in the association table.
|
pyraf> delete f606w_v61c1_asn.fits
pyraf> buildasn f606w_v61c1 suffix='crj.fits' shiftfile='shift.txt'
pyraf> tprint f606w_v61c1_asn.fits
# MEMNAME MEMTYPE MEMPRSNT XOFF YOFF XDELTA YDELTA ROTATION
j8c061021 EXP-DTH yes 0. 0. 0. 0. 0.
j8c0c1011 EXP-DTH yes 0. 0. 24.46 -56.54 0.001
f606w_v61c1 PROD-DTH no 0. 0. 0. 0. 0.
|
- Finally we run MultiDrizzle on the new image association. The two CRJ images are combined to create a single DRZ image called 'f606w_v61c1_drz.fits'.
|
pyraf> multidrizzle f606w_v61c1_asn.fits final_bits=96
|
'Absolute Shifts' in the 'Output Frame'
As a continuation of the previous example, we illustrate how to specify absolute shifts in the 'output' frame of reference.For example, this is the case when drizzling an observation to an output orientation of North up.
- First, the CRJ images from each visit are drizzled to separate output images. Absolute shifts are determined by separately drizzling images onto their own unique WCS frame. In this example, an additional rotation is applied to the drizzled images so that north is oriented up.
|
pyraf> pydrizzle j8c061021_crj.fits output=j8c06102X_drz.fits bits=96 rotate+ orient=0
pyraf> pydrizzle j8c0c1011_crj.fits output=j8c0c101X_drz.fits bits=96 rotate+ orient=0
|
- As in the previous example, we create and cross correlate coordinates lists from each visit using point sources in each image. We create the following "shiftfile", a simple ascii table called 'shift1.txt', using the derived offsets. Note that because we are using absolute shifts, we must specify the name of the reference image.
|
#units: pixels
#frame: output
#form: absolute
#reference: j8c06102X_drz.fits
j8c061021_crj 0.00 0.00 0.000
j8c0c1011_crj -41.64 45.51 0.001
|
- Next, we build a new image association using the two CRJ files and the derived shift file.
|
pyraf> import buildasn
pyraf> buildasn f606w_v61c1rot suffix='crj.fits' shiftfile='shift1.txt'
|
- To verify that the association has been correctly populated, we use the tprint command. Notice that the absolute shifts have been correctly added to the
OFFSET columns, not the DELTA columns.
|
pyraf> tprint f606w_v61c1rot_asn.fits
# MEMNAME MEMTYPE MEMPRSNT XOFF YOFF XDELTA YDELTA ROTATION
j8c061021 EXP-DTH yes 0. 0. 0. 0. 0.
j8c0c1011 EXP-DTH yes -41.64 45.51 0. 0. 0.001
f606w_v61c1rot PROD-DTH no 0. 0. 0. 0. 0.
|
- Finally we run MultiDrizzle on the new image association, specifying a rotation such that north is up. The two CRJ images are combined using the updated shift information to create a single DRZ image called 'f606w_v61c1rot_drz.fits'.
|
pyraf> multidrizzle f606w_v61c1rot_asn.fits final_bits=96 rotate+ orient=0
|
4.6.5 Tweakshifts
While manually deriving the shifts provides the greatest degree of control and flexibility, the extensive amount of book-keeping required can also make this relatively time-consuming. We are therefore developing a new task, Tweakshifts, which is available as a prototype release within Pyraf/STSDAS V3.4 or later (as of November 2005). Not all functional modes of this task are available yet, but it has been tested for basic scenarios, such as the example described here.
Tweakshifts can be given several different types of files as input, specified in the same way as for MultiDrizzle. In this example we provide it with an association table containing a set of FLT files, although it could also have been a list of FLT files, or an ASCII file containing the names of the FLT files, specified in the same way as for MultiDrizzle.
Tweakshifts then needs to be told what method to use in determining the shifts, using the findmode parameter. It can use essentially two methods: (1) cross-correlation, which would be appropriate for large diffuse targets, very crowded fields, or planetary targets; or (2) cataloging, which is appropriate for less crowded fields, either stellar or extragalactic. Cross-correlation is currently made available on an experimental basis only and will be described more fully in a future update. Cataloging is more generally used, and either SExtractor or DAOfind can be used, the former being more appropriate for extragalactic fields containing mostly extended sources, while the latter is better suited to stellar fields. The parameters to DAOfind are directly accessible from the Tweakshifts parameter list, while those for SExtractor are available as the sextractpars pset. The default values for these parameters are chosen to provide useful results in most types of images (more than at least 20 - 30 sources per exposure, preferably 100 or more, and not too many saturated sources). If desired, the cataloging parameters can be adjusted to suit different types of datasets. In this simple example, Tweakshifts can be invoked as follows:
|
pyraf> tweakshifts f606w_v61c1rot_asn.fits output='shifts.txt' findmode='catalog' gencatalog='sextractor' fitgeometry='rotate'
|
In this case, the type of shift determination is constrained to measuring x,y shifts and a rotation (fitgeometry='rotate'). Other commonly-used options would consist of 'shift' (measuring only the x,y shifts) and 'rscale' (solving for x,y shifts, rotation, and a uniform scale change in x and y). The behavior of this parameter is the same as in the IRAF task 'geomap'. The shifts that are measured by Tweakshifts are stored in two different places:
- in the association table itself, where the shift and rotation columns are updated to reflect the cumulative shift and rotation if Tweakshifts is run multiple times
- in the output file ('shifts.txt'), which has the same format as described in Section 4.6.3, and contains only the shift values determined in the current run of Tweakshifts.
It is almost always desirable to run Tweakshifts at least twice, iterating on the shifts. This is simply because, on the second pass, more objects will likely be matched (since the shifts from the first run are being applied), so the resulting shifts will be more accurate, hence different, to those obtained on the first pass. It is worth checking that the shifts on the second pass are generally smaller than those obtained on the first pass, to ensure that more objects are being matched. Tweakshifts also produces catalogs of the objects when running in catalog mode, which should be examined and overplotted on the images to ensure that the correct objects are being cross-identified and used to determine the shifts.
When the input files are specified as FLT files, Tweakshifts will generate catalogs on the FLT files (in the distorted frame), then remove the distortion using the same algorithms as drizzle when calculating the shifts. It is also possible to provide Tweakshifts with an input reference catalog and request that all the images be registered to this catalog. Tweakshifts can also be asked to measure shifts for images that are already drizzled, which is often useful when comparing clean combined images of the same target obtained in different orbits or visits.
Since the task is currently available as a prototype, any feedback on its use would be welcomed, by sending email to help@stsci.edu. Future improvements will include the ability to directly modify the WCS of the input files (thereby eliminating the need for shiftfiles or ASN table modifications), as well as more generally robust ways to determine shifts.