MVTools-pfmod

[pinterf]

I like when the questions get answered without me. btw masks, I think I still have some work on the mask side for 10+ bits. Are masks 8 bit in the vapoursynth mvtools version?

[feisty2]

there's still no high bit depth support for MMask in jackoneill's branch, but I got my 32bits floating point version of MMask in my branch.
https://github.com/IFeelBloated/vapoursynth-mvtools-sf/blob/master/src/MVMask.cpp

[real.finder]

I think there are something related to mvtools here https://forum.doom9.org/showpost.php?p=1800104&postcount=2286

cuz QTGMC(SLMode=0,tv_range=false,tr1=0,tr2=0)

will be ok in all bit depth

[pinterf]

I think there are something related to mvtools here https://forum.doom9.org/showpost.php?p=1800104&postcount=2286

cuz QTGMC(SLMode=0,tv_range=false,tr1=0,tr2=0)

will be ok in all bit depth
What difference should I recognize? Yes, there are minor differences, but only when I'm looking at the same frames with the alt-tab method and pixel-peeping. I'm testing with a Hi8 DV-AVI source.

[real.finder]

What difference should I recognize? Yes, there are minor differences, but only when I'm looking at the same frames with the alt-tab method and pixel-peeping. I'm testing with a Hi8 DV-AVI source.

it look sharp and somehow with some artefact

[real.finder]

even in SMDegrain, so I think there are something in MDegrainX

and something else, can you add error message for not use lsb with native high bits?

[pinterf]

Can you send me a short clip sample where the differences are well visible? It would save me time to have a good test case, thank you in advance

[real.finder]

Can you send me a short clip sample where the differences are well visible? It would save me time to have a good test case, thank you in advance

done in pm :)

[pinterf]

New release with an important fix for 10+ bits
MvTools2 2.7.15.22 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.15.22)

MvTools2 2.7.15.22 (20170316)
Fix: 16 bit SAD for non-AVX code path
Misc: MDegrain1-6: add error on lsb_flag=true for non-8 bit sources

[MysteryX]

Here's a bug with MVTools2 with YV24.

Here's what it looks like on a still video, but I don't think it matters which source you use.
https://s1.postimg.org/fffg0qn0b/mvtools2bug.png (https://postimg.org/image/fffg0qn0b/)


AviSource("Preview.avi")
ConvertToYV24()
jm_fps(60)


function jm_fps(clip source, float "fps")
{
fps = default(fps, 25.000)
fps_num = int(fps * 1000)
fps_den = 1000

prefiltered = RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = 16, overlap = 4, search = 3, dct = 0)
forward = MAnalyse(superfilt, isb = false, blksize = 16, overlap = 4, search = 3, dct = 0)
forward_re = MRecalculate(super, forward, blksize = 8, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 8, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)

return out
}

[pinterf]

Thanks, reproduced. YV16 and YV24 both have artifacts
EDIT:
Could you send me a link to your source?
Because your script produces the same artifacts for all colorspaces YV12, YUY2, YV24 for me.
Checked YV12 and YUY2 with older mvtools versions 2.5.11.3, 2.5.11.22, 2.6.0.5 and they are also ugly.

[MysteryX]

I often use this source for testing; with LSMASHSource
https://www.spiritualselftransformation.com/files/media-encoder-old.mpg

[pinterf]

I often use this source for testing; with LSMASHSource
https://www.spiritualselftransformation.com/files/media-encoder-old.mpg
Thanks. Still I can see no differences between YV12/YV24 or even YUV444P16.
Are you using 2.7.15.22?
If so, what processor capabilities do you have? (Different code paths?)

[MysteryX]

Thanks. Still I can see no differences between YV12/YV24 or even YUV444P16.
Are you using 2.7.15.22?
If so, what processor capabilities do you have? (Different code paths?)
I'll be traveling until the 12th. I can do some more testing later if you haven't figured it out yet.

[Motenai Yoda]

depanestimate (or depan) parameters have been changed? coz scene change detection looks broken to me

It isn't fixed yet?

[real.finder]

It isn't fixed yet?

it is


Depan 2.13.1.2 (20161228)
Fix: DepanStabilize: removed too strict checking for large motion vectors received from depan
that resulted in like scene change

[Motenai Yoda]

it is

I got it,
but what I was/am experiencing is a lot of scene-changes not detected...

[VS_Fan]

I got it,
but what I was/am experiencing is a lot of scene-changes not detected...Have you tried using lower values for the thSDC2 parameter?
This is what I usually do: The default for thSCD2 is 130 equivalent to the 51% of blocks changed. Try lower values in steps of 8, which corresponds approximately to steps of 3%: to 128, 120, 112, etc.

You can use showSAD parameter of the mShow function to estimate both thSCD1 & thSCD2 values:
return mshow(super, vectors, showsad=True, thSCD1=400, thSCD2=112, sil=1)
After determining the appropriate values of thSCDx paramenters, you can use the info=True parameter of the mDepan Function, to refine them more precisely:
globalmotion = mDepan(pf, vectors, zoom=True, pixaspect=1.0, thSCD1=400, thSCD2=112, info=True, error=60.0, wrong=40.0)
return globalmotion
BTW: error and wrong parameters of mDepan can be raised a bit from the defaults to make it more tolerant to big movements that could otherwise reset the motion compensation as if it were due to Scene Change

Finally, you can use the info=True parameter in the DePanStabilize function to verify the results.

And don't forget to comment out the whole mShow function and set to False the showsad and info parameters

[Motenai Yoda]

I'm not using mdepan but depanestimate

s = 8
stab_reference = removegrain(4,-1,-1).mt_edge(mode="min/max",U=-128,V=-128)
data = depanestimate(stab_reference,trust=2.0,dxmax=s,dymax=s,stab=12,zoommax=1.0)
DePanStabilize(cutoff=1.0,data=data,dxmax=s,dymax=s,zoommax=1.0,rotmax=0.0,mirror=15,blur=30,method=1,subpixel=2)

[pinterf]

Ok, I'll make a comparison with this script

[MysteryX]

Thanks. Still I can see no differences between YV12/YV24 or even YUV444P16.
Are you using 2.7.15.22?
Yes


If so, what processor capabilities do you have? (Different code paths?)
MMX2 SSE2Fast SSSE3 SSE4.2 AVX

This is the script I use. I am unable to see artifacts in YV12 and am unable to get good results in YV24. Also, single-threaded gives only slight artifacts while Prefetch(4) gives much stronger artifacts, so there is some multi-threading memory issue.

LWLibavVideoSource("Input.mpg", cache=False, threads=1)
ConvertToYV24()
jm_fps(60)
Prefetch(4)

[pinterf]

Same processor features for me, but to be sure I have run the script on AVX2 simulator, and w/o AVX and there was no issue at all.

Still something is different.

Script (with the current variant of jm_fps)
LWLibavVideoSource("media-encoder-old.mpg", cache=False, threads=1)
ConvertToYV24()
jm_fps(60)
Prefetch(4)
function jm_fps(clip source, float "fps")
{
fps = default(fps, 25.000)
fps_num = int(fps * 1000)
fps_den = 1000

prefiltered = source.IsYUY2 ? RemoveGrain(source.ConvertToYV16(), 22).ConvertToYUY2() : RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = 16, overlap = 4, search = 3, dct = 0)
forward = MAnalyse(superfilt, isb = false, blksize = 16, overlap = 4, search = 3, dct = 0)

forward_re = MRecalculate(super, forward, blksize = 8, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 8, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)
return out
}
Clip: the one you have provided (352x288)
Win7 Prof
MvTools2 2.7.15.22
RgTools 0.95
Avs+ r2455 (checked both x86 and x64)
libfftw3f-3.dll: 3.3.5

Could you please start minimizing this script until the issue is still there? Or modify parameters (e.g. other dct setting, eliminate RemoveGrain, and changing blocksize from 16/8 to 32/16) or change LibAvVideoSource to ffms2? Thanks in advance.

[MysteryX]

Interesting. It is RemoveGrain.dll that fails. If I remove it, then it works.

[pinterf]

Good. Time to kill those plugins that have already replacement. Then I'm not debugging any further.

[MysteryX]

Good. Time to kill those plugins that have already replacement. Then I'm not debugging any further.
What could RemoveGrain be replaced with to work in YV24?

[Reel.Deel]

What could RemoveGrain be replaced with to work in YV24?

RgTools (https://github.com/pinterf/RgTools/releases)

[MysteryX]

MvTools.MMask doesn't work in 16-bit

Here's what I get
https://s10.postimg.org/uew8whaud/MMask_Bug.png (https://postimg.org/image/uew8whaud/)

You can use the FrameRateConverter (https://forum.doom9.org/showthread.php?p=1804492#post1804492) code to test.

[MysteryX]

Also, MMask leaves junk data in unused planes. It might be good to avoid that.

[pinterf]

Yes, it is a mask, not something for watching

[MysteryX]

Sometimes it's good to preview the mask visually. Why doesn't it just use a Y8 clip? Are the other planes really unused, or are they applied on the chroma planes? Just want to be sure the random data isn't affecting my code.

[pinterf]

Y8 exists since avs 2.6 and mvtools was a 2.5 plugin

[pinterf]

New release
MvTools2 2.7.16.22 (https://github.com/pinterf/mvtools/releases/tag/2.7.16.22)

Change log
- 2.7.16.22 (20170423)
Fix: MMask 10-16 bits
Fix: MRecalculate 14-16 bits passed nSCD1=999999 internally which caused overflow (scene change problems later)
Fix is done by clamping SCD1 to 8*8*(255-0) (maximum value of sum of SADs on a 8x8 block)
Misc: MDegrainX 8 bits: internal 16 bit buffer to 8 bits: SSE2

[MysteryX]

Thanks! There were quite a lot of bugs with 16-bit here and in masktools2

[MysteryX]

Y8 exists since avs 2.6 and mvtools was a 2.5 plugin

Can you confirm whether the other planes are unused?

Can I convert the mask to Y8 and get the same result, but with lower mask processing cost? I tried and the mask didn't seem to get applied. This could be supported without breaking old code.

[MysteryX]

Why is there such a difference between the masks generated in YV12 and YV24?


EM = MaskSAD > 0 ? C.MMask(bak, ml=MaskSAD, kind=1) : BlankClip(C) # kind=SAD
EMfwd = MaskSAD > 0 ? C.MMask(fwd, ml=MaskSAD, kind=1) : EM # kind=temporal blending
EMfwd = FrameDouble ? EMfwd.DeleteFrame(0) : EMfwd
EM = MaskSAD > 0 ? EM.Overlay(EMfwd, opacity=0.5, mode="lighten") : EM
SkipEM = EM
return ScriptClip(SkipEM, "Subtitle(String(AverageLuma))").ConvertToY8()


YV12
https://s15.postimg.org/l28nzz3yf/Mask_YV12.png (https://postimg.org/image/l28nzz3yf/)

YV24
https://s15.postimg.org/42zpkpsqv/Mask_YV24.png (https://postimg.org/image/42zpkpsqv/)

[pinterf]

Perhaps the scaling does not normalize on a larger chroma part in SAD. What does it look like if you use YUY2? It should be between yv12 and yv24.

[MysteryX]

Perhaps the scaling does not normalize on a larger chroma part in SAD. What does it look like if you use YUY2? It should be between yv12 and yv24.
Yes, it is between YV12 and YV24.

How can I normalize the output?

[raffriff42]

Fantastic to see high bit depth suddenly becoming a real thing, supported by all the best filters. Pinterf, I know you're probably standing on some tall shoulders, but your recent productivity has been amazing. You're a closer (https://www.google.com/search?q=ALWAYS+BE+CLOSING)!

[StainlessS]

your recent productivity has been amazing.

Yes, Pinterf is the Dogs Bollocks, no exception !

[MysteryX]

Fantastic to see high bit depth suddenly becoming a real thing, supported by all the best filters
While others have been talking about it for what... 10 or 15 years?

"Just do it" is a better philosophy than "let's talk about it"

[MysteryX]

SMDegrain was written before 16-bit support was added to MaskTools2 and MVTools2. Now that they both support 16-bit, SMDegrain should be adapted for it.

Edit: Actually, if SMDegrain uses libraries that support 16-bit, it should work with native 16-bit out-of-the-box when supplied a 16-bit clip -- will have to test.

[pinterf]

Yes, it is between YV12 and YV24.

How can I normalize the output?
From the original MMask documentation (kind=1)

"kind=1 (SAD)
Allows to build a mask of the SAD (sum of absolute differences) values instead of the vectors' length. It can be useful to find problem areas with bad motion estimation. Internal factor blksize*blksizeV/4 is used for normalization of scale ml."

So it does not take into account the larger SAD values by design, normalization only handles the different block sizes.

Less subsampling means that there is more chroma SAD.
There is another thing to mention: when you omit chroma, then SAD will contain only luma SAD, regardless of the subsampling.

[MysteryX]

I think that behavior should be changed -- but it needs to stay compatible with previous behaviors, so it might need an extra parameter to normalize.

[pinterf]

I dont know whether this behavior was intentional in the yv12/yuy2 age

[MysteryX]

I see no reason or purpose for such behavior -- yet nobody complained so far

[Morku]

Version 2.7.16.22 brings me artefefacts in image on the right side, when I use QTGMC, most noticable as a popping green line:

http://imgur.com/ZQUg5RH

It's more heavily when using a slow preset like slow, slower, placebo... it is kind of gone when I use "ultra fast".

I revert back to 2.7.15.22 and everything is back fine.

Thats the script I am using:


AVISource("x.avi", audio=true).AssumeFPS(25,1)

QTGMC(Denoiser="dfttest", Preset="Slower", EdiMode="NNEDI3", EdiThreads=8, Sharpness=1.0)

Thats the state of my program version:
Avisynth+(x86) r2455 MT
masktools2 2.2.7
nnedi3 0.9.4.40
rgtools 0.95
QTGMC 3.357s
dfftest 1.94 ICL10

I hope I could help somehow.

[Groucho2004]

What are the image dimensions? Try to crop 2 pixels from the right (or left).

[Morku]

It's 720x576 (PAL).
To add crop(0, 0, -2, 0) does not solve the problem.

EDIT:
To add crop before QTGMC removes the green line, it's now grey.

[Groucho2004]

It's 720x576 (PAL).
To add crop(0, 0, -2, 0) does not solve the problem.Hm, don't know. Better post in the new QTGMC() thread.

EDIT:
To add crop before QTGMC removes the green line, it's now grey.
Well, cropping before the filters was implied. Anyway, pinterf is probably on the right track.

[pinterf]

It's 720x576 (PAL).
To add crop(0, 0, -2, 0) does not solve the problem.

EDIT:
To add crop before QTGMC removes the green line, it's now grey.
Could you resize it in 704x576?
Chroma width is 360 at YV12 which is not divisible by 16.
EDIT: found it, fix is coming soon