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