HAvsFunc

[fAy01]

Update r29.


Overlay: Add opacity parameter.
srestore: Fix dclip parameter being no effect.
MCTemporalDenoise: Add useTTmpSm and stabilize parameters.
Toon: Remove unnecessary workaround for AWarpSharp2.
Add EdgeCleaner function.


Thank you. Why does vs' Santiag require fmtconv whereas avs' Santiag doesn't require dither?

[HolyWu]

Thank you. Why does vs' Santiag require fmtconv whereas avs' Santiag doesn't require dither?

Because the center shift correction has to take chroma subsampling into account, and the relevant parameter of fmtconv is of array type hence I can specify different values for different planes. The center shift correction of chroma planes in avs' santiag is wrong.

[HolyWu]

Update r30.


ContraSharpening: Set default radius value according to resolution. Change default rep value to 13. Add planes parameter and process all planes by default.
LUTDeCrawl: Remove unnecessary workaround for SCDetect.
MCTemporalDenoise: Change default search value to 4. Add pfMode, refine, thSADC and thSADC2 parameters. Now uses DFTTest instead of FFT3DFilter for prefiltering by default.
srestore: Fix format conversion error.

[Boulder]

Radius > 1 seems to totally kill performance in ContraSharpening if the input clips are 16-bit video. Is there any way around this (i.e. a Vapoursynth bug) or is it just the way it is?

[HolyWu]

Radius > 1 seems to totally kill performance in ContraSharpening if the input clips are 16-bit video. Is there any way around this (i.e. a Vapoursynth bug) or is it just the way it is?

If radius=2 is slow for you then you probably are not using the latest version of CTMF because a special path is added for radius=2 in r4 and the workaround is removed in MinBlur(2) afterward. For radius=3 it is indeed slow because the calculation complexity is greatly affected by bit depth and that's how the original algorithm is designed.

[Boulder]

Thanks, works perfectly now. I must have missed the update of CTMF last summer, so I just subscribed to the corresponding thread in case of further developments :)

[fAy01]

I've got another request. Could you update and improve vs' FineDehalo port? It's also not being developed.
https://gist.github.com/SX91/bcd427ec0fa8fdf7c45433917521bac4

AVS code: http://avisynth.nl/index.php/FineDehalo (There's also a mod at the bottom of the page)

Question regarding Santiag, is it possible to adjust contrast sharp values?

Thank you!

[DJATOM]

FineDehalo fixed version from me. Also mt_edge and std.Prewitt produce different results, so I made some additions into code to use masktools version for that mask.
https://pastebin.com/pBXL0ubQ

[Myrsloik]

FineDehalo fixed version from me. Also mt_edge and std.Prewitt produce different results, so I made some additions into code to use masktools version for that mask.
https://pastebin.com/pBXL0ubQ

I can't remember which issue of all the ones that exist you've found here again so I'm going to list them:

1. Many avisynth authors are very confused about sobel/prewitt/whatever kernels. Some of them are horribly misnamed.
2. All avisynth implementations seem to simply add the absolute values together in order to avoid a square root. This gives diagonal edges a disproportionately big intensity.
3. I think some filter tried to combine the two kernels without realizing why it just doesn't work.

I'm sorry if the correct output has offended you.

[DJATOM]

Original port had issues with proper values conversion (haf.scale(255, bits) where proper way to convert value is haf.scale(255, peak)). Output mask was plain black due to that.
> I'm sorry if the correct output has offended you.
No problem with that. I just noticed the difference while checked avs versus vs versions of output masks, so I checked plain std.Prewitt/mt_edge(mode="prewitt", thY1=0, thY2=255, U=0, V=0) and confirmed that difference occurs there.
https://slowpics.org/comparison/9500bb72-61e4-4808-91d5-0f93e2617498 - actual comparison.

[HolyWu]

Question regarding Santiag, is it possible to adjust contrast sharp values?

um...what is contrast sharp value? Did you mean contra-sharpening? If so, it's a standalone function and you can use it on your own.

> I'm sorry if the correct output has offended you.
No problem with that. I just noticed the difference while checked avs versus vs versions of output masks, so I checked plain std.Prewitt/mt_edge(mode="prewitt", thY1=0, thY2=255, U=0, V=0) and confirmed that difference occurs there.
https://slowpics.org/comparison/9500bb72-61e4-4808-91d5-0f93e2617498 - actual comparison.

You never get identical results between them, since the kernels in masktools differ greatly from the standard definitions, like Sobel operator (https://en.wikipedia.org/wiki/Sobel_operator#Formulation) or Prewitt operator (https://en.wikipedia.org/wiki/Prewitt_operator#Formulation). For example, the doc of masktools says that "prewitt" is equivalent to mt_logic(mt_logic(mt_edge("1 1 0 1 0 -1 0 -1 -1 1"), mt_edge("1 1 1 0 0 0 -1 -1 -1 1"), mode="max"), mt_logic(mt_edge("1 0 -1 1 0 -1 1 0 -1 1"), mt_edge("0 -1 -1 1 0 -1 1 1 0 1"), mode="max"), mode="max"). To get the same incorrect output as masktools', you have to use:


# mt_edge("prewitt", 0, 255)
clip1 = core.std.Expr([core.std.Convolution(clip, matrix=[1, 1, 0, 1, 0, -1, 0, -1, -1], saturate=False), core.std.Convolution(clip, matrix=[1, 1, 1, 0, 0, 0, -1, -1, -1], saturate=False)], 'x y max')
clip2 = core.std.Expr([core.std.Convolution(clip, matrix=[1, 0, -1, 1, 0, -1, 1, 0, -1], saturate=False), core.std.Convolution(clip, matrix=[0, -1, -1, 1, 0, -1, 1, 1, 0], saturate=False)], 'x y max')
clip = core.std.Expr([clip1, clip2], 'x y max')


Now here comes the problem. What's the point? :)

[DJATOM]

HolyWu
Thanks, I'll use it instead of loading avs plugin.

[Myrsloik]

HolyWu
Thanks, I'll use it instead of loading avs plugin.

Do you have en example where the output is actually better/worse because of the difference? I mean at most I'd expect you to have to scale up the mask intensity by about 20% to compensate for the lower values on average but that's it.

[DJATOM]

Do you have en example where the output is actually better/worse because of the difference? I mean at most I'd expect you to have to scale up the mask intensity by about 20% to compensate for the lower values on average but that's it.

Check the 1st comparison from my link. https://i.imgur.com/mnA8gLr.png this part is missing with native VS mask.

[TheFluff]

The Masktools Prewitt is super weird, yes. To refresh the maths: the Prewitt operator as commonly implemented in image processing calculates the magnitude of a gradient in a 3x3 pixel grid, horizontally and vertically, by applying two convolutions, one for the horizontal and one for the vertical direction, commonly referred to as Gx and Gy respectively:


Gx (horizontal):
-1 0 1
-1 0 1
-1 0 1

Gy (vertical):
1 1 1
0 0 0
-1 -1 -1


The total gradient magnitude is then calculated as sqrt(Gx² + Gy²). A common optimization to avoid the square root is to approximate the magnitude by simply adding the absolute values of Gx and Gy, i.e. abs(Gx) + abs(Gy). This is a decent approximation if one of them is small (that is, the edge is straight, either vertically or horizontally) but pretty bad otherwise.

The Vapoursynth implementation (https://github.com/vapoursynth/vapoursynth/blob/master/src/core/genericfilters.cpp#L1239) is just straight up the canonical Prewitt - the pixel values on the 3x3 grid are called a<column><row>, so the upper left corner of the grid is a11 and the bottom right corner is a33:

float scale = params.scale;
float gx, gy;

gx = a31 + a32 + a33 - a11 - a12 - a13;
gy = a13 + a23 + a33 - a11 - a21 - a31;

return std::sqrt(static_cast<float>(gx * gx + gy * gy)) * scale;


(Some surrounding code omitted for clarity.)

Masktools does something completely different (https://github.com/pinterf/masktools/blob/16bit/masktools/filters/mask/edge/edgemask.cpp#L69) - I guess it works in practice, but it's not what is typically called a Prewitt operator:


const int p90 = a11 + a21 + a31 - a13 - a23 - a33;
const int p180 = a11 + a12 + a13 - a31 - a32 - a33;
const int p45 = a12 + a11 + a21 - a33 - a32 - a23;
const int p135 = a13 + a12 + a23 - a31 - a32 - a21;

const int max1 = max<int>( abs<int>( p90 ), abs<int>( p180 ) );
const int max2 = max<int>( abs<int>( p45 ), abs<int>( p135 ) );
const int maxv = max<int>( max1, max2 );

return threshold<Byte, int>( maxv, nLowThreshold, nHighThreshold );


p90 and p180 are the same as Gx and Gy, but then there's also a "diagonal Prewitt" calculation, using these two kernels:


"G45"
1 1 0
1 0 -1
0 -1 -1

"G135"
0 1 1
-1 0 1
-1 -1 0


Instead of the usual Prewitt which kinda sums the horizontal and vertical magnitude, this returns the maximum magnitude - max(max(Gx, Gy), max(G45, G135)).

[fAy01]

This is a big ask but amDCT performs significantly well than Deblock_QED. Could you port it? https://forum.doom9.org/showthread.php?p=1801244#post1801244
A request thread was created before but no dice: https://forum.doom9.org/showthread.php?t=173866

[TheFluff]

This is a big ask but amDCT performs significantly well than Deblock_QED. Could you port it? https://forum.doom9.org/showthread.php?p=1801244#post1801244
A request thread was created before but no dice: https://forum.doom9.org/showthread.php?t=173866

Porting amDCT would be a Herculean task. It's an incredibly messy codebase even by Avisynth plugin standards, and that's saying something. It's got everything - copypasted code (a bunch of it from other projects, even), dead code, wildly inconsistent indentation, a custom memcpy, inline asm, internal Windows-only multithreading, global debugging variables, comments that go "this doesn't work" and "this isn't used at the moment", etc etc. Just figuring out which parts of the code are actually reachable would probably take a week of hard work. Just load it via the Avisynth compatibility wrapper if you want it.

[fAy01]

Porting amDCT would be a Herculean task. It's an incredibly messy codebase even by Avisynth plugin standards, and that's saying something. It's got everything - copypasted code (a bunch of it from other projects, even), dead code, wildly inconsistent indentation, a custom memcpy, inline asm, internal Windows-only multithreading, global debugging variables, comments that go "this doesn't work" and "this isn't used at the moment", etc etc. Just figuring out which parts of the code are actually reachable would probably take a week of hard work. Just load it via the Avisynth compatibility wrapper if you want it.

I see your point but it performs better than most Deblock plugins. I tested it against other deblock filters before asking.

[TheFluff]

I’m not saying it doesn’t work, I’m just saying it would be really hard to port.

[fAy01]

Yeah, but avs is somewhat limiting and extremely slow compared to vs, hence the request for port. Anyway, Smartfade/mod might be an easier port: https://pastebin.com/3ePs7WHD
Thank you!

[HolyWu]

This is a big ask but amDCT performs significantly well than Deblock_QED. Could you port it? https://forum.doom9.org/showthread.php?p=1801244#post1801244
A request thread was created before but no dice: https://forum.doom9.org/showthread.php?t=173866

Porting amDCT is definitely no go. Maybe you can try something like DeblockPP7 or AutoDeblock in fvsfunc (https://github.com/Irrational-Encoding-Wizardry/fvsfunc). The former is probably one thousand times easier to port for me.

[ChaosKing]

You could also try the "low quality" version of Oyster https://forum.doom9.org/showthread.php?p=1780389#post1780389

[fAy01]

Porting amDCT is definitely no go. Maybe you can try something like DeblockPP7 or AutoDeblock in fvsfunc (https://github.com/Irrational-Encoding-Wizardry/fvsfunc). The former is probably one thousand times easier to port for me.

How about this?
Yeah, but avs is somewhat limiting and extremely slow compared to vs, hence the request for port. Anyway, Smartfade/mod might be an easier port: https://pastebin.com/3ePs7WHD
Thank you!

[Selur]

@HolyWu: any preferences where to post requests? Here or over in github?
Posted a small request there, and wasn't sure whether it would have been more convenient for you if I had posted it here (https://github.com/HomeOfVapourSynthEvolution/havsfunc/issues/12).

Cu Selur

[fAy01]

I tried calling chroma=true in haf.logoNR and it is not set. Could you please explain?

[HolyWu]

I tried calling chroma=true in haf.logoNR and it is not set. Could you please explain?

In Python the first letter of the boolean value needs to be capitalized, i.e., chroma=True.

[fAy01]

Thanks!

There's another variant of smartfade with masking: https://forum.doom9.org/showpost.php?p=1685277&postcount=25

[fAy01]

Hi, again. Could you please add another function: https://pastebin.com/xyVhfQFe or https://forum.doom9.org/showpost.php?p=1665492&postcount=27

[kgrabs]

Hi, again. Could you please add another function: https://pastebin.com/xyVhfQFe or https://forum.doom9.org/showpost.php?p=1665492&postcount=27

DeCross, mt_motion, and TEMmod/TEdgeMask are not available in Vapoursynth

Edit: I lied, TEdgeMask is a function now (https://github.com/WolframRhodium/muvsfunc/blob/master/muvsfunc.py#L1146) (but adding it would create another dependency)

Also life hack about the chroma=true thing: use 0 for False and 1 for True to save yourself some keystrokes, since python treats them the same. You can actually use any non-zero for True but you know what they say, KISS

[fAy01]

DeCross, mt_motion, and TEMmod/TEdgeMask are not available in Vapoursynth

Edit: I lied, TEdgeMask is a function now (https://github.com/WolframRhodium/muvsfunc/blob/master/muvsfunc.py#L1146) (but adding it would create another dependency)

Also life hack about the chroma=true thing: use 0 for False and 1 for True to save yourself some keystrokes, since python treats them the same. You can actually use any non-zero for True but you know what they say, KISS

I see. Thanks for the clarification.

[fAy01]

I called LUTDeCrawl with default settings and I am seeing image distortion in some areas.

https://diff.pics/1CsGIqJz_aur/1

Image 1 - The edges of the clouds (blur)
Sample: https://www26.zippyshare.com/v/RySrd4MX/file.html

Image 2 - Somehow the green color is being displaced (check frame 22)
Sample: https://www26.zippyshare.com/v/BeqbFVsU/file.html

[HolyWu]

I called LUTDeCrawl with default settings and I am seeing image distortion in some areas.

https://diff.pics/1CsGIqJz_aur/1

Image 1 - The edges of the clouds (blur)
Sample: https://www26.zippyshare.com/v/RySrd4MX/file.html

Image 2 - Somehow the green color is being displaced (check frame 22)
Sample: https://www26.zippyshare.com/v/BeqbFVsU/file.html

Unfortunately that's the defect of the function itself, not that I did something wrong when porting. Something you can try is to lower the default values, like LUTDeCrawl(ythresh=5, cthresh=5, maxdiff=25), or another decrawl filter TComb.

[fAy01]

Unfortunately that's the defect of the function itself, not that I did something wrong when porting. Something you can try is to lower the default values, like LUTDeCrawl(ythresh=5, cthresh=5, maxdiff=25), or another decrawl filter TComb.

Unfortunately, it suffers from the same issue. Just tested LUTDeCrawl(ythresh=5, cthresh=5, maxdiff=25) <-- causes the same issue with lower values. So there might not be anything wrong with your port but there might be something within the code.

[Selur]

Got a question related to LUTDeRainbow: Does LUTDeRainbow only support YUV420P8-10?
I thought it was supposed to support YUVXXXP8-YUVXXXP10, but when actually testing it, everything that isn't 4:2:0, gives me:
Lut2: only clips with integer samples, same dimensions, same subsampling and up to a total of 20 indexing bits supported
-> Was my assumption that it was supposed to support YUVXXXP8-YUVXXXP10 wrong or is this a bug somewhere in the code?

[HolyWu]

Got a question related to LUTDeRainbow: Does LUTDeRainbow only support YUV420P8-10?
I thought it was supposed to support YUVXXXP8-YUVXXXP10, but when actually testing it, everything that isn't 4:2:0, gives me:

-> Was my assumption that it was supposed to support YUVXXXP8-YUVXXXP10 wrong or is this a bug somewhere in the code?

Fixed. Thanks for the report.

[Selur]

Thanks for fixing. :)

[poisondeathray]

LSFmod crashes on a single frame input

e.g

clip = core.std.BlankClip(format=vs.YUV420P8)
#clip = clip[0] # return single frame 0 => crash
#clip = clip[0:2] # return 0,1 (2 frames) => ok
clip = haf.LSFmod(clip)
clip.set_output()


error message
Attempted to read key 'clip' from a map with error set: Trim: last frame beyond clip end

[HolyWu]

LSFmod crashes on a single frame input

Well, it's caused by misc.SCDetect which is used indirectly when soothe=True. In misc.SCDetect it uses Trim (https://github.com/vapoursynth/vapoursynth/blob/master/src/filters/misc/miscfilters.cpp#L93) to "shift" the frames for scene change detection. Since it's a one-frame clip so the range gets out of bounds. But misc.SCDetect doesn't properly check whether there is an error set in the map or not, hence you get abnormal crash in this case.

[Myrsloik]

Well, it's caused by misc.SCDetect which is used indirectly when soothe=True. In misc.SCDetect it uses Trim (https://github.com/vapoursynth/vapoursynth/blob/master/src/filters/misc/miscfilters.cpp#L93) to "shift" the frames for scene change detection. Since it's a one-frame clip so the range gets out of bounds. But misc.SCDetect doesn't properly check whether there is an error set in the map or not, hence you get abnormal crash in this case.

Fixed, it will now return an error on pointless 1 frame clips.

[poisondeathray]

Fixed, it will now return an error on pointless 1 frame clips.

Thanks

Now back to my pointless adventures :D

[fAy01]

Could you please update: http://avisynth.nl/index.php/QTGMC & http://avisynth.nl/index.php/Srestore ?

And please add these functions as well: https://pastebin.com/GyM2N6km ++ https://pastebin.com/Z7k3ZXBr ++ http://putin999.blog.fc2.com/blog-entry-4.html

Thank you.

[Myrsloik]

You should probably replace the use of depan by mvtools since it has all the required functions now. Just an observation when i checked the used plugins.

[Myrsloik]

I just realized that you depend on nnedi3_resample which is missing the conditional use of znedi3. So nnedi3 is still required and used in that script part. I've reported it as an issue for nnedi3_resample but thought I should mention it.

[fAy01]

https://www.mediafire.com/file/sygi04y47eknvc2/xaa_v1.2.1.avsi
Please add this, if you can. Thanks.

[lansing]

I was testing out the fast presets of QTGMC on my video, I was deinterlacing a 1080i clip and downscale it to 720p, here's the benchmark with vs editor.

faster: 23.6 fps
very fast: 24.8 fps
super fast: 36.1 fps
ultra fast: 36 fps
draft: 85.5 fps

The presets doesn't really scale in speed, "faster" is the same as "very fast" and "super fast" is the same as "ultra fast". Though there was a 130% speed increase when going from "ultra fast" to "draft". It just doesn't look right to me.

I am looking for a preset for fast encoding and it seems like I have no choice except to use "draft", but it just feels cheap to use the lowest setting. Can there be some changes in the "ultra fast" so to make it less cheap than "draft" but be significantly faster than "super fast"?

[HolyWu]

I am looking for a preset for fast encoding and it seems like I have no choice except to use "draft", but it just feels cheap to use the lowest setting. Can there be some changes in the "ultra fast" so to make it less cheap than "draft" but be significantly faster than "super fast"?

You can compare what values are changed between "ultra fast" and "draft" at https://github.com/HomeOfVapourSynthEvolution/havsfunc/blob/master/havsfunc.py#L896 and tweak the relevant parameters then.

[lansing]

You can compare what values are changed between "ultra fast" and "draft" at https://github.com/HomeOfVapourSynthEvolution/havsfunc/blob/master/havsfunc.py#L896 and tweak the relevant parameters then.

Here's my test result:

ultra fast: 36 fps

Changing Rep2 from 3 to 0 increased the speed to 48 fps.
Changing Smode from 2 to 0 increased it to 41 fps.
Changing EdiMode from "nnedi3" to "bob" increased it to 40.7 fps.

Changing all three together increased it to 68.1 fps. It looks like a good reasonable fps for the name.

[HolyWu]

Update r31.


daa, santiag, QTGMC, ivtc_txt60mc: Add device parameter.
Add smartfademod and FineDehalo functions.
LUTDeRainbow: Fix incompatibility with different subsampling.
LUTDeCrawl: Change default cthresh value to 10.
Stab: Use depan filters in mvtools plugin.
TemporalDegrain: Fix hqdn3d's namespace and filter name.
LSFmod: Speed up preblur by using MinBlur(1).

[tormento]

Update r31.
I'd like to give VapourSynth a run. The only filter I use is SMDegrain (oh yeah.. CompTest xD too). Could you please update your script to reflect the 100s (https://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution/page5#post2413356) version?

[ChaosKing]

If you want tr > 3 use the hnwvsfunc.SMDegrain version by Wolfberry https://forum.doom9.org/showthread.php?t=175614