BGR;15/16 scaling

[Yay295]

Currently when getting a BGR;15/16 pixel value, the result is scaled from 0-31 to 0-255.

Pillow/src/libImaging/Access.c

Lines 90 to 108 in de18f55

	static void
	get_pixel_BGR15(Imaging im, int x, int y, void *color) {
	UINT8 *in = (UINT8 *)&im->image8[y][x * 2];
	UINT16 pixel = in[0] + (in[1] << 8);
	char *out = color;
	out[0] = (pixel & 31) * 255 / 31;
	out[1] = ((pixel >> 5) & 31) * 255 / 31;
	out[2] = ((pixel >> 10) & 31) * 255 / 31;
	}
	static void
	get_pixel_BGR16(Imaging im, int x, int y, void *color) {
	UINT8 *in = (UINT8 *)&im->image8[y][x * 2];
	UINT16 pixel = in[0] + (in[1] << 8);
	char *out = color;
	out[0] = (pixel & 31) * 255 / 31;
	out[1] = ((pixel >> 5) & 63) * 255 / 63;
	out[2] = ((pixel >> 11) & 31) * 255 / 31;
	}

Storing one of these pixels is also scaled, though using a different algorithm.

Pillow/src/_imaging.c

Lines 607 to 623 in de18f55

	if (!strcmp(im->mode, "BGR;15")) {
	UINT16 v = ((((UINT16)r) << 7) & 0x7c00) +
	((((UINT16)g) << 2) & 0x03e0) +
	((((UINT16)b) >> 3) & 0x001f);
	ink[0] = (UINT8)v;
	ink[1] = (UINT8)(v >> 8);
	ink[2] = ink[3] = 0;
	return ink;
	} else if (!strcmp(im->mode, "BGR;16")) {
	UINT16 v = ((((UINT16)r) << 8) & 0xf800) +
	((((UINT16)g) << 3) & 0x07e0) +
	((((UINT16)b) >> 3) & 0x001f);
	ink[0] = (UINT8)v;
	ink[1] = (UINT8)(v >> 8);
	ink[2] = ink[3] = 0;
	return ink;

Should scaling be done at all for these modes when getting/setting pixels? Also, the pixel order is backwards. It seems that these functions are actually converting to/from RGB rather than just returning the BGR;15/16 values.

[radarhere]

These modes aren't actually used by any image format (the rawmodes are, but not the modes). So a discussion about how they should behave is just about consistency with how the rest of Pillow behaves.

But speaking of the fact that they aren't used

• Support for creating images with these modes was added in Support creating BGR;15, BGR;16 and BGR;24 images, but drop support for BGR;32 #7010 in Pillow 9.5.0 in response to Endianness is inconsistent #6769 (comment).
• Support for access for these modes was added in Support BGR;15, BGR;16 and BGR;24 access, unpacking and putdata #7303 in Pillow 10.1.0 to help Fix putdata() for I;16N on big-endian #7209 and Add tp_richcompare handler for Imaging_Type/ImagingCore #7260

If your goal is to progressively ensure that all Pillow operations are supported for all modes, I don't think building out support for them in a test-driven development fashion is a worthwhile endeavour if there's no evidence that they would be used.

I'm more in favour of the idea from #2228 of just removing BGR;15, BGR;16 and BGR;24 as modes entirely.

[Yay295]

I agree with removing them, but I think that will require a deprecation period. Slightly changing how they work doesn't require a deprecation period, so it could be done at the same time.

[Yay295]

Also, the two converters changed in #7972 should be added as packers. There's not really any difference between a packer, an unpacker, and a converter, so they could all be grouped into one list.

[radarhere]

I've created #7978 to deprecate them.

Slightly changing how they work doesn't require a deprecation period, so it could be done at the same time.

The modes are currently supported for image creation, converting to the mode, access, unpacking and putdata(). There's no way to use the final image result for these modes except by getting the pixel values. So if you're using these modes, and then you find the scale of the pixel values returned is different, you have to rewrite your code.

Introducing a breaking change to a feature at the same time as deprecating it seems counterproductive.

Also, the two converters changed in #7972 should be added as packers. There's not really any difference between a packer, an unpacker, and a converter, so they could all be grouped into one list.

I don't see anything special about converting RGB to BGR;15 or BGR;16 that means we need packers for them specifically. If you want to restructure packers, unpackers and converters in general, then I suggest you start a new conversation about that.

[Yay295]

How does packing work without a packer? There is currently a packer from BGR;15/16 to BGR;15/16, but there is not a packer from RGB to BGR;15/16. There already are unpackers from BGR;15/16 to RGB.

[radarhere]

How does packing work without a packer?

You think that Pillow is currently packing without a packer, for some scenario? Could you provide an example of that scenario?

There is currently a packer from BGR;15/16 to BGR;15/16,

Yes.

but there is not a packer from RGB to BGR;15/16.

...so? I don't see how that contradicts anything, or why there would have to be at the moment.

There already are unpackers from BGR;15/16 to RGB.

Yes.

I think you're drifting off-topic from BGR;* scaling, and this would be better asked in a new conversation.

[radarhere]

#7978 has been merged, deprecating these modes, so I'm in favour of closing this, rather than introducing a breaking change to deprecated functionality.