M_QTGMC script error

[SVAPrjm]

Playing around with M_QTGMC and getting the following script error in Avisynth+:


[Attachment 87113 - Click to enlarge]

Can anyone point me in the right direction as to what I need to do here? Thank you!

[hello_hello]

I don't know for sure, but I suspect it requires this version of MVTools:
https://github.com/DTL2020/mvtools/releases

[SVAPrjm]

Yeah that didn't work either


[Attachment 87121 - Click to enlarge]

[DTL2023]

I don't know for sure, but I suspect it requires this version of MVTools:
https://github.com/DTL2020/mvtools/releases

The latest build of that branch of mvtools was not really released in the repository of mvtools2 and was only included with archive with latest release of M_QTGMC (may be sort of next r.2.7.46-a.30 tagged release). After pinterf made 2.7.46 release I do now know how to better name that branch files and they can not be mixed in the installation because uses same functions names. So the only way to use that branch builds is to load locally (or from some folder pointed by path in LoadPlugin() ?) . Also they can not be mixed in single script (AVS process) anyway. With the number of changes it may be numbered as mvtools 2.8 or even 3.0. But as about no one uses this after home video processing is died in 202x it may be no any difference how it is named. The last video processing in the dying civilization is AI-based and no need linear logic implementations.

So the correct way to use M_QTGMC is unpack all files from archive to single folder and load mvtools2.dll locally into source script. As was described in https://forum.videohelp.com/threads/404164-Why-is-QTGMC-so-destructive-and-why-do-so-m...e3#post2734199

Other way is to download latest sources from github and build the latest version.

Also the main idea of M_QTGMC may be used with pinterf branch of mvtools2 after removing all new features and left only available for that branch variation of parameters in several calls to QTGMC and select the most different samples values using either plugin mostdiffval.dll or Expr() based implementation (somehow slower but require AVS core only).

So someone may make M_QTGMC version using only usual QTGMC script and branch of mvtools2 from pinterf. It still allow to use different block size and other significant different MAnalyse settings like truemotion on/off. Also Area-mode motion search may be somehow simulated with several offsetted copies of clips (like extended overlap processing down to all integer samples positions shift instead of overlap= blksize/2 only).

[DTL2023]

Reduced version of M_QTGMC() script to work with old versions of mvtools2 (up to 2.7.46 release by pinterf) - https://github.com/DTL2020/QTGMC/releases/tag/m_0.2old_mvt

It still works somehow better in comparison with QTGMC(preset="slow"). Test/compare script example included in the release archive. Also expected to be much faster without new complex motion estimation modes for MAnalyse. Currently highest complexity preset M_QTGMC_high() looks also working and make some better result (but even much more slower).

Also I see users reports new version of mvtools2 from DTL branch sometime unstable or cause green frames/distortions. The version by pinterf up to 2.7.46 expected to be much more stable.

Some comparison at running animal capture (VHS-like)
https://imgsli.com/MzgyNjA0

Also there is an idea to make QTGMC with RIFE interpolation engine for comparison instead of mvtools. Though it also fails on low quality blurry content like VHS captures.

[Selur]

how about using a faster preset?

[DTL2023]

I really don't understand your question very well. Is this preset not working ? Any errors displayed ?

I know you release Hybrid processing windows GUI software and I see it is used in our company by some users. As the simplified M_QTGMC script is compatible with the expected stable branch of mvtools2 (by pinterf) - you can add this version of script to Hybrid and it will be available to more users.

The named presets in M_QTGMC are not any final and no fine tuned sets of params - it is only my ideas from 2024 of what it may look like (for quality/performance balance) and need lots of testing and more fine tuning.

Currently included as faster presets in comparison with 'medium':
M_QTGMC_low()
and
M_QTGMC_medlow()

I not test that presets very much.

I update the version in repository https://github.com/DTL2020/QTGMC/blob/main/M_QTGMC_old_mvt.avsi (commit https://github.com/DTL2020/QTGMC/commit/228578d4fc083e6375877d4fc36163e788ea18e3 ) - it should run faster at _low and _medlow presets if you like to see even more faster but somehow lower in quality processing.

Though it is expected if user want higher quality processing in comparison with simple QTGMC(present="slow") - it is worth to use at least 'normal' or higher quality presets.

[Selur]

My point was, that you should compare not just preset 'slow', but other presets like 'fast' too.
blindly using a slower preset in QTGMC doesn't necessarily mean better detail preservation. QTGMCs general goal is not detail preservation,..

[DTL2023]

Initially M_QTGMC was designed while using QTGMC with its default (?) preset 'slow'. So it is a comparison of QTGMC with most internal presets of params of 'slow' (except variable in M_QTGMC and a few defaults) vs next level of external wrapper to gather most details from several QTGMC runs. If you know some more magic combination of about 100 QTGMC params for better results you may test it and even post your version of a script with such params.
The usage of external detail-gathering wrapper makes more freedom for the user because with a single filter run the user must select some single set of params to make most of the frame/scene/clip to look about good as some weighted average. And with an external detail-gathering wrapper with sample-level granularity, an intraframe user can make more fine tuning of params in each filter run and possibly get a more detailed output result (again somehow weighted average).

If you doing GUI software for using of AVS scripts and have somehow supported QTGMC (or really any other filter with different results at different areas of the frame with different params settings like any denoise/deinterlace and other filters) - you can also implement same idea of details gathering from different filter runs as currently implemented in M_QTGMC wrapper. Its solution is not perfect but somehow working (on per-sample granularity). Other solutions may be based on block analysis or FFT based and may be some AI-based. See how the function of GetSharpest(clip1, clip2) is implemented in M_QTGMC.

So for GUI-based software expected design: For each filter with required multi-runs details gathering add a (drop-down ?) list of filter params for each run (at least 2 or more) and generate same as M_QTGMC script at runtime with the provided by user params for each filter run. I hope GUI can save projects with all provided params for each filter so users do not need to remember and enter lots of params each time. Also presets may be saved too.

The expected workflow for users with such software:
1. First make several single filter runs with required footage for processing and remember the best combination of filter params making better at least some areas of a frame/scene/clip.
Example: With MAnalyse it is known to make MVs for some areas better and for other areas worse with varying input clip pre-processing of setting truemotion on and off and setting different block size. So typical variation of params for filters/scripts based on MVtools and MAnalyse:
- pre-process input and not
- set truemotion on and off
- set blocksize to 8 and 16 (or even 4,8,16,32)

2. Set several presets of filter params in script form like M_QTGMC or in GUI software supporting such details gathering from several filter/script runs.
3. Run processing and wait (much more time) for the result. Typical time scale is at least multiple of different filter presets runs (and some presets may be more slow).

Though for denoise filters it may decrease denoise ratio because with gathering most detailed areas (as most differential from the blurred) it also will collect more noise from each filter run.

As was found after about 2 years of development around MAnalyse - it may be not possible to make a single set of params with all areas of all frames best processing. But it is possible to make several runs of processing script and pick the best areas from each frame using external software - it is the main design idea of M_QTGMC script.

[Selur]

Seems like your M_QTGMC tries to do what simply using a faster preset would do.

[DTL2023]

Many calls to MAnalyse (+MCompesate) can not be any faster of the single calls in original (Quick-)TGMC. So it may expected only on extraslow/ultraslow/awfullyslow presets.