MCTemporalDenoise [v1.4.20 - Update 2010/07/02]

[Khun_Doug]

Here is the entire piece of code that is faulting. I will highlight the two areas that fail.

Sclp = (sharp == true) ? (shF!="internal") ? Eval("smE."+shF) :
\ IsBool(ssource) ? ssource ? smE.LSFmod(strength=strength,Smode=SHmode,Smethod=SHmethod,Lmode=0,overshoot=Sovershoot,preblur="ON",secure=true,edgemode=0,soft=0,soothe=false,ss_x=1.00,ss_y=1.00,source=i)
\ : smE.LSFmod(strength=strength,Smode=SHmode,Smethod=SHmethod,Lmode=Slimit,overshoot=Sovershoot,preblur="ON",secure=true,edgemode=0,soft=0,soothe=false,ss_x=1.00,ss_y=1.00) :
\ IsClip(ssource) ? smE.LSFmod(strength=strength,Smode=SHmode,Smethod=SHmethod,Lmode=0,overshoot=Sovershoot,preblur="ON",secure=true,edgemode=0,soft=0,soothe=false,ss_x=1.00,ss_y=1.00,source=ssource) :
\ Assert(False, "MCTD: ssource should be bool or clip!")
\ : NOP()
Tmax = (sharp == true) ? i.mt_logic(f1c,"max",U=1,V=1).mt_logic(b1c,"max",U=1,V=1) : NOP()
Tmin = (sharp == true) ? i.mt_logic(f1c,"min",U=1,V=1).mt_logic(b1c,"min",U=1,V=1) : NOP()

shrp = (sharp==false) ? smE
\ : (Tlimit==true) ? Sclp.mt_clamp(Tmax, Tmin, Tovershoot, Tovershoot, U=1, V=1) <=== fails if sharp=true AND tlimit=true
\ : Sclp

sL = (sharp==true&&adapt==true) ? useMMask ? mt_merge(smE,shrp,mL,U=chr21,V=chr21)
\ : mt_merge(smE,shrp,mR,U=chr21,V=chr21) <=== sharp=true AND tlimit=false
\ : shrp.mergechroma(smE)

If sharp=false and tlimit=true the filter works, but presumably is not sharpening. The defaults are for both sharp and tlimit to be true.
My script that calls the filter is as follows:

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll")
FFVideoSource(source="D:\Doug\Videos\DVD\FRANKENSTEIN\VTS_01_1.VOB")
ConvertToYV12() <=== Added as a suggestion. Makes no difference to the outcome.
Spline36Resize(640,480)
Tweak(sat=1.06,cont=1.06,bright=1)
MCTD (sharp=false) <==== This works

MCTD ()
script error: invalid arguments to function 'mt_clamp'

MCTD(sharp=true,tlimit=false)
script error: invalid arguments to function 'mt_merge'

[Khun_Doug]

I think you are on to something with the parameter/syntax. I grabbed the version from the Wiki and added your two lines at the end. Just colorbars and a call the function and voila, THE SAME ERROR! That leads me to believe the version of masktools2 has parameter or syntax difference than what the filter expects.

Using MCTD(sharp=true,tlimit=false) with the colorbars the error changes to invalid arguments to function 'mt_merge'.

I tried using the older masktools, not masktools2 and the same error.

I have the output from avsmeter -avsinfo that I can post if anyone believes that will be helpful.

[StainlessS]

I've now tried all three versions that I could find,
LaTo v1.4.20,
taro mod_4.2
AmjadSONY mod_4.3 (at bottom of this page http://avisynth.nl/index.php/MCTemporalDenoise )

No problems with any of them.

EDIT: Avsmeter log might be useful.

[Khun_Doug]

Keep in mind that I tested LimitedSharpenFaster, that uses mt_clamp, and the filter runs. Other filters that use these same plugins also work correctly.

Here is the avsmeter output:

C:\TEMP>avsmeter -avsinfo

AVSMeter 2.7.5 (x86) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2664, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2018-03-29, 01:04:18 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth 2.5\plugins
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+


[CPP 2.5 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth 2.5\plugins\AddGrainC.dll [1.7.1.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\deblock.dll [1.2.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\Decomb.dll [2013-02-26]
C:\Program Files (x86)\AviSynth 2.5\plugins\EEDI2.dll [0.9.2.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\flash3kyuu_deband.dll [2015-05-02]
C:\Program Files (x86)\AviSynth 2.5\plugins\FluxSmooth.dll [2006-11-09]
C:\Program Files (x86)\AviSynth 2.5\plugins\gradfun2db.dll [2018-05-11]
C:\Program Files (x86)\AviSynth 2.5\plugins\LSMASHSource.dll [2017-02-25]
C:\Program Files (x86)\AviSynth 2.5\plugins\MaskTools.dll [1.5.1.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-25.dll [2.0.48.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-26.dll [2.0.48.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\SangNom.dll [2004-01-18]
C:\Program Files (x86)\AviSynth 2.5\plugins\SSIM.dll [0.25.1.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\TDeint.dll [1.1.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\TTempSmooth.dll [0.9.4.0]

[CPP 2.6 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth 2.5\plugins\AutoAdjust.dll [2.6.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\DCTFilter.dll [0.5.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\DCTFilter_avx2.dll [0.5.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\DePan.dll [2.13.1.3]
C:\Program Files (x86)\AviSynth 2.5\plugins\DePanEstimate.dll [2.10.0.2]
C:\Program Files (x86)\AviSynth 2.5\plugins\DirectShowSource.dll [2.6.0.3]
C:\Program Files (x86)\AviSynth 2.5\plugins\eedi3.dll [0.9.2.1]
C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll [2016-12-29]
C:\Program Files (x86)\AviSynth 2.5\plugins\fft3dfilter.dll [2.4.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\masktools2.dll [2.2.14.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\msharpen.dll [2017-12-03]
C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll [2.7.25.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi3.dll [0.9.4.33]
C:\Program Files (x86)\AviSynth 2.5\plugins\RgTools.dll [0.96.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\SangNom2.dll [2018-05-11]
C:\Program Files (x86)\AviSynth 2.5\plugins\TCPDeliver.dll [2.6.0.7]
C:\Program Files (x86)\AviSynth 2.5\plugins\yadifmod2.dll [2017-12-16]
C:\Program Files (x86)\AviSynth 2.5\plugins\yadifmod2_avx2.dll [2017-12-16]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [2018-03-29]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [2018-03-29]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [2018-03-29]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [2018-03-29]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [2018-03-29]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [2018-03-29]

[Scripts (AVSI)]
C:\Program Files (x86)\AviSynth 2.5\plugins\colors_rgb.avsi [2015-03-30]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.avsi [2016-07-05]

[Uncategorized DLLs (32 Bit)]
C:\Program Files (x86)\AviSynth 2.5\plugins\avcodec-57.dll [57.81.100.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\avformat-57.dll [57.66.102.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\avresample-3.dll [3.2.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\avutil-55.dll [55.47.100.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\libfftw3-3.dll [2016-07-30]
C:\Program Files (x86)\AviSynth 2.5\plugins\libfftw3f-3.dll [2016-07-30]
C:\Program Files (x86)\AviSynth 2.5\plugins\libfftw3l-3.dll [2016-07-30]
C:\Program Files (x86)\AviSynth 2.5\plugins\swscale-4.dll [4.3.101.0]

[Uncategorized files]
C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.lib [2016-12-29]
C:\Program Files (x86)\AviSynth 2.5\plugins\ffmsindex.exe [2016-12-29]
C:\Program Files (x86)\AviSynth 2.5\plugins\masktools2.dll-old [2.2.10.0]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.txt [2016-07-05]

C:\TEMP>

[StainlessS]

[CPP 2.5 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-25.dll [2.0.48.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-26.dll [2.0.48.0] # Wrongly labelled, same as above

[Uncategorized DLLs (32 Bit)] # All Rubbish
C:\Program Files (x86)\AviSynth 2.5\plugins\avcodec-57.dll [57.81.100.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\avformat-57.dll [57.66.102.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\avresample-3.dll [3.2.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\avutil-55.dll [55.47.100.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\libfftw3-3.dll [2016-07-30]

# this one usually in system32/SysWOW64 for dfttest (also same file renamed as fftw3.dll for FFT3DFilter)
C:\Program Files (x86)\AviSynth 2.5\plugins\libfftw3f-3.dll [2016-07-30]

C:\Program Files (x86)\AviSynth 2.5\plugins\libfftw3l-3.dll [2016-07-30]
C:\Program Files (x86)\AviSynth 2.5\plugins\swscale-4.dll [4.3.101.0]


[Uncategorized files] # Rubbish
C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.lib [2016-12-29]
C:\Program Files (x86)\AviSynth 2.5\plugins\ffmsindex.exe [2016-12-29] # For ffms2, but not really needed.
C:\Program Files (x86)\AviSynth 2.5\plugins\masktools2.dll-old [2.2.10.0]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.txt [2016-07-05]

[Groucho2004]

@Khun_Doug
You have 3 versions of MaskTools2 in your auto-load directory:
mt_masktools-25.dll [2.0.48.0]
mt_masktools-26.dll [2.0.48.0]
masktools2.dll [2.2.14.0]

Hard to say which one is loaded first. Get rid of the mt_* versions and try again. While you're at it, delete the "MaskTools.dll [1.5.1.0]" as well unless you need it.

Edit:
Also, pick just one of these two:
yadifmod2.dll [2017-12-16]
yadifmod2_avx2.dll [2017-12-16]

[Khun_Doug]

Groucho, you just helped me learn something new. I didn't realize that if the plugin was in the directory it may get loaded. I'm going to clean this up and do more testing.

I am also updating a VMware test box that I can use for testing. I'll get this resolved ... push, pull, or drag!

[StainlessS]

Also, pick just one of these two:
yadifmod2.dll [2017-12-16]
yadifmod2_avx2.dll [2017-12-16]


And again here

C:\Program Files (x86)\AviSynth 2.5\plugins\DCTFilter.dll [0.5.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\DCTFilter_avx2.dll [0.5.0.0]

[Khun_Doug]

The problem is resolved! Yippee!!

Thanks to everyone that provided some help. A special thanks to StainlessS and Groucho2004. With their help I was able to eliminate several older plugins, and now have a much cleaner report from avsmeter.

For anyone that hits this thread in the future and is having the same problem, the solution is to get the proper version of LSFmod. There is a version "v1.9 - 05 October 2009 Modded Version by LaTo INV." That did NOT work on my install. The version I found that DOES work is "v2.1 - 13 July 2017 another Modded Version by A.SONY." Once that was included and the v1.9 was left out, the script began to work as expected.

The only way I found the solution was to diddle the script. I could see where a variable smE was being referenced and LSFmod was being used on that variable. I stuffed smE in as the paramter to mt_clamp instead of using Sclp, and the script worked. That pointed to something with LSFmod. I looked on Internet and found a newer version than what I had, and that version resolved the problem.

[MysteryX]

I searched and cannot find such a thing as LSFMod v2.1; and v1.9 does work for me.

I also looked into whether this could work in 16-bit. Changing the validations is easy, there are 2 IsYV12() calls in MCTemporalDenoise and 1 in LSFMod, change them to Is420().

However, it uses a lot of filters and not all support 16-bit. Looking at the list of filters

Supports high-bit-depth

- MVTools: yes
- MaskTools2: yes
- RgTools: yes
- FFT3Dfilter: yes
- AddGrainC: yes (?)

- TTempSmooth: NO
- DeBlock: NO
- DctFilter: NO
- EEDI2: NO
- SangNom: NO
- GradFun2db: NO

There's still a lot of work to do to add high-bit-depth support into existing plugins, and unfortunately there's a big lack of man-power when it comes to developers.

Furthermore, it doesn't work well with MT, it could require extensive testing to figure out which functions need to be configured with which mode.

If I look at debug output, I get this message: "FFT3DFilterMulti: cannot work in reentrant multithread mode!". If I specify a MT mode for FF3DFilter, however, it says "Ignoring unnecessary MT-mode specification for fft3dfilter_FFT3DFilter() by script"

[Khun_Doug]

Here are the links to the LSFmod 2.1. I'm not sure why LSFmod 1.9 is a no-go on my machine, but tracing the MCTD filter when it crashed helped me isolate the trouble area. This version of LSFmod resolves the problem.

https://forum.doom9.org/showthread.php?t=174752
-and-
https://pastebin.com/NnjaqCa8

I just hit the error "FFT3DFilterMulti: cannot work in reentrant multithread mode!" in my evaluation of the filter, today. What I did that worked was use SetFilterMTMode("MCTD", 4, force=true). Using this I was able to take an SD source and save as an uncompressed AVI without a crash. Possibly a fluke, but I will use that again on another SD source. I'll use a different tool to encode the uncompressed AVI to X265.

[Stereodude]

I also looked into whether this could work in 16-bit. Changing the validations is easy, there are 2 IsYV12() calls in MCTemporalDenoise and 1 in LSFMod, change them to Is420().

However, it uses a lot of filters and not all support 16-bit. Looking at the list of filters

Supports high-bit-depth

- MVTools: yes
- MaskTools2: yes
- RgTools: yes
- FFT3Dfilter: yes
- AddGrainC: yes (?)

- TTempSmooth: NO
- DeBlock: NO
- DctFilter: NO
- EEDI2: NO
- SangNom: NO
- GradFun2db: NO

There's still a lot of work to do to add high-bit-depth support into existing plugins, and unfortunately there's a big lack of man-power when it comes to developers.
Thanks for your investigation.

[MysteryX]

I would also note that high-bit-depth would be ESPECIALLY useful for this filter because it runs at the beginning of the script. The slight rounding errors have cascading effects on the rest of the script.

But so far, Pinterf is among the very few porting existing plugins into high-bit-depth. I unfortunately have no knowledge of assembly whatsoever -- and have too many other priorities to start learning that.

[poisondeathray]

The vapoursynth version works at higher bit depth , could some elements be back ported or at least be a starting point?

[Boulder]

Why not use the VS + Avisynth combo? Or just VS for videos that require the filter.

[MysteryX]

The vapoursynth version works at higher bit depth , could some elements be back ported or at least be a starting point?
Was looking into VapourSynth code. SangNomMod only supports 8-bit-depth, so that would make the whole script fail if you're using that. Deblock and DCTFilter do support HBD.

[poisondeathray]

Was looking into VapourSynth code. SangNomMod only supports 8-bit-depth, so that would make the whole script fail if you're using that. Deblock and DCTFilter do support HBD.

sangnommod is not used in the vpy version

And there are no error messages at , say 10bit or 16bit (Float fails because mvtools super complains)

Let HolyWu know if you find a problem in the havsfunc thread

[MysteryX]

I have back-ported Deblock from VapourSynth to Avisynth, and Chikuzen had developed a new DCTFilter but the Wiki was outdated. Perhaps some other filters have HBD versions that I'm not aware of.

Supports high-bit-depth

- MVTools: yes
- MaskTools2: yes
- RgTools: yes
- FFT3Dfilter: yes
- AddGrainC: yes (?)
- DeBlock: yes
- DctFilter: yes

- TTempSmooth: NO
- EEDI2: NO
- SangNom: NO -- Note: VapourSynth version doesn't use SangNom
- GradFun2db: NO

[VoodooFX]

I accidentally noticed that MCTemporalDenoise() gives random quality results. I'm lost a bit what is going on, anyone can confirm it?
I used latest MeGui to encode (tried VirtualDub but it is random with any avs script I tested).

avs script:
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\Test\Test_VTS_01_1.d2v")
Trim(0, 159)
MCTemporalDenoise()

crc of files (above avs encoded few times using same settings):
Test_VTS_01_1_enc-1.mkv AC6B9993
Test_VTS_01_1_enc-2.mkv 8EC5D5ED

For example avs script without MCTemporalDenoise:
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\Test\Test_VTS_01_1.d2v")
Trim(0, 159)
QTGMC( Preset="Medium", InputType=1 )
LSFmod()

crc of files (above avs encoded few times using same settings):
Test_VTS_01_1_enc-1.mkv 75FCDA51
Test_VTS_01_1_enc-2.mkv 75FCDA51

[poisondeathray]

crc of files (above avs encoded few times using same settings):
Test_VTS_01_1_enc-1.mkv AC6B9993
Test_VTS_01_1_enc-2.mkv 8EC5D5ED


MCTD has addgrain and gradfun (enhance=true) applied by default ("randomness" from the grain generator)

[VoodooFX]

MCTD has addgrain and gradfun (enhance=true) applied by default ("randomness" from the grain generator)

That makes sense now. Thanks for answer.

[Stereodude]

Where are we at for running MCTD in 64-bits AVS+? I know we don't have >8-bit support yet. :(

MCTD has addgrain and gradfun (enhance=true) applied by default ("randomness" from the grain generator)
Not only that, x264/x265 are not deterministic video encoders with the commonly used options.

[poisondeathray]

Where are we at for running MCTD in 64-bits AVS+? I know we don't have >8-bit support yet. :(


Four more, see post 720 . MysteryX was having a go at it but got lost in the mountains or something (went on a trip)
https://forum.doom9.org/showpost.php?p=1843774&postcount=719



Not only that, x264/x265 are not deterministic video encoders with the commonly used options.

Are you sure ? --non-deterministic is disabled by default, and the previous poster got crc check match without mctd a few times, but no match with mctd

A quick test with default encoding settings looks ok too
[Parsed_psnr_2 @ 000000d202242000] PSNR y:inf u:inf v:inf average:inf min:inf max:inf

[Stereodude]

Four more, see post 720 . MysteryX was having a go at it but got lost in the mountains or something (went on a trip)
https://forum.doom9.org/showpost.php?p=1843774&postcount=719
I thought he was speaking to >8bit color depth support, not 64-bit support.

Are you sure ? --non-deterministic is disabled by default, and the previous poster got crc check match without mctd a few times, but no match with mctd

A quick test with default encoding settings looks ok too
[Parsed_psnr_2 @ 000000d202242000] PSNR y:inf u:inf v:inf average:inf min:inf max:inf
AFAIK, using VBV makes them non-deterministic. Aren't those enabled and enforced by default per the level you select?

[poisondeathray]

I thought he was speaking to >8bit color depth support, not 64-bit support.



Sorry I misread

It works fine in avisynth+ x64 MT for 8bit right now



AFAIK, using VBV makes them non-deterministic. Aren't those enabled and enforced by default per the level you select?

I don't know what the current status is .

At one point --level didn't enforce anything and was just a "label." That might have changed

A quick test with --vbv-maxrate and --vbv-bufsize specified shows the same per frame PSNR wise - but it might not have been long enough, or diverse enough test

[Stereodude]

Where are we at for running MCTD in 64-bits AVS+? I know we don't have >8-bit support yet. :(
So i decided to try getting MCTD to work in x64 again the other day (no MT). It was quite easy to get working. I tried it once before some years ago and found it finicky and unstable, but there seems to be no issues thanks to all of pinterf's work on mvtools and the other key components. Clearly I should have taken poisondeathray's report above and tried it a year ago. It is a little faster too.

I still wish for >8-bit support though.

[Stereodude]

Updated the script to use SangNom2 for full x64 support. Also updated the filter dependency list to the latest filters.

Edit: Note that SangNom2 requires AviSynth 2.6 Alpha4 (or later) or Avisynth+.

[Stereodude]

Updated to v1.4.22x (x for experimental)

Changes:
Uses NeoFFT3D (https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D) instead of FFT3dFilter
YUY2 support is removed
ncpu parameter is removed
~10% faster on preset low for HD material [1920 wide]
~20% faster on preset medium (and higher) for HD material [1920 wide]

Edit: pastebin with the script: https://pastebin.com/ZtL3ZcM3

[StainlessS]

If you are gonna remove functionality, maybe also a name change is prudent (as MeteorRain did for the FF3DFilter/NeoFFT3D),
Maybe McTemporalDenoiseNeo(). If it makes sense for the dll, why would it make less sense for a script function which is similarly enhanced/crippled.

[Either that or continue original support with script work arounds where HBD, call original dll where Neo-dll not available, or where YUY2].

[pinterf]

What's the point of working with yuy2 instead of converting it to yv16 right after the source filter? Which filters do not know about planar 422?

[MeteorRain]

Actually, it would just be an extra convert to YV16 and back in order to support YUY2.

And no it doesn't make sense to always support the exact same feature as it was. Plugins and scripts supported YUY2 only because it was a widely used color space back then. There shouldn't be reasons to deliberately use a legacy format at this moment..

[pinterf]

Yep, I do it at some filters. No special code for yuy2 inside but convert to and from yv16 on the fly. Same can apply on packed rgb formats

[StainlessS]

Actually, it would just be an extra convert to YV16 and back in order to support YUY2.
I would have no probem with that [EDIT: so long as conversion is lossless].

It's just that I like if script can adjust to whatever is thrown at it, where automatic handling can remove human intervention,
and if it can be done relatively easily, then why not.
The only colorspace that I really have no probs avoiding is YV411 [and dont even go anywhere near YV410, that aint nice
EDIT: 3x3 luma for single chroma UV pair, think its called YV410].

[pinterf]

On the other hand, if yuy2 support is still allowed, users won't bother with removing it, resulting in huge complex scripts full with IsYUY2? : constructs. And a small speed penalty.

[StainlessS]

users won't bother with removing it
Well then that is down to user, and they have to pay penalty for it, but should it throw error, me would say not.
I might feel different if there was a non lossless colorspace change involved.
[EDIT: My time is more valuable to me than the computers run time, others may disagree.]

EDIT: "just do what I say and dont give me any lip !" [ my command to script, not to Pinterf :) ]

EDIT: For non native English speakers
“Don't give me any lip” would be something said by someone who received an impudent, insolent, and impertinent reply.
They perceived that they were addressed in a very disrespectful or cheeky manner.
Typically, “don't give me any lip” is spoken by an adult to someone younger, often parents to their children.

EDIT:
resulting in huge complex scripts full with IsYUY2? : constructs. And a small speed penalty.
Assuming that we are not in runtime environment eg scriptclip, then any IsYUY2 would only execute during graph building stage anyway [maybe 50us]
with only any ConvertToYV16 [and back again] embedded in the filter graph, whereas if user converted to YV16 before calling script function,
then same converToYV16 [and maybe back] would be called outside of script, no great difference really except in human intervention time.
If input colorspace is already YV16, then the IsYUY2 stuff is pretty much irrelevant, unless in runtime environment, eg scriptclip.
Of course it would be best if input is already YV16, but aint nuttin' wrong with having a safety value to stop it exploding.

[tormento]

Just to satisfy my curiosity: what is the speed advantage to create its own dll instead of avsi?

I mean, how much is the penalty between avisynth interpreting a script and instead executing a dll?

[StainlessS]

In the main, avisynth script is only used to 'stitch' filters [dll or in-built] together, once frame serving starts no huge great difference
unless using runtime environment somewhere [eg Scriptclip], implementing any runtime environment script as dll filter would/might make a big-ish difference though.

My first attempts at RgbAmplifier() script function [for user Forensic], was real slow [cant remember how slow, something like 15 secs per frame],
conversion to dll where method a near copy of script function [with a few shortcuts] was I think about 76,000 times faster.
Most Scriptclip functions would NOT exhibit that kind of improvement, that script function manipulated R, G, & B components for each individual pixel.

RgbAmplifier:- https://forum.doom9.org/showthread.php?t=168293

EDIT: Another script functions, S_ExLogo(), simply stitches together a few Crop(), BilinearResize(), StackVertical(), StackHorizontal(), and Layer() filters together,
and that goes like the clappers [FAST, does not use runtime environment], and doing same as dll would not make any vast improvement to speed [maybe none worth mention].

[tormento]

In the main
:thanks:

So MCTemporalDenoise is a good candidate. xD

[StainlessS]

Probably not, also dont think anybody would want to take that on as a task.
I've never actually used McTemporalDenoise, just took a little look at it and there is a lot of it, but again just seems to stitch together a load of filters.
Something like sRestore might benefit (I think that uses scriptclip or some other runtime filter, not sure), but again dont think anybody would want to do it.
(and more difficult to modify CPP, also not good if any non built-in filters used, cannot rely on external dll filter being correct version etc)

[Stereodude]

If you are gonna remove functionality, maybe also a name change is prudent (as MeteorRain did for the FF3DFilter/NeoFFT3D),
Maybe McTemporalDenoiseNeo(). If it makes sense for the dll, why would it make less sense for a script function which is similarly enhanced/crippled.

[Either that or continue original support with script work arounds where HBD, call original dll where Neo-dll not available, or where YUY2].
Well, it is listed as "experimental". Currently if someone wants the extra speed from using NeoFFT3D they can't use YUY2 because NeoFFT3D doesn't support it. I'm sure there's any number of solutions ranging from the script changing YUY2 input to YV16, forking the script, etc. Which one is the right one, I'm not sure. I have no idea if most of the filters used by MCTD support YV16.

FWIW, I wasn't intending to become the maintainer/developer of MCTD. I just made a few easy changes to something that's about a decade old (and still the best Avisynth NR plugin I know of).

[StainlessS]

Maybe I should give it a try, when I see that many parameters, I just think, "Not today Josephine".
I also dont often use QTGMC, seems to use way too much noise reduction or something [by default],
I'de rather use my own NR which inevitably would be McDegrainSharp(), use it for nearly everything.
(Somebody else recently made the QTGMC default noise observation, and that is exactly why I'm not overjoyed by it).
EDIT: I dont think you can switch OFF noise reduction altogether in QTGMC, thats what I would prefer.

I wasn't intending to become the maintainer/developer of MCTD.
Tag, you're 'it'!

https://thegrammarexchange.infopop.cc/topic/tag-you-re-it

[tormento]

Maybe I should give it a try, when I see that many parameters, I just think, "Not today Josephine".
The same reason for me to use SMDegrain almost every time but a few really peculiar situations.

[StainlessS]

Thats another one that I know is used by many, and I have yet to try it.
(I recently download both scripts and will try them one day).

[Boulder]

EDIT: I dont think you can switch OFF noise reduction altogether in QTGMC, thats what I would prefer.

I've been using QTGMC parameters SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1 and tr2=0 for years. I think the result looks pretty much non-denoised, got those other parameters except tr2=0 from the author himself so I think they are as good as it gets.

[real.finder]

I'm sure there's any number of solutions ranging from the script changing YUY2 input to YV16, forking the script, etc. Which one is the right one, I'm not sure. I have no idea if most of the filters used by MCTD support YV16.


that is the problem, some developers remove the YUY2 from plugins then scripts that use that plugin was made with YUY2 in mind will not able to use YUY2 after update, and not all other filters work with YV16 so it's now only YV12 script filter :)

that why I did some edits for these cases in SMDegrain and QTGMC back then, nowadays SMDegrain can work with all avs+ colors (Except motion analyzing with float clip) but QTGMC still not yet

[StainlessS]

Cheers Boulder, I'm taking note of that and gonna try it out with those args. :)

EDIT:
real.finder, good post, you nail'd it dead.

[real.finder]

Stereodude

since you start work on this, will you keep going? I think you can even add basic HBD if you tried (of course not for all setings since not all dlls work with HBD yet)

if you already stopped maybe I will do it myself

[StainlessS]

I've been using QTGMC parameters SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1 and tr2=0 for years. I think the result looks pretty much non-denoised, got those other parameters except tr2=0 from the author himself so I think they are as good as it gets.

I tried your posted settings in my (pretty much standard) script, and am probably as happy as I'm ever gonna be, so thanks for the nudge, working well. :thanks:

EDIT: I also added NoisePreset="Faster" ("Faster" by Default but changeable, your args are fixed although I might try change to Sharpness=0.0, I do my own sharp thingy later).

[tormento]

I tried your posted settings in my (pretty much standard) script, and am probably as happy as I'm ever gonna be, so thanks for the nudge, working well.
I always wondered myself why QTGMC has a denoise part or, at least, it's not possible to disable it at all. There are much better scripts out there to do that filthy job. :p

[hello_hello]

tormento,
The old help file says QTGMC naturally denoises due to multiple temporal smooths. The way I read it, QTGMC needs to identify the noise and then restore it after de-interlacing.

It appears if you want to retain some noise, which personally I rarely do, you need to use a setting such as EZKeepGrain to put it back. The help file says Lossless=1 restores the exact source pixels to the output (I assume that refers to the original scan-lines) but may result in artefacts. Lossless=2 makes the output lossless before the final sharpening and temporal smooth.

SourceMatch seems to be a way to retain detail without actually being lossless, although the help file says it can also faithfully reproduce artefacts such as blocking and banding, with higher modes being sensitive to noise, and could possibly cause occasional aliasing. It does mention that SourceMatch can reduce haloing, which I'd forgotten about, so I might try it myself as QTGMC does tend to enhance existing halos with the default settings.

It seems noise can only get in the way of de-interlacing. If QTGMC didn't deal with it in some way it'd probably look more like Yadif.

In QTGMC's denoising defence, I dug out an old torture test clip and ran some comparison denoising encodes. It's nothing definitive, because I didn't play around with settings much, but they're all denoisers I'd use. Even though the source is progressive (I assume it was originally progressive as outdoor scenes were generally shot on film), and looks like it might have been unnecessarily de-interlaced, that probably also makes it an example of the shimmering and aliasing that would result if you de-interlaced without denoising a noisy clip first. QTGMC does the best job of settling that down, and I had to use MCTD's highest settings for it to compete, although QTGMC can sometimes produce artefacts other denoisers don't. Whatever works for a source.

Denoising Comparisons.zip (https://files.videohelp.com/u/210984/Denoising%20Comparisons.zip) (58MB)