lcms-user — For users of the little cms library

[Lcms-user] odd change in 2.13

[Derek B. N. <de...@gl...>]

I'm seeing very different output in one particular case, after
upgrading from 2.12 to 2.13 (or 2.13.1).

The input profile is from a PDF file, and claims to be e-sRGB.  With
INTENT_RELATIVE_COLORIMETRIC and cmsFLAGS_BLACKPOINTCOMPENSATION, the
transform to sRGB (builtin profile) produces completely different
results.

The code looks like this (error checking and cleanup intentionally
omitted):

#include <stdio.h>
#include <lcms2.h>

int main() {
  cmsHPROFILE inputProfile = cmsOpenProfileFromFile("profile.icc", "r");
  cmsHPROFILE outputProfile = cmsCreate_sRGBProfile();
  cmsHTRANSFORM xform = cmsCreateTransform(inputProfile, TYPE_RGB_8,
					   outputProfile, TYPE_RGB_8,
					   INTENT_RELATIVE_COLORIMETRIC,
					   cmsFLAGS_BLACKPOINTCOMPENSATION);
  unsigned char in[3] = {0x61, 0x61, 0x61};
  unsigned char out[3];
  cmsDoTransform(xform, in, out, 1);
  printf("%02x %02x %02x\n", out[0], out[1], out[2]);
}

and I'm attaching the profile.

The results with 2.12 are "1e 1e 1e" and with 2.13 (same with 2.13.1)
are "9f 9f 9f".

I pulled the profile out of a PDF file, so it's possible there's a
problem in the profile itself -- but I'm not seeing any error messages
from LCMS if I use cmsSetLogErrorHandler.

If anyone has some idea of what's going on here, I'd love to know.

Thanks!

Re: [Lcms-user] Clarification about chromatic adaptation

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

Hi,

The chromatic adaptation matrix is just an informative field on what has been done on intents perceptual, relative colorimetric and saturation. It is not used when building a transform, the “true” chromatic adaptation is embedded in the colorant matrix or in the LUT.

Having said so, there is one situation where this is used. If you create a absolute colorimetric transform with observer not adapted (and only in this case!) the CMM “undoes” the chromatic adaptation of the profile using the CHAD matrix. It works to some extent, because many vendors put whatever in the CHAD and not disclose their “secret sauce”.  So in your sample, using -d0 you will get some differences. Remember in ICC 4 absolute colorimetric observer is fully adapted by default, therefore no differences on different illuminants.

Regards
Marti

> On 11 Mar 2022, at 11:37, Andrea Galligani <and...@ma...> wrote:
> 
> Hi to all,
> I realized an esperiment coping a standard profile and changing the chromatic adaptation matrix from identity to a
> Bradford D65->D50 one. I saved a D65 Lab profile using the code:
> 
> cmsHPROFILE                 hProfile   = cmsCreateLab2Profile( &D65illuminant );
> cmsSaveProfileToFile( hProfile, "LabD65.icc" );
> 
> Than I created a very simple CGATS with base pure CMYK tints and I used transicc to translate
> CMYK to Lab using this commands
> 
> transicc -iSNAP2007_D50.icc -o*Lab2 -t3 CMYK.txt CMYK_D50.txt
> 
> and
> 
> transicc -iSNAP2007_D65.icc -oLabD65.icc -t3 CMYK.txt CMYK_D65.txt
> 
> I expected different results from D50 and D65, similar to measures obtained
> measuring the printed patches under the different illuminants, but
> transicc produced almost identical results (Max DE00 0.0015).
> 
> Did I do somethink wrong?
> 
> Thanks
> Andrea
> 
> -- 
> 
> Andrea Galligani
> 
> ------------------------------------------------------------------------------
>  Macs Tech S.r.l.
> 
>    Via San Paolo, 11
>    50125 Pisa
>    Italy
> 
>      Tel: +39 050 40 915
>    email: in...@ma...
> ------------------------------------------------------------------------------
> Non stampare questa e-mail.
> 
> Avviso di confidenzialità - Questa e-mail è indirizzata esclusivamente al
> destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati,
> sono da ritenersi personali, confidenziali e riservate secondo i termini del
> vigente D.Lgs. 196/2003 in materia di privacy e del Regolamento europeo
> 679/2016 – GDPR-  e quindi ne è proibita l’utilizzazione ulteriore non
> autorizzata. Se avete ricevuto per errore questo messaggio, Vi preghiamo
> cortesemente di contattare immediatamente il mittente e cancellare la e-mail.
> Grazie.
> 
> ------------------------------------------------------------------------------
> Please don’t print this e-mail.
> 
> Confidentiality Notice – This e-mail message including any attachments is for
> the sole use of the intended recipient and may contain confidential and
> privileged information pursuant to Legislative Decree 196/2003 and the
> European General Data Protection Regulation 679/2016 – GDPR-. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy all
> copies of the original message.
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Clarification about chromatic adaptation

[Andrea G. <and...@ma...>]

Hi to all,
I realized an esperiment coping a standard profile and changing the 
chromatic adaptation matrix from identity to a
Bradford D65->D50 one. I saved a D65 Lab profile using the code:

cmsHPROFILE                 hProfile   = cmsCreateLab2Profile( 
&D65illuminant );
cmsSaveProfileToFile( hProfile, "LabD65.icc" );

Than I created a very simple CGATS with base pure CMYK tints and I used 
transicc to translate
CMYK to Lab using this commands

transicc -iSNAP2007_D50.icc -o*Lab2 -t3 CMYK.txt CMYK_D50.txt

and

transicc -iSNAP2007_D65.icc -oLabD65.icc -t3 CMYK.txt CMYK_D65.txt

I expected different results from D50 and D65, similar to measures obtained
measuring the printed patches under the different illuminants, but
transicc produced almost identical results (Max DE00 0.0015).

Did I do somethink wrong?

Thanks
Andrea

-- 

Andrea Galligani

------------------------------------------------------------------------------
   Macs Tech S.r.l.

     Via San Paolo, 11
     50125 Pisa
     Italy

       Tel: +39 050 40 915
     email: in...@ma...
------------------------------------------------------------------------------
Non stampare questa e-mail.

Avviso di confidenzialità - Questa e-mail è indirizzata esclusivamente al
destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati,
sono da ritenersi personali, confidenziali e riservate secondo i termini del
vigente D.Lgs. 196/2003 in materia di privacy e del Regolamento europeo
679/2016 – GDPR-  e quindi ne è proibita l’utilizzazione ulteriore non
autorizzata. Se avete ricevuto per errore questo messaggio, Vi preghiamo
cortesemente di contattare immediatamente il mittente e cancellare la e-mail.
Grazie.

------------------------------------------------------------------------------
Please don’t print this e-mail.

Confidentiality Notice – This e-mail message including any attachments is for
the sole use of the intended recipient and may contain confidential and
privileged information pursuant to Legislative Decree 196/2003 and the
European General Data Protection Regulation 679/2016 – GDPR-. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

------------------------------------------------------------------------------

Re: [Lcms-user] cmsReadRawTag inconsistent results.

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

Hi Phil,


> On 7 Mar 2022, at 05:07, Philip Race <phi...@or...> wrote:
> 
> I am having some trouble understanding the intent of the following comment versus what I observe:

You are right. These comments were outdated and didn’t explain what the code was doing. I have updated the file.

Thanks!

Best regards
Marti

[Lcms-user] cmsReadRawTag inconsistent results.

[Philip R. <phi...@or...>]

I am having some trouble understanding the intent of the following 
comment versus what I observe:

----------
// Read and write raw data. The only way those function would work and 
keep consistence with normal read and write
// is to do an additional step of serialization. That means, readRaw 
would issue a normal read and then convert the obtained
// data to raw bytes by using the "write" serialization logic. And 
vice-versa. I know this may end in situations where
// raw data written does not exactly correspond with the raw data 
proposed to cmsWriteRaw data, but this approach allows
// to write a tag as raw data and the read it as handled.

cmsUInt32Number CMSEXPORT cmsReadRawTag(cmsHPROFILE hProfile, 
cmsTagSignature sig, void* data, cmsUInt32Number BufferSize)

----------

To me it seems to be saying that cmsReadRawTag will *always* return the 
serialized result of a "cooked" tag - ie what
you will get after directly calling cmsReadTag(). And it does this to be 
consistent.

However the code isn't doing that because we have
     // It is already read?
     if (Icc -> TagPtrs[i] == NULL) {

         // No yet, get original position
         Offset   = Icc ->TagOffsets[i];
         TagSize  = Icc ->TagSizes[i];
...
...
}

Only if we get past that, and some other code, do we reach
-----------
     // Already read, or previously set by cmsWriteTag(). We need to 
serialize that
     // data to raw in order to maintain consistency.

     _cmsUnlockMutex(Icc->ContextID, Icc ->UsrMutex);
     Object = cmsReadTag(hProfile, sig);
     if (!_cmsLockMutex(Icc->ContextID, Icc ->UsrMutex)) return 0;

     if (Object == NULL) goto Error;

     // Now we need to serialize to a memory block: just use a memory 
iohandler
-----------

So this means that if you
1) Write a tag using cmsWriteRawTag
2) Call cmsReadRawTag() - you get back the "raw" data
3) Call cmsReadTag() - you "cook" the tag
4) Call cmsReadRawTag() - you now get back the serialized cooked data 
which may differ from (2)

as I have observed with code using the above sequence.

And this seems to me to contradict what the code comment I started with 
implies.

For clarity, regarding :-

// I know this may end in situations where
// raw data written does not exactly correspond with the raw data 
proposed to cmsWriteRaw data, but this approach allows
// to write a tag as raw data and the read it as handled.

Yes, I get that it means write and read back may differ - but I am 
seeing write and read back be inconsistent which
is what I think the comment is saying the implementation will avoid ..

-phil.

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

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

It is now fixed in git. This bug has been there since 2.10

https://github.com/mm2/Little-CMS/commit/fdbfb7694f9d7048d53674b79ddfc38068bfdaf7 <https://github.com/mm2/Little-CMS/commit/fdbfb7694f9d7048d53674b79ddfc38068bfdaf7>

A true pity, but 2.13 is already released. You can avoid the bug on the official releases by using cmsFLAGS_NOOPTIMIZE when input grayscale is being used. I guess this is not very common as the flaw has been unnoticed by years. In 2.13 is more evident because another bug was discarding channels G and B in the gray->RGB optimized transforms, anyway that was wrong too.

Regards
Marti



> 
>> On 30 Jan 2022, at 02:48, Aaron Boxer <bo...@gm...> wrote:
>> 
>> Hi Marti,
>> 
>> Thank you for this new release! I think I have found a regression, though.
>> 
>> I maintain the Grok Jpeg 2000 codec, and we use lcms2 to apply ICC profiles after
>> decompressing from JPEG 2000. 
>> 
>> The attached file file8.jp2 is a monochrome image
>> with a grayscale ICC profile.  For decompression, the codec decompresses
>> the single channel, applies the ICC profile, and then converts it to RGB 
>> (by duplicating the mono channel)
>> 
>> file8.jp2.tif is the decompressed result with the older version of lcms2.
>> file8.jp2_new.tif is the result with lcms2 2.13. You can see that the image w/ 2.13 
>> is saturating at the top of the range.
>> 
>> If you need, I can point you to the code that applies the ICC profile.
>> 
>> Let me know if I can provide any more information.
>> Thanks again,
>> Aaron
>> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

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

[Aaron B. <bo...@gm...>]

Thanks for the fix, and once again thank you for this incredible library.

On Sun, Jan 30, 2022 at 11:03 AM Marti Maria <mar...@li...>
wrote:

>
> It is now fixed in git. This bug has been there since 2.10
>
>
> https://github.com/mm2/Little-CMS/commit/fdbfb7694f9d7048d53674b79ddfc38068bfdaf7
>
> A true pity, but 2.13 is already released. You can avoid the bug on the
> official releases by using cmsFLAGS_NOOPTIMIZE when input grayscale is
> being used. I guess this is not very common as the flaw has been unnoticed
> by years. In 2.13 is more evident because another bug was discarding
> channels G and B in the gray->RGB optimized transforms, anyway that was
> wrong too.
>
> Regards
> Marti
>
>
>
>
> On 30 Jan 2022, at 02:48, Aaron Boxer <bo...@gm...> wrote:
>
> Hi Marti,
>
> Thank you for this new release! I think I have found a regression, though.
>
> I maintain the Grok Jpeg 2000 codec, and we use lcms2 to apply ICC
> profiles after
> decompressing from JPEG 2000.
>
> The attached file file8.jp2 is a monochrome image
> with a grayscale ICC profile.  For decompression, the codec decompresses
> the single channel, applies the ICC profile, and then converts it to RGB
> (by duplicating the mono channel)
>
> file8.jp2.tif is the decompressed result with the older version of lcms2.
> file8.jp2_new.tif is the result with lcms2 2.13. You can see that the
> image w/ 2.13
> is saturating at the top of the range.
>
> If you need, I can point you to the code that applies the ICC profile.
>
> Let me know if I can provide any more information.
> Thanks again,
> Aaron
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>
>

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

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

Hi Aaron,

Thanks for reporting, but unfortunately I cannot reproduce the issue. I have extracted the profile embedded in file8.jp2 and it seems a quite typical gray profile. 
Tried transicc and numbers goes fine. Also tried tificc with several combinations of the profile as input and as output and everything works as expected.
Could you please tell me details how are you doing the transform? In special, are you using the fast_float plugin?
 
Thanks again and best regards
Marti Maria

> On 30 Jan 2022, at 02:48, Aaron Boxer <bo...@gm...> wrote:
> 
> Hi Marti,
> 
> Thank you for this new release! I think I have found a regression, though.
> 
> I maintain the Grok Jpeg 2000 codec, and we use lcms2 to apply ICC profiles after
> decompressing from JPEG 2000. 
> 
> The attached file file8.jp2 is a monochrome image
> with a grayscale ICC profile.  For decompression, the codec decompresses
> the single channel, applies the ICC profile, and then converts it to RGB 
> (by duplicating the mono channel)
> 
> file8.jp2.tif is the decompressed result with the older version of lcms2.
> file8.jp2_new.tif is the result with lcms2 2.13. You can see that the image w/ 2.13 
> is saturating at the top of the range.
> 
> If you need, I can point you to the code that applies the ICC profile.
> 
> Let me know if I can provide any more information.
> Thanks again,
> Aaron
> 

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

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

I am glad  to announce the release of lcms2-2.13.

Get it here: https://sourceforge.net/projects/lcms/files/latest/download

Files kindly hosted by sourceforge


Changes

	• Added support for premultiplied alpha
	• tifficc can now handle alpha channels, both unassociated and premultiplied
	• Better documentation
	• CGATS parser can now deal with very long strings
	• Added Projects for Visual Studio 2020
	• Travis CI discontinued, GitHub actions used instead
	• Added a very preliminary meson build script (thanks to xclaesse)
	• Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
	• Added thread safe code to get time
	• Added automatic linear space detection
	• Added cmsGetStageContextID function
	• Added cmsDetectRGBProfileGamma
	• configure now accepts --without-fastfloat to turn plugin off
	• autogen.sh has now a --distclean toggle to get rid of all autotools generated files
	• Checked to work on STM32 Cortex-A, Cortex-M families
	• Bug & typos fixing (thanks to many reporters and contributors)
	• Fixed mem leaks and out-of bounds accesses as reported by fuzzer



Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com

[Lcms-user] Crafting a YCbCr profile with LittleCMS

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

Hi,

I am writing to this list in hope of getting some help for crafting 
profiles with LittleCMS. My objective is to craft a Rec.709 YCbCr to XYZ 
profile for Krita. The YCbCr -> XYZ conversion goes as this:

1. YCbCr -> normalized R'G'B. Source: Ford & Roberts (1998), eq. 105. 
<http://poynton.ca/PDFs/coloureq.pdf>

2. Normalized R'G'B -> linear RGB. Source: ITU-R BT.2087

3. Linear RGB -> XYZ. Source: Ford & Roberts (1998), eq. 102. 
<http://poynton.ca/PDFs/coloureq.pdf>


And for the XYZ -> YCbCr side of things,

1. XYZ -> Linear RGB. Source: Ford & Roberts (1998), eq. 103. 
<http://poynton.ca/PDFs/coloureq.pdf>

2. Linear RGB -> Normalized R'G'B. Source: ITU-R BT.2087

3. Normalized R'G'B -> YCbCr. Source: Ford & Roberts (1998), eq. 104. 
<http://poynton.ca/PDFs/coloureq.pdf>



My questions are as follows:

1. Are the pipelines correct? If not, what are the errors?

2. According to the ICC 4.3 standard, sections 10.10.1 and 10.11.1, to 
use the CLUT I must wrap it in two triplets of (identity) tone curves. 
But doing so simply renders the pipeline into an empty tag, so I need to 
downgrade to 2.2 and remove the tone curves from the pipeline. Why is 
this happening?



If anyone wants to check my code out, I have uploaded it at 
<https://github.com/amyspark/krita-ycbcr-profiles>. Please reply to this 
email with any questions you may have.

Best regards,

amyspark

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

Re: [Lcms-user] [Release candidate] Little CMS 2.13 is ready to be released

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

Hi,

Many thanks to all reporters. 

Please see here the release candidate two, with fixes for found glitches and memory leaks. 

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

If this candidate is ok I will proceed with the official release on end of January as expected.

Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com <http://www.littlecms.com/>



> On 7 Jan 2022, at 18:23, Marti Maria <mar...@li...> wrote:
> 
> Happy new year!
> 
> I am happy to announce the imminent release of lcms2-2.13.
> 
> The first release candidate is available here:
> 
> https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc1
> 
> Changes 
> 
> - Added support for premultiplied alpha
> - tifficc can now handle alpha channels, both unassociated and premultiplied
> - Better documentation
> - CGATS parser can now deal with very long strings
> - Added Projects for Visual Studio 2020
> - Travis CI discontinued, GitHub actions used instead
> - Added a very preliminary meson build script (thanks to xclaesse)
> - Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
> - Added thread safe code to get time
> - Added automatic linear space detection 
> - Added cmsGetStageContextID function
> - configure now accepts --without-fastfloat to turn plugin off
> - autogen.sh has now a --distclean toggle to get rid of all autotools generated files
> - Checked to work on STM32 Cortex-A, Cortex-M families
> - Bug & typos fixing (thanks to many reporters and contributors)
> 
> 
> Feel free to test it on all your products, tentative release date for final lcms2-2.13 is end of Jan-2022 Please contact me on any issue either on info { at } littecms.com <mailto:in...@li...> or using this list.
> 
> 
> Best regards
> Marti Maria
> The LittleCMS Project
> http:\www.littlecms.com <http://www.littlecms.com/>

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

[LittleCMS c. s. <in...@li...>]

Happy new year!


I am glad  to announce the imminent release of lcms2-2.13.

The first release candidate is available here:

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

(Sorry, now with the right link behind the text)


Changes 

- Added support for premultiplied alpha
- tifficc can now handle alpha channels, both unassociated and premultiplied
- Better documentation
- CGATS parser can now deal with very long strings
- Added Projects for Visual Studio 2020
- Travis CI discontinued, GitHub actions used instead
- Added a very preliminary meson build script (thanks to xclaesse)
- Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
- Added thread safe code to get time
- Added automatic linear space detection 
- Added cmsGetStageContextID function
- configure now accepts --without-fastfloat to turn plugin off
- autogen.sh has now a --distclean toggle to get rid of all autotools generated files
- Checked to work on STM32 Cortex-A, Cortex-M families
- Bug & typos fixing (thanks to many reporters and contributors)


Feel free to test it on all your products, tentative release date for final lcms2-2.13 is end of Jan-2022 Please contact me on any issue either on info { at } littecms.com <mailto:in...@li...> or using this list.


Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com <http://www.littlecms.com/>

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

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

Happy new year!

I am happy to announce the imminent release of lcms2-2.13.

The first release candidate is available here:

https://github.com/mm2/Little-CMS/releases/tag/lcms2.13rc1 <http://www.littlecms.com/lcms2-2.10rc1.tar.gz>

Changes 

- Added support for premultiplied alpha
- tifficc can now handle alpha channels, both unassociated and premultiplied
- Better documentation
- CGATS parser can now deal with very long strings
- Added Projects for Visual Studio 2020
- Travis CI discontinued, GitHub actions used instead
- Added a very preliminary meson build script (thanks to xclaesse)
- Added ARM64 target to visual studio 2019 (thanks to gaborkertesz-linaro)
- Added thread safe code to get time
- Added automatic linear space detection 
- Added cmsGetStageContextID function
- configure now accepts --without-fastfloat to turn plugin off
- autogen.sh has now a --distclean toggle to get rid of all autotools generated files
- Checked to work on STM32 Cortex-A, Cortex-M families
- Bug & typos fixing (thanks to many reporters and contributors)


Feel free to test it on all your products, tentative release date for final lcms2-2.13 is end of Jan-2022 Please contact me on any issue either on info { at } littecms.com <mailto:in...@li...> or using this list.


Best regards
Marti Maria
The LittleCMS Project
http:\www.littlecms.com <http://www.littlecms.com/>

[Lcms-user] Multi channel profiles

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

Hi all,

I'd be very interested in speaking to anyone that uses LCMS with 'high' 
numbers of color channels. (i.e. people who use LCMS with color profiles 
for higher than the usual 4 CMYK channels).

In particular, I'd be very interested in seeing a) some relevant color 
profiles, and b) some files that use those.

If you are such a person, please contact me! Probably best to do it off 
list, so we don't clog up the channel here.

Thanks in advance!

Robin

Re: [Lcms-user] Question about sRGB and rendering intent

[Aaron B. <bo...@gm...>]

Hi Marti,
Thank you, I will continue to ignore gAMMA and cHRM. I think I can get away
without an ICC profile, as I already indicate sRGB
color space in the image header. My guess is that perceptual was simply
chosen in the original file because
it equals zero, which seems to be a sane default value, even if it isn't :)
Best,
Aaron


On Tue, Sep 14, 2021 at 3:50 PM Marti Maria <mar...@li...>
wrote:

>
> Hi,
>
> My advice: just ignore gAMMA and cHRM chunks, they are just an
> approximation to sRGB space for non color-savvy readers. Embed the standard
> sRGB profile with relative colorimetric intent and this is colorimetrically
> correct and going to work in most situations.
>
> In the embedded profile you may use perceptual or relative colorimetric,
> but this indeed is an advanced topic. Please note that the image is already
> “in-gamut” so the meaning of the intent here is something completely
> different.
>
> if you use “relative colorimetric”: that means all RGB in the image have a
> direct correspondence with Lab. There is no color shifts or movements. The
> profile exactly identifies the Lab of each RGB triplet in a colorimetric
> way.
> if you use “perceptual”: That means the RGB has been tweaked to “look
> good” under whatever device the embedded profile represents. You can use
> the perceptual table A2B0 of the embedded profile to “undo” this preference
> mapping and obtain the original Lab values. Doing so may result in
> different appearance, but maybe close to the original image, whatever
> “original image” may mean.
>
> So, be careful with perceptual, as it can destroy images if you don’t know
> the gory details under the hood.
>
> Best regards
> Marti Maria.
>
>
> > On 14 Sep 2021, at 16:21, Aaron Boxer <bo...@gm...> wrote:
> >
> > Hello!
> > This question is not LCMS specific, but I figured this is a good place
> > to ask a general CMS question:
> >
> > I have a PNG image in sRGB space with sRGB chunk (perceptual rendering
> intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am
> converting this image to JPEG 2000
> > format, which does not store rendering intent information. When I
> convert, I ignore the gamma and chroma info.
> >
> > Does it make sense to convert perceptual rendering intent into an ICC
> profile for display ? JPEG 2000 is able to store ICC profiles.
> >
> > Any insight here would be greatly appreciated.
> > Thanks,
> > Aaron
> > _______________________________________________
> > Lcms-user mailing list
> > Lcm...@li...
> > https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

Re: [Lcms-user] Question about sRGB and rendering intent

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

Hi,

My advice: just ignore gAMMA and cHRM chunks, they are just an approximation to sRGB space for non color-savvy readers. Embed the standard sRGB profile with relative colorimetric intent and this is colorimetrically correct and going to work in most situations.

In the embedded profile you may use perceptual or relative colorimetric, but this indeed is an advanced topic. Please note that the image is already “in-gamut” so the meaning of the intent here is something completely different.

if you use “relative colorimetric”: that means all RGB in the image have a direct correspondence with Lab. There is no color shifts or movements. The profile exactly identifies the Lab of each RGB triplet in a colorimetric way.
if you use “perceptual”: That means the RGB has been tweaked to “look good” under whatever device the embedded profile represents. You can use the perceptual table A2B0 of the embedded profile to “undo” this preference mapping and obtain the original Lab values. Doing so may result in different appearance, but maybe close to the original image, whatever “original image” may mean.

So, be careful with perceptual, as it can destroy images if you don’t know the gory details under the hood.

Best regards
Marti Maria.


> On 14 Sep 2021, at 16:21, Aaron Boxer <bo...@gm...> wrote:
> 
> Hello!
> This question is not LCMS specific, but I figured this is a good place
> to ask a general CMS question:
> 
> I have a PNG image in sRGB space with sRGB chunk (perceptual rendering intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am converting this image to JPEG 2000
> format, which does not store rendering intent information. When I convert, I ignore the gamma and chroma info.
> 
> Does it make sense to convert perceptual rendering intent into an ICC profile for display ? JPEG 2000 is able to store ICC profiles.
> 
> Any insight here would be greatly appreciated.
> Thanks,
> Aaron 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Question about sRGB and rendering intent

[Aaron B. <bo...@gm...>]

Thanks, Noel. I have no idea how the images will eventually be viewed.
I just don't want any color management information lost when the images are
compressed.
So, since I don't know how the images will be rendered, I guess it makes
sense
to suppress the origin perceptual rendering intent.
Aaron


On Tue, Sep 14, 2021 at 11:21 AM Noel Carboni <
NCa...@pr...> wrote:

> Hi Aaron,
>
>
>
> How do you imagine these images being viewed?  Online?  On a device with a
> specific viewer application?  What has gone
>
>
>
> Not all software handles all formats or even does color management
> properly.
>
>
>
> -Noel
>
>
>
> *From:* Aaron Boxer <bo...@gm...>
> *Sent:* Tuesday, September 14, 2021 10:22 AM
> *To:* lcm...@li...
> *Subject:* [Lcms-user] Question about sRGB and rendering intent
>
>
>
> Hello!
>
> This question is not LCMS specific, but I figured this is a good place
>
> to ask a general CMS question:
>
>
>
> I have a PNG image in sRGB space with sRGB chunk (perceptual rendering
> intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am
> converting this image to JPEG 2000
>
> format, which does not store rendering intent information. When I convert,
> I ignore the gamma and chroma info.
>
>
>
> Does it make sense to convert perceptual rendering intent into an ICC
> profile for display ? JPEG 2000 is able to store ICC profiles.
>
>
>
> Any insight here would be greatly appreciated.
>
> Thanks,
>
> Aaron
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

Re: [Lcms-user] Question about sRGB and rendering intent

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

Hi Aaron,

 

How do you imagine these images being viewed?  Online?  On a device with a specific viewer application?  What has gone 

 

Not all software handles all formats or even does color management properly.

 

-Noel

 

From: Aaron Boxer <bo...@gm...> 
Sent: Tuesday, September 14, 2021 10:22 AM
To: lcm...@li...
Subject: [Lcms-user] Question about sRGB and rendering intent

 

Hello!

This question is not LCMS specific, but I figured this is a good place

to ask a general CMS question:

 

I have a PNG image in sRGB space with sRGB chunk (perceptual rendering intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am converting this image to JPEG 2000

format, which does not store rendering intent information. When I convert, I ignore the gamma and chroma info.

 

Does it make sense to convert perceptual rendering intent into an ICC profile for display ? JPEG 2000 is able to store ICC profiles.

 

Any insight here would be greatly appreciated.

Thanks,

Aaron 

[Lcms-user] Question about sRGB and rendering intent

[Aaron B. <bo...@gm...>]

Hello!
This question is not LCMS specific, but I figured this is a good place
to ask a general CMS question:

I have a PNG image in sRGB space with sRGB chunk (perceptual rendering
intent) and also gAMMA and cHRM chunks for gamma and chromaticity. I am
converting this image to JPEG 2000
format, which does not store rendering intent information. When I convert,
I ignore the gamma and chroma info.

Does it make sense to convert perceptual rendering intent into an ICC
profile for display ? JPEG 2000 is able to store ICC profiles.

Any insight here would be greatly appreciated.
Thanks,
Aaron

Re: [Lcms-user] css-color-hdr and HDR eotfs (Jzazbz and ICtCp)

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

Ok, I found the answer to my own question(s): Not yet.

All of these are being discussed on whether they'll become extensions
to ICC4 & Max:
http://www.color.org/groups/hdr/index.xalter

This also includes recommended ways of handling NCLX colorspace descriptions,
for those of us that are trying to figure out the mysteries of heif and avif.

Hope this helps,

On Wed, Feb 10, 2021 at 3:41 PM Wolthera <gri...@gm...> wrote:
>
> hey,
>
> I was reading the css-color-hdr draft [1], and it contains a few
> unusual colorspaces.
>
> Now, as far as I understand it, the only way to have an ICC spec
> conformant icc profile for Rec 2100 is by using LUTs, because the PQ
> and HLG eotfs cannot be described by the formulas in the ICC specs
> [2]. But at the least it is possible.
>
> But the draft also specifies a Jzazbz colorspace (which seems to be
> L*a*b*, except L* is replaced with the PQ-encoded Jz) as well as ICtCp
> [3].
>
> Is it possible to have icc profiles, or a littleCMS workflow for
> these? I'm not too familiar with the icc profile spec, so I don't know
> what the exact rules are for these big encompassing colorspaces, and I
> think it'd be valuable for W3C to have the feedback if these
> colorspaces are not possible for a variety of open source software.
>
> [1] - https://drafts.csswg.org/css-color-hdr/
> [2] - https://github.com/mm2/Little-CMS/issues/217
> [3] - https://en.wikipedia.org/wiki/ICtCp
> --
> Wolthera



-- 
Wolthera

[Lcms-user] css-color-hdr and HDR eotfs (Jzazbz and ICtCp)

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

hey,

I was reading the css-color-hdr draft [1], and it contains a few
unusual colorspaces.

Now, as far as I understand it, the only way to have an ICC spec
conformant icc profile for Rec 2100 is by using LUTs, because the PQ
and HLG eotfs cannot be described by the formulas in the ICC specs
[2]. But at the least it is possible.

But the draft also specifies a Jzazbz colorspace (which seems to be
L*a*b*, except L* is replaced with the PQ-encoded Jz) as well as ICtCp
[3].

Is it possible to have icc profiles, or a littleCMS workflow for
these? I'm not too familiar with the icc profile spec, so I don't know
what the exact rules are for these big encompassing colorspaces, and I
think it'd be valuable for W3C to have the feedback if these
colorspaces are not possible for a variety of open source software.

[1] - https://drafts.csswg.org/css-color-hdr/
[2] - https://github.com/mm2/Little-CMS/issues/217
[3] - https://en.wikipedia.org/wiki/ICtCp
-- 
Wolthera

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

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

Little CMS 2.12 released

I am glad to the announce the release 2.12 of the LittleCMS open source color engine.

lcms2-2.12 will add stability. Most of the new development has been done in fast float plug-in, now we have a integrated build system (a command line option in configure script) and more kernels, RGB to anything, and Lab to anything. The path “Lab to RGB” in float is specially useful. This release also recovers PDF for documentation, but at a reduced size.

Little CMS intends to be a small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard when regarding to color management. The ICC specification is widely used and is referred to in many International and other de-facto standards.

Changes:

Added build system for fast-float plugin (see plugin documentation)
Added new build-in sigmoidal tone curve
Added XCode 12 project
Added support for multichannel input up to 15 channels
Fix LUT8 write matrix
Fix version mess on 10/11
Fix tools & samples xgetopt
Fix warnings on different function pointers
Fix matlab MEX compilation
plugin: cleanup and better SSE detection
plugin: add lab to any on float
plugin: it can now be compiled as C++
recover PDF documentation, but try to keep it under a resonable size.
Prevent a rare but possible out-of-bounds read in postscript generator
Fix some compiler warnings
Add named color profile building sample to testbed

Main site: 
http://www.littlecms.com Downloads: 
http://www.littlecms.com/download.html <http://www.littlecms.com/download.html>

Best regards, 
Marti Maria The Little CMS project 
http://www.littlecms.com

[Lcms-user] [Release candidate] Release candidate 2 for 2.12 is now available (lcms2-2.12rc2)

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

Thanks to everybody for your feedback on RC1. I have published a release candidate 2 with the suggested changes. Hopefully it will become the final 2.12 in a week.

Please let me know if something is not working for you.

You can get it at:

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


Best regards
Marti Maria

Re: [Lcms-user] Named Color Profiles

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

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

Sure, here you go. Make sure to add error checking! I am adding this sample to the test bed as well.
Hope That helps
Marti

// For educational purposes ONLY. No error checking is performed!
static
void CreateNamedColorProfile(void)
{     
    // Color list database
    cmsNAMEDCOLORLIST* colors = cmsAllocNamedColorList(0, 10, 4, "PANTONE", "TCX");

    // Containers for names
    cmsMLU* DescriptionMLU, *CopyrightMLU;

    // Create an empty profile
    cmsHPROFILE hProfile = cmsOpenProfileFromFile("named.icc", "w");
    
    // Values
    cmsCIELab Lab;
    cmsUInt16Number PCS[3], Colorant[4];

    // Set profile class and so
    cmsSetProfileVersion(hProfile, 4.3);
    cmsSetDeviceClass(hProfile, cmsSigNamedColorClass);
    cmsSetColorSpace(hProfile, cmsSigCmykData);
    cmsSetPCS(hProfile, cmsSigLabData);
    cmsSetHeaderRenderingIntent(hProfile, INTENT_PERCEPTUAL);
        
    // Add description and copyright only in english/US
    DescriptionMLU = cmsMLUalloc(0, 1);
    CopyrightMLU   = cmsMLUalloc(0, 1);

    cmsMLUsetWide(DescriptionMLU, "en", "US", L"Profile description");
    cmsMLUsetWide(CopyrightMLU,   "en", "US", L"Profile copyright");

    cmsWriteTag(hProfile, cmsSigProfileDescriptionTag, DescriptionMLU);
    cmsWriteTag(hProfile, cmsSigCopyrightTag, CopyrightMLU);

    // Set the media white point
    cmsWriteTag(hProfile, cmsSigMediaWhitePointTag, cmsD50_XYZ());


    // Populate one value, Colorant = CMYK values in 16 bits, PCS[] = Encoded Lab values (in V2 format!!)
    Lab.L = 50; Lab.a = 10; Lab.b = -10;
    cmsFloat2LabEncodedV2(PCS, &Lab); 
    Colorant[0] = 10 * 257; Colorant[1] = 20 * 257; Colorant[2] = 30 * 257; Colorant[3] = 40 * 257;
    cmsAppendNamedColor(colors, "Hazelnut 14-1315", PCS, Colorant);

    // Another one. Consider to write a routine for that
    Lab.L = 40; Lab.a = -5; Lab.b = 8;
    cmsFloat2LabEncodedV2(PCS, &Lab);
    Colorant[0] = 10 * 257; Colorant[1] = 20 * 257; Colorant[2] = 30 * 257; Colorant[3] = 40 * 257;
    cmsAppendNamedColor(colors, "Kale 18-0107", PCS, Colorant);

    // Write the colors database
    cmsWriteTag(hProfile, cmsSigNamedColor2Tag, colors);

    // That will create the file
    cmsCloseProfile(hProfile);

    // Free resources
    cmsFreeNamedColorList(colors);
    cmsMLUfree(DescriptionMLU);
    cmsMLUfree(CopyrightMLU);
}

Re: [Lcms-user] [Release candidate]

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

Hi Noel,

Thank you for the testing. Is there any of those warnings that you consider should be fixed upstream? I also tried -Wall as well as static analysis but found many of those warnings are just informative about actions taken by the compiler. Adding alignment to structures for example. Compiler parser also emits warning for things like using default: on switch(), which is completely legal (and necessary!) Regarding /Qsprectre, oh, well, this is entirely generated and handled by the compiler itself, as C code knows nothing on this vulnerability. 

Regards
Marti


> On 8 Jan 2021, at 06:40, Noel Carboni <NCa...@Pr...> wrote:
> 
> Hi Marti,
>  
> I have built your version 12 RC1 code (without the fast float plug-in) into my Photoshop plug-in products and it has tested well, proving quite capable of doing all the transforms that we need.  Thanks for your ongoing work to clean up the code and make the Little CMS implementation more robust - it's literally been years since anyone's reported a color-management problem against any of our products, with Little CMS doing the color work under the covers.
>  
> FWIW because we compile with the C++ compiler and use -wAll plus the Code Analyzer, I change a few lines of your code (mostly to add explicit casts), and also we suppress several specific warning classes (/wd4061 /wd4711 /wd4774 /wd4820 /wd5045) in our version of the project. 
>  
> Examples of the above-mentioned suppressed warnings:
>  
> warning C4061: enumerator 'SBEGIN_DATA' in switch of enum 'SYMBOL' is not explicitly handled by a case label
> warning C4711: function 'unsigned short __cdecl _cmsFloat2Half(float)' selected for automatic inline expansion
> warning C4774: '_snprintf' : format string expected in argument 3 is not a string literal 
> warning C4820: '_cms_NAMEDCOLORLIST_struct': '2' bytes padding added after data member '_cms_NAMEDCOLORLIST_struct::Suffix'
> warning C5045: Compiler will insert Spectre mitigation for memory load if /Qspectre switch specified
>  
> -Noel Carboni
> ProDigital Software