Previous "magic" conversion of float to integer in fromarray/frombuffer

[djhoese]

I'm updating some old code and noticed a new failure that I'm really surprised ever worked in the first place.

import numpy as np
from PIL import Image

data = np.zeros((1, 1, 3))
img = Image.fromarray(data, mode="rgb")

With older pre-12.0 versions of PIL this magically worked. If you look at the properties, data.dtype is actually 64-bit float and np.array(img).dtype will give you uint8. In newer PIL this fails due to no cases in fromarray's type map for float -> RGB. This totally makes sense, it isn't a usual common case or even what my original code was intended to do. I think my original code assumed data would always be integers. However, after looking in the pillow code I can't find a reason for this to have worked.

1. Was this supposed to work (float -> RGB integer image) as a supported feature?
2. Should it work now in pillow 12+? I don't need it to. Like I said, I was surprised it worked before. I'm just curious.

[radarhere]

With older pre-12.0 versions of PIL this magically worked

I'm not able to replicate this. With 11.3.0, I receive

Traceback (most recent call last):
  File "demo.py", line 6, in <module>
    img = Image.fromarray(data, mode="rgb")
  File "PIL/Image.py", line 3336, in fromarray
    return frombuffer(mode, size, obj, "raw", rawmode, 0, 1)
  File "PIL/Image.py", line 3225, in frombuffer
    return frombytes(mode, size, data, decoder_name, args)
  File "PIL/Image.py", line 3152, in frombytes
    im = new(mode, size)
  File "PIL/Image.py", line 3117, in new
    return im._new(core.fill(mode, size, color))
ValueError: unrecognized image mode

But I do receive a different error with Pillow 12.

Traceback (most recent call last):
  File "PIL/Image.py", line 3285, in fromarray
    typemode, rawmode, color_modes = _fromarray_typemap[typekey]
KeyError: ((1, 1, 3), '<f8')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "demo.py", line 6, in <module>
    img = Image.fromarray(data, mode="rgb")
  File "PIL/Image.py", line 3289, in fromarray
    raise TypeError(msg) from e
TypeError: Cannot handle this data type: (1, 1, 3), <f8

[djhoese]

$ conda list pillow
# packages in environment at /home/davidh/miniforge3/envs/satpy_py312:
#
# Name                     Version          Build            Channel
pillow                     11.3.0           py312h7b42cdd_3  conda-forge
$ python -c "import numpy as np; from PIL import Image; data = np.zeros((1, 1, 3)); print(data.dtype); img = Image.fromarray(data, mode='RGB'); print(np.array(img).dtype)"
float64
<string>:1: DeprecationWarning: 'mode' parameter is deprecated and will be removed in Pillow 13 (2026-10-15)
uint8

[djhoese]

Oh "rgb" and "RGB" are treated differently:

$ python -c "import numpy as np; from PIL import Image; data = np.zeros((1, 1, 3)); print(data.dtype); img = Image.fromarray(data, mode='rgb'); print(np.array(img).dtype)"
float64
<string>:1: DeprecationWarning: 'mode' parameter is deprecated and will be removed in Pillow 13 (2026-10-15)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/davidh/miniforge3/envs/satpy_py312/lib/python3.12/site-packages/PIL/Image.py", line 3336, in fromarray
    return frombuffer(mode, size, obj, "raw", rawmode, 0, 1)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/davidh/miniforge3/envs/satpy_py312/lib/python3.12/site-packages/PIL/Image.py", line 3225, in frombuffer
    return frombytes(mode, size, data, decoder_name, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/davidh/miniforge3/envs/satpy_py312/lib/python3.12/site-packages/PIL/Image.py", line 3152, in frombytes
    im = new(mode, size)
         ^^^^^^^^^^^^^^^
  File "/home/davidh/miniforge3/envs/satpy_py312/lib/python3.12/site-packages/PIL/Image.py", line 3117, in new
    return im._new(core.fill(mode, size, color))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: unrecognized image mode

[radarhere]

Thanks.

Previously, the mode parameter was used as an override in whether or not the array type was present in _fromarray_typemap.

You have seen that there is a deprecation for some mode values. At first we deprecated the mode argument altogether, but then we rolled that back a bit in #9063, so that if you are using the mode value in a way that relates to palettes or color spaces, that is not deprecated. See https://pillow.readthedocs.io/en/stable/deprecations.html#image-fromarray-mode-parameter

So there should be two scenarios that currently work, but are deprecated.

1. Using mode on an array type not present in _fromarray_typemap
2. Using a mode value that isn't in the color modes for that array type in _fromarray_typemap

Unintentionally, during that rollback, I dropped support for the first scenario. It should be deprecated, but still work, but now it just doesn't work.

Now that it is out there though, I'm not convinced that we should bring back the deprecation? It seems odd to make Pillow 12.1.0 work, only to take the fuctionality away again when the deprecation ends in Pillow 13 in October 2026.

Feel free to offer your thoughts.

[djhoese]

Yep, I'm familiar with the mode deprecation and lightening of that deprecation (I'm the person who asked when the second PR was going to be released).

I don't think you need to change anything or at least not to support this functionality I'm talking about here. This code I'm having an issue with is very very old and wasn't trying to support float data, it just didn't take care to make the data not-float before passing to Pillow.

I'm mostly just curious how "supported" this invisible float->integer conversion was, but now I'm also curious about this difference in "RGB" and "rgb" mode behavior. If you have any info on it then great, but otherwise no problem.

[radarhere]

I'm also curious about this difference in "RGB" and "rgb" mode behavior.

"rgb" was reported as an "unrecognized image mode". That makes sense to me. If you look at the list of Pillow modes, you will see that we have both RGBA and RGBa, along with LA and La. This means that we can't handle all mode names case insensitively.

I'm mostly just curious how "supported" this invisible float->integer conversion was

The behaviour has been present since Pillow forked from PIL. I don't think of features as being more or less supported, so I'm not sure what you mean. Within an issue talking about interpreting float NumPy data as integers, there was the following comment - #5465 (comment)

I think that the mode to use parameter is a footgun. It’s not an implicit conversion, it’s a cast.

#5849 documented mode as

This will not be used to convert the data after reading, but will be used to change how the data is read:

from PIL import Image
import numpy as np
a = np.full((1, 1), 300)
im = Image.fromarray(a, mode="L")
im.getpixel((0, 0))  # 44
im = Image.fromarray(a, mode="RGB")
im.getpixel((0, 0))  # (44, 1, 0)

[djhoese]

Maybe I should have said "intended" instead of "supported". That is, I was wondering if it is documented somewhere in the API as "if the data type is X then it will be cast to fit the mode...blah blah blah".

No big deal though. Thanks for your time. I'll close this.