lcms-user — For users of the little cms library

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

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

Hello, Colors Experts!

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

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

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

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

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

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

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

Thank you for any suggestions!

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

-- 
Best regards, Sergey.

Re: [Lcms-user] Handling channel extraction

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

Hi,

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

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

Regards

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



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

Re: [Lcms-user] Handling channel extraction

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

Hi,

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

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

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

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

Hope that helps
Regards

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




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

[Lcms-user] Handling channel extraction

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

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

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

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

Thanks,

Adrian.

[Lcms-user] How to correct wrong black-point

[Tamas L. <lit...@gm...>]

Hi,

I encountered a strange working behavior of my X-Rite i1 and don't know how
to solve that problem..

We have a new small size photo printer in our shop which uses a special dye
ink.
I usually do my own calibrations instead of using those ones that come from
the manufacturers and 99% of my profiles work as I expected. Except for
this printer.

Manufacturer's profile has some serious shadows (disadvantage) that I don't
like, but the blacks are 99.9% black (advantage).
My profiles have a much more linear response without that shadow
(advantage), but the blacks always have some color tints in it - like a
little bit greenish - compared to "real" blacks. The manufacturer's profile
can "guess" this black, but i1Profiler cannot and I don't know the reason
why. Because i1Profiler performs well on other types of paper and printer,
I think it's caused by a bad combination of photo paper and dye ink type.
(My first guess was the high OBA content, but the OBA Calibration mode in
i1Profiler had similar results.)

What can I do with it?

I also don't know how we can define the grays & blacks, what is an exact
gray without (or a min.) color components included....

Is there a way to move my "wrong" calibration to the right direction? How
can I measure the exact distance for it...? Not only in theory, but
programmatically, too (I am familiar with lcms). Is it the right path to
solve the problem?

Any ideas or help welcome!

Thanks!
Tamas

Re: [Lcms-user] How to change number of threads between transforms

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

Hi Adrian,

What you need are contexts. Contexts gives you exactly the functionality you
asked for:

cmsContext ctx_single = cmsCreateContext(NULL, NULL); // A context for 1
thread
cmsContext ctx_multi  =
cmsCreateContext(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS),
NULL); // A context for multi-threaded

Then use cmsCreateTransformTHR to create different transforms on each
context. The obtained transforms will use one thread or be multithreaded. 
You can just apply the transforms by using cmsDoTransform or
cmsTransformLineStride. The CMM knows if it should split or not the work
because that information is already in the transform handle.

Hope that helps
Regards

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




> -----Original Message-----
> From: Adrian Knagg-Baugh <aje...@gm...>
> Sent: Friday, July 14, 2023 1:10 AM
> To: lcm...@li...
> Subject: [Lcms-user] How to change number of threads between transforms
> 
> Hi,
> 
> Please excuse the skeletal pseudocode. Sometimes in my code I would like
to
> use multiple threads when doing a transform, but at other times it is
> important that I only use a single thread. So I need to work out how best
to
> switch between the two configurations.
> 
> Is it permitted to do something like this:
> {
> cmsPlugin(cmsFastFloatExtensions()); // Register fast float plugin
> cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS,
> 0)); // Register the threading plugin with maximum threads
> 
> // I want this transform to use maximum threads
> cmsDoTransformLineStride(...);
> 
> // I want this next transform to use only 1 thread
> cmsPlugin(cmsThreadedExtensions(1, 0)); // Reconfigure the threading
plugin
> with 1 thread cmsDoTransformLineStride(...); // Do the single-threaded
> transform
> 
> // Now back to maximum threads...
> cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS,
> 0)); // Reconfigure the threading plugin with maximum threads }
> 
> Or instead would I have to do this:
> {
> cmsPlugin(cmsFastFloatExtensions()); // Register fast float plugin
> cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS,
> 0)); // Register the threading plugin with maximum threads
> 
> // I want this transform to use maximum threads
> cmsDoTransformLineStride(...);
> 
> // I want this next transform to use only 1 thread cmsUnregisterPlugins();
//
> Revert to pristine lcms2 cmsPlugin(cmsFastFloatExtensions()); //
Re-register
> fast float plugin only cmsDoTransformLineStride(...); // Do the
single-threaded
> transform
> 
> // Now back to maximum threads...
> cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS,
> 0)); // Re-register threading plugin with maximum threads }
> 
> Thanks,
> 
> Adrian.
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] How to change number of threads between transforms

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

Hi,

Please excuse the skeletal pseudocode. Sometimes in my code I would
like to use multiple threads when doing a transform, but at other
times it is important that I only use a single thread. So I need to
work out how best to switch between the two configurations.

Is it permitted to do something like this:
{
cmsPlugin(cmsFastFloatExtensions()); // Register fast float plugin
cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS, 0));
// Register the threading plugin with maximum threads

// I want this transform to use maximum threads
cmsDoTransformLineStride(...);

// I want this next transform to use only 1 thread
cmsPlugin(cmsThreadedExtensions(1, 0)); // Reconfigure the threading
plugin with 1 thread
cmsDoTransformLineStride(...); // Do the single-threaded transform

// Now back to maximum threads...
cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS, 0));
// Reconfigure the threading plugin with maximum threads
}

Or instead would I have to do this:
{
cmsPlugin(cmsFastFloatExtensions()); // Register fast float plugin
cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS, 0));
// Register the threading plugin with maximum threads

// I want this transform to use maximum threads
cmsDoTransformLineStride(...);

// I want this next transform to use only 1 thread
cmsUnregisterPlugins(); // Revert to pristine lcms2
cmsPlugin(cmsFastFloatExtensions()); // Re-register fast float plugin only
cmsDoTransformLineStride(...); // Do the single-threaded transform

// Now back to maximum threads...
cmsPlugin(cmsThreadedExtensions(CMS_THREADED_GUESS_MAX_THREADS, 0));
// Re-register threading plugin with maximum threads
}

Thanks,

Adrian.

Re: [Lcms-user] Linearization

[Tamas L. <lit...@gm...>]

Thank you for your fast reply!

It took me a few days to find the bug in the "reverse interpolation" part,
and you are right, I was lost in details.
Probably I can fine-tune the interpolation somehow, but the printed results
- especially the "BullsEye" gradients are very beautiful now.

Thanks again!
Tamas


On Thu, 15 Jun 2023 at 08:41, <mar...@li...> wrote:

> Hello,
>
>
>
> When doing this kind of things, it is important to keep in mind the real
> goals of the process because sometimes is very easy to get lost in details.
>
>
>
> “Linearization” is a term that I’ve seen used to a multitude of scenarios.
>
>
>
>
> A valid approach when profiling a printer is to do it on two steps. The
> first step would be to bring the particular printer to a generic well-known
> state. For example, by using C, M Y and K tone curves, one per output
> channel. Then profile this generic printer.  The first step is known as
> “linearization”. The obvious advantage of this approach is you have not to
> reprofile your printer often but just recompute the curves, which is by far
> cheaper and faster.
>
>
>
> Another situation when the term linearization is used is when you want a
> profile to “match” the characteristics of a given metric. Examples of this
> are to create an RGB device space that behaves linearly on Luma.  Some of
> the linearization goal metrics are intuitive, others are not. For example,
> when linearizing CMYK, you can use L* on all channels but on Yellow.
> Reason is yellow contributes poorly to L*, and is better to use b* in this
> case. Other metrics can be optical density or its derivatives.
>
>
>
> So, assuming you want a tone curve to make a gray device space to behave
> linearly with L*, you could print a scale of 10-20 patches and then measure
> it. With the obtained values perform reverse interpolation. For each L* you
> will obtain which device gray value to print. With those values build a
> tone curve and you got the linearization. As a test, your tone curve should
> match the printed values.
>
>
>
> When doing multidimensional, things go more complex though.
>
>
>
> Hope that helps
>
> Regards
>
>
>
> Marti Maria
>
> The LittleCMS Project
>
> https://www.littlecms.com
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Tamas Littmann <lit...@gm...>
> *Sent:* Wednesday, June 14, 2023 1:39 PM
> *To:* lcm...@li...
> *Subject:* [Lcms-user] Linearization
>
>
>
> Hello,
>
>
>
> I have used LCMS for image color space transforms for lots of years, but I
> am relatively new in creating my own profiles.
>
> Using C# and .NET, I can do most of the creating process successfully.
>
> However, it seems that I cannot move on from some of the easiest steps (I
> think I understand the process, but the results are not satisfactory).
>
>
>
> Here, I try to minimize the problem, and use 1D transforms (linearization
> curve) and Grayscale space (only 1 color).
>
>
>
> In this case, how can I linearize a black&white grayscale image/printer?
>
>
>
> Here is what I tried to do:
>
> 1. Print an equal step  grayscale ramp (in grayscale mode, using 8-bit 0 -
> 255 values. E.g: for six steps it's 0/51/102/153/204/255). 52 steps seems
> to be a good starting point (steps are 0 - 5 - 10 - 15 - 20 - etc..)
>
>
>
> 2. I have an X-Rite i1 / Datacolor Spyder, so I can read the values in LAB
> format (saved CGATS files).
>
>
>
> 3. White Point LAB L* is usually around 94, black point LAB L* is usually
> from 3 - 15, depends the type of media, so i need to slice this range to
> equal steps to find the linear values (if i want something else, not like a
> linear line, but a special curve, i need to slice this range according to
> that curves).
>
>
>
> 4. Normalize both LAB L* data arrays to a 0.0 - 100.0 range.
>
>
>
> 5. Find the difference between the measured ones and the linear ones.
>
>
>
> 6. Used those differences to calculate LAB L* -> Grayscale values. (This
> is the point where I think I misunderstand something). Normally I added
> these difference values to the original source Gray -> LAB L* values.
>
>
>
> I can use the corrected LAB L* values to create normal output profiles, or
> can use the Grayscale values to create a simple DeviceLink profile. The
> easiest method is to use the cmsBuildTabulatedToneCurve16 with the
> resulting values converted to the 0 - 65535 range. (But also got advice to
> use an 1D LUT table, but the ToneCurves are needs to be enough)
>
>
>
> Everything seems right and works flawlessly, except the results are not
> (very) linear and the  classic 'bullseye' images are wrong....
>
>
>
>
>
> From anyone who tried to do similar linearizations in the past or any hint
> or help would be very helpful for me.
>
>
>
> Many thanks,
>
> Tamas
>
>
>
>
>

Re: [Lcms-user] RGB to XYZ conversion

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

Hello,

I have written a small program to check this and found it works fine to me.
At first glance I see a couple of things on your code, but didn't analyze in
detail. float_xyz[] do not compile, you need to set the size, which at least
should be 3. Another thing is the formatters TYPE_RGB_FLT_PLANAR and
TYPE_XYZ_FLT_PLANAR that are not in lcms2.h, therefore you have defined them
elsewhere.  Check if correct. 

Anyway, this is the program I did that gives the right values.

#include "lcms2.h"

#define TYPE_RGB_FLT_PLANAR
(FLOAT_SH(1)|COLORSPACE_SH(PT_RGB)|CHANNELS_SH(3)|BYTES_SH(4)|PLANAR_SH(1))
#define TYPE_XYZ_FLT_PLANAR
(FLOAT_SH(1)|COLORSPACE_SH(PT_XYZ)|CHANNELS_SH(3)|BYTES_SH(4)|PLANAR_SH(1))

int main()
{
    float rgb[] = { 0.75f, 0.5f, 0.3f };
    float xyz[3];

    cmsHPROFILE srgb_icc = cmsCreate_sRGBProfile();
    cmsHPROFILE xyz_icc = cmsCreateXYZProfile();

    cmsHTRANSFORM workingtoxyz = cmsCreateTransform(srgb_icc,
TYPE_RGB_FLT_PLANAR, xyz_icc, TYPE_XYZ_FLT_PLANAR, INTENT_PERCEPTUAL, 0);

    cmsCloseProfile(xyz_icc);
    cmsCloseProfile(srgb_icc);

    cmsDoTransform(workingtoxyz, rgb, xyz, 1);

    printf("LCMS rgb2xyz: %f %f %f\n", xyz[0], xyz[1], xyz[2]);
    cmsDeleteTransform(workingtoxyz);

   return 0;
}

Output:
LCMS rgb2xyz: 0.320747 0.274139 0.080336

You can verify the values using this calculator
http://www.brucelindbloom.com/index.html?ColorCalculator.html

Hope that helps

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



> -----Original Message-----
> From: Adrian Knagg-Baugh <aje...@gm...>
> Sent: Thursday, June 15, 2023 8:54 PM
> To: lcm...@li...
> Subject: [Lcms-user] RGB to XYZ conversion
> 
> Hello,
> 
> I'm trying to convert data from a source RGB colorspace to HSLuv (that
color
> space is a bit niche but I specifically want to use it for a saturation
stretching
> function). I did an initial test using the C implementation from hsluv.org
and
> sRGB source data and it works well, but I want to be able to cope with any
RGB
> source profile so my plan was to use LittleCMS to convert the source data
to
> XYZ and then use the hsluv.org functions to convert XYZ to HSLuv.
> 
> However I'm getting unexpected results from the initial conversion to XYZ
and
> I wonder if I'm doing something wrong. Here's what I'm trying, first I
make a
> transform:
> ```
>     cmsHPROFILE xyz = cmsCreateXYZProfile();
>     cmsUInt32Number formatrgb = TYPE_RGB_FLT_PLANAR;
>     cmsUInt32Number formatxyz = TYPE_XYZ_FLT_PLANAR;
>     cmsHTRANSFORM workingtoxyz = cmsCreateTransform(gfit.icc_profile,
> formatrgb, xyz, formatxyz, com.pref.icc.processing_intent, 0);
>      cmsCloseProfile(xyz);
> ```
> gfit.icc_profile is a cmsHPROFILE and contains a sRGB profile, and
> com.pref.processing_intent is set to INTENT_PERCEPTUAL: those work fine
> throughout the rest of the code.
> But when I apply it with cmsDoTransform() the effect on an image looks
> completely wrong compared with my initial test using hsluv's rgb2xyz()
> function. I tested the RGB to XYZ conversion using the following:
> ```
>     float test_rgb[] = {0.75f, 0.5f, 0.3f};
>     float test_xyz[];
>     printf("RGB test: %f %f %f\n", test_rgb[0], test_rgb[1], test_rgb[2]);
>     hsluv_rgbtoxyz(test_rgb[0], test_rgb[1], test_rgb[2], &test_xyz[0],
> &test_xyz[1], &test_xyz[2]);
>     printf("HSLuv rgb2xyz: %f %f %f\n", test_xyz[0], test_xyz[1],
test_xyz[2]);
>      cmsDoTransform(workingtoxyz, (void*) &test_rgb, (void*) &test_xyz,
1);
>     printf("LCMS rgb2xyz: %f %f %f\n", test_xyz[0], test_xyz[1],
test_xyz[2]); ```
> And the results are completely different:
> 
> HSLuv rgb2xyz: 0.305239 0.269471 0.105229 LCMS rgb2xyz: 0.160394
> 0.137083 0.040251
> 
> I assume I'm doing something wrong but I can't see what - grateful for any
> help you can offer.
> 
> Thanks,
> 
> Adrian.
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] RGB to XYZ conversion

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

Hello,

I'm trying to convert data from a source RGB colorspace to HSLuv (that
color space is a bit niche but I specifically want to use it for a
saturation stretching function). I did an initial test using the C
implementation from hsluv.org and sRGB source data and it works well,
but I want to be able to cope with any RGB source profile so my plan
was to use LittleCMS to convert the source data to XYZ and then use
the hsluv.org functions to convert XYZ to HSLuv.

However I'm getting unexpected results from the initial conversion to
XYZ and I wonder if I'm doing something wrong. Here's what I'm trying,
first I make a transform:
```
    cmsHPROFILE xyz = cmsCreateXYZProfile();
    cmsUInt32Number formatrgb = TYPE_RGB_FLT_PLANAR;
    cmsUInt32Number formatxyz = TYPE_XYZ_FLT_PLANAR;
    cmsHTRANSFORM workingtoxyz = cmsCreateTransform(gfit.icc_profile,
formatrgb, xyz, formatxyz, com.pref.icc.processing_intent, 0);
     cmsCloseProfile(xyz);
```
gfit.icc_profile is a cmsHPROFILE and contains a sRGB profile, and
com.pref.processing_intent is set to INTENT_PERCEPTUAL: those work
fine throughout the rest of the code.
But when I apply it with cmsDoTransform() the effect on an image looks
completely wrong compared with my initial test using hsluv's rgb2xyz()
function. I tested the RGB to XYZ conversion using the following:
```
    float test_rgb[] = {0.75f, 0.5f, 0.3f};
    float test_xyz[];
    printf("RGB test: %f %f %f\n", test_rgb[0], test_rgb[1], test_rgb[2]);
    hsluv_rgbtoxyz(test_rgb[0], test_rgb[1], test_rgb[2],
&test_xyz[0], &test_xyz[1], &test_xyz[2]);
    printf("HSLuv rgb2xyz: %f %f %f\n", test_xyz[0], test_xyz[1], test_xyz[2]);
     cmsDoTransform(workingtoxyz, (void*) &test_rgb, (void*) &test_xyz, 1);
    printf("LCMS rgb2xyz: %f %f %f\n", test_xyz[0], test_xyz[1], test_xyz[2]);
```
And the results are completely different:

HSLuv rgb2xyz: 0.305239 0.269471 0.105229
LCMS rgb2xyz: 0.160394 0.137083 0.040251

I assume I'm doing something wrong but I can't see what - grateful for
any help you can offer.

Thanks,

Adrian.

Re: [Lcms-user] Linearization

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

Hello,

 

When doing this kind of things, it is important to keep in mind the real goals of the process because sometimes is very easy to get lost in details. 

 

“Linearization” is a term that I’ve seen used to a multitude of scenarios.  

 

A valid approach when profiling a printer is to do it on two steps. The first step would be to bring the particular printer to a generic well-known state. For example, by using C, M Y and K tone curves, one per output channel. Then profile this generic printer.  The first step is known as “linearization”. The obvious advantage of this approach is you have not to reprofile your printer often but just recompute the curves, which is by far cheaper and faster.

 

Another situation when the term linearization is used is when you want a profile to “match” the characteristics of a given metric. Examples of this are to create an RGB device space that behaves linearly on Luma.  Some of the linearization goal metrics are intuitive, others are not. For example, when linearizing CMYK, you can use L* on all channels but on Yellow.  Reason is yellow contributes poorly to L*, and is better to use b* in this case. Other metrics can be optical density or its derivatives.

 

So, assuming you want a tone curve to make a gray device space to behave linearly with L*, you could print a scale of 10-20 patches and then measure it. With the obtained values perform reverse interpolation. For each L* you will obtain which device gray value to print. With those values build a tone curve and you got the linearization. As a test, your tone curve should match the printed values.

 

When doing multidimensional, things go more complex though.

 

Hope that helps

Regards

 

Marti Maria

The LittleCMS Project

https://www.littlecms.com

 

 

 

 

 

 

From: Tamas Littmann <lit...@gm...> 
Sent: Wednesday, June 14, 2023 1:39 PM
To: lcm...@li...
Subject: [Lcms-user] Linearization

 

Hello,

 

I have used LCMS for image color space transforms for lots of years, but I am relatively new in creating my own profiles.

Using C# and .NET, I can do most of the creating process successfully. 

However, it seems that I cannot move on from some of the easiest steps (I think I understand the process, but the results are not satisfactory).

 

Here, I try to minimize the problem, and use 1D transforms (linearization curve) and Grayscale space (only 1 color).

 

In this case, how can I linearize a black&white grayscale image/printer?

 

Here is what I tried to do:

1. Print an equal step  grayscale ramp (in grayscale mode, using 8-bit 0 - 255 values. E.g: for six steps it's 0/51/102/153/204/255). 52 steps seems to be a good starting point (steps are 0 - 5 - 10 - 15 - 20 - etc..)

 

2. I have an X-Rite i1 / Datacolor Spyder, so I can read the values in LAB format (saved CGATS files).

 

3. White Point LAB L* is usually around 94, black point LAB L* is usually from 3 - 15, depends the type of media, so i need to slice this range to equal steps to find the linear values (if i want something else, not like a linear line, but a special curve, i need to slice this range according to that curves).

 

4. Normalize both LAB L* data arrays to a 0.0 - 100.0 range.

 

5. Find the difference between the measured ones and the linear ones.

 

6. Used those differences to calculate LAB L* -> Grayscale values. (This is the point where I think I misunderstand something). Normally I added these difference values to the original source Gray -> LAB L* values.

 

I can use the corrected LAB L* values to create normal output profiles, or can use the Grayscale values to create a simple DeviceLink profile. The easiest method is to use the cmsBuildTabulatedToneCurve16 with the resulting values converted to the 0 - 65535 range. (But also got advice to use an 1D LUT table, but the ToneCurves are needs to be enough)

 

Everything seems right and works flawlessly, except the results are not (very) linear and the  classic 'bullseye' images are wrong....

 

 

>From anyone who tried to do similar linearizations in the past or any hint or help would be very helpful for me.

 

Many thanks,

Tamas

 

 

[Lcms-user] Linearization

[Tamas L. <lit...@gm...>]

Hello,

I have used LCMS for image color space transforms for lots of years, but I
am relatively new in creating my own profiles.
Using C# and .NET, I can do most of the creating process successfully.
However, it seems that I cannot move on from some of the easiest steps (I
think I understand the process, but the results are not satisfactory).

Here, I try to minimize the problem, and use 1D transforms (linearization
curve) and Grayscale space (only 1 color).

In this case, how can I linearize a black&white grayscale image/printer?

Here is what I tried to do:
1. Print an equal step  grayscale ramp (in grayscale mode, using 8-bit 0 -
255 values. E.g: for six steps it's 0/51/102/153/204/255). 52 steps seems
to be a good starting point (steps are 0 - 5 - 10 - 15 - 20 - etc..)

2. I have an X-Rite i1 / Datacolor Spyder, so I can read the values in LAB
format (saved CGATS files).

3. White Point LAB L* is usually around 94, black point LAB L* is usually
from 3 - 15, depends the type of media, so i need to slice this range to
equal steps to find the linear values (if i want something else, not like a
linear line, but a special curve, i need to slice this range according to
that curves).

4. Normalize both LAB L* data arrays to a 0.0 - 100.0 range.

5. Find the difference between the measured ones and the linear ones.

6. Used those differences to calculate LAB L* -> Grayscale values. (This is
the point where I think I misunderstand something). Normally I added these
difference values to the original source Gray -> LAB L* values.

I can use the corrected LAB L* values to create normal output profiles, or
can use the Grayscale values to create a simple DeviceLink profile. The
easiest method is to use the cmsBuildTabulatedToneCurve16 with the
resulting values converted to the 0 - 65535 range. (But also got advice to
use an 1D LUT table, but the ToneCurves are needs to be enough)

Everything seems right and works flawlessly, except the results are not
(very) linear and the  classic 'bullseye' images are wrong....


>From anyone who tried to do similar linearizations in the past or any hint
or help would be very helpful for me.

Many thanks,
Tamas

Re: [Lcms-user] Device space float ranges

[John J. <j.j...@nt...>]

Many thanks Marti,

John

On 04/05/2023 15:46, mar...@li... wrote:
> Hi,
>
> Problem is if I change this 100 scaling, I break photoshop notation, and many people is using that.
>
> A neat solution would be writing a formatter plug-in to replace double encoding to the scale you need.  You could copy & paste the formatters code you want to change from cmspack.c and modify it.
>
> You probably not need all the variants, so you could simplify the code and get some throughput boost.
> See some examples on plug-ins manual, "Formatters plug-in"
>
> Regards
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
>
>
>
>> -----Original Message-----
>> From: John Jefferies via Lcms-user <lcm...@li...>
>> Sent: Thursday, May 4, 2023 2:13 PM
>> To: lcm...@li...
>> Subject: [Lcms-user] Device space float ranges
>>
>> Hello Marti,
>> I have a system where all colour spaces are device spaces (PT_GRAY, PT_RGB,
>> PT_CMYK, PT_MCH*), and all colour values are floats in the range of 0-1. I
>> therefore need a formatter to handle this, so I use this
>> formatter:
>>       cmsFormatterForColorspaceOfProfile(hProfile, sizeof(float), TRUE)
>>
>> It appears that lcms assumes that the client's float colour values are in the
>> range 0-100 if colour space is an IsInkSpace(). The problem then becomes
>> how to marshal my float values into and out of lcms. It appears that in client
>> code, I have to ensure the values are *100 or /100 as appropriate if the colour
>> space I have is an ink space.
>>
>> For my purposes, that's a bit daft. Firstly, IsInkSpace() isn't an exported
>> function so the client code has to duplicate the function itself. Secondly, it's
>> rather inefficient. Thirdly, the client code is uglier than it needs to be. Finally,
>> the assumed range of 0-100 isn't documented anywhere that I could find;
>> apologies if it is somewhere blindingly obvious.
>>
>> Is there any other way to use float values in the range 0-1?
>>
>> Regards + many thanks
>> John
>>
>>
>>
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Device space float ranges

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

Hi,

Problem is if I change this 100 scaling, I break photoshop notation, and many people is using that.

A neat solution would be writing a formatter plug-in to replace double encoding to the scale you need.  You could copy & paste the formatters code you want to change from cmspack.c and modify it.

You probably not need all the variants, so you could simplify the code and get some throughput boost.
See some examples on plug-ins manual, "Formatters plug-in"

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



> -----Original Message-----
> From: John Jefferies via Lcms-user <lcm...@li...>
> Sent: Thursday, May 4, 2023 2:13 PM
> To: lcm...@li...
> Subject: [Lcms-user] Device space float ranges
> 
> Hello Marti,
> I have a system where all colour spaces are device spaces (PT_GRAY, PT_RGB,
> PT_CMYK, PT_MCH*), and all colour values are floats in the range of 0-1. I
> therefore need a formatter to handle this, so I use this
> formatter:
>      cmsFormatterForColorspaceOfProfile(hProfile, sizeof(float), TRUE)
> 
> It appears that lcms assumes that the client's float colour values are in the
> range 0-100 if colour space is an IsInkSpace(). The problem then becomes
> how to marshal my float values into and out of lcms. It appears that in client
> code, I have to ensure the values are *100 or /100 as appropriate if the colour
> space I have is an ink space.
> 
> For my purposes, that's a bit daft. Firstly, IsInkSpace() isn't an exported
> function so the client code has to duplicate the function itself. Secondly, it's
> rather inefficient. Thirdly, the client code is uglier than it needs to be. Finally,
> the assumed range of 0-100 isn't documented anywhere that I could find;
> apologies if it is somewhere blindingly obvious.
> 
> Is there any other way to use float values in the range 0-1?
> 
> Regards + many thanks
> John
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Device space float ranges

[John J. <j.j...@nt...>]

Hello Marti,
I have a system where all colour spaces are device spaces (PT_GRAY, 
PT_RGB, PT_CMYK, PT_MCH*), and all colour values are floats in the range 
of 0-1. I therefore need a formatter to handle this, so I use this 
formatter:
     cmsFormatterForColorspaceOfProfile(hProfile, sizeof(float), TRUE)

It appears that lcms assumes that the client's float colour values are 
in the range 0-100 if colour space is an IsInkSpace(). The problem then 
becomes how to marshal my float values into and out of lcms. It appears 
that in client code, I have to ensure the values are *100 or /100 as 
appropriate if the colour space I have is an ink space.

For my purposes, that's a bit daft. Firstly, IsInkSpace() isn't an 
exported function so the client code has to duplicate the function 
itself. Secondly, it's rather inefficient. Thirdly, the client code is 
uglier than it needs to be. Finally, the assumed range of 0-100 isn't 
documented anywhere that I could find; apologies if it is somewhere 
blindingly obvious.

Is there any other way to use float values in the range 0-1?

Regards + many thanks
John

Re: [Lcms-user] Profile ID mismatch between Linux and Windows?

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

Hi again,

Updating on the state of profile ID mismatch. I verified on my Macbook
that it returned the same MD5 checksum as on Halla's machine, so I
hooked into all the functions that accessed the cmsHPROFILE and saved a
copy to the desktop.

md5sum analysis showed that the the copies prior to injecting the MD5
checksum match "W" (the Windows checksum, 84...) or "U" (the Unix
checksum, 133...) respectively, so I started grepping any lines that
changed behaviour based on CMS_IS_WINDOWS_.

With this in mind, I was able to establish the culprit is
_cmsWriteHeader, more specifically cmsio0.c lines 908-912. These run
roughshod over the platform signature that the original profile
establishes ("*nix"), thus enabling the failure.

Marti, what'd be the best way to deal with this? Would it be possible to
preserve the original header's platform signature (and maybe other bits,
given that there are other hardcodes in that function)?

Best,

amyspark

On 03/03/2023 14:51, L. E. Segovia wrote:
> Hi Marti,
> 
> This is the flow Krita follows for computing a profile ID:
> 
> https://invent.kde.org/graphics/krita/-/blob/master/plugins/color/lcms2engine/colorprofiles/LcmsColorProfileContainer.cpp#L551-573
> 
> In short, we retrieve the MD5 checksum of the profile if available,
> otherwise we tell LCMS to calculate it, then get it through
> cmsGetHeaderProfileID.
> 
> I'll try and see what's going on once I finish with my current intray.
> 
> Best,
> 
> amyspark
> 
> On 03/03/2023 10:55, mar...@li... wrote:
>> Hello,
>>
>> Not sure what steps are you following, but there is currently no functionality in lcms2 to compute the MD5 of an existing profile.
>>
>> The function cmsMD5computeID() computes the MD5 for a *new* profile you are creating. Which is not the same as the profile you have just open.  Please note the function does not return any hash, it just stores it in the profile header to be latter saved. The idea is to call this function before saving in the case you want to include MD5 checksum in the profile.
>>
>> In your case, opening the profile "sRGB-elle-V4-srgbtrc.icc" gives a valid template in the handle that you could modify by using cmsWriteTag(). If you save this handle with cmsSaveProfileToFile(), you would obtain a new profile with same functionality but not necessarily with same layout. Maybe with some extra tags, maybe with user-defined tags stripped down. The header will be different, too. For sure creation datetime and platform could change. So, the MD5 will obviously be different and profiles remain valid, but not binary equal. This was never intended to keep same layout, nor to be a profile editor that preserves fields.
>>
>> If you want a function to compute the MD5 of a yet existing profile, I could add it to 2.16, just let me know.
>>
>> Regards
>> Marti
>>
>>
>>
>>> -----Original Message-----
>>> From: L. E. Segovia via Lcms-user <lcm...@li...>
>>> Sent: Thursday, March 2, 2023 4:56 PM
>>> To: lcm...@li...
>>> Subject: [Lcms-user] Profile ID mismatch between Linux and Windows?
>>>
>>> Hi all,
>>>
>>> We've just found something strange when getting the MD5 checksum of a
>>> profile through cmsMD5computeID. Judging from Halla Rempt's test here,
>>>
>>> https://invent.kde.org/graphics/krita/-
>>> /commit/1191295a4618a93893987497e3c54e6f0c2fd025#note_634123
>>>
>>> the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes depending
>>> on the operating system; 84f64878faf21217362594685be031d5 is the
>>> Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux hash.
>>>
>>> The profile is available here:
>>>
>>> https://invent.kde.org/graphics/krita/-
>>> /blob/1191295a4618a93893987497e3c54e6f0c2fd025/libs/flake/tests/data/icc
>>> /sRGB-elle-V4-srgbtrc.icc
>>>
>>> Or alternatively:
>>>
>>> https://invent.kde.org/graphics/krita/-
>>> /blob/1191295a4618a93893987497e3c54e6f0c2fd025/krita/data/profiles/elles
>>> -icc-profiles/sRGB-elle-V4-srgbtrc.icc
>>>
>>> As a verification, the sha256sum of the icc file is:
>>>
>>> 52d632fd6c3d2389a767a84faa0919beae6498eeb501730d170e90f0f86f594f
>>> sRGB-elle-V4-srgbtrc.icc
>>>
>>> Please let me know if you've run into this before, if not, I'll try to debug it
>>> myself during the weekend.
>>>
>>> Best,
>>>
>>> amyspark
>>>
>>> --
>>> amyspark 🌸 https://www.amyspark.me
>>>
>>>
>>> _______________________________________________
>>> Lcms-user mailing list
>>> Lcm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
> 

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

Re: [Lcms-user] Profile ID mismatch between Linux and Windows?

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

Hi Marti,

This is the flow Krita follows for computing a profile ID:

https://invent.kde.org/graphics/krita/-/blob/master/plugins/color/lcms2engine/colorprofiles/LcmsColorProfileContainer.cpp#L551-573

In short, we retrieve the MD5 checksum of the profile if available,
otherwise we tell LCMS to calculate it, then get it through
cmsGetHeaderProfileID.

I'll try and see what's going on once I finish with my current intray.

Best,

amyspark

On 03/03/2023 10:55, mar...@li... wrote:
> Hello,
> 
> Not sure what steps are you following, but there is currently no functionality in lcms2 to compute the MD5 of an existing profile.
> 
> The function cmsMD5computeID() computes the MD5 for a *new* profile you are creating. Which is not the same as the profile you have just open.  Please note the function does not return any hash, it just stores it in the profile header to be latter saved. The idea is to call this function before saving in the case you want to include MD5 checksum in the profile.
> 
> In your case, opening the profile "sRGB-elle-V4-srgbtrc.icc" gives a valid template in the handle that you could modify by using cmsWriteTag(). If you save this handle with cmsSaveProfileToFile(), you would obtain a new profile with same functionality but not necessarily with same layout. Maybe with some extra tags, maybe with user-defined tags stripped down. The header will be different, too. For sure creation datetime and platform could change. So, the MD5 will obviously be different and profiles remain valid, but not binary equal. This was never intended to keep same layout, nor to be a profile editor that preserves fields.
> 
> If you want a function to compute the MD5 of a yet existing profile, I could add it to 2.16, just let me know.
> 
> Regards
> Marti
> 
> 
> 
>> -----Original Message-----
>> From: L. E. Segovia via Lcms-user <lcm...@li...>
>> Sent: Thursday, March 2, 2023 4:56 PM
>> To: lcm...@li...
>> Subject: [Lcms-user] Profile ID mismatch between Linux and Windows?
>>
>> Hi all,
>>
>> We've just found something strange when getting the MD5 checksum of a
>> profile through cmsMD5computeID. Judging from Halla Rempt's test here,
>>
>> https://invent.kde.org/graphics/krita/-
>> /commit/1191295a4618a93893987497e3c54e6f0c2fd025#note_634123
>>
>> the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes depending
>> on the operating system; 84f64878faf21217362594685be031d5 is the
>> Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux hash.
>>
>> The profile is available here:
>>
>> https://invent.kde.org/graphics/krita/-
>> /blob/1191295a4618a93893987497e3c54e6f0c2fd025/libs/flake/tests/data/icc
>> /sRGB-elle-V4-srgbtrc.icc
>>
>> Or alternatively:
>>
>> https://invent.kde.org/graphics/krita/-
>> /blob/1191295a4618a93893987497e3c54e6f0c2fd025/krita/data/profiles/elles
>> -icc-profiles/sRGB-elle-V4-srgbtrc.icc
>>
>> As a verification, the sha256sum of the icc file is:
>>
>> 52d632fd6c3d2389a767a84faa0919beae6498eeb501730d170e90f0f86f594f
>> sRGB-elle-V4-srgbtrc.icc
>>
>> Please let me know if you've run into this before, if not, I'll try to debug it
>> myself during the weekend.
>>
>> Best,
>>
>> amyspark
>>
>> --
>> amyspark 🌸 https://www.amyspark.me
>>
>>
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 

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

Re: [Lcms-user] Profile ID mismatch between Linux and Windows?

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

Hello Graeme, 

As said I think is just a matter the profile binary image is different. I
tried several tools and all agree on correct MD5.
Regards
Marti

> -----Original Message-----
> From: Graeme Gill <gr...@ar...>
> Sent: Friday, March 3, 2023 1:36 PM
> To: Boudewijn Rempt via Lcms-user <lcm...@li...>
> Subject: Re: [Lcms-user] Profile ID mismatch between Linux and Windows?
> 
> L. E. Segovia via Lcms-user wrote:
> 
> > the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes
> > depending on the operating system; 84f64878faf21217362594685be031d5 is
> > the Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux
> hash.
> 
> Hmm. Using my code, I get an ICC Id of
> F1C8F4B812DE52CB4532C943C2F5FC04 for that profile.
> (I get matching Id's for V4 sample profiles from the ICC website, so there
is
>   some minimal confidence that my code is correct.)
> 
> Cheers,
> 	Graeme Gill.
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Profile ID mismatch between Linux and Windows?

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

Hello,

Not sure what steps are you following, but there is currently no functionality in lcms2 to compute the MD5 of an existing profile.

The function cmsMD5computeID() computes the MD5 for a *new* profile you are creating. Which is not the same as the profile you have just open.  Please note the function does not return any hash, it just stores it in the profile header to be latter saved. The idea is to call this function before saving in the case you want to include MD5 checksum in the profile.

In your case, opening the profile "sRGB-elle-V4-srgbtrc.icc" gives a valid template in the handle that you could modify by using cmsWriteTag(). If you save this handle with cmsSaveProfileToFile(), you would obtain a new profile with same functionality but not necessarily with same layout. Maybe with some extra tags, maybe with user-defined tags stripped down. The header will be different, too. For sure creation datetime and platform could change. So, the MD5 will obviously be different and profiles remain valid, but not binary equal. This was never intended to keep same layout, nor to be a profile editor that preserves fields.

If you want a function to compute the MD5 of a yet existing profile, I could add it to 2.16, just let me know.

Regards
Marti



> -----Original Message-----
> From: L. E. Segovia via Lcms-user <lcm...@li...>
> Sent: Thursday, March 2, 2023 4:56 PM
> To: lcm...@li...
> Subject: [Lcms-user] Profile ID mismatch between Linux and Windows?
> 
> Hi all,
> 
> We've just found something strange when getting the MD5 checksum of a
> profile through cmsMD5computeID. Judging from Halla Rempt's test here,
> 
> https://invent.kde.org/graphics/krita/-
> /commit/1191295a4618a93893987497e3c54e6f0c2fd025#note_634123
> 
> the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes depending
> on the operating system; 84f64878faf21217362594685be031d5 is the
> Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux hash.
> 
> The profile is available here:
> 
> https://invent.kde.org/graphics/krita/-
> /blob/1191295a4618a93893987497e3c54e6f0c2fd025/libs/flake/tests/data/icc
> /sRGB-elle-V4-srgbtrc.icc
> 
> Or alternatively:
> 
> https://invent.kde.org/graphics/krita/-
> /blob/1191295a4618a93893987497e3c54e6f0c2fd025/krita/data/profiles/elles
> -icc-profiles/sRGB-elle-V4-srgbtrc.icc
> 
> As a verification, the sha256sum of the icc file is:
> 
> 52d632fd6c3d2389a767a84faa0919beae6498eeb501730d170e90f0f86f594f
> sRGB-elle-V4-srgbtrc.icc
> 
> Please let me know if you've run into this before, if not, I'll try to debug it
> myself during the weekend.
> 
> Best,
> 
> amyspark
> 
> --
> amyspark 🌸 https://www.amyspark.me
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Fwd: Profile ID mismatch between Linux and Windows?

[Kai-Uwe B. <ku...@gm...>]

-------- Weitergeleitete Nachricht --------
Betreff: Re: [Lcms-user] Profile ID mismatch between Linux and Windows?
Datum: Fri, 3 Mar 2023 14:57:47 +0100
Von: Kai-Uwe Behrmann <ku...@gm...>
An: Graeme Gill <gr...@ar...>
Kopie (CC): ku...@gm...

Am 03.03.23 um 13:35 schrieb Graeme Gill:
> L. E. Segovia via Lcms-user wrote:
>
>> the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes
>> depending on the operating system; 84f64878faf21217362594685be031d5 is
>> the Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux hash.
>
> Hmm. Using my code, I get an ICC Id of F1C8F4B812DE52CB4532C943C2F5FC04
> for that profile.
> (I get matching Id's for V4 sample profiles from the ICC website, so
> there is
>   some minimal confidence that my code is correct.)
>
> Cheers,
>      Graeme Gill.

RefIccMAX and Oyranos code say as well: f1c8f4b812de52cb4532c943c2f5fc04

Re: [Lcms-user] Profile ID mismatch between Linux and Windows?

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

L. E. Segovia via Lcms-user wrote:

> the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes
> depending on the operating system; 84f64878faf21217362594685be031d5 is
> the Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux hash.

Hmm. Using my code, I get an ICC Id of F1C8F4B812DE52CB4532C943C2F5FC04 for that profile.
(I get matching Id's for V4 sample profiles from the ICC website, so there is
  some minimal confidence that my code is correct.)

Cheers,
	Graeme Gill.

[Lcms-user] Profile ID mismatch between Linux and Windows?

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

Hi all,

We've just found something strange when getting the MD5 checksum of a
profile through cmsMD5computeID. Judging from Halla Rempt's test here,

https://invent.kde.org/graphics/krita/-/commit/1191295a4618a93893987497e3c54e6f0c2fd025#note_634123

the profile 'sRGB-elle-V4-srgbtrc' results in two different hashes
depending on the operating system; 84f64878faf21217362594685be031d5 is
the Windows hash, and 133a66607cffeebdd64dd433ada9bf4e is the Linux hash.

The profile is available here:

https://invent.kde.org/graphics/krita/-/blob/1191295a4618a93893987497e3c54e6f0c2fd025/libs/flake/tests/data/icc/sRGB-elle-V4-srgbtrc.icc

Or alternatively:

https://invent.kde.org/graphics/krita/-/blob/1191295a4618a93893987497e3c54e6f0c2fd025/krita/data/profiles/elles-icc-profiles/sRGB-elle-V4-srgbtrc.icc

As a verification, the sha256sum of the icc file is:

52d632fd6c3d2389a767a84faa0919beae6498eeb501730d170e90f0f86f594f
sRGB-elle-V4-srgbtrc.icc

Please let me know if you've run into this before, if not, I'll try to
debug it myself during the weekend.

Best,

amyspark

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

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

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

Hi Marti,

Apologies for not testing sooner, but it seems some functions were added
prior to release and these weren't specified in the .def file. This
breaks build on MinGW-derived compilers because the .def takes
precedence over the cms_EXPORT if present.

A quick workaround is to remove the vs_module_defs file from the
lcms2_lib entry.

> [69/73] Linking target plugins/fast_float/src/liblcms2_fast_float.dll
> FAILED: plugins/fast_float/src/liblcms2_fast_float.dll
> "E:/krita-win/llvm-mingw-20220906-ucrt-x86_64/bin/cc.exe"  -o plugins/fast_float/src/liblcms2_fast_float.dll plugins/fast_float/src/plugins_fast_float_src_lcms2_fast_float.rc_lcms2_fast_float.o plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_16_tethra.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_curves.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_matsh.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_matsh_sse.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_tethra.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_15bits.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_15mats.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_cmyk.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_curves.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_lab.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_matsh.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_separate.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_sup.c.obj plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_tethra.c.obj "-LE:/krita-win/clang64/i_deps//lib" "-shared" "-Wl,--start-group" "-Wl,--out-implib=plugins\fast_float\src\liblcms2_fast_float.dll.a" "-Wl,--dynamicbase" "-Wl,--nxcompat" "-Wl,--disable-auto-image-base" "-Wl,--high-entropy-va" "-Wl,--image-base,0x140000000" "src\liblcms2.dll.a" "-lm" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32" "-Wl,--end-group"
> ld.lld: error: undefined symbol: _cmsOptimizePipeline
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_16_tethra.c:360
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_16_tethra.c.obj:(Optimize16BitRGBTransform)
> 
> ld.lld: error: undefined symbol: _cmsGetTransformFlags
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_16_tethra.c:126
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_16_tethra.c.obj:(PerformanceEval16)
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_8_curves.c:282
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_curves.c.obj:(FastGrayIdentity8)
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_8_curves.c:219
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_curves.c.obj:(FastEvaluateGrayCurves8)
>>>> referenced 14 more times
> 
> ld.lld: error: undefined symbol: _cmsReasonableGridpointsByColorspace
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_8_tethra.c:373
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_8_tethra.c.obj:(Optimize8BitRGBTransform)
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_float_cmyk.c:355
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_cmyk.c.obj:(OptimizeCLUTCMYKTransform)
>>>> referenced by ../ext_lcms2/plugins/fast_float/src/fast_float_tethra.c:263
>>>>               plugins/fast_float/src/liblcms2_fast_float.dll.p/fast_float_tethra.c.obj:(OptimizeCLUTRGBTransform)
> clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
> [70/73] Compiling C object testbed/testcms.exe.p/testcms2.c.obj
> ../ext_lcms2/testbed/testcms2.c:5181:16: warning: unused function 'CheckDictionary16' [-Wunused-function]
> cmsInt32Number CheckDictionary16(cmsInt32Number Pass,  cmsHPROFILE hProfile)
>                ^
> 1 warning generated.
> ninja: build stopped: subcommand failed.
> ninja: build stopped: subcommand failed.
> ERROR: Building of ext_lcms2 failed

Best,

amyspark

On 01/03/2023 10:14, mar...@li... wrote:
> 
>     Little CMS 2.15 released
> 
> I am glad to the announce the release 2.15 of the LittleCMS open source
> color engine. This is a maintenance release.
> 
>  
> 
> Changes
> 
>  
> 
>   * New MESON build system, many thanks to amispark and Lovell Fuller
>     for bringing this.      
>   * Fixed a bug that caused memory corruption on colord
>   * cmsReadRawTag can read portions of tags again. Removing this caused
>     colord to segfault when dumping profiles
>   * Added more checks based of fuzzer discoveries.
>   * MSYS2 can now compile lcms2
>   * Checked on Apple Silicon M1 and M2
>   * Fixed a bug of fastfloat plug-in that affected Krita CMYK color selector
> 
>  
> 
>  
> 
> Reach it at:
> 
> https://www.littlecms.com/color-engine/
> <https://www.littlecms.com/color-engine/>
> 
>  
> 
> Downloads:
> 
> https://sourceforge.net/projects/lcms/files/latest/download
> <https://sourceforge.net/projects/lcms/files/latest/download>
> 
>  
> 
>  
> 
> Best regards, 
> 
> Marti Maria The Little CMS project 
> https://www.littlecms.com <https://www.littlecms.com>
> 
>  
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

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

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

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

Little CMS 2.15 released


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

 

Changes

 

*	New MESON build system, many thanks to amispark and Lovell Fuller for bringing this.       
*	Fixed a bug that caused memory corruption on colord
*	cmsReadRawTag can read portions of tags again. Removing this caused colord to segfault when dumping profiles
*	Added more checks based of fuzzer discoveries.
*	MSYS2 can now compile lcms2
*	Checked on Apple Silicon M1 and M2 
*	Fixed a bug of fastfloat plug-in that affected Krita CMYK color selector

 

 

Reach it at:

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

 

Downloads:

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

 

 

Best regards, 

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

 

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

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

Hi,

Due to some issues on 2.14, I am advancing the release of 2.15 and moving the planned features to 2.16. 
There was a bug that caused memory corruption when unregistering all plug-ins from a context and then deleting the context. Unfortunately, colord was doing that sequence so whole gnome was affected by that. Also, the removal of the undocumented feature of reading portions of raw tags broke the profile dump program. 

Not only bug fixes, with this release we have now a full MESON build, with support for the plug-ins, the samples and testbeds.  Many thanks to Amyspark and Lovell Fuller for bringing this.  

The first release candidate is available here:

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

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


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