JPSDR Avisynth's plugins pack

[FranceBB]

Thank you! :D

[kedautinh12]

Thank you! :D

Carefull, some one video remind you increase post count without meaning post :D

[FranceBB]

Carefull, some one video remind you increase post count without meaning post :D

You mean Donald now-water-polo-manager-after-retiring Graft? xD
He knows me and I know him, we're fine considering that long time ago I paid for the DGDecodeNV license ehehehehehehe
Good luck to him and his water polo team, I guess.
I hope that coaching those guys gives him many more rewards than coding for a bunch of virtual users on Doom9 :P

Jokes aside, the only thing that changed in this version might just be a "silly" Avisynth header targeting 3.7.3, but Jean Philippe deserves all the thanks in the world for what he has done 'till now, especially with HDRTools (and to a lesser extent NNEDI3 as he is literally the only one who picked it up and prevented it from dying).

[kedautinh12]

I mean R***D*** :D

[guest]

You mean Donald now-water-polo-manager-after-retiring Graft? xD


So, what does that mean for all his "stuff" ??

[kedautinh12]

So, what does that mean for all his "stuff" ??

He update some stuff from here
http://rationalqm.us/board/viewtopic.php?f=5&t=463&sid=371cac0f28eb38899f583dc8fe9d6181

And his Tools and Utilities (old)
https://www.rationalqm.us/mine.html

[FranceBB]

So, what does that mean for all his "stuff" ??

He still updates his stuff, but only as a home user now, for the fun of it.
When I said "retired" I meant from his real job, not from the community. ;)
His hobby nowadays is coaching a water polo team and I wish him all the best. :)

[jpsdr]

New version, see first post.

[FranceBB]

Thanks to both Jean Philippe and whatever DTL's real name is xD
Looks like I'm gonna have something to try tomorrow morning at work. :)

[jpsdr]

New version, see first post.

[FranceBB]

Thanks for the update! :)
I'll test it tomorrow.

[hello_hello]

After spending forever trying to debug a resizing function, I discovered this...
So far it's the only resolution/cropping combination I've found that produces an incorrect result. I'm using version 3.3.5 of the plugins pack (64 bit).

ColorBars().KillAudio()
Spline36Resize(960,718)
Lanczos4ResizeMT(1280,716, 0,1,960,716)

Output 960x716 (screenshot half size)
https://i.ibb.co/sFV4d1v/Lanczos4-Resize-MT.png


ColorBars().KillAudio()
Spline36Resize(960,718)
Lanczos4Resize(1280,716, 0,1,960,716)

Output 1280x716 (screenshot half size)
https://i.ibb.co/0DRFvpH/Lanczos4-Resize.png

For reasons I don't understand, the ResampleMT result is correct for a YV12 source (but incorrect for YV24, YV16 and Y8).

ColorBars().KillAudio()
ConvertToYUV420()
Spline36Resize(960,718)
Lanczos4ResizeMT(1280,716, 0,1,960,716)

[jpsdr]

I don't have time for now, but i'll look at it when i'll have time.

[hello_hello]

I found another fun one.

The following produces the error message "Crop: you cannot use crop to enlarge or 'shift' a clip"

ColorBars().KillAudio()
Spline36Resize(1210,604)
Spline36ResizeMT(1208,600, 1,2,-1,-2)

[jpsdr]

One day, i'll try to look, but unfortunately right now i absolutely have no time... :(

[Guest]

One day, i'll try to look, but unfortunately right now i absolutely have no time... :(

FYI,

There is something very wrong, here :-

https://github.com/jpsdr/x265/releases/tag/3.50.116

[jpsdr]

Ouuups.... Thanks.

[Guest]

Ouuups.... Thanks.

You're welcome, but I have to ask, are you planning to add the --auto-aq command to a future build ??

I did just read the x265_Help.txt file and there's reference to --aq-auto, but I can't get it to work (process).

You've got --aq-mode 5...

Cheers

[jpsdr]

This is not realy the right place for x265.
Also, about --aq-auto, check here (http://forum.doom9.org/showthread.php?p=1998149#post1998149).

[tormento]

Merge of Avisynth's plugins
I saw that you don't include NNEDI3_weights.bin.

Isn't it necessary for your build?

[jpsdr]

@tormento
No, the neural network weights are included in the DLL, this is why the NNEDI3 dll is "so big".

[jpsdr]

After spending forever trying to debug a resizing function, I discovered this...
So far it's the only resolution/cropping combination I've found that produces an incorrect result. I'm using version 3.3.5 of the plugins pack (64 bit).

ColorBars().KillAudio()
Spline36Resize(960,718)
Lanczos4ResizeMT(1280,716, 0,1,960,716)

Output 960x716 (screenshot half size)
...
Fixed on github, new build soon (or you can make your build).

[StainlessS]

Thanks j, you be the man.
Mucho grassy ass.

[DTL]

Pinterf in the process of preparing big update to the very old AVS resampling engine - expected in the 3.7.4 release or next weeks. It will now have same quality in processing edges of the frame as fmtconv and other (like avsresize) and even finally stop emit errors like 'frame size too small for current resize support'. It is expected for updating in this plugins pack too. Also may be fixed other possible bugs.

[jpsdr]

Argh...
I have some requirements of my own i still keep, it's the fact that my filters can be build with VS 2010. If pinterf's updates don't break my rule, with time, i'll include them, but otherwise, it will stay at it is.

[tormento]

Pinterf in the process of preparing big update to the very old AVS resampling engine - expected in the 3.7.4 release or next weeks. It will now have same quality in processing edges of the frame as fmtconv and other (like avsresize) and even finally stop emit errors like 'frame size too small for current resize support'. It is expected for updating in this plugins pack too. Also may be fixed other possible bugs.
What about chroma position when downscaling? AFAIK AVSResize only is capable of giving good and reliable results, as per Resize8 thread.

[DTL]

What about chroma position when downscaling? AFAIK AVSResize only is capable of giving good and reliable results, as per Resize8 thread.

Can you provide some test scrips to show the difference in processing between AVSresize resampler and AVS+ core resampler for that differences ? And mark or describe where to look for difference.

[jpsdr]

Pinterf in the process of preparing big update to the very old AVS resampling engine - expected in the 3.7.4 release or next weeks. It will now have same quality in processing edges of the frame as fmtconv and other (like avsresize) and even finally stop emit errors like 'frame size too small for current resize support'. It is expected for updating in this plugins pack too. Also may be fixed other possible bugs.

After a little thought, i don't see why there should be any change in the core engine for the edge frame, the structure coefficients (pixel_coefficient[] and pixel_offset[]) and the functions in resample_avx2 and resample_sse shouldn't change.
Only the computation of the coefficients around the edge position in ResamplingFunction::GetResamplingProgram will change to have better result.
If it's only that (and i think it should be), there is a big chance i'll be able to update...;)
If not and everything is redonne, there is a big chance i'll unfortunately not update...:(

[tormento]

Can you provide some test scrips to show the difference in processing between AVSresize resampler and AVS+ core resampler for that differences ? And mark or describe where to look for difference.
The discussion is part of the Resize8 (https://forum.doom9.org/showthread.php?t=183057) thread.

[DTL]

The discussion is part of the Resize8 (https://forum.doom9.org/showthread.php?t=183057) thread.

You may try latest testbuild with different chroma placement options and make report if it solve that issues: https://github.com/AviSynth/AviSynthPlus/issues/431#issuecomment-2745886159

New Parameters:

"placement": Specifies chroma placement, with options such as "auto", "mpeg2", "center", etc.,
similar to ConvertToXXXX and Text. The default is "auto", which reads the frame property
_ChromaLocation for 420, 422, and 411 formats.

"keepc" (boolean, default: true): Determines whether to "keep center".
If true, the chroma shift from "placement" is now considered when resizing chroma.

GaussResize(width3, height3) # keepc=true, placement="auto"
GaussResize(width3, height3, placement="auto") # the new default, read frame props
GaussResize(width3, height3, placement="bottom") #center, top, etc visible differences in chroma
GaussResize(width3, height3, placement="center") #legacy Avisynth worked like this
GaussResize(width3, height3, keepc=false) #dont keep pixel center, not even for the luma

[tormento]

You may try latest testbuild with different chroma placement options and make report if it solve that issues
My fault, I have not explained things clearly.

Resize8 applies different scaling to chroma and luma channels to keep as much data as possibile, i.e. if you resize 1920p to 1280p it's stupid to apply the same ratio to chroma, as you will lose a lot more information than differently resizing chroma (which already is 960p) and luma.

The problem that now arises is to find the correct chroma shift to adapt the differently resized chroma to luma.

The author of Resize8 found that AVSresize is the only resizer that fit that job correctly. That's why I told you to read that thread.

I have not enough knowledge to test and understand if a separate resize produces a correct chroma placement. :p

[DTL]

" if you resize 1920p to 1280p it's stupid to apply the same ratio to chroma, as you will lose a lot more information than differently resizing chroma (which already is 960p) and luma."

It can work good only if you go from typical 4:2:0 broadcast and delivery to the more rare 4:4:4 format. If you keep chroma subsampling mode at the output - typically the chroma downscale ratio must match the luma.

Though chroma-subsampled formats are non-linear and ugly by design and it is required something like neural-network aided rescale to make artifacts lower. Same as we have in NNEDI resize for upsample aliased fields from interlaced frames. The neural network looks like was trained on the typical aliasing artifacts of the fields and now create more pleasing resuilts.

Same way someone need to invest in the neural network traning on the 4:2:0 chroma subsampling artifacts and make finally better and NN-assited decoder of 4:2:0 color into RGB with less distortions. Chroma placement is not the only issue in these color formats.

Also possible unlimited number of non-linear resampling methods for such lossy formats and each may have its strong and weak parts.

[tormento]

It can work good only if you go from typical 4:2:0 broadcast and delivery to the more rare 4:4:4 format.
That is really trivial for 420 to 444 at half resolution.

On other cases, such as resizing 1080p to 720p (with source 420, i.e. y=1080p, u=540p, v=540p), you can have a dumb and a smarter one.

With a "stupid" resizer, it would apply the same ratio to all three planes:

y 1080*2/3 = 720p
u 540*2/3 = 360p ---> to upscaler
v 540*2/3 = 360p ---> to upscaler

leaving to you to increase in some way or another the chroma from 360p (and you have already lost some data) to 720p.

when instead a "smart one" you would apply the full resize to luma only, upscaling proportionally the chroma channels with a different coefficient, losing nothing:

y 1080*2/3 = 720p
u 540p ---> directly to upscaler
v 540p ---> directly to upscaler

There is more data in 540p than starting from 360p.

At least that is the idea behind Resize8 and what I'd like to see applied to general resizers in AVS+.

[DTL]

Core resizers do not change chroma subsampling. To downsize with conversion from 4:2:0 to 4:4:4 you can use a sequence
ConvertToYUV444() (upsize uv from 540p to 1080p - set the kernel and its params as you like more in your workflow, only UVs will be upsized)
Resize(to720p) (downsize yuv 1080p to 720p - also set kernel as you like)

And you will get chroma with better bandwidth without going to 360p.

Other possible way - separate to Y and UV and downsize Y from 1080p to 720p and upsize UVs from 540p to 720p and combine planes. Each plane will be processed only once. It may give better quality. You can compare what way make better yuv 4:4:4 720p for your content.

AVS core do not have single filter call like ResizeAndConvertTo444(). It need at least dual kernel setup params for each operation.

[tormento]

Core resizers do not change chroma subsampling.
I know and that is what I am doing already.

The question about "positioning" is not about chroma subsampling but how much to shift the planes each other not to have a mess.

I once read -0.5,0.5 pixels for half resolution but I have no idea about the value for not half resolutions.

[jpsdr]

New version, see first post, but as said in resampler thread, resamplers are not updated to the new core in this version.

[jpsdr]

New version, see first post.

[jpsdr]

Hi.
New version, see first post.

[FranceBB]

Thank you for the new build.
No issues so far with the new resizers on Windows XP Professional x86 nor Windows 10 Professional x64.
Given that XP is up to SSE4.2 I didn't expect anything to happen anyway, so the real test for the new AVX2 was on Windows 10, but the output was identical. :)


#AVX2
SetMaxCPU("AVX2")
ColorBars(1920, 1080, pixel_type="YV24")
SinPowResizeMT(1024, 576)


https://i.imgur.com/Ncv0TqG.png


#Plain C++
SetMaxCPU("none")
ColorBars(1920, 1080, pixel_type="YV24")
SinPowResizeMT(1024, 576)


https://i.imgur.com/9iJ43ll.png


Testing the results:


plain=ImageSource("A:\MEDIA\temp\New File (1)000001.png")
avx2=ImageSource("A:\MEDIA\temp\New File (1)000000.png")

Subtract(plain, avx2)


https://i.imgur.com/Wmtm8ss.png

And sure enough SSIM says 1.0 for Y, U, and V, thus confirming that they're exactly the same output. Very well done, as always. :)


plain=ImageSource("A:\MEDIA\temp\New File (1)000001.png").Converttoyv12()
avx2=ImageSource("A:\MEDIA\temp\New File (1)000000.png").Converttoyv12()

SSIM(plain, avx2, "A:\MEDIA\temp\results.csv", "A:\MEDIA\temp\globalSSIM.txt", lumimask=2, scaled=1)


https://i.imgur.com/wvjFOXE.png

[jpsdr]

There is also the script of DTL:

Loadplugin("ResampleMT.dll")


Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8)

pad=50

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

mt=LanczosResizeMT(width*2, height*2, taps=16).Subtitle("ResampleMT 2xLanczosResize taps=16", align=5)

d1 = Diff(mt,std)
d2 = Diff(mt,std)

StackHorizontal(StackVertical(std, mt), Stackvertical(d1, d2))

[StainlessS]

There is also the script of DTL:

Loadplugin("ResampleMT.dll")


Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8) # What is this ? Not on Wiki

pad=50 # Un-Used

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

mt=LanczosResizeMT(width*2, height*2, taps=16).Subtitle("ResampleMT 2xLanczosResize taps=16", align=5)

d1 = Diff(mt,std)
d2 = Diff(mt,std)

StackHorizontal(StackVertical(std, mt), Stackvertical(d1, d2))


Does "ResampleMT" re-define AddBorders() with extra args r and param1 ?
I have not been following (much) this thread, and it dont look right.

[jpsdr]

This will work both AVS & AVS+.

Function Diff(clip src1, clip src2)
{
# return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
return Subtract(src1,src2).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

#AddBorders(2, 2, 2, 2, r=2, param1=8)
AddBorders(2, 2, 2, 2)

pad=50
Subtitle("Resample test", align=5)

#std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)
std=LanczosResize(width*2, height*2, taps=16)#.Subtitle("Resample test", align=5)

#mt=LanczosResizeMT(width*2, height*2, taps=16).Subtitle("ResampleMT 2xLanczosResize taps=16", align=5)
mt=LanczosResizeMT(width*2, height*2, taps=16)#.Subtitle("Resample test", align=5)

d1 = Diff(mt,std)
d2 = Diff(mt,std)

StackHorizontal(StackVertical(std, mt), Stackvertical(d1, d2))

[tormento]

Could you please add AVX or at least SSE build to EEDI3CL-1.1.0?

As far as I can see from the dll names, they are AVX2 or AVX512 only.

Thank you!

[jpsdr]

EEDI3CL-1.1.0 is not one of my filters, so i can't do anything about it.

[StvG]

Could you please add AVX or at least SSE build to EEDI3CL-1.1.0?

As far as I can see from the dll names, they are AVX2 or AVX512 only.

Thank you!

Did you actually try them? The names are saying which one should be faster for specific CPU instructions not that they require the specific instructions.

[tormento]

EEDI3CL-1.1.0 is not one of my filters, so i can't do anything about it.

LOL, sorry. Don't know what happened to the mess we call brain.

Yesterday, I think I'd better stay in bed. :o

[jpsdr]

New version, see first post.

[FranceBB]

Thank you for the new release.
As always, it works fine on Windows XP. :)

[DTL]

r=2, param1=8) # What is this ? Not on Wiki

Wiki is slow in updates - the latest documentation is https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/addborders.html

[FranceBB]

Wiki is slow in updates

if you don't have an account and you're having issues creating one, ask Wilbert, I'm sure he's gonna help you. By the way, I've seen the updates about the new resizers and I will add them to the wiki, eventually. I just need to find the time.