HDR: speed up reading by around 4x

[aras-p]

Description

Most of the cost in HDR file reading was converting from RGBE to floats, inside ldexpf(), which at least on Windows/VS2022 spends most of the time inside _ctrlfp(). But we only have 256 possible exponents in total, so just use a precomputed table.

On my PC (Windows 10, VS2022, Ryzen 5950X) with #3588 applied, this change gets file read time for an 8x resolution HDR image from 1.10s down to 0.27s

Tests

No new tests necessary.

Checklist:

• I have read the contribution guidelines.
• If this is more extensive than a small change to existing code, I
  have previously submitted a Contributor License Agreement
  (individual, and if there is any way my
  employers might think my programming belongs to them, then also
  corporate).
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite
  (adding new test cases if necessary).
• My code follows the prevailing code style of this project.

[lgritz]

LGTM

[ThiagoIze]

I know this is 2 years old, but I came across this and just wanted to point out that the table could be replaced with some floating point manipulation. Powers of 2 in IEEE754 are all represented by changes in the exponent. The sign and mantissa never change. So I think this could be further optimized by just adding the rgbe[3] - (128 + 8) to a 1.0f's exponent. This is just a few instructions and would pollute the cache much less, so I think it would result in equal or faster performance. Even if it's not much of a speedup because the bottleneck now lies elsewhere, it would at least remove a big ugly table.

I don't know if I'll have time to try this out myself, so in case I don't, I leave this here for anyone that might be inspired to try it out.

[aras-p]

@ThiagoIze yeah, so your suggestion is essentially "manual reimplementation" of ldexpf, but without all of the handling that makes the actual C function be slow (floating point control word handling, possible floating point exceptions, handling of too large or too small exponents etc.). It might be faster or at least cleaner indeed.