z.lib resizers for AviSynth+

[Stephen R. Savage]

z_ConvertFormat(
    clip clip,
    int "width",
    int "height",
    str "pixel_type",
    str "colorspace_op",
    str "chromaloc_op",
    bool "interlaced",
    float "src_left",
    float "src_top",
    float "src_width",
    float "src_height",
    str "resample_filter",
    float "filter_param_a",
    float "filter_param_b",
    str "resample_filter_uv",
    float "filter_param_a_uv",
    float "filter_param_b_uv",
    str "dither_type")

width:                  output width in pixels
height:                 output height in pixels
pixel_type:             output pixel type ("YV12", "YUV420P16", etc.)
colorspace_op:          colorspace operation description
    Format is
        "matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"
    Example JPEG to MPEG: "170m:709:709:f=>709:709:709:l"
chromaloc_op:           chroma location operation description
    Format is "[locS]=>[locD]"
    Example JPEG to MPEG2: "center=>left"
interlaced:             whether to use interlaced mode (default: false)
resample_filter:        resampling mode
filter_param_a:         first parameter to resampler
filter_param_b:         second parameter to resampler
    Example Bicubic (Mitchell-Netravali):
        resample_filter="bicubic", filter_param_a=0.333, filter_param_b=0.333
    Example 4-tap Lanczos: resample_filter="lanczos", filter_param_a=4
resample_filter_uv:     resampling mode for chroma
filter_param_a_uv:      first parameter to chroma resampler
filter_param_b_uv:      second parameter to chroma resampler
dither_type:            dithering type

See VapourSynth documentation for valid string constants.

Also has all the AviSynth resizers, but with "z_" prefix.

Download: r2

[Reel.Deel]

Thanks twc, are you planning on adding support for colorspace and bit depth conversions?

[pinterf]

Thanks, I will look try it later it when I have time, just looked at the source.

A remark: Planar RGB plane order is PLANAR_G, PLANAR_B, PLANAR_R
Question: AVS+ default alignment is 32. Is the 64 byte alignment is a requirement for zimg?

[wonkey_monkey]

Just curious, but what does "z.lib" refer to in this context? It's too close to zlib to Google for it...

[Reel.Deel]

Originally Posted by davidhorman

Just curious, but what does "z.lib" refer to in this context? It's too close to zlib to Google for it...

See here: https://github.com/sekrit-twc/zimg#zlib

[TheFluff]

I'm pretty sure he named it that just to be obnoxious. It's what he does.

[filler56789]

Originally Posted by TheFluff

I'm pretty sure he named it that just to be obnoxious. It's what he does.

lol LoL LOL

[MysteryX]

Does this provide 16-bit support for AviSynth+?

[Sparktank]

Any updates on this?

[Sparktank]

Originally Posted by Stephen R. Savage

Is there any update needed?

I wouldn't know if it needs updating or not, so I was asking.

[Sparktank]

Does any of this have to do with Zimg?
Zimg is getting a lot of updates.
And the documentation for this is lazy. I find things better looking at source code.

ZIMG is getting a lot of updates. This isn't getting anything.
https://github.com/sekrit-twc/zimg

Would it be better to ask Pinterf to make a port? Or even cretindesalpes?

Open source is nice. But only for those who know what it means.

Why is ZIMG getting more updates than this very small port?
The doc really says nothing. I only learn from looking at the source code and guessing.


Does the AVS+ port mean nothing?
I'll stick to Dither_tools until AVS+ really improves on these functions.

[TheFluff]

It's an Avisynth plugin that uses the zimg resizers, yes, but since nobody seemed interested in it I doubt it'll ever get updated again. Just use the Vapoursynth version instead; there's no reason to use Avisynth anymore since the new avsproxy plugin lets you load even ancient no-source 32-bit Avisynth plugins in a 64-bit Vapoursynth process, or run Avisynth scripts if that's a thing you need.

[real.finder]

Originally Posted by TheFluff

It's an Avisynth plugin that uses the zimg resizers, yes, but since nobody seemed interested in it I doubt it'll ever get updated again. Just use the Vapoursynth version instead; there's no reason to use Avisynth anymore since the new avsproxy plugin lets you load even ancient no-source 32-bit Avisynth plugins in a 64-bit Vapoursynth process, or run Avisynth scripts if that's a thing you need.

what is the difference between avsproxy and MP_Pipeline?

[edcrfv94]

Originally Posted by real.finder

what is the difference between avsproxy and MP_Pipeline?

MP_Pipeline can not export clip to VapourSynth and pass it back.

[Stephen R. Savage]

Since it came up in the main AviSynth+ thread, I updated the first post with a new build. It has an updated version of z.lib.

[pinterf]

Originally Posted by Stephen R. Savage

Since it came up in the main AviSynth+ thread, I updated the first post with a new build. It has an updated version of z.lib.

Speedwise much better on my i7-7770. I guess it's really not much time is spent in resizers in complex scripts but I definitely like the art of optimization.

[pinterf]

Something strange happens.
When resizing vertically performance suddenly drops at delta=256.
Using avsresize r1b, x64, Intel i7-7700, current dev avs+ x64

w = 1920
h = 1920
BlankClip(width=w, height=h, length=8000, pixel_type = "YUV444P8")
#z_Spline64Resize(w,h+255) # 192.5 fps
z_Spline64Resize(w,h+256) #30 fps

[Stephen R. Savage]

You managed to find an obscure bug in z.lib. I updated first post with a new build (z.lib 2.7.3).

[videoh]

These conversions seem extremely slow compared to the Vapoursynth core equivalents. Really, it is too slow to be usable. Here is the script:

dgsource("THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
#tonemap()
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(8)

For a typical clip, this takes 45 seconds while the corresponding Vapoursynth script takes 13 seconds.

Is there any way to speed things up or do we have to declare Avisynth+ dead for things like this?

MAGA (Make Avisynth Great Again)

[pinterf]

Originally Posted by videoh

These conversions seem extremely slow compared to the Vapoursynth core equivalents. Really, it is too slow to be usable. Here is the script:

dgsource("THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
#tonemap()
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(8)

For a typical clip, this takes 45 seconds while the corresponding Vapoursynth script takes 13 seconds.

Is there any way to speed things up or do we have to declare Avisynth+ dead for things like this?

MAGA (Make Avisynth Great Again)

The functions - I think - are not autoregistering their MT modes for Avs+. Try using SetFilterMTMode avs+ function, probably they are MT_NICE_FILTER compatible but at least good for MT_MULTI_INSTANCE.