• Make width/height optional arguments to allow 1x resampling with non-interpolatory kernels without manually specifying w/h.
• add "match centers" resampling model.
• Implement blur aka resizeable filter curves.

When using descale, if the input clip is not Progressive, it needs to split per-field and descale each field separately to half the height, and these shifts must be applied by default unless the user passes their own shift (so the default of (0, 0) should probably be changed to None)

first field = 0.25 / (clip.height / (output_height / 2))
second_field = -0.25 / (clip.height / (output_height / 2))

Radius, param1, param2, and wparam are not configurable.

Scalings that are possible using the plugin directly are not possible within vskernels
For example:
clip = vskernels.EwaRobidoux(b=50, c=50).scale(clip, 960, 540) will error with TypeError: Placebo.__init__() got multiple values for argument 'b'
but
clip = core.placebo.Resample(clip, 960, 540, filter="ewa_robidoux", param1=50, param2=50) works just fine.

Fmtconv's spline works differently from the Spline100, Spline144, etc resizers found in other applications, they do not produce the same results. These kernels can be seen as entirely different and as such they should be made to match the original Spline kernels or just removed entirely.

from vstools import vs, initialize_clip, Matrix, Transfer, Primaries, ColorRange
from vskernels import Point

reference = vs.core.imwri.Read("reference.png")
reference = initialize_clip(reference, None)
limited_range_yuv = Point.resample(reference, range=ColorRange.FULL, matrix=Matrix.BT709, transfer=Transfer.BT709, format=vs.YUV444P8)

This script currently produces limited range output since the zimg values do not match the frameprop values. Using range=ColorRange.FULL.value_zimg does produce a full range output, but it would be more convenient and foolproof if the value_zimg could be automatically used when providing a ColorRange

Hello. Nice job.

Of interest, requirements.txt mentions vstools>=2.0.5
however over at https://github.com/Irrational-Encoding-Wizardry/vs-tools the latest release is only 1.3.0.

Am I looking at the right place and at the right vstools ?

Thanks.

The main benefit here would be elliptical (EWA) kernel support, such as ewa_lanczos or ewa_robidoux*. From memory Robidoux kernels were originally intended to be EWA, there are posts on the imagemagick forum about this but I cannot find them at the moment.

With the placebo.Resample plugin, make sure not to accidentally use the 'bicubic' filter -- it's actually some kind of 'fast' bicubic kernel which is extremely blurry and not configurable.

This is useless and a duplicate of zimg's Point

All the EWA kernels give AttributeError: module 'vskernels' has no attribute 'EWALanczos' in VSEditor. Other kernels in various.py and Lanczos in resize.py have no issue.

These Bicubic presets are very questionable, producing poor results, with some of them even being literal shitposts that were kept anyways.

Bicubic Zopti variants specifically are auto generated bicubic presets based on poor metrics that were never even investigated through human eyes.

Users can still use these kernels through manually setting b/c, but their time as a preset should be coming to an end.

Currently it's not clear to me whether we can really affect the shift introduced during the resampling of interlaced video.

Specifically, some implementations may improperly shift the fields in the same direction (@wiwaz can clarify or correct me here), however currently, to my understanding, there's no way to follow this behaviour, making it impossible to descale it the same way unless you separate the fields yourself. This is rather impractical in certain situations where you have to check different kernels for every frame. Having some kind of way to either override these parameters or toggle between different directions and the same direction would be nice.