MVTools-pfmod

[pinterf]

out16 is simply omitting a final conversion of the intermediate result back to 8 bits. This internal result is always of 16 bits precision for 8 bit sources. This is the same as lsb_out works but the result is not stacked but a real 16 bit clip.

[tormento]

Please look here.

Originally Posted by pinterf

out16 is simply omitting a final conversion of the intermediate result back to 8 bits. This internal result is always of 16 bits precision for 8 bit sources. This is the same as lsb_out works but the result is not stacked but a real 16 bit clip.

So why there is so much difference between the results? 16 bit source should give the same result as out16 and 10/12 bit source should be a lot faster than out16 too.

[pinterf]

SMDegrain <> MDegrain

[tormento]

Originally Posted by pinterf

SMDegrain <> MDegrain

I understand. As I asked before, would it be possible to have 10 bit internal precision and output for 8 bit source too instead of 16 only?

[real.finder]

Originally Posted by tormento

I understand. As I asked before, would it be possible to have 10 bit internal precision and output for 8 bit source too instead of 16 only?

start read from here https://forum.doom9.org/showthread.p...12#post1835712

[takla]

Originally Posted by tormento

I understand. As I asked before, would it be possible to have 10 bit internal precision and output for 8 bit source too instead of 16 only?

Why not do the following with an 8 bit source:

ConvertBits(16)
MDegrain()
ConvertBits(bits=10, dither=1)

As explained here, 10 to 16 bit makes no difference in speed and so you should either convert to 16bit or don't use out16 / ConvertBits at all.

[joka]

If I use MCompensate
s = c.MSuper(pel=2)
vb1 = s.MAnalyse(isb=false, delta=1, blksize=bs, overlap=ov)
cp1 = c.MCompensate(s, vb1)

and provide blksize and overlap I get (depending on the parameters) an unprocessed strip (with cp1 == c) on the bottom and the right border.
Further evaluation shows the same for MDeGrain (output of MDeGrain == c). With MDeGrain it is easier to compare/see. Height / width of strip depends on parameters.

Examples:
blksize/overlap
8/0 ok., nothing
8/4 ok., nothing
16/0 bottom
16/8 ok., nothing
32/0 bottom
32/8 bottom, right
32/16 bottom
64/0 bottom, right

Clip size is 1440x1080.
I use mvtools-2.7.43-with-depans20200602, AMD x64.

Do I something wrong? Is this a known issue? Exists a workaroud?

[StainlessS]

Joka, try same with 2.2.7.44:- https://github.com/pinterf/mvtools/releases

Change log
** 2.7.44 (20201214)**

MAnalyze: fix motion vector generation inconsistencies across multiple runs.
Note: when internal multithreading is used (avstp + mt=true), inconsistencies will still occur by design.

EDIT: Always a good idea to try latest version before reporting problem, if same then re-submit problem report.

[pinterf]

MDegrain is simply copying 'uncovered' bottom and right regions. Uncovered means that these pixels are not covered by whole blocks of the given blocksize.

[joka]

Good to know. I tested blksize/overlap - 24/12. This seems to solve it for clip size 1440/1080 and 1920/1080.
Thank you pinterf.

[zorr]

The current documentation on MAnalyse states about overlap: "Must be even and less than block size (up to blksize/2 for MCompensate)".

However, when I try overlap > blksize/2 I get this error message "MAnalyse: overlap must be less or equal than half block size". I don't have MCompensate in the script. MVTools x64 version 2.7.44.

So is the documentation or the code wrong?

EDIT: Seems like MAnalyse also doesn't accept negative levels.

[zorr]

Originally Posted by zorr

The current documentation on MAnalyse states about overlap: "Must be even and less than block size (up to blksize/2 for MCompensate)".

I confirmed that this is just an error in the documentation (and it has been like that a long time). I do wonder though would it be possible to get rid of this limitation. It's usually the largest possible overlap that gives the best quality so it would be interesting to see if the trend (larger = better) would continue even with overlap > blksize/2.

Originally Posted by zorr

EDIT: Seems like MAnalyse also doesn't accept negative levels.

This was my own error, the levels parameter was just too negative and there weren't any levels left.

[Dogway]

Would it make sense to implement a half pel option to increase speed for UHD clips or is it the same as increasing blksize and overlap?

[Boulder]

Isn't half pel the same as pel=2?

[Dogway]

I meant pel=0.5, double pel in mvtools terms

[StainlessS]

I meant pel=0.5, double pel in mvtools terms

Would that not have [a sort of] effect of lowering effective resolutuion of the result clip ?
[would seem to me that pel=1, and bigger blocksize, is the way to go]

[Dogway]

I don't think so, many prefilters use gaussian type blurs for easier motion search, lowering the resolution is just the same but with less pixels (faster). Also many UHDs are upscaled conversions.

I don't know what others have to say, seems to me that pel=2 would also equal to pel=1 and smaller blocksize?

[feisty2]

it is equivalent to performing motion estimation on a downscaled version of the video, then you 2x upscale the motion vectors

[StainlessS]

Originally Posted by feisty2

it is equivalent to performing motion estimation on a downscaled version of the video, then you 2x upscale the motion vectors

And, Would that not have [a sort of] effect of lowering effective resolution of the result clip ?

EDIT: Arh, the new avatar is a cat or something, hard to figure out what it is.

[Dogway]

Originally Posted by feisty2

it is equivalent to performing motion estimation on a downscaled version of the video, then you 2x upscale the motion vectors

Wow, thanks, already updated SMDegrain with the changes, didn't remember MScaleVect