real.finder's Avisynth Stuff

[dREV]

Originally Posted by real.finder

I think you need to know the basic of what lsb (aka dither tools things aka Stack16) and what is HBD in avs+, why don't you read the wiki link I post many many times?!!! they can't be mixed UNLESS with http://avisynth.nl/index.php/ConvertStacked (the link you don't read or don't understand its content every time) and btw you already mixed both (even without ConvertFromDoubleWidth by using Dither_out with HBD input so the output will be 100% wrong indeed) but in wrong way

Listen man. I keep writing my posts in very plain English as best I can. I've read so many posts on doom9 that I've come to the conclusion that getting simple plain English is at times out of reach of its many posters.

My entire confusion came from your post of this

ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
lc = edi_rpow2(fwidth=1280*2, fheight=720*2,cshift="Spline64")
lu = lc.ExtractU()
lv = lc.ExtractV()
YtoUV(lu,lv,ly)

I've read http://avisynth.nl/index.php/ConvertStacked many times and I've asked the simplest question of how to turn off and on 8 bit to 16 bit and vice-versa. If it was me speaking to somebody who was like myself I would of wrote to him/her that

ConvertToStacked() and ConvertFromStacked() is kinda = dither_convert_8_to_16()

done, nothing complicated, no necessary posts, nada with additional notes. If you know what was in the lsb hack http://avisynth.nl/index.php/Dither_tools this concept of To and From DOES NOT EXIST and this is what I was going by.

The documentation says NOTHING about this. While I also had the pressing issue of finding a way how to go to 8 bit to 16 bit and vice-versa was my MAIN CONCERN after your modded resizer scripts. I kept writing ConvertBits(bits=8) thinking it was dither_convert_8_to_16() but it was NOT working!

I don't even know what your correlation of ConvertFromDoubleWidth() is with Dither_out() I need a DitherPost(mode=-1) equivalent.

And no I was not using Dither_out() at all until I wrote what you said. On avspmod it's been only DitherPost(mode=-1) and I had to turn it off as it was NOT working with HBD that and you should know that Dither_out() on avspmod would result in green or something that would not look correct.

Originally Posted by real.finder

do not expect getting a result identity by 100% matching if the script or the used plugins or even the avs changed/updated, and that normal since the edit I did for GradFun3mod and DebilinearM will use yet another plugins away from original Debilinear.dll

and my edit of nnedi3_resize16 in avs+ even with lsb it will use some HBD features to get real 16bit as possible since nnedi3_resize16 with lsb don't do real 16 bit proccess in first place since nnedi3 don't has lsb support, so yes without set the nlsb in nnedi3_resize16 to false in avs+ you will get a different result and it should be a better

That's not how it should be. The detail loss is apparent and it's not worth using your nnedi3 version over the original if detail is loss. Don't take that with disrespect which seems you may have.

-----------------------------------------------------

I'm having some issues with your MAA2 script and ConvertBits. Everything works fine on avspmod but when it comes time to encode I get errors.

For MAA2 script on MeGUI it states this: Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)

Everything is above the requirement to use this script. The original works just fine. I dunno how to go about where the issue is for this one.

For ConvertBits maybe it's the combination of MeGUI ver2525, HEVC (latest 3.1.0.14), using the old lsb hack to pipe. It just says this on MeGUI

---[NoImage] AssumeTFF()
---[NoImage] LoadPlugin("C:\Path\avstp.dll")
---[NoImage] LoadPlugin("C:\Path\dfttest.dll")
---[NoImage] LoadPlugin("C:\Path\AddGrainC.dll")
---[NoImage] LoadPlugin("C:\Path\dither.dll")
---[NoImage] Import("C:\Path\dither.avsi")
---[NoImage] LoadPlugin("C:\Path\mvtools2.dll")
---[NoImage] LoadPlugin("C:\Path\masktools2.dll")
---[NoImage] Import("C:\Path\mt_xxpand_multi.avsi")
---[NoImage] LoadPlugin("C:\Path\RgTools.dll")
---[NoImage] LoadPlugin("C:\Path\fturn_26.dll")
---[NoImage] #Import("C:\Path\Antialiasing_MAA2.avsi")
---[NoImage] LoadPlugin("C:\Path\SangNom2.dll")
---[NoImage] LoadPlugin("C:\Path\DctFilter.dll")
---[NoImage] LoadPlugin("C:\Path\nnedi3.dll")
---[NoImage] Import("C:\Path\Contra_Sharpen_mod_3.4.avsi")
---[NoImage] LoadPlugin("C:\Path\SmoothAdjust.dll")
---[NoImage] Import("C:\Path\EdgeCleaner1.04.avsi")
---[NoImage] LoadPlugin("C:\Path\aWarpSharp.dll")
---[NoImage] Import("C:\Path\Hysteria_20161019.avsi")
---[NoImage] #Import("C:\Path\LSFmod.v1.9.avsi")
---[NoImage] LoadPlugin("C:\Path\warpsharp.dll")
---[NoImage] Import("C:\Path\FineSharp.avsi")
---[NoImage] LoadPlugin("C:\Path\flash3kyuu_deband.dll")
---[NoImage] Import("C:\Path\flash3kyuuMOD16.avsi")
---[NoImage] #Import("C:\Path\DebilinearM_v1.3.1.avsi")
---[NoImage] LoadPlugin("C:\Path\debilinear.dll")
---[NoImage] LoadPlugin("C:\Path\debicubic.dll")
---[NoImage] #Import("C:\Path\ResizeX_v1.0.1.avsi")
---[NoImage] Import("C:\Path\HQDeringmod_v1.8.avsi")
---[NoImage] LoadPlugin("C:\Path\MedianBlur2.dll")
---[NoImage] #Import("C:\Path\DeHalo_FineDehalo.avsi")
---[NoImage] #Import("C:\Path\GradFun3mod.avsi")
---[NoImage] LoadPlugin("C:\Path\EdgeFixer.dll")
---[NoImage] LoadPlugin("C:\Path\FillMargins.dll")
---[NoImage] Import("C:\Path\SMDegrain_plus v.3.1.2.104s.avsi")
---[NoImage] Import("C:\Path\GradFun3mod_plus r6 mod 3.1.avsi")
---[NoImage] Import("C:\Path\nnedi3_resize16_v3.3_plus.avsi")
---[NoImage] Import("C:\Path\edi_rpow2_plus v1.0 mod 7.avsi")
---[NoImage] Import("C:\Path\ResizeX_plus v1.0.1_mod 9.35.avsi")
---[NoImage] Import("C:\Path\DebilinearM_plus v1.3.1_mod_1.25.avsi")
---[NoImage] Import("C:\Path\LSFmod_plus v2.183.avsi")
---[NoImage] Import("C:\Path\DeHalo_FineDehalo_plus v1.1 mod8.75.avsi")
---[NoImage] LoadPlugin("C:\Path\despot.dll")
---[NoImage] ConvertBits(bits=16) #if it not 16 HBD already
---[NoImage] #GradFun3mod(thr=0.05, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
---[NoImage] ly = ConvertToStacked().GradFun3mod(thr=0.35, smode=2,thr_det=2,elast=4,mode=6, yuv444=true, resizer="DebilinearMTM", lsb_in=true, lsb=true).ConvertFromStacked()
---[NoImage] lc = edi_rpow2(fwidth=1280*2, fheight=720*2,cshift="Spline64",nsize=6,pscrn=2,qual=2,etype=0)
---[NoImage] lu = lc.ExtractU()
---[NoImage] lv = lc.ExtractV()
---[NoImage] YtoUV(lu,lv,ly)
---[NoImage] Dither_out()
--[Error] [9/13/2019 10:32:16 AM] An error occurred
---[Error] [9/13/2019 10:32:16 AM] Exception message
----[NoImage] The file Z:\samples\# # megui\work\n1rzueuv.2zd\test.avs cannot be opened.
----[NoImage] Error message for your reference: Script error: there is no function named "ConvertBits"
----[NoImage] (Z:\samples\# # megui\work\n1rzueuv.2zd\test.avs, line 47)
---[Error] [9/13/2019 10:32:16 AM] Stacktrace
----[NoImage]    at MeGUI.JobUtil.GetAllInputProperties(UInt64& nbOfFrames, Double& framerate, Int32& framerate_n, Int32& framerate_d, Int32& hRes, Int32& vRes, Dar& dar, String video)
----[NoImage]    at MeGUI.JobUtil.getInputProperties(UInt64& nbOfFrames, Double& framerate, String video)
----[NoImage]    at MeGUI.OneClickPostProcessing.StartPostProcessing()
---[Error] [9/13/2019 10:32:16 AM] Inner exception
----[Error] [9/13/2019 10:32:16 AM] Exception message
-----[NoImage] Script error: there is no function named "ConvertBits"
-----[NoImage] (Z:\samples\# # megui\work\n1rzueuv.2zd\test.avs, line 47)
----[Error] [9/13/2019 10:32:16 AM] Stacktrace
-----[NoImage]    at MeGUI.AviSynthClip..ctor(String func, String arg, AviSynthColorspace forceColorspace)
-----[NoImage]    at MeGUI.AvsFile..ctor(String script, Boolean parse)
-----[NoImage]    at MeGUI.JobUtil.GetAllInputProperties(UInt64& nbOfFrames, Double& framerate, Int32& framerate_n, Int32& framerate_d, Int32& hRes, Int32& vRes, Dar& dar, String video)
----[Error] [9/13/2019 10:32:16 AM] Inner exception: null
--[Information] [9/13/2019 10:32:16 AM] Job completed

As can see I used only the HBD Gradfun3mod script nothing else. With the MAA2 script I used the lsb hack.

[real.finder]

maa2 use SangNom2 which not work with HBD (yet)

and that log said 'there is no function named "ConvertBits"' which mean it not use the avs+, MeGUI already use it's own avisynth

ConvertToStacked() and ConvertFromStacked() is kinda = dither_convert_8_to_16()

that wrong, dither_convert_8_to_16() is kinda mean ConvertBits(16) in HBD, ConvertToStacked mean Convert HBD clip to Stacked clip to use it in old filters that not work with HBD yet but work with lsb (Stacked), and GradFun3mod (even my edit of it) not work with HBD, but my edit of DebilinearM work with HBD

detail loss in my edit of nnedi3_resize16? post your script with video sample, and are you use the last nnedi3 plugin? did you try set nlsb to false?

Dither_out and ConvertFromDoubleWidth FOR YOUR x264 Borders problem IF you still using the lsb/Stack16 things not if you use 8bit or HBD

in HBD ConvertBits(bits=8, dither=-1) is DitherPost(mode=-1) equivalent, don't know if you know but you don't need ConvertBits(bits=8) just for avspmod, it work with HBD nowadays

btw, I did many edits for http://avisynth.nl/index.php/ConvertStacked and added another example for lsb

[Natty]

damn i gave you a short example already but i think you ignored it. i would recommend you to forget HBD and just stick to lsb (dither tools).
HBD is too slow to encode anyways. except the case of f3kdb neo.

[real.finder]

Originally Posted by Natty

damn i gave you a short example already but i think you ignored it. i would recommend you to forget HBD and just stick to lsb (dither tools).
HBD is too slow to encode anyways. except the case of f3kdb neo.

dREV has many problems so I'm not surprised of ignored or not note it, but anyway it's also in wiki and in my posts but seems dREV still don't get the point of these functions/examples

about the speed, lsb is slower when it did real 16bit, HBD is faster and you can see that in SMDegrain(n16_out=true) vs SMDegrain(lsb_out=true) see here https://forum.doom9.org/showthread.p...10#post1837210

must lsb things don't do real or at least don't do full 16bit process so you may see HBD slow compare to it

you can try DebilinearM using DeResizeMT=true with HBD vs lsb and see. even if it do masking in 8bit with lsb it should give you more speed with HBD and better result

[Natty]

Originally Posted by real.finder

dREV has many problems so I'm not surprised of ignored or not note it, but anyway it's also in wiki and in my posts but seems dREV still don't get the point of these functions/examples

about the speed, lsb is slower when it did real 16bit, HBD is faster and you can see that in SMDegrain(n16_out=true) vs SMDegrain(lsb_out=true) see here https://forum.doom9.org/showthread.p...10#post1837210

must lsb things don't do real or at least don't do full 16bit process so you may see HBD slow compare to it

you can try DebilinearM using DeResizeMT=true with HBD vs lsb and see. even if it do masking in 8bit with lsb it should give you more speed with HBD and better result

yes i recommended him lsb only because he is mixing lsb and hdb incorrectly.

yes n16 is fast, f3kdb neo is fast. but plugins like finedehalo get too much slow.

[dREV]

Originally Posted by real.finder

maa2 use SangNom2 which not work with HBD (yet)

Huh?

Originally Posted by dREV

With the MAA2 script I used the lsb hack. https://forum.doom9.org/showthread.p...08#post1884808

Again it's not working with the lsb hack the original MAA2 worked just fine using all dlls requirements including SangNom2 ver v0.35. I never wrote that I did this using HBD.

Originally Posted by real.finder

and that log said 'there is no function named "ConvertBits"' which mean it not use the avs+, MeGUI already use it's own avisynth

Oh ok I've read about this and they said that in MeGUI 32 bit there's an option under Settings > Main Configuration > Always use the included AviSynth but it's already been checked, so I guess this is an issue with the MeGUI I'm using as it's not working properly while the MeGUI 64 bit version works just fine, so had to get the AviSynth+ dll from the System folder and put it in MeGUI and overwrite the AviSynth 2.0.6 and now it works.

However, it's ConvertToDoubleWidth() seems to be the equivalent to Dither_out() not ConvertFromDoubleWidth() as I kept getting issues with the video when I followed that instruction. Again I've been literally cleaving to the words you've said to me since I'm new to AviSynth+ and trying them out and reporting back. Dither_out() did not work at all with HBD it kept ruining the video also when I use ConvertBits(8) on both avspmod and encoding it.

And also your MAA2 script now works with the removal of AviSynth 2.0.6 version from MeGUI.

Originally Posted by Natty

damn i gave you a short example already but i think you ignored it. i would recommend you to forget HBD and just stick to lsb (dither tools).
HBD is too slow to encode anyways. except the case of f3kdb neo.

I didn't ignore it I even tried it but seems you ignored it my post.

Originally Posted by dREV

I've tried what Natty posted but didn't work. https://forum.doom9.org/showthread.p...21#post1884721

As I've already wrote and writing it yet once again I specifically wrote that the concept of "To" and "From" does not exist for a person like myself whose been using lsb hack for a long time especially since they are AviSynth+ exclusive which I came from using AviSynth 2.0.6 32 bit version trying to transition to 64 bit. and my mindset was set on this. Your example didn't help me get over this hurdle whatsoever as I thought there was going to be a 1:1 transition not a 1:2, I need issue resolving my issue not what you insinuate nor what makes it look I'm intentionally doing something I'm not. Note also you posted your example AFTER real-finder was helping me on getting HBD to work with his Gradfun3mod + edi_rpow2 function.

Your example was NOT going to help me regardless especially since I'm not even using a simple resizer as your example shows as I've been only using an advance function as I'm certain you've seen it by now and it was NOT working despite not being the one who made that function. I was using what I was being supplied with.

And from what I'm getting seems I have to do this 2 x for EACH function (before and after) that supports HBD. HBD is slow? real.finder keeps saying it's faster then lsb? I haven't tested it obviously but I'll find out.

Originally Posted by real.finder

that wrong, dither_convert_8_to_16() is kinda mean ConvertBits(16) in HBD, ConvertToStacked mean Convert HBD clip to Stacked clip to use it in old filters that not work with HBD yet but work with lsb (Stacked), and GradFun3mod (even my edit of it) not work with HBD, but my edit of DebilinearM work with HBD

OK to let this be over with I was doing my testing based on a non-HBD resizer function that I was supplied with to use and ONLY after I was told different with Gradfun3mod + edi_rpow2 all while I was trying to get the next 16 bit filter to work and it was not working and this was using ConvertBits(8). Look through all of the posts since I started to post back to page 13 and keep in mind this is centered around the the resizer > then everything else. So if you've mocked me and had in mind that I was stupid in your heart know where I was at combined with my post that getting simple plain English from doom9 is out of reach in addition that this HBD is 2 x (To and From) functions now instead of lsb hack which was a simple dither 8 to 16, dither post, and dither out. Very plain and easy.

Originally Posted by real.finder

detail loss in my edit of nnedi3_resize16? post your script with video sample, and are you use the last nnedi3 plugin? did you try set nlsb to false?

I've already laid out what it was. I already wrote everything is using the same filters except your NNEDI script only and it's using lsb hack. It instead uses the original NNEDI3. The nnedi3 plugin I'm using is version 0.9.4.51 and no I did not set nlsb I didn't know that existed as that's not in the original.

I have tested it putting nlsb off and there was no change. Note that I'm only using lsb functions and may just stick to it.

Originally Posted by real.finder

Dither_out and ConvertFromDoubleWidth FOR YOUR x264 Borders problem IF you still using the lsb/Stack16 things not if you use 8bit or HBD

in HBD ConvertBits(bits=8, dither=-1) is DitherPost(mode=-1) equivalent, don't know if you know but you don't need ConvertBits(bits=8) just for avspmod, it work with HBD nowadays

btw, I did many edits for http://avisynth.nl/index.php/ConvertStacked and added another example for lsb

My AddBorders() issue and my posts here are two entirely different matters. I'm not really certain what you're talking about on this at all because if you read the script I used on my issue for the AddBorders you'd see me using Dither_out https://forum.doom9.org/showthread.p...83#post1884083 if it's something else then clarify as I don't understand if you trying to help me fix my issue with AddBorders in h264.

Originally Posted by real.finder

dREV has many problems so I'm not surprised of ignored or not note it, but anyway it's also in wiki and in my posts but seems dREV still don't get the point of these functions/examples

So which is it? Ignored or note it or something else? Even when I state my reasoning and my confusion my post gets blatantly ignored. So whose really ignoring or not noting?

Writing this post was almost a complete waste of time having to explain myself YET again but what I won't be is surprised that it gets ignored.

[real.finder]

you said

I'm having some issues with your MAA2 script and ConvertBits.

ConvertBits = HBD things, so how you then said "I never wrote that I did this using HBD."?!

Dither_out() output clip same as ConvertToDoubleWidth() BUT not same input clip and usage

those "HBD is 2 x (To and From) functions" not for pure HBD and that should be something very clear, THEY are for mixing HBD and lsb if you didn't find updated or alternative filter for YOUR lsb Favorite filter, in pure HBD case you dont need any thing (even ConvertBits if your source already more than 8 bit) mean you deal with it as 8bit clip most of times

I didn't get what you get with nlsb=false, but with nlsb=false both my edit and the original will be same unless there are bug

============================

the Reply to dREV end here

=================

@Natty, 16bit process should be slower than 8bit, that normal, and finedehalo don't has lsb in first place

@everyone

I plan to change many things, move the avs versions functions to independent script, and move the General functions to another independent script and start using github as replacement for pastebin and doom9 Attached, and there will be many updates for filters, all this after pinterf add the changes that I waiting for

[dREV]

I think I've finally got it down mixing ConvertBits() and LSB and Convert To and [b]From[/] Stacked but the only issue I have now is understanding when to use ConvertToDoubleWidth(). Is this only only for HBD filters or something? The link http://avisynth.nl/index.php/ConvertStacked seems to point that it is and just need a confirmation if this is true. I only know the one to end the HBD stacked which as I wrote before being ConvertFromDoubleWidth().


In another matter, as I wrote before about your NNEDI3 script having less quality then the 32 bit counterpart of a previous version of NNEDI3 there's another issue that I came about when it came to encoding.

Using my script combined with ConvertBits(16) and ConvertToStacked() and your NNEDI3 script it takes over 6 minutes for the encoder to prepare the encode and when it's ready the fps is slooooow and I mean sloooow 1-5 fps and I am on a Ryzen 5 2nd generation. I don't think it's at my end that's the issue.

I thought maybe I had the wrong ResampleMT.dll and/or NNEDI3.dll but I read Ryzen seems to supports AVX2 (I even tried the others too with the same results tho) but then I changed the NNEDI3 script to a previous version one from 2017 and 2015 (one of several other versions I have too) and it ran like normal, super quick like it should be and started to encode in less than 30 seconds. I even tried without any HBD stacked and just using LSB and still had the same issue.

Keep in mind as I wrote before this script by itself is the culprit as I've narrowed it down one by one just as I did before. Something is very wrong with it besides just not being the same quality as the one I've been using on my 32 bit filters only to surpass it but only with the help of stacked. I used both versions of MeGUI 32 bit and 64 bit versions using the latest HEVC encoder https://forum.doom9.org/showthread.p...62#post1884762. I dunno why the latest NNEDI3 script works just fine on avspmod but not on the encoder they both are using literally the same script chain.

Here are all of the scripts so you can see for yourself. I even included both 32 and 64 bit AviSynth plugins for easy drag/drop testing to see yourself and replicate it tho I dunno what GUI you use as I am exclusively using only MeGUI plus I included my actual scripts tho only for 720p.

They are in .rar format using WinRar 5.71 http://www.mediafire.com/file/xvceiy...ple01.rar/file.

In all honesty it may not be your NNEDI3 script alone for the small loss in quality (tho with stacked HBD it terms of file size png images has become more then the 32 bit but only on avspmod doing a few comparisons) but may also be in part to ResampleMT.dll and NNEDI3.dll being ports to the 64 bit not done by the original creator. I would have to do more comparisons cuz seems I am using three to four versions of the NNEDI3 scripts. I always thought the 64 bit version is suppose to be better then the 32 bit.

Also, I think putting it up on GitHub is a good idea as it'll be easier to get a previous version if something goes wrong with the latest update like what's happening with the NNEDI3 script.

[real.finder]

as the link said in notes, DoubleWidth is another kind of hack using 8bit clip to convey 16bit by make it Double Width, it's also mentioned here http://avisynth.nl/index.php/Dither_tools#Formats

I will not repeat what I said before about how lsb things like nnedi3_resize16 use 8bit many times and why sometimes seems faster (all that in my Replies to Natty), anyway saying "less quality" when nnedi3_resize16 try give you real 16 bit as possible mean it's better for you to stay with 8bit Especially in your scripts seems you get rid of most if not all benefits of 16bit whether it's lsb or HBD by going to 8bit many times, and I didn't see you use nlsb=false with last nnedi3_resize16 in your scripts

x64 (64 bit) not always give same output as x86 (32 bit) but x64 should be faster (not always), It depends on the plugins (dll) and the asm code in it and the cpu, if you have problem (like big difference in output with same scripts "both avs and avsi") then you should report that in the plugins threads not here

and the output of encoders is also another topic, here you should just use avspmod, and for me the output of nnedi3_resize16 (without nlsb=false) has more quality (details and sharp) but half speed

[Natty]

thanks for n3_r16 update, i see nlsb is for hbd + lsb

so if i set nlsb=true, lsb=true, lsb_in=true, the output will be real 16bit stacked (better than before)?

and default value of dither is 50.which dithering method does 50 use?

[real.finder]

Originally Posted by Natty

thanks for n3_r16 update, i see nlsb is for hbd + lsb

so if i set nlsb=true, lsb=true, lsb_in=true, the output will be real 16bit stacked (better than before)?

and default value of dither is 50.which dithering method does 50 use?

the letter "n" for Native, which mean hybrid (Native HBD and lsb) kinda like what I did for YUY2 support in avs26 by using YV16 inside the functions as stopgap since (at least back then) not many filters updated to support YV16 and in the same time YUY2 removed from the updated one

and yes it will better than before, aside from that I did also added nlsb in admfilter while ago (before add it in Nnedi3_resize16) for Motion-Compensated and also true by Default in avs+

and from the scripts itself the default values of dither are

dither   = tv_range ? Default(dither, 6) : Default(dither, 50)    # dither mode for 16-bit to 8-bit conversion

and in nnedi3_resize16_U16

    dither   = Default(dither,   -1     ) # -1 for no dither, 0 for ordered-dither, 1-100 for noise strength

and you can read the Documentation of SmoothAdjust since it used when full range (DitherPost used in tv range)

[Natty]

thanks for explaining. but i still don't know what method will dither=50 use. maybe it's just the strength of noise

and will output be correct is this case?

ConvertBits(16)
ConvertToStacked()
nnedi3_resize16(mysettings, nlsb=true,
lsb_in=true, lsb=true, tv_range=true)
Dither_convert_yuv_to_rgb(matrix="601", output="rgb48y", tv_range=true, lsb_in=true)
r = SelectEvery(3, 0)
g = SelectEvery(3, 1)
b = SelectEvery(3, 2)
Dither_convert_rgb_to_yuv(r, g, b, matrix="709", tv_range=true, lsb=true)
HQDeringmod(lsb_in=true, lsb=true, lsb_out=true, tv_range=true)
ConvertFromStacked()

[real.finder]

Originally Posted by Natty

thanks for explaining. but i still don't know what method will dither=50 use. maybe it's just the strength of noise

and will output be correct is this case?

ConvertBits(16)
ConvertToStacked()
nnedi3_resize16(mysettings, nlsb=true,
lsb_in=true, lsb=true, tv_range=true)
Dither_convert_yuv_to_rgb(matrix="601", output="rgb48y", tv_range=true, lsb_in=true)
r = SelectEvery(3, 0)
g = SelectEvery(3, 1)
b = SelectEvery(3, 2)
Dither_convert_rgb_to_yuv(r, g, b, matrix="709", tv_range=true, lsb=true)
HQDeringmod(lsb_in=true, lsb=true, lsb_out=true, tv_range=true)
ConvertFromStacked()

you should ask the original Author about it, anyway I told you to read the Documentation of SmoothAdjust

dither [default: 75]
    --------------------
     Type of the dithering
     -1  = dithering OFF
     0   = pattern
     xx  = intermediary
     100 = noise

and I think if you use 50 with tv range you will get error from DitherPost

and what you mean by correct? real 16bit? if it so then I don't think so since I think HQDeringmod is also used some 8bit mix with lsb, and since I don't use it and it's kinda big script (I guess) I don't think I will touch it at least soon, so anyone can feel free edit it

edit: and what is the point of Dither_convert_yuv_to_rgb and Dither_convert_rgb_to_yuv? you can use avsresize aka z_ConvertFormat which work with HBD and faster and even has many new things and did the job better

[Natty]

i have read smoothadjust docs .))

point was to convert 601 to 709.

ok I'll try z_ConvertFormat too.

[LouieChuckyMerry]

Hi real.finder, I hope you're well . Some months ago you helped me upgrade from x86 AviSynth+ with SMDegrain LSB to x64 AviSynth+ with SMDegrain native HBD, which almost doubled my encoding speed. . Recently I encountered a situation where the encoding speed is much much much slower and I hoped you'd have a solution. The following script with a 1080p source took about 1.5 hours for the first pass and 2.5 hours for the second pass:

SetMemoryMax(1024)
SetMTMode(3,3)
LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetMTMode(2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
LinearResize(1280,720,Kernel="Bicubic",A1=-0.5,A2=0.25,LSB_In=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,LSB_In=True,LSB=True)
Dither_Out()

however, the following script takes almost 12 hours just for the first pass (I've not bothered with a second pass):

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

Do you have any idea why the native HDB script takes eight times longer? Thanks for your time.


EDIT: OK. A bit of searching and testing later, it seems that EDI_RPow2 is designed for upscaling, not downscaling. Could you please recommend a filter-plugin for downscaling in native HBD? Thanks.

[real.finder]

Originally Posted by LouieChuckyMerry

Hi real.finder, I hope you're well . Some months ago you helped me upgrade from x86 AviSynth+ with SMDegrain LSB to x64 AviSynth+ with SMDegrain native HBD, which almost doubled my encoding speed. . Recently I encountered a situation where the encoding speed is much much much slower and I hoped you'd have a solution. The following script with a 1080p source took about 1.5 hours for the first pass and 2.5 hours for the second pass:

SetMemoryMax(1024)
SetMTMode(3,3)
LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetMTMode(2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
LinearResize(1280,720,Kernel="Bicubic",A1=-0.5,A2=0.25,LSB_In=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod(Strength=24)
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,LSB_In=True,LSB=True)
Dither_Out()

however, the following script takes almost 12 hours just for the first pass (I've not bothered with a second pass):

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

Do you have any idea why the native HDB script takes eight times longer? Thanks for your time.


EDIT: OK. A bit of searching and testing later, it seems that EDI_RPow2 is designed for upscaling, not downscaling. Could you please recommend a filter-plugin for downscaling in native HBD? Thanks.

I didn't have internet for almost a whole week ago, now is back but don't know if they will cut it again, anyway you can use ResizeX for downscaling

Regarding the slowing, you can back some pages ago here to know that not always HBD is faster since the lsb method in scripts most of times not real 16 bit process unlike the HBD but anyway I will check it later and see what is the bottleneck or why it's slow

[StainlessS]

Real.finder, I just posted about this in devs forum,
he's DOWNSIZING but using EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720), so 1080p source is first being upsized to 2160p and then downsized to 720p,
thats what is eating up time.

EDIT: Replace

EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)

with

Spline64Resize(1280,720)

EDIT: Ie,

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

To

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
Spline64Resize(1280,720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

EDIT: Also, quality is bound to have suffered due to the EDI upsize, then downsize, it was not necessary.

[LouieChuckyMerry]

Originally Posted by real.finder

I didn't have internet for almost a whole week ago, now is back but don't know if they will cut it again, anyway you can use ResizeX for downscaling

Regarding the slowing, you can back some pages ago here to know that not always HBD is faster since the lsb method in scripts most of times not real 16 bit process unlike the HBD but anyway I will check it later and see what is the bottleneck or why it's slow

The slowing was because I was ignorant to the fact that EDI_RPow2 is for upscaling only, as StainlessS states below, so please don't waste your time checking for a bottleneck. I hope your internet connection has stabilized .

Originally Posted by StainlessS

Real.finder, I just posted about this in devs forum,
he's DOWNSIZING but using EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720), so 1080p source is first being upsized to 2160p and then downsized to 720p,
thats what is eating up time.

EDIT: Replace

EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)

with

Spline64Resize(1280,720)

EDIT: Ie,

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

To

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
Spline64Resize(1280,720)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

EDIT: Also, quality is bound to have suffered due to the EDI upsize, then downsize, it was not necessary.

Thanks, StainlessS, for the acknowledgement of my ignorance. Now to the AviSynth+ thread...

[real.finder]

maybe EDI_RPow2 need some code to make sure it will not be used in downsize, but that will happen later (when pinterf back with the updates)

I note you use F3KDB, there are "Neo f3kdb" since F3KDB will stay only for old things

I hope your internet connection has stabilized .

last days we got worst Internet than PRC or even worst than DPRK since even the local sites not works, and when it back it's very slow without social media sites ofc, They even used snipers to confront young people demonstrating!

[Natty]

i see that aWarpSharp4xx has only 1 lsb switch. no lsb_in or out. will output be correct of 16bit stacked is feeded like aWarpSharp4xx(lsb=true)?