Menu
▾
▴
Re: [Lcms-user] odd change in 2.13
|
From: <mar...@li...> - 2022-03-24 15:48:23
|
Hi,
Thanks for reporting the issue. The reason for getting same results was
both programs were using same *.so and therefore both were using 2.13
Actually the issue was due to a bug, that was there from the old days
but was not triggered because unbounded mode was limited.
Now, 2.13 has extended unbounded mode support and some profiles, like
the one you sent, can work in such conditions. For relative
colorimetric, the profile reports a L* of -400, which is obviously out
of gamut. 2.12 didn't obtain this value because didn't handle such
extended values and returned zero. 2.13 does, and unfortunately there
was no code on BPC algorithm to clip negative L* to zero. As a result
the black point was detected wrongly.
This bug needs a particular profile and also needs a transform using
black point compensation. Not very common. It is now fixed in github
Regards
Marti
On 2022-03-23 21:03, Derek B. Noonburg wrote:
> Thanks for taking a look at this.
>
> On Wed, 23 Mar 2022 14:37:35 +0100
> Marti Maria <mar...@li...> wrote:
>
>> > On 22 Mar 2022, at 23:10, Derek B. Noonburg
>> > <de...@gl...> wrote:
>> >
>> > I'm seeing very different output in one particular case, after
>> > upgrading from 2.12 to 2.13 (or 2.13.1).
>> >
>>
>> Checked your profile and gives same results to me, tested on Debian
>> 11, system lcms2 (from Debian, which is 2.12) vs. compilation of 2.13
>> on /usr/local
>>
>> marti@debian:~$ /usr/bin/transicc -c1 -s -ex -i profile.icc -b -t1
>> ...
>
> There's something strange going on here. I can reproduce my results
> with transicc, so I'm pretty sure it's not an issue with transicc vs my
> sample code.
>
> I just rebuilt lcms 2.12 and 2.13.1 on my Linux system (Slackware 14.2,
> gcc 5.5.0), and I get this:
>
> $ ./lcms212/bin/transicc -c1 -s -ex -i profile.icc -b -t1
> LittleCMS ColorSpace conversion calculator - 5.0 [LittleCMS 2.12]
> Copyright (c) 1998-2020 Marti Maria Saguer. See COPYING file for
> details.
>
> Enter values, 'q' to quit
> R? 97
> G? 97
> B? 97
>
> R=0x1E G=0x1E B=0x1F
>
> Enter values, 'q' to quit
> R? q
> Done.
>
> $ ./lcms2131/bin/transicc -c1 -s -ex -i profile.icc -b -t1
> LittleCMS ColorSpace conversion calculator - 5.0 [LittleCMS 2.13]
> Copyright (c) 1998-2022 Marti Maria Saguer. See COPYING file for
> details.
>
> Enter values, 'q' to quit
> R? 97
> G? 97
> B? 97
>
> R=0x9F G=0x9F B=0x9F
>
> Enter values, 'q' to quit
> R? q
> Done.
>
> I also built 2.12 and 2.13.1 on Windows, using the provided VC 2019
> project files (default config - win32 debug), and got the exact same
> results.
>
> I have no idea why we're seeing different behavior with transicc 2.12.
> I can't think of anything that would explain that. I ran both versions
> under valgrind on Linux, and it didn't report any errors.
>
> One other note: I believe the 0x1e results are correct. I discovered
> this odd behavior looking at a regression test on my Xpdf build. The
> 2.12 output (0x1e) matches the output I see from Adobe.
>
> I'll be happy to do more testing, if there's anything that you think
> might help track this down.
>
> - Derek
>
>
>> LittleCMS ColorSpace conversion calculator - 5.0 [LittleCMS 2.12]
>> Copyright (c) 1998-2020 Marti Maria Saguer. See COPYING file for
>> details.
>>
>> Enter values, 'q' to quit
>> R? 97
>> G? 97
>> B? 97
>>
>> R=0x9F G=0x9F B=0x9F
>>
>> Enter values, 'q' to quit
>> R? q
>> Done.
>> marti@debian:~$ transicc -c1 -s -ex -i profile.icc -b -t1
>> LittleCMS ColorSpace conversion calculator - 5.0 [LittleCMS 2.13]
>> Copyright (c) 1998-2022 Marti Maria Saguer. See COPYING file for
>> details.
>>
>> Enter values, 'q' to quit
>> R? 97
>> G? 97
>> B? 97
>>
>> R=0x9F G=0x9F B=0x9F
>>
>> Enter values, 'q' to quit
>> R? q
>> Done.
>>
>> Should I use your exact program to reproduce the issue? The transicc
>> utility does basically same.
>>
>> BTW I have checked ColorSync utility on relcol to sRGB. ColorSync
>> does not have black point compensation, but turning it off on both
>> sides, they agree on same value: 30
>>
>> Regards
>> Marti
>>
>>
>>
>> > The input profile is from a PDF file, and claims to be e-sRGB. With
>> > INTENT_RELATIVE_COLORIMETRIC and cmsFLAGS_BLACKPOINTCOMPENSATION,
>> > the transform to sRGB (builtin profile) produces completely
>> > different results.
>> >
>> > The code looks like this (error checking and cleanup intentionally
>> > omitted):
>> >
>> > #include <stdio.h>
>> > #include <lcms2.h>
>> >
>> > int main() {
>> > cmsHPROFILE inputProfile = cmsOpenProfileFromFile("profile.icc",
>> > "r"); cmsHPROFILE outputProfile = cmsCreate_sRGBProfile();
>> > cmsHTRANSFORM xform = cmsCreateTransform(inputProfile, TYPE_RGB_8,
>> > outputProfile,
>> > TYPE_RGB_8, INTENT_RELATIVE_COLORIMETRIC,
>> > cmsFLAGS_BLACKPOINTCOMPENSATION);
>> > unsigned char in[3] = {0x61, 0x61, 0x61};
>> > unsigned char out[3];
>> > cmsDoTransform(xform, in, out, 1);
>> > printf("%02x %02x %02x\n", out[0], out[1], out[2]);
>> > }
>> >
>> > and I'm attaching the profile.
>> >
>> > The results with 2.12 are "1e 1e 1e" and with 2.13 (same with
>> > 2.13.1) are "9f 9f 9f".
>> >
>> > I pulled the profile out of a PDF file, so it's possible there's a
>> > problem in the profile itself -- but I'm not seeing any error
>> > messages from LCMS if I use cmsSetLogErrorHandler.
>> >
>> > If anyone has some idea of what's going on here, I'd love to know.
>> >
>> > Thanks!
>> > <profile.icc>_______________________________________________
>> > Lcms-user mailing list
>> > Lcm...@li...
>> > https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
|
