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 2021, 22:01 | #182 | Link |
Registered User
Join Date: Jul 2018
Posts: 447
|
avsresize_r10 (pass: 7fgQwBn9zreN): do not set matrix frame property when source matrix frame property is undef and color family is not changed;
- zimg@bf73dbe. |
13th August 2021, 12:53 | #183 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Thanks for the new build and most importantly thanks for making the plugin in the first place.
I wouldn't have been able to encode some Studio RGB 12bit PQ masterfiles by reliably applying my non-public LUTs without messing up with the levels without this one. You saved me in a certain sense. Last edited by FranceBB; 13th August 2021 at 13:00. |
18th November 2021, 01:35 | #184 | Link |
Registered User
Join Date: Jul 2018
Posts: 447
|
avsresize_r11 (pass: 2bzWmpDAZbk8): added parameter use_props (whether to read and set frame properties);
- zimg 3.0.3. |
18th November 2021, 06:26 | #185 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Thank you for the new version
Would it be possible to add an option to use properties from a different clip than the source for the colorspace_op (and maybe chromaloc_op)? My use case is a simple "original clip" -> "convert to linear RGB and downscale" -> "convert back to original colorspace".
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
18th November 2021, 08:27 | #186 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
use case is a simple "original clip" -> "convert to linear RGB and downscale" -> "convert back to original colorspace".'
If you use typical chroma subsampled input and output to this 'simple' - it is really very complex. Because chroma subsampling introduce distortions that can not be completely fixed in 'linear processing'. To better fix the both luma and chroma distortions of nonlinear systems the 'non-linear' that is content-adaptive processing required. Also to build the better processing the standartization of chroma antialiasing filter in display device required (or standartization of other display subsampled-decompressor if it finally going out of 'linear processing' at all). So the playing 'simple' games around chroma-loc and 'going to linear' that is not perfectly possible from chroma-subsampled ugly old lossy compression still not allow to get best possible results. The distortions raises with saturation of colours and sharpness of colour transients. So if the developer of z.lib reads here - may be try to add some content-adaptive non-linear resizer methods too to this library of functions. |
18th November 2021, 22:55 | #187 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
|
|
19th November 2021, 07:37 | #188 | Link | ||
Registered User
Join Date: Jul 2018
Posts: 447
|
Quote:
Quote:
When every option of colorspace_op is specified (matrix, transfer, primaries, range) and different than "auto", use_props=false can be used for higher fps. But now I'm seeing that use_props=false doesn't pass frame properties (removes the frame properties). Another version is needed to fix that. |
||
19th November 2021, 08:34 | #189 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
In that phase, the source clip is in RGB. It's basically YUV420P16 (BT709 or BT2020) -> linear RGB, downscale -> YUV420P16 (original format) -> feed to x265 for encoding.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
21st November 2021, 11:06 | #192 | Link |
Registered User
Join Date: Jul 2018
Posts: 447
|
avsresize_r12 (pass: oPrkZ7IH132A): changed use_props type from bool to int.
Code:
use_props (default -1) - whether to read and set frame properties: -1: If frame properties are supported - if every option of colorspace_op and chromaloc_op are specified and different than "auto", 0, otherwise 1. If frame properties are not supported - 0. 0: If frame properties are supported - only set frame properties. 1: Read and set frame properties. 2: Save properties of the source clip as frame properties: z_ChromaLocation, z_ColorRange, z_Matrix, z_Transfer, z_Primaries. Every option of colorspace_op and chromaloc_op must be specified and different than "auto". 3: Save properties of the source clip as frame properties: z_ChromaLocation, z_ColorRange, z_Matrix, z_Transfer, z_Primaries. Frame properties _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries must exist. Frame properties _Matrix, _Transfer, _Primaries must have values different than 2 (unspec). 4: Use z_xxx frame properties as target values. z_xxx frame propeties are removed after the colorspace conversion. use_props=2 is faster than use_props=3 Example use_props=2 and use_props=4 Code:
z_ConvertFormat(pixel_type="rgbp", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left", use_props=2) z_ConvertFormat(pixel_type="yv12", use_props=4) # convert rgb to yuv with the yuv initial properties Code:
z_ConvertFormat(pixel_type="rgbp", colorspace_op="709:709=>rgb:linear", use_props=3) z_ConvertFormat(pixel_type="yv12", use_props=4) # convert rgb to yuv with the yuv initial properties |
22nd November 2021, 10:29 | #193 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Well, looks like it works!
Quote:
Last edited by FranceBB; 22nd November 2021 at 10:32. |
|
7th January 2022, 01:12 | #194 | Link |
Registered User
Join Date: Mar 2003
Location: Germany
Posts: 215
|
ditehring methods returning different averages
I would like to report that the dithering methods ordered, random, error_diffusion of the z_ConvertFormat function return slightly different averaged values.
So when having big single color patches like in test patterns, the averages over all pixels are slightly different for the methods. I admit that the difference is small (9 in the full range of 0-32768 which equals 0.07 for the range of 0-255). But still for 16 bit clips this would be measurable. I put all the screenshots in the folder and also the saved pictures from the clip, which can be opened an checked: https://drive.google.com/drive/folde...pn?usp=sharing If this is expected, then which method is nearer to the true average? |
7th January 2022, 03:00 | #195 | Link | |
Registered User
Join Date: Jan 2018
Posts: 2,153
|
Quote:
|
|
8th January 2022, 01:12 | #196 | Link | |
Registered User
Join Date: Jul 2018
Posts: 447
|
Quote:
For info: - colorspace_op conversions are done in float and then dither to the target bit depth (if different than float); - resize operations are done in 16-bit (if source/target are not float) and then dither to the target bit depth (if target lower than source and lower than 16/32-bit). |
|
25th January 2022, 06:08 | #199 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
25th January 2022, 23:31 | #200 | Link | |
Registered User
Join Date: Jul 2018
Posts: 447
|
Quote:
a) if denoise in source bit depth (10-bit), downscale w/o bit depth change (10-bit->16-bit->10-bit - how internally avsresize will scale), deband w/o bit depth change (assume f3kdb: 10->16-bit->10-bit - how internally f3kdb will deband) b) convert to 16-bit, denoise, downscale, deband, convert to source bit depth (10-bit) For a) it's better to apply dither after the downscaling. For b) 16-bit->10-bit is done only once at the end - dither. If the speed penalty of b) isn't the bottleneck, it should be always the preferred option imo. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|