Back to the OpenGL extension cross reference
GL_SGIX_texture_range
SGIX_texture_range
Name Strings
GL_SGIX_texture_range
Version
$Date: 1999/06/24 02:20:36 $ $Revision: 1.4 $
Number
181
Dependencies
OpenGL 1.2 is required.
SGI_color_range is required
SGIS_texture4D affects the definition of this extension
Overview
This extension defines new internal formats for the storage of signed
texture images, as well as extended range and precision texture images.
IP Status
Silicon Graphics has filed for patent protection for some of the
techniques described in this extension document.
Issues
* Should the fact that the numeric type is different create new base
formats to better classify this difference? Also this might make
sense if there were more than one internal extended-range component
resolutions or types in a given system.
- Yes. New base formats added to spec.
* Don't want to get extended-range when we don't want it
- With new base formats, the user explicitly requests extended-range
or signed internal formats, either sized or not.
* TLUT clamping (clamped to [0, 1])
- Since the texture color lookup section says that it acts as in
section 3.6.3, for color table lookups, and since that section says
that the color is first clamped to [0, 1], then everything should be
fine.
* Do we want to make the fact that there are floating-point formats
visible at the API level?
- Not in this spec. In any future spec that defines the
floating-point formats and their API, we probably should add a query
for exp, mant, sign bits per internal format.
* Since Bali won't have 4D textures, should we take out references to it
in this spec?
- No.
* OK to add tokens for formats not supported by Bali, for completeness?
- Moot point, since we have none. We'll add them as we decide to
implement hardware that uses them.
* Since we're not defining the explicit bit representation of the
format, does it still make sense to define sized formats? Or should
we wait until the floating-point formats are defined to put out sized
enumerants?
- Keep the sized formats in this spec.
* It is often assumed in OpenGL that texture values are in the range
[0, 1]. For instance, in the detail texture extension, the filtered
detail texture color values are scaled by 2 and then have 1 subtracted
to generate a number in the [-1, 1] range. What should happen when
the texture format can support values in the [-1, 1] range, then?
Should the GL still do the scale and bias, or should it just pass the
texture value through?
- Still do the scale and bias. This avoids either a) breaking
previous applications by changing their behavior or b) creating
hardware that does calculations both with and without the scale and
bias.
* Which of the Section 3.8 alterations should be in this spec, as
opposed to the color_range? Which color clamping operations should be
based upon the texture internal format, versus the framebuffer format?
- The color clampings controlled by this spec should be the:
a) Clamping of downloaded texture values.
b) Clamping of the result of the texture filter operation.
Both are clampings based upon the texture internal format. All
other color clamps are based upon the framebuffer format, including
incoming and outgoing colors of the texture environment operation.
* Texture environment clamping is made stickier with multitexturing.
Should the environment function clamp its input values? Its output
values? Should it clamp based upon its associated texture's internal
format, or based upon the framebuffer format?
- See above. All incoming colors, fragment color, texture color,
etc., and the outgoing color, are clamped based upon the framebuffer
format.
* For queries of the min & max component values, what should be returned
if the component doesn't exist in the texture, e.g., MIN_RED_SGIS in
an intensity texture or MAX_INTENSITY_SGIS in an RGBA texture. And
what about alpha, should it be treated differently since it's implied
in non-alpha textures? Should we have the new INTENSITY and LUMINANCE
tokens at all, or should we query the red and/or alpha components' min
and max values?
- If a queried component doesn't exist in the format, both the min and
max are returned as 0, and no error condition is set. Because of
this, we need the INTENSITY and LUMINANCE tokens.
* What about ALPHA, in textures that don't have it, since it ususally
is an implied 1, instead of an implied 0?
- For now, as above, min & max are returned as 0. Since the user has
requested an alpha-free texture format, one would hope they would be
smart enought to not then query the available alpha range. One
would hope.
None
Accepted by the <internalformat> parameter of TexImage1D, TexImage2D,
TexImage3DEXT, TexImage4DSGIS, CopyTexImage1D, and CopyTexImage2D:
RGB_SIGNED_SGIX 0x85E0
RGBA_SIGNED_SGIX 0x85E1
ALPHA_SIGNED_SGIX 0x85E2
LUMINANCE_SIGNED_SGIX 0x85E3
INTENSITY_SIGNED_SGIX 0x85E4
LUMINANCE_ALPHA_SIGNED_SGIX 0x85E5
RGB16_SIGNED_SGIX 0x85E6
RGBA16_SIGNED_SGIX 0x85E7
ALPHA16_SIGNED_SGIX 0x85E8
LUMINANCE16_SIGNED_SGIX 0x85E9
INTENSITY16_SIGNED_SGIX 0x85EA
LUMINANCE16_ALPHA16_SIGNED_SGIX 0x85EB
RGB_EXTENDED_RANGE_SGIX 0x85EC
RGBA_EXTENDED_RANGE_SGIX 0x85ED
ALPHA_EXTENDED_RANGE_SGIX 0x85EE
LUMINANCE_EXTENDED_RANGE_SGIX 0x85EF
INTENSITY_EXTENDED_RANGE_SGIX 0x85F0
LUMINANCE_ALPHA_EXTENDED_RANGE_SGIX 0x85F1
RGB16_EXTENDED_RANGE_SGIX 0x85F2
RGBA16_EXTENDED_RANGE_SGIX 0x85F3
ALPHA16_EXTENDED_RANGE_SGIX 0x85F4
LUMINANCE16_EXTENDED_RANGE_SGIX 0x85F5
INTENSITY16_EXTENDED_RANGE_SGIX 0x85F6
LUMINANCE16_ALPHA16_EXTENDED_RANGE_SGIX 0x85F7
Accepted by the <value> parameter of of GetTexLevelParameterfv and
GetTexLevelParameteriv:
MIN_LUMINANCE_SGIS 0x85F8
MAX_LUMINANCE_SGIS 0x85F9
MIN_INTENSITY_SGIS 0x85FA
MAX_INTENSITY_SGIS 0x85FB
Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
None
Additions to Chapter 3 of the 1.2 Specification (Rasterization)
The following is added to Section 3.8.1:
"... just before final conversion. Each R, G, B, and A value so
generated is clamped to [min, max]. The minimum is implementation-
dependent for extended range and precision internal formats, but at most
0. It is -1 for signed internal formats, and is 0 for all other
formats. The maximum is implementation-dependent for extended range and
precision formats, but is at least 1, and is 1 for all other formats.
The following is added to Table 3.16:
Sized Base R G B A L I
Internal Format Internal Format Bits Bits Bits Bits Bits Bits
--------------- ----------------------------------- ---- ---- ---- ---- ---- ----
RGB16_SIGNED_SGIX RGB_SIGNED_SGIX 16 16 16
RGBA16_SIGNED_SGIX RGBA_SIGNED_SGIX 16 16 16 16
ALPHA16_SIGNED_SGIX ALPHA_SIGNED_SGIX 16
LUMINANCE16_SIGNED_SGIX LUMINANCE_SIGNED_SGIX 16
INTENSITY16_SIGNED_SGIX INTENSITY_SIGNED_SGIX 16
LUMINANCE16_ALPHA16_SIGNED_SGIX LUMINANCE_ALPHA_SIGNED_SGIX 16 16
RGB16_EXTENDED_RANGE_SGIX RGB_EXTENDED_RANGE_SGIX 16 16 16
RGBA16_EXTENDED_RANGE_SGIX RGBA_EXTENDED_RANGE_SGIX 16 16 16 16
ALPHA16_EXTENDED_RANGE_SGIX ALPHA_EXTENDED_RANGE_SGIX 16
LUMINANCE16_EXTENDED_RANGE_SGIX LUMINANCE_EXTENDED_RANGE_SGIX 16
INTENSITY16_EXTENDED_RANGE_SGIX INTENSITY_EXTENDED_RANGE_SGIX 16
LUMINANCE16_ALPHA16_EXTENDED_RANGE_SGIX LUMINANCE_ALPHA_EXTENDED_RANGE_SGIX 16 16
The following is added to Section 3.8.3:
"... values to floating point. Each of the four values set by
TEXTURE_BORDER_COLOR is clamped to lie in [min, max], where min and max
are based upon the internal format of the image in level-of-detail 0, as
specified in section 3.8.1"
Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations
and the Frame Buffer)
None
Additions to Chapter 5 of the 1.2 Specification (Special Functions)
None
Additions to Chapter 6 of the 1.2 Specification (State and State Requests)
The following is added to Section 6.1.3:
"...when the image array was defined. Queries of MIN_RED_SGIS,
MAX_RED_SGIS, MIN_GREEN_SGIS, MAX_GREEN_SGIS, MIN_BLUE_SGIS,
MAX_BLUE_SGIS, MIN_ALPHA_SGIS, MAX_ALPHA_SGIS, MIN_LUMINANCE_SGIS,
MAX_LUMINANCE_SGIS, MIN_INTENSITY_SGIS, and MAX_INTENSITY_SGIS
return the minimum and maximum expressable values of the internal
format of the image. Queries of TEXTURE_WIDTH ..."
Additions to the GLX Specification
None
Dependencies on SGIS_texture4D
If SGIS_texture4D is not supported, all references to TexImage4DSGIS,
TexSubImage4DSGIS, and CopyTexSubImage4DSGIS are ignored.
Errors
None
New State
Get Value Get Command Type Initial Value
--------- ----------- ---- -------------
MIN_RED_SGIS GetTexLevelParameterfv R 0.0
MAX_RED_SGIS GetTexLevelParameterfv R+ 1.0
MIN_GREEN_SGIS GetTexLevelParameterfv R 0.0
MAX_GREEN_SGIS GetTexLevelParameterfv R+ 1.0
MIN_BLUE_SGIS GetTexLevelParameterfv R 0.0
MAX_BLUE_SGIS GetTexLevelParameterfv R+ 1.0
MIN_ALPHA_SGIS GetTexLevelParameterfv R 0.0
MAX_ALPHA_SGIS GetTexLevelParameterfv R+ 1.0
MIN_LUMINANCE_SGIS GetTexLevelParameterfv R 0.0
MAX_LUMINANCE_SGIS GetTexLevelParameterfv R+ 1.0
MIN_INTENSITY_SGIS GetTexLevelParameterfv R 0.0
MAX_INTENSITY_SGIS GetTexLevelParameterfv R+ 1.0
New Implementation Dependent State
Get Value Get Command Type
--------- ----------- ----
TEXTURE_RANGE_SGIX GetBooleanv B
Implementation Support
List of OpenGL implementations supporting the GL_SGIX_texture_range extension
Original File
Original text file for the GL_SGIX_texture_range extension
Page generated on Sun Nov 20 18:38:47 2005