MC noise removal script

[Infrid]

right, it's my fault, sorry

from the README
unfilter: Ver 0.0.1.5 Unfilter

[McCauley]

Hi Spuds,

i tried getting the 0.8b version from the wiki, but when i go back to march 28 the link to the avs still points to the latest revision.
I think understand what is causing the (over-)saturation, the denoising seems to replace noise pixels with pixels of the same colour of their neighbours, so the overall saturation increases, because the "grey" noise is removed and the whole area becomes more intense in his colours. I don't know if this description is an accurate one to describe the phenomenon.
I'll make some screens and will send you a sample in a few days.
I have no idea to counter that, everything i have in mind will slow down the script more.

As we're talking of slowing the script, i have some ideas to improve the computed output. :)
Since this script is oftne used to restore old movies we have to fight the jitter that i caused by loose reels during the film scanning process, this messes up the motion vector search and will worsen the noise removal.
You maybe want have a look at this (http://forum.doom9.org/showpost.php?p=1114432&postcount=2) post from g-force, it helped me to stablize my source very effieciently.

Another thing is the deblocking.
Since we already computed a motion and a static mask,why not use stronger deblocking for the motion mask? Areas with motion tend to be blockier than areas with low motion (guess why :) )
Maybe a third "high" motion mask for the stronger deblocking would be appropiate?!

As always looking for forward what you will come up with. :-)

Regards
McCauley

[talen9]

Hi Spuds,

i tried getting the 0.8b version from the wiki, but when i go back to march 28 the link to the avs still points to the latest revision.

Ahem ... http://avisynth.org/mediawiki/upload/archive/2/20/20080318015002%21MC_Spuds.avs ;)

You just have to click on the link marked "15:15, 28 February 2008" in the wiki page linked in the previous post from Spuds :)

[Spuds]

@Infrid Looks like you got your answer on the unfilter error. A couple of comments on your script. First using setmtmode(4) before mc_spuds is sure to slow it down, use setmtmode(2) instead. Also I'd recommend doing a bob on the script vs the even/odd processing you have ... I'd do something like

SetMTMode(2)
import("mc_spuds.avs")
SetMTMode(5)
Avisource("L:\primi_dinosauri.avi")
ConvertToYV12(interlaced=true)
ChromaShift(C=2, L=-2)
SetMTMode(2)
Assume?ff # set to tff or bff depending on what you have
bob()
mc_spuds(frames=2,strength=4)
Assume?ff() #set the fieldorder again (must be the SAME as above!)
separatefields().selectevery(4,0,3).weave()

[2Bdecided]

bob(0.0, 1.0) can be better than bob()

IIRC there is no requirement for the second assume?ff to match the first - you can happily swap the field order at this point if you want to. However, the quality will be reduced, since all the "kept" lines will be interpolated, unless you use a better bobber (e.g. mcbob) - in which case it's a perfectly OK thing to do (if you want to!).

Unless I've misunderstood?

Cheers,
David.

[McCauley]

Ahem ... http://avisynth.org/mediawiki/upload/archive/2/20/20080318015002%21MC_Spuds.avs ;)
Shame on me...:rolleyes:

Regards
McCauley

[Infrid]

thanks spuds, but i lose detail with your script, download this file and look yourself.

http://mihd.net/jpncdg6
file list:
[sample_original.avi] the original video with noise
[sample_denoised.avi] noise removed, strength=3 *
[spuds_script.avi] processed with your script (bob), strength=3

i'd like to keep an interlaced video without a deinterlacing process (like bob), because i want to keep the maximum detail as possible.

i will not use MT anymore, after 9 hours of encoding there are some nice green frames and withe noise in the aiudio track... :D

used ChromaShift(C= 4, V=-2, L=-2, U=-2 ) and FixChromaBleeding()

[Spuds]

@2Bdecided
I'll probably get the wording wrong here but after something runs through bob avisynth resets the parity flag. So if you did a assumetff.bob.info it would say bottom field video.

After bobbing its progressive so the parity is irrelevant so the flag is reset (my guess). Bob is not the only deinterlacer that will do this, so do some don't. In this case, especially with dumb bob, we want the original lines and not the reconstructed lines, hence the need to state it again (well for a tff video).

@Infrid
I'm a bit surprised by this result. Bob is a relatively dumb filter, using it only creates a double frame rate, very fluid video to denoise.

After denoising we reconstructed the interlaced video with the original and now denoised data and discarded the bob data. As the above discusses you must set and reset the correct field order, in your case its tff (based on the video you uploaded), if you get it wrong you could get the bob data and thats not what you want.

If you already did all this correctly then choose what your eyes like, in the end thats whats most important.

[2Bdecided]

@2Bdecided
I'll probably get the wording wrong here but after something runs through bob avisynth resets the parity flag. So if you did a assumetff.bob.info it would say bottom field video.

After bobbing its progressive so the parity is irrelevant so the flag is reset (my guess). Bob is not the only deinterlacer that will do this, so do some don't. In this case, especially with dumb bob, we want the original lines and not the reconstructed lines, hence the need to state it again (well for a tff video).Yes, I know - I didn't disagree with you in my previous post. I was just pointing out that if you want to swap parity, here is a place you can do it, if the bob is a good one. Otherwise, of course not (like I said).

btw, I don't think I've ever said thank you for pulling together such a great script - thank you!

Cheers,
David.

[Spuds]

@David,

I figured you knew that, looking back I just misread your post a bit, thought it was stating a no need for the second vs what it really says of no need for it to match. Doh!
-----------------

I have made some updates to ver 0.9d, consider this a beta and as so its only on the link in post number 2 and not released to the wiki just yet.

The changes in this update are as follows:

Fixed error in the debug output, it was cropping the top line
Improved the overall output of the parameters debug view (debug=1). Many more are now listed.
Moved the location of the colorbleed function to post mv-denoise vs pre mv-denoise
Added parameters to allow setting of additional mvanalyse options, including truemotion (bool), lamda (int), lsad (int), plevel (0,1) and mvglobal (bool)
Added fs1,fs2,fs3,fs4 parameters so tweakers can pass sigma values to the flow function instead of using the scripts values. For flow and frames>2 only fs1 is required.
Increased search radius of contra-sharp for higher strength settings.
Added new prefast option to speed up processing, prefast=true/false. This is a alternative faster function to clean the video for motion vector searches. Not as robust but adequate for many sources. (beta)
Changed edgeclean function from using fft3dfilter to hqdn3d, uses same mask. (beta) This increases speed but may not be as effective.


I'm considering making the prefast=true the default for strength values 0,1,2 and maybe 3. The edge cleaning is a test, the current function worked well but speed increases could be found with other functions hence the beta test.

[Vesi]

http://img329.imageshack.us/img329/8205/53271555gx2.png (http://imageshack.us)

I'm getting color problems with latest Script
mc_spuds(frames=2,strength=1)

Edit: And I found that, the problem exist in beta V with .9 everything is ok

[Spuds]

@vesi

Was this the version on the wiki or the version from the link in post number 2 (the beta).
If the beta what is the date in the script header? There was a version that had the color processing wrong, although with the call you made you should not have seen that.
If its the version from the wiki make sure you did not get repairsse# installed, only use repair.
If none of the above then you know the drill, the script and short clip with the error please.

Thanks!

[Vesi]

version from the post number 2. And I use repair.
Date 26.04.08 14:34

Edit: I will send you the sample along with script and test result soon by pm.

[Spuds]

@Vesi

I updated the file in post number 2, this should take care of the color issue you were seeing. The defect was interesting, it was basically a few color blocks from forward looking frames coming through into the current frame, occurring 1-2 frames ahead of a scene change.

Frankly I was cheating things a bit and using luma motion vectors on all the planes for mvdenoise (speed but not really proper) and this tripped up the scene change detection. I could eliminate your example by lowering thscd2 to 90 but in the end decided to change the processing to be chroma proper.

Give the new script a try and let me know what you think.

[Vesi]

Everything is fine now Spuds. And thanks for updating the script.

[Avenger007]

First, let me say thanks a lot for an impressive noise removal script. :)

Second, an observation about debug view...
In function pre_filter, bt and ov are:
bt = (premax && frames > 1) ? 3 : (premax) ? 3 : (strength < 5) ? select(frames , 1 , 1 , 1 , 2 , 2) : select(frames , 1 ,1 , 2 , 2 , 3)
ov = (premax) ? 8 : select(strength , 2 , 4 , 4 , 4 , 8 , 8 , 8)
But in function debug_view, bt and ov are redefined:
bt = (premax && frames > 1) ? 5 : (premax) ? 3 : (strength < 4) ? select(frames , 0 , 1 , 2 , 3 , 3) : select(frames , 0 ,2 , 3 , 4 , 5)
ov = (premax) ? 8 : select(strength , 2 , 4 , 4 , 4 , 8 , 8 , 8)
So when I experimented with bt and ov (like bt=3, ov=8) in pre_filter, the debug view list remained the same. It's no big deal really, I just thought I would point it out. ;)

Third, is dering_clp still being tested?
Is there an updated version for it or for the MC_Spuds script in general?

:thanks: again for a great script.

[Spuds]

Second, an observation about debug view...
In function pre_filter, bt and ov are:

Good catch! ... The way I'm doing that in debug_view was just lazy on my part, bt and ov should be passed in the functions or made global but not defined twice ... but when it came to the debug view function I was kind of lazy :)


is dering_clp still being tested Yes and no ... overall I'm satisfied with the processing in the last beta (post #2 and I think its the same as the last official on the wiki but would have to double check) and I'm satisfied with the edge mask creation. In the script you some of the ways I've worked on the edges, but like everything its a speed, effectiveness, detail retention tradeoff.

All of those deringing noise functions are applied via an edge mask which is just as important as the denoising function itself. You will get more deringing by changing the edm_lo and edm_hi values (use debug views to see how those add or removed edges to the mask).

All that said I'm always looking for and trying new things.

[Dreassica]

Using starfield = true in 0.9d results in an: The named argument "threshhold' to mt_binarize had the wrong type, line 104 and line 524 in mcspuds avs.

[Spuds]

Dreassica .. thanks for the bug report in 0.9d, looks like you had starfield and anime set to true. I placed a new beta version at the link in post#2, its still 0.9d but now has todays date in the header.

When using starfield remember to do some tunning of the thstar and lumathres values.

lumathres will allow more spots to be considered in the mask, lower includes more spots (don't go below 130). Its basically the luma value of the stars in question, if they are all very bright increase the value to avoid false hits.

thstar will look at the mask that is created with the lumathres value and decide if there are enough spots that what we have is indeed a starfield and not just a few spots or dots that are really noise.

use debug=9 to see the starmask to help in tunning. I have used starmask to retain stars, bubbles, plankton, and lots of other swarming fields in video that would have normally been removed or diminished by tunning the values.

[hartford]

You should add something like this to your doc:

# requires: addgrain v1.4
# awarpsharp
# despot v3.4.1
# dfttest v1.1
# fft3dfilter v2.1.1
# hqdn3d v0.11
# mt_masktools v2.0.32
# mvtools v1.9.2
# removedirt v0.9
# removegrain v1.0
# removegrainT v1.0
# Repair v1.0.dll
# undot v0.0.1.1
# unfilter v0.0.1.5
# warpsharp 03Nov03.dll

# Scripts:
#
# deblock_qed.avs
# LimitedSharpenFaster.avs



Xsharpen is in the old warpsharp as dated above.
Clense is in the latest RemoveGrainT from Kassandro

<a href="http://home.arcor.de/kassandro/prerelease/RemoveGrainT-1.0.rar
">RemovegrainT</a>

<a href="http://avisynth.org/warpenterprises/files/warpsharppackage_25_dll_20031103.zip">Old Warpsharp</a>

[McCauley]

Hi Spuds,

sorry, i forgot to give an update to my last post. The saturation thingy was caused by another function i really didn't take
into account (and i still don't understand why it does it...).

May i make a few suggestions again? :D

How about implementing MVDegrain4/5/6 (http://forum.doom9.org/showthread.php?p=1141506#post1141506)?

While you're at it you could implement , as far as i understand it, the speed impact should be almost zero with everything already
computed. MoComp'ed ContraSharpening (http://forum.doom9.org/showthread.php?p=1104251#post1104251)

Since this script should be used most of the time to denoise/degrain older movies, why not integrate a real scratch removal function? It already does a
decent job on scratch removal, but i want it to be better. :devil:

How about offering support for fft3dGPU like in UDegrain (http://forum.doom9.org/showthread.php?t=139766)?

Another cosmetic change i want to suggest would be to change prefilter,prefast and premax to a single prefilter call with integer values:
0 off
1 prefast
2 strength based
3 premax
That would make the usage a bit prettier IMHO.


Looking forward to further development of your outstanding script.

Regards
McCauley

[45tripp]

While you're at it you could implement , as far as i understand it, the speed impact should be almost zero with everything already
computed. MoComp'ed ContraSharpening (http://forum.doom9.org/showthread.php?p=1104251#post1104251)

+1


How about offering support for fft3dGPU like in UDegrain (http://forum.doom9.org/showthread.php?t=139766)?


+1


ty
tripp

[Spuds]

Had a bit of free time so decided to play around a bit and add some of the features based on the latest suggestions. The latest 1.0 Beta is available in the link (http://www.rcboataholic.com/MC_Spuds.zip) in post number 2. Consider it a test version to check things out and let me know if there are any problems.

The changes are:
1. Added mvdegrain4 capability for frames=4. Could have added more but since there are also with temporal and aggressive processing options the script has enough noise removal power.

2. Added gpu=true which will utilize fft3dgpu in place of fft3dfilter throughout the script.

3. Added prefilter = 0-4, 0-none, 1-fast, 2-strength based, 3-max. The old premax, prefast, etc also are still available.

4. Added third sharpening option, contra with MC determined limits. Use via sharpp=3 (0=none, 1=contra, 2=limitedsharpenfaster, 3=MC contra). Have not had enough time to fully test this so give it a try and let me know how you like the results.

5. Fixed / added some debug information in the debug=1 screen

[elguaxo]

thanks!

[McCauley]

Awesome!
Thank you very much!

Regards
McCauley

[Lux Delux]

Wooo your effort is greatly appreciated! This scripty does wonders on Chuck Norris :D

[Lux Delux]

Hmmm I just noticed sharpp=3 introduces 2px white borders around my image. Any ideas? :eek:

EDIT: actually it seems it appears with removeblocks=true. Even with sharpp=1 I got the lines but then they were sort of grayish. Removing removeblocks made it dissapear with sharpp=1 but the problem is still there it seems with 3.

[g-force]

Spuds,

your MCcontra routine is totally hosed. You're applying the clamp to the difference signal, it should be applied to the un-differenced end result.

something like:

pshrp = last
pmax = source.MT_Logic(bw1,"max").MT_Logic(fw1,"max")
pmin = source.MT_Logic(bw1,"min").MT_Logic(fw1,"min")
rg11d = MT_MakeDiff(pshrp,pshrp.RemoveGrain(12,-1))
MT_MakeDiff(pshrp,pshrp.RemoveGrain(4,-1))
MT_LUTxy(rg11d,last,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?")
MT_MakeDiff(pshrp,last)
MT_MakeDiff(last,last.RemoveGrain(12,-1))
MT_LUTxy(pshrp,last,"y 128 - 1.5 * x +",chroma="copy first")
MT_Clamp(last,pmax,pmin,1,1,chroma="copy first") #or better yet, have a variable overshoot amount

-G

[Didée]

Yeah, the "MCsharpening()" routine is a bit off. Clamping the diff instead of the result, as g-force already found ... one or two mt_LutXY not making much sense ... oh, and a closing parenthesis at the wrong place, which in effect reduces the sharpening strength for strength >=4, where it should increase. Indeed, just a little bit broken. ;)

Corrected version:

FUNCTION MCSharpening(clip denoised, clip original, int frames, int strength, bool flow, int thsad)
{
# apply sharpening to the denoised clip
# sharp = yv12lutxy( denoised, denoised.minblur(1,1).removegrain(11,-1), "x y = x x x y - abs 16.25 / 0.25 ^ 16.25 * 1.5 * x y - 2 ^ x y - 2 ^ 4.5 + / * x y - x y - abs / * 1 x y - abs 20 / 4 ^ + / + ?",U=2,V=2)
s = denoised.minblur(1,1) # Damp down remaining spots of the denoised clip.

# The difference of a simple kernel blur. Use a larger radius for stronger strength values
ssD = (strength < 4) ? mt_makediff(s,s.removegrain(11,-1)) \
: mt_makediff(s,s.removegrain(11,-1).removegrain(20,-1))

# determine our clamping limits based of our original clip and a simple MVcompensate
global idx_pointer = (flow) ? idx_pointer : idx_pointer + 1
comp_bw1 = (flow) ? sv_cb1 : original.MVCompensate(sv_b1,thsad=thsad,idx=idx_pointer)
comp_fw1 = (flow) ? sv_cf1 : original.MVCompensate(sv_f1,thsad=thsad,idx=idx_pointer)
pmax = original.mt_logic(comp_bw1,"max").mt_logic(comp_fw1,"max")
pmin = original.mt_logic(comp_bw1,"min").mt_logic(comp_fw1,"min")

denoised.mt_adddiff(ssD,U=2,V=2) # Apply the blur difference. (Sharpening is just inverse blurring.)
last.mt_clamp(pmax,pmin,0,0,U=2,V=2) # limit the sharpened clip to not exceed the original temporal neighborhood

RETURN (last)
}

[Lux Delux]

Great, no more problems with sharpp=3 now :)

And I like it btw, I'm starting to use mcspuds as a all in one denoiser/sharpener/deblocker :D

[Seraphic-]

Wanted to try this out, but I'm having a problem as it keeps crashing VirtualDub.
Could anyone show me what is wrong with my code?
To be clear, my source isn't Anime, but 3D rendered graphics.

On a side note, could this be used to denoise, sharpen and/or smooth along with helping with anti-aliasing to remove jagged edges?

AviSource("C:\Documents and Settings\Desktop\test.avi")
ConvertToYV12()

import("C:\Documents and Settings\Desktop\AVISynth\Filters\avs\mc_spuds.avs")
import("C:\Documents and Settings\Desktop\AVISynth\Filters\avs\LimitedSharpenFaster.avs")
import("C:\Documents and Settings\Desktop\AVISynth\Filters\avs\FastLineDarken_1.3.avs")

LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\mt_masktools-26.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\RemoveGrainSSE3.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\deblock.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\FFT3DFilter.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\mvtools.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\RemoveDirtSSE2.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\TTempSmooth.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\hqdn3d.dll")
LoadPlugin("C:\Documents and Settings\Desktop\AVISynth\Filters\dll\RepairSSE3.dll")

mc_spuds(frames=2,strength=4)
ttempsmooth()
fastlinedarkenmod(thinning=0, strength=25)
limitedsharpenfaster(ss_x=1.0, ss_y=1.0, smode=4, strength=20)

[McCauley]

Hey Spuds,

maybe worth a try?
MC'ed Soothe (http://forum.doom9.org/showthread.php?p=1166238#post1166238).

What do you say to MV based scratch removal?

Regards
McCauley

[Lux Delux]

@Seraphic, what Mvtools version you have? I know it crashed my vdub also when I had the new multi-threaded build. With the older one it worked fine.

[talen9]

@Seraphic, avoid using *SSE3 version of Kassandro's plugins: their presence in autoload folders or in explicit "LoadPlugin()" instructions has been proved in the past to be a source of crashes/problems .... use the *SSE2 versions (they're almost as fast), delete the *SSE3 from your system and try again ;)

[Didée]

maybe worth a try?
MC'ed Soothe (http://forum.doom9.org/showthread.php?p=1166238#post1166238).
Generally, not a bad idea. ;)
However: Within a script that does MC noise reduction, doing an explicit MC-Soothe either adds unnecessary processing overhead, and/or is suboptimally efficient. Within an MC'ed noise reduction script, I prefer to do that step inherently :

http://img181.imageshack.us/img181/4940/prob2piccd1.th.jpg (http://img181.imageshack.us/my.php?image=prob2piccd1.jpg) http://img440.imageshack.us/img440/3530/prob1picww0.th.jpg (http://img440.imageshack.us/my.php?image=prob1picww0.jpg)

http://img261.imageshack.us/img261/7952/ok2picnm3.th.jpg (http://img261.imageshack.us/my.php?image=ok2picnm3.jpg) http://img181.imageshack.us/img181/8733/ok1picaj4.th.jpg (http://img181.imageshack.us/my.php?image=ok1picaj4.jpg)

http://img181.imageshack.us/img181/716/hmm02picpi7.th.jpg (http://img181.imageshack.us/my.php?image=hmm02picpi7.jpg) http://img410.imageshack.us/img410/2915/hmm01picvi8.th.jpg (http://img410.imageshack.us/my.php?image=hmm01picvi8.jpg)

Just re-mixing the same old methods over and over again is a bit of yawn. We've like twenty different MC denoisers, and ALL of them have to make the same decision of compromise at some certain points. Above, MC_spuds is just a random example. Exchange it with TemporalDegrain, GTDegrain, "Ultimate"Degrain, or whatever ... the result looks more or less the same.

The old vegetable soup tastes vapid by now. Time to use new spicery.

[Boulder]

The old vegetable soup tastes vapid by now. Time to use new spicery.Chef Didée, would you like to show us the spice you apparently discovered on your vacation? :D

[Nikos]

Thanks Didie for the MC'ed Soothe. Here (http://forum.doom9.org/showpost.php?p=992576&postcount=446) is one of your old post about soothe:

In "standalone" Soothe, in a temporally mood I had decided to make the parameter "keep", i.e. how much of the original sharpening to keep at least. Hence, 0=maximum soothing (no minimum sharpening to keep), 100=minimum soothing (keep all sharpening).

When building SeeSaw, I found it's a bit unintuitive this way, and reversed the meaning to "strength-of-soothing". Hence, in SeeSaw, sootheT=0 means minimum soothing (do no soothing, keep all sharpening), sootheT=100 means maximum soothing (no minimum sharpening to keep).

The meaning of "reduc" in the MC'ed Soothe is the same as "keep" in standalone soothe function or the opposite as the SeeSaw internal sootheT?

I want to be sure :D

[Didée]

No, "reduc" and "keep" are not the same. Old Soothe() does not even ask for "reduc", it silently uses reduc=1.0. Then it uses the quoted procedure on top of that.
These both versions of soothing really are facing pretty different conditions. Old Soothe is completely un-aware of motion, hence it is tweaked to behave reasonably no matter whether there is motion or not. OTOH, for the shown MC-soothing something like "motion" doesn't exist, it is living in a static no-motion world [created by MVDegrain, which also takes care of most possible errors]. Therefore no need for a "keep" constraint.


@ Boulder: Application for admission has been filed, but you know, sometimes it takes years until the FDA approves. Especially in case of suspicious spice, they're paranoid about possible spillovers.

[Seraphic-]

Alright have the script loading at least, but there is quite a bit of delay when seeking other parts of the video, even for my system.

@Seraphic, what Mvtools version you have? I know it crashed my vdub also when I had the new multi-threaded build. With the older one it worked fine.

I was using mvtools V1.9.6.0_6, but changing to mvtools-v1.9.5.7 and it seems to work now.

@Seraphic, avoid using *SSE3 version of Kassandro's plugins: their presence in autoload folders or in explicit "LoadPlugin()" instructions has been proved in the past to be a source of crashes/problems .... use the *SSE2 versions (they're almost as fast), delete the *SSE3 from your system and try again ;)

Went to SSE2 versions when I changed to the older mvtool version. After it loaded without crash, I tried the two SSE3s again and it still worked.

[Nikos]

Thanks Didie, for explanation that "reduc" and "keep" are not the same.
Now the question is:
Big "reduc" number mean that we will have big reduction in sharpening effect or the opposite?
or in simple words what's the meaning of "reduc"?

[Boulder]

OT: The SSE3 problems with the RemoveGrain plugin might be fixed with this version: http://home.arcor.de/kassandro/prerelease/RemoveGrain-1.0.rar

[Spuds]

Thanks for finding and providing some fixes for the error. I updated the script and its available at the same old link as always.

@Didée .. do you have a link to those source samples so others can play? ;)

[Adub]

Thanks for the link Boulder! That version fixes a few issues that I myself was having with removegrainsse3. I'll update the avisynth wiki to point to this release.

[Didée]

do you have a link to those source samples so others can play? ;)
Here you go. Five snipplets (total 82MB) from the original footage, with plenty of problems for grain removal filters:

(DL from MediaFire) (http://www.mediafire.com/download.php?x0wlihyfyse) / (DL from MegaUpload) (http://www.megaupload.com/?d=INSIH6AK)

Goal is to get the strong-grained static sections really calm, but to not seriously harm faint textures in the moving parts.

I'm mostly aiming at a basic problem, and at pre-filtering.
OTOH: If a too weak pre-filter leaves leftover flicker behind, then the ME tends to follow the flicker, leading to flicker in the end result.
OTOH: If a too coarse pre-filter removes too much of faint-but-important texture in motion parts, then there's not enough left over to make the ME follow that motion, which leads to also loosing that texture in the end result.

So, using pre-filtering does not solve a problem, it mostly just relocates it. A different method of making decisions is what is needed.

[Nikos]

Spuds this is your MCSharpening function:

FUNCTION MCSharpening(clip denoised, clip original, int frames, int strength, bool flow, int thsad)
{
# apply sharpening to the denoised clip
s = denoised.minblur(1,1) # Damp down remaining spots of the denoised clip.

# The difference of a simple kernel blur. Use a larger radius for stronger strength values
ssD = (strength < 4) ? mt_makediff(s,s.removegrain(11,-1)) \
: mt_makediff(s,s.removegrain(11,-1).removegrain(20,-1))

# determine our clamping limits based of our original clip and a simple MVcompensate
global idx_pointer = (flow) ? idx_pointer : idx_pointer + 1
comp_bw1 = (flow) ? sv_cb1 : original.MVCompensate(sv_b1,thsad=thsad,idx=idx_pointer)
comp_fw1 = (flow) ? sv_cf1 : original.MVCompensate(sv_f1,thsad=thsad,idx=idx_pointer)
pmax = original.mt_logic(comp_bw1,"max").mt_logic(comp_fw1,"max")
pmin = original.mt_logic(comp_bw1,"min").mt_logic(comp_fw1,"min")

denoised.mt_adddiff(ssD,U=2,V=2) # Apply the blur difference. (Sharpening is just inverse blurring.)
last.mt_clamp(pmax,pmin,0,0,U=2,V=2) # limit the sharpened clip to not exceed the original temporal neighborhood

RETURN (last)
}

I think, this is better:

FUNCTION MCSharpening(clip denoised, clip original, int frames, int strength, bool flow, int thsad, int sharpen_strength)
{

# determine our clamping limits based of our original clip and a simple MVcompensate
global idx_pointer = (flow) ? idx_pointer : idx_pointer + 1
comp_bw1 = (flow) ? sv_cb1 : original.MVCompensate(sv_b1,thsad=thsad,idx=idx_pointer)
comp_fw1 = (flow) ? sv_cf1 : original.MVCompensate(sv_f1,thsad=thsad,idx=idx_pointer)
pmax = original.mt_logic(comp_bw1,"max").mt_logic(comp_fw1,"max")
pmin = original.mt_logic(comp_bw1,"min").mt_logic(comp_fw1,"min")

# non linear sharpener with variable strength, from Didie's LSF, smode=4
Str=string(float(sharpen_strength)/100.0)
mt_lutxy(denoised,denoised.RemoveGrain(11,-1),"x y == x x x y - abs 16 / 1 2 / ^ 16 * "+Str+
\ " * x y - 2 ^ x y - 2 ^ "+Str+" 100 * 25 / + / * x y - x y - abs / * + ?")

# limit the sharpened clip to not exceed the original temporal neighborhood
last.mt_clamp(pmax,pmin,0,0,U=2,V=2)

RETURN (last)
}

Didie if you wish, explain to us the meaning of "reduc" in the MC'ed Soothe. (Please!!!)

[Spuds]

@Didée .. thank you very much for the clips, they are great (or can be :) ) Do you think its worth exploring creating a basic motion mask and then applying a stronger prefilter to the static areas and weaker to the moving areas and then to use that merged prefiltered clip in the primary mvanalysis?

@Nikos .. I think that does look a bit nicer as well, need to do some more testing. Original I had explored several other sharpening techniques but was not happy with the results, of course I now now that's in part because I had applied the clamp incorrectly so I need to go back and play.

[Didée]

Do you think its worth exploring creating a basic motion mask and then applying a stronger prefilter to the static areas and weaker to the moving areas and then to use that merged prefiltered clip in the primary mvanalysis?
Exploring is always good. Try and tell. :)

(When being out in a nutshell on stormy seas, it might become difficult to travel on a straight line ...)


@Nikos:
The sharpen-differences of several frames are temporalsoften'ed together. Then:
"reduc=0.0" -> take that average as-is. (a pixel's sharp-diff can be either decreased or increased by soothing)
"reduc=1.0" -> the average may only decrease a pixel's sharp-diff, not increase it. (a pixel can only get less sharpening by soothing, never more).

[Nikos]

Thanks Didie for the explanation!!!
From my understanding, with reduc=0.4:
if abs original sharpen diff. <abs MC'ed sharpen diff. then we apply a mix 40% of original sharpen diff. and 60% of MC'ed sharpen diff. else we apply 100% of MC'ed sharpen diff.

In simple words, the result with reduc<1 is unknown unlike normal soothe where we only get less sharpening.

It's so simple :D

[Spuds]

I've made some changes to the script, its available here (http://www.rcboataholic.com/MC_Spuds_mvt.zip)

There are a few important updates in this test version.

First is that it has been changed to run with the version of mvtools that josey_wells created, so the function is now called mc_spuds_mvt. It will not run with the last official version of mv_tools, you need the 1.9.6.1+ branch

Second is that I added motion masking to the prefilter phase. This has the effect of better retaining details in the high motion areas that were normally heavily tamped down during the preprocess. Probably needs some more tweaking but its good enough now to get some feedback on.

Third is to make it a bit easier to use for the non tweakers I added several mode options mc_spuds_mvt(mode="medium") for example, this sets processing options suitable for that mode of noise removal. The modes are "very low", "low", "medium", "high", "very high", "anime low", "anime high". You can use that and then override with any of the myriad of options :)

Last I found an error with temporal=true with certain options enabled, thats been fixed.

I have not folded the last three items back into mc_spuds, I'll do that sometime over the next few days and post that update as well.

[Ranguvar]

Excellent update, Spuds! This is becoming an easy to use do-it-all cleanup kit, which is fantastic when I don't have the time to fine-tune everything for my source =] Keep up the great work.