From fitsbits-request  Sun Aug  1 22:20:18 1993
X-VM-VHeader: ("From:" "Sender:" "Resent-From" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:" "Resent-Date:") nil
X-VM-Bookmark: 43
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA25357; Sun, 1 Aug 93 22:20:18 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Aug1222002 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
From: dwells at fits.CV.NRAO.EDU (Don Wells)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: the "archival" issue
Date: Mon, 2 Aug 1993 03:20:02 GMT

The appended posting by Archie Warnock appeared in newsgroup
sci.data.formats two days ago.  I am reposting it to sci.astro.fits
because I suspect that many s.a.f. subscribers do not read s.d.f. and
because I agree with what Archie says here about design considerations
for archival-quality data formats. Glossary: HDF = Hierarchical Data
Format (developed by NCSA at UIUC), API = Application Programming
Interface, CDF = Common Data Format (developed at NASA-GSFC), EOS =
Earth Observation Systems (the "Mission to Planet Earth" project at
GSFC, which has chosen HDF as its archival format).  -Don
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Newsgroups: sci.data.formats
Subject: Re: HDF as an archive format
Date: 30 Jul 93 14:30:30 GMT
Organization: NASA Goddard Space Flight Center -- InterNetNews site

mike at jpl-devvax.jpl.nasa.gov (Mike Tankenson) writes:
>1) Is there something inherent about HDF that would prevent its use as an
>archive format?

Depends on how serious you are about archiving.  The fundamental
question to ask is how will a user, some 20 or 30 years in the future,
upon finding a file in HDF format, access the data.

In my opinion, formats which are defined _solely_ by software toolboxes
and APIs are extremely dangerous for archival storage.  We have no way
of assuring future generations of users that the software will be
usable.  The questions to ask about archival storage are:

1.  Where is the byte-by-byte description of the format given?  In an
internationally recognized standards document?  In the refereed
literature?  In a private publication by some individual institution?
In source code?  Which is most likely to be accessible 50 years from
now?

2.  Is the format self-documenting?  Is the metadata in (at least)
ASCII?  Can the user determine anything about the contents of the data
from a simple dump?

3.  Is the format well-defined?  Can a user assume that versions are
backward compatible?

There are (at least) three different applications for data formats -
interchange, access and archival storage.  It is not at all obvious that
any single format can meet the needs of all 3 simultaneously, even less
obvious that any single format currently _does_ meet the needs of all 3.

In general, working formats need to emphasize access (read/write)
efficiency.  Interchange formats need storage efficiency and
standardized numeric representations.  Archival formats need to be
self-documenting, externally documented and simple.

Things like HDF, netCDF and CDF are good working formats but are risky
as archival formats (at least, I've never seen references to format
descriptions in the refereed literature - I hope I'm wrong, cause
otherwise EOSDIS is gonna be in a lot of trouble years from now).  FITS
and PDS are pretty good interchange and archival formats, but weak
working formats.

It's an important area for discussion...

--
_______________________________________________________________________
-- Archie Warnock              Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                  "Unix --- JCL For The 90s"
-- NASA/GSFC                   Project STELAR: WAIS to do science
--

  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 fitsbits-request  Mon Aug  2 07:36:27 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["984" "Mon" "2" "August" "1993" "12:31:42" "+0100" "Clive Page, Leicester University, UK" "cgp%ltvad.dnet at star-gw.rl.ac.uk " nil "18" "Underscores vs hyphens in FITS column names" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA26455; Mon, 2 Aug 93 07:36:27 EDT
Return-Path: <cgp%ltvad.dnet at star-gw.rl.ac.uk>
Message-Id: <9308021131.AA02875 at star-gw.rl.ac.uk>
From: cgp%ltvad.dnet at star-gw.rl.ac.uk (Clive Page, Leicester University, UK)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: "fitsbits at fits.cv.nrao.edu"%RLSGW.dnet at star-gw.rl.ac.uk
Subject: Underscores vs hyphens in FITS column names
Date: Mon, 2 Aug 1993 12:31:42 +0100

I'd like to support the recent posting by Bill Pence recommending that
underscores be used in place of hyphens in FITS keyword names where 
possible.  Apart from the reasons cited, the problems of parsing an
expression involving FITS keyword names should be considered; one might
want to do this when using utilities such as FTOOLS to compute a new
column or select a given set of rows.  In such cases the selection
expression might include FITS keyword names as "variable names".  If
some of these names contain hyphens (which are just like minus signs)
parsing the expression is much harder, which means the syntax rules
forced on the user are bound to be more complex. 

We are, of course, stuck with some names like DATE-OBS for historical
reasons, but in my view it would be better to avoid creating new names
like this in future. 

I also support the other recent postings concerning min and max table 
column keywords, and standard keywords for RA, DEC, and reference 
frames.

From fitsbits-request  Mon Aug  2 10:00:47 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["215" "" "2" "August" "1993" "13:43:47" "GMT" "Edward J.M. Colbert" "colbert at astro.umd.edu " nil "8" "Making a FITS file" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA27278; Mon, 2 Aug 93 10:00:47 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <23j5mj$4p0 at umd5.umd.edu>
Organization: University of Maryland, Astronomy Department
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!news-feed-2.peachnet.edu!umn.edu!spool.mu.edu!wupost!uunet!haven.umd.edu!umd5.umd.edu!colbert
From: colbert at astro.umd.edu (Edward J.M. Colbert)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Making a FITS file
Date: 2 Aug 1993 13:43:47 GMT

Hi:

I would like to take a 3-dimensional float array (x,y,z)_i and make
a FITS image out of it with x and y on the pixel axes.  There must 
be a routine already written to do this.  Where can I get it?

Thanks,
Ed

From fitsbits-request  Mon Aug  2 10:52:36 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2699" "Mon" "2" "August" "93" "10:51:43" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "79" "Re: Making a FITS file" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA27300; Mon, 2 Aug 93 10:52:36 EDT
Return-Path: <pence at tetra.gsfc.nasa.gov>
Message-Id: <9308021451.AA13415 at tetra.gsfc.nasa.gov>
From: pence at tetra.gsfc.nasa.gov (William Pence)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Cc: pence at tetra.gsfc.nasa.gov
Subject: Re: Making a FITS file
Date: Mon, 2 Aug 93 10:51:43 EDT

Ed colbert wrote:

>I would like to take a 3-dimensional float array (x,y,z)_i and make
>a FITS image out of it with x and y on the pixel axes.  There must 
>be a routine already written to do this.  Where can I get it?

I'm not sure what you mean by "with x and y on the pixel axes", but
the following sample subroutine will take a 3-d array and write it out
as a 3-D FITS image (data cube) if that is what you wanted to do.
  
First, build a copy of the FITSIO subroutine library, available from the
/pub/fitsio/ directory in the anonymous ftp account on tetra.gsfc.nasa.gov
then link it will the following Fortran subroutine as a template for creating a
FITS file.  You will probably need to make some minor modifications to this
subroutine to meet your exact requirements.:

C-------------------------------------------------------------------------------
	subroutine make3d(array,nx,ny,nz)

C	Write the array of data out to a FITS file.

C	array = input floating point 3D array
C	nx = input size of the first axis of array
C	ny = input size of the second axis of array
C	nz = input size of the third axis of array

	integer nx,ny,nz
	real array(nx,ny,nz)
	integer status,blocksize,iunit,bitpix,naxis,naxes(3)
	integer pcount,gcount,group,fpixel,nelem
	logical simple,extend

C	initialize status, FITS blocksize, and the fortran unit number to use
        status=0
	blocksize=1
        iunit=21

C       Create the new FITS file called file3d.fits
        call ftinit(iunit, 'file3d.fits', blocksize, status)

C	Define datatype of FITS array as single precision floating point.
        bitpix=-32

C       Initialize values for required keywords
        simple=.true.
        naxis=3
        naxes(1)=nx
        naxes(2)=ny
	naxes(3)=nz
        pcount=0
        gcount=1
        extend=.true.

C       Write the required primary array keywords
        call ftphpr(iunit,simple,bitpix,naxis,naxes,pcount,gcount,
     &       extend,status)

C       Define the primary array structure (sets up internal FITSIO parameters)
        call ftpdef(iunit,bitpix,naxis,naxes,pcount,gcount,status)

C       Write the primary array of data (real*4 data array)
        group=1
        fpixel=1
	nelem=nx*ny*nz
        call ftppre(iunit,group,fpixel,nelem,array,status)

C	Close the FITS file
        call ftclos(iunit,status)

	end

C-------------------------------------------------------------------------

It would be useful to add more error checking to the above program
such as checking that the returned status values are = 0.  Also, one
would probably want to add some additional optional header keywords to
the FITS file.  This can be easily be done with other FITSIO subroutine calls.

-Bill Pence

From fitsbits-request  Tue Aug  3 14:08:12 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["870" "" "3" "August" "93" "16:40:57" "GMT" "William Thompson" "thompson at serts.gsfc.nasa.gov " nil "19" "Re: min and max table column keywords" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA00481; Tue, 3 Aug 93 14:08:12 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <thompson.744396057 at serts.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!skates.gsfc.nasa.gov!serts.gsfc.nasa.gov!thompson
References: <9307301816.AA21391 at tetra.gsfc.nasa.gov>
From: thompson at serts.gsfc.nasa.gov (William Thompson)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: min and max table column keywords
Date: 3 Aug 93 16:40:57 GMT

pence at tetra.gsfc.nasa.gov (William Pence) writes:

>Here within the OGIP/HEASARC we have a need to define a pair of standard
>FITS header keywords to give the minimum and maximum values contained
>within a column in a FITS table.  These keywords would be analogous to
>the DATAMIN and DATAMAX keywords which are defined for use with
>FITS images.   An obvious choice of names for these new keywords would
>be:

>TDMINnnn =  0.0    / the actual minimum value contained in column nnn of the table
>TDMAXnnn = 1000.   / the actual maximum value contained in column nnn of the table

>Does anyone have any comment on these keyword names?  Or has an alternative
>keyword already been proposed and/or used for this purpose?

I had proposed these same keywords earlier, and have been planning to use them
for the SOHO project.  It is the most obvious choice.

William Thompson

From fitsbits-request  Wed Aug  4 20:45:42 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["453" "Wed" "4" "August" "1993" "20:55:10" "GMT" "Dominique Beauchamp" "beaucham at phy.ulaval.ca " nil "13" "A FITS viewer for OS/2 PM ViewFITS" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA04486; Wed, 4 Aug 93 20:45:42 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <CB9640.43u at athena.ulaval.ca>
Organization: CRAPUL
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!darwin.sura.net!math.ohio-state.edu!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!mcrcim.mcgill.edu!sifon!athena.ulaval.ca!leo!beaucham
Reply-To: beaucham at phy.ulaval.ca
From: beaucham at phy.ulaval.ca (Dominique Beauchamp)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: A FITS viewer for OS/2 PM ViewFITS
Date: Wed, 4 Aug 1993 20:55:10 GMT

Hi!

I released yesterday the most recent version (0.3 rel. 2) of ViewFITS, a FITS
viewer for OS/2 2.1, presentation manager.  If you want to get it, it is on
ftp.cdrom.com in /pub/os2/incoming, its name is vf03r2.zip.

The package comes with 3 images.  It is still a beta version but has interesting
features.  If you try it, let me know!

Dominique Beauchamp
InterNet: beaucham at phy.ulaval.ca
FidoNet (NET MAIL or Astronomy Echo): DOMINIQUE BEAUCHAMP


From fitsbits-request  Thu Aug  5 18:33:48 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["3300" "" "5" "August" "1993" "19:38:15" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "61" "Re: HDF as an archive format" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA07223; Thu, 5 Aug 93 18:33:48 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <23rnj7INNo7d at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla
References: <JENNINGS.93Aug4153252 at antwrp.enemy.gsfc.nasa.gov> <5AUG199310442680 at nssdca.gsfc.nasa.gov>
From: sla at umbra.UCSC.EDU (Steve Allen)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: HDF as an archive format
Date: 5 Aug 1993 19:38:15 GMT

In article <5AUG199310442680 at nssdca.gsfc.nasa.gov>
bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes:
>First of all, a general comment.  All FITS formats endorsed by the IAU
>have been published in the refereed literature...

Which is a good thing.  Anything that goes in to a FITS file will always
be possible to get out.  I use FITS as a part of my work, and as a
data storage mechanism for my thesis data.  Some of my thesis data
are synthetic.  They are model matrices with appropriate amounts of
structured information to describe what each element of the model is,
how it was generated, etc.

>The basic goal of a FITS software reader is to generate the
>appropriate table or array....

This sentence exposes one of the worst problems with FITS
	"tabel or array"
FITS is great for encoding any kind of multidimensional rectangular
array.  It is not so great for other entities.

>       ...           So FITS readers should be able to create
>correctly structured binary tables from any BINTABLE FITS file.

I have no argument here.  Again, anything that goes *in* to a FITS
file will always be possible to get out.  The problem is, that some
kinds of data are very difficult to get *in* to a FITS file.

I mean, specifically, data structures, linked lists, and other sorts of
documentary information which would be associated with an image.  It is
possible now, with the BINTABLE extension, to encode these sorts of things
in a FITS file.  BINTABLE provides all the necessary pointers and
data HEAPs.

However, there really are no tools for converting a generic data structure
into this format.  Likewise, there are no tools for guaranteeing that the
data can be extracted into a reader which will reconstruct the original
structures.  Bill Pence's FITSIO toolkit is perfect for dealing with the
low-level operations on FITS files, and I use it.  Being written in standard
Fortran 77, however, means that it cannot provide the routines necessary
to comprehend, encode, and decode structures of data.

Using FITSIO, I have created a number of tools of this sort for my thesis
data, but they are in no way standardized.  I would not expect that
someone else's FITS reader would have a chance of actually using my
FITS files to do the work they were written to do.  Basically, then,
I have invented tools with some of the features of HDF, but which are
based upon an "archival" underlying format.

If HDF makes doing the work easier, then that is a significant advantage
for it which FITS does not have.  This is especially true for graduate
students or other sorts of projects which do not have the time to
invent some kind of wrapper code that successfuly stores and retrieves
their data structures.  Bill Pence's FITSIO routines are good, but
FITS would benefit even more by having a much higher-level interface
in a language which comprehends the kinds of non-rectangular data
structures which have always been around but which are awkward to
manipulate in FORTRAN.
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me.

From fitsbits-request  Fri Aug  6 07:02:13 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["3291" "" "6" "August" "93" "01:28:39" "GMT" "Lee E. Brotzman" "leb at Hypatia.gsfc.nasa.gov " nil "56" "Re: min and max table column keywords" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA07662; Fri, 6 Aug 93 07:02:13 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <leb.744600519 at Hypatia>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!Hypatia!leb
References: <9307301816.AA21391 at tetra.gsfc.nasa.gov> <thompson.744396057 at serts.gsfc.nasa.gov>
From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: min and max table column keywords
Date: 6 Aug 93 01:28:39 GMT

pence at tetra.gsfc.nasa.gov (William Pence) writes:
>TDMINnnn =  0.0    / the actual minimum value contained in column nnn of the table
>TDMAXnnn = 1000.   / the actual maximum value contained in column nnn of the table
>
>Does anyone have any comment on these keyword names?  Or has an alternative
>keyword already been proposed and/or used for this purpose?

A resounding yes!  This convention was mentioned some time ago, and I have been
a big fan ever since.  Future FITS tables from the Astronomical Data Center 
will definitely use this convention, and I plan to propose that they be made
standard keywords whenever the next NOST FITS committee begins operation.

One remaining question is about the datatype of the value.  Should it always
be floating point?  In ASCII tables, the TNULL field is defined to be a string
readable with the format given in TFORM.  This may present a problem for
binary tables where the value of the keyword is character, regardless of
whether it is enclosed in quotes or not, whereas the actual data you'd be
comparing TDMIN/TDMAX against are binary.  I think that it would suffice for
both ASCII and BINTABLE extensions to have the TDMIN/TDMAX be strings readable
by the TFORM keyword, implying that a sensible mapping of the BINTABLE TFORMs
can be made to some default formats in Fortran, C, etc.

The reason I'd like to have it this way is to allow a MAX and MIN for
ASCII-valued columns.  I'd hate to see a really useful feature like this
restricted to just numbers.  The ADC has found that specifying maximum and
minimum values for strings in tables, e.g. note flags that range from 'A' to
'M', provide for easy validation checking of the contents of a table.  It has
become extremely useful and very nearly mandatory for us to do our jobs.

Does anyone have any comment on that?  It's still unresolved in my own mind,
and I'd really appreciate hearing from the community before we go into
production on our tables.  (Paul Kuin and I have just won a grant to generate 
FITS tables from another 150 or so ADC catalogs over the next two years, so 
there *will* be new FITS data from the ADC, and it *will* be using TDMIN and 
TDMAX and possibly TSORT to indicate sorted columns.)

>Similarly, we need to define a pair of keywords which give the minimum
>and maximum _legal_ value for the numbers in a column.  For example, a
>table column containing the X coordinate of a list of detected photon
>in an image may have legal values from 0 - 255 inclusive.  A good
>keyword name for this purpose is less obvious, but the following pair
>of keywords has been suggested:

>TAMINnnn =   0.0   / the smallest possible value for column nnn of the table
>TAMAXnnn = 255.0   / the largest possible value for column nnn of the table

I might suggest, TLMINnnn and TLMAXnnn for "Table Legal Min" and "Table Legal
Max", respectively.  I think that these keywords are not needed as much as the
ones mentioned above.  It's much more important to know the *real* value
boundaries then the *expected* boundaries, at least in the applications that I
can think of.

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

From fitsbits-request  Fri Aug  6 07:12:41 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2122" "" "6" "August" "1993" "05:39:52" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "58" "shell tools for FITS files, part II" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA07800; Fri, 6 Aug 93 07:12:41 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <23sqr8INN5jf at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!news.udel.edu!udel!gvls1!dsinc!spool.mu.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla
From: sla at umbra.UCSC.EDU (Steve Allen)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: shell tools for FITS files, part II
Date: 6 Aug 1993 05:39:52 GMT

A while back I posted a little shell script that could be used to
print the contents of FITS file headers.  Here, with thanks to
Alberto Accomazzi, is an improved version.

#!/bin/sh
#       A little Cshell script which acts like cat.
#       Author: Steve Allen (sla at lick.ucsc.edu) 1992,1993
#       It takes as input a FITS file, and cats out the headers of
#       the primary HDU and any FITS extensions which may be present.
#       04/27/93        Modified to be a Bourne shell script and redirect
#                       the statistics generated by dd to /dev/null
#                       Alberto Accomazzi (alberto at cfa.harvard.edu).
#       06/22/93        Modified to print only primary header and quit
#                       unless flag -x is specified
#                       Alberto Accomazzi (alberto at cfa.harvard.edu).
#
#   Some recent Lick FITS headers have a "comment" as a part of the
#   END card.  This is actually illegal, but by giving the -L switch
#   as the first argument this script will tolerate them.

sed1='/^SIMPLE  = /,/^END *$/p'
sed2='/^END *$/q'
files=""

if [ $# -gt 0 ] ; then
    for arg in $* ; do
	case "$arg" in
	-l|-L)  # be compatible with the illegal Lick FITS headers
		sed1='/^SIMPLE  = /,/^END */p' ;;
	-x|-X)  # print extension header
		sed2='/^XTENSION= /,/^END *$/p' ;;
	-*)     # illegal option
		echo "Usage: $0 [-x] [-l] [fitsfile]" >&2
		exit 1 ;;
	*)      # filename
		files="$files $arg" ;;
	esac
    done
fi

#
if [ -z "$files" ] ; then
    # act like a pipeline element
    ( dd conv=unblock cbs=80  | sed -n -e "$sed1" -e "$sed2" ) 2>/dev/null
else
    set $files
    for file in $* ; do
	if [ $# -gt 1 ] ; then
	    echo "===> "$file" <==="
	fi
	( dd conv=unblock cbs=80 if=$file 2>/dev/null | sed -n -e "$sed1" -e "$sed2" ) 2>/dev/null
    done
fi

_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me.

From fitsbits-request  Fri Aug  6 07:13:40 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2320" "" "6" "August" "1993" "05:46:49" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "55" "shell tools for FITS files, part III" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA07827; Fri, 6 Aug 93 07:13:40 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <23sr89INN5no at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!europa.eng.gtefsd.com!uunet!spool.mu.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla
References: <23sqr8INN5jf at darkstar.UCSC.EDU>
From: sla at umbra.UCSC.EDU (Steve Allen)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: shell tools for FITS files, part III
Date: 6 Aug 1993 05:46:49 GMT

Here is yet one more little shell tool for FITS files.  Given
a keyword on the command line, it picks out the value of that
keyword and prints it.  There is lots of room for improvement
of this script, but it works.

#!/bin/sh
#                       fitskey
#       A little bourne shell script which acts like fgrep for FITS keywords.
#       It only looks in the primary header; extensions are ignored.
#       Author: Steve Allen (sla at lick.ucsc.edu) 1993
#       It takes as input a FITS file, and prints out the FITS key
#       values associated with the given FITS keyword.
#       Could be enhanced to look at XTENSIONs, and to optionally print
#       the keyword itself and/or the comment field.  It also produces
#       stupid output if there is more than one identical keyword.
#
if [ $# -lt 1 ]; then
    echo "Usage: $0 FITSkeyword [FITSfile ...]" >&2
    exit 1
fi

# a legal FITS key must be 8 characters long with explicit trailing spaces
# the awk script here ensures that arrangement
# find a quoted string (but not one which contains quotes!)
seds=`echo $1 | awk '{printf("s&^%-8.8s= *\(%c[^%c]%c\)&\1&p",$1,39,39,39)}'`
# echo seds is $seds
# find a value followed by a comment
sedc=`echo $1 | awk '{printf("s&^%-8.8s= *\(.*\)/.*&\1&p",$1)}'`
# echo sedc is $sedc
# find a value not followed by a comment
sedv=`echo $1 | awk '{printf("s&^%-8.8s= *\(.*\)&\1&p",$1)}'`
# echo sedv is $sedv
shift                   # throw away the FITS keyword in the first argument
sedq='/^END */q'        # detect end of primary fits header (even if from Lick)

if [ -z "$*" ] ; then
    # act like a pipeline element
    ( dd conv=unblock cbs=80  | sed -n -e "$sedq" -e "$seds" -e t -e "$sedc" -e t -e "$sedv" ) 2>/dev/null
else
    for file in $* ; do
	keyval=`dd cbs=80 conv=unblock if=$file 2>/dev/null | \
	sed -n -e "$sedq" -e "$seds" -e t -e "$sedc" -e t -e "$sedv"`
	if [ ! -z "$keyval" ]; then
	    if [ $# -gt 1 ]; then
		echo $file": "$keyval
	    else
		echo $keyval
	    fi
	fi
    done
fi
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me.

From fitsbits-request  Fri Aug  6 12:14:12 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["852" "" "6" "August" "1993" "11:43" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "23" "Re: HDF as an archive format" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA09487; Fri, 6 Aug 93 12:14:12 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <6AUG199311431903 at nssdca.gsfc.nasa.gov>
Organization: NASA - Goddard Space Flight Center
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
References: <JENNINGS.93Aug4153252 at antwrp.enemy.gsfc.nasa.gov> <5AUG199310442680 at nssdca.gsfc.nasa.gov> <23rnj7INNo7d at darkstar.UCSC.EDU>
From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: HDF as an archive format
Date: 6 Aug 1993 11:43 EDT

In article <23rnj7INNo7d at darkstar.UCSC.EDU>, sla at umbra.UCSC.EDU (Steve Allen) writes...
>In article <5AUG199310442680 at nssdca.gsfc.nasa.gov>
>bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes:
> 
>>The basic goal of a FITS software reader is to generate the
>>appropriate table or array....
> 

>This sentence exposes one of the worst problems with FITS
>	"tabel or array"
>FITS is great for encoding any kind of multidimensional rectangular
>array.  It is not so great for other entities.
> 
> 
>I mean, specifically, data structures, linked lists, and other sorts of
>documentary information which would be associated with an image. 

Tables and arrays are the only standard extensions and proposals under 
consideration at present.  But the field is open for more development.


				Barry Schlesinger
				NSSDC/NOST FITS Support Office

From fitsbits-request  Fri Aug  6 14:11:02 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1693" "" "6" "August" "1993" "17:24:21" "GMT" "Steve Allen" "sla at umbra.UCSC.EDU " nil "53" "Re: shell tools for FITS files, part II" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA09556; Fri, 6 Aug 93 14:11:02 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <23u445INNfbs at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!darkstar.UCSC.EDU!umbra.UCSC.EDU!sla
References: <23sqr8INN5jf at darkstar.UCSC.EDU>
From: sla at umbra.UCSC.EDU (Steve Allen)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: shell tools for FITS files, part II
Date: 6 Aug 1993 17:24:21 GMT

In article <23sqr8INN5jf at darkstar.UCSC.EDU> sla at umbra.UCSC.EDU
(that was me) forgot that one of Alberto Accomazzi's best additions to
the original shell script was to create a man page.  Kindly
associate it with the shell script if you are keeping these.

.TH fitshead l "22 June 1993"
.IX fitshead
.SH NAME
fitshead - display the header of a FITS file
.SH SYNOPSIS
.B fitshead
[
.B -l
] [
.B -x
] [
.IR fitsfile \ ...
]
.SH DESCRIPTION
Displays the header of a FITS file.
If flag
.B \-x
is specified, any extensions that may be present in the
input file are displayed as well.
.SH OPTIONS
.PP
.TP
.B \-l
forces
.I fitshead
to tolerate illegal END cards in the header (these cases have been found in
files generated at Lick Observatory).
.PP
.TP
.B \-x
scans the file for any FITS extensions and, if found, displays the extension
header(s).
.SH "SEE ALSO"
dd(1), sed(1)
.SH AUTHOR
Steve Allen (sla at lick.ucsc.edu) 1992,1993
.br
Modified by Alberto Accomazzi (alberto at cfa.harvard.edu) 1993.
.\" Permission to use, copy, modify, and distribute this software and its
.\" documentation for any purpose and without fee is hereby granted, provided
.\" that the above copyright notice appear in all copies and that both that
.\" copyright notice and this permission notice appear in supporting
.\" documentation.  This software is provided "as is" without express or
.\" implied warranty.
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't use me.

From fitsbits-request  Fri Aug  6 15:56:49 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1025" "Fri" "6" "August" "1993" "15:54:41" "-0400" "Usque ad mortem bibendum" "GEORGE at ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "26" "OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings  " "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA09628; Fri, 6 Aug 93 15:56:49 EDT
Return-Path: <GEORGE at ROSGIP.GSFC.NASA.GOV>
Message-Id: <930806155441.20c000b3 at ROSGIP.GSFC.NASA.GOV>
X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU"   
From: GEORGE at ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum))
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings  
Date:    Fri, 6 Aug 1993 15:54:41 -0400 (EDT)

A new version of the OGIP memo (OGIP/93-001) listing the OGIP-standard 
strings to specify physical units within FITS files is now available. 
Only very minor changes have been made compared to previous versions to 
help clarify a number of points. The "unit" byte is also now included
due to popular demand.

The memo is available via anonymous ftp on 
	legacy.gsfc.nasa.gov (128.183.8.233) 
as 
	.caldb/docs/memos/ogip_93_001.tex	the LaTeX source
	.caldb/docs/memos/ogip_93_001.ps  	PS version of complete doc.


It is intended that this document will also be published in the next issue 
of "Legacy: The Journal of the HEASARC" (currently scheduled for 93 Sept/Oct).

For your info, this latest version was formally endorsed by a meeting of
the OGIP FITS Standards Panel (OFSP) within the Office of Guest
Investigators (OGIP) at NASA/GSFC on 1993 Aug 04. All future OGIP FITS
files will therefore adhere to the recommendations contained therewithin. 
						
regards
Ian M George 			(george at lheavx.gsfc.nasa.gov)
HEASARC



From fitsbits-request  Fri Aug  6 18:18:43 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1269" "Fri" "06" "August" "93" "18:18" "EDT" "\"Wayne H. Warren Jr. 286-5419\"" "W3WHW at GIBBS.GSFC.NASA.GOV" nil "26" "TAMIN, TAMAX Keywords" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA09691; Fri, 6 Aug 93 18:18:43 EDT
Return-Path: <W3WHW at GIBBS.GSFC.NASA.GOV>
Message-Id: <9308062218.AA09685 at fits.cv.nrao.edu>
From: "Wayne H. Warren Jr. 286-5419"       <W3WHW at GIBBS.GSFC.NASA.GOV>
	        (Code 681/GSFC)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: FITSBITS                            <fitsbits at FITS.CV.NRAO.EDU>
Subject: TAMIN, TAMAX Keywords
Date:    Fri, 06 Aug 93 18:18 EDT


leb at hypatia.gsfc.nasa.gov (Lee Brotzman) writes:

>I might suggest, TLMINnnn and TLMAXnnn for "Table Legal Min" and
>"Table Legal Max", respectively.  I think that these keywords are not
>needed as much as the ones mentioned above. It's much more important to
>know the *real* value boundaries then the *expected* boundaries, at
>least in the applications that I can think of.

I prefer TAMINnnn and TAMAXnnn for "allowed" myself, since the other
seems to imply that these "allowed" values could never change for the
same data (plus they remind me of LAWYERS-"sic").  These parameters may
be somewhat less important than the REAL extrema, but for validation
purposes, they can be very useful to discover invalid data.  For
example, in a catalog of stellar parameters, one knows that stellar
radial velocities can never be outside the range +/-300 k/s (just an
example), whereas the actual range might be much smaller and the user
might not be familiar enough with radial velocites to know the "allowed"
values.  Thus, the allowed extrema provide at least a certain amount of
validation for data that cannot be checked at all by any other means.

Wayne H. Warren Jr.
Hughes STX Corporation
Laboratory for Astronomy and Solar Physics
NASA GSFC
w3whw at gibbs.gsfc.nasa.gov

From dwells  Fri Aug  6 22:31:22 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1430" "Fri" "6" "August" "1993" "13:58:31" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "32" "OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings " "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA10036; Fri, 6 Aug 93 22:31:22 EDT
Resent-Message-Id: <9308070231.AA10036 at fits.cv.nrao.edu>
Return-Path: <dwells>
Message-Id: <9308070231.AA10030 at fits.cv.nrao.edu>
Resent-Sender: dwells
From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum))
Sender: fitsbits-request at fits.CV.NRAO.EDU
Resent-From: dwells (Don Wells)
To: fitsbits
Subject: OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings 
Date:    Fri, 6 Aug 1993 13:58:31 -0400 (EDT)
Resent-Date:    Fri, 6 Aug 1993 13:58:31 -0400 (EDT)

------- Start of forwarded message -------
Message-Id: <930806135831.20e003a1 at HEAGIP.GSFC.NASA.GOV>
From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum))
To: fitsbits-request at fits.CV.NRAO.EDU
Subject: OGIP/93-001 (Vers 1993 Aug 06): On the specification of unit strings 
Date:    Fri, 6 Aug 1993 13:58:31 -0400 (EDT)

A new version of the OGIP memo (OGIP/93-001) listing the OGIP-standard 
strings to specify physical units within FITS files is now available. 
Only very minor changes have been made compared to previous versions to 
help clarify a number of points. The "unit" byte is also now included
due to popular demand.

The memo is available via anonymous ftp on 
	legacy.gsfc.nasa.gov (128.183.8.233) 
as 
	.caldb/docs/memos/ogip_93_001.tex	the LaTeX source
	.caldb/docs/memos/ogip_93_001.ps  	PS version of complete doc.


It is intended that this document will also be published in the next issue 
of "Legacy: The Journal of the HEASARC" (currently scheduled for 93 Sept/Oct).

For your info, this latest version was formally endorsed by a meeting of
the OGIP FITS Standards Panel (OFSP) within the Office of Guest
Investigators (OGIP) at NASA/GSFC on 1993 Aug 04. All future OGIP FITS
files will therefore adhere to the recommendations contained therewithin. 
						
regards
Ian M George 			(george at lheavx.gsfc.nasa.gov)
HEASARC
------- End of forwarded message -------

From fitsbits-request  Sat Aug  7 09:57:01 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["4740" "Sat" "7" "August" "1993" "9:55:09" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "96" "OFSP Proposal for a HDUCLASn hierarchy of keywords (v 93-Aug-08)" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA11708; Sat, 7 Aug 93 09:57:01 EDT
Return-Path: <GEORGE at HEAGIP.GSFC.NASA.GOV>
Message-Id: <930807095509.20e00530 at HEAGIP.GSFC.NASA.GOV>
X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU"
From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum))
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: OFSP Proposal for a HDUCLASn hierarchy of keywords (v 93-Aug-08)
Date:    Sat, 7 Aug 1993 9:55:09 -0400 (EDT)

	-------------------------------------------------------
	|   THE USE OF HDUCLASn KEYWORDS WITHIN FITS FILES    |
	-------------------------------------------------------
					  Version: 1993 Aug 06

(Formerly, "THE USE OF EXTCLASn KEYWORDS WITHIN FITS FILES")

At a meeting on 1993 Aug 04 of the OGIP FITS Standards Panel (OFSP) within
the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review
of the OFSPs previous proposal for the provision of a hierarchical
classification scheme for various types of FITS extension to be used within
the OGIP (and potentially elsewhere). 

As a result of a comment received from Maureen Conroy (CfA), the previous
proposal (as posted to FITSBITS by George 93-jul-26) has been revised such
that the proposed hierarchy is now achieved using HDUCLASn keywords (rather
than the previous suggestion of EXTCLASn). The current proposal is included
below in full. As ever, the OFSP would welcome any comments (via FITSBITS)
on this new proposal. 


====================== Current Proposal in Full ============================

	-------------------------------------------------------
	|   THE USE OF HDUCLASn KEYWORDS WITHIN FITS FILES    |
	-------------------------------------------------------
					  Version: 1993 Aug 06

Introduction
------------
We consider there to be a common need for a set of keywords which 
precisely define the scientific 'type', 'sub-type', 'sub-sub-type'..etc 
of the data contained within a given FITS extension (including the 
Primary Array). It should be stressed that by scientific 'type' we 
are referring to whether a given extension contains (say) a 'light curve',
a 'PHA spectrum', a 'background map', and possibly sub-classes of these.
We are NOT explicitly referring to how that data is actually stored internally 
within the FITS extension.

As far as we are aware, no existing FITS keywords are commonly used for
SOLELY for this purpose, or (can easily) provide the necessary & desirable
number of hierarchical levels (at least for our intended usage). Indeed, we
are aware that a variety of existing keywords have been employed for
similar purposes within the community (specifically EXTNAME), but often
using mutually incompatible conventions. Here we therefore propose a family
of new keywords which forms such a hierarchy of descriptive strings
EXPLICITLY for this usage. We believe these new keywords compliment &
clarify the use of existing FITS keywords, and are likely to be of general
use throughout the FITS community. 

The Proposal
------------
We propose that the scientific 'type', 'sub-type', 'sub-sub-type'..etc 
of the data contained within a given FITS extension be specified using
a set of keywords of the form HDUCLASn (standing for Header-Data Unit Class), 
where "n" is an integer between 1 & 9. These keywords should be considered 
hierarchical with n = 1 as the highest level, and n = 9 the lowest level. 

Usage
-----
The need & use of such keywords can be illustrated as follows. The input to
a specific application task is a FITS file consisting of a large number of
extensions. The application requires access to a particular type of 
(scientific) data -- lets say a "heavy particle background map" for a given 
observation using a given detector. Under the proposal, an extension 
containing such data would contain (say):
   HDUCLAS1 = 'BKGDMAP'
   HDUCLAS2 = 'PARTICLE'            
   HDUCLAS3 = 'HEAVY'            
and the application would thus first search through the file looking 
for HDUCLASn keywords with these values. If found, the application can then 
check for appropriate values of OBS-DATE, TELESCOP, INSTRUME etc. 
[Of course for generality/safety, the application might also want to continue
checking the remainder of the input file for additional extensions
fulfilling the above criteria. If additional extensions are indeed found,
then the application may, for example, prompt the user for which they wish
to use supplying information from other keywords etc] 
Once the required extension has been identified, the data can obviously be 
accessed. 

Advantages
----------
We consider the advantages of these new keywords over the use existing 
keywords (in particular the EXTNAME keyword) for this purpose to be 
as follows:
1) The new keywords are explicitly designed for this purpose, and thus 
	will not impact the ways in which other keywords are currently used.
2) The new keywords are equally appropriate for use with the Primary Array
	or an extension. 
3) The hierarchical nature of the information is explicit, and allows 
	smaller, user-friendly strings to be employed

----------------------------------- END ---------------------------------- 
Ian M George 					
NASA/GSFC OFSP
1993 Aug 08

From fitsbits-request  Sat Aug  7 10:58:48 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1917" "Sat" "7" "August" "1993" "10:56:57" "-0400" "Usque ad mortem bibendum" "GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA )" nil "38" "OFSP proposal Re: min and max table column keywords " "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA11859; Sat, 7 Aug 93 10:58:48 EDT
Return-Path: <GEORGE at HEAGIP.GSFC.NASA.GOV>
Message-Id: <930807105657.20e00530 at HEAGIP.GSFC.NASA.GOV>
X-Vmsmail-To: SMTP%"fitsbits at fits.CV.NRAO.EDU"
From: GEORGE at HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum))
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: OFSP proposal Re: min and max table column keywords 
Date:    Sat, 7 Aug 1993 10:56:57 -0400 (EDT)

  ------------------------------------------------------------------------
  | PROPOSED KEYWORDS TO GIVE THE MIN & MAX LEGAL VALUES WITHIN A COLUMN |
  ------------------------------------------------------------------------

At a meeting on 1993 Aug 04 of the OGIP FITS Standards Panel (OFSP) within
the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review
of keywords pairs used to give the minimum/maximum values actually contained
and the minimum/maximum legal values within a column in a FITS table.  

It was confirmed that the OGIP will use the TDMINnnn/TDMAXnnn keywords
already in common usage (eg Thompson FITSBITS post 93-aug-03) for the
minimum/maximum values actually contained within column 'nnn' of a FITS
table. 

In addition, the OFSP provisionally recommended that the TLMINnnn/TLMAXnnn
keywords be used to give the minimum/maximum LEGAL value for the numbers in 
column 'nnn' of a FITS table (as suggested by Brotzman FITSBITS 93-aug-06).

The OFSP also recommended the following to clarity:
- The datatype of the keywords should be the same as that of the table 
	column to which they refer.
- The keywords refer to ALL elements of a vector column. 
- These keywords imposed no constraints or information regarding the 
	meaning of any null data values within the data.
- It should not be forbidden to have values of (say) TDMIN < TLMIN, leaving
	it to individual applications as to what such situations implied. 
- If the keyword for the minimum value be GREATER than that for the maximum 
	value (ie TDMIN>TDMAX or TLMIN>TLMAX as appropriate), then this 
	should be taken to mean that the values had not been defined 
	and/or therefore needed [re-]calculating.

[The OFSP meeting obviously took place prior to Wayne Warren's FITSBITS 
 post on 93-aug-06]

----------------------------------- END ---------------------------------- 
Ian M George 					
NASA/GSFC OFSP
1993 Aug 07

From fitsbits-request  Sat Aug  7 11:56:14 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["797" "Sat" "7" "August" "1993" "15:10:51" "GMT" "Brad A. Pennock" "benji at netcom.com " nil "12" "FITS viewer for the Amiga?" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA11894; Sat, 7 Aug 93 11:56:14 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <benjiCBEA64.49C at netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-1.peachnet.edu!umn.edu!csus.edu!netcom.com!benji
From: benji at netcom.com (Brad A. Pennock)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITS viewer for the Amiga?
Date: Sat, 7 Aug 1993 15:10:51 GMT

I was just wondering if there was anyone reading this who knows of a FITS image viewer for the Amiga?  If not, is there a program that works for the Mac that'llconvert a FITS image into .GIF or 24bit?  Thanks for your help!

-- 
                                           _______----_______
       Brad A. Pennock          ___---~~~~~.. ... .... ... ..~~~~~---___
      benji at netcom.com      ==============================================
 ________________________- .. ..   _--~~~~~-------____-------~~~~~
(____________________][__)____     -
   /       /____---~~~.. .. ..~~-_~  "We put humans on the Moon in less time
  <_____________________________-     than we've spent debating the space
      ~~~~~~----__           _-       station."  Daniel S. Goldin, NASA.
                  ~~~~~~~~~~~ 

From fitsbits-request  Wed Aug 11 14:58:14 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA22041; Wed, 11 Aug 93 14:58:14 EDT
Return-Path: <pence at tetra.gsfc.nasa.gov>
Message-Id: <9308111857.AA08076 at tetra.gsfc.nasa.gov>
From: pence at tetra.gsfc.nasa.gov (William Pence)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Cc: pence at tetra.gsfc.nasa.gov
Subject: Re: the "archival" issue
Date: Wed, 11 Aug 93 14:57:18 EDT

Don Wells (2 Aug 1993) quoted Archie Warnock as saying:

>There are (at least) three different applications for data formats -
>interchange, access and archival storage.  It is not at all obvious that
>any single format can meet the needs of all 3 simultaneously, even less
>obvious that any single format currently _does_ meet the needs of all 3.
>
>In general, working formats need to emphasize access (read/write)
>efficiency.  Interchange formats need storage efficiency and
>standardized numeric representations.  Archival formats need to be
>self-documenting, externally documented and simple.
>
>Things like HDF, netCDF and CDF are good working formats but are risky
>as archival formats. (...) FITS
>and PDS are pretty good interchange and archival formats, but weak
>working formats.

The last sentence seems questionable since we have been using
FITS as a working format within the HEASARC for the past 2 years with
great success.  I need to give a talk on this subject in a couple
weeks, so I would be very interested to hear other opinions or
explanations on why FITS is not the ideal working format.

-Bill Pence
pence at tetra.gsfc.nasa.gov


From fitsbits-request  Wed Aug 11 22:32:05 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA24059; Wed, 11 Aug 93 22:32:05 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <1993Aug11.215833.5575 at Mr-Hyde.aoc.nrao.edu>
Organization: National Radio Astronomy Observatory, Socorro NM
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!dbriggs
References: <9308111857.AA08076 at tetra.gsfc.nasa.gov>
From: dbriggs at Mr-Hyde.aoc.nrao.edu (Daniel Briggs)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITS as a working format
Date: Wed, 11 Aug 93 21:58:33 GMT

In article <9308111857.AA08076 at tetra.gsfc.nasa.gov>
  pence at tetra.gsfc.nasa.gov (William Pence) writes:
>>FITS and PDS are pretty good interchange and archival formats, but weak
>>working formats.
>
>The last sentence seems questionable since we have been using
>FITS as a working format within the HEASARC for the past 2 years with
>great success.  I need to give a talk on this subject in a couple
>weeks, so I would be very interested to hear other opinions or
>explanations on why FITS is not the ideal working format.

I'll just comment that we have an image processing system here at NRAO
called SDE that primarily uses FITS as the working format.  It's a
collection of cooperating programs that are starting from the command
line.  All images, visibility files and what have you are stored as native
files under the host OS, and are read into memory as needed by each task.

Now this is a system designed for coding up experimental tasks quickly.
(In fact, the acronym stands for Software Development Environment.)  We
have a very flexible in memory database format for objects, which can
potentially have all sorts of additional things hanging off of them that
are not necessarily easily representable by FITS.  Our FITS reader/writer
makes no effort to encode or decode unknown keywords into FITS format.  It
just writes out all the standard keywords, and a small list of local ones,
if they are present.  If we have a database object that uses the more
flexible features of the format, we store the object as a (nonportable)
memory image.  For most other objects, we use FITS format.  Since we use
SAOimage for image display, there is a strong incentive to use FITS rather
than the memory image format.  (SAOimage can be used on the memory image
files, but only with great effort.)

My point is this: I use this system every day, and do a lot of software
development with fairly complicated algorithms.  I can't remember the last
time I was forced to use the memory image format.  It's amazing how much
everyday work can done with a very simple FITS format, and small handful
of 'optional' header keywords.  Some of our software is a bit sloppy in
assuming that one or more of the local keywords are present in the header,
but that's only bitten me once in the last three years I've been working in
this system.  (That was when importing an image from a different system --
we used different keywords for pointing center.)  Basically, FITS has
worked out just fine as a working format for us, with the caveat that we
have the option of going to a less portable, more flexible format when
needed.  But we rarely need it.

-- 
| Daniel Briggs  (dbriggs at nrao.edu)                      |  USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |      DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        | 
Support the League for Programming Freedom   (info from lpf at uunet.uu.net)

From fitsbits-request  Wed Aug 11 22:56:58 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1551" "Wed" "11" "August" "93" "23:06:23" "GMT" "Chris Flatters" "cflatter at cv3.CV.NRAO.EDU " nil "29" "Re: FITS as a working format" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA24071; Wed, 11 Aug 93 22:56:58 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <1993Aug11.230623.16228 at Mr-Hyde.aoc.nrao.edu>
Organization: NRAO
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!laphroaig!cflatter
References: <1993Aug11.215833.5575 at Mr-Hyde.aoc.nrao.edu>
Reply-To: cflatter at cv3.CV.NRAO.EDU
From: cflatter at cv3.CV.NRAO.EDU (Chris Flatters)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: FITS as a working format
Date: Wed, 11 Aug 93 23:06:23 GMT

The limitations of FITS as a working format only become apparent if you have
to modify a FITS file in place.  In this case you start to hit problems due to
the fact that a FITS file contains several pieces that follow one after another.
If you have to extend any but the last you need to shuffle everything later
in the file to make room.

As a simple but contrived example suppose that you have a CCD image and are
removing background stars and CCD defects using some interactive editor.  Your
editor adds history records to the FITS header describing every edit.  After
a number of edits the empty space in the header will be exhausted and the
editor will have to add another 2880-byte block to the header.  In order to
do this it must add 2880 bytes to the end of the file and then copy all of the
image data down by 2880 bytes.  If the image is large this could be an expensive
operation.

This type of problem is made worse if the are multiple HDUs (Header and
Data Units) in the file and similar problems will arise in any format where
the data are encoded as a serial stream of data units.  

The problem is avoided if in-place modification is forbidden and every change
requires a new file to be written.  This is not always practical.

It can also be avoided by splitting the FITS file into its component parts
(but then it is no longer a FITS file).  The idea of using a disected version
of FITS as a common working format for AIPS, IRAF etc was floated about 3
years ago but didn't seem to get anywhere.

	Chris Flatters
	cflatter at nrao.edu

From fitsbits-request  Thu Aug 12 05:00:24 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["5911" "Thu" "12" "August" "1993" "10:18:57" "+0200" "Lucio Chiappetti" "lucio at ifctr.mi.cnr.it" nil "113" "Re: the \"archival\" issue" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA24141; Thu, 12 Aug 93 05:00:24 EDT
Resent-Message-Id: <9308120900.AA24141 at fits.cv.nrao.edu>
Return-Path: <lucio at ifctr.mi.cnr.it>
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Reply-To: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
In-Reply-To: <9308111857.AA08076 at tetra.gsfc.nasa.gov>
Message-Id: <Pine.3.05.9308121034.D28830-d100000 at poseidon.ifctr.mi.cnr.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Resent-Sender: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Sender: fitsbits-request at fits.CV.NRAO.EDU
Resent-From: fitsbits-request
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: the "archival" issue
Date: Thu, 12 Aug 1993 10:18:57 +0200 (MET DST)
Resent-Date: Thu, 12 Aug 1993 10:18:57 +0200 (MET DST)



On Wed, 11 Aug 1993, William Pence wrote:

> Don Wells (2 Aug 1993) quoted Archie Warnock as saying:
> 
> >There are (at least) three different applications for data formats -
> >interchange, access and archival storage. [...]
> >
> >Things like HDF, netCDF and CDF are good working formats but are risky
> >as archival formats. (...) FITS
> >and PDS are pretty good interchange and archival formats, but weak
> >working formats.
> 
> The last sentence seems questionable since we have been using
> FITS as a working format within the HEASARC for the past 2 years with
> great success.  I need to give a talk on this subject in a couple
> weeks, so I would be very interested to hear other opinions or
> explanations on why FITS is not the ideal working format.
> 

  Essentially the reasons why (IMHO) FITS is not an ideal WORKING format
  are listed below (Bill you alrady know my opinion on this, I'm just
  repeating for the benefit of the list). However this is a matter of
  choice of the particular software package writer/user, and in my
  opinion has a lesser weight than the fact that FITS is at present
  an excellent INTERCHANGE format. 
  I've recently got access to a newsreader and subscribed to sci.data.formats
  and was surprised to find that there are more data formats between heaven
  and earth than are used by us astronomers, but my reaction was "oh not 
  yet another format" .... and in fact I've never seen other than FITS
  used for interchange (besides person-to-person arrangements using native
  formats of IRAF or MIDAS).
  Concerning ARCHIVING I am not so competent to judge, but I gather from
  the previous messages in this thread that FITS is good there too.

                            LONG life to FITS !!!

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

  Here are the reasons why I choose not to use FITS as working format
  (in this following an historical trend)

  a) FITS uses non-native binary representation, i.e. is more or less 
     slower on non-IEEE machines like VMS, Ultrix (nowadays this might
     be not so important, but one might like to gain that little extra
     speed)
     [My working format uses native representation, and optionally allows
     in place conversion between different operating system formats]

  b) FITS headers are bulkier (because they're ASCII card images, which
     is good for exhcange/archiving) than a possible pure-binary
     representation  [which I use in my working format]

  c) FITS headers are not extensible (this is pointed out also by Chris
     Flatters). In my opinion this is a major snag of a working format if
     one wants to add keywords taking into account a file in-place (rever-
     sible or not) modifications.
     [in my working format I use a file made of three parts : a fixed
     miniheader at start, a data section, and the "header" at the end.
     This because I do not like to keep things separate a' la .imh+.pix]

  d) the FITS 2880 block size is somewhat unnatural (this is totally
     transparent to an user of a package, but may be of some relevance to
     debugging while developing ... I'd like my file to have a "natural"
     record size, e.g. one image or table row  ... so that I can easily
     look at a wrong file with some record oriented tool and find out what
     I did wrong)
     [in my working format I use such "natural" record sizes ... even if
     incidentally the data section on a non-record oriented (Unix), IEEE
     machine will be identical to the data section of a FITS HDU]

  e) Chris Flatters mentioned (as an additional inefficiency to be added
     to point c) the fact that sometimes a FITS file has extra extensions.
     I personally do not like the usage to stick more HDUs in the same
     file for working purposes (bseides the usual SINGLE binary table
     case, of course), while this might be used for interchange (in fact
     most s/w I know unpacks the extensions in separate native files)
     [in my working format each file is standalone, however I conceive
     to stick together some associated files when converting to FITS for
     exchange ... e.g. my original proposal for exchange of a response
     matrix was a primary HDU with the matrix, and an IMAGE extension with
     the associated energy grid]
     Of course this is nothing intrinsic in FITS (just it is TOO flexible), is
     just a matter of taste of software writers.

Actually most of the above is matter of tastes. It was enough for me to
choose a different working format, but definitely not enough to depart
from FITS for interchange (in fact I enforced a number of FITS conventions
and **limitations** in the definition of my format, in order to preserve
easy mapping)

  f) one additional element may be that FITS needs conventions (in order
     to be long-lived), which may not always be suitable to the needs of
     a particular packages. If you choose FITS as working format you have
     either to stick to the conventions, or to propose new ones (the sort
     of things from OGIP seen in the last few months over fitsbits and
     HEAFITS). If these are mainly "insider" conventions, it could be
     easier to arrange things within a native format.
     [e.g. things like  character keywords longer than 68 char, or arrays
     or keywords] 

-----------------------------------------------------------------------------   
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E          
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager           
Internet: LUCIO at IFCTR.MI.CNR.IT            |           FORTUNAE SUAE            
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |                                    
Bitnet:   <please do not use any more>     |                                    
-----------------------------------------------------------------------------   





From fitsbits-request  Mon Aug 16 18:32:54 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["5326" "" "16" "August" "93" "20:55:25" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "107" "Re: the \"archival\" issue" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA06362; Mon, 16 Aug 93 18:32:54 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <warnock.745534525 at Hypatia>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!Hypatia!warnock
References: <9308111857.AA08076 at tetra.gsfc.nasa.gov>
From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: the "archival" issue
Date: 16 Aug 93 20:55:25 GMT

pence at tetra.gsfc.nasa.gov (William Pence) writes:
>The last sentence seems questionable since we have been using
>FITS as a working format within the HEASARC for the past 2 years with
>great success.  I need to give a talk on this subject in a couple
>weeks, so I would be very interested to hear other opinions or
>explanations on why FITS is not the ideal working format.

First of all, note that I claim only that it's not an ideal working
format, not an unusable working format.  Until the development of FITSIO
(a relatively recent development in the long and illustrious history of
FITS), it _was_ essentially unusable as a working format.

There are still some problems, though.  A number have already been
mentioned.  I'm still waiting for a C interface to FITSIO that doesn't
require a Fortran compiler.  There's no support in FITS for advanced
data structures (yeah - I know about BINTABLE, but I'm still waiting to
see some complex data structures encoded and utilized portably.  It just
_might_ work, but I'm not sure it's actually been done yet).

It works pretty well as a working format in some (reasonably simple)
cases, but I think you'd need to look at some of the annotation and
other capabilities of HDF before you make the case that FITS is anything
close to ideal.

FITS is unsurpassed (I firmly believe) in doing what it was designed
for.  My remarks are in no way to be interpreted as an overall
criticism.  Heck, I've even seen a text editor written in Fortran.  Just
because you can do it doesn't mean you _should_ do it... <more
platitudes about teaching pigs to sing and everything looking like a
nail, etc, etc>


--
_______________________________________________________________________
-- Archie Warnock              Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                  "Unix --- JCL For The 90s"
-- NASA/GSFC                   Project STELAR: WAIS to do science

From fitsbits-request  Tue Aug 17 07:46:18 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["697" "Tue" "17" "August" "1993" "12:46:02" "GMT" "Don Wells" "dwells at fits.CV.NRAO.EDU " nil "14" "Annotation capability (was Re: the \"archival\" issue)" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA08407; Tue, 17 Aug 93 07:46:18 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <DWELLS.93Aug17074602 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
References: <9308111857.AA08076 at tetra.gsfc.nasa.gov> <warnock.745534525 at Hypatia>
From: dwells at fits.CV.NRAO.EDU (Don Wells)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Annotation capability (was Re: the "archival" issue)
Date: Tue, 17 Aug 1993 12:46:02 GMT

In article <warnock.745534525 at Hypatia> warnock at Hypatia.gsfc.nasa.gov
(Archie Warnock) writes: "... I think you'd need to look at some of
the annotation and other capabilities of HDF before you make the case
that FITS is anything close to ideal.."

Archie, please tell us about annotation and other HDF features that
may be lacking in present FITS practice. What is annotation, how does
it work, what does it do?
--

  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 fitsbits-request  Tue Aug 17 14:26:01 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA09058; Tue, 17 Aug 93 14:26:01 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <17AUG199314000763 at nssdca.gsfc.nasa.gov>
Organization: NASA - Goddard Space Flight Center
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITS User's Guide available in PostScript
Date: 17 Aug 1993 14:00 EDT

	 An experimental PostScript copy of the User's Guide for FITS,
commissioned by NASA Headquarters and maintained by the NOST FITS
Support Office, has been added to the anonymous ftp files in the FITS
directory at nssdca.gsfc.nasa.gov.  This version of the User's Guide
(3.0) is the one that has been available in printed form since
January 1993.  The User's Guide is designed as a comprehensive
introduction to FITS, providing, in addition to the basic rules, FITS
background and history, recommended practices and hints for FITS use,
and discussions of current directions of development.  The style is
deliberately conversational, in contrast to the NOST Standard's
precise rulebook formality. 
	This PostScript file was generated by capturing the Macintosh
MS Word original in PostScript format.  Reports received by the FITS
office are that it has successfully printed from both VAX and Sun
computers, on HP Laserjet printers (IIIsi) and Sun printers.  Numerous
other retrievals have been made without any printing problems
reported, although a ghostwriter previewer could not deal with certain
fonts.  However, because of the well-known problems in converting
Macintosh Word to PostScript, universal portability cannot be
guaranteed. Please notify the FITS Support Office by electronic mail
of any problems. 

				Barry Schlesinger
				NSSDC/NOST FITS Support Office
				
				(Internet) fits at nssdca.gsfc.nasa.gov 
				(DECnet)   NCF::FITS 

				+1-301-513-1634

From fitsbits-request  Wed Aug 18 12:01:40 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["9887" "" "18" "August" "93" "15:18:00" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "249" "Identification of a FITS byte stream" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA02705; Wed, 18 Aug 93 12:01:40 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <warnock.745687080 at Hypatia>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!ames!skates.gsfc.nasa.gov!Hypatia!warnock
From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Identification of a FITS byte stream
Date: 18 Aug 93 15:18:00 GMT


The recent discussion on suitability of formats for archiving has
reminded me of the following small issue I'd like to raise here.  How
does someone who knows nothing about FITS identify an arbitrary byte
stream as FITS?

Note - if we _know_ about FITS, we can tell it's FITS by the presence of
the SIMPLE keyword at the start of the byte stream.  But there's nothing
required in the byte stream that says "I'm a FITS file and here's where
you go to find out about me."  Should such a comment be mandatory?
--
_______________________________________________________________________
-- Archie Warnock              Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                  "Unix --- JCL For The 90s"
-- NASA/GSFC                   Project STELAR: WAIS to do science

From fitsbits-request  Wed Aug 18 12:01:42 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	["753" "" "18" "August" "93" "15:20:47" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " "<warnock.745687247 at Hypatia>" "15" "Re: Annotation capability (was Re: the \"archival\" issue)" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA02711; Wed, 18 Aug 93 12:01:42 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <warnock.745687247 at Hypatia>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usenet.ins.cwru.edu!agate!ames!skates.gsfc.nasa.gov!Hypatia!warnock
References: <9308111857.AA08076 at tetra.gsfc.nasa.gov> <warnock.745534525 at Hypatia> <DWELLS.93Aug17074602 at fits.cv.nrao.edu>
From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: Annotation capability (was Re: the "archival" issue)
Date: 18 Aug 93 15:20:47 GMT

dwells at fits.cv.nrao.edu (Don Wells) writes:
>Archie, please tell us about annotation and other HDF features that
>may be lacking in present FITS practice. What is annotation, how does
>it work, what does it do?

Will do, but it's going to take a couple of days before I get time to
root through my HDF documentation.  Obviously, it's critical to identify
capabilities that exist in other formats that aren't supported in FITS
so that we can address the issue of format conversion.

--
_______________________________________________________________________
-- Archie Warnock              Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                  "Unix --- JCL For The 90s"
-- NASA/GSFC                   Project STELAR: WAIS to do science

From fitsbits-request  Wed Aug 18 13:17:18 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1303" "Wed" "18" "August" "93" "13:16:19" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "27" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA03003; Wed, 18 Aug 93 13:17:18 EDT
Return-Path: <pence at tetra.gsfc.nasa.gov>
Message-Id: <9308181716.AA19559 at tetra.gsfc.nasa.gov>
From: pence at tetra.gsfc.nasa.gov (William Pence)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: Identification of a FITS byte stream
Date: Wed, 18 Aug 93 13:16:19 EDT

Archie Warnock wrote:

>Note - if we _know_ about FITS, we can tell it's FITS by the presence of
>the SIMPLE keyword at the start of the byte stream.  But there's nothing
>required in the byte stream that says "I'm a FITS file and here's where
>you go to find out about me."  Should such a comment be mandatory?

I think it would be a good idea to 'strongly recommend' that all
FITS writers should add a standard comment citing a reference to a FITS 
definition document. This cannot be made manditory however without
invalidating all the existing FITS files which don't have such a 
comment, unless there is a grandfather clause that exempts all 
existing FITS files.

What is the best reference to cite?  The old A&A Suppl. papers, which
are somewhat out of date but are at least widely available in any
Astronomical library?  Or the new NOST FITS definition document 
which is much more complete, but may not be as easily accessable
50 years from now when someone is trying to decifer a dusty FITS tape?
Or both?

Also, should it be recommended that this comment be located as near as
possible to the beginning of the FITS file, to make it easy to spot?
Presumable this comment would only be needed in the primary array, and
there would be little reason to repeat it in every extension.

-Bill Pence

From fitsbits-request  Wed Aug 18 20:37:19 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["5401" "Wed" "18" "August" "93" "18:36:23" "-0600" "ADS User Support" "ads at cuads.Colorado.EDU" nil "156" "The ADS Abstract Service" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA05781; Wed, 18 Aug 93 20:37:19 EDT
Return-Path: <ads at cuads.Colorado.EDU>
Message-Id: <9308190036.AA00505 at cuads.Colorado.EDU>
From: ADS User Support <ads at cuads.Colorado.EDU>
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: FITSBITS at NRAO.EDU
Subject: The ADS Abstract Service
Date: Wed, 18 Aug 93 18:36:23 -0600


   NOTE: We apologize if you have already received this message.


   Dear Colleague,

   We are pleased to announce the availability of the ADS Abstract Service
   for use by non-US users.  To make use of this service, however, those
   users must make a patch update to their ADS installation (see the
   Installation Instructions below).  Also, to help ensure the continued
   availability of the Abstract service outside the US, it would be
   worthwhile if you would also review the following Background
   Information.

   If you have non-US colleagues who would benefit from this or other ADS
   services, please pass this notice on to them or suggest that they contact

			   ADS User Support
			   ads at cuads.colorado.edu
			   (303) 492-0466

							    Sincerely,
							    ADS Operations


   Background Information
   ----------------------
   The Astrophysics Data System (ADS) project has reached an agreement
   with NASA regarding the distribution of the abstracts to non-US users.
   The existing ADS Abstract Service provides access to over 125,000
   abstracts written by NASA RECON (and provided by the NASA Scientific
   and Technical Information Program) describing the articles appearing in
   all major astronomical journals.

   According to the new agreement with NASA, we will make the Abstract
   Service available to non-US users for a period of 6 months.  During
   this time we will gather statistics concerning usage patterns by non-US
   users.  NASA will review these and will then either:

	    Keep the abstracts open to all users,

	    Place restrictions or requirements for compensation
	    on some or all users/institutions, or

	    Discontinue the distribution to non-US users.

   Compensation would probably be in the form of requiring articles and
   publications to be submitted to the NASA Aerospace Database and made
   available to the aerospace research community.

   Since the NASA archives depend on such contributions, NASA encourages
   voluntary contributions from users/institutions of archival
   material.  If you have reports, journals or journal articles,
   conference papers or proceedings or any other form of scientific or
   technical information to contribute to NASA please
   contact:

	      Glen Hoetker
	      NASA Scientific and Technical Information Program
	      1213 Jefferson Davis Highway
	      Suite 1200
	      Arlington, VA 22202

	      Tel: (703) 685-1350
	      Fax: (703) 271-5669

	      ghoetker at sti.nasa.gov


   Please mention in your contact that this is in return for the use of
   the ADS abstract service.  Such contributions would make it much more
   likely that the first option above is the one chosen.

   If you have any questions or comments about this service and its 
   availability, please contact:


	      Dr. Guenther Eichhorn
	      Project Manager
	      Astrophysics Data System
	      (617) 495-7260
	      gei at cfa.harvard.edu



   Installation Instructions
   -------------------------
   All non-US users must update their ADS installations in order to
   make use of the Abstract service.

   Complete the following steps to update the Abstract service in your
   local installation of the ADS.  Note: If your installation requires
   super-user privileges you may need to contact your system
   administrator.

   1. Ensure that you are currently using ADS version 3.20.  If you
      are currently using an earlier version of the ADS you will have to
      upgrade the entire installation to take advantage of the Abstract
      service.  Check the file $ADS/ReleaseNotes.ADS if you do not know
      which version of the ADS you are running.

   2. Change directory to $ADS/ads_lib.
    
      > cd $ADS/ads_lib <return>

   3. Pick up the new Abstract service files from the authenticated
      ftp site at IPAC.  Be sure to use your ADS login and password when
      logging into the authenticated ftp directory at IPAC.  

	% ftp
	ftp> open adsftp.ipac.caltech.edu 10011

	[connection information ...]

	Name (adsftp.ipac.caltech.edu:[LOGNAME]): [ads_logname]
	331 Password required for [ads_logname].
	Password: [ads_password]
	230 User [ads_logname] logged in.
	ftp> binary
	ftp> cd basic_system/ads320/patch
	ftp> get README.Abstract_Update             (This File)
	ftp> get xads_abs
	ftp> quit

	[Note: If you are not running a name resolver at your site
	you will need to use "134.4.10.102 10011" in place of
	"adsftp.ipac.caltech.edu 10011".  However, this address is
	subject to change without prior notice and you are strongly
	advised to use or install a name resolver.]

   4. Start the ADS and try to submit a query to the Abstract
      service.  You may use the Abstract examples in the first ADS
      science scenario to help you get started.  If you no longer have
      this scenario, you may pick it up via anonymous ftp using the
      following steps.

	% ftp cuads.colorado.edu
	Connected to cuads.colorado.edu.
	220 cuads FTP server (ULTRIX Version 4.1 Tue Mar 19 00:38:17 EST 1991)
	ready.
	Name (cuads.colorado.edu:[LOGNAME]): anonymous
	331 Guest login ok, send ident as password.
	Password: [LOGNAME]
	230 Guest login ok, access restrictions apply.
	ftp> cd pub/ads
	ftp> get ADS_scenario1
	ftp> quit
	   
   If you have any problems or questions, you may contact ADS User Support at:

			      ads at cuads.colorado.edu
					or
				 (303) 492-0466




From fitsbits-request  Thu Aug 19 12:26:47 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["12325" "" "19" "August" "1993" "15:49:23" "GMT" " Frank ROUSSEL " "rousself at univ-rennes1.fr " nil "226" "FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA08109; Thu, 19 Aug 93 12:26:47 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <2507e4$etv at news.univ-rennes1.fr>
Organization: CRI Universite' de Rennes 1 - FR
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!math.ohio-state.edu!uwm.edu!rpi!batcomputer!ghost.dsi.unimi.it!univ-lyon1.fr!vishnu.jussieu.fr!zaphod.crihan.fr!news.univ-rennes1.fr!univ-rennes1.fr!rousself
From: rousself at univ-rennes1.fr ( Frank ROUSSEL )
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITS -> GIF or JPEG or TIFF converter
Date: 19 Aug 1993 15:49:23 GMT

Does such a converter exist for Unix ?
Thanks
---------------------------------------------------------------------------------
   _______       _______       ________   | Firstname: Frank
  /______/|     /______/\     /_______/|  | Lastname : ROUSSEL
 / ______|/    /  ____ \/|    |__   __|/  | E-mail: rousself at univ-rennes1.fr
/ /|           | |____| |/       | ||     | Telephone: + 33 99 83 26 10
| ||           |  __  __/        | ||     | 
| |\______     | || \ \\       __| ||__   | Address: 175, rue Belle Epine
\ \______/|    | ||  \ \\     /__| |/_/|  | CityStateZip: 35510
 \_______|/    |_|/   \_\|    |_______|/  | Cityname: CESSON SEVIGNE
    Centre de Ressources Informatiques    | Country: FRANCE
---------------------------------------------------------------------------------
---------- Science without conscience is only soul's ruin (Rabelais) ------------
---------------------------------------------------------------------------------
- Signed: The responsible of ASTROGOF project at Rennes' University of France   -
- who contributes to the development of CRI-CICB Gopher's server by maintaining -
- an astronomic anonymous ftp server 'ftp.univ-rennes1.fr' in /pub/Images/ASTRO -
---------------------------------------------------------------------------------

From fitsbits-request  Thu Aug 19 17:02:30 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["10366" "" "19" "August" "1993" "16:19" "EDT" "BARRY M. SCHLESINGER" "bschlesinger at nssdca.gsfc.nasa.gov " nil "194" "FITS basics and information (periodic posting)" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA09781; Thu, 19 Aug 93 17:02:30 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <19AUG199316193740 at nssdca.gsfc.nasa.gov>
Organization: NASA - Goddard Space Flight Center
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!haven.umd.edu!cs.umd.edu!skates.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger
From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITS basics and information (periodic posting)
Date: 19 Aug 1993 16:19 EDT

	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 provide a means for 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
also provide additional information, for example, about the instrument
or the history of the data.  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; it does not incorporate "FITS viewers", packages
for decoding the data into an image.  Users must develop or obtain
separate software to convert 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.
However, support is not guaranteed for all FITS files where the data
are in the form of an image.  In particular, there may be problems
when the data matrix members are in IEEE floating point format
(BITPIX<0) or the matrix has more than two dimensions (NAXIS>2).

     Archie Warnock and Ron Baalke have announced release of version
7.8 of the IMDISP program. IMDISP is an interactive image processing
program that runs on an IBM PC computer and supports FITS input. 
IMDISP 7.8 is available via anonymous ftp at ames.arc.nasa.gov
[128.102.18.3] in a file called imdisp78.zip in the pub/SPACE/SOFTWARE
subdirectory and at hypatia.gsfc.nasa.gov in the pub/software/imdisp
subdirectory.  It is also available (at least for the time being)
through Simtel-20 [192.88.110.20] 

Dominique Beauchamp, Universite Laval, Quebec City, has released a new
version (0.3 rel. 2) of ViewFITS, a FITS reader for OS/2 2.1,
presentation manager.  It is on ftp.cdrom.com in /pub/os2/incoming,
file name vf03r2.zip. This program gives the user the opportunity to
display FITS images (8,16 or 32 bits, integer or float), modifying the
gray shade palette, doing negation and zooming out. The program now
uses bitmap instead of direct drawing to the screen, with 100x faster
execution time.  It is still a beta version. If you try it, inform him
at beaucham at phy.ulaval.ca. 

	Additional 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/Science Office of Standards and Technology
(NOST) FITS Support Office.  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.  The current version, 3.0, was issued in January
1993. 	 

	The NOST has codified FITS as endorsed by the IAU into a
formal standard, eliminating some contradictions and ambiguities in
the original FITS papers.  This Definition of FITS was developed by a
Technical Panel chaired by Dr. Robert J. Hanisch (STSci), with review
by the astronomical community.  On June 18, 1993, it was approved as a
NOST Standard by an Accreditation Panel consisting of the NOST
Executive Board and an astronomical community representative; this
review was to confirm that the community had been given a satisfactory
opportunity to review the standard and that the Technical Panel had
properly considered and responded to all comments. 
	The NOST standard has been submitted to the IAU FITS Working
Group for endorsement as the international FITS standard, to replace
the four FITS papers and the Floating Point Agreement, which are the
current endorsed standard.  While this committee could in principle
endorse a version that differs in some way from the NOST document,
changes are unlikely, because members of this committee were active in
the process of reviewing the standard and their comments were given
significant weight in the deliberations of the Technical Panel. 
	The IAU has endorsed the Floating Point Agreement, which
defines how floating point numbers are to be expressed in FITS.  The
basic agreement appears verbatim in the User's Guide, and the
substance is incorporated in the NOST 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 at this writing.  A proposed reorganization would
move the FITS material to a FITS subdirectory under a STANDARDS
directory. The FITS files include copies of the current NOST draft
standard in flat ASCII, PostScript, and LaTeX.  Style and index files
are provided for the LaTeX form.  Except that the ASCII form lacks
typeface formatting, the copies in the three formats are identical;
only one need be retrieved.  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.  	There is an
experimental PostScript copy of the current version of the User's
Guide, generated by capturing the Macintosh MS Word original in
PostScript format. While copies have been printed without problems on
a variety of systems (a ghostwriter previewer could not deal with
certain fonts), because of the well-known problems in converting
Macintosh Word to PostScript, universal portability cannot be
guaranteed. Please notify the FITS Support Office by electronic mail
of any problems. The directory also contains a modified version of
this posting. An AAREADME.DOC file describes the contents of the
directory.  
	A SOFTWARE subdirectory contains a prototype for software in C 
that
will eventually validate FITS files, along with instructions. Because
this software is still under development, it should not be run before
reading the separate instructions file.  The current version investigates
required keywords for primary headers and prints sample data for
integer data arrays.  There is also C software to read and list the
headers of a FITS file.  Another file provides 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.  Be sure to use binary transfer for ftp access of FITS
test files.  Both the SOFTWARE and ERRTEST subdirectories include
AAREADME.DOC files describing their content. A modified version of
this posting is now in the main directory. 
 	Additional material can be obtained by anonymous ftp from the
National Radio Astronomy Observatory, from fits.cv.nrao.edu, in the
directory fits.  The documents subdirectory contains a number of
subdirectories.  A proposals subdirectory contain proposals, such as
the BINTABLE Binary Tables extension proposal, which is now under
consideration by the IAU FITS Working Group. A drafts subdirectory
contains drafts of designs not yet submitted, for example, a proposed
method for incorporating data compression under FITS.  The wcs
subdirectory contains material serving as the basis for continuing
discussion of world coordinates issues, some of which appears on this
newsgroup from time to time.  

	Printed copies of many of the documents listed above can be
obtained from the NOST Librarian. Printed or electronic copies of the
User's Guide and the NOST 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 NOST can be reached as follows: 

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

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

Telephone: +1-301-286-3575 8 a. m. - 5 p. m., U. S. Eastern Time
	If the Librarian is unavailable, a phone mail system takes the
call after four rings. 
	Please mention this posting in your request.

	Use the FITS office electronic mail address below for replies
or questions. It is monitored by other NOST staff members when I am
away from the office and provides a greater certainty of rapid
response. 

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

From fitsbits-request  Thu Aug 19 18:01:18 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["21875" "" "19" "August" "93" "20:54:47" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "671" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA10271; Thu, 19 Aug 93 18:01:18 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <warnock.745793687 at Hypatia>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!cs.umd.edu!skates.gsfc.nasa.gov!Hypatia!warnock
References: <9308181716.AA19559 at tetra.gsfc.nasa.gov>
From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: Identification of a FITS byte stream
Date: 19 Aug 93 20:54:47 GMT

pence at tetra.gsfc.nasa.gov (William Pence) writes:

>Archie Warnock wrote:
>I think it would be a good idea to 'strongly recommend' that all
>FITS writers should add a standard comment citing a reference to a FITS 
>definition document. This cannot be made manditory however without
>invalidating all the existing FITS files which don't have such a 
>comment, unless there is a grandfather clause that exempts all 
>existing FITS files.

Agreed - "strongly recommend" is good.

>What is the best reference to cite?  The old A&A Suppl. papers, which
>are somewhat out of date but are at least widely available in any
>Astronomical library?  Or the new NOST FITS definition document 
>which is much more complete, but may not be as easily accessable
>50 years from now when someone is trying to decifer a dusty FITS tape?
>Or both?

Yeah - that's a problem isn't it.  Forward referencing in the literature
is hard.  I think that the original A&A paper is probably enough of a
lef-up on the problem for starters (since it tells you something about
parsing the initial header), but I think more is probably better.  The
ultimate solution would be to get the NOST document into the refereed
literature somehow.

>Also, should it be recommended that this comment be located as near as
>possible to the beginning of the FITS file, to make it easy to spot?
>Presumable this comment would only be needed in the primary array, and
>there would be little reason to repeat it in every extension.

I don't think position is critical - we're doing this primarily for
machine parsing, rather for a human reading a dump.  And once is
probably sufficient.  Hmmm...

--
_______________________________________________________________________
-- Archie Warnock              Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                  "Unix --- JCL For The 90s"
-- NASA/GSFC                   Project STELAR: WAIS to do science

From fitsbits-request  Fri Aug 20 10:33:49 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1636" "Fri" "20" "August" "1993" "15:30:59" "GMT" "Pat Murphy" "pmurphy at cv3.CV.NRAO.EDU " nil "43" "Re: FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA13165; Fri, 20 Aug 93 10:33:49 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <PMURPHY.93Aug20103059 at orangutan.cv.nrao.edu>
Organization: National Radio Astronomy Observatory
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!pmurphy
References: <2507e4$etv at news.univ-rennes1.fr>
From: pmurphy at cv3.CV.NRAO.EDU (Pat Murphy)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: FITS -> GIF or JPEG or TIFF converter
Date: Fri, 20 Aug 1993 15:30:59 GMT

In article <2507e4$etv at news.univ-rennes1.fr>, rousself at univ-rennes1.fr (
  Frank ROUSSEL ) writes: 

FR> Does such a converter exist for Unix ?

Sort of.  Here's an excerpt:

orangutan_pmurphy<524> man fitstopgm

     fitstopgm(1)            (20 September 89)            fitstopgm(1)

     NAME
          fitstopgm - convert a FITS file into a portable graymap

     SYNOPSIS
          fitstopgm [-image N] [FITSfile]

     DESCRIPTION
          Reads a FITS file as input.  Produces a portable graymap as
          output.  The results may need to be flipped top for bottom;
          if so, just pipe the output through pnmflip -tb.

     OPTIONS
          The -image option is for FITS files with three axes.  The
          assumption is that the third axis is for multiple images,
          and this option lets you select which one you want.

You could do something like:

	fitstopgm <file> | pnmflip | pgmtoppm | ppmtogif

The pbmplus package is available at many fine archive sites, the nearest
to you is probably cnam.cnam.fr (pub/Archives/comp.sources.misc/pbmplus/)
according to xarchie.
				- Pat
--
==========================================================================
| Patrick P. Murphy, Ph.D.                Scientific Programming Analyst |
| National Radio Astronomy Observatory    Net:       pmurphy at nrao.edu    |
| 520 Edgemont Road                       Phone:     (804) 296-0372      |
| Charlottesville, VA 22903-2475          VoiceMail: (804) 980-5889      |
|      "I don't believe in the no-win scenario"  --- James T. Kirk       |
==========================================================================

From fitsbits-request  Fri Aug 20 12:05:49 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1003" "Fri" "20" "August" "1993" "15:21:10" "GMT" "Greg Hennessy" "gsh7w at fermi.clas.Virginia.EDU " nil "23" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA13372; Fri, 20 Aug 93 12:05:49 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <CC2DBA.Ep3 at murdoch.acc.Virginia.EDU>
Organization: University of Virginia
Path: cv3.cv.nrao.edu!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gsh7w
References: <9308181716.AA19559 at tetra.gsfc.nasa.gov> <warnock.745793687 at hypatia>
From: gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: Identification of a FITS byte stream
Date: Fri, 20 Aug 1993 15:21:10 GMT

Archie Warnock  writes:
#I don't think position is critical - we're doing this primarily for
#machine parsing, rather for a human reading a dump.  And once is
#probably sufficient.  Hmmm...

Err, I may have missed something, but I find it hard to imagine that a
computer program is going to care about the reference of the FITS
file. A grad student trying to figure out what is on the tape 10 years
later when the spectrometer that took the data no longer exists, and
the professor who took the data was not the observer, but the
collaborator of the observer *IS* going to find that information
useful. 

And yes, I actually had to do that task. Got it to work, although I
had to figure out that the file was not *really* fits, since it was
written in byte-swaped format to the tapes. VAXEN drive me crazy at
times. 

--
-Greg Hennessy, University of Virginia
 USPS Mail:     Astronomy Department, Charlottesville, VA 22903-2475 USA
 Internet:      gsh7w at virginia.edu  
 UUCP:		...!uunet!virginia!gsh7w

From fitsbits-request  Fri Aug 20 18:12:25 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["13865" "Fri" "20" "August" "93" "21:01:34" "GMT" "Daniel Briggs" "dbriggs at Mr-Hyde.aoc.nrao.edu " nil "490" "Re: FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA13574; Fri, 20 Aug 93 18:12:25 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <1993Aug20.210134.17910 at Mr-Hyde.aoc.nrao.edu>
Organization: National Radio Astronomy Observatory, Socorro NM
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!Mr-Hyde.aoc.nrao.edu!dbriggs
References: <2507e4$etv at news.univ-rennes1.fr> <PMURPHY.93Aug20103059 at orangutan.cv.nrao.edu>
From: dbriggs at Mr-Hyde.aoc.nrao.edu (Daniel Briggs)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: FITS -> GIF or JPEG or TIFF converter
Date: Fri, 20 Aug 93 21:01:34 GMT

In article <PMURPHY.93Aug20103059 at orangutan.cv.nrao.edu>
  pmurphy at nrao.edu (Pat Murphy) writes:
>In article <2507e4$etv at news.univ-rennes1.fr>, rousself at univ-rennes1.fr (
>  Frank ROUSSEL ) writes: 
>
>FR> Does such a converter exist for Unix ?
>
>Sort of....

I hacked on the pbmplus program fitstopgm, and added a few more options.
(Some generally useful, and one or several that are kind of obscure.)
Most important to the folks on this group is that it can handle floating
point FITS on machines whose native architecture support IEEE-754.
I *think* I sent it off to Jef for incorporation into the next release, but
I honestly can't remember.  Certainly I never heard back from him.

Anyway, here's what I did.  Feel free to mess with it some more.  If we
want to have a decent FITS->generic image translator widely available, *we*
are going to have to write it.  It's no fair to ask Jef to do so, when he
doesn't use FITS routinely.

-----fitstopgm.1-----
.TH fitstopgm 1 "21 June 93"
.IX fitstopgm
.SH NAME
fitstopgm - convert a FITS file into a portable graymap
.SH SYNOPSIS
.B fitstopgm
.RB [ -image
.IR N ]
.RB [ -noraw ]
.RB [ -scanmax ]
.RB [ -printmax ]
.RB [ -min
.IR f ]
.RB [ -max
.IR f ]
.RI [ FITSfile ]
.SH DESCRIPTION
Reads a FITS file as input.
.IX FITS
Produces a portable graymap as output.
The results may need to be flipped top for bottom; if so, just
pipe the output through
.B pnmflip -tb.
.IX pnmflip
This version of the program will accept integer FITS, and floating point
FITS if the host machine architecture is IEEE 754 compliant.
.SH OPTIONS
.PP
The
.B -image
option is for FITS files with three axes.
The assumption is that the third axis is for multiple images,
and this option lets you select which one you want.  Additional
axes will generate a warning message, but will otherwise be
ignored.
.PP
If the pbm package has been compiled with the RAWBITS option, the output
will be RAW PGM format.  The
.B -noraw
option forces the output to ASCII.
.PP
The program assumes that the input file has been scaled to allow for
maximum dynamic range, which is true for many FITS files.  If not,
the
.B -scanmax
option
forces the program to prescan the file and determine the most
appropriate scaling constants.
The
.B -printmax
option causes the program to print the minimum and maximum values
encountered and exit.  
A portion of the data range can
be selected with
the options 
.B -min
.I f
and
.B -max
.I f.
Data beyond this range will be clipped appropriately.
.PP
All flags can be abbreviated to their shortest unique prefix.
.SH REFERENCES
FITS stands for Flexible Image Transport System.  A full description
of the basic image format can be found in Astronomy & Astrophysics Supplement
Series 44 (1981), page 363.  The full standard, including the "Floating
Point Agreement for FITS" is available from the NASA/OSSA Office of
Standards and Technology.  The standards are also available for ftp
on the host nssdca.gsfc.nasa.gov.
.SH "SEE ALSO"
pgmtofits(1), pgm(5), pnmflip(1)
.SH AUTHOR
Copyright (C) 1989 by Jef Poskanzer.
.PP
Additional code contributed by Daniel Briggs
.\" Permission to use, copy, modify, and distribute this software and its
.\" documentation for any purpose and without fee is hereby granted, provided
.\" that the above copyright notice appear in all copies and that both that
.\" copyright notice and this permission notice appear in supporting
.\" documentation.  This software is provided "as is" without express or
.\" implied warranty.

-----fitstopgm.c-----
/* fitstopgm.c - read a FITS file and produce a portable graymap
 **
 ** Copyright (C) 1989 by Jef Poskanzer.
 **
 ** Permission to use, copy, modify, and distribute this software and its
 ** documentation for any purpose and without fee is hereby granted, provided
 ** that the above copyright notice appear in all copies and that both that
 ** copyright notice and this permission notice appear in supporting
 ** documentation.  This software is provided "as is" without express or
 ** implied warranty.
 **
 ** Hacked up version by Daniel Briggs  (dbriggs at nrao.edu)  20-Oct-92
 **
 ** Include floating point formats, more or less.  Will only work on
 ** machines that understand IEEE-754.  Added -scanmax -printmax
 ** -min -max and -noraw.  Ignore axes past 3, instead of error (many packages
 ** use pseudo axes).  Use a finite scale when max=min.  NB: Min and max
 ** are the real world FITS values (scaled), so watch out when bzer & bscale
 ** are not 0 & 1.  Datamin & datamax interpreted correctly in scaled case,
 ** and initialization changed to less likely values.  If datamin & max are
 ** not present in the header, the a first pass is made to determine them
 ** from the array values.
 */

#include "pgm.h"

/* Do what you have to, to get a sensible value here.  This may not be so */
/* portable as the rest of the program.  We want to use MAXFLOAT and */
/* MAXDOUBLE, so you could define them manually if you have to. */
#include <values.h>

struct FITS_Header {
  int simple;		/* basic format or not */
  int bitpix;		/* number of bits per pixel */
  int naxis;		/* number of axes */
  int naxis1;		/* number of points on axis 1 */
  int naxis2;		/* number of points on axis 2 */
  int naxis3;		/* number of points on axis 3 */
  double datamin;	/* min # (Physical value!) */
  double datamax;	/* max #     "       "     */
  double bzer;		/* Physical value = Array value*bscale + bzero */
  double bscale;
};

static void read_fits_header ARGS(( FILE* fp, struct FITS_Header* hP ));
static void read_card ARGS(( FILE* fp, char* buf ));
static void read_val ARGS(( FILE* fp, int bitpix, double* vp ));
     
void
main( argc, argv )
int argc;
char* argv[];
{
  FILE* ifp;
  gray* grayrow;
  register gray* gP;
  int argn, imagenum, image, row;
  register int col;
  gray maxval;
  double val, fmaxval, frmin, frmax, dmax, dmin, scale, t;
  int rows, cols, images;
  struct FITS_Header h;
  char* fits_name;
  char* usage = "[-image N] [-noraw] [-scanmax] [-printmax] [-min f] [-max f] [FITSfile]";

  int doscan = 0;
  int forceplain = 0;
  int forcemin = 0;
  int forcemax = 0;
  int printmax = 0;
  
  pgm_init( &argc, argv );
  
  argn = 1;
  imagenum = 1;
  
  while ( argn < argc && argv[argn][0] == '-' && argv[argn][1] != '\0' )
    {
      if ( pm_keymatch( argv[argn], "-image", 2 ) )
	{
	  ++argn;
	  if ( argn == argc || sscanf( argv[argn], "%d", &imagenum ) != 1 )
	    pm_usage( usage );
	}
      else if ( pm_keymatch( argv[argn], "-max", 3 ) )
	{
	  ++argn;
	  forcemax = 1;
	  if ( argn == argc || sscanf( argv[argn], "%lf", &frmax ) != 1 )
	    pm_usage( usage );
	}
      else if ( pm_keymatch( argv[argn], "-min", 3 ) )
	{
	  ++argn;
	  forcemin = 1;
	  if ( argn == argc || sscanf( argv[argn], "%lf", &frmin ) != 1 )
	    pm_usage( usage );
	}
      else if ( pm_keymatch( argv[argn], "-scanmax", 2 ) )
	doscan = 1;
      else if ( pm_keymatch( argv[argn], "-noraw", 2 ) )
	forceplain = 1;
      else if ( pm_keymatch( argv[argn], "-printmax", 2 ) )
	printmax = 1;
      else
	pm_usage( usage );
      ++argn;
    }
  
  if ( argn < argc )
    {
      fits_name = argv[argn];
      ifp = pm_openr( fits_name );
      ++argn;
    }
  else
    ifp = stdin;
  
  if ( argn != argc )
    pm_usage( usage );
  
  read_fits_header( ifp, &h );
  if (forcemin) h.datamin = frmin;
  if (forcemax) h.datamax = frmax;
  
  if ( ! h.simple )
    pm_error( "FITS file is not in simple format, can't read" );
  switch ( h.bitpix )
    {
    case 8:
      fmaxval = 255.0;
      break;
      
    case 16:
      fmaxval = 65535.0;
      break;
      
    case 32:
      fmaxval = 4294967295.0;
      break;
      
    case -32:
      fmaxval = MAXFLOAT;
      break;
      
    case -64:
      fmaxval = MAXDOUBLE;
      break;
      
    default:
      pm_error( "unusual bits per pixel (%d), can't read", h.bitpix );
    }
  if ( h.naxis != 2 && h.naxis != 3 )
    pm_message( "Warning: FITS file has %d axes", h.naxis );
  cols = h.naxis1;
  rows = h.naxis2;
  if ( h.naxis == 2 )
    images = 1;
  else
    images = h.naxis3;
  if ( imagenum > images )
    pm_error( "only %d image%s in this file",
	     images, images > 1 ? "s" : "" );
  maxval = min( fmaxval, PGM_MAXMAXVAL );
  if ( doscan || h.datamin == MAXDOUBLE || h.datamax == MAXDOUBLE )
    {
      /* OK, We have to scale this the hard way. */
      pm_message( "Scanning file for scaling parameters" );
      dmax = -fmaxval;
      dmin = fmaxval;
      for ( image = 1; image <= imagenum; ++image )
	{
	  for ( row = 0; row < rows; ++row)
	    {
	      for ( col = 0; col < cols; ++col)
		{
		  read_val (ifp, h.bitpix, &val);
		  if ( image == imagenum ) {
		    if ( val > dmax ) dmax = val;
		    if ( val < dmin ) dmin = val;
		  }
	        }
	    }
	  pm_close( ifp );
	  if (h.bscale < 0.0) {
	    t = dmax;
	    dmax = dmin;
	    dmin = t;
	  }
	  ifp = pm_openr( fits_name );
	  read_fits_header( ifp, &h );
	  h.datamin = forcemin ? frmin : dmin * h.bscale + h.bzer;
	  h.datamax = forcemax ? frmax : dmax * h.bscale + h.bzer;
	}
    }

  /* If printmax option is true, just print and exit. */
  /* For use in shellscripts.  Ex:                    */
  /* eval `fitstopgm -printmax $filename | \          */
  /*   awk '{min = $1; max = $2}\                     */
  /*         END {print "min=" min; " max=" max}'`    */
  if (printmax) {
    printf( "%lf %lf\n", h.datamin, h.datamax);
    pm_close( ifp );
    pm_close( stdout );
    exit( 0 );
  }

  /* Just in case we have a file with constant value. */
  if (h.datamax != h.datamin)
    scale = maxval / (h.datamax - h.datamin);
  else
    scale = 1.e10;

  grayrow = pgm_allocrow( cols );
  pgm_writepgminit( stdout, cols, rows, maxval, forceplain);
  for ( image = 1; image <= imagenum; ++image )
    {
      if ( image != imagenum )
	pm_message( "skipping image %d of %d", image, images );
      else if ( images > 1 )
	pm_message( "reading image %d of %d", image, images );
      for ( row = 0; row < rows; ++row)
	{
	  for ( col = 0, gP = grayrow; col < cols; ++col, ++gP )
	    {
	      read_val (ifp, h.bitpix, &val);
	      t = scale * ( val * h.bscale + h.bzer - h.datamin );
	      if (t < 0)
		*gP = (gray) 0;
	      else if (t > maxval)
		*gP = (gray) maxval;
	      else
		*gP = (gray) t;
	    }
	  if ( image == imagenum )
	    pgm_writepgmrow( stdout, grayrow, cols, maxval, forceplain );
	}
    }
  pm_close( ifp );
  pm_close( stdout );
  
  exit( 0 );
}

/*
 ** This code will deal properly with integers, no matter what the byte order
 ** or integer size of the host machine.  Sign extension is handled manually
 ** to prevent problems with signed/unsigned characters.  Floating point
 ** values will only be read properly when the host architecture is IEEE-754
 ** conformant.  If you need to tweak this code for other machines, you might
 ** want to snag a copy of the FITS documentation from nssdca.gsfc.nasa.gov
 */

static void
  read_val (fp, bitpix, vp)
FILE *fp;
int bitpix;
double *vp;

{
  int i, ich, ival;
  long int lval;
  unsigned char c[8];
  
  switch ( bitpix )
    {
      /* 8 bit FITS integers are unsigned */
    case 8:
      ich = getc( fp );
      if ( ich == EOF )
	pm_error( "EOF / read error" );
      *vp = ich;
      break;
      
    case 16:
      ich = getc( fp );
      if ( ich == EOF )
	pm_error( "EOF / read error" );
      c[0] = ich;
      ich = getc( fp );
      if ( ich == EOF )
	pm_error( "EOF / read error" );
      c[1] = ich;
      if (c[0] & 0x80)
	ival = ~0xFFFF | c[0]<<8 | c[1];
      else
	ival = c[0]<<8 | c[1];
      *vp = ival;
      break;
      
    case 32:
      for (i=0; i<4; i++) {
	ich = getc( fp );
	if ( ich == EOF )
	  pm_error( "EOF / read error" );
	c[i] = ich;
      }
      if (c[0] & 0x80)
	lval = ~0xFFFFFFFF |
	  c[0]<<24 | c[1]<<16 | c[2]<<8 | c[3];
      else
	lval = c[0]<<24 | c[1]<<16 | c[2]<<8 | c[3];
      *vp = lval;
      
    case -32:
      for (i=0; i<4; i++) {
	ich = getc( fp );
	if ( ich == EOF )
	  pm_error( "EOF / read error" );
	c[i] = ich;
      }
      *vp = *( (float *) c);
      break;
      
    case -64:
      for (i=0; i<8; i++) {
	ich = getc( fp );
	if ( ich == EOF )
	  pm_error( "EOF / read error" );
	c[i] = ich;
      }
      *vp = *( (double *) c);
      break;
      
    default:
      pm_error( "Strange bitpix in read_value" );
    }
}

static void
  read_fits_header( fp, hP )
FILE* fp;
struct FITS_Header* hP;
{
  char buf[80];
  int seen_end;
  int i;
  char c;
  
  seen_end = 0;
  hP->simple = 0;
  hP->bzer = 0.0;
  hP->bscale = 1.0;
  hP->datamin = MAXDOUBLE;
  hP->datamax = MAXDOUBLE;
  
  while ( ! seen_end )
    for ( i = 0; i < 36; ++i )
      {
	read_card( fp, buf );
	
	if ( sscanf( buf, "SIMPLE = %c", &c ) == 1 )
	  {
	    if ( c == 'T' || c == 't' )
	      hP->simple = 1;
	  }
	else if ( sscanf( buf, "BITPIX = %d", &(hP->bitpix) ) == 1 );
	else if ( sscanf( buf, "NAXIS = %d", &(hP->naxis) ) == 1 );
	else if ( sscanf( buf, "NAXIS1 = %d", &(hP->naxis1) ) == 1 );
	else if ( sscanf( buf, "NAXIS2 = %d", &(hP->naxis2) ) == 1 );
	else if ( sscanf( buf, "NAXIS3 = %d", &(hP->naxis3) ) == 1 );
	else if ( sscanf( buf, "DATAMIN = %lf", &(hP->datamin) ) == 1 );
	else if ( sscanf( buf, "DATAMAX = %lf", &(hP->datamax) ) == 1 );
	else if ( sscanf( buf, "BZERO = %lf", &(hP->bzer) ) == 1 );
	else if ( sscanf( buf, "BSCALE = %lf", &(hP->bscale) ) == 1 );
	else if ( strncmp( buf, "END ", 4 ) == 0 ) seen_end = 1;
      }
}

static void
  read_card( fp, buf )
FILE* fp;
char* buf;
{
  if ( fread( buf, 1, 80, fp ) == 0 )
    pm_error( "error reading header" );
}

-- 
| Daniel Briggs  (dbriggs at nrao.edu)                      |  USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |      DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        | 
Support the League for Programming Freedom   (info from lpf at uunet.uu.net)

From fitsbits-request  Sat Aug 21 11:54:45 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["890" "Sat" "21" "August" "1993" "15:34:14" "GMT" "David Robinson" "drtr at mail.ast.cam.ac.uk " nil "19" "Re: FITS -> GIF or JPEG or TIFF converter" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA14868; Sat, 21 Aug 93 11:54:45 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <1993Aug21.153414.512 at infodev.cam.ac.uk>
Organization: Institute of Astronomy, Cambridge
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!uknet!pavo.csi.cam.ac.uk!cast0.ast.cam.ac.uk!drtr
References: <2507e4$etv at news.univ-rennes1.fr>
From: drtr at mail.ast.cam.ac.uk (David Robinson)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: FITS -> GIF or JPEG or TIFF converter
Date: Sat, 21 Aug 1993 15:34:14 GMT

12345678901234567890123456789012345678901234567890123456789012345678901234567890
In article <2507e4$etv at news.univ-rennes1.fr>, rousself at univ-rennes1.fr
( Frank ROUSSEL ) writes:
|> Does such a converter exist for Unix ?
|> Thanks

The xv package (current version 3.00a, archie search for xv-3.00a.tar.Z)
supports many formats, including GIF, PBM, JPEG, TIFF and PostScript. The
current version does not support FITS by default. However, I have patched it to
support reading and writing of FITS files. The patches supports all BITPIX
values, and do *not* assume that the host has IEEE floating point. It supports
three dimensional (NAXIS=3) FITS files by treating then as containing
NAXIS3 sets of two-dimensional images.

The patches can be anonymously ftp'd from ftp-hst.ast.cam.ac.uk by fetching the
file pub/software/xv-patches/FITS-v2.tar.Z.

David Robinson. (drtr at mail.ast.cam.ac.uk)


From fitsbits-request  Sat Aug 21 16:54:06 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["10952" "" "21" "August" "93" "20:29:54" "GMT" "Archie Warnock" "warnock at Hypatia.gsfc.nasa.gov " nil "233" "Re: Identification of a FITS byte stream" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA14922; Sat, 21 Aug 93 16:54:06 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <warnock.745964994 at Hypatia>
Organization: NASA Goddard Space Flight Center -- InterNetNews site
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!sdd.hp.com!saimiri.primate.wisc.edu!ames!skates.gsfc.nasa.gov!Hypatia!warnock
References: <9308181716.AA19559 at tetra.gsfc.nasa.gov> <warnock.745793687 at hypatia> <CC2DBA.Ep3 at murdoch.acc.Virginia.EDU>
From: warnock at Hypatia.gsfc.nasa.gov (Archie Warnock)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: Identification of a FITS byte stream
Date: 21 Aug 93 20:29:54 GMT

gsh7w at fermi.clas.Virginia.EDU (Greg Hennessy) writes:
>Archie Warnock  writes:
>#I don't think position is critical - we're doing this primarily for
>#machine parsing, rather for a human reading a dump.  And once is
>#probably sufficient.  Hmmm...

>Err, I may have missed something, but I find it hard to imagine that a
>computer program is going to care about the reference of the FITS
>file. A grad student trying to figure out what is on the tape 10 years

Urp...  That's what I meant.  No really.  Would you believe it's an
obscure form of dyslexia?  No?  How about temporary insanity?  Maybe
it's not so temporary...

Anyway, what I _meant_ is that we're _NOT_ talking about machine
parsing.  Sigh...  I need another vacation to recover from my
vacation... 


>had to figure out that the file was not *really* fits, since it was
>written in byte-swaped format to the tapes. VAXEN drive me crazy at
>times. 

You just wouldn't believe the bizarre stuff we got submitted to
International Halley Watch with the claim that it was FITS.  It's not
nearly as universally used as we'd like to believe.

I got a standard VMS ASCII file (yep - variable length records, the
whole works) from one submitter claiming it was FITS - well, he could
type it out and it _looked_ like the samples in the papers...
--
_______________________________________________________________________
-- Archie Warnock              Internet:  warnock at hypatia.gsfc.nasa.gov
-- Hughes STX                  "Unix --- JCL For The 90s"
-- NASA/GSFC                   Project STELAR: WAIS to do science

From fitsbits-request  Mon Aug 23 12:13:59 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["3967" "Mon" "23" "August" "93" "12:12:58" "EDT" "William Pence" "pence at tetra.gsfc.nasa.gov " nil "84" "FITSIO V3.401 is available" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA17569; Mon, 23 Aug 93 12:13:59 EDT
Return-Path: <pence at tetra.gsfc.nasa.gov>
Message-Id: <9308231612.AA00464 at tetra.gsfc.nasa.gov>
From: pence at tetra.gsfc.nasa.gov (William Pence)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU, wgas at hypatia.gsfc.nasa.gov
Subject: FITSIO V3.401 is available
Date: Mon, 23 Aug 93 12:12:58 EDT

                        FITSIO - Version 3.401
                           23 August 1993

A new release of the FITSIO subroutine library, version 3.401, is now
available.  This new version contains a number of significant new
features as described below.  This new version is upwardly compatible
with the previous versions, therefore all existing programs which use
FITSIO should still work without any modification.

For those unfamiliar with FITSIO, it is a full-featured yet simple to use
Fortran subroutine interface for reading and writing files in FITS
format.  It runs on most common types of computers and supports FITS
ASCII tables, binary tables, and image extensions as well as simple
primary array FITS files.

The FITSIO software, documentation, and example programs can be obtained via
anonymous ftp from (note the new address compared to previous releases):

        legacy.gsfc.nasa.gov   (128.183.8.233)

Type the following commands from the ftp prompt to copy any desired files:

        ftp>  user anonymous
        Password:                 [type your username as a password]
        ftp>  cd software/fitsio  [to move to the fitsio subdirectory]
        ftp>  ls                  [to see a list of the available files]
        ftp>  get README          [contains latest information about FITSIO]
        ftp>  get fitsio.doc      [complete user documentation]
        ftp>  get fitsio.tex      [Latex version of the documentation]
        ftp>  get ...             [get any additional desired files]
                                  [  Be sure to switch to binary mode in ftp ]
                                  [  when getting the .tar files or the  ]
                                  [  FITS format files.  ]
        ftp>  quit

A brief summary of the the more important changes introduced with this
release are described below.  For more details on the changes made to
this version, see the 'release.doc' file in the FITSIO distribution
directory.

  NEW PORTS:
     - fitsio is now supported on IBM AIX operating systems and
       DEC Alpha OSF/1 and Alpha OpenVMS machines.

  NEW SUBROUTINES:
     - to modify the name of an existing keyword in a FITS header
     - to return the number of the current header-data-unit which is open
     - to read or write keyword values in 'triple precision' F28.16 format
     - to insert a new keyword at a specified location in a FITS header
     - to read a subset of a multidimensional primary array or subset of 
       an N-dimensional vector array column in a binary table.  

  ENHANCEMENTS:

  - the subroutines to write COMMENT or HISTORY keywords were enhanced
    to automatically write multiple keywords if the input string is
    longer than 70 characters.

  - Implemented a local convention for reading and writing character
    string keywords which are too long to fit in a single
    keyword record.  The long keyword values are continued over multiple 
    comment keywords.

  - enhanced the TEST1.FOR and TEST2.FOR programs to perform a
    more extensive test of the FITSIO interface functionality.

  - several efficiency improvements have been implemented

  - added error checking to detect attempts to move to an illegal HDU
    number, (either negative, or greater than the internal buffer size).

  - expanded the documentation in fitsio.doc, including a new section
    on suggestions for optimizing the I/O performance of FITSIO programs.

  - 12 reported bugs were fixed.  These problems were relatively
    obscure and should not have affected many users.  

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

From fitsbits-request  Mon Aug 23 17:51:06 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1505" "" "23" "August" "1993" "16:58:32" "GMT" " Frank ROUSSEL " "rousself at univ-rennes1.fr " nil "24" "FITS -> ... converter (2)" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA17705; Mon, 23 Aug 93 17:51:06 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <25asvp$mg2 at news.univ-rennes1.fr>
Organization: CRI Universite' de Rennes 1 - FR
Path: cv3.cv.nrao.edu!uvaarpa!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!zaphod.crihan.fr!news.univ-rennes1.fr!univ-rennes1.fr!rousself
From: rousself at univ-rennes1.fr ( Frank ROUSSEL )
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITS -> ... converter (2)
Date: 23 Aug 1993 16:58:32 GMT

Thank you for all your responses !

At 'julian.uwo.ca:/pub/unix/X-windows/X.V11R5/contrib/clients/pbmplus',
i've retrieved a X11R5 compiled version of fitstopgm, but i've not found
one of pgmtoppm. Does anyone know where i can get one, please ?

Thanks in advance
---------------------------------------------------------------------------------
   _______       _______       ________   | Firstname: Frank
  /______/|     /______/\     /_______/|  | Lastname : ROUSSEL
 / ______|/    /  ____ \/|    |__   __|/  | E-mail: rousself at univ-rennes1.fr
/ /|           | |____| |/       | ||     | Telephone: + 33 99 83 26 10
| ||           |  __  __/        | ||     | 
| |\______     | || \ \\       __| ||__   | Address: 175, rue Belle Epine
\ \______/|    | ||  \ \\     /__| |/_/|  | CityStateZip: 35510
 \_______|/    |_|/   \_\|    |_______|/  | Cityname: CESSON SEVIGNE
    Centre de Ressources Informatiques    | Country: FRANCE
---------------------------------------------------------------------------------
---------- Science without conscience is only soul's ruin (Rabelais) ------------
---------------------------------------------------------------------------------
- Signed: The responsible of ASTROGOF project at Rennes' University of France   -
- who contributes to the development of CRI-CICB Gopher's server by maintaining -
-an astronomical anonymous ftp server 'ftp.univ-rennes1.fr' in /pub/Images/ASTRO-
---------------------------------------------------------------------------------

From fitsbits-request  Mon Aug 23 21:45:48 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1556" "Tue" "24" "August" "1993" "02:42:56" "GMT" "Pat Murphy" "pmurphy at cv3.CV.NRAO.EDU " nil "34" "Re: FITS -> ... converter (2)" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA18039; Mon, 23 Aug 93 21:45:48 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <PMURPHY.93Aug23214256 at orangutan.cv.nrao.edu>
Organization: National Radio Astronomy Observatory
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!pmurphy
References: <25asvp$mg2 at news.univ-rennes1.fr>
From: pmurphy at cv3.CV.NRAO.EDU (Pat Murphy)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: FITS -> ... converter (2)
Date: Tue, 24 Aug 1993 02:42:56 GMT

In article <25asvp$mg2 at news.univ-rennes1.fr>, rousself at univ-rennes1.fr (
   Frank ROUSSEL ) writes: 

FR> At 'julian.uwo.ca:/pub/unix/X-windows/X.V11R5/contrib/clients/pbmplus',
FR> i've retrieved a X11R5 compiled version of fitstopgm, but i've not found
FR> one of pgmtoppm. Does anyone know where i can get one, please ?

Hmm, I didn't know that the pbmplus package needed the X11R5 libraries.
Most of them are simple filters to convert one file format to another.

Anyways, checking a well known archive (ftp.uu.net) reveals the
following:

200-91/12/11 00:00   678238 pub/window-sys/X/contrib/pbmplus10dec91.tar.Z

(So maybe it does need X11?  Hmm again).  I just grabbed this, and
checked it:

orangutan_pmurphy<507> zcat pbmplus* | tar tvf - | grep pgmtoppm
rw-r--r--1544/20   3431 Dec 10 19:56 1991 pbmplus10dec91/ppm/pgmtoppm.c
rw-r--r--1544/20   2259 Dec 10 19:56 1991 pbmplus10dec91/ppm/pgmtoppm.1

so it is in this particular distribution.  Perhaps the ftp site you used
only had a partial implementation.

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

From fitsbits-request  Tue Aug 24 07:56:25 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["159" "Tue" "24" "August" "1993" "04:26:45" "GMT" "Ted Matsumura" "tedm at tsoft.net " nil "5" "sidereal time progs." "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA19723; Tue, 24 Aug 93 07:56:25 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <CC8xoM.5o3 at tsoft.net>
Organization: TSoft BBS and Public Access Unix, +1 415 969 8238
Path: cv3.cv.nrao.edu!uvaarpa!concert!gatech!howland.reston.ans.net!spool.mu.edu!sgiblab!tsoft!tedm
From: tedm at tsoft.net (Ted Matsumura)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: sidereal time progs.
Date: Tue, 24 Aug 1993 04:26:45 GMT

I am looking for a program which converts UT to Local Sidereal time.  I 
would be grateful for any references to such, which work on the IBM PC.
Thanks.
 
Ted

From fitsbits-request  Tue Aug 24 08:50:49 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["286" "Tue" "24" "August" "1993" "13:49:33" "+0100" "P.T.Wallace" "ptw at rlstar.bnsc.rl.ac.uk " nil "7" "UT to ST" "^From:" nil nil "8"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA19744; Tue, 24 Aug 93 08:50:49 EDT
Return-Path: <ptw at rlstar.bnsc.rl.ac.uk>
Message-Id: <9308241250.AA19738 at fits.cv.nrao.edu>
Reply-To: ptw at star.rl.ac.uk
X-Vms-To: SMTP%"fitsbits at fits.cv.nrao.edu"
X-Vms-Cc: PTW
From: ptw at rlstar.bnsc.rl.ac.uk (P.T.Wallace)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: UT to ST
Date: Tue, 24 Aug 1993 13:49:33 +0100

Ted Matsumara asks for a program to convert UT to ST.  I have
independently e-mailed him a copy of the relevant SLALIB
routines.  Anyone who would like further details of the (mainly
positional astronomy) SLALIB library can contact me directly.

Patrick Wallace
Starlink Project Manager

From fitsbits-request  Tue Aug 31 17:55:25 1993
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA07271; Tue, 31 Aug 93 17:55:25 EDT
Return-Path: <pence at tetra.gsfc.nasa.gov>
Message-Id: <9308312154.AA20977 at tetra.gsfc.nasa.gov>
From: pence at tetra.gsfc.nasa.gov (William Pence)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Cc: pence at tetra.gsfc.nasa.gov
Subject: FITS Coordinate Keywords
Date: Tue, 31 Aug 93 17:54:26 EDT

This note describes the 3 different sets of coordinate system keywords
that the HEASARC proposes to use within it's FITS files.  One of these
is the standard set of celestial coordinate system keywords that has
already been widely used for FITS images in the primary array, or in
IMAGE extensions.  The other 2 sets of coord. system keywords are used
when the image information is expressed in a FITS binary table.  Two
different sets of keywords are needed because sometimes the array
coordinate values are explicitly given in the table, but in other cases
the array coordinate is only implicitly given by the position of the
pixel within the multidimensional array (as is the case in a FITS
primary array).  Any comments, criticisms, or suggestions about these
proposed sets of keywords are welcome.

---------------------------------------------------------------------------
A.  Possible FITS Image Representations

There are three different ways (at least) of representing an image
in a FITS file, and each way requires a slightly different set
of keywords to define the coordinate system in the image.  The
three ways of representing an image are  (for simplicity, the
image is assumed to be a 2-D array. but this discussion can
be applied to an array with any number of dimensions):

     1)  as a 2-D array in the FITS primary array (or
         in an IMAGE extension).

     2)  as a 2-D array in a single element of BINTABLE
         extension

     3)  as a list of pixels in a BINTABLE extension, where the X and Y
         coordinates and the pixel intensity are given in 3 separate
         columns of the table.

Note that the 3rd method is qualitively different from the first 2 in
that the pixel coordinates are explicitly given in the table.  In the
first 2 cases the pixel coordinates are only implied by the location of
the pixel within the array.  This difference results in a significant
difference in the way the coordinate keywords are to be interpreted.

B.  Coordinate System Keywords.

The three different sets of coordinate system keywords are summarized
in the following table and are described in more detail in the
following sections:


               PRIMARY ARRAY    BINTABLE ARRAY    TABLE LIST
               --------------   --------------    ----------
Axis Type        CTYPEm            mCTYPnnn        TCTYPnnn
Ref. Pixel       CRPIXm            mCRPXnnn        TCRPXnnn
Ref. Value       CRVALm            mCRVLnnn        TCRVLnnn
Pixel Increment  CDELTm             -----          TCDLTnnn
Coord Matrix     CDi_j             i_jCDnnn         -----
Axis Units       CUNITm            mCUNInnn        TCUNInnn

    Notes:   nnn = integer table column number
             m   = integer array axis number
             i_j = pair of integer array axis numbers

1.  Primary Array Coordinate Keywords

All the keywords listed here, except for the last CUNIT keyword,
have been widely used in the FITS world and form the basis for
the 2 other sets of derived keywords.  The CUNIT keyword has been
added for generality in cases where the axis units are not already
implied by the CTYPE value.

2.  BINTABLE Array Coordinate Keywords

In this case the image is represent by a vector column in a Binary Table.
The TDIMnnn keyword gives the number and size of the array axes.  The keyword
usage is best explained by example where a 10 x 20 image is in
column 2 of the binary table:

TFORM2  = '200J'         / this is a 200 element vector of I*4 values
TDIM2   = '(10,20)'      / a 2-D array  10 x 20
1CTYP2  = 'RA---TAN'
2CTYP2  = 'DEC--TAN'
1CRPX2  =             5.0
2CRPX2  =            10.0
1CRVL2  =           45.83
2CRVL2  =           63.57
1_1CD2  =    -0.002777777
2_2CD2  =     0.002777777
1CUNI2  = 'deg     '
2CUNI2  = 'deg     '

Note that only the 2 diagonal terms of the full CD matrix are given since
the other terms are zero.  Hopefully the meaning of these keywords
is obvious by analogy with the primary array coordinate keywords.

(Note:  William Thompson has proposed a different set of keywords,
TDESCnnn, TRPIXnnn, TRVALnnn, TDELTnnn, which give values for
all the axes in single string, e.g.,

TRPIX2   = '(5.0,10.0)'

We decided not to use this convention because the string values can
in principle become very long, exceeding the maximum length of 
as single keyword, and because it is more complicated having to deal
with a whole array of values rather than just reading or writing
a single value per keyword).

3.  Table List Coordinate Keywords.

In this case the image is not represented as an array, but instead each
pixel (or perhaps only each non-zero pixel) is listed separately on
multiple rows of a FITS table.  Each row has a column for the X
coordinate of the pixel, the Y coordinate, and a column for the
intensity of the pixel value. (If the table just represents a list of
recorded events, such as photon detections, then the intensity column
may be absent).  The coordinate keywords in this case are understood to
be applied to the _value_ in the column, and not to the _position_ of
the value in an array as is the case in the other 2 types of FITS image
representation.  To give a concrete example, the 10 x 20 array in the
previous example could be represented as 200 rows in a table with 3
columns 'X', 'Y', and 'Value'.  The relevant coordinate keywords would
then be:

TCTYP1  = 'RA---TAN'
TCTYP2  = 'DEC--TAN'
TCRPX1  =           5.0
TCRPX2  =          10.0
TCRVL1  =         45.83
TCRVL2  =         63.57
TCDLT1  =  -0.002777777
TCDLT2  =   0.002777777
TCUNI1  = 'deg     '
TCUNI2  = 'deg     '

C.  Summary

These 3 sets of keywords will probably be widely used within the FITS 
files generated by the HEASARC.  We would appreciate any comments
on this usage from the rest of the FITS community.