.fit file open problem?

[mschuster]

Hi Juan,

This .fit is from AudeLA, a spectrograph capture.

https://dl.dropboxusercontent.com/u/109232477/PixInsight/altair-1.fit

When opened in PI data range is compressed to 32768 +/- 0.5. I think actual data range is something like 300 to 44000 DN.

It may be that the FITS header is incomplete.

Is there a workaround?

Thanks,
Mike

[Juan Conejero]

Hi Mike,

This is a 32-bit signed integer image storing raw data (instead of 16-bit unsigned as it should be...)

To load it correctly, enable the "Signed integer images store physical pixel data" option in FITS preferences. Alternatively, you can use the "signed-is-physical" input format hint with tools that accept format hints.

[mschuster]

Thanks Juan,

FYI, enabling "Signed integer images store physical pixel data" by itself did not seem to solve the problem. The resulting data values are now very small.

The PixelMath "65536 * $target" helps. With this the resulting DNs match my expectation +/- 1.

Is this expected?

Thanks,
Mike

[Juan Conejero]

Yes, this is expected. The file stores raw data (= 16-bit unsigned integers) in the positive half of 32-bit signed integers. When you enable the "Signed integer images store physical..." option, the pixel data are loaded in memory exactly as they are stored in the file, that is, ignoring the negative subrange of 32-bit integers.

The resulting values are very small because they have been referred to a wrong range. Since the image is in the 32-bit unsigned integer format, 0=black and 2³²-1=white. However, the original raw data are actually referred to the 16-bit unsigned integer range, so 0=black and 2¹⁶-1=65535=white is the true numerical range of the data.

So this is the only solution to read these images correctly in PixInsight:

- Load them with the "Signed integer images store physical pixel data" FITS preferences option enabled, or use the "signed-is-physical" input hint where appropriate.

- Multiply the image by the constant (2³²-1)/(2¹⁶-1) = 65537.

Unfortunately, many (most?) software applications insist in storing raw pixel data using wrong data formats. This complicates things unnecessarily and generates incompatibilities between applications. In some cases these incompatibilities are intentional; in most cases they are the result of bad software design. Raw CCD data are 16-bit unsigned integers, and this is how they should *always* be stored, irrespective of the file formats used.