Dogway's Filters Packs

[FTLOY]

Originally Posted by salvo00786

I don't know if I am wrong, but I downloaded the latest avisynth+ from your link and I overwrited the files in the staxrip directory with the files downloaded. But when I use SMDegrain, the same error appear.

You may have to modify the call a little bit..

pre=ex_Median(mode="IQMST")
SMDegrain(tr=6,thSAD=600,thSADC=300,contrasharp=true,prefilter=pre,refinemotion=true)

Might be an idea to also ask the question on the StaxRip thread...

[Dogway]

@salvo00786: Update ExTools and try again. IQMST was a last addition, even so it's already a few months ago.

[FTLOY]

Originally Posted by Dogway

@salvo00786: Update ExTools and try again. IQMST was a last addition, even so it's already a few months ago.

Does StaxRip use or support Extools ???

Just checked, it's under the "x\Apps\Plugins\AVS\Scripts\ExTools.avsi"

At least v10.0, but latest here, is v10.2

Hello,

is there any way to improve details retantion of this call and also remove more background grain?

pre=ex_Median(mode="IQMST", UV=3,thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_median("IQMV").ex_sbr(1,UV=3)

my_TR = 3 # 4/5 depends on the grain
my_thSAD = 400
my_thSCD1 = my_thSAD + 100
my_thSADC = my_thSAD - 100

SMDegrain(mode="TemporalSoften", tr=my_TR, thSAD=my_thSAD, thSADC=my_thSADC, thSCD1=my_thSCD1, thSCD2=110, Str=2.0, limits=false, refinemotion=true, prefilter=pre, chroma=true, plane=4, search=5, subpixel=3)

Originally Posted by FTLOY

Does StaxRip use or support Extools ???

Just checked, it's under the "x\Apps\Plugins\AVS\Scripts\ExTools.avsi"

At least v10.0, but latest here, is v10.2

i use Staxrip 2.18 and i aways import/load below:

import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\GradFun3plus.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\SMDegrain\SMDegrain.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3DCPU_AVS.dll")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3DCUDA_AVS.dll")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3D_VAggregate_AVS.dll")
loadplugin("E:\4k_encode\dgdecnv_244\DGDecodeNV.dll")
loadplugin("E:\4k_encode\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
loadplugin("E:\4k_Encode\neo_FFT3D_r11\x64\neo-fft3d.dll")
loadplugin("E:\4k_Encode\fmtconv-r30\win64\fmtconv.dll")
loadplugin("E:\4k_Encode\avs_libplacebo-1.1.4\x64\Release\avs_libplacebo.dll")
loadplugin("E:\4k_Encode\ClipClop_x86_x64_dll_v1-26_20181222\Avisynth+_x64\ClipClop_x64.dll")
loadplugin("E:\4k_Encode\DGHDRtoSDR_1.15\DGHDRtoSDR.dll")

and i do not have any problem with SMDegrain calls

[FTLOY]

Originally Posted by madey83

i use Staxrip 2.18

I don't use StaxRip, but hopefully this help salvo...

[StainlessS]

Madey83,

loadplugin("E:\4k_encode\dgdecnv_244\DGDecodeNV.dll")

DgDecNv currently on v247.
https://www.rationalqm.us/dgdecnv/binaries/

Not sure, I think versions about 244 could produce garbled frame if jumping about within the clip,
but if step back a dozen or so frames and then stepping forward frame by frame, did not produce garbled frame on the original bad one.
Have not noticed similar behaviour recently, so is maybe fixed in v247.

EDIT: Actually, Seems it was updated yesterday, is now v248.

Originally Posted by StainlessS

Madey83,

DgDecNv currently on v247.
https://www.rationalqm.us/dgdecnv/binaries/

Not sure, I think versions about 244 could produce garbled frame if jumping about within the clip,
but if step back a dozen or so frames and then stepping forward frame by frame, did not produce garbled frame on the original bad one.
Have not noticed similar behaviour recently, so is maybe fixed in v247.

EDIT: Actually, Seems it was updated yesterday, is now v248.

thx

[Dogway]

madey83: You are using very strong filters there, for instance IQMST paired with TemporalSoften. Without seeing your source this could be too much. Maybe use a milder prefilter and increase thSAD. Settings vary a lot from source to source.

Also there are updated versions of your plugins:

avs_libplacebo-1.2.0
BM3DCUDA_AVS-test10-cuda118
ClipClop_x86_x64_dll_v1-27_20210727

[salvo00786]

Hi... Thanks for all your replies. I tried with Staxrip 1.18 and I updated Extools, but the error is the same.

Originally Posted by Dogway

madey83: You are using very strong filters there, for instance IQMST paired with TemporalSoften. Without seeing your source this could be too much. Maybe use a milder prefilter and increase thSAD. Settings vary a lot from source to source.

Also there are updated versions of your plugins:

avs_libplacebo-1.2.0
BM3DCUDA_AVS-test10-cuda118
ClipClop_x86_x64_dll_v1-27_20210727

Hi Dogway,

my main problem is that i have not enough powerfull CPU on my PC, and i always try to get as much as possible clean picture (targeting bitrate between 2-3 Mbps for 1080p) with possible high details remain as possible and of course speed is important for me too. With above settings of SMDegrain + LSFplus + neo_f3kdb i got ~4 fps which is quite low in my opinion.

i have tried also below settings:

pre=STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced

my_TR = 3 # 4/5 depends on the grain
my_thSAD = 500
my_thSCD1 = my_thSAD + 100
my_thSADC = my_thSAD - 100

SMDegrain(mode="STWM", limit=255, UHDHalf=true, prefilter=pre, tr=my_TR, thSAD=my_thSAD, thSADC=my_thSADC, thSCD1=my_thSCD1, thSCD2=110, LFR=false, limits=false, DCTFlicker=false, refinemotion=true, search=5, subpixel=3)

but remove grain was not enough. Rising TR and thSAD did not remove grain more... only reduced speed of encode.

this is the picture example where i would like to get clean background but have remain as much as possible details on foreground

https://postimg.cc/tZpLdbf8

[DTL]

Typically to visibly remove more grain and got less MPEG output bitrate at fixed crf-value it is require to make much larger tr-value adjustments (like doubling of tr-value only make photon shot noise about sqrt(2) lower). So playing around tr of 3,4,5 may be not any visible (also doubling of tr typically make processing fps half lower). To make some more visible step in subtle degraining it is more benefitical to move from linear FIR-type filter (like in current 2.7.45 MDegrainX) to IIR-type (also non-linear) filter (like pmode=2 in post 2.7.45 builds and VSTTempSmooth my tech demo). The IIR-type filter can remember best block or sample value over tr-scope and continue output it (equal to frame-duplicate but at block or sample level) and make most MPEG-friendly frame sequence to encode.

FIR-type filter linear because of its math can not reach such samples stability over many frames with not very large tr-values. And residual very small samples non-stability over sequence of frames to encode still create very high 'noise bitrate' to MPEG encoder.

So it may be recommended to wait until new processing modes will be 'officially' released in mvtools/vsttempsmooth (or sample-based vsttempsmooth-like processing will be also integrated as additional mode into MDegrainN as planned depending on some algorithm like for blocks with too bad SAD/dismetrc and so like). Not waste time and CPU/power to use too outdated mvtools manalyse/degrain of about 1..2 decade old. Even with some scripting enchancements over very old and simple FIR-type linear degrain engine. Playing around very simple manalyse/mdegrain engine of 200x years design can not make degraining better and better each year with some 'prefiters' shuffling and simply increasing tr and thSAD. The old 2.7.45-mvtools based denoiser may reach its limits already at 201x years.
I hope if pinterf will have time in 202x years we may still see updated mvtools version 'stable' of post-2.7.45 version number with many new features added. So Dogway will make redesign of SMDegrain for better degrain performance.

I understand users like to make encodings today and not wait years and decades for next better version of software - but things become slower and slower now. After very powerful design of opensource software in 200x years users may be used to have more and more advanced software releases several time per year and now in 202x as most of opensource at current planet and current EU+US civilization is died already it may be only 1 new updated release per decade or even more rare.

[Dogway]

madey83: Update a sample clip so I can have a look. Typically this is a matter of configuring a nice prefilter. What CPU do you have? So I can compare to mine which isn't top notch either.

Originally Posted by Dogway

madey83: Update a sample clip so I can have a look. Typically this is a matter of configuring a nice prefilter. What CPU do you have? So I can compare to mine which isn't top notch either.

@Dogway

Regarding my CPU it is ashamed to admit by it is i7 10750h....

example:
https://mega.nz/file/8QgQSTbQ#Y2XXFl...3oSclOZDl1LoPs

this is my entire call which gives me bitrate ~3500 Kbps, and yes i know HDR/DV source should have DGHDRtoSDR but i can't properly find white point of my source and i think some colors are shifted/not match to the source. I will update this matter in next time, when i will see this...

edit:
ConvertBits(16)

deep_resize(1920,edge="Zopti1080")
MaxFALL=22 #check for DV/HDR white point

pre=DGHDRtoSDR(mode="pq",white=MaxFALL,gamma=1/2.4,tm=1.0).ex_Median(mode="IQMST", UV=3,thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_median("IQMV").ex_sbr(1,UV=3)

my_TR = 3 # 4/5 depends on the grain
my_thSAD = 400
my_thSCD1 = my_thSAD + 100
my_thSADC = my_thSAD - 100

SMDegrain(mode="MDegrain", tr=my_TR, thSAD=my_thSAD, thSADC=my_thSADC, thSCD1=my_thSCD1, thSCD2=110, Str=2.0, limits=false, refinemotion=true, prefilter=pre, chroma=true, plane=4, search=5, subpixel=3)
LSFplus(strength=50, preset="LSF", secure=true, Lmode=3, soft=-2, soothe=true, Smode=3, Smethod=3, Szrp=16, Spwr=4, SdmpLo=4, SdmpHi=48, overshoot=1, undershoot=1, Overshoot2=1, Undershoot2=1, keep=20, edgemode=0)
neo_f3kdb(preset="veryhigh/nograin", dynamic_grain=false, sample_mode=2,keep_tv_range=false,dither_algo=3,mt=false)
fmtc_bitdepth(bits=10, dmode=7)
Prefetch(10,12)


FYI: i'm newbie in avisynth filtering, so this is my level of understanding how to use it....

[LeXXuz]

Originally Posted by madey83

this is my entire call which gives me bitrate ~3500 Kbps, and

Well if you care to bound your encodes to a certain bitrate you may tweak your encoder settings instead of trying to denoise your sources too much.
You can't 'denoise' any source down to your desired bitrate without losing too much detail at some point.

Why not do 'some' denoising for better compression and opt for a 2-pass encode at ~3.5Mbit instead of CRF?

Hi LeXXuz,

If I would have enough powerful CPU then I would be possible to do 2 pass encode, but I don't have it and double the time for single episode it is to much for me. That's the reason why I prefer CRF with denoising + plus clean sharp picture is my preference...

[LeXXuz]

Originally Posted by DTL

So it may be recommended to wait until new processing modes will be 'officially' released in mvtools/vsttempsmooth (or sample-based vsttempsmooth-like processing will be also integrated as additional mode into MDegrainN as planned depending on some algorithm like for blocks with too bad SAD/dismetrc and so like). Not waste time and CPU/power to use too outdated mvtools manalyse/degrain of about 1..2 decade old. Even with some scripting enchancements over very old and simple FIR-type linear degrain engine. Playing around very simple manalyse/mdegrain engine of 200x years design can not make degraining better and better each year with some 'prefiters' shuffling and simply increasing tr and thSAD. The old 2.7.45-mvtools based denoiser may reach its limits already at 201x years.
I hope if pinterf will have time in 202x years we may still see updated mvtools version 'stable' of post-2.7.45 version number with many new features added. So Dogway will make redesign of SMDegrain for better degrain performance.

I understand users like to make encodings today and not wait years and decades for next better version of software - but things become slower and slower now. After very powerful design of opensource software in 200x years users may be used to have more and more advanced software releases several time per year and now in 202x as most of opensource at current planet and current EU+US civilization is died already it may be only 1 new updated release per decade or even more rare.

You know, you have a point there I think.
SMDegrain is an excellent script, but after many month and hundreds of tested configurations, it always came down to the very same conclusion that mvtools is the weak spot here and in its current state couldn't cut it to satisfy my needs and expectations of a high-class motion-based denoising workflow on more demanding sources.

I'm almost at the brink of saying I'd better buy more hard drives instead of wasting that money on energy cost for half-satisfying 'remastering' jobs of my collection which I may regret one day.

And here is the big problem I see for any future development. 20 years ago disc space was expensive and hard drive space even more. So lots of people were looking for smarter solutions to back up their content. Hence began a vast development in filters and codecs to reduce file sizes while maintaining or even improving quality. I've been here long enough and witnessed most of that evolution.

Today, storage space is cheap. Talking TB now instead of GB two decades ago. In the same time storage cost went down, energy cost went up constantly. Making video transcoding less and less attractive to many people. In my circle of friends I'm the only one left still caring about encoding efficiency and video filtering. All the other guys do is backing up their discs to their storage networks and be done with it.

And here I am, still wasting lots of money on a somewhat outdated 'profession' with results that don't even fully convince me in the end. Makes you think.

I do hope mvtools will get the updates one day it really needs to greatly improve motion-based denoising methods to a level that can satisfy ambitious quality expectations.
But like you said, we need the people that have the time and knowledge to code and implement those things. And these people get more rare every year.

Don't want to get this OT and like I said, Dogways script is excellent but it can only do as much as its core element. It's like having a Porsche with an old VW engine. Looking awesome at first glance but gets more unsatisfying the deeper you look into it.

[FTLOY]

Originally Posted by salvo00786

Hi... Thanks for all your replies. I tried with Staxrip 1.18 and I updated Extools, but the error is the same.

Have you tried StaxRip 2.19.0 ??

https://forum.doom9.org/showthread.p...31#post1987631

And did you try the script I suggested ??

https://forum.doom9.org/showthread.p...12#post1987812

[DTL]

Originally Posted by LeXXuz

And here I am, still wasting lots of money on a somewhat outdated 'profession' with results that don't even fully convince me in the end. Makes you think.

I do hope mvtools will get the updates one day it really needs to greatly improve motion-based denoising methods to a level that can satisfy ambitious quality expectations.
But like you said, we need the people that have the time and knowledge to code and implement those things. And these people get more rare every year.

If pinterf is currently have low time and busy with AVS core - the only known other good programmer is Asd-g with many AVS plugins supported and some supplementing with required SIMD/bitdepth and other features for today usage. May be open a petition to take mvtools after pinterf and add my partially implemented features to make bugfixed 'stable' build at least with most simple and usefull features added (of total current list about 40+ new features) ? Or may be even open crowdfanding project to collect some money to pay to good programmer to make new better build. After this the Dogway may make additional tests and finally update SMDegrain with new version of mvtools.

I tried to send request to Asd-g for maintaining mvtools versions after 2.7.45 of pinterf build with as most as possible of my additions and will wait for answer.

[kedautinh12]

Asd-g won't touch mvtools if Pinterf still development it