Integrated Color Graphics Device-Dependent Information

Supported Visuals

For color displays:

For grayscale displays, only one visual is supported:

Supported Screen Options

The following Screen Options are supported:

Colormaps and Colormap Management

Color Graphics devices have two hardware colormaps (color lookup tables), each with 256 entries. The X server controls the allocation and contents of these hardware colormaps.

Accessing HP Color Recovery Technology via Xlib

Color Recovery is a technique to generate a better picture by attempting to eliminate the graininess caused by dithering. Access to the Color Recovery capability is transparent when using a 3D graphics API such as Starbase, HP-PHIGS or PEX. If you are producing graphics using Xlib calls, your application must perform some of the necessary processing. At server startup (if Color Recovery is not disabled in the X*screens file), the following properties are defined and placed on the root window:

These properties are of type RGB_COLOR_MAP and carry pointers to structures of type XStandardColormap. They may be interrogated with calls to XGetRGBColormaps. The colormaps in the _HP_RGB_SMOOTH_TRUE_MAP and _HP_RGB_SMOOTH_PSEUDO_MAP structures identify colormaps which are created at server startup and are for use with the TrueColor and PseudoColor visuals, respectively. They are both initialized to contain the 3:3:2 ramp of 8-bit TrueColor. Neither of these colormaps can be modified as they are read-only. The property _HP_RGB_SMOOTH_MAP_LIST is a list of colormaps that are associated with all of the root window's visual IDs that support Color Recovery. When the XGetRGBColormaps routine searches this list for a colormap with a visual ID that matches the visual ID that your window is using and it finds one, your application knows that your visual supports Color Recovery, and uses that colormap for any Color Recovery window in your window's visual.

Note that the algorithm used for the Color Graphics device is slightly different from that used for the HCRX family of devices. If you do not wish for your application to have to do device-specific checks, HP recommends that you use the HCRX encoding algorithm for Color Recovery regardless of the device on which your application is executing. The results on the Color Graphics device will not be optimal, but will generally still be much better than a standard dither. If you are willing to do device-specific checks, the existence of either the _HP_RGB_SMOOTH_TRUE_MAP or _HP_RGB_SMOOTH_PSEUDO_MAP property will indicate the device is Color Graphics.

Color Recovery uses all 256 entries of one of the available colormaps. The color visual used by Color Recovery emulates the 24-bit TrueColor visual; thus, the colors red, green, and blue are typically declared as integers in the range from 0 to 255. Note that each window that uses Color Recovery will have the same colormap contents.

For Color Recovery to produce the best results, the emulated 24-bit TrueColor data is dithered as explained below.

A pixel to be dithered is sent to the routine provided in this example. Note that the values of the variables RedValue, GreenValue, and BlueValue are generated by an application. In this example, the color values are assumed to be in the range 0..255.

The given routine receives the color values and the X and Y window address (X_p and Y_p) of the pixel. The X and Y address is used to access the dither tables. The values from the dither tables are added to the color values. After the dither addition, the resultant color values are quantized to three bits of red and green and two bits of blue. The quantized results are packed into an 8-bit unsigned char and then stored in the frame buffer. In the process of sending the contents of the frame buffer to the CRT, a special section in the hardware then converts the frame buffer's 8-bit data into 24-bit TrueColor data for display.

Here is a routine that can be used to dither the 24-bit TrueColor data.

unsigned char dither_pixel_for_CR(RedValue,GreenValue,BlueValue,Xp,Yp)
  int   RedValue, GreenValue, BlueValue, Xp, Yp;
{
    static short        dither_red[2][16] = {
      {-16,  4, -1, 11,-14,  6, -3,  9,-15,  5, -2, 10,-13,  7, -4,  8},
      { 15, -5,  0,-12, 13, -7,  2,-10, 14, -6,  1,-11, 12, -8,  3, -9}};
    static short        dither_green[2][16] = {
      { 11,-15,  7, -3,  8,-14,  4, -2, 10,-16,  6, -4,  9,-13,  5, -1},
      {-12, 14, -8,  2, -9, 13, -5,  1,-11, 15, -7,  3,-10, 12, -6,  0}};
    static short        dither_blue[2][16] = {
      { -3,  9,-13,  7, -1, 11,-15,  5, -4,  8,-14,  6, -2, 10,-16,  4},
      {  2,-10, 12, -8,  0,-12, 14, -6,  3, -9, 13, -7,  1,-11, 15, -5} };
    int                 red, green, blue;
    int                 x_dither_table, y_dither_table;
    unsigned char       pixel;
 
    /* Determine the dither table entries to use based on the pixel address */
    x_dither_table = Xp % 16;   /* X Pixel Address MOD 16 */
    y_dither_table = Yp % 2;    /* Y Pixel Address MOD 2 */
 
    /* Start with the initial values as supplied by the calling routine */
    red   = RedValue;
    green = GreenValue;
    blue  = BlueValue;
 
    /* Generate the red dither value */
    red += dither_red[y_dither_table][x_dither_table];
    /* Check for overflow or underflow on red value */
    if (red > 0xff) red = 0xff;
    if (red < 0x00) red = 0x00;
 
    /* Generate the green dither value */
    green += dither_green[y_dither_table][x_dither_table];
    /* Check for overflow or underflow on green value */
    if (green > 0xff) green = 0xff;
    if (green < 0x00) green = 0x00;
 
    /* Generate the blue dither value */
    blue += (dither_blue[y_dither_table][x_dither_table]<<1);
    /* Check for overflow or underflow on blue value */
    if (blue > 0xff) blue = 0xff;
    if (blue < 0x00) blue = 0x00;
 
    /* Generate the pixel value by "or"ing the values together */
    pixel = ((red &0xE0) | ((green &0xE0) >> 3) | ((blue &0xC0) >> 6));
    return(pixel);
}