Re: [Openexr-devel] 8 bit int?

[Brendan Bolles]

On Jun 23, 2009, at 4:13 PM, Larry Gritz wrote:

> I'm tempted (not that this is an immediate thing at all) to try the  
> solution "store as fp16, with header attribute that hints that it  
> can be down-converted to uint8 upon read" and see if that works.   
> Thanks for the suggestion!


I think that's the way to go.  Keep your 8 bits out of OpenEXR! :)

One of the best things about OpenEXR (in my opinion) is that it  
pushes people toward a linear workflow because every reader should  
know that it can't just throw the fp16 pixels on screen - they need  
conversion.  With an 8-bit image, that's not going to be the case,  
and 8-bit isn't good enough to store a linear image.

Given that you can store any kind of attribute you want in an EXR,  
you should be able to come up with a system that flags a file to say  
it originated from an 8-bit image and the reader can feel free to  
down-convert (after converting linear to sRGB in float).  The  
conversion operation will be very fast because you can make an fp16- 
>sRGB->uint8 LUT.

Granted, I imagine the only benefit to this is that the texture  
buffer itself would be held 8-bit in memory.  I'm assuming the  
renderer is still converting to float for each sample.

Anyway, this solution would require no additional EXR retooling and  
the files you made would still be proper EXRs, adhering to the  
standard.  Everybody wins!


Brendan


PS - if you put your 0-255 into a uint32 channel, does the  
compression help to take care of the extra bits?