|
From: | Larry Gritz |
Subject: | Re: [Openexr-devel] 8 bit int? |
Date: | Tue, 23 Jun 2009 15:25:58 -0700 |
User-agent: | Thunderbird 2.0.0.21 (Macintosh/20090302) |
Florian Kainz wrote:
One problem that needs to be solved is how the mapping between floating-point numbers and integers gets encoded.
How does it work for the currently-supported int32? I'd be happy with something analogous, only fewer bits.
I am not sure that "256 levels are more than enough" for masks.
Of course there are many texture use cases that must be 16 bit or float. Nevertheless, a great many 8-bit files pop up in our productions, with no ill effect, and I'd like to take advantage of the file size, I/O, memory, and performance without forcing everything to more precision that is needed.
You could read each tile into a temporary buffer and convert the pixels to 8 bits during the transfer from the buffer to the tile cache. (Yes, I know it's not the most efficient method ever, but you can do it without waiting for an 8-bit EXR data type.)
Neat idea! If fp16 files that only use ~256 values really do compress especially well, then I could store as fp16 and have a special header tag that means "it's ok to keep this internally as 8 bits."
That's a potentially great solution. Do you have a specific suggestion for name and semantics of header attributes that would indicate that the exr file has "extra" precision and range that could be dropped? May as well choose a common convention, in case others also want a solution like this.
-- lg -- Larry Gritz address@hidden
[Prev in Thread] | Current Thread | [Next in Thread] |