lcms-user — For users of the little cms library

[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

Re: [Lcms-user] Unexpected gray to RGB result

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

Hello,

>As I am trying to make sense of it, I notice that the XYZ numbers you cited
are off by two digits. According to ICC.1:2022, chapter 6.3.4.3, they should
be:

 >> XYZ values for the PCS perceptual black point (X = 0,003357, Y =
0,003479, Z = 0,002869)

ICC PCS uses XYZ values divided by 100, so Y in white point is represented
by 1.0 instead of 100. Is just a matter of encoding.

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

-----Original Message-----
From: Ralf Junker <ral...@gm...> 
Sent: Wednesday, November 30, 2022 11:01 AM
To: lcm...@li...
Subject: Re: [Lcms-user] Unexpected gray to RGB result

On 29.11.2022 20:00, mar...@li... wrote:

 > ICC spec expects a "good" V4 perceptual profile to return "perceptual
black"
 > on darkest colorant (gray=0). This is around Lab=(3.14, 0, 0) or XYZ=(  >
0.3357, 0.3479, 0.2869).

Thanks for explaining!

As I am trying to make sense of it, I notice that the XYZ numbers you cited
are off by two digits. According to ICC.1:2022, chapter 6.3.4.3, they should
be:

 > XYZ values for the PCS perceptual black point (X = 0,003357, Y =
0,003479, Z = 0,002869)


I further noticed that lcms2.h uses slightly different values:

// V4 perceptual black
#define cmsPERCEPTUAL_BLACK_X  0.00336
#define cmsPERCEPTUAL_BLACK_Y  0.0034731 #define cmsPERCEPTUAL_BLACK_Z
0.00287

https://github.com/mm2/Little-CMS/blob/caab4c07e60022a0f776b543eaa30785e2bb4
2ed/include/lcms2.h#L280-L283


I also noticed that src/cmscam02.c contains the floating-point literal
3.141592654 three times, all of which could probably be replaced by M_PI for
clarity, simplicity and accuracy.

Ralf


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

Re: [Lcms-user] Unexpected gray to RGB result

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

On 30/11/2022 10:01, Ralf Junker wrote:
> https://github.com/mm2/Little-CMS/blob/caab4c07e60022a0f776b543eaa30785e2bb42ed/include/lcms2.h#L280-L283
> 
> I also noticed that src/cmscam02.c contains the floating-point literal
> 3.141592654 three times, all of which could probably be replaced by M_PI
> for clarity, simplicity and accuracy.

This would also guard us against the possibility of PI changing in future.

Robin

Re: [Lcms-user] Unexpected gray to RGB result

[Ralf J. <ral...@gm...>]

On 29.11.2022 20:00, mar...@li... wrote:

 > ICC spec expects a "good" V4 perceptual profile to return "perceptual
black"
 > on darkest colorant (gray=0). This is around Lab=(3.14, 0, 0) or XYZ=(
 > 0.3357, 0.3479, 0.2869).

Thanks for explaining!

As I am trying to make sense of it, I notice that the XYZ numbers you
cited are off by two digits. According to ICC.1:2022, chapter 6.3.4.3,
they should be:

 > XYZ values for the PCS perceptual black point (X = 0,003357, Y =
0,003479, Z = 0,002869)


I further noticed that lcms2.h uses slightly different values:

// V4 perceptual black
#define cmsPERCEPTUAL_BLACK_X  0.00336
#define cmsPERCEPTUAL_BLACK_Y  0.0034731
#define cmsPERCEPTUAL_BLACK_Z  0.00287

https://github.com/mm2/Little-CMS/blob/caab4c07e60022a0f776b543eaa30785e2bb42ed/include/lcms2.h#L280-L283


I also noticed that src/cmscam02.c contains the floating-point literal
3.141592654 three times, all of which could probably be replaced by M_PI
for clarity, simplicity and accuracy.

Ralf

Re: [Lcms-user] Did X-Rite use LCMS?

[Christian S. <rea...@mo...>]

> Am 30.11.2022 um 03:41 schrieb Kang Wei Hsu <beb...@gm...>:
> 
> Just found there is a "CORE_RL_lcms_.dll" in the i1Profiler folder. And there are jpeg, libxml, magick, png and tiff .dll files. Other .dll files are obviously dependent libraries that i1Profiler uses. Does that mean X-Rite uses LCMS as i1Profiler's color engine? X-Rite always claimed they use their own i1Prism color engine. I'm just curious.

Please note that GraphicsMagick library comes with CORE_RL_lcms_.dll included.
So if they use GraphicsMagick to load images, it includes LCMS.

e.g. DLLs in the GraphicsMagick package:

CORE_RL_bzlib_.dll
CORE_RL_zlib_.dll
CORE_RL_xlib_.dll
CORE_RL_wmf_.dll
CORE_RL_webp_.dll
CORE_RL_wand_.dll
CORE_RL_ttf_.dll
CORE_RL_tiff_.dll
CORE_RL_png_.dll
CORE_RL_Magick++_.dll
CORE_RL_magick_.dll
CORE_RL_libxml_.dll
CORE_RL_lcms_.dll
CORE_RL_jpeg_.dll
CORE_RL_jp2_.dll
CORE_RL_jbig_.dll
CORE_RL_filters_.dll
CORE_RL_coders_.dll

Best regards,
Christian

-- 
Read our blog about news on our plugins:

http://www.mbsplugins.de/