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
|
Notes on changes needed for V4.2
--------------------------------------------
Spec name/version/file version relationship.
This is more complicated that it really should be:
Spec. Name Spec. Version File Version
---------- ------------- ------------
ICC.1:2004-10 4.2 4.2.0 <-- target icclib4
ICC.1:2003-09 4.1 4.1.0
ICC.1:2001-12 4.0 4.0.0
ICC.1:2001-04 (3.7?) 2.4.0
ICC.1A:1999-04 (3.6?) 2.3.0
ICC.1:1998-09 (3.5?) 2.2.0
(Version 3.4) 3.4 2.1.0 (a) <-- current icclib
(Version 3.3) 3.3 2.1.0
(Version 3.2) 3.2 2.0.0 (b)
(Version 3.01) 3.01 2.0.0 (a)
(Version 3.0) 3.0 2.0.0
-----------------------------
There are other changes from V2.1 in later versions,
such as:
2.3.0
Chromaticity Tag added
2.4.0
Lut tables now allowed for monochrome
Added chromaticAdaptationTag
Input, Display, Output and Colorspace LUT profiles
now support all 3 intents.
Can this be made backwards compatible without
messing about with specific code for other versions ??
This doesn't seem possible. The profile generator code and icclib
would seem to need to know which version they were generating,
for assured backwards compatibility with other CMMs.
-----------------------------
Should add "guess ink limit" support to ease gamut finding
from profiles. (Implemented in xicc at the moment) ?
-----------------------------
Add usage of #def icVersionNumberV41 when "V4" flag is active.
Tags needed since V2.1
icSigChromaticAdaptationTag = 0x63686164L, /* 'chad' V2.4+ */
icSigChromaticityTag = 0x6368726DL, /* 'chrm' V2.3+ */
icSigColorantOrderTag = 0x636C726FL, /* 'clro' V4.0+ */
icSigColorantTableTag = 0x636C7274L, /* 'clrt' V4.0+ */
icSigColorantTableOutTag = 0x636C6F74L, /* 'clot' V4.0+ */
icSigDeviceSettingsTag = 0x64657673L, /* 'devs' V2.2 - V4.0 */
icSigOutputResponseTag = 0x72657370L, /* 'resp' V2.2+ */
Tag types needed since V2.1
icSigDeviceSettingsType = 0x64657673L, /* 'devs' V2.2 - V4.0 */
icSigChromaticityTag = 0x6368726DL, /* 'chrm' V2.3+ */
icSigColorantOrderType = 0x636C726FL, /* 'clro' V4.0+ */
icSigColorantTableType = 0x636C7274L, /* 'clrt' V4.0+ */
icSigLutAtoBType = 0x6d414220L, /* 'mAB ' V4.0+ */
icSigLutBtoAType = 0x6d424120L, /* 'mBA ' V4.0+ */
icSigMultiLocalizedUnicodeType = 0x6D6C7563L, /* 'mluc' V4.0+ */
icSigParametricCurveType = 0x70617261L, /* 'para' V4.0+ */
icSigResponseCurveSet16Type = 0x72637332L, /* 'rcs2' V2.2 - V4.0 */
Stuff to deal with in implementing ICCV4:
-------------------
Make sure DLL/SO version is compilable ??
Add V4 flag in main icc struct (DONE), and some way of setting it before tags
are added.
Date & time being UTC.
- add flag when setting ?
- display both when dumping ?
- have both in structure when reading ?
- or simply not handle this ??
Check all padding is zero during writing - DONE
Implement MD5 generation on profile writing - DONE
Implement MD5 check method on read profile ?
Cross check MD5 against external V4 profiles. Cross check with cygwin md5sum!
Colorant table tag needed in V4 for xCLR devices.
colorantTableTag requirement for xCLR device link profiles.
Add check that tags are unique within a profile ?
Configure conformance to run as V4.2 or V2.4 on writing, and accept V4.X or V2.X on
reading. Don't try and implement detailed minor version behaviour.
Have some sort of table to embody valid tags and tag types within the two major
version numbers (2 & 4) ??
Check that non A2B0 and B2A0 intents are allowed for Input, Display & Colorspace
profiles ??
V4 mandates a chromatic adaptation tag for any profile that requires a white point
tag & not D50. Add to V4 check, & generate chromatic adaptation tag for V2 & V4
creation (method ?). Need to carefully read spec. to understand what chromatic
adaptation tag is meant to represent.
Implement absolute<->PCS object to represent functionality of chramatic adaptation,
analogous to conversion object.
Check mono profile black and white interpretation.
Matrix/shaper in V4 has clipping requirements. Should these be honoured ??
Maybe make this optional via a run time flag ?
May be best to have multiple conformance flags (Absolute Intent etc. ?)
Check icclink set header rendering intents correctly for device links.
Implemenmt parametric curve type as extra icmCurveStyle(s), and use icmCurve object to
do the work.
Implement MultiLocalizedUnicodeType as overload of icmTextDescription, or new tagtype ??
- - - - -
Implement icSigLutAtoBType and icSigLutBtoAType as overloads of icmLut ??
If so, add new icmLuAlgType types for AtoB and BtoA conversions (NO - more complicated)
- OR -
switch to single superset Lut type ?? (YES - best solution) :-
Should a more extensive general model be considered, as a superset of V4 ?? (YES)
pcs/abs -> Curves -> matrix -> curves -> lut -> curves -> matrix -> curves -> pcs/abs
[ or asymetric ??: (NO)
pcs->curves->lut->3x3+3matrix->curves->pcs/abs (dev->PCS, PCS->PCS, dev->dev)
pcs/abs->curves->3x3+3matrix->curves->lut->curves (PCS->dev) ]
Could use this as universal transform method, even for matrix profiles (don't use old style
matrix/shaper or LUT at all internaly ?) (YES - need to accomodate V2 & V4 though).
Add new methods to setup the transform stages, with current set mathods implemented
as backwards compatible ? Have multiple methods rather than a single "set" ?
( - how are ranges determined in latter case ?)
Finish support for generic 3 stage conversion view (input per chan, cross chan, output per chan.),
and support this in icclib4.
Use bit flags to indicate which stages are valid.
Flags effectively replace "algorithm" flag.
Flag combination set determines how transform can be represented by a profile
(Mono, Matrix, V2Lut, V4Lut etc.).
Have flags for "separable" (i.e. channel independent) and
"reversable".
Support implementing a universal transform both forwards and
backwards from a given set of ICC tags (backwards won't be
valid for some tags, ie. Lut).
lookup object acts as ideal abstract above exact tag representation within
a profile. Use this model for other aspects of ICC profiles.
Extend to simplify xicc/icc relationship - make xicc a true inheriting
class, and add whatever hooks are needed into icclib4 to make this work.
ICC tags -> luo -> transform
ICC tags <- luo <- Set transform
What impact does this have on memory usage though ?
- Makes sure transform is completely independent of
tags or profile after setting up, so that tags and/or
profile can be released.
- - - - - -
Split icc.c into 3 levels:
1 Basic support (I/O, primitives)
Toolkit for buiding ICC like file formats, but not
specic to the actual ICC file. Can be used to
create custom tags, and custom ICC like files (e.g. calibration)
2 Specific to ICC format, tags etc.
3 ICC color transform objects etc.
Allow for inheretance, so that xicc can be implemented
much more elegantly.
|