lcms-user — For users of the little cms library

Re: [Lcms-user] Named Color Profiles

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

<div dir='auto'><div>Hi,</div><div dir="auto"><br></div><div dir="auto">You can create named color profiles, either V2 or V4.</div><div dir="auto"><br></div><div dir="auto">To do so, you first allocate an empty profile with cmsCreateProfilePlaceholder and then add required tags with cmsWriteTag. Finally you need to save the profile cmsSaveProfileToFile.</div><div dir="auto"><br></div><div dir="auto">For named color database tag, you have cmsAllocNamedColorList family. I have used named color profile creation extensively and seems to work well.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Marti</div><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 8 Jan 2021 13:32, Jason Campbell &lt;cam...@gm...&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>
<p><span style="font-size:11pt">Is it possible to create a named color profile with LCMS or only to read it?&nbsp; I know some profile types can be created programmatically but it does not appear you can do so for NCP -- unless I missed something…</span></p>
</div>
</div>
</blockquote></div><br></div></div></div>

Re: [Lcms-user] Named Color Profiles

[Jason C. <cam...@gm...>]

Marti,

Thanks for the tips -- would you have any skeleton code showing the proper set of tags required in the proper sequence to make it work?


From: "mar...@li..." <mar...@li...>
Date: Sunday, January 17, 2021 at 1:58 PM
To: Jason Campbell <cam...@gm...>
Cc: "lcm...@li..." <lcm...@li...>
Subject: Re: [Lcms-user] Named Color Profiles

Hi,

You can create named color profiles, either V2 or V4.

To do so, you first allocate an empty profile with cmsCreateProfilePlaceholder and then add required tags with cmsWriteTag. Finally you need to save the profile cmsSaveProfileToFile.

For named color database tag, you have cmsAllocNamedColorList family. I have used named color profile creation extensively and seems to work well.

Regards
Marti

On 8 Jan 2021 13:32, Jason Campbell <cam...@gm...> wrote:

Is it possible to create a named color profile with LCMS or only to read it?  I know some profile types can be created programmatically but it does not appear you can do so for NCP -- unless I missed something…

Re: [Lcms-user] Named Color Profiles

[Richard H. <hug...@gm...>]

On Fri, 8 Jan 2021 at 12:33, Jason Campbell <cam...@gm...> wrote:
> Is it possible to create a named color profile with LCMS or only to read it?  I know some profile types can be created programmatically but it does not appear you can do so for NCP -- unless I missed something…

If you're on LInux you can do this:
https://github.com/hughsie/colord/blob/master/data/profiles/x11-colors.iccprofile.xml
and then use cd-create-profile --output=OUTPUT.icc INPUT.xml from
memory.

Richard.

[Lcms-user] Named Color Profiles

[Jason C. <cam...@gm...>]

Is it possible to create a named color profile with LCMS or only to read it?  I know some profile types can be created programmatically but it does not appear you can do so for NCP -- unless I missed something…

Re: [Lcms-user] [Release candidate]

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

Hi Marti,

 

I have built your version 12 RC1 code (without the fast float plug-in) into
my Photoshop plug-in products and it has tested well, proving quite capable
of doing all the transforms that we need.  Thanks for your ongoing work to
clean up the code and make the Little CMS implementation more robust - it's
literally been years since anyone's reported a color-management problem
against any of our products, with Little CMS doing the color work under the
covers.

 

FWIW because we compile with the C++ compiler and use -wAll plus the Code
Analyzer, I change a few lines of your code (mostly to add explicit casts),
and also we suppress several specific warning classes (/wd4061 /wd4711
/wd4774 /wd4820 /wd5045) in our version of the project. 

 

Examples of the above-mentioned suppressed warnings:

 

warning C4061: enumerator 'SBEGIN_DATA' in switch of enum 'SYMBOL' is not
explicitly handled by a case label

warning C4711: function 'unsigned short __cdecl _cmsFloat2Half(float)'
selected for automatic inline expansion

warning C4774: '_snprintf' : format string expected in argument 3 is not a
string literal 

warning C4820: '_cms_NAMEDCOLORLIST_struct': '2' bytes padding added after
data member '_cms_NAMEDCOLORLIST_struct::Suffix'

warning C5045: Compiler will insert Spectre mitigation for memory load if
/Qspectre switch specified

 

-Noel Carboni

ProDigital Software

[Lcms-user] W3C is organizing a workshop around Wide Color Gamut and HDR on the web

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

Hey everyone,

I just saw this: https://www.w3.org/Graphics/Color/Workshop/index.html

Basically, the W3C is organizing a virtual workshop around widge gamut
and HDR on the web, participation is free, but registration necessary,
and registrations won't start until the 15th of january.

We, the Krita team, intend to participate, and I figured that there
would be many more people with interest in this topic subscribed to
the LCMS mailinglist, so hence why I am sharing it with you all.

I hope this is of use to you,
-- 
Wolthera

[Lcms-user] [Release candidate]

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

Happy new year!

It is time to do a release in preparation to some big changes. This is release candidate 1 of lcms2-2.12 that hopefully will add stability. Most of the new development has been done in fast float plug-in, now we have a integrated build system (a command line option in configure script) and more kernels, RGB to anything, and Lab to anything. The path "Lab to RGB" in float is specially useful. This release also recovers PDF for documentation, but at a reduced size. Thankd to Thomas Weber from Debian to help with this issue.

Here you can find the pre-release

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

After this, I will get rid of autogenerated files in repository, as per https://github.com/mm2/Little-CMS/pull/230 <https://github.com/mm2/Little-CMS/pull/230> The idea is only official release will have those files and if anybody wants to use latest, will need to use autotools across the provided script.

Feel free to test it on all your products, tentative release date for final lcms2-2.12 is Jan-25-2021 Please contactme on any issue either on info { at } littecms.com <mailto:in...@li...> or across this list

Best regards
Marti Maria
The LittleCMS Project

Re: [Lcms-user] Gamut diagram

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

Hello,

This is indeed a very interesting topic. I have written some explanation and a sample program as a blog entry. 

You can reach it at:

http://littlecms.com/blog/2019/10/02/visualizing-gamut/ <http://littlecms.com/blog/2019/10/02/visualizing-gamut/>

Hope this helps
Regards
Marti.

> On 29 Aug 2020, at 18:12, Lukas Sommer <som...@gm...> wrote:
> 
> Hi Martí.
> 
> Thanks for the feedback!
> 
> If I understand correctly, then …
> 
> 1.) My first approach (relying on unbounded mode, and filtering our RGB colors who’s components are not between 0…1) is not reliably. It works with LittleCMS’ build-in sRGB profile, but con break on other, LUT-based profiles because they deliver always RGB values between 0…1.
> 
> 2.) The approach using a proofing transform is not reliably either, because its out-of-gamut detection will fail on LUT_based profiles.
> 
> Did I get understand you correctly there?
> 
> In the meantime, I've tried your suggestion with the GBD functions. This is my code:
> 
>     cmsContext ContextID = cmsCreateContext(NULL, NULL);
>     cmsHANDLE h_gamutBoundaryDescriptor = cmsGBDAlloc(ContextID);
>     qreal h;
>     qreal s;
>     qreal v;
>     constexpr qreal step = 1;
>     cmsCIELab lab; //     cmsCIELab lab; 
>     QColor color;
>     for (h = 0; h < 359; h += step) {
>         s = 255;
>         for (v = 1; v <= 254; v += step) {
>             lab = colorSpace->colorLab(QColor::fromHsv(h, s, v));
>             cmsGDBAddPoint(h_gamutBoundaryDescriptor, &lab);
>         }
>         v = 255;
>         for (s = 1; s <= 254; s += step) {
>             lab = colorSpace->colorLab(QColor::fromHsv(h, s, v));
>             cmsGDBAddPoint(h_gamutBoundaryDescriptor, &lab);
>         }
>     }
>     cmsGDBCompute(
>         h_gamutBoundaryDescriptor,
>         0 // As of LittleCMS documentation: dwFlags: reserved (unused). Set it to 0
>     );
> 
> It uses (missuses?) HSV model to walk through the outer shell of the RGB gamut. HSV is converted to RGB by Qt’s build-in functions. Then, this is used by cmsGDBAddPoint. The result is however quite surprising: https://github.com/sommerluk/perceptualcolor/raw/1ca8c9ce1575e5c2715184f162b3021aebdbab63/other/gbd.png <https://github.com/sommerluk/perceptualcolor/raw/1ca8c9ce1575e5c2715184f162b3021aebdbab63/other/gbd.png> When I raise the precision (using 0.1 instead of 1.0 of distance), so adding more points, it still gets a similar result. And it gets really very slow. What am I doing wrong here?
> 
> Best regards
> 
> Lukas
> 
> PS: In the meantime, I've uploaded a small video showing the color selector in action (with the code that relies on the unbound LittleCMS mode): https://github.com/sommerluk/perceptualcolor/blob/31defb5aec031e9e84f4b89702788fc128750896/other/video.mkv?raw=true <https://github.com/sommerluk/perceptualcolor/blob/31defb5aec031e9e84f4b89702788fc128750896/other/video.mkv?raw=true>
> 
> 
> 
> 
> 
> Am Di., 18. Aug. 2020 um 08:20 Uhr schrieb Marti Maria <mar...@li... <mailto:mar...@li...>>:
> 
> Hello Lukas,
> 
>> In the last months, I've started to develop a colour picker widget based on the LCh model:
> 
> Great!
> 
> 
>> What is the best way to know the gamut of a given colour space? 
> 
> Gamut is a 3-D thing because we have 3 kind of color receptors in the eye, so the best way to represent a gamut is by using a 3D solid.
> 
>> What I try to get is this: 
> 
> This may work to some extent on very regular color spaces, but is not suitable for real device spaces. Slides on different L* may exhibit very different shape on certain device spaces, like prepress CMYK, for example.
> 
> In general, there is no way to know the gamut of a profile, and this is why there is a special tag to include the gamut. But nonetheless, you can use some tools to approximate the gamut. But please keep in mind the behaviour of the ICC profiles is to map colours inside gamut, no matter which intent. Absolute colorimetric often clips the colours, which at the end is a sort of gamut mapping. So, the only reliable way is to use the inverse direction, from device obtain the Lab and then build the gamut hull.
> 
> The code you sent, may work on matrix-shaper profiles, but will not work on CLUT. An option would be to use Jan Morovic’s segment maxima gamut hull descriptor (see cmsGBDxxx routines) You need to do a coarse sampling on the device space, RGB or CMYK,  get the Lab values, populate the GDB and after compute it you can check for individual points. In the cmsm.c source code, there is (commented out) a routine to dump the 3D solid as VRML. I guess converting that to openGL would be easy and this would be a very accurate representation of the gamut. Then you can slide this volume at any L* to show the shape.
> 
> Otherwise, INTENT_ABSOLUTE_COLORIMETRIC is ok, but in V4 ICC is same as INTENT_RELATIVE_COLORIMETRIC. If you want to distinguish between D50 and D65 white points you have to use INTENT_ABSOLUTE_COLORIMETRIC and adaptation state set to zero (unadapted). The effect of this is only to displace the gamut volume in chromaticity space, and only is useful the comparing spot colours side-by-side. If you are using this for normal usage, chromatic adaptation applies and it is better to use INTENT_RELATIVE_COLORIMETRIC or to set adaptation state to 1.0 (fully adapted) 
> 
> Regards
> Martí
> 
>  
> 
> 
> 
> 
>> On 16 Aug 2020, at 10:11, Lukas Sommer <som...@gm... <mailto:som...@gm...>> wrote:
>> 
>> Hello.
>> 
>> In the last months, I've started to develop a colour picker widget based on the LCh model: https://github.com/sommerluk/perceptualcolor <https://github.com/sommerluk/perceptualcolor>
>> 
>> It displays a given colour space gamut (sRGB or something other) within LCh diagrams, to provide a perceptually uniform colour picker with a nice UI. It's under MIT licence.
>> 
>> However, I'm new to colour management and don't have much experience with it. It would be great if I could get some help here.
>> 
>> 1.)
>> ==========
>> 
>> What is the best way to know the gamut of a given colour space? What I try to get is this: https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/expected.png <https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/expected.png>
>> 
>> The colour blob in the middle is a cut through the LCh model at a given lightness (the gamut is the sRGB gamut here, but it should work also with other gamuts). The code works like this:
>> – Create a buffer with a Lab image
>> – Transform it with LittleCMS like this:
>>     cmsHPROFILE labProfileHandle = cmsCreateLab4Profile(NULL);
>>     cmsHPROFILE rgbProfileHandle = cmsCreate_sRGBProfile();
>>     m_transformLabToRgbHandle = cmsCreateTransform(
>>         labProfileHandle,             // input profile handle
>>         TYPE_Lab_DBL,                 // input buffer format
>>         rgbProfileHandle,             // output profile handle
>>         TYPE_RGB_DBL,                 // output buffer format
>>         INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
>>         0                             // flags
>>     );
>> – Test for each pixel if one of R, G or B component is outside the range 0–1. If so, treat is as transparent. If not, paint it actually on the screen.
>> 
>> This approach works. However, there are also problems.
>> 
>> a) If I understand correctly the paper “Unbounded Color Engines” than LittleCMS might switch to bounded mode if the profile does not support unbounded mode. So comparing the output channels to the range 0–1 would be useless, and the approach might not be reliably.
>> 
>> b) It is slow, and does not provide proofing.
>> 
>> So I tried something different:
>>     cmsHTRANSFORM xform = cmsCreateProofingTransform(
>>         labProfileHandle,                           // Input profile handle
>>         TYPE_Lab_FLT,                               // InputFormat
>>         rgbProfileHandle,                           // Output
>>         TYPE_BGRA_8,                                // OutputFormat
>>         rgbProfileHandle,                           // Proofing
>>         INTENT_ABSOLUTE_COLORIMETRIC,               // Intent
>>         INTENT_ABSOLUTE_COLORIMETRIC,               // ProofingIntent
>>         (cmsFLAGS_SOFTPROOFING|cmsFLAGS_GAMUTCHECK) // dwFlags
>>     );
>> It relies directly on LittleCMS for the out-of-gamut detection. It seems that out-of-gamut colours are automatically transparent. The problem is that the out-of-gamut detection seems to be far less exact than the other method. Therefore, the gamut image has a very strange shape: https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/actual.png <https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/actual.png>
>> 
>> What would be the recommended approach here?
>> 
>> 2.)
>> ==========
>> I've used INTENT_ABSOLUTE_COLORIMETRIC as rendering intent. It this the correct choice for this use case?
>> 
>> 3.)
>> ==========
>> The build-in Lab profile has D50, but the build-in sRGB has D65. Does this matter? Or can I safely ignore that?
>> 
>> Best regards
>> 
>> Lukas Sommer
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li... <mailto:Lcm...@li...>
>> https://lists.sourceforge.net/lists/listinfo/lcms-user <https://lists.sourceforge.net/lists/listinfo/lcms-user>
> 

Re: [Lcms-user] Gamut diagram

[Lukas S. <som...@gm...>]

Hi Martí.

Thanks for the feedback!

If I understand correctly, then …

1.) My first approach (relying on unbounded mode, and filtering our RGB
colors who’s components are not between 0…1) is not reliably. It works with
LittleCMS’ build-in sRGB profile, but con break on other, LUT-based
profiles because they deliver always RGB values between 0…1.

2.) The approach using a proofing transform is not reliably either, because
its out-of-gamut detection will fail on LUT_based profiles.

Did I get understand you correctly there?

In the meantime, I've tried your suggestion with the GBD functions. This is
my code:

    cmsContext ContextID = cmsCreateContext(NULL, NULL);
    cmsHANDLE h_gamutBoundaryDescriptor = cmsGBDAlloc(ContextID);
    qreal h;
    qreal s;
    qreal v;
    constexpr qreal step = 1;
    cmsCIELab lab; //     cmsCIELab lab;
    QColor color;
    for (h = 0; h < 359; h += step) {
        s = 255;
        for (v = 1; v <= 254; v += step) {
            lab = colorSpace->colorLab(QColor::fromHsv(h, s, v));
            cmsGDBAddPoint(h_gamutBoundaryDescriptor, &lab);
        }
        v = 255;
        for (s = 1; s <= 254; s += step) {
            lab = colorSpace->colorLab(QColor::fromHsv(h, s, v));
            cmsGDBAddPoint(h_gamutBoundaryDescriptor, &lab);
        }
    }
    cmsGDBCompute(
        h_gamutBoundaryDescriptor,
        0 // As of LittleCMS documentation: dwFlags: reserved (unused). Set
it to 0
    );

It uses (missuses?) HSV model to walk through the outer shell of the RGB
gamut. HSV is converted to RGB by Qt’s build-in functions. Then, this is
used by cmsGDBAddPoint. The result is however quite surprising:
https://github.com/sommerluk/perceptualcolor/raw/1ca8c9ce1575e5c2715184f162b3021aebdbab63/other/gbd.png
When I raise the precision (using 0.1 instead of 1.0 of distance), so
adding more points, it still gets a similar result. And it gets really very
slow. What am I doing wrong here?

Best regards

Lukas

PS: In the meantime, I've uploaded a small video showing the color selector
in action (with the code that relies on the unbound LittleCMS mode):
https://github.com/sommerluk/perceptualcolor/blob/31defb5aec031e9e84f4b89702788fc128750896/other/video.mkv?raw=true





Am Di., 18. Aug. 2020 um 08:20 Uhr schrieb Marti Maria <
mar...@li...>:

>
> Hello Lukas,
>
> In the last months, I've started to develop a colour picker widget based
> on the LCh model:
>
>
> Great!
>
>
> What is the best way to know the gamut of a given colour space?
>
>
> Gamut is a 3-D thing because we have 3 kind of color receptors in the eye,
> so the best way to represent a gamut is by using a 3D solid.
>
> What I try to get is this:
>
>
> This may work to some extent on very regular color spaces, but is not
> suitable for real device spaces. Slides on different L* may exhibit very
> different shape on certain device spaces, like prepress CMYK, for example.
>
> In general, there is no way to know the gamut of a profile, and this is
> why there is a special tag to include the gamut. But nonetheless, you can
> use some tools to approximate the gamut. But please keep in mind the
> behaviour of the ICC profiles is to map colours inside gamut, no matter
> which intent. Absolute colorimetric often clips the colours, which at the
> end is a sort of gamut mapping. So, the only reliable way is to use the
> inverse direction, from device obtain the Lab and then build the gamut hull.
>
> The code you sent, may work on matrix-shaper profiles, but will not work
> on CLUT. An option would be to use Jan Morovic’s segment maxima gamut hull
> descriptor (see cmsGBDxxx routines) You need to do a coarse sampling on the
> device space, RGB or CMYK,  get the Lab values, populate the GDB and after
> compute it you can check for individual points. In the cmsm.c source code,
> there is (commented out) a routine to dump the 3D solid as VRML. I guess
> converting that to openGL would be easy and this would be a very accurate
> representation of the gamut. Then you can slide this volume at any L* to
> show the shape.
>
> Otherwise, INTENT_ABSOLUTE_COLORIMETRIC is ok, but in V4 ICC is same as
> INTENT_RELATIVE_COLORIMETRIC. If you want to distinguish between D50 and
> D65 white points you have to use INTENT_ABSOLUTE_COLORIMETRIC and
> adaptation state set to zero (unadapted). The effect of this is only to
> displace the gamut volume in chromaticity space, and only is useful the
> comparing spot colours side-by-side. If you are using this for normal
> usage, chromatic adaptation applies and it is better to use
> INTENT_RELATIVE_COLORIMETRIC or to set adaptation state to 1.0 (fully
> adapted)
>
> Regards
> Martí
>
>
>
>
>
>
> On 16 Aug 2020, at 10:11, Lukas Sommer <som...@gm...> wrote:
>
> Hello.
>
> In the last months, I've started to develop a colour picker widget based
> on the LCh model: https://github.com/sommerluk/perceptualcolor
>
> It displays a given colour space gamut (sRGB or something other) within
> LCh diagrams, to provide a perceptually uniform colour picker with a nice
> UI. It's under MIT licence.
>
> However, I'm new to colour management and don't have much experience with
> it. It would be great if I could get some help here.
>
> 1.)
> ==========
>
> What is the best way to know the gamut of a given colour space? What I try
> to get is this:
> https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/expected.png
>
> The colour blob in the middle is a cut through the LCh model at a given
> lightness (the gamut is the sRGB gamut here, but it should work also with
> other gamuts). The code works like this:
> – Create a buffer with a Lab image
> – Transform it with LittleCMS like this:
>     cmsHPROFILE labProfileHandle = cmsCreateLab4Profile(NULL);
>     cmsHPROFILE rgbProfileHandle = cmsCreate_sRGBProfile();
>     m_transformLabToRgbHandle = cmsCreateTransform(
>         labProfileHandle,             // input profile handle
>         TYPE_Lab_DBL,                 // input buffer format
>         rgbProfileHandle,             // output profile handle
>         TYPE_RGB_DBL,                 // output buffer format
>         INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
>         0                             // flags
>     );
> – Test for each pixel if one of R, G or B component is outside the range
> 0–1. If so, treat is as transparent. If not, paint it actually on the
> screen.
>
> This approach works. However, there are also problems.
>
> a) If I understand correctly the paper “Unbounded Color Engines” than
> LittleCMS might switch to bounded mode if the profile does not support
> unbounded mode. So comparing the output channels to the range 0–1 would be
> useless, and the approach might not be reliably.
>
> b) It is slow, and does not provide proofing.
>
> So I tried something different:
>     cmsHTRANSFORM xform = cmsCreateProofingTransform(
>         labProfileHandle,                           // Input profile handle
>         TYPE_Lab_FLT,                               // InputFormat
>         rgbProfileHandle,                           // Output
>         TYPE_BGRA_8,                                // OutputFormat
>         rgbProfileHandle,                           // Proofing
>         INTENT_ABSOLUTE_COLORIMETRIC,               // Intent
>         INTENT_ABSOLUTE_COLORIMETRIC,               // ProofingIntent
>         (cmsFLAGS_SOFTPROOFING|cmsFLAGS_GAMUTCHECK) // dwFlags
>     );
> It relies directly on LittleCMS for the out-of-gamut detection. It seems
> that out-of-gamut colours are automatically transparent. The problem is
> that the out-of-gamut detection seems to be far less exact than the other
> method. Therefore, the gamut image has a very strange shape:
> https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/actual.png
>
> What would be the recommended approach here?
>
> 2.)
> ==========
> I've used INTENT_ABSOLUTE_COLORIMETRIC as rendering intent. It this the
> correct choice for this use case?
>
> 3.)
> ==========
> The build-in Lab profile has D50, but the build-in sRGB has D65. Does this
> matter? Or can I safely ignore that?
>
> Best regards
>
> Lukas Sommer
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>
>

Re: [Lcms-user] Gamut diagram

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

Hello Lukas,

> In the last months, I've started to develop a colour picker widget based on the LCh model:

Great!


> What is the best way to know the gamut of a given colour space? 

Gamut is a 3-D thing because we have 3 kind of color receptors in the eye, so the best way to represent a gamut is by using a 3D solid.

> What I try to get is this: 

This may work to some extent on very regular color spaces, but is not suitable for real device spaces. Slides on different L* may exhibit very different shape on certain device spaces, like prepress CMYK, for example.

In general, there is no way to know the gamut of a profile, and this is why there is a special tag to include the gamut. But nonetheless, you can use some tools to approximate the gamut. But please keep in mind the behaviour of the ICC profiles is to map colours inside gamut, no matter which intent. Absolute colorimetric often clips the colours, which at the end is a sort of gamut mapping. So, the only reliable way is to use the inverse direction, from device obtain the Lab and then build the gamut hull.

The code you sent, may work on matrix-shaper profiles, but will not work on CLUT. An option would be to use Jan Morovic’s segment maxima gamut hull descriptor (see cmsGBDxxx routines) You need to do a coarse sampling on the device space, RGB or CMYK,  get the Lab values, populate the GDB and after compute it you can check for individual points. In the cmsm.c source code, there is (commented out) a routine to dump the 3D solid as VRML. I guess converting that to openGL would be easy and this would be a very accurate representation of the gamut. Then you can slide this volume at any L* to show the shape.

Otherwise, INTENT_ABSOLUTE_COLORIMETRIC is ok, but in V4 ICC is same as INTENT_RELATIVE_COLORIMETRIC. If you want to distinguish between D50 and D65 white points you have to use INTENT_ABSOLUTE_COLORIMETRIC and adaptation state set to zero (unadapted). The effect of this is only to displace the gamut volume in chromaticity space, and only is useful the comparing spot colours side-by-side. If you are using this for normal usage, chromatic adaptation applies and it is better to use INTENT_RELATIVE_COLORIMETRIC or to set adaptation state to 1.0 (fully adapted) 

Regards
Martí

 




> On 16 Aug 2020, at 10:11, Lukas Sommer <som...@gm...> wrote:
> 
> Hello.
> 
> In the last months, I've started to develop a colour picker widget based on the LCh model: https://github.com/sommerluk/perceptualcolor <https://github.com/sommerluk/perceptualcolor>
> 
> It displays a given colour space gamut (sRGB or something other) within LCh diagrams, to provide a perceptually uniform colour picker with a nice UI. It's under MIT licence.
> 
> However, I'm new to colour management and don't have much experience with it. It would be great if I could get some help here.
> 
> 1.)
> ==========
> 
> What is the best way to know the gamut of a given colour space? What I try to get is this: https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/expected.png <https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/expected.png>
> 
> The colour blob in the middle is a cut through the LCh model at a given lightness (the gamut is the sRGB gamut here, but it should work also with other gamuts). The code works like this:
> – Create a buffer with a Lab image
> – Transform it with LittleCMS like this:
>     cmsHPROFILE labProfileHandle = cmsCreateLab4Profile(NULL);
>     cmsHPROFILE rgbProfileHandle = cmsCreate_sRGBProfile();
>     m_transformLabToRgbHandle = cmsCreateTransform(
>         labProfileHandle,             // input profile handle
>         TYPE_Lab_DBL,                 // input buffer format
>         rgbProfileHandle,             // output profile handle
>         TYPE_RGB_DBL,                 // output buffer format
>         INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
>         0                             // flags
>     );
> – Test for each pixel if one of R, G or B component is outside the range 0–1. If so, treat is as transparent. If not, paint it actually on the screen.
> 
> This approach works. However, there are also problems.
> 
> a) If I understand correctly the paper “Unbounded Color Engines” than LittleCMS might switch to bounded mode if the profile does not support unbounded mode. So comparing the output channels to the range 0–1 would be useless, and the approach might not be reliably.
> 
> b) It is slow, and does not provide proofing.
> 
> So I tried something different:
>     cmsHTRANSFORM xform = cmsCreateProofingTransform(
>         labProfileHandle,                           // Input profile handle
>         TYPE_Lab_FLT,                               // InputFormat
>         rgbProfileHandle,                           // Output
>         TYPE_BGRA_8,                                // OutputFormat
>         rgbProfileHandle,                           // Proofing
>         INTENT_ABSOLUTE_COLORIMETRIC,               // Intent
>         INTENT_ABSOLUTE_COLORIMETRIC,               // ProofingIntent
>         (cmsFLAGS_SOFTPROOFING|cmsFLAGS_GAMUTCHECK) // dwFlags
>     );
> It relies directly on LittleCMS for the out-of-gamut detection. It seems that out-of-gamut colours are automatically transparent. The problem is that the out-of-gamut detection seems to be far less exact than the other method. Therefore, the gamut image has a very strange shape: https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/actual.png <https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/actual.png>
> 
> What would be the recommended approach here?
> 
> 2.)
> ==========
> I've used INTENT_ABSOLUTE_COLORIMETRIC as rendering intent. It this the correct choice for this use case?
> 
> 3.)
> ==========
> The build-in Lab profile has D50, but the build-in sRGB has D65. Does this matter? Or can I safely ignore that?
> 
> Best regards
> 
> Lukas Sommer
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Gamut diagram

[Lukas S. <som...@gm...>]

Hello.

In the last months, I've started to develop a colour picker widget based on
the LCh model: https://github.com/sommerluk/perceptualcolor

It displays a given colour space gamut (sRGB or something other) within LCh
diagrams, to provide a perceptually uniform colour picker with a nice UI.
It's under MIT licence.

However, I'm new to colour management and don't have much experience with
it. It would be great if I could get some help here.

1.)
==========

What is the best way to know the gamut of a given colour space? What I try
to get is this:
https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/expected.png

The colour blob in the middle is a cut through the LCh model at a given
lightness (the gamut is the sRGB gamut here, but it should work also with
other gamuts). The code works like this:
– Create a buffer with a Lab image
– Transform it with LittleCMS like this:
    cmsHPROFILE labProfileHandle = cmsCreateLab4Profile(NULL);
    cmsHPROFILE rgbProfileHandle = cmsCreate_sRGBProfile();
    m_transformLabToRgbHandle = cmsCreateTransform(
        labProfileHandle,             // input profile handle
        TYPE_Lab_DBL,                 // input buffer format
        rgbProfileHandle,             // output profile handle
        TYPE_RGB_DBL,                 // output buffer format
        INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
        0                             // flags
    );
– Test for each pixel if one of R, G or B component is outside the range
0–1. If so, treat is as transparent. If not, paint it actually on the
screen.

This approach works. However, there are also problems.

a) If I understand correctly the paper “Unbounded Color Engines” than
LittleCMS might switch to bounded mode if the profile does not support
unbounded mode. So comparing the output channels to the range 0–1 would be
useless, and the approach might not be reliably.

b) It is slow, and does not provide proofing.

So I tried something different:
    cmsHTRANSFORM xform = cmsCreateProofingTransform(
        labProfileHandle,                           // Input profile handle
        TYPE_Lab_FLT,                               // InputFormat
        rgbProfileHandle,                           // Output
        TYPE_BGRA_8,                                // OutputFormat
        rgbProfileHandle,                           // Proofing
        INTENT_ABSOLUTE_COLORIMETRIC,               // Intent
        INTENT_ABSOLUTE_COLORIMETRIC,               // ProofingIntent
        (cmsFLAGS_SOFTPROOFING|cmsFLAGS_GAMUTCHECK) // dwFlags
    );
It relies directly on LittleCMS for the out-of-gamut detection. It seems
that out-of-gamut colours are automatically transparent. The problem is
that the out-of-gamut detection seems to be far less exact than the other
method. Therefore, the gamut image has a very strange shape:
https://raw.githubusercontent.com/sommerluk/perceptualcolor/master/other/actual.png

What would be the recommended approach here?

2.)
==========
I've used INTENT_ABSOLUTE_COLORIMETRIC as rendering intent. It this the
correct choice for this use case?

3.)
==========
The build-in Lab profile has D50, but the build-in sRGB has D65. Does this
matter? Or can I safely ignore that?

Best regards

Lukas Sommer

Re: [Lcms-user] Version Number

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

Hi Marti,

 

I see you're doing maintenance on the LittleCMS trunk to get the version info straightened out.  Check also for these lines in Visual Studio .rc files:

FILEVERSION 2,10,0,0

PRODUCTVERSION 2,10,0,0

 

Thanks for all the updates!

 

-Noel

 

From: mar...@li... <mar...@li...> 
Sent: Thu, June 18, 2020 11:50 AM
To: js...@dl...
Cc: lcm...@li...
Subject: Re: [Lcms-user] Version Number

 

:( Too bad. 

 

Well, it is too late to fix. Anyway the API and ABI of 2.10 and 2.11 are identical, with no new features. So, maybe we can live with this as 2.11 in reality is a patched 2.10. Changes are only a couple of fixed bugs.

 

Sorry, but making  a new release now would be a pain.

Regards

Marti

 

On 18 Jun 2020 01:05, Jonathan Sachs <jsa...@gm... <mailto:jsa...@gm...> > wrote:

It looks like you forgot to change LCMS_VERSION from 2100 to 2110.

 

Jonathan Sachs

www.dl-c.com <http://www.dl-c.com> 

 

Re: [Lcms-user] Version Number

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

<div dir='auto'><div>:( Too bad.&nbsp;</div><div dir="auto"><br></div><div dir="auto">Well, it is too late to fix. Anyway the API and ABI of 2.10 and 2.11 are identical, with no new features. So, maybe we can live with this as 2.11 in reality is a patched 2.10. Changes are only a couple of fixed bugs.</div><div dir="auto"><br></div><div dir="auto">Sorry, but making&nbsp; a new release now would be a pain.</div><div dir="auto">Regards</div><div dir="auto">Marti</div><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 18 Jun 2020 01:05, Jonathan Sachs &lt;jsa...@gm...&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">It looks like you forgot to change LCMS_VERSION from 2100 to 2110.</div><div style="font-size:small"><br></div><div style="font-size:small">Jonathan Sachs</div><div style="font-size:small"><a href="http://www.dl-c.com">www.dl-c.com</a></div></div>
</blockquote></div><br></div></div></div>

[Lcms-user] Version Number

[Jonathan S. <jsa...@gm...>]

It looks like you forgot to change LCMS_VERSION from 2100 to 2110.

Jonathan Sachs
www.dl-c.com

Re: [Lcms-user] Changes to LittleCMS release archive files

[Bob F. <bfr...@si...>]

I see that if I navigate to a different directory on the SourceForge 
download site 
(https://sourceforge.net/projects/lcms/files/lcms/2.11/), I find files 
which use the more traditional naming.

There are two different download directories.

This is confusing!

Bob

On Tue, 16 Jun 2020, Bob Friesenhahn wrote:

> Marti,
>
> Did you really intend to change the release archive naming strategy which has 
> been used for a great many years, and also include a space in the file names?
>
> I definitely appreciate the new file sizes.
>
> The changing in the naming is sure to cause issues with existing scripts due 
> to using a different spelling of the package names, and including an embedded 
> space, which is inconvenient for Unix scripting since it typically breaks 
> tokens on spaces unless quoting is added.
>
> Bob
>

-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

[Lcms-user] Changes to LittleCMS release archive files

[Bob F. <bfr...@si...>]

Marti,

Did you really intend to change the release archive naming strategy 
which has been used for a great many years, and also include a space 
in the file names?

I definitely appreciate the new file sizes.

The changing in the naming is sure to cause issues with existing 
scripts due to using a different spelling of the package names, and 
including an embedded space, which is inconvenient for Unix scripting 
since it typically breaks tokens on spaces unless quoting is added.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

[Lcms-user] ANNOUNCE: LittleCMS 2.11 released (maintenance release)

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

Hello,

Due to some errors found in 2.10, I have packed this new released with  
all known blockers hopefully solved. Actually, a slight  
misinterpretation of a feature can have catastrophic consequences for  
other big packages that relies on this library, so I prefer to do a  
new release few days after 2.10 and keep a good mood.

As a plus, the documentation is now on ODT format, which reduces  
greatly the package size. The final tarball is reduced from roughly  
from 14 Mb to 6Mb. Not bad, as there is no need to make a separate  
package without documentation anymore. Never mind, I really didn't  
like the idea of code without documentation at all.

Fixed glitches:

- GIMP was affected by a copy-alpha bug on double formats that  
prevented some brushes to work.
- There was a race condition in  create context. Was there since 2.2.  
Very hard to reproduce.
- Fast float plug-in didn´t compile for linux because a bogus  
__cpuid() call for SSE2 detection.
- LUT16 on V2 Profiles matrix was wrong on multichannel.
- Create transform optimization may fail in some combinations.

Some of those bugs were serious enough to do a maintenance release, so  
here it is.

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

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

[Lcms-user] LCMS usage with high number of component profiles

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

Hi,

I'm playing with an idea for accelerating lcms when used with transforms 
involving 4 (or more) source components. 4 components is fairly common 
in printing (e.g. CMYK spaces), but higher is much rarer.

I'd be really interested in hearing from people that use lcms for 
transforms using larger numbers (e.g. 5,6,7,8) source components. If 
there is anyone out there doing stuff like this, please drop me a mail!

Thanks,

Robin

Re: [Lcms-user] ANNOUNCE: LittleCMS 2.10 released

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

Hi,

Due to some spurious return/linefeed characters in bad places, I have  
had to regenerate the 2.10 packages. The process has included a couple  
of commits done since initial 2.10 release.
None of them are important and none makes any functionality difference  
with previous 2.10.

Please ignore this change that only affects some packager scripts.

Thanks
Marti

Re: [Lcms-user] Lcms distribution package size

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

Hi Marti,

Not to go against the grain, but I think the practice of providing the
documentation along with the code is good.  It's all in one place and
everyone knows what goes together.  That being said, we pull from your git
repo so what's in your distribution package really matters not to us here.

I'm not saying this is the issue, but I do know that Acrobat offers
effective options for reducing the size impact of embedded images.

-Noel Carboni
 ProDigital Software

-----Original Message-----
From: mar...@li... <mar...@li...> 
Sent: Tue, June 2, 2020 12:51 PM
To: Bob Friesenhahn <bfr...@si...>
Cc: Lcms Liste <lcm...@li...>
Subject: Re: [Lcms-user] Lcms distribution package size


> Regardless out of the packages that GraphicsMagick directly uses, Lcms 
> has become the package with the largest source distribution file. 
> FreeType may be a good model to follow given that they distribute 
> three different archive files per release, one of which contains the 
> documentation.

Okey, after removing the documentation I have:

-rw-r--r-- 1 marti marti 5.0M Jun  2 16:55 lcms2-2.10_no_doc.tar.gz
-rw-r--r-- 1 marti marti  16M Jun  2 16:52 lcms2-2.10.tar.gz

Which seems reasonable. I have uploaded all packages on:

https://github.com/mm2/Little-CMS/releases/tag/lcms2.10
https://sourceforge.net/projects/lcms/files/lcms/2.10/

Thanks for pointing out the issue!
Best regards
Marti









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

Re: [Lcms-user] Lcms distribution package size

[Vincent T. <vin...@gm...>]

it's easy as you are using autotools :

https://www.gnu.org/software/automake/manual/automake.html#The-Types-of-Distributions

add dist-xz to AM_INIT_AUTOMAKE

Vincent Torri

On Tue, Jun 2, 2020 at 7:38 PM <mar...@li...> wrote:
>
>
>
> have you tried to also provide archives compressed with xz ?
>
> Sure it will be better, problem is everybody have zip and tar, and the release scripts are complex enough. I think just providing a stripped down tarball would suffice.
>
> Regards
> Marti.

Re: [Lcms-user] Lcms distribution package size

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

<div dir='auto'><div><br><div class="gmail_extra"><div class="gmail_quote"><br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">have you tried to also provide archives compressed with xz ?
<br><br>
</p>
</blockquote></div>Sure it will be better, problem is everybody have zip and tar, and the release scripts are complex enough. I think just providing a stripped down tarball would suffice.</div></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Regards</div><div class="gmail_extra" dir="auto">Marti.</div></div>

Re: [Lcms-user] Lcms distribution package size

[Vincent T. <vin...@gm...>]

have you tried to also provide archives compressed with xz ?

Vincent Torri

On Tue, Jun 2, 2020 at 6:51 PM <mar...@li...> wrote:
>
>
> > Regardless out of the packages that GraphicsMagick directly uses,
> > Lcms has become the package with the largest source distribution
> > file. FreeType may be a good model to follow given that they
> > distribute three different archive files per release, one of which
> > contains the documentation.
>
> Okey, after removing the documentation I have:
>
> -rw-r--r-- 1 marti marti 5.0M Jun  2 16:55 lcms2-2.10_no_doc.tar.gz
> -rw-r--r-- 1 marti marti  16M Jun  2 16:52 lcms2-2.10.tar.gz
>
> Which seems reasonable. I have uploaded all packages on:
>
> https://github.com/mm2/Little-CMS/releases/tag/lcms2.10
> https://sourceforge.net/projects/lcms/files/lcms/2.10/
>
> Thanks for pointing out the issue!
> Best regards
> Marti
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Lcms distribution package size

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

> Regardless out of the packages that GraphicsMagick directly uses,  
> Lcms has become the package with the largest source distribution  
> file. FreeType may be a good model to follow given that they  
> distribute three different archive files per release, one of which  
> contains the documentation.

Okey, after removing the documentation I have:

-rw-r--r-- 1 marti marti 5.0M Jun  2 16:55 lcms2-2.10_no_doc.tar.gz
-rw-r--r-- 1 marti marti  16M Jun  2 16:52 lcms2-2.10.tar.gz

Which seems reasonable. I have uploaded all packages on:

https://github.com/mm2/Little-CMS/releases/tag/lcms2.10
https://sourceforge.net/projects/lcms/files/lcms/2.10/

Thanks for pointing out the issue!
Best regards
Marti

Re: [Lcms-user] Lcms distribution package size

[Bob F. <bfr...@si...>]

On Tue, 2 Jun 2020, mar...@li... wrote:

> Hello Bob, 
> This is because the PDFs. I use ms word and print to PDF and the result is huge files.
> 
> I could make a tarball without the doc folders and this will squeeze the size in about 10 Mb less. 
> 
> Someting like lcms2-2.10_no_doc.tar.gz would work?

Certainly breaking out generated large files which are not needed to 
build or use the distribution into a different archive file would 
help.

I am not sure what the impact would be for Linux (or other) 
distributions such as if they bundle these PDF files into an 
installable documentation package.

> I guess most  people just want  the sources for automated builds.

In some cases.  But for many users of binary distributions they 
do not care about the sources at all because only a few people build 
the binary packages they install.  Users of source-based distributions 
would care about source.

Regardless out of the packages that GraphicsMagick directly uses, Lcms 
has become the package with the largest source distribution file. 
FreeType may be a good model to follow given that they distribute 
three different archive files per release, one of which contains the 
documentation.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt