MVTools, Depan, DepanEstimate for VapourSynth

[Boulder]

Originally Posted by HolyWu

Because the "limit" and "limitc" parameters do not scale internally to the bit depth of the input clip, hence it can't really do anything for so low limits on 16-bit input. The range becomes 0 to 65535 for 16-bit clips.

Damn, I really start feeling like a newbie once more

all 10 modes of dct are broken in the current binary, dct 5-10 have been fixed in the source code, but no binary available yet, dct 1-4 are just broken
I fixed all dct stuff in my floating point branch tho, if u wanna try it

I was wondering why dct=5 is dead slow so it being broken that's probably the reason. Your binary seems to be for x64 so that's out of the question for the moment (because of DGDecodeNV.dll which cannot be loaded in VSx64).

[feisty2]

weird... Is it worth it? Stay on x86 just for a source filter.... That's new
Well, just replace that with ffms or lsmash, both got x64 binaries

[Boulder]

And both have their issues Besides, DG's product is much more convenient for my usage so I'll stick to x86 for the time being. Maybe I'll get around to building MVTools but there's no rush, I'll progress slowly anyway.

[feisty2]

And besides, there's avsreader... So, use dg whatever under avisynth x64, and avsreader will link to avisynth and output the avisynth script as a regular video clip

[jackoneill]

dct > 0 isn't slow because it's broken, it's just slow.

Does limit(c) even do anything? When I tested that, it barely had any effect.

MShow probably won't be added for a long time.

[Boulder]

Are the other options in MVTools functions scaled for 16-bit input (thsad etc.) or will they need to be scaled according to the input bit depth as well?

[Boulder]

Thanks!

[cybersharky]

Please can someone help with writing this function in python?

PHP Code:

function McDegrainSharp(clip c, int "frames", float "bblur", float "csharp", bool "bsrch")
{ # Based on MCDegrain By Didee, [url]http://forum.doom9.org/showthread.php?t=161594[/url]
  # Also based on DiDee observations in this thread: [url]http://forum.doom9.org/showthread.php?t=161580[/url] 
  # "Denoise with MDegrainX, do slight sharpening where motionmatch is good, do slight blurring where motionmatch is bad"
  # In areas where MAnalyse cannot find good matches, the blur() will be dominant.
  # In areas where good matches are found, the sharpen()'ed pixels will overweight the blur()'ed pixels
  # when the pixel averaging is performed. 
    frames = default(frames, 2)
    bblur  = default(bblur, 0.6)
    csharp = default(csharp, 0.6)
    bsrch  = default(bsrch, true)
    bs = (c.width>960) ? 16 : 8
    
    c2 = c.blur(bblur)
    super = bsrch ? c2.MSuper(pel=2, sharp=1) : c.MSuper(pel=2, sharp=1)
    super_rend     = c.sharpen(csharp).MSuper(pel=2, sharp=1,levels=1)
    backward_vec3 = MAnalyse(super, isb = true, delta = 3, blksize=bs, overlap=bs/2)
    backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=bs, overlap=bs/2)
    backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=bs, overlap=bs/2)
    forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=bs, overlap=bs/2)
    forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=bs, overlap=bs/2)
    forward_vec3 = MAnalyse(super, isb = false, delta = 3, blksize=bs, overlap=bs/2)    
    (frames<=0) ? c :\
    (frames==1) ? c2.MDegrain1(super_rend, backward_vec1,forward_vec1,thSAD=400) :\
    (frames==2) ? c2.MDegrain2(super_rend, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400) :\
              c2.MDegrain3(super_rend, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400)
    return(last)
} 


[Are_]

I'm not sure it's working correctly because I can't test it, but here you have it anyway. mcdegrainsharp.py

[Boulder]

Originally Posted by jackoneill

dct > 0 isn't slow because it's broken, it's just slow.

The difference in performance between dct=0 and dct=5 is much less drastic in the Avisynth plugin. Is there any room for improvement (totally unoptimized code or something) or is it about as good as it gets?

[jackoneill]

Originally Posted by Boulder

The difference in performance between dct=0 and dct=5 is much less drastic in the Avisynth plugin. Is there any room for improvement (totally unoptimized code or something) or is it about as good as it gets?

If it's slower than the Avisynth plugin then yes, there is room for improvement. I don't know what makes it slower in this case.

[Boulder]

I made a quick test with 8-bit clips. The scripts are naturally not exactly the same but the operations are quite close to each other.

1.68 fps, Vapoursynth with dct=5
3.70 fps, Vapoursynth with dct=0
2.79 fps, Avisynth with dct=5
2.99 fps, Avisynth with dct=0

[Tarutaru]

Originally Posted by Are_

I'm not sure it's working correctly because I can't test it, but here you have it anyway. mcdegrainsharp.py

Thanks, but when I apply this function, the color is changed...

import vapoursynth as vs
import mcdegrainsharp as mcds
core = vs.get_core()
ret = core.ffms2.Source(source='/foo/bar.mkv')
ret1 = mcds.mcdegrainsharp(ret)
ret = core.std.Interleave([ret,ret1])
ret.set_output()

Original:
https://na.cx/i/FbQhF3.png

Output:
https://na.cx/i/0d1JvY.png

Look at the grass between Lipton and the other tropper, they are not as green as the original....

[Are_]

Yeah, indeed. Looks like generic.Blur is bugged when input is 8bit? Try again with the latest version please, keep in mind the weights for ssharp and bblur behave differently now.

[Tarutaru]

Originally Posted by Are_

Yeah, indeed. Looks like generic.Blur is bugged when input is 8bit? Try again with the latest version please, keep in mind the weights for ssharp and bblur behave differently now.

It looks good with the new version
Original:
https://na.cx/i/Rj64wd.png
Output:
https://na.cx/i/52ag3Z.png

[Boulder]

Originally Posted by Boulder

is it OK to simply resize to double the dimensions of the clip fed to Super as pelclip (if pel=2)? In Avisynth 2.6, you need to do some shifting.

What about this question?

[jackoneill]

Originally Posted by Boulder

What about this question?

If shifting is needed in Avisynth, then it's needed here too.

[Boulder]

I found a bug in the latest release. This code will crash MVTools, I'm getting a crash around frame 15. Sometimes frame 7 also causes it. You can also see that there's a lot of artifacts around the coloured area in several frames.

The crash doesn't occur if the line feed = has.DitherLumaRebuild(clp) is replaced by feed = clp.

The crash and artifacts disappear if the conversion to 16 bits is removed, or if you remove the last two lines with mv.Recalculate.

import vapoursynth as vs
import havsfunc as has

core = vs.get_core()

clp = core.ffms2.Source(r'u:\test-002.264')
clp = core.fmtc.bitdepth(clp, bits=16)

feed = has.DitherLumaRebuild(clp)

superanalyse = core.mv.Super(feed, pel=2, rfilter=4)
supermdg = core.mv.Super(clp, pel=2, rfilter=4, levels=1)

bv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, isb=True)
fv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, isb=False)
bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=100, blksize=8, overlap=4, search=3)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=100, blksize=8, overlap=4, search=3)
bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=100, blksize=4, overlap=2, search=3)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=100, blksize=4, overlap=2, search=3)

finalclip = core.mv.Degrain1(clp, supermdg, bv1, fv1, thscd1=300, thscd2=80)

output = finalclip

output.set_output()

Here's the sample clip to use to test and debug:
https://drive.google.com/file/d/0Bze...ew?usp=sharing

[jackoneill]

Originally Posted by Boulder

I found a bug in the latest release. This code will crash MVTools, I'm getting a crash around frame 15. Sometimes frame 7 also causes it. You can also see that there's a lot of artifacts around the coloured area in several frames.

I can reproduce this. Some integer variable probably overflows, because MVTools wasn't written with 16 bit input in mind. (Something similar has happened before.)

[feisty2]

Originally Posted by Boulder

I found a bug in the latest release. This code will crash MVTools, I'm getting a crash around frame 15. Sometimes frame 7 also causes it. You can also see that there's a lot of artifacts around the coloured area in several frames.

The crash doesn't occur if the line feed = has.DitherLumaRebuild(clp) is replaced by feed = clp.

The crash and artifacts disappear if the conversion to 16 bits is removed, or if you remove the last two lines with mv.Recalculate.

import vapoursynth as vs
import havsfunc as has

core = vs.get_core()

clp = core.ffms2.Source(r'u:\test-002.264')
clp = core.fmtc.bitdepth(clp, bits=16)

feed = has.DitherLumaRebuild(clp)

superanalyse = core.mv.Super(feed, pel=2, rfilter=4)
supermdg = core.mv.Super(clp, pel=2, rfilter=4, levels=1)

bv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, isb=True)
fv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, isb=False)
bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=100, blksize=8, overlap=4, search=3)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=100, blksize=8, overlap=4, search=3)
bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=100, blksize=4, overlap=2, search=3)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=100, blksize=4, overlap=2, search=3)

finalclip = core.mv.Degrain1(clp, supermdg, bv1, fv1, thscd1=300, thscd2=80)

output = finalclip

output.set_output()

Here's the sample clip to use to test and debug:
https://drive.google.com/file/d/0Bze...ew?usp=sharing

tested your script (removed chroma and changed bitdepth to 32) on my floating point branch and didn't see any crash or artifacts...
weird, cuz my branch was forked from this master branch and should have suffered the same issue...