View Single Post
Old 16th December 2014, 09:28   #72  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Orf View Post
But this NEDI/NNEDI is really confusing me. To summarize what I've learned from your:
- NNEDI3 is the most heavy algorithm, but it gives the best result in the end
- NEDI implemented here for example is less heavy, so PS use is acceptable
- madVR internally should have at least two image processing conveyers. #1 is PS conveyer, #2 is OpenCL conveyer. Also it possible have DirectCompute conveyer as #3
- IMadVRExternalPixelShaders supports only #1 (?)
- To make general and flexible image processing support all three conveyers have to be implemented
- Which one of the three is better is kind of an open question. Also picking and implementing only one of them will require rewriting of hlsl/cl code (thing I very unlikely can do myself)
Seems all correct to me.

Although the names suggest otherwise, NNEDI3 and NEDI are *totally* different algorithms, which have almost nothing in common (except for doing an exact 2x upscale). IMO NNEDI3 has better image quality, but it's also quite a bit slower than NEDI. And yes, NEDI works fine with simple PS3.0 pixel shaders, while NNEDI3 requires OpenCL to run at a decent speed.

FYI, Shiandow has written a super-res post-processing algorithm (using simple pixel shaders, once again) which improves NEDI quality even further, bringing it even nearer to NNEDI3 quality. This super-res algorithm is currently available for NEDI, only, I think, but it could in theory also be used to improve other 2x upscale algorithms, e.g. NNEDI3, or even Bicubic/Lanczos. I'm not sure if this super-res algorithm would improve NNEDI3 quality, too, we haven't tried yet, I think. But it might. I'm hoping that the super-res algorithm will sooner or later be a separate filter, running after any other 2x upscaling algorithm.
madshi is offline   Reply With Quote