lcms-user — For users of the little cms library

Re: [Lcms-user] C++17 "register" warning when including lcms2.h

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

Hi,

>> VS 2017 produces a warning when including lcms2.h from C++ code:
>> "warning C5033: 'register' is no longer a supported storage class".
>
> These declarations appear wrong to me, regardless of C++.

This comes from the early days of lcms1. It is part of C99, which is  
the standard required by lcms2:

"6.7.1 Storage-class specifiers
4 A declaration of an identifier for an object with storage-class  
specifier register suggests that access to the object be as fast as  
possible. The extent to which such suggestions are effective is  
implementation-defined

6.7.5.3  Function declarators (including prototypes)
2 The only storage-class specifier that shall occur in a parameter  
declaration is register

6.9.1 Function definitions
6 […] The declarations in the declaration list shall contain no  
storage-class specifier other than register and no initializations."

Having said this, I don't see any evil on using a toggle in lcms to  
prevent register keyword, but set to off by default and disabled when  
.so/DLL is being used. As Bob says, the big issue here is ABI  
compatibility.
On most compilers register does nothing when used in parameters of  
exported functions, but in some embedded it is implemented and it  
makes a difference. On these cases there are no shared objects involved.

So, please let me know... should I add an hypothetical  
CMS_NO_REGISTER_KEYWORD, undefined by default, that would get rid of  
register on params? or maybe get rid of register completely when the  
option is selected?
Please note in any case lcms2 will stay on C99 standard, and therefore  
register has to be supported. As said, on some embedded compilers  
proper use of register makes huge difference on throughput.

Regards
Marti

Re: [Lcms-user] C++17 "register" warning when including lcms2.h

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

Hi Fellow LCMS users,

This represents one of the few files where at my company we've decided to maintain our own
slightly modified version of the Little CMS library.  While not a big deal, it does represent a
small ongoing expenditure of additional effort.

Since the C++ compilers we use aren't influenced by the register keyword I support Hanno's
request to consider removing it.

-Noel Carboni
 ProDigital Software

-----Original Message-----
From: Hanno Hoffstadt [mailto:Han...@gm...]
Sent: Fri, January 18, 2019 6:37 AM
To: Lcm...@li...
Subject: [Lcms-user] C++17 "register" warning when including lcms2.h

Hi,

VS 2017 produces a warning when including lcms2.h from C++ code:
"warning C5033: 'register' is no longer a supported storage class".

I've read that "register" is still valid C, just not C++17, see also

https://developercommunity.visualstudio.com/content/problem/117986/unexpected-warning-c5033-for-
using-register-storag.html

Out of curiosity, I've removed the keyword from all interfaces and compared the result of the
testbed.
Performance of register- and non-register versions were identical on x64 lcms2-2.9 builds, both
on MacOSX (Apple LLVM version 9.0.0) and Windows 10 VS 2017.

So I wonder if it would be possible to remove the keyword and leave this optimization to the
compiler, or is it still needed for old compilers / systems?

Best regards

Hanno



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

Re: [Lcms-user] C++17 "register" warning when including lcms2.h

[Bob F. <bfr...@si...>]

On Fri, 18 Jan 2019, Hanno Hoffstadt wrote:

> Hi,
>
> VS 2017 produces a warning when including lcms2.h from C++ code:
> "warning C5033: 'register' is no longer a supported storage class".

These declarations appear wrong to me, regardless of C++.

The way parameters are passed by function call interfaces (whether via 
registers and/or stack) are defined by the ABI definition (function 
calling conventions are part of ABI definitions) for the particular 
target platform.  Only interfaces which are not extern and can be 
inlined/optimized by the compiler would be able to avoid this since 
they are not defined by the ABI and thus the compiler can do what it 
wants.

Now there is some risk that a code difference will appear if these 
'register' declarations are removed from the lcms public headers.  If 
these callbacks are used internally by liblcms, then there might be a 
change to generated code in the library.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

[Lcms-user] C++17 "register" warning when including lcms2.h

[Hanno H. <Han...@gm...>]

Hi,

VS 2017 produces a warning when including lcms2.h from C++ code:
"warning C5033: 'register' is no longer a supported storage class".

I've read that "register" is still valid C, just not C++17, see also

https://developercommunity.visualstudio.com/content/problem/117986/unexpected-warning-c5033-for-using-register-storag.html

Out of curiosity, I've removed the keyword from all interfaces and compared the result of the testbed.
Performance of register- and non-register versions were identical on x64 lcms2-2.9 builds,
both on MacOSX (Apple LLVM version 9.0.0) and Windows 10 VS 2017.

So I wonder if it would be possible to remove the keyword and leave this optimization to the compiler, or is it still needed for old compilers / systems?

Best regards

Hanno

Re: [Lcms-user] multi threaded fork

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

<div dir='auto'><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jan 2, 2019 13:43, Vincent Torri &lt;vin...@gm...&gt; wrote:<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>
can't you add functions which use their changes ? So just API additions ?
<br></p></blockquote></div></div></div><div dir="auto">I'm afraid that is all functions, so this means duplicating the entire API. I spent long time trying to figure out how to integrate those changes without breaking compatibility, but found no way. For an hypotetical lcms3, maybe. But for now it is difficult. Technically difficult and complicated for me, that unfortunately have little time for&nbsp; this project.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Marti</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
</p>
</blockquote></div><br></div></div></div>

Re: [Lcms-user] multi threaded fork

[Vincent T. <vin...@gm...>]

On Wed, Jan 2, 2019 at 12:06 PM Marti <mar...@li...> wrote:
>
>
> Thanks Vicent,
>
> I  am already in contact with Artifex, they told me about their fork.
>
> Please note lcms already is multi-threading capable, and some critical
> functions like cmsDoTransform are re-entrant.   By default, it uses pthreads
> on everything but windows, that uses critical sections instead.
>
> Artifex have added a way to pass parameters to each function to identify the
> thread,  but unfortunately this breaks all compatibility with prior APIs, so
> I had to reject the changes on upstream because compatibility sake.  The
> "normal" lcms is based on contexts. It allows you to change via plug-in's
> the locking strategy and the memory allocation.

can't you add functions which use their changes ? So just API additions ?

Vincent Torri

Re: [Lcms-user] multi threaded fork

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

Thanks Vicent,

I  am already in contact with Artifex, they told me about their fork.

Please note lcms already is multi-threading capable, and some critical
functions like cmsDoTransform are re-entrant.   By default, it uses pthreads
on everything but windows, that uses critical sections instead. 

Artifex have added a way to pass parameters to each function to identify the
thread,  but unfortunately this breaks all compatibility with prior APIs, so
I had to reject the changes on upstream because compatibility sake.  The
"normal" lcms is based on contexts. It allows you to change via plug-in's
the locking strategy and the memory allocation. 

Regards
Marti

-----Original Message-----
From: Vincent Torri [mailto:vin...@gm...] 
Sent: Wednesday, January 2, 2019 9:08 AM
To: Lcm...@li...
Subject: [Lcms-user] multi threaded fork

Hello

i've seen this mupdf/ghostsciprt fork which adds multi threading :

http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=commitdiff;h=c9f2256ff2
479a219a5b3521c57b5adeded0d6ac

in case it interests you

regards

Vincent Torri


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

Re: [Lcms-user] multi threaded fork

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

On 02/01/2019 08:07, Vincent Torri wrote:
> i've seen this mupdf/ghostsciprt fork which adds multi threading :
> 
> http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=commitdiff;h=c9f2256ff2479a219a5b3521c57b5adeded0d6ac

A better link:

http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=shortlog;h=refs/heads/lcms2mt

And for why the fork exists, read:

http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=blob;f=doc/WhyThisFork.txt;h=e3cbde475a32ce6d75cb9d6c42bf6bb9e8fbf023;hb=2e1587ee015b168399a6b2fde86858e8396c9a59

HTH,

Robin

[Lcms-user] multi threaded fork

[Vincent T. <vin...@gm...>]

Hello

i've seen this mupdf/ghostsciprt fork which adds multi threading :

http://git.ghostscript.com/?p=thirdparty-lcms2.git;a=commitdiff;h=c9f2256ff2479a219a5b3521c57b5adeded0d6ac

in case it interests you

regards

Vincent Torri

[Lcms-user] patched lcms2 in pdfium

[Vincent T. <vin...@gm...>]

Hello

i've browsed the pdfium source code and found this :

https://pdfium.googlesource.com/pdfium/+/master/third_party/lcms/

There are around 30 patches for lcms2.

I don't know if all of them are good or not, i just want to mention
them. Maybe it can help and improve lcms2

regards

Vincent Torri

Re: [Lcms-user] Profile linearization and softproofing

[Aurélien P. <re...@au...>]

Hi,

Le 04/11/2018 à 23:38, Graeme Gill a écrit :
> Hi,
>
>> I understand the theory of profiling and error reverting with LUT or TRC, it's on the
>> actual implementation that I'm lost, and what actually happens in the pixelpipe.
> seems then that this is really a question for those who understand
> darktable's internals.
>
> Note though, that changing the display profile to allow for a change
> in the source color encoding, is 100% wrong.
> Instead you need to make the source color encoding match the
> source profile. Note that in this context "source" means the
> input to the conversion to display space made using lcms,
> which is the output of darktables photo processing.
I know, for now I'm trying to debug and understand what's going on,
elegant solutions will come later.
>> output Lab values are off, too bright : data 50 % Lab (measured on a RAW photo of a ColorChecker grey
>> patch with white patch properly exposed) is shown as 75 % screen Lab. Given that 0.5^(1/2.4) = 0.75,
>> that sounds like a gamma issue.
> Hmm. That's an odd way of measurement, given that gamma usually relates linear light to
> gamma encoded, while L* is a non-linear light measure.
>
> Are you sure that your "50 % Lab" is actual L*, and not a linear light % ?
>
> i.e. a 50% linear light value would be expected to measure approximately
> L* 76 if white is L*100.

Oh God, yes, you are right. darktable labels it L but it is L* (looking
at the code). So I was mislead the whole time and everything is
perfectly normal.

Thanks a lot for your time,

Aurélien.

>
> ( L* = linear_light^1/3 * 116 - 16)
>
> Cheers,
> 	Graeme Gill.
>

Re: [Lcms-user] Profile linearization and softproofing

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

Aurélien Pierre wrote:

Hi,

> I understand the theory of profiling and error reverting with LUT or TRC, it's on the
> actual implementation that I'm lost, and what actually happens in the pixelpipe.

seems then that this is really a question for those who understand
darktable's internals.

Note though, that changing the display profile to allow for a change
in the source color encoding, is 100% wrong.
Instead you need to make the source color encoding match the
source profile. Note that in this context "source" means the
input to the conversion to display space made using lcms,
which is the output of darktables photo processing.

> output Lab values are off, too bright : data 50 % Lab (measured on a RAW photo of a ColorChecker grey
> patch with white patch properly exposed) is shown as 75 % screen Lab. Given that 0.5^(1/2.4) = 0.75,
> that sounds like a gamma issue.

Hmm. That's an odd way of measurement, given that gamma usually relates linear light to
gamma encoded, while L* is a non-linear light measure.

Are you sure that your "50 % Lab" is actual L*, and not a linear light % ?

i.e. a 50% linear light value would be expected to measure approximately
L* 76 if white is L*100.

( L* = linear_light^1/3 * 116 - 16)

Cheers,
	Graeme Gill.

Re: [Lcms-user] Profile linearization and softproofing

[Aurélien P. <re...@au...>]

Hi Graeme,

thank you for your answer.

The problem I have is that, in darktable, it seems the image is
gamma-corrected twice :

  * output Lab values are off, too bright : data 50 % Lab (measured on a
    RAW photo of a ColorChecker grey patch with white patch properly
    exposed) is shown as 75 % screen Lab. Given that 0.5^(1/2.4) = 0.75,
    that sounds like a gamma issue.
  * masks featherings show some sort of quantization artifacts on the edges,
  * linear grey ramps in an image (PNG synthesized grey gradient) looks
    washed away for the most part (again, too bright).

It is solved by removing the tonecurves from the output color conversion
or by using Elle Stones Identity ICC profile (gamma 1.0) as a display
profile in the software (but, of course, colors are desaturated then).
For usual RGB output spaces, this is done with darktable internal
functions (easy to hack), but for exotic RGB output spaces, LittleCMS
handles that with black boxes.

Or maybe I'm wrong and there is some place elsewhere in the code where
arbitrary gamma 2.4 conversions happen.

I understand the theory of profiling and error reverting with LUT or
TRC, it's on the actual implementation that I'm lost, and what actually
happens in the pixelpipe.

Thank you,

Aurélien.

Le 04/11/2018 à 18:56, Graeme Gill a écrit :
> Aurélien Pierre wrote:
>
> Hi,
>
>> I'm working on the software darktable to enable a linear workflow (no gamma correction
>> from the display, this is done by a log2 function internally), in order to visualize the
>> data in the scene-referred space.
>> I'm looking for a way to keep the RGB primaries but remove the TCR/tonecurve from that
>> xform in order to suppress the gamma correction. So far, I'm clueless. Is that possible ?
> it's not really clear what you are attempting to do.
>
> Note that all conventional displays have a gamma reproduction characteristic - the
> display light levels are non-linearly related to the frame buffer control values.
> This is because it makes the control values more perceptually uniform,
> and therefore there is less visual quantization with limited frame buffer depth
> or video signal encoding depth.
>
> Typically the term "gamma correction" means the image processing
> system applying the anti-gamma of the display, in order to cancel
> out the effects of the gamma response, so that the code can
> deal with linear light levels in computation.
>
> In an ICC profile color managed system though, the display profile provides
> a mapping between PCS (i.e. CIE standard observer, device independent) values
> and the display control (i.e. device) values. (i.e. it provides the
> inversion of the display behavior.)
>
> PCS can be either CIE XYZ or CIE L*a*b* D50 white point values.
> These are effectively interchangeable, since the conversion
> is fixed. CIE XYZ values are linear light.
>
> So you don't really need a proofing transform to send linear light
> values to the display, you just need the inverse (i.e. B2A direction)
> ICC device profile. Note though that the range of values is limited
> by the display gamut.
>
> A soft proofing transform is typically quite complex, involving
> three device profiles i.e.:
>
> Source color space -> input profile -> proofing profile -> Proofing colorspace ->
> proofing profile -> output profile -> Output colorspace.
>
> i.e. the transform does a color conversion from the source color space
> to the proofing space, and then converts that to the output (typically
> display) color space. The purpose is typically to be able to
> see the gamut mapping characteristics of the proofing device (i.e. printer),
> while viewing on a different device (i.e. display). Note that within
> the gamut and the accuracy of the profiles, the color fidelity
> will be maintained by the color management system.
>
> If that's really what you want to do (i.e. you really want to do
> a soft proof, because you are targeting (say) a printer), then you
> control the source color space by your choice of source ICC profile.
> i.e. if you want the source to be a linear light RGB type space,
> then you need to create or use such a profile as the source profile.
>
> This is because the whole point of a color management system
> is to manage the color. Its purpose is to be closed loop control.
> So you provide a color, define what that color means by providing
> a color profile (the source profile) or use a device independent
> color encoding like XYZ or L*a*b*, and then the color management
> system takes care of faithfully conveying that color to the output
> device as much as is possible, without you having to know
> much about how that device behaves.
>
> Note that if you don't really wish to use a proofing transform,
> you would use the simpler cmsCreateTransform(), which converts
> between your source colorspace and your display.
>
> Hope this helps,
>
> 	Graeme Gill.
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Profile linearization and softproofing

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

Aurélien Pierre wrote:

Hi,

> I'm working on the software darktable to enable a linear workflow (no gamma correction
> from the display, this is done by a log2 function internally), in order to visualize the
> data in the scene-referred space.

> I'm looking for a way to keep the RGB primaries but remove the TCR/tonecurve from that
> xform in order to suppress the gamma correction. So far, I'm clueless. Is that possible ?

it's not really clear what you are attempting to do.

Note that all conventional displays have a gamma reproduction characteristic - the
display light levels are non-linearly related to the frame buffer control values.
This is because it makes the control values more perceptually uniform,
and therefore there is less visual quantization with limited frame buffer depth
or video signal encoding depth.

Typically the term "gamma correction" means the image processing
system applying the anti-gamma of the display, in order to cancel
out the effects of the gamma response, so that the code can
deal with linear light levels in computation.

In an ICC profile color managed system though, the display profile provides
a mapping between PCS (i.e. CIE standard observer, device independent) values
and the display control (i.e. device) values. (i.e. it provides the
inversion of the display behavior.)

PCS can be either CIE XYZ or CIE L*a*b* D50 white point values.
These are effectively interchangeable, since the conversion
is fixed. CIE XYZ values are linear light.

So you don't really need a proofing transform to send linear light
values to the display, you just need the inverse (i.e. B2A direction)
ICC device profile. Note though that the range of values is limited
by the display gamut.

A soft proofing transform is typically quite complex, involving
three device profiles i.e.:

Source color space -> input profile -> proofing profile -> Proofing colorspace ->
proofing profile -> output profile -> Output colorspace.

i.e. the transform does a color conversion from the source color space
to the proofing space, and then converts that to the output (typically
display) color space. The purpose is typically to be able to
see the gamut mapping characteristics of the proofing device (i.e. printer),
while viewing on a different device (i.e. display). Note that within
the gamut and the accuracy of the profiles, the color fidelity
will be maintained by the color management system.

If that's really what you want to do (i.e. you really want to do
a soft proof, because you are targeting (say) a printer), then you
control the source color space by your choice of source ICC profile.
i.e. if you want the source to be a linear light RGB type space,
then you need to create or use such a profile as the source profile.

This is because the whole point of a color management system
is to manage the color. Its purpose is to be closed loop control.
So you provide a color, define what that color means by providing
a color profile (the source profile) or use a device independent
color encoding like XYZ or L*a*b*, and then the color management
system takes care of faithfully conveying that color to the output
device as much as is possible, without you having to know
much about how that device behaves.

Note that if you don't really wish to use a proofing transform,
you would use the simpler cmsCreateTransform(), which converts
between your source colorspace and your display.

Hope this helps,

	Graeme Gill.

[Lcms-user] Profile linearization and softproofing

[Aurélien P. <re...@au...>]

Hi,

I'm working on the software darktable to enable a linear workflow (no
gamma correction from the display, this is done by a log2 function
internally), in order to visualize the data in the scene-referred space.

To convert from internal Lab to display RGB (or other spaces, for image
export), darktable uses :

    d->xform = cmsCreateProofingTransform(Lab, TYPE_LabA_FLT, output,
    output_format, softproof,
                                              out_intent,
    INTENT_RELATIVE_COLORIMETRIC, transformFlags);

I'm looking for a way to keep the RGB primaries but remove the
TCR/tonecurve from that xform in order to suppress the gamma correction.
So far, I'm clueless. Is that possible ?

Thank you,

Aurélien.

Re: [Lcms-user] ICC Profile description tag not read correctly

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

Richard Hughes wrote:

> I think Graeme needs some convincing on v4.

Sorry, highly unconvinced in any technical sense. I may get
there eventually, but it's a long way down my priority list.

Cheers,
	Graeme.

Re: [Lcms-user] ICC Profile description tag not read correctly

[Richard H. <hug...@gm...>]

On Wed, 19 Sep 2018 at 21:30, Marti Maria <mar...@li...> wrote:
> software that only accepts v2 profiles, maybe your should consider to upgrading to something more actual

I get asked about supporting V2-only profiles in colord every few
months for use in ArgyllCMS. I think Graeme needs some convincing on
v4.

Richard.

Re: [Lcms-user] ICC Profile description tag not read correctly

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

<div dir='auto'><div><br><div><br><div class="elided-text">On 18 Sep 2018 10:27, Carles Llopis &lt;car...@in...&gt; wrote:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello Martí,<br><div><br></div><div><blockquote><div><p>This happens on legacy profiles using TextDescriptionType as data container. We are talking about profiles generated on 1998, TWENTY years ago.&nbsp;<br></p></div></blockquote></div><div><div><p>This is not absolutely true. We are using an 3rd party ICC profile generation tool where we set output to be V2 profile, to maximise compatibility. Our users can decide then</p></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">V2 is an obsolete format which should be avoided in any case, see&nbsp; ICC notes:</div><div dir="auto">http://color.org/whyusev4.xalter<br></div><div dir="auto"><br></div><div dir="auto">There is no active lcms developement on v2 and will never be. This is also to discourage the usage of&nbsp; this old and problematic&nbsp; format. if you are using&nbsp; software that only accepts v2 profiles, maybe your should consider to upgrading to something more actual.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Marti</div><div dir="auto"><br></div><div dir="auto"></div></div>

Re: [Lcms-user] ICC Profile description tag not read correctly

[Martí M. <mar...@li...>]

Hi,

This happens on legacy profiles using TextDescriptionType as data 
container. We are talking about profiles generated on 1998, TWENTY years 
ago.

The reason to choose ASCII on such old profiles is because in many 
sample profiles, the wide part was broken.

Any modern V4 profile holding multilocalizedUnicode as data container 
will behave as you expect.

  Regards

Marti




On 9/17/2018 2:12 PM, Angel Sánchez wrote:
> Hello folks!
>
> We are using LCMS to read some profile descriptions from images and 
> with this one looks like it can't read the Unicode part of the tag, 
> and instead reads the ASCII one.
>
> Here is the code we are using:
> ------------
> wchar_t desc[2048]={0};
>
> if (m_cmshProfile != NULL)
> {
> cmsMLU * pDescTag = (cmsMLU *) cmsReadTag(m_cmshProfile, 
> cmsSigProfileDescriptionTag);
>
> if (!cmsGetProfileInfo(m_cmshProfile, cmsInfoDescription, 
> cmsNoLanguage, cmsNoCountry, desc, sizeof(desc)))
>               return NULL;
> }
> ------------
>
> In this case desc gets this characters: ASCII   sRGB IEC61966-2.1
> And instead it should be Unicodé sRGB IEC61966-2.1
>
> This happens on windows using Visual Studio 2017 and macOS.
>
> If I extract the ICC profile with ImageMagick and convert to xml with 
> IccXML ( https://sourceforge.net/projects/iccxml/ ), I can see the 
> following tags:
> ---------
> <textDescriptionType>
> <TagSignature>desc</TagSignature>
>       <ASCII><![CDATA[ASCII sRGB IEC61966-2.1]]></ASCII>
>       <Unicode><![CDATA[Unicodé sRGB IEC61966-2.1]]></Unicode>
>     </textDescriptionType>
> ---------
>
> Looks like it is getting the ASCII tag instead the Unicode one.
> How we should read the Unicode tag?
>
> I have attached the ICC profile.
>
> Feel free to contact me for any questions, suggestions and advice.
>
> Thanks,
> Angel
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] ICC Profile description tag not read correctly

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

Hi Angel,

 

I took your question as an opportunity to familiarize myself more with the Little CMS source code.

 

Since you did not specify a language, this comment, from the internal implementation of _cmsMLUgetWide(), states that the first description found will be returned.  In the case of your profile it's the  "ASCII sRGB IEC61966-2.1" description.

 

// The algorithm first searches for an exact match of country and language, if not found it uses

// the Language. If none is found, first entry is used instead.

 

Are you suggesting that the above code should be changed so that it chooses a wide character description over the narrow character one if the wide character cmsGetProfileInfo() function is used, and the narrow character description preferentially only if the cmsGetProfileInfoASCII() function is used?

 

I suspect making such a change could break other software that already depends on the above-described behavior, though it's not explicitly documented either way in the manual.

 

Only Marti can speak to whether design changes would make sense and fit his original goals.

 

-Noel Carboni

ProDigital Software

 

From: Angel Sánchez [mailto:sal...@gm...] 
Sent: Mon, September 17, 2018 8:12 AM
To: lcm...@li...
Subject: [Lcms-user] ICC Profile description tag not read correctly

 

Hello folks!

 

We are using LCMS to read some profile descriptions from images and with this one looks like it can't read the Unicode part of the tag, and instead reads the ASCII one.

 

Here is the code we are using:

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

wchar_t desc[2048]={0};

 

if (m_cmshProfile != NULL)

{

            cmsMLU * pDescTag = (cmsMLU *) cmsReadTag(m_cmshProfile, cmsSigProfileDescriptionTag);

 

            if (!cmsGetProfileInfo(m_cmshProfile, cmsInfoDescription, cmsNoLanguage, cmsNoCountry, desc, sizeof(desc)))

              return NULL;

}

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

 

In this case desc gets this characters:  ASCII   sRGB IEC61966-2.1

And instead it should be Unicodé sRGB IEC61966-2.1

 

This happens on windows using Visual Studio 2017 and macOS.

 

If I extract the ICC profile with ImageMagick and convert to xml with IccXML ( https://sourceforge.net/projects/iccxml/ ), I can see the following tags:

---------

<textDescriptionType>

      <TagSignature>desc</TagSignature>

      <ASCII><![CDATA[ASCII sRGB IEC61966-2.1]]></ASCII>

      <Unicode><![CDATA[Unicodé sRGB IEC61966-2.1]]></Unicode>

    </textDescriptionType>

---------

 

Looks like it is getting the ASCII tag instead the Unicode one.

How we should read the Unicode tag?

 

I have attached the ICC profile.

 

Feel free to contact me for any questions, suggestions and advice.

 

Thanks,

Angel

[Lcms-user] ICC Profile description tag not read correctly

[Angel S. <sal...@gm...>]

Hello folks!

We are using LCMS to read some profile descriptions from images and with
this one looks like it can't read the Unicode part of the tag, and instead
reads the ASCII one.

Here is the code we are using:
------------
wchar_t desc[2048]={0};

if (m_cmshProfile != NULL)
{
cmsMLU * pDescTag = (cmsMLU *) cmsReadTag(m_cmshProfile,
cmsSigProfileDescriptionTag);

if (!cmsGetProfileInfo(m_cmshProfile, cmsInfoDescription, cmsNoLanguage,
cmsNoCountry, desc, sizeof(desc)))
              return NULL;
}
------------

In this case desc gets this characters:  ASCII   sRGB IEC61966-2.1
And instead it should be Unicodé sRGB IEC61966-2.1

This happens on windows using Visual Studio 2017 and macOS.

If I extract the ICC profile with ImageMagick and convert to xml with
IccXML ( https://sourceforge.net/projects/iccxml/ ), I can see the
following tags:
---------
<textDescriptionType>
      <TagSignature>desc</TagSignature>
      <ASCII><![CDATA[ASCII sRGB IEC61966-2.1]]></ASCII>
      <Unicode><![CDATA[Unicodé sRGB IEC61966-2.1]]></Unicode>
    </textDescriptionType>
---------

Looks like it is getting the ASCII tag instead the Unicode one.
How we should read the Unicode tag?

I have attached the ICC profile.

Feel free to contact me for any questions, suggestions and advice.

Thanks,
Angel

[Lcms-user] How to build the library/Framework targeting iOS

[Thomas H. <tha...@t-...>]

Hi,
 I have tried to build the LCMS as a library for iOS targets with all the
".c"-files  and I get a linker error in the end:
ld: entry point (_main) undefined for architecture arm64

What should I add (probably in a maim.m file) to get a valid library for
iOS? 

Regards
Thomas

Re: [Lcms-user] Parametric curve to curve table

[Mikhail E. <m...@em...>]

I've found the answer, no help needed anymore.

-- 
Mikhail

> On 5 Jun 2018, at 21:02, Mikhail Emelchenkov via Lcms-user <lcm...@li...> wrote:
> 
> Hello!
> 
> I want to convert parametric curve of ICC v4 to 256 values curve table of ICC v2. Function is zero, y=x * lambda. Could you please tell how to calculate proper values?

[Lcms-user] Parametric curve to curve table

[Mikhail E. <m...@em...>]

Hello!

I want to convert parametric curve of ICC v4 to 256 values curve table of ICC v2. Function is zero, y=x * lambda. Could you please tell how to calculate proper values?

(IccXML output of ICC v4):
<parametricCurveType>
  <TagSignature>rTRC</TagSignature>
  <ParametricCurve FunctionType="0">
    2.19447327
  </ParametricCurve>
</parametricCurveType>

-- 
Mikhail

[Lcms-user] Lcms python - DeltaE calculous

[Gonzalez C. J. <jor...@hp...>]

I am using the little cms in python but when I want to use the cmsCIE94DeltaE(Lab1: 'cmsCIELab', Lab2: 'cmsCIELab') -> "cmsFloat64Number": function i get a argument 1 of type 'cmsCIELab const *'. What i do is the following:

Import littlecms as lcms

Color1 = lcms. cmsCIELab
#The vàlues are an example
Color1.L = 12.0
Color1.a = 14.0
Color1.b = 22.0

Color2 = lcms. cmsCIELab
#The vàlues are an example
Color2.L = 15.0
Color2.a = 14.0
Color2.b = 22.0

Distance = lcms.cmsCIE94DeltaE(Color1,Color2)