Internaly multi-threaded resampling functions

[tormento]

Originally Posted by hello_hello

I did try it both ways.

I was actually wrong. I forgot a 'c' in the function name.

They are eventually equal in image output but jpsdr's SinPowResizeMT is faster, with threads=1 in a Prefetch (2,6) script.

I have tried DeSinPowResizeMT to downsize an image but the results is awful.

[FranceBB]

Originally Posted by tormento

DeSinPowResizeMT to downsize an image but the results is awful.

Each "De" version of resampling kernels is used to invert such a kernel. If the content was upscaled with Bilinear, then DeBilinear inverts it, if the content was upscaled with Bicubic, then DeBicubic inverts it and so on.
In other words, only if an image was upscaled with SinPowerResize, then you can reverse it using the "De" variant.

A few catches, though:

1) SinPower is only really used to downscale, so it's very unlikely to ever find a source that has been upscaled with such a kernel

2) Inverting a kernel isn't a normal downscale, you have to not only be sure that a content was upscaled with that resizing kernel, but also that the resolution you're bringing it back to was the one you started with.



For your use-case which is downscaling, you can go with SinPowerResize and call it a day.

[tormento]

@jpsdr

Can your resampling functions deal with fractional resolutions? If positive, have I to converto to floating before your resizing filter or the output is floating already?

[jpsdr]

They are exactly the same as the core functions. Parameters target are interger, src are float.
I don't realy understand the question about the ouput. The data depth is the same as the input, if picture data input is float, picture data output is float.

[FranceBB]

Originally Posted by tormento

Can your resampling functions deal with fractional resolutions?

You can't convert to fractional resolutions, they have to be integers. If you work in yv12 then they can only be even and if you work in yv16, yv24 or rgb24 then they can also be odd.

For instance:

ColorBars(848, 480, pixel_type="yv12")

Spline64Resize(848, 478)

because you can only resize to even resolutions, but if you go to yv16, yv24 or rgb24 then you can resize to odd resolutions, so this works:

ColorBars(848, 480, pixel_type="yv16")

Spline64Resize(848, 479)

same goes for this:

ColorBars(848, 480, pixel_type="yv24")

Spline64Resize(848, 479)

and of course this:

ColorBars(848, 480, pixel_type="RGB24")

Spline64Resize(848, 479)

Note the "479" here being odd, yet working.
Anyway, encoding files with an odd resolution is a very bad behavior and I know a person or two who would try to find you and scold you if they were to get in touch with a similarly encoded file hahahahahahha

Originally Posted by tormento

If positive, have I to converto to floating before your resizing filter or the output is floating already?

Nope, ConvertBits(32) won't save you, you can't resize with non integer values, so sticking a "ConvertBits(32)" before Spline64ResizeMT() won't automagically allow you to do something like Spline64Resize(848, 479.5).


TL;DR just resize to even pixels and encode it.

[DTL]

Originally Posted by tormento

@jpsdr

Can your resampling functions deal with fractional resolutions? If positive, have I to converto to floating before your resizing filter or the output is floating already?

First you need to understand the difference between:
1. Frame/canvas size
2. Image size
3. Resolution

1. Frame or digital canvas size always integer (simply number of samples)

2. Image size can be any real number in size (also the position too) and in the beast case Image size < Frame size. For example at ADC of Analog TV line (ITU Rec.601 and later) it takes 702 samples of 720 frame size. Outer samples help to encode transients from edge of line to the 'known level' and it is black level. With your fractional V image size it is better to add some padding to digital frame size to keep these transients (also you need to shape/prepare/condition these transients in a good way so any upscale resizer at display will create nice image borders without Gibbs ringing).
The 'pure digital' standards like DV and many more others with 'all-samples active image') are not completely defined at the image edges and require some hacking at the image processing to handle image edges of 'special case' (typically as some extension of last sample to half kernel size or other ways to fix edge issues).

3. Resolution is property of image data and can be from zero to max (soft of Nyquist and Gibbs limited).

Here is some simple drawing how Image can be positioned inside Frame
https://ibb.co/d23F04C


After you prepare an Image inside Frame (Digital) you can perform a non-integer scale (and shift) to fine tune your image in digital form on digital canvas. If resizer filters do not support real number direct scale - you can use upsize to N and downsize to M integers so output will have N/M real numbered size. Any avisynth resizer should support integer-sized resize (also see chroma subsampling limitations if used).

So with AVS resizers you operate with Frame/canvas integer sized objects all the time but your Image inside this Frame can be real numbered in size and position (relative to sampling grid). Similar to any real object in the image. You can treat Image as largest possible object in the digital Frame.

If you set Image size = Frame size you lost about half samples to proper encode Image size and position in real numbers space. And force display scaling to work in harder way to make some more or less nice scaling at the edges if image. For N.x Image size you anyway need to use Frame size at least of N+1 or more integer. For less scaling aftifacts it is recommended to pad source frame enough before scaling and make scaling to output Frame size and try to Crop as many Frame samples around Image as you decide (also test with your display scalers how they will handle such prepared Image edges - simple scalers can make more halo or even ringing at poorly conditioned Image edges). In a 'perfect digital world' we need to have some 'safe area' around Image in the Frame and auto-overscan in the display device to cut-off this transient area to show only Image area limited by hardware frame of display device. Like emulating physical overscan at CRT display device. If user set zero overscan at display device it will cause some issues like black border at white areas near frame edge (or any other level of Frame edge defined). If display device also black frame over Image area it may be minor issue.

[tormento]

Thank you all!