Re: [Openexr-devel] Processing in 'half' float

[Drew Hess]

"Luc-Eric Rousseau" <address@hidden> writes:

> If I'm not mistaken, the c++ class 'half' relies on converting to and from 
> 32-bit float to provide mathematical operators.  
>
> Is it reasonable to consider refactoring existing c++ image processing code 
> written for 32-bit floats to work in 'half'?  What I'm looking for is saving 
> RAM and avoid converting images for processing for cases like blurs and 
> effects more complex than a per-channel look-up-table can handle.
>
> Is anyone doing something like this, or is the performance cost too high?  
>
> Alternatively, are there fast software-only /,*,+,-, operators implementation 
> available for 'half' that won't go through 32-bit float?  


Lots of our image-processing code works in half and it runs pretty
well.  In the past, we've measured a 10-20% speed hit vs. float; this
is due to converting half<->float and depends on how good your
compiler's optimizer is.

And, as you point out, if you're aggressive about encoding functions
in 2^16 tables, you can often make things faster than computing with
float.  See halfFunction.h for a class which makes this easier.

Finally, half is a great format for image processing on GPUs.

d