VideoHelp Forum


Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!


Try StreamFab Downloader and download streaming video from Youtube, Netflix, Amazon! Download free trial.


+ Reply to Thread
Page 5 of 7
FirstFirst ... 3 4 5 6 7 LastLast
Results 121 to 150 of 210
Thread
  1. 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+ ?
    Quote Quote  
  2. Originally Posted by poisondeathray View Post
    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.
    Quote Quote  
  3. 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:

    Quote Quote  
  4. Yes, update to last version of Dither which included the "slice" parameter.
    Quote Quote  
  5. alino: it works for me with SMDegrainMod3.1.2d and the LatestDitherDll&Avsi.
    Image Attached Files
    Quote Quote  
  6. Thanks guys but now I have:




    It's strange...
    Quote Quote  
  7. I fix the problem, I change my mvtools2.dll with the last one .

    Dogway, LouieChuckyMerry thanks
    Quote Quote  
  8. 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
    Last edited by real.finder; 21st Jul 2019 at 20:52. Reason: another changes in the script
    Quote Quote  
  9. 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(!)
    Quote Quote  
  10. Originally Posted by Dogway View Post
    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
    Last edited by real.finder; 16th Nov 2015 at 09:10.
    Quote Quote  
  11. 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.
    Quote Quote  
  12. Originally Posted by Dogway View Post
    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)

    Code:
    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
    Quote Quote  
  13. 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.
    Quote Quote  
  14. Originally Posted by Dogway View Post
    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
    Last edited by real.finder; 10th Oct 2015 at 12:22.
    Quote Quote  
  15. 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.
    Last edited by Dogway; 10th Oct 2015 at 16:32.
    Quote Quote  
  16. cshift is center shift not chroma shift

    it shift both luma and chroma to the center after do
    Code:
    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.
    Last edited by real.finder; 10th Oct 2015 at 17:23. Reason: Typo
    Quote Quote  
  17. 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.
    Quote Quote  
  18. Originally Posted by Dogway View Post
    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
    Quote Quote  
  19. 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.
    Quote Quote  
  20. Originally Posted by Dogway View Post
    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
    Quote Quote  
  21. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    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
    Quote Quote  
  22. Originally Posted by hydra3333 View Post
    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.
    Quote Quote  
  23. Member
    Join Date
    Oct 2015
    Location
    Sweden
    Search PM
    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?
    Quote Quote  
  24. 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)
    Quote Quote  
  25. 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
    Quote Quote  
  26. 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.
    Quote Quote  
  27. Learner
    Join Date
    Jan 2015
    Location
    soton
    Search Comp PM
    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.
    Quote Quote  
  28. Hi Dogway, I hope you've been well . I'm trying to use PreFilter=4 but I receive this error message:

    Image
    [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.
    Quote Quote  
  29. 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
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!