Simple MDegrain Mod v3.1.2d - A Quality Denoising Solution

[poisondeathray]

tormento - sorry I missed the few posts above . That was on vanilla avisynth 2.6 MT x86. I assume your problem is still referring to avisynth+ ?

[tormento]

tormento - sorry I missed the few posts above . That was on vanilla avisynth 2.6 MT x86. I assume your problem is still referring to avisynth+ ?

Nope I switched back to AVS MT vanilla.

[alino]

Hi Dogway, I have some problem with this

SMDegrain(tr=2, thSAD=200, search=5, lsb=True, prefilter=0)

the problem is lsb=true, all plugins are update dither too.

This is the error with avspmod:

[Dogway]

Yes, update to last version of Dither which included the "slice" parameter.

[LouieChuckyMerry]

alino: it works for me with SMDegrainMod3.1.2d and the LatestDitherDll&Avsi.

[alino]

Thanks guys but now I have:




It's strange...

[alino]

I fix the problem, I change my mvtools2.dll with the last one .

Dogway, LouieChuckyMerry thanks

[real.finder]

hi Dogway

I did some changes to SMDegrain

https://pastebin.com/4y4Zw2xG

1- fix subpixel=3
2- add Prefilter auto 16 (lsb) support
3- YUY2 support in avs 2.6 with masktools 2.6
4- medianblur2 now will be used in Minblur instead of Quantile RemoveGrainHD in avs 2.6
5- add TV_range bool
6- less lsb if not use lsb things and get ready for yv16 and yv24
7- add dct
8- add device_id for prefilter=4
9- no need to use Planar2Interleaved() after cropping in Show with YUY2 (this is old changed, and now with mvtools support yv16 most people will not use YUY2)
10- add MDegrain4 and MDegrain5 and MDegrain6, this will make tr=4-6 faster

maybe can make the next version release soon

the changes didn't dropped the 2.5 support

[Dogway]

Thanks for the helping hand, I haven't had time to check your other two modifications but I wouldn't do the first one.
If you use NNEDI3 v0.9.4.20 there's no need to "fix" anything in SMDegrain.

Now you could argue that NNEDI3 port is only 2.6 compatible but you haven't done any avs26 work around that, and even if you did I would find the choice of 2 chained nnedi3 calls unoptimized, speed can not differ much (if you kept spline16resize for cshift which I added to cut off time) but memory handling may not be the best. Debating on quality of output because a subpixel chroma shift on the prefilter clip when using subpixel=3 in AVS v2.5, I think is a bit too much of a burden for SMDegrain to carry, I would rather expect people to insist to the original developer.

edit: Also I want to know how KNLmeans unfolds for v7.0 in order to do any modifications in the script if necessary, just have some patience, I just released v3.1.2 two and a half months back(!)

[real.finder]

Thanks for the helping hand, I haven't had time to check your other two modifications but I wouldn't do the first one.
If you use NNEDI3 v0.9.4.20 there's no need to "fix" anything in SMDegrain.

Now you could argue that NNEDI3 port is only 2.6 compatible but you haven't done any avs26 work around that, and even if you did I would find the choice of 2 chained nnedi3 calls unoptimized, speed can not differ much (if you kept spline16resize for cshift which I added to cut off time) but memory handling may not be the best. Debating on quality of output because a subpixel chroma shift on the prefilter clip when using subpixel=3 in AVS v2.5, I think is a bit too much of a burden for SMDegrain to carry, I would rather expect people to insist to the original developer.

edit: Also I want to know how KNLmeans unfolds for v7.0 in order to do any modifications in the script if necessary, just have some patience, I just released v3.1.2 two and a half months back(!)

new edit https://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denois...=1#post2413356 for make YUY2 fast

about NNEDI3, it should be used with no cshift setting in SMDegrain, so if you use NNEDI3 v0.9.4.20 or older versions it will be almost the same, more about that here

[Dogway]

What I am trying to say is that if you have problems with NNEDI3 (including documentation), post on the NNEDI3 thread. My usage of the plugin is correct and if you think something is wrong (other than the chroma shift for rfactor=4 in AVS2.5), then try to explain it in a elaborated way or at least link me to a post that does.

[real.finder]

What I am trying to say is that if you have problems with NNEDI3 (including documentation), post on the NNEDI3 thread. My usage of the plugin is correct and if you think something is wrong (other than the chroma shift for rfactor=4 in AVS2.5), then try to explain it in a elaborated way or at least link me to a post that does.

ok, here a little test (do it in any version of NNEDI3)

r = blankclip(width=64,height=64,pixel_type="YV12",color_yuv=$FF0000)
g = blankclip(width=64,height=64,pixel_type="YV12",color_yuv=$00FF00)

stackhorizontal(r,g)
stackvertical(last,last.fliphorizontal())

regularupsample=Dither_convert_8_to_16().Dither_Resize16(width*2,height*2,src_left=0.25, src_top=0.25).Ditherpost(mode=-1) #src_left=0.25, src_top=0.25 from mvtools2 manual
nnedi3upsample=nnedi3_rpow2(rfactor=2)
interleave(regularupsample,nnedi3upsample)

the shift is the same here

and if you set cshift then both chroma and luma will be wrong for pelclip

[Dogway]

Not sure what you want to proof, give this a go, so far can't see anything wrong.

If you have any qualms discuss it with jpsdr. We have been arguing about NNEDI3 for several posts now when its use within SMDegrain is tangential at most.

[real.finder]

Not sure what you want to proof, give this a go, so far can't see anything wrong.

If you have any qualms discuss it with jpsdr. We have been arguing about NNEDI3 for several posts now when its use within SMDegrain is tangential at most.

the problem here is not in NNEDI3 as I say before, the synopsis is that pelclip need top-left aligned clip so in regular resize we need src_left=0.25, src_top=0.25 for pel=2 and src_left=0.375, src_top=0.375 for pel=4

and in NNEDI3 with rfactor=2 and without set cshift the output clip will be top-left aligned so we don't need to set cshift for pel=2 pelclip as the example here, but for pel=4 we need to do it like this nnedi3_rpow2(rfactor=2).nnedi3_rpow2(rfactor=2)

set cshift will make the output clip centred as the original and that wrong for pelclip

see mvtools2 manual\documentation and http://forum.doom9.org/showpost.php?p=1409423&postcount=1334 and here too http://forum.doom9.org/showthread.php?t=147285 (aWarp4 examples) or http://avisynth.nl/index.php/AWarpsharp2/aWarp4

cshift was wrong in chroma and jpsdr fix it, but as we don't need cshift here so any version of NNEDI3 will be enough

[Dogway]

Your point, which basically is resumed here, is that pelclip expects (for some reason) borked top-left chroma aligned clips, just like indeed nnedi3_rpow2 output without chroma shift correction, both blatantly wrong but... expected input for pelclip. Is that so?

-I have several questions with this, first more references/documentation on why this "top-left" alignment.
-Second why isn't this fixed at mvtools2 level, firesledge had been very proactive on fixing and updating mvtools2 code.
-Third, I wouldn't run two chained nnedi3 calls, I would use rfactor=4 for pel=4, and then correct for chroma, this is more optimized IMO (although I haven't run tests yet)
-And fourth your example test is wrong, as per documentation the Dither resizing fix you are using is only towards luma, for chroma:

Recent note: it is true for luma, but it doesn't correspond to chroma pixels positions of internal MVTools interpolation. Nevertheless vectors and motion compensation are quite similar for usual clips, same chroma would be with src_left = 0.5 for YUY2 and additionally src_top = 0.5 for YV12.

I wouldn't know how that translates as it is poorly explained, but one of your links already answered that.



About your aWarp4 link. The only relation to mvtools2 pelclip, is that it is equally broken chroma placement wise. It also expects top-left alignment so it should be fixed, conforming to broken practices is risky and misleading, firesledge/cretindesalpes also did a modification of awarpsharp2 but he didn't deal with the bug (he doesn't have to either way).

I'm not going to contradict so many knowledgeable developers that actually had a glimpse to the original code like SEt, Gavino or cretindesalpes, so I can add borked code to comply to pelclip, but it needs annotations because the code is wrong and the plugins should be fixed at some point.

[real.finder]

cshift is center shift not chroma shift

it shift both luma and chroma to the center after do

nnedi3(dh=true)
turnright()
nnedi3(dh=true)
turnleft()

the need of top-left aligned is not a bug, from mvtools2 guide

Pixels at rows and colunms positions multiple to pel (0,2,4,... for pel=2) (without padding) must be original source pixels, other pixels must be interpolated.

[Dogway]

cshift = (chroma plane) center shift

I could correct your English but correcting for the sake of correcting is not going to lead us anywhere. As stated, bugs, non-standard or poorly explained behaviours collide one to each other.
If you want to help, try to explain or expand your quote's reasoning.
I certainly think you were talking about "cositing" when you say "top-left" alignment, but again you haven't supplied a single illustration to show that.

[real.finder]

cshift = (chroma plane) center shift

I could correct your English but correcting for the sake of correcting is not going to lead us anywhere. As stated, bugs, non-standard or poorly explained behaviours collide one to each other.
If you want to help, try to explain or expand your quote's reasoning.
I certainly think you were talking about "cositing" when you say "top-left" alignment, but again you haven't supplied a single illustration to show that.

from nnedi3 - Readme.txt

cshift -

Sets the resizer used for correcting the image center shift that nnedi3_rpow2
introduces. This can be any of Avisynth's internal resizers, such as "spline36resize",
"lanczosresize", etc... If not specified the shift is not corrected. The correction
is accomplished by using the subpixel cropping capability of Avisynth's internal
resizers.

Default: not set (string)

"top-left aligned" quoted from SEt

Anyway, I modified your script, including the subpixel=3, and you free to accept all edits or some of it, or even not accept any of it

thanks

[Dogway]

If you had been around you would know that it's common knowledge for cshift to be an interchangeable term for chroma shift.
http://forum.doom9.org/showthread.php?p=1662264&highlight=chroma+shift#post1662264

To inquiry something you should understand it first, but you only quote or link to what I already tagged as poor or loose definitions. "top-left aligned" could mean anything, you need to talk about pixel center and cositing or not (interstitially siting). Or make a picture instead. In my book "original source pixels" means cosited, but in yours mean "top-left".

I will call it a bug regardless until someone reasons why it should be top-left aligned and documents it clear enough.

[real.finder]

If you had been around you would know that it's common knowledge for cshift to be an interchangeable term for chroma shift.
http://forum.doom9.org/showthread.php?p=1662264&highlight=chroma+shift#post1662264

To inquiry something you should understand it first, but you only quote or link to what I already tagged as poor or loose definitions. "top-left aligned" could mean anything, you need to talk about pixel center and cositing or not (interstitially siting). Or make a picture instead. In my book "original source pixels" means cosited, but in yours mean "top-left".

I will call it a bug regardless until someone reasons why it should be top-left aligned and documents it clear enough.

I know the jpsdr NNEDI thread

I was there too http://forum.doom9.org/showthread.php?p=1733293#post1733293

[tormento]

VapourSynth version here.

[hydra3333]

Thank you tormento.
I hold out a tiny hope for DG's NV tools in vapoursynth some day, but until then vs is unfortunately a no-go zone for me

[tormento]

Thank you tormento.
I hold out a tiny hope for DG's NV tools in vapoursynth some day, but until then vs is unfortunately a no-go zone for me

Try this.

[markanini]

I sometimes use this for reducing blocking and moquito nosie on shitty sources in realtime although I'm not sure I've found the optimal settings. My CPU sometimes chokes on SD and above material. What would be suitable settings settings for this purpose?

[Dogway]

Hello markanini (S)MDegrain is great for fine filtering, the trick is to use whatever filter you need to pass but as a SMDegrain prefilter rather than directly. You can even use a tangled chain of filters even masked (ie. to deal with mosquito), and ultimately pass it as prefilter. But I don't think you can run this in real time, it's not made for that. The next is the fastest you might get without any prefilter, if it's still slow add pel=1.

smdegrain(tr=1,thSAD=300,hpad=0,vpad=0,subpixel=0)

[real.finder]

yesterday tried to use prefilter=2 in very grainy 1080 source and then I get stability issues because high memory use, so I did another change https://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denois...=1#post2413356

[Dogway]

Yes, I learned the hard way years back, brackets can't be omitted. I guess everything else is fine but I will have a look soon, I want to release v3.2, it's a compendium of little fixes.

[BÌG•bµdd]

Hi, i was trying "Globals=1" but i can't get smdegrain works with globals option here is a what error i get

http://prntscr.com/a04sd8

please can anyone explain it how can i get Smdegrain worked with Globals=1 option.

[LouieChuckyMerry]

Hi Dogway, I hope you've been well . I'm trying to use PreFilter=4 but I receive this error message:


[Attachment 35630 - Click to enlarge]

Checking the .avsi, line 199 is "input8". KNLMeansCL works on it's own without issue so I don't know what's wrong. Any help would be much appreciated, thanks.

[The Masked Onion]

a new version of KNLMeansCL has been released with improved device selection. Give that a try and see if it works.

https://github.com/Khanattila/KNLMeansCL/releases/tag/v0.7.5