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. |
12th August 2020, 22:00 | #121 | Link |
Registered User
Join Date: Dec 2010
Posts: 65
|
Added a few tiny fixes, and now I can run avsresize filer as a dynamic library libavsresize.so with avs+ 3.6.1-git natively on my debian box.
I checked resize and color space conversion, everything seems to be fine. Code:
how to build: g++ -Wall -Wextra -O2 -std=c++17 -fPIC -c -o avsresize.o avsresize.cpp g++ -s -shared -o libavsresize.so avsresize.o -lzimg =============================================================================== --- avsresize.orig.cpp 2020-04-23 19:48:21.000000000 +0200 +++ avsresize.cpp 2020-08-11 21:22:33.716137465 +0200 @@ -9,7 +9,22 @@ #include <regex> #include <string> #include <malloc.h> +#ifdef _WIN32 #include "avisynth.h" +#else +#include <avisynth/avisynth.h> +#define _aligned_free free +#define __int64 int64_t +/* gnu libc offers the equivalent 'aligned_alloc' BUT requested 'size' + has to be a multiple of 'alignment' - in case it isn't, I'll set + a different size, rounding up the value */ +#define _aligned_malloc(s,a) ( \ + (s%a)? \ + aligned_alloc(a,(s/a+1)*a) \ + : \ + aligned_alloc(a,s) \ + ) +#endif #include "zimg++.hpp" namespace { |
26th August 2020, 15:59 | #122 | Link |
Registered User
Join Date: Jul 2018
Posts: 447
|
avsresize_r1f - added @Losko patch, zimg v3.0.1, added support for frame properties.
|
2nd October 2020, 18:44 | #125 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff Last edited by real.finder; 2nd October 2020 at 18:56. |
|
3rd October 2020, 07:49 | #126 | Link | |
Registered User
Join Date: Jul 2018
Posts: 447
|
Quote:
avsresize_r1g - added parameter prefer_props; read and set _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries frame properties; added chromaloc_op parameters - bottom_left and bottom. For more info check the included README.md. |
|
6th October 2020, 18:27 | #127 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
8th October 2020, 08:31 | #128 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
can we have "auto" in colorspace_op input and "same" in output?
colorspace_op="auto:auto:auto:auto=>same:same:same:f" the "auto" see if there are frame properties first and if there are no frame properties for the parameter it will use presupposed value based on video informations like resolution and fps and "same" will use the input value
__________________
See My Avisynth Stuff |
9th October 2020, 10:41 | #129 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
|
|
13th October 2020, 18:57 | #130 | Link | |
Registered User
Join Date: Jul 2018
Posts: 447
|
Quote:
|
|
14th October 2020, 01:48 | #131 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
but "auto" make things easier for user
__________________
See My Avisynth Stuff |
14th October 2020, 18:39 | #132 | Link |
Registered User
Join Date: Jul 2018
Posts: 447
|
avsresize_r2 - added keyword 'same' for destination matrix, transfer, primaries, range, chromaloc_op.
When it's used the source value (argument or frame property) is used for destination too. |
15th October 2020, 03:15 | #133 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
colorspace_op="709:709:709=>709:709:709", prefer_props=true and since prefer_props=true the it will use the frame properties and ignore the input 709:709:709=> right?
__________________
See My Avisynth Stuff |
|
15th October 2020, 05:32 | #134 | Link |
Registered User
Join Date: Jul 2018
Posts: 447
|
Sorry for avsresize_r2. I was negligent.
avsresize_r3: - removed parameter prefer_props; - added keyword "auto" for source matrix, transfer, primaries, range. When it's used the corresponding input frame properties are used, if such frame properties don't exist either an error is raised or default matrix and color range are used; - added keyword "auto" for source chromaloc_op. When it's used the corresponding input frame property is used, if such frame property doesn't exist default chromaloc is used. If colorspace_op is not defined and there are frame properties, they are used for default source values. If colorspace_op is not defined and there are no frame properties or they are not supported, default values are used as before (there are default values for matrix, range and chromaloc). If colorspace_op is defined and you want to use the frame property for a source value, use "auto". If colorspace_op is defined and you use "auto" without frame property, the default value for that argument will be used if exist. If you use "auto" for argument with frame property that has value of 2 (unspec) and use anything different than "same" for destination, error will be raised. If you use "auto=>same" for matrix/transfer/primaries with frame property 2 (unspec) and you want to make colorspace conversion, error will be raised. For example: Code:
#transfer property has value of 2 #primaries 709 (1) #input yv12 z_convertformat(pixel_type="rgbp", colorspace_op="auto:auto:709=>rgb:same:470bg") # error raised #z_convertformat(pixel_type="rgbp", colorspace_op="auto:709:709=>rgb:709:470bg") # ok #z_convertformat(pixel_type="rgbp", colorspace_op="auto:709:auto=>rgb:same:470bg") # ok #z_ConvertFormat(colorspace_op="auto:auto=>same:470bg") # error #z_ConvertFormat(colorspace_op="auto:auto:auto:auto=>same:same:same:f") # ok Last edited by StvG; 15th October 2020 at 05:49. Reason: More examples. |
15th October 2020, 07:18 | #135 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
thanks! the changes seems ok, and I will test and see
__________________
See My Avisynth Stuff |
15th October 2020, 09:06 | #136 | Link |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
I was thinking it would be helpful to simplify the current list of enum values for matrix/transfer/primaries by indicating in the documentation that certain standards actually use the same matrix/transfer/primaries values.
For example:
The reason I mention it is because it's easy for someone to lose a lot of time sweating over the details of whether an old video capture is ST 170M or BT.601, only to realize after many hours of research that they're essentially the same thing. |
15th October 2020, 12:13 | #137 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
StvG, what about interlaced parameter and frame properties?
__________________
See My Avisynth Stuff |
18th October 2020, 16:59 | #139 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Just asking, but does R3 works fine for everyone? I'm converting a 1920x1080 4:2:2 10bit clip from 709 to 601 and I get a system exception (without any additional infos) on x64 while on x86 Vdub2 crash and close without any warning. The same script works with R1g.
|
18th October 2020, 20:58 | #140 | Link |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
Thanks!
One more documentation suggestion: I think the current definition of nominal_luminance could also benefit from some clarification. It says, "Nominal peak luminance in cd/m^2 when converting HDR content to RGB Linear". However, I don't think HDR conversion is the only scenario in which this parameter can be used. To the best of my understanding, what nominal_luminance really does is determine the scale of conversion between linear and non-linear transfer functions. It defines which luminance value (in cd/m^2) in a non-linear colorspace should be mapped to 1.0 in the floating point linear RGB colorspace, regardless of whether one is converting to or from linear RGB. For example, if I am converting from HLG ("std-b67") to linear RGB and want to capture the full BT.2100 HLG range (0-1000 nits) in 0.0-1.0 linear RGB, I'd set the nominal_luminance value to 1000. Does that sound right, or is my own understanding of the parameter incorrect? Thank you for bringing this great plugin to AviSynth - it's much appreciated! |
Thread Tools | Search this Thread |
Display Modes | |
|
|