Added DDS BC5 reading

[radarhere]

Helps #5499

After declaring BC5_UNORM format to be available in DdsImagePlugin, all that was wrong was that the alpha channel was set to zero. I've fixed that by setting the image mode to RGB instead of RGBA.

As for BC5_SNORM, "the data is encoded in SNORM range", meaning that it is signed rather than unsigned. The key changes to read this data were changing a0 and a1 in the struct from UINT8 to INT8, and then adjusting it into the UNORM range with

a0 = (b.a0 + 255) / 2;
a1 = (b.a1 + 255) / 2;

The sample image from the issue has a fourcc of "BC5S". I've also added a hexeditted version that uses the DX10 fourcc value like the other versions here.

For BC5_TYPELESS, https://docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-resources-intro#strong-vs-weak-typing

In a type less resource, the data type is unknown when the resource is first created. The application must choose from the available type less formats

My conclusion is that 'typeless' formats don't actually specify whether they should be UNORM or SNORM. So I have continued our existing tradition of treating TYPELESS as UNORM -

Pillow/src/PIL/DdsImagePlugin.py

Line 158 in 16b9cad

if dxgi_format in (DXGI_FORMAT_BC7_TYPELESS, DXGI_FORMAT_BC7_UNORM):

Pillow/src/PIL/DdsImagePlugin.py

Lines 165 to 169 in 16b9cad

	elif dxgi_format in (
	DXGI_FORMAT_R8G8B8A8_TYPELESS,
	DXGI_FORMAT_R8G8B8A8_UNORM,
	DXGI_FORMAT_R8G8B8A8_UNORM_SRGB,
	):

See https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpcr2/98e2dbc9-3a1d-4ab2-93e3-152eeebd17a3 for documentation that

• DXGI_FORMAT_BC5_TYPELESS is 0x00000052 = 82
• DXGI_FORMAT_BC5_UNORM is 0x00000053 = 83
• DXGI_FORMAT_BC5_SNORM is 0x00000054 = 84.

[hugovk]

Let's also add this to release notes 👍

[radarhere]

Sure, done