back  Return to list

homeprevnext Name
homeprevnext Name Strings
homeprevnext 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  
homeprevnext Contact
    Mark J. Kilgard, NVIDIA Corporation (mjk 'at'  
homeprevnext 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).  
homeprevnext Version
    Date: January 24, 2007  
    Revision: 0.8  
homeprevnext Number
homeprevnext 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.  
homeprevnext 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.  
homeprevnext 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  
    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?  
        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  
        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?  
        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  
    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?  
        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  
    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?  
        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  
        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.  
homeprevnext New Procedures and Functions
homeprevnext 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  
homeprevnext Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
homeprevnext 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  
        -----------------------------------  --------------------  
    Add 4 new rows to Table 3.18 (page 155).  
        Generic Compressed Internal Format  Base Internal Format  
        ----------------------------------  --------------------  
        COMPRESSED_SRGB_EXT                 RGB  
 -- 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]."  
homeprevnext Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations and the Frame Buffer)
homeprevnext Additions to Chapter 5 of the 1.2 Specification (Special Functions)
homeprevnext Additions to Chapter 6 of the 1.2 Specification (State and State Requests)
homeprevnext Additions to the OpenGL Shading Language specification
homeprevnext Additions to the GLX Specification
homeprevnext 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.  
homeprevnext 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,  
    COMPRESSED_RGBA_S3TC_DXT5_EXT are listed.  
homeprevnext 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  
homeprevnext GLX Protocol
homeprevnext 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_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.  
homeprevnext 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.]  
homeprevnext 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  
homeprevnext 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.  
    0.3:  Update NV_texture_expand_normal interaction.  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.