z.lib resizers for AviSynth+

[tormento]

Originally Posted by StvG

If anyone downloaded avsresize_r6, download it again (fixed regression: approximate_gamma (r5 is ok)).

Unable to download.

Il server non è stato in grado di completare la tua richiesta.

Se ciò si verifca nuovamente, invia i seguenti dettagli tecnici all'amministratore del server.

Ulteriori dettagli sono disponibili nel log del server.

Dettagli tecnici
Indirizzo remoto: 84.221.196.138
ID richiesta: WXU1VipibSaEEFhe3TpD

Edit: now it works.

[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?