| 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. |
