1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
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>
|
