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+ ?
+ Reply to Thread
Results 121 to 150 of 210
alino: it works for me with SMDegrainMod3.1.2d and the LatestDitherDll&Avsi.
I fix the problem, I change my mvtools2.dll with the last one .
Dogway, LouieChuckyMerry thanks
I did some changes to SMDegrain
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
Last edited by real.finder; 21st Jul 2019 at 20:52. Reason: another changes in the script
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(!)
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
Last edited by real.finder; 16th Nov 2015 at 09:10.
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.
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)
and if you set cshift then both chroma and luma will be wrong for pelclip
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
Last edited by real.finder; 10th Oct 2015 at 12:22.
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.
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.
Last edited by Dogway; 10th Oct 2015 at 16:32.
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()
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.
Last edited by real.finder; 10th Oct 2015 at 17:23. Reason: Typo
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.
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
Default: not set (string)
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
If you had been around you would know that it's common knowledge for cshift to be an interchangeable term for chroma shift.
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 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?
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.
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
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.