Hi Gert,
That forum thread is pretty old (2009?). We now have more flexible options implemented in the FITS format support module.
I guess this is a 32-bit signed integer image storing physical pixel data. In other words, the negative half of the available numeric range, from -1 to -2
31, is not being used (the negative value at {0,0} looks like a spurious value or a border artifact). Please do the following to open these images correctly in PixInsight (see attached image):
- Open the Format Explorer window.
- Double click the FITS item on the left column.
- On the FITS Format Preferences dialog, enable the "Signed integer images store physical pixel data" option (Miscellaneous Options section).
- You may also want to set "Coordinate origin = Upper left corner" in order to load these FITS images with the correct orientation.
- Click OK.
Now these images will be loaded with the correct range in PixInsight. This means that the data will be loaded and kept with their original values in memory, as a 32-bit unsigned integer image (signed integer images don't exist as objects available to the user in the PixInsight platform).
However, we now have a completely different, much harder problem: we don't know how to interpret these images. In particular, we have no way to know where the white point is located inside the vast space of 2,147,483,648 discrete values (from 0 to 2
31-1 ; since we know that the original file stored signed integers, we know for sure that the upper half of the unsigned numeric range is not being used). You may think that this can be solved by simply rescaling all existing pixel values to the [0,2
32-1] range, which is what the Rescale tool does. However, this is just a cosmetic solution to let you see the image, but not a valid general solution to the data interpretation problem. By rescaling the data we are assuming that the minimum and maximum pixel values stored in the original file (and now stored in RAM as an image in PixInsight) are intended to represent the black and white points in the dynamic range of the image. In general, this is not necessarily true, unless the image has some black and saturated valid pixels. So by rescaling the image we take the risk to lose the physical meaning of the original data. This is bad because, among other effects, two or more images loaded under the same conditions are not guaranteed to be mutually comparable. Unfortunately, the FITS format does not provide any standard way to define the bounds of the numerical range to which an image is referred. Only the developers of each application are responsible to publicly define the range of the data they generate in a consistent way.
As for PixInsight, we always follow these rules for every image we generate:
- Pixel samples stored in floating point images (32-bit and 64-bit IEEE 754 formats) are always referred to the [0,1] range, where 0 is black (no signal) and 1 is white (full signal).
- Pixel samples stored in unsigned integer images (8-bit, 16-bit and 32-bit unsigned integer images) are always referred to [0,2
n-1], where n is the number of bits used to represent each pixel sample.
- Pixel samples stored in signed integer images (16-bit and 32-bit signed integer images) are always referred to [-2
n-1,+2
n-1-1], where n is the number of bits used to represent each pixel sample.
For integer images, the bounds of the nominal range always represent, respectively, the black and white points of the image.
I apply the rescale and surprisingly a 16bit scaled image pops out.
Not at all; the data is stored and managed in RAM as a 32-bit unsigned integer image (unless you convert it to a different format, for example with the SampleFormatConversion tool).
When I check statistics right after opening the image the statistics are limited to 16bit, which doesn't make sense.
In PixInsight, pixel readouts are virtual. This means that you can read pixel values in any real or integer range of your choice (including arbitrary integer ranges), irrespective of the actual data type used to store and manipulate the image. For example, you can load a 32-bit integer image and read its pixels as 16-bit integers if you want, or load a floating point image and read it in the [0,1000] range, if this is useful for you. The ReadoutOptions tool allows you to manage these settings.
The default readout range is [0,1]. We call it
normalized real range, and it is very important and widely used throughout the whole PixInsight platform. It allows us to express and manipulate images in a purely abstract numerical space that is independent on the actual data type of each image. It also has the advantage that we can remap it to any arbitrary range by a simple multiplication with a constant.
The Statistics tool also allows you to acquire statistical data in virtual ranges. It doesn't offer the 32-bit integer range, mainly because we think that working with 32-bit integer numbers is quite confusing (what is the difference between 1,000,300,768 and 1,700,500,123 in terms of brightness?). If you need precision with the Statistics tool, select the normalized real range.
You can also read statistical values very quickly from the console. Select your image and enter this command from the console:
j $min
$min is a predefined macro that shows you the minimum value of the current image in the [0,1] range. If you want to read it as a 32-bit integer number, use this command:
j $min*(Math.pow2(32)-1)
In a similar way, you can use the $max, $mean, $median, $stddev and $avgdev predefined macros.
Hope this helps.
