Optimize image conversion for half and float formats.

[BlueCube3310]

Optimizes conversion between RGBA variants of half and float image formats.
On average, this makes the conversion process ~7 times faster, depending on the formats. This is especially important for RGB images, which need to be converted to RGBA by most GPUs.

Build - Windows 64-bit, production
CPU: Ryzen 9 5900X 12-Core
RAM: 64 GB DDR4 3000 MHz

4096x4096 image:

Conversion	Unopt	Opt
RH - RGH	133ms	14ms
RH - RGBH	157ms	28ms
RH - RGBAH	176ms	31ms
RGBH - RGBAH	226ms	32ms
RGBAH - RH	163ms	10ms
RGBAH - RGBH	214ms	22ms

MRP: image-half-convert.zip

[clayjohn]

Looks great!

[Calinou]

Tested locally, it works as expected.

Benchmark

Using an optimized editor binary (optimize=speed lto=full).

Testing project: image-half-convert-benchmark.zip
(only source format is taken into account in the benchmark)

PC specifications

• CPU: Intel Core i9-13900K
• GPU: NVIDIA GeForce RTX 4090
• RAM: 64 GB (2×32 GB DDR5-5800 C30)
• SSD: Solidigm P44 Pro 2 TB
• OS: Linux (Fedora 39)

The time taken to create an image and convert its format 1,000 times (the image is recreated on every iteration seems identical before and after this PR. Here it is for reference:

Format	After (this PR)
RH	77.5 ms
RGH	99.5 ms
RGBH	119.5 ms
RGBAH	140.8 ms
RF	65.5 ms
RGF	77.1 ms
RGBF	75.2 ms
RGBAF	79.9 ms

I'm a bit surprised I don't see any performance improvement in this scenario, but at least it's not slower than before.

Note that the stripped binary size also grows by 8 KB with this PR, likely due to the addition of a template function. It's not a huge issue but I thought it'd be worth mentioning nonetheless.

[BlueCube3310]

Tested locally, it works as expected.

Thank you for the review!

I'm a bit surprised I don't see any performance improvement in this scenario, but at least it's not slower than before.

The first conversion happens between the source 8-bit uint image and the specified half/float format. In order to get the correct results, only the second conversion/match statement has to be measured.
This PR only affects the conversion times between halfX-halfY and floatX-floatY conversions, since these ones have the same data type and can be handled with a simple memcpy, instead of the slower fallback function. I apologise if I hadn't been clear about that. The source format also needs to differ from the destination.

Here's the benchmark with the different measurements: image-half-convert-benchmark.zip

[akien-mga]

Thanks!