Kai-Uwe Behrmann schrieb:
Input is floating point numbers with values over 1.0 .
Kai-Uwe,
recently I noticed, that - even for float (e.g. TYPE_RGB_DBL) transforms - LCMS first converts float to 16-bit integer and internally carries out the transformation with integer numbers:
static
LPBYTE UnrollDouble(register _LPcmsTRANSFORM info,
register WORD wIn[], register
LPBYTE accum)
{
double* Inks = (double*) accum;
int nChan = T_CHANNELS(info -> InputFormat);
int i;for (i=0; i < nChan; i++) {
double v = floor(Inks[i] * 65535.0 + 0.5);
if (v > 65535.0)
v = 65535.0;
if (v < 0)
v = 0;
wIn[i] = (WORD) v;
}
return accum + (nChan + T_EXTRA(info ->InputFormat)) * sizeof(double);
}
So I'm also wondering, whether 16-bit precision is sufficient for very dark colors in HDR images, particularly in conjunction with linear luminance color spaces, like e.g. an XYZ PCS?
Btw:
* I think the above code snipplet also answers the question what
happens to RGB input values > 1.0 * For XYZ input values (e.g. for a PCS->device transform), the valid
input range is up to 1.99996, but this does not imply that Y > 1.0
is mapped to RGB values > 1.0.-Gerhard
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user
