Resize8 - An updated version of the original resizing function

[hello_hello]

This is an updated version of Resize8 1.2 2015.02.23 by mawen1250.

Resize8 2025-03-25.zip (https://files.videohelp.com/u/210984/Resize8%202025-03-25.zip)

The initial changes compared to the original Resize8 are listed in the next post.

-----------------------------

From version 2024-06-22, it's possible to configure the way the sample/pixel aspect ratio in frame properties is updated:

When resizing with most resizers, unless the storage aspect ratio (width / height) for the resized video matches the storage aspect ratio of the source video, the resizing stretches the video in some manner. In order to prevent that a new sample aspect ratio must be calculated manually and used when encoding the video. Some newer resizers such as the AVSResize plugin (or VapourSynth's native resizers) will read the source video's sample aspect ratio in frame properties and update it after resizing, but sometimes you might want to specify a new sample aspect ratio manually in order to stretch the video and correct the way it displays. Therefore....

Three new arguments have been added relating to the SAR written to frame properties after resizing.
These arguments have no affect on the resizing, only the SAR written to frame properties.

DAR (float - display aspect ratio). The default is 0.0, which means an unspecified DAR.
SAR (float - sample aspect ratio). The default is 0.0, which means an unspecified SAR.
Keep (bool). The default is false. Keep determines whether Resize8 calculates a new SAR after resizing, keeps the source SAR, or keeps the source DAR after resizing if one is specified and calculates a new SAR accordingly.

If neither a DAR or SAR are specified Resize8 takes the source SAR from frame properties, if one exists.
If a DAR is specified Resize8 converts it to a SAR and uses it as the source SAR.
If a SAR is specified Resize8 uses it as the source SAR.

When keep=false (the default) Resize8 always calculates a new SAR after resizing and writes it to frame properties.

When keep=true and no DAR is specified, Resize8 writes the source SAR to frame properties after resizing, while calculating a new DAR for the resized video (displayed when Info or Show are true).
If a DAR is specified when keep=true, it becomes the DAR for the output video, therefore Resize8 calculates a new SAR for frame properties after resizing (also displayed when Info or Show are true).

There's also a new argument named Info. Like the Show argument, Info=true displays the resizing strings as well as the input and output aspect ratios, but instead of displaying that info over a blank clip as Show=true does, Info=true displays it over the resized video.

Some examples:

Resizing a non-anamorphic 16:9 video to a different aspect ratio and calculating a new SAR.
The DAR remains unchanged.

Resize8(1048,576, Info=true)

https://i.postimg.cc/Vs9gxMSw-/Resize-Non-Anamorphic-1.jpg

Stretching a non-anamorphic 16:9 video while resizing and therefore keeping the original SAR.
The video has a new DAR.

Resize8(1048,576, keep=true, Info=true)

https://i.postimg.cc/Hspzdx5y/Resize-Non-Anamorphic-2.jpg

Resizing a 16:9 NTSC DVD to 16:9 PAL dimensions.

Resize8(720,576, Info=true)

https://i.postimg.cc/HsB2xg4P/Resize-NTSC-1.jpg

Over-riding the SAR in frame properties for the 16:9 NTSC DVD and resizing to PAL dimensions.

Resize8(720,576, SAR=40.0/33.0, Info=true)
or
Resize8(720,576, DAR=20.0/11.0, Info=true)
or
Resize8(720,576, SAR=16.0/11.0, keep=true, Info=true)

https://i.postimg.cc/zGvkHcxD/Resize-NTSC-2.jpg

[hello_hello]

Changes compared to the original Resize8.
The default output should be exactly the same as the original.

--- There's a help file of sorts.

--- All Avisynth+ color spaces and bitdepths are supported.

--- Any resizer with the same arguments for cropping as the native Avisynth resizers can be used.

--- The Jinc, ResampleMT and SplineResize plugins are added as "known" resizers.
The SplineResize plugin kernels are limited to 8 bit video, and don't support all color spaces.
For SplineResize the individual planes are converted to YV12 for resizing, so all Avisynth 2.6
colorspaces are supported that way.
Support for the SplineResize plugin as a native resizer has been removed since version 2024-06-22.

--- The Resize8_Separate() function has been removed, but it's functionality is retained via
an additional Resize8 argument "separate", so Resize8(separate=true) can be used instead.

--- New arguments, "RStr" and "RStr_c", for specifying named arguments as strings. They can be used
instead of the a1 and a2 arguments for "known" resizers.
For example:
Resize8(1280,720, kernel="Bicubic", RStr="b=0.5,c=0.5")
Resize8(1280,720, kernel="Spline36ResizeMT", RStr="prefetch=4, threads=2")

--- New "show" argument
show=true bypasses the resizing stage and opens a blank clip to display the full resizing strings
as subtitles, as well as some other basic info. It might be useful if there's problems using the
"RStr" arguments, or just to confirm the function is behaving as expected.

--- Resize8 will attempt to use the the ResampleMT plugin for it's default resizing, but if it's not
loaded it will use the native Avisynth resizers instead.

--- When specifying a luma resizer with the kernel argument, the same kernel is now
automatically used for chroma, unless a different chroma resizer is specified with kernel_c.
Likewise, the "_c" arguments now default to the same values as their non "_c" counterparts,
but only when the same kernel is used for both luma and chroma (when kernel = kernel_c).

--- Adaptive ringing repair now works when downscaling, not just upscaling, but it's disabled
for downscaling by default. It's also disabled for all "unknown" resizers by default.

--- For RGBA, the luma kernel is applied to the R-G-B-A planes, except when a chroma kernel is specified
or the default kernels are used, in which case the chroma kernel is used for the alpha plane.
For YUVA, the luma kernel is applied to the Y-U-V-A planes, except when a chroma kernel is specified
or the default kernels are used, in which case the chroma kernel is used for the U-V planes.

--- The "alpha" argument behaves a little differently.
If the source has no alpha plane and alpha=true, one will be added to the output when possible.
The defaults for alpha are true when an alpha plane exists, and false when it doesn't.

--- Added some simple, one line functions to the end of the Resize8 script. They can easily be modified
to change the default resizing kernels and set default resizer strings.

--- There's a help file of sorts.

--- All Avisynth+ color spaces and bitdepths are supported.

--- Any resizer with the same arguments for cropping as the native Avisynth resizers can be used.

--- The Jinc, ResampleMT and SplineResize plugins are added as "known" resizers.
The SplineResize plugin kernels are limited to 8 bit video, and don't support all color spaces.
For SplineResize the individual planes are converted to YV12 for resizing, so all Avisynth 2.6
colorspaces are supported that way.

--- The Resize8_Separate() function has been removed, but it's functionality is retained via
an additional Resize8 argument "separate", so Resize8(separate=true) can be used instead.

--- New arguments, "RStr" and "RStr_c", for specifying named arguments as strings. They can be used
instead of the a1 and a2 arguments for "known" resizers.
For example:
Resize8(1280,720, kernel="Bicubic", RStr="b=0.5,c=0.5")
Resize8(1280,720, kernel="Spline36ResizeMT", RStr="prefetch=4, threads=2")

--- New "show" argument
show=true bypasses the resizing stage and opens a blank clip to display the full resizing strings
as subtitles, as well as some other basic info. It might be useful if there's problems using the
"RStr" arguments, or just to confirm the function is behaving as expected.

--- Resize8 will attempt to use the the ResampleMT plugin for it's default resizing, but if it's not
loaded it will use the native Avisynth resizers instead.
The ResampleMT plugin is no longer used by default from version 2024-06-22.

--- When specifying a luma resizer with the kernel argument, the same kernel is now
automatically used for chroma, unless a different chroma resizer is specified with kernel_c.
Likewise, the "_c" arguments now default to the same values as their non "_c" counterparts,
but only when the same kernel is used for both luma and chroma (when kernel = kernel_c).

--- Adaptive ringing repair now works when downscaling, not just upscaling, but it's disabled
for downscaling by default. It's also disabled for all "unknown" resizers by default.

--- For RGBA, the luma kernel is applied to the R-G-B-A planes, except when a chroma kernel is specified
or the default kernels are used, in which case the chroma kernel is used for the alpha plane.
For YUVA, the luma kernel is applied to the Y-U-V-A planes, except when a chroma kernel is specified
or the default kernels are used, in which case the chroma kernel is used for the U-V planes.

--- The "alpha" argument behaves a little differently.
If the source has no alpha plane and alpha=true, one will be added to the output when possible.
The defaults for alpha are true when an alpha plane exists, and false when it doesn't.

--- Added some simple, one line functions to the end of the Resize8 script. They can easily be modified
to change the default resizing kernels and set default resizer strings.

[hello_hello]

Sigh.... I realised a did a silly with rounding for a couple of numbers that display when show=true.

There's a link for the fixed version dated 2021-08-06 in the opening post.

[kedautinh12]

I click linked and it's open post again

[hello_hello]

I don't know why but it's working now. It's probably just as well as my last fiddle with the way the strings display when show=true caused the right and bottom cropping to display as positive when they should be negative, and the other way around. It's fixed now.

[hello_hello]

New version dated 2021-09-07 in the opening post.

Resize8 is supposed to fall back to using the internal Avisynth resizers for it's default resizing instead of the MT resizers if the ResampleMT plugin isn't loaded. Instead it was producing an error message unless a non-MT resizer was specified manually. That's fixed now. The default resizing methods haven't changed.

[hello_hello]

New version dated 2021-12-30 in the opening post.

[hello_hello]

New version dated 2022-09-23 in the opening post with a minor bug fix.

An alpha plane wasn't always being added when it should have been.

[hello_hello]

New version dated 2023-02-03 in the opening post. See the opening post for details.

[hello_hello]

New version dated 2023-02-09 in the opening post. See the changelog (just some minor tweaks).

[hello_hello]

New version dated 2024-01-18 in the opening post. See the "changes" text file in the zip file for details.

[hello_hello]

New version dated 2024-06-15 in the opening post. See the "changes" text file in the zip file for details.

[hello_hello]

New version dated 2024-06-22 in the opening post.
There's also a description of the new functionality, with some pictures to illustrate.

[hello_hello]

I fixed a problem with an error message not displaying and re-uploaded the zip file. It's not important, so I left the version date the same (2024-06-22).

[hello_hello]

After a lot of changes, apparently missing a few minor bugs is inevitable.
There's a link for a new version dated 2024-06-24 in the opening post.
Changes in the included text file.

[hello_hello]

There's a new version dated 2024-10-02 in the opening post.

[tormento]

There's a new version dated 2024-10-02 in the opening post.
While you are fixing your last version, what are the limitations of this one?

[hello_hello]

While you are fixing your last version, what are the limitations of this one?

No limitations as such, but I'll upload the new version dated 2024-11-01 shortly (the link will be in the opening post).

Changes for the new version:

Support for additional chroma placements in frame properties or via the cplace/cplaced arguments. Supported chroma placements are:

0 (left/mpeg2), 1 (center/mpeg1/jpeg), 2 (top_left), 3 (top), 4 (bottom_left) & 5 (bottom).

Added a new argument "fullc".
For YUV, when fullc=true the output always has full chroma (YUV444).

It should be correct as I made sure the handling of chroma placement agrees with what AVSResize does, although for some reason the AVSResize resizing methods don't produce identical results to the Avisynth resizers, and the lower the bitdepth, the greater the difference.

A = last.ConvertToYUV420().Spline36Resize(960,540)
B = A.Z_ConvertFormat(1920,1080, resample_filter="Spline36", chromaloc_op="center=>center", pixel_type="YUV420P8").ExtractY()
C = A.Spline36Resize(1920,1080).ExtractY()
Compare(B, C)

https://imgur.com/xKcNNWx.png

Anyhow... it took me enough time to come up with the bright idea of using AVSResize as a resizer for Resize8 to leave little doubt I'm mentally challenged, but once that penny dropped I was able to check Resize8's handling of chroma against AVSResize and they're in agreement.

Moving top left chroma to center placement while resizing.

A = last.ConvertToYUV420().Spline36Resize(960,540)
B = A.Z_ConvertFormat(1920,1080, resample_filter="Spline36", chromaloc_op="top_left=>center", pixel_type="YUV420P8").ExtractU()
C = A.Resize8(1920,1080, kernel="z_Spline36Resize", noring=false, CPlace="top_left", CPlaced="center").ExtractU()
Compare(B, C)

https://imgur.com/hbN8jso.png

Upscaling the chroma for YUV444 while downscaling the luma.

A = last.ConvertToYUV420().Spline36Resize(1920,1080)
B = A.Z_ConvertFormat(1280,720, resample_filter="Spline36", chromaloc_op="left=>center", pixel_type="YUV444P8")
C = A.Resize8(1280,720, kernel="z_Spline36Resize", noring=false, CPlace="left", fullc=true)
Compare(B, C)

https://imgur.com/ukJ2Pxc.png

[tormento]

the link will be in the opening post
Thank you!

What kind of transformation do you use to go from 420 to 444?

I use AIUpscale with KriegBilateral but, as far as you told, you are just applying avsresize, right?

[hello_hello]

Upscaling from sub-sampled chroma to 444 is done with the specified resizer, although I used AVSResize to resize for the examples above because there's enough difference between resizers to make it hard to check against AVSResize that Resize8 was fixing the chroma shift correctly when it was resizing with Avisynth. Even AVSResize and FMTConv don't produce the same output according to Compare().

For the record, Resize8 extracts the YUV planes (or RGB planes) and resizes them individually before combining them again, cropping the UV planes as required to correct any chroma shift, so there's no need to use a resizer capable of understanding or correcting chroma placement. It can't make a difference as the resizer doesn't see any UV planes as such.

As I was messing around doing some testing I thought I'd post the results. I took 5000 frames from a 720p video, upscaled to 1080p, and ran a speed test with AvsPmod. Resize8 doesn't slow the resizing down by much, but I found it more interesting how much faster Avisynth's native resizing and AVSResize are with multi-threading disabled, although I'm running Avisynth in Wine so maybe on Windows the results would be different.
There's two numbers next to each resizing method representing the number of seconds it took to run the test. The first is with multi-threading enabled by adding Prefetch(12) to the end of the script (12 core CPU). The second is without multi-threading enabled. The Resize8 tests were done with ringing repair enabled and disabled (the video is resized twice when noring=true and run through RGTools).

MT - Yes, No

Resize8(1920,1080, noring=true, kernel="Spline36Resize") 37, 15
Resize8(1920,1080, noring=false, kernel="Spline36Resize") 38, 7
Spline36Resize(1920,1080) 33, 6

Resize8(1920,1080, noring=true, kernel="Spline36ResizeMT") 31, 32
Resize8(1920,1080, noring=false, kernel="Spline36ResizeMT") 16, 16
Spline36ResizeMT(1920,1080) 10, 11

Resize8(1920,1080, noring=true, kernel="Spline36ResizeMT", RStr="threads=12") 16, 16
Resize8(1920,1080, noring=false, kernel="Spline36ResizeMT", RStr="threads=12") 16, 16
Spline36ResizeMT(1920,1080, threads=12) 11, 11

Resize8(1920,1080, noring=true, kernel="z_Spline36Resize") 36, 14
Resize8(1920,1080, noring=false, kernel="z_Spline36Resize") 33, 6
z_Spline36Resize(1920,1080) 32, 5

[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)

https://imgur.com/GDu00is.png

[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]

"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]

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/master/cli.html#vui-video-usability-information-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]

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.

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 (https://codeberg.org/StvG/avsresize) - "-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 (http://avisynth.nl/index.php/Descale),2 (http://avisynth.nl/index.php/ResampleMT)) 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 (http://avisynth.nl/index.php/Resize8) is vastly outdated.

[pinterf]

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

[tormento]

Just a note
As you can see, I put it as annotation for the maintainer of the Wiki :p

[Jamaika]

Are descale operators (1 (http://avisynth.nl/index.php/Descale),2 (http://avisynth.nl/index.php/ResampleMT)) 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 (http://avisynth.nl/index.php/Resize8) 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" """)

Are descale operators (1 (http://avisynth.nl/index.php/Descale),2 (http://avisynth.nl/index.php/ResampleMT)) 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 (http://avisynth.nl/index.php/Resize8) 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]

As you can see, I put it as annotation for the maintainer of the Wiki :p
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 (https://forum.doom9.org/showthread.php?p=2006746#post2006746) topic directly if someone would take care of that section.

[tormento]

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 (https://forum.doom9.org/showthread.php?p=1954534#post1954534) 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.

[tormento]

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]

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 (https://github.com/Irrational-Encoding-Wizardry/descale/releases), 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]

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. :p

[tormento]

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]

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...;)