| Name |
| |
| ARB_framebuffer_sRGB |
| |
| Name Strings |
| |
| GL_ARB_framebuffer_sRGB |
| GLX_ARB_framebuffer_sRGB |
| WGL_ARB_framebuffer_sRGB |
| |
| Contributors |
| |
| Herb (Charles) Kuta, Quantum3D |
| 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 |
| Jeremy Sandmel, Apple |
| Jon Leech |
| Adam Jackson, Red Hat |
| |
| Contact |
| |
| Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL Working Group. For |
| extensions which have been promoted to a core Specification, fixes will |
| first appear in the latest version of that core Specification, and will |
| eventually be backported to the extension document. This policy is |
| described in more detail at |
| https://www.khronos.org/registry/OpenGL/docs/update_policy.php |
| |
| Status |
| |
| Approved by the ARB on July 11, 2008 |
| |
| Version |
| |
| Date: September 19, 2019 |
| Revision: 1.3 |
| |
| Number |
| |
| ARB Extension #46 |
| |
| Dependencies |
| |
| OpenGL 1.1 is 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. |
| |
| ARB_framebuffer_object is required. |
| |
| 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 |
| glXChooseFBConfig, and by the <attrib> parameter of glXGetConfig |
| and glXGetFBConfigAttrib: |
| |
| GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB 0x20B2 |
| |
| Accepted by the <piAttributes> parameter of |
| wglGetPixelFormatAttribivEXT, wglGetPixelFormatAttribfvEXT, and |
| the <piAttribIList> and <pfAttribIList> of wglChoosePixelFormatEXT: |
| |
| WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB 0x20A9 |
| |
| Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, |
| and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, |
| and GetDoublev: |
| |
| FRAMEBUFFER_SRGB 0x8DB9 |
| |
| 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) |
| |
| 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 is enabled and the value |
| of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer |
| attachment corresponding to the destination buffer is SRGB (see |
| section 6.1.3), 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 is disabled, or the |
| value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, no |
| linearization is performed. |
| |
| The resulting linearized R, G, and B and unmodified A values are |
| recombined as the destination color used in blending computations. |
| |
| |
| 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 is enabled and the value of |
| FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer attachment |
| corresponding to the destination buffer is SRGB (see section 6.1.3), |
| 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). |
| |
| If FRAMEBUFFER_SRGB is disabled or the value of |
| FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, then |
| |
| cs = cl |
| |
| The resulting cs values for R, G, and B and the unmodified A 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." |
| |
| 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 |
| |
| If GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB is specified for glXChooseVisual or |
| glXChooseFBConfig, it is treated as an exact match. If it is not specified, |
| it is treated as GLX_DONT_CARE. Sorting of visuals and fbconfigs by |
| GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB is undefined. |
| |
| 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 ARB_framebuffer_object |
| |
| If EXT_texture_sRGB and ARB_framebuffer_object are both supported, the |
| implementation should set the value of |
| FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING to LINEAR 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 the value of |
| FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING to SRGB for the |
| EXT_texture_sRGB introduced internal formats. Implementations are |
| encouraged to allow sRGB update and blending when rendering to sRGB |
| textures using ARB_framebuffer_object but this is not required. |
| In any case, FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING should indicate |
| whether or not sRGB update and blending is supported. |
| |
| Dependencies on ARB_draw_buffers, EXT_texture_sRGB, and ARB_framebuffer_object |
| |
| If ARB_draw_buffers, EXT_texture_sRGB, and ARB_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 SRGB |
| capable, 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 FRAMEBUFFER_SRGB 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 B IsEnabled False sRGB update and 4.1.X color-buffer/enable |
| blending enable |
| |
| New Implementation Dependent State |
| |
| None |
| |
| Issues |
| |
| 1) What should this extension be called? |
| |
| RESOLVED: ARB_framebuffer_sRGB. |
| |
| The "ARB_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 a destination buffer's 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 is enabled (and |
| GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is GL_SRGB), 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 sRGB-capable ignore the |
| state of the GL_FRAMEBUFFER_SRGB enable for sRGB update and |
| blending. Note that unlike EXT_framebuffer_sRGB, the |
| sRGB-capable query may be performed on a per-color-attachment |
| basis. |
| |
| 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 ARB_framebuffer_object? |
| |
| RESOLVED: ARB_framebuffer_object is required to provide the |
| GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING query used to determine |
| if the color texture image is capable of sRGB rendering. |
| |
| This query should be LINEAR for all texture internal formats |
| other than sRGB internal formats such as those introduced by |
| EXT_texture_sRGB. Implementations of this extension must 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 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) Why don't the new tokens and entry points in this extension have |
| "ARB" suffixes like other ARB extensions? |
| |
| RESOLVED: Unlike most ARB extensions, this is a strict subset of |
| functionality already approved in OpenGL 3.0. This extension |
| exists only to support that functionality on older hardware that |
| cannot implement a full OpenGL 3.0 driver. Since there are no |
| possible behavior changes between the ARB extension and core |
| features, source code compatibility is improved by not using |
| suffixes on the extension. |
| |
| This does not apply to the GLX and WGL elements of this |
| extension, since those elements are not part of a new core GLX |
| or WGL release yet. |
| |
| 21) Where's the specification language for the GLX and WGL pixel |
| format selection interface? |
| |
| TO BE DONE. The {GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB pixel |
| format attributes are used to select default framebuffers which |
| are sRGB-capable in the fairly obvious way, but this language |
| was missing in the original EXT_framebuffer_sRGB and needs to be |
| added here. |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- ------------------------------------- |
| 1.3 09/19/19 ajax Clarify GLX interaction. |
| 1.2 08/11/08 jleech Use per-FBO-attachment state for |
| sRGB-capable queries, rather then the |
| EXT's single boolean query for the |
| entire framebuffer. |
| 1.1 08/08/08 jleech Remove ARB suffixes. |
| 1 10/21/06 barthold Added revision history |
| 0.4 10/20/06 mjk Added issue 19 |
| 0.3 mjk Internal spec development. |
| |