| Name |
| |
| EXT_sRGB_write_control |
| |
| Name Strings |
| |
| GL_EXT_sRGB_write_control |
| |
| Contributors |
| |
| Matt Trusten |
| Maurice Ribble |
| |
| Parts of this specification were taken from ARB_framebuffer_sRGB |
| Parts of this specification were taken from EXT_sRGB |
| |
| Contact |
| |
| Maurice Ribble, Qualcomm (mribble 'at' qti.qualcomm.com) |
| |
| Status |
| |
| Complete |
| |
| Version |
| |
| Version #2, August 5, 2013 |
| |
| Number |
| |
| OpenGL ES Extension #153 |
| |
| Dependencies |
| |
| This extension requires OpenGL ES 2.0 and EXT_sRGB or OpenGL ES 3.0 |
| |
| This extension is based on the wording and functionality of the OpenGL ES |
| 3.0 specification. |
| |
| Overview |
| |
| This extension's intent is to expose new functionality which allows an |
| application the ability to decide if the conversion from linear space to |
| sRGB is necessary by enabling or disabling this conversion at framebuffer |
| write or blending time. An application which passes non-linear vector data |
| to a shader may not want the color conversion occurring, and by disabling |
| conversion the application can be simplified, sometimes in very significant |
| and more optimal ways. |
| |
| New Procedures and Functions |
| |
| None |
| |
| New Tokens |
| |
| Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, |
| and by the <pname> parameter of GetBooleanv, GetFloatv, GetIntegerv and |
| GetInteger64v: |
| |
| FRAMEBUFFER_SRGB_EXT 0x8DB9 |
| |
| Additions to Chapter 3 of the 3.0 Specification (Rasterization) |
| |
| None |
| |
| Additions to Chapter 4 of the 3.0 Specification (Per-Fragment Operations and |
| the Framebuffer) |
| |
| Modify Section 4.1.7: Blending |
| |
| If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer |
| attachment corresponding to the destination buffer is SRGB (see section |
| 6.1.13) and FRAMEBUFFER_SRGB_EXT is enabled, the R, G, and B |
| destination color values (after conversion from fixedpoint to |
| floating-point) are considered to be encoded for the sRGB color space and |
| hence must be linearized prior to their use in blending. Each R, G, and B |
| component is converted in the same fashion described for sRGB texture |
| components in section 3.8.16. |
| If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, or |
| FRAMEBUFFER_SRGB_EXT is disabled, no linearization is performed. |
| |
| Modify Section 4.1.8: sRGB Conversion |
| |
| If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer |
| attachment corresponding to the destination buffer is SRGB (see section |
| 6.1.13) and FRAMEBUFFER_SRGB_EXT is enabled, the R, G, and B |
| values after blending are converted into the non-linear sRGB color space by |
| computing |
| |
| { 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). |
| |
| Modify Section 4.3.2: Copying Pixels |
| |
| When values are taken from the read buffer, if the value of FRAMEBUFFER_- |
| ATTACHMENT_COLOR_ENCODING for the framebuffer attachment corresponding to |
| the read buffer is SRGB (see section 6.1.13), the red, green, and blue |
| components are converted from the non-linear sRGB color space according to |
| equation 3.24 if FRAMEBUFFER_SRGB_EXT is enabled. |
| |
| Interactions with OpenGL ES 2.0 and EXT_sRGB: |
| |
| In the case of not working with OpenGL ES 3.0, sRGB conversion is dictacted |
| by EXT_sRGB. The following changes should be made to EXT_sRGB to support |
| this extension properly in this case: |
| |
| In "Additions to Chapter 4 of the Specification", the third paragraph after |
| "with the following sentences", the following excerpt should be changed |
| from: |
| |
| If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT is not SRGB, |
| no linearization is performed. |
| |
| to: |
| |
| If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT is not SRGB, |
| or FRAMEBUFFER_SRGB_EXT is disabled, no linearization is performed. |
| |
| In the "ADD new section 4.1.X..." section, change the first paragraph which |
| reads: |
| |
| "If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the |
| framebuffer attachment corresponding to the destination buffer is SRGB, |
| the R, G, and B values after blending are converted into the non-linear |
| sRGB color space by computing: |
| |
| { 0.0, cl <= 0 |
| { 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). |
| |
| to: |
| |
| "If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the |
| framebuffer attachment corresponding to the destination buffer is SRGB, |
| and FRAMEBUFFER_SRGB_EXT is enabled, the R, G, and B values after |
| blending are converted into the non-linear sRGB color space by |
| computing: |
| |
| { 0.0, cl <= 0 |
| { 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). |
| |
| and after the second paragraph, before the following: |
| |
| The following should be added to table 4.5 Renderbuffer Image formats: |
| SRGB8_ALPHA8_EXT color_renderable 8 8 8 8 - - |
| |
| add: |
| |
| If FRAMEBUFFER_SRGB_EXT is disabled, no conversion into linear space |
| will occur. |
| |
| Errors |
| |
| Relaxation of INVALID_ENUM errors |
| --------------------------------- |
| |
| Enable, Disable, IsEnabled, GetBooleanv, GetFloatv, GetIntegerv and |
| GetInteger64v now accept the new token as allowed in the "New Tokens" |
| section. |
| |
| New State |
| |
| Add to table 6.11 (Pixel Operations) |
| |
| Get Value Type Get Command Initial Value Description Sec. Attribute |
| -------------------- ---- ----------- ------------- --------------- ----- ------------------- |
| FRAMEBUFFER_SRGB_EXT B IsEnabled True sRGB update and 4.1.X color-buffer/enable |
| blending enable |
| |
| New Implementation Dependent State |
| |
| None |
| |
| Issues |
| |
| 1) What should this extension be called? |
| |
| As a place holder we are using: EXT_sRGB_write_control |
| |
| This was chosen because EXT_framebuffer_sRGB does not make it |
| immediately obvious that this extension is only dealing with operations |
| after the pixel path, and EXT_sRGB_write_control seems more clear. The |
| original is named with ARB, ARB_framebuffer_sRGB, so it may also make |
| sense to change the name to EXT_framebuffer_sRGB. |
| |
| 2) How is sRGB blending done in the default state (FRAMEBUFFER_SRGB_EXT |
| is enabled)? |
| |
| 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. |
| |
| 3) How are multiple render targets handled? |
| |
| RESOLVED: Render targets that are not sRGB capable 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. |
| |
| 4) Why is the sRGB framebuffer GL_FRAMEBUFFER_SRGB_EXT enabled by default? |
| |
| Based on the the GLES 3.0 spec, if this conversion choice is disabled |
| by default then current apps which expect this conversion to happen |
| will be broken and the output will not look as intended. |
| |
| 5) FRAMEBUFFER_SRGB seems concerned with writing to sRGB framebuffers and |
| blending operations. How do we want to handle the operations which |
| include reading from a framebuffer, such as glBlitFramebuffer, |
| glReadPixels, or glCopyTexImage? |
| |
| This flag will affect glBlitFramebuffer, but will not affect |
| glReadPixels or glCopyTex[Sub]Image. |
| |
| If the implementation does not support OpenGL ES 3.0 and instead |
| supports OpenGL 2.0 and EXT_sRGB, references to glBlitFramebuffer can |
| be ignored. However, the above will be true if the implementation |
| supports NV_framebuffer_blit. |
| |
| 6) 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. |
| |
| Revision History |
| #02 8/05/2013 Matt Trusten Minor bug fixes |
| Added multisampling issue from |
| ARB_framebuffer_sRGB |
| |
| #01 6/04/2013 Matt Trusten First draft. |