198 lines
7.2 KiB
Plaintext
Executable File
198 lines
7.2 KiB
Plaintext
Executable File
|
|
Notes on changes needed for V4.2 (OLD - outdated by icclib V3.0)
|
|
|
|
--------------------------------------------
|
|
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 ??
|
|
[ Create common class having plain ASCII that TextDescription and MultiLocalizedUnicode
|
|
inheret from. ]
|
|
|
|
- - - - -
|
|
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. [ Use reference counting ? ]
|
|
|
|
- - - - - -
|
|
|
|
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.
|
|
|