GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4047

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

Allen & Wells Informational [Page 1] RFC 4047 MIME Sub-type Registrations for FITS April 2005

     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".

Allen & Wells Informational [Page 2] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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

Allen & Wells Informational [Page 3] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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

Allen & Wells Informational [Page 4] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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.

Allen & Wells Informational [Page 5] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 Brief highlights of the history of FITS
  1. 1979: Initial FITS Agreement and first interchange of files
  1. 1980: Random groups convention developed
  1. 1981: Published original (single HDU) definition [FITS]
  1. 1981: Published random groups definition [GROUPS]
  1. 1982: Formally endorsed by the IAU
  1. 1988: Defined rules for multiple HDUs [XTENSION]
  1. 1988: FITS Working Group established by IAU [IAUFWG]
  1. 1988: Extended to include ASCII tables [TABLE]
  1. 1990: Extended to include IEEE floating-point data
  1. 1994: Extended to multiple image arrays [IMAGE]
  1. 1995: Extended to binary tables [BINTABLE]
  1. 1997: Adopted a Y2K-compliant date format
  1. 2001: Reiterated existing standard in one paper [NOST]
  1. 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

Allen & Wells Informational [Page 6] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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

Allen & Wells Informational [Page 7] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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:

Allen & Wells Informational [Page 8] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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.

Allen & Wells Informational [Page 9] RFC 4047 MIME Sub-type Registrations for FITS April 2005

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.

Allen & Wells Informational [Page 10] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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.

Allen & Wells Informational [Page 11] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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:
  1. An empty PHDU (containing zero data elements) followed by a table

HDU that contains a catalog of celestial objects.

Allen & Wells Informational [Page 12] RFC 4047 MIME Sub-type Registrations for FITS April 2005

  1. 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.

  1. An empty PHDU followed by a series of IMAGE HDUs containing data

from an exposure taken by a mosaic of CCD detectors.

  1. An empty PHDU followed by a series of table HDUs that contain a

snapshot of the state of a relational database.

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

metadata.

  1. 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>

Allen & Wells Informational [Page 13] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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.

Allen & Wells Informational [Page 14] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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

Allen & Wells Informational [Page 15] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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".

Allen & Wells Informational [Page 16] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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

Allen & Wells Informational [Page 17] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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.

Allen & Wells Informational [Page 18] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 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.

Allen & Wells Informational [Page 19] RFC 4047 MIME Sub-type Registrations for FITS April 2005

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.

Allen & Wells Informational [Page 20] RFC 4047 MIME Sub-type Registrations for FITS April 2005

 [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:
  1. Francois Ochsenbein (Observatoire Astronomique de Strasbourg)
  1. Clive Davenhall (Institute for Astronomy of the Royal

Observatory Edinburgh)

  1. Tom McGlynn (Laboratory for High Energy Astrophysics of

the NASA Goddard Space Flight Center)

  1. Lucio Chiappetti (Milan section of the Italian Istituto di

Astrofisica Spaziale e Fisica Cosmica)

  1. William Pence (NASA High Energy Astrophysics Science Archive

Research Center)

  1. Arnold Rots (High Energy Astrophysics Division of the

Smithsonian Astrophysical Observatory)

  1. Doug Tody (National Radio Astronomy Observatory)
  1. Bob Hanisch (Space Telescope Science Institute)
  1. Mark Calabretta (Australia Telescope National Facility)

Allen & Wells Informational [Page 21] RFC 4047 MIME Sub-type Registrations for FITS April 2005

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

Allen & Wells Informational [Page 22] RFC 4047 MIME Sub-type Registrations for FITS April 2005

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.

Allen & Wells Informational [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4047.txt · Last modified: 2005/04/13 16:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki