Jinc Resizer - Avisynth Plugin [v0.1.1]

[innocenat]

So I know a lot of people (including me) want the new Jinc resizer from madVR in Avisynth. So after some research and some help from madshi, here I present the Jinc Resizer

This plugin require Avisynth 2.6.

• Download
• GitHub repo

IMPORTANT: Downscaling isn't currently implemented.

Changelog

v0.2
 - Core rewritten to use quantized lookup table for coefficient
 - Support SSE2, SSE3, AVX2 and FMA3.
 - Basically, MUCH faster.

v0.1.1
 - Binary now compile with ICC14
 - More optimized code, should rune much faster.
 - Thanks to tp7 and others for optimization tip.

v0.1
 - Initial release

Documentation
The plugin currently exposes 3 functions:

• Jinc36Resize(clip, int width, int height)
• Jinc64Resize(clip, int width, int height)
• Jinc144Resize(clip, int width, int height)
• Jinc256Resize(clip, int width, int height)

Crop-style syntax like in internal resizers also works. You can control sub-pixel quantization option by quant_x and quant_y parameter, default is 256.

Note

It should be fast enough for encoding now, especially if you have Haswell CPU or newer. Though the quality without anti-ringing filter is debatable.

Roadmap

• Add anti-riging filter
• Possibly add OpenCL version

[burfadel]

Looks interesting Will be looking forward to when the stuff in the roadmap is completed.

If making an OpenCL version, it would probably be worth adding related things like sharpen and deband of some description. I know Madshi is currently implementing debanding in MadVR. I suggest this because a small amount of sharpening and debanding can be a good thing when resizing, and might as well get that done on the graphics side of things.

[PetitDragon]

OMG! This is just f*cking great!

[innocenat]

v0.1.1 released, with more optimization that should runs at least two times faster.

[Gavino]

Thanks for this, innocenat - a useful addition.

I notice that only planar YUV clips are currently supported.
Will support for YUY2 and RGB be included eventually?

Also worth noting it is a 2.60 plugin only.
Any reason why it couldn't be made to work on 2.58 too?

[innocenat]

Originally Posted by Gavino

I notice that only planar YUV clips are currently supported.
Will support for YUY2 and RGB be included eventually?

I don't think I will add support for YUY2 and RGB data soon. The problem is that interleaved format is hard to load quickly in SIMD. And the filter is already slow as it is.

Originally Posted by Gavino

Also worth noting it is a 2.60 plugin only.
Any reason why it couldn't be made to work on 2.58 too?

First, a lot of things I use differ from 2.5 header and 2.6 header, such as accepting floating point parameter, get subsampling detail etc. Not that it couldn't be done, but unless there are actually people who want it, I don't think it's worth the effort. Also, there might be AVX optimization in future, and you'd require Avs+ or post-a5 Avisynth 2.6 anyway.

Second, I think most users of Jinc Resizers will be hardcore user and will probably be using 2.6 already anyway.

[Keiyakusha]

After putting it into plugins directory, I'm getting this, even if JincResizer is not used:

The program can't start because libmmd.dll is missing from your computer. Try reinstalling the program to fix this problem.

[innocenat]

Originally Posted by Keiyakusha

After putting it into plugins directory, I'm getting this, even if JincResizer is not used:

Sorry, binaries updated.

[Keiyakusha]

Well, for me on core i7, when doing 720x480 -> 1920x1080, Jinc36 is 2-3 times (depending on content complexity due to prescreener) slower than icl-compiled nnedi3 with fturn (4x upscale + bicubic downscale) and the visual quality is obviously worse.
Edit: nnedi was set to use only 1 thread. I hope I'm not sleeping again, cause as of late I'm getting weird results when trying new avisynth resamplers ^^

[turbojet]

Thanks for this, do you plan on implementing downsizing?

[innocenat]

@turbojet

Downscaling will be added later, that's for sure.

@Keiyakusha

Yes, nnedi3_rpow2 should be much better choices right now. Maybe until I implement an AR filter and add a prescreener and/or OpenCL version.

[Keiyakusha]

Originally Posted by innocenat

Yes, nnedi3_rpow2 should be much better choices right now. Maybe until I implement an AR filter and add a prescreener and/or OpenCL version.

Mmm... but if this is exactly the same stuff as in madvr, it won't be able to beat nnedi quality-wise even with AR. It simply doesn't connects lines as good. And judging from the feedback in madvr thread, Jinc downscale sux and sticking to something like spline36 is a better idea. Also now that we have OpenCL nnedi3, do you think Jinc is still will be competitive? So far Jinc performs exactly as I was afraid of...

[innocenat]

Originally Posted by Keiyakusha

Mmm... but if this is exactly the same stuff as in madvr, it won't be able to beat nnedi quality-wise even with AR. It simply doesn't connects lines as good. And judging from the feedback in madvr thread, Jinc downscale sux and sticking to something like spline36 is a better idea. Also now that we have OpenCL nnedi3, do you think Jinc is still will be competitive? So far Jinc performs exactly as I was afraid of...

It's nice to have options, after all.

Personally, I don't care if people will use it over nnedi3ocl; coding this is fun, and help me learn a lot of thing.

[mandarinka]

Oh, this could be very interesting.

Correct me if I am wrong, but this really shouldn't be that much slow, no? Since it is still just a resampler, not a complex interpolator like nnedi variants and other EDI methods, I would expect it to be faster.

[madshi]

Jinc has to be slower than other linear resamplers because due to how it works (can't be split into 2 separate passes) it has to read and process more source pixels. E.g. compared to Lanczos3, Jinc3 has to read and process 4x as many source pixels.

One thing to keep in mind is that NNEDI3 can only do exact 2x enlargements while Jinc can handle any up- and downscale factor you want.

[innocenat]

In addition to what madshi said, other traditional resampler can also be normalize to integer operation and has their coefficients cached prior to actual resampling.

Jinc and other 2d resampler unfortunately can't, and has to calculate everything in floating point without any coefficients cache.

[cretindesalpes]

BlankClip (width=640, height=480, pixel_type="YV12")
ShowFrameNumber ()
Jinc64Resize (1920, 1080)

The result is often corrupted:

Sometimes it works, but there is no obvious pattern.

I quickly hacked a version with precalculated coefficients, compiled with MSVC 2012. It’s faster but very memory hungry (don’t even think about Jinc256 on a HD frame). Enable the precalculation with table=true. However the memory usage can be easily reduced when the scale is a rational fraction or by accepting a small phase error (sub-pixel shift), which would allow using a same set of coefficients for different locations.

EDIT: Second attempt with position quantization (1/256). Much more memory-friendly and faster. Use pquant=true to enable the quantization.

[innocenat]

Yes, a Jinc36Resize on 1920x1080 frame would produce roughly 490MB worth (49 coeff * 4 bytes (float) * 1920x1080 pixel). That's why I don't even think about doing that. I guess I could add option for that. The precalculated coeff version could be simplify further by using integer operation instead of floating point (accepting a small rounding error).

Regarding the error, I guess it's because some reckless assumption I made concerning memory layout. Will have to investigate further.

[Nevilne]

Anti-ringing filter:

Function nrJinc36Resize(clip input, int "target_width", int "target_height", float "src_left", float "src_top", float "src_width", float "src_height"){
  
  Assert( input.IsPlanar(), "nrJinc36Resize: only planar color spaces are supported!" )
  
  target_width  = Default( target_width,   width(input) )
  target_height = Default( target_height, height(input) )
  src_left      = Default( src_left,                  0 )
  src_top       = Default( src_top,                   0 )
  src_width     = Default( src_width,                 0 )
  src_height    = Default( src_height,                0 )
  
  return input.Jinc36Resize(target_width, target_height, src_left, src_top, src_width, src_height)
  \           .Repair(input.GaussResize(target_width, target_height, src_left, src_top, src_width, src_height, p=100), 1)
  
}

[Gavino]

Originally Posted by Nevilne

  src_width     = Default( src_width,                 0 )
  src_height    = Default( src_height,                0 )

The built-in defaults for src_width and src_height are not zero, they are respectively width(input) and height(input). In the case where src_left or src_top is non-zero, this gives a different result.

If you want your function to have the same defaults as the actual resizers, the simplest way is just to pass on the function parameters src_left, src_top, src_width and src_height unchanged. That way, you don't even need to know what the actual default is.