skia / external / github.com / KhronosGroup / OpenGL-Registry / 108-cleanup-xml / . / extensions / SGIX / GLX_SGIX_color_type.txt

XXX - Not complete yet!!! | |

Name | |

SGIX_color_type | |

Name Strings | |

GLX_SGIX_color_type | |

GL_SGIX_color_type | |

Version | |

$Date: 1996/10/01 21:31:47 $ $Revision: 1.5 $ | |

Number | |

89 | |

Dependencies | |

SGIX_fbconfig is required | |

SGI_complex affects the definition of this extension | |

EXT_histogram affects the definition of this extension | |

SGI_color_table affects the definition of this extension | |

Overview | |

This extension enhances the fbconfig types to support extended range | |

real and complex data types. Complex data formats include storage for | |

both real and imaginary parts of a color. The ranges of the data types | |

are extended from [0,1] to [-m0.n0,m1.n1], e.g., [-1.5,4.0]. Most | |

OpenGL data paths which clamp colors to [0,1] are modified to clamp | |

colors to [-m0.n0,m1.n1]. These extended range data types are useful for | |

imaging calculations and multipass shading operations that often require | |

signed data and/or complex data formats. | |

Issues | |

* two concepts are defined in this extension, color components with | |

extended range and storage for complex color components. I'm not | |

sure if the range aspect should be separated from the complex | |

storage aspect -- they both extend GLX so it seemed like a time | |

saver to group them together | |

* how does an application specify the color range it needs to represent? | |

should the min/max values be interpreted specially in ChooseConfig | |

or should they be of a more limited usefulness exact match style? | |

* the spec does not distinguish between old-style [0,1] real color | |

and extend range real color (i.e. no attribute bits). Is this okay? | |

* float input pixel values and float colors automatically support the | |

extended range. Integer colors are still scaled to [0,1]. | |

This means that GetIntegerv of an extended range color can not | |

represent an extended color range. Is this okay? | |

* when the color range is extended this implies that accumulation buffers | |

and texture colors also support the extended range. Is this okay? | |

* if a component isn't stored in the framebuffer (bits == 0) what should | |

range queries return. 0 seems obvious for R, G, and B, but what about | |

alpha. If there is no alpha value, should alpha be the max value? | |

* do transparent pixel values need to be embellished? | |

* is a complex ClearColor and ClearAccum needed? | |

New Procedures and Functions | |

None | |

New Tokens | |

Accepted by the <pname> parameters of GetBooleanv, GetIntegerv, | |

GetFloatv, and GetDoublev and accepted by the <attrib_list> parameter of | |

glXChooseFBConfigSGIX: | |

MIN_RED_SGIX 0x???? | |

MAX_RED_SGIX 0x???? | |

MIN_GREEN_SGIX 0x???? | |

MAX_GREEN_SGIX 0x???? | |

MIN_BLUE_SGIX 0x???? | |

MAX_BLUE_SGIX 0x???? | |

MIN_ALPHA_SGIX 0x???? | |

MAX_ALPHA_SGIX 0x???? | |

Accepted by the <attributes> parameter of glXGetFBConfigAttribSGIX, and | |

by the <attrib_list> parameter of glXChooseFBConfigSGIX: | |

GLX_COLOR_TYPE_SGIX 0x???? | |

GLX_MIN_RED_SGIX 0x???? | |

GLX_MAX_RED_SGIX 0x???? | |

GLX_MIN_GREEN_SGIX 0x???? | |

GLX_MAX_GREEN_SGIX 0x???? | |

GLX_MIN_BLUE_SGIX 0x???? | |

GLX_MAX_BLUE_SGIX 0x???? | |

GLX_MIN_ALPHA_SGIX 0x???? | |

GLX_MAX_ALPHA_SGIX 0x???? | |

Returned by glXGetFBConfigAttribSGIX (when <attribute> is set to | |

GLX_COLOR_TYPE_SGIX) and accepted by the <attrib_list> parameter of | |

glXChooseFBConfigSGIX (following the GLX_COLOR_TYPE_SGIX token): | |

GLX_REAL_COLOR_SGIX 0x???? | |

GLX_COMPLEX_COLOR_SGIX 0x???? | |

Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation) | |

Section 2.7 Vertex Specification | |

Versions of the Color command that take floating-point values | |

accept values nominally between <min> and <max>. <min> corresponds | |

to the minimum value while <max> corresponds to the maximum (machine | |

dependent) value that a compone tmay take on in th framebuffer. | |

The three component variants of the color command set A to <max>. | |

Section 2.12 Colors and Coloring | |

Integer colors are still scaled to the range [0,1] and thus cannot | |

directly represent colors outside the range [0,1]. Floating-point | |

colors can be used to represent colors outside the range [0,1]. | |

Section 2.12.6 (Clamping or Masking) | |

After lighting, RGBA colors are clamped to the range [min, max]. | |

Section 2.12.9 (Final Color Processing) | |

For an RGBA color, each color component (which lies in [min,max]) is | |

converted (by rounding to nearest) to a fixed-point value with m bits | |

for the each of the real and imaginary parts. We assume that the | |

fixed-point representation used represents each value | |

min+(max-min)k/(2^m - 1), | |

where k is in {0, 1, ..., 2^m - 1}, as k (e.g. <max> is represented | |

in binary as a string of all ones). m must be at least as large as | |

the number of bits in the corresponding component of the framebuffer. | |

If the framebuffer is complex, then m must be at least as large as | |

the number of bits in the corresponding real or imaginary part of the | |

component of the framebuffer. | |

[are the rules for the msbs of unsigned color values matching the | |

framebuffer components true for color ranges outside [0,1]?] | |

Additions to Chapter 3 of the 1.0 Specification (Rasterization) | |

Section 3.6.3 (Rasterization of Pixels) | |

Final Expansion to RGBA | |

if a group does not contain an A element, then A is added and set to 1.0. | |

If any of R, G, or B is missing from the group, each missing element is | |

assigned a value of 0.0. | |

RGBA to RGBA Lookup | |

First, each component is clamped to the range [min,max]. If there is a | |

table associated with each of the R, G, B, and A component elements: | |

PIXEL_MAP_R_TO_R for R, PIXEL_MAP_G_TO_G for G, PIXEL_MAP_B_TO_B for B, | |

and PIXEL_MAP_A_TO_A for A. Each element is multiplied by t/(max-min) | |

where t is an integer one less than the size of the corresponding table, | |

and, for each element, and address is found by resounding this value to | |

the nearest integer. For each element, the addressed value in the | |

corresponding table replaces the element. | |

Histogram | |

If HISTOGRAM_EXT is enabled and the width of the table is non-zero, and | |

the pixel groups contain RGBA values, then indices Ri, Gi, Bi, and Ai | |

are derived from the red, green, blue, and alpha components of each | |

pixel group (without modifying these components) by clamping the | |

components to [min,max], multiplying each by t/(max-min) where t is one | |

less than the width of the histogram table, and rounding each to the | |

nearest integer. | |

Color Table | |

The color components of each group that are being replaced by table | |

values are converted to indices by clamping the components to | |

[min,max], multiplying each by one t/(max-min) where t is one less than | |

the width of the color table, and rounding each to the nearest | |

integer. The component value (R, G, B, or A) is then replaced by the | |

value in color table indicated in table E14.2, at the computed index. | |

Final Conversion | |

For RGBA components each element is clamped to [min,max]. The resulting | |

values are converted to fixed-point according to the rules given in | |

section 2.12.9 (Final Color Processing). | |

Section 3.8 (Texturing) | |

Each R, G, B, and A value so extracted is clamped to [min,max]. | |

Each of the four values set by TEXTURE_BORDER_COLOR is clamped to lie | |

in [min,max]. | |

Section 3.8.3 (Texture Environments and Texture Functions) | |

TEXTURE_ENV_COLOR is set to an RGBA color by providing four | |

single-precision floating-point values in the range [min,max] (values | |

outside this range are clamped to it). | |

R, G, B, and A values after being obtained from a supplied texture image, | |

are in the range [min, max]. | |

[modifications to table 3.9???] | |

Section 3.9 (Fog) | |

Each component of Cf is clamped to [min, max] when specified. | |

Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations | |

and the Frame buffer) | |

Color buffers consiste of either unsigned integer color indices or | |

R, G, B, and , optionally A unsigned or signed integer values. The | |

values may also consist of real and imaginary parts. | |

Section 4.1.3 (Alpha Test) | |

red is clamped to lie in [min, max], and then converted to a fixed-point | |

value according to the rules given for an A component in section 2.12.9. | |

Section 4.2.3 (Clearing the Buffers) | |

void ClearColor(clampf r, clampf g, clampf b, clampf a); | |

sets the clear value for the color buffers in RGBA mode. Each of the | |

specified components is clapmed to [min, max] and converted to fixed-point | |

according to the rules of section 2.12.9. | |

void ClearAccum(clampf r, clampf g, clampf b, clampf a); | |

takes four floating-point arguments that are the values, in order, to which | |

to set the R, G, B, and A values of the accumulation buffer (see the next | |

section). These values are clamped to the range [min2,max] where min2 | |

= minimum(-1,<min>) when they are specified. | |

Section 4.2.4 (The Accumulation Buffer) | |

Accumulation buffer values are taken to be signed values in the range | |

[min2,max] where min2 = minimum(-1,<min>). Using ACCUM obtains the R, G, | |

B, and A components from the buffer current selected for | |

reading (section 4.3.2). Each component, considered as a fixed-point | |

values in [min,max] (see section 2.12.9) is converted to floating-point. | |

Each result is then multiplied by value. | |

The color components operated on by Accum must be clamped only if the | |

operation is RETURN. In this case, a value sent to the enabled color | |

buffers is first clamped to [min,max]. Otherwise, results are undefined | |

if the result of an operation on a color component is too large (in | |

magnitude) to be represented by the number of available bits. | |

4.3.2 (Reading Pixels) | |

Conversion to RGBA values | |

The R, G, and B (and possibly A) values form a group of elements. Each | |

element is taken to be a fixed-point value in [min,max] with m bits, where | |

m is the number of bits in the corresponding color component of the | |

selected buffer (see section 2.12.9) | |

Final Conversion | |

For a component, if the type is FLOAT then each component is first clamped | |

to [min, max]; if the type is not FLOAT then each component is first | |

clamped to [0,1]. Then the appropriate conversion formula from Table 4.7 | |

is applied to the component. | |

Additions to Chapter 5 of the 1.0 Specification (Special Functions) | |

None | |

Additions to Chapter 6 of the 1.0 Specification (State and State Requests) | |

None | |

Additions to the GLX Specification | |

[Added to the description of glXChooseFBConfigSGIX ] | |

If any of GLX_MIN_RED_SGIX, GLX_MAX_RED_SGIX, GLX_MIN_GREEN_SGIX, | |

GLX_MAX_GREEN_SGIX, GLX_MIN_BLUE_SGIX, GLX_MAX_BLUE_SGIX, | |

GLX_MIN_ALPHA_SGIX, or GLX_MAX_ALPHA_SGIX are specified in <attrib_list> | |

then the value that follows indicates the minimum or maximum value | |

which can be represented in the OpenGL pipeline as a color. Any | |

OpenGL state which stores color values (e.g. current color, texture | |

data, the color buffer, accumulation buffer, aux buffers, etc) can | |

represent values between the minimum and maximum range. Values | |

are specified as integral numerator, denominator pairs (rational | |

numbers). | |

If GLX_COLOR_TYPE_SGIX is in <attrib_list> then the value that follows | |

indicates how color values are represented in the framebuffer: | |

GLX_REAL_COLOR_SGIX specifies that only the real value of each color | |

component is stored in the color and accumulation buffers. | |

The actual representation of the data is unspecified, but the | |

range that can be represented can be queried using the color | |

component min and max requests. | |

GLX_COMPLEX_COLOR_SGIX specifies that each color component | |

is stored as a complex number. The distribution of bits | |

used to represent the real and imaginary portions of the | |

complex number are unspecified as is the actual representation | |

of the data (two's complement, sign magnitude, floating point etc). | |

GLX_RED_SIZE, GLX_GREEN_SIZE, GLX_BLUE_SIZE, GLX_ALPHA_SIZE | |

are equal to the sum of the number of framebuffer bits used to store | |

both the real and imaginary parts. | |

If an accumulation buffer is present, then it also stores both | |

real and imaginary parts for each color component present. | |

GLX_ACCUM_RED_SIZE, GLX_ACCUM_GREEN_SIZE, GLX_ACCUM_BLUE_SIZE, and | |

GLX_ACCUM_ALPHA_SIZE are equal to the total number of bits used to | |

store each complex component. | |

In general, only non-displayable drawable types (e.g. GLXPbuffers) will | |

be able to be created with FBConfigs which support extended range real or | |

complex color component types (see GLX_DRAWABLE_TYPE_SGIX). | |

GLX Protocol | |

[tbd] | |

Dependencies on EXT_histogram | |

If EXT_histogram is not implemented, then the references to | |

GetHistogramEXT and GetMinmaxEXT in this file are invalid, and should be | |

ignored. | |

Dependencies on SGI_color_table | |

If SGI_color_table is not implemented, then the references to | |

ColorTableSGI and GetColorTableSGI in this file are invalid, and should | |

be ignored. | |

Dependencies on SGI_complex | |

If SGI_complex is not supported, references to GLX_REAL_COLOR_SGIX, | |

GLX_COMPLEX_COLOR_SGIX and GLX_COLOR_TYPE_SGIX in this document are | |

invalid and should be ignored. | |

Errors | |

None | |

New State | |

None | |

New Implementation Dependent State | |

None |