NV_sRGB_formats

GL_NV_sRGB_formats

Contributors to ARB_framebuffer_sRGB and EXT_texture_sRGB
Mathias Heyer, NVIDIA
Jussi Rasanen, NVIDIA
Greg Roth, NVIDIA

Greg Roth, NVIDIA (groth 'at' nvidia.com)

Complete

Date: 17 Jan, 2013
Revision: 5

OpenGL ES Extension #148

OpenGL ES 2.0 is required.

This extension is written against the OpenGL ES 2.0.25
specification.

Requires EXT_sRGB.

OES_compressed_ETC1_RGB8_texture affects the definition of this
extension.

EXT_texture_storage affects the definition of this extension.

NV_texture_array affects the definition of this extension.

NV_texture_compression_s3tc affects the definition of this
extension.

NV_texture_compression_s3tc_update affects the definition of this
extension.

This extension adds new uncompressed and compressed color texture
formats with nonlinear sRGB color components.

Luminance and luminance alpha provide support for textures
containing sRGB values with identical red, green, and blue
components.

Compressed texture formats using S3TC and ETC1 compression
algorithms are also added to provide compressed sRGB texture
options.

Finally, sized variant of sRGB, sLuminace, and sLuminance_alpha are
provided for immutable textures defined using the EXT_texture_storage
extension.

None

Accepted by the <format> and <internalformat> parameter of
TexImage2D, and TexImage3DNV.  These are also accepted by <format>
parameter of TexSubImage2D and TexSubImage3DNV:

    SLUMINANCE_NV                                  0x8C46
    SLUMINANCE_ALPHA_NV                            0x8C44

Accepted by the <internalformat> parameter of RenderbufferStorage,
TexStorage2DEXT, and TexStorage3DEXT:
    SRGB8_NV                                       0x8C41

Accepted by the <internalformat> parameter of TexStorage2DEXT and
TexStorage3DEXT:
    SLUMINANCE8_NV                                 0x8C47
    SLUMINANCE8_ALPHA8_NV                          0x8C45

Accepted by the <internalformat> parameters of TexImage2D,
TexImage3DNV, CompressedTexImage2D, and CompressedTexImage3DNV as
well as the <format> parameter of TexSubImage2D, TexSubImage3DNV,
CompressedTexSubImage2D, and CompressedTexSubImage3DNV:

    COMPRESSED_SRGB_S3TC_DXT1_NV                   0x8C4C
    COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV             0x8C4D
    COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV             0x8C4E
    COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV             0x8C4F

Accepted by the <internalformat> parameter of CompressedTexImage2D,
and CompressedTexImage3DNV:

    ETC1_SRGB8_NV                                  0x88EE

Add 2 new rows to Table 3.3, "TexImage2D and ReadPixels formats":

                          Element Meaning
    Format Name           and Order        Target Buffer
    ----------------      ---------------  -------------
    SLUMINANCE_NV         Luminance        Color
    SLUMINANCE_ALPHA_NV   Luminance, A     Color

Add 2 new rows to Table 3.4, "Valid pixel format and type
combinations":

    Format                Type             Bytes per Pixel
    ----------------      ---------------  ---------------
    SLUMINANCE_NV         UNSIGNED_BYTE    1
    SLUMINANCE_ALPHA_NV   UNSIGNED_BYTE    2

Add 2 new rows to "Valid combinations of format, type, and sized
internal-format" Table:

    Internal Format        Format              Type
    ----------------       --------            ------
    SLUMINANCE8_NV         SLUMINANCE_NV       UNSIGNED_BYTE
    SLUMINANCE8_ALPHA8_NV  SLUMINANCE_ALPHA_NV UNSIGNED_BYTE


Add 5 new rows to "Specific Compressed Internal Formats" Table

    Compressed Internal Format           Base Internal Format
    -----------------------------------  --------------------
    COMPRESSED_SRGB_S3TC_DXT1_NV         RGB
    COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV   RGBA
    COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV   RGBA
    COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV   RGBA
    ETC1_SRGB8_NV                        RGB

Modify Section 3.7.2 "Alternate Texture Image Specification
Commands"

Modify the first sentence of the last paragraph (added by
NV_texture_compression_s3tc_update):

When the internal format of the texture object is
COMPRESSED_RGB_S3TC_DXT1_EXT, COMPRESSED_RGBA_S3TC_DXT1_EXT,
COMPRESSED_RGBA_S3TC_DXT3_EXT, COMPRESSED_RGBA_S3TC_DXT5_EXT,
COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV
COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, or COMPRESSED_SRGB_ALPHA_-
S3TC_DXT5_NV the update region specified in TexSubImage2D must be
aligned to 4x4 pixel blocks. ...

Modify Section 3.7.3 "Compressed Texture Images"

Add to the description of CompressedTexImage*

If <internalformat> is COMPRESSED_SRGB_S3TC_DXT1_NV,
COMPRESSED_SRGBA_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT3_NV, or
COMPRESSED_SRGBA_S3TC_DXT5_NV, the compressed texture is stored
using one of several S3TC compressed texture image formats.  The
S3TC texture compression algorithm supports only 2D images.
CompressedTexImage3DNV produce an INVALID_OPERATION error if
<internalformat> is an S3TC format and <target> is not TEXTURE_-
2D_ARRAY_NV.

If <internalformat> is ETC1_SRGB8_NV, the compressed texture is an
ETC1 compressed texture.

Change the penultimate paragraph describing CompressedTexSubImage*
(added by NV_texture_compression_s3tc):

If the internal format is one of COMPRESSED_RGB_S3TC_DXT1_NV,
COMPRESSED_RGBA_S3TC_DXT1_NV, COMPRESSED_RGBA_S3TC_DXT3_NV,
COMPRESSED_RGBA_S3TC_DXT5_NV, COMPRESSED_SRGBA_S3TC_DXT1_NV,
COMPRESSED_SRGBA_S3TC_DXT3_NV, or COMPRESSED_SRGBA_S3TC_DXT5_NV
the compressed texture is stored using one of several S3TC
compressed texture image formats ...

Modify Section 3.7.14, "sRGB Texture Color Conversion":

Change the first sentence to:

"If the currently bound texture's internal format is one
of SRGB_EXT, SRGB_ALPHA_EXT, SLUMINANCE_ALPHA_NV, SLUMINANCE_NV,
COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV,
COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV,
or ETC1_SRGB8_NV 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.7.7 and 3.7.8. ..."

The following should be added to table 4.5 "Renderbuffer Image
formats":

SRGB8_NV              color_renderable 8  8  8  -  -  -

In section 6.1.3, modify the last sentence of the description of
GetFramebufferAttachmentParameteriv:

"... For framebuffer objects, components are sRGB-encoded if the
internal format of a color attachment is SRGB_EXT, SRGB8_NV,
SRGB_ALPHA_EXT, SRGB8_ALPHA8_EXT, SLUMINANCE_NV, SLUMINANCE8_NV,
SLUMINANCE_ALPHA_NV, SLUMINANCE8_ALPHA8_NV, COMPRESSED_SRGB_S3TC_-
DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_-
S3TC_DXT3_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV, or ETC1_SRGB8_NV."

If OES_compressed_ETC1_RGB8_texture is not supported, ignore all
references to ETC1_SRGB8_NV.

If EXT_texture_storage is not supported, ignore all references to
glTexStorage2DEXT and TexStorage3DEXT functions, additions to the
"Valid combinations of format, type, and sized internal-format"
Table, and LUMINANCE8_NV and LUMINANCE8_ALPHA8_NV tokens.

If NV_texture_array is not supported, ignore all references to
TexImage3DNV, TexSubImage3DNV, CompressedTexImage3DNV, and
CompressedTexSubImage3DNV.

If EXT_texture_compression_s3tc is not supported, ignore the new
COMPRESSED_*_S3TC_DXT* tokens, the additions to the "Compressed
Internal Format" table, errors related to the COMPRESSED_*_S3TC_DXT*
tokens, and related discussion. Also ignore edits to decription
of CompressedTexSubImage*.

If NV_texture_compression_s3tc_update is not supported, passing
COMPRESSED_SRGB_NV, COMPRESSED_SRGB_ALPHA_NV,
COMPRESSED_SLUMINANCE_NV, COMPRESSED_SLUMINANCE_ALPHA_NV,
COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT1_NV,
COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV, or COMPRESSED_SRGB_ALPHA_S3TC_-
DXT5_NV to the <internalformat> parameter of TexImage2D,
TexImage3DNV, is not supported and will produce an INVALID_VALUE

INVALID_OPERATION is generated by CompressedTexSubImage* if
<internalformat> is COMPRESSED_SRGB_S3TC_DXT1_NV,
COMPRESSED_SRGBA_S3TC_DXT1_NV, COMPRESSED_SRGBA_S3TC_DXT3_NV, or
COMPRESSED_SRGBA_S3TC_DXT5_NV and any of the following apply:
    * <width> is not a multiple of four, and <width> plus
      <xoffset> is not equal to the texture width;
    * <height> is not a multiple of four, and <height> plus
      <yoffset> is not equal to the texture height; or
    * <xoffset> or <yoffset> is not a multiple of four.

INVALID_OPERATION is generated by CompressedTexImage3DNV if
<internalformat> is COMPRESSED_SRGB_S3TC_DXT1_NV, COMPRESSED_SRGB_-
ALPHA_S3TC_DXT1_NV, COMPRESSED_SRGB_ALPHA_S3TC_DXT3_NV,
COMPRESSED_SRGB_ALPHA_S3TC_DXT5_NV, or ETC1_SRGB8_NV and <target> is
not TEXTURE_IMAGE_2D_ARRAY_NV.

INVALID_OPERATION is generated by CompressedTexSubImage2D,
TexSubImage2D, CompressedTexSubImage3DNV, or TexSubImage3DNV, if the
texture image <level> bound to <target> has internal format
ETC1_SRGB8_NV.

None

None

1)  Should this be one extension or two?

    RESOLVED: one. Desktop GL divided this functionality between
    texture_sRGB and framebuffer_sRGB, but the ES extension EXT_sRGB
    which took some features from each of those was only one. For
    consistency with EXT_sRGB, this is a single extension.

2)  Should inherently incomplete compressed sRGB texture attachments
    still return sRGB for FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT
    queries?

    RESOLVED: Yes. Just because they are incomplete doesn't mean they
    aren't attached. Such a query might be performed to determine
    why an FBO is incomplete.

3)  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.

4)  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.

5)  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.

6)  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 ES 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*_NV
    tokens are accepted.

    We avoid explicitly requiring S3TC formats when EXT_texture_sRGB
    is advertised to avoid IP encumbrances.

7)  How is the texture border color handled for sRGB formats?
    (Only relevant if NV_texture_border_clamp is supported.

    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.

    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 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.

8)  Should sRGB framebuffer support affect the pixel path?

    RESOLVED:  No.

    sRGB conversion only applies to color reads for blending and
    color writes.  Color reads for glReadPixels have no sRGB
    conversion applied.

Rev.    Date       Author       Changes
----   --------    ---------    -------------------------------------
 5     17 Jan 2013  groth       Add sized L and LA sRGB formats
                                Drastically flesh out interactions.
 4     11 sep 2012  groth       Further clarify interactions
 3     21 Aug 2012  groth       Reorganzied issues. Clarified some.
 2     15 Aug 2012  groth       Clarified mheyer feedback.
 1     13 Aug 2012  groth       Initial draft based off EXT_texture_sRGB