lcms-user — For users of the little cms library

[Lcms-user] Lab to RGB conversion

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

Hello!
This isn't strictly an lcms question, but I was wondering if anyone here
can give me some insight into a few lines of code I've inherited in my
project that use
lcms to convert Lab to RGB:

https://github.com/GrokImageCompression/grok/blob/master/src/bin/common/color.cpp#L742

This code works for 8 bit Lab but not for 16 bit and I am trying to fix
this. I am particularly wondering about the three constants 100, 170 and
200.

Any insight would be greatly appreciated.
Thanks!
Aaron

Re: [Lcms-user] [SPAM] Re: Bug in soft proofing?

[Boudewijn R. <bo...@va...>]

Would it be technically possible to create another icc profile that does some pre- or post-correction to work around this profile's bugs? It seems it's pretty widely used and recommended, for some weird reason.

On zaterdag 7 december 2019 21:49:10 CET Mar...@li... wrote:
> 
> Quoting Wolthera <gri...@gm...>:
> 
> > Hey,
> >
> > So, the person who made that bugreport, David Revoy, has tried to use
> > the profile because the printing company requested it of him, with
> > terrible results:
> > https://www.davidrevoy.com/article747/the-english-book-printed-project-production-report-2#c0747-1890
> >
> > So, what is going on here that even though the profile is borked,
> > indesign is showing a proper proof(perhaps due to using a different
> > table? Bizare that photoshop then acts weirdly...).
> 
> In the thread you mention, there are other people that found the  
> profile to be buggy in photoshop. So, I have further investigated this  
> profile, and found the source of problems on the B2A1 table, that is,  
> the relative colorimetric proofing direction. It is broken. It seems  
> to me that it is implementing some sort of absolute colorimetric,  
> which would be emulating the paper white. Some products of Adobe "hot  
> fixes" this profile, when used as softproof, but this is just hidding  
> the profile error, which is something that lcms does not.
> 
> You can also try the icc profile inspector available in the ICC site  
> (www.color.org) If you take a look on the rel.col table (B2A1), the  
> output curves seems a little bit off when compared with the perceptual  
> table (B2A0) which is correct.
> 
> > And that in turn affects users because they just cannot follow the
> > printing company's instructions faithfully: everything looks weird in
> > LCMS running software. Is there something we can do to smooth this
> > out?
> 
> I would try to either to found another profile that represenst the  
> standard, or to build one by using argyll and the measurement set  
> available on ICC site. See below:
> 
> http://www.argyllcms.com
> http://www.npes.org/Portals/0/standards/docs/CGATS21-2-CRPC1.txt
> 
> 
> Regards
> Marti Maria
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 


-- 
https://www.valdyas.org | https://www.krita.org

Re: [Lcms-user] [SPAM] Re: Bug in soft proofing?

[<Mar...@li...>]

Quoting Wolthera <gri...@gm...>:

> Hey,
>
> So, the person who made that bugreport, David Revoy, has tried to use
> the profile because the printing company requested it of him, with
> terrible results:
> https://www.davidrevoy.com/article747/the-english-book-printed-project-production-report-2#c0747-1890
>
> So, what is going on here that even though the profile is borked,
> indesign is showing a proper proof(perhaps due to using a different
> table? Bizare that photoshop then acts weirdly...).

In the thread you mention, there are other people that found the  
profile to be buggy in photoshop. So, I have further investigated this  
profile, and found the source of problems on the B2A1 table, that is,  
the relative colorimetric proofing direction. It is broken. It seems  
to me that it is implementing some sort of absolute colorimetric,  
which would be emulating the paper white. Some products of Adobe "hot  
fixes" this profile, when used as softproof, but this is just hidding  
the profile error, which is something that lcms does not.

You can also try the icc profile inspector available in the ICC site  
(www.color.org) If you take a look on the rel.col table (B2A1), the  
output curves seems a little bit off when compared with the perceptual  
table (B2A0) which is correct.

> And that in turn affects users because they just cannot follow the
> printing company's instructions faithfully: everything looks weird in
> LCMS running software. Is there something we can do to smooth this
> out?

I would try to either to found another profile that represenst the  
standard, or to build one by using argyll and the measurement set  
available on ICC site. See below:

http://www.argyllcms.com
http://www.npes.org/Portals/0/standards/docs/CGATS21-2-CRPC1.txt


Regards
Marti Maria

Re: [Lcms-user] [SPAM] Re: Bug in soft proofing?

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

Hey,

So, the person who made that bugreport, David Revoy, has tried to use
the profile because the printing company requested it of him, with
terrible results:
https://www.davidrevoy.com/article747/the-english-book-printed-project-production-report-2#c0747-1890

So, what is going on here that even though the profile is borked,
indesign is showing a proper proof(perhaps due to using a different
table? Bizare that photoshop then acts weirdly...).

And that in turn affects users because they just cannot follow the
printing company's instructions faithfully: everything looks weird in
LCMS running software. Is there something we can do to smooth this
out?

Pepper and Carrot is CC-BY licensed, and David has all the files
available on his website, so there's plenty of material to test
against. The real question is what is going on and how to solve it.

On Sat, Oct 12, 2019 at 5:52 PM Boudewijn Rempt via Lcms-user
<lcm...@li...> wrote:
>
> Thanks for the answer! I guess the profile is just broken then :-)
>
> On zaterdag 12 oktober 2019 17:49:29 CEST Marti Maria wrote:
> > Hi, nice to hear from you.
> >
> >
> > Regarding the issue, I've checked the profile with photoshop and also got weird results, so chances are the a2b1 proof table is not correct in this profile.
> >
> >
> > Softproofing is performed in lcms by two steps. In first step the image is converted to the target colorspace using the settings the user wish, bpc rendering intent, etc. Once we have the image in the desired colorspace, we measure the lab values of the colors. To do so, we use relative colorimetric (i.e., no gamut remapping) in the reverse direction. This is encoded in the profile as the a2b1 table and is often called the "proofing" table. This is different from using the reverse table of perceptual a2b0, which "undoes" gamut mapping to display the image. So, tables may be diffeent on certain profiles.
> > This could explain the differences you see.
> >
> >
> > Regards
> > Marti
> >
> >
> >
> >
> >
> >
> > On 8 Oct 2019 11:42, Boudewijn Rempt via Lcms-user <lcm...@li...> wrote:
> >
> >
> > Hi,
> >
> >
> > We recently received this bug report: https://bugs.kde.org/show_bug.cgi?id=412604 "CGATS21_CRPC1.icc has a different rendering between softproofed and converted".
> >
> >
> > As its summary says, if you use the profile provided in the bug report for soft-proofing, the rendering is different than when you use it when converting to CMYK. Because GIMP and Scribus have the same behaviour, I'm wondering whether this could be a problem in LCMS?
> >
> >
>
>
> --
> Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org_______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user



-- 
Wolthera

[Lcms-user] Postcript CIEBasedA, CIEBasedABC, CIEBasedDEF, CIEBasedDEFG conversion into ICC color space

[Moin Salah-ud-D. <moi...@gm...>]

Hi,

I am new in this domain, I have an issue to transform Postscript CIE-Based
Color Spaces into ICC color spaces. I found that Little CMS provides
support to convert the ICC into  Postscript CIE-Based Color Spaces but
didn't any method to convert it other way around.

May you help me or guide me how can I transform this information

Thanks in advance for your help.

---
Best Regards
Moin Salah-ud-Din

Re: [Lcms-user] [SPAM] Re: Bug in soft proofing?

[Boudewijn R. <bo...@va...>]

Thanks for the answer! I guess the profile is just broken then :-)

On zaterdag 12 oktober 2019 17:49:29 CEST Marti Maria wrote:
> Hi, nice to hear from you.
> 
> 
> Regarding the issue, I've checked the profile with photoshop and also got weird results, so chances are the a2b1 proof table is not correct in this profile.
> 
> 
> Softproofing is performed in lcms by two steps. In first step the image is converted to the target colorspace using the settings the user wish, bpc rendering intent, etc. Once we have the image in the desired colorspace, we measure the lab values of the colors. To do so, we use relative colorimetric (i.e., no gamut remapping) in the reverse direction. This is encoded in the profile as the a2b1 table and is often called the "proofing" table. This is different from using the reverse table of perceptual a2b0, which "undoes" gamut mapping to display the image. So, tables may be diffeent on certain profiles. 
> This could explain the differences you see.
> 
> 
> Regards
> Marti
> 
> 
> 
> 
> 
> 
> On 8 Oct 2019 11:42, Boudewijn Rempt via Lcms-user <lcm...@li...> wrote:
> 
> 
> Hi,
> 
> 
> We recently received this bug report: https://bugs.kde.org/show_bug.cgi?id=412604 "CGATS21_CRPC1.icc has a different rendering between softproofed and converted".
> 
> 
> As its summary says, if you use the profile provided in the bug report for soft-proofing, the rendering is different than when you use it when converting to CMYK. Because GIMP and Scribus have the same behaviour, I'm wondering whether this could be a problem in LCMS?
> 
> 


-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

[Lcms-user] [SPAM] Re: Bug in soft proofing?

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

<div dir='auto'><div>Hi, nice to hear from you.</div><div dir="auto"><br></div><div dir="auto">Regarding the issue, I've checked the profile with photoshop and also got weird results, so chances are the a2b1 proof table is not correct in this profile.</div><div dir="auto"><br></div><div dir="auto">Softproofing is performed in lcms by two steps. In first step the image is converted to the target colorspace using the settings the user wish, bpc rendering intent, etc. Once we have the image in the desired colorspace, we measure the lab values of the colors. To do so, we use relative colorimetric (i.e., no gamut remapping) in the reverse direction. This is encoded in the profile as the a2b1 table and is often called the "proofing" table. This is different from using the reverse table of perceptual a2b0, which "undoes" gamut mapping to display the image. So, tables may be diffeent on certain profiles.&nbsp;</div><div dir="auto">This could explain the differences you see.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Marti</div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 8 Oct 2019 11:42, Boudewijn Rempt via Lcms-user &lt;lcm...@li...&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,
<br>

<br>
We recently received this bug report: https://bugs.kde.org/show_bug.cgi?id=412604 "CGATS21_CRPC1.icc has a different rendering between softproofed and converted".
<br>

<br>
As its summary says, if you use the profile provided in the bug report for soft-proofing, the rendering is different than when you use it when converting to CMYK. Because GIMP and Scribus have the same behaviour, I'm wondering whether this could be a problem in LCMS?
<br>
-- 
<br>
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org</p>
<p dir="ltr">_______________________________________________
<br>
Lcms-user mailing list
<br>
Lcm...@li...
<br>
https://lists.sourceforge.net/lists/listinfo/lcms-user
<br>
</p>
</blockquote></div><br></div></div></div>

Re: [Lcms-user] Bug in soft proofing?

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

I wanted to add to this that I previously did mail about this issue in
Krita, but then Real Life happened, and I was unable to answer. So I
am going to outline the color management er... 'pipeline' within
Krita(Cannot speak for GIMP and Scribus).

Say we have a situation where we have an Image profile, a CMYK profile
and a Display profile. When we're using conversion (which gives the
correct result), we're going from

Image profile -> Display Profile

Where the rendering intent and blackpoint compensation is configurable
by the user. The user then converts, where they too can configure the
rendering intent and BPC, leading to.

Image Profile -> CMYK Profile.
CMYK Profile(The new image profile) -> Display Profile.

Now for softproofing, we have the following:

Image Profile -> CMYK Profile -> Display Profile.

The rendering intent and bpc is the same for both transforms(and
configured by the user), which may not be strictly correct. However,
even when we set up the configuration so that the conversion pipeline
and the softproofing pipeline use the exact same configuration, the
softproofing result looks faded compared to the conversion result.

I hope this helps figuring out what is going on.

-- 
Wolthera

[Lcms-user] Bug in soft proofing?

[Boudewijn R. <bo...@va...>]

Hi,

We recently received this bug report: https://bugs.kde.org/show_bug.cgi?id=412604 "CGATS21_CRPC1.icc has a different rendering between softproofed and converted".

As its summary says, if you use the profile provided in the bug report for soft-proofing, the rendering is different than when you use it when converting to CMYK. Because GIMP and Scribus have the same behaviour, I'm wondering whether this could be a problem in LCMS?
-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: [Lcms-user] Missing PCS black point adjustment for perceptual transforms between version-2 and version-4 profiles (and vice versa)?

[Maurice L. <mau...@gm...>]

Hi Marti,

Thank you for your quick reply again.

Completely avoiding V2 is still difficult these days, given that many
standard profiles are still V2 (e.g. AdobeRGB and the various offset
standard profiles for GRACoL and Fogra).

In my experience with other CMMs (ACE, SampleICC) these version-2 to
version-4 (and vice versa) perceptual black point conversions are
automatically handled without having to enable BPC, so I expected LCMS2 to
do that as well.
Anyway, I now realize that I can change the behavior myself using a plugin,
if I would need to.
I'm still in the process of getting familiar with LCMS2...

With kind regards,
Maurice

Op vr 4 okt. 2019 om 15:48 schreef <Mar...@li...>:

>
>
> Hello,
>
> You should activate black point compensation when mixing V4 and V2
> profiles on perceptual or saturation intents.
>
> In some cases, lcms detects the situation and performs BPC
> automatically, for example V2->V4, this is a common case
>   of embedded profiles. On others scenarios, like V4->V2, you need to
> explicitly set the BPC flag. This is because some V2 printer profiles
> are broken on black point, so making the detection automatic would
> prevent any operation with those profiles.
>
> Anyway your best option is avoid V2 entirely, those are really
> outdated (even V4 is actually outdated!) and many are buggy.
>
> For lcms keeping some compatibility is on, but this is low in the
> priorities.
>
> I tried your sample activating BPC and works as expected.
> Regards
> Marti.
>
> Quoting Maurice Luttmer <mau...@gm...>:
>
> > Hi,
> >
> > I've been looking through the internals of LCMS2, in particular function
> > DefaultICCintents() which converts the array of profiles, intents etc.
> into
> > a cmsPipeline.
> >
> > But I'm a bit puzzled, since I would expect to see a conversion being
> > introduced in case of a transformation with a perceptual rendering intent
> > between a version-2 profile and a version-4 profile (or vice versa) in
> > order to handle the difference in PCS black points of version-2 and
> > version-4 profiles.
> >
> > In order to verify this, I did a test with a floating point conversion of
> > RGB (0, 0, 0) from the version-4 sRGB_v4_ICC_preference.icc profile to
> the
> > version-2 sRGB2014.icc profile (and I multiplied the output values by
> 255).
> >
> > If everything is fine, I would expect the result to also have RGB = (0,
> 0,
> > 0).
> > If there is a black point mismatch, I would expect the RGB value to
> > correspond to the version-4 black point (which has a lightness of about
> > 3.1).
> > The resulting RGB value (times 255) that I got was (11.311, 11.311,
> > 11.311), which indeed corresponds to the lightness of the version-4 PCS
> > black point.
> >
> > This suggests that adjustments between the version-2 and version-4
> > perceptual PCS black points (and vice versa) are indeed missing.
> > Or am I misunderstanding something?
> >
> > With kind regards,
> > Maurice
>
>
>

Re: [Lcms-user] Missing PCS black point adjustment for perceptual transforms between version-2 and version-4 profiles (and vice versa)?

[<Mar...@li...>]

Hello,

You should activate black point compensation when mixing V4 and V2  
profiles on perceptual or saturation intents.

In some cases, lcms detects the situation and performs BPC  
automatically, for example V2->V4, this is a common case
  of embedded profiles. On others scenarios, like V4->V2, you need to  
explicitly set the BPC flag. This is because some V2 printer profiles  
are broken on black point, so making the detection automatic would  
prevent any operation with those profiles.

Anyway your best option is avoid V2 entirely, those are really  
outdated (even V4 is actually outdated!) and many are buggy.

For lcms keeping some compatibility is on, but this is low in the priorities.

I tried your sample activating BPC and works as expected.
Regards
Marti.

Quoting Maurice Luttmer <mau...@gm...>:

> Hi,
>
> I've been looking through the internals of LCMS2, in particular function
> DefaultICCintents() which converts the array of profiles, intents etc. into
> a cmsPipeline.
>
> But I'm a bit puzzled, since I would expect to see a conversion being
> introduced in case of a transformation with a perceptual rendering intent
> between a version-2 profile and a version-4 profile (or vice versa) in
> order to handle the difference in PCS black points of version-2 and
> version-4 profiles.
>
> In order to verify this, I did a test with a floating point conversion of
> RGB (0, 0, 0) from the version-4 sRGB_v4_ICC_preference.icc profile to the
> version-2 sRGB2014.icc profile (and I multiplied the output values by 255).
>
> If everything is fine, I would expect the result to also have RGB = (0, 0,
> 0).
> If there is a black point mismatch, I would expect the RGB value to
> correspond to the version-4 black point (which has a lightness of about
> 3.1).
> The resulting RGB value (times 255) that I got was (11.311, 11.311,
> 11.311), which indeed corresponds to the lightness of the version-4 PCS
> black point.
>
> This suggests that adjustments between the version-2 and version-4
> perceptual PCS black points (and vice versa) are indeed missing.
> Or am I misunderstanding something?
>
> With kind regards,
> Maurice

[Lcms-user] Missing PCS black point adjustment for perceptual transforms between version-2 and version-4 profiles (and vice versa)?

[Maurice L. <mau...@gm...>]

Hi,

I've been looking through the internals of LCMS2, in particular function
DefaultICCintents() which converts the array of profiles, intents etc. into
a cmsPipeline.

But I'm a bit puzzled, since I would expect to see a conversion being
introduced in case of a transformation with a perceptual rendering intent
between a version-2 profile and a version-4 profile (or vice versa) in
order to handle the difference in PCS black points of version-2 and
version-4 profiles.

In order to verify this, I did a test with a floating point conversion of
RGB (0, 0, 0) from the version-4 sRGB_v4_ICC_preference.icc profile to the
version-2 sRGB2014.icc profile (and I multiplied the output values by 255).

If everything is fine, I would expect the result to also have RGB = (0, 0,
0).
If there is a black point mismatch, I would expect the RGB value to
correspond to the version-4 black point (which has a lightness of about
3.1).
The resulting RGB value (times 255) that I got was (11.311, 11.311,
11.311), which indeed corresponds to the lightness of the version-4 PCS
black point.

This suggests that adjustments between the version-2 and version-4
perceptual PCS black points (and vice versa) are indeed missing.
Or am I misunderstanding something?

With kind regards,
Maurice

Re: [Lcms-user] First experiments with LCMS2

[Maurice L. <mau...@gm...>]

Hi Marti,

Thank you very much for the quick response and the fix.

With kind regards,
Maurice

Op do 3 okt. 2019 om 11:03 schreef <Mar...@li...>:

>
>
> > When looking at the resulting input profile in ICC Profile Inspector I
> see
> > that the resulting profile is a version-2.4 profile (as requested) with
> > linear (out = in) input and output channels (consisting of 2 points
> each, 0
> > and 65535), which is fine.
> >
> > But the value of the first CLUT entry (for CMYK = (0, 0, 0, 0)) is equal
> to
> > (65535, 32896, 32896), which is the version-4 encoding for Lab (100, 0,
> 0).
> >
> > It should have been (65280, 32768, 32768) which is the version-2 encoding
> > for Lab = (100, 0, 0).
>
>
> Hi, thanks for reporting. This is actually a bug, which I have already
> fixed in github. If you want to modify your sources directly, in
> cmsvirt.c, you need to add this:
>
>   if ((xform ->ExitColorSpace) == cmsSigLabData && (Version < 4.0)) {
>
>          dwFlags |= cmsFLAGS_NOWHITEONWHITEFIXUP;
>          if (!cmsPipelineInsertStage(LUT, cmsAT_END,
> _cmsStageAllocLabV4ToV2(ContextID)))
>              goto Error;
>
> Which fixes this special case.
>
> Regarding the other case you report, media white, the code has no idea
> on which is the media white point when you are building input profiles
> by chaining. Actually it takes it from the first profile, which seems
> reasonable in many cases.
> On the other hand, many V2 devicelink profiles does not use any media
> white at all, so if you use a devicelink as the first profile you
> probably will end in D50 as media white.
> In V4 workflows, this is not so terrible at all, since media white is
> not used anymore, even V4 absolute colorimetric is assuming fully
> adapted observers.
>
> Best regards
> Marti
>
>

Re: [Lcms-user] First experiments with LCMS2

[<Mar...@li...>]

> When looking at the resulting input profile in ICC Profile Inspector I see
> that the resulting profile is a version-2.4 profile (as requested) with
> linear (out = in) input and output channels (consisting of 2 points each, 0
> and 65535), which is fine.
>
> But the value of the first CLUT entry (for CMYK = (0, 0, 0, 0)) is equal to
> (65535, 32896, 32896), which is the version-4 encoding for Lab (100, 0, 0).
>
> It should have been (65280, 32768, 32768) which is the version-2 encoding
> for Lab = (100, 0, 0).


Hi, thanks for reporting. This is actually a bug, which I have already  
fixed in github. If you want to modify your sources directly, in  
cmsvirt.c, you need to add this:

  if ((xform ->ExitColorSpace) == cmsSigLabData && (Version < 4.0)) {

         dwFlags |= cmsFLAGS_NOWHITEONWHITEFIXUP;
         if (!cmsPipelineInsertStage(LUT, cmsAT_END,  
_cmsStageAllocLabV4ToV2(ContextID)))
             goto Error;

Which fixes this special case.

Regarding the other case you report, media white, the code has no idea  
on which is the media white point when you are building input profiles  
by chaining. Actually it takes it from the first profile, which seems  
reasonable in many cases.
On the other hand, many V2 devicelink profiles does not use any media  
white at all, so if you use a devicelink as the first profile you  
probably will end in D50 as media white.
In V4 workflows, this is not so terrible at all, since media white is  
not used anymore, even V4 absolute colorimetric is assuming fully  
adapted observers.

Best regards
Marti

[Lcms-user] First experiments with LCMS2

[Maurice L. <mau...@gm...>]

Hi,



I'm new to LittleCMS2 and I'm impressed. But my first test did reveal two
issues.



I used linkicc to create a CMYK input profile as follows:



linkicc -o DevLink2PSOcoated_v3.icc -t1 -n17 -x -r2.4 DevLink.icc
PSOcoated_v3.icc



The DevLink2PSOcoated_v3.icc profile is a CMYK to CMYK ICC version-2
DeviceLink profile (which maps CMYK (0, 0, 0, 0) to CMYK (0, 0, 0, 0)) and
the PSOcoated_v3.icc profile is a CMYK to Lab ICC version-2 Printer profile
(Fogra-51).



When looking at the resulting input profile in ICC Profile Inspector I see
that the resulting profile is a version-2.4 profile (as requested) with
linear (out = in) input and output channels (consisting of 2 points each, 0
and 65535), which is fine.

But the value of the first CLUT entry (for CMYK = (0, 0, 0, 0)) is equal to
(65535, 32896, 32896), which is the version-4 encoding for Lab (100, 0, 0).

It should have been (65280, 32768, 32768) which is the version-2 encoding
for Lab = (100, 0, 0).



The reason for this is that FixWhiteMisalignment() in cmsopt.c "fixes" the
first value in the CLUT from its correct version-2 encoded Lab value to the
version-4 encoded Lab value, which it got from _cmsEndPointsBySpace() for
the output Lab color space.

This is clearly not the intended behavior.



Another issue with the resulting input profile is that the
mediaWhitePointTag is set to the D50 white point instead of to the white
point of the PSOcoated_v3.icc profile.
This is because cmsCreateExtendedTransform() sets the EntryWhitePoint of
the transform to the white point of the first profile in the chain of
profiles (but since a DeviceLink profile does't have a white point tag, it
is set to the D50 white point).

Then, since we are creating an input profile, cmsTransform2DeviceLink()
sets the mediaWhitePointTag of the profile to the EntryWhitePoint.



I understand that, in general, choosing the correct mediaWhitePoint for the
resulting input profile is non-trivial. But it would be nice if the simpler
cases, like the one presented here, could be handled correctly.



With kind regards,

Maurice

[Lcms-user] Heuristics for badly-encoded profileDescriptionTag

[Tomalak Geret'k. <to...@ke...>]

 

Greetings, 

I've encountered more than a few ICC profiles which seem to be
malformed, in the sense that they only store the Profile Description in
the 7-bit ASCII part of profileDescriptionTag (§6.4.27), despite there
being high bits set in the name. 

For example, "SWOP (couché), 20%" or "LG HDR 4K-". 

In the profiles I'm looking at, the former appears to be Mac Roman
encoded (and is accompanied by a PrimaryPlatform of "APPL"), whereas the
latter appears to be Codepage 1252 (or compatible) encoded (and is
accompanied by a PrimaryPlatform of "MSFT"). 

When using cmsGetProfileInfo, littlecms is correctly finding that there
is no Unicode localisation and gives me the "ASCII" version in a
wchar_t[]. However, as mentioned, it's not actually ASCII and there's no
way to know what the encoding should be. 

This is not littlecms's fault; it's a spec violation. However it's
common enough that I was wondering whether some heuristics could be
added: in the case that only an "ASCII" variant is present, ignore the
fact that the spec requires 7-bit and try to interpret the name in some
codepage, based on the PrimaryPlatform. This would then be transcoded to
UTF-16 (or whatever the native wide-char encoding is, I guess) for the
result of cmsGetProfileInfo, and the calling scope would not need to
worry about the fact that it has no idea what encoding some malformed
Profile Description is in. We'd be more likely to get the "right"
result. 

This is a long shot, I know, but would the team be interested in
something like this? Or are "dirty hacks" for bad files totally frowned
upon in this project? 

Cheers :)
Tom 
  

Re: [Lcms-user] Missing cmsFLAGS_COPY_ALPHA documentation

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

<div dir='auto'>Thanks for pointing out,. Yes the documentation needs some updating. I will try to make a new release when possible.<div dir="auto"><br><div dir="auto">Regards</div><div dir="auto">Marti</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">El 5 sept. 2019 17:50, Wolthera &lt;gri...@gm...&gt; escribió:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,&#13;<br>
&#13;<br>
It seems that cmsFLAGS_COPY_ALPHA, which was introduced in 2.8 isn't&#13;<br>
actually included in the API documentation. Could this be added?&#13;<br>
&#13;<br>
-- &#13;<br>
Wolthera&#13;<br>
&#13;<br>
&#13;<br>
_______________________________________________&#13;<br>
Lcms-user mailing list&#13;<br>
Lcm...@li...&#13;<br>
https://lists.sourceforge.net/lists/listinfo/lcms-user&#13;<br>
</p>
</blockquote></div><br></div>

[Lcms-user] Missing cmsFLAGS_COPY_ALPHA documentation

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

Hi,

It seems that cmsFLAGS_COPY_ALPHA, which was introduced in 2.8 isn't
actually included in the API documentation. Could this be added?

-- 
Wolthera

Re: [Lcms-user] General question about CIE Lab and TIFF

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

Thanks, Mark! I will try that, also will post a code snippet of the current
conversion- would rather use lcms
to do the conversion.

On Wed, Aug 21, 2019 at 7:44 PM Mark Allen <m.f...@pl...> wrote:

> I’ve had experience with old image file formats like TIFF but I’m just a
> LittleCMS user. So I don’t know the insides of LittleCMS and I'm not a
> color management expert. But my guesses follow... Keep in mind they're just
> guesses and you're probably better off spending some serious time with the
> LittleCMS documentation.
>
>
> >>Is it possible with lcms to extract the illuminant and Lab range from
> the ICC
> I haven't seen anything regarding a range of values in LittleCMS but I
> don't know every nook and cranny of it. I'd think you'd just have to write
> your own code to check the pixel values. LittleCMS has routines which can
> read ICC tags for you but I'm not knowledgeable enough to know which one(s)
> you want. I'd personally use LittleCMS to set up for a color conversion and
> follow the code in the debugger and watch the part where it figures it out.
> LittleCMS certainly knows how to do it. It may involve this routine:
> _cmsReadMediaWhitePoint but I don't really know the insides of LittleCMS.
> I'd follow it in the debugger once to make sure you get the right result.
> I’d just do what it does. I don’t see a public routine which does it for
> you but I may have missed it.
>
>
> >>And vice-versa, when decompressing custom CIE, can I convert an
> illumanant with Lab range into an ICC profile?
> These create LAB ICC profiles with a white point:
>
> cmsHPROFILE cmsCreateLab2Profile(const cmsCIExyY* WhitePoint);
> cmsHPROFILE cmsCreateLab4Profile(const cmsCIExyY* WhitePoint);
>
> LittleCMS can write that profile to a stream or write it to a file for you
> so you can create an ICC profile. I'm not sure what J2K is after with the
> range part.
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

Re: [Lcms-user] General question about CIE Lab and TIFF

[Mark A. <m.f...@pl...>]

I’ve had experience with old image file formats like TIFF but I’m just a LittleCMS user. So I don’t know the insides of LittleCMS and I'm not a color management expert. But my guesses follow... Keep in mind they're just guesses and you're probably better off spending some serious time with the LittleCMS documentation.


>>Is it possible with lcms to extract the illuminant and Lab range from the ICC
I haven't seen anything regarding a range of values in LittleCMS but I don't know every nook and cranny of it. I'd think you'd just have to write your own code to check the pixel values. LittleCMS has routines which can read ICC tags for you but I'm not knowledgeable enough to know which one(s) you want. I'd personally use LittleCMS to set up for a color conversion and follow the code in the debugger and watch the part where it figures it out. LittleCMS certainly knows how to do it. It may involve this routine: _cmsReadMediaWhitePoint but I don't really know the insides of LittleCMS. I'd follow it in the debugger once to make sure you get the right result. I’d just do what it does. I don’t see a public routine which does it for you but I may have missed it.


>>And vice-versa, when decompressing custom CIE, can I convert an illumanant with Lab range into an ICC profile?
These create LAB ICC profiles with a white point:

cmsHPROFILE cmsCreateLab2Profile(const cmsCIExyY* WhitePoint);
cmsHPROFILE cmsCreateLab4Profile(const cmsCIExyY* WhitePoint);

LittleCMS can write that profile to a stream or write it to a file for you so you can create an ICC profile. I'm not sure what J2K is after with the range part.

Re: [Lcms-user] General question about CIE Lab and TIFF

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

Mark, thanks! Extremely helpful. Yeah, working with TIFF is like going back
in time.
Currently I extract IPTC , ICC and XMP from TIFF files, but I will look
into EXIF, as exiftool can add this to jpeg 2000 files.
I am trying to get as close to lossless (data and meta-data) as I can while
governed by the j2k standard.

So, with j2k, there are enumerated colour spaces such as sRGB, CMYK, there
are ICC colour spaces with profile, and
there is CIE LAB, which comes in two variants: "default" CIE (default
illuminant D50 and default Lab range)
and "custom" CIE with specified illuminant and 6 32-bit integers specifying
the Lab range. It's not possible to have
CIE pixel data along with ICC profile.

So, if I have a TIFF file with CIELAB or ICCLAB and no ICC profile, I map
this to "default" CIE in jpeg 2000.
But, suppose I have CIELAB with ICC. Is it possible with lcms to extract
the illuminant and Lab range from the ICC,
and store that in the j2k file ? And vice-versa, when decompressing custom
CIE, can I convert an illumanant
with Lab range into an ICC profile?

Thanks again!
Aaron



On Sun, Aug 18, 2019 at 6:50 PM Mark Allen <m.f...@pl...> wrote:

> As far as I know there are three places where color management info
> appears in TIFF: the common one, the old one, and the obscure one. And
> this is TIFF and it’s got a mass quantities of tags and I may not know
> about all of them. There could be more obscure ones I’ve missed.
>
> 1) The standard ICC profile: TIFFTAG_ICCPROFILE Modern software which does
> color management will honor this one.
>
> 2) Three chromaticities, a white point, and a “gamma”:
> TIFFTAG_PRIMARYCHROMATICITIES, TIFFTAG_WHITEPOINT, and
> TIFFTAG_TRANSFERFUNCTION. These are the pre-ICC profile way of doing things
> and I doubt much software will even look at these anymore. I tried to honor
> them in a TIFF reader and I never managed to find an example file using the
> transfer function. Maybe some old adobe software generated it. It doesn’t
> help that they implemented a more general transfer function instead of a
> simple gamma exponent.
>
> 3) EXIF tags: #40961. I'm just going from memory here but I believe some
> digital cameras (maybe professional Nikons) can output TIFFs which include
> EXIF data. I know JPEGs do this but I believe the EXIF document said that
> you could also insert EXIF data in TIFFs. In any case you can specify sRGB
> and adobe RGB using tag #40961. 65535 means unspecified, 1 means sRGB, and
> 2 is the unofficial way of specifying adobe RGB. I seem to recall finding
> the #40961 EXIF tag in JPEGs rather than an ICC profile for both sRGB and
> adobe RGB pictures. It looks like EXIF TIFFs do the same thing if I'm
> reading the EXIF document correctly (https://www.exif.org/Exif2-2.PDF)
> and some software might actually look at that. You could output #40961 if
> you're trying to be extremely thorough.
>
> If you're trying to create a TIFF with the most clearly specified color
> management info then you include the ICC profile because that's what modern
> software is going to generate and honor. The three chromaticies, white
> point, and gamma tags are probably not honored by much software but I guess
> there's no harm in putting them out there. TIFF readers ignore lots of tags
> and unrecognized ones are generally just ignored. If you have a JPEG2000
> which is sRGB or adobe RGB and you're outputing a TIFF then I suppose you
> could include the EXIF tag #40961 but I'm not 100% sure that TIFFs really
> include them. That's just how I read the EXIF document.
>
> If you’re writing a TIFF and it’s practical color management that you’re
> interested in then you could just output the ICC profile and call it a day.
> If you want to be extremely thorough then you could generate the other two
> kinds of info because it’s not that much more work.
>
> If you’re reading TIFFs and trying not to lose color management info then
> it would be more work to honor 2) and its transfer function and I don’t
> know if anybody actually generates it anymore.
>
> TIFF - it's an adventure...
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

Re: [Lcms-user] General question about CIE Lab and TIFF

[Mark A. <m.f...@pl...>]

As far as I know there are three places where color management info appears in TIFF: the common one, the old one, and the obscure one. And this is TIFF and it’s got a mass quantities of tags and I may not know about all of them. There could be more obscure ones I’ve missed. 

1) The standard ICC profile: TIFFTAG_ICCPROFILE Modern software which does color management will honor this one.

2) Three chromaticities, a white point, and a “gamma”: TIFFTAG_PRIMARYCHROMATICITIES, TIFFTAG_WHITEPOINT, and TIFFTAG_TRANSFERFUNCTION. These are the pre-ICC profile way of doing things and I doubt much software will even look at these anymore. I tried to honor them in a TIFF reader and I never managed to find an example file using the transfer function. Maybe some old adobe software generated it. It doesn’t help that they implemented a more general transfer function instead of a simple gamma exponent.

3) EXIF tags: #40961. I'm just going from memory here but I believe some digital cameras (maybe professional Nikons) can output TIFFs which include EXIF data. I know JPEGs do this but I believe the EXIF document said that you could also insert EXIF data in TIFFs. In any case you can specify sRGB and adobe RGB using tag #40961. 65535 means unspecified, 1 means sRGB, and 2 is the unofficial way of specifying adobe RGB. I seem to recall finding the #40961 EXIF tag in JPEGs rather than an ICC profile for both sRGB and adobe RGB pictures. It looks like EXIF TIFFs do the same thing if I'm reading the EXIF document correctly (https://www.exif.org/Exif2-2.PDF) and some software might actually look at that. You could output #40961 if you're trying to be extremely thorough.

If you're trying to create a TIFF with the most clearly specified color management info then you include the ICC profile because that's what modern software is going to generate and honor. The three chromaticies, white point, and gamma tags are probably not honored by much software but I guess there's no harm in putting them out there. TIFF readers ignore lots of tags and unrecognized ones are generally just ignored. If you have a JPEG2000 which is sRGB or adobe RGB and you're outputing a TIFF then I suppose you could include the EXIF tag #40961 but I'm not 100% sure that TIFFs really include them. That's just how I read the EXIF document.

If you’re writing a TIFF and it’s practical color management that you’re interested in then you could just output the ICC profile and call it a day. If you want to be extremely thorough then you could generate the other two kinds of info because it’s not that much more work.

If you’re reading TIFFs and trying not to lose color management info then it would be more work to honor 2) and its transfer function and I don’t know if anybody actually generates it anymore.

TIFF - it's an adventure...

Re: [Lcms-user] General question about CIE Lab and TIFF

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

Thanks, Mark That's quite helpful. Is there a way of storing the illumanant
or other CIE information in the TIFF ?
And are there any other TIFF tags I should be reading besides photometric
tag ?

On Sun, Aug 18, 2019 at 3:53 AM Mark Allen <m.f...@pl...> wrote:

> Hi,
>
> If you’re talking about TIFFTAG_PHOTOMETRIC (262) then the
> PHOTOMETRIC_CIELAB (8) and PHOTOMETRIC_ICCLAB (9) just tell what color
> space the pixel data uses. The only difference in the two is whether the A
> and B components are signed or unsigned.
>
> The original implementation of LAB in TIFF defined CIELAB. It uses signed
> values –128..127 for the A and B components.
>
> Apparently some people implemented it improperly and assumed unsigned
> values for A and B of 0..255. Adobe tried to “solve” the problem by adding
> the ICCLAB version to TIFF which uses unsigned 0..255 for A and B. At least
> that’s how I remember it. This happened more than 20 years ago.
>
> There’s two formats so you can have both signed and unsigned versions of A
> and B. Signed values seems to cause problems for some software so they can
> use the unsigned version instead. Other than that the two LABs are the same.
>
> You can see the “official” version in the two main TIFF documents.
> https://www.adobe.io/open/standards/TIFF.html  The addition of ICCLAB is
> mentioned in the TIFF technical notes:
> https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFFPM6.pdf
>
> Mark Allen
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

Re: [Lcms-user] General question about CIE Lab and TIFF

[Mark A. <m.f...@pl...>]

Hi,

If you’re talking about TIFFTAG_PHOTOMETRIC (262) then the PHOTOMETRIC_CIELAB (8) and PHOTOMETRIC_ICCLAB (9) just tell what color space the pixel data uses. The only difference in the two is whether the A and B components are signed or unsigned.

The original implementation of LAB in TIFF defined CIELAB. It uses signed values –128..127 for the A and B components.

Apparently some people implemented it improperly and assumed unsigned values for A and B of 0..255. Adobe tried to “solve” the problem by adding the ICCLAB version to TIFF which uses unsigned 0..255 for A and B. At least that’s how I remember it. This happened more than 20 years ago.

There’s two formats so you can have both signed and unsigned versions of A and B. Signed values seems to cause problems for some software so they can use the unsigned version instead. Other than that the two LABs are the same.

You can see the “official” version in the two main TIFF documents. https://www.adobe.io/open/standards/TIFF.html  The addition of ICCLAB is mentioned in the TIFF technical notes: https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFFPM6.pdf

Mark Allen

[Lcms-user] General question about CIE Lab and TIFF

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

Hello!

This isn't directly related to lcms, but can anyone "illuminate" me
on the two CIE tags PHOTOMETRIC_ICCLAB and PHOTOMETRIC_CIELAB
in the TIFF format ?  I can't find much on the web about them.

I am trying to relate them to the two CIE colour spaces supported by JPEG
2000
standard:
1) CIE with default D50 illuminant
2) CIE with custom illuminant, which I plan on storing in the TIFF ICC
profile.

Thanks very much,
Aaron