Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th November 2013, 07:32   #1  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
Jinc Resizer - Avisynth Plugin [v0.1.1]

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.

IMPORTANT: Downscaling isn't currently implemented.

Changelog
Code:
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

Last edited by innocenat; 27th July 2014 at 16:46. Reason: v0.2
innocenat is offline   Reply With Quote
Old 26th November 2013, 07:51   #2  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,235
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.

Last edited by burfadel; 26th November 2013 at 07:53.
burfadel is offline   Reply With Quote
Old 26th November 2013, 09:01   #3  |  Link
PetitDragon
Registered User
 
Join Date: Sep 2006
Posts: 80
OMG! This is just f*cking great!
PetitDragon is offline   Reply With Quote
Old 26th November 2013, 10:53   #4  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
v0.1.1 released, with more optimization that should runs at least two times faster.
innocenat is offline   Reply With Quote
Old 26th November 2013, 11:28   #5  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,380
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?
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 26th November 2013, 11:37   #6  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
Quote:
Originally Posted by Gavino View Post
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.

Quote:
Originally Posted by Gavino View Post
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.
innocenat is offline   Reply With Quote
Old 26th November 2013, 11:42   #7  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,567
After putting it into plugins directory, I'm getting this, even if JincResizer is not used:

Quote:
The program can't start because libmmd.dll is missing from your computer. Try reinstalling the program to fix this problem.
Keiyakusha is offline   Reply With Quote
Old 26th November 2013, 11:52   #8  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
Quote:
Originally Posted by Keiyakusha View Post
After putting it into plugins directory, I'm getting this, even if JincResizer is not used:
Sorry, binaries updated.
innocenat is offline   Reply With Quote
Old 26th November 2013, 12:14   #9  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,567
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 ^^

Last edited by Keiyakusha; 26th November 2013 at 12:18.
Keiyakusha is offline   Reply With Quote
Old 26th November 2013, 12:24   #10  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
Thanks for this, do you plan on implementing downsizing?
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650
PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0
turbojet is offline   Reply With Quote
Old 26th November 2013, 13:34   #11  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
@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.
innocenat is offline   Reply With Quote
Old 26th November 2013, 14:05   #12  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,567
Quote:
Originally Posted by innocenat View Post
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...
Keiyakusha is offline   Reply With Quote
Old 26th November 2013, 14:10   #13  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
Quote:
Originally Posted by Keiyakusha View Post
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.
innocenat is offline   Reply With Quote
Old 26th November 2013, 20:30   #14  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 666
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.
mandarinka is offline   Reply With Quote
Old 26th November 2013, 20:47   #15  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,070
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.
madshi is offline   Reply With Quote
Old 27th November 2013, 03:18   #16  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
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.
innocenat is offline   Reply With Quote
Old 27th November 2013, 09:57   #17  |  Link
cretindesalpes
͡҉҉ ̵̡̢̛̗̘̙̜̝̞̟̠͇̊̋̌̍̎̏̿̿
 
cretindesalpes's Avatar
 
Join Date: Feb 2009
Location: No support in PM
Posts: 610
Code:
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.
__________________
dither 1.27.2 for AviSynth | avstp 1.0.3 for AviSynth development | fmtconv r19 for Vapoursynth | trimx264opt segmented encoding

Last edited by cretindesalpes; 27th November 2013 at 12:11. Reason: Second attempt
cretindesalpes is offline   Reply With Quote
Old 27th November 2013, 10:27   #18  |  Link
innocenat
Registered User
 
innocenat's Avatar
 
Join Date: Dec 2011
Posts: 77
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.
innocenat is offline   Reply With Quote
Old 27th November 2013, 10:44   #19  |  Link
Nevilne
Registered User
 
Join Date: Aug 2010
Posts: 134
Anti-ringing filter:

Code:
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)
  
}
Nevilne is offline   Reply With Quote
Old 27th November 2013, 11:17   #20  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,380
Quote:
Originally Posted by Nevilne View Post
Code:
  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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.