THE ING NEWSLETTER No. 3, September 2000
    GENERAL
    		 SCIENCE
    TELESCOPES AND INSTRUMENTATION
    OTHER NEWS FROM ING
    TELESCOPE TIME
    Previous: Fibre Feeding the UES Up: Table of Contents Next: The Isaac Newton Group of Telescopes and ESO

    Other available formats: PDF | gzipped Postscript

    UltraDAS and ING FITS Headers

    Nicholas A. Walton and Guy T. Rixon (ING)

    The new data acquisition system for the ING, the UltraDAS (see Rixon et al., Proc. SPIE, 4009, 2000, in press), is being implemented for use with all ING detectors. The UltraDAS development is a key component of the ING's new observing system, the philosophy of which is described in Walton et al., 1998, Proc. SPIE, 351, pp. 197–208.

    The UltraDAS was first commissioned on the INT's Wide Field Camera (WFC) in August 1999, resulting in much improved readout speeds. It has subsequently been released for use with the two chip EEV mosaic used with the WHT's UES and PFC and most recently with both detectors (EEV42 and TEK) of the INT's IDS. The WHT's ISIS spectrograph will be converted to use the UltraDAS by the end of 2000.

    Along with the introduction of UltraDAS, the format of the FITS data product that the ING provides has changed. The main impact that the visiting observer will see is that their data will now be in the so-called Multi-Extension FITS format (MEF).

    This paper describes the ING UltraDAS version s9.1 and later.

    1. UltraDAS

    The UltraDAS generates FITS files on disk as its final product. The UltraDAS produces one FITS file per observation. Where one camera produces data from multiple readout-amplifiers, detectors or detector controllers, only one observation is deemed to have taken place; one run number is issued and all the pixels go into one FITS file.

    Hence, in the case of the INT's WFC, with an array of four CCDs, the data from all four CCDs is contained in one file with a unique run number. This is a change from the case with the old data acquisition system where one exposure would have generated in this case four individual image frames, each containing the data from just one of the array CCDs.

    The UltraDAS produces FITS files as defined by issue 2.0 of NASA's standard (NOST 100-2.0 —see http://fits.gsfc.nasa.gov). All observations are stored in FITS files with image extensions, even if there is only one image per file. One image extension is produced for each contiguous raster in the output.

    The reference document describing the ING FITS headers is available on-line at: http://www.ing.iac.es/~docs/ins/das/ins-das-26/ins-das-26.html.

    1.1. The UltraDAS Structure

    The primary HDU, or Header Definition Unit, has the following structure:
     

    1. Mandatory descriptors, such as SIMPLE and BITPIX, with NAXIS set to zero to indicate no associated image.
    2. The run packet (where a packet is a set of descriptors from the same source), written by UltraDAS.
    3. Packets of descriptors from outside UltraDAS (e.g. from the instrument control system (ICS), telescope control, etc).
    4. A packet of descriptors detailing the timing of the integration (usually from inside UltraDAS, but may come as a packet from the ICS).
    5. A packet describing the state of the camera from inside UltraDAS.
    6. A HISTORY descriptor marking the end of the header written to file by UltraDAS.
    7. The END descriptor.


    Each image extension has the structure:
     

    1. Mandatory descriptors for image extension.
    2. INHERIT.
    3. Channel packet.
    4. Integration packet.
    5. END.
    6. Image.


    The number of image extensions is determined by the number of detectors in the array, the number of windowed readouts, etc. In the simplest case, there is one image extension per output amplifier.

    The pixels may be in any FITS format. Typically, CCD pixels are recorded as signed 16-bit integers BITPIX=16, BZERO=32768, BSCALE not present). IR images are typically stored as 32-bit floating numbers (BITPIX=32, BZERO not present, BSCALE not present).

    1.2. Image Extensions

    This use of image extensions was developed by the NOAO for the cameras at KPNO (based on FITS image extensions as proposed by Ponz et al. (1992) —see http://fits.cv.nrao.edu/documents/standards/image.ps) and is an emerging de-facto standard for multi-channel cameras. ESO uses MEF format for WFI@2.2m, MEF is also offered at the CFHT with the CFH12K camera. However, the generalisation to multiple windows has been devised specifically for ING.

    Some FITS keywords are provided to match the conventions of IRAF and the NOAO conventions; some are traditional at ING. This means that some data are duplicated.

    The INHERIT keyword comes from the STScI convention on inheritance of HDUs, as described in NASA's user guide to FITS (see http://fits.gsfc.nasa.gov/). The keyword, which takes the Boolean value T, states that the extension HDU to which it applies should inherit non-conflicting descriptors from the primary HDU. Thus, if one channel of the observation is extracted to a separate file, it carries with it all the relevant information from the primary HDU. To make this scheme work, there must not be an image following the primary HDU.

    For keywords contained in the both the primary HDU and the image extensions, the value set in the extension takes priority. Take for example the case of INGRID, the ING's IR detector. The keyword EXPTIME in the primary HDU would represent the total exposed time. Each extension might contain individual non-destructive reads, the EXPTIME associated with any extension would then be the exposed time up-to that point.

    At the time of writing, UltraDAS does not use other FITS extensions such as tables. It may do so in later releases.

    1.3. Timing Information

    With the new UltraDAS (from version s9.1) the recording of timing information in the FITS headers has changed. This is to accommodate the use of UltraDAS with infra-red detectors, where exposure timing information is required in the individual extensions.

    Thus the timing keywords, EXPOSED, ELAPSED and UTSTART, now appear in the image extension headers. But, in order to ensure backwards compatibility, these keywords are duplicated in the primary HDU, with the following rules being followed:
     

    1. The timing keywords always appear in the main HDU.
    2. If the detector has a shutter controlled by the DAS (i.e. all but INT WFC), then the timing keywords also appear in the extension HDUs.
    3. The cards in the extensions override the cards in the main HDU (normal inheritance).
    4. The times in the main HDU are the ruling times for the observation as a whole; e.g. in an INGRID run, the start of the first integration and the longest integration of any image in the file.
    5. The times in the extension HDUs are specific to the associated image.


    1.4. World Coordinate System

    Each image has a primary world co-ordinate system (WCS). The primary WCS reserves space in the header in which data-reduction software may later write celestial coordinates. The primary WCS defines the positions of images in detector (pixel) coordinates in the focal plane. The WCS arrangements are described in the channel packet. There is no "WCS packet" covering the whole camera.

    Background, upon which the UltraDAS WCS specification is based, can be found in the ING software document INS-DAS-19: Coordinate Systems for UltraDAS (at http://www.ing.iac.es/~docs/ins/das/ins-das-19/ins-das-19.html). Also, the NRAO information page (and links therein) on 'Representation of World Coordinate Systems in FITS' at http://www.cv.nrao.edu/fits/documents/wcs/wcs.html has useful information.

    2. Data Image Sizes

    The introduction of UltraDAS (version s9.1 and greater) sees some changes to the CCD data package size. The existing detectors have the same number of active pixels as always. However, in some cases the format of the electronically added bias and over-scan regions have changed.

    For instance, TEK5, a detector now in use with the INT+IDS, has 1024×1024 active pixels. Before July 2000, it appeared in a image of size 1124×1124, the extra pixels being bias and over-scan regions. Its new size is 1100×1040, the bias regions having changed. Observers are asked to be aware of this.

    Further, when binning OR windowing any particular CCD, the readout characteristics MAY change. This could mean a change of gain and noise characteristics. However, for most detectors, windowing or binning will not change the selected readout speed (per pixel). These details will be available on the ING Detector www pages.

    3. Handling Multi-Extension Format Files

    As stated previously the UltraDAS produces FITS format data files. The visiting astronomer typically receives a copy of these files on tape (DAT) or via ftp.

    3.1. IRAF

    IRAF is able to handle multi-extension fits data. For example, IRAF provides a full package for handling mosaic data array's —mscred. The IRAF guide to this gives a fuller description of how IRAF handles MEF data —see the guide to the NOAO MOSAIC data handling software at http://iraf.noao.edu/scripts/irafhelp?mscguide.

    A brief example:

    cl> imhead r200546[0] l+

    would give a full listing of the FITS header of the primary HDU of that run.

    cl> imhead r200546[1] l+

    however, would only list the FITS headers of the primary HDU and the first image extension, as the INHERIT=TRUE keyword is set.

    3.2. STARLINK

    Full support for MEF files is not yet available in Starlink software, although work to correct this position is underway.

    People who wish to reduce their data using Starlink, need to use one of three possible workarounds. The first is to use the IRAF mscsplit task (within the mscred package) to split MEF files into separate images. The second is to use the IRAF fxsplit task within the fitsutil package, this splits a MEF file into single FITS files. These can then be converted to Starlink's NDF format with the CONVERT tasks: FITS2NDF or IRAF2NDF. The third method involves converting the whole MEF to NDF format (using FITS2NDF) and then extracting individual NDFs using the KAPPA command NDFCOPY.

    In the near future (with a release date tentatively set for end 2000) fuller support for MEF data will be available. A new FITS2NDF convertor will allow the extraction of specific image extensions into single NDFs and a new version of GAIA will provide native access to MEF extensions (images and tables).

    At that time all Starlink applications will also allow automatic on-the-fly conversion for selecting specific MEF extensions. This means you will be able to use commands like:

    % stats 'ingmef.fits[1]'

    to get statistics for the first image extension of ingmef.fits.

    For updates on the Starlink software referred to above please contact Peter Draper, P.W.Draper@durham.ac.uk, or see his WWW home page at
    http://star-www.dur.ac.uk/~pdraper/.

    4. Closing Remarks

    The introduction of the UltraDAS will bring significant benefits to the visiting astronomer. Readout times are much reduced, now being silicon limited in most cases. Hence observing on-sky efficiencies are maximised. Further one system will be available to control ALL of ING's optical and infra-red detectors, this simplifying use for observers and reducing operation support costs.

    Further information about this topic can be obtained from the UltraDAS project scientist, Nic Walton (naw@ing.iac.es).

    More general information about instrumentation developments can be found under the Instrumentation Developments area of the ING web
    pages at http://www.ing.iac.es/Astronomy/

    Thanks to Peter Draper for providing information on the use of STARLINK software to handle ING MEF data.
     
     

    Email contact: Nic Walton (naw@ing.iac.es)
     
     

    Previous: Fibre Feeding the UES Up: Table of Contents Next: The Isaac Newton Group of Telescopes and ESO
    GENERAL SCIENCE TELESCOPES AND INSTRUMENTATION OTHER NEWS FROM ING TELESCOPE TIME
    © Isaac Newton Group of Telescopes