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

clipka wrote:
> 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?

Waste of memory happens first of all because there is always that 5 
channel 32 bit float image buffer used even for e.g. a simple 1 channel
grayscale OpenEXR file. Also for the most common case (3 rgb channels 
without alpha) there are 2 channels "wasted".

> 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.
>

While it indeed might be a good idea to implement a "half" image 
container format (because this is not file format specific), I do not 
believe there should be a container for every possible floating point 
representation just because it is used by one even outdated (as Greg 
Ward himself called it almost ten years ago) file format. Otherwise 
there would be also need to implement luts for the LogLUV format and 
others that are e.g. supported by TIFF (that also can store "half" data 
and as mentioned almost everything else).

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

According to some benchmarking I've done (well, not with POV-Ray but 
with random and sequential access to image data using 16 and 32 bit 
floats there is no speed difference even if the conversion from 'half' 
to 32 bit 'float' requires a few clock ticks. Guess it has to do with 
better utilization of the cache line or whatever.

Note also that 'half' is implemented as class by ILM and the conversion 
from 'half' to float (automatically done when e.g. using the "=" 
operator) is there already implemented by using a LUT.
The problem is that someone might want to compile without support for 
OpenEXR.

-Ive

Post a reply to this message