lcms-user — For users of the little cms library

Re: [Lcms-user] Build warnings on OSX / clang

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

Hi Marti,

 

Thanks for the feedback on seeing errors for interpolation and math; I'm sorry I broke something.  I was afraid that might happen, since I wasn't clear in a couple of places on whether the math was intended to actually able to handle negative numbers.  

 

I already have a pretty good idea of where the problems may be.  There is also a small chance I corrected some inaccuracies, but at this point I trust the test bed more than my own recent work.

 

I'll be happy to remake the changes against your latest sources from Git, assuming I can find them, since my changes are fresh in my mind and they really didn't take long to do.  

 

And I do need to take the time to enable the testbed and verify my work myself.

 

My intent is certainly not to make additional work for you so that everyone can gain the potential benefits of more rigorous compiler checking.

 

So everyone else on the mailing list:

 

Please at this point hold off taking the sources I posted before, at least until I can at least pass them through the testbed tests successfully or know exactly why they fail.

 

-Noel

 

From: Martí Maria [mailto:mar...@li...] 
Sent: Wed, July 26, 2017 3:50 AM
To: Noel Carboni; lcm...@li...
Cc: 'Aaron Boxer'
Subject: Re: [Lcms-user] Build warnings on OSX / clang

 

 

Hi Noel,

Many thanks for your hard work. There are, however, two important issues:

- You modified sources other than latest ones in GIT. That means all changes since 2.8 are lost.  Changes are big, and this means merging is difficult and error prone.

- The testbed reports multiple failures in critical parts like interpolation and math in general. This is bad :(

I would be glad to accept some changes to silence compiler warnings, but I'm afraid merging those all changes and make sure all is working would take me months that currently I don't have.

Regards

Marti.

 

On 7/26/2017 6:26 AM, Noel Carboni wrote:

Hi guys,

 

I've had a pass through the code.  I made several hundred changes to 20 or so source files, and now have it building here with warnings set to max in Visual Studio 2017.  Mostly the changes were to make unsigned variables out of signed variables, and I didn't have to add much casting.

 

I have tested it in my own application (which of course only exercises part of the library), and it seems to work great.  I'm not presently set up to run the battery of tests included with the software, so I hope someone can help with that.  It would be also interesting to know if other compilers (e.g., clang) find fault where Visual Studio does not.

Here's the source code:

 

http://Noel.ProDigitalSoftware.com/temp/LittleCMS_2.8NC.zip

 

I've made a number of changes to the release 2.8 sources with the following philosophies in mind:

 

1.  Don't alter the external interface (lcms2.h)

 

2.  Minimize the changes Marti will have to review and do them as safely as possible.

 

3.  Make the use of signed and unsigned types consistent to reduce the hundreds of warnings emitted when -Wall is used.

 

4.  Use as few casts as possible.

 

4.  Maintain efficiency.

 

 

With this set of files you can now enable -Wall in Visual Studio 2017 builds for ongoing LittleCMS development work, to gain the benefits of tighter type checking, but with the following caveats:

 

A.  You'll most likely want to specifically disable several of the -Wall warnings by putting the following additional options on the C/C++ compiler command line:

     

         /wd4711 /wd4820 /wd4061 /wd4774 /wd4710 /wd4668

 

     These specifically quiet the following Visual Studio 2017 C++ warnings, which may not be helpful to you:

 

         warning C4711: function 'xxxxxxxxxxxxxxxxx' selected for automatic inline expansion

         warning C4820: 'xxxxxxxx': 'n' bytes padding added after data member  

         warning C4061: enumerator 'xxxxxxxxxxxxx' in switch of enum 'yyyyyyyyyyyyy' is not explicitly handled by a case label

         warning C4774: '_snprintf' : format string expected in argument 3 is not a string literal

         warning C4710: 'int _snprintf(char *const ,const ::size_t,const char *const ,...)': function not inlined

         warning C4668: '_M_HYBRID_X86_ARM64' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'

 

B.  There is one warning, in cmsxform.c, that may indicate a real problem, especially in light of compilation of this library for different systems with different compilers.  Marti, you may want to review the code and decide whether to change it or suppress the warning:

 

         ..\..\..\src\cmsxform.c(799): warning C4191: 'type cast': unsafe conversion from '_cmsTransform2Fn' to '_cmsTransformFn'

 

The above text, to help Marti see what I've done, is also in a comment block in lcms2_internal.h.

 

I suggest careful review and testing of these changes should be done.  I don't think I have corrected any serious logic errors, and I hope I haven't caused any new ones.  The compiler's additional scrutiny can be brought to bear going forward to help Marti et. al. with ongoing development.

 

-Noel

 

From: Aaron Boxer [mailto:bo...@gm...] 
Sent: Mon, July 24, 2017 7:03 PM
To: Marti Maria
Cc: Noel Carboni; lcm...@li...
Subject: Re: [Lcms-user] Build warnings on OSX / clang

 

Thanks to Noel for offering fixes, and to Marti for graciously accepting :)

I've gone through similar issues with my JPEG 2000 codec, much of the code inherited from developers
who didn't worry about these issues.  I spent a lot of time converting signed to unsigned for all quantities
that must always be positive : number of image components, image dimensions, etc. 

Also, removed as many casts as possible. The code is now more resilient to overflow, and compiles with no 

warnings at maximum -Wall compiler settings. I think it is worth the effort.

Regards,

Aaron 







 

 

On Mon, Jul 24, 2017 at 6:31 PM, Marti Maria <mar...@li...> wrote:

Sounds great. All improvements are more than welcome.

Regards

Marti

 

On 25 Jul 2017 00:27, Noel Carboni <NCa...@Pr...> wrote:

Hi Marti,

 

As C/C++ programmers we have to face the fact that the language is growing ever more tightly typed.

 

It's not quite correct even to promote implicitly from signed to unsigned when you "just know" that the values will be small, since under some conditions negative numbers could have meaning.  Or worse, be given special meaning in the future.  It's tempting to return -1 as a special error or "not found" case, but that can ultimately cause conflict with code that expects only signed values.

 

It's only really properly done - and thus "safe" from future maintenance problems - if you use consistent types across the board, or add casts occasionally when you really do want to express that you're fitting a small positive unsigned value into a signed field.

 

Looking your released code over just now I think that it can be substantially cleaned up without a lot of casts added.  There are a lot of cases where you have a habit of using "int" when what you really want is "unsigned int" (e.g., for number of channels, where negative values don't have meaning).  :)

 

Tell you what; I'll go through all the code and see what I can come up with to get it down to zero warnings at max warning level.  I don't think it'll take me more than a few man-hours.  I'll send the result to you and you can compare the files and see whether you feel the changes are safe enough.  I'll make it my mission not to change the logic or your intent with the style.

                                                                      

-Noel

 

From: Marti Maria [mailto:mar...@li...] 
Sent: Mon, July 24, 2017 6:09 PM
To: Noel Carboni
Cc: lcm...@li...
Subject: Re: [Lcms-user] Build warnings on OSX / clang

 

Hi, 

 

Sometimes I use  signed to unsigned promotion without cast. This is safe  if values are small and positive. Mostly to avoid casts in memset, memmove, calloc, etc. which looks really ugly.

 

If you can found other cases, like that one in cmsgamma.c, please let me know. But this latter was fixed after the original report.

 

Regards

Marti

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

 

 

Re: [Lcms-user] Build warnings on OSX / clang

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

Thanks, Noel. Might be safer to do this on linux, where you can run make
check
to test. May I ask how I turn on -Wall on linux build for lcms ?

On Wed, Jul 26, 2017 at 12:26 AM, Noel Carboni <
NCa...@pr...> wrote:

> Hi guys,
>
>
>
> I've had a pass through the code.  I made several hundred changes to 20 or
> so source files, and now have it building here with warnings set to max in
> Visual Studio 2017.  Mostly the changes were to make unsigned variables out
> of signed variables, and I didn't have to add much casting.
>
>
>
> I have tested it in my own application (which of course only exercises
> part of the library), and it seems to work great.  I'm not presently set up
> to run the battery of tests included with the software, so I hope someone
> can help with that.  It would be also interesting to know if other
> compilers (e.g., clang) find fault where Visual Studio does not.
>
> Here's the source code:
>
>
>
> http://Noel.ProDigitalSoftware.com/temp/LittleCMS_2.8NC.zip
>
>
>
> I've made a number of changes to the release 2.8 sources with the
> following philosophies in mind:
>
>
>
> 1.  Don't alter the external interface (lcms2.h)
>
>
>
> 2.  Minimize the changes Marti will have to review and do them as safely
> as possible.
>
>
>
> 3.  Make the use of signed and unsigned types consistent to reduce the
> hundreds of warnings emitted when -Wall is used.
>
>
>
> 4.  Use as few casts as possible.
>
>
>
> 4.  Maintain efficiency.
>
>
>
>
>
> With this set of files you can now enable -Wall in Visual Studio 2017
> builds for ongoing LittleCMS development work, to gain the benefits of
> tighter type checking, but with the following caveats:
>
>
>
> A.  You'll most likely want to specifically disable several of the -Wall
> warnings by putting the following additional options on the C/C++ compiler
> command line:
>
>
>
>          /wd4711 /wd4820 /wd4061 /wd4774 /wd4710 /wd4668
>
>
>
>      These specifically quiet the following Visual Studio 2017 C++
> warnings, which may not be helpful to you:
>
>
>
>          warning C4711: function 'xxxxxxxxxxxxxxxxx' selected for
> automatic inline expansion
>
>          warning C4820: 'xxxxxxxx': 'n' bytes padding added after data
> member
>
>          warning C4061: enumerator 'xxxxxxxxxxxxx' in switch of enum
> 'yyyyyyyyyyyyy' is not explicitly handled by a case label
>
>          warning C4774: '_snprintf' : format string expected in argument 3
> is not a string literal
>
>          warning C4710: 'int _snprintf(char *const ,const ::size_t,const
> char *const ,...)': function not inlined
>
>          warning C4668: '_M_HYBRID_X86_ARM64' is not defined as a
> preprocessor macro, replacing with '0' for '#if/#elif'
>
>
>
> B.  There is one warning, in cmsxform.c, that may indicate a real problem,
> especially in light of compilation of this library for different systems
> with different compilers.  Marti, you may want to review the code and
> decide whether to change it or suppress the warning:
>
>
>
>          ..\..\..\src\cmsxform.c(799): warning C4191: 'type cast': unsafe
> conversion from '_cmsTransform2Fn' to '_cmsTransformFn'
>
>
>
> The above text, to help Marti see what I've done, is also in a comment
> block in lcms2_internal.h.
>
>
>
> I suggest careful review and testing of these changes should be done.  I
> don't think I have corrected any serious logic errors, and I hope I haven't
> caused any new ones.  The compiler's additional scrutiny can be brought to
> bear going forward to help Marti et. al. with ongoing development.
>
>
>
> -Noel
>
>
>
> *From:* Aaron Boxer [mailto:bo...@gm...]
> *Sent:* Mon, July 24, 2017 7:03 PM
> *To:* Marti Maria
> *Cc:* Noel Carboni; lcm...@li...
>
> *Subject:* Re: [Lcms-user] Build warnings on OSX / clang
>
>
>
> Thanks to Noel for offering fixes, and to Marti for graciously accepting :)
>
> I've gone through similar issues with my JPEG 2000 codec, much of the code
> inherited from developers
> who didn't worry about these issues.  I spent a lot of time converting
> signed to unsigned for all quantities
> that must always be positive : number of image components, image
> dimensions, etc.
>
> Also, removed as many casts as possible. The code is now more resilient to
> overflow, and compiles with no
>
> warnings at maximum -Wall compiler settings. I think it is worth the
> effort.
>
> Regards,
>
> Aaron
>
>
>
>
>
>
>
>
> On Mon, Jul 24, 2017 at 6:31 PM, Marti Maria <mar...@li...>
> wrote:
>
> Sounds great. All improvements are more than welcome.
>
> Regards
>
> Marti
>
>
>
> On 25 Jul 2017 00:27, Noel Carboni <NCa...@Pr...>
> wrote:
>
> Hi Marti,
>
>
>
> As C/C++ programmers we have to face the fact that the language is growing
> ever more tightly typed.
>
>
>
> It's not quite correct even to promote implicitly from signed to unsigned
> when you "just know" that the values will be small, since under some
> conditions negative numbers could have meaning.  Or worse, be given special
> meaning in the future.  It's tempting to return -1 as a special error or
> "not found" case, but that can ultimately cause conflict with code that
> expects only signed values.
>
>
>
> It's only really properly done - and thus "safe" from future maintenance
> problems - if you use consistent types across the board, or add casts
> occasionally when you really do want to express that you're fitting a small
> positive unsigned value into a signed field.
>
>
>
> Looking your released code over just now I think that it can be
> substantially cleaned up without a lot of casts added.  There are a lot of
> cases where you have a habit of using "int" when what you really want is
> "unsigned int" (e.g., for number of channels, where negative values don't
> have meaning).  :)
>
>
>
> Tell you what; I'll go through all the code and see what I can come up
> with to get it down to zero warnings at max warning level.  I don't think
> it'll take me more than a few man-hours.  I'll send the result to you and
> you can compare the files and see whether you feel the changes are safe
> enough.  I'll make it my mission not to change the logic or your intent
> with the style.
>
>
>
> -Noel
>
>
>
> *From:* Marti Maria [mailto:mar...@li...]
> *Sent:* Mon, July 24, 2017 6:09 PM
> *To:* Noel Carboni
> *Cc:* lcm...@li...
> *Subject:* Re: [Lcms-user] Build warnings on OSX / clang
>
>
>
> Hi,
>
>
>
> Sometimes I use  signed to unsigned promotion without cast. This is safe
>  if values are small and positive. Mostly to avoid casts in memset,
> memmove, calloc, etc. which looks really ugly.
>
>
>
> If you can found other cases, like that one in cmsgamma.c, please let me
> know. But this latter was fixed after the original report.
>
>
>
> Regards
>
> Marti
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>
>

Re: [Lcms-user] Build warnings on OSX / clang

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

Hi Noel,

Many thanks for your hard work. There are, however, two important issues:

- You modified sources other than latest ones in GIT. That means all 
changes since 2.8 are lost. Changes are big, and this means merging is 
difficult and error prone.

- The testbed reports multiple failures in critical parts like 
interpolation and math in general. This is bad :(

I would be glad to accept some changes to silence compiler warnings, but 
I'm afraid merging those all changes and make sure all is working would 
take me months that currently I don't have.

Regards

Marti.


On 7/26/2017 6:26 AM, Noel Carboni wrote:
>
> Hi guys,
>
> I've had a pass through the code.  I made several hundred changes to 
> 20 or so source files, and now have it building here with warnings set 
> to max in Visual Studio 2017.  Mostly the changes were to make 
> unsigned variables out of signed variables, and I didn't have to add 
> much casting.
>
> I have tested it in my own application (which of course only exercises 
> part of the library), and it seems to work great. I'm not presently 
> set up to run the battery of tests included with the software, so I 
> hope someone can help with that.  It would be also interesting to know 
> if other compilers (e.g., clang) find fault where Visual Studio does not.
>
> Here's the source code:
>
> http://Noel.ProDigitalSoftware.com/temp/LittleCMS_2.8NC.zip
>
> I've made a number of changes to the release 2.8 sources with the 
> following philosophies in mind:
>
> 1.  Don't alter the external interface (lcms2.h)
>
> 2.  Minimize the changes Marti will have to review and do them as 
> safely as possible.
>
> 3.  Make the use of signed and unsigned types consistent to reduce the 
> hundreds of warnings emitted when -Wall is used.
>
> 4.  Use as few casts as possible.
>
> 4.  Maintain efficiency.
>
> With this set of files you can now enable -Wall in Visual Studio 2017 
> builds for ongoing LittleCMS development work, to gain the benefits of 
> tighter type checking, but with the following caveats:
>
> A.  You'll most likely want to specifically disable several of the 
> -Wall warnings by putting the following additional options on the 
> C/C++ compiler command line:
>
>          /wd4711 /wd4820 /wd4061 /wd4774 /wd4710 /wd4668
>
> These specifically quiet the following Visual Studio 2017 C++ 
> warnings, which may not be helpful to you:
>
> warning C4711: function 'xxxxxxxxxxxxxxxxx' selected for automatic 
> inline expansion
>
> warning C4820: 'xxxxxxxx': 'n' bytes padding added after data member
>
>          warning C4061: enumerator 'xxxxxxxxxxxxx' in switch of enum 
> 'yyyyyyyyyyyyy' is not explicitly handled by a case label
>
> warning C4774: '_snprintf' : format string expected in argument 3 is 
> not a string literal
>
> warning C4710: 'int _snprintf(char *const ,const ::size_t,const char 
> *const ,...)': function not inlined
>
> warning C4668: '_M_HYBRID_X86_ARM64' is not defined as a preprocessor 
> macro, replacing with '0' for '#if/#elif'
>
> B.  There is one warning, in cmsxform.c, that may indicate a real 
> problem, especially in light of compilation of this library for 
> different systems with different compilers.  Marti, you may want to 
> review the code and decide whether to change it or suppress the warning:
>
> ..\..\..\src\cmsxform.c(799): warning C4191: 'type cast': unsafe 
> conversion from '_cmsTransform2Fn' to '_cmsTransformFn'
>
> The above text, to help Marti see what I've done, is also in a comment 
> block in lcms2_internal.h.
>
> I suggest careful review and testing of these changes should be done.  
> I don't think I have corrected any serious logic errors, and I hope I 
> haven't caused any new ones.  The compiler's additional scrutiny can 
> be brought to bear going forward to help Marti et. al. with ongoing 
> development.
>
> -Noel
>
> *From:*Aaron Boxer [mailto:bo...@gm...]
> *Sent:* Mon, July 24, 2017 7:03 PM
> *To:* Marti Maria
> *Cc:* Noel Carboni; lcm...@li...
> *Subject:* Re: [Lcms-user] Build warnings on OSX / clang
>
> Thanks to Noel for offering fixes, and to Marti for graciously 
> accepting :)
>
> I've gone through similar issues with my JPEG 2000 codec, much of the 
> code inherited from developers
> who didn't worry about these issues.  I spent a lot of time converting 
> signed to unsigned for all quantities
> that must always be positive : number of image components, image 
> dimensions, etc.
>
> Also, removed as many casts as possible. The code is now more 
> resilient to overflow, and compiles with no
>
> warnings at maximum -Wall compiler settings. I think it is worth the 
> effort.
>
> Regards,
>
> Aaron
>
>
>
>
> On Mon, Jul 24, 2017 at 6:31 PM, Marti Maria 
> <mar...@li... <mailto:mar...@li...>> wrote:
>
> Sounds great. All improvements are more than welcome.
>
> Regards
>
> Marti
>
> On 25 Jul 2017 00:27, Noel Carboni <NCa...@Pr... 
> <mailto:NCa...@Pr...>> wrote:
>
> Hi Marti,
>
> As C/C++ programmers we have to face the fact that the language is 
> growing ever more tightly typed.
>
> It's not quite correct even to promote implicitly from signed to 
> unsigned when you "just know" that the values will be small, since 
> under some conditions negative numbers could have meaning.  Or worse, 
> be given special meaning in the future.  It's tempting to return -1 as 
> a special error or "not found" case, but that can ultimately cause 
> conflict with code that expects only signed values.
>
> It's only really properly done - and thus "safe" from future 
> maintenance problems - if you use consistent types across the board, 
> or add casts occasionally when you really do want to express that 
> you're fitting a small positive unsigned value into a signed field.
>
> Looking your released code over just now I think that it can be 
> substantially cleaned up without a lot of casts added.  There are a 
> lot of cases where you have a habit of using "int" when what you 
> really want is "unsigned int" (e.g., for number of channels, where 
> negative values don't have meaning).  :)
>
> Tell you what; I'll go through all the code and see what I can come up 
> with to get it down to zero warnings at max warning level.  I don't 
> think it'll take me more than a few man-hours.  I'll send the result 
> to you and you can compare the files and see whether you feel the 
> changes are safe enough.  I'll make it my mission not to change the 
> logic or your intent with the style.
>
> -Noel
>
> *From:*Marti Maria [mailto:mar...@li... 
> <mailto:mar...@li...>]
> *Sent:* Mon, July 24, 2017 6:09 PM
> *To:* Noel Carboni
> *Cc:* lcm...@li... 
> <mailto:lcm...@li...>
> *Subject:* Re: [Lcms-user] Build warnings on OSX / clang
>
> Hi,
>
> Sometimes I use  signed to unsigned promotion without cast. This is 
> safe  if values are small and positive. Mostly to avoid casts in 
> memset, memmove, calloc, etc. which looks really ugly.
>
> If you can found other cases, like that one in cmsgamma.c, please let 
> me know. But this latter was fixed after the original report.
>
> Regards
>
> Marti
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li... <mailto:Lcm...@li...>
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

Re: [Lcms-user] Build warnings on OSX / clang

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

On 26 July 2017 at 05:26, Noel Carboni <NCa...@pr...> wrote:
> Here's the source code:
> http://Noel.ProDigitalSoftware.com/temp/LittleCMS_2.8NC.zip

Can you provide a patch please? With a patch I can test it with the
colord self tests which run on quite a few different types of machine.
Thanks.

Richard.

Re: [Lcms-user] Build warnings on OSX / clang

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

Hi guys,

 

I've had a pass through the code.  I made several hundred changes to 20 or so source files, and now have it building here with warnings set to max in Visual Studio 2017.  Mostly the changes were to make unsigned variables out of signed variables, and I didn't have to add much casting.

 

I have tested it in my own application (which of course only exercises part of the library), and it seems to work great.  I'm not presently set up to run the battery of tests included with the software, so I hope someone can help with that.  It would be also interesting to know if other compilers (e.g., clang) find fault where Visual Studio does not.

Here's the source code:

 

http://Noel.ProDigitalSoftware.com/temp/LittleCMS_2.8NC.zip

 

I've made a number of changes to the release 2.8 sources with the following philosophies in mind:

 

1.  Don't alter the external interface (lcms2.h)

 

2.  Minimize the changes Marti will have to review and do them as safely as possible.

 

3.  Make the use of signed and unsigned types consistent to reduce the hundreds of warnings emitted when -Wall is used.

 

4.  Use as few casts as possible.

 

4.  Maintain efficiency.

 

 

With this set of files you can now enable -Wall in Visual Studio 2017 builds for ongoing LittleCMS development work, to gain the benefits of tighter type checking, but with the following caveats:

 

A.  You'll most likely want to specifically disable several of the -Wall warnings by putting the following additional options on the C/C++ compiler command line:

     

         /wd4711 /wd4820 /wd4061 /wd4774 /wd4710 /wd4668

 

     These specifically quiet the following Visual Studio 2017 C++ warnings, which may not be helpful to you:

 

         warning C4711: function 'xxxxxxxxxxxxxxxxx' selected for automatic inline expansion

         warning C4820: 'xxxxxxxx': 'n' bytes padding added after data member  

         warning C4061: enumerator 'xxxxxxxxxxxxx' in switch of enum 'yyyyyyyyyyyyy' is not explicitly handled by a case label

         warning C4774: '_snprintf' : format string expected in argument 3 is not a string literal

         warning C4710: 'int _snprintf(char *const ,const ::size_t,const char *const ,...)': function not inlined

         warning C4668: '_M_HYBRID_X86_ARM64' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'

 

B.  There is one warning, in cmsxform.c, that may indicate a real problem, especially in light of compilation of this library for different systems with different compilers.  Marti, you may want to review the code and decide whether to change it or suppress the warning:

 

         ..\..\..\src\cmsxform.c(799): warning C4191: 'type cast': unsafe conversion from '_cmsTransform2Fn' to '_cmsTransformFn'

 

The above text, to help Marti see what I've done, is also in a comment block in lcms2_internal.h.

 

I suggest careful review and testing of these changes should be done.  I don't think I have corrected any serious logic errors, and I hope I haven't caused any new ones.  The compiler's additional scrutiny can be brought to bear going forward to help Marti et. al. with ongoing development.

 

-Noel

 

From: Aaron Boxer [mailto:bo...@gm...] 
Sent: Mon, July 24, 2017 7:03 PM
To: Marti Maria
Cc: Noel Carboni; lcm...@li...
Subject: Re: [Lcms-user] Build warnings on OSX / clang

 

Thanks to Noel for offering fixes, and to Marti for graciously accepting :)

I've gone through similar issues with my JPEG 2000 codec, much of the code inherited from developers
who didn't worry about these issues.  I spent a lot of time converting signed to unsigned for all quantities
that must always be positive : number of image components, image dimensions, etc. 

Also, removed as many casts as possible. The code is now more resilient to overflow, and compiles with no 

warnings at maximum -Wall compiler settings. I think it is worth the effort.

Regards,

Aaron 






 

 

On Mon, Jul 24, 2017 at 6:31 PM, Marti Maria <mar...@li...> wrote:

Sounds great. All improvements are more than welcome.

Regards

Marti

 

On 25 Jul 2017 00:27, Noel Carboni <NCa...@Pr...> wrote:

Hi Marti,

 

As C/C++ programmers we have to face the fact that the language is growing ever more tightly typed.

 

It's not quite correct even to promote implicitly from signed to unsigned when you "just know" that the values will be small, since under some conditions negative numbers could have meaning.  Or worse, be given special meaning in the future.  It's tempting to return -1 as a special error or "not found" case, but that can ultimately cause conflict with code that expects only signed values.

 

It's only really properly done - and thus "safe" from future maintenance problems - if you use consistent types across the board, or add casts occasionally when you really do want to express that you're fitting a small positive unsigned value into a signed field.

 

Looking your released code over just now I think that it can be substantially cleaned up without a lot of casts added.  There are a lot of cases where you have a habit of using "int" when what you really want is "unsigned int" (e.g., for number of channels, where negative values don't have meaning).  :)

 

Tell you what; I'll go through all the code and see what I can come up with to get it down to zero warnings at max warning level.  I don't think it'll take me more than a few man-hours.  I'll send the result to you and you can compare the files and see whether you feel the changes are safe enough.  I'll make it my mission not to change the logic or your intent with the style.

                                                                      

-Noel

 

From: Marti Maria [mailto:mar...@li...] 
Sent: Mon, July 24, 2017 6:09 PM
To: Noel Carboni
Cc: lcm...@li...
Subject: Re: [Lcms-user] Build warnings on OSX / clang

 

Hi, 

 

Sometimes I use  signed to unsigned promotion without cast. This is safe  if values are small and positive. Mostly to avoid casts in memset, memmove, calloc, etc. which looks really ugly.

 

If you can found other cases, like that one in cmsgamma.c, please let me know. But this latter was fixed after the original report.

 

Regards

Marti

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

 

Re: [Lcms-user] Build warnings on OSX / clang

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

Thanks to Noel for offering fixes, and to Marti for graciously accepting :)

I've gone through similar issues with my JPEG 2000 codec, much of the code
inherited from developers
who didn't worry about these issues.  I spent a lot of time converting
signed to unsigned for all quantities
that must always be positive : number of image components, image
dimensions, etc.
Also, removed as many casts as possible. The code is now more resilient to
overflow, and compiles with no
warnings at maximum -Wall compiler settings. I think it is worth the effort.

Regards,
Aaron






On Mon, Jul 24, 2017 at 6:31 PM, Marti Maria <mar...@li...>
wrote:

> Sounds great. All improvements are more than welcome.
> Regards
> Marti
>
> On 25 Jul 2017 00:27, Noel Carboni <NCa...@Pr...>
> wrote:
>
> Hi Marti,
>
>
>
> As C/C++ programmers we have to face the fact that the language is growing
> ever more tightly typed.
>
>
>
> It's not quite correct even to promote implicitly from signed to unsigned
> when you "just know" that the values will be small, since under some
> conditions negative numbers could have meaning.  Or worse, be given special
> meaning in the future.  It's tempting to return -1 as a special error or
> "not found" case, but that can ultimately cause conflict with code that
> expects only signed values.
>
>
>
> It's only really properly done - and thus "safe" from future maintenance
> problems - if you use consistent types across the board, or add casts
> occasionally when you really do want to express that you're fitting a small
> positive unsigned value into a signed field.
>
>
>
> Looking your released code over just now I think that it can be
> substantially cleaned up without a lot of casts added.  There are a lot of
> cases where you have a habit of using "int" when what you really want is
> "unsigned int" (e.g., for number of channels, where negative values don't
> have meaning).  :)
>
>
>
> Tell you what; I'll go through all the code and see what I can come up
> with to get it down to zero warnings at max warning level.  I don't think
> it'll take me more than a few man-hours.  I'll send the result to you and
> you can compare the files and see whether you feel the changes are safe
> enough.  I'll make it my mission not to change the logic or your intent
> with the style.
>
>
>
> -Noel
>
>
>
> *From:* Marti Maria [mailto:mar...@li...]
> *Sent:* Mon, July 24, 2017 6:09 PM
> *To:* Noel Carboni
> *Cc:* lcm...@li...
> *Subject:* Re: [Lcms-user] Build warnings on OSX / clang
>
>
>
> Hi,
>
>
>
> Sometimes I use  signed to unsigned promotion without cast. This is safe
>  if values are small and positive. Mostly to avoid casts in memset,
> memmove, calloc, etc. which looks really ugly.
>
>
>
> If you can found other cases, like that one in cmsgamma.c, please let me
> know. But this latter was fixed after the original report.
>
>
>
> Regards
>
> Marti
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

Re: [Lcms-user] Build warnings on OSX / clang

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

Hi Marti,

 

As C/C++ programmers we have to face the fact that the language is growing ever more tightly typed.

 

It's not quite correct even to promote implicitly from signed to unsigned when you "just know" that the values will be small, since under some conditions negative numbers could have meaning.  Or worse, be given special meaning in the future.  It's tempting to return -1 as a special error or "not found" case, but that can ultimately cause conflict with code that expects only signed values.

 

It's only really properly done - and thus "safe" from future maintenance problems - if you use consistent types across the board, or add casts occasionally when you really do want to express that you're fitting a small positive unsigned value into a signed field.

 

Looking your released code over just now I think that it can be substantially cleaned up without a lot of casts added.  There are a lot of cases where you have a habit of using "int" when what you really want is "unsigned int" (e.g., for number of channels, where negative values don't have meaning).  :)

 

Tell you what; I'll go through all the code and see what I can come up with to get it down to zero warnings at max warning level.  I don't think it'll take me more than a few man-hours.  I'll send the result to you and you can compare the files and see whether you feel the changes are safe enough.  I'll make it my mission not to change the logic or your intent with the style.

                                                                      

-Noel

 

From: Marti Maria [mailto:mar...@li...] 
Sent: Mon, July 24, 2017 6:09 PM
To: Noel Carboni
Cc: lcm...@li...
Subject: Re: [Lcms-user] Build warnings on OSX / clang

 

Hi, 

 

Sometimes I use  signed to unsigned promotion without cast. This is safe  if values are small and positive. Mostly to avoid casts in memset, memmove, calloc, etc. which looks really ugly.

 

If you can found other cases, like that one in cmsgamma.c, please let me know. But this latter was fixed after the original report.

 

Regards

Marti

Re: [Lcms-user] Build warnings on OSX / clang

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

Hello all,

Compiler warnings are available to show us where programmers have taken
liberties with the language, but have not acknowledged those liberties
(via a cast).  IMO, the C language implicit integer assignment rules
were a shortcoming of the language, leading to sloppy work, not a
feature.

In our projects all our code builds clean with Visual Studio's max
warning level (-Wall) and Code Analysis.  We don't allow warnings to
persist, and I honestly don't know why - other than economics - anyone
would want to set a project up to use anything less.

I don't mean to be critical of Marti's code - it's very good overall and
emits no warnings with Visual Studio 2017 on level 4 (which is better
than most source projects), but it DOES gather hundreds of warnings when
set to -Wall, many of which are of the form:

..\..\..\src\cmsgamma.c(143): warning C4365: '=': conversion from
'cmsUInt32Number' to 'int', signed/unsigned mismatch

Unfortunately, it really IS a coding error to expect an unsigned integer
to fit implicitly into a signed integer.   If you "just know" that there
can be no sign problems, then the code should reflect that.

The right solution is not to add casts, but rather to change the code so
that the data types DO match one another - or in a pinch use explicit
casts in the code (with appropriate comments) indicating that the
disparity has been noted and is expected and okay.

In the specific case identified (an unsigned 32 bit number being copied
to a signed 32 bit value) we can't know, without careful analysis of the
code, whether there can be (now, or in the future) a negative number or
positive 32 bit number larger than 2^31 passed around.  That's a gotcha
that should not be left in.

If types have to change, of course it's necessary to work out the
problems each code change could cause.   That's the cost of creating
truly good code.

The upside is that when it's done the code can be consistently compiled
with the highest warning level, which helps keep errors from creeping in
during ongoing development.

Marti, I'm willing to take a look at reducing the warning count if
you're willing to entertain putting the changes back into your sources
(as you have done in the past).

-Noel Carboni
 ProDigital Software

Re: [Lcms-user] Build warnings on OSX / clang

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

> Thanks. I've turned on this warning in my build because the implicit
>> conversion can cause
>> hard-to-trace bugs.
>>
>
> Inappropriate explicit casts in the C code can also cause hard-to-trace
> bugs and explicit casts should be minimized.  I think that usually implicit
> type conversion should be preferred over many explicit casts.  Regardless,
> type conversion should be minimized as much as possible.
>

Absolutely agree - casts are a necessary evil :)

>
> Not all compiler warnings are intended to be enabled for normal use.
>
> Yes, I suppose I could disable the warning for production.

Aaron

Re: [Lcms-user] Build warnings on OSX / clang

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

On Mon, 24 Jul 2017, Aaron Boxer wrote:

> Hi Marti,
>
> Thanks. I've turned on this warning in my build because the implicit
> conversion can cause
> hard-to-trace bugs.

Inappropriate explicit casts in the C code can also cause 
hard-to-trace bugs and explicit casts should be minimized.  I think 
that usually implicit type conversion should be preferred over many 
explicit casts.  Regardless, type conversion should be minimized as 
much as possible.

Not all compiler warnings are intended to be enabled for normal use.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: [Lcms-user] Build warnings on OSX / clang

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

Hi Marti,

Thanks. I've turned on this warning in my build because the implicit
conversion can cause
hard-to-trace bugs.

Regards,
Aaron

On Mon, Jul 24, 2017 at 3:10 AM, Martí Maria <mar...@li...>
wrote:

>
> Thanks for reporting.
>
> lcms uses the C feature of implicit sign conversion, so if you activate
> -Wsign-conversion you will get some warnings.
>
> This not set in the included build system.
>
> Regards
>
> Marti
>
> On 7/24/2017 3:16 AM, Aaron Boxer wrote:
>
> Hello,
> Just wanted to report a few warnings I am getting when building with clang.
>
> http://my.cdash.org/viewBuildError.php?type=1&buildid=1257347
>
> For example:
>
> <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L143'>grok/thirdparty/liblcms2/src/cmsgamma.c:143</a>:32: warning: implicit conversion changes signedness: 'cmsUInt32Number' (aka 'unsigned int') to 'int' [-Wsign-conversion]
>     fl ->nFunctions = Plugin ->nFunctions;
>                     ~ ~~~~~~~~~^~~~~~~~~~
> <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L150'>grok/thirdparty/liblcms2/src/cmsgamma.c:150</a>:63: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion]
>     memmove(fl->FunctionTypes,  Plugin ->FunctionTypes,   fl->nFunctions * sizeof(cmsUInt32Number));
>
>
> Thanks,
>
> Aaron
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Lcms-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

Re: [Lcms-user] Build warnings on OSX / clang

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

Thanks for reporting.

lcms uses the C feature of implicit sign conversion, so if you activate 
-Wsign-conversion you will get some warnings.

This not set in the included build system.

Regards

Marti


On 7/24/2017 3:16 AM, Aaron Boxer wrote:
> Hello,
> Just wanted to report a few warnings I am getting when building with 
> clang.
>
> http://my.cdash.org/viewBuildError.php?type=1&buildid=1257347
>
> For example:
>
> <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L143'>grok/thirdparty/liblcms2/src/cmsgamma.c:143</a>:32: warning: implicit conversion changes signedness: 'cmsUInt32Number' (aka 'unsigned int') to 'int' [-Wsign-conversion]
>      fl ->nFunctions = Plugin ->nFunctions;
>                      ~ ~~~~~~~~~^~~~~~~~~~
> <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L150'>grok/thirdparty/liblcms2/src/cmsgamma.c:150</a>:63: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion]
>      memmove(fl->FunctionTypes,  Plugin ->FunctionTypes,   fl->nFunctions * sizeof(cmsUInt32Number));
>
> Thanks,
> Aaron
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Build warnings on OSX / clang

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

Hello,
Just wanted to report a few warnings I am getting when building with clang.

http://my.cdash.org/viewBuildError.php?type=1&buildid=1257347

For example:

<a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L143'>grok/thirdparty/liblcms2/src/cmsgamma.c:143</a>:32:
warning: implicit conversion changes signedness: 'cmsUInt32Number'
(aka 'unsigned int') to 'int' [-Wsign-conversion]
    fl ->nFunctions = Plugin ->nFunctions;
                    ~ ~~~~~~~~~^~~~~~~~~~
<a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L150'>grok/thirdparty/liblcms2/src/cmsgamma.c:150</a>:63:
warning: implicit conversion changes signedness: 'int' to 'unsigned
long' [-Wsign-conversion]
    memmove(fl->FunctionTypes,  Plugin ->FunctionTypes,
fl->nFunctions * sizeof(cmsUInt32Number));

Thanks,

Aaron

Re: [Lcms-user] Language code backwards? ne_SU instead of en_US

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

Sounds like possibly a "Big Endian" vs. "Little Endian" processor
difference - i.e., the order things are stored in RAM (most significant
bits first vs. last).  Probably most computer systems in the world now
are the latter, since Intel is so dominant (PCs and Macs).

It might help to know what hardware you're running it on.  I'm guessing
it's a system with a Big Endian processor.

-Noel

-----Original Message-----
From: Kornel [mailto:mai...@po...]
Sent: Wed, June 14, 2017 8:56 AM
To: lcm...@li...
Subject: [Lcms-user] Language code backwards? ne_SU instead of en_US

I've noticed that language and country codes given by MLU functions are
backwards. When querying an ICC file containing "enUS" locale, I get
"ne" language and "SU" country.

Here's a program to reproduce:

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

int main() {
    cmsHPROFILE p =
cmsOpenProfileFromFile("/Library/ColorSync/Profiles/WebSafeColors.icc",
"r"); // This profile is standard on OS X and I've verified with hexdump
that locales are in a normal byte order
    cmsMLU *mlu = cmsReadTag(p, cmsSigProfileDescriptionMLTag);

    int cnt = cmsMLUtranslationsCount(mlu);
    for(int i=0; i < cnt; i++) {
        char lang[3] = {0};
        char country[3] = {0};
        cmsMLUtranslationsCodes(mlu, i, lang, country);
        printf("%s %s\n", lang, country);
    }
}

It outputs:

ks KS
ne SU
ac SE
iv NV
tp RB
ku AU
rf UF
uh UH
hz WT
bn ON
ok RK
sc ZC
eh LI
or OR
ed ED
ti TI
vs ES
hz NC
aj PJ
le RG
tp OP
ln LN
se SE
ht HT
rt RT
if IF
rh RH
lp LP
ur UR
ra GE
ad KD
------------------------------------------------------------------------
------
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Language code backwards? ne_SU instead of en_US

[Kornel <mai...@po...>]

I've noticed that language and country codes given by MLU functions are backwards. When querying an ICC file containing "enUS" locale, I get "ne" language and "SU" country.

Here's a program to reproduce:

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

int main() {
    cmsHPROFILE p = cmsOpenProfileFromFile("/Library/ColorSync/Profiles/WebSafeColors.icc", "r"); // This profile is standard on OS X and I've verified with hexdump that locales are in a normal byte order
    cmsMLU *mlu = cmsReadTag(p, cmsSigProfileDescriptionMLTag);

    int cnt = cmsMLUtranslationsCount(mlu);
    for(int i=0; i < cnt; i++) {
        char lang[3] = {0};
        char country[3] = {0};
        cmsMLUtranslationsCodes(mlu, i, lang, country);
        printf("%s %s\n", lang, country);
    }
}

It outputs:

ks KS
ne SU
ac SE
iv NV
tp RB
ku AU
rf UF
uh UH
hz WT
bn ON
ok RK
sc ZC
eh LI
or OR
ed ED
ti TI
vs ES
hz NC
aj PJ
le RG
tp OP
ln LN
se SE
ht HT
rt RT
if IF
rh RH
lp LP
ur UR
ra GE
ad KD

[Lcms-user] Is TYPE_XYZA_FLT safe to use?

[Tobias E. <me...@ho...>]

Hi,

just a quick question: I want to use TYPE_XYZA_FLT in my code which is still 
mentioned in the recent API documentation. However, it seems that it was 
removed from lcms2 in 2.4 rc2 (d00163e17de9399a77138d035104ff1786d89d1d).

Is there a reason not to use it? For the time being I can just #define it 
myself the way it used to be done before, but maybe I am missing something?

Tobias

[Lcms-user] Static analysis warning

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

I get this warning on the latest master when running VS 2015 static
analyzer:

cmsplugin.c(967): warning C28182: Dereferencing NULL pointer. 'prev'
contains the same NULL value as '_cmsContextPoolHead' did.

Re: [Lcms-user] Create ICC V2 profile

[Terence T. <ter...@gm...>]

Hi Marti,

Thanks! That was easy. :-)

Follow-up question: do you think an app should write V4 profiles by default
and only switch to a V2 profile when the user explicitly wants the output
to be backward compatible with old software? Or do you think an app should
write V2 profiles by default and switch to a V4 profile when there is a
need to take advantage of V4 features?

Terence

On Wed, Apr 12, 2017 at 3:27 PM, Marti Maria <mar...@li...>
wrote:

> Hi Terence,
> It is easy. Just set the version to 2.0 prior saving. The library will do
> all necessary conversions to get a V2 compliant profile. Many V2 profiles
> are marked as using 3.4
>
> Regards
> Marti
>
>
>
>
> On 12 Apr 2017 18:29, Terence Tay <ter...@gm...> wrote:
>
> Hello,
>
> I am currently using LCMS to create profiles using cmsCreateRGBProfile()
> and by specifying the primaries, tone curve and white point.
>
> Then I use cmsSaveProfileToMem() to save this profile to an array of
> bytes, which is then embedded in the image format (usually JPEG or TIFF).
>
> It looks like the ICC profiles created in this way are V4 profiles. Some
> older software (like Windows Photo Viewer) don't read V4 profiles.
>
> How can I create V2 versions of these profiles?
>
> Thanks.
>
>
>

[Lcms-user] Create ICC V2 profile

[Terence T. <ter...@gm...>]

Hello,

I am currently using LCMS to create profiles using cmsCreateRGBProfile()
and by specifying the primaries, tone curve and white point.

Then I use cmsSaveProfileToMem() to save this profile to an array of bytes,
which is then embedded in the image format (usually JPEG or TIFF).

It looks like the ICC profiles created in this way are V4 profiles. Some
older software (like Windows Photo Viewer) don't read V4 profiles.

How can I create V2 versions of these profiles?

Thanks.

Re: [Lcms-user] Check Out-of-gamut in Output CMYK Profile

[Sapaico-Valera, R. <ric...@oc...>]

Hello Marti,

I really appreciate your quick reply.
After I did like you suggested the Gamut Check is working.

Thanks a lot, and have a great day.

Best regards,
Ricardo


From: Marti Maria [mailto:mar...@li...]
Sent: Wednesday, April 12, 2017 14:29
To: Sapaico-Valera, Ricardo
Cc: lcm...@li...
Subject: Re: [Lcms-user] Check Out-of-gamut in Output CMYK Profile

Hi, you need to use the built-in lab identity for input and the formatter would be TYPE_Lab_DBL,
Then instead of sRGB, put your CMYK profile. You may alsowant to check the result with transicc.

Regards
Marti

On 12 Apr 2017 10:11, "Sapaico-Valera, Ricardo" <ric...@oc...<mailto:ric...@oc...>> wrote:

Hello,



I have an output CMYK ICC profile, which I created using a printing RIP software.



Using MATLAB, I can verify that in the ICC Profile Header:

Device Class=’output’

ColorSpace=’CMYK’

ConnectionSpace=’Lab

RenderingIntent = ‘Perceptual’

Version=’4.0.0’

Also, when I take a look at the ‘CLUT’ structures in the Profile, I can see that they are in the uint16 format.



Using an ICC profile viewer, I am able to find out whether a Lab value is inside or outside the gamut.

However, I would like to test programmatically whether a list (~1000) of Lab values is inside or outside the gamut.

From what I found in the mailing list, I am using the following code:



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

cmsHPROFILE hInProfile, hNULL;

cmsHTRANSFORM xform;



cmsUInt16Number Alarm[16] = { 0xFF, 0xFF, 0xFF };

cmsSetAlarmCodes(Alarm);



hInProfile = cmsOpenProfileFromFile("MyICCProfile.icc", "r");

if (hInProfile == NULL) return 0;  // Failed



hNULL = cmsCreateNULLProfile();



xform = cmsCreateProofingTransform(

        hInProfile,                                         // Input

        TYPE_CMYK_16,                             // Input Format

        hNULL,                                              // Output

        TYPE_GRAY_8,                              // Output Format

        cmsCreate_sRGBProfile(),       // Proofing

        INTENT_RELATIVE_COLORIMETRIC,                       // Intent

        INTENT_RELATIVE_COLORIMETRIC,                       // Proofing Intent

        cmsFLAGS_GAMUTCHECK                                 // Flags

    );



cmsCIELab Lab1 = { 83.53, 5.35, 15.22 };

cmsCIELab Lab2 = { 12.75, -6.35, -2.32 };



cmsUInt8Number gamut;

cmsDoTransform(xform, &Lab1, &gamut, 1);

cmsDoTransform(xform, &Lab2, &gamut, 1);



cmsDeleteTransform(xform);

cmsCloseProfile(hInProfile);

cmsCloseProfile(hNULL);

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



Using the Profile Gamut viewer, I know that the value ‘Lab1’ is inside, and ‘Lab2’ is outside.

However, when I ran the code above, I get both of them as inside.

Next, I thought maybe if I changed the input to cmsDoTransform to be the corresponding CMYK values it might work:



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

cmsUInt16Number CMYK1[4], CMYK2[4];

CMYK1[0] = 6553; CMYK1[1] = 13107; CMYK1[2] = 19660; CMYK1[3] = 0;                // C=10%, M=20%, Y=30%, K=0%   -> should be in-gamut

CMYK2[0] = 52428; CMYK2[1] = 42597; CMYK2[2] = 42597; CMYK2[3] = 39321;    // C=80%, M=65%, Y=65%, K=60%   -> should be out-of-gamut

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



But it didn’t help, and I still get “gamut=0” for both CMYK values (I even tried with extreme values as C=M=Y=K=0% and C=M=Y=K=100%, to no avail).



I did some debugging and I found something it might help.

In ‘cmslut.c’, in the “_LUTeval16” function (lines 1294..1314), the variable “lut->InputChannels” is 3;

however, I was expecting it to be 4, since I’m working with CMYK values.

Moreover, the correct 16-bit CMYK values are stored in the variable In[].



Could you please let me know what I am doing wrong?

I have the suspicion that my input to the ‘cmsDoTransform’ might not be ok; but I cannot figure it out what else I could try.



Thank you very much in advance for your help.



Best regards,

Ricardo Sapaico
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

[Lcms-user] Check Out-of-gamut in Output CMYK Profile

[Sapaico-Valera, R. <ric...@oc...>]

Hello,

I have an output CMYK ICC profile, which I created using a printing RIP software.

Using MATLAB, I can verify that in the ICC Profile Header:
Device Class='output'
ColorSpace='CMYK'
ConnectionSpace='Lab
RenderingIntent = 'Perceptual'
Version='4.0.0'
Also, when I take a look at the 'CLUT' structures in the Profile, I can see that they are in the uint16 format.

Using an ICC profile viewer, I am able to find out whether a Lab value is inside or outside the gamut.
However, I would like to test programmatically whether a list (~1000) of Lab values is inside or outside the gamut.
>From what I found in the mailing list, I am using the following code:

---------------------------------------------------
cmsHPROFILE hInProfile, hNULL;
cmsHTRANSFORM xform;

cmsUInt16Number Alarm[16] = { 0xFF, 0xFF, 0xFF };
cmsSetAlarmCodes(Alarm);

hInProfile = cmsOpenProfileFromFile("MyICCProfile.icc", "r");
if (hInProfile == NULL) return 0;  // Failed

hNULL = cmsCreateNULLProfile();

xform = cmsCreateProofingTransform(
        hInProfile,                                         // Input
        TYPE_CMYK_16,                             // Input Format
        hNULL,                                              // Output
        TYPE_GRAY_8,                              // Output Format
        cmsCreate_sRGBProfile(),       // Proofing
        INTENT_RELATIVE_COLORIMETRIC,                       // Intent
        INTENT_RELATIVE_COLORIMETRIC,                       // Proofing Intent
        cmsFLAGS_GAMUTCHECK                                 // Flags
    );

cmsCIELab Lab1 = { 83.53, 5.35, 15.22 };
cmsCIELab Lab2 = { 12.75, -6.35, -2.32 };

cmsUInt8Number gamut;
cmsDoTransform(xform, &Lab1, &gamut, 1);
cmsDoTransform(xform, &Lab2, &gamut, 1);

cmsDeleteTransform(xform);
cmsCloseProfile(hInProfile);
cmsCloseProfile(hNULL);
---------------------------------------------------

Using the Profile Gamut viewer, I know that the value 'Lab1' is inside, and 'Lab2' is outside.
However, when I ran the code above, I get both of them as inside.
Next, I thought maybe if I changed the input to cmsDoTransform to be the corresponding CMYK values it might work:

---------------------------------------------------
cmsUInt16Number CMYK1[4], CMYK2[4];
CMYK1[0] = 6553; CMYK1[1] = 13107; CMYK1[2] = 19660; CMYK1[3] = 0;                // C=10%, M=20%, Y=30%, K=0%   -> should be in-gamut
CMYK2[0] = 52428; CMYK2[1] = 42597; CMYK2[2] = 42597; CMYK2[3] = 39321;    // C=80%, M=65%, Y=65%, K=60%   -> should be out-of-gamut
---------------------------------------------------

But it didn't help, and I still get "gamut=0" for both CMYK values (I even tried with extreme values as C=M=Y=K=0% and C=M=Y=K=100%, to no avail).

I did some debugging and I found something it might help.
In 'cmslut.c', in the "_LUTeval16" function (lines 1294..1314), the variable "lut->InputChannels" is 3;
however, I was expecting it to be 4, since I'm working with CMYK values.
Moreover, the correct 16-bit CMYK values are stored in the variable In[].

Could you please let me know what I am doing wrong?
I have the suspicion that my input to the 'cmsDoTransform' might not be ok; but I cannot figure it out what else I could try.

Thank you very much in advance for your help.

Best regards,
Ricardo Sapaico
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

[Lcms-user] PNG, Gamma and JPEG 2000

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

Hello,
Sorry, this is a bit off topic, but does anyone have an opinion about the
following situation:

Suppose I want to compress a PNG image to JPEG 2000, where the PNG has
gamma correction.
JPEG 2000 has no way of storing gamma correction, apparently.

Should I just ignore gamma, or try to apply it to the PNG before
compressing.

Thanks so much,
Aaron

Re: [Lcms-user] Regression? Added a check on LUT consistency

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

Hi Marti,

Thanks for the fix, but it's still not quite right; I still get NULL
for the transform.

Richard.

On 13 March 2017 at 09:27, Martí Maria <mar...@li...> wrote:
>
> Thanks Richard,
>
> It is now fixed per a99291c
>
> https://github.com/mm2/Little-CMS/commit/a99291c5bdaaf1637c2b3389c3deae76c61ce157
>
> Regards
> Marti
>
>
> On 3/11/2017 9:15 PM, Richard Hughes wrote:
>
> Since 9936ecf0745002cea8e46dc575079b4872e9af8c in lcms2 I'm getting a
> failure on the colord self tests:
>
> What the self test is trying to do is creating a proofing transform
> with gamut check, so we can getting the coverage of one profile of
> another, i.e. to approximate the gamut intersection. e.g.
>
> profile_null = cmsCreateNULLProfileTHR (ctx);
> transform = cmsCreateProofingTransformTHR (ctx,
>   hnd1,
>   TYPE_RGB_FLT,
>   profile_null,
>   TYPE_GRAY_FLT,
>   hnd2,
>   INTENT_ABSOLUTE_COLORIMETRIC,
>   INTENT_ABSOLUTE_COLORIMETRIC,
>   cmsFLAGS_GAMUTCHECK |
>   cmsFLAGS_SOFTPROOFING);
>
> Since 9936ecf0 the transform is coming back NULL. Am I doing something
> broken, or is this indeed a regression?
>
> Richard.
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

Re: [Lcms-user] Regression? Added a check on LUT consistency

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

Thanks Richard,

It is now fixed per |a99291c|

|https://github.com/mm2/Little-CMS/commit/a99291c5bdaaf1637c2b3389c3deae76c61ce157
|

Regards
Marti

On 3/11/2017 9:15 PM, Richard Hughes wrote:
> Since 9936ecf0745002cea8e46dc575079b4872e9af8c in lcms2 I'm getting a
> failure on the colord self tests:
>
> What the self test is trying to do is creating a proofing transform
> with gamut check, so we can getting the coverage of one profile of
> another, i.e. to approximate the gamut intersection. e.g.
>
> profile_null = cmsCreateNULLProfileTHR (ctx);
> transform = cmsCreateProofingTransformTHR (ctx,
>    hnd1,
>    TYPE_RGB_FLT,
>    profile_null,
>    TYPE_GRAY_FLT,
>    hnd2,
>    INTENT_ABSOLUTE_COLORIMETRIC,
>    INTENT_ABSOLUTE_COLORIMETRIC,
>    cmsFLAGS_GAMUTCHECK |
>    cmsFLAGS_SOFTPROOFING);
>
> Since 9936ecf0 the transform is coming back NULL. Am I doing something
> broken, or is this indeed a regression?
>
> Richard.
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>

[Lcms-user] Regression? Added a check on LUT consistency

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

Since 9936ecf0745002cea8e46dc575079b4872e9af8c in lcms2 I'm getting a
failure on the colord self tests:

What the self test is trying to do is creating a proofing transform
with gamut check, so we can getting the coverage of one profile of
another, i.e. to approximate the gamut intersection. e.g.

profile_null = cmsCreateNULLProfileTHR (ctx);
transform = cmsCreateProofingTransformTHR (ctx,
  hnd1,
  TYPE_RGB_FLT,
  profile_null,
  TYPE_GRAY_FLT,
  hnd2,
  INTENT_ABSOLUTE_COLORIMETRIC,
  INTENT_ABSOLUTE_COLORIMETRIC,
  cmsFLAGS_GAMUTCHECK |
  cmsFLAGS_SOFTPROOFING);

Since 9936ecf0 the transform is coming back NULL. Am I doing something
broken, or is this indeed a regression?

Richard.