lcms-user — For users of the little cms library

Re: [Lcms-user] Lcms-user Digest, Vol 135, Issue 3

[Jason C. <cam...@gm...>]

Christian,

Two things to add from my own efforts of similar intent:


  *   Adobe uses their own ACE (Adobe Color Engine) which does differ from Apple CMM and LCMS and others.  So even basic conversions I’ve tested will have some slight differences.
  *   Usually Absolute Colorimetric is used to force a source whitepoint to be simulated in the destination space.  I think LCMS has a whitepoint override but I don’t know the detail on where you need to insert that.  Others on the list might have detail on that piece.
  *   Preserving the numbers is an option on the handling of the file itself -- if it needs to, for some reason, NOT manage the RGB/CMYK build colors and preserve them in lieu of respecting the results of the transform.


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

Date: Fri, 8 Feb 2019 11:50:40 +0100
From: Christian Schmitz <rea...@mo...<mailto:rea...@mo...>>
To: lcm...@li...<mailto:lcm...@li...>
Subject: [Lcms-user] LCMS questions for paper simulation

Hello,

We try to replicate here the display from Photoshop and there is an option for paper simulation.

Does someone know how to achieve this with LCMS2?

We already created a transform with CreateProofingTransform with image profile a source, monitor profile as destination and the device profile as transfer one with relative color metric intent (is that right?) and Flags Soft Proofing and BPC. The result looks close, but not exactly the same as in photoshop.

Also the is an option to preserve RGB or CMYK numbers.
I don't see an option for that.

Black point compensation is also a checkbox, but for that we found a flag.

Re: [Lcms-user] LCMS questions for paper simulation

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

<div dir='auto'>Hi,<div dir="auto">Try absolute colorimetric as proofing intent for paper simulation.&nbsp;&nbsp;</div><div dir="auto"><br></div><div dir="auto">To get same as photoshop,&nbsp; experiment with intents. Diferrent intents sometimes makes a big difference.</div><div dir="auto">Regards</div><div dir="auto">Marti</div></div>

Re: [Lcms-user] Fwd: fake ICC profile to visualize quickly color matched areas...

[Sebastien L. <sl...@po...>]

Hi guys,

Edgar, the profile you sent me works fine !
Thank you all for your help :-)

Best regards

Sébastien

Le 07/02/2019 à 12:09, Edgar Loser a écrit :
> Hi Sébastien,
>
> or take this profile as output. It has a very small gamut, i.e. when
> doing a transform from sRGB to fakeOut.icc
> the output will be very saturated (values are either 0 or 255).
>
> Edgar 

[Lcms-user] LCMS questions for paper simulation

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

Hello,

We try to replicate here the display from Photoshop and there is an option for paper simulation.

Does someone know how to achieve this with LCMS2?


We already created a transform with CreateProofingTransform with image profile a source, monitor profile as destination and the device profile as transfer one with relative color metric intent (is that right?) and Flags Soft Proofing and BPC. The result looks close, but not exactly the same as in photoshop.


Also the is an option to preserve RGB or CMYK numbers. 
I don't see an option for that.


Black point compensation is also a checkbox, but for that we found a flag.

Sincerely
Christian

-- 
Read our blog about news on our plugins:

http://www.mbsplugins.de/

Re: [Lcms-user] Fwd: fake ICC profile to visualize quickly color matched areas...

[Edgar L. <lo...@co...>]

Hi Sébastien,

or take this profile as output. It has a very small gamut, i.e. when doing a transform from sRGB to fakeOut.icc
the output will be very saturated (values are either 0 or 255).

Edgar

> Hello,
> 
> Edgar, Kai-Uwe, thanks a lot for taking the time to send me these profiles.
> 
> Theoritically, they should be perfect and I have no problem to load them
> (as they are in RGB color space).
> 
> Unfortunately, when I try to use them (named "debugRGB") and create the
> following 2 transforms, littlecms returns an error :
> error 13: Couldn't link the profiles
> 
> The transform are quite trivial (sRGB 8 bits -> debugRGB and Lab double
> -> debugRGB ):
> 
>   t1   = cmsCreateTransform(sRGB, TYPE_QRGB_8, debugRGB, TYPE_BGRA_8,
> intent, flags);
>   t2   = cmsCreateTransform(LabHandle,  TYPE_Lab_DBL,  debugRGB,
> TYPE_BGRA_8,  intent, flags);
> 
> If I use ProPhoto or an icc profile from a screen, I don't have any
> trouble :-(
> 
> I'm a bit puzzled...
> 
> May be the problem is obvious for you ?
> 
> Best regards
> 
> Sébastien
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 


-- 
lakeBits Inh. Edgar Loser
Haydnstr. 25
78464 Konstanz
Tel 0049 7531 5844154 0
Fax 0049 7531 5844154 9
https://www.colymp.com/
mailto:lo...@co...

Re: [Lcms-user] Fwd: fake ICC profile to visualize quickly color matched areas...

[Edgar L. <lo...@co...>]

Hi Sébastien,

can you swap the profiles in cmsCreateTransform?
Going from "debugRGB" to sRGB?
In this case they should be compatible with lcms...

Edgar

On 07.02.2019 10:01, Sébastien L. wrote:
> Hello,
> 
> Edgar, Kai-Uwe, thanks a lot for taking the time to send me these profiles.
> 
> Theoritically, they should be perfect and I have no problem to load them
> (as they are in RGB color space).
> 
> Unfortunately, when I try to use them (named "debugRGB") and create the
> following 2 transforms, littlecms returns an error :
> error 13: Couldn't link the profiles
> 
> The transform are quite trivial (sRGB 8 bits -> debugRGB and Lab double
> -> debugRGB ):
> 
>   t1   = cmsCreateTransform(sRGB, TYPE_QRGB_8, debugRGB, TYPE_BGRA_8,
> intent, flags);
>   t2   = cmsCreateTransform(LabHandle,  TYPE_Lab_DBL,  debugRGB,
> TYPE_BGRA_8,  intent, flags);
> 
> If I use ProPhoto or an icc profile from a screen, I don't have any
> trouble :-(
> 
> I'm a bit puzzled...
> 
> May be the problem is obvious for you ?
> 
> Best regards
> 
> Sébastien
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 


-- 
lakeBits Inh. Edgar Loser
Haydnstr. 25
78464 Konstanz
Tel 0049 7531 5844154 0
Fax 0049 7531 5844154 9
https://www.colymp.com/
mailto:lo...@co...

Re: [Lcms-user] Fwd: fake ICC profile to visualize quickly color matched areas...

[Sébastien L. <sl...@ma...>]

Hello,

Edgar, Kai-Uwe, thanks a lot for taking the time to send me these profiles.

Theoritically, they should be perfect and I have no problem to load them
(as they are in RGB color space).

Unfortunately, when I try to use them (named "debugRGB") and create the
following 2 transforms, littlecms returns an error :
error 13: Couldn't link the profiles

The transform are quite trivial (sRGB 8 bits -> debugRGB and Lab double
-> debugRGB ):

 t1   = cmsCreateTransform(sRGB, TYPE_QRGB_8, debugRGB, TYPE_BGRA_8,
intent, flags);
 t2   = cmsCreateTransform(LabHandle,  TYPE_Lab_DBL,  debugRGB,
TYPE_BGRA_8,  intent, flags);

If I use ProPhoto or an icc profile from a screen, I don't have any
trouble :-(

I'm a bit puzzled...

May be the problem is obvious for you ?

Best regards

Sébastien

Re: [Lcms-user] [EXTERNAL]Re: fake ICC profile to visualize quickly color matched areas...

[Edgar L. <lo...@co...>]

Hi Sébastien,

I've two RGB profiles for you (attached, hope that works in this list):
one is "spinning" around rgb (rgb becomes brg)
the other one is converting rgb to green (when used as input profile)

Edgar


On 06.02.2019 16:46, Sebastien Leon wrote:
> Hi Marco,
> Thank you for your answer.
> 
>> Not sure I understand the way you are using them, but can't you just use
>> something like an extreme wide gamut profile to see the differences?
> ProPhoto or such?
> 
> Yes, it is a solution. But it is visually less obvious that using a
> profile that completely modify the colors (like switching channels or
> turning everything black, ...)
> I thought such profiles were easy to find (or easy to create for ICC
> wizards) but it seems I am wrong.
> 
> Sébastien
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 


-- 
lakeBits Inh. Edgar Loser
Haydnstr. 25
78464 Konstanz
Tel 0049 7531 5844154 0
Fax 0049 7531 5844154 9
https://www.colymp.com/
mailto:lo...@co...

[Lcms-user] fake ICC profile to visualize quickly color matched areas...

[Sebastien L. <sl...@po...>]

Hi guys,

For some years I use littleCMS (and it is great, thanks Marti) and
included it into a graphical software.

Some of my dialog were color-matched, and some others were not (old
architecture, lack of time, dev skill, etc...)

Now, I'm searching an ICC profile (rgb color space) that I could
substitute to the default screen profile so I could immediately see
which dialog are color matched and which one are not...
Does anyone here has such profile ? (for an example, a profile that
turns everything to grayscale or darker or anything really different...)
(of course, I could go to the code, but 250 dialog will take me a lot of
time)

Thanks for your help !

Sébastien Léon
Pointcarré Textile Software

Re: [Lcms-user] [EXTERNAL]Re: fake ICC profile to visualize quickly color matched areas...

[Sebastien L. <sl...@po...>]

Hi Marco,
Thank you for your answer.

> Not sure I understand the way you are using them, but can't you just use
> something like an extreme wide gamut profile to see the differences?
ProPhoto or such?

Yes, it is a solution. But it is visually less obvious that using a
profile that completely modify the colors (like switching channels or
turning everything black, ...)
I thought such profiles were easy to find (or easy to create for ICC
wizards) but it seems I am wrong.

Sébastien

Re: [Lcms-user] [EXTERNAL]Re: fake ICC profile to visualize quickly color matched areas...

[Marco F. <Mar...@en...>]

Not sure I understand the way you are using them, but can't you just use something like an extreme wide gamut profile to see the differences? ProPhoto or such?

Marco

-----Ursprüngliche Nachricht-----
Von: Sebastien Leon [mailto:sl...@po...] 
Gesendet: Mittwoch, 6. Februar 2019 09:07
An: lcm...@li...
Betreff: [EXTERNAL]Re: [Lcms-user] fake ICC profile to visualize quickly color matched areas...

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

Hi Kai-Uwe,

I replaced my screen profile by one of yours but it failed.
After few tests I realized that your profiles were all in Lab color
space (which is incompatible with screen correction code in RGB color space)
Any idea to get the same profiles in RGB or to get some others in RGB ?

Best regards

Sébastien

Le 06/02/2019 à 14:01, Sebastien Leon a écrit :
> Hi Kai-Uwe,
>
> This looks perfect for my need !
>
> Thanks a lot
>
> Sébastien
>
> Le 06/02/2019 à 13:53, Kai-Uwe Behrmann a écrit :
>> Dear Sebastien,
>>
>> here are some effect profiles, which might be of use for your purpose:
>>
>> https://github.com/oyranos-cms/oyranos/files/1756684/vcgt-effects-icc.zip
>>
>> best regards
>> Kai-Uwe
>>
>> Am 06.02.19 um 13:48 schrieb Sebastien Leon:
>>> Hi guys,
>>>
>>> For some years I use littleCMS (and it is great, thanks Marti) and
>>> included it into a graphical software.
>>>
>>> Some of my dialog were color-matched, and some others were not (old
>>> architecture, lack of time, dev skill, etc...)
>>>
>>> Now, I'm searching an ICC profile (rgb color space) that I could
>>> substitute to the default screen profile so I could immediately see
>>> which dialog are color matched and which one are not...
>>> Does anyone here has such profile ? (for an example, a profile that
>>> turns everything to grayscale or darker or anything really different...)
>>> (of course, I could go to the code, but 250 dialog will take me a lot of
>>> time)
>>>
>>> Thanks for your help !
>>>
>>> Sébastien Léon
>>> Pointcarré Textile Software
>>>




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

Re: [Lcms-user] fake ICC profile to visualize quickly color matched areas...

[Sebastien L. <sl...@po...>]

Hi Kai-Uwe,

I replaced my screen profile by one of yours but it failed.
After few tests I realized that your profiles were all in Lab color
space (which is incompatible with screen correction code in RGB color space)
Any idea to get the same profiles in RGB or to get some others in RGB ?

Best regards

Sébastien

Le 06/02/2019 à 14:01, Sebastien Leon a écrit :
> Hi Kai-Uwe,
>
> This looks perfect for my need !
>
> Thanks a lot
>
> Sébastien
>
> Le 06/02/2019 à 13:53, Kai-Uwe Behrmann a écrit :
>> Dear Sebastien,
>>
>> here are some effect profiles, which might be of use for your purpose:
>>
>> https://github.com/oyranos-cms/oyranos/files/1756684/vcgt-effects-icc.zip
>>
>> best regards
>> Kai-Uwe
>>
>> Am 06.02.19 um 13:48 schrieb Sebastien Leon:
>>> Hi guys,
>>>
>>> For some years I use littleCMS (and it is great, thanks Marti) and
>>> included it into a graphical software.
>>>
>>> Some of my dialog were color-matched, and some others were not (old
>>> architecture, lack of time, dev skill, etc...)
>>>
>>> Now, I'm searching an ICC profile (rgb color space) that I could
>>> substitute to the default screen profile so I could immediately see
>>> which dialog are color matched and which one are not...
>>> Does anyone here has such profile ? (for an example, a profile that
>>> turns everything to grayscale or darker or anything really different...)
>>> (of course, I could go to the code, but 250 dialog will take me a lot of
>>> time)
>>>
>>> Thanks for your help !
>>>
>>> Sébastien Léon
>>> Pointcarré Textile Software
>>>

Re: [Lcms-user] fake ICC profile to visualize quickly color matched areas...

[Sebastien L. <sl...@po...>]

Hi Kai-Uwe,

This looks perfect for my need !

Thanks a lot

Sébastien

Le 06/02/2019 à 13:53, Kai-Uwe Behrmann a écrit :
> Dear Sebastien,
>
> here are some effect profiles, which might be of use for your purpose:
>
> https://github.com/oyranos-cms/oyranos/files/1756684/vcgt-effects-icc.zip
>
> best regards
> Kai-Uwe
>
> Am 06.02.19 um 13:48 schrieb Sebastien Leon:
>> Hi guys,
>>
>> For some years I use littleCMS (and it is great, thanks Marti) and
>> included it into a graphical software.
>>
>> Some of my dialog were color-matched, and some others were not (old
>> architecture, lack of time, dev skill, etc...)
>>
>> Now, I'm searching an ICC profile (rgb color space) that I could
>> substitute to the default screen profile so I could immediately see
>> which dialog are color matched and which one are not...
>> Does anyone here has such profile ? (for an example, a profile that
>> turns everything to grayscale or darker or anything really different...)
>> (of course, I could go to the code, but 250 dialog will take me a lot of
>> time)
>>
>> Thanks for your help !
>>
>> Sébastien Léon
>> Pointcarré Textile Software
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Lcms-user mailing list
>> Lcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcms-user
>>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

[Lcms-user] fake ICC profile to visualize quickly color matched areas...

[Sébastien L. <sl...@ma...>]

Hi guys,

For some years I use littleCMS (and it is great, thanks Marti) and
included it into a graphical software.

Some of my dialog were color-matched, and some others were not (old
architecture, lack of time, dev skill, etc...)

Now, I'm searching an ICC profile (rgb color space) that I could
substitute to the default screen profile so I could immediately see
which dialog are color matched and which one are not...
Does anyone here has such profile ? (for an example, a profile that
turns everything to grayscale or darker or anything really different...)
(of course, I could go to the code, but 250 dialog will take me a lot of
time)

Thanks for your help !

Sébastien Léon
Pointcarré Textile Software

Re: [Lcms-user] fake ICC profile to visualize quickly color matched areas...

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

Dear Sebastien,

here are some effect profiles, which might be of use for your purpose:

https://github.com/oyranos-cms/oyranos/files/1756684/vcgt-effects-icc.zip

best regards
Kai-Uwe

Am 06.02.19 um 13:48 schrieb Sebastien Leon:
> Hi guys,
> 
> For some years I use littleCMS (and it is great, thanks Marti) and
> included it into a graphical software.
> 
> Some of my dialog were color-matched, and some others were not (old
> architecture, lack of time, dev skill, etc...)
> 
> Now, I'm searching an ICC profile (rgb color space) that I could
> substitute to the default screen profile so I could immediately see
> which dialog are color matched and which one are not...
> Does anyone here has such profile ? (for an example, a profile that
> turns everything to grayscale or darker or anything really different...)
> (of course, I could go to the code, but 250 dialog will take me a lot of
> time)
> 
> Thanks for your help !
> 
> Sébastien Léon
> Pointcarré Textile Software
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
> 

[Lcms-user] fake ICC profile to visualize quickly color matched areas...

[Sebastien L. <sl...@po...>]

Hi guys,

For some years I use littleCMS (and it is great, thanks Marti) and
included it into a graphical software.

Some of my dialog were color-matched, and some others were not (old
architecture, lack of time, dev skill, etc...)

Now, I'm searching an ICC profile (rgb color space) that I could
substitute to the default screen profile so I could immediately see
which dialog are color matched and which one are not...
Does anyone here has such profile ? (for an example, a profile that
turns everything to grayscale or darker or anything really different...)
(of course, I could go to the code, but 250 dialog will take me a lot of
time)

Thanks for your help !

Sébastien Léon
Pointcarré Textile Software

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

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

On Tue, 22 Jan 2019, Marti Maria wrote:
> 
> Yes,  lcms2.h does that, as most libraries written in C.
> 
>
>       Are people saying that with that, valid C99 is rejected by a C++17
>       compiler?  Is the idea that anything included must be valid C++17?  That
>       seems like an unreasonably large requirement on dependencies.
> 
> That seems to be the case.

Microsoft has publically declared their intention to not support C 
language features beyond C90 except for those required to support C++. 
Their focus is on C++.

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

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

[Marco F. <Mar...@en...>]

Well...

> Maybe I'm off base here, but I thought that when including a C header in
>C++, one should use
>
>  exterm "C"
>
>to specify C linkage.

lcms2.h already has an extern "C" { ... } block around declarations when included in c++ compiled code.. In this regard, yeah, it might be debatable if the error MSVC17 throws is not a false one; actually, it's a warning only, but by (default) compiler settings, these warnings are an error.

> Are people saying that with that, valid C99 is rejected by a C++17
> compiler?  Is the idea that anything included must be valid C++17?  That
> seems like an unreasonably large requirement on dependencies.

"register" as I know it is typically used within a function body to hint variables. It mainly guarantees, I think, that no-one will/can get the address of the variable, thus it could be heavily optimized by the compiler, including changing its address in memory (for example if it would optimize caching).
I think it's a borderline use case to use it for a function parameter at all, as usually how parameters are passed (how many are in registers anyways) is up to the platform; 
I would think that 99% of the compilers ignore the keyword anyways, because the internal optimization is better. Maybe a few old embedded or microcontroller compilers don't...  That's one of the reasons why the keyword was deprecated already in C++11 and guaranteed to be ignored by compiler (if not before, I'm not 100% sure). I think it's status just changed to "unused reserved keyword" with C++17 standard.
The problem is, I agree, that it MIGHT break ABI for those compilers that do not ignore it, but I guess we talk C compilers only anyways.

Marco

-----Ursprüngliche Nachricht-----
Von: Greg Troxel [mailto:gd...@le...] 
Gesendet: Dienstag, 22. Januar 2019 11:10
An: mar...@li...
Cc: Lcm...@li...; Bob Friesenhahn
Betreff: [EXTERNAL]Re: [Lcms-user] C++17 "register" warning when including lcms2.h

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

mar...@li... writes:

> 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:

Maybe I'm off base here, but I thought that when including a C header in
C++, one should use

  exterm "C"

to specify C linkage.

Are people saying that with that, valid C99 is rejected by a C++17
compiler?  Is the idea that anything included must be valid C++17?  That
seems like an unreasonably large requirement on dependencies.





_______________________________________________
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

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

<div dir='auto'>Hi,<br><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Maybe I'm off base here, but I thought that when including a C header in
<br>
C++, one should use
<br>

<br>
&nbsp; exterm "C"
<br>

<br>
to specify C linkage.
<br>

</p></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes,&nbsp; lcms2.h does that, as most libraries written in C.</div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
Are people saying that with that, valid C99 is rejected by a C++17
<br>
compiler?&nbsp; Is the idea that anything included must be valid C++17?&nbsp; That
<br>
seems like an unreasonably large requirement on dependencies.
<br>

</p></blockquote></div></div><div dir="auto">That seems to be the case.</div><div dir="auto"><br></div><div dir="auto">Anyway in the GIT there is a commit that implements the discussed changes. Next release will support it.</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">Marti</div></div>

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

[Greg T. <gd...@le...>]

mar...@li... writes:

> 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:

Maybe I'm off base here, but I thought that when including a C header in
C++, one should use

  exterm "C"

to specify C linkage.

Are people saying that with that, valid C99 is rejected by a C++17
compiler?  Is the idea that anything included must be valid C++17?  That
seems like an unreasonably large requirement on dependencies.

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

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

<div dir='auto'><div>That would have a severe impact on some embedded, and break ABI compatibility as well. Sorry, the default has to be compatible with previous versions.<div dir="auto">Marti</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jan 21, 2019 13:14, Christian Schmitz &lt;rea...@mo...&gt; wrote:<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">

<br>

<br>
I would suggest to remove register as default.
<br>

<br>
e.g. change register to __LCMS_REGISTER__ and than allow people to define 
<br>

<br>
#define __LCMS_REGISTER__ register
<br>

<br>
If they need it. But default I should go with next update.
<br>
It has no big effect so far. And when people update to newer version, they probably rebuild all their static libs and their own source code. For DLL register had no effect as far as I know.
<br>

<br>
So either remove it or keep a define as fallback for people who need it.
<br>

<br>
Just my humble opinion.
<br>

<br>
Sincerely
<br>
Christian
<br>

<br>
-- 
<br>
Read our blog about news on our plugins:
<br>

<br>
http://www.mbsplugins.de/
<br>

<br>

<br>

<br>

<br>
_______________________________________________
<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] C++17 "register" warning when including lcms2.h

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

> Am 21.01.2019 um 13:01 schrieb Hanno Hoffstadt <Han...@gm...>:
> 
> Sorry, too quick, that was only half the answer.
> While both options (remove only in params / completely) for static libs should be OK for me, I would prefer to have "CMS_NO_REGISTER_KEYWORD" remove register completely.


I would suggest to remove register as default.

e.g. change register to __LCMS_REGISTER__ and than allow people to define 

#define __LCMS_REGISTER__ register

If they need it. But default I should go with next update.
It has no big effect so far. And when people update to newer version, they probably rebuild all their static libs and their own source code. For DLL register had no effect as far as I know.

So either remove it or keep a define as fallback for people who need it.

Just my humble opinion.

Sincerely
Christian

-- 
Read our blog about news on our plugins:

http://www.mbsplugins.de/

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

[Marco F. <Mar...@en...>]

Very stupid question ...

I have simply circumvent this problem by using:
	#pragma warning(push)
	#pragma warning(disable:5033) // register variables
	#include <lcms2.h>
	#pragma warning(pop)
in my C++17 code.

Does anybody see a real Danger in that approach? 

Best regards,
Marco

-----Ursprüngliche Nachricht-----
Von: Hanno Hoffstadt [mailto:Han...@gm...] 
Gesendet: Montag, 21. Januar 2019 06:01
An: mar...@li...
Cc: Lcm...@li...; Bob Friesenhahn
Betreff: [EXTERNAL]Re: [Lcms-user] C++17 "register" warning when including lcms2.h

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

Sorry, too quick, that was only half the answer.
While both options (remove only in params / completely) for static libs should be OK for me, I would prefer to have "CMS_NO_REGISTER_KEYWORD" remove register completely.

Best regards
Hanno

> Am 21.01.2019 um 12:47 schrieb Hanno Hoffstadt <han...@gm...>:
> 
> Hi Marti,
> 
> for me, CMS_NO_REGISTER_KEYWORD would be a perfect solution.
> Thanks,
> 
> Hanno
> 
>> Am 21.01.2019 um 10:26 schrieb 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
>> 
> 


_______________________________________________
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

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

Sorry, too quick, that was only half the answer.
While both options (remove only in params / completely) for static libs should be OK for me, I would prefer to have "CMS_NO_REGISTER_KEYWORD" remove register completely.

Best regards
Hanno

> Am 21.01.2019 um 12:47 schrieb Hanno Hoffstadt <han...@gm...>:
> 
> Hi Marti,
> 
> for me, CMS_NO_REGISTER_KEYWORD would be a perfect solution.
> Thanks,
> 
> Hanno
> 
>> Am 21.01.2019 um 10:26 schrieb 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

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

Hi Marti,

for me, CMS_NO_REGISTER_KEYWORD would be a perfect solution.
Thanks,

Hanno

> Am 21.01.2019 um 10:26 schrieb 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
>