Three component color encoding registry
Three component color encodings (mostly RGB) are defined in this part of the characterization registry. The definitions are derived from various sources, including published international standards and specifications published by individual companies or consortia.
The definitions can be used as follows:
The term "color space" is commonly used to refer to color encodings, but this is not strictly correct as the specification of a color encoding includes more than the specification of the color space. This registry includes complete color encoding information, including the color space, the encoding specifications, and the reference medium and viewing conditions (if applicable).
|Name||Definition||Image state||White point
|Adobe RGB (1998)
||Adobe RGB (1998) color image encoding||Output-referred||D65|
|bg-sRGB||Amendment 1 to IEC 61966-2-1:1999||Output-referred||D65|
||Amendment 1 to IEC 61966-2-1:1999||Output-referred||D65|
||ISO 22028-2:2013||Output-referred (print)||D50|
||European Colour Initiative (ECI)||Output-referred||D50|
Equations defining the characterisation data for v4 colorimetric profiles may be obtained as a pdf file on the color encoding description page.
In many cases links are given to example profiles. These are for convenience only and do not represent any endorsement by ICC.
Transforming via the ICC PCS
In most cases the three component color encoding specifications as published do not use the same reference color space as that used by ICC. In such cases this means that the specifications provided for these three component color encoding specifications have had to be extended in this registry to provide the characterisation data necessary for building ICC profiles. These extensions follow each of the formal specifications in a section headed 'Hints for profile makers'.
Two types of extensions have been provided. The first is a chromatic adaptation correction to convert the data from the specified reference color space to the D50 color space required for ICC profiles. In calculating this use has been made of a matrix (derived from the Bradford chromatic adaptation transformation) provided on the ICC web-site for converting D65 data to D50.
The second extension is appropriate when deriving tables for the colorimetric rendering intents in version 4 profiles. In order to understand this some background may be helpful. In earlier versions of the ICC specification a single PCS was assumed that was based on the concept of a virtual reflection print with no defined gamut or black point. In the latest version this has changed. While the PCS for the perceptual rendering intent is still assumed to be that of a reflection print (but with a defined dynamic range), the PCS for the colorimetric rendering intents is no longer assumed to be the colorimetry for any specific reference medium, but simply the colorimetry of the media as measured and chromatically adapted to D50.
However, for encoding purposes, many RGB color encodings are scaled or normalized, often with the reference medium white scaled to Y=1 and the reference medium black scaled to Y=0. In some of the reference color encoding standards this scaling is explicitly provided, for example ISO 22028-2 (ROMM RGB) and the Adobe RGB (1998) Color Image Encoding Specification. In other cases the scaling is not provided, and in some cases the reference medium black point may not be clearly specified, but is required for making v4 profiles. In the latter case the information provided in this registry effectively extends the color encoding specification interpretation, and other interpretations may also be used. ISO 22028-1 provides additional information regarding some standard color encodings. This registry follows the ISO 22028-1 recommendations where provided.
Furthermore, it should be noted that common practice when making version 2 RGB profiles is to scale the encoding zero to zero in the PCS. Then, it is up to the color management system to know that if encoding zero maps to XYZ zero in the version 2 PCS, that this value probably results from a scaled encoding black point. (One goal of the version 4 revision was to remove this ambiguity.)