[fitsbits] INF/NAN as header values?

[Eric Greisen]

Erik Bray wrote:
> I originally sent this message a few months ago and never got any replies.  Now 
> based on recent activity I'm thinking maybe the mailinglist was having issues? 
> So trying again. Apologies if this is a duplicate.
> 
> 
> -------- Original Message --------
> Subject: INF/NAN as header values?
> Date: Mon, 8 Apr 2013 15:15:21 -0400
> From: Erik Bray <embray at stsci.edu>
> To: <fitsbits at nrao.edu>
> 
> Hello all,
> 
> I've had a few different issues reported against PyFITS lately regarding INF/NaN
> as values in FITS headers (that is, as float literals, without quotation marks
> around them).
> 
> In particular, reading files that contain values like this fails in PyFITS, and
> writing those values to a header currently has undefined behavior (though upon
> writing to disk the header is reported as invalid).  And according to a strict
> reading of the current FITS standard, specifically section 4.2.4, this is
> correct:  INF and NaN are not valid formats for header values.
> 
> I have a suspicion that this was at one time intentional--not all systems may
> have had representations for those values in their floating point
> implementations.  But by today's standards it feels like an oversight.  It was
> pointed out to me that IDL allows saving INF/NaN as header values, but the way
> it writes them violates the FITS standard.  But several such files appear to be
> present in the wild, so I'm considering going and letting PyFITS allow this too.
> 
> Are there any thoughts/feelings on this?  Should this be corrected in a future
> version of the standard?

I too do not remember this issue.

If I understand what we initially proposed, these headers are erroneous. 
  The images are allowed to contain NaNs and inf's which are supposed to 
be recognized by software reading them as invalid pixels in whatever way 
that software handles "unknown" pixels.  FITS-writing software that does 
not remember to skip over unknown-value pixels when finding the max/min 
for the header is software with errors.  the headers are incorrect.

Reading software for these headers should, however, be able to deal with 
this error gracefully.  My software (I think) ignores the header max min 
and finds them while reading the data and correctly turning the NaNs 
into my software's "magic value" for unknown or "blanked" pixels.

Eric Greisen