z.lib resizers for AviSynth+

[FranceBB]

It was working, I updated Avisynth on my production server to 3.7.0, now it's throwing this error:



Why?

Edit: Tested on Avisynth 3.7.1 Beta 6, same result, same error.

Edit 2: I'm temporarily using ConverttoYUV422(matrix="PC2020") as a workaround. Technically, it should leave the levels untouched from the Studio RGB...

[StvG]

avsresize_r7 (pass: hIaK6dSB69uK): fixed frame properties reading.

[kedautinh12]

Thanks

[FranceBB]

I updated but now I get: RGB Color family cannot have YUV matrix coefficients



if I remove the last conversion and leave it as RGB it works:




Version: Avisynth 3.7.1 Beta 6 x64
OS: Windows 10 Enterprise x64

[StvG]

Check the last line from the first screenshot: pixel_type=rgb but destination matrix 2020 (yuv).

[Dogway]

Originally Posted by StvG

Check the last line from the first screenshot: pixel_type=rgb but destination matrix 2020 (yuv).

This is one of the many reasons why I started Transforms Pack, no-sense limitations and restrictions in avsresize. YUV 2020 can be converted to RGB 2020, it's even a standard conversion (CL and NCL).

[FranceBB]

Originally Posted by StvG

Check the last line from the first screenshot: pixel_type=rgb but destination matrix 2020 (yuv).

Daaaamn, this is why I shouldn't test things at 6.42 in the morning before having my breakfast...

Version 7 works like a charm now, thanks!
I'm rolling it on all my production server.
Now I've got a few MJPEG2000 12bit PQ masterfiles to encode in HLG eheheheh

[StvG]

avsresize_r8 (pass: Zz299Qct9i4P): changed MT mode to MT_MULTI_INSTANCE.

[kedautinh12]

Thanks

[Audionut]

Hi, I'm seeing an issues with levels that begun in r7.

This is what the frames should look like.

And this is the output of ComparisonGen.avsi after updating to r7.

Still same issue in r8.

[StvG]

avsresize_r9 (pass: au7cG6ztmrW4): do not use the same color range for the destination when frame property available and source/destination color family is different;
- set the correct color range frame property value for destination YUV 32-bit.

[kedautinh12]

thanks

[FranceBB]

Thanks for the update!
Time to test and then replace it in our production servers.

[Boulder]

Out of interest, should the value for nominal_luminance be adjusted based on source metadata (=maximum content light level) in case of HDR?

[StvG]

Originally Posted by Boulder

Out of interest, should the value for nominal_luminance be adjusted based on source metadata (=maximum content light level) in case of HDR?

Check the first two comments from this issue.
Ideally you want to set it to the frame peak luminance.

[Boulder]

Originally Posted by StvG

Check the first two comments from this issue.
Ideally you want to set it to the frame peak luminance.

Thanks, looks like it's not worth it and best just to leave it at the default if unknown. There probably is no tool to find the value by scanning the whole video.

[Dogway]

@Boulder: runtime yplanemax maybe? Maybe do a first pass analysis.

[FranceBB]

Originally Posted by Boulder

Thanks, looks like it's not worth it and best just to leave it at the default if unknown. There probably is no tool to find the value by scanning the whole video.

PQStat (written by William Swartzendruber, who is also a user of this forum) can do it for you: it's free, open source and written in Rust.
It will scan the whole video and report the right values in nits.
Please note, though, that if you're not scanning a lossless masterfile made of 12bit tiff but rather a consumer relatively low bitrate HEVC .ts file from a broadcasting channel or a consumer UHD-BD HEVC .m2ts file (which also has a low bitrate compared to the master), there are gonna be compression overshooting (i.e outliers) which might affect the overall detection.
(Just as a reference, a ProRes 4K mezzanine file, which is NOT lossless, has 1 Gbit/s as bitrate and it's still losing quality and potentially creating overshooting, so those ARE DEFINITELY GONNA HAPPEN in a "low bitrate" H.265 HEVC file...)

[Boulder]

Originally Posted by FranceBB

PQStat (written by William Swartzendruber, who is also a user of this forum) can do it for you: it's free, open source and written in Rust.
It will scan the whole video and report the right values in nits.
Please note, though, that if you're not scanning a lossless masterfile made of 12bit tiff but rather a consumer relatively low bitrate HEVC .ts file from a broadcasting channel or a consumer UHD-BD HEVC .m2ts file (which also has a low bitrate compared to the master), there are gonna be compression overshooting (i.e outliers) which might affect the overall detection.
(Just as a reference, a ProRes 4K mezzanine file, which is NOT lossless, has 1 Gbit/s as bitrate and it's still losing quality and potentially creating overshooting, so those ARE DEFINITELY GONNA HAPPEN in a "low bitrate" H.265 HEVC file...)

Thanks, I'll check that one out.

Wouldn't it actually be better to use the value, overshooting or not, since it's from the source that the decoder gets anyway?

[FranceBB]

Originally Posted by Boulder

Wouldn't it actually be better to use the value, overshooting or not, since it's from the source that the decoder gets anyway?

Well no.
Simply put: whenever you have a file and it has a waveform and it has a certain set of values and you re-encode it with some kind of compression, those values might not be respected.
What happens is this kind of overshooting, but here's the thing: the overshoot is an outlier.
Simply put: let's suppose that you're looking for the peak brightness in nits in a PQ file and the official metadata say it's 2500 nits. You analyze the file and you find out it's actually 2842 nits. At this point, you set the conversion to respect that and everything looks dark, way darker than it should have been. Why? Easy: the 2842 pixel was indeed the peak, but it was an outlier, which means that although the average was like closer to the right value, every now and then there are few overshoots occurred due to the compression and those will be much higher than the real value. Of course, if you take into account a simple average, what you're gonna get is a skewed result as the outliers are gonna affect the final value of the average brightness, so what you need is to avoid to take those outliers into account, however it would be hard to write a logic around that 'cause you would have to decide how far away a pixel has to go to be considered an outlier, which can be tough. Luckily for us, the standard deviation comes in rescue:



which tells us how much a set of values is disperse/various.
Anyway, we're digressing.
The point is that if you do end up using PQStat or similar tools on compressed files, you're gonna have to take the results with a pinch of salt, so always remember to look at the waveform and to trust your eyes as well.