Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Kai-Uwe Behrmann]

Am 27.02.2015 um 15:44 schrieb Elle Stone:
> On 02/23/2015 02:42 PM, Kai-Uwe Behrmann wrote:
>> LCMS is just one CMM, with its prefered set of min and maximal values
>> for certain colour spaces. I could never find it convincing to have
>> CIE*L expressed in % in LCMS, the same goes for Cmyk - a printing space.
>> But LCMS uses these fixed value ranges from inbuild defaults.
>
> I'm not sure what you mean by "fixed value ranges from inbuild defaults".
>
> Since LCMS version 2 there is no clipping during conversions from RGB
> to LAB, XYZ, or another RGB color space. There's also no clipping upon
> export as long as the file format can hold 32-bit floating point RGB
> values outside the range 0-1 floating point.

Oh, I wrote from remembering lcms1, which is not much used these days.
You are right that the default value range changed with lcms2 to 0-1 for
floating point, which appears good to me.

> Of course there are precision limitations on how high those 32-bit
> floating point tiff values can go before there's too little precision
> for useful image editing, though I don't know where the line should be
> drawn.

Wikipedias Logluv_TIFF article links to the following:
http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

> Are there differences in the number of stops that can be held in
> 32-bit floating point tiffs vs 32-bit floating point OpenEXR images?