MVDegrain as an independent function?

[Terranigma]

Hello, I was wonderin' if MVDegrain would function properly if it was a lone filter like ttempsmooth, instead of being dependent on the built-in clp,clp x function (degrain 1, 2, 3) and it's auto interleave feature. It's one of the top temporal denoisers, but under certain circumstances, it sometimes doesn't do anything (as shown by King Didée).


the reason to make a step-by-step rebuild of MVDegrain3 was more towards adding some features in that MVDegrainX does not have at all. (When going to make suggestions to a dev, ears are wider open when you can show a working solution instead of just boring with theoretical blabla.)

Par ex: Seamless integration of using an alternative filter (resp. an alternatively filtered clip), weighted by thSAD:

http://img151.imageshack.us/img151/4931/mvdegrainmu4.th.png (http://img151.imageshack.us/my.php?image=mvdegrainmu4.png)

Note the motion regions where MVDegrain3 folds its arms & says "no, here I do nothing".
(That's more interesting than discussing how to simulate MVDgr7 with MVDgr1.)

I've recently started to notice this too sadly. :(
So I was thinking that if we could use mvdegrain like any other filter that can be improved by motion analysis, then maybe this bug in mvdegrain would be no more.

I could be totally out of the loop here though, but I think it may be worth a try. :D

[Sagekilla]

Note: This is completely nothing like what you said, but at least we have a standalone MVDegrain to work with.

Alright, I've made a very simple MVDegraining script that lets you just stick it into your script without fiddling around. I didn't include MVDegrain3 because it's not public yet, and the scripted MVDegrain3 doesn't do much. If there's enough demand, I'll include it. Default settings work very well and use MVDegrain1.

#######################################################
# Easy MVDegrain by Sagekilla (Jan 13, 2008) #
# #
# Description of functions #
# method = MVDegrain with 1 or 2 vectors #
# thSAD = MVDegrain thSAD #
# limit = MVAnalyse limit #
# blksize = MVAnalyse block size #
# pel = MVAnalyse Subpixel accuracy #
# overlap = MVAnalyse block overlap #
# quality = Not working yet! #
#######################################################

function MVDegrain ( clip input, int "method", int "thSAD", int "blksize", int "pel", int "overlap")
{
o = input
method = default( method, 1 )
thSAD = default( thSAD, 400 )
blksize = default (blksize, 8 )
pel = default( pel, 2 )
overlap = default( overlap, 2 )

# Motion vector search
b2vec = (method==2) ?
\ o.MVAnalyse(isb=true, delta=2,pel=pel,overlap=overlap,blksize=blksize,idx=1) : BlankClip
b1vec = o.MVAnalyse(isb=true, delta=1,pel=pel,overlap=overlap,blksize=blksize,idx=1)
f1vec = o.MVAnalyse(isb=false,delta=1,pel=pel,overlap=overlap,blksize=blksize,idx=1)
f2vec = (method==2) ?
\ o.MVAnalyse(isb=false,delta=2,pel=pel,overlap=overlap,blksize=blksize,idx=1) : Blankclip


# Now we perform the actual MVDegrain.
output = (method==2) ? o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=thSAD,idx=2) :
\ o.MVDegrain1(b1vec,f1vec,thSAD=thSAD,idx=2)

return(output)
}

That should work... Report any bugs to me ASAP.

[Didée]

MVDegrain is a complex function, involving the base clip, motion vectors obtained by a motion search, and a SAD mask calculated from compairing [compensate(base,vectors)] with [base].

Now, how should a "standalone" version of MVDegrain look like? I don't see it ... trying to pull MVDegrain into small pieces, you'll get more or less what TTempSmooth already *is*.


BTW, the fact that MVDegrain sometimes "does nothing" in certain areas is not a bug in any way. It's by design. If all compensated blocks have a high SAD, then the weights for the compensated blocks are reduced to zero, the pixels of the original block get 100% weight, which results in "no change". That's how MVDegrain works.

What I showed with Scripted_MVDegrain (in the out-commented lines) was an alternative way of operation: Pre-calculate an "alternatively filtered" clip, and instead of just reducing weights for increasing SAD, assign weight to the alternative clip instead.
Then again, this has rather little to do with the idea of a "standalone" MVDegrain filter.

[Fizick]

1. Where is original quoted post by Didée? (link)
2. MVDegrain coud be function like PixieDust, but Avisynth is scripting language, not "one button" program.
Of course, anybody is free to take MVTools source code and create anything from it, even MVDegrain.exe (under GPL) :)

[Terranigma]

1. Where is original quoted post by Didée? (link)

The original post can be found here (http://forum.doom9.org/showthread.php?p=1078576#post1078576).

[Didée]

... and the script is in this post (http://forum.doom9.org/showthread.php?p=1077950#post1077950). (The "alternative clip weighting" is commented out, though.)

[Zep]

Hello, I was wonderin' if MVDegrain would function properly if it was a lone filter like ttempsmooth,

Sadly ttempsmooth barfs as well many times. I did 300 all 3 ways Didee posted

his first script of course then his scripted version both using ttempsmooth way and the alt way. alt way just is not good at all. too soft and detail lost too much. The other 2 ways flip a coin. They both did some things better and other things worse. I think Didee should try to do a version that does not use MV at all which is what I am experimenting with right now.

[Zep]

BTW, the fact that MVDegrain sometimes "does nothing" in certain areas is not a bug in any way. It's by design. If all compensated blocks have a high SAD, then the weights for the compensated blocks are reduced to zero, the pixels of the original block get 100% weight, which results in "no change". That's how MVDegrain works.



is there a way to know when those blocks get 100% weight and MVDegrain "does nothing" so we can take action to compensate?

[Terranigma]

is there a way to know when those blocks get 100% weight and MVDegrain "does nothing" so we can take action to compensate?

I don't think that's possible, but if it is, i'd like to know as well. :D