| Name | |
| EXT_framebuffer_sRGB | |
| Name Strings | |
| GL_EXT_framebuffer_sRGB | |
| GLX_EXT_framebuffer_sRGB | |
| WGL_EXT_framebuffer_sRGB | |
| Contributors | |
| Alex Eddy, Apple | |
| Chris Niederauer, Apple | |
| Herb (Charles) Kuta, Quantum3D | |
| Jeremy Sandmel, Apple | |
| Jesse Hall, NVIDIA | |
| From the EXT_texture_sRGB specification... | |
| Alain Bouchard, Matrox | |
| Brian Paul, Tungsten Graphics | |
| Daniel Vogel, Epic Games | |
| Eric Werness, NVIDIA | |
| Kiril Vidimce, Pixar | |
| Mark J. Kilgard, NVIDIA | |
| Pat Brown, NVIDIA | |
| Yanjun Zhang, S3 Graphics | |
| Contact | |
| Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) | |
| Status | |
| Complete. | |
| Version | |
| Date: September 17, 2010 | |
| Revision: 4 | |
| Number | |
| 337 | |
| Dependencies | |
| OpenGL 1.1 required | |
| This extension is written against the OpenGL 2.0 (September 7, | |
| 2004) specification. | |
| WGL_EXT_extensions_string is required for WGL support. | |
| WGL_EXT_pixel_format is required for WGL support. | |
| ARB_color_buffer_float interacts with this extension. | |
| EXT_framebuffer_object interacts with this extension. | |
| EXT_texture_sRGB interacts with this extension. | |
| ARB_draw_buffers interacts with this extension. | |
| Overview | |
| Conventionally, OpenGL assumes framebuffer color components are stored | |
| in a linear color space. In particular, framebuffer blending is a | |
| linear operation. | |
| The sRGB color space is based on typical (non-linear) monitor | |
| characteristics expected in a dimly lit office. It has been | |
| standardized by the International Electrotechnical Commission (IEC) | |
| as IEC 61966-2-1. The sRGB color space roughly corresponds to 2.2 | |
| gamma correction. | |
| 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. | |
| The primary motivation for this extension is that it allows OpenGL | |
| applications to render into a framebuffer that is scanned to a monitor | |
| configured to assume framebuffer color values are sRGB encoded. | |
| This assumption is roughly true of most PC monitors with default | |
| gamma correction. This allows applications to achieve faithful | |
| color reproduction for OpenGL rendering without adjusting the | |
| monitor's gamma correction. | |
| New Procedures and Functions | |
| None | |
| New Tokens | |
| Accepted by the <attribList> parameter of glXChooseVisual, and by | |
| the <attrib> parameter of glXGetConfig: | |
| GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT 0x20B2 | |
| Accepted by the <piAttributes> parameter of | |
| wglGetPixelFormatAttribivEXT, wglGetPixelFormatAttribfvEXT, and | |
| the <piAttribIList> and <pfAttribIList> of wglChoosePixelFormatEXT: | |
| WGL_FRAMEBUFFER_SRGB_CAPABLE_EXT 0x20A9 | |
| Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, | |
| and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, | |
| and GetDoublev: | |
| FRAMEBUFFER_SRGB_EXT 0x8DB9 | |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, | |
| GetFloatv, and GetDoublev: | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT 0x8DBA | |
| Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation) | |
| None | |
| Additions to Chapter 3 of the 2.0 Specification (Rasterization) | |
| None | |
| Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations | |
| and the Frame Buffer) | |
| -- Section 4.1.8 "Blending" | |
| DELETE the following sentence from section 4.1.8 (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.14.9." | |
| If ARB_color_buffer_float is supported, the following paragraph | |
| is modified to eliminate the fixed-point clamping and conversion | |
| because this behavior is moved to the new "sRGB Conversion" section. | |
| "If the color buffer is fixed-point, the components of the source | |
| and destination values and blend factors are clamped to [0, 1] | |
| prior to evaluating the blend equation, the components of the | |
| blending result are clamped to [0,1] and converted to fixed- | |
| point values in the manner described in section 2.14.9. If the | |
| color buffer is floating-point, no clamping occurs. The | |
| resulting four values are sent to the next operation." | |
| The modified ARB_color_buffer_float paragraph should read: | |
| "If the color buffer is fixed-point, the components of the source | |
| and destination values and blend factors are clamped to [0, 1] | |
| prior to evaluating the blend equation. If the color buffer is | |
| floating-point, no clamping occurs. The resulting four values are | |
| sent to the next operation." | |
| Replace the following sentence: | |
| "Destination (framebuffer) components are taken to be fixed-point | |
| values represented according to the scheme in section 2.14.9 (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.14.9 (Final | |
| Color Processing). If FRAMEBUFFER_SRGB_EXT is enabled and the boolean | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true, 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. Otherwise if FRAMEBUFFER_SRGB_EXT is disabled, or the | |
| drawable is not sRGB capable, or the value corresponds to the A | |
| component, then cs = cl for such components. The corresponding cs | |
| values for R, G, B, and A are recombined as the destination color | |
| used subsequently by blending." | |
| ADD new section 4.1.X "sRGB Conversion" after section 4.1.8 (Blending) | |
| and before section 4.1.9 (Dithering). With this new section added, | |
| understand the "next operation" referred to in the section 4.1.8 | |
| (Blending) to now be "sRGB Conversion" (instead of "Dithering"). | |
| "If FRAMEBUFFER_SRGB_EXT is enabled and the boolean | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true, the R, | |
| G, and B values after blending are converted into the non-linear | |
| sRGB color space by some approximation of the following: | |
| { 0.0, 0 <= cl | |
| { 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). Otherwise if | |
| FRAMEBUFFER_SRGB_EXT is disabled, or the drawable is not sRGB | |
| capable, or the value corresponds to the A element, then cs = cl | |
| for such elements. | |
| The resulting cs values 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 in the | |
| manner described in section 2.14.9. The resulting four values are | |
| sent to the subsequent dithering operation." | |
| -- Section 4.1.10 "Logical Operation" | |
| Add this pargraph after the first paragraph in the section: | |
| "Logical operation has no effect on an sRGB destination color buffer | |
| (i.e., the boolean FRAMEBUFFER_SRGB_CAPABLE_EXT state for the | |
| drawable is true) when FRAMEBUFFER_SRGB_EXT is enabled; however, | |
| if the logical operation is enabled, blending is still disabled." | |
| If ARB_color_buffer_float is supported, that specification's paragraph | |
| (upon which the above paragraph is modeled) would be modified to | |
| read: | |
| "Logical operation has no effect on a floating-point destination | |
| color buffer or sRGB destination color buffer (i.e., the boolean | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true) when | |
| FRAMEBUFFER_SRGB_EXT is enabled; however, if the logical operation | |
| is enabled, blending is still disabled." | |
| -- Section 4.2.3 "Clearing the Buffers" | |
| Change the first full sentence after the ClearColor prototype to | |
| read: | |
| "Each of the specified components is clamped to [0,1]." | |
| (removing the "converted to fixed-point..." phrase because this | |
| technically happens prior to sRGB conversion and/or dithering during | |
| a Clear rather than at the time of the ClearColor call.) | |
| Change the first sentence in the second to last paragraph of the | |
| section to read: | |
| "When Clear is called, the only per-fragment operations that are | |
| applied (if enabled) are the pixel ownership test, the scissor test, | |
| sRGB conversion, and dithering. The resulting color value (possibly | |
| sRGB converted and/or dithered) is converted to fixed-point according | |
| to the rules of section 2.14.19." | |
| -- Section 4.2.4 "The Accumulation Buffer" | |
| Change the fifth sentence of the second pargraph (describing ACCUM) to read: | |
| "Each component, considered as a fixed-point value in | |
| [0,1] (see section 2.14.9) is converted to floating-point; | |
| special rules apply if the color buffer is sRGB-capable. | |
| Specifically, if FRAMEBUFFER_SRGB_EXT is enabled and the boolean | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT state for the drawable is true, 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 for accumulation. | |
| This conversion uses the formula to compute cl from cs is section | |
| 4.1.8." | |
| Change the second to last sentence of the fourth paragraph (describing | |
| RETURN) to read: | |
| "The resulting color value is placed in the buffers currently | |
| enabled for color writing as if it were a fragment produced from | |
| rasterization, except that the only per-fragment operations that are | |
| applied (if enabled) are the pixel ownership test, the scissor test | |
| (section 4.1.2), sRGB conversion (section 4.2.X), and dithering | |
| (section 4.1.9)." | |
| 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) | |
| None | |
| Additions to the OpenGL Shading Language specification | |
| None | |
| Additions to the GLX Specification | |
| None | |
| Dependencies on ARB_color_buffer_float | |
| If ARB_color_buffer_float is not supported, ignore the edits to | |
| ARB_color_buffer_float language. | |
| Dependencies on EXT_texture_sRGB and EXT_framebuffer_object | |
| If EXT_texture_sRGB and EXT_framebuffer_object are both supported, the | |
| implementation should set FRAMEBUFFER_SRGB_CAPABLE_EXT to false when | |
| rendering to a color texture that is not one of the EXT_texture_sRGB | |
| introduced internal formats. An implementation can determine whether | |
| or not it will set FRAMEBUFFER_SRGB_CAPABLE_EXT to true for the | |
| EXT_texture_sRGB introduced internal formats. Implementations are | |
| encouraged to allow sRGB update and blending when rendering to sRGB | |
| textures using EXT_framebuffer_object but this is not required. | |
| In any case, FRAMEBUFFER_SRGB_CAPABLE_EXT should indicate whether | |
| or not sRGB update and blending is supported. | |
| Dependencies on ARB_draw_buffers, EXT_texture_sRGB, and EXT_framebuffer_object | |
| If ARB_draw_buffers, EXT_texture_sRGB, and EXT_framebuffer_object | |
| are supported and an application attempts to render to a set | |
| of color buffers where some but not all of the color buffers | |
| are FRAMEBUFFER_SRGB_CAPABLE_EXT individually, the query of | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT should return true. | |
| However sRGB update and blending only apply to the color buffers | |
| that are actually sRGB-capable. | |
| GLX Protocol | |
| None. | |
| Errors | |
| Relaxation of INVALID_ENUM errors | |
| --------------------------------- | |
| Enable, Disable, IsEnabled, GetBooleanv, GetIntegerv, GetFloatv, | |
| and GetDoublev now accept the new token as allowed in the "New | |
| Tokens" section. | |
| New State | |
| Add to table 6.20 (Pixel Operations) | |
| Get Value Type Get Command Initial Value Description Sec. Attribute | |
| -------------------- ---- ----------- ------------- --------------- ----- ------------------- | |
| FRAMEBUFFER_SRGB_EXT B IsEnabled False sRGB update and 4.1.X color-buffer/enable | |
| blending enable | |
| Add to table 6.33 (Implementation Dependent Values) | |
| Get Value Type Get Command Initial Value Description Sec. Attribute | |
| ---------------------------- ---- ----------- ------------- -------------------- ----- --------- | |
| FRAMEBUFFER_SRGB_CAPABLE_EXT B GetIntegerv - true if drawable 4.1.X - | |
| supports sRGB update | |
| and blending | |
| New Implementation Dependent State | |
| None | |
| Issues | |
| 1) What should this extension be called? | |
| RESOLVED: EXT_framebuffer_sRGB. | |
| The "EXT_framebuffer" part indicates the extension is in | |
| the framebuffer domain and "sRGB" indicates the extension is | |
| adding a set of sRGB formats. This mimics the naming of the | |
| EXT_texture_sRGB extension that adds sRGB texture formats. | |
| The mixed-case spelling of sRGB is the established usage so | |
| "_sRGB" is preferred to "_srgb". The "s" stands for standard | |
| (color space). | |
| For token names, we use "SRGB" since token names are uniformly | |
| capitalized. | |
| 2) Should alpha be sRGB encoded? | |
| RESOLVED: No. Alpha remains linear. | |
| A rationale for this resolution is found in Alvy Ray's "Should | |
| Alpha Be Nonlinear If RGB Is?" Tech Memo 17 (December 14, 1998). | |
| See: ftp://ftp.alvyray.com/Acrobat/17_Nonln.pdf | |
| 3) Should the ability to support sRGB framebuffer update and blending | |
| be an attribute of the framebuffer? | |
| RESOLVED: Yes. It should be a capability of some pixel formats | |
| (mostly likely just RGB8 and RGBA8) that says sRGB blending can | |
| be enabled. | |
| This allows an implementation to simply mark the existing RGB8 | |
| and RGBA8 pixel formats as supporting sRGB blending and then | |
| just provide the functionality for sRGB update and blending for | |
| such formats. | |
| sRGB support for floating-point formats makes little sense | |
| (because floating-point already provide a non-linear distribution | |
| of precision and typically have considerably more precision | |
| than 8-bit fixed-point framebuffer components allow) and would | |
| be expensive to support. | |
| Requiring sRGB support for all fixed-point buffers means that | |
| support for 16-bit components or very small 5-bit or 6-bit | |
| components would require special sRGB conversion hardware. | |
| Typically sRGB is well-suited for 8-bit fixed-point components | |
| so we do not want this extension to require expensive tables | |
| for other component sizes that are unlikely to ever be used. | |
| Implementations could support sRGB conversion for any color | |
| framebuffer format but implementations are not required to | |
| (honestly nor are implementations like to support sRGB on anything | |
| but 8-bit fixed-point color formats). | |
| 4) Should there be an enable for sRGB update and blending? | |
| RESOLVED: Yes, and it is disabled by default. The enable only | |
| applies if the framebuffer's underlying pixel format is capable | |
| of sRGB update and blending. Otherwise, the enable is silently | |
| ignored (similar to how the multisample enables are ignored when | |
| the pixel format lacks multisample supports). | |
| 5) How is sRGB blending done? | |
| RESOLVED: Blending is a linear operation so should be performed | |
| on values in linear spaces. sRGB-encoded values are in a | |
| non-linear space so sRGB blending should convert sRGB-encoded | |
| values from the framebuffer to linear values, blend, and then | |
| sRGB-encode the result to store it in the framebuffer. | |
| The destination color RGB components are each converted | |
| from sRGB to a linear value. Blending is then performed. | |
| The source color and constant color are simply assumed to be | |
| treated as linear color components. Then the result of blending | |
| is converted to an sRGB encoding and stored in the framebuffer. | |
| 6) What happens if GL_FRAMEBUFFER_SRGB_EXT is enabled (and | |
| GL_FRAMEBUFFER_SRGB_CAPABLE_EXT is true for the drawable) but | |
| GL_BLEND is not enabled? | |
| RESOLVED: The color result from fragment coloring (the source | |
| color) is converted to an sRGB encoding and stored in the | |
| framebuffer. | |
| 7) How are multiple render targets handled? | |
| RESOLVED: Render targets that are not | |
| GL_FRAMEBUFFER_SRGB_CAPABLE_EXT ignore the state of the | |
| GL_FRAMEBUFFER_SRGB_EXT enable for sRGB update and blending. | |
| So only the render targets that are sRGB-capable perform sRGB | |
| blending and update when GL_FRAMEBUFFER_SRGB_EXT is enabled. | |
| 8) Should sRGB framebuffer support affect the pixel path? | |
| RESOLVED: No. | |
| sRGB conversion only applies to color reads for blending and | |
| color writes. Color reads for glReadPixels, glCopyPixels, | |
| or glAccum have no sRGB conversion applied. | |
| For pixel path operations, an application could use pixel maps | |
| or color tables to perform an sRGB-to-linear conversion with | |
| these lookup tables. | |
| 9) Can luminance (single color component) framebuffer formats | |
| support sRGB blending? | |
| RESOLVED: Yes, if an implementation chooses to advertise such | |
| a format and set the sRGB attribute for the format too. | |
| Implementations are not obliged to provide such formats. | |
| 10) Should all component sizes be supported for sRGB components or | |
| just 8-bit? | |
| RESOLVED: This is at the implementation's discretion since | |
| the implementation decides what pixel formats such support sRGB | |
| update and blending. | |
| It likely implementations will only provide sRGB-capable | |
| framebuffer configurations for configurations with 8-bit | |
| components. | |
| 11) What must be specified as far as how do you convert to and from | |
| sRGB and linear RGB color spaces? | |
| RESOLVED: The specification language needs to only supply the | |
| linear RGB to sRGB conversion (see section 4.9.X above). | |
| The sRGB to linear RGB conversion is documented in the | |
| EXT_texture_sRGB specification. | |
| For completeness, the accepted linear RGB to sRGB conversion | |
| (the inverse of the function specified in section 3.8.x) is as | |
| follows: | |
| Given a linear RGB component, cl, convert it to an sRGB component, | |
| cs, in the range [0,1], with this pseudo-code: | |
| if (isnan(cl)) { | |
| /* Map IEEE-754 Not-a-number to zero. */ | |
| cs = 0.0; | |
| } else if (cl > 1.0) { | |
| cs = 1.0; | |
| } else if (cl < 0.0) { | |
| cs = 0.0; | |
| } else if (cl < 0.0031308) { | |
| cs = 12.92 * cl; | |
| } else { | |
| cs = 1.055 * pow(cl, 0.41666) - 0.055; | |
| } | |
| The NaN behavior in the pseudo-code is recommended but not | |
| specified in the actual specification language. | |
| sRGB components are typically stored as unsigned 8-bit | |
| fixed-point values. If cs is computed with the above | |
| pseudo-code, cs can be converted to a [0,255] integer with this | |
| formula: | |
| csi = floor(255.0 * cs + 0.5) | |
| 12) Does this extension guarantee images rendered with sRGB textures | |
| will "look good" when output to a device supporting an sRGB | |
| color space? | |
| RESOLVED: No. | |
| Whether the displayed framebuffer is displayed to a monitor that | |
| faithfully reproduces the sRGB color space is beyond the scope | |
| of this extension. This involves the gamma correction and color | |
| calibration of the physical display device. | |
| 13) How does this extension interact with EXT_framebuffer_object? | |
| RESOLVED: When rendering to a color texture, an application | |
| can query GL_FRAMEBUFFER_SRGB_CAPABLE_EXT to determine if the | |
| color texture image is capable of sRGB rendering. | |
| This boolean should be false for all texture internal formats | |
| except may be true (but are not required to be true) for the sRGB | |
| internal formats introduced by EXT_texture_sRGB. The expectation | |
| is that implementations of this extension will be able to support | |
| sRGB update and blending of sRGB textures. | |
| 14) How is the constant blend color handled for sRGB framebuffers? | |
| RESOLVED: The constant blend color is specified as four | |
| floating-point values. Given that the texture border color can | |
| be specified at such high precision, it is always treated as a | |
| linear RGBA value. | |
| 15) How does glCopyTex[Sub]Image work with sRGB? Suppose we're | |
| rendering to a floating point pbuffer or framebuffer object and | |
| do CopyTexImage. Are the linear framebuffer values converted | |
| to sRGB during the copy? | |
| RESOLVED: No, linear framebuffer values will NOT be automatically | |
| converted to the sRGB encoding during the copy. If such a | |
| conversion is desired, as explained in issue 12, the red, green, | |
| and blue pixel map functionality can be used to implement a | |
| linear-to-sRGB encoding translation. | |
| 16) Should this extension explicitly specify the particular | |
| sRGB-to-linear and linear-to-sRGB conversions it uses? | |
| RESOLVED: The conversions are explicitly specified but | |
| allowance for approximations is provided. The expectation is | |
| that the implementation is likely to use a table to implement the | |
| conversions the conversion is necessarily then an approximation. | |
| 17) How does this extension interact with multisampling? | |
| RESOLVED: There are no explicit interactions. However, arguably | |
| if the color samples for multisampling are sRGB encoded, the | |
| samples should be linearized before being "resolved" for display | |
| and then recoverted to sRGB if the output device expects sRGB | |
| encoded color components. | |
| This is really a video scan-out issue and beyond the scope | |
| of this extension which is focused on the rendering issues. | |
| However some implementation advice is provided: | |
| The implementation sufficiently aware of the gamma correction | |
| configured for the display device could decide to perform an | |
| sRGB-correct multisample resolve. Whether this occurs or not | |
| could be determined by a control panel setting or inferred by | |
| the application's use of this extension. | |
| 18) Why is the sRGB framebuffer GL_FRAMEBUFFER_SRGB_EXT enable | |
| disabled by default? | |
| RESOLVED: This extension could have a boolean | |
| sRGB-versus-non-sRGB pixel format configuration mode that | |
| determined whether or not sRGB framebuffer update and blending | |
| occurs. The problem with this approach is 1) it creates may more | |
| pixel formation configurations because sRGB and non-sRGB versions | |
| of lots of existing configurations must be advertised, and 2) | |
| applicaitons unaware of sRGB might unknowingly select an sRGB | |
| configuration and then generate over-bright rendering. | |
| It seems more appropriate to have a capability for sRGB | |
| framebuffer update and blending that is disabled by default. | |
| This allows existing RGB8 and RGBA8 framebuffer configurations | |
| to be marked as sRGB capable (so no additional configurations | |
| need be enumerated). Applications that desire sRGB rendering | |
| should identify an sRGB-capable framebuffer configuration and | |
| then enable sRGB rendering. | |
| This is different from how EXT_texture_sRGB handles sRGB support | |
| for texture formats. In the EXT_texture_sRGB extension, textures | |
| are either sRGB or non-sRGB and there is no texture parameter | |
| to switch textures between the two modes. This makes sense for | |
| EXT_texture_sRGB because it allows implementations to fake sRGB | |
| textures with higher-precision linear textures that simply convert | |
| sRGB-encoded texels to sufficiently precise linear RGB values. | |
| Texture formats also don't have the problem enumerated pixel | |
| format descriptions have where a naive application could stumble | |
| upon an sRGB-capable pixel format. sRGB textures require | |
| explicit use of one of the new EXT_texture_sRGB-introduced | |
| internal formats. | |
| 19) How does sRGB and this extension interact with digital video | |
| output standards, in particular DVI? | |
| RESOLVED: The DVI 1.0 specification recommends "as a default | |
| position that digital moniotrs of all types support a color | |
| transfer function similar to analog CRT monitors (gamma=2.2) | |
| which makes up the majority of the compute display market." This | |
| means DVI output devices should benefit from blending in the | |
| sRGB color space just like analog monitors. | |
| 20) How does an sRGB framebuffer interact with glClearColor? | |
| RESOLVED: The R, G, and B color components passed to glClearColor | |
| are assumed to be linear color components. | |
| So when GL_FRAMEBUFFER_SRGB_EXT is enabled and the color buffer | |
| is sRGB-capable, the clear color is converted to a sRGB value | |
| as part of the clear operation. | |
| This behavior is consistent with the behavior of Direct3D 9, | |
| 10, and 11. | |
| 21) How does an sRGB framebuffer interact querying with | |
| GL_COLOR_CLEAR_VALUE? | |
| RESOLVED: The sRGB conversion of the clear color value | |
| happens during the clear operation so when glGetFloatv for | |
| GL_COLOR_CLEAR_VALUE returns an RGBA value, the RGB components | |
| are the same values last passed to glClearColor (or similar | |
| routines that update the same state such as glClearColorIiEXT | |
| and glClearColorIuiEXT). | |
| 22) How does an sRGB framebuffer interact with the accumulation | |
| buffer? | |
| RESOLVED: When the accumulation buffer reads color values from | |
| the color buffer during the GL_ACCUM or GL_LOAD operations, | |
| the color values should be converted from sRGB values to linear | |
| RGB values if GL_FRAMEBUFFER_SRGB_EXT is enabled and the color | |
| buffer is sRGB-capable. Amended language says that the GL_ACCUM | |
| (and implicitly, the GL_LOAD operation defined in terms of | |
| GL_ACCUM) perform an sRGB to linear RGB conversion when color | |
| buffer pixels are accumulated/loaded into the accumulation | |
| buffer. | |
| When the accumulation returns color values to the color | |
| buffer during the GL_RETURN operation, the color values in the | |
| accumulation buffer should be converted from linear RGB values | |
| to sRGB values if GL_FRAMEBUFFER_SRGB_EXT is enabled and the | |
| color buffer is sRGB-capable. The specification accomplishes | |
| this by saying that the sRGB conversion (if enabled) per-fragment | |
| operation applies to the GL_RETURN operation. | |
| No sRGB conversion affects the accumulation buffer alpha | |
| component. | |
| This behavior ensures that the accumulation buffer and its linear | |
| operations are performed on linear color values. | |
| 23) How does an sRGB framebuffer interact with GL_LOGIC_OP? | |
| RESOLVED: When GL_LOGIC_OP is enabled and rendering to an | |
| sRGB-capable color buffer with GL_FRAMEBUFFER_SRGB_EXT enabled, | |
| the framebuffer's color representation is no longer fixed-point | |
| so a bit-wise operation such as logic-op is dubious. | |
| This same issue was faced with floating-point color buffers | |
| and the decision there was to ignore the logic operation for | |
| floating-point color components (and ignore blending, if enabled, | |
| too because logic-op's behavior trumps blending). | |
| So sRGB color components should ignore logic-op if enabled. | |
| This resolution is consistent with the ARB_color_buffer_float | |
| specification. | |
| Implementation Notes | |
| Implementations of this extension prior to late 2010 likely do | |
| not implement the correct sRGB conversion for accumulation buffer | |
| operations (the correct specification language was added in September | |
| 2010). | |
| Revision History | |
| Rev. Date Author Changes | |
| ---- -------- -------- ------------------------------------- | |
| 4 09/17/10 mjk Add logic-op interaction | |
| 3 09/14/10 mjk Add interactions with clear and | |
| accumulation buffer operations | |
| 2 08/11/08 mjk Get Command: IsEnabled -> GetInteger | |
| for FRAMEBUFFER_SRGB_CAPABLE_EXT | |
| 1 10/21/06 barthold Added revision history | |
| 0.4 10/20/06 mjk Added issue 19 | |
| 0.3 mjk Internal spec development. | |