1Name 2 3 EXT_framebuffer_sRGB 4 5Name Strings 6 7 GL_EXT_framebuffer_sRGB 8 GLX_EXT_framebuffer_sRGB 9 WGL_EXT_framebuffer_sRGB 10 11Contributors 12 13 Alex Eddy, Apple 14 Chris Niederauer, Apple 15 Herb (Charles) Kuta, Quantum3D 16 Jeremy Sandmel, Apple 17 Jesse Hall, NVIDIA 18 19 From the EXT_texture_sRGB specification... 20 21 Alain Bouchard, Matrox 22 Brian Paul, Tungsten Graphics 23 Daniel Vogel, Epic Games 24 Eric Werness, NVIDIA 25 Kiril Vidimce, Pixar 26 Mark J. Kilgard, NVIDIA 27 Pat Brown, NVIDIA 28 Yanjun Zhang, S3 Graphics 29 30Contact 31 32 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 33 34Status 35 36 Complete. 37 38Version 39 40 Date: September 17, 2010 41 Revision: 4 42 43Number 44 45 337 46 47Dependencies 48 49 OpenGL 1.1 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 EXT_framebuffer_object interacts with this extension. 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_EXT 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_EXT 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_EXT 0x8DB9 120 121 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 122 GetFloatv, and GetDoublev: 123 124 FRAMEBUFFER_SRGB_CAPABLE_EXT 0x8DBA 125 126Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation) 127 128 None 129 130Additions to Chapter 3 of the 2.0 Specification (Rasterization) 131 132 None 133 134Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations 135and the Frame Buffer) 136 137 -- Section 4.1.8 "Blending" 138 139 DELETE the following sentence from section 4.1.8 (Blending) because 140 it is moved to the new "sRGB Conversion" section: 141 142 "Each of these floating-point values is clamped to [0,1] and 143 converted back to a fixed-point value in the manner described in 144 section 2.14.9." 145 146 If ARB_color_buffer_float is supported, the following paragraph 147 is modified to eliminate the fixed-point clamping and conversion 148 because this behavior is moved to the new "sRGB Conversion" section. 149 150 "If the color buffer is fixed-point, the components of the source 151 and destination values and blend factors are clamped to [0, 1] 152 prior to evaluating the blend equation, the components of the 153 blending result are clamped to [0,1] and converted to fixed- 154 point values in the manner described in section 2.14.9. If the 155 color buffer is floating-point, no clamping occurs. The 156 resulting four values are sent to the next operation." 157 158 The modified ARB_color_buffer_float paragraph should read: 159 160 "If the color buffer is fixed-point, the components of the source 161 and destination values and blend factors are clamped to [0, 1] 162 prior to evaluating the blend equation. If the color buffer is 163 floating-point, no clamping occurs. The resulting four values are 164 sent to the next operation." 165 166 Replace the following sentence: 167 168 "Destination (framebuffer) components are taken to be fixed-point 169 values represented according to the scheme in section 2.14.9 (Final 170 Color Processing), as are source (fragment) components." 171 172 with the following sentences: 173 174 "Destination (framebuffer) components are taken to be fixed-point 175 values represented according to the scheme in section 2.14.9 (Final 176 Color Processing). If FRAMEBUFFER_SRGB_EXT is enabled and the boolean 177 FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true, the R, 178 G, and B destination color values (after conversion from fixed-point 179 to floating-point) are considered to be encoded for the sRGB color 180 space and hence need to be linearized prior to their use in blending. 181 Each R, G, and B component is linearized by some approximation of 182 the following: 183 184 { cs / 12.92, cs <= 0.04045 185 cl = { 186 { ((cs + 0.055)/1.055)^2.4, cs > 0.04045 187 188 where cs is the component value prior to linearization and cl is 189 the result. Otherwise if FRAMEBUFFER_SRGB_EXT is disabled, or the 190 drawable is not sRGB capable, or the value corresponds to the A 191 component, then cs = cl for such components. The corresponding cs 192 values for R, G, B, and A are recombined as the destination color 193 used subsequently by blending." 194 195 ADD new section 4.1.X "sRGB Conversion" after section 4.1.8 (Blending) 196 and before section 4.1.9 (Dithering). With this new section added, 197 understand the "next operation" referred to in the section 4.1.8 198 (Blending) to now be "sRGB Conversion" (instead of "Dithering"). 199 200 "If FRAMEBUFFER_SRGB_EXT is enabled and the boolean 201 FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true, the R, 202 G, and B values after blending are converted into the non-linear 203 sRGB color space by some approximation of the following: 204 205 { 0.0, 0 <= cl 206 { 12.92 * c, 0 < cl < 0.0031308 207 cs = { 1.055 * cl^0.41666 - 0.055, 0.0031308 <= cl < 1 208 { 1.0, cl >= 1 209 210 where cl is the R, G, or B element and cs is the result 211 (effectively converted into an sRGB color space). Otherwise if 212 FRAMEBUFFER_SRGB_EXT is disabled, or the drawable is not sRGB 213 capable, or the value corresponds to the A element, then cs = cl 214 for such elements. 215 216 The resulting cs values form a new RGBA color value. If the color 217 buffer is fixed-point, the components of this RGBA color value are 218 clamped to [0,1] and then converted to a fixed-point value in the 219 manner described in section 2.14.9. The resulting four values are 220 sent to the subsequent dithering operation." 221 222 -- Section 4.1.10 "Logical Operation" 223 224 Add this pargraph after the first paragraph in the section: 225 226 "Logical operation has no effect on an sRGB destination color buffer 227 (i.e., the boolean FRAMEBUFFER_SRGB_CAPABLE_EXT state for the 228 drawable is true) when FRAMEBUFFER_SRGB_EXT is enabled; however, 229 if the logical operation is enabled, blending is still disabled." 230 231 If ARB_color_buffer_float is supported, that specification's paragraph 232 (upon which the above paragraph is modeled) would be modified to 233 read: 234 235 "Logical operation has no effect on a floating-point destination 236 color buffer or sRGB destination color buffer (i.e., the boolean 237 FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true) when 238 FRAMEBUFFER_SRGB_EXT is enabled; however, if the logical operation 239 is enabled, blending is still disabled." 240 241 -- Section 4.2.3 "Clearing the Buffers" 242 243 Change the first full sentence after the ClearColor prototype to 244 read: 245 246 "Each of the specified components is clamped to [0,1]." 247 248 (removing the "converted to fixed-point..." phrase because this 249 technically happens prior to sRGB conversion and/or dithering during 250 a Clear rather than at the time of the ClearColor call.) 251 252 Change the first sentence in the second to last paragraph of the 253 section to read: 254 255 "When Clear is called, the only per-fragment operations that are 256 applied (if enabled) are the pixel ownership test, the scissor test, 257 sRGB conversion, and dithering. The resulting color value (possibly 258 sRGB converted and/or dithered) is converted to fixed-point according 259 to the rules of section 2.14.19." 260 261 -- Section 4.2.4 "The Accumulation Buffer" 262 263 Change the fifth sentence of the second pargraph (describing ACCUM) to read: 264 265 "Each component, considered as a fixed-point value in 266 [0,1] (see section 2.14.9) is converted to floating-point; 267 special rules apply if the color buffer is sRGB-capable. 268 Specifically, if FRAMEBUFFER_SRGB_EXT is enabled and the boolean 269 FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true, the R, G, 270 and B destination color values (after conversion from fixed-point to 271 floating-point) are considered to be encoded for the sRGB color space 272 and hence need to be linearized prior to their use for accumulation. 273 This conversion uses the formula to compute cl from cs is section 274 4.1.8." 275 276 Change the second to last sentence of the fourth paragraph (describing 277 RETURN) to read: 278 279 "The resulting color value is placed in the buffers currently 280 enabled for color writing as if it were a fragment produced from 281 rasterization, except that the only per-fragment operations that are 282 applied (if enabled) are the pixel ownership test, the scissor test 283 (section 4.1.2), sRGB conversion (section 4.2.X), and dithering 284 (section 4.1.9)." 285 286Additions to Chapter 5 of the 2.0 Specification (Special Functions) 287 288 None 289 290Additions to Chapter 6 of the 2.0 Specification (State and State Requests) 291 292 None 293 294Additions to the OpenGL Shading Language specification 295 296 None 297 298Additions to the GLX Specification 299 300 None 301 302Dependencies on ARB_color_buffer_float 303 304 If ARB_color_buffer_float is not supported, ignore the edits to 305 ARB_color_buffer_float language. 306 307Dependencies on EXT_texture_sRGB and EXT_framebuffer_object 308 309 If EXT_texture_sRGB and EXT_framebuffer_object are both supported, the 310 implementation should set FRAMEBUFFER_SRGB_CAPABLE_EXT to false when 311 rendering to a color texture that is not one of the EXT_texture_sRGB 312 introduced internal formats. An implementation can determine whether 313 or not it will set FRAMEBUFFER_SRGB_CAPABLE_EXT to true for the 314 EXT_texture_sRGB introduced internal formats. Implementations are 315 encouraged to allow sRGB update and blending when rendering to sRGB 316 textures using EXT_framebuffer_object but this is not required. 317 In any case, FRAMEBUFFER_SRGB_CAPABLE_EXT should indicate whether 318 or not sRGB update and blending is supported. 319 320Dependencies on ARB_draw_buffers, EXT_texture_sRGB, and EXT_framebuffer_object 321 322 323 If ARB_draw_buffers, EXT_texture_sRGB, and EXT_framebuffer_object 324 are supported and an application attempts to render to a set 325 of color buffers where some but not all of the color buffers 326 are FRAMEBUFFER_SRGB_CAPABLE_EXT individually, the query of 327 FRAMEBUFFER_SRGB_CAPABLE_EXT should return true. 328 329 However sRGB update and blending only apply to the color buffers 330 that are actually sRGB-capable. 331 332GLX Protocol 333 334 None. 335 336Errors 337 338 Relaxation of INVALID_ENUM errors 339 --------------------------------- 340 341 Enable, Disable, IsEnabled, GetBooleanv, GetIntegerv, GetFloatv, 342 and GetDoublev now accept the new token as allowed in the "New 343 Tokens" section. 344 345New State 346 347 Add to table 6.20 (Pixel Operations) 348 349 Get Value Type Get Command Initial Value Description Sec. Attribute 350 -------------------- ---- ----------- ------------- --------------- ----- ------------------- 351 FRAMEBUFFER_SRGB_EXT B IsEnabled False sRGB update and 4.1.X color-buffer/enable 352 blending enable 353 354 Add to table 6.33 (Implementation Dependent Values) 355 356 Get Value Type Get Command Initial Value Description Sec. Attribute 357 ---------------------------- ---- ----------- ------------- -------------------- ----- --------- 358 FRAMEBUFFER_SRGB_CAPABLE_EXT B GetIntegerv - true if drawable 4.1.X - 359 supports sRGB update 360 and blending 361 362New Implementation Dependent State 363 364 None 365 366Issues 367 368 1) What should this extension be called? 369 370 RESOLVED: EXT_framebuffer_sRGB. 371 372 The "EXT_framebuffer" part indicates the extension is in 373 the framebuffer domain and "sRGB" indicates the extension is 374 adding a set of sRGB formats. This mimics the naming of the 375 EXT_texture_sRGB extension that adds sRGB texture formats. 376 377 The mixed-case spelling of sRGB is the established usage so 378 "_sRGB" is preferred to "_srgb". The "s" stands for standard 379 (color space). 380 381 For token names, we use "SRGB" since token names are uniformly 382 capitalized. 383 384 2) Should alpha be sRGB encoded? 385 386 RESOLVED: No. Alpha remains linear. 387 388 A rationale for this resolution is found in Alvy Ray's "Should 389 Alpha Be Nonlinear If RGB Is?" Tech Memo 17 (December 14, 1998). 390 See: ftp://ftp.alvyray.com/Acrobat/17_Nonln.pdf 391 392 3) Should the ability to support sRGB framebuffer update and blending 393 be an attribute of the framebuffer? 394 395 RESOLVED: Yes. It should be a capability of some pixel formats 396 (mostly likely just RGB8 and RGBA8) that says sRGB blending can 397 be enabled. 398 399 This allows an implementation to simply mark the existing RGB8 400 and RGBA8 pixel formats as supporting sRGB blending and then 401 just provide the functionality for sRGB update and blending for 402 such formats. 403 404 sRGB support for floating-point formats makes little sense 405 (because floating-point already provide a non-linear distribution 406 of precision and typically have considerably more precision 407 than 8-bit fixed-point framebuffer components allow) and would 408 be expensive to support. 409 410 Requiring sRGB support for all fixed-point buffers means that 411 support for 16-bit components or very small 5-bit or 6-bit 412 components would require special sRGB conversion hardware. 413 Typically sRGB is well-suited for 8-bit fixed-point components 414 so we do not want this extension to require expensive tables 415 for other component sizes that are unlikely to ever be used. 416 Implementations could support sRGB conversion for any color 417 framebuffer format but implementations are not required to 418 (honestly nor are implementations like to support sRGB on anything 419 but 8-bit fixed-point color formats). 420 421 4) Should there be an enable for sRGB update and blending? 422 423 RESOLVED: Yes, and it is disabled by default. The enable only 424 applies if the framebuffer's underlying pixel format is capable 425 of sRGB update and blending. Otherwise, the enable is silently 426 ignored (similar to how the multisample enables are ignored when 427 the pixel format lacks multisample supports). 428 429 5) How is sRGB blending done? 430 431 RESOLVED: Blending is a linear operation so should be performed 432 on values in linear spaces. sRGB-encoded values are in a 433 non-linear space so sRGB blending should convert sRGB-encoded 434 values from the framebuffer to linear values, blend, and then 435 sRGB-encode the result to store it in the framebuffer. 436 437 The destination color RGB components are each converted 438 from sRGB to a linear value. Blending is then performed. 439 The source color and constant color are simply assumed to be 440 treated as linear color components. Then the result of blending 441 is converted to an sRGB encoding and stored in the framebuffer. 442 443 6) What happens if GL_FRAMEBUFFER_SRGB_EXT is enabled (and 444 GL_FRAMEBUFFER_SRGB_CAPABLE_EXT is true for the drawable) but 445 GL_BLEND is not enabled? 446 447 RESOLVED: The color result from fragment coloring (the source 448 color) is converted to an sRGB encoding and stored in the 449 framebuffer. 450 451 7) How are multiple render targets handled? 452 453 RESOLVED: Render targets that are not 454 GL_FRAMEBUFFER_SRGB_CAPABLE_EXT ignore the state of the 455 GL_FRAMEBUFFER_SRGB_EXT enable for sRGB update and blending. 456 So only the render targets that are sRGB-capable perform sRGB 457 blending and update when GL_FRAMEBUFFER_SRGB_EXT is enabled. 458 459 8) Should sRGB framebuffer support affect the pixel path? 460 461 RESOLVED: No. 462 463 sRGB conversion only applies to color reads for blending and 464 color writes. Color reads for glReadPixels, glCopyPixels, 465 or glAccum have no sRGB conversion applied. 466 467 For pixel path operations, an application could use pixel maps 468 or color tables to perform an sRGB-to-linear conversion with 469 these lookup tables. 470 471 9) Can luminance (single color component) framebuffer formats 472 support sRGB blending? 473 474 RESOLVED: Yes, if an implementation chooses to advertise such 475 a format and set the sRGB attribute for the format too. 476 477 Implementations are not obliged to provide such formats. 478 479 10) Should all component sizes be supported for sRGB components or 480 just 8-bit? 481 482 RESOLVED: This is at the implementation's discretion since 483 the implementation decides what pixel formats such support sRGB 484 update and blending. 485 486 It likely implementations will only provide sRGB-capable 487 framebuffer configurations for configurations with 8-bit 488 components. 489 490 11) What must be specified as far as how do you convert to and from 491 sRGB and linear RGB color spaces? 492 493 RESOLVED: The specification language needs to only supply the 494 linear RGB to sRGB conversion (see section 4.9.X above). 495 496 The sRGB to linear RGB conversion is documented in the 497 EXT_texture_sRGB specification. 498 499 For completeness, the accepted linear RGB to sRGB conversion 500 (the inverse of the function specified in section 3.8.x) is as 501 follows: 502 503 Given a linear RGB component, cl, convert it to an sRGB component, 504 cs, in the range [0,1], with this pseudo-code: 505 506 if (isnan(cl)) { 507 /* Map IEEE-754 Not-a-number to zero. */ 508 cs = 0.0; 509 } else if (cl > 1.0) { 510 cs = 1.0; 511 } else if (cl < 0.0) { 512 cs = 0.0; 513 } else if (cl < 0.0031308) { 514 cs = 12.92 * cl; 515 } else { 516 cs = 1.055 * pow(cl, 0.41666) - 0.055; 517 } 518 519 The NaN behavior in the pseudo-code is recommended but not 520 specified in the actual specification language. 521 522 sRGB components are typically stored as unsigned 8-bit 523 fixed-point values. If cs is computed with the above 524 pseudo-code, cs can be converted to a [0,255] integer with this 525 formula: 526 527 csi = floor(255.0 * cs + 0.5) 528 529 12) Does this extension guarantee images rendered with sRGB textures 530 will "look good" when output to a device supporting an sRGB 531 color space? 532 533 RESOLVED: No. 534 535 Whether the displayed framebuffer is displayed to a monitor that 536 faithfully reproduces the sRGB color space is beyond the scope 537 of this extension. This involves the gamma correction and color 538 calibration of the physical display device. 539 540 13) How does this extension interact with EXT_framebuffer_object? 541 542 RESOLVED: When rendering to a color texture, an application 543 can query GL_FRAMEBUFFER_SRGB_CAPABLE_EXT to determine if the 544 color texture image is capable of sRGB rendering. 545 546 This boolean should be false for all texture internal formats 547 except may be true (but are not required to be true) for the sRGB 548 internal formats introduced by EXT_texture_sRGB. The expectation 549 is that implementations of this extension will be able to support 550 sRGB update and blending of sRGB textures. 551 552 14) How is the constant blend color handled for sRGB framebuffers? 553 554 RESOLVED: The constant blend color is specified as four 555 floating-point values. Given that the texture border color can 556 be specified at such high precision, it is always treated as a 557 linear RGBA value. 558 559 15) How does glCopyTex[Sub]Image work with sRGB? Suppose we're 560 rendering to a floating point pbuffer or framebuffer object and 561 do CopyTexImage. Are the linear framebuffer values converted 562 to sRGB during the copy? 563 564 RESOLVED: No, linear framebuffer values will NOT be automatically 565 converted to the sRGB encoding during the copy. If such a 566 conversion is desired, as explained in issue 12, the red, green, 567 and blue pixel map functionality can be used to implement a 568 linear-to-sRGB encoding translation. 569 570 16) Should this extension explicitly specify the particular 571 sRGB-to-linear and linear-to-sRGB conversions it uses? 572 573 RESOLVED: The conversions are explicitly specified but 574 allowance for approximations is provided. The expectation is 575 that the implementation is likely to use a table to implement the 576 conversions the conversion is necessarily then an approximation. 577 578 17) How does this extension interact with multisampling? 579 580 RESOLVED: There are no explicit interactions. However, arguably 581 if the color samples for multisampling are sRGB encoded, the 582 samples should be linearized before being "resolved" for display 583 and then recoverted to sRGB if the output device expects sRGB 584 encoded color components. 585 586 This is really a video scan-out issue and beyond the scope 587 of this extension which is focused on the rendering issues. 588 However some implementation advice is provided: 589 590 The implementation sufficiently aware of the gamma correction 591 configured for the display device could decide to perform an 592 sRGB-correct multisample resolve. Whether this occurs or not 593 could be determined by a control panel setting or inferred by 594 the application's use of this extension. 595 596 18) Why is the sRGB framebuffer GL_FRAMEBUFFER_SRGB_EXT enable 597 disabled by default? 598 599 RESOLVED: This extension could have a boolean 600 sRGB-versus-non-sRGB pixel format configuration mode that 601 determined whether or not sRGB framebuffer update and blending 602 occurs. The problem with this approach is 1) it creates may more 603 pixel formation configurations because sRGB and non-sRGB versions 604 of lots of existing configurations must be advertised, and 2) 605 applicaitons unaware of sRGB might unknowingly select an sRGB 606 configuration and then generate over-bright rendering. 607 608 It seems more appropriate to have a capability for sRGB 609 framebuffer update and blending that is disabled by default. 610 This allows existing RGB8 and RGBA8 framebuffer configurations 611 to be marked as sRGB capable (so no additional configurations 612 need be enumerated). Applications that desire sRGB rendering 613 should identify an sRGB-capable framebuffer configuration and 614 then enable sRGB rendering. 615 616 This is different from how EXT_texture_sRGB handles sRGB support 617 for texture formats. In the EXT_texture_sRGB extension, textures 618 are either sRGB or non-sRGB and there is no texture parameter 619 to switch textures between the two modes. This makes sense for 620 EXT_texture_sRGB because it allows implementations to fake sRGB 621 textures with higher-precision linear textures that simply convert 622 sRGB-encoded texels to sufficiently precise linear RGB values. 623 624 Texture formats also don't have the problem enumerated pixel 625 format descriptions have where a naive application could stumble 626 upon an sRGB-capable pixel format. sRGB textures require 627 explicit use of one of the new EXT_texture_sRGB-introduced 628 internal formats. 629 630 19) How does sRGB and this extension interact with digital video 631 output standards, in particular DVI? 632 633 RESOLVED: The DVI 1.0 specification recommends "as a default 634 position that digital moniotrs of all types support a color 635 transfer function similar to analog CRT monitors (gamma=2.2) 636 which makes up the majority of the compute display market." This 637 means DVI output devices should benefit from blending in the 638 sRGB color space just like analog monitors. 639 640 20) How does an sRGB framebuffer interact with glClearColor? 641 642 RESOLVED: The R, G, and B color components passed to glClearColor 643 are assumed to be linear color components. 644 645 So when GL_FRAMEBUFFER_SRGB_EXT is enabled and the color buffer 646 is sRGB-capable, the clear color is converted to a sRGB value 647 as part of the clear operation. 648 649 This behavior is consistent with the behavior of Direct3D 9, 650 10, and 11. 651 652 21) How does an sRGB framebuffer interact querying with 653 GL_COLOR_CLEAR_VALUE? 654 655 RESOLVED: The sRGB conversion of the clear color value 656 happens during the clear operation so when glGetFloatv for 657 GL_COLOR_CLEAR_VALUE returns an RGBA value, the RGB components 658 are the same values last passed to glClearColor (or similar 659 routines that update the same state such as glClearColorIiEXT 660 and glClearColorIuiEXT). 661 662 22) How does an sRGB framebuffer interact with the accumulation 663 buffer? 664 665 RESOLVED: When the accumulation buffer reads color values from 666 the color buffer during the GL_ACCUM or GL_LOAD operations, 667 the color values should be converted from sRGB values to linear 668 RGB values if GL_FRAMEBUFFER_SRGB_EXT is enabled and the color 669 buffer is sRGB-capable. Amended language says that the GL_ACCUM 670 (and implicitly, the GL_LOAD operation defined in terms of 671 GL_ACCUM) perform an sRGB to linear RGB conversion when color 672 buffer pixels are accumulated/loaded into the accumulation 673 buffer. 674 675 When the accumulation returns color values to the color 676 buffer during the GL_RETURN operation, the color values in the 677 accumulation buffer should be converted from linear RGB values 678 to sRGB values if GL_FRAMEBUFFER_SRGB_EXT is enabled and the 679 color buffer is sRGB-capable. The specification accomplishes 680 this by saying that the sRGB conversion (if enabled) per-fragment 681 operation applies to the GL_RETURN operation. 682 683 No sRGB conversion affects the accumulation buffer alpha 684 component. 685 686 This behavior ensures that the accumulation buffer and its linear 687 operations are performed on linear color values. 688 689 23) How does an sRGB framebuffer interact with GL_LOGIC_OP? 690 691 RESOLVED: When GL_LOGIC_OP is enabled and rendering to an 692 sRGB-capable color buffer with GL_FRAMEBUFFER_SRGB_EXT enabled, 693 the framebuffer's color representation is no longer fixed-point 694 so a bit-wise operation such as logic-op is dubious. 695 696 This same issue was faced with floating-point color buffers 697 and the decision there was to ignore the logic operation for 698 floating-point color components (and ignore blending, if enabled, 699 too because logic-op's behavior trumps blending). 700 701 So sRGB color components should ignore logic-op if enabled. 702 703 This resolution is consistent with the ARB_color_buffer_float 704 specification. 705 706Implementation Notes 707 708 Implementations of this extension prior to late 2010 likely do 709 not implement the correct sRGB conversion for accumulation buffer 710 operations (the correct specification language was added in September 711 2010). 712 713Revision History 714 715 Rev. Date Author Changes 716 ---- -------- -------- ------------------------------------- 717 4 09/17/10 mjk Add logic-op interaction 718 3 09/14/10 mjk Add interactions with clear and 719 accumulation buffer operations 720 2 08/11/08 mjk Get Command: IsEnabled -> GetInteger 721 for FRAMEBUFFER_SRGB_CAPABLE_EXT 722 1 10/21/06 barthold Added revision history 723 0.4 10/20/06 mjk Added issue 19 724 0.3 mjk Internal spec development. 725 726