EXT_sRGB

GL_EXT_sRGB

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.

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

Not complete.

Date: Sept 14, 2011

OpenGL ES Extension #105

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.

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.

None

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

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

Add the following sentence to the end of this section:

If the format of a texture is sRGB, he error INVALID_OPERATION is 
generated.

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

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

None

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

None

None

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

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

None

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.