diff options
author | Jörg Frings-Fürst <debian@jff-webhosting.net> | 2014-09-01 13:56:46 +0200 |
---|---|---|
committer | Jörg Frings-Fürst <debian@jff-webhosting.net> | 2014-09-01 13:56:46 +0200 |
commit | 22f703cab05b7cd368f4de9e03991b7664dc5022 (patch) | |
tree | 6f4d50beaa42328e24b1c6b56b6ec059e4ef21a5 /doc/iccgamutmapping.html |
Initial import of argyll version 1.5.1-8debian/1.5.1-8
Diffstat (limited to 'doc/iccgamutmapping.html')
-rw-r--r-- | doc/iccgamutmapping.html | 163 |
1 files changed, 163 insertions, 0 deletions
diff --git a/doc/iccgamutmapping.html b/doc/iccgamutmapping.html new file mode 100644 index 0000000..d180372 --- /dev/null +++ b/doc/iccgamutmapping.html @@ -0,0 +1,163 @@ +<!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: Perceptual<br> +AtoB1, BtoA1: Colorimetric<br> +AtoB2, BtoA2: 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> + 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> |