Difference between revisions of "Blending functions"
Haiddasalami (Talk | contribs) (Created page with "Here are all the Photoshop Blending Modes, in easy to use functions for various languages. ==HLSL== ===Category 1 (Darker)=== <pre>float4 Darken (float4 cBase, float4 cBlend)...") |
Millennium (Talk | contribs) m (→Category 3 (Complex)) |
||
(One intermediate revision by the same user not shown) | |||
Line 51: | Line 51: | ||
===Category 3 (Complex)=== | ===Category 3 (Complex)=== | ||
− | + | ||
− | + | ==== Condintional statements in shaders ==== | |
− | + | [http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html GPUs hate branching], so it's better to avoid '''if..else''' in your shaders. The promblem here is that GPU will execute both blocks of code anyway - for then and else respectively - eventually a part of calculations will be thrown away (the more unnecessary instructions executed, the lower shader performance will be). In most of the cases conditional statements could be substituted with a help of [https://msdn.microsoft.com/en-us/library/windows/desktop/ff471376(v=vs.85).aspx HLSL's intrinsic functions]. | |
+ | |||
+ | Let's optimize the following piece of code: | ||
+ | <pre> | ||
float4 cNew; | float4 cNew; | ||
if (cBase.r > .5) { cNew.r = 1 - (1 - 2 * (cBase.r - .5)) * (1 - cBlend.r); } | if (cBase.r > .5) { cNew.r = 1 - (1 - 2 * (cBase.r - .5)) * (1 - cBlend.r); } | ||
Line 63: | Line 66: | ||
if (cBase.b > .5) { cNew.b = 1 - (1 - 2 * (cBase.b - .5)) * (1 - cBlend.b); } | if (cBase.b > .5) { cNew.b = 1 - (1 - 2 * (cBase.b - .5)) * (1 - cBlend.b); } | ||
else { cNew.b = (2 * cBase.b) * cBlend.b; } | else { cNew.b = (2 * cBase.b) * cBlend.b; } | ||
− | + | </pre> | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | As we see the result values of R, G and B components (except for alpha) for this blending mode depend on it's base layer initial values | |
− | + | <pre> | |
− | + | if (baseColor > .5) then { | |
− | + | resultColor = A; | |
− | + | } else { | |
− | + | resultColor = B; | |
− | + | } | |
− | + | </pre> | |
− | + | ||
− | + | ||
− | + | ||
+ | Using of [https://msdn.microsoft.com/en-us/library/windows/desktop/bb509618(v=vs.85).aspx lerp(A, B, interpolation_value)] - linear interpolation - function makes it simpler to switch between two branches. | ||
+ | <pre> | ||
+ | float4 newColor = lerp(A, B, interpolation_value); // = A*(1 - interpolation_value) + B*interpolation_value | ||
+ | </pre> | ||
+ | |||
+ | Actually we don't want newColor to gradually change between A and B, but only switch A <-> B, so interpolation_value must be strictly equal to 0 or 1. And here is where the [https://msdn.microsoft.com/en-us/library/windows/desktop/bb509665(v=vs.85).aspx step(x, y)] function comes in. The equivalent for '''step''' functionality is: | ||
+ | <pre> | ||
+ | float step(x, y) { | ||
+ | if (x > y) then { | ||
+ | return 0; | ||
+ | } else { | ||
+ | return 1; | ||
+ | } | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | Apparently, if it's required to invert output values, we just should change the order of '''step''' input arguments. Let's assembly all the information we've found out and re-write our shader: | ||
+ | <pre> | ||
+ | float isLessOrEq = step(cBase, 0.5); | ||
+ | float4 cNew = lerp(1. - (1. - 2.*(cBase - .5))*(1. - cBlend), 2*cBase*cBlend, isLessOrEq); // get rid of per component calculations and using vectorization | ||
+ | // for performance optimization sake | ||
+ | cNew.a = 1.; // restore alpha | ||
+ | </pre> | ||
+ | |||
+ | P.S. In a special case, when one of the possible values of '''cNew''' is 0, there is no more need in '''lerp''' | ||
+ | <pre> | ||
+ | float isLessOrEq = step(cBase, 0.5); | ||
+ | float4 cNew = isLessOrEq * 2*cBase*cBlend; // = (x <= 0.5) ? 2*cBase*cBlend : 0; | ||
+ | </pre> | ||
+ | |||
+ | P.P.S. Although compiler will do this work for you at the optimization stage, keep in mind that explicit variables declaration as '''float''' (1.0, 1. or 1.f insted of 1) is more preferable then writing expressions with variables of different types and, in result, mixing '''float''' with '''int'''. It causes implicit type conversion, which sometimes leads to [http://media.moddb.com/images/members/1/691/690410/G-Mans_Ghost.jpg unforeseen consequences]. | ||
+ | |||
+ | |||
+ | ==== Shaders implementation ==== | ||
+ | <pre>float4 Overlay (float4 cBase, float4 cBlend) | ||
+ | { | ||
+ | float isLessOrEq = step(cBase, .5); | ||
+ | float4 cNew = lerp(2*cBlend*cBase, 1 - (1 - 2*(Base - .5))*(1 - Blend), isLessOrEq); | ||
cNew.a = 1.0; | cNew.a = 1.0; | ||
return cNew; | return cNew; | ||
Line 92: | Line 121: | ||
<pre>float4 SoftLight (float4 cBase, float4 cBlend) | <pre>float4 SoftLight (float4 cBase, float4 cBlend) | ||
{ | { | ||
− | + | float isLessOrEq = step(cBlend, .5); | |
− | + | float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend*cBase), cBase*(1 - (1 - cBase)*(1 - 2*cBlend)), isLessOrEq); | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
cNew.a = 1.0; | cNew.a = 1.0; | ||
return cNew; | return cNew; | ||
Line 108: | Line 129: | ||
<pre>float4 HardLight (float4 cBase, float4 cBlend) | <pre>float4 HardLight (float4 cBase, float4 cBlend) | ||
{ | { | ||
− | + | float isLessOrEq = step(cBlend, .5); | |
− | + | float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend), 2*cBlend*cBase, isLessOrEq); | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
cNew.a = 1.0; | cNew.a = 1.0; | ||
return cNew; | return cNew; | ||
Line 124: | Line 137: | ||
<pre>float4 VividLight (float4 cBase, float4 cBlend) | <pre>float4 VividLight (float4 cBase, float4 cBlend) | ||
{ | { | ||
− | + | float isLessOrEq = step(cBlend, .5); | |
− | + | float4 cNew = lerp(1 - (1 - cBase)/(2*(cBlend - .5)), cBase/(1 - 2*cBlend), isGreaterThen); | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
cNew.a = 1.0; | cNew.a = 1.0; | ||
return cNew; | return cNew; | ||
Line 140: | Line 145: | ||
<pre>float4 LinearLight (float4 cBase, float4 cBlend) | <pre>float4 LinearLight (float4 cBase, float4 cBlend) | ||
{ | { | ||
− | + | float isLessOrEq = step(cBlend, .5); | |
− | + | float4 cNew = lerp(cBase + 2*(cBlend - .5), cBase + 2*cBlend - 1., isLessOrEq); | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
cNew.a = 1.0; | cNew.a = 1.0; | ||
return cNew; | return cNew; | ||
Line 156: | Line 153: | ||
<pre>float4 PinLight (float4 cBase, float4 cBlend) | <pre>float4 PinLight (float4 cBase, float4 cBlend) | ||
{ | { | ||
− | + | float isLessOrEq = step(cBlend, .5); | |
− | + | float4 cNew = lerp(max(cBase, 2*(cBlend - .5)), min(cBase, 2*cBlend), isLessOrEq); | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
cNew.a = 1.0; | cNew.a = 1.0; | ||
return cNew; | return cNew; |
Latest revision as of 07:03, 14 October 2015
Here are all the Photoshop Blending Modes, in easy to use functions for various languages.
Contents
HLSL
Category 1 (Darker)
float4 Darken (float4 cBase, float4 cBlend) { float4 cNew; cNew.rgb = min(cBase.rgb, cBlend.rgb); cNew.a = 1.0; return cNew; }
float4 Multiply (float4 cBase, float4 cBlend) { return (cBase * cBlend); }
float4 ColorBurn (float4 cBase, float4 cBlend) { return (1 - (1 - cBase) / cBlend); }
float4 LinearBurn (float4 cBase, float4 CBlend) { return (cBase + cBlend - 1); }
Category 2 (Lighter)
float4 Lighten (float4 cBase, float4 cBlend) { float4 cNew; cNew.rgb = max(cBase.rgb, cBlend.rgb); cNew.a = 1.0; return cNew; }
float4 Screen (float4 cBase, float4 cBlend) { return (1 - (1 - cBase) * (1 - cBlend)); }
float4 ColorDodge (float4 cBase, float4 cBlend) { return (cBase / (1 - cBlend)); }
float4 LinearDodge (float4 cBase, float4 cBlend) { return (cBase + cBlend); }
Category 3 (Complex)
Condintional statements in shaders
GPUs hate branching, so it's better to avoid if..else in your shaders. The promblem here is that GPU will execute both blocks of code anyway - for then and else respectively - eventually a part of calculations will be thrown away (the more unnecessary instructions executed, the lower shader performance will be). In most of the cases conditional statements could be substituted with a help of HLSL's intrinsic functions.
Let's optimize the following piece of code:
float4 cNew; if (cBase.r > .5) { cNew.r = 1 - (1 - 2 * (cBase.r - .5)) * (1 - cBlend.r); } else { cNew.r = (2 * cBase.r) * cBlend.r; } if (cBase.g > .5) { cNew.g = 1 - (1 - 2 * (cBase.g - .5)) * (1 - cBlend.g); } else { cNew.g = (2 * cBase.g) * cBlend.g; } if (cBase.b > .5) { cNew.b = 1 - (1 - 2 * (cBase.b - .5)) * (1 - cBlend.b); } else { cNew.b = (2 * cBase.b) * cBlend.b; }
As we see the result values of R, G and B components (except for alpha) for this blending mode depend on it's base layer initial values
if (baseColor > .5) then { resultColor = A; } else { resultColor = B; }
Using of lerp(A, B, interpolation_value) - linear interpolation - function makes it simpler to switch between two branches.
float4 newColor = lerp(A, B, interpolation_value); // = A*(1 - interpolation_value) + B*interpolation_value
Actually we don't want newColor to gradually change between A and B, but only switch A <-> B, so interpolation_value must be strictly equal to 0 or 1. And here is where the step(x, y) function comes in. The equivalent for step functionality is:
float step(x, y) { if (x > y) then { return 0; } else { return 1; } }
Apparently, if it's required to invert output values, we just should change the order of step input arguments. Let's assembly all the information we've found out and re-write our shader:
float isLessOrEq = step(cBase, 0.5); float4 cNew = lerp(1. - (1. - 2.*(cBase - .5))*(1. - cBlend), 2*cBase*cBlend, isLessOrEq); // get rid of per component calculations and using vectorization // for performance optimization sake cNew.a = 1.; // restore alpha
P.S. In a special case, when one of the possible values of cNew is 0, there is no more need in lerp
float isLessOrEq = step(cBase, 0.5); float4 cNew = isLessOrEq * 2*cBase*cBlend; // = (x <= 0.5) ? 2*cBase*cBlend : 0;
P.P.S. Although compiler will do this work for you at the optimization stage, keep in mind that explicit variables declaration as float (1.0, 1. or 1.f insted of 1) is more preferable then writing expressions with variables of different types and, in result, mixing float with int. It causes implicit type conversion, which sometimes leads to unforeseen consequences.
Shaders implementation
float4 Overlay (float4 cBase, float4 cBlend) { float isLessOrEq = step(cBase, .5); float4 cNew = lerp(2*cBlend*cBase, 1 - (1 - 2*(Base - .5))*(1 - Blend), isLessOrEq); cNew.a = 1.0; return cNew; }
float4 SoftLight (float4 cBase, float4 cBlend) { float isLessOrEq = step(cBlend, .5); float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend*cBase), cBase*(1 - (1 - cBase)*(1 - 2*cBlend)), isLessOrEq); cNew.a = 1.0; return cNew; }
float4 HardLight (float4 cBase, float4 cBlend) { float isLessOrEq = step(cBlend, .5); float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend), 2*cBlend*cBase, isLessOrEq); cNew.a = 1.0; return cNew; }
float4 VividLight (float4 cBase, float4 cBlend) { float isLessOrEq = step(cBlend, .5); float4 cNew = lerp(1 - (1 - cBase)/(2*(cBlend - .5)), cBase/(1 - 2*cBlend), isGreaterThen); cNew.a = 1.0; return cNew; }
float4 LinearLight (float4 cBase, float4 cBlend) { float isLessOrEq = step(cBlend, .5); float4 cNew = lerp(cBase + 2*(cBlend - .5), cBase + 2*cBlend - 1., isLessOrEq); cNew.a = 1.0; return cNew; }
float4 PinLight (float4 cBase, float4 cBlend) { float isLessOrEq = step(cBlend, .5); float4 cNew = lerp(max(cBase, 2*(cBlend - .5)), min(cBase, 2*cBlend), isLessOrEq); cNew.a = 1.0; return cNew; }
Category 4 (Comparison)
float4 Difference (float4 cBase, float4 cBlend) { return (abs(cBase - cBlend)); }
float4 Exclusion (float4 cBase, float4 cBlend) { return (.5 - 2 * (cBase - .5) * (cBlend - .5)); }