real.finder's Avisynth Stuff

[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 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]

Originally Posted by 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 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?

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/HomeOfAviSynthPlu...iDeen/releases

[hello_hello]

Originally Posted by real.finder

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.



I thought it was some glitch on the site, as the main page displays normally.



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.

Originally Posted by real.finder

anyway, for DFMDeRainbow in avs 2.6 or plus you need minideen https://github.com/HomeOfAviSynthPlu...iDeen/releases

Ahh... the requirements at the top of the script only list Deen. That's better. Thanks.

[real.finder]

Originally Posted by hello_hello

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.



I thought it was some glitch on the site, as the main page displays normally.



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

Originally Posted by hello_hello

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]

Originally Posted by LigH

...only recent Firefox and Chrome (incl. Edge) display it well.

This one can help -> GitHub Web Components Polyfill (multiprocess (e10s) must be disabled).

[hello_hello]

Originally Posted by VoodooFX

This one can help -> GitHub Web Components 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.

[LigH]

Originally Posted by VoodooFX

This one can help -> GitHub Web Components Polyfill (multiprocess (e10s) must be disabled).

Works in Pale Moon as well as in Seamonkey

[VoodooFX]

Originally Posted by LigH

Works in Pale Moon as well as in Seamonkey

This one works for various websites and multiprocess -> 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]

Originally Posted by 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.

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]

Originally Posted by Boulder

It's best to convert to 16 bits

Too slow IMHO.

[Boulder]

Originally Posted by tormento

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]

Originally Posted by Boulder

Is this utilized in the SMDegrain port?

you can by using prefilter as clip

[real.finder]

Originally Posted by 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)

pinterf already answer this https://forum.doom9.org/showthread.p...51#post1855351

but anyway, 1st one is slower but maybe give a bit better output

[tormento]

Originally Posted by Boulder

How much is the difference between 10 and 16 bits?

PHP Code:

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

PHP Code:

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

PHP Code:

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]

Originally Posted by tormento

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]

Originally Posted by real.finder

#8bit source input

Please explain me why explicitely define prefilter is faster than implicitely use prefilter=4.