z.lib resizers for AviSynth+

[Boulder]

Originally Posted by StvG

It depends. If your source is 10-bit (it will be valid for any bit depth < 16-bit):
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.

For 8- or 10-bit sources, I do the denoising part in 16 bits. Then that is fed to the downscaling part, where it's converted to linear RGBPS, downscaled and converted to YUV420P16. Then debanding without any bitdepth change, fed to the encoder (x265) as 16-bit and the internal dithering is enabled to get the final 10-bit output. So based on your answer, I think it's best that dithering is disabled wherever possible and allow it only at the encoder phase.

By the way, what is the difference between converting the format and resizing in the same z_ConvertFormat call and doing it in two different calls (resizing first, then converting to the final format)? I tested it yesterday and there seems to be a rather noticable performance drop if you use two calls.

[FranceBB]

Originally Posted by Boulder

[...] fed to the encoder (x265) as 16-bit and the internal dithering is enabled to get the final 10-bit output.

I do exactly the same.
No matter if the source is 8bit, 10bit or 12bit planar, I always bring everything to 16bit planar, filter everything out and feed the encoder with the 16bit input.

My outputs are always 10bit, so x264 will dither it down using the Sierra-2-4A algorithm, while x265 will use... something else.

Speaking of which, what will x265 use with --dither? I mean, which algorithm?
I know we've been having this conversation before but I forgot xD

[Reel.Deel]

I try to do everything in one go (if possible). Sometimes doing 2 steps can be detrimental. For example, I saw this script in another thread:

Originally Posted by ErazorTT

LWLibavVideoSource("video.uhd.rmx.mkv",cachefile="video.lwi",format="YUV420P16",decoder="hevc_qsv",prefer_hw=2) # hw

# (avsresize.dll)
z_Spline36Resize(1920,1080) # FHD

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020:st2084:2020:l=>rgb:st2084:2020:f",dither_type="none")

# Apply LUT (vscube.dll)  input full / output full  HLG
Cube("hlg-tools65.cube",fullrange=true) # max-cll 1000

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:f=>2020ncl:std-b67:2020:l",dither_type="error_diffusion")

The source is 4k and it's getting resized down to 1920x1080 YUV420 and then converted to RGB16. Here the chroma is going from 1920x1080 down to 960x540 and then scaled back up to 1080p when converted to RGB. Sure, after applying the LUT it is converted back to YUV420 and the chroma size is back again down to 960x540. Most wont even be able to tell the difference but it still does unnecessary processing. source.z_ConvertFormat(1920,1080, pixel_type="RGBP16",...) would be higher fidelity. At least that is how dither works when you resize and change format at the same time. In this scenario you can even go from UHD YUV4:2:0 down to FHD YUV4:4:4 without even resizing the chroma planes. Provided that the luma channel gets independently resized with src_left=-0.50, src_top=-0.50 to account for the chroma placement shift (top left in this case, assuming source is uhd bluray). After that, merge the luma with the original chroma planes, convert to RGB and proceed .

Edit: re-reading the last few post, seems my comment is somewhat not related to the discussion. But, I'll leave it here since it's still relevant to the thread. I should be asleep lol.

[Boulder]

Originally Posted by FranceBB

I do exactly the same.
No matter if the source is 8bit, 10bit or 12bit planar, I always bring everything to 16bit planar, filter everything out and feed the encoder with the 16bit input.

My outputs are always 10bit, so x264 will dither it down using the Sierra-2-4A algorithm, while x265 will use... something else.

Speaking of which, what will x265 use with --dither? I mean, which algorithm?
I know we've been having this conversation before but I forgot xD

From api.cpp: "The dithering algorithm is based on Sierra-2-4A error diffusion." It's probably identical to x264, why re-invent the wheel since they ported other stuff as well.

[StvG]

Originally Posted by Boulder

By the way, what is the difference between converting the format and resizing in the same z_ConvertFormat call and doing it in two different calls (resizing first, then converting to the final format)? I tested it yesterday and there seems to be a rather noticable performance drop if you use two calls.

If you mean something like this:

z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left")
z_BicubicResize(x, y)
z_ConvertFormat(pixel_type="yuv420p16", colorspace_op="rgb:linear:709:f=>709:709:709:l", chromaloc_op="left=>left")

z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left")
z_ConvertFormat(x, y, pixel_type="yuv420p16", colorspace_op="rgb:linear:709:f=>709:709:709:l", chromaloc_op="left=>left")

These variants give identical results. The first one have some overhead that could have some penalty for the final speed. My quick test shows ~7% difference. If frame properties are involved I would say there is no speed difference.

[StvG]

avsresize_r13 (pass: f0MNKlTxVxl5):
- zimg@dd4c4df;
- use_props= -1: If frame properties are supported - if every option of colorspace_op and chromaloc_op (for src/dst colorspace with subsampling w/h > 0) are specified and different than "auto", 0, otherwise 1.

[FranceBB]

Originally Posted by StvG

ffms2_6ad7738 (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.

Thanks, works perfectly on Windows 11 x64 and Windows Server 2019 x64.

FFMpegSource2("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\test_PCM_DolbyE_PCM_PCM.mxf", atrack=-1)

propClearAll()

#From 4:2:0 16bit planar Narrow Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="709:709:709:limited=>rgb:709:709:full", dither_type="error_diffusion")

#From BT709 SDR to BT2020 HDR HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\5a_BT709_HLG_UPCONVERT_DISPLAY_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)

#From RGB 16bit planar Full Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

to deliver a cool nice 75% ref white HLG output.



Cheers,
Frank

[Boulder]

Using props=4 causes an access violation on my system. Tested with this:

z_ConvertFormat(pixel_type="RGBPS", chromaloc_op="auto=>same", colorspace_op="auto:auto:auto:auto=>rgb:linear:same:full", approximate_gamma=true, cpu_type="AVX2", use_props=3)
z_ConvertFormat(pixel_type="YUV420P16", chromaloc_op="auto=>same", resample_filter="Bicubic", resample_filter_uv="Bicubic", filter_param_a=0, filter_param_b=0.6, width=960, height=720, cpu_type="AVX2", dither_type="none", approximate_gamma=true, use_props=4)

[StvG]

avsresize_r14 (pass: QOvyNpMf5TyF) - fixed regression (r12) when reading frame properties (use_props=3/4).

[Boulder]

Originally Posted by StvG

avsresize_r14 (pass: QOvyNpMf5TyF) - fixed regression (r12) when reading frame properties (use_props=3/4).

Still the same problem with this one.

[StvG]

Originally Posted by Boulder

Still the same problem with this one.

Download again the r14. You will see error that chromaloc_op (colospace_op too) must be not specified when use_props=4.

[Boulder]

Originally Posted by StvG

Download again the r14. You will see error that chromaloc_op (colospace_op too) must be not specified when use_props=4.

Thanks, works now

[Stephen R. Savage]

Released r2:

• Update to z.lib 3.0
• Enable 64-byte alignment
• Support real Spline64Resize
• Support alpha-aware resizing
• Implement multi-threading

[kedautinh12]

Hmm, 2 version?

[FranceBB]

What do you mean by "real" Spline64Resize?

[Reel.Deel]

Originally Posted by FranceBB

What do you mean by "real" Spline64Resize?

Up until 2 years ago or so, Spline64Resize was just an alias for Spline32Resize. z.lib added the spline64 filter in v2.9.3.

[tormento]

Originally Posted by kedautinh12

Hmm, 2 version?

First number major buiid, second number minor release?

[Reel.Deel]

Originally Posted by tormento

First number major buiid, second number minor release?

Stephen R. Savage is the original author of avsresize (and z.lib). He released the first version of avsresize (r1) back in 2016 and then some periodic updates. The last update was r1d in March of 2018. StvG then continued updating the plugin ever since, up to r14 now.

[kedautinh12]

Originally Posted by Reel.Deel

Stephen R. Savage is the original author of avsresize (and z.lib). He released the first version of avsresize (r1) back in 2016 and then some periodic updates. The last update was r1d in March of 2018. StvG then continued updating the plugin ever since, up to r14 now.

And r2 is continued update of r14??

[TomArrow]

I've a quick question about z_ConvertFormat. Does it write any usually not visible metadata to the clip that a software like ffmpeg can use? A friend reported that in conjunction with ffmpeg, using this filter (just doing a straight conversion to the same color space) can result in changes to the output file in terms of metadata, transfer characteristic specifically.

Of course this doesn't have to be a bad thing per se, but it would be good to know.