adding search_coarse from SVP fork

[realfinder]

Hi
svp fork https://web.archive.org/web/20140702041253/http://www.svp-team.com/files/gpl/mvtools-2.5.11.9-svp.zip

VS mvtools already add it https://forum.doom9.org/showpost.php?p=1704418&postcount=67

also, aside from search_coarse, backthen https://forum.doom9.org/showthread.php?p=1790461#post1790461 you did add the speedup of svp fork, but is it for all filters of mvtools or just MAnalyse()?

[DTL2020]

What you expect from coarse levels search type control ? The only possibe is better performance but in 2026 old mvtools already fast enough and users mostly asks for better quality not better performance. Also all coarse levels has much less number of blocks and using faster coarse search type do not adds too much to performance.

In that old svp version the default search coarse type looks like was logarithmic. To get more performance for realtime svp tasks.
In latest mvtools versions coarse search type fixed to exhaustive internally (except pure H or V search requested) and already most quality search of implemented methods.
See

mvtools/Sources/GroupOfPlanes.cpp

Line 148 in a488b09

SearchType searchTypeSmallest =

for first level and

mvtools/Sources/GroupOfPlanes.cpp

Line 191 in a488b09

SearchType searchTypeLevel =

for other levels

One current visible limitation of quality for better performance easy enough to control externally is trymany search methods are disabled for finest (slowest) level=0 (as was same in the svp project of the old ages of slow CPUs) -

mvtools/Sources/GroupOfPlanes.cpp

Line 223 in a488b09

tryManyLevel = (tryMany && i > 0); // not for finest level to not decrease speed

So to make search a bit higher quality this can be controlled by some new param (or by some workaround with existing params to keep compatibility with existing scripts).

May be the changing of the default internal coarse levels search type from non-exhaustive (logarithmic ?) to exhaustive was missed from the old versions changes. Also it is missed from current documentation and it may be non clear what really controls 'search' param for MAnalyse and MRecalculate. For MAnalyse it controls only search at finest level and for MRecalculate controls only single refining search (also only if block SAD after interpolation >thSAD).

[realfinder]

but in 2026 old mvtools already fast enough

well, not all people has a fast or newer CPU :) some people in doom9 still even use Pentium III era CPU (not kidding, you can search and see)

users mostly asks for better quality not better performance.

why not both? if possible :D of course, or having a option to choose

[pinterf]

Those people are definitely not the target audience, they probably must use their former stuff on. I do not agree on demanding developers to invest their working days into optimizing for 15 yr-old hardware in 2026.

[pinterf]

The actual search_coarse commit is this one.
dubhatervapoursynth/vapoursynth-mvtools@6f5d013
and the other speed-up stuff is already in mvtools.
dubhatervapoursynth/vapoursynth-mvtools@fb96fd1

[pinterf]

And it is not even complete, since it can have a different parameter from the main 'search' type, so I introduced a 'search_coarse_param' companion for 'search_coarse'.

[pinterf]

Is it OK to have 'trymanyall' (default false) as the parameter name for selecting (tryMany && i > 0); vs (tryMany) case?

Present change log, if it helps.

Feature request #68: adding search_coarse from SVP fork: MAnalyse: new parameters search_coarse.
MAnalyse: Add parameter searchparam_coarse specifically for search_coarse.
MAnalyse: Add parameter trymanyall, which allows trymany for the finest level as well (default false to not decrease speed)

[realfinder]

what about add it as "search_coarse=-1" (Instead of trymanyall=true)?

[pinterf]

This is the place, where DTL removed the constraint:
DTL2020@bfca640

[realfinder]

This is the place, where DTL removed the constraint: DTL2020@bfca640

then search_coarse < 0 ? (tryMany) : (tryMany && i > 0) and of course the "search_coarse" will need abs() in search_coarse related things

the point is to add less parameters :)

[realfinder]

This is the place, where DTL removed the constraint: DTL2020@bfca640

then search_coarse < 0 ? (tryMany) : (tryMany && i > 0) and of course the "search_coarse" will need abs() in search_coarse related things

the point is to add less parameters :)

I think since search_coarse has "0" this not suitable, so new "trymanyall" is better

[pinterf]

Yep, search_course is checked against and documented to have valid values 0..7, I don't want to abuse this parameter. Since this is the 34th parameter for this poor MAnalyse, it's all the same.

[DTL2020]

If search_coarse is added it is about control of search at coarse levels. And the required trymany part control is about finest level where 'search' is used. So possible ways are to encode additional bool to 'search' or 'searchparam' for finest level.
Possible ways:

1. Add decimal encoded additive as new_paramxN10 + old_param. Like x10 or x100. So trymany=enabled_at_finest may be search=1x (12, 13, ..) or 10x (102, 103, ..). It is enough easy to encode by user. Also many new params may be added to single input integer.
2. Single bool new param may be added as sign inversion. Like -search or -searchparam signal to trymany enabled at finest level. Though it is less natural to user I think.

"Is it OK to have 'trymanyall' (default false)"

More exact name may be 'trymanyfinest' because all levels except finest already controlled by 'trymany' param.

Also for future development this better to make integer param instead of bool because many new predictors may be added and also to control performance/quality user may select how many predictors (or sets of predictors) to check with 'trymanyfinest' enabled. Full name of the param 'try_to_refine_many_predictors_at_finest_level'. Also with a new predictors the coarse levels also need same control methods to balance performance/quality.

[pinterf]

TryMany must be kept as bool.
Do you propose that we must implement trymanyfinest as int (default 0 acts as false, 1 is like true (no limit)) ? And then decide about the meaning of rest of the values

[DTL2020]

" implement trymanyfinest as int (default 0 acts as false, 1 is like true (no limit)) ? "

Yes - it will be better for future.
0 - no additional predictors - only best predictor after previous search steps (as in 2.7.47 version at finest level).
1 - all predictors at the versions like 2.7.47 and before (about 5..7 predictors depending on temporal=true/false and global=true/false)
This is one of the place to check some set (not all of) the predictors with trymany enabled

mvtools/Sources/PlaneOfBlocks.cpp

Line 970 in cdf04a5

if (tryMany)

and final selection of best of the best of all refined

mvtools/Sources/PlaneOfBlocks.cpp

Line 979 in cdf04a5

if (tryMany)

2 and more - new additional predictors possible (like more surrounding predictors, some average(s) of the surroundings (in addition to current median of 3 ?), some previous levels predictors, more temporal predictors (like previous frames several predictors) and many other possible).

The more predictors used the better may be quality but also more performance penalty for the attempt to refine around each predictor. The performance penalty is about linear proportion to the used predictors number. So it may be better to control number of the used predictors too like index of the set of predictors used.