Next: WCSTools: Image World Coordinate System Utilities
Previous: Practical Applications of a Relational Database of FITS Keywords
Up: FITS-Flexible Image Transport System
Table of Contents - Index - PS reprint - PDF reprint

Astronomical Data Analysis Software and Systems VI
ASP Conference Series, Vol. 125, 1997
Editors: Gareth Hunt and H. E. Payne

Multiple World Coordinate Systems for DEIMOS Mosaic Images

S. L. Allen, De Clarke
UCO/Lick Observatory



The Deep Extra-galactic Imaging Multi-Object Spectrograph (DEIMOS) under construction for Keck II will employ a detector comprised of a mosaic of eight CCDs. World coordinate system (WCS) information is needed for mapping between FITS pixels and many other systems. To permit an arbitrary number of WCS mappings, we extend the FITS metaphor by placing the WCS information in a FITS table. For the purposes of simulation and planning, the scheme can be generalized to accommodate mappings between non-FITS coordinates.


1. WCS Needs of the DEIMOS Instrument

DEIMOS will be installed on the Nasmyth platform of the Keck II telescope in 1998. The instrument will sample a 16×5arc-minute off-axis region of the telescope field for imaging and multi-slit spectroscopy. The slitmasks will be manufactured from flat metal sheets; these are curved cylindrically while in use to approximate the shape of the Nasmyth focal surface. The detector will be a mosaic of eight 2048×4096 pixel two-amplifier CCDs.

When examining data from the instrument, the observer will need a real-time conversion from FITS pixels to numerous other coordinate systems. Data reduction pipelines and archival data users will also need this WCS information. Coordinates of various CCD defects will be constant per amplifier and/or per chip. Vignetting effects will be constant in the overall dewar focal plane. Effects of the hexagonal Keck pupil depend on the telescope elevation and DEIMOS position angle. Identification of slitlets requires coordinates on the slitmask. Identification of objects requires coordinates on the sky. The guide camera FOV will sample subregions of the slitmask and CCD mosaic. Identification of spectral features requires calculation of dispersion. For the sake of simplicity, DEIMOS will use a single scheme for manipulating, transmitting, and archiving all of the WCS mappings.

2. Adaptation of Existing WCS Schemes

A single WCS mapping is easily documented using the formalisms of the original FITS paper (Wells et al. 1981), and these formalisms are widely recognized by FITS image viewers. The eight-character keyword name space of FITS headers limits the number of WCSs which can be stored within an image HDU. The conventions in the draft WCS proposal (Greisen & Calabretta 1996) permit up to nine different mappings from FITS pixels to sky, and they store the information in repeating groups of FITS indexed keywords. These draft conventions are not intended to provide the generality necessary for conversions from FITS pixel to instrumental coordinate systems, nor do they address the issues of conversion between coordinates where neither system is FITS pixels.

Some of the data products from the DEIMOS mosaic will need more than nine complete WCS mappings. Our initial attempts to describe these within the image HDU involved keywords with unilluminating names consisting largely of indexing digits. The keywords were also incapable of handling the amount of WCS data which could be generated by mosaics more complex than DEIMOS.

As an alternative, we store the bulk of the WCS information in a separate FITS table associated with the image HDUs. This is similar to the scheme used in the HST Data Archive of WF/PC images, but for DEIMOS we use standard FITS tables rather than adaptations of FITS random group parameters. We thus avoid the problem of consuming large amounts of the precious name space of indexed keywords in FITS headers.

The DEIMOS design includes a relational database (RDB) as an active component of its operation. The documents defining FITS tables (Harten et al. 1988; Cotton et al. 1995) permit a very close mapping between astronomical data sets and RDB tables. We treat the separate WCS FITS table as an instance of a RDB table. We treat the keywords in the image header as if they were fields from a single row of another RDB table (one example of such a table would be the header catalog of the NOAO Save the Bits archive project). We follow the principles of good RDB design (Date 1990) by avoiding the use of repeating groups of WCS information in the image HDU.

3. Operational Principles

Consider the simple case of operation with only a single FITS array. The principal WCS, typically the sky, is stored in the image header. The WCS table contains the same principal WCS as the fields of one row, plus other rows with mappings from FITS pixels to various instrumental systems. In addition to the fields which contain the WCS information there is another field, WCS_DEST, which serves as part of the primary key of the WCS table. Values for WCS_DEST can indicate a reference frame for the sky (e.g., FK5_2000) or for the instrument (e.g., SLITMASK). The user interface will permit selection of any desired WCS from a menu of available values of this key.

Actual DEIMOS FITS files will consist of numerous IMAGE and TABLE extensions. Each sub-raster readout region of each CCD will be stored with a unique value of the keyword SRRID. A single WCS table will contain mappings for all the IMAGE extensions; it will include the column SRRID to serve as another component of the primary key used to select the WCS coefficients.

The WCS table contains at least the following fields: SRRID, WCS_DEST (as composite primary key); CRPIX n, CRVAL n, CDELT n, CTYPE n, CUNIT n, CROTA n, CD i_j, CD iiijjj, PC iiijjj, RADECSYS, EQUINOX, and MJD-OBS (parameters for the WCS). Note that we can supply information as may be needed by both the traditional and draft WCS specifications. We can also include additional fields, e.g., a field which documents the provenance of the rest of the WCS information. Thus the WCS table scheme permits archival documentation of arbitrary numbers of WCS mappings for the FITS pixels of a given image.

4. Extension to Non-FITS Coordinates

The observation planning and simulation software for DEIMOS shares many WCS requirements with the archival FITS software. In particular, slitmask fabrication requires the mapping between CCDs, sky, and slitmask. Neither of the latter two of these systems is represented as FITS pixels. Because there are eight separate CCDs, it is impractical to implement the mappings from CCD to sky and CCD to slitmask as a two-step process. Instead, we intend to use the existing WCS formalisms to encode mappings such as the one between slitmask and sky.

The origin for these mappings is not an actual FITS image, and we must specify the information which permits proper selection and interpretation of the simulation WCS tables. The field WCS_ORIG is added as another component of the primary key. WCS_ORIG specifies the original reference frame whenever it differs from FITS pixels. We always place the sky on the WCS_DEST side of the mapping, and pixels on the WCS_ORIG side. Thus we preserve the general sense of FITS WCS mappings. In the simulation WCS tables we must also provide bounding information to serve the purpose filled by NAXIS n in actual images. And we include CCDLOC and AMPLOC to indicate individual elements of the CCD mosaic.

5. Discussion

Work for the DEIMOS project (Clarke & Allen 1997) has led us to explore various other possibilities of employing FITS files as portable instances of RDB tables. We require only a few restrictions on the structure of FITS tables and image headers, and the attributes of RDBs provide interesting possibilities for user interfaces. We find that this provides sufficient versatility to outweigh the drawbacks of separating WCS information from the image HDU, and these same tables continue to perform their traditional archival role. We are experimenting with a generic scheme for classifying FITS keywords and table columns as primary keys and foreign keys. We expect that further examination of the relationships between FITS tables and RDBs could lead to general formalisms for grouping FITS HDUs.


The construction of DEIMOS is supported by the National Science Foundation, the Center for Particle Astrophysics, and the California Association for Research in Astronomy.


Clarke, De, & Allen, S. L. 1997, this volume

Cotton, W. D., Tody, D. B., & Pence, W. D. 1995, A&AS, 113, 159

Date, C. J. 1990, An Introduction to Database Systems Vol. I (Reading, MA: Addison-Wesley)

Greisen, E. W. & Calabretta, M. 1996, Representations of celestial coordinates in FITS

Harten, R. H., Grosbøl, P., Greisen, E. W., & Wells, D. C. 1988, A&AS, 73, 365

Wells, D. C., Greisen, E. W., & Harten, R. H. 1981, A&AS, 44, 363

© Copyright 1997 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA

Next: WCSTools: Image World Coordinate System Utilities
Previous: Practical Applications of a Relational Database of FITS Keywords
Up: FITS-Flexible Image Transport System
Table of Contents - Index - PS reprint - PDF reprint