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