Resize8 - An updated version of the original resizing function

[hello_hello]

Actually, I'd prefer that you could fix that issue, perhaps having two different workpath for resize and downscale. :p

The main idea of Resize8 was to correct the chroma shift created by Avisynth's resizers, but without having put any real thought into it, I'm not sure it'd be possible or even practical when using a descaling resizer. Plus if you're descaling, I don't know if there's a way to know for sure if it was upscaled while correcting the chroma shift. I'd be thinking it's safer to assume it wasn't.

If I remember correctly, for a left chroma placement, a 2x upscale shifts the chroma a quarter of a pixel to the left, and for a 2x downscale it's half a pixel to the right, so it's not drastic unless you're resizing by a large amount, but according to jpsdr's latest post it's not possible to correct a shift with the descaling resizers anyway.

You could decide for yourself if the chroma needs shifting and by how much after resizing or descaling.
http://www.avisynth.nl/index.php/ChromaShiftSP
http://avisynth.nl/index.php/PixelShiftPlus

A function for doing it automatically I've never tried:
https://forum.doom9.net/showthread.php?t=166834

A function for shifting the chroma so you can decide what it takes for it to look aligned. I've not used this one either:
https://forum.doom9.org/showthread.php?t=173685

[tormento]

The main idea of Resize8 was to correct the chroma shift created by Avisynth's resizers
Thank you.

When downscaling, has noring and noring_c = true any effect on final output or are them simply discarded?

[hello_hello]

Yes it can be applied when downscaling (the original Resize8 would only apply ringing repair when upscaling). To be honest I'm not sure how necessary or effective it'd be to apply it when downscaling, but it can be enabled either way.

The automatic ringing repair is still enabled by default when upscaling but only for the sharper Avisynth resizers. For any other resizers it has to be enabled manually with either noring=true, in which case the amount of ringing repair is calculated according to the degree of upscaling or downscaling, or by specifying the amount of ringing repair yourself, where noring=0.5 is 50% and noring=1.0 is 100% etc.

Keep in mind the ringing repair will only be able to repair any ringing that's created when you resize a video. It'll likely have no effect on pre-existing ringing, aside from maybe preventing the resizing from making it worse.

[hello_hello]

There's a link to a new version dated 2025-03-25 in the opening post.

Fixed the SAR being calculated and written to frame properties not always being correct when the Resize8 arguments for cropping were used.
Added support for the new GaussResize arguments "b" and "s", via the "a2" and "a3" arguments respectively.

[tormento]

There's a link to a new version dated 2025-03-25 in the opening post.
:thanks:

Is there any change to support the "new" AVS+ resize changes?

[hello_hello]

I don't think there's anything to support as such, aside from adding the new GaussResize arguments as Resize8 does the chroma placement correction itself.
Is there anything else that should be updated in respect to the Avisynth resizers?

Thinking about it, the main difference is when there's no chroma placement in frame properties, Resize8 defaults to using "left"' whereas the Avisynth resizers still default to "center" for some reason.

Edit: And now I've looked more closely, the native resizers in Avisynth 3.7.4 support chroma placement in respect to not causing it to shift relative to the luma, but they don't have an argument for changing the chroma location while resizing.

[tormento]

Would be possible/useful to use NEEDI3/NEEDI3CL to upscale chroma to 444 before any resize?

[hello_hello]

I think this would do it. You'd need to move the chroma location to center first (I assume).

A = z_ConvertFormat(chromaloc_op="left=>center") # or Resize8(CPlace="left", CPlaceD="center")
B = A.nnedi3_rpow2(2)
C = A.ExtractY()
D = B.ExtractU()
E = B.ExtractV()
CombinePlanes(C,D,E, planes="YUV", source_planes="YYY", pixel_type="YUV444P8")


Edit: z_ConvertFormat and Resize8 won't produce identical results in the example above, according to Compare(), but I discovered that's probably mainly due to the different way they shift the chroma. Resize8 uses the resizer, so for the Avisynth resizers that means repeating the edge pixels as the picture is shifted. z_ConvertFormat does it by creating a mirror image of the edge pixels. This would produce the same result with Resize8.

Resize8(CPlace="left", CPlaceD="center", kernel="z_ConvertFormat")

If you want to see an extreme example of the difference in the way they shift pixels, try this.

Spline36Resize(width(),height(), -50,-50,width(),height())
or
Resize8(width(),height(), -50,-50,width(),height(), kernel="Spline36Resize")
vs
z_Spline36Resize(width(),height(), -50,-50,width(),height())

For shifting a fraction of a pixel it doesn't really matter, and logically to me, unless you shift by more than one pixel they should be the same, but maybe it explains most of the difference when using Compare() after a small pixel shift.

[DTL]

Would be possible/useful to use NEEDI3/NEEDI3CL to upscale chroma to 444 before any resize?

NNEDI was trained to fix aliasing artifacts. For better fix the distortions of old ugly chroma-subsampled digital designs we need to train and use some other neural network.

Chroma subsampling do not directly produce aliasing but because half-band Y data is missed at encoder side - it produce different distortions.