Appendix A. Profile Anatomy
The ICC specification prescribes a format for various classes of what are generically referred to as ICC profiles. The intent of the format is to be both platform-independent and application-independent. Before the work of the ICC, profiles were either platform-specific or application-specific.
This appendix provides color geeks with more technical information about what various ICC profiles contain. Naturally it’s not a substitute for the ICC spec itself, which is available at www.color.org, the Web site of the International Color Consortium.
The specification is set to circulate as a Draft International Standard, with possible approval by the end of 2004 as ISO 15076. After approval it’s expected that the complete ISO version will be released as version 4.2 of the ICC specification to bring the two into parity.
Profile Structure
All ICC profiles have the following three segments: a profile header, a tag table, and tagged element data (see Figure A-1).
Figure A-1 ICC Profile cross-section
Profile Header
The profile header contains information that allows searching and sorting ICC profiles—the header is always exactly 128 bytes. The profile header contains the following encoded parameters, in order:
Profile size
The total profile size in bytes.
CMM Type signature
This specifies the preferred CMM—effectively the default CMM. It’s possible to define no preferred CMM. Signatures must be registered to avoid conflicts.
Profile version
The version of the ICC specification to which the profile conforms. There are placeholders for major revisions (defined as newly added/changed required tags, necessitating an updated CMM to use the profile); minor revisions (defined as newly added/changed optional tags that don’t require an updated CMM to use the profile); and bug fix revisions.
Profile Class
This defines the class of profile.
Additional profile classes are:
Color space signature
There are 25 possible signatures for both device and non-device color spaces. This includes XYZ, CIELAB, CIELUV, YCbCr, CIEYxy, RGB, gray, HSV, HLS, CMYK and CMY explicitly, and any custom color space containing between 2 and 15 channels.
Profile Connection Space signature
There are only two options for the PCS: CIEXYZ or CIELAB.
Primary platform signature
Defines the platform on which the profile was created. The six possibilities are: Apple Computer, Inc.; Microsoft Corporation; Silicon Graphics, Inc.; Sun Microsystems, Inc.; Taligent, Inc.; and no primary platform.
Profile flags
There are two flags. One specifies whether the profile is currently a standalone profile (not embedded) or is embedded in a document. The other specifies whether or not the profile, when embedded, can be extracted from the document in which it’s embedded, and made into a standalone profile.
Device manufacturer and model signatures
Signatures for devices must be registered with the ICC. Too many devices are registered to list here.
Device attributes
This describes the media associated with the device the profile applies to. Options are: reflective or transparency; glossy or matte; positive or negative; color or black and white. This frequently contains incorrect data, which doesn’t affect the performance of the profile (like all of the data in this segment), but forces us to differentiate profiles using the profile name rather than the device attributes signature.
Rendering intent
This specifies the default rendering intent table in the profile. Options are perceptual, media-relative colorimetric, saturation, and ICC-absolute colorimetric. See Figure A-2 for the “mother” cross-reference of rendering intent tags.
Figure A-2 Profile class to rendering intent cross-reference
Profile Creator signature
This identifies the creating manufacturer of the profile from the device manufacturer signatures list (mentioned previously).
Profile ID
This is generated with the MD5 fingerprinting method—a value of zero indicates the ID hasn’t been calculated. This signature is currently optional.
Tag Table
The tag table is the second and smallest segment of a profile, but is as vital to a profile as the index file is to a database, or the table of contents is to a book. It contains a tag count listing the total number of tags in the profile, followed by a sequential list of each tag contained in the profile. The list refers to each tag using a 4-byte tag signature registered with the ICC, a 4-byte offset to denote where the data for that tag starts, and a 4-byte size value to denote how long that tag is.
Tagged Element Data
This third segment of a profile contains the meat and potatoes—white point information, the profile description that appears in pop-up menus, rendering intent tables, tone response curves, etc.
One way to envision this is that the tag table is like the card catalog in a library, while the tag element data portion of the profile is the books—the analogy works better if you imagine books with no covers, just page after page with no obvious beginning or end to each book. The tag table tells the CMS what each tag is, and where it’s located in the profile. It’s important because the tags can come in any order, and some tags can be any length.
Required Tags
The ICC profile specification includes both required and optional tags. The following required tags must be in every ICC profile.
profileDescriptionTag
This contains the profile name that appears on menus. The file name and profile name are two different things. The profileDescriptionTag is the real profile name. This is required by the additional profile classes as well.
mediaWhitePointTag
This is the measurement of media white, in CIEXYZ, which is used in the calculation of the absolute colorimetric rendering intent. Absolute colorimetric rendering is computed from the AtoB1Tag and BtoA1Tag in conjunction with a mediaWhitePointTag.
chromaticAdaptationTag
If the actual illumination source is not D50, this tag is required, and is used to convert the actual illumination source to the PCS illuminant (which is D50).
copyrightTag
The profile copyright is stored as a 7-bit ASCII string, also required by the additional profile classes.
Input Profiles
Input profiles support grayscale, RGB, and CMYK input devices. In theory, they could describe multichannel input devices as well, although we don’t know of a package that makes CMYK input profiles, let alone multi-channel ones. (We aren’t aware of a package that makes monochrome input profiles either.) So the options are, RGB matrix, RGB table-based, and RGB matrix-and-table-based input profiles.
Matrix-Based Profiles
For RGB matrix-based input profiles, only two additional tag types are required, for a total of 10 tags. The data contained in these two tags is very small, which is why RGB matrix profiles are typically only a few kilobytes in size. The additional required tags are:
MatrixColumnTag
The three required MatrixColumn tags are redMatrixColumnTag, greenMatrixColumnTag, and blueMatrixColumnTag. They contain the XYZ tristimulus value of the primary (red, green, or blue, respectively). CIELAB is not supported in matrix profiles.
TRCTag
There are also three Tone Reproduction Curve (TRC) tags: green-TRCTag, redTRCTag, and blueTRCTag.
Table-Based Profiles
For RGB table-based input profiles, there is only one additional tag required, but it can contain a substantial amount of information when compared to matrix-based profiles.
AtoB0Tag
This table contains device-to-PCS data for the perceptual rendering intent. Only the perceptual rendering intent is required for table-based input profiles, although other rendering intents are supported as well. Both 8-bit and 16-bit precision are supported. The PCS data may be represented as either CIEXYZ or CIELAB.
Hybrid Profiles
The ICC specification, version 4.0, supports input profiles that are both matrix- and table-based.
Display Profiles
Monochrome display profiles are supported by the ICC spec with just a single grayTRCTag, but the much more common color display profiles are, like input profiles, RGB matrix-based, RGB table-based, and RGB matrix-and-table-based profiles.
The required tags for RGB matrix-based display profiles are identical to those for RGB matrix-based input profiles. Table-based and hybrid display profiles require one additional tag, described next.
BtoA0Tag
This contains the PCS-to-device perceptual table. This tag is required to ensure that display profiles are reversible. Though the perceptual table is required, this does not mean that perceptual rendering is used: this tag almost always contains colorimetric data, so renderings are always colorimetric—either relative or absolute.
Output Profiles
The ICC specification allows for TRC-only monochrome output profiles, although we’re again hard-pressed to think of a package that makes them. For all practical purposes, you’ll find that output profiles are generally RGB, CMYK, and (much more rarely) grayscale table-based profiles. The ICC spec currently supports up to 15-channel profiles (in version 4.0.0), but the common CMMs support only up to 8-channel output profiles. Here are the required tags.
AtoBTag and BtoATag
There are six possible tags representing both the rendering intent and the direction (to the PCS or from the PCS). It’s easy to get them confused—one way to remember is to think “A to P” and “P to A” instead of “A to B” and “B to A,” where “P” is the PCS and “A” is the device.
• The AtoB0Tag is device-to-PCS perceptual rendering
• The AtoB1Tag is device-to-PCS colorimetric rendering
• The AtoB2Tag is device-to-PCS saturation rendering
• The BtoA0Tag is PCS to device perceptual rendering
• The BtoA1Tag is PCS to device colorimetric rendering
• The BtoA2Tag is PCS to device saturation rendering
Notice that there’s only a single colorimetric table. See “mediaWhitePointTag” for more information. For a description of how rendering intents are actually applied in conversions, see the sidebar “Rendering Intents and Conversions.”
gamutTag
This table contains PCS values on the input side, and on the output side a single value, either 1 or 0. A value of 1 means the PCS value is out-of-gamut, and a value of 0 means the PCS color is in-gamut.
Additional Profile Classes
Besides device profiles (including “virtual device” profiles such as Adobe RGB (1998), Colormatch RGB and sRGB), the ICC specification allows for four additional classes of profile. The additional profile classes are: Device-Link, Color Space Conversion, Abstract, and Named Color.
DeviceLink
DeviceLink profiles allow for direct device-to-device conversions—they’re essentially profiles that contain a conversion from one profile to another. While they typically contain only a single source and destination profile, any number of device and nondevice spaces in series can be combined in a DeviceLink profile, though the first and last profiles in the chain must represent device spaces. Four tags are required for Device-Link profiles: profileDescriptionTag, AtoB0Tag, profileSequenceDescTag, and copyrightTag.
DeviceLinks may appear to break the rule that you always need two profiles to make a conversion, but under the hood, a devicelink contains at least two profiles even though it’s a single file.
ProfileSequenceDescTag
This describes the sequence of the profiles contained in the link.
ColorSpace Conversion
ColorSpace conversion profiles are used by CMMs to convert between different device-independent color spaces, such as between CIELAB and CIELUV. These profiles can be embedded in images—if you have a LAB image that isn’t based on D50, you need a suitable ColorSpace Conversion profile embedded in it.
Abstract
Abstract profiles are intended to perform image editing by transforming color data within the PCS. In practice they are rarely, if ever, used. We know of only two packages that create them: Kodak Custom Color ICC, and ITEC ColorBlind Edit.
Named Color
Named color profiles (often referred to as NCPs) are used to support named color systems such as Pantone, Focoltone, or vendor-specific custom colors. The requirement is for the named colors to be associated with a device-independent (typically LAB) value. The optional, but most practical aspect of NCPs is to reference each named color to device values, thereby ensuring the best possible reproduction of a named color on a specific device.