RGB/BGR confusion

[ubitux]

What did you do?

import sys
from PIL import Image

i = Image.open(sys.argv[1])
o = Image.new(mode="RGB", size=i.size)
o.putdata([r << 16 | g << 8 | b for r, g, b in i.getdata()])
o.save(sys.argv[2])

What did you expect to happen?

I expected this to have the input and output identical (normal case, no transparency etc)

What actually happened?

The output seems to expect BGR pixel format data, not RGB. I don't know if it's a bug or a documentation issue here. If this is expected, the doc probably needs some clarification about endianness and actual memory layout expected.

What are your OS, Python and Pillow versions?

• OS: Linux x86_64
• Python: 3.13.3
• Pillow: 11.2.1

--------------------------------------------------------------------
Pillow 11.2.1
Python 3.13.3 (main, Apr  9 2025, 07:44:25) [GCC 14.2.1 20250207]
--------------------------------------------------------------------
Python executable is /usr/bin/python3
System Python files loaded from /usr
--------------------------------------------------------------------
Python Pillow modules loaded from /usr/lib/python3.13/site-packages/PIL
Binary Pillow modules loaded from /usr/lib/python3.13/site-packages/PIL
--------------------------------------------------------------------
--- PIL CORE support ok, compiled for 11.2.1
--- TKINTER support ok, loaded 8.6
--- FREETYPE2 support ok, loaded 2.13.3
--- LITTLECMS2 support ok, loaded 2.17
--- WEBP support ok, loaded 1.5.0
*** AVIF support not installed
--- JPEG support ok, compiled for libjpeg-turbo 3.1.0
--- OPENJPEG (JPEG2000) support ok, loaded 2.5.3
--- ZLIB (PNG/ZIP) support ok, loaded 1.3.1
--- LIBTIFF support ok, loaded 4.7.0
--- RAQM (Bidirectional Text) support ok, loaded 0.10.2
--- LIBIMAGEQUANT (Quantization method) support ok, loaded 4.2.2
--- XCB (X protocol) support ok
--------------------------------------------------------------------

[radarhere]

Can I ask, what lead you to try and pass the RGB data back as single integers?

You likely realised the possibility of o.putdata([j for j in i.getdata()]), and from that I would have thought the more natural option would have been o.putdata([(r, g, b), (r, g, b), ...]).

[ubitux]

I use Python for prototyping C code where tuple do not exist, so in my image processing algorithm I tend to use the same data structures for consistency and reducing the risk of introducing mistakes during language switches.

Also, since I'm working with large inputs, this:

>>> sys.getsizeof((0xff,0xff,0xff))
64
>>> sys.getsizeof(0xffffff)
28

[wiredfool]

The pixel in C is struct { r uint8, g uint8, b uint8, x uint8}. If you map a little endian uint32 onto that, the channels are going to be reversed. Either that or you're just writing into gbx channels because it should be a 24/16/8 bit shift. I'd have to trace through for it, but when you assemble an int instead of the individual channels, there are a lot of details that are obvious in C and aren't nearly so in Python.

[ubitux]

My understanding is that the integer ends up as is into image->image32 here (_imaging.c:1737):

union {
    char ink[4];
    INT32 inkint;
} u;

u.inkint = 0;

op = PySequence_Fast_GET_ITEM(seq, i);
if (!op || !getink(op, image, u.ink)) {
    Py_DECREF(seq);
    return NULL;
}
/* FIXME: what about scale and offset? */
image->image32[y][x] = u.inkint;

The union dance will actually make putdata([0xff7f00]) turn into u.inkint=0xff7f00 (I'm surprised about the fields being signed btw, I guess that's a mistake?). Then I'm not sure how this integer is read back, but it seems that the int32 gets casted into uint8*, which doesn't sound like a good idea at all.

[radarhere]

From my perspective, in the previous comment's code, it is getink() that is actually splitting up the value into channels.

Pillow/src/_imaging.c

Lines 613 to 617 in 77f3a09

	/* compatibility: ABGR */
	a = (UINT8)(r >> 24);
	b = (UINT8)(r >> 16);
	g = (UINT8)(r >> 8);
	r = (UINT8)r;

The behaviour has been in place since PIL.

I've created #9067 to resolve this by improving the documentation.