Dogway's Filters Packs

[kedautinh12]

Originally Posted by tormento

Trying ResizersPack-7.1~Dogway.avsi

Script error: Invalid arguments to function 'width'.
(D:/Programmi/Media/AviSynth+/plugins64/ResizersPack-7.1~Dogway.avsi, line 171)
(D:/Programmi/Media/AviSynth+/plugins64/ResizersPack-7.1~Dogway.avsi, line 150)
(D:/Programmi/Media/AviSynth+/plugins64/TransformsPack-1.0rc29~Dogway.avsi, line 136)
(D:/Programmi/Media/AviSynth+/plugins64/TransformsPack-1.0rc29~Dogway.avsi, line 145)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 914)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 917)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 228)

Cause ResizersPack latest ver update for extools v6.9 but extools just updated v6.8

[tormento]

Originally Posted by kedautinh12

Cause ResizersPack latest ver update for extools v6.9 but extools just updated v6.8

Version 7.0 works perfectly fine and I think it was the first one prepared for newer extools. Only Dogway will tell us what happened

[Dogway]

Ok, I just updated ExTools so hope things go back to normal slowly. Still need to update SMDegrain. TransformsPack I don't know what the issue is?
I was holding back for the ex_bs() refactor but it was delayed on conversations with pinterf so decided to do it for next version, so sad v6.9 will be so short-lived

[anton_foy]

Originally Posted by Dogway

Ok, I just updated ExTools so hope things go back to normal slowly. Still need to update SMDegrain. TransformsPack I don't know what the issue is?
I was holding back for the ex_bs() refactor but it was delayed on conversations with pinterf so decided to do it for next version, so sad v6.9 will be so short-lived

Nice work! I replaced with new Extools but LSFmod get another error:

ex_lutspa does not have a named argument "fulls"

EDIT: sorry my bad, it was deblockpack but when I updated from 1.5 to 1.6 I get that runtime error again at line 98.

[Dogway]

LSFmod and TransformsPack still need to be updated. DeblockPack is updated so it should work, line 98? Do you mean this line?:

propGetInt      (clp,"_ColorRange") == 0 : rgb

[Forteen88]

Originally Posted by tormento

The issue is the resulting bitrate, too high for a BW movie.

The best results are from SPresso+STPresso+SMDegrain but the speed is in the order of 0.5 fpsL too slow. I am eager to see your porting of STPresso if it could achieve better speeds and the same quality.

Plus, I have found that, strangely, if you apply plane=0 and chroma=false, you obtain a lower noise cleanup.

If I have to pick either SPresso or STPresso, would it be better to pick STPresso to encode DVD-videos, because it's temporal? To my understanding, SPresso is probably better to encode a video with a bunch of still-images.

[Boulder]

Video is a bunch of still images you know..

[Forteen88]

Originally Posted by Boulder

Video is a bunch of still images you know..

I think that you understand what I mean.
STPresso for sequential video.

[Dogway]

I always favour some temporal filtering, so you can try STPresso. It has bias options between spatial and temporal, it's a tad slower than SPresso so for a faster alternative I made STTWM(). You can try them and use what suits your needs.

[anton_foy]

Originally Posted by Dogway

LSFmod and TransformsPack still need to be updated. DeblockPack is updated so it should work, line 98? Do you mean this line?:

propGetInt      (clp,"_ColorRange") == 0 : rgb

It says "propnumelements: this filter can only be used within run-time filters. DeblockPack.avsi, line 98"

[Forteen88]

Originally Posted by Dogway

I always favour some temporal filtering, so you can try STPresso....

Thanks.

[Dogway]

Originally Posted by anton_foy

It says "propnumelements: this filter can only be used within run-time filters. DeblockPack.avsi, line 98"

I think you don't have latest AVS+ installed because it's working fine here. frameprops can be read from frame index 0 since a few versions back.


By the way, I just uploaded a refactor of FlatMask() inspired by the recent thread here on edge masks for cartoons.
I remade it entirely with ExTools and while it isn't exactly the same it probably works faster than doing full segmentation like described in the paper.
It serves two purposes, edge masks without double edges, and if fine tuned also as a flat mask. It uses an internal limiter so it also can be used to mix filtered clips to pass only on flat areas.

[Shinkiro]

LSFmod broken

[Dogway]

Yes, updating soon.

[anton_foy]

Originally Posted by Dogway

I think you don't have latest AVS+ installed because it's working fine here. frameprops can be read from frame index 0 since a few versions back.

Don't know what Im doing wrong I replaced all avisynth.dll's with the newest "Avisynth+ 3.7.1 test build 34 (20211208)"
In Avisynth_repository>x86-folder and in System32-folder.

EDIT: BTW. Thanks Dogway for the applygradientcurves substitution!!!

[Dogway]

Are you using avisynth x86? If not files should go into the x64 folder and system32. In other words in the test34 zip go to the x64 folder and copy Avisynth.dll and DeVil.dll into System32, then the files from plugins folder into "plugins64+" folder of your avisynth+ installation. If this doesn't work you might need to check your paths with avsmeter "avsmeter64 avsinfo -lf >AVSinfo.log"

This is how it looks here:

VersionString:              AviSynth+ 3.7.1 (r3577, master, x86_64)
VersionNumber:              2.60
File / Product version:     3.7.1.0 / 3.7.1.0
Interface Version:          8
Multi-threading support:    Yes
Avisynth.dll location:      C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp:    2021-12-08, 19:27:35 (UTC)
PluginDir2_5 (HKLM, x64):   C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+   (HKLM, x64):   C:\Program Files (x86)\AviSynth+\plugins64+

[anton_foy]

Originally Posted by Dogway

Are you using avisynth x86? If not files should go into the x64 folder and system32. In other words in the test34 zip go to the x64 folder and copy Avisynth.dll and DeVil.dll into System32, then the files from plugins folder into "plugins64+" folder of your avisynth+ installation. If this doesn't work you might need to check your paths with avsmeter "avsmeter64 avsinfo -lf >AVSinfo.log"

This is how it looks here:

VersionString:              AviSynth+ 3.7.1 (r3577, master, x86_64)
VersionNumber:              2.60
File / Product version:     3.7.1.0 / 3.7.1.0
Interface Version:          8
Multi-threading support:    Yes
Avisynth.dll location:      C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp:    2021-12-08, 19:27:35 (UTC)
PluginDir2_5 (HKLM, x64):   C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+   (HKLM, x64):   C:\Program Files (x86)\AviSynth+\plugins64+

Yes I use 32-bit AVS+

[DTL]

I see default overlap param in SMDegrain = half block size. Do it really makes great visible quality benefit over the smaller size (like 2) ? I see enabling overlap (overlap > 0) in MDegrain significantly affect speed. With block size 8x8 overlap =4 may be 4 times slower of no-overlap. Overlap=2 runs about 60% of no-overlap speed. The overlap=0 really produces visible blocks edges (and make best speed but lowest quality).

Wiki lists:
overlap int = blksize/2
Must be *even* and *less* than block size. Common values: blksize/4 or blksize/2. Larger overlap looks slightly better and runs slower.

May be it exist some statistics what is most commonly used overlap value ?

Assuming with hardware motion search the MAnalyse will be *infinitely* fast - the overlapping processing of MDegrain on CPU will be the main speed limiter.

[Dogway]

Guess I didn't notice the change of defaults, typically settings are as in MVTools defaults so a SMDegrain dumb call is practically the same.

The documentation says:
"The greater overlap, the more blocks number, and the lesser the processing speed. However the default value 0 may cause blocking-like artefacts"

But I can test with blksize/4, I will have a look at zorr statistics but I also have pending my own statistics. For SMDegrain is that and automatic thSAD detection, but it will be in form of a helper function to be called explicitly. I think a wise strategy is to default to blksize/4 if refinemotion is used.

[zorr]

Originally Posted by Dogway

But I can test with blksize/4, I will have a look at zorr statistics but I also have pending my own statistics.

In my tests so far larger overlap most of the time means better quality. Some of my results can be found in this post.

The test was using MFlowFPS while MCompensate would most likely be closer to what MDegrain is doing. Nevertheless I think the results also apply to MDegrain to certain degree at least.

Optimal overlap and overlapv were different in that test, I think because motion was almost perfectly horizontal. In the general case that doesn't apply so using blksize/2 is the best option. I have even suggested that MVTools allowed larger than blksize/2 overlaps since there's a clear trend of better quality the larger the overlap.

It would be interesting to test if the quality drop of having smaller overlap like blksize/4 can be compensated with other parameters which don't slow down the processing that much.