JPSDR Avisynth's plugins pack

[DTL]

"The only thing sure is that if the string is not here, the ressource won't be called..."

Yes - it looks was hidden bug by microsoft in some (many) versions and finally become activated in last versions (or by some other thing). As pointed in the stackoverflow answers - presence of InitializeCriticalSectionEx function in a binary already mean it is not compatible with WinXP.

The question applies not just to v120_xp but to any other _xp toolset (which even VS2017 has), and InitializeCriticalSectionEx is one of the few signature functions that surface whenever a program was compiled without XP support. –
ivan_pozdeev
CommentedDec 1, 2017 at 15:04

But for some time that partial bug of the compiler was not completely activated (by marking this function for connection by binary loader ?).

[jpsdr]

@FranceBB
When you can, i've put on the server a release for what should be the last test.

[FranceBB]

No issues found with JincResizeMT_Test_VS2022_v2

https://i.postimg.cc/d0mhMqsL/image.png

works like a charm too. :)
https://i.postimg.cc/J0qwm2yc/image.png

[jpsdr]

Good, thanks for testing. I hope in the begining of next week make a new release of the actual code.

[DTL]

Yes - JincResizeMT looks like ready for release. I made several encodings of about several hours total runtime and no significant issues found.

"No issues found with JincResizeMT_Test_VS2022_v2"

You may also test its downscaler UserDefined4ResizeSPMT() even with default settings.

[jpsdr]

@FranceBB
I've updated my Visual 2019 to the last version.
I've put on the server an XP build for testing, if you can check it when you have time.

[tormento]

What are the difference between this implementation of jinc and ewa-lanczos in avslibplacebo, beside one running on cpu and the other on gpu?

[jpsdr]

As i absolutely don't know ewa-lanczos, i have no idea.

[DTL]

I hope they are enough equal. This implementation uses kernel quantization table as some LUT for better performance and may be lower in precision. The base kernel as jinc weithged by jinc expected to be the same. And single-pass 2D weighting resampling engine too. The exact implementation may be different - like usage of square or round kernel (it is free to compute square instead of round with striped out some corners in SIMD) and that quantization process (it is adjustable and you can now set quant_x/y to 2048 if 256 precision is not enough).

Better to make your own tests of both jinc resize implementations and to see if any difference visible.

[tormento]

As i absolutely don't know ewa-lanczos, i have no idea.
Found this (https://github.com/mpv-player/mpv/issues/2015).

[DTL]

The most important redesign of filters for better performance we need in 202x for multi-core CPUs with slow host RAM is different plane/frame and partial plane/frame processing modes. See current examples in master-1 branch for filters Invert() and RGBAdjust() (also updated filters API in avisynth.h) - https://github.com/DTL2020/AviSynthPlus/tree/master-1 . I still not received any reply from pinterf or possible other developers of AVS+ core if it is planned for addition to main branch. Also it is not totally finished for all possible scripts versions (currently working for single filterchain without clip splitting and fully implemented only for transform in place filters).

Can you analyse filters in your pack and complexity of addition of plane-separated, partial-plane and may be partial-frame (for interleaved formats) modes ? To make somethin more useful in performance we need filters used in QTGMC script - it is at least NNEDI3 and may be ResampleMT->GaussResizeMT (used in some way of prefiltering blur before motion search). The MCompensate and MDegrainX from pinterf mvtools2 2.7.46 I will try to do.

For resize filters it is easy enough to make at least frame-splitting part of new API (without pass-through of partial processing to previous filters). I.e. new GetPlaneOfFrame() and ProcessPlaneOfFrame() methods without forwarding partial requests to child filters. For non-resize filters it is possible to make full update. For non-transform in place filters I hope to make some solution in future.

As I look in NNEDI3 sources - it is not hard to make at least separated planes output because it is not uses inter-plane dependencies in GetFrame() method ? For partial plane output it may require more complex redesign of plane-processing function. Though parts are H-stripes and they are close to your internal multithreading plane separation ?

[DTL]

Found this (https://github.com/mpv-player/mpv/issues/2015).

About 'blur' value to scale kernel in spatial size (relative to 2D sampling grid) - it is present in JincResizeMT.

About fine control over kernel size/cut-off - it is not present in JincResizeMT currently because it uses internal conversion of integer taps to float jinc zeroes. But it already have 's/support' kernel size control for UserDefined4ResizeMT and if users like - it can be expanded to JincResizeMT (as alternative to taps control argument).

Possible solution: if taps argument is not set and s-argument is set for JincResizeMt filter - use s argument value in the filter size control (radius variable in JincResize sources) instead of LUT of jinc-zeroes.

At the https://github.com/DTL2020/JincResizeMT/blob/5f42a8511efba36d4e9f0660fcb3c913ae3847a3/Src/JincResizeMT.cpp#L1738 equal to
https://github.com/DTL2020/JincResizeMT/blob/5f42a8511efba36d4e9f0660fcb3c913ae3847a3/Src/JincResizeMT.cpp#L1741

It is simply different ways to control jinc kernel size cut-off because it is infinite in size and not self-limited in space. May be users and developers of JincResize not found it useful to have float-precision control and make enough good taps-number size control. But if some other developers found it somehow useful to have float-precision control of filter size it can be easily added.

It looks in libplacebo developers simply make some named presets of jinc resize with somehow different combinations of blur and radius/support size. The JincResize(MT) simply exposes these control params to user script.

Like: "ewa_lanczossharp", 3.2383154841662362, jinc, .blur = 0.9812505644269356
it is equal to JincResize(blur = 0.9812505644269356, support/radius=3.2383154841662362).
From jinc_zeros table - https://github.com/DTL2020/JincResizeMT/blob/5f42a8511efba36d4e9f0660fcb3c913ae3847a3/Src/JincResizeMT.cpp#L181
it is radius of 3rd zero. So equal to tap=2 (?).

[jpsdr]

Made a new version of all my filters, don't have time right now to update the first pages.

[tormento]

Made a new version of all my filters, don't have time right now to update the first pages.
Thank you.

The included plugins_JPSDR - Readme.txt refers to 4.0.0.

[jpsdr]

Ah... Maybe i forgot to update in the .7z. I'll check and update it in a next build when the last 21.1.x LLVM will be out, or if there is an issue to fix wich will produce a new release instead of just a new build.

[jpsdr]

First page updated.

[jpsdr]

The included plugins_JPSDR - Readme.txt refers to 4.0.0.

New build (but not new version), fix the Readme.

[FranceBB]

New build (but not new version), fix the Readme.

Oh... :(
https://images2.imgbox.com/38/45/nZhwAwBD_o.png


Doesn't work on Windows XP Professional x86 for the issue we talked about last time. I'll try to make a build next week with Visual Studio 2026, let's see how it goes.

[Emulgator]

As I seem to gather, also from looking at other compile's problems:
Any function suffixed Ex or 2 seems to give grief in terms of backwards compatibilty. Best to avoid these...?

[jpsdr]

@Emulgator
The problem is that there is NOT such functions used. It complains about functions not in the code !

So, we have :

Last Visual Studio 2019 (11.53) version produces Windows 7 compatible Avisynth and my plugins builds, but not working Windows XP versions of my plugins.
Last Visual Studio 2022 (14.23) probably produces (because of last toolset version from what i read) incompatible Windows 7 Avisynth builds (don't know for my plugins) but working Windows XP from previous test.
Visual Studio 2026 produces incompatible Windows 7 Avisynth builds... This realy begins to become a nightmare !

EDIT:
I've uploaded new XP builds.

[FranceBB]

I've uploaded new XP builds.

They work like a charm. :D

https://images2.imgbox.com/1f/96/BJ3GiHFh_o.png

[FranceBB]

For those curious, here's the actual test script with a picture I took at the pond in Osterley:


ImageSource("D:\PXL_20251226_152608961.jpg")
Converttoyv24(matrix="Rec709")


downscale_point=PointResizeMT(Width/16, Height/16).Subtitle("PointResize")
downscale_gauss=GaussResizeMT(Width/16, Height/16).Subtitle("GaussResize")
downscale_bilinear=BilinearResizeMT(Width/16, Height/16).Subtitle("BilinearResize")
downscale_bicubic=BicubicResizeMT(Width/16, Height/16).Subtitle("BicubicResize")
downscale_sinc=SincResizeMT(Width/16, Height/16).Subtitle("SincResize")
downscale_lanczos=LanczosResizeMT(Width/16, Height/16).Subtitle("LanczosResize")
downscale_blackman=BlackmanResizeMT(Width/16, Height/16).Subtitle("BlackmanResize")
downscale_jinc=JincResizeMT(Width/16, Height/16).Subtitle("JincResize")
downscale_sin=SinPowResizeMT(Width/16, Height/16).Subtitle("SinPowerResize")
downscale_spline=Spline64ResizeMT(Width/16, Height/16).Subtitle("Spline64Resize")

v1=StackHorizontal(downscale_point, downscale_gauss, downscale_bilinear, downscale_bicubic, downscale_sinc)
v2=StackHorizontal(downscale_lanczos, downscale_blackman, downscale_jinc, downscale_sin, downscale_spline)

StackVertical(v1, v2)


https://images2.imgbox.com/62/00/rQ1blF2W_o.png

[tormento]

For those curious, here's the actual test script with a picture I took at the pond in Osterley
Can you share it uncompressed?

[FranceBB]

Sure, here it is: https://photos.app.goo.gl/UW2mWj88zDa3rnok8
That's the original 4080×3072 ƒ/1.85 1/198 6.81mm ISO125 picture.
Please note that it's in the Ultra HDR standard we discussed here https://forum.doom9.org/showpost.php?p=2010083&postcount=9, meaning that if you don't have a proper decoder, it will only decode the SDR version without interpreting the XMP gain map (i.e the HDR metadata).

[tormento]

Sure, here it is
How on hell can I save that photo? ;)
if you don't have a proper decoder
Such as? :)

[FranceBB]

Such as? :)


Any modern version of Google Chrome is gonna be able to read it correctly on Windows 11, however that implies that you have HDR mode enabled.
On Android of course Google Photo also reads it correctly.

[Ingram112]

The consolidation of multiple Avisynth plugins into a single DLL is a significant improvement for multi-threading efficiency. Reducing the number of threadpools can noticeably improve performance on systems with high CPU core counts. It's interesting to see how JPSDR merges AutoYUY2, NNEDI3, ResampleMT, and other filters in one pack.

[jpsdr]

Yes, one DLL to rule them all.

[jpsdr]

New version, see first post.

[DTL]

It looks like you update only plugins_JPSDR repository with new AVX512 resample functions but ResampleMT repository only with header files with new version number.

Also about possible performance optimization of V-stripe scan order H-resamplers (AVX512 and AVX2) there is one more simple idea about meander scan order - see comment https://github.com/pinterf/AviSynthPlus/commit/a37fc225ed7a261a9aa748d08f6bf0a9fd8addd9#r184890431

Also other ideas may be not completely tested is meander scan + software prefetch for read (source bytes) and also software prefetch for write for result storage (next target bytes of the next V-stripe to process). There is a separate instruction PREFETCHW to hint cacheline fetch from RAM to caches to make it 'hot' in cache and allow faster write.

What was tested but did not make significant performance changes is software cache flushing to attempt to flush stored result cache lines to RAM to free cache resources for next source and target bytes.

[jpsdr]

No, both have new AVX512 functions.

[DTL]

Github shows only one commit Commit 360d443
and only 2 files changed
resample.h
resample.rc
in May 2026.

Or the all AVX512 commits were at Mar 2026 ?

[jpsdr]

Yes.
I haven't time until now to build and make a minimal check (the Test_Resample_New.avs you made) on my PC with AVX512.