The detector for DEIMOS is a mosaic of 8 CCDs, each with 2048x4096 imaging pixels (see drawing as PDF or PS or a subset in a web page). Its layout is extremely similar to that of the KPNO Mosaic detector which has been in use for several years.
There is a need to standardize the FITS keywords which are used for reporting the world coordinate systems (WCSs) of mosaic images. Without standard keywords different image display programs are unable to produce consistent views of the mosaic data.
Note that the KPNO mosaic data structures define a set of WCSs which relate FITS pixels to locations on the entire detector and on individual CCDs. These WCSs are used to display the KPNO mosaic data both in real-time during readout and subsequently during processing.
The WCS keywords used in the KPNO mosaic images make use of "image sections" to describe relevant subsets of pixels. Some image section keywords describe various subsets of pixels in the FITS image array. Other keywords describe subsets of pixels on the CCDs or subsets of pixels in the focal plane of the entire mosaic.
These image section keywords are evolved from prior usage at KPNO and within IRAF. They do not make use of the formalisms proposed in the FITS WCS draft papers by Greisen and Calabretta.
Early versions of the ds9 display program attempts to make use of the KPNO mosaic WCS keywords as defined by Frank Valdes. Unfortunately the definition of these keywords is slightly ambiguous. The result was that ds9 did not assemble a multi-HDU mosaic image in the same fashion as the IRAF tools. After much collaboration, and a tremendous amount of effort on the part of the its development team, ds9 now displays DEIMOS images in a sensible fashion.
A typical raw DEIMOS or KPNO mosaic image consists of about 140 Mbytes of data. Images of this size are too large for casual interchange and too large for some computers to display easily. Probably for this reason there has been relatively little interchange of mosaic data between tools from different sites. In an attempt to remedy this situation we present a multi-HDU FITS file containing a typical spectral image from DEIMOS. This file is 140 Mbytes big.
The meanings of the mosaic data structure keywords adopted for use in IMAGE extensions produced by mosaic built at UCO/Lick Observatory are explained in these XML files.
Those who are familiar will see that DEIMOS has followed the basic
structure of the NOAO images. The image from each amplifier is stored
as a separate FITS IMAGE extension. In the details of
the keywords, however, the differences become evident. DEIMOS has
omitted many of the NOAO mosaic keywords in favor of ones that conform
to the WCS standard.
We present three early FITS files produced by readouts of the new HIRES science grade mosaic on 2003-10-28 just after it was installed in the dewar.
We have a PNG file showing how the ds9 viewer displays a HIRES mosaic from such multi-HDU fits files. The IRAF mosaic image display should produce similar results. The images above differ in that they were taken with the X-ray calibration bar obscuring the central portion of each CCD.
The images demonstrate that the HIRES mosaic can be read out using either the three A amplifiers, or the three B amplifiers, or all six. Therefore the number and size of the FITS IMAGE extensions will vary. The FITS keywords supplied with each IMAGE extension unambiguously identify which FITS pixel came from which physical pixel through which amplifier. This PDF file contains the engineering diagram that gives the vocabulary for the names and coordinates.
As an example of this new capability we offer
The source data are from the 1-degree RAND/SIO global topography map (360x180 pixels). For completeness (and ease of viewing with old image displays) the mosaic image is also available split into single-HDU FITS files as would have been obtained from the ``B'' amplifiers 1, 3, 5, 7, 10, 12, 14, 16.
Note that I have included keywords for multiple WCS in the fashion described by Greisen and Calabretta. This should display correctly with the current version of ds9, but I have not checked recently.
For the sake of initial interoperability tests I have included several mosaic WCS keywords which are peculiar to the KPNO mosaic; namely these are DETSIZE and DETSEC. These are currently required for ds9 to interpret the file as a mosaic image. However I believe these two need not be in the final, standard set of FITS mosaic WCS keywords. (I had originally included CTYPE cards with names like 'xxxx-LIN' in the expectation that this is needed for Doug Mink's WCS libraries.)
The ds9 image display correctly interprets the NOAO-inspired DATASEC DETSEC, and DETSIZE keywords. It also makes use of the multiple different WCS that are described in these files.
The DETSIZE and DETSEC keywords are useful in the case where there are no transpositions or significant rotations involved in the layout of a CCD mosaic. They permit easy display using old software which is presuming that all pixels fall onto an integer grid of pixels. Without DETSIZE an image display cannot know the ultimate extents of the complete display until it has processed the DATASEC and WCS keywords from all of the IMAGE extensions in a multi-HDU mosaic FITS file. Nevertheless, I do not consider these reasons to be sufficient justification for the necessity of DETSIZE.
The NOAO image structure definitions from Frank Valdes contain ATM/ATV (and/or LTM/LTV or DTM/DTV) keywords along with the DETSEC keywords. These do provide the information necessary in the case where there are transpositions or rotations, but they do not provide any information which is not contained in the DATASEC and standard FITS WCS keywords. (None of this is a surprise because the NOAO definitions originated before the language for multiple WCSs in the current drafts.) The NOAO image structure definitions also contain hard-coded notions of CCD, amplifier, image, and detector coordinates. I think it preferable to use the standard keywords along with WCSNAME cards identify a particular WCS as 'CCD', 'amplifier', or 'detector' (WCSNAME is a feature added to the WCS drafts at my behest in anticipation of application to this situation).
In the general case this becomes a user-interface issue which will require significantly more research into the possibilities before we dare to standardize keywords. What kinds of keywords might be used to indicate these intentions to an image display application? Is it even appropriate to consider the standardization of keywords which are intended as verbs to be executed as opposed to the original FITS attribute/value pairs?
The issue of multi-HDU FITS files containing mosaics needs to be discussed by the entire FITS community. I hope this serves as fodder to get things started. Some consensus on keywords for the simpler cases is needed as soon as possible.
