[fitsbits] INF/NAN as header values?

[Eric Greisen]

Tim Pearson wrote:
> On Jun 7, 2013, at 8:22 AM, Erik Bray wrote:
> 
>> 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).
> 
> I can think of no use-cases in which it would be appropriate for the value of a FITS header keyword to be Inf: perhaps someone else can? 
> 
> There are cases where the value NaN might be appropriate, but in such cases I think it must be better to indicate ignorance by omitting the keyword.
> 
> I understand that some programs, given bad data, may sometimes generate Inf or NaN for the value to be attached to a keyword. But this is a case of "garbage in, garbage out" and it doesn't really matter that the resulting file is invalid FITS: you are going to delete it anyway (I hope)!
> 
> So I do not think keyword-values Inf and NaN should be added to the FITS standard.
> 
> Incidentally, it would be nice if the already-great CFITSIO could be modified to make it impossible to write an invalid FITS file (i.e., one that fails FITSVERIFY), but perhaps that is an unreasonable request.

It is entirely possible for the image to contain a lot of very valid and 
useful pixels, whilst having other pixels as undefined.  AIPS gets this 
through mathematical reasons or through the user selecting area that he 
deems to be source free and does not want adding to the noise.  AIPS 
then writes these pixels as NaNs in the 32-bit floating format per the 
standard (although the internal representation is 3140.89282 = 'INDE' on 
standard Intel machines).  We assume that FITS readers can handle these 
NaNs is whatever way is appropriate to the particular software package.
But, when we determine DATAMAX and DATAMIN we ignore our INDE pixels and 
so give a sensible header value.

ERic Greisen