Dogway's Filters Packs

[StainlessS]

NotePad2[Florian Balmer] and NotePad3[Derick Payne], seem to be from different authors.
Also there is at least one more by same name (NotePad2) on sourceforge by Ikiki.

NotePad2[Florian Balmer]:- https://www.flos-freeware.ch/
NotePad3[Derick Payne]:- https://github.com/rizonesoft/Notepad3/releases
NotePad2[Ikiki]:- https://sourceforge.net/projects/notepad2/

EDIT: There dont seem to be a NotePad4, except on Android.

[Dogway]

I was using the notepad2-mod from XhmikosR here (https://github.com/XhmikosR/notepad2-mod/releases/tag/4.2.25.870). From 2013, guess it's time to update lol

[guest]

Wow, it's hard to keep up with all the mod's & revisions you're doing, "Dog"...I only updated some of these this morning... :)

[Dogway]

Most of the things are finished by now, just little things here and there. QTGMC is fine but can be improved further (on the long run) after I run some Zopti tests, same with SMDegrain, but the logic here is finished. I also plan to implement a temporal limiting mode to LSFMod to propagate into SMDegrain.
TransformsPack is in WIP, but ConvertFormat() works, I just left some chroma issue unfixed a few months ago and of course chroma placement which still haunts me.
I'm adding a few more sharpeners to SharpenersPack and finishing DeblockPack to upload soon.

I was having some issues matching fft3dfilter with FFT3DGPU with large sigma, I saw a post of someone matching both but I forgot where...

[kedautinh12]

About deblocking, i seen SmoothD2 and SmoothD2c still good but that support only yv12 and don't have HBD

[Dogway]

I include SmoothD2c but ultimately depends on SmoothD2 which is a plugin, so we are limited by that. I'm also porting SmoothDeblock, which is a bit of a nightmare, but I will go little by little. These kind of projects help me see what I'm missing in ExTools so I include them on the go to be able to port them easier.
I already ported Deblock_QED() gaining 29% of performance.

[kedautinh12]

About Deblock_QED(), autodeblock had this function and have more options to do: weakdeblock, mediumdeblock, strongdeblock, autodeblock
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/autodeblock2.avsi

[Dogway]

Looks a bit over-the-top, but I might include it at some point given it gives good results or I can optimize it more.
This is the list of deblocks, those marked as Script are subject to be included.

I'm also including some Didée's suggestions for MC deblocking like MCSoothe, SoothCL, etc, based on FFT3D, which I try to port to FFT3DGPU. Once this is done I upload while SmoothDeblock still in WIP.
### Included: ###
### Deblock_QED (+Deblock plugin) ###
### SmoothD2c (+SmoothD2 plugin) ###
### MSUDeCor (+MSU_Smart_Deblocking plugin) ###
### SmoothDeblock (Script) ###
### Other (not included): ###
### BlindPP("xxxx")(DCDecode) ###
### Deblock(DGDecode,MVTools) ###
### DeblockM ###
### vsDeblockPP7 ###
### MSUDeblock ###
### MSUSmartDeblocking ###
### SmoothD2 ###
### Unblock ###
### BlockTerminator (Script) ###
### BlockKiller (Script) ###
### FunkyDeblock (Script) ###

[kedautinh12]

I seen MSU filter but it's VirtualDub plugin and can't autoload in avs+

Edit: unblock only support avs x86. Where can i get deblockM??

[Dogway]

I think he meant MDeblock here (https://forum.doom9.org/showthread.php?p=913365). Yes, you need to manually load the MSU filter.
I think the best Deblock_QED contender might be SmoothDeblock but it uses old procedures for loop, arrays, etc, and while it might work fine today I want to refactor it entirely to modern syntax, so that will take me some time.

[kedautinh12]

I think he meant MDeblock here (https://forum.doom9.org/showthread.php?p=913365). Yes, you need to manually load the MSU filter.
I think the best Deblock_QED contender might be SmoothDeblock but it uses old procedures for loop, arrays, etc, and while it might work fine today I want to refactor it entirely to modern syntax, so that will take me some time.

Link dead and i got MDeblock but it's still only support x86 ver

[guest]

Hi Dogway,

Grabbed Sharpeners Pack v1.5 (19-09-2021), and I am now having an error @ Line 556 Col 8, if !(MC && isg) {

no issues with previous build.

[tormento]

Dogway's Filters Packs

Script error: expected `('
(D:/Programmi/Media/AviSynth+/plugins64/SharpenersPack-1.5~Dogway.avsi, line 556, column 8)

Edit: so fast you were. Working :)

[Dogway]

Yes, sorry I seem to make the stupidest mistakes, fixed now.

By the way, I'm currently porting Plum, so I will upload soon.
Also porting Oyster to DeblockPack, but lack of features in AVS BM3D makes it difficult if not impossible to replicate vs version.

[kedautinh12]

Yes, sorry I seem to make the stupidest mistakes, fixed now.

By the way, I'm currently porting Plum, so I will upload soon.
Also porting Oyster to DeblockPack, but lack of features in AVS BM3D makes it difficult if not impossible to replicate vs version.

Yeah WolframRhodium only fork a part of vs-BM3D of HolyWu

[Dogway]

Finally uploaded DeblockPack, a nightmare. Except for Deblock_QED() I wouldn't use the rest yet, specially SmoothDeblock() and Oyster. Oyster should be "working" (aside from the missing settings in BM3D) but it actually hangs avspmod, probably because of the absurd values...

[anton_foy]

I tried your version of Deblock_QED and got:

Script error: ex_lutspa does not have a named argument "expr" DeblockPack.avsi, line 113
Am I missing something?

[Dogway]

Update ExTools I guess.

[anton_foy]

Update ExTools I guess.

Sorry yes that fixed it, thank you.

[Dogway]

By the way, uploaded FrameRateConverter 2.0, rebased to v2.0 beta 11. Works great, possibly faster than vanilla in 8-bits, and nearly as fast in 16-bit. Updated benchs on OP.
I also observed that blending is reduced when processing in HBD.

[WolframRhodium]

Yeah WolframRhodium only fork a part of vs-BM3D of HolyWu

True. And the denoising strength of the two filters is different. I do not recommend replacing VS-BM3D with the CUDA version without careful tuning at this moment.

[kedautinh12]

@Dogway Vapoursynth now support back win7. You can compare result between vs and avs+ when you want port vs filters or scripts to avs+
https://forum.doom9.org/showthread.php?p=1952807#post1952807

[real.finder]

@Dogway Vapoursynth now support back win7. You can compare result between vs and avs+ when you want port vs filters or scripts to avs+
https://forum.doom9.org/showthread.php?p=1952807#post1952807

when I use vs for compare I use https://forum.doom9.org/showthread.php?t=175529

[Dogway]

@Dogway Vapoursynth now support back win7. You can compare result between vs and avs+ when you want port vs filters or scripts to avs+
https://forum.doom9.org/showthread.php?p=1952807#post1952807

Thanks, yes I have that pending. Actually I have many things pending (vs, notepad3, PC cleanup, emulators setup), but it will come useful for yugefunc, the problem is my computer is full to the brim, I need to delete things, and pytorch and these things take a good amount of space. So when I get time to do cleanup and finish the main avs+ ports I want to try it.
I'm interested on using vs for the neural network filters and enhance some old photos.

[Dogway]

I'm finishing porting Plum. Yeah, I'm having many issues due to memory overflow. Currently using a 1080p source.
nnedi3
Requested buffer size of 6417285120 is too large

nnedi3
Error while allocating planar dstPF

KNLMeansCL: fatal error!
(clCreateContext: CL_OUT_OF_RESOURCES)
(New File (30), line 93)

I don't know who to blame here, the plugins, avisynth... in any case I think overall the framework should be updated to deal fine with 8K clips, not necessarily for 8K sources but also ss 4K or 2K sources. I have 32Gb of RAM and 8Gb of VRAM.


Also having issues with, returns Undefined() when further processing, ok as final call:
Expr(clp, SelectEvery(src, {radius} * 2 + 1, {i}), ...(x13), "x y max z max a max b max c max d max e max f max g max h max i max j max")




EDIT: Uploaded Plum. Report back if you manage to get something out of it : P

[real.finder]

I'm having many issues due to memory overflow.
vs feisty2 functions are so slow that run Seconds per frame not frames per second, and he made them for dvd/SD masters not even for HD

[Dogway]

Yes I know. At last I tested with a resized down to 480p clip and it kept processing 15 minutes so I closed it. Even with my optimizations and relaxed down settings (pel=2) and todays computer standards compared to 2016 (8Gb VRAM, 32Gb RAM, CUDA, etc).

Will try at another time, I need to get an output to verify it works fine, apparently F2QSharp changed some settings in the meantime.


EDIT: Did some tests with SMDegrain, motion compensating ex_median() filtering. Result are comparable at least for tr=3 and thSAD=400
# SMDegrain MC:
# STWM 9.5fps P(6) rec=false 17
# ML3Dex 20fps P(6) rec=false 31
# medianST rec=false 25fps P(6)
# MDegrain 14fps P(6) (no MC, usual method)

[real.finder]

I still need to port LimitFilter (https://github.com/HomeOfVapourSynthEvolution/mvsfunc/blob/7948c8be129bc9cb282cf24e25b3c4b77328a9e0/mvsfunc.py#L1776)and SmoothGrad (https://github.com/WolframRhodium/muvsfunc/blob/80e99100c78b96b1c925a5989259ef22c1bc6173/muvsfunc.py#L1899).

function SmoothGradPlus(clip m, int "radius", float "thr", clip "ref", float "elast", int "Y", int "UV")
{
radius = Default(radius, 16)
Y = Default(Y, 3)
Y2 = Y==3 ? 3 : 1
UV = Default(UV, 3)
UV2 = UV==3 ? 3 : 1
smooth = ex_boxblur(m, radius-1, mode="mean", Y=Y2, UV=UV2)
slimit_dif(smooth, m, ref, thr, elast, Y=Y, U=UV, V=UV)
}

convertbits(16)
SmoothGradPlus
ConvertToStacked()
DitherPost()
luma_histogram() (https://github.com/realfinder/UniversalPluginsFolders/blob/master/plugins/luma_histogram.avsi)

vs

Dither_convert_8_to_16()
SmoothGrad
DitherPost()
luma_histogram()

show that they are about 99% same (they are same but the small difference come from ex_boxblur vs Dither_box_filter16 rounding errors or something), still, SmoothGradPlus can be shorten (and it will improve performance too) by make it only one line expr (by gathering only the parts that needed for SmoothGradPlus from slimit_dif and ex_boxblur)

[Dogway]

Great, interested on the numbers ( Prefetch(cores) works best with ex_boxblur() ), I know that Dither_box_filter16() is very fast but if we are in 200+fps territory I think it's fine (EDIT: oh no rad=16!), but using ConvertBits(8) instead.

I have been researching for some time how to speed up mean blur, one method is akin to ex_gaussianblur(), by resizing down+up, but what kernel? Well with fmtconv on avs+ now we can use the "box" kernel in HBD, so that's for downscale, I'm still unsure on what to use for upscale. Maybe some resampler guru can shed some light. What I found out today is that GaussResize(p=21) is the same as BicubicResize(b=1,c=0) (a perfect cubic spline?)

[kedautinh12]

vs feisty2 functions are so slow that run Seconds per frame not frames per second, and he made them for dvd/SD masters not even for HD

feisty2 said: "i only made my scripts with placebo speed"

[Dogway]

I could approximate a mean blur with "box" resize down, mean blur rad=2, resize up in softcubic. But then I thought, is there a reasoning for using mean blur and not other blur? If you observe mean blur in high radii it's far from ideal, like image doubling. So I went and used gaussian blur with some padding.

function SmoothGradPlus(clip m, int "radius", float "thr", clip "ref", float "elast", int "Y", int "UV")
{
radius = Default(radius, 16)
Y = Default(Y, 3)
Y2 = Y==3 ? 3 : 1
UV = Default(UV, 3)
UV2 = UV==3 ? 3 : 1
pad = ceil(radius)
m = sh_Padding(m, pad, pad, pad, pad)
smooth = ex_GaussianBlur(m, (radius-1)/1.5,Y=Y2, UV=UV2)
slimit_dif(smooth, m, ref, thr, elast, Y=Y, U=UV, V=UV)
crop(pad, pad, -pad, -pad)
}


EDIT: some benchs, 126fps, with optimized slimit_dif() 183fps, without padding 285fps. Maybe we can replace GaussResize() with a border aware resizer...

[real.finder]

is there a reasoning for using mean blur and not other blur?

to make it output similar to SmoothGrad, or it will no point of use it name and it better to use SmoothGrad2 instead of SmoothGradPlus, I make it Plus since it work only in avs+ and it give almost same output

edit: btw, vs port not give similar output (again (https://forum.doom9.org/showpost.php?p=1952785&postcount=410)), so likely we will see more posts like this (https://forum.doom9.org/showpost.php?p=1952619&postcount=403) and this (https://forum.doom9.org/showpost.php?p=1952784&postcount=409) which is bad since it kinda misinformation

[kedautinh12]

I think real.finder release SmoothGradPlus cause it's similar smoothgrad and dogway will release SmoothGrad2 cause it's different smoothgrad :D

[Dogway]

Making match something for the sake of it is just an unnecessary added burden, if it does what it says and does it well, who cares? I will try to roughly match the output but I will not be nitpicky about it.
I will call it ex_deband() in any case.

I'm now working with GaussResize cropping features to add and crop borders at the same time of resizing, it's tricky, resizing down is done, up is yet.

[real.finder]

Making match something for the sake of it is just an unnecessary added burden, if it does what it says and does it well, who cares?

aside from what I said before, it necessary in case of those dll filters used in another functions that maybe very sensitive to those changes, Especial if someone replace them without know they are not same in output

[guest]

Hard to keep up to all the changes & updates...

I got SMDegrainv3.3.1d today, and got an error, seems to be OK on one PC, but no the other, both are Ryzens, but one has nVidia GPU, the other has AMD.

If I recall, it was Line 498 (489).

But everything is SO SLOW when encoding 4K with these "strong" filters :(

[Dogway]

Can you be more precise? what is your SMDegrain call?
I have tested and everything seems to work, given you updated the other scripts (in case they are being used).

SMDegrain is the fastest UHD temporal denoiser because AFAIK is the only one that implements vector scaling.
You can speed it up further using another degrain mode like ML3DEx (limited to tr=1) or STWM (tr=2) or even temporalsoften.

Anyway most of the recent changes are features rather than bugfixes.

[guest]

Can you be more precise? what is your SMDegrain call?
I have tested and everything seems to work, given you updated the other scripts (in case they are being used).

SMDegrain is the fastest UHD temporal denoiser because AFAIK is the only one that implements vector scaling.
You can speed it up further using another degrain mode like ML3DEx (limited to tr=1) or STWM (tr=2) or even temporalsoften.

Anyway most of the recent changes are features rather than bugfixes.

Well, 3.3.0d worked fine, and 3.3.1d has quite a few more lines, that's about it for changes, I made to my script.

I'd certainly like to know how to use those "modes" you mentioned above...might have to have a look tomorrow.

Cheers

[Dogway]

3.3.1d has quite a few more lines

"More lines" doesn't mean "does more", by default SMDegrain works the same as before.

[tormento]

"More lines" doesn't mean "does more", by default SMDegrain works the same as before.
Please, please, please, update your filter documentation, SMDegrain mostly.

There are some switches that are not clear to me and others rather obscure. :p

[guest]

I think I'm going to have to go back to my older filters that did a real good job, and didn't take a LONG time....these filters might be way to complex, and trying to do too much, they're just slow. :(

Reasonable quality, but at good speed !!

[Dogway]

@Pauly Dunne: Funny when almost all my changes are biased for speed, check OP for benchmarks. By the way, you just duplicated the post in the HQMC thread. You have been advised before of such demanding attitudes. We are all here to help and nothing is given for granted. So thank what is given.

@tormento: Yes I have to, it's cumbersome but with the latest additions (limitS, mode, Str) it makes more sense. Before that I want to finish ex_vibrance() and skin_qualifier() for peace of mind.

[guest]

@Pauly Dunne: Funny when almost all my changes are biased for speed, check OP for benchmarks. By the way, you just duplicated the post in the HQMC thread. You have been advised before of such demanding attitudes. We are all here to help and nothing is given for granted. So thank what is given.

You're exactly right, Dogway...

https://forum.doom9.org/showthread.php?p=1952980#post1952980

[tormento]

Before that I want to finish ex_vibrance() and skin_qualifier() for peace of mind.

SMDegrain (tr=4, thSAD=400, refinemotion=true, contrasharp=false, PreFilter=5, plane=4, chroma=true)

Script error: the named argument "sigma" to BM3D_CUDA had the wrong type (passed an array to a non-array parameter)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.1d~Dogway.avsi, line 775)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.1d~Dogway.avsi, line 170)

No problems with prefilter=4.

[Dogway]

Yes, you have to update (https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/actions/runs/1215772307).

[tormento]

Yes, you have to update
I did not notice the update.

Thank you, it's working now.

[Dogway]

Just updated SMDegrain, LSFmod and SharpeningPack. All related to SMDegrain.
Ok, in lack of proper documentation for the time being I will brief the latest changes.

Recently there have been only three meaningful changes; denoiser mode, temporal-limiting sharpening, and ex_retinex.

ex_retinex: 'Str' is the argument that controls what kind of luminance optimization is performed. When set to 0, it only expands from TV range to PC range. When set to 1.0 or below uses ex_retinex() and over 1.0 to ex_luma_rebuild(). Default is 3.0, at this value not only a TV to PC range is performed but also some dark areas are brightened in a gentle manner. ex_retinex though uses the Multi-Scale Retinex algorithm, this is best suited for dark and/or low contrast sources and works better than ex_luma_rebuild(), since Retinex requires a range normalization the 'Str' defines the lower bound value, so when set to 0.40 it means that the retinex output will be normalized to PC range from value 40 to 255-lo/3. As always check the clip in 'show' mode to adjust values.

denoiser mode: I was developing TSMC script mod, and also having a glance to Didèe's LTSMC. When I realised, why take the whole SMDegrain to TSMC and not simply add the few lines to SMDegrain itself? So I did. Now you can use brute force denoising with all the features of SMDegrain like vector scaling, prefiltering, sharpening, etc. On the way I also had to auto activate a few switches so mode="TemporalSoften" really means "Degrain this shit out". It involved creating motion compensated frames and from there it was just a matter of including other denoisers I had created, so now you can use ex_median() temporal denoisers instead of MDegrain, some of them perform faster and with similar (better or worse) quality, just without scene change detection (should be handled by motion vectors). In today's update I included recursion mode, meaning it will denoise with past frames already denoised. It's a poor man's recursion so performance is like if called twice. Simply call like "rML3DEx" with an "r" preceding the denoiser name.

Temporal Limiting: There's not much to say about this. I reworked the temporal limiting in ex_contrasharpening(), and added it also to LSFmod, so by disabling spatial limiting with limitS=false you will enable temporal limiting. Depending on source it might work better or worse.

Some examples with the new features:

# Heavy grain denoising (mfilter to filter -blur here- where block matching was bad, aka action scenes, sudden movements). It needs a low pass recover pass that I will add in the future to avoid blending/motion blur effect.
smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=900,contrasharp=false,refinemotion=true)
smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=300,mfilter=ex_blur(1),contrasharp=true,refinemotion=true)

# Dealing with dark sources
smdegrain(tr=2,thSAD=300,Str=0.4,contrasharp=20,refinemotion=true)

# Using another denoiser and temporal limiting (MC frames directly fed to ex_contrasharpening() so saving a few CPU cycles)
smdegrain(tr=2,thSAD=300,mode="medianT5",contrasharp=true,limitS=false,refinemotion=true)

# Spatio Temporal denoising with recursion (STWM only uses a temporal radius of 2, so you won't see changes past tr=2)
smdegrain(tr=3,thSAD=300,mode="rSTWM",prefilter=5,contrasharp=true,refinemotion=true)

Main alternative denoisers:
Default: "MDegrain"
tr=1 -> "medianT" "MedianST", "ML3DEx"
tr=2 -> "medianT5", "STWM", "GaussT5"
tr<8 -> "TemporalSoften"

[guest]

I have a question before I take a break....

Do any of you ppl that are constantly improving & testing these filters & scripts, actually do any encoding with them ??

Like I mean a full length, 4K movie with your filters, just to see how they REALLY perform !!!

[tormento]

it only expands from TV range to PC range
Out of curiosity: what is the advantage to expand from TV to PC range if the majority of people will watch the movie on a TV set? Won't the expanded range be discarded by player/tv?

[Dogway]

@Pauly Dunne: Looks like you haven't updated LSFmod to 3.5mix, EX mod still needs to be updated to 3.5. Apparently you got bad timing because I didn't update any of my filters since 2015 and soon I will leave again. If you want to encode 4K you need to relax the settings, I'm sure you didn't live the times where filtering DVDs were at a rate of 0.5fps.

@Tormento: The range expansion is only for the motion vectors, not the denoising clip. Read from here (https://forum.doom9.org/showthread.php?p=1944794#post1944794).