z.lib resizers for AviSynth+

[StvG]

avsresize_r22 (pass: m6UEtJm68sPV):
- interlaced now works with use_props=1 too.
If interlaced is not specified, frame property "_FieldBased" is read to enable/disable the interlaced mode.
If interlaced is specified, "_FieldBased" doesn't have effect.
- zimg v3.0.5.

[real.finder]

Originally Posted by StvG

avsresize_r22 (pass: m6UEtJm68sPV):
- interlaced now works with use_props=1 too.
If interlaced is not specified, frame property "_FieldBased" is read to enable/disable the interlaced mode.
If interlaced is specified, "_FieldBased" doesn't have effect.
- zimg v3.0.5.

thank you, I will test it as soon as possible

edit: everything seems ok, what about chroma subsampling parameter? https://forum.doom9.org/showthread.p...50#post1989150

[StvG]

Originally Posted by real.finder

thank you, I will test it as soon as possible

edit: everything seems ok, what about chroma subsampling parameter? https://forum.doom9.org/showthread.p...50#post1989150

What's the difference between z_ConvertFormat(pixel_type="yuv444p16") and z_ConvertFormat(chroma_subsampling="444") (assuming YUV420P16 input)?

[real.finder]

Originally Posted by StvG

What's the difference between z_ConvertFormat(pixel_type="yuv444p16") and z_ConvertFormat(chroma_subsampling="444") (assuming YUV420P16 input)?

with YUV420P16 case both are same but with yv12 (8bit YUV420) z_ConvertFormat(pixel_type="yuv444p16") will convert it from 8 bit to 16 bit and 4:4:4 while z_ConvertFormat(chroma_subsampling="444") will only convert it to 4:4:4 (it will be yv24)

edit: maybe it also worth adding bit_bepth parameter too

and both chroma_subsampling and bit_bepth will be ignored when pixel_type is used

[StvG]

Originally Posted by real.finder

with YUV420P16 case both are same but with yv12 (8bit YUV420) z_ConvertFormat(pixel_type="yuv444p16") will convert it from 8 bit to 16 bit and 4:4:4 while z_ConvertFormat(chroma_subsampling="444") will only convert it to 4:4:4 (it will be yv24)

edit: maybe it also worth adding bit_bepth parameter too

and both chroma_subsampling and bit_bepth will be ignored when pixel_type is used

z_ConvertFormat(pixel_type="yuv444p" + (ComponentSize() == 4 ? "s" : String(BitsPerComponent())))

Is the above code too complicated?

Don't get me wrong. There are already a lot of parameters that making the usage a bit complicated at first look. Adding more parameters with actions that are already covered is unnecessary further complication imo.

[real.finder]

if the problem that it got lot of parameters, then can we got pixel_type to accept things like "444" (or "yuv444*") or "Y" (without any number or "Y*") and same with bitbepth (like *P16)

[StvG]

avsresize_r23 (pass: m6UEtJm68sPV):
- Added parameter bit_depth: output bit depth. It doesn't have effect if pixel_type is defined;
- Added parameter chroma_subsampling: output chroma subsampling. It doesn't have effect if pixel_type is defined;
- zimg v3.0.5.

[real.finder]

Originally Posted by StvG

avsresize_r23 (pass: m6UEtJm68sPV):
- Added parameter bit_depth: output bit depth. It doesn't effect if pixel_type is defined;
- Added parameter chroma_subsampling: output chroma subsampling. It doesn't effect if pixel_type is defined;
- zimg v3.0.5.

thanks! both work fine

[FranceBB]

Originally Posted by StvG

- Added parameter bit_depth: output bit depth. It doesn't effect if pixel_type is defined;
- Added parameter chroma_subsampling: output chroma subsampling. It doesn't effect if pixel_type is defined;
- zimg v3.0.5.

So, as long as I specify the pixel_type, everything stays the same as in the last version if I don't specify the two new parameters, right?

[StvG]

Originally Posted by FranceBB

So, as long as I specify the pixel_type, everything stays the same as in the last version if I don't specify the two new parameters, right?

Yes, if you specify pixel_type the two new parameters are ignored even if they are specified too.

[FranceBB]

Perfect, so it won't break any of my supply chains.

Well, I'm suffering from insomnia due to the heatwave (I'm currently in Milan, Italy and not in the UK unfortunately) and the fan is just blowing hot air on me, which is useless...
So... I might just get up, take a shower, have breakfast, go to the office (where I actually have AC) and update all my servers xD

[joearmstrong]

I'm not sure if I'm using chromaloc_op correctly. I haven't used it so far.

I want to convert HDR PQ to SDR:
Example 1:
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020ncl:st2084:2020:limited=>rgb:st2084:2020:full", chromaloc_op="top_left=>top_left", dither_type="none")
Cube("D:\5-NBCU_PQ2SDR_DL_Adobe_v1.cube", interp=1, fullrange=1)
z_ConvertFormat(pixel_type="YV12", colorspace_op="rgb:709:709:full=>709:709:709:limited", chromaloc_op="top_left=>left", dither_type="ordered")

Example 2:
z_ConvertFormat(pixel_type="YUV444P16",colorspace_op="2020ncl:st2084:2020:l=>2020ncl:st2084:2020:l",chromaloc_op="top_left=>top_left",dither_type="none")
ConvertYUVtoXYZ(Color=0,HDRMode=0,OOTF=false,OutputMode=2)
ConverXYZ_BT2446_C_HDRtoSDR(PQMode=true,Lhdr=50000.0,Lsdr=100.0,pColor=0,pct_ref=0.6,pct_ip=0.6,pct_wp=1.0,pct_sdr_skin=1.0,pct_hdr_skin=0.44)
ConvertXYZtoYUV(Color=2,pColor=0,OOTF=false)
z_ConvertFormat(pixel_type="YV12",colorspace_op="709:709:709:l=>709:709:709:l",chromaloc_op="top_left=>left",dither_type="ordered")

I think the change to "left" (mpeg2), which is the standard for Rec709, should be placed at the end of the scripts ?

[FranceBB]

It should, in theory, be fine.
When you upscale the chroma to RGB, you're essentially going to the same resolution for both luma and chroma and, just like with 4:4:4, the chroma location loses its meaning.
When you're downscaling the chroma to go back to 4:2:0, however, it actually matters, but given that by default it assumes that you want the classic 4:2:0 (i.e left) and not type 2 (i.e top left), it will automatically get it right even if you don't specify it

[joearmstrong]

Thanks for your answer and explanation, FranceBB.

[StvG]

The source code is uploaded here.
Builds are here.

[tormento]

Originally Posted by StvG

Builds are here.

Thank you