lcms-user — For users of the little cms library

Re: [Lcms-user] Need help recovering the chromaticities that a profile was made with

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

Hello,

 

> is there something I'm not accounting for? And is there a more correct way to read the original chromaticities back out of a profile?

 

You are assuming the internals of ICC profiles works in a way they don’t. The cmsSigXXXColorantTag tags does NOT contain direct information on the primaries, numbers are “cooked” and it is certainly possible for those tags to be missing on some profiles.

 

You should avoid reading tags directly as much as possible. Instead, use an absolute colorimetric transform with no observer adaptation to get the primaries.  This would work no matter which profile type are you using.

 

Here an example by using the transicc tool, you can do the same creating a transform with absolute colorimetric intent making sure to set the observer adaptation state to 0 first. I am trying to recover sRGB red primary:

 

marti@I7:~$ transicc -t3 -d0 -i*sRGB -o*XYZ

LittleCMS ColorSpace conversion calculator - 5.1 [LittleCMS 2.16]

Copyright (c) 1998-2023 Marti Maria Saguer. See COPYING file for details.

 

Enter values, 'q' to quit

R? 255

G? 0

B? 0

 

X=41.2391 Y=21.2639 Z=1.9331

 

You convert this XYZ of (41.2391, 21.2639, 1.9331) to xyY, for example using this link: http://www.brucelindbloom.com/ColorCalculator.html

 

xyY = (0.6400, 0.3300, 21.2639) Which corresponds to the Rec709 chromaticity of red.

 

Hope that helps

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

 

 

From: Adrian Knagg-Baugh <aje...@gm...> 
Sent: Monday, January 29, 2024 10:34 PM
To: lcm...@li...
Subject: [Lcms-user] Need help recovering the chromaticities that a profile was made with

 

Hi,

 

I have extracted the chromaticity xy coordinates from a cmsHPROFILE as follows:


cmsCIEXYZ   *red;
cmsCIEXYZ   *green;
cmsCIEXYZ   *blue;
red   = cmsReadTag (profile, cmsSigRedColorantTag);
green = cmsReadTag (profile, cmsSigGreenColorantTag);
blue  = cmsReadTag (profile, cmsSigBlueColorantTag);

cmsXYZ2xyY(&redxyY, &red);
cmsXYZ2xyY(&greenxyY, &green);

cmsXYZ2xyY(&bluexyY, &blue);

 

However, if the profile I do this to is a sRGB profile made with chromaticities from the cmsCIExyYTRIPLE {{0.639998686, 0.330010138, 1.0}, {0.300003784, 0.600003357, 1.0}, {0.150002046, 0.059997204, 1.0}}, and the standard sRGB whitepoint cmsCIExyY d65_srgb_adobe_specs = {0.3127, 0.3290, 1.0}; I don't get back the same coordinates. Instead I get:

 

redxyY x: 0.648438, y: 0.330868, Y: 0.222488 
greenxyY x: 0.321176, y: 0.597877, Y: 0.716904 
bluexyY x: 0.155899, y: 0.066051, Y: 0.060608 

 

What's going on here: is there something I'm not accounting for? And is there a more correct way to read the original chromaticities back out of a profile?

 

Thanks,

 

Adrian.

 

Re: [Lcms-user] Need help recovering the chromaticities that a profile was made with

[Adrian Knagg-B. <aje...@gm...>]

Thank you for the explanation. Yes, that's great, I will create a transform
from profile to XYZ, use it to transform each RGB primary using absolute
colorimetric, and then convert to xyY straightforwardly.

Thanks again,

Adrian.

On Mon, 29 Jan 2024, 22:02 , <mar...@li...> wrote:

> Hello,
>
>
>
> > is there something I'm not accounting for? And is there a more correct
> way to read the original chromaticities back out of a profile?
>
>
>
> You are assuming the internals of ICC profiles works in a way they don’t.
> The cmsSigXXXColorantTag tags does NOT contain direct information on the
> primaries, numbers are “cooked” and it is certainly possible for those tags
> to be missing on some profiles.
>
>
>
> You should avoid reading tags directly as much as possible. Instead, use
> an absolute colorimetric transform with no observer adaptation to get the
> primaries.  This would work no matter which profile type are you using.
>
>
>
> Here an example by using the transicc tool, you can do the same creating a
> transform with absolute colorimetric intent making sure to set the observer
> adaptation state to 0 first. I am trying to recover sRGB red primary:
>
>
>
> marti@I7:~$ transicc -t3 -d0 -i*sRGB -o*XYZ
>
> LittleCMS ColorSpace conversion calculator - 5.1 [LittleCMS 2.16]
>
> Copyright (c) 1998-2023 Marti Maria Saguer. See COPYING file for details.
>
>
>
> Enter values, 'q' to quit
>
> R? 255
>
> G? 0
>
> B? 0
>
>
>
> X=41.2391 Y=21.2639 Z=1.9331
>
>
>
> You convert this XYZ of (41.2391, 21.2639, 1.9331) to xyY, for example
> using this link: http://www.brucelindbloom.com/ColorCalculator.html
>
>
>
> xyY = (0.6400, 0.3300, 21.2639) Which corresponds to the Rec709
> chromaticity of red.
>
>
>
> Hope that helps
>
>
>
> Marti Maria
>
> The LittleCMS Project
>
> https://www.littlecms.com
>
>
>
>
>
>
>
>
>
> *From:* Adrian Knagg-Baugh <aje...@gm...>
> *Sent:* Monday, January 29, 2024 10:34 PM
> *To:* lcm...@li...
> *Subject:* [Lcms-user] Need help recovering the chromaticities that a
> profile was made with
>
>
>
> Hi,
>
>
>
> I have extracted the chromaticity xy coordinates from a cmsHPROFILE as
> follows:
>
>
> cmsCIEXYZ   *red;
> cmsCIEXYZ   *green;
> cmsCIEXYZ   *blue;
> red   = cmsReadTag (profile, cmsSigRedColorantTag);
> green = cmsReadTag (profile, cmsSigGreenColorantTag);
> blue  = cmsReadTag (profile, cmsSigBlueColorantTag);
>
> cmsXYZ2xyY(&redxyY, &red);
> cmsXYZ2xyY(&greenxyY, &green);
>
> cmsXYZ2xyY(&bluexyY, &blue);
>
>
>
> However, if the profile I do this to is a sRGB profile made with
> chromaticities from the cmsCIExyYTRIPLE {{0.639998686, 0.330010138, 1.0},
> {0.300003784, 0.600003357, 1.0}, {0.150002046, 0.059997204, 1.0}}, and the
> standard sRGB whitepoint cmsCIExyY d65_srgb_adobe_specs = {0.3127, 0.3290,
> 1.0}; I don't get back the same coordinates. Instead I get:
>
>
>
> redxyY x: 0.648438, y: 0.330868, Y: 0.222488
> greenxyY x: 0.321176, y: 0.597877, Y: 0.716904
> bluexyY x: 0.155899, y: 0.066051, Y: 0.060608
>
>
>
> What's going on here: is there something I'm not accounting for? And is
> there a more correct way to read the original chromaticities back out of a
> profile?
>
>
>
> Thanks,
>
>
>
> Adrian.
>
>
>

[Lcms-user] Need help recovering the chromaticities that a profile was made with

[Adrian Knagg-B. <aje...@gm...>]

Hi,

I have extracted the chromaticity xy coordinates from a cmsHPROFILE as
follows:

cmsCIEXYZ   *red;
cmsCIEXYZ   *green;
cmsCIEXYZ   *blue;
red   = cmsReadTag (profile, cmsSigRedColorantTag);
green = cmsReadTag (profile, cmsSigGreenColorantTag);
blue  = cmsReadTag (profile, cmsSigBlueColorantTag);
cmsXYZ2xyY(&redxyY, &red);
cmsXYZ2xyY(&greenxyY, &green);
cmsXYZ2xyY(&bluexyY, &blue);

However, if the profile I do this to is a sRGB profile made with
chromaticities from the cmsCIExyYTRIPLE {{0.639998686, 0.330010138, 1.0},
{0.300003784, 0.600003357, 1.0}, {0.150002046, 0.059997204, 1.0}}, and the
standard sRGB whitepoint cmsCIExyY d65_srgb_adobe_specs = {0.3127, 0.3290,
1.0}; I don't get back the same coordinates. Instead I get:

redxyY x: 0.648438, y: 0.330868, Y: 0.222488
greenxyY x: 0.321176, y: 0.597877, Y: 0.716904
bluexyY x: 0.155899, y: 0.066051, Y: 0.060608

What's going on here: is there something I'm not accounting for? And is
there a more correct way to read the original chromaticities back out of a
profile?

Thanks,

Adrian.

Re: [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

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

Hi,

 

>ie JDK could (SFAICS) change to specify the flag only when both src and dest have alpha.
>I don't know when we actually need it when there's no alpha. Sergey ?

 

That would solve all issues. Problem is, the code has no idea on how alpha should be interpreted, and this includes initializing. So, whatever I do to initialize alpha would be wrong in some cases. At that point I think it is better just flagging the error and let’s user to decide.

Please note if you don’t specify the flag, the dest alpha channel is untouched, so the caller is responsible of initializing it. If you specify the flag, then the destination alpha channel is initialized by the CMM by copying it from source. The difference is when using the flag you can just malloc the dest memory, without the flag you have to process it before calling cmsDoTransform.

Regards

 

Marti Maria

The LittleCMS Project

 <https://www.littlecms.com> https://www.littlecms.com

 

 

 

 

From: Philip Race <phi...@or...> 
Sent: Friday, January 5, 2024 8:55 PM
To: mar...@li...; Lcm...@li...
Subject: Re: [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

 

 

On 1/4/24 1:19 AM, mar...@li... <mailto:mar...@li...>  wrote:

Hi Phil,

 

The reason was to prevent using this flag when the output has alpha channel and there is no source alpha.


Specifically that case ?
The JDK code currently and only relies on the opposite case, but the check as written allows neither.




Other examples are different number of alpha channels. It is not clear what to do with the alpha in such cases. Should lcms initialize the excess with zero?

Some folks began to have ideas of adding a new interface to init spare alpha channels so I just applied Occam’s razor. 

 

I am open to changes as long as they make sense. The actual implementation complains if the request cannot be accomplished, user specify to copy alpha and there is no alpha or the number of channels is different, an error is triggered. 

I guess you don’t like this being reported as an error. Ignoring the request seems also not right because user may think it is being performed whilst is really not.

 

What should I do?


Mainly I'd like some quick clarity so we can decide if we should change JDK code or wait for an update to LCMS.

I can see the argument that specifying "copy alpha" is inconsistent with "there's no alpha to copy from", or
"there's nowhere to copy the alpha to". And I can also see that it could easily be a mistake on the part of the app,
that is best flagged in an upfront way.

But if there's a sensible default action in some subset of  these cases, that's documented and easily understood, 
meaning not loaded with exceptions and caveats, which would allow the existing usage to function properly,
that might be preferable. 

I am not sure that either choice (keep the check as is, or relax it) would make what Sergey is asking for impossible,
but I'll defer to him to comment on that.

ie JDK could (SFAICS) change to specify the flag only when both src and dest have alpha.
I don't know when we actually need it when there's no alpha. Sergey ?

-phil.




 

Regards

Marti Maria

The LittleCMS Project

 <https://www.littlecms.com> https://www.littlecms.com

 

 

 

From: Philip Race  <mailto:phi...@or...> <phi...@or...> 
Sent: Wednesday, January 3, 2024 9:00 PM
To: Lcm...@li... <mailto:Lcm...@li...> 
Subject: [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

 

JDK is using the flag cmsFLAGS_COPY_ALPHA. It is specified in a few cases including if
the source has alpha but the destination is opaque, expecting that the alpha channel will be ignored.

Here's where JDK started using the flag https://github.com/openjdk/jdk/commit/16acfafb#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98b

But in LCMS 2.16 there's a new check that this is running afoul of.
https://github.com/mm2/Little-CMS/commit/e55b6fa4d3c5b7e08d9e4bc8c803a79ca908b5a4#diff-3627f903d37617a227e71f0ee1[…]2629b5ee838707e3fcd7dcb46e762f4e

It seems to me that likely we could just drop specifying cmsFLAGS_COPY_ALPHA in this case,
but I can't find any background information on the reason for the change in LCMS, or awareness that
it might be a compatibility issue.

Thoughts / comments ? 

-phil.




 

Re: [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

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

On 1/4/24 1:19 AM, mar...@li... wrote:
>
> Hi Phil,
>
> The reason was to prevent using this flag when the output has alpha 
> channel and there is no source alpha.
>

Specifically that case ?
The JDK code currently and only relies on the opposite case, but the 
check as written allows neither.

> Other examples are different number of alpha channels. It is not clear 
> what to do with the alpha in such cases. Should lcms initialize the 
> excess with zero?
>
> Some folks began to have ideas of adding a new interface to init spare 
> alpha channels so I just applied Occam’s razor.
>
> I am open to changes as long as they make sense. The actual 
> implementation complains if the request cannot be accomplished, user 
> specify to copy alpha and there is no alpha or the number of channels 
> is different, an error is triggered.
>
> I guess you don’t like this being reported as an error. Ignoring the 
> request seems also not right because user may think it is being 
> performed whilst is really not.
>
> What should I do?
>

Mainly I'd like some quick clarity so we can decide if we should change 
JDK code or wait for an update to LCMS.

I can see the argument that specifying "copy alpha" is inconsistent with 
"there's no alpha to copy from", or
"there's nowhere to copy the alpha to". And I can also see that it could 
easily be a mistake on the part of the app,
that is best flagged in an upfront way.

But if there's a sensible default action in some subset of  these cases, 
that's documented and easily understood,
meaning not loaded with exceptions and caveats, which would allow the 
existing usage to function properly,
that might be preferable.

I am not sure that either choice (keep the check as is, or relax it) 
would make what Sergey is asking for impossible,
but I'll defer to him to comment on that.

ie JDK could (SFAICS) change to specify the flag only when both src and 
dest have alpha.
I don't know when we actually need it when there's no alpha. Sergey ?

-phil.

> Regards
>
> Marti Maria
>
> The LittleCMS Project
>
> https://www.littlecms.com <https://www.littlecms.com>
>
> *From:* Philip Race <phi...@or...>
> *Sent:* Wednesday, January 3, 2024 9:00 PM
> *To:* Lcm...@li...
> *Subject:* [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: 
> Mismatched alpha channels
>
> JDK is using the flag cmsFLAGS_COPY_ALPHA. It is specified in a few 
> cases including if
> the source has alpha but the destination is opaque, expecting that the 
> alpha channel will be ignored.
>
> Here's where JDK started using the flag 
> https://github.com/openjdk/jdk/commit/16acfafb#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98b
>
> But in LCMS 2.16 there's a new check that this is running afoul of.
> https://github.com/mm2/Little-CMS/commit/e55b6fa4d3c5b7e08d9e4bc8c803a79ca908b5a4#diff-3627f903d37617a227e71f0ee1[…]2629b5ee838707e3fcd7dcb46e762f4e
>
> It seems to me that likely we could just drop specifying 
> cmsFLAGS_COPY_ALPHA in this case,
> but I can't find any background information on the reason for the 
> change in LCMS, or awareness that
> it might be a compatibility issue.
>
> Thoughts / comments ?
>
> -phil.
>

Re: [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

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

Hi Phil,

 

The reason was to prevent using this flag when the output has alpha channel and there is no source alpha. Other examples are different number of alpha channels. It is not clear what to do with the alpha in such cases. Should lcms initialize the excess with zero?

Some folks began to have ideas of adding a new interface to init spare alpha channels so I just applied Occam’s razor. 

 

I am open to changes as long as they make sense. The actual implementation complains if the request cannot be accomplished, user specify to copy alpha and there is no alpha or the number of channels is different, an error is triggered. 

I guess you don’t like this being reported as an error. Ignoring the request seems also not right because user may think it is being performed whilst is really not.

 

What should I do?

 

Regards

Marti Maria

The LittleCMS Project

 <https://www.littlecms.com> https://www.littlecms.com

 

 

 

From: Philip Race <phi...@or...> 
Sent: Wednesday, January 3, 2024 9:00 PM
To: Lcm...@li...
Subject: [Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

 

JDK is using the flag cmsFLAGS_COPY_ALPHA. It is specified in a few cases including if
the source has alpha but the destination is opaque, expecting that the alpha channel will be ignored.

Here's where JDK started using the flag https://github.com/openjdk/jdk/commit/16acfafb#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98b

But in LCMS 2.16 there's a new check that this is running afoul of.
https://github.com/mm2/Little-CMS/commit/e55b6fa4d3c5b7e08d9e4bc8c803a79ca908b5a4#diff-3627f903d37617a227e71f0ee1[…]2629b5ee838707e3fcd7dcb46e762f4e

It seems to me that likely we could just drop specifying cmsFLAGS_COPY_ALPHA in this case,
but I can't find any background information on the reason for the change in LCMS, or awareness that
it might be a compatibility issue.

Thoughts / comments ? 

-phil.

[Lcms-user] LCMS 2.16: CMMException: LCMS error 13: Mismatched alpha channels

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

JDK is using the flag cmsFLAGS_COPY_ALPHA. It is specified in a few 
cases including if
the source has alpha but the destination is opaque, expecting that the 
alpha channel will be ignored.

Here's where JDK started using the flag 
https://github.com/openjdk/jdk/commit/16acfafb#diff-eed6ddb15e9c5bdab9fc3b3930d5d959966165d9622ddd293e8572489adea98b

But in LCMS 2.16 there's a new check that this is running afoul of.
https://github.com/mm2/Little-CMS/commit/e55b6fa4d3c5b7e08d9e4bc8c803a79ca908b5a4#diff-3627f903d37617a227e71f0ee1[…]2629b5ee838707e3fcd7dcb46e762f4e

It seems to me that likely we could just drop specifying 
cmsFLAGS_COPY_ALPHA in this case,
but I can't find any background information on the reason for the change 
in LCMS, or awareness that
it might be a compatibility issue.

Thoughts / comments ?

-phil.

Re: [Lcms-user] How does a transformation work

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

Hi,

>From your explanation, it seems to me that the transformation you want has nothing to do with color management. You know nothing about the L* of your grayscale and need only some scaling. I would rather use simple math in this case:

Gray_out = (Gray_in * 40) /51 + 40;

You could just use a for() loop. This is going to be faster that using any color management routines.

Regards

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




> -----Original Message-----
> From: flap <fb...@oh...>
> Sent: Friday, December 29, 2023 12:06 PM
> To: lcm...@li...
> Subject: [Lcms-user] How does a transformation work
> 
> Hi list,
> 
> what I want: an 8 bit grey-scale output for my printer, where the input dot
> values (0 … 255) are scaled and limited to values of 40 … 240 (…just an
> example).
> 
> So I created a simple test input data (256 elements of unsigned char) with a
> linear ramp from 0 (at index 0) … 255 (at index 255).
> 
> And I created an array with 4096 short entries beginning with 40 (* 256 for
> unsigned short) and ramp up linear to 240 (* 256 for unsigned short) and feed
> it into cmsBuildTabulatedToneCurve16() and cmsCreateGrayProfile() with
> cmsD50_xyY() as its whitepoint (for the output profile).
> 
> For the input profile I used cmsBuildGamma() with a value of 1.0 and
> cmsCreateGrayProfile() with cmsD50_xyY().
> 
> After creating the transformation with cmsCreateTransform() with
> input/output types both TYPE_GRAY_8 and an intent of INTENT_PERCEPTUAL
> and applying this transformation with cmsDoTransformLineStride () to my
> simple input data, the output result is still almost linear from 0 to 255 and not
> limited to 40 … 240.
> 
> So, I think I'm using the tone curves in a wrong way. But where is my mistake?
> 
> Cheers,
> Jürgen
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] How does a transformation work

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

Ok, 

The procedure to create a gray profile is simple. 
First measure the transfer function of your gray device to XYZ. That could be a gamma curve or anything.
Then measure the white point of your gray space. The adaptation to D50 is already done by lcms.
Then create a tone curve with your transfer function. 
Finally, by using white point and curve, create a profile.

Please note you cannot map contone values for input to output since the output profile is unknown. So, you cannot map 0 to 40 and 255 to 240. You can only characterize which XYZ you get with gray = 0 and gray = 255.

Example:

    cmsToneCurve* tone;
    cmsUInt16Number curve[256];
    int i;
    cmsHPROFILE hProfile;

    for (i = 0; i < 256; i++)
    {        
        curve[i] = (cmsUInt16Number) round(65535.0 * pow(i / 255.0, 2.2));
    }

    tone = cmsBuildTabulatedToneCurve16(0, 256, curve);

    hProfile = cmsCreateGrayProfile(cmsD50_xyY(), tone);
    cmsFreeToneCurve(tone);

    cmsSaveProfileToFile(hProfile, "gray_test.icc");
    cmsCloseProfile(hProfile);

Regards

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


> -----Original Message-----
> From: flap <fb...@oh...>
> Sent: Friday, December 29, 2023 2:21 PM
> To: lcm...@li...
> Subject: Re: [Lcms-user] How does a transformation work
> 
> Am Freitag, 29. Dezember 2023, 14:01:40 CET schrieb
> mar...@li...:
> > Hi,
> >
> > From your explanation, it seems to me that the transformation you want
> > has
> nothing to do with color management. You
> > know nothing about the L* of your grayscale and need only some
> > scaling. I
> would rather use simple math in this case:
> >
> > Gray_out = (Gray_in * 40) /51 + 40;
> >
> > You could just use a for() loop. This is going to be faster that using
> > any
> color management routines.
> 
> Hmm. It just was a test to understand how it (may) works.
> The profile I create is used in the muPDF library to create a greyscale out from
> a PDF document. I would expect, any kind of PDF could be rasterized into a
> greyscale raster this way.
> 
> Cheers,
> Jürgen
> 
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] How does a transformation work

[flap <fb...@oh...>]

Am Freitag, 29. Dezember 2023, 14:01:40 CET schrieb mar...@li...:
> Hi,
> 
> From your explanation, it seems to me that the transformation you want has 
nothing to do with color management. You
> know nothing about the L* of your grayscale and need only some scaling. I 
would rather use simple math in this case:
> 
> Gray_out = (Gray_in * 40) /51 + 40;
> 
> You could just use a for() loop. This is going to be faster that using any 
color management routines.

Hmm. It just was a test to understand how it (may) works.
The profile I create is used in the muPDF library to create a greyscale out 
from a PDF document. I would expect, any kind of PDF could be rasterized into 
a greyscale raster this way.

Cheers,
Jürgen

[Lcms-user] How does a transformation work

[flap <fb...@oh...>]

Hi list,

what I want: an 8 bit grey-scale output for my printer, where the input dot 
values (0 … 255) are scaled and limited to values of 40 … 240 (…just an 
example).

So I created a simple test input data (256 elements of unsigned char) with a 
linear ramp from 0 (at index 0) … 255 (at index 255).

And I created an array with 4096 short entries beginning with 40 (* 256 for 
unsigned short) and ramp up linear to 240 (* 256 for unsigned short) and feed 
it into cmsBuildTabulatedToneCurve16() and cmsCreateGrayProfile() with 
cmsD50_xyY() as its whitepoint (for the output profile).

For the input profile I used cmsBuildGamma() with a value of 1.0 and 
cmsCreateGrayProfile() with cmsD50_xyY().

After creating the transformation with cmsCreateTransform() with input/output 
types both TYPE_GRAY_8 and an intent of INTENT_PERCEPTUAL and applying this 
transformation with cmsDoTransformLineStride () to my simple input data, the 
output result is still almost linear from 0 to 255 and not limited to 40 … 
240.

So, I think I'm using the tone curves in a wrong way. But where is my mistake?

Cheers,
Jürgen

Re: [Lcms-user] cmsCreateTransform(): Unclear error message

[flap <fb...@oh...>]

Hi Marti,

Myself wrote:
> […]
> 
> I will try with valgrind.

Result: classic "use-after-free" error... m(

Thank you for pointing me to a memory corruption tip.

Cheers,
Jürgen

Re: [Lcms-user] cmsCreateTransform(): Unclear error message

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

Hi Jürgen,

> It only happens (e.g. the error message) in my final application. The same
> piece of code works in my test program (which does at most the same, same
> PNG file, same output definition).

This is memory corruption. Maybe you have closed the input or output profiles before calling cmsCreateTransform?

 The snipped you send is correct, used in many different places with no problems. Could you run your program under a memory checker, valgrind or visual studio sanitizer, for example?


Upgrading to 2.16 would be also a good idea, but I doubt using an old version is the root cause of this issue.

Regards

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


> -----Original Message-----
> From: flap <fb...@oh...>
> Sent: Thursday, December 21, 2023 6:51 PM
> To: lcm...@li...
> Subject: [Lcms-user] cmsCreateTransform(): Unclear error message
> 
> Hello list,
> 
> I have the following lines in my code:
> 
> […]
> 	assert(cmsGetColorSpace(info->incms) == cmsSigRgbData);
> 	assert(cmsGetColorSpace(info->outcms) == cmsSigGrayData);
> 
> 	cmsHTRANSFORM trans = cmsCreateTransform(info->incms,
> 			TYPE_RGB_8, /* from 24 bit RGB raster */
> 			info->outcms,
> 			TYPE_GRAY_8, /* into an 8 bit grey-scale raster */
> 			INTENT_PERCEPTUAL,
> 			0); /* no further flags for now */
> 	if (trans == NULL)
> 		return -EINVAL;
> […]
> 
> The catched error message when calling cmsCreateTransform() is code 13 ('not
> suitable') and 'Couldn't link the profiles'. What does it mean?
> 
> It only happens (e.g. the error message) in my final application. The same
> piece of code works in my test program (which does at most the same, same
> PNG file, same output definition).
> 
> I'm now confused what the difference can be to make the call fail.
> 
> Background: The "info->incms" comes from an embedded ICC profile in the
> PNG file and the "info->outcms" is a virtual profile generated with
> cmsCreateGrayProfileTHR(). On my system liblcms2.so.2 -> liblcms2.so.2.0.12
> is in use.
> 
> Cheers,
> Jürgen
> 
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] cmsCreateTransform(): Unclear error message

[flap <fb...@oh...>]

Hi Marti,

mar...@li... wrote:
> > It only happens (e.g. the error message) in my final application. The same
> > piece of code works in my test program (which does at most the same, same
> > PNG file, same output definition).
> 
> This is memory corruption. Maybe you have closed the input or output
> profiles before calling cmsCreateTransform?

No, both profiles are still open.

> The snipped you send is correct, used in many different places with no
> problems. Could you run your program under a memory checker, valgrind or
> visual studio sanitizer, for example?

My programs run with ASAN enabled. Most of the time it triggers in a reliable 
manner if the memory gets corrupted. Here not - yet.

I will try with valgrind.

Thanks,
Jürgen

[Lcms-user] cmsCreateTransform(): Unclear error message

[flap <fb...@oh...>]

Hello list,

I have the following lines in my code:

[…]
	assert(cmsGetColorSpace(info->incms) == cmsSigRgbData);
	assert(cmsGetColorSpace(info->outcms) == cmsSigGrayData);

	cmsHTRANSFORM trans = cmsCreateTransform(info->incms,
			TYPE_RGB_8, /* from 24 bit RGB raster */
			info->outcms,
			TYPE_GRAY_8, /* into an 8 bit grey-scale raster */
			INTENT_PERCEPTUAL,
			0); /* no further flags for now */
	if (trans == NULL)
		return -EINVAL;
[…]

The catched error message when calling cmsCreateTransform() is code 13 ('not 
suitable') and 'Couldn't link the profiles'. What does it mean?

It only happens (e.g. the error message) in my final application. The same 
piece of code works in my test program (which does at most the same, same PNG 
file, same output definition).

I'm now confused what the difference can be to make the call fail.

Background: The "info->incms" comes from an embedded ICC profile in the PNG 
file and the "info->outcms" is a virtual profile generated with 
cmsCreateGrayProfileTHR(). On my system liblcms2.so.2 -> liblcms2.so.2.0.12 is 
in use.

Cheers,
Jürgen

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

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

Little CMS 2.16 released


I am glad to the announce the release 2.16 of the LittleCMS open-source
color engine. 

lcms2-2.16 is a featured release. 

 

Changes:

*	New: import .CUBE files as RGB device links
*	New: Read/Write MHC2 tags for Windows GPU access
*	New: Support for UTF8 on multi-localized Unicode functions
*	New: Support for OkLab color space, built-in and formatter.
*	Improved: floating point transforms float -> integers are now
honored as float
*	Improved: MSYS2, mingw is now supported
*	Improved: preferred CMM, platform and creator now survive profile
edition.
*	Fixed: tificc now can deal with Lab TIFF
*	Fixed: code can now be compiled by a C++17 compiler, "register"
keywork use is detected at compile time.
*	Fixed: Reverted PostScript creation that corrupted some
interpreters.
*	Bug fixing & security enhancements

 

Little CMS intends to be an open source small-footprint color management
engine, with special focus on accuracy and performance. It uses the
International Color Consortium standard (ICC), which is the modern standard
when regarding to color management. The ICC specification is widely used and
is referred to in many International and other de-facto standards. It was
approved as an International Standard, ISO 15076-1, in 2005. 

 

Main site: 
http://www.littlecms.com 

 

Downloads: 
http://www.littlecms.com/download.html

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

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

 

 

Best regards, 

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

 

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

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

Hi,

 

It's time to make a new release. I try to alternate stabilization and new
features, and this time it's new features.

 

The first release candidate is available here:

 

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

 

 

Changes

*	New: import .CUBE files as RGB devicelinks
*	New: Read/Write MHC2 tags for Windows GPU access
*	New: Support for UTF8 on multilocalized unicode functions
*	New: Support for OkLab color space, built-in and formatter.
*	Improved: floating point transforms float -> integers are now
honored as float
*	Improved: MSYS2, mingw is now supported
*	Improved: preferred CMM, platform and creator now survive profile
edition.
*	Fixed: tificc now can deal with Lab TIFF
*	Fixed: code can now be compiled by a C++17 compiler, "register"
keywork use detected at compile time.
*	Fixed: Reverted PostScript creation that corrupted some
interpreters.
*	Bug fixing & security enhancements

 

Feel free to test it on all your products, tentative release date for final
lcms2-2.16 is end of Nov-2023 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] Configuration of the bounded/unbounded mode

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

Hello Sergey,

> The actual data of the image(byte, short, int, float, double)->float->short->start
> lcms
> internal->float->apply color transform in floats->end lcms
> internal->float->internals->short->float->the data of the
> image(byte, short, int, float, double). So at the end we have a "good" precision
> of the result especially if the image stores the color component in 17+ bits.

I don't know the internal architecture of OpenJDK, so maybe this is not feasible, but it seems to me the way you are doing the conversions is a serious throughput killer.  Lcms goes in a lot of trouble to optimize color transforms to make them as fast as possible whilst keeping the maximum precision. So, if you are going to convert a bitmap of 8 bits to another bitmap of 8 bits, your best option is to tell lcms to use 8 bits on input and output. The math precision and throughput performance you will obtain is actually better than going to float and then back to 8 bits, because lcms use tricks on rounding and fixed-point interpolation to go fast and accurate. Ditto for 16 bits, float, double, half...

Floating point transforms should be only used when your data is already in floating point, or in the case you want to convert to floating point. But that should be transparent to you, you should only tell the engine how your data is organized and let it to pick the better way to do the conversion. If you always convert to float assuming this is going to increase precision you are obtaining the inverse effect: sometimes less precision and definitively slower throughput. But again, I don't know OpenJDK architecture, so maybe the float step is unavoidable because other components.

Best regards

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




> -----Original Message-----
> From: Sergey Bylokhov <byl...@am...>
> Sent: Monday, August 14, 2023 10:18 PM
> To: Philip Race <phi...@or...>; mar...@li...; lcms-
> us...@li...
> Subject: Re: [Lcms-user] Configuration of the bounded/unbounded mode
> 
> On 8/13/23 15:07, Philip Race wrote:
> > Sergey,
> >
> > Why do you want to do this ? I'm not sure I see the value in it.
> >
> > Although JDK does support float for images, none of the standard image
> > formats use floats.
> 
> Unfortunately not, even though most standard images use bytes and ints to
> convert color profiles and access pixels in images, we use floats. So the
> common pattern we have is:
> The actual data of the image(byte, short, int, float, double)->float->short->start
> lcms
> internal->float->apply color transform in floats->end lcms
> internal->float->internals->short->float->the data of the
> image(byte, short, int, float, double). So at the end we have a "good" precision
> of the result especially if the image stores the color component in 17+ bits.
> 
> An examples of such conversion:
> 1.
> https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f
> 9bcdd/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.j
> ava#L230
> 2.
> https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f
> 9bcdd/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L8
> 09
> 3. Well we have a public API for such float based conversion -
> to/From/RGB/CIEXYZ:
> https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f
> 9bcdd/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L20
> 2
> 
> 
> But there are a few things I would like to check before starting to work on the
> OpenJDK side.
> 1. The slow performance of the float based calculations, described here:
> https://github.com/mm2/Little-CMS/issues/356 But I think elimination of an
> additional conversion should compensate that.
> 2. Compatibility related to the out-gamut values discussed in this thread. I
> would like to understand how to implement clip properly. Note that our
> current implementation do not clip out-of-gamtut values but blindly cast to
> short and get some "random" value at the end.
> 
> --
> Best regards, Sergey.

Re: [Lcms-user] Configuration of the bounded/unbounded mode

[Sergey B. <byl...@am...>]

On 8/13/23 15:07, Philip Race wrote:
> Sergey,
> 
> Why do you want to do this ? I'm not sure I see the value in it.
> 
> Although JDK does support float for images, none of the standard image
> formats use floats.

Unfortunately not, even though most standard images use bytes and ints to convert color profiles and 
access pixels in images, we use floats. So the common pattern we have is:
The actual data of the image(byte, short, int, float, double)->float->short->start lcms 
internal->float->apply color transform in floats->end lcms internals->short->float->the data of the 
image(byte, short, int, float, double). So at the end we have a "good" precision of the result 
especially if the image stores the color component in 17+ bits.

An examples of such conversion:
1. 
https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L230
2. 
https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L809
3. Well we have a public API for such float based conversion - to/From/RGB/CIEXYZ: 
https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L202


But there are a few things I would like to check before starting to work on the OpenJDK side.
1. The slow performance of the float based calculations, described here: 
https://github.com/mm2/Little-CMS/issues/356 But I think elimination of an additional conversion 
should compensate that.
2. Compatibility related to the out-gamut values discussed in this thread. I would like to 
understand how to implement clip properly. Note that our current implementation do not clip 
out-of-gamtut values but blindly cast to short and get some "random" value at the end.

-- 
Best regards, Sergey.

Re: [Lcms-user] Configuration of the bounded/unbounded mode

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

Sergey,

Why do you want to do this ? I'm not sure I see the value in it.

Although JDK does support float for images, none of the standard image 
formats use floats.
So I'm not sure how well this change would be tested nor where we'd see 
any benefit from it
so who is asking for this ?

-phil.

On 8/13/23 2:36 AM, mar...@li... wrote:
> Hi,
>
> Keep in mind the CMM internally operates always in unbounded mode and clips
> values at final stage if you use anything but floating point. Also, not all
> profiles allow unbounded mode. Doing the change you purpose would have a
> severe impact on applications not expecting values negative or over 1.0.
> By using shorts, you are limiting precision to 16 bits, if you use floats,
> you get more accuracy. Also note the encoding range changes, 0.1 for RGB,
> 0.100 for CMYK and for Lab it comes already decoded.
> Unbounded mode works in both directions, if you feed the transform with a
> value bigger then 1.0 and the profile supports it, the obtained XYZ would be
> an out-of-gamut extrapolation.
>
> The flag cmsFLAGS_NONEGATIVES was introduced to prevent only negative values
> because security issues, does not work for values bigger than 1. In any
> case, no matter what you do, the result would be wrong because this is an
> out of gamut value. Clipping is an option, just the simplest gamut mapping
> you could do.
>
>> 3. What about the use case when the user splits the "big" transform into a
>> few small intermediate transformations, is it possible to enable
> "unbounded"
>> mode for all transformations except for the output of the latest
> transform?
>
> Sure. Just ad a couple of "if >= 0 &&  <= 1.0" at the very end of the
> pipeline.
>
> Regards
>
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
>
>
>
>> -----Original Message-----
>> From: Sergey Bylokhov via Lcms-user <lcm...@li...>
>> Sent: Sunday, August 13, 2023 1:48 AM
>> To: lcm...@li...
>> Subject: [Lcms-user] Configuration of the bounded/unbounded mode
>>
>> Hello, Colors Experts!
>>
>> I am working on the OpenJDK project and have a couple of questions about
>> the LittleCMS library.
>>
>> The OpenJDK uses the LittleCMS for color conversion for a long time. And
> one
>> of the use cases is getting the pixel data from the user in float format.
>> Unfortunately before passing this float data to the LittleCMS the OpenJDK
>> converts them to shorts(16 bit) and after color transformation converts
> the
>> shorts to floats back and returns that floats to the user.
>>
>> The current implementation was done for LittleCMS 1 and was not updated
> for
>> version 2. I have read this[1] document about the "Floating Point Encoding
>> Range" added to the spec in 2006 and how it is implemented in the
> LittleCMS
>> library and would like to use this functionality in OpenJDK.
>>
>> The change in OpenJDK should be straightforward, delete the intermediate
>> conversion from floats to shorts and back and pass the floats directly to
> the
>> LittleCMS library. But this is a moment I would like to clarify some
> possible
>> impacts on the compatibility with the old behavior.
>>
>> 1. It is a good thing to do all intermediate computation in the unbounded
>> mode during color transformation, but how the out-of-gamut values are
>> handled for input and output data? That was not a problem for short but
>> could be a  problem for floats, for example, what will happen if 2.0f is
> passed
>> as a color value for the sRGB format - will it be clipped? or error will
> occur? or
>> transformation will be applied as-is?
>>
>> 2. What about the output? There is a cmsFLAGS_NONEGATIVES flag to prevent
>> negative values but when and how that values will be clipped by the upper
>> bounds? There are no options to configure that and it seems some clipping
>> occurs here and there in the code based on some constants which are not
>> exposed as CMS API.
>>
>> 3. What about the use case when the user splits the "big" transform into a
>> few small intermediate transformations, is it possible to enable
> "unbounded"
>> mode for all transformations except for the output of the latest
> transform?
>> Thank you for any suggestions!
>>
>> [1] https://www.littlecms.com/CIC18_UnboundedCMM.pdf
>>
>> --
>> Best regards, Sergey.
>>
>>
>> _______________________________________________
>> 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] Configuration of the bounded/unbounded mode

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

Hi,

Keep in mind the CMM internally operates always in unbounded mode and clips
values at final stage if you use anything but floating point. Also, not all
profiles allow unbounded mode. Doing the change you purpose would have a
severe impact on applications not expecting values negative or over 1.0. 
By using shorts, you are limiting precision to 16 bits, if you use floats,
you get more accuracy. Also note the encoding range changes, 0.1 for RGB,
0.100 for CMYK and for Lab it comes already decoded.
Unbounded mode works in both directions, if you feed the transform with a
value bigger then 1.0 and the profile supports it, the obtained XYZ would be
an out-of-gamut extrapolation.

The flag cmsFLAGS_NONEGATIVES was introduced to prevent only negative values
because security issues, does not work for values bigger than 1. In any
case, no matter what you do, the result would be wrong because this is an
out of gamut value. Clipping is an option, just the simplest gamut mapping
you could do.

> 3. What about the use case when the user splits the "big" transform into a
> few small intermediate transformations, is it possible to enable
"unbounded"
> mode for all transformations except for the output of the latest
transform?

Sure. Just ad a couple of "if >= 0 &&  <= 1.0" at the very end of the
pipeline.

Regards

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



> -----Original Message-----
> From: Sergey Bylokhov via Lcms-user <lcm...@li...>
> Sent: Sunday, August 13, 2023 1:48 AM
> To: lcm...@li...
> Subject: [Lcms-user] Configuration of the bounded/unbounded mode
> 
> Hello, Colors Experts!
> 
> I am working on the OpenJDK project and have a couple of questions about
> the LittleCMS library.
> 
> The OpenJDK uses the LittleCMS for color conversion for a long time. And
one
> of the use cases is getting the pixel data from the user in float format.
> Unfortunately before passing this float data to the LittleCMS the OpenJDK
> converts them to shorts(16 bit) and after color transformation converts
the
> shorts to floats back and returns that floats to the user.
> 
> The current implementation was done for LittleCMS 1 and was not updated
for
> version 2. I have read this[1] document about the "Floating Point Encoding
> Range" added to the spec in 2006 and how it is implemented in the
LittleCMS
> library and would like to use this functionality in OpenJDK.
> 
> The change in OpenJDK should be straightforward, delete the intermediate
> conversion from floats to shorts and back and pass the floats directly to
the
> LittleCMS library. But this is a moment I would like to clarify some
possible
> impacts on the compatibility with the old behavior.
> 
> 1. It is a good thing to do all intermediate computation in the unbounded
> mode during color transformation, but how the out-of-gamut values are
> handled for input and output data? That was not a problem for short but
> could be a  problem for floats, for example, what will happen if 2.0f is
passed
> as a color value for the sRGB format - will it be clipped? or error will
occur? or
> transformation will be applied as-is?
> 
> 2. What about the output? There is a cmsFLAGS_NONEGATIVES flag to prevent
> negative values but when and how that values will be clipped by the upper
> bounds? There are no options to configure that and it seems some clipping
> occurs here and there in the code based on some constants which are not
> exposed as CMS API.
> 
> 3. What about the use case when the user splits the "big" transform into a
> few small intermediate transformations, is it possible to enable
"unbounded"
> mode for all transformations except for the output of the latest
transform?
> 
> Thank you for any suggestions!
> 
> [1] https://www.littlecms.com/CIC18_UnboundedCMM.pdf
> 
> --
> Best regards, Sergey.
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Configuration of the bounded/unbounded mode

[Sergey B. <byl...@am...>]

Hello, Colors Experts!

I am working on the OpenJDK project and have a couple of questions about the LittleCMS library.

The OpenJDK uses the LittleCMS for color conversion for a long time. And one of the use cases is 
getting the pixel data from the user in float format. Unfortunately before passing this float data 
to the LittleCMS the OpenJDK converts them to shorts(16 bit) and after color transformation converts 
the shorts to floats back and returns that floats to the user.

The current implementation was done for LittleCMS 1 and was not updated for version 2. I have read 
this[1] document about the "Floating Point Encoding Range" added to the spec in 2006 and how it is 
implemented in the LittleCMS library and would like to use this functionality in OpenJDK.

The change in OpenJDK should be straightforward, delete the intermediate conversion from floats to 
shorts and back and pass the floats directly to the LittleCMS library. But this is a moment I would 
like to clarify some possible impacts on the compatibility with the old behavior.

1. It is a good thing to do all intermediate computation in the unbounded mode during color 
transformation, but how the out-of-gamut values are handled for input and output data? That was not 
a problem for short but could be a  problem for floats, for example, what will happen if 2.0f is 
passed as a color value for the sRGB format - will it be clipped? or error will occur? or 
transformation will be applied as-is?

2. What about the output? There is a cmsFLAGS_NONEGATIVES flag to prevent negative values but when 
and how that values will be clipped by the upper bounds? There are no options to configure that and 
it seems some clipping occurs here and there in the code based on some constants which are not 
exposed as CMS API.

3. What about the use case when the user splits the "big" transform into a few small intermediate 
transformations, is it possible to enable "unbounded" mode for all transformations except for the 
output of the latest transform?

Thank you for any suggestions!

[1] https://www.littlecms.com/CIC18_UnboundedCMM.pdf

-- 
Best regards, Sergey.

Re: [Lcms-user] Handling channel extraction

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

Hi,

> One further question about your suggestion, if the images are higher bit
> depth than 8-bit should I use more than 256 points to create my tone curve,
> or will lcms2 smooth the shape of the curve well enough that 256 points is still
> adequate?

The CMM uses nodes by interpolation, so there is no need to use 256 points. You could any number. Since this takes few memory you could use up to 4096. Including more than 4096 points gives no further accuracy gain.
Please note the profiles always use precision higher than 8 bits, unless you use a very old flavor of v2 profiles.

Regards

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



> -----Original Message-----
> From: Adrian Knagg-Baugh <aje...@gm...>
> Sent: Thursday, August 10, 2023 7:23 PM
> To: mar...@li...
> Subject: Re: [Lcms-user] Handling channel extraction
> 
> Yes. The images in question are most often either 16-bit unsigned int or 32-bit
> float format (they're astronomical data). I'm content with the loss of channel
> interaction, and in many cases the RGB images start out being composited
> from mono images taken through filters anyway. There are a couple of reasons
> we do this in the program: one is to read partial areas of images which is used
> in parallelising stacking images together to improve SNR. In this case I don't
> think we care about the color profile, because it will invariably be linear
> anyway at that stage of acquisition, and the parts are immediately going to be
> averaged (sort of) and reassembled into an image with the same color profile.
> But also there is a function to split a 3-color image into separate single
> channel R, G and B images, perhaps the user only wants one channel or
> perhaps they want to process each one separately and then recombine them.
> So in that case I think I do need to assign a reasonable color profile to each
> split-out channel.
> 
> One further question about your suggestion, if the images are higher bit
> depth than 8-bit should I use more than 256 points to create my tone curve,
> or will lcms2 smooth the shape of the curve well enough that 256 points is still
> adequate?
> 
> Thanks,
> 
> Adrian.
> 
> On Thu, Aug 10, 2023 at 5:42 PM <mar...@li...> wrote:
> >
> > Hi,
> >
> > If I understand correctly, you want to split an image, say for example
> > a RGB TIFF file, in 3 TIFF gray files, one per channel. And then you
> > want to embed in each one of those TIFFs a gray profile derivate from
> > the RGB profile you found embedded in the original file. Is that?
> >
> > First, I should warn you that doing that you will lose information, as
> > all the inter-actions between channels are lost, so you will get how
> > the channel contributes to the image if converted to gray, but nothing
> > else. Having said so, you should not use the TRC tags, that is only an
> > implementation detail and you may find profiles that are not using
> > matrix-shaper. All profiles using AtoB tags are not going to work in this way.
> >
> > I would rather use this approach which seems more general to me:
> >
> > - Get the embedded profile from original image.
> > - Create a transform from this profile to the XYZ built-in. Use
> > perceptual or relative colorimetric intent + BPC.
> > - Feed this transform from channel values from 0 to 255 set other
> > channels to 0. Get the Y from resulting XYZ. You will end with an
> > array of 256 Y values that corresponds to the obtained Y when using
> > that value on that channel.
> > - With those 256 Y values, crate a tone curve and with the tone curve,
> > create a gray profile. Use D50 as white point. That would be the r
> > channel profile.
> > - Repeat for g and b. All those profiles would explain the
> > contribution of the channel to Y, which is the maximum you can do on gray
> images.
> >
> > Hope that helps
> > Regards
> >
> > Marti Maria
> > The LittleCMS Project
> > https://www.littlecms.com
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Adrian Knagg-Baugh <aje...@gm...>
> > > Sent: Thursday, August 10, 2023 5:52 PM
> > > To: lcm...@li...
> > > Subject: [Lcms-user] Handling channel extraction
> > >
> > > Hi,
> > > I'm trying to understand how to handle assignment of a color profile
> > > to a single channel extracted from a colour image that may have an
> > > arbitrary
> > RGB
> > > color profile (e.g. extracting the R channel).
> > >
> > > Would something like this work, assuming rgb_profile is the
> > > cmsHPROFILE associated with the full RGB image?
> > >
> > > cmsHPROFILE extracted_profile == NULL; if (cmsIsTag(rgb_profile,
> > > cmsSigRedTRCTag) && cmsIsTag(rgb_profile,
> > > cmsSigMediaWhitePoint)) {
> > >   cmsToneCurve tonecurve = cmsReadTag(rgb_profile, cmsSigRedTRCTag);
> > >   cmsCIExyY whitepoint = cmsReadTag(rgb_profle,
> cmsSigMediaWhitePoint);
> > >   extracted_profile = cmsCreateGrayProfile(whitepoint, tonecurve); }
> > >
> > > Thanks,
> > >
> > > Adrian.
> > >
> > >
> > > _______________________________________________
> > > Lcms-user mailing list
> > > Lcm...@li...
> > > https://lists.sourceforge.net/lists/listinfo/lcms-user
> >

Re: [Lcms-user] Handling channel extraction

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

Hi,

If I understand correctly, you want to split an image, say for example a RGB
TIFF file, in 3 TIFF gray files, one per channel. And then you want to embed
in each one of those TIFFs a gray profile derivate from the RGB profile you
found embedded in the original file. Is that?

First, I should warn you that doing that you will lose information, as all
the inter-actions between channels are lost, so you will get how the channel
contributes to the image if converted to gray, but nothing else. Having said
so, you should not use the TRC tags, that is only an implementation detail
and you may find profiles that are not using matrix-shaper. All profiles
using AtoB tags are not going to work in this way.

I would rather use this approach which seems more general to me:

- Get the embedded profile from original image.
- Create a transform from this profile to the XYZ built-in. Use perceptual
or relative colorimetric intent + BPC.
- Feed this transform from channel values from 0 to 255 set other channels
to 0. Get the Y from resulting XYZ. You will end with an array of 256 Y
values that corresponds to the obtained Y when using that value on that
channel.
- With those 256 Y values, crate a tone curve and with the tone curve,
create a gray profile. Use D50 as white point. That would be the r channel
profile.
- Repeat for g and b. All those profiles would explain the contribution of
the channel to Y, which is the maximum you can do on gray images.

Hope that helps
Regards

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




> -----Original Message-----
> From: Adrian Knagg-Baugh <aje...@gm...>
> Sent: Thursday, August 10, 2023 5:52 PM
> To: lcm...@li...
> Subject: [Lcms-user] Handling channel extraction
> 
> Hi,
> I'm trying to understand how to handle assignment of a color profile to a
> single channel extracted from a colour image that may have an arbitrary
RGB
> color profile (e.g. extracting the R channel).
> 
> Would something like this work, assuming rgb_profile is the cmsHPROFILE
> associated with the full RGB image?
> 
> cmsHPROFILE extracted_profile == NULL;
> if (cmsIsTag(rgb_profile, cmsSigRedTRCTag) && cmsIsTag(rgb_profile,
> cmsSigMediaWhitePoint)) {
>   cmsToneCurve tonecurve = cmsReadTag(rgb_profile, cmsSigRedTRCTag);
>   cmsCIExyY whitepoint = cmsReadTag(rgb_profle, cmsSigMediaWhitePoint);
>   extracted_profile = cmsCreateGrayProfile(whitepoint, tonecurve); }
> 
> Thanks,
> 
> Adrian.
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Handling channel extraction

[Adrian Knagg-B. <aje...@gm...>]

Hi,
I'm trying to understand how to handle assignment of a color profile
to a single channel extracted from a colour image that may have an
arbitrary RGB color profile (e.g. extracting the R channel).

Would something like this work, assuming rgb_profile is the
cmsHPROFILE associated with the full RGB image?

cmsHPROFILE extracted_profile == NULL;
if (cmsIsTag(rgb_profile, cmsSigRedTRCTag) && cmsIsTag(rgb_profile,
cmsSigMediaWhitePoint)) {
  cmsToneCurve tonecurve = cmsReadTag(rgb_profile, cmsSigRedTRCTag);
  cmsCIExyY whitepoint = cmsReadTag(rgb_profle, cmsSigMediaWhitePoint);
  extracted_profile = cmsCreateGrayProfile(whitepoint, tonecurve);
}

Thanks,

Adrian.