[jpsdr]

I've created a specific thread even if it will be implemented inside the ResampleMT dll, because i've thought it would be more appropriate. And if i didn't create a specific dll, it's because it's exactly the same thing, and just adding around 1% of code add the functions.

Download is on the ResampleMT dll page here.

The new functions are :
DeBilinearResizeMT
DeBicubicResizeMT
DeLanczosResizeMT
DeLanczos4ResizeMT
DeBlackmanResizeMT
DeSpline16ResizeMT
DeSpline36ResizeMT
DeSpline64ResizeMT
DeGaussResizeMT
DeSincResizeMT
DeSinSqrResizeMT (same parameters than DeGauss)
DeSincLin2ResizeMT (same parameters than Sinc, default param 15)
DeUserDefined2ResizeMT (Same parameters as BicubicResize)

Parameters are identicals to the resampling functions, except there is two others parameters at the end.

accuracy -
Will specify the accuracy used for the desampling.
0 : Average
1 : A little less than 0.
2 : A little better than 0.

Default: 0 (int)

order -
Will specify in what order the desampling will be done (process horizontal or vertical first).
0 : Automatic, will choose according the same method implemented in the core filters.
1 : Process vertical first.
2 : Process horizontal first.

Default: 0 (int)

So, syntax is :
DesampleFunction([parameters of ResampleMT],int accuracy,int order)

The usage is the following : You have to enter in the parameters exactly the same that have been
used for the original resampling, except the size of course, where you specify the original size you want back.

For exemple, if the source file is an 720x480 video :

Spline36ResizeMT(1280,720,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)
# or Spline36Resize(1280,720,src_left=17.2,src_width=680,src_top=-8.7,src_height=440)
# To revert :
DeSpline36ResizeMT(720,480,src_left=17.2,src_width=680,src_top=-8.7,src_height=440,accuracy=0,order=0)

This is intended to be a new version of the actual DeBilinear, working with all data formats of avs+, and having an x64 version. There is no intended link between the parameters of this new version and the old original. If some parameters happen to be identical, it's pure coincidence.


Now, a little explaination of how it works.

I'll note 'A the transpose matrix of A.
If X is your input line to resample, you can write the resampling method like this : Y=A*X.
Using the less square method, you can revert by the following method :
'A*Y='A*A*X
B = inverse_matrix ('A*A)
C = B*'A
We have X=C*Y.
So applying the matrix C, we can revert the resampling process.

Now, if in the A matrix, around 95% are 0.0 value (size of rif resampler is only around 3 or 4), it's absolutely not the same for the C matrix.

For exemple, in a case of reverting a 720 -> 1080 upscale, with an upscale rif filter of 4.
The scan in the lines of resulting matrix C showed that it will produce a rif size filter of 311.

This this where the accuracy parameter is used.

For the default value, 0, it will use what i would call "integer" precision.
In the filter, the integer values of the filter are converted with the following formula : int(0.5+f*16384).
So, if this result in 0, the coefficient in the C matrix is set to 0.0.
In our example, it will produce a rif filter of size 30.

With the value of 1, it will keep a 0.1% of precision. On each line of C, the max(abs(f)) is scanned, and any value lower than 0.1% of this max is set to 0. In our example, it will produce a rif filter of size 20.

With the value of 2, any value within C which abs()<1e-6 is set to 0. In our example case, it will produce a rif filter of size 41.

So, for a 720 data vector input [0, 1, 2, ..., 719] inside, "upscaled" to 1080 values, and then reduce back to 720 values, the results are the following :

accuracy 0 :
[-0.000209 1.000103 1.999724 3.000118 3.999680 5.000134
.... 714.983521 716.005859 716.983643 718.006226 718.985046]

accuracy 1 :
[-0.000512 1.003681 1.999033 3.004512 3.998633 5.005422
... 714.856384 716.323120 716.855835 718.331421 718.868530]
Rounded it's still good.

accuracy 2 :
[-0.000005 1.000017 1.999993 3.000018 3.999994 5.000021
... 714.999573 716.000732 716.999756 718.000977 718.999634]

Now, the order parameter.
This will set if the image of the video will be processed horizontaly first, or verticaly first.
If the value is 0, in automatic mode, the filter will figure out, according the internal avisynth core filter algorithm, in what order the image would have been processed by the original resampling, to do the oposite.
For example, if the original resampling would result in resampling horizontal first, then vertical, the filter in that case will do vertical, then horizontal.
Of course, if original resampling is not done by avisynth, you can't know for sure, this is why you can set the order to the filter, to check what produce the best result.

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.

WARNING !!!!
The init phase of the filter is very slow, it can take easely several seconds, and the bigger the picture is, the more it will take. If you don't even have SSE2 instructions, it may take several dozen of seconds !

So, in a standard filter chain doing :
Create,Constructor,getframe(n=0),getframe(n=1),getframe(n=2),...destructor, there will be no issue.
Now, if you are using something like ScriptClip, which works like this :
Create,Constructor,getframe(n=0),Destructor,Create,Constructor,getframe(n=1),Destructor,Create,Constructor, getframe(n=2),Destructor,...
It will be slow as hell !!! Avoid absolutely using it in this case.