JPSDR Avisynth's plugins pack

[jpsdr]

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

[jpsdr]

Originally Posted by 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)
...

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]

Originally Posted by 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.

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

[DTL]

Originally Posted by tormento

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]

Originally Posted by 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.

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]

Originally Posted by DTL

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 thread.

[DTL]

Originally Posted by tormento

The discussion is part of the Resize8 thread.

You may try latest testbuild with different chroma placement options and make report if it solve that issues: https://github.com/AviSynth/AviSynth...ent-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]

Originally Posted by DTL

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.

[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]

Originally Posted by DTL

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]

Originally Posted by DTL

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.