Resize8 - An updated version of the original resizing function

[tormento]

Originally Posted by hello_hello

Just specifying the source width and height is enough to cause a problem for the desampling functions

So, conclusion is that there is nothing to do to make them working?

[hello_hello]

Pretty much.
Can you use the Descale plugin?
http://www.avisynth.nl/index.php/Descale

Edit: Apparently not (1080p source again).

LanczosResize(1280,720, src_left=0,src_top=0,src_width=1920,src_height=1080)
https://i.ibb.co/bM8VhpBs/C.jpg

DeLanczos(1280,720, src_left=0,src_top=0,src_width=1920,src_height=1080)
https://i.ibb.co/xtY58s7j/D.jpg

I've only checked the 64 bit Avisynth version so I don't know if the VapourSynth version has the same problem, although obviously Resize8 is an Avisynth script and you were wanting to use the descaling functions with it anyway.

[tormento]

Originally Posted by hello_hello

Edit: Apparently not (1080p source again).

Is a plugin issue or a script one?

If the plugin, we could ask to jpsdr.

[hello_hello]

It's a plugin issue because you can't use the src_width and src_height arguments as expected. Most of the examples I've posted screenshots for didn't involve Resize8 at all.

I've reported ResampleMT problems to jpsdr a couple of times (I posted a link to one report in an earlier post) but back then he said he didn't have any spare time to look at it, although he hoped to in the future. I guess he's still too busy.

The 64 bit Avisynth version of the Descale plugin I tested came from here, so you could report the bug there if you want to.

Resize8 always uses the src_width and src_height arguments. It has to use them to crop the chroma correctly to prevent chroma shift. The CropResize function also uses the resizer for sub-pixel cropping to prevent aspect error, which is when I think I first discovered there was a ResampleMT bug. Most people probably don't use the resizers for cropping so the problems have gone unnoticed.

[jpsdr]

Be sure to follow what said in the readme and in the exemple :
"The usage is the following : You have to enter in the parameters exactly the same that have been used for the original resampling, except the size of course, where you specify the original size you want back."

So, if your source is 1920x1080, you do :
LanczosResize(MT)(1280,720, src_left=0,src_top=0,src_width=1920,src_height=1080)

To desample you do :
DeLanczosResizeMT(1920,1080, src_left=0,src_top=0,src_width=1920,src_height=1080) or DeLanczos(1920,1080, src_left=0,src_top=0)

Don't know how to make color, so i'm using italic and bold.

The other issue, still no time unfortunately...

[tormento]

I need to downscale a 4k video that is 420 type 2 to 1080p.

Will Resize8 deal with the type 2 automatically?

[hello_hello]

Yes. If you want to check the exact resizing and chroma placement used, add Info=true. If you're not able to do that due to an error message, use Show=true instead. The former displays the info over the resized video, while the latter bypassing the actual resizing to prevent an error from occurring, and displays the same info over a blank clip instead.

Any chroma placement in frame properties should be shown. The chroma placement actually being used is also shown, as it may be different to the chroma placement in frame properties if you tell Resize8 to do something else via the CPlace arguments. I posted an example screenshot earlier, although the text is fairly small due to the image having been downscaled. https://i.ibb.co/Gz7Qmv6/4.png

As you've no doubt discovered from reading jpsdr's post, the src_width and src_height arguments have a different meaning for the descaling resizers, so they won't work correctly with Resize8. If ever I have a need to update Resize8 again, I'll try to add an error message to prevent the descale functions being used. They all begin with "de" if I remember correctly, so it shouldn't be hard.

[tormento]

Originally Posted by hello_hello

I'll try to add an error message to prevent the descale functions being used. They all begin with "de" if I remember correctly, so it shouldn't be hard.

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

[tormento]

Originally Posted by hello_hello

as it may be different to the chroma placement in frame properties

Is there any way to understand the real chroma subsampling position without frame/stream properties? I mean just "looking" at the elementary stream itself.

[jpsdr]

Originally Posted by hello_hello

As you've no doubt discovered from reading jpsdr's post, the src_width and src_height arguments have a different meaning for the descaling resizers

The Desample don't crop or anything, and of course cannot get back the originaly cropped pixels...

[hello_hello]

Originally Posted by tormento

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

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]

Originally Posted by hello_hello

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]

Originally Posted by hello_hello

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

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]

Originally Posted by tormento

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.