NV_blend_equation_advanced
Name
NV_blend_equation_advanced
Name Strings
GL_NV_blend_equation_advanced
GL_NV_blend_equation_advanced_coherent
Contact
Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
Contributors
Jeff Bolz, NVIDIA Corporation
Mathias Heyer, NVIDIA Corporation
Mark Kilgard, NVIDIA Corporation
Daniel Koch, NVIDIA Corporation
Rik Cabanier, Adobe
Status
NV_blend_equation_advanced is released in NVIDIA Driver Release
326.xx (June 2013).
Version
Last Modified Date: February 14, 2018
NVIDIA Revision: 10
Number
OpenGL Extension #433
OpenGL ES Extension #163
Dependencies
This extension is written against the OpenGL 4.1 Specification
(Compatibility Profile).
OpenGL 2.0 is required (for Desktop).
OpenGL ES 2.0 is required (for mobile).
EXT_blend_minmax is required (for mobile).
This extension interacts with OpenGL 4.0.
This extension interacts with OpenGL 4.1 (Core Profile).
This extension interacts with OpenGL 4.3 or later.
This extension interacts with OpenGL ES 2.0.
This extension interacts with OpenGL ES 3.0.
This extension interacts with NV_path_rendering.
Overview
This extension adds a number of "advanced" blending equations that can be
used to perform new color blending operations, many of which are more
complex than the standard blend modes provided by unextended OpenGL. This
extension provides two different extension string entries:
- NV_blend_equation_advanced: Provides the new blending equations, but
guarantees defined results only if each sample is touched no more than
once in any single rendering pass. The command BlendBarrierNV() is
provided to indicate a boundary between passes.
- NV_blend_equation_advanced_coherent: Provides the new blending
equations, and guarantees that blending is done coherently and in API
primitive ordering. An enable is provided to allow implementations to
opt out of fully coherent blending and instead behave as though only
NV_blend_equation_advanced were supported.
Some implementations may support NV_blend_equation_advanced without
supporting NV_blend_equation_advanced_coherent.
In unextended OpenGL, the set of blending equations is limited, and can be
expressed very simply. The MIN and MAX blend equations simply compute
component-wise minimums or maximums of source and destination color
components. The FUNC_ADD, FUNC_SUBTRACT, and FUNC_REVERSE_SUBTRACT
multiply the source and destination colors by source and destination
factors and either add the two products together or subtract one from the
other. This limited set of operations supports many common blending
operations but precludes the use of more sophisticated transparency and
blending operations commonly available in many dedicated imaging APIs.
This extension provides a number of new "advanced" blending equations.
Unlike traditional blending operations using the FUNC_ADD equation, these
blending equations do not use source and destination factors specified by
BlendFunc. Instead, each blend equation specifies a complete equation
based on the source and destination colors. These new blend equations are
used for both RGB and alpha components; they may not be used to perform
separate RGB and alpha blending (via functions like
BlendEquationSeparate).
These blending operations are performed using premultiplied colors, where
RGB colors stored in the framebuffer are considered to be multiplied by
alpha (coverage). The fragment color may be considered premultiplied or
non-premultiplied, according the BLEND_PREMULTIPLIED_SRC_NV blending
parameter (as specified by the new BlendParameteriNV function). If
fragment color is considered non-premultiplied, the (R,G,B) color
components are multiplied by the alpha component prior to blending. For
non-premultiplied color components in the range [0,1], the corresponding
premultiplied color component would have values in the range [0*A,1*A].
Many of these advanced blending equations are formulated where the result
of blending source and destination colors with partial coverage have three
separate contributions: from the portions covered by both the source and
the destination, from the portion covered only by the source, and from the
portion covered only by the destination. The blend parameter
BLEND_OVERLAP_NV can be used to specify a correlation between source and
destination pixel coverage. If set to CONJOINT_NV, the source and
destination are considered to have maximal overlap, as would be the case
if drawing two objects on top of each other. If set to DISJOINT_NV, the
source and destination are considered to have minimal overlap, as would be
the case when rendering a complex polygon tessellated into individual
non-intersecting triangles. If set to UNCORRELATED_NV (default), the
source and destination coverage are assumed to have no spatial correlation
within the pixel.
In addition to the coherency issues on implementations not supporting
NV_blend_equation_advanced_coherent, this extension has several
limitations worth noting. First, the new blend equations are not
supported while rendering to more than one color buffer at once; an
INVALID_OPERATION will be generated if an application attempts to render
any primitives in this unsupported configuration. Additionally, blending
precision may be limited to 16-bit floating-point, which could result in a
loss of precision and dynamic range for framebuffer formats with 32-bit
floating-point components, and in a loss of precision for formats with 12-
and 16-bit signed or unsigned normalized integer components.
New Procedures and Functions
void BlendParameteriNV(enum pname, int value);
void BlendBarrierNV(void);
New Tokens
Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, and by
the <pname> parameter of GetIntegerv, GetBooleanv, GetFloatv, GetDoublev
and GetInteger64v:
BLEND_ADVANCED_COHERENT_NV 0x9285
Note: The BLEND_ADVANCED_COHERENT_NV enable is provided if and only if
the NV_blend_equation_advanced_coherent extension is supported. On
implementations supporting only NV_blend_equation_advanced, this enable is
considered not to exist.
Accepted by the <pname> parameter of BlendParameteriNV, GetBooleanv,
GetIntegerv, GetInteger64v, GetFloatv, and GetDoublev:
BLEND_PREMULTIPLIED_SRC_NV 0x9280
BLEND_OVERLAP_NV 0x9281
Accepted by the <value> parameter of BlendParameteriNV when <pname> is
BLEND_PREMULTIPLIED_SRC_NV:
TRUE
FALSE
Accepted by the <value> parameter of BlendParameteriNV when <pname> is
BLEND_OVERLAP_NV:
UNCORRELATED_NV 0x9282
DISJOINT_NV 0x9283
CONJOINT_NV 0x9284
Accepted by the <mode> parameter of BlendEquation and BlendEquationi:
ZERO // reused from core
SRC_NV 0x9286
DST_NV 0x9287
SRC_OVER_NV 0x9288
DST_OVER_NV 0x9289
SRC_IN_NV 0x928A
DST_IN_NV 0x928B
SRC_OUT_NV 0x928C
DST_OUT_NV 0x928D
SRC_ATOP_NV 0x928E
DST_ATOP_NV 0x928F
XOR_NV 0x1506
MULTIPLY_NV 0x9294
SCREEN_NV 0x9295
OVERLAY_NV 0x9296
DARKEN_NV 0x9297
LIGHTEN_NV 0x9298
COLORDODGE_NV 0x9299
COLORBURN_NV 0x929A
HARDLIGHT_NV 0x929B
SOFTLIGHT_NV 0x929C
DIFFERENCE_NV 0x929E
EXCLUSION_NV 0x92A0
INVERT // reused from core
INVERT_RGB_NV 0x92A3
LINEARDODGE_NV 0x92A4
LINEARBURN_NV 0x92A5
VIVIDLIGHT_NV 0x92A6
LINEARLIGHT_NV 0x92A7
PINLIGHT_NV 0x92A8
HARDMIX_NV 0x92A9
HSL_HUE_NV 0x92AD
HSL_SATURATION_NV 0x92AE
HSL_COLOR_NV 0x92AF
HSL_LUMINOSITY_NV 0x92B0
PLUS_NV 0x9291
PLUS_CLAMPED_NV 0x92B1
PLUS_CLAMPED_ALPHA_NV 0x92B2
PLUS_DARKER_NV 0x9292
MINUS_NV 0x929F
MINUS_CLAMPED_NV 0x92B3
CONTRAST_NV 0x92A1
INVERT_OVG_NV 0x92B4
RED_NV 0x1903
GREEN_NV 0x1904
BLUE_NV 0x1905
NOTE: These enums are not accepted by the <modeRGB> or <modeAlpha>
parameters of BlendEquationSeparate or BlendEquationSeparatei.
NOTE: The tokens XOR_NV, RED_NV, GREEN_NV, and BLUE_NV have the same
values as core OpenGL API enumerants with names without the "_NV"
suffixes. Either #define can be used, but the non-suffixed #defines are
not available in OpenGL ES 2.0 and XOR is not available in OpenGL ES 3.0.
Additions to Chapter 2 of the OpenGL 4.1 Specification (OpenGL Operation)
None.
Additions to Chapter 3 of the OpenGL 4.1 Specification (Rasterization)
None.
Additions to Chapter 4 of the OpenGL 4.1 Specification (Per-Fragment Operations and the Frame Buffer)
Modify Section 4.1.8, Blending (p. 359).
(modify the first paragraph, p. 361, allowing for new values in the
<mode> parameter) ... <modeRGB> and <modeAlpha> must be one of
FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT, MIN, or MAX as listed
in Table 4.1. <mode> must be one of the values in Table 4.1,
or one of the blend equations listed in tables X.2, X.3, and X.4. ...
(modify the third paragraph, p. 361, specifying minimum precision and
dynamic range for blend operations) ... Blending computations are treated
as if carried out in floating-point. For the equations in table 4.1,
blending computations will be performed with a precision and dynamic range
no lower than that used to represent destination components. For the
equations in table X.2, X.3, and X.4, blending computations will be
performed with a precision and dynamic range no lower than the smaller of
that used to represent destination components or that used to represent
16-bit floating-point values as described in section 2.1.1.
(add unnumbered subsection prior to "Dual Source Blending and Multiple
Draw Buffers", p. 363)
Advanced Blend Equations
The advanced blend equations are those listed in tables X.2, X.3, and X.4.
Parameters related to the advanced blend equations can be set by calling
void BlendParameteriNV(enum pname, int param);
with <pname> set to BLEND_PREMULTIPLIED_SRC_NV or BLEND_OVERLAP_NV. When
<pname> is BLEND_PREMULTIPLIED_SRC_NV, the valid values for <param> are
TRUE or FALSE. When <pname> is BLEND_OVERLAP_NV, the valid values for
<param> are UNCORRELATED_NV, CONJOINT_NV, and DISJOINT_NV. An
INVALID_ENUM error is generated if <pname> is not
BLEND_PREMULTIPLIED_SRC_NV or BLEND_OVERLAP_NV, or if <param> is not a
legal value for <pname>.
When using one of the equations in table X.2 or X.3, blending is performed
according to the following equations:
R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad)
G = f(Gs',Gd')*p0(As,Ad) + Y*Gs'*p1(As,Ad) + Z*Gd'*p2(As,Ad)
B = f(Bs',Bd')*p0(As,Ad) + Y*Bs'*p1(As,Ad) + Z*Bd'*p2(As,Ad)
A = X*p0(As,Ad) + Y*p1(As,Ad) + Z*p2(As,Ad)
where the function f and terms X, Y, and Z are specified in the table.
The R, G, and B components of the source color used for blending are
derived according to the premultiplied source color blending parameter,
which is set by calling BlendParameteriNV with <pname> set to
BLEND_PREMULTIPLIED_SRC_NV, and <param> set to TRUE or FALSE.
If the parameter is set to TRUE, the fragment color components are
considered to have been premultiplied by the A component prior to
blending. The base source color (Rs',Gs',Bs') is obtained by dividing
through by the A component:
(Rs', Gs', Bs') =
(0, 0, 0), if As == 0
(Rs/As, Gs/As, Bs/As), otherwise
If the premultiplied source color parameter is FALSE, the fragment color
components are used as the base color:
(Rs', Gs', Bs') = (Rs, Gs, Bs)
The destination color components are always considered to have been
premultiplied by the destination A component and the base destination
color (Rd', Gd', Bd') is obtained by dividing through by the A component:
(Rd', Gd', Bd') =
(0, 0, 0), if Ad == 0
(Rd/Ad, Gd/Ad, Bd/Ad), otherwise
When blending using advanced blend equations, we expect that the R, G, and
B components of premultiplied source and destination color inputs be
stored as the product of non-premultiplied R, G, and B component values
and the A component of the color. If any R, G, or B component of a
premultiplied input color is non-zero and the A component is zero, the
color is considered ill-formed, and the corresponding component of the
blend result will be undefined.
The weighting functions p0, p1, and p2 are defined in table X.1. In these
functions, the A components of the source and destination colors are taken
to indicate the portion of the pixel covered by the fragment (source) and
the fragments previously accumulated in the pixel (destination). The
functions p0, p1, and p2 approximate the relative portion of the pixel
covered by the intersection of the source and destination, covered only by
the source, and covered only by the destination, respectively. These
functions are specified by the blend overlap parameter, which can be set
by calling BlendParameteriNV with <pname> set to BLEND_OVERLAP_NV. <param>
can be one of UNCORRELATED_NV (default), CONJOINT_NV, and DISJOINT_NV.
UNCORRELATED_NV indicates that there is no correlation between the source
and destination coverage. CONJOINT_NV and DISJOINT_NV indicate that the
source and destination coverage are considered to have maximal or minimal
overlap, respectively.
Overlap Mode Weighting Equations
--------------- --------------------------
UNCORRELATED_NV p0(As,Ad) = As*Ad
p1(As,Ad) = As*(1-Ad)
p2(As,Ad) = Ad*(1-As)
CONJOINT_NV p0(As,Ad) = min(As,Ad)
p1(As,Ad) = max(As-Ad,0)
p2(As,Ad) = max(Ad-As,0)
DISJOINT_NV p0(As,Ad) = max(As+Ad-1,0)
p1(As,Ad) = min(As,1-Ad)
p2(As,Ad) = min(Ad,1-As)
Table X.1, Advanced Blend Overlap Modes
Mode Blend Coefficients
-------------------- -----------------------------------
ZERO (X,Y,Z) = (0,0,0)
f(Cs,Cd) = 0
SRC_NV (X,Y,Z) = (1,1,0)
f(Cs,Cd) = Cs
DST_NV (X,Y,Z) = (1,0,1)
f(Cs,Cd) = Cd
SRC_OVER_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = Cs
DST_OVER_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = Cd
SRC_IN_NV (X,Y,Z) = (1,0,0)
f(Cs,Cd) = Cs
DST_IN_NV (X,Y,Z) = (1,0,0)
f(Cs,Cd) = Cd
SRC_OUT_NV (X,Y,Z) = (0,1,0)
f(Cs,Cd) = 0
DST_OUT_NV (X,Y,Z) = (0,0,1)
f(Cs,Cd) = 0
SRC_ATOP_NV (X,Y,Z) = (1,0,1)
f(Cs,Cd) = Cs
DST_ATOP_NV (X,Y,Z) = (1,1,0)
f(Cs,Cd) = Cd
XOR_NV (X,Y,Z) = (0,1,1)
f(Cs,Cd) = 0
MULTIPLY_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = Cs*Cd
SCREEN_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = Cs+Cd-Cs*Cd
OVERLAY_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = 2*Cs*Cd, if Cd <= 0.5
1-2*(1-Cs)*(1-Cd), otherwise
DARKEN_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = min(Cs,Cd)
LIGHTEN_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = max(Cs,Cd)
COLORDODGE_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
0, if Cd <= 0
min(1,Cd/(1-Cs)), if Cd > 0 and Cs < 1
1, if Cd > 0 and Cs >= 1
COLORBURN_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
1, if Cd >= 1
1 - min(1,(1-Cd)/Cs), if Cd < 1 and Cs > 0
0, if Cd < 1 and Cs <= 0
HARDLIGHT_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = 2*Cs*Cd, if Cs <= 0.5
1-2*(1-Cs)*(1-Cd), otherwise
SOFTLIGHT_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
Cd-(1-2*Cs)*Cd*(1-Cd),
if Cs <= 0.5
Cd+(2*Cs-1)*Cd*((16*Cd-12)*Cd+3),
if Cs > 0.5 and Cd <= 0.25
Cd+(2*Cs-1)*(sqrt(Cd)-Cd),
if Cs > 0.5 and Cd > 0.25
DIFFERENCE_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = abs(Cd-Cs)
EXCLUSION_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = Cs+Cd-2*Cs*Cd
INVERT (X,Y,Z) = (1,0,1)
f(Cs,Cd) = 1-Cd
INVERT_RGB_NV (X,Y,Z) = (1,0,1)
f(Cs,Cd) = Cs*(1-Cd)
LINEARDODGE_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
Cs+Cd, if Cs+Cd<=1
1, otherwise
LINEARBURN_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
Cs+Cd-1, if Cs+Cd>1
0, otherwise
VIVIDLIGHT_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
1-min(1,(1-Cd)/(2*Cs)), if 0 < Cs < 0.5
0, if Cs <= 0
min(1,Cd/(2*(1-Cs))), if 0.5 <= Cs < 1
1, if Cs >= 1
LINEARLIGHT_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
1, if 2*Cs+Cd>2
2*Cs+Cd-1, if 1 < 2*Cs+Cd <= 2
0, if 2*Cs+Cd<=1
PINLIGHT_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) =
0, if 2*Cs-1>Cd and Cs<0.5
2*Cs-1, if 2*Cs-1>Cd and Cs>=0.5
2*Cs, if 2*Cs-1<=Cd and Cs<0.5*Cd
Cd, if 2*Cs-1<=Cd and Cs>=0.5*Cd
???
HARDMIX_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = 0, if Cs+Cd<1
1, otherwise
Table X.2, Advanced Blend Equations
When using one of the HSL blend equations in table X.3 as the blend
equation, the RGB color components produced by the function f() are
effectively obtained by converting both the non-premultiplied source and
destination colors to the HSL (hue, saturation, luminosity) color space,
generating a new HSL color by selecting H, S, and L components from the
source or destination according to the blend equation, and then converting
the result back to RGB. The HSL blend equations are only well defined
when the values of the input color components are in the range [0..1].
In the equations below, a blended RGB color is produced according to the
following pseudocode:
float minv3(vec3 c) {
return min(min(c.r, c.g), c.b);
}
float maxv3(vec3 c) {
return max(max(c.r, c.g), c.b);
}
float lumv3(vec3 c) {
return dot(c, vec3(0.30, 0.59, 0.11));
}
float satv3(vec3 c) {
return maxv3(c) - minv3(c);
}
// If any color components are outside [0,1], adjust the color to
// get the components in range.
vec3 ClipColor(vec3 color) {
float lum = lumv3(color);
float mincol = minv3(color);
float maxcol = maxv3(color);
if (mincol < 0.0) {
color = lum + ((color-lum)*lum) / (lum-mincol);
}
if (maxcol > 1.0) {
color = lum + ((color-lum)*(1-lum)) / (maxcol-lum);
}
return color;
}
// Take the base RGB color <cbase> and override its luminosity
// with that of the RGB color <clum>.
vec3 SetLum(vec3 cbase, vec3 clum) {
float lbase = lumv3(cbase);
float llum = lumv3(clum);
float ldiff = llum - lbase;
vec3 color = cbase + vec3(ldiff);
return ClipColor(color);
}
// Take the base RGB color <cbase> and override its saturation with
// that of the RGB color <csat>. The override the luminosity of the
// result with that of the RGB color <clum>.
vec3 SetLumSat(vec3 cbase, vec3 csat, vec3 clum)
{
float minbase = minv3(cbase);
float sbase = satv3(cbase);
float ssat = satv3(csat);
vec3 color;
if (sbase > 0) {
// Equivalent (modulo rounding errors) to setting the
// smallest (R,G,B) component to 0, the largest to <ssat>,
// and interpolating the "middle" component based on its
// original value relative to the smallest/largest.
color = (cbase - minbase) * ssat / sbase;
} else {
color = vec3(0.0);
}
return SetLum(color, clum);
}
Mode Result
-------------------- ----------------------------------------
HSL_HUE_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = SetLumSat(Cs,Cd,Cd);
HSL_SATURATION_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = SetLumSat(Cd,Cs,Cd);
HSL_COLOR_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = SetLum(Cs,Cd);
HSL_LUMINOSITY_NV (X,Y,Z) = (1,1,1)
f(Cs,Cd) = SetLum(Cd,Cs);
Table X.3, Hue-Saturation-Luminosity Advanced Blend Equations
When using one of the equations in table X.4 as the blend equation, the
source color used by these blending equations is interpreted according to
the BLEND_PREMULTIPLIED_SRC_NV blending parameter. The blending equations
below are evaluated where the RGB source and destination color components
are both considered to have been premultiplied by the corresponding A
component.
(Rs', Gs', Bs') =
(Rs, Gs, Bs), if BLEND_PREMULTIPLIED_SRC_NV is TRUE
(Rs*As, Gs*As, Bs*As), if BLEND_PREMULTIPLIED_SRC_NV is FALSE
Mode Result
-------------------- ----------------------------------------
PLUS_NV (R,G,B,A) = (Rs'+Rd, Gs'+Gd, Bs'+Bd,As'+Ad)
PLUS_CLAMPED_NV (R,G,B,A) =
(min(1,Rs'+Rd), min(1,Gs'+Gd),
min(1,Bs'+Bd), min(1,As+Ad))
PLUS_CLAMPED_ALPHA_NV (R,G,B,A) =
(min(min(1,As+Ad),Rs'+Rd),
min(min(1,As+Ad),Gs'+Gd),
min(min(1,As+Ad),Bs'+Bd), min(1,As+Ad))
PLUS_DARKER_NV (R,G,B,A) =
(max(0,min(1,As+Ad)-((As-Rs')+(Ad-Rd))),
max(0,min(1,As+Ad)-((As-Gs')+(Ad-Gd))),
max(0,min(1,As+Ad)-((As-Bs')+(Ad-Bd))),
min(1,As+Ad))
MINUS_NV (R,G,B,A) = (Rd-Rs', Gd-Gs', Bd-Bs', Ad-As)
MINUS_CLAMPED_NV (R,G,B,A) =
(max(0,Rd-Rs'), max(0,Gd-Gs'),
max(0,Bd-Bs'), max(0,Ad-As))
CONTRAST_NV (R,G,B,A) =
(Ad/2 + 2*(Rd-Ad/2)*(Rs'-As/2),
Ad/2 + 2*(Gd-Ad/2)*(Gs'-As/2),
Ad/2 + 2*(Bd-Ad/2)*(Bs'-As/2),
Ad)
INVERT_OVG_NV (R,G,B,A) =
(As*(1-Rd)+(1-As)*Rd,
As*(1-Gd)+(1-As)*Gd,
As*(1-Bd)+(1-As)*Bd,
As+Ad-As*Ad)
RED_NV (R,G,B,A) = (Rs', Gd, Bd, Ad)
GREEN_NV (R,G,B,A) = (Rd, Gs', Bd, Ad)
BLUE_NV (R,G,B,A) = (Rd, Gd, Bs', Ad)
Table X.4, Additional RGB Blend Equations
Advanced blending equations are supported only when rendering to a single
color buffer using fragment color zero. If any non-NONE draw buffer uses
a blend equation found in table X.2, X.3, or X.4, the error
INVALID_OPERATION is generated by [[Compatibility Profile: Begin or any
operation that implicitly calls Begin (such as DrawElements)]] [[Core
Profile: DrawArrays and the other drawing commands defined in section
2.8.3]] if:
* the draw buffer for color output zero selects multiple color buffers
(e.g., FRONT_AND_BACK in the default framebuffer); or
* the draw buffer for any other color output is not NONE.
[[ The following paragraph applies to NV_blend_equation_advanced only. ]]
When using advanced blending equations, applications should split their
rendering into a collection of blending passes, none of which touch an
individual sample more than once. The results of blending are undefined
if the sample being blended has been touched previously in the same pass.
The command
void BlendBarrierNV(void);
specifies a boundary between passes when using advanced blend equations.
Any command that causes the value of a sample to be modified is considered
to touch the sample, including clears, blended or unblended primitives,
BlitFramebuffer copies, and direct updates by commands such as
TexSubImage2D.
[[ The following paragraph applies to NV_blend_equation_advanced_coherent
only. ]]
When using advanced blending equations, blending is typically done
coherently and in primitive order. When an individual sample is covered
by multiple primitives, blending for that sample is performed sequentially
in the order in which the primitives were submitted. This coherent
blending is enabled by default, but can be enabled or disabled by calling
Enable or Disable with the symbolic constant BLEND_ADVANCED_COHERENT_NV.
If coherent blending is disabled, applications should split their
rendering into a collection of blending passes, none of which touch an
individual sample more than once. When coherent blending is disabled, the
results of blending are undefined if the sample being blended has been
touched previously in the same pass. The command
void BlendBarrierNV(void);
specifies a boundary between passes when using advanced blend equations.
Any command that causes the value of a sample to be modified is considered
to touch the sample, including clears, blended or unblended primitives,
BlitFramebuffer copies, and direct updates by commands such as
TexSubImage2D.
Additions to Chapter 5 of the OpenGL 4.1 Specification (Special Functions)
None.
Additions to Chapter 6 of the OpenGL 4.1 Specification (State and State Requests)
None.
Additions to Appendix A of the OpenGL 4.1 Specification (Invariance)
None.
Additions to the AGL/GLX/WGL/EGL Specifications
None.
GLX Protocol
!!! TBD
Dependencies on OpenGL 4.0
If OpenGL 4.0 is not supported, references to the BlendEquationi API should
be removed.
Dependencies on OpenGL 4.1 (Core Profile)
This extension throws an INVALID_OPERATION when Begin is called if advanced
blend equations are used in conjunction with multiple draw buffers. For
the core profile of OpenGL 4.1 (and other versions of OpenGL), there is no
Begin command; instead, the error is thrown by other rendering commands
such as DrawArrays. The language in this specification documenting the
error has separate versions for the core and compatibility profiles.
Dependencies on OpenGL 4.3 or later (any Profile)
References to Chapter 4 are replaced with references to Chapter 17 (Writing
Fragments and Samples to the Framebuffer).
References to section 4.1.8 are replaced with references to section 17.3.8.
References to Table 4.1 are replace with references to Table 17.1.
References to section 2.1.1 are replaced with references to section 2.3.3.
Dependencies on OpenGL ES 2.0
If unextended OpenGL ES 2.0 is supported, references to BlendEquationi,
BlendEquationSeparatei, GetInteger64v, and GetDoublev should be ignored.
Ignore any references to multiple draw buffers if EXT_draw_buffers or
NV_draw_buffers is not supported.
Dependencies on EXT_blend_minmax
Requires EXT_blend_minmax on OpenGL ES 2.0 implementations and references
to MIN and MAX should be replace by references to MIN_EXT and MAX_EXT as
introduced by that extension.
Dependencies on OpenGL ES 3.0
If unextended OpenGL ES 3.0 is supported, references to BlendEquationi,
BlendEquationSeparatei, and GetDoublev should be ignored.
Dependencies on NV_path_rendering
When NV_path_rendering is supported, covering geometry generated by the
commands CoverFillPathNV, CoverFillPathInstancedNV, CoverStrokePathNV, and
CoverStrokePathInstancedNV will automatically be blended coherently
relative to previous geometry when using the blend equations in this
extension. This guarantee is provided even on implementations supporting
only NV_blend_equation_advanced.
Insert the following language after the discussion of the BlendBarrierNV()
command for both extensions:
[[ For NV_blend_equation_advanced only: ]]
The commands CoverFillPathNV, CoverFillPathInstancedNV,
CoverStrokePathNV, and CoverStrokePathInstancedNV are considered to
start a new blending pass, as though BlendBarrierNV were called prior to
the cover operation. If a cover primitive is followed by subsequent
non-cover primitives using advanced blend equations and touching the
same samples, applications must call BlendBarrierNV after the cover
primitives to ensure defined blending results.
[[ For NV_blend_equation_advanced_coherent, the language immediately
above should be used, but the first sentence should be prefixed with
"When coherent blending is disabled, ...". ]]
Errors
If any non-NONE draw buffer uses a blend equation found in table X.2, X.3,
or X.4, the error INVALID_OPERATION is generated by Begin or any operation
that implicitly calls Begin (such as DrawElements) if:
* the draw buffer for color output zero selects multiple color buffers
(e.g., FRONT_AND_BACK in the default framebuffer); or
* the draw buffer for any other color output is not NONE.
If BlendParameteriNV is called and <pname> is not
BLEND_PREMULTIPLIED_SRC_NV or BLEND_OVERLAP_NV the error INVALID_ENUM is
generated.
If BlendParameteriNV is called with <pname> set to
BLEND_PREMULTIPLIED_SRC_NV the error INVALID_ENUM is generated if <param>
is not TRUE or FALSE.
If BlendParameteriNV is called with <pname> set to BLEND_OVERLAP_NV the
error INVALID_ENUM is generated if <param> is not one of UNCORRELATED_NV,
DISJOINT_NV, or CONJOINT_NV.
New State Initial Get Value Type Get Command Value Description Sec Attribute ——————– —- ———— ———— ———————— —– ———— BLEND_ADVANCED_ B IsEnabled TRUE are advanced blending 4.1.8 color-buffer COHERENT_NV equations guaranteed to be evaluated coherently? BLEND_PREMULTIPLIED_ B GetBooleanv TRUE use premultiplied src 4.1.8 color-buffer SRC_NV colors with advanced blend equations BLEND_OVERLAP_NV Z3 GetIntegerv UNCORRELATED correlation of src/dst 4.1.8 color-buffer _NV coverage within a pixel
Note: The BLEND_ADVANCED_COHERENT_NV enable is provided if and only if
the NV_blend_equation_advanced_coherent extension is supported. On
implementations supporting only NV_blend_equation_advanced, this enable is
considered not to exist.
New Implementation Dependent State
None.
NVIDIA Implementation Details
Older versions of this extension specification and early shipping
implementations supported the COLORDODGE_NV and COLORBURN_NV equations
without the special case discussed in issue (34). This should be fixed for
newer driver releases.
Issues
(1) How should these new blending operations be supported?
RESOLVED: Provide a separate blend equation for each of the various
blending operations.
(2) Many of these blending operations involve complicated computations on
the RGB color components, but corresponding alpha operations are
typically very simple. How should blending on the alpha channel work?
RESOLVED: Each new blend equation provides one equation for color and
another for alpha. In this extension, separate advanced blend equations
for color and alpha are not supported; BlendEquationSeparate does not
accept these enums.
This extension contemplated separate blend equations for RGB and alpha,
perhaps with only basic equations for alpha, but we chose to tie RGB and
alpha blending together for simplicity.
(3) Should we provide explicit support for premultiplied colors?
RESOLVED: Yes. Many of the imaging APIs supporting similar blend
equations use premultiplied colors, some exclusively. Additionally,
many equations are simpler to express and compute with premultiplied
colors.
In this extension, we choose to treat the destination colors and the
blend result as premultiplied. We considered providing a blend
parameter supporting non-premultiplied destinations, but chose to
support only premultiplied destinations for mathematical simplicity.
(4) Should we support blending where some, but not all, colors are
premultiplied? For example, there may be cases where the source
fragment colors are not premultiplied, but where the destination
colors are premultiplied.
RESOLVED: Yes, we will provide support for non-premultiplied fragment
colors (via a blending parameter), in which case the RGB color
components are multiplied by alpha prior to blending.
We considered requiring premultiplication in the fragment shader, but
opted to provide a fixed-function premultiply operation for cases where
it was inconvenient to modify the fragment shader to perform the
multiplication, or where no fragment shader is executed (e.g.,
fixed-function fragment processing, blits via the NV_draw_texture
extension).
(5) Should we support different types of correlation between source and
destination coverage in partially covered pixels? If so, how?
RESOLVED: We will provide a blend parameter allowing for multiple
versions of many blending equations based on the "correlation" between
source and destination coverage. For pixels with partial opacity, there
might be three different blend cases: (a) where the portions of the
pixel covered by the primitives are considered to have minimal overlap
(e.g., abutting primitives in a mesh), (b) where the portions of the
pixel covered by the primitives are considered to have maximal overlap
(e.g., overlapping geometry), (c) where the portions of the pixel
covered by the primitives are considered uncorrelated.
(6) Should we support swapping source and destination coverage in advanced
blends? If so, how?
RESOLVED: In the current version, we don't support fully general
swapping. We do provide several pairs of blend equations that are
equivalent, other than swapping source and destination colors. For
example, we provide complementary blend equations SRC_OVER_NV, where the
source color is considered to be "over" the destination, and
DST_OVER_NV, where the destination color is considered to be "over the
source. Having pairs of equations such as "SRC_OVER" and "DST_OVER"
seems to be common practice in various imaging APIs.
Alternately, we could provide a blend parameter that simply swaps source
and destination for arbitrary blend equations. In the example above, we
could provide a single blend equation OVER_NV, where the source color is
considered "over" when unswapped and the destination color is considered
"over" when swapped.
(7) Should we generalize the blending operation, replacing the notions of
"source" and "destination" colors with more generic "A" and "B"
parameters, which might be obtained from a variety of sources
(fragment color, one of <N> color attachment points, some additional
source of textures/images)?
RESOLVED: Not in this extension; the only blending operation we support
takes a fragment color (which could be obtained from an arbitrary
source, either through a fragment shader, fixed function fragment
processing, or an imaging API such as NV_draw_texture) and a destination
color, performs a blend, and stores the result in the buffer from which
the destination color was extracted.
(8) How should we expose the various combinations of blending modes?
RESOLVED: The base blending equation is specified by the same
BlendEquation() API supported for regular OpenGL blending. Additional
parameters (such as pre-multiplied source colors, overlap mode, source
destination swapping, input selection) can be specified via the
BlendParameteriNV() API.
We could provide for a "general" blend equation API specifying multiple
parameters at once, such as:
void BlendEquationGeneralNV(enum blend, enum overlap,
boolean swapSrcDst);
but that API would require applications to pass parameters that are
always the same (e.g., overlap as UNCORRELATED_NV) and wouldn't be
easily extensible. Note that there are several features that we've
chosen not to include but might be usefully added as blend parameters in
the future -- see issues (3), (6), and (7), for example.
(9) What limitations apply to the new blend modes?
RESOLVED: In the current implementation, these blend equations are not
supported with more than one color buffer; if this is attempted, a
draw-time error is generated. This limitation is similar in nature to
one for dual-source blending, which implementations are not required to
support in conjunction with multiple color buffers. This limitation may
be relaxed in a future version of this extension.
(10) What precision is used in the computations for these blending
equations?
RESOLVED: There are no minimum precision requirements specified in
OpenGL 4.1, though one would expect implementations to blend with at
least the precision used to store destination color components. This
extension provides this as a minimum baseline for existing blending
equations.
For the new equations, we specify a minimum precision that is the
smaller of the precision of the destination buffer or the precision of
16-bit floating-point computations. For most formats, this meets the
limit for basic blend equations. However, there may be precision loss
if these new blending equations are used with 12-bit unsigned normalized
components, 16-bit unsigned or signed normalized components, or 32-bit
floating-point components.
This restriction is specified so that implementations are not required
to support the large number of blending equations specified here with
full 32-bit floating-point computations.
(11) When targeting a fixed-point buffer, are input color components
clamped to [-1,1] for signed normalized color buffers or to [0,1] for
unsigned normalized color buffers?
RESOLVED: We will use the same clamping behavior as for basic blend
equations, where fragment color components are clamped to [0,1] prior to
blending for unsigned normalized color targets.
Note that the OpenGL 4.1 specification, against which this spec is
written, had an oversight related signed normalized color buffers. It
specifies [0,1] clamping for all "fixed point" targets, which is clearly
not desired for signed normalized color buffers. Fragment shader color
outputs should be clamped to [-1,+1] in this case; this was fixed in
OpenGL 4.2 (bug 6849).
(12) What happens when converting a premultiplied color with an alpha of
zero to a non-premultiplied color?
RESOLVED: We specify that a premultiplied color of (0,0,0,0) should
produce non-premultiplied (R,G,B) values of (0,0,0). A premultiplied
color with an alpha of zero and a non-zero R, G, or B component is
considered to be ill-formed and will produce undefined blending results.
For a non-premultiplied color (R',G',B',A'), the corresponding
premultiplied color (R,G,B,A) should satisfy the equation:
(R,G,B,A) = (R'*A', G'*A', B'*A', A')
If the alpha of a non-premultiplied color is zero, the corresponding
premultiplied color (R,G,B,A) should be (0,0,0,0).
We specify that ill-formed premultiplied colors produce undefined
blending results to enable certain performance optimizations. In many
of these blending equations, the alpha component used as a denominator
to compute the non-premultiplied color ends up being multiplied by the
same alpha component in the coverage, resulting in cancellation. For
example, implementations may want to substitute a premultiplied
destination color into the last term of the basic blend equation:
R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad)
= ... + Z*Rd'*(Ad*(1-As))
= ... + Z*(Rd'*Ad)*(1-As)
= ... + Z* Rd * (1-As)
This substitution would be invalid for ill-formed premultiplied
destination colors. We choose to specify undefined results for invalid
input colors rather than requiring implementations to skip such
optimizations or include logic to check for zero alpha values for each
input.
(13) Should we provide "advanced" RGB blend equations for modes commonly
used in dedicated imaging APIs that can already be expressed with
current OpenGL blending modes?
RESOLVED: Yes; we will provide a number of "advanced" blend equations
for basic computations that can be done with existing blend equations.
This allows applications wanting to use these advanced modes to use them
exclusively, without having to figure out which blends are not supported
and generate separate BlendEquation/BlendFunc state for each.
(14) How do the advanced RGB blend equations interact with sRGB color
buffers? In particular, how does it interact with storing
premultiplied color values in the framebuffer?
RESOLVED: When targeting an sRGB color buffer with the blend equations
in this extension, we will convert the destination colors from sRGB to
linear and will convert the linear blend result back to sRGB when
writing it to the framebuffer. This approach is no different from
regular blends.
sRGB conversions will affect premultiplied colors differently than
non-premultiplied colors since:
linear_to_srgb(C*A) != A * linear_to_srgb(C)
When storing an sRGB-encoded value into an sRGB texture or renderbuffer,
we expect that the values will be extracted as sRGB colors in a
subsequent texturing, blending, or display operation. The fetched sRGB
color components will be converted back to linear. Except from rounding
errors in converting the color components to fixed-point, converting to
and from sRGB will not modify the color, with or without
premultiplication.
(15) The HSL blend equations are "color surgery" operations where
components from the source and destination colors are mixed. Are
there any problems using these equations with premultiplied color
components?
RESOLVED: Like all of the "f/X/Y/Z" blends, the function f() in HSL
blend equations are expressed in terms of non-premultiplied colors,
which implies a division operation prior to evaluating f(). However, it
may be possible to perform some or all of the blending operation using
pre-multiplied colors directly. In particular, the luminosity and
saturation of a color with components scaled by alpha is equal to alpha
times the luminosity or saturation of the un-scaled color:
lumv3(C*A) = A * lumv3(C)
satv3(C*A) = A * satv3(C)
(16) How should we express the blending equations?
RESOLVED: In general, we will use the formulation found in the PDF and
SVG specifications, which define each blend in terms of four parameters:
* a function f(Cs,Cd) specifies the blended color contribution in the
portion of the pixel containing both the source and destination;
* a constant X specifies whether the region containing both the source
and destination contributes to the final alpha;
* a constant Y specifies whether the region containing only the source
contributes to the final color and alpha; and
* a constant Z specifies whether the region containing only the
destination contributes to the final color and alpha.
This formulation is relatively compact and nicely illustrates the
contributions from the three relevant combinations of source and
destination coverage; the portion of the pixel covered by neither the
source nor the destination contributes nothing to color or alpha.
Additionally, we specify three functions p0(As,Ad), p1(As,Ad), and
p2(As,Ad) specifying the relative portion of the pixel covered by both
the source and destination, just the source, and just the destination,
respectively. These functions are defined according to the overlap
blend parameter; the most common mode (UNCORRELATED) defines:
p0(As,Ad) = As*Ad
p1(As,Ad) = As*(1-Ad)
p2(As,Ad) = Ad*(1-As)
There are certain special-purpose blending equations that don't fit
this general model (modes that mix RGB or HSL components from the
source and destination). These blends don't fit nicely into the
mathematical formulas above and are instead defined separately as a
component-by-component operation.
(17) How should we express the equations for the HSL blend equations?
RESOLVED: The equations used by this specification are loosely adapted
from similar code in the version 1.7 of the PDF (Portable Document
Format) specification. The equations have been modified to use
GLSL-style "vec3" syntax. Additionally, they use vector math in the
pseudocode overriding the saturation of a base color instead of using
"C_min", "C_mid", and "C_max" syntax effectively defining references to
the three components of the base color.
Alternately, we could have specified functions for converting (R,G,B)
colors to and from an (H,S,L) color space. But we decided not to do
that because actual (H,S,L) colors are never used in the pipeline.
(18) What issues apply to the PLUS and MINUS equations?
RESOLVED: The PLUS and MINUS equations provide arithmetically simple
operations; we simply perform a component-wise add or subtract
operations. The most interesting question is how and where clamping is
performed. The original Porter-Duff compositing specification provided
a "plus" equation intended to support blending between two images,
effectively performing:
weight * image1 + (1-weight) * image2
If the components of <image1>, <image2>, and <weight> are all in [0,1],
there is no need for clamping. However, in a general add with no
<weight> built in, there is no guarantee that adding components of two
images will remain inside the range [0,1]. When using fixed-point
unsigned normalized color buffers, the sum will automatically be clamped
to [0,1] when stored in the framebuffer. However, there may be cases
with floating-point color buffers where not clamping the sum also makes
sense.
Additionally, when storing premultiplied colors, it may also be
desirable to clamp R/G/B components to the range [0,A]. Premultiplied
colors effectively store "R*A" in the R channel, where "R" is the
non-premultiplied color and A is alpha. Clamping this value to A
ensures that the non-premultiplied form of R is in [0,1].
To handle all possible cases, we provide five "PLUS" and "MINUS"
equations.
PLUS_NV: Add color and alpha components without clamping.
PLUS_CLAMPED_NV: Add color and alpha components; clamp each sum to
1.0.
PLUS_CLAMPED_ALPHA_NV: Add color and alpha components. Clamp the
alpha sum to 1.0; clamp the color sums to the alpha result (i.e., the
clamped alpha sum). Note that if premultiplied inputs are clamped
properly where 0<=R,G,B<=A, this equation isn't needed since the color
sums will always be less than the alpha sum.
MINUS_NV: Subtract the source color and alpha components from the
destination without clamping.
MINUS_CLAMPED_NV: Subtract the source color and alpha components from
the destination; clamp the difference to 0.0.
We don't bother clamping in "unexpected" direction. We don't bother
clamping sums to be greater than or equal to zero or differences to be
less than or equal to one; either case would require an unclamped input
with a negative component.
Note that when blending to an unsigned fixed-point buffer, the clamped
and non-clamped versions of "PLUS" and "MINUS" produce the same results,
since inputs and outputs are both clamped to [0,1].
Note that the LINEARDODGE_NV equation is another form of "PLUS"; in the
area of intersection, the source and destination colors are added and
clamped to 1.0.
(19) Should we provide a blend parameter to clamp the destination color
(when read) to [0,1]? What about clamping premultiplied RGB
components to [0,a]?
RESOLVED: No. We expect the most common use case to involve unsigned
normalized color buffers, where components will automatically be clamped
to [0,1] by virtue of how they're stored in the framebuffer. It doesn't
seem worth the trouble to add a clamp-on-read feature to clamp to [0,a]
when it seems easy enough to program colors to stay in range.
(20) Should we provide a blend parameter to clamp final color or alpha
output components to [0,1]? What about clamping premultiplied RGB
outputs to [0,a]?
RESOLVED: As above, when writing the blend results to unsigned
normalized targets, output components will automatically be clamped to
[0,1] by virtue of how they're stored in the framebuffer. It doesn't
seem worth the trouble to clamp to [0,a], either. Most of the blend
equations supported by this extension will produce outputs with
premultiplied color component values in the range [0,a] as long as the
inputs also have that property. One exception is PLUS_NV, but we
explicitly provide a PLUS_CLAMPED_ALPHA_NV equation to for that case.
(21) Should we provide an equation like the VG_BLEND_SOFTLIGHT_SVG_KHR
blending equation in the KHR_advanced_blending extension to OpenVG?
RESOLVED: No. The KHR_advanced_blending appears to have specified a
equation implementing the "soft-light" compositing property in a working
draft of a SVG 1.2 specification, as described here:
http://www.w3.org/TR/2004/WD-SVG12-20041027/
rendering.html#compositing
This version of the specification appears to have been abandoned. The
equations for the "soft-light" property in the SVG Compositing
Specification at:
http://www.w3.org/TR/SVGCompositing/
match the SOFTLIGHT_NV equation provided by this extension and
VG_BLEND_SOFTLIGHT_KHR (no "SVG") in KHR_advanced_blending.
Additionally, the equations in the SVG 1.2 draft and the
KHR_advanced_blending extension both appear to contain clear errors in
the first and second cases. Both begin with "(cd*(as-(1-cd/ad)*..." in
the KHR spec but should be "(cd*(as+(1-cd/ad)*...". Both of these sign
errors are corrected in the "SVG" functions in this extension. With the
errors, there is a local minimum at Cs=0.5 (where we switch from the
first form to the second or third) and the function has a major
discontinuity at Cd=0.125 when Cs>0.5 (where we switch from the second
form to the third). For example, when Cs=0.8 and Cd=0.125, the second
form of the KHR extension would generate a result of -0.00625 and the
third form would generate a result of ~0.26213. Note that the corrected
equations still aren't continuous at Cd=0.125; the fixed second and
third forms generate 0.25625 and 0.26213, respectively, when Cs=0.8 and
Cd=0.125.
(22) What issues apply to the INVERT and INVERT_OVG_NV equations?
RESOLVED: The INVERT and INVERT_OVG_NV equations were included to
provide functionality similar to the same VG_BLEND_INVERT_KHR blend
equation provided by the KHR_advanced_blending extension to OpenVG and
similar equations in a few other compositing APIs/standards.
Unfortunately, the equation specified by the KHR extension has issues.
The apparent intent of this blend equation is to use the source alpha to
blend between the destination color and an inverted form of the
destination color. This description conceptually matches the
description in the KHR extension:
(1 - asrc) * c'dst + asrc * (1 - c'dst)
However, since source and destination colors are premultiplied, the
expression "1-c'dst" doesn't correctly invert the destination color. To
invert a premultiplied destination color, "adst-c'dst" should be used.
For example, if the premultiplied destination color is 50% gray and 50%
opaque (adst=0.5), the RGBA destination color will be
(0.25,0.25,0.25,0.5). Inverting the color components via "1-c'dst"
would yield RGB component values of 0.75, which isn't consistent with an
alpha of 0.5. Inverting via "adst-c'dst" would yield correct RGB
component values of 0.25.
Additionally, the alpha computed for this equation in the KHR extension
is the standard "asrc+adst*(1-asrc)", equivalent to X=Y=Z=1 in our
normal formulation. However, given that the source color doesn't
contribute at all, having "Y=1" doesn't make a whole lot of sense. The
INVERT equation used in this extension uses X=Z=1 and Y=0, which means
that blending with this equation never changes destination alpha.
We provide a separate blend equation INVERT_OVG_NV to provide
compatibility with the formulation in the KHR extension. The math in
the KHR extension does perform a "valid" blending operation -- it will
produce results that remain in [0,1] when inputs are in [0,1], and its
results are continuous. It can't be expressed directly via our f/X/Y/Z
parameterization, but it does match our general f/X/Y/Z model if you
consider all three areas to contribute where:
* the intersection area contributes the inverted destination color
* the destination-only area contributes the destination color
* the source-only area contributes full white
Note that INVERT and INVERT_OVG_NV equations are mathematically
equivalent when the destination is opaque (i.e., adst=1.0); in this
case, "1-c'dst" and "adst-c'dst" are equivalent. In our f/X/Y/Z model,
the full destination coverage means there is no "source-only" area in
this case.
(23) What issues apply to the PLUS_DARKER_NV blend equation?
RESOLVED: The PLUS_DARKER_NV equation corresponds to an equation
provided in the Quartz 2D API from Apple. The public documentation for
this equation specifies the color computed by this operation as:
R = MAX(0, 1 - ((1 - D) + (1 - S)))
This equation appears to want to invert the source and destination
colors, add the two inverted colors, and then invert the result.
However, this equation appears to assume opaque source and destination
colors. As noted in the discussion for INVERT_OVG_NV, inverting a color
via "1-C" doesn't make any sense. We've reformulated the equations to
use pre-multipled colors and invert with "A-C" in a manner similar to
that described in this email thread:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg06536.html
which appears to be the "darker" mode implemented in the Safari browser
(at least in 2007). Our formulation is equivalent to the one in the
Quartz 2D documentation when As=Ad=1.
(24) Should we apply the f/X/Y/Z formulation to blend equations where the
equations can be expressed this way only if one or more of X, Y, or
Z are neither zero nor one?
RESOLVED: No. The f/X/Y/Z model subdivides a pixel into four regions
based on the alpha of the source and the destination, three of which
(intersection, source only, destination only) either contribute or don't
contribute color and coverage based on the given blend equation. The
figure below depicts a pixel where the source and destination both have
coverage of 0.5 (50%). The picture assigns source coverage to the upper
left portion of the pixel and the destination coverage to the upper
right, and assumes an UNCORRELATED model. In this case, the pixel is
divided into four areas of equal size. The area of intersection is at
the top, and its color and coverage are controlled by the f() and X
parameters. The source-only and destination-only regions are on the
left and right, respectively, and color and coverage are both controlled
by the Y and Z parameters.
+-----------+
|\_ f/X _/|
source | \_ _/ | destination
(upper ==>| Y \_/ Z | (upper
left) | _/ \_ | <== right)
| _/ \_ |
|/ \|
+-----------+
The PLUS_NV equation could be expressed with f(Cs,Cd) = Cs+Cd, X=2, Y=1,
and Z=1. The X=2 term effectively has the source and destination *both*
contribute coverage in the area of intersection. The MINUS_NV equation
could be expressed with f(Cs,Cd) = Cd-Cs, X=1, Y=-1, and Z=1. The Y=-1
term effectively has the source-only portion of the pixel *remove*
coverage. Both of these don't match the physical model, and would yield
odd results when combined with conjoint or disjoint overlap modes.
(25) Should we provide more specialized versions of CONJOINT_NV and
DISJOINT_NV?
RESOLVED: Not in this extension. In the future, we could add new
overlap modes such as:
NON_INTERSECTING_NV: Like DISJOINT_NV, except that it assumes that
As+Ad<=1. This might be interesting when rendering polygons with
POLYGON_SMOOTH?
DST_INSIDE_NV, SRC_INSIDE_NV: Like CONJOINT_NV, except that it
assumes that the destination coverage is fully inside the source or
vice versa. For DST_INSIDE, the p0/p1/p2 terms would be Ad, As-Ad,
and 0, respectively.
For all three of these modes, the specialized versions would have
simpler and possibly more efficient math. We're not going to add any of
these modes in this extension, however.
(26) Should the blend equations have a common prefix (e.g.,
"BLEND_SRC_OVER") or just use forms without a prefix?
RESOLVED: Use forms without a prefix where the tokens are only used in
the context of blending (i.e., via the BlendEquation API). We will use
a "BLEND_" prefix to identify BlendParameter <pname> values because
those tokens can also be used in the general GetIntegerv API. Note that
in current OpenGL, some parameters have their own Get* API (e.g.,
TexParameter), while others use the general GetInteger queries (e.g.,
PointParameter).
(27) Should we use standard GL enums for the blend equations that already
have these names?
RESOLVED: Yes, to minimize the number of new enums. The primary risk
is that reusing standard enum definitions would be problematic if a
future core version wanted to use these parameters in the same place
with a different meaning. However, all such names are in common use in
various compositing standards and our semantics are consistent with
those standards.
(28) What other APIs support blend equations similar to the ones provided
here, and how does the feature set compare?
RESOLVED: Khronos' OpenVG 1.1 vector graphics library provides a
variety of basic blending equations, with additional modes provided by
the KHR_advanced_blending extension:
* http://www.khronos.org/registry/vg/specs/openvg-1.1.pdf
* http://www.khronos.org/registry/vg/extensions/KHR/advanced_blending.txt
The World Wide Web Consortium (W3C)'s Scalable Vector Graphics format
supports a variety of blending equations in its compositing
specification:
* http://www.w3.org/TR/SVGCompositing
W3C also has a CSS standard (Compositing and Blending Level 1):
* http://www.w3.org/TR/compositing-1/
Adobe's widely-used Portable Document Format (PDF) specification
provides numerous blending equations in its "Transparency" section:
* http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/
pdf_reference_1-7.pdf
Adobe's SWF (Flash) File Format Specification
* http://www.adobe.com/go/swfspec
Various "2D" graphics APIs, including Oracle's JavaFX, Apple's Quartz
2D, Qt's QPainter class, and X Window System's X Rendering Extension
also support a variety of blending equations:
* http://docs.oracle.com/javafx/2/api/javafx/scene/effect/BlendMode.html
* http://developer.apple.com/library/ios/#documentation/GraphicsImaging/
Reference/CGContext/Reference/reference.html
* http://doc.qt.digia.com/4.7/qpainter.html#composition-modes
* http://www.x.org/releases/current/doc/renderproto/renderproto.txt
The following table indicates the set of blend equations from this
extension that are supported in these various standards or APIs. "X"
indicates that the equation is supported. For OpenVG, "E" indicates
that the equation is supported by the KHR_advanced_blending extension.
"XO" that the indicates that the equation is supported with conjoint and
disjoint overlap modes; others support only the uncorrelated overlap
mode.
Blending Equation OVG SVG PDF SWF JFX Q2D QPT XRE
-------------------- ----- ----- ----- ----- ----- ----- ----- -----
ZERO E X - - - X X XO
SRC_NV X X - X - X X XO
DST_NV E X - - - - X XO
SRC_OVER_NV X X X X X X X XO
DST_OVER_NV X X - - - X X XO
SRC_IN_NV X X - - - X X XO
DST_IN_NV X X - X - X X XO
SRC_OUT_NV E X - - - X X XO
DST_OUT_NV E X - X - X X XO
SRC_ATOP_NV E X - - X X X XO
DST_ATOP_NV E X - - - X X XO
XOR_NV E X - - - X X XO
MULTIPLY_NV X X X X X X X X
SCREEN_NV X X X X X X X X
OVERLAY_NV E X X X X X X X
DARKEN_NV X X X X X X X X
LIGHTEN_NV X X X X X X X X
COLORDODGE_NV E X X - X X X X
COLORBURN_NV E X X - X X X X
HARDLIGHT_NV E X X X X X X X
SOFTLIGHT_NV E X X - X X X X
DIFFERENCE_NV E X X X X X X X
EXCLUSION_NV E X X - X X X X
INVERT - - - X - - - -
INVERT_RGB_NV - - - - - - - -
LINEARDODGE_NV E - - - - - - -
LINEARBURN_NV E - - - - - - -
VIVIDLIGHT_NV E - - - - - - -
LINEARLIGHT_NV E - - - - - - -
PINLIGHT_NV E - - - - - - -
HARDMIX_NV E - - - - - - -
HSL_HUE_NV - - X - - X - X
HSL_SATURATION_NV - - X - - X - X
HSL_COLOR_NV - - X - - X - X
HSL_LUMINOSITY_NV - - X - - X - X
PLUS_NV /
PLUS_CLAMPED_NV / X X - X X X X X
PLUS_CLAMPED_ALPHA_NV
PLUS_DARKER_NV - - - - - X - -
MINUS_NV / E - - X - - - -
MINUS_CLAMPED_NV
CONTRAST_NV - - - - - - - -
INVERT_OVG_NV E - - - - - - -
RED_NV - - - - X - - -
GREEN_NV - - - - X - - -
BLUE_NV - - - - X - - -
OpenGL COLOR_LOGIC_OP - - - - - - X -
(not in this extension)
Notes:
* The PLUS_NV, PLUS_CLAMPED_NV, and PLUS_CLAMPED_ALPHA_NV equations
are very similar and may be indistinguishable when the destination
buffer components are stored in normalized [0,1] numeric spaces, as
is the case in most of these standards. The MINUS_NV and
MINUS_CLAMPED_NV equations behave similarly.
* The SWF specification has a mode called "invert", but it's not clear
whether the mode is implemented using INVERT, INVERT_OVG_NV, or some
other equation.
(29) Should we provide an extension that can be supported on
implementations that may not provide fully coherent blending when
using the new equations? If so, how will this support be provided
and what limitations apply?
RESOLVED: Yes, this functionality is useful not just for general 3D
rendering, but also for 2D rendering operations (where the primitives
rendered may be less complex). As indicated in the issue above, the
blend equations provided by this extension are already very commonly
used in 2D rendering. Accelerating them on a wide range of GPUs, old
and new, would be very useful.
Older NVIDIA GPUs are able to support these blending equations as long
as rendering is split into distinct passes and no pixel is touched more
than once in any given pass. For such GPUs, we specify that the results
of blending are undefined if a single pixel (or sample) is touched more
than once in a pass, and provide the command BlendBarrierNV() to allow
applications to delimit boundaries between passes. As long as rendering
commands can be split into passes with barriers, advanced blending will
work "normally" even on these older GPUs.
Since there are two distinct levels of capability, we will advertise two
different extension string entries:
- GL_NV_blend_equation_advanced: Provides the new blending
functionality without support for full coherence (older GPUs).
- GL_NV_blend_equation_advanced_coherent: Provides the new blending
functionality with full coherence.
Since the functionality of these two extensions is nearly identical, we
document them in a single extension specification.
(30) On implementations that don't support fully coherent blending, should
we provide any convenience features so that "2D" applications aren't
required to manually sprinkle BlendBarrierNV() throughout the code?
RESOLVED: Yes. When using NV_blend_equation_advanced in conjunction
with NV_path_rendering commands like CoverFillPathNV and
CoverStrokePathNV, the driver will assist in ensuring coherent and
properly ordered blending by inserting implicit blend barriers before
rendering each cover primitive.
(31) When we generate fragments using the automatic coherence guarantees
from NV_path_rendering commands like CoverFillPathNV, what happens if
a pixel touched by CoverFillPathNV had already been touched by a
previous non-NVpr rendering command without an intervening call to
BlendBarrierNV? What happens if a pixel touched by CoverFillPathNV
is subsequently touched by a subsequent non-NVpr without an
intervening call to BlendBarrierNV?
RESOLVED: We specify that a blend barrier is inserted prior to each
cover primitives, so that cover primitives are blended coherently
relative to geometry from previous primitives (cover or otherwise). We
do not guarantee that a blend barrier is inserted after each cover
primitive, so applications need to call BlendBarrierNV manually if
subsequent non-cover primitives are rendered to the same set of pixels.
(32) On implementations supporting fully coherent blending, should we
provide some mode allowing implementations to opt out of coherent
blending?
RESOLVED: Yes. We will provide an enable allowing applications to
disable coherent blending in case where (a) implementations are able to
provide higher-performance implementations if they don't have to worry
about full coherence and/or ordering and (b) applications are willing to
use BlendBarrierNV() to take advantage of the higher-performance
implementation. The enable will be on by default, which means that
advanced blending on fully capable implementations will be "safe" unless
explicitly disabled.
(33) When fully coherent blending is disabled or not supported,
BlendBarrierNV() is used to indicate boundaries between passes.
Should any other commands in the OpenGL API also implicitly serve as
blend barriers?
RESOLVED: In general, no. Except for the NV_path_rendering case above,
we will require applications manually use BlendBarrierNV(). There may
be other operations that indirectly cause blend results to become
coherent (in an implementation-dependent way), but we don't attempt to
provide any explicit guarantees. Except for path rendering cover
primitives (see issues 30 and 31), applications should always call
BlendBarrierNV() between possibly overlapping passes.
Note that implementations of this extension may use texture mapping
hardware to source the framebuffer for blending and may end up caching
pre-blended texel values. This can cause subsequent texture fetches to
return stale values unless the texture is re-bound, the
TextureBarrierNV() command from the NV_texture_barrier extension is
used, or some other action is taken to break the "rendering feedback
loop". The existing spec already defines that texel fetches produce
undefined results when a texture object is bound both as a texture and
attached to the current draw framebuffer, with or without advanced blend
equations. See the "Rendering Feedback Loops" section (p. 316 in the
OpenGL 4.1 Compatibility Profile specification) for more information.
(34) How should the blend equations COLORDODGE_NV and COLORBURN_NV be
expressed mathematically?
RESOLVED: We changed the definition of these equations after the
NV_blend_equation_advanced spec was originally published, as discussed
below. These changes add new special cases to the COLORDODGE_NV and
COLORBURN_NV equations that are found in newer compositing standard
specifications and in a number of implementations of old and new
standards. We believe that the omission of the special case in other
older specifications is a bug. We have no plans to add new blend
equation tokens to support "equivalent" modes without the new special
case.
Note, however, that older versions of this extension and older NVIDIA
drivers implementing it will lack these special cases. A driver update
may be required to get the new behavior.
There is some disagreement in different published specifications about
how these two blend equations should be handled. At the time this
extension was initially developed, all specifications we found that
specified blending equations mathematically (see issue 28) were written
the same way. Since then, we discovered that newer working drafts of
the W3C Compositing and Blending Level 1 specification (for CSS and SVG)
express "color-burn" as follows (translated to our nomenclature):
if (Cd == 1) // their Cb (backdrop) is our Cd (destination)
f(Cs,Cd) = 1 // their B() is our f()
else if (Cs == 0)
f(Cs,Cd) = 0
else
f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs)
http://www.w3.org/TR/2013/WD-compositing-1-20131010/
#blendingcolorburn
Earlier versions of the same W3C specification, an older SVG compositing
draft specification, the Adobe PDF specification (and the ISO 32000-1
standard), and the KHR_advanced_blending extension to OpenVG all specify
the following equation without the initial special case:
if (Cs == 0)
f(Cs,Cd) = 0
else
f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs)
http://www.w3.org/TR/2012/WD-compositing-20120816/
#blendingcolorburn
http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/
pdfs/pdf_reference_1-7.pdf
http://www.khronos.org/registry/vg/extensions/KHR/
advanced_blending.txt
For the Adobe PDF specification, the corrected blend equations are
published in an Adobe supplement to ISO 32000-1 and are expected to be
accepted in a future version of the standard:
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/
devnet/pdf/pdfs/adobe_supplement_iso32000_1.pdf
The author's understanding is that multiple shipping implementations of
these blending modes implement the special case for "Cd==1" above,
including various Adobe products and the open-source Ghostscript
project.
We believe that the extra special case in this specification is
consistent with the physical model of color burning. Burning is
described in
http://en.wikipedia.org/wiki/Dodging_and_burning
as making a print with normal exposure, and then adding additional
exposure to darken the overall image. In the general equation:
1 - min(1, (1-Cd)/Cs)
Cs operates as a sort of fudge factor where a value of 1.0 implies no
additional exposure time and 0.0 implies arbitrarily long additional
exposure time, where the initial amount of exposure (1-Cd) is multiplied
by 1/Cs and then clamped to maximum exposure by the min() operation.
The Cd==1 special case here implies that we get zero exposure in the
initial print, since 1-Cd==0. No amount of extra exposure time will
generate any additional exposure. This would imply that the final
result should have zero exposure and thus a final f() value of 1. This
matches the initial special case. Without that special case, we would
hit the second special case if Cs==0 (infinite exposure time), which
would yield an incorrect final value of 0 (full exposure).
A similar issue applies to COLORDODGE_NV, where some specifications
include a special case for Cb==0 while others do not. We have added a
special case there as well.
(35) For "HSL" blend equations, the blend equation involves a clipping
step where colors may be "clipped" if the blend would produce
components are outside the range [0,1]. Are there inputs where this
blend could produce ill-defined or nonsensical results?
RESOLVED: Yes, the results of HSL blend equations are undefined if the
input colors have components outside the range [0,1]. Even if the input
colors are in-range, the basic color adjustment done in these blends
could produce result components outside the range [0,1]. To compensate,
the ClipColor() function in the specification interpolates the result
color and a greyscale value that matches the luminance of the result.
The math for the clipping operation assumes the luminance of the result
color is in the range [0,1]. If that isn't the case, the clipping
operation could result in a divide by zero (when all result components
have the same out-of-bounds value) or perform an otherwise nonsensical
computation.
Revision History
Rev. Date Author Changes
---- -------- -------- ----------------------------------------------
10 02/14/18 pdaniell Fix ClipColor() equation where in the
"if (maxcol > 1.0)" body the "(color-lum)*lum"
term should have been "(color-lum)*(1-lum)".
Also add new issue 35 for the case where the
inputs to SetLum() are outside the range
[0..1] and could cause a divide-by-zero in
ClipColor().
9 09/30/14 pbrown Fix incorrectly specified color clamping in
the HSL blend modes.
8 02/26/14 pbrown For non-coherent blending, clarify that all
writes to a sample are considered to "touch"
that sample and require a BlendBarrierOES call
before blending overlapping geometry. Clears,
non-blended geometry, and copies by
BlitFramebuffer or TexSubImage are all
considered to "touch" a sample (bug 11738).
Specify that non-premultiplied values
corresponding to ill-conditioned premultiplied
colors such as (1,1,1,0) are undefined (bug
11739). Update issue (12) related to
ill-conditioned premultiplied colors.
7 11/06/13 pbrown Fix the language about non-coherent blending
to specify that results are undefined only if an
individual *sample* is touched more than once
(instead of *pixel*). Minor language tweaks to
use "equations" consistently, instead of
sometimes using "modes".
6 10/21/13 pbrown Add NV-suffixed names for tokens reusing values
from core OpenGL enums (XOR, RED, GREEN, BLUE)
that are not in core OpenGL ES 2.0. This allows
code targeting both APIs to use the same
NV-suffixed #defines. Some older versions of
the OpenGL "glext.h" header will not have the
NV-suffixed names.
5 10/21/13 pbrown Add a reference to the Adobe supplement to
ISO 32000-1, which includes the corrected
equations for COLORDODGE_NV and COLORBURN_NV.
Move "NVIDIA Implementation Details" down
a bit in the spec.
4 10/16/13 pbrown Modify the definition of COLORDODGE_NV and
COLORBURN_NV to match de facto standard
implemenations and new CSS/SVG compositing
spec; add issue (34).
3 08/19/13 pbrown Fix typos in the OpenGL ES 2.0 and 3.0
interactions sections.
2 07/25/13 mjk Add W3C CSS compositing reference.
1 pbrown Internal revisions.