real.finder's Avisynth Stuff

[real.finder]

also AKA A.SONY's Avisynth Stuff

I decided to open this Thread like what Groucho2004 did (http://forum.doom9.org/showthread.php?t=173259)

AudSub Splitter (http://forum.doom9.org/showthread.php?t=169961)
GUI for vfr.py and trimsubs

https://forum.doom9.org/showthread.php?p=1673913#post1673913 some moded macros for avsp

note:- Zs_RF_Shared.avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) (Shared Functions and utility V1.05 or up) is needed

note 2:- many scripts support native HBD now, some for few settings and some others for all settings depending on the used dll's in the function

update note: new scripts and updates will be on github from now on
https://github.com/realfinder/AVS-Stuff/tree/master

avs/avs+ Universal Plugins Folders (https://forum.doom9.org/showthread.php?t=181989)

SRFBob() (https://forum.doom9.org/showthread.php?t=186330)

SRFComb() and SRFComb2() (https://forum.doom9.org/showthread.php?t=186908)

PhosphorPersistence() (https://forum.doom9.org/showthread.php?t=186923)

daa3mod (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/daa3MOD.avsi)
daa with nnedi3 and ss (slow) method have less artifacts and less loss of details and others

dfttestMC and MC things (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/dfttestMC_and_MC_things.avsi)
my mod for dfttestmc

admfilter and edgesidebleed and others (Advanced Denoising.avsi) (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)
bob for anime, smam to clean up the bob Artifacts
admfilter is Adaptive motion denoise that use dfttestmc, the goal of it to get rational denoise in all cases (whether motions or not), and other functions

DDComb (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/DDComb.avsi)
I just did some edit in it

QTGMC (https://forum.doom9.org/showthread.php?t=174544)
edit to use YUY2 in avs 2.6 and others

NotSMDegrain (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/NotSMDegrain.avsi) my old SMDegrain mod

RemoveDirtMC_SE (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/RemoveDirtMC_SE.avsi)

stab3 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/Stab3.avsi)

AnimeIVTC 2 mod, bug fixed and more (http://forum.doom9.org/showthread.php?t=170364)

ASTDR DeRainbow (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/ASTDR.avsi)

chroma blend/bleed/halo fix (http://goo.gl/enjQaR)

DeHaloHmod (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/DeHaloH.avsi)

maa2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/maa2.avsi)

insertsign (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/insertsign.avsi)

aWarpSharp4xx (https://pastebin.com/qLkBTbiF)

eedi3_resize16 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/eedi3_resize16.avsi), ResizeX (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/ResizeX.avsi), edi_rpow2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/edi_rpow2.avsi) and IResize (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/IResize.avsi)

nnedi3_resize16 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/nnedi3_resize16.avsi)
nnedi3_resize16 speed up with nnedi3 for avs 2.6 especially with not yv12

MP_Pipeline (http://forum.doom9.org/showthread.php?p=1746479#post1746479)
not much edit, just support avs mt inside mpp block, my goal now is here https://github.com/SAPikachu/MP_Pipeline/issues/1

nnchromaupsubsampling (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/nnchromaupsubsampling.avsi)
NNEDI chroma upsubsampling

VHSHaloremover (https://pastebin.com/u3B4WFT2)

abcxyz (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Abcxyz_MT2.avsi)

DeHalo_alpha_MT2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/DeHalo_alpha_mt2.avsi)

BlindDeHalo3_mt2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/BlindDeHalo3_mt2.avsi)

Masked_DHA (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Masked_DHA.avsi)

FastLineDarken mod (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/FastLineDarkMOD2.avsi)

FineDehalo (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/FineDehalo.avsi)

srestore (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Srestore.avsi)

LSFmod (https://forum.doom9.org/showthread.php?t=174752)

BalanceBorders (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/BalanceBorders.avsi)

FixBlendIVTC (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/FixBlendIVTC.avsi)

DebilinearM (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/DebilinearM.avsi)

SeeSaw (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/seesaw.avsi)

Deblock_QED_MT2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Deblock_QED_MT2.avsi)

YAHRmods (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/YAHRmod.avsi)

F3KDB_s (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/F3KDB_s.avsi) (now with F3KDB_3_adg and F3KDB_3)

smaskmerge (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/smaskmerge.avsi)

GrainFactory3 (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/GrainFactory3.avsi)

GrainFactory3mod (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/GrainFactory3mod.avsi)

MCTDmod (https://pastebin.com/xuRuW787) this is modified so can put MCTemporalDenoise.avsi and MCTD.avsi together in auto-load folder

Hysteria.avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Hysteria.avsi)

FineSharp (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/FineSharp.avsi)

EdgeCleaner (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/EdgeCleaner.avsi)

HQDeringmod (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/HQDeringmod.avsi)

LUTDeCrawl (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/LUTDeCrawl.avsi)

LUTDeRainbow (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/LUTDeRainbow.avsi)

Spresso (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Spresso.avsi)

STpresso (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/STpresso.avsi)

MCTemporalDenoise (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/MCTemporalDenoise.avsi)

YLevels_mt (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/YLevels_mt.avsi)

oSmoothLevels (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/oSmoothLevels.avsi)

mToon (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/mToon.avsi)

unb_s.avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/unb_s.avsi) *.mp4 guy unbt (https://forum.doom9.org/showthread.php?p=1379930#post1379930)

GrainStabilizeMC (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/GrainStabilizeMC.avsi)

LRemoveDust (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/LRemoveDust.avsi)

DFMDeRainbow (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/DFMDeRainbow.avsi)

Santiag (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Santiag.avsi)

GradFun2DBmod (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/GradFun2DBmod.avsi) also has GradFun2DB3()

MCBob (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/MCBob.avsi)

Vinverse_avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Vinverse_avsi.avsi)

AutoDeblock2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AutoDeblock2.avsi)

LimitedSharpen2 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/LimitedSharpen2.avsi)

AutoBorderFiller (https://raw.githubusercontent.com/realfinder/AVS-Stuff/refs/heads/master/for%20AVSPlus/AutoBorderFiller.avsi)

chikuzen plugins that I edit/build https://forum.doom9.org/showpost.php?p=1798117&postcount=36

maki mod of DGIndex & DGMPGDec I build https://forum.doom9.org/showpost.php?p=1782576&postcount=15

...

aside from https://github.com/realfinder/AVS-Stuff/tree/Community , there maybe others in pastebin but I don't remember them now

[Sparktank]

Great stuff! What a nice collection.

[real.finder]

*** these OUTDATED now ***

new SMDegrain edit https://pastebin.com/4y4Zw2xG

now all KNLMeansCL workaround in SMDegrain_KNLMeansCL and support last KNLMeansCL

[real.finder]

new QTGMC edit to use SMDegrain_KNLMeansCL to process chroma too http://forum.doom9.org/showpost.php?p=1732845&postcount=2041

[real.finder]

did a lot of changed in SMDegrain last days, it should be faster in yv16 without lsb now (there was a bug that call SSE*Tools)

[ndjamena]

You're still referencing EdiMode and ChromaEdi from within QTGMC_ApplySourceMatch. Those variables are neither declared global nor are they passed to the QTGMC_ApplySourceMatch function, therefore SourceMatch will not work until those references are removed.

[real.finder]

You're still referencing EdiMode and ChromaEdi from within QTGMC_ApplySourceMatch. Those variables are neither declared global nor are they passed to the QTGMC_ApplySourceMatch function, therefore SourceMatch will not work until those references are removed.

I didn't get what you say, but I did nothing to original design of QTGMC, if you see a bug in it then explain it clearly where it is

[ndjamena]

http://pastebin.com/dS06e6p8

Line 1002


yv16match1Edi = EdiMode=="NNEDI2" || EdiMode=="NNEDI" || EdiMode=="EEDI3+NNEDI3" || EdiMode=="EEDI3" || EdiMode=="EEDI2" || EdiMode=="TDeint" || EdiMode=="cYadif" || EdiMode=="RepcYadif" || ChromaEdi=="cYadif"

That's INSIDE SourceMatch, where EdiMode and ChromaEdi aren't available.

[real.finder]

http://pastebin.com/dS06e6p8

Line 1002


yv16match1Edi = EdiMode=="NNEDI2" || EdiMode=="NNEDI" || EdiMode=="EEDI3+NNEDI3" || EdiMode=="EEDI3" || EdiMode=="EEDI2" || EdiMode=="TDeint" || EdiMode=="cYadif" || EdiMode=="RepcYadif" || ChromaEdi=="cYadif"

That's INSIDE SourceMatch, where EdiMode and ChromaEdi aren't available.

fix it, thanks for report

[ingoldie]

What is the difference between RemoveDirtMC and RemoveDirtMC_SE?

[real.finder]

What is the difference between RemoveDirtMC and RemoveDirtMC_SE?

see the posts here http://forum.doom9.org/showthread.php?t=145753&page=2

[StainlessS]

With many plugs, an S suffix, means Static ie no dll required, SSE means Pentium 4 +. (thats about it).

[real.finder]

new SMDegrain and DDComb edits

[Groucho2004]

With many plugs, an S suffix, means Static ie no dll required, SSE means Pentium 4 +. (thats about it).Methinks you misunderstood. The "_SE" in this case relates to GPU support. By the way, SSE means >= P3/Athlon XP.

[StainlessS]

Yes of course.

[yup]

Hi real.finder!
Thank You for Your effort.
I am try Your QTGMC script after Windows 10 Reset.
Script
AVISource("cap1.avi")
AssumeTFF()
#ConvertToYV16(interlaced=true)
QTGMC(Edithreads=1,dct=5)
prefetch(8)
VirtualDub 32 bit work fine, but VirtualDub 64 bit show only chroma (green black pattern).
Afer adding line ConvertToYV16(interlaced=true) problem gone.
My avsmeter log
C:\Video\AVSMeter246>avsmeter -avsinfo

AVSMeter 2.4.6 (x86) - Copyright (c) 2012-2016, Groucho2004

VersionString: AviSynth+ 0.1 (r2294, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\syswow64\AviSynth.dll
Avisynth.dll time stamp: 2016-10-26, 15:29:36 (UTC)
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


[CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins\avstp.dll [1.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins\dither.dll [n/a]

[CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll [2.7.9.22]
C:\Program Files (x86)\AviSynth+\plugins+\nnedi3.dll [0.9.4.32]
C:\Program Files (x86)\AviSynth+\plugins+\RgTools.dll [0.93.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [n/a]

C:\Video\AVSMeter246>avsmeter64 -avsinfo

AVSMeter 2.4.6 (x64) - Copyright (c) 2012-2016, Groucho2004

VersionString: AviSynth+ 0.1 (r2294, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-10-26, 15:06:10 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\avstp.dll [1.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins64\dither.dll [n/a]

[CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\masktools2.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins64+\mvtools2.dll [2.7.9.22]
C:\Program Files (x86)\AviSynth+\plugins64+\nnedi3.dll [0.9.4.32]
C:\Program Files (x86)\AviSynth+\plugins64+\RgTools.dll [0.93.0.0]
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll [n/a]

yup.

[real.finder]

Hi real.finder!
Thank You for Your effort.
I am try Your QTGMC script after Windows 10 Reset.
Script
AVISource("cap1.avi")
AssumeTFF()
#ConvertToYV16(interlaced=true)
QTGMC(Edithreads=1,dct=5)
prefetch(8)
VirtualDub 32 bit work fine, but VirtualDub 64 bit show only chroma (green black pattern).
Afer adding line ConvertToYV16(interlaced=true) problem gone.
My avsmeter log
C:\Video\AVSMeter246>avsmeter -avsinfo

AVSMeter 2.4.6 (x86) - Copyright (c) 2012-2016, Groucho2004

VersionString: AviSynth+ 0.1 (r2294, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\syswow64\AviSynth.dll
Avisynth.dll time stamp: 2016-10-26, 15:29:36 (UTC)
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


[CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins\avstp.dll [1.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins\dither.dll [n/a]

[CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll [2.7.9.22]
C:\Program Files (x86)\AviSynth+\plugins+\nnedi3.dll [0.9.4.32]
C:\Program Files (x86)\AviSynth+\plugins+\RgTools.dll [0.93.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [n/a]

C:\Video\AVSMeter246>avsmeter64 -avsinfo

AVSMeter 2.4.6 (x64) - Copyright (c) 2012-2016, Groucho2004

VersionString: AviSynth+ 0.1 (r2294, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-10-26, 15:06:10 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\avstp.dll [1.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins64\dither.dll [n/a]

[CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\masktools2.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins64+\mvtools2.dll [2.7.9.22]
C:\Program Files (x86)\AviSynth+\plugins64+\nnedi3.dll [0.9.4.32]
C:\Program Files (x86)\AviSynth+\plugins64+\RgTools.dll [0.93.0.0]
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [n/a]
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll [n/a]

yup.

yes, I see it, it's bug in jpsdr nnedi3 with yuy2
ColorBars(width=640, height=480, pixel_type="yuy2")
nnedi3
will show same bug

and if you use this http://www.dropbox.com/s/fovpn5z9jy4goft/nnedi3_0.9.4_x64.zip?dl=1 will work fine but this 2.5 one (just yv12 and yuy2 and rgb)

[real.finder]

added aWarpSharp4xx with new Feature aWarp4 bool (should make the output quality better)

added insertsign with new Features like deal with HD and UHD automatically and if the source is RGBA (Packed) then it will use layer instead of overlay for speed and not lost original alpha

[real.finder]

Happy New Year :)

new QTGMC and sanimebob

try with sanimebob(8) and enjoy

[Izuchi]

I'm getting the following error message: I don't know what "merge 16" means. Can you confirm that it should be shift16 instead?

# Threshold Merging & Output

enable ? \
Eval("""
merge16 = !nnt ? flat16
\ : mixed ? Dither_limit_dif16(flat16, edge16, thr=thr, elast=elast, y=Ynn, u=Unn, v=Vnn)
\ : Ynnt==Unnt && Unnt==Vnnt || IsY8 ? edge16
\ : mt_lutxy(edge16, flat16, Y=Yt?Ynnt?2:4:1, U=Ut?Unnt?2:4:1, V=Vt?Vnnt?2:4:1)
merge16 = IsY8 ? output=="Y8" ? merge16.ConvertToY8() : Eval("merge16.ConvertTo"+oCSP).Dither_lut16(Y=2, U=-32768, V=-32768) : merge16

final = IsRGB ? merge16.Dither_convert_yuv_to_rgb(matrix=matrix, tv_range=tv_range, lsb_in=True, mode=dither, output=output)
\ : lsb ? merge16
\ : merge16.nnedi3_resize16_Down8(tv_range, True, !IsY8, !IsY8, dither)
""") : \
Eval("""
shift16 = input16.Dither_resize16(ow, oh, src_left, src_top, src_width, src_height, kernel="point", y=Y, u=U, v=V)
shift16 = IsY8 ? output=="Y8" ? merge16.ConvertToY8() : Eval("shift16.ConvertTo"+oCSP).Dither_lut16(Y=2, U=-32768, V=-32768) : shift16

final = IsRGB ? shift16.Dither_convert_yuv_to_rgb(matrix=matrix, tv_range=tv_range, lsb_in=True, mode=dither, output=output)
\ : lsb ? shift16
\ : shift16.nnedi3_resize16_Down8(tv_range, True, !IsY8, !IsY8, dither)
""")


return final
}

[real.finder]

I'm getting the following error message: I don't know what "merge 16" means. Can you confirm that it should be shift16 instead?

# Threshold Merging & Output

enable ? \
Eval("""
merge16 = !nnt ? flat16
\ : mixed ? Dither_limit_dif16(flat16, edge16, thr=thr, elast=elast, y=Ynn, u=Unn, v=Vnn)
\ : Ynnt==Unnt && Unnt==Vnnt || IsY8 ? edge16
\ : mt_lutxy(edge16, flat16, Y=Yt?Ynnt?2:4:1, U=Ut?Unnt?2:4:1, V=Vt?Vnnt?2:4:1)
merge16 = IsY8 ? output=="Y8" ? merge16.ConvertToY8() : Eval("merge16.ConvertTo"+oCSP).Dither_lut16(Y=2, U=-32768, V=-32768) : merge16

final = IsRGB ? merge16.Dither_convert_yuv_to_rgb(matrix=matrix, tv_range=tv_range, lsb_in=True, mode=dither, output=output)
\ : lsb ? merge16
\ : merge16.nnedi3_resize16_Down8(tv_range, True, !IsY8, !IsY8, dither)
""") : \
Eval("""
shift16 = input16.Dither_resize16(ow, oh, src_left, src_top, src_width, src_height, kernel="point", y=Y, u=U, v=V)
shift16 = IsY8 ? output=="Y8" ? merge16.ConvertToY8() : Eval("shift16.ConvertTo"+oCSP).Dither_lut16(Y=2, U=-32768, V=-32768) : shift16

final = IsRGB ? shift16.Dither_convert_yuv_to_rgb(matrix=matrix, tv_range=tv_range, lsb_in=True, mode=dither, output=output)
\ : lsb ? shift16
\ : shift16.nnedi3_resize16_Down8(tv_range, True, !IsY8, !IsY8, dither)
""")


return final
}

in what function? and the settings?

[Izuchi]

Sorry, it's in the nnedi3_resize16 function.

# 1920x1080 input
Dither_convert_8_to_16()
nnedi3_resize16(lsb_in=true, lsb=true, output="RGB48Y")
nnedi3_resize16(1920, 1080, lsb_in=True, lsb=True, Y=3, U=1, V=1)
Dither_convert_rgb_to_yuv(SelectEvery(3, 0), SelectEvery(3, 1), SelectEvery(3, 2), lsb=True, output="YV24")
DitherPost()

[real.finder]

Sorry, it's in the nnedi3_resize16 function.

# 1920x1080 input
Dither_convert_8_to_16()
nnedi3_resize16(lsb_in=true, lsb=true, output="RGB48Y")
nnedi3_resize16(1920, 1080, lsb_in=True, lsb=True, Y=3, U=1, V=1)
Dither_convert_rgb_to_yuv(SelectEvery(3, 0), SelectEvery(3, 1), SelectEvery(3, 2), lsb=True, output="YV24")
DitherPost()


fixed it, thanks for report

[ndjamena]

# Get maximum temporal radius needed
maxTR = (temporalSL) ? SLRad : 0
maxTR = (MatchTR2 > maxTR) ? MatchTR2 : maxTR
maxTR = (TR1 > maxTR) ? TR1 : maxTR
maxTR = (TR2 > maxTR) ? TR2 : maxTR
maxTR = (NoiseTR > maxTR) ? NoiseTR : maxTR
maxTR = (ProgSADMask > 0.0 || StabilizeNoise || ShutterBlur > 0) ? (maxTR > 1 ? maxTR : 1) : maxTR
maxTR = (ForceTR > MaxTR) ? ForceTR : maxTR


Just curious if this mess in QTGMC is actually necessary given that there's always been a max function in AVISynth.

I'm pretty sure a line or two of consisting of max() would be easier to read and this just makes the script look more complicated than it actually is.

[real.finder]

# Get maximum temporal radius needed
maxTR = (temporalSL) ? SLRad : 0
maxTR = (MatchTR2 > maxTR) ? MatchTR2 : maxTR
maxTR = (TR1 > maxTR) ? TR1 : maxTR
maxTR = (TR2 > maxTR) ? TR2 : maxTR
maxTR = (NoiseTR > maxTR) ? NoiseTR : maxTR
maxTR = (ProgSADMask > 0.0 || StabilizeNoise || ShutterBlur > 0) ? (maxTR > 1 ? maxTR : 1) : maxTR
maxTR = (ForceTR > MaxTR) ? ForceTR : maxTR


Just curious if this mess in QTGMC is actually necessary given that there's always been a max function in AVISynth.

I'm pretty sure a line or two of consisting of max() would be easier to read and this just makes the script look more complicated than it actually is.

I will check it later (when there is a bug or really needed change)

[real.finder]

added DeHalo_alpha and others

DeHalo_alpha now in avs 2.6 is faster and it's rad can be set more flexible (cuz it's done in Y8 with no mod4 or mod8 etc... resize limit)

[hydra3333]

Great stuff! What a nice collection.

and ... +1

[real.finder]

new update for admfilter and RemoveDirtMC_SE

[ChaosKing]

Will you push all of your filters/scripts to github?

[real.finder]

Will you push all of your filters/scripts to github?

maybe

[mp3dom]

Using AVS+, in SMDegrain, having stacked 16bit 422 YV16 as a source, I have the following error only when contrasharp=true

StackVertical: Image formats don't match

at line 541

lsb_out ? StackVertical (last, BlankClip (last, pixel_type=type, color_yuv=0,length=1)) : last""")}

[real.finder]

Using AVS+, in SMDegrain, having stacked 16bit 422 YV16 as a source, I have the following error only when contrasharp=true

StackVertical: Image formats don't match

at line 541

lsb_out ? StackVertical (last, BlankClip (last, pixel_type=type, color_yuv=0,length=1)) : last""")}


fixed

[mp3dom]

Many thanks!

[real.finder]

new dehalo edit and other added and updated

[real.finder]

nnchromaupsubsampling() now work with more than 8 bit in avs+

[real.finder]

I build some plugins of chikuzen since he/she absent from the scene

TCannyMod and CombMask 32 bit plugins work with xp unlike original chikuzen plugins

yadifmod2 already work in xp but this one is work with new colour format in avs+ (chikuzen update the source in github but didn't make new release)
edit: my yadifmod2 build is useless since the HBD code is buggy, also the x64 one seems avx one

edit: there are another update for this https://forum.doom9.org/showthread.php?p=1821422#post1821422

[real.finder]

DeHalo_alpha now work with all new avs+ bit depth, big thanks to pinterf, new updates for other dehalos maybe silently come very soon (maybe after some hours from now or next days)

[ingoldie]

Does anybody know how to fix the "RemoveGrain: only planar color spaces are supported" error for BlindDeHalo3_mt2?

[real.finder]

Does anybody know how to fix the "RemoveGrain: only planar color spaces are supported" error for BlindDeHalo3_mt2?

make sure you use last RgTools

I did port BlindDeHalo3 now to work in all new bit depth, VHSHaloremover is already done but waiting for new avs+ release, abcxyz is done from yesterday

[real.finder]

The situation for support new format in avs+ now is:

* new Masked_DHA and BlindDeHalo3 update to make them accept float in all possible parameters (it will be more accurate especially with high bit)

* SMDegrain now work with 10-16 bit in default settings

* edgesidebleed() now work with all new bit depth

[pinterf]

VHSHaloremover is already done but waiting for new avs+ release
Just to make sure, what function or fix is needed?

[real.finder]

Just to make sure, what function or fix is needed?

you forget? it's merge in float, you give me fixed build but I am wait for public build

[pinterf]

O.k. I thought that I had promised something else for example IsVideoFloat. So expect it possibly on the next week.

[real.finder]

edit for ResizeX and edi_rpow2, to support YUVA and HBD

[magiblot]

I'm using sanimebob on a NTSC clip with YUY2 colorspace:

AVISource(...) #Lagarith YUY2 source
sanimebob(1)

http://i.imgur.com/wJNZvxX.png

http://i.imgur.com/TKqwB1A.png

I have the following plugin versions:


sanimebob: Advanced Denoising and anime bob v1.42
tmm2: last Github release (0.1.1)
MaskTools2: last Github release (2.2.4) #edit: now 2.2.5
QTGMC: 3.355 #edit: updated to 3.357
AnimeIVTC: v2.20 2017-02-09 mod
SMDegrain: 3.1.2.90s #edit: updated to 92s


Changing sanimebob's parameters doesn't solve it (even with useqtgmc = 0).

Do I lack some update or is it a bug?

Here is a video sample:
https://mega.nz/#!NlRwmRZJ!xpG2E6wRKLV8hbtNyo-7zA-zivd6_ArCbDOOP0FsAPQ

By the way, is there any detailed explanation of what sanimebob's parameters do?

Thanks a lot for developing all those functions!

[mp3dom]

Tmm2 only supports planar colorspace, so no native YUY2.
Try to replace tmm2 with the old tmm1, or convert to YV16 at the beginning (assuming that both sanimebob and animeivtc can work with planar yv16 to begin with).

[real.finder]

Tmm2 only supports planar colorspace, so no native YUY2.
Try to replace tmm2 with the old tmm1, or convert to YV16 at the beginning (assuming that both sanimebob and animeivtc can work with planar yv16 to begin with).

you can't use yv16 now cuz not all plugins support it yet

and yuy2 should work cuz I did some code to convert to yv16 and back to yuy2 for these cases, I am checking now

[real.finder]

I'm using sanimebob on a NTSC clip with YUY2 colorspace:

sanimebob(1)

http://i.imgur.com/wJNZvxX.png

http://i.imgur.com/TKqwB1A.png

I have the following plugin versions:


sanimebob: Advanced Denoising and anime bob v1.42
tmm2: last Github release (0.1.1)
MaskTools2: last Github release (2.2.4)
QTGMC: 3.355
AnimeIVTC: v2.00 2017-02-09 mod
SMDegrain: 3.1.2.90s


Changing sanimebob's parameters doesn't solve it (even with useqtgmc = 0).

Do I lack some update or is it a bug?

Here is a video sample:
https://mega.nz/#!NlRwmRZJ!xpG2E6wRKLV8hbtNyo-7zA-zivd6_ArCbDOOP0FsAPQ

By the way, is there any detailed explanation of what sanimebob's parameters do?

Thanks a lot for developing all those functions!

can't reproduce, are you sure you using it with yuy2 not yv16? what source function you use? ffms2? or AVISource?

about sanimebob's parameters

useQTGMC:- not need for explain, it's clear, 0 will not use QTGMC at all

bobpresmooth:- will did some smooth for make the output more stable

Str, Amp, TV_range:- see SMDegrain

usedaa3mod, usesmam:- not need for explain, they clear

tr2:- see QTGMC

[real.finder]

update to masktools 2.2.5 done for many functions in 1st post

[magiblot]

I use AVISource to import the clip.
Maybe it's related to the AviSynth version I use. What's your AviSynth version? I'll try updating when I get back home.
Thanks for the parameter explanation. What does useQTGMC do for values bigger than 1?

[real.finder]

I use AVISource to import the clip.
Maybe it's related to the AviSynth version I use. What's your AviSynth version? I'll try updating when I get back home.


I don't use a specific version, most of times I change the avs in mpp by load it's dll in it, but my test done with 2.61 in xp and last 2.6 by set in windows server 2008 r2

Thanks for the parameter explanation. What does useQTGMC do for values bigger than 1?

it will be used in some settings that should be work with anime and so, take a look at the function code for more informations

[magiblot]

Indeed, updating Avisynth fixed the problem (I was stuck at an old AVS+ release that came with installer). I'm using now last version of AVS+ from Groucho's version switcher.
However, output colorspace is YV16, according to AvsPmod. Is that expected to happen?

AviSource(..) #Lagarith NTSC interlaced YUY2 source, VHS capture through composite video cable
sanimebob(1, usedaa3mod=true)

EDIT: Well, it's not fixed completely... the bottom half of the video still has some problems. It's hard to see them now (you need to zoom in a lot), but they are definitely there (this doesn't happen if converting to YV12 (with interlaced=true) before calling sanimebob).

http://i.imgur.com/QH3HM3N.png

http://i.imgur.com/Y9X5cql.png

I will upload more video samples later which contain the parts where I'm spotting these errors.

1: Uncompressed YV16 video with the error (first snapshot) -
https://mega.nz/#!Ux4y1Crb!0snYEr4xKE2Tve5DeTnnj5Ua_ckaR5CQVZwxuzR_lMI

2: Same cutscene but it's a direct stream copy of the original -
https://mega.nz/#!tkJA0DRA!1EhiKyEO7QvF0XdAJxmMaDpSzw14Opy40y7kw1Jv__Y

[real.finder]

Indeed, updating Avisynth fixed the problem (I was stuck at an old AVS+ release that came with installer). I'm using now last version of AVS+ from Groucho's version switcher.
However, output colorspace is YV16, according to AvsPmod. Is that expected to happen?

AviSource(..) #Lagarith NTSC interlaced YUY2 source, VHS capture through composite video cable
sanimebob(1, usedaa3mod=true)

EDIT: Well, it's not fixed completely... the bottom half of the video still has some problems. It's hard to see them now (you need to zoom in a lot), but they are definitely there (this doesn't happen if converting to YV12 (with interlaced=true) before calling sanimebob).

http://i.imgur.com/QH3HM3N.png

http://i.imgur.com/Y9X5cql.png

I will upload more video samples later which contain the parts where I'm spotting these errors.

1: Uncompressed YV16 video with the error (first snapshot) -
https://mega.nz/#!Ux4y1Crb!0snYEr4xKE2Tve5DeTnnj5Ua_ckaR5CQVZwxuzR_lMI

2: Same cutscene but it's a direct stream copy of the original -
https://mega.nz/#!tkJA0DRA!1EhiKyEO7QvF0XdAJxmMaDpSzw14Opy40y7kw1Jv__Y

make sure the output from AVISource is YUY2 not yv16, if it yv16 then convert it to YUY2

[magiblot]

make sure the output from AVISource is YUY2 not yv16, if it yv16 then convert it to YUY2
Indeed:

http://i.imgur.com/deFVwBO.png

[real.finder]

Indeed:

http://i.imgur.com/deFVwBO.png

weird, it's work fine here (xp and windows server 2008 r2) and the output is YUY2

make sure that you use last Animeivtc (2.20 or up) script and last days I did update many scripts for masktools 2.2.5 and up

[magiblot]

Ok, I'll try with AviSynth 2.6 later.

[real.finder]

Ok, I'll try with AviSynth 2.6 later.

it work fine in last avs+ in both xp and windows server 2008 r2, see my edit in previous post

[magiblot]

make sure that you use last Animeivtc (2.20 or up) script and last days I did update many scripts for masktools 2.2.5 and up

Yes, I have everything up to date https://o1.t26.net/img/emoticons/5.gif, however I might not face the problem anymore since I have been able to match the fields manually.

Actually, the video source seems to have a 3:2 pulldown. However, none of the IVTC filters I tried could match the fields properly (TFM, AnimeIVTC(mode=1)). Then I decided to bob, but for some reason srestore wasn't working either.

After that, I detected the frame repeating pattern and decimated the frames from the bobbed clip myself, with a simple SelectEvery call.

However, I realised that I could just match the fields directly from the original clip, instead of bobbing and discarding frames. So, I was able to do it with the following pattern:

AviSource(..) #Lagarith NTSC interlaced YUY2 source, VHS capture through composite video cable
trim(..) #Discards initial frames that don't belong to the animation with 3:2 pulldown
SeparateFields()
separated = last

f0 = separated.selectevery(10,0,1).Weave()
f1 = separated.selectevery(10,2,3).Weave()
f2 = separated.selectevery(10,4,5).Weave()
f3 = separated.selectevery(10,6,9).Weave() #"fields" 7 and 8 don't form an actual frame

Interleave(f0,f1,f2,f3)
daa3mod() #this is necessary because the source comes from VHS and is very unstable


I will upload a longer sample of my source in case you are interested in testing your IVTC functions with it.

EDIT: https://drive.google.com/file/d/0B8YfT7N-cAzCYkl0UUdtdmM4TjA/view?usp=sharing - lossy sample (x264 CRF 18 because the original lossless is too big for sharing)

Also, I have now other difficulties which are not related to this thread, so I'm opening a new one for that.

[real.finder]

maybe you have two .avsi for animeivtc in autoload folder, one old and one not

and you say 2.00 and it 2.20

anyway, I will see the sample now

[hello_hello]

magiblot appears to be using SMDegrain 3.1.2.90s which appears to be quite broken. Would that be causing the problem?

Version 3.1.2.90s was producing some sort of weird frame blended for me (progressive source) until I upgraded to version 3.1.2.92s, or downgraded to version 3.1.2.87s again.

[tcope]

Any chance on some usage doc's for
your version of FineDehalo ?

The default version has been providing
promising results at removing extreme
ringing in odd areas, while retaining detail
on HD footage. Though I am only working
in yv12 space, am eager to see how your
version may do.

[magiblot]

magiblot appears to be using SMDegrain 3.1.2.90s which appears to be quite broken. Would that be causing the problem?
No, I already updated it, but I haven't edited my old post.

maybe you have two .avsi for animeivtc in autoload folder, one old and one notand you say 2.00 and it 2.20anyway, I will see the sample now
Don't worry, that was just a mistake. What I do have is an "AnimeIVTC_helper" avsi, but maybe it is no loger necessary.

[real.finder]

Any chance on some usage doc's for
your version of FineDehalo ?

The default version has been providing
promising results at removing extreme
ringing in odd areas, while retaining detail
on HD footage. Though I am only working
in yv12 space, am eager to see how your
version may do.

the original FineDehalo don't has doc too

anyway, my edit to make more control of it, made mask function to use the mask for another things or using external Dehalo or mask in FineDehalo or whatever, and support HBD in avs+

and other functions included for masking

[tcope]

I am guessing the default legacy options still
apply.
FineDehalo (http://www.avisynth.nl/index.php/FineDehalo)

I look forward to exploring the added features.
Cheers :)

[real.finder]

I am guessing the default legacy options still
apply.
FineDehalo (http://www.avisynth.nl/index.php/FineDehalo)

I look forward to exploring the added features.
Cheers :)

yes, but that doc not by Author

maybe later I will explain the new things

and btw even if you work with yv12 source, you can convert it to more than 8 bit and filter it and then back to 8 bit, with this you will get getter result, Especially if you use many filters

[tcope]

and btw even if you work with yv12 source, you can convert it to more than 8 bit and filter it and then back to 8 bit, with this you will get getter result, Especially if you use many filters


Very good to know. May give colour space conversion
a try as well.

Thank You :)

[real.finder]

new SMDegrain edit to use last KNLMeansCL (v1.1.0) https://forum.doom9.org/showthread.php?p=1790702#post1790702

[Dreamland]

Thx..works perfectly!

[Heaud]

Using dfttestmc with mdg=true gives an error stating that there is no function named DarkPreserve_function. Am I missing something? Using Avisynth 2.6 with dither tools, dfttest, and MVTools.

[real.finder]

Using dfttestmc with mdg=true gives an error stating that there is no function named DarkPreserve_function. Am I missing something? Using Avisynth 2.6 with dither tools, dfttest, and MVTools.

yes, Advanced Denoising (the one that has sanimebob and smam)

or you can set mdg_domask=false

[Heaud]

Ported the function found here (https://pastebin.com/wZc8W13u) into dfttestmc and the setting now works! Thank you for letting me know where to get a copy.

[hello_hello]

real.finder,

Unless I'm going blind, your mod of SRestore appears to be missing from your collection of Avisynth stuff. I eventually found a link to it here (https://forum.doom9.org/showthread.php?p=1802514#post1802514), so I guess that's where I got it originally, but I just thought I'd let you know in case you want to add it to the collection.

Cheers.

[real.finder]

real.finder,

Unless I'm going blind, your mod of SRestore appears to be missing from your collection of Avisynth stuff. I eventually found a link to it here (https://forum.doom9.org/showthread.php?p=1802514#post1802514), so I guess that's where I got it originally, but I just thought I'd let you know in case you want to add it to the collection.

Cheers.

yes, I didn't add it since it in wiki

and speaking of SRestore, there still need some edit for HBD

in srestore_inside() function specifically, I find this flaw (in HBD) from a long time but too lazy to did edit it, as srestore is complex too

[hello_hello]

The link in the wiki seems to lead to an older version than this one (https://forum.doom9.org/showthread.php?p=1802514#post1802514). (2.7h vs 2.76)?

Also, I don't know if anyone looks after the wiki, but there's a typo under the explanation of the omode option (the last example):

source #progressive
srestore(dmode=-4,omode="pp0")
decimate(cycle=5,quality=0) #recommed decimating

[hello_hello]

An SMDegrain question.....

Should contrasharp=50 (or some other value for sharpening with LSFMod) work for HD (720p) sources as contrasharp=true does? (although the latter is usually so subtle I wonder if it's working and I'm seeing placebo sharpening much of the time)
I ask, because contrasharp=50 (or some other value) appears not to work, although it does produce artefacts around the edges if you crank the sharpening up too much, even though it doesn't sharpen. For example (small section of the frame):

SMDegrain(thSAD=150)
LSFMod(strength=100)
Probably over-sharpened a bit, but to illustrate the difference.

https://s16.postimg.org/sm08gzr1x/sharp1.png

SMDegrain(thSAD=150, contrasharp=500)
Note the bottom scan line.

https://s16.postimg.org/xlxooxwol/sharp2.png

Thanks.

[real.finder]

An SMDegrain question.....

Should contrasharp=50 (or some other value for sharpening with LSFMod) work for HD (720p) sources as contrasharp=true does? (although the latter is usually so subtle I wonder if it's working and I'm seeing placebo sharpening much of the time)
I ask, because contrasharp=50 (or some other value) appears not to work, although it does produce artefacts around the edges if you crank the sharpening up too much, even though it doesn't sharpen. For example (small section of the frame):

SMDegrain(thSAD=150)
LSFMod(strength=100)
Probably over-sharpened a bit, but to illustrate the difference.

https://s16.postimg.org/sm08gzr1x/sharp1.png

SMDegrain(thSAD=150, contrasharp=500)
Note the bottom scan line.

https://s16.postimg.org/xlxooxwol/sharp2.png

Thanks.

it use this setting

LSFmod(OutTO8,source=CClip,defaults="slow",strength=Contrasharp,soothe=false,Lmode=0,soft=-2,keep=0)

[hello_hello]

I tried the same thing with v3.1.2d after downscaling to SD, to make sure it wasn't SMDegrain trying to be clever according to the resolution, and while the LSFMod version is oversharpened, to illustrate the difference:

SMDegrain(thSAD=150)
https://s16.postimg.org/6hm1106n9/sharp1.jpg

SMDegrain(thSAD=150, contrasharp=500)
Note the bottom row of pixels again.
https://s16.postimg.org/664ko8q79/sharp2.jpg

SMDegrain(thSAD=150)
LSFMod(strength=500)
https://s16.postimg.org/ss9w0z3xh/sharp3.jpg

Edit: Looking at those screenshots again (upscaled to 1080p on my TV), the Contrasharp=500 version has been sharpened/altered compared to the original, so maybe the contrasharp function is meant to be so subtle it's almost impossible to see the effect at normal settings, even when LSFMod is used??

I'll confess I assumed it'd have the same effect as LSFMod on it's own, but maybe that's not how it works. From the help file:

Contrasharp.
In the other hand if your parameter input is an integer, LSFmod() will be used instead. It will be much slower, but maybe better for certain sources. Its value will serve as a contrasharpening multiplier, use one around 50 for similar strength as Contrasharpening().

I assume a "contrasharpening multiplier" is not the same thing?

[real.finder]

the artefacts in bottom scan line and the top one seems bug in LSFMod with these settings defaults="slow",strength=100,soothe=false,Lmode=0,soft=-2,keep=0

[hello_hello]

the artefacts in bottom scan line and the top one seems bug in LSFMod with these settings defaults="slow",strength=100,soothe=false,Lmode=0,soft=-2,keep=0

Those settings are fine for me when using LSFMod on it's own.

When I crank LSFMod up to a stupid level though, and overlay the result on the SMDegrain version, it looks as though the edge line/row of pixels is being sharpened by the same amount each time, while the rest of the image is being "contrasharpened" in the usual way, or however that works.

Place these two images on top of each other and switch between them and hopefully you'll see what I mean. It looks like the first column of pixels from the first image has been placed over the second image. Same with the last column on the right. That's possibly not what's actually happening....

LSFMod(defaults="slow",strength=500,soothe=false,Lmode=0,soft=-2,keep=0)
https://s4.postimg.org/gsbary9rx/sharp4.jpg

SMDegrain(thSAD=150, contrasharp=500)
https://s4.postimg.org/dwy7l35rx/sharp5.jpg

It doesn't matter anyway. Normally you wouldn't crank the contrasharp setting so high, and I don't think using LSFMod for SMDegrain's contrasharpening is intended to sharpen in the usual way, so I'll continue to use LSFMod on it's own.

Thanks.

[real.finder]

Those settings are fine for me when using LSFMod on it's own.

When I crank LSFMod up to a stupid level though, and overlay the result on the SMDegrain version, it looks as though the edge line/row of pixels is being sharpened by the same amount each time, while the rest of the image is being "contrasharpened" in the usual way, or however that works.

Place these two images on top of each other and switch between them and hopefully you'll see what I mean. It looks like the first column of pixels from the first image has been placed over the second image. Same with the last column on the right. That's possibly not what's actually happening....

LSFMod(defaults="slow",strength=500,soothe=false,Lmode=0,soft=-2,keep=0)
https://s4.postimg.org/gsbary9rx/sharp4.jpg

SMDegrain(thSAD=150, contrasharp=500)
https://s4.postimg.org/dwy7l35rx/sharp5.jpg

It doesn't matter anyway. Normally you wouldn't crank the contrasharp setting so high, and I don't think using LSFMod for SMDegrain's contrasharpening is intended to sharpen in the usual way, so I'll continue to use LSFMod on it's own.

Thanks.

interesting, I will check the SMDegrain code again

[real.finder]

well it work like this


#~ SMDegrain(Contrasharp=500)
LSFmod(SMDegrain(),source=last,defaults="slow",strength=500,soothe=false,Lmode=0,soft=-2,keep=0) #same as above

so, it's bug in LSFmod when using source clip

[nhope]

The SMDegrain documentation (http://avisynth.nl/index.php/SMDegrain#Basic) states 100 as the maximum value for Contrasharp:

Contrasharp int (0-100, default -)

So maybe it doesn't know what to do with a value of 500?

[hello_hello]

well it work like this


#~ SMDegrain(Contrasharp=500)
LSFmod(SMDegrain(),source=last,defaults="slow",strength=500,soothe=false,Lmode=0,soft=-2,keep=0) #same as above

so, it's bug in LSFmod when using source clip

I get the same with this (just to check), and LSFMod doesn't specify an upper limit for the strength value, so yes it must be an LSFMod bug.

LSFmod(FluxSmoothT(),source=last,defaults="slow",strength=500,soothe=false,Lmode=0,soft=-2,keep=0)

I've never used LSFMod's source option before, so I had a look and it says:
"If source is defined, LSFmod doesn't sharp more a denoised clip than this source clip
In this mode, you can safely set Lmode=0 & PP=off"

Now I know why SMDegrain's contrasharp function doesn't actually appear to sharpen, relative to the source, as I assume it uses LSFMod the same way.

Thanks for the help and info. When applying sharpening if I want the output to be a little sharper than the source (which I usually do) I now know I need to keep using LSFMod() separately.

Cheers.

[real.finder]

updated ResizeX (in same edi_rpow2 link in OP) for fix Y8 bugs that happened in last updates

[tormento]

I was trying contrasharpening with SMDegrain (x64 flavor) and it can't find medianblur and AFAIK there is no x64 version of it.

Any workaround?

[blaze077]

It uses MedianBlur2 which can be found here. (http://github.com/tp7/MedianBlur2/releases/download/0.94/MedianBlur2-x64.zip)

[tormento]

It uses MedianBlur2 which can be found here. (http://github.com/tp7/MedianBlur2/releases/download/0.94/MedianBlur2-x64.zip)
This morning I woke up at 6. That is the result. :thanks:

[tuanden0]

Could you please upload plugin TBilateral.dll x64?
DehaloHmod require it but I'm using avs+ x64 and only 32bit on wiki.

[real.finder]

Could you please upload plugin TBilateral.dll x64?
DehaloHmod require it but I'm using avs+ x64 and only 32bit on wiki.

I will happily upload it if it existing, as far I know no one did port it to x64

[hello_hello]

real.finder,

I was playing around with your "sanimebob and smam and admfilter" script today (v1.44) and I think I found an error in the admfilter function.
Simply using this: admfilter()
results in an error "dfttestMC doesn't have a named argument luma_rebuild".

While I'm here....
The dfttestMC script (v3) includes the Dither_Luma_Rebuild function but it's quite different from the Dither_Luma_Rebuild function in the SMDegrain script which obviously has more functionality. Should the two functions have different names or is it safe to delete or comment out the function in the dfttestMC script?

Thanks.

[real.finder]

real.finder,

I was playing around with your "sanimebob and smam and admfilter" script today (v1.44) and I think I found an error in the admfilter function.
Simply using this: admfilter()
results in an error "dfttestMC doesn't have a named argument luma_rebuild".

While I'm here....
The dfttestMC script (v3) includes the Dither_Luma_Rebuild function but it's quite different from the Dither_Luma_Rebuild function in the SMDegrain script which obviously has more functionality. Should the two functions have different names or is it safe to delete or comment out the function in the dfttestMC script?

Thanks.

my edit of dfttestMC don't has Dither_Luma_Rebuild function (you must have SMDegrain) and you must use my edit of dfttestMC with admfilter

[hello_hello]

AnimeIVTC seems to insist on using TMM2 if you specify mode=1 or mode=4. It's the same if the source is YV12 or YUY2, which I'll confess confuses me a little as I didn't think TMM2 supported YUY2. Modes 2 and 3 work without TMM2 regardless of the source type.
I had no idea TMM2 existed until I bumped into the error. Could a link to TMM2 be added to the Wiki as well? There's only a link for TMM.

I don't know whether it matters, but according to the TMM2 help file it only supports Windows Vista SP2 or later. Contrary to that though, putting tmm2.dll in the Avisynth plugins folder prevented the "no function named tmm2" error even though I'm using XP, so I assume it's working.

Should the script be checking for the existence of TMM2? I'm just trying to understand if/when the video needs to be converted to a different format.

Cheers.

[real.finder]

AnimeIVTC seems to insist on using TMM2 if you specify mode=1 or mode=4. It's the same if the source is YV12 or YUY2, which I'll confess confuses me a little as I didn't think TMM2 supported YUY2. Modes 2 and 3 work without TMM2 regardless of the source type.
I had no idea TMM2 existed until I bumped into the error. Could a link to TMM2 be added to the Wiki as well? There's only a link for TMM.

I don't know whether it matters, but according to the TMM2 help file it only supports Windows Vista SP2 or later. Contrary to that though, putting tmm2.dll in the Avisynth plugins folder prevented the "no function named tmm2" error even though I'm using XP, so I assume it's working.

Should the script be checking for the existence of TMM2? I'm just trying to understand if/when the video needs to be converted to a different format.

Cheers.

yes in avs26 and avs+ you need tmm2

and for YUY2 in avs26 it will convert to yv16 then back to YUY2, most of filters (whether dll or avsi) that support YUY2 do something like this internally anyway

even if chikuzen said it work on vista and up some of his plugins work with xp too

and some that not work I did built them to work in xp 32 https://forum.doom9.org/showthread.php?p=1798117#post1798117

[hello_hello]

my edit of dfttestMC don't has Dither_Luma_Rebuild function (you must have SMDegrain) and you must use my edit of dfttestMC with admfilter

I must've googled myself into an early version of your edit of the script. It has your name on it and it's labelled v3.

I've now found v3.9 though, and it has no Dither_Luma_Rebuild function and admfilter works fine.

Thanks.

[StainlessS]

Cheers, real.finder. I musta missed that post.

[real.finder]

new edit for aWarpSharp4xx, even if it added support for the new parameters that jpsdr added recently (in the test builds that he PM me), it still support 2015.12.30 Version and up if you didn't use the new upcoming parameters, and this edit fix some small things, so it's better to update even before new Version of awarpsharp2

[real.finder]

I did change the GBlur function name for TCannyMod by chikuzen to avoid the collision with GBlur by vcmohan https://github.com/realfinder/TCannyMod/releases

now it's GBlur2

same for https://github.com/realfinder/CombMask/releases but for all functions since they existing in old dlls

now every function has 2 in the end (CombMask2, MaskedMerge2 and IsCombed2)

[magiblot]

new edit for aWarpSharp4xx, even if it added support for the new parameters that jpsdr added recently (in the test builds that he PM me), it still support 2015.12.30 Version and up if you didn't use the new upcoming parameters, and this edit fix some small things, so it's better to update even before new Version of awarpsharp2

Hi real.finder,

Is there a thread or link to stay informed about aWarpSharp2 updates?

Also, you could add a link to your srestore (https://forum.doom9.org/showpost.php?p=1809661&postcount=696) update in the main post.

[real.finder]

Hi real.finder,

Is there a thread or link to stay informed about aWarpSharp2 updates?


https://forum.doom9.org/showthread.php?p=1819882#post1819882

[real.finder]

new update for DeHalo_alpha things, more speed in some cases (in search_rade=1, search_radi=1)

keep in mind that I did some update in the previous period for another functions but didn't post to advertise them due laziness and/or whatever

[kuchikirukia]

Unfiltered: 30MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true) = 21MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true, plane=0) = 28MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true, plane=3) = 81MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true, plane=1) = 83MB

Umm....

eh, 3.1.2d does it too.

[real.finder]

Unfiltered: 30MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true) = 21MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true, plane=0) = 28MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true, plane=3) = 81MB
smdegrain(thsad=200,lsb=true,lsb_in=false,lsb_out=true, plane=1) = 83MB

Umm....

eh, 3.1.2d does it too.

it's something in mvtools or the way of how the encoder work

[real.finder]

days ago I did update stab3, now it's should be more stable with mirror=15

[tormento]

I want to ask you a curiosity: is SMDegrain written to work with the 16 bit depth capabilities of MaskTool, MVTool and KNLMeansCL or does it use some kind of workaround?

AFAIK they are the only filters I use with the following:

SMDegrain (tr=4,PreFilter=4,thSAD=600,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=0)

If not, would be a "pure" 16 bit version faster and/or more precise than the workaround method, if any?

[real.finder]

I want to ask you a curiosity: is SMDegrain written to work with the 16 bit depth capabilities of MaskTool, MVTool and KNLMeansCL or does it use some kind of workaround?

AFAIK they are the only filters I use with the following:

SMDegrain (tr=4,PreFilter=4,thSAD=600,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=0)

If not, would be a "pure" 16 bit version faster and/or more precise than the workaround method, if any?

in avs+ native 16 bit? it not use workaround, but the lsb in your code is not, it should show you some error message that lsb it not work with native HBD

edit: it will not be faster in native 16 unless you did this workaround


#8bit source
c=last

SMDegrain(globals=3,tr=4,PreFilter=4)
global fv1 = fv1.MScalevect(bits=16)
global fv2 = fv2.MScalevect(bits=16)
global fv3 = fv3.MScalevect(bits=16)
global fv4 = fv4.MScalevect(bits=16)
global bv1 = bv1.MScalevect(bits=16)
global bv2 = bv2.MScalevect(bits=16)
global bv3 = bv3.MScalevect(bits=16)
global bv4 = bv4.MScalevect(bits=16)

c
ConvertBits(16)
SMDegrain(globals=1,tr=4,thSAD=600,contrasharp=false,refinemotion=false,truemotion=true,plane=4)
ConvertBits(8,dither=1)

[tormento]

in avs+ native 16 bit?
Thanks for your clear reply.

To clarify my question: will be possible one day to have a SMDegrain (bitdepthworkingspace=8/10/16,outputbitdepth=8/10/16) without the need of LSB? Would like also to try if a pure 16 bit processing would be more precise than a "fake" one.

[real.finder]

Thanks for your clear reply.

To clarify my question: will be possible one day to have a SMDegrain (bitdepthworkingspace=8/10/16,outputbitdepth=8/10/16) without the need of LSB? Would like also to try if a pure 16 bit processing would be more precise than a "fake" one.

it's already do that but there are some filters that not work with native HBD yet (in your case it support native 10-16 bit now but you should remove the "lsb=true" or make it false), but that is way slower than the lsb method, even with the code I post above, see here https://forum.doom9.org/showthread.php?p=1833887#post1833887

[tormento]

@real.finder

Could you please tell me which is the difference between
pre=KNLMeansCL (d=0, a=3, h=7.0)
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=pre, truemotion=false, plane=4, chroma=true)
and
pre=SMDegrain_KNLMeansCL (d=0, a=3, h=7.0)
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=pre, truemotion=false, plane=4, chroma=true)
They are giving me different results.

[real.finder]

@real.finder

Could you please tell me which is the difference between
pre=KNLMeansCL (d=0, a=3, h=7.0)
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=pre, truemotion=false, plane=4, chroma=true)
and
pre=SMDegrain_KNLMeansCL (d=0, a=3, h=7.0)
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=pre, truemotion=false, plane=4, chroma=true)
They are giving me different results.

of course they are different, since SMDegrain_KNLMeansCL process chroma with luma by special way

[tormento]

of course they are different, since SMDegrain_KNLMeansCL process chroma with luma by special way
Please define "special".

[real.finder]

Please define "special".

back then and still KNLMeansCL can't process chroma with luma in subsampling Chroma (new KNLMeansCL can do process chroma alone) so dogway use stacking method, you can see the code yourself, or back to dogway posts in videohelp forum

[magiblot]

Hi real.finder,

Is there any way to run srestore in AVS+ x64? At first sight, it won't run because there doesn't seem to be a x64 version of GScript. Since I have read AVS+ supports GScript's functionality natively, I tried to replace the call to GScriptClip in srestore.avsi with ScriptClip, but a "I don't know what 'dm' means" error is the farthest I got.

Thanks.

[StainlessS]

GScriptClip is from Grunt plugin, not GScript.

[magiblot]

Wow, what a miss.
Thanks, Stainless :).

[real.finder]

Hi real.finder,

Is there any way to run srestore in AVS+ x64? At first sight, it won't run because there doesn't seem to be a x64 version of GScript. Since I have read AVS+ supports GScript's functionality natively, I tried to replace the call to GScriptClip in srestore.avsi with ScriptClip, but a "I don't know what 'dm' means" error is the farthest I got.

Thanks.

as StainlessS said, it's Grunt

and I think the error related to something else (not Grunt)

you use mt "Prefetch()"? cuz it will not work, runtime things (srestore use it) not compatible with mt yet

[tormento]

back then and still KNLMeansCL can't process chroma with luma in subsampling Chroma (new KNLMeansCL can do process chroma alone) so dogway use stacking method, you can see the code yourself, or back to dogway posts in videohelp forum
Looked.

What does this line

!lsb && lsb_in ? Ditherpost(mode=6,slice=false) : last

means?

As I am using SMDegrain_KNLMeansCL as a prefilter (just to have more control over prefilter parameters), is it useful to dither when SMDegrain already dither again at some point?

Wanting to use KNLMeansCL as a plain prefilter, would it be sufficient to use:

pre =KNLMeansCL (d=0, a=3, h=7.0, channels="Y")
pre2=KNLMeansCL (d=0, a=3, h=7.0, channels="UV")
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=pre2, truemotion=false, plane=4, chroma=true)

or the very complex prefilter script is necessary?

[real.finder]

remember that I told you that mvtools don't has lsb_in anywhere, it's just has lsb parameter in mdegrainX, so you must dither any stacked input clip

yes, you can use

pre =KNLMeansCL (d=0, a=3, h=7.0, channels="Y")
pre2=KNLMeansCL (d=0, a=3, h=7.0, channels="UV")
SMDegrain (tr=6, thSAD=400, refinemotion=false, lsb=true, mode=0, contrasharp=false, PreFilter=pre2, truemotion=false, plane=4, chroma=true)

or anything give you what you want

but I think you need to added "pre." before KNLMeansCL in pre2, so it should be

pre2=pre.KNLMeansCL (d=0, a=3, h=7.0, channels="UV")

[tormento]

remember that I told you that mvtools don't has lsb_in anywhere, it's just has lsb parameter in mdegrainX, so you must dither any stacked input clip
We need some Pinterf modding here :)
or anything give you what you want
:thanks:

[real.finder]

We need some Pinterf modding here :)


why? lsb is hack, he already did support native avs+ HBD, and he will add out16 as replacement for lsb method, see last posts in his mvtools Thread

[tormento]

why? lsb is hack, he already did support native avs+ HBD, and he will add out16 as replacement for lsb method, see last posts in his mvtools Thread

I saw and I know. Look at smiley.

[burfadel]

To clarify my question: will be possible one day to have a SMDegrain (bitdepthworkingspace=8/10/16,outputbitdepth=8/10/16) without the need of LSB? Would like also to try if a pure 16 bit processing would be more precise than a "fake" one.

We need some Pinterf modding here :)

It's more a limitation of SMDegrain script. It was designed purely with the hack workaround in mind since native 16 bit support wasn't available in Avisynth and the supporting filters when the script was made. Updating to support the latest PinterF tools can be done, but is such a significant change it would be a bit of work. Also there's the issue of whether to keep the hack support in place etc.

How does it fair with the latest mClean (which requires the latest various filter versions, a link to the dependencies is available in the thread). It's made with 8-16 bit support in mind. For filters where there are no >8 bit support (mainly for deband and optional autoadjust) there is a script workaround for it. Keep in mind though the output with different to SMDegrain due to a different design and implementation. It's also designed to be simpler to use since many typical optional parameters provided in scripts really don't provide noticeable difference, or they sound good but potentially be disadvantageous. Mostly they just confuse people :).

[real.finder]

SMDegrain work with native 8-16 bit support since long time, but not in all options yet since many filters dont has native 8-16 bit support yet

lsb still can be used and it's faster than native 8-16 bit but there will be new out16 that will be the fastest (see last posts in mvtools pfmod)

[tormento]

How does it fair with the latest mClean
When I start to use a script, beside intrinsic value, I check that all the plugins that it uses are “alive” and well supported from authors. Some are from 2012. That will tell us they will never receive good AVS+ implementation and/or high bit.

[real.finder]

days ago I updated the SMDegrain with new n16 and n16_out bool parameters

in n16 no prefiltiring nor tv to pc convert will be in 16 bit like what happen in old lsb method. in other words they will be in pure 8 bit unless you use the prefilter clip method. then you can feed in native HBD or lsb if you like and the SMDegrain will convert them to 8 bit internally after do tv to pc convert. same as old lsb method

in other words, n16 and n16_out should be same as lsb things but faster

but keep in mind that they are not 100% same because of the difference in dither (avs+ convertbits dither will be used)

aside from that. there are little change in lut scaling of tv to pc function (aka luma rebuild) as pinterf suggest. but still no fix for dot vs comma things yet

edit: and something else since we talk about prefilter clip method

both SMDegrain_prefilters in PreFilter=4 and SMDegrain_KNLMeansCL outside use Different Default settings than what used in SMDegrain(), if you want same output use it like this

PreFilterclip=SMDegrain_prefilters (PreFilter=4, d=1, a=1, h=7.0, device_type="GPU")

[ChaosKing]

I used the old non native 16bit smdegrain like this:
lsb=true \
U = ExtractU().SMDegrain(thsad=400, lsb_out=lsb, prefilter=p.ExtractU(), thSADC=0, plane=0, chroma=false) \
V = ExtractV().SMDegrain(thsad=400, lsb_out=lsb, prefilter=p.ExtractV(), thSADC=0, plane=0, chroma=false) \
Y = SMDegrain(thsad=500, lsb_out=lsb, lsb=lsb, prefilter=p, thSADC=0, plane=0, chroma=false)
YToUV(U, V, Y)

As far I can see I just need to change lsb_out to n16_out and lsb to n16? But know I get this error:
MDegrainX : only YV12, YV16 or YV24 allowed for out16

line 559 -> lsb_out ? StackVertical (last, BlankClip (last, pixel_type=type, color_yuv=0,length=1)) : last""")}

What am I doing wrong?

[real.finder]

I used the old non native 16bit smdegrain like this:
lsb=true \
U = ExtractU().SMDegrain(thsad=400, lsb_out=lsb, prefilter=p.ExtractU(), thSADC=0, plane=0, chroma=false) \
V = ExtractV().SMDegrain(thsad=400, lsb_out=lsb, prefilter=p.ExtractV(), thSADC=0, plane=0, chroma=false) \
Y = SMDegrain(thsad=500, lsb_out=lsb, lsb=lsb, prefilter=p, thSADC=0, plane=0, chroma=false)
YToUV(U, V, Y)

As far I can see I just need to change lsb_out to n16_out and lsb to n16? But know I get this error:
MDegrainX : only YV12, YV16 or YV24 allowed for out16

line 559 -> lsb_out ? StackVertical (last, BlankClip (last, pixel_type=type, color_yuv=0,length=1)) : last""")}

What am I doing wrong?

well, seems pinterf don't allow Y8 for out16 in mvtools (don't know why he did that)

try with ExtractV().converttoyv12() and ExtractU().converttoyv12()

[ChaosKing]

Now the message is MDegrain6: source clip and vectors: plane width or height subsampling is different!
Same line 559

[pinterf]

well, seems pinterf don't allow Y8 for out16 in mvtools (don't know why he did that)

try with ExtractV().converttoyv12() and ExtractU().converttoyv12()
maybe poor Y8 was forgotten.

[real.finder]

Now the message is MDegrain6: source clip and vectors: plane width or height subsampling is different!
Same line 559

you need to make the prefilter same color type (by use converttoyv12 with it too), anyway pinterf will fix this and make it work with Y8

[pinterf]

Fixed. Check it.

[ChaosKing]

Thanks pinterf, works now :D

//EDIT, small bench
AviSynth+ 0.1 (r2632, MT, i386)

lsb + ConvertFromStacked():
FPS (min | max | average): 3.505 | 10.88 | 9.164
Memory usage (phys | virt): 214 | 235 MiB
Thread count: 100
CPU usage (average): 59%

Time (elapsed): 00:01:49.119

n16:
FPS (min | max | average): 4.635 | 11.40 | 9.373
Memory usage (phys | virt): 205 | 224 MiB
Thread count: 100
CPU usage (average): 60%

Time (elapsed): 00:01:46.684

A bit faster and uses less memory, good job!

[real.finder]

new edit for eedi3_resize16 (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/eedi3_resize16.avsi) and ResizeX (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.6%20and%20up/ResizeX.avsi) and edi_rpow2 (https://pastebin.com/YAtftry1) and IResize (https://forum.doom9.org/showthread.php?p=1823545#post1823545)

edi_rpow2 and eedi3_resize16 now don't use yv12 workaround since pinterf did update eedi3 to work with Y8

[magiblot]

Can the daa() function in AnimeIVTC be updated to use NNEDI3 instead of NNEDI2? NNEDI2 is not avaiable in x64.
P.S.: I know there's daa3mod but there are certain uses for which daa works better.
EDIT:
Look at the Marios:

https://i.imgur.com/JWFCoND.jpg

EDIT2:

This is daa's code:

function daa(clip c) {
nn = c.nnedi2(field=-2)
dbl = mt_average(selecteven(nn),selectodd(nn),U=3,V=3)
dblD = mt_makediff(c,dbl,U=3,V=3)
shrpD = mt_makediff(dbl,dbl.removegrain((width(c)>1100) ? 20 : 11),U=3,V=3)
DD = shrpD.repair(dblD,13)
return dbl.mt_adddiff(DD,U=3,V=3) }

Replacing "nnedi2" with "nnedi3" is enough to have it working on x64 but since I'm not used to calling these directly I'm not sure if this all right.

[real.finder]

Can the daa() function in AnimeIVTC be updated to use NNEDI3 instead of NNEDI2? NNEDI2 is not avaiable in x64.
P.S.: I know there's daa3mod but there are certain uses for which daa works better.
EDIT:
Look at the Marios:

https://i.imgur.com/JWFCoND.jpg

EDIT2:

This is daa's code:

function daa(clip c) {
nn = c.nnedi2(field=-2)
dbl = mt_average(selecteven(nn),selectodd(nn),U=3,V=3)
dblD = mt_makediff(c,dbl,U=3,V=3)
shrpD = mt_makediff(dbl,dbl.removegrain((width(c)>1100) ? 20 : 11),U=3,V=3)
DD = shrpD.repair(dblD,13)
return dbl.mt_adddiff(DD,U=3,V=3) }

Replacing "nnedi2" with "nnedi3" is enough to have it working on x64 but since I'm not used to calling these directly I'm not sure if this all right.

well, aa it's not recommended in first place as I said in AnimeIVTC Thread

daa3 already do it. or set slow parameter in daa3mod to false

[magiblot]

daa3 already do it. or set slow parameter in daa3mod to false

That's right, thanks!

[tormento]

keep in mind that they are not 100% same because of the deference in dither (avs+ convertbits dither will be used)
I can see worse banding on some color transitions.

Is there anything you can do (apart from using a not yet existing highbit Dither build) to improve things?

[real.finder]

I can see worse banding on some color transitions.

Is there anything you can do (apart from using a not yet existing highbit Dither build) to improve things?

can you show some samples for that?

[tormento]

can you show some samples for that?
Can you please send me the latest working version with lsb and dither?

[real.finder]

Can you please send me the latest working version with lsb and dither?

you can use lsb if you want in last one, n16 has nothing to do with lsb, all lsb things didn't changed

[tormento]

you can use lsb if you want in last one, n16 has nothing to do with lsb, all lsb things didn't changed

But there is no dither.dll use anymore :)

[real.finder]

But there is no dither.dll use anymore :)

if you mean with n16, then yes that normal, dither.dll = lsb hack things

[tormento]

if you mean with n16, then yes that normal, dither.dll = lsb hack things
Ok. I tried and lsb needs dither indeed.

After some testing, I have realized it is my player problem to amplify macroblocks and artifacts when decoding. I have tried to load different samples inside VirtualDub2 and the difference is negligible.

At this point I dunno if MPHC-BE is too sensitive or Virtualdub2 is way better when decoding ;)

Trigger disengaged (at least now ;))

I will go on using n16 as it is way faster than lsb. Anyway I would like CorvertBits to add more modes than ordered dithering only.

[tormento]

Download this (https://openload.co/f/wobfOwA6EQU/Fantozzi692vs704.mkv.mp4)file and apply this script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\ffms\ffms2.dll")
FFVideoSource("F:\Out\Fantozzi692vs704.mkv", fpsnum=25, fpsden=1, threads=1)
SMDegrain (tr=4, thSAD=400, n16=true, mode=0, PreFilter=4)
Prefetch(6)
The result is this:

https://i.lensdump.com/i/89N7bi.md.jpg (https://lensdump.com/i/89N7bi)

Any idea of why?

[StainlessS]

In a script like that, you really should reduce the problem (remove noise), eg

LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\ffms\ffms2.dll")
FFVideoSource("F:\Out\Fantozzi692vs704.mkv", fpsnum=25, fpsden=1, threads=1)
SMDegrain (tr=4, thSAD=400, n16=true, mode=0, PreFilter=4)


Does it occur without the SMDegain line ?
Does it occur only on first frame or all of the way through ? (some clips have that kind of corruption only on first frame, seems to be unrelated to any script).
Try use another source filter, same ?
Which version MVTools ? (bottom line looks to be missing U and V (all 0) ?

[pinterf]

Where can I download the latest SMDegrain? I'm trying to follow the instruction given on the 1st page but found nothing. This page: http://avisynth.nl/index.php/SMDegrain lists the yr 2015 version 3.1.2d as the latest.

[real.finder]

Where can I download the latest SMDegrain? I'm trying to follow the instruction given on the 1st page but found nothing. This page: http://avisynth.nl/index.php/SMDegrain lists the yr 2015 version 3.1.2d as the latest.

here https://forum.doom9.org/showpost.php?p=1790702&postcount=3

[tormento]

Does it occur without the SMDegain line ?
Does it occur only on first frame or all of the way through ? (some clips have that kind of corruption only on first frame, seems to be unrelated to any script).
Try use another source filter, same ?
Which version MVTools ? (bottom line looks to be missing U and V (all 0) ?

1) No, it does not.
2) All the way.
3) I use DGSource, that was already my attempt to try different source input.
4) Latest MVTools.

[pinterf]

here https://forum.doom9.org/showpost.php?p=1790702&postcount=3
Thanks. Could you edit the first post, so that instead of
"see videohelp link and the top of script" it mentions the 3rd post as well?

[real.finder]

Thanks. Could you edit the first post, so that instead of
"see videohelp link and the top of script" it mentions the 3rd post as well?

done :)

[tormento]

@StainlessS @real.finder

No idea? :)

[Groucho2004]

@StainlessS @real.finder

No idea? :)
The green line will disappear when you crop to mod 16 (688).

[tormento]

The green line will disappear when you crop to mod 16 (688).

That is a simple solution I already know.



I usually encode 1920xMOD4/8 videos without green lines.



I would like to know why in THIS case it appears.

[pinterf]

That is a simple solution I already know.
I usually encode 1920xMOD4/8 videos without green lines.
I would like to know why in THIS case it appears.
It was an out16=true issue.
Fixed in mvtools2 2.7.31. Thanks for the report.

[tormento]

It was an out16=true issue.
Fixed in mvtools2 2.7.31. Thanks for the report.
You are always welcome. :thanks:

[real.finder]

added new parameter "nnrep" to fix eediX artifacts (https://i.postimg.cc/J01bGwZG/both.png) by using nnedi clip

for now it available in sanimebob and eedi3_resize16

edit: and edi_rpow2

[gugglu]

Hi real.finder 1st of all thank you for updating great collection of scripts, very nice work. I like your new updates.i need help on smdegrain to get start with following smdegrain(n16=true,n16_out=true) i don't know what i am missing it didn't worked gave me an error i have attached a error scrn.shot.

i tried it like this
ConvertToRGB24()
smdegrain(n16=true,n16_out=true)

ConvertToRGB24()
ConvertBits(16)
smdegrain(n16=true,n16_out=true)

n16 & n16_out are not working with alone RGB24 i m missing something there can u correct or complete my code. :thanks:

[real.finder]

Hi real.finder 1st of all thank you for updating great collection of scripts, very nice work. I like your new updates.i need help on smdegrain to get start with following smdegrain(n16=true,n16_out=true) i don't know what i am missing it didn't worked gave me an error i have attached a error scrn.shot.

i tried it like this
ConvertToRGB24()
smdegrain(n16=true,n16_out=true)

ConvertToRGB24()
ConvertBits(16)
smdegrain(n16=true,n16_out=true)

n16 & n16_out are not working with alone RGB24 i m missing something there can u correct or complete my code. :thanks:

the Attachments Pending Approval but anyway smdegrain (mvtools too) not work with rgb in first place, and n16 need 8bit input

[gugglu]

the Attachments Pending Approval but anyway smdegrain (mvtools too) not work with rgb in first place, and n16 need 8bit input

thanks for your reply ,
sorry i wasn't aware of that attachment take time to approve , yes n16 works with 8 bits as you said https://prnt.sc/j72wvk

, but what about n16_out=true soon as i putt n16_out=true into smdegrain(n16=true) on 8 bit clip it brings me this http://prntscr.com/j733s5

please tell me how to get it work i am trying from last couples of hours with no luck how it works in Avisynthplus .please guide

[real.finder]

thanks for your reply ,
sorry i wasn't aware of that attachment take time to approve , yes n16 works with 8 bits as you said https://prnt.sc/j72wvk

, but what about n16_out=true soon as i putt n16_out=true into smdegrain(n16=true) on 8 bit clip it brings me this http://prntscr.com/j733s5

please tell me how to get it work i am trying from last couples of hours with no luck how it works in Avisynthplus .please guide

it's megui and avs+ problems. the megui use rgb for preview and avs+ dont allow 16bit yuv to rgb24 (8 bit)

[gugglu]

it's megui and avs+ problems. the megui use rgb for preview and avs+ dont allow 16bit yuv to rgb24 (8 bit)

Thanks for clearing it that it will not work with Megui+AvisynthPlus, but i don't use megui to encode anyway it is just for making a script or sometime i use AvspMod to edit the script.
For Encoding i use .cmd Avs2pipemod+x264-10bit. i want to learn how to do a color-space conversion and please tell in which tool have u tested the n16_out setting.
I want to know how it works with AvisynthPlus's Native High bit-depth. and what are the requirement to use it, smdegrain is very nice function i use it on most of my clips but without knowing some setting in the function that i m trying to find out how they works is kind strange, never had problem any other parameter i have tested the full code of smdegrain() excluding n16=true, n16_out=true and works as excepted no doubt you did very great job.
i am curious to know few things hope you won't mind explaining them more clearly. thanks real.finder you're a great mod.

if we cant use n16_out=true why it is there? or is it related to Avs+ Native High_bit-depth

if we can use it then how ?

if it don't work with MeGui+AvisynthPlus so which tool u used tried these setting?

one last thing how to prepare color-space for smdegrain if i want to use it n16_out=true, n16=n16_out

i was thinking about DitherTools it i have some function related to color-space but i don't know how to do it as this happening 1st time with me i want to know how we prepare color-space before so next we be able to use

dither_convert_yuv_to_rgb()
r
g
b
Dither_convert_rgb_to_yuv()

smdegrain(n16_out=true, n16=true)

[pinterf]

it's megui and avs+ problems. the megui use rgb for preview and avs+ dont allow 16bit yuv to rgb24 (8 bit)
I suppose Megui Invokes a simple ConvertToRGB24()?

[real.finder]

Thanks for clearing it that it will not work with Megui+AvisynthPlus, but i don't use megui to encode anyway it is just for making a script or sometime i use AvspMod to edit the script.
For Encoding i use .cmd Avs2pipemod+x264-10bit. i want to learn how to do a color-space conversion and please tell in which tool have u tested the n16_out setting.
I want to know how it works with AvisynthPlus's Native High bit-depth. and what are the requirement to use it, smdegrain is very nice function i use it on most of my clips but without knowing some setting in the function that i m trying to find out how they works is kind strange, never had problem any other parameter i have tested the full code of smdegrain() excluding n16=true, n16_out=true and works as excepted no doubt you did very great job.
i am curious to know few things hope you won't mind explaining them more clearly. thanks real.finder you're a great mod.

if we cant use n16_out=true why it is there? or is it related to Avs+ Native High_bit-depth

if we can use it then how ?

if it don't work with MeGui+AvisynthPlus so which tool u used tried these setting?

one last thing how to prepare color-space for smdegrain if i want to use it n16_out=true, n16=n16_out

i was thinking about DitherTools it i have some function related to color-space but i don't know how to do it as this happening 1st time with me i want to know how we prepare color-space before so next we be able to use

dither_convert_yuv_to_rgb()
r
g
b
Dither_convert_rgb_to_yuv()

smdegrain(n16_out=true, n16=true)

I think you should report this in megui Thread, anyway, you can convert it back to 8 bit in last line for preview, and don't use convert for encoding

DitherTools can do it (for preview) but don't support native HBD of avs+ but you can convert native to lsb at cost of some speed to use DitherTools Dither_srgb_display or dither_convert_yuv_to_rgb

edit: I think virtualdub2 can do it for preview using native avs+ HBD

[real.finder]

I suppose Megui Invokes a simple ConvertToRGB24()?

it seems do that

[gugglu]

I think you should report this in megui Thread, anyway, you can convert it back to 8 bit in last line for preview, and don't use convert for encoding

DitherTools can do it (for preview) but don't support native HBD of avs+ but you can convert native to lsb at cost of some speed to use DitherTools Dither_srgb_display or dither_convert_yuv_to_rgb

i know the lsb thing , thanks for your time tho.

[gugglu]

edit: I think virtualdub2 can do it for preview using native avs+ HBD

Much appreciate it real.finder :) , it works smdegrain(n16_out=true,n16=true) in Virtuldub2 preview thanks lot for mentioning VDub2 :thanks:

[tormento]

I don't know if SMDegrain could be the right address to my request but sometimes, with old movies, camera was not so stable and it introduces useless micropanning to video.

Could you please add some MDepan/Depan or DePanEstimate/DePan function to improve motion estimation and decrease bitrate?

[real.finder]

I don't know if SMDegrain could be the right address to my request but sometimes, with old movies, camera was not so stable and it introduces useless micropanning to video.

Could you please add some MDepan/Depan or DePanEstimate/DePan function to improve motion estimation and decrease bitrate?

there are stab() (or stab3()), and I already did some edit to it

[tormento]

there are stab() (or stab3()), and I already did some edit to it
Where?

Could be nice to have an all in one inside SMDegrain :)

[real.finder]

Where?


in the OP ofc

Could be nice to have an all in one inside SMDegrain :)

will not do this, SMDegrain has nothing to do with stab, and why you ever want this!

[tormento]

in the OP ofc
Can you give me decryption key? :(

[ChaosKing]

Click on his signature link and then on "stab3 and others":
here's the direct link: https://pastebin.com/XHxCbbxC

[tormento]

will not do this, SMDegrain has nothing to do with stab, and why you ever want this!
In my absence of knowledge, if any MV is used, it should be the same from denoising.

[tormento]

Click on his signature link and then on "stab3 and others":
Thanks.

[StainlessS]

Just pointing out to someone (dont know who), that the Wiki entry for SRestore function prototype
http://avisynth.nl/index.php/Srestore
and the one actually in use, are quite dissimilar [think I first noticed this some years ago].

From Wiki,

srestore(clip source, float "frate", "omode", float "blocks", int "mthresh", int "bthresh", bool "chroma", int "cache", float "rr", clip "dclip")


v2.792

Srestore(clip sourceo, float "frate", "omode", float "speed", float "blocks", int "mode", float "thresh", int "cache", clip "dclip")


I'm currently trying to clean SRestore up a bit (dont like use of eg IsFloat() rather than Defined()) also Adding in Gscript [or built in to Avs+] Functionality
so as to avoid lots ternary conditional tests when a single test can suffice for a block of calculations.
Function seems to have gathered quite a lot of crud over the years.
I shall post my mods but will not support, is for my own use only, if someone else want to continue from there, then fine.

EDIT: My version will likely use RT_Stats for some things, eg String copy, or checking availability of a builtin function, so would work in
all v2.58, v2.6, avs+, might require some removals or replacments to support new function alternatives in avs+ only (ie drop support for other version avs).

EDIT: Will also be making some things more explicit, eg function argument "omode" to Val "omode"
and giving variable types to all of the nested function args rather than implicit type Val for all of them (way too prone to error and scary for
coder to mod anything).

EDIT: Apparently 'blocks' arg not used at all in current ver$.
EDIT: The 'dmode' mentioned in docs dont exist either, presume 'mode' is intended, docs need a real good eye cast over them.

[tormento]

there are stab() (or stab3()), and I already did some edit to it
Unfortunately GrunT AFAIK is x86 only.

[ChaosKing]

Here's a 64bit version for GrunT http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

[tormento]

Here's a 64bit version for GrunT http://avisynth.nl/index.php/AviSynth%2B_x64_plugins
Thanks!

[StainlessS]

Grunt is another Gavino plug that should 100% for sure be embedded in the fantabulous Avs+ Wadjumacallit, thingy.

[tormento]

Grunt is another Gavino plug that should 100% for sure be embedded in the fantabulous Avs+ Wadjumacallit, thingy.
+1

Suggest to Pinterf :)

[StainlessS]

Real.Finder, found bug in latest SRestore(), (v2.792)


svhalf = ssIsVF ? 0.5 : sdoscal ? shbdbpc == 10 ? 512 : shbdbpc == 12 ? 1024 : shbdbpc == 14 ? 8192 : 32768 : 128


half of 2 ^ 12 = 4096 / 2 = 2048. [EDIT: not 1024]
So, possible problems with Avs+ 12 bit.

EDIT: Not sure but think maybe this line also screwed up (was not sure what it was supposed to be).

sscalva = shbdbpc == 10 ? 4 : shbdbpc == 12 ? 8 : shbdbpc == 14 ? 64 : 256

Looks like it might be supoosed to be 12 : 16, where something like for 12 bit, 128 * 8 = 1024,
and should (maybe be] 128 * 16 = 2048.

EDIT: OOps, NO, that is from my "work in progress" converted version, this was from your version.

sscalva = sdoscal ? shbdbpc == 10 ? 4 : shbdbpc == 12 ? 8 : shbdbpc == 14 ? 64 : 256 : 1

[danfgtn]

I'm trying to use some of the dehalomod for 16bit filtering, however, I'm having a little problem, the pixels at the bottom of the image become a bit darker, this only happened to me when I mistakenly used an 8bit filter in 16bit video. I think maybe I understood or done something wrong. I'll leave the images attached. Could someone help me understand what is wrong?

my script:

TFM(mode=5, slow=2, PP=0).TDecimate(mode=1, hybrid=0)

#daa3mod(slow=true)

Dither_convert_8_to_16()

#HQDeringmod(sharp=0, drrep=13, thr=8, elast=2, darkthr=0, lsb_in=true, lsb=true, lsb_out=true, tv_range=true)

#DeHalo_Alpha(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)
#DeHalo_Alpha_2BD(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)

#BlindDeHalo3(rx=1.25, ry=1.25)

nnedi3_resize16(target_width=1024, target_height=576, src_left=0, src_top=0, src_width=0, src_height=0, kernel_d="Spline36",
\kernel_u="Spline36", taps=128, nsize=0, nns=4, qual=2, etype=0, pscrn=0, elast=1.0, tv_range=true, lsb_in=true, lsb=true)

DitherPost(mode=-1)
#Dither_quantize(10, reducerange=true, mode=-1)
#Dither_Out()

Prefetch(4)


Zoomed comparison:
https://i.imgur.com/Zq9YCFf.jpg

Dehalo_alpha:
https://i.imgur.com/zyD02o9.jpg

BlindDehalo:
https://i.imgur.com/gpgno0q.jpg

"Source"
https://i.imgur.com/uehyE8t.jpg

[real.finder]

I'm trying to use some of the dehalomod for 16bit filtering, however, I'm having a little problem, the pixels at the bottom of the image become a bit darker, this only happened to me when I mistakenly used an 8bit filter in 16bit video. I think maybe I understood or done something wrong. I'll leave the images attached. Could someone help me understand what is wrong?

my script:

TFM(mode=5, slow=2, PP=0).TDecimate(mode=1, hybrid=0)

#daa3mod(slow=true)

Dither_convert_8_to_16()

#HQDeringmod(sharp=0, drrep=13, thr=8, elast=2, darkthr=0, lsb_in=true, lsb=true, lsb_out=true, tv_range=true)

#DeHalo_Alpha(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)
#DeHalo_Alpha_2BD(rx=1.25, ry=1.25, darkstr=0.0, brightstr=1.0, lowsens=0, ss=3.0, cs=true)

#BlindDeHalo3(rx=1.25, ry=1.25)

nnedi3_resize16(target_width=1024, target_height=576, src_left=0, src_top=0, src_width=0, src_height=0, kernel_d="Spline36",
\kernel_u="Spline36", taps=128, nsize=0, nns=4, qual=2, etype=0, pscrn=0, elast=1.0, tv_range=true, lsb_in=true, lsb=true)

DitherPost(mode=-1)
#Dither_quantize(10, reducerange=true, mode=-1)
#Dither_Out()

Prefetch(4)


Zoomed comparison:
https://i.imgur.com/Zq9YCFf.jpg

Dehalo_alpha:
https://i.imgur.com/zyD02o9.jpg

BlindDehalo:
https://i.imgur.com/gpgno0q.jpg

"Source"
https://i.imgur.com/uehyE8t.jpg

the mods I did for avs+ HBD not for lsb hack, that why, it will work with lsb like any 8 bit filter

[mp3dom]

Is it expected that the output from SMDegrain is different between a lsb input and HBD input (with same settings obviously)?

[real.finder]

Is it expected that the output from SMDegrain is different between a lsb input and HBD input (with same settings obviously)?

it is

n16 give more or less same output as lsb (Depends on what settings you use, it should be same but there are some differences in how SMDegrain deal with both), but with HBD input will give different output.

well, there are some way to make it (with HBD input) less different (and faster) by using motion vector from 8 bit clip, back to old posts here for more info

[mp3dom]

Ok, but now I'm facing some "problems":
- with hbd input (lsmash->format yuv422p16->convertfromdoublewidth->p216), I can't use n16 (error: "MDegrainX out16 flag only for 8bit sources" - smdegrain line 545) so I guess it's a feature to ouput 8bit input to native hbd 16bit output.
- with the above hbd and prefilter 3 (uses dftttest) I get some damaged pictures. For "damaged" I mean really destroyed picture like missing objects. This doesn't happens with lsb input.

[real.finder]

Ok, but now I'm facing some "problems":
- with hbd input (lsmash->format yuv422p16->convertfromdoublewidth->p216), I can't use n16 (error: "MDegrainX out16 flag only for 8bit sources" - smdegrain line 545) so I guess it's a feature to ouput 8bit input to native hbd 16bit output.
- with the above hbd and prefilter 3 (uses dftttest) I get some damaged pictures. For "damaged" I mean really destroyed picture like missing objects. This doesn't happens with lsb input.

for 1st point, yes indeed, it's for 8bit input, lsb_in is not real anyway (we talk about that before)

for the 2nd one, that because dftttest not update yet for HBD

1 solution for both is using 8bit motion vector (you can also scale the 8bit vector to 16bit vector or Vice versa, but in your case you don't need that)

[real.finder]

new test (cuz it use test builds of avs+ and masktools (https://forum.doom9.org/showthread.php?p=1845370#post1845370)) update for SMDegrain https://pastebin.com/fU2a3Mqy

it should be faster in many cases in avs+ (will use avs+ expr), also there are new parameter "cplace" in SMDegrain_prefilters will affect prefilter 3

[mp3dom]

Ok, thanks.
Just one last question: without prefilter, is smdegrain (with hbd) working at real 16bit then?
With prefilter < 3 (uses Medianblur2) the output seems fine with hbd albeit medianblur2 afaik is not designed for hbd. Is it safe to assume that everything is running fine (and at real 16bit, or should I calculate 8bit vectors and apply to 16bit video?)

[real.finder]

Ok, thanks.
Just one last question: without prefilter, is smdegrain (with hbd) working at real 16bit then?
With prefilter < 3 (uses Medianblur2) the output seems fine with hbd albeit medianblur2 afaik is not designed for hbd. Is it safe to assume that everything is running fine (and at real 16bit, or should I calculate 8bit vectors and apply to 16bit video?)

real 16bit? with HBD I did no workaround so now some options will not work with HBD until it's plugins get update, lsb did use a lot of workarounds indeed, but not HBD or even n16 use any, so all things with HBD and n16 are "real" :)

for HBD, the only safe prefilter for now are -1 to 1 (2 need medianblur2 and it not updated yet for HBD), and 4, contrasharp=true may work with SD (with HD it use minblur with r=2 so it need medianblur2), also contrasharp=int usage will work if you use https://forum.doom9.org/showthread.php?t=174752

[mp3dom]

Many thanks again!

[Motenai Yoda]

Eru you can also generate and use your own HBD prefilter clip to feed into smdegrain

[tormento]

update for SMDegrain
Will you please, one day, update html doc too? :scared:

[pinterf]

new test (cuz it use test builds of avs+ and masktools (https://forum.doom9.org/showthread.php?p=1845370#post1845370)) update for SMDegrain https://pastebin.com/fU2a3Mqy

it should be faster in many cases in avs+ (will use avs+ expr), also there are new parameter "cplace" in SMDegrain_prefilters will affect prefilter 3
Masktools link updated to test8:
https://forum.doom9.org/showthread.php?p=1845370#post1845370
(mt_merge: cplace="mpeg2" now works for 4:2:2 as well, stacked 16 bit support (does anybody use it?) and make "mpeg2" default)

[danfgtn]

the mods I did for avs+ HBD not for lsb hack, that why, it will work with lsb like any 8 bit filter

Excuse my ignorance, but I can not understand. I thought hbd would directly imply a 16bit filtering, however I'm not understanding how hbd works without it. Could someone please explain to me how hbd works on an 8bit filter, and how does it differ from a standard 8 bit filter without it?

(And just to make sure I'm not confusing myself, hbd means high bit depth, right?)

[real.finder]

Will you please, one day, update html doc too? :scared:

not likely

Excuse my ignorance, but I can not understand. I thought hbd would directly imply a 16bit filtering, however I'm not understanding how hbd works without it. Could someone please explain to me how hbd works on an 8bit filter, and how does it differ from a standard 8 bit filter without it?

(And just to make sure I'm not confusing myself, hbd means high bit depth, right?)

yes, HBD = high bit depth

we used to say HBD to mention native avs+ Deep color (http://avisynth.nl/index.php/AviSynth%2B#Deep_color)

lsb (stacked) = hack, hack that use normal 8bit clip but with double Height

also avs+ HBD dont need any parameters to work unlike most lsb filters, nor need set bit depth like some lsb and double width filters, and work with multi bits in same function (filter) and that never and ever will be in lsb or double width, if filter support HBD then it work like you use the filter in 8bit mode (most of times)

[tormento]

SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2413356&viewfull=1#post2413356)
or the 3rd post here, see videohelp link and the top of script for the changes log
It doesn't point anymore to the latest version, i.e. 98s, that you sent on this forum only :o

[real.finder]

It doesn't point anymore to the latest version, i.e. 98s, that you sent on this forum only :o

yes, I didn't post it their for 2 reasons 1- it need more tests

2- it need another edits, since I was think the use_expr=2 mean always in avs+

[real.finder]

new update for SMDegrain https://forum.doom9.org/showthread.php?p=1790702#post1790702

[real.finder]

updates for: Abcxyz_MT2, VHSHaloremover, DeHaloH, DeHalo_alpha_mt2, FineDehalo, Masked_DHA, BlindDeHalo3_mt2 and FastLineDarkMOD

keep in mind they no fully optimized for speed yet, the updates manly for not get wrong output in new masktools (2.2.15 and up), and not use realtime and use avs+ expr instead for speedup, so yes it faster in many cases now but it need another optimize for every mt_lut* line by test use_expr=3 and so to see if it faster or slower since expr is not faster in most cases, but it's faster in some cases

[danfgtn]

Hello everyone!

I'm having problems with daa3mod, a horizontal of greenish pixels is appearing at the bottom of the video. When I use KNLMeans in any part of the script after daa3mod sometimes the frames seem to merge the chroma with the previous frame. When removing daa3 the frames return to normal with KNL, I do not know what one has to do with the other, but I noticed that.

I do not know if it's just coincidence, but when using a mod16 resolution the horizontal greenish pixels do not appear, however, the problem with KNL is not eliminated in that way.

Following are images of both problems:

"greenish" (https://images2.imgbox.com/d4/bb/esBv982L_o.png)
"chroma merge(?)" (https://images2.imgbox.com/72/ef/P1DMdFgm_o.png)
"What's going on here?" (https://images2.imgbox.com/3c/df/K46pwc9q_o.png)

Does anyone know a way to solve this? Sorry if this is not a problem with the filter, im a noob in avisynth.

Tests made in AvS+ r2728
masktools in the latest version

My Script (https://pastebin.com/jyb2zURN)


By Google Translate

[real.finder]

Hello everyone!

I'm having problems with daa3mod, a horizontal of greenish pixels is appearing at the bottom of the video. When I use KNLMeans in any part of the script after daa3mod sometimes the frames seem to merge the chroma with the previous frame. When removing daa3 the frames return to normal with KNL, I do not know what one has to do with the other, but I noticed that.

I do not know if it's just coincidence, but when using a mod16 resolution the horizontal greenish pixels do not appear, however, the problem with KNL is not eliminated in that way.

Following are images of both problems:

"greenish" (https://images2.imgbox.com/d4/bb/esBv982L_o.png)
"chroma merge(?)" (https://images2.imgbox.com/72/ef/P1DMdFgm_o.png)
"What's going on here?" (https://images2.imgbox.com/3c/df/K46pwc9q_o.png)

Does anyone know a way to solve this? Sorry if this is not a problem with the filter, im a noob in avisynth.

Tests made in AvS+ r2728
masktools in the latest version

My Script (https://pastebin.com/jyb2zURN)


By Google Translate

try without Prefetch(4)

[danfgtn]

try without Prefetch(4)

This works for daa3 + knl, however, the problem with the greenish pixels remains. What can this be? Or what am I doing wrong?

Removing the prefecht I disable MT, right? How much will this affect performance? Is it a good idea to keep the script without this?

[real.finder]

This works for daa3 + knl, however, the problem with the greenish pixels remains. What can this be? Or what am I doing wrong?

Removing the prefecht I disable MT, right? How much will this affect performance? Is it a good idea to keep the script without this?

yes it will not work with mt anymore and will affect performance, report this in avs+ Thread (https://forum.doom9.org/showthread.php?t=168856)

I do not know if it's just coincidence, but when using a mod16 resolution the horizontal greenish pixels do not appear

the greenish pixels maybe some asm code is broken somewhere, try with nnedi3 alone and see, if it same then report it in nnedi3 Thread (https://forum.doom9.org/showthread.php?t=170083) and also mention the cpu you have

[tormento]

@real.finder

I have a bit of confusion in my mind. From what I have learned, SMDegrain works internally with high bit precision.

If I want to feed the output to a 10 bit encoder such as x265 (instead of the usual 8 bit I feed x264 with), which flags and conversion should I use in a simple script?

[real.finder]

I don't use x265 but anyway maybe convertbits(10) in the last line of script will help you

[tormento]

I don't use x265 but anyway maybe convertbits(10) in the last line of script will help you
That will convert the SMDegrain 8 bit output to 10 bit. How is possible to tell SMDegrain to output directly to 10 bit?

[sneaker_ger]

http://avisynth.nl/index.php/SMDegrain#High_Bit_Depth_Processing_And_Dithering

So something like:
SMDegrain(lsb_out=true)
ConvertFromStacked() #convert from hacked stacked format to native AviSynth+ 16 bit format
ConvertBits(10, dither=0)

[tormento]

So something like:
[code]SMDegrain(lsb_out=true)
AFAIK lsb is now deprecated as it was a workaround. real.finder will tell us more :)

[sneaker_ger]

Hm, it seems you are correct. Not yet documented in the wiki.
now work basically with new high bit depth in avs+
now has new parameters bool n16 and bool n16_out
https://pastebin.com/u1xsPLwK

So then:
ConvertBits(16) # unless clip is 16 bit to begin with
SMDegrain()
ConvertBits(10, dither=0) # last step before output to 10 bit encoder
?

/edit:
I see it now has "n16" and "n16_out" parameters. Not sure how to use them.
https://forum.doom9.org/showthread.php?p=1837161#post1837161
:confused:

[tormento]

Hm, it seems you are correct. Not yet documented in the wiki.
Perhaps
SMDegrain(n16=true, n16_out=true)
ConvertBits(10, dither=0)

[sneaker_ger]

No, probably my example in post #209 is correct. Not really sure what the n16 stuff is about. I think maybe it is for stacked output but with AviSynth+ native functions instead of the dither package. So basically in case you want to other, old filters that don't do native 16 bit.

[real.finder]

Perhaps
SMDegrain(n16=true, n16_out=true)
ConvertBits(10, dither=0)

this one ok, example in post #209 is ok too but it's slower, you can replace ConvertBits(16) with ConvertBits(10) for more speed and ofc remove the last one, unless your clip is 10bit or higher then no need to use any converter function

[real.finder]

Not really sure what the n16 stuff is about. I think maybe it is for stacked output but with AviSynth+ native functions instead of the dither package. So basically in case you want to other, old filters that don't do native 16 bit.

n16 work like lsb but the output is 16 bit native, and it's faster than lsb with more or less almost same output (go back to older posts here to see why if you interested :) )

[tormento]

you can replace ConvertBits(16) with ConvertBits(10) for more speed
Let me understand:

if I feed 8 bit video to SMDegrain with no ConvertBits before but n16=true, how does it works internally? 8/10/16?
If I use ConvertBits(x) before AND I use n16=true, which bit precision does it uses internally?
If I use ConvertBits(x) before with NO n16, which bit precision does it uses internally?

I'd like you to kindly cast light on some of the input/engine/output bitdepth, perhaps with some examples too.

[real.finder]

Let me understand:

if I feed 8 bit video to SMDegrain with no ConvertBits before but n16=true, how does it works internally? 8/10/16?
If I use ConvertBits(x) before AND I use n16=true, which bit precision does it uses internally?
If I use ConvertBits(x) before with NO n16, which bit precision does it uses internally?

I'd like you to kindly cast light on some of the input/engine/output bitdepth, perhaps with some examples too.

irc mvtools and most avs filters use more bits internally than 8 bit for 8bit clips, anyway if you test yourself you will know that n16 don't work with anything other than 8bit in first place

n16 (out16) and lsb are almost same, and use same bit precision and irc which is not same as using 16 bit input (whether it's original 16 bit clip or by using ConvertBits(16) before the function)

you should ask pinterf for more informations :) or back to his posts about lsb vs HBD input in mvtools MDegrain

[pinterf]

irc mvtools and most avs filters use more bits internally than 8 bit for 8bit clips, anyway if you test yourself you will know that n16 don't work with anything other than 8bit in first place

n16 (out16) and lsb are almost same, and use same bit precision and irc which is not same as using 16 bit input (whether it's original 16 bit clip or by using ConvertBits(16) before the function)

you should ask pinterf for more informations :) or back to his posts about lsb vs HBD input in mvtools MDegrain
In MDegrain inputs of 8 bit precision are becoming 16 bit precision internally. This intermediate result is either kept as 16 bits when out16=true or lsb=true is used or truncated back to give a 8 bit result. out16=true in MDegrain accepts only 8 bit video input.

Using 10-16 bit inputs MDegrain works at a higher internal precision and will scale the result back to the bit depth of the input. Similarly 32 bit float inputs will be kept being float.
In any case, motion vectors would come from analyzing clips of different bit depth.

[tormento]

In MDegrain inputs of 8 bit precision are becoming 16 bit precision internally.
So, if the input is 8 bit, which is the best way to get a 10 bit output? Use out16= true and then convertbits(10) or convert to 10 bit before mdegrain and allow it to output same bitdepth?

[pinterf]

ConvertBits(10)->Degrain() must be equally good as Degrain(out16=true)->ConvertBits(10)
Maybe when overlap is used the out16=true option offers theoretically better precision, because the items taking part in the weighted averaging overlap calculation are of 16 bits precision instead of 10 bits. (Provided we can talk about precision on a filter of which purpose is smearing the details)
But ConvertBits(16)->Degrain()->ConvertBits(10) should have the same quality as Degrain(out16=true)->ConvertBits(10)

[tormento]

But ConvertBits(16)->Degrain()->ConvertBits(10) should have the same quality as Degrain(out16=true)->ConvertBits(10)
:thanks:

[real.finder]

if anyone interested, I made an update to mpp (MP_Pipeline) using last code from official github https://github.com/SAPikachu/MP_Pipeline

there are two changes aside from support old avs mt, one is "Add support for specifying cores", and the 2nd one is "Fix crash on systems with many CPUs"

you can get it from here https://github.com/realfinder/MP_Pipeline/releases

[gugglu]

if anyone interested, I made an update to mpp (MP_Pipeline) using last code from official github https://github.com/SAPikachu/MP_Pipeline

there are two changes aside from support old avs mt, one is "Add support for specifying cores", and the 2nd one is "Fix crash on systems with many CPUs"

you can get it from here https://github.com/realfinder/MP_Pipeline/releases

Can you please write one example how to use core future?

this is my script i've tried with ### cores:4 at the end of script, can you clear this to me am i ordering it correct or not , thanks.

o = last

mb1 = o.minblur(1)

mb2 = o.mt_adddiff(mt_makediff(mb1,mb1.removegrain(4)))

ss = seesaw(o, mb2, ssx=1.30, ssy=1.30)

rep = ss.repair(o,1,1,1,false)

mt_lutxy (o, rep, expr="x y < y 1 - x y > y 1 + y ? ?", y=3, u=3, v=3)

Can you please check my 8-bit process and i think it needs some correction. if possible pls look below mt_adddiff(mt_makediff(mb1,mb1.removegrain(4))) i tried seesaw / repair / mt_lutxy i think they need swapping up or down with each other i tried replacing them what not sure where thats how they should be placed or need correction. i would be greatly thankful to you if you clear this illusion in script.i have 14Core/28thread cpu i need an script example for

thanks a ton ,your efforts are very much appreciated.

[real.finder]

it's just the old
### lock threads to cores

but now you can set the thread/core like this

mp_pipeline("""
### platform
1st block here
### lock threads to cores 1
### ###
### platform
2nd block here
### lock threads to cores 2
### ###
""")

and so, and ofc you can use another threads/cores as you like

Regarding 8-bit process Question, it's off topic but anyway seesaw need denoised clip in 2nd clip input, o.mt_adddiff(mt_makediff(mb1,mb1.removegrain(4))) give sharp noisily output

aside from that why you still use lsb not the native clean and fast HBD in avs+?

[gugglu]

it's just the old
### lock threads to cores

but now you can set the thread/core like this

mp_pipeline("""
### platform
1st block here
### lock threads to cores 1
### ###
### platform
2nd block here
### lock threads to cores 2
### ###
""")

and so, and ofc you can use another threads/cores as you like

Regarding 8-bit process Question, it's off topic but anyway seesaw need denoised clip in 2nd clip input, o.mt_adddiff(mt_makediff(mb1,mb1.removegrain(4))) give sharp noisily output

aside from that why you still use lsb not the native clean and fast HBD in avs+?

Hello, and sorry for late reply (it is my working hour very long).thanks for the example.i have done two test on my laptop both works.

mp_pipeline("""

### platform:win32
### dll:avisynth.dll

Setmemorymax(1536)

DGDecode_mpeg2source("C:\Users\Kalik\Videos\VTS.d2v", cpu=4, info=3)

ColorMatrix(hints=true, threads=0)

crop(2, 66, 0, -66)
### prefetch:128,32
### lock threads to cores: 2
### ###

### platform:win64
### dll:avisynth.dll

setmemorymax(2048)

SMDegrain(Tr=3)
### prefetch:64,16
### lock threads to cores: 2
### ###
""")
or
mp_pipeline("""

### platform:win32
### dll:avisynth.dll

Setmemorymax(1536)

DGDecode_mpeg2source("C:\Users\Kalik\Videos\VTS.d2v", cpu=4, info=3)

ColorMatrix(hints=true, threads=0)

crop(2, 66, 0, -66)
### prefetch:128,32
### lock threads to cores 2
### ###

### platform:win64
### dll:avisynth.dll

setmemorymax(2048)

SMDegrain(Tr=3)
### prefetch:64,16
### lock threads to cores 2
### ###
""")

AVS+ Native HBD perform better gives nicer output, but i don't know any Debanding filter which works with Avs+ Native HBD so i can stick that just after smdegrain this is why i use lsb thing some time(but i tried Avs+ Native HBD and to be honest i like the result more than the lsb ting).

Please can you correct this if u have some free time , i've core-i9 7940x 14cores/28threads only thing where i get confused ### lock threads to cores , do i have to type cores number or threads number? thanks for your precious work i really like mp_pipeline and i use it every time i encode any clip.

mp_pipeline("""

### platform:win32
### dll:avisynth.dll

Setmemorymax(1536)

DGDecode_mpeg2source("C:\Users\Kalik\Videos\VTS.d2v", cpu=4, info=3)

ColorMatrix(hints=true, threads=0)

crop(2, 66, 0, -66)
### prefetch:128,32
### lock threads to cores 14
### ###

### platform:win64
### dll:avisynth.dll

setmemorymax(2048)

SMDegrain(Tr=3)
### prefetch:64,16
### lock threads to cores 14
### ###
""")

[real.finder]

from the old read me of mpp

### lock threads to cores

Slave processes with this statement will lock their worker threads into a core. This may improve performance for some scripts.

Core selection is on a round-robin manner, with awareness of hyper-threading.


the new change is

Affinity: Add support for specifying cores

so every block should has different number (or using some threads/cores that has no heavy load, mean you can balance that in which way make the script run faster), and those numbers should be up to cores counts (or maybe threads, you should ask a Developer :) ) in the cpu

the old mpp as the read me said, does it automatically I think, maybe even in the new one still does that if not specified by user


and Regarding
### lock threads to cores 2
vs
### lock threads to cores: 2

I think the 1st one is the correct as I understand from the Source code, the 2nd one may act like old method (ignore the number) or maybe work as it should, see what you got in the task manager in windows

[real.finder]

AVS+ Native HBD perform better gives nicer output, but i don't know any Debanding filter which works with Avs+ Native HBD so i can stick that just after smdegrain this is why i use lsb thing some time(but i tried Avs+ Native HBD and to be honest i like the result more than the lsb ting).


you can use flash3kyuu_deband, it's can use interleaved format which is like Native in speed, https://f3kdb.readthedocs.io/en/latest/usage.html#cmdoption-arg-input-mode with using ConvertToDoubleWidth() (http://avisynth.nl/index.php/ConvertStacked#Syntax_and_Parameters) in avs+

[real.finder]

SMDegrain update
new divide parameter (Dogway) and some edits for avs+ and avs neo cases and some others changes

---

there are many of my scripts already use some method for avs+ detection since years, but unfortunately it not work with avs neo so updates will come soon for those, and from now on you will need SMDegrain.avsi more than ever since it have the IsAvsNeo() (https://forum.doom9.org/showthread.php?p=1865978#post1865978), IsAvsPlus() and AvsPlusVersionNumber() (https://forum.doom9.org/showthread.php?p=1865958#post1865958) functions. why? (https://forum.doom9.org/showthread.php?p=1805621#post1805621)

[real.finder]

almost all filters updated, and SMDegrain.avsi is needed now for many scripts since it have the IsAvsNeo(), IsAvsPlus() and AvsPlusVersionNumber() functions

[StainlessS]

Thankyou RF for you continued work, I'm gonna have to steal some of your code, so thanx in advance. :)

[ChaosKing]

Thx for the update(s).

[Vitality]

also AKA A.SONY's Avisynth Stuff

note:- SMDegrain.avsi (v3.1.2.101s or up) is needed now for many scripts since it have the IsAvsNeo(), IsAvsPlus() and AvsPlusVersionNumber() functions. why? (https://forum.doom9.org/showthread.php?p=1805621#post1805621)

DeHalo_alpha_MT2 (https://pastebin.com/uB6Pynhr)


I have SMDegrain v3.1.2.101s but I still get the AvsPlusVersionNumber() missing error with DeHalo_alpha_MT2.

https://i.imgur.com/uI7sphJ.png

[real.finder]

I did update dfttestMC (now "dfttestMC and MC things")

there are new mcKNLMeansCL(), you can also try with sMCwarper(prefilter=1,"SMDegrain_KNLMeansCL(d=2)")

edit: there was some bug, re-download it

[tormento]

I did update dfttestMC (now "dfttestMC and MC things")
Well, we need a OpenCL DFTtest :eek:

[Natty]

i recently upgraded to ryzen + radeon. i am getting weird frames while using knlmeans prefilter in smdegrain like this

https://i.imgur.com/YL2rHpH.jpg

it didnt happen in intel + nvidia... is there any solution ?

[real.finder]

i recently upgraded to ryzen + radeon. i am getting weird frames while using knlmeans prefilter in smdegrain like this

https://i.imgur.com/YL2rHpH.jpg

it didnt happen in intel + nvidia... is there any solution ?

other prefilter's work fine? if not then it's mvtools problem, if they work fine then it's knlmeans

[Natty]

other prefilter's work fine? if not then it's mvtools problem, if they work fine then it's knlmeans

yes prefilter 2 and 3 work fine.. even prefilter 4 works good in normal noised sources.. craps out on too noisy sources.

[tormento]

new SMDegrain edit
I hope some day you will release changelog with new versions :p

[real.finder]

I hope some day you will release changelog with new versions :p

too late for that, anyway I did in the top of script for most new things, other updates mostly for bug fix, the last update for this (https://forum.doom9.org/showthread.php?p=1875574#post1875574)

[Zetti]

https://i.imgsafe.org/62/629550ec88.jpeg

I can't choose Prefilter4 in AvsPmod

Can it be a bug??

Edit I forgot to mention i use SMDegrain v3.1.2.102s

[real.finder]

https://i.imgsafe.org/62/629550ec88.jpeg

I can't choose Prefilter4 in AvsPmod

Can it be a bug??

Edit I forgot to mention i use SMDegrain v3.1.2.102s

this in avspmod? you should report it in avsp Thread

[ChaosKing]

https://i.imgsafe.org/62/629550ec88.jpeg

I can't choose Prefilter4 in AvsPmod

Can it be a bug??

Edit I forgot to mention i use SMDegrain v3.1.2.102s

The profile/config for smdegrain needs to be updated in avsp mod. This is a manual task and can't be detected automatically as far as I know.

[Groucho2004]

The profile/config for smdegrain needs to be updated in avsp mod. This is a manual task and can't be detected automatically as far as I know.This can easily be done in a text editor ("filterdb.dat", search for smdegrain and change "int "prefilter"=0 (0 / 1 / 2 / 3)," to "int "prefilter"=0 (0 / 1 / 2 / 3 / 4),".

[Zetti]

Thank You, Working Fine.

[Natty]

thanks for your collection i have been playing with it recently and have some questions

https://pastebin.com/CcMxX3xG - your FineDehalo. is it optimized for 16bit? because when i run ConvertBits(16).FineDehalo() it runs atleast 50% slower is it normal? same for your other filters. results are impressive when using whole script in native HBD but its so slow that its not usable.

will u update f3kdb for native high bit depth?

and i need your help in selective debanding.

for example. i use this for full clip.

f3kdb(range=30, y=50, Cb=50, Cr=50, grainY=50, grainC=50, keep_tv_range=true)

but i want to put more grain in some complex large flat and dark scenes only. how can i do that?

hoping for faster HBD filters in future. thanks for all your collection. i use most of them. :thanks::helpful:

[real.finder]

thanks for your collection i have been playing with it recently and have some questions

https://pastebin.com/CcMxX3xG - your FineDehalo. is it optimized for 16bit? because when i run ConvertBits(16).FineDehalo() it runs atleast 50% slower is it normal? same for your other filters. results are impressive when using whole script in native HBD but its so slow that its not usable.

will u update f3kdb for native high bit depth?

and i need your help in selective debanding.

for example. i use this for full clip.

f3kdb(range=30, y=50, Cb=50, Cr=50, grainY=50, grainC=50, keep_tv_range=true)

hoping for faster HBD filters in future. thanks for all your collection. i use most of them. :thanks::helpful:

yes many filters updated to work with HBD, and it will be slower than 8bit ofc

f3kdb is not a script so I can't, you should ask someone else for it :) but anyway you can use Double-Width hack (http://avisynth.nl/index.php/ConvertStacked) for it

but i want to put more grain in some complex large flat and dark scenes only. how can i do that?

that can be done with masktools, there are already many examples around, you can search in https://forum.doom9.org/showthread.php?t=98985

[ChaosKing]

but i want to put more grain in some complex large flat and dark scenes only. how can i do that?

You could try LumaDB http://avisynth.nl/index.php/External_filters#Debanding
Click also on the discussion link.

[Natty]

thank you r.f and chaos, i will test and read about it.

[Natty]

LSFmod (https://forum.doom9.org/showthread.php?t=174752)


this this the latest version ?

https://pastebin.com/pzACBAX1

:thanks:

[real.finder]

this this the latest version ?

https://pastebin.com/pzACBAX1

:thanks:

yes it is

[DarkNite]

Getting script error: Invalid arguments to function 'mt_convolution' for lines 18, 59, and 71 of the 2019.07.12 mod of DDComb. Typo in sbrV?

[real.finder]

Getting script error: Invalid arguments to function 'mt_convolution' for lines 18, 59, and 71 of the 2019.07.12 mod of DDComb. Typo in sbrV?

work fine here, what is your full script?

[real.finder]

scripts state for float (32bit) chroma for now:-

aside from smaskmerge, in SMDegrain, Dither_Luma_Rebuild and SMDegrain_prefilters mode 3 both will give wrong output in chroma

but since mode 3 use Dfttest not work with float (32bit) yet this is not a big problem, Dither_Luma_Rebuild can be used in many scripts so it's problem for now, avoid use float (32bit) with it if you processes chroma


qtgmc in other hand has no problem but since there are a bug (https://forum.doom9.org/showpost.php?p=1879220&postcount=4802)


will see the other scripts soon and then report back

edit: the same bug in qtgmc float (32bit) can be in other scripts

[real.finder]

updates for FineDehalo, BalanceBorders, LSFmod, FastLineDarkenMOD, Masked_DHA, BlindDeHalo3 and DeHalo_alpha

all update are some changes in LUT things, mainly for speed up float (32bit)

[dREV]

I need to double post as the character limit is preventing me to place the script within one post.

Thanks for the updates. I am having issues with DebilinearM still. I'm guessing it maybe due to not being able to get the latest ResizeX_v1.0.1 mod 9 as it's still pending for approval so I only got mod 7. Would it be possible to provide a pastebin?

I'm receiving the following in avspmod: ResizeX does not have a named argument "dither_mode" (C: path\plugins64+\DebilinearM_v1.3.1_mod1.25.avsi, line 78) (New File, line 95).

Another subject. As mentioned on the ResampleMT thread, https://forum.doom9.org/showthread.php?p=1879189#post1879189 I came about this script just a few days ago but it's been available since 2016. Haven't seen it on any Doom9 thread for Avisynt just VaporSynth. It uses DebilinearM and Debilinear.dll for both versions of AviSynth x86 not sure for 64 bit.

This script, Gradfun3mod (https://forum.doom9.org/showthread.php?p=1879765#post1879765) I've been implementing it like so: dither_convert_8_to_16()
ly = GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

The issue thus far I've found is that for resolutions 1920x1080 > 1280x720 like say a old show in 4:3 with black borders it'll create a 1 pixel artifact on all 4 sides that even ContinuityFixer / EdgeFixer http://avisynth.nl/index.php/EdgeFixer won't be able to fix. I had to get around this by adding nnedi3_resize16(960, 720,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64") below YtoUV(lu,lv,ly).

I'm not asking for anything but this if you may be interested in modifying this to work with your updated DebilinearM script using the ResampleMT plugin for Avisynth+.

Also, about this n16 matter. Is there a documentation about this? I like to know more as if I understood correctly this n16 is true 16 bit and not the somewhat fake 16 bit of lsb and how would I turn it off going 8 bit. Is there an new method of going:
dither_convert_8_to_16()
DitherPost(mode=6)
& to end Dither_out()

Thanks for your time.

:script: :helpful:

[dREV]

:stupid:

The script is called Gradfun3mod. https://pastebin.com/0mkhsimh
##################################################################################################################
#
# High bitdepth tools for Avisynth - GradFun3mod r6
# based on Dither v1.27.1
# Author: Firesledge, slightly modified by Gebbi
#
# What?
# - This is a slightly modified version of the original GradFun3.
# - It combines the usual color banding removal stuff with resizers during the process
# for sexier results (less detail loss, especially for downscales of cartoons).
# - This is a starter script, not everything is covered through parameters. Modify it to your needs.
#
# Requirements (in addition to the Dither requirements):
# - AviSynth 2.6.x
# - Debilinear, Debicubic, DebilinearM
# - NNEDI3 + nnedi3_resize16
#
# Changes from the original GradFun3:
# - yuv444 = true
# (4:2:0 -> 4:4:4 colorspace conversion, needs 1920x1080 input)
# - resizer = [ "none", "Debilinear", "DebilinearM", "Debicubic", "DebicubicM", "Spline16",
# "Spline36", "Spline64", "lineart_rpow2", "lineart_rpow2_bicubic" ]
# (use it only for downscales)
# NOTE: As of r2 Debicubic doesn't have 16-bit precision, so a Y (luma) plane fix by torch is used here,
# more info: https://mechaweaponsvidya.wordpress.com/2015/07/07/a-precise-debicubic/
# Without yuv444=true Dither_resize16 is used with an inverse bicubic kernel.
# - w = 1280, h = 720
# (output width & height for the resizers; or production resolution for resizer="lineart_rpow2")
# - smode = 4
# (the old GradFun3mod behaviour for legacy reasons; based on smode = 1 (dfttest);
# not useful anymore in most cases, use smode = 2 instead (less detail loss))
# - deb = true
# (legacy parameter; same as resizer = "DebilinearM")
#
# Usage examples:
# - Source is bilinear 720p->1080p upscale (BD) with 1080p credits overlayed,
# revert the upscale without fucking up the credits:
# lwlibavvideosource("lol.m2ts")
# GradFun3mod(smode=1, yuv444=true, resizer="DebilinearM")
#
# - You just want to get rid off the banding without changing the resolution:
# GradFun3(smode=2)
#
# - Source is 1080p production (BD), downscale to 720p:
# GradFun3mod(smode=2, yuv444=true, resizer="Spline36")
#
# - Source is a HDTV transportstream (or CR or whatever), downscale to 720p:
# GradFun3mod(smode=2, resizer="Spline36")
#
# - Source is anime, 720p->1080p upscale, keep the resolution
# but with smoother lineart instead of bilinear upscaled shit:
# GradFun3mod(smode=2, resizer="lineart_rpow2")
# This won't actually resize the video but instead mask the lineart and re-upscale it using
# nnedi3_rpow2 which often results in much better looking lineart (script mostly by Daiz).
#
# Note: Those examples don't include parameters like thr, radius, elast, mode, ampo, ampn, staticnoise.
# You probably don't want to use the default values.
# For 16-bit output use:
# GradFun3mod(lsb=true).Dither_out()
#
# What's the production resolution of my korean cartoon?
# - Use your eyes combined with Debilinear(1280,720) - if it looks like oversharped shit,
# it was probably produced in a higher resolution.
# - Use Debilinear(1280,720).BilinearResize(1920,1080) for detail loss search.
# - Alternatively you can lookup the (estimated) production resolution at
# http://anibin.blogspot.com (but don't blindly trust those results)
#
# This program is free software. It comes without any warranty, to
# the extent permitted by applicable law. You can redistribute it
# and/or modify it under the terms of the Do What The Fuck You Want
# To Public License, Version 2, as published by Sam Hocevar. See
# http://sam.zoy.org/wtfpl/COPYING for more details.
#
##################################################################################################################


Function GradFun3mod (clip src, float "thr", int "radius", float "elast",
\ int "mask", int "mode", float "ampo", float "ampn", int "pat",
\ bool "dyn", float "dthr", int "smode", float "wmin", float "thr_det",
\ float "thr_edg", int "debug", int "subspl", bool "lsb", bool "lsb_in",
\ bool "staticnoise", float "thrc", int "radiusc", float "elastc",
\ int "y", int "u", int "v", clip "ref", bool "slice", bool "yuv444", int "w", int "h", string "resizer", bool "deb")
{
thr = Default (thr, 0.35)
thrc = Default (thrc, thr)
radius = Default (radius, 12)
radiusc = Default (radiusc, radius)
elast = Default (elast, 3.0)
elastc = Default (elastc, elast)
mask = Default (mask, 2)
smode = Default (smode, 2)
wmin = Default (wmin, 1.0)
thr_det = Default (thr_det, 2 + Round (Dither_max (thr - 0.35, 0) / 0.3))
debug = Default (debug, 0)
subspl = Default (subspl, 0)
lsb = Default (lsb, false)
lsb_in = Default (lsb_in, false)
ref = Default (ref, src)
yuv444 = Default (yuv444, false)
w = Default (w, 1280)
h = Default (h, 720)
resizer = Default (resizer, "none")
deb = Default (deb, false)


# Do lineart smoothing first for sharper results

ow = src.Width()
oh = src.Height()

src = (resizer == "lineart_rpow2") ? lineart_rpow2(src, w, h, ow, oh, false)
\ : (resizer == "lineart_rpow2_bicubic") ? lineart_rpow2(src, w, h, ow, oh, true)
\ : src

# Input range check. The other parameters are checked by the plugins.
Assert (radius > 0, "GradFun3: "+chr(34)+"radius" +chr(34)+" must be strictly positive.")
Assert (radiusc > 0, "GradFun3: "+chr(34)+"radiusc"+chr(34)+" must be strictly positive.")
Assert (thr > 0, "GradFun3: "+chr(34)+"thr" +chr(34)+" must be strictly positive.")
Assert (thrc > 0, "GradFun3: "+chr(34)+"thrc" +chr(34)+" must be strictly positive.")
Assert (thr_det > 0, "GradFun3: "+chr(34)+"thr_det"+chr(34)+" must be strictly positive.")
Assert (elast >= 1, "GradFun3: "+chr(34)+"elast" +chr(34)+" must be greater or equal to 1.")
Assert (elastc >= 1, "GradFun3: "+chr(34)+"elastc" +chr(34)+" must be greater or equal to 1.")
(yuv444 && resizer != "lineart_rpow2" && resizer != "lineart_rpow2_bicubic") ? Assert (w == 1280, "GradFun3mod: Output resolution must be 1280x720 when using 4:4:4 colorspace.") : true
(yuv444 && resizer != "lineart_rpow2" && resizer != "lineart_rpow2_bicubic") ? Assert (h == 720, "GradFun3mod: Output resolution must be 1280x720 when using 4:4:4 colorspace.") : true

src_8 = (lsb_in) ? src.DitherPost (mode=-1) : src
src_16 = (lsb_in) ? src : src.Dither_convert_8_to_16 ()
ref_16 = (lsb_in) ? ref : ref.Dither_convert_8_to_16 ()
yv411_flag = src.Dither_isyv411 ()

# Main debanding

yp = (! Defined (y) || (y == 3)) ? 3 : 1
up = (! Defined (u) || (u == 3)) ? 3 : 1
vp = (! Defined (v) || (v == 3)) ? 3 : 1

chroma_flag = ( (thrc != thr || radiusc != radius || elastc != elast)
\ && yp == 3 && (up == 3 || vp == 3))
up2 = (chroma_flag) ? 1 : up
vp2 = (chroma_flag) ? 1 : vp

src_16
flt_y = Dither_gf3_smooth_mod (last, src_8, ref_16, smode, radius, thr, elast, lsb_in, wmin, subspl, yp, up2, vp2)
flt_c = (chroma_flag) ? Dither_gf3_smooth_mod (last, src_8, ref_16, smode, radiusc, thrc, elastc, lsb_in, wmin, subspl, 1, up, vp) : flt_y
flt = (chroma_flag) ? flt_y.MergeChroma (flt_c) : flt_y

# Edge/detail mask

td_lo = Dither_max (thr_det * 0.75, 1)
td_hi = Dither_max (thr_det, 1)
mexpr = Dither_make_expr_gate (td_lo, td_hi)

dmask = (mask > 0 && yv411_flag) ? src_8.ConvertToY8 () : src_8
dmask = (mask > 0) ? dmask.Dither_build_gf3_range_mask (mask) : dmask
dmask = (mask > 0) ? dmask.mt_lut (expr=mexpr) : dmask
dmask = (mask > 0) ? dmask.Dither_removegrain_emul (22, -1) : dmask
dmask = (mask > 1) ? dmask.Dither_removegrain_emul (11, -1) : dmask
dmask = (mask > 2) ? dmask.Dither_removegrain_emul (20, -1) : dmask
dmask = (mask > 0 && yv411_flag) ? dmask.ConvertToYV411 () : dmask

res_16 = (mask > 0) ? Dither_merge16_8 (flt, src_16, dmask, luma=true, y=yp, u=up, v=vp) : flt

# Resizing / colorspace conversion (GradFun3mod)

resizer = (deb) ? "DebilinearM" : resizer
resizer = (yuv444 && resizer == "none") ? "Spline36" : resizer

rkernel = (resizer == "Debilinear" && yuv444) ? res_16.DebilinearY(w,h,lsb_inout=true)
\ : (resizer == "Debilinear") ? res_16.Debilinear(w,h,lsb_inout=true)
\ : (resizer == "DebilinearM" && yuv444) ? res_16.DebilinearM(w,h,lsb_inout=true,chroma=false)
\ : (resizer == "DebilinearM") ? res_16.DebilinearM(w,h,lsb_inout=true)
\ : (resizer == "Debicubic" && yuv444) ? res_16.debicubicy_precise(w,h)
\ : (resizer == "Debicubic") ? res_16.Dither_resize16(w,h,kernel="bicubic",invksh=true,fh=1.3,fv=1.3,invkstaps=7)
\ : (resizer == "DebicubicM" && yuv444) ? res_16.DebicubicM_precise16(w,h,chroma=false)
\ : (resizer == "DebicubicM") ? res_16.DebicubicM_precise16(w,h)
\ : (resizer == "Spline16" && yuv444) ? res_16.Dither_resize16(w,h,kernel="spline16",fh=1.2,fv=1.2).ConvertToY8()
\ : (resizer == "Spline16") ? res_16.Dither_resize16(w,h,kernel="spline16",fh=1.2,fv=1.2)
\ : (resizer == "Spline36" && yuv444) ? res_16.Dither_resize16(w,h,kernel="spline36",fh=1.2,fv=1.2).ConvertToY8()
\ : (resizer == "Spline36") ? res_16.Dither_resize16(w,h,kernel="spline36",fh=1.2,fv=1.2)
\ : (resizer == "Spline64" && yuv444) ? res_16.Dither_resize16(w,h,kernel="spline64",fh=1.2,fv=1.2).ConvertToY8()
\ : (resizer == "Spline64") ? res_16.Dither_resize16(w,h,kernel="spline64",fh=1.2,fv=1.2)
\ : ((resizer == "lineart_rpow2" || resizer == "lineart_rpow2_bicubic") && yuv444) ? res_16.Dither_resize16(1280,720,kernel="spline36",fh=1.2,fv=1.2).ConvertToY8()
\ : (resizer == "lineart_rpow2" || resizer == "lineart_rpow2_bicubic") ? res_16
\ : (resizer == "none") ? res_16
\ : Assert (false, "GradFun3mod: wrong resizer value.")

ly = rkernel
lu = res_16.utoy8().Dither_resize16(1280, 720, src_left=0.25, kernel="blackman")
lv = res_16.vtoy8().Dither_resize16(1280, 720, src_left=0.25, kernel="blackman")
(yuv444) ? ytouv(lu,lv,ly) : rkernel

# Dithering

result = (lsb) ? last : last.DitherPost (
\ mode=mode, ampo=ampo, ampn=ampn, pat=pat, dyn=dyn,
\ prot=false, thr=dthr, staticnoise=staticnoise,
\ y=yp, u=up, v=vp, slice=slice
\ )
result = (lsb)
\ ? Dither_switch_planes16 (src_16, result, y=y, u=u, v=v)
\ : Dither_switch_planes8 (src_8, result, y=y, u=u, v=v)

(debug == 1 ) ? dmask.GreyScale () : result
(debug == 1 && lsb) ? Dither_convert_8_to_16 () : last
}



Function Dither_gf3_smooth_mod (clip src_16, clip src_8, clip ref_16, int smode, int radius, float thr, float elast, bool lsb_in, float wmin, int subspl, int yp, int up, int vp)
{
src_16
(smode == 0) ? Dither_gf3_smoothgrad_multistage (ref_16, radius, thr, elast, yp, up, vp)
\ : (smode == 1) ? Dither_gf3_dfttest (src_8, ref_16, radius, thr, elast, lsb_in, yp, up, vp)
\ : (smode == 2) ? Dither_gf3_bilateral_multistage (ref_16, radius, thr, elast, wmin, subspl, yp, up, vp)
\ : (smode == 3) ? Dither_gf3_smoothgrad_multistage_3 (radius, thr, elast, yp, up, vp)
\ : (smode == 4) ? Dither_gf3_dfttest_mod (src_8, ref_16, radius, thr, elast, lsb_in, yp, up, vp)
\ : Assert (false, "GradFun3mod: wrong smode value.")
}



# Valid values for y, u and v: 1 and 3
Function Dither_gf3_dfttest_mod (clip src, clip src_8, clip ref,
\ int radius, float thr, float elast, bool lsb_in,
\ int y, int u, int v)
{
Assert (radius <= 128, "GradFun3: max "+chr(34)+"radius" +chr(34)+" value is 128 when smode = 1.")

hrad = Dither_max (radius * 3 / 4, 1)

(lsb_in) ? src : src_8

dfttest (
\ sigma=thr*12, tbsize=1,
\ sbsize=hrad*4, sosize=hrad*3,
\ lsb=true, lsb_in=lsb_in,
\ Y=(y==3), U=(u==3), V=(v==3)
\ )

Dither_limit_dif16 (last, ref, thr=thr, elast=elast, y=y, u=u, v=v)
}

Function lineart_rpow2 (clip src, int w, int h, int ow, int oh, bool bicubic)
{
w = default(w, 1280)
h = default(h, 720)
ow = default(ow, 1920)
oh = default(oh, 1080)
bicubic = default(bicubic, false)

orig = src
(bicubic) ? DebicubicM(src, w, h) : DebilinearM(src, w, h)
nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=ow, fheight=oh)
edges = last.mt_edge("prewitt", 4, 24, 4, 24, chroma="true").removegrain(20, 1)
sharp = last
mt_merge(orig, sharp, edges)
}

Function debicubicy_precise(clip src, int dst_width, int dst_height, float "src_left", float "src_top", float "src_width", float "src_height")
{
# script by torch

sw = src.width()
sh = src.height()/2
src_left = default(src_left, 0.0)
src_top = default(src_top, 0.0)
src_width = default(src_width, sw)
src_height = default(src_height, sh)

inv_left = -src_left * dst_width/src_width
inv_top = -src_top * dst_height/src_height
inv_width = (sw-src_left) * dst_width/src_width
inv_height = (sh-src_top) * dst_height/src_height

seed = debicubicy(src, dst_width, dst_height, src_left, src_top, src_width+src_left, src_height+src_top, lsb_inout=true)
up = seed.dither_resize16(sw, sh, inv_left, inv_top, inv_width, inv_height, kernel="bicubic", fh=-1.0, fv=-1.0)
diff = dither_sub16(src, up, dif=true).dither_lut16("x 32768 - 99 * 32768 +")
down = diff.debicubicy(dst_width, dst_height, src_left, src_top, src_width+src_left, src_height+src_top, lsb_inout=true)
down = down.dither_lut16("x 32768 - 99 / 32768 + round")

return seed.dither_add16(down, dif=true)
}

Function DebicubicM_precise16(clip input, int target_width, int target_height, bool "chroma")
{
# based on DebilinearM v1.3.1

Assert(target_width > 0, "GradFun3mod: target width must be greater than 0")
Assert(target_height > 0, "GradFun3mod: target height must be greater than 0")

thr = 10
expand = 1
inflate = 2
kernel = "Spline36"
chroma = Default(chroma, true)

w = input.Width()
h = input.Height()/2
uvint = chroma ? 3 : 1

# Resizing
input_8bit = input.DitherPost(mode=-1)
dbi = chroma ? input.Dither_resize16(target_width,target_height,kernel="bicubic",invksh=true,fh=1.3,fv=1.3,invkstaps=7)
\ : input.debicubicy_precise(target_width,target_height)
dbi_8bit = chroma ? input_8bit.Debicubic(target_width,target_height)
\ : input_8bit.DebicubicY(target_width,target_height)
dbi2 = dbi_8bit.ResizeX(w,h, kernel="Bicubic", chroma=chroma)
rs = input.ResizeX(target_width,target_height, kernel=kernel, chroma=chroma, lsb_in=true, lsb=true)

# Masking
diffmask = mt_lutxy(input_8bit,dbi2, "x y - abs", U=uvint, V=uvint).mt_binarize(threshold=thr, U=uvint, V=uvint)
diffmask = diffmask.ResizeX(target_width,target_height, kernel="Bilinear", chroma=chroma)
\ .mt_binarize(threshold=3, U=uvint, V=uvint)
\ .DebilinearM_expand(expand=expand, U=uvint, V=uvint)
\ .DebilinearM_inflate(inflate=inflate, U=uvint, V=uvint)
merged = Dither_merge16_8(dbi,rs,diffmask, u=uvint, v=uvint)

return merged
}

[real.finder]

I need to double post as the character limit is preventing me to place the script within one post.

Thanks for the updates. I am having issues with DebilinearM still. I'm guessing it maybe due to not being able to get the latest ResizeX_v1.0.1 mod 9 as it's still pending for approval so I only got mod 7. Would it be possible to provide a pastebin?

I'm receiving the following in avspmod: ResizeX does not have a named argument "dither_mode" (C: path\plugins64+\DebilinearM_v1.3.1_mod1.25.avsi, line 78) (New File, line 95).



it's already has the pastebin https://pastebin.com/LP7kDbe6 but seems you didn't note it
https://i.imgur.com/VfM6rlf.png

about n16 yes it's like lsb but true 16bit, we did talk about that here in the past (and even in other Threads like https://forum.doom9.org/showthread.php?p=1875147#post1875147)

will see the other things you asked for later (maybe in few Hours or some days)

and since you bring deband filter, can you or other members provides some video samples (I remember there also some code in avs to generate moving banding in some post here in doom9 few years ago)

[Natty]

updates for FineDehalo, BalanceBorders, LSFmod, FastLineDarkenMOD, Masked_DHA, BlindDeHalo3 and DeHalo_alpha

all update are some changes in LUT things, mainly for speed up float (32bit)

thanks. will this speed up native HBD (16) too?

[real.finder]

thanks. will this speed up native HBD (16) too?

in very few scripts

[StainlessS]

Very sneaky Real.Finder, that squiggle in your last [EDIT: but one] post had me investigating how you did it, (to save anybody else the trouble of finding out, its repeated below [png]).


https://i.postimg.cc/rFNpYF0K/Empty.png (https://postimages.org/)

[StainlessS]

can you or other members provides some video samples (I remember there also some code in avs to generate moving banding in some post here in doom9 few years ago)

I had a good look for the banding generator, but could not find.

What is the cause of "Moving Banding", just moving images ?

EDIT: This works but need low OUTLEVELS for real obvious banding

Function BandingGenny(clip c,int "nLevels",Bool "PcLevels") { # https://forum.doom9.org/showthread.php?p=1879799#post1879799
c
nLevels = Default(NLevels,36)
PcLevels = Default(PcLevels,False)
Foot = (PcLevels) ? 0 : 16
Head = (PcLevels) ? 255 : 235
Levels(Foot , 1.0, Head, Head-nLevels+1, Head,coring=false) # Squish range to nLevels number of levels
Levels(Head-nLevels+1, 1.0, Head, Foot , Head,coring=false) # UnSquish range, still nLevels number of levels
return Last
}


AviSource("D:\AutoLevels\OZ.avi")
ConvertToYV12
ORG=Last
### CONFIG ###
PCLEVELS = False
OUTLEVELS = 36
SHOW = false
##########
BandingGenny(OutLevels,PcLevels)
(Show) ? Subtract(ORG) : Last
return last

EDIT: Above banding definitely moves plenty good.

[StvG]

... The issue thus far I've found is that for resolutions 1920x1080 > 1280x720 like say a old show in 4:3 with black borders it'll create a 1 pixel artifact on all 4 sides that even ContinuityFixer / EdgeFixer http://avisynth.nl/index.php/EdgeFixer won't be able to fix. I had to get around this by adding nnedi3_resize16(960, 720,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64") below YtoUV(lu,lv,ly)...

Did you try different radius values? radius 2-5 should be ok.

[real.finder]

thanks. will this speed up native HBD (16) too?

I did added more updates today, many scripts now should be faster in HBD (10-32) thanks to avs+ expr()

I had a good look for the banding generator, but could not find.

What is the cause of "Moving Banding", just moving images ?

EDIT: This works but need low OUTLEVELS for real obvious banding

Function BandingGenny(clip c,int "nLevels",Bool "PcLevels") { # https://forum.doom9.org/showthread.php?p=1879799#post1879799
c
nLevels = Default(NLevels,36)
PcLevels = Default(PcLevels,False)
Foot = (PcLevels) ? 0 : 16
Head = (PcLevels) ? 255 : 235
Levels(Foot , 1.0, Head, Head-nLevels+1, Head,coring=false) # Squish range to nLevels number of levels
Levels(Head-nLevels+1, 1.0, Head, Foot , Head,coring=false) # UnSquish range, still nLevels number of levels
return Last
}


AviSource("D:\AutoLevels\OZ.avi")
ConvertToYV12
ORG=Last
### CONFIG ###
PCLEVELS = False
OUTLEVELS = 36
SHOW = false
##########
BandingGenny(OutLevels,PcLevels)
(Show) ? Subtract(ORG) : Last
return last

EDIT: Above banding definitely moves plenty good.

thanks StainlessS, will try it, "Moving Banding" was this http://i.imgur.com/uonzj6V.png but moving from left to right and vice versa kinda thing

edit:
ImageSource("uonzj6V.png")
ConvertToYV24(matrix="Rec709", interlaced=false)
mt_merge(last,FlipHorizontal(),BlankClip(last,color = $FFFFFF).FadeIO(500))

this kinda do it

edit: find it here https://forum.doom9.org/showthread.php?p=1668270#post1668270

-------

if anyone has dark Anime Scenes that has banding, and will be better if the dark part that has banding has some details

[real.finder]

:stupid:

The script is called Gradfun3mod. https://pastebin.com/0mkhsimh


https://pastebin.com/BY6CfBMv


dither_convert_8_to_16()
ly = GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()


edit: there are new update

but anyway I don't encourage get 720 yuv444 from 1080 yuv420

Gradfun3mod maybe can get more updates but not likely for me, so anyone else can feel free to do it

[StainlessS]

EDIT: OK, I get what you mean by moving banding now.

You can make '[EDIT: physically] moving' color gradient banding (if required) by saving AVI from VDub2/Menu/Tools/"Create Test Video"/Gradients,
and run through the BandingGenny() thing. [for testing purposes, eg banding removal testing]

[real.finder]

ResizeX_v1.0.1 mod 9

there was a big problem in ResizeX, it was not ready for lsb with desampling

I did post mod 9.1 to fix that

[dREV]

it's already has the pastebin https://pastebin.com/LP7kDbe6 but seems you didn't note it
https://i.imgur.com/VfM6rlf.png

about n16 yes it's like lsb but true 16bit, we did talk about that here in the past (and even in other Threads like https://forum.doom9.org/showthread.php?p=1875147#post1875147)

will see the other things you asked for later (maybe in few Hours or some days)

and since you bring deband filter, can you or other members provides some video samples (I remember there also some code in avs to generate moving banding in some post here in doom9 few years ago)

Thanks. I had no idea it was there. Looks like I wasn't the only one that didn't spot it. I been busy was going to reply several days ago but been too busy and with the heat wave too.

I was going to reply about an issue with the sharpness not looking the same as the original, the thr code was backwards but now see there's been an update to ResizeX_v1.0.1 mod 9 to ResizeX_v1.0.1 mod 9.35 and seeing the results looks like the original DebilinearM for AviSynth x86. Thanks alot! Looking forward to doing some encodes with this before fully switchin. :cool:


edit: there are new update

but anyway I don't encourage get 720 yuv444 from 1080 yuv420

Gradfun3mod maybe can get more updates but not likely for me, so anyone else can feel free to do it

If you encode it in 4:2:0 the colors diminish which bothers me as it don't match the Bluray (downscaled comparisons obviously) but with 444 it does, so that's my preference. In H264 with 8 bit or 10 bit from several test encodes seem to make it better going by those codes I've posted. HEVC with 10 bit and 12 bit even moreso. Dunno about 8 bit stuff with it I think I was having trouble getting it to work with that. I'm aware Doom9 prefers what they like, so I can understand why you write that having read a lot (and a lot) of threads on this site and elsewhere like VideoHelp.

Thanks for updating Gradfun3mod to be used on 64 bit Avisynth+ and the example script it helps me alot and I'm sure for newbies as well. Will you put this script on your list of updates on the first page? Since you may decide not update it anymore you could indicate this as well.

Also, could I be educated on what native HBD (16) means? Wondering if I should understand this term to be used in AviSynth+ 64 bit.

Also, I read that FTurn http://avisynth.nl/index.php/FTurn was implemented but the code doesn't work so had to write TurnRight and TurnLeft, my question is is it really using this?

Did you try different radius values? radius 2-5 should be ok.
I did at first to see what it does didn't see anything and after I spotted those artifacts. With that in mind I tried to check it out and seems to work but not certain on the extend without doing some small encodes. Thanks for your help.


I want to advertise this script for no other reason then to let it be known and be used by others as I don't see it available on the original creators webpage any longer and maybe somebody will include these scripts into the AviSynth filter for people to find easier and the Wiki entries for it. I believe they have moved on to VaporSynth.

It is called f3kdbmod16 / flash3kyuuMOD16 # Author: Petoyusa, eXmendiC, Frechdachs, kageru
# f3kdbmod16 / flash3kyuuMOD16 Version: 1.3
#
# Radiusy = Radius of the Debian in the Luma area (Y)
# Radiusc = radius of the Debander in the Chroma range (UV)
# Thry = strength of the gander in the luma area (Y)
# Thrc = Strength of the Debander in the Chroma-Area (UV)
# Mask_thr = thickness of the mask to recognize contours / details of banding # this is thr=0.88 on Gradfun3()
# Mask_radius = Radius of the mask # This is probably mask on Gradfun3() 2 is the default on Gradfun3 and 0 is to use the mask when banding
# Grainy = grain which is added after the deprocessing process in the luma area (Y)
# Grainc = Grain which is added after the decanting process in the chroma region (UV)
# Dynamic_grainy = Use dynamic grains instead of static grains in the luma area (Y)
# Dynamic_grainy = Use dynamic grains instead of static grains in the chroma range (UV)
#

function f3kdbmod16(clip clp, int "thry", int "thrc", int "radiusy", int "radiusc", int "grainy", int "grainc", bool "dynamic_grainy", bool "dynamic_grainc", float "mask_thr", int "mask_radius")
{
radiusy = default( radiusy, 12 )
radiusc = default( radiusc, 8 )
thry = default( thry, 40 )
thrc = default( thrc, thry/2 )
mask_thr = default( mask_thr, 2 )
mask_radius = default( mask_radius, 2 )
grainy = default( grainy, 15 )
grainc = default( grainc, 0 )
dynamic_grainy = default( dynamic_grainy, false )
dynamic_grainc = default( dynamic_grainc, false )

mask = clp.GradFun3(thr_det=mask_thr,mask=mask_radius,debug=1,lsb_in=true,lsb=true)
U = clp.UToY().f3kdb(range=radiusc, Y=thrc, Cb=0, Cr=0, grainY=grainc, grainC=0, dynamic_grain=dynamic_grainc, keep_tv_range=true, input_depth=16, output_depth=16)
V = clp.VToY().f3kdb(range=radiusc, Y=thrc, Cb=0, Cr=0, grainY=grainc, grainC=0, dynamic_grain=dynamic_grainc, keep_tv_range=true, input_depth=16, output_depth=16)
Y = clp.f3kdb(range=radiusy, Y=thry, Cb=0, Cr=0, grainY=grainy, grainC=0, dynamic_grain=dynamic_grainy, keep_tv_range=true, input_depth=16, output_depth=16)
filtered = YToUV(U, V, Y)
return Dither_merge16(filtered, clp, mask, y=3, u=3, v=3, luma=true)
}

[Groucho2004]

Also, I read that FTurn http://avisynth.nl/index.php/FTurn was implemented but the code doesn't work so had to write TurnRight and TurnLeft, my question is is it really using this?What do you mean by "the code doesn't work"?

Anyway, tp7's fast code for TurnLeft()/TurnRight() was integrated into AVS+ a long time ago.

[dREV]

What do you mean by "the code doesn't work"?

Anyway, tp7's fast code for TurnLeft()/TurnRight() was integrated into AVS+ a long time ago.

The code as in writing it as FTurnRight and FTurnLeft. So writing it as TurnRight and TurnLeft wasn't sure if I was using the old version or the FTurn version as the documentation doesn't indicate that its been renamed to TurnRight and TurnLeft in Avisynth+ 64 bit because in Avisynth+ x86 the code FTurn Left and Right works but not so in 64 bit.

[Groucho2004]

The code as in writing it as FTurnRight and FTurnLeft. So writing it as TurnRight and TurnLeft wasn't sure if I was using the old version or the FTurn version as the documentation doesn't indicate that it's been renamed in Avisynth+ 64 bit because in Avisynth+ x86 the code FTurn works but not so in 64 bit.Nothing was renamed. FTurnLeft/FTurnRight are external functions and you need the fturn plugin to use them.

[dREV]

Nothing was renamed. FTurnLeft/FTurnRight are external functions and you need the fturn plugin to use them.

For real? If I am understanding correctly there's a 64 bit version? If so, I've looked at:
https://github.com/tp7/fturn/releases
https://forum.doom9.org/showthread.php?t=168315

and nothing. If you are using it could you point me to where it is?

[Groucho2004]

For real? If I am understanding correctly there's a 64 bit version? If so, I've looked at:
https://github.com/tp7/fturn/releases
https://forum.doom9.org/showthread.php?t=168315

and nothing. If you are using it could you point me to where it is?
There is no 64 bit fturn plugin as far as I'm aware and if you're using AVS+ there is no reason to use it anyway.

[dREV]

There is no 64 bit fturn plugin as far as I'm aware and if you're using AVS+ there is no reason to use it anyway.
Oh, I see. If you had read the posts thus far it's been about transitioning from AviSynth+ x86 to 64 bit. I hope I've clarified your question.

[Groucho2004]

Oh, I see. If you had read the posts thus far it's been about transitioning from AviSynth+ x86 to 64 bit. I hope I've clarified your question.I did read the posts. Also, what question of mine needed clarification?

[dREV]

I did read the posts. Also, what question of mine needed clarification?

Um. You asked what the code I was referring to was. I clarified it.

I have a question. I don't want the thread to be long detracting my reply to real.finder, so I'll ask this question.

So without the FTurn it's not implemented within AviSynth+ to replace the original Turn in AviSynth? Or did I misunderstand and that it means that it can be used on AviSynth+? Note: FTurn is only recommended for AviSynth. The optimized code is integrated into the AviSynth+ core, thus making FTurn obsolete. So it's using Turn but using the code of FTurn? Guess I'm a little slow in understanding this.

[Groucho2004]

So it's using Turn but using the code of FTurn?Exactly.

[dREV]

Exactly.

OK cool. That's what I wanted to know. Thanks for your help. :thanks:

[Edit] Question. I see you have an update for DeScratch. Is there one for DeSpot?
I tried using a old version of DeScratch (using defaults) and DeSpot (defaults) and they didn't like each other. Both avspmod and encode ended up having issues. Not so when used separately. Maybe I did something wrong.

[Groucho2004]

I see you have an update for DeScratch. Is there one for DeSpot?No, but I'll look into updating the headers and making a 64 bit version.

[StainlessS]

As far as DeSpot is concerned (I cant remember about DeScratch),
there is some Despot option which uses some temporal blurring (between frames, for detected spots), if you have any other temporal filters following DeSpot, do not use its
blur option (cant remember what its called), otherwise the temporal blur will stop other temporal filters from working as well as they could.
[I think that the default for the blurring thing was probably ON, so find it and switch it off).

[dREV]

No, but I'll look into updating the headers and making a 64 bit version.

Thanks for the reply and consideration for a 64 bit version of DeSpot.

As far as DeSpot is concerned (I cant remember about DeScratch),
there is some Despot option which uses some temporal blurring (between frames, for detected spots), if you have any other temporal filters following DeSpot, do not use its
blur option (cant remember what its called), otherwise the temporal blur will stop other temporal filters from working as well as they could.
[I think that the default for the blurring thing was probably ON, so find it and switch it off).

Maybe that's what happened. The default says it is 1.
blur (from 0 to 4, default 1)
Value (length) of local spatial blur near borders of deleted spots I'll check this out later to test. Was disappointed that I couldn't use them both together and couldn't figure out why those artifacts was happening.

Thanks for your help. I'm still trying to understand these Spatial stuff.

[StainlessS]

Actually, me thinks this is it. [looks like default of 0, off [temporal smoothing, rather than blurring], maybe some of the examples use tsmooth, so dont just blindly copy them)

tsmooth (from 0 to 127, default 0)
Control temporal smoothing in static areas (except spots and motion).
Set approximate threshold of pixel luma variance in 3 frames,
The more variance exceed this threshold, the less temporal smoothing.
0 - no temporal smoothing.

Blur, is spatial only arg.

EDIT: You would also want to turn it off, if using several instances of DeSpot (eg different size/color spots) otherwise earlier instances would inhibit
detection by later instances of Despot.

[real.finder]

Also, could I be educated on what native HBD (16) means? Wondering if I should understand this term to be used in AviSynth+ 64 bit.


it mean the real 16bit that don't use any hack like lsb or DoubleWidth like how LSMASHSource used to be, see here (https://forum.doom9.org/showthread.php?p=1845564&highlight=hack#post1845564) aside from that many lsb scripts around has at least not real lsb_in 16bit like SMDegrain or even all lsb in it not real 16bit at all like Nnedi3_resize16

f3kdbmod16 / flash3kyuuMOD16 (https://pastebin.com/61vM40V9)

I don't think there are anything can done for it since GradFun3 not work with HBD yet, but is it good function? what its main benefit

[real.finder]

For real? If I am understanding correctly there's a 64 bit version? If so, I've looked at:
https://github.com/tp7/fturn/releases
https://forum.doom9.org/showthread.php?t=168315

and nothing. If you are using it could you point me to where it is?

you don't need to care, at least for my updates for scripts if avs+ is used then FTurn will not be used

and I didn't see script that work only with FTurn before, all them check if the function existing but in my updates check if it avs+ first before do the other check

[Groucho2004]

Thanks for the reply and consideration for a 64 bit version of DeSpot.It's up on my Stuff page.

[dREV]

it mean the real 16bit that don't use any hack like lsb or DoubleWidth like how LSMASHSource used to be, see here (https://forum.doom9.org/showthread.php?p=1845564&highlight=hack#post1845564) aside from that many lsb scripts around has at least not real lsb_in 16bit like SMDegrain or even all lsb in it not real 16bit all like Nnedi3_resize16
Thanks for the link.


I don't think there are anything can done for it since GradFun3 not work with HBD yet, but is it good function? what its main benefit

From what I could recall it was meant to take the place of the original flash3kyuu. I don't really remember the rest as one of the modders where I had grabbed this from the page for it is no longer available as he or she recommends using VaporSynth.

I've only been using it prior to a downscaling that's about it. The original does the grain better then it but both depending on the scene destroys the dark line art particular hard to see lines where it kinda looks like part of the background art or is surrounded by color like part of the shadow of clothing, body, etc. So I been using Dither_add_grain16(var=0.10,uvar=0,soft=100) instead to prevent that and been pleased thus far.

I merely put it up to exist on this site nothing more if it can be picked up by the search bot for other users to use and try out. Maybe be included in the AviSynth filter page or something.


Actually, me thinks this is it. [looks like default of 0, off [temporal smoothing, rather than blurring], maybe some of the examples use tsmooth, so dont just blindly copy them)

Blur, is spatial only arg.

EDIT: You would also want to turn it off, if using several instances of DeSpot (eg different size/color spots) otherwise earlier instances would inhibit
detection by later instances of Despot.
Thanks for the added information and correction. Will keep your post in mind when trying it out again.


It's up on my Stuff page.

That was fast. Will try it out later. Thanks for the time you willingly put into this and sharing it to all of us.

[real.finder]

Thanks for the link.

From what I could recall it was meant to take the place of the original flash3kyuu. I don't really remember the rest as one of the modders where I had grabbed this from the page for it is no longer available as he or she recommends using VaporSynth.

I've only been using it prior to a downscaling that's about it. The original does the grain better then it but both depending on the scene destroys the dark line art particular hard to see lines where it kinda looks like part of the background art or is surrounded by color like part of the shadow of clothing, body, etc. So I been using Dither_add_grain16(var=0.10,uvar=0,soft=100) instead to prevent that and been pleased thus far.

I merely put it up to exist on this site nothing more if it can be picked up by the search bot for other users to use and try out. Maybe be included in the AviSynth filter page or something.


I was plan to play with deband things and I had Feature request or whatever in flash3kyuu Thread (https://forum.doom9.org/showthread.php?p=1880098#post1880098) but seems it ignored

if you have some original video samples for these cases can you post them so I can play with them?

[real.finder]

From what I could recall it was meant to take the place of the original flash3kyuu.

what about F3KDB_3 I just did in Advanced Denoising.avsi :)


ConvertBits(16)
Hqdn3d_2 #I just did make it work with HBD using ConvertTo/FromDoubleWidth which is faster than lsb
F3KDB_3(pass=4) #I just did make it work with HBD same as Hqdn3d_2
ConvertBits(8, dither=1)


and no, I didn't drop old avs26 or even avs25 lsb to support HBD ;)

[Natty]

:thanks:
where can i find f3kdb_3? and do all your filters support lsb and hbd both? it will be interesting to compare speeds in that case. and can i request 1 filter to be added in your list of stuffs? its SeeSaw. mod it with your magic if you have time and think its worth it.
:thanks:

[real.finder]

:thanks:
where can i find f3kdb_3? and do all your filters support lsb and hbd both? it will be interesting to compare speeds in that case. and can i request 1 filter to be added in your list of stuffs? its SeeSaw. mod it with your magic if you have time and think its worth it.
:thanks:

As I said. In Advanced Denoising. Same script that has sanimebob.

The speed if not same as real HBD plugin it will be more faster than lsb.

Not all scripts support both lsb and hbd. But I dont remove lsb support if I added HBD most of times if not all

I will try update SeeSaw later. Maybe in hours or days or even ever

edit: about f3kdb_3, there was some bugs I just fixed, and it still sample_mode=4 (Default) not work correctly with lsb and DoubleWidth (Merge function non-compatible with them), it's not like I will care more for those hacks so I will leave it as it for now

[dREV]

I was plan to play with deband things and I had Feature request or whatever in flash3kyuu Thread (https://forum.doom9.org/showthread.php?p=1880098#post1880098) but seems it ignored

if you have some original video samples for these cases can you post them so I can play with them?

If I understood correctly by "moving banding" you mean something like this animated gif? It is about 9.6 MB file (https://i.ibb.co/LvKBH1z/Miru-Tights.gif).

If so, I don't have anything that's close to that. I see that a lot on video streaming sites like Crunchyroll and YouTube and such. I could provide a 3-5 second or so scene with a banding that stood out to me if you want that. It's nothing that extreme tho.


what about F3KDB_3 I just did in Advanced Denoising.avsi :)


ConvertBits(16)
Hqdn3d_2 #I just did make it work with HBD using ConvertTo/FromDoubleWidth which is faster than lsb
F3KDB_3(pass=4) #I just did make it work with HBD same as Hqdn3d_2
ConvertBits(8, dither=1)


and no, I didn't drop old avs26 or even avs25 lsb to support HBD ;)

I've never heard of f3kdb_3 before but I am interested in your example above. May try it out.

I've done some testings with MeGUI 64 bit version 2855 but looks like I need to consider buying another 8 GB ram. Didn't expect it to jump my ram output over 92/95% with just single 8 GB stick.

[real.finder]

If I understood correctly by "moving banding" you mean something like this animated gif? It is about 9.6 MB file (https://i.ibb.co/LvKBH1z/Miru-Tights.gif).

I already get that "moving banding" posts ago

I could provide a 3-5 second or so scene with a banding that stood out to me if you want that.

any samples are welcome


I've never heard of f3kdb_3 before but I am interested in your example above. May try it out.

I've done some testings with MeGUI 64 bit version 2855 but looks like I need to consider buying another 8 GB ram. Didn't expect it to jump my ram output over 92/95% with just single 8 GB stick.

because I did it when I post days ago, it's just script function

---------

aside from that I just updates few things in "dfttestMC and MC things" and "Advanced Denoising" (admfilter has new things and fixes, f3kdb_3 fix lsb and DoubleWidth with sample_mode=4)

[real.finder]

testing with Death Note R2J DVD sample I have

MPEG2Source("E:\VTS_01_2(00h04m12s-00h05m36s).d2v", cpu=0)
TFM(d2v="E:\VTS_01_2(00h04m12s-00h05m36s).d2v")
TDecimate(1)
ConvertBits(16)
smam(filter=daa3mod())
ConvertToStacked().admfilter(lsb_in=true,lsb_out=true).ConvertFromStacked()
F3KDB_3()
ConvertBits(8, dither=1)
luma_histogram()

https://i.imgur.com/24in1pQ.png

after using the red code

https://i.imgur.com/jhJSsRy.png

[StvG]

... aside from that I just updates few things in "dfttestMC and MC things" and "Advanced Denoising" (admfilter has new things and fixes, f3kdb_3 fix lsb and DoubleWidth with sample_mode=4)

I didn't see the requirements of "Advanced Denoising". Where are they written?

[real.finder]

I didn't see the requirements of "Advanced Denoising". Where are they written?

didn't make one, what about try and error?

[real.finder]

and can i request 1 filter to be added in your list of stuffs? its SeeSaw. mod it with your magic if you have time and think its worth it.
:thanks:

done, see the 1st (OP) post

[Natty]

done, see the 1st (OP) post

thanks a lot.

what are the changes apart from avs version / number lines?

[real.finder]

thanks a lot.

what are the changes apart from avs version / number lines?

Almost same as dehalo_alpha, faster in avs 2.6 and HBD in avs+

[Natty]

thanks again, experts like you on doom9 made many things possible for me. i am very much thankful to all of them and doom9 owners.

[real.finder]

thanks again, experts like you on doom9 made many things possible for me. i am very much thankful to all of them and doom9 owners.

experts, me? :eek: it's just Hobby, and I didn't studied any programming language other than what was taught to us in middle school in the beginning of the millennium

[StvG]

didn't make one, what about try and error?

Is this version (https://forum.doom9.org/showpost.php?p=1781204&postcount=16) the latest?

Is there any chance F3KDB_3 to work with the latest f3kdb plugin supporting HDB?

[real.finder]

Is this version (https://forum.doom9.org/showpost.php?p=1781204&postcount=16) the latest?

I think so, anyway it's the one I use

Is there any chance F3KDB_3 to work with the latest f3kdb plugin supporting HDB?

latest f3kdb removed many things and didn't offer any new things except HBD for 10-16 bit's which F3KDB_3 can do with the older F3KDB but maybe with small slowdown (didn't check that but anyway going To/From DoubleWidth is just change the flag so it should not be any speed difference)

making F3KDB_3 work with the latest f3kdb mean goodbye for all those things that removed and losing most compatibility unless I made more codes in F3KDB_3 to just make it work with latest f3kdb in some Conditions but I don't think it worth it for now

[StvG]

Ok. Thanks for the info.

[real.finder]

well, I think F3KDB_3 is stable now, hope there are no bugs left :scared:

========

F3KDB_3 updates and features


difference from F3KDB:-

1- sample_mode 3 and 4 (4 is the Default)

2- new pass parameter (2 is Default if sample_mode = 4)

3- new chroma parameter

4- work with HBD and old lsb/interleaved hack and all avs/avs+ Versions

=======

if you use it without chroma=false or still using avs 2.5 you need flash3kyuu deband 1.5.1:- x86 (https://web.archive.org/web/20190804055433/http://chaosking.de/repo/avsfilters/Restoration_Filters/Debanding/flash3kyuu_deband___(1.5.1_-_2011-09-07).7z) / x64 (https://web.archive.org/web/20190804055453/http://chaosking.de/repo/avsfilters/Restoration_Filters/Debanding/flash3kyuu_deband___(1.5.1_-_2011-09-07)_x64.7z)

if you use it with chroma=false and avs 2.6 / avs+ then you need f3kdb-b98d6bc in Attachments

if you use it with old lsb/interleaved hacks then you will need dither tools (http://avisynth.nl/index.php/Dither_tools) and HDRCore (in Attachments)

=========

note:- if F3KDB() added sample_mode 3 and 4 and pass parameter and others then this function will update to take that into account since coding those in dll will make them faster

======

download:-
this is a old one, see the 1st OP post

pastebin (https://pastebin.com/3Fnru0B5) and in Attachments

=====

Samples:-

with this (https://forum.doom9.org/showpost.php?p=1879897&postcount=32) using ConvertBits(16).F3KDB_3(pass=4).ConvertBits(8, dither=1) (https://i.imgur.com/mfSriVf.png)

-------

with this (https://web.archive.org/web/20111211192652if_/http://img828.imageshack.us/img828/6518/wallorig.png) (got it from here (https://forum.doom9.org/showthread.php?p=1503800#post1503800))

F3KDB() (https://i.imgur.com/tDmQErk.png) /// F3KDB_3() (https://i.imgur.com/6GztFZF.png)

Hqdn3d_2().F3KDB() (https://i.imgur.com/cBAiy9V.png) /// Hqdn3d_2().F3KDB_3() (https://i.imgur.com/XACv5vj.png)

edit: see this post (https://forum.doom9.org/showthread.php?p=1881244#post1881244) for last update info

[ChaosKing]

What is the difference between f3kdb-b98d6bc and flash3kyuu 1.5.1 or v2.0pre?

EDIT: Only avs 2.5 compatibility?

[real.finder]

What is the difference between f3kdb-b98d6bc and flash3kyuu 1.5.1 or v2.0pre?

EDIT: Only avs 2.5 compatibility?

flash3kyuu 1.5.1 has bug with Y8 and input_mode > 0, I think 2.0pre fix that, but f3kdb-b98d6bc was the last one by SAPikachu (2.0pre may has some bugs that fixed in b98d6bc but the main reason is b98d6bc has x64 and x86 while 2.0pre is only x86)

[ChaosKing]

And is this version (F3KDB Version 2.1 with native high bit depth) supported? https://forum.doom9.org/showthread.php?t=176553

[real.finder]

And is this version (F3KDB Version 2.1 with native high bit depth) supported? https://forum.doom9.org/showthread.php?t=176553

not yet, I answer this here https://forum.doom9.org/showthread.php?p=1880853#post1880853

and above
note:- if F3KDB() added sample_mode 3 and 4 and pass parameter and others then this function will update to take that into account since coding those in dll will make them faster

[real.finder]

new update for F3KDB_3 in the same post above (https://forum.doom9.org/showthread.php?p=1881052#post1881052)

new masking parameter (true by default) with mask_thr and mask_radius parameters that make it act like f3kdbmod16 / flash3kyuuMOD16

edit: new parameter added (bool lastpassmask)

edit: test sample with the same things here https://forum.doom9.org/showthread.php?p=1880477#post1880477 but with smam(filter=daa3mod(slow=4)) (https://forum.doom9.org/showthread.php?p=1639679#post1639679) instead of smam(filter=daa3mod()), with all scripts updates until today

https://i.imgur.com/TQkDvyO.png

edit: new F3KDB_3_adg https://pastebin.com/e196hcN9 (not part of Advanced Denoising.avsi)

[Natty]

when i try to use FastLineDarkenMod2() alone i get error
i dont know what "avsplusnumber" means
is there any way to fix it without using SMDegrain forcefully?
same issues with other plugins.
:thanks:

[real.finder]

when i try to use FastLineDarkenMod2() alone i get error
i dont know what "avsplusnumber" means
is there any way to fix it without using SMDegrain forcefully?
same issues with other plugins.
:thanks:

you dont need to use SMDegrain you just need to load it or put it in autoload folder

anyway you can copy the missing functions (like AvsPlusVersionNumber) from SMDegrain in any script you use

[Natty]

thanks. moved Smdegrain, masktools and rgtools from staxrip's internal folder to plugins64+ folder and its fixed and working fast now. thanks.

[real.finder]

new update for DeHaloHmod https://pastebin.com/mGRFQjje

now can work with minideen (https://forum.doom9.org/showthread.php?t=176554) and still can work with old deen if minideen not present

edit: it's not work with minideen yet https://forum.doom9.org/showthread.php?p=1883458#post1883458 it will use old deen until this fixed

edit: it's fixed in r3 and r4 of minideen

[dREV]

from https://forum.doom9.org/showthread.php?p=1884083

I haven't switched to 64 bit AviSynth+ because when I did my testing RAM went up over 90% on my single 8 GB RAM, so I planning to buy another 8 GB RAM as I use the same computer to do stuff while I wait for encode to finish.

Also, when I tried to use it on 32 bit AviSynth+ it would say this on avspmod:

"I don't know what 'AvsPlusVersionNumber' means
C:\ path\plugins\ResizeX_v1.0.1_mod 9.avsi, line 70
C:\ path\plugins\DebilinearM_v1.3.1_mod_1.25.avsi, line 76"

So I just went back to how I did it normally till I get to 64 bit.


On 64 bit AviSynth+ I can't use it without the lsb hack because when I use ConvertBits(bits=16) or ConvertBits(bits=32) with
ly = DebilinearM(1280,544,thr=01,lsb_inout=true, DeResizeMT=true)
lc = nnedi3_resize16(1280*2, 544*,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

and HBD it tells me on avspmod

"lsb hack is not Compatible with native high bit depth
C:\ path\plugins64+\ResizeX_v1.0.1_mod9.35.avsi, line 79
C:\ path\plugins64+\DebilinearM_v1.3.1_mod1.25.avsi, line 87"

It works fine if I use the lsb hack dither_convert_8_to_16()
You should be how to do it like that tho? Remember? https://forum.doom9.org/showthread.php?p=1879523#post1879523

Same thing when I use Gradfun3mod with HBD

ly = GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

On avspmod it tells me:

"ConvertToYV411: 8 bit only
C:\ path\plugins64+\GradFun3mod 3.1.avsi, line 176"

Works fine if I use the lsb hack dither_convert_8_to_16() for this too.
You showed me to do it this way also, https://forum.doom9.org/showthread.php?p=1879909#post1879909

Can you show me how to do it properly cuz I don't get it as you know I'm still new to this HBD thing as I am so use to using the lsb hack. If you know how to could you edit those posts above to include the HBD please leave lsb hack too.

On 32 bit AviSynth+ version I can't get around the thing it says that it doesn't know what AvsPlusNumber is. So until I get that RAM I can't use your scripts till I switch to 64 bit version and buy another 8 GB RAM.

Or maybe I'm missing something again? :confused:

[real.finder]

from https://forum.doom9.org/showthread.php?p=1884083

I haven't switched to 64 bit AviSynth+ because when I did my testing RAM went up over 90% on my single 8 GB RAM, so I planning to buy another 8 GB RAM as I use the same computer to do stuff while I wait for encode to finish.

that odd, it should not use that much


Also, when I tried to use it on 32 bit AviSynth+ it would say this on avspmod:

"I don't know what 'AvsPlusVersionNumber' means
C:\ path\plugins\ResizeX_v1.0.1_mod 9.avsi, line 70
C:\ path\plugins\DebilinearM_v1.3.1_mod_1.25.avsi, line 76"

So I just went back to how I did it normally till I get to 64 bit.

if you google that message you will know why, anyway you need SMDegrain.avsi in your plugins folder


On 64 bit AviSynth+ I can't use it without the lsb hack because when I use ConvertBits(bits=16) or ConvertBits(bits=32) with
ly = DebilinearM(1280,544,thr=01,lsb_inout=true, DeResizeMT=true)
lc = nnedi3_resize16(1280*2, 544*,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

and HBD it tells me on avspmod

"lsb hack is not Compatible with native high bit depth
C:\ path\plugins64+\ResizeX_v1.0.1_mod9.35.avsi, line 79
C:\ path\plugins64+\DebilinearM_v1.3.1_mod1.25.avsi, line 87"

It works fine if I use the lsb hack dither_convert_8_to_16()
You should be how to do it like that tho? Remember? https://forum.doom9.org/showthread.php?p=1879523#post1879523

Same thing when I use Gradfun3mod with HBD

ly = GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

On avspmod it tells me:

"ConvertToYV411: 8 bit only
C:\ path\plugins64+\GradFun3mod 3.1.avsi, line 176"

Works fine if I use the lsb hack dither_convert_8_to_16() for this too.
You showed me to do it this way also, https://forum.doom9.org/showthread.php?p=1879909#post1879909

Can you show me how to do it properly cuz I don't get it as you know I'm still new to this HBD thing as I am so use to using the lsb hack. If you know how to could you edit those posts above to include the HBD please leave lsb hack too.

On 32 bit AviSynth+ version I can't get around the thing it says that it doesn't know what AvsPlusNumber is. So until I get that RAM I can't use your scripts till I switch to 64 bit version and buy another 8 GB RAM.

Or maybe I'm missing something again? :confused:

Of course lsb not work with HBD, you must find updated scripts or alternatives to use it with HBD, like this


ConvertBits(bits=16)
ly = DebilinearM(1280,544,thr=01, DeResizeMT=true)
lc = edi_rpow2(1280*2, 544*2,cshift="Spline64",src_top=0.0,src_left=0.50)
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)


if you didn't find updated scripts or alternatives then you can use ConvertToStacked/ConvertFromStacked see here http://avisynth.nl/index.php/ConvertStacked


ConvertBits(bits=16) #if it not 16 HBD already
ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(1280*2, 720*2,cshift="Spline64",src_top=0.0,src_left=0.50)
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

[Natty]

nnedi3 resize16 and gradfun dont support HBD i think. you can try like this

Dither_convert_8_to_16() or ConvertBits(16).ConvertToStacked()
Nnedi3_resize16(lsb_in=true, lsb=true)
GradFun3mod(lsb_in=true, lsb=true)
DitherPost(mode=0) or ConvertFromStacked().ConvertBits(8 or 10, Dither=0)

[real.finder]

days ago I start read how Nnedi3_resize16 work to either make it work with HBD or add its features to edi_rpow2, and find it use Dither_limit_dif16, first time I didnt think of it can be replaced with something else, and there are SmoothAdjust but seems it only for tvrange vs full range things, then I start study Dither_limit_dif16 and find it work almost same as my sBlackerPixel and swhiterPixel, so I use them as a base to simulate Dither_limit_dif16 and it seems work!


# base on Dither_limit_dif16 idea (not 100% same output)
function slimit_dif(clip "flt", clip "src", clip "ref", float "thr", float "elast", int "Y", int "U", int "V", bool "elastinfl")
{
thr = default(thr, 0.25)
elast = default(elast, 3.0)
elast2 = elast > 1.0 ? elast * thr : elast
Y = default(Y, 3)
U = default(U, 3)
V = default(V, 3)
elastinfl = default(elastinfl, false)

Assert(!(elast < 1), "slimit_dif: elast must be more than 1")
Assert((defined(flt) && defined(src)), "slimit_dif: both flt clip and src clip are needed")

ldmask = elast!=1 ? VersionNumber() < 2.6 ? mt_lutxy(defined(ref) ? ref : src,flt,"x y - abs "+string(thr)+" <= 255 x y - abs "+string(elast2)+" <= ? 255 255 "+string(elast2)+" / x y - abs * - 0 ?", Y=Y,U=U,V=V)
\ : mt_lutxy(defined(ref) ? ref : src,flt,"x y - abs "+string(thr)+" scalef <= range_max x y - abs "+string(elast2)+" scalef <= ? range_max range_max "+string(elast2)+" scalef / x y - abs * - 0 ?", Y=Y,U=U,V=V,use_expr=2) : nop()

elast!=1 ? VersionNumber() < 2.6 ? smaskmerge(src,flt, elastinfl ? ldmask.mt_inflate(155) : ldmask, Y=Y,U=U,V=V) : Mt_Merge(src,flt, elastinfl ? ldmask.mt_inflate(155) : ldmask, Y=Y,U=U,V=V) : \
VersionNumber() < 2.6 ? defined(ref) ? ref.mt_lutxyz(flt,src,"x y - abs "+string(thr)+" <= y z ?", Y=Y,U=U,V=V) : src.mt_lutxy(flt,"x y - abs "+string(thr)+" <= y x ?", Y=Y,U=U,V=V)
\ : defined(ref) ? ref.mt_lutxyz(flt,src,"x y - abs "+string(thr)+" scalef <= y z ?",use_expr=2, Y=Y,U=U,V=V) : src.mt_lutxy(flt,"x y - abs "+string(thr)+" scalef <= y x ?",use_expr=2, Y=Y,U=U,V=V)
}


with elast=1 both are 100% same

but as it process choma, avoid use it with float clip if you process choma for now, I will add it in Advanced Denoising.avsi soon so any update will be in Advanced Denoising.avsi not the code above

[dREV]

posted another one https://forum.doom9.org/showthread.php?p=1884673#post1884673...

I've put in SMDegrain.avsi and trying out
ConvertBits(bits=16)
ly = DebilinearM(1280,544,thr=01, DeResizeMT=true)
lc = edi_rpow2(1280*2, 544*2,cshift="Spline64",src_top=0.0,src_left=0.50)
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

Got avspmod to say:
Script error: edi_pow2 does not have a named argument "src_top"

So I went and edited the edi out to, edi_rpow2(1280*2, 544*2,cshift="Spline64").

Now gives a new error
edi_rpow2: rfactorX must be a power of 2
(C:\path\plugins\edi_rpow2+ v1.0 mod 7.avsi, line 205)

...... :p

So tried the other one you put using

ConvertBits(bits=16) #if it not 16 HBD already
ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(1280*2, 720*2,cshift="Spline64",src_top=0.0,src_left=0.50)
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

Now it complains about this:

Gradfun3mod: wrong resizer value.
(C:\path\plugins\GradFunmod.avsi, line 187) :mad:

I've got all your scripts
Import("C:\path\plugins\SMDegrain+ v.3.1.2.104s.avsi")
Import("C:\path\plugins\edi_rpow2+ v1.0 mod 7.avsi")
Import("C:\path\plugins\ResizeX+_v1.0.1_mod 9.35.avsi")

Also, not sure if I like having to give up my friend, nnedi3_resize16() yet.

[real.finder]

sorry, I didn't note that edi_pow2 does not have src_top, so I will try add it in edi_pow2 or port the nnedi3_resize16 to support HBD

and it need to be like this edi_rpow2(fwidth=1280*2, fheight=544*2,cshift="Spline64") to work but will not give right output in your case since there are no src_top

and about "Gradfun3mod: wrong resizer value." are you sure you use the MT edit I did of Gradfun3mod?

[dREV]

Sorry I forgot to add your modded GradFun3mod, I didn't see it on your Avisynth script page, so had to look around but found them again, https://forum.doom9.org/showthread.php?p=1879909#post1879909.

Got errors though

ConvertBits(bits=16) #if it not 16 HBD already
ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(1280*2, 720*2,cshift="Spline64")
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

edi_rpow2:rfactorX must be a power of 2
(C:\path\plugins\edi_rpow2+ v1.0 mod 7.avsi, line 205)

Then I put in the other one you told me to write instead but got errors too

ConvertBits(bits=16) #if it not 16 HBD already
ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(fwidth=1280*2, fheight=544*2,cshift="Spline64")
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

YToUV: Video height ratio does not match any internal colorspace.

But I forgot had to change edi_rpow2(fwidth=1280*2, fheight=544*2,cshift="Spline64") to edi_rpow2(fwidth=1280*2, fheight=720*2,cshift="Spline64") and it worked because of how GradFun3mod is strict as it forces to use only 1280x720 resolution and won't allow any another resolution. So for sources where I have to crop (like the one I been having trouble on) I need to use DebilinearM or something else.

When I use some functions of edi_rpow2 to use the functions of nedi3_resize16() specifically nsize=6,pscrn=4,qual=2,etype=0 seems the screenshots I take became smaller instead of be the same or increase. Odd but I found the culprit to be pscn= when using "3" or "4" but using "1" and "2" do fine.

The nnedi3 documentation http://avisynth.nl/index.php/Nnedi3/nnedi3_rpow2
0 - no prescreening (same as false in prior versions)
1 - original prescreener (same as true in prior versions)
2 - new prescreener level 0
3 - new prescreener level 1
4 - new prescreener level 2

Higher levels for the new prescreener result in cubic interpolation being used on fewer pixels (so are slower, but incur less error). However, the difference is pretty much unnoticeable.
Level 2 is closest to the original prescreener in terms of incurred error, but is much faster. I wanted to use "4" but I this is alright

--------------------------------------------------------------------------------

I'm playing around with the HBD with your modded Gradfun3mod and having major issues with implementing certain functions such as
f3kdb(Y=65,Cb=65,Cr=65,grainY=65,grainC=65,mt=true,input_depth=16,output_depth=16)
Dither_add_grain16()

And I'm certain other filters that I need after resizing but basically majority of my scripts is centered around the lsb hack. It's slow trying to transition to HBD. I think I read that these filters can't use HBD and I also use
s16 = last
s16.Dither_limit_dif16 (last, thr=, elast=)
before I resize and cannot figure out how to implement this or even if I can do it in the first place with HBD.

How can i replace lsb with hbd on clean sources

#sometimes use 8 bit filter(s) here
dither_convert_8_to_16()
s16 = last
DitherPost()

Turn. #sometimes line darkening filter
#anti-aliasing filter.Turn

dither_convert_8_to_16()
s16.Dither_limit_dif16 (last, thr=0.25, elast=4.0)
SmoothGrad()

# resizer 4:4:4 DebilinearM or GradFun3mod
# grain filter
# if not using gradfun3mod resizer I use banding filter here
Dither_out()

What I'm looking for is the HBD equivalent of opening 8 bit to 16 bit and vice-versa like with the lsb hack's dither_convert_8_to_16(), DitherPost(), and Dither_out(). As whenever I use HBD with the resizer above my screen is green or is messed up when I'm trying to use the rest of my filters like Dither_add_grain16() grain filter which I need. How can I do this? I've tried what Natty posted but didn't work.


Thanks for your time in helping me out and trying to work out the other stuff. I also noticed how fast the resizer is with HBD and took less RAM on really interested if can get this to work completely.

Can you help me out on the [i]AddBorders() question too if you don't mind? Have issues with H264 but it works fine with HEVC. https://forum.doom9.org/showthread.php?p=1884673#post1884673

[real.finder]

the edit I did for Gradfun3mod not for HBD, because it use "dither tools" or better call it "lsb or Stacked tools" and it not work with HBD ofc, so you can't mix "dither tools" things with HBD or bad things happen unless you use http://avisynth.nl/index.php/ConvertStacked

about x264, you must ask someone else, anyway try put ConvertFromDoubleWidth() after Dither_out() and it will output native (HBD) 16 bit and remove --input-depth 16 (like you encode 8 bit clip)

[dREV]

the edit I did for Gradfun3mod not for HBD, because it use "dither tools" or better call it "lsb or Stacked tools" and it not work with HBD ofc, so you can't mix "dither tools" things with HBD or bad things happen unless you use http://avisynth.nl/index.php/ConvertStacked

about x264, you must ask someone else, anyway try put ConvertFromDoubleWidth() after Dither_out() and it will output native (HBD) 16 bit and remove --input-depth 16 (like you encode 8 bit clip)

Alright, I may just do it the easy way or something else on the AddBorders() thing with h264.


Didn't you say you can't mix dither tools with HBD? Dither_out() is part of the dither tools. Well I tried what you said

ConvertBits(bits=16) #if it not 16 HBD already
ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(fwidth=1280*2, fheight=720*2,cshift="Spline64")
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)
Dither_out().ConvertFromDoubleWidth()

error (I had a feeling this wasn't gonna work)
ConvertFromDoubleWidth: Input double width clip must be YV12, YV16, YV24, Y8, RGB24 or RGB32

I've tried manipulating around that and ConvertToStacked and I just can't figure it out.... I'm about to give up on this HBD thing. There's not enough information to the documentation nor examples for me to customize it like I did for lsb hack that came with the dither tools. If I can't get around this HBD to use other filters there's really no point. Sorry for wasting your time with me on that.

---------------------------------------------------------------------------------------------------

Also, I found something odd. I have some screenshot sample results of the same frame.

With DebilinearM:
DebilinearM (original script) 709 KB
DebilinearM (your version) 764 KB

With Gradfun3mod() I get:
Gradfunmod3 (original script) 794 KB
Gradfunmod3 (your version) 761 KB

Changed both the original and your version's thr from "01" instead of default "10" in the DebilinearM.avsi script as it gives too much sharpness creating halos. They also are using the lsb version not the HBD. I've manipulated scripts around and eliminating what may be the reason why it gives low output and it seems to be your modded version of nnedi3_resize16_v3.3. Everything else was the same file size except when I used that script it would go down and that one only.

Latest screenshots results were using GradFun3mod

original 781 kb
your version 755 kb

In addition when I use GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true) file size is high (781 kb) but when I switch to GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true) it goes down (to 755 kb) both using the original nnedi3_resize16_v3.3 script. However, even when I use your modded nnedi3 version together with both functions of Gradfun3mod they still give results 755 kb. Only when returning to the original nnedi3 script does it return to normal as well as using the original GradFun3mod function.

All of this was using your updated scripts from ResizeX v1.0.1 mod 9.35, edi_rpow2 v1.0 mod 7, Gradfun3mod r6 mod 3.1, DebilinearM v1.3.1 mod 1.25, etc

Seems the original Gradfun3mod output has increased detail moreso then with both the original and your version of DebilinearM also. What you think?

[real.finder]

I think you need to know the basic of what lsb (aka dither tools things aka Stack16) and what is HBD in avs+, why don't you read the wiki link I post many many times?!!! they can't be mixed UNLESS with http://avisynth.nl/index.php/ConvertStacked (the link you don't read or don't understand its content every time) and btw you already mixed both (even without ConvertFromDoubleWidth by using Dither_out with HBD input so the output will be 100% wrong indeed) but in wrong way

do not expect getting a result identity by 100% matching if the script or the used plugins or even the avs changed/updated, and that normal since the edit I did for GradFun3mod and DebilinearM will use yet another plugins away from original Debilinear.dll

and my edit of nnedi3_resize16 in avs+ even with lsb it will use some HBD features to get real 16bit as possible since nnedi3_resize16 with lsb don't do real 16 bit proccess in first place since nnedi3 don't has lsb support, so yes without set the nlsb in nnedi3_resize16 to false in avs+ you will get a different result and it should be a better

[dREV]

I think you need to know the basic of what lsb (aka dither tools things aka Stack16) and what is HBD in avs+, why don't you read the wiki link I post many many times?!!! they can't be mixed UNLESS with http://avisynth.nl/index.php/ConvertStacked (the link you don't read or don't understand its content every time) and btw you already mixed both (even without ConvertFromDoubleWidth by using Dither_out with HBD input so the output will be 100% wrong indeed) but in wrong way

Listen man. I keep writing my posts in very plain English as best I can. I've read so many posts on doom9 that I've come to the conclusion that getting simple plain English is at times out of reach of its many posters.

My entire confusion came from your post of this ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(fwidth=1280*2, fheight=720*2,cshift="Spline64")
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

I've read http://avisynth.nl/index.php/ConvertStacked many times and I've asked the simplest question of how to turn off and on 8 bit to 16 bit and vice-versa. If it was me speaking to somebody who was like myself I would of wrote to him/her that

ConvertToStacked() and ConvertFromStacked() is kinda = dither_convert_8_to_16()

done, nothing complicated, no necessary posts, nada with additional notes. If you know what was in the lsb hack http://avisynth.nl/index.php/Dither_tools this concept of To and From DOES NOT EXIST and this is what I was going by.

The documentation says NOTHING about this. While I also had the pressing issue of finding a way how to go to 8 bit to 16 bit and vice-versa was my MAIN CONCERN after your modded resizer scripts. I kept writing ConvertBits(bits=8) thinking it was dither_convert_8_to_16() but it was NOT working!

I don't even know what your correlation of ConvertFromDoubleWidth() is with Dither_out() I need a DitherPost(mode=-1) equivalent.

And no I was not using Dither_out() at all until I wrote what you said. On avspmod it's been only DitherPost(mode=-1) and I had to turn it off as it was NOT working with HBD that and you should know that Dither_out() on avspmod would result in green or something that would not look correct.


do not expect getting a result identity by 100% matching if the script or the used plugins or even the avs changed/updated, and that normal since the edit I did for GradFun3mod and DebilinearM will use yet another plugins away from original Debilinear.dll

and my edit of nnedi3_resize16 in avs+ even with lsb it will use some HBD features to get real 16bit as possible since nnedi3_resize16 with lsb don't do real 16 bit proccess in first place since nnedi3 don't has lsb support, so yes without set the nlsb in nnedi3_resize16 to false in avs+ you will get a different result and it should be a better

That's not how it should be. The detail loss is apparent and it's not worth using your nnedi3 version over the original if detail is loss. Don't take that with disrespect which seems you may have.

-----------------------------------------------------

I'm having some issues with your MAA2 script and ConvertBits. Everything works fine on avspmod but when it comes time to encode I get errors.

For MAA2 script on MeGUI it states this: Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

Everything is above the requirement to use this script. The original works just fine. I dunno how to go about where the issue is for this one.

For ConvertBits maybe it's the combination of MeGUI ver2525, HEVC (latest 3.1.0.14), using the old lsb hack to pipe. It just says this on MeGUI

---[NoImage] AssumeTFF()
---[NoImage] LoadPlugin("C:\Path\avstp.dll")
---[NoImage] LoadPlugin("C:\Path\dfttest.dll")
---[NoImage] LoadPlugin("C:\Path\AddGrainC.dll")
---[NoImage] LoadPlugin("C:\Path\dither.dll")
---[NoImage] Import("C:\Path\dither.avsi")
---[NoImage] LoadPlugin("C:\Path\mvtools2.dll")
---[NoImage] LoadPlugin("C:\Path\masktools2.dll")
---[NoImage] Import("C:\Path\mt_xxpand_multi.avsi")
---[NoImage] LoadPlugin("C:\Path\RgTools.dll")
---[NoImage] LoadPlugin("C:\Path\fturn_26.dll")
---[NoImage] #Import("C:\Path\Antialiasing_MAA2.avsi")
---[NoImage] LoadPlugin("C:\Path\SangNom2.dll")
---[NoImage] LoadPlugin("C:\Path\DctFilter.dll")
---[NoImage] LoadPlugin("C:\Path\nnedi3.dll")
---[NoImage] Import("C:\Path\Contra_Sharpen_mod_3.4.avsi")
---[NoImage] LoadPlugin("C:\Path\SmoothAdjust.dll")
---[NoImage] Import("C:\Path\EdgeCleaner1.04.avsi")
---[NoImage] LoadPlugin("C:\Path\aWarpSharp.dll")
---[NoImage] Import("C:\Path\Hysteria_20161019.avsi")
---[NoImage] #Import("C:\Path\LSFmod.v1.9.avsi")
---[NoImage] LoadPlugin("C:\Path\warpsharp.dll")
---[NoImage] Import("C:\Path\FineSharp.avsi")
---[NoImage] LoadPlugin("C:\Path\flash3kyuu_deband.dll")
---[NoImage] Import("C:\Path\flash3kyuuMOD16.avsi")
---[NoImage] #Import("C:\Path\DebilinearM_v1.3.1.avsi")
---[NoImage] LoadPlugin("C:\Path\debilinear.dll")
---[NoImage] LoadPlugin("C:\Path\debicubic.dll")
---[NoImage] #Import("C:\Path\ResizeX_v1.0.1.avsi")
---[NoImage] Import("C:\Path\HQDeringmod_v1.8.avsi")
---[NoImage] LoadPlugin("C:\Path\MedianBlur2.dll")
---[NoImage] #Import("C:\Path\DeHalo_FineDehalo.avsi")
---[NoImage] #Import("C:\Path\GradFun3mod.avsi")
---[NoImage] LoadPlugin("C:\Path\EdgeFixer.dll")
---[NoImage] LoadPlugin("C:\Path\FillMargins.dll")
---[NoImage] Import("C:\Path\SMDegrain_plus v.3.1.2.104s.avsi")
---[NoImage] Import("C:\Path\GradFun3mod_plus r6 mod 3.1.avsi")
---[NoImage] Import("C:\Path\nnedi3_resize16_v3.3_plus.avsi")
---[NoImage] Import("C:\Path\edi_rpow2_plus v1.0 mod 7.avsi")
---[NoImage] Import("C:\Path\ResizeX_plus v1.0.1_mod 9.35.avsi")
---[NoImage] Import("C:\Path\DebilinearM_plus v1.3.1_mod_1.25.avsi")
---[NoImage] Import("C:\Path\LSFmod_plus v2.183.avsi")
---[NoImage] Import("C:\Path\DeHalo_FineDehalo_plus v1.1 mod8.75.avsi")
---[NoImage] LoadPlugin("C:\Path\despot.dll")
---[NoImage] ConvertBits(bits=16) #if it not 16 HBD already
---[NoImage] #GradFun3mod(thr=0.05, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
---[NoImage] ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
---[NoImage] lc = edi_rpow2(fwidth=1280*2, fheight=720*2,cshift="Spline64",nsize=6,pscrn=2,qual=2,etype=0)
---[NoImage] lu = lc.ExtractU()
---[NoImage] lv = lc.ExtractV()
---[NoImage] YtoUV(lu,lv,ly)
---[NoImage] Dither_out()
--[Error] [9/13/2019 10:32:16 AM] An error occurred
---[Error] [9/13/2019 10:32:16 AM] Exception message
----[NoImage] The file Z:\samples\# # megui\work\n1rzueuv.2zd\test.avs cannot be opened.
----[NoImage] Error message for your reference: Script error: there is no function named "ConvertBits"
----[NoImage] (Z:\samples\# # megui\work\n1rzueuv.2zd\test.avs, line 47)
---[Error] [9/13/2019 10:32:16 AM] Stacktrace
----[NoImage] at MeGUI.JobUtil.GetAllInputProperties(UInt64& nbOfFrames, Double& framerate, Int32& framerate_n, Int32& framerate_d, Int32& hRes, Int32& vRes, Dar& dar, String video)
----[NoImage] at MeGUI.JobUtil.getInputProperties(UInt64& nbOfFrames, Double& framerate, String video)
----[NoImage] at MeGUI.OneClickPostProcessing.StartPostProcessing()
---[Error] [9/13/2019 10:32:16 AM] Inner exception
----[Error] [9/13/2019 10:32:16 AM] Exception message
-----[NoImage] Script error: there is no function named "ConvertBits"
-----[NoImage] (Z:\samples\# # megui\work\n1rzueuv.2zd\test.avs, line 47)
----[Error] [9/13/2019 10:32:16 AM] Stacktrace
-----[NoImage] at MeGUI.AviSynthClip..ctor(String func, String arg, AviSynthColorspace forceColorspace)
-----[NoImage] at MeGUI.AvsFile..ctor(String script, Boolean parse)
-----[NoImage] at MeGUI.JobUtil.GetAllInputProperties(UInt64& nbOfFrames, Double& framerate, Int32& framerate_n, Int32& framerate_d, Int32& hRes, Int32& vRes, Dar& dar, String video)
----[Error] [9/13/2019 10:32:16 AM] Inner exception: null
--[Information] [9/13/2019 10:32:16 AM] Job completed

As can see I used only the HBD Gradfun3mod script nothing else. With the MAA2 script I used the lsb hack.

[real.finder]

maa2 use SangNom2 which not work with HBD (yet) :)

and that log said 'there is no function named "ConvertBits"' which mean it not use the avs+, MeGUI already use it's own avisynth

ConvertToStacked() and ConvertFromStacked() is kinda = dither_convert_8_to_16()

that wrong, dither_convert_8_to_16() is kinda mean ConvertBits(16) in HBD, ConvertToStacked mean Convert HBD clip to Stacked clip to use it in old filters that not work with HBD yet but work with lsb (Stacked), and GradFun3mod (even my edit of it) not work with HBD, but my edit of DebilinearM work with HBD

detail loss in my edit of nnedi3_resize16? post your script with video sample, and are you use the last nnedi3 plugin? did you try set nlsb to false?

Dither_out and ConvertFromDoubleWidth FOR YOUR x264 Borders problem IF you still using the lsb/Stack16 things not if you use 8bit or HBD

in HBD ConvertBits(bits=8, dither=-1) is DitherPost(mode=-1) equivalent, don't know if you know but you don't need ConvertBits(bits=8) just for avspmod, it work with HBD nowadays

btw, I did many edits for http://avisynth.nl/index.php/ConvertStacked and added another example for lsb

[Natty]

damn i gave you a short example already but i think you ignored it. i would recommend you to forget HBD and just stick to lsb (dither tools).
HBD is too slow to encode anyways. except the case of f3kdb neo.

[real.finder]

damn i gave you a short example already but i think you ignored it. i would recommend you to forget HBD and just stick to lsb (dither tools).
HBD is too slow to encode anyways. except the case of f3kdb neo.

dREV has many problems so I'm not surprised of ignored or not note it, but anyway it's also in wiki and in my posts but seems dREV still don't get the point of these functions/examples

about the speed, lsb is slower when it did real 16bit, HBD is faster and you can see that in SMDegrain(n16_out=true) vs SMDegrain(lsb_out=true) see here https://forum.doom9.org/showthread.php?p=1837210#post1837210

must lsb things don't do real or at least don't do full 16bit process so you may see HBD slow compare to it

you can try DebilinearM using DeResizeMT=true with HBD vs lsb and see. even if it do masking in 8bit with lsb it should give you more speed with HBD and better result

[Natty]

dREV has many problems so I'm not surprised of ignored or not note it, but anyway it's also in wiki and in my posts but seems dREV still don't get the point of these functions/examples

about the speed, lsb is slower when it did real 16bit, HBD is faster and you can see that in SMDegrain(n16_out=true) vs SMDegrain(lsb_out=true) see here https://forum.doom9.org/showthread.php?p=1837210#post1837210

must lsb things don't do real or at least don't do full 16bit process so you may see HBD slow compare to it

you can try DebilinearM using DeResizeMT=true with HBD vs lsb and see. even if it do masking in 8bit with lsb it should give you more speed with HBD and better result

yes i recommended him lsb only because he is mixing lsb and hdb incorrectly.

yes n16 is fast, f3kdb neo is fast. but plugins like finedehalo get too much slow.

[dREV]

maa2 use SangNom2 which not work with HBD (yet) :)

Huh? With the MAA2 script I used the lsb hack. https://forum.doom9.org/showthread.php?p=1884808#post1884808

Again it's not working with the lsb hack the original MAA2 worked just fine using all dlls requirements including SangNom2 ver v0.35. I never wrote that I did this using HBD.

and that log said 'there is no function named "ConvertBits"' which mean it not use the avs+, MeGUI already use it's own avisynth

Oh ok I've read about this and they said that in MeGUI 32 bit there's an option under Settings > Main Configuration > Always use the included AviSynth but it's already been checked, so I guess this is an issue with the MeGUI I'm using as it's not working properly while the MeGUI 64 bit version works just fine, so had to get the AviSynth+ dll from the System folder and put it in MeGUI and overwrite the AviSynth 2.0.6 and now it works.

However, it's ConvertToDoubleWidth() seems to be the equivalent to Dither_out() not ConvertFromDoubleWidth() as I kept getting issues with the video when I followed that instruction. Again I've been literally cleaving to the words you've said to me since I'm new to AviSynth+ and trying them out and reporting back. Dither_out() did not work at all with HBD it kept ruining the video also when I use ConvertBits(8) on both avspmod and encoding it.

And also your MAA2 script now works with the removal of AviSynth 2.0.6 version from MeGUI.

damn i gave you a short example already but i think you ignored it. i would recommend you to forget HBD and just stick to lsb (dither tools).
HBD is too slow to encode anyways. except the case of f3kdb neo.

I didn't ignore it I even tried it but seems you ignored it my post.

I've tried what Natty posted but didn't work. https://forum.doom9.org/showthread.php?p=1884721#post1884721

As I've already wrote and writing it yet once again I specifically wrote that the concept of "To" and "From" does not exist for a person like myself whose been using lsb hack for a long time especially since they are AviSynth+ exclusive which I came from using AviSynth 2.0.6 32 bit version trying to transition to 64 bit. and my mindset was set on this. Your example didn't help me get over this hurdle whatsoever as I thought there was going to be a 1:1 transition not a 1:2, I need issue resolving my issue not what you insinuate nor what makes it look I'm intentionally doing something I'm not. Note also you posted your example AFTER real-finder was helping me on getting HBD to work with his Gradfun3mod + edi_rpow2 function.

Your example was NOT going to help me regardless especially since I'm not even using a simple resizer as your example shows as I've been only using an advance function as I'm certain you've seen it by now and it was NOT working despite not being the one who made that function. I was using what I was being supplied with.

And from what I'm getting seems I have to do this 2 x for EACH function (before and after) that supports HBD. HBD is slow? real.finder keeps saying it's faster then lsb? I haven't tested it obviously but I'll find out.


that wrong, dither_convert_8_to_16() is kinda mean ConvertBits(16) in HBD, ConvertToStacked mean Convert HBD clip to Stacked clip to use it in old filters that not work with HBD yet but work with lsb (Stacked), and GradFun3mod (even my edit of it) not work with HBD, but my edit of DebilinearM work with HBD

OK to let this be over with I was doing my testing based on a non-HBD resizer function that I was supplied with to use and ONLY after I was told different with Gradfun3mod + edi_rpow2 all while I was trying to get the next 16 bit filter to work and it was not working and this was using ConvertBits(8). Look through all of the posts since I started to post back to page 13 and keep in mind this is centered around the the resizer > then everything else. So if you've mocked me and had in mind that I was stupid in your heart know where I was at combined with my post that getting simple plain English from doom9 is out of reach in addition that this HBD is 2 x (To and From) functions now instead of lsb hack which was a simple dither 8 to 16, dither post, and dither out. Very plain and easy.

detail loss in my edit of nnedi3_resize16? post your script with video sample, and are you use the last nnedi3 plugin? did you try set nlsb to false?

I've already laid out what it was. I already wrote everything is using the same filters except your NNEDI script only and it's using lsb hack. It instead uses the original NNEDI3. The nnedi3 plugin I'm using is version 0.9.4.51 and no I did not set nlsb I didn't know that existed as that's not in the original.

I have tested it putting nlsb off and there was no change. Note that I'm only using lsb functions and may just stick to it.


Dither_out and ConvertFromDoubleWidth FOR YOUR x264 Borders problem IF you still using the lsb/Stack16 things not if you use 8bit or HBD

in HBD ConvertBits(bits=8, dither=-1) is DitherPost(mode=-1) equivalent, don't know if you know but you don't need ConvertBits(bits=8) just for avspmod, it work with HBD nowadays

btw, I did many edits for http://avisynth.nl/index.php/ConvertStacked and added another example for lsb

My AddBorders() issue and my posts here are two entirely different matters. I'm not really certain what you're talking about on this at all because if you read the script I used on my issue for the AddBorders you'd see me using Dither_out https://forum.doom9.org/showthread.php?p=1884083#post1884083 if it's something else then clarify as I don't understand if you trying to help me fix my issue with AddBorders in h264.


dREV has many problems so I'm not surprised of ignored or not note it, but anyway it's also in wiki and in my posts but seems dREV still don't get the point of these functions/examples

So which is it? Ignored or note it or something else? Even when I state my reasoning and my confusion my post gets blatantly ignored. So whose really ignoring or not noting? :rolleyes:

Writing this post was almost a complete waste of time having to explain myself YET again but what I won't be is surprised that it gets ignored.

[real.finder]

you said
I'm having some issues with your MAA2 script and ConvertBits.
ConvertBits = HBD things, so how you then said "I never wrote that I did this using HBD."?!

Dither_out() output clip same as ConvertToDoubleWidth() BUT not same input clip and usage

those "HBD is 2 x (To and From) functions" not for pure HBD and that should be something very clear, THEY are for mixing HBD and lsb if you didn't find updated or alternative filter for YOUR lsb Favorite filter, in pure HBD case you dont need any thing (even ConvertBits if your source already more than 8 bit) mean you deal with it as 8bit clip most of times

I didn't get what you get with nlsb=false, but with nlsb=false both my edit and the original will be same unless there are bug

============================

the Reply to dREV end here

=================

@Natty, 16bit process should be slower than 8bit, that normal, and finedehalo don't has lsb in first place

@everyone

I plan to change many things, move the avs versions functions to independent script, and move the General functions to another independent script and start using github as replacement for pastebin and doom9 Attached, and there will be many updates for filters, all this after pinterf add the changes that I waiting for

[dREV]

I think I've finally got it down mixing ConvertBits() and LSB and Convert To and From[/] Stacked but the only issue I have now is understanding when to use ConvertToDoubleWidth(). Is this only only for HBD filters or something? The link http://avisynth.nl/index.php/ConvertStacked seems to point that it is and just need a confirmation if this is true. I only know the one to end the HBD stacked which as I wrote before being Convert[b]FromDoubleWidth().


In another matter, as I wrote before about your NNEDI3 script having less quality then the 32 bit counterpart of a previous version of NNEDI3 there's another issue that I came about when it came to encoding.

Using my script combined with ConvertBits(16) and ConvertToStacked() and your NNEDI3 script it takes over 6 minutes for the encoder to prepare the encode and when it's ready the fps is slooooow and I mean sloooow 1-5 fps and I am on a Ryzen 5 2nd generation. I don't think it's at my end that's the issue.

I thought maybe I had the wrong ResampleMT.dll and/or NNEDI3.dll but I read Ryzen seems to supports AVX2 (I even tried the others too with the same results tho) but then I changed the NNEDI3 script to a previous version one from 2017 and 2015 (one of several other versions I have too) and it ran like normal, super quick like it should be and started to encode in less than 30 seconds. I even tried without any HBD stacked and just using LSB and still had the same issue.

Keep in mind as I wrote before this script by itself is the culprit as I've narrowed it down one by one just as I did before. Something is very wrong with it besides just not being the same quality as the one I've been using on my 32 bit filters only to surpass it but only with the help of stacked. I used both versions of MeGUI 32 bit and 64 bit versions using the latest HEVC encoder https://forum.doom9.org/showthread.php?p=1884762#post1884762. I dunno why the latest NNEDI3 script works just fine on avspmod but not on the encoder they both are using literally the same script chain.

Here are all of the scripts so you can see for yourself. I even included both 32 and 64 bit AviSynth plugins for easy drag/drop testing to see yourself and replicate it tho I dunno what GUI you use as I am exclusively using only MeGUI plus I included my actual scripts tho only for 720p.

They are in .rar format using WinRar 5.71 http://www.mediafire.com/file/xvceiyblz5hhz82/ScriptSample01.rar/file.

In all honesty it may not be your NNEDI3 script alone for the small loss in quality (tho with stacked HBD it terms of file size png images has become more then the 32 bit but only on avspmod doing a few comparisons) but may also be in part to ResampleMT.dll and NNEDI3.dll being ports to the 64 bit not done by the original creator. I would have to do more comparisons cuz seems I am using three to four versions of the NNEDI3 scripts. I always thought the 64 bit version is suppose to be better then the 32 bit.

Also, I think putting it up on GitHub is a good idea as it'll be easier to get a previous version if something goes wrong with the latest update like what's happening with the NNEDI3 script.

[real.finder]

as the link said in notes, DoubleWidth is another kind of hack using 8bit clip to convey 16bit by make it Double Width, it's also mentioned here http://avisynth.nl/index.php/Dither_tools#Formats

I will not repeat what I said before about how lsb things like nnedi3_resize16 use 8bit many times and why sometimes seems faster (all that in my Replies to Natty), anyway saying "less quality" when nnedi3_resize16 try give you real 16 bit as possible mean it's better for you to stay with 8bit Especially in your scripts seems you get rid of most if not all benefits of 16bit whether it's lsb or HBD by going to 8bit many times, and I didn't see you use nlsb=false with last nnedi3_resize16 in your scripts

x64 (64 bit) not always give same output as x86 (32 bit) but x64 should be faster (not always), It depends on the plugins (dll) and the asm code in it and the cpu, if you have problem (like big difference in output with same scripts "both avs and avsi") then you should report that in the plugins threads not here

and the output of encoders is also another topic, here you should just use avspmod, and for me the output of nnedi3_resize16 (without nlsb=false) has more quality (details and sharp) but half speed

[Natty]

thanks for n3_r16 update, i see nlsb is for hbd + lsb

so if i set nlsb=true, lsb=true, lsb_in=true, the output will be real 16bit stacked (better than before)? :thanks:

and default value of dither is 50.which dithering method does 50 use?

[real.finder]

thanks for n3_r16 update, i see nlsb is for hbd + lsb

so if i set nlsb=true, lsb=true, lsb_in=true, the output will be real 16bit stacked (better than before)? :thanks:

and default value of dither is 50.which dithering method does 50 use?

the letter "n" for Native, which mean hybrid (Native HBD and lsb) kinda like what I did for YUY2 support in avs26 by using YV16 inside the functions as stopgap since (at least back then) not many filters updated to support YV16 and in the same time YUY2 removed from the updated one

and yes it will better than before, aside from that I did also added nlsb in admfilter while ago (before add it in Nnedi3_resize16) for Motion-Compensated and also true by Default in avs+

and from the scripts itself the default values of dither are

dither = tv_range ? Default(dither, 6) : Default(dither, 50) # dither mode for 16-bit to 8-bit conversion

and in nnedi3_resize16_U16

dither = Default(dither, -1 ) # -1 for no dither, 0 for ordered-dither, 1-100 for noise strength

and you can read the Documentation of SmoothAdjust since it used when full range (DitherPost used in tv range)

[Natty]

thanks for explaining. but i still don't know what method will dither=50 use. maybe it's just the strength of noise

and will output be correct is this case?

ConvertBits(16)
ConvertToStacked()
nnedi3_resize16(mysettings, nlsb=true,
lsb_in=true, lsb=true, tv_range=true)
Dither_convert_yuv_to_rgb(matrix="601", output="rgb48y", tv_range=true, lsb_in=true)
r = SelectEvery(3, 0)
g = SelectEvery(3, 1)
b = SelectEvery(3, 2)
Dither_convert_rgb_to_yuv(r, g, b, matrix="709", tv_range=true, lsb=true)
HQDeringmod(lsb_in=true, lsb=true, lsb_out=true, tv_range=true)
ConvertFromStacked()

[real.finder]

thanks for explaining. but i still don't know what method will dither=50 use. maybe it's just the strength of noise

and will output be correct is this case?

ConvertBits(16)
ConvertToStacked()
nnedi3_resize16(mysettings, nlsb=true,
lsb_in=true, lsb=true, tv_range=true)
Dither_convert_yuv_to_rgb(matrix="601", output="rgb48y", tv_range=true, lsb_in=true)
r = SelectEvery(3, 0)
g = SelectEvery(3, 1)
b = SelectEvery(3, 2)
Dither_convert_rgb_to_yuv(r, g, b, matrix="709", tv_range=true, lsb=true)
HQDeringmod(lsb_in=true, lsb=true, lsb_out=true, tv_range=true)
ConvertFromStacked()

you should ask the original Author about it, anyway I told you to read the Documentation of SmoothAdjust
dither [default: 75]
--------------------
Type of the dithering
-1 = dithering OFF
0 = pattern
xx = intermediary
100 = noise

and I think if you use 50 with tv range you will get error from DitherPost

and what you mean by correct? real 16bit? if it so then I don't think so since I think HQDeringmod is also used some 8bit mix with lsb, and since I don't use it and it's kinda big script (I guess) I don't think I will touch it at least soon, so anyone can feel free edit it

edit: and what is the point of Dither_convert_yuv_to_rgb and Dither_convert_rgb_to_yuv? you can use avsresize aka z_ConvertFormat (https://forum.doom9.org/showthread.php?t=173986) which work with HBD and faster and even has many new things and did the job better

[Natty]

i have read smoothadjust docs .))

point was to convert 601 to 709.

ok I'll try z_ConvertFormat too. :thanks:

[LouieChuckyMerry]

Hi real.finder, I hope you're well :) . Some months ago you helped me upgrade from x86 AviSynth+ with SMDegrain LSB to x64 AviSynth+ with SMDegrain native HBD, which almost doubled my encoding speed. :thanks: . Recently I encountered a situation where the encoding speed is much much much slower and I hoped you'd have a solution. The following script with a 1080p source took about 1.5 hours for the first pass and 2.5 hours for the second pass:

SetMemoryMax(1024)
SetMTMode(3,3)
LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetMTMode(2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
LinearResize(1280,720,Kernel="Bicubic",A1=-0.5,A2=0.25,LSB_In=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,LSB_In=True,LSB=True)
Dither_Out()

however, the following script takes almost 12 hours just for the first pass (I've not bothered with a second pass):

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

Do you have any idea why the native HDB script takes eight times longer? Thanks for your time.


EDIT: OK. A bit of searching and testing later, it seems that EDI_RPow2 is designed for upscaling, not downscaling. Could you please recommend a filter-plugin for downscaling in native HBD? Thanks.

[real.finder]

Hi real.finder, I hope you're well :) . Some months ago you helped me upgrade from x86 AviSynth+ with SMDegrain LSB to x64 AviSynth+ with SMDegrain native HBD, which almost doubled my encoding speed. :thanks: . Recently I encountered a situation where the encoding speed is much much much slower and I hoped you'd have a solution. The following script with a 1080p source took about 1.5 hours for the first pass and 2.5 hours for the second pass:

SetMemoryMax(1024)
SetMTMode(3,3)
LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetMTMode(2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
LinearResize(1280,720,Kernel="Bicubic",A1=-0.5,A2=0.25,LSB_In=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,LSB_In=True,LSB=True)
Dither_Out()

however, the following script takes almost 12 hours just for the first pass (I've not bothered with a second pass):

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

Do you have any idea why the native HDB script takes eight times longer? Thanks for your time.


EDIT: OK. A bit of searching and testing later, it seems that EDI_RPow2 is designed for upscaling, not downscaling. Could you please recommend a filter-plugin for downscaling in native HBD? Thanks.

I didn't have internet for almost a whole week ago, now is back but don't know if they will cut it again, anyway you can use ResizeX for downscaling

Regarding the slowing, you can back some pages ago here to know that not always HBD is faster since the lsb method in scripts most of times not real 16 bit process unlike the HBD but anyway I will check it later and see what is the bottleneck or why it's slow

[StainlessS]

Real.finder, I just posted about this in devs forum,
he's DOWNSIZING but using EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720), so 1080p source is first being upsized to 2160p and then downsized to 720p,
thats what is eating up time.

EDIT: Replace

EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)

with

Spline64Resize(1280,720)


EDIT: Ie,

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)


To

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
Spline64Resize(1280,720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)


EDIT: Also, quality is bound to have suffered due to the EDI upsize, then downsize, it was not necessary.

[LouieChuckyMerry]

I didn't have internet for almost a whole week ago, now is back but don't know if they will cut it again, anyway you can use ResizeX for downscaling

Regarding the slowing, you can back some pages ago here to know that not always HBD is faster since the lsb method in scripts most of times not real 16 bit process unlike the HBD but anyway I will check it later and see what is the bottleneck or why it's slow

The slowing was because I was ignorant to the fact that EDI_RPow2 is for upscaling only, as StainlessS states below, so please don't waste your time checking for a bottleneck. I hope your internet connection has stabilized :) .


Real.finder, I just posted about this in devs forum,
he's DOWNSIZING but using EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720), so 1080p source is first being upsized to 2160p and then downsized to 720p,
thats what is eating up time.

EDIT: Replace

EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)

with

Spline64Resize(1280,720)


EDIT: Ie,

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)


To

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
Spline64Resize(1280,720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)


EDIT: Also, quality is bound to have suffered due to the EDI upsize, then downsize, it was not necessary.

Thanks, StainlessS, for the acknowledgement of my ignorance. Now to the AviSynth+ thread...

[real.finder]

maybe EDI_RPow2 need some code to make sure it will not be used in downsize, but that will happen later (when pinterf back with the updates)

I note you use F3KDB, there are "Neo f3kdb" since F3KDB will stay only for old things

I hope your internet connection has stabilized :) .

last days we got worst Internet than PRC or even worst than DPRK since even the local sites not works, and when it back it's very slow without social media sites ofc, They even used snipers to confront young people demonstrating!

[Natty]

i see that aWarpSharp4xx has only 1 lsb switch. no lsb_in or out. will output be correct of 16bit stacked is feeded like aWarpSharp4xx(lsb=true)?

[real.finder]

i see that aWarpSharp4xx has only 1 lsb switch. no lsb_in or out. will output be correct of 16bit stacked is feeded like aWarpSharp4xx(lsb=true)?

it's like lsb_inout in other plugins, anyway it's don't do any real 16 bit process

[Natty]

it's like lsb_inout in other plugins, anyway it's don't do any real 16 bit process

understood ;) hope everything becomes fine there soon. :thanks:

[Natty]

SMDegrain(tr=2, thSAD=200, lsb=true, Contrasharp=60, RefineMotion=false)

this is giving error : there is no function named "padding"

lsfmod line: 617

smdegrain line: 545

[StainlessS]

function Padding(clip c, int left, int top, int right, int bottom) {
# Didee: http://forum.doom9.org/showthread.php?p=1596804#post1596804
# eg, Padding(32,32,0,0).Padding(0,0,32,32)
w = c.width()
h = c.height()
c.pointresize( w+left+right, h+top+bottom, -left, -top, w+left+right, h+top+bottom )
}

[real.finder]

or in Advanced Denoising.avsi, and it's already edited for mt resizer

[Natty]

function Padding(clip c, int left, int top, int right, int bottom) {
# Didee: http://forum.doom9.org/showthread.php?p=1596804#post1596804
# eg, Padding(32,32,0,0).Padding(0,0,32,32)
w = c.width()
h = c.height()
c.pointresize( w+left+right, h+top+bottom, -left, -top, w+left+right, h+top+bottom )
}



understood :)

[Natty]

or in Advanced Denoising.avsi, and it's already edited for mt resizer

thanks its working now. :devil:

[hello_hello]

real.finder,

Could you add a link for Hqdn3dY to the opening post, because that seems to be a bit of an obscure one.
I tried using ASTDR today, which I'm sure I've used before, but today it gave me a "no such function as Hqdn3dY" error, and initially thinking that was one of your functions and a case of function inter-dependency hell, it took me a while to discover Hqdn3dY is an actual plugin, possibly still only surviving due to The WayBack Machine. I doubt I would have found it without searching the forum because I couldn't find it via a standard google search.

Anyway, aside from getting that off my chest, I thought I'd let you know the attached rar files for the Advanced Denoising functions here seem to be corrupted. https://forum.doom9.org/showthread.php?p=1881052#post1881052
Both WinRAR and 7-Zip claim they're not archive files.

Thanks for you continued hard work!

PS I still think a single script containing all the "helper functions" required by your other functions would be a better way to do things than having unrelated functions depend on each other. The example above of requiring Advanced Denoising.avsi in order to make SMDeGrain.avsi work is one where a function dependency is far from obvious.

Cheers.

[real.finder]

real.finder,

Could you add a link for Hqdn3dY to the opening post, because that seems to be a bit of an obscure one.
I tried using ASTDR today, which I'm sure I've used before, but today it gave me a "no such function as Hqdn3dY" error, and initially thinking that was one of your functions and a case of function inter-dependency hell, it took me a while to discover Hqdn3dY is an actual plugin, possibly still only surviving due to The WayBack Machine. I doubt I would have found it without searching the forum because I couldn't find it via a standard google search.

the last one here https://forum.doom9.org/showthread.php?p=1781025#post1781025 and it's already had link in http://avisynth.nl/index.php/AviSynth%2B_x64_plugins but maybe it's better if someone add it in http://avisynth.nl/index.php/External_filters



Anyway, aside from getting that off my chest, I thought I'd let you know the attached rar files for the Advanced Denoising functions here seem to be corrupted. https://forum.doom9.org/showthread.php?p=1881052#post1881052
Both WinRAR and 7-Zip claim they're not archive files.

Thanks for you continued hard work!

it's seems fine https://i.imgur.com/DNL6ILo.png


PS I still think a single script containing all the "helper functions" required by your other functions would be a better way to do things than having unrelated functions depend on each other. The example above of requiring Advanced Denoising.avsi in order to make SMDeGrain.avsi work is one where a function dependency is far from obvious.

Cheers.

that will be done as soon as pinterf update avs+ and masktools and if the Internet is not interrupted

[hello_hello]

it's seems fine https://i.imgur.com/DNL6ILo.png

It's fine for me now too, but I swear I downloaded both at least three times yesterday and they wouldn't open. Gremlins...

that will be done as soon as pinterf update avs+ and masktools and if the Internet is not interrupted

Awesome!

Cheers.

[dREV]

Hi again, to bother with questions. :eek:

I'm trying to figure out how to use other resizers with DebilinearM. I'm trying out gauss / gaussian http://avisynth.nl/index.php/Resize#GaussResize for my source that has halo's to see if this will work better than just using your DeHalo_alpha_MT2 script but I dunno how to adjust the float p parameter or if it's even possible.

Keep in mind that I am also using it in conjunction with GradFun3mod https://forum.doom9.org/showthread.php?p=1879765#post1879765 and https://forum.doom9.org/showthread.php?p=1879909#post1879909 from several pages ago, so I know I cannot write it (below) and has to be in the DebilinearM script.

dither_convert_8_to_16()
ly = GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

I see the script says: function DebilinearM(clip input, int target_width, int target_height, int "thr", int "expand", int "inflate", string "kernel",
int "taps", float "a1", float "a2", bool "cubic", float "b", float "c", bool "chroma", bool "lsb_inout", int "showmask", bool "DeResizeMT")

thr = Default(thr, 10)
expand = Default(expand, 1)
inflate = Default(inflate, 2)
kernel = Default(kernel, "Spline36")
cubic = Default(cubic, false)
chroma = Default(chroma, true)
lsb_inout = Default(lsb_inout, false)
DeRMT = Default(DeResizeMT, false)
showmask = Default(showmask, 0)

Is it possible to adjust this so I can play around with the Guass float's default of 30.0? :confused:

I'd also like to know how to use the taps parameter for the sinc resizer for blurry sources. Is it possible to also use other resizers?

[real.finder]

in nnedi3_resize16 and DebilinearM it's like dither_resize16 you can by a1 and a2, but in GradFun3mod you can't

[dREV]

I never used the parameter before, so was wondering how to use them but I think I figured it out thanks to a site and seems to work (also had an explanation for few of the parameters) sadly I have to create a custom DebilinearM script.

In DebilinearM it's
# a1 = Default(a1, 30) #b parameter of bicubic upscale, ignored if kernel != 'bicubic'
# a2 = Default(a2, 30) #c parameter of bicubic upscale, ignored if kernel != 'bicubic'
# taps = Default(taps, 4) #number of taps for reverse scaling



The # in red at a1, a2, and taps is to block resizers like gauss / gaussian and sync when not in use. Maybe there's a better way to go about that?

Not sure on the taps one as I don't have a blurry source to play with at the moment.
:helpful:

[real.finder]

new updates will be on github from now on
https://github.com/realfinder/AVS-Stuff/tree/master

you may want to update since new updates for avs+ and masktools kinda break things in HBD (Specifically in float) in few scripts like dehalo alpha :) but on the other hand there are fixes for float UV things

SMDegrain.avsi no longer needed for QTGMC and others, there are new "ZS AVS Shared Functions.avsi" for that

also new basic HBD support for nnedi3_resize16.avsi and ContraSharpen_mod.avsi, nlsb in nnedi3_resize16.avsi now false by default, with HBD you will need ResizeX and most conversion parameters in nnedi3_resize16 will not do anything (since the input color formats = the output color formats), the output also is different in HBD (still didn't check if it bug or normal)

that not all things :) more updates will come soon

[real.finder]

also soon I will move all the OP in this post (as backup) so the OP will has new informations

also AKA A.SONY's Avisynth Stuff

I decided to open this Thread like what Groucho2004 did (http://forum.doom9.org/showthread.php?t=173259)

AudSub Splitter (http://forum.doom9.org/showthread.php?t=169961)
GUI for vfr.py and trimsubs

https://forum.doom9.org/showthread.php?p=1673913#post1673913 some moded macros for avsp

note:- SMDegrain.avsi (v3.1.2.101s or up) is needed now for many scripts since it have the IsAvsNeo(), IsAvsPlus() and AvsPlusVersionNumber() functions. why? (https://forum.doom9.org/showthread.php?p=1805621#post1805621)

note 2:- many scripts support native HBD now, some for few settings and some others for all settings depending on the used dll's in the function

daa3mod (http://forum.doom9.org/showthread.php?p=1639679#post1639679)
daa with nnedi3 and ss (slow) method have less artifacts and less loss of details and others

dfttestmc (http://forum.doom9.org/showthread.php?p=1725400#post1725400)
my mod for dfttestmc

sanimebob and smam and admfilter and others (Advanced Denoising.avsi) (https://forum.doom9.org/showthread.php?p=1881052#post1881052)
bob for anime, smam to clean up the bob Artifacts
admfilter is Adaptive motion denoise that use dfttestmc, the goal of it to get rational denoise in all cases (whether motions or not), and other functions

DDComb (https://pastebin.com/V15XkSAK)
I just did some edit in it

QTGMC (https://forum.doom9.org/showthread.php?t=174544)
edit to use YUY2 in avs 2.6 and others

SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution?p=2413356&viewfull=1#post2413356)
or the 3rd post here, see videohelp link and the top of script for the changes log

RemoveDirtMC_SE (http://pastebin.com/uNUbMQEh)

stab3 and others (https://pastebin.com/6hStBeaN)

AnimeIVTC 2 mod, bug fixed and more (http://forum.doom9.org/showthread.php?t=170364)

ASTDR DeRainbow (http://forum.doom9.org/showthread.php?p=1665492#post1665492)

chroma blend/bleed/halo fix (http://goo.gl/enjQaR)

DeHaloHmod (http://goo.gl/K0XsVB)

maa2 (https://forum.doom9.org/showpost.php?p=1725500&postcount=69)

insertsign (https://pastebin.com/p0sExcvQ)

aWarpSharp4xx (https://pastebin.com/qLkBTbiF)

edi_rpow2 and ResizeX and eedi3_resize16 and IResize (https://forum.doom9.org/showthread.php?p=1837361&posted=1#post1837361)

nnedi3_resize16 (https://pastebin.com/qF22KqqH)
nnedi3_resize16 speed up with nnedi3 for avs 2.6 especially with not yv12

MP_Pipeline (http://forum.doom9.org/showthread.php?p=1746479#post1746479)
not much edit, just support avs mt inside mpp block, my goal now is here https://github.com/SAPikachu/MP_Pipeline/issues/1

nnchromaupsubsampling (https://pastebin.com/tZu3W40P)
NNEDI chroma upsubsampling

VHSHaloremover (https://pastebin.com/u3B4WFT2)

abcxyz (https://pastebin.com/UL6ycpbp)

DeHalo_alpha_MT2 (https://pastebin.com/JmHNvMz1)

BlindDeHalo3_mt2 (https://pastebin.com/yFNETMLx)

Masked_DHA (https://pastebin.com/1KFH1FkH)

FastLineDarken mod (https://pastebin.com/MmXGK6yf)

FineDehalo (https://pastebin.com/NamQ8g66)

srestore (https://forum.doom9.org/showthread.php?p=1846373#post1846373)

LSFmod (https://forum.doom9.org/showthread.php?t=174752)

BalanceBorders (https://forum.doom9.org/showthread.php?p=1859631#post1859631)

FixBlendIVTC (https://pastebin.com/8SZ8WdWJ)

DebilinearM (https://forum.doom9.org/showthread.php?p=1879523#post1879523)

SeeSaw (https://pastebin.com/hqyLDArX)

Deblock_QED_MT2 (https://pastebin.com/MuajpPfm)

YAHR (http://avisynth.nl/index.php/YAHRmod_source)

chikuzen plugins that I edit/build https://forum.doom9.org/showpost.php?p=1798117&postcount=36

maki mod of DGIndex & DGMPGDec I build https://forum.doom9.org/showpost.php?p=1782576&postcount=15

...

maybe there is others but I don't remember them now

[tormento]

also soon I will move all the OP in this post (as backup) so the OP will has new informations
I had couple of errors with 105 release of SMDegrain: the first (about no function AvsPlusVersionNumber) was fixed by downloading ZS AVS Shared Functions-1.01.avsi, the second is
[2020-03-06][13:13:17] error: Script error: There is no function named 'SMDegrain_KNLMeansCL'.
[2020-03-06][13:13:17] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2—105.avsi, line 610)
[2020-03-06][13:13:17] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2—105.avsi, line 181)
and I saw you removed SMDegrain_KNLMeansCL function from 105 SMDegrain script. Which other avsi is needed to have it functioning properly?

[real.finder]

I had couple of errors with 105 release of SMDegrain: the first (about no function AvsPlusVersionNumber) was fixed by downloading ZS AVS Shared Functions-1.01.avsi, the second is
[2020-03-06][13:13:17] error: Script error: There is no function named 'SMDegrain_KNLMeansCL'.
[2020-03-06][13:13:17] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2—105.avsi, line 610)
[2020-03-06][13:13:17] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2—105.avsi, line 181)
and I saw you removed SMDegrain_KNLMeansCL function from 105 SMDegrain script. Which other avsi is needed to have it functioning properly?

yes all shared functions moved to "ZS AVS Shared Functions" but some renamed to another name, I think I replaced the name in SMDegrain but seems I forget to save the changes or something, anyway try the updated SMDegrain I just upload :)

[tormento]

I forget to save the changes or something, anyway try the updated SMDegrain I just upload :)
Working now! :D

:thanks:

[real.finder]

new improve to nnrep (https://forum.doom9.org/showpost.php?p=1839184&postcount=155)

https://i.postimg.cc/3kPtHdW1/both2.png (https://postimg.cc/3kPtHdW1)

[kedautinh12]

I see you deleted function Hqn3d_2 in last ver Advanced Denoising.avsi, i need use this function, can you add this again??

[real.finder]

I see you deleted function Hqdn3d_2 in last ver Advanced Denoising.avsi, i need use this function, can you add this again??

it's in "ZS AVS Shared Functions.avsi" now

[kedautinh12]

it's in "ZS AVS Shared Functions.avsi" now

Oh, thanks

[real.finder]

new basic HBD support for nnedi3_resize16.avsi and ContraSharpen_mod.avsi, nlsb (https://forum.doom9.org/showpost.php?p=1885406&postcount=331) in nnedi3_resize16.avsi now false by default, with HBD you will need ResizeX and most conversion parameters in nnedi3_resize16 will not do anything (since the input color formats = the output color formats), the output also is different in HBD (still didn't check if it bug or normal)


aside from without nlsb (https://forum.doom9.org/showpost.php?p=1885406&postcount=331) (without nlsb is the fastest but it's not real 16bit since nnedi3 not work with lsb) I did more tests


ColorBars(width=640, height=480).converttoyv12
ConvertBits(16)
nnedi3_resize16(2000,2000)
ConvertBits(8)


same output (or at least there is no noticeable difference) as


ColorBars(width=640, height=480).converttoyv12
ConvertBits(16)
ConverttoStacked
nnedi3_resize16(2000,2000,nlsb=true,lsb=true,lsb_in=true)
ConvertFromStacked
ConvertBits(8)


but it's a bit slower in HBD (I think it's because slimit_dif vs Dither_limit_dif16)

however, aside from more quality, its faster with float clip!
ColorBars(width=640, height=480).converttoyv12
ConvertBits(32)
nnedi3_resize16(2000,2000)
ConvertBits(8)

[real.finder]

update:

nnedi3_resize16 should work with RGBP(A) and YUVA

and another updates for fixing things for other scripts

[Morku]

Hi,

I have updated my plugins and Avisynth Scripts to last version (from your github) and can't use Srestore (2.797) anymore.

When I load, I get the error: "I don't know what 'AvsPlusVersionNumbers' means." (line 66)

So I figured out, it is part of SMDegrain (IsAVSPlus()). But in version 3.1.2.106s and 3.1.2.105s it is missing.

So I downgraded SMDegrain to 3.1.2.101s. But than Srestore tells: "There is no function names 'sh_StrReplace'." (line 405)

So before I start to downgrade any plugin and Avisynth version of the last weeks/months, maybe you can tell me, what the reason is?

[StainlessS]

'AvsPlusVersionNumbers'
Too many 's', I think but,
Think RF is hiding his utility stuff here now:- https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/ZS%20AVS%20Shared%20Functions.avsi

I defo dont like the SPACE in the file name ie "Advanced Denoising.avsi", I'm using "AdvancedDenoising.avsi"

EDIT: Actually, I dont know where I got that filename from, seems should be this "ZS AVS Shared Functions.avsi", which I still dont like because of SPACE's.

I'll use "ZS_AVS_Shared_Functions.avsi

EDIT: Actually under RAW, is called "AVS S Shared Functions.avsi"
Real.Finder, clarification, what is the file supposed to be called ?

EDIT: And NOTE, Plugin or script files Filenames should NOT have Hyphen "-" in them, and also no SPACE's
(should parse same as Variable names, ie '_' or Alpha for 1st char, thereafter digit also acceptable. [and finally '.avsi' or '.avs' or where dll then '.dll'])

EDIT:
I defo dont like the SPACE in the file name ie "Advanced Denoising.avsi", I'm using "AdvancedDenoising.avsi"

EDIT: Actually, I dont know where I got that filename from, seems should be this "ZS AVS Shared Functions.avsi", which I still dont like because of SPACE's.

I (wrongly) got it (Filename "Advanced Denoising.avsi") from here:- https://forum.doom9.org/showthread.php?p=1904931#post1904931

[Morku]

Thank you. It is the missing piece. :) It's working now.

And you are right. The error is only 'AvsPlusVersionNumber'. Without s. Mistake by myself when I wrote it.

[StainlessS]

Real.Finder, Note
in your shared functions avsi (full name as yet unknown, see two posts earlier)

Function sh_StrReplace(string s, string find, string replace)
{
AvsPlusVersionNumber > 2347 ? ReplaceStr(s,find,replace) : eval("""i = s.FindStr(find) Chr(3) i ==0 || Replace=="" ? s : (s.LeftStr(i-1)+replace+s.MidStr(Strlen(find)+i)).StrReplace(find, replace)""")
}

ReplaceStr() was bugged (crash) in some versions prior to v3.5 build 3072,

Fix: ReplaceStr when the pattern string to be replaced is empty
https://forum.doom9.org/showthread.php?p=1904672#post1904672

Also NOTE in RED StrReplace is wrong function name, should be maybe sh_StrReplace ie recursive call to self function.

[real.finder]

Hi,

I have updated my plugins and Avisynth Scripts to last version (from your github) and can't use Srestore (2.797) anymore.

When I load, I get the error: "I don't know what 'AvsPlusVersionNumbers' means." (line 66)

So I figured out, it is part of SMDegrain (IsAVSPlus()). But in version 3.1.2.106s and 3.1.2.105s it is missing.

So I downgraded SMDegrain to 3.1.2.101s. But than Srestore tells: "There is no function names 'sh_StrReplace'." (line 405)

So before I start to downgrade any plugin and Avisynth version of the last weeks/months, maybe you can tell me, what the reason is?

Did you see the OP?

[real.finder]

Real.Finder, Note
in your shared functions avsi (full name as yet unknown, see two posts earlier)

Function sh_StrReplace(string s, string find, string replace)
{
AvsPlusVersionNumber > 2347 ? ReplaceStr(s,find,replace) : eval("""i = s.FindStr(find) Chr(3) i ==0 || Replace=="" ? s : (s.LeftStr(i-1)+replace+s.MidStr(Strlen(find)+i)).StrReplace(find, replace)""")
}

ReplaceStr() was bugged (crash) in some versions prior to v3.5 build 3072,


https://forum.doom9.org/showthread.php?p=1904672#post1904672


ReplaceStr only bugged in 3072?

Also NOTE in RED StrReplace is wrong function name, should be maybe sh_StrReplace ie recursive call to self function.

nice catch, will fix it soon

EDIT: Actually under RAW, is called "AVS S Shared Functions.avsi"
Real.Finder, clarification, what is the file supposed to be called ?

Did not matter, rename it what you want :) I put the z in the beginning to be sure it load after all other scripts

[StainlessS]

note:- ZS AVS Shared Functions.avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/ZS%20AVS%20Shared%20Functions.avsi) (AVS S Shared Functions V1.01 or up) is needed

Arh, its in the massive text link in OP - I could not see it, way too big [and wrong color for a link] :)
Would be a real good idea to pick a better file name without SPACE as noted in a previous post,
"AVS S Shared Functions.avsi" aint a kosher name, likely has to be kludged in the likes of Avisynth and AvsPMod so that it resembled a legal variable name (plus ".avsi").

EDIT:
ReplaceStr only bugged in 3072?
I stand corrected, thanks.

Did not matter, rename it what you want
Not good enough, give some guidance to us lowly scoundrels so that we are all on the same page :)
EDIT: There may also be other tools (in addition to Avisynth and AvsPMod) that are not clever enough to mend bad filenames, and will screw up, so why tempt fate.

EDIT:
Eg, "RF_Shared.avsi" or "Z_RF_Shared.avsi"
Reference to "AVS" is probably not necessary given that the file extension is ".avsi"

[real.finder]

Arh, its in the massive text link in OP - I could not see it, way too big [and wrong color for a link] :)
Would be a real good idea to pick a better file name without SPACE as noted in a previous post,
"AVS S Shared Functions.avsi" aint a kosher name, likely has to be kludged in the likes of Avisynth and AvsPMod so that it resembled a legal variable name (plus ".avsi").


it's also here https://github.com/realfinder/AVS-Stuff/tree/master#avsavs-stuff

is the spaces really bad? I didn't note any problem in avspmod, even the warning only mentioned the dlls

EDIT:

I stand corrected, thanks.


Not good enough, give some guidance to us lowly scoundrels so that we are all on the same page :)


so, any suggestion? :)

maybe I will changes the names (and remove spaces)

[StainlessS]

is the spaces really bad?
It just does not taste right. [I hate spaces in any filenames, eg PDF, just dont like em, I'm fine with Proper Case eg ProperCase.avsi]

I didn't note any problem in avspmod, even the warning only mentioned the dlls
Maybe it will not cause problems in Avs or AvsPMod, but I cant say same for all tools, maybe one of the Avisynth Glitterati could advise.

Some suggestions given in prev edit.

[Groucho2004]

It just does not taste right. [I hate spaces in any filenames, eg PDF, just dont like em, I'm fine with Proper Case eg ProperCase.avsi]I also try to avoid spaces in file names, that's probably an old school habit (having started with MSDOS/DRDOS which did not support spaces/long filenames at the time).

CamelCase (what you call ProperCase) is what I use most, it gives a certain clarity and looks nice.

Different strokes...

[StainlessS]

Apparently VisualBasic and Excel, has some kind of Proper Case converter, where words are not joined togather but each word start letter is uppercase and others lower, I musta gottit from that.

More here on CamelCase:- https://en.wikipedia.org/wiki/Camel_case

[Morku]

Did you see the OP?

Well... no. :) :)
Because I bookmarked your github weeks ago and directly checking here for updates.
And I know, it is also described in the github Readme (edited 4 days ago).

So since I use these Scripts for a very long time, I wasn't aware that kind of change and to start from beginning.
That's the whole story :D

[real.finder]

StainlessS
Names update with sh_StrReplace fix

[StainlessS]

Names update with sh_StrReplace fix
Thank you for being Real.Finder :)

[tormento]

@real.finder

I asked a similar question, some time ago, but this is bit different.

Hi have a Hi10P source (unfortunately x264 and so no hw decode support). My idea was to use a script like this:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\lsmash\LSMASHSource.dll")
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\avs\plugins\ConvertStacked.dll")
LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P8")

SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)

Prefetch(6)

Instead of YUV420P8 space, I'd like to use YUV420P10 and let SMDegrain deal with better color space and final conversion to 8 bit. Is there any change I have to do to the script or SMDegrain parameters to feed it with 10 bit or higher bit material? As I told, I need 8 bit as output.

Thanks :)

[FranceBB]

I don't know if there have been any updates for SMDegrain (i.e if it supports 16bit planar as well), but it definitely supports 16bit stacked, therefore (assuming you have Avisynth+):


#Indexing with 16bit planar output from 10bit planar source
LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")

#From 16bit planar to 16bit stacked
ConverttoStacked()

#Denoise with high bit depth precision: 16bit stacked input, 8bit planar output with dither (Floyd-Steinberg error diffusion)
SMDegrain (tr=4, thSAD=500, refinemotion=false, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true, lsb_in=true, lsb_out=false, mode=6)


And that's it...
The changes I made to your parameters are:
lsb_in=true to tell SMDegrain "Hey, you're gonna get 16bit stacked input with MSB, LSB stacked one on the top of the other, not a weird aspect ratio yv12 8bit source, so deal with it properly!!"
lsb_out=false to tell SMDegrain "Hey, don't you dare outputting 16bit stacked with psychedelic garbage on the bottom, I want a nice clean regular 8bit planar as an output!"
mode=6 to tell SMDegrain to use DitherPost to dither down to 8bit the output in a proper way. There are 8 modes that you can use for dithering, but I generally use the Floyd-Steinberg Error Diffusion as it's somewhat a good compromise.
Anyway, feel free to use a different mode if you like:

-1 no dither, round to the closest value
0 8-bit ordered dither + noise.
1 1-bit dither
2 2-bit dither, light
3 2-bit dither, medium
4 2-bit dither, strong
5 2-bit dither, stronger
6 Serpentine Floyd-Steinberg error diffusion.
7 Stucki error diffusion.
8 Atkinson error diffusion.



I'll wait for real.finder to comment, though, as perhaps my SMDegrain version is old and there's a new one which supports 16bit planar... I don't know...

[tormento]

I'll wait for real.finder to comment, though, as perhaps my SMDegrain version is old and there's a new one which supports 16bit planar... I don't know...
Thanks for your help. I doubt we can mix n16 with lsb :scared:

[real.finder]

@real.finder

I asked a similar question, some time ago, but this is bit different.

Hi have a Hi10P source (unfortunately x264 and so no hw decode support). My idea was to use a script like this:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\lsmash\LSMASHSource.dll")
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\avs\plugins\ConvertStacked.dll")
LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P8")

SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)

Prefetch(6)

Instead of YUV420P8 space, I'd like to use YUV420P10 and let SMDegrain deal with better color space and final conversion to 8 bit. Is there any change I have to do to the script or SMDegrain parameters to feed it with 10 bit or higher bit material? As I told, I need 8 bit as output.

Thanks :)

just remove those with red color, and add convertbits(8,dither=0) or with dither=1 for Floyd-Steinberg before Prefetch(6)

I don't know if there have been any updates for SMDegrain (i.e if it supports 16bit planar as well), but it definitely supports 16bit stacked, therefore (assuming you have Avisynth+):


#Indexing with 16bit planar output from 10bit planar source
LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")

#From 16bit planar to 16bit stacked
ConverttoStacked()

#Denoise with high bit depth precision: 16bit stacked input, 8bit planar output with dither (Floyd-Steinberg error diffusion)
SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true, lsb_in=true, lsb_out=false, mode=6)


And that's it...
The changes I made to your parameters are:
lsb_in=true to tell SMDegrain "Hey, you're gonna get 16bit stacked input with MSB, LSB stacked one on the top of the other, not a weird aspect ratio yv12 8bit source, so deal with it properly!!"
lsb_out=false to tell SMDegrain "Hey, don't you dare outputting 16bit stacked with psychedelic garbage on the bottom, I want a nice clean regular 8bit planar as an output!"
mode=6 to tell SMDegrain to use DitherPost to dither down to 8bit the output in a proper way. There are 8 modes that you can use for dithering, but I generally use the Floyd-Steinberg Error Diffusion as it's somewhat a good compromise.
Anyway, feel free to use a different mode if you like:

-1 no dither, round to the closest value
0 8-bit ordered dither + noise.
1 1-bit dither
2 2-bit dither, light
3 2-bit dither, medium
4 2-bit dither, strong
5 2-bit dither, stronger
6 Serpentine Floyd-Steinberg error diffusion.
7 Stucki error diffusion.
8 Atkinson error diffusion.



I'll wait for real.finder to comment, though, as perhaps my SMDegrain version is old and there's a new one which supports 16bit planar... I don't know...

SMDegrain support HBD as input=output since years but not for all settings

as for now only MedianBlur2 missed the HBD, if it have HBD then SMDegrain will fully support HBD as input=output for all settings (still there are some mvtools2 functions not work with float clip)

[tormento]

as for now only MedianBlur2 missed the HBD, if it have HBD then SMDegrain will fully support HBD as input=output for all settings (still there are some mvtools2 functions not work with float clip)

SMDegrain with variable bit in and out would be a dream. It’s still early for me to deal with 4K HDR material as I don’t own the proper hardware but I am thinking that, one day, I will have to denoise it too.

Real.Finder, do you have a roadmap?

[real.finder]

SMDegrain with variable bit in and out would be a dream. It’s still early for me to deal with 4K HDR material as I don’t own the proper hardware but I am thinking that, one day, I will have to denoise it too.

Real.Finder, do you have a roadmap?

MedianBlur2 is dll plugin so no, I asked days ago in avs+ Thread for add HBD and no one but pinterf volunteered to do it but I think he busy with another things in avs+ core

[tormento]

MedianBlur2 is dll plugin so no, I asked days ago in avs+ for add HBD and no one but pinterf volunteered to do it but I think he busy with another things in avs+ core



Thanks, anyway [emoji846]

[real.finder]

Thanks, anyway [emoji846]

I see pinterf update MedianBlur2 githup for HBD so it's a good thing :)

anyway, aside from that, I maybe will be nice with 4:4:4 fans like dREV (cuz there is a friend who use these things 720 444 from 1080 420), but will not update Gradfun3mod, Instead there will be another new function that did what Gradfun3mod (maybe base on it) but with no deband

[tormento]

I see pinterf update MedianBlur2 githup for HBD so it's a good thing

/me happy [emoji4]

Waiting for variable bit depth SMDegrain!

[tormento]

just remove those with red color

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P10")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")
Working and I got 4,86 fps instead of 6,71 fps on 8 bit chain.

[real.finder]

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P10")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")
Working

KNLMeansCL has problems with 10 bit clip https://github.com/Khanattila/KNLMeansCL/issues/42#issuecomment-469839637

and I got 4,86 fps instead of 6,71 fps on 8 bit chain.

Thank God it's not half speed of the 8-bit :rolleyes:

yes, more than 8 bit will be slower indeed

[tormento]

KNLMeansCL has problems with 10 bit clip https://github.com/Khanattila/KNLMeansCL/issues/42#issuecomment-469839637
I saw there is a workaround setting YUV, is it possible to create a script variant for that specific case, as all the H.265 HDR material out there is 10 bit?

[real.finder]

I saw there is a workaround setting YUV, is it possible to create a script variant for that specific case, as all the H.265 HDR material out there is 10 bit?

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended

[tormento]

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended
Thanks man!

So if the source is 444, SMDegrain should work?

[real.finder]

Thanks man!

So if the source is 444, SMDegrain should work?

yes ;)

[tormento]

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended
Just a question arise to my mind: Hi10P is 10 bit. You tell me to use 16 bit BUT at the end I have to dither to go back to 10 bit again to encode as proper format. Isn't better to find a way to stay in 10 bit with no dithering at the end?

[real.finder]

Just a question arise to my mind: Hi10P is 10 bit. You tell me to use 16 bit BUT at the end I have to dither to go back to 10 bit again to encode as proper format. Isn't better to find a way to stay in 10 bit with no dithering at the end?

more bits = better :)

anyway you can chose another prefilter other than 4 :) or ask KNLMeansCL developer to make it work with grayscale in any bit depth (seems he only against 420 with 10 bit which is not being used in SMDegrain)

[tormento]

more bits = better :)
Yes unless the standard for UHD is 10bit and you need to dither at the end :p

That's why I was asking for a solution to have 10 bit chain :D

[tormento]

@real.finder

Would you mind consider implementing DGDenoise() as additional prefilter? It is FAST (CUDA) and gives good results.

[ChaosKing]

@real.finder

Would you mind consider implementing DGDenoise() as additional prefilter? It is FAST (CUDA) and gives good results.

prefilter also accepts a clip as input.

[tormento]

prefilter also accepts a clip as input.
I do know but if you look at the avsi, you will notice that even KNLMeansCL needs script processing to do the job correctly.

[real.finder]

@real.finder

Would you mind consider implementing DGDenoise() as additional prefilter? It is FAST (CUDA) and gives good results.

I don't has CUDA :)

anyway as ChaosKing said, you can always feed any clip in prefilter

[tormento]

I don't has CUDA :)
I can test it for you. :cool:
you can always feed any clip in prefilter
Please explain me what the KNLMeansCL part in ZS AVS Shared Functions-1.01.avsi and SMDegrain-3.1.2·106.avsi does.

Is it simply a way to pass parameters or it does some other stuff too?

[real.finder]

I can test it for you. :cool:

still, I cant do things blindly, you can test without me and feed clip into prefilter

Please explain me what the KNLMeansCL part in ZS AVS Shared Functions-1.01.avsi and SMDegrain-3.1.2·106.avsi does.

Is it simply a way to pass parameters or it does some other stuff too?

it's better to ask Dogway about that :)

but anyway it's because KNLMeansCL don't process chroma if it not 444 and some settings that Dogway think it better for prefilter

[tormento]

but anyway it's because KNLMeansCL don't process chroma if it not 444
Luckily DGDenoise does:
chroma: true/false (default: false)
When set to true NLM denoising is applied to the chroma as well as the luma.
Should I use strong values to create a proper prefilter clip?

[ChaosKing]

Luckily DGDenoise does:
chroma: true/false (default: false)
When set to true NLM denoising is applied to the chroma as well as the luma.
Should I use strong values to create a proper prefilter clip?

As always, it depends on your source. Too strong and you could loose some details, too light and you are left with more noise. But in general it is a more "forgiving" filter. I 'm mean you can't overfilter that easily with smdegrain.

You can read about different techniques here http://avisynth.nl/index.php/SMDegrain
(Use you browser search to find everything prefilter related)

[real.finder]

I maybe will be nice with 4:4:4 fans like dREV (cuz there is a friend who use these things 720 444 from 1080 420), but will not update Gradfun3mod, Instead there will be another new function that did what Gradfun3mod (maybe base on it) but with no deband


dither_convert_8_to_16()
ly = GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()


so, I think this thing don't need function, anyway, it's better to do it like this


useDebilinearM=false #Depend on the source
nativeWidth=1504 #Depend on the source
nativeHeight=846 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true) : luma.ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.25,kernel_u="blackman") #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)


Regarding the deband, https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/F3KDB_s.avsi has the masking that in f3kdbmod16x/f3kdbmod16

[real.finder]

added GrainFactory3 (still you need wait for AddGrain fix) and GrainFactory3mod (use it without AddGrain for now)

update for Deblock_QED_MT2 should work with 8-16 bits and float

also keep in mind I usually do Silent updates, so it's better to keep eye on https://github.com/realfinder/AVS-Stuff/tree/master

[tormento]

also keep in mind I usually do Silent updates
And we kindly hate you for that. :p

Seriously: did you implement latest contrasharpen mod into SMDegrain? Do I need to download the proper avsi or is it in ZS_AVScan'tremembername.avsi?

[StainlessS]

I think ZS_AVS etc .avsi is just a bundle of utility functions used by other scripts.

[real.finder]

And we kindly hate you for that. :p

Seriously: did you implement latest contrasharpen mod into SMDegrain? Do I need to download the proper avsi or is it in ZS_AVScan'tremembername.avsi?

it can't be helped, I am kinda lazy :D

yes, and delete the old "ZS AVS Shared Functions" and use Zs_RF_Shared.avsi cuz it was renamed days ago along with others thanks to StainlessS (https://forum.doom9.org/showthread.php?p=1905192#post1905192) :devil:

https://i.postimg.cc/YhBcL4SZ/Untitled.png (https://postimg.cc/YhBcL4SZ)

[tormento]

it can't be helped, I am kinda lazy :D
We can whip you once a day to be more productive :*

Do you plan to introduce the infamous MedianBlur in SMDegrain? :D

[tormento]

I think ZS_AVS etc .avsi is just a bundle of utility functions used by other scripts.
Yes but I saw contrasharpen as separate AVSI. Couldn't understand if SMDegrain needed it or not. If Contrasharpen is included in ZSAVS, why to create a separate script?

[real.finder]

Do you plan to introduce the infamous MedianBlur in SMDegrain? :D

it's used by http://avisynth.nl/index.php/MinBlur dogway replaced it with RemoveGrainHD just for YUY2 support, then I did bring back MedianBlur for avs26 since it worked with yv16 (same chorma subsampling as YUY2)

Yes but I saw contrasharpen as separate AVSI. Couldn't understand if SMDegrain needed it or not. If Contrasharpen is included in ZSAVS, why to create a separate script?

Sorry for the confusion, I was mean yes for you only need Zs_RF_Shared.avsi I didn't change the ContraSharpeningHD that was dogway used, there are many Contrasharp functions like the mod one that used in nnedi3_resize16 and there are one in finedehalo and the HD one from SMDegrain, simply you can use any one by just don't set the sharp parameter in SMDegrain and use external one after the SMDegrain line

[tormento]

Sorry but I couldn't understand both your replies (I am not native language speaker).
it's used by http://avisynth.nl/index.php/MinBlur dogway replaced it with RemoveGrainHD just for YUY2 support, then I did bring back MedianBlur for avs26 since it worked with yv16 (same chorma subsampling as YUY2)
So, you put it back in the script? Sorry I can't get it right.
Sorry for the confusion, I was mean yes for you only need Zs_RF_Shared.avsi I didn't change the ContrasharpenHD that was dogway used, there are many Contrasharp functions like the mod one that used in nnedi3_resize16 and there are one in finedehalo and the HD one, simply you can use any with any just don't set the sharp parameter in SMDegrain and use external one after the SMDegrain line
Why you don't simply put every ContraSharpen function in the separate AVSI so we can use whatever parameter in SMDegrain?

[real.finder]

I am also not native language speaker

So, you put it back in the script? Sorry I can't get it right.

I used some check code for these cases, if the script used in avs 2.5 with YUY2 it will use RemoveGrainHD, other cases will be MedianBlur

Why you don't simply put every ContraSharpen function in the separate AVSI so we can use whatever parameter in SMDegrain?

because I didn't made SMDegrain so I can't did changes like this for many reasons, including people's objection (happened many times even here in doom9 like dREV and nnedi3_resize16), and also respect for the original developer (I only add new things that I often not set them to Default and didn't change the original Default settings)

[tormento]

I used some check code for these cases, if the script used in avs 2.5 with YUY2 it will use RemoveGrainHD, other cases will be MedianBlur
Please, remember me the switches that turn on MinBlur because I have neither RemoveGrainHD nor MedianBlur installed and SMDegrain works. :D
because I didn't made SMDegrain so I can't did changes like this for many reasons, including people's objection
Dogway is long time gone and people shouldn't complain about free (and very good) work. Their alternative is do the job in your turn...

Just my 2 cents.

[real.finder]

Please, remember me the switches that turn on MinBlur because I have neither RemoveGrainHD nor MedianBlur installed and SMDegrain works. :D


in prefilter 1 and 2 I think, and maybe the contasharp

[hello_hello]

real.finder,

Putting the scripts on github is a great idea but is it necessary to have them in folders according to the supported Avisynth version?

I went looking for "Zs_RF_Shared.avsi" here (https://github.com/realfinder/AVS-Stuff) and of course the first question that came to mind was "where is it?" (I now see the location is in the readme file). Just my opinion, but I'd prefer all the functions to be together with the supported Avisynth versions listed at the top of each one.

Even though I know it'd upset StainlessS's naming convention :), I think it'd be nice to include the version number or date in the file name. If you're just putting scripts in the auto-loading folder it doesn't matter if the file name changes when they're updated, and if you're manually importing them and don't want the name to change for backwards compatibility then it's easy enough to remove the version number from the file name. I think it'd make checking for updates easier.

I've added the version number or date to the file name of every dll and script in the Avisynth auto-loading folder and it's not ever caused me a problem, spaces in file names included, and it makes checking for updated versions simpler.

Just a thought.....

https://i.postimg.cc/sv68Mph8/Clipboard.gif (https://postimg.cc/sv68Mph8)

PS. I tell a lie. I can recall one time when renaming dlls caused a problem and it was possibly one of your mods to a function where you changed it to call deblock.dll directly and as a result deblock.dll is the only plugin I have with it's original name, but I understand why that was done and there's always something to look out for no matter what you do.

[hello_hello]

Another question....

When right clicking on a script link at github and selecting "save link as", for me it saves an html document with an avsi extension rather than the actual script. Is that expected behaviour? If it is, it's another reason why it'd be handy to be able to identify the script version without having to open each link to check.

Cheers.

PS To offer an argument in favour of spaces in file names, based on the fact function names can't have spaces....

Your function Abcxyz() has a file name of "Abcxyz_MT2.avsi".
If I didn't use that function very often I'd probably look at the file name and assume the function name was Abcxyz_MT2().
If it was named "Abcxyz MT2.avsi", or even "Abcxyz MT2 2020-03-24.avsi", my first guess at the function name would be Abcxyz().

That's how I try to name avsi files myself. The function name followed by a space followed by any informative stuff.
Or sometimes it has to be the informative stuff, space, function name, such as "MCTemporalDeNoiseMod 1.4.20 - MCTD.avsi".
It's just a little thing... being able pick the function name out of the file name without having to open the script to check it. :)

[real.finder]

Putting the scripts on github is a great idea but is it necessary to have them in folders according to the supported Avisynth version?

I went looking for "Zs_RF_Shared.avsi" here and of course the first question that came to mind was "where is it?" (I now see the location is in the readme file). Just my opinion, but I'd prefer all the functions to be together with the supported Avisynth versions listed at the top of each one.

all (at least most) them already in OP here in doom9 :)

I think it'd be nice to include the version number or date in the file name.

I am against this, because if someone put several versions in auto-loading folder can get some problems, also I need to change the name every time!

When right clicking on a script link at github and selecting "save link as", for me it saves an html document with an avsi extension rather than the actual script. Is that expected behaviour? If it is, it's another reason why it'd be handy to be able to identify the script version without having to open each link to check.

right clicking should be done on the raw link :)

https://i.postimg.cc/QK77MWYK/Untitled.png (https://postimg.cc/QK77MWYK)

anyway, if you don't like the names, you can always rename ;)

[hello_hello]

I am against this, because if someone put several versions in auto-loading folder can get some problems, also I need to change the name every time!

Is it possible to at least have a text file on github with a list of functions and their current version numbers? It's a pain having to click on every link to see if the function needs updating.

Cheers.

[real.finder]

Is it possible to at least have a text file on github with a list of functions and their current version numbers? It's a pain having to click on every link to see if the function needs updating.

Cheers.

maybe when I did another updates I will try, but you don't need that even as it now, there are commits and

https://i.postimg.cc/PNkn4Yj4/Untitled.png (https://postimg.cc/PNkn4Yj4)

:)

[tormento]

@real.finder

Please, please, please put a shred of changelog about your avsi.

I subscribed to GitHub notifications and I see them changing but I have no idea of what those changes mean. :(

What changed from Zs_RF_Shared-1.10 to Zs_RF_Shared-1.11?

What mcKNLMeansCL does and how is it different from SMDegrain?

[real.finder]

@real.finder

Please, please, please put a shred of changelog about your avsi.

I subscribed to GitHub notifications and I see them changing but I have no idea of what those changes mean. :(

What changed from Zs_RF_Shared-1.10 to Zs_RF_Shared-1.11?

What mcKNLMeansCL does and how is it different from SMDegrain?

is these info not enough? https://github.com/realfinder/AVS-Stuff/commits/Community

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

mcKNLMeansCL use KNLMeansCL as the main denoiser while SMDegrain use mvtools MDegrain as the main denoiser, which one better? It depends on the source and what satisfy you ;)

[tormento]

is these info not enough?
I read release from mobile GitHub... err...

What does sh_KNLMeansCL does precisely?

P.S: Are you planning to release SMDegrain for neo_DFT?

[real.finder]

I read release from mobile GitHub... err...

This is one of the many reasons why I hate mobile platforms :cool:


What does sh_KNLMeansCL does precisely?

P.S: Are you planning to release SMDegrain for neo_DFT?

sh_KNLMeansCL is SMDegrain_KNLMeansCL but renamed as I said before

P.S: Are you planning to release SMDegrain for neo_DFT?
I do https://forum.doom9.org/showthread.php?p=1907924#post1907924

[kedautinh12]

I do https://forum.doom9.org/showthread.php?p=1907924#post1907924

I see pinterf was updated new ver defttest just 24 days ago
https://github.com/pinterf/dfttest/releases

[real.finder]

I see pinterf was updated new ver defttest just 24 days ago
https://github.com/pinterf/dfttest/releases

I already know it, no changes needed for it in old scripts

[pinterf]

Are you ready for version numbers like 3.5.2 instead of simple 3.5?

[real.finder]

Are you ready for version numbers like 3.5.2 instead of simple 3.5?

I think I will take StainlessS code (https://forum.doom9.org/showpost.php?p=1897680&postcount=5103) or simply made users go to his thread/post :devil:

[pinterf]

The test build I'd like to publish next week would have this type of version numbering, of course I don't want all scripts to suddenly fail.
That's why I mentioned some weeks ago the possible problem with it.

[tormento]

The test build I'd like to publish next week would have this type of version numbering, of course I don't want all scripts to suddenly fail.
That's why I mentioned some weeks ago the possible problem with it.



Given how much I use KNLMeansCL, would you please compile it with 3.5.2 support? I think Khanattila has quit developing.

[pinterf]

Yep, it'll be needed in order not to feel the power of voodoo dolls aimed at me :)

[tormento]

Yep, it'll be needed in order not to feel the power of voodoo dolls aimed at me :)
clang version too to make we forgive you ahahahahah :p

[Groucho2004]

Are you ready for version numbers like 3.5.2 instead of simple 3.5?This is all the version info one can extract from avisynth.dll::
[Avisynth info]
VersionString: AviSynth+ 3.5 (r3106, 3.5, x86_64)
VersionNumber: 2.60
File / Product version: 3.5.0.0 / 3.5.0.0

Which parts do you want to change? All of them? Maybe there should be a runtime variable that reflects the info in VERSION_INFO resource to avoid the string acrobatics? Something like 3.5.2.0?

[real.finder]

The test build I'd like to publish next week would have this type of version numbering, of course I don't want all scripts to suddenly fail.
That's why I mentioned some weeks ago the possible problem with it.

I just did it ;)

#######

aside from that I did add more scripts:- GrainFactory3, GrainFactory3mod, Hysteria.avsi, FineSharp, EdgeCleaner and HQDeringmod

Although I do not use most of them but I did work on them for the community so testing and report are welcome

[kedautinh12]

I think you need add full Requirements (plugins + scripts) cause i see your some script don't add full and some script don't have Requirements. When i use your new script, avs+ sometimes errors "don't have some functions" cause your Requirements don't full or don't have Requirements

[real.finder]

I think you need add full Requirements (plugins + scripts) cause i see your some script don't add full and some script don't have Requirements. When i use your new script, avs+ sometimes errors "don't have some functions" cause your Requirements don't full or don't have Requirements

the only script that needed now is Zs_RF_Shared.avsi (Except few cases)

maybe I will update the Requirements for the scripts that already has them

[StainlessS]

This is all the version info one can extract from avisynth.dll::
[Avisynth info]
VersionString: AviSynth+ 3.5 (r3106, 3.5, x86_64)
VersionNumber: 2.60
File / Product version: 3.5.0.0 / 3.5.0.0

Which parts do you want to change? All of them? Maybe there should be a runtime variable that reflects the info in VERSION_INFO resource to avoid the string acrobatics? Something like 3.5.2.0?

Note, version stuff need work in other versions of Avs too, not just latest Avs+.

I think I will take StainlessS code (https://forum.doom9.org/showpost.php?p=1897680&postcount=5103) or simply made users go to his thread/post :devil:

Script linked by real.Finder (AvsVersion.avsi), the version functions are also resident in AvsInit.avsi [so could use one or other script].

Perhaps if Grouchy could add these functions to sysInfo whatsit, then would do away with script acrobatics and also make Groucho2004 SysInfo almost mandatory for all users no matter what avs ver.
[EDIT: Grouchy would become famous, they would write songs about him and know his name down the generations]

Function IsAvs26() { VersionNumber>=2.6}
Function IsAvsNeo() { FindStr(VersionString," Neo")!=0}
Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!=0||IsAvsNeo}
Function PlusBuildNumber() { V=VersionString Off=(!IsAvsPlus)?0:FindStr(V,"(r") return (Off==0)?0:V.MidStr(Off+2).Value.Int } # Avs+ & Neo, (More than 4 digits, Max 24 bit, ~16M)
Function AvsPlusVersionNumber() { Return PlusBuildNumber } # Stub for AvsPlusBuildNumber(), suggest AvsPlusVersionNumber is deprecated.
Function AvsVersionNumberString() { s=VersionString ND="0123456789." s=s.MidStr(s.StrBrkChrLen(ND,True)+1) Return s.LeftStr(s.StrMatchChrLen(ND,True)) }

Function AvsVersionNumberPartNo(int PartNo) { # Get dot separated Version Part as Int from AvsVersionNumberString[eg "1.2.3"], Where PartNo=1->3. 1=MAJOR version: 2=MINOR version : 3=BUGFIX version
PartNo=Min(Max(PartNo,1),3) # Limit Range 1->3
s=AvsVersionNumberString
d=s.FindStr(".") n1=(d==0)?s:s.LeftStr(d-1) s=(d==0)?"":s.MidStr(d+1)
d=s.FindStr(".") n2=(d==0)?s:s.LeftStr(d-1) s=(d==0)?"":s.MidStr(d+1)
d=s.FindStr(".") n3=(d==0)?s:s.LeftStr(d-1)
ns=(PartNo==1)?n1:(PartNo==2)?n2:n3
Return (ns=="")?0:ns.Eval
}

Function IsAvsVerOrGreater(int a,int "b",int "c") { # Compares with version obtained from VersionString
b=Default(b,0) c=Default(c,0)
aa=AvsVersionNumberPartNo(1) bb=AvsVersionNumberPartNo(2) cc=AvsVersionNumberPartNo(3)
return (aa>a) || (aa==a && (bb>b || (bb==b && cc>=c)))
}


I could then do away with above and also these two functions in AvsInit.avsi (although they are actually quite handy functions and might be worth having in some other avsi script.

# Return length of string S that matches any character in Chars set of characters [Default case insignificant]. # StrMatchChrLen("1234.567abcd","0123456789.") = 8
Function StrMatchChrLen(String s,String Chars,Bool "Sig") {
Function __StrMatchChrLen_LOW(String s,String Chars,int n) { c=s.MidStr(n+1,1) Return(c==""||Chars.FindStr(c)==0) ? n : s.__StrMatchChrLen_LOW(Chars,n+1) }
Sig=Default(False) # Default Case Insignificant
s=(Sig)?s:s.UCASE Chars=(Sig)?Chars:Chars.UCASE
Return __StrMatchChrLen_LOW(s,Chars,0)
}

# Return length of string s that DOES NOT match any character in Chars set of characters [Default case insignificant]. # StrBrkChrLen("1234.567,abcd",",.") = 4
# If 1st character of s matches any in Chars set, then returns 0. # StrBrkChrLen("1234.567,abcd","321") = 0
# If no characters in s match any character in Chars set, then returns length of string s. # StrBrkChrLen("1234.567,abcd","NOP") = 13
Function StrBrkChrLen(String s,String Chars,Bool "Sig") {
Function __StrBrkChrLen_LOW(String s,String Chars,int n) {c=s.MidStr(n+1,1) Return(c==""||Chars.FindStr(c)!=0)?n:s.__StrBrkChrLen_LOW(Chars,n+1)}
Sig=Default(False) # Default Case Insignificant
s=(Sig)?s:s.UCASE Chars=(Sig)?Chars:Chars.UCASE
Return __StrBrkChrLen_LOW(s,Chars,0)
}


EDIT: In fact all of below could perhaps be included in Groucho2004 SysInfo plugin, with exception of SystemInfoExists(), below are all from avsInit.avsi docs.

GScriptExists() Returns true if Gavino GScript plugin is present.
SystemInfoExists() Returns true if Groucho2004 SysInfo v0.114 plugin is present.
IsAvs26() Return true if Avisynth v2.60 or higher.
IsAvsNeo() Return True if using Avisynth Neo.
IsAvsPlus() Return True if using Avisynth Plus
AvsVersionNumberString() Returns Avisynth version number embedded in Avisynths VersionString, for eg Avs+ v3.4.2, "AviSynth+ 3.4.2 (r2983, linux3, i386)" would return "3.4.2"
IsAvsVerOrGreater(int a,int "b",int "c") Compares with version Part Numbers obtained from VersionString, returns true if version at least (a,b,c) is as high as AvsVersionNumberPartNo() parts.
To reqire minimum Avs+ version of eg v3.4.2 use IsAvsVerOrGreater(3,4,2).
PlusBuildNumber() Return Avs+/Neo Build number from Avsisynth VersionString, eg 2983 from Avs+ 3.4, (0 if non AvsPlus). BEST use IsAvsVerOrGreater(a,b,c) to check for minimum AVS+ version.
AvsPlusVersionNumber() Stub for PlusBuildNumber(), SUGGEST AvsPlusVersionNumber as DEPRECATED, ie use PlusBuildNumber instead IF YOU MUST [build number may be phased out].
###
SystemEnvTemp() Returns Path to USER System environment TEMP folder.
SystemEnvComSpec() Returns Path to System environment command line processor
eg "C:\Windows\system32\cmd.exe".
SystemEnvComputerName() Returns System environment Commputer Name eg "Colossus".
SystemEnvUserName() Returns System environment User Name eg "Yahweh".
###
IsAvs64Bit() Return Avisynth Process Bitness, True = 64 bit.
IsOS64Bit() Return Operating System Bitness, True = 64 bit (CPU could still be 64 bit if false).
IsWinXP() Return true if Windows XP (NT 5.1 XP32, 5.2 XP64)
IsWinVista() Return true if Windows Vista (NT 6.0)
IsWin7() Return true if Windows Windows 7 (NT 6.1)
IsWin8() Return true if Windows 8 (NT 6.2)
IsWin81() Return true if Windows 8.1 (NT 6.3)
IsWin10() Return true if Windows 10 (NT 10.0)
HasMMX() Return true if has MXX
HasSSE() Return true if has SSE
HasSSE2() Return true if has SSE2
HasSSE3() Return true if has SSE3
HasSSE41() Return true if has SSE4.1
HasSSE42() Return true if has SSE4.2
HasAVX() Return true if has AVX
HasAVX2() Return true if has AVX2

## EDIT: Maybe at some point
IsWindows()
IsLinux()
IsMacOS()


Below are Avs independent script functions.

Function FuncNameExists(String Fn) {Try{Eval(Fn+"()")B=True}catch(e){Assert(e.FindStr("syntax")==0,"FuncNameExists: Error in Function Name '"+Fn+"'")
\ B=(e.FindStr("no function named")==0)}Return B}

Function SystemInfoExists() { Return FuncNameExists("SI_FileVersion")} # although check for at least specific version Sysinfo should be done

[Groucho2004]

In fact all of below could perhaps be included in Groucho2004 SysInfo pluginOh dear. :eek:

[StainlessS]

Oh dear. :eek:

Not such a bad idea though, yes.

Cannot have such functionality embedded in avs+, has got to be a separate and dll maybe best option.

I am totally confident that it is all within your considerable capability.

[ Anybody else think that G2K4 could achieve this ? ]

[Groucho2004]

I am totally confident that it is all within your considerable capability.It's not about that, the 'oh dear' refers to the hours I'll have to spend. :)

[StainlessS]

Not that time consuming really, you can just copy the already written stuff in AvsInit script.
[but probably even easier in C]

EDIT: And think about how good you'de feel about yourself for doin' it, got anything else planned during your lockdown ?

EDIT: Which one is the best Stand-Up comedian, George Dubya, or Donny T. ?

[Groucho2004]

got anything else planned during your lockdown ?All kinds of things, building a pre-amplifier, cleaning the house, ... Apart from that, I' one of the lucky ones who can work from home and maintain a steady income.

Anyway, I'll get started on this and just do it bit by bit. Also, as you mentioned, it shouldn't take that long.

[Groucho2004]

Which one is the best Stand-Up comedian, George Dubya, or Donny T. ?Lewis Black.
However, of the 2 you mentioned I'd pick George "fool me once" WB.

[StainlessS]

Lewis Black, Yep, I know that face, he's Professor (Creepy) Crawley [insect expert EDIT: entomologist] in Big Bang Theory [field cricket episode EDIT: "The Jiminy Conjecture" (2009)].
Billy Connolly for me, but I also like Chris Rock. [I had two of Connolly's tapes 3 years before he appeared on Parkinson, ie before he became in-famous]

EDIT: Chris Rock has some interesting observations about George Dubya, I'm guessin on Donny T too.

EDIT: To Below: Yes like both samples you posted, I'll look for more of him when I get around to it.

[Groucho2004]

Lewis Black, Yep, I know that faceHere's a couple of samples:
https://www.youtube.com/watch?v=Q0_utZaJUL0
https://www.youtube.com/watch?v=kps4IKAnEWQ

[StainlessS]

Including these might be asking too much (or would it)


Function X_HasAlpha(clip c) { c IsAvsPlus ? HasAlpha : IsRGB32 }
Function X_HasChroma(clip c) { c IsRGB ? False : IsAvsPlus ? !IsY : !IsAvs26||!IsY8 }
Function X_IsYV411(clip c) { c IsAvs26 ? IsYV411 : False }
Function X_IsY(clip c) { c IsAvsPlus ? IsY : IsAvs26 ? IsY8 : False } # True=Single Plane : (!IsRGB)=True = Any type with Y, YUY2/YUVA/Y8 etc. BEWARE Y8_Clip.IsYUV returns True
Function X_Is420(clip c) { c IsAvsPlus ? Is420 : IsYV12 }
Function X_Is422(clip c) { c IsAvsPlus ? Is422 : False } # YUY2_Clip.Is422=False [ie not Planar]
Function X_Is444(clip c) { c IsAvsPlus ? Is444 : IsAvs26 ? IsYV24 : False }
Function X_IsRGB48(clip c) { c IsAvsPlus ? IsRGB48 : False }
Function X_IsRGB64(clip c) { c IsAvsPlus ? IsRGB64 : False }
Function X_IsRGBA(clip c) { c IsRGB && X_HasAlpha }
Function X_NumComponents(clip c) { c IsAvsPlus ? NumComponents : IsAvs26&&IsY8 ? 1 : IsRGB32 ?4 : 3 } # Num of channels
Function X_Bpc(clip c) { c IsAvsPlus ? BitsPerComponent : 8 } # Bits per channel, 32 = Float
Function X_ComponentMax(clip c) { c bpc=X_Bpc Return (bpc==32) ? 1.0 : IsAvsPlus ? BitLShift(1,bpc) - 1 : 255} # Max possible component value for colorspace
Function X_ComponentFullScale(clip c) { c bpc=X_Bpc Return (bpc==32) ? 255/256.0 : IsAvsPlus ? BitLShift(255,bpc-8) : 255} # Bit shifted value for colorspace
Function X_ComponentTvBlack(clip c) { c bpc=X_Bpc Return (bpc==32) ? 16/256.0 : IsAvsPlus ? BitLShift( 16,bpc-8) : 16} # TV Black level for colorspace
Function X_ComponentTvWhite(clip c) { c bpc=X_Bpc Return (bpc==32) ? 235/256.0 : IsAvsPlus ? BitLShift(235,bpc-8) : 235} # TV White level for colorspace
Function X_PixelType(clip c) { c IsAvs26 ? PixelType : IsYV12?"YV12":IsYUY2?"YUY2":IsRGB32?"RGB32":"RGB24" } # Eg "RGB32" or "YUV420P10"
Function X_YMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Height/ExtractU.Height):(IsYV12 ?2:1) } # Y Min crop multiple for Progressive
Function X_XMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Width/ExtractU.Width):IsAvs26?(IsYV411?4:IsYUY2||IsYV16||IsYV12?2:1):(IsRGB?1:2)} # X Min crop multiple
Function X_CsXMod(Val CSP) { (CSP.IsClip)?CSP:(CSP.IsString)?Blankclip(Length=1,Width=16,height=16,Pixel_type=CSP):Assert(False,"X_CsXMod: CSP Clip or Pixel_Type string ONLY") Return X_XMod }
Function X_CsYMod(Val CSP) { (CSP.IsClip)?CSP:(CSP.IsString)?Blankclip(Length=1,Width=16,height=16,Pixel_type=CSP):Assert(False,"X_CsYMod: CSP Clip or Pixel_Type string ONLY") Return X_YMod }


EDIT: Not sure those in blue are correct or final [just what I'm using right now].

EDIT: Perhaps Real.Finder has some candidates too :)

[Groucho2004]

Including these might be asking too much (or would it)As I wrote - bit by bit. What does the 'X_' stand for?

[StainlessS]

What does the 'X_' stand for?

Dont know, maybe Cross Version or something [maybe Real.Finder uses "Z_" or something else].
I'm happy to use RF version names if all above implemented.

EDIT: The script it originates from is not complete, names are not fixed or anything, just first names that entered my head.

EDIT: Maybe "XAVS_" intro would be better.

EDIT:
These would be going too far, but I post as maybe of interest to somebody, still under construction [from s_ExLogoPlus.avs (transient name, support v2.58 -> Avs+)]


Function ExL_MatchCS(clip c,clip matchto,String "matrix",Bool "fulls",bool "fulld") { # Match c clip to matchto clip colorspace
RT_DebugF("ExL_MatchCS: IN c=%s MatchTo=%s",c.X_PixelType,matchto.X_PixelType)
if(c.X_PixelType != matchto.X_PixelType) {
# currently (avs+ 3.5) fulld must equal fulls
mat=Default(matrix,"PC.601") # Matrix default no change ie full range matrix : fulls=auto ie undefined, true for RGB else false.
matchto.IsYV12?c.ConvertToYV12(matrix=Mat):matchto.IsYUY2?c.ConvertToYUY2(matrix=Mat):matchto.IsRGB24?c.ConvertToRGB24(matrix=Mat)
\ : matchto.IsRGB32?c.ConvertToRGB32(matrix=Mat):matchto.IsYV16?c.ConvertToYV16(matrix=Mat):matchto.IsYV24?c.ConvertToYV24(matrix=Mat)
\ : matchto.IsY8?c.ConvertToY8(matrix=Mat):matchto.IsRGB48?c.ConvertToRGB48(matrix=Mat):matchto.IsRGB64?c.ConvertToRGB64(matrix=Mat):Undefined
if(!Defined) { # Is Avs+ AND MatchTo == Planar, Can use AVS+ functions directly here.
c
if(matchto.IsRGB) {
matchto.HasAlpha == HasAlpha ? NOP : matchto.HasAlpha ? ConvertToPlanarRGBA(matrix=Mat) : ConvertToPlanarRGB(matrix=Mat)
} else if(matchto.IsY) {
RT_DebugF("Match to IsY")
ConvertToY(matrix=Mat)
} else {
RT_DebugF("Match to IsYUVA=%s or ISYUV=%s",matchto.IsYUVA,matchto.IsYUV)
if(matchto.Is444) { ConvertToYUV444(matrix=Mat) }
else if(matchto.Is422) { ConvertToYUV422(matrix=Mat) }
else if(matchto.Is420) { ConvertToYUV420(matrix=Mat) }
}
mbpc=matchto.BitsPerComponent bpc=BitsPerComponent
if(mbpc!=bpc) {
RT_debugF("Converting Bits from %d to %d",X_Bpc,matchto.X_Bpc)
ConvertBits(mbpc) #,fulls=fulls,fulld=fulld)
}
(matchto.HasAlpha==HasAlpha) ? NOP : HasAlpha ? RemoveAlphaPlane : AddAlphaPlane
}
} else { c }
RT_DebugF("ExL_MatchCS: OUT c=%s matchto=%s",X_PixelType,matchto.X_PixelType)
return last
}
Function ExL_Layer(clip c,clip oc,String "op",Int "x",Int "y",Int "th", Bool "chroma",Float "opacity") {
RT_debugF("ExL_Layer: c = %s oc=%s",c.X_PixelType,oc.X_PixelType)
Opacity=min(max(Default(opacity,1.0),0.0),1.0)
if (IsAvsPlus) { c.Layer(oc,op,Undefined,x,y,th,chroma,opacity) }
else { c.Layer(oc,op,Round((c.X_ComponentMax + (c.X_HasAlpha ? 2 : 1)) * Opacity),x,y,th,chroma) }
}


EDIT: I would not be happy about removing YUY2 capability from any of my scripts, doing so is not any kind of improvement in my eyes, even if it is the easy choice.
EDIT: Also, where per pixel chroma filtering is tightly bound to Luma pixel filtering, then YUY2 is likely as fast as equivalent planar YUV422 [at least when C code path].

[pinterf]

Just to confuse you all, what if I introduced roman numbers. Avisynth+ III.V.C ?

[StainlessS]

Dont worry bout that, Groucho will easily take care of it [he probably thought of it already].

[tormento]

Just to confuse you all, what if I introduced roman numbers. Avisynth+ III.V.C ?
With a UTF-16LE aware system, you could introduce chinese numbers too.

[StainlessS]

No problem whatever, Groucho2004 is the Bees Knees, the Cats Whiskers, the Dogs Bollocks when it comes to internationalization,
and for any time period too [did not the Mayans use Base 60 or something].

[real.finder]

as a Mesopotamian, I want it Cuneiform :P

[tormento]

did not the Mayans use Base 60 or something

Base 20. It was replaced by Base 10 when people started to use shoes (not kidding). There are some traces in the “barbarian” part of Europe, such as France, where the language still reflects their ancient numeral system (80 = quatre-vingts).

[StainlessS]

in the “barbarian” part of Europe, such as France

Loved that bit, some things never change :)

Cuneiform, G2K4 got that covered too I bet.

(not kidding)
Arh, was that them.
Did not somebody use base 60, divisible by 2, 3, 4, 5, 10, 12.
And who was it that used a fist as extension to fingers and thumbs for base 12 (2*6).

EDIT:
Did not somebody use base 60
Arh yes, the guy who invented the speaking clock. [well nearly]

EDIT: Cuneiform, wedge shaped marks made by reed on clay tablet.
Sorry Grouchy Groucho, AKA GG (pronounced Gee-Gee just like the horse).

[Groucho2004]

Cuneiform, G2K4 got that covered too I bet.Never heard of it.
Cuneiform, wedge shaped marks made by reed on clay tablet.
OK, should have known that.


Also, please stop blowing smoke up my bunghole, I'm already saturated.

https://media.giphy.com/media/fdHg7T902uzLy/giphy.gif

[real.finder]

Groucho2004 it's this https://www.youtube.com/watch?v=FxTencmpDLc

edit: also https://www.youtube.com/watch?v=J5Ug3Cr8RUE

[Groucho2004]

A couple of questions/notes about the list below:

GScriptExists() should also return true if the plugin is present but AVS+ with built-in GScript is used, right?
Avs64Bit is already covered with 'SI_ProcessBitness'. Do we need it anyway as a convenience function?
I have SytemEnvironment implemented differently. You pass the environment variable and it returns the value. I think that's more elegant and flexible than having a function for each variable (SystemEnvTemp(), SystemEnvComSpec(), SystemEnvComputerName(), SystemEnvUserName()), don't you think?


Also, I'd like to prefix the functions that relate to Avisynth with 'AI_' (AvisynthInfo). Any objections?

In fact all of below could perhaps be included in Groucho2004 SysInfo plugin, with exception of SystemInfoExists(), below are all from avsInit.avsi docs.

GScriptExists() Returns true if Gavino GScript plugin is present.
SystemInfoExists() Returns true if Groucho2004 SysInfo v0.114 plugin is present.
IsAvs26() Return true if Avisynth v2.60 or higher.
IsAvsNeo() Return True if using Avisynth Neo.
IsAvsPlus() Return True if using Avisynth Plus
AvsVersionNumberString() Returns Avisynth version number embedded in Avisynths VersionString, for eg Avs+ v3.4.2, "AviSynth+ 3.4.2 (r2983, linux3, i386)" would return "3.4.2"
IsAvsVerOrGreater(int a,int "b",int "c") Compares with version Part Numbers obtained from VersionString, returns true if version at least (a,b,c) is as high as AvsVersionNumberPartNo() parts.
To reqire minimum Avs+ version of eg v3.4.2 use IsAvsVerOrGreater(3,4,2).
PlusBuildNumber() Return Avs+/Neo Build number from Avsisynth VersionString, eg 2983 from Avs+ 3.4, (0 if non AvsPlus). BEST use IsAvsVerOrGreater(a,b,c) to check for minimum AVS+ version.
AvsPlusVersionNumber() Stub for PlusBuildNumber(), SUGGEST AvsPlusVersionNumber as DEPRECATED, ie use PlusBuildNumber instead IF YOU MUST [build number may be phased out].
###
SystemEnvTemp() Returns Path to USER System environment TEMP folder.
SystemEnvComSpec() Returns Path to System environment command line processor
eg "C:\Windows\system32\cmd.exe".
SystemEnvComputerName() Returns System environment Commputer Name eg "Colossus".
SystemEnvUserName() Returns System environment User Name eg "Yahweh".
###
IsAvs64Bit() Return Avisynth Process Bitness, True = 64 bit.
IsOS64Bit() Return Operating System Bitness, True = 64 bit (CPU could still be 64 bit if false).
IsWinXP() Return true if Windows XP (NT 5.1 XP32, 5.2 XP64)
IsWinVista() Return true if Windows Vista (NT 6.0)
IsWin7() Return true if Windows Windows 7 (NT 6.1)
IsWin8() Return true if Windows 8 (NT 6.2)
IsWin81() Return true if Windows 8.1 (NT 6.3)
IsWin10() Return true if Windows 10 (NT 10.0)
HasMMX() Return true if has MXX
HasSSE() Return true if has SSE
HasSSE2() Return true if has SSE2
HasSSE3() Return true if has SSE3
HasSSE41() Return true if has SSE4.1
HasSSE42() Return true if has SSE4.2
HasAVX() Return true if has AVX
HasAVX2() Return true if has AVX2

## EDIT: Maybe at some point
IsWindows()
IsLinux()
IsMacOS()

[StainlessS]

GScriptExists() should also return true if the plugin is present but AVS+ with built-in GScript is used, right?
Where GScript is present under AVS+, so Gscript dll is used as external dll Overrides builtin [also user installed dll for a reason, presumably].


Nope, Script func overrides dll, dll overrides builtin.

Wiki:- http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Name_Precedence



EDIT:
Also, where in main script and decision as to use GScript(GSTRING) or Avs+ Eval(GSTRING) to process a GSTRING string containing GScript if/for/next/while type stuff,
scriptor should choose to use GScript(GSTRING) where Gscript dll is available whether Avs std or avs+, and only AVS+ Eval(GSTRING) when Avs+ and no GScript dll installed.



Avs64Bit is already covered with 'SI_ProcessBitness'. Do we need it anyway as a convenience function?
Convenience function, I guess you choose if you wanna do it.

I have SytemEnvironment implemented differently. You pass the environment variable and it returns the value. I think that's more elegant and flexible than having a function for each variable (SystemEnvTemp(), SystemEnvComSpec(), SystemEnvComputerName(), SystemEnvUserName()), don't you think?
Again, Convenience functions, but implement as you will. [maybe a note of possible uses in your copious documentation].

The Operating system and CPU caps would really be useful and a helluva lot easier than extraction for the CPU Caps string.

EDIT:

So above GScriptExists() could be used like this


GSTRING = """
Function SomeFunc(int n) { # AKA Terminal() function, but slow iterated version
sum = 0
for(i=1,n) {
sum = sum + i
}
return sum
}

Function Terminal(int n) { # Fast version of above SomeFunc
# Return sum of integers 1 to n. Input n range 1 to 65535, else returns 0. (From Knuth TAOCP Vol 1)
return (n > 65535 || n <= 0) ? 0 : (n % 2 == 0) ? (n+1)*(n/2) : n * ((n + 1) / 2)
}
"""

GSTR = """
if (Sum == Term) {
S2 = " Sum and Term BOTH SAME"
} else {
S2 = " Sum and Term BOTH DIFFERENT"
}
"""

# Install SomeFunc() and Terminal() as Functions
GScriptExists() ? GScript(GSTRING)
\ : IsAvsPLus() ? Eval(GSTRING)
\ : Assert(False,"Need Either GScript or Avs+ for SomeFunc()")

N=3 # N=3 shows Sum=6

Sum = SomeFunc(N)
Term = Terminal(N)

s = "Sum of Numbers 1 to " + String(N) + " = " + String(Sum) + " : Terminal(" + String(N) + ") = " + String(Term)

# Do something that aint a function : Assign a string to S2 using GScript style If/Else
GScriptExists() ? GScript(GSTR) : Eval(GSTR) # Already Checked above for either GScript Or AVS+

BlankClip(Width=480,height=128)
Subtitle(s+"\n"+S2,lsp=0)
Return Last

https://i.postimg.cc/761jqFzc/G-00.jpg (https://postimages.org/)

EDIT: NOTE For Pinterf, note the horizontal offset of both strings.

EDIT: Continued in SysInfo thread here:- https://forum.doom9.org/showthread.php?p=1908594#post1908594

[Groucho2004]

Let's move this to the Sysinfo thread.

[real.finder]

added LUTDeRainbow and LUTDeCrawl

new LUTComb() (it use LUTDeRainbow and LUTDeCrawl with MC) in AdvancedDenoising.avsi

[dREV]

Time for noob questions again.

Should I be modifying the script or something? I got kinda confused as I see nnedi3 twice and so forth. I modified a bit and looks fine in avspmod, however, as I asked over at AviSynth thread https://forum.doom9.org/showthread.php?p=1908974#post1908974 I'm trying to do my script and encode it in HEVC 4:2:0 10 bit profile but it's not working out for my live footage.

Is it possible to do both chroma shift and chroma upscale using your script? I'm just wondering if it's possible with the script you shared since my favorite resize scripts isn't working out in that profile but only in 4:4:4 which I don't mind but I don't wanna do that to live footage.

Here's the script I modified. Let me know if I screwed up or something.useDebilinearM=true #Depend on the source
nativeWidth=1920 #Depend on the source
nativeHeight=1080 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=nativeWidth > outputWidth || nativeHeight > outputHeight
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight) : luma.ResizeX(nativeWidth,nativeHeight) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.25,nsize=6,pscrn=4,qual=2,etype=0,mixed=true,thr=1.0,elast=1.5,kernel_d="Spline64",kernel_u="Spline64",nlsb=false) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)


I dunno if it's doing a chroma shift and chroma upscale but I modified to try to match the file size in avspmod as it wasn't the same as my usual script that I use but it's still less kilobyte size.

Also, am I suppose to be using the above script with the second link that you shared? https://forum.doom9.org/showthread.php?p=1906465#post1906465

[real.finder]

Time for noob questions again.

Should I be modifying the script or something? I got kinda confused as I see nnedi3 twice and so forth. I modified a bit and looks fine in avspmod, however, as I asked over at AviSynth thread https://forum.doom9.org/showthread.php?p=1908974#post1908974 I'm trying to do my script and encode it in HEVC 4:2:0 10 bit profile but it's not working out for my live footage.

Is it possible to do both chroma shift and chroma upscale using your script? I'm just wondering if it's possible with the script you shared since my favorite resize scripts isn't working out in that profile but only in 4:4:4 which I don't mind but I don't wanna do that to live footage.

Here's the script I modified. Let me know if I screwed up or something.useDebilinearM=true #Depend on the source
nativeWidth=1920 #Depend on the source
nativeHeight=1080 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=nativeWidth > outputWidth || nativeHeight > outputHeight
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight) : luma.ResizeX(nativeWidth,nativeHeight) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.25,nsize=6,pscrn=4,qual=2,etype=0,mixed=true,thr=1.0,elast=1.5,kernel_d="Spline64",kernel_u="Spline64",nlsb=false) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)


I dunno if it's doing a chroma shift and chroma upscale but I modified to try to match the file size in avspmod as it wasn't the same as my usual script that I use but it's still less kilobyte size.

Also, am I suppose to be using the above script with the second link that you shared? https://forum.doom9.org/showthread.php?p=1906465#post1906465

nativeWidth =/= inputWidth

native is https://web.archive.org/web/20200112132220/https://kageru.moe/blog/article/resolutions/

edit: I did some update for the method, so it not use descale if the native = input

chroma shift is needed since 4:2:0 mpeg2 (even avc and newer ones) is https://web.archive.org/web/20160611081942/http://img.tfd.com/cde/YCBCR420.GIF

in your old method you use 2 resizers in full YUV which make it slower than my edit

the second one here https://forum.doom9.org/showthread.php?p=1906465#post1906465 just for make the output better

[dREV]

OK, so I can't use your script for 4:2:0. That's fine no big deal.

I have several issues with your script. I am interested in testing the speed but it's not working in either 16 bit or HBD. Maybe I am doing it wrong but it only works in the 8 bit field. Even if I don't edit anything besides native and output resolution sizes it's still the same result.

dither_convert_8_to_16()
# filter(s)
s16 = last
DitherPost()
# filter(s)
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
# does not work here in lsb.
DitherPost()
# 8 bit field - where I put your script at to get it to work
ConvertBits(bits=16)
ConvertToStacked()
useDebilinearM=true #Depend on the source
nativeWidth=1920 #Depend on the source
nativeHeight=1080 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=false,thr=01) : luma.ResizeX(nativeWidth,nativeHeight,desampling=false) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,nsize=6,pscrn=4,qual=2,etype=0,mixed=true,thr=1.0,elast=1.5,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50,nlsb=false) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)
ConvertFromStacked().ConvertToDoubleWidth()

Another issue is I been trying to match the settings from my usual script but it's not doing anything. In the DebilinearM settings for the thr parameter won't change the sharpness even if I go higher it remains the same file size. I got 1 kilobyte more increased file size with the second nnedi3 script copying my script to yours but it's still isn't matching my usual script.

So I took samples from my test in avspmod and took it into photoshop to see why.

My usual script png image was 476 kb
your script is 434 kb

Here's a zoomed in of that image I took and the results show the sharpness on DebilinearM script compared to the cleaner and less grain but less sharpness of your script which explains why the file size is smaller.

First image is using your modified script of DebilinearM together with NNEDI3_resize16 in YUV and
second image is your newer resize script with my editing (the same exact script above but in the 8 bit field).

https://i.ibb.co/ww2qPJD/01-gradfun3mod.jpg https://i.ibb.co/C8VGL7k/02-real-finders-debi-M.jpg

Any clue why is there a difference? It should be the same but it isn't. And why the DebilinearM desampleluma line does nothing with thr? I'm not a fan of the cleaner look but I do like the faster speed compared to my usual script. The sharpness could be an issue for me on detail compared to my usual script but haven't gone that far with my testing so far cuz maybe the file size is different since it's in the 8 bit field and not in 16 bit.

[real.finder]

make these

nativeWidth=1280 #Depend on the source
nativeHeight=720 #Depend on the source

and they should be the same

but seems you don't know what are you doing, since you use descale things without know what is the native resolutions

[dREV]

Could you stick to answering my questions? I know what I am doing but it seems you like to ignore my questions when I post as I specifically stated that I am trying to match my usual script with yours. That's my main priority right now before moving on not looking for no damn native resolution.

Plus you didn't even bother to answer my first question (and several others) on why I cannot use your script in either 16 bit or HBD but only in 8 bit field or why the parameter thr is not working in DebilinearM as I need that for sources that are blurry.

I did a test encode and the speed is slower than my usual script.
I am getting 0.26 fps for 5518 frames using your script
compared to 0.46 fps with same amount of frames using Gradfun3mod + NNEDI_resize16 YUV script in 16 bit.

So I'd appreciate it if you would answer my questions regarding your script instead of just insinuating what you're imagining. And about Scaled444tonative that script is pointless for me unless it is required to use your script more effectively.

[real.finder]

Could you stick to answering my questions? I know what I am doing but it seems you like to ignore my questions when I post as I specifically stated that I am trying to match my usual script with yours. That's my main priority right now before moving on not looking for no damn native resolution.


why do you use Debilinear then? it's not a normal resizer if you don't know!


Plus you didn't even bother to answer my first question (and several others) on why I cannot use your script in either 16 bit or HBD but only in 8 bit field or why the parameter thr is not working in DebilinearM as I need that for sources that are blurry.

it should work with even lsb (which seems you use, not normal 8bit) if you know what you are doing :) but anyway if you read the code you will know that it will not use DebilinearM if the input = native


I did a test encode and the speed is slower than my usual script.
I am getting 0.26 fps for 5518 frames using your script
compared to 0.46 fps with same amount of frames using Gradfun3mod + NNEDI_resize16 YUV script in 16 bit.
ok then stay with your old method since you get that ;)


So I'd appreciate it if you would answer my questions regarding your script instead of just insinuating what you're imagining. And about Scaled444tonative that script is pointless for me unless it is required to use your script more effectively.

tell this to feisty2 (https://forum.doom9.org/showthread.php?t=173005) :rolleyes: Scaled444tonative =~= ChromaReconstructor

[dREV]

No thanks to you I figured it out.

I had to change 2 codes:
from useDebilinearM=false and ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=true)
to useDebilinearM=true and ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=false)
gets it to almost match my usual script which is what I been asking for.

It would seem your ego is getting in the way but it does not work in lsb. Just how many times do I gotta write this before you get it? Even when I post how I got it to work with my actual script here https://forum.doom9.org/showthread.php?p=1909358#post1909358 highlighted in red your inflated ego gets in the way of being able to properly convey an explanation.

Heck, you still haven't answered why thr parameter for DebilinearM will not work despite your own words stating this in your script: #you must set the correct kernel and the settings here (Depend on the source). Only ResizeX and NNEDI3_resize16 settings work. And once again your script does not work in lsb. It only works in 8 bit again https://forum.doom9.org/showthread.php?p=1909358#post1909358 highlighted in red.

Why would I need to ask feisty2 when you gave me the link with no proper explanation if it goes together with your script or not. This is absurd.

Tone down your arrogance dude or maybe you enjoy stroking your ego and wasting people's damn time. Especially when you took the time to reply to me in an attempt to answer my question which I may add you didn't bother to read what my question was in the first place as I was looking for a chroma shift and chroma upscale script and for it to work in a 4:2:0 color depth profile only for you to tell me to just use a resizer... While also providing your new 4:4:4 script. What else was there but your ego being involved?

Has anybody told you you are a terrible teacher?

Instead of correcting what I may be doing wrong your busy stroking your vain ego. I can't stand people with pride.
Last time, your script does not work in lsb even when I add the lsb code to the script. https://forum.doom9.org/showthread.php?p=1909358#post1909358 highlighted in red. Now I know why I haven't kept up with your thread.

[real.finder]

No thanks to you I figured it out.

I had to change 2 codes:
from useDebilinearM=false and ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=true)
to useDebilinearM=true and ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=false)
gets it to almost match my usual script which is what I been asking for.

It would seem your ego is getting in the way but it does not work in lsb. Just how many times do I gotta write this before you get it? Even when I post how I got it to work with my actual script here https://forum.doom9.org/showthread.php?p=1909358#post1909358 highlighted in red your inflated ego gets in the way of being able to properly convey an explanation.

Heck, you still haven't answered why thr parameter for DebilinearM will not work despite your own words stating this in your script: #you must set the correct kernel and the settings here (Depend on the source). Only ResizeX and NNEDI3_resize16 settings work. And once again your script does not work in lsb. It only works in 8 bit again https://forum.doom9.org/showthread.php?p=1909358#post1909358 highlighted in red.

Why would I need to ask feisty2 when you gave me the link with no proper explanation if it goes together with your script or not. This is absurd.

Tone down your arrogance dude or maybe you enjoy stroking your ego and wasting people's damn time. Especially when you took the time to reply to me in an attempt to answer my question which I may add you didn't bother to read what my question was in the first place as I was looking for a chroma shift and chroma upscale script and for it to work in a 4:2:0 color depth profile only for you to tell me to just use a resizer... While also providing your new 4:4:4 script. What else was there but your ego being involved?

Has anybody told you you are a terrible teacher?

Instead of correcting what I may be doing wrong your busy stroking your vain ego. I can't stand people with pride.
Last time, your script does not work in lsb even when I add the lsb code to the script. https://forum.doom9.org/showthread.php?p=1909358#post1909358 highlighted in red

the problem is you don't know what are you doing as I said (and still same with your new edit)

also I am not a teacher :)


dither_convert_8_to_16()
# filter(s)
s16 = last
DitherPost()
# filter(s)
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
# does work here in lsb.
useDebilinearM=true #Depend on the source
nativeWidth=1280 #Depend on the source
nativeHeight=720 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height/2 && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true,thr=01, lsb_inout=true) : luma.ResizeX(nativeWidth,nativeHeight, desampling=true,lsb_in=true,lsb_out=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight, lsb_in=true,lsb=true) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,nsize=6,pscrn=4,qual=2,etype=0,mixed=true,thr=1.0,elast=1.5,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50,nlsb=false, lsb_in=true,lsb=true) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)
ConvertFromStacked().ConvertToDoubleWidth()


or in HBD

dither_convert_8_to_16()
# filter(s)
s16 = last
DitherPost()
# filter(s)
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
ConvertFromStacked()
useDebilinearM=true #Depend on the source
nativeWidth=1280 #Depend on the source
nativeHeight=720 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true,thr=01) : luma.ResizeX(nativeWidth,nativeHeight,desampling=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,nsize=6,pscrn=4,qual=2,etype=0,mixed=true,thr=1.0,elast=1.5,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50,nlsb=false) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)
ConvertToDoubleWidth() #if you still insistent to use old hacks

[dREV]

I'm not surprised you have no idea what I even meant by teacher since English may not be your first language.

Anyways, maybe you should read the documentation in which you helped edit and see that the one for HBD you did in combination with dither_convert_8_to_16() is no where in sight as an example.
http://avisynth.nl/index.php/ConvertStacked which isn't your first time neglecting to document that when I tried to get NNEDI3_resize16 to work only to be told to input nlsb=false which did not exist in previous versions.

And by the way, the HBD does not work. I get this message:
lsb hack is not Compatible with native high bit depth
(path:\ResizeX_plus v1.0.1_mod 9.37.avsi, line 80)
new file (3), line 201

And since I rarely use ResizeX script as a function I had no idea it needed lsb, so that's my fault there.

Now for something odd. Using the same sample images for my testing for whatever reason putting your script in the 8 bit field works out way better when using native resolution on the source.
However, when it's done in lsb (non-HBD) field it creates halo's. I don't even understand why it does that. Nothing has been changed besides adding lsb to the code as seen below.
I used the default script to illustrate this followed by the exact script.

https://i.ibb.co/0s5mjXq/01-8-bit-field.jpg https://i.ibb.co/ZGrkwdc/02-LSB.jpg

Left Image in 8 bit field script
dither_convert_8_to_16()
s16 = last
DitherPost()
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
DitherPost(mode=-1)
useDebilinearM=false #Depend on the source
nativeWidth=1280 #Depend on the source
nativeHeight=720 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true) : luma.ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.25,kernel_u="blackman") #you can add another settings depend on what you needYtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)
ConvertBits(bits=16)
ConvertToStacked()
ConvertFromStacked().ConvertToDoubleWidth()

and

Right Image using LSB script
dither_convert_8_to_16()
s16 = last
DitherPost()
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
useDebilinearM=false #Depend on the source
nativeWidth=1280 #Depend on the source
nativeHeight=720 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true, lsb_inout=true) : luma.ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=true, lsb_in=true,lsb_out=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight, lsb_in=true,lsb=true) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.25,kernel_u="blackman", lsb_in=true,lsb=true) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)
DitherPost(mode=-1)
ConvertBits(bits=16)
ConvertToStacked()
ConvertFromStacked().ConvertToDoubleWidth()

[real.finder]

English may not be your first language

indeed, it's not as I said many many times

and nnedi3_resize16 work with HBD since months, you are not up do date :) go back to older post here, and using HBD is like using 8bit no need to use lsb=true or you will get error or even worst the output will be wrong

anyway, it work for me (with the 2 codes I post or with pure HBD), you are free to use it or not, I didn't do it for you in first place as I said, it was for friend who encode anime in 720 444 from 1080 420 and he is happy with my code :)

and of course the results of 8bit not 100% same as lsb and both not 100% same as HBD, but with nlsb=true (now I make it false by Default as I said before) then HBD almost if not 100% same as lsb (with lsb_in=true, lsb=true, nlsb=true)

[dREV]

and nnedi3_resize16 work with HBD since months, you are not up do date :) go back to older post here, and using HBD is like using 8bit no need to use lsb=true or you will get error or even worst the output will be wrong

I am up to date on nnedi3_resize16.

anyway, it work for me (with the 2 codes I post or with pure HBD), you are free to use it or not, I didn't do it for you in first place as I said, it was for friend who encode anime in 720 444 from 1080 420 and he is happy with my code :)

I am not sure why you even wrote that or had to let me know about it in the first place. You told me about the script and I'm asking questions about it that's it and I can do without your ego in the way. Your script is useful for me to use which is why my main priority was to get it to match my usual script before I move on so I can prepare it with my other resize scripts for source scenarios that I've come across.

and of course the results of 8bit not 100% same as lsb and both not 100% same as HBD, but with nlsb=true (now I make it false by Default as I said before) then HBD almost if not 100% same as lsb (with lsb_in=true, lsb=true, nlsb=true)

I tried using it with nlsb=true with your default script and it now says this message:
nnedi3_resize16: you can't use lsb hacks with HBD input or RGB
(path:\nnedi3_resize_v3.3.plus 2020.avsi, line 137
(New File (3), line 177)

Here's the exact HBD script, as you wrote it here https://forum.doom9.org/showthread.php?p=1909424#post1909424
dither_convert_8_to_16()
s16 = last
DitherPost()
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
ConvertFromStacked()
useDebilinearM=false #Depend on the source
nativeWidth=1280 #Depend on the source
nativeHeight=720 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true) : luma.ResizeX(nativeWidth,nativeHeight,kernel="bicubic",a1=0,a2=1,desampling=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth, outputHeight,nlsb=true) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.25,kernel_u="blackman",nlsb=true) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)
ConvertToDoubleWidth() #if you still insistent to use old hacks


And before it is asked yet again nnedi3_resize16 is updated from your main page. The version is dated 2020.04.07 as well as updated ResizeX v1.0.1 mod 9.37 and DebilinearM v1.3.1 mod 1.29. I'm about at my limit with getting this HBD shit to get it to work - always one problem after another, so I don't care if you answer this one or not.

What's more important to me now is how come your chroma shift on the second nnedi3 was at 0.25? I thought it's suppose to be 0.50. Which one is it? Is it src_left=0.25 for 4:4:4 while src_left=0.50 only for 4:2:0? When I tried to match with my sources it seems 0.25 is the one at least for 2 sources I used so far.

Also, does your script do chroma upscaling? As I said before I don't understand the language of what it's doing so I'd like to know. And is there a way for me to see if it upscaled it or not?

[real.finder]

I was mean nlsb=true with lsb as I put it in () ofc nlsb is still lsb hack, you should not add it when you use HBD as input clip

HBD should has no problem if you don't have to use it with lsb (or another hack), mean if you use it as pure HBD

like:-

ffms2("some8bitvideo")
convertbits(16)
some filter that work with HBD
another filter with HBD

or if your source is already HBD

ffms2("someHBDvideo")
some filter that work with HBD
another filter with HBD

and so on, and in the end use the script with up to date encoder without any additions
well, you may need to convert 10bit (or 12bit or 14bit) to 16bit but that can be done in avs+ like this:-

ffms2("someHBDvideo") #not 16bit, like 10bit or 12bit
some filter that work with HBD
another filter with HBD
convertbits(16)

is this that hard? I don't think so, but you may not like my words but "you don't know what are you doing" and then you start false accusations against me, like say I am waste your time but in fact YOU DID WASTE MY TIME and also another people time like https://forum.doom9.org/showthread.php?p=1884824#post1884824 since you still don't get the relationship between lsb and another hacks with native HBD in avs+

then the native resolutions, and now I am afraid about next war with chroma shift!

anyway, I will not get involved with you again But I will answer for the last time since you don't read wikis and Guides and I am writing this post, I use 0.25 since I deal with half resolutions chroma (4:2:0), in the old code they use 0.5 cuz it done for both chroma and luma (Full YUV) and inside it will be 0.25 for chroma if it 420. edit: for more info https://forum.doom9.org/showthread.php?p=1663804#post1663804 and https://forum.doom9.org/showthread.php?t=170832

so, my code only if you did 1080 420 to 720 444, anything else you have to did some edits, ofc if you encode from 444 to 444 you only need a resizer, and if from 420 to 420 or 422 to 422 you also don't need any code except a good resizer (one that work with MPEG2 chroma centre)

Also, does your script do chroma upscaling? As I said before I don't understand the language of what it's doing so I'd like to know. And is there a way for me to see if it upscaled it or not?

it does ofc, from 540 to 720 using nnedi3_resize16

[real.finder]

added unb_s.avsi *.mp4 guy unbt and unbs and new unbtmc

test code to make sure LUTComb don't make any termporal artifacts (use it after ivtc/deint):- LUTComb.Repair(unbs.Rainbow_Smooth)

added GrainStabilizeMC

and some updates and fixes for others

[Boulder]

Would you mind creating a small utility function to limit the amount of change with hdb clips properly? 8-bit clips are restricted to 0-255 but anything beyond 8 bits allows for more values so it could be used to tune the filtering strength much better. I see the functionality is included as a part of some other functions but I think a generic function would be very useful in many user's toolbox. Thanks for the other ports anyway :)

[real.finder]

Would you mind creating a small utility function to limit the amount of change with hdb clips properly? 8-bit clips are restricted to 0-255 but anything beyond 8 bits allows for more values so it could be used to tune the filtering strength much better. I see the functionality is included as a part of some other functions but I think a generic function would be very useful in many user's toolbox. Thanks for the other ports anyway :)

I already make these parameters float if they int so user can use something like this 231.77

[Boulder]

I already make these parameters float if they int so user can use something like this 231.77

But is that functionality available as a separate utility function so you could use it with any filter against the original clip?

[real.finder]

But is that functionality available as a separate utility function so you could use it with any filter against the original clip?

don't know if I get what you need correctly, but slimit_dif() in Zs_RF_Shared.avsi base on Dither_limit_dif16 idea (not 100% same output)

[Boulder]

don't know if I get what you need correctly, but slimit_dif() in Zs_RF_Shared.avsi base on Dither_limit_dif16 idea (not 100% same output)

Thanks, I'll check that one out. It looks like it would suit the purpose fine.

[Boulder]

I was now able to read some more and I think the function is not exactly what I've been thinking of. I've thought of something more like a hard limiter, i.e. if a pixel value in a hbd clip changes by 300 and my limit is 180, allow the change but limit it to 180. The function, at least by the original dither_tools description, discards the change.

Something like what StainlessS does here: https://forum.doom9.org/showthread.php?p=1870697#post1870697 but with the possibility to utilize the greater range for hbd clips (65536 vs 256 possible values).

[real.finder]

I was now able to read some more and I think the function is not exactly what I've been thinking of. I've thought of something more like a hard limiter, i.e. if a pixel value in a hbd clip changes by 300 and my limit is 180, allow the change but limit it to 180. The function, at least by the original dither_tools description, discards the change.

Something like what StainlessS does here: https://forum.doom9.org/showthread.php?p=1870697#post1870697 but with the possibility to utilize the greater range for hbd clips (65536 vs 256 possible values).

so you need StainlessS script port of Kassandro LimitChange with HBD support?

[StainlessS]

script port of Kassandro LimitChange with HBD support?
Sounds right up your strasse RF.

[Boulder]

Yes, that would be it. It would be a good all-round solution to any occasion :)

[real.finder]

Yes, that would be it. It would be a good all-round solution to any occasion :)

done with new LRemoveDust (with HBD) in op

note: I added LimitChange in Zs_RF_Shared.avsi as sh_LimitChange (with HBD)

[Boulder]

done with new LRemoveDust (with HBD) in op

note: I added LimitChange in Zs_RF_Shared.avsi as sh_LimitChange (with HBD)

Thank you so much :)

[real.finder]

added DFMDeRainbow

it has new mt paramter and use_Flux5framesT

note: use r6 minideen, don't ask me why it not work with last minideen, ask here https://forum.doom9.org/showthread.php?p=1911914#post1911914 also since minideen don't work with Y8 it's not work in full speed

[hello_hello]

real.finder,

For Deblock_QED 2020.04.06 with an 8 bit clip, I get an error message:
mt_LutSpa does not have an argument "scale_inputs".
Am I missing something?

Cheers.

[real.finder]

real.finder,

For Deblock_QED 2020.04.06 with an 8 bit clip, I get an error message:
mt_LutSpa does not have an argument "scale_inputs".
Am I missing something?

Cheers.

last update of https://github.com/pinterf/masktools/releases

[hello_hello]

Ah.... I looked at the minimum version specified in the changelog in the Deblock_QED script and thought I was good.

Thanks.

[real.finder]

Ah.... I looked at the minimum version specified in the changelog in the Deblock_QED script and thought I was good.

Thanks.

I didn't update any minimum version specified in the changelogs recently :devil:

maybe later, anyway for now anyone can help me with this by pull requests or any other way

[real.finder]

new script added

Santiag


some fixes for SangNom (SangNom2 "order" parameter is different from SangNom), new aath bool (I think you should set it to true)

note: you need asd-g SangNom2 for avs 2.6 and avs+

new supported color formats (HBD depends on the plugins), new lumaonly bool and SantiagUV, some speedup

it should work with any avs, but of course you will get more speed and color formats supported with avs 2.6 and for even more in avs+

[real.finder]

some beta updates in https://github.com/realfinder/AVS-Stuff/tree/Community

[mastrboy]

some beta updates in https://github.com/realfinder/AVS-Stuff/tree/Community

Thanks for putting all those scripts up on github, there are so many brilliant minds on this forum that posts really valuable scripts, but often many of those often get "lost" in 100+ pages threads.

[tormento]

some beta updates in https://github.com/realfinder/AVS-Stuff/tree/Community
Please oh please, write in the comments what they do. Some are provided, some not.

I can't have memory of 10+ years of Doom9 threads :rolleyes:

P.S: Out of curiosity, why did you remove the neo_xxx dll and replaced the older ones?

[real.finder]

Please oh please, write in the comments what they do. Some are provided, some not.

I can't have memory of 10+ years of Doom9 threads :rolleyes:


you mean neo_* things? they should be modern and faster but since MeteorRain like ignore my feedbacks (https://forum.doom9.org/showthread.php?p=1911914#post1911914) I will not post any more feedbacks in case any bug or issue happen, I just added support for them since kedautinh12 ask for them, in case you don't have them old ones are used/needed

P.S: Out of curiosity, why did you remove the neo_xxx dll and replaced the older ones?

I didn't get what you mean by that :confused:

[kedautinh12]

you mean neo_* things? they should be modern and faster but since MeteorRain like ignore my feedbacks (https://forum.doom9.org/showthread.php?p=1911914#post1911914) I will not post any more feedbacks in case any bug or issue happen, I just added support for them since kedautinh12 ask for them, in case you don't have them old ones are used/needed
He just feedback, i think he very busy, let's waiting for him
https://forum.doom9.org/showthread.php?p=1914136#post1914136

[kedautinh12]

Author of TemporalDegrain2 offline very long, can you mod it with add neo_dfttest and neo_fft3d??
https://forum.doom9.org/showthread.php?t=175798

[tormento]

I didn't get what you mean by that :confused:
You removed from newest versions of your scripts in favor of the plain vanilla plugins.

[real.finder]

Author of TemporalDegrain2 offline very long, can you mod it with add neo_dfttest and neo_fft3d??
https://forum.doom9.org/showthread.php?t=175798

I don't think I will, I already did edit many scripts so anyone else maybe will do it

You removed from newest versions of your scripts in favor of the plain vanilla plugins.

when? where? I didn't added neo_ things (Except for f3kdb) to them before that (https://forum.doom9.org/showthread.php?p=1913979#post1913979), anyway most new things are optional even the Asd-g ones, because I didn't drop 2.5 support in most scripts and also there are people like manolito around

[tormento]

when? where?
Can't remember exactly but I saw in some revision you put and then you took away.

Perhaps my family Alzheimer's is taking me too. :o

[real.finder]

Can't remember exactly but I saw in some revision you put and then you took away.

Perhaps my family Alzheimer's is taking me too. :o

I didn't remove/delete any revision/commits :rolleyes:

[mastrboy]

Is there a version av DDComb that use an alternative to frfun7 since that plugin doesn't exist for 64bit?

[real.finder]

Is there a version av DDComb that use an alternative to frfun7 since that plugin doesn't exist for 64bit?

no, but there are some settings/conditions that don't need frfun7

[StainlessS]

I'm getting some seriously messed up results with QTGMC() # all defaults,
Dont know what the cause is, originally current avs+ 3.6.1_test8, then tried 3.5_r3106, same,
went back to r2772 and older QTGMC, SMDegrain / etc all ok now.
Also probs with
QTGMC(Preset="Medium",NoisePreset="Faster",SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, tr2=0) # simple least denoise args from Boulder

Gone back to r2772 and old scripts without probs.

Maybe check that QTGMC is working proper.
I'm unclear exactly what requirements are for current script, but whatever they are should not really produce destroyed video if not fully satisfied.

EDIT: After playing 100+ frames, rubbish still there (maybe some clip out-of-sync or something).
https://i.postimg.cc/MvVkzNqj/BH1-00.jpg (https://postimg.cc/MvVkzNqj)

Anybody got current QTGMC working ok with v3.6.1_test8 ? [I have not installed neo_FFT3DFilter/neo_Ddftest, still on old ones]

EDIT: Is singlerate/doublerate sync problem, see next post.

[StainlessS]

Here we loaded below script into VDub2, and jumped to frame 10000
Then played to frame 10305.


VideoFileName ="D:\DVD\BH1\VIDEO_TS\BH1.d2v"
MPEG2Source(VideoFileName)
AssumeTFF
ShowFramenumber(scroll=true)
QTGMC(Preset="Medium",NoisePreset="Faster",SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, tr2=0)
Return Last


result is doublerate,
Can see blurry 10305 current double rate frame number higher up,
and see original framerate frame number in lower number, ie some kind of sync problem between clips.

https://i.postimg.cc/fRCWS0Nt/BH1-TEST-00.jpg (https://postimages.org/)

So I have to make assumption that problem is in QTGMC itself.
EDIT: They should (I think) both be showing the original single rate frame numbers.

EDIT:
Frame from more than halfway though the doublerate clip [75754]
https://i.postimg.cc/d1m5JvdY/BH1-TEST-01.jpg (https://postimages.org/)



and doublerate frame 37877, singlerate input 18938

https://i.postimg.cc/HsQXK3Qq/37877.jpg (https://postimages.org/)

Input frame 37877 with QTGMC() commented out
https://i.postimg.cc/sx8z4p2K/No-QTGMC-37877.jpg (https://postimages.org/)

EDIT: Just defaults QTGMC(), second half of clip all black + FrameNumber of last singlerate input frame.

EDIT:
Last doublerate frame 136626 [ with all defaults QTGMC() ] showing only single number. [complete 2nd half of clip same frame contents]
https://i.postimg.cc/DzcCTn1K/last.jpg (https://postimages.org/)

[real.finder]

can you post video sample?

also what nnedi3 you use? https://github.com/jpsdr/NNEDI3/issues/8 and https://forum.doom9.org/showpost.php?p=1910419&postcount=581

[StainlessS]

RF, above bum steer, using broken UniversalInstaller directory, with NEW QTGMC + SmDegrain + Zs_RF_Shared.avsi,
Copied over ALL OLD plugins from working UniversalInstaller directory, problem disappeared.

Trying to pin down to broken plugin.

EDIT: Dont need sample clip, any clip will demo problem when it exists [in particular the non default args given].

[kedautinh12]

I meet same error

[real.finder]

as I said, the problem is same as the one in https://forum.doom9.org/showpost.php?p=1910419&postcount=581 and https://github.com/jpsdr/NNEDI3/issues/8

it's NNEDI3

[StainlessS]

Yep RF, I musta missed that problem, v0.9.4.54, totally busted.

[Selur]

Struggling here to get DFMDeRainbow working,
first I got that svsMSharpen is unknown renaming it to MSharpen seems to work, but then using:
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll") # 2.2.23.0
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MSharpen.dll") # MSharpen
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FluxSmooth.dll") # 1.4
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\Deen.dll") # beta 2
Import("I:\Hybrid\32bit\avisynthPlugins\Zs_RF_Shared.avsi") # V1.126
Import("I:\Hybrid\32bit\avisynthPlugins\DFMDeRainbow.avsi") # Last updated: 2020/06/02
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_853323747_1_0.ffindex",fpsnum=25,colorspace="YV12")
DFMDeRainbow(interlaced=false)
return last
I get : 'deen need a YV12 input"
then I read here that miniDeen r6 should be used, so I tried:
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MSharpen.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FluxSmooth.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MiniDeen_r6.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Zs_RF_Shared.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\DFMDeRainbow.avsi")
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_853323747_1_0.ffindex",fpsnum=25,colorspace="YV12")
DFMDeRainbow(interlaced=false)
return last
but that only gave me "There is no function named 'deen'."

-> any hint on how to get this working?

Cu Selur

[real.finder]

Struggling here to get DFMDeRainbow working,
first I got that svsMSharpen is unknown renaming it to MSharpen seems to work, but then using:
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll") # 2.2.23.0
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MSharpen.dll") # MSharpen
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FluxSmooth.dll") # 1.4
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\Deen.dll") # beta 2
Import("I:\Hybrid\32bit\avisynthPlugins\Zs_RF_Shared.avsi") # V1.126
Import("I:\Hybrid\32bit\avisynthPlugins\DFMDeRainbow.avsi") # Last updated: 2020/06/02
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_853323747_1_0.ffindex",fpsnum=25,colorspace="YV12")
DFMDeRainbow(interlaced=false)
return last
I get : 'deen need a YV12 input"
then I read here that miniDeen r6 should be used, so I tried:
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MSharpen.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FluxSmooth.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MiniDeen_r6.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Zs_RF_Shared.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\DFMDeRainbow.avsi")
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_853323747_1_0.ffindex",fpsnum=25,colorspace="YV12")
DFMDeRainbow(interlaced=false)
return last
but that only gave me "There is no function named 'deen'."

-> any hint on how to get this working?

Cu Selur

seems you mixed scripts from both master and community branches, if you used one from community then update all others from community as well

anyway, you need MiniDeen r9 now for both master and community, aside it (MiniDeen r9) has bug when you used it with interlaced=true or with field base input

[Selur]

Thanks, that helped! :)

Cu Selur

[kedautinh12]

EEDI2 was released: https://github.com/Asd-g/AviSynth-EEDI2

[kentafilo]

Hi
Sorry for my bab english but in AVS+ 3.6.0
maa2 don't work :-(

https://funkyimg.com/i/35M5t.png

[real.finder]

Hi
Sorry for my bab english but in AVS+ 3.6.0
maa2 don't work :-(

https://funkyimg.com/i/35M5t.png

known thing (been asked many times already like https://forum.doom9.org/showthread.php?p=1915080#post1915080), you need to update your scripts

[kentafilo]

Sorry Real but i have 434 versione of maa2 and avs+ 3.6.1 installed but does not work

https://i.postimg.cc/4yzwr2sR/04-real-finder.png https://i.postimg.cc/HxFQWwBW/02-REAL-FINDER.png https://i.postimg.cc/sxS5MMNY/03-CATTURA-REAL-FINDER.png

Thanks

[mp3dom]

You need this (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) avsi

[kentafilo]

You need this (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) avsi

Thanks :thanks:

[bruno321]

I'm using MCTemporalDenoise v1.4.20 from yesterday, and I've got the latest Zs_RF_Shared.avsi, 1.129. When I try MCTemporalDenoise(settings="high"), I get:

https://i.imgur.com/wfIlz2r.png

When I use "medium", it works fine.

[real.finder]

I'm using MCTemporalDenoise v1.4.20 from yesterday, and I've got the latest Zs_RF_Shared.avsi, 1.129. When I try MCTemporalDenoise(settings="high"), I get:

https://i.imgur.com/wfIlz2r.png

When I use "medium", it works fine.

thanks for report

update Zs_RF_Shared.avsi to 1.130

[bruno321]

It worked, thanks for the quick fix.

[real.finder]

SMDegrain update:- support float type for limit/limitc

[real.finder]

now since mcbob (u8) added, there are new toy for people like feisty2 who don't care about how slow the script is

mcbob(blocksize=8,exEdi=sanimebob(nnedi3pad=true, nnrep=2,bobpresmooth=true))
smam

it should give you all the best of almost all avs Deinterlacers

and it will be more good when TMM2 and EEDI3 add HBD

[tormento]

It's years I have a strange behaviour when using SMDegrain on black & white movies.
SMDegrain (tr=whatever, thSAD=whatever, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
gives more noise removal than
Greyscale()
SMDegrain (tr=whatever, thSAD=whatever, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
Any idea of the reason?

[real.finder]

It's years I have a strange behaviour when using SMDegrain on black & white movies.
SMDegrain (tr=whatever, thSAD=whatever, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
gives more noise removal than
Greyscale()
SMDegrain (tr=whatever, thSAD=whatever, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
Any idea of the reason?

maybe some noise in UV that killed in Greyscale, but since you set chroma=false it should be 100% same

do you have a video sample?

[Boulder]

Could be a UV plane weighting thing in thsad calculation in MAnalyse.

[real.finder]

Could be a UV plane weighting thing in thsad calculation in MAnalyse.

yes I just note chroma=true in first code but in the 2nd it's chroma=false

so yes, it normal behaviour, for black & white chroma should be set to chroma=false, or convert the clip to Y* like Y8 before work with it

[tormento]

do you have a video sample?
Two cuts from the video, a dark one (https://www.mediafire.com/file/jtxfwery48em3c7/eclisse%2C_L%27_%28Criterion%29-040.mkv/file) and a bright one (https://www.mediafire.com/file/ha5xngs5no62cox/eclisse%2C_L%27_%28Criterion%29-041.mkv/file).

With this movie I use:
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
and
Greyscale()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
I am curious to know your findings.

[tormento]

Could be a UV plane weighting thing in thsad calculation in MAnalyse.
And how could I speed things up when no chroma is needed?

[real.finder]

And how could I speed things up when no chroma is needed?

ConvertToY
SMDegrain

[tormento]

ConvertToY
SMDegrain
With plane=0 and chroma=false?

[real.finder]

With plane=0 and chroma=false?

no, ConvertToY/ConvertToY8 alone did the job, unless you use avs 2.5 then the only option you have is plane=0 and chroma=false

[tormento]

no, ConvertToY/ConvertToY8 alone did the job, unless you use avs 2.5 then the only option you have is plane=0 and chroma=false
Thanks, I will try as soon as my encoding queue finishes and I will post results.

[real.finder]

now since mcbob (u8) added, there are new toy for people like feisty2 who don't care about how slow the script is

mcbob(blocksize=8,exEdi=sanimebob(nnedi3pad=true, nnrep=2,bobpresmooth=true))
smam

it should give you all the best of almost all avs Deinterlacers

and it will be more good when TMM2 and EEDI3 add HBD

now after AnimeIVTC/sanimebob update

mcbob(blocksize=4, exEdi=sanimebob(nnedi3pad=true, nnrep=2, bobpresmooth=true, usetfm=true))
smam

and ofc it's more slower now :devil:

[ChaosKing]

now after AnimeIVTC/sanimebob update

mcbob(blocksize=4, exEdi=sanimebob(nnedi3pad=true, nnrep=2, bobpresmooth=true, usetfm=true))
smam

and ofc it's more slower now :devil:

5fps PAL DVD on a ryzen 2700 - cpu is only @ 40%, could get it up to 10fps I guess
Not impressed by it's slowness 😤

But quality seems good ;)

[tormento]

ConvertToY
SMDegrain

It works when I use planes=0, chroma=false, otherwise, with planes=4, chroma=true:

error: KNLMeansCL: 'channels' must be 'Y' with Y8 pixel format!
(D:/Programmi/Media/AviSynth+/plugins64/Zs_RF_Shared-1.132—realfinder.avsi, line 788)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2·109—realfinder.avsi, line 615)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2·109—realfinder.avsi, line 184)

I saw I can use

ConvertToY8(clip [, string matrix] )
ConvertToY(clip, [ string matrix ] ) AVS+

and I use AVS+ indeed. It doesn't work with ConvertToY8 too, anyway.

Statistics on eclisse, L (Criterion)-040 (https://www.mediafire.com/file/jtxfwery48em3c7/eclisse%2C_L%27_%28Criterion%29-040.mkv/file) clip:

SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
encoded 3241 frames, 9.53 fps, 2708.14 kb/s

Greyscale()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 3241 frames, 12.03 fps, 2894.09 kb/s

Greyscale()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
encoded 3241 frames, 9.82 fps, 2708.21 kb/s

ConvertToY8()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 3241 frames, 10.58 fps, 2906.59 kb/s

ConvertToY8()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Not working

ConvertToY()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 3241 frames, 10.42 fps, 2906.54 kb/s

ConvertToY()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Not working

Statistics on eclisse, L (Criterion)-041 (https://www.mediafire.com/file/ha5xngs5no62cox/eclisse%2C_L%27_%28Criterion%29-041.mkv/file) clip:

SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
encoded 2858 frames, 7.30 fps, 4912.82 kb/s

Greyscale()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 2858 frames, 10.30 fps, 5215.71 kb/s

Greyscale()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
encoded 2858 frames, 8.91 fps, 4912.79 kb/s

ConvertToY8()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 2858 frames, 10.42 fps, 5231.36 kb/s

ConvertToY8()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Not working

ConvertToY()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 2858 frames, 10.08 fps, 5231.30 kb/s

ConvertToY()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Not working

Stange enough, uh? I mean, beside errors, y/y8 should give at least better or similar bitrate to full chroma processing.

[real.finder]

with planes=4, chroma=true:

error: KNLMeansCL: 'channels' must be 'Y' with Y8 pixel format!
(D:/Programmi/Media/AviSynth+/plugins64/Zs_RF_Shared-1.132—realfinder.avsi, line 788)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2·109—realfinder.avsi, line 615)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2·109—realfinder.avsi, line 184)
that was a bug, I just fix it in Zs_RF_Shared 1.133

y/y8 should give at least better or similar bitrate to full chroma processing

unless you work with black & white, it wil be a big difference with black & white, even with colored clip it will not be similar and can be more or less bitrate than full chroma processing (Depends on the nature of the source), anyway for black & white y/y8 should be used

[tormento]

unless you work with black & white, it wil be a big difference with black & white, even with colored clip it will not be similar and can be more or less bitrate than full chroma processing (Depends on the nature of the source), anyway for black & white y/y8 should be used
I can't elaborate this.

If you convert to Y/Y8, why the Y/Y8 denoising gives worse results than treating the BW clip as a color one?

Look at these values:
Statistics on eclisse, L (Criterion)-041 (https://www.mediafire.com/file/ha5xngs5no62cox/eclisse%2C_L%27_%28Criterion%29-041.mkv/file) clip:

SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
encoded 2858 frames, 7.30 fps, 4912.82 kb/s

ConvertToY8()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 2858 frames, 10.42 fps, 5231.36 kb/s

ConvertToY()
SMDegrain (tr=6, thSAD=700, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
encoded 2858 frames, 10.08 fps, 5231.30 kb/s

[real.finder]

I can't elaborate this.

If you convert to Y/Y8, why the Y/Y8 denoising gives worse results than treating the BW clip as a color one?

Look at these values:

because chroma is always centred (128 in 8bit) in all pixels so as Boulder told you it's "effect thsad calculation in MAnalyse" so it's wrong and Inaccurate and can remove details and case ghosting that why it give less size, anyway there are a strange situation with your test, the size of ConvertToY/ConvertToY8 and yuv with "plane=0, chroma=false" should be same, and the speed of ConvertToY/ConvertToY8 should be the fastest but you show that both is not

[tormento]

anyway there are a strange situation with your test, the size of ConvertToY/ConvertToY8 and yuv with "plane=0, chroma=false" should be same, and the speed of ConvertToY/ConvertToY8 should be the fastest but you show that both is not
Perhaps I triggered some hidden bug?

[real.finder]

Perhaps I triggered some hidden bug?

yes, in plugins side I think

maybe has a relation with https://forum.doom9.org/showthread.php?p=1916393#post1916393

[tormento]

Service announcement, I'll be *offline for two weeks".
We need you :p

[ChaosKing]

I can't elaborate this.

If you convert to Y/Y8, why the Y/Y8 denoising gives worse results than treating the BW clip as a color one?

Look at these values:

Because you denoise only the first plane, plane 2+3 ("chroma") are not touched, hence the higher bitrate.

[tormento]

Because you denoise only the first plane, plane 2+3 ("chroma") are not touched, hence the higher bitrate.


There is no chroma in greyscale or Y clip, AFAIK.

[real.finder]

There is no chroma in greyscale or Y clip, AFAIK.

yes, seems ChaosKing get it wrong

and even encode y/y8 should be smaller if the encoder didn't convert it to 420 like yv12, and even if it do convert it to 420 it should be smaller than original noisy uv

[ChaosKing]

Ahh yes my mistake. But it was only half wrong, in this particular case ... I think :D

My guess was, that smdegrain or mvtools also uses motion vectors from UV (Idk how smdegrain works). I mean in a grayscale clip I can still output U and V but it's just blank. That is why denoising only Y is stronger. (for a grayscale clip)


clip=ffms2("source")
clip = clip.smdegrain(tr=3, thsad=2000, prefilter=2, plane=4, chroma=true)
clip2 = clip.smdegrain(tr=3, thsad=2000, prefilter=2, plane=0, chroma=false)
clip = clip.ExtractY()
clip2 = clip2.ExtractY()
return stackhorizontal(clip.crop(600,500,-500,-100), clip2.crop(600,500,-500,-100))

https://i.imgur.com/qAVUawm.png

I got an error with prefilter = 4, so I used prefilter=2.
@tormento have you tried other parameters?

EDIT
Can you show your encoding parameters? Since I can't reproduce these numbers even with your parameters...

[tormento]

@tormento have you tried other parameters?
Such as? My interest is speed up denoising working on Y plane but I can’t get to that result.

[ChaosKing]

Such as? My interest is speed up denoising working on Y plane but I can’t get to that result.

Like default parameters. To see if it changes anything since it looks like a bug...

But on my side everything works as expected. denoising only Y is faster and file is smaller...

[tormento]

Like default parameters. To see if it changes anything since it looks like a bug...

But on my side everything works as expected. denoising only Y is faster and file is smaller...


Give me your SMDegrain line.

[ChaosKing]

Give me your SMDegrain line.

https://forum.doom9.org/showthread.php?p=1917491#post1917491

[tormento]

Can you show your encoding parameters? Since I can't reproduce these numbers even with your parameters...
https://forum.doom9.org/showthread.php?p=1917445#post1917445

I put both test files and my scripts there. Try and tell me.

P.S: The not working has been solved by realfinder update.

[ChaosKing]

I mean x264 encoding parameters (or whatever you used)

[tormento]

I mean x264 encoding parameter (or whatever you used)

I use Simple x264/x265 Launcher. The log:

Simple x264 Launcher (Build #1208), built 2020-06-25

Job started at 2020-07-04, 12:20:35.

Source file : E:\in\eclisse\041_6-700y_4t.avs
Output file : E:\in\eclisse\041_6-700y_4t.mkv

--- SYSTEMINFO ---

Binary Path : D:\Eseguibili\Media\x264 Launcher
Avisynth : Yes
VapourSynth : No

--- SETTINGS ---

Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : slow
Tuning : <None>
Profile : High
Custom : --level 4.1 --keyint 240 --aq-mode 2 --sar 1:1 --opencl

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"D:\Eseguibili\Media\x264 Launcher\toolset\x64\x264_x64.exe" --version

x264 0.161.3015 4c2aafd
(libswscale 5.6.100)
(libavformat 58.33.100)
built on Jul 2 2020, gcc: 8.2-win32 20190215
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat license: LGPL version 2.1 or later

WARNING: Your x264 binary uses an untested core (API) version, take care!
This application works best with x264 core (API) version 160. Newer versions may work or not.

Detect video source version:

Creating process:
"D:\Eseguibili\Media\x264 Launcher\toolset\x64\avs2yuv_x64.exe"

Avs2YUV 0.24bm6

> x264 revision: 3015 (core #161)
> Avs2YUV version: 0.24.6

--- GET SOURCE INFO ---

Creating process:
"D:\Eseguibili\Media\x264 Launcher\toolset\x64\avs2yuv_x64.exe" -frames 1 E:\in\eclisse\041_6-700y_4t.avs NUL

E:\in\eclisse\041_6-700y_4t.avs: 1920x1024, Y8, 8-bits, progressive, 24000/1001 fps, 2858 frames
converting input clip to YUV420

Resolution: 1920 x 1024
Frame Rate: 24000/1001
No. Frames: 2858

--- ENCODING VIDEO ---

Creating input process:
"D:\Eseguibili\Media\x264 Launcher\toolset\x64\avs2yuv_x64.exe" E:\in\eclisse\041_6-700y_4t.avs -

Creating encoder process:
"D:\Eseguibili\Media\x264 Launcher\toolset\x64\x264_x64.exe" --output-depth 8 --crf 20.0 --preset slow --profile high --level 4.1 --keyint 240 --aq-mode 2 --sar 1:1 --opencl --output E:\in\eclisse\041_6-700y_4t.mkv --frames 2858 --demuxer y4m --stdin y4m -

y4m [info]: 1920x1024p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 1060 3GB
x264 [info]: profile High, level 4.1, 4:2:0, 8-bit
x264 [info]: frame I:18 Avg QP:17.33 size:195983
x264 [info]: frame P:752 Avg QP:20.21 size: 59222
x264 [info]: frame B:2088 Avg QP:25.01 size: 14313
x264 [info]: consecutive B-frames: 1.6% 1.8% 3.7% 92.9%
x264 [info]: mb I I16..4: 6.7% 84.5% 8.9%
x264 [info]: mb P I16..4: 0.8% 7.7% 0.6% P16..4: 43.6% 22.9% 11.4% 0.0% 0.0% skip:13.0%
x264 [info]: mb B I16..4: 0.0% 0.4% 0.1% B16..8: 50.2% 6.9% 1.6% direct: 2.2% skip:38.7% L0:37.7% L1:52.1% BI:10.2%
x264 [info]: 8x8 transform intra:84.5% inter:71.4%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra: 87.0% 0.0% 0.0% inter: 17.9% 0.0% 0.0%
x264 [info]: i16 v,h,dc,p: 23% 15% 9% 53%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 15% 4% 9% 12% 12% 12% 12% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 10% 3% 9% 15% 15% 14% 11% 13%
x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
x264 [info]: Weighted P-Frames: Y:0.1% UV:0.0%
x264 [info]: ref P L0: 61.1% 21.0% 13.8% 4.1% 0.1%
x264 [info]: ref B L0: 93.2% 5.5% 1.3%
x264 [info]: ref B L1: 96.7% 3.3%
x264 [info]: kb/s:5231.28
encoded 2858 frames, 10.11 fps, 5231.33 kb/s
av2y [info]: E:\in\eclisse\041_6-700y_4t.avs: 1920x1024, Y8, 8-bits, progressive, 24000/1001 fps, 2858 frames
av2y [info]: converting input clip to YUV420
Final file size is 74.4 MB bytes.

--- COMPLETED ---

Job finished at 2020-07-04, 12:25:22. Process took 4 minutes, 47 seconds.

[tormento]

Any idea to solve that issue?

[Boulder]

Have you tried converting the clip to regular YV12 before it ends up in the encoder process?

[LeXXuz]

real.finder does dfttestMC support sstring parameter for dfttest instead of sigma?

I usually prefer different sigma values based on frequency.

I can set sstring in dfttestMC parameters, f.e. like this:
dfttestMC(Y=true, U=false, V=false, sstring="$ 0.0:4 0.2:9 0.4:16 0.6:25 0.7:16 0.8:9 0.9:4 1.0:25", tbsize=5, dither=0, dfttest_params=", threads=16")

But I wonder if this really gets relayed to dfttest or the default value (sigma=16) is used instead? From my testing the latter seems to be the case.

I also can't set this string inside the 'dft_params' string either. Is this a syntax problem? Can you set a string inside a string anyway? :confused:

[real.finder]

real.finder does dfttestMC support sstring parameter for dfttest instead of sigma?

I usually prefer different sigma values based on frequency.

I can set sstring in dfttestMC parameters, f.e. like this:
dfttestMC(Y=true, U=false, V=false, sstring="$ 0.0:4 0.2:9 0.4:16 0.6:25 0.7:16 0.8:9 0.9:4 1.0:25", tbsize=5, dither=0, dfttest_params=", threads=16")

But I wonder if this really gets relayed to dfttest or the default value (sigma=16) is used instead? From my testing the latter seems to be the case.

I also can't set this string inside the 'dft_params' string either. Is this a syntax problem? Can you set a string inside a string anyway? :confused:

sstring in dfttestMC should work

you can't use dfttest_params for things has independent parameters like sstring since it will be used twice and you will get error about that

"Can you set a string inside a string anyway?"

you can, with dfttest_params=""",somepara="somestring" """

[LeXXuz]

sstring in dfttestMC should work

It seems I made an error in my script that's why I had the impression sstring may not work.
Good to know sstring is supported. :)


you can't use dfttest_params for things has independent parameters like sstring since it will be used twice and you will get error about that

"Can you set a string inside a string anyway?"

you can, with dfttest_params=""",somepara="somestring" """

Thanks for the quick reply and that explanation. :)
Finally I now know how to use that syntax correctly. :o:D

[Dogway]

@real.finder can you have a look at nnedi3_resize16()? I had stability issues when used on YUV444P16 format as opposed to stacked.

[real.finder]

@real.finder can you have a look at nnedi3_resize16()? I had stability issues when used on YUV444P16 format as opposed to stacked.

they are not a same I note this before https://forum.doom9.org/showthread.php?p=1903763#post1903763

[Dogway]

It's not quality issues but performance/stability, maybe an avisynth bug, just updated AVS+ and plugins to latest yesterday.


By the way I fixed a stability issue in "Stabilization Tools Pack", do you want me to PR it?

UVfix ? eval("""
clpDith=Dither_convert_8_to_16()

ScriptClip ("
blue=round((AverageChromaU(clp) - AverageChromaU()) * 256.0)
red=round((AverageChromaV(clp) - AverageChromaV()) * 256.0)

SmoothTweak16(clpDith,saturation=1.0,hue1=min(384,blue),hue2=min(384,red),HQ=true)
DitherPost(stacked=true,prot=false,mode=6)
", args="clp,clpDith" )
""") : last

It would be wise to convert this to internal avisynth but I couldn't find a U and V axis based HUE function, read on Tweak or ColorYUV. (I think I can swap planes as a dirty trick tho)

[real.finder]

It's not quality issues but performance/stability, maybe an avisynth bug, just updated AVS+ and plugins to latest yesterday.


By the way I fixed a stability issue in "Stabilization Tools Pack", do you want me to PR it?

UVfix ? eval("""
clpDith=Dither_convert_8_to_16()

ScriptClip ("
blue=round((AverageChromaU(clp) - AverageChromaU()) * 256.0)
red=round((AverageChromaV(clp) - AverageChromaV()) * 256.0)

SmoothTweak16(clpDith,saturation=1.0,hue1=min(384,blue),hue2=min(384,red),HQ=true)
DitherPost(stacked=true,prot=false,mode=6)
", args="clp,clpDith" )
""") : last

It would be wise to convert this to internal avisynth but I couldn't find a U and V axis based HUE function, read on Tweak or ColorYUV. (I think I can swap planes as a dirty trick tho)

I didn't get what "PR it" mean

I think UV bug fixed in some update of depan plugin

and indeed HBD is slower than lsb (not nlsb) in case of nnedi3_resize16, since lsb use 8bit for nnedi3 (it will be 16bit if you set nlsb to true), also some new script functions (like I said in case of slimit_dif vs Dither_limit_dif16 in the old link) not as fast as the old dither functions (I think it used asm optimization)

[Dogway]

PullRequest over Github. I don't know if Depan is fixed, should run a test but I'm just finishing a project, also need to run a test to see if current internal Resizers are as fast as the ResizersMT from avsresizers by jpsdr. It's been some time since I last checked.

[real.finder]

PullRequest over Github. I don't know if Depan is fixed, should run a test but I'm just finishing a project, also need to run a test to see if current internal Resizers are as fast as the ResizersMT from avsresizers by jpsdr. It's been some time since I last checked.

then sure, why not? if you note I keep it in the edit I made in Stabilization Tools Pack in Stab3 but made it false by default (in case some one need it if using old things for debug or whatever)

internal Resizers should be faster than the ResizersMT when using external MT (prefetch in avs+) and no internal MT (set the Threads to 1 in ResizersMT)

[real.finder]

since there are no answer to this https://forum.doom9.org/showthread.php?p=1915440#post1915440

I plan to make some trick with something like how QTGMC_GetUserGlobal work, mean if the user set some global thing like set_plugins_threads it will be used in all scripts for internal multi-threading

I will not start work on this as soon as possible, maybe it will done in some days or weeks

[LeXXuz]

real.finder I've been playing around with motion compensated dfttest a little.

I've noticed camera pans in a noisy movie look more blury and noisy with increased tbsize.

I always thought increasing temporal resolution would benefit motion compensated noise reduction, especially in pans. Or do I misunderstand this?

I did two encodes with identical settings. One with tbsize=3 and one with tbsize=7. The latter gets bigger in file size and looks less clean on moving objects :confused:

[real.finder]

real.finder I've been playing around with motion compensated dfttest a little.

I've noticed camera pans in a noisy movie look more blury and noisy with increased tbsize.

I always thought increasing temporal resolution would benefit motion compensated noise reduction, especially in pans. Or do I misunderstand this?

I did two encodes with identical settings. One with tbsize=3 and one with tbsize=7. The latter gets bigger in file size and looks less clean on moving objects :confused:

didn't you note this in the script itself?
# tbsize should not be set higher than mc * 2 + 1.

and it's better set the mc not the tbsize in dfttestMC since by default tbsize will change itself to mc * 2 + 1

[LeXXuz]

didn't you note this in the script itself?
# tbsize should not be set higher than mc * 2 + 1.

and it's better set the mc not the tbsize in dfttestMC since by default tbsize will change itself to mc * 2 + 1

Whoops. I didn't notice that, no. :o Thanks for the explanation. Any recommendet values for mc for very noisy/little noisy sources? :)

[real.finder]

Whoops. I didn't notice that, no. :o Thanks for the explanation. Any recommendet values for mc for very noisy/little noisy sources? :)

for very noisy you may want to use mc=5, anyway trying and testing is the best thing

[LigH]

Nothing serious, I believe, just a warning in AvsInfoTool: Zs_RF_Shared.avsi has a function "Undefined" which appears as duplicate of an internal core function with the same name. But I guess this is intended?

[real.finder]

Nothing serious, I believe, just a warning in AvsInfoTool: Zs_RF_Shared.avsi has a function "Undefined" which appears as duplicate of an internal core function with the same name. But I guess this is intended?

it will not be loaded in first placed unless you use avs 2.5

[real.finder]

since there are no answer to this https://forum.doom9.org/showthread.php?p=1915440#post1915440

I plan to make some trick with something like how QTGMC_GetUserGlobal work, mean if the user set some global thing like set_plugins_threads it will be used in all scripts for internal multi-threading

I will not start work on this as soon as possible, maybe it will done in some days or weeks

done for QTGMC in Community branch

Global set_plugins_threads =1
QTGMC

seems work as it should

[LeXXuz]

real.finder can you tell me if LSFMod() and dfttestMC() support mod-4 or even just mod-2 resolutions?
I can't find all infos in the readmes for the filters related to these scripts.

Usually I over- or undercrop to mod-16 resolution because I had strange artefacts with some avs filters in the long past.

I wonder if this is still valid or any resolution will do as long as it's mod-2 at least.

[real.finder]

real.finder can you tell me if LSFMod() and dfttestMC() support mod-4 or even just mod-2 resolutions?
I can't find all infos in the readmes for the filters related to these scripts.

Usually I over- or undercrop to mod-16 resolution because I had strange artefacts with some avs filters in the long past.

I wonder if this is still valid or any resolution will do as long as it's mod-2 at least.

you should ask plugins Developers about this, anyway all I can say is try and see, and keep in mind I didn't made LSFMod() and dfttestMC() in first place I just added new things to them and did some fixes

[LouieChuckyMerry]

Hi real.finder, I hope you're well. Happy Friday :) ! I'm receiving an error message from your latest version of SMDegrain (3.1.2.109s) when trying to encode a 10-bit source:

MDegrainX : out16 flag only for 8 bit sources (SMDegrain.avsiPath, line 545)

Is there a simple way to correct this? Or should I just use an 8-bit lossless intermediary? Thanks for your time.

[real.finder]

Hi real.finder, I hope you're well. Happy Friday :) ! I'm receiving an error message from your latest version of SMDegrain (3.1.2.109s) when trying to encode a 10-bit source:

MDegrainX : out16 flag only for 8 bit sources (SMDegrain.avsiPath, line 545)

Is there a simple way to correct this? Or should I just use an 8-bit lossless intermediary? Thanks for your time.

dont use n16=true or n16_out=true with more than 8bit input

[LouieChuckyMerry]

dont use n16=true or n16_out=true with more than 8bit input

Thanks for your reply. Will the 10-bit source video still be processed in 16-bits if I don't use n16=true or n16_out=true?

[StainlessS]

I aint looked at this at all, but maybe could mod script something like

n16_out = (input_bpc>8) ? false : n16_out

:helpful:

[real.finder]

Thanks for your reply. Will the 10-bit source video still be processed in 16-bits if I don't use n16=true or n16_out=true?

it will processed in 10bit

if you want to processed in 16bit simply convert your clip to 16bit before SMDegrain

I aint looked at this at all, but maybe could mod script something like

n16_out = (input_bpc>8) ? false : n16_out

:helpful:

that will make n16_out output things that not 16bit (between 10bit and 14bit)

edit: at the end, n16_out and n16 are just fast and clean replacement for lsb_out and lsb, so no point to make them work with more than 8bit input in first place :)

[real.finder]

more updates on let scripts use sh_GetUserGlobalIMT (Global set_plugins_threads = X) https://github.com/realfinder/AVS-Stuff/tree/Community

[StainlessS]

I was just going by this,
dont use n16=true or n16_out=true with more than 8bit input
I did not bother to do same for n16 but intended similar,
Purpose just so as to comply with above quote. [ie avoid/ignore stupid args]

[LouieChuckyMerry]

dont use n16=true or n16_out=true with more than 8bit input

When I eliminate "n16=true" and "n16_out=true" from the script I receive the error message:

I don't know what 'AvsPlusVersionNumber' means. (SMDegrain.avsiPath, line 76)

I'm using AviSynth+ v3.6.1-64bit (:thanks: Grouco2004!), if that matters.

[StainlessS]

Think you want,
Real.Finder Zs_RF_Shared.avsi:- https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/ZS%20AVS%20Shared%20Functions.avsi

[LouieChuckyMerry]

Think you want,
Real.Finder Zs_RF_Shared.avsi:- https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/ZS%20AVS%20Shared%20Functions.avsi

Page Not Found :confused:

Are you toying with me, Bender :p ?

[StainlessS]

Page Not Found :confused:

Are you toying with me, Bender :p ?

Yep.

https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi

He changed name again (always good for a giggle is RF)

Anyways, just look in parent directory if fails in future when renamed again.

[LouieChuckyMerry]

Thanks StainlessS, that stopped the error message. Now, what exactly is it :p ?

[StainlessS]

that stopped the error message. Now, what exactly is it ?

Its a message, that tells what the error is.

Oh, and by the way, the script thingy is just RF general use functions, used throughout his mods.

[LouieChuckyMerry]

Please allow me to be more specific. Why would the real.finder SharedFunctions1.135.avsi to which you pointed me cause the AviSynth+ error message to disappear? Make believe I'm even slower than I seem when you kindly explain...

[hintlou]

After I update all my avsies from real.finder,QTGMC makes script error:sneo_FFT3D does not have a named "threads".
my code:
Import("E:\KKBOX\StaxRip-x64-2.1.3.9-beta\Apps\Plugins\AVS\QTGMC\QTGMC.avsi")
MPEG2Source("E:\Downloads\xz_temp\xz.d2v")
AssumeFPS(25.000)
Global set_plugins_threads =1
QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=8).SelectEven()
Lanczos4Resize(768, 576)

[StainlessS]

Why would the real.finder SharedFunctions1.135.avsi to which you pointed me cause the AviSynth+ error message to disappear?

AvsPlusVersionNumber() is a function in that avsi, if avsi missing, then cannot find the function.
EDIT: Is used in many other scripts and so is included in shared function script to avoid having same funcs in every script.

[StainlessS]

Hintlou,

What is the full error message incl line number ?
Where do you get sneo_FFT3D script ?

EDIT:
This is the only line in QTGMC.avsi that calls sneo_FFT3D(), no threads arg used. Are you using current QTGMC v3.368s ?


noiseWindow.sneo_FFT3D( u=ChromaNoise ? 3 : 2,v=ChromaNoise ? 3 : 2, sigma=Sigma, bt=noiseTD )

[real.finder]

Please allow me to be more specific. Why would the real.finder SharedFunctions1.135.avsi to which you pointed me cause the AviSynth+ error message to disappear? Make believe I'm even slower than I seem when you kindly explain...

it's not avs+ error in first place, it's function name for return avs+ version

I made all shared functions in one script to easy update them and avoid any problem with any shared functions not updated in some script

After I update all my avsies from real.finder,QTGMC makes script error:sneo_FFT3D does not have a named "threads".
my code:
Import("E:\KKBOX\StaxRip-x64-2.1.3.9-beta\Apps\Plugins\AVS\QTGMC\QTGMC.avsi")
MPEG2Source("E:\Downloads\xz_temp\xz.d2v")
AssumeFPS(25.000)
Global set_plugins_threads =1
QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=8).SelectEven()
Lanczos4Resize(768, 576)

you need to update Zs_RF_Shared.avsi (Shared Functions and utility) and use https://www.solidfiles.com/v/xZn85B3knMGAy

edit: also neo-fft3d https://www.solidfiles.com/v/55WKMW38dpX42 but keep in mind both has known bugs, I recommend use old dfttest and fft3dfilter

[real.finder]

After I update all my avsies from real.finder,QTGMC makes script error:sneo_FFT3D does not have a named "threads".
my code:
Import("E:\KKBOX\StaxRip-x64-2.1.3.9-beta\Apps\Plugins\AVS\QTGMC\QTGMC.avsi")
MPEG2Source("E:\Downloads\xz_temp\xz.d2v")
AssumeFPS(25.000)
Global set_plugins_threads =1
QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=8).SelectEven()
Lanczos4Resize(768, 576)

yes there were bug in QTGMC, thanks for report, it fixed in 3.371

Hintlou,

What is the full error message incl line number ?
Where do you get sneo_FFT3D script ?

EDIT:
This is the only line in QTGMC.avsi that calls sneo_FFT3D(), no threads arg used. Are you using current QTGMC v3.368s ?


noiseWindow.sneo_FFT3D( u=ChromaNoise ? 3 : 2,v=ChromaNoise ? 3 : 2, sigma=Sigma, bt=noiseTD )


Hintlou use the last test updates from Community tree, not the stable master one

[real.finder]

Yep.

https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi

He changed name again (always good for a giggle is RF)

Anyways, just look in parent directory if fails in future when renamed again.

no, I didn't, it's still same name you make my do it https://forum.doom9.org/showthread.php?p=1906639&highlight=Zs_RF_Shared.avsi#post1906639 ;)

[StainlessS]

OK, maybe I still had link to old named script. My Bad :)

[Boulder]

The link to Zs_RF_Shared.avsi is incorrect in your first post. Or is it intentionally an older version?

[ChaosKing]

First post link = master branch, you're probably on the community branch.

[Boulder]

First post link = master branch, you're probably on the community branch.

I was just confused as I updated QTGMC as per rf's previous post and went to update the utility script using the link. But now I know that there's two branches instead of just one, thanks :)

[StainlessS]

First post link = master branch, you're probably on the community branch.


what exactly is the difference ???
[I'm a bit thick]

Community is 'Nightly/beta build' ?

[ChaosKing]

As far as I understood: master = stable. Community = bleeding edge / experimental
Maybe master as the default branch would be the better choice + explain what the difference is in the Readme on github.

[StainlessS]

"bleeding edge", ooh goodness!
Thanks.

[LouieChuckyMerry]

AvsPlusVersionNumber() is a function in that avsi, if avsi missing, then cannot find the function.
EDIT: Is used in many other scripts and so is included in shared function script to avoid having same funcs in every script.

it's not avs+ error in first place, it's function name for return avs+ version

I made all shared functions in one script to easy update them and avoid any problem with any shared functions not updated in some script.

Thanks for the explanation :) .

[real.finder]

all MT updates from Community now added to master

[kedautinh12]

Can't call QTGMC_bob() with new QTGMC ver

[real.finder]

Can't call QTGMC_bob() with new QTGMC ver

it's replaced by sh_Bob in https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi

[kedautinh12]

Thanks

[real.finder]

added AutoDeblock2 with HBD

[jinkazuya]

Just wonder if there is a way to speed up or use up all cores of the CPU? I have the first generation of threadripper of AMD? I only use QTGMC to deinterlace my video - encoding 1080i to 720p of the TS. Here is only one line of script that I used.

SetFilterMTMode("", 2)
.....// some plugins and scripts that support QTGMC
QTGMC(Preset="Fast",EdiMode="nnedi3", MatchEnhance=1.3, SourceMatch=2, NNeurons=2, Lossless=2, StabilizeNoise=true, EdiThreads=16)
SelectEven()
LanczosResize(1280,720) # Lanczos (Sharp)
prefetch(10)

However, the computer only use 50% of the CPU power and then the max frames encoded per minute is about 20. If there is a way to speed it up to probably more than 30. It would be great. Thanks.

[LigH]

Parallelization has its limits. There are calculations which need to wait for intermediate results of previous calculations. This cannot be accelerated. You can only make compromises not to waste too much time on too little differences.

EdiThreads=16 is surely overkill, prefetch(10) as well: I doubt you have 10*16=160 cores in your CPU. Many many threads will need to wait for other threads to finish before they get any CPU time. And on top, it possibly needs so much RAM that some data needs to be swapped to harddisk.

PS: This question would have fit better in the thread about QTGMC (https://forum.doom9.org/showthread.php?t=174544)...

[LeXXuz]

I second that. I did a lot of testing with Avisynth' multi-threading on my 12-core and 16-core Ryzen machines.

My conclusion was to not go higher than Prefetch(4). Anything higher utilized more CPU usage but gained NO speed improvement at all. At least not with the filters I use on a regular basis.

To speed things up you could split your encode in two parts and run two encodes in parallel. Or encode two movies in prallel. That's what I do.

[real.finder]

no need to use SetFilterMTMode("", 2)
take the text from https://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest and put it in MtModes.avsi and then put MtModes.avsi in plugins folder

and maybe using with last qtgmc

Global set_plugins_threads = 1
QTGMC(Preset="Fast",EdiMode="nnedi3", MatchEnhance=1.3, SourceMatch=2, NNeurons=2, Lossless=2, StabilizeNoise=true)
SelectEven()
LanczosResize(1280,720) # Lanczos (Sharp)
prefetch(10)

will help

[jinkazuya]

I second that. I did a lot of testing with Avisynth' multi-threading on my 12-core and 16-core Ryzen machines.

My conclusion was to not go higher than Prefetch(4). Anything higher utilized more CPU usage but gained NO speed improvement at all. At least not with the filters I use on a regular basis.

To speed things up you could split your encode in two parts and run two encodes in parallel. Or encode two movies in prallel. That's what I do.

How do I split my encode and this is very interesting and I am a noob and hope u could show me. Thx.

To real.finder: what is this line for?
Global set_plugins_threads = 1

[real.finder]

How do I split my encode and this is very interesting and I am a noob and hope u could show me. Thx.

To real.finder: what is this line for?
Global set_plugins_threads = 1

start read from https://forum.doom9.org/showthread.php?p=1921381#post1921381

[jinkazuya]

start read from https://forum.doom9.org/showthread.php?p=1921381#post1921381

Thanks a lot

Here is the whole script

Import("C:\Program Files (x86)\AviSynth+\Plugins64+\MtModes.avsi")
LoadPlugin("C:\Users\Desktop\MEGUI 64\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("C:\Users\HDTV 1080i X264 2Audio.mkv")
Import("C:\Program Files (x86)\AviSynth+\Plugins64+\SMDegrain.avsi")
Import("C:\Program Files (x86)\AviSynth+\Plugins64+\Zs_RF_Shared.avsi")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\RgTools.dll")
Import("C:\Program Files (x86)\AviSynth+\plugins64+\QTGMC.avsi")

Global set_plugins_threads = 1
QTGMC(Preset="Fast",EdiMode="nnedi3", MatchEnhance=1.3, SourceMatch=2, NNeurons=2, Lossless=2, StabilizeNoise=true)
SelectEven()
LanczosResize(1280,720) # Lanczos (Sharp)
prefetch(16)

Below is the attached image of the MEGUI and the task manager.

Still cannot utilize all the power of the CPU. Just wonder how to split the encode and run them in parallel with MEGUI?

Half way through the encode, there is an error, which crashes the MEGUI
Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

[StvG]

Just wonder if there is a way to speed up or use up all cores of the CPU? I have the first generation of threadripper of AMD? I only use QTGMC to deinterlace my video - encoding 1080i to 720p of the TS. Here is only one line of script that I used.



However, the computer only use 50% of the CPU power and then the max frames encoded per minute is about 20. If there is a way to speed it up to probably more than 30. It would be great. Thanks.
You should try splitting into chunks (https://forum.doom9.org/showthread.php?p=1906337#post1906337).

[real.finder]

Thanks a lot

Here is the whole script

Import("C:\Program Files (x86)\AviSynth+\Plugins64+\MtModes.avsi")
LoadPlugin("C:\Users\Desktop\MEGUI 64\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("C:\Users\HDTV 1080i X264 2Audio.mkv")
Import("C:\Program Files (x86)\AviSynth+\Plugins64+\SMDegrain.avsi")
Import("C:\Program Files (x86)\AviSynth+\Plugins64+\Zs_RF_Shared.avsi")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\RgTools.dll")
Import("C:\Program Files (x86)\AviSynth+\plugins64+\QTGMC.avsi")

Global set_plugins_threads = 1
QTGMC(Preset="Fast",EdiMode="nnedi3", MatchEnhance=1.3, SourceMatch=2, NNeurons=2, Lossless=2, StabilizeNoise=true)
SelectEven()
LanczosResize(1280,720) # Lanczos (Sharp)
prefetch(16)

Below is the attached image of the MEGUI and the task manager.

Still cannot utilize all the power of the CPU. Just wonder how to split the encode and run them in parallel with MEGUI?


post the image using https://postimages.org/

Half way through the encode, there is an error, which crashes the MEGUI

post the MEGUI full log using https://pastebin.com/

[LeXXuz]

How do I split my encode and this is very interesting and I am a noob and hope u could show me. Thx.


A simple way is to use the Trim() command in your Avisynth scripts. Or you could try out Staxrip as an encoding tool. If I'm not mistaken it does support splitting your encodes in several parts.

As for Avisynth. Create two identical scripts and add a Trim command in each before the Prefetch() command.

For example if your movie has like 150,000 frames you would add
Trim (0,75000) to your first script and Trim(75001,0) to your second.

Then encode both parts in parallel with your encoder.

If you use Matroska files for your destination files, which is the most common option today, it is really no problem to put those two parts back together again.

You can use MKVtoolnix to append the second video encode to the first one. Just add the first video part to MKVtoolnix right click on it and select "append" files. No need to split audio and subtitles of course. Just add them as usual to your muxing project.

For more detailed info you should look into the appropriate forums here.

[real.finder]

https://forum.doom9.org/attachment.php?attachmentid=17502&stc=1&d=1601592369

I think this usage is ok, you should not get always 100% in new cpus, anyway maybe you can use prefetch(20)

[LeXXuz]

real.finder I can't give the threads parameter with dfttestmc to dfttest.

This is my script line:
dfttestMC(Y=true, U=true, V=true, sstring="0.0:48 0.05:0 0.1:12 0.2:18 0.3:24 0.4:36 1.0:48", MC=2, dither=0, dfttest_params="opt=4, threads=8")

I get this error message:
[Error] [02.10.2020 19:28:56] Exception message
-[NoImage] Calling setup of processor failed with error 'The file E:\test.mkv.avs cannot be opened.
-[NoImage] Error message for your reference: Script error: expected a , or )
-[NoImage] ((null), line 1, column 195)
-[NoImage] (C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\dfttestMC.avsi, line 184)

If I remove the threads parameter everything works just fine.
Calling dfttest with this line:
dfttest(Y=true, U=true, V=true, sstring="0.0:48 0.05:0 0.1:12 0.2:18 0.3:24 0.4:36 1.0:48", threads=5, dither=0, opt=4, threads=8)
also works fine.

What do I miss? What did I forget? :o

[real.finder]

real.finder I can't give the threads parameter with dfttestmc to dfttest.

This is my script line:
dfttestMC(Y=true, U=true, V=true, sstring="0.0:48 0.05:0 0.1:12 0.2:18 0.3:24 0.4:36 1.0:48", MC=2, dither=0, dfttest_params="opt=4, threads=8")

I get this error message:

If I remove the threads parameter everything works just fine.
Calling dfttest with this line:
dfttest(Y=true, U=true, V=true, sstring="0.0:48 0.05:0 0.1:12 0.2:18 0.3:24 0.4:36 1.0:48", threads=5, dither=0, opt=4, threads=8)
also works fine.

What do I miss? What did I forget? :o

dfttest_params need to start with (",) your is not and anyway you will get error in both cases since dfttestmc has threads in last updates

[LeXXuz]

Of course! I forgot the comma. Oh gee. :rolleyes:
Thank you!

PS: Didn't know it's implemented now. Guess I should update my script. :o

[jinkazuya]

-[Information] Log for job1 (video, Jade HDTV 1080i X264 2Audio-CHDHKTV.mkv - Copy.avs -> Jade HDTV 1080i X264 2Audio-CHDHKTV.mkv - Copy.264)
--[Information] [10/2/2020 6:15:59 PM] Started handling job
--[Information] [10/2/2020 6:16:00 PM] Preprocessing
-[NoImage] SetFilterMTMode("", 2)
-[NoImage] LoadPlugin("C:\Users\Desktop\MEGUI 64\tools\lsmash\LSMASHSource.dll")
-[NoImage] LWLibavVideoSource("C:\Users\\Desktop\Encoding Videos\Jade HDTV 1080i X264 2Audio-CHDHKTV.mkv")
-[NoImage] Import("C:\Program Files (x86)\AviSynth+\Plugins64+\SMDegrain.avsi")
-[NoImage] Import("C:\Program Files (x86)\AviSynth+\Plugins64+\Zs_RF_Shared.avsi")
-[NoImage] LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\masktools2.dll")
-[NoImage] LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\nnedi3.dll")
-[NoImage] LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\mvtools2.dll")
-[NoImage] LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\RgTools.dll")
-[NoImage] Import("C:\Program Files (x86)\AviSynth+\plugins64+\QTGMC.avsi")
-[NoImage] QTGMC(Preset="Fast",EdiMode="nnedi3", MatchEnhance=1.3, SourceMatch=2, NNeurons=2, Lossless=2, StabilizeNoise=true)
-[NoImage] SelectEven()
-[NoImage] LanczosResize(1280,720) # Lanczos (Sharp)
-[NoImage] trim(32644, 65286)
-[NoImage] prefetch(16)
--[Information] [10/2/2020 6:16:00 PM] AviSynth input script
--[Information] [10/2/2020 6:16:02 PM] resolution: 1280x720
--[Information] [10/2/2020 6:16:02 PM] frame rate: 25/1
--[Information] [10/2/2020 6:16:02 PM] frames: 32642
--[Information] [10/2/2020 6:16:02 PM] length: 00:21:45.680
--[Information] [10/2/2020 6:16:02 PM] aspect ratio: 16:9 (1.778)
--[Information] [10/2/2020 6:16:02 PM] color space: I420
--[Information] [10/2/2020 6:16:02 PM] Job command line: "C:\Users\Desktop\MEGUI 64\tools\x264\x264.exe" --crf 18 --deblock 1:1 --bframes 2 --b-adapt 2 --qpmin 10 --qpmax 51 --vbv-maxrate 25000 --merange 32 --me umh --direct auto --subme 9 --partitions all --trellis 2 --sar 1:1 --frames 32642 --output "C:\Users\Desktop\Encoding Videos\Jade HDTV 1080i X264 2Audio-CHDHKTV.mkv - Copy.264" "C:\Users\Desktop\Encoding Videos\Jade HDTV 1080i X264 2Audio-CHDHKTV.mkv - Copy.avs"
--[Information] [10/2/2020 6:16:02 PM] Process started
--[Information] [10/2/2020 6:16:02 PM] Standard output stream
--[Information] [10/2/2020 6:16:02 PM] Standard error stream
---[Information] [10/2/2020 6:16:22 PM] avs [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
---[Warning] [10/2/2020 6:16:22 PM] x264 [warning]: VBV maxrate specified, but no bufsize, ignored
---[Information] [10/2/2020 6:16:22 PM] x264 [info]: using SAR=1/1
---[Information] [10/2/2020 6:16:22 PM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
---[Information] [10/2/2020 6:16:22 PM] x264 [info]: profile Progressive High, level 3.1, 4:2:0, 8-bit
--[Error] [10/2/2020 6:16:34 PM] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)
--[Information] [10/2/2020 6:16:34 PM] Job completed


it just keeps saying status access violation. What is happening?

[real.finder]

it just keeps saying status access violation. What is happening?

don't know, it didn't say from where that access violation come, try another encoding tool or try play the .avs script with mpc and see

[StainlessS]

How do I split my encode and this is very interesting and I am a noob and hope u could show me. Thx.


MakeMultiPartScripts
Two Functions to processes avs script in multiple parts.

MakeMultiPartScripts:- https://forum.doom9.org/showthread.php?t=176386&highlight=MakeMultiPartScripts

[LeXXuz]

real.finder would it be possible to modify dfttestMC to work with this fork of dfttest:
https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest

I couldn't get it to work. They replaced the booleans for Y,U,V planes with integers and replaces sstring with a parameter called slocation.

I did some speed comparisons between dfttest 1.9.6 and the neo-dfttest fork and the latter was about 10-15% faster on my machine.

May not sound much, but on a usual 24h encode it shapes off at least 2-3 hours of encoding time. :)

[real.finder]

real.finder would it be possible to modify dfttestMC to work with this fork of dfttest:
https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest

I couldn't get it to work. They replaced the booleans for Y,U,V planes with integers and replaces sstring with a parameter called slocation.

I did some speed comparisons between dfttest 1.9.6 and the neo-dfttest fork and the latter was about 10-15% faster on my machine.

May not sound much, but on a usual 24h encode it shapes off at least 2-3 hours of encoding time. :)

try https://github.com/realfinder/AVS-Stuff/raw/Community/avs%202.5%20and%20up/dfttestMC_and_MC_things.avsi when use it without lsb it will try with neo_dfttest and if it not work (not loaded) it will use old dfttest, so for testing temporarily (permanent in case you don't have any script use old dfttest or you don't use lsb) remove dfttest from autoload plugins folder and see if it work fine then put back dfttest if there still some script need it or you use lsb

but you need to use this neo_dfttest http://www.solidfiles.com/v/xZn85B3knMGAy for now since it base on uptodate source, see here https://forum.doom9.org/showthread.php?p=1923086#post1923086

and keep in mind there seems bug in neo_dfttest as Dogway said https://forum.doom9.org/showthread.php?p=1920010#post1920010 so if it bother you remove neo_dfttest from autoload plugins and dfttestMC will use the old dfttest

[LeXXuz]

:eek: Thank you very much real.finder! :)
Can't wait to give this a try when I'm back home. :thanks:

[LeXXuz]

Up and running. :D

But I must have made some kind of mistake.

If I understood your post correctly all I have to do with your new "dfttestMC_and_MC_things.avsi" script is either load dfttest or neo-dfttest whichever I choose to use, right?

It works with both plugins so far. So I assume your script takes care of the different syntaxes between dfttest and neo-dfttest?

I did a comparison with both plugins and this command line:
dfttestMC(Y=true, U=true, V=true, sstring="0.0:64 0.05:0 0.1:16 0.2:24 0.3:32 0.4:48 1.0:64", MC=3, dither=0)

See this screenshot:
https://abload.de/thumb/screenshot2020-10-041yvjbg.png (https://abload.de/image.php?img=screenshot2020-10-041yvjbg.png)
https://abload.de/image.php?img=screenshot2020-10-041yvjbg.png

The left one is with dfttest, the right one with neo-dfttest you provided in your post.

They file gets much smaller with neo-dfttest which makes me assume that it may not be using my sstring but falling back to a default sigma-value instead?

[real.finder]

Up and running. :D

But I must have made some kind of mistake.

If I understood your post correctly all I have to do with your new "dfttestMC_and_MC_things.avsi" script is either load dfttest or neo-dfttest whichever I choose to use, right?

It works with both plugins so far. So I assume your script takes care of the different syntaxes between dfttest and neo-dfttest?


yes and yes (edit: there were bug in alpha and a: I just fixed)

I did a comparison with both plugins and this command line:
dfttestMC(Y=true, U=true, V=true, sstring="0.0:64 0.05:0 0.1:16 0.2:24 0.3:32 0.4:48 1.0:64", MC=3, dither=0)

See this screenshot:
https://abload.de/thumb/screenshot2020-10-041yvjbg.png (https://abload.de/image.php?img=screenshot2020-10-041yvjbg.png)
https://abload.de/image.php?img=screenshot2020-10-041yvjbg.png

The left one is with dfttest, the right one with neo-dfttest you provided in your post.

They file gets much smaller with neo-dfttest which makes me assume that it may not be using my sstring but falling back to a default sigma-value instead?

don't know, maybe it's bug in neo one? try with more tests and see

[LeXXuz]

Well I couldn't solve this for now and in the other thread noone seems to have an idea either. All I know it's not your script, the difference also appears by comparing dfttest with neo_dfttest directly. :)

I also noticed with neo-dfttest & dfttest that it seems to denoise darker areas much stronger than brighter ones. I don't know if this is by design, I never noticed this before. Just now after trying to denoise some very old and grainy movies from the 1930's a little.

Right now I'm fiddling around a little with LSFmod and a custom denoiser for the preblur option. Does LimitedSharpen work in all planes or just luma? I already wanted to ask that in it's own threads, but those are almost ancient.

[real.finder]

it's luma only at least for now

[LeXXuz]

Ah thanks. That's fine. Was just asking so a denoiser used with the preblur-option only has to work in the luma plane as well. That saves some cpu time. :)

[jeffk]

Hi, is there any way to use FixChromaBleedingMod on a 64bits pipeline ?

I'm now using ChromaShiftSP (http://avisynth.nl/images/ChromaShiftSP.avsi)(since regular ChromaShift is 32bits only) but i'm not sure if this is optimal.

Thanks !

[real.finder]

Hi, is there any way to use FixChromaBleedingMod on a 64bits pipeline ?

I'm now using ChromaShiftSP (http://avisynth.nl/images/ChromaShiftSP.avsi)(since regular ChromaShift is 32bits only) but i'm not sure if this is optimal.

Thanks !

you can try this one https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/FixChromaBleedingMod_.avsi

[jeffk]

you can try this one https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/FixChromaBleedingMod_.avsi

Thanks ! I used to need -8 on X with ChromaShiftSP now I need to use -4, I guess the maths are different with ChromaShiftSP2 (used in FixChromaBleedingMod)

[real.finder]

Thanks ! I used to need -8 on X with ChromaShiftSP now I need to use -4, I guess the maths are different with ChromaShiftSP2 (used in FixChromaBleedingMod)

I think it's better to report that to Asd-g here https://github.com/Asd-g/AviSynthPlus-Scripts/issues

[jeffk]

Oh sorry I was sure that FixChromaBleedingMod was one of your creation when I posted, my bad.

[real.finder]

Oh sorry I was sure that FixChromaBleedingMod was one of your creation when I posted, my bad.

it was, but the update one by Asd-g is not

[LigH]

Seems that one calculates in Luma units and the other in Chroma units, hence half the number for YUV 4:2:x chroma subsampling... just a guess.

[real.finder]

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P10")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")
Working

KNLMeansCL has problems with 10 bit clip https://github.com/Khanattila/KNLMeansCL/issues/42#issuecomment-469839637

I saw there is a workaround setting YUV, is it possible to create a script variant for that specific case, as all the H.265 HDR material out there is 10 bit?

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended

Thanks man!

So if the source is 444, SMDegrain should work?

yes ;)


Just a question arise to my mind: Hi10P is 10 bit. You tell me to use 16 bit BUT at the end I have to dither to go back to 10 bit again to encode as proper format. Isn't better to find a way to stay in 10 bit with no dithering at the end?

more bits = better :)

anyway you can chose another prefilter other than 4 :) or ask KNLMeansCL developer to make it work with grayscale in any bit depth (seems he only against 420 with 10 bit which is not being used in SMDegrain)

Yes unless the standard for UHD is 10bit and you need to dither at the end :p

That's why I was asking for a solution to have 10 bit chain :D

thanks to pinterf, KNLMeansCL soon will work with these cases

test build for now https://drive.google.com/file/d/1Yi8_CbWH-4kHu83zUjfyrV_cO9fX7K3u/view?usp=sharing (it's not final version as pinterf said, for testing only)

[tormento]

thanks to pinterf, KNLMeansCL soon will work with these cases
Could you introduce some presets in SMDegrain to work with 8 bit, 10 bit and HDR arbitrary input/output combination? I.e. input 8 bit -> output 10 bit, input 10 bit -> output 8 bit, etc.

[real.finder]

Could you introduce some presets in SMDegrain to work with 8 bit, 10 bit and HDR arbitrary input/output combination? I.e. input 8 bit -> output 10 bit, input 10 bit -> output 8 bit, etc.

you can only do input 8 bit -> output 16 bit with n16_out since it supported in mvtools, others I think there are no benefit from them (pinterf think same (https://forum.doom9.org/showthread.php?p=1835712#post1835712))

in any case you can always use convertbits() to do these (like input 8 bit -> output 10 bit) at the cost of some speed losing

[PoeBear]

Deblock_QED_MT2 seems to crash 3.6.1 (and 3.6.2-test6). Works fine in 3.5.1

Any ideas what could be tweaked in the script to get it working again?

[real.finder]

Deblock_QED_MT2 seems to crash 3.6.1 (and 3.6.2-test6). Works fine in 3.5.1

Any ideas what could be tweaked in the script to get it working again?

update the used plugins

[PoeBear]

update the used plugins

Doh! *facepalm*

DCTFilter (https://github.com/Asd-g/DCTFilter/releases) was my culprit :rolleyes:

[hello_hello]

real.finder,
Using the latest neo_dfttest (r7) here (https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest), despite the documentation, this produces an error.
neo_dfttest(fft_threads=2)
"neo_dfttest does not have a named argument fft_threads"
Therefore your sneo_dfttest function can only use dfttest. Unless it's an oddity specific to the XP version. I haven't tried Win7 yet.

And I know it's not your plugin, but is neo_dfttest normally slower than dfttest, or is that an XP thing? I haven't played with it on it's own much yet, but it's obvious it's output differs from dfttest quite a bit, so I'm wondering if that makes supporting it for QTGMC a good idea. neo_fft3d is also slower than FFT3DFilter. At least on my old XP PC.

Cheers.

[kedautinh12]

Please use this (compile by real.finder) have ncpu
https://forum.doom9.org/showpost.php?p=1923091&postcount=153

[real.finder]

real.finder,
Using the latest neo_dfttest (r7) here (https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest), despite the documentation, this produces an error.
neo_dfttest(fft_threads=2)
"neo_dfttest does not have a named argument fft_threads"
Therefore your sneo_dfttest function can only use dfttest. Unless it's an oddity specific to the XP version. I haven't tried Win7 yet.

And I know it's not your plugin, but is neo_dfttest normally slower than dfttest, or is that an XP thing? I haven't played with it on it's own much yet, but it's obvious it's output differs from dfttest quite a bit, so I'm wondering if that makes supporting it for QTGMC a good idea. neo_fft3d is also slower than FFT3DFilter. At least on my old XP PC.

Cheers.

Except minideen and neo_Vague_Denoiser, I don't recommend use neo_ things for now, since at least neo_fft3d and neo_f3kdb both has bugs that not fixed yet, neo_dfttest may has bug too since there are output differs than dfttest

Regarding the speed, some people say neo_ is faster, IIRC msg7086 (MeteorRain) remove sse2 code and use sse as minimum so maybe this why is slower in your case

[hello_hello]

Please use this (compile by real.finder) have ncpu
https://forum.doom9.org/showpost.php?p=1923091&postcount=153

I assume real.finder removed the ncpu argument from sneo_dfttest() in his latest shared functions collection (v1.143), but the fft_threads argument doesn't cause a problem with the version of neo_dfttest you linked to.

I think I'll take real.finder's advice and stick with the standard versions for the moment though.

[hello_hello]

real.finder,
Just a quick question if I may....

For functions/plugins that don't like YUY2, when it's stacked 16 bit, is there any reason not to simply convert to YV16 with Avisynth? This sort of thing:

ConvertToYUY2()
Dither_convert_8_to_16
ConvertToYV16()
Some_Planar_Only_Filter_That Supports_LSB()
DitherPost()
ConvertToYUY2()

It's just that I noticed your Dither Luma Rebuild function converts using the old Planar2Interleaved hack first.

Planar2Interleaved(uv==1)
Dither_YUY2toPlanar16()

or for AVisynth 2.6

Planar2Interleaved(uv==1)
ConvertToYV16()

I'm obviously missing something, but could you explain why that is for me?

Cheers.

[real.finder]

real.finder,
Just a quick question if I may....

For functions/plugins that don't like YUY2, when it's stacked 16 bit, is there any reason not to simply convert to YV16 with Avisynth? This sort of thing:

ConvertToYUY2()
Dither_convert_8_to_16
ConvertToYV16()
Some_Planar_Only_Filter_That Supports_LSB()
DitherPost()
ConvertToYUY2()

It's just that I noticed your Dither Luma Rebuild function converts using the old Planar2Interleaved hack first.

Planar2Interleaved(uv==1)
Dither_YUY2toPlanar16()

or for AVisynth 2.6

Planar2Interleaved(uv==1)
ConvertToYV16()

I'm obviously missing something, but could you explain why that is for me?

Cheers.

because Dither Luma Rebuild need Special hacked YUY2 that called Planar YUY2

[hello_hello]

Thanks for the explanation. I might have to read it again later to make sure I absorbed it all. :)

Now I've looked again... I see I misread one of the functions. I thought it was doing this:

Interleaved2Planar(uv==1)
Dither_YUY2toPlanar16()

Instead of Planar2Interleaved, so now it makes more sense.

I've spent a while perusing some of your functions, mainly trying to understand more about QTGMC, and often it calls one of your shared functions, which call other functions and plugins and so on.... so trying to follow the flow can be tricky... and I'm easily confused.

Cheers.

[Tempter57]

real.finder
Happy new year !!! :)
Adjustment of script YAHRmod.avsi is necessary. Additional functions EMask_dhh, DR_Radius_dhh, Camembert_dhh, GreyCenteredToMask_dhh and FastLineDarkenMOD3_dhh are necessary for function YAHR3 (). Earlier specified functions were a part of function DehaloHmod.avsi. Now in a new wording DehaloHmod.avsi the given functions miss :(

[real.finder]

real.finder
Happy new year !!! :)
Adjustment of script YAHRmod.avsi is necessary. Additional functions EMask_dhh, DR_Radius_dhh, Camembert_dhh, GreyCenteredToMask_dhh and FastLineDarkenMOD3_dhh are necessary for function YAHR3 (). Earlier specified functions were a part of function DehaloHmod.avsi. Now in a new wording DehaloHmod.avsi the given functions miss :(
Happy new year
now they are in Zs_RF_Shared.avsi and FastLineDarkMOD2.avsi, DehaloHmod.avsi still needed too

[real.finder]

Seems that one calculates in Luma units and the other in Chroma units, hence half the number for YUV 4:2:x chroma subsampling... just a guess.

that true, I did update it in my git

[Tempter57]

Happy new year
now they are in Zs_RF_Shared.avsi and FastLineDarkMOD2.avsi, DehaloHmod.avsi still needed too
No function
Function DR_Radius_dhh(clip i, int dr_rad, int count)
{
return count > dr_rad ? i : DR_Radius_dhh(i.mt_expand(), dr_rad, count+1)
}

[real.finder]

do you have all scripts updated?

DR_Radius_dhh is removed now and I did made spasses() to did it job inside DeHaloH.avsi

[Tempter57]

do you have all scripts updated?

DR_Radius_dhh is removed now and I did made spasses() to did it job inside DeHaloH.avsi

I am sorry, I have forgotten to update YAHRmod.avsi

[hello_hello]

real.finder,
it's quite a process making sure all scripts are up to date, given none of them in the list here (https://github.com/realfinder/AVS-Stuff/tree/master/avs%202.5%20and%20up) have version numbers, so you're forced to open and check the version number of each one individually.
Would it be possible to have a readme file containing the latest version number for each script?

Also, a description at the top of each script explaining what it does might be nice. sync_tools for example. I can see it but I have no idea what it's for.

Anyway, after reverting Zs_RF_Shared 1.143 back to version 1.141, as that seems to have happened, and updating DFMDeRainbow, I'm still getting the following error message for a YV12 clip.

deen need a YV12 input
Zs_RF_Shared.avsi, line 339
Zs_RF_Shared.avsi, line 339
DFMDeRainbow.avsi, line 74

Thanks for all the hard work though!

[real.finder]

real.finder,
it's quite a process making sure all scripts are up to date, given none of them in the list here (https://github.com/realfinder/AVS-Stuff/tree/master/avs%202.5%20and%20up) have version numbers, so you're forced to open and check the version number of each one individually.
Would it be possible to have a readme file containing the latest version number for each script?

Also, a description at the top of each script explaining what it does might be nice. sync_tools for example. I can see it but I have no idea what it's for.

Anyway, after reverting Zs_RF_Shared 1.143 back to version 1.141, as that seems to have happened, and updating DFMDeRainbow, I'm still getting the following error message for a YV12 clip.

deen need a YV12 input
Zs_RF_Shared.avsi, line 339
Zs_RF_Shared.avsi, line 339
DFMDeRainbow.avsi, line 74

Thanks for all the hard work though!

this dosn't help you?
https://i.postimg.cc/qB3MsqMK/Untitled.png (https://postimages.org/)
or you use mobile to download? so you don't see it

anyway, for DFMDeRainbow in avs 2.6 or plus you need minideen https://github.com/HomeOfAviSynthPlusEvolution/MiniDeen/releases

[hello_hello]

this dosn't help you?
or you use mobile to download? so you don't see it

I saw it until recently, and at least it's a guide if you have an idea how long it's been since you've updated scripts, but yesterday all I saw was this.

https://i.postimg.cc/PfBSFXsY/github.jpg

I thought it was some glitch on the site, as the main page displays normally.

https://i.postimg.cc/76qkz3XP/github2.jpg

Maybe it's because I'm running older browsers on XP. I've tried Firefox, New Moon, SlimJet and Advanced Chrome.
Still... a readme with a list of version numbers would be nice.

anyway, for DFMDeRainbow in avs 2.6 or plus you need minideen https://github.com/HomeOfAviSynthPlusEvolution/MiniDeen/releases

Ahh... the requirements at the top of the script only list Deen. That's better. Thanks.

[real.finder]

I saw it until recently, and at least it's a guide if you have an idea how long it's been since you've updated scripts, but yesterday all I saw was this.

https://i.postimg.cc/PfBSFXsY/github.jpg

I thought it was some glitch on the site, as the main page displays normally.

https://i.postimg.cc/76qkz3XP/github2.jpg

Maybe it's because I'm running older browsers on XP. I've tried Firefox, New Moon, SlimJet and Advanced Chrome.
Still... a readme with a list of version numbers would be nice.

maybe some day, since I am not good in English and also kinda lazy to do these things, and as always, anyone can help in github with Pull request :)


Ahh... the requirements at the top of the script only list Deen. That's better. Thanks.

usually I don't update the old description in the scripts (laziness, also cuz of my English)

[LigH]

Oh, yes, github messed its GUI since Microsoft took it, it requires some very recent JavaScript features. Pale Moon would support them, but github doesn't recognize it so it looks the same there, only recent Firefox and Chrome (incl. Edge) display it well.

[VoodooFX]

...only recent Firefox and Chrome (incl. Edge) display it well.
This one can help -> GitHub Web Components Polyfill (https://github.com/JustOff/github-wc-polyfill) (multiprocess (e10s) must be disabled).

[hello_hello]

This one can help -> GitHub Web Components Polyfill (https://github.com/JustOff/github-wc-polyfill) (multiprocess (e10s) must be disabled).

I tried it with my old version of Pale Moon / New Moon but it refused to install because it's not compatible.
So I changed the xpi extension to zip, unzipped it, opened install.rdf and changed all the minimum version numbers to something really low, zipped it up again and changed the extension back to xpi.

On the plus side, I can see the missing text, and it changes to "link color" when I hover the cursor, but....
Proving every silver lining has a cloud, my left mouse button won't open them. I can middle click, I can pretend I'm using IE6 again and right click to open in a new window/tab, I can drag them onto the address bar and they'll open... but no left mouse clicky. Still, it's better than not seeing them at all.

Edit: It turns out if I enable uBlock Origin on github I get to left click on the links. When uBlock Origin is disabled completely for github, I can't left click to open them. I've no idea how that works.

Cheers.

https://i.postimg.cc/tC80XMrW/git.jpg

[LigH]

This one can help -> GitHub Web Components Polyfill (https://github.com/JustOff/github-wc-polyfill) (multiprocess (e10s) must be disabled).

:cool: Works in Pale Moon as well as in Seamonkey

[VoodooFX]

:cool: Works in Pale Moon as well as in Seamonkey

This one works for various websites and multiprocess -> Polly (https://github.com/zakius/Polly), but it loads for every site and sometimes can crash tab.

For Github select:
Use request modification...
Webcomponents-sd
Webcomponents-ce

[tormento]

@real.finder

1) After Pinterf released KNLMeansCL v1.1.1e - 20201112-pfmod, I'd like to know how is the bit depth chain working now, i.e. if you implemented HBD on prefilter=4, when bitdepth > 8.

2) I am starting to play with x265, where we can get 10 bit depth "for free" and I'd like to use SMDegrain with 10 bit precision on 8 bit / 10 bit sources. Is there any advantage on working on 8 bit source with 10 bit precision, i.e. less banding when denoising?

3) Is it enough to use a ConvertBits(10) after source filter on AVS+ or is there any other parameter I need to use with SMDegrain?

Thanks. ;)

[real.finder]

1) HBD in SMDegrain is "Input Bit Depth=Output Bit Depth"

2) in x264 with 10bit yes, I didn't use x265 but it should be "yes" too

3) it's enough

[Boulder]

@real.finder

1) After Pinterf released KNLMeansCL v1.1.1e - 20201112-pfmod, I'd like to know how is the bit depth chain working now, i.e. if you implemented HBD on prefilter=4, when bitdepth > 8.

2) I am starting to play with x265, where we can get 10 bit depth "for free" and I'd like to use SMDegrain with 10 bit precision on 8 bit / 10 bit sources. Is there any advantage on working on 8 bit source with 10 bit precision, i.e. less banding when denoising?

3) Is it enough to use a ConvertBits(10) after source filter on AVS+ or is there any other parameter I need to use with SMDegrain?

Thanks. ;)
It's best to convert to 16 bits and do all the processing at that depth. Then in x265, parameters --profile main10 --input-depth 16 --dither will make sure that you get proper conversion to 10 bits in the final result.

pinterf's MVTools has the possibility to use MAnalyse and MRecalculate at a lower bitdepth and do all the processing at a higher bitdepth. In this case it would mean creating the vectors at 8 bits and do all the denoising etc. at 16 bits which makes things quite a bit faster. Is this utilized in the SMDegrain port?

[tormento]

It's best to convert to 16 bits
Too slow IMHO.

[Boulder]

Too slow IMHO.

How much is the difference between 10 and 16 bits? That's exactly what pinterf's scaling attacks since motion analysis tends to be the slowest part of the whole thing. Doing it in 8 bits gives you a nice boost without actually sacrificing quality.

And I'm not exactly sure if it even makes a difference whether you feed 8, 10 or 16 bit data into those GPU based functions. The GPU may well convert it to something else like a 32-bit float and then back to your source format.

[tormento]

@real.finder

Is it better to use:

DGSource()
ConvertBits(16)
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)

or

DGSource()
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true, n16_out=true)

[real.finder]

Is this utilized in the SMDegrain port?

you can by using prefilter as clip

[real.finder]

@real.finder

Is it better to use:

DGSource()
ConvertBits(16)
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)

or

DGSource()
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true, n16_out=true)

pinterf already answer this https://forum.doom9.org/showthread.php?p=1855351#post1855351

but anyway, 1st one is slower but maybe give a bit better output

[tormento]

How much is the difference between 10 and 16 bits?
SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_50 colore venuto dallo spazio, Il\colore.dgi",ct=140,cb=140,cl=0,cr=0)
SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Prefetch(6)

x265 slow 4.32 fps

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_50 colore venuto dallo spazio, Il\colore.dgi",ct=140,cb=140,cl=0,cr=0)
ConvertBits(10)
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Prefetch(6)

x265 slow 4.10 fps

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_50 colore venuto dallo spazio, Il\colore.dgi",ct=140,cb=140,cl=0,cr=0)
CompTest24(1)
ConvertBits(16)
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
Prefetch(6)

x265 slow --input-depth 16 --dither 4.01 fps

Any optimization is welcome :)

[real.finder]

Any optimization is welcome :)


#8bit source input
ConvertBits(10).SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0), truemotion=true, plane=4, chroma=true)


or if you have 10bit source


#HBD source input
SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=ConvertBits(8).SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0), truemotion=true, plane=4, chroma=true)

[tormento]

#8bit source input
Please explain me why explicitely define prefilter is faster than implicitely use prefilter=4.

[tormento]

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_50 colore venuto dallo spazio, Il\colore.dgi",ct=140,cb=140,cl=0,cr=0)
CompTest24(1)
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true, n16_out=true)
Prefetch(6)

x265 slow --input-depth 16 --dither 4.43 fps

Perhaps the best compromise yet.

[real.finder]

Please explain me why explicitely define prefilter is faster than implicitely use prefilter=4.

in the code I post it will be 8bit for prefilter, and it will be faster as Boulder told you

Doing it in 8 bits gives you a nice boost without actually sacrificing quality.

[tormento]

in the code I post it will be 8bit for prefilter, and it will be faster as Boulder told you
The bold part is the one I need clarification about:

ConvertBits(10).SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0), truemotion=true, plane=4, chroma=true)

[tormento]

SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=ConvertBits(8).SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0), truemotion=true, plane=4, chroma=true)

SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=ConvertBits(8).SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0),, truemotion=true, plane=4, chroma=true, n16_out=true)
actually turned out to be slower than
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true, n16_out=true)
4.27 fps vs 4.43.

P.S: n16_out=true doesn't need to have ConvertBit(16) in front of SMDegrain, does it?

[real.finder]

The bold part is the one I need clarification about:

ConvertBits(10).SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0), truemotion=true, plane=4, chroma=true)

as the name said it's just prefilter function of SMDegrain

SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=ConvertBits(8).SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0),, truemotion=true, plane=4, chroma=true, n16_out=true)
actually turned out to be slower than
SMDegrain (tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true, n16_out=true)
4.27 fps vs 4.43.

they should be the same in that case

edit: try add ,device_type="GPU" to SMDegrain_prefilters

anyway there are no point of using n16_out with external PreFilter like this


P.S: n16_out=true doesn't need to have ConvertBit(16) in front of SMDegrain, does it?

n16_out is like the lsb_out but a bit faster and only work with 8bit input

[tormento]

as the name said it's just prefilter function of SMDegrain
Ok, but why to use it instead of prefilter=4 in the 8 bit source case?
anyway there are no point of using n16_out with external PreFilter like this
Ok, why? I thought n16_out is used to output 16 bit depth video. Am I wrong? What should I use to deliver a 16 bit video out from *ANY* input source?
n16_out is like the lsb_out but a bit faster and only work with 8bit input
So if I have a 10/12 bit input, have I to ConvertBits(16) before using SMDegrain?

[real.finder]

Ok, but why to use it instead of prefilter=4 in the 8 bit source case?


who say use it in 8 bit source? you asked for speed optimization and I give you some, no more no less

Ok, why? I thought n16_out is used to output 16 bit depth video. Am I wrong? What should I use to deliver a 16 bit video out from *ANY* input source?

it is but it only work for 8bit input, see here https://forum.doom9.org/showthread.php?p=1837161&highlight=n16#post1837161

if you need 16bit from 10-14 bits then use ConvertBits(16) before SMDegrain

So if I have a 10/12 bit input, have I to ConvertBits(16) before using SMDegrain?

it's up to you, SMDegrain can work with those as they are (input depth = output depth)

[tormento]

if you need 16bit from 10-14 bits then use ConvertBits(16) before SMDegrain
What will happen if I feed 10 bit source without ConvertBits(16) but with n16_out?

[real.finder]

What will happen if I feed 10 bit source without ConvertBits(16) but with n16_out?

you should get an error message

[tormento]

Ok, the results. Bit long and tedious job but it will save me some encoding time.

Number of frames: 4560
Length (hh:mm:ss.ms): 00:03:10.190
Frame width: 1920
Frame height: 1040
Framerate: 23.976 (24000/1001)
Colorspace: YV12
Base script:
SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\2_37 padrino III coda, Il - La morte di Michael Corleone\coda.dgi",ct=20,cb=20,cl=0,cr=0)
(*)
Prefetch(6)
where (*) are the differences that I will list below.
[1] SMDegrain (tr=6, thSAD=600, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[2] ConvertBits(10).SMDegrain (tr=6, thSAD=600, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[3] ConvertBits(12).SMDegrain (tr=6, thSAD=600, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[4] ConvertBits(16).SMDegrain (tr=6, thSAD=600, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[5] SMDegrain (tr=6, thSAD=600, refinemotion=false, n16_out=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
AVSMeter64 results:
FPS min | max | average
[1] 1.238 | 46512 | 10.96
[2] 1.222 | 256.8 | 7.679
[3] 1.174 | 46083 | 6.170
[4] 1.084 | 140845 | 6.210
[5] 1.272 | 35461 | 10.97
x265 encoding:
[1] x265_x64.exe -D 10 --crf 22.0 --preset slow --profile main10 --level 4.1 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --aq-mode 2 --sar 1:1
[2] same as [1]
[3] same as [1] --input-depth 12 --dither
[4] same as [1] --input-depth 16 --dither
[5] same as [1] --input-depth 16 --dither
x265 results:
[1] 3.51 fps, 1734.92 kb/s, Avg QP:25.95
[2] 3.23 fps, 1713.39 kb/s, Avg QP:25.92
[3] 2.86 fps, 1713.58 kb/s, Avg QP:25.91
[4] 2.75 fps, 1716.02 kb/s, Avg QP:25.91
[5] 3.55 fps, 1714.94 kb/s, Avg QP:25.91

Can't understand the speedup with out16.

[real.finder]

Ok, the results. Bit long and tedious job but it will save me some encoding time.

Number of frames: 4560
Length (hh:mm:ss.ms): 00:03:10.190
Frame width: 1920
Frame height: 1040
Framerate: 23.976 (24000/1001)
Colorspace: YV12
Base script:
SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\2_37 padrino III coda, Il - La morte di Michael Corleone\coda.dgi",ct=20,cb=20,cl=0,cr=0)
(*)
Prefetch(6)
where (*) are the differences that I will list below.
[1] SMDegrain (tr=6, thSAD=600, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[2] ConvertBits(10).SMDegrain (tr=6, thSAD=600, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[3] ConvertBits(12).SMDegrain (tr=6, thSAD=600, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[4] ConvertBits(16).SMDegrain (tr=6, thSAD=600, refinemotion=false, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
[5] SMDegrain (tr=6, thSAD=600, refinemotion=false, n16_out=true, mode=0, contrasharp=false, PreFilter=4, truemotion=true, plane=4, chroma=true)
AVSMeter64 results:
FPS min | max | average
[1] 1.238 | 46512 | 10.96
[2] 1.222 | 256.8 | 7.679
[3] 1.174 | 46083 | 6.170
[4] 1.084 | 140845 | 6.210
[5] 1.272 | 35461 | 10.97
x265 encoding:
[1] x265_x64.exe -D 10 --crf 22.0 --preset slow --profile main10 --level 4.1 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --aq-mode 2 --sar 1:1
[2] same as [1]
[3] same as [1] --input-depth 12 --dither
[4] same as [1] --input-depth 16 --dither
[5] same as [1] --input-depth 16 --dither
x265 results:
[1] 3.51 fps, 1734.92 kb/s, Avg QP:25.95
[2] 3.23 fps, 1713.39 kb/s, Avg QP:25.92
[3] 2.86 fps, 1713.58 kb/s, Avg QP:25.91
[4] 2.75 fps, 1716.02 kb/s, Avg QP:25.91
[5] 3.55 fps, 1714.94 kb/s, Avg QP:25.91

Can't understand the speedup with out16.

see here https://forum.doom9.org/showthread.php?p=1835681&highlight=out16#post1835681

also you can speed 2-4 as Boulder told you and I post an example code to do that

[tormento]

also you can speed 2-4 as Boulder told you and I post an example code to do that
That is what I am doing, i.e. process everything in 16 bit and dither in x265.

He asked you:
Is this utilized in the SMDegrain port?

[real.finder]

He asked you:

edit: I mean that part of his post

pinterf's MVTools has the possibility to use MAnalyse and MRecalculate at a lower bitdepth and do all the processing at a higher bitdepth. In this case it would mean creating the vectors at 8 bits and do all the denoising etc. at 16 bits which makes things quite a bit faster. Is this utilized in the SMDegrain port?

also
motion analysis tends to be the slowest part of the whole thing. Doing it in 8 bits gives you a nice boost without actually sacrificing quality.

and I answer

you can by using prefilter as clip

then I give how to do that for you


#8bit source input
ConvertBits(XX).SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0,device_type="GPU"), truemotion=true, plane=4, chroma=true)


or if you have HBD source already


#HBD source input
SMDegrain(tr=4, thSAD=500, refinemotion=false, mode=0, contrasharp=false, PreFilter=ConvertBits(8).SMDegrain_prefilters(prefilter=4,a=1,d=1,h=7.0,device_type="GPU"), truemotion=true, plane=4, chroma=true)


(same old post but with small edit)

[Boulder]

For HDR sources, I recommend ConvertBits(10) instead of ConvertBits(8) for prefilter as the source has information in the whole 10-bit range. At least DGSource will output 16-bit video in such cases (it's what the card just does).

[real.finder]

For HDR sources, I recommend ConvertBits(10) instead of ConvertBits(8) for prefilter as the source has information in the whole 10-bit range. At least DGSource will output 16-bit video in such cases (it's what the card just does).

prefilter it's just for Motion Analyse even if your source is 16bit you can use 8bit without loosing quality, but if you care that much about HBD and you have fast CPU and you don't care about time then you can Motion Analyse in HBD and maybe you will get some better Motion Analyse from that in the end

anyway, I don't know about DGSource, but I think LSMASHSource can do HW decode for 10bit without convert it to 16bit

[tormento]

same old post but with small edit
The code you are giving me does SMDegrain on 8 bit source giving out 8 bit video. I need 10 bit output (or higher) to feed 10 bit x265 with.

[real.finder]

The code you are giving me does SMDegrain on 8 bit source giving out 8 bit video. I need 10 bit output (or higher) to feed 10 bit x265 with.

https://i.postimg.cc/QdqyXd2F/Annotation-2021-02-02-210114.png (https://postimages.org/)

[tormento]

https://i.postimg.cc/QdqyXd2F/Annotation-2021-02-02-210114.png (https://postimages.org/)


I lost the initial conversion :)

I tried some posts ago and it was slower than regular pre=4

[real.finder]

I lost the initial conversion :)

I tried some posts ago and it was slower than regular pre=4

you tried vs n16 things, of course n16 and even n16_out are the fastest high bit method

edit: also it was without device_type="GPU"

I said for your case above


AVSMeter64 results:
FPS min | max | average
[1] 1.238 | 46512 | 10.96
[2] 1.222 | 256.8 | 7.679
[3] 1.174 | 46083 | 6.170
[4] 1.084 | 140845 | 6.210
[5] 1.272 | 35461 | 10.97


for 2, 3 and 4 not for 1 and 5 which use n16 things

[tormento]

Launching AVSMeter_x64 -avsinfo, I am getting:

Function duplicates:

"undefined" : "[InternalFunction]"
"Undefined" : "D:\Programmi\Media\AviSynth+\plugins64\Zs_RF_Shared-1.143~realfinder.avsi"

Why?

[LigH]

AFAIK, nothing to worry hard about...

[real.finder]

Launching AVSMeter_x64 -avsinfo, I am getting:

Function duplicates:

"undefined" : "[InternalFunction]"
"Undefined" : "D:\Programmi\Media\AviSynth+\plugins64\Zs_RF_Shared-1.143~realfinder.avsi"

Why?

AFAIK, nothing to worry hard about...

yes https://forum.doom9.org/showthread.php?p=1920737&highlight=Undefined#post1920737

[tormento]

yes
As it’s the second time that you get asked, why not changing the name? :)

[StainlessS]

why not changing the name
If I understand you correctly,
Undefined() is new function in v2.60+, not suooported in v2.58 and earlier.
(Older) AvsMeter sees script function Undefined() in R.F.'s script, and even though is not used in R.F. code, flags it as duplicate function,
needs AvsMeter update.
Changing name from Undefined() to something else would not work, it needs to emulate new function in v2.60 for old v2.58 and older.

Update AvsMeter should fix your Duplicate function thing when using Zs_RF_Shared_1.143.avsi.
Latest version AvsMeter is v3.0.7.0:- https://forum.doom9.org/showthread.php?t=174797&highlight=AvsMeter

[tormento]

Latest version AvsMeter is v3.0.7.0
The same I have.

Did you launch x86 or x64 build?

Which version of AVS+ do you run? Here AviSynth+ 3.7.0 (r3382, 3.7, x86_64).

[tormento]

Update AvsMeter should fix your Duplicate function thing when using Zs_RF_Shared_1.143.avsi.
Updated to 3.0.8.0. Warning is still there.

[StainlessS]

No problem for me.


C:\Users\root>avsmeter64 -avsinfo

AVSMeter 3.0.8.0 (x64), (c) Groucho2004, 2012-2021

VersionString: AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 21:36:39 (UTC)
PluginDir2_5 (HKLM, x64): C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plug
ins
PluginDir+ (HKLM, x64): C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plug
ins


[C++ 2.6 Plugins (64 Bit)] [Version, Time stamp]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\AutoLevels.dll [0.12.3.0, 2019-07-18]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\FrameSel.dll [2.20.0.0, 2018-04-20]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\Grunt.dll [1.0.2.0, 2020-04-30]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\RoboCrop.dll [1.12.0.0, 2020-02-07]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\RT_Stats.dll [2.0.13.0, 2020-12-29]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\SysInfo64.dll [0.1.2.5, 2020-05-27]

[Scripts (AVSI)] [Time stamp]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\AvsInit.avsi [2020-06-15]


DebugView output [I use AvsInit() script]

00000181 0.00000000 [224] AvsInit:
00000182 0.00003225 [224] AvsInit: Auto load plugins script ENTRY
00000183 0.00006377 [224] AvsInit:
00000184 0.00433908 [224] AvsInit_ShowInfo:
00000185 0.00437278 [224] AvsInit_ShowInfo: AvsInit_Version = 1.10
00000186 0.00440466 [224] AvsInit_ShowInfo: GScript Available = AVS+
00000187 0.00443619 [224] AvsInit_ShowInfo: RT_Stats Version = 2.00Beta13
00000188 0.00446807 [224] AvsInit_ShowInfo: SysInfo Version = 0.125000
00000189 0.00449995 [224] AvsInit_ShowInfo: SysInfo.dll DIR = C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins
00000190 0.00453220 [224] AvsInit_ShowInfo: VersionString = AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
00000191 0.00456372 [224] AvsInit_ShowInfo: SetMemoryMax = 3055
00000192 0.00459488 [224] AvsInit_ShowInfo: Avisynth Bitness = 64
00000193 0.00463147 [224] AvsInit_ShowInfo: WorkingDir = C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\
00000194 0.00466336 [224] AvsInit_ShowInfo: ProcessName = C:\BIN\AVSMeter64.exe
00000195 0.00469560 [224] AvsInit_ShowInfo: ParentProcessName = cmd.exe
00000196 0.00472676 [224] AvsInit_ShowInfo: OSVersionString = Windows 7 (x64) Service Pack 1.0 (Build 7601)
00000197 0.00475865 [224] AvsInit_ShowInfo: OSVersionNumber = 6.100000
00000198 0.00479017 [224] AvsInit_ShowInfo: OS Bitness = 64
00000199 0.00482169 [224] AvsInit_ShowInfo: CPUName = Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz / Yorkfield (Core 2 Quad) 6M
00000200 0.00485430 [224] AvsInit_ShowInfo: Cores = 04:04 (Phy:Log)
00000201 0.00488582 [224] AvsInit_ShowInfo: CPU Extensions = MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
00000202 0.00493002 [224] AvsInit_ShowInfo: Total Memory = 12221MB
00000203 0.00495756 [224] AvsInit_ShowInfo: Avail Memory = 10364MB'
00000204 0.00498473 [224] AvsInit_ShowInfo: Screen Res = 1280x1024
00000205 0.00501299 [224] AvsInit_ShowInfo: Screen BitsPerPixel = 32
00000206 0.00504125 [224] AvsInit_ShowInfo: Time = Tuesday 09 March 2021 16:53:10[GMT Standard Time]
00000207 0.00506806 [224] AvsInit_ShowInfo: User TEMP Dir = C:\Users\root\AppData\Local\Temp
00000208 0.00509415 [224] AvsInit_ShowInfo: ComSpec = C:\Windows\system32\cmd.exe
00000209 0.00512096 [224] AvsInit_ShowInfo: Computer Name = PLEX-P2
00000210 0.00514777 [224] AvsInit_ShowInfo: User Name = root
00000211 0.00517639 [224] AvsInit_ShowInfo:
00000212 0.02200412 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\AutoContrast.avsi
00000213 0.02331026 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\colors_rgb.avsi
00000214 0.02429322 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\DBSC.avsi
00000215 0.04639009 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\Favc.avsi
00000216 0.04994513 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\FFMS2.avsi
00000217 0.05217011 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\InpaintDelogo.avsi
00000218 0.06014176 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\JohnFPS.avsi
00000219 0.06099501 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\LSFmod_2.187.avsi
00000220 0.06846558 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\MakeLoc.avsi
00000221 0.06918478 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\MCBob_v0.3u8.avsi
00000222 0.07382060 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\McDegrain.avsi
00000223 0.07571478 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\MCTemporalDenoise_1.4.20.avsi
00000224 0.09298018 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\Misc.avsi
00000225 0.09659536 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\QTGMC_3.368s.avsi
00000226 0.11294918 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\RoboSplice.avsi
00000227 0.11980671 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\SelectRanges.avs
00000228 0.12060091 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\SetMTMode.avsi
00000229 0.12518999 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\SMDegrain_3.1.2.109s.avsi
00000230 0.12999320 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\SpotLess.avsi
00000231 0.13092761 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\SubtitleCharacterSet.avsi
00000232 0.13201962 [224] AvsInit_DImport: Importing ... C:\VideoTools\AvisynthRepository\GIMPORT\Zs_RF_Shared_1.143.avsi
00000233 0.16316567 [224] AvsInit_DImport: IMPORTED 21 scripts from 'C:\VideoTools\AvisynthRepository\GIMPORT'
00000234 0.17668185 [224] AvsInit_DImport: IMPORTED 0 scripts from 'C:\VideoTools\AvisynthRepository\AVSPLUS370_x64\plugins\GIMPORT'
00000235 0.19469868 [224] AvsInit_DLoadConditional: STARTING DLL SCAN on C:\VideoTools\AvisynthRepository\MACHINE
00000236 0.19822618 [224] AvsInit_DLoadConditional: dfttest.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000237 0.20083086 [224] AvsInit_DLoadConditional: FFMS2.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000238 0.20214896 [224] AvsInit_DLoadConditional: LSMASHSource.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000239 0.20521379 [224] AvsInit_DLoadConditional: masktools2.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000240 0.20636414 [224] AvsInit_DLoadConditional: MedianBlur2.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000241 0.20861194 [224] AvsInit_DLoadConditional: mvtools2.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000242 0.21005903 [224] AvsInit_DLoadConditional: nnedi3.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000243 0.21164849 [224] AvsInit_DLoadConditional: RemoveDirt.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000244 0.21315320 [224] AvsInit_DLoadConditional: TIVTC.dll LoadPlugin OK from 2_WIN7_0\5_AVS26x64\0_CPP
00000245 0.21525136 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\5_AVS26x64\0_CPP\dfttest.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000246 0.21550824 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\5_AVS26x64\0_CPP\masktools2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000247 0.21576729 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\5_AVS26x64\0_CPP\MedianBlur2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000248 0.21602780 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\5_AVS26x64\0_CPP\mvtools2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000249 0.21628723 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\5_AVS26x64\0_CPP\nnedi3.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000250 0.21654844 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\5_AVS26x64\0_CPP\TIVTC.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000251 0.21819082 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\4_AVS26Stdx64\0_CPP\ffms2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000252 0.21844552 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\4_AVS26Stdx64\0_CPP\masktools2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000253 0.21870820 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\4_AVS26Stdx64\0_CPP\nnedi3.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000254 0.21897016 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\4_AVS26Stdx64\0_CPP\RemoveDirt.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000255 0.22130202 [224] AvsInit_DLoadConditional: DGDecode.dll LoadPlugin OK from 0_XP\3_AVS25x64\0_CPP
00000256 0.22158717 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\3_AVS25x64\0_CPP\ffms2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000257 0.22184876 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\3_AVS25x64\0_CPP\LSMASHSource.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000258 0.22210854 [224] AvsInit_DLoadConditional: !!! Skipping File 0_XP\3_AVS25x64\0_CPP\masktools2.dll, already loaded from 2_WIN7_0\5_AVS26x64\0_CPP
00000259 0.22297338 [224] AvsInit_DLoadConditional: STARTING SCRIPT SCAN on C:\VideoTools\AvisynthRepository\MACHINE
00000260 0.22838238 [224] AvsInit_DLoadConditional: 10 dll's LOADED : 13 dll's SKIPPED : 0 dll's FAILED
00000261 0.22843130 [224] AvsInit_DLoadConditional: 0 scripts LOADED : 0 Scripts SKIPPED : 0 scripts FAILED


EDIT: Arh, wait a minute, R.F. shared library is loaded by AvsInit.avsi [and so maybe not seen by AvsMeter].

[tormento]

No problem for me.
Please try to put Zs_RF_Shared_1.143.avsi in the AVSI folder or one that imports it automatically.

[StainlessS]

Yeah you are right, [ with AvsInit() disabled - and shared lib in plugins]


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\root>avsmeter -avsinfo

AVSMeter 3.0.8.0 (x86), (c) Groucho2004, 2012-2021

VersionString: AviSynth+ 3.7.0 (r3382, 3.7, i386)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 21:32:15 (UTC)
PluginDir2_5 (HKLM, x86): C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins
PluginDir+ (HKLM, x86): C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins


[C++ 2.5 Plugins (32 Bit)] [Version, Time stamp]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\NicAudio.dll [n/a, 2012-08-27]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\SysInfo32.dll [0.1.2.5, 2020-05-27]

[C++ 2.6 Plugins (32 Bit)] [Version, Time stamp]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\AutoLevels.dll [0.12.3.0, 2019-07-18]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\FrameSel.dll [2.20.0.0, 2018-04-20]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\GRunT.dll [1.0.2.0, 2016-12-19]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\RoboCrop.dll [1.12.0.0, 2020-02-07]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\RT_Stats.dll [2.0.13.0, 2020-12-29]

[Scripts (AVSI)] [Time stamp]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\Zs_RF_Shared_1.143.avsi [2021-03-09]

[Uncategorized files] [Time stamp]
C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\AvsInit.avsi_BAK [2020-06-15]



[Plugin errors/warnings]
________________________________________________________________________________


Function duplicates:


"undefined" : "[InternalFunction]"
"Undefined" : "C:\VideoTools\AvisynthRepository\AVSPLUS370_x86\plugins\Zs_RF_Shared_1.143.avsi"

________________________________________________________________________________

[LigH]

Well, AVSMeter works as intended, you just need to understand that a warning is not a reason for panic, just to realize the cause.

[Arx1meD]

real.finder, I have used some scripts from your collection and noticed a strange thing.
In some scripts (for example: YLevels_mt.avsi, FastLineDarkMOD2.avsi, FineDehalo.avsi possibly in others) there is a line:sisavs26 = !(VersionNumber() < 2.60)
As I understand it is needed to determine the version of AviSynth. I checked this for AviSynth+ 3.7.0 and AviSynth 2.6 and sisavs26 gave the same result.
Then I decided to test it on other versions of AviSynth. And here's the result:
BlankClip(240, 800, 50)
Subtitle("VersionNumber: "+String(VersionNumber())+"; VersionString: "+String(VersionString()))
AVS 2.58 -> VersionNumber: 2.580000; VersionString: AviSynth 2.58, build: Dec 22 2008 [08:46:51]
AVS 2.60 -> VersionNumber: 2.600000; VersionString: AviSynth 2.60, build: Mar 31 2015 [16:38:54]
AVS+ r2772 -> VersionNumber: 2.600000; VersionString: AviSynth+ 0.1 (r2772, MT, i386)
AVS+ 3.4.0 -> VersionNumber: 2.600000; VersionString: AviSynth+ 3.4 (r2925, master, i386)
AVS+ 3.5.0 -> VersionNumber: 2.600000; VersionString: AviSynth+ 3.5 (r3043, master, i386)
AVS+ 3.5.1 -> VersionNumber: 2.600000; VersionString: AviSynth+ 3.5 (r3106, 3.5, i386)
AVS+ 3.6.0 -> VersionNumber: 2.600000; VersionString: AviSynth+ 3.6.0 (r3276, 3.6, i386)
AVS+ 3.6.1 -> VersionNumber: 2.600000; VersionString: AviSynth+ 3.6.1 (r3300, 3.6, i386)
AVS+ 3.7.0 -> VersionNumber: 2.600000; VersionString: AviSynth+ 3.7.0 (r3382, 3.7, x86_64)
My question is, is it correct to use VersionNumber() to determine the version?

[real.finder]

real.finder, I have used some scripts from your collection and noticed a strange thing.
In some scripts (for example: YLevels_mt.avsi, FastLineDarkMOD2.avsi, FineDehalo.avsi possibly in others) there is a line:
As I understand it is needed to determine the version of AviSynth. I checked this for AviSynth+ 3.7.0 and AviSynth 2.6 and sisavs26 gave the same result.
Then I decided to test it on other versions of AviSynth. And here's the result:


My question is, is it correct to use VersionNumber () to determine the version?

that because avs+ is based on avs 2.6 so that why it keep VersionNumber() report as 2.6 especially when avs+ start with 0.1 back then

so I did use https://github.com/realfinder/AVS-Stuff/blob/ca5f8f535f741848d94b6e04a1d5c2bcb010efe4/avs%202.5%20and%20up/Zs_RF_Shared.avsi#L1722 for avs+ and in newer avs+ there are IsVersionOrGreater https://github.com/realfinder/UniversalPluginsFolders/blob/5cace5b515523ed5646f62cfe768061e668ad212/plugins64%2B/zz_avsx64p.avsi#L6

[LeXXuz]

real.finder is it possible to modify dfttestMC so Y and U,V planes use different sigma or sstring values?

With the material I'm working on right now I get far more pleasing results with different values for Y and U,V.

So I have to run dfttestMC() twice. Which is much slower than one instance of dfttestMC filtering all three planes.

[real.finder]

real.finder is it possible to modify dfttestMC so Y and U,V planes use different sigma or sstring values?

With the material I'm working on right now I get far more pleasing results with different values for Y and U,V.

So I have to run dfttestMC() twice. Which is much slower than one instance of dfttestMC filtering all three planes.

it can be done but not that easy, and maybe it will not give that speed difference than the 2 call

[LeXXuz]

I understand. Well, if you ever feel bored... :D;)

[real.finder]

I understand. Well, if you ever feel bored... :D;)

try https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi and https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/dfttestMC_and_MC_things.avsi

example
dfttestMC(sigma=0.0,dfttest_params=", chrsigma=1000.0")

[LeXXuz]

Thank you very much. :)

Framerate almost doubled :eek:

But there seems to be a bug. Colours are off now by a certain angle. Cyan became green, red became purple and so on...

https://abload.de/thumb/2021-03-1930ej7a.png (https://abload.de/image.php?img=2021-03-1930ej7a.png)https://abload.de/thumb/2021-03-19279jnl.png (https://abload.de/image.php?img=2021-03-19279jnl.png)

Maybe you can take another look? :o Oh yes, I use neo_dfttest and 16-bit bitdepth if that changes anything.

[LigH]

Brief: Cb becomes equal to Cr, it seems.

[real.finder]

Thank you very much. :)

Framerate almost doubled :eek:

But there seems to be a bug. Colours are off now by a certain angle. Cyan became green, red became purple and so on...

https://abload.de/thumb/2021-03-1930ej7a.png (https://abload.de/image.php?img=2021-03-1930ej7a.png)https://abload.de/thumb/2021-03-19279jnl.png (https://abload.de/image.php?img=2021-03-19279jnl.png)

Maybe you can take another look? :o Oh yes, I use neo_dfttest and 16-bit bitdepth if that changes anything.

it was copy past typo :p fixed in Zs_RF_Shared V1.146

[LeXXuz]

Now it's working fine. Speed still is way higher than running two instances. Awesome!

How do I set sstring for chroma? Is there a 'new' parameter too?

[real.finder]

How do I set sstring for chroma? Is there a 'new' parameter too?

there are string "chrnlocation", string "chrslocation", string "chrssx", string "chrssy", string "chrsst"

in neo style https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest#usage

[LeXXuz]

there are string "chrnlocation", string "chrslocation", string "chrssx", string "chrssy", string "chrsst"

in neo style https://github.com/HomeOfAviSynthPlusEvolution/neo_DFTTest#usage

Ah perfect! Thanks a lot!


EDIT: File size of output differs quite a bit between those two settings:

dfttestMC(Y=true, U=true, V=true, sigma=48, MC=3, dither=0, dfttest_params=", chrsigma=16")
and
dfttestMC(Y=true, U=false, V=false, sigma=48, MC=3, dither=0)
dfttestMC(Y=false, U=true, V=true, sigma=16, MC=3, dither=0)

https://abload.de/img/screenshot2021-03-1910rkzj.png (https://abload.de/image.php?img=screenshot2021-03-1910rkzj.png)

Any idea why this occurs?

[real.finder]

motion Analysis in 2nd call of dfttestMC will not be the same of 1st one cuz it will use denoised input

maybe it will be same if you do it like this

dfttestMC(Y=true, U=false, V=false, sigma=48, MC=3, dither=0).MergeChroma(dfttestMC(Y=false, U=true, V=true, sigma=16, MC=3, dither=0))

or better dfttestMC(sigma=48, MC=3, dither=0).MergeChroma(dfttestMC(sigma=16, MC=3, dither=0))

[LeXXuz]

motion Analysis in 2nd call of dfttestMC will not be the same of 1st one cuz it will use denoised input

So motion analysis will always only be done in Y plane, even if you call dfttestMC to only process chroma planes? Does this mean the "new" variant (with dfttestMC(Y=true, U=true, V=true, sigma=48, MC=3, dither=0, dfttest_params=", chrsigma=16")) would be more precise?


maybe it will be same if you do it like this

dfttestMC(Y=true, U=false, V=false, sigma=48, MC=3, dither=0).MergeChroma(dfttestMC(Y=false, U=true, V=true, sigma=16, MC=3, dither=0))

Thank you. I will give it a try.


or better dfttestMC(sigma=48, MC=3, dither=0).MergeChroma(dfttestMC(sigma=16, MC=3, dither=0))

I don't understand this one actually. :o Wouldn't this process all three planes twice?

[real.finder]

motion analysis will always only be done in Y plane, even if you call dfttestMC to only process chroma planes

motion analysis will always use luma, but there are way to not use chroma in motion analysis

in dfttestMC the motion analysis of using chroma is linked with u and v parameters by default, so I just did update to add chromaMA

so now
dfttestMC(Y=true, U=false, V=false, sigma=48, MC=3, dither=0, chromama=true).MergeChroma(dfttestMC(Y=false, U=true, V=true, sigma=16, MC=3, dither=0))

output should be same as dfttestMC(Y=true, U=true, V=true, sigma=48, MC=3, dither=0, dfttest_params=", chrsigma=16")

[LeXXuz]

Sorry to say it, but the difference in file size is still the same.

I've triple checked everything. I've updated both avsi once more to v2.122 and V1.146 and did another run with your code examples.

with
dfttestMC(Y=true, U=true, V=true, sigma=48, MC=3, dither=0, dfttest_params=", chrsigma=16")

Output is still ~161MB, encoding speed ~11.69 FPS

and with
dfttestMC(Y=true, U=false, V=false, sigma=48, MC=3, dither=0, chromama=true).MergeChroma(dfttestMC(Y=false, U=true, V=true, sigma=16, MC=3, dither=0))
Output is still ~150MB, encoding speed ~6.81 FPS

So the question is, which one is doing the job 'correctly' :confused:

[real.finder]

can you try with sneo_dfttest(sigma=48, chrsigma=16) vs sneo_dfttest(sigma=48).MergeChroma(sneo_dfttest(sigma=16)) ?

[real.finder]

ok, I find many problems with sneo_dfttest, fixed in Zs_RF_Shared V1.147

aside from that there was some compatibility problems with old dfttest since neo_dfttest is based on VS dfttest port which has some default settings changes, now they should be fixed

[LeXXuz]

can you try with sneo_dfttest(sigma=48, chrsigma=16) vs sneo_dfttest(sigma=48).MergeChroma(sneo_dfttest(sigma=16)) ?

Quite close but not identical.

sneo_dfttest(sigma=48, chrsigma=16): 149.835.776 Bytes @ 13.45FPS

sneo_dfttest(sigma=48).MergeChroma(sneo_dfttest(sigma=16)): 149.848.064 Bytes @ 10.26FPS

Both for exact 10,000 frames of the same source material. At least far closer than with MC.

EDIT: Didn't see your new post. This is still with ZS 1.146 Shall I try it again with 1.147?

[real.finder]

yes, try with last one for all tests (both MC and without MC)

100% identical I think is something improbable, it's ok if it 99% in this case

[tormento]

Zs_RF_Shared.avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) (Shared Functions and utility V1.05 or up) is needed
I don't know how but there are two versions floating on GitHub: 1.143 and 1.147.

[LeXXuz]

Well, here we go:

1)
sneo_dfttest(sigma=48, chrsigma=16):
(149.680.128 Bytes) ~ 11.29FPS

2)
sneo_dfttest(sigma=48).MergeChroma(sneo_dfttest(sigma=16)):
(149.639.168 Bytes) ~ 7.52FPS

3)
dfttestMC(Y=true, U=true, V=true, sigma=48, MC=3, dither=0, dfttest_params=", chrsigma=16"):
(128.700.416 Bytes) ~ 9.11FPS

4)
dfttestMC(Y=true, U=false, V=false, sigma=48, MC=3, dither=0, chromama=true).MergeChroma(dfttestMC(Y=false, U=true, V=true, sigma=16, MC=3, dither=0)):
(128.708.608 Bytes) ~ 8.08FPS


=>
-All four tests with exact 10,000 frames of the same source material.
-With v1.147 encoding speed dropped for all 4 tests compared to V1.146.
-Output file size with MC much smaller, as expected. But I'm quite suprised MC reduces speed only by such a little margin. Is that correct???
-Why is 4) faster than 2)? Because x265 encoder had less grain to analyze?


Filters used:

Zs_RF_Shared.avsi V1.147
dfttestMC_and_MC_things.avsi V2.122
mvtools-2.7.44\x64\mvtools2.dll (pinterf's version)
neo-dfttest\64\neo-dfttest.dll (still use the version you provided me with here (https://forum.doom9.org/showthread.php?p=1924992#post1924992))
mtmodes.avsi (from here (http://avisynth.nl/index.php/AviSynth+#Help_filling_MT_modes) )
Avisynth+ 3.6.1 (r3300, 3.6, x86_64)
Prefetch(8)

Avisynth script:
SetMemoryMax(10240)
#
LoadPlugin("C:\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\WORK\source.mkv")
#
crop(240, 0, -240, 0)
#
LoadPlugin("C:\MeGUI (x64)\tools\avisynth_plugin\neo-dfttest\64\neo-dfttest.dll")
LoadPlugin("c:\MeGUI (x64)\tools\avisynth_plugin\mvtools-2.7.44\x64\mvtools2.dll")
#
Import("C:\MeGUI (x64)\tools\avisynth_plugin\dfttestMC_and_MC_things.avsi") #v2.122
Import("C:\MeGUI (x64)\tools\avisynth_plugin\Zs_RF_Shared.avsi") #v1.146
Import("C:\MeGUI (x64)\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
#
<INSERT DENOISER HERE>
#
Trim(0,10000)
Prefetch(8)
Return(Last)

x265 Settings:

-[Information] [20.03.2021 14:19:37] custom command line: --qpfile "D:\WORK\chp.qpf" --output-depth 10 --ctu 32
--aq-mode 2 --limit-refs 3 --rd 4 --psy-rd 3 --psy-rdoq 15 --colorprim bt709 --transfer bt709 --colormatrix bt709

...

-[Information] [20.03.2021 14:19:39] y4m [info]: 1440x1080 fps 24000/1001 i420p16 sar 1:1 unknown frame count
-[Information] [20.03.2021 14:19:39] raw [info]: output file: D:\WORK\Output.hevc
-[Information] [20.03.2021 14:19:39] x265 [info]: HEVC encoder version 3.5+8-57e817329
-[Information] [20.03.2021 14:19:39] x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 10bit
-[Information] [20.03.2021 14:19:39] x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
-[Information] [20.03.2021 14:19:39] x265 [info]: Main 10 profile, Level-4 (Main tier)
-[Information] [20.03.2021 14:19:39] x265 [info]: Thread pool created using 32 threads
-[Information] [20.03.2021 14:19:39] x265 [info]: Slices : 1
-[Information] [20.03.2021 14:19:39] x265 [info]: frame threads / pool features : 5 / wpp(34 rows)
-[Information] [20.03.2021 14:19:39] x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
-[Information] [20.03.2021 14:19:39] x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
-[Information] [20.03.2021 14:19:39] x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
-[Information] [20.03.2021 14:19:39] x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
-[Information] [20.03.2021 14:19:39] x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
-[Information] [20.03.2021 14:19:39] x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
-[Information] [20.03.2021 14:19:39] x265 [info]: References / ref-limit cu / depth : 5 / on / on
-[Information] [20.03.2021 14:19:39] x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
-[Information] [20.03.2021 14:19:39] x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
-[Information] [20.03.2021 14:19:39] x265 [info]: tools: rect amp limit-modes rd=4 psy-rd=3.00 rdoq=2 psy-rdoq=15.00
-[Information] [20.03.2021 14:19:39] x265 [info]: tools: rskip mode=1 limit-tu=4 signhide tmvp b-intra
-[Information] [20.03.2021 14:19:39] x265 [info]: tools: strong-intra-smoothing deblock sao

[real.finder]

I don't know how but there are two versions floating on GitHub: 1.143 and 1.147.

because I didn't update the master tree yet



=>
-All four tests with exact 10,000 frames of the same source material.
-With v1.147 encoding speed dropped for all 4 tests compared to V1.146.
-Output file size with MC much smaller, as expected. But I'm quite suprised MC reduces speed only by such a little margin. Is that correct???
-Why is 4) faster than 2)? Because x265 encoder had less grain to analyze?



as I said

aside from that there was some compatibility problems with old dfttest since neo_dfttest is based on VS dfttest port which has some default settings changes, now they should be fixed

the default of tbsize in neo is 3 but in original it was 5 and that why now it's slower, in mc you set the mc=3 and that will make tbsize=3

[LeXXuz]

in mc you set the mc=3 and that will make tbsize=3

I'm confused now. Isn't tbsize set to 2*MC+1 in dfttestMC()? Or is this not valid anymore?

[real.finder]

I'm confused now. Isn't tbsize set to 2*MC+1 in dfttestMC()?

yes, but it's kinda equivalent to non MC tbsize if you think of it that way, since you compare the sizes and speed

edit: also 4) is faster than 2) since 2 process all planes twice

[LeXXuz]

Ok, so I guess option 3) would be my best bet, right?

Just one last thing, I have to use slocation not sstring if I want to give a sigma curve via dfttest_params to neo-dfttest. Is that correct?

My final denoiser line with option 3) would look like this now:
dfttestMC(Y=true, U=true, V=true, MC=3, dither=0, dfttest_params=""", slocation="0.0:64 0.1:8 0.2:16 0.3:32 0.4:64 1.0:64", chrslocation="0.0:16 0.1:2 0.2:4 0.3:8 0.4:16 1.0:16" """)

To use "0.0:64 0.1:8 0.2:16 0.3:32 0.4:64 1.0:64" as the sigma frequency-curve for luma and "0.0:16 0.1:2 0.2:4 0.3:8 0.4:16 1.0:16" for chroma.

In the past I would have used these lines:
dfttestMC(Y=true, U=false, V=false, sstring="0.0:64 0.1:8 0.2:16 0.3:32 0.4:64 1.0:64", MC=3, dither=0)
dfttestMC(Y=false, U=true, V=true, sstring="0.0:16 0.1:2 0.2:4 0.3:8 0.4:16 1.0:16", MC=3, dither=0)

Which I learned now, wasn't quite correct because the 2nd instance used the already denoised output of the 1st instance.

Just want to make sure I understood the syntax correctly now and get what I intend to, before I start lots of encoding jobs.^^ :o

[real.finder]

like this dfttestMC(Y=true, U=true, V=true, MC=3, dither=0, sstring="0.0:64 0.1:8 0.2:16 0.3:32 0.4:64 1.0:64", chrslocation="0.0:16 0.1:2 0.2:4 0.3:8 0.4:16 1.0:16")

[LeXXuz]

Perfect! Thanks a lot real.finder. Once again, you've been a tremendous help! :thanks:

[LeXXuz]

real.finder can you explain what the "rStr" parameter does in dfttestMC()?

And is "mdgSAD" or "thSAD" here the parameter to modify the 'strength' of the optional degrain filter?

Right now I have a source that is so noisy that dfttest alone couldn't cut it without losing way too much detail in dark areas. :(

[real.finder]

real.finder can you explain what the "rStr" parameter does in dfttestMC()?

And is "mdgSAD" or "thSAD" here the parameter to modify the 'strength' of the optional degrain filter?

Right now I have a source that is so noisy that dfttest alone couldn't cut it without losing way too much detail in dark areas. :(

it's same as Str in SMDegrain

Str float (0.0-8.0, default 1.0)

Gamma correction. With this parameter you control the strength of the brightening of the prefilter clip, good for when problems with dark areas arise. Using this internally instead of externally creates less quantization artifacts, since it's done in the same stage as the TV->PC range conversion.

but not same effect.


mdgSAD is for optional degrain filter, thSAD is not

[LeXXuz]

I see. The mdgSAD=thSAD note in the script confused me a little. Thanks! :)

[GMJCZP]

Real.finder:

Your latest version of DeHaloHmod does not contain the Camembert function (which is called internally) as if the version 2.38 I have.

[real.finder]

Real.finder:

Your latest version of DeHaloHmod does not contain the Camembert function (which is called internally) as if the version 2.38 I have.

it's moved to Zs_RF_Shared.avsi

[GMJCZP]

it's moved to Zs_RF_Shared.avsi

Ok, thanks.

[Dogway]

Do I need a plugin for sh_GetUserGlobalIMTint()? I don't get any output from it, not a number at least.

[real.finder]

Do I need a plugin for sh_GetUserGlobalIMTint()? I don't get any output from it, not a number at least.

see here https://forum.doom9.org/showpost.php?p=1921381&postcount=574

[real.finder]

SMDegrain now NotSMDegrain in Community tree, since Dogway back to update SMDegrain

[kedautinh12]

Why NotSMDegrain?? I think SMDegrain2 is beautiful name. In the future if you continue development i think you need rename LSFmod to LSFmod2, grainfactorymod to grainfactorymod2

[real.finder]

Why NotSMDegrain??

because it's not simple anymore

[Ripmann]

because it's not simple anymore

How about SMDegrainRF (Real.Finder)?

Also, I checked for the latest available version by Dogway and it's still very old. Was it already updated somewhere else, or the update is just in plans for now? What are the expected differences between the two scripts?

[real.finder]

NotSMDegrain will not keep it update with Dogway SMDegrain, if it do then it will be waste of efforts, the points I kept it as NotSMDegrain are since it based on very known version of Dogway SMDegrain for long time and I kinda use it for things that not Degrain (https://forum.doom9.org/showthread.php?p=1942945#post1942945), also since new Dogway SMDegrain dropped many things and only work in newer avs+

[LeXXuz]

After playing around with SMDegrain for quite some time, I have to say that "contrasharp=true" routine does a pretty good job in retaining fine detail. :)

A much better one as plain LSF/mod for my taste.

So I was wondering is it possible to implement this into dfttestMC somehow? :o:D

[real.finder]

After playing around with SMDegrain for quite some time, I have to say that "contrasharp=true" routine does a pretty good job in retaining fine detail. :)

A much better one as plain LSF/mod for my taste.

So I was wondering is it possible to implement this into dfttestMC somehow? :o:D

you can use it as ContraSharpeningHD https://github.com/realfinder/AVS-Stuff/blob/fe1aece169f30f805c0c1fec5f0478e0dfd5f5f0/avs%202.5%20and%20up/Zs_RF_Shared.avsi#L576

but it will not act as "ContraSharpeningHD" but "ContraSharpening" HD case will need doing "global" for motion analysis mvtools things

[LeXXuz]

Is there a way to get super, cb1 and cf1 for HD sharpening mode out of dfttestMC?

I can get HD mode to work with running SMDegrain to just get the vectors. Like:
SMDDegrain() (vectors only, added two lines to globals for cb1 and cf1, so I can leave contrasharp=false)
dfttestMC()
ContraSharpeningHD()

However, that really eats up my system memory.

[zorr]

Is there a way to get super, cb1 and cf1 for HD sharpening mode out of dfttestMC?

In the latest test version of AviSynth you could store the clips into frame properties. https://forum.doom9.org/showthread.php?p=1946405#post1946405

[real.finder]

Is there a way to get super, cb1 and cf1 for HD sharpening mode out of dfttestMC?

I can get HD mode to work with running SMDegrain to just get the vectors. Like:
SMDDegrain() (vectors only, added two lines to globals for cb1 and cf1, so I can leave contrasharp=false)
dfttestMC()
ContraSharpeningHD()

However, that really eats up my system memory.

I will think about this later. its too hot here to do anything :)

[real.finder]

try https://github.com/realfinder/AVS-Stuff/commit/15ec37a05e090c9438fc855b7d2df572436ccb75

[kedautinh12]

Thanks

[LeXXuz]

I will think about this later. its too hot here to do anything :)

No worries. :) I'm already wondering how much difference in 'quality' or even speed there might be between HD-mode and normal mode.

[hello_hello]

real.finder,

ResizeX seems to have issues. Try this with any source and you'll see what I mean.

ResizeX(width(),height(), 100,100,0,0)

Cheers.

[real.finder]

real.finder,

ResizeX seems to have issues. Try this with any source and you'll see what I mean.

ResizeX(width(),height(), 100,100,0,0)

Cheers.

original ResizeX by Desbreko is same, resize8 is ok

[real.finder]

real.finder,

ResizeX seems to have issues. Try this with any source and you'll see what I mean.

ResizeX(width(),height(), 100,100,0,0)

Cheers.

try ResizeX(width(),height(), 100,100,0,0,resize8=true) with https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/ResizeX.avsi

[hello_hello]

Is the Resize8 argument for testing purposes?

It seems to be okay when Resize8=true (the output appears to be the same as Resize8 with it's noring arguments false and Spline36 used for luma and chroma).
When it's false it's the same as before. I'm not sure why you'd want it to behave the old way though.

Can you tell me if I'm missing something here?
Edit: Don't worry, I worked it out and explained it to myself in the next post.
I haven't tried very hard to work out why yet, but something doesn't seem quite right, and I'm not seeing anything obvious in the functions.

ColorBars()
KillAudio()
ConvertToYV12()
A = last

OutW = 1280
OutH = 960
RXCropC = 0.25 * (1.0 - (float(width(A) / 2.0) / float(OutW / 2.0)))
RXCrop = RXCropC * 2.0
R8CropC = 0.25 - ((width(A) / 2) * 0.25 / float(OutW / 2))
R8Crop = R8CropC * 2.0

Yp = ExtractY(A).BilinearResize(OutW,OutH, 0,0,0,0)
Up = ExtractU(A).BilinearResize(OutW/2,OutH/2, RXCropC,0,0,0)
Vp = ExtractV(A).BilinearResize(OutW/2,OutH/2, RXCropC,0,0,0)

CP = CombinePlanes(Yp, Up, Vp, planes="YUV", source_planes="YYY", pixel_type=PixelType(A))
MC = MergeChroma(A.BilinearResize(OutW,OutH, 0,0,0,0), A.BilinearResize(OutW,OutH, RXCrop,0,0,0))
RX = A.ResizeX(OutW,OutH, kernel="Bilinear", Resize8=true)
R8 = A.Resize8(OutW,OutH, noring=false, noring_c=false, kernel="Bilinear", kernel_c="Bilinear")

# Subtract(CP, MC) # Same
# Subtract(RX, R8) # Same
# Subtract(CP, RX) # Different
# Subtract(MC, R8) # Different

subtitle(string(RXCropC, "%.20f"), align=8)\
.subtitle(string(R8CropC, "%.20f"), align=2)

While I'm here, in case you know.
Any idea why ResizeX excludes PointResize from the chroma shift fix?

Cheers.

[hello_hello]

I think I know what the difference is. It's due to the way Avisynth interprets "src_right" according to whether it's >0 or <=0, and both scripts are converting a src_right cropping of zero to a positive number, changing the way it's interpreted.

Using my MergeChroma example above, the way I thought it was done in one of the original threads where this issue first came to light was like this:

MergeChroma(A.BilinearResize(OutW,OutH, 0,0,0,0), A.BilinearResize(OutW,OutH, RXCrop,0,0,0))

But it was actually this:
https://forum.doom9.org/showthread.php?p=1543797#post1543797

SW = width(A)
SH = height(A)
MergeChroma(A.BilinearResize(OutW,OutH, 0,0,SW,SH), A.BilinearResize(OutW,OutH, RXCrop,0,SW,SH))

That makes more sense, as it effectively increases the chroma width and keeps the same luma to chroma ratio.

Sorry to interrupt the thread while I worked that out. :)

[tuqc]

when I use "notSMDegrain(Contrasharp=true)" I get "I dont know what 'cb1' means".anyone help me out,thx

tested。1080P works fine with 'Contrasharp=true'。 480p get error 。anyone same promble?

[real.finder]

Is the Resize8 argument for testing purposes?

It seems to be okay when Resize8=true (the output appears to be the same as Resize8 with it's noring arguments false and Spline36 used for luma and chroma).
When it's false it's the same as before. I'm not sure why you'd want it to behave the old way though.

kinda of, I don't want to change filter behavior I didn't made in first place, keep in mind that edi_rpow2 use resizex, I didn't test if this break it, also I can't do much test/works these days (https://forum.doom9.org/showpost.php?p=1946527&postcount=756) so contributions are welcome


when I use "notSMDegrain(Contrasharp=true)" I get "I dont know what 'cb1' means".anyone help me out,thx

tested。1080P works fine with 'Contrasharp=true'。 480p get error 。anyone same promble?

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

[hello_hello]

kinda of, I don't want to change filter behavior I didn't made in first place, keep in mind that edi_rpow2 use resizex, I didn't test if this break it, also I can't do much test/works these days (https://forum.doom9.org/showpost.php?p=1946527&postcount=756) so contributions are welcome

I'm not familiar with edi_rpow2 and I haven't studied avisynth variable shorthand, so it's not always easy to work out what variables/functions represent. "sisphbd", "nrb", "nrf", "tmm2_ortmm1"... I'm learning them slowly though.
Why are so many functions written as though there's a need for DOS 8.3 vrbnames. :)

Anyway, as ResizeX effectively adds the left and top cropping to the source width and height (or doesn't subtract it... I've forgotten already) it seems specifying those prevents it misbehaving. With the new Resize8 argument false there's an obvious difference between these two.

ColorBars()

ResizeX(640,480, 20,20,620,460)
and
ResizeX(640,480, 20,20,0,0)

These are in complete agreement though, so I can only assume ResizeX has been broken for a while (I used a wrapper function to disable anti-ringing etc for Resize8).

Spline36Resize(640,480, 20,20,0,0)
WResize8(640,480, 20,20,0,0, cplace="mpeg1")

I had a quick skim through edi_rpow2, and most of the calls to ResizeX don't specify any right or bottom cropping. Bummer..... For the record, these two are the same, so I assume eedi3 does.

eedi3_rpow2(rfactor=4, cshift="ResizeX", fwidth=1280, fheight=960)
eedi3_rpow2(rfactor=4, cshift="WResize8", fwidth=1280, fheight=960)

[hello_hello]

kinda of, I don't want to change filter behavior I didn't made in first place....

Well it turns out ResizeX's behaviour isn't that far removed from the norm. Obviously I've spent too much time with my head up my backside to notice.

The Avisynth resizer page says the defaults for src_width and src_height are... well... the source width and height.

http://avisynth.nl/index.php/Resize
float src_left, src_top = 0, 0
float src_width, src_height = (source width, height)

That's followed by cropping rules that are just plain wrong for resizer cropping, but ResizeX isn't quite following them anyway, because.....

float src_width/height =
If > zero, these set the width and height of the clip before resizing.
If <= zero, they set the cropping of the right and bottom edges respectively, before resizing.

BilinearResize(640,480, 100) behaves like ResizeX.
BilinearResize(640,480, 100, 0, 0,0) ends the madness.

For ResizeX though, zero for the right/bottom cropping doesn't get it done.

Well... I'm off to contemplate living in a world where those defaults aren't considered mental...

[real.finder]

yes, I also think ResizeX behaviour is worng, but maybe edi_rpow2 (https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/edi_rpow2.avsi) not eedi3_rpow2 need this

[StainlessS]

R.F.,
Any idea whats happening here,


ColorBars(Pixel_type="YV12").KillAudio.Assumetff
Stab3(use_Feedback=true) # Stab3(use_Feedback=false) OK


PotPlayer and VDub2 both just disappear like magic [on play/load], similar symptoms to recursive stack exhaustion and Avisynth total crash [without error message].

[kedautinh12]

Yeah, i crash with Stab3() too, use normally with Stab3(use_Feedback=true)

[StainlessS]

Further, W10 Windows Logs

Exception code: 0xc0000409
Fault offset: 0x000000000006db8e
Faulting process ID: 0x740
Faulting application start time: 0x01d7893d29ee940e
Faulting application path: C:\NON-INSTALL\VDUB\VDUB2\VirtualDub64.exe
Faulting module path: C:\Windows\System32\ucrtbase.dll
Report ID: ab0d1965-784d-4b6d-aa1a-5f61d73dfdef
Faulting package full name:
Faulting package-relative application ID:

EDIT:
Above error code seem to be related to Windows Update Error, [I have Windows Update disabled on W10],
dont see why that can be related.

W7, I'm gettin'
The named argument 'mask' to InpaintDelogo had the wrong type.
StabilizationToolsPack.avsi, Line 482.

Line 482

bfix > 1 ? stabclip.FillBorders_stabi(pad=subsampl && mirror!=15 ? 1 : 0,subsample=subsampl,FixFalPos=defined(FalPosclip) ||
\ FixFalPos ? last : Undefined, mirror=mirror==15,PAR=PAR, FillBordersc=u_ExIn ? preclip.ExInpaint(bfixc.mt_lut(u=-255,v=-255))
\ : u_InDe ? preclip.InpaintDelogo(mask=bfixc, Loc="0,0,0,0",dPP=0,dPPm=1,diPP=1,diPPm=0,oPP=1,oPPm=0,Inflate=0)
\ : preclip.InpaintLogo(bfixc)) : bfixc

EDIT: Just before above line bfixc = type YV12, presume InpaintDelogo requires RGB.
EDIT: Says "wrong type", not "wrong colorspace type", But is showing for me type clip YV12. [so I'm confused]

[StainlessS]

PotPlayer and VDub2 both just disappear like magic [on play/load], similar symptoms to recursive stack exhaustion and Avisynth total crash [without error message].


From Stack Overflow
The clue to the problem is in the exception code: 0xc0000409

0xc0000409 means STATUS_STACK_BUFFER_OVERRUN.

In other words, something in your program is writing past the current stack frame, corrupting data on the stack. The program has detected this and rather than let it continue, has thrown an exception.
https://stackoverflow.com/questions/23409809/windows-7-exception-code-0xc0000409
Dont know why some post on Microsoft.com thought it were to do with Windows Update.

EDIT: So, AVS error message on W7, and Stack exhaustion/corruption on W10.

EDIT: Anybody confirm error results on both W7 and W10 ? [with current StabilizationToolsPack.avsi and Zs_RF_Shared.avsi]

[real.finder]

did you have last https://forum.doom9.org/showthread.php?t=176860 ?

[StainlessS]

I had v1.2 [5th July 2019] which seems to be last in Pinterf suppository :),
but posted by VoodooFX as v1.24 [28 Nov 2020] at your linked post [post attachment].

Thanks, I'll give it a try [maybe later, gotta get to pub before it runs out of beer].

EDIT: Damn it, I think I was confusing InpaintDelogo[v1.24] and AvsInpaint[v1.2].

[StainlessS]

R.F.,
Any idea whats happening here,


ColorBars(Pixel_type="YV12").KillAudio.Assumetff
Stab3(use_Feedback=true) # Stab3(use_Feedback=false) OK


PotPlayer and VDub2 both just disappear like magic [on play/load], similar symptoms to recursive stack exhaustion and Avisynth total crash [without error message].

OK, I finally updated InPaintDeLogo.avsi [v1.24] and problem disappears [on W10 (stack exhaustion gone), not tried yet on W7 but anticipate no probs], Thanks R.F.

[real.finder]

test update https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/nnedi3_resize16.avsi to use fmtconv

note: it's not work with noring yet, it's need porting Dither_resize16nr to fmtc_resamplenr, which use array in way like this https://forum.doom9.org/showthread.php?p=1949689#post1949689 so I will wait for now

fmtconv update for nnedi3_resize16 should fix many old problems, like this https://forum.doom9.org/showthread.php?p=1924894#post1924894

something old now (nothing to do with last update) but also if you want the old default hybrid LBD and lsb you can set FastNnediHBD to true (to use nnedi3 with 8bit whatever the HBD input is used, just like the old "lsb_in=true, lsb=true" but it using HBD in other places so it's not 100% same output or even speed as lsb (it's a bit slower than lsb because slimit_dif vs Dither_limit_dif16))

also aside from that, keep in mind that nnedi3_resize16 still use dithertools if you use 8bit even without lsb, in short it's still use hacks

[tormento]

also AKA A.SONY's Avisynth Stuff
Could you please adapt SPresso and STpresso to ExTools from DogWay? We could get rid of masktools, RGTools and perhaps something else.

P.S: Do they support HBD?

[real.finder]

I plan to update crt-display (CRT display emulator) by cretindesalpes but it need Dither_box_filter16 (https://forum.doom9.org/showpost.php?p=1943559&postcount=1131) and Dither_resize16nr (already plan to port it to fmtc_resamplenr (https://forum.doom9.org/showpost.php?p=1950009&postcount=777))

Could you please adapt SPresso and STpresso to ExTools from DogWay? We could get rid of masktools, RGTools and perhaps something else.

Currently very unlikely

[Dogway]

Could you please adapt SPresso and STpresso to ExTools from DogWay? We could get rid of masktools, RGTools and perhaps something else.

I ported SPresso (https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/Spresso.avsi).

Anyway I'm not entirely replacing RGTools with ExTools (except for EX mods) because RGTools is insanely fast (AVX2 helps), blurs are ok within 10% of removegrain() but medians are slower. Anyway removegrain(4) is very very basic and thickens lines so I will replacing it with a smarter median on the long run.

[tormento]

I ported SPresso

Thanks! Please when you have time, port STPresso too, as I need it. ;)

[Dogway]

I tested it and runs at 3.1 fps. I think there might be better. For spatio-temporal I made STWM which runs at 132 fps or even ML3D (304 fps), they are not thresholded but I can craft something similar. I don't have time these days since I'm finishing ExTools and Sharpeners Pack but will have a look later on.


EDIT: Couldn't resist so made something quickly, check over my thread (https://forum.doom9.org/showthread.php?p=1950095#post1950095).

[tormento]

Anyway I'm not entirely replacing RGTools with ExTools (except for EX mods) because RGTools is insanely fast (AVX2 helps)
Unfortunately Sandy Bridge here, no AVX2.

[tormento]

I ported SPresso

My script:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_52 Mimi metallurgico ferito nell'onore\mimi.dgi",ct=24,cb=24,cl=0,cr=0)
CompTest24(1)
Spresso(10,30).STpresso(10,30,4,22,8,49,1,mc=true) #last updates
Prefetch(6)

Little sample with original real.finder SPresso:

Number of frames: 3264
Length (hh:mm:ss.ms): 00:02:16.000
Frame width: 1920
Frame height: 1032
Framerate: 24.000 (24/1)
Colorspace: YV12

Frames processed: 3264 (0 - 3263)
FPS (min | max | average): 2.216 | 666666 | 25.01
Process memory usage (max): 1006 MiB
Thread count: 19
CPU usage (average): 70.1%

Time (elapsed): 00:02:10.485

With Dogway's SPresso:

Frames processed: 3264 (0 - 3263)
FPS (min | max | average): 2.121 | 270270 | 20.80
Process memory usage (max): 989 MiB
Thread count: 21
CPU usage (average): 71.5%

Time (elapsed): 00:02:36.938

Dogway SPresso is slower in 8 bit but way faster in HBD (16 bit):

real.finder

FPS (cur | min | max | avg): 0.591 | 0.122 | 344828 | 1.198

Dogway

FPS (cur | min | max | avg): 1.686 | 0.199 | 108696 | 1.949

I can't use Dogway STPresso too as some switched are missing (MC=true). Please make it true :)

[Dogway]

It's on the header of ExTools, it's normal that it's slower in 8-bit, since pinterf is still working on Expr LUT calculations, but that's not always true (check QTGMC mix mod benchmarks) because I do heavy expression optimizations.

STPresso uses FluxSmoothT which is a dumb temporal median, so it needs an internal thresholding AND a slow MC limiter. I solved that with a temporal gaussian median. In the same vein STPresso uses minblur/removegrain(4) which is a dumb spatial median, I replaced that with a gaussian weighted median. minblur by the way is very inefficient, I already modified it for next SMDegrain version doubling its speed, in any case I might totally get rid of it since it can be replaced with a single type of median.

These tools were fine for its time, now fortunately we have better. I will try to implement fluxsmootht to ex_median if that makes people happy : P

[tormento]

These tools were fine for its time, now fortunately we have better. I will try to implement fluxsmootht to ex_median if that makes people happy : P
Sometimes I beat my head to some strange and heavily incompressible video that, even if the grain seems filtered out, it gives insane bitrate when encoding with x264 or such. Usually, with a CRF of 20, I get as max 3500 kbit/s while this particular one goes over 6/7k.

If you are interested I can share a brief clip to you.

[tormento]

These tools were fine for its time, now fortunately we have better.
I have tried many aces in my sleeve with this video clip (https://send.cm/d/4PF0) but I can't get a x264 encode under ~7000 kb/s with CRF=20.

There seems to be no grain left and I really can't understand what is preventing me to have a good compressibility.

Ideas about how to deal with it?

[LeXXuz]

I'm asked for a pw to download that file :confused:

[real.finder]

I'm asked for a pw to download that file :confused:

what file and what is "pw"?

[LigH]

Might be related to tormento's clip; "pw" means "password"; some file hosters with short URLs use them to restrict downloading to countable attempts (to avoid brute force guessing of valid short URLs).

[LeXXuz]

Yes. I wanted to take a look at the file tormento spoke about. But its download seems to be password protected.

[tormento]

I'm asked for a pw to download that file :confused:

what file and what is "pw"?

Might be related to tormento's clip

Sorry guys. I tried a new sharing service and I did not properly use it.

Here is the correct link (https://send.cm/wtzb6onyxvqp). It will expire in 15 days.

[tormento]

Nobody? Don't want to open a new thread for this. :)

[LeXXuz]

Will take a look. What have you tried so far?

[tormento]

Will take a look. What have you tried so far?


SMDegrain and nested SPresso.

[LeXXuz]

Well that clip is quite noisy. Will see how much I can remove without losing noticeable detail. Why that 7Mbit goal?

[Dogway]

You can use mfilter to blur where motion vectors fail, like:
mf=ex_boxblur(2,mode="weighted")
smdegrain(tr=5,thSAD=400,contrasharp=false,mfilter=mf,prefilter=2,refinemotion=true)

You can also try:
TSMC(6,280,blocksize=16)

But it will smear a bit low freq image. I plan to port Didée's LTSMC() as a more robust version of TSMC, where I will also include an mfilter option.

EDIT: for the time being maybe you can use this:

mf=ex_boxblur(2,mode="weighted")
pre=TSMC(6,280,blocksize=16)
smdegrain(tr=5,thSAD=400,contrasharp=true,mfilter=mf,prefilter=pre,refinemotion=true)

[LeXXuz]

I end up with around 5.5-6Mbit for that clip @ CRF20

1st try:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2 min 55 s
Bit rate : 6 056 kb/s
Width : 1 920 pixels
Height : 1 036 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.127
Stream size : 127 MiB (98%)
Writing library : x264 core 161 r3018 db0d417
Encoding settings : cabac=1 / ref=4 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.15:0.30 / mixed_ref=1 /
me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-4 / threads=48 / lookahead_threads=4 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 /
weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 /
vbv_maxrate=25000 / vbv_bufsize=31250 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=2:1.00
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

2nd try:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2 min 55 s
Bit rate : 5 552 kb/s
Width : 1 920 pixels
Height : 1 036 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.116
Stream size : 116 MiB (98%)
Writing library : x264 core 161 r3018 db0d417
Encoding settings : cabac=1 / ref=4 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.15:0.30 / mixed_ref=1 /
me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-4 / threads=48 / lookahead_threads=4 / sliced_threads=0 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 /
weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 /
vbv_maxrate=25000 / vbv_bufsize=31250 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=2:1.00
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

This is what I get on a quick run. Look for yourself at the samples I sent you. Can provide script if you like what you see.

That movie is tricky. It's not only the film grain that prevents low bitrates. On camera pans you can see that they already tried some ugly noise filtering.
Also in the outdoor scenes of the construction site you can clearly see compression artefacts on the walls. Seems the source encoder already didn't get enough bitrate for that scenery.


I don't like x264 deblocking filter, that's why it is set to -3:-3. With CRF20, x264 smoothes the picture enough already.
10-bit video would improve backgrounds a little more but I don't know if your players can decode 10-bit AVC, so I sticked with 8-bit. Personally I don't do 8-bit encodes anymore.
Anyhow, I haven't used x264 in a long time so these may not be the best settings to use.

[real.finder]

in case someone didn't note, https://github.com/realfinder/AVS-Stuff/blob/Community/for%20AVSPlus/fmtc_resamplenr.avsi (still need work for planes paramters for rgtools and masktools if that even possible with how fmtconv use planes parameter)

also now you can do this

convertbits(32) #or fmtc_bitdepth(32)
eedi3_resize16(1000,1000,fastedihbd=true,nnsclip=true,nnrep=2)
# or nnedi3_resize16(1000,1000,fastnnedihbd=true)

[kedautinh12]

Wow, many updates after for a long time. Welcome back real.finder

[tormento]

Well that clip is quite noisy. Will see how much I can remove without losing noticeable detail. Why that 7Mbit goal?
I put myself a limit with x264 CRF 20 at around 3600 kbps.

[tormento]

Look for yourself at the samples I sent you. Can provide script if you like what you see.
Very nice piece of work, please share the script.
I don't like x264 deblocking filter, that's why it is set to -3:-3.
I will try too.
10-bit video would improve backgrounds
I love HEVC @ 10bit but my PC is getting old and encoding at 3-5 fps is a bit slow :) I do that only for masterpiece movies.

[tormento]

You can use mfilter to blur where motion vectors fail, like
Never thought about that. Thank you!

[LeXXuz]

please share the script.

No problem. Nothing spectacular. I used this for the first clip:
ConvertBits(16)
Original=last
neo_fft3d(sigma=6, sigma2=1.50, sigma3=1.50, sigma4=1.50, bt=1, sharpen=0, Y=3, U=2, V=2)
neo_fft3d(sigma=3, sigma2=0.75, sigma3=0.75, sigma4=0.75, bt=1, sharpen=0, Y=2, U=3, V=3)
pre=RemoveGrain(mode=2, modeU=17, modeV=17, planar=false).sneo_dfttest(slocation="0.0:6 0.6:24 1.0:48", chrslocation="0.0:3 0.6:12 1.0:24", tbsize=1, Y=3, U=3, V=3).Blur(0.25)
SMDegrain(tr=12, thSAD=500, contrasharp=true, CClip=Original, refinemotion=true, truemotion=false, Str=1.2, pel=1, subpixel=2, prefilter=pre)
neo_f3kdb(range=30, Y=64, Cb=64, Cr=64, grainY=64, grainC=64, sample_mode=4)
ConvertBits(8, dither=1)
Prefetch(20,20)
Return(Last)

And this one for the second:
ConvertBits(16)
Original=last
neo_fft3d(sigma=6, sigma2=1.50, sigma3=1.50, sigma4=1.50, bt=1, sharpen=0, Y=3, U=2, V=2)
neo_fft3d(sigma=3, sigma2=0.75, sigma3=0.75, sigma4=0.75, bt=1, sharpen=0, Y=2, U=3, V=3)
pre=RemoveGrain(mode=2, modeU=17, modeV=17, planar=false).sneo_dfttest(slocation="0.0:6 0.6:24 1.0:48", chrslocation="0.0:3 0.6:12 1.0:24", tbsize=1, Y=3, U=3, V=3).Blur(0.25)
SMDegrain(tr=6, thSAD=300, contrasharp=false, refinemotion=true, truemotion=false, Str=1.2, pel=1, subpixel=2, prefilter=pre, globals=2)
SMDegrain(tr=6, thSAD=300, contrasharp=true, CClip=Original, refinemotion=true, truemotion=false, Str=1.2, pel=1, subpixel=2, prefilter=-1, globals=1)
neo_f3kdb(range=30, Y=64, Cb=64, Cr=64, grainY=64, grainC=64, sample_mode=4)
ConvertBits(8, dither=1)
Prefetch(16,16)
Return(Last)

These are the filters and scripts needed:

LoadPlugin("...\neo-dfttest_rf-fix\64\neo-dfttest.dll") #fixed version by real.finder from 05/29/21
LoadPlugin("...\neo-f3kdb_r6\clang-x64\neo-f3kdb.dll")
LoadPlugin("...\NeoFFT3D_rf-fix\64\neo-fft3d.dll") #fixed version by real.finder from 05/29/21
#
LoadPlugin("...\masktools2-v2.2.26\x64_clang\masktools2.dll")
LoadPlugin("...\mvtools-2.7.44\x64\mvtools2.dll")
LoadPlugin("...\RgTools-v1.1\x64_LLVM_build\RgTools.dll")
LoadPlugin("...\MedianBlur2_v1.1\x64_Clang\MedianBlur2.dll")
#
Import("...\SMDegrain.avsi") #v3.1.2d
Import("...\Zs_RF_Shared.avsi") #v1.147
Import("...\mtmodes.avsi")


These scripts are taylored to my machines, my personal taste and my viewing equipment for very noisy films. On slower machines this may be a little bit overkill.

So, for speed improvement lower the temporal radius in SMDegrain from what I used. => tr=6 for that single-stage filtering and tr=4 for those two 2pass-stages in the other script.
You could also try to disable contrasharp which will give you more speed and surely even more compressibility. But the picture may look too smooth in the end. Remove the blur for SMDegrains prefiltering if you don't use contrasharp.

neo_fft3d is pretty quick so I would not touch that. It removes high pitched noise in all planes in the spatial domain. Otherwise you may get a "curtain-like" effect on camera pans as SMDegrain tends to leave 'static' pixels in the picture on higher settings. Prefiltering with a spatial denoiser helps to reduce that effect.

I use my own dfttest-settings with higher sigma ramps for prefiltering in SMDegrain instead of the default values (prefilter=3).

I prefer to filter chroma planes about half as much as the luma plane. I don't like the effect that too strong chroma filtering has on moving objects in the picture.

[real.finder]

tormento, you can try https://forum.doom9.org/showthread.php?p=1910867#post1910867

[tormento]

tormento, you can try
I will. It seems I am a bad transfer movie subscriber...

[LeXXuz]

Sorry, if this may be a little OT. :o

I have a film here which got some very bad post processing.The studio really went over the hill with edge sharpening.

So I was wondering, is there some kind of counterpart to LimitedSharpen? I mean a filter which does soften sharp edges/high contrasts way more than subtle textures/details?

I know LSFmod has a built-in softener but that only affects the prior sharpening effect if I'm not mistaken.

[real.finder]

in case someone need fmtconv/fmtcavs for winxp https://github.com/realfinder/UniversalPluginsFolders/blob/633abc99b47e34b1f7a62f086e177bae7f395a73/plugins/avsplus/fmtcavs.dll (Maybe once in the life, in the next UniversalPluginsFolders update it will be replaced with Official one but the link should be permanent)

[Boulder]

I'm trying to use sh_LimitChange, but it gives me an error for invalid arguments. I don't see anything wrong with them :( I'm using the Avisynth_3.7.1_20210911_test12 build, and just loading the source with DGSource prior to the call.

sh_limitchange(last, last.blur(0.15), limity=1)

[real.finder]

I'm trying to use sh_LimitChange, but it gives me an error for invalid arguments. I don't see anything wrong with them :( I'm using the Avisynth_3.7.1_20210911_test12 build, and just loading the source with DGSource prior to the call.

sh_limitchange(last, last.blur(0.15), limity=1)

this sh_limitchange(last, last.blur(0.15), 1) seems work

[Boulder]

this sh_limitchange(last, last.blur(0.15), 1) seems work

Thanks, that one works but now I got a second issue. Looks like limit 0.5 is the lowest one to set, anything below that gives an identical limit which seems to be close to zero.

Easy to test with ex_makediff(last, sh_limitchange(last, last.removegrain(17), 0.5), aug=true).

[real.finder]

Thanks, that one works but now I got a second issue. Looks like limit 0.5 is the lowest one to set, anything below that gives an identical limit which seems to be close to zero.

Easy to test with ex_makediff(last, sh_limitchange(last, last.removegrain(17), 0.5), aug=true).

that normal if you use 8bit video

[Boulder]

that normal if you use 8bit video

I think I also had 16-bit video as I placed it inside my denoising function, but I can retest that in the morning.

[Boulder]

I've checked and the same happens for 16-bit video. By the way, is the limit scaled somehow for HBD values like in MDegrain's limit (i.e. range is fixed 0-255 and for HBD limit 0.1 = 0.1 * 255)?

[real.finder]

IBy the way, is the limit scaled somehow for HBD values like in MDegrain's limit (i.e. range is fixed 0-255 and for HBD limit 0.1 = 0.1 * 255)?

I think it's same

and you can't see the real diff of 16 if you got 8bit display, even if you have more than 8bit display you still need the right tools/programs and settings to see the diff

[sp4ce_c0wb0y]

I'm trying to use ASTDRmc() with AviSynth+ v2.6.0 x64. When I try to open the file I get an error saying "There is no function named 'vsTEdgeMask". According to the wiki that's the extra requirement for motion compensation if you're using avisynth 2.5.x and there is no x64 version of TEdgeMask that I could find. I have MVTools and TEMmod as per the wiki and regular ASTDR() works fine. Is this a bug or am I doing something wrong?

Regular ASTDR() is the best de-rainbow I've tried so far btw. Awesome work.

Edit: the error is on line 60 of the script

[kedautinh12]

You need download here
https://github.com/Asd-g/AviSynth-vsTEdgeMask

[sp4ce_c0wb0y]

You need download here
https://github.com/Asd-g/AviSynth-vsTEdgeMask

That did it. Thank you!

[anton_foy]

I try to get the neo_dfttest version of DFTTESTMC to work. I have deleted the "dfttest.dll" and I have only "neo_dfttest.dll" to load.
Still with this:
convertbits(16)
dfttestmc() I get a stacked output (half normal, half green image). Also "slocation" for neo_dfttest doesn't work with dfttestmc only old "sstring"?
I use this version: https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/dfttestMC_and_MC_things.avsi

[real.finder]

I try to get the neo_dfttest version of DFTTESTMC to work. I have deleted the "dfttest.dll" and I have only "neo_dfttest.dll" to load.
Still with this:
convertbits(16)
dfttestmc() I get a stacked output (half normal, half green image).
I use this version: https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/dfttestMC_and_MC_things.avsi

work fine for me
ColorBars(width=640, height=480, pixel_type="yv12")
convertbits(16)
dfttestmc()

Also "slocation" for neo_dfttest doesn't work with dfttestmc only old "sstring"?

if you mean the relationship between dfttest and neo_dfttest and dfttestmc then it should work in either way, anyway you should read starting from https://forum.doom9.org/showthread.php?p=1938572&highlight=chrslocation#post1938572 to know the story

tl;dr: nstring and sstring are for luma (and chroma if you didn't use chrslocation), and didn't matter if you have dfttest or neo_dfttest

[anton_foy]

work fine for me
ColorBars(width=640, height=480, pixel_type="yv12")
convertbits(16)
dfttestmc()



if you mean the relationship between dfttest and neo_dfttest and dfttestmc then it should work in either way, anyway you should read starting from https://forum.doom9.org/showthread.php?p=1938572&highlight=chrslocation#post1938572 to know the story

tl;dr: nstring and sstring are for luma (and chroma if you didn't use chrslocation), and didn't matter if you have dfttest or neo_dfttest
Thanks yes I read that but still gives me the double image (half normal, half green) output but I guess I will have to check everything from scratch because sneo_dfttest and neo_dfttest works without a problem.

EDIT: sorry my mistake I mixed it up, yes sstring works without error in dfttestmc but not slocation. When using sstring with chrslocation it freezes but probably due to my slow system.

[kedautinh12]

Zs_RF_Shared.avsi updated with latest ver vstcanny
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/scripts/Zs_RF_Shared.avsi

[real.finder]

Zs_RF_Shared.avsi updated with latest ver vstcanny
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/master/scripts/Zs_RF_Shared.avsi

thanks for let me know, I did the update on my side https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi

[LeXXuz]

Was there any change in the syntax of now NotSMDegrain()?

With contrasharp=true MeGUI crashes instantly in AVS Script Creator without letting me know what reason.

Integers work as parameter (it uses LimitedSharpen then instead of Contrasharpen, right?)

Any plugin I could be missing?

[real.finder]

Was there any change in the syntax of now NotSMDegrain()?

With contrasharp=true MeGUI crashes instantly in AVS Script Creator without letting me know what reason.

Integers work as parameter (it uses LimitedSharpen then instead of Contrasharpen, right?)

Any plugin I could be missing?

I dont use MeGUI but work fine here (avspmod), tested with DVD source

Integers work as parameter (it uses LimitedSharpen then instead of Contrasharpen, right?)

true, but LSFmod not LimitedSharpen

[LeXXuz]

Weird. Finally got an error message upon import of my script.

Avisynth doesn't know what 'cb1' means.
In NotSMDegrain.avsi line 555.

Does that tell you anything?

I guess I'm missing a plugin, but I don't know which one. MeGUI did an update I did not actually want and caused a little havoc in my plugins folder. :mad:

[real.finder]

Weird. Finally got an error message upon import of my script.

Avisynth doesn't know what 'cb1' means.
In NotSMDegrain.avsi line 555.

Does that tell you anything?

I guess I'm missing a plugin, but I don't know which one. MeGUI did an update I did not actually want and caused a little havoc in my plugins folder. :mad:

no https://github.com/realfinder/AVS-Stuff/blob/24fd3d9394335bdc14e6fcc5678a8e83e898dd4f/avs%202.5%20and%20up/NotSMDegrain.avsi#L555

maybe your scripts/plugins outdated

[malze]

Is there any changes to Srestore or even 64-bit verison of this plugin

[kedautinh12]

You can read changes list from script
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Srestore.avsi

[malze]

Is this for 64-bit avisynth or mainly for 32-bit.

[kedautinh12]

Is this for 64-bit avisynth or mainly for 32-bit.

Both for x64 & x86

[StainlessS]

sRestore is a script, is uses/requires x86 plugins in 32 bit avisynth, and x64 plugins in 64 bit avisynth.

[malze]

Where is sRestore in the mediafire link as I am looking for it there.

[kedautinh12]

Just use my link i shared above

[malze]

How do I save the file as I copy it to the plugins folder it says error of the .avsi in AvsPmod.

[kedautinh12]

Just right click on "raw" and save as .avsi file

[real.finder]

idea for sanimebob2()

edic=nnedi3(-2)
istff=GetParity()
TFMbob = Interleave(TFM(field=istff ? 1 : 0, micmatching=0, mode=0, clip2=edic.selecteven()), TFM(field=istff ? 0 : 1, micmatching=0, mode=0, clip2=edic.selectodd()))
bobclip = stgmc(tr0=-2,useEdiExt=1,EdiExt=TFMbob,Sharpness=0,tr2=5, Refinemotion=true, fastma=true)
yadifmod2(mode=3, edeint=bobclip).Vinverse_avsi(custem=edic).Repair(TFMbob).slimit_dif2(bobclip,thr=4)

any Feedback? :rolleyes:

"custem" should be "custom", but I will replace it with clip2 in the next update anyway

[Ceppo]

Just thinking, why don't you make a plugin pack with all the dll you use and your avsi files? That would be so good for lazy people like me :)

Also, do you use TFM (which I no longer remember the parameters) for the comb detection method?

Also, I don't like yadifmod because it create artefacts, dunno if you ever saw them, but I kinda not like them.

[StainlessS]

why don't you make a plugin pack with all the dll you use and your avsi files?
+1 :)

[real.finder]

Just thinking, why don't you make a plugin pack with all the dll you use and your avsi files? That would be so good for lazy people like me :)

+1 :)

there are https://forum.doom9.org/showthread.php?t=181989 already, why I need another one? :confused:


Also, do you use TFM (which I no longer remember the parameters) for the comb detection method?

Also, I don't like yadifmod because it create artefacts, dunno if you ever saw them, but I kinda not like them.

you mean the "mi" or cthresh? anyway tfm is kinda confusing since most of it paramters not for field matching but for 60i things, so I like the idea you use it in ctools to put those in CPostProcessing not the CTelecineNew :goodpost:

yadifmod/yadifmod2 did artefacts yes, that why I use some filters after it, test and see yourself ;)

[StainlessS]

there are https://forum.doom9.org/showthread.php?t=181989 already, why I need another one?
Oops, yes.
For me, its the never ending changes to scripts and not knowing what is needed for single script update.

I'm not so bothered bout dll's, I dont want to change the dll's I use, categorised for different OS/Bitage/Hardware, and documented,
Way too many dll's got no version indicated at all.

[Ceppo]

there are https://forum.doom9.org/showthread.php?t=181989 already, why I need another one?

Sorry, I'm the kind of type that does everything fast, I'm very prone to error. :)

[real.finder]

idea for sanimebob2()

edic=nnedi3(-2)
istff=GetParity()
TFMbob = Interleave(TFM(field=istff ? 1 : 0, micmatching=0, mode=0, clip2=edic.selecteven()), TFM(field=istff ? 0 : 1, micmatching=0, mode=0, clip2=edic.selectodd()))
bobclip = stgmc(tr0=-2,useEdiExt=1,EdiExt=TFMbob,Sharpness=0,tr2=5, Refinemotion=true, fastma=true)
yadifmod2(mode=3, edeint=bobclip).Vinverse_avsi(custem=edic).Repair(TFMbob).slimit_dif2(bobclip,thr=4)

any Feedback? :rolleyes:

"custem" should be "custom", but I will replace it with clip2 in the next update anyway

I made it as function with other additions

# sanimebob2 v1.2
function sanimebob2(clip i, int "stgmc_type", val "bobpresmooth", float "Str", float "Amp", bool "TV_range", int "tr2", bool "repblend", int "nnrep", string "tfm_params", int "NNSize", int "NNeurons", int "EdiQual", int "EdiMaxD", int "blockx", int "blocky", int "tfm_mi", bool "FastNnediHBD") {
sisphbd = AvsPlusVersionNumber > 2294
SBitsn = sisphbd ? i.BitsPerComponent() : 8
FastNned = Default(FastNnediHBD, SBitsn > 8)
nnrep = default (nnrep, 2)
stgmc_type = default (stgmc_type, 0)
tfm_params = default(tfm_params, "")
Str = default (Str, 1.5)
tr2 = default (tr2, stgmc_type==0 ? 5 : 2)
blockx=default (blockx, stgmc_type == 0 ? 16 : 8)
blocky=default (blocky, stgmc_type == 0 ? 16 : 8)
tfm_mi = default (tfm_mi, stgmc_type == 0 ? 40 : 30)
STGMC_lsb = sisphbd ? SBitsn > 8 ? false : true : true
STGMC_n16 = STGMC_lsb && AvsPlusVersionNumber < 3382
STGMC_lsb = STGMC_n16 ? false : STGMC_lsb
istff=GetParity(i)
ii = FastNned ? i.convertbits(8, dither=1) : i
prefiltered_i = defined(bobpresmooth) ? isclip(bobpresmooth) ? bobpresmooth : IsString(bobpresmooth) ? Eval("i." + bobpresmooth) : undefined() : undefined()
iforbob = defined(prefiltered_i) ? prefiltered_i : ii.sh_bob(0,0.5).reduceflicker(strength=2).interlaced60or50(BFF=!istff)
iforbob = !defined(prefiltered_i) ? iforbob.SeparateFields().Repair(ii.SeparateFields()).weave() : iforbob
threads = sh_GetUserGlobalIMTint()
ib = FastNned ? i.sh_bob(0,0.5) : i
pni = iforbob.sh_Padding(2,4,2,4,threads=threads).nnedi3(-2, nsize=NNSize, nns=NNeurons, qual=EdiQual,threads=threads).crop(2,4,-2,-4,true)
ei = ii.eedi3(-2, mdis=EdiMaxD,sclip=pni,threads=threads)
pni = FastNned ? ib.slimit_dif(pni.convertbits(SBitsn), thr=1, elast=1.5) : pni
ei = FastNned ? ib.slimit_dif(ei.convertbits(SBitsn), thr=1, elast=1.5) : ei
ei = nnrep > 0 ? nnrep > 1 ? ei.slimit_dif2(pni,thr=4) : ei.Repair(pni,9) : ei

TFMbob = eval("Interleave(i.TFM(field=istff ? 1 : 0, micmatching=0, mode=0, blockx=blockx, blocky=blocky, mi=tfm_mi, clip2=ei.selecteven()" + tfm_params + "), i.TFM(field=istff ? 0 : 1, micmatching=0, mode=0, blockx=blockx, blocky=blocky, mi=tfm_mi, clip2=ei.selectodd()" + tfm_params + "))")
bobclip = stgmc_type == 0 ? i.stgmc(tr0=-2,useEdiExt=1,EdiExt=TFMbob,Sharpness=0, Refinemotion=true, fastma=true, lsb=STGMC_lsb, n16=STGMC_n16, TV_range=TV_range, Str=Str, Amp=Amp, tr2=tr2, EdiThreads=threads) : i.stgmc(useEdiExt=2,EdiExt=TFMbob,Sharpness=0,tr2=2,ESearchP=true, Refinemotion=true, fastma=true, lsb=STGMC_lsb, n16=STGMC_n16, TV_range=TV_range, Str=Str, Amp=Amp, tr2=tr2, EdiThreads=threads)
i.sh_Padding(0,4,0,4,threads=threads).yadifmod2(mode=3, edeint=bobclip.sh_Padding(0,4,0,4,threads=threads)).Vinverse_avsi(clip2=ei.sh_Padding(0,4,0,4,threads=threads)).Repair(TFMbob.sh_Padding(0,4,0,4,threads=threads)).slimit_dif2(bobclip.sh_Padding(0,4,0,4,threads=threads),thr=4).crop(0,4,-0,-4,true)
}

edit: update

# sanimebob2 v1.3
function sanimebob2(clip i, int "stgmc_type", val "bobpresmooth", float "Str", float "Amp", bool "TV_range", int "tr2", bool "repblend", int "nnrep", string "tfm_params", int "NNSize", int "NNeurons", int "EdiQual", int "EdiMaxD", int "blockx", int "blocky", int "tfm_mi", bool "FastNnediHBD") {
sisphbd = AvsPlusVersionNumber > 2294
SBitsn = sisphbd ? i.BitsPerComponent() : 8
FastNned = Default(FastNnediHBD, SBitsn > 8)
nnrep = default (nnrep, 2)
stgmc_type = default (stgmc_type, 0)
tfm_params = default(tfm_params, "")
Str = default (Str, 1.5)
tr2 = default (tr2, stgmc_type==0 ? 2 : 5)
blockx=default (blockx, stgmc_type == 0 ? 16 : 8)
blocky=default (blocky, stgmc_type == 0 ? 16 : 8)
tfm_mi = default (tfm_mi, stgmc_type == 0 ? 40 : 30)
STGMC_lsb = sisphbd ? SBitsn > 8 ? false : true : true
STGMC_n16 = STGMC_lsb && AvsPlusVersionNumber < 3382
STGMC_lsb = STGMC_n16 ? false : STGMC_lsb
istff=GetParity(i)
ii = FastNned ? i.convertbits(8, dither=1) : i
prefiltered_i = defined(bobpresmooth) ? isclip(bobpresmooth) ? bobpresmooth : IsString(bobpresmooth) ? Eval("i." + bobpresmooth) : undefined() : undefined()
iforbob = defined(prefiltered_i) ? prefiltered_i : ii.sh_bob(0,0.5).reduceflicker(strength=2).interlaced60or50(BFF=!istff)
iforbob = !defined(prefiltered_i) ? iforbob.SeparateFields().Repair(ii.SeparateFields()).weave() : iforbob
threads = sh_GetUserGlobalIMTint()
ib = FastNned ? i.sh_bob(0,0.5) : i
pni = iforbob.sh_Padding(2,4,2,4,threads=threads).nnedi3(-2, nsize=NNSize, nns=NNeurons, qual=EdiQual,threads=threads).crop(2,4,-2,-4,true)
ei = ii.eedi3(-2, mdis=EdiMaxD,sclip=pni,threads=threads)
pni = FastNned ? ib.slimit_dif(pni.convertbits(SBitsn), thr=1, elast=1.5) : pni
ei = FastNned ? ib.slimit_dif(ei.convertbits(SBitsn), thr=1, elast=1.5) : ei
ei = nnrep > 0 ? nnrep > 1 ? ei.slimit_dif2(pni,thr=4) : ei.Repair(pni,9) : ei

TFMbob = eval("Interleave(i.TFM(field=istff ? 1 : 0, micmatching=0, mode=0, blockx=blockx, blocky=blocky, mi=tfm_mi, clip2=ei.selecteven()" + tfm_params + "), i.TFM(field=istff ? 0 : 1, micmatching=0, mode=0, blockx=blockx, blocky=blocky, mi=tfm_mi, clip2=ei.selectodd()" + tfm_params + "))")
bobclip = stgmc_type == 0 ? i.stgmc(tr0=-2,useEdiExt=1,EdiExt=TFMbob,Sharpness=0, Refinemotion=true, fastma=true, lsb=STGMC_lsb, n16=STGMC_n16, TV_range=TV_range, Str=Str, Amp=Amp, tr2=tr2, EdiThreads=threads) : i.stgmc(useEdiExt=2,EdiExt=TFMbob,Sharpness=0,ESearchP=true, Refinemotion=true, fastma=true, lsb=STGMC_lsb, n16=STGMC_n16, TV_range=TV_range, Str=Str, Amp=Amp, tr2=tr2, EdiThreads=threads)
i.sh_Padding(0,4,0,4,threads=threads).yadifmod2(mode=3, edeint=bobclip.sh_Padding(0,4,0,4,threads=threads)).Vinverse_avsi(clip2=ei.sh_Padding(0,4,0,4,threads=threads)).Repair(TFMbob.sh_Padding(0,4,0,4,threads=threads)).slimit_dif2(bobclip.sh_Padding(0,4,0,4,threads=threads),thr=4).crop(0,4,-0,-4,true)
}

# sanimebob2 v1.34
function sanimebob2(clip i, int "stgmc_type", float "Str", float "Amp", bool "TV_range", int "tr2", bool "repblend", int "nnrep", string "tfm_params", int "NNSize", int "NNeurons", int "EdiQual", int "EdiPscrn", int "EdiMaxD", float "EdiAlpha", float "EdiBeta", float "EdiGamma", int "blockx", int "blocky", int "tfm_mi", bool "FastNnediHBD") {
sisphbd = AvsPlusVersionNumber > 2294
SBitsn = sisphbd ? i.BitsPerComponent() : 8
FastNned = Default(FastNnediHBD, SBitsn > 8)
nnrep = default (nnrep, 0)
NNSize = Default(NNSize, nnrep==0 ? 2 : 1 )
NNeurons = Default(NNeurons, nnrep==0 ? 4 : 3)
EdiQual = Default(EdiQual, nnrep==0 ? 2 : 1)
EdiPscrn = Default(EdiPscrn, nnrep==0 ? 4 : 3)
EdiAlpha = Default(EdiAlpha, nnrep==0 ? 0.1 : 0.15)
EdiBeta = Default(EdiGamma, nnrep==0 ? 0.3 : 0.27)
EdiGamma = Default(EdiGamma, nnrep==0 ? 30.0 : 25.0)
stgmc_type = default (stgmc_type, 0)
tfm_params = default(tfm_params, "")
Str = default (Str, 1.5)
tr2 = default (tr2, stgmc_type==0 ? 2 : 5)
blockx=default (blockx, stgmc_type == 0 ? 16 : 8)
blocky=default (blocky, stgmc_type == 0 ? 16 : 8)
tfm_mi = default (tfm_mi, stgmc_type == 0 ? 40 : 30)
STGMC_lsb = sisphbd ? SBitsn > 8 ? false : true : true
STGMC_n16 = STGMC_lsb && AvsPlusVersionNumber < 3382
STGMC_lsb = STGMC_n16 ? false : STGMC_lsb
istff=GetParity(i)
ii = FastNned ? i.convertbits(8, dither=1) : i
threads = sh_GetUserGlobalIMTint()
ib = FastNned ? i.sh_bob(0,0.5) : i
pni = ii.sh_Padding(2,4,2,4,threads=threads).nnedi3(-2, nsize=NNSize, nns=NNeurons, Pscrn=EdiPscrn, qual=EdiQual,threads=threads).crop(2,4,-2,-4,true)
ei = ii.eedi3(-2, mdis=EdiMaxD,Alpha=EdiAlpha,Beta=EdiBeta,Gamma=EdiGamma,sclip=pni,threads=threads)
pni = FastNned ? ib.slimit_dif(pni.convertbits(SBitsn), thr=1, elast=1.5) : pni
ei = FastNned ? ib.slimit_dif(ei.convertbits(SBitsn), thr=1, elast=1.5) : ei
ei = nnrep > 0 ? nnrep > 1 ? ei.slimit_dif2(pni,thr=4) : ei.Repair(pni,9) : ei

TFMbob = eval("Interleave(i.TFM(field=istff ? 1 : 0, micmatching=0, mode=0, blockx=blockx, blocky=blocky, mi=tfm_mi, clip2=ei.selecteven()" + tfm_params + "), i.TFM(field=istff ? 0 : 1, micmatching=0, mode=0, blockx=blockx, blocky=blocky, mi=tfm_mi, clip2=ei.selectodd()" + tfm_params + "))")
TFMbobsm=TFMbob.Blur(1.58,0)
bobclip = stgmc_type == 0 ? i.stgmc(tr0=-2,useEdiExt=1,EdiExt=TFMbob.slimit_dif2(ei,TFMbobsm.Vinverse(),thr=5,fltref=TFMbobsm,elastinfl=true),Sharpness=0, Refinemotion=true, fastma=true, lsb=STGMC_lsb, n16=STGMC_n16, TV_range=TV_range, Str=Str, Amp=Amp, tr2=tr2, EdiThreads=threads) : i.stgmc(useEdiExt=2,EdiExt=TFMbob.slimit_dif2(ei,TFMbobsm.Vinverse(),thr=5,fltref=TFMbobsm,elastinfl=true),Sharpness=0,ESearchP=true, Refinemotion=true, fastma=true, lsb=STGMC_lsb, n16=STGMC_n16, TV_range=TV_range, Str=Str, Amp=Amp, tr2=tr2, EdiThreads=threads)
TFMbob.Vinverse(clip2=bobclip).slimit_dif2(bobclip,thr=4,fltref=TFMbobsm)
}

[Ceppo]

I'm waiting for a sunny day so that I can add the block-based comb detection for the mouth problem so that TFM calls disappear :D

If you will like it of course. :p

[real.finder]

I'm waiting for a sunny day so that I can add the block-based comb detection for the mouth problem so that TFM calls disappear :D

If you will like it of course. :p

nice, I will see how block-based will work for the field matching since tfm seems use it only for clip2

[Tempter57]

real.finder

AnimeIVTC.avsi v.2.386 line 797
useBWDIF ? yadifclip.vinverse(clip2=yadifclip.smam(filter=daa3mclip,repblend=repblend)) : yadifclip.smam(filter=daa3mclip,repblend=repblend)

It is necessary to correct on
useBWDIF ? yadifclip.vinverse_avsi(clip2=yadifclip.smam(filter=daa3mclip,repblend=repblend)) : yadifclip.smam(filter=daa3mclip,repblend=repblend)

[kedautinh12]

You need download Asd-g's vinverse to use AnimeIVTC v2.386
https://github.com/Asd-g/vinverse/releases

[LeXXuz]

I've noticed that in (Not)SMDegrain LSFMod is used with limit=0, soothe=false and keep=0.

Doesn't this kinda defeat the purpose of a limited sharpener?

Just trying to understand why it is used here in that way. :)

[real.finder]

I've noticed that in (Not)SMDegrain LSFMod is used mit limit=0, soothe=false and keep=0.

Doesn't this kinda defeat the purpose of a limited sharpener?

Just trying to understand why it is used here in that way. :)

it's better to ask Dogway (https://forum.doom9.org/showthread.php?t=182881) since I only did some mods to it :) but I think it used as contra-sharpening not as just limited sharpener (you may want to read from this (https://forum.doom9.org/showthread.php?p=1807637&highlight=lsfmod#post1807637) up to #83)

[LeXXuz]

it's better to ask Dogway (https://forum.doom9.org/showthread.php?t=182881) since I only did some mods to it :) but I think it used as contra-sharpening not as just limited sharpener (you may want to read from this (https://forum.doom9.org/showthread.php?p=1807637&highlight=lsfmod#post1807637) up to #83)
I'll ask Dogway about that. Just read the posts you've linked in your message. Have there been some bigger changes to the Contrasharpening routine since then?

Because this makes me wonder:
From the help file:

Contrasharp.
In the other hand if your parameter input is an integer, LSFmod() will be used instead. It will be much slower, but maybe better for certain sources. Its value will serve as a contrasharpening multiplier, use one around 50 for similar strength as Contrasharpening().
see: https://forum.doom9.org/showthread.php?p=1807647#post1807647

After quite a lot of testing I'm very positive right now that even contrasharp=100 sharpens the image less than contrasharp=true. File sizes are always noticeably larger with contrasharp(=true) than with LSFmod(contrasharp=100). :confused:

From the notes it reads like contrasharp() is the quicker/faster way than using LSFmod as a contrasharpener while LSFmod may provide better quality. Is that correct?

[Dogway]

Yes, that's it, contrasharpening doesn't need limiting mode as the contrasharpening routine already does the limiting.

It might be possible that contrasharp=50 sharpens less than contrasharp=true. I only tested a few examples, but I always prefer to err on the low side just in case.

[LeXXuz]

Thanks for the clarification Dogway :thanks:

I guess I'll stay with LSFmod as contrasharpener then if it is supposed to have a better quality, even if just marginal.

With the current latest version of LSFmod, SMDegrain is even faster than with "contrasharp=true".

Here is a short speed and file size comparison:
https://abload.de/thumb/screenshot2022-03-2719tkds.png (https://abload.de/image.php?img=screenshot2022-03-2719tkds.png)

Left: contrasharp=true
Middle: contrasharp=100 (with default settings of LSFmods slow preset; lmode=4, soothe=true, keep=20)
Right: contrasharp=100 (with SMDegrains default settings for LSFmod; lmode=0, soothe=false, keep=0)

[LeXXuz]

Out of curiosity: what happens if values >100 are used?

LSFmod supports it but SMDegrain has a range of 0-100. Yet, I get no error with values over 100.

[PoeBear]

GrainFactory3 (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/GrainFactory3.avsi)

GrainFactory3mod (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/GrainFactory3mod.avsi)

Is there a way to use one of these plugins with some sort of black screen detection? Without having to merge Trim()s or use ConditionalFilter. Like an "if colorrange=0 then don't run GrainFactory3.avsi"

I'm encoding some MPEG-2 stuff, and it's pretty rough quality, so I add grain to even out the image sometimes. But on my heavier/higher grain setting encodes, the black screens or commercial breaks end up eating a lot of bitrate in CRF mode. After loading up Bitrate Viewer, I noticed some seemingly random bitrate spikes, then tracked down the time in AvsPMod, and sure enough, it was because GrainFactory is adding grain to those sections as part of it's g1str parameter (makse sense)

x264 obviously tries to preserve the grain, but it's so dark it just eats and spikes the bitrate, so I'd love to kill the plugin when it detects 99% black or something like that. Some of the movies/shows have a lot of points that I'd rather not have to skip through to Trim() manually

[real.finder]

Is there a way to use one of these plugins with some sort of black screen detection? Without having to merge Trim()s or use ConditionalFilter. Like an "if colorrange=0 then don't run GrainFactory3.avsi"

I'm encoding some MPEG-2 stuff, and it's pretty rough quality, so I add grain to even out the image sometimes. But on my heavier/higher grain setting encodes, the black screens or commercial breaks end up eating a lot of bitrate in CRF mode. After loading up Bitrate Viewer, I noticed some seemingly random bitrate spikes, then tracked down the time in AvsPMod, and sure enough, it was because GrainFactory is adding grain to those sections as part of it's g1str parameter (makse sense)

x264 obviously tries to preserve the grain, but it's so dark it just eats and spikes the bitrate, so I'd love to kill the plugin when it detects 99% black or something like that. Some of the movies/shows have a lot of points that I'd rather not have to skip through to Trim() manually

try them with https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/AdaptiveGrain.avsi

[LeXXuz]

Is there a reliable and fast filter for just automatically fixing phase/field shifts in progressive PAL DVD sources?

Very very long time ago I had a filter named something like DeinterlacerAutoPAL or similar. I remember it did a terrific job when I was capturing my old VHS tapes about 20 years ago.

I tried QTGMC, (N)NEDI, yadif and decomb so far. All with more or less satisfactory results. The first two process the picture way too much and the latter two missed quite a lot of scenes.

Btw what does QTGMC do on a progressive frame? Will it get processed or skipped?

[Ceppo]

If you post a sample of your PAL source, I will try to suggest a solution.

[LeXXuz]

There's really nothing to show. Its just sources captured with a faulty encoder who randomly dropped fields here and there. So the captured frame consists of two fields belong to two different progressive source frames. Sadly this happens quite often on low budget DVD productions.

So they just encode this MPEG-2 interlaced and let the DVD player/decoder fix their dirty work. Well more or less.

[StainlessS]

LeXXuz,

Here an explanation of Phase Shifted (AKA Perverse) Telecine [click a 2nd time for magnified image].
https://i.postimg.cc/14MJpkkm/Perverse-TC.jpg (https://postimg.cc/14MJpkkm)

Taken from Scharfis_Brain Exotic Interlacing [originally in German],
see DATA Folder @ MediaFire in my sig below this post for PDF's in English or German.
[There is also a zip containing Web page]

EDIT: The Website is no longer online, but LigH posted a link to his saved copy somewhere.

EDIT: Original web page on WayBack Machine:- https://web.archive.org/web/20140411222900/http://home.arcor.de/scharfis_brain/ExotischesInterlacing/

And a thread I started on it (forgot about it) some time ago:- https://forum.doom9.org/showthread.php?t=176104&highlight=Exotic+Interlacing

EDIT: LigH hosted original web page in German:- https://www.ligh.de/scharfis_brain/ExotischesInterlacing/

[kedautinh12]

You just say alone and don't have any helper when you don't share any samples :D

[LeXXuz]

LeXXuz,

Ah, I remember scharfis excellent guide. Thanks for posting this.

I give Telecide() another try then which should do exactly what I'm looking for. But I think I messed up a parameter. :o

You just say alone and don't have any helper when you don't share any samples :D

That is, of course, not my intention. :D:p;)

[Ceppo]

If I don't look at a sample, I can only speculate without empirical proof. And is quite pointless. But let's speculate.

Try:

CTelecine() #field matching
CPostProcessing() #Deinterlace leftover combed

[PoeBear]

try them with https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/AdaptiveGrain.avsi

Works perfectly, thanks! It kills all traces of the added GrainFactory3 grain near any completely black areas. FYI for other users in my predicament: You'll definitely want to Trim() this out for end credits, as it will still apply near the scrolling text, giving you a grain fade out that will definitely cost in CRF over using without

Follow up (basic AviSynth usage) question, but I can't seem to insert AdaptiveGrain in the middle of a script with line breaks, I can only call it without line breaks (or at the end). I'm not sure of what script magic to fix it, it's a new error to me. Eg

Works:
MPEG2Source("D:\Edit\DVD\ntscDVD.d2v")
TFM()
TDecimate()
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0)
z_Spline36Resize(1440,1080)
AdaptiveGrain(grain=GrainFactory3(g1str=1, g2str=2, g3str=3))
z_Spline36Resize(640,480)

Fails ("Script error: invalid arguments to function 'GrainFactory3'"):
MPEG2Source("D:\Edit\DVD\ntscDVD.d2v").\
TFM().\
TDecimate().\
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0).\
z_Spline36Resize(1440,1080).\
AdaptiveGrain(grain=GrainFactory3(g1str=1, g2str=2, g3str=3)).\
z_Spline36Resize(640,480)

It works fine with line breaks with just GrainFactory3:
MPEG2Source("D:\Edit\DVD\ntscDVD.d2v").\
TFM().\
TDecimate().\
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0).\
z_Spline36Resize(1440,1080).\
GrainFactory3(g1str=1, g2str=2, g3str=3).\
z_Spline36Resize(640,480)

Ideally I need to use the line breaks so I can load the source once, but have separate filter areas for the main movie and the filter-less credits and make calls back-and-forth with Trim()s

[LigH]

I don't see the advantage of explicitly chaining all the function calls instead of implicitly chaining them via the omittable "last" clip (which will fail if there is any assignment to variables in this sequence, not all function calls only) ... nevertheless, an interesting find. A fix will require some insight in the parser.

To provide different filter sequences for scenes, I would recommend declaring user functions. Their declaration may contain sequences without explicit chains. But I don't get your intent completely yet. You will know if that idea is feasible.

[LeXXuz]

If I don't look at a sample, I can only speculate without empirical proof. And is quite pointless. But let's speculate.

Try:

CTelecine() #field matching
CPostProcessing() #Deinterlace leftover combed


I don't know these two functions. To what plugin do they belong to? :confused:

[LigH]

See the CQTGMC thread (https://forum.doom9.org/showthread.php?t=183823) => https://github.com/CeppoTools/CTools

@Ceppo: Add these to your signature?

[LeXXuz]

:thanks: LigH

Downloaded latest package, but I can't get it to work. MeGUI crashes instantly (and sadly without an error message) upon loading this script:

#
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\CTools v1.2.2 (x86_x64)\x64\CTools.dll")
Import("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\CTools v1.2.2 (x86_x64)\CTools.avsi")
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\QTGMC.avsi") #v3.33
#
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("G:\WORK\dvdsource.mkv")
#
CTelecine() #field matching
CPostProcessing() #Deinterlace leftover combed


Avisynth+ 3.7.2 x64 used. What do I miss?

[PoeBear]

I don't see the advantage of explicitly chaining all the function calls instead of implicitly chaining them via the omittable "last" clip (which will fail if there is any assignment to variables in this sequence, not all function calls only) ... nevertheless, an interesting find. A fix will require some insight in the parser.

I wasn't looking for any advantage, I just wrote the script best I could, trying to keep it as readable and clean/low memory as possible. Maybe a non-sample script will help. Here's an HD script that I would ideally replace the one GrainFactory3 call with AdaptiveGrain+GrainFactory3 instead (if someone can help with a fix/replacement script):

BLU=LWLibavVideoSource("C:\Edit\Any\title01.mkv").\
bbmod(1,0,1,0)

MOVIE=BLU.\
z_Spline36Resize(1280,720).\
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0).\
z_Spline36Resize(1920,1080).\
GrainFactory3(g1str=8, g2str=12, g3str=18, g1size=1.8, g2size=1.6, g3size=1.4).\
z_Spline36Resize(1280,720)

CREDITS=BLU.\
z_Spline36Resize(1280,720).\
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0)

OUTPUT=\
BlankClip(length=24,width=1280,height=720,fps=24000,fps_denominator=1001,pixel_type="YV12").KillAudio+\
MOVIE.Trim(0,127475)+\
CREDITS.Trim(127476,0)+\
BlankClip(length=48,width=1280,height=720,fps=24000,fps_denominator=1001,pixel_type="YV12").KillAudio

OUTPUT

It's never given me any issues with the dozen or so other plugins from this page I also use. If I'm doing something wrong, or I can streamline it even more (while still making sense when looking at it lol), please let me know. I've just taken bits and pieces from what I've seen on here or the wiki, and breaking up all the functions helps me when I'm adding/removing/replacing/comparing to the same script but with 1 or 2 variables different. Or sometimes the second half of the movie has a different crop or some dirty lines, so I can make a MOVIE2 call with different crops/fixes, and just merge them at the end

Pay no attention to my many resizes. I find even GrainFactory3's softest grain is too sharp in certain instances, so I always apply it at a higher resolution than my output (and I resize it first because that deblocks better than QED Deblock_QED, a cleaner source I wouldn't resize first). The rest of the trims are 1) because I don't want to grain the credits 2.) I was making one of my Blu-rays frame accurate with my DVD that had 5.1 and needed blank frames

But I don't get your intent completely yet.

When GrainFactory3 is left to its own devices, it ends up applying grain to fade-in and fade-outs, which ends up eating a lot of bitrate in x264/x265 CRF mode. But with AdaptiveGrain, it detects black areas and won't apply grain to them, so fade outs will cost next to nothing

It can also affect really dark movies (like the movie in my script example). If a scene takes place at night, and a lot of the image is dark and wouldn't normally have grain, AdaptiveGrain seems to help not apply it there, letting you use the bitrate for other areas of the image

My intent is to fix my script so it loads and I can make my encode smaller :D

[kedautinh12]

:thanks: LigH

Downloaded latest package, but I can't get it to work. MeGUI crashes instantly (and sadly without an error message) upon loading this script:

#
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\CTools v1.2.2 (x86_x64)\x64\CTools.dll")
Import("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\CTools v1.2.2 (x86_x64)\CTools.avsi")
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\QTGMC.avsi") #v3.33
#
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("G:\WORK\dvdsource.mkv")
#
CTelecine() #field matching
CPostProcessing() #Deinterlace leftover combed


Avisynth+ 3.7.2 x64 used. What do I miss?

You missing RgTools, MVTools2, MaskTools2

[LeXXuz]

That's what happens when you remove too much for visibility. :p

They are present in the original script. Still crashes instantly with this script though:
#
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\CTools v1.2.2 (x86_x64)\x64\CTools.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\masktools2-v2.2.26\x64_clang\masktools2.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\mvtools-2.7.44\x64\mvtools2.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\RgTools-v1.1\x64_LLVM_build\RgTools.dll")
Import("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\CTools v1.2.2 (x86_x64)\CTools.avsi")
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\QTGMC.avsi") #v3.33
#
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("G:\WORK\source.mkv")
#
CTelecine() #field matching
CPostProcessing() #Deinterlace leftover combed

:o:(

[Ceppo]

@Ceppo: Add these to your signature?
I don't understand how to do that. I passed 2 minutes trying then I gave up :D

@LeXXuz
You lack vinverse.dll, https://github.com/Asd-g/vinverse/releases
Also, be sure to have all QTGMC stuff.

(It should give you an error saying that vinverse.dll was not found tho...)
EDIT:
Also, you should remove the filters one by one to understand which one makes you script crash, also see if it loads with AvspMod.

[LeXXuz]

@LeXXuz
You lack vinverse.dll, https://github.com/Asd-g/vinverse/releases
Also, be sure to have all QTGMC stuff.


That did it. Didn't know it was needed. Maybe add this to the docs of CTools? Or did I overlook it? :confused:

Sadly most of the time MeGUI prefers to crash instead of giving a useful error message...

[Ceppo]

The doc says that mode=5 (default) uses vinverse, and it should give you a error if you don't have it, never used MeGui so I don't know :)

[LeXXuz]

The doc says that mode=5 (default) uses vinverse, and it should give you a error if you don't have it, never used MeGui so I don't know :)

My bad. Must've overlooked it. Thanks for the help. :)

[LigH]

@Ceppo: Edit your signature (https://forum.doom9.org/profile.php?do=editsignature) to something like:

CQTGMC thread (https://forum.doom9.org/showthread.php?t=183823) / CeppoTools on github (https://github.com/CeppoTools/CTools)

[Ceppo]

Did it, thank you. :)

[LeXXuz]

NotSMDegrain (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/NotSMDegrain.avsi) my old SMDegrain mod



Is there a 'new' one? :confused:

[LeXXuz]

If I don't look at a sample, I can only speculate without empirical proof. And is quite pointless. But let's speculate.

Try:

CTelecine() #field matching
CPostProcessing() #Deinterlace leftover combed


Just to let you know; I did quite a few jobs with some very nasty PAL-DVDs in the meantime and your filters did a terrific job! :thanks:

[kedautinh12]

Is there a 'new' one? :confused:

New is Dogway's ver

[Blankmedia]

Hi, thank you for your work.

I don't know if this have been discussed before, but do you think you could add an ID for feedback in Stab3, like the avs filename (RT_FilenameSplit(string filename,int "get"=4) I think*)

So if multiple script are in the same folder they can be run simultan... at the same time, without trouble.

I've just checked and since ID in feedback only use integer, maybe the time the script is started? I really don't have much suggestion, but I think it would be neat.

Maybe there's a function to convert string to binary. So when you run the same script it overwrite the file (like it's doing rigth now) and doesn't make more and more files.

[StainlessS]

but do you think you could add an ID for feedback in Stab3, like the avs filename (RT_FilenameSplit(string filename,int "get"=4) I think*)

FN_NAME_ONLY = RT_FilenameSplit(FN,get=4) # Name node only, no path, no extension

[Blankmedia]

FN_NAME_ONLY = RT_FilenameSplit(FN,get=4) # Name node only, no path, no extension

Thanks StainlessS but I think the feedback plugin only takes integer for argument.

Feedback
========

Feedback is a pair of filters that allow the output of a filter chain to be
passed back as an input, further up the chain, to be used in outputting the next
frame of the chain.

For example, it can be used to fill in the empty areas of a stablised clip by
compositing in the previous output frame (which itself will have been composited
using Feedback).

Usage
=====

FeedbackInput(
(clip),
(int) id
)

FeedbackOutput(
(clip),
(int) id
)

FeedbackInput will return frame 0 of its input clip as frame 0 of its output,
but after that it returns frame n-1 of the associated FeedbackOutput clip.

FeedbackOutput sets a clip as a source for a FeedbackInput clip.

The id parameter is optional, but must be given unique values whenever there is
more than one FeedbackInput/FeedbackOutput set in a script environment.

I tried, but maybe incorrectly.

function Stab31 (clip clp, int "ts", int "range", int "dxmax", int "dymax", bool "UVfix", bool "FixFalPos", float "zoom", int "mirror", float "PAR", clip "Prefilter", int "Luma_Exp", int "FillBorder", clip "FalPosclip", bool "use_ExInpaint", bool "use_InpaintDelogo", bool "use_Feedback", string "the_path") {

ts = default(ts, 7) #frames to temporal average for better motion estimation (max. 7)
range = default(range, 1) #frames before/after to estimate motion
dxmax = default(dxmax, Round(clp.width()/180.0)) #maximum deviation in pixels
dymax = default(dymax, dxmax) #x, and y should be the same
zoom = default(zoom, 1) #maximum zoom factor (1 disabled)
u_feed = default(use_Feedback, false)
mirror = default(mirror, u_feed ? 15 : 0) #Edge filling. 0 off, 15 everything on
PAR = default(PAR, 1.0) #PAR of your source
UVfix = default(UVfix, false) # Fixes the bug of change of HUE in Depan, not need in depan 1.13.1 and up
bfix = default(FillBorder, u_feed ? 2 : 1) # 1=Fixes borders of 3 or less pixels wide.
u_ExIn = default(use_ExInpaint, false)
u_InDe = default(use_InpaintDelogo, u_feed)
b3fix = bfix > 0
FixFalPos = default(FixFalPos, true) # Fixes borders of 3 or more pixels wide. Use along crop(2,2,-2,-2)...
# ...after stab2() to get rid of border issues entirely
Lumae = default(Luma_Exp, 1) #Luma Rebuild

Pref = Defined(Prefilter) ? Prefilter : clp
temp = Pref.TemporalSoften(ts,255,255,25,2) # SC thr to 25 otherwise pans will stutter
rep = temp.Repair(Pref.TemporalSoften(1,255,255,25,2))
inter = Interleave(rep,Pref)

FN_NAME_ONLY = RT_FilenameSplit(the_path,get=4)

# temporal stable auto-contrast (better subpixel detection)
Luma_Expa = Lumae==2 ? AutoAdjust(inter,temporal_radius=10,auto_balance=false,auto_gain=true,use_interp=true,\
avg_safety=0.25,dark_limit=10,bright_limit=10,gamma_limit=1.0,dark_exclude=0.05,bright_exclude=0.05,\
chroma_process=0,scd_threshold=16,input_tv=false,output_tv=false,high_bitdepth=false,debug_view=false) : \
Lumae==1 ? inter.ColorYUV(levels="TV->PC") : inter

mdata = DePanEstimate(Luma_Expa,range=range,pixaspect=PAR,trust=0,dxmax=dxmax,dymax=dymax,zoommax=zoom)

DePan(Defined(Prefilter)?Interleave(rep,clp):inter,data=mdata,offset=-1,mirror=b3fix ? 0 : mirror,pixaspect=PAR,matchfields=false,subpixel=2)
SelectEvery(2,0)

stabclip=last
FalPosclip = !defined(FalPosclip) && FixFalPos && mirror==15 && b3fix ? clp : FalPosclip

# from depansafe() function
b3fix && defined(FalPosclip) ? FalPosclip : FixFalPos ? eval("""
thick = b3fix ? 3.0 : 2.0 # removing >2px wide borders
cropx = dxmax*2
ratiox = "YPlaneMax("+string(ceil(99-thick/cropx*100))+")"

crop(0,0,0,cropx).conditionalfilter(last,clp,ratiox,">","0")
crop(0,height-cropx,0,0).conditionalfilter(last,clp,ratiox,">","0")
crop(0,0,cropx,0).conditionalfilter(last,clp,ratiox,">","0")
crop(width-cropx,0,0,0).conditionalfilter(last,clp,ratiox,">","0")""") : last

subsampl = b3fix ? AvsPlusVersionNumber > 2294 ? !(clp.is444() || clp.isy()) : VersionNumber() < 2.60 ? clp.isyv12() : !(clp.isyv24() || clp.isy8()) : nop()

bfixc = bfix > 0 ? stabclip.FillBorders_stabi(pad=subsampl && mirror!=15 ? 1 : 0,subsample=subsampl,FixFalPos=defined(FalPosclip) || FixFalPos ? last : Undefined, mirror=mirror==15,PAR=PAR, maskonly=bfix > 1) : last
stabbclp = bfix > 1 && u_feed ? BlankClip(bfixc,color_yuv=$000000) : nop()
stabclpa1 = bfix > 1 && u_feed ? stabclip.SCSelect(stabbclp,bfixc,bfixc).ExtractY().Invert() : nop()
stabclpa2 = bfix > 1 && u_feed ? stabclip.SCSelect(stabbclp,stabbclp,bfixc).ExtractY().Invert() : nop()
# stabclip = bfix > 1 && u_feed ? Layer(stabclip.AddAlphaPlane(stabclpa1).FeedbackInput(clp.AddAlphaPlane(stabclpa1), id=FN_NAME_ONLY).FeedbackOutput(id=FN_NAME_ONLY)) : stabclip
stabclip = bfix > 1 && u_feed ? Layer(stabclip.AddAlphaPlane(stabclpa1).FeedbackInput(id=FN_NAME_ONLY), clp.AddAlphaPlane(stabclpa1)).FeedbackOutput(id=FN_NAME_ONLY) : stabclip
stabclip = bfix > 1 && u_feed ? stabclip.RemoveAlphaPlane() : stabclip
preclip = mt_merge(stabclip,clp,bfixc,luma=true)
preclip = bfix > 1 && u_feed ? mt_merge(stabclip,preclip,stabclpa2,luma=true).repair(preclip) : preclip
bfix > 1 ? stabclip.FillBorders_stabi(pad=subsampl && mirror!=15 ? 1 : 0,subsample=subsampl,FixFalPos=defined(FalPosclip) || FixFalPos ? last : Undefined, mirror=mirror==15,PAR=PAR, FillBordersc=u_ExIn ? preclip.ExInpaint(bfixc.mt_lut(u=-255,v=-255)) : u_InDe ? preclip.InpaintDelogo(mask=bfixc, Loc="0,0,0,0",dPP=0,dPPm=1,diPP=1,diPPm=0,oPP=1,oPPm=0,Inflate=0) : preclip.InpaintLogo(bfixc)) : bfixc
bfix > 1 && u_feed ? mt_merge(stabclip,last,stabclpa2.sh_Padding(2,2,2,2).mt_expand().crop(2,2,-2,-2),luma=true).repair(preclip) : last

UVfix ? eval("""
lumaf=last
clpDith=Dither_convert_8_to_16()

ScriptClip ("
blue=round((AverageChromaU(clp) - AverageChromaU()) * 256.0)
red=round((AverageChromaV(clp) - AverageChromaV()) * 256.0)

SmoothTweak16(clpDith,saturation=1.0,hue1=min(384,blue),hue2=min(384,red),HQ=true)
DitherPost(stacked=true,prot=false,mode=6,y=1,slice=false)
", args="clp,clpDith" )
Mergeluma(lumaf)
""") : last

}

In this script :


MPEG2Source (chemin, idct=5)
# RequestLinear(clim=100)
RoboCrop(LeftAdd=2, TopAdd=0, RightAdd=0, BotAdd=0)
Scomb(Decrawing=False, ntsccombmask=False)
# Convertbits(16)
A=STGMC( Preset="very slow",sourcematch=3, Sharpness=0.0, lossless=2 ).selecteven()
B=STGMC( Preset="very slow",sourcematch=3, Sharpness=0.0, lossless=2 ).selectodd()
C=Tfm(field=1,Mode=5,PP=2,cthresh=2,mthresh=2,clip2=A,micmatching=0,chroma=true,display=false, d2v=chemin, slow=2)
D=Tfm(field=0,Mode=5,PP=2,cthresh=2,mthresh=2,clip2=B,micmatching=0,chroma=true,display=false, d2v=chemin, slow=2)
Interleave(C,D)

Stab31(use_feedback=True, the_path=chemin)

I get this error in FFMPEG:

[avisynth @ 00000153a3375a00] Script error: Invalid arguments to function 'FeedbackInput'.
(D:/A encoder/avs_plugin_372/Stab31.avsi, line 68)
(simpsons_s02e01_p1_scomb3.avs, line 45)
simpsons_s02e01_p1_scomb3.avs: Unknown error occurred

[Blankmedia]

I messed up that line in stab31* :

stabclip = bfix > 1 && u_feed ? Layer(stabclip.AddAlphaPlane(stabclpa1).FeedbackInput(id=FN_NAME_ONLY), clp.AddAlphaPlane(stabclpa1)).FeedbackOutput(id=FN_NAME_ONLY) : stabclip

Now it's the "good" error code:

avisynth @ 000001fc10ed5a00] Script error: the named argument "id" to FeedbackInput had the wrong type
(D:/A encoder/avs_plugin_372/Stab31.avsi, line 69)
(simpsons_s02e01_p1_scomb3.avs, line 45)
simpsons_s02e01_p1_scomb3.avs: Unknown error occurred

It works if I put id=123

[StainlessS]

I only added that stuff so that Real.Finder would not have to look up what it did. (was not meant as any kind of solution)

[StainlessS]

OK, here extracts PartNo from multi-part Filename, only tested with given script.


Function GetMultipartFileNamePartNo(String FN) {
FN = RT_FilenameSplit(FN,get=4) # Name node only, no path, no extension eg, "FFMS_MultiPart_Source_PART_1"
RFN = RevStr(FN)
S="" # Init
C = RFN.MidStr(1,1)
While("0" <= C <= "9") {
S = C + S
RFN = RFN.MidStr(2)
C = RFN.MidStr(1,1)
}
Return Eval("0" + S)
}


FN = "FFMS_MultiPart_Source_PART_123.avs"

PartNo = GetMultipartFileNamePartNo(FN)
Assert(PartNo > 0, "Bad PartNo")

BlankClip
Subtitle("Got PartNo = " + String(PartNo))


Produces clip Subtitled with "123".

EDIT: Extracts the bit in RED as int.

EDIT: Added "0" +
in the Eval, ie Return Eval(S) to Return Eval("0" + S).

[Blankmedia]

This is a good idea

[dREV]

I wanted to ask if this script below from https://forum.doom9.org/showthread.php?p=1906222#post1906222 doesn't need an update to it after a year and many months of updates later? Thanks for sharing that script as I been using it since even now.

useDebilinearM=false #Depend on the source
nativeWidth=1504 #Depend on the source
nativeHeight=846 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true) : luma.ResizeX(nativeWidth,
nativeHeight,kernel="bicubic",a1=0,a2=1,dither_mode=0,desampling=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth,
outputHeight) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,kernel_u="blackman"src_top=0.0,src_left=0.50) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)

I tried adding LSB to it and seems to work with no issues useDebilinearM=false #Depend on the source
nativeWidth=1504 #Depend on the source
nativeHeight=846 #Depend on the source
outputWidth=1280 #Depend on what you need
outputHeight=720 #Depend on what you need
noDesample=(nativeWidth > outputWidth && nativeHeight > outputHeight) || (nativeHeight >= Height && nativeWidth >= Width)
luma=IsAvsPlus() ? ExtractY() : ConvertToY8()
chroma=Interleave(IsAvsPlus() ? ExtractU() : UToY8(), IsAvsPlus() ? ExtractV() : VToY8())
desampleluma=noDesample ? luma : useDebilinearM ? luma.DebilinearM(nativeWidth,nativeHeight, DeResizeMT=true,thr=01, lsb_inout=true) : luma.ResizeX(nativeWidth,
nativeHeight,kernel="bicubic",a1=0,a2=1,dither_mode=0,lsb_in=true,lsb_out=true,desampling=true) #you must set the correct kernel and the settings here (Depend on the source)
outputluma=!(noDesample || (nativeWidth != outputWidth || nativeHeight != outputHeight)) ? desampleluma : desampleluma.nnedi3_resize16(outputWidth,
outputHeight, lsb_in=true,lsb=true) #you can add another settings depend on what you need
outputchroma=chroma.nnedi3_resize16(outputWidth, outputHeight,0.50,kernel_u="blackman",src_top=0.0,src_left=0.50,lsb_in=true,lsb=true) #you can add another settings depend on what you need
YtoUV(outputchroma.SelectEven(),outputchroma.SelectOdd(),outputluma)

In addition, I wanted to ask if you think it doesn't need the "prefetch" and the "MT" parameter to take advantage of JPSDR's dll's like "ResampleMT" (https://github.com/jpsdr/ResampleMT/blob/master/ResampleMT%20-%20Readme.txt) to use "Spline36MT" instead of the regular "Spline36" or when using "DebilinearM" using "BicubicResizeMT" instead of "BicubicResize" and so on.

One more thing, does "nnedi3_resize16 (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.6%20and%20up/nnedi3_resize16.avsi)" use the "MT's" or take advantage of "ResampleMT"? I think you did this for "DebilinearM (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.6%20and%20up/DebilinearM.avsi)" to use "MT" in the script. Maybe I am wrong but seems to be "DeRMT". I just don't see it in "nnedi3_resize16" as I see "kernel_d = Default(kernel_d, "Spline36" " so I think it uses the normal "Spline36". You think it's fine the way it is? or could use an update or would that take too long?

[PoeBear]

try them with https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/AdaptiveGrain.avsi

Did this get merged into another package, or is there a better solution now?

[Reel.Deel]

Did this get merged into another package, or is there a better solution now?

It is now a plugin: https://github.com/Asd-g/AviSynth-AGM

[PoeBear]

It is now a plugin: https://github.com/Asd-g/AviSynth-AGM

Cheers! Now can someone smarter than I help me figure out how I would use AGM with GrainFactory3, a la "AdaptiveGrain(grain=GrainFactory3(..."? :D

[kedautinh12]

Cheers! Now can someone smarter than I help me figure out how I would use AGM with GrainFactory3, a la "AdaptiveGrain(grain=GrainFactory3(..."? :D

You need make a script wraper to use them

[PoeBear]

You need make a script wraper to use them

That seems... like a lot of extra work lol. The old one looked good enough to me with just a single line. Luckily I found a copy of it on gitlab (https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/blob/plugins_pack_r62/scripts/AdaptiveGrain.avsi), if anyone wants to try/compare/have an alternate solution/hold onto for posterity/etc

[StvG]

Cheers! Now can someone smarter than I help me figure out how I would use AGM with GrainFactory3, a la "AdaptiveGrain(grain=GrainFactory3(..."? :D

Like this:

MPEG2Source("D:\Edit\DVD\ntscDVD.d2v")
TFM()
TDecimate()
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0)
z_Spline36Resize(1440,1080)
AdaptiveGrain(grain=GrainFactory3(g1str=1, g2str=2, g3str=3))
z_Spline36Resize(640,480)

MPEG2Source("D:\Edit\DVD\ntscDVD.d2v")
TFM()
TDecimate()
neo_f3kdb(y=64, cb=64, cr=64, grainy=0, grainc=0)
z_Spline36Resize(1440,1080)
mt_merge(GrainFactory3(g1str=1, g2str=2, g3str=3), agm())
z_Spline36Resize(640,480)

[tormento]

I am getting error in maa2, i.e.

there is no function named sh_GetUserGlobalIMTint() function

present at line 61 as

threads = default(Threads, sh_GetUserGlobalIMTint())

How can I fix it, more than setting threads = 1? :)

The second error I get is

I don't know what AvsPlusVersionNumber means

"fixed" using sisphbd = true instead of sisphbd = AvsPlusVersionNumber > 2294

The third error is

I don't know what IsAVSPlus means

again "fixed" setting as true.

Help.

[LeXXuz]

real.finder's helper functions script "Zs_RF_Shared.avsi" installed?

[tormento]

real.finder's helper functions script "Zs_RF_Shared.avsi" installed?
Is it still needed? Oh man... will try ASAP.

[LigH]

It will probably always be needed since it was introduced. And always in a recent version.

[De-M-oN]

Why are dependencies never included in the downloads?
First this is missing, then the next is missing, then the next, then the next until I can finally run the script. This is a bit frustrating

[anton_foy]

Trying to understand the code of admfilter and the motionthresh part. Looks interesting for speed with the tiles 16x16. But it is only for scenchanges or for something more?


# MotionThresh by mf, mod by A.SONY
# Simple scenechange-proof motion threshold
# Tile outputs 16x16 clip for speed
# Use tile=true for conditional filtering, tile=false for masking

[real.finder]

Trying to understand the code of admfilter and the motionthresh part. Looks interesting for speed with the tiles 16x16. But it is only for scenchanges or for something more?

admfilter used mainly to make denoiser more aggressive in high motion, motionthresh part to pass how fast motion moving value but as an unified clip and that why it is 16x16 and it can be one pixel in nowadays avs+ for even faster

[anton_foy]

admfilter used manly to make denoiser more aggressive in high motion, motionthresh part to pass how fast motion moving value but as an unified clip and that why it is 16x16 and it can be one pixel in nowadays avs+ for even faster

Very good! For mvtools I guess this could be masking but for the opposite? Like more mdegrain in static areas and spatial filtering on higher motion? Must try it out anyway for deeper understanding.

[LouieChuckyMerry]

I realize the last post in this thread is a year old, but I'm wondering if anyone knows if SMDegrain is still being actively developed. Thanks for any help.

[DTL]

Latest SMDegrain updates were from Dogway at https://forum.doom9.org/showthread.php?t=182881 . And latest updates for quality of mvtools ME and some in MDegrainN are in the post-2.7.45 builds of mvtools (next release expected to be 2.8.0-a.00 because pinterf update 2.7.45 to 2.7.46 number in 2024 year keeping only old features of 2.7.45 ''classic' now) at https://forum.doom9.org/showthread.php?t=183517 . All new features typically disabled (as pinterf ask to keep as much compatibility with old scripts as possible) so to enable new processing modes and features you need to manually enable params of MSuper/MAnalyse/MDegrainN or even change script (like adding more processing paths and MAverage() MVs to make even more stable).

So it is expected in 202x years will be mvtools-classic 2.7.x bugfixes and may be performance only updates and finally 2.8.x with new features added (but may work less stable so script designers not like to use it until some very-very stable release in some (very-very unknown) future.

[LouieChuckyMerry]

DTL: Thank you for the information; I really appreciate it :) .

[real.finder]

Very good! For mvtools I guess this could be masking but for the opposite? Like more mdegrain in static areas and spatial filtering on higher motion? Must try it out anyway for deeper understanding.

I think mfilter in SMDegrain is what you need

[TCmullet]

I hope this is the appropriate place to report this. I started using QTGMC. One of it's requirements is Zs_RF_Shared.avsi. In QTGMC if I set EZDenoise to something greater than zero, one of the functions in Zs_RF_Shared.avsi tries to call FFT3DFilter. I get "Script error: There is no function named 'FFT3DFilter'. That function appears in more than one place in Zs_RF_Shared.avsi.

I assume if I get and install that filter in my plugins, the error will go away. Therefore whoever maintains
http://avisynth.nl/index.php/Zs_RF_Shared
should add that filter to the requirements for Zs_RF-Shared.avsi.

[LigH]

It's documented in http://avisynth.nl/index.php/QTGMC

[TCmullet]

It's documented in http://avisynth.nl/index.php/QTGMC
Oh I see now. I had skipped over "Optional plugins" as I was not intentionally opting for anything beyond what was required. I didn't realize that the "invisible magic engine" inside would made decisions to embrace options.

[real.finder]

been testing my new AutoBorderFiller() (https://github.com/realfinder/AVS-Stuff/blob/master/for%20AVSPlus/AutoBorderFiller.avsi) function

and seems I get a good results using
AutoBorderFiller()
bmasks=ExtractA().mt_inflate().TemporalSoften(3, 255, 255, 0, 2)
RemoveAlphaPlane().InpaintDelogo(mask=bmasks, Loc="0,0,0,0",Inflate=0)
mt_merge(last,TemporalSoften(3, 255, 255, 10, 2),bmasks,luma=true)

[rgr]

Vinverse_avsi (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Vinverse_avsi.avsi)

How is it different from the standard Vinverse?

[real.finder]

How is it different from the standard Vinverse?

Vinverse was just script function in the first place then tritical convert it to dll plugin backthen, anyway now https://github.com/Asd-g/vinverse should work similar to my mod of Vinverse_avsi

[real.finder]

been testing my new AutoBorderFiller() function

and seems I get a good results using

I did update AutoBorderFiller() and the code in quoted post of #909, now it's has better quality and stability than before

[HeadMD]

I'm trying your AutoBorderFiller and I'm getting an error "There is no function named 'bore_SinglePlane'." I've tried searching online but I'm not finding which plugin it's associated with. What am I missing?

EDIT. Figured out that I needed OpusGang Bore (https://github.com/OpusGang/bore). Now I have a different error: mt_merge: "luma" is unsupported in 422 and 444. I've tried converting to 420 and all kinds of other color formats.

[real.finder]

Now I have a different error: I've tried converting to 420 and all kinds of other color formats.

maybe your masktools2 is not updated?