lcms-user — For users of the little cms library

Re: [Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

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

Am 19.05.2016 um 14:10 schrieb Elle Stone:
> On 05/19/2016 02:03 AM, Kai-Uwe Behrmann wrote:
> So there wasn't an equivalent Cinepaint option for "simulate black ink"?
> (If there's a way to compile Cinepaint on Gentoo, I haven't found it.)

I never thought about that. Oyranos git should be in Gentoo. At least we
obtain patches from Gentoo.

> Did/does the Cinepaint/Oyranos
> "simulate paper" match the PhotoShop "simulate paper"?

Back when implementing that stuff, I checked visually with lots of
prints and light both comparisons and found satisfying results in
CinePaint. However, my goal was not to blindly follow PhotoShop. So no
guarantee for identical output.

kind regards
Kai-Uwe

Re: [Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

[Elle S. <ell...@ni...>]

On 05/19/2016 02:03 AM, Kai-Uwe Behrmann wrote:
> Am 18.05.2016 um 21:16 schrieb Elle Stone:
>> Can LCMS be used to provide soft proofing options like PhotoShop's
>> "simulate black ink" and "simulate paper"?
>>
>> I seem to remember seeing similar options in Cinepaint, which used LCMS
>> version 1. But looking in the Cinepaint code, all I see is this:
>>
>> menus_set_state ("<Image>/View/Simulatate Paper", gdisp->cms_proof_flags
>> ==INTENT_ABSOLUTE_COLORIMETRIC);
>

So there wasn't an equivalent Cinepaint option for "simulate black ink"? 
(If there's a way to compile Cinepaint on Gentoo, I haven't found it.)

> For the lcms2 API one needs to set the adaption state as well in order
> to obtain a monitor to light both match. That way the
> oyranos-image-display viewer shows the same result like with lcms1.

Thanks! That is a helpful pointer. Did/does the Cinepaint/Oyranos 
"simulate paper" match the PhotoShop "simulate paper"?

Best,
Elle

Re: [Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

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

Am 18.05.2016 um 21:16 schrieb Elle Stone:
> Can LCMS be used to provide soft proofing options like PhotoShop's 
> "simulate black ink" and "simulate paper"?
> 
> I seem to remember seeing similar options in Cinepaint, which used LCMS 
> version 1. But looking in the Cinepaint code, all I see is this:
> 
> menus_set_state ("<Image>/View/Simulatate Paper", gdisp->cms_proof_flags 
> ==INTENT_ABSOLUTE_COLORIMETRIC);

For the lcms2 API one needs to set the adaption state as well in order
to obtain a monitor to light both match. That way the
oyranos-image-display viewer shows the same result like with lcms1.

kind regards
Kai-Uwe

Re: [Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

[Florian H. <lis...@ho...>]

Am 18.05.2016 um 21:16 schrieb Elle Stone:
> The Cinepaint code almost looks like absolute colorimetric intent is
> the same as  "simulate paper". But that can't be right, can it?

That should be right.

> And even if that's what the Cinepaint code actually did, is the
> PhotoShop option doing something else?

Not as far as I know.

When "Simulate paper" is checked, PS uses abs. col.
When only "Simulate black ink" is checked, PS uses rel. col.
If neither are checked, PS uses rel. col. with black point compensation.

Cheers,

Florian.

[Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

[Elle S. <ell...@ni...>]

Can LCMS be used to provide soft proofing options like PhotoShop's 
"simulate black ink" and "simulate paper"?

I seem to remember seeing similar options in Cinepaint, which used LCMS 
version 1. But looking in the Cinepaint code, all I see is this:

menus_set_state ("<Image>/View/Simulatate Paper", gdisp->cms_proof_flags 
==INTENT_ABSOLUTE_COLORIMETRIC);

The Cinepaint code almost looks like absolute colorimetric intent is the 
same as  "simulate paper". But that can't be right, can it? And even if 
that's what the Cinepaint code actually did, is the PhotoShop option 
doing something else?

Best,
Elle

Re: [Lcms-user] in-place transformation problem

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

Hi,

Looks like you are calling cmsDoTransform() with the number of bytes instead of the number of pixels.

Regards
Marti

On May 5, 2016 11:14 AM, Andreas Frisch <fra...@op...> wrote:
>
> Hi guys, 
>
> i wrote a gstreamer wrapper element for littlecms ( https:// 
> bugzilla.gnome.org/attachment.cgi?id=327238 ) 
>
> I've observed that the functions cmsDoTransformStride and cmsDoTransform 
> overwrite the subsequent data in my buffer plane if input and output pointers 
> are pointing to the same position in memory (in-place transformation). 
>
> i wrote a simple test case which shows this issue. 
> $ gcc -Wall -g `pkg-config lcms2 --cflags --libs` lcms-memory-corruption- 
> testcase.c -o lcms-memory-corruption-testcase 
> $ ./lcms-memory-corruption-testcase CP955_F.icc 
> initalize 3 rows with 4 bpp = 12 bytes of source data... 
> initalized source data looks like: 
> row 0@0x1f63a20 0xF0E0D0FF 
> row 1@0x1f63a24 0xF1E1D1FF 
> row 2@0x1f63a28 0xF2E2D2FF 
>
> doing transformation data->new_data... 
> row 0@0x1f63a20 0xF0E0D0FF (subsequent data 0xF1E1D1FF) => 0xF2E3D1FE 
> row 1@0x1f63a24 0xF1E1D1FF (subsequent data 0xF2E2D2FF) => 0xFED7CEFE 
> row 2@0x1f63a28 0xF2E2D2FF => 0xB7EDCEF7 
>
> doing IN PLACE transformation... 
> row 0@0x1f63a20 0xF0E0D0FF (subsequent data 0xF1E1D1FF) => 0xF2E3D1FE 
> row 1@0x1f63a24 0xB6ECCEF7 (subsequent data 0xFED8D2FF) => 0xC3E3D1FD 
> row 2@0x1f63a28 0xFDD4D2FD => 0xEBE0D0F7 
>
> so first a buffer is filled with data and then a test transformation is 
> performed into a newly allocated buffer. the result is as expect. 
>
> then another transform is done with output buffer = input buffer, and then the 
> subsequent input data is changed by the the cmsDoTransform call even though 
> the given size is correctly specified with 4 bpp. therefore, the result is 
> incorrect, except for the very first transformation. it happens with 3 bpp 
> aswell. 
>
> this in-place transformation is optional in gstreamer and just saves a memcpy, 
> so the simplest workaround is operating my gstreamer element in a way where 
> input and output buffers are different memory, but I'd like to find out why the 
> in-place transformation corrupts the input. 
> the tutorial says on page 15 that it is okay to use the same memory block for 
> input and output as long as the formats are the same. i haven't debugged yet, 
> before i investigate more, i'd like to find out if maybe i'm just doing it 
> wrong? 
>
> cheers 
> fraxinas
>
> ------------------------------------------------------------------------------ 
> Find and fix application performance issues faster with Applications Manager 
> Applications Manager provides deep performance insights into multiple tiers of 
> your business applications. It resolves application problems quickly and 
> reduces your MTTR. Get your free trial! 
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________ 
> Lcms-user mailing list 
> Lcm...@li... 
> https://lists.sourceforge.net/lists/listinfo/lcms-user 

[Lcms-user] in-place transformation problem

[Andreas F. <fra...@op...>]

Hi guys,

i wrote a gstreamer wrapper element for littlecms ( https://
bugzilla.gnome.org/attachment.cgi?id=327238 )

I've observed that the functions cmsDoTransformStride and cmsDoTransform 
overwrite the subsequent data in my buffer plane if input and output pointers 
are pointing to the same position in memory (in-place transformation).

i wrote a simple test case which shows this issue.
$ gcc -Wall -g `pkg-config lcms2 --cflags --libs` lcms-memory-corruption-
testcase.c -o lcms-memory-corruption-testcase
$ ./lcms-memory-corruption-testcase CP955_F.icc
initalize 3 rows with 4 bpp = 12 bytes of source data...
initalized source data looks like:
row 0@0x1f63a20 0xF0E0D0FF
row 1@0x1f63a24 0xF1E1D1FF
row 2@0x1f63a28 0xF2E2D2FF

doing transformation data->new_data...
row 0@0x1f63a20 0xF0E0D0FF (subsequent data 0xF1E1D1FF) => 0xF2E3D1FE 
row 1@0x1f63a24 0xF1E1D1FF (subsequent data 0xF2E2D2FF) => 0xFED7CEFE 
row 2@0x1f63a28 0xF2E2D2FF => 0xB7EDCEF7 

doing IN PLACE transformation...
row 0@0x1f63a20 0xF0E0D0FF (subsequent data 0xF1E1D1FF) => 0xF2E3D1FE 
row 1@0x1f63a24 0xB6ECCEF7 (subsequent data 0xFED8D2FF) => 0xC3E3D1FD 
row 2@0x1f63a28 0xFDD4D2FD => 0xEBE0D0F7 

so first a buffer is filled with data and then a test transformation is 
performed into a newly allocated buffer. the result is as expect.

then another transform is done with output buffer = input buffer, and then the 
subsequent input data is changed by the the cmsDoTransform call even though 
the given size is correctly specified with 4 bpp. therefore, the result is 
incorrect, except for the very first transformation. it happens with 3 bpp 
aswell.

this in-place transformation is optional in gstreamer and just saves a memcpy, 
so the simplest workaround is operating my gstreamer element in a way where 
input and output buffers are different memory, but I'd like to find out why the 
in-place transformation corrupts the input.
the tutorial says on page 15 that it is okay to use the same memory block for 
input and output as long as the formats are the same. i haven't debugged yet, 
before i investigate more, i'd like to find out if maybe i'm just doing it 
wrong?

cheers
fraxinas

Re: [Lcms-user] Recent regression with master

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

Thanks Richard, 

It is now fixed  in GIT.

I wonder if you would allow me to use the crayons.icc file for the automated
test. That would prevent same error to show up again.

Regards
Marti Maria
The LittleCMS project
http://www.littlecms.com 

-----Original Message-----
From: Richard Hughes [mailto:hug...@gm...] 
Sent: miércoles, 30 de marzo de 2016 11:50
To: Lcms Liste <lcm...@li...>
Subject: [Lcms-user] Recent regression with master

My colord self tests have been failing since commit:

commit 40c640365214587d6f61161a738ade93ccba25c8
Author: Marti <mar...@tk...>
Date:   Mon Nov 30 10:11:30 2015 +0100

    Fixed alignment issues on alpha

The failure I'm seeing is:

 libcolord:ERROR:cd-test-private.c:1739:colord_icc_localized_func:
assertion failed (str == "Crayon Colors"): ("Crayon Colours" == "Crayon
Colors")

which is opening the MLUC-using crayons.icc which has multiple translations,
"Crayon Colors" for en_US and "Crayon Colours" for en_GB. Since that
alpha-fixup commit I'm always getting the en_GB data even when asking for
the en_US version explicitly..

Richard

----------------------------------------------------------------------------
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics
Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Recent regression with master

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

On 29 April 2016 at 17:23, Marti Maria <mar...@li...> wrote:
> I wonder if you would allow me to use the crayons.icc file for the automated
> test. That would prevent same error to show up again.

Sure, no problem at all. It's autogenerated in colord, so feel free to
use it under any license you want. Thanks!

Richard.

[Lcms-user] UBSAN reporting errors in libcms

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

Hello,

First of all, thanks for making this awesome project available as open
source.

The OpenJPEG project uses lcms for colour management, and we recently ran
the UBSAN
undefined behaviour sanitizer on our code - it turned up a few issues with
lcms.

For example:

http://my.cdash.org/testDetails.php?test=24434785&build=946319


One caveat - OpenJPEG runs an older version of lcms, so you folks may have
fixed this issue already


Kind Regards,
Aaron Boxer

[Lcms-user] Recent regression with master

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

My colord self tests have been failing since commit:

commit 40c640365214587d6f61161a738ade93ccba25c8
Author: Marti <mar...@tk...>
Date:   Mon Nov 30 10:11:30 2015 +0100

    Fixed alignment issues on alpha

The failure I'm seeing is:

 libcolord:ERROR:cd-test-private.c:1739:colord_icc_localized_func:
assertion failed (str == "Crayon Colors"): ("Crayon Colours" ==
"Crayon Colors")

which is opening the MLUC-using crayons.icc which has multiple
translations, "Crayon Colors" for en_US and "Crayon Colours" for
en_GB. Since that alpha-fixup commit I'm always getting the en_GB data
even when asking for the en_US version explicitly..

Richard

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

OK, soooo I circumvented Adobe’s awkward CMM installer and installed the Adobe CMM manually on OS X – so that I could compare it with Little CMS wrt/ its TRC behavior.

I also had to reimplement my test program, since the Adobe CMM is 32 bit only, whereas Apple’s current version of ColorSync is a complete reimplementation from 2009 which is 64 bit only. So I had to use the old, 32 bit ColorSync API from before 2009 to be able to access the Adobe CMM; this lead to a few additional insights.


But first, the Adobe CMM: I can confirm now that Little CMS with cmsFLAGS_SLOPE_LIMIT_32 does indeed successfully emulate the Adobe CMM. There are two qualifications, though:


1. The Adobe CMM enables black point compensation by default (you’d have to install a specific plist file on OS X to disable BPC, as explained in the PDF documentation that comes with the Adobe CMM). So to actually emulate the Adobe CMM behavior completely, you’ll need cmsFLAGS_SLOPE_LIMIT_32 | cmsFLAGS_BLACKPOINTCOMPENSATION. And you have to keep in mind that this is only confirmed for the 32 bit CMM version from 2008; theoretically, the behavior could have changed in the unpublished 64 bit version (cf. the behavioral change in the ColorSync CMM when going from 32 to 64 bit; see below).


2. The Adobe CMM forces values near 1 to be 1 and (unless BPC is applied) values near 0 to be 0. For instance, the TRC for a conversion from gamma 1.961 to gamma 2.2 (with identical primaries) in Little CMS is:

{{0.000, 0.000}, {0.002, 0.002}, {0.004, 0.004}, {0.006, 0.006}, {0.008, 0.008}, {0.010, 0.010}, {0.012, 0.012}, {0.014, 0.014}, ... , {0.986, 0.988}, {0.988, 0.989}, {0.990, 0.991}, {0.992, 0.993}, {0.994, 0.995}, {0.996, 0.996}, {0.998, 0.998}, {1.000, 1.000}}

whereas in the Adobe CMM it’s:

{{0.000, 0.000}, {0.002, 0.000}, {0.004, 0.000}, {0.006, 0.000}, {0.008, 0.000}, {0.010, 0.000}, {0.012, 0.012}, {0.014, 0.014}, ... , {0.986, 0.988}, {0.988, 0.989}, {0.990, 1.000}, {0.992, 1.000}, {0.994, 1.000}, {0.996, 1.000}, {0.998, 1.000}, {1.000, 1.000}}




When implementing the 32 bit version of my test program, I also found that the ColorSync CMM in its 32 bit incarnation had *no slope limit*; obviously, this was only introduced with the 64 bit version in 2009 (OS X 10.6 Snow Leopard).

Finally, I was also able to test the 32 bit ColorGear CMM from Canon. This turned out to have no slope limit, either.



------------
SUMMARY:
------------

So, to emulate various CMMs with Little CMS (with my slope limit patch), you’d use the following flags for cmsCreateTransform() and cmsCreateTransformTHR():

Adobe CMM (confirmed for published 32 bit version from 2008):
     cmsFLAGS_SLOPE_LIMIT_32 | cmsFLAGS_BLACKPOINTCOMPENSATION

ColorSync CMM (32 bit, up until and including OS X 10.5 Leopard from 2007):
     no flags

ColorSync CMM (64 bit, starting with OS X 10.6 Snow Leopard from 2009):
     cmsFLAGS_SLOPE_LIMIT_16

ColorGear CMM (from Canon, 32 bit, 2008):
     no flags

Kodak CMM (unpublished on OS X, according to documentation from Kodak):
     cmsFLAGS_SLOPE_LIMIT_16




            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

Am 22.03.2016 um 14:37 schrieb Uli Zappe <ul...@ri...>:

> I just realized that cmsFLAGS_SLOPE_LIMIT_16 and cmsFLAGS_SLOPE_LIMIT_32 do only work together with cmsFLAGS_NOOPTIMIZE.

I have uploaded a new version of the patch file which fixes this issue preliminarily by internally setting cmsFLAGS_NOOPTIMIZE as soon as cmsFLAGS_SLOPE_LIMIT_16 or cmsFLAGS_SLOPE_LIMIT_32 are specified.

If you already downloaded the patch file, please download it again.

            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

Am 22.03.2016 um 14:37 schrieb Uli Zappe <ul...@ri...>:

> So the patch should probably be modified such that cmsFLAGS_SLOPE_LIMIT_16 and cmsFLAGS_SLOPE_LIMIT_32 automatically include cmsFLAGS_NOOPTIMIZE.

Or, more precisely, the "Implements" element in the _cmsStage_struct that represents the tone curve with a slope limit could be set to a different value that signifies that no optimization is possible at this stage. But this is something that I think Marti should decide.

            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

One important addition:

I just realized that cmsFLAGS_SLOPE_LIMIT_16 and cmsFLAGS_SLOPE_LIMIT_32 do only work together with cmsFLAGS_NOOPTIMIZE.

During coding, I always used cmsFLAGS_NOOPTIMIZE, and then forgot to do the final tests without it.

So the patch should probably be modified such that cmsFLAGS_SLOPE_LIMIT_16 and cmsFLAGS_SLOPE_LIMIT_32 automatically include cmsFLAGS_NOOPTIMIZE.


            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

Am 22.03.2016 um 01:46 schrieb Miguel Medalha <mig...@sa...>:

> Maybe you are well aware of this, but here it goes just in case: back in 
> 2007 Adobe made a public release of their Color Management Module (CMM). 
> It can be downloaded from the following links:
> 
> Mac version
> http://www.adobe.com/support/downloads/detail.jsp?ftpID=3617

Yep, I know, but Adobe, in their infinite wisdom, don’t even manage to produce software without capitalization errors in the file references of their code, meaning that their software – the Adobe CMM included – does not run on case-sensitive file systems, which I use on OS X.

And instead of fixing these bugs, this brain-dead company builds installers that refuse to install their software as soon as they detect a case-sensitive file system. Go figure.

So unfortunately, I cannot run any Adobe software whatsoever (well, except Lightroom and DNG related apps).

My focus was on ColorSync compatibility, anyway. I just tried to make my patch as universally usable as possible, but it will be up to people who can and want to run Adobe software to confirm that cmsFLAGS_SLOPE_LIMIT_32 adequately emulates the Adobe CMM.

            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Miguel M. <mig...@sa...>]

> I have tested the implementation in comparison with ColorSync and can 
> confirm that it emulates the behavior of ColorSync exactly. I do not 
> have access to the Adobe CMM, so I cannot confirm that it emulates the 
> Adobe CMM as precisely as it does with ColorSync.

Maybe you are well aware of this, but here it goes just in case: back in 
2007 Adobe made a public release of their Color Management Module (CMM). 
It can be downloaded from the following links:

Mac version
http://www.adobe.com/support/downloads/detail.jsp?ftpID=3617

Windows version
http://www.adobe.com/support/downloads/detail.jsp?ftpID=3618

Unfortunately, both are 32bit only.

Re: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

Am 21.03.2016 um 23:48 schrieb Uli Zappe <ul...@ri...>:

> Therefore, I decided to patch the Little CMS source code directly.

To clarify, this patch is against the Little CMS 2.7 release version. Somehow this information got lost while I was editing my post.

            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

[Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS

[Uli Z. <ul...@ri...>]

Hi everyone,

about one year ago, Esben H-R Myosotis wrote in “Emulating Adobe's color engine” (https://sourceforge.net/p/lcms/mailman/message/33544095/):

> The Adobe color engine has the annoying quirk that it limits the slope of the transfer function for pure gamma profiles. They spill the beans in "Annex C: implementation notes (Informative)" in the specification of the Adobe1998 color space.
> 
> Since a disturbingly large fraction of the world consider Adobe products to be the standard of color management, it would be useful to have an option that emulates this behavior.

I have encountered the same issue, but with Apple’s ColorSync CMM (which uses seemingly the same formula although with factor 16 instead of Adobe’s 32). In fact, though it is not part of the ICC spec, this mechanism, known as “Slope Limit”, seems to be fairly widespread (e.g. Kodak’s CMM uses it, too – again with factor 16 (see the ProPhoto specification, page 5, http://scarse.sourceforge.net/docs/kodak/ProPhoto.pdf)). And Adobe’s and Apple’s CMMs are certainly among the most widely used CMMs. So I certainly agree with Esben that an option emulating this behavior would be very useful in Little CMS.

Basically, what slope limiting does is to calculate a linear transfer in parallel to the transfer function of matrix shaper profiles, and then use the maximum or minimum value (depending on the direction of the conversion) of both. So, assuming TRC(V) is the transfer function that converts the (R, G, B) component value V, and that F is the aforementioned factor (32 for Adobe, 16 for Apple and Kodak), slope limiting means:

for the RGB to PCS direction:

   V = max ( TRC(V) , V / F )

for the PCS to RGB direction:

   V = min ( TRC(V) , V * F )


Replying to Esben, Marti Maria has suggested to use Little CMS’ plug-in API to implement this behavior. But at least I fail to see how this could possibly work in a generally usable way. Also, I feel that the fact that slope limiting is so widespread warrants an emulation option in Little CMS itself. Therefore, I decided to patch the Little CMS source code directly. I’ll discuss how to apply this patch at the end of this post.

Obviously, implementing the above slope limiting formula itself is extremely simple; it’s just a few lines of code in the cmsEvalToneCurveFloat() function in cmsgamma.c. The more tricky part and by far the one that requires the most code changes is to propagate the information when and which slope limiting should be applied to this function.

My implementation offers two new dwFlags for cmsCreateTransform() and cmsCreateTransformTHR():

   cmsFLAGS_SLOPE_LIMIT_16    and
   cmsFLAGS_SLOPE_LIMIT_32

This means you can decide on a per-transform basis whether slope limiting should be applied or not, and which one. (Obviously, cmsFLAGS_SLOPE_LIMIT_16 emulates ColorSync and the Kodak CMM, cmsFLAGS_SLOPE_LIMIT_32 emulates Adobe’s CMM.)

Apart from these two additional flags, my patch does not affect the public API of Little CMS 2.7 at all. But of course, this also means that you’ll have no access to this new feature apart from the cmsFLAGS_SLOPE_LIMIT_16 and cmsFLAGS_SLOPE_LIMIT_32 flags. A modified implementation could change the public API of Little CMS and allow for more detailed access to this feature.

I have tested the implementation in comparison with ColorSync and can confirm that it emulates the behavior of ColorSync exactly. I do not have access to the Adobe CMM, so I cannot confirm that it emulates the Adobe CMM as precisely as it does with ColorSync.

You can download the patch file from

   ftp://ftp.ritual.org/common/ColorManagement/LittleCMS.2.7.SlopeLimit.patch

(Make sure to use the binary mode with ftp so as to leave the patch file untouched.)

Move LittleCMS.2.7.SlopeLimit.patch into the lcms2-2.7 directory.

Then, in Terminal, go into the lcms2-2.7 directory and enter:

   patch -p0 -i LittleCMS.2.7.SlopeLimit.patch

That should do it.

(@Marti: If you want me to, I can fork the current development version of Little CMS on GitHub and issue a pull request for the patch.)

            Bye
                    Uli
_________________________________________________________________________

  Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
_________________________________________________________________________

Re: [Lcms-user] Visual C# DLL function declaration

[<lit...@vi...>]

Hi,
Thank you for the fast answer. You were right.
It seems that little change from byte number to pixel number solved my problem.
Huge thanks,
*Tamas*

Re: [Lcms-user] Visual C# DLL function declaration

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

Hi,

 

*  // cmsDoTransform(hTransform, sourcePtr, targetPtr, bytes); 

 

It should not be number of bytes but number of píxels. Also, I think you lock only the scanline, not the whole image. 

 

Otherwise it looks fine to me, changing from bytes to scanline pixels should do something. Then iterate for all scanlines,

 

Regards

Marti

 

From: lit...@vi... [mailto:lit...@vi...] 
Sent: martes, 19 de enero de 2016 16:47
To: lcm...@li...
Subject: [Lcms-user] Visual C# DLL function declaration

 

I am using Visual C# 2015 with .NET.
Made the lcms2.dll without any problem, and also half-made a new lcms2 "header" for my C# project.
Most of the functions works fine - i can open and close profiles; get the infos from them, etc. -, but i cannot program the InputBuffer and OutputBuffer of the function *cmsDoTransform* in the right way.
If anybody familiar with this problem, please help me.

Here is a simple working example of the cmsGetProfileInfo function declaration:

    [DllImport("lcms2.dll")]
    public static extern UInt32 cmsGetProfileInfo(IntPtr hProfile, int InfoType, string LanguageCode, string CountryCode, [MarshalAsAttribute(UnmanagedType.LPWStr)] StringBuilder Buffer, int BufferSize);

And like most of the other functions its works nice.
But i stucked in cmsDoTransform, and don't know what would be the ideal declaration and usage. (Unmanaged Marshal attributes are one path, i tried a few variations of it without any succes)

E.g.:
    [DllImport("lcms2.dll")]
    public static extern void cmsDoTransform(IntPtr hTransform, IntPtr InputBuffer, IntPtr OutputBuffer,UInt32 Size);
or
    [DllImport("lcms2.dll")]
    public static extern void cmsDoTransform(IntPtr hTransform, char[] InputBuffer, char[] OutputBuffer,UInt32 Size);


For pixel manipulation i use the following code:

    Bitmap Source = new Bitmap("test.jpg", true);
    Bitmap Target = new Bitmap(Source.Width, Source.Height, PixelFormat.Format32bppArgb);

    Rectangle r1 = new Rectangle(0, 0, Source.Width, Source.Height);

    BitmapData sourceData = Source.LockBits(r1, ImageLockMode.ReadOnly, sourcePixelFormat);
    BitmapData targetData = Target.LockBits(r1, ImageLockMode.WriteOnly, sourcePixelFormat);

    IntPtr sourcePtr = sourceData.Scan0;
    IntPtr targetPtr = targetData.Scan0;

    int bytesPerPixel = ColorDepth / 8;
    int bytes = Source.Width * bytesPerPixel * Source.Height;

    byte[] colorValues = new byte[bytes];

    Marshal.Copy(sourcePtr, colorValues, 0, bytes);

    // Do stuffs here, like:
    // cmsDoTransform(hTransform, sourcePtr, targetPtr, bytes); - Or using the colorValues array, or ???

    Marshal.Copy(colorValues, 0, targetPtr, bytes);

    Source.UnlockBits(sourceData);
    Target.UnlockBits(targetData);
    ...

During debug, i always got memory error on the second and third argument of the cmsDoTransform function.

*Tamas*

[Lcms-user] Visual C# DLL function declaration

[<lit...@vi...>]

I am using Visual C# 2015 with .NET.
 Made the lcms2.dll without any problem, and also half-made a new lcms2 "header" for my C# project.
 Most of the functions works fine - i can open and close profiles; get  the infos from them, etc. -, but i cannot program the InputBuffer and  OutputBuffer of the function *cmsDoTransform* in the right way.
 If anybody familiar with this problem, please help me.
 
 Here is a simple working example of the cmsGetProfileInfo function declaration:
 
     [DllImport("lcms2.dll")]
     public static extern UInt32 cmsGetProfileInfo(IntPtr hProfile, int  InfoType, string LanguageCode, string CountryCode,  [MarshalAsAttribute(UnmanagedType.LPWStr)] StringBuilder Buffer, int  BufferSize);
 
 And like most of the other functions its works nice.
 But i stucked in cmsDoTransform, and don't know what would be the ideal  declaration and usage. (Unmanaged Marshal attributes are one path, i  tried a few variations of it without any succes)
 
 E.g.:
     [DllImport("lcms2.dll")]
     public static extern void cmsDoTransform(IntPtr hTransform, IntPtr InputBuffer, IntPtr OutputBuffer,UInt32 Size);
 or
     [DllImport("lcms2.dll")]
     public static extern void cmsDoTransform(IntPtr hTransform, char[] InputBuffer, char[] OutputBuffer,UInt32 Size);
 
 
 For pixel manipulation i use the following code:
 
     Bitmap Source = new Bitmap("test.jpg", true);
     Bitmap Target = new Bitmap(Source.Width, Source.Height, PixelFormat.Format32bppArgb);
 
     Rectangle r1 = new Rectangle(0, 0, Source.Width, Source.Height);
 
     BitmapData sourceData = Source.LockBits(r1, ImageLockMode.ReadOnly, sourcePixelFormat);
     BitmapData targetData = Target.LockBits(r1, ImageLockMode.WriteOnly, sourcePixelFormat);
 
     IntPtr sourcePtr = sourceData.Scan0;
     IntPtr targetPtr = targetData.Scan0;
 
     int bytesPerPixel = ColorDepth / 8;
     int bytes = Source.Width * bytesPerPixel * Source.Height;
 
     byte[] colorValues = new byte[bytes];
 
     Marshal.Copy(sourcePtr, colorValues, 0, bytes);
 
     // Do stuffs here, like:
     // cmsDoTransform(hTransform, sourcePtr, targetPtr, bytes); - Or using the colorValues array, or ???
 
     Marshal.Copy(colorValues, 0, targetPtr, bytes);
 
     Source.UnlockBits(sourceData);
     Target.UnlockBits(targetData);
     ...
 
 During debug, i always got memory error on the second and third argument of the cmsDoTransform function.
 
 *Tamas*

Re: [Lcms-user] Question about Python bindings for lcms2

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

On 28 September 2015 at 21:33, Kunda <ku...@sc...> wrote:
> What is the status of Python bindings for lcms2?

It's not exactly the same, and is probably only an option on Linux,
but libcolord has an API that wraps the important parts of lcms2 and
provides a nice GObjectIntrospection interface that can be easily
consumed in Python.
https://github.com/hughsie/colord/blob/master/examples/cd-get-devices.py
is an example talking to the daemon, but if this is interesting to you
I can do an example that does a colorspace conversion.

Richard.

[Lcms-user] Question about Python bindings for lcms2

[Kunda <ku...@sc...>]

What is the status of Python bindings for lcms2?
Is anyone working on this?

Cheers,
/Kunda

Re: [Lcms-user] Fwd: Trying to make a UI for colorspaces, have some questions.

[Elle S. <ell...@ni...>]

On 09/26/2015 07:23 AM, Noel Carboni wrote:
>> http://ninedegreesbelow.com/photography/srgb-profile-comparison.html
>
> Interesting article, thanks for the link.  Out of curiosity, where does
> the Microsoft sRGB profile (as delivered with Windows, i.e., sRGB Color
> Space Profile.icm) fall in the table?  Or is it there and I just don't
> realize it?

The sRGB profile that was bundled with Windows 2000 falls in group 3. I 
don't know about newer versions of Windows, but I will guess it's the 
same, with the same primaries as the color.org V2 matrix sRGB profiles.

>
> By the way, to further the original question, an approach that can work
> (I'm using it) to operate on non-linear image data linearly is this:
>
> 1.  Derive the general tone and reverse tone curves of an image's
> profile by passing grayscale values from black to white through a
> transform from the image's profile to a created linear working profile.
> Use the results of that to build tone and inverse tone curves and smooth
> them.
>
> 2.  Use optimized conversion processes using the tone curve data from
> step 1 to access the pixels of the image.  In other words, the act of
> reading a pixel removes the gamma precompensation and the act of writing
> a pixel restores it.

Thanks! for describing this approach.


Elle