lcms-user — For users of the little cms library

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

[Lcms-user] odd change in 2.13

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

I'm seeing very different output in one particular case, after
upgrading from 2.12 to 2.13 (or 2.13.1).

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!

Re: [Lcms-user] Clarification about chromatic adaptation

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

Hi,

The chromatic adaptation matrix is just an informative field on what has been done on intents perceptual, relative colorimetric and saturation. It is not used when building a transform, the “true” chromatic adaptation is embedded in the colorant matrix or in the LUT.

Having said so, there is one situation where this is used. If you create a absolute colorimetric transform with observer not adapted (and only in this case!) the CMM “undoes” the chromatic adaptation of the profile using the CHAD matrix. It works to some extent, because many vendors put whatever in the CHAD and not disclose their “secret sauce”.  So in your sample, using -d0 you will get some differences. Remember in ICC 4 absolute colorimetric observer is fully adapted by default, therefore no differences on different illuminants.

Regards
Marti

> On 11 Mar 2022, at 11:37, Andrea Galligani <and...@ma...> wrote:
> 
> Hi to all,
> I realized an esperiment coping a standard profile and changing the chromatic adaptation matrix from identity to a
> Bradford D65->D50 one. I saved a D65 Lab profile using the code:
> 
> cmsHPROFILE                 hProfile   = cmsCreateLab2Profile( &D65illuminant );
> cmsSaveProfileToFile( hProfile, "LabD65.icc" );
> 
> Than I created a very simple CGATS with base pure CMYK tints and I used transicc to translate
> CMYK to Lab using this commands
> 
> transicc -iSNAP2007_D50.icc -o*Lab2 -t3 CMYK.txt CMYK_D50.txt
> 
> and
> 
> transicc -iSNAP2007_D65.icc -oLabD65.icc -t3 CMYK.txt CMYK_D65.txt
> 
> I expected different results from D50 and D65, similar to measures obtained
> measuring the printed patches under the different illuminants, but
> transicc produced almost identical results (Max DE00 0.0015).
> 
> Did I do somethink wrong?
> 
> Thanks
> Andrea
> 
> -- 
> 
> Andrea Galligani
> 
> ------------------------------------------------------------------------------
>  Macs Tech S.r.l.
> 
>    Via San Paolo, 11
>    50125 Pisa
>    Italy
> 
>      Tel: +39 050 40 915
>    email: in...@ma...
> ------------------------------------------------------------------------------
> Non stampare questa e-mail.
> 
> Avviso di confidenzialità - Questa e-mail è indirizzata esclusivamente al
> destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati,
> sono da ritenersi personali, confidenziali e riservate secondo i termini del
> vigente D.Lgs. 196/2003 in materia di privacy e del Regolamento europeo
> 679/2016 – GDPR-  e quindi ne è proibita l’utilizzazione ulteriore non
> autorizzata. Se avete ricevuto per errore questo messaggio, Vi preghiamo
> cortesemente di contattare immediatamente il mittente e cancellare la e-mail.
> Grazie.
> 
> ------------------------------------------------------------------------------
> Please don’t print this e-mail.
> 
> Confidentiality Notice – This e-mail message including any attachments is for
> the sole use of the intended recipient and may contain confidential and
> privileged information pursuant to Legislative Decree 196/2003 and the
> European General Data Protection Regulation 679/2016 – GDPR-. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy all
> copies of the original message.
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Clarification about chromatic adaptation

[Andrea G. <and...@ma...>]

Hi to all,
I realized an esperiment coping a standard profile and changing the 
chromatic adaptation matrix from identity to a
Bradford D65->D50 one. I saved a D65 Lab profile using the code:

cmsHPROFILE                 hProfile   = cmsCreateLab2Profile( 
&D65illuminant );
cmsSaveProfileToFile( hProfile, "LabD65.icc" );

Than I created a very simple CGATS with base pure CMYK tints and I used 
transicc to translate
CMYK to Lab using this commands

transicc -iSNAP2007_D50.icc -o*Lab2 -t3 CMYK.txt CMYK_D50.txt

and

transicc -iSNAP2007_D65.icc -oLabD65.icc -t3 CMYK.txt CMYK_D65.txt

I expected different results from D50 and D65, similar to measures obtained
measuring the printed patches under the different illuminants, but
transicc produced almost identical results (Max DE00 0.0015).

Did I do somethink wrong?

Thanks
Andrea

-- 

Andrea Galligani

------------------------------------------------------------------------------
   Macs Tech S.r.l.

     Via San Paolo, 11
     50125 Pisa
     Italy

       Tel: +39 050 40 915
     email: in...@ma...
------------------------------------------------------------------------------
Non stampare questa e-mail.

Avviso di confidenzialità - Questa e-mail è indirizzata esclusivamente al
destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati,
sono da ritenersi personali, confidenziali e riservate secondo i termini del
vigente D.Lgs. 196/2003 in materia di privacy e del Regolamento europeo
679/2016 – GDPR-  e quindi ne è proibita l’utilizzazione ulteriore non
autorizzata. Se avete ricevuto per errore questo messaggio, Vi preghiamo
cortesemente di contattare immediatamente il mittente e cancellare la e-mail.
Grazie.

------------------------------------------------------------------------------
Please don’t print this e-mail.

Confidentiality Notice – This e-mail message including any attachments is for
the sole use of the intended recipient and may contain confidential and
privileged information pursuant to Legislative Decree 196/2003 and the
European General Data Protection Regulation 679/2016 – GDPR-. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

------------------------------------------------------------------------------

Re: [Lcms-user] cmsReadRawTag inconsistent results.

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

Hi Phil,


> On 7 Mar 2022, at 05:07, Philip Race <phi...@or...> wrote:
> 
> I am having some trouble understanding the intent of the following comment versus what I observe:

You are right. These comments were outdated and didn’t explain what the code was doing. I have updated the file.

Thanks!

Best regards
Marti

[Lcms-user] cmsReadRawTag inconsistent results.

[Philip R. <phi...@or...>]

I am having some trouble understanding the intent of the following 
comment versus what I observe:

----------
// Read and write raw data. The only way those function would work and 
keep consistence with normal read and write
// is to do an additional step of serialization. That means, readRaw 
would issue a normal read and then convert the obtained
// data to raw bytes by using the "write" serialization logic. And 
vice-versa. I know this may end in situations where
// raw data written does not exactly correspond with the raw data 
proposed to cmsWriteRaw data, but this approach allows
// to write a tag as raw data and the read it as handled.

cmsUInt32Number CMSEXPORT cmsReadRawTag(cmsHPROFILE hProfile, 
cmsTagSignature sig, void* data, cmsUInt32Number BufferSize)

----------

To me it seems to be saying that cmsReadRawTag will *always* return the 
serialized result of a "cooked" tag - ie what
you will get after directly calling cmsReadTag(). And it does this to be 
consistent.

However the code isn't doing that because we have
     // It is already read?
     if (Icc -> TagPtrs[i] == NULL) {

         // No yet, get original position
         Offset   = Icc ->TagOffsets[i];
         TagSize  = Icc ->TagSizes[i];
...
...
}

Only if we get past that, and some other code, do we reach
-----------
     // Already read, or previously set by cmsWriteTag(). We need to 
serialize that
     // data to raw in order to maintain consistency.

     _cmsUnlockMutex(Icc->ContextID, Icc ->UsrMutex);
     Object = cmsReadTag(hProfile, sig);
     if (!_cmsLockMutex(Icc->ContextID, Icc ->UsrMutex)) return 0;

     if (Object == NULL) goto Error;

     // Now we need to serialize to a memory block: just use a memory 
iohandler
-----------

So this means that if you
1) Write a tag using cmsWriteRawTag
2) Call cmsReadRawTag() - you get back the "raw" data
3) Call cmsReadTag() - you "cook" the tag
4) Call cmsReadRawTag() - you now get back the serialized cooked data 
which may differ from (2)

as I have observed with code using the above sequence.

And this seems to me to contradict what the code comment I started with 
implies.

For clarity, regarding :-

// I know this may end in situations where
// raw data written does not exactly correspond with the raw data 
proposed to cmsWriteRaw data, but this approach allows
// to write a tag as raw data and the read it as handled.

Yes, I get that it means write and read back may differ - but I am 
seeing write and read back be inconsistent which
is what I think the comment is saying the implementation will avoid ..

-phil.

Re: [Lcms-user] [ANNOUNCE] Little CMS 2.13 released

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

It is now fixed in git. This bug has been there since 2.10

https://github.com/mm2/Little-CMS/commit/fdbfb7694f9d7048d53674b79ddfc38068bfdaf7 <https://github.com/mm2/Little-CMS/commit/fdbfb7694f9d7048d53674b79ddfc38068bfdaf7>

A true pity, but 2.13 is already released. You can avoid the bug on the official releases by using cmsFLAGS_NOOPTIMIZE when input grayscale is being used. I guess this is not very common as the flaw has been unnoticed by years. In 2.13 is more evident because another bug was discarding channels G and B in the gray->RGB optimized transforms, anyway that was wrong too.

Regards
Marti



> 
>> On 30 Jan 2022, at 02:48, Aaron Boxer <bo...@gm...> wrote:
>> 
>> Hi Marti,
>> 
>> Thank you for this new release! I think I have found a regression, though.
>> 
>> I maintain the Grok Jpeg 2000 codec, and we use lcms2 to apply ICC profiles after
>> decompressing from JPEG 2000. 
>> 
>> The attached file file8.jp2 is a monochrome image
>> with a grayscale ICC profile.  For decompression, the codec decompresses
>> the single channel, applies the ICC profile, and then converts it to RGB 
>> (by duplicating the mono channel)
>> 
>> file8.jp2.tif is the decompressed result with the older version of lcms2.
>> file8.jp2_new.tif is the result with lcms2 2.13. You can see that the image w/ 2.13 
>> is saturating at the top of the range.
>> 
>> If you need, I can point you to the code that applies the ICC profile.
>> 
>> Let me know if I can provide any more information.
>> Thanks again,
>> Aaron
>> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] [ANNOUNCE] Little CMS 2.13 released

[Aaron B. <bo...@gm...>]

Thanks for the fix, and once again thank you for this incredible library.

On Sun, Jan 30, 2022 at 11:03 AM Marti Maria <mar...@li...>
wrote:

>
> It is now fixed in git. This bug has been there since 2.10
>
>
> https://github.com/mm2/Little-CMS/commit/fdbfb7694f9d7048d53674b79ddfc38068bfdaf7
>
> A true pity, but 2.13 is already released. You can avoid the bug on the
> official releases by using cmsFLAGS_NOOPTIMIZE when input grayscale is
> being used. I guess this is not very common as the flaw has been unnoticed
> by years. In 2.13 is more evident because another bug was discarding
> channels G and B in the gray->RGB optimized transforms, anyway that was
> wrong too.
>
> Regards
> Marti
>
>
>
>
> On 30 Jan 2022, at 02:48, Aaron Boxer <bo...@gm...> wrote:
>
> Hi Marti,
>
> Thank you for this new release! I think I have found a regression, though.
>
> I maintain the Grok Jpeg 2000 codec, and we use lcms2 to apply ICC
> profiles after
> decompressing from JPEG 2000.
>
> The attached file file8.jp2 is a monochrome image
> with a grayscale ICC profile.  For decompression, the codec decompresses
> the single channel, applies the ICC profile, and then converts it to RGB
> (by duplicating the mono channel)
>
> file8.jp2.tif is the decompressed result with the older version of lcms2.
> file8.jp2_new.tif is the result with lcms2 2.13. You can see that the
> image w/ 2.13
> is saturating at the top of the range.
>
> If you need, I can point you to the code that applies the ICC profile.
>
> Let me know if I can provide any more information.
> Thanks again,
> Aaron
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>
>

Re: [Lcms-user] [ANNOUNCE] Little CMS 2.13 released

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

Hi Aaron,

Thanks for reporting, but unfortunately I cannot reproduce the issue. I have extracted the profile embedded in file8.jp2 and it seems a quite typical gray profile. 
Tried transicc and numbers goes fine. Also tried tificc with several combinations of the profile as input and as output and everything works as expected.
Could you please tell me details how are you doing the transform? In special, are you using the fast_float plugin?
 
Thanks again and best regards
Marti Maria

> On 30 Jan 2022, at 02:48, Aaron Boxer <bo...@gm...> wrote:
> 
> Hi Marti,
> 
> Thank you for this new release! I think I have found a regression, though.
> 
> I maintain the Grok Jpeg 2000 codec, and we use lcms2 to apply ICC profiles after
> decompressing from JPEG 2000. 
> 
> The attached file file8.jp2 is a monochrome image
> with a grayscale ICC profile.  For decompression, the codec decompresses
> the single channel, applies the ICC profile, and then converts it to RGB 
> (by duplicating the mono channel)
> 
> file8.jp2.tif is the decompressed result with the older version of lcms2.
> file8.jp2_new.tif is the result with lcms2 2.13. You can see that the image w/ 2.13 
> is saturating at the top of the range.
> 
> If you need, I can point you to the code that applies the ICC profile.
> 
> Let me know if I can provide any more information.
> Thanks again,
> Aaron
> 

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

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

I am glad  to announce the release of lcms2-2.13.

Get it here: https://sourceforge.net/projects/lcms/files/latest/download

Files kindly hosted by sourceforge


Changes

	• Added support for premultiplied alpha
	• tifficc can now handle alpha channels, both unassociated and premultiplied
	• Better documentation
	• CGATS parser can now deal with very long strings
	• Added Projects for Visual Studio 2020
	• Travis CI discontinued, GitHub actions used instead
	• Added a very preliminary meson build script (thanks to xclaesse)
	• Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
	• Added thread safe code to get time
	• Added automatic linear space detection
	• Added cmsGetStageContextID function
	• Added cmsDetectRGBProfileGamma
	• configure now accepts --without-fastfloat to turn plugin off
	• autogen.sh has now a --distclean toggle to get rid of all autotools generated files
	• Checked to work on STM32 Cortex-A, Cortex-M families
	• Bug & typos fixing (thanks to many reporters and contributors)
	• Fixed mem leaks and out-of bounds accesses as reported by fuzzer



Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com

[Lcms-user] Crafting a YCbCr profile with LittleCMS

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

Hi,

I am writing to this list in hope of getting some help for crafting 
profiles with LittleCMS. My objective is to craft a Rec.709 YCbCr to XYZ 
profile for Krita. The YCbCr -> XYZ conversion goes as this:

1. YCbCr -> normalized R'G'B. Source: Ford & Roberts (1998), eq. 105. 
<http://poynton.ca/PDFs/coloureq.pdf>

2. Normalized R'G'B -> linear RGB. Source: ITU-R BT.2087

3. Linear RGB -> XYZ. Source: Ford & Roberts (1998), eq. 102. 
<http://poynton.ca/PDFs/coloureq.pdf>


And for the XYZ -> YCbCr side of things,

1. XYZ -> Linear RGB. Source: Ford & Roberts (1998), eq. 103. 
<http://poynton.ca/PDFs/coloureq.pdf>

2. Linear RGB -> Normalized R'G'B. Source: ITU-R BT.2087

3. Normalized R'G'B -> YCbCr. Source: Ford & Roberts (1998), eq. 104. 
<http://poynton.ca/PDFs/coloureq.pdf>



My questions are as follows:

1. Are the pipelines correct? If not, what are the errors?

2. According to the ICC 4.3 standard, sections 10.10.1 and 10.11.1, to 
use the CLUT I must wrap it in two triplets of (identity) tone curves. 
But doing so simply renders the pipeline into an empty tag, so I need to 
downgrade to 2.2 and remove the tone curves from the pipeline. Why is 
this happening?



If anyone wants to check my code out, I have uploaded it at 
<https://github.com/amyspark/krita-ycbcr-profiles>. Please reply to this 
email with any questions you may have.

Best regards,

amyspark

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

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

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

Hi,

Many thanks to all reporters. 

Please see here the release candidate two, with fixes for found glitches and memory leaks. 

https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc2

If this candidate is ok I will proceed with the official release on end of January as expected.

Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com <http://www.littlecms.com/>



> On 7 Jan 2022, at 18:23, Marti Maria <mar...@li...> wrote:
> 
> Happy new year!
> 
> I am happy to announce the imminent release of lcms2-2.13.
> 
> The first release candidate is available here:
> 
> https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc1
> 
> Changes 
> 
> - Added support for premultiplied alpha
> - tifficc can now handle alpha channels, both unassociated and premultiplied
> - Better documentation
> - CGATS parser can now deal with very long strings
> - Added Projects for Visual Studio 2020
> - Travis CI discontinued, GitHub actions used instead
> - Added a very preliminary meson build script (thanks to xclaesse)
> - Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
> - Added thread safe code to get time
> - Added automatic linear space detection 
> - Added cmsGetStageContextID function
> - configure now accepts --without-fastfloat to turn plugin off
> - autogen.sh has now a --distclean toggle to get rid of all autotools generated files
> - Checked to work on STM32 Cortex-A, Cortex-M families
> - Bug & typos fixing (thanks to many reporters and contributors)
> 
> 
> Feel free to test it on all your products, tentative release date for final lcms2-2.13 is end of Jan-2022 Please contact me on any issue either on info { at } littecms.com <mailto:in...@li...> or using this list.
> 
> 
> Best regards
> Marti Maria
> The LittleCMS Project
> http:\www.littlecms.com <http://www.littlecms.com/>

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

[LittleCMS c. s. <in...@li...>]

Happy new year!


I am glad  to announce the imminent release of lcms2-2.13.

The first release candidate is available here:

https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc1 <https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc1>

(Sorry, now with the right link behind the text)


Changes 

- Added support for premultiplied alpha
- tifficc can now handle alpha channels, both unassociated and premultiplied
- Better documentation
- CGATS parser can now deal with very long strings
- Added Projects for Visual Studio 2020
- Travis CI discontinued, GitHub actions used instead
- Added a very preliminary meson build script (thanks to xclaesse)
- Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
- Added thread safe code to get time
- Added automatic linear space detection 
- Added cmsGetStageContextID function
- configure now accepts --without-fastfloat to turn plugin off
- autogen.sh has now a --distclean toggle to get rid of all autotools generated files
- Checked to work on STM32 Cortex-A, Cortex-M families
- Bug & typos fixing (thanks to many reporters and contributors)


Feel free to test it on all your products, tentative release date for final lcms2-2.13 is end of Jan-2022 Please contact me on any issue either on info { at } littecms.com <mailto:in...@li...> or using this list.


Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com <http://www.littlecms.com/>

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

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

Happy new year!

I am happy to announce the imminent release of lcms2-2.13.

The first release candidate is available here:

https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc1 <http://www.littlecms.com/lcms2-2.10rc1.tar.gz>

Changes 

- Added support for premultiplied alpha
- tifficc can now handle alpha channels, both unassociated and premultiplied
- Better documentation
- CGATS parser can now deal with very long strings
- Added Projects for Visual Studio 2020
- Travis CI discontinued, GitHub actions used instead
- Added a very preliminary meson build script (thanks to xclaesse)
- Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
- Added thread safe code to get time
- Added automatic linear space detection 
- Added cmsGetStageContextID function
- configure now accepts --without-fastfloat to turn plugin off
- autogen.sh has now a --distclean toggle to get rid of all autotools generated files
- Checked to work on STM32 Cortex-A, Cortex-M families
- Bug & typos fixing (thanks to many reporters and contributors)


Feel free to test it on all your products, tentative release date for final lcms2-2.13 is end of Jan-2022 Please contact me on any issue either on info { at } littecms.com <mailto:in...@li...> or using this list.


Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com <http://www.littlecms.com/>

[Lcms-user] Multi channel profiles

[Robin W. <rob...@ar...>]

Hi all,

I'd be very interested in speaking to anyone that uses LCMS with 'high' 
numbers of color channels. (i.e. people who use LCMS with color profiles 
for higher than the usual 4 CMYK channels).

In particular, I'd be very interested in seeing a) some relevant color 
profiles, and b) some files that use those.

If you are such a person, please contact me! Probably best to do it off 
list, so we don't clog up the channel here.

Thanks in advance!

Robin

Re: [Lcms-user] Question about sRGB and rendering intent

[Aaron B. <bo...@gm...>]

Hi Marti,
Thank you, I will continue to ignore gAMMA and cHRM. I think I can get away
without an ICC profile, as I already indicate sRGB
color space in the image header. My guess is that perceptual was simply
chosen in the original file because
it equals zero, which seems to be a sane default value, even if it isn't :)
Best,
Aaron


On Tue, Sep 14, 2021 at 3:50 PM Marti Maria <mar...@li...>
wrote:

>
> Hi,
>
> My advice: just ignore gAMMA and cHRM chunks, they are just an
> approximation to sRGB space for non color-savvy readers. Embed the standard
> sRGB profile with relative colorimetric intent and this is colorimetrically
> correct and going to work in most situations.
>
> In the embedded profile you may use perceptual or relative colorimetric,
> but this indeed is an advanced topic. Please note that the image is already
> “in-gamut” so the meaning of the intent here is something completely
> different.
>
> if you use “relative colorimetric”: that means all RGB in the image have a
> direct correspondence with Lab. There is no color shifts or movements. The
> profile exactly identifies the Lab of each RGB triplet in a colorimetric
> way.
> if you use “perceptual”: That means the RGB has been tweaked to “look
> good” under whatever device the embedded profile represents. You can use
> the perceptual table A2B0 of the embedded profile to “undo” this preference
> mapping and obtain the original Lab values. Doing so may result in
> different appearance, but maybe close to the original image, whatever
> “original image” may mean.
>
> So, be careful with perceptual, as it can destroy images if you don’t know
> the gory details under the hood.
>
> Best regards
> Marti Maria.
>
>
> > On 14 Sep 2021, at 16:21, Aaron Boxer <bo...@gm...> wrote:
> >
> > Hello!
> > This question is not LCMS specific, but I figured this is a good place
> > to ask a general CMS question:
> >
> > I have a PNG image in sRGB space with sRGB chunk (perceptual rendering
> intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am
> converting this image to JPEG 2000
> > format, which does not store rendering intent information. When I
> convert, I ignore the gamma and chroma info.
> >
> > Does it make sense to convert perceptual rendering intent into an ICC
> profile for display ? JPEG 2000 is able to store ICC profiles.
> >
> > Any insight here would be greatly appreciated.
> > Thanks,
> > Aaron
> > _______________________________________________
> > Lcms-user mailing list
> > Lcm...@li...
> > https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

Re: [Lcms-user] Question about sRGB and rendering intent

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

Hi,

My advice: just ignore gAMMA and cHRM chunks, they are just an approximation to sRGB space for non color-savvy readers. Embed the standard sRGB profile with relative colorimetric intent and this is colorimetrically correct and going to work in most situations.

In the embedded profile you may use perceptual or relative colorimetric, but this indeed is an advanced topic. Please note that the image is already “in-gamut” so the meaning of the intent here is something completely different.

if you use “relative colorimetric”: that means all RGB in the image have a direct correspondence with Lab. There is no color shifts or movements. The profile exactly identifies the Lab of each RGB triplet in a colorimetric way.
if you use “perceptual”: That means the RGB has been tweaked to “look good” under whatever device the embedded profile represents. You can use the perceptual table A2B0 of the embedded profile to “undo” this preference mapping and obtain the original Lab values. Doing so may result in different appearance, but maybe close to the original image, whatever “original image” may mean.

So, be careful with perceptual, as it can destroy images if you don’t know the gory details under the hood.

Best regards
Marti Maria.


> On 14 Sep 2021, at 16:21, Aaron Boxer <bo...@gm...> wrote:
> 
> Hello!
> This question is not LCMS specific, but I figured this is a good place
> to ask a general CMS question:
> 
> I have a PNG image in sRGB space with sRGB chunk (perceptual rendering intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am converting this image to JPEG 2000
> format, which does not store rendering intent information. When I convert, I ignore the gamma and chroma info.
> 
> Does it make sense to convert perceptual rendering intent into an ICC profile for display ? JPEG 2000 is able to store ICC profiles.
> 
> Any insight here would be greatly appreciated.
> Thanks,
> Aaron 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Question about sRGB and rendering intent

[Aaron B. <bo...@gm...>]

Thanks, Noel. I have no idea how the images will eventually be viewed.
I just don't want any color management information lost when the images are
compressed.
So, since I don't know how the images will be rendered, I guess it makes
sense
to suppress the origin perceptual rendering intent.
Aaron


On Tue, Sep 14, 2021 at 11:21 AM Noel Carboni <
NCa...@pr...> wrote:

> Hi Aaron,
>
>
>
> How do you imagine these images being viewed?  Online?  On a device with a
> specific viewer application?  What has gone
>
>
>
> Not all software handles all formats or even does color management
> properly.
>
>
>
> -Noel
>
>
>
> *From:* Aaron Boxer <bo...@gm...>
> *Sent:* Tuesday, September 14, 2021 10:22 AM
> *To:* lcm...@li...
> *Subject:* [Lcms-user] Question about sRGB and rendering intent
>
>
>
> Hello!
>
> This question is not LCMS specific, but I figured this is a good place
>
> to ask a general CMS question:
>
>
>
> I have a PNG image in sRGB space with sRGB chunk (perceptual rendering
> intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am
> converting this image to JPEG 2000
>
> format, which does not store rendering intent information. When I convert,
> I ignore the gamma and chroma info.
>
>
>
> Does it make sense to convert perceptual rendering intent into an ICC
> profile for display ? JPEG 2000 is able to store ICC profiles.
>
>
>
> Any insight here would be greatly appreciated.
>
> Thanks,
>
> Aaron
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

Re: [Lcms-user] Question about sRGB and rendering intent

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

Hi Aaron,

 

How do you imagine these images being viewed?  Online?  On a device with a specific viewer application?  What has gone 

 

Not all software handles all formats or even does color management properly.

 

-Noel

 

From: Aaron Boxer <bo...@gm...> 
Sent: Tuesday, September 14, 2021 10:22 AM
To: lcm...@li...
Subject: [Lcms-user] Question about sRGB and rendering intent

 

Hello!

This question is not LCMS specific, but I figured this is a good place

to ask a general CMS question:

 

I have a PNG image in sRGB space with sRGB chunk (perceptual rendering intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am converting this image to JPEG 2000

format, which does not store rendering intent information. When I convert, I ignore the gamma and chroma info.

 

Does it make sense to convert perceptual rendering intent into an ICC profile for display ? JPEG 2000 is able to store ICC profiles.

 

Any insight here would be greatly appreciated.

Thanks,

Aaron 

[Lcms-user] Question about sRGB and rendering intent

[Aaron B. <bo...@gm...>]

Hello!
This question is not LCMS specific, but I figured this is a good place
to ask a general CMS question:

I have a PNG image in sRGB space with sRGB chunk (perceptual rendering
intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am
converting this image to JPEG 2000
format, which does not store rendering intent information. When I convert,
I ignore the gamma and chroma info.

Does it make sense to convert perceptual rendering intent into an ICC
profile for display ? JPEG 2000 is able to store ICC profiles.

Any insight here would be greatly appreciated.
Thanks,
Aaron

Re: [Lcms-user] css-color-hdr and HDR eotfs (Jzazbz and ICtCp)

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

Ok, I found the answer to my own question(s): Not yet.

All of these are being discussed on whether they'll become extensions
to ICC4 & Max:
http://www.color.org/groups/hdr/index.xalter

This also includes recommended ways of handling NCLX colorspace descriptions,
for those of us that are trying to figure out the mysteries of heif and avif.

Hope this helps,

On Wed, Feb 10, 2021 at 3:41 PM Wolthera <gri...@gm...> wrote:
>
> hey,
>
> I was reading the css-color-hdr draft [1], and it contains a few
> unusual colorspaces.
>
> Now, as far as I understand it, the only way to have an ICC spec
> conformant icc profile for Rec 2100 is by using LUTs, because the PQ
> and HLG eotfs cannot be described by the formulas in the ICC specs
> [2]. But at the least it is possible.
>
> But the draft also specifies a Jzazbz colorspace (which seems to be
> L*a*b*, except L* is replaced with the PQ-encoded Jz) as well as ICtCp
> [3].
>
> Is it possible to have icc profiles, or a littleCMS workflow for
> these? I'm not too familiar with the icc profile spec, so I don't know
> what the exact rules are for these big encompassing colorspaces, and I
> think it'd be valuable for W3C to have the feedback if these
> colorspaces are not possible for a variety of open source software.
>
> [1] - https://drafts.csswg.org/css-color-hdr/
> [2] - https://github.com/mm2/Little-CMS/issues/217
> [3] - https://en.wikipedia.org/wiki/ICtCp
> --
> Wolthera



-- 
Wolthera

[Lcms-user] css-color-hdr and HDR eotfs (Jzazbz and ICtCp)

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

hey,

I was reading the css-color-hdr draft [1], and it contains a few
unusual colorspaces.

Now, as far as I understand it, the only way to have an ICC spec
conformant icc profile for Rec 2100 is by using LUTs, because the PQ
and HLG eotfs cannot be described by the formulas in the ICC specs
[2]. But at the least it is possible.

But the draft also specifies a Jzazbz colorspace (which seems to be
L*a*b*, except L* is replaced with the PQ-encoded Jz) as well as ICtCp
[3].

Is it possible to have icc profiles, or a littleCMS workflow for
these? I'm not too familiar with the icc profile spec, so I don't know
what the exact rules are for these big encompassing colorspaces, and I
think it'd be valuable for W3C to have the feedback if these
colorspaces are not possible for a variety of open source software.

[1] - https://drafts.csswg.org/css-color-hdr/
[2] - https://github.com/mm2/Little-CMS/issues/217
[3] - https://en.wikipedia.org/wiki/ICtCp
-- 
Wolthera