Hi,
Back from vacation, so late to the discussion :-( But here I am, and would try to clarify some of these questions. lcms precision is currently limited to 16 bits. This is because lcms tries to give a good balancing between precision vs. speed. Doing the interpolation and unpacking in floating point would result in a severe slowdown. This is not perfect, I know, but still makes the CMM fast enough for most real world usage. The *_DBL format specifiers are just a way to make things easier for programmer, and does NOT mean that internal computations are done in 16 bit. The clipping of high values, specially on XYZ above 100 or RGB above 1.0 is not so good on 1.13, and I have some changes on that for the incoming 1.14 Non-encodeable values are not going to be supported anyway, this would mean a refactoring of critical parts and I doubt this would be of any use at all. But as said, you can expect some improvement in that area for 1.14 Regards, Marti Maria The little cms project http://www.littlecms.com ----- Original Message ----- From: "Gerhard Fuernkranz" <[EMAIL PROTECTED]> To: "Lcms Liste" <[EMAIL PROTECTED]> Cc: "Kai-Uwe Behrmann" <[EMAIL PROTECTED]> Sent: Thursday, September 09, 2004 9:45 PM Subject: Re: [Lcms-user] over white color clipping 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 ------------------------------------------------------- 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. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
