QTGMC Deinterlacing Script (v3.32)

[fusebyte]

I tried with EAC3TO. Very good output and remuxable with MKVMERGE to add SRT sub track without any playback problem but I would wish try with QTGMC encoder
and don't understand how start avs script with cmd QTGMC inside.
I always obtain errors, I'm sure that's just my fault.

[dragon_warrior]

I tried with EAC3TO. Very good output and remuxable with MKVMERGE to add SRT sub track without any playback problem but I would wish try with QTGMC encoder
and don't understand how start avs script with cmd QTGMC inside.
I always obtain errors, I'm sure that's just my fault.
:script:
and
:logfile:

[Lyris]

First time user here.

That is magnificent. Thank you.

[Aktan]

First off, great job on this script. It does wonders. Now I do see it as being very very slow. I'm curious to know if it would be faster if it was combined into one plugin instead. I would think some of the work is redundant because you are using different plugins and they aren't talking to each other.

Minor comment bug report:

for MatchPreset2 table, the Very is on top of Placebo, making it look like "Very Placebo" instead of "Very Slow"

[dirk362]

I get a DLL error with only certain Presets ???

The example AVS below works fine
LoadPlugin("E:\Tools\Applications\DGMPGDec\DGDecode.dll")
SetMemoryMax(1024)
SetMTMode(5,6)
MPEG2Source("D:\temp\inputfile temp files\inputfile.d2v", CPU=6)
SetMTMode(2)
AssumeTFF()
ConvertToYV12(interlaced=true)
Import("C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.11.avsi")
QTGMC( Preset="Slower", EdiThreads=3 )
SelectEven()
However, if I change to
QTGMC( Preset="Very Slow", EdiThreads=3 )
I get the error message of
FFT3DFilter: Can not load FFTW3.DLL !
(C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.11.avsi, line 632)
(D:\temp\inputfile temp files\inputfile.avs, line 9)
This occurs for Placebo and Very Slow only. All other presets work fine.
I'm fairly confident I've not messed up any of the pre-reqs. And the file does exist in both the plugins directory for AviSynth and also in the path.

Any ideas anyone ?

Thanks in advance

[dirk362]

I get a DLL error with only certain Presets ???

FFT3DFilter: Can not load FFTW3.DLL !
(C:\Program Files (x86)\AviSynth 2.5\plugins\QTGMC3.11.avsi, line 632)
(D:\temp\inputfile temp files\inputfile.avs, line 9)

OK - I've been a bit thick for which I apologise. The issue was that as this is 64-bit Windows I need to have FFTW3.DLL in the C:\Windows\SysWOW64 directory (even though that's not in the path as an environment, the OS sorts this out by recognising it's a 32-bit app).

So thought I'd post for those on 64-bit OS but still using 32-bit AviSynth that you need to think about SysWOW64 directory as well. Doh !

[-Vit-]

Atkan: it's only as slow as your preset and computer. Seriously though, regarding plugins "talking to each other", there's not much redundancy in the script - that's not really the problem. It's the enormous number of operations that makes it slow. Some ideas I have for speed are:
- Using the GPU to do the simpler per-pixel tasks
- Using simpler algorithms for the chroma deinterlacing
- Reducing the cache load, to improve performance on very complex settings
I'm working on all three of those ideas.

Writing a QTGMC-custom plugin might bring some benefits, most notably being able to combine some of the simpler operations. That is partly what I'm intending to do with the GPU point above...

EDIT: Well spotted on that typo! Hmmm, "Very Placebo", I'm sure there are some people who would like that option...
____

dirk362: easy mistake to make - I've updated the requirements in the OP to briefly note the issue

[kypec]

EDIT: Well spotted on that typo! Hmmm, "Very Placebo", I'm sure there are some people who would like that option...

Sorry for being such numb but what exactly is affected by this bug (seeing that you did not mention any bug-fix released yet)?
If there is preset "Very Slow" used in the script, does it work as intended or not?:stupid:

[-Vit-]

It was just a mistake in a comment. No effect on the script.

[Vitaliy Gorbatenko]

Bad way to connect their modules through the autoload and :\windows\* directory
It is better to copy its modules to the selected directory, for example:
x:\Knot\AviSynthPluginsx64\
and connect them in a script:
SetWorkingDir ("x:\Knot\AviSynthPluginsx64\")
LoadPlugin ("average.dll")
...
and so on.
And with the re installation of the system problems will not arise and can be accurately select Plug-ins, and syntax is reduced.

PS: but this is my personal opinion.

[-Vit-]

I assume that post refers to the FFTW3.dll issue above... FFTW3.dll is not itself an avisynth plugin. It's a module used by FFT3DFilter. You can't use LoadPlugin on it. Using SetWorkingDir alone will work (as long as no plugin or other script changes the working directory... :eek:)

[fusebyte]

My wish?
Some expert makes a GUI for QTGMC.
I honestly am not able use it... just my fault.

greetings

[Dogway]

@fusebyte: be a bit more thankful by turning the complain into a petition. Its a hard work of one guy for free, but GUI? this is avisynth...

[henryho_hk]

I just notice (or re-discover) a pattern that QTGMC() fails but TGMC() works.

Pick a true intelaced footage (say, NTSC) that has a solid black 1-pixel line at row 478 on every frame. After bobbing, QTGMC() will have the black removed on even frames, and a 2-pixel-high black line on odd frames. TGMC() keeps the 1-pixel black line on every frame.

[-Vit-]

You didn't note your settings [or did you literally use QTGMC()?].
No time to check right now, but maybe Border=true or SVThin=1.0 will restore same behavior. They are defaults changed from original TGMC
[Why? My material never needs Border=true, it can cause occasional artefacts of its own and is a *tiny* bit slower. SVThin - I just don't like the results]

[henryho_hk]

It's TGMC(tr2=3,EDIMode="NNEDI3") vs QTGMC(Preset="Slower",tr2=3). I also notice similar behaviour in sadie's DV sample. His DV seems to leave the topmost line black in some scenes, and after QTGMC(), the black line will disappear and then duplicate on alternate frames.

[-Vit-]

I looked at sadie's example - I don't see a topmost black line - I see a darker line on the second line. And, yes it dances on QTGMC defaults - and the difference from TGMC is that you need Border=true.

The QTGMC docs say of Border: "set true you see flickering on the very top or bottom line of the output" (yep I guess that needs to read 'lines')
There's section at the end of the docs comparing with TGMC which also answers this question.

You set edimode="nnedi3" on TGMC, only modded versions of beta2 support nnedi3, in the original version that will just do a bob. So let's be exact:

TempGaussMC_beta2() is the same as:
TempGaussMC_beta2( 2,2,1, 4,0,4, "eedi2" ) is the same as:
QTGMC( preset="Slower", edimode="eedi2", border=true, svthin=1.0, lsad=1600, precise=true )
[Corrected - thanks Taurus]

The other default differences: Precise switches on/off barely visible steps for a small speed-up. lsad is different because the MVTools documentation is especially confusing on whether that setting should be scaled by blocksize - I had to read the MVTools source code to find that it shouldn't be.

[nhope]

I made a quick reference table of how the presets affect the settings. I'm deinterlacing 1080i so I've used "faster" as the benchmark.

http://dl.dropbox.com/u/21489814/QTGMC-presets.png

[Taurus]

TempGaussMC_beta2() is the same as:
TempGaussMC_beta2( 2,2,1, 4,0,4, "nnedi2" ) is the same as:
QTGMC( preset="Slower", edimode="nnedi2", border=true, svthin=1.0, lsad=1600, precise=true, nneurons=2 )

@Vit
Are you sure TempGaussMC_beta2() uses "nnedi2" as default?
From the TempGaussMC_beta2.avsi:
# Defaults for EDI interpolation
EdiMode = default( EdiMode,"EEDI2")
Same for TempGaussMC_beta2u.avsi mod (nnedi3 support).

[-Vit-]

Taurus: You're right! I changed my version a long time ago to default to nnedi2, and forgot. I've edited the post above. The equivalence is still there, QTGMC supports EEDI2 also.

nhope: Thanks for that. The presets gradually change. The upcoming version has some noise-related changes because I've brought in [motion-compensated] dfttest.

[kypec]

@ nhope & -Vit-
Would be nice if you could upload that preset table and made it available on GoogleDocs (not necessarily editable by others)
I'm sure it could be helpful for further development/discussion/changes tracking of this wonderful QTGMC script, thanks!

[kolak]

3.11 works much more stable.
About 30fps for 60i SD (slow preset) on 2x X5450. 8 cores at 90%.

Used on 60i footage, which had real 60i, badly deinterlaced 60i, 30p and 23.976+pulldown- hahhaha. Final result 29.97p upscaled to HD plays smooth :)

Amazing piece of script :)
Thanks Vit.

Andrew

[aegisofrime]

3.11 works much more stable.
About 30fps for 60i SD (slow preset) on 2x X5450. 8 cores at 90%.

Used on 60i footage, which had real 60i, badly deinterlaced 60i, 30p and 23.976+pulldown- hahhaha. Final result 29.97p upscaled to HD plays smooth :)

Amazing piece of script :)
Thanks Vit.

Andrew

Wait a minute, 30fps for 60i SD for dual X5450s? I know from a report of a fellow QTGMC user that a i7-2600K gets 57fps on slow preset. Granted, that is with encoding to lossless, so perhaps you are using very slow x264 settings? Or perhaps you have not multi-threaded your script properly?

[nhope]

@ -Vit- - I'll try to remember to go back and update it when your new versions come out.

@ kypec - Version with "faster" as the benchmark (https://spreadsheets.google.com/ccc?key=0AtvvpQjptJLFdGxFaEZwNDNXdGliTi1KdElEUEVtTHc&hl=en) & version with "medium" as the benchmark (https://spreadsheets.google.com/ccc?key=0AtvvpQjptJLFdGVGQzFUa0ozWTZJYXItLWFFTURBMXc&hl=en). I just changed the colours to make it easier to visualise the effect of changing the presets, depending on your preset starting point.

[kypec]

@ nhope: Many thanks for your contribution.
@ -Vit-: please copy that spreadsheets links to your first post in this thread for convenience, thank you.

[nhope]

In my script I am following QTGMC with a SelectEven() and a LanczosResize(1280,720). For multi-threading, should I put Distributor() before or after these lines?

[kolak]

Wait a minute, 30fps for 60i SD for dual X5450s? I know from a report of a fellow QTGMC user that a i7-2600K gets 57fps on slow preset. Granted, that is with encoding to lossless, so perhaps you are using very slow x264 settings? Or perhaps you have not multi-threaded your script properly?

It's from Canopus Lossless to Canopus Lossless- no encoding :(

setmtmode(mode=5, threads=8)
avisource("R:\SD.avi",audio=false)
converttoyv12(interlaced=true)
setmtmode(mode=2)
QTGMC( Preset="slow", EdiThreads=4)
converttoyuy2()
selecteven()


EdiThreads=4- tried different values- nothing helps.

Any idea?

X5450 are quite old- way slower than i7.

I was using avisynth 2.5.7.5 MT dll. Updated to 2.5.8 and now it's crashing much more :(

Andrew

[-Vit-]

nhope: Firstly you can do the horizontal resize (to 1280) before the QTGMC call for a good speed up without loss, just do the vertical resize afterwards.

Distributor() goes at the end of the script. You may not need it - it depends what encoding GUI you use. Try it without.

[nhope]

nhope: Firstly you can do the horizontal resize (to 1280) before the QTGMC call for a good speed up without loss, just do the vertical resize afterwards.
Thanks for the tip. I had wondered about that. Sorry to stray off topic but if I am resizing in one direction at a time as you suggest, is Lanczos3 still a sensible algorithm to use? I am downscaling to 1280x720 from 1920x1080 or 1440x1080 anamorphic.

Distributor() goes at the end of the script. You may not need it - it depends what encoding GUI you use. Try it without.
I am using x264 in MeGUI. Do you know if that normally requires Distributor()? I am only using a Core 2 Duo here in 32-bit XP and when I tested multi-threading without Distributor I had a slight speed drop over ST when I included Distributor and a crash when I didn't. I guess it's not worth attempting MT with a Core 2 Duo but I'm writing a QTGMC/MeGUI tutorial that will be read by a lot of quadcore+ users so I want to guide them the right way.

[-Vit-]

All avisynths resizers operate in two passes anyway (horizontal and vertical). So you don't need to do anything different if you split it up like this and there's no performance penalty from resizing twice in this particular way.

MeGUI requires Distributor(). The MT docs in the OP and in the script apply best to those with 4+ cores. With less cores there is less scope for MT tweaking, especially at HD, but if you ever see your CPU is not close to 100%, then you should see if you can get more out of MT (unless you have stability issues).

kolak: Try all versions of MT avisynth, everyone seems to have different stability results. Some find 2.6MT works well.

[jpsdr]

@kolak : Try eventualy xhmikosr builds (if it's not already the case) here (http://xhmikosr.1f0.de/).

[Didée]

Additional oddities stem from the fact that (all!) plugins *should* be compiled with the corresponding libraries of the targetted Avisynth version. A plugin for vanilla 2.5.8 should be compiled differently for 2.5.8.MT should be comiled differently for 2.5.7.MT should be compiled differently for 2.6 should be compiled differently for 2.6.MT.

If not, be prepared to experience problems.

Has it already been noted that Avisynth MT is an unutterable, giant mess?

[dirk362]

This statement about resize horizontal first for speed-up intrigues me ... Can I ask a couple of stupid questions in terms of sequence then ?

1. Should you perform the horizontal resize before QTGMC ?
2. For point 1 should it be new horizontal x cropped height ?

I appreciate these are not totally specific to QTGMC, but it seems people are talking about speed-ups and I'm just not seeing this when I test it. Of course I can perform lots of different tests to come up with the answer although I'm guessing given the posts in this thread so far there is a "known" way to achieve this...

As an example if I have source of 544x576 and have crop of 2,2,-2,-4 this gives me an effective image size of 538x572. If I'm working to 640xwhatever (accepting this is upscaling), should I therefore have something like:-

Crop(2,2,-4,-2)
Spline36Resize(640,572)
QTGMC( Preset="Faster", EdiThreads=4 ).SelectEven()
Spline36Resize(640,352)

[-Vit-]

Ah, no... that trick is only a speed-up if you're downscaling. QTGMC's speed is directly proportional to the number of pixels in the material it is given. So give it the lowest possible resolution. If you're downscaling, doing the horizontal resize first gives QTGMC less to work on. You can't do the vertical rescale before QTGMC because you'd destroy the interlacing.

However, if you're upscaling you should QTGMC the original smaller resolution.

[dirk362]

Ah, no... that trick is only a speed-up if you're downscaling. QTGMC's speed is directly proportional to the number of pixels in the material it is given. So give it the lowest possible resolution. If you're downscaling, doing the horizontal resize first gives QTGMC less to work on. You can't do the vertical rescale before QTGMC because you'd destroy the interlacing.

However, if you're upscaling you should QTGMC the original smaller resolution.

Thanks. That makes perfect sense and I guess if I'd engaged my brain just a little more I'd have realised part of that question was just plain daft as veritcal is what you're effectively working on via the deinterlace.
But it now makes sense, so thanks for imparting knowledge. If we didn't ask we wouldn't learn :)

[nhope]

I have written a tutorial for preparing video for the web using the following workflow:

http://dl.dropbox.com/u/21489814/workflow.png

I was going to use TDeint+nnedi3 as the recommended deinterlacing method until I discovered QTGMC. -Vit- and Didée (not to mention tritical et al), thanks for this brilliant script.

The tutorial is here (http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm) and we're discussing it on the Sony Vegas Pro forum here (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=752833). If anyone has any feedback, please let me know.

John Meyer tried it an made some interesting findings regarding multi-threading QTGMC, which can be read about 30 posts down that thread. I've asked him to report his findings here too.

[Didée]

John Meyer tried it an made some interesting findings regarding multi-threading QTGMC, which can be read about 30 posts down that thread. I've asked him to report his findings here too.
Well, speking "generally", his finding is simply wrong. Both QTGMC & TGMC can happily use more than 4 threads. Right now, I've a (TGMC) script running with all 8 Threads on my i7-860 fully utilized. CPU usage oscillates in range 95%~100%.

The key is resolution. With SD input, getting full CPU load is no problem at all. However, with 1080i it's a problem indeed. CPU usage is much lower then. For the exact reasons - don't ask me. It must be related to all the memory shuffling that's going on under the hood. Somewhere there is a borderline, and 1080i is definetly located on the other side. :(

[-Vit-]

Ideal thread counts differ by hardware, by settings and by source resolution. Also by what you're encoding with/to. On default settings I run SD at 13 threads for best speed, full HD at 8 threads. I have seen people indicate anywhere from 2 to 14 threads as their ideal. With HD material 4 threads is a good start, and it can be tricky to get stability and balance memory with more. But it is certainly not a hard limit - don't make the mistake of thinking that threads are tied to physical cores (it's possible for a developer to specify this, but it's not the norm).

[-Vit-]

Regarding multithreading HD material, you need to work SetMemoryMax properly. But I haven't seen it explained in detail anywhere, so here goes:

SetMemoryMax effectively sets two memory limits:
- The number you provide is the maximum memory used for the avisynth cache*
- (2Gb - the number you provide) is the maximum memory reserved for everything else used by your script (e.g. avisynth itself, NNEDI3, MVTools) - that's on a 32-bit workflow
- With 64-bit avisynth, it's more like (available physical memory - number you provide) reserved for plugins etc.

That means as you increase SetMemoryMax, you are reducing the amount of memory available for the plugins like NNEDI3. Plugins working on HD or complex settings will need considerable memory. Even more so when multi-threading because each thread needs plugin memory. So if you set memory max too high -> script failure.

The nature of a cache means that it always will fill up whatever space it is given (except in trivial examples). But it only actually needs to cache those frames that will be reused. Once those are in the cache, making it larger will have no positive effect at all, but it will reduce memory available for plugins.

That means there's a sweet spot, where you've reserved just enough to cache the needed frames and no more. So you [B]do not simply set the value larger and larger for higher resolutions. Go above the sweet spot and you may exhaust memory with no benefit. Go below the sweet spot and it will slow down because frames are not found in the cache (or more usually it will crash - there must be bugs in the avisynth caching). I find the sweet spot for HD around 700-800 but YMMV.

At some point you hit a limit, where: (memory needed for the avisynth cache) + threads x (memory needed for plugins) > your available memory. The formula depends on the factors I noted in the last post - it sets a limit on the number of threads you can run. It might not be enough threads to max out your CPU.

* The memory max figure is actually just a target. Internally, if avisynth desperately wants to cache something it can exceed the value you set. That's one reason why the behaviour is so hard to predict.

[-Vit-]

The latest version, v3.20, is in the first post (http://forum.doom9.org/showthread.php?t=156028). There are three areas of improvement:

Documentation
Most documentation has been stripped from the script itself and put in a separate HTML file. In Avisynth livery. All the new features below are explained in detail in there.

Noise processing / Denoising
I've improved the noise processing in several ways and made it simpler to use:
- Supports chroma noise processing / denoising (set ChromaNoise=true, it defaults to false)
- Supports dfttest as an alternative to fft3dfilter. I added this when I saw what strange results fft3dfilter produces on chroma denoising. I might post about that experience elsewhere. dfttest seems to identify noise vs detail more accurately
- Can provide a motion compensated clip to the denoisers, which further improves noise vs detail detection
- New "EZ" modes of operation which allow denoising or grain retention with just two settings. You set a value to indicate the strength of effect and a preset to determine quality of processing (presets from "Slower" to "Faster" only - used to make choices for the other settings: denoiser, motion compensation etc.). Examples:

# Automatic denoising, value is denoising strength, preset is quality/speed tradeoff
QTGMC( Preset="Slower", EZDenoise=2.5, NoisePreset="Slow" )

# Automatic grain retention - set amount of grain to retain, can be > 1.0
QTGMC( Preset="Slower", EZKeepGrain=1.0, NoisePreset="Faster" )


Access to QTGMC Motion Vectors
QTGMC now sets various uniquely named globals to give the calling script access to its motion vectors and more. Saves time recalculating vectors. Refer to the documentation (the "External Linkage" section) for complete details. Here are some examples:

# Use QTGMC motion vectors for our own smoothing
QTGMC( Preset="Medium", ForceTR=2, SubPel=2 ) # Ensure we get temporal radius of 2 and match Pel setting with next line
super = MSuper( pel=2, levels=1 )
MDegrain2( super, QTGMC_bVec1,QTGMC_fVec1, QTGMC_bVec2,QTGMC_fVec2 ) # Use QTGMC-created motion vectors

# QTGMC can reuse its own vectors. Here repairing progressive material with serious deinterlacing artefacts
t = QTGMC( Preset="Slower", InputType=2 )
b = QTGMC( Preset="Slower", InputType=3, PrevGlobals="Reuse" ) # Reuse motion vectors from first call for a good speed-up
Repair( t, b, 1 )

I'll post about the techniques I'm using for this later. I see this as the first step towards breaking QTGMC up into a set of independently usable components.
____

Full Version Changelog:
* Motion vectors made available to calling script (see External Linkage), added related GlobalNames, PrevGlobals and ForceTR settings
* Added simplified noise processing settings: EZDenoise, EZKeepGrain and NoisePreset
* Support for dfttest as denoiser for noise processing - added settings Denoiser and DftThreads
* Added ChromaNoise setting to optionally enable chroma noise processing
* Added DenoiseMC setting to use motion-compensated clip for denoising, improves detection of noise vs detail
* Replaced fft3dfilter-specific BT setting with NoiseTR setting to set temporal radius for denoiser.
* Added StabilizeNoise setting to "stabilize" & "deshimmer" noise restored in noise bypass (was part of "Generate" mode)
* Dropped NoiseRemove setting, now always removes all noise specified by given Sigma (enough controls already!)
* MotionBlur renamed to ShutterBlur, MBlurLimit renamed to SBlurLimit, DetailRestore renamed to GrainRestore (old names gave wrong impression)
* Bug fixes: stabilization of "Generate" noise mode, manually enabling SLMode with SourceMatch
* Documentation converted to HTML

[SubJunk]

Thanks for the update!

[nhope]

Preset tables updated for 3.20:

Compared to "faster" (https://spreadsheets.google.com/ccc?key=0AtvvpQjptJLFdGxFaEZwNDNXdGliTi1KdElEUEVtTHc&hl=en&pli=1#gid=0)
Compared to "medium" (https://spreadsheets.google.com/ccc?key=0AtvvpQjptJLFdGVGQzFUa0ozWTZJYXItLWFFTURBMXc&hl=en#gid=0)
Noise presets (https://spreadsheets.google.com/ccc?key=tjcarn1zieM-8yvT5wENEYA#gid=0)

[kypec]

Many :thanks: for big improvements and mostly simplified usage of your script!

[aegisofrime]

Many thanks -Vit- for the continual development of this awesome script!

I have been wondering one thing...

AFAIK, there isn't a 64-bit version of Dfttest right? Yet when I modified my 64-bit script to use Dfttest as a denoiser, to my surprise it worked. So I was wondering, might there be a bug in the script that isn't calling Dfttest properly?

Here's my QTGMC settings, for reference.

QTGMC(Preset="Slower",ChromaNoise=True,denoiser="dfttest",DenoiseMC=True)

[henryho_hk]

If anyone has any feedback, please let me know.

1) do not resize vertically before deinterlace
2) you may need "interlaced=true" for ConvertToYV12()

[pokazene_maslo]

AFAIK, there isn't a 64-bit version of Dfttest right?
Here is dfttest x64: http://forum.doom9.org/showthread.php?t=152800 but only an older version

:thanks: for chroma denoising support.
I have couple questions:

NoiseDeint parameter: is it used when GrainRestore and NoiseRestore are 0?
fft3dfilter is missing interlaced=true parameter, is that intentional?

Once again thanks!

[-Vit-]

nhope: Thanks for the updates. I've added them to the OP

aegisofrime: Are you sure you don't actually have the 64-bit dfttest? Those settings will certainly select it. To test if dfttest is really being used, temporarily remove its dll from your plugins folder and try to run your script. If it comes up with a "can't find dfttest" error then you really were using dfttest.

pokazene_maslo:
1. NoiseDeint is only relevant if you are have either GrainRestore > 0 or NoiseRestore > 0, i.e. if you retaining grain rather than denoising. It is set automatically by NoisePreset. [This reminds me that I didn't mention the obvious: EZDenoise and EZKeepGrain are mutually exclusive]
2. Yes, that is intentional. Firstly, dfttest doesn't support interlaced input. Secondly, it's impractical to motion-compensate interlaced input for the denoisers (DenoiseMC=true). So I use a point resize on the fields to get something I can feed to the denoisers that matches the motion vectors. The point resize will not blur the noise and the denoisers seem to be able to handle the line doubling. After the denoise I drop the doubled lines and reweave the result to get noise to match the original interlace. Or put more simply, I implement "interlaced=true" manually in the script.

[aegisofrime]

In fact, I was unaware that there was a 64-bit dfttest before pokazene_maslo told me about it. I remembered checking a few times to make sure whether there was a dfttest.dll in my plugins64 folder. There wasn't.

[-Vit-]

aegisofrime: Just looked again at your QTGMC line. Although you're selecting dfttest you're not actually doing any denoising, that's why it isn't showing any error. I think I should make the documentation clearer and maybe rename the NoiseBypass setting to NoiseProcess

[aegisofrime]

aegisofrime: Just looked again at your QTGMC line. Although you're selecting dfttest you're not actually doing any denoising, that's why it isn't showing any error. I think I should make the documentation clearer and maybe rename the NoiseBypass setting to NoiseProcess

Ah, I see. I needed NoiseByPass to be "1" or "2". Yes, I would say that the name of the setting wasn't exactly intuitive :p