MVTools-pfmod

[burfadel]

Sounds good. MysteryX might also be interested in it for FrameRateConverter.

EDIT: Thanks Pinterf for the test build, it works much better! I presume you got the reply pm I wrote. After testing I was short on time and sent it in a hurry.

[pinterf]

New build: MvTools2 2.7.23 with depans

Download:
https://github.com/pinterf/mvtools/releases/tag/2.7.23

- 2.7.23 (20171012)
Fix: MScaleVect wrong rounding of scaled motion vectors with negative components.
e.g. proper scaling (-1;-2) to (-2;-4) instead of (-1,-3)

Thanks for the patience.

[Taurus]

Thank You,Sir!:thanks:

[burfadel]

Yes, thankyou :)

[FranceBB]

Thank you! :D

[nhope]

Does MVTools-pfmod in itself require libfftw3f-3.dll? If so, is it just for certain functions? The requirements section of the QTGMC wiki (http://avisynth.nl/index.php/QTGMC#Requirements) says it does, but I don't find that stated in any MVTools documentation.

[pinterf]

Does MVTools-pfmod in itself require libfftw3f-3.dll? If so, is it just for certain functions? The requirements section of the QTGMC wiki (http://avisynth.nl/index.php/QTGMC#Requirements) says it does, but I don't find that stated in any MVTools documentation.
Used in MAnalyze when dct parameter is not 0. 8x8 block size in 8-bit clips is an exception, because it uses integer fft instead

[nhope]

Thank you for the clarification pinterf.

[MysteryX]

I was wondering, is it possible to calculate the vectors on a 8-bit clip and then apply them on a 16-bit? King of like the ScaleVect function but that scales the bit depth. Analyzing vectors in 16-bit takes WAY longer.

[pinterf]

I was wondering, is it possible to calculate the vectors on a 8-bit clip and then apply them on a 16-bit? King of like the ScaleVect function but that scales the bit depth. Analyzing vectors in 16-bit takes WAY longer.
It could work like MScaleVect, but bit-depth difference (instead of blocksize) should affect SAD readjustment.

On the other hand, I planned to revise 10-16 bit SAD functions, now they are simd intrinsics, which can be changed into faster hand written asm. And it can be even faster for 10 or 12 bits, taking into consideration of possible sum overflows.

[MysteryX]

and there was the addition of STAR search method which would be interesting when you have time for that

[MysteryX]

btw it has been a while now... any chance for the bug regarding DCT=1 being slow with MT to be fixed?

[pinterf]

How do you know it's a bug and not something that is inevitable when using floating point fft from this external library?

[MysteryX]

The VapourSynth version works perfectly fine and is using the same library AFAIK.

[pinterf]

New release.

Download MvTools2 2.7.24 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.24)

A fix for a crash (see topic (https://forum.doom9.org/showthread.php?t=175076)) in MFlowBlur. I think it was there from the beginnings.

And there is a smart speedup upon MysteryX idea: generate vectors in 8 bits, then use MScaleVect to make it usable for an e.g. 16 bit MDegrain. On my pre-AVX2 PC it gave me more than 50% speedup for a basic MDegrain3 scenario. Try and give feedback.

- 2.7.24 (20171205)
Fix: MFlowBlur: possible access violation crash when nPel>1
New: MScaleVect parameter 'bits'. e.g. Analyze 8 bit clips, use their vectors for 16 bits
Move project to VS2017

For MScaleVect see documentation in the release pack, in the Documentation folder: mvtools2.html.

In brief: MScaleVect has a new parameter: 'bits'. When specified, the default value of the scale parameter is 1.0 instead of 2.0. So when you use 'bits' only, then the vectors won't be scaled by default by 2.

Example: basic process, analyze in 16 bits

a=..source
bit=16
blksize = 16
blksizeV = 16
a8=a
a=a.ConvertBits(bit)

sup = a.MSuper(pel=2) #pel=2

fv1 = sup.MAnalyse(isb=false, delta=1, overlap=ov, blksize = blksize, blksizev = blksizev)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=ov, blksize = blksize, blksizev = blksizev)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=ov, blksize = blksize, blksizev = blksizev)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=ov, blksize = blksize, blksizev = blksizev)
fv3 = sup.MAnalyse(isb=false, delta=3, overlap=ov, blksize = blksize, blksizev = blksizev)
bv3 = sup.MAnalyse(isb=true, delta=3, overlap=ov, blksize = blksize, blksizev = blksizev)

a.MDegrain3(Sup, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=1000)

faster way resulting in almost similar result


a=..source
ov=8
bit=16
blksize = 16
blksizeV = 16
a8=a
a=a.ConvertBits(bit)

sup = a.MSuper(pel=2)
sup8 = a8.MSuper(pel=2)

fv1 = sup8.MAnalyse(isb=false, delta=1, overlap=ov, blksize = blksize, blksizev = blksizev)
bv1 = sup8.MAnalyse(isb=true, delta=1, overlap=ov, blksize = blksize, blksizev = blksizev)
fv2 = sup8.MAnalyse(isb=false, delta=2, overlap=ov, blksize = blksize, blksizev = blksizev)
bv2 = sup8.MAnalyse(isb=true, delta=2, overlap=ov, blksize = blksize, blksizev = blksizev)
fv3 = sup8.MAnalyse(isb=false, delta=3, overlap=ov, blksize = blksize, blksizev = blksizev)
bv3 = sup8.MAnalyse(isb=true, delta=3, overlap=ov, blksize = blksize, blksizev = blksizev)
fv1 = fv1.MScalevect(bits=16)
bv1 = bv1.MScalevect(bits=16)
fv2 = fv2.MScalevect(bits=16)
bv2 = bv2.MScalevect(bits=16)
fv3 = fv3.MScalevect(bits=16)
bv3 = bv3.MScalevect(bits=16)

a.MDegrain3(Sup, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=1000)

[real.finder]

New release.

Download MvTools2 2.7.24 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.24)


thanks, now we can use MAnalyze with high bit without need to filtering all things in high bit for 8 bit clips especially when chroma=false, I think this can make it more accurate for filtering 8 bit clips since the motion Analyze done in HBD

aside form that, when masktools turn come for update?

[MysteryX]

Great job on the update!

Quality-wise, I'd be curious as to the difference between analyzing vectors in 8-bit or 16-bit, but since 16-bit processing was prohibitively slow and we were always better off using a slower preset in 8-bit, the real comparison should be between 8-bit processing and 8-bit analysis + 16-bit motions, both in terms of quality and performance.

How do you know it's a bug and not something that is inevitable when using floating point fft from this external library?
Perhaps you could give it a try with VapourSynth to be sure?

Other people have reported it was perfectly stable with 100% CPU usage.

Other great feature would be STAR search method. You can't use that library for that but you can copy/paste it from x265 library.

[pinterf]

Other great feature would be STAR search method. You can't use that library for that but you can copy/paste it from x265 library.
Copy-paste??? Have you seen the source in mvtools and the one in x265? Spent quite a few hours on investigating the feature but couldn't get a grip on it. I found no common points between the two sources. Right now I don't feel like spending days or weeks on the problem.

[MysteryX]

Copy-paste??? Have you seen the source in mvtools and the one in x265? Spent quite a few hours on investigating the feature but couldn't get a grip on it. I found no common points between the two sources. Right now I don't feel like spending days or weeks on the problem.
Ya copy/paste seems to work better in Word than in C++, somehow

[Groucho2004]

Ya copy/paste seems to work better in Word than in C++, somehow
Hilarious! :D:D

[MysteryX]

but then when I was working for L'Oreal in Paris, my job was mostly to port code from one of their core framework to another (back-porting), running on different versions of .NET

Copy/paste served well.

but .NET isn't C++ :)

[Gavino]

but then when I was working for L'Oreal in Paris, my job was mostly to port code from one of their core framework to another (back-porting), running on different versions of .NET

Copy/paste served well.
It may well have been appropriate for this particular job (I don't know), but your approach sounds a bit like cargo-cult programming.

https://en.wikipedia.org/wiki/Cargo_cult_programming
"The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position."

[MysteryX]

It may well have been appropriate for this particular job (I don't know), but your approach sounds a bit like cargo-cult programming.
Simply L'Oreal is building all their e-commerce websites over a platform that they keep upgrading over time, and while many of their websites use their latest platform, the large website I was responsible for (using 50GB databases and $200k of sales per day!!) stayed on an older version of their platform because specific optimizations were required for that website -- and then sometimes the newer features were needed in that older platform and thus had to be back-ported.

This is no different than any other company. As Windows or Linux get security fixes, those fixes are back-ported to older versions.

https://en.wikipedia.org/wiki/Cargo_cult_programming
"The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little or no understanding of how it works or whether it is required in its new position."
This sounds like what's needed to port STAR, whatever it is! Pinterf, tried that (https://www.google.com/search?q=cult+programming+tutorial)?

[real.finder]

so I back to this https://forum.doom9.org/showthread.php?p=1783190#post1783190

with 8 bit motion analyze

https://s8.postimg.org/54o0jeyb5/8bit_an_55.png (https://postimg.org/image/54o0jeyb5/)

then with 16 bit motion analyze

https://s8.postimg.org/qflknf0xd/16bit_an_55.png (https://postimg.org/image/qflknf0xd/)


LSMASHVideoSource("chroma.mp4")
c=last

ConvertBits(16)
SMDegrain(globals=3,chroma=false )
global fv1 = fv1.MScalevect(bits=8)
global bv1 = bv1.MScalevect(bits=8)
global fv2 = fv2.MScalevect(bits=8)
global bv2 = bv2.MScalevect(bits=8)
#~ SMDegrain(globals=3,chroma=false )

c
SMDegrain(globals=1)
ConvertBits(8)


There is an improvement in some places, but some few others are inverse (worst)

[burfadel]

With MVtools 2.7.24, it says in the included docs (as well as the original for MVTools) that the parameters for MSCDetection include Ysc, however if specifying Ysc it says MSCDetection does not have a named argument "Ysc".

Additionally, no matter what settings for thSCD1 and thSCD2 I use, the whole output is either completely black or completely white for extended periods when using a Y8 source (even in 8-bit). Isn't the output just supposed to be white for the first frame of a detected scenechange? Creates scene detection mask clip from motion vectors data. The mask is created both on the luma and on chroma planes. Output without scene change is 0.
I'm looking to invert this so scene changes are black and the rest is white in the mask. How do the other functions like MFlowFPS, MDegrain etc work internally regarding scene changes presuming they are working correctly?

If using an 8-bit Y12 source with chroma channels, the output is just a single colour like pink or green! Using the default settings, the whole 29 minute show of the clip I used for Masktools (UK Men Behaving Badly), using the Y12 8 bit source there was just a bit of pink output at the beginning for a couple of seconds and the rest was in green. For Y8 it was white at the beginning for those few seconds and the rest of the show was black. There were of course a quite a lot of scene changes that were meant to be there!

[pinterf]

With MVtools 2.7.24, it says in the included docs (as well as the original for MVTools) that the parameters for MSCDetection include Ysc, however if specifying Ysc it says MSCDetection does not have a named argument "Ysc".
Good catch. Contrary to the documentation the implemented name of the parameter is Yth (and as I see it was the case in the old 2.5.x times), which is obviously wrong, because it has the very same purpose as in MMask. It seems that this parameter was never used as a named parameter and probably left on the default.

Additionally, no matter what settings for thSCD1 and thSCD2 I use, the whole output is either completely black or completely white for extended periods when using a Y8 source (even in 8-bit). Isn't the output just supposed to be white for the first frame of a detected scenechange?
I'm looking to invert this so scene changes are black and the rest is white in the mask. How do the other functions like MFlowFPS, MDegrain etc work internally regarding scene changes presuming they are working correctly?

If using an 8-bit Y12 source with chroma channels, the output is just a single colour like pink or green! Using the default settings, the whole 29 minute show of the clip I used for Masktools (UK Men Behaving Badly), using the Y12 8 bit source there was just a bit of pink output at the beginning for a couple of seconds and the rest was in green. For Y8 it was white at the beginning for those few seconds and the rest of the show was black. There were of course a quite a lot of scene changes that were meant to be there!
(Y12 is YV12 I suppose, and not a 12 bit greyscale)
Once StainlessS provided me this test script, could you try this, this works for me.

<source>
ConvertBits(8) #or whatever

Function EndOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at EOS
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
bv=sup.MAnalyse(isb=true, delta=1,blksize=16/*,overlap=8*/)
Return c.MSCDetection(bv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function StartOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at SOS
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
fv=sup.MAnalyse(isb=false,delta=1,blksize=16/*,overlap=8*/)
Return c.MSCDetection(fv,thSCD1=thSCD1,thSCD2=thSCD2)
}

EOS = EndOfSceneClip()
SOS = StartOfSceneClip()
#return EOS
SSS="""
e = EOS.AverageLuma
s = SOS.AverageLuma
Subtitle(String(current_frame)+String(e,"] EOS=%.1f")+String(s," : SOS=%.1f"))
(e!=0.0)
\ ? Subtitle("End Of Scene",Size=48,Text_Color=$FF0000,Y=Height/2-24,Align=5)
\ : (s!=0.0) ? Subtitle("Start Of Scene",Size=48,Text_Color=$0000FF,Y=Height/2+24,Align=5)
\ : NOP
return last
"""

Scriptclip(SSS)
ConvertBits(8)

[burfadel]

Yes that works :). So how do I translate that into a mask such that it is only white at the start frame of a scene change? I want to reuse a calculate forward search 'fvec1'. The documentation makes it sound like it was a simple process of outputting such a mask.

I guess it would also be a handy inclusion in the documentation.

[feisty2]

but then when I was working for L'Oreal in Paris, my job was mostly to port code from one of their core framework to another (back-porting), running on different versions of .NET

Copy/paste served well.

but .NET isn't C++ :)

now I think its a bit unfair to put older C++(98, 03) and recent C++(11 and later) in the same category tho, they have very different type systems and thus have very different syntax for pretty much everything, even the most basic stuff like defining a variable or a function

the older C++ has a nominal type system, the type system inherited from C and also adopted in some other C influenced languages like java or c#, recent C++ has an inferred and structural type system with "auto" being the one and only type throughout almost the entire language, yes even for function parameters, the only type would be "auto" since C++20 (Concepts TS), so for OOP interfaces and inheritances between types are now rendered useless in C++20, instead replace them with (static variant of) duck typing OOP like in Python or JavaScript

human language, older C++ is syntactically closer to C and java, recent C++ is syntactically closer to Python and JavaScript

[`Orum]

I'm seeing some strange color shifting when doing 16-bit processing with MDeGrainN (it does not occur with 8-bit), toward U-/V- (AKA green). First, let me share the script I wrote to simplify using it:
################################
# Scripted_MDeGrain by `Orum #
# v0.3 on 2017-06-04 #
################################

# *NOTE* Some defaults are changed!
# Differing defaults: overlap

function Scripted_MDeGrain(clip c, bool "chroma", bool "mt", int "hpad", int "vpad", int "pel", int "MSlevels", int "sharp", int "rfilter", int "blksize", \
int "blksizeV", int "MAlevels", int "search", int "searchparam", int "pelsearch", bool "truemotion", int "lambda", int "lsad", bool "globalm", int "plevel", \
int "pnew", int "pzero", int "pglobal", int "overlap", int "overlapV", int "dct", int "divide", int "sadx264", int "badSAD", int "badrange", bool "meander", \
bool "temporal", bool "trymany", bool "multi", int "tr", int "thSAD", int "thSADC", int "plane", int "limit", int "limitC", int "thSCD1", int "thSCD2", \
bool "lsb", int "thSAD2", int "thSADC2", bool "debugSCD") {

# Shared params
chroma = default(chroma, true) # Use chroma (in addition to luma)?
mt = default(mt, true) # Use multi-threading?
tr = default(tr, 2) # Temporal radius of motion vector search

# MSuper params
hpad = default(hpad, 8) # Horizontal padding for better motion estimation
vpad = default(vpad, 8) # Vertical padding for better motion estimation
pel = default(pel, 2) # Accuracy of motion estimation (1, 2, or 4)
MSlevels = default(MSlevels, 0) # Number of hierarchical levels in super clip frames (0 = all)
sharp = default(sharp, 2) # Subpixel interpolation when pel > 1 (0 to 2)
rfilter = default(rfilter, 2) # Hierarchical levels smoothing filter (0 to 4)

# MAnalyse params
blksize = default(blksize, 8) # Horizontal block size (4, 8, or 16)
blksizeV = default(blksizeV, blksize) # Vertical block size (4, 8, or 16 - must be <= blksize?)
MAlevels = default(MAlevels, 0) # The number of levels used in the hierarchical analysis while searching for MVs
search = default(search, 4) # See readme (0 to 5)
searchparam = default(searchparam, 2) # Meaning dependant on value of search; see readme
pelsearch = default(pelsearch, pel) # Searchparam at finer levels
truemotion = default(truemotion, true) # Influences other parameter's defaults
lambda = default(lambda, truemotion ? 1000 * blksize * blksizeV / 64 : 0) # Coherence of the vector field
lsad = default(lsad, truemotion ? 1200 : 400) # SAD limit for lambda (recommended > 1000 w/ truemotion)
globalm = default(globalm, truemotion) # Estimate global motion? (only supports pans, not zoom/rotate)
plevel = default(plevel, truemotion ? 1 : 0) # Penalty for lambda level scaling (0 to 2)
pnew = default(pnew, truemotion ? 50 : 0) # Penalty to SAD cost for candidate vectors
pzero = default(pzero, pnew) # Penalty to SAD cost for zero vector
pglobal = default(pglobal, 0) # Penalty to SAD cost for global vector
overlap = default(overlap, blksize/2) # Horizontal block overlap (must be even & < blksize)
overlapV = default(overlapV, overlap) # Vertical block overlap (must be even & < blksizeV)
dct = default(dct, 0) # Use DCT for SAD calculation (0 to 10; see readme)
divide = default(divide, 0) # Post-processing for MVs (0 to 2; see readme)
sadx264 = default(sadx264, 0) # Use SAD from x264 if available (0 to 12; see readme)
badSAD = default(badSAD, 10000) # SAD threshold to widen search for bad vectors (10000 = disable)
badrange = default(badrange, 24) # Range (radius) of search for bad blocks (use positive values for UMH, negative for Exhaustive)
meander = default(meander, true)
temporal = default(temporal, false)
trymany = default(trymany, false)
multi = default(multi, false)

# MDeGrain params
thSAD = default(thSAD, 400) # SAD threshold for luma plane
thSADC = default(thSADC, thSAD) # SAD threshold for chroma planes
plane = default(plane, 4) # Set which planes to process (0 to 4; 0 = Y, 1 = U, 2 = V, 3 = UV, 4 = YUV)
limit = default(limit, 255) # Limit luma change (0 = filter has no effect, 255 = unlimited)
limitC = default(limitC, limit) # Limit chroma change (0 = filter has no effect, 255 = unlimited)
thSCD1 = default(thSCD1, 400) # Block change threshold for a scene cut
thSCD2 = default(thSCD2, 130) # Percent of blocks that must change to be a scene cut (0 to 255; 0 = 0%, 130 = 51%, 255 = 100%)
lsb = default(lsb, false)
thSAD2 = default(thSAD2, thSAD)
thSADC2 = default(thSADC2, thSADC)

# Added custom params
debugSCD = default(debugSCD, false) # Debug scene change detection thresholds (green = no cut, magenta = cut)

sup = c.MSuper(hpad=hpad, vpad=vpad, pel=pel, levels=MSlevels, chroma=chroma, sharp=sharp, rfilter=rfilter, mt=mt)
mvs = sup.MAnalyse(blksize=blksize, blksizeV=blksizeV, levels=MAlevels, search=search, searchparam=searchparam, pelsearch=pelsearch, lambda=lambda, chroma=chroma, delta=tr, truemotion=truemotion, lsad=lsad, plevel=plevel, global=globalm, pnew=pnew, pzero=pzero, pglobal=pglobal, overlap=overlap, overlapV=overlapV, dct=dct, divide=divide, sadx264=sadx264, badSAD=badSAD, badrange=badrange, meander=meander, temporal=temporal, trymany=trymany, multi=true, mt=mt)
mvd = c.MDeGrainN(sup, mvs, tr, thSAD=thSAD, thSADC=thSADC, plane=plane, limit=limit, limitC=limitC, thSCD1=thSCD1, thSCD2=thSCD2, lsb=lsb, thSAD2=thSAD2, thSADC2=thSADC2, mt=mt)

debugSCD ? StackVertical(mvd.Crop(0, 0, -0, -8), c.MSCDetection(mvs.SelectEvery(tr * 2, 1), thSCD1=thSCD1, thSCD2=thSCD2).Crop(0, 0, -0, 8)) : mvd
}

And now for the script to demonstrate the problem:
src = ColorBars(pixel_type="YV24").AddGrain(var=5, uvar=5)
ebd = src.Scripted_MDeGrain(tr=2, thSAD=150, lsb=false)
sbd = src.Scripted_MDeGrain(tr=2, thSAD=150, lsb=true).ConvertFromStacked(16).ConvertBits(8)

Interleave( \
src.Histogram("color").Crop(640, 0, -0, -224).Subtitle("source"), \
ebd.Histogram("color").Crop(640, 0, -0, -224).Subtitle("8 bit degrain"), \
sbd.Histogram("color").Crop(640, 0, -0, -224).Subtitle("16 bit degrain") \
)

Trim(999, 1001)

...which when run should output this:
https://a.pomf.cat/rngahx.png

You can clearly see the dots "migrate" toward the upper left when using the 16-bit processing. I concede that this could instead be an issue with either my script or ConvertFromStacked()/ConvertBits(), so I'd like to see if anyone else can confirm the issue is indeed in MVTools.

Edit: Forgot to mention, this is with MVTools v2.7.24, and AviSynth+ r2580

Edit2: Also, I can at least say ConvertFromStacked()/ConvertBits() are not the problem, as simply cropping to the size of the source clip instead of using those functions results in the same problem.

Edit3: The shift is perhaps even easier to spot if using Histogram("levels") instead of in the "color" mode. You can also see that this shift affects even the luma.
https://a.pomf.cat/tqupow.png

[poisondeathray]

^It doesn't seem to affect SMDegrain, or at least not as much for U,V .

eg. If you replace with

ebd2 = src.smdegrain(tr=2, thsad=150, lsb=false)
sbd2 = src.smdegrain(tr=2, thsad=150, lsb=true, lsb_out=true).ConvertFromStacked(16).ConvertBits(8)

interleave(src, ebd2,sbd2)
histogram("levels")

I'm not familiar with "Scripted_MDeGrain" but I would have a closer look at that to see why

[`Orum]

I don't use SMDegrain because it does a lot of other things within the filter that I don't want it to do (it uses several other filters IIRC), and back when I originally wrote Scripted_MDegrain it didn't even even exist. Everything within my filter should be covered by MVTools itself or the built-in functions to AviSynth.

I'm slightly curious as to why SMDegrain doesn't have as many problems, but I suspect it's due to the numerous other filters it applies.

[poisondeathray]

I don't use SMDegrain because it does a lot of other things within the filter that I don't want it to do

My understanding is it doesn't do anything else unless you explicitly specify it. By default TR=1 is the default MDegrain1 , TR=2 is the default MDegrain2, etc.... ie. it's just a simple wrapper for MDegrain , unless you specify the other options


I'm slightly curious as to why SMDegrain doesn't have as many problems, but I suspect it's due to the numerous other filters it applies.


I think it uses dither tools for the lsb part , so that might be the difference .

[raffriff42]

I'm seeing some strange color shifting when doing 16-bit processing with MDeGrainN (it does not occur with 8-bit), toward U-/V-
...

Edit3: The shift is perhaps even easier to spot if using Histogram("levels") instead of in the "color" mode.
You can also see that this shift affects even the luma.
https://a.pomf.cat/tqupow.png
This is the ConvertBits rounding error first discussed here (https://forum.doom9.org/showthread.php?p=1820991#post1820991) (although only luma shift was noticed back then, not chroma).
Use ConvertBits(8, dither=0)
EDIT or use ColorYUV(off_y=0.48, off_u=0.48, off_v=0.48).ConvertBits(8)

[poisondeathray]

This is the ConvertBits rounding error first discussed here (https://forum.doom9.org/showthread.php?p=1820991#post1820991).
Use ConvertBits(8, dither=0)
EDIT or use ColorYUV(off_y=0.48, off_u=0.48, off_v=0.48).ConvertBits(8)

When he just crops lsb without using convertbits, the error is still there. So it cannot be ConvertBits rounding issue



Edit2: Also, I can at least say ConvertFromStacked()/ConvertBits() are not the problem, as simply cropping to the size of the source clip instead of using those functions results in the same problem.

[raffriff42]

Doing that does not round, it truncates, which is the nature of the bug. No wonder they look the same.

[poisondeathray]

Doing that does not round, it truncates, which is the nature of the bug. No wonder they look the same.

That makes sense

DitherPost also works, which I'm guessing is what smdegrain uses

[`Orum]

Ah, that makes sense. Hopefully that will get fixed upstream soon, as so few utilities support anything beyond 8-bit, so the functions will see lots of use for previewing. Those that aren't aware of the bug will probably be just as puzzled as I was.

Thanks.

[real.finder]

I don't use SMDegrain because it does a lot of other things within the filter that I don't want it to do (it uses several other filters IIRC), and back when I originally wrote Scripted_MDegrain it didn't even even exist. Everything within my filter should be covered by MVTools itself or the built-in functions to AviSynth.



all used plugins by default are MaskTools2 and MVTools2

and you can set tv_range=false and it will be only MVTools2

[pinterf]

I'm seeing some strange color shifting when doing 16-bit processing with MDeGrainN (it does not occur with 8-bit), toward U-/V- (AKA green). First, let me share the script I wrote to simplify using it:
Thanks, well documented case and it seems to be a tough and very interesting problem, already spent a lot of hours on it.

First I found that 16 bit Degrain results (either stacked (since 2.6.0.5) or native) are not rounded from a 32 bit intermediate. Internally there is a 11-bit extra precision when Overlap is used. Before dropping that extra 11 bit accuracy and converting back to 8..16 bits, a 2^10 rounder should be added to have the final result.

Nor is the 8 bit code perfect, there is a 6 bit shift and its rounding at an earlier phase, and a non-rounding 5 bit shift (6+5=11) when the final result is created from a 16 bit intermediate buffer.

When I have put the proper rounding in the 16bit-like paths, the stacked version became OK, but the native still held a shift, but _only_ after ConvertBits(8). Which is a simple bit shift, the very same as striping off the lower part from a stacked-16 clip.

The script which was adding the noise is good to test. Noise is random, but on average it should be zeroed out. I'm testing with clips with uniform 128-129-128-129 pixel values, plus noise.

How could we turn the shift into numbers instead of looking at Histogram?

We can examine the native 16 bit MDegrain2 result using the AverageLuma runtime function. Interestingly, it showed similar (but of course 256 times as much) and correct result, as the 8 bit Degrain result.

But right after we are stripping the lower byte (=ConvertBits(8)), the AverageLuma result becomes much lower. E.g. AverageLuma=32696 (=127.71*256) becomes 127.42 after converting to 8 bits. Probably that means that there is only a minor residual error somewhere, which should be investigated. (And of course: at wht step does the difference appear between the stacked and the native 16 bit method.

[real.finder]

since the native 16 bit is slower than lsb, even with this https://forum.doom9.org/showthread.php?p=1833823#post1833823 it's little faster but still way slower than the lsb method

can mdegrain has "bits" parameter? so it can be used instead of lsb with avs+

[Motenai Yoda]

since the native 16 bit is slower than lsb, even with this https://forum.doom9.org/showthread.php?p=1833823#post1833823 it's little faster but still way slower than the lsb method

can mdegrain has "bits" parameter? so it can be used instead of lsb with avs+

IIRC lsb isn't 16bit processing but 8bit input -> 16bit output
also you can use ie convertbits(10,dither=1) before mdegrain stuff and convertbits(16) after.
also having a rounding option other than truncate/dithering options will be good.

[real.finder]

IIRC lsb isn't 16bit processing but 8bit input -> 16bit output
also you can use ie convertbits(10,dither=1) before mdegrain stuff and convertbits(16) after.
also having a rounding option other than truncate/dithering options will be good.

yes in mvtools there are only lsb output, 8 input 16 lsb output

the bits parameter will do same thing with bits=16, and it's should be faster than lsb, and can use another bit setting like 12 for more speed, and can use 10 bit clip (for 10 bit source and output 16 bit or any other depending on the settings) or others, let see what pinterf say

[pinterf]

since the native 16 bit is slower than lsb, even with this https://forum.doom9.org/showthread.php?p=1833823#post1833823 it's little faster but still way slower than the lsb method

can mdegrain has "bits" parameter? so it can be used instead of lsb with avs+
Open doors.

Since I had found the reason of another mysterious crash, namely 64bit x264 exited when a specific Qtgmc + Tivtc script was used. The culprit was an ancient assembler mmx code used in MSuper. This code did not clear mmx state, as the original asm code did not issue emms, and the Microsoft x64 mode lacks _mm_empty() command (unlike the Intel compiler possibly used in the 2.6.0.5 era). The result was a crash, x264_64.exe probably was conflicted with the non-restored FPU/MMX states.

So after having inserted the missing 'emms' instruction it became rock solid. But I was so angry on MSuper's mmx heritage that I started to backport the sse2 intrinsic rewrite from VapourSynth mvtools. Then I added 10-16 bit sse2 versions. So MSuper is much faster now in 16bits (50+%).

As a side-effect MSuper now works in 32bit float (no SSE2 yet).

Having a 32 bit float MSuper, I was wondering what happens in a 32bit float MDegrain? (Primarily to see that the 16bit-mode color shift would be seen in 32bit mode, using the artifical example in the previous posts)

I made MDegrain able to use arbitrary bit-depth Super clip with vectors created in 8-16 bit mode.
For example we can have vectors created in 16 bit mode and use MDegrain2 on a 32bit float clip by simply passing a 32bit Super clip for MDegrain.

I have to clean up the code, there was quite a bit of work with implementing these features.

And I still need to run tests because 8 bit MDegrain with overlaps uses a strange rounding but since it exists in the C code and used in the asm assembler files also (copy paste?), I need to know whether it is intentional on a bug.
There is a 11 bit precision integer arithmetic that is converted back in two steps: lose first 6 bit (,sum up them) then lose 5 bits.

In 16 bits (and stacked) mode: final_pixel = (x + 1024) / 2048
In 8 bit: final_pixel = ((x + 256) >> 6) >> 5
I don't think the latter is correct. It results an 0.125 increase on average in the final pixel values.

Probably it should be: final_pixel = ((x + 32) >> 6) + 16) >> 5 ?

[pinterf]

Download MvTools2 2.7.25 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.25)

There were quite a big changes, so please test it.
Apart from the time-consuming mmx state bugfix there is a significant change in MDegrain worth to mention.

Source and Super clip format is now independent of the motion vector clip formats. (apart from the subsampling differences which should be the same - I'm lazy).

This means: one can Degrain even a 32bit float (new!) clip with e.g. 8 bit vectors. Pass a 8 bit clip to Super, then to Analyse and get the vectors.

Then use these vectors in MDegrain, while passing a 32 bit source and a 32 bit Super clip.

- 2.7.25 (20180227)
Fix: x64: not-cleared mmx state in MSuper assembly code would cause crash later, e.g. in x264 encoding, depending on following filters.
Fix: MSCDetection SC value parameter name to Ysc from Yth (must be an ancient typo), docs are OK, the fix is now mentioned in docs
MSuper: import 8 bit sse2 interpolators from mvtools-vs. Extend them for 10-16bits (faster super clip). Some filters are still todo.
MSuper: support 32bit float clips, which can be used later by MDegrains (but not for MAnalyse)
MDegrains: allow degraining clip with different bit depth from vectors. Clip and Super must be the same bit depth
MDegrains: consistently use limit and limitC, 255 do nothing, otherwise scale 0-254 value to the current bit-depth range
Overlaps: more correct internal rounding for 8 bits:
old: pixel = Sum( (tmp + 256) >> 6) >> 5
new: pixel = (Sum( (tmp + 32) >> 6) + 16) >> 5
Overlaps: round for 16bits
old: pixel = Sum(tmp) >> 11
new: pixel = (Sum(tmp) + 1024) >> 11
Overlaps: 32bit float (but still use the original 11 bit window constants)
Project: change from yasm to nasm.

[real.finder]

thanks

and the "bits" parameter in MDegrains? :rolleyes:

[pinterf]

What is your speed difference of a e.g. MDegrain2 when passing 8/16/32bit clip and super, but all with 8 bit vectors?

[real.finder]

What is your speed difference of a e.g. MDegrain2 when passing 8/16/32bit clip and super, but all with 8 bit vectors?

oh, this time native is fast, the one that make it slower last time was MScalevect()

but still lsb a bit faster than native

all 8 bit:- 13.93 fps

native 16 with 8 bit vectors:- 13.34 fps

8 bit with lsb:- 13.60 fps

native 32 with 8 bit vectors:- 11 fps

the test done with ColorBars(width=640, height=480, pixel_type="yv12").AddGrainC

[tormento]

but still lsb a bit faster than native
"Precision" is the same? Effectiveness in removing noise? Perceived quality output?

I am a old aged noob, I prefer to have smart guys opinions about matters I just play with. :)

[real.finder]

"Precision" is the same? Effectiveness in removing noise? Perceived quality output?

I am a old aged noob, I prefer to have smart guys opinions about matters I just play with. :)

they should be same in the case above

HBD or lsb should give no banding output mean it will more quality but has some unseen noise, so 8bit should removing more noise

but anyway let see what pinterf say

[burfadel]

Wouldn't the effective block size in the analysis be different between lsb and native 16 bit? If so it will affect processing speed and possibly output quality.