Software tools for ACS: Geometrical Issues and Overall Software Tool Development

Transcription

1 Software tools for ACS: Geometrical Issues and Overall Software Tool Development W.B. Sparks, R. Jedrzejewski, M. Clampin, R.C. Bohlin. June 8, 2000 ABSTRACT We describe the issues relating to internal geometrical distortions in the ACS. A software tool development route is outlined that will lead to provision of rectified ACS associations. We describe other software tool development activities, including pipeline enhancement to include postflash and ramp filter observation calibration, as well as stand-alone tools. I. Software Tools Overview Software tools are required in support of an HST instrument in order to (i) simulate observations with the instrument (ii) access, visualize and manipulate data arrays (iii) provide calibration reference files in support of the calibration pipeline for the instrument (iv) provide the calibration of the instrument, i.e. removal of the instrument specific signatures from the data, through the calibration pipeline itself and in stand-alone mode for more complex operations (v) provide analysis tools that enhance the scientific usefulness of the data and allow scientific measurements to be made. Here we outline the desired software development for ACS and discuss the issues relating to each item. The present ACS pipeline operations are described in ACS ISRs (Hack), (Mutchler et al) and (Hack). Copyright 1999 The Association of Universities for Research in Astronomy, Inc. All Rights Reserved.

2 II. The Geometric Issues ACS has severe distortions in mapping of positions in pixel coordinates to a rectified grid, of order 15% in terms of pixel area projected onto sky. WFC3 will have a similar level of distortion, which is much larger than for existing instruments. There are consequences for: pointing control astrometry photometry ACS images look distorted, Fig. 1. Much of the anticipated ACS science requires accurate shape and isophotal measurements that are much more straightforward on a rectified, well-sampled image, and obviously photometric fidelity is crucial. Hence, there is likely to be a demand for an image rectification stage. Since there are reflective elements only, we do not anticipate any color dependency for the case of direct imaging observations. Most obviously, correction of relative positions requires good knowledge of the internal distortions. Less obviously, photometry is affected as a consequence of pixel size changes (projected onto the sky) across the field of view. Point sources and extended sources, folded together with the flat-fielding strategy adopted, can lead to misleading results in these circumstances. Finally, measurement of the shape of a target depends on both the positional mapping from the detected frame to the sky frame and also on the pixel size variations, which influences apparent isophotal levels. An observed flat-field has more relative flux for bigger pixels, as does the sky, however a point source has the same amount of total flux irrespective of the pixel-area projected on the sky. Hence, flattening with an as-observed (e.g. sky flat) flat-field gives a flat sky but modifes star fluxes by the changed pixel area. Correction, in principle, can be made for the changed pixel area, to rectify the stellar fluxes, but then the sky has gradients imprinted that show the pixel area changes. We also anticipate that an ACS image sequence will frequently be dithered. That is, several images will be taken one after the other with the telescope pointing shifted by a small amount between images. This is done to help eliminate the effects of bad pixels and to obtain additional information on image structure in cases where the images are undersampled. If the maneuveurs are small (i) the telescope will remain on the same guide stars (ii) the data form an association in the archive. (Larger telescope moves are referred to as mosaics rather than dithers.) Combination of dithered (or mosaiced) data requires knowledge of the geometrical distortions and of the convention employed in flat-fielding the data. Current dithering software (algorithmically, at least) is well-capable of taking account of these effects correctly. Currently the ACS pipeline processing stops at the point where individual images have been flat-fielded, with up to three types of flat-field allowed (pixel-to-pixel, or P-flat, large scale or L-flat and delta flats to allow for time variability). Here we describe a path 2

3 towards attaining a goal of providing as the final ACS pipeline product a single rectified photometrically accurate image per input association. Stand-alone tool development that will lead to this single image is described, and also the tools needed to process non-associated (mosaiced) data. Recommendations and Implied Software Development: Geometry. Storing the information Geometric distortions are conceptually and physically completely different from sensitivity variations due to different pixel-to-pixel response. They interact with an observation in different ways. They can both be calibrated independently. Our first recommendation is that the geometric calibration be kept in a single place, utilizing the placeholder IDC file (Image Distortion Correction, or GEOFILE in ISR 99-08). Priority 1. Additionally, a metric equivalent tool to provide RA/Dec from image x,y coordinates and vice versa, should be developed to connect the World coordinate system of the image headers to the known internal distortions (the IDC file). Priority 2. There are potentially several conventions available. In particular the SIAF and drizzle software use similar but not identical conventions. A utility to move between conventions and to provide inverse transformations is needed. Priority 1. Flat field strategies There are basically two options (for straightforward imaging data): (i) divide data by an as observed flat-field without any allowance for pixel size changes, such as a sky-flat, or (ii) correct only for detector sensitivity variations so that the same number of total counts represents the same flux everywhere. A single pixel in the raw flat changes in area on the sky by about +/-10% (19% peak to peak; pixel sizes differ from 0.90 to 1.07 times the central in WFC). If you flatten an image with such a flat, the same star will, roughly, have an apparent brightness change equivalent to the changing pixel size. An image flat-fielded in this way is essentially a surface brightness image, which has pitfalls in a complex partially undersampled field. This is method (i), the surface brightness method of flat-fielding, or LPG in the notation of Bohlin et al ACS/ISR To convert to a flux per pixel image, method (ii), which is necessary if photometric measurements are to be made on stars in the field, it is necessary to multiply the surface brightness image by the relative pixel size, G. In principle, the flat-field reference file itself could be manipulated according to the relative pixel size, however that introduces an undesirable dependency of one calibration file on another (the G-flat on the IDC file). 3

4 Rather than correct for the pixel size immediately after flat-fielding, and thereby imprinting an apparent surface brightness gradient on all ACS images, and since the subsequent software tools are set up to deal with surface-brightness data, we recommend that the data be corrected only with an as-observed flat-field, such as a sky-flat. We urge that warnings be provided about the dangers of using such data scientifically (astrometry, photometry). It is for quick-look purposes only. Given the need for photometric testing and testing of the accuracy of geometric correction, our second specific software tool request is for a tool to provide the pixel area correction to flat-fielded data. Priority 1. The pixel area is given by the determinant of the Jacobian of the transformation between coordinate systems; see Appendix. Correcting for Distortion and Combining Images Much basic astronomy including measurement of anything relating to isophotal parameters, size, shape, quantitative morphology (e.g. a surface brightness profile), comparative morphology (e.g. overlaying optical and radio data) and position needs to be carried out on an image which has been corrected for the geometrical distortions that the camera introduced. If the rectification scheme allows correctly for the modulated pixel size, then it is straightforward to ensure the photometric fidelity of the final product. A final image which is photometrically uniform in its response and geometrically rectified is the obvious scientifically useful data product which we should aim to provide. Also, a large fraction of ACS observations are likely to be dithered or mosaiced. There already exist software techniques to combine such data, the dither package of stsdas, and in particular drizzle. This code of necessity and from the outset is well-capable of dealing with internal geometrical distortions. It may be used simply to geometrically rectify a single image with the appropriate parameter set (pixfrac=1), or else it may be used to geometrically rectify multiple images, resampling onto a finer grid, and combine those multiple images into a single rectified, photometrically useful image. (An iterative stage is usually needed to identify and eliminate cosmic rays.) Since the HST observing strategy at Phase 2 is also designed to accomodate this mode of operation straightforwardly using the DITHER patterns for small offsets, we wish to move towards a pipeline implementation of this image combination option. It is also possible to MOSAIC images to cover a larger field of view, but such mosaics will typically not use the same guide stars and will not be associated in the pipeline or archive. Hence our route towards final implementation is as follows: It is essential that by launch we have the stand-alone tools needed to combine a set of ACS images that are shifted in pointing position from one another. The primary combination tool will be drizzle, or an upgraded version based on that task, which will also be used for single image geometric and photometric rectification. The task should be able to operate from both a user supplied table of relative offsets, and from the HST pointing information. Priority 1. 4

5 Other appropriate utilities in the dither package, such as blot to simulate raw data, should be checked for consistency with ACS data and fully functional in stand-alone mode by launch. Priority 2. In the case of single images, or CR-SPLIT images at a single pointing, provide as a pipeline product a geometrically rectified, photometrically uniform image. For consistency with the next bullet, there is good reason to use drizzle, or its equivalent, to perform this operation. This may be implemented once confidence is gained in the robustness of the task and ahead of the use of drizzle with multiple images since parameter selection is less critical. Priority 1. For multiple images, a stand-alone software tool to determine the relative offsets will be required. The cross-correlation strategy, e.g. as employed by calnicb, should serve as a model for this task. (Cross-correlation tools are also to be found in dither and fourier.) Priority 1.5. Given the stand-alone combination tool (drizzle, first bullet), and given the confidence developed through testing and experience, we urge that in the case of associated data only, i.e. DITHER data, the image combination be implemented in the ACS pipeline. HST pointing information only should be used to estimate the relative offsets in an initial implementation. Priority 1. Any image rectification strategy must ensure correct treatement of the photometry such that in the final data product, a star of given flux will have the same apparent brightness anywhere in the field. The final geometrically corrected product will appear as a single image rather than multiple imsets, or FITS extensions. In the case of single pointing, the sampling will be essentially the same as the detector. For DITHER data we expect to output a more finely sampled image (exact value to be determined from simulation and experience, but probably in the range 1.5 to 2). In order to combine any sequence of images, it is necessary to normalize by the exposure times of the individual input images. The concept of a single exposure time is no longer valid and an exposure time image should be generated. By default, we assume that the output product will have units of count rate following calnicb and current drizzle implementation options. The usual flux calibration header keywords (already present) will allow straightforward absolute calibration of the count-rate data. An interesting alternative may be to take the next step and instead of count-rate, provide a flux calibrated image. Micro-Jansky would be an appropriate unit for typical ACS observations; V=28 is 0.02 microjy for reference. Error analysis for dithered data The variance images of dithered data become more complex, as spatially dependent smoothing has been applied to the data, familiar to FOC observers as the thumbprint noise pattern. Hence, while variances can easily be calculated, adjacent pixels are no longer independent and covariances exist. The issue is whether this is a concern, or is the 5

6 variance information sufficient? Do we need to incorporate a description of the dependencies between pixels? This can lead to a preference for working in the unrectified domain as the error statistics are more tractable. We propose that as a default path, we perform a straightforward variance calculation and provide the usual error, or uncertainty, image without provision for the covariance or pixel-to-pixel dependence of errors. III. Software tools in Other Areas Postflash correction (pipeline) Concerns about the degradation of charge transfer efficiency (CTE) have resulted in a hardware modification to ACS which is the inclusion of a postflash capability. It will be necessary to subtract off the pedestal of post-illumination in the pipeline. The postflash illumination pattern will be strongly non-uniform, hence it is highly desirable that good S/ N reference files be available to support this capability. Priority 2. Ramp filter flat-field tools Calibration of ramp filter data is not trivial. Conceptually, the process may be envisaged as a two-stage one in which firstly, the data are flat-fielded in such a way as to enable continuum subtraction to be carried out, and secondly, the resulting monochromatic data are flux-calibrated to correct for the changing transmission, or sensitivity, around the field of view, knowing (or assuming) the wavelength of the monochromatic data. These tools have not been implemented for WFPC2, however there the ramp filter field of view is so small that an essentially point-source approach is tractable. ACS ramp filter observations cover out to about 70 arcsec, by contrast, and hence tools to correct and manipulate the full area of an ACS ramp filter observation are required for the data analysis stage. Ramp filter flat-fielding Ramp filter flat-fielding requires a tool to interpolate a flat-field from a data cube of monochromatic (or at least flats of known central wavelength) full-field flats at selected wavlengths. The flat-field strategy is discussed Bohlin et al ACS ISR The filter position, determined by the wavelength specified by the observer, gives a mapping for a specific image between position in the field and wavelength. The flat-field data cube allows that information to be used to make an interpolated flat-field value at each pixel. This is the appropriate flat field for a continuum source, presumed to have no strong features across the ramp bandpass and is appropriate for a proper continuum subtraction. Note that a delta flat may be needed if high frequency spatial structure is present on the flat field due to dust on the filter. Such features would appear in different places depending on the filter rotation. Development of this tool should initially be a stand-alone version. It should be tested with ground-based calibration data prior to implementation in the pipeline. The data cube may 6

7 be either (i) a dedicated monochromatic data cube or (ii) the suite of flat-fields delivered as reference files, with a look-up-table giving the suitable entries and their wavelengths. The goals should be to implement this in the pipeline. Priority 2. Flux calibration of ramp filter data An extended monochromatic source image is the expected result of a typical ramp filter observation following continuum subtraction. Continuum subtraction can be a rather specialized operation, so we do not envisage including it in the pipeline. Hence, we cannot include the subsequent step of flux calibration in the pipeline over an extended area. We do expect to provide flux calibration keywords that will be valid for the specified wavelength of hte observation, A stand-alone utility interfacing with the synphot library of transmission curves will in addition enable an areal flux calibration to be carried out. If the source is monochromatic and well centered in the ramp filter (spectrally) at the center of the aperture, then as one moves away from the aperture center, the response curve of the ramp shifts in such a way that the source wavelength is no longer central. Eventually, the ramp filter response moves far enough that the source is completely out of the bandpass. Any given ramp filter position may be thought of as providing a unique throughput curve at each location in the image. Hence, knowing the wavelength of the source, it is straightforward to flux calibrate using standard synphot tools. However, since this needs to be done at every pixel, it requires a software tool to (i) at each position x,y generate the throughput curve given the ramp filter position (ii) use the throughput curve to determine the absolute sensitivity at the source (or externally specified) wavelength (iii) hence provide a flux calibrated image by utilizing the absolute sensitivity at each x,y position. Optional output images would include a central wavelength map and a sensitivity map, and an optional input wavelength-image instead of a single wavelength would be a useful enhancement. An interim utility will be to provide information on the region within which the throughput of the ramp is within, say, plus or minus 1%, 2% etc. of the central value. By default, one would assume the input wavelength specified in the observation. This may be overridden if the observer knows more about the wavelength of the source, or if multiple wavelengths are present, or if the wavelength distribution is known. Priority 3. FPR and Cosmic Ray analysis tools for CTE. The observed CTE degradation of WFPC2 and STIS together with the large format of the ACS CCDs has given rise to great concern over the rate of CTE decline in ACS, particularly the WFC. Hence, CTE monitoring will form an important part of the ACS calibration plan. Analysis tools to facilitiate that monitoring will be helpful once the program is under way. There are currently two options: (i) Mike Jones has designed an engineering program first pixel response test to estimate CTE (ii) Also, Riess WFPC2 ISR describes a technique to measure CTE from cosmic rays in dark frames. 7

8 The ACS group will utilise these techniques to monitor CTE and, if possible, automate the measurement process given experience with on-orbit data. Such a process may become straightforward with an application tool. Priority 3.5. Polarization analysis tool ACS has a high quality, robust imaging polarimetry capability that should lend itself well to relatively automatic data processing, unlike previous instruments such as WFPC2 or NICMOS where the polarization analysis is complex. Although a number of private software packages are available, there is as yet still no iraf or stsdas standard suite of imaging polarization analysis software. The instruments with such a capability are ACS, NICMOS, WFPC2 and the FOC, hence although the polarization community of observers is quite small, there is signficant across-instrument relevance and interst in a general package. The techniques are known and documented in Sparks and Axon (1999) PASP, 111, Provision of a general polarization analysis tool is entirely feasible. Priority 3. Tools for coronagraphic analysis ACS has a powerful coronagraphic capability that will allow faint source to be seen very close to bright stars and quasars. In order to process data of this form, we will require techniques to determine azimuthal profiles using a variety of methods (mean, median, mode for example), plus construction of model profiles utilising the azimuthal averaging information. Priority 3. Contingency time Contingency time must be allowed for, since with a new instrument, it is almost always the case that unforeseen developments lead to new, unanticipated requirements in the area of software support. Hands-on experience with real data could change priorities and introduce new needs, potentially at short notice and potentially as a matter of urgency. IV. Tools which are close to completion and non-ssg tools ACS quick display tools A utility to examine the multiple imsets of an ACS image, and to provide a quick-look correction for the geometric distortion on display, optionally. This task has been completed and is in test. Quick-look products Design carried out by Suchkov ACS ISR 99-10; coding close to completion; in testing. 8

9 ACS ETC Complete basic functionality of ACS ETC (Bohlin/Shaw/Boffi efforts ongoing) PSF modelling Primarily oversight of the Tiny Tim implementation for ACS; Krist. Extracted spectra for grisms ST-ECF have agreed to collaborate on development of grism spectra analysis tools, and to assume formal responsibility for support of the software they provide. 9

10 Summary * "Launch" below implies fully developed and tested in advance of actual launch in order that use may be made of the software from the outset of the science mission. Item Timescale Priority Pipeline? Establish/deliver IDC file May 00 1 yes metric : convert x,y to RA,Dec 2 no drizzle coefficients from IDC 1 yes make pixel area map from IDC May/June 00 1 no stand-alone drizzle functionality - HST pointing information - user-supplied tables of pointing data Launch 1 no (check functionality of dither package) 2 no measure image shifts (cross-correlation) Launch 1.5 no provide rectification for single pointing in pipeline 1 yes image combination of dithers (HST pointing info) 1 yes postflash subtraction 2 yes Ramp filter flat-field interpolation 2 yes Ramp filter flux calibration 3 no Cosmic ray tools 3.5 Polarization analysis tool 3 Coronagraphic analysis tool 3 Contingency time ACS quick display 1 in testing Quick-look PDF products 1 in testing ACS ETC 1 Bohlin/Shaw/ Boffi PSF modelling 1 Krist Extracted spectra for grisms 1 STECF 10

11 APPENDIX: Pixel Area Correction If x = f x (x, y), y = f y (x, y) defines two functions that map coordinate frame (x, y) into coordinate frame (x, y ), then if a pixel (assumed small) has area A in (x, y) at (x, y), it will have area in (x, y ) at (x, y ). Or, f x f A A y f y f x = x y x y = A J A = A J If (x, y) is the observed frame, and (x,y ) is the rectified frame, then in the rectified frame, all pixels have the same area A = 1. Hence, at (x, y), the area of the pixel A(x, y) is A = 1 J and the functions f x and f y are the forward transformations from observed to rectified planes. That is, a unit sized pixel in the output image has area A in the input image, in units of the input pixel size, and so the actual area of the input pixel A in units of the output pixel size is A =1/A = J In the polynomial SIAF formalism we adopt initially, the partial derivatives may be calculated analytically. 11

12 Figure 1. Image taken with HRC plus coronagraphic optics, showing on the left the raw, geometrically distorted image and on the right for comparison, the image rectified with an initial set of distortion coefficients. Note that the coronagraphic holes appear much more circular in the corrected image. 12