Spline64Resize - Does it give artifacts?

[Atlantis]

I want to reduce the size of some 1080 materials to 720 with sharp results. Is Spline64Resize the best filter to reduce resolution?

I have done some tests and I have noticed a little motion artifacts. It's very subtle and a casual viewer will not notice it. It needs trained eyes. For example I have noticed when a person turns his head some pixels lag behind.

Does Spline64Resize to 720 introduce motion artifacts? Are there other resizers that don't do this?

[Boulder]

I highly doubt it is the culprit.

For downsizing, I use Didee's trick which is something like BicubicResize(x, y, b=-0.6, c=0.3), changing b and c depending on the source. The values where b=-0.x and c -0.5*b might make a nice default to test.

[Atlantis]

Thank you. Could you please explain why you use BicubicResize(x, y, b=-0.6, c=0.3)? What it does better than Spline64Resize?

[Boulder]

Well, it just seems to retain sharpness quite nicely without many ill effects. I always use Zopti to find optimal values, comparing the downscaled-upscaled clip to the original and use the values it gives me, but -0.6 and 0.3 might be a good starting point for general testing.
https://forum.doom9.org/showthread.php?p=1579385#post1579385

[FranceBB]

Spline is generally my way to go for upscaling but not for downscaling.
When it comes to downscale, you can give SinPowResizeMT() from plugins_JPSDR a whirl.
For more info about SinPow check here: http://forum.doom9.net/showthread.php?t=181612

[kedautinh12]

Well, it just seems to retain sharpness quite nicely without many ill effects. I always use Zopti to find optimal values, comparing the downscaled-upscaled clip to the original and use the values it gives me, but -0.6 and 0.3 might be a good starting point for general testing.
https://forum.doom9.org/showthread.php?p=1579385#post1579385

thanks

[wonkey_monkey]

Spline64Resize is a spatial filter so it won't create motion artefacts. It might highlight existing ones though.

[feisty2]

Spline64Resize is a spatial filter so it won't create motion artefacts. It might highlight existing ones though.

Downsizing can indeed introduce subtle temporal artifacts. Sharp moving edges can appear "flickering" after downsizing because of aliasing. This can be especially observable if the resampling kernel is very sharp and the downsizing factor is very large.

[GMJCZP]

About two months ago I took some videos with a cell phone and since I wanted to share them on WhatsApp, I had to reduce their size, that included reducing their resolution. I started testing the Spline family included in Avs + and then I remembered the SplineResize plugin and noticed that with the latter with 144 taps I was able to retain much more detail.
The only bad thing about SplineResize is that it doesn't operate on HBD.

[FranceBB]

I started testing the Spline family [...] and noticed that with 144 taps I was able to retain much more detail.

Oh, another person that likes Spline144Resize.
If Katie reads this, she's probably gonna marry you eheheheh

By the way, for me Spline is far too sharp for downscaling. It might behave ok and extremely sharp with normal contents, but whenever there's a caption like a text in the video it creates a lot of ringing.
But yeah, if there's no text whatsoever, it can be good, it's just that I don't wanna risk it... like... at all. :P

[GMJCZP]

Oh, another person that likes Spline144Resize.
If Katie reads this, she's probably gonna marry you eheheheh

By the way, for me Spline is far too sharp for downscaling. It might behave ok and extremely sharp with normal contents, but whenever there's a caption like a text in the video it creates a lot of ringing.
But yeah, if there's no text whatsoever, it can be good, it's just that I don't wanna risk it... like... at all. :P

I think it was precisely because of an exchange of opinions between you that I wanted to do the essay.
Naturally, if there is something in the image that is sharper than the rest, be careful not to add more sharpness, perhaps using a mask will avoid complications.

[wonkey_monkey]

Oh, another person that likes Spline144Resize.

I love Spline144Resize, but only because it does this if you repeatedly downscale and upscale:

https://www.youtube.com/watch?v=KPOwoV7-a14

[feisty2]

Oh, another person that likes Spline144Resize.
If Katie reads this, she's probably gonna marry you eheheheh

By the way, for me Spline is far too sharp for downscaling. It might behave ok and extremely sharp with normal contents, but whenever there's a caption like a text in the video it creates a lot of ringing.
But yeah, if there's no text whatsoever, it can be good, it's just that I don't wanna risk it... like... at all. :P

Are you aware of this?

spline144resize(src, ....).repair(gaussresize(src, ..., p = 100), 1)

[poisondeathray]

I have done some tests and I have noticed a little motion artifacts. It's very subtle and a casual viewer will not notice it. It needs trained eyes. For example I have noticed when a person turns his head some pixels lag behind.



Did you rule out lossy compression artifacts in your testing?

"pixels lag behind" sounds more like temporal artifacts, either in the source already, or introduced by lossy encoding.

Aliasing caused by a spatial resizer can certainly cause artifacts - but the description of those artifacts is inconsistent with your description

[Atlantis]

I encode 720p at crf22 x265. I suppose maybe low bitrate could cause it but I'm not sure yet. I'm experimenting with Spline16Resize at the moment and it looks better to me. Maybe it causes less artifacts because the details are less. The resulting bitrate is a little lower than using Spline64Resize.

[Asmodian]

What about Spline36? That is the standard spline used.

[Atlantis]

Why, you want to kill me? These things are not good for OCD inclined, you can go down the rabbit hole. I already can't really say 64 or 16 is better. So I'm not going to add something in the middle that can drive me nuts! I have already decided that 36 is not divisible by 16 so I don't like it! :D

[wonkey_monkey]

These things are not good for OCD inclined

In that case you may like to know that, with the default parameters b=c=1/3, BicubicResize is a blurring filter. I think b=0, c=0.5 are the most neutral parameters for sharpness (i.e. they will leave an image unchanged if you're not scaling or shifting it).

I have already decided that 36 is not divisible by 16 so I don't like it!

Maybe that's 16's fault!

Both are perfect squares, at least.

[VoodooFX]

I've settled that Spline16Resize is best for me.
Just noticed that if you divide it by 16 you get 1, so now it's even better. :D

[Asmodian]

If it helps Spline16 is two taps, 36 is three taps, and 64 is four taps. :)

Spline36 is a nice balance of the two extremes, ignoring Spline144, and it is usually what people mean when doing a "Spline" resize.

[Atlantis]

BicubicResize does not help OCD! In case you didn't notice, it has 2 float values that you can change forever. Spline is good because you can't change any values! :)

[Atlantis]

Surprising that Spline16Resize is slower than Spline64Resize. I thought it should be faster.

[wonkey_monkey]

Are you sure? Spline16Resize is 20% faster for me (though that's not as much as I had expected).

[Atlantis]

Yes I have done 2 full length tests. It's not much though.

Spline16Resize(1280, 536)
encoded 133640 frames in 4388.78s (30.45 fps), 772.22 kb/s, Avg QP:26.36

Spline36Resize(1280, 536)
encoded 133640 frames in 4039.89s (33.08 fps), 788.30 kb/s, Avg QP:26.37

Spline64Resize(1280, 536)
encoded 133640 frames in 4120.81s (32.43 fps), 788.89 kb/s, Avg QP:26.37

[VoodooFX]

Spline16Resize(1280, 536)
encoded 133640 frames in 4388.78s (30.45 fps), 772.22 kb/s, Avg QP:26.36

Here you are measuring encoding speed, not resizing speed.
Use AVSMeter.

[Atlantis]

Yes I know. I do tests in the real world. I am never going to sit and watch how fast AVSMeter is going. The real world for me is encoding in x265. The whole pipeline from start to end.

[GMJCZP]

BicubicResize does not help OCD! In case you didn't notice, it has 2 float values that you can change forever. Spline is good because you can't change any values! :)

I have been away from Doom9 and am still updating myself, what is the meaning of OCD? Thanks.

[feisty2]

obsessive compulsive disorder? (because he/she wants to find the absolutely optimal parameters)

[Atlantis]

It's when you spend too much time on doing one thing. At one point testing all the things and not being able to decide, makes you crazy. You have to stop at one point.
I already spent more than a day deciding Spline16Resize or Spline64Resize is better! Some day I will find out!

...and these 2 have no variables by the way. Imagine testing BicubicResize! :confused:

[Boulder]

It's when you spend too much time on doing one thing. At one point testing all the things and not being able to decide, makes you crazy. You have to stop at one point.
I already spent more than a day deciding Spline16Resize or Spline64Resize is better! Some day I will find out!

...and these 2 have no variables by the way. Imagine testing BicubicResize! :confused:

You could use Zopti to help you a bit ;)

[Atlantis]

I did google it the day it was mentioned here and opened the thread. My head exploded.

I was already unable to make FineSharp() work! Is it good? Worth it?

[DTL]

Spline is generally my way to go for upscaling but not for downscaling.
When it comes to downscale, you can give SinPowResizeMT() from plugins_JPSDR a whirl.


Further development of this ideas were UserDefined2Resize with currently 2 control params. Its function is currently looks also only in JPSDR's plugins. Though it more complicated for user because of at least 2 control params instead of 1. SinPow is sort of more rough approximation the required for downscaling kernel but more user-friendly having only 1 control param.

Also of the built-in Avisynth resizers kernel only Gauss is sort of spectrum-aware for downsampling processing of video data. Many other resizer kernels are not for video but for other computer-available datasets about images (up to pixel-art or static photo images). So they generally not capable of correct re-build output video data spectrum for both Nyquist and anti-Gibbs requirements at downsampling work. So they can add aliasing and/or ringing.Though most of Avisynth resizers more or less good for upsize work.

"Imagine testing BicubicResize! "

The frequency responce of spectrum-preparation filter for downscaling work depends on:
1. Source spectrum.
2. Downscaling ratio.
3. User preference on output sharpness.

Only 2 can be easy calculated from output/input size. Even in prof broadcast video the exact shapes of spectrum defining sharpness appearing of video image (for 1.) is not standartized and the standard target spectrum (for 3.) is not defined too. So no easy defined full-auto downsizing programs can be created even for 'reference' standards converting like from 1080 to 720 or from 4K to FullHD etc. Currently all downscaling high quality video work require human input for adjustments.

Currently we have only the very beginning work in progress like attempt to define 'video-look' and 'fim-look' moving picture data spectrum shaping for production camera setup (also applicable for production downscaling work).

[hello_hello]

Spline is generally my way to go for upscaling but not for downscaling.
When it comes to downscale, you can give SinPowResizeMT() from plugins_JPSDR a whirl.
For more info about SinPow check here: http://forum.doom9.net/showthread.php?t=181612

I thought I'd give it a spin, but I must be missing something.
The screenshots are:

1 - 1080p source (1920 x 800)
2 - Spline36Resize(1280,532, 0,1,0,-1)
3 - BicubicResize(1280,532, -0.6, 0.3, 0,1,0,-1)
4 - SinPowResizeMT(1280,532, 0,1,0,-1)

2, 3 & 4 were resized back to 1080p with MPC-HC's Bicubic resizing for comparison with the original. Obviously that's another factor, but still....

https://i.postimg.cc/nXznPSyf/1-1080p.png (https://postimg.cc/nXznPSyf)

https://i.postimg.cc/YLHpDrHd/2-Spline36.png (https://postimg.cc/YLHpDrHd)

https://i.postimg.cc/JDb8kfkZ/3-Bicubic.png (https://postimg.cc/JDb8kfkZ)

https://i.postimg.cc/dDr32XYW/4-Sin-Pow-Resize-MT.png (https://postimg.cc/dDr32XYW)

Direct links (hopefully).

https://i.postimg.cc/x1GqqWg8/1-1080p.png

https://i.postimg.cc/5yH60ykW/2-Spline36.png

https://i.postimg.cc/FR6H2mFW/3-Bicubic.png

https://i.postimg.cc/PfFDjsFk/4-Sin-Pow-Resize-MT.png

[DTL]

I thought I'd give it a spin, but I must be missing something.
The screenshots are:

4 - SinPowResizeMT(1280,532, 0,1,0,-1)



The control param p is the last as I see from http://avisynth.nl/index.php/Resize and if not named is default. The default value is close to the sharpest about 2.5 (as I see from some version readme.txt like ver 2.3.2) . If you have already very sharp rendered text and got oversharp downscaled result you can try to set p-param to lower sharpness value up to 2.9..3.0. After 3.2 and more it will be close to Gauss (soft as Gauss).

Also I hope still correct target upsampler for moving picture data (video) is Sinc - not bicubic. Though any user can use its own custom video system with any upsampler he likes or selected by own reasons and select and fine-tune dowscalers for this workflow.

Also I hope the topic is about 'real' video content and not syntetic rasterised text. The good high quality text rasterizer for video is separate topic. If this thread is really about downscaling some rasterised to 1080 text - the selecting of downscaler depends on the spectrum properties of exact used text rasterizer engine + target upscaler (data to optical rendering device) + user's preferences on distortions and sharpness and so on. May be simple Bilinear will be best. For a bit better specttum shaping and decreasing possible over/undershoots the Gauss may be recommended.

What was practically tested here: Workflow of:
1. Some unknown text rendering engine with unknown control params +
2. SinPowResize with very sharp current default p=2.5 +
3. BicubicResize with unknown control params

give not very great result.

[kedautinh12]

How about SSIM_downsample??
https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/SSIM_downsample.avsi

[hello_hello]

The control param p is the last as I see from http://avisynth.nl/index.php/Resize and if not named is default. The default value is close to the sharpest about 2.5 (as I see from some version readme.txt like ver 2.3.2) . If you have already very sharp rendered text and got oversharp downscaled result you can try to set p-param to lower sharpness value up to 2.9..3.0. After 3.2 and more it will be close to Gauss (soft as Gauss).

The screenshots are from a video where the camera is pointing at a monitor displaying text. I only used that shot because FranceBB mentioned text earlier and I wanted to have a look.

I'll have a play again later as the Avisynth wiki says the default for P for Gauss is 30.0 and for SinPowResizeMT it's 2.5, so if they're directly comparable, 2.5 should be fairly blurry, but maybe it doesn't work that way.

What was practically tested here: Workflow of:
1. Some unknown text rendering engine with unknown control params +
2. SinPowResize with very sharp current default p=2.5 +
3. BicubicResize with unknown control params

give not very great result.

Well... only not great for SinPowResize. It was the output of an Avisynth script viewed in MPC-HC. They were all upscaled using the same player/method. It mightn't be completely scientific but if the upscaler was causing artefacts it'd effect them all.
Anyway, as I said, I'll try again later when I get a chance and post back then. Assuming I can find that shot again.

[hello_hello]

In the mean time, I was messing around with the Resize8 (https://forum.doom9.org/showthread.php?t=183057) function the other day. I've been using it for a while (there's a wrapper function for it included with my CropResize function) but I've not done any sort of comparisons before. The default ringing repair when upscaling seems to do a reasonable job, given I upscaled Avisynth's 640x480 ColorBars to 1440.1080 (and it corrects the chroma shift caused by Avisyth's resizers when resizing YV12 and YV16 etc).

ColorBars().KillAudio()

1 - RGB Spline36Resize
RGB ColorBars upscaled with Spline36

2 - RGB Resize8 & Spline36
RGB ColorBars upscaled with Resize 8 (Spline36) and it's default ringing repair.

https://i.postimg.cc/NL705zmR/1-RGB-Spline36.png (https://postimg.cc/NL705zmR)

https://i.postimg.cc/mtLgMyyJ/2-RGB-Resize8-Spline36.png (https://postimg.cc/mtLgMyyJ)

https://i.postimg.cc/bY4SFXvV/1-RGB-Spline36.png
https://i.postimg.cc/8PWJ2yJp/2-RGB-Resize8-Spline36.png

ColorBars().KillAudio().ConvertToYV12(matrix="rec709")

3 - YV12 Spline36Resize
YV12 ColorBars upscaled with Spline36

4 - YV12 Resize8 & Spline36
YV12 ColorBars upscaled with Resize8 (Spline36) correcting the resizer chroma shift and default ringing repair.

https://i.postimg.cc/F7TsxkPR/3-YV12-Spline36.png (https://postimg.cc/F7TsxkPR)

https://i.postimg.cc/23f6jDbz/4-YV12-Resize8-Spline36.png (https://postimg.cc/23f6jDbz)

https://i.postimg.cc/T36Lfrgr/3-YV12-Spline36.png
https://i.postimg.cc/DfSbgf7b/4-YV12-Resize8-Spline36.png

[DTL]

"Avisynth wiki says the default for P for Gauss is 30.0 and for SinPowResizeMT it's 2.5, so if they're directly comparable,"

No. SinPowResize only have same arguments order and naming. It was just easy way of making just another copy of resize function having 1 user-defined control param. The control values of p-param is completely different and results with current default values different too. Same UserDefined2ResizeMT was a copy of BicubicResize only as a resize function taking 2 user-defined control params.

"ColorBars()."

Current Avisynth (+) ColorBars output may be correct for levels reference but completely illegal for moving picture (typical video) data resizers testing because it generates completely unconditioned to moving pictures data levels transitions. It may be used only for testing resizers for 'pixel-art'.

To make about conditioned for 'film-looking' source for typical sinc-based signal processing workflow something like


unc=ColorBars(640*10, 480*10)
UserDefined2ResizeMT(unc, unc.width/10, unc.height/10)

(i.e. using default control params b and c values 121 and 19)

may be used.

And yes - older SinPowResize can not reach same level of conditioning quality even with p about 3. It is easier to use with only 1 control param but gives a bit lower quality (for perfectionists lab tests) in compare with UserDefined2Resize with at least 2 control params.

Close result is from

unc=ColorBars(640*10, 480*10)
GaussResizeMT(unc, unc.width/10, unc.height/10,p=12).


Though Gauss can not produce 'video-look' because of non-over/undershooting. So for sort of 'video-look' simulation something like

unc=ColorBars(640*10, 480*10)
UserDefined2ResizeMT(unc, unc.width/10, unc.height/10, b=83, c=-12)

may be used.

Unfortunately many of Avisynth's functions are from the very old days of processing 'Computer-pictures' like pixel-art data and not 'video data'. So the functions must be used with care.

[hello_hello]

I don't know how you'd classify animation, but I tried SinPowResize (downscaling 1080p to 720p) and didn't think it was well suited for that. It requires p=2.8 to eliminate most of the artefacts but by then it's starting to blur too much.

For "normal" video it seems fine though. The default of p=2.5 is a little too sharp for me, whereas for p=2.6 I was having a hard time telling it apart from Spline36 most of the time.

[DTL]

I don't know how you'd classify animation,

If upscaled with target system Sinc it is visible at levels transitions - 'film-look' is smoother and not over/under-shoots. and 'video-look' do have over/under-shoots at levels transitions and it adds to 'sharpness/crispening'.

Two versions of upscaled 3x colorbars with SincLin2ResizeMT(width*3, height*3, taps=16):
https://i1.imageban.ru/out/2021/07/19/001b5203e6941e0e7d5cfece76cdbb56.png