Re: [Openexr-devel] 8 bit int?

[Larry Gritz]

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