Log in

View Full Version : non-ringing Lanczos scaling


Pages : 1 2 [3]

NeuralSpline
10th June 2012, 07:21
The choice of optimum parameters it always a compromise between value judgment and accuracy and result of such choice is badly predictable, and hardware realization is impossible. Such decision for fans to adjustments whom it is not enough. On it I consider that the good algorithm should do all adjustments itself, and accuracy should be a priority.

I have a question on NNEDI4. For me very much pleased result of work of this algorithm on a clown picture in that place where were good separated red and blue a lines on ambulance car and a power line. I consider it as very good result. What the method was realized? What technical solution was applied? As to process such long objects very difficult. It would be desirable and hear opinions about.

Thank.

Terka
29th August 2012, 15:23
Hi Tritical, when are you planing to put nnedi4 plugin to your website for public testing?

Terka
27th February 2013, 09:43
Does anyone know what is with Tritical?

markanini
31st July 2013, 11:25
Anyone seen Nicolas sigmoidized lanczos? http://www.imagemagick.org/discourse-server/viewtopic.php?&t=21660

madshi
31st July 2013, 11:30
Yes, I've tried it myself. It improves the image quality for some images, but makes it worse for others. So I've decided not to use it.

markanini
31st July 2013, 11:37
How about using it for deinterlacing or AA in place of NNEDI3?

madshi
31st July 2013, 22:20
?? Not sure what you mean. As I said, according to my tests it sometimes helps and sometimes hurts, so my personal stance is that I won't use sigmoidization.

markanini
1st August 2013, 13:34
Just throwing it out there, I played with sigmoidized EWA upsampling in Imagemagick and the results remind me of NNEDI3 (especially the QuadraticJinc variant)so maybe it could be useful for fast processing in Avisynth(requires a 16-bit operatetion though).
Do you have an example of where sigmoidization fails badly?

madshi
1st August 2013, 13:53
IIRC the usual lighthouse scaling test image shows problems. The one which has a lot of ringing around the top circle.

markanini
2nd August 2013, 06:08
Ok, I see it now. Seems like if the original has any aliasing or haloing the gap between NNEDI3 and sigmoidized EWA really jumps at you.

madshi
2nd August 2013, 08:21
Yes, and haloing/ringing is unfortunately very common with video sources.

markanini
2nd August 2013, 20:35
Yes, and haloing/ringing is unfortunately very common with video sources.

Yeah. I think the the resemblence between EWA to NNEDI is limited to how it handles mosquito noise.

madshi
2nd August 2013, 22:36
Well, FWIW, EWA Lanczos (non-sigmoidized), or as madVR calls it, "Jinc", does look better to my eyes than the simple Lanczos/whatever. So it might still make sense to write an AviSynth plugin for that. I like EWA Lanczos / Jinc quite a lot. Just not the "sigmoidize" part.

turbojet
2nd August 2013, 23:37
Could EWA be optimized for downscaling? Probably a lot more common then upscaling in avisynth but would be nice in madvr as well.

madshi
3rd August 2013, 07:07
The algorithm itself supports downscaling just fine.

turbojet
3rd August 2013, 22:52
Why isn't it available for downscaling in madvr?

madshi
4th August 2013, 14:09
Because I didn't implement it yet, but that's OT here...

Undead Sega
17th July 2014, 06:00
I just want to say that I think this non-ringing Lanczos filter is absolutely great!

Why hasn't this been used more often? Has it been implemented?? How does one use it???

madshi
17th July 2014, 06:51
A modified version of this filter has been implemented in madVR, for all scaling algorithms. FWIW, I believe NNEDI3 easily beats this in terms of quality, but NNEDI3 is rather slow. If you need a fast performing algorithm, Lanczos with anti-ringing is a good alternative. To my best knowledge there's no software other then madVR which has implemented this so far.

Undead Sega
9th August 2014, 05:00
Why hasn't this been implemented in AviSynth???

And I keep hearing about madVR. What is it exactly?

madshi
9th August 2014, 07:48
AviSynth is an open source project, so this was not implemented in AviSynth yet because no developer had the time and/or interest to implement it (yet?). So what could you do to have it implemented in AviSynth? You could do it yourself, or you could try to motivate a developer to do it somehow, e.g. by offering some monetary incentive or so. Personally, I'm not an AviSynth developer, I just wanted to share the algorithm idea, that's why I started this thread.

madVR is a DirectShow video renderer for real time video playback (*not* reencoding). For madVR you need Windows XP or newer, a 32bit media player which supports it (e.g. MPC-HC/BE, ZoomPlayer, PotPlayer, ...) and a budget DX9 GPU. If you're interested in encoding, madVR is not for you (at least not at this point in time).

mzso
9th August 2014, 12:21
Why hasn't this been implemented in AviSynth???

And I keep hearing about madVR. What is it exactly?

Because you didn't implement it.

MadVR (http://forum.doom9.org/showthread.php?t=146228) is a video renderer.

raffriff42
9th August 2014, 18:17
Why hasn't this been implemented in AviSynth???Try Didée's script on the first page of this thread - it may appear simple, but to my eye, it achieves a good balance of sharpness and accuracy, ie lack of overshoot. It's my favorite upscaler, along with Nnedi3, depending on the source material.
LanczosResize(dest_x,dest_y).Repair(Gaussresize(dest_x,dest_y,p=100),1)

Kein
8th March 2015, 20:51
^
any idea which version of what plugin he had in mind for that example. There are (http://avisynth.nl/index.php/RemoveGrain) quite a few. (http://avisynth.nl/index.php/RgTools)

raffriff42
8th March 2015, 22:52
I was using the version of RepairSSE2.dll (July 2005) that ships with QTGMC (http://avisynth.nl/index.php/QTGMC) - I wasn't even aware of the RgTools (http://avisynth.nl/index.php/RgTools) modern rewrite. I substituted RgTools.dll version 0.92.1 -x86, and there were no compatibility issues.

Reel.Deel
8th March 2015, 23:48
RgTools should be fully backward compatible with the original RemoveGrain, Repair, and VerticalCleaner. The only incompatibilities come from the Clense family (Clense, Backward/ForwardClense), due to some parameters removed/added, more info in the actual filter pages. As suggested here (http://forum.doom9.org/showpost.php?p=1684012&postcount=25&highlight=clense), RgTools' Clense() should be the same as Clense(reduceflicker=false), not sure what the equivalent for Clense(reduceflicker=true) would be.

Kein
9th March 2015, 12:22
By compatibility I was mostly talking about the possible result errors.