Name EXT_texture_sRGB Name Strings GL_EXT_texture_sRGB Contributors 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 Contact Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) Status 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). Version Date: January 24, 2007 Revision: 0.8 Number 315 Dependencies 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. Overview 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. Issues 1) What should this extension be called? RESOLVED: EXT_texture_sRGB. 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 capitalized. 2) Should this extension mandate that sRGB conversion be performed pre-filtering? 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 gamma-corrected? 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 conversions. 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? RESOLVED: No. 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 meaningless. 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_* formats. 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? RESOLVED: No. 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. RESOLVED: No. 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 tables. 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 follows: 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 formula: 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? RESOLVED: No. 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 filtering. 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 textures. 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 operation. 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 general-purpose. 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? RESOLVED. Yes. 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 space. 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 formats.) 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 None New Tokens Accepted by the parameter of TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, CopyTexImage2D: SRGB_EXT 0x8C40 SRGB8_EXT 0x8C41 SRGB_ALPHA_EXT 0x8C42 SRGB8_ALPHA8_EXT 0x8C43 SLUMINANCE_ALPHA_EXT 0x8C44 SLUMINANCE8_ALPHA8_EXT 0x8C45 SLUMINANCE_EXT 0x8C46 SLUMINANCE8_EXT 0x8C47 COMPRESSED_SRGB_EXT 0x8C48 COMPRESSED_SRGB_ALPHA_EXT 0x8C49 COMPRESSED_SLUMINANCE_EXT 0x8C4A COMPRESSED_SLUMINANCE_ALPHA_EXT 0x8C4B Accepted by the parameter of TexImage2D, CopyTexImage2D, and CompressedTexImage2DARB and the parameter of CompressedTexSubImage2DARB: COMPRESSED_SRGB_S3TC_DXT1_EXT 0x8C4C COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT 0x8C4D COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT 0x8C4E COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT 0x8C4F Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation) None 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 --------------------- --------------- ---- ---- ---- ---- ---- ---- ---- SRGB8_EXT RGB 8 8 8 SRGB8_ALPHA8_EXT RGBA 8 8 8 8 SLUMINANCE_EXT LUMINANCE 8 SLUMINANCE_ALPHA8_EXT LUMINANCE_ALPHA 8 8 Add 4 new rows to Table 3.17 (page 155). Compressed Internal Format Base Internal Format ----------------------------------- -------------------- COMPRESSED_SRGB_S3TC_DXT1_EXT RGB COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT RGBA COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT RGBA COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT RGBA Add 4 new rows to Table 3.18 (page 155). Generic Compressed Internal Format Base Internal Format ---------------------------------- -------------------- COMPRESSED_SRGB_EXT RGB COMPRESSED_SRGB_ALPHA_EXT RGBA COMPRESSED_SLUMINANCE_EXT LUMINANCE COMPRESSED_SLUMINANCE_ALPHA_EXT LUMINANCE_ALPHA -- 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 of SRGB_EXT, SRGB8_EXT, SRGB_ALPHA_EXT, SRGB8_ALPHA8_EXT, SLUMINANCE_ALPHA_EXT, SLUMINANCE8_ALPHA8_EXT, SLUMINANCE_EXT, SLUMINANCE8_EXT, COMPRESSED_SRGB_EXT, COMPRESSED_SRGB_ALPHA_EXT, COMPRESSED_SLUMINANCE_EXT COMPRESSED_SLUMINANCE_ALPHA_EXT, COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or 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) 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) None Additions to the OpenGL Shading Language specification None Additions to the GLX Specification None 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. Add COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, and 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, COMPRESSED_RGBA_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT3_EXT, and COMPRESSED_RGBA_S3TC_DXT5_EXT are listed. Dependencies on NV_texture_compression_vtc If NV_texture_compression_vtc IS supported, allow the following tokens to be accepted by the parameter of CompressedTexImage3DARB and the parameter of CompressedTexSubImage3DARB: COMPRESSED_SRGB_S3TC_DXT1_EXT COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT GLX Protocol None. Errors 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 is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and is not equal to zero. INVALID_OPERATION is generated by TexSubImage2D CopyTexSubImage2D, or CompressedTexSubImage2D if INTERNAL_FORMAT is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply: is not a multiple of four or equal to TEXTURE_WIDTH; is not a multiple of four or equal to TEXTURE_HEIGHT; or is not a multiple of four. INVALID_ENUM is generated by CompressedTexImage1DARB if is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. INVALID_ENUM is generated by CompressedTexSubImage1DARB if is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. Errors if NV_texture_compression_vtc is NOT supported ----------------------------------------------------- INVALID_ENUM is generated by CompressedTexImage3DARB if is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. INVALID_ENUM is generated by CompressedTexSubImage3DARB if is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT. Errors if NV_texture_compression_vtc IS supported ----------------------------------------------------- INVALID_OPERATION is generated by CompressedTexImage3DARB if is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and is not equal to zero. INVALID_OPERATION is generated by TexSubImage3D or CopyTexSubImage3D if INTERNAL_FORMAT is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply: is not a multiple of four or equal to TEXTURE_WIDTH; is not a multiple of four or equal to TEXTURE_HEIGHT; or is not a multiple of four. INVALID_OPERATION is generated by CompressedTexSubImage3D if INTERNAL_FORMAT is COMPRESSED_SRGB_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and any of the following apply: is not a multiple of four or equal to TEXTURE_WIDTH; is not a multiple of four or equal to TEXTURE_HEIGHT; is not a multiple of four or equal to TEXTURE_DEPTH; , or 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 None 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 post-filtering. 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 Sandmel. 0.6: Add issue 22 about GL_COMPRESSED_TEXTURE_FORMATS. 0.5: Fix grammar, add issues 20 and 21 based on Brian Paul's feedback. 0.4: Update issue 18 based on Matrox feedback. 0.3: Update NV_texture_expand_normal interaction.