(0.1)
HP and Microsoft propose the addition of support for a standard color space, sRGB, within the Microsoft OS's, HP products and the Internet. The aim of this color space is to complement the current color management strategies by enabling a third method of handling color in the OS's and the Internet that utilizes a simple and robust device independent color definition that will provide good quality with minimum transmission and system overhead. Based on a colorimetric RGB color space well suited to Cathode Ray Tube (CRT) monitors, television, scanners, digital cameras, and printing systems, such a space can be supported with minimum cost to software and hardware vendors. Our intent here is to promote its adoption by showing the benefits of supporting a standard color space, the suitability of the standard color space we are proposing, and describe some of the system issues and propose a methodology for its implementation on the Web.
Definition:
A color space is a model for representing color numerically in terms of three or more coordinates. e.g. The RGB color space represents colors in terms of the Red, Green and Blue coordinates.
For color to be reproduced in a predictable manner across different devices and materials, it has to be described in a way that is independent of the specific behavior of the mechanisms and materials used to produce it. For instance, color CRTs and color printers use very different mechanisms for producing color. To address this issue, current methods require that color be described using device independent color coordinates, which are translated into device dependent color coordinates for each device.
Definition:
Color management is a term that describes a technology that translates the colors of an object (images, graphics or text) from their current color space to the color space of the output devices like monitors, printers, ….
Traditionally, operating systems have supported color by declaring support for a particular color space, RGB in most cases. However, since RGB varies between devices, color was not reliably reproduced across different devices.
The high-end publishing market could not meet its needs with the traditional means of color support, so the various OS's added support for using International Color Consortium (ICC) profiles to characterize device dependent colors in a device independent way. They use the profiles of the input device that created an image and the output device that displayed the image and create a transform that moves the image from the input device's color space to the output device's color space. This resulted in very accurate color. However, it also involved the overhead of transporting the input device's profile with the image and running the processor overhead of running the image through the transform.
HP and Microsoft propose the addition of a third means of managing color that is optimized to meet the needs of most users without the overhead of carrying an ICC profile with the image: the addition to the OS and the Internet of support for a Standard Color Space. Since the image is in a known color space and the profile for that color space would ship with the OS and browser, this enables the end users to enjoy the benefits of color management without the overhead of larger files. While it may be argued that profiles could buy slightly higher color accuracy, we believe that the benefits of using a standard color space far out-weigh the drawbacks for a wide range of users. The migration of devices to natively support the standard color space will further enhance the speed and quality of the user experience.
We are proposing the use of the color space, sRGB , that is consistent with but is a more tightly defined version of Rec. ITU-R BT.709 as the standard color space for the OS's and the Internet. This space obtained in April 1990 unanimous worldwide agreement as the calibrated nonlinear RGB space for HDTV production and program exchange.
We propose the following style sheet syntax to specify that page elements are in sRGB. Under most conditions, the user will not want to override the color space provided by the page author, so a color space designation would not normally appear in a user style sheet. If no color space is indicated by the author, the User Agent (UA) should interpret this as "no color correction" and continue to render as it does now.
Value: none | Web_sRGB
Initial: none
Applies to: all elements
Inherited: yes
Percentage values: N/A
Example:
BODY { color_space: Web_sRGB }
IMG.no_space { color_space: none }
#mypic001 { color_space: Web_sRGB }
<IMG ID=mypic001 SRC="http://www.site.com/layout.mypic001.gif"
>
<IMG CLASS=no_space SRC="http://www.site.com/layout.mypic002.gif"
>
Once page elements are converted to sRGB, the browser needs to interpret the color space correctly and use the OS color management to image the page. The following table summarizes how the browser handles color management in each of the possible scenarios.
| Style Sheet tagged with sRGB | Style Sheet has no Color Space information | Re-purpose Data outside of Browser/ HTML environment | |
| Embedded Profile in Image | Color Space for Image determined by embedded profile. | Color Space for Image determined by embedded profile. | Color Space for Image determined by embedded profile. |
| Image file specifies sRGB | Color Space for Image is sRGB | Color Space for Image is sRGB | Color Space for Image is sRGB |
| Image has no Color space information. | Color Space for Image is sRGB | Color Space for image is device color space. | Color Space for image is device color space. |
| Text | Color Space for text is sRGB | Color Space for text is device color space. | Color Space for text is device color space. |
| Graphics | Color Space for Graphics is sRGB | Color Space for graphics is device color space. | Color Space for graphics is device color space. |
The following cases describe what an end-user sees in the various scenarios:
The following scenarios describe how to get an image into sRGB when creating it.
We believe that the addition of standard color space, sRGB, support to the Internet and the OS is a complementary addition to the existing color management support that utilizes and expands the benefits and availability of color management to a broader range of users.
Recently the International Color Consortium has proposed and is positioned to provide breakthrough solutions to problems in communicating color in open systems. Yet the ICC profile format does not provide a complete solution for all situations.
Currently, the ICC has one means of tracking and ensuring that a color is correctly mapped from the input to the output color space. This is done by attaching a profile for the input color space to the image in question. This is appropriate for high end users, however, there are a broad range of users that do not require this level of color quality, a broad range of file formats that will never support color profile embedding, and a broad range of uses that discourage people from appending any extra data to their files. It is at this level that a common standard RGB color space becomes useful and necessary.
We expect applications and users that do not want the overhead of embedding profiles with documents or images to convert them to a common color space and store them in that format. Currently there is a plethora of RGB monitor color spaces filling this void. There is a need to merge the many standard and non-standard RGB monitor spaces into a single standard RGB color space. Such a standard could dramatically improve the color fidelity in the desktop environment. For example, if operating system vendors provide support for a standard RGB color space, the input and output device vendors that support this standard color space could easily and confidently communicate color without further color management overhead in the most common situations. The two major factors of this RGB space are the colorimetric RGB definition and the gamma value of 2.22, along with a number of secondary details necessary to enable the clear and unambiguous communication of color.
The dichotomy between the device dependent (e.g. amounts of ink expressed in CMYK or digitized video voltages expressed in RGB) and device independent color spaces (such as CIE LAB or CIE XYZ) has created a performance burden on the system because of the complexity of the transforms, and a reliability gap since the complexity and variety of the transforms make it hard to ensure that the system is properly configured.
To address these concerns and serve the needs of PC and Web based color imaging systems, we propose a colorimetric RGB specification that is based on the average performance of personal computer displays. This solution is supported by the following observations:
This combination of factors makes a colorimetric RGB space well suited for wide adoption since it can both describe the colors in a unambiguous way and be the native space for actual hardware devices. This, many readers will recognize, describes in a roundabout way what has been the practice in color television for some 45 years. This proven methodology provides highest performance where it is needed the most, the fast display of images in CRT monitors.
For computer software and hardware designers the most significant aspect of the proposed space is the 2.22 gamma. Because gamma correction tends to be a topic surrounded by confusion, it is worthwhile spending a few paragraphs discussing it.
The non-linearity of the electro-optical radiation transfer function of CRTs is often expressed by the exponent gamma. This transfer function describes how much visible radiant energy (cd/m2) results from voltages applied to the CRT electron-gun. Because most of the other characteristics of CRT based computer monitors are linear (including DACs and video amplifiers) the resulting transfer function has the same gamma value determining its non-linearity.
(0.1)
Where K1 and K2 are the system gain and offset, D is the normalized pixel value, A is the maximum radiant intensity of the CRT and I is the resulting luminance.
The key point that we wish to convey here is that gamma is dependent only on the electron gun design, and the vast majority of monitors and TV sets in use today are based on designs that result, on average, in the value 2.22 for gamma. Most of the variation between computer monitors and between TV sets are due to the differences in system gain and offsets (K1 and K2), which are partially under control of the user in the form of contrast and brightness knobs. Unfortunately, the actual set-up is often not know, but the best CRT performance happens when the system offset puts the dark parts of the images at the CRT cut-off, i.e. the black (pixel value 0) parts of the CRT image are just about to emit light. Under these conditions equation 0.1 above becomes
(0.2)
and the monitor has the widest-dynamic range. The simplified form in equation 0.2 is what is usually found in the computer literature.
The gamma value 2.22 was the standard for television encoding before the advent of color TVs and was formalized in 1953. It is well matched to the eye own non-linearity and it helps minimize transmission noise in the dark areas. Because all television sets have to display content generated with this encoding, it was very important for all CRT designs to conform to it. Only recently has the computer monitor market become as large as the TV market. As a result, most computer monitors have a native 2.22 gamma, with widest variations being in the set-up and screen reflectivity (older and less expensive display can reflect up to 20% of the ambient light). These factors typically can not be characterized a priori since they might change in the course of the day (ambient light) and at the whim of the user (by modifying contrast and brightness) but in practice the process tends to be self-regulatory, with users looking for darker places to set their monitors and modifying the controls to re-establish the expected display appearance. Exhaustive testing carried at Hewlett-Packard on VGA computer monitors from many brands has shown the average gamma to be indeed 2.22, with a standard deviation of about 0.2.
Two special circumstances will lead computer systems to systematically deviate from the 2.22 gamma response - color dithering for 16 color systems and system imposed gamma correction via look-up-tables (LUT).
The first of course was very common until a few years ago. Until about 1993 most Windows PCs were well described by a gamma of 1.8 because despite having 2.22 gamma display systems, the color were dithered into the 4 bit frame buffers, resulting in a flattening of the system transfer function. This happens because screen dithering mixes colors linearly in the eye, making it less dependent of the CRT non-linearity. Since currently most Windows PC support 16 or 24 bit color modes, 2.22 gamma is now the average.
The second systematic deviation happens when the graphics system in the computer hardware or software imposes its own gamma correction. This is done for a variety of reasons, but is usually an attempt to compromise between image display and graphics/image processing performance (most computer graphic rendering assumes linear radiation space, e.g. transparency operations, and so does image processing, e.g. scaling and filtering). The gamma correcting of image data can be described by applying an exponent (g2) to the image data as follows :
(0.3)
and the apparent system transfer function becomes:
(0.4)
For the Macintosh the apparent exponent (gamma/g2) is around 1.8 and for SGI workstations around 1.7.
In summary, there has been some concern with the choice a 2.22 gamma as opposed to a 1.8 gamma. We feel that there are many reasons to support this choice, including compatibility with a large legacy of images (Photo CD, many Unix workstations, PCís with 256+ colors and their desktop color schemes and icons, several ultra-large image collections, analog television and CCIR 601 images), it is also a better fit with Weberís fraction, it is compatible with numerous standards (TIFF/EP, EXIF, digital TV, HDTV, analog video, and PhotoCD), it is closer to native CRTs gamma and it consistent with a larger market of displays.
For a single color space to achieve acceptance, it must be objective, that is, have a tightly-defined relationship with the CIE standards. We are fortunate to have obtained in April 1990 unanimous worldwide agreement on a calibrated nonlinear RGB space for HDTV production and program exchange.: Rec. ITU-R BT.709. HP and Microsoft suggest using these parameters as the basis for the sRGB color space.
There are two parts to this standard; the viewing environment parameters with its dependencies on the human visual system and the standard device space colorimetric definitions and transformations. The viewing environment descriptions contain all the necessary information, when combined with most color appearance models, to provide conversions between the standard and target viewing environments. The colorimetric definitions provide the transforms necessary to convert between the sRGB color space and the CIEXYZ two degree observer color space.
Reference viewing environments are defined for standard RGB in Table 0.1.
| TABLE 0.1 sRGB viewing environment Parameters | |
| Condition | Srgb |
| Viewing flare | 1.0% |
| Image surround | 20% |
| Luminance level | 80 cd/m2 |
| Illuminant White | x = 0.3127, y = 0.3291 |
| Ambient Illuminance Level | 200 lux |
| Ambient White | x = 0.3457, y = 0.3585 |
The sRGB reference viewing environment corresponds to conditions typical of monitor display viewing conditions.
Viewing flare is specified to be 1.0% of the maximum white-luminance level.
The image surround is defined as 20% of the maximum white luminance. This is close to a CIELAB L* value of 50, while maintaining computational simplicity. The areas surrounding the image being viewed are similar in luminance and chrominance to the image itself. This surround condition would correspond, for example, to a reflection print displayed on a spectrally non-selective gray background of about twenty percent reflectance, where the print and the background are uniformly illuminated by the same light source.
The luminance level is representative of typical CRT display levels.
The chromaticities of the illuminant white are those of CIE D65.
The ambient illuminance level is intended to be representative of a typical office viewing environment. Note that the illuminance is at least an order of magnitude lower than average outdoor levels.
The chromaticities of the ambient white are those of CIE D50.
sRGB in combination with the reference viewing environments can be defined from standard CIE colorimetric values through simple mathematical transformations.
CIE colorimetry provides the basis for sRGB encoding of the color. For the calculation of CIE colorimetric values, it is necessary to specify a viewing environment and a set of spectral sensitivities for a specific capture device. The definitions for sRGB given in equations 1.1 to 1.3 are based on CIE tristimulus values computed for the viewing environment in table 0.1.
The CIE chromaticities for the red, green, and blue Rec. ITU-R BT.709 reference primaries, and for CIE Standard Illuminant D65, are given in Table 0.2.
| TABLE 0.2 CIE chromaticities for ITU-R BT.709 reference primaries and CIE standard illuminant | ||||
| Red | Green | Blue | D65 | |
| x | 0.6400 | 0.3000 | 0.1500 | 0.3127 |
| y | 0.3300 | 0.6000 | 0.0600 | 0.3290 |
| z | 0.0300 | 0.1000 | 0.7900 | 0.3583 |
sRGB tristimulus values for the illuminated objects of the scene are simply linear combinations of the 1931 CIE XYZ values and these RGB tristimulus values can be computed using the following derived relationship:
(1.1)
In the sRGB encoding process, negative sRGB tristimulus values, and sRGB tristimulus values greater than 1.00 are not typically retained and the luminance dynamic range and color gamut of sRGB is limited to the tristimulus values between 0.0 and 1.0 by simple clipping. This gamut, however, is large enough to encompass most colors that can be displayed on CRT monitors.
The sRGB tristimulus values are next transformed to nonlinear sR'G'B' values as follows:
For RsRGB, GsRGB, BsRGB > 0.018:
(1.2a)
For 0 <= RsRGB, GsRGB, BsRGB <= 0.018:
(1.2b)
Some applications, such as photographic film reproduction, require a larger gamut that monitors can provide. Therefore the following negative RGB formulas are provided to help implement this capability.For -0.018 <= RsRGB, GsRGB, BsRGB < 0.0:
(1.3a)
For RsRGB, GsRGB, BsRGB < -0.018:
(1.3b)
Finally, the nonlinear sR'G'B' values are converted to digital code values. This conversion scales the above sR'G'B' values by using the equation below where WDC represents the white digital count and KDC represents the black digital count.
(1.4)
This current specification proposes using a black digital count of 0 and a white digital count of 255 for 24-bit (8-bits/channel) encoding. The resulting RGB values are formed according to the following equations:
(1.5)
This obviously can be simplified as shown below.
(1.6)
Digital broadcast television uses a black digital count of 16 and a white digital count of 235 in order to provide a larger encoded color gamut. While we do not propose currently using this encoding at this time due to the large legacy of images and applications using the previous black and white digital counts, it is vital to allow for a possible future revision to provide this capability.