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