X Window System Core Protocol - Colors

Colors

At the protocol level, a color is represented by a 32-bit unsigned integer, called a pixelvalue. The following elements affect the representation of colors:

1. the color depth
2. the colormap, which is a table containing red, green, and blue intensity values
3. the visual type, which specifies how the table is used to represent colors

In the easiest case, the colormap is a table containing a RGB triple in each row. A pixelvalue x represents the color contained in the x-th row of the table. If the client can change the entries in the colormap, this representation is identified by the PseudoColor visual class. The visual class StaticColor is similar, but the client cannot change the entries in the colormap.

There are a total of six possible visual classes, each one identifying a different way for representing an RGB triple with a pixelvalue. PseudoColor and StaticColor are two. Another two are GrayScale and StaticGray, which differ in that they only display shades of grey.

The two remaining visual classes differ from the ones above because they break pixelvalues in three parts and use three separate tables for the red, green, and blue intensity. According to this color representation, a pixelvalue is converted into an RGB triple as follows:

1. the pixelvalue is seen as a sequence of bits
2. this sequence is broken in three parts
3. each of these three chunks of bits is seen as an integer and used as an index to find a value in each of three separate tables

This mechanism requires the colormap to be composed of three separate tables, one for each primary color. The result of the conversion is still a triple of intensity values. The visual classes using this representation are the DirectColor and TrueColor ones, differing on whether the client can change colormaps or not.

These six mechanisms for representing colors with pixelvalues all require some additional parameters to work. These parameters are collected into a visual type, which contains a visual class and other parameters of the representation of colors. Each server has a fixed set of visualtypes, each one associated with a numerical identifier. These identifiers are 32-bit unsigned integers, but are not necessarily different from identifiers of resources or atoms.

When the connection from a client is accepted, the acceptance packet sent by the server contains a sequence of blocks, each one containing information about a single screen. For each screen, the relative block contains a list of other blocks, each one relative to a specific color depth that is supported by the screen. For each supported depth, this list contains a list of visualtypes. As a result, each screen is associated a number of possible depths, and each depth of each screen is associated a number of possible visual types. A given visual type can be used for more screens and for different depths.

For each visual type, the acceptance packet contains both its identifier and the actual parameters it contains (visual class, etc.) The client stores this information, as it cannot request it afterwards. Moreover, clients cannot change or create new visual types. Requests for creation of a new window include the depth and the identifier of the visual type to use for representing colors of this window.

Colormaps are used regardless of whether the hardware controlling the screen (e.g., a graphic card) uses a palette, which is a table that is also used for representing colors. Servers use colormaps even if the hardware is not using a palette. Whenever the hardware uses palettes, only a limited number of colormaps can be installed. In particular, a colormap is installed when the hardware shows colors according to it. A client can request the server to install a colormap. However, this may require the uninstalling of another colormap: the effect is that windows using the uninstalled colormap are not shown with the correct color, an effect dubbed color flashing or technicolor. This problem can be solved using standard colormaps, which are colormaps with a predictable association between pixelvalues and colors. Thanks to this property, standard colormaps can be used by different applications.

The creation of colormaps is regulated by the ICCCM convention. Standard colormaps are regulated by the ICCCM and by the Xlib specification.

A part of the X colour system is the X Color Management System (xcms). This system was introduced with X11R6 Release 5 in 1991. This system consists of several additional features in xlib, found in the Xcms* series of functions. This system defines device independent color schemes which can be converted into device dependent RGB systems. The system consists of the xlib Xcms* functions and as well the X Device Color Characterization Convention (XDCCC) which describes how to convert the various device independent colour systems into device dependent RGB colour systems. This system supports the CIEXYZ, xyY, CIELUV and CIELAB and as well the TekHVC colour systems.,