Re: [Openexr-devel] 16-bit unsigned integer

[Robin Rowe]

Florian,

Thanks for the reply.

> 16-bit floating-point numbers have enough range and resolution for red,
> green, blue, alpha, and similar channels that represent "continuous"
> quantities.

I'm not sure I understand the implication. Is it your advice to accept the
data loss from squeezing an unsigned short into the range of 0 to 1.0 in a
half?

> If you have integer per-pixel data that happen to fit into 16 bits,
> you can store them in a 32-bit integer channel.  OpenEXR will preserve
> the data exactly, and the PIZ compression method will take advantage
> of the fact that only 16 of the 32 bits are used.  If the remaining
> 16 bits in each pixel contain only zeroes, PIZ will compress them
> to almost nothing.

The issue is speed more than size. What you propose will be slower than
saving the data directly, and create a pointless 16-bit to 32-bit to 16-bit
process for 16-bit tools.

I understand your reservation about adding more pixel types to a design, and
if I was asking for a significant difference such as 8-bit operation I could
better understand your reasoning. However, with 16-bit unsigned and 16-bit
half why would there be any overhead supporting both? Are you doing
something to 16-bit half in the act of reading it? Isn't it just data?

Cheers,

Robin
---------------------------------------------------------------------------
address@hidden   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software