Avisynth Compatibility usage survey

[Myrsloik]

I'm curious if anyone actually uses the feature nowadays and if so, which parts of it.

[ChaosKing]

I think I used avsw.Eval() more often then avs.Loadplugin() in the past since I needed also some avs scripts.
If avsw.Eval() could support 64bit avisynth + HBD* then it would be the perfect replacement for the AVS Compatibility Layer. As far as I remember you don't need to have avisynth installed, setting the dll-path argument is enough.

* HBD is possible via the "Stack16" format, but native 16/32bit support would be nice.

[Myrsloik]

I think I used avsw.Eval() more often then avs.Loadplugin() in the past since I needed also some avs scripts.
If avsw.Eval() could support 64bit avisynth + HBD* then it would be the perfect replacement for the AVS Compatibility Layer. As far as I remember you don't need to have avisynth installed, setting the dll-path argument is enough.

* HBD is possible via the "Stack16" format, but native 16/32bit support would be nice.

You'd still get the IPC overhead with avsw though. I guess it's a tradeoff in the end. Did frame properties catch on in Avisynth yet?

[ChaosKing]

Yes, they are currently mostly implemented in scripts/plugins by pinterf and Asd-g.

For example:
https://github.com/Asd-g/AviSynthPlus-Scripts/blob/0ed568b3b995e00ba94ee8c9b4159ab266e81f45/GMSD.avsi#L94
https://github.com/AkarinVS/L-SMASH-Works/commit/711688689fe9a75c4ae9a12f0a599cf986794582

[Selur]

I usually use only native Vapoursynth plugins, but sometime use AutoAdjust, amDCT and CCD on YV12 content.

[DJATOM]

Sometimes I have to use avsw and avs for one single filter (that I was lazy enough to make native) — CullResize.

[Myrsloik]

Sometimes I have to use avsw and avs for one single filter (that I was lazy enough to make native) — CullResize.

I completely forgot about the avsw option. Also, stop being lazy.

[feisty2]

I still use the avisynth compatibility for frfun7 (http://avisynth.nl/index.php/Frfun7) to remove dot crawl, unfortunately I cannot port this plugin to vaporsynth because the source code was never released :(

[Myrsloik]

I still use the avisynth compatibility for frfun7 (http://avisynth.nl/index.php/Frfun7) to remove dot crawl, unfortunately I cannot port this plugin to vaporsynth because the source code was never released :(

Which version is the more relevant one? The one called rev6 or 2013? Such a small plugin should be fairly easy to reverse engineer and I have a great interest in dot crawl removal....

Disregard that. I'll just ask PrudeTree directly.

[kedautinh12]

If PrudeTree don't reply, will you make a plugin same frfun7???

[Myrsloik]

If PlumTree don't reply, will you make a plugin same frfun7???

Already got his reply. It's a plain NLM-denoiser unintentionally good at removing dot crawl. Not going to try to recreate it. Maybe I'll one day play around with this unintentionally useful method in my own dotkill filter.

[Reel.Deel]

Which version is the more relevant one? The one called rev6 or 2013? Such a small plugin should be fairly easy to reverse engineer and I have a great interest in dot crawl removal....

Disregard that. I'll just ask PrudeTree directly.

Frfun rev6 is better in terms of speed/quality. Prune no longer has the source code for that version, sadly. Not long after rev6 was released, the source code was modified, it added the "p" parameter along with internal changes, this version was released years after as the "2013" version. Unfortunately the output of rev6 and 2013 are not identical, to get the same quality as rev6 one has to set p=1 in the 2013 version, but it is much slower than the rev6 version.

Pinterf has a fully working x64 version after prune released the source code some months ago. I got really busy at some point and it delayed my testing. Anyways, an open source for frfun is right around the corner :)

[GMJCZP]

If this discussion involves a modernization of the Prunedtree plugin collection I am the first to support it, and if it is DualSynth it would be ideal.

Myrsloik is absolutely right that by reverse engineering the structure of each plugin can be deciphered.

If you ask Prunedtree a question and it doesn't answer, ask Soulhunter.

[Myrsloik]

If this discussion involves a modernization of the Prunedtree plugin collection I am the first to support it, and if it is DualSynth it would be ideal.

Myrsloik is absolutely right that by reverse engineering the structure of each plugin can be deciphered.

The problem is that both and I and PrunedTree agree that the modernization should be by writing new and better filters every time I ask him how some of his old creations work. Makes it hard to get motivated.

[feisty2]

I'm curious of how frfun7 works exactly, because we have plenty of NLMeans plugins out there and none of them is as effective as frfun7 in terms of dot crawl removal.

[GMJCZP]

The problem is that both and I and PrunedTree agree that the modernization should be by writing new and better filters every time I ask him how some of his old creations work. Makes it hard to get motivated.

I understand it, but being a regular user of several of those plugins for years I am reluctant to accept it entirely with the rebelliousness of a boy, don't get me wrong.

Although it is for historical purposes, the Prunedtree collection should last over time with some adjustment, even if it is with "a good coat of paint."

[lansing]

I only use it for its virtualdub plugin filter because there's no native vs plugin for that.

[pinterf]

Pinterf has a fully working x64 version after prune released the source code some months ago. I got really busy at some point and it delayed my testing. Anyways, an open source for frfun is right around the corner :)
Anyway, I made it now public, but please wait a bit until it really gets finished: https://github.com/pinterf/Frfun7/

[Tima]

I usually use only native Vapoursynth plugins, but sometime use AutoAdjust, amDCT and CCD on YV12 content.

Same story here.

I occasionally use AutoAdjust and amDCT, but can live without them (or just go Avisynth-only when I can't).

Basically, CCD is the only plugin that makes me to stick with AVS compat.

There was an (unfinished) conversion effort:
https://forum.doom9.org/showthread.php?t=182152

Source code of the original filter:
https://forum.doom9.org/showthread.php?p=1916925#post1916925

[kedautinh12]

Other people finish project
https://github.com/End-of-Eternity/vs-ccd/releases

[EoE]

Still working on vs-ccd, but I will look into doing AutoAdjust and amDCT at some point. Can someone link me to the most up to date versions for these in case they're burried somewhere?

[ChaosKing]

AutoAdjust is not opensource. See gdrive link for amDCT here https://forum.doom9.org/showthread.php?t=174433

[ChaosKing]

I still use the avisynth compatibility for frfun7 (http://avisynth.nl/index.php/Frfun7) to remove dot crawl, unfortunately I cannot port this plugin to vaporsynth because the source code was never released :(

Your prayers have been heard https://github.com/dubhater/vapoursynth-frfun7

[Selur]

Sadly there is no stable working RemoveDirt and no avaiable alternative to avsInpaint (hoping for a port of InpaintDelogo).

[Julek]

Sadly there is no stable working RemoveDirt and no avaiable alternative to avsInpaint (hoping for a port of InpaintDelogo).
You can inpainting in vapoursynth via OpenCV

Doc:
https://docs.opencv.org/4.x/df/d3d/tutorial_py_inpainting.html

Example:
https://github.com/WolframRhodium/muvsfunc/wiki/OpenCV-Python-for-VapourSynth#inpainting

[Selur]

@Julek: Thanks that looks interessting, may be posting InpaintDelogo is possible with this.

[VoodooFX]

You can inpainting in vapoursynth via OpenCV

@Julek: Thanks that looks interessting, may be posting InpaintDelogo is possible with this.

AvsInpaint is not a one function, so OpenCV can't substitute it, moreover, photo inpainting is quite different thing from video inpainting.

Even if you would have all necessary dlls ported to VS, then translating InpaintDelogo to VS sounds like an insane task, it's twice the size of QTGMC... :eek:

[Selur]

then translating InpaintDelogo to VS sounds like an insane task, it's twice the size of QTGMC...
first 900 lines are comments, the deprecated stuff wouldn't have to be ported, but you are right, it would be a ton of work even if each of the dlls got ported. :(
So for restortation stuff one would probably have to use:
- Avisynth for most stuff that uses RemoveDirt and InpaintDelogo
- Vapoursynth for using some of the ml based denoisers&co (DPIR, BasicVSR++) and ml based resizers like RealESRGAN.

Cu Selur