porting LSFmod for HBD in avs+

[real.finder]

edit: all old talk that was here moved to the 2nd post now

the porting is done https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/LSFmod.avsi

[real.finder]

days ago start port LSFmod, I didn't care for it before cuz I don't use sharp most of times but since it's used by SMDegrain so I plan for port it

but there are some lut lines that can't make it give same result in another bit depth, but in 32 bit with clamp_f_i8 it's ok

https://pastebin.com/NnjaqCa8

the problem when use smode 4 and 5


\ : Smode==4 ? VersionNumber() < 2.6 ? mt_lutxy(tmp, method, yexpr="x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - 2 ^ x y - 2 ^ "
\ +string(SdmpLo)+" + / * x y - x y - abs / * 1 "+string(SdmpHi)+" 0 == 0 x y - abs "+string(SdmpHi)+" / 4 ^ ? + / + ?",U=1,V=1) \
: mt_lutxy(tmp, method, yexpr="clamp_f_i8 x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - 2 ^ x y - 2 ^ "
\ +string(SdmpLo)+" scalef + / * x y - x y - abs / * 1 "+string(SdmpHi)+" 0 == 0 x y - abs "+string(SdmpHi)+" / 4 ^ ? + / + ?",U=1,V=1)
\ : VersionNumber() < 2.6 ? mt_lutxy(tmp, method, yexpr="x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - x y - abs / * x y - 2 ^ "
\ +string(Szrp)+" 2 ^ "+string(SdmpLo)+" + * x y - 2 ^ "+string(SdmpLo)+" + "+string(Szrp)+" 2 ^ * / * 1 "
\ +string(SdmpHi)+" 0 == 0 "+string(Szrp)+" "+string(SdmpHi)+" / 4 ^ ? + 1 "+string(SdmpHi)+" 0 == 0 x y - abs "+string(SdmpHi)+" / 4 ^ ? + / * + ?",U=1,V=1) \
: mt_lutxy(tmp, method, yexpr="clamp_f_i8 x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - x y - abs / * x y - 2 ^ "
\ +string(Szrp)+" 2 ^ "+string(SdmpLo)+" scalef + * x y - 2 ^ "+string(SdmpLo)+" scalef + "+string(Szrp)+" 2 ^ * / * 1 scalef "
\ +string(SdmpHi)+" 0 == 0 "+string(Szrp)+" scalef "+string(SdmpHi)+" scalef / 4 ^ ? + 1 scalef "+string(SdmpHi)+" scalef 0 == 0 x y - abs "+string(SdmpHi)+" scalef / 4 ^ ? + / * + ?",U=1,V=1)


some test code for lut only (smode=4), Formula in non RPN https://s11.postimg.org/ej1ht7bo3/Untitled.png


#video source here
convertbits(16)
tmp=last
method=Blur(1)

szrp=16
spwr=4
str=100/100.0
sdmplo=4
sdmphi=48

mt_lutxy(tmp, method, yexpr="clamp_f_i8 x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - 2 ^ x y - 2 ^ "
\ +string(SdmpLo)+" scalef + / * x y - x y - abs / * 1 "+string(SdmpHi)+" 0 == 0 x y - abs "+string(SdmpHi)+" / 4 ^ ? + / + ?",U=1,V=1)
convertbits(8)


maybe we need pinterf to make an option to scale the inputs (x, y, etc...) in non floats sources too (like scale_input=true, and it's better to make it true by default so any old script that no one port yet may work in HBD without any edit), and keep only clamp_f out of another clamp_f_XX

edit: scale_inputs="int" or "float" or "both" (default) or "none" will be better than bool

I forgot to mention that there are other changes, like fix https://forum.doom9.org/showthread.php?p=1807637#post1807637

and remove yv12 limit, and some speed optimization in avs2.6 and avs+ (thanks to Y8/Y)

[FranceBB]

Thanks! :)
Any chance in getting it to work in 16bit with Dither Tool in Avisynth 2.6 (not just AVS+)?

[pinterf]

days ago start port LSFmod, I didn't care for it before cuz I don't use sharp most of times but since it's used by SMDegrain so I plane for port it

but there are some lut lines that can't make it give same result in another bit depth, but in 32 bit with clamp_f_i8 it's ok

https://pastebin.com/NnjaqCa8

some test code for lut only (smode=4), Formula in non RPN https://s11.postimg.org/ej1ht7bo3/Untitled.png


#video source here
convertbits(16)
tmp=last
method=Blur(1)

szrp=16
spwr=4
str=100/100.0
sdmplo=4
sdmphi=48

mt_lutxy(tmp, method, yexpr="clamp_f_i8 x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - 2 ^ x y - 2 ^ "
\+string(SdmpLo)+" scalef + / * x y - x y - abs / * 1 "+string(SdmpHi)+" 0 == 0 x y - abs "+string(SdmpHi)+" / 4 ^ ? + / + ?",U=1,V=1)
convertbits(8)


maybe we need pinterf to make an option to scale the inputs (x, y, etc...) in non floats sources too (like scale_input=true, and it's better to make it true by default so any old script that no one port yet may work in HBD without any edit), and keep only clamp_f out of another clamp_f_XX

edit: scale_inputs="int" or "float" or "both" (default) or "none" will be better than bool

Finally got time and had a look at the formula itself.

szrp, sdmphi is in the 8-bit (256) magnitude
sdmplo appears in a square context so it should be in the 256^2 magnitude

Thus for 10-16 bits variables szrp and sdmphi must be scaled by 4* (10 bits) or 256* (16 bits).
Or they have to be divided by 255.0 for 32 bit float.

Same rule applies on sdmplo, but the scaling is 4*4 (10 bits) and 256*256 (16 bits). And for 32 bit float we should divide its original value by (255.0*255.0).

So this expression won’t work properly even for 10-16 bits.

Good news (obviously) that there is no need of extra pre-scaling magic for float, we cannot divide apples with oranges. The constants are for 8 bits data, they have to be scaled accordingly. The scaling can also be done with scaleb inside the expression string.

This solution gave me nearly identical results for all bit depths.

(Script contains tests for the new avs+ filter Expr, ignore it at the moment)

(source filter)
Spline64Resize(480,240) #resize, result is a multistacked image
src=last

# expr
c8 = CalcTest(src,8, False)
c16 = CalcTest(src,16, False)
c32 = CalcTest(src,32, False)

# lutxy
c8e = CalcTest(src,8, True)
c16e = CalcTest(src,16, True)
c32e = CalcTest(src,32, True)

res8=Diff(c8,src)
res16=Diff(c16,src)
res32=Diff(c32,src)

res8e=Diff(c8e,src)
res16e=Diff(c16e,src)
res32e=Diff(c32e,src)

col1=StackVertical(c8,c16.convertbits(8),c32.convertbits(8))
col2=StackVertical(res8, res16, res32)
col3=StackVertical(c8e,c16e.convertbits(8),c32e.convertbits(8))
col4=StackVertical(res8e, res16e, res32e)
StackHorizontal(col1, col2, col3, col4)

Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

Function CalcTest(clip src, int bits, bool lut)
{
src
convertbits(bits)
tmp=last
method=Blur(1)

szrp=16
spwr=4
str=100/100.0
sdmplo=4
sdmphi=48
expr = "x y == x x x y - abs "+string(Szrp) +" scaleb / 1 "+string(Spwr)+" / ^ "+string(Szrp) +" scaleb * "+string(str)+" * x y - 2 ^ x y - 2 ^ "
\+string(SdmpLo)+" scaleb scaleb + / * x y - x y - abs / * 1 "+string(SdmpHi)+" scaleb 0 == 0 x y - abs "+string(SdmpHi)+" scaleb / 4 ^ ? + / + ?"
ret=lut ? mt_lutxy(tmp,method, yexpr=expr, U=1,V=1 ) : Expr(tmp,method,expr,"","")
return ret
}

[real.finder]

seems ok. good scale, but what about the other expr? you only test with smode 4 there are another one and more complex (smode 5)

well even if your scale is better than using any "extra pre-scaling magic" and even faster (theoretically), I don't think you can do same thing with other expr's especially for float

and like I said here (https://github.com/pinterf/masktools/issues/1#issuecomment-340470392) "extra pre-scaling magic" it's better than edit hundreds of scripts just for high bit :) you can make it auto (https://github.com/pinterf/masktools/issues/1#issuecomment-337638835) and none by default in new Expr() since there are no old scripts made with it

and thank you for your time for look at this issue, and for developing avs things

[pinterf]

Now I had only time for this, smode 5 follows. At least it turned out that expr used pow for ^ and = for ==. So I made available the mt_lut syntax in Expr to avoid using different expression strings.

[real.finder]

finally! here is the last "working" one (need last masktools and avs+ (https://forum.doom9.org/showthread.php?p=1844527#post1844527))

https://pastebin.com/uG1jcPKt

some expr still use lut since there are some differences in output and make image darker or brighter, don't know if it bug in avs+ expr or something else, let see what pinterf said

even if I test smode from 3 to 5 in 16 and 32 bit, other options need to test by any volunteer

[pinterf]

Investigating.

EDIT:
Problem fixed in avs+ r2721 test. See avs+ topic

Evaluating the expression with Expr is a must have.
Checked the speeds for a 16 bit clip: for smode=3 the speed factor is 4x. For smode=4 the speed gain is even higher: 10x (on i7-7700, it has AVX2, Expr benefits from it)

[real.finder]

the last edit now, I think you can use it for real encode now! https://pastebin.com/J5CRtqjj (not the last one now, see the post below)


Evaluating the expression with Expr is a must have.
Checked the speeds for a 16 bit clip: for smode=3 the speed factor is 4x. For smode=4 the speed gain is even higher: 10x (on i7-7700, it has AVX2, Expr benefits from it)

yes it's very fast now in HBD, maybe in the future all new expr's in new functions will not use lut anymore especially if avs+ continuously evolving

[real.finder]

fix a bug that happen in the last edit and high optimization ver.

test done using 2012 pentium laptop cpu (don't has avx) and the tests done with every lut line separately

stable new LSFmod https://pastebin.com/pzACBAX1

another scripts updates will come soon

[FranceBB]

fix a bug that happen in the last edit and high optimization ver.

test done using 2012 pentium laptop cpu (don't has avx) and the tests done with every lut line separately

stable new lsfmod https://pastebin.com/WVmCWifm

another scripts updates will come soon

Thank you for your efforts. Is there any change in the code for 8bit processing or can I stick with the old one if I have Avisynth 2.6.1?

Last but not least, I'm gonna quote myself, asking the same question I asked a year ago:

Thanks! :)
Any chance in getting it to work in 16bit stacked or interleaved (HDR Core/Dither Tools) in Avisynth 2.6 (not just AVS+)?

[real.finder]

Thank you for your efforts. Is there any change in the code for 8bit processing or can I stick with the old one if I have Avisynth 2.6.1?

there are some

like fix https://forum.doom9.org/showthread.php?p=1807637#post1807637

and remove yv12 limit, and some speed optimization in avs2.6 and avs+ (thanks to Y8/Y)

Last but not least, I'm gonna quote myself, asking the same question I asked a year ago:
Any chance in getting it to work in 16bit stacked or interleaved (HDR Core/Dither Tools) in Avisynth 2.6 (not just AVS+)?

not likely

[`Orum]

This doesn't appear to work when using it to upscale, i.e. dest_x or dest_y are larger than the input clip. I'll work on a fix unless real.finder is still around, as he's more familiar with the script than me.

[real.finder]

This doesn't appear to work when using it to upscale, i.e. dest_x or dest_y are larger than the input clip. I'll work on a fix unless real.finder is still around, as he's more familiar with the script than me.

fixed :)

[FranceBB]

fixed :)

Good to know, thanks.
I laughed reading back my post from 2017 in which I was asking for 16bit stacked or interleaved as I was on Avisynth 2.6.1 and I was tied to these two high bit depth options xD
(Yes, it was 2017 and I moved to Avisynth+ one year later) :P

[real.finder]

Good to know, thanks.
I laughed reading back my post from 2017 in which I was asking for 16bit stacked or interleaved as I was on Avisynth 2.6.1 and I was tied to these two high bit depth options xD
(Yes, it was 2017 and I moved to Avisynth+ one year later) :P

I just did another fix for using source clip case and some YUY2 cases codes

when dest_x or dest_y are larger than the input clip there are no YUY2 support and no avs2.6/avs+ speed up ofc

aside form that, 16bit stacked maybe impossible for LSFmod since lut/expr code was hard even for HBD

[Gser]

(Yes, it was 2017 and I moved to Avisynth+ one year later) :P

I remember that. It was a good day.

[Tempter57]

real.finder
Hi, LSFmod v.2.183 clashes with SMDegrain v3.1.2.104s, it concerns lines with sisupscale : "MergeLuma: Images must have same width and height! LSFmod v.2.183.avsi, line 600 \SMDegrain v3.1.2.104s.avsi, line 545"

[real.finder]

real.finder
Hi, LSFmod v.2.183 clashes with SMDegrain v3.1.2.104s, it concerns lines with sisupscale : "MergeLuma: Images must have same width and height! LSFmod v.2.183.avsi, line 600 \SMDegrain v3.1.2.104s.avsi, line 545"

fixed https://pastebin.com/P2TDCB7d

[Tempter57]

fixed https://pastebin.com/P2TDCB7d

Thanks you for script updating, now all are normal, it was necessary to connect only still function
function Padding(clip c, int left, int top, int right, int bottom)
{
w = c.width()
h = c.height()
c.pointresize( w+left+right, h+top+bottom, -left, -top, w+left+right, h+top+bottom )
}

[real.finder]

Thanks you for script updating, now all are normal, it was necessary to connect only still function
function Padding(clip c, int left, int top, int right, int bottom)
{
w = c.width()
h = c.height()
c.pointresize( w+left+right, h+top+bottom, -left, -top, w+left+right, h+top+bottom )
}

I have Padding as part of Advanced Denoising.avsi

anyway I plan to change this soon as I said here https://forum.doom9.org/showthread.php?p=1884872#post1884872

[Tempter57]

I have Padding as part of Advanced Denoising.avsi

anyway I plan to change this soon as I said here https://forum.doom9.org/showthread.php?p=1884872#post1884872

Has understood, but there was a problem of application LSFmod with smode=1 and smode=2

[real.finder]

Has understood, but there was a problem of application LSFmod with smode=1 and smode=2

that because not all filters updated yet to use avs 2.6 Y8

try this https://pastebin.com/eE37iYWZ

LSFmod(smode=2,avs26_optimize=false)

and if all filters updated later then you will not need to set avs26_optimize=false

[Boulder]

Found a little problem with show=true: the AddBorders calls have an incorrect syntax. Fixed by removing ',true' off them.

[real.finder]

Found a little problem with show=true: the AddBorders calls have an incorrect syntax. Fixed by removing ',true' off them.

what settings and what LSFmod is used? since I got no problem with lsfmod(show=true)

[Boulder]

HD source, AVS+ v3.6. The latest version of LSFMod, defaults="slow", show=true right after loading the source.

As far as I know, AddBorders doesn't have any Boolean variables.

[real.finder]

HD source, AVS+ v3.6. The latest version of LSFMod, defaults="slow", show=true right after loading the source.

As far as I know, AddBorders doesn't have any Boolean variables.

yes, it's copy/paste bug when I add it to crop, I will update it soon

[Boulder]

While you're working on the script, is it possible to get a larger kernel to use with (U)HD sources? As far as I remember, the 3x3 kernel suits SD sources but HD would require a larger one for the same effect regarding detail enhancement.

[real.finder]

While you're working on the script, is it possible to get a larger kernel to use with (U)HD sources? As far as I remember, the 3x3 kernel suits SD sources but HD would require a larger one for the same effect regarding detail enhancement.

I think that need RemoveGrainHD

[Boulder]

Ah, that one is still non-hbd :(

[LeXXuz]

I'm playing around with LSFmod a little. I use latest avs+ and LSFmod v2.187.

I use either 10-bit or 16-bit scripts/filterchains and I've noticed the sharpening effect with the default value of 100 is rather subtle, if noticeable at all.
So just increase strength to your liking, right? Well that works fine on LBD. However on HBD I get artefacts.

For a little test I use this line on a 1080p source:
LSFmod(strength=400, defaults="slow")

I chose 400 (which is way too much, of course) to make the difference more visible. ;)

8-bit looks okay, well oversharpened but okay. 10/16-bit looks, well see for yourself:

https://abload.de/thumb/2020-07-04123ckta.png (https://abload.de/image.php?img=2020-07-04123ckta.png)https://abload.de/thumb/2020-07-043x2kul.png (https://abload.de/image.php?img=2020-07-043x2kul.png)

Why is this happening in HBD?

[real.finder]

I'm playing around with LSFmod a little. I use latest avs+ and LSFmod v2.187.

I use either 10-bit or 16-bit scripts/filterchains and I've noticed the sharpening effect with the default value of 100 is rather subtle, if noticeable at all.
So just increase strength to your liking, right? Well that works fine on LBD. However on HBD I get artefacts.

For a little test I use this line on a 1080p source:
LSFmod(strength=400, defaults="slow")

I chose 400 (which is way too much, of course) to make the difference more visible. ;)

8-bit looks okay, well oversharpened but okay. 10/16-bit looks, well see for yourself:

https://abload.de/thumb/2020-07-04123ckta.png (https://abload.de/image.php?img=2020-07-04123ckta.png)https://abload.de/thumb/2020-07-043x2kul.png (https://abload.de/image.php?img=2020-07-043x2kul.png)

Why is this happening in HBD?

https://i.postimg.cc/PP9SLY5c/2020-07-04123ckta.png (https://postimg.cc/PP9SLY5c)

with

ImageSource("2020-07-04123ckta.png")
converttoyv24
convertbits(16)
LSFmod(strength=400, defaults="slow")
convertbits(8)

https://i.postimg.cc/5Qjmy2db/test-Copy-3-Copy-Copy000120.png (https://postimg.cc/5Qjmy2db)

[LeXXuz]

Thanks for the quick response. So something seems to be wrong on my system? :o But I wonder what. :(

[real.finder]

Thanks for the quick response. So something seems to be wrong on my system? :o But I wonder what. :(

can you try with the same image I post? maybe the original frame has noise that case this

if it still has that artefacts then make sure that you use last rgtools https://github.com/pinterf/RgTools and masktools https://github.com/pinterf/masktools/

[LeXXuz]

It seems I was NOT running the latest AVS+ version. My bad. :o

I had r3106, 3.5 (x64) installed. Now updated to r3300, 3.6 (x64)

But I can't get LSFmod to work anymore.
Some problem with version check:
https://abload.de/thumb/2020-07-0415snj5d.png (https://abload.de/image.php?img=2020-07-0415snj5d.png)

My AvsPlusVersionNumber.avsi
function IsAvsPlus()
{
FindStr(VersionString, "AviSynth+") != 0
}

function AvsPlusVersionNumber()
{
IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0
}

My LSFmod.avsi:
https://pastebin.com/cZFKV0ab

Can't I just remove this version check thingy somehow?

[real.finder]

It seems I was NOT running the latest AVS+ version. My bad. :o

I had r3106, 3.5 (x64) installed. Now updated to r3300, 3.6 (x64)

But I can't get LSFmod to work anymore.
Some problem with version check:
https://abload.de/thumb/2020-07-0415snj5d.png (https://abload.de/image.php?img=2020-07-0415snj5d.png)

My AvsPlusVersionNumber.avsi
function IsAvsPlus()
{
FindStr(VersionString, "AviSynth+") != 0
}

function AvsPlusVersionNumber()
{
IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0
}

My LSFmod.avsi:
https://pastebin.com/cZFKV0ab

Can't I just remove this version check thingy somehow?

update scripts from https://github.com/realfinder/AVS-Stuff

[LeXXuz]

What exactly should I update? :o

I can only find this avsi on that page:
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/LSFmod.avsi

Which looks to be the same.

[Boulder]

Zs_RF_Shared.avsi is one to update as well, it contains a lot of helper functions etc.

[LeXXuz]

Zs_RF_Shared.avsi is one to update as well, it contains a lot of helper functions etc.

That's what I was missing. Thank you! :)

can you try with the same image I post? maybe the original frame has noise that case this

if it still has that artefacts then make sure that you use last rgtools https://github.com/pinterf/RgTools and masktools https://github.com/pinterf/masktools/

Well I get the same result with this image as you do.
Then I took a picture of the source frame and ran your little script with it. Again no artefacts.

So, like you already assumed, something must be in the source vid that produces these artefacts. But why only in HBD? And how do I get rid of these? :confused:

I could downconvert to 8-bit, use LSFm and convert back up to 16-bit before using the next filter, but thats not really ideal, isn't it?

[real.finder]

Then I took a picture of the source frame and ran your little script with it. Again no artefacts.


then it should work with video too, did you tried after updating things?

anyway, sharpening should be after denoising

[LeXXuz]

then it should work with video too, did you tried after updating things?

anyway, sharpening should be after denoising

Yeah it's odd. I don't understand it atm. But the result with the source video is the same as before.

I always denoise before using LSFm. And, believe it or not, this picture is already denoised with a 2 stage filtering by dfttest. If I'll do more, I'll lose too much detail...

Usually I use some chain like:

-convert to 10/16bit
-denoise: dfttest (sometimes fft3dgpu, but rarely since it doesn't support HBD)
-sharpen: LSFm
-deband: neo_f3kdb
-encode to i420p10 with x.265

I was quite happy to now have a complete HBD capable filter chain, until I saw these strange artefacts.

However, I still have 0.98 of RGTools (x64-clang) and masktools2-v2.2.21 (x64-clang). Can this be the problem?

I saw you have newer versions on your page but I could only find source codes. (And I'm too dumb to compile stuff myself :()

Would be great if someone has these as compiled x64-dlls (maybe even optimized for Zen2 ?)

[real.finder]

Yeah it's odd. I don't understand it atm. But the result with the source video is the same as before.

I always denoise before using LSFm. And, believe it or not, this picture is already denoised with a 2 stage filtering by dfttest. If I'll do more, I'll lose too much detail...

Usually I use some chain like:

-convert to 10/16bit
-denoise: dfttest (sometimes fft3dgpu, but rarely since it doesn't support HBD)
-sharpen: LSFm
-deband: neo_f3kdb
-encode to i420p10 with x.265

I was quite happy to now have a complete HBD capable filter chain, until I saw these strange artefacts.

However, I still have 0.98 of RGTools (x64-clang) and masktools2-v2.2.21 (x64-clang). Can this be the problem?

I saw you have newer versions on your page but I could only find source codes. (And I'm too dumb to compile stuff myself :()

Would be great if someone has these as compiled x64-dlls (maybe even optimized for Zen2 ?)

can you upload raw video sample?

https://i.postimg.cc/yxzdKPC9/Untitled.png (https://postimages.org/)

https://github.com/pinterf/RgTools/releases has the compiled dlls, same for masktools2

and it's by pinterf not mine

[LeXXuz]

I did some testing with a few titles and I'm quite sure now it's not the movie.

Only noisy material makes those artefacts visible 'earlier'.

These next screenshots are taken from Angry Birds anime movie which is perfectly clean.
So I had to crank strength up to 1000(:eek:) to make the difference appear more noticeable.
I know that's way off daily use, but there's a clear visible difference. And it shouldn't, right?

https://abload.de/thumb/2020-07-0427yik7j.png (https://abload.de/image.php?img=2020-07-0427yik7j.png)https://abload.de/thumb/2020-07-04282ej75.png (https://abload.de/image.php?img=2020-07-04282ej75.png)


Note that strange solarize effect that appears on the HBD version. It seems the limiting does not quite work as it should and as it does in the LBD version.

Anyhow, I will update my RGTools and Masktools to see if it'll make any difference. :)

[feisty2]

the LUT expressions were targeted for 8-bit range (0-255), have you tweaked the expressions accordingly for each bit depth? you have to first scale the pixel range to [0.0, 255.0] before the LUT evaluation then scale it back when the evaluation completes.

[real.finder]

the LUT expressions were targeted for 8-bit range (0-255), have you tweaked the expressions accordingly for each bit depth? you have to first scale the pixel range to [0.0, 255.0] before the LUT evaluation then scale it back when the evaluation completes.

that already done, but I think there are some bug in bit scale (round error), I will see where it is

[real.finder]

I made mini LSFmod for debug


function LSFmoddebug( clip inclip )
{

ox = inclip.width
oy = inclip.height

strength = 400
kernel = 11

Szrp = 16
Spwr = 4
SdmpLo = 4
SdmpHi =48

overshoot = 4
undershoot = overshoot
overshoot2 = overshoot*2
undershoot2 = overshoot2

soft = -2
keep =20

ss_x = 1.50
ss_y = ss_x
dest_x = ox
dest_y = oy

soft = int( (1.0+(2.0/(ss_x+ss_y))) * sqrt(strength) )
soft = soft<=100 ? soft : 100

xxs = round(ox*ss_x/8)*8
yys = round(oy*ss_y/8)*8

str = float(strength)/100.0

input = inclip.converttoy()

### SHARP
tmp = input.spline36resize(xxs,yys)
pre = tmp

dark_limit = pre.mt_inpand(U=1,V=1)
bright_limit = pre.mt_expand(U=1,V=1)
minmaxavg = mt_average(dark_limit,bright_limit,U=1,V=1)

method1 = minmaxavg.removegrain(kernel,-1)

method = method1.mt_lutxy(pre,"x y < x 1 scalef + x y > x 1 scalef - x ? ?",use_expr=2,U=1,V=1)

normsharp = mt_lutxy(tmp, method, yexpr="x y == x x x y - abs "+string(Szrp)+" / 1 "+string(Spwr)+" / ^ "+string(Szrp)+" * "+string(str)+" * x y - x y - abs / * x y - 2 ^ "
\ +string(Szrp)+" 2 ^ "+string(SdmpLo)+" + * x y - 2 ^ "+string(SdmpLo)+" + "+string(Szrp)+" 2 ^ * / * 1 "
\ +string(SdmpHi)+" 0 == 0 "+string(Szrp)+" "+string(SdmpHi)+" / 4 ^ ? + 1 "+string(SdmpHi)+" 0 == 0 x y - abs "+string(SdmpHi)+" / 4 ^ ? + / * + ?",U=1,V=1,use_expr=2,scale_inputs="allf")


### LIMIT
normal = mt_clamp(normsharp, bright_limit, dark_limit, overshoot, undershoot, U=1, V=1)
second = mt_clamp(normsharp, bright_limit, dark_limit, overshoot2, undershoot2, U=1, V=1)

edge1 = mt_logic( tmp.mt_edge(thY1=0,thY2=255,"8 16 8 0 0 0 -8 -16 -8 4",U=1,V=1)
\ ,tmp.mt_edge(thY1=0,thY2=255,"8 0 -8 16 0 -16 8 0 -8 4",U=1,V=1)
\ ,"max",U=1,V=1)

edge = edge1.mt_lut("x range_half / 0.86 ^ range_max *",use_expr=2,scale_inputs="floatf",clamp_float=true,U=1,V=1)

limit1 = mt_merge(second, normal, edge.mt_inflate(U=1,V=1), U=1, V=1)

limit2 = limit1


### SOFT
sharpdiff1 = mt_makediff(tmp,limit2,U=1,V=1)
sharpdiff = mt_lutxy(sharpdiff1,sharpdiff1.removegrain(19,-1),
\ "x range_half - abs y range_half - abs > y "+string(soft)+" * x "+string(100-soft)+" * + 100 / x ?",use_expr=2,U=1,V=1)

PP1 = mt_makediff(tmp,sharpdiff,U=1,V=1)


### SOOTHE
diff = mt_makediff(tmp,PP1,U=1,V=1)
diff2 = diff.temporalsoften(1,255,0,32,2)
diff3 = mt_lutxy(diff,diff2,"x range_half - y range_half - * 0 < x range_half - 100 / "+string(keep)+
\ " * range_half + x range_half - abs y range_half - abs > x "+string(keep)+" * y 100 "+string(keep)+" - * + 100 / x ? ?",use_expr=2,clamp_float=true,U=1,V=1)

PP2 = mt_makediff(tmp,diff3,U=1,V=1)


### OUTPUT
out = PP2.spline36resize(dest_x,dest_y)

in = input

shrpD = mt_makediff(in,out,U=1,V=1)
output = out

output = CombinePlanes(output,inclip,planes="YUV",sample_clip=inclip)

return output
}
Source("")
convertbits(16)
LSFmoddebug()
convertbits(8)

[real.finder]

ok, I think I know why, every function (Especial the cores and the rgtools one) give slightly different output in HBD compare to 8bit and since it's complex script then the final output is kinda big different compare to 8bit one, maybe because these are as old as https://forum.doom9.org/showthread.php?p=1916380#post1916380 so they has no rounding

edit: using https://forum.doom9.org/showthread.php?p=1916545#post1916545 you can check with

ColorBars
converttoyv12
AddGrainC(constant=true)
Interleave(somefilter().luma_histogram(),convertbits(16).somefilter().convertbits(8).luma_histogram())

[real.finder]

I did some testing with a few titles and I'm quite sure now it's not the movie.

Only noisy material makes those artefacts visible 'earlier'.

These next screenshots are taken from Angry Birds anime movie which is perfectly clean.
So I had to crank strength up to 1000(:eek:) to make the difference appear more noticeable.
I know that's way off daily use, but there's a clear visible difference. And it shouldn't, right?

https://abload.de/thumb/2020-07-0427yik7j.png (https://abload.de/image.php?img=2020-07-0427yik7j.png)https://abload.de/thumb/2020-07-04282ej75.png (https://abload.de/image.php?img=2020-07-04282ej75.png)


Note that strange solarize effect that appears on the HBD version. It seems the limiting does not quite work as it should and as it does in the LBD version.

Anyhow, I will update my RGTools and Masktools to see if it'll make any difference. :)

can you try this update? https://github.com/realfinder/AVS-Stuff/raw/Community/avs%202.5%20and%20up/LSFmod.avsi

[Boulder]

Does the problem affect also other ports, like FineSharp?

[real.finder]

Does the problem affect also other ports, like FineSharp?

I think no, LSFmod was more complex, but you can try with many settings and see

[LeXXuz]

can you try this update? https://github.com/realfinder/AVS-Stuff/raw/Community/avs%202.5%20and%20up/LSFmod.avsi

Today I'm not at home. I'll test it tomorrow and report back to you. :)

[LeXXuz]

Okay, here are the results:

Source:
https://abload.de/thumb/2020-07-07_source75jcc.png (https://abload.de/image.php?img=2020-07-07_source75jcc.png)

LSFmod (new) in 8-bit:
https://abload.de/thumb/2020-07-071_8bit5xjij.png (https://abload.de/image.php?img=2020-07-071_8bit5xjij.png)

LSFmod (new) in 10-bit:
https://abload.de/thumb/2020-07-072_10bit7xjhk.png (https://abload.de/image.php?img=2020-07-072_10bit7xjhk.png)

LSFmod (new) in 16-bit:
https://abload.de/thumb/2020-07-073_16bitjtkwu.png (https://abload.de/image.php?img=2020-07-073_16bitjtkwu.png)

LSFmod (old) in 16-bit:
https://abload.de/thumb/2020-07-074_16bit-oldb2ko1.png (https://abload.de/image.php?img=2020-07-074_16bit-oldb2ko1.png)

Looks alright to my eyes. Out of curiosiy, what did you change exactly?

Anyhow thank you very much for maintaining this script and looking into this! :) :thanks:

[real.finder]

Out of curiosiy, what did you change exactly?


https://github.com/realfinder/AVS-Stuff/commit/101bb78673aec19e71dd1613a93f93a0ead9e2ff

I did this, in 8bit will still same since the lut will round it (I used 0.51, 0.5 should also work but it's not for some reason)

[LeXXuz]

I have the impression the sharpening effekt is a little weaker in 10/16 but maybe my old eyes are just messing with me. :D

Will sharpening strength be about the same in HBD than in LBD?
Or should I use slightly higher values when filtering my videos in 10bit, compared to 8bit?

[real.finder]

I have the impression the sharpening effekt is a little weaker in 10/16 but maybe my old eyes are just messing with me. :D

Will sharpening strength be about the same in HBD than in LBD?
Or should I use slightly higher values when filtering my videos in 10bit, compared to 8bit?

it should be in same strength, and it also depends on how you display the HBD (like convert to 8bit at the end with dither or not, and in megui it just convert it to rgb24 for any bitdepth), but anyway the HBD outputs for most filters are not similar to 8bit in first place and that why this problem happened

[LeXXuz]

Okay, thanks again. :)

[WorBry]

edit: all old talk that was here moved to the 2nd post now

the porting is done https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/LSFmod.avsi

I've just tried to run the script and I'm getting "I don't know what AvsPlusVersionNumber means, LSFMod.avsi, line 433"

What to do? I'm running AviSynthPlus 3.6.1

Thanks.

[real.finder]

I've just tried to run the script and I'm getting "I don't know what AvsPlusVersionNumber means, LSFMod.avsi, line 433"

What to do? I'm running AviSynthPlus 3.6.1

Thanks.

you need this https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi

[WorBry]

OK thanks.

[WorBry]

So I've been (re)evaluating denoise and sharpening filter combinations for post processing of graded DaVinci Resolve exports - these are 1080/60p Cineform (Filmscan 2) avi files exported at 'Video Levels' but retaining super-white data. The original source material is 1080/60p HD-AVC.mp4 shot on a Canon HF-G40 camcorder in 'Wide DR' gamma mode. Anyone familiar with Wide DR on Canon cameras will know, the 'extended dynamic range', as perceived, comes at the expense of a softer image and increased levels of gain noise in the shadows. Adding back local contrast ('clarity', or 'Midtone Detail' in Resolve), coupled with light sharpening, offers the best prospect for 'enhancing' more detail. The sharpen/blur tool-set in Resolve is very good (IMO), but I'm using the free version and NR is only available in the Studio version. I'd consider the 'NeatVideo' OFX plugin but, AFAIK, that requires the Studio version also.

Hence, my reason for turning to AVISynth.

I've been getting very nice results with KNLMeans and LSFMod processed in 10bit 422 (p210) pipeline. Typical script, for Wide DR:

LWLibavVideoSource("{Path}:\Cineform_export.avi", fpsnum=60000, fpsden=1001,format="YUV422P10")
KNLMeansCL(h=1.2) #up to 1.5 for noisier scenes.
LSFMod(LSFMod(strength=110, defaults="slow")#ranging between 90 - 120.

I'm quite happy with the results as they stand but, if possible, I'd like to look at adding back noise after sharpening. Searching back through the forum I found this snippet from Didee:

https://forum.doom9.org/showthread.php?p=1651062#post1651062

source = whatever
filter = source.AnyDenoiserThatFitsTheSource()
sharpy = filter.YourSharpenerOfChoice()
result = source.mt_makediff(mt_makediff(filter,sharpy),U=2,V=2)

But I think the MaskTools expression would need to be updated for HBD processing - wouldn't it ? - and I'm not sure how to do that. Also how could it be modified to add back noise in varying degrees ?

Thanks.

[poisondeathray]

But I think the MaskTools expression would need to be updated for HBD processing - wouldn't it ? - and I'm not sure how to do that. Also how could it be modified to add back noise in measured degrees ?


Modern MaskTools2 for avs+ supports HBD and float for most functions. There is a chart in the readme
https://github.com/pinterf/masktools/releases

Merge can "merge" clips with weighting and supports HBD in avs+ .
http://avisynth.nl/index.php/Merge

[WorBry]

OK thanks. I'm not at my PC just now to try this, but just to be clear - I should be able to use that MakeDiff script for adding back noise as is, or do I need to add some operator for 10bit scaling ?

[poisondeathray]

OK thanks. I'm not at my PC just now to try this, but just to be clear - I should be able to use that MakeDiff script for adding back noise as is, or do I need to add some operator for 10bit scaling ?

You don't need anything for 10bit scaling, masktools works up to 16bits and some functions at float

That script is not "adding back noise" , it's applying sharpening to a denoised version

It might look something like this




source=last

#d is denoiser apply only

d = source.whateverdenoisers()

#ds is denoiser+sharpener

ds = d.whateversharpeners()

#result1 is add back to ds, the diff between denoised and source

result1=mt_adddiff(ds, mt_makediff(d,source),U=2,V=2)

#modulate strength of addback to ds from 0.0 to 1.0 .

merge(ds, result1, 0.5)

[WorBry]

That script is not "adding back noise" , it's applying sharpening to a denoised version

True, strictly it's by-passing noise - sharpening a denoised version and applying the difference between that and the denoised version (i.e. the denoised sharpening) to the original noisy version, so leaving the noise in (not adding it back).



source=last

#d is denoiser apply only

d = source.whateverdenoisers()

#ds is denoiser+sharpener

ds = d.whateversharpeners()

#result1 is add back to ds, the diff between denoised and source

result1=mt_adddiff(ds, mt_makediff(d,source),U=2,V=2)

#modulate strength of addback to ds from 0.0 to 1.0 .

merge(ds, result1, 0.5)


OK thanks, I'll give it a go.

Edit: Yes, that works. Thanks.

[Dogway]

Updated LSFmod to use internal Expr() and dropped avs 2.5 support. Runs faster on my tests. Still needs masktools2 for the convolutions.
https://github.com/Dogway/Avisynth-Scripts/blob/master/Mods/LSFmod.v2.192m.avsi

[real.finder]

Updated LSFmod to use internal Expr() and dropped avs 2.5 support. Runs faster on my tests. Still needs masktools2 for the convolutions.
https://github.com/Dogway/Avisynth-Scripts/blob/master/Mods/LSFmod.v2.192m.avsi

how much faster? masktools2 lut things can use internal Expr (use_expr) but yes pinterf said back then that using Expr directly will be faster but even so with most 8bit RPN lut still faster from my tests

[Reel.Deel]

Updated LSFmod to use internal Expr() and dropped avs 2.5 support. Runs faster on my tests. Still needs masktools2 for the convolutions.
https://github.com/Dogway/Avisynth-Scripts/blob/master/Mods/LSFmod.v2.192m.avsi

Thanks for the update Dogway. Death to AviSynth 2.5 :devil:

[Dogway]

Near 4% faster. The limiting factor here is the convolutions (mt_edge, mt_xxpand, mt_xxflate, etc). If VS convolution is ever ported probably the difference would be bigger. I kinda want to deprecate masktools2 but some functions are still needed.

CPU: i7-4790K (4C/8T)
2.192: 41.5fps
2.192m: 43fps

setmemorymax(2048)
DGSource("source.dgi") # 1080p

ConvertBits(16)
LSFmod(defaults="slow",strength=200,edgemode=0,soothe=true,ss_x=1.0,ss_y=1.0)

trim(7529,12601)
Prefetch(4)

@Reel.Deel: lol, yeah even me haven't found a reason to go back.

[real.finder]

yeah there are some functions need to be ported from vs like https://forum.doom9.org/showpost.php?p=1941761&postcount=318 and as you said VS convolution

anyway, you test with 16bit, did you tried with 8bit?

@Reel.Deel, Dogway also killed avs 2.6 :) and any old avs+ that don't has expr (that not as important as kill avs 2.6 :) anyway)

[Dogway]

Yes, box blur is a type a convolution filter, in that case one of variable size.

In 8-bit masktools2 seems faster. This was unexpected. I will test with simple calls if there's something else that can be done.

2.192: 97fps
2.192m: 67fps

[Reel.Deel]

@Reel.Deel, Dogway also killed avs 2.6 :) and any old avs+ that don't has expr (that not as important as kill avs 2.6 :) anyway)

Good, there is no reason to use classic AviSynth over AviSynth+ ... And if people don't want to update to the latest version, well, shame on them. Your script modifications would greatly benefit from you doing the same thing, they would be much cleaner without the hundreds of calls to "sisavs26", "isyuy2", etc. But hey, to each his own :)

[StainlessS]

And if people don't want to update to the latest version, well, shame on them.
No shame at all, personal choice, however so long as it runs on XP, I'm stickin' with + [although I feel myself quivering a bit on that XP thing].
Not sure, I think I did last Pole on Avisynth version usage [or maybe the penultimate one], maybe Reel.Deel
or one of the other NonPlus haters would hold a new pole, see how the land lies.
[surely nobody is still usin' 2.58].

[Dogway]

Good news I found how to use convolutions with Expr()

BoxBlur example, same as Blur(1.0) but faster:
removegrain(19)

BoxBlur with Expr(), slower by 10-15% than removegrain in either bitdepth, but still need to compare with masktools2.
Expr(last,"x[-1,-1] x[1,1] x[-1,0] x[1,0] x[0,1] x[0,-1] x[-1,1] x[1,-1] + + + + + + + 8 /")



EDIT: yep, Expr() is slower (no AVX2)
487fps
mt_edge(mode="sobel",thY1=0.0,thY2=0.0,thC1=0.0,thC2=0.0,chroma="-128")

353fps
Expr(last,"x[-2,0] x[-1,1] x[1,1] x[2,0] x[1,-1] x[-1,-1] + - - - + 2 ^ " \
+"x[-1,0] x[-1,1] x[0,2] x[1,1] x[1,-1] x[0,-2] x[-1,-1] + + + - - - 2 ^ * sqrt", "range_half")

[StainlessS]

DogWay

Avisource("D:\Parade.avi")
return Expr(last,"x[-1,-1] x[1,1] x[-1,0] x[1,0] x[0,1] x[0,-1] x[-1,1] x[1,-1] + + + + + + + 8 /") # Dogway

EDIT: Oops, I posted the mod above, instead of DogWay original, fixed.


AVSMeter 3.0.8.0 (x86), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.0 (r3382, 3.7, i386) (3.7.0.0)

Number of frames: 7373
Length (hh:mm:ss.ms): 00:04:06.012
Frame width: 488
Frame height: 360
Framerate: 29.970 (30000/1001)
Colorspace: YV12
Audio channels: 2
Audio bits/sample: 16
Audio sample rate: 44100
Audio samples: 10849148

Frames processed: 7373 (0 - 7372)
FPS (min | max | average): 204.1 | 343.6 | 307.6 # Dogways
Process memory usage (max): 39 MiB
Thread count: 9
CPU usage (average): 25.3%

Time (elapsed): 00:00:23.970


Mod (assuming that is in form [x,y]), then all Y-1, then all Y, then all Y+1. [& all left to right,instead of jumping all over the place]
EDIT: I presume that Expr() may be able to take shortcuts, if ordering is as expected in raster order.
EDIT: + possibly more CPU cache friendly.

Avisource("D:\Parade.avi")
return Expr(last,"x[-1,-1] x[0,-1] x[1,-1] x[-1,0] x[1,0] x[-1,1] x[0,1] x[1,1] + + + + + + + 8 /")



AVSMeter 3.0.8.0 (x86), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.0 (r3382, 3.7, i386) (3.7.0.0)

Number of frames: 7373
Length (hh:mm:ss.ms): 00:04:06.012
Frame width: 488
Frame height: 360
Framerate: 29.970 (30000/1001)
Colorspace: YV12
Audio channels: 2
Audio bits/sample: 16
Audio sample rate: 44100
Audio samples: 10849148

Frames processed: 7373 (0 - 7372)
FPS (min | max | average): 142.9 | 357.7 | 319.1 # Mod
Process memory usage (max): 37 MiB
Thread count: 9
CPU usage (average): 26.5%

Time (elapsed): 00:00:23.104


However, should this boxblur thingy not include the original pixel itself, and not just the ones surrounding it.
EDIT: I've no idea how boxblur works. [EDIT: Yes, boxblur should include the original pixel value too, ie 9 coords]

This below would seem to suggest the Blur(1), RemoveGrain(19) and the Expr thingy, aint the same at all.

Avisource("D:\Parade.avi")
#Greyscale
AMP=True

A= Blur(1)
B= removegrain(19)
C=Expr(last,"x[-1,-1] x[1,1] x[-1,0] x[1,0] x[0,1] x[0,-1] x[-1,1] x[1,-1] + + + + + + + 8 /") # Dogway
D=Expr(last,"x[-1,-1] x[0,-1] x[1,-1] x[-1,0] x[1,0] x[-1,1] x[0,1] x[1,1] + + + + + + + 8 /") # Mod
E=Expr(last,"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] + + + + + + + + 9 /") # Mod, 9 coords

P=ClipDelta(A,B,AMP) # blur(1), RemoveGrain(19)
Q=ClipDelta(A,C,AMP) # blur(1), Dogway
R=ClipDelta(A,E,AMP) # blur(1), 9 coords
S=ClipDelta(B,C,AMP) # RemoveGrain(19), Dogway
T=ClipDelta(B,E,AMP) # RemoveGrain(19), 9 coords
U=ClipDelta(C,D,AMP) # Dogway, Mod : The only one that is identical
V=ClipDelta(C,E,AMP) # Dogway, 9 coords
P
return Last

Function ClipDelta(clip clip1,clip clip2,bool "amp",bool "show") {
amp=Default(amp,false)
show=Default(show,false)
c2=clip1.levels(128-32,1.0,128+32,128-32,128+32).greyscale()
c1=clip1.subtract(clip2)
c1=(amp)?c1.levels(127,1.0,129,0,255):c1
return (show)?c1.Merge(c2):c1
}

EDIT: Above changed around a bit.

ClipDelta(amp=true) shows any difference at all as pretty much max.

[real.finder]

well I do keep avs25 for some reasons, like use it as a reference either for experimentation or for code, aside from satisfaction the simple or poor peoples that still use old things, also in my personal opinion, I prefer to maintain compatibility with older versions whenever possible (indeed they will not have all privileges), finally it's kinda fun to do this :P

[StainlessS]

Masochism is a hard habit to break :) [I know, I've been there, partly still am there]

[real.finder]

seems I will do another update since I got https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/UnsharpMask_avsi.avsi

the only missed HBD now is http://avisynth.nl/index.php/VariableBlur/Unsharp

here https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/LSFmod.avsi

[StainlessS]

seems I will do another update since I got https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/UnsharpMask_avsi.avsi


RF, thanks, above, too many avsi's.

[Dogway]

mt_convolution is very very slow, in this case I recommend using Expr() for over double the speed. Stepping is not actually the same as Expr() conv doesn't accept floats.

function UnsharpMask_HBD(clip clp, float "strength", int "radius", float "threshold")
{
str = Default(strength,64)
radius = Default(radius,3)
thres = Default(threshold,8)

rd = radius - 1
str = str/128.

blurclip = Expr(clp,Format("x[-{rd},-{rd}] x[0,-{rd}] x[{rd},-{rd}] x[-{rd},0] x[0,0] x[{rd},0] x[-{rd},{rd}] x[0,{rd}] x[{rd},{rd}] + + + + + + + + 9 /"))

sIsRGB=clp.IsRGB()
e = Format("x y - abs {thres} scalef > x y - {str} * x + x ?")
Expr(clp, blurclip, e, sIsRGB?e:"x") }

[StainlessS]

Concerning the timing of the 8 pixel coord convolution blur whotsit [which looked more like a de-dot thingy to me, missed out the original pixel],
Doggy changed to 9 coord Expr() convolution so including the missing pixel, looks like 9 coords was correct.
This also is correct, according to wikiPedia Boxblur:- https://en.wikipedia.org/wiki/Box_blur

and,
A number of optimizations can be applied when implementing the box blur of a radius r and N pixels:[6]

The box blur is a separable filter, so that only two 1D passes of averaging 2 r + 1 pixels will be needed, one horizontal and one vertical, for each pixel. This lowers the complexity from O(Nr2) to O(Nr). In digital signal processing terminology, each pass is a moving-average filter.

"Separable filter", so same kind of thing avisynth does with 2 * 1D resizer instead of 2D resizer.

So, I tried this

# boxblur,, 9 coords
Avisource("D:\Parade.avi")
Expr("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] + + + + + + + + 9 /")
Return Last


Now has 9 coords, so slightly slower than the previously timed 8 coord whotsit.

AVSMeter 3.0.8.0 (x86), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.0 (r3382, 3.7, i386) (3.7.0.0)

Number of frames: 7373
Length (hh:mm:ss.ms): 00:04:06.012
Frame width: 488
Frame height: 360
Framerate: 29.970 (30000/1001)
Colorspace: YV12
Audio channels: 2
Audio bits/sample: 16
Audio sample rate: 44100
Audio samples: 10849148

Frames processed: 7373 (0 - 7372)
FPS (min | max | average): 168.1 | 321.4 | 290.3
Process memory usage (max): 38 MiB
Thread count: 9
CPU usage (average): 25.7%

Time (elapsed): 00:00:25.395


2 * 1D [EDIT: or should it be horizontal(long side), then vertical(short side), I think there is mention of it somewhere about resizers]

# Vertical 3, then horizontal 3
Avisource("D:\Parade.avi")
Expr("x[0,-1] x[0,0] x[0,1] + + 3 /")
Expr("x[-1,0] x[0,0] x[1,0] + + 3 /")
return Last



AVSMeter 3.0.8.0 (x86), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.0 (r3382, 3.7, i386) (3.7.0.0)

Number of frames: 7373
Length (hh:mm:ss.ms): 00:04:06.012
Frame width: 488
Frame height: 360
Framerate: 29.970 (30000/1001)
Colorspace: YV12
Audio channels: 2
Audio bits/sample: 16
Audio sample rate: 44100
Audio samples: 10849148

Frames processed: 7373 (0 - 7372)
FPS (min | max | average): 237.4 | 466.8 | 406.5
Process memory usage (max): 38 MiB
Thread count: 9
CPU usage (average): 26.8%

Time (elapsed): 00:00:18.136

So a pretty fair speed improvement.
However, is not exaclty the same as 9 coord boxblur, probably due to being rounded to int in both vertical and horizontal filtering.
If you do a subtract of 9 coord Expr() thingy, and the 2 * 1D whotsit, it does not show any obvious difference,
and if put through ClipDelta(AMP=True) then the rounding differences look pretty much like random noise,
except in occasional areas of the original clip which were flat in color.

EDIT: Assuming that original 8 coord try at BoxBlur was actaully a DeDot thingy (is it)

# De-Dot
Avisource("D:\Parade.avi")
Expr("x[0,-1] x[0,1] + 2 /")
Expr("x[-1,0] x[1,0] + 2 /")
return Last

Do we have a HBD UnDot ? [if it is an undot/dedot, then maybe one for real.finder collection]

[Dogway]

Wow, pretty cool! Yes, I thought on shaving some speed with the 8 coords but was wrong.

I think here we might have a masktools2 killer. For me the speed improvement defeats the subtle change.
In any case I have yet to test in HBD.


Here is mt_expand(mode="both"), slower in any case:
Expr("x[0,0] x[0,-1] x[0,1] x[-1,0] x[1,0] + + + +","")

mt_inpand(mode="both")
Expr("x[0,0] x[0,-1] x[0,1] x[-1,0] x[1,0] min min min min","")


I'm going to create a library. EDIT: done, check here -> ExTools (https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi)

[kedautinh12]

new mod ver of dogway v2.193mod support > avs+ 2724
https://github.com/Dogway/Avisynth-Scripts/blob/master/Mods/LSFmod.v2.193m.avsi

[Boulder]

Do we have a HBD UnDot ? [if it is an undot/dedot, then maybe one for real.finder collection]

I believe RemoveGrain(1) is the same as Undot().

[Reel.Deel]

I believe RemoveGrain(1) is the same as Undot().

Indeed it is :)