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]

Originally Posted by Damien147

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

Originally Posted by cyberbeing

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.

Originally Posted by Shiandow

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.

Cool, looks almost like a fractal...

Originally Posted by The 8472

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.

Originally Posted by Asmodian

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.

Originally Posted by turbojet

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

Originally Posted by turbojet

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.

Originally Posted by turbojet

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.

Originally Posted by XMonarchY

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.

Originally Posted by XMonarchY

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.

Originally Posted by aufkrawall

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*]

Originally Posted by ryrynz

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.

[bacondither]

Originally Posted by madshi

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]

Originally Posted by *Touche*

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.

Originally Posted by madshi

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]

Originally Posted by bacondither

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.

Originally Posted by 6233638

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]

Originally Posted by madshi

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!

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]

Originally Posted by madshi

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]

Originally Posted by 6233638

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.

Originally Posted by 6233638

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]

Originally Posted by James Freeman

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]

Originally Posted by 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!

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]

Originally Posted by cyberbeing

Recently I've been using SomeImage, as it allows images up to 15MB in size and hotlinking.

imgbox 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]

Originally Posted by madshi

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

White clipping - ED2

White clipping - Random

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.

RGB 255 - Error diffusion.

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

[James Freeman]

Originally Posted by bacondither

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

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]

Originally Posted by bacondither

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.