Thanks for your reply, it is quite satisfactory.
Le quartidi 14 fructidor, an CCXIII, Marti a écrit :
> Well, this is actually the ICC encoding, as defined in the ICC spec.
Ok. I did not know that ICC went into such details.
> // Convert them to "normal" floating point Lab
> // range L*(0 -> 100) ab*(-128.0 -> +127.996)
>
> Lab.L =
> Lab.a = ... do the scaling here using L100, a100, b100...
> Lab.b =
>
> // From floating point to 16-bits ICC encoding
> cmsFloat2LabEncoded(wIn, &Lab);
As far as I can see in the source, the role cmsFloat2LabEncoded is to (1)
clamp the values of L, a and b, and (2) encode them as unsigned 16-bits
integers, with 0 -> 0, 65535 -> 100 for L and 0 -> -128, 65535 -> 128-1/256
for a and b.
Is it safe to assume that this encoding will be kept, and so just write:
wIn[0] = L100 * 257;
wIn[1] = a100 * 65535 / 100;
wIn[2] = b100 * 65535 / 100;
(with maybe some tweaks to have proper rounding)?
> That's all. You can now use cmsDoTransform() directly. Of course this
> will call your function for each color, so if you want performance you
> may need to optimize the code as much as possible.
Of course. By the way, I understand that the "normal" Lab decoder is just a
pointer to a function that happens to be the default function. In that case,
there is no overhead in using a custom decoder instead of the builtin one.
Am I right ?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
