madVR - high quality video renderer (GPU assisted)

[huhn]

Hi guys..

In the Ati- video - advance color setting..

Are we suppose to set it to 16-235 or 0-255 for best madvr playback..

this is ignored by madvr.

dxva scaling/deint can be affacted

[tp4tissue]

this is ignored by madvr.

dxva scaling/deint can be affacted

Awesome Thxxxx:goodpost:


so.... for dxva... on my slower single core computers.. Which one do I use

[DragonQ]

But why explicitly disabling it then? It won't be used when not needed and when needed it's very nice improvement.
Why explicitly enable it if it's never needed?

[Stereodude]

so.... for dxva... on my slower single core computers.. Which one do I useWhat do you have the computer connected to? TV, monitor? Are you using YUV 4:4:4?

[huhn]

What do you have the computer connected to? TV, monitor? Are you using YUV 4:4:4?

he is talking about the color setting for videos not for hdmi.

just set everything to "player settings"

[flashmozzg]

I like DC3 version more. DC4 has higer noise wich is for me more distracting than this patterns.

[The 8472]

I was finally able to confirm that using error-diffusion in an image with colour does indeed introduce coloured "noise" because of the misalignment of the different channels. The good news is that the effect isn't as bad as it could be. The bad news is that it does exists and mainly near edges which is unfortunate.

I've generated the pattern by using the Colorbars function from avisynth in the video processor of Potplayer, which for some reason resulted in an image which was horizontally flipped.

I then cropped the image and scaled the range [0-40] to [0-255] and doubled the size (nearest neighbour scaling). This gave the following result for the different algorithms:

normal dithering (http://i.imgur.com/lXGshAf.png), error diffusion build 3 (http://i.imgur.com/nt7bEvL.png), error diffusion build 4 (http://i.imgur.com/lrXQXCH.png)

You should be able to see that the pattern near the coloured surfaces is slightly coloured where it should be dark-gray. To make this more obvious here are the same three images but with the saturation increase by 100.

normal dithering (http://i.imgur.com/XS2FxmP.png), error diffusion build 3 (http://i.imgur.com/jStccuu.png), error diffusion build 4 (http://i.imgur.com/FnfEbVC.png)

Luckily the added noise from build 4 doesn't seem to add more coloured noise than the previous algorithm. It is also fairly hard to detect without special methods, but it might be worth it to see if it is at all possible to do the dithering in YCbCr which, at least in my experiments, should prevent this from happening. This likely won't be free though, although I think it is possible to do it with one 7x3,3x1 matrix multiplication and several if statements.

Edit: I seemed to have accidentally used bicubic scaling on the error diffusion build 4 image, this might explain why the "coloured noise" looks slightly different.

Since the errors seem to extend in both directions could this actually be the ringing artifacts extending further into the neighboring areas, albeit in the less-significant bits of the high precision color spaces? Either that or madshi is using serpentine traversal.
The fact that the error only extends upwards by ~2 pixels seems to indicate that it's the latter case.

Still interesting that the error consistently only spreads 16-20 pixels in one direction. I guess that even high with 16bit math the rounding lets the error fall below the LSB relatively quickly.

Assuming/speculating the "use 10bit image buffer instead of 16bit" setting also affects dithering then using 10bits might actually taper off faster if my theory is right.


Ok, thanks. I thought that a quick and dirty way would be sufficient, but I gave it another shot with GIMP, because Irfanview was definitely not able to do change levels/curves like that.

DirectCompute3 ED vs. DirectCompute4 ED vs. Random Dither

http://abload.de/thumb/directcompute3_enhancmgki4.png (http://abload.de/image.php?img=directcompute3_enhancmgki4.png)http://abload.de/thumb/directcompute4_enhancqqj3y.png (http://abload.de/image.php?img=directcompute4_enhancqqj3y.png)http://abload.de/thumb/random_dither_enhance7hjqd.png (http://abload.de/image.php?img=random_dither_enhance7hjqd.png)

In/out ranges are [0-11 -> 0-255]

I´ve also marked each 3 with red boxes at the bottom, too, because I´ve found something strange. Now, please don´t mind the movement of the boxes themselves, because I am not entirely sure how to add a stable second layer with GIMP so they don´t move (I had to do it manually), but what I wanted to illustrate is the movement of the right edge to the left of bar 20 and the movement to the left of the white line in bar 18 inside of the boxes. Because strangely, this does only happen with DirectCompute4 ED+random noise and not with DirectCompute3 ED or the Random Dithering. You probably need to put them in a slideshow (like Irfanview can do) to see it clearly.

Version 3 - at least this particular test-case with the applied enhancements - does look more appealing to me. The solid areas actually look flat when you don't zoom in.


@madshi

Which algorithm do you use to add noise in version 4? The one that Shiandow proposed might yield better results. He suggested simply using a handful of different diffusion tables and picking among them at random on each pixel. That should avoid introducing additional noise, it just spreads the errors in a way that seems less like a pattern to the human eye.

[tp4tissue]

he is talking about the color setting for videos not for hdmi.

just set everything to "player settings"

k, will do, thx:D

[Shiandow]

Assuming/speculating the "use 10bit image buffer instead of 16bit" setting also affects dithering then using 10bits might actually taper off faster if my theory is right.

I just tried that, using a 10bit buffer only changes the coloured noise a bit it doesn't seem to lessen it or change the range, actually Madshi said in a previous comment:


It's somewhat similar to Floyd-Steinberg with serpentine scanning, but I'm using different weights and 16x16 pixel blocks.


So what I suspect is that the coloured noise is confined to those 16x16 blocks, the coloured error which causes the noise doesn't travel past those blocks. This seems the only sensible way to implement error diffusion on a GPU since otherwise you'd have to scan the image pixel by pixel which would mean that using a CPU would be faster.

Also with the way error-diffusion works, changing one value, even slightly, will have an effect on all the following pixels since different rounding errors occur in different places in a very unpredictable way. Given this you'd expect that when you use error diffusion separately on the different channels then it would be extremely unlikely that the result is the same for all channels, which leads to coloured noise.

The reason this doesn't always occur is because error diffusion does exactly the same thing for the same values, this combined with the fact that error diffusion is only used on 16x16 blocks means that when the entire 16x16 block is gray, it will give exactly the same result for the same channels, which leads to an image which is gray.

[The 8472]

actually Madshi said in a previous comment:

It's somewhat similar to Floyd-Steinberg with serpentine scanning, but I'm using different weights and 16x16 pixel blocks.
Ah, I missed that part. That pretty much explains it.

[turbojet]

Thanks bacondither, zhaoyang with no random noise looks really impressive but maybe changing the 'difficult gray levels' is too obvious?

Shame it's so much slower than ED, wonder why Cris wrote it's just as fast.

[Megalith]

How intensive is OpenCL Error Diffusion? My HTPC is decently powerful (Radeon 5850), but when that option is active, my videos play back at what seems like one or two frames per second.

Also, does anyone use a Kuro for 24 Hz playback? I'm trying to figure out why going into full-screen mode in MPC-HC makes all my Blu-ray .mkv rips appear letterboxed when my HTPC is set for 24 Hz output. It doesn't happen when I'm running the panel at 60 Hz or when I'm playing back an .mkv in a window on the desktop.

[pie1394]

How intensive is OpenCL Error Diffusion? My HTPC is decently powerful (Radeon 5850), but when that option is active, my videos play back at what seems like one or two frames per second.

Also, does anyone use a Kuro for 24 Hz playback? I'm trying to figure out why going into full-screen mode in MPC-HC makes all my Blu-ray .mkv rips appear letterboxed when my HTPC is set for 24 Hz output. It doesn't happen when I'm running the panel at 60 Hz or when I'm playing back an .mkv in a window on the desktop.

Well ... there might be something wrong in your setup if it just renders 1 ~ 2 frames per second with your HTPC..

With HD7970 GPU, it requires about additional 10ms to process one 1920x1080 video frame via OpenCL-path ED on madVR 0.74. The Chroma 960x540 NNEDI3 32 neurons 2x scaling takes about 15ms via the same path on this GPU.

How about the TV side's AR setting? Does the madVR statistics (Ctrl-J) show different thing with both 24/60Hz output mode? The top-end TV often provides individual settings on different input, and even resolution /refresh rates.

[Mangix]

How intensive is OpenCL Error Diffusion? My HTPC is decently powerful (Radeon 5850), but when that option is active, my videos play back at what seems like one or two frames per second.

The error diffusion setting is very resource intensive. Leaving it off is recommended as other settings have a more important effect on video quality.

Also, madshi has implemented a DirectCompute version of error diffusion. You may wish to use that one as it's a bit faster.

[kasper93]

How intensive is OpenCL Error Diffusion? My HTPC is decently powerful (Radeon 5850), but when that option is active, my videos play back at what seems like one or two frames per second.

Use directcompute version, it is 10x faster on my HD5870.

[Mangix]

Does anyone know what the flush settings in the windowed and exclusive mode settings pages do? I've disabled all of them and currently have no issues. The only thing that I notice is that rendering times are not shown in the OSD anymore.

[travex]

Hi guys.

I'm having some problem with the newest madVR. Whenever I use NNEDI3 to double LUMA even with 16 neurons only, I get huge frame drop when play this demo file (720p-8bit-60fps) , my GPU is often loaded at 95-100%.

Without NEEDI3 on, I can play the file smooth as butter (90% GPU load with full screen :angry: )

I'm using madVR level 5 with my rig (3770k@4.5GHz and 7970 at default + 32GB 1600Mhz under win 7 64 bit)

So the question is, is my 7970 not powerful enough to deal with NNEDI3 or I need to tweak something ?

Thank guys.


Ps: The demo file mentioned can be downloaded free here:
(http://www.hfrmovies.com/2012/12/30/sample-avatar-clips-at-48-fps-and-60-fps/)

[pie1394]

Hi guys.
So the question is, is my 7970 not powerful enough to deal with NNEDI3 or I need to tweak something ?



Yes... You have to do that with madVR 0.84.7 for 60 fps playback on this GPU.

Profile list for 60fps --> #22356 (http://forum.doom9.org/showthread.php?p=1665685#post1665685)
ED feature timing on OpenCL / DC3 --> #22472 (http://forum.doom9.org/showthread.php?p=1666050#post1666050)

[ShadowVlican]

Hi guys.

I'm having some problem with the newest madVR. Whenever I use NNEDI3 to double LUMA even with 16 neurons only, I get huge frame drop when play this demo file (720p-8bit-60fps) , my GPU is often loaded at 95-100%.

Without NEEDI3 on, I can play the file smooth as butter (90% GPU load with full screen :angry: )

I'm using madVR level 5 with my rig (3770k@4.5GHz and 7970 at default + 32GB 1600Mhz under win 7 64 bit)

So the question is, is my 7970 not powerful enough to deal with NNEDI3 or I need to tweak something ?

Thank guys.


Ps: The demo file mentioned can be downloaded free here:
(http://www.hfrmovies.com/2012/12/30/sample-avatar-clips-at-48-fps-and-60-fps/)
my AMD 7950 can't even do NNEDI3 16 neurons with 720P24 (typical broadcast anime)

NNEDI3 is only usable on SD content with my system

edit: just updated to DirectCompute4 and awesome! i can finally use Error Diffusion without worrying about dropped frames!

[travex]

my AMD 7950 can't even do NNEDI3 16 neurons with 720P24 (typical broadcast anime)

NNEDI3 is only usable on SD content with my system

edit: just updated to DirectCompute4 and awesome! i can finally use Error Diffusion without worrying about dropped frames!

Can you be more specific about how to install directcompute4 mate , cheer ?

@Pie1394 : Thanks mate I will give it a try ;)

[kazuya2k8]

I finally decided to go to the darkside and downgrade my Nvidia drivers to 327.23 :devil: Oh well I spent much time watching than gaming anyway. NNEDI3 really makes a big difference on SD content.

I have a GTX 660 2Gb OC from MSI, an I5-3470 running at 40x and 8 gb 1866 ram. NNED is kicking my arse all over the place.

We have similar GPU but mine's from EVGA with i5-4430@Stock and 16GB 1866Mhz ram. These are my settings for watching progressive Hi10p 23.796 contents on 1080p display (madvr directcompute4):

Common:
-Trade quality for performance all unchecked
-Jinc3AR for Luma/Chroma upscaling
-CatmullRomARLL for Luma downscaling
-Debanding Low
-SmoothMotion on judder

Then I created a simple profile for 'image doubling'

if (srcHeight <= 360) "doubling-quad2"
elseif (srcHeight <= 480) "doubling-quad"
elseif (srcHeight <= 720) "doubling-on"
else "doubling-off"

doubling-quad2: Luma NNEDI3 128/16 neurons (1.5x/3x)
doubling-quad: Luma NNEDI3 64/16 neurons (1.5x/3x)
doubling-on: Luma NNEDI3 16 neurons (1.5x)
doubling-off: Everything unchecked

So far so good playing with no frame drops. Having NNEDI3 16 on 720p contents is already a big improvement. I can push to 32 nuerons if OpenCL ED is disabled.

[cyberbeing]

The CPU spikes you mention, can you see them in the task manager? Because I cannot reproduce it here. Just tried various clips with various resolutions with very demanding NNEDI3 settings, smooth motion and ED and at least on my setup, madVR immediately goes down to 0-1% CPU usage when I hit pause. The same in windowed or exclusive mode. Sounds like there´s a bug somewhere (which seems to depend on the settings), would be helpful if someone else could also take a look, too.

Yes I can see it in Task Manager. Using Process Explorer with an update interval set to 0.5 seconds, I can clearly seek the spiking CPU usage between 0% <-> 25% (quad-core no HT) each interval and produce a spiky CPU graph.

All I know is that the madVR CTRL+J OSD w/ something OpenCL running on the paused frame is the trigger. There must be some way for madVR to prevent NVIDIA's OpenCL driver from waking up and going full bore on the CPU for a couple milliseconds, each time madVR polls or updates the OSD...

[G_M_C]

See these multiquotes:

I get the feeling that moderate to powerful AMD cards are having more trouble with NNEDI3 than comparable Nv cards. I cannot explain the difference very well.

Hmm, I've finaly found time to see if the newest developments in madVR work for me.

I've got a C2Q 9650XE with an AMD HD7850 @ 950 core / 1250 mem.
[...]
Then installed madVR 87.4 with DirectCompute V3 build /.ax.

Seems i cannot use nnedi3 without getting dropped frames, not for chroma upscaling nor for image doubling. Tested with an 720p24 anime wich has to be upscaled to a 1080p60 display. Playing with settings (neurons, smooth motion on/off, error difusion on/off and so forth) did not help much.
[...]
But something tells me my HD7850 should do better. Anyone ideas what could be wrong here ?


Hi guys.

I'm having some problem with the newest madVR. Whenever I use NNEDI3 to double LUMA even with 16 neurons only, I get huge frame drop when play this demo file (720p-8bit-60fps) , my GPU is often loaded at 95-100%.
[...]
I'm using madVR level 5 with my rig (3770k@4.5GHz and 7970 at default + 32GB 1600Mhz under win 7 64 bit)
[...]


my AMD 7950 can't even do NNEDI3 16 neurons with 720P24 (typical broadcast anime)
[...]


These are my settings for watching progressive Hi10p 23.796 contents on 1080p display (madvr directcompute4):

doubling-quad2: Luma NNEDI3 128/16 neurons (1.5x/3x)
doubling-quad: Luma NNEDI3 64/16 neurons (1.5x/3x)
doubling-on: Luma NNEDI3 16 neurons (1.5x)
doubling-on: Everything unchecked

So far so good playing with no frame drops. [...]

[romulous]

P.S: Or I could add an undocumented feature to madVR to auto-load pixel shaders from a text file or from the registry or something. No big problem, really...

Yes please! :)

[cyberbeing]

Yes I can see it in Task Manager. Using Process Explorer with an update interval set to 0.5 seconds, I can clearly seek the spiking CPU usage between 0% <-> 25% (quad-core no HT) each interval and produce a spiky CPU graph.

All I know is that the madVR CTRL+J OSD w/ something OpenCL running on the paused frame is the trigger. There must be some way for madVR to prevent NVIDIA's OpenCL driver from waking up and going full bore on the CPU for a couple milliseconds, each time madVR polls or updates the OSD...

Investigated this a bit more with Process Hacker 2, it seems that NNEDI3 + madVR OSD stats causes a madVR thread to bounce between the states of "Running", "Wait:UserRequest", "Wait:DelayExecution" every few hundred miliseconds. When NNEDI3 or the OSD is disabled, that thread in madVR never leaves the "Wait:UserRequest" state when the video is paused.

Looking at the thread stack, it changes between this (http://i1.someimage.com/DP5U4Iv.png) and this (http://i1.someimage.com/rxV1iCD.png) in sync with the CPU load spikes. Definitely the OpenCL driver which is being woken up by madVR's OSD, but the mystery is why. It also looks like this problem thread is set to THREAD_PRIORITY_HIGHEST (understandable to prevent issues during normal playback) with a dynamic priority of 11+ when this issue occurs.

[kazuya2k8]

I get the feeling that moderate to powerful AMD cards are having more trouble with NNEDI3 than comparable Nv cards. I cannot explain the difference very well.

But my configurations is for 24p viewing only. And one problem is from playing 60p (2.5x more frames to render):

I'm having some problem with the newest madVR. Whenever I use NNEDI3 to double LUMA even with 16 neurons only, I get huge frame drop when play this demo file (720p-8bit-60fps) , my GPU is often loaded at 95-100%.

And as expected got massive frame drops with my personal config. Eliminated the frame drops by setting to a lower scaling algorithm (Croma Bicubic75/LumaUp Lanc3/LumaDown CatRom) and deband off with NNEDI3 16.

Edit:
For some unknown reasons, after using mpc-hc with madvr (after making it load/play several videos, pause/resume, fse in/out abuse), madVR would refuse to go fullscreen. It would maximize to a black screen for a second and go back to window mode. Afterwards, trying to close mpc-hc would display a crash message.

[Boltron]

P.S: Or I could add an undocumented feature to madVR to auto-load pixel shaders from a text file or from the registry or something. No big problem, really...

That would be awesome. I have for so long wanted to include a sharpen filter since my Darbee died and it just doesn't work with JRiver. I have tried a few ways with avisynth but it is just not stable enough on the HTPC.

[madshi]

It seems that's not where the problem lies. Even setting it to a ridiculous value like 51 (20% gray) just to check that it was working, black is still non-zero and shows dithering patterns.
That's weird. The custom pixel shader should move blacks into the BTB range. madVR does not clip BTB in any of its processing steps. So your video blacks should enter the 3dlut in the BTB range. And the 3dlut is *supposed* to scale down into the BTB range, too. If it did, there could still be dithering noise, but it should be between e.g. steps 14-15 of the BTB range, so it shouldn't be visible at all. This all leads me to the conclusion that probably your 3dlut clips BTB and moves all BTB data into >= 16 range? Is that possible? Did you create your 3dlut with the latest ArgyllCMS version? If not, try recreating it with the latest ArgyllCMS build.

I can also confirm that the modified error diffusion dither in build 4 behaves similar to "random dither" on blacks when using a 3DLUT. Both add 1px dots of noise with levels of R0-G0-B1 R0-G1-B0 and R1-G0-B0 on black where none should exist. To completely eliminate every last stray dither dot on black, I need to set the shader madshi posted to 1.0 / 255.0.
But the custom shader does fix the problem for you?

I´m interested, how does madshi´s new implementation compare to your floyd_96.png image?
Those images all did 1bit dithering, IIRC? So you can't really compare that. madVR dithers to 8bit, not to 1bit.

I guess that´s the case for both, NV and AMD?

Since the GPU itself shouldn´t really care if it´s a compute-based DX or OCL shader, I guess their compilers are not as well optimized for both.

So apparently it´s like this at the moment:

Nvidia = CUDA and DirectCompute has good performance, OpenCL is acceptable or really bad
AMD = OpenCL has excellent performance and DirectCompute is at least as good as NV
I don't know if I can draw such a conclusion yet. What I can say is that AMD performs really well in comparison to Intel and NVidia when using OpenCL - but the D3D <-> OpenCL interop cost is so extremely high with AMD that OpenCL becomes almost useless - except for *really* time consuming stuff like NNEDI3. Intel and NVidia seem to have much lower interop cost.

I have a question about how madVR settings are laid out. What is the distinction between processing and rendering? Because it seems to me that smooth motion should be moved from rendering into processing.
I probably should rename "rendering" into "presentation" to make things clearer. Smooth motion FRC is a part of the whole presentation logic, which depends on the display refresh rate etc. In any case, now is not the time to prettify the settings dialog. We're still talking about a work-in-progress project which has not reached v1.0 yet.

How intensive is OpenCL Error Diffusion? My HTPC is decently powerful (Radeon 5850), but when that option is active, my videos play back at what seems like one or two frames per second.
Try the latest DirectCompute test build. It will run much faster on your 5850.

Does anyone know what the flush settings in the windowed and exclusive mode settings pages do? I've disabled all of them and currently have no issues. The only thing that I notice is that rendering times are not shown in the OSD anymore.
The flushes are sometimes necessary to make playback work smoothly and correctly. If you can disable them without negative side effect that might improve your GPU performance slightly. Watch out for weird problems, though, and if you get such, remember that you removed the flushes.

I'm having some problem with the newest madVR. Whenever I use NNEDI3 to double LUMA even with 16 neurons only, I get huge frame drop when play this demo file (720p-8bit-60fps) , my GPU is often loaded at 95-100%.

Without NEEDI3 on, I can play the file smooth as butter (90% GPU load with full screen :angry: )

I'm using madVR level 5 with my rig (3770k@4.5GHz and 7970 at default + 32GB 1600Mhz under win 7 64 bit)
How do you manage to bring a 7970 to 90% load without using NNEDI3? Are you using Jinc8AR for everything?? Check your 3D settings (like anisotropic filtering, anti-aliasing etc). If you have them forced on, they will slow madVR down without bringing any visual benefit.

Yes I can see it in Task Manager. Using Process Explorer with an update interval set to 0.5 seconds, I can clearly seek the spiking CPU usage between 0% <-> 25% (quad-core no HT) each interval and produce a spiky CPU graph.

All I know is that the madVR CTRL+J OSD w/ something OpenCL running on the paused frame is the trigger. There must be some way for madVR to prevent NVIDIA's OpenCL driver from waking up and going full bore on the CPU for a couple milliseconds, each time madVR polls or updates the OSD...
Investigated this a bit more with Process Hacker 2, it seems that NNEDI3 + madVR OSD stats causes a madVR thread to bounce between the states of "Running", "Wait:UserRequest", "Wait:DelayExecution" every few hundred miliseconds. When NNEDI3 or the OSD is disabled, that thread in madVR never leaves the "Wait:UserRequest" state when the video is paused.

Looking at the thread stack, it changes between this (http://i1.someimage.com/DP5U4Iv.png) and this (http://i1.someimage.com/rxV1iCD.png) in sync with the CPU load spikes. Definitely the OpenCL driver which is being woken up by madVR's OSD, but the mystery is why. It also looks like this problem thread is set to THREAD_PRIORITY_HIGHEST (understandable to prevent issues during normal playback) with a dynamic priority of 11+ when this issue occurs.
I explained it yesterday. You seem to have missed my post?

Test4 adds low level noise outside the target rectangle when using ED outside the left,right,top bottom of the image.
And in some cases strage noise patterns outside edges when the background is black. The noise is extremly low level but noise outside the target rectangle suggest that something is not right.
I'm not sure about that. Error diffusion is applied to the final rendering image, which includes black bars added to the image through scaling or letterboxing. So having low level dithering noise outside of the active video rectangle does not have to be a sign of a problem.

To me the build 4 version seems a bit more 'noisy'.
Have to agree...

I was finally able to confirm that using error-diffusion in an image with colour does indeed introduce coloured "noise" because of the misalignment of the different channels. The good news is that the effect isn't as bad as it could be. The bad news is that it does exists and mainly near edges which is unfortunate.

I've generated the pattern by using the Colorbars function from avisynth in the video processor of Potplayer, which for some reason resulted in an image which was horizontally flipped.

I then cropped the image and scaled the range [0-40] to [0-255] and doubled the size (nearest neighbour scaling). This gave the following result for the different algorithms:

normal dithering (http://i.imgur.com/lXGshAf.png), error diffusion build 3 (http://i.imgur.com/nt7bEvL.png), error diffusion build 4 (http://i.imgur.com/lrXQXCH.png)

You should be able to see that the pattern near the coloured surfaces is slightly coloured where it should be dark-gray. To make this more obvious here are the same three images but with the saturation increase by 100.

normal dithering (http://i.imgur.com/XS2FxmP.png), error diffusion build 3 (http://i.imgur.com/jStccuu.png), error diffusion build 4 (http://i.imgur.com/FnfEbVC.png)

Luckily the added noise from build 4 doesn't seem to add more coloured noise than the previous algorithm. It is also fairly hard to detect without special methods, but it might be worth it to see if it is at all possible to do the dithering in YCbCr which, at least in my experiments, should prevent this from happening. This likely won't be free though, although I think it is possible to do it with one 7x3,3x1 matrix multiplication and several if statements.

Edit: I seemed to have accidentally used bicubic scaling on the error diffusion build 4 image, this might explain why the "coloured noise" looks slightly different.
I'm afraid of the added performance cost. The problem is not even the math instructions, but the added registers the compiler would need to spend on this. Furthermore, we're mostly talking about chroma noise here, not luma noise. It's already very difficult to see the Error Diffusion luma noise at 8bit. Probably it's only visible due to the worm artifacts. I think chroma noise at 8bit Error Diffusion levels should be invisible to the human eye, especially if we manage to remove the worm artifacts without raising the noise level (see test build 5).

Actually I wonder if it wouldn't be beneficial to have colored dithering patterns instead of gray ones. Because gray dithering patterns mean we have luma noise. Colored dithering patterns means we get chroma noise, but since all 3 channels have different dithering patterns, this might actually decrease luma noise! Which might actually lower the subjective noise levels. Thoughts?

So what I suspect is that the coloured noise is confined to those 16x16 blocks, the coloured error which causes the noise doesn't travel past those blocks. This seems the only sensible way to implement error diffusion on a GPU since otherwise you'd have to scan the image pixel by pixel which would mean that using a CPU would be faster.
Correct. The errors are confined to those 16x16 blocks. Originally I feared the borders of those 16x16 blocks might become visible. But fortunately I've not seen this happening (yet?).

The reason this doesn't always occur is because error diffusion does exactly the same thing for the same values, this combined with the fact that error diffusion is only used on 16x16 blocks means that when the entire 16x16 block is gray, it will give exactly the same result for the same channels, which leads to an image which is gray.
Correct again.

Which algorithm do you use to add noise in version 4? The one that Shiandow proposed might yield better results. He suggested simply using a handful of different diffusion tables and picking among them at random on each pixel. That should avoid introducing additional noise, it just spreads the errors in a way that seems less like a pattern to the human eye.
Hmmmm... In test build 4 I was adding a random value to the pixel value before rounding it. I think Shiandow's idea to use different weights is a good idea. However, for test build 5 I've chosen to not use a weight table. Instead I'm now using fully random error distribution weights. There are some restrictions to the randomness, and I'm making sure the weight sum is slightly below 1.0. Results look promising to me.

-------

I hope this build will make everyone happy:

http://madshi.net/madVRdirectCompute5.rar

From what I can see the worm artifacts are gone, and the noise level doesn't appear to be raised much. At least much less than in test build 4. There are still some stray dots sometimes, but it's pretty rare now, I think.

[cyberbeing]

But the custom shader does fix the problem for you?

Yes, it did. Though it seems slightly sub-optimal, considering that shader also shifted the white level by the same amount.


I explained it yesterday. You seem to have missed my post?

What you explained yesterday didn't answer my question about how the madVR CTRL+J OSD is related to this...

madVR does a "busy wait" on DirectCompute processing. I think NVidia does the same internally when I ask it for for OpenCL processing. This type of busy wait sets the waiting thread to 100% CPU usage. *However*, it's a special kind of wait which doesn't really slow anything else down. Meaning, madVR basically tells Windows: "If anybody else needs the CPU, give it to them immediately, otherwise let me have it". The reason I'm using this type of wait is that I don't want to waste any time. The only way to bring CPU usage down would be to tell Windows "I don't need the CPU for the next 1 ms". But then if DirectCompute/OpenCL were finished 0.00001ms after that, I would have wasted almost 1 full ms rendering time. And that just for one rendering step. Each video frame often requires multiple rendering steps...


The video is paused in windowed mode and not touched throughout these steps
madVR render queue is full.
madVR is idle.
NNEDI3 OpenCL has no workload to process.
0-1% CPU load.
Press CTRL+J to enabled OSD stats.
The video remains paused.
madVR is updating OSD.
NNEDI3 OpenCL still has no workload to process.
0-100% CPU load "busy wait" CPU spikes by OpenCL driver
Press CTRL+J to disable OSD stats.
The video remains paused
madVR stops updating OSD.
NNEDI3 OpenCL still has no workload to process.
0-1% CPU load.
Press CTRL+J to enabled OSD stats.
The video remains paused.
madVR is updating OSD.
NNEDI3 OpenCL still has no workload to process.
0-100% CPU load "busy wait" CPU spikes by OpenCL driver
Press CTRL+J to disable OSD stats.
The video remains paused
madVR stops updating OSD.
0-1% CPU load.

:confused:

Could you please clarify:

Why madVR's CTRL+J OSD triggers the 100% CPU "busy wait" when the video is paused and there isn't any OpenCL processing needed?

Why the "busy wait" disappears when the CTRL+J OSD is disabled?

Why does madVR request OpenCL processing from NVIDIA's driver when the CTRL+J OSD is enabled?

Why does madVR stop requesting OpenCL processing from NVIDIA's driver when the CTRL+J OSD is disabled?

[iSunrise]

I hope this build will make everyone happy:

http://madshi.net/madVRdirectCompute5.rar

From what I can see the worm artifacts are gone, and the noise level doesn't appear to be raised much. At least much less than in test build 4. There are still some stray dots sometimes, but it's pretty rare now, I think.
Yes, the random dots are pretty much gone with this build. Noise also seems pretty well spread, worms are, apart from bar 19, non-existent, now.

However, compared to the DC3 and DC4 builds, bar 17 appears a bit darker and the thin white line at the bottom of bar 18 suddenly disappears. Is that expected? While the darkening of bar 17 could probably be handled with another calibration pass, the lost white line worries me a bit, to be honest.

http://abload.de/thumb/directcompute3_enhancw0kc1.png (http://abload.de/image.php?img=directcompute3_enhancw0kc1.png)http://abload.de/thumb/directcompute4_enhanc0zklw.png (http://abload.de/image.php?img=directcompute4_enhanc0zklw.png)http://abload.de/thumb/directcompute5_enhancpmjah.png (http://abload.de/image.php?img=directcompute5_enhancpmjah.png)

Here are magnified versions, so you should see it more clearly:

http://abload.de/thumb/directcompute3_enhancghktp.png (http://abload.de/image.php?img=directcompute3_enhancghktp.png)http://abload.de/thumb/directcompute4_enhancphjwt.png (http://abload.de/image.php?img=directcompute4_enhancphjwt.png)http://abload.de/thumb/directcompute5_enhancczkpl.png (http://abload.de/image.php?img=directcompute5_enhancczkpl.png)


@cyberbeing:
madVR constantly (even when you hit pause) needs to redraw, otherwise we could not see updates to the OSD and when we change settings in real-time, so it still has to process every step of the pipeline, have you taken that into account? Because when I read "NNEDI3 OpenCL still has no workload to process." I´m a little bit unsure if you did.

[nevcairiel]

Why does madVR request OpenCL processing from NVIDIA's driver when the CTRL+J OSD is enabled?

It probably redraws the frame to update the OSD even in pause mode.
Seems like a non-issue to have high load with debug OSD in pause mode. Its just how it is.

[wolfman2791]

I have a q about "artifact removal". Is it best to turn it on or off? If one should turn it on, what are the best settings? Thanks in advance.

[cyberbeing]

It probably redraws the frame to update the OSD even in pause mode.
Seems like a non-issue to have high load with debug OSD in pause mode. Its just how it is.

If I assume this is true, it still doesn't explain why redrawing the frame requires OpenCL access in the driver? There is 0% GPU load, so considering how expensive NNEDI3 is, it seems unlikely OpenCL actually has any workload? Do window re-paints somehow necessitate an OpenCL<->D3D9 interop or similar, even when there is no actual OpenCL processing needed? Is that also why this OpenCL "busy wait" exists when the video is paused, OSD disabled, and you move the window around the screen?

@cyberbeing:
madVR constantly (even when you hit pause) needs to redraw, otherwise we could not see updates to the OSD and when we change settings in real-time, so it still has to process every step of the pipeline, have you taken that into account? Because when I read "NNEDI3 OpenCL still has no workload to process." I´m a little bit unsure if you did.

I'm a bit unclear about what madVR's redraw pipeline looks like? Unless the user changes settings or window dimensions, madVR already has a finalized video frame sitting GPU RAM from the Render Queue. When a redraw is requested, these finalized frames only need to be Presented and displayed onscreen as-is. Resizers like NNEDI3, Spline, Lanczos, etc should not entire the pipeline during a simple redraw of an already fully processed video frame.

[ryrynz]

I have a q about "artifact removal". Is it best to turn it on or off?

Entirely depends on your content. Try it and see for yourself. It smooths out gradients aka "debanding"

If one should turn it on, what are the best settings?

There's a rule here about asking that question :P

Just read back in the forum regarding debanding and decide from expert options or heaven forbid you could try it and decide for yourself if it suits.

[iSunrise]

I have a q about "artifact removal". Is it best to turn it on or off? If one should turn it on, what are the best settings? Thanks in advance.
It is used for sources that need debanding, like anime, some movies and other kinds of clips, like highly-compressed youtube videos. Set it to low, if you want to avoid side-effects like lost details (although by the very nature of it, this is already the case, even at this low setting), set it higher if you need more debanding strength. You can also tweak it manually, with the keyboard controls.

And don´t post things like "what are the best settings", there really is no best, otherwise there wouldn´t be any options there would they. ;)

[6233638]

That's weird. The custom pixel shader should move blacks into the BTB range. madVR does not clip BTB in any of its processing steps. So your video blacks should enter the 3dlut in the BTB range. And the 3dlut is *supposed* to scale down into the BTB range, too. If it did, there could still be dithering noise, but it should be between e.g. steps 14-15 of the BTB range, so it shouldn't be visible at all. This all leads me to the conclusion that probably your 3dlut clips BTB and moves all BTB data into >= 16 range? Is that possible? Did you create your 3dlut with the latest ArgyllCMS version? If not, try recreating it with the latest ArgyllCMS build.I'm still using the yCMS option inside madVR, as that actually lets me edit the values used in the LUT. I've never been able to get good results with ArgyllCMS.

I've just checked by changing the output to 16-235 though, and you're right - using the yCMS option is clipping BTB values.

From speaking with Graeme, as I understand it ArgyllCMS intentionally uses a non-zero black level in the LUT creation, which is absolutely the wrong thing to do in my experience. (which is years of using external hardware LUT boxes, and hand-crafted LUTs)

EDIT: You can't even specify zero as your black level in ArgyllCMS. It resets to 0.000001 cd/m²
EDIT2: And Windows 8.1 is not letting me use the ArgyllCMS custom driver instead of the signed X-Rite drivers.

[CruNcher]

Did a quick test of DC version build of Error Diffusion on the HD7970.

- 1920x1080p24 H.264 Hi10 contents to 1080p24 output mode.
- NNEDI3 32 for Chroma 2x upscaling
- Debanding with angle detection

No dithering with 0.87.4: 15.2 ~ 15.3 ms
No dithering with DC3 : 15.1 ~ 15.2 ms
Random dithering with DC3: 15.2 ~ 15.3ms
ED with 0.87.4 OpenCL: 26ms (39ms**)
ED with DC1: 17.2ms
ED with DC3: 17.0ms


** This is the timing number when the GPU-z runs at the background, the playback is also unstable. So I recommend those people who have measured strange timing numbers should be careful about this.

This is completely expected and everyone that's more advanced knows that the pooling on a none RTOS will cause latency issues ;)

But it is allways good to keep users and Programmers aware of that ;)

This is also something Gamer really have to learn ;)

[leeperry]

Just spent some time comparing DC3/4/5 and I've got a 720p24 sample here where the pop effect is drastically higher using DC3 to my eyes: 720p24_sample.mkv (3.8 MB) (https://mega.co.nz/#!y4pTFIIa!RcItc8YlU_v0dXQZUd6uAHbU6LIFmUU5C6gNKPMoLY8)

I'm using 64 neurons for luma, J3AR for chroma and CC AR LL for downscaling @ 1080p24.

I'm colorblind on red so don't shoot the messenger but I find the kid's hair flying in the air or the depth impression of that redhead kid on the rooftop behind the front kid much more striking with DC3......apparently 8% of the male population is colorblind (http://www.colourblindawareness.org/) so I don't think there would be such a thing as a dithering algorithm that would make everyone equally happy, especially if you start adding noise to chroma :o

[bacondither]

Strange dots with error diffusion are gone in madVRdirectCompute5. :D

[James Freeman]

I'm still using the yCMS option inside madVR, as that actually lets me edit the values used in the LUT. I've never been able to get good results with ArgyllCMS

Agreed 100%.

I use HCFR to measure the coordinates with i1 Display Pro and enter them into yCMS.
Yet, yCMS is also flawed, it gives wrong color gradient and clipped colors.
3DLUT is a complete mess in many ways...


The absolute best color management I've tested is the built in "Enhanced Video Renderer" that comes with MPC-HC.
It uses the .ICM profile you load into Windows and it JUST WOKS like in Photoshop or any other Color Aware software.

Don't get me started..
I'm getting sad only thinking about MadVR not using the most simple and best method for CMS,
instead we have to struggle with highly complicated and inaccurate 3DLUTs.

Every time I tried to talk about it, its always the same answer from madshi "No feature request till 1.0" :(

Its not a feature request,
Its a fundamental requirement to get the absolute best picture from MadVR, even more than DeBanding or NNEDI...
A good hassle free Color Management that uses the already activated .ICM profile in Windows.

Picture/Color Quality (the purpose of MadVR)?
Color Management is the FIRST thing that has to be addressed properly.
Yet, MadVR makes it many times harder than it should be.

End of Rant. :o

Mashi hope you got the messege.. :D

[leeperry]

I'm getting sad only thinking about MadVR not using the most simple and best method for CMS,
instead we have to struggle with highly complicated and inaccurate 3DLUTs.
Hard to disagree, I was using that gamut PS script because FSE/FSW transitions were very smooth on XP(and I made automatic profiles in PotP based on fps/resolution), but it's a blinking laggy feast on W7 so ideally I would like to finally put this thing (http://www.geek.com/review/logitech-nulooq-navigator-571565/) to use and set hotkeys for gamut mapping and forcing 24Hz(it's currently quite a PITA to watch 25p@24Hz in mVR with automatic refresh rate rolling enabled and I can't force 25p@24p because I've got genuine 25p content), but the ArgyllCMS 3DLUT adventure looks like an endless source of headaches.

[James Freeman]

Hard to disagree....
ArgyllCMS 3DLUT adventure looks like an endless source of headaches.

Not only headaches, also an inaccurate crappy 3DLUT.
I myself use ArgyLLCMS+DispcalGUI for calibration which gives me the best results (and its free).
BUT the resulting .MadVR 3DLUT creation is absolute mess...


Still... there is no proper Color Management in MadVR which is a shame.

[CruNcher]

Just to clarify how good Error Diffusion is compared to Random Dithering.
These are actual screen shots from MPC-HC+MadVR.

http://www.mediafire.com/convkey/17dc/a42gcrd46hj3ycpfg.jpg

this is nice but you forget one important thing the Display Device ;)

[madshi]

What you explained yesterday didn't answer my question about how the madVR CTRL+J OSD is related to this...
In order to update the OSD, I have to re-render the frame. IIRC I do a full redraw, including all OpenCL/DirectCompute algorithms. Obviously, if the OSD is disabled, I don't have to do that.

However, compared to the DC3 and DC4 builds, bar 17 appears a bit darker and the thin white line at the bottom of bar 18 suddenly disappears. Is that expected? While the darkening of bar 17 could probably be handled with another calibration pass, the lost white line worries me a bit, to be honest.
Are you sure you've compared the same frame? In theory this is static content, but it's encoded with a lossy video codec, so it's not really static, anymore. I think it's quite probable that the white line is there in some frames and not in others. Not sure about the brightness of bar 17. The error diffusion is now slightly more exact in test build 5 than it was before. But the difference is pretty small so it would surprise me if that would explain the different bar 17 brightness level. Maybe it's also a frame-by-frame difference in the video file?

I have a q about "artifact removal". Is it best to turn it on or off?
The default deband configuration was carefully tweaked to not hurt image detail, while still doing a useful amount of banding artifact removal. IMHO you can leave the "low" setting always on without worrying about damaging your video quality. For bad quality videos you may want to raise the debanding strength, which will nicely take care of banding artifacts, on the cost of maybe losing a little bit of detail. I don't recommend using "medium" or "high" settings on default for all videos, but "low" should be fine. Of course that's only my personal opinion. Others may disagree.

I've just checked by changing the output to 16-235 though, and you're right - using the yCMS option is clipping BTB values.
Ok, that explains why the custom shader trick didn't work.

So, does the original problem still occur with test build 5?

Just spent some time comparing DC3/4/5 and I've got a 720p24 sample here where the pop effect is drastically higher using DC3 to my eyes: 720p24_sample.mkv (3.8 MB) (https://mega.co.nz/#!y4pTFIIa!RcItc8YlU_v0dXQZUd6uAHbU6LIFmUU5C6gNKPMoLY8)
Do you have something more concrete than a subjective impression of "pop effect"? Ideally a screenshot or something which shows why you like DC3 better? From a technical point of view, "pop effect" does not help me in my development, because I haven't got a clue which screw to turn in my algorithm to increase or decrease a subjective "pop effect".

Tell me something about worm artifacts, noise levels, or things like that, and I can actually go looking for the cause of the problems and try to fix it. But trying to improve abstract black box things like "pop effect" is like fishing in the dark...

Strange dots with error diffusion are gone in madVRdirectCompute5. :D
:)

[kerimcem]

dc/4/5 my old pc(ati 3650) full black screen dont work madvr...

[nevcairiel]

dc/4/5 my old pc(ati 3650) full black screen dont work madvr...

DirectCompute requires a DirectX 11 compatible graphics card, which means at least 5000 series for ATI/AMD, I believe.

[The 8472]

I'm afraid of the added performance cost. The problem is not even the math instructions, but the added registers the compiler would need to spend on this. Furthermore, we're mostly talking about chroma noise here, not luma noise. It's already very difficult to see the Error Diffusion luma noise at 8bit. Probably it's only visible due to the worm artifacts. I think chroma noise at 8bit Error Diffusion levels should be invisible to the human eye, especially if we manage to remove the worm artifacts without raising the noise level (see test build 5).

Actually I wonder if it wouldn't be beneficial to have colored dithering patterns instead of gray ones. Because gray dithering patterns mean we have luma noise. Colored dithering patterns means we get chroma noise, but since all 3 channels have different dithering patterns, this might actually decrease luma noise! Which might actually lower the subjective noise levels. Thoughts?

I don't think that's a good idea, chroma noise is very visible on on blacks. It looks more brown than black in those cases. I think this is because the colors are not perceptually uniform. Varying blue levels doesn't do much, but adding some more red when there shouldn't be any makes it brownish.



Hmmmm... In test build 4 I was adding a random value to the pixel value before rounding it. I think Shiandow's idea to use different weights is a good idea. However, for test build 5 I've chosen to not use a weight table. Instead I'm now using fully random error distribution weights. There are some restrictions to the randomness, and I'm making sure the weight sum is slightly below 1.0. Results look promising to me.

To me the flat, grey bars still look smoother in build 3. In iSunrise's enhanced screenshots this is especially visible on bar #19. Build 3 produces a fine, uniform lattice which gives it a smooth appearance since it visually blurs together. The new random weights on the other hand create clusters of the same color which are more noticeable.

But 5 still is a good improvement over 4 or random dithering.

[leeperry]

Do you have something more concrete than a subjective impression of "pop effect"? Ideally a screenshot or something which shows why you like DC3 better? From a technical point of view, "pop effect" does not help me in my development, because I haven't got a clue which screw to turn in my algorithm to increase or decrease a subjective "pop effect".

Tell me something about worm artifacts, noise levels, or things like that, and I can actually go looking for the cause of the problems and try to fix it. But trying to improve abstract black box things like "pop effect" is like fishing in the dark...
I'm sorry, I'm mostly using mVR to watch movies from a 1 or 2 meters distance, I don't primarly use mVR to zoom at 3200% on nasty test patterns and come whine in here for a fix on stuff nobody would ever see from a distance(j/k :p).

The primary thing I've always been looking for in this hobby is the subjective pop effect and I've compared DC3/4/5 several times.....to my brain DC3 provides a much more pronounced depth impression(dead obvious on that sample really). But then again, many things come at play here: how my TV dithers its 10/12bit internal processing to 8bit, the fact that I'm colorblind on red, how its antiglare layer pearly pattern will react, how noisy the encode is, etc etc....

Maybe you could allow us to choose between several dithering algorithms? I would more than likely stick with DC3 over 4/5.

There's no one-size-fits all scaler, there might very well not be no "best" dithering algorithm either, especially if you start adding noise to chroma. DC3 looks stunning, I see the same pop effect as I get from SmoothL FWIW :cool:

[6233638]

Ok, that explains why the custom shader trick didn't work.

So, does the original problem still occur with test build 5?Yes, but to a lesser degree:
http://abload.de/thumb/build-53kzsh.png (http://abload.de/img/build-53kzsh.png)

Much better than Test Build 4 (http://abload.de/img/directcompute-4ocji7.png), but still enough to prevent the display from turning off dimming zones.

Interestingly, I think the "0% Black" area (which is still visible in Test Build 3 (http://abload.de/img/directcompute-3t1j53.png)) is supposed to be BTB content - though it may be an encoding issue which causes the outline to show up.

[Shiandow]

I'm afraid of the added performance cost. The problem is not even the math instructions, but the added registers the compiler would need to spend on this. Furthermore, we're mostly talking about chroma noise here, not luma noise. It's already very difficult to see the Error Diffusion luma noise at 8bit. Probably it's only visible due to the worm artifacts. I think chroma noise at 8bit Error Diffusion levels should be invisible to the human eye, especially if we manage to remove the worm artifacts without raising the noise level (see test build 5).

Actually I wonder if it wouldn't be beneficial to have colored dithering patterns instead of gray ones. Because gray dithering patterns mean we have luma noise. Colored dithering patterns means we get chroma noise, but since all 3 channels have different dithering patterns, this might actually decrease luma noise! Which might actually lower the subjective noise levels. Thoughts?

I'm afraid that it is not that you have chroma noise instead of luma noise, but rather that you have chroma noise on top of the luma noise. Although since most monitors rely on the fact that two coloured dots close to each other "blend" together, it does seem unlikely that you can see the difference on a normal monitor. But it might still be visible on some projectors.

By the way does "The problem is not even the math instructions, but the added registers the compiler would need to spend on this." mean that you could do the calculations but this would require you to write and read things to memory which takes more time? Because with some minor approximations I think it might actually be possible to do some of the calculations beforehand, in parallel, although if it then takes too much time to read the answers then that obviously doesn't help.

Also I think that in cases where the worm patterns themselves aren't visible it is actually beneficial to use those patterns instead of a randomized version since those patterns are closest to the actual colour and any attempt to remove the pattern will make those colours more 'noisy'. So normal error diffusion will probably be better for screens with a high pixel density whereas randomized error diffusion will be better for screens with a lower pixel density. I suspect that the latter case will profit the most from using error diffusion, so randomized error diffusion should probably be the default but it would be nice if you could still switch to normal error diffusion.