SORTED :) Windows After XP Sux big time.

[StainlessS]

Not sure, but I think I recall that Spline36 is neutral, whereas Spline64 sharpens.

EDIT: If so, then I presume that Spline16 does a mild blur.

[GeoffreyA]

I've been pleased with Spline36, and its not looking artificially sharp or soft.

[Z2697]

I've been using spline64 since FFmpeg updated zscale filter with that option (finally), in places where I would use spline36.
For most cases the difference is unnoticeable though.

[FranceBB]

Looks like George King from the MSFN community just ported the TPM 2.0 module driver to Windows XP. I'm not really sure what XP would do with it, but hey, it works.

[GeoffreyA]

Originally Posted by Z2697

I've been using spline64 since FFmpeg updated zscale filter with that option (finally), in places where I would use spline36.
For most cases the difference is unnoticeable though.

The other day, I experimented with high iteration count of Spline and Lanczos, finding that all except Spline64 showed odd crosshatch patterns, Lanczos and Spline16 being the worst, but Spline36 also suffering from it. The tradeoff with Spline64 was that, after many iterations, it was softer. Further testing showed that using Spline64 for the upscaling and Spline36 for the downscaling eliminated most artefacts, leaving only mild softening and ringing, and looking visually closer to the original. Of course, with less than 10 or 5 scalings, one isn't likely to see any problem.

Originally Posted by FranceBB

Looks like George King from the MSFN community just ported the TPM 2.0 module driver to Windows XP. I'm not really sure what XP would do with it, but hey, it works.

Good to see XP going strong.

[FranceBB]

Originally Posted by GeoffreyA

Of course, with less than 10 or 5 scalings, one isn't likely to see any problem.

In theory if one knows the kernel it should be possible to invert it and get back the original. Out of curiosity, what was the result with like Spline64ResizeMT() and DeSpline64ResizeMT()?

By the way, for things that are not upscaled but rather at a native high resolution that need to be downscaled I generally use SinPowerResize() which prevents overshooting and it's gibbs ringing free.

Originally Posted by GeoffreyA

Good to see XP going strong.

Windows XP Forever

[GeoffreyA]

Originally Posted by FranceBB

In theory if one knows the kernel it should be possible to invert it and get back the original. Out of curiosity, what was the result with like Spline64ResizeMT() and DeSpline64ResizeMT()?

By the way, for things that are not upscaled but rather at a native high resolution that need to be downscaled I generally use SinPowerResize() which prevents overshooting and it's gibbs ringing free.

It was done in VapourSynth, so I'll have to look for the descaling functions. I used the zimg scalers. The problems only show up after many, many iterations, but I found it useful to amplify the characteristics of each scaler this way. Normally, I can't tell the difference. As a result of this experiment, I changed my (HDR->SDR) libplacebo upscaler to Spline64 and left the downscaler at 36. Not that it matters though.

I've seen your recommendation of SinPowerResize() before and would have liked to try it, but am not sure on the VapourSynth side where to find a version.

[GeoffreyA]

from vapoursynth import core

src = core.bs.VideoSource(r"oracle.bmp")

src = src.fmtc.bitdepth(bits=32)
tmp = src

count = 100

for i in range(count):
    tmp = tmp.resize.Spline36(3840, 2160)
    tmp = tmp.resize.Spline36(1920, 1080)
    
tmp = tmp.text.Text(str(count) + " iterations", alignment=4)
tmp = tmp.text.ClipInfo(alignment=6)

src = core.std.Interleave([src, tmp])
src = src.fmtc.bitdepth(bits=8)

src.set_output()

100x 32-bit float: https://slow.pics/s/SDYffpRB
100x 8-bit integer: https://slow.pics/s/9o9eQ2at

This picture has a lot of grain. A flatter one shows the crosshatch pattern better. Curiously, leaving the frame at 8-bit depth eliminates most of the artefacts.

Edit: Updated version but still without the descalers: https://forum.doom9.org/showthread.p...74#post2028074