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!

[hello_hello]

StvG,

I know I asked about 32 bit float handling a while ago, but I'm still not 100% sure how to correctly convert to float and back.

For an 8 bit limited range clip, the frame property becomes full range if I do this:

ConvertBits(32)\
.z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")\
.ConvertBits(8)

ConvertBits can change the frame property back to limited range though, and the result is exactly the same:

ConvertBits(32)\
.z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")\
.ConvertBits(8, fulls=false, fulld=false)

However as you previously said zimg assumes 32-bit float is full range, I'm wondering if I should do it like this. According to Compare() the output isn't the same, but in my head at least, it seems to be the technically correct method. Would that assumption be correct?

Cheers.

ConvertBits(32, fulls=false, fulld=true)\
.z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")\
.ConvertBits(8, fulls=true, fulld=false)

[DTL]

If all used equations are not dependent on the range mapping - the frame properties range mapping hints do nothing in float samples format processing. So if the result is the same - you can pass any range mapping to float processing. But you need to check the before and after range mapping to be equal. Some plugins may depend on the black (and all other levels position/mapping).

So if you send narrow-float (shifted black) to convert and use narrow-float to narrow-integer convert back it will work. Many plugins may assume float always uses black mapped to 0.0f and nominal white mapped to 1.0f. (Also zero UV to 0.0f). But some may use any other like 0..max_int mapped to 0.0f..max_int_as_float.

"For an 8 bit limited range clip, the frame property becomes full range if I do this:

ConvertBits(32)\
.z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")\
.ConvertBits(8)"

You use 3 filters in a chain - first you can start to look where your range mapping property switched from narrow/limited to full. Maybe after the first ConvertBits(32) filter.

[hello_hello]

Originally Posted by DTL

You use 3 filters in a chain - first you can start to look where your range mapping property switched from narrow/limited to full. Maybe after the first ConvertBits(32) filter.

It's definitely z_ConvertFormat writing "full" to frame properties. Avisynth's ConvertBits is happy for float to be either full or limited range.
I hunted around some more and I'm pretty sure for my example above, converting limited range integer to full range float before z_ConvertFormat is the correct way to do it, as zimg always assumes float is full range (either that or let zimg do the conversion).

https://github.com/sekrit-twc/zimg/issues/134
https://forum.doom9.org/showthread.p...24#post1927024

I think the same applies to FMTConv. The help file doesn't specifically say float is full range, but it does say the fulls and fulld arguments have no meaning for float data.

These produce the same result (8 bit limited range input):

A = ConvertBits(32, fulls=false, fulld=true)\
.z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")\
.ConvertBits(8, fulls=true, fulld=false)

B = z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg", bit_depth=32)\
.ConvertBits(8, fulls=true, fulld=false)

Compare(A,B)

The output here is very close, but not exactly the same. Maybe a rounding difference when converted back to 8 bit?

A = ConvertBits(32, fulls=false, fulld=true)\
.z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg")\
.ConvertBits(8, fulls=true, fulld=false)

B = z_ConvertFormat(colorspace_op="170m:601:170m=>470bg:601:470bg", bit_depth=32)\
.z_ConvertFormat(bit_depth=8)

Compare(A,B)