MVTools-pfmod

[hello_hello]

It could be that I'm losing my mind, or maybe it's related to the previous MDegrainN bug, but I've been using the following for light denoising now and then:

tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
MDegrainN (super, multi_vec, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

That works fine, but if I make the three changes highlighted blue below, it results in an error message "Invalid arguments to function MDegrainN". Am I missing the obvious?

#tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=1)
MDegrainN (super, multi_vec, tr=1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

Thanks.

[MysteryX]

MDegrainN (super, multi_vec, tr=1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)
tr is the name of the variable, not the name of the parameter.

Try this

MDegrainN (super, multi_vec, 1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

[hello_hello]

MysteryX,
If it's a named argument, shouldn't tr=1 work, or am I being dumb?

Your suggestion does work, by the way.

MDegrainN (super, multi_vec, 1, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

But to me it should work like this. All these MAnalyse configurations seem to be fine:

tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
MDegrainN (super, multi_vec, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

or

multi_vec = MAnalyse (super, blksize=16, mt=mt, multi=true, overlap=overlap, delta=tr)

or

multi_vec = MAnalyse (super, 16, mt=mt, multi=true, overlap=overlap, delta=tr)

I'm not understanding why the same doesn't apply to "tr", or even supplying the input clips for MDegrainN as named arguments. That doesn't seem to work either. Should it, or am I being silly?

[MysteryX]

I'm not understanding why the same doesn't apply to "tr", or even supplying the input clips for MDegrainN as named arguments. That doesn't seem to work either. Should it, or am I being silly?
Because the argument's name is not "tr". We'd have to check in the doc to know the argument's name.

[hello_hello]

I did. :)

tr
Temporal radius, > 0. Must match the mvmulti content, i.e. the delta parameter in MAnalyse.

MDeGrainN (
clip,
clip super,
clip mvmulti,
int tr,
int thSAD (400),
int thSADC (thSAD),
int plane (4),
int limit (255),
int limitC (limit),
int thSCD1,
int thSCD2,
bool isse,
bool planar,
bool lsb (false),
int thSAD2 (thSAD),
int thSADC2 (thSADC),
bool mt (true)
)

[pinterf]

While I'm asking, I assume this means there's a reasonable difference between the old ff3dfilter and the new? Is it something to care about?

Cheers.

fft3dfilter 2.3 vs fft3dfilter 2.4

http://image.ibb.co/mGjk2k/fft3dfilter1.jpg

fft3dfilter 2.3 vs fft3dfilter 2.1.1

http://image.ibb.co/cGOdNk/fft3dfilter2.jpg
Maybe different compiler, 80 bit x87 arithmetic vs 64 bit IEEE double/float, or rounding, etc...
I have found a build of 2.1.1 version from 2011 which is giving identical results to the current 2.2.4 but is different from the original 2007 version.
Nevertheless, the differences are very minor.
Even the existing C and SSE results are different within the same plugin, so I don't think we should put more time into investigating bit-identical outputs in this case.

[pinterf]

I did. :)

tr
Temporal radius, > 0. Must match the mvmulti content, i.e. the delta parameter in MAnalyse.

MDeGrainN (
clip,
clip super,
clip mvmulti,
int tr,
int thSAD (400),
int thSADC (thSAD),
int plane (4),
int limit (255),
int limitC (limit),
int thSCD1,
int thSCD2,
bool isse,
bool planar,
bool lsb (false),
int thSAD2 (thSAD),
int thSADC2 (thSADC),
bool mt (true)
)

MDegrainN's signature:
ccci[thSAD]i[thSADC]i[plane]i[limit]i[limitC]i[thSCD1]i[thSCD2]i[isse]b[planar]b[lsb]b[thsad2]i[thsadc2]i[mt]b

Even super and mvmulti are named in the documentation but cannot be specified with their names.

[hello_hello]

pinterf,

Thanks for your efforts. The "tr" thing seems odd, but at least now I know why.

Cheers.

[pinterf]

New mvtools2 release, fixed broken MDegrainN chroma.
Thanks hello_hello for the report.

Download mvtools2 2.7.21.22 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.21.22)

- 2.7.21.22 (20170629)
Fix: [MDegrainN] fix chroma plane processing

[MysteryX]

I'm trying to build MvTools2 to run it into a profiler to see if anything comes up while running with MT.

How do I get it to build? It needs YASM.

I downloaded the x64 version of YASM. Extracted to this folder and removed the "vs" in front of each file so it's called "yasm"
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\BuildCustomizations\

Then I copied vsyasm.exe to
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\bin\

I changed the project to use VS 2017 and WinSdk10.

I get this error
The command ""C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\bin\"vsyasm.exe -Xvc -f Win32 -g cv8 -i "asm/include" -o "Win32\Debug\mvtools\\" -rnasm -pnasm -DPREFIX asm\Bilinear.asm asm\fdct_mmx.asm" exited with code 1.

What's missing?

[StainlessS]

MysteryX, could these be related.

https://forum.doom9.org/showthread.php?p=1742975#post1742975

https://forum.doom9.org/showthread.php?p=1780581#post1780581

[feisty2]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

[StainlessS]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?

I'm sure that Pinterf would appreciate all assistance that you care to offer in doing that, would likely be lots of hard work and a whole bevy of new bugs to iron out, but would give you much satisfaction when you've finally done it successfully.

Looking forward to it. :thanks:

[MysteryX]

Here are benchmark tests of jm_fps script (simplified version)

function jm_fps(clip C, int Dct) {
Blksize=16
BlkSizeV=16
Dct = Default(Dct, 0)
NewNum=60
NewDen=1
Recalculate = false
Prefilter = C.RemoveGrain(22)
superfilt = MSuper(prefilter, hpad=16, vpad=16) # all levels for MAnalyse
super = MSuper(C, hpad=16, vpad=16, levels=1)
bak = MAnalyse(superfilt, isb=true, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, overlapv = BlkSizeV>4?(BlkSizeV/4+1)/2*2:0, search=3, dct=Dct)
fwd = MAnalyse(superfilt, isb=false, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, search=3, dct=Dct)
fwd = Recalculate ? MRecalculate(super, fwd, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : fwd
bak = Recalculate ? MRecalculate(super, bak, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : bak
Flow = MFlowFps(C, super, bak, fwd, num=NewNum, den=NewDen, blend=false, ml=200, mask=2, thSCD2=255)
return Flow
}

DCT=0, single-thread

FPS (min | max | average): 3.189 | 14.91 | 5.136
Memory usage (phys | virt): 289 | 296 MiB
Thread count: 21
CPU usage (average): 12%

DCT=0, Prefetch(8)

FPS (min | max | average): 2.933 | 77949 | 15.08
Memory usage (phys | virt): 1401 | 1422 MiB
Thread count: 29
CPU usage (average): 68%

DCT=1, single-threaded

FPS (min | max | average): 0.160 | 16.01 | 0.448
Memory usage (phys | virt): 314 | 319 MiB
Thread count: 21
CPU usage (average): 11%


DCT=1, Prefetch(8)

FPS (min | max | average): 0.109 | 66813 | 1.119
Memory usage (phys | virt): 1096 | 1105 MiB
Thread count: 26
CPU usage (average): 37%

DCT=0 is "fine" with 68% CPU usage. DCT=1 is what gives problems with multi-threading with 37% CPU usage, choppy playback, and occasional freezes -- but DCT=1 is definitely better than before the recent Pinterf fix!

[Groucho2004]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?The asm shit tends to be pretty fast if done properly.

[feisty2]

The asm shit tends to be pretty fast if done properly.

-> any particular reason you cant just get rid of all that asm shit and use intrinsics instead?
no comment

[Groucho2004]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?Define "use intrinsics". There is no automatic ASMShitToIntrinsics converter of which I'm aware. There are ~10,000 lines of asm in mvtools2.

[feisty2]

Define "use intrinsics". There is no automatic ASMShitToIntrinsics converter of which I'm aware. There are ~10,000 lines of asm in mvtools2.

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#

[Groucho2004]

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#Very good, you posted the Intel intrinsics reference. I still don't see the magic that converts 10000 lines of ASM shit to intrinsics.

[Groucho2004]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?By the way, what did you do with the asm shit in your VS single precision mvtools?

[feisty2]

Your original post was "asm shit is fast", and I been saying, intrinsics are equally fast, without having to use an assembler
Obviously you realized that, then you changed your point to, "you can't automatically convert raw asm to intrinsics"
Get a room with Katie already, troll

[Groucho2004]

Your original post was "asm shit is fast", and I been saying, intrinsics are equally fast, without having to use an assembler
Obviously you realized that, then you changed your point to, "you can't automatically convert raw asm to intrinsics"
Get a room with Katie already, trollI didn't change my point, you missed it. Also, you didn't write "intrinsics are equally fast, without having to use an assembler", you wrote "use intrinsics instead" which is very vague and implies that this could be done instantly.

What's wrong with using an assembler? Do you realize that for example the speed of libx264 is based on its highly efficient asm code?

My point is that there is perfectly good and fast asm code in mvtools2 (32 and 64 bit). Having this converted to intrinsics would be good but it's a lot of work.

[tebasuna51]

...
Get a room with Katie already, troll

Please guys stop that way.

The question is clear, stop the discussion.

[Groucho2004]

Please guys stop that way.

The question is clear, stop the discussion.
I'm not sure to which question you're referring, Mystery's or feisty's. Either way, nothing wrong with having a discussion. I still don't quite understand feisty's troll accusation but I suppose there was some kind of misinterpretation of something I posted...

[TheFluff]

The main benefit of intrinsics over handwritten assembly is that it's easier to write and maintain, as well as easier to integrate into your C++ stuff (such as templates - a lot of the VS multi-bitdepth stuff uses templated intrinsics). A minor bonus is that you don't need a separate assembler in addition to your regular compiler. However, if you already have a bunch of well tested and functioning .asm (in separate files, not some inline monstrosity pain in the rear) and that you have no intention of changing, then porting to intrinsics is just a lot of busy-work that's probably going to introduce a lot of new and exciting bugs. Not even the VS port of MVTools has gotten rid of all the .asm files, because there was simply no need. New code has been ported to intrinsics though.

[Groucho2004]

However, if you already have a bunch of well tested and functioning .asm (in separate files, not some inline monstrosity pain in the rear) and that you have no intention of changing, then porting to intrinsics is just a lot of busy-work that's probably going to introduce a lot of new and exciting bugs. Not even the VS port of MVTools has gotten rid of all the .asm files, because there was simply no need.
That was exactly my point. I think pinterf replaced most (if not all) inline asm with intrinsics so the remaining problem seems to be that some people have trouble producing a few .obj files using yasm/nasm. It's just bizarre.

[yup]

pinterf :thanks: for update.
Now some my scripts work stable.
But I see strange behaviour when open scripts in VirtualDubMod, I do not see error message if I writen script with error related to MVTools functions, during this VirtatualDub hung and not response.
I can not close video in Vitualdub, only close Vitualdub.
Job control also do not work.
Please advice.

yup.

[pinterf]

any particular reason you cant just get rid of all that asm shit and use intrinsics instead?
Because the porting is done in my free time which is limited.

Asm vs intrinsics.

SAD and SATD code (which are the most important routines regarding mvtools2 speed) written in intrinsics is _much_ slower than using existing asm, I'm talking about VS2015/2017 code generator.

I have experienced the opposite case as well when the generated code from intrinsics is faster than the original asm (experienced in FFT3DFilter and TIVTC) perhaps because of smarter instruction ordering. Even a C version can be faster than the old asm (TIVTC).

I usually have a look at the generated assembler code of the intrinsics.

There are cases when the optimizer uses too many xmm registers, so the prolog/epilog register save/restore (which we cannot control) takes significant time relative to the actual task, as experienced in 16 bit SAD intrinsics routines. I had to play with less-than-optimal loop unrolling until I found out the fastest result for a particular SAD blocksize.

[pinterf]

DCT=0 is "fine" with 68% CPU usage. DCT=1 is what gives problems with multi-threading with 37% CPU usage, choppy playback, and occasional freezes -- but DCT=1 is definitely better than before the recent Pinterf fix!
DCT=1 is using integer arithmetic for 8 bit video and 8x8 block sizes.
In all other cases (such as for block size 16x16) the routines from the FFTW3 library are used.
I don't know which fftw3 version are you using (i can see 3.3.6 as the latest one in http://www.fftw.org/ ), perhaps you could try comparing different versions.

[MysteryX]

I don't know which fftw3 version are you using (i can see 3.3.6 as the latest one in http://www.fftw.org/ ), perhaps you could try comparing different versions.
I don't know which version but it is from March 2014 :D I'll try the latest and see how it behaves.

Still the same problem. Stuck at 37% CPU usage.

It is the libfftw3f-3.dll file in C:\Windows\SysWOW64, correct?

If I use BlkSize=8, I get 47% CPU usage.

[shae]

What's supposed to happen if FFTW is missing?

QTGMC seems to work without it. Is it because MvTools2 doesn't always need it or something else?

And can it load libfftw3f-3.dll from the same directory as mvtools2.dll instead of the system dir?
AvsMeter says the FFTW DLL cannot be loaded, but maybe it only looks for it in the system directory.

[real.finder]

What's supposed to happen if FFTW is missing?

QTGMC seems to work without it. Is it because MvTools2 doesn't always need it or something else?

And can it load libfftw3f-3.dll from the same directory as mvtools2.dll instead of the system dir?
AvsMeter says the FFTW DLL cannot be loaded, but maybe it only looks for it in the system directory.

yes, MvTools2 doesn't always need it

you can load FFTW DLL by using this (https://forum.doom9.org/showthread.php?t=119200), x64 here (https://forum.doom9.org/showthread.php?p=1777483#post1777483)

[shae]

I think I'll just go by "it's probably fine if it the script loads, doesn't crash, and the beginning of the video look okay". :)

[GMJCZP]

When I use this hello_hello script (# 301) in 16 bits:
tr = 1 # Temporal radius
mt = true # Internal multithreading
lsb = false # 16-bit
thSAD = 200 # denoising strength
blksize = 16 # block size
overlap = 4 # block overlap
super = MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
MDegrainN (super, multi_vec, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=150)

By putting lsb = true, delta =1 and tr> 1 I get artifacts.

[hello_hello]

GMJCZP,
Delta and TR have to be the same. From the help file:

MDeGrainN has a temporal radius given by the tr parameter, and uses a special motion vector clip.
tr
Temporal radius, > 0. Must match the mvmulti content, i.e. the delta parameter in MAnalyse.

[GMJCZP]

:thanks:

Problem solved.

[GMJCZP]

Now I have another problem, I do not present the image correctly if I do not use f3kdb and DitherPost together, I'm still a rookie at this 16-bit:

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)
DitherPost()

# 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

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
}


In truck, if I use dfttest(sigma=2, tbsize=1, lsb_in=true, lsb=true, Y=true, U=true, V=true, opt=3, dither=0), instead of MDegrain, DitherPost is no longer necessary.
Can anyone please explain to me if I am redundant with DitherPost, or if my script is correct?

Or is there a way to use only, or f3kdb or DitherPost?

[blaze077]

1. Afaik, TemporalSoften does not support 16 bit stacked input, so you should apply it before the dither_convert_8_to_16 call.

2. I don't think MDegrainN takes in 16 bit stacked input. It can only output it using lsb=true. (No lsb_in parameter)

3. Ditherpost simply turns a 16 bit clip into an 8 bit clip. In your f3kdb call, you already output 8 bit video so you don't need ditherpost.

Alternatively, you could change f3kdb's output_depth to 16, and then ditherpost would work as expected.

[GMJCZP]

1. Temporal soften does not have anything to do with the problem.
2. The script works perfectly as it is, the problem is if I use f3kdb and DitherPost together, I said it before.
3. I repeat it again, if I do not use DitherPost the video is poorly displayed.

Anyway thanks for the reply.

I repeat my doubt, Is my script okay and I'm not messing with DitherPost?, Because I can not get an f3kdb command that correctly displays the image.

EDIT: I solved the problem, the MVTools documentation says:

lsb

Generates 16-bit data when set to true. The picture made of the most siginificant bytes (MSB) is stacked on the top of the least significant byte (LSB) block. Hence a twice taller resulting picture. You can extract the MSB or the LSB with a simple Crop() call. This mode helps recovering the full bitdepth of temporally dithered data.

Then the definitive script 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).Crop(0,0,0,960)
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

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
}

In short, DitherPost was not necessary.

[blaze077]

I just tried to run your script and the cause is indeed your MDegrainLight function.
As you know, 16 bit stacked is double the height of the normal video (MSB and LSB).
You pass a 16 bit stacked clip to MDegrainN, but MDegrain does not have any way of knowing that you passed a 16 bit stacked clip to it. It just assumes that you gave it an 8 bit clip and processes it accordingly.
Since you pass lsb=true to MDegrainN, it tries to convert the already 16 bit stacked clip to 16 bit stacked again.
The result is that your video is now 4 times it's normal height!
With the f3kdb call, the video is back to double height and with the ditherpost call, it is back to normal height.

A solution can be to call ditherpost() before all the MVTools calls (MSuper, analyze and degrainN) inside your MDegrainLight function.

[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]

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]

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]

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
}

:)