z.lib resizers for AviSynth+

[tormento]

Originally Posted by FranceBB

Link (avsresize r25 + Spline64 SSE2 bugfix x64 MSVC)

Getting

Script error: There is no function named 'z_ConvertFormat'.

for

z_ConvertFormat(pixel_type="YUV420P10", resample_filter_uv="Spline64", dither_type="error_diffusion")

[FranceBB]

You're missing the Microsoft C++ Redistributable.
You can install them one by one from the Microsoft website or get the unofficial AIO (all in one) package from here https://github.com/abbodi1406/vcredist/releases/

[tormento]

Originally Posted by FranceBB

You're missing the Microsoft C++ Redistributable.

You linked the debug dlls not the standard ones.

[StvG]

avsresize_r25a:
- zimg 2aed91a


@hello_hello, you can also try this build if the other r25a build still give you different output in Wine.

[Jamaika]

plugins/libzimg/zimg++.hpp:333:8: warning: extra tokens at end of '#endif' directive [-Wendif-labels]
333 | #endif ZIMG_GRAPHENGINE_API // ZIMG_GRAPHENGINE_API
| ^~~~~~~~~~~~~~~~~~~~
plugins/avsresize.cpp:1067:27: error: 'ZIMG_TRANSFER_PROPHOTORGB' was not declared in this scope
1067 | { "prophoto", ZIMG_TRANSFER_PROPHOTORGB},
| ^~~~~~~~~~~~~~~~~~~~~~~~~
plugins/avsresize.cpp:1085:25: error: 'ZIMG_PRIMARIES_PROPHOTO' was not declared in this scope
1085 | { "prophoto", ZIMG_PRIMARIES_PROPHOTO },
| ^~~~~~~~~~~~~~~~~~~~~~~
plugins/avsresize.cpp: In function 'AVSValue {anonymous}::create_resize(AVSValue, void*, IScriptEnvironment*)':
plugins/avsresize.cpp:1472:29: error: 'struct zimgxx::zfilter_graph_builder_params' has no member named 'scene_referred'
1472 | params.graph_params.scene_referred = args[22].AsBool(false);
| ^~~~~~~~~~~~~~

[StvG]

Originally Posted by Jamaika

plugins/libzimg/zimg++.hpp:333:8: warning: extra tokens at end of '#endif' directive [-Wendif-labels]
333 | #endif ZIMG_GRAPHENGINE_API // ZIMG_GRAPHENGINE_API
| ^~~~~~~~~~~~~~~~~~~~
plugins/avsresize.cpp:1067:27: error: 'ZIMG_TRANSFER_PROPHOTORGB' was not declared in this scope
1067 | { "prophoto", ZIMG_TRANSFER_PROPHOTORGB},
| ^~~~~~~~~~~~~~~~~~~~~~~~~
plugins/avsresize.cpp:1085:25: error: 'ZIMG_PRIMARIES_PROPHOTO' was not declared in this scope
1085 | { "prophoto", ZIMG_PRIMARIES_PROPHOTO },
| ^~~~~~~~~~~~~~~~~~~~~~~
plugins/avsresize.cpp: In function 'AVSValue {anonymous}::create_resize(AVSValue, void*, IScriptEnvironment*)':
plugins/avsresize.cpp:1472:29: error: 'struct zimgxx::zfilter_graph_builder_params' has no member named 'scene_referred'
1472 | params.graph_params.scene_referred = args[22].AsBool(false);
| ^~~~~~~~~~~~~~

There is zimg.patch in the release archive.

[FranceBB]

Originally Posted by StvG

avsresize_r25a:
- zimg 2aed91a

Thank you for the official build!
I can confirm that the issue is solved.

[hello_hello]

Originally Posted by StvG

avsresize_r25a:
- zimg 2aed91a


@hello_hello, you can also try this build if the other r25a build still give you different output in Wine.

Thanks. I tried them both but the result is still the same. I need to use the cpu_type argument for the RGB to YUV part of the conversion to get the expected result when approximate_gamma is true.

z_ConvertFormat(colorspace_op="rgb:linear:xyz:full=>709:709:709:limited", pixel_type=YUV420P16, cpu_type="avx512f")

It doesn't seem to be a Wine issue as such though, as the behavior is the same for the native Linux flavor of VapourSynth and it's resizers. Possibly something to do with my AMD 7900X CPU??

Cheers.

[FranceBB]

Hey hello_hello, I'm trying to reproduce this on Windows Server 2019 Standard x64 running on an Intel Xeon Gold 6238R which supports AVX512 natively.
Unfortunately (or should I say "fortunately" in this case) I can't reproduce as the C++, AVX, AVX2 and AVX512 conversions all produce identical results.

source=ColorBars(500, 960, pixel_type="YUV444P16").Crop(0, 0, -0, -940).ConvertYUVtoXYZ().ConverttoPlanarRGB()

z_ConvertFormat(source, colorspace_op="rgb:linear:xyz:full=>709:709:709:limited", pixel_type="YUV420P16", cpu_type="none")
Subtitle("C++")
cpp=last

z_ConvertFormat(source, colorspace_op="rgb:linear:xyz:full=>709:709:709:limited", pixel_type="YUV420P16", cpu_type="avx")
Subtitle("AVX")
avx=last

z_ConvertFormat(source, colorspace_op="rgb:linear:xyz:full=>709:709:709:limited", pixel_type="YUV420P16", cpu_type="avx2")
Subtitle("AVX2")
avx2=last

z_ConvertFormat(source, colorspace_op="rgb:linear:xyz:full=>709:709:709:limited", pixel_type="YUV420P16", cpu_type="avx512f")
Subtitle("AVX512")
avx512=last

StackVertical(cpp, avx, avx2, avx512)

In other words, it doesn't seem to be an issue within avsresize, at least not in the Avisynth version running on bare metal hardware.

[hello_hello]

Originally Posted by FranceBB

Hey hello_hello, I'm trying to reproduce this on Windows Server 2019 Standard x64 running on an Intel Xeon Gold 6238R which supports AVX512 natively.
Unfortunately (or should I say "fortunately" in this case) I can't reproduce as the C++, AVX, AVX2 and AVX512 conversions all produce identical results.

If it's a CPU related issue it looks like it's an AMD one. Or an AMD/Linux one. The same problem exists for both AVSResize running in Wine and the native Linux VapourSynth resizers.

If Avisynth and/or VapourSynth are running on Windows 11 in VirtualBox there's no issue with approximate_gamma=true. I don't know much about emulation but apparently VirtualBox pretends Windows is running on an Intel chipset, although Device Manager correctly identifies the AMD Ryzen 9 7900x CPU. I haven't tried adding cpu_type to z_ConvertFormat running on Windows though as it's not needed and I rarely run anything in Windows/VirtualBox anyway.

As a side note I was reading a review regarding the newer AMD CPUs and SMT (hyperthreading). It mentioned disabling SMT can sometimes improve performance a little for specific workloads, so I thought I'd try it. The Avisynth script I used for testing included some fairly slow denoising and I was encoding with x264, all running in Wine. I wasn't expecting much of a change, but disabling SMT increased encoding speed by roughly 30% (~25 fps to ~33fps), CPU usage increased from 50-60% to 90%, and the CPU also ran about 7 degrees cooler with SMT disabled. I ran the test twice for each, obviously rebooting in between to disable/enable SMT. Maybe that's a Wine or Linux issue too. I haven't run the test again with the native Linux Vapoursynth and x264 to see if the result is similar, but I probably will sometime soon, just out of curiosity.

[StvG]

@hello_hello, you can report to zimg.

[Emulgator]

Maybe just one codepath, and maybe compiler dependent, so dependent on build version ?
IIRC qyot27 found such dependency on another occasion.

[takla]

Originally Posted by hello_hello

As a side note I was reading a review regarding the newer AMD CPUs and SMT (hyperthreading). It mentioned disabling SMT can sometimes improve performance a little for specific workloads, so I thought I'd try it. The Avisynth script I used for testing included some fairly slow denoising and I was encoding with x264, all running in Wine. I wasn't expecting much of a change, but disabling SMT increased encoding speed by roughly 30% (~25 fps to ~33fps), CPU usage increased from 50-60% to 90%, and the CPU also ran about 7 degrees cooler with SMT disabled. I ran the test twice for each, obviously rebooting in between to disable/enable SMT. Maybe that's a Wine or Linux issue too. I haven't run the test again with the native Linux Vapoursynth and x264 to see if the result is similar, but I probably will sometime soon, just out of curiosity.

If your CPU wasn't thermal or power throttling SMT=Off shouldn't get more fps.

[hello_hello]

Originally Posted by StvG

@hello_hello, you can report to zimg.

Done. https://github.com/sekrit-twc/zimg/issues/211

[hello_hello]

According to the response to my question here, there's no need to use an intermediate RGB clip when converting color with AVSResize (at least for standard matrix/primaries conversions). Therefore converting from rec.2020 to rec.709 this way isn't necessary:

z_ConvertFormat(colorspace_op="2020:2020:2020:limited=>rgb:linear:xyz:full", pixel_type="RGBP16")
z_ConvertFormat(colorspace_op="rgb:linear:xyz:full=>709:709:709:limited", pixel_type="YUV420P16")

And it's okay to do it like this:

z_ConvertFormat(colorspace_op="2020:2020:2020=>709:709:709", pixel_type="YUV420P16")

Is that correct?? I feel like it shouldn't be after using the first method for so long.

[StvG]

This way is also worse if the intermediate RGB is 16-bit and not float. If the intermediate RGB is float (RGBPS), then both methods has identical output - your choice which to use (I always use the one line method).

[hello_hello]

Thanks!