Re: [Lcms-user] small question about transicc conversion

[Michal S. <so...@zi...>]

Ah, great. Thanks for quick fixing.

Regarding bugs, I think I found small cosmetic bug in transicc 
(although with potential side effects) - if the profile contains 
unicode (utf-16be in this case) strings, it is treated as a regular 
ascii string - example output:

Output profile:
sG 4ICpeeec ecpulitn e
Cprgt20 nentoa oo osri


Btw - when testing with sRGB v4 profile:

transicc -t1 -v3 -i sRGB_v4_ICC_preference.icc -o sRGB_v4_ICC_preference.icc

R? 0 G? 0 B? 0
R=-0.3043 G=-0.0087 B=0.0021
[PCS] Lab=(10.9194,0.0195,-0.0078) XYZ=(1.2056,1.2497,1.0314)

R? 1 G? 1 B? 1
R=0.7644 G=1.1842 B=1.0450
[PCS] Lab=(11.1360,0.0039,0.0039) XYZ=(1.2345,1.2802,1.0557)

R? 2 G? 2 B? 2
R=1.8321 G=1.7806 B=1.9141
[PCS] Lab=(11.3405,-0.0117,-0.0039) XYZ=(1.2621,1.3093,1.0803)

R? 3 G? 3 B? 3
R=2.8999 G=2.9735 B=2.9570
[PCS] Lab=(11.5511,0.0234,0.0078) XYZ=(1.2926,1.3398,1.1047)

R? 7 G? 7 B? 7
R=6.6369 G=6.8504 B=7.1287
[PCS] Lab=(12.3430,0.0117,-0.0078) XYZ=(1.4069,1.4587,1.2039)


R values in particular - -0.30(0), 0.76(1), 6.64(7) - are they proper in 
context of PCS -> sRGB transfer ? Even if after rounding we get proper 
integers (0, 1, 7), they seem dangerously off the spot. Following one of 
the whitepapers from color.org, no-bpc v2 profile ("type 1 v2 profile") 
should roughly give the same results as v4, and theoretically, 
shouldn't provide worse accuracy. If the profile is fine, maybe there is 
some other bug lurking somewhere.

http://www.color.org/srgbprofiles.xalter
http://www.color.org/ICC_White_Paper_26_Using_the_V4_sRGB_ICC_profile.pdf


Regards
Michal