blob: d419e11e9d392e6665f801f26a05f2559f12de63 [file] [log] [blame]
Name Strings
Alain Bouchard, Matrox
Brian Paul, Tungsten Graphics
Daniel Vogel, Epic Games
Eric Werness, NVIDIA
Kiril Vidimce, Pixar
Mark J. Kilgard, NVIDIA
Pat Brown, NVIDIA
Yanjun Zhang, S3 Graphics
Jeremy Sandmel, Apple
Herb Kuta, Quantum3D
Mark J. Kilgard, NVIDIA Corporation (mjk 'at'
Implemented by NVIDIA's Release 80 driver series for GeForce FX
(NV3x), GeForce 6 and 7 Series (NV4x and G7x), and Quadro FX (NV3xGL,
NV4xGL, G7xGL).
Date: January 24, 2007
Revision: 0.8
OpenGL 1.1 required
EXT_texture_compression_s3tc interacts with this extension.
NV_texture_compression_vtc interacts with this extension.
This extension is written against the OpenGL 2.0 (September 7,
2004) specification.
Conventional texture formats assume a linear color space. So for
a conventional internal texture format such as GL_RGB8, the 256
discrete values for each 8-bit color component map linearly and
uniformly to the [0,1] range.
The sRGB color space is based on typical (non-linear) monitor
characteristics expected in a dimly lit office. It has been
standardized by the International Electrotechnical Commission (IEC)
as IEC 61966-2-1. The sRGB color space roughly corresponds to 2.2
gamma correction.
This extension adds a few new uncompressed and compressed color
texture formats with sRGB color components.
1) What should this extension be called?
The "EXT_texture" part indicates the extension is in the texture
domain and "sRGB" indicates the extension is adding a set of
sRGB formats. ARB_texture_float is similarly named where "_float"
indicates float texture formats are added by the extension.
The mixed-case spelling of sRGB is the established usage so
"_sRGB" is preferred to "_srgb". The "s" stands for standard
(color space).
For token names, we use "SRGB" since token names are uniformly
2) Should this extension mandate that sRGB conversion be performed
RESOLVED: Post-filtering sRGB color conversion is allowed though
pre-filtering conversion is the preferred approach.
Ideally, sRGB conversion moves from the non-linear sRGB to the
linear RGB color space. However, implementations should be
provided leeway as to whether sRGB conversion occurs before or
after texture filtering of RGB components.
3) Should the alpha component of sRGB texture formats be
RESOLVED: No. Alpha is correctly understood to be a weighting
factor that is best stored in a linear representation. The alpha
component should always be stored as a linear value.
"SRGB_ALPHA" is used to indicate sRGB formats with an alpha
component. This naming (as opposed to something like "SRGBA")
helps highlight the fact that the alpha component is separate
and stored with a linear distribution of precision.
4) Should formats for sRGB luminance values be supported?
RESOLVED: Yes. Implementations can always support luminance
and luminance-alpha sRGB formats as an RGB8 or RGBA8 format with
replicated R, G, and B values.
For lack of a better term, "SLUMINANCE" will be used within
token names to indicate sRGB values with identical red, green,
and blue components.
5) Should formats for sRGB intensity values be supported?
RESOLVED: No. Intensity uses the same value for both luminance
and alpha. Treating a single value as an sRGB luminance value
and a linear alpha value is undesirable.
Hardware design is simplified if alpha never involves sRGB
6) Should all component sizes be supported for sRGB components or
just 8-bit?
RESOLVED: Just 8-bit. For sRGB values with more than 8 bit of
precision, a linear representation may be easier to work with
and adequately represent dim values. Storing 5-bit and 6-bit
values in sRGB form is unnecessary because applications
sophisticated enough to sRGB to maintain color precision will
demand at least 8-bit precision for sRGB values.
Because hardware tables are required sRGB conversions, it doesn't
make sense to burden hardware with conversions that are unlikely
when 8-bit is the norm for sRGB values.
7) Should color tables, convolution kernels, histogram table,
and minmax table entries support sRGB formats?
The internalformat for histogram table entries determines the bit
precision of the histogram bin counters so indicating the sRGB
color space is meaningless in this context. The internalformat
for minmax table entries simply indicates the components
for minmax bounding so indicating the sRGB color space is
Convolution filter values are weighting factors rather than
color values needing a color space.
Color table entries may be colors but the component values are
typically stored with more than 8 bits already. For example,
software implementations of the OpenGL color table functionality
typically store colors in floating-point.
8) Should generic compressed sRGB formats be supported?
RESOLVED: Yes. Implementations are free simply to use
uncompressed sRGB formats to implement the GL_COMPRESSED_SRGB_*
9) Should S3TC compressed sRGB formats be supported?
RESOLVED: Yes, but only if EXT_texture_compression_s3tc is also
advertised. For competitive reasons, we expect OpenGL will need
an S3TC-based block compression format for sRGB data.
Rather than expose a separate "sRGB_compression" extension,
it makes more sense to specify a dependency between
EXT_texture_compression_s3tc and this extension such that when
BOTH extensions are exposed, the GL_COMPRESSED_SRGB*_S3TC_DXT*_EXT
tokens are accepted.
We avoid explicitly requiring S3TC formats when EXT_texture_sRGB
is advertised to avoid IP encumbrances.
10) Should the S3TC decompression algorithm be affected by support
for sRGB component values?
S3TC involves the linear weighting of two per-block R5G6B5 colors.
The sRGB to linear RGB color conversion should occur AFTER the
linear weighting of the two per-block colors performed during
texel decompression.
Also be aware that an sRGB value with 8-bit red, green, and blue
components must be quantized to a 5, 6, and 5 bits respectively
to form the two per-block R5G6B5 colors.
S3TC compressors may wish to account for the sRGB color space
as part of the compression algorithm.
11) Should VTC compressed sRGB formats be supported?
RESOLVED. Yes, for the same reasons as S3TC.
12) Should pixel data entering or exiting the OpenGL pixel path be
labeled as sRGB or conventional linear RGB? This would allow
pixels labeled as sRGB to be converted to a linear RGB color space
prior to processing by the pixel path which includes operations
such as convolution, scale, and bias that presume a linear
color space. If the destination (say a texture with an sRGB
internal format) was sRGB, then linear RGB components would be
converted to sRGB prior to being packed into the texture image.
This would assume new format parameters to glDrawPixels and
glReadPixels indicating the source or destination format was
sRGB if a GL_SRGB_EXT or GL_SRGB_ALPHA_EXT format is specified.
Likewise, a format parameter to glTexImage2D such as GL_SRGB_EXT
would indicate the pixel data was already in an sRGB color space
where GL_RGB would indicate a linear color space. New state
would indicate if the framebuffer held sRGB or linear RGB pixels.
The pixel path should be left blind to color spaces and provide
no implicit conversions.
Core pixel maps and ARB_imaging provides sufficient color
tables so that applications interested in managing color space
conversions within the pixel path can do so themselves.
A 256 entry table outputting floating-point values is sufficient
to convert sRGB to linear RGB.
However when converting from linear RGB to sRGB, one must
be careful to make sure the source linear RGB values are
specified with more than 8 bits of precision and the color
table to implement the conversion must likewise have more than
256 entries. A power-of-two table sufficient to map values
to each of the 256 sRGB encodings for an 8-bit sRGB component
requires at least 4096 entries (a fairly large color table).
Because vertex and fragment programs and shaders operate in
floating-point and have sufficient programmability to implement
the sRGB to linear RGB and vice versa without resorting to large
13) Does this extension imply filtered results from sRGB texture
have more than 8 bits of precision?
RESOLVED: Effectively, yes.
8-bit components of sRGB texels are converted to linear RGB values
which requires more than 8 bits to avoid lose of precision.
This implies the filtering involve more than 8 bits of color
precision per component. Moreover, fragment color (whether by
a fragment program, vertex program, or glTexEnv modes) should
operate at precision beyond 8 bits per color component.
The exact precision maintained (and its distribution) is left to
implementations to define but returning at least 12 but more
likely 16 linear bits per component, post-filtering, is a
reasonable expectation for developers.
This extension assumes fragment coloring is performed
14) What must be specified as far as how do you convert to and from
sRGB and linear RGB color spaces?
RESOLVED: The specification language needs to only supply the
sRGB to linear RGB conversion (see section 3.8.x below).
For completeness, the accepted linear RGB to sRGB conversion
(the inverse of the function specified in section 3.8.x) is as
Given a linear RGB component, cl, convert it to an sRGB component,
cs, in the range [0,1], with this pseudo-code:
if (isnan(cl)) {
/* Map IEEE-754 Not-a-number to zero. */
cs = 0.0;
} else if (cl > 1.0) {
cs = 1.0;
} else if (cl < 0.0) {
cs = 0.0;
} else if (cl < 0.0031308) {
cs = 12.92 * cl;
} else {
cs = 1.055 * pow(cl, 0.41666) - 0.055;
sRGB components are typically stored as unsigned 8-bit
fixed-point values. If cs is computed with the above
pseudo-code, cs can be converted to a [0,255] integer with this
csi = floor(255.0 * cs + 0.5)
15) Does this extension provide any sort of sRGB framebuffer formats
or guarantee images rendered with sRGB textures will "look good"
when output to a device supporting an sRGB color space?
Whether the displayed framebuffer is displayed to a monitor that
faithfully reproduces the sRGB color space is beyond the scope
of this extension. This involves the gamma correction and color
calibration of the physical display device.
With this extension, artists can author content in an sRGB color
space and provide that sRGB content for use as texture imagery
that can be properly converted to linear RGB and filtered as part
of texturing in a way that preserves the sRGB distribution of
precision, but that does NOT mean sRGB pixels are output
to the framebuffer. Indeed, this extension provides texture
formats that convert sRGB to linear RGB as part of filtering.
With programmable shading, an application could perform a
linear RGB to sRGB conversion just prior to emitting color
values from the shader. Even so, OpenGL blending (other than
simple modulation) will perform linear math operations on values
stored in a non-linear space which is technically incorrect for
sRGB-encoded colors.
One way to think about these sRGB texture formats is that they
simply provide color components with a distribution of values
distributed to favor precision towards 0 rather than evenly
distributing the precision with conventional non-sRGB formats
such as GL_RGB8.
16) How does this extension interact with EXT_framebuffer_object?
RESOLVED: No specific interaction language is necessary but
there is no provision that pixels written into a framebuffer
object with a texture with an sRGB internal format for its color
buffer will in anyway convert the output color values into an sRGB
color space. A fragment program or shader could be written to
convert linear RGB values to sRGB values prior to shader output,
but NO automatic conversion is performed.
So you can create a texture with an sRGB internal format (such
as GL_SRGB8_ALPHA8_EXT), bind that texture to a framebuffer
object with glFramebufferTexture2DEXT, and then render into
that framebuffer. If you then texture with the sRGB texture,
the texels within the texture are treated as sRGB values for
17) Should sRGB be supported with a texture parameter rather than
new texture formats?
RESOLVED: Adding new texture formats is the right approach.
Hardware is expected to implements sRGB conversions via hardwired
look-up tables. Such tables are expensive (when sRGB isn't
being used, they are basically "wasted gates") and so we want to
minimize the number of unique tables that hardware must support.
However OpenGL supports various component sizes for RGB and RGBA
Various RGB texture formats have different bit sizes for R, G,
and B that map to [0,1]. Think about RGB5. It encodes values
0/15, 1/15, 2/15, ... 14/15, and 15/15. Excepting 0/15==0.0
and 15/15==1.0, those values are different than the values
for RGB8 which would be 0/255, 1/255, ... 254/255, 255/255.
Technically, you'd need a different sRGB table to toggle between
RGB4 and sRGB4 than you'd need to toggle between RGB8 and sRGB8.
There are also RGB12 and RGB16 textures where it is simply not
tractable to implement 4096 and 65,536 entry tables, nor is the
"real" sRGB conversion math cheap enough to evaluate directly
at those precisions.
What this extension shouldn't require is sRGB conversion for
any component sizes beyond 8-bit. Indeed, it appears the only
component sizes sRGB users really care about are 8-bit components.
This is because if you have more than 8 bits per component,
you typically have enough precision to avoid the complexity
created by a non-linear RGB component encoding. Additionally,
sRGB users are picky about color reproduction so fewer than 8
bits is generally not acceptable to them.
The problem with making a "toggle" (say controlled by
glTexParameter) is that hardware would very likely (indeed
it's pretty much certain) not implement toggling between RGB12
and sRGB12 formats. Recall that OpenGL doesn't mandate internal
formats so you can request GL_RGB8 and have the implementation
actually given you RGB12 or RGB10 or R5G6B5.
It is inappropriate to put in a texture parameter mode where
we say "this mode works just with GL_RGB8 and GL_RGBA8 and yet
only when the underlying internal format is actually RGB8 or
RGBA8". We'd also surely preclude floating-point RGB formats,
signed RGB formats, new HDR formats, and certain compressed RGB
formats from being included because such formats don't really
even make sense for sRGB.
By adding new formats specifically for the sRGB color space,
we avoid all these problems.
We also avoid an awkward precedent where other more varied
color spaces (CYMK, XYZ, and YUV being obvious examples) have
to "toggle" between RGB and RGBA formats. Indeed, already
extensions for such other color spaces (YUV and CMYK at least)
set the precedent of introducing new texture formats.
18) How is the texture border color handled for sRGB formats?
RESOLVED: The texture border color is specified as four
floating-point values. Given that the texture border color can
be specified at such high precision, it is always treated as a
linear RGBA value.
Only texel components are converted from the sRGB encoding to a
linear RGB value ahead of texture filtering. The border color
can be used "as is" without any conversion.
The implication of this is, for example, that two textures with
GL_RGBA8 and GL_SRGB8_ALPHA8_EXT internal formats respectively and
a border color of (0.4, 0.2, 0.9, 0.1) and the GL_CLAMP_TO_BORDER
wrap mode will both return (0.4, 0.2, 0.9, 0.1) if 100% of the
border color is sampled.
By keeping the texture border color specified as a linear
RGB value at the API level allows developers to specify the
high-precision texture border color in a single consistent color
space without concern for how the sRGB conversion is implemented
in relation to filtering.
An implementation that does post-filtering sRGB conversion is
likely to store convert the texture border color to sRGB within
the driver so it can be filtered with the sRGB values coming
from texels and then the filtered sRGB value is converted to
linear RGB.
By maintaining the texture border color always in linear RGB,
we avoid developers having to know if an implementation is
performing the sRGB conversion (ideally) pre-filtering or (less
ideally) post-filtering.
19) How does this extension interact with NV_texture_expand_normal?
RESOLVED: sRGB components are not affected by the "expand normal"
mode even though they are unsigned components because they have
non-linear precision (similar to floating-point).
The alpha component of GL_SRGB8_ALPHA8_EXT and other sRGB formats
with an alpha component is affected by the "expand normal" mode.
The sRGB formats have unsigned components with [0,1] range which
is the requirement for the NV_texture_expand_normal extension's
Be warned because sRGB formats distribute their precision more
towards zero, enabling the GL_EXPAND_NORMAL_NV mode with sRGB
textures will mean there are more representable negative values
than positive values. For example, the 8-bit value 128 maps
roughly to zero when encoded with a GL_RGB8 internal format and
then remapped with the GL_EXPAND_NORMAL_NV mode. In contrast,
the sRGB encoded 8-bit value 188 maps roughly to zero when encoded
with a GL_SRGB8_ALPHA8 internal format and then remapped with
GL_EXPAND_NORMAL_NV. Still 0 will map to -1 and 255 will map
to +1 in either case.
20) What values should glGetTexImage return? Are the sRGB values
returned "as-is" or are they converted to linear RGB first?
RESOLVED: sRGB values are returned "as-is" without an
sRGB-to-linear conversion. Unlike other commands that transfer
pixel data, "No pixel transform operations are performed" on
the queried texture image.
21) How does glCopyTex[Sub]Image work with sRGB? Suppose we're
rendering to a floating point pbuffer or framebuffer object and
do CopyTexImage. Are the linear framebuffer values converted
to sRGB during the copy?
RESOLVED: No, linear framebuffer values will NOT be automatically
converted to the sRGB encoding during the copy. If such a
conversion is desired, as explained in issue 12, the red, green,
and blue pixel map functionality can be used to implement a
linear-to-sRGB encoding translation.
22) Should the new COMPRESSED_SRGB_* formats be listed in an
implementation's GL_COMPRESSED_TEXTURE_FORMATS list?
RESOLVED: No. Section 3.8.1 says formats listed by
GL_COMPRESSED_TEXTURE_FORMATS are "suitable for general-purpose
usage." The non-linear distribution of red, green, and
blue for these sRGB compressed formats makes them not really
23) Could this extension be implemented by hardware with no special
hardware support for sRGB but does support native GL_RGB12 or
GL_RGB16 textures? If so, how?
The conversion from the sRGB encoding to linear encoding described
in section 3.8.x could be performed at texture specification
time (after the image has been transformed by the pixel path)
rather than texture fetch time.
When glTexImage2D, glTexSubImage2D, glCopyTexImage2D, etc. occur,
the pixels would be transformed by the pixel path as normal and
then when pixels are converted to the internal texture format,
the section 3.8.x conversion is applied to the red, green, and
blue components (not alpha). The result of this conversion
can be quantized and stored into the respective red, green,
or blue 12-bit or 16-bit component of the stored texel.
This means when a texture fetch occurs, no fetch-time conversion
is required.
The advantages of this approach is that sRGB conversion is
pre-filtering (the ideal) and the hardware is not required to have
texture fetch hardware to perform the special sRGB conversion.
The disadvantage of this technique is that sRGB textures may
require more space than required if 8-bit component sRGB components
are stored in texture memory.
The ability to implement this extension in this manner provides
one more justification to avoid a "toggle" texture parameter
for sRGB conversion or not.
One caveat to this approach is that glGetTexImage should
return the texel values with the sRGB conversion from section
3.8.x "reverse converted". (The section 3.8.x function is
reversible.) As specified, the conversion is performed at fetch
time so the understanding is that data returned by glGetTexImage
should be the texels prior to the conversion. If the components
are stored converted, that means they must be reverse-converted
when returned by glGetTexImage.
24) How should mipmap generation work for sRGB textures?
RESOLVED: The best way to perform mipmap generation for sRGB
textures is by downsampling the sRGB image in a linear color
This involves converting the RGB components of sRGB texels
in a given texture image level to linear RGB space, filtering
appropriately in that linear RGB space, and then converting the
linear RGB values to sRGB for storage in the downsampled texture
level image.
(Remember alpha, when present, is linear even in sRGB texture
The OpenGL specification says "No particular filter algorithm
is required, though a box filter is recommended as the default
filter" meaning there is no requirement for how even non-sRGB
mipmaps should be generated. So while the resolution to this
issue is technically a recommendation, it is however a strongly
advised recommendation.
The rationale for why sRGB textures should be converted to
linear space prior to filtering and converted back to sRGB after
filtering is clear. If an implementation naively simply performed
linear filtering on (non-linear) sRGB components as if they were
in a linear space, the result tends to be a subtle darkening of
the texture images as mipmap generation continues recursively.
This darkening is an inappropriate basis that the resolved
"best way" above would avoid.
New Procedures and Functions
New Tokens
Accepted by the <internalformat> parameter of TexImage1D, TexImage2D,
TexImage3D, CopyTexImage1D, CopyTexImage2D:
SRGB8_EXT 0x8C41
Accepted by the <internalformat> parameter of TexImage2D,
CopyTexImage2D, and CompressedTexImage2DARB and the <format> parameter
of CompressedTexSubImage2DARB:
Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
Additions to Chapter 3 of the 1.2 Specification (Rasterization)
-- Section 3.8.1, Texture Image Specification:
Add 4 new rows to Table 3.16 (page 154).
Sized Base R G B A L I D
Internal Format Internal Format bits bits bits bits bits bits bits
--------------------- --------------- ---- ---- ---- ---- ---- ---- ----
Add 4 new rows to Table 3.17 (page 155).
Compressed Internal Format Base Internal Format
----------------------------------- --------------------
Add 4 new rows to Table 3.18 (page 155).
Generic Compressed Internal Format Base Internal Format
---------------------------------- --------------------
-- Section 3.8.x, sRGB Texture Color Conversion
Insert this section AFTER section 3.8.14 Texture Comparison Modes
and BEFORE section 3.8.15 Texture Application.
"If the currently bound texture's internal format is one
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT, the red, green, and blue
components are converted from an sRGB color space to a linear color
space as part of filtering described in sections 3.8.8 and 3.8.9.
Any alpha component is left unchanged. Ideally, implementations
should perform this color conversion on each sample prior to filtering
but implementations are allowed to perform this conversion after
filtering (though this post-filtering approach is inferior to
converting from sRGB prior to filtering).
The conversion from an sRGB encoded component, cs, to a linear
component, cl, is as follows.
{ cs / 12.92, cs <= 0.04045
cl = {
{ ((cs + 0.055)/1.055)^2.4, cs > 0.04045
Assume cs is the sRGB component in the range [0,1]."
Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations
and the Frame Buffer)
Additions to Chapter 5 of the 1.2 Specification (Special Functions)
Additions to Chapter 6 of the 1.2 Specification (State and State Requests)
Additions to the OpenGL Shading Language specification
Additions to the GLX Specification
Dependencies on ARB_texture_compression and OpenGL 1.3 or later
If ARB_texture_compression or OpenGL 1.3 or later is NOT supported,
ignore the new COMPRESSED_* tokens, the additions to tables 3.17
and 3.18, and the errors associated with the Compressed* commands.
Dependencies on EXT_texture_compression_s3tc
If EXT_texture_compression_s3tc is NOT supported, ignore the new
COMPRESSED_*_S3TC_DXT* tokens, the additions to table 3.17, errors
related to the COMPRESSED_*_S3TC_DXT* tokens, and related discussion.
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT to token lists in the section
3.8.2 specification language added by EXT_texture_compression_s3tc
when the internal formats COMPRESSED_RGB_S3TC_DXT1_EXT,
Dependencies on NV_texture_compression_vtc
If NV_texture_compression_vtc IS supported, allow the following
tokens to be accepted by the <internalformat> parameter
of CompressedTexImage3DARB and the <format> parameter of
GLX Protocol
Relaxation of INVALID_ENUM errors
TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D,
CompressedTexImage2DARB, CompressedTexSubImage2DARB now accept the
new tokens as listed in the "New Tokens" section.
New errors
INVALID_OPERATION is generated by CompressedTexImage2DARB if
if <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT,
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and <border> is not equal to
INVALID_OPERATION is generated by TexSubImage2D
CopyTexSubImage2D, or CompressedTexSubImage2D if INTERNAL_FORMAT is
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply:
<width> is not a multiple of four or equal to TEXTURE_WIDTH; <height>
is not a multiple of four or equal to TEXTURE_HEIGHT; <xoffset>
or <yoffset> is not a multiple of four.
INVALID_ENUM is generated by CompressedTexImage1DARB if
<internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT,
INVALID_ENUM is generated by CompressedTexSubImage1DARB if <format> is
Errors if NV_texture_compression_vtc is NOT supported
INVALID_ENUM is generated by CompressedTexImage3DARB if
<internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT,
INVALID_ENUM is generated by CompressedTexSubImage3DARB if <format> is
Errors if NV_texture_compression_vtc IS supported
INVALID_OPERATION is generated by CompressedTexImage3DARB
if <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_EXT,
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and <border> is not equal to
INVALID_OPERATION is generated by TexSubImage3D or CopyTexSubImage3D
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply:
<width> is not a multiple of four or equal to TEXTURE_WIDTH; <height>
is not a multiple of four or equal to TEXTURE_HEIGHT; <xoffset>
or <yoffset> is not a multiple of four.
INVALID_OPERATION is generated by CompressedTexSubImage3D
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply:
<width> is not a multiple of four or equal to TEXTURE_WIDTH; <height>
is not a multiple of four or equal to TEXTURE_HEIGHT; <depth> is not
a multiple of four or equal to TEXTURE_DEPTH; <xoffset> <yoffset>,
or <zoffset> is not a multiple of four.
New State
In table 6.17, Textures (page 278), increment the 42 in "n x Z42*"
by 16 (or 12 if EXT_texture_compression_s3tc is not supported).
[NOTE: The OpenGL 2.0 specification actually should read "n x Z48*"
because of the 6 generic compressed internal formats in table 3.18.]
New Implementation Dependent State
NVIDIA Implementation Details
GeForce FX, Quadro FX, and GeForce 6 and 7 Series GPUs store
sRGB texels at 8 bits per component. sRGB conversion occurs
Revision History
0.8: Add issue 24 with recommendation for sRGB mipmap generation.
0.7: Add issue 23 about alternative implementation based on
either GL_RGB12 or GL_RGB16 based on discussions with Jeremy
0.6: Add issue 22 about GL_COMPRESSED_TEXTURE_FORMATS.
0.5: Fix grammar, add issues 20 and 21 based on Brian Paul's
0.4: Update issue 18 based on Matrox feedback.
0.3: Update NV_texture_expand_normal interaction.