Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4047

MIME Sub-type Registrations for Flexible Image Transport System (FITS)

Pages: 23
Informational

Top   ToC   RFC4047 - Page 1
Network Working Group                                           S. Allen
Request for Comments: 4047                          UCO/Lick Observatory
Category: Informational                                         D. Wells
                                    National Radio Astronomy Observatory
                                                              April 2005


                    MIME Sub-type Registrations for
                 Flexible Image Transport System (FITS)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS.

Table of Contents

1. Introduction.................................................. 2 2. Conventions Used in this Document............................. 2 3. Overview...................................................... 2 4. FITS Definition............................................... 3 4.1. FITS Structure.......................................... 3 4.2. History of FITS Features................................ 5 4.3. Stability of the FITS definition........................ 6 4.4. Portability of FITS files............................... 7 4.5. Application Programming Interfaces to FITS.............. 7 4.6. FITS File Conformance Testing........................... 8 4.7. Archives That Distribute FITS Files..................... 8 5. IANA Considerations........................................... 9 5.1. Registration of application/fits........................ 10 5.2. Registration of image/fits.............................. 14 6. References.................................................... 19 6.1. Normative References.................................... 19
Top   ToC   RFC4047 - Page 2
       6.2.  Informative References.................................. 20
   7.  Security Considerations....................................... 21
   8.  Contributors.................................................. 21
   9.  Acknowledgements.............................................. 22
   Authors' Addresses................................................ 22
   Full Copyright Statement.......................................... 23

1. Introduction

The FITS file format [FITS] was designed in order to facilitate the interchange of astronomical image data between observatories. FITS provides a means of transporting arrays and tables of data and keyword/value pairs of metadata. FITS is defined by standards documents that are approved by the International Astronomical Union (IAU, http://www.iau.org/) and published in refereed journals. Before the inception of HTTP, astronomers used the Internet to exchange FITS files. Multiple unofficial media types for FITS files [ASU] came into use shortly after the inception of the WWW and have remained in use. Currently (2005) the international astronomical community is pursuing many cooperative efforts (e.g., [IVOA], [NVO], [AstroGrid], [AVO]) to produce web services that provide astronomical data. The exchange of FITS files is a fundamental element of the prototypes for these web services [SIAP]. The astronomical community has to agree to use one set of media types for FITS files in order to promote interoperability of its various services. In its simplest form, FITS is used as a means of transporting astronomical image data in a raster form along with coordinate information and other standard and locally defined metadata. In such applications FITS is much like the well-known TIFF format [TIFF] with the addition of the GeoTIFF tags [GeoTIFF]. However, FITS is capable of describing a much broader range of data than 2-dimensional rasters. A consensus has developed in the FITS community that two media types are needed: one for images and one for all other cases.

2. Conventions Used in this Document

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [Require].

3. Overview

This document describes the registration of the MIME media sub-types "application/fits" and "image/fits".
Top   ToC   RFC4047 - Page 3
   In 1988 the International Astronomical Union formed the FITS Working
   Group (IAUFWG) to oversee matters pertaining to the evolution of the
   FITS data format.  The IAUFWG has approved the submission of this
   document and the registration of these two MIME types.

4. FITS Definition

FITS is defined by a document approved by the International Astronomical Union (IAU) and published in the journal Astronomy & Astrophysics [NOST]. Conventions for additional keywords used in FITS files are proposed by interested parties and negotiated and reviewed by ad hoc committees of the FITS community. If such usage of additional keywords is approved by national committees and the IAUFWG then they become new reserved keywords in the FITS standard and are published in an ongoing series of papers (e.g., [WCS1, WCS2]). Copies of the standard documents can be found at the following sites: http://fits.gsfc.nasa.gov/ http://archive.stsci.edu/fits/ http://www.cv.nrao.edu/fits/ http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html Although a brief structure and feature description is provided in this section as background information, the reader is directed to the FITS standards documents to obtain complete feature and technical details.

4.1. FITS Structure

A FITS file consists of a sequence of one or more header and data units (HDUs) optionally followed by special records. The structure of a FITS file is based on blocks with a length of 2880 8-bit bytes (23040 bits). This size was chosen because it is evenly divisible by the byte and word lengths of all known computer systems. All FITS files have lengths that are integral multiples of this block size. Each FITS header consists of a sequence of one or more 2880-byte blocks that hold 36 80-character records (36*80=2880). The records consist of ASCII keyword/value pairs plus optional comments. The character set is the 7-bit printing ASCII codes, including the ASCII space. In particular, the control codes CR, LF, FF, TAB and NUL are not used in FITS headers. The keywords are up to 8 characters in length. Some keywords are mandatory, and their meaning is rigidly
Top   ToC   RFC4047 - Page 4
   prescribed.  Among these are keywords that describe the structure and
   size of the subsequent data array.  The standard reserves other
   keywords for the purpose of conveying specifically defined items of
   metadata.  Keywords that are neither mandatory nor reserved may be
   inserted with semantics that are defined by local conventions.  (Some
   local conventions have later been adopted into standardized
   practice.)  The end of the header is signified by a block containing
   the keyword "END".  A simple example of a FITS header for a digital
   image, using only keywords that were specified in the initial FITS
   Agreement of March 1979 [FITS], is as follows:

            1         2         3         4         5         6
   1234567890123456789012345678901234567890123456789012345678901234567..

   SIMPLE  =                    T / file does conform to FITS standard
   BITPIX  =                   16 / 16-bit twos-complement pixel values
   NAXIS   =                    2 / 2-dimensional image
   NAXIS1  =                  512 / first axis length
   NAXIS2  =                  512 / second axis length
   COMMENT  -----------------------------------------------------
   COMMENT   FITS (Flexible Image Transport System) format is defined
   COMMENT   in 'Astronomy and Astrophysics', volume 376, page 359;
   COMMENT   bibcode: 2001A&A...376..359H
   COMMENT  -----------------------------------------------------
   ORIGIN  = 'Lick Observatory   ' /
   DATE    = '2003-11-22T05:23:45' / when this file was written
   END

   (These 13 records are followed by 23 80-character records of ASCII
   spaces, to pad the header block to the 2880-byte FITS block size.)

   The first keyword/value pair, SIMPLE=T, is the signature of FITS; all
   FITS files begin with these characters.  BITPIX is the second keyword
   of all FITS files; legal values for it are 8, 16, 32, -32 and -64.
   NAXIS is the third keyword of all FITS files; legal values for it are
   0 to 999.  NAXIS=0 is legal, and implies that there is no image data
   matrix associated with the header (and the NAXISi keywords must not
   be present); this value is common for files that will be given the
   media type "application/fits" as discussed in section 5.1 of this
   document.  NAXIS=2 is the value most often used for files that will
   be given the media type "image/fits", as discussed in section 5.2 of
   this document (NAXIS=3 FITS images are also common).  The COMMENT
   records will be ignored by FITS reading software, but are used here
   to specify the precise journal citation for the FITS standard, an
   item of information that is important for archiving on timescales of
   decades.  The ORIGIN keyword is commonly used in FITS files to encode
   the name of the institution where the file was produced.  The DATE
   keyword is used to convey the timestamp for the file (whereas the
Top   ToC   RFC4047 - Page 5
   keyword DATE-OBS is used to convey observation start times).  FITS
   headers commonly contain a vast variety of additional keywords used
   to encode metadata.  In particular, a digital image header will often
   include keywords to specify the precise celestial coordinates of the
   pixels of the 2-D matrix, with conventions that became part of the
   FITS standard in 2002 (see [WCS2]).  Finally, the above example
   demonstrates how, in addition to the COMMENT records, 60% of the
   bytes in keyword=value records in FITS headers are reserved for
   comments.  Although the simple header example above is contained in
   only one FITS block, multi-block FITS headers are commonly
   interchanged.

   Following each header is a data unit that consists of a sequence of
   zero or more 2880-byte blocks.  In accordance with the description in
   the keywords of their header, these blocks contain an N-dimensional
   data array, optionally followed by other small groups of array data.
   In most cases, the data array represents either an N-dimensional
   array of image pixel values or a 2-dimensional array of tabular data.

   Following the HDUs a FITS file may contain zero or more 2880-byte
   blocks of special records.  The standard does not specify anything
   about their content.  (This convention for special records is not
   known to have been used for any purpose other than prototyping new
   elements of the standard, such as random groups and BINTABLE.)

   The initial HDU in a FITS file is known as the primary HDU (PHDU);
   any subsequent HDU is known as an extension HDU (XHDU).  The keyword
   content of the PHDU is distinct (a PHDU requires a slight alteration
   before it can become an XHDU, and most types of XHDU cannot become a
   PHDU).  A PHDU may have a data array consisting of zero elements, and
   this will often be the case for FITS files intended to communicate
   tables and multiple images.  An XHDU may be one of several standard
   types, or it may be another conforming type.  Standard types of XHDU
   include "IMAGE" (containing an N-dimensional data array similar in
   most respects to the PHDU), "TABLE" (containing a 2-dimensional table
   of ASCII character data), and "BINTABLE" (containing a 2-dimensional
   table of binary data whose elements may themselves be multi-
   dimensional arrays).

4.2. History of FITS Features

In 1981 the original definition of FITS described a single HDU containing one multi-dimensional image array [FITS], as illustrated by the sample header shown in section 4.1. Subsequent agreements have used the original framework of HDUs and keyword/value pairs to extend FITS while preserving the validity of all existing files. FITS now has standard means of describing multiple arrays of image data and/or multiple tables of numeric and character information.
Top   ToC   RFC4047 - Page 6
   Brief highlights of the history of FITS

      - 1979: Initial FITS Agreement and first interchange of files

      - 1980: Random groups convention developed

      - 1981: Published original (single HDU) definition [FITS]

      - 1981: Published random groups definition [GROUPS]

      - 1982: Formally endorsed by the IAU

      - 1988: Defined rules for multiple HDUs [XTENSION]

      - 1988: FITS Working Group established by IAU [IAUFWG]

      - 1988: Extended to include ASCII tables [TABLE]

      - 1990: Extended to include IEEE floating-point data

      - 1994: Extended to multiple image arrays [IMAGE]

      - 1995: Extended to binary tables [BINTABLE]

      - 1997: Adopted a Y2K-compliant date format

      - 2001: Reiterated existing standard in one paper [NOST]

      - 2002: Approved conventions for world coordinates [WCS1, WCS2]

4.3. Stability of the FITS Definition

After the adoption of FITS by the IAU in 1982, some in the emerging community of FITS users realized that there would be tension between the need for archival stability and the need for evolution. In order to satisfy both of these requirements they set up a controlled parliamentary process. At the time of the Generalized Extensions Agreement [XTENSION], the meta-agreement that controls the evolution of FITS, the FITS community adopted the guiding principle "Once FITS, always FITS". Under this rule, no change may be made to FITS that invalidates existing files. Changes to the FITS standard occur only after action by the IAU FITS Working Group (FWG). The FWG acts only after approval by regional working groups that coordinate FITS activity in various parts of the world. FITS has been adopted as the archival format for image data and interferometric data obtained by many ground-based observatories and for all data from many spacecraft. Many astrophysical archives store
Top   ToC   RFC4047 - Page 7
   their data in FITS format, and most astronomical catalog data has
   been transcribed into FITS files.  The many terabytes of data in
   these archives contribute to the stability of the FITS standard.

4.4. Portability of FITS files

Eric Greisen, one of the authors of the original document [FITS], relates that in 1979 [t]he first FITS files were written by a PL/I program on an IBM 360 under OS/MFT (32-bit, twos-complement numbers and 8-bit EBCDIC characters) and were read by a Fortran program executing on a CDC 6400 under SCOPE (60-bit, ones-complement numbers and 6-bit "Display Code" characters). [Remark] Subsequent evolution of computing hardware and FITS over 25 years has not degraded this ability to transfer the data content. The structure of FITS files is extremely general, and this necessarily complements the nature of astronomical data. FITS is used to store observations of the entire electromagnetic spectrum from radio to gamma rays, from ground-based observatories and from spacecraft. FITS is also used to communicate physical properties other than radiation intensity; these may be inferred from observations or calculated by theoretical models. The pedigree of data in a FITS file typically varies among disciplines; FITS may be used to store raw and uncalibrated data, completely reduced and calibrated data, or both. Nevertheless, the FITS standard provides that the syntactic content of the data and metadata are unambiguously available to posterity. Observatories have developed numerous local conventions for the storage and transfer of data peculiar to their instrumentation and purview. Application software for handling FITS files from different regions of the electromagnetic spectrum has been largely disjoint. For a FITS file that consists of multiple HDUs there are no widely established conventions governing the meaning of, interrelations between, and suggested use of the data sets. Recognition of any local conventions used for FITS data has often been based on heuristics of the additional (non-standard) keyword/value pairs. Fully understanding the semantic content of a FITS file usually requires an external data dictionary.

4.5. Application Programming Interfaces to FITS

Although the definition of FITS is expressed in terms of the bit content of the files, there are widely supported application programming interfaces (APIs) which simplify the task of manipulating
Top   ToC   RFC4047 - Page 8
   FITS files.  Interfaces exist for many languages and operating
   systems.  A partial list of APIs follows:

   CFITSIO      http://heasarc.gsfc.nasa.gov/fitsio/
   fitsTcl      http://heasarc.gsfc.nasa.gov/ftools/fv/fitsTcl_home.html
   WCSLIB       http://www.atnf.csiro.au/people/mcalabre/WCS/
   PyFITS       http://www.stsci.edu/resources/software_hardware/pyfits
   WCSTools     http://tdc-www.harvard.edu/software/wcstools/
   FUNTOOLS     http://hea-www.harvard.edu/RD/funtools/
   IDLASTRO     http://idlastro.gsfc.nasa.gov/
   fitsy        http://cfa-www.harvard.edu/~john/fitsy/
   IUEDAC       http://archive.stsci.edu/iue/iuedacfits.html
   Mathematica  http://documents.wolfram.com/v5/Built-inFunctions/
                       GraphicsAndSound/ImportAndExport/
                       AdditionalInformation/Import.html
   MatLab       http://www.mathworks.com/access/helpdesk/help/techdoc/
                       ref/fitsread.shtml?cmdname=fitsread

   Current lists of more APIs can be found at
   http://fits.gsfc.nasa.gov/fits_libraries.html

   List of applications that use FITS are found in the IANA
   registrations of the media types.

4.6. FITS File Conformance Testing

FITS files can be tested for conformance to the Definition of FITS rules [NOST, WCS1, WCS2] with an application named "fitsverify", which is available at http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ in the form of executable binary files for Solaris, Linux, and Windows platforms, as well as in source code. Although "fitsverify" has not been endorsed by the IAUFWG, users should be aware that the designer of the program was the Secretary of the Technical Panel that produced the published FITS standard [NOST].

4.7. Archives That Distribute FITS Files

As noted in section 4.3 of this RFC, massive (multi-terabyte) data archives that contain and/or distribute FITS files contribute to the stability of the FITS standard. There are numerous publicly available archives of FITS files derived from both space and ground- based observations that span the entire range of the electromagnetic spectrum from radio to gamma-ray wavelengths. The following are examples of such archives, in no particular order:
Top   ToC   RFC4047 - Page 9
   Telescope(s)   URLs for archive access
   ------------   ------------------------------------------------------
   KPNO,CTIO,..   http://archive.noao.edu/nsa/
   VLT,HST,..     http://archive.eso.org/
   Subaru         http://smoka.nao.ac.jp/
   SDSS           http://www.sdss.org/dr3/
   CFHT           http://cadcwww.dao.nrc.ca/cfht/cfht.html
   VLA,VLBA,GBT   http://e2e.aoc.nrao.edu/archive/archive_describe.html
   HST,MAST       http://archive.stsci.edu/
   HEASARC        http://heasarc.gsfc.nasa.gov/w3browse/
   Chandra        http://cxc.harvard.edu/cda/
   LaPalma        http://archive.ast.cam.ac.uk/ingarch/
   BIMA           http://bimaarch.ncsa.uiuc.edu/
   Keck-DEIMOS    http://archive.deep.ucolick.org/
   ComptonGRO     http://cossc.gsfc.nasa.gov/archive/index.html
   Spitzer,..     http://www.ipac.caltech.edu/
   AAT            http://www.aao.gov.au/archive/
   HIPASS         http://www.atnf.csiro.au/research/multibeam/
                          multibeam.html
   JCMT           http://salish.dao.nrc.ca:8080/jcmt/intro.html
   COBE,WMAP      http://lambda.gsfc.nasa.gov/
   EVN            http://www.jive.nl/archive/scripts/listarch.php
   Gemini         http://gemini.ast.cam.ac.uk/sciops/data/dataIndex.html
   XMM-Newton     http://xmm.vilspa.esa.es/external/xmm_data_acc/xsa/

5. IANA Considerations

The general nature of the full FITS standard requires the use of the media type "application/fits". Nevertheless, the principal intent for a great many FITS files is to convey a single data array in the PHDU, and such arrays are very often 2-dimensional images. Several common image viewing applications already display single-HDU FITS files, and the prototypes for virtual observatory projects specify that data provided by web services be conveyed by the data array in the PHDU. These uses justify the registration of a second media type, namely "image/fits", for files which use the subset of the standard described by the original FITS standard paper [FITS]. We note that the media type "image/gif" [MIME2] admits raster images that are three dimensional, because animated GIF images contain two spatial dimensions and one temporal dimension. We note that the media types "image/vnd.dwg" and "image/vnd.dxf" admit data that include three-dimensional vectors and curves as well as objects created by using constructive solid geometry. Following these precedents for the "image" media type, we specify that "image/fits" MAY be used to describe FITS PHDUs that have other than two dimensions. We expect that most files described as "image/fits" will have two-dimensional (NAXIS=2) PHDUs.
Top   ToC   RFC4047 - Page 10

5.1. Registration of application/fits

To: ietf-types@iana.org Subject: Registration of Standard MIME Media type application/fits MIME media type name: application MIME subtype name: fits Required parameters: none Optional parameters: none Encoding considerations: binary FITS files can be quite large. When transferred via HTTP it may be efficient for the transaction to make use of content-coding or transfer-coding values such as "gzip", "compress", or "deflate". Security considerations: FITS provides a means of transporting arrays and tables of data and keyword/value pairs of metadata. The standard FITS keywords are either mandatory or reserved. Mandatory keywords provide information necessary for correct interpretation of the data; reserved keywords merely provide standard bits of metadata. As such, the current standard FITS keywords do not pose security risks. A FITS file author may insert additional keywords with semantics that are not described by the standard. Parties exchanging FITS files may employ locally defined conventions that use various keywords and their values to induce actions on the part of the recipient. There are existing local conventions where such keywords are used to request the reading of other files and/or URIs. There are other local conventions where such keywords are used to modify the state of a telescope and/or instrument. The security implications of local conventions such as these SHOULD be analyzed by the parties employing them. Interoperability considerations: FITS files have been successfully transported between wildly different computers since 1979. The difficulty most likely to be encountered by a FITS application is inability to acquire the computational resources required by a very large FITS file.
Top   ToC   RFC4047 - Page 11
   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E. and M. Calabretta, "Representations of world coordinates
   in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://cxc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   At the present time many of these applications are not designed to
   support use as viewers of "application/fits" files in association
   with web browsers.
Top   ToC   RFC4047 - Page 12
   Additional information:

   A FITS file described with the media type "application/fits" SHOULD
   conform to the published standards for FITS files as determined by
   convention and agreement within the international FITS community.  No
   other constraints are placed on the content of a file described as
   "application/fits".

   A FITS file described with the media type "application/fits" may have
   an arbitrary number of conforming extension header and data units
   (XHDUs) that follow its mandatory primary header and data unit
   (PHDU).  The XHDUs may be one of the standard types ("IMAGE",
   "TABLE", and "BINTABLE") or any other type that satisfies the
   "Requirements for Conforming Extensions" (section 4.4.1 of [NOST]).
   The PHDU or any "IMAGE" XHDU may contain zero to 999 dimensions with
   zero or more pixels along each dimension.

   The PHDU may use the random groups convention, in which the dimension
   of the first axis is zero and the keywords GROUPS, PCOUNT and GCOUNT
   appear in the header.  NAXIS1=0 and GROUPS=T is the signature of
   random groups; see section 7 of the Definition of FITS paper [NOST].

   Recommendations for application writers:

   An application intended to handle "application/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.

   An application intended to handle "application/fits" SHOULD be
   prepared to encounter XHDUs that contain either ASCII or binary
   tables, and to provide a user with access to their elements.

   An application which can modify FITS files or retrieve FITS files
   from an external service SHOULD be capable of writing such files to a
   local storage medium.

   Complete interpretation of the meaning and intended use of the data
   in each of the HDUs typically requires the use of heuristics that
   attempt to ascertain which local conventions were used by the author
   of the FITS file.

   As examples, files with media type "application/fits" might contain
   any of the following contents:

   - An empty PHDU (containing zero data elements) followed by a table
     HDU that contains a catalog of celestial objects.
Top   ToC   RFC4047 - Page 13
   - An empty PHDU followed by a table HDU that encodes a series of
     time-tagged photon events from an exposure using an X-ray detector.

   - An empty PHDU followed by a series of IMAGE HDUs containing data
     from an exposure taken by a mosaic of CCD detectors.

   - An empty PHDU followed by a series of table HDUs that contain a
     snapshot of the state of a relational database.

   - A PHDU containing a single image along with keyword/value pairs of
     metadata.

   - A PHDU with NAXIS1=0 and GROUPS=T followed by random groups data
     records of complex fringe visibilities

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.

   Intended usage: Common

   Persons to contact for further information:

      "Steve Allen"     <sla@ucolick.org>
      "Don Wells"       <dwells@nrao.edu>
Top   ToC   RFC4047 - Page 14
   Author/Change controller:

      "Steve Allen" <sla@ucolick.org>

   The IAU FITS Working Group may authorize changes to this document.

5.2. Registration of image/fits

To: ietf-types@iana.org Subject: Registration of Standard MIME Media type image/fits MIME media type name: image MIME subtype name: fits Required parameters: none Optional parameters: none Encoding considerations: binary FITS files can be quite large. When transferred via HTTP it may be efficient for the transaction to make use of content-coding or transfer-coding values such as "gzip", "compress", or "deflate". Security considerations: FITS provides a means of transporting arrays and tables of data and keyword/value pairs of metadata. The standard FITS keywords are either mandatory or reserved. Mandatory keywords provide information necessary for correct interpretation of the data; reserved keywords merely provide standard bits of metadata. As such, the current standard FITS keywords do not pose security risks. A FITS file author may insert additional keywords with semantics that are not described by the standard. Parties exchanging FITS files may employ locally defined conventions that use various keywords and their values to induce actions on the part of the recipient. There are existing local conventions where such keywords are used to request the reading of other files and/or URIs. There are other local conventions where such keywords are used to modify the state of a telescope and/or instrument. The security implications of local conventions such as these SHOULD be analyzed by the parties employing them.
Top   ToC   RFC4047 - Page 15
   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.

   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E.  and M.  Calabretta, "Representations of world
   coordinates in FITS", Astronomy & Astrophysics, 395, p.  1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://cxc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
Top   ToC   RFC4047 - Page 16
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   Non-astronomical FITS image display applications include:

   netpbm          http://netpbm.sourceforge.net/
   gimp            http://www.gimp.org/
   IDL             http://www.rsinc.com/
   ImageMagick     http://www.imagemagick.com/
   Mathematica     http://www.wolfram.com/
   MatLab          http://www.mathworks.com/
   xv              http://www.trilon.com/xv/xv.html

   There are also two FITS plug-ins for Adobe Photoshop
   (http://www.adobe.com/products/photoshop/), available at
   http://astroshed.com/fitsplug/fitsplug.htm and
   http://www.spacetelescope.org/projects/fits_liberator/

   At the present time many of the applications listed above are not
   designed to support use as viewers of "image/fits" files in
   association with web browsers.

   Additional information:

   A FITS file described with the media type "image/fits" SHOULD have a
   PHDU with positive integer values for the NAXIS and NAXISn keywords,
   and hence SHOULD contain at least one pixel.  Files with 4 or more
   non-degenerate axes (NAXISn>1) SHOULD be described as
   "application/fits", not as "image/fits".  (In rare cases it may be
   appropriate to describe a NULL image -- a dataless container for FITS
   keywords, with NAXIS=0 or NAXISn=0 -- or an image with 4+ non-
   degenerate axes as "image/fits" but this usage is discouraged because
   such files may confuse simple image viewer applications.)

   FITS files declared as "image/fits" MAY also have one or more
   conforming XHDUs following their PHDUs.  These extension HDUs MAY
   contain standard, non-linear, world coordinate system (WCS)
   information in the form of tables or images.  The extension HDUs MAY
   also contain other, non-standard metadata pertaining to the image in
   the PHDU in the forms of keywords and tables.

   A FITS file described with the media type "image/fits" SHOULD be
   principally intended to communicate the single data array in the
   PHDU.  This means that "image/fits" SHOULD NOT be applied to FITS
   files containing MEF (multi-exposure-frame) mosaic images.  Also,
   random groups files MUST be described as "application/fits" and not
   as "image/fits".
Top   ToC   RFC4047 - Page 17
   A FITS file described with the media type "image/fits" is also valid
   as a file of media type "application/fits".  The choice of
   classification depends on the context and intended usage.

   Recommendations for application writers:

   An application that is intended to handle "image/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.  An application writer MAY choose to ignore HDUs beyond the
   PHDU, but even in this case the application SHOULD be able to present
   the user with the keyword/value pairs from the PHDU.

   Note that an application intended to render "image/fits" for viewing
   by a user has significantly more responsibility than an application
   intended to handle, e.g., "image/tiff" or "image/gif".  FITS data
   arrays contain elements which typically represent the values of a
   physical quantity at some coordinate location.  Consequently they
   need not contain any pixel rendering information in the form of
   transfer functions, and there is no mechanism for color look-up
   tables.  An application SHOULD provide this functionality, either
   statically using a more or less sophisticated algorithm, or
   interactively allowing a user various degrees of choice.

   Furthermore, the elements in a FITS data array may be integers or
   floating-point numbers.  The dynamic range of the data array values
   may exceed that of the display medium and the eye, and their
   distribution may be highly nonuniform.  Logarithmic, square-root, and
   quadratic transfer functions along with histogram equalization
   techniques have proved helpful for rendering FITS data arrays.  Some
   elements of the array may have values which indicate that their data
   are undefined or invalid; these should be rendered distinctly.  Via
   WCS Paper I [WCS1] the standard permits "CTYPEnnn = 'COMPLEX'" to
   assert that a data array contains complex numbers (future revisions
   might admit other elements such as quaternions or general tensors).

   Three-dimensional data arrays (NAXIS=3 with NAXIS1, NAXIS2 and NAXIS3
   > 1) are of special interest.  Applications intended to handle
   "image/fits" MAY default to displaying the first 2D plane of such an
   image cube, or they MAY default to presenting such an image in a
   fashion akin to that used for an animated GIF, or they MAY present
   the data cube as a mosaic of "thumbnail" images.  Even in the absence
   of WCS indication of a temporal axis the time-lapse movie-looping
   display technique can be effective, and application writers SHOULD
   consider offering it for all three-dimensional arrays.

   An "image/fits" PHDU with NAXIS=1 is describing a one-dimensional
   entity such as a spectrum or a time series.  Applications intended to
Top   ToC   RFC4047 - Page 18
   handle "image/fits" MAY default to displaying such an image as a
   graphical plot rather than as a two-dimensional picture with a single
   row.

   An application that cannot handle an image with dimensionality other
   than 2 SHOULD gracefully indicate its limitations to its users when
   it encounters NAXIS=1 or NAXIS=3 cases, while still providing access
   to the keyword/value pairs.

   FITS files with degenerate axes (i.e., one or more NAXISn=1) MAY be
   described as "image/fits", but the first axes SHOULD be non-
   degenerate (i.e., the degenerate axes SHOULD be the highest
   dimensions).  An algorithm designed to render only two-dimensional
   images will be capable of displaying such an NAXIS=3 or NAXIS=4 FITS
   array that has one or two of the axes consisting of a single pixel,
   and an application writer SHOULD consider coding this capability into
   the application.  Writers of new applications which generate FITS
   files intended to be described as "image/fits" SHOULD consider using
   the WCSAXES keyword [WCS1] to declare the dimensionality of such
   degenerate axes, so that NAXIS can be used to convey the number of
   non-degenerate axes.

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.
Top   ToC   RFC4047 - Page 19
   Intended usage: Common

   Persons to contact for further information:

      "Steve Allen"     <sla@ucolick.org>
      "Don Wells"       <dwells@nrao.edu>

   Author/Change controller:

      "Steve Allen"     <sla@ucolick.org>

   The IAU FITS Working Group may authorize changes to this document.

6. References

6.1. Normative References

[Require] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [NOST] Hanisch, R., et al., "Definition of the Flexible Image Transport System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001. [WCS1] Greisen, E. and M. Calabretta, "Representations of world coordinates in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002. [WCS2] Calabretta, M. and E. Greisen, "Representations of celestial coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.
Top   ToC   RFC4047 - Page 20

6.2. Informative References

[FITS] Wells, D., et al., "FITS: A Flexible Image Transport System", Astronomy & Astrophysics Supplement, 44, p. 363, 1981. [GROUPS] Greisen, E. and R. Harten, "An extension of FITS for groups of small arrays of data", Astronomy & Astrophysics Supplement, 44, p. 371, 1981. [XTENSION] Grosbol, P., et al., "Generalized extensions and blocking factors for FITS", Astronomy & Astrophysics Supplement, 73, p. 359, 1988. [IAUFWG] McNally, D., ed., "Transactions of the IAU, Vol. XXB 1988, Proceedings of the Twentieth General Assembly Baltimore 1988", Kluwer Academic, p. 52 (Resolution B2), 1988. [TABLE] Harten, R., et al., "The FITS tables extension", Astronomy & Astrophysics Supplement, 73, p. 365, 1988. [IMAGE] Ponz, J., et al., "The FITS image extension", Astronomy & Astrophysics Supplement, 105, p. 53, 1994. [BINTABLE] Cotton, W., et al., "Binary table extension to FITS", Astronomy & Astrophysics Supplement, 113, p. 159, 1995. [Remark] Greisen, E., "FITS: A remarkable achievement in information exchange" in "Information Handling in Astronomy -- Historical Vistas", A. Heck, ed., Kluwer Academic, p. 71, 2003. [IVOA] The International Virtual Observatory Alliance, http://www.ivoa.net/ [NVO] The US National Virtual Observatory, http://www.us- vo.org/ [AstroGrid] The UK AstroGrid, http://www.astrogrid.org/ [AVO] The European Astrophysical Virtual Observatory, http://www.euro-vo.org/ [ASU] Albrecht, M., et al., "Astronomical Server URL", http://vizier.u-strasbg.fr/doc/asu.html, 1996.
Top   ToC   RFC4047 - Page 21
   [SIAP]      Tody, D., et al., "Simple Image Access Prototype
               Specification", http://www.us-vo.org/pubs/, 2002.

   [TIFF]      Adobe Systems Incorporated, "TIFF Revision 6.0",
               http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
               1992.

   [GeoTIFF]   Ritter, N. and M. Ruth, "GeoTIFF Format Specification",
               http://www.remotesensing.org/geotiff/geotiff.html, 2000.

7. Security Considerations

The security considerations of interchanging FITS files are discussed above within the text of the IANA registration for each media type.

8. Contributors

Several individuals have made significant contributions to the content and clarity of this text: - Francois Ochsenbein (Observatoire Astronomique de Strasbourg) - Clive Davenhall (Institute for Astronomy of the Royal Observatory Edinburgh) - Tom McGlynn (Laboratory for High Energy Astrophysics of the NASA Goddard Space Flight Center) - Lucio Chiappetti (Milan section of the Italian Istituto di Astrofisica Spaziale e Fisica Cosmica) - William Pence (NASA High Energy Astrophysics Science Archive Research Center) - Arnold Rots (High Energy Astrophysics Division of the Smithsonian Astrophysical Observatory) - Doug Tody (National Radio Astronomy Observatory) - Bob Hanisch (Space Telescope Science Institute) - Mark Calabretta (Australia Telescope National Facility)
Top   ToC   RFC4047 - Page 22

9. Acknowledgements

This document originated when William Joye of the Research and Development Group at the Smithsonian Astrophysical Observatory High Energy Astrophysics Division discovered many experimental and unofficial MIME media types being used by various agencies. Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) contributed the FITS entries for the magic number file that permits the Unix-like "file" command on many systems to identify a FITS file. Nelson Zarate verified that the fgread and fgwrite programs are able to store hierarchical directories containing files with arbitrary MIME media types within a HDU of a FITS file. The fgread and fgwrite programs are part of the FITSUTIL IRAF external package (version dated September 1999) written by N. Zarate, D. Tody, and R. Seaman at National Optical Astronomy Observatory (NOAO).

Authors' Addresses

Steven L. Allen UCO/Lick Observatory University of California Santa Cruz, CA 95064 USA Phone: +1 831 459 3046 EMail: sla@ucolick.org Donald C. Wells National Radio Astronomy Observatory 520 Edgemont Road Charlottesville, Virginia 22903-2475 USA Phone: +1 434 296 0277 EMail: dwells@nrao.edu
Top   ToC   RFC4047 - Page 23
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.