Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th August 2016, 08:45   #61  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by yup View Post
pinterf!

I see some slowdown for dct=5, approx. 10%.
FFTW updated.
yup.
Yes, slowdown, because the old one did virtually nothing.
pinterf is offline   Reply With Quote
Old 5th September 2016, 03:59   #62  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
hi pinterf, since you work on mvtools, dogway said that denoising chroma with luma only vectors is bugged
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 5th September 2016, 05:21   #63  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
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.
pinterf is offline   Reply With Quote
Old 5th September 2016, 07:19   #64  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by pinterf View Post
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
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 5th September 2016, 08:49   #65  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Thanks, I will look into it.
pinterf is offline   Reply With Quote
Old 26th September 2016, 21:32   #66  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
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

Last edited by pinterf; 26th September 2016 at 21:54. Reason: clarify no release
pinterf is offline   Reply With Quote
Old 30th September 2016, 18:35   #67  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by pinterf View Post
As a result of generality: now we have a new MDegrain4 and MDegrain5.
We need MDegrain6 too
__________________
@turment on Telegram
tormento is online now   Reply With Quote
Old 30th September 2016, 19:23   #68  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Haha, I was just practicing. And you will get a special MDegrain2.718281, too
pinterf is offline   Reply With Quote
Old 1st October 2016, 19:32   #69  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by pinterf View Post
Haha, I was just practicing. And you will get a special MDegrain2.718281, too
MDegrainE
__________________
@turment on Telegram
tormento is online now   Reply With Quote
Old 19th October 2016, 00:47   #70  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by pinterf View Post
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
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 19th October 2016, 16:57   #71  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
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.
pinterf is offline   Reply With Quote
Old 20th October 2016, 03:45   #72  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by pinterf View Post
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?
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 20th October 2016, 14:52   #73  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by real.finder View Post
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.
pinterf is offline   Reply With Quote
Old 20th October 2016, 16:09   #74  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by pinterf View Post
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
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 20th October 2016, 19:42   #75  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
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)

Last edited by pinterf; 20th October 2016 at 19:57.
pinterf is offline   Reply With Quote
Old 22nd October 2016, 01:17   #76  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
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=falsedelta=1overlap=4)
bv1 sup.MAnalyse(isb=truedelta=1overlap=4)
fv2 sup.MAnalyse(isb=falsedelta=2overlap=4)
bv2 sup.MAnalyse(isb=truedelta=2overlap=4)
MDegrain2(Supbv1fv1bv2fv2thSAD=200)
converttostacked()
b=last

d
=Dither_convert_8_to_16()
sup2 MSuper(pel=1#pel=2
fv12 sup2.MAnalyse(isb=falsedelta=1overlap=4)
bv12 sup2.MAnalyse(isb=truedelta=1overlap=4)
fv22 sup2.MAnalyse(isb=falsedelta=2overlap=4)
bv22 sup2.MAnalyse(isb=truedelta=2overlap=4)

m=d.dither_get_msb()
supM m.Msuper(pel=1)

l=d.dither_get_lsb()
supL l.Msuper(pel=1)

msb=m.MDegrain2(SupMbv12fv12bv22fv22thSAD=200,lsb=true)
lsbl.MDegrain2(SupLbv12fv12bv22fv22thSAD=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.
Motenai Yoda is offline   Reply With Quote
Old 23rd October 2016, 21:48   #77  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Motenai Yoda View Post
sure this is right? with
PHP Code:
ConvertBits(16)
sup MSuper(pel=1#pel=2
fv1 sup.MAnalyse(isb=falsedelta=1overlap=4)
bv1 sup.MAnalyse(isb=truedelta=1overlap=4)
fv2 sup.MAnalyse(isb=falsedelta=2overlap=4)
bv2 sup.MAnalyse(isb=truedelta=2overlap=4)
MDegrain2(Supbv1fv1bv2fv2thSAD=200)
converttostacked()
b=last

d
=Dither_convert_8_to_16()
sup2 MSuper(pel=1#pel=2
fv12 sup2.MAnalyse(isb=falsedelta=1overlap=4)
bv12 sup2.MAnalyse(isb=truedelta=1overlap=4)
fv22 sup2.MAnalyse(isb=falsedelta=2overlap=4)
bv22 sup2.MAnalyse(isb=truedelta=2overlap=4)

m=d.dither_get_msb()
supM m.Msuper(pel=1)

l=d.dither_get_lsb()
supL l.Msuper(pel=1)

msb=m.MDegrain2(SupMbv12fv12bv22fv22thSAD=200,lsb=true)
lsbl.MDegrain2(SupLbv12fv12bv22fv22thSAD=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)

Last edited by pinterf; 23rd October 2016 at 21:58. Reason: Comparison script
pinterf is offline   Reply With Quote
Old 24th October 2016, 01:28   #78  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
Quote:
Originally Posted by pinterf View Post
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...
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 24th October 2016, 07:58   #79  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by Motenai Yoda View Post
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.
pinterf is offline   Reply With Quote
Old 25th October 2016, 08:59   #80  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
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
real.finder is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.