View Full Version : SORTED :) Windows After XP Sux big time.
Pages :
1
2
3
4
5
6
7
8
9
10
[
11]
StainlessS
29th January 2026, 11:23
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
29th January 2026, 14:28
I've been pleased with Spline36, and its not looking artificially sharp or soft.
Z2697
31st January 2026, 20:00
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
7th February 2026, 00:10
Looks like George King from the MSFN community just ported the TPM 2.0 module driver (https://www.mediafire.com/file/t7lsbos6a4vjjbr/TPM_6.1.7601.24564_x86.7z/file) to Windows XP. I'm not really sure what XP would do with it, but hey, it works.
https://images2.imgbox.com/ca/78/Jna1w6pd_o.png
https://images2.imgbox.com/a9/47/svgxO3tL_o.png
GeoffreyA
8th February 2026, 09:19
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.
Looks like George King from the MSFN community just ported the TPM 2.0 module driver (https://www.mediafire.com/file/t7lsbos6a4vjjbr/TPM_6.1.7601.24564_x86.7z/file) 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
8th February 2026, 12:52
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.
Good to see XP going strong.
Windows XP Forever :D
GeoffreyA
8th February 2026, 13:16
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
8th February 2026, 15:14
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.php?p=2028074#post2028074
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.