Looking for a strong blur only in horizontal direction

[LigH]

I need a configurable blur filter with different strengths per direction, especially a horizontal blur with a float radius I can "Animate", with a range up to 10 or even 20.

The core Blur() filter has different strengths per direction but only a very limited maximum radius (1.58), and stacking it in a dozen would not be very useful.

[DTL]

GaussResize(width, height, force=1,s=0,p=0.1)

Adjust gauss blur radius with p-param. Lower p value makes larger blur.

[LigH]

Force resize to the original dimensions while still applying the kernel ... got it, thank you.

[wonkey_monkey]

GaussResize seems to blur chroma twice as much as luma if it's subsampled (e.g. YV12), and seems to have a limit to how blurry you can go (although you could just apply it more than once).

FastBlur(10,0)

(https://horman.net/avisynth/download/FastBlur0.3.2.zip) takes subsampling into account, and should be quicker for stronger blurs.

Think some of the docs might need updating on GaussResize as they don't mention "force" or "s".

[DTL]

Latest docs looks like this https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

[johnmeyer]

I think that a convolution kernel will do this. Having it work only on adjacent horizontal pixels is the essence of how it works. Something like:[0, 0, 0 ]
[1/3, 1/3, 1/3]
[0, 0, 0 ]

[wonkey_monkey]

Latest docs looks like this https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/resize.html

Ah. Google rather brilliantly directs you to the 3.5 docs...

I must say I am completely nonplussed as what the parameters do even after reading the latest docs, and have absolutely no idea why the numbers given above lead to a horizontal-only blur.

Edit: Ah. It's due to the specific value of "force". The whole "force" thng still seems like a horrible kludge to me.

[DTL]

Before 'force' users had an option to set non-zero src_left param to start convolution processing for h-only blur. But old GaussResize had fixed support (of 4 ?) and more limited p-param value and it limits possible blur radius and quality. Now it can auto-adjust support if s=0.

Yes - there are also IIR-filter small kernel simulation of large radius gauss blur also possible and it expected to be faster in comparison with full-blood FIR filter.

Because programmers may not like to add many new parameters to filters it is planned even more combined options to 'force' parameter of resizers - add planes processing control (like with opt in Asd-g plugins) as bitmask. Currently bits 0 and 1 used as control of forcing processing of different dimensions. Other bits of 32 or even 64bits integer may be used to control type of planes processing (up to 4 planes in RGBA/YUVA formats). Also from 3 variants:
0 - standard process
1 - copy (faster)
2 - return random RAM content as undefined samples values (fastest).

Though at time of script-writing creation of the control variable may be even more complex.

" have a limit to how blurry you can go (although you could just apply it more than once)."

If more blur is required - dual-resize may be used. It may be even faster (need check in each use case).
Like
GaussResize(width/10, height, p=.., s=0)
GaussResize(width*10, height)

"GaussResize seems to blur chroma twice as much as luma if it's subsampled (e.g. YV12)"

I think in the AVS core resampling program is created for each plane in its individual size and filter scaled to the plane size (not frame size) -
may be something from this line and lower - https://github.com/AviSynth/AviSynthPlus/blob/b6d79944a59cf066fa00466ee02edb08e3ca214f/avs_core/filters/resample_functions.cpp#L334 .

If user need other blur scaling over planes - currently possible to split planes and process each plane with required blur param and combine planes.