z.lib resizers for AviSynth+

[real.finder]

Originally Posted by mp3dom

Just asking, but does R3 works fine for everyone? I'm converting a 1920x1080 4:2:2 10bit clip from 709 to 601 and I get a system exception (without any additional infos) on x64 while on x86 Vdub2 crash and close without any warning. The same script works with R1g.

maybe it's better to post a simple script with colorbars that show the problem

[mp3dom]

Originally Posted by real.finder

maybe it's better to post a simple script with colorbars that show the problem

ColorBars(width=1920,height=1080,pixel_type="yuv422p10")
z_ConvertFormat(720,480,colorspace_op="709:709:709:limited=>170m:601:170m:limited",resample_filter="bicubic")

This made VDub2 crash without any warning/advice, at least here.

[StvG]

avsresize_r4: - fixed crashing when avs+ doesn't support frame properties;
- set _SARNum and _SARDen properties;
- read the input frame property _ChromaLocation if available;
- do not process clips with frame property _FiledBased > 0.

[zambelli]

Originally Posted by StvG

avsresize_r4: - fixed crashing when avs+ doesn't support frame properties;
- set _SARNum and _SARDen properties;
- read the input frame property _ChromaLocation if available;
- do not process clips with frame property _FiledBased > 0.

Thanks for the update - the new build no longer crashes VDub.

I've run into another unrelated bug though. It looks like it's been there going back to at least version r1g.

The output of z_ConvertFormat() is different depending on whether the input is integer or floating point.

Example:

ColorBars()
v1 = ConvertToPlanarRGB().ConvertBits(32).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg:l=>rgb:709:709:f")
v2 = ConvertToPlanarRGB().ConvertBits(16).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg:l=>rgb:709:709:f")

Interleave(v1, v2)

[StvG]

zimg expects full range when input is YUV float or RGB.
In your example "ColorBars().ConvertToPlanarRGB()" returns RGB in limited range so after "ConvertToYUV444(matrix="Rec601")" you have limited range but zimg expects full range.
The following give you identical output:

ColorBars()
#v1 = ConvertToPlanarRGB().z_ConvertFormat(pixel_type="rgbps", colorspace_op="auto:auto:auto:l=>same:same:same:f").ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg=>rgb:709:709") # also same output
v1 = ConvertToPlanarRGB().ConvertBits(32, fulls=false, fulld=true).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg=>rgb:709:709")
v2 = ConvertToPlanarRGB().ConvertBits(16).ConvertToYUV444(matrix="Rec601").z_ConvertFormat(pixel_type="RGBP8", colorspace_op="470bg:470bg:470bg=>rgb:709:709")

Interleave(v1, v2)

[zambelli]

Originally Posted by StvG

zimg expects full range when input is YUV float or RGB.

Are you saying that when input to zimg is floating point YUV and the input range is indicated as "limited", zimg assumes that black is Y=0.0 and white is Y=1.0?

Shouldn't "limited" range imply that black is Y=0.06 and white is Y=0.92?

When RGBP8 0-255 is converted to RGBPS using Avisynth's internal ConvertBits(32), I am making the assumption that 0 gets mapped to 0.0 and 255 gets mapped to 1.0.
When RGBPS gets converted to YUV444PS using internal ConvertToYUV444(matrix="Rec601"), I am making the assumption that RGB 0.0 gets mapped to Y=16.0/255.0, and RGB 1.0 gets mapped to Y=235.0/255.0 since the matrix indicates RGB full --> YUV limited.

Am I making the wrong assumptions there?

[real.finder]

Originally Posted by zambelli

Are you saying that when input to zimg is floating point YUV and the input range is indicated as "limited", zimg assumes that black is Y=0.0 and white is Y=1.0?

Shouldn't "limited" range imply that black is Y=0.06 and white is Y=0.92?

When RGBP8 0-255 is converted to RGBPS using Avisynth's internal ConvertBits(32), I am making the assumption that 0 gets mapped to 0.0 and 255 gets mapped to 1.0.
When RGBPS gets converted to YUV444PS using internal ConvertToYUV444(matrix="Rec601"), I am making the assumption that RGB 0.0 gets mapped to Y=16.0/255.0, and RGB 1.0 gets mapped to Y=235.0/255.0 since the matrix indicates RGB full --> YUV limited.

Am I making the wrong assumptions there?

https://github.com/sekrit-twc/zimg/issues/134

[zambelli]

Originally Posted by real.finder

https://github.com/sekrit-twc/zimg/issues/134

Huh. Interesting. Is the last comment in that thread correct - is AVS+ converting incorrectly?

So when an 8-bit limited range signal is converted to YUV4xxPS with zimg, does that mean 16 maps to Y=-0.07 and 235 maps to Y=1.09?

[real.finder]

Originally Posted by zambelli

Huh. Interesting. Is the last comment in that thread correct - is AVS+ converting incorrectly?

So when an 8-bit limited range signal is converted to YUV4xxPS with zimg, does that mean 16 maps to Y=-0.07 and 235 maps to Y=1.09?

I don't think it's incorrect, float can be any thing, I don't see problem using 0.06..0.92 but it will not stay as it after using some filters since float don't clamp anyway

anyway, pinterf seems plan about do something about this using frame properties

so for now, you can use z_ConvertFormat if you convert to float permanently, and avs one if you do it temporarily (mean int -> float -> int)

So when an 8-bit limited range signal is converted to YUV4xxPS with zimg, does that mean 16 maps to Y=-0.07 and 235 maps to Y=1.09?

don't know, but you can try it (even if it hard since avsp don't show the real value of the pixel, so you must find some work around)

[TheFluff]

Originally Posted by zambelli

Are you saying that when input to zimg is floating point YUV and the input range is indicated as "limited", zimg assumes that black is Y=0.0 and white is Y=1.0?

zimg always assumes that float input is in the range 0.0-1.0 regardless of whether you tell it that the input is limited range or not, and I believe likewise always converts float output into that range. This is because "limited range" makes no sense for float, or perhaps more accurately it's always limited range. Limited range means using a pair of arbitrarily chosen values to represent black and white instead of using the minimum and maximum values of the storage format (e.g. 8-bit integer, 16-bit integer, 32-bit float), but with float it makes no sense to use the minimum and maximum representable values of the storage format as black and white because then you get different numerical precision in different parts of the range, so we use the arbitrary convention 0.0-1.0 instead. There is no point in choosing a different arbitrary convention.

[zambelli]

Originally Posted by TheFluff

zimg always assumes that float input is in the range 0.0-1.0 regardless of whether you tell it that the input is limited range or not, and I believe likewise always converts float output into that range. [...] There is no point in choosing a different arbitrary convention.

I'm OK with that, it makes sense now, but I'm surprised that Avisynth might not be aligned with that same convention.

I'm still curious: what happens to superblack and superwhite values from a limited Y integer range when it's converted to float? Do they end up mapping to <0 and >1?

[pinterf]

Originally Posted by zambelli

I'm OK with that, it makes sense now, but I'm surprised that Avisynth might not be aligned with that same convention.

I'm still curious: what happens to superblack and superwhite values from a limited Y integer range when it's converted to float? Do they end up mapping to <0 and >1?

Yes, they are mapped then outside the 0..1 range.
At the time I was developing the high bit depth additions I was not aware of any conventions. I suppose this convention was not even a strong one. And it had two phases, even putting the float UV chroma range to zero center was an extra project for me years ago, mainly because I wanted it to be compatible with zimg (and VS). And because it is a reasonable convention. Now it needs a third step: handle 32 bit float format uniformly across avs+ core and plugins. With additions attention to the implemented auto-conversions in Expr and masktools lut.

[hello_hello]

To clarify....

z_ConvertFormat(720,480,colorspace_op="709:709:709:limited=>170m:601:170m:limited")

If the source is some flavour of YUV and the input to z_ConvertFormat is 32 bit float, should "limited" be changed to "full", or is the specified range ignored for float?

[StvG]

Originally Posted by TheFluff

... and I believe likewise always converts float output into that range.

If input is float and output is float - color_range source/destination doesn't have effect; range is always assumed full.
If input is int and output is float - color_range source set to full keeps the values same and returns x/255 (8-bit) within 0..1 range; color_range source set to limited expands the range limited to full; color_range destination doesn't have effect.
If input is float (full range) and output is int - color_range source doesn't have effect; color_range destination set to limited does full to limited; color_range destination set to full keeps the full range.

Originally Posted by hello_hello

To clarify....

z_ConvertFormat(720,480,colorspace_op="709:709:709:limited=>170m:601:170m:limited")

If the source is some flavour of YUV and the input to z_ConvertFormat is 32 bit float, should "limited" be changed to "full", or is the specified range ignored for float?

Using the same value for source and destination means no conversion. It doesn't matter if you use limited for source and destination or full for source and destination, or omit color_range at all.

[StvG]

avsresize_r5: use chromaloc frame property (when available) for the legacy resizers.

[kedautinh12]

I seen zimg have new ver
https://github.com/sekrit-twc/zimg/b...ster/ChangeLog

[StvG]

avsresize_r6: - registered as MT_NICE_FILTER;
- read frame properties from every frame (previously only from the first frame);
- zimg@8d0b839.

[kedautinh12]

Thanks

[StvG]

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

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