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
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Calibration Format File (.cal)</title>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<meta name="author" content="Graeme Gill">
</head>
<body>
<h2>Description of the .cal format</h2>
Device calibration information. This is ASCII text, <a
href="File_Formats.html#CGATS">CGATS</a>, Argyll specific format,
used to hold a description of device setup information that brings
it to a desired calibration state. Calibration files are created by
<a href="synthcal.html">synthcal</a>, <a href="dispcal.html">dispcal</a>
and <a href="printcal.html">printcal</a>.<br>
<br>
While fully compatible with the CGATS.5 Data Exchange Format, the
particular required keywords and fields are unique to Argyll, hence
an Argyll specific file identifier <span style="font-weight: bold;">CAL</span>
is used to avoid confusion with standard ANSI or CGATS files.<br>
<br>
The <span style="font-weight: bold;">.cal</span> format changes
from time to time with new releases, to add new functionality, but
generally retains backwards compatibility. Note that in the
description below, the word "may" indicates an optional component,
while the word "shall" indicates a necessary component.<br>
<br>
Generally a .cal file contains only one table, the table containing
the setup information. <br>
<br>
<br>
The table contains the following:<br>
<br>
The file identifier (First 7 characters) shall be <span
style="font-weight: bold;">CAL</span>.<br>
<br>
A <span style="font-weight: bold;">#</span> character introduces a
comment.<br>
<br>
<span style="font-weight: bold;"><span style="font-weight: bold;"><span
style="font-weight: bold;"></span></span></span>There may be <span
style="font-weight: bold;">DESCRIPTOR</span>, <span
style="font-weight: bold;">ORIGINATOR</span>, or <span
style="font-weight: bold;">CREATED</span> keywords and values (as
per CGATS).<br>
<br>
There shall be a <span style="font-weight: bold;">DEVICE_CLASS</span>
keyword that has a value of <span style="font-weight: bold;">"OUTPUT</span>",
"<span style="font-weight: bold;">DISPLAY</span>" or <span
style="font-weight: bold;">"INPUT"</span>.<br>
This indicates what type of device the calibration information is
suitable for.<br>
<br>
A <span style="font-weight: bold;">"DISPLAY"</span> type device may
have a <span style="font-weight: bold;">VIDEO_LUT_CALIBRATION_POSSIBLE
</span>keyword that must have a value of "<span style="font-weight:
bold;">NO</span>" or "<span style="font-weight: bold;">YES</span>",
to indicate whether the display has the ability to be calibrated by
loading VideoLUT values.<br>
<br>
A <span style="font-weight: bold;">"DISPLAY"</span> type device may
have a <span style="font-weight: bold;">TV_OUTPUT_ENCODING </span>keyword
that must have a value of "<span style="font-weight: bold;">NO</span>"
or "<span style="font-weight: bold;">YES</span>", to indicate
whether the calibration was created withing the video (16-235)/255
compressed range of device value. This is used to signal to a
VideoLUT loader whether calibration values should be converted to
video encoded range when loaded into hardware. The calibration
values stored in the .cal file are never video encoded themselves,
i.e. 0.0 is always device minimum, and 1.0 is always device maximum.<br>
<br>
There shall be a keyword <span style="font-weight: bold;">COLOR_REP</span>
that has a value that indicates what colorspaces of the device
values. The colorspaces shall be encoded with one or two
letters per component. The device spaces shall use the following
letter encoding:<br>
<br>
<span style="font-weight: bold;"><span style="font-weight: bold;"></span></span>
Cyan
C<br>
Magenta
M<br>
Yellow
Y<br>
Black
K<br>
Orange
O<br>
Red
R<br>
Green
G<br>
Blue
B<br>
White
W<br>
Light Cyan
c<br>
Light
Magenta
m<br>
Light
Yellow
y<br>
Light
Black
k<br>
Medium Cyan
2c<br>
Medium Magenta
2m<br>
Medium Yellow
2y<br>
Medium Black
2k<br>
Light Light Black 1k<br>
<br>
There may be an a prefix <span style="font-weight: bold;">i</span>
preceding the device space letter encoding, indicating that although
the space appears to be an additive space, it is in fact a
subtractive device.<br>
<br>
Typical values might be: "<span style="font-weight: bold;">RGB</span><span
style="font-weight: bold;"></span>" for an RGB display, "<span
style="font-weight: bold;">iRGB</span><span style="font-weight:
bold;"></span>" for an RGB printer, "<span style="font-weight:
bold;">CMYK</span>" for a printer, "<span style="font-weight:
bold;">RGB"</span> for an RGB scanner.<br>
<br>
The <span style="font-weight: bold;">NUMBER_OF_FIELDS</span>
keyword shall have a value that indicates the number of fields in
each data set, e.g. <span style="font-weight: bold;">4</span> (as
per CGATS).<br>
<br>
The start of the declaration of the fields shall be marked by the <span
style="font-weight: bold;">BEGIN_DATA_FORMAT</span> keyword (as
per CGATS).<br>
<br>
The fields shall use the standard CGATS pattern of the full
colorspace identified followed by the individual colorant
identifier. There shall be an initial input index value identified
by the letter <span style="font-weight: bold;">I</span>.<br>
<br>
For an RGB device, the following fields would be used:<br>
<br>
<span style="font-weight: bold;">RGB_I</span>
The device value input value between 0.0 and 1.0.<br>
<span style="font-weight: bold;">RGB_R</span>
The Red device value input value between 0.0 and 1.0.<br>
<span style="font-weight: bold;">RGB_G</span>
The Green device value input value between 0.0
and 1.0.<br>
<span style="font-weight: bold;">RGB_B</span>
The Blue device value input value between 0.0
and 1.0.<br>
<br>
The corresponding field names for a CMYK device would be <span
style="font-weight: bold;">CMYK_I</span>, <span
style="font-weight: bold;">CMYK_C</span>, <span
style="font-weight: bold;">CMYK_M</span>, <span
style="font-weight: bold;">CMYK_Y</span> and <span
style="font-weight: bold;">CMYK_K</span>, etc.<br>
<br>
The definition of the fields shall be terminated by the <span
style="font-weight: bold;">END_DATA_FORMAT</span> keyword (as per
CGATS).<br>
<br>
The <span style="font-weight: bold;">NUMBER_OF_SETS</span> keyword
shall have a value that indicates the number of sets of data, e.g. <span
style="font-weight: bold;">256</span> (as per CGATS).<br>
<br>
The start of the values of the data sets shall be marked by the <span
style="font-weight: bold;">BEGIN_DATA</span> keyword (as per
CGATS).<br>
<br>
Each set of data shall be on one line, and shall be separated by
white space. All values shall be normalized to lie between 0.0 and
1.0.<br>
<br>
The end of the values of the data sets shall be marked by the <span
style="font-weight: bold;">END_DATA</span> keyword (as per CGATS).<br>
<br>
There may then be device type specific extra tables that hold target
or device behavior information. These will be specific to the tool
that creates that particular type of calibration.<br>
<br>
Generally any other keywords and values will be ignored.<br>
<br>
<br>
</body>
</html>
|
