MVTools-pfmod

[GMJCZP]

Thank you. Now I face this:

What if I use lsb = false? Is the cleaning quality maintained? This would no longer require Crop.

Edit: or just try your alternative.

[GMJCZP]

Subjectively speaking, as to the quality of the image, you're right, it's best to call DitherPost first.

Everything looks like this:

Dither_convert_8_to_16()
Temporalsoften(2,1,2,mode=2,scenechange=10)
dither_resize16(720,480,kernel="spline16",invks=true,invkstaps=3,src_left=0.0,u=3,v=3)
MDegrainLight(2,lsb=true,thSAD=200)
f3kdb(range=15, grainY=0, grainC=0, keep_tv_range=True, input_depth=16, output_depth=8)

# MDegrainLight
# https://forum.doom9.org/showthread.php?p=1810543#post1810543
# Original idea by hello_hello

function MDegrainLight(clip input, int "tr", bool "mt", bool "lsb", int "thSAD", int "thSAD2", int "blksize", int "overlap")
{
tr = Default(tr, 1) # Temporal radius
mt = Default(mt, true) # Internal multithreading
lsb = Default(lsb, false) # 16-bit
thSAD = Default(thSAD, 200) # Denoising strength
thSAD2 = Default(thSAD2, 150)
blksize = Default(blksize, 16) # Block size
overlap = Default(overlap, 4) # Block overlap

input = (lsb == true ) ? input.DitherPost() : input

super = input.MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
input.MDegrainN (super, multi_vec, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=thSAD2)
return last
}

I wonder if it is not better to use DitherPost (mode = - 1), since f3kdb, so I understand, is already doing Dithering.

However, if there is something better it would be good to know.

Edit: I tried DitherPost (mode = -1) and it looks microscopically better, this makes me think that it is better to put DitherPost (mode = -1) .MDeGrainLight (). F3kdb. If there is no f3kdb then maybe it would be nice to put DitherPost (mode = 0) .MDeGrainLight ().
In any case it would be better not to put it inside the DitherPost function, unless within the function define a new variable that takes this into account.

[blaze077]

There is another method which would avoid any sort of dithering down. While MVTools does not support stacked input, it does support native high bit depth.
You could convert the stacked format to native bit depth (no data loss), degrain the native 16 bit video using MDegrainN and then convert the native 16 bit video back to 16 bit stacked.
This might be slower but it would be much better.

Like so:

function MDegrainLight(clip input, int "tr", bool "mt", bool "lsb", int "thSAD", int "thSAD2", int "blksize", int "overlap")
{
    tr = Default(tr, 1) # Temporal radius
    mt = Default(mt, true) # Internal multithreading
    lsb = Default(lsb, false) # 16-bit
    thSAD = Default(thSAD, 200) # Denoising strength
    thSAD2 = Default(thSAD2, 150)
    blksize = Default(blksize, 16) # Block size
    overlap = Default(overlap, 4) # Block overlap

    input = lsb ? input.ConvertFromStacked() : input

    super = input.MSuper(mt=mt)
    multi_vec = MAnalyse(super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
    input.MDegrainN(super, multi_vec, tr, mt=mt, thSAD=thSAD, thSAD2=thSAD2)
    return lsb ? ConvertToStacked() : last
}

Note: You will need Avisynth+ (any release with working HBD support).

[GMJCZP]

Thanks again.
For now I do not use AVS+, but in the future I will take it into account. I think it is best to use DitherPost, either mode = -1 or mode = 0, outside of the function due to the presence of f3kbd, so IMO I have more flexibility.

Edit: Dithering Down (I'm no expert in understanding the term, sorry) would be mitigated with DitherPost (mode = -1) but the difference seems minimal with respect to DitherPost (mode = 0).

[GMJCZP]

Is it possible to use MCompensate together with MdegrainN? I can not do it.

[BakaProxy]

Originally Posted by GMJCZP

Is it possible to use MCompensate together with MdegrainN? I can not do it.

Technically yes, but I don't think there's much use to it since mdegrain is already kind of motion compensating.

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[StainlessS]

Originally Posted by GMJCZP

Is it possible to use MCompensate together with MdegrainN? I can not do it.

Not sure what you want here but I think that in using MDegrainN, you have already used MCompensate (in a round about way, ie prior to the degrain of MDegrainN, frames are MC compensated to predicted positions, and then degrained).
Not sure that repeating the experience will improve anything much.

EDIT: Beaten by BakaProxy.

[GMJCZP]

Thanks to both.
I suppose Mrecalculate can, right?

Edit: I could do it, lol.

[StainlessS]

Originally Posted by GMJCZP

Thanks to both.
I suppose Mrecalculate can, right?

Edit: I could do it, lol.

Not sure that you could, at least without another MAnalyse on the output of the degraining. You could perhaps do Mrecalculate if you broke it up into MAnalyse type funcs, and then Mrecalculate on each result, and then MDegrainX type func on result of all of that lot.

EDIT:
MDegrainN (which I have never knowingly used) is just a bunch of MAnalyse funcs, followed by a bunch of MDegrainX funcs,
to use MRecalculate, you would need to use that func (MreCalc) between MAnalyse and MDegrainX.

EDIT:

is just a bunch of MAnalyse funcs

Well sort of, equiv to lots of MAnalyse with lots of Delta offsets.

EDIT: Who said life was supposed to be easy ?

[GMJCZP]

Life is simpler than you think, TinMan:

# MDegrainLight
# https://forum.doom9.org/showthread.php?p=1813061#post1813061
# Original idea by detmek, hello_hello
# Adapted by GMJCZP
# Requirements: MVTools, Dither Tools (optional for lsb=true)

function MDegrainLight(clip input, int "tr", bool "mt", bool "lsb", int "thSAD", int "thSAD2", int "blksize", int "overlap")
{
tr = Default(tr, 1) # Temporal radius
mt = Default(mt, true) # Internal multithreading
lsb = Default(lsb, false) # 16-bit
thSAD = Default(thSAD, 200) # Denoising strength
thSAD2 = Default(thSAD2, 150)
blksize = Default(blksize, 16) # Block size
overlap = Default(overlap, 4) # Block overlap

# <Options for lsb=true>
#input = lsb ? input.DitherPost(mode=-1) : input # For AVS, AVS+ users
#input = lsb ? input.ConvertFromStacked() : input # For AVS+ only, more slow, suggestion of blaze077

super = input.MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
multi_vec_re = MRecalculate(super,multi_vec, tr=tr,blksize=4)
input.MDegrainN (super, multi_vec_re, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=thSAD2)
# return lsb ? ConvertToStacked() : last # For AVS+ only, more slow, suggestion of blaze077
return last
}

[StainlessS]

GMJCZP,

Well that Fizick, or whoever designed this stuff is well more clever than I gave credit for, thank you for the education, we need as much of that as we can get.

[GMJCZP]

I give you the whole reason, Fizick, cretindesalpes, pinterf are geniuses.

[GMJCZP]

@ pinterf:

I noticed that the parameter search = 5 (Umh) produces identical results as search = 4 (Hex). In x264 the results are different.

[burfadel]

Originally Posted by GMJCZP

Life is simpler than you think, TinMan:

# MDegrainLight
# https://forum.doom9.org/showthread.php?p=1813061#post1813061
# Original idea by hello_hello
# Adapted by GMJCZP
# Requirements: MVTools, Dither Tools (optional for lsb=true)

function MDegrainLight(clip input, int "tr", bool "mt", bool "lsb", int "thSAD", int "thSAD2", int "blksize", int "overlap")
{
tr = Default(tr, 1) # Temporal radius
mt = Default(mt, true) # Internal multithreading
lsb = Default(lsb, false) # 16-bit
thSAD = Default(thSAD, 200) # Denoising strength
thSAD2 = Default(thSAD2, 150)
blksize = Default(blksize, 16) # Block size
overlap = Default(overlap, 4) # Block overlap

# <Options for lsb=true>
#input = lsb ? input.DitherPost() : input # For AVS, AVS+ users
#input = lsb ? input.ConvertFromStacked() : input # For AVS+ only, more slow, suggestion of blaze077

super = input.MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
multi_vec_re = MRecalculate(super,multi_vec, tr=tr,blksize=4)
input.MDegrainN (super, multi_vec_re, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=thSAD2)
# return lsb ? ConvertToStacked() : last # For AVS+ only, more slow, suggestion of blaze077
return last
}

I have found that processing chroma and luma separately produces nicer results in regards to mdegrain. I came up with the following script based on existing Mdegrain concept, in conjuction with a luma mask I borrowed from the linked post. The luma mask is beneficial in reducing motion artifacts.

In this script luma is handed by MVtools and chroma is handled by FFT3DFilter. FFT3DFilter seems more appropriate for chroma, and MVTools seems more appropriate for luma according to the results that each achieves. On a clip I tried it also was worked as a de-rainbow filter, although the effect is likely quite weak.

# MClean basic script
# Mask from bennynihon https://forum.doom9.org/showthread.php?p=1689444#post1689444
# Remaining script by burfadel altered from generic information
# Basics for this script is to remove grain whilst retaining as much information as possible
# The script should also be relatively fast, even without Masktools2 multithreading (disabled due to possible MT bug)
# Chroma is processed via a different method to luma for optimal results
# Requires RGTools, Modplus (Veed, for part of chroma filter), MVTools2, Masktools2, FFT3DFilter
 

function MClean(clip c, int "thSAD", int "blksize", int "blksizeV", int "overlap", int "cblksize", int "cblksizeV", int "cpu")
{
thSAD     = Default(thSAD, 350) # Denoising threshold
blksize   = Default(blksize, 16) # Horizontal block size for luma
blksizeV  = Default(blksizeV, blksize) # Vertical block size for luma, default same as horizontal
overlap   = Default(overlap, 8) # Block overlap
cblksize  = Default(cblksize, 32) # Horizontal block size for chroma
cblksizeV = Default(cblksizeV, cblksize) # Vertical block size for chroma, default same as horizontal
cpu       = Default(cpu, 4) # Threads for FFT3DFilter

coverlapH = (cblksize/2) # Overlap for horizontal chroma blocks, half blksize
coverlapV = (cblksizeV/2) # Overlap for vertical chroma blocks, half blksizeV


# Masks
LumaMask=mt_binarize(c, threshold=64, upper=true).greyscale().BilinearResize((c.width/16)*2, (c.height/16)*2).BilinearResize(c.width,c.height).mt_binarize(threshold=254)
EdgeMask=mt_edge(c, mode="prewitt",thy1=0,thy2=16).greyscale().mt_binarize(threshold=16, upper=true).BilinearResize((c.width/16)*2, (c.height/16)*2).BilinearResize(c.width,c.height).mt_binarize(threshold=254)
GrainMask=mt_logic(LumaMask,EdgeMask,mode="and")
DegrainMask=GrainMask.mt_invert()

# Chroma filter
filt_chroma=fft3dfilter(veed(c), plane=3, bw=cblksize, bh=cblksizeV, ow=coverlapH, oh=coverlapV, bt=5, sharpen=0.6, ncpu=cpu, dehalo=0.2, sigma=2.35)

# Luma Filter
super = c.MSuper(rfilter=4, chroma=false,hpad=16, vpad=16)
bvec2 = MAnalyse(super, chroma=false, isb = true, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=5)
bvec1 = MAnalyse(super, chroma=false, isb = true, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=3)
fvec1 = MAnalyse(super, chroma=false, isb = false, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=3)
fvec2 = MAnalyse(super, chroma=false, isb = false, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=5)
Clean = c.MDegrain2(super, bvec1, fvec1, bvec2, fvec2, thSAD=thSAD, plane = 0)

#Luma mask merge
filt_luma = c.mt_merge(Clean, DegrainMask, U=1, V=1)

# Combining result of luma and chroma cleaning
output = mergechroma(filt_luma, filt_chroma)

return output
}

Yes, no doubt it could be improved, but it produces pretty good results. I guess from that you could add dither.

[MysteryX]

Hey, quick question. MvTools2 has performance and stability issues with MT, especially when using DCT=1. Does the VapourSynth version also have such issues or does it work smoothly there?

[blaze077]

It works perfectly even with DCT=1 for me. I've never encountered a problem with it (because of Vapoursynth's stable MT).

[hello_hello]

GMJCZP,
Thanks for the credit in your script, but I must confess the idea was not mine.
Im pretty sure I stole it from this post.
https://forum.doom9.org/showthread.p...55#post1583955

[GMJCZP]

Originally Posted by hello_hello

GMJCZP,
Thanks for the credit in your script, but I must confess the idea was not mine.
Im pretty sure I stole it from this post.
https://forum.doom9.org/showthread.p...55#post1583955

Thank you for your honesty. You have not stolen anything, just the circumstances.

I updated the script just to reflect this.

[MysteryX]

Does DCT=1 have the same issues with BlkSize=8 that doesn't use FFTW?

ColorBarsHD()
ConvertToYV12()
jm_fps()
Prefetch(8)

function jm_fps(clip source, float "fps")
{
	fps = default(fps, 60)
	fps_num = int(fps * 1000)
	fps_den = 1000
	
	prefiltered = RemoveGrain(source, 22)
	super = MSuper(source, hpad = 16, vpad = 16, levels = 1) # one level is enough for MRecalculate
	superfilt = MSuper(prefiltered, hpad = 16, vpad = 16) # all levels for MAnalyse
	backward = MAnalyse(superfilt, isb = true, blksize = 8, overlap = 4, search = 3, dct = 1)
	forward = MAnalyse(superfilt, isb = false, blksize = 8, overlap = 4, search = 3, dct = 1)
	forward_re = MRecalculate(super, forward, blksize = 4, overlap = 2, thSAD = 100)
	backward_re = MRecalculate(super, backward, blksize = 4, overlap = 2, thSAD = 100)
	out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)
	
	return out
}

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module:   C:\Windows\SysWOW64\KernelBase.dll
Address:  0x76C3A9F2

WOOPS!!

[VS_Fan]

Originally Posted by MysteryX

Does DCT=1 have the same issues with BlkSize=8 that doesn't use FFTW?

It looks like your problem is not related to DCT=1 in MAnalyse, but instead with different blocksizes and overlaps in MAnalyse and MRecalculate.

I had a similar crash problem with FFTW related to mvtools2 in a script some time ago with SET’s avisyth 2.6 MT and Firesledge’s mvtools 2.6.0.5. So I tried my old solution in your script, appending mt=False to MSuper, MAnalyse and MRecalculate, but that didn’t help. It still crashes.

Then I tried changing MRecalculate with the same blocksize and overlap you used in MAnalyse. This effectively prevents the crash in your script. Although it unfortunately is not what you intend to do, I hope this helps to find a potential bug in MVTools-pfmod.