lcms-user — For users of the little cms library

[Lcms-user] Did X-Rite use LCMS?

[Kang W. H. <beb...@gm...>]

Just found there is a "CORE_RL_lcms_.dll" in the i1Profiler folder. And
there are jpeg, libxml, magick, png and tiff .dll files. Other .dll files
are obviously dependent libraries that i1Profiler uses. Does that mean
X-Rite uses LCMS as i1Profiler's color engine? X-Rite always claimed they
use their own i1Prism color engine. I'm just curious.

Kang-Wei

Re: [Lcms-user] Unexpected gray to RGB result

[<mar...@li...>]

Hi,

Thanks for checking.

> One more question, if I may: You wrote that the fix is in the "algorithm
to detect those bad profiles". What corrections would be needed to generate
a good profile in the first place?

ICC spec expects a "good" V4 perceptual profile to return "perceptual black"
on darkest colorant (gray=0). This is around Lab=(3.14, 0, 0) or XYZ=(
0.3357, 0.3479, 0.2869). 
You profile was trying to trick the CMM by returning Lab=(100, 0, 0) on the
darkest colorant. And made it crazy. Now it detects this and let you to take
full control.

Regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: Ralf Junker <ral...@gm...> 
Sent: Tuesday, November 29, 2022 10:35 AM
To: lcm...@li...
Subject: Re: [Lcms-user] Unexpected gray to RGB result

On 27.11.2022 17:44, mar...@li... wrote:

> Now it is fixed by
> https://github.com/mm2/Little-CMS/commit/caab4c07e60022a0f776b543eaa30
> 785e2bb42ed

Thanks for the fix. I confirm it works well. lcms2 now generates visually
identically image to Chromium, Firefox, and Gimp.

One more question, if I may: You wrote that the fix is in the "algorithm to
detect those bad profiles". What corrections would be needed to generate a
good profile in the first place?

Ralf


_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Unexpected gray to RGB result

[Ralf J. <ral...@gm...>]

On 27.11.2022 17:44, mar...@li... wrote:

> Now it is fixed by
> https://github.com/mm2/Little-CMS/commit/caab4c07e60022a0f776b543eaa30785e2bb42ed

Thanks for the fix. I confirm it works well. lcms2 now generates
visually identically image to Chromium, Firefox, and Gimp.

One more question, if I may: You wrote that the fix is in the "algorithm
to detect those bad profiles". What corrections would be needed to
generate a good profile in the first place?

Ralf

Re: [Lcms-user] Unexpected gray to RGB result

[<mar...@li...>]

Hello,

I was puzzled because I remember I added an algorithm to detect those bad
profiles and hot-fix them. Upon reviewing the code, the algorithm was there
but it failed on your profile!

So, you hit the rare case of gray profile + wrong V4 encoding + apparent
black point higher than L* > 50 + inverted curves.  All that was confusing
the black point compensation part that was supposed to fix the issue.

Thank you very much to help in finding a very elusive bug. 

Now it is fixed by
https://github.com/mm2/Little-CMS/commit/caab4c07e60022a0f776b543eaa30785e2b
b42ed

Best regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: Ralf Junker <ral...@gm...> 
Sent: Sunday, November 27, 2022 9:41 AM
To: lcm...@li...
Subject: Re: [Lcms-user] Unexpected gray to RGB result

Thanks for the fast answer!

> The embedded profile is wrong. It claims to be V4 and perceptual, but 
> fails to scale on perceptual black.

Here is the C code that generated the profile:

int main()
{
   const cmsCIExyY *whitepoint = cmsD50_xyY();
   int i;
   cmsUInt16Number values[256];
   cmsToneCurve *tonecurve;
   cmsHPROFILE profile;

   for(i = 0;  i < 256; i++) {
     values[i] = (255 - i) * 65535 / 255;
   }

   tonecurve = cmsBuildTabulatedToneCurve16 (0, 256, values);
   profile = cmsCreateGrayProfile(whitepoint, tonecurve);

   cmsSaveProfileToFile(profile, "gray-inverted.icc"); }

The goal is a profile which swaps blacks and whites, dark grays and white
grays, to create an inverted, negative grayscale.

The profile's purpose is testing image rendering software with color
correction using lcms2. I found WhackedRGB.icc for color images, but nothing
for grayscale.

> Other CMM may choose to reject the profile, lcms uses it, despite it 
> is wrong.

My bad, I take your point. Please note that the profile somehow works with
Chromium, Firefox and Gimp which all show whites on the left and blacks on
the right of the image. And they all show it identically.

Viewers which do not apply the profile show blacks on the left and whites on
the right.

> See https://color.org/specification/ICC.1-2022-05.pdf
>
> "6.3.4.3 PCS encodings for white and black"

Unfortunately, I am unable translate this technical specification into
lcms2 code. Could you suggest a function or a chapter in the documentation?
I found nothing obviously related, I'm afraid.

Grateful,

Ralf


_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Unexpected gray to RGB result

[Ralf J. <ral...@gm...>]

Thanks for the fast answer!

> The embedded profile is wrong. It claims to be V4 and perceptual,
> but fails to scale on perceptual black.

Here is the C code that generated the profile:

int main()
{
   const cmsCIExyY *whitepoint = cmsD50_xyY();
   int i;
   cmsUInt16Number values[256];
   cmsToneCurve *tonecurve;
   cmsHPROFILE profile;

   for(i = 0;  i < 256; i++) {
     values[i] = (255 - i) * 65535 / 255;
   }

   tonecurve = cmsBuildTabulatedToneCurve16 (0, 256, values);
   profile = cmsCreateGrayProfile(whitepoint, tonecurve);

   cmsSaveProfileToFile(profile, "gray-inverted.icc");
}

The goal is a profile which swaps blacks and whites, dark grays and
white grays, to create an inverted, negative grayscale.

The profile's purpose is testing image rendering software with color
correction using lcms2. I found WhackedRGB.icc for color images, but
nothing for grayscale.

> Other CMM may choose to reject the profile, lcms uses it, despite it
> is wrong.

My bad, I take your point. Please note that the profile somehow works
with Chromium, Firefox and Gimp which all show whites on the left and
blacks on the right of the image. And they all show it identically.

Viewers which do not apply the profile show blacks on the left and
whites on the right.

> See https://color.org/specification/ICC.1-2022-05.pdf
>
> "6.3.4.3 PCS encodings for white and black"

Unfortunately, I am unable translate this technical specification into
lcms2 code. Could you suggest a function or a chapter in the
documentation? I found nothing obviously related, I'm afraid.

Grateful,

Ralf

Re: [Lcms-user] Unexpected gray to RGB result

[<mar...@li...>]

Hi,

The embedded profile is wrong. It claims to be V4 and perceptual, but fails to scale on perceptual black. 

See https://color.org/specification/ICC.1-2022-05.pdf

"6.3.4.3 PCS encodings for white and black"
"Perceptual transforms developed to meet ICC specifications prior to version 4.0 frequently use zero to represent 
the black point, and thus do not conform to this specification."

Other CMM may choose to reject the profile, lcms uses it, despite it is wrong.

Regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: Ralf Junker <ral...@gm...> 
Sent: Saturday, November 26, 2022 11:13 PM
To: lcm...@li...
Subject: [Lcms-user] Unexpected gray to RGB result

I try to use lcms2 to convert gray to RGB, but the output differs considerably.

So I double-checked with

   jpgicc gray-inverted-profile-linear.jpg gray-rgb-linear.jpg

but the result is the same: Unexpected saturation of dark gray areas to pitch black.

As reference of the expected outcome, please take a look at gray-chromium.png to see how Chromium renders gray-inverted-profile-linear.jpg. Firefox and GIMP look just the same.

Am I missing something? I am grateful for any advice!

Ralf

PS I hope the list accepts attachments. If not please advice how to send the images in question.

[Lcms-user] Unexpected gray to RGB result

[Ralf J. <ral...@gm...>]

I try to use lcms2 to convert gray to RGB, but the output differs
considerably.

So I double-checked with

   jpgicc gray-inverted-profile-linear.jpg gray-rgb-linear.jpg

but the result is the same: Unexpected saturation of dark gray areas to
pitch black.

As reference of the expected outcome, please take a look at
gray-chromium.png to see how Chromium renders
gray-inverted-profile-linear.jpg. Firefox and GIMP look just the same.

Am I missing something? I am grateful for any advice!

Ralf

PS I hope the list accepts attachments. If not please advice how to send
the images in question.

[Lcms-user] [ANNOUNCE] Little CMS 2.14 released

[<mar...@li...>]

Little CMS 2.14 released


I am glad to the announce the release 2.14 of the Little CMS open source color engine.

Changes

 

               • lcms2 now fully implements ICC specification 4.4

               • New multi-threaded plug-in

               • several fixes to keep fuzzers happy

               • Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used

               • Added more validation against broken profiles

               • Add more help to several tools

 

ICC Version 4.4 and the multithreaded plug-in are important milestones. 

 

Fixes because fuzzers have been many, none of them harmful in terms   of exploits.

 

Reach it at:

https://www.littlecms.com/color-engine/

 

Downloads:

https://sourceforge.net/projects/lcms/files/latest/download

 

 

Best regards, 

Marti Maria The Little CMS project 
http://www.littlecms.com

Re: [Lcms-user] Multi-threading Little CMS Performance on Modern High-End Hardware

[<mar...@li...>]

Hi Noel,

Those are very good numbers, thanks for sharing!

Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: Noel Carboni <NCa...@Pr...> 
Sent: Monday, October 31, 2022 11:14 AM
To: mar...@li...; lcm...@li...
Subject: Multi-threading Little CMS Performance on Modern High-End Hardware

Hi Marti and Little CMS list members,

I've been exercising Little CMS on a new AMD Threadripper Pro system.  This machine has the AMD Ryzen Threadripper Pro 5975X processor with 32 cores (64 logical processors in Windows with SMT enabled).  My software divides up the color management processing into multiple threads depending on several factors including image size, cache sizes, etc.  I thought you might like to see some representative performance numbers from Little CMS doing RGB to RGB color transforms (from image to monitor profiles)...  Note that I am NOT using the Little CMS plug-ins, just the base code, compiled for Windows using Visual Studio 2022.

Performance Message: Total Time =  10.617 milliseconds, ConvertColorOf() - Completed color conversion using 63 simultaneous threads.  Image:  3032 x 2016 pixels x 16 bits per color.

Performance Message: Total Time =  15.247 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  3852 x 2598 pixels x 8 bits per color.

Performance Message: Total Time =  18.508 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  4246 x 3925 pixels x 16 bits per color.

Performance Message: Total Time =  50.934 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  8492 x 7850 pixels x 8 bits per color.

Performance Message: Total Time =  40.886 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  8492 x 7850 pixels x 16 bits per color.

Performance Message: Total Time = 241.950 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  8492 x 7850 pixels x 32 bits per color.

Extrapolating from the next to last 66 megapixel entry above, we're seeing more than 1.6 gigapixels per second color-transformed.

-Noel Carboni
 ProDigital Software

[Lcms-user] Multi-threading Little CMS Performance on Modern High-End Hardware

[Noel C. <NCa...@Pr...>]

Hi Marti and Little CMS list members,

I've been exercising Little CMS on a new AMD Threadripper Pro system.  This machine has the AMD Ryzen Threadripper Pro 5975X processor with 32 cores (64 logical processors in Windows with SMT enabled).  My software divides up the color management processing into multiple threads depending on several factors including image size, cache sizes, etc.  I thought you might like to see some representative performance numbers from Little CMS doing RGB to RGB color transforms (from image to monitor profiles)...  Note that I am NOT using the Little CMS plug-ins, just the base code, compiled for Windows using Visual Studio 2022.

Performance Message: Total Time =  10.617 milliseconds, ConvertColorOf() - Completed color conversion using 63 simultaneous threads.  Image:  3032 x 2016 pixels x 16 bits per color.

Performance Message: Total Time =  15.247 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  3852 x 2598 pixels x 8 bits per color.

Performance Message: Total Time =  18.508 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  4246 x 3925 pixels x 16 bits per color.

Performance Message: Total Time =  50.934 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  8492 x 7850 pixels x 8 bits per color.

Performance Message: Total Time =  40.886 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  8492 x 7850 pixels x 16 bits per color.

Performance Message: Total Time = 241.950 milliseconds, ConvertColorOf() - Completed color conversion using 64 simultaneous threads.  Image:  8492 x 7850 pixels x 32 bits per color.

Extrapolating from the next to last 66 megapixel entry above, we're seeing more than 1.6 gigapixels per second color-transformed.

-Noel Carboni
 ProDigital Software

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[<mar...@li...>]

Hi

> If so, a random thought...  On x64 (with the Microsoft C++ compiler at least), just an (int) cast from a 32 bit float to 32 bit int, which compiles down to one x86 machine instruction - cvttss2si - will truncate to the next integer value in the direction of 0.  No need to call a floor function at all.

Thanks. Nowadays  I tend to write code for clarity and let the compiler do the optimizations. In this case, it is hardly compiler dependent. On ARM for example, clang 11 generates fcvtms versus  fcvtzs on other compiler things may change. For most compilers floorf is an intrinsic. Since the algorithm is described using floor, I use floor instead of an int cast. In fact, the mantissa trick I was using is no longer faster that the floorf function. After all the optimizer rearranges code so it depends on how well the whole thing parallelizes. Floorf uses xxmm instructions and those parallelize very well. 

Regards

Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: Noel Carboni <NCa...@Pr...> 
Sent: Friday, October 21, 2022 6:18 AM
To: mar...@li...
Cc: lcm...@li...
Subject: RE: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hi Marti,

> Found the bug and fixed it in
> https://github.com/mm2/Little-CMS/commit/aa7f240da8dc27a0bb082462889cc
> a9026bf2b27

Are all your px, py, pz values always non-negative at the point of the above changes to fast_float_tethra.c?  

If so, a random thought...  On x64 (with the Microsoft C++ compiler at least), just an (int) cast from a 32 bit float to 32 bit int, which compiles down to one x86 machine instruction - cvttss2si - will truncate to the next integer value in the direction of 0.  No need to call a floor function at all.

If those values can be negative...  Never mind.  😊

-Noel Carboni
 ProDigital Software

-----Original Message-----
From: mar...@li... <mar...@li...>
Sent: Thu, October 20, 2022 1:24 PM
To: 'L. E. Segovia' <am...@am...>
Cc: lcm...@li...
Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hello,

Found the bug and fixed it in
https://github.com/mm2/Little-CMS/commit/aa7f240da8dc27a0bb082462889cca9026bf2b27

It is an AMAZING bug, triggered by an issue of precision loss. 

For those that enjoy this kind of things I will briefly describe what was happening.

I used a tweaked floor() for speed. floor() function is supposed to return the largest integer value that is less than or equal to a number. My tweaked function was using mantissa tricks to run as fast as possible. It worked for all but a small number of combinations. 
Well, you hit one of those bad combinations. A number like 47.9993 (I think, I may be wrong on recalling the exact number). Quick floor of this particular number returned 48 when it really was 47. At the end its only 0.0007 difference so may seem harmless...
BUT this was used for interpolation so a subtraction was involved. if we try to compute the node with that faulty floor and then subtract values to get the rest, we end in a negative number. And you know, negative number mixes bad with unsigned, so at the end this was creating a nasty out-of-bounds condition.  Funny enough, very few numbers are capable of that. You were lucky enough to discover the bug because you hit a bad number with white with those profiles and flags otherwise this could go unnoticed for years.

Many thanks for reporting. You earned the award of "bug of the year" because its rarity.

Best regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: L. E. Segovia <am...@am...>
Sent: Thursday, October 20, 2022 3:46 AM
To: mar...@li...
Cc: lcm...@li...
Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hi,

The Krita code for the LCMS transform initialization is a nightmare... 
apart from a 10 y-o typo in the format definition (not declaring FLOAT_SH where we should), I've managed to consistently reproduce the bug.

I've adjusted two lines below:

> #include <lcms2.h>
> #include <lcms2_fast_float.h>
> 
> int main(void)
> {
>     cmsHPROFILE hInput, hOutput;
>     cmsHTRANSFORM xform;
> 
>     cmsPlugin(cmsFastFloatExtensions());
> 
>     hInput = cmsOpenProfileFromFile("profile.icc", "r");
>     hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500
> 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>     xform = cmsCreateTransform(hInput, TYPE_RGBA_FLT, hOutput, 
> TYPE_RGBA_FLT, INTENT_PERCEPTUAL, cmsFLAGS_BLACKPOINTCOMPENSATION | 
> cmsFLAGS_HIGHRESPRECALC);
> 
>     float ones[4] = {0.999999821f, 1.0f, 5.05994073e-08f, 1.0f };
>     float result[4] = { 0 };
> 
>     cmsDoTransform(xform, ones, result, 1);
> 
>     cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>     cmsDeleteTransform(xform);
>     return 1;
> }

We at Krita use RGBA, and the given conversion flags: 
cmsFLAGS_BLACKPOINTCOMPENSATION and cmsFLAGS_HIGHRESPRECALC.

The pixel values were extracted straight from the exception stacktrace, and I've verified them separately.

Best,

amyspark

On 19/10/2022 09:08, mar...@li... wrote:
> 
> Hi,
> 
> I've tried the following code with the plug-in and your profiles. It works fine.  Please let me know which differences are in the Krita call because I cannot reproduce the error.
> 
> int checkKrita(void)
> {
>      cmsHPROFILE hInput, hOutput;
>      cmsHTRANSFORM xform;
> 
>      cmsPlugin(cmsFastFloatExtensions());
> 
>      hInput = cmsOpenProfileFromFile("profile.icc", "r");
>      hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500
> 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>      xform = cmsCreateTransform(hInput, TYPE_RGB_FLT, hOutput, 
> TYPE_RGB_FLT, INTENT_PERCEPTUAL, 0);
> 
>      float ones[3] = { 1.0f, 1.0f, 1.0f };
>      float result[3] = { 0 };
> 
>      cmsDoTransform(xform, ones, result, 1);
> 
>      cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>      cmsDeleteTransform(xform);
>      return 1;
> }
> 
> BTW, are you linking the plug-in as a DLL?
> 
> Regards
> 
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
> 
> -----Original Message-----
> From: L. E. Segovia <am...@am...>
> Sent: Wednesday, October 19, 2022 2:38 AM
> To: Marti Maria <mar...@li...>
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready 
> to be released
> 
> Hey Marti,
> 
> I've been able to reproduce the bug in both 2.13.1 and the recent release candidate, both point to this stacktrace (snipped for brevity) inside the tetrahedral RGB interpolation module:
> 
> lcms2_fast_float.dll!FloatCLUTEval(_cmstransform_struct * CMMcargo, 
> const void * Input, void * Output, unsigned int PixelsPerLine, 
> unsigned int LineCount, const cmsStride * Stride) Line 199 
> (e:\krita-win\patches\Little-CMS\src\plugins\fast_float\src\fast_float
> _tethra.c:199) lcms2.dll!cmsDoTransform(void * Transform, const void * 
> InputBuffer, void * OutputBuffer, unsigned int Size) Line 207
> (e:\krita-win\patches\Little-CMS\src\src\cmsxform.c:207)
> 
> The bug can be reproduced with 1.0 in any of the input's channels, and the source and display profiles provided in the bug report.
> 
> Is there anything else I can do to help you reproduce it?
> 
> Best,
> 
> amyspark
> 
> On 16/10/2022 16:40, Marti Maria wrote:
>> Hello,
>>
>> Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.
>>
>> Thanks
>> Marti
>>
>>
>>> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
>>>
>>> Hey Marti,
>>>
>>> We've gotten a bug report at Krita regarding the fast float plugin:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=460512
>>>
>>> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
>>>
>>> Best,
>>>
>>> amyspark
>>>
>>> On 15/10/2022 15:38, Marti Maria wrote:
>>>> I am glad to announce the imminent release of lcms2-2.14 The first 
>>>> release candidate is available here:
>>>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>>>> Changes
>>>> 	• lcms2 now fully implements ICC specification 4.4
>>>> 	• New multi-threaded plug-in
>>>> 	• several fixes to keep fuzzers happy
>>>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>>>> 	• Added more validation against broken profiles
>>>> 	• Add more help to several tools
>>>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>>>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>>>> Best regards
>>>> Marti Maria
>>>> The LittleCMS Project
>>>> https://www.littlecms.com
>>>> _______________________________________________
>>>> Lcms-user mailing list
>>>> Lcm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>>
>>> --
>>> amyspark 🌸 https://www.amyspark.me
>>>
>>>
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
> 
> --
> amyspark 🌸 https://www.amyspark.me
> 

--
amyspark 🌸 https://www.amyspark.me



_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[Noel C. <NCa...@Pr...>]

Hi Marti,

> Found the bug and fixed it in
> https://github.com/mm2/Little-CMS/commit/aa7f240da8dc27a0bb082462889cca9026bf2b27

Are all your px, py, pz values always non-negative at the point of the above changes to fast_float_tethra.c?  

If so, a random thought...  On x64 (with the Microsoft C++ compiler at least), just an (int) cast from a 32 bit float to 32 bit int, which compiles down to one x86 machine instruction - cvttss2si - will truncate to the next integer value in the direction of 0.  No need to call a floor function at all.

If those values can be negative...  Never mind.  😊

-Noel Carboni
 ProDigital Software

-----Original Message-----
From: mar...@li... <mar...@li...> 
Sent: Thu, October 20, 2022 1:24 PM
To: 'L. E. Segovia' <am...@am...>
Cc: lcm...@li...
Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hello,

Found the bug and fixed it in
https://github.com/mm2/Little-CMS/commit/aa7f240da8dc27a0bb082462889cca9026bf2b27

It is an AMAZING bug, triggered by an issue of precision loss. 

For those that enjoy this kind of things I will briefly describe what was happening.

I used a tweaked floor() for speed. floor() function is supposed to return the largest integer value that is less than or equal to a number. My tweaked function was using mantissa tricks to run as fast as possible. It worked for all but a small number of combinations. 
Well, you hit one of those bad combinations. A number like 47.9993 (I think, I may be wrong on recalling the exact number). Quick floor of this particular number returned 48 when it really was 47. At the end its only 0.0007 difference so may seem harmless...
BUT this was used for interpolation so a subtraction was involved. if we try to compute the node with that faulty floor and then subtract values to get the rest, we end in a negative number. And you know, negative number mixes bad with unsigned, so at the end this was creating a nasty out-of-bounds condition.  Funny enough, very few numbers are capable of that. You were lucky enough to discover the bug because you hit a bad number with white with those profiles and flags otherwise this could go unnoticed for years.

Many thanks for reporting. You earned the award of "bug of the year" because its rarity.

Best regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: L. E. Segovia <am...@am...>
Sent: Thursday, October 20, 2022 3:46 AM
To: mar...@li...
Cc: lcm...@li...
Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hi,

The Krita code for the LCMS transform initialization is a nightmare... 
apart from a 10 y-o typo in the format definition (not declaring FLOAT_SH where we should), I've managed to consistently reproduce the bug.

I've adjusted two lines below:

> #include <lcms2.h>
> #include <lcms2_fast_float.h>
> 
> int main(void)
> {
>     cmsHPROFILE hInput, hOutput;
>     cmsHTRANSFORM xform;
> 
>     cmsPlugin(cmsFastFloatExtensions());
> 
>     hInput = cmsOpenProfileFromFile("profile.icc", "r");
>     hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500
> 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>     xform = cmsCreateTransform(hInput, TYPE_RGBA_FLT, hOutput, 
> TYPE_RGBA_FLT, INTENT_PERCEPTUAL, cmsFLAGS_BLACKPOINTCOMPENSATION | 
> cmsFLAGS_HIGHRESPRECALC);
> 
>     float ones[4] = {0.999999821f, 1.0f, 5.05994073e-08f, 1.0f };
>     float result[4] = { 0 };
> 
>     cmsDoTransform(xform, ones, result, 1);
> 
>     cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>     cmsDeleteTransform(xform);
>     return 1;
> }

We at Krita use RGBA, and the given conversion flags: 
cmsFLAGS_BLACKPOINTCOMPENSATION and cmsFLAGS_HIGHRESPRECALC.

The pixel values were extracted straight from the exception stacktrace, and I've verified them separately.

Best,

amyspark

On 19/10/2022 09:08, mar...@li... wrote:
> 
> Hi,
> 
> I've tried the following code with the plug-in and your profiles. It works fine.  Please let me know which differences are in the Krita call because I cannot reproduce the error.
> 
> int checkKrita(void)
> {
>      cmsHPROFILE hInput, hOutput;
>      cmsHTRANSFORM xform;
> 
>      cmsPlugin(cmsFastFloatExtensions());
> 
>      hInput = cmsOpenProfileFromFile("profile.icc", "r");
>      hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500
> 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>      xform = cmsCreateTransform(hInput, TYPE_RGB_FLT, hOutput, 
> TYPE_RGB_FLT, INTENT_PERCEPTUAL, 0);
> 
>      float ones[3] = { 1.0f, 1.0f, 1.0f };
>      float result[3] = { 0 };
> 
>      cmsDoTransform(xform, ones, result, 1);
> 
>      cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>      cmsDeleteTransform(xform);
>      return 1;
> }
> 
> BTW, are you linking the plug-in as a DLL?
> 
> Regards
> 
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
> 
> -----Original Message-----
> From: L. E. Segovia <am...@am...>
> Sent: Wednesday, October 19, 2022 2:38 AM
> To: Marti Maria <mar...@li...>
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready 
> to be released
> 
> Hey Marti,
> 
> I've been able to reproduce the bug in both 2.13.1 and the recent release candidate, both point to this stacktrace (snipped for brevity) inside the tetrahedral RGB interpolation module:
> 
> lcms2_fast_float.dll!FloatCLUTEval(_cmstransform_struct * CMMcargo, 
> const void * Input, void * Output, unsigned int PixelsPerLine, 
> unsigned int LineCount, const cmsStride * Stride) Line 199 
> (e:\krita-win\patches\Little-CMS\src\plugins\fast_float\src\fast_float
> _tethra.c:199) lcms2.dll!cmsDoTransform(void * Transform, const void * 
> InputBuffer, void * OutputBuffer, unsigned int Size) Line 207
> (e:\krita-win\patches\Little-CMS\src\src\cmsxform.c:207)
> 
> The bug can be reproduced with 1.0 in any of the input's channels, and the source and display profiles provided in the bug report.
> 
> Is there anything else I can do to help you reproduce it?
> 
> Best,
> 
> amyspark
> 
> On 16/10/2022 16:40, Marti Maria wrote:
>> Hello,
>>
>> Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.
>>
>> Thanks
>> Marti
>>
>>
>>> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
>>>
>>> Hey Marti,
>>>
>>> We've gotten a bug report at Krita regarding the fast float plugin:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=460512
>>>
>>> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
>>>
>>> Best,
>>>
>>> amyspark
>>>
>>> On 15/10/2022 15:38, Marti Maria wrote:
>>>> I am glad to announce the imminent release of lcms2-2.14 The first 
>>>> release candidate is available here:
>>>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>>>> Changes
>>>> 	• lcms2 now fully implements ICC specification 4.4
>>>> 	• New multi-threaded plug-in
>>>> 	• several fixes to keep fuzzers happy
>>>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>>>> 	• Added more validation against broken profiles
>>>> 	• Add more help to several tools
>>>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>>>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>>>> Best regards
>>>> Marti Maria
>>>> The LittleCMS Project
>>>> https://www.littlecms.com
>>>> _______________________________________________
>>>> Lcms-user mailing list
>>>> Lcm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>>
>>> --
>>> amyspark 🌸 https://www.amyspark.me
>>>
>>>
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
> 
> --
> amyspark 🌸 https://www.amyspark.me
> 

--
amyspark 🌸 https://www.amyspark.me



_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[<mar...@li...>]

Hello,

Found the bug and fixed it in 
https://github.com/mm2/Little-CMS/commit/aa7f240da8dc27a0bb082462889cca9026bf2b27

It is an AMAZING bug, triggered by an issue of precision loss. 

For those that enjoy this kind of things I will briefly describe what was happening.

I used a tweaked floor() for speed. floor() function is supposed to return the largest integer value that is less than or equal to a number. My tweaked function was using mantissa tricks to run as fast as possible. It worked for all but a small number of combinations. 
Well, you hit one of those bad combinations. A number like 47.9993 (I think, I may be wrong on recalling the exact number). Quick floor of this particular number returned 48 when it really was 47. At the end its only 0.0007 difference so may seem harmless...
BUT this was used for interpolation so a subtraction was involved. if we try to compute the node with that faulty floor and then subtract values to get the rest, we end in a negative number. And you know, negative number mixes bad with unsigned, so at the end this was creating a nasty out-of-bounds condition.  Funny enough, very few numbers are capable of that. You were lucky enough to discover the bug because you hit a bad number with white with those profiles and flags otherwise this could go unnoticed for years.

Many thanks for reporting. You earned the award of "bug of the year" because its rarity.

Best regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: L. E. Segovia <am...@am...> 
Sent: Thursday, October 20, 2022 3:46 AM
To: mar...@li...
Cc: lcm...@li...
Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hi,

The Krita code for the LCMS transform initialization is a nightmare... 
apart from a 10 y-o typo in the format definition (not declaring FLOAT_SH where we should), I've managed to consistently reproduce the bug.

I've adjusted two lines below:

> #include <lcms2.h>
> #include <lcms2_fast_float.h>
> 
> int main(void)
> {
>     cmsHPROFILE hInput, hOutput;
>     cmsHTRANSFORM xform;
> 
>     cmsPlugin(cmsFastFloatExtensions());
> 
>     hInput = cmsOpenProfileFromFile("profile.icc", "r");
>     hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500 
> 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>     xform = cmsCreateTransform(hInput, TYPE_RGBA_FLT, hOutput, 
> TYPE_RGBA_FLT, INTENT_PERCEPTUAL, cmsFLAGS_BLACKPOINTCOMPENSATION | 
> cmsFLAGS_HIGHRESPRECALC);
> 
>     float ones[4] = {0.999999821f, 1.0f, 5.05994073e-08f, 1.0f };
>     float result[4] = { 0 };
> 
>     cmsDoTransform(xform, ones, result, 1);
> 
>     cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>     cmsDeleteTransform(xform);
>     return 1;
> }

We at Krita use RGBA, and the given conversion flags: 
cmsFLAGS_BLACKPOINTCOMPENSATION and cmsFLAGS_HIGHRESPRECALC.

The pixel values were extracted straight from the exception stacktrace, and I've verified them separately.

Best,

amyspark

On 19/10/2022 09:08, mar...@li... wrote:
> 
> Hi,
> 
> I've tried the following code with the plug-in and your profiles. It works fine.  Please let me know which differences are in the Krita call because I cannot reproduce the error.
> 
> int checkKrita(void)
> {
>      cmsHPROFILE hInput, hOutput;
>      cmsHTRANSFORM xform;
> 
>      cmsPlugin(cmsFastFloatExtensions());
> 
>      hInput = cmsOpenProfileFromFile("profile.icc", "r");
>      hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500 
> 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>      xform = cmsCreateTransform(hInput, TYPE_RGB_FLT, hOutput, 
> TYPE_RGB_FLT, INTENT_PERCEPTUAL, 0);
> 
>      float ones[3] = { 1.0f, 1.0f, 1.0f };
>      float result[3] = { 0 };
> 
>      cmsDoTransform(xform, ones, result, 1);
> 
>      cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>      cmsDeleteTransform(xform);
>      return 1;
> }
> 
> BTW, are you linking the plug-in as a DLL?
> 
> Regards
> 
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
> 
> -----Original Message-----
> From: L. E. Segovia <am...@am...>
> Sent: Wednesday, October 19, 2022 2:38 AM
> To: Marti Maria <mar...@li...>
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready 
> to be released
> 
> Hey Marti,
> 
> I've been able to reproduce the bug in both 2.13.1 and the recent release candidate, both point to this stacktrace (snipped for brevity) inside the tetrahedral RGB interpolation module:
> 
> lcms2_fast_float.dll!FloatCLUTEval(_cmstransform_struct * CMMcargo, 
> const void * Input, void * Output, unsigned int PixelsPerLine, 
> unsigned int LineCount, const cmsStride * Stride) Line 199
> (e:\krita-win\patches\Little-CMS\src\plugins\fast_float\src\fast_float
> _tethra.c:199) lcms2.dll!cmsDoTransform(void * Transform, const void * 
> InputBuffer, void * OutputBuffer, unsigned int Size) Line 207
> (e:\krita-win\patches\Little-CMS\src\src\cmsxform.c:207)
> 
> The bug can be reproduced with 1.0 in any of the input's channels, and the source and display profiles provided in the bug report.
> 
> Is there anything else I can do to help you reproduce it?
> 
> Best,
> 
> amyspark
> 
> On 16/10/2022 16:40, Marti Maria wrote:
>> Hello,
>>
>> Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.
>>
>> Thanks
>> Marti
>>
>>
>>> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
>>>
>>> Hey Marti,
>>>
>>> We've gotten a bug report at Krita regarding the fast float plugin:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=460512
>>>
>>> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
>>>
>>> Best,
>>>
>>> amyspark
>>>
>>> On 15/10/2022 15:38, Marti Maria wrote:
>>>> I am glad to announce the imminent release of lcms2-2.14 The first 
>>>> release candidate is available here:
>>>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>>>> Changes
>>>> 	• lcms2 now fully implements ICC specification 4.4
>>>> 	• New multi-threaded plug-in
>>>> 	• several fixes to keep fuzzers happy
>>>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>>>> 	• Added more validation against broken profiles
>>>> 	• Add more help to several tools
>>>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>>>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>>>> Best regards
>>>> Marti Maria
>>>> The LittleCMS Project
>>>> https://www.littlecms.com
>>>> _______________________________________________
>>>> Lcms-user mailing list
>>>> Lcm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>>
>>> --
>>> amyspark 🌸 https://www.amyspark.me
>>>
>>>
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
> 
> --
> amyspark 🌸 https://www.amyspark.me
> 

--
amyspark 🌸 https://www.amyspark.me

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[L. E. S. <am...@am...>]

Hi,

The Krita code for the LCMS transform initialization is a nightmare... 
apart from a 10 y-o typo in the format definition (not declaring 
FLOAT_SH where we should), I've managed to consistently reproduce the bug.

I've adjusted two lines below:

> #include <lcms2.h>
> #include <lcms2_fast_float.h>
> 
> int main(void)
> {
>     cmsHPROFILE hInput, hOutput;
>     cmsHTRANSFORM xform;
> 
>     cmsPlugin(cmsFastFloatExtensions());
> 
>     hInput = cmsOpenProfileFromFile("profile.icc", "r");
>     hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>     xform = cmsCreateTransform(hInput, TYPE_RGBA_FLT, hOutput, TYPE_RGBA_FLT, INTENT_PERCEPTUAL, cmsFLAGS_BLACKPOINTCOMPENSATION | cmsFLAGS_HIGHRESPRECALC);
> 
>     float ones[4] = {0.999999821f, 1.0f, 5.05994073e-08f, 1.0f };
>     float result[4] = { 0 };
> 
>     cmsDoTransform(xform, ones, result, 1);
> 
>     cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>     cmsDeleteTransform(xform);
>     return 1;
> }

We at Krita use RGBA, and the given conversion flags: 
cmsFLAGS_BLACKPOINTCOMPENSATION and cmsFLAGS_HIGHRESPRECALC.

The pixel values were extracted straight from the exception stacktrace, 
and I've verified them separately.

Best,

amyspark

On 19/10/2022 09:08, mar...@li... wrote:
> 
> Hi,
> 
> I've tried the following code with the plug-in and your profiles. It works fine.  Please let me know which differences are in the Krita call because I cannot reproduce the error.
> 
> int checkKrita(void)
> {
>      cmsHPROFILE hInput, hOutput;
>      cmsHTRANSFORM xform;
> 
>      cmsPlugin(cmsFastFloatExtensions());
> 
>      hInput = cmsOpenProfileFromFile("profile.icc", "r");
>      hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");
> 
>      xform = cmsCreateTransform(hInput, TYPE_RGB_FLT, hOutput, TYPE_RGB_FLT, INTENT_PERCEPTUAL, 0);
> 
>      float ones[3] = { 1.0f, 1.0f, 1.0f };
>      float result[3] = { 0 };
> 
>      cmsDoTransform(xform, ones, result, 1);
> 
>      cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
>      cmsDeleteTransform(xform);
>      return 1;
> }
> 
> BTW, are you linking the plug-in as a DLL?
> 
> Regards
> 
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
> 
> -----Original Message-----
> From: L. E. Segovia <am...@am...>
> Sent: Wednesday, October 19, 2022 2:38 AM
> To: Marti Maria <mar...@li...>
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released
> 
> Hey Marti,
> 
> I've been able to reproduce the bug in both 2.13.1 and the recent release candidate, both point to this stacktrace (snipped for brevity) inside the tetrahedral RGB interpolation module:
> 
> lcms2_fast_float.dll!FloatCLUTEval(_cmstransform_struct * CMMcargo, const void * Input, void * Output, unsigned int PixelsPerLine, unsigned int LineCount, const cmsStride * Stride) Line 199
> (e:\krita-win\patches\Little-CMS\src\plugins\fast_float\src\fast_float_tethra.c:199)
> lcms2.dll!cmsDoTransform(void * Transform, const void * InputBuffer, void * OutputBuffer, unsigned int Size) Line 207
> (e:\krita-win\patches\Little-CMS\src\src\cmsxform.c:207)
> 
> The bug can be reproduced with 1.0 in any of the input's channels, and the source and display profiles provided in the bug report.
> 
> Is there anything else I can do to help you reproduce it?
> 
> Best,
> 
> amyspark
> 
> On 16/10/2022 16:40, Marti Maria wrote:
>> Hello,
>>
>> Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.
>>
>> Thanks
>> Marti
>>
>>
>>> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
>>>
>>> Hey Marti,
>>>
>>> We've gotten a bug report at Krita regarding the fast float plugin:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=460512
>>>
>>> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
>>>
>>> Best,
>>>
>>> amyspark
>>>
>>> On 15/10/2022 15:38, Marti Maria wrote:
>>>> I am glad to announce the imminent release of lcms2-2.14 The first
>>>> release candidate is available here:
>>>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>>>> Changes
>>>> 	• lcms2 now fully implements ICC specification 4.4
>>>> 	• New multi-threaded plug-in
>>>> 	• several fixes to keep fuzzers happy
>>>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>>>> 	• Added more validation against broken profiles
>>>> 	• Add more help to several tools
>>>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>>>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>>>> Best regards
>>>> Marti Maria
>>>> The LittleCMS Project
>>>> https://www.littlecms.com
>>>> _______________________________________________
>>>> Lcms-user mailing list
>>>> Lcm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>>
>>> --
>>> amyspark 🌸 https://www.amyspark.me
>>>
>>>
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
> 
> --
> amyspark 🌸 https://www.amyspark.me
> 

-- 
amyspark 🌸 https://www.amyspark.me

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[<mar...@li...>]

Hi,

I've tried the following code with the plug-in and your profiles. It works fine.  Please let me know which differences are in the Krita call because I cannot reproduce the error.

int checkKrita(void)
{
    cmsHPROFILE hInput, hOutput;
    cmsHTRANSFORM xform;

    cmsPlugin(cmsFastFloatExtensions());

    hInput = cmsOpenProfileFromFile("profile.icc", "r");
    hOutput = cmsOpenProfileFromFile("Cintiq 13 #2 2022-07-29 D6500 2.2 S XYZLUT+MTX sRGB-HQ.icm", "r");

    xform = cmsCreateTransform(hInput, TYPE_RGB_FLT, hOutput, TYPE_RGB_FLT, INTENT_PERCEPTUAL, 0);

    float ones[3] = { 1.0f, 1.0f, 1.0f };
    float result[3] = { 0 };

    cmsDoTransform(xform, ones, result, 1);

    cmsCloseProfile(hInput); cmsCloseProfile(hOutput);
    cmsDeleteTransform(xform);
    return 1;
}

BTW, are you linking the plug-in as a DLL?  

Regards

Marti Maria
The LittleCMS Project
https://www.littlecms.com

-----Original Message-----
From: L. E. Segovia <am...@am...> 
Sent: Wednesday, October 19, 2022 2:38 AM
To: Marti Maria <mar...@li...>
Cc: lcm...@li...
Subject: Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

Hey Marti,

I've been able to reproduce the bug in both 2.13.1 and the recent release candidate, both point to this stacktrace (snipped for brevity) inside the tetrahedral RGB interpolation module:

lcms2_fast_float.dll!FloatCLUTEval(_cmstransform_struct * CMMcargo, const void * Input, void * Output, unsigned int PixelsPerLine, unsigned int LineCount, const cmsStride * Stride) Line 199
(e:\krita-win\patches\Little-CMS\src\plugins\fast_float\src\fast_float_tethra.c:199)
lcms2.dll!cmsDoTransform(void * Transform, const void * InputBuffer, void * OutputBuffer, unsigned int Size) Line 207
(e:\krita-win\patches\Little-CMS\src\src\cmsxform.c:207)

The bug can be reproduced with 1.0 in any of the input's channels, and the source and display profiles provided in the bug report.

Is there anything else I can do to help you reproduce it?

Best,

amyspark

On 16/10/2022 16:40, Marti Maria wrote:
> Hello,
> 
> Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.
> 
> Thanks
> Marti
> 
> 
>> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
>>
>> Hey Marti,
>>
>> We've gotten a bug report at Krita regarding the fast float plugin:
>>
>> https://bugs.kde.org/show_bug.cgi?id=460512
>>
>> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
>>
>> Best,
>>
>> amyspark
>>
>> On 15/10/2022 15:38, Marti Maria wrote:
>>> I am glad to announce the imminent release of lcms2-2.14 The first 
>>> release candidate is available here:
>>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>>> Changes
>>> 	• lcms2 now fully implements ICC specification 4.4
>>> 	• New multi-threaded plug-in
>>> 	• several fixes to keep fuzzers happy
>>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>>> 	• Added more validation against broken profiles
>>> 	• Add more help to several tools
>>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>>> Best regards
>>> Marti Maria
>>> The LittleCMS Project
>>> https://www.littlecms.com
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
>> --
>> amyspark 🌸 https://www.amyspark.me
>>
>>
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 

--
amyspark 🌸 https://www.amyspark.me

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[L. E. S. <am...@am...>]

Hey Marti,

I've been able to reproduce the bug in both 2.13.1 and the recent 
release candidate, both point to this stacktrace (snipped for brevity) 
inside the tetrahedral RGB interpolation module:

lcms2_fast_float.dll!FloatCLUTEval(_cmstransform_struct * CMMcargo, 
const void * Input, void * Output, unsigned int PixelsPerLine, unsigned 
int LineCount, const cmsStride * Stride) Line 199 
(e:\krita-win\patches\Little-CMS\src\plugins\fast_float\src\fast_float_tethra.c:199)
lcms2.dll!cmsDoTransform(void * Transform, const void * InputBuffer, 
void * OutputBuffer, unsigned int Size) Line 207 
(e:\krita-win\patches\Little-CMS\src\src\cmsxform.c:207)

The bug can be reproduced with 1.0 in any of the input's channels, and 
the source and display profiles provided in the bug report.

Is there anything else I can do to help you reproduce it?

Best,

amyspark

On 16/10/2022 16:40, Marti Maria wrote:
> Hello,
> 
> Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.
> 
> Thanks
> Marti
> 
> 
>> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
>>
>> Hey Marti,
>>
>> We've gotten a bug report at Krita regarding the fast float plugin:
>>
>> https://bugs.kde.org/show_bug.cgi?id=460512
>>
>> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
>>
>> Best,
>>
>> amyspark
>>
>> On 15/10/2022 15:38, Marti Maria wrote:
>>> I am glad to announce the imminent release of lcms2-2.14
>>> The first release candidate is available here:
>>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>>> Changes
>>> 	• lcms2 now fully implements ICC specification 4.4
>>> 	• New multi-threaded plug-in
>>> 	• several fixes to keep fuzzers happy
>>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>>> 	• Added more validation against broken profiles
>>> 	• Add more help to several tools
>>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>>> Best regards
>>> Marti Maria
>>> The LittleCMS Project
>>> https://www.littlecms.com
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
>> -- 
>> amyspark 🌸 https://www.amyspark.me
>>
>>
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 

-- 
amyspark 🌸 https://www.amyspark.me

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[Marti M. <mar...@li...>]

Hello,

Could you try with 2.14rc1? there are some fixes on the plugin picking optimisations where it should not. Chances are that this is solved.

Thanks
Marti


> On 16 Oct 2022, at 19:56, L. E. Segovia via Lcms-user <lcm...@li...> wrote:
> 
> Hey Marti,
> 
> We've gotten a bug report at Krita regarding the fast float plugin:
> 
> https://bugs.kde.org/show_bug.cgi?id=460512
> 
> Haven't yet had the time to symbolicate it, so sending this to keep you aware of it.
> 
> Best,
> 
> amyspark
> 
> On 15/10/2022 15:38, Marti Maria wrote:
>> I am glad to announce the imminent release of lcms2-2.14
>> The first release candidate is available here:
>> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
>> Changes
>> 	• lcms2 now fully implements ICC specification 4.4
>> 	• New multi-threaded plug-in
>> 	• several fixes to keep fuzzers happy
>> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
>> 	• Added more validation against broken profiles
>> 	• Add more help to several tools
>> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>> Best regards
>> Marti Maria
>> The LittleCMS Project
>> https://www.littlecms.com
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 
> -- 
> amyspark 🌸 https://www.amyspark.me
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[L. E. S. <am...@am...>]

Hey Marti,

We've gotten a bug report at Krita regarding the fast float plugin:

https://bugs.kde.org/show_bug.cgi?id=460512

Haven't yet had the time to symbolicate it, so sending this to keep you 
aware of it.

Best,

amyspark

On 15/10/2022 15:38, Marti Maria wrote:
> I am glad to announce the imminent release of lcms2-2.14
> 
> The first release candidate is available here:
> 
> https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1
> 
> Changes
> 
> 	• lcms2 now fully implements ICC specification 4.4
> 	• New multi-threaded plug-in
> 	• several fixes to keep fuzzers happy
> 	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
> 	• Added more validation against broken profiles
> 	• Add more help to several tools
> 
> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
> 
> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
> 
> 
> Best regards
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

-- 
amyspark 🌸 https://www.amyspark.me

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[Marti M. <mar...@li...>]

Hi,

> Are there any plans for lcms to take advantage of the cicp tag to
> determine colorspace, or will it just treat it as yet another bit of
> metadata for the time being? I'm super stoked regardless of the
> answer.


Yes. for 2.14 just the metadata, for 2.15 some integration of the cicp tag to detect mismatches and avoid transforms on same profile on both sides. 
But this will take some time.

Best regards
Marti

Re: [Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[Wolthera <gri...@gm...>]

Excellent!

On Sun, Oct 16, 2022 at 4:04 AM Marti Maria <mar...@li...> wrote:
>
> I am glad to announce the imminent release of lcms2-2.14
> [snip]
>
> ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.
>
> Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.
>
>
> Best regards
> Marti Maria

For people wondering, the changes are described in the 'Foreword' of
the ICC 4.4 spec, and they consist of some smaller fixes, improved
metadata features and most usefully the cicpTag, which is for storing
colorspace encoding metadata as defined by ITU H.273, which basically
defines some standard color spaces used in video broadcasting, and are
used for some screen-first formats like avif and heif. While we can
currently just create icc profiles or transform the data (rec 2100 can
be indicated by cicp but not represented in icc v4, so for Krita we
need to transform) as necessary, round tripping was less than ideal,
and being able to store some cicp data inside the profiles is going to
be super helpful!

Are there any plans for lcms to take advantage of the cicp tag to
determine colorspace, or will it just treat it as yet another bit of
metadata for the time being? I'm super stoked regardless of the
answer.

The new threading plugin looks cool too, I imagine it's going to be a
lot of help for people newly integrating lcms!
-- 
Wolthera

[Lcms-user] [Release candidate] Little CMS 2.14 is ready to be released

[Marti M. <mar...@li...>]

I am glad to announce the imminent release of lcms2-2.14

The first release candidate is available here:

https://github.com/mm2/Little-CMS/releases/tag/lcms2.14rc1

Changes 

	• lcms2 now fully implements ICC specification 4.4
	• New multi-threaded plug-in
	• several fixes to keep fuzzers happy
	• Remove check on DLL when CMS_NO_REGISTER_KEYWORD is used
	• Added more validation against broken profiles
	• Add more help to several tools

ICC Version 4.4 and the multithreaded plug-in are important milestones. Fixes because fuzzers have been many, none of them harmful in terms of exploits.

Feel free to test it on all your products, tentative release date for final lcms2-2.14 is end of Oct-2022 Please contact me on any issue either on info { at } littecms.com or using this list.


Best regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com

Re: [Lcms-user] odd change in 2.13

[Derek B. N. <de...@gl...>]

Thanks.  I can confirm that the current github code fixes the problem
I was seeing.

- Derek


On Thu, 24 Mar 2022 15:53:05 +0100
mar...@li... wrote:

> 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  
> 

Re: [Lcms-user] odd change in 2.13

[<mar...@li...>]

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

Re: [Lcms-user] odd change in 2.13

[Derek B. N. <de...@gl...>]

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  
> 

Re: [Lcms-user] odd change in 2.13

[Marti M. <mar...@li...>]

Hi,


> 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
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