MVTools-pfmod

[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]

Originally Posted by MysteryX

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]

Originally Posted by Morku

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.

Originally Posted by Morku

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]

Originally Posted by 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.

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

[Morku]

Originally Posted by pinterf

EDIT: found it, fix is coming soon

Thanks a lot

[pinterf]

New release with an important fix (regression in previous 2.7.16.22), big thanks to Morku for the early report.

The SAD mask scaling issue (different magnitude for YV12 and YV24) was noticed by MysteryX. @MysteryX: please have a look at it.

MvTools2 2.7.17.22

Change log
- 2.7.17.22 (20170426)
  Fix: Regression in 2.7.16.22: MDegrain right pixel artifacts on non-modulo 16 widths
  Misc: MMask, mode SADMask output is normalized further by video subsampling (YV16/YV24 has larger SAD value due to bigger chroma part that classic YV12)

[MysteryX]

YV24 masks are now weaker than YV12 masks.

YV12 / YV24


It seems you're over-compensating.

[Taurus]

Thanks pinterf!
The same thing Morku was explaining happened to me yesterday.
I hope the new build will fix this.
It happened on a cropped and resized video to 960x720.
Straight 1920x1080 and 1280x720 do not show this artifact.
Will test the new build in a few minutes...
Hmmh, at first glance everything is allright now.
Green line and grey line after cropping are gone on my side.
Maybe Morku can comment on this.

QTGMC 3.357s
masktools2 2.2.7
nnedi3 0.9.4.40
rgtools 0.95
dfftest 1.94 ICL10
mvtools2 2.7.17.22

[pinterf]

Originally Posted by MysteryX

YV24 masks are now weaker than YV12 masks.[/img][/url]

It seems you're over-compensating.

Or the theory fails.
SAD comes from luma and chroma
On YV12 Y:U:V has 1:0.25:0.25 ratio
On YV24 the ratio is 1:1:1.
I think the masks should look the same when you convert the clips to greyscale before analysis (or chroma=false)? Just an idea.

[pinterf]

Originally Posted by Taurus

Thanks pinterf!
The same thing Morku was explaining happened to me yesterday.

Uh, I'm really sorry for the inconvenience.

[Morku]

Originally Posted by Taurus

Green line and grey line after cropping are gone on my side.
Maybe Morku can comment on this.

My example also looks fine now without cropping and resizing.
Thank you for the fast fix.

[Taurus]

Originally Posted by pinterf

Uh, I'm really sorry for the inconvenience.

No problem.
I deeply appreciate your work on modernising and fixing Avisynth flaws.

[MysteryX]

Originally Posted by pinterf

I think the masks should look the same when you convert the clips to greyscale before analysis (or chroma=false)? Just an idea.

Just to clarify, the screenshots call ConvertToY8 on the masks.

[pinterf]

Originally Posted by MysteryX

Just to clarify, the screenshots call ConvertToY8 on the masks.

That's ok, I wondered that what happens when the clip to analyze is GreyScale()'d before that. Thus the chroma SAD difference is zero for both YV12 and YV24 and does not affect the SAD weighting.

I'm thinking that there should be an option to be able to give weight the chroma part of the SAD. The internal contribution of SAD elements (Luma:Chroma) in YV12 is 1:0.5, while for YV24 the ratio is 1:2, which drives the whole thing a bit off.