set to zero. If the histogram table would be accomodated by Histogram called with target set to HISTOGRAM, the proxy state values are set exactly as though the actual histogram table were being specified. Calling Histogram with target PROXY HISTOGRAM has no effect on the actual histogram table.

There is no image associated with PROXY HISTOGRAM. It cannot be used as a histogram, and its image must never queried using GetHistogram. The error INVALID ENUM results if this is attempted.

Minmax Table Specification

The minmax table is specified with

void Minmax( enum target, enum internalformat, boolean sink );

target must be MINMAX. internalformat specifies the format of the table entries. sink specifies whether pixel groups will be consumed by the minmax operation (TRUE) or passed on to final conversion ( FALSE).

The error INVALID ENUM is generated if internalformat is not one of the formats in table 3.15 or table 3.16, or is 1, 2, 3, 4, or any of the DEPTH or INTENSITY formats in those tables. The resulting table always has 2 entries, each with values corresponding only to the components of the internal format.

The state necessary for minmax operation is a table containing two elements (the first element stores the minimum values, the second stores the maximum values), an integer describing the internal format of the table, and a flag indicating whether or not pixel groups are consumed by the operation. The initial state is a minimum table entry set to the maximum representable value and a maximum table entry set to the minimum representable value. Internal format is set to RGBA and the initial value of the flag is false.

3.6.4 Rasterization of Pixel Rectangles

The process of drawing pixels encoded in host memory is diagrammed in figure 3.7. We describe the stages of this process in the order in which they occur.

Pixels are drawn using

void DrawPixels( sizei width, sizei height, enum format, enum type, void *data );

format is a symbolic constant indicating what the values in memory represent. width and height are the width and height, respectively, of the pixel rectangle to

Version 2.0 - October 22, 2004

Table 3.5: DrawPixels and ReadPixels type parameter values and the corresponding GL data types. Refer to table 2.2 for definitions of GL data types. Special interpretations are described near the end of section 3.6.4.

be drawn. data is a pointer to the data to be drawn. These data are represented with one of seven GL data types, specified by type. The correspondence between the twenty type token values and the GL data types they indicate is given in table 3.5. If the GL is in color index mode and format is not one of COLOR INDEX,

STENCIL INDEX, or DEPTH COMPONENT, then the error INVALID OPERATION occurs. If type is BITMAP and format is not COLOR INDEX or STENCIL INDEX then the error INVALID ENUM occurs. Some additional constraints on the combinations of format and type values that are accepted is discussed below.

Version 2.0 - October 22, 2004

Table 3.6: DrawPixels and ReadPixels formats. The second column gives a description of and the number and order of elements in a group. Unless specified as an index, formats yield components.

Unpacking

Data are taken from host memory as a sequence of signed or unsigned bytes (GL data types byte and ubyte), signed or unsigned short integers (GL data types short and ushort), signed or unsigned integers (GL data types int and uint), or floating point values (GL data type float). These elements are grouped into sets of one, two, three, or four values, depending on the format, to form a group. Table 3.6 summarizes the format of groups obtained from memory; it also indicates those formats that yield indices and those that yield components.

By default the values of each GL data type are interpreted as they would be specified in the language of the client’s GL binding. If UNPACK SWAP BYTES is enabled, however, then the values are interpreted with the bit orderings modified as per table 3.7. The modified bit orderings are defined only if the GL data type ubyte has eight bits, and then for each specific GL data type only if that type is represented with 8, 16, or 32 bits.

The groups in memory are treated as being arranged in a rectangle. This rectangle consists of a series of rows, with the first element of the first group of the first row pointed to by the pointer passed to DrawPixels. If the value of UNPACK ROW LENGTH is not positive, then the number of groups in a row is width;

Version 2.0 - October 22, 2004

Table 3.7: Bit ordering modification of elements when UNPACK SWAP BYTES is enabled. These reorderings are defined only when GL data type ubyte has 8 bits, and then only for GL data types with 8, 16, or 32 bits. Bit 0 is the least significant.

otherwise the number of groups is UNPACK ROW LENGTH. If p indicates the location in memory of the first element of the first row, then the first element of the Nth row is indicated by

where n is the number of elements in a group, l is the number of groups in the row, a is the value of UNPACK ALIGNMENT, and s is the size, in units of GL ubytes, of an element. If the number of bits per element is not 1, 2, 4, or 8 times the number of bits in a GL ubyte, then k = nl for all values of a.

There is a mechanism for selecting a sub-rectangle of groups from a larger containing rectangle. This mechanism relies on three integer parameters:

UNPACK ROW LENGTH, UNPACK SKIP ROWS, and UNPACK SKIP PIXELS. Before obtaining the first group from memory, the pointer supplied to DrawPixels is effectively advanced by (UNPACK SKIP PIXELS)n+(UNPACK SKIP ROWS)k elements. Then width groups are obtained from contiguous elements in memory (without advancing the pointer), after which the pointer is advanced by k elements. height sets

UNSIGNED INT 2 10 10 10 REV is a special case in which all the components of each group are packed into a single unsigned byte, unsigned short, or

Version 2.0 - October 22, 2004

3.6. PIXEL RECTANGLES

ROW_LENGTH

subimage

SKIP_PIXELS

SKIP_ROWS

Figure 3.8. Selecting a subimage from an image. The indicated parameter names are prefixed by UNPACK for DrawPixels and by PACK for ReadPixels.

unsigned int, depending on the type. The number of components per packed pixel is fixed by the type, and must match the number of components per group indicated by the format parameter, as listed in table 3.8. The error INVALID OPERATION is generated if a mismatch occurs. This constraint also holds for all other functions that accept or return pixel data using type and format parameters to define the type and format of that data.

Bitfield locations of the first, second, third, and fourth components of each packed pixel type are illustrated in tables 3.9, 3.10, and 3.11. Each bitfield is interpreted as an unsigned integer value. If the base GL type is supported with more than the minimum precision (e.g. a 9-bit byte) the packed components are right-justified in the pixel.

Components are normally packed with the first component in the most significant bits of the bitfield, and successive component occupying progressively less significant locations. Types whose token names end with REV reverse the component packing order from least to most significant locations. In all cases, the most significant bit of each component is packed in the most significant bit location of its location in the bitfield.

Version 2.0 - October 22, 2004

Table 3.8: Packed pixel formats.

UNSIGNED BYTE 3 3 2:

UNSIGNED BYTE 2 3 3 REV:

Table 3.9: UNSIGNED BYTE formats. Bit numbers are indicated for each component.

Version 2.0 - October 22, 2004

UNSIGNED SHORT 5 6 5:

UNSIGNED SHORT 5 6 5 REV: