1Name 2 3 ARB_framebuffer_sRGB 4 5Name Strings 6 7 GL_ARB_framebuffer_sRGB 8 GLX_ARB_framebuffer_sRGB 9 WGL_ARB_framebuffer_sRGB 10 11Contributors 12 13 Herb (Charles) Kuta, Quantum3D 14 Alain Bouchard, Matrox 15 Brian Paul, Tungsten Graphics 16 Daniel Vogel, Epic Games 17 Eric Werness, NVIDIA 18 Kiril Vidimce, Pixar 19 Mark J. Kilgard, NVIDIA 20 Pat Brown, NVIDIA 21 Yanjun Zhang, S3 Graphics 22 Jeremy Sandmel, Apple 23 Jon Leech 24 25Contact 26 27 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 28 29Notice 30 31 Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at 32 http://www.khronos.org/registry/speccopyright.html 33 34Status 35 36 Approved by the ARB on July 11, 2008 37 38Version 39 40 Date: August 11, 2008 41 Revision: 1.2 42 43Number 44 45 ARB Extension #46 46 47Dependencies 48 49 OpenGL 1.1 is required 50 51 This extension is written against the OpenGL 2.0 (September 7, 52 2004) specification. 53 54 WGL_EXT_extensions_string is required for WGL support. 55 56 WGL_EXT_pixel_format is required for WGL support. 57 58 ARB_color_buffer_float interacts with this extension. 59 60 ARB_framebuffer_object is required. 61 62 EXT_texture_sRGB interacts with this extension. 63 64 ARB_draw_buffers interacts with this extension. 65 66Overview 67 68 Conventionally, OpenGL assumes framebuffer color components are stored 69 in a linear color space. In particular, framebuffer blending is a 70 linear operation. 71 72 The sRGB color space is based on typical (non-linear) monitor 73 characteristics expected in a dimly lit office. It has been 74 standardized by the International Electrotechnical Commission (IEC) 75 as IEC 61966-2-1. The sRGB color space roughly corresponds to 2.2 76 gamma correction. 77 78 This extension adds a framebuffer capability for sRGB framebuffer 79 update and blending. When blending is disabled but the new sRGB 80 updated mode is enabled (assume the framebuffer supports the 81 capability), high-precision linear color component values for red, 82 green, and blue generated by fragment coloring are encoded for sRGB 83 prior to being written into the framebuffer. When blending is enabled 84 along with the new sRGB update mode, red, green, and blue framebuffer 85 color components are treated as sRGB values that are converted to 86 linear color values, blended with the high-precision color values 87 generated by fragment coloring, and then the blend result is encoded 88 for sRGB just prior to being written into the framebuffer. 89 90 The primary motivation for this extension is that it allows OpenGL 91 applications to render into a framebuffer that is scanned to a monitor 92 configured to assume framebuffer color values are sRGB encoded. 93 This assumption is roughly true of most PC monitors with default 94 gamma correction. This allows applications to achieve faithful 95 color reproduction for OpenGL rendering without adjusting the 96 monitor's gamma correction. 97 98New Procedures and Functions 99 100 None 101 102New Tokens 103 104 Accepted by the <attribList> parameter of glXChooseVisual, and by 105 the <attrib> parameter of glXGetConfig: 106 107 GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB 0x20B2 108 109 Accepted by the <piAttributes> parameter of 110 wglGetPixelFormatAttribivEXT, wglGetPixelFormatAttribfvEXT, and 111 the <piAttribIList> and <pfAttribIList> of wglChoosePixelFormatEXT: 112 113 WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB 0x20A9 114 115 Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, 116 and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 117 and GetDoublev: 118 119 FRAMEBUFFER_SRGB 0x8DB9 120 121Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation) 122 123 None 124 125Additions to Chapter 3 of the 2.0 Specification (Rasterization) 126 127 None 128 129Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations 130and the Frame Buffer) 131 132 DELETE the following sentence from section 4.1.8 (Blending) because 133 it is moved to the new "sRGB Conversion" section: 134 135 "Each of these floating-point values is clamped to [0,1] and 136 converted back to a fixed-point value in the manner described in 137 section 2.14.9." 138 139 If ARB_color_buffer_float is supported, the following paragraph 140 is modified to eliminate the fixed-point clamping and conversion 141 because this behavior is moved to the new "sRGB Conversion" section. 142 143 "If the color buffer is fixed-point, the components of the source 144 and destination values and blend factors are clamped to [0, 1] 145 prior to evaluating the blend equation, the components of the 146 blending result are clamped to [0,1] and converted to fixed- 147 point values in the manner described in section 2.14.9. If the 148 color buffer is floating-point, no clamping occurs. The 149 resulting four values are sent to the next operation." 150 151 The modified ARB_color_buffer_float paragraph should read: 152 153 "If the color buffer is fixed-point, the components of the source 154 and destination values and blend factors are clamped to [0, 1] 155 prior to evaluating the blend equation. If the color buffer is 156 floating-point, no clamping occurs. The resulting four values are 157 sent to the next operation." 158 159 Replace the following sentence: 160 161 "Destination (framebuffer) components are taken to be fixed-point 162 values represented according to the scheme in section 2.14.9 (Final 163 Color Processing), as are source (fragment) components." 164 165 with the following sentences: 166 167 "Destination (framebuffer) components are taken to be fixed-point 168 values represented according to the scheme in section 2.14.9 (Final 169 Color Processing). If FRAMEBUFFER_SRGB is enabled and the value 170 of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer 171 attachment corresponding to the destination buffer is SRGB (see 172 section 6.1.3), the R 173 G, and B destination color values (after conversion from fixed-point 174 to floating-point) are considered to be encoded for the sRGB color 175 space and hence need to be linearized prior to their use in blending. 176 Each R, G, and B component is linearized by some approximation of 177 the following: 178 179 { cs / 12.92, cs <= 0.04045 180 cl = { 181 { ((cs + 0.055)/1.055)^2.4, cs > 0.04045 182 183 where cs is the component value prior to linearization and cl is 184 the result. Otherwise if FRAMEBUFFER_SRGB is disabled, or the 185 value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, no 186 linearization is performed. 187 188 The resulting linearized R, G, and B and unmodified A values are 189 recombined as the destination color used in blending computations. 190 191 192 ADD new section 4.1.X "sRGB Conversion" after section 4.1.8 (Blending) 193 and before section 4.1.9 (Dithering). With this new section added, 194 understand the "next operation" referred to in the section 4.1.8 195 (Blending) to now be "sRGB Conversion" (instead of "Dithering"). 196 197 "If FRAMEBUFFER_SRGB is enabled and the value of 198 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer attachment 199 corresponding to the destination buffer is SRGB (see section 6.1.3), 200 the R, G, and B values after blending are converted into the non-linear 201 sRGB color space by some approximation of the following: 202 203 { 0.0, 0 <= cl 204 { 12.92 * c, 0 < cl < 0.0031308 205 cs = { 1.055 * cl^0.41666 - 0.055, 0.0031308 <= cl < 1 206 { 1.0, cl >= 1 207 208 where cl is the R, G, or B element and cs is the result 209 (effectively converted into an sRGB color space). 210 211 If FRAMEBUFFER_SRGB is disabled or the value of 212 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, then 213 214 cs = cl 215 216 The resulting cs values for R, G, and B and the unmodified A form a 217 new RGBA color value. If the color 218 buffer is fixed-point, the components of this RGBA color value are 219 clamped to [0,1] and then converted to a fixed-point value in the 220 manner described in section 2.14.9. The resulting four values are 221 sent to the subsequent dithering operation." 222 223Additions to Chapter 5 of the 2.0 Specification (Special Functions) 224 225 None 226 227Additions to Chapter 6 of the 2.0 Specification (State and State Requests) 228 229 None 230 231Additions to the OpenGL Shading Language specification 232 233 None 234 235Additions to the GLX Specification 236 237 None 238 239Dependencies on ARB_color_buffer_float 240 241 If ARB_color_buffer_float is not supported, ignore the edits to 242 ARB_color_buffer_float language. 243 244Dependencies on EXT_texture_sRGB and ARB_framebuffer_object 245 246 If EXT_texture_sRGB and ARB_framebuffer_object are both supported, the 247 implementation should set the value of 248 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING to LINEAR when 249 rendering to a color texture that is not one of the EXT_texture_sRGB 250 introduced internal formats. An implementation can determine whether 251 or not it will set the value of 252 FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING to SRGB for the 253 EXT_texture_sRGB introduced internal formats. Implementations are 254 encouraged to allow sRGB update and blending when rendering to sRGB 255 textures using ARB_framebuffer_object but this is not required. 256 In any case, FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING should indicate 257 whether or not sRGB update and blending is supported. 258 259Dependencies on ARB_draw_buffers, EXT_texture_sRGB, and ARB_framebuffer_object 260 261 If ARB_draw_buffers, EXT_texture_sRGB, and ARB_framebuffer_object 262 are supported and an application attempts to render to a set of 263 color buffers where some but not all of the color buffers are SRGB 264 capable, sRGB update and blending only apply to the color buffers 265 that are actually sRGB-capable. 266 267GLX Protocol 268 269 None. 270 271Errors 272 273 Relaxation of INVALID_ENUM errors 274 --------------------------------- 275 276 Enable, Disable, IsEnabled, GetBooleanv, GetIntegerv, GetFloatv, 277 and GetDoublev now accept FRAMEBUFFER_SRGB as allowed in the "New 278 Tokens" section. 279 280New State 281 282 Add to table 6.20 (Pixel Operations) 283 284 Get Value Type Get Command Initial Value Description Sec. Attribute 285 ---------------- ---- ----------- ------------- --------------- ----- ------------------- 286 FRAMEBUFFER_SRGB B IsEnabled False sRGB update and 4.1.X color-buffer/enable 287 blending enable 288 289New Implementation Dependent State 290 291 None 292 293Issues 294 295 1) What should this extension be called? 296 297 RESOLVED: ARB_framebuffer_sRGB. 298 299 The "ARB_framebuffer" part indicates the extension is in 300 the framebuffer domain and "sRGB" indicates the extension is 301 adding a set of sRGB formats. This mimics the naming of the 302 EXT_texture_sRGB extension that adds sRGB texture formats. 303 304 The mixed-case spelling of sRGB is the established usage so 305 "_sRGB" is preferred to "_srgb". The "s" stands for standard 306 (color space). 307 308 For token names, we use "SRGB" since token names are uniformly 309 capitalized. 310 311 2) Should alpha be sRGB encoded? 312 313 RESOLVED: No. Alpha remains linear. 314 315 A rationale for this resolution is found in Alvy Ray's "Should 316 Alpha Be Nonlinear If RGB Is?" Tech Memo 17 (December 14, 1998). 317 See: ftp://ftp.alvyray.com/Acrobat/17_Nonln.pdf 318 319 3) Should the ability to support sRGB framebuffer update and blending 320 be an attribute of the framebuffer? 321 322 RESOLVED: Yes. It should be a capability of some pixel formats 323 (mostly likely just RGB8 and RGBA8) that says sRGB blending can 324 be enabled. 325 326 This allows an implementation to simply mark the existing RGB8 327 and RGBA8 pixel formats as supporting sRGB blending and then 328 just provide the functionality for sRGB update and blending for 329 such formats. 330 331 sRGB support for floating-point formats makes little sense 332 (because floating-point already provide a non-linear distribution 333 of precision and typically have considerably more precision 334 than 8-bit fixed-point framebuffer components allow) and would 335 be expensive to support. 336 337 Requiring sRGB support for all fixed-point buffers means that 338 support for 16-bit components or very small 5-bit or 6-bit 339 components would require special sRGB conversion hardware. 340 Typically sRGB is well-suited for 8-bit fixed-point components 341 so we do not want this extension to require expensive tables 342 for other component sizes that are unlikely to ever be used. 343 Implementations could support sRGB conversion for any color 344 framebuffer format but implementations are not required to 345 (honestly nor are implementations like to support sRGB on anything 346 but 8-bit fixed-point color formats). 347 348 4) Should there be an enable for sRGB update and blending? 349 350 RESOLVED: Yes, and it is disabled by default. The enable only 351 applies if a destination buffer's pixel format is capable 352 of sRGB update and blending. Otherwise, the enable is silently 353 ignored (similar to how the multisample enables are ignored when 354 the pixel format lacks multisample supports). 355 356 5) How is sRGB blending done? 357 358 RESOLVED: Blending is a linear operation so should be performed 359 on values in linear spaces. sRGB-encoded values are in a 360 non-linear space so sRGB blending should convert sRGB-encoded 361 values from the framebuffer to linear values, blend, and then 362 sRGB-encode the result to store it in the framebuffer. 363 364 The destination color RGB components are each converted 365 from sRGB to a linear value. Blending is then performed. 366 The source color and constant color are simply assumed to be 367 treated as linear color components. Then the result of blending 368 is converted to an sRGB encoding and stored in the framebuffer. 369 370 6) What happens if GL_FRAMEBUFFER_SRGB is enabled (and 371 GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is GL_SRGB), but 372 GL_BLEND is not enabled? 373 374 RESOLVED: The color result from fragment coloring (the source 375 color) is converted to an sRGB encoding and stored in the 376 framebuffer. 377 378 7) How are multiple render targets handled? 379 380 RESOLVED: Render targets that are not sRGB-capable ignore the 381 state of the GL_FRAMEBUFFER_SRGB enable for sRGB update and 382 blending. Note that unlike EXT_framebuffer_sRGB, the 383 sRGB-capable query may be performed on a per-color-attachment 384 basis. 385 386 8) Should sRGB framebuffer support affect the pixel path? 387 388 RESOLVED: No. 389 390 sRGB conversion only applies to color reads for blending and 391 color writes. Color reads for glReadPixels, glCopyPixels, 392 or glAccum have no sRGB conversion applied. 393 394 For pixel path operations, an application could use pixel maps 395 or color tables to perform an sRGB-to-linear conversion with 396 these lookup tables. 397 398 9) Can luminance (single color component) framebuffer formats 399 support sRGB blending? 400 401 RESOLVED: Yes, if an implementation chooses to advertise such 402 a format and set the sRGB attribute for the format too. 403 404 Implementations are not obliged to provide such formats. 405 406 10) Should all component sizes be supported for sRGB components or 407 just 8-bit? 408 409 RESOLVED: This is at the implementation's discretion since 410 the implementation decides what pixel formats such support sRGB 411 update and blending. 412 413 It likely implementations will only provide sRGB-capable 414 framebuffer configurations for configurations with 8-bit 415 components. 416 417 11) What must be specified as far as how do you convert to and from 418 sRGB and linear RGB color spaces? 419 420 RESOLVED: The specification language needs to only supply the 421 linear RGB to sRGB conversion (see section 4.9.X above). 422 423 The sRGB to linear RGB conversion is documented in the 424 EXT_texture_sRGB specification. 425 426 For completeness, the accepted linear RGB to sRGB conversion 427 (the inverse of the function specified in section 3.8.x) is as 428 follows: 429 430 Given a linear RGB component, cl, convert it to an sRGB component, 431 cs, in the range [0,1], with this pseudo-code: 432 433 if (isnan(cl)) { 434 /* Map IEEE-754 Not-a-number to zero. */ 435 cs = 0.0; 436 } else if (cl > 1.0) { 437 cs = 1.0; 438 } else if (cl < 0.0) { 439 cs = 0.0; 440 } else if (cl < 0.0031308) { 441 cs = 12.92 * cl; 442 } else { 443 cs = 1.055 * pow(cl, 0.41666) - 0.055; 444 } 445 446 The NaN behavior in the pseudo-code is recommended but not 447 specified in the actual specification language. 448 449 sRGB components are typically stored as unsigned 8-bit 450 fixed-point values. If cs is computed with the above 451 pseudo-code, cs can be converted to a [0,255] integer with this 452 formula: 453 454 csi = floor(255.0 * cs + 0.5) 455 456 12) Does this extension guarantee images rendered with sRGB textures 457 will "look good" when output to a device supporting an sRGB 458 color space? 459 460 RESOLVED: No. 461 462 Whether the displayed framebuffer is displayed to a monitor that 463 faithfully reproduces the sRGB color space is beyond the scope 464 of this extension. This involves the gamma correction and color 465 calibration of the physical display device. 466 467 13) How does this extension interact with ARB_framebuffer_object? 468 469 RESOLVED: ARB_framebuffer_object is required to provide the 470 GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING query used to determine 471 if the color texture image is capable of sRGB rendering. 472 473 This query should be LINEAR for all texture internal formats 474 other than sRGB internal formats such as those introduced by 475 EXT_texture_sRGB. Implementations of this extension must be able 476 to support sRGB update and blending of sRGB textures. 477 478 14) How is the constant blend color handled for sRGB framebuffers? 479 480 RESOLVED: The constant blend color is specified as four 481 floating-point values. Given that the texture border color can 482 be specified at such high precision, it is always treated as a 483 linear RGBA value. 484 485 15) How does glCopyTex[Sub]Image work with sRGB? Suppose we're 486 rendering to a floating point pbuffer or framebuffer object and 487 do CopyTexImage. Are the linear framebuffer values converted 488 to sRGB during the copy? 489 490 RESOLVED: No, linear framebuffer values will NOT be automatically 491 converted to the sRGB encoding during the copy. If such a 492 conversion is desired, as explained in issue 12, the red, green, 493 and blue pixel map functionality can be used to implement a 494 linear-to-sRGB encoding translation. 495 496 16) Should this extension explicitly specify the particular 497 sRGB-to-linear and linear-to-sRGB conversions it uses? 498 499 RESOLVED: The conversions are explicitly specified but 500 allowance for approximations is provided. The expectation is 501 that the implementation is likely to use a table to implement the 502 conversions the conversion is necessarily then an approximation. 503 504 17) How does this extension interact with multisampling? 505 506 RESOLVED: There are no explicit interactions. However, arguably 507 if the color samples for multisampling are sRGB encoded, the 508 samples should be linearized before being "resolved" for display 509 and then recoverted to sRGB if the output device expects sRGB 510 encoded color components. 511 512 This is really a video scan-out issue and beyond the scope 513 of this extension which is focused on the rendering issues. 514 However some implementation advice is provided: 515 516 The implementation sufficiently aware of the gamma correction 517 configured for the display device could decide to perform an 518 sRGB-correct multisample resolve. Whether this occurs or not 519 could be determined by a control panel setting or inferred by 520 the application's use of this extension. 521 522 18) Why is the sRGB framebuffer GL_FRAMEBUFFER_SRGB enable 523 disabled by default? 524 525 RESOLVED: This extension could have a boolean 526 sRGB-versus-non-sRGB pixel format configuration mode that 527 determined whether or not sRGB framebuffer update and blending 528 occurs. The problem with this approach is 1) it creates may more 529 pixel formation configurations because sRGB and non-sRGB versions 530 of lots of existing configurations must be advertised, and 2) 531 applicaitons unaware of sRGB might unknowingly select an sRGB 532 configuration and then generate over-bright rendering. 533 534 It seems more appropriate to have a capability for sRGB 535 framebuffer update and blending that is disabled by default. 536 This allows existing RGB8 and RGBA8 framebuffer configurations 537 to be marked as sRGB capable (so no additional configurations 538 need be enumerated). Applications that desire sRGB rendering 539 should identify an sRGB-capable framebuffer configuration and 540 then enable sRGB rendering. 541 542 This is different from how EXT_texture_sRGB handles sRGB support 543 for texture formats. In the EXT_texture_sRGB extension, textures 544 are either sRGB or non-sRGB and there is no texture parameter 545 to switch textures between the two modes. This makes sense for 546 EXT_texture_sRGB because it allows implementations to fake sRGB 547 textures with higher-precision linear textures that simply convert 548 sRGB-encoded texels to sufficiently precise linear RGB values. 549 550 Texture formats also don't have the problem enumerated pixel 551 format descriptions have where a naive application could stumble 552 upon an sRGB-capable pixel format. sRGB textures require 553 explicit use of one of the new EXT_texture_sRGB-introduced 554 internal formats. 555 556 19) How does sRGB and this extension interact with digital video 557 output standards, in particular DVI? 558 559 RESOLVED: The DVI 1.0 specification recommends "as a default 560 position that digital moniotrs of all types support a color 561 transfer function similar to analog CRT monitors (gamma=2.2) 562 which makes up the majority of the compute display market." This 563 means DVI output devices should benefit from blending in the 564 sRGB color space just like analog monitors. 565 566 20) Why don't the new tokens and entry points in this extension have 567 "ARB" suffixes like other ARB extensions? 568 569 RESOLVED: Unlike most ARB extensions, this is a strict subset of 570 functionality already approved in OpenGL 3.0. This extension 571 exists only to support that functionality on older hardware that 572 cannot implement a full OpenGL 3.0 driver. Since there are no 573 possible behavior changes between the ARB extension and core 574 features, source code compatibility is improved by not using 575 suffixes on the extension. 576 577 This does not apply to the GLX and WGL elements of this 578 extension, since those elements are not part of a new core GLX 579 or WGL release yet. 580 581 21) Where's the specification language for the GLX and WGL pixel 582 format selection interface? 583 584 TO BE DONE. The {GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB pixel 585 format attributes are used to select default framebuffers which 586 are sRGB-capable in the fairly obvious way, but this language 587 was missing in the original EXT_framebuffer_sRGB and needs to be 588 added here. 589 590Revision History 591 592 Rev. Date Author Changes 593 ---- -------- -------- ------------------------------------- 594 1.2 08/11/08 jleech Use per-FBO-attachment state for 595 sRGB-capable queries, rather then the 596 EXT's single boolean query for the 597 entire framebuffer. 598 1.1 08/08/08 jleech Remove ARB suffixes. 599 1 10/21/06 barthold Added revision history 600 0.4 10/20/06 mjk Added issue 19 601 0.3 mjk Internal spec development. 602 603