madVR - high quality video renderer (GPU assisted)

[turbojet]

bacondither: What does zhoufang look like without random noise?

[Damien147]

Damn,I am confused... to conclude,image doubling or anything related to nnedi3 doesn't work on hd 4xxx(amd) and GPUs of the same era,right?

[turbojet]

Damien147: only error diffusion doesn't work on ati 4000 series currently maybe nnedi3 won't at some point soon, up to madshi. Unless outputting to a small resolution, probably < 720p those gpus can't handle it anyway.

[Ver Greeneyes]

It would be nice if Error Diffusion were available on all cards capable of Direct3D 10.1 and up, since at least some of the higher end ones probably have the juice for it.. But if it would take a completely separate code path from the Direct3D 11 version of DirectCompute, it's probably not worth it.

[Damien147]

@turbojet

Ok,thank you.

[biggerpapi]

Finally after 5 long days I can post and hopefully get this figured out lol

So here's my issue. Ive got a laptop that uses Optimus with an HD4000 and a 640M. Ive renamed mpc-hc to make sure it uses my 640M. Ive downgraded my drivers to 327.23(and older/and performed clean installs each time) However, none of the NNEDI3 features are working still. I get a green screen with chroma upscaling and a dark black/red screen with image doubling. And openCL is checked on my 640m when I run GPU-z.

Now when I force mpc-hc to use the HD4000 NNEDI3 works, but is obviously unusable as I get massive frame drops, which I expected but I wanted to see if it at least worked.

Any ideas as to why this isnt working on the 640M? I understand these are pretty demanding processes but I'd rather end my insanity and see dropped frames rather than it not working at all.

[cyberbeing]

Using the random code from Zhou-Fang is maybe better...

new = 255*(old >= 128+(rand*96)*strg(img(ii,jj)+1)); Rand*96 instead of 128

Image (http://s23.postimg.org/5drazaoi3/floyd_96.png)
Unfortunately, madshi said it´s "not as fast", so I´m not sure if he´s willing to do that.

madshi only said the Zhou-Fang dither algorithm was "not as fast". That image bacondither posted was Floyd-Steinberg dither algorithm + random element. It uses that tiny snippet of random code from Zhou-Fang instead of some arbitrary value.

@bacondither

Just a heads up that you appear to have slight flaw in your image processing, since the histograms of all the dither images you are posting have R>G>B bias towards Red, while the input is a perfect R=G=B grayscale.


@madshi

I'm seeing high CPU usage from madVR on my NVIDIA card when the video is paused if both OpenCL NNEDI3 and the CTRL+J OSD stats are enabled. Same thing occurs with OpenCL dither to a lesser extent. If I disable either all the compute stuff or the CTRL+J stats, the issue goes away.

[bacondither]

.... have R>G>B bias towards Red, while the input is a perfect R=G=B grayscale.
I've noticed it too and mabe it is a bug in the library DIPimage or in MATLAB... :confused:
bacondither: What does zhoufang look like without random noise?
Zhou-Fang No dither (http://s4.postimg.org/xpz9yodjx/ZF_ND.png)


Zhou-Fang with dither takes around 2 times longer to compute then Floyd Steinberg with dither. That's in matlab and may not apply in other implementations.

[madshi]

So here's my issue. Ive got a laptop that uses Optimus with an HD4000 and a 640M. Ive renamed mpc-hc to make sure it uses my 640M. Ive downgraded my drivers to 327.23(and older/and performed clean installs each time) However, none of the NNEDI3 features are working still. I get a green screen with chroma upscaling and a dark black/red screen with image doubling. And openCL is checked on my 640m when I run GPU-z.

Now when I force mpc-hc to use the HD4000 NNEDI3 works, but is obviously unusable as I get massive frame drops, which I expected but I wanted to see if it at least worked.

Any ideas as to why this isnt working on the 640M? I understand these are pretty demanding processes but I'd rather end my insanity and see dropped frames rather than it not working at all.
Not sure why that happens for you. It seems that OpenCL is always producing "zero" output for you, just as the latest NVidia drivers do for all newer NVidia GPUs. Maybe once NVidia fixes the issue with the latest driver, it will also make it work on your GPU? I don't know, though.

I'm seeing high CPU usage from madVR on my NVIDIA card when the video is paused if both OpenCL NNEDI3 and the CTRL+J OSD stats are enabled. Same thing occurs with OpenCL dither to a lesser extent. If I disable either all the compute stuff or the CTRL+J stats, the issue goes away.
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...

-------

Here's a new test build, adding some randomness to Error Diffusion. The randomness is the same for every frame, so the patterns should not change for static content.

http://madshi.net/madVRdirectCompute4.rar

Please give it a try and let me know:

(1) How much performance this costs.
(2) Whether it gets rid of the worm artifacts well enough.
(3) If the subjective noise level went up or not.

Bad news: Currently my DirectCompute NNEDI3 implementation is about 10 times slower than OpenCL. I'm not sure yet why. I'm trying to improve performance, but I'm not hopeful right now. It's very well possible (or rather probable at this point) that we'll have to stick with OpenCL for NNEDI3. So we probably do need that NVidia driver fix, after all...

[6233638]

Here's a new test build, adding some randomness to Error Diffusion. The randomness is the same for every frame, so the patterns should not change for static content.

http://madshi.net/madVRdirectCompute4.rar

Please give it a try and let me know:

(1) How much performance this costs.
(2) Whether it gets rid of the worm artifacts well enough.
(3) If the subjective noise level went up or not.This is giving a non-zero black level with 3DLUTs again.

Extremely brightened examples of Build 3/4:
http://abload.de/thumb/directcompute-3t1j53.png (http://abload.de/img/directcompute-3t1j53.png) http://abload.de/thumb/directcompute-4ocji7.png (http://abload.de/img/directcompute-4ocji7.png)

[leeperry]

Here's a new test build, adding some randomness to Error Diffusion. The randomness is the same for every frame, so the patterns should not change for static content.

http://madshi.net/madVRdirectCompute4.rar

Please give it a try and let me know:

(1) How much performance this costs.
(2) Whether it gets rid of the worm artifacts well enough.
(3) If the subjective noise level went up or not.
Ouh, it's been Christmas everyday lately :D
Not much change compared to the DC3 build on 720p24@1080p with 32 neurons chroma and 64 luma + spline AR LL downscaling(tried to maximize the load here): http://thumbnails104.imagebam.com/30626/d989df306256642.jpg (http://www.imagebam.com/image/d989df306256642) http://thumbnails111.imagebam.com/30626/58a0cf306256643.jpg (http://www.imagebam.com/image/58a0cf306256643)

I think the subjective noise level has decreased, OTOH it would appear truer to the source and won't hide its artifacts nearly as well I guess...I'll run more real world comparisons from a 2 meters distance and will report back.

:thanks:

[bacondither]

Worms be gone! madVRdirectCompute4 looks great.

Build 3 Error diffusion (http://s29.postimg.org/574qdk4uv/ED_0s.png)
Build 4 Error diffusion (http://s30.postimg.org/wlixyzfdt/ED_NEW.png)

Mabe 6233638s problem is that his 3DLUT is raising the image black level from ex 0.000 to 0.001 in a 0-255(8-bit) integer and madvr tries to dither the raised black level. Or mabe its just a bug... :confused:

[James Freeman]

Worm pattern gone.
No performance hit.
Blacks untouched.

Thanks.

[6233638]

Mabe 6233638s problem is that his 3DLUT is raising the image black level from ex 0.001 to 0.001 in a 0-255(8-bit) integer and madvr tries to dither the raised black level. Or mabe its just a bug... :confused:It shouldn't be - black should always be zero in the LUT. But the controls offered in the internal calibration tools are very basic, and the author of ArgyllCMS insists that black should not be set to zero in the LUT. (because he's interpolating the lower values from zero then, rather than calculating the LUT and then setting black to zero after all other values have been calculated)

[madshi]

This is giving a non-zero black level with 3DLUTs again.

Extremely brightened examples of Build 3/4
That means your 3DLUT probably raises the black level. You could try using a custom pixel shader to lower the black level again to the right value. E.g. the following should lower the black level by 0.1 in 8bit:

sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, tex) - 0.1 / 255.0;
}
If this doesn't help, try 0.2 / 255.0, or even more until the problem goes away.

Worms be gone! madVRdirectCompute4 looks great.
Worm pattern gone.
No performance hit.
Blacks untouched.
Sounds good!

[6233638]

I really wish that we could just write output values for the LUTs rather than having to tweak input values. (and we cannot enter a value for zero in the madVR GUI)

I don't think JRiver MC supports pixel shaders.

[madshi]

I really wish that we could just write output values for the LUTs rather than having to tweak input values. (and we cannot enter a value for zero in the madVR GUI)

I don't think JRiver MC supports pixel shaders.
Why don't you try with MPC-HC to confirm whether it's working as expected? If it does, you could ask the JRiver MC guys to add support for pixel shaders. It should be pretty easy for them to do that. They'd just have to send the pixel shader code (in clear text form) to madVR, and madVR then does the rest. They could even hack this together and load the pixel shader(s) from a text file, so they don't have to add any GUI for this. There are 2 D3D9 dlls needed for this to work, though. They're both distributed with MPC-HC, so no problem to find them.

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...

[cyberbeing]

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...

Okay, but why does this occur when the video is paused, and how is it related to the CTRL+J OSD stats?

If the CTRL+J OSD is disabled + NNEDI3 enabled and I pause the video, CPU usage is less than 1% and my computer is silent.

If the CTRL+J OSD is enabled + NNEDI3 disabled and I pause the video, CPU usage is less than 1% and my computer is silent.

If the CTRL+J OSD is enabled + NNEDI3 enabled and I pause the video, CPU usage is ~10-15% and causes a my computer to make a rather annoying noise like power usage is fluctuating up and down in an unstable fashion. Since this is a quad-core without HT, it seems likely it's bouncing between 0% load and 100% load in short intervals.

[6233638]

Why don't you try with MPC-HC to confirm whether it's working as expected?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.

http://abload.de/thumb/20-percent3trbg.png (http://abload.de/img/20-percent3trbg.png)

[trip_let]

Finally after 5 long days I can post and hopefully get this figured out lol

So here's my issue. Ive got a laptop that uses Optimus with an HD4000 and a 640M. Ive renamed mpc-hc to make sure it uses my 640M. Ive downgraded my drivers to 327.23(and older/and performed clean installs each time) However, none of the NNEDI3 features are working still. I get a green screen with chroma upscaling and a dark black/red screen with image doubling. And openCL is checked on my 640m when I run GPU-z.

Now when I force mpc-hc to use the HD4000 NNEDI3 works, but is obviously unusable as I get massive frame drops, which I expected but I wanted to see if it at least worked.

Any ideas as to why this isnt working on the 640M? I understand these are pretty demanding processes but I'd rather end my insanity and see dropped frames rather than it not working at all.

Same happens on my HD 4000 / GT 650M. HD 4000 if selected works but is slow; GT 650M doesn't like NNEDI3 even on old drivers, clean install, etc.

Well, realistically 384 Kepler CUDA cores isn't going to cut it for much anyway.

[Skwelcha]

Don't know if this is an issue with MadVR or MPC-HC, but when I play a video file with a resolution of 1920 x "something under 1080"(let's say for example 816), I get a target rectangle of 0, 132, 1920, 948 when I play it in fullscreen(exclusive mode without aero). Shouldn't the height resolution stay at 816? I mean something is stretching the picture apperantly.. I've got this issue for quite a time now. I changed the MPC-HC, LAV and MadVR version without a change, that's why I can't narrow it down to where the problem is...

[nevcairiel]

Don't know if this is an issue with MadVR or MPC-HC, but when I play a video file with a resolution of 1920 x "something under 1080"(let's say for example 816), I get a target rectangle of 0, 132, 1920, 948 when I play it in fullscreen(exclusive mode without aero). Shouldn't the height resolution stay at 816? I mean something is stretching the picture apperantly.. I've got this issue for quite a time now. I changed the MPC-HC, LAV and MadVR version without a change, that's why I can't narrow it down to where the problem is...

The image just gets moved to the center, so it starts at pixel 132 and goes to pixel 948 ---> 948-132 = 816 pixels high.

[trip_let]

The image just gets moved to the center, so it starts at pixel 132 and goes to pixel 948 ---> 948-132 = 816 pixels high.

Yeah, I thought it could've been a question about pixels counted inclusively (height of 948 through 132 being 817 rather than 816 pixels), but that's apparently not how it works.

After all, it reports 0,0,1920,1080 for straight-up 16:9 material on 1080p screens. That's not 1921 and 1081 pixels. The box is defined by the start and end positions I guess.

[cyberbeing]

Performance with Direct Compute build 4 is slightly slower, but still faster than build 1.

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.

The build 3 error diffusion also has a couple R0-G1-B0 stray dots , but they are elminated with the shader only set to 0.2 / 255.0. Oddly the number of stray dots on black actually were higher with the shader set to 0.1 vs disabled.

Completely disabled dither produced a solid black with the 3DLUT.

[Skwelcha]

ah, so there isn't a problem at all... good to know, thx :)

[Dogway]

I lost image after version 0.86.9 on Techsmith codec videos. I use Intel HD 4600 on XP, on 7 it works fine. I'm waiting for a new dedicated card but thought you should know this.

Just making sure you didn't overlook the post, since this evening I will be installing the Quadro and forget about this.

[James Freeman]

Anyone who have problems with 3DLUT elevated blacks, blue whites, dithered blacks...
I have posted in AVS Forums (what in my experience) a solution.

ArgyllCMS - MadVR (3DLUT) (http://www.avsforum.com/t/1471169/madvr-argyllcms/1440#post_24320182)

I'm a happy camper now, with perfect colors and calibration curve.
Yes, 3DLUT & madVRdirectCompute4 with no noise in the blacks and perfect color and gamma.

[Shiandow]

Worms be gone! madVRdirectCompute4 looks great.

Build 3 Error diffusion (http://s29.postimg.org/574qdk4uv/ED_0s.png)
Build 4 Error diffusion (http://s30.postimg.org/wlixyzfdt/ED_NEW.png)

Mabe 6233638s problem is that his 3DLUT is raising the image black level from ex 0.000 to 0.001 in a 0-255(8-bit) integer and madvr tries to dither the raised black level. Or mabe its just a bug... :confused:

To me the build 4 version seems a bit more 'noisy'. This becomes a bit more obvious if you look at a blurred version of the same image. I'm not sure if this is a realistic way of measuring how noisy it looks to the human eye, but it's the best I can think of.

This is the result of adding a Gaussian blur with a radius of 2 pixels:

Build 3 Error diffusion blurred (http://i.imgur.com/KLJDlLF.png)

Build 4 Error diffusion blurred (http://i.imgur.com/V1AfTjx.png)

[wolfman2791]

As a noob, i will ask a noob question :D

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. As a result, i'm running these settings because it's the most my computer can handle:

- Chroma upscaling = Jinc 3AR
- Image doubling = Luma doubling - NNED13 32 Neurons set to "always on" AND Luma quadrupling - NNED13 32 Neurons set to 3x
- Image upscaling = Lanzcos 2 AR LL
- Image downscaling = CR AR LL
- Smooth motion on if there's judder
- Nothing checked in the "improve performance by reducing quality" page

With this, a 720p anime upscaled to 1080p fullscreen renders at 36ms lol. I don't lose frames or get any delayed frames though.

Are these the settings you recommend? If not, what would you recommend?

[fairchild]

- Chroma upscaling = Jinc 3AR
- Image doubling = Luma doubling - NNED13 32 Neurons set to "always on" AND Luma quadrupling - NNED13 32 Neurons set to 3x
- Image upscaling = Lanzcos 2 AR LL
- Image downscaling = CR AR LL
- Smooth motion on if there's judder
- Nothing checked in the "improve performance by reducing quality" page

The following is what I run on my AMD 7870:

- Chroma upscaling = NNEDI3 32 neurons
- Image doubling = Luma doubling - NNEDI3 64 Neurons set to "if scaling 2.0x or higher" (all other NNEDI3 disabled)
- Image upscaling = Lanczos3 AR
- Image downscaling = camtull-rom AR+LL
- Smooth motion disabled
- Nothing checked in the "improve performance by reducing quality" page

The doubling is set like that on purpose to make it so 720p and down is not doubled, as this would cause the image downscaling to kick in and cause even more stress on the graphics card and cause the rendering times to increase for a very marginal gain. I think Lanczos3 AR or Jinc3 AR is sufficient to image upscale from 1280x720 to 1920x1080

[iSunrise]

Worms be gone! madVRdirectCompute4 looks great.

Build 3 Error diffusion (http://s29.postimg.org/574qdk4uv/ED_0s.png)
Build 4 Error diffusion (http://s30.postimg.org/wlixyzfdt/ED_NEW.png)

Mabe 6233638s problem is that his 3DLUT is raising the image black level from ex 0.000 to 0.001 in a 0-255(8-bit) integer and madvr tries to dither the raised black level. Or mabe its just a bug... :confused:
I´m interested, how does madshi´s new implementation compare to your floyd_96.png image?

That´s probably also a good question for madshi, though.

Okay, but why does this occur when the video is paused, and how is it related to the CTRL+J OSD stats?

If the CTRL+J OSD is disabled + NNEDI3 enabled and I pause the video, CPU usage is less than 1% and my computer is silent.

If the CTRL+J OSD is enabled + NNEDI3 disabled and I pause the video, CPU usage is less than 1% and my computer is silent.

If the CTRL+J OSD is enabled + NNEDI3 enabled and I pause the video, CPU usage is ~10-15% and causes a my computer to make a rather annoying noise like power usage is fluctuating up and down in an unstable fashion. Since this is a quad-core without HT, it seems likely it's bouncing between 0% load and 100% load in short intervals.
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.

However, I also can hear my CPU fan dialing up for about 1-2 seconds, which seems to indicate short fluctuations, but I cannot verify that with the task manager.

I tested this with the release 0.87.4 build and also DirectCompute3 and DirectCompute4, neither behave like you describe. I´m on Windows 7 x64 with a GTX580 and 327.23 drivers.

Here's a new test build, adding some randomness to Error Diffusion. The randomness is the same for every frame, so the patterns should not change for static content.

http://madshi.net/madVRdirectCompute4.rar

Please give it a try and let me know:

(1) How much performance this costs.
(2) Whether it gets rid of the worm artifacts well enough.
(3) If the subjective noise level went up or not.
1) About the same as DirectCompute3, I would say a tiny bit slower (within some margin of error of about 1-2% GPU load depending on the clips I play and when I have smooth motion enabled, which should be the worst case)
2) It does.
3) It clearly went up. Also, the randomly appearing dots in the bars 17-18 don´t happen with the old implementation and I am not using a 3DLUT. I´m not sure if that´s supposed to happen, because of the randomness introduced. To really judge and compare your new implementation, though, a comparison picture like bacondither posted, would be helpful. It could very well be that even though noise went up, fine detail and definition went up with it, too. But since we´re all only comparing with bars here, it´s hard to say. Because there´s no apparent structure in them to really see if that´s transferable to real world pictures or other content. It´s still clearly a lot less noisy than the random dithering of course, because random dithering also adds these ugly colored noise artifacts.

Anyway, here are my comparisons (contrast enhanced):

DirectCompute 3 ED vs. DirectCompute 4 ED vs. Random Dither

http://abload.de/thumb/directcompute3_enhancd4jr1.png (http://abload.de/image.php?img=directcompute3_enhancd4jr1.png)http://abload.de/thumb/directcompute4_enhanc8xkq6.png (http://abload.de/image.php?img=directcompute4_enhanc8xkq6.png)http://abload.de/thumb/random_dither_enhancemskxn.png (http://abload.de/image.php?img=random_dither_enhancemskxn.png)

Bad news: Currently my DirectCompute NNEDI3 implementation is about 10 times slower than OpenCL. I'm not sure yet why. I'm trying to improve performance, but I'm not hopeful right now. It's very well possible (or rather probable at this point) that we'll have to stick with OpenCL for NNEDI3. So we probably do need that NVidia driver fix, after all...
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

[wolfman2791]

The following is what I run on my AMD 7870:

- Chroma upscaling = NNEDI3 32 neurons
- Image doubling = Luma doubling - NNEDI3 64 Neurons set to "if scaling 2.0x or higher" (all other NNEDI3 disabled)
- Image upscaling = Lanczos3 AR
- Image downscaling = camtull-rom AR+LL
- Smooth motion disabled
- Nothing checked in the "improve performance by reducing quality" page

The doubling is set like that on purpose to make it so 720p and down is not doubled, as this would cause the image downscaling to kick in and cause even more stress on the graphics card and cause the rendering times to increase for a very marginal gain. I think Lanczos3 AR or Jinc3 AR is sufficient to image upscale from 1280x720 to 1920x1080

Thanks dude. Makes sense.

How about the general settings in the rendering sections? What are your GPU and CPU queue sizes?

[kasper93]

- Chroma upscaling = NNEDI3 32 neurons
- Image doubling = Luma doubling - NNEDI3 64 Neurons set to "if scaling 2.0x or higher" (all other NNEDI3 disabled)
- Image upscaling = Lanczos3 AR
- Image downscaling = camtull-rom AR+LL
- Smooth motion disabled
- Nothing checked in the "improve performance by reducing quality" page

NNEDI3 is totally not worth for chroma upscaling.

And I don't get why you don't use such great feature as Smooth motion... Jinc3 AR for both Chroma and luma upscaling is ok. For chroma you may even go with Bicubic75....

[iSunrise]

NNEDI3 is totally not worth for chroma upscaling.
You mean NNEDI3 chroma doubling/quadrupling, as NNEDI3 4:2:2 -> 4:4:4 chroma upscaling definitely gives good improvements.

If he doesn´t have enough GPU performance, he should be fine with Lanczos 3 AR / Bicubic75 AR for chroma upscaling, indeed.

[fairchild]

Thanks dude. Makes sense.

How about the general settings in the rendering sections? What are your GPU and CPU queue sizes?

They are at the defaults (16 and 8), debanding off, and deinterlacing at defaults too.

NNEDI3 is totally not worth for chroma upscaling.

And I don't get why you don't use such great feature as Smooth motion... Jinc3 AR for both Chroma and luma upscaling is ok. For chroma you may even go with Bicubic75....

Other's are saying that NNEDI3 for chroma upscaling is better than any other scaler even at 16 neurons, since chroma always comes at half resolution and NNEDI3 is designed for doubling resolution so....

As for smooth motion, I don't use it since I have a display which provides a flicker free 96hz mode for 23/24p content and works great. Any 29p/30p content looks fine using the displays 60hz mode, so don't need smooth motion.

[bacondither]

iSunrise your test images are wonky... level 17 is clipped which should be visible and black is not black its dark grey.

@madshi
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.

Some megabrightened images to show the strange dither outside the target rectangle:

Error diffusion build4 (http://i.imgur.com/IFvDXC4.png?1)

Error diffusion build3 (http://i.imgur.com/Hn4enQb.png)

Random dither build4 (http://i.imgur.com/U3RsALu.png)

+added
A better image to illustrate the problem (http://i.imgur.com/revxF1K.png)

[wolfman2791]

Thanks dude. Without smooth motion, it runs at around 16ms which is great. Smooth motion bumps it up to 25ms, but i need it because my monitor can't handle everything... still much better than before and i understand the reasons for your choices too, which is great.

[TheElix]

No you don't.
If you can see the difference between 127 vs 128 PIXEL THIN lines of grey, you are inhuman.
Take the Color Picker tool in you soft and check what colors the 18 zigzag lines are made of (ED dithered), I'll tell you, its made of 2 & 3 (out of 255).
If you can see that with you naked eye... please contact the UN straight away because you may be trained as a pilot.I see the pattern in your first image. Or did you mean the original non-zoomed one?

Edit: Nvm, I figured it out later on. You're right, I can't see it on non-zoomed version.

[iSunrise]

iSunrise your test images are wonky... level 17 is clipped which should be visible and black is not black its dark grey.
They are taken directly from the AVS HD display calibration package (1-Black Clipping.mp4).

Like I wrote, too, they are all enhanced with the same settings (minimal gamma adjustment [which is why pure black isn´t really black] and some contrast enhancement) to better illustrate the results and make them a bit more visible. Otherwise it is extremely hard to see the single dots which are in the darkest blacks. They still are perfectly comparable with one another.

@madshi
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.

Some megabrightened images to show the strange dither outside the target rectangle:
That´s exactly what I meant with the dots (added noise). Your shots make them even more obvious.

[huhn]

Thanks dude. Without smooth motion, it runs at around 16ms which is great. Smooth motion bumps it up to 25ms, but i need it because my monitor can't handle everything... still much better than before and i understand the reasons for your choices too, which is great.

aktive this "use random dithering instead of opencl error diffusion"

SM + ED cost a lot but ED is not worth it to disable SM on 60 hz only screen.

with ED you gain little PQ for heavy cost, this should only be used on really fast gpu's. it's disabled on default and i think this is a good choice.

[XMonarchY]

That means your 3DLUT probably raises the black level. You could try using a custom pixel shader to lower the black level again to the right value. E.g. the following should lower the black level by 0.1 in 8bit:

sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, tex) - 0.1 / 255.0;
}
If this doesn't help, try 0.2 / 255.0, or even more until the problem goes away.



Sounds good!

I think the best fix for raised 3DLUT blacks is to use dispcalGUI's official black-level-fix feature (tri-color button in "Show Curves") that corrects ArgyllCMS dispcal.exe black level calibration rise and then use the fixed LUT.cal file to create a 3DLUT. You need to make sure to load the LUT.cal file to your display device (not madVR) first and only then set madVR as a display device. Then, untick "do not use videocard gamma table to apply calibration" before you start profiling to utilize that fixed LUT.cal properly. Profiling does not raise blacks if the LUT.cal file used is black-level-fixed.

I think its even a better idea to create a black-level-fixed LUT.cal file, use it for profile patch measures, but not include the LUT.cal (do not tick "Apply vcgt") during 3DLUT creation (do apply "BT.1886 gamma mapping" "2.4" "Absolute colorimetric with white point scaling"). Then load the generated 3DLUT, untick "disable GPU gamma ramps", and load the saved LUT.cal file with fixed blacks separately! It will make it more flexible as you can also create a different LUT.cal with a different gamma and switch between them to see which one you prefer without having to re-profile or make a different 3DLUT. It is also a good idea because LAV Video doesn't clip WTW and white clipping patterns may show yellow flashing bars when a LUT.cal file is fully integrated into 3DLUT.

[The 8472]

iSunrise your test images are wonky... level 17 is clipped which should be visible and black is not black its dark grey.

Like I wrote, too, they are all enhanced with the same settings (minimal gamma adjustment [which is why pure black isn´t really black] and some contrast enhancement) to better illustrate the results and make them a bit more visible. Otherwise it is extremely hard to see the single dots which are in the darkest blacks. They still are perfectly comparable with one another.

How to get more reproduceable resoluts when enhancing this kind of test image:


open in your favorite image editor
use the levels adjustment tool (should have a histogram view)
lock RGB channels together
pick 0-20 or so as source range, the histogram should help you to tell where the input levels stop being relevant
pick 0-255 as output range


Voila, you have expanded the input levels to the output levels without the non-linear effects of adjusting gamma or the like. For reproducibility you can mention the in/out ranges you picked, e.g. [0-20 -> 0-255] when you post them.

[XMonarchY]

Anyone who have problems with 3DLUT elevated blacks, blue whites, dithered blacks...
I have posted in AVS Forums (what in my experience) a solution.

ArgyllCMS - MadVR (3DLUT) (http://www.avsforum.com/t/1471169/madvr-argyllcms/1440#post_24320182)

I'm a happy camper now, with perfect colors and calibration curve.
Yes, 3DLUT & madVRdirectCompute4 with no noise in the blacks and perfect color and gamma.

Take a look at my latest reply - there an official fix in dispcalGUI for raised blacks and it existed for a while now. You can use it to get that proper BT.1886 2.4 absolute gamma and no raised blacks.

[DragonQ]

NNEDI3 is totally not worth for chroma upscaling.
Is it not still better if your GPU can do it without sacrificing other features?

And I don't get why you don't use such great feature as Smooth motion...
Not everyone needs it. It's extremely awesome for PC displays but usually not necessary for TVs.

[kasper93]

You mean NNEDI3 chroma doubling/quadrupling, as NNEDI3 4:2:2 -> 4:4:4 chroma upscaling definitely gives good improvements.
Is it not still better if your GPU can do it without sacrificing other features?

My point is that you don't notice chroma scaling quality that much. NNEDI3 is still heavy I just don't see a reason to push power consumption only for sake of it. Seriously guys we don't watch movies with magnifier in hand. And don't get me wrong, I'm the one who always pursuit the best possible quality, but we need to be reasonable at the same time and pick settings that we can actually see with our own eyes.

But I have to give you that if you can upscale both luma and chroma with NNEDI3 it's definitely what you want to do. (I missed that part of the post) Though keep in mind to balance your settings and luma upscaling is more noticeable then chroma :)

Not everyone needs it. It's extremely awesome for PC displays but usually not necessary for TVs.

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

[iSunrise]

How to get more reproduceable resoluts when enhancing this kind of test image:


open in your favorite image editor
use the levels adjustment tool (should have a histogram view)
lock RGB channels together
pick 0-20 or so as source range, the histogram should help you to tell where the input levels stop being relevant
pick 0-255 as output range


Voila, you have expanded the input levels to the output levels without the non-linear effects of adjusting gamma or the like. For reproducibility you can mention the in/out ranges you picked, e.g. [0-20 -> 0-255] when you post them.
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.

[ryrynz]

Worms be gone! madVRdirectCompute4 looks great.

Build 3 Error diffusion (http://s29.postimg.org/574qdk4uv/ED_0s.png)
Build 4 Error diffusion (http://s30.postimg.org/wlixyzfdt/ED_NEW.png)


I agree the patterns do look fairly good, but what's with all those lighter pixels, shouldn't it just be changing the pattern and not the color of the pixels? Most visible in 20 and 21.

[tp4tissue]

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..

[Shiandow]

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.

[mindbomb]

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.