Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th June 2009, 08:08   #61  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by DeathTheSheep View Post
Regarding your SplineResize_v01.zip, increasing the number of taps for the splineResize function causes the frame to shift further and further to the left, duplicating the pixels of the final column.

Source: 640x480. splineresize(320,240,32).
The documentation is wrong. The 3rd paramater is src_left.
Use taps=32.
Gavino is offline   Reply With Quote
Old 20th June 2009, 12:29   #62  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
Conclusion: Is there a problem with spline100resize? The image it produces is far too sharp (and filesize too big) compared to the other (working?) filters. All of the others (except spline16) were similar in visual appearance, as is expected from spline36+ in terms of the law of diminishing returns to how 'accurately' the interpolator can resize an image (yes, I used the two words together).
See the pics below. Remember, spline16w was verified to have a coefficient problem in the past, and it looks as if spline100 is following suit (though to a lesser extent). Of course, this anomalous problem could be reversed: if the splines are supposed to become increasingly sharp, then spline144 clearly isn't sharp enough! But I somehow doubt this to be the case.
When i made Spline16W i didn't know what i was doing, so therefor it was faulty. Spline100/Spline144 should be correct though. Looking at your pics I see that Spline100 is sharper than Spline64/Spline144. Strange. I will look at it next week after my exams.

Could you do this test for SplineResize(x,y,taps=xx) too and post the results?
Wilbert is offline   Reply With Quote
Old 20th June 2009, 17:36   #63  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
@Gavino: Thanks. I should have also looked at the example scripts first. Haste makes waste, indeed.
@Wilbert: Okay, done. I modified the test so it was more extreme: 32 cycles. I also made it a perfect '2xScale' and included the original picture. Updated tests for the cubic spline filters were included as well. In this file, all pictures are provided. Those named tX are the natural splines of taps X.

Conclusions: For low even numbers of taps, the behavior of the natural spline (SplineResize) is aberrant much like spline16w. This 'oversharp' problem also does occur with spline100, and surprisingly to some small extent with spline36, which was only revealed after this more excessive repetition size.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!
DeathTheSheep is offline   Reply With Quote
Old 20th June 2009, 17:54   #64  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
@DeathTheSheep,

Thanks! I goofed up Spline100Resize. There was a minus sign in the leading coefficients in one of the polynomials that shouldn't be there. Could you try this version:
http://www.geocities.com/wilbertdijk...Resize_v02.zip
and post a screenshot? I will look at your other pics later.

Could you tell me how you made your pics? Just downsize with a factor of 2 (using Spline) and upsize with a factor of 2 (using Pointresize), and do that 5 resp. 32 times?

Last edited by Wilbert; 20th June 2009 at 18:02.
Wilbert is offline   Reply With Quote
Old 20th June 2009, 21:53   #65  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
[img][/img]
[edit]Image removed, since it was replaced by imageshack with some italian-looking illegal screenshot thing. Suffice it to say, spline100 is back on track.[/edit]

It appears in-line with the other results from spline64 and up.

As to how I made these pics, yes, I at first did it exactly the way you described 5 times, but then decided to change my strategy: it's more interesting to instead test how accurately the interpolator can then scale up what it just scaled down, essentially a 2-way test. So I ended up doing:
Code:
spline100resize(320,240)
spline100resize(640,480)
32 times to produce these exact results.
Now it's even more interesting that spline36 produces such a 'sharp' image, sharper than the rest. Surely the coefficients for spline36 were determined via some other method or source?

Also, the natural spline produces oversharp images at low even tap numbers (2 and 4 most noticeably). When taps is increased too far (beyond the bounds of human reason, I'd say) as was the case with 64 taps, it produces strange artifacts on the bottom of the image.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!

Last edited by DeathTheSheep; 1st October 2009 at 00:29.
DeathTheSheep is offline   Reply With Quote
Old 20th June 2009, 22:36   #66  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Good!

Quote:
32 times to produce these exact results.
Now it's even more interesting that spline36 produces such a 'sharp' image, sharper than the rest. Surely the coefficients for spline36 were determined via some other method or source?
No, it is derived in the same way as Spline16/64/100/144 (i've double checked its coefficients). Sorry, i have no explanation for its sharpness.

Quote:
Also, the natural spline produces oversharp images at low even tap numbers (2 and 4 most noticeably). When taps is increased too far (beyond the bounds of human reason, I'd say) as was the case with 64 taps, it produces strange artifacts on the bottom of the image.
Yes, i noticed that in your pics. The coefficients are calculated on the fly (two times per frame; yes one time for the whole clip should be enough but i don't know how to do that). I will check the calculated coefficients with the exact ones (which can be easily calculated with Maple). Perhaps something goes wrong somewhere.

Last edited by Wilbert; 20th June 2009 at 22:40.
Wilbert is offline   Reply With Quote
Old 21st June 2009, 02:14   #67  |  Link
mikenadia
Registered User
 
Join Date: Nov 2007
Posts: 246
For SplineResize, I think that the use of natural cubic spline is flawed.
For taps=2 , the natural cubic spline model does not take into account that for abs(x)>=2, h(x)=0, so the natural cubic spline is not C1 continuous at x=2. It should be at least the clamped cubic spline with first derivatives at endpoints=0 (that will lead to a=-0.75). It seems that a=-0.5 is preferred (we should get rid of the C2 continuous condition at abs(x)=1 and replace it with another one (Keys 1981 paper).

Last edited by mikenadia; 21st June 2009 at 02:27.
mikenadia is offline   Reply With Quote
Old 21st June 2009, 10:56   #68  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
On the other hand, the existing SplineNNResize kernels are not C1 continuous at the joins (x=integer), not even at x=0, yet they seem to give 'reasonable' results.

I think MfA got it right in saying that there is no perfect mathematical solution. It helps to start with a mathematical model that approximates 'reality', but ultimately the results can only be judged by experiment with real images.
Gavino is offline   Reply With Quote
Old 21st June 2009, 12:12   #69  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
For taps=2 , the natural cubic spline model does not take into account that for abs(x)>=2, h(x)=0
Yes, it does. That is, it should do that when implemented correctly, but perhaps i did something wrong somewhere. I don't think the artifacts are caused by this. I will check it after my exams.

Quote:
natural cubic spline is not C1 continuous at x=2
Yes, it's not C1 continuous at the end-points (only C2 continuous): x=+/-support.

Last edited by Wilbert; 21st June 2009 at 12:28.
Wilbert is offline   Reply With Quote
Old 22nd June 2009, 00:43   #70  |  Link
MfA
Registered User
 
Join Date: Mar 2002
Posts: 1,075
Anyone know any blender? It would be nice to have a couple of losslessly encoded short scenes from Elephant's Dream rendered at a couple of resolutions (preferably with a large GCD) and subpixel offsets for objective testing of scalers/interpolators.

Though the default renderer might have too many resolution dependent effects to really work well for benchmarking. Some of the more physically correct pathtracing engines such as Luxrender would be better, but don't know how feasible it would be to use that with the ED animation.

Last edited by MfA; 22nd June 2009 at 00:57.
MfA is offline   Reply With Quote
Old 30th September 2009, 18:30   #71  |  Link
EpheMeroN
EphMan
 
Join Date: May 2004
Posts: 737
Just glancing over this thread, are you guys saying Spline16Resize is heavily flawed?

But Spline144Resize is the better choice?

IIRC just going from Spline16 to Spline36 took a HUGE hit on encoding speed. So Spline144Resize must be incredibly slow?
EpheMeroN is offline   Reply With Quote
Old 30th September 2009, 23:32   #72  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
No, spline16 as implemented in avisynth seems to work just fine. We were just discussing a[n oddly unbounded] development filter. Unless there's something really meticulous you need to do, spline16 should be fine. Yes, 36 is slower, and 144 much slower still.

In other news, what the hell happened to my image (above)? What the heck is that thing? That's not what I posted at all.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!
DeathTheSheep is offline   Reply With Quote
Old 1st October 2009, 00:11   #73  |  Link
thewebchat
Advanced Blogging
 
Join Date: May 2009
Posts: 480
I think the real question is regarding the rule 6 violation apparent in the picture from the last page of this thread.
thewebchat is offline   Reply With Quote
Old 1st October 2009, 00:27   #74  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
I fully agree. Also rules 3, 5, and 7 are being broken in addition to 6.

Trust me, I did not put that picture there. Imageshack must have erased the original, 100b, which was a picture of the fixed spline100 interpolator showing the correct behavior.

I will edit the post to remove all image tags. Are my other pictures still intact, or have they been changed as well? Anybody notice anything?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!
DeathTheSheep is offline   Reply With Quote
Old 24th December 2009, 22:04   #75  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
@Wilbert:

Your link is dead-- could you re-upload sometime? I reinstalled my system so my old package is gone...
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!
DeathTheSheep is offline   Reply With Quote
Old 25th December 2009, 14:10   #76  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
http://www.wilbertdijkhof.com/SplineResize_v02.zip
Wilbert is offline   Reply With Quote
Old 17th July 2012, 05:54   #77  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
It is still in development? Or stopped?
bxyhxyh is offline   Reply With Quote
Old 17th July 2012, 18:08   #78  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
It is still in development? Or stopped?
What do you like to see? A while ago i got the following bug report from someone:

I did some testing of various resizers and found that SplineResize() was shown with a left shift.
I've attached a picture and the data I used for testing.


But i haven't looked at that yet.
Wilbert is offline   Reply With Quote
Old 5th November 2012, 23:33   #79  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
I see a noticeable improvement of spline144 over spline100. Would spline196 or even spline256 bring further improvement?
turbojet is offline   Reply With Quote
Old 12th March 2017, 21:30   #80  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,048
A rewrite of the OP in plain English would be extremely valuable.

Quote:
Originally Posted by MfA View Post
The funny thing about the Catmull-Rom spline is the amount of different methods which lead to it.
Yeah, I've suspected for a while that Catrom is the "true" cubic, as it's the one cubic that (a) always goes through all of the original sample points, and (b) preserves linear gradients
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.
Katie Boundary is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:06.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.