| 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 <internalformat> 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 <internalformat> parameter of TexImage2D, | |
| CopyTexImage2D, and CompressedTexImage2DARB and the <format> 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 <internalformat> parameter | |
| of CompressedTexImage3DARB and the <format> 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 <internalformat> 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 <border> 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: | |
| <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, | |
| 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 <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. | |
| Errors if NV_texture_compression_vtc is NOT supported | |
| ----------------------------------------------------- | |
| INVALID_ENUM is generated by CompressedTexImage3DARB if | |
| <internalformat> 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 <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. | |
| 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_DXT1_EXT, | |
| COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT, or | |
| COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT and <border> 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: | |
| <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 | |
| 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: | |
| <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 | |
| 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. |