Resize8 - An updated version of the original resizing function

[tormento]

Thanks.

Why you didn't set the chroma default as top-left? Usually that's the one used for AVC/HEVC encoding.

Moreover: is there a way to make it work and output arbitrary bitdepth, such as 10/16/32?

Otherwise I need to put

z_ConvertFormat(resample_filter="spline64",dither_type="error_diffusion",pixel_type="yuv420p16")

before the Resize8 line and, on my slow cpu, it's stealing some cycles instead of having it done internally.

[hello_hello]

The default is left as it's the default for all chroma placement aware resizers, to the best of my knowledge. The native Avisynth functions that support chroma placement, such as ConvertToYUV420(), also default to left. It doesn't really matter though, as if the chroma placement is specified in frame properties it's the placement that's used.

The original version of the function was intended to correct the chroma shift while using Avisynth's resizers as they're (still) not chroma placement aware, but even though the updated version supports any resizer with the same named arguments for cropping as Avisynth's resizers, they don't necessarily have the ability to change the bitdepth, and when they do they have different arguments for specifying it. The only practical way for Resize8 to change the bitdepth would be to use ConvertBits(), but I'm not sure if there's much point when it's easy enough to add ConvertBits to a script.

Edit: If you're using a chroma placement aware resizer then it might be simpler to use it instead, especially if it can change the bitdepth. These should give you an identical output if the chroma location is "left".

ConvertBits(16).Resize8(940,540, kernel="z_Spline64Resize")
ConvertBits(16).z_Spline64Resize(940,540)
z_ConvertFormat(940,540, resample_filter="Spline64", pixel_type="YUV420P16")

For some reason though, you have to tell z_ConvertFormat to use the chroma location in frame properties otherwise it assumes "left", but for a "top_left" chroma location in frame properties these should produce an identical result. I'm not sure why the default chroma location for z_ConvertFormat isn't "auto" rather than left, but it appears not to be, so without chromaloc_op="auto=>same" the output isn't identical as Resize8 would use "top_left" but z_ConvertFormat wouldn't.

propSet("_ChromaLocation", 2) # top_left

A = ConvertBits(16).Resize8(940,540, kernel="z_Spline64Resize")
B = z_ConvertFormat(940,540, resample_filter="Spline64", pixel_type="YUV420P16", chromaloc_op="auto=>same")

Compare(A,B)

[Z2697]

"top_left" is not the default, default is "left", not only in all chroma placement aware resizers, but also true for virtually all encodings "below" UHD Bluray - they just somehow suddenly decided to change it to top_left

[tormento]

Originally Posted by Z2697

"top_left" is not the default, default is "left", not only in all chroma placement aware resizers, but also true for virtually all encodings "below" UHD Bluray - they just somehow suddenly decided to change it to top_left

Is there a way to determine where chroma placement is?

I mean, without frame properties.

[hello_hello]

Originally Posted by tormento

Is there a way to determine where chroma placement is?

I mean, without frame properties.

I'm pretty sure FFMS2, lsmash and BestSource all write the chroma location to frame properties.
x264 and x265 both have a command line option --chromaloc so it's obviously saved as Video Usability Information, but I don't recall MediaInfo displaying it. That doesn't necessarily mean it doesn't, if it exists, as my memory isn't great.

https://x265.readthedocs.io/en/maste...mation-options

[FranceBB]

Mediainfo doesn't explicitly mention it, however when it says 4:2:0 without anything it means left (the good old MPEG-2 standard) and when it says Type 2 it means top_left (the "new" H.265 standard). Other tools like ffprobe or indeed the two Avisynth indexers you mentioned display it explicitly.

[StvG]

Originally Posted by hello_hello

For some reason though, you have to tell z_ConvertFormat to use the chroma location in frame properties otherwise it assumes "left", but for a "top_left" chroma location in frame properties these should produce an identical result. I'm not sure why the default chroma location for z_ConvertFormat isn't "auto" rather than left, but it appears not to be, so without chromaloc_op="auto=>same" the output isn't identical as Resize8 would use "top_left" but z_ConvertFormat wouldn't.

The chroma location is "auto" when there is valid _ChromaLocation frame prop and reading frame props are enabled (use_props=-1*/1). In the rest cases a default value is used ("left").

* If the conditions are met.

Originally Posted by hello_hello

I'm pretty sure FFMS2, lsmash and BestSource all write the chroma location to frame properties.

Yes, when ffmpeg also signals (not always) the chroma location.

[hello_hello]

Ah..... yes, these seem to produce the same result.

propSet("_ChromaLocation", 2) # top_left
A = z_ConvertFormat(940,540, resample_filter="Spline64", pixel_type="YUV420P16", use_props=1)
B = z_ConvertFormat(940,540, resample_filter="Spline64", pixel_type="YUV420P16", chromaloc_op="auto=>same")
Compare(A,B)

Could I ask why the default for use_props isn't 1 though?
Would it be more intuitive if the default for use_props was 1 but it automatically switched to -1 when the colorspace_op or chromaloc_op arguments are used? That way z_ConvertFormat would use any frame properties that exist without the user having to tell it to, but it'd ignore them and do something else when values for colorspace_op or chromaloc_op are specified. Maybe I'm missing something....

Cheers.

[StvG]

B = z_ConvertFormat(940,540, resample_filter="Spline64", pixel_type="YUV420P16", chromaloc_op="auto=>same") - is using use_props=1. From doc - "-1: If frame properties are supported - if every value of colorspace_op and every value of chromaloc_op is specified, and it's different than "auto", 0, otherwise 1."

So you're comparing the same processing.

Maybe you want - B = z_ConvertFormat(940,540, resample_filter="Spline64", pixel_type="YUV420P16", chromaloc_op="top_left=>top_left"). In this case use_props=0 is used.

The default use_props is -1 - meaning its auto selected between 0 and 1 depending on the used command. Compare the speed of A with the new B (with use_props=0). The reason for the default value of -1 - for some filtering one can completely ignore the frame props (changing only bit depth or just resizing RGB/YUV444 video...) and can benefit from the better speed.

Maybe I could add the case when a video with chroma subsampling is resized and use_props=-1 used, the frame props to be read.

[tormento]

Are descale operators (1,2) supported too?

If positive, what are the theorical results for noring=true, noring_c=true, fullc=true parameters and precise chroma position?

Are Lanczos 2/3/4 aliases for a1=2,3,4 or are they different beasts?

P.S: for the owner of Avisynth Wiki, the Resize8 page is vastly outdated.

[pinterf]

Just a note: wiki maintenance is done by ourselves. It's by far not the owner's task.

[tormento]

Originally Posted by pinterf

Just a note

As you can see, I put it as annotation for the maintainer of the Wiki

[Jamaika]

Originally Posted by tormento

Are descale operators (1,2) supported too?

If positive, what are the theorical results for noring=true, noring_c=true, fullc=true parameters and precise chroma position?

Are Lanczos 2/3/4 aliases for a1=2,3,4 or are they different beasts?

P.S: for the owner of Avisynth Wiki, the Resize8 page is vastly outdated.

You have two Lanczos functions: LanczosResizeMT, Lanczos4ResizeMT, z_LanczosResize, z_Lanczos4Resize.
You can test with Jamaika
By default, "Lanczos4" is set for luma upscaling, "Lanczos" is set for chroma upscaling, "Spline36" is set for luma/chroma downscaling.
For the default kernel of downscaling, kernel="Spline36"+noring=True is applied for luma/chroma, but the adaptive anti-ringing will turn off anti-ringing. Resize8 will delete noring.

This should probably be deleted.
http://avisynth.nl/index.php/Descale
I know there will be grumbling soon. No SIMD. Projest doesn't support NASM under GCC/MINGW.
http://avisynth.nl/index.php/ResampleMT

https://www.sendspace.com/file/foq5f1

[hello_hello]

This version of the function has diverged from the original quite a lot and I've never attempted to update the wiki, although with it's default settings (same as the original) the output should be the same. The original version only supported the resizers it was aware of, whereas this version should support any resizer with the same cropping arguments as the Avisynth resizers.

If you're referring to using the DeScale functions, they should work. If not, let me know. The difference is the a1, a2 and a3 arguments can't be used, but you can use the RStr argument instead.

Resize8(w,h, kernel="DeBicubic", RStr="b=1.0/3.0, c=1.0/3.0")

The ResampleMT DeScale functions weren't included as "known" resizers, so the same applies.

Resize8(w,h, kernel="DeBicubicResizeMT", RStr="b=1.0/3.0, c=1.0/3.0")

If a resizer argument is a string, you can use triple quotes.

Resize8(w,h, kernel="SomeResizer", RStr=""" arg1=4, arg2="SomeString" """)

Originally Posted by tormento

Are descale operators (1,2) supported too?

If positive, what are the theorical results for noring=true, noring_c=true, fullc=true parameters and precise chroma position?

Are Lanczos 2/3/4 aliases for a1=2,3,4 or are they different beasts?

P.S: for the owner of Avisynth Wiki, the Resize8 page is vastly outdated.

Yes, for Lanczos2 a1=2 is automatically set, which translates to LanczosResize(w,h, taps=2).
This is from the function (below line 251) where strings are created to configure the arguments, and you can probably see the a1 argument can be used to set a taps value for Lanczos, but not for the aliases.

arg1_Kl = (Kl == "Lanczos")   ? (IsA1 ? ", taps=" + R8_FS(a1) : "") :
\         (Kl == "Lanczos2")  ? ", taps=2" :
\         (Kl == "Lanczos3")  ? ", taps=3" :
\         (Kl == "Lanczos4")  ? "" : .....

The ringing repair works by creating a second resized version of the clip with GaussResize(w,h, p=100) as GaussResize is sharp without ringing. As with the resizing of the video itself, each plane is resized individually. Resize8 uses the resizer to crop the UV planes to prevent chroma shift or to change the chroma placement, so the same U and V cropping is applied to both clips. As an example:

U1 = LanczosResize(640,360, -0.14,0,640,360)
U2 = GaussResize(640,360, -0.14,0,640,360, p=100)
U3 = Repair(U1, U2)
U =  Merge(U1, U3, weight)

Where weight is the amount of ringing repair. By default the weight is calculated according to the degree of up-scaling, and by default it's mostly disabled, but it is automatically enabled for the sharper Avisynth and ResampleMT resizers such as Spline and Lanczos, although only when upscaling. If you use noring=true yourself, it'll be applied to any resizer, and can be applied when upscaling or downscaling. I'm pretty sure noring=false ensures the ringing repair is always disabled.

[pinterf]

Originally Posted by tormento

As you can see, I put it as annotation for the maintainer of the Wiki

O.K., anyway it's not easy to be an editor, mainly answering the anti-spam questions can be annoying and one has to accomodate to the doc writing syntax. I think it's good to drop a line to the documentation help requested for new mediawiki topic directly if someone would take care of that section.

[tormento]

Originally Posted by hello_hello

If you're referring to using the DeScale functions, they should work. If not, let me know. The difference is the a1, a2 and a3 arguments can't be used, but you can use the RStr argument instead.

Please let me know what I am doing wrong.

I want to replace

z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")
DeLanczos4ResizeMT (1600,900, threads=1, prefetch=2, accuracy=2)
fmtc_bitdepth (bits=10,dmode=8)

with Resize8

z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")
Resize8(1600,900, kernel="DeLanczos4ResizeMT", kernel_c="DeLanczos4ResizeMT", RStr="threads=1, prefetch=2, accuracy=2", noring=true, noring_c=true, fullc=true)
fmtc_bitdepth (bits=10,dmode=8)

but I get

ResizeHMT: Error while GetDesamplingProgram for luma!
(Resize YUV Eval, line 10)
(D:/Programmi/Media/AviSynth+/plugins64/Resize8-2024_1101~hello_hello.avsi, line 668)

[tormento]

I get the very same error even without passing parameters, i.e.

z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")
Resize8(1500,844, kernel="DebilinearResizeMT", noring=true, noring_c=true, fullc=true)
fmtc_bitdepth (bits=10,dmode=8)

[Jamaika]

I look at what tormento is complaining about. And how does it work in ffmpeg Jamaica?
Test came out badly. Errors in ResampleMT. Sample functions work but desample functions don't. Problem with GetDesamplingData. I modified ResampleMT as best could and something started working.

z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")
Resize8(1280,720, kernel="DeSpline64ResizeMT", kernel_c="DeSpline64ResizeMT", RStr="threads=1, prefetch=2, accuracy=2", noring=true, noring_c=true, fullc=false)

https://www.sendspace.com/file/1z8joy

[hello_hello]

If you try this using a source with a lower resolution than 1920x1080 (although I only tested 720p), it will produce the same error.

DeLanczos4ResizeMT(1920,1080)

So I assume it means you can only use the de-sampling kernels for downscaling and upscaling the chroma is causing the error. Without fullc=true there is no error, although something worse might happen....
While using Resize8 with ResampleMT in the past I've bumped into a few oddities (I found one post where I'd reported a problem). At the time though it seemed unlikely that it'd occur very often, but I found another example while playing around.

Downscaling a 1080p image to 900p with a standard resizer and ringing repair enabled I get a normal output, but when I do the same using a desampling resizer with ringing repair enabled I get this (the screenshots seem to have been downscaled by the hosting site so they mightn't be 1600x900):

Resize8(1600,900, kernel="DeLanczos4ResizeMT", RStr="threads=1, prefetch=2", noring=true)
https://i.ibb.co/k2GX8QQr/1.png

What seems to be happening is Resize8 is telling the resizer to crop the U and V planes to prevent chroma shift, and in the case of the descale kernel it's causing ReSampleMT to do odd things. Using the same 1920x1080 image as the source I was able to reproduce the problem. This simply downscales the video as you'd expect:

Lanczos4ResizeMT(1600,900, 0.5,0,1920,1080)
https://i.ibb.co/C5b6yhMY/2.png

But this crops a slab of picture:

DeLanczos4ResizeMT(1600,900, 0.5,0,1920,1080)
https://i.ibb.co/7NQDdsTQ/3.png

I don't know if it's a problem with all of the descaling kernels yet as I've not played around any more.

By the way, unlike the original Resize8, if your specify a resizer using the kernel argument it's also applied to kernel_c, then as long as the luma and chroma kernels are the same, it works the same way for the other arguments. noring=true would also be applied to noring_c unless you specify something yourself for noring_c. The same is true for the RStr and RStr_c arguments.

Resize8(1600,900, kernel="Lanczos4ResizeMT", RStr="threads=1, prefetch=2", noring=true, show=true)
If the hosting site decides to scale the screenshot again, you'll probably need to enlarge it to read the text.
https://i.ibb.co/Gz7Qmv6/4.png

[hello_hello]

It looks like you don't have to crop. Just specifying the source width and height is enough to cause a problem for the desampling functions.
I don't know if it's by design, but it appears src_width and src_height need to be the output width and height when desampling.
For a 1080p source:

Lanczos4ResizeMT(960,540, src_left=0, src_top=0, src_width=1920, src_height=1080)
or
DeLanczos4ResizeMT(960,540, src_left=0, src_top=0, src_width=960, src_height=540)
https://imgbb.io/ib/eiglUWs5APWt5Cs_1738174696.jpg

DeLanczos4ResizeMT(960,540, src_left=0, src_top=0, src_width=1920, src_height=1080)
https://imgbb.io/ib/yKzioK91a9M3NVp_1738174696.jpg

Something's definitely amiss with the ResampleMT plugin itself. Another example (same 1080p source):

Lanczos4Resize(960,540, src_left=0, src_top=0, src_width=960, src_height=540)
Outputs the expected result:
https://imgbb.io/ib/lp3dYTSgdt6EA1l_1738174696.jpg

Lanczos4ResizeMT(960,540, src_left=0, src_top=0, src_width=960, src_height=540)
The error message:
https://imgbb.io/ib/N2r0AhZvbDDDmnL_1738174693.jpg

I'm using ResampleMT included in Plugins_JPSDR.dll, so I'm assuming the result will be the same for the individual ResampleMT dll.

Side Note: It appears when an image is being resized in AvsPmod's preview and you use the "Video/Save Image" menu, AvsPmod saves the image in it's zoomed state. I'd been assuming it's saved at it's original resolution, but it isn't, so the first three screenshots above should be 960x540, but they're actually 974x548 or 978x550.