JPSDR Avisynth's plugins pack

[Groucho2004]

Ok, there is something odd indeed, thanks reporting. All the other filters seems to behave properly, but the resampler runs only on one core with SetAffinity set to true, which is totaly unexpected.
I have a rather basic question - What makes you think that messing with Windows' thread scheduler by manipulating thread affinity improves the speed? What if another program does the same? Have you measured the speed in different scenarios (various Windows versions, CPUs with Hyperthreading, software that messes with thread priority)?

[jpsdr]

What makes you think that messing with Windows' thread scheduler by manipulating thread affinity improves the speed?
Image is splitted horizontaly, so, for cache access, it may be better if contiguous zones are on the same physical core, no more, no less. If you don't have HT, less significant. That's what i think, and, yes, it's just a pure theorical thinking, didn't spend time to make all kind of test. (Wrote allready this in the part added in the 1rst post).
And, the threadpool i've used as exemple to make mine was even more restrictive, no choice, put each thread on one CPU only. I've expended that.
Nevertheless, this has nothing to do with Intel compiler messing the code...:sly:
But maybe it's also my fault, using /O3 may be too much experimental.

[TheFluff]

Image is splitted horizontaly, so, for cache access, it may be better if contiguous zones are on the same physical core, no more, no less.

u wot m8

it's random access memory, yeah?

[jpsdr]

LOL... Yes, the "Random" part means that you can directly access randomly to the data if you want, because the memory chipset/componant have an address bus allowing you to choose whatever memory data/case you want. Opposed to different kind of memory, which have for exemple only serial access, meaning that you can't directly access to whatever data you want without accessing to others before.

So... What this has to do with the fact that the memory zone you're working on can eventualy fit in the cache ?

[jpsdr]

Intel version trashed, no difference between /O2 or /O3. File updated, redownload it.

[jpsdr]

Some bench tests :

Script :

Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)


Result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 1080 | 1315 | 1293
Memory usage (phys | virt): 47 | 44 MiB
Thread count: 41
CPU usage (average): 81%
Efficiency index: 15.96

Time (elapsed): 00:00:07.736


SetAffinity=false, result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 1050 | 1372 | 1173
Memory usage (phys | virt): 47 | 45 MiB
Thread count: 41
CPU usage (average): 69%
Efficiency index: 17.00

Time (elapsed): 00:00:08.527


Script :

Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
aWarpSharp2(SetAffinity=true)


Result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 165.6 | 270.2 | 239.8
Memory usage (phys | virt): 60 | 60 MiB
Thread count: 41
CPU usage (average): 84%
Efficiency index: 2.854

Time (elapsed): 00:00:41.707


SetAffinity=false, result :

[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 170.4 | 271.0 | 207.2
Memory usage (phys | virt): 60 | 60 MiB
Thread count: 41
CPU usage (average): 67%
Efficiency index: 3.092

Time (elapsed): 00:00:48.270


Script :

Colorbars(width=1920,height=1080,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,4)
nnedi3(dh = true, nsize = 3, nns = 4, qual = 2,pscrn=0,threads=0,SetAffinity=true)


Result :

[Runtime info]
Frames processed: 5 (0 - 4)
FPS (min | max | average): 0.431 | 0.433 | 0.432
Memory usage (phys | virt): 49 | 53 MiB
Thread count: 41
CPU usage (average): 97%
Efficiency index: 0.00446

Time (elapsed): 00:00:11.569


SetAffinity=false, result :

[Runtime info]
Frames processed: 5 (0 - 4)
FPS (min | max | average): 0.379 | 0.403 | 0.392
Memory usage (phys | virt): 49 | 52 MiB
Thread count: 41
CPU usage (average): 87%
Efficiency index: 0.00451

Time (elapsed): 00:00:12.741


Is it what can be called empirical evidence ?

Nevertheless, doesn't mean it will be like this for everybody. This is why everyone can tune according his results.

[Atak_Snajpera]

Still something is not right. I used dll from Release_W7 folder.
SetAffinity=true (it is even slower than before ;)
http://i.cubeupload.com/85WwtN.png

SetAffinity=false
http://i.cubeupload.com/HsGCFa.png

[TheFluff]

LOL... Yes, the "Random" part means that you can directly access randomly to the data if you want, because the memory chipset/componant have an address bus allowing you to choose whatever memory data/case you want. Opposed to different kind of memory, which have for exemple only serial access, meaning that you can't directly access to whatever data you want without accessing to others before.

So... What this has to do with the fact that the memory zone you're working on can eventualy fit in the cache ?

Say that you read a megabyte of framebuffer data from RAM into CPU cache and do some work on it. You then want to read some other megabyte of framebuffer data to CPU cache and do some work on that. What, to you, implies that the second memory-to-cache transfer would be affected by the previous one?

I find "benchmarks are, like, just your opinion, maaaan" to be an exceptionally poor argument, by the way. Your results compared to Atak_Snajpera's ones seem to imply that your implementation doesn't actually work, or at least doesn't do what you think it does. Heavens above know what you're even benchmarking.

e: to just quickly restate the argument about cache locality in resizers: recall that most resizers are separable filters which work by moving a sampling window over the input image one dimension at a time. Where do you see the potential for great time savings in the form of cache hits in this, exactly?

[jpsdr]

@Atak_Snajpera

Can you provide yours results with both true/false for just the following script :


Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)


No need to bother with pictures, just paste the [Runtime info] from the log file, it should be easier and faster for you.

[jpsdr]

Heavens above know what you're even benchmarking.

The script are provided, so, if looking at them it's impossible to say what is benchmarked, i indeed don't know what to do more.

About cache, i'm just saying that if you have 8 physical CPUs with 8 threads workings each one on 1/8 of 1Mb frame and each thread on a different CPU, there is more chances that the working memory zone of each threads will totaly fit and stay within the cache during the whole process, than if you have 8 threads working each one on a full 1Mb frame.
No more, no less.

[TheFluff]

The script are provided, so, if looking at them it's impossible to say what is benchmarked, i indeed don't know what to do more.
That's not what I mean. You're arguing that your setAffinity thing is improving performance by improving the CPU cache hit ratio. You then provide a measurement that is supposed to be supporting this argument. I can't say what your benchmark is actually measuring since I don't know where the bottleneck actually is, but it's definitely not CPU cache hit ratio, and since your implementation appears to give drastically different results for other people I suspect the implementation doesn't do what you think it does. Even if it did improve performance consistently, the measurement would still not be saying anything about CPU cache hit ratio.

About cache, i'm just saying that if you have 8 physical CPUs with 8 threads workings each one on 1/8 of 1Mb frame and each thread on a different CPU, there is more chances that the working memory zone of each threads will totaly fit and stay within the cache during the whole process, than if you have 8 threads working each one on a full 1Mb frame.
No more, no less.
Again, why do you think this is advantageous? Consider a trivial case: we're downscaling an image 2x in both directions with pointresize. Each destination pixel will only sample two input pixels per pass (horizontal/vertical) and they never get reused after that. Pretty much all you need is to fit a single scanline in cache.

[Atak_Snajpera]

@Atak_Snajpera

Can you provide yours results with both true/false for just the following script :


Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)


No need to bother with pictures, just paste the [Runtime info] from the log file, it should be easier and faster for you.

true
AVSMeter 2.2.6 (x64)
AviSynth+ 0.1 (r2580, MT, x86_64) (0.1.0.0)
Loading script...

Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 140.6 | 408.9 | 342.0
Memory usage (phys | virt): 35 | 30 MiB
Thread count: 33
CPU usage (average): 81%

Time (elapsed): 00:00:29.236

false
AVSMeter 2.2.6 (x64)
AviSynth+ 0.1 (r2580, MT, x86_64) (0.1.0.0)
Loading script...

Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 214.8 | 412.9 | 362.1
Memory usage (phys | virt): 35 | 30 MiB
Thread count: 33
CPU usage (average): 85%

Time (elapsed): 00:00:27.614

It works with colorbars. I think You should start testing with some real footage like me. (3840x2160 HDR + crop + resize).
Summary. Messing with affinity makes zero sense.

[jpsdr]

Something is strange.
You have here, as expected, 33 threads : 1 + 16 from avs+ + 16 from internal multi-threading.
In your previous posts, you have 49 threads, so 16 more. They could be explained if you have added prefetch(16) in your script, but it's not the case. I'm wondering where they are comming from...
I'll make some tests at home with a file.

[Atak_Snajpera]

You do realize that ffms decoder spawns additional threads? Those extra 16 threads are basically from decoder.

#VideoSource
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\ffms\ffms_latest\x64\ffms2.dll")
video=FFVideoSource("E:\_Video_Samples\mkv\Passengers_2016_4K.mkv",cachefile = "C:\Temp\RipBot264temp\job1\Passengers_2016_4K.mkv.ffindex")

[jpsdr]

Yes, of course !

And i have also the same things in these results :


[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 21.43 | 192.1 | 153.3
Memory usage (phys | virt): 92 | 102 MiB
Thread count: 61
CPU usage (average): 46%

Time (elapsed): 00:01:26.106

[Script]
a=AviSource("Dark_Crystal_HDR.avi",False,"YV12")
b=a+a+a+a+a+a+a+a+a+a+a
c=b+b+b+b+b+b+b+b+b+b+b+b
Spline36ResizeMT(c,1920,1080,SetAffinity=true,threads=0)



[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 21.30 | 185.2 | 149.0
Memory usage (phys | virt): 92 | 102 MiB
Thread count: 61
CPU usage (average): 40%

Time (elapsed): 00:01:28.569

[Script]
#SetMemoryMax(192)
a=AviSource("Dark_Crystal_HDR.avi",False,"YV12")
b=a+a+a+a+a+a+a+a+a+a+a
c=b+b+b+b+b+b+b+b+b+b+b+b
Spline36ResizeMT(c,1920,1080,SetAffinity=false,threads=0)



[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 47.03 | 186.4 | 173.7
Memory usage (phys | virt): 306 | 478 MiB
Thread count: 49
CPU usage (average): 16%

Time (elapsed): 00:01:15.980

[Script]
DGSource("DCrystal.dgi",i420=false,deinterlace=0,fieldop=0).trim(0,13199)
Spline36ResizeMT(1920,1080,SetAffinity=true,threads=0)



[Clip info]
Number of frames: 13200
Length (hh:mm:ss.ms): 00:09:10.550
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

[Runtime info]
Frames processed: 13200 (0 - 13199)
FPS (min | max | average): 54.67 | 180.2 | 172.9
Memory usage (phys | virt): 306 | 478 MiB
Thread count: 49
CPU usage (average): 14%

Time (elapsed): 00:01:16.342

[Script]
DGSource("DCrystal.dgi",i420=false,deinterlace=0,fieldop=0).trim(0,13199)
Spline36ResizeMT(1920,1080,SetAffinity=false,threads=0)

As i've said, it seems that sometimes you need to tune for yourself, what's good for one, is not always good for another.

[jpsdr]

Again, why do you think this is advantageous?
I'll clarify my thought : It may be, not it will be. Also, don't focuss only on resampler, maybe there is different filters on which it could be more efficient.
And again, if what is good for me is not for you, there is no issue, because you can change it. It's not like it's forced and you don't have the choice.
As they are my builds, i set the default settings to what give me the best results for my use case, so i play selfish, to not have to adjust for myself...:p.

[Atak_Snajpera]

As i've said, it seems that sometimes you need to tune for yourself, what's good for one, is not always good for another.
SetAffinity should be disabled by default. There is more trouble than benefit. Speed increase in your example is less than 3%.

[jpsdr]

Sorry, but for now, i'll keep it this way.

[real.finder]

after I update for the last resample I note there are some slow and after I see Atak_Snajpera posts here I decided to test with avsmeter


SetAffinity test

old cpu (2010) on old windows
https://s9.postimg.org/ghr0nsvan/image.png

new cpu (2014 maybe not really new) on new windows
https://s9.postimg.org/g4zmhn067/image.png

both said there are problem in SetAffinity in last update, the previous version was fine https://forum.doom9.org/showpost.php?p=1831560&postcount=41

[jpsdr]

Argh... Two against one...:scared: This is begining to be harder. Why am i the only one where it works differently...:confused:
I know !!! It's a conspiracy ! Ah... I knew the earth was indeed flat !
Out of curiousity, what is your script ?

[Groucho2004]

Why am i the only one where it works differently...:confused:Maybe your Broadwell 10/20 core CPU behaves differently compared to the CPUs that we mere mortals use?

[jpsdr]

Maybe your Broadwell 10/20 core CPU behaves differently compared to the CPUs that we mere mortals use?
Ah... That's it of course... Poor low mortals...:cool:

[Atak_Snajpera]

I can also confirm that previous version 2.0.5 worked ok (or was bugged and was always false) with default setaffinity=true.
SetAffinity is useless because:
1) Unpredictable performance for many users.
2) Extremely tiny speed boost for users with specific CPU (Broadwell). Furthermore that extra 3% will be most likely further "eaten" by other filter or procces (x264/x265)
3) has to be disabled when prefetch is used in script

SetAffinity=true as default setting is NOT optimal. Period!

[real.finder]

Argh... Two against one...:scared: This is begining to be harder. Why am i the only one where it works differently...:confused:
I know !!! It's a conspiracy ! Ah... I knew the earth was indeed flat !
Out of curiousity, what is your script ?

I used this

Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Spline36ResizeMT(1920,1080,SetAffinity=true)

[jpsdr]

New version, see first post, updated also the Multi-treading text part.

[jpsdr]

New version, see first post.

[FranceBB]

Updated, thank you! :D

[jpsdr]

New version, add HDRTools, see first post.

[jpsdr]

Slipstreamed a new build/file. There is no change in the code, so it's not a new version.
I've realised that i didn't put the documentation of the plugins in this package, and if you wanted the documentation you also needed to download each plugin version, which is not very convenient (and not smart from my part). So, i've added in the release file the documentation of each plugin.
I took the opportunuity to make new builds with the last Visual Studio release, and also put back the Intel Compiler builds.

[jpsdr]

New version, see first post.

[FranceBB]

New version, see first post.

Thank you Jean-Philippe, but what does ThreadLevel do and how should we use it?

[ryrynz]

what does ThreadLevel do and how should we use it?

from the readme.

ThreadLevel - This parameter will set the priority level of the threads created for the processing (internal multithreading). No effect if threads=1.

1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)

Default : 6

[FranceBB]

from the readme.

ThreadLevel - This parameter will set the priority level of the threads created for the processing (internal multithreading). No effect if threads=1.

1 : Idle level.
2 : Lowest level.
3 : Below level.
4 : Normal level.
5 : Above level.
6 : Highest level.
7 : Time critical level (WARNING !!! use this level at your own risk)

Default : 6

I see, so now we're also able to set the level for the specific thread used by the plugins like when we manually modify the priority on Windows for a specific process.
That's kinda nice, thank you. :)

Tested and working on Windows XP, however, as the other previous releases, XP SSE4.2 produces a code that is not compatible with Windows XP: Link (https://i.imgur.com/DXZTQEF.png)
It's looking for the function libm_sse2_exp2 inside LIBMMD.DLL for whatever reason and it doesn't work.
As to the SSE2 one, it works, as always: Link (https://i.imgur.com/oZ5wsTA.png)

Thank you again anyway,
Frank.

[jpsdr]

New version, see first post.

[jpsdr]

I've messed-up on resampler my files management between my VS versions, commited but not pushed, result the build was made with only some parts of the fixes (but still the output was not bad or incorrect).
If you see this post and have already downloaded the 3.1.2 version, re-download it, and sorry for the inconvenience.

[dREV]

Hello, I been trying to transition from using megui 32 bit to megui 64 bit with avisynth+ 64 bit in the hopes of seeing a speed increase during encode and slowly looking for the 64+ filters equivalents but having problems with this plugin.

My problem is the debilinear and debicubic and am I reading correct that this is essentially is an update to that plugin with multi-threading and a 64+ version as I don't see any 64 bit version plugin for this filter. As far as I am aware this is the only for that exists.

http://avisynth.nl/index.php/Debilinear
http://avisynth.nl/index.php/Debicubic

The issue I am running into is that it doesn't have the code "bool lsb_inout" and its telling me when I use another script called DebilinearM found here (https://twitter.com/desbreko145/status/492482320079663104). On AvsPmod 64 bit states "script error: DebilinearResizeMT does not have a named argument "lsb_inout" (path DebilinearM_v1.3.1.avsi, line 67) (New File, line 82)".

As another user wrote the nnedi3_resize16 code works just fine with the lsb's for it which I use and need to make the change so I thought maybe this was an oversight. But both Debilinear and Debicubic don't seem to work and are missing the "lsb_inout" argument as I also used DeBilinearResizeMT by itself without the additional script above and it did not work with lsb_inout input. Not sure if DebilinearY and DebicubicY work, can this be confirmed?

I used the one in the x64\Release_W7_AVX2 folder for this as I think I'm suppose to use this for my Ryzen 5 machine.

Also, off topic is there a EdgeCleaner 64 bit version for avisynt+ same for warpsharp? I only been using http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

[jpsdr]

The "Dexxxx" versions are included within the ResampleMT, read the doc of it, and read also here (https://forum.doom9.org/showthread.php?t=174846).

They are not an upgrade/update of the previous version, they do the same thing, but they are totaly rewritten from scratch, and there is no intended link between the parameters with my version and the original version. If some parameters between both version happen to have the same purpose, it's just by luck.
So, yes, there is no lsb_inout parameter in my version.

[dREV]

Thanks for replying. I've read the documentation several times which is why I thought it was strange that the nnedi3_resize16 lsb's work as intended and thought perhaps the Debilinear and Debicubic missing these parameters were simply oversights in addition the documentation advice to work in 16 bit or float. Also, another one using IResize with success.

Maybe I'm just misunderstanding. I'm trying to understand.

Quality improvement tip
There is the accuracy parameter, but another way to eventualy improve the quality is to increase the bit depth if you're using avs+. If you are in 8 bits, the resampler compute using integer rif parameters converted from the float rif parameters. But, if you are in bit depth>8, the resampler uses the float coefficients. In desampling cases, where rif size can easely be of 40 or 50, if you're trying to be the most accurate, i would advise to increase the bitdepth to 16 (or even to float if you're searching for ultra accuracy) just for the desampling filter.

Maybe there's another method to this that I'm not aware of as I use dither_convert_8_to_16() parameter to go into 16 bit. How would this be accomplished without lsb when using Debilinear or Debicubic together with the documentation quote above? I'm enticed about this ultra accurate thing to play around with if it does indeed improve the quality.

Perhaps give an example if you don't mind on how to apply this 16 bit as I am not seeing it. Essentially, I'm trying to get this to work in a 16 bit field using the DebilinearM script as mentioned in my previous post.

Since you mention that you don't have the original code asking if this function could be implemented maybe asking too much. Therefore, I have to ask if you are aware of any other Debilinear plugins available for avisynth+? Maybe I am not looking hard enough but I just do not see them. I might have to give VaporSynth a look if there is none.

[real.finder]

have a look here http://avisynth.nl/index.php/AviSynth%2B#Deep_color

[jpsdr]

It's possible that this :

#For exemple, if the source file is a 1280x720 8 bits video :

Spline36ResizeMT(1920,1080,src_left=-0.2)
# or Spline36Resize(1920,1080,src_left=-0.2)
# To revert :
ConvertBits(16)
# or ConvertBits(32)
DeSpline36ResizeMT(1280,720,src_left=-0.2)
ConvertBits(8) # If you want to revert back to 8 bits video


produces a more accurate result than this :

#For exemple, if the source file is a 1280x720 8 bits video :

Spline36ResizeMT(1920,1080,src_left=-0.2)
# or Spline36Resize(1920,1080,src_left=-0.2)
# To revert :
DeSpline36ResizeMT(1280,720,src_left=-0.2)


I don't see the point of having internal function within the filter to change bit depth, as they allready exist in the core.

[dREV]

have a look here http://avisynth.nl/index.php/AviSynth%2B#Deep_color

Thanks for the link. I had no idea about that I've usually stuck to the articles for original AviSynth. Together with what jpsdr wrote it worked by itself tho and there are issues. Which I will note below.

I don't see the point of having internal function within the filter to change bit depth, as they allready exist in the core.

This is intended to be an upgrade of the actual DeBilinear, working with all data formats of avs+, and having an x64 version. https://forum.doom9.org/showthread.php?p=1817097#post1817097 I thought I did read correctly the intention of this plugin to be an update to 64 bit and the oversight was correct but then I was corrected that it was not the case, so I like to ask if this is truly the case and that opinion from the quote above no longer holds true? The function only has 4 parameters.

The issue I ran into while it did work by itself given the code above I can't do anything about the sharpness of the source. I cannot soften that parameter so it doesn't look like jagged edges (this is with using anti-aliasing filter) and this is where DebilinearM comes into play. Found at the very bottom of http://avisynth.nl/index.php/Debilinear in the mediafire link. Using the thr parameter I can soften the amount of descaling sharpness thing it does on the very same source used in the testing for DebilinearResizeMT. /* DebilinearM v1.3.1

DebilinearM is a wrapper function for the Debilinear and Debicubic plugins that masks parts of the frame that aren't upscaled,
such as text overlays, and uses a regular ResizeX kernel to downscale those areas. It works by downscaling the input
clip to the target resolution with Debilinear or Debicubic, upscaling it again, comparing it to the original clip,
and masking pixels that have a difference greater than the specified threshold.

##### Requirements #####

Plugins:
Debicubic
Debilinear
Dither
MaskTools2

Scripts:
ResizeX

Color formats:
YV12
*/

function DebilinearM(clip input, int target_width, int target_height, int "thr", int "expand", int "inflate",
\ string "kernel", int "taps", float "a1", float "a2", bool "cubic", float "b", float "c",
\ bool "chroma", bool "lsb_inout", int "showmask") {

# Default settings and other variable assignment
thr = Default(thr, 10)
expand = Default(expand, 1)
inflate = Default(inflate, 2)
kernel = Default(kernel, "Spline36")
cubic = Default(cubic, false)
chroma = Default(chroma, true)
lsb_inout = Default(lsb_inout, false)
showmask = Default(showmask, 0)

Assert(target_width > 0, "DebilinearM: target width must be greater than 0")
Assert(target_height > 0, "DebilinearM: target height must be greater than 0")
Assert(thr >= 0 && thr <= 255, "DebilinearM: thr must be in the range 0 to 255")
Assert(showmask > -1 && showmask < 3, "DebilinearM: showmask must be 0, 1, or 2")

w = input.Width()
h = lsb_inout ? input.Height()/2 : input.Height()

uvint = chroma ? 3
\ : 1

# Resizing
input_8bit = lsb_inout ? input.DitherPost(mode=-1) : input

cubic ?
\ Eval("""
dbi = chroma ? input.Debicubic(target_width,target_height, b=b, c=c, lsb_inout=lsb_inout)
\ : input.DebicubicY(target_width,target_height, b=b, c=c, lsb_inout=lsb_inout)
dbi_8bit = chroma ? input_8bit.Debicubic(target_width,target_height, b=b, c=c)
\ : input_8bit.DebicubicY(target_width,target_height, b=b, c=c)
dbi2 = lsb_inout ? dbi_8bit.ResizeX(w,h, kernel="Bicubic", a1=b, a2=c, chroma=chroma)
\ : dbi.ResizeX(w,h, kernel="Bicubic", a1=b, a2=c, chroma=chroma)
""")
\ : Eval("""
dbi = chroma ? input.Debilinear(target_width,target_height, lsb_inout=lsb_inout)
\ : input.DebilinearY(target_width,target_height, lsb_inout=lsb_inout)
dbi_8bit = chroma ? input_8bit.Debilinear(target_width,target_height)
\ : input_8bit.DebilinearY(target_width,target_height)
dbi2 = lsb_inout ? dbi_8bit.ResizeX(w,h, kernel="Bilinear", chroma=chroma)
\ : dbi.ResizeX(w,h, kernel="Bilinear", chroma=chroma)
""")

rs = input.ResizeX(target_width,target_height, kernel=kernel, taps=taps, a1=a1, a2=a2, chroma=chroma, lsb_in=lsb_inout, lsb=lsb_inout)

# Masking
diffmask = mt_lutxy(input_8bit,dbi2, "x y - abs", U=uvint, V=uvint).mt_binarize(threshold=thr, U=uvint, V=uvint)
diffmask = showmask == 2 ? diffmask.DebilinearM_expand(expand=expand, U=uvint, V=uvint)
\ .DebilinearM_inflate(inflate=inflate, U=uvint, V=uvint)
\ : diffmask.ResizeX(target_width,target_height, kernel="Bilinear", chroma=chroma)
\ .mt_binarize(threshold=3, U=uvint, V=uvint)
\ .DebilinearM_expand(expand=expand, U=uvint, V=uvint)
\ .DebilinearM_inflate(inflate=inflate, U=uvint, V=uvint)

merged = lsb_inout ? Dither_merge16_8(dbi,rs,diffmask, u=uvint, v=uvint)
\ : mt_merge(dbi,rs,diffmask, U=uvint, V=uvint)

return showmask > 0 ? diffmask
\ : merged
}

# DebicubicM alias
function DebicubicM(clip input, int target_width, int target_height, int "thr", int "expand", int "inflate",
\ string "kernel", int "taps", float "a1", float "a2", float "b", float "c",
\ bool "chroma", bool "lsb_inout", int "showmask") {

return DebilinearM(input,target_width,target_height,thr,expand,inflate,kernel,taps,a1,a2,true,b,c,chroma,lsb_inout,showmask)
}


# Helper functions
function DebilinearM_expand(clip input, int "expand", int "U", int "V") {
return expand > 0 ? DebilinearM_expand(input.mt_expand(mode="both", U=U, V=V), expand-1)
\ : input
}

function DebilinearM_inflate(clip input, int "inflate", int "U", int "V") {
return inflate > 0 ? DebilinearM_inflate(input.mt_inflate(U=U, V=V), inflate-1)
\ : input
} I've tried to modify the script to use DebilinearResizeMT but I have almost zero knowledge on this and have had zero success.

My script involves the implementations of what's in image 02:

https://i.ibb.co/stQnHgD/Examp01-Debilinear-Resize-MT.jpg https://i.ibb.co/RBJSh3X/Examp02-Debilinear-M-thf0-1.jpg

Image 01 (left)(by itself) via AviSynth+ 64 bit
ConvertBits(32)
DeBilinearResizeMT(1280,720,accuracy=2)

Image 02 (right) via Avisynth+ 32 bit
dither_convert_8_to_16()
ly = DebilinearM(1280,720,thr=01,lsb_inout=true) # Debilinear
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out() It don't look so good. Both ConvertBits(16) and ConvertBits(32) I'm not knowledgeable enough on how to go about this method. That along with the problematic result of the jagged edges with DebilinearResizeMT. My ignorance in trying to place it within the YtoUV (on image 02) function turns horrid obviously to those who are more knowledgeable then I may see that.

The above script (at least from what I read from others) allows upscaling the chroma, I don't understand it myself but results on the quality of both the image and colors are better then simply by itself. I've also recently found another script that's even greater that requires both DebilinearM and Debilinear.dll with even more depth to detail, colors, and debanding.

Also, I don't understand why your code had src_left=-0.2 when I used it it did not match the source I had when taking screenshot. The image 02 doesn't do this as if it does it won't match my 1080p source and when I downsize it via avspmod and photoshop (where I do my comparisons from). I had read here on Doom9 that for chroma it's src_left=0.50.

Would it be possible to do the above with this plugin as is? From what I'm perceiving it may not be so. Sorry for having to repeat myself and sorry for the long post. If not I'll give VaporSynth a look as I don't want to waste your time anymore with my questions.

[jpsdr]

The code was just an exemple of what Dexxxx parameters must be, linked to the xxxx parameters.
Don't see any specific sense in the value themselve. I used src_left in the exemple, but it could has been any other src_xxx.

I'll update my post, as it seems it can lead to misunderstanding.

[real.finder]

here an update for DebilinearM https://pastebin.com/bS8s4Chn

ColorBars(width=1280, height=720, pixel_type="yv12")
BilinearResize(1920,1080)
dither_convert_8_to_16()
ly = DebilinearM(1280,720,thr=01,lsb_inout=true, DeResizeMT=true) # Debilinear
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

with this it will use dither resize, use it without lsb things to use DeXXXXXResizeMT

you need update ResizeX https://forum.doom9.org/showthread.php?p=1837361#post1837361

[dREV]

The code was just an exemple of what Dexxxx parameters must be, linked to the xxxx parameters.
Don't see any specific sense in the value themselve. I used src_left in the exemple, but it could has been any other src_xxx.

I'll update my post, as it seems it can lead to misunderstanding.

Oh, alright. I was going on the assumption that it was the default settings for that particular resize and alignment. Thanks for your reply.


here an update for DebilinearM https://pastebin.com/8zNJUDZw

ColorBars(width=1280, height=720, pixel_type="yv12")
dither_convert_8_to_16()
ly = DebilinearM(1280,720,thr=01,lsb_inout=true, DeResizeMT=true) # Debilinear
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50) #
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

with this it will use dither resize, use it without lsb things to use DeXXXXXResizeMT

you need update ResizeX https://forum.doom9.org/showthread.php?p=1837361#post1837361

Thank you for taking the time and sharing your update with all people and the example script that will help me out :thanks:. I'll test it out over the weekend (I hope) when I get some more time. I'm looking forward to finally using DebilinearResizeMT with DebilinearM. Will I be able to take advantage of the "accuracy" thing by default?

I also read all of the posts after the ResizeX link you gave above and I wanted to ask some questions to clarify if I understood it correct. But I think I should ask it over at your thread instead of here so I don't go off topic.

I also have another script that I briefly mentioned above that maybe you can help me understand why it adds artifact (not sure if that's the term for it) and another issue added with it that requires another color profile that may or may not conflict with one another with the "YV12" I see in your example script. If you don't mind that is once I play around with the filter.

[real.finder]

DebilinearM

new update for speed (in HBD only, will not see speed up in lsb)

[dREV]

Thanks. Made a post on your thread. https://forum.doom9.org/showthread.php?p=1879764#post1879764

[jpsdr]

New version, see first post.

[Patman]

Hi jpsdr,

pls update your plugin pack. I saw that you've updated HDRTools.

[jpsdr]

It's in process...

[Patman]

It's in process...Thx

Gesendet von meinem HMA-L09 mit Tapatalk