madVR - high quality video renderer (GPU assisted)

[iSunrise]

Originally Posted by 6233638

What I find is that you might see no difference in chroma algorithms (assuming they are sufficiently sharp) but every so often a scene appears where the difference is clearly visible. Most of the time, Bicubic 75 AR is going to look almost the same as Jinc 3 AR or NNEDI3. But every so often you're going to find an image where there is obviously aliasing caused by using Bicubic rather than Jinc or NNEDI3.

I want the image to look its best all the time, not just most of the time.

Indeed, I also choose the settings that are giving me the most consistent results. That´s why in the past I went with Bicubic75, too, because it´s just amazingly cheap for what you get out of it. However, like you say, that comes with it´s own problems, like potentially too much aliasing or ringing, which may already be there in the source and which will get even more amplified by it´s relatively high sharpness. With the additional AR introduced, it completely changed the game, though, the negatives suddenly rarely mattered. Because without AR, I found it specifically distracting on content that needs deinterlacing or was deinterlaced wrong. SoftCubic worked much better in these (rare) cases.

With NNEDI3 though, this consistent behaviour has gotten a lot easier to achieve, because it actually is also perfectly applicable to game recordings for instance, not just for movies or other clips. And if the HQ dithering (whatever or however it may be implemented in the end) doesn´t leave behind strange artifacts, everyone should immediately benefit, because there´s a lot of different setups and content out there that will always show flaws more than others. It doesn´t even have to get into the completely insane territory, but a balanced and broad approach that improves upon what we already have, without much additional performance loss or other limiting side effects.

@madshi:
I got word back from Blaire about the reported OpenCL issue(s) >327.23, NV has actually reproduced it now, but they didn´t get into specifics of when a fix is going to happen. Not sure if that still matters though or what you´ve decided once you also have NNEDI3 running well in DirectCompute. But at least they know about the bug now.

Originally Posted by kgp700

madVR v0.87.4

* workaround added: NNEDI3 upscaling failed/froze with newer NVidia GPUs
* fixed: NNEDI3 chroma upscaling produced wrong colors with 10bit sources
* got rid of some unnecessary texture sharing

I'm using GTX660 with 334.67 driver (windows 8.1)
and using potplayer, mpc-hc + madVR v0.87.4

but still have driver crash when using scaling algorithms - image doubling - NNEDI3 options
also have wrong colors issue (all green) when using scaling algorithms - chroma upscaling -NNEDI3

tested with 720p x264 video (not 10bit, it just commonness x264 video)

please solve this issues

when "enable automatic fullscreen exclusive mode" , driver don't crash and no color issue but too much frame drop and tearing

Have many advantages when use NNEDI3 upscaling?
for example 720p little more similar as 1080p?


p.s. tooooooo difficult random questions when write on this forum ... that's so subjective ...
please change random questions

The latest drivers have broken OpenCL. The last driver set that has functioning OpenCL is 327.23. nVidia most likely reproduced the error and will include a fix in future drivers.

[Shiandow]

Originally Posted by bacondither

This is a contrast enhanced and zoomed image of the error diffusion algorithm:

[...]

You want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness in the thresholds as suggested by Cris Luengo.

And random dithering if someone want to compare.

Could someone do a similar test but with some random coloured pixels thrown in? This might cause coloured patterns to show up instead of gray ones, I'm interested to see if this would be more noticeable.

I also don't quite understand why these lines appear, I've tested the standard Flloyd-Steinberg error diffusion which didn't cause these patterns, from what I understand Madshi uses a method which should be superior not worse.

Edit: Apparently it can also happen using the Flloyd-Steinberg algorithm, but it might be possible to prevent it from happening.

[Ver Greeneyes]

Originally Posted by James Freeman

Tell me if you see any worm pattern.

Not to beat a dead horse, but.. Yes I can, on level 18. It's too small to see on my 24" monitor unless I get about twice as close to it as I usually do, and I probably wouldn't notice it if the image wasn't static, but I can imagine it being visible on a big-ass TV with a high contrast ratio where the pixels are much bigger

[6233638]

Originally Posted by NicolasRobidoux

AR changes the game.

Well, it removes the obvious effects of ringing, but not all of them.

Using an old example, comparing Lanczos 3 AR with Lanczos 8 AR:


You can see that the right of the red circle is still affected, even though the obvious signs of ringing disappear.

[madshi]

Originally Posted by turbojet

zhoufang from cris' blog looks much better than ed+random fix. It's apparently just as fast too.

No, it's not as fast.

Originally Posted by The 8472

Since this should only affect the least significant bits in the output colors maybe simply using a different rounding mode when converting high precision RGB to 6/7/8bit RGB would be sufficient. Depending on what you're using right now round to even or stochastic rounding might be sufficient.

I'm not familiar with "round to even" or "stochastic rounding". Can you clarify what that means?

Originally Posted by kgp700

madVR v0.87.4

* workaround added: NNEDI3 upscaling failed/froze with newer NVidia GPUs
* fixed: NNEDI3 chroma upscaling produced wrong colors with 10bit sources
* got rid of some unnecessary texture sharing

I'm using GTX660 with 334.67 driver (windows 8.1)
and using potplayer, mpc-hc + madVR v0.87.4

but still have driver crash when using scaling algorithms - image doubling - NNEDI3 options
also have wrong colors issue (all green) when using scaling algorithms - chroma upscaling -NNEDI3

It's nice that you read the v0.87.4 announcement post. It would have been even nicer if you had read the *whole post* and not just a part of it...

Originally Posted by bacondither

Maby this will help?
The MWC64X Random Number Generator

Thanks, might help, will have to test.

Originally Posted by turbojet

zhoufang without random noise might be interesting. It's supposed to workarond difficult greys.

Please note that all the discussion on Cris' blog is about 8bit -> 1bit error diffusion. Some of the optimizations are especially targetted at exactly this operation. madVR is doing 16bit+ -> 8bit error diffusion, which in concept is similar, but not all of the "tricks" suggested on Cris' blog work for what madVR does.

Originally Posted by iSunrise

I got word back from Blaire about the reported OpenCL issue(s) >327.23, NV has actually reproduced it now, but they didn´t get into specifics of when a fix is going to happen. Not sure if that still matters though or what you´ve decided once you also have NNEDI3 running well in DirectCompute. But at least they know about the bug now.

Great - thanks! I think I'll switch completely to DirectCompute, so the bug fix is probably not important for me, anymore. But it's not decided yet.

Originally Posted by NicolasRobidoux

Mathias: Now I think that I remember better:

Deblurring Jinc5 with a different recipe than the one used for "your" Jinc3 gives a scheme which actually is very different: It really "de-aliases" "pixel art" diagonal lines in a way that no reasonable Jinc3 can. (I do not remember if Jinc4 at about the same deblur gave close results to Jinc5. I do remember, making a note to myself that EWA Lanczoses seem to work better with odd numbers of lobes.)

Would you like me to dig this out/experiment or should I leave you alone in your NNEDI bliss?

I would like to see what your modified Jinc5 can do. This test image might be a good candidate for pixel art:

http://madshi.net/SNES.png

Here are comparisons between NNEDI3 vs. Jinc3AR, and between Jinc3AR vs. Jinc3:

http://screenshotcomparison.com/comparison/59698
http://screenshotcomparison.com/comparison/59702

[*Touche*]

Originally Posted by cyberbeing

I use a customized lower than low deband preset for high quality content.

avgDIF 0.3, maxDIF 1.3, midDIF 0.6, angleBoost 2.0, maxAngle 0.08 + analyze gradient angles

Just barely strong enough to smooth out minor imperfections in detected gradients, while not harming detail. That said, this was tuned specially for the minimum visible improvement on my calibrated GDM-F520 CRT along with NNEDI3 luma doubling and chroma upsampling. If you have a display which cannot render perfectly smooth gradients, cannot show 1-step differences in any of the RGB channels distinctly, or are not using NNEDI3, you may need to go a bit stronger then this to have a positive effect. Just keep in mind that the madVR's default Low preset is already very borderline in terms of detail preservation, so that should be your upper limit for high quality content.

I'm using a 55" Panasonic ST60. I think it would benefit from a touch stronger settings, like default low, if I remember plasmas issues correctly.

[toniash]

Originally Posted by madshi

Here are comparisons between NNEDI3 vs. Jinc3AR, and between Jinc3AR vs. Jinc3:

http://screenshotcomparison.com/comparison/59698
http://screenshotcomparison.com/comparison/59702

impressive!

[DragonQ]

That NNEDI3 looks pretty tasty for emulators.

[pie1394]

I have mentioned debanding_with_angle_detection + NNEDI3 chroma 2x even improves the Sony XCA7 super-resolution engine's performance for 1920x1080 4:2:0 contents. Comparing with Jinc3AR, it increases the perceptual resolution and stability on patterned object shapes under moving scenes -- in either interlaced or progressive format.

[The 8472]

Originally Posted by madshi

I'm not familiar with "round to even" or "stochastic rounding". Can you clarify what that means?

round to even means on 0.5 it chooses to even integer value. 0.5 -> 0, 1.5 -> 2, 2.5 -> 2. 3.5 -> 4, 4.5 -> 4, etc.
stochastic rounding picks at random whether to round up or down on 0.5.

The differences are relevant to error propagation, always rounding up on 0.5 introduces some bias.

But rounding may not be the right thing to do at all if you're using integer RGB -> RGB since only the range [0.0,0.5] would result in black while (0.5,1.5) would result in 1, i.e. full black and full white would get squeezed into a smaller interval. It's probably more appropriate to use if you come from a larger color space and have to clamp anyway.

I only brought it up because I was thinking that if you want to introduce randomness in the dither then it should be no more significant than the quantization error, so if it could be incorporated in the quantization step it would probably be the best.

Another issue with grey-grey gradients is that if we add noise separately to the RGB channels it will end up propagating to different pixels, basically introducing colored noise when there shouldn't be any.

Of course it's very unlikely that real content will have perfectly monochrome gradients with zero deviation between the RGB channels.

[6233638]

Originally Posted by cyberbeing

Your Jinc3 images are bugged. This is what Jinc3AR actually looks like...

This is actually a bit concerning. I thought it was just a fluke, but I actually experienced this exact same "madVR blurry bug" yesterday when I was testing various settings on a paused video and taking screenshots.

You're confusing Jinc with NNEDI. The images are correct - Jinc 3 has a tendency to blur together images like that. (which is actually beneficial for games, as that's simply dithered because they had a limited palette to work with)

For example, Pitfall via an RGB connection:


Pitfall via a Composite connection:


Source: http://www.neogaf.com/forum/showpost...1&postcount=77

[huhn]

pixel art can be a real problem for needi3:

image 1 source

jinc3ar
spline3ar
neeid3x4spline3ar

huge artifacts in the bottom left and a lot of small ones with needi3, jinc is known to have problems with this as you can see

image 2 source

jinc3ar
spline3ar
needi3x4spline3ar

with needi3 the face in the bottom left looks really good but there a artifacts in the fonts again.

64 neurons are used for all screens
the mice position can be of by 1 frame in this lossless rgb video i get a black screen when i use neeidi3 with my hd4000 for 1 frame i'm sorry

[6233638]

I think the goals for scaling up pixel art are very different from scaling up video, or even animation.
Pixel art was very useful for showing issues with the anti-ringing filter, but I don't know that it's useful for judging the quality of scaling algorithms.

[cyberbeing]

Originally Posted by 6233638

You're confusing Jinc with NNEDI.

Oops, I missed a setting (too many profiles...). Deleted that post.

I did experience a blurry bug yesterday though... Probably was just a fluke with PrtScn, so I won't worry about it.

[Ver Greeneyes]

Originally Posted by The 8472

round to even means on 0.5 it chooses to even integer value. 0.5 -> 0, 1.5 -> 2, 2.5 -> 2. 3.5 -> 4, 4.5 -> 4, etc.

I think this is usually called "round to nearest, ties to even" or "round to nearest, half to even". It's the default rounding method for IEEE 754 floating point.

[kasper93]

Are we using madVR to play games or watch movies? C'mon guys... For such content I personally prefer Nearest Neighbour, I don't mind having pixels on screen and blurring them is not for me.

[The 8472]

Originally Posted by kasper93

Are we using madVR to play games or watch movies? C'mon guys... For such content I personally prefer Nearest Neighbour, I don't mind having pixels on screen and blurring them is not for me.

There are specialized pixel art upscaling algorithms, NN is not the best choice there. But it certainly isn't madVRs focus, so NNEDI does a decent job there for something it isn't optimized for.

[Shiandow]

Originally Posted by The 8472

Another issue with grey-grey gradients is that if we add noise separately to the RGB channels it will end up propagating to different pixels, basically introducing colored noise when there shouldn't be any.

Of course it's very unlikely that real content will have perfectly monochrome gradients with zero deviation between the RGB channels.

The issue with coloured noise probably already occurs when the image contains some coloured pixels before the gray-gray gradient. In that case the error-diffusion algorithm will no longer output exactly the same values for the different RGB channels.

The reason this doesn't occur on grayscale images is that the algorithm is deterministic and in a grayscale image all RGB channels are exactly the same, therefore it will simply give the same output for all channels. But this effect is more of an coincidence than a feature of the algorithm and is extremely unstable; if anywhere in the picture there is a rounding error which causes the RGB channel error to be different then you will get coloured patterns instead of gray ones.

You can prevent this from happening by performing the calculations in YCbCr space, but this is rather expensive. If you want to see some (exaggerated) examples then see my previous post.

By the way I've also been able to figure out why the line like patterns happen. This happens whenever a value is 1/3 of the way between the two possible ways to round this value. For example in the 1bit black-white case using error diffusion on a background which is 1/3 white will result in white lines on a black background, which if you think about it is actually 'optimal' since any 3x3 block contains 3 white pixels and 6 black pixels which averages to 1/3 white. I'm not entirely sure if I even agree with the people who claim that this looks worse, I've compared this to a randomized versions of error diffusion and I prefer the normal error diffusion.

Here are the results of the versions I tried:

normal error diffusion:


Version where the error is diffused in 3 different ways, picked randomly:


Version with small amount of noise, error diffused in YCbCr:


Version with small amount of noise, error diffused in RGB:


Note that using error diffusion with noise in RGB adds coloured noise.

[iSunrise]

Originally Posted by madshi

I would like to see what your modified Jinc5 can do. This test image might be a good candidate for pixel art:

http://madshi.net/SNES.png

Here are comparisons between NNEDI3 vs. Jinc3AR, and between Jinc3AR vs. Jinc3:

http://screenshotcomparison.com/comparison/59698
http://screenshotcomparison.com/comparison/59702

This is a great example to test pixel art indeed.

While NNEDI3 4x paired together with Spline or some other Bicubic resizer already does a good job, I can easily see some additional ringing artifacts introduced.

Now I wonder, would it be possible to improve that even more with NNEDI 4x + your AR algorithm, because the AR applied with the additional luma resizer is already too late in the chain to correct it.

I´ve marked some spots in question with red circles and arrows.