From fitsbits-request  Thu Oct  1 02:50:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1542" "Thu" "1" "October" "92" "05:51:27" "GMT" "Daniel Briggs" "dbriggs at zia.aoc.nrao.edu " nil "29" "Re: FITS to GIF Image Conversion?" "^From:" nil nil "10"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA14866; Thu, 1 Oct 92 02:50:59 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <1992Oct1.055127.18231 at zia.aoc.nrao.edu>
Organization: National Radio Astronomy Observatory, Socorro NM
Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!umn.edu!lynx!zia.aoc.nrao.edu!dbriggs
References: <1992Sep29.043951.13504 at news.iastate.edu> <193 at neftis.CSS.GOV>
From: dbriggs at zia.aoc.nrao.edu (Daniel Briggs)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: FITS to GIF Image Conversion?
Date: Thu, 1 Oct 92 05:51:27 GMT

In article <193 at neftis.CSS.GOV>
  stevem at neftis.CSS.GOV (Steve Masters) writes:
>In article <1992Sep29.043951.13504 at news.iastate.edu> F1.DAO at isumvs.iastate.edu (David Oesper) writes:
>>Is there a FITS to GIF conversion program available for the IBM or
>>Macintosh?
>
>The PBMPLUS suite of programs can get you from FITS to GIF.  I believe
>there is a port for the IBM-PC...perhaps others on the net can verify
>this.

Well, the FITS reader built into the PBM+ package is very primitive.  I
have a slightly enhanced version that I wrote for my own purposes.  In
particular, it handles floating point values for machines which use
IEEE-754, (I think that the 80x87 hardware uses this, so unless the byte
order is screwed up, it might work on a PC with hardware floating point.)
I added a prescan for scaling constants, in the absence of DATAMIN &
DATAMAX, forceable min and max, and cleaned up the scaling code, which was
incorrect for non-identity BZER & BSCALE.

I make no claim that this code is suitable for any purpose other than that
for which I wrote it.  Eventually I'll get around to sending it back to Jef,
but I wanted to see if routine use turned up any more problems.  However, if
anyone wants the code now, I'll send it to them.

-- 
| 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 league at prep.ai.mit.edu)

From fitsbits-request  Thu Oct  1 13:25:45 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["873" "Thu" "1" "October" "1992" "16:49:00" "GMT" "301" "landsman at stars.gsfc.nasa.gov (Wayne Landsman -286-3625)" nil "22" "Re: triple precision keywords" "^From:" nil nil "10"])
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA15637; Thu, 1 Oct 92 13:25:45 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
Message-Id: <1OCT199212490103 at stars.gsfc.nasa.gov>
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!spool.mu.edu!agate!ames!nsisrv!stars.gsfc.nasa.gov!landsman
References: <pence.717873310 at heawk1>
From: landsman at stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625)
Sender: fitsbits-request at fits.CV.NRAO.EDU
To: fitsbits at fits.CV.NRAO.EDU
Subject: Re: triple precision keywords
Date: Thu, 1 Oct 1992 16:49:00 GMT

In article <pence.717873310 at heawk1>, pence at heawk1.gsfc.nasa.gov (William Pence) writes...
> 

>In principle there is no reason that this information could not all
>be expressed in a single keyword value, like:
> 
>MJD     =      48043.8797453703700742 /  MJD

    My current IDL FITS reader takes the NOST manual literally.   It
only extracts the 20 characters in columns 11-30 to determine the FITS
keyword value.    Any characters in columns 31-50 are interpreted as being
the imaginary part of a complex number.

        My suggestion would be to express this value as a string.

MJD     =      '48043.8797453703700742' /  MJD

       This would guarentee that all FITS readers preserve the full precision.
The calling program could then parse the string into its integer plus 
fractional component.

--Wayne Landsman                        landsman at stars.gsfc.nasa.gov

From bschlesinger at nssdca.gsfc.nasa.gov Fri Oct  2 11:55:05 1992
Newsgroups: sci.astro.fits
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Subject: Re: triple precision keywords
Summary: Fixed format is required only for mandatory keywords
News-Software: VAX/VMS VNEWS 1.41    
Keywords: fixed format, double precision  
Nntp-Posting-Host: nssdca.gsfc.nasa.gov
Organization: NASA - Goddard Space Flight Center
Date: Fri, 2 Oct 1992 15:38:00 GMT

In article <1OCT199212490103 at stars.gsfc.nasa.gov>, landsman at stars.gsfc.nasa.gov (Wayne Landsman (301)-286-3625) writes...

>    My current IDL FITS reader takes the NOST manual literally.   It
>only extracts the 20 characters in columns 11-30 to determine the FITS
>keyword value.    Any characters in columns 31-50 are interpreted as being
>the imaginary part of a complex number.
> 

This requirement applies only to fixed format.  The fixed format is
required only for values of mandatory keywords.  (At present, there
are no mandatory keywords with floating point values.)  For other
keyword values, it is recommended but not required.  See FITS Paper I,
which says "recommended, and partly required."  This language is
interpreted in 5.3.1 of the NOST standard by saying, "The fixed format
is required for values of mandatory keywords and recommended for all
others."  A well-recognized problem is that columns 11-30 do not
contain enough space to express the full precision of a double
precision floating point number.  The most common, but not standard or
required solution, is to extend the value beyond column 30.  A number
of proposed designs reviewed by the FITS office use this solution.  A
FITS reader that assumes that values of standard optional keywords or
user-defined keywords end in column 30 will not extract correct values
for some user-defined keywords in these data sets. 

Incidentally, EVERYBODY should be certain that their copy of the NOST
Standard is current.  The most recent version is 0.3b.  Some
misunderstandings have arisen because users are referring to 
superseded versions.

				Barry Schlesinger
				NOST FITS Support Office

From fitsbits-request  Mon Oct  5 10:05:44 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA21121; Mon, 5 Oct 92 10:05:44 EDT
Resent-Date:         Mon, 05 Oct 92 14:12:12 ITA
Resent-From: fitsbits-request
Resent-Message-Id: <9210051405.AA21121 at fits.cv.nrao.edu>
Return-Path: < at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET>
Message-Id: <9210051405.AA21114 at fits.cv.nrao.edu>
Date:         Mon, 05 Oct 92 14:12:12 ITA
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Subject:      Re: triple precision keywords
To: fitsbits at fits.CV.NRAO.EDU
In-Reply-To:  Message of Wed, 30 Sep 1992 17:15:10 GMT from
	<pence at heawk1.gsfc.nasa.gov>
X-Acknowledge-To: <EXOSAT%IMISIAM.BITNET at vm.cnuce.cnr.it>
Resent-Sender: Lucio Chiappetti <EXOSAT%IMISIAM.BITNET at vm.cnuce.cnr.it>
Sender: fitsbits-request at fits.CV.NRAO.EDU

On Wed, 30 Sep 1992 17:15:10 GMT  <pence at heawk1.gsfc.nasa.gov> said:
>
>Here at the HEASARC we often need to express keyword values which have
>more significant figures than can be stored in a double precision

  I actually wonder how this is SPECIFICALLY related to the example of
  MJD discussed below, or is really general.

>A common example of this problem is the Modified Julian Date
>which has a value something like 48043.8797453703700742

  I am inclined to think this is somehow related to the need of expressing
  time quantities like this.
  What I believe is needed is a way of defining some "compound" or "non-
  primitive" data types. By non-primitive I mean they should go beyond the
  usual CHARACTER, INTEGER, REAL and DOUBLE PRECISION supported by FITS.
  I raised this point already in a previous posting.
  In my view this concerns BOTH header keywords AS WELL AS data quantities
  (e.g. columns in binary tables).
  The sort of data types I am thinking of are quantities like :

  ANGLE   :  an angle in degrees, expressed e.g. as a DOUBLE PRECISION
             floating point number (but liable to be displayed as
             ddd:mm:ss.ff... and/or read as an array of ddd mm ss etc.)
  HANGLE  :  an angle in hours, possibly stored as the previous one,
             but liable to be displayed as hh:mm:ss.ff (with an implicit
             multiplication/division by 15 whenever needed)
  DATE    :  a quantity liable to be displayed as YYYY-Mon-DD (or YYYY-MM-DD
             or DD-MM-YYYY or MM-DD-YYYY according to whatever European or
             US or other form ... I personally prefer YYYY-MM-DD because it
             is simpler to sort). This quantity is likely to be more used
             in headers (e.g. to time stamp a file) than in data areas.
             However it might be worthwhile to represent it natively as
             a numeric quantity on which one can perform arithmetic operations.
             Any choice of a running count of days since an arbitrary zero
             is good, so IAU MJDs are a reasonable choice.
             Since one is interested only at a precision at the day level
             here, an INTEGER*4 is sufficient (using MJD instead of JD is
             preferred)
  DATETIME : a quantity liable to be displayed as YYYY-MM-DD-hh:mm:ss
             that is, similar to the previous one in usage, but with a
             precision at the level of seconds.
             Again more likely to be used in headers than in data areas.
             A running count of seconds since an arbitrary zero, expressed
             as an INTEGER*4, is good. I would recommend using seconds since
             1 Jan 1970 - which is what most Unix systems do - and which
             will cover about 68 years since then.

  TIME :     here is where I am in trouble. I want to express times with
             an arbitrarily high precision (say 1 ms or less). This is
             more the case of a column in a binary table (say, representing
             the time of a bin in a time profile, or the arrival time of a
             photon).
             I am very reluctant to renounce the usage of traditional data
             types, namely either INTEGER*4 or DOUBLE PRECISION.
             One way to cut out the number of significant figures needed is
             therefore to subtract a standard offset from the values.
             I would be personally inclined to use a representation like
             the following :

          -  time in an arbitrary unit (this most likely will be either a
             negative power of 2, 2**-N seconds, in an INTEGER quantity, or
             a decimal fraction like 1 ms, 10 ms, 0.1 ms in a DOUBLE PRECISION
             quantity) since 0 UT of the day containing the first bin or
             first photon of the dataset. This is the quantity stored as
             "data".
          -  a keyword in the header will define the time units (e.g. a
             real number as a fraction of seconds)
          -  another keyword in the header will define the reference time
             corresponding to "0" units, this could be a quantity of type
             DATETIME as above

             In general one does not need the full range of figures when
             doing processing, nor the units to be seconds (if one is doing
             a Fourier transform, one would anyhow subtract the time of the
             first bin, and one would have a power spectrum vs a frequency
             in 1/timeunit instead of Hz), but just when displaying the data
             and in such case one can do the conversion using the info in
             the header keywords

>Currently, we  express this number as 2 separate
>This however has several disadvantages:
>	- it requires 2 keywords = 160 bytes to express the value

  Ah ... sorry Bill. This is the usual "FITS as storage system vs FITS as
  transport system"  ... of course using a native internal representation
  for local storage will allow a more compact representation than FITS
  allows .... while for transport one can gladly spare 160 bytes

>	- it clutters up the header with extra keywords which makes it
>          more difficult for people to read
>In principle there is no reason that this information could not all
>be expressed in a single keyword value, like:
>
>MJD     =      48043.8797453703700742 /  MJD
>
>The only difficultly with this is that there has been no convenient way
>to read or write values in this format, so I have proposed to add (in
>

  The real problem is NOT that there is no convenient way to READ or WRITE
  values in this format, but there is no portable way of STORING them in
  memory (REAL*16 is not standard). That's why I would try the best effort
  to avoid using quantities either than I*4 or R*8.

  The above line of reasoning tries to demonstrate that, at least in the
  area of expressing times and angles, one could do without using "exotic"
  representations.

  One is left however with an important problem, which is at a SEMANTIC level.
  That is, how to know a quantity (a binary table column, or an header
  keyword) is of a specific type (particularly if the type is a nonstandard
  one like DATETIME or ANGLE).
  In a non-FITS system this might be easier (for instance I store all kewyords
  as <type> <length> <name> <values>, and I could code <type> as I wish).
  But I am still left with the problem of expressing them into FITS kewyords
  for export (either a single "hyper-precision" one, like in Bill Pence's
  proposal, or a couple of associated keywords, which is after all not so
  awful).

  The only solution I may think of is of semantic nature, that is to know
  beforehand that a keyword with a particular NAME has a specific TYPE
  associated to it.
  This is already the case e.g. of NAXISn or TFIELDS, which everybody know
  are integers, or of DATE and DATE-OBS which are strings of a particular
  format, or of OBSERVER and ORIGIN, which are strings, etc. etc.
  Definition of additional conventions at this level should remain completely
  within the FITS spirit, and would be highly beneficial to facilitate
  data interchange.
  I would therefore endorse the case that such conventions be defined.

-----------------------------------------------------------------------------
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:   EXOSAT at IMISIAM                   |
-----------------------------------------------------------------------------
From fitsbits-request  Mon Oct  5 14:59:37 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA21526; Mon, 5 Oct 92 14:59:37 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Mon, 5 Oct 1992 18:01:00 GMT
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Message-Id: <5OCT199214015451 at stars.gsfc.nasa.gov>
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!agate!ames!nsisrv!stars.gsfc.nasa.gov!thompson
References: <9210051405.AA21114 at fits.cv.nrao.edu>
Subject: Re:      Re: triple precision keywords
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article <9210051405.AA21114 at fits.cv.nrao.edu>, Lucio Chiappetti <lucio at ifctr.mi.cnr.it> writes...
>On Wed, 30 Sep 1992 17:15:10 GMT  <pence at heawk1.gsfc.nasa.gov> said:
>>
>>Here at the HEASARC we often need to express keyword values which have
>>more significant figures than can be stored in a double precision
> 
>  I actually wonder how this is SPECIFICALLY related to the example of
>  MJD discussed below, or is really general.
> 
>>A common example of this problem is the Modified Julian Date
>>which has a value something like 48043.8797453703700742
> 
>  I am inclined to think this is somehow related to the need of expressing
>  time quantities like this.
>  What I believe is needed is a way of defining some "compound" or "non-
>  primitive" data types. By non-primitive I mean they should go beyond the
>  usual CHARACTER, INTEGER, REAL and DOUBLE PRECISION supported by FITS.
>  I raised this point already in a previous posting.
>  In my view this concerns BOTH header keywords AS WELL AS data quantities
>  (e.g. columns in binary tables).
>  The sort of data types I am thinking of are quantities like :
> 

	(He goes on to describe suggested definitions of the quantities ANGLE,
	HANGLE, DATE, DATETIME, and TIME.  Definitions omitted to save space.)

I strongly suggest looking into the document "Time Code Formats" from the
Consultative Committee for Space Data Systems, CCSDS 301.0-B-2, April 1990.
This is available from

	CCSDS Secretariat
	Communications and Data Systems Division (Code-OS)
	National Aeronatuics and Space Administration
	Washington, DC 20546, USA

The topic of encoding date and time values into binary and ASCII values is
discussed there in some detail.  The suggested format for ASCII encoding is
briefly outlined below for the following example (5 Oct 1992 at 1:23:45 UT)

			   1992-10-05T01:23:45.000Z

The number of decimal places after the seconds field ("45") can be whatever is
appropriate, or can be omitted entirely.  Encoding only date, or only time,
values is also discussed.

It's always better to use a pre-existing standard than to reinvent the wheel.

On another note, I agree with Wayne Landsman that encoding the more-than-double
precision value as a character string, i.e.

	MJD     = '48043.8797453703700742'    /  MJD

is preferable to

	MJD     =      48043.8797453703700742 /  MJD

Bill Thompson
From fitsbits-request  Wed Oct  7 11:04:34 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA26535; Wed, 7 Oct 92 11:04:34 EDT
Return-Path: <forveill at gag.observ-gr.fr>
Message-Id: <199210071503.AA12607 at chenas.inria.fr>
Date: Wed, 7 Oct 92 16:03:42 +0100
From: forveill at gag.observ-gr.fr (Thierry Forveille)
Posted-Date: Wed, 7 Oct 92 16:03:42 +0100
To: fitsbits at fits.CV.NRAO.EDU, lucio at ifctr.mi.cnr.it
Subject: Re: Some FITS tables suggestions
Sender: fitsbits-request at fits.CV.NRAO.EDU

Lucio Chiappetti (LUCIO at IFCTR.MI.CNR.IT) writes

> YES, conventions are needed to avoid those incompatibilities, which can
> be very annoying.
> And I would say those conventions are needed beyond the area of databases,
> but, for instance, in the area of keywords describing the content of a
> photon list.
> At the moment I am using provisional, local conventions for the designation
> of columns for a photon list : for instance I call THETA and PHI the angular
> cooordinates of a photon (from the optical axis), X and Y the coordinates in
> micron on the focal plane, and XPOSITN YPOSITN the coordinates in detector
> pixels ...or I call ENERGY true energy in keV, but PHA energy in channels,
> and I ignore whether they are consistent e.g. with EXSAS or PROS - which
> I am told are not compatible among them)

I certainly agree that conventions for keywords names should be agreed upon 
in the various subfields of astronomy, but they should at least be compatible
with the existing standard. Specifically, A VALID FITS FILE MUST USE SI
UNITS. This tends to be repeatedly forgotten, even though it was already 
explicitly specified in the original FITS paper.
X and Y should therefore be stored in metres, not microns, ENERGY in Joules
not kev (or cm**-1, or Kelvin, or GHz),  and so on...
Also, there are some well established conventions to store projected angular
coordinates (RA---GLS or GLAT-ATF or...) though I am not sure they are part
of the standard yet.

	Thierry Forveille
	Observatoire de Grenoble
	forveill at gag.observ-gr.fr
From fitsbits-request  Wed Oct  7 11:55:48 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA26553; Wed, 7 Oct 92 11:55:48 EDT
Resent-Date:         Wed, 07 Oct 92 16:19:26 ITA
Resent-From: fitsbits-request
Resent-Message-Id: <9210071555.AA26553 at fits.cv.nrao.edu>
Return-Path: < at vm.cnuce.cnr.it:EXOSAT at IMISIAM.BITNET>
Message-Id: <9210071555.AA26547 at fits.cv.nrao.edu>
Date:         Wed, 07 Oct 92 16:19:26 ITA
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Subject:      Re: Some FITS tables suggestions
To: fitsbits at fits.CV.NRAO.EDU
In-Reply-To:  Message of Wed, 7 Oct 92 16:03:42 +0100 from
	<forveill at gag.observ-gr.fr>
X-Acknowledge-To: <EXOSAT%IMISIAM.BITNET at vm.cnuce.cnr.it>
Resent-Sender: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Resent-Sender: Lucio Chiappetti <EXOSAT%IMISIAM.BITNET at vm.cnuce.cnr.it>
Sender: fitsbits-request at fits.CV.NRAO.EDU

In reply to a posting of mine (which in turn replied to some questions
by Bill Pence) :

On Mon, 5 Oct 1992 18:01:00 GMT thompson at stars.gsfc.nasa.gov said:
>>
>>>A common example of this problem is the Modified Julian Date
>>>which has a value something like 48043.8797453703700742
>>
>>  I am inclined to think this is somehow related to the need of expressing
>>  time quantities like this.
>
>        (He goes on to describe suggested definitions of the quantities ANGLE,
>        HANGLE, DATE, DATETIME, and TIME.  Definitions omitted to save space.)
>
>I strongly suggest looking into the document "Time Code Formats" from the
>Consultative Committee for Space Data Systems, CCSDS 301.0-B-2, April 1990.

  I knew about this standard from a previous posting (may be by the
  same author, I have not looked it up) in fitsbits or WGAS, which I
  have noted down
  (perhaps for the disastrous state of our postal system unfortunately I tend
   to consider any document NOT available via network as not existing)
>
>discussed there in some detail.  The suggested format for ASCII encoding is
>briefly outlined below for the following example (5 Oct 1992 at 1:23:45 UT)
>
>                           1992-10-05T01:23:45.000Z
>

   However perhaps I gave the WRONG impression that the topic of my mail
   was to establish conventions for ASCII encoding |
   That was not my primary aim | I intended to solicit a discussion about
   NAMES and CONTENTS of keywords from a semantic and logical point of view
   (the fact that those keywords need an ASCII encoding is specific to a
   FITS implementation, while my concern goes beyond FITS into the native
   representations used by analysis systems ... which MAY be non FITS but
   SHOULD be FITS-compatible)
   I am ready to comply with whatever ASCII encoding for date-times will
   be agreed for FITS in addition to the one currently used in DATE and
   DATE-OBS.
   My interim solution was not so different from the CCSDS scheme and
   had that in mind since it is very easy to map it ;

                        1992-10-05-01:23:45.00

   actually it is the notation used by VMS. I find more LEGIBLE to have
   an hyphen instead of a T, and no Z at the end (which makes me think
   of "Zulu" timezone notation), but it is really trivial to switch to
   the other notation.

   See more below on standards ....

On Wed, 7 Oct 92 16:03:42 +0100  <forveill at gag.observ-gr.fr> said:
>
>with the existing standard. Specifically, A VALID FITS FILE MUST USE SI
>UNITS. This tends to be repeatedly forgotten, even though it was already
>explicitly specified in the original FITS paper.
>X and Y should therefore be stored in metres, not microns, ENERGY in Joules
>not kev (or cm**-1, or Kelvin, or GHz),  and so on...

   Again I gave the WRONG impression that my concern was on units of
   measurement, while I was more concerned about the fact the file be
   self-documenting about the units used, and about establishing conventions
   for names, contents and "binary" representation.

   Concerning SI units and alike, when I was a student I was an enthusiast
   of the SI, and I swore never to use cgs and similar things.
   When I later started my research life I realized one needs to be more
   flexible. I am not scandalized to use Angstroms or keVs (actually I
   cannot THINK of an X-ray spectrum if not in photon/cm2/s/keV vs keV,
   and of an UV spectrum if not in erg/cm2/s/A vs A  ... and I believe
   this is what everybody does ... I have never seen a paper on Ap.J. with
   photons/m2/s/J or J/m2/s/m
   Similarly the examples I made in my posting were just examples (although
   I will not find very useful to give photon energies in Joules or to
   use metres instead of microns to measure positions on a CCD plate: the
   latter example is particularly specific to Bill Pence's posting, since
   it avoids an unnecessary factor 10**6 and therefore 6 digits of -
   fictitious - precision)

   Concerning standards, therefore they also are subject to a silent
   judgement from the community, based on comfort and legibility.
   There is a nice paper by Arnold Toynbee, the historian, explaining why
   the French Revolution Calendar was not able to supplant the traditional
   calendar.
   Everybody uses Internet domains for e-mail addressing, which are legible,
   instead of the awful X.400 notations.
   Some years ago there was some proposed standard to express ALL decimal
   numbers in exponential notation in power of 1000, so a date in year
   1992 had to expressed as 1.992d3 or something like that : it fell in
   the place where everything is forgotten.

On the contrary other standards, of which FITS looks a working example,
meet the general agreement and ARE used.

I would however just reiterate my concept, that I regard the two points
treated above (ASCII-encoding and units) as completely minor in my line
of thought, while I would once again solicit a discussion on names of
keywords (and their content).

I feel that this would be beneficial AT LEAST to the X-ray community which
is now working separately at many separate missions, in fields like :

   list of photons :

   should we call photon detector-pixel positions X and Y, or XPOSITN and
   YPOSITN (8-char FITS names) or whatever ?
   should we call photon energy expressed as a PHA channel (not keV) with
   the name of ENERGY (I would say no and reserve it for keV, Joule or
   whatever physical unit) or PHA or what else ?

   time profiles (this perhaps also beyond X-ray astronomy) :

   it is important to agree a convention on the format of such files as
   binary tables, on the names of the columns and on the additional
   keywords needed to specify time of each bin

I hope to listen to some discussion on the latter topics in the near
future.

-----------------------------------------------------------------------------
       A member of  G.ASS : Group for Astronomical Software Support
-----------------------------------------------------------------------------
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:   EXOSAT at IMISIAM                   |
-----------------------------------------------------------------------------
From fitsbits-request  Wed Oct  7 18:26:19 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA27073; Wed, 7 Oct 92 18:26:19 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Wed, 7 Oct 1992 22:02:00 GMT
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Message-Id: <7OCT199218024426 at stars.gsfc.nasa.gov>
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Path: cv3.cv.nrao.edu!uvaarpa!caen!sdd.hp.com!think.com!ames!nsisrv!stars.gsfc.nasa.gov!thompson
References: <9210071555.AA26547 at fits.cv.nrao.edu>
Subject: Re:      Re: Some FITS tables suggestions
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article <9210071555.AA26547 at fits.cv.nrao.edu>, Lucio Chiappetti <lucio at ifctr.mi.cnr.it> writes...

	(stuff deleted)

>I would however just reiterate my concept, that I regard the two points
>treated above (ASCII-encoding and units) as completely minor in my line
>of thought, while I would once again solicit a discussion on names of
>keywords (and their content).
> 
>I feel that this would be beneficial AT LEAST to the X-ray community which
>is now working separately at many separate missions, in fields like :
> 
>   list of photons :
> 
>   should we call photon detector-pixel positions X and Y, or XPOSITN and
>   YPOSITN (8-char FITS names) or whatever ?
>   should we call photon energy expressed as a PHA channel (not keV) with
>   the name of ENERGY (I would say no and reserve it for keV, Joule or
>   whatever physical unit) or PHA or what else ?
> 
>   time profiles (this perhaps also beyond X-ray astronomy) :
> 
>   it is important to agree a convention on the format of such files as
>   binary tables, on the names of the columns and on the additional
>   keywords needed to specify time of each bin
> 

I would just like to make two comments on this general topic.  No, three
comments--the zeroth comment being that it's a very difficult thing to do.

One thing to avoid is the mistake I've been told the Planetary Data System made
with their Object Descriptor Language (although I haven't had any experience
with it directly).  As I understand it, basic names got frozen in at an early
stage, so that for example the keyword "FLUX" could only be used with particle
fluxes, and light measurements could only be referred to as a "BRIGHTNESS"
(which is a different thing).

Of course, you might say that brightness is the quantity that astronomers are
really interested in, but I argue that one does not want to limit oneself to
specific "most-common" observation modes and data types.  I can think of
situations where flux would be the fundamental quantity of measurements, e.g.
solar UV luminosity monitoring, or the flux distribution as a function of
height in a planetary atmosphere from a planetary probe.  Flux is the
fundamental quantity when concerned with energy transport in a plane-parallel
atmosphere, and a standard file format should be able to handle data from
theoretical calculations as well as from actual observations.

Secondly, I would just like to emphasize that such standardization should
proceed outside of the formalization process of the FITS standard itself (which
I'm sure was Lucio Chiappetti's intent as well).  Any such effort could only
consider a subset of the possible types of observations and the forms the data
could take.  Granted, it could possibly cover a large fraction of the
astronomical data actually taken, but there will always be data products and
observations which don't fall into the mold.

It may be best for this effort to proceed along disciplinary lines, rather than
to try to encompass all possible astronomical data into one grand scheme.  For
instance, I'm aware of a standardization process of this sort for radio
interferometry data, I believe organized by the Green Bank group.  Simple
image data already has some standardization applied to it, since that's what
FITS was originally designed for.  Just in general, I think more progress will
be made if the goals remain more focused.

Bill Thompson
From fitsbits-request  Thu Oct  8 00:21:08 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA27496; Thu, 8 Oct 92 00:21:08 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: 8 Oct 92 03:25:11 GMT
From: murison at cfa203.HARVARD.EDU (Marc A. Murison, RG)
Message-Id: <1992Oct8.032511.2423 at cfa203.harvard.edu>
Organization: Smithsonian Astrophysical Observatory, Cambridge, MA,  USA
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!ukma!hsdndev!cfa203!news
Subject: C++ FITS classes?
Sender: fitsbits-request at fits.CV.NRAO.EDU

Does anyone know of any C++ FITS classes available?  I'd
rather not re-invent any wheels...

------------------------------------------------------------------------
Marc A. Murison                | #include <fstream.h>
Smithsonian Astrophysical Obs. | void main( void ) { 
From fitsbits-request  Fri Oct 23 12:31:29 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA11724; Fri, 23 Oct 92 12:31:29 EDT
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Fri, 23 Oct 1992 16:45:00 GMT
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Message-Id: <23OCT199211452730 at nssdca.gsfc.nasa.gov>
Organization: NASA - Goddard Space Flight Center
Path: cv3.cv.nrao.edu!uvaarpa!caen!sdd.hp.com!elroy.jpl.nasa.gov!ames!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger
Subject: FITS basics and information (periodic posting)
Sender: fitsbits-request at fits.CV.NRAO.EDU

	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 through Simtel-20 [192.88.110.20]
at PD1:<MSDOS.GRAPHICS>IMDISP78.ZIP. 

	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/OSSA 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.  This document is available only in hard copy
form. 

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

	The IAU has endorsed the Floating Point Agreement, which
defines how floating point numbers are to be expressed in FITS.  The
basic agreement appears verbatim in the User's Guide, and the
substance is incorporated in the Draft NASA Standard. 

	The NOST maintains a file of FITS information available by
anonymous ftp from nssdca.gsfc.nasa.gov or DECnet copy from NSSDCA, in
the directory FITS. It includes copies of the current draft NASA
Standard in flat ASCII, PostScript, and LaTeX.  Style and index files
are provided for the LaTeX form.  A current list of the extension type
(structure) names registered with the IAU FITS Working Group is
maintained.  Also available, in LaTeX form, is the text of the
proposal for one of these new extension types, IMAGE.  A README. file
describes the contents of the directory.  A SOFTWARE subdirectory,
described by an included README.FIRST file, contains a program in C to
read and list the headers of a FITS file and another file with
information on publicly available FITS software packages. The ERRTEST
subdirectory contains several versions of the same FITS file, a valid one and
several with different kinds of header errors, for use in testing
software to read FITS files.  An included README.FIRST file contains
details. 
	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 (case is significant)
contains copies of the proposed BINTABLE Binary Tables extension,
which is now under consideration by the FITS committees, and a draft
describing a suggested method for data compression under FITS. These
documents are available in both LaTeX and PostScript forms. A number
of additional documents are available in ASCII text forms, including
the proposal on physical blocking of FITS files on media other than
tape and material on FITS, its history, and the FITS community. 

	Paper copies of many of the documents listed above can be
obtained from the NOST Librarian. Paper copies of the User's Guide and
either paper or electronic copies of the Draft 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/OSSA 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: (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.

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

From fitsbits-request  Mon Oct 26 10:09:59 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA17612; Mon, 26 Oct 92 10:09:59 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Mon, 26 Oct 1992 15:09:39 GMT
From: dwells at fits.CV.NRAO.EDU (Don Wells)
Message-Id: <DWELLS.92Oct26100939 at fits.cv.nrao.edu>
Organization: nrao
Path: cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
Subject: FITS support for MacOS?
Sender: fitsbits-request at fits.CV.NRAO.EDU

Recently I have received two queries asking about FITS support for
Macintosh systems. What is available? I would like to create a
subdirectory /FITS/OSsupport/MacOS under anonFTP on fits.cv.nrao.edu
from the response to this question.
--

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 Oct 26 16:32:47 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA00369; Mon, 26 Oct 92 16:32:47 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: 26 Oct 1992 21:01:17 GMT
From: raffi at aero.org (Raffi Krikorian)
Message-Id: <1chmatINN9tn at news.aero.org>
Organization: The Aerospace Corporation, El Segundo, CA
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!news.aero.org!raffi
Subject: Saving a 2D image w/ C
Sender: fitsbits-request at fits.CV.NRAO.EDU

I'm intresested in using FITS format to save 256X256 floating point
values to disk on a PC.  Are there any C routines that would do this?

Raffi Krikorian
raffi at aero.org

From fitsbits-request  Mon Oct 26 22:24:44 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA01632; Mon, 26 Oct 92 22:24:44 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: 27 Oct 1992 03:00:15 GMT
From: sla at umbra.ucsc.edu (Steve Allen)
Message-Id: <1cibc0INNpjq at darkstar.UCSC.EDU>
Organization: UCO/Lick Observatory
Path: cv3.cv.nrao.edu!uvaarpa!caen!spool.mu.edu!decwrl!hal.com!darkstar.UCSC.EDU!umbra!sla
Subject: Which characters are legal in a string?
Sender: fitsbits-request at fits.CV.NRAO.EDU

I am looking through the NOST 100-0.3b standard document trying to be
very sure about one point:

    Section 5.3.2.1 specifies that a "character string shall be composed
    only of ASCII text."

    Section 6.1 specifies that characters shall be 7-bit ASCII

These specifications do not preclude the existence of unprintable characters
(ASCII 0 through 31 and 127) in a character string.  Is it intended that
unprintable characters be legal?  Are there FITS readers which will be
confounded by unprintables?

A further question might be asked about the reason why 8-bit ASCII is not
allowed, but I would rather defer that until later.
_______________________________________________________________________________
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 tell me.
From fitsbits-request  Tue Oct 27 12:05:31 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA03042; Tue, 27 Oct 92 12:05:31 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Tue, 27 Oct 1992 17:05:01 GMT
From: cflatter at cv3.CV.NRAO.EDU (Chris Flatters)
Message-Id: <1992Oct27.170501.2980 at nrao.edu>
Organization: NRAO
Path: cv3.cv.nrao.edu!laphroaig!cflatter
References: <1cibc0INNpjq at darkstar.UCSC.EDU>
Reply-To: cflatter at cv3.CV.NRAO.EDU
Subject: Re: Which characters are legal in a string?
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article 1cibc0INNpjq at darkstar.UCSC.EDU, sla at umbra.ucsc.edu (Steve Allen) writes:
>I am looking through the NOST 100-0.3b standard document trying to be
>very sure about one point:
>
>    Section 5.3.2.1 specifies that a "character string shall be composed
>    only of ASCII text."
>
>    Section 6.1 specifies that characters shall be 7-bit ASCII
>
>These specifications do not preclude the existence of unprintable characters
>(ASCII 0 through 31 and 127) in a character string.  Is it intended that
>unprintable characters be legal?  Are there FITS readers which will be
>confounded by unprintables?

Many C and C++ based readers will have problems with ASCII 0 in character
strings.  Many FORTRAN readers will also have problems on Unix systems (the
Fortran RTL often uses C standard library functions that attach a special
meaning to character zero).

	Chris Flatters
	cflatter at nrao.edu
From fitsbits-request  Tue Oct 27 13:25:52 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA03214; Tue, 27 Oct 92 13:25:52 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Tue, 27 Oct 1992 17:47:57 GMT
From: hanisch at stsci.edu (Bob Hanisch, ST ScI)
Message-Id: <1992Oct27.174757.18460 at stsci.edu>
Organization: Space Telescope Science Institute, Baltimore MD
Path: cv3.cv.nrao.edu!uvaarpa!caen!destroyer!ncar!noao!stsci!iris.stsci.edu!hanisch
References: <1992Oct27.170501.2980 at nrao.edu>
Reply-To: hanisch at stsci.edu
Subject: Re: Which characters are legal in a string?
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article 1cibc0INNpjq at darkstar.UCSC.EDU, sla at umbra.ucsc.edu (Steve Allen) writes:
>I am looking through the NOST 100-0.3b standard document trying to be
>very sure about one point:
>
>    Section 5.3.2.1 specifies that a "character string shall be composed
>    only of ASCII text."
>
>    Section 6.1 specifies that characters shall be 7-bit ASCII
>
>These specifications do not preclude the existence of unprintable characters
>(ASCII 0 through 31 and 127) in a character string.  Is it intended that
>unprintable characters be legal?  Are there FITS readers which will be
>confounded by unprintables?

If you look on p. 5 of the same document, "ASCII text" is defined as ASCII
characters in the range of hex 20 to 7E.  This was done in order to have to
avoid repeating this every time we wanted to refer to printable ASCII text.

So the statement does NOT allow unprintable characters.

The distinction is further clarified in Appendix E (pp. 63-43).

---
Robert J. Hanisch                       Tel. (410)338-4910   Fax. (410)338-5090
Space Telescope Science Institute       NSI: hanisch at stsci.edu [130.167.1.2]
3700 San Martin Drive                   DECNet: STSCIC::HANISCH [6549::] 
Baltimore, MD  21218  USA               Bitnet: hanisch at stsci

From fitsbits-request  Tue Oct 27 13:53:51 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA03263; Tue, 27 Oct 92 13:53:51 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Tue, 27 Oct 1992 14:40:00 GMT
From: thompson at stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Message-Id: <27OCT199210400385 at stars.gsfc.nasa.gov>
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Path: cv3.cv.nrao.edu!uvaarpa!darwin.sura.net!wupost!decwrl!ames!nsisrv!stars.gsfc.nasa.gov!thompson
References: <1cibc0INNpjq at darkstar.UCSC.EDU>
Subject: Re: Which characters are legal in a string?
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article <1cibc0INNpjq at darkstar.UCSC.EDU>, sla at umbra.ucsc.edu (Steve Allen) writes...
>I am looking through the NOST 100-0.3b standard document trying to be
>very sure about one point:
> 
>    Section 5.3.2.1 specifies that a "character string shall be composed
>    only of ASCII text."
> 
>    Section 6.1 specifies that characters shall be 7-bit ASCII
> 
>These specifications do not preclude the existence of unprintable characters
>(ASCII 0 through 31 and 127) in a character string.  Is it intended that
>unprintable characters be legal?  Are there FITS readers which will be
>confounded by unprintables?
> 

I've always gone by the philosophy that only ordinary printable characters
should appear in a FITS header.  For instance, my software will expand tab
characters out to the appropriate number of spaces before writing it into the
header.

One might argue that more leniency could be permitted in ASCII fields in FITS
binary tables.

>A further question might be asked about the reason why 8-bit ASCII is not
>allowed, but I would rather defer that until later.

That's simple:  8-bit ASCII isn't really a standard, is it?  You get different
characters on different machines.

Bill Thompson
From fitsbits-request  Tue Oct 27 17:54:24 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA04234; Tue, 27 Oct 92 17:54:24 EST
Return-Path: <news at cv3.CV.NRAO.EDU>
To: fitsbits at fits.CV.NRAO.EDU
Date: Tue, 27 Oct 1992 21:00:00 GMT
From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Message-Id: <27OCT199216002831 at nssdca.gsfc.nasa.gov>
Organization: NASA - Goddard Space Flight Center
Path: cv3.cv.nrao.edu!uvaarpa!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!ames!nsisrv!nssdca.gsfc.nasa.gov!bschlesinger
References: <1cibc0INNpjq at darkstar.UCSC.EDU>
Subject: Re: Which characters are legal in a string?
Sender: fitsbits-request at fits.CV.NRAO.EDU

In article <1cibc0INNpjq at darkstar.UCSC.EDU>, sla at umbra.ucsc.edu (Steve Allen) writes...
>I am looking through the NOST 100-0.3b standard document trying to be
>very sure about one point:
> 
>    Section 5.3.2.1 specifies that a "character string shall be composed
>    only of ASCII text."
> 
This section is referring to values of header keywords.

>    Section 6.1 specifies that characters shall be 7-bit ASCII
> 

This section refers to data

>These specifications do not preclude the existence of unprintable characters
>(ASCII 0 through 31 and 127) in a character string.  Is it intended that
>unprintable characters be legal?  Are there FITS readers which will be
>confounded by unprintables?
> 

In Section 3, the term ASCII text is defined to mean "ASCII characters
hexadecimal 20-7E" (decimal 32-127) for the NOST standard.  These
characters are the printable ASCII characters.  Section 4.2 states
"The primary HDU and every extension HDU shall consist of an integral
number of header records consisting of ASCII text, which may be
followed by an integral number of data records."  Thus ASCII decimal
0-31,127 are excluded from headers.  The specification for character
data does not restrict the permitted characters.  Specifications for
individual structures may.  For example, for ASCII Tables, 8.1.5 reads
"All data in an ASCII tables extension data record shall be ASCII
text...."  A restriction to printable ASCII characters and 
NULL (decimal and hexadecimal zero) is proposed for binary tables. 

					Barry Schlesinger
					NOST FITS Support Office

From fitsbits-request  Thu Oct 29 17:47:41 1992
Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5)
	id AA12071; Thu, 29 Oct 92 17:47:41 EST
Return-Path: <pence at tetra.gsfc.nasa.gov>
Date: Thu, 29 Oct 92 17:47:58 EST
From: pence at tetra.gsfc.nasa.gov (William Pence)
Message-Id: <9210292247.AA12180 at tetra.gsfc.nasa.gov>
To: fitsbits at fits.CV.NRAO.EDU
Subject: FITSIO V3.3 is available
Sender: fitsbits-request at fits.CV.NRAO.EDU

                        FITSIO - Version 3.3
                           29 October 1992

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

This 3.3 version of FITSIO is completely compatible with the previous
version and contains the following new features:

  - Added a major new port to run FITSIO within the IRAF environment.  A set  
    of SPP-callable interface routines is also provided.

  - Added a new port to run on Macintosh computers with Absoft's MacFortran II.

  - The maximumn allowed number of open FITS files has been doubled
    from the previous 6 files to 12 files.

  - Added further checks to permit only printable ASCII characters to be
    written to a FITS header.

  - Made 7 other small enhancements and fixed 5 minor bugs.

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

Programmers interested in using the new IRAF/SPP version of FITSIO should
note that the HEASARC plans the first release of its FTOOLS software
utility package next week.  This will contain a complete example of how 
to build and use the FITSIO library within IRAF.

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

       ftp tetra.gsfc.nasa.gov   (128.183.8.77)

Then type the following:

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

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