Subject: Draft of FITS standard revision 1.2 available for comment

From: Richard White <rwhite at nssdc.gsfc.nasa.gov>
Date: Wed, 15 Apr 1998 10:24:31 -0400 (EDT)

PLEASE REDISTRIBUTE WIDELY

Call for comments on Revised FITS Standard

The NASA/Science Office of Standards and Tecnology (NOST) Draft Standard
100-1.2, Definition of the Flexible Image Transport System (FITS), is now
available for review and comment. This is a major revision to the previous version 1.1 of the FITS standard that was adopted in 1995.  This Standard is being
developed by a NOST-sponsored Technical Panel.

FITS Technical Panel
Robert J. Hanisch, Chair			STScI
Barry M Schlesinger, Secretary			NASA/FITS Support Office
Allen Farris					STScI
Eric W. Greisen					NRAO
William D. Pence				NASA/GSFC
Peter J. Teuben					UMd
Randall W. Thompson				STScI/CSC(formerly at GSFC/IUE)
Archibald Warnock				A/WWW Enterprises

The purpose of distributing this Draft Revision to the NOST FITS Standard is to
provide for community review and comment.  The Technical Panel will review and
respond to all comments.  The Panel will either incorporate the substance of a
comment into the Standard, or it will instead provide the reasons for not doing
so and describe any revision to the Standard motivated by the comment.  After
the panel has completed review of and responded to all comments, the final
version will be submitted to NOST for certification.  Upon certification, the
final version number will be 2.0.  It will then be submitted to IAU Commission 5
for formal acceptance as the IAU standard.

Copies of the standard are available in two ways: paper copies and access to
electronic copies via the WWW.  Electronic copies are available formatted for
LaTeX, PostScript, gziped Postscript and html.  The electronic versions are
posted on the FITS Support Office web site homepage at
http://fits.gsfc.nasa.gov/

Paper versions may be requested from the National Space Science Data Center
Coordinated Request and User Support Office (CRUSO) at

Coordinated Request User Support Office (CRUSO)
Code 633,
National Space Science Data Center
NASA Goddard Space Flight Center
Greenbelt, Maryland 20771, USA

E-mail: request at nssdca.gsfc.nasa.gov
Telephone: (301) 286-6695
FAX: (301) 286-1635

All comments should be mailed to the fitsbits exploder at
fitsbits at fits.cv.nrao.edu, or posted to the newsgroup sci.astro.fits. 
Dr. William Pence, a member of the technical panel,
will oversee the reading, discussion, and panel response to all comments.
There will be an approximately 3 month period for comments.  All comments
should be submitted by July 15, 1998.

The development of the standard and its certification is supported by the FITS
Support Office in the Astrophysics Data Facility at NASA's Goddard Space
Flight Center.

FITS Support Office
Code 631
NASA/Goddard Space Flight Center
Greenbelt, MD 20771
USA

e-mail:	fits at fits.gsfc.nasa.gov
http://fits.gsfc.nasa.gov/
+1-301-286-6695 

List of Significant Changes Between Versions 1.1 and 1.2 (Draft) of the NOST
FITS Standard

Section            Description of Changes
-------    ---------------------------------------------

 3:       Definitions have been added, deleted, or revised:
           Added: ASCII NULL, DAT, Fraction, Heap, IAUFWG,
                      Mantissa, Primary HDU, Repeat count
           Deleted:   AIPS, CfA, ESO, NOAO, NRAO, STScI
           Revised:   Entry, Floating point, Indexed keyword

 4.6:     New section describing Physical Blocking.  Incorporates some text
          previously contained in Appendix B.

 5.1.2.2: Explicitly states that null-valued keywords are allowed.

 5.1.2.3: Keyword comment, if present, must be preceeded by a slash.

 5.2:     References to ANSI FORTRAN-77 have been removed and
          replaced with explicit definitions of free format values.

 5.2:     Keyword values are restricted to be a single value
          and not an array of values.

 5.2.1:   Fixed format character string values no longer need to be
          padded with blanks to be at least 8 characters long.
          (e.g., XTENSION= 'TABLE' is now a legal keyword record).

 5.2.1:   Previous requirement that reading the data values should
          not require decoding any more than the first eight
          characters of a character string value of a keyword has
          been dropped.

 5.2.2:   Explicitly states that a logical value must consist
          of a single `T' or `F' character, followed only by a
          space or a slash character.

 5.2.3:   Explicitly states that an integer value must not contain
          embedded spaces and is always interpreted as a signed
          decimal value.

 5.2.4:   Explicitly states that a real floating point value must not
          contain embedded spaces. The decimal point is not required,
          so values like 12, and 1E30 are valid, but E30 is not.

 5.2.5:   Fixed format for complex integers is no longer defined.
          Free format complex integer values must be enclosed in
          parentheses separated by a comma, e.g. (14, -45).

 5.2.6:   Fixed format for complex reals is no longer defined.
          Free format complex real values must be enclosed in
          parentheses separated by a comma, e.g. (14.5, -4.5E+5).

 5.4.1.1  Explicitly states that no other keywords may intervene between
          the SIMPLE and last NAXISn keyword in the primary header.
          The SIMPLE keyword must not appear in extension headers.

 5.4.1.2  Explicitly states that no other keywords may intervene between
          the XTENSION and last NAXISn keyword in an extension.

 5.4.2    The description of the DATE and DATE-OBS keywords has been
          modified in accordance with the new Y2000 FITS agreement.

 6.3      Definition of IEEE floating point has been moved to appendix H.

 8.1      Explicitly states that no other keywords may intervene between
          the XTENSION and TFIELDS keywords in an ASCII table extension.

          The TFORM format codes must be in upper case.  Numeric values
          in ASCII tables are always decimal, and never binary, octal,
          hexadecimal, or other representation.

 8.1.5    New discussion about selecting a format appropriate to the
          data.   References to ANSI FORTRAN-77 have been removed and
          replaced with explicit definitions of how each format should
          be interpreted.

 8.2      Definition of the image extension has been added.

 8.3      Definition of binary table extension has been moved from
          Appendix A into the standard itself.   The TFORM format codes
          must be in upper case.

 8.3.4    Explicit definitions are given for the possible display formats.

Appendix A: (new) gives a formal syntax for keyword card images.

Appendix D: (new) discusses time scale issues related to the new
            DATE-OBS keyword format.

Appendix H: (new) defines IEEE floating point formats

-----------------------------------------------------------------------------

Types of keywords that are explicitly allowed in the new FITS standard
-----------------------------------------------------------------------

KEYWORD =                      / the value of this keyword is undefined
XTENSION= 'TABLE'              / string can be less than 8 chars long
REALVAL =                   14 / decimal point is not required for reals
COMPLEXI=            (12, -45) / complex integer value
COMPLEXR=       (12.5, 5.6E-3) / complex real value
DATE    = '2000-01-01T11:45:59.999' / new date format

Types of keywords that are explicitly disallowed in the new FITS standard
-----------------------------------------------------------------------

KEYWORD =               3.1415   Value of Pi (no slash before comment)
KEYWORD =          1,2,3,4,5,8 / arrays of values are not allowed
LOGICAL =                 TRUE / logical values must be only T or F
INTVAL  =                 0777 / must not be interpreted as octal number
INTVAL  =               124 56 / embedded spaces not allowed in integers
REALVAL =            1.34 E+11 / embedded spaces not allowed in reals
REALVAL =                  E20 / number preceeding the exponent is required

---

From: Don Wells <dwells at nrao.edu>
Date: 16 Apr 1998 10:57:58 -0400

Dear friends of FITS,

>>>>> "R.White" == Richard White <rwhite at nssdc.gsfc.nasa.gov> writes:
    R.White> The NASA/Science Office of Standards and Tecnology (NOST)
    R.White> Draft Standard 100-1.2, Definition of the Flexible Image
    R.White> Transport System (FITS), is now available for review and
    R.White> comment. This is a major revision to the previous version
    R.White> 1.1 of the FITS standard that was adopted in 1995.  ..

Acting as Chair of the IAU FITS Working Group (the body which controls
the FITS standard), I want to take this opportunity to thank NASA
Headquarters, the NASA/NOST and the FITS Support Office at NASA/GSFC
for supporting this project to produce a comprehensive, definitive
version of the FITS standards. Their demonstrated will to maintain
their support of this project for so many years in the face of budget
difficulties and organizational changes is admirable.

The FITS Technical Panel (Hanisch [Chair], Schlesinger, Farris,
Greisen, Pence, Teuben, Thompson, Warnock) which produced this
document gets my highest praise for their service to the community.
The Panel asked for my opinion on several technical issues in recent
years. During those discussions I became quite aware of the
dedication, professionalism and attention to detail which has
characterized their work.

As an example of "attention to detail", I cite the subtle wording of
the last sentence in section 5.1.2.1 (Keyword) on page 15: 'For
indexed keywords with a single index the counter shall not have
leading zeroes.' Why do they say 'with a single index'?!? Well, the
answer is that, although the indexed keywords mentioned in the
document (e.g., NAXIS2, CRPIX1) obey this traditional rule, the panel
want to leave open the possibility for double-indexed keywords to have
fixed format; such keywords are likely to be needed in a future World
Coordinate System [WCS] agreement.  So, this document is not merely
codifying existing FITS practice (the formal mission of the NASA
project), it is also establishing meta-rules which prepare the path
for the evolution of FITS.

    R.White> The purpose of distributing this Draft Revision to the
    R.White> NOST FITS Standard is to provide for community review and
    R.White> comment.  The Technical Panel will review and respond to
    R.White> all comments..
    R.White> All comments should be mailed to the fitsbits exploder at
    R.White> fitsbits at fits.cv.nrao.edu, or posted to the newsgroup
    R.White> sci.astro.fits..

I urge the entire worldwide FITS community to review this document and
comment on it in sci.astro.fits/fitsbits. The document is destined to
become the definitive response to the question 'what are the FITS
standards?' and it is, therefore, important that the official answer
should represent a true consensus of the entire astronomy community.
Public discussion in this newsgroup/mailing-list is the best way to
create and exhibit such consensus.

    R.White> .., the final version.. will.. be submitted to IAU
    R.White> Commission 5 for formal acceptance as the IAU standard.

After NOST certifies that the work of the Panel appears to represent
consensus of the community, the document will be considered by the
three regional FITS committees. After all three have approved it by
formal votes, it will be considered by the IAU FITS Working Group. The
IAUFWG has the authority, under a resolution of the IAU General
Assembly, to declare the document (by a formal vote) to be the
official version of the FITS standards, superceding the various papers
which have been published in Astronomy and Astrophysics Supplements
over the past 17 years.  I intend to argue that a version of this
document should also be published in an issue of A&A Supplements,
because it is critical to our long-term archiving strategy that the
documentation of our bitstreams should be available in archival
professional journals which will survive at least as long as our
bitstreams will survive.

-Don
-- 
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
		    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA

---

From: William Thompson <William.T.Thompson.1 at gsfc.nasa.gov>
Date: Fri, 17 Apr 1998 19:12:29 -0400

>     R.White> 1.1 of the FITS standard that was adopted in 1995.  ..

I no longer have access to the original message.  Where is the draft
standard?  I went to the NOST page, and couldn't find it.

Bill Thompson

---

From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Date: Fri, 24 Apr 1998 11:19:26 +0200 (MET DST)

> fitsbits at fits.cv.nrao.edu, or posted to the newsgroup sci.astro.fits. 

  Here they are.

First of all I would commend the very useful work done in providing a
comprehensive and up to date view of the standard, and in particular I feel
that having it on line on the Web, in a very friendly way to consult, is
great. [I look forward to the pleasure to tell to somebody, 'look your
program is wrong, see http://.....' :-) ]

Therefore the comments are minor

General

I endorse Don Wells comment that the revised standard shall somehow be
also published on a journal (probably a supplement series).

General

deprecated feature shall be hilighted in the text (e.g. boldface, on 
standalone lines)

1.2 Scope

would it be the right time to freeze and discourage use of some of the earlier
extensions (random groups and ASCII tables) which are no longer justified ?

4.3.1

just for clarity redefine here a "card image" as an 80-byte card image.

4.3.2

in describing array storage order, a note that this is the storage order used
by Fortran would be useful.

4.5

are these special records really necessary ?

node53.html : NAXISn Keywords

"A value of zero for any of the NAXISn signifies that no data follow the
header in the HDU. If NAXIS is equal to 0, there should not be any NAXISn
keywords." 

is this not somewhat redundant and confusing, since already a NAXIS "value of
zero signifies that no data follow the header in the HDU." ?

http://fits.gsfc.nasa.gov/documents/nost_1.2/node56.html
http://fits.gsfc.nasa.gov/documents/nost_1.2/node57.html

the description of the XTENSION Keyword should more properly appear in the
second of these pages

TELESCOPE and INSTRUME

is it worth clarifying that for space missions TELESCOPE is the spacecraft
and INSTRUME a combination of eventual optics systems and detector ?

6.3

the text is not clear about the endianness of the IEEE data, while we know
this is a critical item. A reference table in appendix about the most common
OS usages should be useful.

----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)      
----------------------------------------------------------------------------
Fuscim donca de Miragn        E tornem a sta scio' in Bregn                 
Che i fachign e i cortesagn   Magl' insema no stagn begn                    
Drizza la', compa' Tapogn                            (Rabisch, II 41, 96-99)
----------------------------------------------------------------------------
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html             
----------------------------------------------------------------------------

---

From: Clive Page <cgp at nospam.le.ac.uk>
Date: 27 Apr 1998 10:42:23 +0100

In article <Pine.OSF.3.95.980417173858.28733T-100000 at poseidon.ifctr.mi.cnr.it>,

>extensions (random groups and ASCII tables) which are no longer justified ?

I would support this, except for the fact that ASCII tables seem to be
alive and well.  For example the CDS at Strasbourg has an unrivalled
collection of source catalogues and other tabular data.  They hold them in
some internal form, but produce FITS tables for export.  But these are
always ASCII tables.  I asked CDS staff last year why they didn't use
binary tables (because more efficient, no loss of numerical precision,
etc);  they vigorously defended the use of ASCII tables.  Unfortunately I
don't recall now all the reasons they cited - perhaps someone from the CDS
reads this group and can enlighten us?

-- 
-- 
Clive Page,
Dept of Physics & Astronomy,        
University of Leicester.