1Name 2 3 NV_blend_equation_advanced 4 5Name Strings 6 7 GL_NV_blend_equation_advanced 8 GL_NV_blend_equation_advanced_coherent 9 10Contact 11 12 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 13 14Contributors 15 16 Jeff Bolz, NVIDIA Corporation 17 Mathias Heyer, NVIDIA Corporation 18 Mark Kilgard, NVIDIA Corporation 19 Daniel Koch, NVIDIA Corporation 20 Rik Cabanier, Adobe 21 22Status 23 24 NV_blend_equation_advanced is released in NVIDIA Driver Release 25 326.xx (June 2013). 26 27Version 28 29 Last Modified Date: February 14, 2018 30 NVIDIA Revision: 10 31 32Number 33 34 OpenGL Extension #433 35 OpenGL ES Extension #163 36 37Dependencies 38 39 This extension is written against the OpenGL 4.1 Specification 40 (Compatibility Profile). 41 42 OpenGL 2.0 is required (for Desktop). 43 44 OpenGL ES 2.0 is required (for mobile). 45 46 EXT_blend_minmax is required (for mobile). 47 48 This extension interacts with OpenGL 4.0. 49 50 This extension interacts with OpenGL 4.1 (Core Profile). 51 52 This extension interacts with OpenGL 4.3 or later. 53 54 This extension interacts with OpenGL ES 2.0. 55 56 This extension interacts with OpenGL ES 3.0. 57 58 This extension interacts with NV_path_rendering. 59 60Overview 61 62 This extension adds a number of "advanced" blending equations that can be 63 used to perform new color blending operations, many of which are more 64 complex than the standard blend modes provided by unextended OpenGL. This 65 extension provides two different extension string entries: 66 67 - NV_blend_equation_advanced: Provides the new blending equations, but 68 guarantees defined results only if each sample is touched no more than 69 once in any single rendering pass. The command BlendBarrierNV() is 70 provided to indicate a boundary between passes. 71 72 - NV_blend_equation_advanced_coherent: Provides the new blending 73 equations, and guarantees that blending is done coherently and in API 74 primitive ordering. An enable is provided to allow implementations to 75 opt out of fully coherent blending and instead behave as though only 76 NV_blend_equation_advanced were supported. 77 78 Some implementations may support NV_blend_equation_advanced without 79 supporting NV_blend_equation_advanced_coherent. 80 81 In unextended OpenGL, the set of blending equations is limited, and can be 82 expressed very simply. The MIN and MAX blend equations simply compute 83 component-wise minimums or maximums of source and destination color 84 components. The FUNC_ADD, FUNC_SUBTRACT, and FUNC_REVERSE_SUBTRACT 85 multiply the source and destination colors by source and destination 86 factors and either add the two products together or subtract one from the 87 other. This limited set of operations supports many common blending 88 operations but precludes the use of more sophisticated transparency and 89 blending operations commonly available in many dedicated imaging APIs. 90 91 This extension provides a number of new "advanced" blending equations. 92 Unlike traditional blending operations using the FUNC_ADD equation, these 93 blending equations do not use source and destination factors specified by 94 BlendFunc. Instead, each blend equation specifies a complete equation 95 based on the source and destination colors. These new blend equations are 96 used for both RGB and alpha components; they may not be used to perform 97 separate RGB and alpha blending (via functions like 98 BlendEquationSeparate). 99 100 These blending operations are performed using premultiplied colors, where 101 RGB colors stored in the framebuffer are considered to be multiplied by 102 alpha (coverage). The fragment color may be considered premultiplied or 103 non-premultiplied, according the BLEND_PREMULTIPLIED_SRC_NV blending 104 parameter (as specified by the new BlendParameteriNV function). If 105 fragment color is considered non-premultiplied, the (R,G,B) color 106 components are multiplied by the alpha component prior to blending. For 107 non-premultiplied color components in the range [0,1], the corresponding 108 premultiplied color component would have values in the range [0*A,1*A]. 109 110 Many of these advanced blending equations are formulated where the result 111 of blending source and destination colors with partial coverage have three 112 separate contributions: from the portions covered by both the source and 113 the destination, from the portion covered only by the source, and from the 114 portion covered only by the destination. The blend parameter 115 BLEND_OVERLAP_NV can be used to specify a correlation between source and 116 destination pixel coverage. If set to CONJOINT_NV, the source and 117 destination are considered to have maximal overlap, as would be the case 118 if drawing two objects on top of each other. If set to DISJOINT_NV, the 119 source and destination are considered to have minimal overlap, as would be 120 the case when rendering a complex polygon tessellated into individual 121 non-intersecting triangles. If set to UNCORRELATED_NV (default), the 122 source and destination coverage are assumed to have no spatial correlation 123 within the pixel. 124 125 In addition to the coherency issues on implementations not supporting 126 NV_blend_equation_advanced_coherent, this extension has several 127 limitations worth noting. First, the new blend equations are not 128 supported while rendering to more than one color buffer at once; an 129 INVALID_OPERATION will be generated if an application attempts to render 130 any primitives in this unsupported configuration. Additionally, blending 131 precision may be limited to 16-bit floating-point, which could result in a 132 loss of precision and dynamic range for framebuffer formats with 32-bit 133 floating-point components, and in a loss of precision for formats with 12- 134 and 16-bit signed or unsigned normalized integer components. 135 136New Procedures and Functions 137 138 void BlendParameteriNV(enum pname, int value); 139 void BlendBarrierNV(void); 140 141New Tokens 142 143 Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, and by 144 the <pname> parameter of GetIntegerv, GetBooleanv, GetFloatv, GetDoublev 145 and GetInteger64v: 146 147 BLEND_ADVANCED_COHERENT_NV 0x9285 148 149 Note: The BLEND_ADVANCED_COHERENT_NV enable is provided if and only if 150 the NV_blend_equation_advanced_coherent extension is supported. On 151 implementations supporting only NV_blend_equation_advanced, this enable is 152 considered not to exist. 153 154 Accepted by the <pname> parameter of BlendParameteriNV, GetBooleanv, 155 GetIntegerv, GetInteger64v, GetFloatv, and GetDoublev: 156 157 BLEND_PREMULTIPLIED_SRC_NV 0x9280 158 BLEND_OVERLAP_NV 0x9281 159 160 Accepted by the <value> parameter of BlendParameteriNV when <pname> is 161 BLEND_PREMULTIPLIED_SRC_NV: 162 163 TRUE 164 FALSE 165 166 Accepted by the <value> parameter of BlendParameteriNV when <pname> is 167 BLEND_OVERLAP_NV: 168 169 UNCORRELATED_NV 0x9282 170 DISJOINT_NV 0x9283 171 CONJOINT_NV 0x9284 172 173 Accepted by the <mode> parameter of BlendEquation and BlendEquationi: 174 175 ZERO // reused from core 176 SRC_NV 0x9286 177 DST_NV 0x9287 178 SRC_OVER_NV 0x9288 179 DST_OVER_NV 0x9289 180 SRC_IN_NV 0x928A 181 DST_IN_NV 0x928B 182 SRC_OUT_NV 0x928C 183 DST_OUT_NV 0x928D 184 SRC_ATOP_NV 0x928E 185 DST_ATOP_NV 0x928F 186 XOR_NV 0x1506 187 MULTIPLY_NV 0x9294 188 SCREEN_NV 0x9295 189 OVERLAY_NV 0x9296 190 DARKEN_NV 0x9297 191 LIGHTEN_NV 0x9298 192 COLORDODGE_NV 0x9299 193 COLORBURN_NV 0x929A 194 HARDLIGHT_NV 0x929B 195 SOFTLIGHT_NV 0x929C 196 DIFFERENCE_NV 0x929E 197 EXCLUSION_NV 0x92A0 198 INVERT // reused from core 199 INVERT_RGB_NV 0x92A3 200 LINEARDODGE_NV 0x92A4 201 LINEARBURN_NV 0x92A5 202 VIVIDLIGHT_NV 0x92A6 203 LINEARLIGHT_NV 0x92A7 204 PINLIGHT_NV 0x92A8 205 HARDMIX_NV 0x92A9 206 207 HSL_HUE_NV 0x92AD 208 HSL_SATURATION_NV 0x92AE 209 HSL_COLOR_NV 0x92AF 210 HSL_LUMINOSITY_NV 0x92B0 211 212 PLUS_NV 0x9291 213 PLUS_CLAMPED_NV 0x92B1 214 PLUS_CLAMPED_ALPHA_NV 0x92B2 215 PLUS_DARKER_NV 0x9292 216 MINUS_NV 0x929F 217 MINUS_CLAMPED_NV 0x92B3 218 CONTRAST_NV 0x92A1 219 INVERT_OVG_NV 0x92B4 220 RED_NV 0x1903 221 GREEN_NV 0x1904 222 BLUE_NV 0x1905 223 224 NOTE: These enums are not accepted by the <modeRGB> or <modeAlpha> 225 parameters of BlendEquationSeparate or BlendEquationSeparatei. 226 227 NOTE: The tokens XOR_NV, RED_NV, GREEN_NV, and BLUE_NV have the same 228 values as core OpenGL API enumerants with names without the "_NV" 229 suffixes. Either #define can be used, but the non-suffixed #defines are 230 not available in OpenGL ES 2.0 and XOR is not available in OpenGL ES 3.0. 231 232Additions to Chapter 2 of the OpenGL 4.1 Specification (OpenGL Operation) 233 234 None. 235 236Additions to Chapter 3 of the OpenGL 4.1 Specification (Rasterization) 237 238 None. 239 240Additions to Chapter 4 of the OpenGL 4.1 Specification (Per-Fragment 241Operations and the Frame Buffer) 242 243 Modify Section 4.1.8, Blending (p. 359). 244 245 (modify the first paragraph, p. 361, allowing for new values in the 246 <mode> parameter) ... <modeRGB> and <modeAlpha> must be one of 247 FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT, MIN, or MAX as listed 248 in Table 4.1. <mode> must be one of the values in Table 4.1, 249 or one of the blend equations listed in tables X.2, X.3, and X.4. ... 250 251 (modify the third paragraph, p. 361, specifying minimum precision and 252 dynamic range for blend operations) ... Blending computations are treated 253 as if carried out in floating-point. For the equations in table 4.1, 254 blending computations will be performed with a precision and dynamic range 255 no lower than that used to represent destination components. For the 256 equations in table X.2, X.3, and X.4, blending computations will be 257 performed with a precision and dynamic range no lower than the smaller of 258 that used to represent destination components or that used to represent 259 16-bit floating-point values as described in section 2.1.1. 260 261 (add unnumbered subsection prior to "Dual Source Blending and Multiple 262 Draw Buffers", p. 363) 263 264 Advanced Blend Equations 265 266 The advanced blend equations are those listed in tables X.2, X.3, and X.4. 267 Parameters related to the advanced blend equations can be set by calling 268 269 void BlendParameteriNV(enum pname, int param); 270 271 with <pname> set to BLEND_PREMULTIPLIED_SRC_NV or BLEND_OVERLAP_NV. When 272 <pname> is BLEND_PREMULTIPLIED_SRC_NV, the valid values for <param> are 273 TRUE or FALSE. When <pname> is BLEND_OVERLAP_NV, the valid values for 274 <param> are UNCORRELATED_NV, CONJOINT_NV, and DISJOINT_NV. An 275 INVALID_ENUM error is generated if <pname> is not 276 BLEND_PREMULTIPLIED_SRC_NV or BLEND_OVERLAP_NV, or if <param> is not a 277 legal value for <pname>. 278 279 When using one of the equations in table X.2 or X.3, blending is performed 280 according to the following equations: 281 282 R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad) 283 G = f(Gs',Gd')*p0(As,Ad) + Y*Gs'*p1(As,Ad) + Z*Gd'*p2(As,Ad) 284 B = f(Bs',Bd')*p0(As,Ad) + Y*Bs'*p1(As,Ad) + Z*Bd'*p2(As,Ad) 285 A = X*p0(As,Ad) + Y*p1(As,Ad) + Z*p2(As,Ad) 286 287 where the function f and terms X, Y, and Z are specified in the table. 288 The R, G, and B components of the source color used for blending are 289 derived according to the premultiplied source color blending parameter, 290 which is set by calling BlendParameteriNV with <pname> set to 291 BLEND_PREMULTIPLIED_SRC_NV, and <param> set to TRUE or FALSE. 292 If the parameter is set to TRUE, the fragment color components are 293 considered to have been premultiplied by the A component prior to 294 blending. The base source color (Rs',Gs',Bs') is obtained by dividing 295 through by the A component: 296 297 (Rs', Gs', Bs') = 298 (0, 0, 0), if As == 0 299 (Rs/As, Gs/As, Bs/As), otherwise 300 301 If the premultiplied source color parameter is FALSE, the fragment color 302 components are used as the base color: 303 304 (Rs', Gs', Bs') = (Rs, Gs, Bs) 305 306 The destination color components are always considered to have been 307 premultiplied by the destination A component and the base destination 308 color (Rd', Gd', Bd') is obtained by dividing through by the A component: 309 310 (Rd', Gd', Bd') = 311 (0, 0, 0), if Ad == 0 312 (Rd/Ad, Gd/Ad, Bd/Ad), otherwise 313 314 When blending using advanced blend equations, we expect that the R, G, and 315 B components of premultiplied source and destination color inputs be 316 stored as the product of non-premultiplied R, G, and B component values 317 and the A component of the color. If any R, G, or B component of a 318 premultiplied input color is non-zero and the A component is zero, the 319 color is considered ill-formed, and the corresponding component of the 320 blend result will be undefined. 321 322 The weighting functions p0, p1, and p2 are defined in table X.1. In these 323 functions, the A components of the source and destination colors are taken 324 to indicate the portion of the pixel covered by the fragment (source) and 325 the fragments previously accumulated in the pixel (destination). The 326 functions p0, p1, and p2 approximate the relative portion of the pixel 327 covered by the intersection of the source and destination, covered only by 328 the source, and covered only by the destination, respectively. These 329 functions are specified by the blend overlap parameter, which can be set 330 by calling BlendParameteriNV with <pname> set to BLEND_OVERLAP_NV. <param> 331 can be one of UNCORRELATED_NV (default), CONJOINT_NV, and DISJOINT_NV. 332 UNCORRELATED_NV indicates that there is no correlation between the source 333 and destination coverage. CONJOINT_NV and DISJOINT_NV indicate that the 334 source and destination coverage are considered to have maximal or minimal 335 overlap, respectively. 336 337 Overlap Mode Weighting Equations 338 --------------- -------------------------- 339 UNCORRELATED_NV p0(As,Ad) = As*Ad 340 p1(As,Ad) = As*(1-Ad) 341 p2(As,Ad) = Ad*(1-As) 342 CONJOINT_NV p0(As,Ad) = min(As,Ad) 343 p1(As,Ad) = max(As-Ad,0) 344 p2(As,Ad) = max(Ad-As,0) 345 DISJOINT_NV p0(As,Ad) = max(As+Ad-1,0) 346 p1(As,Ad) = min(As,1-Ad) 347 p2(As,Ad) = min(Ad,1-As) 348 349 Table X.1, Advanced Blend Overlap Modes 350 351 352 Mode Blend Coefficients 353 -------------------- ----------------------------------- 354 ZERO (X,Y,Z) = (0,0,0) 355 f(Cs,Cd) = 0 356 357 SRC_NV (X,Y,Z) = (1,1,0) 358 f(Cs,Cd) = Cs 359 360 DST_NV (X,Y,Z) = (1,0,1) 361 f(Cs,Cd) = Cd 362 363 SRC_OVER_NV (X,Y,Z) = (1,1,1) 364 f(Cs,Cd) = Cs 365 366 DST_OVER_NV (X,Y,Z) = (1,1,1) 367 f(Cs,Cd) = Cd 368 369 SRC_IN_NV (X,Y,Z) = (1,0,0) 370 f(Cs,Cd) = Cs 371 372 DST_IN_NV (X,Y,Z) = (1,0,0) 373 f(Cs,Cd) = Cd 374 375 SRC_OUT_NV (X,Y,Z) = (0,1,0) 376 f(Cs,Cd) = 0 377 378 DST_OUT_NV (X,Y,Z) = (0,0,1) 379 f(Cs,Cd) = 0 380 381 SRC_ATOP_NV (X,Y,Z) = (1,0,1) 382 f(Cs,Cd) = Cs 383 384 DST_ATOP_NV (X,Y,Z) = (1,1,0) 385 f(Cs,Cd) = Cd 386 387 XOR_NV (X,Y,Z) = (0,1,1) 388 f(Cs,Cd) = 0 389 390 MULTIPLY_NV (X,Y,Z) = (1,1,1) 391 f(Cs,Cd) = Cs*Cd 392 393 SCREEN_NV (X,Y,Z) = (1,1,1) 394 f(Cs,Cd) = Cs+Cd-Cs*Cd 395 396 OVERLAY_NV (X,Y,Z) = (1,1,1) 397 f(Cs,Cd) = 2*Cs*Cd, if Cd <= 0.5 398 1-2*(1-Cs)*(1-Cd), otherwise 399 400 DARKEN_NV (X,Y,Z) = (1,1,1) 401 f(Cs,Cd) = min(Cs,Cd) 402 403 LIGHTEN_NV (X,Y,Z) = (1,1,1) 404 f(Cs,Cd) = max(Cs,Cd) 405 406 COLORDODGE_NV (X,Y,Z) = (1,1,1) 407 f(Cs,Cd) = 408 0, if Cd <= 0 409 min(1,Cd/(1-Cs)), if Cd > 0 and Cs < 1 410 1, if Cd > 0 and Cs >= 1 411 412 COLORBURN_NV (X,Y,Z) = (1,1,1) 413 f(Cs,Cd) = 414 1, if Cd >= 1 415 1 - min(1,(1-Cd)/Cs), if Cd < 1 and Cs > 0 416 0, if Cd < 1 and Cs <= 0 417 418 HARDLIGHT_NV (X,Y,Z) = (1,1,1) 419 f(Cs,Cd) = 2*Cs*Cd, if Cs <= 0.5 420 1-2*(1-Cs)*(1-Cd), otherwise 421 422 SOFTLIGHT_NV (X,Y,Z) = (1,1,1) 423 f(Cs,Cd) = 424 Cd-(1-2*Cs)*Cd*(1-Cd), 425 if Cs <= 0.5 426 Cd+(2*Cs-1)*Cd*((16*Cd-12)*Cd+3), 427 if Cs > 0.5 and Cd <= 0.25 428 Cd+(2*Cs-1)*(sqrt(Cd)-Cd), 429 if Cs > 0.5 and Cd > 0.25 430 431 DIFFERENCE_NV (X,Y,Z) = (1,1,1) 432 f(Cs,Cd) = abs(Cd-Cs) 433 434 EXCLUSION_NV (X,Y,Z) = (1,1,1) 435 f(Cs,Cd) = Cs+Cd-2*Cs*Cd 436 437 INVERT (X,Y,Z) = (1,0,1) 438 f(Cs,Cd) = 1-Cd 439 440 INVERT_RGB_NV (X,Y,Z) = (1,0,1) 441 f(Cs,Cd) = Cs*(1-Cd) 442 443 LINEARDODGE_NV (X,Y,Z) = (1,1,1) 444 f(Cs,Cd) = 445 Cs+Cd, if Cs+Cd<=1 446 1, otherwise 447 448 LINEARBURN_NV (X,Y,Z) = (1,1,1) 449 f(Cs,Cd) = 450 Cs+Cd-1, if Cs+Cd>1 451 0, otherwise 452 453 VIVIDLIGHT_NV (X,Y,Z) = (1,1,1) 454 f(Cs,Cd) = 455 1-min(1,(1-Cd)/(2*Cs)), if 0 < Cs < 0.5 456 0, if Cs <= 0 457 min(1,Cd/(2*(1-Cs))), if 0.5 <= Cs < 1 458 1, if Cs >= 1 459 460 LINEARLIGHT_NV (X,Y,Z) = (1,1,1) 461 f(Cs,Cd) = 462 1, if 2*Cs+Cd>2 463 2*Cs+Cd-1, if 1 < 2*Cs+Cd <= 2 464 0, if 2*Cs+Cd<=1 465 466 PINLIGHT_NV (X,Y,Z) = (1,1,1) 467 f(Cs,Cd) = 468 0, if 2*Cs-1>Cd and Cs<0.5 469 2*Cs-1, if 2*Cs-1>Cd and Cs>=0.5 470 2*Cs, if 2*Cs-1<=Cd and Cs<0.5*Cd 471 Cd, if 2*Cs-1<=Cd and Cs>=0.5*Cd 472 ??? 473 474 HARDMIX_NV (X,Y,Z) = (1,1,1) 475 f(Cs,Cd) = 0, if Cs+Cd<1 476 1, otherwise 477 478 Table X.2, Advanced Blend Equations 479 480 481 When using one of the HSL blend equations in table X.3 as the blend 482 equation, the RGB color components produced by the function f() are 483 effectively obtained by converting both the non-premultiplied source and 484 destination colors to the HSL (hue, saturation, luminosity) color space, 485 generating a new HSL color by selecting H, S, and L components from the 486 source or destination according to the blend equation, and then converting 487 the result back to RGB. The HSL blend equations are only well defined 488 when the values of the input color components are in the range [0..1]. 489 In the equations below, a blended RGB color is produced according to the 490 following pseudocode: 491 492 float minv3(vec3 c) { 493 return min(min(c.r, c.g), c.b); 494 } 495 float maxv3(vec3 c) { 496 return max(max(c.r, c.g), c.b); 497 } 498 float lumv3(vec3 c) { 499 return dot(c, vec3(0.30, 0.59, 0.11)); 500 } 501 float satv3(vec3 c) { 502 return maxv3(c) - minv3(c); 503 } 504 505 // If any color components are outside [0,1], adjust the color to 506 // get the components in range. 507 vec3 ClipColor(vec3 color) { 508 float lum = lumv3(color); 509 float mincol = minv3(color); 510 float maxcol = maxv3(color); 511 if (mincol < 0.0) { 512 color = lum + ((color-lum)*lum) / (lum-mincol); 513 } 514 if (maxcol > 1.0) { 515 color = lum + ((color-lum)*(1-lum)) / (maxcol-lum); 516 } 517 return color; 518 } 519 520 // Take the base RGB color <cbase> and override its luminosity 521 // with that of the RGB color <clum>. 522 vec3 SetLum(vec3 cbase, vec3 clum) { 523 float lbase = lumv3(cbase); 524 float llum = lumv3(clum); 525 float ldiff = llum - lbase; 526 vec3 color = cbase + vec3(ldiff); 527 return ClipColor(color); 528 } 529 530 // Take the base RGB color <cbase> and override its saturation with 531 // that of the RGB color <csat>. The override the luminosity of the 532 // result with that of the RGB color <clum>. 533 vec3 SetLumSat(vec3 cbase, vec3 csat, vec3 clum) 534 { 535 float minbase = minv3(cbase); 536 float sbase = satv3(cbase); 537 float ssat = satv3(csat); 538 vec3 color; 539 if (sbase > 0) { 540 // Equivalent (modulo rounding errors) to setting the 541 // smallest (R,G,B) component to 0, the largest to <ssat>, 542 // and interpolating the "middle" component based on its 543 // original value relative to the smallest/largest. 544 color = (cbase - minbase) * ssat / sbase; 545 } else { 546 color = vec3(0.0); 547 } 548 return SetLum(color, clum); 549 } 550 551 552 Mode Result 553 -------------------- ---------------------------------------- 554 HSL_HUE_NV (X,Y,Z) = (1,1,1) 555 f(Cs,Cd) = SetLumSat(Cs,Cd,Cd); 556 557 HSL_SATURATION_NV (X,Y,Z) = (1,1,1) 558 f(Cs,Cd) = SetLumSat(Cd,Cs,Cd); 559 560 HSL_COLOR_NV (X,Y,Z) = (1,1,1) 561 f(Cs,Cd) = SetLum(Cs,Cd); 562 563 HSL_LUMINOSITY_NV (X,Y,Z) = (1,1,1) 564 f(Cs,Cd) = SetLum(Cd,Cs); 565 566 Table X.3, Hue-Saturation-Luminosity Advanced Blend Equations 567 568 569 When using one of the equations in table X.4 as the blend equation, the 570 source color used by these blending equations is interpreted according to 571 the BLEND_PREMULTIPLIED_SRC_NV blending parameter. The blending equations 572 below are evaluated where the RGB source and destination color components 573 are both considered to have been premultiplied by the corresponding A 574 component. 575 576 (Rs', Gs', Bs') = 577 (Rs, Gs, Bs), if BLEND_PREMULTIPLIED_SRC_NV is TRUE 578 (Rs*As, Gs*As, Bs*As), if BLEND_PREMULTIPLIED_SRC_NV is FALSE 579 580 Mode Result 581 -------------------- ---------------------------------------- 582 PLUS_NV (R,G,B,A) = (Rs'+Rd, Gs'+Gd, Bs'+Bd,As'+Ad) 583 584 PLUS_CLAMPED_NV (R,G,B,A) = 585 (min(1,Rs'+Rd), min(1,Gs'+Gd), 586 min(1,Bs'+Bd), min(1,As+Ad)) 587 588 PLUS_CLAMPED_ALPHA_NV (R,G,B,A) = 589 (min(min(1,As+Ad),Rs'+Rd), 590 min(min(1,As+Ad),Gs'+Gd), 591 min(min(1,As+Ad),Bs'+Bd), min(1,As+Ad)) 592 593 PLUS_DARKER_NV (R,G,B,A) = 594 (max(0,min(1,As+Ad)-((As-Rs')+(Ad-Rd))), 595 max(0,min(1,As+Ad)-((As-Gs')+(Ad-Gd))), 596 max(0,min(1,As+Ad)-((As-Bs')+(Ad-Bd))), 597 min(1,As+Ad)) 598 599 MINUS_NV (R,G,B,A) = (Rd-Rs', Gd-Gs', Bd-Bs', Ad-As) 600 601 MINUS_CLAMPED_NV (R,G,B,A) = 602 (max(0,Rd-Rs'), max(0,Gd-Gs'), 603 max(0,Bd-Bs'), max(0,Ad-As)) 604 605 CONTRAST_NV (R,G,B,A) = 606 (Ad/2 + 2*(Rd-Ad/2)*(Rs'-As/2), 607 Ad/2 + 2*(Gd-Ad/2)*(Gs'-As/2), 608 Ad/2 + 2*(Bd-Ad/2)*(Bs'-As/2), 609 Ad) 610 611 INVERT_OVG_NV (R,G,B,A) = 612 (As*(1-Rd)+(1-As)*Rd, 613 As*(1-Gd)+(1-As)*Gd, 614 As*(1-Bd)+(1-As)*Bd, 615 As+Ad-As*Ad) 616 617 RED_NV (R,G,B,A) = (Rs', Gd, Bd, Ad) 618 619 GREEN_NV (R,G,B,A) = (Rd, Gs', Bd, Ad) 620 621 BLUE_NV (R,G,B,A) = (Rd, Gd, Bs', Ad) 622 623 Table X.4, Additional RGB Blend Equations 624 625 626 Advanced blending equations are supported only when rendering to a single 627 color buffer using fragment color zero. If any non-NONE draw buffer uses 628 a blend equation found in table X.2, X.3, or X.4, the error 629 INVALID_OPERATION is generated by [[Compatibility Profile: Begin or any 630 operation that implicitly calls Begin (such as DrawElements)]] [[Core 631 Profile: DrawArrays and the other drawing commands defined in section 632 2.8.3]] if: 633 634 * the draw buffer for color output zero selects multiple color buffers 635 (e.g., FRONT_AND_BACK in the default framebuffer); or 636 637 * the draw buffer for any other color output is not NONE. 638 639 [[ The following paragraph applies to NV_blend_equation_advanced only. ]] 640 641 When using advanced blending equations, applications should split their 642 rendering into a collection of blending passes, none of which touch an 643 individual sample more than once. The results of blending are undefined 644 if the sample being blended has been touched previously in the same pass. 645 The command 646 647 void BlendBarrierNV(void); 648 649 specifies a boundary between passes when using advanced blend equations. 650 Any command that causes the value of a sample to be modified is considered 651 to touch the sample, including clears, blended or unblended primitives, 652 BlitFramebuffer copies, and direct updates by commands such as 653 TexSubImage2D. 654 655 [[ The following paragraph applies to NV_blend_equation_advanced_coherent 656 only. ]] 657 658 When using advanced blending equations, blending is typically done 659 coherently and in primitive order. When an individual sample is covered 660 by multiple primitives, blending for that sample is performed sequentially 661 in the order in which the primitives were submitted. This coherent 662 blending is enabled by default, but can be enabled or disabled by calling 663 Enable or Disable with the symbolic constant BLEND_ADVANCED_COHERENT_NV. 664 If coherent blending is disabled, applications should split their 665 rendering into a collection of blending passes, none of which touch an 666 individual sample more than once. When coherent blending is disabled, the 667 results of blending are undefined if the sample being blended has been 668 touched previously in the same pass. The command 669 670 void BlendBarrierNV(void); 671 672 specifies a boundary between passes when using advanced blend equations. 673 Any command that causes the value of a sample to be modified is considered 674 to touch the sample, including clears, blended or unblended primitives, 675 BlitFramebuffer copies, and direct updates by commands such as 676 TexSubImage2D. 677 678 679Additions to Chapter 5 of the OpenGL 4.1 Specification (Special Functions) 680 681 None. 682 683Additions to Chapter 6 of the OpenGL 4.1 Specification (State and 684State Requests) 685 686 None. 687 688Additions to Appendix A of the OpenGL 4.1 Specification (Invariance) 689 690 None. 691 692Additions to the AGL/GLX/WGL/EGL Specifications 693 694 None. 695 696GLX Protocol 697 698 !!! TBD 699 700Dependencies on OpenGL 4.0 701 702 If OpenGL 4.0 is not supported, references to the BlendEquationi API should 703 be removed. 704 705Dependencies on OpenGL 4.1 (Core Profile) 706 707 This extension throws an INVALID_OPERATION when Begin is called if advanced 708 blend equations are used in conjunction with multiple draw buffers. For 709 the core profile of OpenGL 4.1 (and other versions of OpenGL), there is no 710 Begin command; instead, the error is thrown by other rendering commands 711 such as DrawArrays. The language in this specification documenting the 712 error has separate versions for the core and compatibility profiles. 713 714Dependencies on OpenGL 4.3 or later (any Profile) 715 716 References to Chapter 4 are replaced with references to Chapter 17 (Writing 717 Fragments and Samples to the Framebuffer). 718 References to section 4.1.8 are replaced with references to section 17.3.8. 719 References to Table 4.1 are replace with references to Table 17.1. 720 References to section 2.1.1 are replaced with references to section 2.3.3. 721 722Dependencies on OpenGL ES 2.0 723 724 If unextended OpenGL ES 2.0 is supported, references to BlendEquationi, 725 BlendEquationSeparatei, GetInteger64v, and GetDoublev should be ignored. 726 727 Ignore any references to multiple draw buffers if EXT_draw_buffers or 728 NV_draw_buffers is not supported. 729 730Dependencies on EXT_blend_minmax 731 732 Requires EXT_blend_minmax on OpenGL ES 2.0 implementations and references 733 to MIN and MAX should be replace by references to MIN_EXT and MAX_EXT as 734 introduced by that extension. 735 736Dependencies on OpenGL ES 3.0 737 738 If unextended OpenGL ES 3.0 is supported, references to BlendEquationi, 739 BlendEquationSeparatei, and GetDoublev should be ignored. 740 741Dependencies on NV_path_rendering 742 743 When NV_path_rendering is supported, covering geometry generated by the 744 commands CoverFillPathNV, CoverFillPathInstancedNV, CoverStrokePathNV, and 745 CoverStrokePathInstancedNV will automatically be blended coherently 746 relative to previous geometry when using the blend equations in this 747 extension. This guarantee is provided even on implementations supporting 748 only NV_blend_equation_advanced. 749 750 Insert the following language after the discussion of the BlendBarrierNV() 751 command for both extensions: 752 753 [[ For NV_blend_equation_advanced only: ]] 754 755 The commands CoverFillPathNV, CoverFillPathInstancedNV, 756 CoverStrokePathNV, and CoverStrokePathInstancedNV are considered to 757 start a new blending pass, as though BlendBarrierNV were called prior to 758 the cover operation. If a cover primitive is followed by subsequent 759 non-cover primitives using advanced blend equations and touching the 760 same samples, applications must call BlendBarrierNV after the cover 761 primitives to ensure defined blending results. 762 763 [[ For NV_blend_equation_advanced_coherent, the language immediately 764 above should be used, but the first sentence should be prefixed with 765 "When coherent blending is disabled, ...". ]] 766 767Errors 768 769 If any non-NONE draw buffer uses a blend equation found in table X.2, X.3, 770 or X.4, the error INVALID_OPERATION is generated by Begin or any operation 771 that implicitly calls Begin (such as DrawElements) if: 772 773 * the draw buffer for color output zero selects multiple color buffers 774 (e.g., FRONT_AND_BACK in the default framebuffer); or 775 776 * the draw buffer for any other color output is not NONE. 777 778 If BlendParameteriNV is called and <pname> is not 779 BLEND_PREMULTIPLIED_SRC_NV or BLEND_OVERLAP_NV the error INVALID_ENUM is 780 generated. 781 782 If BlendParameteriNV is called with <pname> set to 783 BLEND_PREMULTIPLIED_SRC_NV the error INVALID_ENUM is generated if <param> 784 is not TRUE or FALSE. 785 786 If BlendParameteriNV is called with <pname> set to BLEND_OVERLAP_NV the 787 error INVALID_ENUM is generated if <param> is not one of UNCORRELATED_NV, 788 DISJOINT_NV, or CONJOINT_NV. 789 790New State 791 Initial 792 Get Value Type Get Command Value Description Sec Attribute 793 -------------------- ---- ------------ ------------ ------------------------ ----- ------------ 794 BLEND_ADVANCED_ B IsEnabled TRUE are advanced blending 4.1.8 color-buffer 795 COHERENT_NV equations guaranteed to 796 be evaluated coherently? 797 BLEND_PREMULTIPLIED_ B GetBooleanv TRUE use premultiplied src 4.1.8 color-buffer 798 SRC_NV colors with advanced 799 blend equations 800 BLEND_OVERLAP_NV Z3 GetIntegerv UNCORRELATED correlation of src/dst 4.1.8 color-buffer 801 _NV coverage within a pixel 802 803 Note: The BLEND_ADVANCED_COHERENT_NV enable is provided if and only if 804 the NV_blend_equation_advanced_coherent extension is supported. On 805 implementations supporting only NV_blend_equation_advanced, this enable is 806 considered not to exist. 807 808New Implementation Dependent State 809 810 None. 811 812NVIDIA Implementation Details 813 814 Older versions of this extension specification and early shipping 815 implementations supported the COLORDODGE_NV and COLORBURN_NV equations 816 without the special case discussed in issue (34). This should be fixed for 817 newer driver releases. 818 819Issues 820 821 (1) How should these new blending operations be supported? 822 823 RESOLVED: Provide a separate blend equation for each of the various 824 blending operations. 825 826 (2) Many of these blending operations involve complicated computations on 827 the RGB color components, but corresponding alpha operations are 828 typically very simple. How should blending on the alpha channel work? 829 830 RESOLVED: Each new blend equation provides one equation for color and 831 another for alpha. In this extension, separate advanced blend equations 832 for color and alpha are not supported; BlendEquationSeparate does not 833 accept these enums. 834 835 This extension contemplated separate blend equations for RGB and alpha, 836 perhaps with only basic equations for alpha, but we chose to tie RGB and 837 alpha blending together for simplicity. 838 839 (3) Should we provide explicit support for premultiplied colors? 840 841 RESOLVED: Yes. Many of the imaging APIs supporting similar blend 842 equations use premultiplied colors, some exclusively. Additionally, 843 many equations are simpler to express and compute with premultiplied 844 colors. 845 846 In this extension, we choose to treat the destination colors and the 847 blend result as premultiplied. We considered providing a blend 848 parameter supporting non-premultiplied destinations, but chose to 849 support only premultiplied destinations for mathematical simplicity. 850 851 (4) Should we support blending where some, but not all, colors are 852 premultiplied? For example, there may be cases where the source 853 fragment colors are not premultiplied, but where the destination 854 colors are premultiplied. 855 856 RESOLVED: Yes, we will provide support for non-premultiplied fragment 857 colors (via a blending parameter), in which case the RGB color 858 components are multiplied by alpha prior to blending. 859 860 We considered requiring premultiplication in the fragment shader, but 861 opted to provide a fixed-function premultiply operation for cases where 862 it was inconvenient to modify the fragment shader to perform the 863 multiplication, or where no fragment shader is executed (e.g., 864 fixed-function fragment processing, blits via the NV_draw_texture 865 extension). 866 867 (5) Should we support different types of correlation between source and 868 destination coverage in partially covered pixels? If so, how? 869 870 RESOLVED: We will provide a blend parameter allowing for multiple 871 versions of many blending equations based on the "correlation" between 872 source and destination coverage. For pixels with partial opacity, there 873 might be three different blend cases: (a) where the portions of the 874 pixel covered by the primitives are considered to have minimal overlap 875 (e.g., abutting primitives in a mesh), (b) where the portions of the 876 pixel covered by the primitives are considered to have maximal overlap 877 (e.g., overlapping geometry), (c) where the portions of the pixel 878 covered by the primitives are considered uncorrelated. 879 880 (6) Should we support swapping source and destination coverage in advanced 881 blends? If so, how? 882 883 RESOLVED: In the current version, we don't support fully general 884 swapping. We do provide several pairs of blend equations that are 885 equivalent, other than swapping source and destination colors. For 886 example, we provide complementary blend equations SRC_OVER_NV, where the 887 source color is considered to be "over" the destination, and 888 DST_OVER_NV, where the destination color is considered to be "over the 889 source. Having pairs of equations such as "SRC_OVER" and "DST_OVER" 890 seems to be common practice in various imaging APIs. 891 892 Alternately, we could provide a blend parameter that simply swaps source 893 and destination for arbitrary blend equations. In the example above, we 894 could provide a single blend equation OVER_NV, where the source color is 895 considered "over" when unswapped and the destination color is considered 896 "over" when swapped. 897 898 (7) Should we generalize the blending operation, replacing the notions of 899 "source" and "destination" colors with more generic "A" and "B" 900 parameters, which might be obtained from a variety of sources 901 (fragment color, one of <N> color attachment points, some additional 902 source of textures/images)? 903 904 RESOLVED: Not in this extension; the only blending operation we support 905 takes a fragment color (which could be obtained from an arbitrary 906 source, either through a fragment shader, fixed function fragment 907 processing, or an imaging API such as NV_draw_texture) and a destination 908 color, performs a blend, and stores the result in the buffer from which 909 the destination color was extracted. 910 911 (8) How should we expose the various combinations of blending modes? 912 913 RESOLVED: The base blending equation is specified by the same 914 BlendEquation() API supported for regular OpenGL blending. Additional 915 parameters (such as pre-multiplied source colors, overlap mode, source 916 destination swapping, input selection) can be specified via the 917 BlendParameteriNV() API. 918 919 We could provide for a "general" blend equation API specifying multiple 920 parameters at once, such as: 921 922 void BlendEquationGeneralNV(enum blend, enum overlap, 923 boolean swapSrcDst); 924 925 but that API would require applications to pass parameters that are 926 always the same (e.g., overlap as UNCORRELATED_NV) and wouldn't be 927 easily extensible. Note that there are several features that we've 928 chosen not to include but might be usefully added as blend parameters in 929 the future -- see issues (3), (6), and (7), for example. 930 931 (9) What limitations apply to the new blend modes? 932 933 RESOLVED: In the current implementation, these blend equations are not 934 supported with more than one color buffer; if this is attempted, a 935 draw-time error is generated. This limitation is similar in nature to 936 one for dual-source blending, which implementations are not required to 937 support in conjunction with multiple color buffers. This limitation may 938 be relaxed in a future version of this extension. 939 940 (10) What precision is used in the computations for these blending 941 equations? 942 943 RESOLVED: There are no minimum precision requirements specified in 944 OpenGL 4.1, though one would expect implementations to blend with at 945 least the precision used to store destination color components. This 946 extension provides this as a minimum baseline for existing blending 947 equations. 948 949 For the new equations, we specify a minimum precision that is the 950 smaller of the precision of the destination buffer or the precision of 951 16-bit floating-point computations. For most formats, this meets the 952 limit for basic blend equations. However, there may be precision loss 953 if these new blending equations are used with 12-bit unsigned normalized 954 components, 16-bit unsigned or signed normalized components, or 32-bit 955 floating-point components. 956 957 This restriction is specified so that implementations are not required 958 to support the large number of blending equations specified here with 959 full 32-bit floating-point computations. 960 961 (11) When targeting a fixed-point buffer, are input color components 962 clamped to [-1,1] for signed normalized color buffers or to [0,1] for 963 unsigned normalized color buffers? 964 965 RESOLVED: We will use the same clamping behavior as for basic blend 966 equations, where fragment color components are clamped to [0,1] prior to 967 blending for unsigned normalized color targets. 968 969 Note that the OpenGL 4.1 specification, against which this spec is 970 written, had an oversight related signed normalized color buffers. It 971 specifies [0,1] clamping for all "fixed point" targets, which is clearly 972 not desired for signed normalized color buffers. Fragment shader color 973 outputs should be clamped to [-1,+1] in this case; this was fixed in 974 OpenGL 4.2 (bug 6849). 975 976 (12) What happens when converting a premultiplied color with an alpha of 977 zero to a non-premultiplied color? 978 979 RESOLVED: We specify that a premultiplied color of (0,0,0,0) should 980 produce non-premultiplied (R,G,B) values of (0,0,0). A premultiplied 981 color with an alpha of zero and a non-zero R, G, or B component is 982 considered to be ill-formed and will produce undefined blending results. 983 984 For a non-premultiplied color (R',G',B',A'), the corresponding 985 premultiplied color (R,G,B,A) should satisfy the equation: 986 987 (R,G,B,A) = (R'*A', G'*A', B'*A', A') 988 989 If the alpha of a non-premultiplied color is zero, the corresponding 990 premultiplied color (R,G,B,A) should be (0,0,0,0). 991 992 We specify that ill-formed premultiplied colors produce undefined 993 blending results to enable certain performance optimizations. In many 994 of these blending equations, the alpha component used as a denominator 995 to compute the non-premultiplied color ends up being multiplied by the 996 same alpha component in the coverage, resulting in cancellation. For 997 example, implementations may want to substitute a premultiplied 998 destination color into the last term of the basic blend equation: 999 1000 R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad) 1001 = ... + Z*Rd'*(Ad*(1-As)) 1002 = ... + Z*(Rd'*Ad)*(1-As) 1003 = ... + Z* Rd * (1-As) 1004 1005 This substitution would be invalid for ill-formed premultiplied 1006 destination colors. We choose to specify undefined results for invalid 1007 input colors rather than requiring implementations to skip such 1008 optimizations or include logic to check for zero alpha values for each 1009 input. 1010 1011 (13) Should we provide "advanced" RGB blend equations for modes commonly 1012 used in dedicated imaging APIs that can already be expressed with 1013 current OpenGL blending modes? 1014 1015 RESOLVED: Yes; we will provide a number of "advanced" blend equations 1016 for basic computations that can be done with existing blend equations. 1017 This allows applications wanting to use these advanced modes to use them 1018 exclusively, without having to figure out which blends are not supported 1019 and generate separate BlendEquation/BlendFunc state for each. 1020 1021 (14) How do the advanced RGB blend equations interact with sRGB color 1022 buffers? In particular, how does it interact with storing 1023 premultiplied color values in the framebuffer? 1024 1025 RESOLVED: When targeting an sRGB color buffer with the blend equations 1026 in this extension, we will convert the destination colors from sRGB to 1027 linear and will convert the linear blend result back to sRGB when 1028 writing it to the framebuffer. This approach is no different from 1029 regular blends. 1030 1031 sRGB conversions will affect premultiplied colors differently than 1032 non-premultiplied colors since: 1033 1034 linear_to_srgb(C*A) != A * linear_to_srgb(C) 1035 1036 When storing an sRGB-encoded value into an sRGB texture or renderbuffer, 1037 we expect that the values will be extracted as sRGB colors in a 1038 subsequent texturing, blending, or display operation. The fetched sRGB 1039 color components will be converted back to linear. Except from rounding 1040 errors in converting the color components to fixed-point, converting to 1041 and from sRGB will not modify the color, with or without 1042 premultiplication. 1043 1044 (15) The HSL blend equations are "color surgery" operations where 1045 components from the source and destination colors are mixed. Are 1046 there any problems using these equations with premultiplied color 1047 components? 1048 1049 RESOLVED: Like all of the "f/X/Y/Z" blends, the function f() in HSL 1050 blend equations are expressed in terms of non-premultiplied colors, 1051 which implies a division operation prior to evaluating f(). However, it 1052 may be possible to perform some or all of the blending operation using 1053 pre-multiplied colors directly. In particular, the luminosity and 1054 saturation of a color with components scaled by alpha is equal to alpha 1055 times the luminosity or saturation of the un-scaled color: 1056 1057 lumv3(C*A) = A * lumv3(C) 1058 satv3(C*A) = A * satv3(C) 1059 1060 (16) How should we express the blending equations? 1061 1062 RESOLVED: In general, we will use the formulation found in the PDF and 1063 SVG specifications, which define each blend in terms of four parameters: 1064 1065 * a function f(Cs,Cd) specifies the blended color contribution in the 1066 portion of the pixel containing both the source and destination; 1067 1068 * a constant X specifies whether the region containing both the source 1069 and destination contributes to the final alpha; 1070 1071 * a constant Y specifies whether the region containing only the source 1072 contributes to the final color and alpha; and 1073 1074 * a constant Z specifies whether the region containing only the 1075 destination contributes to the final color and alpha. 1076 1077 This formulation is relatively compact and nicely illustrates the 1078 contributions from the three relevant combinations of source and 1079 destination coverage; the portion of the pixel covered by neither the 1080 source nor the destination contributes nothing to color or alpha. 1081 1082 Additionally, we specify three functions p0(As,Ad), p1(As,Ad), and 1083 p2(As,Ad) specifying the relative portion of the pixel covered by both 1084 the source and destination, just the source, and just the destination, 1085 respectively. These functions are defined according to the overlap 1086 blend parameter; the most common mode (UNCORRELATED) defines: 1087 1088 p0(As,Ad) = As*Ad 1089 p1(As,Ad) = As*(1-Ad) 1090 p2(As,Ad) = Ad*(1-As) 1091 1092 There are certain special-purpose blending equations that don't fit 1093 this general model (modes that mix RGB or HSL components from the 1094 source and destination). These blends don't fit nicely into the 1095 mathematical formulas above and are instead defined separately as a 1096 component-by-component operation. 1097 1098 (17) How should we express the equations for the HSL blend equations? 1099 1100 RESOLVED: The equations used by this specification are loosely adapted 1101 from similar code in the version 1.7 of the PDF (Portable Document 1102 Format) specification. The equations have been modified to use 1103 GLSL-style "vec3" syntax. Additionally, they use vector math in the 1104 pseudocode overriding the saturation of a base color instead of using 1105 "C_min", "C_mid", and "C_max" syntax effectively defining references to 1106 the three components of the base color. 1107 1108 Alternately, we could have specified functions for converting (R,G,B) 1109 colors to and from an (H,S,L) color space. But we decided not to do 1110 that because actual (H,S,L) colors are never used in the pipeline. 1111 1112 (18) What issues apply to the PLUS and MINUS equations? 1113 1114 RESOLVED: The PLUS and MINUS equations provide arithmetically simple 1115 operations; we simply perform a component-wise add or subtract 1116 operations. The most interesting question is how and where clamping is 1117 performed. The original Porter-Duff compositing specification provided 1118 a "plus" equation intended to support blending between two images, 1119 effectively performing: 1120 1121 weight * image1 + (1-weight) * image2 1122 1123 If the components of <image1>, <image2>, and <weight> are all in [0,1], 1124 there is no need for clamping. However, in a general add with no 1125 <weight> built in, there is no guarantee that adding components of two 1126 images will remain inside the range [0,1]. When using fixed-point 1127 unsigned normalized color buffers, the sum will automatically be clamped 1128 to [0,1] when stored in the framebuffer. However, there may be cases 1129 with floating-point color buffers where not clamping the sum also makes 1130 sense. 1131 1132 Additionally, when storing premultiplied colors, it may also be 1133 desirable to clamp R/G/B components to the range [0,A]. Premultiplied 1134 colors effectively store "R*A" in the R channel, where "R" is the 1135 non-premultiplied color and A is alpha. Clamping this value to A 1136 ensures that the non-premultiplied form of R is in [0,1]. 1137 1138 To handle all possible cases, we provide five "PLUS" and "MINUS" 1139 equations. 1140 1141 PLUS_NV: Add color and alpha components without clamping. 1142 1143 PLUS_CLAMPED_NV: Add color and alpha components; clamp each sum to 1144 1.0. 1145 1146 PLUS_CLAMPED_ALPHA_NV: Add color and alpha components. Clamp the 1147 alpha sum to 1.0; clamp the color sums to the alpha result (i.e., the 1148 clamped alpha sum). Note that if premultiplied inputs are clamped 1149 properly where 0<=R,G,B<=A, this equation isn't needed since the color 1150 sums will always be less than the alpha sum. 1151 1152 MINUS_NV: Subtract the source color and alpha components from the 1153 destination without clamping. 1154 1155 MINUS_CLAMPED_NV: Subtract the source color and alpha components from 1156 the destination; clamp the difference to 0.0. 1157 1158 We don't bother clamping in "unexpected" direction. We don't bother 1159 clamping sums to be greater than or equal to zero or differences to be 1160 less than or equal to one; either case would require an unclamped input 1161 with a negative component. 1162 1163 Note that when blending to an unsigned fixed-point buffer, the clamped 1164 and non-clamped versions of "PLUS" and "MINUS" produce the same results, 1165 since inputs and outputs are both clamped to [0,1]. 1166 1167 Note that the LINEARDODGE_NV equation is another form of "PLUS"; in the 1168 area of intersection, the source and destination colors are added and 1169 clamped to 1.0. 1170 1171 (19) Should we provide a blend parameter to clamp the destination color 1172 (when read) to [0,1]? What about clamping premultiplied RGB 1173 components to [0,a]? 1174 1175 RESOLVED: No. We expect the most common use case to involve unsigned 1176 normalized color buffers, where components will automatically be clamped 1177 to [0,1] by virtue of how they're stored in the framebuffer. It doesn't 1178 seem worth the trouble to add a clamp-on-read feature to clamp to [0,a] 1179 when it seems easy enough to program colors to stay in range. 1180 1181 (20) Should we provide a blend parameter to clamp final color or alpha 1182 output components to [0,1]? What about clamping premultiplied RGB 1183 outputs to [0,a]? 1184 1185 RESOLVED: As above, when writing the blend results to unsigned 1186 normalized targets, output components will automatically be clamped to 1187 [0,1] by virtue of how they're stored in the framebuffer. It doesn't 1188 seem worth the trouble to clamp to [0,a], either. Most of the blend 1189 equations supported by this extension will produce outputs with 1190 premultiplied color component values in the range [0,a] as long as the 1191 inputs also have that property. One exception is PLUS_NV, but we 1192 explicitly provide a PLUS_CLAMPED_ALPHA_NV equation to for that case. 1193 1194 (21) Should we provide an equation like the VG_BLEND_SOFTLIGHT_SVG_KHR 1195 blending equation in the KHR_advanced_blending extension to OpenVG? 1196 1197 RESOLVED: No. The KHR_advanced_blending appears to have specified a 1198 equation implementing the "soft-light" compositing property in a working 1199 draft of a SVG 1.2 specification, as described here: 1200 1201 http://www.w3.org/TR/2004/WD-SVG12-20041027/ 1202 rendering.html#compositing 1203 1204 This version of the specification appears to have been abandoned. The 1205 equations for the "soft-light" property in the SVG Compositing 1206 Specification at: 1207 1208 http://www.w3.org/TR/SVGCompositing/ 1209 1210 match the SOFTLIGHT_NV equation provided by this extension and 1211 VG_BLEND_SOFTLIGHT_KHR (no "SVG") in KHR_advanced_blending. 1212 1213 Additionally, the equations in the SVG 1.2 draft and the 1214 KHR_advanced_blending extension both appear to contain clear errors in 1215 the first and second cases. Both begin with "(cd*(as-(1-cd/ad)*..." in 1216 the KHR spec but should be "(cd*(as+(1-cd/ad)*...". Both of these sign 1217 errors are corrected in the "SVG" functions in this extension. With the 1218 errors, there is a local minimum at Cs=0.5 (where we switch from the 1219 first form to the second or third) and the function has a major 1220 discontinuity at Cd=0.125 when Cs>0.5 (where we switch from the second 1221 form to the third). For example, when Cs=0.8 and Cd=0.125, the second 1222 form of the KHR extension would generate a result of -0.00625 and the 1223 third form would generate a result of ~0.26213. Note that the corrected 1224 equations still aren't continuous at Cd=0.125; the fixed second and 1225 third forms generate 0.25625 and 0.26213, respectively, when Cs=0.8 and 1226 Cd=0.125. 1227 1228 (22) What issues apply to the INVERT and INVERT_OVG_NV equations? 1229 1230 RESOLVED: The INVERT and INVERT_OVG_NV equations were included to 1231 provide functionality similar to the same VG_BLEND_INVERT_KHR blend 1232 equation provided by the KHR_advanced_blending extension to OpenVG and 1233 similar equations in a few other compositing APIs/standards. 1234 1235 Unfortunately, the equation specified by the KHR extension has issues. 1236 The apparent intent of this blend equation is to use the source alpha to 1237 blend between the destination color and an inverted form of the 1238 destination color. This description conceptually matches the 1239 description in the KHR extension: 1240 1241 (1 - asrc) * c'dst + asrc * (1 - c'dst) 1242 1243 However, since source and destination colors are premultiplied, the 1244 expression "1-c'dst" doesn't correctly invert the destination color. To 1245 invert a premultiplied destination color, "adst-c'dst" should be used. 1246 For example, if the premultiplied destination color is 50% gray and 50% 1247 opaque (adst=0.5), the RGBA destination color will be 1248 (0.25,0.25,0.25,0.5). Inverting the color components via "1-c'dst" 1249 would yield RGB component values of 0.75, which isn't consistent with an 1250 alpha of 0.5. Inverting via "adst-c'dst" would yield correct RGB 1251 component values of 0.25. 1252 1253 Additionally, the alpha computed for this equation in the KHR extension 1254 is the standard "asrc+adst*(1-asrc)", equivalent to X=Y=Z=1 in our 1255 normal formulation. However, given that the source color doesn't 1256 contribute at all, having "Y=1" doesn't make a whole lot of sense. The 1257 INVERT equation used in this extension uses X=Z=1 and Y=0, which means 1258 that blending with this equation never changes destination alpha. 1259 1260 We provide a separate blend equation INVERT_OVG_NV to provide 1261 compatibility with the formulation in the KHR extension. The math in 1262 the KHR extension does perform a "valid" blending operation -- it will 1263 produce results that remain in [0,1] when inputs are in [0,1], and its 1264 results are continuous. It can't be expressed directly via our f/X/Y/Z 1265 parameterization, but it does match our general f/X/Y/Z model if you 1266 consider all three areas to contribute where: 1267 1268 * the intersection area contributes the inverted destination color 1269 * the destination-only area contributes the destination color 1270 * the source-only area contributes full white 1271 1272 Note that INVERT and INVERT_OVG_NV equations are mathematically 1273 equivalent when the destination is opaque (i.e., adst=1.0); in this 1274 case, "1-c'dst" and "adst-c'dst" are equivalent. In our f/X/Y/Z model, 1275 the full destination coverage means there is no "source-only" area in 1276 this case. 1277 1278 (23) What issues apply to the PLUS_DARKER_NV blend equation? 1279 1280 RESOLVED: The PLUS_DARKER_NV equation corresponds to an equation 1281 provided in the Quartz 2D API from Apple. The public documentation for 1282 this equation specifies the color computed by this operation as: 1283 1284 R = MAX(0, 1 - ((1 - D) + (1 - S))) 1285 1286 This equation appears to want to invert the source and destination 1287 colors, add the two inverted colors, and then invert the result. 1288 1289 However, this equation appears to assume opaque source and destination 1290 colors. As noted in the discussion for INVERT_OVG_NV, inverting a color 1291 via "1-C" doesn't make any sense. We've reformulated the equations to 1292 use pre-multipled colors and invert with "A-C" in a manner similar to 1293 that described in this email thread: 1294 1295 http://www.mail-archive.com/whatwg@lists.whatwg.org/msg06536.html 1296 1297 which appears to be the "darker" mode implemented in the Safari browser 1298 (at least in 2007). Our formulation is equivalent to the one in the 1299 Quartz 2D documentation when As=Ad=1. 1300 1301 (24) Should we apply the f/X/Y/Z formulation to blend equations where the 1302 equations can be expressed this way only if one or more of X, Y, or 1303 Z are neither zero nor one? 1304 1305 RESOLVED: No. The f/X/Y/Z model subdivides a pixel into four regions 1306 based on the alpha of the source and the destination, three of which 1307 (intersection, source only, destination only) either contribute or don't 1308 contribute color and coverage based on the given blend equation. The 1309 figure below depicts a pixel where the source and destination both have 1310 coverage of 0.5 (50%). The picture assigns source coverage to the upper 1311 left portion of the pixel and the destination coverage to the upper 1312 right, and assumes an UNCORRELATED model. In this case, the pixel is 1313 divided into four areas of equal size. The area of intersection is at 1314 the top, and its color and coverage are controlled by the f() and X 1315 parameters. The source-only and destination-only regions are on the 1316 left and right, respectively, and color and coverage are both controlled 1317 by the Y and Z parameters. 1318 1319 +-----------+ 1320 |\_ f/X _/| 1321 source | \_ _/ | destination 1322 (upper ==>| Y \_/ Z | (upper 1323 left) | _/ \_ | <== right) 1324 | _/ \_ | 1325 |/ \| 1326 +-----------+ 1327 1328 The PLUS_NV equation could be expressed with f(Cs,Cd) = Cs+Cd, X=2, Y=1, 1329 and Z=1. The X=2 term effectively has the source and destination *both* 1330 contribute coverage in the area of intersection. The MINUS_NV equation 1331 could be expressed with f(Cs,Cd) = Cd-Cs, X=1, Y=-1, and Z=1. The Y=-1 1332 term effectively has the source-only portion of the pixel *remove* 1333 coverage. Both of these don't match the physical model, and would yield 1334 odd results when combined with conjoint or disjoint overlap modes. 1335 1336 (25) Should we provide more specialized versions of CONJOINT_NV and 1337 DISJOINT_NV? 1338 1339 RESOLVED: Not in this extension. In the future, we could add new 1340 overlap modes such as: 1341 1342 NON_INTERSECTING_NV: Like DISJOINT_NV, except that it assumes that 1343 As+Ad<=1. This might be interesting when rendering polygons with 1344 POLYGON_SMOOTH? 1345 1346 DST_INSIDE_NV, SRC_INSIDE_NV: Like CONJOINT_NV, except that it 1347 assumes that the destination coverage is fully inside the source or 1348 vice versa. For DST_INSIDE, the p0/p1/p2 terms would be Ad, As-Ad, 1349 and 0, respectively. 1350 1351 For all three of these modes, the specialized versions would have 1352 simpler and possibly more efficient math. We're not going to add any of 1353 these modes in this extension, however. 1354 1355 (26) Should the blend equations have a common prefix (e.g., 1356 "BLEND_SRC_OVER") or just use forms without a prefix? 1357 1358 RESOLVED: Use forms without a prefix where the tokens are only used in 1359 the context of blending (i.e., via the BlendEquation API). We will use 1360 a "BLEND_" prefix to identify BlendParameter <pname> values because 1361 those tokens can also be used in the general GetIntegerv API. Note that 1362 in current OpenGL, some parameters have their own Get* API (e.g., 1363 TexParameter), while others use the general GetInteger queries (e.g., 1364 PointParameter). 1365 1366 (27) Should we use standard GL enums for the blend equations that already 1367 have these names? 1368 1369 RESOLVED: Yes, to minimize the number of new enums. The primary risk 1370 is that reusing standard enum definitions would be problematic if a 1371 future core version wanted to use these parameters in the same place 1372 with a different meaning. However, all such names are in common use in 1373 various compositing standards and our semantics are consistent with 1374 those standards. 1375 1376 (28) What other APIs support blend equations similar to the ones provided 1377 here, and how does the feature set compare? 1378 1379 RESOLVED: Khronos' OpenVG 1.1 vector graphics library provides a 1380 variety of basic blending equations, with additional modes provided by 1381 the KHR_advanced_blending extension: 1382 1383 * http://www.khronos.org/registry/vg/specs/openvg-1.1.pdf 1384 * http://www.khronos.org/registry/vg/extensions/KHR/advanced_blending.txt 1385 1386 The World Wide Web Consortium (W3C)'s Scalable Vector Graphics format 1387 supports a variety of blending equations in its compositing 1388 specification: 1389 1390 * http://www.w3.org/TR/SVGCompositing 1391 1392 W3C also has a CSS standard (Compositing and Blending Level 1): 1393 1394 * http://www.w3.org/TR/compositing-1/ 1395 1396 Adobe's widely-used Portable Document Format (PDF) specification 1397 provides numerous blending equations in its "Transparency" section: 1398 1399 * http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/ 1400 pdf_reference_1-7.pdf 1401 1402 Adobe's SWF (Flash) File Format Specification 1403 1404 * http://www.adobe.com/go/swfspec 1405 1406 Various "2D" graphics APIs, including Oracle's JavaFX, Apple's Quartz 1407 2D, Qt's QPainter class, and X Window System's X Rendering Extension 1408 also support a variety of blending equations: 1409 1410 * http://docs.oracle.com/javafx/2/api/javafx/scene/effect/BlendMode.html 1411 1412 * http://developer.apple.com/library/ios/#documentation/GraphicsImaging/ 1413 Reference/CGContext/Reference/reference.html 1414 1415 * http://doc.qt.digia.com/4.7/qpainter.html#composition-modes 1416 1417 * http://www.x.org/releases/current/doc/renderproto/renderproto.txt 1418 1419 The following table indicates the set of blend equations from this 1420 extension that are supported in these various standards or APIs. "X" 1421 indicates that the equation is supported. For OpenVG, "E" indicates 1422 that the equation is supported by the KHR_advanced_blending extension. 1423 "XO" that the indicates that the equation is supported with conjoint and 1424 disjoint overlap modes; others support only the uncorrelated overlap 1425 mode. 1426 1427 Blending Equation OVG SVG PDF SWF JFX Q2D QPT XRE 1428 -------------------- ----- ----- ----- ----- ----- ----- ----- ----- 1429 ZERO E X - - - X X XO 1430 SRC_NV X X - X - X X XO 1431 DST_NV E X - - - - X XO 1432 SRC_OVER_NV X X X X X X X XO 1433 DST_OVER_NV X X - - - X X XO 1434 SRC_IN_NV X X - - - X X XO 1435 DST_IN_NV X X - X - X X XO 1436 SRC_OUT_NV E X - - - X X XO 1437 DST_OUT_NV E X - X - X X XO 1438 SRC_ATOP_NV E X - - X X X XO 1439 DST_ATOP_NV E X - - - X X XO 1440 XOR_NV E X - - - X X XO 1441 MULTIPLY_NV X X X X X X X X 1442 SCREEN_NV X X X X X X X X 1443 OVERLAY_NV E X X X X X X X 1444 DARKEN_NV X X X X X X X X 1445 LIGHTEN_NV X X X X X X X X 1446 COLORDODGE_NV E X X - X X X X 1447 COLORBURN_NV E X X - X X X X 1448 HARDLIGHT_NV E X X X X X X X 1449 SOFTLIGHT_NV E X X - X X X X 1450 DIFFERENCE_NV E X X X X X X X 1451 EXCLUSION_NV E X X - X X X X 1452 INVERT - - - X - - - - 1453 INVERT_RGB_NV - - - - - - - - 1454 LINEARDODGE_NV E - - - - - - - 1455 LINEARBURN_NV E - - - - - - - 1456 VIVIDLIGHT_NV E - - - - - - - 1457 LINEARLIGHT_NV E - - - - - - - 1458 PINLIGHT_NV E - - - - - - - 1459 HARDMIX_NV E - - - - - - - 1460 HSL_HUE_NV - - X - - X - X 1461 HSL_SATURATION_NV - - X - - X - X 1462 HSL_COLOR_NV - - X - - X - X 1463 HSL_LUMINOSITY_NV - - X - - X - X 1464 PLUS_NV / 1465 PLUS_CLAMPED_NV / X X - X X X X X 1466 PLUS_CLAMPED_ALPHA_NV 1467 PLUS_DARKER_NV - - - - - X - - 1468 MINUS_NV / E - - X - - - - 1469 MINUS_CLAMPED_NV 1470 CONTRAST_NV - - - - - - - - 1471 INVERT_OVG_NV E - - - - - - - 1472 RED_NV - - - - X - - - 1473 GREEN_NV - - - - X - - - 1474 BLUE_NV - - - - X - - - 1475 1476 OpenGL COLOR_LOGIC_OP - - - - - - X - 1477 (not in this extension) 1478 1479 Notes: 1480 1481 * The PLUS_NV, PLUS_CLAMPED_NV, and PLUS_CLAMPED_ALPHA_NV equations 1482 are very similar and may be indistinguishable when the destination 1483 buffer components are stored in normalized [0,1] numeric spaces, as 1484 is the case in most of these standards. The MINUS_NV and 1485 MINUS_CLAMPED_NV equations behave similarly. 1486 1487 * The SWF specification has a mode called "invert", but it's not clear 1488 whether the mode is implemented using INVERT, INVERT_OVG_NV, or some 1489 other equation. 1490 1491 (29) Should we provide an extension that can be supported on 1492 implementations that may not provide fully coherent blending when 1493 using the new equations? If so, how will this support be provided 1494 and what limitations apply? 1495 1496 RESOLVED: Yes, this functionality is useful not just for general 3D 1497 rendering, but also for 2D rendering operations (where the primitives 1498 rendered may be less complex). As indicated in the issue above, the 1499 blend equations provided by this extension are already very commonly 1500 used in 2D rendering. Accelerating them on a wide range of GPUs, old 1501 and new, would be very useful. 1502 1503 Older NVIDIA GPUs are able to support these blending equations as long 1504 as rendering is split into distinct passes and no pixel is touched more 1505 than once in any given pass. For such GPUs, we specify that the results 1506 of blending are undefined if a single pixel (or sample) is touched more 1507 than once in a pass, and provide the command BlendBarrierNV() to allow 1508 applications to delimit boundaries between passes. As long as rendering 1509 commands can be split into passes with barriers, advanced blending will 1510 work "normally" even on these older GPUs. 1511 1512 Since there are two distinct levels of capability, we will advertise two 1513 different extension string entries: 1514 1515 - GL_NV_blend_equation_advanced: Provides the new blending 1516 functionality without support for full coherence (older GPUs). 1517 1518 - GL_NV_blend_equation_advanced_coherent: Provides the new blending 1519 functionality with full coherence. 1520 1521 Since the functionality of these two extensions is nearly identical, we 1522 document them in a single extension specification. 1523 1524 (30) On implementations that don't support fully coherent blending, should 1525 we provide any convenience features so that "2D" applications aren't 1526 required to manually sprinkle BlendBarrierNV() throughout the code? 1527 1528 RESOLVED: Yes. When using NV_blend_equation_advanced in conjunction 1529 with NV_path_rendering commands like CoverFillPathNV and 1530 CoverStrokePathNV, the driver will assist in ensuring coherent and 1531 properly ordered blending by inserting implicit blend barriers before 1532 rendering each cover primitive. 1533 1534 (31) When we generate fragments using the automatic coherence guarantees 1535 from NV_path_rendering commands like CoverFillPathNV, what happens if 1536 a pixel touched by CoverFillPathNV had already been touched by a 1537 previous non-NVpr rendering command without an intervening call to 1538 BlendBarrierNV? What happens if a pixel touched by CoverFillPathNV 1539 is subsequently touched by a subsequent non-NVpr without an 1540 intervening call to BlendBarrierNV? 1541 1542 RESOLVED: We specify that a blend barrier is inserted prior to each 1543 cover primitives, so that cover primitives are blended coherently 1544 relative to geometry from previous primitives (cover or otherwise). We 1545 do not guarantee that a blend barrier is inserted after each cover 1546 primitive, so applications need to call BlendBarrierNV manually if 1547 subsequent non-cover primitives are rendered to the same set of pixels. 1548 1549 (32) On implementations supporting fully coherent blending, should we 1550 provide some mode allowing implementations to opt out of coherent 1551 blending? 1552 1553 RESOLVED: Yes. We will provide an enable allowing applications to 1554 disable coherent blending in case where (a) implementations are able to 1555 provide higher-performance implementations if they don't have to worry 1556 about full coherence and/or ordering and (b) applications are willing to 1557 use BlendBarrierNV() to take advantage of the higher-performance 1558 implementation. The enable will be on by default, which means that 1559 advanced blending on fully capable implementations will be "safe" unless 1560 explicitly disabled. 1561 1562 (33) When fully coherent blending is disabled or not supported, 1563 BlendBarrierNV() is used to indicate boundaries between passes. 1564 Should any other commands in the OpenGL API also implicitly serve as 1565 blend barriers? 1566 1567 RESOLVED: In general, no. Except for the NV_path_rendering case above, 1568 we will require applications manually use BlendBarrierNV(). There may 1569 be other operations that indirectly cause blend results to become 1570 coherent (in an implementation-dependent way), but we don't attempt to 1571 provide any explicit guarantees. Except for path rendering cover 1572 primitives (see issues 30 and 31), applications should always call 1573 BlendBarrierNV() between possibly overlapping passes. 1574 1575 Note that implementations of this extension may use texture mapping 1576 hardware to source the framebuffer for blending and may end up caching 1577 pre-blended texel values. This can cause subsequent texture fetches to 1578 return stale values unless the texture is re-bound, the 1579 TextureBarrierNV() command from the NV_texture_barrier extension is 1580 used, or some other action is taken to break the "rendering feedback 1581 loop". The existing spec already defines that texel fetches produce 1582 undefined results when a texture object is bound both as a texture and 1583 attached to the current draw framebuffer, with or without advanced blend 1584 equations. See the "Rendering Feedback Loops" section (p. 316 in the 1585 OpenGL 4.1 Compatibility Profile specification) for more information. 1586 1587 (34) How should the blend equations COLORDODGE_NV and COLORBURN_NV be 1588 expressed mathematically? 1589 1590 RESOLVED: We changed the definition of these equations after the 1591 NV_blend_equation_advanced spec was originally published, as discussed 1592 below. These changes add new special cases to the COLORDODGE_NV and 1593 COLORBURN_NV equations that are found in newer compositing standard 1594 specifications and in a number of implementations of old and new 1595 standards. We believe that the omission of the special case in other 1596 older specifications is a bug. We have no plans to add new blend 1597 equation tokens to support "equivalent" modes without the new special 1598 case. 1599 1600 Note, however, that older versions of this extension and older NVIDIA 1601 drivers implementing it will lack these special cases. A driver update 1602 may be required to get the new behavior. 1603 1604 There is some disagreement in different published specifications about 1605 how these two blend equations should be handled. At the time this 1606 extension was initially developed, all specifications we found that 1607 specified blending equations mathematically (see issue 28) were written 1608 the same way. Since then, we discovered that newer working drafts of 1609 the W3C Compositing and Blending Level 1 specification (for CSS and SVG) 1610 express "color-burn" as follows (translated to our nomenclature): 1611 1612 if (Cd == 1) // their Cb (backdrop) is our Cd (destination) 1613 f(Cs,Cd) = 1 // their B() is our f() 1614 else if (Cs == 0) 1615 f(Cs,Cd) = 0 1616 else 1617 f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs) 1618 1619 http://www.w3.org/TR/2013/WD-compositing-1-20131010/ 1620 #blendingcolorburn 1621 1622 Earlier versions of the same W3C specification, an older SVG compositing 1623 draft specification, the Adobe PDF specification (and the ISO 32000-1 1624 standard), and the KHR_advanced_blending extension to OpenVG all specify 1625 the following equation without the initial special case: 1626 1627 if (Cs == 0) 1628 f(Cs,Cd) = 0 1629 else 1630 f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs) 1631 1632 http://www.w3.org/TR/2012/WD-compositing-20120816/ 1633 #blendingcolorburn 1634 http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/ 1635 http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/ 1636 pdfs/pdf_reference_1-7.pdf 1637 http://www.khronos.org/registry/vg/extensions/KHR/ 1638 advanced_blending.txt 1639 1640 For the Adobe PDF specification, the corrected blend equations are 1641 published in an Adobe supplement to ISO 32000-1 and are expected to be 1642 accepted in a future version of the standard: 1643 1644 http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/ 1645 devnet/pdf/pdfs/adobe_supplement_iso32000_1.pdf 1646 1647 The author's understanding is that multiple shipping implementations of 1648 these blending modes implement the special case for "Cd==1" above, 1649 including various Adobe products and the open-source Ghostscript 1650 project. 1651 1652 We believe that the extra special case in this specification is 1653 consistent with the physical model of color burning. Burning is 1654 described in 1655 1656 http://en.wikipedia.org/wiki/Dodging_and_burning 1657 1658 as making a print with normal exposure, and then adding additional 1659 exposure to darken the overall image. In the general equation: 1660 1661 1 - min(1, (1-Cd)/Cs) 1662 1663 Cs operates as a sort of fudge factor where a value of 1.0 implies no 1664 additional exposure time and 0.0 implies arbitrarily long additional 1665 exposure time, where the initial amount of exposure (1-Cd) is multiplied 1666 by 1/Cs and then clamped to maximum exposure by the min() operation. 1667 The Cd==1 special case here implies that we get zero exposure in the 1668 initial print, since 1-Cd==0. No amount of extra exposure time will 1669 generate any additional exposure. This would imply that the final 1670 result should have zero exposure and thus a final f() value of 1. This 1671 matches the initial special case. Without that special case, we would 1672 hit the second special case if Cs==0 (infinite exposure time), which 1673 would yield an incorrect final value of 0 (full exposure). 1674 1675 A similar issue applies to COLORDODGE_NV, where some specifications 1676 include a special case for Cb==0 while others do not. We have added a 1677 special case there as well. 1678 1679 (35) For "HSL" blend equations, the blend equation involves a clipping 1680 step where colors may be "clipped" if the blend would produce 1681 components are outside the range [0,1]. Are there inputs where this 1682 blend could produce ill-defined or nonsensical results? 1683 1684 RESOLVED: Yes, the results of HSL blend equations are undefined if the 1685 input colors have components outside the range [0,1]. Even if the input 1686 colors are in-range, the basic color adjustment done in these blends 1687 could produce result components outside the range [0,1]. To compensate, 1688 the ClipColor() function in the specification interpolates the result 1689 color and a greyscale value that matches the luminance of the result. 1690 The math for the clipping operation assumes the luminance of the result 1691 color is in the range [0,1]. If that isn't the case, the clipping 1692 operation could result in a divide by zero (when all result components 1693 have the same out-of-bounds value) or perform an otherwise nonsensical 1694 computation. 1695 1696 1697Revision History 1698 1699 Rev. Date Author Changes 1700 ---- -------- -------- ---------------------------------------------- 1701 10 02/14/18 pdaniell Fix ClipColor() equation where in the 1702 "if (maxcol > 1.0)" body the "(color-lum)*lum" 1703 term should have been "(color-lum)*(1-lum)". 1704 Also add new issue 35 for the case where the 1705 inputs to SetLum() are outside the range 1706 [0..1] and could cause a divide-by-zero in 1707 ClipColor(). 1708 1709 9 09/30/14 pbrown Fix incorrectly specified color clamping in 1710 the HSL blend modes. 1711 1712 8 02/26/14 pbrown For non-coherent blending, clarify that all 1713 writes to a sample are considered to "touch" 1714 that sample and require a BlendBarrierOES call 1715 before blending overlapping geometry. Clears, 1716 non-blended geometry, and copies by 1717 BlitFramebuffer or TexSubImage are all 1718 considered to "touch" a sample (bug 11738). 1719 Specify that non-premultiplied values 1720 corresponding to ill-conditioned premultiplied 1721 colors such as (1,1,1,0) are undefined (bug 1722 11739). Update issue (12) related to 1723 ill-conditioned premultiplied colors. 1724 1725 7 11/06/13 pbrown Fix the language about non-coherent blending 1726 to specify that results are undefined only if an 1727 individual *sample* is touched more than once 1728 (instead of *pixel*). Minor language tweaks to 1729 use "equations" consistently, instead of 1730 sometimes using "modes". 1731 1732 6 10/21/13 pbrown Add NV-suffixed names for tokens reusing values 1733 from core OpenGL enums (XOR, RED, GREEN, BLUE) 1734 that are not in core OpenGL ES 2.0. This allows 1735 code targeting both APIs to use the same 1736 NV-suffixed #defines. Some older versions of 1737 the OpenGL "glext.h" header will not have the 1738 NV-suffixed names. 1739 1740 5 10/21/13 pbrown Add a reference to the Adobe supplement to 1741 ISO 32000-1, which includes the corrected 1742 equations for COLORDODGE_NV and COLORBURN_NV. 1743 Move "NVIDIA Implementation Details" down 1744 a bit in the spec. 1745 1746 4 10/16/13 pbrown Modify the definition of COLORDODGE_NV and 1747 COLORBURN_NV to match de facto standard 1748 implemenations and new CSS/SVG compositing 1749 spec; add issue (34). 1750 1751 3 08/19/13 pbrown Fix typos in the OpenGL ES 2.0 and 3.0 1752 interactions sections. 1753 1754 2 07/25/13 mjk Add W3C CSS compositing reference. 1755 1756 1 pbrown Internal revisions. 1757