madVR - high quality video renderer (GPU assisted)

[hannes69]

One question beside the dithering hype:
I now replaced my old AMD HD4550 by a R7 250. Formerly I used Powerstrip for custom resolutions to get judder free playback of 23,976 / 24.000 / 25,000 / 29,970 fps movies. Powerstrip doesn´t support the newer GPUs so I switched to the EDID override method used by CRU utility. Works like a charm, so I have the four different refresh rates for my new GPU (refresh rate = fps x 2 each because I´m feeding a projector which accepts refresh rates in the 30 - 60 Hz range). Now as a bonus i can use the madvr´s display switcher, works great too. No Powerstrip needed anymore, automatic switching. The custom resolutions are accurate enough for a judder free playback > 3h.
But there is one problem: In Windows the decimal numbers are truncated /rounded, so 48,000 and 47,952 Hz can´t be distinguished. It is not possible to keep both refresh rates side by side. I want to work with the display switcher and the accurate refresh rates, NOT with smoothmotion as workaround.
Does anybody know a solution for this problem? At the moment I´m working with 720p48 /720p50 /720p60 in the display switcher (720p projector!) by using the 47,952 setting for 720p48, so I can´t use the 48,000 setting, I hope you know what I mean... There must be a solution, is there no place where you can fool Windows with the names, e.g. in the registry?
A possible workaround would be to use 24,000 or 72,000, but my projector doesn´t accept refresh rates so low / so high.
Hope somebody has worked around this problem and can give me some assistance.
:)
Hannes.

[madshi]

Can smallramp.ytp be used as a reference point? Got a 6-bit panel(u2412)with afrc and I get the smoothest result by setting madvr in 8-bit,to see the difference with dithering off though I got to stick my face on the screen.
Yes, if you zoom smallramp.ytp up you can use it as a reference point, because upscaling turns the original 8bit ramp into a high bitdepth ramp. Just make sure you don't use DXVA scaling because that outputs 8bit with some GPUs (Intel).

So rather, what you've posted there is RGB <-> YPbPr (analog) according to Poynton, rather than YCbCr (digital).

Does that mean YPbPr is equivalent to full-range YCbCr, or rather that this matrix can only be used if full-range YCbCr is first converted to YPbPr?
I'm not sure if the matrixes are any different between YPbPr and YCbCr. I think the usual YCbCr matrixes are for video levels, that's probably the only reason they're different.

Hi madshi, I just tested the fix for the green tint and it seems to work! This is how the distribution of green/magenta pixels looks now: link (http://i.imgur.com/BQKoBWs.jpg).
Cool, looks almost like a fractal... :D

Interesting, 3bit + dynamic causes some significant pulsing. It becomes less perceivable with 4bit.

Is that some effect of not doing dithering it in perceptually uniform colors and thus the different perturbations created by dynamic actually not being interchangeable? I guess at higher bit-depths it works fine because the differences can be approximated as locally linear, especially if neighboring pixels have similar colors.
You haven't seen 2bit... ;) It's blinking like crazy there. I'm not sure about the exact reason, haven't analyzed it, but it's probably because of doing the dithering in gamma light.

Yes, the attached gamma ramps are applied to the GPU ramps even when using overlay mode. It would be very cool if madVR did leave the GPU ramps alone when in overlay mode. :)
Could you please create a bug tracker entry for this? Thanks.

madshi: You want bug reports about dither only builds in the bug tracker?
Yes, please. I'm currently looking through the bugs in the tracker and having all bugs listed there makes my life quite a bit easier, because I can then sort the bugs in groups. E.g. look at all multi-monitor bugs first, then all NVidia-only bugs etc...

Also another issue has popped up with overlay, there is no screen in mpc-be or potplayer when the window is not maximized.
No screen? Don't know what you mean.

There's also always been video artifacts maximizing with overlay mode. It places the non-maximized window inside of the maximized window at the upper-left part of the screen for about 500ms. I can't figure out a way to show the issue, print screen and screen capping result in a blank overlay window.
Overlay mode does have some cosmetical issues when resizing. That is currently considered "by design". I don't think I can fix this, but I haven't tied too hard. And I won't in the near future. Cosmetical issues are very very low priority for now.

There is a slight issue with LAV Video decoder in that it doesn't clip WTW levels
The decoder is not supposed to clip anything! If other decoders clip I consider that a bug.

when you use 0-255 setting in madVR with a 16-235 ArgyllCMS 3DLUT to run white clipping pattern - you get yellow flashing bars.
The usual approach is to calibrate your display so that BTB and WTW are not visible. If you do that, there should be no yellow flashing bars.

This is procuding a lot of glitches here.

Btw: Error diffusion in general is causing dropped frames and presentation glitches with 1080p60 video in FSE. GPU is not well utilized.
Are you using the official v0.87.4 build or one of the recent test builds? The official v0.87.4 build still uses OpenCL to do error diffusion. The latest test builds use DirectCompute instead, which seems to work better for both AMD and NVidia GPUs. About glitches: Have you tried increasing the number of pre-presented frames, as I suggested earlier? If that doesn't work, then I don't know what else to do. As I said before, glitches are a problem between Direct3D and the GPU driver, so it's mostly out of my control.

[*Touche*]

I downloaded your images and checked again comparing using xnview and yes I can see the colored dithering screenshot has the VT50 delivering darker blacks in the darkest areas (the corners) of the image.

Yes, it's mostly visible in the corners, but it is the opposite on my ST60, colored one is brighter. :confused:

[bacondither]

You haven't seen 2bit... ;) It's blinking like crazy there. I'm not sure about the exact reason, haven't analyzed it, but it's probably because of doing the dithering in gamma light.

The video is flickering because a mismatch of video framerate and display framerate. I see flickering in 3bit mode too, but only with video that have a mismatched framerate to my display.

[6233638]

Is it normal that activating colored noise increases black levels or should that have been fixed?I'm seeing this as well, even without using a 3DLUT.
Mono Ordered Dither displays black correctly, Colored Ordered Dither shows some noise on black.

When using 3DLUTs, Mono dither does not show any noise with the Error Diffusion options, but does show noise on black with Colored noise.

You haven't seen 2bit... ;) It's blinking like crazy there. I'm not sure about the exact reason, haven't analyzed it, but it's probably because of doing the dithering in gamma light.I thought it might simply be due to the fact that there are so few colors, but I wonder if there might be a solution for this?

[madshi]

The video is flickering because a mismatch of video framerate and display framerate. I see flickering in 3bit mode too, but only with video that have a mismatched framerate to my display.
You're right! Playing a video with matching framerates gets totally rid of the flickering, even in 2bit and 1bit.

I'm seeing this as well, even without using a 3DLUT.
Mono Ordered Dither displays black correctly, Colored Ordered Dither shows some noise on black.
Nope. I just tried that with a black BMP test image, and mono ordered dither has some noise on black, too. And it must have, if the colored ordered dither has, it makes no sense any other way. The colored option does not increase the amount of noise, it just changes the distribution pattern.

Please feel free to report this as a bug in the bug tracker. It's not really a bug, but I should be able to add a limiter which stops pixels from getting noise if they're truely black.

[James Freeman]

I should be able to add a limiter which stops pixels from getting noise if they're truely black.

Yes please.
I also heard you got some funky 2-bit version...;)


When using Static dithering at low bit depth the image appears brighter, but in dynamic mode the gamma appears correct.
You can pause the video in dynamic mode (too look like Static) and press the Up/Down arrow and keep holding (volume) to update the picture and look like Dynamic but paused.
You can remove the OSD (Ctrl+J) to stop the refreshing every second that the OSD is doing.

[bacondither]

One thing that is noticable is that the image is getting brighter the lower bit depth you dither to.

Linear light would help here as stated before, so i made some graphs to took at how much brighter or darker the image gets when converting a bt709 gamma encoded image to linear, using power functions.

Curves! (http://i.imgur.com/NhOkxGe.png)

If you are using a power function to decode gamma i think ~1.85 would be the best approximation, it gives an integral between 0(black) and 1(white) of ~1.01. Perfect linear gamma gives an integral of 1.

And the previous discussion about linear light was a bit misleading because the discussed images was near black and almost invisible if not enhanced.

[6233638]

Nope. I just tried that with a black BMP test image, and mono ordered dither has some noise on black, too. And it must have, if the colored ordered dither has, it makes no sense any other way. The colored option does not increase the amount of noise, it just changes the distribution pattern.

Please feel free to report this as a bug in the bug tracker. It's not really a bug, but I should be able to add a limiter which stops pixels from getting noise if they're truely black.Sorry, I need to find a better test for this. I was using the "Black Clipping" test again,and I thought I was looking at the same frames, but apparently not.

Because it's a video file, it seems that one image showed noise on black and the other did not. It just coincided with me toggling the "use colored noise" option.

Normally, there is some amount of noise on black, but not below-black, and with a 3DLUT I'm seeing noise on below-black values (which should be clipped) too.

Looks like it's back to Error Diffusion and the "This display is already calibrated" options for me, which at least eliminates the noise on black for now.

[James Freeman]

Normally, there is some amount of noise on black, but not below-black, and with a 3DLUT I'm seeing noise on below-black values (which should be clipped) too.
Yep, here too.
Try to turn up Contrast (and/or turning down Brightness) in MPC-HC to see it clearer.


Looks like it's back to Error Diffusion and the "This display is already calibrated" options for me, which at least eliminates the noise on black for now.
Are you the one with the plasma that does not dim the black area because of this?

[6233638]

Are you the one with the plasma that does not dim the black area because of this?It's a full-array local dimming LCD, but yes it prevents the zones turning off. They only dim to a very low level instead.

[James Freeman]

Reference Black should be completely black, 3DLUT or not, Dithering or not.

[iSunrise]

One thing that is noticable is that the image is getting brighter the lower bit depth you dither to.

Linear light would help here as stated before, so i made some graphs to took at how much brighter or darker the image gets when converting a bt709 gamma encoded image to linear, using power functions.

Curves! (http://i.imgur.com/NhOkxGe.png)

If you are using a power function to decode gamma i think ~1.85 would be the best approximation, it gives an integral between 0(black) and 1(white) of ~1.01. Perfect linear gamma gives an integral of 1.

And the previous discussion about linear light was a bit misleading because the discussed images was near black and almost invisible if not enhanced.
Yes, like I said, we should try linear light again. Because some of the anomalies we see may not happen at all with LL. We dismissed LL way too early, because we just judged it by using some pre-defined power function that wasn´t necessarily "correct".

Still, we have to keep in mind that it´s a "half-hack" (like madshi already stated), because we would only need it for the final conversion anyway, not further processing.

Also, if we had access to a 2bit/1bit mode, too, we would be able to analyse this even better. When we analysed LL last time, we didn´t even have something like the 4bit mode "hack".

[kasper93]

Recently I've been using SomeImage (http://someimage.com/), as it allows images up to 15MB in size and hotlinking.

imgbox (http://imgbox.com/) is rock solid, I use it for years and it has everything you need from image hosting site.

[Shiandow]

The 'blinking' seems to be caused by performing smooth motion in linear light, and dithering the result in gamma light. If you either stop smooth motion or perform the blending in gamma light then the blinking stops. So if you want to solve the 'blinking' then dithering and smooth motion should both use the same linear light conversion (or none at all).

[madshi]

FWIW, I'm getting blinking here without smooth motion frc, too, if the framerates don't match.

Anyway, linear light error diffusion has serious algorithm problems. Without a limiter it should work, but it would increase noise quite noticeably. I don't plan to try linear light error diffusion again at moment.

[The 8472]

You're right! Playing a video with matching framerates gets totally rid of the flickering, even in 2bit and 1bit. Shouldn't SM fix this? It was enabled.

Edit: nvm, i should finish reading the thread before replying

[bacondither]

@madshi

Why is reference white dithered with error diffusion?.
There should be no error to spread to neighbour pixels. All testing is done in 8-bit output in madvr. No shaders, debanding or 3dlut is active.

Disabling colored noise or "dynamic dither" made no difference.
All images are contrast enhanced.

White clipping - ED1 (http://i.imgur.com/y645yon.png)

White clipping - ED2 (http://i.imgur.com/9sT3z6a.png)

White clipping - Random (http://i.imgur.com/4zAodX8.png)

I created a pure white image with RGB 255 on all pixels and with random dithering after contrast enhancment the image is white. With both ED modes it shows dither snow after enhancement, it should show all white!

RGB 255 - Random dithering. (http://i.imgur.com/N4s9olo.png)

RGB 255 - Error diffusion. (http://i.imgur.com/laIQf0A.png)

It is a minor issue but i dont understand why ED is dithering pure white. :confused:

[James Freeman]

@madshi
It is a minor issue but i dont understand why ED is dithering pure white. :confused:

And pure Black.


madshi,
Its already in the Bug Tracker by 6233638.
If you think its appropriate, do the same Limiting procedure to the whites.

[madshi]

Why is reference white dithered with error diffusion?
I don't know. Can you please add this to the bug tracker? Thx.

P.S: Yes, black is already in the bug tracker, but this might be a different issue, I don't know.

[bacondither]

And pure Black.


madshi,
Its already in the Bug Tracker by 6233638.
If you think its appropriate, do the same Limiting procedure to the whites.

No, error diffusion shows no noise on black. Black image with histogram clipped at 1 with ED-1.

RGB 0 - ED1 (http://i.imgur.com/ZotkuLm.png)

[James Freeman]

@bacondither

I can't reproduce this.
Everything is fine here: ED Whites (http://www.mediafire.com/convkey/b795/ni7lygnl5rv6p4tfg.jpg)

Are you sure you disabled all the post processing?


@madshi
I can see dithering on pure white with 3DLUT enabled.
This time it is the same problem as 6233638 posted about Blacks but on pure Whites.
Still, if you think its appropriate, do the same Limiting procedure to the whites.

[bacondither]

@bacondither

I can't reproduce this.
Everything is fine here: ED Whites (http://www.mediafire.com/convkey/b795/ni7lygnl5rv6p4tfg.jpg)

Are you sure you disabled all the post processing?

Yes, quadruple checked.

Can you upload a non modified image?

Did you take a screenshot or did you file->save image ?

[James Freeman]

Can you upload a non modified image?

White ED1 Untouched (http://www.mediafire.com/convkey/0bb9/73guf9yy914b1vbfg.jpg)
White ED1 Untouched 2 (http://www.mediafire.com/convkey/1b4c/58mux07lhksjm8ufg.jpg)

Maybe an upscaler?

Did you take a screenshot or did you file->save image ?
Screenshot of course.
*I'm not new to this.

[bacondither]

If i do file -> save image then i get no dithered whites. :confused:

Tried it on another display (1080p) no scaling and i still get dithered whites.

[nevcairiel]

If i do file -> save image then i get no dithered whites. :confused:

That uses a special way to extract the image, always use PrintScreen to get the same thing madVR renders on the screen.

[James Freeman]

Try: restore default settings.bat

[bacondither]

No difference.
I'm going to try another partion with with a fresh install of windows and different drivers just to check.

[James Freeman]

What about decoder settings? Check LAV Video Filter, Make sure everything is at default.

[bacondither]

Lav is default and is outputting video untouched.

Tried with catalyst 14.2 beta, same problem.

[James Freeman]

Try using "None" for Hardware Decoder in LAV.
Uncheck everything in MadVR Quality for Performance Settings

Can anyone upload an Untouched image to triple check it?

[bacondither]

Maybe it could be some difference in how Nvidia or AMD does math in pixel shaders or direct compute?

ED2 dither.

White clipping untouched (http://i.imgur.com/e90uHop.png)

[James Freeman]

Maybe it could be some difference in how Nvidia or AMD does math in pixel shaders or direct compute?

ED2 dither.
White clipping untouched (http://i.imgur.com/e90uHop.png)

Maybe,
That's why I wanted another AMD user to post an untouched image (not you bacon).
Till then I'm out of suggestions, sorry.

Yes, the dithering is already there in your image.

P.S
From your first images, I can see some sharpening Pixel Shader.
There should be no borders around the stripe in the clipped whites, which is clearly visible in your shots.
Also white border around the black letters, which I don't have in my enhanced images.

[cyberbeing]

Maybe it could be some difference in how Nvidia or AMD does math in pixel shaders or direct compute?
Have you triple checked your driver settings? Later today I'll check on my HD5770 if no one else confirms this issue only affects AMD before then.

No issue on NVIDIA at least with ED:
White clipping untouched (NVIDIA) (http://i1.someimage.com/zTZ6RbA.png)

[bacondither]

Maybe,
P.S
From your first images, I can see some sharpening Pixel Shader.
There should be no borders around the stripe in the clipped whites, which is clearly visible in your shots.
Also white border around the black letters, which I don't have in my enhanced images.

No no no. My first image was downscaled by madvr with lanczos3 anti ringing, no pixel shader.

[James Freeman]

Oh, Ok.

[bacondither]

With random dithering everything is fine. No dithering of reference white.
The image is untouched and not scaled.

White clipping untouched random (http://i.imgur.com/hMfWWap.png)

[MistahBonzai]

Later today I'll check on my HD5770 if no one else confirms this issue only affects AMD before then...

No issue on AMD (HD-7850):
White clipping untouched (https://www.mediafire.com/?3jgkest19m3omkz) (AMD HD-7850)

^The above image was using OD - No colored noise but dynamic.
The following image was set to ED option 2, colored noise, dynamic.

No issue on AMD (HD-7850):
White clipping untouched (http://www.mediafire.com/view/i5hm5o3l7wwa6z4/Image2.png) (AMD HD-7850)

[James Freeman]

MistahBonzai,
I can see some grey noise there, not pure white like in the Nvidia images.
Please repost this image with ED2, both dithering options checked, and without up/down scaling.

[bacondither]

No issue on AMD (HD-7850):
White clipping untouched (AMD HD-7850) (https://www.mediafire.com/?3jgkest19m3omkz)

You are using ordered dithering, please change to Error Diffusion - Option 1 or 2 and post the images again. :)

And you do have dithering on reference white with ordered dithering.

[James Freeman]

Thanks MistahBonzai.
Yep, its an AMD issue with Direct Compute, the last step of pure white is dithered.



@Madshi
One step before pure white looks fine.
Can you kill two birds with one stone...

[madshi]

FWIW, I can reproduce the noise on white clipping here.

[bacondither]

FWIW, I can reproduce the noise on white clipping here.
Are you using a AMD or NVIDIA gpu?

[madshi]

AMD, but I have a hard time believing that it would be GPU specific. Anyway, doesn't matter, as long as I can reproduce it.

[MistahBonzai]

Please repost this image with ED2, both dithering options checked, and without up/down scaling.

OK..hopefully this image is captured as requested:

ED(option 2), dynamic and colored.
Trade quality for performance = unchecked.
Jinc upscaling.
Catmull-ROM (AR and LL enabled) downscaling.
No MadVR "Processing".
ffdshow off - no external processing connected.

HD-7850 (http://www.mediafire.com/view/j1u560i0mevfura/Image3.png)

[XMonarchY]

madshi

My TV is set to 0-255 in drivers (using your NVidia 0-255 tool and verifying it) and in TV settings. It is also properly calibrated. I was in close contact with dispcalGUI developer, Fhoech, who did confirm that the issue is that WTW levels are not clipped by LAV Video decoder. When ffdshow is used instead of LAV Video - all is fine and peachy. Fhoech created a workaround for LAV Video decoder users - he allowed to create 3DLUTs with 16-235 input but 0-255 output in dispcalGUI 3DLUT generator. Such a 3DLUT will only work properly if madVR is set to 16-235. This does work, but I don't know what will happen if you use a true 0-255 source... This isn't really a bug, its just how it is. LAV Video does not clip WTW for a reason, and madVR is working how it should, so does ArgyllCMS/dispcalGUI when using either 16-235 output or 0-255 output for 3DLUTs. This has nothing to do with my TV, settings, or calibration. I never even ran across a true 0-255 source before, so I don't know what would happen... Maybe someone can link me to a legit 0-255 clip?

[XMonarchY]

What is the current consensus on the use of ED during madTPG pattern generation? I do not get a frozen black screen like some report - it works for me. Yet, some say that ED will make readings inaccurate. I do recall ArgyllCMS developer stating that random dithering should be used and not static images... Is that still true?

[madshi]

My TV is set to 0-255 in drivers (using your NVidia 0-255 tool and verifying it) and in TV settings. It is also properly calibrated. I was in close contact with dispcalGUI developer, Fhoech, who did confirm that the issue is that WTW levels are not clipped by LAV Video decoder. When ffdshow is used instead of LAV Video - all is fine and peachy. Fhoech created a workaround for LAV Video decoder users - he allowed to create 3DLUTs with 16-235 input but 0-255 output in dispcalGUI 3DLUT generator. Such a 3DLUT will only work properly if madVR is set to 16-235. This does work, but I don't know what will happen if you use a true 0-255 source... This isn't really a bug, its just how it is. LAV Video does not clip WTW for a reason, and madVR is working how it should, so does ArgyllCMS/dispcalGUI when using either 16-235 output or 0-255 output for 3DLUTs. This has nothing to do with my TV, settings, or calibration. I never even ran across a true 0-255 source before, so I don't know what would happen... Maybe someone can link me to a legit 0-255 clip?
I'm not sure what Fhoech and you talked about, but what you ended up doing is very wrong.

(1) A video decoder MUST NOT clip anything. So LAV does it correctly. And if your report is true then ffdshow is buggy.

(2) madVR requires 3dluts to have video level input and output. So creating a 0-255 output 3dlut is all wrong.

(3) If you configure madVR to output 0-255 then BTB and WTW are clipped by madVR. So I can only guess that you had set madVR to 16-235 output (which is not correct if you set your display to 0-255), or that your original 3dlut was buggy.

What is the current consensus on the use of ED during madTPG pattern generation?
The next official madVR builds will always use ordered dithering for madTPG, regardless of which settings you're using in madVR.

[cyberbeing]

AMD, but I have a hard time believing that it would be GPU specific. Anyway, doesn't matter, as long as I can reproduce it.

I can confirm this issue also occurs on my ATI HD5750 (http://i1.someimage.com/WFgqtP2.png) with old crusty Catalyst 13.2 drivers using madVRfinalDither4, so it's certainly looking to be something GPU specific. Someone should probably check if they can reproduce this issue on an Intel Ivy|Haswell iGPU. For all we know, NVIDIA being unaffected could be a bug in itself. I'd be curious what the underlying cause is, once you track it down.

[seiyafan]

Ok, 270x is here, but when I enter full screen mode MPC would just froze, what's the issue here?