lcms-user — For users of the little cms library

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

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

Little CMS 2.19 released


I am glad to the announce the release 2.19 of the Little CMS open-source
color engine. This is a featured release.

 

Changes:

- CMake build system. Thanks to Vlad Erium for the initial implementation
and kmilos for improvements. 

- Large files support to use profiles up to 4Gb

- Black point compensation works on multi-channel profiles

- Added more test platforms/architectures in GitHub tests, Cygwin and MSYS
are now fully checked.

- jpgicc banner is not shown on normal operation, only when help is
requested.

- Added a way to access internal transform pipelines. For read only.

- Add a way to retrieve the CMM signature

- Added extra checks on postscript undocumented functions

- Added guard on integer overflow when reading .cube files

- Added unneeded checks as a try to get rid of spam reports about
"vulnerabilities" that are not real.

- Utility program names generated by Visual Studio 2026 are now same as all
other platforms.

- Creating an output profile by cmsTransform2DeviceLink does not propagate
correctly the colorant table. Fixed.

- Added some profile class definitions from iccMAX

- Deprecated uint16 and uint32 types removed from tifdiff

- fixed generation of tifdiff on Cmake and meson

 

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. 

 

Reach it at:

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

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

 

 

The canonical page:

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

 

 

Best regards, 

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

[Lcms-user] Release candidate of lcms2-2.19

[<in...@li...>]

 

Hi,

 

Here you can download the release candidate 1 for lcms2‑2.19. I plan to publish the final release in four days if no issues are found.

 

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

 

Changelog:

CMake build system. Thanks to Vlad Erium for the initial implementation and kmilos for improvements. 

Large files support to use profiles up to 4Gb

Black point compensation works on multi-channel profiles

Added more test platforms/architectures in GitHub tests, Cygwin and MSYS are now fully checked.

jpgicc banner is not shown on normal operation, only when help is requested.

Added a way to access internal transform pipelines. For read only.

Add a way to retrieve the CMM signature

Added extra checks on postscript undocumented functions

Added guard on integer overflow when reading .cube files

Added unneeded checks as a try to get rid of spam reports about "vulnerabilities" that are not real.

Utility program names generated by Visual Studio 2026 are now same as all other platforms.

Creating an output profile by cmsTransform2DeviceLink does not propagate correctly the colorant table. Fixed.

Added some profile class definitions from iccMAX

Deprecated uint16 and uint32 types removed from tiffdiff

 

Best regards

 

Marti Maria

The LittleCMS Project

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

 

 

From: mar...@li... <mar...@li...> 
Sent: Friday, April 17, 2026 5:22 PM
To: lcm...@li...
Cc: in...@li...
Subject: CMake up and working

 

Dear users of the the little-CMS mailing list,

 

Just a quick update: after extensive testing, the CMake build system is now fully up and running. This is an important improvement, and I’ll be releasing version 2.19 to include it.

 

I’m also adding patches for a few very minor issues involving crafted (malicious) profiles attempting to trigger integer overflows. None of these pose any real danger, so there’s no need to worry at all. Since many spammers are trying to gain visibility by reporting such AI‑generated overflow warnings, I want to address this proactively to avoid unnecessary noise.

 

I will create a release candidate next week and add the documentation for the CMake build system. If you want to test it before that, please use the GitHub master branch. The set of test platforms has also been expanded to include Cygwin and MSYS.

 

https://github.com/mm2/Little-CMS

 

Thanks again for your unconditional support.

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

 

[Lcms-user] CMake up and working

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

Dear users of the the little-CMS mailing list,

 

Just a quick update: after extensive testing, the CMake build system is now fully up and running. This is an important improvement, and I’ll be releasing version 2.19 to include it.

 

I’m also adding patches for a few very minor issues involving crafted (malicious) profiles attempting to trigger integer overflows. None of these pose any real danger, so there’s no need to worry at all. Since many spammers are trying to gain visibility by reporting such AI‑generated overflow warnings, I want to address this proactively to avoid unnecessary noise.

 

I will create a release candidate next week and add the documentation for the CMake build system. If you want to test it before that, please use the GitHub master branch. The set of test platforms has also been expanded to include Cygwin and MSYS.

 

https://github.com/mm2/Little-CMS

 

Thanks again for your unconditional support.

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

 

Re: [Lcms-user] LittleCMS Insighter is now free for everyone

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

Hello,

> is a Linux release planned?

There is a Linux version, but I reserve that one for customers. The reason
is that installation is not straightforward and depends on the Linux
distribution, so I need to dedicate time to each individual setup.
This applies to all commercial utilities.

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


> -----Original Message-----
> From: Pekka Paalanen <pek...@ha...>
> Sent: Thursday, March 19, 2026 12:47 PM
> To: lcm...@li...
> Subject: Re: [Lcms-user] LittleCMS Insighter is now free for everyone
> 
> On Tue, 17 Mar 2026 14:01:24 +0100
> <mar...@li...> wrote:
> 
> > Download Insighter
> > https://www.littlecms.com/insighter
> 
> Hi Marti,
> 
> is a Linux release planned?
> 
> Or is there something else already for Linux that I missed?
> 
> 
> Thanks,
> pq

Re: [Lcms-user] LittleCMS Insighter is now free for everyone

[Pekka P. <pek...@ha...>]

On Tue, 17 Mar 2026 14:01:24 +0100
<mar...@li...> wrote:

> Download Insighter
> https://www.littlecms.com/insighter

Hi Marti,

is a Linux release planned?

Or is there something else already for Linux that I missed?


Thanks,
pq

[Lcms-user] LittleCMS Insighter is now free for everyone

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

Dear color enthusiasts,

 

I hope this message finds you well. 

 

I'm glad to announce we're making a new tool, LittleCMS Insighter completely
free.

 

For anyone working with ICC color profiles, whether you're a color
scientist, profile author, print engineer, or developer. I think you'll find
it genuinely useful.

 

What is Insighter?

 

Insighter is a deep-inspection tool for ICC color profiles. Rather than
simply using profiles, Insighter lets you look inside them. Load any ICC
profile and you get immediate access to:

 

*	The full ICC header : device class, color space, PCS, rendering
intent, creation date, profile ID checksum, and more
*	A tag browser with intelligent grouping and highlighting of related
tags
*	Pipeline visualization : AToB, BToA, DToB, and BToD tags are
rendered as interactive workflow diagrams you can click through stage by
stage
*	Tone curve graphs with zoom and pan, including decoded parametric
formulas
*	Matrix display in proper bracket notation, ideal for reading
chromatic adaptation and shaper-matrix values
*	An interactive CLUT slice viewer for multi-dimensional lookup tables
*	Chromaticity diagrams for primaries and white point, plotted against
the CIE 1931 spectral locus
*	Named color tables with live color swatches
*	A raw hex viewer for every tag

 

It runs on Windows 10/11 and macOS 11+, is built on LittleCMS 2 and Qt 6,
and supports ICC profiles of any version or device class. No registration,
no time limit, no cost.

 

 

A word about our commercial model

Insighter is free in its entirety. However, if you already use, or later
adopt, any of our other LittleCMS products (Translator, Translator MINI,
Abstractor, or Monitor ICC Tweaker), Insighter will automatically detect
that and unlock two additional features:

 

*	3D Gamut Hull Visualization - the profile's color gamut rendered as
an interactive convex hull in CIE Lab space, exportable as VRML
*	Soft Proofing panel - a live image preview simulating how your image
will look reproduced through the loaded profile, with gamut warning, black
ink simulation, and an eyedropper readout

 

This is our way of adding value to the broader LittleCMS ecosystem without
putting the core inspection tool behind a paywall. I believe the community
deserves free access to quality color tooling.

 

Download Insighter

https://www.littlecms.com/insighter

 

 

As always, we welcome your feedback. If you have questions or suggestions,
feel free to reach out.

Thank you for your continued support of LittleCMS.

 

Warm regards,

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

 

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

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

Little CMS 2.18 released


I am glad to the announce the release 2.18 of the Little CMS open-source
color engine. This is a maintenance release.

 

Changes:

*	Add an extra check for completeness only.
*	Fix a signed integer overflow which could trigger a FPE_INTOVF
*	Fix Microsoft'2 MHC2 private tag
*	Added projects for XCode 26 & Visual Studio 2026
*	Added documentation for PCS illuminants and chromatic adaptation
*	Check for a possible out-of-bounds in softproofing transforms when
using cmsCreateExtendedTransform
*	Fix for a out-of-bound read, issue #522
<https://github.com/mm2/Little-CMS/issues/522> 
*	Add an extra check for out-of-bounds read when misusing a support
function
*	avoid divide by zero, special case from spec. notes on CAM02
*	Fix CGATS parser bug when number has a "+" sign
*	Fix a typo when handling a special case for BPC
*	Fixed a loss of precision when Lab16 is used as input color space on
integer transforms
*	Fixes hypotetical corrupted pointer in non-happy path. Cannot happen
in real world
*	Fix a theoretical memory leak.
*	Add support of localized descriptions in v2 profiles for MacOS
*	Mark some tables as const
*	Make the param of cmsCreateLab4Profile() to refer to the media white
instead of the illuminant
*	fix a warning in unit tests
*	Remove redundant check. Fixes #497
<https://github.com/mm2/Little-CMS/issues/497> 
*	Update autotools
*	fix plugins soname + add oklab to transicc (experimental)
*	meson: ability to disable .so.version libraries
*	Fix black point detection when using darker colorant.
*	testcms2.c: Fix incorrect string comparisons
*	Fix CICp tag size.
*	Fix broken linkicc
*	meson: Bump minimum Meson version to 0.52 for visibility:hidden
*	meson: Disable unused fs import
*	Add a guard against a wrong use of flags
*	Fix for #469 <https://github.com/mm2/Little-CMS/issues/469>  heap
buffer overflow on convert_utf16_to_utf32()

 

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. 

 

Reach it at:

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

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

 

The canonical page:

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

 

 

Best regards, 

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

[Lcms-user] [Release candidate] Little CMS 2.18 release candidate 1

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

Hi,

 

It's time to make a new release. Stabilization in this case.

 

The first release candidate is available here:

 

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

 

Changes

 

*	Added projects for XCode 26 & Visual Studio 2026
*	Added documentation for PCS illuminants and chromatic adaptation
*	Check for a possible out-of-bounds in softproofing transforms when
using cmsCreateExtendedTransform
*	Fix for a out-of-bound read, issue #522
*	Add an extra check for out-of-bounds read when misusing a support
function
*	avoid divide by zero, special case from spec. notes on CAM02
*	Fix CGATS parser bug when number has a "+" sign
*	Fix a typo when handling a special case for BPC
*	Fixed a loss of precision when Lab16 is used as input color space on
integer transforms
*	Fixes hypotetical corrupted pointer in non-happy path. Cannot happen
in real world
*	Fix a theoretical memory leak.
*	Add support of localized descriptions in v2 profiles for MacOS
*	Mark some tables as const
*	Make the param of cmsCreateLab4Profile() to refer to the media white
instead of the illuminant
*	fix a warning in unit tests
*	Remove redundant check. Fixes #497
*	Update autotools
*	fix plugins soname + add oklab to transicc (experimental)
*	meson: ability to disable .so.version libraries
*	Fix black point detection when using darker colorant.
*	testcms2.c: Fix incorrect string comparisons
*	Fix CICp tag size.
*	Fix broken linkicc
*	meson: Bump minimum Meson version to 0.52 for visibility:hidden
*	meson: Disable unused fs import
*	Add a guard against a wrong use of flags
*	Fix for #469 heap buffer overflow on convert_utf16_to_utf32()

 

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

 

Best regards

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

Re: [Lcms-user] How to transform across profiles with different whitepoints?

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

Hi Lukas,

 

Human vision is capable to discount the chromaticity of media or the light that illuminates that media.

 

https://en.wikipedia.org/wiki/Chromatic_adaptation

 

The ICC way to do color management assumes you want this behavior by default. Light used to illuminate the media is always discounted. Chromaticity of the media is controlled by the rendering intent. “absolute colorimetric” means to NOT discount the media color. You normally should use “perceptual” or “relative colorimetric plus black point compensation” , as you normally want to model full adaptation. That is, consider unprinted paper is “white” no matter different papers may be of different color. 

 

LittleCMS can also deal with the light, by using cmsSetAdaptationState(), but this is an advanced feature that may confuse you. Use only if strictly needed.

 

So, to answer your question, you have just to use intent perceptual or relative colorimetric and white points are handled automatically by profiles.

 

Hope that helps

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

 

From: Lukas Sommer <som...@gm...> 
Sent: Monday, October 27, 2025 1:31 PM
To: Lcm...@li...
Subject: [Lcms-user] How to transform across profiles with different whitepoints?

 

Hello!

 

I've a question about correct treatment of profiles with different whitepoints.

 

Consider the following code:

 

///////////////////////////////////////////////////////////////////////////

            cmsHPROFILE srgbProfileHandle = cmsCreate_sRGBProfile(); // D65?

 

            cmsHPROFILE cielabProfileHandle = cmsCreateLab4Profile(
                // nullptr means: Default white point (D50)
                // TODO Does this make sense? sRGB, for example, has
                // D65 as whitepoint…

                nullptr);

 

            auto m_transform = cmsCreateTransform(
                cielabProfileHandle, // input profile handle
                TYPE_Lab_DBL, // input buffer format
                rgbProfileHandle, // output profile handle
                TYPE_RGB_DBL, // output buffer format
                INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
                cmsFLAGS_NOCACHE // flags

            );

///////////////////////////////////////////////////////////////////////////

 

Now, I suppose srgbProfileHandle is D65 and cielabProfileHandle is D50?

 

Is it allowed to create simply the transform like in the example, and to rely on LCMS to do the conversion? Or do I have to make a white point adaption before?

 

Best regards

 

Lukas

Re: [Lcms-user] How to transform across profiles with different whitepoints?

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

Thanks a lot for the explication!

Lukas Sommer


Am Mo., 27. Okt. 2025 um 13:00 Uhr schrieb <mar...@li...>:

> Hi Lukas,
>
>
>
> Human vision is capable to discount the chromaticity of media or the light
> that illuminates that media.
>
>
>
> https://en.wikipedia.org/wiki/Chromatic_adaptation
>
>
>
> The ICC way to do color management assumes you want this behavior by
> default. Light used to illuminate the media is always discounted.
> Chromaticity of the media is controlled by the rendering intent. “absolute
> colorimetric” means to NOT discount the media color. You normally should
> use “perceptual” or “relative colorimetric plus black point compensation” ,
> as you normally want to model full adaptation. That is, consider unprinted
> paper is “white” no matter different papers may be of different color.
>
>
>
> LittleCMS can also deal with the light, by using cmsSetAdaptationState(),
> but this is an advanced feature that may confuse you. Use only if strictly
> needed.
>
>
>
> So, to answer your question, you have just to use intent perceptual or
> relative colorimetric and white points are handled automatically by
> profiles.
>
>
>
> Hope that helps
>
>
>
> Marti Maria
>
> The LittleCMS Project
>
> https://www.littlecms.com
>
>
>
>
>
>
>
> *From:* Lukas Sommer <som...@gm...>
> *Sent:* Monday, October 27, 2025 1:31 PM
> *To:* Lcm...@li...
> *Subject:* [Lcms-user] How to transform across profiles with different
> whitepoints?
>
>
>
> Hello!
>
>
>
> I've a question about correct treatment of profiles with different
> whitepoints.
>
>
>
> Consider the following code:
>
>
>
> ///////////////////////////////////////////////////////////////////////////
>
>             cmsHPROFILE srgbProfileHandle = cmsCreate_sRGBProfile(); //
> D65?
>
>
>
>             cmsHPROFILE cielabProfileHandle = cmsCreateLab4Profile(
>                 // nullptr means: Default white point (D50)
>                 // TODO Does this make sense? sRGB, for example, has
>                 // D65 as whitepoint…
>
>                 nullptr);
>
>
>
>             auto m_transform = cmsCreateTransform(
>                 cielabProfileHandle, // input profile handle
>                 TYPE_Lab_DBL, // input buffer format
>                 rgbProfileHandle, // output profile handle
>                 TYPE_RGB_DBL, // output buffer format
>                 INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
>                 cmsFLAGS_NOCACHE // flags
>
>             );
>
> ///////////////////////////////////////////////////////////////////////////
>
>
>
> Now, I suppose srgbProfileHandle is D65 and cielabProfileHandle is D50?
>
>
>
> Is it allowed to create simply the transform like in the example, and to
> rely on LCMS to do the conversion? Or do I have to make a white point
> adaption before?
>
>
>
> Best regards
>
>
>
> Lukas
>

[Lcms-user] How to transform across profiles with different whitepoints?

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

Hello!

I've a question about correct treatment of profiles with different
whitepoints.

Consider the following code:

///////////////////////////////////////////////////////////////////////////
            cmsHPROFILE srgbProfileHandle = cmsCreate_sRGBProfile(); // D65?

            cmsHPROFILE cielabProfileHandle = cmsCreateLab4Profile(
                // nullptr means: Default white point (D50)
                // TODO Does this make sense? sRGB, for example, has
                // D65 as whitepoint…
                nullptr);

            auto m_transform = cmsCreateTransform(
                cielabProfileHandle, // input profile handle
                TYPE_Lab_DBL, // input buffer format
                rgbProfileHandle, // output profile handle
                TYPE_RGB_DBL, // output buffer format
                INTENT_ABSOLUTE_COLORIMETRIC, // rendering intent
                cmsFLAGS_NOCACHE // flags
            );
///////////////////////////////////////////////////////////////////////////

Now, I suppose srgbProfileHandle is D65 and cielabProfileHandle is D50?

Is it allowed to create simply the transform like in the example, and to
rely on LCMS to do the conversion? Or do I have to make a white point
adaption before?

Best regards

Lukas

Re: [Lcms-user] Question related to curve smoothing

[Pekka P. <pek...@ha...>]

On Fri, 9 May 2025 09:51:47 +0200
<mar...@li...> wrote:

> Regarding your question, a good test would be to chain two ICC profiles for
> real devices. Take LUT-based ones, which you can identify easily by looking
> at file size, big sizes mean they are using CLUT and are complex. Take a
> profile for a real camera and a profile for a real monitor and try the
> algorithm to model the color transform with those. If you try sRGB +
> AdobeRGB, you are just chaining two matrixes and you can't see the real
> power, although the algorithm works equally well.

Hi Marti,

so any combination of real camera and display CLUT profiles should be
able to hit most of the pitfalls? That sounds good! Now we just need to
find profiles we can store in the Weston project, so we can use them in
the automated test suite.

> Here is a description on how to implement it:
> 
> a) Use LittleCMS to create a color transform from source RGB to destination
> RGB. Use cmsFLAGS_NOOPTIMIZE to get maximum accuracy. With this you have a
> way to evaluate RGB->R'G'B'
> b) Compute the neutral curves. For example, on 256 values, for (i=0; i <
> 256; i++) R[i]=G[i]=B[i] = i; and then using a) obtain the R'G'B' of those
> 256 values. It is certainly possible that R' != G' != B'  if you use real
> devices.
> c) Smooth a little bit those curves, make sure those are monotonic. You can
> use any algorithm you wish. The important thing is to get rid of abrupt
> changes and make them monotonic to allow the inverting.
> d) Invert the curves. LittleCMS gives you a function to do that. You can use
> any other algorithm you wish.
> c) Build the LUT for GPU by sampling all RGB cube. You want to obtain the
> R'G'B' for all RGB to model the color transformation in just one 3D table.
> You could do this directly and it would work more or less, but what the
> paper says is that if you use those inverted curves to linearize the RGB
> values first, the cube interpolation is much more efficient and you could
> get more accurate results with less nodes.
> 
> Hope that makes sense to you

It does, thanks!
pq

Re: [Lcms-user] Question related to curve smoothing

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

Hello,

> that email seems to have reached no-one.

Too bad. I was not aware of any issues on the mailing list. Thanks for let
me know.  I will double-check to see if the problem comes from the list or
was just my mail client.

Regarding your question, a good test would be to chain two ICC profiles for
real devices. Take LUT-based ones, which you can identify easily by looking
at file size, big sizes mean they are using CLUT and are complex. Take a
profile for a real camera and a profile for a real monitor and try the
algorithm to model the color transform with those. If you try sRGB +
AdobeRGB, you are just chaining two matrixes and you can't see the real
power, although the algorithm works equally well.

Here is a description on how to implement it:

a) Use LittleCMS to create a color transform from source RGB to destination
RGB. Use cmsFLAGS_NOOPTIMIZE to get maximum accuracy. With this you have a
way to evaluate RGB->R'G'B'
b) Compute the neutral curves. For example, on 256 values, for (i=0; i <
256; i++) R[i]=G[i]=B[i] = i; and then using a) obtain the R'G'B' of those
256 values. It is certainly possible that R' != G' != B'  if you use real
devices.
c) Smooth a little bit those curves, make sure those are monotonic. You can
use any algorithm you wish. The important thing is to get rid of abrupt
changes and make them monotonic to allow the inverting.
d) Invert the curves. LittleCMS gives you a function to do that. You can use
any other algorithm you wish.
c) Build the LUT for GPU by sampling all RGB cube. You want to obtain the
R'G'B' for all RGB to model the color transformation in just one 3D table.
You could do this directly and it would work more or less, but what the
paper says is that if you use those inverted curves to linearize the RGB
values first, the cube interpolation is much more efficient and you could
get more accurate results with less nodes.

Hope that makes sense to you

All the best

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








> -----Original Message-----
> From: Pekka Paalanen <pek...@ha...>
> Sent: Thursday, May 8, 2025 12:07 PM
> To: mar...@li...
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] Question related to curve smoothing
> 
> On Tue, 6 May 2025 19:18:55 +0200
> <mar...@li...> wrote:
> 
> > Hello,
> > I answered that mail on 24/3, see the answer attached.
> 
> Hi Marti,
> 
> as you can see in
> https://sourceforge.net/p/lcms/mailman/lcms-user/thread/93d1cd5d-89f9-
> 406e-965f-3ca3349aba1a%40riseup.net/#msg59164589
> that email seems to have reached no-one.
> 
> Thanks for attaching it!
> 
> I was hoping for more insight with the specific use case, because I am
sure you
> have extensive experience in applying the "ASIC prelinearization"
algorithm.
> Currently we do not know of a good test case nor what a typical situation
> would even look like.
> 
> Can you recommend a test case that would pose as many problems as
> possible, but still be feasible to your taste for the prelinearization?
> Some specific ICC profile combination, maybe?
> 
> > shaper + 3D LUT is not supported by this function.
> 
> What do you mean? Why is cmsSmoothToneCurve() not applicable to the
> estimated shaper in
> https://www.littlecms.com/ASICprelinerization_CGIV08.pdf ?
> 
> 
> Thanks,
> pq
> 
> > -----Original Message-----
> > From: Pekka Paalanen <pek...@ha...>
> > Sent: Tuesday, May 6, 2025 9:40 AM
> > To: lcm...@li...
> > Subject: Re: [Lcms-user] Question related to curve smoothing
> >
> > On Mon, 24 Mar 2025 11:39:03 -0300
> > Leandro Ribeiro <lea...@ri...> wrote:
> >
> > > Hello,
> > >
> > > Based on [1], we've added the code to decompose a cmsHTRANSFORM
> into
> > > a shaper (3x1D LUT) + 3D LUT on Weston [2].
> > >
> > > We want to smooth the shaper with cmsSmoothToneCurve(), but we don't
> > > know exactly how to choose the lambda parameter. In [1] we have:
> > > "lambda is a parameter by which we can trade smoothness of z against
> > > fit to data y". But would there be any drawback in using lambda ==
> > > 0, i.e. allowing "full smoothness"?
> > >
> > > Any feedback from your experience with that would be appreciated.
> > >
> > > [1] https://www.littlecms.com/ASICprelinerization_CGIV08.pdf
> > > [2]
> > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1644
> > >

Re: [Lcms-user] Question related to curve smoothing

[Pekka P. <pek...@ha...>]

On Tue, 6 May 2025 19:18:55 +0200
<mar...@li...> wrote:

> Hello,
> I answered that mail on 24/3, see the answer attached.

Hi Marti,

as you can see in
https://sourceforge.net/p/lcms/mailman/lcms-user/thread/93d1cd5d-89f9-406e-965f-3ca3349aba1a%40riseup.net/#msg59164589
that email seems to have reached no-one.

Thanks for attaching it!

I was hoping for more insight with the specific use case, because I am
sure you have extensive experience in applying the "ASIC
prelinearization" algorithm. Currently we do not know of a good test
case nor what a typical situation would even look like.

Can you recommend a test case that would pose as many problems as
possible, but still be feasible to your taste for the prelinearization?
Some specific ICC profile combination, maybe?

> shaper + 3D LUT is not supported by this function.

What do you mean? Why is cmsSmoothToneCurve() not applicable to the
estimated shaper in https://www.littlecms.com/ASICprelinerization_CGIV08.pdf ?


Thanks,
pq

> -----Original Message-----
> From: Pekka Paalanen <pek...@ha...> 
> Sent: Tuesday, May 6, 2025 9:40 AM
> To: lcm...@li...
> Subject: Re: [Lcms-user] Question related to curve smoothing
> 
> On Mon, 24 Mar 2025 11:39:03 -0300
> Leandro Ribeiro <lea...@ri...> wrote:
> 
> > Hello,
> > 
> > Based on [1], we've added the code to decompose a cmsHTRANSFORM into a 
> > shaper (3x1D LUT) + 3D LUT on Weston [2].
> > 
> > We want to smooth the shaper with cmsSmoothToneCurve(), but we don't 
> > know exactly how to choose the lambda parameter. In [1] we have: 
> > "lambda is a parameter by which we can trade smoothness of z against 
> > fit to data y". But would there be any drawback in using lambda == 0, 
> > i.e. allowing "full smoothness"?
> > 
> > Any feedback from your experience with that would be appreciated.
> > 
> > [1] https://www.littlecms.com/ASICprelinerization_CGIV08.pdf
> > [2] 
> > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1644
> >   

Re: [Lcms-user] Question related to curve smoothing

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

Hello,
I answered that mail on 24/3, see the answer attached.

shaper + 3D LUT is not supported by this function.

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



-----Original Message-----
From: Pekka Paalanen <pek...@ha...> 
Sent: Tuesday, May 6, 2025 9:40 AM
To: lcm...@li...
Subject: Re: [Lcms-user] Question related to curve smoothing

On Mon, 24 Mar 2025 11:39:03 -0300
Leandro Ribeiro <lea...@ri...> wrote:

> Hello,
> 
> Based on [1], we've added the code to decompose a cmsHTRANSFORM into a 
> shaper (3x1D LUT) + 3D LUT on Weston [2].
> 
> We want to smooth the shaper with cmsSmoothToneCurve(), but we don't 
> know exactly how to choose the lambda parameter. In [1] we have: 
> "lambda is a parameter by which we can trade smoothness of z against 
> fit to data y". But would there be any drawback in using lambda == 0, 
> i.e. allowing "full smoothness"?
> 
> Any feedback from your experience with that would be appreciated.
> 
> [1] https://www.littlecms.com/ASICprelinerization_CGIV08.pdf
> [2] 
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1644
> 

Hi everyone,

we still don't know about this.

How do people choose the smoothing parameters for the shaper + 3D LUT case?


Thanks,
pq

Re: [Lcms-user] Question related to curve smoothing

[Pekka P. <pek...@ha...>]

On Mon, 24 Mar 2025 11:39:03 -0300
Leandro Ribeiro <lea...@ri...> wrote:

> Hello,
> 
> Based on [1], we've added the code to decompose a cmsHTRANSFORM into a
> shaper (3x1D LUT) + 3D LUT on Weston [2].
> 
> We want to smooth the shaper with cmsSmoothToneCurve(), but we don't know
> exactly how to choose the lambda parameter. In [1] we have: "lambda is a
> parameter by which we can trade smoothness of z against fit to data y". But
> would there be any drawback in using lambda == 0, i.e. allowing "full
> smoothness"?
> 
> Any feedback from your experience with that would be appreciated.
> 
> [1] https://www.littlecms.com/ASICprelinerization_CGIV08.pdf
> [2] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1644
> 

Hi everyone,

we still don't know about this.

How do people choose the smoothing parameters for the shaper + 3D LUT
case?


Thanks,
pq

Re: [Lcms-user] XYZ to Lab conversion issue

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

Hello Steve,

The easiest wat to deal with encodings is to let the engine to do the work
for you. 
If you use TYPE_Lab_DBL and TYPE_XYZ_DBL, you can provide arrays of doubles.

Example:

#include "lcms2.h"
int main()
{
    cmsHPROFILE hLab = cmsCreateLab4Profile(NULL);
    cmsHPROFILE hXYZ = cmsCreateXYZProfile();

    cmsHTRANSFORM xyz2lab = cmsCreateTransform(hXYZ, TYPE_XYZ_DBL, hLab,
TYPE_Lab_DBL, INTENT_RELATIVE_COLORIMETRIC, 0);
    cmsHTRANSFORM lab2xyz = cmsCreateTransform(hLab, TYPE_Lab_DBL, hXYZ,
TYPE_XYZ_DBL, INTENT_RELATIVE_COLORIMETRIC, 0);

    double XYZ[3] = { 0.06113, 0.0634, 0.05231 };

    double Lab[3];

    cmsDoTransform(xyz2lab, XYZ, Lab, 1);
    cmsDoTransform(lab2xyz, Lab, XYZ, 1);

    cmsCloseProfile(hLab);
    cmsCloseProfile(hXYZ);
    cmsDeleteTransform(xyz2lab);
    cmsDeleteTransform(lab2xyz);
}

If you want to deal with the encoding directly, it is the encoding described
in ICC spec 4.4 
in "6.3.4 Colour space encodings for the PCS".

Hope that helps
Best regards

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


> -----Original Message-----
> From: Steve Upton via Lcms-user <lcm...@li...>
> Sent: Sunday, April 27, 2025 12:14 AM
> To: lcm...@li...
> Subject: [Lcms-user] XYZ to Lab conversion issue
> 
> 
> when I call  cmsXYZ2Lab with the white point set to NULL and XYZ =
0.06113,
> 0.0634, 0.05231   I get the expected L* value of around 30.255 - no
problem
> 
> But when I set up a transform from the 'stock, D50' XYZ profile to the
stock
> Lab profile, I get the L* value around 40
> 
> I messed around with a ton of different methods of encoding the XYZ values
> and decoding the Lab values as well a different profile versions and get
the
> same wrong number (ish)
> 
> Somewhere along the way I realized the L* = 40 number, converted to XYZ
> basically doubles the original XYZ values. Sure enough, when I divide the
> original XYZ values by 2, they convert to the value I'm expecting - though
I
> think this is just a dawdle...
> 
> Anyway, what might I be doing wrong?
> 
> Also, can anyone point me in the direction of how encodings like
type_XYZ_16
> are performed? I've having trouble tracking it down.
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] XYZ to Lab conversion issue

[Steve U. <up...@ch...>]

when I call  cmsXYZ2Lab with the white point set to NULL and XYZ = 0.06113, 0.0634, 0.05231   I get the expected L* value of around 30.255 - no problem

But when I set up a transform from the 'stock, D50' XYZ profile to the stock Lab profile, I get the L* value around 40

I messed around with a ton of different methods of encoding the XYZ values and decoding the Lab values as well a different profile versions and get the same wrong number (ish)

Somewhere along the way I realized the L* = 40 number, converted to XYZ basically doubles the original XYZ values. Sure enough, when I divide the original XYZ values by 2, they convert to the value I'm expecting - though I think this is just a dawdle...

Anyway, what might I be doing wrong?

Also, can anyone point me in the direction of how encodings like type_XYZ_16 are performed? I've having trouble tracking it down.

[Lcms-user] Question related to curve smoothing

[Leandro R. <lea...@ri...>]

Hello,

Based on [1], we've added the code to decompose a cmsHTRANSFORM into a
shaper (3x1D LUT) + 3D LUT on Weston [2].

We want to smooth the shaper with cmsSmoothToneCurve(), but we don't know
exactly how to choose the lambda parameter. In [1] we have: "lambda is a
parameter by which we can trade smoothness of z against fit to data y". But
would there be any drawback in using lambda == 0, i.e. allowing "full
smoothness"?

Any feedback from your experience with that would be appreciated.

[1] https://www.littlecms.com/ASICprelinerization_CGIV08.pdf
[2] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1644

Thanks,
Leandro Ribeiro

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

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

Little CMS 2.17 released


I am glad to the announce the release 2.17 of the Little CMS open-source
color engine. This is a maintenance release.

 

Changes

 

*	Add fuzzers foundation. Many thanks to Amir Montazery and
Open-Source Technology Improvement Fund (ostif.org), Google, for funding
that.
*	Add ability to disable building tests in meson
*	Fixed gamut warning not working on certain conditions
*	Mac sequoia added to test beds
*	Add the possibility of duplicating a NULL context for cloning
defaults.
*	Small cleanup of CGATS parser.
*	Change computation of profile ID to follow actual ICC spec (yes,
they changed the spec!)
*	Allow to apply color management on memory blocks > 4Gb.
*	Get rid of samples on meson compilation
*	Increase coverage of pre-multiplied alpha.
*	Bug fixing and cosmetical work.

 

 

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. 

 

 

Reach it at:

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

 

Downloads:

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

 

 

Best regards, 

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

[Lcms-user] [Release candidate] Little CMS 2.17 release candidate 1

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

Hi,

 

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

 

The first release candidate is available here:

 

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

 

Changes

 

*	Add fuzzers foundation. Many thanks to Amir Montazery and
Open-Source Technology Improvement Fund (ostif.org), Google, for funding
that.
*	Add ability to disable building tests in meson
*	Fixed gamut warning not working on certain conditions
*	Mac sequoia added to test beds
*	Add the possibility of duplicating a NULL context for cloning
defaults.
*	Small cleanup of CGATS parser.
*	Change computation of profile ID to follow actual ICC spec (yes,
they changed the spec!)
*	Allow to apply color management on memory blocks > 4Gb.
*	Get rid of samples on meson compilation
*	Increase coverage of pre-multiplied alpha.
*	Bug fixing and cosmetical work.

 

Feel free to test it on all your products, tentative release date for final
lcms2-2.17 is end of Jan-2025 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] HDR

[Pekka P. <pek...@ha...>]

On Tue, 19 Mar 2024 17:56:42 +1100
Graeme Gill <gr...@ar...> wrote:

> mar...@li... wrote:
> 
> >  I think the issue here
> > is HDR is not well supported by ICC workflows, highlights and values above
> > L* 100 of D50 are seldom discussed in the 4.4 ICC spec. For BT.2020/PQ,
> > which profile I'm attaching this is quite evident. Lcms can deal with it on
> > unbounded mode, but if you feed a RGB -> Lab transform, for
> > RGB=(255,255,255) you will find L*=523!! This is not encodable in any CLUT
> > unless you provide enough headroom.   
> 
> In my view the elephant in the room with regard to HDR standards
> is the lack of explicitly dealing with the diffuse white.
> [ As best I understand it this is a result of rushing mastering
>   HDR standards into consumer products. ]

I suppose you refer to various HDR "systems" like BT.2100 PQ and HLG
defining their diffuse white as a specific code point, so it does not
need explicit communication as long as you know what system you are
looking at?

Then, PQ system defines "absolute" luminance by its TF, which is
relative to its reference viewing environment. HDR static metadata
tells the mastering display color volume (or not) to give the bounds on
luminance and gamut.

HLG system uses relative luminance signal, and defines a luminance
conversion function to map the signal to given display capability. The
result is again relative to reference viewing environment.

Neither specifies how to adapt the image to a different viewing
environment.

Does this match your understanding?

Our draft of Wayland protocol extension currently stops at delivering
the HDR static metadata. We think that we also need to communicate
expected or reference viewing environment somehow, and perhaps diffuse
white level in order to pin everything down in the image content. Those
may be defined by the "system" the content was made for, if nothing
else.

Then let the end user adjust a couple of simple knobs to get the image
right for their display and viewing environment. That will affect the
final diffuse white level on display, which affects also the HDR
headroom.

> This then flows through to a lack of standards in things like
> ICC profiles for HDR displays. Simply determining a PCS diffuse white point for
> a given ICC defined HDR space lets you trivially convert to/from
> SDR, and not have to even worry about using ICC V4 to represent
> above PCS white values. This also means that SDR mappings
> are not hard coded into the profiles, and can be set by the user
> to suite their viewing situation and/or the source material.
> Levels above diffuse white can also be well managed in terms
> of compressing highlights to fit the range of the display,
> or applying tricks like highlight extrapolation from SDR sources.


Thanks,
pq

Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT profiles, problem with BPC

[Pekka P. <pek...@ha...>]

On Tue, 19 Mar 2024 10:16:12 +0100
<mar...@li...> wrote:

> Hi,
> 
> > I have understood that LittleCMS has already made that decision for me,  
> for
> > the v4 perceptual rendering intent:
> > https://github.com/mm2/Little-
> > CMS/blob/46355888b823b563db928faec59b0312a05e1143/src/cmscnvrt.
> > c#L1129-L1133  
> 
> That was a long time ago.  You probably know about V4 and perceptual PCS.
> For V4, ICC decided to define a different PCS for perceptual and saturation
> intents. This PCS is almost identical to relative colorimetric but with a
> perceptual black point. This decision messed out things to incredible
> levels, converting some combined transforms in a big mess. Just consider a
> scanner to printer going rel. colorimetric in scanner and perceptual on
> printer. 
> To make things worse, I found a lot of matrix-shaper profiles claiming to be
> V4 and providing only one set of matrix-curves. Obviously, this cannot give
> zero and perceptual black at same time, so I reported the issue to ICC (I
> was in the committee at that time) and get the answer "all those profiles
> are wrong".

Does that mean that it is basically illegal to craft a v4 profile with
only TRC and Colorant tags, without any BToA0/BToD0 tags?

Looking at ICC v4.4, there is no requirement for any *To* tags for a
three-channel Display class profile. They really should say if more
tags are required.

> Then, since I could not discard such big number of profiles, I tried to
> imagine a way to automatically do the rescaling from different PCS. And
> found BPC to work fine for that. So, the idea behind this change is to
> increase inter-operability and fix broken profiles.

Given the spec, your decision does make sense to me. I actually had
been wondering "which PCS" should win when a profile contains only TRC
and Colorant tags, but no *To*0 tags, and why the ICC spec does not
seem to say. I see now.

I have understood that the cLUT profiles I generate are badly formed
when they (the perceptual tags) do not map device black to the v4
perceptual PCS black. This causes my tests to fail. Therefore when
constructing my cLUT, I am adding a BPC step that matches what
LittleCMS would do. Then the device black point matches PCS
expectations, and my both matrix-shaper and cLUT profiles produce
identical results via LittleCMS.

I've also wondered why BPC is not done twice: from source to PCS and
PCS to destination. I suppose if PCS by definition has that hardcoded
non-zero black point, then any conversion to/from PCS already has the
PCS black point, and BPC would do nothing. But... uh...


Thanks,
pq

Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT profiles, problem with BPC

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

>It seems to me that BPC makes black worse almost as often as it makes it
better though!
Haha, blame Adobe for that, I just followed their recipe.

> Case in point with lcms BPC:
Nice matching, don't they?

I guess both profiles you used are V2. The BPC is used automatically by lcms
when you mix V2 and V4

Tried with built-in sRGB, which is V4:

marti@PORTATIL:~$ transicc -i\*srgb -o bpctest.icm -t0
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.09]

Enter values, 'q' to quit
R? 0
G? 0
B? 0

R=19.3152 G=11.3658 B=24.4436

Regards
Marti

-----Original Message-----
From: Graeme Gill <gr...@ar...> 
Sent: Wednesday, March 20, 2024 3:20 AM
Cc: lcm...@li...
Subject: Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT
profiles, problem with BPC

mar...@li... wrote:

Hello Marti,

> Sure, 16 bits is a plenty of room, but if you use 16 bits to encode L* 
> and a big part of the domain are highlights over 100, then you could 
> end 0..100 to be encoded using 9 bits and this is still not enough for a
decent accuracy.

An available HDR display is lucky to hit 2000 cd/m^2. If you pick a diffuse
white of (say) 200 cd/^m, and the max is encoded as L* = 100, then the
diffuse white ends up at L* = 37.8. With 16 bits that leaves 24773
perceptually encoded levels SDR range or 14.6 bits. That's a resolution of
0.004 dE, more than enough.

Worst case XYZ PCS is not so favourable of course - a 10000 cd/m^2 display
running at a diffuse white point of 100 cd/m^s would only have a little over
9 bits of linear encoding available. This would have visible banding in
black. So yes, either a ICC V2 16 bit L*a*b* PCS or ICC V4 MPE XYZ PCS
floating point to encode source standards.

> Another issue is what to do with those highlights. A tag with HDR 
> diffuse white would help to do a coarse clipping, but if you want some 
> gamut mapping to bring highlights into SDR gamut, you have to redo
everything.

I really don't imagine doing this in the profile itself. Too inflexible.
Better off doing this in the linking or execution of the source to
destination transform using non-ICC machinery.

> Then, since I could not discard such big number of profiles, I tried 
> to imagine a way to automatically do the rescaling from different PCS. 
> And found BPC to work fine for that. So, the idea behind this change 
> is to increase inter-operability and fix broken profiles.

It seems to me that BPC makes black worse almost as often as it makes it
better though!

Case in point with lcms BPC:

Using this RGB printer profile: <https://www.argyllcms.com/bpctest.icm>

transicc.exe -t1 -isRGB.icm -obpctest.icm Enter values, 'q' to quit R? 0 0 0
R=25.8949 G=5.3969 B=0.0000

icclu -ff -ir -s255 bpctest.icm
25.894900 5.396900 0.000000 [RGB] -> Lut_A2B1 -> 5.693560 0.252739 -3.343661
[Lab]

transicc.exe -b -t1 -isRGB.icm -obpctest.icm Enter values, 'q' to quit R? 0
0 0
R=41.5914 G=9.5681 B=0.0000

icclu -ff -ir -s255 bpctest.icm
41.591400 9.568100 0.000000 [RGB] -> Lut_A2B1 -> 8.089132 -0.308324
-2.011786 [Lab]


At least the lcms BPC doesn't seem to wreck the perceptual black on this
one:
(unlike Adobe's always on BPC in Lightroom)

transicc.exe -b -t0 -isRGB.icm -obpctest.icm Enter values, 'q' to quit R? 0
0 0
R=19.3152 G=11.3658 B=24.4436

icclu -ff -ir -s255 bpctest.icm
19.315200 11.365800 24.443600 [RGB] -> Lut_A2B1 -> 4.296325 -0.431107
-5.422716 [Lab]

Cheers,
	Graeme.	


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

Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT profiles, problem with BPC

[Graeme G. <gr...@ar...>]

mar...@li... wrote:

Hello Marti,

> Sure, 16 bits is a plenty of room, but if you use 16 bits to encode L* and a
> big part of the domain are highlights over 100, then you could end 0..100 to
> be encoded using 9 bits and this is still not enough for a decent accuracy. 

An available HDR display is lucky to hit 2000 cd/m^2. If you pick a diffuse
white of (say) 200 cd/^m, and the max is encoded as L* = 100, then the
diffuse white ends up at L* = 37.8. With 16 bits that leaves 24773
perceptually encoded levels SDR range or 14.6 bits. That's a resolution
of 0.004 dE, more than enough.

Worst case XYZ PCS is not so favourable of course - a 10000 cd/m^2
display running at a diffuse white point of 100 cd/m^s would only
have a little over 9 bits of linear encoding available. This would
have visible banding in black. So yes, either a ICC V2 16 bit L*a*b* PCS
or ICC V4 MPE XYZ PCS floating point to encode source standards.

> Another issue is what to do with those highlights. A tag with HDR diffuse
> white would help to do a coarse clipping, but if you want some gamut mapping
> to bring highlights into SDR gamut, you have to redo everything.

I really don't imagine doing this in the profile itself. Too inflexible.
Better off doing this in the linking or execution of the source to destination
transform using non-ICC machinery.

> Then, since I could not discard such big number of profiles, I tried to
> imagine a way to automatically do the rescaling from different PCS. And
> found BPC to work fine for that. So, the idea behind this change is to
> increase inter-operability and fix broken profiles.

It seems to me that BPC makes black worse almost as often as it
makes it better though!

Case in point with lcms BPC:

Using this RGB printer profile: <https://www.argyllcms.com/bpctest.icm>

transicc.exe -t1 -isRGB.icm -obpctest.icm
Enter values, 'q' to quit
R? 0 0 0
R=25.8949 G=5.3969 B=0.0000

icclu -ff -ir -s255 bpctest.icm
25.894900 5.396900 0.000000 [RGB] -> Lut_A2B1 -> 5.693560 0.252739 -3.343661 [Lab]

transicc.exe -b -t1 -isRGB.icm -obpctest.icm
Enter values, 'q' to quit
R? 0 0 0
R=41.5914 G=9.5681 B=0.0000

icclu -ff -ir -s255 bpctest.icm
41.591400 9.568100 0.000000 [RGB] -> Lut_A2B1 -> 8.089132 -0.308324 -2.011786 [Lab]


At least the lcms BPC doesn't seem to wreck the perceptual black on this one:
(unlike Adobe's always on BPC in Lightroom)

transicc.exe -b -t0 -isRGB.icm -obpctest.icm
Enter values, 'q' to quit
R? 0 0 0
R=19.3152 G=11.3658 B=24.4436

icclu -ff -ir -s255 bpctest.icm
19.315200 11.365800 24.443600 [RGB] -> Lut_A2B1 -> 4.296325 -0.431107 -5.422716 [Lab]

Cheers,
	Graeme.