AviSynth/AviSynthPlus

GeneralConvolution issue (changes) ?

DTL2020 opened this issue · 1 comments

It looks GeneralConvolution() is somehow broken between 201x and 202x years.

In old decade
GeneralConvolution(0, "
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true, luma=true, chroma=false)
Make some sharpening effect on more medium frequencies in compare with Sharpen() because Sharpen use only 3x3 kernel. Now it return significantly distorted frame with lots of banding. The sum of coefficients is =1 so auto=true/false do nothing.

For simple YV12 format. Tried RGB32, tried 16bit.
At Windows7 tried AVS versions from 2.6 to +3.6 , +3.7 and still the same distortion. May be GeneralConvolution depends on some updated VisualC++ libs or other windows7 components ?

Here most simple form of bug with GeneralConvolution:

GeneralConvolution(0, "
-0.4 -2 -0.4
-2 9 -2
-0.4 -2 -0.4", auto=true, luma=true, chroma=false)

Make sharpening about as expected.

GeneralConvolution(0, "
-0.5 -2 -0.5
-2 9 -2
-0.5 -2 -0.5", auto=true, luma=true, chroma=false)

Turn to significant blurring. The switch from about good to significantly bad result occur when diagonal angle coefficients of simplest 3x3 matrix go from -0.4 to -0.5. Looks like some rounding or auto-normalization error ?

Same is with documentation example:
GeneralConvolution(0, "
-0.4 -1 -0.4
-1 5 -1
-0.4 -1 -0.4 ", auto=true, luma=true, chroma=false)
Still make sharpening as expected.

GeneralConvolution(0, "
-0.5 -1 -0.5
-1 5 -1
-0.5 -1 -0.5 ", auto=true, luma=true, chroma=false)
Switch to very blurry.

Same result with 3.7.2 release, 3.7.3 test 7 x64, x64_xp (x64_clang and x64_IntelClassic not work with AVI import filter error).

May be something was changed in GeneralConvolution processing so 'old matrix' now not work as expected ?

Kernel of 5 at the center and -1 surround also should not be blur kernel. Now the significant discontinuity in output effect from corners kernel members 0 to -1 also not look like correct action. If even floats not accepted it is only expected more significant step from light sharp with
0 -1 0
-1 5 -1
0 -1 0

to stronger sharp with
-1 -1 -1
-1 5 -1
-1 -1 -1.

But now last kernel cause switching to blur. The visible difference - sum of 1st kernel is 5+(-4)=1 and sum of last is 5+(-8)=-3. May this negative sum sign also play role in the issue ?

Checked (YV12 8bit 4:2:0):
-1 -1 -1
-1 5 -1
-1 -1 -1 - blur

-1 -1 -1
-1 6 -1
-1 -1 -1 - slightly sharper

-1 -1 -1
-1 7 -1
-1 -1 -1 - sharper, horizontal and vertical double contour

-1 -1 -1
-1 8 -1
-1 -1 -1 - almost black frame ! (zero sum), still auto=true

-1 -1 -1
-1 9 -1
-1 -1 -1 - finally sharping, auto=true/false - equally.

-1 -1 -1
-1 10 -1
-1 -1 -1 (auto=true - less sharp, auto=false - significant level offset to white)

So auto=true do not work with zero and negative integer sum ?

But kernel of 5x5 of
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

with sum=1 still return sort of HigiPassFilter only with about removed DC component and very low frequencies. DC component (median level and very low frequecies) start to recover to about
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 45 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

45..50..60 value of the 'central' value. So sum is much higher 1. With auto=false and center 80 - return white frame. May be something is changed in 'auto=true' internal processing ?

Attempt to float32:
ConvertBits(32)
GeneralConvolution(0, "
-1 -1 -1
-1 5 -1
-1 -1 -1 ", auto=true, luma=true, chroma=false)
ConvertBits(8)

change nothing from 8bit luma - still blur.

So it looks logic of GeneralConvolution kernel coefficients processing is changed somehow and now for 'sharp' kernels the total sum must be >>1 and only auto=true is working ?
For example now about good linear sharpener is
GeneralConvolution(0, "
-1 -2 -2 -2 -1
-2 -2 -3 -2 -2
-2 -3 70 -3 -2
-2 -2 -3 -2 -2
-1 -2 -2 -2 -1", auto=true, luma=true, chroma=false)
And adjusting center member in range about 60..100 it is now possible to adjust 'strength'. Where 60 is very strong, 100 is very weak and 50 is sort of high-pass filter only. May it is also valuable mode but it looks old versions work differently and old matrices require re-adjustment of 'center' member.

So it may be new feature of GeneralConvolution kernel members auto-normalization ?