A couple of random thoughts: compression should not be a problem - existing methods could either be specialized for 8 bits, or the 8-bit data could be padded to 16 bits.
One problem that needs to be solved is how the mapping between floating-point numbers and integers gets encoded. During file reads the library automatically converts between pixel formats; to do this correctly, the libray must know about the mapping. And of course, application code must know about this too. Your mail suggests that this mapping should be selectable per channel. I am not sure that "256 levels are more than enough" for masks. If a mask with a smooth and not very steep gradient is used to interpolate between two layers that contain essentially flat fields, the stair steps in the mask can become visible. > "Use fp16 with piz, it compresses as well as 8 bit" -> on disk, maybe, > but it takes up twice the space in an in-memory tile cache. 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.) _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
