Hi Bitli,
Thank you for the sample file you uploaded for me. The problem is with the BZERO keyword value. This file has the following keywords:
BITPIX=16
BZERO=32767
BSCALE=1
As you know, the FITS standard does not support unsigned integer data natively. To overcome this, the well-known 'BZERO trick' is always used as a de-facto standard. The trick consists of setting these keywords:
BITPIX=16
BZERO=32768
BSCALE=1
to transform the 16-bit signed integer values stored in the file into unsigned integer numbers with the same bit length. As specified by the FITS standard, the following operation has to be applied to each pixel to convert the stored values into physical data:
physical_pixel_value = BZERO + BSCALE*fits_pixel_value
So if we have BZERO=32768 and BSCALE=1, the above transformation converts the stored data from its original signed range [-32768,+32767] into the unsigned range [0,65535]. This is how all unsigned integer images are managed as FITS files.
In the case of the file you have provided, however, we have BZERO=32767. So the transformation is as follows:
[-32768,+32767] -> [-1,+65534]
So the output pixel data are still signed integer values. Even worse, the output range cannot be represented with 16-bit integers. It requires 32-bit signed integers. Indeed, when you load this file in PixInsight you get a 32-bit image, not a 16-bit image as expected. Note that this conversion is automatically performed by CFITSIO (which out FITS support module uses internally) as a result of the exotic BZERO value.
In my opinion, this BZERO value is an error. It is fully standards-compliant, that's true (because the FITS standard does not impose any particular value for this keyword), but I cannot see any valid reason to use BZERO=32767. In my opinion also, the way PixInsight is reading this file is the correct way.
Naturally, I can modify our FITS module to support these files, for the sake of compatibility. It is not very easy, but of course can be done. However, please realize that my workload is currently so huge that fixing this problem has to be a very low-priority task.
The best workaround to this problem is patching the file to replace 32767 with 32768. This can be done very easily with a binary file editor, or you can also write a simple PixInsight script to perform this task automatically. If the file has been generated in a coherent way (and we have no reason to doubt about this), by doing this patch you'll load the image with a constant pedestal of +1 added to all pixel values. This shouldn't be a problem if you calibrate with dark frame optimization enabled. To be meticulous, you can subtract this pedestal very easily with PixelMath:
$T - 1/65536
with the rescale result option disabled.
Hope this helps.
