Dogway's Filters Packs

[Dogway]

A little bit slower you mean. I asked last week so now Str is 2.0 by default, that means it does a slight shadow lift, set to 1.0 to disable (previous behaviour). Also for comparisons it's better to limit to 6 frames delta, 7 uses MDegrainN which is slower.

The other edit I did was revert ex_logic to mt_logic (in Contrasharp function), I found that "min" and "max" modes run slower on Expr(), but it might not be the case, test this if the above doesn't solve it.

[tormento]

Originally Posted by Dogway

Also for comparisons it's better to limit to 6 frames delta, 7 uses MDegrainN which is slower.

I compared apples to apples. Sometimes a higher delta is required on very grainy sources. Long time ago I asked Pinterf to optimize MDegrain up to 9 but it's not a priority.

I did not use Contrasharpening at all.

So, the difference is because of Str=2.0?

[Dogway]

What I meant is that comparing with high delta you are mostly comparing MAnalyse and little else, to easily check the impact of other things (prefilter, sharpening, etc) using a lower delta is preferred. But this is a debugging tip, I also run real case scripts often to compare.

Yes, I can only think of Str. Another thing to compare is quality. The source seems to be 8-bit, aside of quality gain from lifting the shadows in my version prefiltering is performed in 16-bit (knlmeans + luma_rebuild). I would try to compare dark scenes or with low contrast.

[tormento]

Originally Posted by Dogway

Yes, I can only think of Str. Another thing to compare is quality. The source seems to be 8-bit, aside of quality gain from lifting the shadows in my version prefiltering is performed in 16-bit (knlmeans + luma_rebuild). I would try to compare dark scenes or with low contrast.

Thanks for your clarification.

[Dogway]

Quick heads up. Big overhaul day with latest ExTools changes. Most of the filters, except for Transforms Pack have been updated so give it a look if you wish (and report bugs).
Benchmarks for LSFmod (5 fps performance increase) and GrainFactory3mod (+3 fps) have been updated. Cheers.

[kedautinh12]

Thank Dogway

[wonkey_monkey]

Hi Dogway,

Just copying/expanding on this from the Avisynth+ thread.

You can get a speed increase, at least 20%, from ex_boxblur (should work with the rest as well) with the following changes:

    for (px = -krnlrd, krnlrd, 1) {
        krnh = px == -krnlrd ? Format("x[{px},0] ") : Format(krnh + "x[{px},0] + ")
       }
			 
			 krnh = krnh + Format(" {wgh} * ")

...

    for (py = -krnlrv, krnlrv, 1) {
        krnv = py == -krnlrv ? Format("x[0,{py}] ") : Format(krnv + "x[0,{py}] + ")
       }

			 krnv = krnv + Format(" {wgh} * ")

...

    str  = "x[-1,1] x[0,1] + x[1,1] + x[-1,0] + x[0,0] + " \
          +"x[1,0] + x[-1,-1] + x[0,-1] + x[1,-1] + 0.111111 * "

This replaces all the individual pixel multiplications with a single trailing multiplications.

It should also minimise rounding error. Personally I'd add a few more digits to 0.111111 as well (9 ones gives you the minimum rounding error when storing 1/9 as a float)

[Dogway]

Yes, I did the edits and get some 4% performance increase for ex_boxblur(1). Following with radius of 4.

# 294fps  286fps (pp sum, pp mult)
#ex_boxblur(4)

# 298fps 303fps (trailed sum, global div)
#ex_boxblur(4)

# 265fps 268fps (trailed sum, pp mult)
#ex_boxblur(4)

# 314fps 313fps (trailed sum, global mult)
ex_boxblur(4)

Yes, with trailed sum global mult I gain 4%, so 91% of removegrain(19,-1) (483fps) vs ex_boxblur(1, UV=1) (441fps)

It should also minimise rounding error. Personally I'd add a few more digits to 0.111111 as well (9 ones gives you the minimum rounding error when storing 1/9 as a float)

I thought Expr() would round to 6 decimals.


The edited function:

function ex_boxblur(clip a, int "radius", int "radiusV", int "UV", bool "fulls") {

    rgb  = isRGB(a)
    isy  = isy(a)
    bi   = BitsPerComponent(a)

    rd = Default(radius,  1)            # from 0 to inf
    rv = Default(radiusV, rd)           # from 0 to inf
    UV = Default(UV, rgb ? 3 : 1)
    fs = Default(fulls, false)
    rd = max(rd, 1)
    rv = max(rv, 1)

    krnlsz = 2 * rd + 1
    krnlrd = krnlsz/2

    krnh = ""
    for (px = -krnlrd, krnlrd, 1) {
        krnh = Format(krnh + "x[{px},0] ")
        plsh = px == -krnlrd ? "" : plsh + "+ "
       }

    krnlsz = 2 * rv + 1
    krnlrv = krnlsz/2

    krnv = ""
    for (py = -krnlrv, krnlrv, 1) {
        krnv = Format(krnv + "x[0,{py}] ")
        plsv = py == -krnlrv ? "" : plsv + "+ "
       }

    str  = "x[-1,1] x[0,1] x[1,1] x[-1,0] x[0,0] x[1,0] x[-1,-1] x[0,-1] x[1,-1] + + + + + + + + 0.111111111 *"

    fbox = rd == 1 && rv == 1
    strv = fbox ? str : krnv + plsv + string(1. / krnlrv*2+1) + " *" 
    strh =              krnh + plsh + string(1. / krnlrd*2+1) + " *"

    rv == 0 ?      a                                                                  : \
    isy     ? Expr(a,    strv                                                       ) : \
    UV == 1 ? Expr(a,    strv, ""                                                   ) : \
              Expr(a,    strv, ex_UVexpr(strv, UV, bi, rgb, fs), scale_inputs="none")
    rd == 0 || fbox  ? last                                                           : \
    isy     ? Expr(last, strh                                                       ) : \
    UV == 1 ? Expr(last, strh, ""                                                   ) : \
              Expr(last, strh, ex_UVexpr(strh, UV, bi, rgb, fs), scale_inputs="none") }

[wonkey_monkey]

I thought Expr() would round to 6 decimals.

6-7 significant decimal digits is often quoted as the limit for floats, but it's only an approximation. Expr itself reads floats using a stringstream, which takes in all the digits and does its best to convert them to a float.

With 6 ones, the value stored is (approximately):

0.11111100018024444580078125

With 9 or more ones, it's:

0.11111111193895339965820312

[Dogway]

Thanks for the help, I will update and rerun benchmarks to see what I get and update OP if necessary.

[wonkey_monkey]

It occurs to me that a box blur is one case where a non-SIMD variation of Expr could, in theory, work better. The ideal algorithm reads every pixel exactly twice - once when adding it to an accumulator, once when subtracting it. That will give you a near constant-time box blur. Expr has to read the full box of pixels every time.

On another topic, doesn't RemoveGrain(19) only averages the eight neighbours, missing out the central pixel? You should give yourself an extra 11.1% for that

[Dogway]

I did some optimizations to the kernels aside from the above tips and did some benchs and wow, ex_blur(1) is now 96% of removegrain(12)! ex_boxblur(1) is 91% (read below).
Also shaved 4% for ex_xxflate(). Optimized also some convolutions from ex_edge() so they should run faster, for some reason "hprewitt" is bugged I would swear it was working fine before. Also added Overlay_MTools() to the list.

@wonkey_monkey: I don't remember fine but I think I didn't like what it was doing with bigger radius. In any case I removed the central pixel to match removegrain(19) (for parity) and then keep as previous for bigger radius. Now the speed is 97% that of removegrain!

[kedautinh12]

I think can apply above code in here
https://github.com/Dogway/Avisynth-S...rter.avsi#L246

[wonkey_monkey]

I saw BicubicResize on that line of code. Did you know that, with default parameters, BicubicResize is actually a little bit blurry, even if you do a "null" resize with just a infinitessimal shift of pixels? Setting b = 0, c = 0.5 fixes it and is more mathematically correct.

[kedautinh12]

Thanks

[kedautinh12]

About blur(.6)
https://forum.doom9.org/showthread.p...77#post1946677

[Arx1meD]

Concerning the ex_merge function.
The formula (x*(range_max-z)+y*z)/255 can be simplified to x-(x-y)*(z/range_max)
This will increase the speed.

change

str = "x range_max z - * y z * + range_max /"

to

str = "x x y - z range_max / * -"

[Dogway]

Wow thank you, I was giving it a thought yesterday but couldn't come with any idea, except for the usual reciprocal.

"x x y - z 1 range_max / * * -"

I updated ExTools with several more updates, LSFmod and FrameRateConverter.

[kedautinh12]

Thanks

[kedautinh12]

But how wonkey_monkey said about BicubicResize in Framerateconverter???