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