Subject: Interpretion of BLANK

From: gtr at mail.ast.cam.ac.uk (Guy Rixon)
Date: 26 Jul 1994 15:44:45 GMT

I have found an ambiguity in the NOST FITS-standard concerning the use of the keyword BLANK.

NOST 100-1.0 says:

"BLANK Keyword    [...] The value field shall contain an integer that specifies the representation of array
values whose physical values are undefined."

This is clear enough if BZERO = 0 and BSCALE = 1, but we have problems with the case BZERO = +32K.
Our (that is the Isaac Newton Group's) FITS writer assumes that the test for dud pixels is made after
correcting for BSCALE/BZERO; several FITS readers make the opposite assumption.

Is an authoritative ruling possible here?

---

From: Arnold Rots <arots at xebec.gsfc.nasa.gov>
Date: Thu, 28 Jul 1994 17:49:09 -0400

I think it's fairly obvious that the standard intends BLANK to represent
the value *before* application of BZERO or BSCALE: if either or both of
them were non-integer, one could not satisfy the requirement that BLANK
have an integer value.

Remember, BZERO and BSCALE were originally introduced to facilitate the
transport of floating point numbers through integers (back in the days
when there was no IEEE float standard, but two's complement was well-
defined).

This also points at the danger of using BZERO (and BSCALE) in situations
were one wants to convert an integer to an integer (e.g., unsigned to
signed): there is no protection against overflows.  I know, the target
data type is not defined in FITS (i.e., you're on your own), but common
practice is different: the IN group obviously implicitly assumes that
the numbers will be cast to integers after conversion.

  - Arnold Rots

---

From: gtr at mail.ast.cam.ac.uk (Guy Rixon)
Date: 26 Jul 1994 17:30:19 GMT

In article <313b1d$p2c at lyra.csx.cam.ac.uk>, gtr at mail.ast.cam.ac.uk (Guy Rixon) writes:
|> I have found an ambiguity in the NOST FITS-standard concerning the use of the keyword BLANK.
|> 
|> NOST 100-1.0 says:
|> 
|> "BLANK Keyword    [...] The value field shall contain an integer that specifies the representation of array
|> values whose physical values are undefined."
|> 
|> This is clear enough if BZERO = 0 and BSCALE = 1, but we have problems with the case BZERO = +32K.
|> Our (that is the Isaac Newton Group's) FITS writer assumes that the test for dud pixels is made after
|> correcting for BSCALE/BZERO; several FITS readers make the opposite assumption.
|> 
|> Is an authoritative ruling possible here?

It has been pointed out, in another group, that that NOST 100-1.0 defines "array value" as the actual
number written for a pixel/voxel in the FITS file, without any processing to get the physical value.
The NOST "FITS user guide" (which I haven't seen an advert for; I'll check the FAQ for this group next time
it comes round) makes it even clearer: "The value of BLANK is the one that appears
in the actual data array, without scaling." 

Thanks to Martin Oldfield and Malcolm Currie for clearing this up.

---

From: thompson at orpheus.gsfc.nasa.gov (William Thompson)
Date: 26 Jul 1994 20:30:30 GMT

>Is an authoritative ruling possible here?

I don't think it's ambiguous.  The definition of BLANK says that it's an
*integer*.  In the most general case, once you have applied BZERO and BSCALE,
then you have a floating point number.  Hence, the test for dud pixels is made
*before* applying BZERO/BSCALE.

Bill Thompson