Is there something wrong with spline36resize?

[StainlessS]

encode.avs
FFVideoSource ("trippy-lossless.mkv")
mt_lut ("x 255 / 239 * 16 +", u=-128, v=-128)

Not sure that I understand that, but should 239 be 219 ?

EDIT: Looks like 0->255 convert to 16->255, should it be 0->255 convert to 16->235 ?

[foxyshadis]

Numerical accuracy issues are really nice (http://ldesoras.free.fr/video/trippy.mp4) indeed.

I almost don't want it fixed now. In fact, I feel like building a MazeGenerator() for movie intros and music videos.

[cretindesalpes]

Not sure that I understand that, but should 239 be 219 ??
You’re right, it’s a typo mixing 235 and 219.

[Sparktank]

I almost don't want it fixed now. In fact, I feel like building a MazeGenerator() for movie intros and music videos.

Exactly that!
Perfect for a cover for Inception, Dark City, The Labyrinth and so many others.
Revamp the end credits to Inception, even.

DeviantArt users would love it for minimalist posters.

You’re right, it’s a typo mixing 235 and 219.

I'll adjust the script after this batch is done.

[Wilbert]

The effect gets worse the more taps you use, since taps have nothing to do with positioning, that would be a hint as to what's wrong.

SplineResize used with 6 taps doesn't have the same mangling problem as Spline144Resize (or even Spline100Resize) so the algorithms being used are obviously different.

Other than the left shift SplineResize is actually an improvement over the more specific resizers. However, it does seem to still screw with YV12 colours in a way that it really shouldn't.

[I can't manage to compile the filters, much less try to figure out how they work... it seems to be rejecting the SoftWire from the latest AVISynth source code or something plus I'm having problems with MSVCRTD.lib now... Is there something wrong with VS2012 or is absolute difficulty trying to compile anything downloaded from the internet normal?]
I finally had some time to look at this. It's simply a documentation error. It should be

SplineResize (clip clip, int target_width, int target_height
[, float src_left, float src_top, float src_width, float src_height, int taps = 4])

instead of

SplineResize (clip clip, int target_width, int target_height, int taps = 4
[, float src_left, float src_top, float src_width, float src_height])

So you were actually cropping from the left, resulting in a left shift.

With respect to your post #34. If i use that script and the image of that girl, my output isn't messed up as yours. The second frame is just much darker. I need to look at that.

With respect to your post #45. It works this way indeed.

[raffriff42]

Sharpen has the same ''problem'', as we found here (http://forum.doom9.org/showthread.php?p=1748503#post1748503). Try this on any reasonably sharp source...
Sharpen(1.0).Sharpen(1.0).Sharpen(1.0).Sharpen(1.0)
I'm guessing that since both resizers and sharpeners have peaks and valleys
in their spatial frequency response, the peaks get higher with every pass - and this
is made worse by 8-bit processing.

[ndjamena]

The script I posted produces TWO FRAMES, interleaved. One OK frame that uses spline64 and a second mangled frame that uses spline100. You need to look at the second frame to see where the problem is.

[colours]

I'm guessing that since both resizers and sharpeners have peaks and valleys in their spatial frequency response, the peaks get higher with every pass - and this is made worse by 8-bit processing.

Yup, that's exactly the reason. It's worth noting that the peaks don't just get higher—they get higher exponentially quickly. After a few iterations it doesn't really matter whether you use 8-bit processing or 16-bit processing or whatever; it's likely that the values have already saturated at the minimum or maximum.