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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
|
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<meta name="GENERATOR" content="Mozilla/4.73 [en] (WinNT; I)
[Netscape]">
<title>Argyll Environment Variables</title>
</head>
<body>
<br>
<h2> <u>Environment variables<br>
</u></h2>
The following environment variables affect behaviour:<br>
<br>
<span style="font-weight: bold;"><a name="ARGYLL_NOT_INTERACTIVE"></a>ARGYLL_NOT_INTERACTIVE</span><br>
<br>
<div style="margin-left: 40px;">Normally Argylls tools expect that
they are directly interacting with a user, and use a couple of
techniques for communicating with them through the command line.
One is to output progress information by re-writing the same
display line by using a Carriage Return rather than a Line Feed at
the end of each line. Another is to allow a single key stroke to
trigger an action or interrupt operations.<br>
<br>
If the <span style="font-weight: bold;">ARGYLL_NOT_INTERACTIVE</span>
environment variable is set, then:<br>
<br>
A Line Feed will be added to the end of each
progress line.<br>
<br>
Any time it would wait for a single keystroke
input, it will instead wait for and read the next character from
stdin.<br>
To facilitate flushing stdin, any return or
line feed characters will be ignored, so a character other than
return or line feed must be used to trigger activity.<br>
<br>
Note that while a reading is being made, a
character input can abort the reading, just as with normal
interactive mode.<br>
<br>
Note that on MSWin systems, the character and
return or line fee characters must be written to stdin in a single
operation (i.e. testing <span style="font-weight: bold;">ARGYLL_NOT_INTERACTIVE
</span>mode manually will probably fail, because the character and
return get split up.)<br>
</div>
<span style="font-weight: bold;"></span><br>
<b><a name="ARGYLL_3D_DISP_FORMAT"></a>ARGYLL_3D_DISP_FORMAT<br>
</b>
<blockquote>This overrides the default 3D visualisation file format
for tools such as <a href="iccgamut.html">iccgamut</a> or <a
href="viewgam.html">viewgam</a>. Set to<b> </b><b>VRML</b> or <b>X3D
</b>or <b>X3DOM</b>, which will result in <b>.wrl</b>, <b>.x3d</b>
and <b>.x3d.html</b> files respectively. See <a href="3dformat">3d
Viewing Format</a>.<br>
</blockquote>
<b><br>
</b> <span style="font-weight: bold;"><a
name="ARGYLL_COLMTER_CAL_SPEC_SET"></a>ARGYLL_COLMTER_CAL_SPEC_SET</span><br>
<span style="font-weight: bold;"><a name="ARGYLL_COLMTER_COR_MATRIX"></a>ARGYLL_COLMTER_COR_MATRIX</span><br>
<br>
<div style="margin-left: 40px;">Both of these can be used to set a
default <span style="font-weight: bold;">CCMX</span> or <span
style="font-weight: bold;">CCSS</span> colorimeter calibration
file, equivalent to supplying a <span style="font-weight: bold;">-X</span>
argument to spotread, dispcal, dispread and any other utility that
allows using a colorimteter. The ARGYLL_COLMTER_CAL_SPEC_SET will
take priority if both are set.<br>
<br>
</div>
<br>
<span style="font-weight: bold;"><a
name="ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS"></a>ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS<br>
<br>
</span>
<div style="margin-left: 40px;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span>Normally
a
delay of 200 msec is allowed between changing a patch color in
software, and that change appearing in the displayed color itself.
For some instuments (ie. i1d3, i1pro, ColorMunki, Klein K10-A)
ArgyllCMS will automatically measure and set an appropriate update
delay during instrument calibration. In rare situations this delay
may not be sufficient (ie. some TV's with extensive image
processing features turned on), and a larger delay can be set
using the <span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span>ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS
environment
variable, ie. ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=400 would set a
400 msec minimum delay.<br>
<span style="font-weight: bold;"><br>
</span></div>
<span style="font-weight: bold;"></span><span style="font-weight:
bold;"><span style="font-weight: bold;"><a
name="ARGYLL_DISPLAY_SETTLE_TIME_MULT"></a>ARGYLL_DISPLAY_SETTLE_TIME_MULT</span></span><br>
<blockquote> Normally the display technology type determines how
long is allowed between when a patch color change appears on the
display, and when that change has settled down, and as actually
complete within measurement tolerance. A CRT or Plasma display for
instance, can have quite a long settling delay due to the decay
characteristics of the phosphor used, while an LCD can also have a
noticeable settling delay due to the liquid crystal response time
and any response time enhancement circuitry. [ Instruments without
a display technology type selection such as spectrometers assume a
worst case.].<br>
The ARGYLL_DISPLAY_SETTLE_TIME_MULT environment variable allows
the rise and fall times of the model to be scaled to extend or
reduce the settling time. For instance,
ARGYLL_DISPLAY_SETTLE_TIME_MULT=2.0 would double the settling
time, while ARGYLL_DISPLAY_SETTLE_TIME_MULT=0.5 would halve it.<br>
</blockquote>
<span style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight:
bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight:
bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span
style="font-weight: bold;"><a
name="ARGYLL_CREATE_WRONG_VON_KRIES_OUTPUT_CLASS_REL_WP"></a>ARGYLL_CREATE_WRONG_VON_KRIES_OUTPUT_CLASS_REL_WP<br>
</span></span></span></span></span></span></span></span></span></span></span></span>
<blockquote>By default ArgyllCMS uses the Bradford sharpened cone
Chromatic adaption matrix in adapting the measured, absolute
colorimetric test data to the <b>PCS</b> (Profile Connection
Space) relative colorimetric D50 white point for all profile
types. This makes the profile handling consistent with the widely
deployed (HP & Microsoft) sRGB and AdobeRGB profiles, as well
as being recommended practice in modelling chromatic
adaption. The ICC profile format though, specifies the use
of a non-cone space XYZ adaptation (so called "Wrong Von Kries"
chromatic adaptation) [ ICC Specification<br>
ICC.1:2001-04 (ICCV2.4) Annex A, pp 66, equations A.1, A.2 &
A.3 ], so ArgyllCMS profiles have a very slight incompatibility
with ICC profiles created strictly according to the ICC
specifications, depending on how close to white Output (i.e.
print) profiles media white is to the perfect diffuser. (Note that
CMM's that strictly follow the ICC specifications have much more
gross incompatibilities due to this, when dealing with the HP
& Microsoft sRGB and AdobeRGB profiles.) By setting this
environment variable, Output (i.e. print) profiles will be created
that better conform to the ICC specification, and therefore
have better inter-interoperability with some other CMMs, at the
cost of poorer color behavior.<br>
See also the <a href="ArgyllCMS_arts_tag.html">ArgyllCMS 'arts'
tag</a>.<br>
<span style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight:
bold;"></span></span></span></span></span></span></blockquote>
<span style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight:
bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><span style="font-weight:
bold;"><a
name="ARGYLL_CREATE_DISPLAY_PROFILE_WITH_CHAD"></a>ARGYLL_CREATE_DISPLAY_PROFILE_WITH_CHAD<br>
</span></span></span></span></span></span></span></span></span>
<blockquote>The ICC V2 format originally provided no clear mechanism
for Display profiles to use a modern chromatic adaptation
transform in dealing with the D65 white point of typical displays.
Profile makers ended up taking two different approaches :- one was
to use a Bradford chromatic transform for the media (display)
white to PCS D50 (this approach being used by the widely deployed
HP & Microsoft sRGB and AdobeRGB profiles, as well as
ArgyllCMS profiles by default), and the other was to apply the
Bradford transform to the measurement data and then disable
Absolute Intent for display profiles by setting the
mediaWhitePoint tag to D50. The latter approach was supplemented
later on with the introduction of the ChromaticAdapation ('chad')
tag, but this did not restore the Absolute Colorimetric capability
to Display profiles. The latter approach has also been adopted
more formally in the ICC V4 specifications. To improve restore the
Absolute Intent for such profiles, ArgyllCMS will make use of the
'chad' tag in such profiles when Absolute Colorimetric intent is
requested, but by default does not create such profiles. Setting
this environment variable causes it to create Display profiles in
the fashion dictated by the ICC V4 spec. :- setting the
mediaWhitePoint tag to D50 and storing the display media white to
D50 matrix in the 'chad' tag. (This approach has slightly poorer
accuracy for Absolute Intent than ArgyllCMS's default.) <br>
</blockquote>
<span style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><a
name="ARGYLL_CCAST_DEFAULT_RECEIVER"></a>ARGYLL_CCAST_DEFAULT_RECEIVER<br>
</span></span></span>
<blockquote>By default the ChromeCast test patch source uses a
special receiver application that gets the test patch data
directly. By setting this environment variable to true, the
default Google ChromeCast receiver will be used, making use of a
local web server to provide the images. This is slower than the
special reciever, but can be used as a fallback.<br>
</blockquote>
<span style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"><a name="ARGYLL_IGNORE_XRANDR1_2"></a>ARGYLL_IGNORE_XRANDR1_2<br>
<br>
</span></span> </span>
<div style="margin-left: 40px;">On an X11 system, if this is <span
style="font-weight: bold;"></span>set (ie. set it to "yes"),
then the presence of the XRandR 1.2 extension will be ignored, and
other extensions such as Xinerama and XF86VidMode extension will
be used. This may be a way to work around buggy XRandR 1.2
implementations.<br>
<br>
</div>
<span style="font-weight: bold;"><a
name="ARGYLL_DISABLE_I1PRO2_DRIVER"></a>ARGYLL_DISABLE_I1PRO2_DRIVER<br>
<br>
</span>
<div style="margin-left: 40px;">There is now support for most of the
the Eye-One Pro Rev E (aka Eye-One Pro 2) instrument features, but
a Rev E can be operated in legacy mode if the environment variable
ARGYLL_DISABLE_I1PRO2_DRIVER is set (ie. set it to "yes").<br>
</div>
<span style="font-weight: bold;"></span><br>
<span style="font-weight: bold;"><a name="XDG_CACHE_HOME"></a>XDG_CACHE_HOME<br>
<span style="font-weight: bold;"><br>
</span></span>
<div style="margin-left: 40px;">Argyll tries to follow the <a
href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
Base
Directory Specification</a>, and uses the <span
style="font-weight: bold;">XDG_CACHE_HOME</span> environment
variable to place per instrument calibration information, and
.ccmx and .ccss files.<br>
</div>
<br>
<span style="font-weight: bold;"><a name="XDG_CONFIG_DIRS"></a>XDG_CONFIG_DIRS<br>
<a name="XDG_DATA_DIRS"></a>XDG_DATA_DIRS<span style="font-weight:
bold;"><br>
<span style="font-weight: bold;"></span></span></span><br>
<div style="margin-left: 40px;">On Unix type operating systems,
configuration and profiles for displays are placed relative to
these environment variables.<br>
</div>
<br>
<br>
See <a href="Performance.html">Performance Tuning</a> for other
variables.<br>
<br>
<br>
</body>
</html>
|
