Unsigned integer support in NOST 100-1.2

[John E. Davis]

On 13 Jul 1998 12:47:52 -0400, William Pence <pence at tetra.gsfc.nasa.gov>
wrote:
>However, I have since come to appreciate that the current FITS format
>already fully supports unsigned integers (16 and 32 bit at least), hence
>I would now oppose any change to the Standard in this regard.  FITS is

I understand your point that a fits can store unsigned values using
the current convention.  As long as that convention is documented, I
do not care about what bits need to be flipped.  However, I think that
there is a deeper issue that keeps nagging me.  This leads me to
believe that the fits file specification does not define a
well-defined file format that is independent of the reader.

To see what I mean, consider the BZERO and BSCALE keywords.  The NOST
document states that these keywords represent floating point values,
and if the keywords are absent, then they default to 0.0 and 1.0,
respectively.  Then the value of a pixel pixel is given by:

   Physical_Value = BZERO + BSCALE * Array_Value

Does this mean that all images are floating point images?  If so, are
they 64 bit floating point values or 32 bit floating point values?
The file specification does not spell this out which means that the
interpretation is left to the fits reader.  In my opinion, the
document should state that the result of

   Physical_Value = BZERO + BSCALE * Array_Value

depends upon the range of the resulting values, and upon the data types
specified by the syntax used to specify the BZERO and BSCALE keywords.
In this respect, the default values should be the *integers*, 0 and 1,
and not floating point values.

At this point, I have concluded that a fits file simply stores any
numeric value as a 64 bit floating point value in various floating
point and signed integer representations, using the BZERO/BSCALE
values (or their equivalents) to perform the appropriate conversions.
Please try to understand that I am not implying that everything gets
written out to the fits files as 8 byte floating point double
precision numbers.

I feel that the only consistent way to view the current specification
is that all data types are implicitly converted to the largest
available data type capable of representing them, namely 64 bit
floats, and then written out in a user specified representation, e.g.,
as signed 16 bit integers, with the appropriate values of BZERO and
BSCALE.  I can live with this interpretation as long as I can store
all the numeric data types that I work with with no loss of precision.
However, this will present a problem when the file format gets
enlarged to handle 64 bit integer quantities.  Then,

   Physical_Value = BZERO + BSCALE * Array_Value

will result in a loss of precision for 64 bit integers.

Some may find this whole debate pointless, but if you want to define a
fits file whose contents have a well defined meaning that is
independent of the software that reads it, then these seemingly
trivial points matter.

--John