LanczosResize vs. SplineResize

[DeathTheSheep]

The paper states that monotonically decreasing coefficient magnitutes with larger kernel lengths (tending to infinity!) gives less nth degree error.

So then what does "kernel" mean in this sense?

[Henrikx]

Perhaps this is also interesting for you.
ResizeTest : Upsize/Downsize by Selur
http://gleitz.info/wiki/index.php/We...ize-Filter_%3F
(German)
Testpicture (Downsize)
http://www.heise.de/ct/ftp/testbilder/kameras_0621/

[MfA]

Originally Posted by DeathTheSheep

So then what does "kernel" mean in this sense?

For each increase in length you add one extra cubic section on both sides of the kernel, an extra lobe so you will.

[DeathTheSheep]

Henrikx: Wow, these tests (especially upsizing the 'O') have managed to reaffirm my preference towards high splines.

MfA: I see...! Is this how you found the coefficients for your spline64 experimental plugin?

[MfA]

No, it's Wilbert who said he found out how they were calculated ... as I said before, the ones in the splineX filters are not these ones.

[DeathTheSheep]

Ah, sorry--must have missed that

[Wilbert]

No, it's Wilbert who said he found out how they were calculated ... as I said before, the ones in the splineX filters are not these ones.

That statement was a bit premature

My approach was to work backwards, see what conditions those polynomials satisfied and to recompute the weights of these polynomials.

As everyone can check (by differentiating the polynomials), for Spline16/36/64 the following conditions are satisfied (Spline_k^2):

wj(x) = aj* + bj*x + cj*x^2 + dj*x^3; x in [0,1] (for all x in [0,1] and j=0,..,k-1):

w0(0) = 0, w0(1) = 0, w1(0) = 0, w1(1) = 1, w2(0) = 1, w2(1) = 0, w3(0) = 0, w3(1) = 0  (a)

w0'(0) = -w3'(1), w0'(1) = -w3'(0), w1'(0) = -w2'(1), w1'(1) = -w2'(0)  (b)

w0''(0) = w3''(1), w0''(1) = w3''(0), w1''(0) = w2''(1), w1''(1) = w2''(0)  (c)

The equations above are for k=4 (Spline16), but the extension to arbitrary k is obvious.

As you can see these are 8 + 4 + 4 = 16 equations, and since we have 16 unknowns (aj,bj,cj,dj for j=0,1,2,3), the system should be solvable. At least that's what i thought yesterday, but i guess these equations are dependent, since i wasn't able to solve for the unknowns.

So we need some additional constraints, but i have no clue which ones. I guess i need to ask my colleagues on sci.math about this.

Two remarks about the constraints above:

1) As you can see the constraints don't connect all the equations. The constrains connect w0(x) and w3(x), and also w1(x) and w2(x), BUT strangely NOT w0(x) and w1(x). I think this is very bad, but i'm not sure what the consequences are.

2) The first derivative constraints: w0'(0) = -w3'(1). This is also very bad. The cubics have to be connected in a smooth way (which can be enforced by the constraints), but they are not. I bet that this causes the ringing that some people see.

Anyhow, on http://mathworld.wolfram.com/CubicSpline.html they give a correct derivation of cubic splines (they show how to solve for the bj coefficients). Solving for the remaining cj/dj coefficients shouldn't be that difficult. I will report about it very soon ...

[MfA]

The papers say making the sections C2 continuous is enough to get a unique solution (a non optimal one) and I'm inclined to believe them. I'm too lazy to actually do the math (they already give the solution, both for optimal kernels and C2 continuous ones ... I chose to just believe them on their word on those). I checked the continuity of the splineX kernels too though, since they aren't even C1 continuous I don't think this will get you anywhere as far as determining how the SplineX kernels were derived. I think I'll have to go back to my original statements, they are completely ad hoc.

Ringing is an integral part of any linear filter with negative taps, regardless of continuity.

[twolfe18]

i just jumped in on this thread like dspider, and i just wanted a bit more detail.

for me, i do mainly conversion of hdtv (mostly 1080i), and i usually downscale to 1024x576. i have noticed the ringing you talk about with lanczos and lanczos4, but do these hold an advantage at higher resolutions?

basically, what is the best hi-res downscaler?

[foxyshadis]

From earlier this thread...

http://forum.doom9.org/showthread.ph...474#post956474
http://forum.doom9.org/showthread.ph...735#post957735
and the most important of all,
http://forum.doom9.org/showthread.ph...801#post950801

Such issues are the same no matter what you resize, but the higher the output resolution, the less noticeable any artifacts are.

[DeathTheSheep]

I was thinking SplineX might be using coefficients chosen by visual trial and error, rather than mathematical nth degree derivative continuity ("optimal" method).

So either:
1. The developers simply don't know what they're doing
2. The developers genuinely thought their version produced better results
3. We're missing something-- perhaps there's a more complicated answer.

Either way, it would be very interesting to see how splineX's implementations match up with the mathematically optimal ones.

[IanB]

Yes the splines are not smooth. Sorry for the confusion in assuming the spline segments were 2nd order smooth.

My current guess is the splines are chosen to most strongly match the segments of a particular, as yet undiscovered, truncated sinc function. Although not identical to the Blackman sinc function, they are surprisingly very close, one would have to suspect the rational for each is related.

[Wilbert]

3. We're missing something-- perhaps there's a more complicated answer.

I think it is this one. I added the Spline resizers given at mathworld to the package of foxyshadis. Usage:

Spline16WResize()/Spline36WResize()/Spline64WResize()

Some early observations:

1) Spline16WResize blurs like hell. Which makes me really curious about Spline16Resize, because it is so much better.

2) Spline36WResize / Spline36Resize have about the same quality.

3) Spline64WResize / Spline64Resize have about the same quality, but both are less sharp as Spline36WResize / Spline36Resize.

Tell me what you think about it:

http://www.savefile.com/files/530858

[Terranigma]

thanks wilbert. checking them out now

[wonkey_monkey]

I'm just having a quick look at resample_functions.cpp, and I'm a little confused - shouldn't the number in the spline function correspond to the number of pixels in the window? For example, spline64filter considers values of value from -4 to 4, making an 8x8 window of 64 pixels - as I'd expect. But spline16wfilter also considers value from -4 to 4, which is still 64 pixels, not 16...

Spline36wfilter seems to be using a window size of 144... and so on. Sorry, I've probably missed something important earlier in the thread, but it's something of a pet subject for me.

David

[Wilbert]

I'm just having a quick look at resample_functions.cpp, and I'm a little confused - shouldn't the number in the spline function correspond to the number of pixels in the window?

Yup.

For example, spline64filter considers values of value from -4 to 4, making an 8x8 window of 64 pixels - as I'd expect.

I'm confused. I didn't notice it, but it only uses four equations and not eight! (As far as i can see, they are not symmetric around zero.)

IanB, foxyshadis what did you do with the other equations from this page? Thus w2,w3 for Spline16, w3,w4,w5 for Spline36, etc ...

[wonkey_monkey]

They are symmetrical, and that's why there are only four equations, because you use the absolute value of value to choose an equation.

In resample_functions.h all four functions return a value for support of 4 - shouldn't that be 2 for the spline16s and 3 for the spline36s?

David

PS:

1) Spline16WResize blurs like hell. Which makes me really curious about Spline16Resize, because it is so much better.

I think I might know why that is - with the current equations, the spline shoots up to >1 at around ±3.8 (it should go to, and stay at, 0 once it gets to ±2).

[Wilbert]

They are symmetrical, and that's why there are only four equations, because you use the absolute value of value to choose an equation.

If you plot them you will see that they are not symmetrical, but perhaps i'm missing something.

In resample_functions.h all four functions return a value for support of 4 - shouldn't that be 2 for the spline16s and 3 for the spline36s?

Yup, thanks! That solves the blurring problem of Spline16W!

[DeathTheSheep]

Here are some screens downsized 2:1 and then upsized again with pointresize:

Spline16:

Spline16w:


The visual evidence certainly does seem to support this conclusion

[DeathTheSheep]

Spline64WResize / Spline64Resize have about the same quality, but both are less sharp as Spline36WResize / Spline36Resize.

I'm not so sure about that--to my eyes, Spline64Resize definitely does seem sharper than Spline36Resize, and resulting filesizes (encodings) are bigger with it, which is a pretty good indication of sharpness, too.

PS: Any chance for re-uploading the "fixed" package? Thanks!