From leb at Hypatia.gsfc.nasa.gov Wed Jul  1 12:11:59 1992
X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil
X-VM-Bookmark: 25
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1382" "" "1" "July" "92" "14:37:29" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "27" "Re: ODL and ASN.1" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Keywords: Data interchange, standards
Organization: Goddard Space Flight Center
Nntp-Posting-Host: hypatia.gsfc.nasa.gov
From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Subject: Re: ODL and ASN.1
Date: 1 Jul 92 14:37:29 GMT

Both Bill Thompson and Chris Flatters are correct in their assessment of ODL
and ASN.1, and I'm not suggesting that they be used to completely replace FITS
(at least not yet, anyway).  I just want the FITS people to know that there are
other, richer, data description languages out there.

I also posted my original letter to the WGAS mailing list, and I think that
I'll pursue further discussion over there.  The astronomical community may find
that it has a use for other commonly used data transfer formats -- heretical
as that thought may be.

By the way, I'll be starting up a newsgroup to accompany the WGAS mail exploder
called alt.sci.astro.wgas as soon as I can get the attention of the Goddard
newsfeed lords long enough to set up the two-way link to the mail exploder.
If you don't get the alt. news hierarchy, you can subscribe to the WGAS mail
exploder by sending E-mail to listserv at hypatia.gsfc.nasa.gov.  In the body of
the mail message (not the subject line) put the command:

	SUBSCRIBE WGAS Your Name

where "Your Name" is your name, not your E-mail address.  LISTSERV will get the
mailing address from the mail headers.

--
-- Lee E. Brotzman                    Internet:  leb at hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB at SCFMVS
-- NASA Goddard Space Flight Center

From hybl at umbc4.umbc.edu) Wed Jul  1 20:34:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2395" "Wed" "1" "July" "1992" "23:54:48" "GMT" "UMAB-BIOPHYS" "hybl at umbc4.umbc.edu (Dr. Albert Hybl )" nil "45" "On using .fits as a file extension" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: University of Maryland Baltimore Campus
From: hybl at umbc4.umbc.edu (Dr. Albert Hybl (UMAB-BIOPHYS))
Subject: On using .fits as a file extension
Date: Wed, 1 Jul 1992 23:54:48 GMT

The extension '.fits' does not guaranty anything about the contents
of the file.  The contents of the file must be examined to validate
that it conforms with the FITS standard.  The extension is just
a lazy man's way to remember something.  I have seen the extensions:
'.f', '.F', '.for', '.ftn' and others used to identify F77 Fortran
source code.  I _store_ my FITS files with the extension '.fits.Z'
where the '.Z' indicates that the files are compressed.  I
don't think that I can present an 'image.fits.Z' file to IRAF.
Why not?  The '.Z' extension is more standard than '.fits'; I would
like to have the programs look for '.Z' and if the program finds that
the file isn't a standard FITS file after uncompressing, if necessary,
then the program can take some error action.  When the 'uncompress'
program tries to uncompress a fake 'file.Z,' it outputs the message:
"file.Z: not in compressed format."  Surely IRAF and other programs
could do likewise after examination of the contents of the file.

The driving force for this thread seems to be a desire to supplement or
perhaps supplant the use of magnetic tape as the standard image trans-
port modality and to begin to consider the _general_ availability of
astronomy images from internet archives and/or on CD-ROM.  Clearly
one must begin to consider conforming specifications for archiving
image data and especially for an efficient retrieval system.  Perhaps
there already is such a system, I'm not the person who would know.
(See the discussion of ODL and ASN.1 etc.)

Here are two tidbits of information I have read in other newsgroups:

        Two CD-ROM Filesystem Formats:  High Sierra and Rock Ridge.
        ==========================
        The High Sierra format is common and also known as ISO-9660
        and characterized by MS-DOS file naming conventions and an
        8-level deep MAXIMUM directory hierarchy.  The Rock Ridge
        format is newer and permits UNIX-style file-naming conventions
        and directory depths.

        Filesystem Name lengths: DOS/8+3 S5/14 BSD/255 bytes.
        =====================================
        The 14-byte length limit for filenames and path component names
        plus the lack of symbolic links are two deficiencies extant
        in my S5 UNIX system for things I would like to do with my AT&T
        3B1 computer.

Regards,
Albert Hybl (hybl at umbc3.umbc.edu)

From dwells at azalea.cx.nrao.edu Thu Jul  2 12:24:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2633" "Thu" "2" "July" "1992" "17:23:33" "GMT" "Don Wells" "dwells at azalea.cx.nrao.edu " nil "47" "Re: ODL and ASN.1" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
In-Reply-To: leb at Hypatia.gsfc.nasa.gov's message of 1 Jul 92 14: 37:29 GMT
Organization: National Radio Astronomy Observatory, Charlottesville, VA.
From: dwells at azalea.cx.nrao.edu (Don Wells)
Subject: Re: ODL and ASN.1
Date: Thu, 2 Jul 1992 17:23:33 GMT

In article <leb.710001449 at Hypatia> leb at Hypatia.gsfc.nasa.gov (Lee E.
Brotzman) writes:

 LEB> ... I'm not suggesting that [ODL and ASN.1] be used to
 LEB> completely replace FITS (at least not yet, anyway).  I just want
 LEB> the FITS people to know that there are other, richer, data
 LEB> description languages out there.. The astronomical community may
 LEB> find that it has a use for other commonly used data transfer
 LEB> formats.." 

ODL and ASN.1 are fine ideas, but they are not necessarily superior to
the current FITS agreements for the purposes of interchange and
archiving of astronomical datasets. The BINTABLE format (descriptive
language) is strong enough to describe most object types currently
used in astronomy, and the cases which it does not explicitly support
can be implemented by conventions layered on top of BINTABLE (I am not
aware of any interesting exceptions to this assertion). In particular,
the vector fields (blobs) will permit encapsulation of other objects
(BINTABLEs inside BINTABLEs) and the character fields can be used to
"point" to other BINTABLEs (trees of sets of objects). The proposed
Appendix-B pointer convention will support variable-sized objects. The
ODL and ASN.1 notations for describing objects are much more terse
than the equivalent FITS notations, but terseness of description has
never been the primary design objective in FITS negotiations. Our goal
has always been to produce archival-quality self-describing
(paperless) datasets for interchange and archiving. An important
property of our architecture is that it does not depend on an
(ephemeral?) central registry of object descriptions.

There are indeed interchange formats which solve problems for which
FITS does not currently have good solutions. The GIS [Geographic
Information Systems] community has developed a format used by USGS and
others to digitize the information carried in maps. At present I do
not believe that astronomy has applications of this type, but if it
did I would advocate that the FITS community simply declare
XTENSION='<protocol name>' to encapsulate the bitstream of the GIS
standard inside FITS files. In a similar fashion I believe that there
may be a good argument for agreeing to use XTENSION='TIFF' to attach
quick-look overview renderings of FITS objects to the files containing
those objects.

--

Donald C. Wells             Associate Scientist        dwells at nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N 

From fischer at physun.physics.mcmaster.ca Sun Jul  5 17:58:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["359" "" "5" "July" "92" "17:59:20" "GMT" "Phil Fischer" "fischer at physun.physics.mcmaster.ca " nil "12" "Converting Fits to an SGI RGB file" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: Dept. of Physics & Astronomy, McMaster University
Nntp-Posting-Host: physun.physics.mcmaster.ca
From: fischer at physun.physics.mcmaster.ca (Phil Fischer)
Subject: Converting Fits to an SGI RGB file
Date: 5 Jul 92 17:59:20 GMT

If anybody has a program which converts fits to Silicon Graphics RGB format
I would be very grateful if he/she would send me a copy.

Thank You 

Phil

Phil Fischer                         | Hamilton, Ont.
Fischer at Crocus.Physics.McMaster.Ca   | Canada
Dept. of Physics and Astronomy       | L8S 4M1
McMaster University                  | 416-525-9140 X 4574

From dwells at azalea.cx.nrao.edu Mon Jul  6 17:44:50 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2037" "Mon" "6" "July" "1992" "22:39:05" "GMT" "Don Wells" "dwells at azalea.cx.nrao.edu " nil "44" "Re: VLBA UV-data FITS test files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
In-Reply-To: mcs at goblin.caltech.edu's message of Sat, 27 Jun 1992 03: 42:59 GMT
Organization: National Radio Astronomy Observatory, Charlottesville, VA.
From: dwells at azalea.cx.nrao.edu (Don Wells)
Subject: Re: VLBA UV-data FITS test files
Date: Mon, 6 Jul 1992 22:39:05 GMT

In article <1992Jun27.034259.18877 at cco.caltech.edu>
mcs at goblin.caltech.edu (Martin Shepherd) writes: "... I have just been
reading the draft proposal for the new FITS format for interferometer
UV data exchange. Does anybody know if there are any FITS test files
in this format - available by anonymous ftp?..."

anonFTP fits.cx.nrao.edu[192.33.115.8]:/FITS/SampleData/VLBA contains:

       1485 Jul  6 16:19 README
     318012 Jun 19 12:32 VLBA_format.ps
    8663040 Jun 23 16:23 j000015.fits
      12426 Jul  6 15:40 j000015.lis

The README says:

		-*- Sample VLBA distribution file -*-

The FITS file in this directory, j000015.fits, was produced by the
VLBA Correlator in late June 1992, just before the machine was
disassembled for shipment to New Mexico.  The file contains fringe
visibilities from an astronomical source observed by a five-station
array in early April. The file format is described in the document
VLBA_format.ps; it is a set of binary tables ('BINTABLE' extensions).
Current TST versions of AIPS are said to be able to read this file.

Those who are interested solely in the header syntax, not in the
visibility data, should get the file j000015.lis, which contains an
ASCII listing of the headers of all the tables plus size information
for the binary records.

This sample distribution file does *not* conform exactly to the format
described in the document. In particular, the UV data table does not
have the integration time column which is specified in the document.
Both the document and the file format should be regarded as *DRAFT*;
details will be subject to change in the coming months.

Send comments or questions about the VLBA format to John Benson
(jbenson at nrao.edu) and/or Phil Diamond (pdiamond at nrao.edu).
--

Donald C. Wells             Associate Scientist        dwells at nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N 

From pence at heawk1.gsfc.nasa.gov Fri Jul 10 22:56:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2302" "" "8" "July" "92" "20:49:34" "GMT" " William Pence" "pence at heawk1.gsfc.nasa.gov " nil "59" "FITSIO V3.21 is available" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: Goddard Space Flight Center
Nntp-Posting-Host: heawk1.gsfc.nasa.gov
From: pence at heawk1.gsfc.nasa.gov ( William Pence)
Subject: FITSIO V3.21 is available
Date: 8 Jul 92 20:49:34 GMT

                        FITSIO - Version 3.21
                           8 July 1992

This is to announce that Version 3.21 of the FITSIO package is now available. 
FITSIO is a powerful yet simple to use Fortran subroutine interface for reading
and writing files in FITS format.  

This 3.21 version of FITSIO is 100% upwardly compatible with the previous 3.20
version and contains the following new features:

  NEW SUBROUTINES:
	- support for Lehey Fortran on IBM PCs
	- new more robust family of subroutines to read and write the required
          header keywords
	- 3 additional subroutines to make it easier to read or modify header 
          keywords

  ENHANCEMENTS:
	- improved documentation file
	- changed the way FITSIO handles arrays of ASCII strings to be 
	  compatible with the proposed binary table format
	- rewrote several of the previously machine-specific subroutines
	  in portable Fortran-77, to make it easier to port FITSIO to new
	  machines.
	- improved the functionality of several other subroutines

  BUG FIXES:
	- fixed 9 (relatively small) bugs in various FITSIO subroutines

For further details on these new features, see the 'release.doc' file
in the FITSIO distribution directory.

The FITSIO software, documentation, and example programs are available via
anonymous ftp from:

       ftp tetra.gsfc.nasa.gov   (128.183.8.77)

Then type the following:

        ftp>  user anonymous
        Password:               [type your username as a password]
        ftp>  cd pub/fitsio3    [to move to the version 3 subdirectory]
        ftp>  ls                [to see a list of the available files]
        ftp>  get read.me       [contains latest information about FITSIO]
        ftp>  get fitsio.doc    [complete user documentation]
        ftp>  get ...           [get any additional desired files]
        ftp>  quit

Alternatively, the FITSIO files may be copied from following SPAN/DECnet node:

   NDADSA::HEASARC:[EXOSAT.XANADU.FITS.FITSIO] 

--------------------------------------------------------------------------
Dr. William Pence                 (Internet)  pence at tetra.gsfc.nasa.gov
HEASARC                           (SPAN)      LHEAVX::PENCE
Code 668                          Telephone:  (301)286-4599
NASA/Goddard Space Flight Center
Greenbelt, MD 20771

From thompson at stars.gsfc.nasa.gov Tue Jul 14 14:42:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["5548" "Tue" "14" "July" "1992" "15:39:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "124" "Summary:  Storing long keywords in FITS files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
News-Software: VAX/VMS VNEWS 1.4-b1  
Nntp-Posting-Host: stars.gsfc.nasa.gov
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Summary:  Storing long keywords in FITS files
Date: Tue, 14 Jul 1992 15:39:00 GMT

A while back I had asked the following question

	Is there any kind of defacto way to store keywords longer than eight
	characters in a FITS header?  Someone suggested using the COMMENT
	keyword followed by the non-standard keyword, although another
	possibility is using the null keyword (eight blanks).  Is this what
	other people do?

	I'm not talking about keywords essential to reading and scientifically
	processing the data.  I'm more interested in storing engineering
	information about the state of the instrument.  It would be desirable
	to retain the original mnemonic names used by the engineers.  Important
	information could also be replicated using more standard FITS keywords.

	Although it's obviously legal to put anything in a COMMENT field, I'm
	interested in knowing what other people do.

I think that the problem of storing and manipulating keywords of greater than
eight characters in length is important for the future growth of FITS,
particularly if one wants to be able to move data back and forth between FITS
and other scientific file formats such as SFDU/PVL.

The functionality I was looking for was not simply to store the information,
but to be able to retrieve and manipulate that information as well.

Of the responses I got back, I was attracted to one in particular.  First,
because it is already in use at at least one major site, and second because it
seems to offer the kind of functionality and expandability I need.  That
response, from Eric Greisen at NRAO, is as follows:

	The solution we have used at NRAO (at it is even quietly present
	in the original FITS paper!) is to have HISTORY cards.  As the
	first word in the HISTORY we put an identifier that says that
	we have written the card, e.g. NRAO or AIPS.  Then we put one
	or more keyword=value pairs, with any old arbitrary choice of
	keywords.  Our FITS readers check each HISTORY card's next word
	and if it is one of a few magic ones they parse the rest of the
	card.  Otherwise, they ignore the card as non-NRAO readers are
	expected to do with all our cards as well.

I like this idea.  However, I think I would make the magic work something
unusual so that it wouldn't be confused with some ordinary text message.  For
instance, I think I would preface it with "K_" to represent special keyword.
Thus, I could have something like

	HISTORY K_SOHO MYSTRINGKEY = "This is a string" /Comment
	HISTORY K_SOHO MYINTEGERKEY = 3			/Another comment

I don't know if HAO does it or not, but I would even allow for FITS-like
comments, delimited by slashes, as shown above.  I wouldn't be picky about the
number of spaces between the various elements, or exactly which columns the
values occur in.  The only trouble I would anticipate would be with complex
values, because the FITS standard has the real and imaginary parts occuring in
specific columnar regions, which wouldn't be possible here.

A somewhat similar solution, from David Robinson, is shown below.  However, I'm
less attracted to it because it doesn't seem to be oriented toward recovering
and manipulating the data electronically.

	It seems clear to me that the keywords should be reserved for storing
	information that is essential for the processing of the data.
	Information that records how the data was generated (such as instrument
	settings, options given to the processing software etc.) should
	properly be stored in HISTORY records.

	For example, here is the FITS header for an output file from an image
	processing program that I have written:

	SIMPLE  =                    T
	BITPIX  =                  -32
	NAXIS   =                    2
	NAXIS1  =                  512
	NAXIS2  =                    1
	DATE    = '29/05/92'
	HISTORY Written by TOY3
	HISTORY set nrand 1
	HISTORY set tol 0.1
	HISTORY set background 5
	HISTORY set entropy standard
	HISTORY set image "line.dat"
	HISTORY set psf "psf1.dat"
	HISTORY var chisq 196.25
	HISTORY var iter 6
	HISTORY var sigma 2.78645
	HISTORY command write image "out.dat"
	END

	The HISTORY cards record the program used, the parameters given by the
	user (set..), the variables that the program found, (var...) and the
	command given to write out the file.

Simon Ellingsen writes:

	Instead of putting this type of none standard information in the
	header, why don't you use a binary extension table.  Then you
	effectively store the keywords in the TFORMn value which doesn't have
	the eight character restriction.

I agree, and intend to do just that when appropriate.  However, some data would
apply to the table as a whole, or to a primary FITS HDU.

A couple of people suggested converting the long keywords to an eight-character
equivalent, and then storing the real name in the comment.  Edward J. Groth
>from Princeton writes:

	How about

	KKKKKKKK=value  / Engineering keyword here

And Thierry Forveille of the Observatoire de Grenoble writes:

	Althought I never had to face that specific problem, I would suggest
	you store the information with a standard keyword and append the
	original mnemonic as an end of line comment (after the /). This is
	standard too, and the information will be easier to extract for a
	general FITS handling program if you later want to plot this
	engineering information. Extracting the information from a COMMENT or
	blank keyword would probably need ad hoc (though trivial) modifications
	of the program. Of course the standard keyword need not be particularly
	informative and something line ENGIN001 to ENGIN999 would work.

I thank everybody for their input.

Bill Thompson

From thompson at stars.gsfc.nasa.gov Tue Jul 14 16:12:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2663" "Tue" "14" "July" "1992" "17:57:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "53" "Variable length character string arrays." "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
News-Software: VAX/VMS VNEWS 1.4-b1  
Nntp-Posting-Host: stars.gsfc.nasa.gov
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Variable length character string arrays.
Date: Tue, 14 Jul 1992 17:57:00 GMT

A while back there was a bunch of discussion about devising a standard for
denoting the length of character strings in an array of character strings in a
binary table.  It started off when Bill Pence suggested using

				TFORMn = 'rAw'

where 'r' is the total number of characters in the array, and 'w' is the number
of characters in each character string element of the array.  However, it was
also pointed out (by Doug Tody?) that character strings could also be variable
length, delimited by a particular byte value.  I believe the suggestion for
that was

			       TFORMn = 'rA\ooo'

where 'ooo' was the octal representation of the delimiting byte.  I myself
suggested using separate keywords, TCLENn and TCDELn, to express either the
fixed length, or variable length delimiter.

I've been thinking some more about storing variable length strings in binary
tables.  I've convinced myself that two pieces of information have to be
supplied to allow all readers to be able to parse the information.  The first
piece, of course, is the value of the delimiter byte.  The second desirable
piece of information is the maximum length of the character string.  I have
worked with environments which could only handle string arrays where each
element of the array had the same string length as all the others (e.g. the
original VMS version of IDL).  While I don't currently work with anything that
has this limitation, I'm not sure we can guarantee that all environments won't
be so limited.  In such a situation, it would be an advantage to know a priori
the largest size the string element could obtain, so that the string array
could be properly initialized.  I think that this approach is similar to that
taken by the "Variable Length Array Facility" described in the binary tables
proposal, where the number of elements of the array is variable, but the
maximum possible number of elements is stored in the TFORM keyword.

Hence, the most desirable standard for delimiting the individual character
strings in a character string array would have the following characteristics:

	1.  It would work for both fixed-length and variable-length
	    (byte-delimited) character strings.

	2.  It would work for both direct (TFORM='rA') and pointer (TFORM='PA')
	    binary table columns.

	3.  For fixed-length strings, it would specify the character length.

	4.  For byte-delimited strings, it would specify both the byte code
	    used to delimit the strings, and a maximum length that the string
	    will not exceed.

A remaining question is whether this information is best appended to the TFORM
keyword, or stored in one or more separate keywords.

Bill Thompson

From stoll at ocf.berkeley.edu Wed Jul 15 06:43:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["635" "" "15" "July" "92" "04:01:03" "GMT" "Cliff Stoll" "stoll at ocf.berkeley.edu " nil "16" "minus signs in Fits keywords" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: U. C. Berkeley Open Computing Facility
NNTP-Posting-Host: headcrash.berkeley.edu
From: stoll at ocf.berkeley.edu (Cliff Stoll)
Subject: minus signs in Fits keywords
Date: 15 Jul 92 04:01:03 GMT

The Fits standard originally aimed at Fortran Namelist compatabilty
with header file keywords.  I don't think anyone's using
Fortran namelist utilities to read Fits header files, but it's
still an admirable goal.  It's also useful to map fits keywords 
directly onto program variables.

As written, however, Fits permits (and encourages) embedded minus
signs in keywords, for instance, MAX-RA.

Such keywords are incompatible with namelist reading and cannot
be mapped onto program variables in most languages.

This problem's been around for a while, but I trip over it every
couple years.  

-Cliff Stoll      stoll at ocf.berkeley.edu

From pence at heawk1.gsfc.nasa.gov Wed Jul 15 16:47:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1765" "Wed" "15" "July" "1992" "18:02:00" "GMT" " William Pence" "pence at heawk1.gsfc.nasa.gov " nil "42" "Re: Variable length character string arrays." "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Nntp-Posting-Host: heawk1.gsfc.nasa.gov
Organization: Goddard Space Flight Center
From: pence at heawk1.gsfc.nasa.gov ( William Pence)
Subject: Re: Variable length character string arrays.
Date: Wed, 15 Jul 1992 18:02:00 GMT

Here is how I would implement Bill Thompson's requirements for string arrays:

>Hence, the most desirable standard for delimiting the individual character
>strings in a character string array would have the following characteristics:
>
>	1.  It would work for both fixed-length and variable-length
>	    (byte-delimited) character strings.

TFORM1  = 'rAw'          / fixed length strings; r = total no. of characters
                         /    and w = length of each fixed-length string
TFORM1  = 'rA\ooo'       / byte delimited strings where 'ooo' is the octal byte

>	2.  It would work for both direct (TFORM='rA') and pointer (TFORM='PA')
>	    binary table columns.

TFORM1  = 'rAw'           / fixed length strings, direct
TFORM1  = 'rA\ooo'        / byte delimited strings, direct
TFORM1  = 'PAw(r)'        / fixed length strings, pointer
TFORM1  = 'PA\ooo(r)'     / byte delimited strings, pointer

>	3.  For fixed-length strings, it would specify the character length.

The 'w' integer field in all the above examples represents the fixed-length

>	4.  For byte-delimited strings, it would specify both the byte code
>	    used to delimit the strings, and a maximum length that the string
>	    will not exceed.

The integer 'r' field in all the above cases is the maximum length of a
delimited string.  In general, a single string could fill the entire field

>A remaining question is whether this information is best appended to the TFORM
>keyword, or stored in one or more separate keywords.

I strongly believe all this information should be encoded into the
single TFORM keyword.  Otherwise, FITS readers/writers have to be
made more complicatd to handle the extra keywords, which are not needed
for columns with any other datatype.

-Bill Pence

From thompson at stars.gsfc.nasa.gov Thu Jul 16 06:58:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2184" "" "15" "July" "92" "21:24:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "49" "Re: Variable length character string arrays." "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1
Nntp-Posting-Host: stars.gsfc.nasa.gov
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Re: Variable length character string arrays.
Date: 15 Jul 92 21:24:00 GMT

In article <pence.711223320 at heawk1>, pence at heawk1.gsfc.nasa.gov ( William Pence) writes...
> 
>Here is how I would implement Bill Thompson's requirements for string arrays:
> 
		(stuff deleted)

>>	4.  For byte-delimited strings, it would specify both the byte code
>>	    used to delimit the strings, and a maximum length that the string
>>	    will not exceed.
> 
>The integer 'r' field in all the above cases is the maximum length of a
>delimited string.  In general, a single string could fill the entire field

If one has

>	TFORM1  = 'rA\ooo'        / byte delimited strings, direct
>	TFORM1  = 'PA\ooo(r)'     / byte delimited strings, pointer

and I want to read this into a string array, then I don't know how many string
elements to assign to the array, nor do I know many characters to allocate for
each string, if my environment required me to do it.  The extremes are that
there could be as many as r/2 strings of one character each (if r is even), or
one string with r characters.  The most conservative approach would be to
allocate an array of r/2 elements, each of which with r characters, leading
to a total of r^2/2 characters for the resulting array, which is ridiculous.

I guess that I don't just want to know how big the string can get; I also want
to know how many strings there are.  Note that this is not a problem with the
simpler approach

>	TFORM1  = 'rAw'           / fixed length strings, direct
>	TFORM1  = 'PAw(r)'        / fixed length strings, pointer

For my own part, it's this kind of string I would most expect to store in FITS
files.  It's worth thinking about variable length strings, though.

Finally,

>I strongly believe all this information should be encoded into the
>single TFORM keyword.  Otherwise, FITS readers/writers have to be
>made more complicatd to handle the extra keywords, which are not needed
>for columns with any other datatype.

The philosophy behind the TFORM keyword seems to be to define things at an
atomic level.  The question then comes up: is one atom of character string data
a string or a character?  From a user's point of view, it should be the former,
but the answer may be software sensitive.

Bill Thompson

From thompson at stars.gsfc.nasa.gov Thu Jul 16 06:58:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["909" "" "15" "July" "92" "20:57:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "22" "Re: minus signs in Fits keywords" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1
Nntp-Posting-Host: stars.gsfc.nasa.gov
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Re: minus signs in Fits keywords
Date: 15 Jul 92 20:57:00 GMT

In article <1407tvINNje9 at agate.berkeley.edu>, stoll at ocf.berkeley.edu (Cliff Stoll) writes...
>The Fits standard originally aimed at Fortran Namelist compatabilty
>with header file keywords.  I don't think anyone's using
>Fortran namelist utilities to read Fits header files, but it's
>still an admirable goal.  It's also useful to map fits keywords 
>directly onto program variables.
> 
>As written, however, Fits permits (and encourages) embedded minus
>signs in keywords, for instance, MAX-RA.
> 
>Such keywords are incompatible with namelist reading and cannot
>be mapped onto program variables in most languages.
> 
>This problem's been around for a while, but I trip over it every
>couple years.  
> 
>-Cliff Stoll      stoll at ocf.berkeley.edu

For similar reasons, I'm recommending to the SOHO project that all keywords not
use embedded minus sign characters, but use underscores instead.

Bill Thompson

From bschlesinger at nssdca.gsfc.nasa.gov Thu Jul 16 20:23:08 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1742" "" "16" "July" "92" "21:33:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "43" "Re: minus signs in Fits keywords" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: NASA - Goddard Space Flight Center
News-Software: VAX/VMS VNEWS 1.41
Nntp-Posting-Host: nssdca.gsfc.nasa.gov
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Subject: Re: minus signs in Fits keywords
Date: 16 Jul 92 21:33:00 GMT

In article <15JUL199216574340 at stars.gsfc.nasa.gov>,
thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
writes... 
>In article <1407tvINNje9 at agate.berkeley.edu>, stoll at ocf.berkeley.edu
(Cliff Stoll) writes... 
>>The Fits standard originally aimed at Fortran Namelist compatabilty
>>with header file keywords.  I don't think anyone's using
>>Fortran namelist utilities to read Fits header files, but it's
>>still an admirable goal.  It's also useful to map fits keywords 
>>directly onto program variables.
>> 
>>As written, however, Fits permits (and encourages) embedded minus
>>signs in keywords, for instance, MAX-RA.

In FITS Paper I (A&A 1981, 44,363) the reserved and recommended
DATE-OBS keyword uses the hyphen (ASCII hexadecimal 2D).  Because, "we
are not permitted to alter the basic format in such a way as to make
existing FITS tapes invalid" (Paper III, A&A 1988, 73, p. 360, section
4) and the hyphen appears on many FITS data sets that use Paper I as a
model, its use cannot be forbidden now. 

I wouldn't say that future use is necessarily being encouraged.  A
straw in the wind is the ASCII Tables paper (A&A 1988 73,359)
recommendation that only letters (upper case) numbers, and underscore
be used for values of the TTYPEn keywords. 

>> 
>>Such keywords are incompatible with namelist reading and cannot
>>be mapped onto program variables in most languages.
>> 
>>This problem's been around for a while, but I trip over it every
>>couple years.  

> 
>For similar reasons, I'm recommending to the SOHO project that all keywords not
>use embedded minus sign characters, but use underscores instead.
> 

I would endorse this approach for user-defined keywords.

				Barry Schlesinger
				FITS Support Office

From zarate at scivax.stsci.edu Fri Jul 17 13:40:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1504" "Fri" "17" "July" "1992" "17:13:58" "GMT" "zarate at scivax.stsci.edu" "zarate at scivax.stsci.edu" nil "54" "TNULL's in TABLEs." "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Organization: Space Telescope Science Institute
Distribution: na
From: zarate at scivax.stsci.edu
Subject: TNULL's in TABLEs.
Date: Fri, 17 Jul 1992 17:13:58 GMT

Hello 

	I would like to ask the opinion of those who have written FITS
programs with TABLE extension, or have good idea what is the interpretation 
of the FITS NOST document when dealing with null strings on overlapping
fields.

	For example: A FITS TABLE descriptors for columns 6,7,8 are:

TTYPE6  = 'Class   '
TBCOL6  =                   54
TFORM6  = 'A5      '
TNULL6  = '*       '

TTYPE7  = 'Type    '
TBCOL7  =                   54
TFORM7  = 'A1      '
TNULL7  = '*       '

TTYPE8  = 'Class_No'
TBCOL8  =                   55
TFORM8  = 'I4      '
TNULL8  = '        '

	The FITS table data in one of the lines that have a null value
is:

	....... *  32

where the '*' is at column 54.

	My thougths about this are as follows:

     1)	The column 6 descriptor specified a width of 5 characters; so the
	data entry for the column is null, right?

     2) The column 7 descriptor specified a width of 1 character; so the
	data entry for the column is null, right?

     3) The column 8 descriptor specified a width of 4 character; so the
	data entry for the column is 32.

	If the above is correct, that this means that a correct null entry
for a 'A5' format is '* &+(' or it has to be '*    '; because '32' is
garbage for the column 6 specification since the fields overlap.
The NOST document in 8.1.2 says "TNULLn Keywords. ....The string is
implicitly blank filled to the width of the field".

Thank you
Nelson Zarate  (nelson at stsci.edu)
Space Telescoope Science Institute
Baltimore MD 21218 

From leb at Hypatia.gsfc.nasa.gov Sat Jul 18 21:23:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2556" "Sat" "18" "July" "1992" "20:22:45" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "77" "Re: TNULL's in TABLEs." "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Nntp-Posting-Host: hypatia.gsfc.nasa.gov
Organization: Goddard Space Flight Center
Distribution: na
From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Subject: Re: TNULL's in TABLEs.
Date: Sat, 18 Jul 1992 20:22:45 GMT

zarate at scivax.stsci.edu writes:
>	For example: A FITS TABLE descriptors for columns 6,7,8 are:
>
>TTYPE6  = 'Class   '
>TBCOL6  =                   54
>TFORM6  = 'A5      '
>TNULL6  = '*       '
>
>TTYPE7  = 'Type    '
>TBCOL7  =                   54
>TFORM7  = 'A1      '
>TNULL7  = '*       '
>
>TTYPE8  = 'Class_No'
>TBCOL8  =                   55
>TFORM8  = 'I4      '
>TNULL8  = '        '
>
>	The FITS table data in one of the lines that have a null value
>is:
>
>	....... *  32
>
>where the '*' is at column 54.
>
>	My thougths about this are as follows:
>
>     1) The column 6 descriptor specified a width of 5 characters; so the
>	data entry for the column is null, right?

Wrong.  The NULL value given for field Class is "*    ", the given field is
"*  32" which doesn't match.

>     2) The column 7 descriptor specified a width of 1 character; so the
>	data entry for the column is null, right?

Right.  This field matches it's (one character) null value specification.

>     3) The column 8 descriptor specified a width of 4 character; so the
>	data entry for the column is 32.

Right.  This field has a valid data value.  The null value for field Class_No
is "    " (exactly four blank characters).

>	If the above is correct, that this means that a correct null entry
>for a 'A5' format is '* &+(' or it has to be '*    '; because '32' is
>garbage for the column 6 specification since the fields overlap.
>The NOST document in 8.1.2 says "TNULLn Keywords. ....The string is
>implicitly blank filled to the width of the field".

Personally I think that this is a case of an error in the table data (although
I can't be sure, since the example is taken out of context).  If the Class Type
is NULL, then it seems to me that there shouldn't be a Class Number.  Also, I
think that the header is ill-formed (God, I hope that it isn't one of *my* 
headers from the ADC CD-ROM :-).  Overlapping fields, while legal, can be 
confusing as this case shows.  I think that this table would be better 
specified as:

TTYPE6  = 'Class_Type'
TBCOL6  =                   54
TFORM6  = 'A1      '
TNULL6  = '*       '

TTYPE7  = 'Class_No'
TBCOL7  =                   55
TFORM7  = 'I4      '
TNULL7  = '        '

>Thank you
>Nelson Zarate  (nelson at stsci.edu)
>Space Telescoope Science Institute
>Baltimore MD 21218 
--
-- Lee E. Brotzman                    Internet:  leb at hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB at GIBBS
-- NASA Goddard Space Flight Center

From bschlesinger at nssdca.gsfc.nasa.gov Mon Jul 20 17:42:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1260" "Mon" "20" "July" "1992" "21:40:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "29" "FITS error test files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
News-Software: VAX/VMS VNEWS 1.41    
Keywords: FITS, software, readers 
Nntp-Posting-Host: nssdca.gsfc.nasa.gov
Organization: NASA - Goddard Space Flight Center
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Subject: FITS error test files
Date: Mon, 20 Jul 1992 21:40:00 GMT

	In response to the requests at the Columbus meeting of the
WGAS, a number of "FITS" files originally created to test the NOST
FITS Product Conformance Tester (FPCT) are now available.  These files
provide an opportunity to test the ability of FITS readers to cope
with errors in primary headers of the input files. All the files
except one are variations on a theme; they are the same except that
different kinds of errors have been introduced.  Some types of errors
included are improper keyword order, incorrect card image syntax, and
incorrect values.  The remaining file is designed to test the response
of software to a file that doesn't even resemble FITS, as might occur
if the software were used by mistake on the wrong file. 

	These files are available from nssdca.gsfc.nasa.gov by anonymous
ftp or by DECnet copy from NSSDCA. They are in the FITS directory,
ERRTEST subdirectory.  NSSDCA is a VAX; case is not significant.  The
README.FIRST file describes the others in more detail. 

	Answers to any questions, and copies of the prototype FPCT
itself, can be obtained from the FITS Support Office: 

	Internet: fits at nssdca.gsfc.nasa.gov
	DECnet NCF::FITS
	Telephone: (301)513-1634 

				Barry Schlesinger
				Coordinator
				FITS Support Office

From bhill at stars.gsfc.nasa.gov Mon Jul 20 17:43:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["657" "Mon" "20" "July" "1992" "21:52:00" "GMT" "Robert S. Hill" "bhill at stars.gsfc.nasa.gov " nil "12" "Re: FITS error test files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
News-Software: VAX/VMS VNEWS 1.4-b1  
Keywords: FITS, software, readers
Nntp-Posting-Host: stars.gsfc.nasa.gov
Organization: Hughes STX Corp./NASA Goddard Space Flight Center
From: bhill at stars.gsfc.nasa.gov (Robert S. Hill)
Subject: Re: FITS error test files
Date: Mon, 20 Jul 1992 21:52:00 GMT

In article <20JUL199216405756 at nssdca.gsfc.nasa.gov>, 
bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger) writes...
>	In response to the requests at the Columbus meeting of the
>WGAS, a number of "FITS" files originally created to test the NOST
>FITS Product Conformance Tester (FPCT) are now available.  These files

Inquiring minds want to know:  is the FPCT itself available?

------------------------------------------------------------------------
Robert S. Hill                  | Internet:  BHILL at STARS.GSFC.NASA.GOV
Hughes STX Corp.                | Phone:     301/286-3624
------------------------------------------------------------------------

From bschlesinger at nssdca.gsfc.nasa.gov Mon Jul 20 17:43:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["6422" "Mon" "20" "July" "1992" "21:46:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "131" "FITS basics and information (periodic posting)" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
News-Software: VAX/VMS VNEWS 1.41    
Nntp-Posting-Host: nssdca.gsfc.nasa.gov
Organization: NASA - Goddard Space Flight Center
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Subject: FITS basics and information (periodic posting)
Date: Mon, 20 Jul 1992 21:46:00 GMT

	This basic FITS information is posted and updated periodically
for the benefit of new readers and the reference of old readers. 

	FITS (Flexible Image Transport System) is a data format
designed to allow convenient exchange of astronomical data between
installations whose standard internal formats and hardware differ. A
FITS file is composed of a sequence of Header Data Units (HDUs). The
header consists of keyword=value statements, which describe the format
and organization of the data in the HDU and may contain other
information such as information about the instrument or the history of
the data or data set.  The data follow, structured as the header
specifies. The data section of the HDU may contain a digital image,
but, except for the first, IT DOESN'T HAVE TO.  Other possible formats
include tables and multidimensional matrices that are not images. The
first HDU must contain a multidimensional matrix or no data at all;
the data in subsequent HDUs, called extensions, may be of any type,
consistent with certain rules.  The "Image" in the name comes from the
original use of the format to transport digital images, but it's not
just for images any more. 

 	FITS is not principally a graphics format designed for the
transfer of pictures with standard support for many platforms included
as part of the package for decoding the image. Separate software must
be developed or obtained for converting the data from the FITS file
into a form that can be readily displayed.  As has been discussed in
this newsgroup, and in alt.sci.astro.fits before it, the Extended
Portable Bitmap Toolkit (pbm+) can be used for converting many FITS
files to such a format, but support for all FITS files where the data
are in the form of an image, in particular those where the data matrix
members are in IEEE floating point format (BITPIX<0) or the matrix has
more than two dimensions (NAXIS>2), is not guaranteed. Discussion of
FITS - image converters appears in this newsgroup from time to time. 

	The fundamental references on FITS are the following four
papers, often referred to collectively as the "Four FITS Papers". 
These papers are the formal standard for FITS, endorsed by the
International Astronomical Union (IAU). 

Wells, D. C., Greisen, E. W., and Harten, R. H., "FITS: a flexible 
image transport system," Astronomy and Astrophysics Supplement Series, 
44,  363-370, 1981. 

Greisen, E. W. and Harten, R. H., "An extension of FITS for small 
arrays of data," Astronomy and Astrophysics Supplement Series, 44, 
371-374, 1981. 
(NOTE: The format described in this paper has been used almost 
exclusively to transport radio interferometry and is likely to be 
replaced by other formats in the future.  Writing data other than 
radio interferometry data using this format is not recommended.)   

Grosbol, P., Harten, R. H., Greisen, E. W., and Wells, D. C., 
"Generalized extensions and blocking factors for FITS," Astronomy and 
Astrophysics Supplement Series, 73, 359-364, 1988. 

Harten, R. H., Grosbol. P., Greisen, E. W., and Wells, D. C., "The 
FITS tables extension, Astronomy and Astrophysics Supplement Series, 
73, 365-372, 1988. 

	 A User's Guide for FITS, commissioned by NASA Headquarters,
is maintained by the NASA/OSSA Office of Standards and Technology
(NOST).  This Guide is intended to be a tutorial for new FITS users. 
In addition to presenting the rules of FITS, it provides some of the
history and reasoning behind the choice of the rules, adds
recommendations on good practices, and discusses current developments
in FITS.  This document is available only in hard copy form. 

	NASA is sponsoring development of a formal standard for FITS.
The goal of this process is a document consistent with FITS as
endorsed by the IAU, eliminating some contradictions and ambiguities
in the original FITS papers, that can be endorsed by the IAU FITS
Working Group as the FITS standard.  The document is being developed
by a Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with
review by the astronomical community.  Only minor revisions are
expected to the current draft, version 0.3b, but the form of the
standard is not final, and it does not supersede the four papers and
Floating Point Agreement endorsed by the IAU as the official standard
for FITS. 

	The IAU has endorsed the Floating Point Agreement, which
defines how floating point numbers are to be stored in the data
matrix defined in the first of the four papers.  The basic agreement
appears verbatim in the User's Guide, and the substance is
incorporated in the Draft NASA Standard. 

	The NOST maintains a file of FITS information available by
anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in
the directory FITS. It includes copies of the current draft NASA
Standard in flat ASCII, PostScript, and LaTeX.  Style and index files
are provided for the LaTeX form.  A current list of the extension type
(structure) names registered with the IAU FITS Working Group is
maintained.  Also available, in LaTeX form, is the text of the
proposal for one of these new extension types, IMAGE.  A README. file
describes the contents of the directory.  A SOFTWARE subdirectory,
described by an included README.FIRST file, contains a program in C to
read and list the headers of a FITS file and another file with
information on publicly available FITS software packages. The ERRTEST
subdirectory contains several versions of the same FITS file, a valid one and
several with different kinds of header errors, for use in testing
software to read FITS files.  An included README.FIRST file contains
details. 

	Paper copies of many of the documents listed above can be
obtained from the NOST Librarian. Paper copies of the User's Guide and
either paper or electronic copies of the Draft Implementation
Standard, for those without ftp access, are available.  Because of
restrictions set by the copyright holder, NOST can send copies of the
four FITS papers only to non-profit organizations.  The addresses of
the NOST are as follows: 

  (Postal) NASA/OSSA Office of Standards and Technology
	Code 933
	Goddard Space Flight Center
	Greenbelt MD 20771
	USA

(Internet) nost at nssdca.gsfc.nasa.gov
(DECnet) NCF::NOST

	Please mention this posting in your request.

					Barry M. Schlesinger
					Coordinator,
					NASA/NSSDC
					NOST FITS Support Office
		
(301) 513-1634				fits at nssdca.gsfc.nasa.gov
					NCF::FITS

From bschlesinger at nssdca.gsfc.nasa.gov Tue Jul 21 17:31:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["425" "" "21" "July" "92" "19:04:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "15" "Re: FITS error test files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Summary: Test prototype only
Keywords: FPCT
Organization: NASA - Goddard Space Flight Center
News-Software: VAX/VMS VNEWS 1.41
Nntp-Posting-Host: nssdca.gsfc.nasa.gov
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Subject: Re: FITS error test files
Date: 21 Jul 92 19:04:00 GMT

In article <20JUL199216523472 at stars.gsfc.nasa.gov>, bhill at stars.gsfc.nasa.gov (Robert S. Hill) writes...
> 
>Inquiring minds want to know:  is the FPCT itself available?
> 

	A prototype of the first build is available for testing, to check for 
portability and errors.  The first build is limited to 

	Primary HDU
	Integer data
	Twos complement

	Copies can be obtained from the FITS Support Office

					Barry Schlesinger

From pence at heawk1.gsfc.nasa.gov Wed Jul 22 16:14:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2006" "" "22" "July" "92" "17:36:45" "GMT" " William Pence" "pence at heawk1.gsfc.nasa.gov " nil "74" "Re: FITS error test files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Keywords: FITS, software, readers
Organization: Goddard Space Flight Center
Nntp-Posting-Host: heawk1.gsfc.nasa.gov
From: pence at heawk1.gsfc.nasa.gov ( William Pence)
Subject: Re: FITS error test files
Date: 22 Jul 92 17:36:45 GMT

I tried reading the test defective FITS files  generated by Barry
Schlesinger (see previous post to this newsgroup) to see if the FITSIO
subroutine package detected the errors.   I tried reading each pseudo
FITS file with a simple program that just lists the header of a FITS
file.  The following list shows the error message that was returned by
FITSIO for each file.   FITSIO did very well and found all the errors,
except one:  it didn't complain if the first keyword was 'SIMPLE =
W';  it just assumed that if SIMPLE was not true, then it must be false.
I'll add this check to the next version of FITSIO.

-Bill Pence
--------------------------------------------------------------------------

List of error responses generated by FITSIO when trying to read test defective
FITS files generated by Barry Schlesinger

FILENAME       FITSIO RESPONSE
--------       ---------------
good.tst
        No errors detected; OK since this is a legal FITS file

different.tst:
	Error Status Returned :  210
	Missing "= " in cols 9-10

nosimple.tst
	Error Status Returned :  221
	SIMPLE keyword not found

simplew.tst
        No errors detected;  didn't detect SIMPLE = W;  FITSIO should
        have complained about this.

simplef.tst
        No errors detected;  didn't complain about SIMPLE = F; OK

bitpixq2
	Error Status Returned :  211
	Illegal BITPIX keyword value

bitpix13
	Error Status Returned :  211
	Illegal BITPIX keyword value

noequal.tst
	Error Status Returned :  210
	Missing "= " in cols 9-10

qin10.tst
	Error Status Returned :  210
	Missing "= " in cols 9-10

extraxis.tst
	No errors detected;  OK since this is a legal FITS file

missaxis.tst
	Error Status Returned :  224
	NAXISnnn keywords not found

simple2nd.tst
	Error Status Returned :  210
	Missing "= " in cols 9-10

shuffle.tst
	Error Status Returned :  222
	BITPIX keyword not found

latenaxis.tst
	Error Status Returned :  223
	NAXIS  keyword not found

endequal.tst
	No errors detected;  OK since this is a legal FITS file (?).

From bschlesinger at nssdca.gsfc.nasa.gov Thu Jul 23 11:59:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1928" "" "23" "July" "92" "13:59:00" "GMT" "Barry Schlesinger" "bschlesinger at nssdca.gsfc.nasa.gov " nil "56" "Re: FITS error test files" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Keywords: FITS, software, readers
Organization: NASA - Goddard Space Flight Center
News-Software: VAX/VMS VNEWS 1.41
Nntp-Posting-Host: nssdca.gsfc.nasa.gov
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Subject: Re: FITS error test files
Date: 23 Jul 92 13:59:00 GMT

In article <pence.711826605 at heawk1>, pence at heawk1.gsfc.nasa.gov ( William Pence) writes...
> 
>I tried reading the test defective FITS files  generated by Barry
>Schlesinger (see previous post to this newsgroup) to see if the FITSIO
>subroutine package detected the errors.  I tried reading each pseudo
>FITS file with a simple program that just lists the header of a FITS
>file.  The following list shows the error message that was returned by
>FITSIO for each file.   FITSIO did very well and found all the errors,
>except one:  it didn't complain if the first keyword was 'SIMPLE =
>W';  it just assumed that if SIMPLE was not true, then it must be false.
>I'll add this check to the next version of FITSIO.
> 
>-Bill Pence
>--------------------------------------------------------------------------
> 
>List of error responses generated by FITSIO when trying to read test defective
>FITS files generated by Barry Schlesinger
> 
>FILENAME       FITSIO RESPONSE
>--------       ---------------
>good.tst
>        No errors detected; OK since this is a legal FITS file
> 
>different.tst:
>	Error Status Returned :  210
>	Missing "= " in cols 9-10
> 

This is something of an understatement, as the file isn't close to 
FITS.

> ... [results for other files] ...
.
>shuffle.tst
>	Error Status Returned :  222
>	BITPIX keyword not found

Actually there is a BITPIX keyword in the file, just in the wrong 
place.  But a reader shouldn't be expected to find it.

>latenaxis.tst
>	Error Status Returned :  223
>	NAXIS  keyword not found 

As above.

>endequal.tst
>	No errors detected;  OK since this is a legal FITS file (?).

Not exactly.  The = in column 9 of the END card image shouldn't be
there.  Readers probably should provide a warning.  Validation
software certainly should.  As is noted in the README.FIRST, Don Wells
reports that some readers have crashed on this syntax. 

				Barry Schlesinger
				FITS Support Office

From teuben at lynx.astro.umd.edu Tue Jul 28 14:14:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1250" "" "28" "July" "92" "15:27:13" "GMT" "Peter Teuben" "teuben at lynx.astro.umd.edu " nil "28" "BSCALE/BZERO" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Distribution: sci
Organization: University of Maryland, Astronomy Department
From: teuben at lynx.astro.umd.edu (Peter Teuben)
Subject: BSCALE/BZERO
Date: 28 Jul 92 15:27:13 GMT

The NOST fits panel report states that for BITPIX < 0 (i.e. when
the data is stored in IEEE floating point format) the usage of
BSCALE and BZERO not recommended. We never (wanted to) forbid 
or explicitly state that it should or should not be applied
in section 6.3 (though section 5.2.2.5 does state this).

The FITS users guide (also published by NOST) does explicitly
states that BSCALE and BZERO  be applied in the BITPIX<0 case, with
the danger of producing overflows/underflows of course (hence the 
reason that BSCALE and BZERO should not be present).

I've indeed noted that the AIPS and MIRIAD readers 'correctly' apply
BSCALE and BZERO in the floating point cases, but the problem arose
when we imported a FITS file generated by IDL. The idl procedure
'WRITEFITS' seems to write images with BSCALE not 1.0, which has
caused some readers to read in the wrong datavalues.
Perhaps Wayne Landsman can comment on this.

Has anybody seen fits readers which skip BSCALE and BZERO if BITPIX < 0?

	Peter

--
Peter J. Teuben         |  INTERNET  : teuben at astro.umd.edu
Astronomy Department    |  FAX:        (301) 314-9067
University of Maryland  |  MA-BELL   : (301) 405-1540 (office)
College Park, MD 20742  |              (301) 405-1502 (secr.)

From thompson at stars.gsfc.nasa.gov Wed Jul 29 14:59:40 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2238" "" "29" "July" "92" "18:36:00" "GMT" "William Thompson, code 682.1, x2040" "thompson at stars.gsfc.nasa.gov " nil "43" "Re: BSCALE/BZERO" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Distribution: sci
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1
Nntp-Posting-Host: stars.gsfc.nasa.gov
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: Re: BSCALE/BZERO
Date: 29 Jul 92 18:36:00 GMT

In article <TEUBEN.92Jul28112713 at lynx.astro.umd.edu>, teuben at lynx.astro.umd.edu
(Peter Teuben) writes...
> 
>The NOST fits panel report states that for BITPIX < 0 (i.e. when
>the data is stored in IEEE floating point format) the usage of
>BSCALE and BZERO not recommended. We never (wanted to) forbid 
>or explicitly state that it should or should not be applied
>in section 6.3 (though section 5.2.2.5 does state this).
> 
>The FITS users guide (also published by NOST) does explicitly
>states that BSCALE and BZERO  be applied in the BITPIX<0 case, with
>the danger of producing overflows/underflows of course (hence the 
>reason that BSCALE and BZERO should not be present).
> 
>I've indeed noted that the AIPS and MIRIAD readers 'correctly' apply
>BSCALE and BZERO in the floating point cases, but the problem arose
>when we imported a FITS file generated by IDL. The idl procedure
>'WRITEFITS' seems to write images with BSCALE not 1.0, which has
>caused some readers to read in the wrong datavalues.
>Perhaps Wayne Landsman can comment on this.
> 
>Has anybody seen fits readers which skip BSCALE and BZERO if BITPIX < 0?

I don't want to talk for Wayne Landsman as to what the IDL routines do or don't
do when writing FITS files.  I do want to address the issue inherent in the
last question, though.

I believe that there is a valid usage for BSCALE and BZERO when applied to
floating point data.  Most people probably think of these variables as just a
way of packing floating point numbers into integer arrays.  However, the FITS
documentation simply states that these parameters are used to convert array
values into scientifically useful physical values.  Thus, another possible use
of BSCALE and BZERO is to convert raw detector values into calibrated values.
Thus, both levels of information are retained, and changing the calibration at
a later date is fairly trivial.

The IDL FITS reader routines do, by default, apply the BSCALE and BZERO
parameters to the data.  This occurs for both integer and floating point
arrays.  However, this behavior can be overridden by including the /NOSCALE
keyword.  That way, the user can also access the "raw" data.  It doesn't matter
whether or not BITPIX is > 0 or < 0.

Bill Thompson

From hyatt at tsc.cs.unc.edu Fri Jul 31 09:01:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["135" "" "30" "July" "92" "21:42:29" "GMT" "Brant Hyatt" "hyatt at tsc.cs.unc.edu " nil "8" "FITS->gif,jpg,tiff etc" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
Keywords: FITS gif jpg
From: hyatt at tsc.cs.unc.edu (Brant Hyatt)
Subject: FITS->gif,jpg,tiff etc
Date: 30 Jul 92 21:42:29 GMT

Does anyone know of or have written a utility that converts
fits to any other format?

Thanks,

Brant Hyatt
brant at sloth.astro.unc.edu

From pmurphy at nrao.edu Fri Jul 31 09:02:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1535" "Fri" "31" "July" "1992" "03:25:02" "GMT" "Pat Murphy" "pmurphy at nrao.edu " nil "32" "Re: FITS->gif,jpg,tiff etc" "^From:" nil nil "7"])
Newsgroups: sci.astro.fits
In-Reply-To: hyatt at tsc.cs.unc.edu's message of 30 Jul 92 21: 42:29 GMT
Organization: National Radio Astronomy Observatory
From: pmurphy at nrao.edu (Pat Murphy)
Subject: Re: FITS->gif,jpg,tiff etc
Date: Fri, 31 Jul 1992 03:25:02 GMT

In article <14259 at borg.cs.unc.edu> hyatt at tsc.cs.unc.edu (Brant Hyatt) writes:

> Does anyone know of or have written a utility that converts
> fits to any other format?

The pbmplus package that we have installed here (Dec 91 vintage I
believe) has fitstopgm, and once there you can use the pgm utilities
to convert it to just about whatever you want.  A quick run of archie
shows that pbmplus is available on ftp.uu.net:

    Location: /usenet/comp.sources.misc/volume26/pbmplus
       Directory drwxr-xr-x 00000512 1991 Dec 14 00:00:00 GMT pbmplus

I'm sure it's available elsewhere.  I don't keep track of the
comp.sources.misc newsgroup so I don't know if this is the latest
version or not.  

That said, I should say that it is NOT a sophisticated fits reader.
It knows about SIMPLE, BITPIX, NAXIS, NAXISn (n up to 3), DATAMIN,
DATAMAX, BZERO and BSCALE (but may not use them) and END.  That's it.
I have extracted the source for this from our pbmplus installation;
email me if you want it.

				- Pat
--
==========================================================================
| Patrick P. Murphy, Ph.D.                Scientific Programming Analyst |
| National Radio Astronomy Observatory    Net:   pmurphy at nrao.edu        |
| 520 Edgemont Road                       or:    uunet!nrao.edu!pmurphy  |
| Charlottesville, VA 22903-2475          Phone: (804) 296-0372          |
|      "I don't believe in the no-win scenario"  --- James T. Kirk       |
==========================================================================