xref: /third_party/openGLES/extensions/EXT/EXT_texture_sRGB.txt

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.