1Name 2 3 EXT_sRGB 4 5Name Strings 6 7 GL_EXT_sRGB 8 9Contributors 10 11 Maurice Ribble 12 Tero Aurto 13 Jon Leech 14 Mark Callow 15 Daniel Koch 16 17 Parts of this extension are copied from ARB_framebuffer_sRGB. 18 Parts of this extension are copied from EXT_texture_sRGB. 19 20Contact 21 22 Maurice Ribble, Qualcomm (mribble 'at' qualcomm.com) 23 24Status 25 26 Not complete. 27 28Version 29 30 Date: Sept 14, 2011 31 32Number 33 34 OpenGL ES Extension #105 35 36Dependencies 37 38 This requires OpenGL ES 1.0 or greater. This extension is written based on 39 the wording of the OpenGL ES 2.0 specification. 40 41 This extension requires support for OES_rgb8_rgba8 or equivalent 42 functionality. 43 44 If OES_texture_3D is not supported then the parts of this extension for 3d 45 textures should be ignored. 46 47 If this is being used with ES 1.x then you need to support 48 OES_framebuffer_object for the framebuffer object related features in this 49 extension. 50 51Overview 52 53 The sRGB color space is based on typical (non-linear) response of the human 54 eye. It has been standardized by the International Electrotechnical 55 Commission (IEC) as IEC 61966-2-1. The transfer function of sRGB roughly 56 corresponds to a power function with a gamma of 2.2. 57 58 FRAMEBUFFERS 59 60 OpenGL assumes framebuffer color components are stored in a linear color 61 space. In particular, framebuffer blending is a linear operation. 62 63 This extension adds a framebuffer capability for sRGB framebuffer update 64 and blending. When blending is disabled but the new sRGB updated mode is 65 enabled (assume the framebuffer supports the capability), high-precision 66 linear color component values for red, green, and blue generated by 67 fragment coloring are encoded for sRGB prior to being written into the 68 framebuffer. When blending is enabled along with the new sRGB update mode, 69 red, green, and blue framebuffer color components are treated as sRGB 70 values that are converted to linear color values, blended with the high- 71 precision color values generated by fragment coloring, and then the blend 72 result is encoded for sRGB just prior to being written into the 73 framebuffer. 74 75 TEXTURES 76 77 Conventional texture formats assume a linear color space. So for a 78 conventional internal texture format such as GL_RGB8, the 256 discrete 79 values for each 8-bit color component map linearly and uniformly to the 80 [0,1] range. 81 82New Procedures and Functions 83 84 None 85 86New Tokens 87 88 Accepted by the <format> and <internalformat> parameter of TexImage2D, and 89 TexImage3DOES. These are also accepted by <format> parameter of 90 TexSubImage2D and TexSubImage3DOES: 91 92 SRGB_EXT 0x8C40 93 SRGB_ALPHA_EXT 0x8C42 94 95 Accepted by the <internalformat> parameter of RenderbufferStorage: 96 SRGB8_ALPHA8_EXT 0x8C43 97 98 Accepted by the <pname> parameter of GetFramebufferAttachmentParameteriv: 99 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT 0x8210 100 101Additions to Chapter 3 of the 2.0 Specification (Rasterization) 102 103Modify Section 3.7.1, Texture Image Specification: 104 105 Add 2 new rows to Table 3.3 106 107 SRGB_EXT R, G, B Color 108 SRGB_ALPHA_EXT R, G, B, A Color 109 110 Add 2 new rows to Table 3.4 111 112 SRGB_EXT UNSIGNED_BYTE 3 113 SRGB_ALPHA_EXT UNSIGNED_BYTE 4 114 115Modify Section 3.7.11: Mipmap Generation 116 117 Add the following sentence to the end of this section: 118 119 If the format of a texture is sRGB, he error INVALID_OPERATION is 120 generated. 121 122Add Section 3.7.14, sRGB Texture Color Conversion 123 124 If the currently bound texture's internal format is one of SRGB_EXT or 125 SRGB_ALPHA_EXT the red, green, and blue components are converted from an 126 sRGB color space to a linear color space as part of filtering described in 127 sections 3.7.7 and 3.7.8. Any alpha component is left unchanged. Ideally, 128 implementations should perform this color conversion on each sample prior 129 to filtering but implementations are allowed to perform this conversion 130 after filtering (though this post-filtering approach is inferior to 131 converting from sRGB prior to filtering). 132 133 The conversion from an sRGB encoded component, cs, to a linear component, 134 cl, is as follows. 135 136 { cs / 12.92, cs <= 0.04045 137 cl = { 138 { ((cs + 0.055)/1.055)^2.4, cs > 0.04045 139 140 Assume cs is the sRGB component in the range [0,1]." 141 142Additions to Chapter 4 of the Specification 143 144 DELETE the following sentence from section 4.1.6 (Blending) because it is 145 moved to the new "sRGB Conversion" section: 146 147 Each of these floating-point values is clamped to [0,1] and converted back 148 to a fixed-point value in the manner described in section 2.1.2. 149 150 Replace the following sentence: 151 152 Destination (framebuffer) components are taken to be fixed-point values 153 represented according to the scheme in section 2.1.2 (Final Color 154 Processing), as are source (fragment) components. 155 156 with the following sentences: 157 158 Destination (framebuffer) components are taken to be fixed-point values 159 represented according to the scheme in section 2.1.2 (Final Color 160 Processing). The R G, and B destination color values (after conversion 161 from fixed-point to floating-point) are considered to be encoded for the 162 sRGB color space and hence need to be linearized prior to their use in 163 blending. Each R, G, and B component is linearized by some approximation 164 of the following: 165 166 { cs / 12.92, cs <= 0.04045 167 cl = { 168 { ((cs + 0.055)/1.055)^2.4, cs > 0.04045 169 170 where cs is the component value prior to linearization and cl is the 171 result. 172 173 If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the 174 framebuffer attachment corresponding to the destination buffer is SRGB, the 175 R, G, and B destination color values (after conversion from fixedpoint to 176 floating-point) are considered to be encoded for the sRGB color space and 177 hence must be linearized prior to their use in blending. Each R, G, and B 178 component is converted in the same fashion described for sRGB texture 179 components as described below. 180 181 If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT is not SRGB, no 182 linearization is performed. 183 184 The resulting linearized R, G, and B and unmodified A values are 185 recombined as the destination color used in blending computations. 186 187 ADD new section 4.1.X "sRGB Conversion". With this new section added, 188 understand the "next operation" referred to in the section 4.1.6 189 (Blending) to now be "sRGB Conversion" (instead of "Dithering"). 190 191 "If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the 192 framebuffer attachment corresponding to the destination buffer is SRGB, the 193 R, G, and B values after blending are converted into the non-linear sRGB 194 color space by computing: 195 196 { 0.0, cl <= 0 197 { 12.92 * c, 0 < cl < 0.0031308 198 cs = { 1.055 * cl^0.41666 - 0.055, 0.0031308 <= cl < 1 199 { 1.0, cl >= 1 200 201 where cl is the R, G, or B element and cs is the result (effectively 202 converted into an sRGB color space). 203 204 The resulting cs values for R, G, and B and the unmodified A form a new 205 RGBA color value. If the color buffer is fixed-point, the components of 206 this RGBA color value are clamped to [0,1] and then converted to a fixed- 207 point value. The resulting four values are sent to the subsequent 208 dithering operation." 209 210 The following should be added to table 4.5 Renderbuffer Image formats: 211 SRGB8_ALPHA8_EXT color_renderable 8 8 8 8 - - 212 213Additions to Chapter 5 of the 2.0 Specification (Special Functions) 214 215 None 216 217Additions to Chapter 6 of the 2.0 Specification (State and State Requests) 218 219 Add the following to 6.1.13's description of 220 GetFramebufferAttachmentParameteriv: 221 222 If pname is FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT, param will contain 223 the encoding of components of the specified attachment, one of LINEAR or 224 SRGB for linear or sRGB-encoded components, respectively. Only color buffer 225 components may be sRGB-encoded. For the default framebuffer, color encoding 226 is determined by the implementation. For framebuffer objects, components 227 are sRGB-encoded if the internal format of a color attachment is SRGB_EXT, SRGB_ALPHA_EXT, or SRGB8_ALPHA8_EXT. 228 229 Add the following to 6.2 State Tables 230 231 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING z2 GetFramebufferAttachementParameteriv 232 - Encoding of components in the attached image 6.1.13 233 234Additions to the OpenGL Shading Language specification 235 236 None 237 238Additions to the GLX Specification 239 240 None 241 242Errors 243 244 Relaxation of INVALID_ENUM errors 245 --------------------------------- 246 247 TexImage2D, TexImage3DOES, and RenderBufferStorage now accept the new 248 tokens as listed in the "New Tokens" section. 249 250New Implementation Dependent State 251 252 None 253 254Issues 255 256 1) Do we require SRGB8_EXT be supported for RenderbufferStorage? 257 258 No. Some hardware would need to pad this out to RGBA and instead of adding 259 that unknown for application developers we will simply not support that 260 format in this extension. 261 262 2) Should the SLUMINANCE* family be supported? 263 264 No. Luminance is a rarely used format so we won't support it here. 265 266 3) Should we allow the SRGB_*_S3TC_DXT* or any of the other COMPRESSED 267 formats if the implementation supports any of those formats? 268 269 No since all hardware doesn't support this. It can be added as a separate 270 extension if needed. 271 272 4) What is the expectation for mipmap generation on SRGB textures? Issue 273 24 from EXT_texture_sRGB gives two possible ways, will we leave it 274 similarly undefined, or is this not intended to be supported at all? 275 276 No. This in not likely to be used much so for simplicity let's not require 277 it. This will generate an INVALID_OPERATION error. 278 279Revision History 280 #06 9/14/2011 Maurice Ribble Removed compressed formats and 281 disallowed generateMipmaps 282 #05 9/12/2011 Maurice Ribble Updated issues and added 283 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING 284 #04 8/18/2011 Maurice Ribble Fixes and issues from Daniel Koch. 285 #03 7/21/2011 Maurice Ribble Language cleanup suggested by Jon 286 Leech and Mark Callow. 287 #02 7/20/2011 Maurice Ribble Minor updates. 288 #01 3/17/2011 Maurice Ribble First draft. 289