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