diff options
Diffstat (limited to 'doc/iccgamutmapping.html')
| -rw-r--r-- | doc/iccgamutmapping.html | 367 |
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: 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> + <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: 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 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> + 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> |