FITS images should be big endian

[petsuter]

The FITS standard states:

3.3.2. Primary data array ... The individual data values shall be stored in big-endian byte order such that the byte containing the most-significant bits of the value appears first in the FITS file, followed by the remaining bytes, if any, in decreasing order of significance.
...
5. Data representation ... Bytes are in big-endian order of decreasing significance.
7.3.3.1. Main data table ...
16-Bit integer... The most-significant byte shall be first (big-endian byte order). ...
Single-precision floating point ... in big-endian byte order ...

Problem: Pillow does not seem to handle this big endian byte order. That's maybe OK for 8bit images. But #7894 already added a 16bit test image Tests/images/m13.fits, and loading and viewing that file demonstrates the problem.

The problem is even worse for floating point images. Example files can be downloaded here.

A workaround is using numpy's byteswap() function after loading the image.

With pillow (wrong byte order):

import PIL.Image
from matplotlib import pyplot as plt
filename = "502nmos.fits"
arr = numpy.asarray(PIL.Image.open(filename))
plt.imshow(arr, cmap='gray')
plt.show()

With byteswap (corrected byte order):

import PIL.Image
from matplotlib import pyplot as plt
filename = "502nmos.fits"
arr = numpy.asarray(PIL.Image.open(filename))
arr = arr.byteswap() # workaround to correct Big Endian byte order
plt.imshow(arr, cmap='gray')
plt.show()

With byteswap (corrected byte order) and normalized (enhanced contrast):

import PIL.Image
from matplotlib import pyplot as plt
import numpy as np
filename = "502nmos.fits"
arr = numpy.asarray(PIL.Image.open(filename))
arr = arr.byteswap() # workaround to correct Big Endian byte order
arr = np.clip(arr, np.percentile(arr, 0.4), np.percentile(arr, 99.6)) # normalize
plt.imshow(arr, cmap="gray")
plt.show()

[petsuter]

Probably https://github.com/python-pillow/Pillow/blob/12.2.0/src/PIL/FitsImagePlugin.py#L108 should be changed from:

        if number_of_bits == 8:
            self._mode = "L"
        elif number_of_bits == 16:
            self._mode = "I;16"
        elif number_of_bits == 32:
            self._mode = "I"
        elif number_of_bits in (-32, -64):
            self._mode = "F"
...
        args = (self.mode, 0, -1)

maybe to something like:

        if number_of_bits == 8:
            self._mode = "L"
            raw_mode = "L"
        elif number_of_bits == 16:
            self._mode = "I;16"
            raw_mode = "I;16BS"
        elif number_of_bits == 32:
            self._mode = "I"
            raw._mode = "I;32BS"
        elif number_of_bits == -32:
            self._mode = "F"
            raw._mode = "F;32B"
        elif number_of_bits == -64:
            self._mode = "F"
            raw_mode = "F;64B"
...
        args = (raw_mode, 0, -1)

?

[radarhere]

I've created #9575. Are you able to test it? Or offer some Pillow only code to create an image that I can post so you can evaluate the result?

[petsuter]

I tested the FitsImagePlugin.py changes. It seems to fix the 16bit file Tests/images/m13.fits.

For 32bit float apparently F;32B is wrong. I found this mapping and this mapping and the unpack macros. I tested F;32BF as that looks more plausible and it seems to work.

[petsuter]

some Pillow only code to create an image

Maybe a test like this could be added:

from PIL import Image
from io import BytesIO
import struct
headers = b"".join(
    data.ljust(80, b" ")
    for data in [
        b"SIMPLE  =                    T / file does conform to FITS standard",
        b"BITPIX  =                  -32 / number of bits per data pixel",
        b"NAXIS   =                    2 / number of data axes",
        b"NAXIS1  =                    1 / length of data axis 1",
        b"NAXIS2  =                    1 / length of data axis 2",
        b"END",
    ]
).ljust(2880, b' ')
f = 123456.75
image_data = headers + struct.pack(">f", f).ljust(2880, b'\x00')
with Image.open(BytesIO(image_data)) as im:
    assert f == im.getpixel((0, 0))

But the offset / padding doesn't seem quite right somehow?

[radarhere]

But the offset / padding doesn't seem quite right somehow?

That's a little vague for me. Could you elaborate? Are you talking about the resulting pixel values?

Or are you asking why the test uses 80 and 2880?

https://fits.gsfc.nasa.gov/fits_primer.html

Each header or data unit is a multiple of 2880 bytes long
...
Each header unit contains a sequence of fixed-length 80-character keyword records

[petsuter]

Nevermind, it's working now (with F;32BF) and the offset / padding does seem right. Not sure what went wrong in my previous test run.

Thanks for looking into this by the way! 🙏

[petsuter]

Is it expected that F;64BF will only be accessible as float32 or is there a chance pillow could provide access to the float64 data?

[radarhere]

Pillow reads data from images in a larger number of "raw" modes, such as F;64BF, but then stores that data in only a few standard modes.

64-bit floating point data is not one of our standard modes.. So what you're suggesting is a larger change.