lcms-user — For users of the little cms library

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

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

Hi Greg,

Please find attached a first draft of the document you described. I'm open
to any additions or corrections you may suggest.
If it looks good to you, I'll submit it as a pull request so everyone can
review and comment on any changes.

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


> -----Original Message-----
> From: Greg Troxel <gd...@le...>
> Sent: Thursday, April 30, 2026 8:56 PM
> To: mar...@li...
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] [ANNOUNCE] Little CMS 2.19 released
> 
> Also
> 
>   In the build instructions, document the preferred build system, and
>   which are supported and believed to be fully satisfactory, and which
>   are in testing.
> 
>   Try really hard not to say to use tool X for some set of systems and
>   tool Y for some other set of systems.

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

[Greg T. <gd...@le...>]

Also

  In the build instructions, document the preferred build system, and
  which are supported and believed to be fully satisfactory, and which
  are in testing.

  Try really hard not to say to use tool X for some set of systems and
  tool Y for some other set of systems.

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

[Greg T. <gd...@le...>]

<mar...@li...> writes:

> The current plan is to listen to maintainers and move in the direction that
> makes the most sense. Autotools still works, but it's getting old and is
> largely superseded by CMake and Meson. I've tried to add all tests and
> targets across all build systems, but there are still a huge number of
> configurations to cover. I added some CI on GitHub, though it only scratches
> the surface.

My overall experience from packaging, across many projects, is that
people say "autotools old, cmake shiny" and claim that there will be no
regressions in moving from autotools to cmake, and then usually there
are regressions (but it works fine for the OS and build environment
where it was tested, of course) -- and the proponents aren't really
interested in fixing those issues.  Usually those problems get fixed
eventually, and my impression is that cmake itself has better defaults
these days, so there are fewer problems.

The real problem with autoconf/automake/libtool is that on Windows, it
only runs in environments with a shell, e.g. cygwin, and not native
builds in a no-/bin/sh environment.

A problem with cmake is that it is huge and seems to need C++17, but it
seems to have some skind of fallback mechanism.  That means if cmake is
the (only) build system, then environments without newish C++ can't
build natively and would have to rely on cross builds.  Today, that is
probably not so bad as it was.  On my system, cmake is 53 MB installed,
vs 8 Mb for the combination of autoconf/automake/libtool-base, and you
don't need automake to build; that's at distfile creation time.

> If you have any recommendations, they would be very welcome. Dropping
> Autotools doesn't seem like a bad idea, but since it still works reliably,
> it may be wiser to leave it in place for now.

My recommendations would be:

  Disregard any criticism of autotools for "old", having a long history
  etc., and only pay attention to actual problems.

  Establish written requirements for build systems, including distfile
  creation, support for alternate prefixes for lcms being built and
  prereqs, cross building, 'make test' or equiv using the just-built
  bits and not the installed bits (requires care in RPATH), operating on
  macOS, *BSD, and illumos in addition to GNU/Linux.

  Don't drop autoconf just because it doesn't do some windows
  toolchains, if it's the preferred method for a significant number, or
  if other systems fail to meet any of the requirements.

  See if meson can really meet requirements; I honestly have no idea.
  Having two recent systems that each have significant resource
  requirements seems duplicative, so I'd ask why there should be both
  meson and cmake.

  I see that only if building with cmake are the cmake support files
  installed.  The point of these is for other programs that use cmake,
  that want to find and link against lcms.  It should not matter how
  lcms was built.

  Consider how the distribution is created.  I'd expect 'make dist' from
  autoconf, now.  I don't get the impression cmake does this; it seems
  more "let the tarball that github creates be what is ditributed" is
  the cmake way.  It's normal to have files in the repo that aren't in
  the tarball, in traditional practice.  We we have github tarball
  disease, where it's forced to be the repo because that's what the
  tools do if you don't fight it, just as github issues are the new
  mailinglists :-(


> By the way, version 2.19 has a significant issue in configure.ac that
> results in incorrect sonames, LIBRARY_REVISION should be set to 19. It's
> already fixed in master, but not in the tarballs published on GitHub. I'm
> considering whether this alone justifies a 2.19.1 release.

It's not a problem for pkgsrc, which can have only one lcms2 version,
and the micro version doesn't really matter.

For other environments, I'm really not sure.  My usual reaction is to
spend the 30 minutes and fix because it takes unknown trouble off the
table and unknown trouble is usually worse than you think -- but I can't
argue that this is wise in this case.

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

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

Hi Greg,

Thanks for reaching out.

The current plan is to listen to maintainers and move in the direction that
makes the most sense. Autotools still works, but it's getting old and is
largely superseded by CMake and Meson. I've tried to add all tests and
targets across all build systems, but there are still a huge number of
configurations to cover. I added some CI on GitHub, though it only scratches
the surface.

If you have any recommendations, they would be very welcome. Dropping
Autotools doesn't seem like a bad idea, but since it still works reliably,
it may be wiser to leave it in place for now.

By the way, version 2.19 has a significant issue in configure.ac that
results in incorrect sonames, LIBRARY_REVISION should be set to 19. It's
already fixed in master, but not in the tarballs published on GitHub. I'm
considering whether this alone justifies a 2.19.1 release.

Best regards,

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

> -----Original Message-----
> From: Greg Troxel <gd...@le...>
> Sent: Thursday, April 30, 2026 3:13 PM
> To: mar...@li...
> Cc: lcm...@li...
> Subject: Re: [Lcms-user] [ANNOUNCE] Little CMS 2.19 released
> 
> <mar...@li...> writes:
> 
> (I am the nominal package maintainer for lcms in pkgsrc.)
> 
> > Little CMS 2.19 released
> >
> > - CMake build system. Thanks to Vlad Erium for the initial
> > implementation and kmilos for improvements.
> 
> What is the plan and status for build systems?   Specifically:
> 
>   I interpret the situation as that autoconf is and remains the
>   official, supported build system, and that cmake has just been added,
>   for people that want to try it.
> 
>   I do not interpret the addition of cmake as signaling a decision to
>   remove autoconf, now or in the future.
> 
>   I am unclear on if tests and cross compilation work as well in cmake
>   as they do in autoconf (or perhaps better, but that's not the usual
>   pattern).
> 
>   I am unclear on if there advantages to using cmake over autoconf, for
>   builds that are not having problems.
> 
> 
> Thanks,
> Greg

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

[Greg T. <gd...@le...>]

<mar...@li...> writes:

(I am the nominal package maintainer for lcms in pkgsrc.)

> Little CMS 2.19 released
>
> - CMake build system. Thanks to Vlad Erium for the initial implementation
> and kmilos for improvements. 

What is the plan and status for build systems?   Specifically:

  I interpret the situation as that autoconf is and remains the
  official, supported build system, and that cmake has just been added,
  for people that want to try it.

  I do not interpret the addition of cmake as signaling a decision to
  remove autoconf, now or in the future.

  I am unclear on if tests and cross compilation work as well in cmake
  as they do in autoconf (or perhaps better, but that's not the usual
  pattern).

  I am unclear on if there advantages to using cmake over autoconf, for
  builds that are not having problems.


Thanks,
Greg

[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