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 and parameter of TexImage2D, and TexImage3DOES. These are also accepted by parameter of TexSubImage2D and TexSubImage3DOES: SRGB_EXT 0x8C40 SRGB_ALPHA_EXT 0x8C42 Accepted by the parameter of RenderbufferStorage: SRGB8_ALPHA8_EXT 0x8C43 Accepted by the 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.