Thread: [Lcms-user] ColorSync/AdobeCMM et al. (“Slope Limit”) compatibility patch for Little CMS
An ICC-based CMM for color management
Brought to you by:
mm2
|
From: Uli Z. <ul...@ri...> - 2016-03-21 23:08:41
|
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 _________________________________________________________________________ |
|
From: Uli Z. <ul...@ri...> - 2016-03-22 00:11:35
Attachments:
smime.p7s
|
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
_________________________________________________________________________
|
|
From: Miguel M. <mig...@sa...> - 2016-03-22 01:13:11
|
> 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. |
|
From: Uli Z. <ul...@ri...> - 2016-03-22 02:16:41
|
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 _________________________________________________________________________ |
|
From: Uli Z. <ul...@ri...> - 2016-03-22 13:37:04
|
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
_________________________________________________________________________
|
|
From: Uli Z. <ul...@ri...> - 2016-03-22 13:57:44
|
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
_________________________________________________________________________
|
|
From: Uli Z. <ul...@ri...> - 2016-03-22 17:09:04
|
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
_________________________________________________________________________
|
|
From: Uli Z. <ul...@ri...> - 2016-03-25 23:13:37
|
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
_________________________________________________________________________
|