"What's wrong with the ICC profile format anyway ?"

Date: 99/2/14
Author: Graeme Gill
In reading the ICC Profile Format Specification Version 3.4, and in trying to understand how to use ICC Profiles, a number of issues have arisen. I hope these comments might provoke some feedback on the ICC profile, and also could help someone else in the position of puzzling over how it is all meant to work ...

Specification problems:

4.8
There is a contradiction on the definition of the tag offset value: 4.8 defines offset to be "An address within an ICC profile,  relative to byte zero of the file", while icc.h defines it in  the icTag structure to be "Start of tag relative to start of  header, Spec. Clause 5".  (It makes more sense that the offset be invariant with its embedding  within a file, i.e. icc.h is right, and 4.8 should really read:  "An address within an ICC profile, relative to byte zero of the profile".)
6.3
The required tags for various profiles is not extensive or precise enough - i.e. there is no reference to non RGB Display profiles, or non Monochrome/RGB/CMYK Output profiles (i.e. Hexachrome). The RGB Display profile only lists the requirements for a matrix based profile, and doesn't show the required tags for a multidimensional table based profile, even though the requirement of a single ATOB0 tag is hinted at in table 22. It is unclear what good it is to have a Display profile with just the ATOB tag present, since most usual uses of a display profile will need the BTOA tag.. (Version 1998-09 of the spec addresses this area somewhat, but there are still many unspecified areas.)
6.4.15
There is a an ambiguity in the gamutTag entry. There is no definition of what color space the gamut table is in. (Presumably it is in PCS, but this should be made explicit.)
6.5.5,     6.5.6
There is no clear explanation of how all color spaces are represented as input or outputs of Luts.

The section explaining how to apply the matrix operation to XYZ encoded input does appear to be consistent with the description of XYZ value encoding as table values described in table 68 in Annex A, since it implies the application of a u1.15 number as an index into the input tables, but it would be nice to have this made explicit.

There is no reference on how a PCS space of Lab should be normalized for input to the input tables however. One could make a guess at normalizing L to its maximum valid value of 100.0,  but should this really be normalized to 100.390625, which is the maximum value representable in 16 bit representation ?. What values should be used for a and b: +127/-128 taken from the 8 bit encoding, or +127.9961/-128 from the 16 bit encoding in Annex A ?

 [Profiles in practice seem to normalize 16 bit Lab to 100.0 and 127/-128 irrespective of them being 8 or 16 bit tables ? - but see the SIGGRAPH course note below.]

On output one could assume that XYZ and Lab should be encoded as per Annex A, yet there are still problems with this. Sections 6.5.5 and 6.5.6 do not make any reference to Annex A as the definition of PCS encoding for output, but make reference only to "output table entry is appropriately normalized to the range 0 - 65535." for Lut16, and "normalized to the range 0 - 255." in the case of Lut8. In contrast, Annex A is explicitly referred to as the encoding used for named color conversions. If Annex A is assumed to apply, then this would seem to indicate that Lut8 is inappropriate for translating to a PCS of XYZ, since there is no definition for 8 bit representation of XYZ. If the output is Lab from a LUT16, does one expect the output values to already be in the representation of tables 69 and 70 of Annex A, or should the output values of L be scaled from the range 0000h-FFFFh to the range 0000h-FF00h, as seems logical for Lab the input ?  Is an  8 bit XYZ Lut profile illegal ?

Input and output representation for pure device spaces (i.e. RGB, CMY and CMYK) can be guessed at as being already normal, and just in need of scaling to the integer input or output resolutions of the tables, but where are the definitions of the normalization needed for other color spaces mentioned in 6.1.5: Luv, YCbCr, Yxy, HSV, HLS ? Why aren't these normalizations made explicit in the specification ?

[Michael Bourgoin, in his 1998 SIGGRAPH course "Color Management with ICC Profiles", notes that there is much confusion about 16 bit Lab encoding. He indicates that the Annex A encoding should be assumed for both input and output encoding to the Lut type processing model. icclib V1.21 and later adopts this interpretation.]

6.5.7
Table 45 indicates that a flare value of 100% (1.0) should be represented by an encoded value of 00010000h, but the example icc34.h file indicates a value of 00000001h, which is more consistent with other tables. The text accompanying table 45 indicates that measurement flare is "equivalent to the basic numeric type u16Fixed16Number in clause 5.3.3.", yet doesn't clarify whether it is a variable value, or an enumeration from table 45. In practice flare seems to be a u16.16 variable, not an enumeration, so table 45 should be deleted, and the description of flare be made clear.
6.5.23
This section on the XYZ type says "Tristimulus values must be non-negative. The signed encoding allows for implementation optimizations by minimizing the number of fixed formats." In fact, since the XYZ array type is used to store the matrix profile "primaries", and the collection of the RGB "primaries" forms a transform matrix from linearised device channels into XYZ, there is no guarantee that the matrix values will be positive. The device could have physically unrealizable primaries due to device specific color manipulations, or even normalization done in the process of creating profiles with D50, relative colorimetric intent. Some real world profiles have matrix "primaries" with -ve values. [Thanks to Richard F. Lyon for pointing out the existence of -ve primary values in some matrix profiles.]
6.5.24
The "surround" is not defined. I have come across two conflicting defintions for Surround in the context of viewing conditions. One defines it as the area immediately surrounding the color stimulous. Another defines this as "background", and the remainder of the visual field outside the background as the surround. For Color Appearance Models that make a distinction between background and surround (for instance the CIECAM97s model), the ICC profile doesn't have any standard way of storing the surround value.
Annex A
Indicates how absolute colorimetry should be converted to relative colorimetry with respect to the white point, and although the black point tag description indicates it is is also involved in the conversion, Annex A fails to specify how the black point should be used in the transform. It is unclear then, whether the relative color information used in a profile is normalized to the media black point or not. [I am assuming this is so in icclib versions prior to V2.0.]
Annex E
There seems to be a contradiction here in how Absolute Colorimetric values should be converted into Relative values. On page 118, a straightforward mapping in XYZ spaces is specified, yet on page 124 a Von Kries transformation (or similar) is reccomended for translating between the Absolute Colorimetric white point and the D50 Relative Colorimetric white point. This contradiction is made obvious when the sRGB (www.sRGB.com) profile is examined. The sRGB profile takes great care in transforming the Absolute Colorimetric D65 white point profile into a Relative Colorimetric D50, ICC compatibe profile using a "Bradford Transform" matrix, and embeds in the profile the D65 white point as the Media White Point. If one then uses the Relative to Absolute transformations recommened in Annex E and Annex A, one does not end up with the original Colorimetric data that the sRGB was created from. [icclib versions prior to V2.0 used the XYZ Von Kries transform for absolute to relative transformations, while version V2.0 and later use the Bradford variant of the Von Kries transform.]

Conceptual problems:

There is no explanation of how the different LUT table types (i.e. AtoB0, AtoB1, AtoB2 etc.) support different rendering intents. It seems to me that the intent (no pun intended) of this scheme to have multiple tables within the profile labeled with particular intents, was to provide a mechanism for fast linking of Device space to PCS and PCS to Device space profiles. This might work for instance if there was a standardized PCS gamut specified by the ICC in PCS co-ordinates. The idea would be that each AToB conversion would map the gamut of the device into the standard sized PCS gamut, with a given intent. Each BToA conversion would then map the standard sized PCS gamut to the device gamut, with a given intent. In this fashion the PCS co-ordinates do not need gamut mapping, allowing very fast profile linking.  Given that no such gamut standard is defined, such usage is impossible in an interchangeable way. Why the ICC profile carries the baggage of the 3 different LUT table types is therefore a puzzle.
The ucrbgType is meaningless in a precise sense, since Under Color Removal and Black Generation are rules that are applied over the whole gamut space. Single values or curves are only meaningful if the algorithm used for UCR and BG is part of the specification. [i.e. This entry is not useful for interchange purposes, and is effectively a private tag. ]

The profile specification does not encourage the recording of the pure device characterization. There is the issue mentioned above of using simple XYZ white point transformations vs. sharpened cone white point transformations. Another instance,  is the case of Input profiles,where the specification talks about providing Device to PCS conversion using an AtoB type Lut, which is in fact the inverted profile of an input device. The non-inverted (natural) profile is the PCS to Device conversion. Given that there is no guarantee that a particular device will have a unique mapping (i.e. it could be non-monotonic), the inverted profile mandated by the ICC spec. will necessarily have lost some of the device characteristics, whereas the non-inverted profile would be able to fully characterize such an ill-behaved device. The same problems exist with monochrome and RGB linear mixing model input profiles.

 In the same vein, the statement that "Multidimensional tables are not allowed to be included in monochrome profiles" is very unfortunate, since this forbids fully characterizing a monochrome device. The assumption that a monochrome device moves in a direct line from its black point to its white point in XYZ space is a convenient simplification for many purposes, but cannot be justified in real world devices, and using a multi-dimensional Lut would allow encoding the full device character.

It is also a pity that the media Black point is not a mandatory part of the profile in the same way the the media White point is, since the lack of the black point makes absolute colorimetric profile interpretation inaccurate, if (as the media black point profile tag description indicates), it is necessary for this..

The Lab representation raises a number of issues in its use within Luts, due to its inability to store values greater than 100.0. If one attempts to use an Lab based Lut to represent an input profile, for instance, there is a problem in storing the device profile in such a way that the Absolute Colorimetric information can be retained. Scanners are characterised by scanning a test chart with known CIE test patches (ie. a Q-60 chart). This chart doesn't necessarily exercise the full gamut of a devices, so to reach the gamut boundaries of the device, some degree of extrapolation from the test points is required. The white point will almost certainly be taken from white of the test chart, which may be a white with a great deal less than 100% reflectance. In making the Absolute profile relative, the extapolated test points on the devices gamut boundary will be divided by the white point, resulting in raw Lab values that can't be represented in the relative ICC profile, and have to be clipped. It is then perfectly possible that a real life sample placed on the scanner may generate device coordinates that can only be represented by these out of range Lab values, and even if the profile is interpreted as an Absolute profile, the resulting PCS values will be incorrect.

A further limitation of Lab based  ICC profiles, is that the idealized medium is a reflection print. Reflection prints inherently have an upper limit of 100% reflectance, meaning that no image value can be brighter than the white point. Other media do not have this limitation. Real world scenes, photographic media and computer rendered scenes, for instance, can all contain large dynamic range values, where some values are whiter than the adapted white point an observer will have when viewing the image. One is forced to use 16 bit XYZ profiles, with their limitations of profile size, and preceptual interpolation inacuracy to overcome this limitation.

Use in practice problems:

On examining a number of ICC profile files made by some of the founding companies of the ICC, I made the following observations:
Many profiles (albeit of creation some time ago), do not conform to the standard for some particular tags. The namedColorType2 TagTypes were often in practice, weird hybrids of namedColorType, and namedColorType2 TagTypes. Some Unicode strings seem to be of incorrect lengths. [Implementation bugs ?]

Some profiles (noticeably those generated by Apples Colorsync), do not encode 16 bit Lab values as per Annex A, or as per Apples own colorsync documentation, but encode it as if an L value of 100.0 is represented by a binary value of 0xFFFF.
[I don't know whether more recent release of Colorsync have fixed this problem.]

It was noticeable that some important additions are being made in practice to the usage of ICC profiles, but this is not being reflected in the standard. The most noticeable is the creation of a Hexachrome profile, with the addition of the "MCH6" colorspace, and the different number of (apparent) required tags. (AToB tags not being present). This should be documented in section 6.3.  ["MCH6" seems to have leaked in from a Colorsync enumerations ?]

I have seen some examples of  Input style RGB->Lab profiles, in which both an A2B0 tag, and the RGB Phosphor primaries and transfer curve information is present. This was unexpected, since the phosphor/curve (i.e. Matrix) model normally only converts to/from a PCS of XYZ. In addition, some specific examples of this type of profile created on the Solaris platform, had some very strange phosphor primary values...

Another concern is the number of private tags that are contained in commercial examples of profiles. One wonders if they are merely enhancing the use of the profile for a particular manufacturer, or whether in fact this private information is essential for getting reasonable quality results.

Many of these issues give me the feeling at times of reluctant rather than open co-operation between some of the companies that created this standard. Having said that, there does seem enough information in the public standard (when combined with examining available existing  profiles) to effectively and accurately characterize color profiles of devices and color spaces. I could imagine there being some poor results at times though, due to some looseness in the spec.

Other comments:

I am a little concerned that the use of BToA LUTs for color conversion from PCS to Device space leads to poor accuracy in the color conversion. The PCS to device space conversion is (in general) done with an interpolation table lookup. This lookup uses an even sided multi-dimensional grid. Given the gamut of typical devices (and not withstanding the possibility of using the 3x3 matrix if the PCS  is XYZ space), then the range of the multi-dimensional grid actually used will be a small fraction of its total volume. What this means  in practice is that gamut in the device space will be controlled by relatively few table entry values, leading to poor lookup accuracy  given the space devoted to the LUT table. An additional problem for CMYK devices is that using a PCS to Device space lookup removes any control over the black generation and under color removal for at profile link time.

One approach to solving this problem would be to introducing a new PCS, which would be either CIE XYZ or L*a*b* augmented with an "auxiliary black ink chanel". This would then permit the presevation of the black ink generation, when converting between CMYK forward and reverse profiles.

An alternate approach to solving these problems is to ignore the BToA LUTs, and use a reverse lookup of the AToB LUT. Working against this is the fact that many profile creators, creating profiles for output devices, seem to store the AToB LUTs with reduced resolution,  assuming the the BToA LUTs are of primary concern. An emphasis during the creation of profiles in conveying the natural profile accurately, rather than the inverted profile, would go some way to addressing this issue.

Return to Home Page