New!! - Bleach Bypass filter

[Gavino]

Originally Posted by WorBry

Rs = (255 - ((255 - x) * (255 -y)))/255 # i.e. Inverse Multiply (Screen)

That doesn't look right, just from the point of view of range normalisation I think it should be
Rs = 255 - ((255 - x) * (255 -y))/255

[WorBry]

Yeah, I tried that also. Here's the reference:

http://books.google.ca/books?id=qxrK...%20128&f=false

Also these:

http://forensicphotoshop.blogspot.co...th-part-2.html

http://www.pegtop.de/delphi/articles.../softlight.htm

(ie. the Pegtop version, not Photoshop)

I get a bit stuck on the algebra in converting these F(a,b) formulae and code to 255-scaled equations, and even more so with the half (128-scaled) equations.

[WorBry]

Well, at least I'm now getting a curve with this:

SoftLight = (((255-x) * ((x * y)/255)) + (x * (255-((255-x) * (255 - y))/255))) / 255

Translated:

SoftLight = mt_lutxy(Clp1, Clp1, "255 y - x y * 255 / * y 255 255 x - 255 y - * 255 / - * + 255 / ", y=3, u=2, v=2)

Grayscale gradient (self blend) with Histogram curve
http://www.mediafire.com/file/vmh5tg...ht%20maybe.png

Two Grayscale gradients (at right angles) blended.

http://www.mediafire.com/file/wnmmgm...t%20maybe2.png

But I'm still not sure if it is right, and then how to convert to the half equations for <128 and =>128 ?

Edit: Ah, just got the 'respected' layer the 'wrong way' round when doing the translation. Like Overlay, should be (respecting (Clp1) x) :

SoftLight= mt_lutxy(Clp1, Clp2, "255 x - x y * 255 / * x 255 255 x- 255 y - * 255 / - * + 255 /", y=3, u=2, v=2)

I think that's right now.

[WorBry]

Realized that the referenced formulas for softlight are not quite correct. For a 0 - 255 scaled image all of the 255 should really be 256. Using 255, offsets the white (255) and grey (128) points marginally. Using 256 gives the correct values.

So:

Originally Posted by WorBry

SoftLight= mt_lutxy(Clp1, Clp2, "255 x - x y * 255 / * x255 255 x- 255 y - * 255 / - * + 255 /", y=3, u=2, v=2)

Should really be:

Originally Posted by WorBry

SoftLight= mt_lutxy(Clp1, Clp2, "256  x - x y * 256 / * x 256 256 x - 256 y - * 256 / - * + 256 /", y=3, u=2, v=2)

Makes you wonder why they didnt realize that when deriving the formula

As for a (128-centred) two-part equation, well I'm stumped. The best fit I can get is with :

SL = "x 128 < 256 x - x y * 128 / * 128 / " 
SL = SL + "x 128 > x 256 256 x - 128 y - * 128 / - * 256 / "
SL = SL + "x ? ? "
Output = mt_lutxy(Clp1, Clp1, SL, y=3, u=2, v=2)

But the curve is not right - kinky around the mid-point (if you see what I mean):

http://www.mediafire.com/file/uytnom...ttempt%202.png

Sure wish someone could help me on this.

Still, I'm quite pleased with the effect that the 'single line' Softlight result achieves. A bit like 'Overlay' but more subtle. Quite useful for enhancing a 'filmic look' without the high-contrast.

Edit: I was surprised to find that the (AVISynth core filter) Overlay gives the following curves for 'Hardlight' and 'Softlight"

http://www.mediafire.com/file/h20a2z...27%20curve.png
http://www.mediafire.com/file/mn4qvm...27%20curve.png

I was under the impression that Overlay uses the Photoshop formulae for its blend modes.

[WorBry]

Oh my giddy aunt, in the midst of the brain-racking, it seems I didnt see the wood for the trees. There is no need to derive separate 'half equations'. Wheras Overlay and Hardlight apply 'Multiply' to values < 128 and 'Screen' to values > 128, the 'Softlight' curve is in fact the net sum of two actions: ((256-x) * Multiply) + (x * Screen). As a result:

a) The same the equation applies to all values across the 0 - 255 scale, and
b) The equation is intrinsically '128-centred' (as long 255 in the original formula is replaced by 256).

In the Blend_MT_alpha function, I took advantage of the 'half-equations' for Hardlight and Overlay, making it possible to apply separate opacity settings for values < 128 and >128. In this way, the effect could be biased somewhat in favour of the shadows or highlights. I thought this might not be possible with 'Softlight', but it is now easily achieved.

[WorBry]

I've updated Blend_MT_alpha accordingly, with added 'Softlight', 'Dodge' and 'Burn' blend modes:
Edit: Also included 'Additive', 'Subtractive' and 'Difference' modes. Some might find them useful.
I see the function text is now too long and so have put the explanation of the 'Blend Modes' as an Appendix.

BTW- On further testing with pure black and white overlays, I note that setting disimilar opacity values for Opac1 and Opac2, as applied to the 'contrast' (bi-phasic) modes (Hardlight, Overlay, Softlight), does tend to introduce some undesirable luma effects. I'll look at this some more, but for now I wouldnt recommend using this option with non-identical source clips i.e. for anything other than 'self-blends'.

function Blend_MT_alpha2(clip clp1 ,clip "clp2", string "BLMode", int "LMode", int "CMode", float "Opac", float "Opac1", float "Opac2", 
\                    bool "BL2", string "BLMode2", float "SOpac", float "SOpac1", float "SOpac2", bool "Preview", bool "GSGrad")
{

# Assembled by WorBry. Thanks to Didee for the Multiply, Screen and '128-Centred Contrast Multiply' computations.
                                          
# DESCRIPTION:

# Blend_MT aims to emulate a number of the blend modes available in commercial imaging software (After Effects etc). Whilst
# the existing core filters, Layer and Overlay, incorporate some of these modes, both require color space conversion to process 
# YV12 sources; Overlay accepts YV12 input, but internally converts to YUV 4:4:4 for processing. Blend_MT uses MaskTools v2 
# only and so allows processing exclusively in YV12. The function was created as one of set of routines to assist in the 
# simulation of certain "filmic looks", but perhaps has general application.
 
# Requires YV12 input, assumes full (pc) range 0-255 and assumes that the source is progressive (native or deinterlaced). 
# Requires MaskTools v2 only.          

# PARAMETER DEFINITIONS:
#
#Clp1          - Input clip that serves as the lower (base) clip in the specified blend operation. 
#Clp2          - Input clip that serves as the upper (overlay) clip in the specified blend operation. If not defined, clp2 
#                 defaults to clp1
#BLMode        - The specific blend operation that will be applied to the clips. At default, the operation is applied to the 
#                luma plane only; chroma is retaind from Clp1. The currently available modes are Blend, Multiply, Screen,
#                Hardlight, Overlay, Softlight, Burn, Dodge,  Reflect, Glow, Darken, Lighten, Additive, Subtractive and 
#                Difference. See Appendix 1 for explanation of these modes. 
#LMode         - Determines whether the luma plane (Y) will be processed by the blend operation (3) or retained from Clp1 (2) 
#                or Clp2 (4). Default is LMode=3. 
#CMode         - (2,3,4 or 0). Determines whether the chroma planes (U,V) will be processed by the blend operation (3), retained 
#                from Clp1 (2) retained Clp2 (4), or excluded i.e. greyscale (0). Note, aside from 'Blend' mode, Cmode=3 has 
#                limited application since the transformations cause marked U and V shifts with undesirable color casts. 
#                However, when applied to the 'contrast' modes (HardLight, Overlay, Softlight), with identical source clips, 
#                CMode=3 may produce an acceptable image in which the U and V profiles are broadened to create a richer mix of 
#                like hues. Depending on the source, this can take on a 'technicolor' film like appearance.                                        
#BL2           - True/False. Whilst the strength of the BLMode operation can be somewhat regulated by opacity adjustment, it may 
#                be desirable to apply a second blend operation to the first. True, activates this option. Default is, False. 
#BL2Mode       - Selects the second blend mode operation. All of the blend modes available in BLMode are available in BL2Mode. 
#                The BLMode2 operation is applied with Clp1 as the base clp and the product of the first BLMode operation as the 
#                top clip. For simplicity, the LMode and CMode settings are kept the same as for BLMode.     
#Opac          - Sets the opacity of the BLMode product relative to Clp1. Range 0.0 - 1.0. At 1.0 (default) all of the blend 
#                product is represented. 
#Opac1, Opac2  - Apply only to Hardlight, Overlay and Softlight. Opac1 sets the opacity of the BLMode product for Clp2 pixel 
#                values <128 and Opac2 sets the opacity for Clp2 values >128. This makes it possible to alter, in some way, 
#                the symetry of the S-curve. Note though, this can introduce some undesirable luma effects with non-identical 
#                source clips. Range 0.0 - 1.0. If not separately defined, defaults to Opac value.   
#SOpac         - Sets the opacity of the BLMode2 product relative to Clp1. Range 0.0 - 1.0. At 1.0 (default) all of the blend 
#                product is represented.
#SOpac1, SOpac2- Apply to Hardlight, Overlay and Softlight. SOpac1 sets the opacity of the BLMode2 product for BLMode pixel 
#                values <128 and SOpac2 sets the opacity for values >128. In this way it is possible to further 
#                manipulate the shape of the curve. Range 0.0 - 1.0. If not separately defined, default to SOpac value.  
#Preview       - True/False. True gives a composite view of the input clips and final output. Default is False. 
#GSGrad        - True/False. True demonstrates the effect of the blend operation as applied to a greyscale gradient; histogram 
#                reveals the luma curve. Default is False.
#   
#Defaults:
#clp2    = default(clp2, clp1)
BLMode  = default(BLMode, "Blend")
LMode   = default(LMode, 3) 
CMode   = default(Cmode, 2 ) 
Opac    = default(Opac,  1.0)
Opac1   = default(Opac1, Opac)
Opac2   = default(Opac2, Opac)
BL2     = default(BL2, False)
BLMode2 = default(BLMode2, "Blend")
SOpac   = default(SOpac, 1.0)
SOpac1  = default(SOpac1, SOpac)
SOpac2  = default(SOpac2, SOpac)
Preview = default(Preview, False)
GSGrad  = default(GSGrad, False)
#
#Limits:
Opac    = Opac <0.0 ? 0.0 : Opac >1.0 ? 1.0 : Opac
Opac1   = Opac1 <0.0 ? 0.0 : Opac1 >1.0 ? 1.0 : Opac1
Opac2   = Opac2 <0.0 ? 0.0 : Opac2 >1.0 ? 1.0 : Opac2
SOpac   = SOpac <0.0 ? 0.0 : SOpac >1.0 ? 1.0 : SOpac
SOpac1  = SOpac1 <0.0 ? 0.0 : SOpac1 >1.0 ? 1.0 : SOpac1
SOpac2  = SOpac2 <0.0 ? 0.0 : SOpac2 >1.0 ? 1.0 : SOpac2
#Switch for CMode=0 greyscale:
CMode  = (Cmode == 0) ? 128 : CMode
#Create greyscale gradients for GSGrad:
GSG    =  colorbars().converttoyv12().mt_lutspa(relative=true,expr="x 255 *").greyscale()
GSG    =  GSG.TurnLeft().LanczosResize(640,360)
Clp1   = (GSGrad == False) ? Clp1 : GSG
clp2   = default(clp2, clp1)
Clp2   = (GSGrad == False) ? Clp2 : GSG
# Create mt_lutxy expressions for the blend modes:
# Didee's '128-Centred Contrast Multiply' (HardLight):
HDL    =  " y 128 < x y * 128 / "+String(Opac1)+" * x 1 "+String(Opac1)+" - * + "
HDL    =  HDL + " y 128 > 256 256 x - 128 y 128 - - abs * 128 / - "+String(Opac2)+" * x 1 "+String(Opac2)+" - * + "
HDL    =  HDL + "x ? ?"
HDL2   =  " y 128 < x y * 128 / "+String(SOpac1)+" * x 1 "+String(SOpac1)+" - * + "
HDL2   =  HDL2 + " y 128 > 256 256 x - 128 y 128 - - abs * 128 / - "+String(SOpac2)+" * x 1 "+String(SOpac2)+" - * + "
HDL2   =  HDL2 + "x ? ?"
#Didee's '128-centred contrast multiply' commuted (Overlay):
OVE    =  " x 128 < y x * 128 / "+String(Opac1)+" * x 1 "+String(Opac1)+" - * + "
OVE    =  OVE + " x 128 > 256 256 y - 128 x 128 - - abs * 128 / - "+String(Opac2)+" * x 1 "+String(Opac2)+" - * + "
OVE    =  OVE + "y ? ?"
OVE2   =  " x 128 < y x * 128 / "+String(SOpac1)+" * x 1 "+String(SOpac1)+" - * + "
OVE2   =  OVE2 + " x 128 > 256 256 y - 128 x 128 - - abs * 128 / - "+String(SOpac2)+" * x 1 "+String(SOpac2)+" - * + "
OVE2   =  OVE2 + "y ? ?"
#Softlight: Based on Gimp and Delphi formula
SFL    = " y 128 < 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / "+String(Opac1)+" * x 1 "+String(Opac1)+" - * + "
SFL    = SFL + " y 128 > 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / "+String(Opac2)+" * x 1 "+String(Opac2)+" - * + "
SFL    = SFL + " y ? ? "
SFL2   = " y 128 < 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / "+String(SOpac1)+" * x 1 "+String(SOpac1)+" - * + "
SFL2   = SFL2 + " y 128 > 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / "+String(SOpac2)+" * x 1 "+String(SOpac2)+" - * + "
SFL2   = SFL2 + "y ? ? "
#Glow
GLO    = "x 255 == x "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
GLO    = GLO + " 255 y y * 255 x - / min "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
GLO    = GLO + "?"
GLO2   = "x 255 == x "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
GLO2   = GLO2 + " 255 y y * 255 x - / min "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
GLO2   = GLO2 + "?"
#Reflect
REF    = "y 255 == y "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
REF    = REF + " 255 x x * 255 y - / min "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
REF    = REF + "?"
REF2   = "y 255 == y "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
REF2   = REF2 + " 255 x x * 255 y - / min "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
REF2   = REF2 + "?"
#
Bl1Expr = (BLMode=="Blend")       ? "y "+string(Opac)+" * x 1 "+string(Opac)+" - * +"
 \      : (BLMode=="Multiply")    ? "x y * 255 / "+String(Opac)+" * x 1 "+String(Opac)+" - * +" 
 \      : (BLMode=="Screen")      ? "256 256 x - 256 y - * 256 / - "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
 \      : (BLMode=="Hardlight")   ? HDL
 \      : (BLMode=="Overlay")     ? OVE
 \      : (BLMode=="Softlight")   ? SFL
 \      : (BLMode=="Burn")        ? "255 255 x - 256 * y 1 + / - "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
 \      : (BLMode=="Dodge")       ? " x 256 * 256 y - / "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
 \      : (BLMode=="Glow")        ? GLO
 \      : (BLMode=="Reflect")     ? REF 
 \      : (BLMode=="Lighten")     ? "x y > x y "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? "
 \      : (BLMode=="Darken")      ? "x y < x y "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? "
 \      : (BLMode=="Additive")    ? "x y + 255 > 255 x y + "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? "
 \      : (BLMode=="Subtractive") ? "x y + 256 - 0 < 0 x y + 256 - "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? " 
 \      : (BLMode=="Difference")  ? "x y - abs "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
 \      : Assert(false, "Invalid BLMode String")
#
Bl2Expr = (BLMode2=="Blend")      ? "y "+string(SOpac)+" * x 1 "+string(SOpac)+" - * +"
 \      : (BLMode2=="Multiply")   ? "x y * 255 / "+String(SOpac)+" * x 1 "+String(SOpac)+" - * +" 
 \      : (BLMode2=="Screen")     ? "256 256 x - 256 y - * 256 / - "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
 \      : (BLMode2=="Hardlight")  ? HDL2
 \      : (BLMode2=="Overlay")    ? OVE2
 \      : (BLMode2=="Softlight")  ? SFL2
 \      : (BLMode2=="Burn")       ? "255 255 x - 256 * y 1 + / - "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
 \      : (BLMode2=="Dodge")      ? " x 256 * 256 y - / "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
 \      : (BLMode2=="Glow")       ? GLO2
 \      : (BLMode2=="Reflect")    ? REF2 
 \      : (BLMode2=="Lighten")    ? "x y > x y "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + ? "
 \      : (BLMode2=="Darken")     ? "x y < x y "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + ? "
 \      : (BLMode2=="Additive")   ? "x y + 255 > 255 x y + "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + ? "
 \      : (BLMode2=="Subtractive") ? "x y + 256 - 0 < 0 x y + 256 - "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + ? " 
 \      : (BLMode2=="Difference") ? "x y - abs "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
 \      : Assert(false, "Invalid BLMode String")

#Apply blend operation:
BLOut  = mt_lutxy(clp1,clp2, Bl1Expr, Y=LMode, U=CMode, V=CMode)
Output = (BL2 == False) ? BLOut : mt_lutxy(Clp1, BLOut, Bl2Expr, Y=LMode, U=CMode, V=CMode)
#Preview set-up:
Clp1s  = Clp1.LanczosResize(640,360).Subtitle("Clp1 (Base)", size=14)
Clp2s  = Clp2.LanczosResize(640,360).Subtitle("Clp2 (Top)", size=14)
Outs   = Output.LanczosResize(640,360).Subtitle("Output", size=14)
Outgs  = Output.Greyscale().LanczosResize(640,360).Subtitle("Output (Greyscale)", size=14) 
Clpsv  = StackVertical(Clp2s, Clp1s)
Outsv  = StackVertical(Outs, Outgs)
Prev   = StackHorizontal(Clpsv, Outsv)
#GSGrad view set-up:
GSGH   = GSG.Histogram().Subtitle("Original")
GSGoH  = Output.LanczosResize(640,360).Histogram().Subtitle("Blend operation applied")
GSGout = StackVertical(GSGH, GSGoH)
#Output
Final  = (Preview == False && GSGrad == False) ? Output
\      : Preview ? Prev : GSGout 
#
Return Final
}

[WorBry]

........Appendix 1. Explanation of the 'Blend Modes':

#                                                          BLEND_MT_ALPHA2 
#                                                             APPENDIX 1

#                                                    EXPLANATION OF BLEND MODES

#  Blend       - Simple merge operation. Note that several other so-called 'blend modes' may be acheived simply by modulating 
#                the LMode, CMode and Opacity settings (see below). Thus:
#                'Luminosity' mode retains the luma from clp2 and chroma from clp1. Blend mode, at default settings (LMode=3, 
#                Cmode=2, Opacity = 1.0), or otherwise LMode=4 and CMode=2, correspond to this.   
#                'Chroma' or 'Color' mode retains the luma from clp1 and the chroma from clp2. LMode=2 and CMode=3 at full 
#                opacity (1.0), or LMode=2 and CMode=4, correspond to this.  
#                'Average' mode is equivalent to 0.5 (50%) opacity.  
#                       
#  Multiply    - Multiplies the corresponding pixel values of the two input clips and divides the result by 255. The outcome 
#                is always a darker composite image. If the input clips are identical, the transformation corresponds to an 
#                exponential curve.
#
#  Screen      - Has the opposite effect to Multiply. It multiples the inverted (complement) values. The outcome is always 
#                a lighter composite image. 
#
#  Hardlight   - (128-Centred Contrast Multiply) Multiplies or screens the pixel values, depending on top clip (Clp2) values. 
#                The effect is likened to shining a harsh spotlight (as if Clp2) on the image (Clp1), hence the name. For Clp2 
#                values > 128 (50% grey) the image is screened, and so lightened; useful for adding highlights. For Clp2 
#                values < 128, the image is multiplied,and so darkened; useful for adding shadows. Pure black or white results 
#                in pure black or white. The computation differs from that used in After Effects/Photoshop, in that it is 
#                128-centred; this avoids luma overflow. If Clp2 and Clp1 have identical pixel values, the result corresponds 
#                to a symetrical S-curve. This is useful for creating high contrast images characteristic of certain 'film looks'.   
#                   
#  Overlay     - (128-Centred Contrast Multiply commuted). Multiplies or screens the pixel values, depending on the base clip 
#                values. For Clp1 pixel values > 128 the image is screened and for Clp1 values < 128 the image is multiplied. 
#                In this way patterns overlay the existing pixels while preserving the highlights and shadows of the base clip. 
#                The formulation, like Hardlight, is 128-centered. It follows that if Clp1 and Clp2 have identical pixel values, 
#                Overlay and Hardlight will produce the same result.
 
#  SoftLight   - Produces a similar effect to Overlay. In this case, "Multiply" and "Screen" derivatives are combined.
#                The composite effect is likened to shining a diffused spotlight (as if Clp2) on the image (Clp1). When Clp1 
#                and Clp2 have identical values, the resulting S-curve that is milder than that produced by Overlay. This is 
#                very useful for enhancing a generic 'filmic look' without the 'high contrast'.                      
#
#  Burn        - Decreases the contrast to make the top clip reflect the base clip. The darker the bottom layer, the more this
#                influnces the mix. Blending with white produces no difference. Blending with black gives black. The effect is
#                similar to changing the 'black point'.
#
#  Dodge       - Decreases the contrast to make the base reflect the top clip: the brighter the top clip, the more this 
#                influences the mix. Blending with white gives white. Blending with black does not change the image. 
#                The effect is similar to changing the 'white point'.             
#                 
#  Reflect    -  Gives the appearance of adding shiny objects. See the Greyscale gradient curve (GSGrad option) to see why. Use 
#                with caution and always wear sun glasses. Reduced opacity is recommended.
# 
#  Glow       -  The opposite of Reflect, but the same cautions apply. 
#                   
#  Darken     -  Takes the darkest pixel value from either clip. If the input clips have identical values, there is no change.
# 
#  Lighten    -  Takes the lightest pixel value from either clip. If the input clips have identical values, there is no change.
#
#  Additive   -  Adds the pixel values from Clp1 and Clp2. Sum values >255 are truncated to pure white. 
#
#  Subtractive-  Similar to Additive mode, except that 256 is subtracted from the sum pixel value. Resulting values <0 are 
#                truncated to pure black.
# 
#  Difference -  Takes the absolute difference between in the clips i.e. subtracts Clp2 value from Clp1 value, or visa-versa
#                to always give a positive value. As a result, overlay with pure white inverts the base image, and overlay with
#                pure black produces no change, as all values are 0. The primary use is for aligning two images with an identical
#                visual element.  

[Gavino]

Glad to see you got it working satisfactorily in the end.

One thing still puzzles me:

Originally Posted by WorBry

Realized that the referenced formulas for softlight are not quite correct. For a 0 - 255 scaled image all of the 255 should really be 256. Using 255, offsets the white (255) and grey (128) points marginally. Using 256 gives the correct values.

If the formulae are derived using a range of 0.0 to 1.0 which is then scaled to 0-255, I don't see how the number 256 can arise.
If 0 is white and 255 is black, isn't (50%) grey 127.5 rather than 128 anyway?

(Perhaps your 128-centred formulae should really be 127.5 centred? )

[WorBry]

Well that’s a good point. I guess the reason why I was looking for a 128-centred formula was for consistency with Didee’s ‘128-Centred Contrast Multiply’ (Hardlight) and it’s mirror – Overlay. Exactly why Didee chose 128 as the centre point rather than 127.5, I am not entirely sure. No doubt there is a valid reason and he could answer that point more accurately than I.

My understanding is that the ‘centred approach’ allows the ‘Multiply’ and ‘Screen’ components to be applied ‘cleanly’ to values <128 and >128 respectively, so avoiding conflict and the potential for luma overflow. The conventional (i.e. Photoshop-based) two-part formulas for Hardlight and Overlay all take the ‘If x> 128 (or <128) then.....Else’ type approach. In that case, what then is the centre point? It can’t be 128 or 127.5.

The Softlight formula (at least the one I have taken) however, is a different situation because it represents the sum of two opposing actions across the entire 0-255 scale, so there is not the same need to set a centre point – as far as I can tell, the equation does that itself. In fact, I find that if I do set the centre point at 128 (in like manner to `128-Centred Contrast Multiply) this seems to upset the balance. This is apparent when overlaying an image with pure white or black – resulting in pits of black in light areas and visa-versa. In this case, resorting to the ’If-Then-Else’ approach, or not partitioning the formula at all, seems to resolve this problem.

I would have to agree though, that if 127.5 is logically taken to be the true` centre (grey point), then the ’original` Softlight formula (i.e. using 255`s instead of 256`s) is perfectly valid – computing 127.5 (as if a self-blend i.e. x values = y values) results in 127.5 exactly. So I think I will leave it that way unless there is a compelling argument for forcing a 128 centre point; I suspect not.

I`ve amended the SoftLight formula in Blend_MT_alpha2 accordingly.....although keeping a 'If x < 128 then...else' format to allow separate Opac1 and Opac2 settings.

[Didée]

"128" is the common center point used for the [0,255] range. Blame the restrictions of 8-bit colorspaces.
In any case, you need a neutral element for the do-nothing case. Using 127.5 as center is not good because you cannot do "nothing". And when you're going to use the result of mt_makediff(this,that) as the modifier clip, this one is 128-centered, too. Even worse: when the blend formula is centered to 127.5, then you can not *correctly* use the result of mt_makediff() as modifier clip: in that case, it will introduce a drift, because 128 would be supposed to do nothing.

Also, don't forget to think out of the box - all these blending modes are not only useful for just modifying the overall frame contrast. You could also use them e.g. for sharpening tasks, and such. For which the presence of a discretely available center element is mandatory.

[WorBry]

Thanks for your explanation. In that case, I remain stumped on a suitable '128-Centred' formula for Softlight.

Based on the 'original' formula :

Result= (((255-x) * ((x * y)/255)) + (x * (255-((255-x) * (255 - y))/255))) / 255

i.e.

 mt_lutxy(Clp1, Clp2, "255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 /", y=3, u=2, v=2)

Then, either:

SFL    = " x 128 < 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / "+String(Opac1)+" * x 1 "+String(Opac1)+" - * + "
SFL    = SFL + " x 128 > 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / "+String(Opac2)+" * x 1 "+String(Opac2)+" - * + "
SFL    = SFL + " x ? ? "
 mt_lutxy(clp1,clp2, SFL, y=3, U=2, V=2)

or

SFL    = " x 128 < 256 x - x y * 256 / * x 256 256 x - 256 y - * 256 / - * + 256 / "+String(Opac1)+" * x 1 "+String(Opac1)+" - * + "
SFL    = SFL + " x 128 > 256 x - x y * 256 / * x 256 256 x - 256 y - * 256 / - * + 256 / "+String(Opac2)+" * x 1 "+String(Opac2)+" - * + "
SFL    = SFL + " x ? ? "
 mt_lutxy(clp1,clp2, SFL, y=3, U=2, V=2)

....both give this sort of pitting/stippling when a greyscale image is overlayed with pure black or white.....which I dont think should happen.

http://www.mediafire.com/file/2wzwgm...%20overlay.png

http://www.mediafire.com/file/m3ino2...%20overlay.png

Converting to a 'If x<128 then, this......or Else (everything else)' resolves it (which is how I have it now in Blend_MT) but then it is not '128-centred' in terms of a neutral anchor point?

Maybe, the SoftLight formula is a different case (for the reasons I suggested above) or is it possible to derive a workable half-equation solution (for x<128 and x>128) that doesnt upset the balance? I couldnt find one, and so resorted to using the 'full' formula for both halves.

[Didée]

Obviously your LUT strings are somehow skewed. Assuming that the 1st clip is the "base" clip and the 2nd clip is the "modifier" clip, you would check for y>/<128, not x. Value 128 on the base clip doesn't need any special handling. Value 128 on the overlay clip is which needs to be checked.

[WorBry]

For sure, that fixes it, but then it's back to this issue of which clip the blend should be referencing/respecting. All of the descriptions for SoftLight I have seen say that (like Overlay) it references (and so reflects the characteristics - highlights, shadows) of the base clip e.g blending with black or white (as the top layer) doesnt result in pure black or white (as Hardlight does). But then I'm thinking, if it does the intended job, which it does, what the heck. So, I'll take your advice on the 'using y instead of x'. Thanks.

Modified the SoftLight formula in Blend_MT_alpha2 (post# 26) accordingly.

[Loadus]

I once tried to emulate a filmlook by using softlight/hardlight/overlay formulas, and got them stitched into a GPU shader filter (well, actually, Phaeron did the code, not me)

The core calculation for softlight was:

A = 1st layer (you can use colorgradients or grayscale on this)
B = 2nd layer (ie. background)
C = resulting composite

   if (A < 0.5)

		C = (2 * A - 1) * (B - B * B) + B;
      else
		C = (2 * A - 1) * (sqrt(B) - B) + B;

Find the discussion here:
http://forums.virtualdub.org/index.p...7&t=14597&st=0

The shader and the code:
http://www.loadusfx.net/virtualdub/filmfxguide.htm

In the examples I used it to just slightly colorgrade the video, but you can crank up the volume and do some mad stuff with it.

Version 1.7.3 is based on a cineon style exposure, and it's here:
http://www.loadusfx.net/virtualdub/F...FX%20v1.7.3.fx

The code on my part is a bit goofy, I haven't cleaned it up + the terms are odd. But it's a tweaker's heaven with the sliders and all. I hope you can get some help from those. ^^

[WorBry]

Thanks for your input. I was beginning to wonder if anyone was interested in film-looks anymore.

If I'm not mistaken (always a possibilty), your Softlight code is based on the Photoshop formula, of which there seem to be various interpretations...some maybe incorrect. I do, at some point, intend to derive a workable mt_lutxy equation based on the Photoshop formula, to see how it compares with the 'Gimp-based' equation that I am using (references in post#22 ); it's interesting to note though that in some versions of Gimp (mine included) they used the same formula for Overlay and SoftLight - I understand this has now been changed.

Your VDub Shader filter looks interesting (bearing in mind that this is a sub-forum for AVISynth useage). Of course, there are lots of things you can do with RGB, in terms of chroma, that are not so easy to replicate in YUV colorspace. My objective was to process entirely in YV12, without intermediate color space conversions, and mimimize, as far as possible, multi-stage layering (as it relates to the respective luma and chroma planes).

The 'bleach' component of your filter is of interest, and I'll look at that some more.

I did experiment quite a bit with a single 'contrast curve-desaturation' blend stage (using a greyscale overlay clip), but decided to keep them separate. That way you can independently control the strength of the luma contrast curve and the degree of chroma desaturation. In fact the SelSah (Selective Saturation & Hue) function that I put together allows you to restrict the saturation control to a defined luma range. Plus, you can choose which clip you want to use for 'controlling' the saturation, which might be the original clip or the blend product. This is relevant, because if one chooses to 'partially desaturate' (not a good term I know), the pattern will be influenced by the shape of the luma curve (that's just the way the function works)...which can be put to some advantage.

Out of interest how do you install your filter? I've never used this type of VDub filter.
Edit: Well I can see some instruction for installation in the virtualdub.org forum thread, but where do I find the GPUFilter vdf?

Edit: Could you just clarify your definitions for the layers. As I understand your terminology:

A = First Layer appears refer to the image ('modifier' as Didee more aptly puts it) that will be overlayed on top of the base image.
B = Second Layer (i.e. background) I take to mean the base image.

If so, this seems contrary to convention (in terms of 'layer' orientation), although consistent with Didee's assertion that it should be the 'modifier' clip that is referenced in partitioned equation. As you might have noted from my foregoing posts, I get hung up on this issue, not least because there are (supposed) Photoshop formulae out there that appear to have got things mixed up (for some modes). This, oft referred to, source being a case in point:

http://www.nathanm.com/photoshop-blending-math/

[CruNcher]

Ehmm you should be able to use that Shader with AviShader for Avisynth
http://forum.doom9.org/showthread.php?s=&threadid=87295

[WorBry]

But it's still RGB though, isnt it? Believe me, if there was an AVISynth filter for generating custom curves (natively) in YV12, I likely wouldnt have gone down this blend mode road; 'possible', of course, with mighty Masktools v2, but way, way way, beyond my capabilities.

Still looking for this ethereal GPUFilter vdf plugin.

If it's relevant, I'm running a GeForce 8400M GS card, Vista (SP2), Core2Duo CPU, DirectX 10.0. Dont really want to mess with the registry ('missing' dll's etc) if that's what it invloves.....I still have the scars.

Edit:
Loadus. Actually, from the information in your 'Film Fx' filter guide, I'm already pretty familiar with the processes involved. What intrigues me is the 'bleaching' effect. OK, I understand that in the 'normal process' adjustments are made in a greyscale copy and that this is applied to the original image with a Softlight blend. For the 'bleaching' component it is stated that:

"The bleaching in the shader is done by reversing the effect of the shader. When bleaching, all the curves and gamma sliders are reversed. When the bleach is set to null (the slider is in the center) the EffectCurves and EffectGamma have no effect....

....The effect layer of the shader is a grayscale copy of the original image and it is blended to the original using "SoftLight" blending, common in image editing programs. All the EffectCurves and EffectGamma's are done to that grayscale effectlayer".

I'm wondering then if the 'bleaching' really just amounts to an opacity adjustment of the final Softlight blend?

[Loadus]

Originally Posted by WorBry

What intrigues me is the 'bleaching' effect.

The SoftLight formula used in my code is from Paint Shop Pro (I guess it's "SoftLight Legacy" or similar in Photoshop) - basically an Overlay calculation that doesn't allow highlight tones from clipping over (ie. classic SoftLight that I use in almost all photo editing).

The bleach effect is done by making the overlay image negative/inversed. If you then apply a blur into the overlay layer (say, radius 20 on a 720 x 480 clip) you'll get a tonemapping effect, similar to the 'HDR' photostuff that peeps do. ^^


EDIT:
If you're still looking for the filter, it's here: http://www.virtualdub.org/beta/gpufilter-0.6.zip

[WorBry]

Thanks for your reply.

Originally Posted by Loadus

The bleach effect is done by making the overlay image negative/inversed.

Ah, OK, gotcha. Easy to do with Blend_MT also.

...... If you then apply a blur into the overlay layer (say, radius 20 on a 720 x 480 clip) you'll get a tonemapping effect, similar to the 'HDR' photostuff that peeps do. ^^

Reduce global contrast, whilst preserving local contrast......pseudo 'extended dynamic range' ; interesting.....from a 'non-peep' perspective . I shoot most of my DV stuff in (Panasonic) 'Procinema' mode' which, apparently, uses some electronic jiggery-pokery in the signal amplification to extend the dynamic range (as claimed). Actually, it's a pretty good starting point for some of this 'film-look' stuff, aside from the pseudo-progressive (frame) motion, which I find a little too jittery, and the pesky aliasing to deal with. Waiting for further improvements in the 50p/60p and low-light capability of AVCHD cams before I make the jump to HD.

EDIT:
If you're still looking for the filter, it's here: http://www.virtualdub.org/beta/gpufilter-0.6.zip

Thanks. It installed/loaded OK (no complaints about missing dll's etc). I'll play around some more. Would be nice if there was an option to reset the FilmFx to default settings.

[Gavino]

Are the formulae for Additive and Subtractive correct?

Originally Posted by WorBry

 \      : (BLMode=="Lighten")     ? "x y > x y "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? "
 \      : (BLMode=="Darken")      ? "x y < x y "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? "
 \      : (BLMode=="Additive")    ? "x y + 255 > 255 x y + "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? "
 \      : (BLMode=="Subtractive") ? "x y + 256 - 0 < 0 x y + 256 - "+String(Opac)+" * x 1 "+String(Opac)+" - * + ? " 
 \      : (BLMode=="Difference")  ? "x y - abs "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
 \                                : Bl1Expr

Note that the opacity is only applied on one branch of the conditionals. That doesn't matter for Lighten and Darken, since the result is unchanged, but not for Additive and Subtractive - is this intended? Should it not be
(BLMode=="Additive") ? "x y + 255 > 255 x y + ? "+String(Opac)+" * x 1 "+String(Opac)+" - * + " etc

I think it would make the formulae more readable and checkable if you defined the opacity expressions as variables, eg
Opacity = String(Opac)+" * x 1 "+String(Opac)+" - * + "
instead of repeating them everywhere.

Also, if you call the function with an unrecognised BLMode, it gives the error "I don't know what Bl1Expr means".
Better would be to replace the final Bl1Expr in the code above with something like
Assert(false, "Invalid BLMode String")