Difference between revisions of "Blending functions"
Millennium (Talk | contribs) (→Category 3 (Complex)) |
Millennium (Talk | contribs) m (→Category 3 (Complex)) |
||
Line 68: | Line 68: | ||
</pre> | </pre> | ||
− | As we see the result values of R, G and B components (except for alpha) for this blending mode | + | 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> | <pre> | ||
if (baseColor > .5) then { | if (baseColor > .5) then { | ||
Line 82: | Line 82: | ||
</pre> | </pre> | ||
− | Actually we don't want newColor to gradually change between A and B, but only switch A <-> B, so 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 [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> | <pre> | ||
float step(x, y) { | float step(x, y) { | ||
Line 93: | Line 93: | ||
</pre> | </pre> | ||
− | Apparently, if it's required to invert output values, just change the order of '''step''' input arguments. Let's assembly all the information we've found out and re-write our shader: | + | 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> | <pre> | ||
float isLessOrEq = step(cBase, 0.5); | float isLessOrEq = step(cBase, 0.5); | ||
Line 107: | Line 107: | ||
</pre> | </pre> | ||
− | P.P.S. Although compiler will do this work for you at the optimization stage, keep in mind that explicit | + | 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]. |
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)); }