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

Name

    EXT_sRGB

Name Strings

    GL_EXT_sRGB

Contributors

    Maurice Ribble
    Tero Aurto
    Jon Leech
    Mark Callow
    Daniel Koch

    Parts of this extension are copied from ARB_framebuffer_sRGB.
    Parts of this extension are copied from EXT_texture_sRGB.

Contact

    Maurice Ribble, Qualcomm (mribble 'at' qualcomm.com)

Status

    Not complete.

Version

    Date: Sept 14, 2011

Number

    OpenGL ES Extension #105

Dependencies

    This requires OpenGL ES 1.0 or greater.  This extension is written based on
    the wording of the OpenGL ES 2.0 specification.

    This extension requires support for OES_rgb8_rgba8 or equivalent 
    functionality.
    
    If OES_texture_3D is not supported then the parts of this extension for 3d
    textures should be ignored.
    
    If this is being used with ES 1.x then you need to support 
    OES_framebuffer_object for the framebuffer object related features in this
    extension.

Overview

    The sRGB color space is based on typical (non-linear) response of the human
    eye.  It has been standardized by the International Electrotechnical 
    Commission (IEC) as IEC 61966-2-1.  The transfer function of sRGB roughly
    corresponds to a power function with a gamma of 2.2.

    FRAMEBUFFERS

    OpenGL assumes framebuffer color components are stored in a linear color
    space.  In particular, framebuffer blending is a linear operation.

    This extension adds a framebuffer capability for sRGB framebuffer update
    and blending.  When blending is disabled but the new sRGB updated mode is
    enabled (assume the framebuffer supports the capability), high-precision 
    linear color component values for red, green, and blue generated by
    fragment coloring are encoded for sRGB prior to being written into the
    framebuffer.  When blending is enabled along with the new sRGB update mode,
    red, green, and blue framebuffer color components are treated as sRGB
    values that are converted to linear color values, blended with the high-
    precision color values generated by fragment coloring, and then the blend
    result is encoded for sRGB just prior to being written into the 
    framebuffer.
    
    TEXTURES

    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.

New Procedures and Functions

    None

New Tokens

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

        SRGB_EXT                                       0x8C40
        SRGB_ALPHA_EXT                                 0x8C42
    
    Accepted by the <internalformat> parameter of RenderbufferStorage:
        SRGB8_ALPHA8_EXT                               0x8C43
        
    Accepted by the <pname> parameter of GetFramebufferAttachmentParameteriv:
        FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT      0x8210

Additions to Chapter 3 of the 2.0 Specification (Rasterization)

Modify Section 3.7.1, Texture Image Specification:

    Add 2 new rows to Table 3.3

        SRGB_EXT             R, G, B        Color
        SRGB_ALPHA_EXT       R, G, B, A     Color

    Add 2 new rows to Table 3.4
    
        SRGB_EXT           UNSIGNED_BYTE     3
        SRGB_ALPHA_EXT     UNSIGNED_BYTE     4

Modify Section 3.7.11: Mipmap Generation

    Add the following sentence to the end of this section:
    
    If the format of a texture is sRGB, he error INVALID_OPERATION is 
    generated.
        
Add Section 3.7.14, sRGB Texture Color Conversion

    If the currently bound texture's internal format is one of SRGB_EXT or 
    SRGB_ALPHA_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.7.7 and 3.7.8. 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 Specification

    DELETE the following sentence from section 4.1.6 (Blending) because it is 
    moved to the new "sRGB Conversion" section:

    Each of these floating-point values is clamped to [0,1] and converted back
    to a fixed-point value in the manner described in section 2.1.2.

    Replace the following sentence:

    Destination (framebuffer) components are taken to be fixed-point values 
    represented according to the scheme in section 2.1.2 (Final Color 
    Processing), as are source (fragment) components.

    with the following sentences:

    Destination (framebuffer) components are taken to be fixed-point values
    represented according to the scheme in section 2.1.2 (Final Color
    Processing).  The R G, and B destination color values (after conversion
    from fixed-point to floating-point) are considered to be encoded for the
    sRGB color space and hence need to be linearized prior to their use in
    blending.  Each R, G, and B component is linearized by some approximation
    of the following:

            {  cs / 12.92,                 cs <= 0.04045
       cl = {
            {  ((cs + 0.055)/1.055)^2.4,   cs >  0.04045

    where cs is the component value prior to linearization and cl is the 
    result.

    If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the 
    framebuffer attachment corresponding to the destination buffer is SRGB, the
    R, G, and B destination color values (after conversion from fixedpoint to 
    floating-point) are considered to be encoded for the sRGB color space and 
    hence must be linearized prior to their use in blending. Each R, G, and B 
    component is converted in the same fashion described for sRGB texture 
    components as described below.
    
    If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT is not SRGB, no 
    linearization is performed.
    
    The resulting linearized R, G, and B and unmodified A values are
    recombined as the destination color used in blending computations.

    ADD new section 4.1.X "sRGB Conversion".  With this new section added,
    understand the "next operation" referred to in the section 4.1.6
    (Blending) to now be "sRGB Conversion" (instead of "Dithering").

    "If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the 
    framebuffer attachment corresponding to the destination buffer is SRGB, the
    R, G, and B values after blending are converted into the non-linear sRGB 
    color space by computing:
    
             {  0.0,                          cl        <= 0
             {  12.92 * c,                    0         <  cl < 0.0031308
        cs = {  1.055 * cl^0.41666 - 0.055,   0.0031308 <= cl < 1
             {  1.0,                                       cl >= 1

    where cl is the R, G, or B element and cs is the result (effectively
    converted into an sRGB color space).

    The resulting cs values for R, G, and B and the unmodified A form a new 
    RGBA color value. If the color buffer is fixed-point, the components of
    this RGBA color value are clamped to [0,1] and then converted to a fixed-
    point value.  The resulting four values are sent to the subsequent 
    dithering operation."
    
    The following should be added to table 4.5 Renderbuffer Image formats:
    SRGB8_ALPHA8_EXT     color_renderable 8  8  8  8  -  -

Additions to Chapter 5 of the 2.0 Specification (Special Functions)

    None

Additions to Chapter 6 of the 2.0 Specification (State and State Requests)

    Add the following to 6.1.13's description of 
    GetFramebufferAttachmentParameteriv:
    
    If pname is FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT, param will contain 
    the encoding of components of the specified attachment, one of LINEAR or 
    SRGB for linear or sRGB-encoded components, respectively. Only color buffer
    components may be sRGB-encoded. For the default framebuffer, color encoding
    is determined by the implementation. For framebuffer objects, components
    are sRGB-encoded if the internal format of a color attachment is SRGB_EXT, SRGB_ALPHA_EXT, or SRGB8_ALPHA8_EXT.
    
    Add the following to 6.2 State Tables
    
    FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING z2 GetFramebufferAttachementParameteriv
     - Encoding of components in the attached image  6.1.13

Additions to the OpenGL Shading Language specification

    None

Additions to the GLX Specification

    None

Errors

    Relaxation of INVALID_ENUM errors
    ---------------------------------

    TexImage2D, TexImage3DOES, and RenderBufferStorage now accept the new 
    tokens as listed in the "New Tokens" section.

New Implementation Dependent State

    None

Issues

    1) Do we require SRGB8_EXT be supported for RenderbufferStorage?
    
    No.  Some hardware would need to pad this out to RGBA and instead of adding
    that unknown for application  developers we will simply not support that
    format in this extension.
    
    2) Should the SLUMINANCE* family be supported?
     
    No.  Luminance is a rarely used format so we won't support it here.
    
    3) Should we allow the SRGB_*_S3TC_DXT* or any of the other COMPRESSED
    formats if the implementation supports any of those formats?
    
    No since all hardware doesn't support this.  It can be added as a separate
    extension if needed.
    
    4) What is the expectation for mipmap generation on SRGB textures?  Issue
    24 from EXT_texture_sRGB gives two possible ways, will we leave it 
    similarly undefined, or is this not intended to be supported at all?
    
    No.  This in not likely to be used much so for simplicity let's not require
    it.  This will generate an INVALID_OPERATION error.

Revision History
  #06    9/14/2011    Maurice Ribble     Removed compressed formats and
                                          disallowed generateMipmaps
  #05    9/12/2011    Maurice Ribble     Updated issues and added 
                                          FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
  #04    8/18/2011    Maurice Ribble     Fixes and issues from Daniel Koch.
  #03    7/21/2011    Maurice Ribble     Language cleanup suggested by Jon 
                                         Leech and Mark Callow.
  #02    7/20/2011    Maurice Ribble     Minor updates.
  #01    3/17/2011    Maurice Ribble     First draft.