Hi Sander,
Well, let's calm a bit and keep our pressure within healthy limits
I apologize for some things that I said in my previous post. Too much pressure I guess...
After reading your message, I have made a more in-depth investigation and have read relevant parts of the New Proposed Version 3.0 (DRAFT) FITS Standard document. It's here:
http://fits.gsfc.nasa.gov/draft/fits_standard_30.pdfIn this document we can read:
5.3 IEEE-754 Floating-Point
Transmission of 32- and 64-bit floating-point data within the FITS format shall use
the ANSI/IEEE-754 standard [21]. BITPIX = -32 and BITPIX = -64 signify 32- and
64-bit IEEE floating-point numbers, respectively; the absolute value of BITPIX is used
for computing the sizes of data structures. The full IEEE set of number forms is allowed
for FITS interchange, including all special values.
The BLANK keyword should not be used when BITPIX = -32 or -64; rather, the
IEEE NaN should be used to represent an undefined value. Use of the BSCALE and
BZERO keywords is not recommended.
So it is clear that the new proposed standard discourages the use of BSCALE and BZERO as we are currently using them. I stand corrected, and consequently, I'll try to make the necessary changes to our implementation ASAP.
Now here comes the real problem. I'll explain what the PCL does for floating point real FITS images.
When an image stores pixels as floating point numbers we face the following problem: there is no prescribed physical range of sample values. This is because we are representing pixels as real numbers, which are defined in the {-infinite,+infinite} interval.
Contrarily, when an image stores integer pixels, we have a finite set of values that each pixel sample can take: [0, 2^n - 1] in the case of unsigned integers. This is [0,65535] for 16-bit unsigned integers.
So, how can be know what the actual range of values is in a floating point image? The problem here is that the pixel values by themselves are not enough to derive the actual range. So we need some extra information. The (proposed and current) standard says:
The full IEEE set of number forms is allowed
for FITS interchange, including all special values.
However, how can we know the actual range of values, as I have said? The above sentence just allows us to use the full range of IEEE 754 values, including singular values (NAN and the like). However it says nothing about sample values and their actual ranges.
In practice, we need to define a range [
a,
b] of values such that:
-
a represents the minimum possible sample value. This is equivalent to the "no signal" condition, say "black".
-
b represents the maximum possible sample value. This is equivalent to the "full signal" condition, say "white".
In other words, [
a,
b] represents the underlying
total dynamic range where the image has been represented (note that this is not the same that the range [min,max] where min is the minimum value present in the image, and max is the maximum present value).
For floating point FITS images, PixInsight/PCL uses the BZERO and BSCALE keywords as follows
for floating point FITS images:
[1]
image_value = (array_value - BZERO)/(BSCALE - BZERO)
only when BZERO != 0 and BSCALE != 1 so we end with all pixel values expressed in the [0,1] range. Of course, this is
bad practice, but what else can we do?
You are right in that this is actually contrary to what the standard states:
physical_value = BZERO + BSCALE * array_value
which is valid for integer images. However, our implementation makes use of existing standard keywords instead of inventing some others
ad-hoc, and it only does that when there is no other alternative, that is, by default PCL writes FITS images in the [1,0] range with BZERO=0 and BSCALE=1, which is completely standards-compliant.
So you're saying that with a BSCALE of 65535 all of a sudden the file would load ok?
It would load ok with the current PCL implementation (and many others as well, in fact). However as I have said at the beginning of this post, this is going to change.
What we are not going to do is adopting that RANGE keyword, because it does not appear neither in the current standard nor in the proposed one.
This is a complex topic and we need to sit and think on it with calm and ensuring that we made the correct decisions.
I have to say you thanks for helping me in rethinking this. At the end of this we'll achieve a much better and solid implementation.
Now about your problem with envisage's files. One question, could you save the images as 16-bit FITS instead of floating point? Consider that you have no advantage in saving them as floating point, because they are raw unprocessed images. As 16-bit integer FITS there would be no problem at all to load them in PixInsight.
[1] Edited Oct 14 : I have replaced the expression indicated above with the correct one.
