3.11: WCS issues and FITS keywords

World Coordinate Systems (WCS) are the means by which pixel coordinates in the image are related to physical coordinates. Documents including the current draft of the proposal for representation of celestial coordinates in FITS are available as URL=http://fits.cv.nrao.edu/documents/wcs/wcs.html.

The DEIMOS specifications for user interaction with the images require that the images be produced with WCS information. WCS mechanisms built into the FITS headers of the DEIMOS give tangible benefits. When viewing a DEIMOS image frame they will permit quick look viewers to provide an instantaneous readout of the celestial coordinates of objects as the mouse tracks across the screen. When viewing a DEIMOS spectroscopy frame the WCS issues are more complex and would be most easily solved by looking at the table of slitlets in the mask. Either of these cases requires knowledge of the relative orientation of the detectors in the mosaic and of the distortions in the DEIMOS camera.

The draft describes 25 different WCS projections of the celestial sphere onto pixel coordinates. The authors also provide code libraries in both Fortran and C which perform the calculations. Unfortunately for DEIMOS none of the projections is able to handle an optical system with non-coaxial distortions. The given WCS projections should be able to map globally to about 10 pixels, or one arcsec. This is quite adequate for tracking the mouse over an image. More precise formulations will be required for the purposes of precision astrometry and slitmask design.

3.11.1: Enumeration of the coordinate systems

The sky as measured via classical astrometric techniques is the most definitive coordinate system. Mappings must be available from all other DEIMOS coordinate systems to the sky and vice versa. In the following list the coordinate systems are divided into two categories: ideal systems (which serve a conceptual purpose but are not used in practice), and operational systems (for which implementations will be required).

3.11.1.1: The Sky (Operational)

Coordinates of objects on the sky are determined by classical astrometric techniques. For minimal light loss the relative positions of objects must be known to about 0.1 arcsec or better. When designing slitmasks from objects in different catalogs the user will have to ensure that there are no systematic differences larger than this limit.

The responsibility for accuracy of input coordinates ultimately lies with the observer. Still, DEIMOS software should ensure that its handling of celestial coordinates is good enough not to be the cause of suboptimal slit positioning. The portions of DEIMOS which handle celestial coordinates (most notably the slitmask design) should make use of all astrometric terms which are relevant for extra-solar objects. (A description of the catalog tables is in section 7.5.3.4) If the astronomer cannot supply all astrometric quantities then the program should give a warning and supply reasonable defaults.

3.11.1.2: The Keck II axis (Operational)

DEIMOS provides no direct method for viewing the axis of the Keck II field of view. This will require that the pointing of the Keck II be determined by independent means when the WCS transformations from sky to components of DEIMOS are created.

3.11.1.3: The Nasmyth Focal Surface (Ideal)

The Nasmyth focal ``plane'' of the Keck II telescope is a spherical surface with radius of curvature = 83.6 inches. Under most observing circumstances the telescope optics may be presumed to be axisymmetric. Thus the mapping from sky to Nasmyth focal plane requires consideration of purely radial terms.

In the DEIMOS design there is no object located on the Nasmyth Focal surface. There is no direct need to know the mapping between it and the sky. Conceptually, however, this mapping will be important for the design of the slitmasks.

3.11.1.4: The Slitmasks (Operational)

The slitmasks are designed to be cylindrical surfaces which are not located on the Keck II axis. These cylinders very nearly match the local shape of the spherical Nasmyth focal plane. The slitmasks will be manufactured from flat sheets which are later curved over cylindrical frames.

In practice it is likely that the tension on the slitmasks may globally deform them into a more nearly conical shape. In this case the mapping from the spherical Nasmyth Focal Surface to the Slitmask might resemble Lambertian projections common in cartography. The tension on the slitmasks will also tend to produce local deformations in regions between the support ribs.

For the purposes of slitmask manufacture the mapping from celestial coordinates to mask coordinates must be known to an accuracy of better than 0.1 arcsecond over the entire slitmask. The slitmask database should store the positions of the slitlets in mask coordinates, not in celestial coordinates. The CNC mill which produces the slitlets will require their coordinates to be specified in a Cartesian coordinate system aligned with the mask.

For the purpose of quick look reductions the mapping from CCD coordinates to slitmask coordinates will be required.

3.11.1.5: The DEIMOS Camera Focal Surface (Ideal)

The focal plane of the DEIMOS camera is a nearly flat surface. In imaging mode the Nasmyth focal plane is mapped onto the camera focal plane. The DEIMOS camera can be presumed to be axisymmetric, but it views the Nasmyth focal plane off-axis. The pointing of the camera can be modified along two axes by the flexure compensation system.

There are radial distortions inherent in both the Keck II field of view and the DEIMOS camera field of view. The coordinate system in the camera focal surface is the product of these two non-coaxial distortions.

Because there is no precision imaging device which spans the entire surface there is no direct need to know the properties of the mapping between sky and camera focal plane. It will be conceptually useful for the CCD WCS and for slitmask design.

3.11.1.6: The DEIMOS CCDs (Operational)

The DEIMOS detector consists of 8 CCDs. Ideally these detectors will be coplanar with the DEIMOS camera focal plane. Each of the CCDs in the DEIMOS detector has a nearly-Cartesian coordinate system which is best described by the FITS draft WCS conventions. Because of slight rotations and alignment variations of the CCDs in the mosaic it will be necessary to have a separate WCS for each CCD. A scheme for documenting the layout of a mosaicked image is given in the section on FITS Keywords for DEIMOS Mosaics.

For the purposes of quick look interaction with direct images the mapping between each CCD and the sky must be known. The same WCS mapping also serves archival purposes.

For the purposes of quick look interaction with spectral images the mapping between each CCD and the slitmask must be known. The coordinate on the slitmask will then be used to determine the sky position and/or observatory wavelength of any pixel.

3.11.1.7: The DEIMOS Guide Camera (Operational)

DEIMOS will have a guide camera which provides a real-time view of the sky. The mechanical design of this camera is not yet available, but it is expected to watch the difference in position between objects and some flexure-immune fiducial marks. The guide camera image should be accompanied by WCS information. The information necessary for this WCS will be created as a part of the autoguider software; it need merely be made available and cast into FITS WCS form.

If the guide camera is used in a slit-viewing mode its field of view will overlap the slitmask. If the guide camera is used in a direct mode its field of view will be disjoint from the slitmask. A WCS for each scenario should be available prior to the observation at the time of slitmask design. The slitmask design program should use these draw a cartoon of the guider FOV within or next to the slitmask. This will assist the slitmask designer in choosing a field center and position angle that admit suitable guide stars.

3.11.2: Determination of the necessary mappings

The WCS conventions provide for a linear mapping between pixel coordinates and any other system. Four of the eight CCDs in each detector are used for imaging purposes. For those 4 CCDs the following schemes can be used to determine the WCS transformations.

3.11.2.1: Mappings between CCDs and the sky

Empirical determinations of the mappings between each CCD and the sky can be made after first light by traditional astrometric means. This will require several fields full of targets with precisely known locations. Ideally these fields should provide several dozen known objects well-distributed upon each of the 4 imaging CCDs. The same field should be viewed at different position angles and hour angles in order to characterize any WCS changes caused by flexure.

It remains to be determined which of the WCS coordinate conventions will most nearly describe the DEIMOS focal plane. It may be necessary to define an extension to the FITS WCS mechanisms to handle the distortions to the desired accuracy. The predicted distortions of Keck II and DEIMOS camera should be analyzed in advance of first light.

3.11.2.2: Mapping between Keck II axis (DCS) and DEIMOS CCD images

DEIMOS provides no on-axis imaging capability, yet the Keck II DCS must point the telescope to align the objects with their slitlets. DCS will also have to manage offset guiding and position angle tracking. This will require astrometric knowledge of the difference between the Keck II axis and the slitmask frames. It will be necessary to measure the distance between the slitmask (and guider) FOV and the Keck II axis, and to understand whether or not it can change with time.

If possible this mapping should be determined simultaneously with the CCD WCS mentioned just above. If the tertiary can be switched rapidly to feed DEIMOS alternately with an imaging device at the other Nasmyth or at the bent Cassegrain focus then the coordinate offset between the DCS and the DEIMOS CCD images should be measurable via classical astrometry. Alternatively it may be possible to place a small camera in the Keck II focal plane between the two slitmasks.

3.11.2.3: Mappings between the CCDs and the slitmask

Empirical determinations of the mappings between each CCD and the slitmask can be made before first light by imaging of a special slitmask. This slitmask will have a pattern of small circular holes which uniformly covers each CCD. Twenty-five holes on each CCD (five rows of five columns) will be more than adequate for determination of the coordinate transformations. The [x,y] positions of these holes must be known precisely in the coordinate frame of the slitmask cutter. Traditional astrometric methods can be used on the images of these artificial stars to determine the coordinate transformations. This slitmask has already been designed and is called the ``Gridhole Mask''. DEIMOS should provide a fully-automated procedure which can determine the WCS parameters from a Gridhole Mask exposure. This transformation should be determined using a variety of different filters.

The WCS for spectrally dispersed images will require another mask (not yet designed) which can be called the ``Gridslit Mask''. This mask should consist of a large number of slitlets which fill the width of the spatial direction of the mask. The slitlets should be offset in the dispersion direction of slitmask such that they sample most of the height of the mask. DEIMOS should provide a fully-automated procedure which can determine the slitlet transformations from a Gridslit Mask exposure. These transformations should be determined using various gratings at various angles.

In addition to the holes for metrology, both of these slitmasks should have small but unique patterns which fall onto each of the CCDs. These unique patterns are helpful for verifying that the readout orientation of each CCD has been correctly determined. These holes might be in the form of words or asymmetric letters of the alphabet.

The illumination of the slitmask in the laboratory may not match the illumination through the Keck II pupil. Furthermore, the Keck II pupil rotates w.r.t. the slitmask. For these reasons the slitmask WCS transformations should be verified after first light.

3.11.2.4: Determination of WCS for the other four CCDs

Because the mirror has a fixed angle which is intended to illuminate only 4 of the 8 CCDs with imaging data, the above procedures cannot provide mappings for the other 4 CCDs. In normal operation data from these non-imaging CCDs will only be obtained when a grating is in place. Such data will be spectrally dispersed along columns of the CCDs.

The mappings along the purely spatial dimension (rows of the CCDs) can be determined from such a calibration spectrum. The mappings along the direction of spectral dispersion are more complex; they involve both spatial and spectral information. As of the time of this PDR we do not have a WCS for describing spectral data. Its complexity will be sufficient that we expect to store it as a FITS table rather than as FITS keywords.

3.11.2.5: Mapping between sky and slitmask

In order to manufacture the slitmasks the mapping between sky coordinates and slitmask coordinates must be known. The above WCS transformations (Sky<->CCD and Mask<->CCD) for imaging could be combined to determine the necessary mapping. However, this presumes that they will be done to astrometric accuracy and that all the nonlinearities will be considered. For normal quick-look operation these other two mappings need not be known to the accuracy required for the Sky<->Mask mapping. Note that there are 4 separate mappings implied by the two-stage process above, one for each CCD.

At the time of observation the mapping between sky and slitmask may be better known than it was at the time of mask design and manufacture. The database should keep a record of the transformation in each case, and WCS information from both should be written into the FITS tables that accompany each CCD image. At the time of observation (or later) it should be possible for the user to see coordinates based on either the design-time or observation-time WCS.

3.11.2.6: Mapping between Guide Camera and anything else

This mapping is best accomplished by using celestial coordinates as an intermediate step. The mappings between celestial coordinates and CCD or slitmask coordinates have already been described.

3.11.3: Mapping from pixel coordinates to sky coordinates

The following is a list of keywords which should (and in one case should not) be included in multi-amplifier DEIMOS FITS images.

3.11.3.1: Keywords derived from DCS

The Keck DCS allows the coordinates of the telescope axis to be specified in several different reference frames. It may be desirable that the WCS embedded into the FITS image header use a reference frame other than that currently in use by DCS. DEIMOS is an off axis instrument and the position indicated by DCS will never appear within an image frame. This distinction between coordinates of the telescope axis and DEIMOS field of view is made in accord with the OGIP recommendations. See the FITS keyword data dictionary for precise definitions of these.

3.11.3.2: WCS Keywords applying to all CCDs

The following keywords apply to all sections of a mosaicked image stored within a single FITS image. See the FITS keyword data dictionary for precise definitions of these.

3.11.3.3: WCS Keywords applying to individual CCDs

These keywords permit the quick look display to map pixel coordinates back to sky coordinates.
SKmPC11
As PC001001 but for detector m coordinates only
SKmPC12
As PC001002 but for detector m coordinates only
SKmPC21
As PC002001 but for detector m coordinates only
SKmPC22
As PC002002 but for detector m coordinates only
SmRPIXn
As CRPIXn in the WCS draft standard. Reference pixel for detector m along FITS array axis n. Pixels are numbered starting with [1,1] and the center of that pixel is its reference point. This will be the pixel location on each CCD whose position on the sky has been measured directly or estimated from a best fit. For best results this will often be a pixel near the center of each CCD. Note that the historical use of CRPIXn at Lick Observatory is inconsistent with the WCS draft standard.
SmDELTn
As CDELTn in the WCS draft standard. Spacing between pixels of detector m along Sky axis n. See the details of the WCS draft which point out that the CDELT1 direction need not correspond with the NAXIS1 direction because of the PCmmmnnn matrix. This might be relevant in the case of pinwheeled arrays of CCD detectors. Note that the historical use of CDELTn at Lick Observatory is inconsistent with the WCS draft standard.
SmRVALn
As CRVALn in the WCS draft standard. The coordinate value on sky axis n which corresponds to the location of the pixel location given by SmRPIXn.
SmUNITn
As CUNITn in the WCS draft standard. Positions should be measured in degrees on the sky.
SmTYPEn
As CTYPEn in the WCS draft standard. See discussion below.
PROJPi
If needed (see CTYPEn discussion below), as in the WCS draft standard. The content of the SmTYPEn keywords will begin with either 'RA--' or 'DEC-' as the first 4 characters. The choice of whether SmTYPE1 or SmTYPE2 begins with 'RA--' is forced by the Position Angle of DEIMOS on the sky (SkyPA). The decision is represented by the following pseudocode:
if (abs(tan(SkyPA)) < 1) {
	# slitlets are more nearly N-S
	SmTYPE1 = 'DEC-....'
	SmTYPE2 = 'RA--....'
} else {
	# slitlets are more nearly E-W
	SmTYPE1 = 'RA--....'
	SmTYPE2 = 'DEC-....'
}

The content of the last 4 characters of the SmTYPEn keywords will be determined by the WCS projection. DEIMOS presents a challenge not considered by the various coordinate systems discussed in the WCS draft standard. The draft standard considers only those projections likely to be produced by coaxial optical systems. DEIMOS images will be the result of a camera looking off-axis of the Keck II telescope. Both the telescope/collimator and the camera will have nonlinear terms in their radial coordinate.

The decision of which projection to use requires information about the relative amounts of distortion caused by the telescope/collimator and the camera. If the distortion of one is much greater than the other then one of the zenithal projections from the WCS draft should suffice. However, initial predictions of the two distortions show them to have approximately the same magnitude. This problem requires further study.

Software which uses the image section information to split a multi-amplifier FITS image into single-amplifier image should rewrite the FITS cards. In each of the resulting m images the SKmPCij keywords should be rewritten as PCiiijjj keywords, and the SmXXXXn keywords should be rewritten as CXXXXn keywords.

3.11.4: Mapping from pixel coordinates to slitmask coordinates

The following keywords should be included in DEIMOS FITS images.
MAmPC11
As PC001001 but for detector m coordinates only. This value should be very nearly +/- 1.
MAmPC12
As PC001002 but for detector m coordinates only. This value should be very nearly 0.
MAmPC21
As PC002001 but for detector m coordinates only. This value should be very nearly 0.
MAmPC22
As PC002002 but for detector m coordinates only This value should be very nearly +/- 1.
MmRPIXn
As CRPIXn in the WCS draft standard. Reference pixel for detector m along FITS array axis n. Pixels are numbered starting with [1,1] and the center of that pixel is its reference point. This will be the pixel location on each CCD whose position on the slitmask has been measured directly or estimated from a best fit. For best results this will often be a pixel near the center of each CCD.
MmDELTn
As CDELTn in the WCS draft standard. Spacing between pixels of detector m along slitmask axis n. See the details of the WCS draft which point out that the CDELT1 direction need not correspond with the NAXIS1 direction because of the PCmmmnnn matrix. This might be relevant in the case of pinwheeled arrays of CCD detectors but is not for DEIMOS.
MmRVALn
As CRVALn in the WCS draft standard. The coordinate value on slitmask axis n which corresponds to the location of the pixel location given by MmRPIXn.
MmTYPEn
Should read 'X coordinate of slitmask'
or 'Y coordinate of slitmask'
MmUNITn
As CUNITn in the WCS draft standard. Positions should be measured in meters, 'm'.
During inspection of a FITS image the results of these coordinate transformations should be displayed as a cursor moves over the image. The resulting coordinates on the slitmask would be compared with the FITS table containing the manufactured locations of each slit. The image display tool should thus be able to tell which object the cursor was indicating.

3.11.5: A coordinate system for the focal plane

For the purposes of instrument simulation and observation planning we define a coordinate system in the focal plane of the detector mosaic. This is not directly useful for scientific purposes.

Each detector can be presumed to consist of a rectangular array of rectangular pixels. On each detector one of the imaging pixels at a corner nearest to a readout amplifier should be denoted as the origin pixel [1,1]. Moving away from the origin along the serial shift direction is the positive X axis of the detector. Moving away from the origin along the parallel shift direction is the positive Y axis of the detector.

DEIMOS will descramble image sections from all 8 detectors to store the image as a single FITS image. The plan for the DEIMOS array is such that the parallel shift and serial shift directions of all detectors are aligned. This makes it possible to specify that the coordinate system of the dewar focal plane be closely aligned with the coordinate system for detector number 1.

Even with the best efforts of dewar assembly crews the individual detectors will not be exactly aligned. Also, a FITS image which is constructed from many separate detectors will have discontinuities where the prescan and overscan pixels are stored. Each detector thus needs its own WCS. A small adaptation of the FITS WCS proposal can be used to specify the location of each detector in the focal plane. This scheme is more general than is required by DEIMOS, and can handle detectors with arbitrary rotations.

The following keywords are not intended for use in DEIMOS FITS images. They are intended for the purposes of simulation and observation planning software.

DFmPC11
As PC001001 but for detector m focal plane coordinates only
DFmPC12
As PC001002 but for detector m focal plane coordinates only
DFmPC21
As PC002001 but for detector m focal plane coordinates only
DFmPC22
As PC002002 but for detector m focal plane coordinates only
DFmPC13 (etc.)
As PC001003 but for detector m focal plane coordinates only
This would not typically be needed; however, in the case where the detectors might deviate appreciably from the focal surface this third dimension could be documented thus.
DmRPIXn
As CRPIXn in the WCS draft standard. Reference pixel for detector m along FITS array axis n. Pixels are numbered starting with [1,1] and the center of that pixel is its reference point. This will be the pixel location on each CCD whose position in the focal plane has been measured directly or estimated from a best fit. For best results this will often be a pixel near the center of each CCD. Note that the historical use of CRPIXn at Lick Observatory is inconsistent with the WCS draft standard.
DmDELTn
As CDELTn in the WCS draft standard. Spacing between pixels of detector m along Focal Plane axis n. See the details of the WCS draft which point out that the CDELT1 direction need not correspond with the NAXIS1 direction because of the PCmmmnnn matrix. This might be relevant in the case of pinwheeled arrays of CCD detectors. Note that the historical use of CDELTn at Lick Observatory is inconsistent with the WCS draft standard.
DmRVALn
As CRVALn in the WCS draft standard. The coordinate value along Focal Plane axis n which corresponds to the location of the pixel location given by DmRPIXn.
DmTYPEn
As CTYPEn. It is not clear that the value of this can really be useful to any automated program. Possible values of the string could be 'Focal Plane Coordinate n of detector m' or, because this is a simple scenario, 'Focal Plane X Coordinate of detector m'
DmUNITn
As CUNITn in the WCS draft standard. Positions in the focal plane should be measured in meters, so these cards should always have the value 'm'.

Steve Allen <sla@ucolick.org>
$Date: 1996/03/20 03:47:49 $