MVTools-pfmod - Page 4

pinterf · 17th August 2016, 08:45

Quote:

Originally Posted by yup

pinterf!

I see some slowdown for dct=5, approx. 10%.
FFTW updated.
yup.

Yes, slowdown, because the old one did virtually nothing.

real.finder · 5th September 2016, 03:59

hi pinterf, since you work on mvtools, dogway said that denoising chroma with luma only vectors is bugged

pinterf · 5th September 2016, 05:21

Is this bug a new one with yv24? Anyway, some more hint, format, script and parameters would be welcome. Freeze or just garbaged output? I am thankful for each minute I can spare instead of blind guessing.

real.finder · 5th September 2016, 07:19

Quote:

Originally Posted by pinterf

Is this bug a new one with yv24? Anyway, some more hint, format, script and parameters would be welcome. Freeze or just garbaged output? I am thankful for each minute I can spare instead of blind guessing.

it's old, dogway write this in SMDegrain

Code:

!chroma         ? Assert(plane==0,                     "Denoising chroma with luma only vectors is bugged in mvtools and thus unsupported") : nop()

and here http://forum.doom9.org/showthread.ph...05#post1551305

pinterf · 5th September 2016, 08:49

Thanks, I will look into it.

pinterf · 26th September 2016, 21:32

I have run the script you linked

Code:

chroma=false
plane=4

super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
bv2=super_search.MAnalyse(isb = true, delta = 2,chroma=chroma)
bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
fv2=super_search.MAnalyse(isb = false, delta = 2,chroma=chroma)
MDegrain2(super_search, bv1, fv1, bv2, fv2, thSAD=200,plane=plane)

but found nothing.

Since I had to deal with the code, did it seriously and unified the MDegrain1/2/3 code for better understanding. It became much more general and a bit faster (at least for MSVC).

As a result of generality: now we have a new MDegrain4 and MDegrain5.

Note that MDegrainN still exists but if there are no special extra SAD parameters, it calls MDegrain1/2/3. No change, it did call them before - but now calls MDegrain4 and MDegrain5 for tr=4 or 5. (Reason by the docs: because they are faster).

Then I became curious whether I can make mvtools co-operate with the latest avs+ dev build, so went on. I had already made MSuper work for 16 bit in the past. The analyzation parts (b and f vectors) still work at 8 bits (haven't ported yet MAnalyze), but MDegrain1/5 can use a 16 bit input and 16 bit super clip and the output is also native 16 bits

Code:

a=Avisource("Hi8.avi").assumefps(25,1).trim(0, 499)
a=a.ConvertToYUV444()
sup = a.MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
fv3 = sup.MAnalyse(isb=false, delta=3, overlap=4)
bv3 = sup.MAnalyse(isb=true, delta=3, overlap=4)
fv4 = sup.MAnalyse(isb=false, delta=4, overlap=4)
bv4 = sup.MAnalyse(isb=true, delta=4, overlap=4)
fv5 = sup.MAnalyse(isb=false, delta=5, overlap=4)
bv5 = sup.MAnalyse(isb=true, delta=5, overlap=4)
sup16=a.ConvertBits(16).MSuper(pel=1)
a.ConvertBits(16).MDegrain5(Sup16, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv5, fv5, thSAD=10000). Info()
ConvertBits(8, dither=0)

Btw, I managed to replace/rewrite the remaining inline asm codes (integer DCT, Resizers, YUY2 converters etc.) for SIMD intrinsics, and now it compiles x64 version in plain VS2015 (+yasm of course)!

And the last info:
Earlier last week I have found some more YV12/YUY specific codes (x/2) in MFlow/MFlowFPS, which may have issues at YV24 in 2.7.0.22d. I hope these occurences were the last ones of this type.

PS: no release, just status report

tormento · 30th September 2016, 18:35

Quote:

Originally Posted by pinterf

As a result of generality: now we have a new MDegrain4 and MDegrain5.

We need MDegrain6 too

pinterf · 30th September 2016, 19:23

Haha, I was just practicing. And you will get a special MDegrain2.718281, too

tormento · 1st October 2016, 19:32

Quote:

Originally Posted by pinterf

Haha, I was just practicing. And you will get a special MDegrain2.718281, too

MDegrainE

real.finder · 19th October 2016, 00:47

Quote:

Originally Posted by pinterf

I have run the script you linked

Code:

chroma=false
plane=4

super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
bv2=super_search.MAnalyse(isb = true, delta = 2,chroma=chroma)
bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
fv2=super_search.MAnalyse(isb = false, delta = 2,chroma=chroma)
MDegrain2(super_search, bv1, fv1, bv2, fv2, thSAD=200,plane=plane)

but found nothing.

since dogway didn't come I find sample that has the bug

first, I edit the SMDegrain to accept this case

the sample http://rgho.st/private/64kh5qQPS/203...c92d8518f840c5

here frame 55 without filter http://i.imgur.com/24VWm23.png

and here with SMDegrain(chroma=false) http://i.imgur.com/fIkzlH1.png

pinterf · 19th October 2016, 16:57

Ok, here is my script

Code:

FFMS2("chroma.mp4")
#ConvertToYUV444()
chroma=false
plane=4 # 0:Luma 1:U 2:V 3:UV 4:All
#ConvertBits(12) #10-16
#super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
super_search=MSuper(chroma=true)

bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
a=MDegrain1(super_search, bv1, fv1, thSAD=0,plane=plane)
b=MDegrain1(super_search, bv1, fv1, thSAD=200,plane=plane)
c=MDegrain1(super_search, bv1, fv1, thSAD=2000,plane=plane)
Stackvertical(a,b,c)#.GreyScale() # bigger thSAD: more "false" blocks but not in greyscale
#MShow(super_search, bv1) #uncomment to see vectors
#super_search #uncomment to see super clip
#ConvertBits(8)

I cannot see bugs here. The big static uniform colored areas make the motion estimation very hard.
Uncomment the MShow line above the see those vectors.

What I also recognized that the blotchy artifacts occur when the luma-only sad is minimal.
Check frame 49, lower right corner. MDegrain is in work, it blends frame #50 into that.
You can check it best at the thSAD=2000 clip. (3rd one if using the above stacked script)
When you uncomment grayscale conversion, it seem to be ok.
I think this kind of clip needs fine-tuning.

real.finder · 20th October 2016, 03:45

Quote:

Originally Posted by pinterf

Ok, here is my script

Code:

FFMS2("chroma.mp4")
#ConvertToYUV444()
chroma=false
plane=4 # 0:Luma 1:U 2:V 3:UV 4:All
#ConvertBits(12) #10-16
#super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
super_search=MSuper(chroma=true)

bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
a=MDegrain1(super_search, bv1, fv1, thSAD=0,plane=plane)
b=MDegrain1(super_search, bv1, fv1, thSAD=200,plane=plane)
c=MDegrain1(super_search, bv1, fv1, thSAD=2000,plane=plane)
Stackvertical(a,b,c)#.GreyScale() # bigger thSAD: more "false" blocks but not in greyscale
#MShow(super_search, bv1) #uncomment to see vectors
#super_search #uncomment to see super clip
#ConvertBits(8)

I cannot see bugs here. The big static uniform colored areas make the motion estimation very hard.
Uncomment the MShow line above the see those vectors.

What I also recognized that the blotchy artifacts occur when the luma-only sad is minimal.
Check frame 49, lower right corner. MDegrain is in work, it blends frame #50 into that.
You can check it best at the thSAD=2000 clip. (3rd one if using the above stacked script)
When you uncomment grayscale conversion, it seem to be ok.
I think this kind of clip needs fine-tuning.

yes, you right, but the problem is why with chroma=true at the thSAD=200 clip chroma will be good but with chroma=false will be that bad?

pinterf · 20th October 2016, 14:52

Quote:

Originally Posted by real.finder

yes, you right, but the problem is why with chroma=true at the thSAD=200 clip chroma will be good but with chroma=false will be that bad?

When you ignore chroma in MAnalyze, the computed SAD (sum of absolute pixel differences between frame blocks (e.g. current, current-1)) will only be computed on luma. If SAD is zero, the blocks are 100% similar.

MDegrain makes its decision on comparing this precomputed sad value (per block) with the given thSAD parameter.

The position of the artifacts is seen exactly at those places where the luma value (check the greyscale clip) is very similar between the compared - e.g. current - next_by_1 - frames.
I think that in this case the SAD of the block (based on luma data only) is well below the given thSAD threshold,thus the blocks are getting blended together. If the difference (SAD) is minimal, then the similar blocks are practically averaged (more or less).

So based only by the luma, it happens that two completely differently colored blocks are merged. Although they differ on the chroma very much, but we asked MAnalyze to ignore it with chroma=false. And we can see the result: one block of the current frame is orange, the next frame contains a blueish grey block at the same place, their luma is similar; the resulting block will look nice in greyscale, but the chroma - and our visual feelings - will be somewhat mixed.

At least this is what I have learned from the code itself and the usage experiences so far.

real.finder · 20th October 2016, 16:09

Quote:

Originally Posted by pinterf

When you ignore chroma in MAnalyze, the computed SAD (sum of absolute pixel differences between frame blocks (e.g. current, current-1)) will only be computed on luma. If SAD is zero, the blocks are 100% similar.

MDegrain makes its decision on comparing this precomputed sad value (per block) with the given thSAD parameter.

The position of the artifacts is seen exactly at those places where the luma value (check the greyscale clip) is very similar between the compared - e.g. current - next_by_1 - frames.
I think that in this case the SAD of the block (based on luma data only) is well below the given thSAD threshold,thus the blocks are getting blended together. If the difference (SAD) is minimal, then the similar blocks are practically averaged (more or less).

So based only by the luma, it happens that two completely differently colored blocks are merged. Although they differ on the chroma very much, but we asked MAnalyze to ignore it with chroma=false. And we can see the result: one block of the current frame is orange, the next frame contains a blueish grey block at the same place, their luma is similar; the resulting block will look nice in greyscale, but the chroma - and our visual feelings - will be somewhat mixed.

At least this is what I have learned from the code itself and the usage experiences so far.

I see, so chroma=false without plane=0 is bad idea especially in Anime

maybe with good chosen of Search parameter in MAnalyze will make it better

pinterf · 20th October 2016, 19:42

After having released the first real test build of high bit depth Avisynth+, here is another release:
MvTools2 2.7.1.22

Important note:
Built with VS2015, this build is 3-8% slower than previous ICC build. Don't use it if you stuck at YV12 or YUY2 clips and this speed loss makes you unhappy.

Changes:

Experimental native 10-16 bit support (MSuper, MAnalyze, MDegrain1-5, MDegrainN)
Some additional fixes for YV24
New: MDegrain4, MDegrain5
16 bit SATD (slow C) for dct>=5 modes and SSE2 optimized regular SAD for 10-16 bits
for 10+ bits you need at least Avisynth+ r2290 but works with classic avs on 8 bits
Inline assembly rewritten to intrinsics -> 64 bit build is possible in VS2015
(External assembly untouched)
Experimental AVX/AVX2 code paths (maybe insignificant, at least I had a test how to mix them together with a non-avx core

Demo script (avs+):

Code:

SetMemoryMax(6000)
FFMS2("prores_yuv422p10le_hq_apch_yuv422p10.mov").RemoveAlphaPlane() #if YUVA original
ConvertBits(14)
ConvertToYUV444()
sup = MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
fv3 = sup.MAnalyse(isb=false, delta=3, overlap=4)
bv3 = sup.MAnalyse(isb=true, delta=3, overlap=4)
fv4 = sup.MAnalyse(isb=false, delta=4, overlap=4)
bv4 = sup.MAnalyse(isb=true, delta=4, overlap=4)
fv5 = sup.MAnalyse(isb=false, delta=5, overlap=4)
bv5 = sup.MAnalyse(isb=true, delta=5, overlap=4)
MDegrain5(Sup, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv5, fv5, thSAD=10000). Info()
ConvertBits(8,dither=0)

Motenai Yoda · 22nd October 2016, 01:17

sure this is right? with

PHP Code:


			
ConvertBits(16)

sup = MSuper(pel=1) #pel=2

fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)

bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)

fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)

bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)

MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200)

converttostacked()

b=last



d=Dither_convert_8_to_16()

sup2 = MSuper(pel=1) #pel=2

fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4)

bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4)

fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4)

bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4)



m=d.dither_get_msb()

supM = m.Msuper(pel=1)



l=d.dither_get_lsb()

supL = l.Msuper(pel=1)



msb=m.MDegrain2(SupM, bv12, fv12, bv22, fv22, thSAD=200,lsb=true)

lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200)



nullclip = l.mt_lut(y=0,u=0,v=0)

diff1=stackvertical(nullclip,lsb)

msb.dither_add16(diff1)

c=last



mt_makediff(b,c,u=3,v=3)

levels(100,1,155,0,255,true)

I get the same lsb part but different msb one, like is applied dithering on msb.
also seems to be slower

pinterf · 23rd October 2016, 21:48

Quote:

Originally Posted by Motenai Yoda

sure this is right? with

PHP Code:


			
ConvertBits(16)

sup = MSuper(pel=1) #pel=2

fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)

bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)

fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)

bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)

MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200)

converttostacked()

b=last



d=Dither_convert_8_to_16()

sup2 = MSuper(pel=1) #pel=2

fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4)

bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4)

fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4)

bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4)



m=d.dither_get_msb()

supM = m.Msuper(pel=1)



l=d.dither_get_lsb()

supL = l.Msuper(pel=1)



msb=m.MDegrain2(SupM, bv12, fv12, bv22, fv22, thSAD=200,lsb=true)

lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200)



nullclip = l.mt_lut(y=0,u=0,v=0)

diff1=stackvertical(nullclip,lsb)

msb.dither_add16(diff1)

c=last



mt_makediff(b,c,u=3,v=3)

levels(100,1,155,0,255,true)

I get the same lsb part but different msb one, like is applied dithering on msb.
also seems to be slower

1.) Is it intentional that the input of the 2nd pass is the stacked 8 bit output of the first 16 bit degrain phase?
2.) Then I don't understand the second part.
You make a d=Dither_convert_8_to_16() from an already stacked clip, and take its lsb that is always zero and filter it, why?

Code:

l=d.dither_get_lsb()
supL = l.Msuper(pel=1)
lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200)

My comparison script:

Code:

FFMS2("chroma.mp4")#.trim(0, 499)
orig8=last
ConvertBits(16)
sup = MSuper(pel=1) #pel=2
fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4)
bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4)
fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4)
bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4)
MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200)
converttostacked()
stackedresult1 =last

orig8
sup2 = MSuper(pel=1) #pel=2
fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4)
bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4)
fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4)
bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4)
stackedResult2 = orig8.MDegrain2(Sup2, bv12, fv12, bv22, fv22, thSAD=200,lsb=true)

mt_makediff(stackedresult1,stackedresult2,u=3,v=3)
levels(100,1,155,0,255,true)

Motenai Yoda · 24th October 2016, 01:28

Quote:

Originally Posted by pinterf

1.) Is it intentional that the input of the 2nd pass is the stacked 8 bit output of the first 16 bit degrain phase?
2.) Then I don't understand the second part.
You make a d=Dither_convert_8_to_16() from an already stacked clip, and take its lsb that is always zero and filter it, why?

1- no it wasn't lol
2- that is the way I use mdegrain on stacked clip, indeed lsb filtered part is all 0 if the input clip's lsb is all 0

btw I found a lot of differences even with your method, in the msb part too...

pinterf · 24th October 2016, 07:58

Quote:

Originally Posted by Motenai Yoda

1- no it wasn't lol
2- that is the way I use mdegrain on stacked clip, indeed lsb filtered part is all 0 if the input clip's lsb is all 0

btw I found a lot of differences even with your method, in the msb part too...

There's no reason to get identical results.
For 16 bit input, even if the original clip is 8 bits and its straight 16 bit conversion has zero lsb, the lower resolution subclips in Super are already interpolated and have meaningful lsb parts.
So the vectors after MAnalyze are possibly different than it would be estimated from a single 8 bit source.
Then the weighting and blending inside MDegrain works with higher precision than for a 8 bit input. That is a difference, too.

real.finder · 25th October 2016, 08:59

speaking of MAnalyze, I have an idea in my mind but I don't know if it good or not, or even if I can do it

it's for 8 bit clip, it's by doing convert to yv24 (if it not yv24) then merge Y, U and V in one 16 bit plane (Y16) then use it in MAnalyze to get more accurate motion vectors

and then use the vectors for both luma and chroma

5th September 2016, 03:59	#62 \| Link
real.finder Registered User Join Date: Jan 2012 Location: Mesopotamia Posts: 2,579	hi pinterf, since you work on mvtools, dogway said that denoising chroma with luma only vectors is bugged __________________ See My Avisynth Stuff

5th September 2016, 05:21	#63 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,246	Is this bug a new one with yv24? Anyway, some more hint, format, script and parameters would be welcome. Freeze or just garbaged output? I am thankful for each minute I can spare instead of blind guessing. __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

5th September 2016, 08:49	#65 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,246	Thanks, I will look into it. __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

26th September 2016, 21:32	#66 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,246	I have run the script you linked Code: chroma=false plane=4 super_search=MSuper(chroma=chroma?true:(plane==0?false:true)) bv2=super_search.MAnalyse(isb = true, delta = 2,chroma=chroma) bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma) fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma) fv2=super_search.MAnalyse(isb = false, delta = 2,chroma=chroma) MDegrain2(super_search, bv1, fv1, bv2, fv2, thSAD=200,plane=plane) but found nothing. Since I had to deal with the code, did it seriously and unified the MDegrain1/2/3 code for better understanding. It became much more general and a bit faster (at least for MSVC). As a result of generality: now we have a new MDegrain4 and MDegrain5. Note that MDegrainN still exists but if there are no special extra SAD parameters, it calls MDegrain1/2/3. No change, it did call them before - but now calls MDegrain4 and MDegrain5 for tr=4 or 5. (Reason by the docs: because they are faster). Then I became curious whether I can make mvtools co-operate with the latest avs+ dev build, so went on. I had already made MSuper work for 16 bit in the past. The analyzation parts (b and f vectors) still work at 8 bits (haven't ported yet MAnalyze), but MDegrain1/5 can use a 16 bit input and 16 bit super clip and the output is also native 16 bits Code: a=Avisource("Hi8.avi").assumefps(25,1).trim(0, 499) a=a.ConvertToYUV444() sup = a.MSuper(pel=1) #pel=2 fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4) bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4) fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4) bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4) fv3 = sup.MAnalyse(isb=false, delta=3, overlap=4) bv3 = sup.MAnalyse(isb=true, delta=3, overlap=4) fv4 = sup.MAnalyse(isb=false, delta=4, overlap=4) bv4 = sup.MAnalyse(isb=true, delta=4, overlap=4) fv5 = sup.MAnalyse(isb=false, delta=5, overlap=4) bv5 = sup.MAnalyse(isb=true, delta=5, overlap=4) sup16=a.ConvertBits(16).MSuper(pel=1) a.ConvertBits(16).MDegrain5(Sup16, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv5, fv5, thSAD=10000). Info() ConvertBits(8, dither=0) Btw, I managed to replace/rewrite the remaining inline asm codes (integer DCT, Resizers, YUY2 converters etc.) for SIMD intrinsics, and now it compiles x64 version in plain VS2015 (+yasm of course)! And the last info: Earlier last week I have found some more YV12/YUY specific codes (x/2) in MFlow/MFlowFPS, which may have issues at YV24 in 2.7.0.22d. I hope these occurences were the last ones of this type. PS: no release, just status report __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average Last edited by pinterf; 26th September 2016 at 21:54. Reason: clarify no release

30th September 2016, 19:23	#68 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,246	Haha, I was just practicing. And you will get a special MDegrain2.718281, too __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

19th October 2016, 16:57	#71 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,246	Ok, here is my script Code: FFMS2("chroma.mp4") #ConvertToYUV444() chroma=false plane=4 # 0:Luma 1:U 2:V 3:UV 4:All #ConvertBits(12) #10-16 #super_search=MSuper(chroma=chroma?true:(plane==0?false:true)) super_search=MSuper(chroma=true) bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma) fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma) a=MDegrain1(super_search, bv1, fv1, thSAD=0,plane=plane) b=MDegrain1(super_search, bv1, fv1, thSAD=200,plane=plane) c=MDegrain1(super_search, bv1, fv1, thSAD=2000,plane=plane) Stackvertical(a,b,c)#.GreyScale() # bigger thSAD: more "false" blocks but not in greyscale #MShow(super_search, bv1) #uncomment to see vectors #super_search #uncomment to see super clip #ConvertBits(8) I cannot see bugs here. The big static uniform colored areas make the motion estimation very hard. Uncomment the MShow line above the see those vectors. What I also recognized that the blotchy artifacts occur when the luma-only sad is minimal. Check frame 49, lower right corner. MDegrain is in work, it blends frame #50 into that. You can check it best at the thSAD=2000 clip. (3rd one if using the above stacked script) When you uncomment grayscale conversion, it seem to be ok. I think this kind of clip needs fine-tuning. __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average

20th October 2016, 19:42	#75 \| Link
pinterf Registered User Join Date: Jan 2014 Posts: 2,246	After having released the first real test build of high bit depth Avisynth+, here is another release: MvTools2 2.7.1.22 Important note: Built with VS2015, this build is 3-8% slower than previous ICC build. Don't use it if you stuck at YV12 or YUY2 clips and this speed loss makes you unhappy. Changes: Experimental native 10-16 bit support (MSuper, MAnalyze, MDegrain1-5, MDegrainN) Some additional fixes for YV24 New: MDegrain4, MDegrain5 16 bit SATD (slow C) for dct>=5 modes and SSE2 optimized regular SAD for 10-16 bits for 10+ bits you need at least Avisynth+ r2290 but works with classic avs on 8 bits Inline assembly rewritten to intrinsics -> 64 bit build is possible in VS2015 (External assembly untouched) Experimental AVX/AVX2 code paths (maybe insignificant, at least I had a test how to mix them together with a non-avx core Demo script (avs+): Code: SetMemoryMax(6000) FFMS2("prores_yuv422p10le_hq_apch_yuv422p10.mov").RemoveAlphaPlane() #if YUVA original ConvertBits(14) ConvertToYUV444() sup = MSuper(pel=1) #pel=2 fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4) bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4) fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4) bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4) fv3 = sup.MAnalyse(isb=false, delta=3, overlap=4) bv3 = sup.MAnalyse(isb=true, delta=3, overlap=4) fv4 = sup.MAnalyse(isb=false, delta=4, overlap=4) bv4 = sup.MAnalyse(isb=true, delta=4, overlap=4) fv5 = sup.MAnalyse(isb=false, delta=5, overlap=4) bv5 = sup.MAnalyse(isb=true, delta=5, overlap=4) MDegrain5(Sup, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv5, fv5, thSAD=10000). Info() ConvertBits(8,dither=0) __________________ AviSynth+ on github, Other repos: RgTools, Masktools2, MvTools2, TIVTC, Average Last edited by pinterf; 20th October 2016 at 19:57.

22nd October 2016, 01:17	#76 \| Link
Motenai Yoda Registered User Join Date: Jan 2010 Posts: 709	sure this is right? with PHP Code: ConvertBits(16) sup = MSuper(pel=1) #pel=2 fv1 = sup.MAnalyse(isb=false, delta=1, overlap=4) bv1 = sup.MAnalyse(isb=true, delta=1, overlap=4) fv2 = sup.MAnalyse(isb=false, delta=2, overlap=4) bv2 = sup.MAnalyse(isb=true, delta=2, overlap=4) MDegrain2(Sup, bv1, fv1, bv2, fv2, thSAD=200) converttostacked() b=last d=Dither_convert_8_to_16() sup2 = MSuper(pel=1) #pel=2 fv12 = sup2.MAnalyse(isb=false, delta=1, overlap=4) bv12 = sup2.MAnalyse(isb=true, delta=1, overlap=4) fv22 = sup2.MAnalyse(isb=false, delta=2, overlap=4) bv22 = sup2.MAnalyse(isb=true, delta=2, overlap=4) m=d.dither_get_msb() supM = m.Msuper(pel=1) l=d.dither_get_lsb() supL = l.Msuper(pel=1) msb=m.MDegrain2(SupM, bv12, fv12, bv22, fv22, thSAD=200,lsb=true) lsb= l.MDegrain2(SupL, bv12, fv12, bv22, fv22, thSAD=200) nullclip = l.mt_lut(y=0,u=0,v=0) diff1=stackvertical(nullclip,lsb) msb.dither_add16(diff1) c=last mt_makediff(b,c,u=3,v=3) levels(100,1,155,0,255,true) I get the same lsb part but different msb one, like is applied dithering on msb. also seems to be slower __________________ powered by Google Translator Last edited by Motenai Yoda; 22nd October 2016 at 01:27.

25th October 2016, 08:59	#80 \| Link
real.finder Registered User Join Date: Jan 2012 Location: Mesopotamia Posts: 2,579	speaking of MAnalyze, I have an idea in my mind but I don't know if it good or not, or even if I can do it it's for 8 bit clip, it's by doing convert to yv24 (if it not yv24) then merge Y, U and V in one 16 bit plane (Y16) then use it in MAnalyze to get more accurate motion vectors and then use the vectors for both luma and chroma __________________ See My Avisynth Stuff

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode