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?
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
