Usually astronomers use a mask file. So for every image file there is a
second file with the same number of pixels that have a quality code to
explain what is special about a given pixel. Many of these codes are
essentially different kinds of Nulls (dead pixel, hot pixel, cosmic ray
hit, bad line, out of focal plane, bad flat field pixel, etc). One does
not want to go the route of using the different NaNs in IEEE, because
a) it is confusing and b) because it is still the case that different
architecture implement the different NaNs differently even though they
all claim to be IEEE compliant. So if you write a NaN one way on an
Intel machine it will come out differently on a Mac (unless an Intel
based Mac).
Personally, I think it would be good idea, when designing a new XML
format, to allow the mask and the data be combined by allowing special
numbers assigned to the different Nulls. Sometimes one wants both a
mask value and a data value for the same pixel, but that is rare enough
that one should simply holds those as triplets (i,j,maskValue). If
there is still a need for a quality mask, then this would not exclude it.
Ed
William Pence wrote:
>Clive Page wrote:
> > On Wed, 21 Jun 2006, Mark Taylor wrote:
> >
> >> I can see that this can be justified in theoretical terms, but I must
> >> admit I've never thought much about the distinction and any software
> >> I've written has got on fine by using NaN (or a magic integer value)
> >> to cover both undefined and numerically indefinite. FITS BINTABLE
> >> and IMAGE seem to have managed without the distinction as well.
> >> Are there really compelling scenarios for this requirement?
> >
> > In the world of relational databases there have long been disputes over
> > how many different types of null should be supported. Since the
> > set-theory basis of RDBMS actually becomes inconsistent in the face of
> > even one type of null, there are many who think that they are all evil.
> >
> > In practice, as Mark said astronomers have long managed with just one
> > type of null in FITS files. Once the idea of having more than one type
> > of null gets around it will be very hard to get agreement on where to
> > stop, and I have seen little evidence of need for more than one. I
> > think it would be more productive to work on a standard way of
> > expressing the notion of upper (or lower) limits - something which is so
> > far missing from most astronomical formats.
> >
>
>It is perhaps worth mentioning that FITS allows all the IEEE special values
>in 32-bit and 64-bit floating point data. There are more than 16 million
>different 32-bit NaN values (if I calculated correctly) and a vastly larger
>number of 64-bit NaN values. In principle, FITS software could use
>different NaN values for different purposes, but as far as I know this has
>never been done. FITS also supports the IEEE special values for positive
>and negative versions of denormalized numbers, underflow, overflow, and
>infinity, but in practice I don't think that these have ever been
>deliberately used in FITS files. A chart of all these special values
>can be
>seen in appendix H of the FITS Standard
>(http://archive.stsci.edu/fits/fits_standard/node95.html
>
>Bill Pence
>
>
Received on 2006-06-23Z12:15:10