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? _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
