New!! - Bleach Bypass filter

[WorBry]

Thanks for your comments. All suggestions for improvement are most welcome.

Originally Posted by Gavino

Are the formulae for Additive and Subtractive correct?

For sure, the formulae per se are 'correct'.

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

For the Opacity component of the mt_lutxy expression strings, I took the same as approach as Didee's earlier Hardlight functions:

http://forum.doom9.org/showpost.php?...32&postcount=2

And taking, for example, 'Additive':

(x + y ) > 255 ? 255 : (( x + y) * "+String(Opac)+" ) + (x * (1 - "+String(Opac)+" ))

....seems right to me and mt_polish (using a arbitary value instead of "+String(Opac)+" ) literally translates this to:

x y + 255 > 255 x y + "+String(Opac)+"  * x 1 "+String(Opac)+"  - * + ?

i.e. puts the ? ('If' condition) at the end of the string (stack?), which is how it is now in Blend_MT.

Reverse translation (mt_infix) of:

"x y + 255 > 255 x y + ? "+String(Opac)+" * x 1 "+String(Opac)+" - * + "

literally gives:

((((x + y) > 255 )) ? 255 : (x + y)) * "+String(Opac)+" ) + (x * (1 - "+String(Opac)+" )))

Which seems to be the same thing. Both '?' options work and give the same result, so I am not sure, which is the 'more correct' ?

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.

Yes, I've been thinking of ways to cut down on the repetition, and will have a look at that, bearing in mind that there are six opacity determinants in all (Opac, Opac1, Opac2, SOpac, SOpac1, SOpac2).

I did at one point (posts #10 and #11) consider applying the blend opacity through a second mt_lutxy expression, but would that (obviously) would mean two lut calcs (each with their own rounding errors) instead of one, and make it more difficult to work in separate opacity determinants for <128 and >128 with the Hardlight, Softlight and Overlay modes.

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")

Quite agree. Added it. Thanks.

[WorBry]

Originally Posted by Gavino

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.

So, I guess you are suggesting something like........(edited)

Edit: Script modified to incorporate changes as suggested by Gavino (below). Now Blend_MT_alpha3. The Appendix 1 'Explanation of the Blend Modes' (Post# 27) remains unchanged.
Edit2: Corrected Overlay and Softlight expressions, and changed the base clip for the BLMode2 operation from Clp1 to the BLMode product (as per post# 46 below)

function Blend_MT_alpha3(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, and to
# Gavino for valuable advice on syntax. 
                                          
# 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 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 as a 'self-blend' i.e. the BLMode product is the top and base 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 pixel 
#                values <128 and Opac2 sets the opacity for 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 the BLMode product. Range 0.0 - 1.0. At 1.0 (default) all 
                  of the BLMode2 product is represented.
#SOpac1, SOpac2- Apply to Hardlight, Overlay and Softlight. SOpac1 sets the opacity of the BLMode2 product for 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:
Opac   = " "+String(Opac)+" * x 1 "+String(Opac)+" - * + "
Opac1  = " "+String(Opac1)+" * x 1 "+String(Opac1)+" - * + "
Opac2  = " "+String(Opac2)+" * x 1 "+String(Opac2)+" - * + "
SOpac  = " "+String(SOpac)+" * x 1 "+String(SOpac)+" - * + "
SOpac1 = " "+String(SOpac1)+" * x 1 "+String(SOpac1)+" - * + "
SOpac2 = " "+String(SOpac2)+" * x 1 "+String(SOpac2)+" - * + "
# Didee's '128-Centred Contrast Multiply' (HardLight):
HDL    =  " y 128 < x y * 128 / " + Opac1
HDL    =  HDL + " y 128 > 256 256 x - 128 y 128 - - abs * 128 / - " + Opac2
HDL    =  HDL + " x ? ? "
HDL2   =  " y 128 < x y * 128 / " + SOpac1
HDL2   =  HDL2 + " y 128 > 256 256 x - 128 y 128 - - abs * 128 / - " + SOpac2
HDL2   =  HDL2 + " x ? ? "
#Didee's '128-centred contrast multiply' commuted (Overlay):
OVE    =  " x 128 < x y * 128 / " + Opac1
OVE    =  OVE + " x 128 > 256 256 x - 128 y 128 - - abs * 128 / - " + Opac2
OVE    =  OVE + " y ? ? "
OVE2   =  " x 128 < x y * 128 / " + SOpac1
OVE2   =  OVE2 + " x 128 > 256 256 x - 128 y 128 - - abs * 128 / - " + 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 / " + Opac1
SFL    = SFL + " y 128 > 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / " + Opac2
SFL    = SFL + " x ? ? "
SFL2   = " y 128 < 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / " + SOPac1
SFL2   = SFL2 + " y 128 > 255 x - x y * 255 / * x 255 255 x - 255 y - * 255 / - * + 255 / " + SOPac2
SFL2   = SFL2 + " x ? ? "
#
Bl1Expr = (BLMode=="Blend")       ? "y " + Opac
 \      : (BLMode=="Multiply")    ? "x y * 255 / " + Opac
 \      : (BLMode=="Screen")      ? "256 256 x - 256 y - * 256 / - " + Opac
 \      : (BLMode=="Hardlight")   ? HDL
 \      : (BLMode=="Overlay")     ? OVE
 \      : (BLMode=="Softlight")   ? SFL
 \      : (BLMode=="Burn")        ? "255 255 x - 256 * y 1 + / - " + Opac
 \      : (BLMode=="Dodge")       ? " x 256 * 256 y - / " + Opac
 \      : (BLMode=="Glow")        ? "x 255 == x 255 y y * 255 x - / min ? " + Opac
 \      : (BLMode=="Reflect")     ? "y 255 == y 255 x x * 255 y - / min ? " + Opac
 \      : (BLMode=="Lighten")     ? "x y > x y ? " + Opac
 \      : (BLMode=="Darken")      ? "x y < x y ? " + Opac
 \      : (BLMode=="Additive")    ? "x y + 255 > 255 x y + ? " + Opac
 \      : (BLMode=="Subtractive") ? "x y + 256 - 0 < 0 x y + 256 - ? " + Opac
 \      : (BLMode=="Difference")  ? "x y - abs " + Opac
 \      : Assert(false, "Invalid BLMode String")
#
Bl2Expr = (BLMode2=="Blend")      ? "y " + SOpac
 \      : (BLMode2=="Multiply")   ? "x y * 255 / " + SOpac
 \      : (BLMode2=="Screen")     ? "256 256 x - 256 y - * 256 / - " + SOpac
 \      : (BLMode2=="Hardlight")  ? HDL2
 \      : (BLMode2=="Overlay")    ? OVE2
 \      : (BLMode2=="Softlight")  ? SFL2
 \      : (BLMode2=="Burn")       ? "255 255 x - 256 * y 1 + / - " + SOpac
 \      : (BLMode2=="Dodge")      ? "x 256 * 256 y - / " + SOpac
 \      : (BLMode2=="Glow")       ? "x 255 == x 255 y y * 255 x - / min ? " + SOpac
 \      : (BLMode2=="Reflect")    ? "y 255 == y 255 x x * 255 y - / min ? " + SOpac
 \      : (BLMode2=="Lighten")    ? "x y > x y ? " + SOpac
 \      : (BLMode2=="Darken")     ? "x y < x y ? " + SOpac
 \      : (BLMode2=="Additive")   ? "x y + 255 > 255 x y + ? " + SOpac
 \      : (BLMode2=="Subtractive") ? "x y + 256 - 0 < 0 x y + 256 - ? " + SOpac
 \      : (BLMode2=="Difference") ? "x y - abs " + 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(BLOut, 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
}

[Gavino]

Originally Posted by WorBry

And taking, for example, 'Additive':

(x + y ) > 255 ? 255 : (( x + y) * "+String(Opac)+" ) + (x * (1 - "+String(Opac)+" ))

....seems right to me

But this way, if x+y >255, the opacity is ignored and 255 is returned directly instead of being blended with the original.

Reverse translation (mt_infix) of:

"x y + 255 > 255 x y + ? "+String(Opac)+" * x 1 "+String(Opac)+" - * + "

literally gives:

((((x + y) > 255 )) ? 255 : (x + y)) * "+String(Opac)+" ) + (x * (1 - "+String(Opac)+" )))

Which seems to be the same thing.

No, it's not the same. The difference is in the brackets I have highlighted in red.
Here the opacity is applied to the entire conditional expression, including the 255 part.

[Gavino]

Originally Posted by WorBry

So, I guess you are suggesting something like:

 \      : (BLMode2=="Additive")   ? "x y + 255 > 255 x y + ? " + SOpac
 \      : (BLMode2=="Subtractive") ? "x y + 256 - 0 < 0 x y + 256 - ? " + SOpac

Exactly. Now it's much more obvious whether the opacity is being applied in the right place. And now Additive and Subtractive are correct.

[WorBry]

Yes, you are right. Silly thing is, I did consider this implication with the Glow and Reflect modes and resolved it this way:

GLO    = "x 255 == x " + Opac
GLO    = GLO + " 255 y y * 255 x - / min " + Opac
GLO    = GLO + "?"

Even so, for consistency, I've modified those also.

Significant changes in all, so above script is now Blend_MT_alpha3......Wow...Gasp!

As my old neurosurgery professor used to remark "What he lacks in accuracy he makes up for in enthusiasm"

[WorBry]

On further testing I find that the 'Overlay' expression is also not quite right. 'Overlay' is merely a commutation (reversal) of 'Hardlight', with respect to the layers. As such, it is sufficient to change only the 'reference' clip in the '128-Centred Contrast Multiply' (Hardlight) formula. Otherwise the half equations for < 128 > are not changed. This was not apparent with simple 'self-blends', but became obvious on further testing of 'double-blends' and non-identical overlays.

So, what was:

OVE    =  " x 128 < y x * 128 / " + Opac1
OVE    =  OVE + " x 128 > 256 256 y - 128 x 128 - - abs * 128 / - " + Opac2
OVE    =  OVE + "y ? ?"

Should be:

OVE    =  " x 128 < x y * 128 / " + Opac1
OVE    =  OVE + " x 128 > 256 256 x - 128 y 128 - - abs * 128 / - " + Opac2
OVE    =  OVE + "y ? ? "

Also, the terminal (128 anchor) in the Softlight formula should be x and not y.

Updated Blend_MT_alpha3 (in post# 42) accordingly.

Edit: Also changed the BLMode2 operation so that it uses the BLMode product as base clip, instead of Clp1 (i.e. is now a 'self-blend'). This is the more usual application in AE/PS/Gimp 'recipes' that involve multiple blends. Of course, the same can be acheived with a repeat pass of Blend_MT if desired.

[WorBry]

Now that I've got the 'luma' component of these blends sorted (I hope), I've been experimenting with some (maybe acheivable) chroma effects (I know...YUV chroma....not for the faint hearted...why not just do it in RGB?). To this end I want to create some (YV12) U and V reference spectra . Figured I could do this using a greyscale gradient and YtoUV, like so:

GSG    =  colorbars().converttoyv12().mt_lutspa(relative=true,expr="x 255 *").Greyscale().LanczosResize(640,640)
GSG2   =  GSG.Reduceby2()
NGry2  =  GSG.mt_lut("x 128 ", y=3).Reduceby2() 
Uspec  =  YtoUV(GSG2, NGry2)
VSpec  =  YtoUV(NGry2, GSG2)
Return Interleave(USpec, VSpec)

But with both spectra, there is obviously some clipping/scale issue going on. Any idea how to resolve?

[Gavino]

Originally Posted by WorBry

But with both spectra, there is obviously some clipping/scale issue going on.

Why do you think it's wrong?
Looks OK to me, as you can see by adding Histogram("levels").

I also changed the code to the simpler

BlankClip(100, 640, 640, pixel_type="YV12")
USpec = mt_lutspa(uexpr="x 255 *", Y=-128, U=3, V=-128)
VSpec = mt_lutspa(vexpr="x 255 *", Y=-128, U=-128, V=3)
Return Interleave(USpec, VSpec)

and got identical results.

[Didée]

Of the various histogram-pictures that you have posted, each and every single one shows clipping. For evaluation, you probably want to add a final

ConvertToRGB32(matrix="PC.601")

before returning.

[WorBry]

Thanks for your replys.

With both methods, I'm still seeing the clipping/banding:

With Histogram 'level's:

http://www.mediafire.com/file/zzmtmi...U_Spectrum.png
http://www.mediafire.com/file/q4ufzm...V_Spectrum.png

With final ConvertToRGB32(matrix="PC.601"):

http://www.mediafire.com/file/nvq0nw...um%20RGB32.png
http://www.mediafire.com/file/kdmzdz...um%20RGB32.png

[Didée]

I'm not quite sure what you are seeing, to me those pics look good. Perhaps it is simply a display issue - what kind of display are you using? TFT panel? Possible to make a true screenshot with a camera?

[WorBry]

I'm seeing a lighter vertical band in the upper range (right side) of both spectra. Thought it might be some VDub quirk, but if you are not seeing it in the upoaded pics, maybe it is my display. I'm on my laptop. Unfortunately, I dont have a camera with me. Screen capture predictably shows the same. I'll play around with my display settings meanwhile. Cheers.


Edit: Here's a composite U & V spectrum (VSpec rotated left 45 deg). If you cant see the cross-banding on that one, it must surely be my display.

http://www.mediafire.com/file/mfzyrj...e_Spectrum.png

[Gavino]

I think I understand what you're referring to now.
Taking the USpec for example, and looking at the RGB values in AvsP, the blue ranges from 0 to 255, but the variation is confined to a central band with bands of constant 0 on the left and constant 255 on the right. This is irrespective of adding ConvertToRGB32("PC.601") or not, although this probably changes the relative sizes of the three regions.

I think the explanation is that you have proper U and V gradients (as the histograms show), but on conversion to RGB you get clipping on the ranges of B (for U) or R (for V). This is because the range of U (and V) which produces valid RGB also depends on the value of Y, as can be seen from the formulae on this page.

[WorBry]

If that's the explanation - then what to do, or should I just take it that the spectra are valid in the context of YV12 processing, if not RGB display?

Edit: Cant find any adjustment to my laptop display that makes a difference. Tried coring (16 - 235) the source greyscale gradient, and the output U and V spectra (using Levels, which also clips the chroma) - same thing. On converting the U and V spectra back to luma, there's no clipping of the luma gradient. So I'm inclined to think you are right about the 'Y' factor, as it relates to RGB rendering of UV chroma.

That's why it also is important to avoid luma 'overflow' (rippling) in the blend formulae - luma aberration translates to colour aberration.

[WorBry]

@Gavino,

I replied to your post (new thread) on the subject of 'RGB invalid' YUV chroma:

http://forum.doom9.org/showthread.ph...23#post1402323