Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
25th October 2024, 23:27 | #361 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,823
|
Getting
Script error: There is no function named 'z_ConvertFormat'. for z_ConvertFormat(pixel_type="YUV420P10", resample_filter_uv="Spline64", dither_type="error_diffusion")
__________________
@turment on Telegram |
26th October 2024, 00:07 | #362 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,118
|
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/ |
27th October 2024, 15:14 | #364 | Link |
Registered User
Join Date: Jul 2018
Posts: 503
|
avsresize_r25a:
- zimg 2aed91a @hello_hello, you can also try this build if the other r25a build still give you different output in Wine. |
27th October 2024, 16:07 | #365 | Link |
Registered User
Join Date: Jul 2015
Posts: 816
|
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); | ^~~~~~~~~~~~~~ |
27th October 2024, 17:25 | #366 | Link | |
Registered User
Join Date: Jul 2018
Posts: 503
|
Quote:
|
|
28th October 2024, 15:59 | #367 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,118
|
Quote:
I can confirm that the issue is solved. |
|
2nd November 2024, 09:51 | #368 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,938
|
Quote:
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. Last edited by hello_hello; 3rd November 2024 at 19:27. |
|
4th November 2024, 14:36 | #369 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,118
|
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. Quote:
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. |
|
4th November 2024, 17:22 | #370 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,938
|
Quote:
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. |
|
4th November 2024, 22:43 | #372 | Link |
Big Bit Savings Now !
Join Date: Feb 2007
Location: close to the wall
Posts: 1,751
|
Maybe just one codepath, and maybe compiler dependent, so dependent on build version ?
IIRC qyot27 found such dependency on another occasion.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain) "Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..." |
5th November 2024, 23:41 | #373 | Link | |
Registered User
Join Date: May 2018
Posts: 214
|
Quote:
|
|
6th November 2024, 17:51 | #374 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,938
|
|
17th November 2024, 21:09 | #375 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,938
|
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. |
19th November 2024, 13:04 | #376 | Link |
Registered User
Join Date: Jul 2018
Posts: 503
|
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).
|
8th December 2024, 05:48 | #378 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,938
|
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) |
8th December 2024, 12:57 | #379 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,209
|
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. |
8th December 2024, 15:26 | #380 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,938
|
Quote:
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): Code:
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) Code:
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) |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|