It just occurs to me -

as the lookup table mechanism for gamma-correction has now been 
implemented anyway, including a 16-bit variant:

What stops us from using the very same mechanism to handle High Dynamic 
Range images?

OpenEXR uses "half-precision" floating-point numbers to store image 
data; while at first glance they call for being converted to proper 
floating-point values straight away, they are actually 16-bit values, 
which could just as well be handled with a look-up table.

Radiance HDR uses 8-bit integers for each color channel plus a common 
8-bit exponent; again, this combines to 16 relevant bits per channel.


Hum... maybe it's time to provide a command-line / INI file parameter to 
choose between optimization for speed and optimization for memory 
consumption.

Post a reply to this message