• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    EXT_sRGB_write_control
4
5Name Strings
6
7    GL_EXT_sRGB_write_control
8
9Contributors
10
11    Matt Trusten
12    Maurice Ribble
13
14    Parts of this specification were taken from ARB_framebuffer_sRGB
15    Parts of this specification were taken from EXT_sRGB
16
17Contact
18
19    Maurice Ribble, Qualcomm (mribble 'at' qti.qualcomm.com)
20
21Status
22
23    Complete
24
25Version
26
27    Version #2, August 5, 2013
28
29Number
30
31    OpenGL ES Extension #153
32
33Dependencies
34
35    This extension requires OpenGL ES 2.0 and EXT_sRGB or OpenGL ES 3.0
36
37    This extension is based on the wording and functionality of the OpenGL ES
38    3.0 specification.
39
40Overview
41
42    This extension's intent is to expose new functionality which allows an
43    application the ability to decide if the conversion from linear space to
44    sRGB is necessary by enabling or disabling this conversion at framebuffer
45    write or blending time. An application which passes non-linear vector data
46    to a shader may not want the color conversion occurring, and by disabling
47    conversion the application can be simplified, sometimes in very significant
48    and more optimal ways.
49
50New Procedures and Functions
51
52    None
53
54New Tokens
55
56    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled,
57    and by the <pname> parameter of GetBooleanv, GetFloatv, GetIntegerv and
58    GetInteger64v:
59
60        FRAMEBUFFER_SRGB_EXT                         0x8DB9
61
62Additions to Chapter 3 of the 3.0 Specification (Rasterization)
63
64    None
65
66Additions to Chapter 4 of the 3.0 Specification (Per-Fragment Operations and
67the Framebuffer)
68
69Modify Section 4.1.7: Blending
70
71    If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
72    attachment corresponding to the destination buffer is SRGB (see section
73    6.1.13) and FRAMEBUFFER_SRGB_EXT is enabled, the R, G, and B
74    destination color values (after conversion from fixedpoint to
75    floating-point) are considered to be encoded for the sRGB color space and
76    hence must be linearized prior to their use in blending. Each R, G, and B
77    component is converted in the same fashion described for sRGB texture
78    components in section 3.8.16.
79    If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB, or
80    FRAMEBUFFER_SRGB_EXT is disabled, no linearization is performed.
81
82Modify Section 4.1.8: sRGB Conversion
83
84    If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
85    attachment corresponding to the destination buffer is SRGB (see section
86    6.1.13) and FRAMEBUFFER_SRGB_EXT is enabled, the R, G, and B
87    values after blending are converted into the non-linear sRGB color space by
88    computing
89
90             {  0.0,                          0         <= cl
91             {  12.92 * c,                    0         <  cl < 0.0031308
92        cs = {  1.055 * cl^0.41666 - 0.055,   0.0031308 <= cl < 1
93             {  1.0,                                       cl >= 1
94
95    where cl is the R, G, or B element and cs is the result (effectively
96    converted into an sRGB color space).
97
98Modify Section 4.3.2: Copying Pixels
99
100    When values are taken from the read buffer, if the value of FRAMEBUFFER_-
101    ATTACHMENT_COLOR_ENCODING for the framebuffer attachment corresponding to
102    the read buffer is SRGB (see section 6.1.13), the red, green, and blue
103    components are converted from the non-linear sRGB color space according to
104    equation 3.24 if FRAMEBUFFER_SRGB_EXT is enabled.
105
106Interactions with OpenGL ES 2.0 and EXT_sRGB:
107
108    In the case of not working with OpenGL ES 3.0, sRGB conversion is dictacted
109    by EXT_sRGB. The following changes should be made to EXT_sRGB to support
110    this extension properly in this case:
111
112    In "Additions to Chapter 4 of the Specification", the third paragraph after
113    "with the following sentences", the following excerpt should be changed
114    from:
115
116        If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT is not SRGB,
117        no linearization is performed.
118
119    to:
120
121        If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT is not SRGB,
122        or FRAMEBUFFER_SRGB_EXT is disabled, no linearization is performed.
123
124    In the "ADD new section 4.1.X..." section, change the first paragraph which
125    reads:
126
127        "If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the
128        framebuffer attachment corresponding to the destination buffer is SRGB,
129        the R, G, and B values after blending are converted into the non-linear
130        sRGB color space by computing:
131
132             {  0.0,                          cl        <= 0
133             {  12.92 * c,                    0         <  cl < 0.0031308
134        cs = {  1.055 * cl^0.41666 - 0.055,   0.0031308 <= cl < 1
135             {  1.0,                                       cl >= 1
136
137        where cl is the R, G, or B element and cs is the result (effectively
138        converted into an sRGB color space).
139
140    to:
141
142        "If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT for the
143        framebuffer attachment corresponding to the destination buffer is SRGB,
144        and FRAMEBUFFER_SRGB_EXT is enabled, the R, G, and B values after
145        blending are converted into the non-linear sRGB color space by
146        computing:
147
148             {  0.0,                          cl        <= 0
149             {  12.92 * c,                    0         <  cl < 0.0031308
150        cs = {  1.055 * cl^0.41666 - 0.055,   0.0031308 <= cl < 1
151             {  1.0,                                       cl >= 1
152
153        where cl is the R, G, or B element and cs is the result (effectively
154        converted into an sRGB color space).
155
156    and after the second paragraph, before the following:
157
158        The following should be added to table 4.5 Renderbuffer Image formats:
159        SRGB8_ALPHA8_EXT     color_renderable 8  8  8  8  -  -
160
161    add:
162
163        If FRAMEBUFFER_SRGB_EXT is disabled, no conversion into linear space
164        will occur.
165
166Errors
167
168    Relaxation of INVALID_ENUM errors
169    ---------------------------------
170
171    Enable, Disable, IsEnabled, GetBooleanv, GetFloatv, GetIntegerv and
172    GetInteger64v now accept the new token as allowed in the "New Tokens"
173    section.
174
175New State
176
177    Add to table 6.11 (Pixel Operations)
178
179    Get Value             Type  Get Command  Initial Value  Description      Sec.   Attribute
180    --------------------  ----  -----------  -------------  ---------------  -----  -------------------
181    FRAMEBUFFER_SRGB_EXT  B     IsEnabled    True           sRGB update and  4.1.X  color-buffer/enable
182                                                            blending enable
183
184New Implementation Dependent State
185
186    None
187
188Issues
189
190    1)  What should this extension be called?
191
192        As a place holder we are using: EXT_sRGB_write_control
193
194        This was chosen because EXT_framebuffer_sRGB does not make it
195        immediately obvious that this extension is only dealing with operations
196        after the pixel path, and EXT_sRGB_write_control seems more clear. The
197        original is named with ARB, ARB_framebuffer_sRGB, so it may also make
198        sense to change the name to EXT_framebuffer_sRGB.
199
200    2)  How is sRGB blending done in the default state (FRAMEBUFFER_SRGB_EXT
201        is enabled)?
202
203        RESOLVED:  Blending is a linear operation so should be performed
204        on values in linear spaces.  sRGB-encoded values are in a
205        non-linear space so sRGB blending should convert sRGB-encoded
206        values from the framebuffer to linear values, blend, and then
207        sRGB-encode the result to store it in the framebuffer.
208
209        The destination color RGB components are each converted
210        from sRGB to a linear value.  Blending is then performed.
211        The source color and constant color are simply assumed to be
212        treated as linear color components.  Then the result of blending
213        is converted to an sRGB encoding and stored in the framebuffer.
214
215    3)  How are multiple render targets handled?
216
217        RESOLVED:  Render targets that are not sRGB capable ignore the
218        state of the GL_FRAMEBUFFER_SRGB_EXT enable for sRGB update and
219        blending. So only the render targets that are sRGB-capable perform
220        sRGB blending and update when GL_FRAMEBUFFER_SRGB_EXT is enabled.
221
222    4)  Why is the sRGB framebuffer GL_FRAMEBUFFER_SRGB_EXT enabled by default?
223
224        Based on the the GLES 3.0 spec, if this conversion choice is disabled
225        by default then current apps which expect this conversion to happen
226        will be broken and the output will not look as intended.
227
228    5)  FRAMEBUFFER_SRGB seems concerned with writing to sRGB framebuffers and
229        blending operations. How do we want to handle the operations which
230        include reading from a framebuffer, such as glBlitFramebuffer,
231        glReadPixels, or glCopyTexImage?
232
233        This flag will affect glBlitFramebuffer, but will not affect
234        glReadPixels or glCopyTex[Sub]Image.
235
236        If the implementation does not support OpenGL ES 3.0 and instead
237        supports OpenGL 2.0 and EXT_sRGB, references to glBlitFramebuffer can
238        be ignored. However, the above will be true if the implementation
239        supports NV_framebuffer_blit.
240
241    6) How does this extension interact with multisampling?
242
243        RESOLVED:  There are no explicit interactions.  However, arguably
244        if the color samples for multisampling are sRGB encoded, the
245        samples should be linearized before being "resolved" for display
246        and then recoverted to sRGB if the output device expects sRGB
247        encoded color components.
248
249        This is really a video scan-out issue and beyond the scope
250        of this extension which is focused on the rendering issues.
251        However some implementation advice is provided:
252
253        The implementation sufficiently aware of the gamma correction
254        configured for the display device could decide to perform an
255        sRGB-correct multisample resolve.  Whether this occurs or not
256        could be determined by a control panel setting or inferred by
257        the application's use of this extension.
258
259Revision History
260  #02    8/05/2013    Matt Trusten     Minor bug fixes
261                                       Added multisampling issue from
262                                         ARB_framebuffer_sRGB
263
264  #01    6/04/2013    Matt Trusten     First draft.
265