summaryrefslogtreecommitdiff
path: root/doc/iccgamutmapping.html
diff options
context:
space:
mode:
Diffstat (limited to 'doc/iccgamutmapping.html')
-rw-r--r--doc/iccgamutmapping.html367
1 files changed, 207 insertions, 160 deletions
diff --git a/doc/iccgamutmapping.html b/doc/iccgamutmapping.html
index d180372..8deab44 100644
--- a/doc/iccgamutmapping.html
+++ b/doc/iccgamutmapping.html
@@ -1,163 +1,210 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
-<head>
- <title>About ICC profiles and Gamut Mapping</title>
- <meta http-equiv="content-type"
- content="text/html; charset=ISO-8859-1">
-</head>
-<body>
-<h2><u>About ICC profiles and Gamut Mapping</u></h2>
-<h3>How ICC profiles support different intents</h3>
-cLUT (Color Lookup Table) based ICC profiles support multiple <span
- style="font-weight: bold;">intents</span> by having a table for each
-intent. In a typical device cLUT profile, there are up to 6 cLUT's,
-three for input (AtoB tables, that convert from device space to PCS
-(Profile connection space)), and three for output (BtoA tables, that
-convert from PCS to device space). The tables allow the use of
-different color transforms, each transform being tailored for a
-different effect:<br>
-<br>
-AtoB0, BtoA0:&nbsp;&nbsp; Perceptual<br>
-AtoB1, BtoA1:&nbsp;&nbsp; Colorimetric<br>
-AtoB2, BtoA2:&nbsp;&nbsp; Saturation<br>
-<br>
-The colorimetric intent is meant to convey the exact device color
-behaviour, without any gamut mapping. Typically it is used to store the
-devices behaviour (characterization), and is also used where exact
-color reproduction is required, such as for proofing. The Colorimetric
-tables double up for both relative colorimetric and
-absolute colorimetric with the application of a white point restoration.<br>
-<br>
-The Perceptual and Saturation tables are meant to contain gamut mapping
-combined with the device characterization. The allowance for this in
-both the AtoB direction, as well as the BtoA direction permits a
-profile to gamut map from the device gamut to some intermediate gamut,
-and then from the intermediate gamut to the device gamut.<br>
-<br>
-[Note that Shaper/Matrix profiles are always Colorimetric intent, since
-there is only a single transformation, and it does not have the
-necessary flexibility to accommodate gamut mapping.]<br>
-<h3>ICC Version 2 behaviour<br>
-</h3>
-Apart from defining the general purpose of the different tables, the
-ICC Version 2 specification doesn't specify exactly how they are to
-achieve this, so it is up to the profile maker to make a choice in this
-regard. There is no common gamut boundary specified for the PCS, and
-such an approach limits the achievable intents in any case (see ICC
-Version 4 behaviour for an explanation why).<br>
-<br>
-What I've chosen to do with Argyll profiles, is to make all the AtoB
-tables the same as colorimetric. This means that the conversion used
-for the source profile is always colorimetric, and also means that the
-source gamut seen by the destination profile is the source colorspace
-gamut. This means that the gamut mapping is done solely in the BtoA
-tables,
-and that their task is to map the source colorspace gamut to the
-destination colorspace gamut. So to construct the perceptual and
-saturation intent mapping tables, a source profile or source gamut
-needs to be specified, so that a gamut mapping can be constructed.<br>
-<br>
-The advantages of this approach is that the behaviour is precisely
-defined, a full range of gamut mapping options is available, and
-compatibility with matrix profiles (which do not have gamut mapping
-transforms) and other foreign profiles can be assured, by simply using
-such profiles as colorimetric sources. The main disadvantage is that
-the gamut mapping will only operate exactly as intended when the
-profile is linked with the source profile it was setup for. This is
-really a fundamental limitation of the idea of having pre-computed
-gamut mapping color transforms, that the ICC profile format was
-intended to support.<br>
-<br>
-Some non-Argyll profile have gamut mapping transforms in their
-Perceptual and Saturation A2B tables, and this means that the apparent
-gamut of a source through these tables may be different to the actual
-device gamut. To accommodate using these profiles with CMM's (Color
-Management Modules) that do not permit the separate choice of intent
-tables for the source and destination profiles, Argyll will by default
-use the gamut defined by the source profile perceptual table to
-create the gamut mapping of the destination perceptual table, and the
-source saturation table to make the destination saturation table. Note
-that this can affect the exact nature of the gamut mapping, the
-distortion of the source gamut changing the apparent relationship
-between it and the destination gamut - see "ICC Version 4 behavior" for
-an illustration of the kind of changes this causes. [This default can
-be overridden though using the colprof -nP and -nS flags.]<br>
-<h3>ICC Version 4 behaviour</h3>
-(Note that Argyll does not currently support ICC V4)<br>
-<br>
-By default, ICC Version 4 profile operate exactly the same as the ICC
-V2 profile in regard to gamut mapping. A slight adjustment was made to
-the permitted tag contents, to allow things like Display profiles to
-contain the full range of AtoB and BtoA tables, so that they could also
-be gamut mapped. But an optional part of ICCV4, is to use the <span
- style="font-weight: bold;">Profile Reference Medium Gamut</span>
-(PRMG) as an
-intermediate gamut boundary between the source colorspace, and the
-destination colorspace. If this option is used, then an additional tag
-in the ICCV4 profile indicates that this is the case. This then solves
-the problem of the gamut mapping having to know the source and
-destination gamuts to operate. Instead, the gamut mapping is split into
-two parts, the first where the source gamut to RMG is done by the AtoB
-tables, and then the RMG to destination gamut is done by the BtoA
-tables. Profiles can therefore be mix and matches, while retaining true
-gamut mapping.<br>
-<br>
-This approach has a number of drawbacks though. One is that the colors
-get gamut mapped twice. Gamut mapping is sometimes not very precise,
-and the geometry of the transforms may not cancel out, especially since
-different profile vendors may choose different algorithms in their
-gamut mapping. By "cancel out", I mean that even if you were linking
-the same source colorspace to the same destination colorspace, the
-gamut may be expanded (say) in the process of mapping to the PRMG, and
-then compressed again in mapping from the RMG to the device space, and
-these expansions and compressions may not quite match. Given that the
-PRMG is a relatively large gamut, larger than many real devices actual
-behavior, this sort of expansion and re-compression will be the normal
-thing.<br>
-<br>
-The chief drawback, is that only one (non colorimetric) intent can
-really be supported, that of saturation. <br>
-<br>
-The typically expected behaviour of perceptual intent gamut mapping, is
-to
-compress any areas of the source gamut that lie outside the destination
-gamut, but for areas that fall within the destination gamut, change
-them as little as possible, consistent with keeping smooth and
-proportional with respect to the compressed colors. This preserves the
-source "look" as much as
-possible, while ensuring that out of gamut colors are smoothly brought
-within the destination gamut.<br>
-<br>
-Typical behavior of a saturation intent, is (at least), to not only
-compress out of gamut source colors to fit within the destination, but
-to expand any source boundary that falls within the destination gamut
-outwards match the destination gamut. Some practical saturation gamut
-mappings may go further than this, and expand a little beyond the
-destination gamut to ensure fully saturated boundary colors, and also
-enhance the saturation of all colors mapped through it.<br>
-<br>
-&nbsp;By mapping the source gamut to
-the RMG in the A2B, all information about what areas of the source
-gamut are
-inside or outside of the destination gamut are lost, so the destination
-gamut mapping can not known which colors may be left unchanged, and
-which really need compressing. All it can do is map the RMG to match
-the destination gamut,
-thereby effecting a saturation style intent. <br>
-<br>
-Once again, this is a fundamental limitation of using pre-computed
-gamut mappings. The only effective way of overcoming such limitations
-is to move to a more active color management architecture, in which
-gamut mappings are computed at link time, to accommodate the actual
-source and destination gamuts.<br>
-<br>
-<br>
-<img alt="Illustration of perceptual and saturation gamut mapping."
- src="gamutmapping1.jpg" style="width: 665px; height: 215px;"><br>
-<br>
-<br>
-<br>
-<br>
-<br>
-</body>
+ <head>
+ <title>About ICC profiles and Gamut Mapping</title>
+ <meta http-equiv="content-type" content="text/html;
+ charset=windows-1252">
+ </head>
+ <body>
+ <h2><u>About ICC profiles and Gamut Mapping</u></h2>
+ <h3>How ICC profiles support different intents</h3>
+ cLUT (Color Lookup Table) based ICC profiles support multiple <span
+ style="font-weight: bold;">intents</span> by having a table for
+ each
+ intent. In a typical device cLUT profile, there are up to 6 cLUT's,
+ three for input (AtoB tables, that convert from device space to PCS
+ (Profile connection space)), and three for output (BtoA tables, that
+ convert from PCS to device space). The tables allow the use of
+ different color transforms, each transform being tailored for a
+ different effect:<br>
+ <br>
+ AtoB0, BtoA0:&nbsp;&nbsp; Perceptual<br>
+ AtoB1, BtoA1:&nbsp;&nbsp; Colorimetric<br>
+ AtoB2, BtoA2:&nbsp;&nbsp; Saturation<br>
+ <br>
+ The colorimetric intent is meant to convey the exact device color
+ behaviour, without any gamut mapping. Typically it is used to store
+ the
+ devices behaviour (characterization), and is also used where exact
+ color reproduction is required, such as for proofing. The
+ Colorimetric
+ tables double up for both relative colorimetric and
+ absolute colorimetric with the application of a white point
+ restoration.<br>
+ <br>
+ The Perceptual and Saturation tables are meant to contain gamut
+ mapping
+ combined with the device characterization. The allowance for this in
+ both the AtoB direction, as well as the BtoA direction permits a
+ profile to gamut map from the device gamut to some intermediate
+ gamut,
+ and then from the intermediate gamut to the device gamut.<br>
+ <br>
+ [Note that Shaper/Matrix profiles are always Colorimetric intent,
+ since
+ there is only a single transformation, and it does not have the
+ necessary flexibility to accommodate gamut mapping.]<br>
+ <h3>ICC Version 2 behaviour<br>
+ </h3>
+ Apart from defining the general purpose of the different tables, the
+ ICC Version 2 specification doesn't specify exactly how they are to
+ achieve this, so it is up to the profile maker to make a choice in
+ this
+ regard. There is no common gamut boundary specified for the PCS, and
+ such an approach limits the achievable intents in any case (see ICC
+ Version 4 behaviour for an explanation why).<br>
+ <br>
+ What I've chosen to do with Argyll profiles, is to make all the AtoB
+ tables the same as colorimetric. This means that the conversion used
+ for the source profile is always colorimetric, and also means that
+ the
+ source gamut seen by the destination profile is the source
+ colorspace
+ gamut. This means that the gamut mapping is done solely in the BtoA
+ tables,
+ and that their task is to map the source colorspace gamut to the
+ destination colorspace gamut. So to construct the perceptual and
+ saturation intent mapping tables, a source profile or source gamut
+ needs to be specified, so that a gamut mapping can be constructed.<br>
+ <br>
+ The advantages of this approach is that the behaviour is precisely
+ defined, a full range of gamut mapping options is available, and
+ compatibility with matrix profiles (which do not have gamut mapping
+ transforms) and other foreign profiles can be assured, by simply
+ using
+ such profiles as colorimetric sources. The main disadvantage is that
+ the gamut mapping will only operate exactly as intended when the
+ profile is linked with the source profile it was setup for. This is
+ really a fundamental limitation of the idea of having pre-computed
+ gamut mapping color transforms, that the ICC profile format was
+ intended to support.<br>
+ <br>
+ Some non-Argyll profile have gamut mapping transforms in their
+ Perceptual and Saturation A2B tables, and this means that the
+ apparent
+ gamut of a source through these tables may be different to the
+ actual
+ device gamut. To accommodate using these profiles with CMM's (Color
+ Management Modules) that do not permit the separate choice of intent
+ tables for the source and destination profiles, Argyll will by
+ default
+ use the gamut defined by the source profile perceptual table to
+ create the gamut mapping of the destination perceptual table, and
+ the
+ source saturation table to make the destination saturation table.
+ Note
+ that this can affect the exact nature of the gamut mapping, the
+ distortion of the source gamut changing the apparent relationship
+ between it and the destination gamut - see "ICC Version 4 behavior"
+ for
+ an illustration of the kind of changes this causes. [This default
+ can
+ be overridden though using the colprof -nP and -nS flags.]<br>
+ <h3>ICC Version 4 behaviour</h3>
+ (Note that Argyll does not currently support ICC V4)<br>
+ <br>
+ By default, ICC Version 4 profile operates similarly to the ICC
+ V2 profile in regard to gamut mapping, with the exception that a
+ minimally specified reference medium and reference viewing
+ conditions are introduced for perceptual (and presumably saturation)
+ tables, allowing at least the luminance range to have a well defined
+ behavior when mixing and matching the perceptual A2B and B2A tables
+ of different profiles. A slight adjustment was made to
+ the permitted tag contents, to allow things like Display profiles to
+ contain the full range of AtoB and BtoA tables, so that they could
+ also
+ be gamut mapped. An optional part of ICCV4, introduces a more
+ comprehensively specified <span style="font-weight: bold;">Profile
+ Reference Medium Gamut</span>
+ (PRMG) as an
+ intermediate gamut boundary between the source colorspace, and the
+ destination colorspace. If this option is used, then an additional
+ tag
+ in the ICCV4 profile indicates that this is the case. This then
+ solves
+ the problem of the gamut mapping having to know the source and
+ destination gamuts to operate. Instead, the gamut mapping is split
+ into
+ two parts, the first where the source gamut to RMG is done by the
+ AtoB
+ tables, and then the RMG to destination gamut is done by the BtoA
+ tables. Profiles can therefore be mix and matches, while retaining
+ true
+ gamut mapping.<br>
+ <br>
+ This approach has a number of drawbacks though. One is that the
+ colors
+ get gamut mapped twice. Gamut mapping is sometimes not very precise,
+ and the geometry of the transforms may not cancel out, especially
+ since
+ different profile vendors may choose different algorithms in their
+ gamut mapping. By "cancel out", I mean that even if you were linking
+ the same source colorspace to the same destination colorspace, the
+ gamut may be expanded (say) in the process of mapping to the PRMG,
+ and
+ then compressed again in mapping from the RMG to the device space,
+ and
+ these expansions and compressions may not quite match. Given that
+ the
+ PRMG is a relatively large gamut, larger than many real devices
+ actual
+ behavior, this sort of expansion and re-compression will be the
+ normal
+ thing.<br>
+ <br>
+ The chief drawback, is that only one (non colorimetric) intent can
+ really be supported, that of saturation. <br>
+ <br>
+ The typically expected behavior of perceptual intent gamut mapping,
+ is
+ to
+ compress any areas of the source gamut that lie outside the
+ destination
+ gamut, but for areas that fall within the destination gamut, change
+ them as little as possible, consistent with keeping smooth and
+ proportional with respect to the compressed colors. This preserves
+ the
+ source "look" as much as
+ possible, while ensuring that out of gamut colors are smoothly
+ brought
+ within the destination gamut.<br>
+ <br>
+ Typical behavior of a saturation intent, is (at least), to not only
+ compress out of gamut source colors to fit within the destination,
+ but
+ to expand any source boundary that falls within the destination
+ gamut
+ outwards match the destination gamut. Some practical saturation
+ gamut
+ mappings may go further than this, and expand a little beyond the
+ destination gamut to ensure fully saturated boundary colors, and
+ also
+ enhance the saturation of all colors mapped through it.<br>
+ <br>
+ &nbsp;By mapping the source gamut to
+ the RMG in the A2B, all information about what areas of the source
+ gamut are
+ inside or outside of the destination gamut are lost, so the
+ destination
+ gamut mapping can not known which colors may be left unchanged, and
+ which really need compressing. All it can do is map the RMG to match
+ the destination gamut,
+ thereby effecting a saturation style intent. <br>
+ <br>
+ Once again, this is a fundamental limitation of using pre-computed
+ gamut mappings. The only effective way of overcoming such
+ limitations
+ is to move to a more active color management architecture, in which
+ gamut mappings are computed at link time, to accommodate the actual
+ source and destination gamuts.<br>
+ <br>
+ <br>
+ <img alt="Illustration of perceptual and saturation gamut mapping."
+ src="gamutmapping1.jpg" style="width: 665px; height: 215px;"><br>
+ <br>
+ <br>
+ <br>
+ <br>
+ <br>
+ </body>
</html>