BGR;15/16 scaling

[Yay295]

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

https://github.com/python-pillow/Pillow/blob/de18f555686b59466ead87ad21bbc053f070391b/src/libImaging/Access.c#L90-L108

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

https://github.com/python-pillow/Pillow/blob/de18f555686b59466ead87ad21bbc053f070391b/src/_imaging.c#L607-L623

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 #7010 in Pillow 9.5.0 in response to https://github.com/python-pillow/Pillow/issues/6769#issuecomment-1364769723.
• Support for access for these modes was added in #7303 in Pillow 10.1.0 to help https://github.com/python-pillow/Pillow/pull/7209 and https://github.com/python-pillow/Pillow/pull/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 https://github.com/python-pillow/Pillow/pull/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.