Hi,
Is correct ;-) This is a testimony of how destructive could be temporary
storage.=20
XYZ does exhibit a gamma of 1.0, sRGB a gamma of 2.2, if you converts =
from
a space of gamma 1.0 to an space of gamma 2.2, you get loss of data.
This effect is also magnified by the fact you are using 8 bits of =
temporary storage,
so, form 16 bit, gamma 1 to 8 bits gamma 2.2, there is a LOT of loss!
28589 ( 0x6FAD ) stored as 8 bits is 0x70 (by rounding), 28704 is =
0x7020,
rounding also 0x70. In your case, the 8 bits quantization is responsible =
of=20
these different numbers.
RGB8 --> XYZ16 --> RGB8 will work fine, since XYZ16 has enough =
precission
(16 bits) to recover the gamma loss.
Anyway, rare is the case of transforms completly reversible. If you are =
feeding=20
a profile with a color out of gamut, the profile will remap it on its =
own, depending
heavely on intent used. On in-gamut colors, the dance of numbers is =
minimized,
but, specially on perceptual intents, is not guarenteed forward and then =
reverse
will yeld same original values. sRGB does this and lcmslabi also do, but =
not all
profiles will behave same.
Regards,
Marti.
----- Original Message -----=20
From: Richard Mitanchey=20
To: Lcms-User list=20
Sent: Wednesday, August 22, 2001 12:59 PM
Subject: [Lcms-user] XYZ16 --> RGB8 --> different XYZ16
Hi,
I observed a strange behaviour with two kinds of transforms :
* First, I tested RGB8 --> XYZ16 --> RGB8, and it worked fine, with =
the following numbers:
(246,246,246)-->(28704,30197,32894)-->(246,246,246)
* I also tried XYZ16 --> RGB8 --> XYZ16, and I got the following =
numbers
(28589,30083,32768)-->(246,246,246)-->(28704,30197,32894)
My profiles are :
"sRGB Color Space Profile.icm"
"LCMSXYZI.icm",=20
and transforms parameters are :
INTENT_ABSOLUTE_COLORIMETRIC, and cmsFLAGS_NOTPRECALC
Am I missing something?
Any clue?
BTW: Just a few words to say that little cms appears to me the best =
ICM color management library for PC's
Thanks again, Marti!
Richard Mitanchey
|
