blob: a76fa2ad2ced79d235083486e32cfd9837fb827b [file] [log] [blame]
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.