Internaly multi-threaded resampling functions

[jpsdr]

New version, see first post (minor update).

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.
About the fix to perfectly match the avs+ output. It didn't produce bad or incorrect output before, just different.
The resize works by resizing horizontal and vertical. You can choose one of your own, but there is no specific rules that says if you should do H before V or the opposite. If you resize H before V, it will produce a different result than resizing V before H (except in float mode). Difference will be very small, and both results are proper results. Sometimes my filter wasn't doing the resize in the same order, so the result was different, but still proper. Now the results perfectly match.

[jpsdr]

I've messed-up 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 2.2.2 version, re-download it, and sorry for the inconvenience.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[jpsdr]

Even if i can just "quickly" merge (without building) DTL's PR, there still the small pinterf's fix i want also include before making a new build. But as the organisation of internal resample and my filter is slighty different, i have to spend a little time to see how to put it in mine, and for now, i'm focussing all of my few spare time on something else, so there will be no new build for a while.

[DTL]

As suggested made temporal build of pre-2.3.2 version if anyone interested in using/testing - see later post. Still only x64 binary (with minimum SSE2 CPU I think) because win32 produces some linker error about SAFESEH with my VS2015.

[jpsdr]

Ok, i try to guess english from my VS french version :
Project -> Property -> Linker -> Advanced -> "Image with exception...something"/the last setting -> SAFESEH:NO

And, as history shows, a new kernel function with the small pinterf fix will just be a 2.3.2...

[DTL]

Originally Posted by jpsdr

Ok, i try to guess english from my VS french version :
Project -> Property -> Linker -> Advanced -> "Image with exception...something"/the last setting -> SAFESEH:NO

Yes - this helps.

Renamed to 2.3.2 and upload new release to fork: https://github.com/DTL2020/ResampleM...ases/tag/2.3.2

[jpsdr]

New version, see first post.

[real.finder]

can UserDefined2ResampleMT simulate Dither_resize16 additional kernels?

also it will be nice if there are something like "MT_resize" that has all Dither_resize16 parameters so we can say goodbye to dither tools and it's lsb hacks

[jpsdr]

I don't know, DTL may answer, but the UserDefined is using bicubic if remember as core root, so it's not a totaly open function.

[DTL]

Originally Posted by jpsdr

the UserDefined is using bicubic if remember as core root,

No - it is pure sinc-based. Its kernel is just a sum of weighted sincs:

return c*sinc(x+2) + b*sinc(x+1) + a*sinc(x) + b*sinc(x-1) + c*sinc(x-2);

Where a=1 and b and c are user-defined weights. It can be expanded to any more number of members for better precision but for typical users it is hard to work even with 2 control params.

For experienced perfectionists or some scientific work may be added expanded version for example with 4 control members (UserDefined4ResizeMT(b,c,d,e) like

return e*sinc(x+4) + d*sinc(x+3) + c*sinc(x+2) + b*sinc(x+1) + a*sinc(x) + b*sinc(x-1) + c*sinc(x-2) + d*sinc(x-3) + e*sinc(x-4);

With expand filter support and other adjustments. It may look as Bicubic just because way of passing params from script to kernel-generation function was taken from BicubicResize and names b and c looks like not very bad, though names may be changed to other simple numbering like param1, param2 etc.

As I see from wiki-description: Dither_resize16 can also accept user-defined samples for kernel generation:

"impulse" Offers the possibility to create your own kernel (useful for convolutions). Add your coefficents in the string after “impulse”, separated with spaces (ex: "impulse 1 2 1"). The number of coefficients must be odd. The curve is linearly interpolated between the provided points. You can oversample the impulse by setting kovrspl to a value > 1.

But it uses linear interpolation between provided samples. So it may be separate request to jpsdr to add this as new resampler's kernel with some new function name.

As I think Dither-tools uses separate non-Avisynth resampler with many other params of kernel adjustments/tweaking. So if you use user-provided kernel in Dither-tools with other options it may be not very easy to port its resizer to ResampleMT.

"also it will be nice if there are something like "MT_resize" that has all Dither_resize16 parameters"

I think it mostly probably will require to port full Dither-tools resampling engine to use all these tweaking and adjustments params. Though may be possible to make some class to prepare kernel (from all that params) usable with ResampleMT/Avisynth resampling engine. Anyway it may require long work.

[real.finder]

Originally Posted by DTL

"also it will be nice if there are something like "MT_resize" that has all Dither_resize16 parameters"

I think it mostly probably will require to port full Dither-tools resampling engine to use all these tweaking and adjustments params. Though may be possible to make some class to prepare kernel (from all that params) usable with ResampleMT/Avisynth resampling engine. Anyway it may require long work.

yes it seems

there are vs port https://github.com/EleonoreMizo/fmtconv maybe it can help

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[DTL]

When trying to make a table of b,c coefficients of impulse kernel for UserDefined2ResizeMT I found something interesting:

Later I think there are many possible b and c combinations available for each power of LPF filtering and over/under shoot amplitude. Keeping 'far' ringing as small as possible. But for real practic it is good to have a table to start with. So I start to make table of b param in rows and 3 different columns for c - for no_overshoot, low, medium, and high.
But at the process of filling the table it shows no many valid combinations available for 'far' ringing as low as possible for each fixed 'b' or 'c' member.
Current table for b,c (and also a bit more precise b,c,d,e for possible UserDefined4Resize())

It can be used currently with UserDefined2ResizeMT(). I send e-mail to jpsdr with suggestion to add b,c version of this table to plugin documentation but not sure it e-mail received.

As table for b,c,d,e shows the practical not-far ringing self-windowing kernel fades quick enough so even e-member typically small differs from zero. Close to +-1LSB. Ofcourse it is for 8bit presicion integer. With very high precision float required number of members may be >10. But for many practical already distorted moving pictures it may be invisible.

So is the main idea of this findings:
The practically useful combinations of b,c (b,c,d,e) is not function of many arguments but looks like function of 1 argument (like b for example). So it is possible to hard-code the b,c,d,e = f(b) table with step like 5 and linear interpolation inbetween values and make separate named resize function of only 1 user-defined argument. As well as SinPowResize(), but that kernel uses attempt of analytic definition of required 'self-windowed low ringing' kernel. And now we have partially table-defined function with sinc internal interpolation as required for resampler.
Will try to make it.

Additional note: The finding above looks like only (mostly) valid for high downsampling ratios like 10:1 and more and (may be) for sources with good conditioning against ringing. For small downsampling ratios the lowest-ringing b,c (d,e) combinations be differs from the current designed table. But it require more investigations. For example if a source with already having some ringing is feed to the resampler. So to compensate the source ringing the different weights for sincs are required. So it not mean the current UserDefined2ResampleMT() will be complete obsolete after new named resizer is designed with only 1 argument and build-in table inside.

It may be also treated as 'self-weighted' kernel. Because it is quickly fades to zero and the real resampler's windowing with 'support' natural 'box window' do not cause additional kernel cutting and no additional Gibbs-effects may be of higher order. So may be possible name for new named resize function is SelfWeightedResize or SWResize to type less in scripting. Also because it very quickly fades to zero it should be fast enough in processing because it do not require large 'support' size for resampler engine. Speed will be close to current UserDefined2ResizeMT with fixed support=2. So new resizer may have speed/quality switch like using bc or bcde table and support =2 or 4.

[hello_hello]

I've been trying to debug a resizing function for so long I'm pretty sure my mind has gone, so I'm not certain this is real. Could somebody please tell me if this is real?

ResampleMT 2.3.4 (and 2.3.3) XP version.

Version.GaussResize(420, 520, src_left=0.0, src_top=0.0, src_width=-300.0, src_height=0.0)



Version.GaussResizeMT(420, 520, src_left=0.0, src_top=0.0, src_width=-300.0, src_height=0.0)



Version.GaussResize(420, 520, src_left=0.0, src_top=0.0, src_width=300.0, src_height=0.0)



Version.GaussResizeMT(420, 520, src_left=0.0, src_top=0.0, src_width=300.0, src_height=0.0)



Edit: Trying to discover why the ResampleMT resizers appear to be behaving themselves when used with one function but not another.
Version.ExtractR().GaussResizeMT(420, 520, src_left=1.0, src_top=1.0, src_width=-300.0, src_height=0.0)



This is also satisfactory, so maybe it's just an RGB thing?
Version.ConvertToYV12().GaussResizeMT(420, 520, src_left=1.0, src_top=1.0, src_width=-300.0, src_height=0.0)