Additional Interfaces to the Display Part 2

ICC Profiles and the sRGB Standard

Before moving on to other physical and electrical interfaces often used with displays, we should mention two additional standards that relate to the problem of display identification. Prior to the introduction of the DDC and EDID standards, as noted above, the host system had no practical means of determining the capabilities and characteristics of the display in use. This was not only a problem from the standpoint of choosing the correct timing and image format for optimum use of the system, but also in terms of ensuring reasonable accurate color in displayed images. The original broadcast television standards (and to some degree, the newer HDTV standards) avoid color-matching problems to a large degree by specifying the relevant performance parameters of the television receiver. The colors of the phosphors, the white point, and the response or “gamma curve” of the displays to be used within each television system are controlled by the standards defining that system. Broadcasters can transmit programming under the assumption that the display will perform per these requirements, and that colors will therefore be properly rendered.

This has never been the case in the computer industry. While many of the display designs used were originally derived from common television practices, there are truly no comparable standards in this industry. Even in a given product, there are often user adjustments for white point and other factors which can affect the displayed color. This situation requires that the host system also have information on the color aspects of the display, at least the generic capabilities for the model in question and preferably measured data from the specific unit in use.

In the absence of standard channels over which such information could be communicated, the industry employed two approaches. First, a standardized file format was developed, specifically for the purpose of conveying color-related information. Defined by the International Color Consortium, “ICC profiles” may be produced not only for electronic displays, but also printers, cameras, and other image input and output devices. Profile information may be attached to image files when a given input device creates them, and this, along with the corresponding output-device profile, may be used by the system to correct or compensate the video data for proper color rendering. Such profiles are, like the VDIF description mentioned above, generally assumed to be supplied by the device manufacturer separate from the device itself. Unlike the DDC/EDID system, there is generally no standard system for obtaining ICC profile information directly from the peripheral itself, and so this method suffers from the same problems as the VDIF. In the case of displays, however, the current definitions of the EDID file and its extensions provide sufficient information so that a reasonably complete ICC profile could be derived from this data. To date, such a translation has not commonly been implemented in either standard operating systems or applications programs.

The ICC profile specification is a fairly complex and flexible standard, and attempting to summarize a typical display profile here would be both difficult and likely misleading. For the purposes of this discussion, it is suffice to note that a complete profile provides the same sort of information as the formats detailed above, such as the color space used by the device, its chromaticity characteristics, response curve(s), etc., but in much more detailed and precise form than could be conveyed in a space-constrained representation such as the EDID file. The full ICC profile specification may be downloaded from the ICC web site (www.color.org), and is recommended if more detailed information is desired.

An alternative, which may be used in the absence of device-specific color information such as an ICC profile, is provided by the “sRGB” standard. This is a specification developed by researchers at Hewlett-Packard Co. and Microsoft (and now standardized as IEC 61966, Part 2.1), and which defines a standard model for a color-output device. The sRGB model establishes norms for the primary colors (based on typical CRT phosphor values), the “white point” (6500K, specifically the CIE D65 illuminant), the response curve or “gamma,” and several other key parameters. Rather than providing for a means of conveying devicespecific information, the sRGB system assumes that standard devices will be built to conform to (or at least can be set up to) these specifications. The operating system or application program therefore can perform color transformations, etc., assuming this standardized output device. Table 11-4 summarizes the key features of the sRGB specification.

The sRGB model can provide significantly improved color performance over the common PC environment in which no information at all about the output device’s characteristics is available or used in the generation of images. It also has the advantage of simplicity; given a single standard definition, color information can be properly generated without the need for complex, device-specific calculation. However, being a generic color system – the definition of a standard “color space” – sRGB lacks flexibility and cannot provide quite the optimum performance for all devices. It is a very CRT-centric definition; the primary colors, response curve, and other factors in effect describe a typical color CRT display, and may not be a good match to the actual characteristics of other types. For critical applications, it is still better to use product-specific information such as an ICC profile or the color information from EDID, or better yet to have such information generated for the particular unit in question.

Table 11-4 Basic sRGB definitions.^a

^a All chromaticity coordinates provided are per the 1931 CIE xy system. The “gamma” and “offset” values define the display response curve as: V = [(V' + 0.055)/1.055]²⁴ for all channels.

Display Control

Beyond merely identifying and describing the display to the host system, there has also been the desire to permit the adjustments and controls commonly provided to the user to be accessed by the host. Such capability cannot only allow the development of “soft” control panels (those which duplicate the front-panel controls of the monitor through software), but also can provide for fully automated adjustment of the display by the video source (as might be the case in automated color correction and management). Such functionality could be implemented via any of a number of general-purpose interfaces already included in many display connector standards, but in several cases new systems intended specifically for the control of various display functions have been defined. Much of this activity has again been performed under the auspices of the Video Electronics Standards Association (VESA), and driven by the needs of the personal computer market. However, many of these standards have attracted the attention of other industries, such as the consumer-television, and are likely to be adopted (and possibly adapted) for their use.

Initially, display control functionality was added to the various interface standards in the form of definitions intended to control specific functions only, such as control of the power-management features. Later, however, as more capable channels have been developed and supported within the interface standards, display control has become more generalized. Using a general-purpose digital interface, commands may be defined for the control of a wide range of disparate display functions. As this trend continues, display control will likely become just another function of a general-purpose, system-wide control and data interface (such as USB), and eventually may come to be transmitted on the same physical and electrical interface as the video data itself, along with other types of supplemental data and commands.

Power Management

As CRT displays represent a significant portion of the electrical power required in most personal computer systems, the development of PC power management techniques in the late 1980s and early 1990s could hardly succeed without attention to these products. Several products and systems were introduced which included the capability for reducing the display power or shutting the display off completely during idle periods, including some which relied on the host simply blanking the video signal for a specified period of time to trigger display shutdown. However, in 1993, VESA released the Display Power Management Signalling (DPMS) standard, and this method was quickly adopted by the industry.

Basically, DPMS allows the host to place the display in any of four defined power states by enabling or disabling the synchronization signals. If either or both sync signals are determined to be inactive by the display, it leaves the normal, “active” mode of operation and enters one of the reduced-power states as shown in Table 11-5. Note that either sync may be considered “inactive” if its rate falls below a defined frequency (40 Hz for the vertical signal, and 10 kHz for the horizontal). This was done to permit host systems that did not have the ability to completely shut off the sync signals to still implement DPMS control, simply by reprogramming the video timing. The four power states were defined to correspond to the “Advanced Power Management” definitions, originally created by Intel and Microsoft for PC systems. DPMS does not specify the actual power levels or recovery times for any of the power states, nor the specific means of implementing the reduced-power states; only the signalling used to control them. However, minimum levels of power-reduction have been specified by various regulatory bodies, such as the Environmental Protection Agency in the US (through their “Energy Star” program). It is assumed, that in general the “deeper” reduced power states will require longer recovery times. In a CRT display, for example, the lowest level of power reduction (the “standby” state) might be implemented by shutting down the deflection circuits, but leaving the CRT filament powered up for a relatively rapid recovery. The deeper “suspend” state might turn the filament off or at least operate it at a greatly reduced power level.

Table 11-5 VESA DPMS power management states. Used by permission of VESA.

^a Note that all video signals must be blanked prior to entering any state below “On”, and should not be restored until after the return to the “On” state.

It is important to note that while the DPMS system permits the display to be put into an “off” state by the host, it is not required that the display be capable of recovering from that state without user intervention. Therefore, it is permissible for the display to be turned off under DPMS control and truly be disconnected from the AC line completely, requiring the user to press the power button to re-enable the display. Most manufacturers have chosen to implement an “active off” state as the lowest-power DPMS level. In such a design, the display continues to consume a very small amount of power even when “off,” but only enough to support continued monitoring of the sync signals and recovery from this state.

The VESA DDC-CI and MCCS Standards

Due to the success of the I2C-based Display Data Channel standard, it was logical to extend the use of this from simply a display-ID channel to a fully bidirectional command and control interface. This was achieved with the release of the VESA “DDC-CI” (Display Data Channel – Command Interface) standard in 1998. The nomenclature of the overall DDC/CI system is somewhat confusing. This standard replaced and expanded upon the earlier “DDC2B+” definition, which was part of the original DDC standard and which permitted the I2C channel to be used in a bidirectional master/slave mode, using an ACCESS.bus host driver. (The difference between this and the full “DDC2AB” mode was that DDC2B+ was a single-device implementation, while “DDC2AB” indicated support for the full ACCESS.bus specification.) The DDC/CI standard redefined this as “DDC2Bi,” and abandoned the ACCESS.bus driver model for a new DDC-specific driver (DDC.DLL at the host PC), although much of the ACCESS.bus protocol definition is retained.

DDC-CI exploits the existing bidirectional capabilities of the I2C interface, adding a new command protocol to the original ID-oriented DDC system. The display device itself operates as an I2C slave device, at address 6E/6F (the EDID information remains accessible as an I2C memory device at A0/A1). The specification also permits a limited number of additional functions or devices to be connected via the DDC2Bi channel, such as pointers (touchscreen, trackball, etc.), audio devices, and so forth. Each is assigned a predefined I2C address by the DDC/CI standard, all in the F0-FF address space. (Other functions have been defined and assigned standard addresses by Philips or other companies/organizations using the I2C system, in other address ranges.)

A separate standard, the VESA Monitor Control Command Set (MCCS), was released along with DDC-CI, and provided a fairly complete set of standard command functions that could be implemented in a CI-capable display. An overview of these is given in Table 11-6. Note that these standards also permit manufacturer-specific “custom” commands to be defined, permitting extension of the basic set as required for a given display product.

^a Unless otherwise noted, all commands are followed by a two-byte value. Codes in the A0-AF range are “read-only”; when given, the display returns a 2-byte value unless otherwise noted. Note: This is an overview, and does not list all codes defined by the MCCS standard. See that standard for details.