madVR 10-bit Display Support Test [Archive]

James Freeman

11th May 2015, 19:42

10-bit Display Support Test

This test will make it easier to see if your display actually supports 10bit input to output.
We already know that D3D11 + FSE in madVR will output a 10bit signal in windows 7 and up.
Now we just need to provide a super smooth black to white test pattern to clearly be able to see with our eyes.

First download 16bit PNG test patterns from here: http://www.bealecorner.org/red/test-patterns/Gradient-16bit.png
I also attached this PNG (zipped) at the bottom in case the URL disappears.
Open a new MPC-HC (or other player) window and drag the test pattern to the MPC-HC window.
Make sure RGB48 is enabled in LAV Video Decoder.

Adjust madVR settings as follows:
display->properties->10bit
display->calibration->disable & disable GPU gamma ramp.
rendering-> general-> Direct3D 11 ON
rendering->dithering->none
rendering->general->automatic exclusive fullscreen mode (FSE)-> off (for now).
Aero in Windows should be On.

When Dithering is Off the resulting output image will be a gradient in the bitdepth you set under properties.
You can switch between bit depths and dithering on/off to see what I mean, and then go back to 10bit dithering-off to continue the test.

Now go fullscreen without FSE (windowed fullscreen) to see the 8bit banding which should be visible because there are only 256 gradients from black to white.
This is because the GPU is still sending the image in 8bit to the display in this mode, even though we selected 10bit in madVR.
You may have to move closer to the display to actually see the gradients.

True 10bit output from your GPU needs FSE mode to work.
Now switch FSE On and go fullscreen again, now the GPU actually sends 10bit image to the display, and if your display supports 10bit input, you should now see 1024 gradients from black to white.
These gradients are 4 times narrower compared to 8bit and are practically indiscernible (to me).
In other words, you should NOT see any gradients.

If you still see the 8bit gradients even though the GPU sends 10bit to your display in FSE+D3D11 mode (check with Ctrl+J), your display does not support 10bit.

Important note for AMD users:

AMD cards dither the output by default, but you can disable it:

Check the Catalyst Control Center under "Information" -> "Software" to get the 2D driver path. Then run regedit.exe and open that path in the left pane.
You should see values in the right pane like "AdapterDesc" and a bunch of settings.
Add a DWORD value named TMDS_DisableDither (for DVI), DP_DisableDither (for DisplayPort), HDMI_DisableDither (for HDMI) with a value of 1. Reboot after.

Only that can explain why I see a difference between 8 and 10 bit output on my 6-bit DELL U2212HM connected with DVI

Note for NVIDIA users:

Since driver version 353.06 users can select bit depth in the Nvidia Control Panel on all systems.
If you can't see 10bit option in the CP, Nvidia will dither down to the bit depth selected if it is lower.

In other words, If you can't choose 10bit in nvidia CP and keep it on 8bit, when you run madVR in 10bit FSE, nvidia WILL Dither and you'll see smooth gradient, not true 10bit.
If you can select 10bit in Nvidia CP, the driver will NOT dither and sent true 10bit signal to your display.

Dell U2410 flickers and switches to 10bit mode and the image is smooth (first time seeing 10bit mode after owning this display for 5 years).

luk008

11th May 2015, 20:47

Disable GPU gamma ramp and disable dithering is only to proceed with test, right?

The requeriments to have 10 bit output are D3D11 + FSE + compatible GPU + compatible display?

nevcairiel

11th May 2015, 21:32

Unfortunately, the test isn't necessarily as reliable as one would hope. At least it may not tell you if your display can actually show 10-bit.

What happens for me, I tried this on both a screen known to have 10-bit support (also a U2410), as well as a screen I know which does not have 10-bit support - both connected over DP.
The result was that both screens showed a smooth gradient. Now I can only assume that the U2410 actually managed to show 10-bit, but what the other screen did, I'm not sure. Did it employ dithering? Does my GPU know that it doesn't take 10-bit, and does it dither? I don't know, and I don't know how to find out. :(

Obviously if you do see banding after the test, you do know that you should definitely stay away from 10-bit.

tickled_pink

11th May 2015, 21:44

The test seems to have worked for me. I noticed my TV flickered when it switched to 10-bit mode. Similar to how it flickers when switching between 50hz and 60hz. Could this be a tell tale sign that the TV in fact supports 10-bit?

Asmodian

11th May 2015, 21:53

No, it might flicker simply due to the GPU changing modes.

huhn

11th May 2015, 22:03

and don't forget nearly all TV support 10 or 12 bit input that doesn't tell us anything about the panel it self.
and using FSE with 10 bit doesn't mean 10 bit is outputted at all.

MS-DOS

11th May 2015, 22:14

To everyone:

AMD cards dither the output by default, but you can disable it:

http://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?pid=3314#pid3314

Check the Catalyst Control Center under "Information" -> "Software" to get the 2D driver path. Then run regedit.exe and open that path in the left pane. You should see values in the right pane like "AdapterDesc" and a bunch of settings. Add a DWORD value named TMDS_DisableDither (for DVI) or DP_DisableDither (for DisplayPort) with a value of 1
HDMI_DisableDither for HDMI. Reboot after.

Only that can explain why I see a difference between 8 and 10 bit output on my 6-bit DELL U2212HM connected with DVI :)

luk008

11th May 2015, 22:50

To everyone:

AMD cards dither the output by default, but you can disable it:

http://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?pid=3314#pid3314

HDMI_DisableDither for HDMI. Reboot after.

Only that can explain why I see a difference between 8 and 10 bit output on my 6-bit DELL U2212HM connected with DVI :)

Disabling AMD dithering I discovered that my TV is in fact 8 bits. I can see a smooth gradient with 10 bits when dithering is enabled. So should I still use 10 bits or just stay with 8?

Zachs

12th May 2015, 00:10

From memory when I tested this on over 10 monitors/TVs over half a year ago with MPDN, the link you use to your display makes a difference too (I.e. HDMI vs DVI vs analog). Some will even display corrupted image. Some works better when dx10 is used instead of dx11.

MS-DOS

12th May 2015, 00:13

Disabling AMD dithering I discovered that my TV is in fact 8 bits. I can see a smooth gradient with 10 bits when dithering is enabled. So should I still use 10 bits or just stay with 8?
I see no point in using 10 bit output in MadVR unless your monitor\TV supports 10 bit input. It will only decrease the overall image quality because of the need of two dithering steps, one by MadVR (16 -> 10) and another by the GPU (10 -> 8).

We disable dithering here just for test purposes. It should always be enabled when converting to a lower bit depth, otherwise you may see banding artifacts.

baii

12th May 2015, 00:20

tobindac

12th May 2015, 02:26

This gives me dithering on 8bit for some reason. The other video you had showed 8bit more choppy. Unless the other one had a bug and didn't really show 8bit but less.

tobindac

12th May 2015, 02:32

Ah nevermind, your idea on madvr thread about the sharpening filter was actually good. On this file it makes it much easier to see the lines ('artifact removal').

This monitor is hilarious. I can see no artifacts on 10bit exclusive.

I guess the assumption is something dithers it, but is it for sure?

bcec

12th May 2015, 04:07

baii

12th May 2015, 04:16

Thanks for the file. What is the proper way to use it? This is what I did (please tell me if I did something wrong):
- Loaded the file up in mpc-hc x64
- Enabled Dx11 and FSE in madvr.
- Switched madvr to 10-bit
- Disabled refresh rate switcher.
- Switched mpc-hc to full screen.
- Disabled dithering.

I still see banding. The display itself should be 10-bit (or 8-bit+frc) afaik, so I was expecting not to see any banding.

check crtl-J OSD, make sure it say RGB48LE, 16bit. If it is not, you need to check RGB48 in lav video decoder.

bcec

12th May 2015, 04:22

check crtl-J OSD, make sure it say RGB48LE, 16bit. If it is not, you need to check RGB48 in lav video decoder.

Thanks, that seems to be correct, it says RGB48LE, 16bit.

I noticed tho that madvr says: "full screen exclusive mode, new path" instead of "full screen exclusive mode, 10bit". Any ideas why?

James Freeman

12th May 2015, 04:44

All folks with AMD cards should redo the test with a small tweak noted in the first post.

MS-DOS pointed out that AND driver dithers the output when it outputs more than 8bit, so you may actually get dithered 8bit which looks like 10bit on ANY panel.
Nevciriel pointed that he gets a smooth ramp even with a known not 10bit panel, and MS-DOS pointed that his 6-bit DELL U2212HM is also smooth...
So all you AMD folks need to do a little registry work to test actual 10bit output and not dithered 8bit by AMD driver.

bcec

12th May 2015, 04:49

Thanks, that seems to be correct, it says RGB48LE, 16bit.

I noticed tho that madvr says: "full screen exclusive mode, new path" instead of "full screen exclusive mode, 10bit". Any ideas why?

aero was off. When on, it worked, thanks!

James Freeman

12th May 2015, 05:13

huhn

12th May 2015, 06:54

just to add my experiences.

i use a cheap Phillips TV it supports 12 bit input and is not chroma subsampling at all. the panel is clearly an 8 bit ips panel.

test picture set to video frame double size to see more banding.

FSE D3D11 10 bit
AMD set to 8 bit output no dither = clear high banding
AMD set to 10 bit output no dither= little banding
AMD set to 12 bit output no dither=little banding

8 bit window mode
no dither clear high banding
madVR dither=little banding

these dither "hacks" are set in the registry. without these hacks AMD set to 8 bit was still pretty good so the GPU can dither on is own with at least ok quality. but i will double check that later.

looks like my screen can use proper dithering

potomac

12th May 2015, 07:34

i saw difference from 8 to 10 bit (LG IPS235) because of amd dither :)

James Freeman

12th May 2015, 07:42

i saw difference from 8 to 10 bit (LG IPS235) because of amd dither :)

That's good to know.
To properly test the panel one should disable software/driver dithering completely.
AMD does dithering without the user knowledge or ability to control it in a user friendly way... pity.

ryrynz

12th May 2015, 07:53

I take it back.. it would help if I let the player go into FSE mode...

I can clearly see a difference with 10 bit output even on my 6 bit + FRC panel. There's definitely a benefit to enabling it even on my ~1000:1 U2412.
I can see a small difference between using 8 bit and 10 bit with dithering enabled, IMO 8 bit with dithering is superior to 10 bit with no dithering.. it's kinda close though.
I'd say it's likely most would stand to benefit from having it enabled.

James Freeman

12th May 2015, 07:58

ryrynz are you using AMD card?
If you are using Nvidia then the U2412 actually dithers the 10bit input to its native 6bit which is good!
If you are on AMD please refer to the first post and disable driver dithering via registry hack.

ryrynz

12th May 2015, 08:10

nah it's Intel HD4000, I'm testing out the plasma now.. have also found a madVR bug.

potomac

12th May 2015, 08:10

Morku

12th May 2015, 08:22

I have an HP ZR24w which should be 8-bit panel.
I made the test. If I understand right, I shouldn't notice any difference, right? But in my case, I see a difference. In window mode I can clearly see the vertikal lines. Also in windowed fullscreen, in FSE they disappear.
So I want to know... is that correctly?
I my logical thinking, I would stay at 10-bit, because it improves the gradient.

I have NVIDIA GTX480, No AMD...

ryrynz

12th May 2015, 08:50

I made the test. If I understand right, I shouldn't notice any difference, right?

Based on various user's experience that would not be right. Even 6 bit panels benefit from having 10 bit enabled, but the difference is of course easily visible when dithering is disabled.
When it's enabled it's a lot harder to see the benefit with (as James has pointed out) sub 1000:1 displays, but of course if you can see a benefit with dithering disabled then it's certainly there with dithering enabled.. So yes enable it if that's the case!

I my logical thinking, I would stay at 10-bit, because it improves the gradient.

Exactly.

tyto

12th May 2015, 08:59

Prolite B2475HDS clearly supports 10bit for who may be interested

Morku

12th May 2015, 09:13

@ryrynz
Thanks for pointing out :)

Just one more question. Should I left dithering option disabled for FSE? Or enable again (for the slightly improved placebo image quality)?
Or depends on the source material?

Of course, this question is just for FSE option relevant, because dithering enabled improves image quality for windowed mode.

nevcairiel

12th May 2015, 09:16

You should always enable dithering.

James Freeman

12th May 2015, 10:12

You should always enable dithering.

To add to that;

Dithering should always be in the last step, and preferable the better quality dithering should be used.
Also preferably, only one dithering stage should be applied for less noise.

If the display dithers 10bit input to its 6bit or 8bit panel (6/8+FRC) and madVR also dithers, you'll have two dithering stages with "noisier" image.

If the panel is 6bit it would be better to send 6bit and dithering from madVR.
If the panel is 8bit it would be better to send 8bit and dithering from madVR.
If the panel is 8bit+FRC (accepts 10bit input) it still would be better to send 8bit and dithering from madVR because madVR dithering is better quality than the mystery FRC inside the monitor.
If the panel is a true 10bit (like Dell U3014) it would be better to send 10bit and dithering from madVR for optimum performace.

To summarize;
It is better to use madVR 6bit + Dithering unless your panel is true 8bit.
It is better to use madVR 8bit + Dithering unless your panel is true 10bit.
If your panel is true 10bit (not 8+FRC) use 10bit + Dithering in madVR.

This is true for computer monitors with known native panel bit depth, TVs are a different story.

A lot of users will want to realize their display capability of 10bit, but the real question is whether it is worth the extra dithering from the display itself if it is not a true 10bit panel....

ryrynz

12th May 2015, 14:01

If the panel is 6bit it would be better to send 6bit and dithering from madVR.

Better? Selecting 6 bit + ED2 dithering (on my 6 bit panel) shows more grain through the whole smallramp picture, I don't see any ramps though, switching to 8+ bit does provide a much smoother picture however, which is "better" isn't it?

huhn

12th May 2015, 14:07

That's good to know.
To properly test the panel one should disable software/driver dithering completely.
AMD does dithering without the user knowledge or ability to control it in a user friendly way... pity.

you have full control of the output bit deep and AMD is just dithering to that bit deep you selected what do you want more.

it's simply the correct way to do things.

James Freeman

12th May 2015, 14:19

ryrynz,
Try ordered dithering with change every frame but turn off colored noise, this is more or less what FRC does according to Wikipedia.
BUT, make sure you use the Grey Ramp test pattern from "madTestPatternSource" (smallramp.ytp) because with a static image the dithering pattern will not "change every frame" because there is none.

you have full control of the output bit deep and AMD is just dithering to that bit deep you selected what do you want more.
it's simply the correct way to do things.

You are right, I sometimes use the nvidia control panel Contrast, Brightness, Gamma, Color controls to lower my display brightness (its already on "0" in the display),
I would love to have dithering after that by the driver like AMD does because I see terrible banding on a grey scale.
Nvidia does its color adjustment processing in control panel in 8bit without dithering.

But I also would not want to apply two or three dithering stages without knowing.
MadVR dithering + AMD dithering + 8bit+FRC display = 3 stage dithering which can be easily turned on unknowingly.

MS-DOS

12th May 2015, 14:48

AMD set to 8 bit output no dither = clear high banding
AMD set to 10 bit output no dither= little banding
AMD set to 12 bit output no dither=little banding

When you change output bit depth in CCC, does your screen fade black like it does when switching refresh rates?

I have an HP ZR24w which should be 8-bit panel.
I my logical thinking, I would stay at 10-bit, because it improves the gradient.

Yes it has a 8 bit panel, but without FRC. So, no, in your case it doesn't.

If the panel is 6bit it would be better to send 6bit and dithering from madVR.
If the panel is 8bit it would be better to send 8bit and dithering from madVR.
If the panel is 8bit+FRC (accepts 10bit input) it still would be better to send 8bit and dithering from madVR because madVR dithering is better quality than the mystery FRC inside the monitor.
If the panel is a true 10bit (like Dell U3014) it would be better to send 10bit and dithering from madVR for optimum performace.

To summarize;
It is better to use madVR 6bit + Dithering unless your panel is true 8bit.
It is better to use madVR 8bit + Dithering unless your panel is true 10bit.
If your panel is true 10bit (not 8+FRC) use 10bit + Dithering in madVR.

I'm not so sure about 6\8 bit + FRC, though. Advanced framerate control works different from normal dithering

Dithering and Frame Rate Control (FRC) relate to the colour depth of a monitor panel and are technologies used to boost the colours which the matrix can display. For instance TN Film screens are traditionally more economical than other technologies when it comes to colour depth. In fact, they only display 64 red, 64 blue and 64 true green shades by default through pixel rotations. The maximum amount of colours achievable from liquid crystal rotation alone is 262,144. In order to reach 16 million colours and above, panel manufacturers commonly use two technologies: Dithering and Frame Rate Control (FRC). These terms are often interchanged, but strictly can mean different things.

Spatial Dithering - This dithering method involves assigning appropriate colour values from the available colour palette to close-by pixels in such a way that it gives the impression of a new colour tone which otherwise could not have been created at all. In doing so, there complex mappings according to which the ground colours are mutually assigned, otherwise it could result in colour noise / dithering noise. Dithering can be used to allow 6-Bit panels, like TN Film, to show 16.2 million perceived colours. This can however sometimes be detectable to the user, and can result in chessboard like patterns being visible in some cases. Spatial dithering is rarely used in the modern market and instead Frame Rate Control is more widely utilised.

Frame Rate Control / Temporal Dithering - The other method is Frame-Rate-Control (FRC), also referred to sometimes as temporal dithering. This works by combining four colour frames as a sequence in time, resulting in perceived mixture. In basic terms, it involves flashing between two colour tones rapidly to give the impression of a third tone, not normally available in the palette. This allows a total of 16.2 reproducible million colours in 6-bit TN Film matrices. FRC is also used to enhance the colour depth of 8-bit panels, boosting them from their standard 16.7 million colours to 1.07 billion in the case of "10-bit" panels (8-bit + FRC). There are a number of FRC algorithms which vary in their effectiveness. Sometimes, a twinkling artefact can be seen, particularly in darker shades, which is a side affect of such technologies.

My U2212HM is 6 bit + FRC and outputting 6 bit with MadVR only adds more noise comparing to 8.

noee

12th May 2015, 14:49

....
But I also would not want to apply two or three dithering stages without knowing.
MadVR dithering + AMD dithering + 8bit+FRC display = 3 stage dithering which can be easily turned on unknowingly.

That's exactly what I'm doing. My secondary monitor is only used for VIdeo and is 8bit-FRC, so I disable the AMD dither and set madVR to 10bit and go from there.

huhn

12th May 2015, 14:50

When you change output bit depth in CCC, does your screen fade black like it does when switching refresh rates?

yes it does.

and going to FSE 10 bit mode take a very long time.

ryrynz

12th May 2015, 14:59

ryrynz,
Try ordered dithering with change every frame but turn off colored noise, this is more or less what FRC does according to Wikipedia.
BUT, make sure you use the Grey Ramp test pattern from "madTestPatternSource" (smallramp.ytp) because with a static image the dithering pattern will not "change every frame" because there is none.

Tried it, though I am face up within two feet of the screen with the lights turned off but I can quite easily see the patches of dither areas in 6 bit with OD (with CN disabled and CEF enabled as you mentioned)
So your assumptions don't really hold true here.

and going to FSE 10 bit mode take a very long time.

It takes some time for sure.

Yes it has a 8 bit panel, but without FRC. So, no, in your case it doesn't.

I would rather him say if it did or not to be sure, it looks like actual results seem to fly in the face of theory.

My U2212HM is 6 bit + FRC and outputting 6 bit with MadVR only adds more noise comparing to 8.

Same here.

feelingblue

12th May 2015, 15:06

Excuse me, but in the driver panel we must flag 10bit or not?

With EDID my video driver automatically sets YCbCr444 10bit
i think that this maybe a way to understand if the panel support 10bit

there is a way to read edid info?

a similar tool is reliable?
http://developer.amd.com/tools-and-sdks/graphics-development/amd-edid-utility/

huhn

12th May 2015, 15:13

Excuse me, but in the driver panel we must flag 10bit or not?

With EDID my video driver automatically sets YCbCr444 10bit
i think that this maybe a way to understand if the panel support 10bit

there is a way to read edid info?
the EDID doesn't tell you at all if your panel is 10 bit you only learn if your Tv support high bit deep input that's all and nearly all support 12 bit input.

AMD uses by default 10 bit if possible and YCbCr. if you select 8 bit in the AMD driver it will only output 8 bit so yes it should be at 10 bit.

first you should check if your Tv supports unlimted RGB than you have to do some test if your TV can dither 10 bit input or display it.

if you don't fully understand how this works you should simply stick with dithered 8 bit madVR.

i'm just guessing you are using AMD because nvidia and intel doesn't have such option in there driver yet.

feelingblue

12th May 2015, 15:53

Thanks

I have not a TV but a VPR.
The functioning is different compared to a TV, there is not a fisical panel.
the manufacturer declares support for 10bit, but if as you said ATI driver and EDID are not affidable the only way is to do comparison test.

My VPR yes, support unlimited RGB.

RenderGuy2

12th May 2015, 16:02

It would interesting to test and confirm that a 10bit signal can pass from MadVR/MPDN through the video card without being dithered/altered along the way.

The only way I can think of to test this would be to use an HDMI capture card. The more expensive ones can capture/record uncompressed 10bit RGB. Even some of the less expensive cards can capture 4:2:0 10bit YUV. One could play some 10bit patterns out to the capture card. By analyzing the captured footage, it should be easy to determine if dithering occurred along the way.

Anyone own a capture card capable of 10bit recording?

Unfortunately I do not.

huhn

12th May 2015, 16:12

noee

12th May 2015, 16:20

the EDID doesn't tell you at all if your panel is 10 bit you only learn if your Tv support high bit deep input that's all and nearly all support 12 bit input.

AMD uses by default 10 bit if possible and YCbCr. if you select 8 bit in the AMD driver it will only output 8 bit so yes it should be at 10 bit.

first you should check if your Tv supports unlimted RGB than you have to do some test if your TV can dither 10 bit input or display it.

if you don't fully understand how this works you should simply stick with dithered 8 bit madVR.

i'm just guessing you are using AMD because nvidia and intel doesn't have such option in there driver yet.

Do you know if this is true with the 13.12 driver that does not actually have the bit depth option?

I ask because I cannot see a difference in the test pattern when sending 10bit from madVR with the AMD HDMI_DisableDither either on or off, so it appears that it just sends the 10bit signal on to the monitor without futzing with it.

huhn

12th May 2015, 16:22

Do you know if this is true with the 13.12 driver that does not actually have the bit depth option?

it doesn't have this option.

i guess AMD is just outputting 10 bit in this case if possible it just a black box on this driver.

James Freeman

12th May 2015, 16:31

FRC works by combining four colour frames as a sequence in time, resulting in perceived mixture. In basic terms, it involves flashing between two colour tones rapidly to give the impression of a third tone, not normally available in the palette.

The question is how fast?
MadVR dithering is limited to the display refresh rate (or eve slower, the movie frame rate?).
Do you think FRC is faster than the display refresh rate? If so, it has an advantage over madVR in lower bit depths where you can still see the pattern.
The faster the change the smoother and less noticeable the pattern is.

baii

12th May 2015, 17:09

It boils down to the lack of real test pattern/tools for this sort of thing, it is not hard to tell if a panel do 8 or 10bit,
but to compare 8bit dither vs native 10bit vs 10bit dither? Probably need 3+ monitor attached to GPUs ~ and the only one that can make judgement is human eye~~

8bit dither -> any bitdepth panel-> smooth gradient
10bit native -> 8 bit or lower panel-> banding
10bit native -> 10bit/8bit+frc panel -> smooth gradient
10bit dither -> any bitdepth panel -> smooth gradient

I guess one can take picture then try to get the SNR, would be a nice scientific project ~

RenderGuy2

12th May 2015, 17:34

we don't even know if a 8 bit picture isn't altered.

True, this would be interesting to test as well. Though it should be easy to determine if 10 bit data was ever reduced to 8 bits. For example, if you sent a 10 bit gradient out to the capture card and then viewed a histogram of the captured gradient, I imagine you would see evenly spaced gaps/peaks in the histogram if it was reduced to 8 bits along the way. Anyway, if nobody has a capture card, I guess we'll never know.

MS-DOS

12th May 2015, 17:41

yes it does.

and going to FSE 10 bit mode take a very long time.
A few more questions if you don't mind: What's your monitor? Is it connected with DisplayPort or HDMI? Does the color format setting in CCC stay at RGB when you switch the output bit depth there to 10 bit?

The question is how fast?
I couldn't find any information regarding this. Let's just say, for me it's good\fast enough to prefer it over an additional portion of normal dithering :)

huhn

12th May 2015, 18:00

A few more questions if you don't mind: What's your monitor? Is it connected with DisplayPort or HDMI? Does the color format setting in CCC stay at RGB when you switch the output bit depth there to 10 bit?
it's on old Phillips TV from 2011 week 11 (that's what's in the identification at least.).
should be the PFL 4603 12 maybe...
i use HDMI

changing the bit deep in the driver doesn't change to YCbCr or RGB limited. it is by default set to 10 bit anyway.

edit: it's a 42PFL4606H/12
i found this on the back of the screen

huhn

12th May 2015, 18:06

True, this would be interesting to test as well. Though it should be easy to determine if 10 bit data was ever reduced to 8 bits. For example, if you sent a 10 bit gradient out to the capture card and then viewed a histogram of the captured gradient, I imagine you would see evenly spaced gaps/peaks in the histogram if it was reduced to 8 bits along the way. Anyway, if nobody has a capture card, I guess we'll never know.

i tested thsi already with my screen.

i disabled the dithering with that registry "hack" and disabled madVR dithering.

when i set the GPU to output 8 bit i saw clearly banding. when i set it to 10 bit i didn't saw banding only a little bit. looks like my 8 bit screen dithered the 10 bit from the GPU.

it would be very strange if the GPU would dither 10 bit to 8 bit if it is set to output 10 bit and didn't dither it when set to 8 bit.
so it is pretty much clear that the registry "hack" has disabled the dithering and my screen is doing this.

James Freeman

12th May 2015, 18:19

Good news, the Panasonic ST60 takes 10bit perfectly with Nvidia through HDMI if the digital color format is YCbCr444 Limited;
EDIT: It also takes RGB 10bit if it set to Limited range 16-235, but only 8bit if Full range 0-255.
Or in short, it takes 8-10 (or more) as long as the range is limited.

ryrynz.
You've got the VT50 don't you?
Try the test again, the VT50 and ST60 are practically the same.

MS-DOS

12th May 2015, 18:21

it's on old Phillips TV from 2011 week 11 (that's what's in the identification at least.).
should be the PFL 4603 12 maybe...
i use HDMI

changing the bit deep in the driver doesn't change to YCbCr or RGB limited. it is by default set to 10 bit anyway.
Thanks :) Couldn't find anything regarding "PFL 4603" though...

Guess I should just install 14.12 and connect my U2212HM with DisplayPort someday to see what's going on there. Not that there will be any benefits for a 6 bit +A-FRC panel, but it's still interesting if it can handle a 10 bit signal at all.

huhn

12th May 2015, 18:24

Thanks :) Couldn't find anything regarding "PFL 4603" though...

Guess I should just install 14.12 and connect my U2212HM with DisplayPort someday to see what's going on there. Not that there will be any benefits for a 6 bit +A-FRC panel, but it's still interesting if it can handle a 10 bit signal at all.

the name of the screen is 42PFL4606H/12

i edit it in my post

RenderGuy2

12th May 2015, 18:34

i tested thsi already with my screen.

i disabled the dithering with that registry "hack" and disabled madVR dithering.

when i set the GPU to output 8 bit i saw clearly banding. when i set it to 10 bit i didn't saw banding only a little bit. looks like my 8 bit screen dithered the 10 bit from the GPU.

it would be very strange if the GPU would dither 10 bit to 8 bit if it is set to output 10 bit and didn't dither it when set to 8 bit.
so it is pretty much clear that the registry "hack" has disabled the dithering and my screen is doing this.

Yes, it would be nice to 100% confirm than the gpu isn't performing any dithering. Sounds promising for AMD after the registry edit. Does any one know if something similar needs to be/can be done for Nvidia?

James Freeman

12th May 2015, 18:40

Does any one know if something similar needs to be/can be done for Nvidia?
Nvidia does not dither.

huhn

12th May 2015, 18:41

Yes, it would be nice to 100% confirm than the gpu isn't performing any dithering. Sounds promising for AMD after the registry edit. Does any one know if something similar needs to be/can be done for Nvidia?

i don't think it is needed to even do this registry edit. it's better to not do it to be honest. if the AMD driver gets 10 bit and can't output 10 bit to the screen is will not dither to 8 bit and the result is bad.

huhn

12th May 2015, 18:50

i just tried my HD4400 with my TV.

madVR said the output is 10 bit but the FSE change is instant and the picture looks like undithered 8 bit.
so i guess the intel isn't outputting 10 bit at all.

fairchild

12th May 2015, 21:47

I use a 16bit greyscale ramp png (converted from 10 bit test ramp.psd, which should be same as the 1 by AMD) that was made to test OPENGL 30bit support in photoshop.

It is much easier to spot if the panel do 10 bit.

https://mega.co.nz/#!OYoQ2IID!0CzRLlDL7v-RXxTjt4FPqDURwcEqWR70VyqpKROztK4

PS: enable LAV filter RGB48.

I just tested my Sony 32EX400 LCD and it appears to work with dithering using the provided 10 bit test ramp, it's very easy to see and the screen does indeed seem to change modes when going FSE.

I'm going to test my 55VT60 panasonic plasma next and see the results of that.

Edit: Just tested my 55VT60 and same thing, both appear to smooth out both gradient pat'erns that I use when going FSE. (also used the one in the OP) Using 13.12 AMD drivers on my 7870 while in RGB Limited.

Maybe someone can answer something for me though, after I have verified that 10-bit is actually working on my setup, do I have to leave the calibration options the same or can I go back to how it was setup which is saying that my display is calibrated to BT709 and disable GPU gamma ramps was unchecked?

luk008

12th May 2015, 23:38

Excuse me, but in the driver panel we must flag 10bit or not?

With EDID my video driver automatically sets YCbCr444 10bit
i think that this maybe a way to understand if the panel support 10bit

there is a way to read edid info?

a similar tool is reliable?
http://developer.amd.com/tools-and-sdks/graphics-development/amd-edid-utility/

For this you can use http://www.entechtaiwan.com/util/moninfo.shtm

ryrynz

13th May 2015, 00:45

You've got the VT50 don't you?
Try the test again, the VT50 and ST60 are practically the same.

Can confirm better grey transistioning using YCbCr444, never thought to test that in particular when comparing these modes earlier.
Hard to tell if 10 bit is changing anything compared to 8 bit here (the only way I believe this can be tested quickly is to simply right click and break out of FSE mode) but I'll be keeping it in YCbCr444.

Francois76l

13th May 2015, 08:51

Nvidia does not dither.

Hello James.
When I set Madvr to output 10bit, my projector (JVC x35 / RS46) receive a 12bit signal because nvidia driver can't send 10 bit (only 8 or 12bit).
So does it mean that nvidia driver are dithering the signal?

James Freeman

13th May 2015, 09:37

...because nvidia driver can't send 10 bit (only 8 or 12bit).

Are you sure about this saying?
Nvidia does not dither any way.

huhn

13th May 2015, 13:40

Are you sure about this saying?
Nvidia does not dither any way.

the 362.63 driver didn't let me choice 10 bit so yes i guess it's true that nvidia is limited to 8 or 12 bit. pretty bad if you ask me...

nevcairiel

13th May 2015, 13:50

Just as with audio, zero-padding bitdepth to extend it will never harm the quality.

huhn

13th May 2015, 14:05

Just as with audio, zero-padding bitdepth to extend it will never harm the quality.

it's not that bad if all TVs would always support 10 bit and 12 bit input at the same time.
but i wouldn't be shocked if some TV only support 10 bit and 8 bit input.

tobindac

13th May 2015, 16:56

madVR dithering is better quality than the mystery FRC inside the monitor.

You have no idea if what you just said is true and you know it.

It's possible.

tobindac

13th May 2015, 17:20

Maybe those tests would be much easier if each stripe was a completely different color. We don't want to check the differences between colors, but that the colors of the stripes differ.

James Freeman

13th May 2015, 17:27

You have no idea if what you just said is true and you know it.
It's possible.

True.

Others claim that FRC in displays actually looks smoother because it is not dependent on the video frame rate like madVR is.
Users claim this at 6bit+dithering in madVR where the pattern is still clearly visible but 6+FRC is less visible.

At 8+ bit it's an absolute guess game.
So how would we actually know without seeing if madVR is better than FRC at 8+ bits?
Maybe it is utterly pointless at this stage.

tobindac

13th May 2015, 17:38

James Freeman

13th May 2015, 17:42

If I understand you correctly you want to use madVR in 8bit WITHOUT dithering?.. Don't.
Always use dithering in madVR in 8bit because banding is still very visible.

tobindac

13th May 2015, 17:44

No no no, dithering and all. I'll just turn off 10bit and use all the bells and whistles as normal. I find it a hassle feeding 10bit to an 8bit monitor when it inflicts an annoying 2sec delay every time it goes full screen.

huhn

13th May 2015, 18:04

The big info for me today is that the AMD driver dithers by default. For me, that makes the case a bit unimportant since a lot of us seeing "10bit" were just seeing the dither of AMD.

I'll just put it on 8bit in madvr myself. Not for anything else, but there is a blank screen for 2sec before going 10bit and I'd rather avoid it if it had no benefits.

I know there may be a theoretical benefit because of madvr doing its calculations on more accurate floating point numbers, but I doubt it can be noticed.

you miss understand this.

AMD can dither the input to 12, 10 or 8 bit and than send it to the TV. don't forget GPU support 16 bit input. but you can easily choice what you want to output to the display. so you have very high control of the AMD driver.

i'm real impressed by this i usually prefer nvidia driver but in term of high bit deep output AMD has currently the better options.

tobindac

13th May 2015, 18:55

you miss understand this.

AMD can dither the input to 12, 10 or 8 bit and than send it to the TV. don't forget GPU support 16 bit input. but you can easily choice what you want to output to the display. so you have very high control of the AMD driver.

i'm real impressed by this i usually prefer nvidia driver but in term of high bit deep output AMD has currently the better options.

I don't get where I said something that opposes that. I realize that there may be even some theoretical benefits to work with 10bit before sending to an 8bit. I just find it not worth it since there is a big delay of about 2seconds before the screen can finally show "10bit"(8bit) (when turning on fullscreen) while I know the "improvements", if any, in such a case would be likely impossible to be noticed by a human.

huhn

13th May 2015, 19:08

I don't get where I said something that opposes that. I realize that there may be even some theoretical benefits to work with 10bit before sending to an 8bit. I just find it not worth it since there is a big delay of about 2seconds before the screen can finally show "10bit"(8bit) (when turning on fullscreen) while I know the "improvements", if any, in such a case would be likely impossible to be noticed by a human.

and where does AMD dither play a rule in this?

luk008

14th May 2015, 03:08

Is HDMI 2.0 necessary to output 10 bits (I'm using 1.4)?

James Freeman

14th May 2015, 08:11

HDMI 1.3 can do 10bit, 12bit, and 16bit in RGB or YCbCr.

Although I think it is in Limited Range (Sometimes called Standard Range) (16-235) only.
EDIT: At least it is what I see with Nvidia GPU and a Panasonic ST60.

huhn

14th May 2015, 13:31

HDMI 1.3 can do 10bit, 12bit, and 16bit in RGB or YCbCr.
Although I think it is in Limited Range (Sometimes called Standard Range) (16-235) only.

no can be full range too. at least i'm pretty sure this is the case on my screen.

full range and limited range take the same bandwidth anyway.

x7007

15th May 2015, 02:24

it says my Tv 7007 support

here is the full log
Monitor Asset Manager Report, generated 15/05/2015
Copyright (c) 1995-2014, EnTech Taiwan.
---------------------------

Monitor #1 [Real-time 0x0071]
Model name............... Philips FTV
Manufacturer............. Philips
Plug and Play ID......... PHL0000
Serial number............ n/a
Manufacture date......... 2012, ISO week 18
Filter driver............ None
-------------------------
EDID revision............ 1.3
Input signal type........ Digital
Color bit depth.......... Undefined
Display type............. RGB color
Screen size.............. 880 x 490 mm (39.7 in)
Power management......... Not supported
Extension blocs.......... 1 (CEA-EXT)
-------------------------
DDC/CI................... Not supported

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.640 - Ry 0.330
Green chromaticity....... Gx 0.290 - Gy 0.600
Blue chromaticity........ Bx 0.150 - By 0.060
White point (default).... Wx 0.289 - Wy 0.299
Additional descriptors... None

Timing characteristics
Horizontal scan range.... 15-70kHz
Vertical scan range...... 48-62Hz
Video bandwidth.......... 170MHz
CVT standard............. Not supported
GTF standard............. Not supported
Additional descriptors... None
Preferred timing......... Yes
Native/preferred timing.. 1920x1080p at 60Hz (16:9)
Modeline............... "1920x1080" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Detailed timing #1....... 1920x1080p at 50Hz (16:9)
Modeline............... "1920x1080" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync

Standard timings supported
640 x 480p at 60Hz - IBM VGA
800 x 600p at 60Hz - VESA
1024 x 768p at 60Hz - VESA
1680 x 1050p at 60Hz - VESA STD
1440 x 900p at 60Hz - VESA STD
1600 x 1200p at 60Hz - VESA STD
1400 x 1050p at 60Hz - VESA STD
1280 x 800p at 60Hz - VESA STD
1280 x 1024p at 60Hz - VESA STD
1280 x 960p at 60Hz - VESA STD

EIA/CEA-861 Information
Revision number.......... 3
IT underscan............. Supported
Basic audio.............. Supported
YCbCr 4:4:4.............. Supported
YCbCr 4:2:2.............. Supported
Native formats........... 1
Detailed timing #1....... 1920x1080p at 24Hz (16:9)
Modeline............... "1920x1080" 74.250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync
Detailed timing #2....... 1920x1080i at 50Hz (16:9)
Modeline............... "1920x1080" 74.250 1920 2448 2492 2640 1080 1084 1094 1124 interlace +hsync +vsync
Detailed timing #3....... 1280x720p at 50Hz (16:9)
Modeline............... "1280x720" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
Detailed timing #4....... 1920x1080i at 60Hz (16:9)
Modeline............... "1920x1080" 74.250 1920 2008 2052 2200 1080 1084 1094 1124 interlace +hsync +vsync

CE video identifiers (VICs) - timing/formats supported
1920 x 1080p at 60Hz - HDTV (16:9, 1:1)
1920 x 1080p at 50Hz - HDTV (16:9, 1:1)
1920 x 1080p at 24Hz - HDTV (16:9, 1:1)
1920 x 1080p at 30Hz - HDTV (16:9, 1:1)
1920 x 1080p at 25Hz - HDTV (16:9, 1:1)
1920 x 1080i at 60Hz - HDTV (16:9, 1:1)
1920 x 1080i at 50Hz - HDTV (16:9, 1:1)
1280 x 720p at 60Hz - HDTV (16:9, 1:1)
1280 x 720p at 50Hz - HDTV (16:9, 1:1)
720 x 576p at 50Hz - EDTV (16:9, 64:45)
720 x 480p at 60Hz - EDTV (16:9, 32:27)
720 x 576p at 50Hz - EDTV (4:3, 16:15)
720 x 480p at 60Hz - EDTV (4:3, 8:9)
720 x 576i at 50Hz - Doublescan (16:9, 64:45)
720 x 480i at 60Hz - Doublescan (16:9, 32:27)
720 x 576i at 50Hz - Doublescan (4:3, 16:15)
720 x 480i at 60Hz - Doublescan (4:3, 8:9)
640 x 480p at 60Hz - Default (4:3, 1:1)
NB: NTSC refresh rate = (Hz*1000)/1001

CE audio data (formats supported)
LPCM 2-channel, 16/20/24 bit depths at 32/44/48/88/96 kHz
AC-3 6-channel, 640k max. bit rate at 32/44/48 kHz

CE speaker allocation data
Channel configuration.... 2.0
Front left/right......... Yes
Front LFE................ No
Front center............. No
Rear left/right.......... No
Rear center.............. No
Front left/right center.. No
Rear left/right center... No
Rear LFE................. No

CE vendor specific data (VSDB)
IEEE registration number. 0x000C03
CEC physical address..... 1.0.0.0
Supports AI (ACP, ISRC).. No
Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes
Supports dual-link DVI... No
Maximum TMDS clock....... 225MHz
Video latency (p)........ 181ms
Audio latency (p)........ 181ms
Audio/video latency (i).. n/a
HDMI video capabilities.. Yes
EDID screen size......... Rounded to nearest cm
3D structures supported.. Top-and-bottom, Side-by-side w. horizontal sub-sampling
3D formats supported..... Mandatory formats plus some primary VICs
1920 x 1080p at 60Hz - HDTV (16:9, 1:1)
1920 x 1080p at 50Hz - HDTV (16:9, 1:1)
1920 x 1080p at 24Hz - HDTV (16:9, 1:1)
1920 x 1080p at 30Hz - HDTV (16:9, 1:1)
1920 x 1080p at 25Hz - HDTV (16:9, 1:1)
1920 x 1080i at 60Hz - HDTV (16:9, 1:1)
1920 x 1080i at 50Hz - HDTV (16:9, 1:1)
1280 x 720p at 60Hz - HDTV (16:9, 1:1)
1280 x 720p at 50Hz - HDTV (16:9, 1:1)
NB: NTSC refresh rate = (Hz*1000)/1001
Data payload............. 030C001000382DAF5B5BD004014001FF

CE colorimetry data
xvYCC709 support......... Yes
xvYCC601 support......... Yes
sYCC601 support.......... No
AdobeYCC601 support...... No
AdobeRGB support......... No
Metadata profile flags... 0x01

Report information
Date generated........... 15/05/2015
Software revision........ 2.90.0.1000
Data source.............. Real-time 0x0071
Operating system......... 6.1.7601.2.Service Pack 1

Raw data
00,FF,FF,FF,FF,FF,FF,00,41,0C,00,00,01,01,01,01,12,16,01,03,80,58,31,78,0A,E6,92,A3,54,4A,99,26,
0F,4A,4C,21,08,00,B3,00,95,00,A9,40,90,40,81,00,81,80,81,40,01,01,02,3A,80,18,71,38,2D,40,58,2C,
45,00,00,D0,52,00,00,1E,02,3A,80,D0,72,38,2D,40,10,2C,45,80,00,D0,52,00,00,1E,00,00,00,FC,00,50,
68,69,6C,69,70,73,20,46,54,56,0A,20,00,00,00,FD,00,30,3E,0F,46,11,00,0A,20,20,20,20,20,20,01,F0,
02,03,37,F1,52,10,1F,20,22,21,05,14,04,13,12,03,11,02,16,07,15,06,01,26,09,1F,07,15,07,50,83,01,
00,00,70,03,0C,00,10,00,38,2D,AF,5B,5B,D0,04,01,40,01,FF,E3,05,03,01,01,1D,80,3E,73,38,2D,40,7E,
2C,45,80,00,D0,52,00,00,1E,01,1D,80,D0,72,1C,16,20,10,2C,25,80,00,D0,52,00,00,9E,01,1D,00,BC,52,
D0,1E,20,B8,28,55,40,00,D0,52,00,00,1E,01,1D,80,18,71,1C,16,20,58,2C,25,00,00,D0,52,00,00,9E,78

---------------------------

Hardware data
BUS_SLOT = PCI00000.PCI00004.PCI00008.PCI0000C.PCI00010.PCI00014.PCI00018.PCI0001C
00000000 = 01508086.20900006.06000009.00000000.00000000.00000000.00000000.00000000
00000008 = 01518086.00100007.06040009.00810010.00000000.00000000.00010100.2000E0E0
000000A0 = 1E318086.02900406.0C033004.00000000.F7320004.00000000.00000000.00000000
000000B0 = 1E3A8086.00100400.07800004.00800000.F7337004.00000000.00000000.00000000
000000C8 = 15038086.00100406.02000004.00000000.F7300000.F7335000.00000001.00000000
000000D0 = 1E2D8086.02900006.0C032004.00000000.F7334000.00000000.00000000.00000000
000000E0 = 1E108086.00100006.060400C4.00810010.00000000.00000000.00020200.200000F0
000000E4 = 244E8086.00100007.060401C4.00810010.00000000.00000000.00040300.200000F0
000000E7 = 1E1E8086.00100006.060400C4.00810010.00000000.00000000.00050500.200000F0
000000E8 = 1E268086.02900006.0C032004.00000000.F7333000.00000000.00000000.00000000
000000F8 = 1E448086.02100007.06010004.00800000.00000000.00000000.00000000.00000000
000000FA = 28228086.02B00407.01040004.00000000.0000F091.0000F081.0000F071.0000F061
000000FB = 1E228086.02800003.0C050004.00000000.F7331004.00000000.00000000.00000000
00000100 = 13C210DE.00100007.030000A1.00800010.F6000000.E000000C.00000000.F000000C
00000101 = 0FBB10DE.00100006.040300A1.00800010.F7080000.00000000.00000000.00000000
00000200 = 00121102.00100006.04030001.00000010.F7204004.00000000.F7200004.00000000
00000300 = 10801B21.00100007.06040103.00010010.00000000.00000000.20040403.202001F1
00000500 = 10421B21.00100406.0C033000.00000010.F7100004.00000000.00000000.00000000
--------
01070000 = 00FFFFFF.FFFFFF00.410C0000.01010101.12160103.80583178.0AE692A3.544A9926
00000020 = 0F4A4C21.0800B300.9500A940.90408100.81808140.0101023A.80187138.2D40582C
00000040 = 450000D0.5200001E.023A80D0.72382D40.102C4580.00D05200.001E0000.00FC0050
00000060 = 68696C69.70732046.54560A20.000000FD.00303E0F.4611000A.20202020.202001F0
01070100 = 020337F1.52101F20.22210514.04131203.11021607.15060126.091F0715.07508301
00000020 = 00007003.0C001000.382DAF5B.5BD00401.4001FFE3.05030101.1D803E73.382D407E
00000040 = 2C458000.D0520000.1E011D80.D0721C16.20102C25.8000D052.00009E01.1D00BC52
00000060 = D01E20B8.28554000.D0520000.1E011D80.18711C16.20582C25.0000D052.00009E78

EDID revision............ 1.3
Input signal type........ Digital
Color bit depth.......... Undefined
Display type............. RGB color
Screen size.............. 880 x 490 mm (39.7 in)
Power management......... Not supported
Extension blocs.......... 1 (CEA-EXT)

CE colorimetry data
xvYCC709 support......... Yes
xvYCC601 support......... Yes

Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes
YCbCr 4:2:2.............. Supported

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.640 - Ry 0.330
Green chromaticity....... Gx 0.290 - Gy 0.600
Blue chromaticity........ Bx 0.150 - By 0.060
White point (default).... Wx 0.289 - Wy 0.299
Additional descriptors... None

Does it mean I can choose 10 bit ? Do I need a video that is 10 bit ? cause 8 bit still works the same and not RGB48.

the Color characteristics means I need to set it like that ?

http://i.imgur.com/fUo4HcU.png

mhourousha

15th May 2015, 03:30

no can be full range too. at least i'm pretty sure this is the case on my screen.
full range and limited range take the same bandwidth anyway.
it depends on gpu and display device.
for example,a playstation3(2006)can output 12bit full range through HDMI 1.3
and for my tv(a sony HX750),AMD card ouput bit depends on catalyst CC setting.NV card(a very old GT240) output 12bit in both 10bit/16bit D3D11 scan-out format.and Intel(HD4000) output 8bit in 10bit scan-out,and 12bit for 16bit scan-out format.
there is also a R10G10B10_XR_BIAS scan-out format mapping to xvYcc gamut.all 3 GPU above support that format but I can't comfirm if the HDMI signal is xvYcc.

huhn

15th May 2015, 13:02

it says my Tv 7007 support
...~...
Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes
YCbCr 4:2:2.............. Supported

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.640 - Ry 0.330
Green chromaticity....... Gx 0.290 - Gy 0.600
Blue chromaticity........ Bx 0.150 - By 0.060
White point (default).... Wx 0.289 - Wy 0.299
Additional descriptors... None

Does it mean I can choose 10 bit ? Do I need a video that is 10 bit ? cause 8 bit still works the same and not RGB48.
http://i.imgur.com/fUo4HcU.png
your TV supports 8, 10 and 12 bit input. this doesn't mean it can output 10 bit what so ever.
depending on how your TV handles these input bit deeps you can get a worse picture and unlikely a better picture.

you don't need 10 bit videos to make use of this.

the Color characteristics means I need to set it like that ?

if you have calibrated your TV to bt 709 gamma 2.2 yes. but without calibration your Tv is "something else".

but setting it to these settings shouldn't harm and most likely didn't change colors at all.

Does it mean I can choose 10 bit ? Do I need a video that is 10 bit ? cause 8 bit still works the same and not RGB48.

i don't get this part.

x7007

15th May 2015, 15:01

your TV supports 8, 10 and 12 bit input. this doesn't mean it can output 10 bit what so ever.
depending on how your TV handles these input bit deeps you can get a worse picture and unlikely a better picture.

you don't need 10 bit videos to make use of this.

if you have calibrated your TV to bt 709 gamma 2.2 yes. but without calibration your Tv is "something else".

but setting it to these settings shouldn't harm and most likely didn't change colors at all.

i don't get this part.

Thanks for answering !

How may I able to check the 8bit vs 10bit quality, I have no idea what to search or which file will show me the obvious different.

madshi said to be able to see the 10bit you need to select RGB48 in LAVFilter Video. I didn't understand that. cause even when I select it I only see NV12 8bit or YV12 8bit in CTRL + J on Bluray MKV movies.

huhn

15th May 2015, 17:56

Thanks for answering !

How may I able to check the 8bit vs 10bit quality, I have no idea what to search or which file will show me the obvious different.

madshi said to be able to see the 10bit you need to select RGB48 in LAVFilter Video. I didn't understand that. cause even when I select it I only see NV12 8bit or YV12 8bit in CTRL + J on Bluray MKV movies.
you need to enable RGB48 so lavfilter gives you the possibility to send 16 bit png to madVR and disable dithering to make the effect even more obvious. on a normal BD source this does nothing ok disabling dithering can have a huge effect.

look at the first post in this thread.

baii

15th May 2015, 20:48

There had not have any "proven" visual evidence or test that say 10bit(with or w/o dither) will look better than 8bit +dither even everything is working as intended.

Theoretically/ Mathematically, 10bit > 8bit but that's pretty much it for now.

ryrynz

16th May 2015, 04:18

James Freeman

16th May 2015, 05:57

You sure? Wasn't it James that showed otherwise?

baii is right, If one can't see it why is it better?
I myself can't see any difference between 10 vs 8+D at all.

As baii noted Theoretically/ Mathematically 10bit may have less error but it is on the edge of visibility anyway, therefor it has less importance with real content.
For now 8+d will do until HDR displays with 100,000:1 will come.

It's a fine line this 8 vs 10 bit discussion, why do you think 8bit lasted 30 years without much complaint?
Because its already almost enough with a revealing test pattern, but with real content (especially already dithered BluRay) it can be practically invisible.
10bit - 16bit is there in the Studio/Grading monitors so that no extra dithering is added, but I bet even for the trained eye 10 vs 8+d will be indistinguishable.

aufkrawall

16th May 2015, 18:15

Is there a way to be sure that the Nvidia driver doesn't do dithering?
I'm not seeing banding with my Qnix QX2710 (PLS panel, DL-DVI input without scaler).

How to prevent exiting FSE when the "video" is done with playing? Pressing space doesn't help.

huhn

16th May 2015, 18:50

aufkrawall

16th May 2015, 18:57

How can I do this, please? :)

James Freeman

16th May 2015, 18:59

Is there a way to be sure that the Nvidia driver doesn't do dithering?
I'm not seeing banding with my Qnix QX2710 (PLS panel, DL-DVI input without scaler).

Input a 10bit signal into a different monitor that you sure is only 8bit, you should see the gradient because Nvidia does not dither.
With windows 10 and latest driver keep the bit depth on 8bit (this is bypassed in FSE mode anyway).

AMD on the other hand always dither the image without a registry hack, an 8bit only monitor will look smooth with a 10bit signal because AMD already dithered it down to 8bit.
This is true if you leave the bit depth in the control panel on 8bit (I don't own an AMD card so I'm not sure about the name of the setting).

How to prevent exiting FSE when the "video" is done with playing? Pressing space doesn't help.
MPC-HC?
View->Options->Playback->After Playback->Do Nothing.

aufkrawall

16th May 2015, 19:16

Input a 10bit signal into a different monitor that you sure is only 8bit, you should see the gradient because Nvidia does not dither.
With windows 10 and latest driver keep the bit depth on 8bit (this is bypassed in FSE mode anyway).

Oh well, I'd have to get an old 19" from the attic...
With DVI, you don't have any input control regarding color depth in the control panel.

huhn

16th May 2015, 21:37

you don't need to do it this way.

you don't want to know if your display is 10 bit you want to know if nvidia is dithering right?

for this you just need to disable dithering in madVR look at the test picture in 8 bit and you must see clear banding.

install the newest nvidia driver for windows 10 (352.83 or something like that). this should be easy because you are on windows 10 right? you will find an option for bit deep in the same place you find an option for RGB, YCbCr and limited full range. set it to 8 bit.
after this use d3d11 10 bit mode and look at the picture if you see banding nvidia isn't dithering.

aufkrawall

16th May 2015, 21:51

you don't need to do it this way.

you don't want to know if your display is 10 bit you want to know if nvidia is dithering right?

for this you just need to disable dithering in madVR look at the test picture in 8 bit and you must see clear banding.

Yes, but maybe the driver does a conversion from 10 bit to 8 bit with dithering when I "try" to output 10 bit?

install the newest nvidia driver for windows 10 (352.83 or something like that). this should be easy because you are on windows 10 right? you will find an option for bit deep in the same place you find an option for RGB, YCbCr and limited full range. set it to 8 bit.
after this use d3d11 10 bit mode and look at the picture if you see banding nvidia isn't dithering.
As I said, there are no options for any of these when using DVI.

But how do you know if the signal is actually 10 bit (and probably converted to 8 bit in the monitor panel with dithering) or if it's just 8 bit, already dithered by the GPU?
In the end, couldn't those bit depth settings just be dither options?

huhn

16th May 2015, 22:06

Yes, but maybe the driver does a conversion from 10 bit to 8 bit with dithering when I "try" to output 10 bit?

than this option would be useless and there is no reason for this option in the first place.

As I said, there are no options for any of these when using DVI.
i have this option with DVI.
http://abload.de/img/dvihru0n.png
if your display doesn't support 10/12 bit input you can't test it anyway.
But how do you know if the signal is actually 10 bit (and probably converted to 8 bit in the monitor panel with dithering) or if it's just 8 bit, already dithered by the GPU?
In the end, couldn't those bit depth settings just be dither options?

they should be dithering to the selected output bit deep.
but James freeman said they are not dithering.
i my test this may self later.

i know it for AMD for sure the only thing i don't know for sure is if my display is 10 bit or dithering. ok it is dithering but i can't say this for sure.

iSunrise

16th May 2015, 22:50

baii is right...
You always want to be as close to madVR's 16fp output as possible, irregardless of whether you might see differences with one setup. Secondly, only if we currectly had screens cheap enough, who would accept such a high bitdepth, we could forget about anything else like dithering and be safe.

Since that isn't the case, everyone should enable 10bit if performance and compatibility permits and there aren't any drawbacks like displays or display firmware that behave strangely with such a bitdepth. That's why everyone needs to test this for themselves.

Don't forget that each post-processing step incuded with madVR, irregardless of it's precision, will always alter the input and so you always want the highest possible bitdepth at every stage you can get. There's a rule in the audio world which also applies here. Always use the highest bitdepth possible, especially when you're post-processing, because every step has the potential to degrade your final result. Technically, if we would really be anal about this, every step you post-process does degrade the image. It is however, when handled properly, hardly (if at all) recognizable.

Therefore, everyone should be advised to keep on testing and shouldn't just "assume" that something couldn't be better, just because you cannot see it. Our eyes are quite limited, some things are hard to catch. Also, our displays are limited, so there's might be differences, but the display is unable to show them (for whatever reason there may be).

If performance is an issue, however, it probably does make sense to lower quality first in areas where you cannot recognize changes, but if there's no limitation, always try to output with max. bitdepth and dithering (if something else doesn't dither, this will greatly improve quality, too). ONLY disable dithering, when input and output = same bitdepth.

It's pretty simple, really.

huhn

17th May 2015, 01:34

first of all you win nothing if you feed a 8 bit panel 10 bit that doesn't even use dither.

the only case where dither isn't need is 16 bit output because madVR doesn't store result higher.

and the next most important thing is if you don't see a difference between 8 and 10 bit output 8 bit is a lot safer so why bother with something like that.

Warner306

17th May 2015, 01:52

huhn

17th May 2015, 02:05

I notice ReClock reports 12 bit output when I bring up the filter during playback. Is this confirmation the TV is receiving this output?

I was able to determine my TV is 12-bit by viewing its parts page. Under Specifications, the gradations of colors was listed.

nearly all TV support 12 bit input. but where do you see this information in reclock?

AMD send 10 bit by default and nvidia 8 bit without 10 bit input and 12 with 10 bit input.

Warner306

17th May 2015, 03:49

ReClock is reporting 12-bit input, not output. My bad.

http://i1357.photobucket.com/albums/q760/Warner306/Kodi%20Illustrations/ReClock_zpsbopcrfim.png

fb39ca4

17th May 2015, 08:45

Will 10 bit work on VGA?

ryrynz

17th May 2015, 10:24

Will 10 bit work on VGA?

Nope. I'd highly recommend updating to DVI/HDMI/DP when possible for other reasons though.

huhn

17th May 2015, 10:50

ReClock is reporting 12-bit input, not output. My bad.

http://i1357.photobucket.com/albums/q760/Warner306/Kodi%20Illustrations/ReClock_zpsbopcrfim.png

this is a 8 bit color space. and the number is bits per pixel.
each channel has 8 but the 2 chroma channel is only 1/4 of the luma channel so this gives you 12 bit per pixel instead of 24 bit per pixel.

iSunrise

17th May 2015, 15:56

first of all you win nothing if you feed a 8 bit panel 10 bit that doesn't even use dither.
That's not the point I was trying to get across. The point is that you should always keep dithering enabled. When you come from internal 16bit floating point data and you select 8bit output, there's another 8bits of data you would cut off without dithering enabled, because the output is integer data. If the display is 8bit and is not even dithering itself, then dithering for madVR is even more important.

Only if you had a screen that is not only accepting 16bit integer (RGB data), but also a panel that is able to display such a high bit depth, only then you would disable dithering.

What a display accepts or not or what a display is able to show is the sole reason why everyone needs to test it for themselves.

the only case where dither isn't need is 16 bit output because madVR doesn't store result higher.
In that case you would also need dithering, since madVR needs to convert 16bit floating point data to 16bit integer. This is ALWAYS the case.

huhn

17th May 2015, 16:16

In that case you would also need dithering, since madVR needs to convert 16bit floating point data to 16bit integer. This is ALWAYS the case.

it's not like madVR is store each step as float. if i'm not mistaken most of it is store as integer.

iSunrise

17th May 2015, 16:40

it's not like madVR is store each step as float. if i'm not mistaken most of it is store as integer.
You're mistaken then, since madVR does everything in pure floating point, hugely because with integer you would constantly lose data within the post-processing steps. Only when it comes to the output stage, where you need integer, madVR applies dithering and then needs to convert to integer. That's also the way it should be done.

vivan

17th May 2015, 19:11

Calculations are done in 32-bit float, because shaders.
Intermediate result (between render steps) is stored as normalized (treated as fp in [0..1] range) 16-bit integer.
16-bit float gives 11 bit of precision in [0..1] range - not enough. 32-bit is twice slower and video rendering requires quite a lot of read/write operations.

Out-of-range data is not really important... maybe only when using 3dlut. But AFAIK madVR internally uses limited range, so it saves some parts of HDR.

RyuzakiL

18th May 2015, 03:04

So after reading all the posts starting with the first radical update madshi made, i'm still kind of confused:stupid:

I'm running on Win. 8.1 Update 3 x64+HD7850+FX8320
Madvr+avisynth+FFDShow+MPC-HC+Reclock+LavFilters

My display is Samsung 40inch Led TV

1. I turned off all video enhancements from CCC including dynamic range since madvr also do that, but i left deinterlace enabled on CCC.
I also switch CCC to run on 12bit and RGB 4:4:4.

2. I didn't mess with native dithering registry hack since from what i read from all the post, I ALWAYS NEED DITHERING.

3. I enabled FSE to be able to use 10bit and all is going well except for random presentation glitches whether "present a frame for every vsync" was ON or OFF. and since i also enabled "display mode switching" by madvr it adds to the time it takes for FSE 10bit to switch >> 5-10 seconds of blackscreen, so it's not recommended for maranthon watching of animes.

Questions

1. I want to lessen extra redundant processing like dithering, deinterlacing and Pixel Conversions in the Chain. So what do you gurus recommend to turn off in the chain? in Lav Filters there's no way to turn off dithering, though i configure it to use random dithering.

2. Can i turn off deinterlacing on CCC since, i configured Lavfilters to deinterlace?

3. I think my display can output 10bit but given the lag time of switching to FSE 10bit + random presentation glitches. I think i need to settle to 8bit for now till madvr fix these issues, coz i think for the moment his focus were on the deband and scaling algorithms. Do I need to change something on LAVVideo settings? since i read somewhere that i need to put a check on something?

4. If i use display mode switching in Madvr, does Reclock becomes useless? I follow this guide http://www.ezoden.com/htpc/4/how-to-setup-htpc-introduction, and it requires to use AviSynth and FFDshow for post-processing, but given that madvr seems to use sharpening algorithms found on Avisynth and FFDshow do you think It's high time for me to scrap those two?

edison

18th May 2015, 03:43

Will 10 bit work on VGA?

It works on CRT via HD15 connector.

nevcairiel

18th May 2015, 10:25

FWIW, the 352.84 NVIDIA driver released today enabled the output bitdepth controls on Windows 8.1 for me, so Windows 10 isn't the only OS where these controls are available now.

James Freeman

18th May 2015, 10:30

I see 352.86 for Windows 7 too, but I'm at work now, so I will test in a couple of hours.
I will also test if this driver dithers at output when in 10/12 bit mode.

James Freeman

18th May 2015, 18:07

I'll just copy paste my post from the official madVR thread:

Windows 7 x64 here.
I have 8 and 10 bit over DisplayPort with my screen, no 12.
Switching to 10bit, my monitor actually goes into 10bit mode so it actually works.
madVR FSE D3D11 10bit switches instantly so that's another sign that all is well.

I have tested and observed the following:
In 10bit mode "Adjust Desktop Color Setting" in control panel (nvidia) actually works in 10bit now, so moving the sliders generate no banding, Hurray!
Operating system Color Management (2DLut) still in 8bit because DWM (Desktop Window Manager) is also still in 8bit, so gradation and banding are generated when I switch on my ICC Porfile.
Windowed Mode in madVR still appears to be in 8bit even if it set to 10bit in madVR, this is again because it has to go through DWM.
Overlay mode is also in 8bit.
In short, EVERYTHING! the whole OS is still in 8bit although the output is in 10bit.

I guess high bit depth DWM is a privileged in windows 10 only, all the older DWM versions of windows (7, 8 , 8.1) are 8bit only.
Or is it? Anyone cares to try windowed mode in 10bit with madVR in 10bit and report is the gradients are visible?

EDIT:
I may be wrong, maybe madshi will be able to call 10bit in windowed mode if the desktop is already in 10bit...

omarank

18th May 2015, 19:33

32-bit is twice slower
Is that true for modern video cards as well?

huhn

18th May 2015, 20:18

madVR needs FSE to get 10 bit.
and it is not confirmed that windows 10 can do 10 bit in window mode. maybe with DX12. maybe never.

Asmodian

19th May 2015, 01:57

You're mistaken then, since madVR does everything in pure floating point, hugely because with integer you would constantly lose data within the post-processing steps. Only when it comes to the output stage, where you need integer, madVR applies dithering and then needs to convert to integer. That's also the way it should be done.

madVR does calculations in 32-bit float but stores each intermediate stage as 16-bit int.

I could also use double float (64bit) for all madVR calculations and store all temp results in 32bit float. That would in theory increase the precision and exactness of madVR's rendering. But it wouldn't bring a visible improvement, and would slow down everything a lot.

RainyDog

19th May 2015, 09:00

So... If your display is a 10bit native panel and properly accepts a 10bit input, can you disable dithering in madVR using D3D11 exclusive with 10bit+ output?

nevcairiel

19th May 2015, 09:02

So... If your display is a 10bit native panel and properly accepts a 10bit input, can you disable dithering in madVR using D3D11 exclusive with 10bit+ output?

You should never disable dithering. Even at 10-bit, there will be data lost if you don't dither.

Zachs

19th May 2015, 09:20

madVR does calculations in 32-bit float but stores each intermediate stage as 16-bit int.

FWIW MPDN does its yuv to rgb conversion and dithering all in 32bit float including the intermediate stores, so it always dithers from 32bit to 8/10/16 bits. Only the step between first and second pass scaling is influenced by the render quality option, which also allows you to choose 32bit float if you select max quality. For single pass scalers, it's 32bit all the way (in the case where you don't use render scripts).

Zachs

19th May 2015, 09:25

Is that true for modern video cards as well?

It depends on which scaler/renderscripts you use. You can play with it by changing the render quality from prefer image quality to prefer max quality in MPDN of you are curious. Image quality setting uses 16bit ints, max quality uses 32bit float. Heck there's even an prefer max performance mode that does only 8bit if you chose to use it. I'd only use it on tight power budget platforms but it does allow you to see what the performance diff is on your GPU/video ram bandwidth with your selected scaler.

x7007

19th May 2015, 15:39

I succeed to use the 10bit , but my render and present queue are 2 and 1.

Without present a frame for every Vsync I had tons of presentation errors / with it none

Any idea how to fix the render and present half queues ?

Does watching movies in 10bit will be any usefulness ? what will it be good for if not for movies

huhn

19th May 2015, 15:47

rule 8...

10 bit output can help with processing on 8 bit screens with proper dither.
and it shows less noise on 10 bit displays.

x7007

19th May 2015, 15:49

rule 8...

10 bit output can help with processing on 8 bit screens with proper dither.
and it shows less noise on 10 bit displays.

so it could help, are the other issues are known as bugs , does it happen to everyone ?

huhn

19th May 2015, 15:50

so it could help, are the other issues are known as bugs , does it happen to everyone ?

depends on the screen. and there could be a lot of bugs 10 bit windows usage is pretty "new"

x7007

19th May 2015, 16:01

depends on the screen. and there could be a lot of bugs 10 bit windows usage is pretty "new"

Did you try to watch a movie with 10bit ? do you have the issue with the render and present queues not full ? and the rendering MS is high by a lot.

huhn

19th May 2015, 16:36

Did you try to watch a movie with 10bit ? do you have the issue with the render and present queues not full ? and the rendering MS is high by a lot.

no works fine for me at least version 88.6. and yes 10 bit works fine but depends a lot on the used screen.
usually 8 bit and forget is the best choice.

Anime Viewer

19th May 2015, 19:20

Did you try to watch a movie with 10bit ? do you have the issue with the render and present queues not full ? and the rendering MS is high by a lot.

I believe I may have been able to replicate your queue problem. Are your queue reading 0-1 or 1-2 before the "/ "regardless of what comes after the "/"?

Ex:

render queue 1-2 / 12
present queue 0-2 / 14

When your queue hit 0 do you see presentation glitches as opposed to dropped frames, both, or neither (even if those it shows it at zero)?

omarank

20th May 2015, 07:03

FWIW MPDN does its yuv to rgb conversion and dithering all in 32bit float including the intermediate stores, so it always dithers from 32bit to 8/10/16 bits. Only the step between first and second pass scaling is influenced by the render quality option, which also allows you to choose 32bit float if you select max quality. For single pass scalers, it's 32bit all the way (in the case where you don't use render scripts).

It depends on which scaler/renderscripts you use. You can play with it by changing the render quality from prefer image quality to prefer max quality in MPDN of you are curious. Image quality setting uses 16bit ints, max quality uses 32bit float. Heck there's even an prefer max performance mode that does only 8bit if you chose to use it. I'd only use it on tight power budget platforms but it does allow you to see what the performance diff is on your GPU/video ram bandwidth with your selected scaler.
Good to know that. I will definitely try out the Max Quality setting to see whether it is any slow on my system.

x7007

20th May 2015, 16:59

I believe I may have been able to replicate your queue problem. Are your queue reading 0-1 or 1-2 before the "/ "regardless of what comes after the "/"?

Ex:

render queue 1-2 / 12
present queue 0-2 / 14

When your queue hit 0 do you see presentation glitches as opposed to dropped frames, both, or neither (even if those it shows it at zero)?

ye, it doesn't actually hit 0, depend if I enable the present a frame for every vsync. but it is render 2 instead of 8 or 7.
the present is always 1 instead of 2 or 3.

If I try to use the D3D11 with 10bit and going full screen Exclusive mode.
1.the ms from 26ms goes to 40ms. ( AKA Fix ) Enabling the Exclusive mode in Potplayer settings to Fastest improves the ms to 31ms in full screen, so we need to enable Exclusive in 2 places and make sure 3DTV is not enabled too.
2.the render queue goes from 7-8/8 to 2-4 changing a bit from time to time.
3.present queue stays 1-3/3
4.if present a frame for every vsync not enabled I have Present errors all the time, with it enabled I don't have any.

EDIT : Wow,,, if you keep 3DTV enabled, it fucks the MS performance from 22ms to 35ms just by it enabled.

feelingblue

23rd May 2015, 07:40

Just for info..

I did all the cross test with render, video settings and various modes.

Benq W1400 VPR does not support 10bit.
Benq declares support for 10bit but actually is 8bit.

I do not make comments on manufacturer honesty...... because there is not a physical screen.

thank you all for the advice

shaolin95

25th May 2015, 16:22

Hello guys!
I am running Windows 8.1 so how can I make sure Aero gets enabled?
My searches seem to mention a "hack" but I was wondering if someone has been able to test this with 8.1

Also, I did test it with the image provided and with the Nvidia Control Panel set to RGB and 0-255 and I was able to see the difference between 8bit and 10 bit (even my wife notice and she rarely sees what I explain lol). What confuses me is that people has commented you need 16-235 to see it with Nvidia for example so makes me wonder if I am doing something wrong.
I am using a BenQ W1070 projector btw.

Any help will be appreciated! :)

huhn

25th May 2015, 16:41

Hello guys!
I am running Windows 8.1 so how can I make sure Aero gets enabled?
My searches seem to mention a "hack" but I was wondering if someone has been able to test this with 8.1
there is an hack to disable it. aero is always active on windows 8

Also, I did test it with the image provided and with the Nvidia Control Panel set to RGB and 0-255 and I was able to see the difference between 8bit and 10 bit

and what did you see? a difference is not what you should look for. you can easily get a worse picture by inputting 10 bit.

What confuses me is that people has commented you need 16-235 to see it with Nvidia for example so makes me wonder if I am doing something wrong.
I am using a BenQ W1070 projector btw.

quote this please. i like to see who said something like this.

shaolin95

25th May 2015, 16:52

there is an hack to disable it. aero is always active on windows 8

and what did you see? a difference is not what you should look for. you can easily get a worse picture by inputting 10 bit.

quote this please. i like to see who said something like this.
Cool about aero and 8!
Clearly better in my case. The "banding" that I was still able to detect with 8bit became a lot harder to see at 10 bit when in full screen and visible again in window mode (when it shows 8bit again) so that was very telling for me and good to know it works!

Looks like the people talking about nvidia and 16-235 etc were either wrong or just on their particular systems so ignore that last comment.
So count the BenQ W1070 as supporting 10bit.

TripleH

28th May 2015, 16:23

I'm trying to enable 10-bit output but having no success with it.

My setup:
nVidia GTX 970 with the latest official driver running on Windows 8.1 x64 connected through HDMI to a Marantz AV8801 SSP and from there to a Lumagen Radience Mini 3D video processor.

AFAIK, my SSP and video processor are both capable of passing and processing 10-bit HDMI input.

However, the nVidia control panel only lets me choose 8-bit output.

Is there any other action the should be taked in order to enable 10-bit HDMI output ?

Thanks.

huhn

28th May 2015, 16:26

if nvidia didn't report 10 or 12 bit that means the EDID said the device can't do it.

try the TV direct at the video card to make sure the TV can take 10 bit or higher input.

Qaq

28th May 2015, 18:01

Perhaps you need to enable DeepColor in the AVR? Run MonInfo to get EDID report.

TripleH

29th May 2015, 18:50

Yes, the problem is EDID related. I connected a HDFury 4K splitter with a custom EDID table to my PC and from there to the SSP and VP just as before and now I have an option to choose 12 bit color output.

Should I use YCbCr 4:4:4 or RGB while the output is set to 12bpc ? I think that RGB should be better since madVR deals with the RGB conversion and the Windows OS itself renders everything at RGB, so a 4:4:4 output should involve another conversion at the end to YCbCr.

Is it right ?

Qaq

29th May 2015, 20:07

RGB 0-255 (madVR/video driver/TV) should do best.

voyager6868

31st May 2015, 21:00

Someone has posted that the nVidia driver does not dither. Could you provide a link to some evidence?

Based on my tests, it does dither. I ran the test detailed in the first post of this thread on an 8-bit monitor and get a smooth pattern (using a Direct3D 10-bit surface). This is a $300 4K monitor that does next to no processing of input, so I highly doubt it is accepting a 10-bit signal and doing something as sophisticated as dithering.

Also, what evidence is there that a consumer nVidia card sends a 10-bit signal, unless it is set to 10bpc or higher in the nVidia control panel? I think people are assuming that if one uses a Direct3D 10-bit surface, that the video card will change modes to 10bpc or higher if the monitor supports it. What evidence is there of that?

AFAICT, the only time nVidia outputs more than 8bpc is if you set it in the control panel (or you have software that explicitly sets the video mode).

Bottom line here is that a dithered 8-bit pattern looks almost indistinguishable from a true 10-bit pattern, so simply looking at the screen is likely not enough to prove anything. Other posters have alluded to this. We need a scientific analysis of the signal coming out of the card.

I would add further, that even when nVidia is sending out a 10-bit signal, there is no guarantee that your monitor is actually showing it a such. It could be dithering down to 8-bit, and you likely could not tell the difference with this gradient test.

I think it will be incredibly hard to ever show than a device is outputting a true 10-bit signal (and given that.. maybe we should not care).

Maybe things will be easier to detect with the human eye once we start using an expanded color space (rec.2020) as there will be greater gaps between the colors.

shaolin95

31st May 2015, 21:08

huhn

31st May 2015, 21:12

nvidia is dithering for sure.

dansrfe

31st May 2015, 21:17

Is there any way to be sure of the results of this test? There is visible banding on windowed and the banding goes away when I invoke a shortcut for FSE while keeping my eyes closely fixed on the screen.

It's a bit hard for me to believe since I have all 1440p korean monitors off ebay yet they are connected directly via an active DP -> Dual-DVI adapter. Are there any changes I need to make in Nvidia's CPL to confirm 10-bit?

Lastly, is dithering in madVR required if 10-bit works and will I need to recalibrate via Argyll and madtpg in 10-bit or can I use the existing 3DLUT?

Thanks!

shaolin95

31st May 2015, 21:30

nvidia is dithering for sure.

How come I dont get the smooth ramp when testing with MPDN? I thought it did the same as MADVR going to 10bit mode in FSE thus I was expecting the next results but then again..that could be just a problem with that program and not related.
So many things to learn for me :D

huhn

31st May 2015, 21:33

shaolin95

31st May 2015, 21:36

i don't know is mpdn set to 10 bit output?

Yep everything set to do it but just wont do it. Tried the 16 bit option too and nothing. Very odd.
And thanks for your recommendation on PM, the system is looking great now.
Ended up calibrating at PC Levels as I use PowerDVD for 3D movies and that one was looking bad when calibrated at tv levels.

voyager6868

31st May 2015, 23:19

How come I dont get the smooth ramp when testing with MPDN? I thought it did the same as MADVR going to 10bit mode in FSE thus I was expecting the next results but then again..that could be just a problem with that program and not related.
So many things to learn for me :D

Are you sure MPDN is interpreting the gradient as 16-bit? Note that if you don't enable RGB48 in the LAV video settings, it will show the gradient as 8-bit, so maybe there is a similar issue with MPDN (caveat is that I've never used that program, so just guessing)

huhn

31st May 2015, 23:37

Are you sure MPDN is interpreting the gradient as 16-bit? Note that if you don't enable RGB48 in the LAV video settings, it will show the gradient as 8-bit, so maybe there is a similar issue with MPDN (caveat is that I've never used that program, so just guessing)

mpdn can't do 16 bit RGB you have to disable everything except y416 in lavfilter.

James Freeman

1st June 2015, 05:11

nvidia is dithering for sure.
Stop giving people answers you have absolutely no idea if they are true or false.

If your statement were true, we all would see smooth pattern on any monitor, which is CLEARLY not the case.
Only from that, I can deduct that your statement is completely thoughtless, impulsive and FALSE.

voyager6868

1st June 2015, 09:07

Stop giving people answers you have absolutely no idea if they are true or false.

If your statement were true, we all would see smooth pattern on any monitor, which is CLEARLY not the case.
Only from that, I can deduct that your statement is completely thoughtless, impulsive and FALSE.

James--you posted earlier that nVidia does not do dithering, however, when I using madVR as you described in Post #1 on a TV whose EDID only supports 8-bit, I get no banding. To me this is solid evidence that nVidia (at least in the latest drivers) is dithering.

It sounds like nevcariel has the same result as me. nVidia is not going to send a 10-bit output signal unless the panel says that it supports it. Otherwise, some users would see "junk" on their screen as the panel would have no idea what to do with such a signal.

Can you point us to your evidence that nVidia is *not* dithering? Which users tried your gradient with the proper settings in madVR, use the latest nVidia drivers set to 8bpc, and get banding on their 8-bit screen?

huhn

1st June 2015, 10:26

James Freeman

1st June 2015, 16:43

huhn

1st June 2015, 19:06

some screens say what signal they got.

i got a sony w800 and this screen tells me what the GPU send as a signal but the screen is has a serious issue so i have to wait until it is replace to test this.

i did this test already for amd.

so everyone with a sony Tv should be able to to the same test.

and i'm pretty sure nvidia is sending high bit deep why shouldn't they.

nikola

3rd June 2015, 16:26

I'm a bit puzzled by this investigation.

Yesterday I connected my AMD 7790 to my Denon X2000 over HDMI, then connected the Denon to my TV over HDMI. The TV was set to expect full-range RGB, and the 7790 was set to output RGB 4:4:4 full-range. I confirmed with madshi's test pattern that the TV set was indeed receiving 4:4:4-sampled video. I setup madVR to output 10-bit, configured the 7790 in AMD's Control Center to output 10-bit, and disabled AMD's HDMI-bound dithering in the registry (then restarted the machine). Then I played back a movie, verified in madVR's OSD that it's outputting 10-bit, and verified in the Denon receiver's menu that the HDMI signal is actually 10-bit.

Does any of this prove that the TV set is displaying 10-bit?

No.

All it proves is that the HDMI receiver in the TV set is receiving a 10-bit signal. And given the fact that my TV set does not advertise 10-bit capability anywhere (I'm pretty sure their marketing dept. would be shouting from high roofs if the TV had 10-bit support), and that it's a mid-range consumer product, I find it highly probable that the TV set itself is dithering the 10-bit input to its native bit-depth, i.e. to 8-bit or even lower.

So what exactly is the purpose of this investigation? The workflow that has been shown here does in no way prove or disprove the actual bit-depth of the panel.

FWIW, I also did the same test with my Dell 2713HM (which, unlike it's sister model, the 2713H, is an 8-bit panel), and the same workflow did produce a picture. If the GPU isn't dithering, there's still the panel itself that does.

nevcairiel

3rd June 2015, 16:32

There is indeed no conclusive way to determine that. All you can do is judge if it looks good, or maybe even looks better than 8-bit output. Even with a 8-bit panel, 10-bit output might be beneficial, as the TV will do processing on the video first, motion interpolation, color changes through a built-in LUT or similar, and whatnot.

huhn

3rd June 2015, 16:37

that's correct nearly all TV are 8 bit these days. but you can easily check with AMD if your TV is dithering.

take the test picture.
make sure 16 bit RGB is checked in lavfilter.
make sure you can send 10 bit to the TV.
disable dithering in madVR.
make sure you see a ton of banding with 8 bit window mode.
go FSE and send 10 bit to the TV.

now you can check if the TV still hows banding if not it is dithering and unlikely 10 bit. if it shows banding than it doesn't dither and should never be feed with 10 bit.

in the end the TV does "stuff" with the picture so giving them a 10 bit picture should help in the end even for 8 bit panels.

nikola

3rd June 2015, 22:12

That's all assuming that by sending a 10-bit signal you'd be triggering a "10-bit processing mode" in the TV's processing pipeline. There is zero evidence to support the belief that TV sets are actually capable of applying color management or motion interpolation to 10-bit signals.

In fact, considering that the vast majority of TV sets already make tons of picture quality compromises to hit a certain price point it'd be much more realistic to assume that a 10-bit signal is first being downgraded to 8-bit, then processed further. I don't see the benefit of this approach. Why not just let madVR dither to 8-bit when we already know that the panel itself can't display 10-bit per channel?

The fact is that madVR's processing pipeline is much more sophisticated than any TV set could offer today. By introducing an unknown parameter to the processing pipeline, i.e. the TV set's 10-bit to 8-bit conversion, you are basically re-introducing what madVR tried to circumvent in the first place, i.e. the GPU driver's implicit mutilation of frames behind the user's back.

nevcairiel

3rd June 2015, 23:16

There is a lot of speculation in there, and the short answer is: We just do not know. If the TV processes in 10-bit, it can result in higher quality, even if it dithers to 8-bit at the end of it. The simple point here is to keep the signal as high a quality as possible for as long as possible.
What if the TV does this processing anyway, and re-dithers, even on 8-bit input? Having a higher precision from the get-go and not introducing extra dithering noise could reduce the final noise, improving the image.

At the end of the day however, the only thing you can do is judge with your eyes, or possibly with some measurement instruments to measure effective bitdepth.
Its an optional setting, anyway.

baii

3rd June 2015, 23:30

Well, there are monitor users, and the test had been pretty much spot on for them.

Sent from my 306SH

kolak

7th June 2015, 20:25

If I find time I may do some tests on Sony professional OLED monitors over HDMI (or Eizo over DP). I know for 100% that these panels are 10bit and HDMI supports passing 10bit.
I've done testing with some pro software, RV and Scratch which supports 10bit with Quadro cards and I was easily able to tell the difference between 8 and 10bit. 8bit dithered was more tricky, but still distinguishable.

When you do these tests it's good to have some reference pipe, which you know for 100% is 10bit capable.

iSunrise

7th June 2015, 23:05

@nikola:
I agree with everything, you kinda feed a black box, therefore I did my own test for my Eizo CG 243W like I already explained in the madVR thread some time ago. I chose a grey ramp from LightIllusion's available 16bit per component test patterns (TGA files) and disabled dithering in madVR. When madVR was set at 8bit I still could see tiny steps between the gradients, with 10bit activated the steps completely disappeared.

The funny thing is that I didn't expect this to happen at all, since I am pretty sure that my panel is 8bit+FRC and not native 10bit. Also, the second surprise is that I am still connected via DVI-I on this display. I didn't even know that DVI supports 10bit output.

So, since everyone has a black box and even additional software in between, it should be pretty safe to send 10bit anyway, when someone isn't completely sure and compare it themselves to 8bit with test patterns. Since even when 10bit might not be accepted correctly, you would probably find something worth your time, like I did. And if not, you at least know that 10bit is out of the question, which should be pretty rare, though.

huhn

7th June 2015, 23:18

you compared 8 bit undithered vs 10 bit dithered to 8 bit of cause the dithered 8 bit wins clearly.

iSunrise

7th June 2015, 23:53

you compared 8 bit undithered vs 10 bit dithered to 8 bit of cause the dithered 8 bit wins clearly.
Which still was a surprise to me, because from then on I knew I can run 10bit to the display and the display doesn't have any problems accepting it, which nikola was talking about. You just have to come to the right conclusions, which a test will mostly solve. Just guessing, because a manufacturer claims it is not ideal.

For an Eizo CG you would expect it, but some other monitors might also work.

huhn

8th June 2015, 00:00

but you can send 10 bit to the GPU driver for an 8 bit or lower screen and it will dithered too by the GPU.

but the most important question is madVR dither better or the GPU/display dither?

so you can always use it.

kiwijunglist

13th June 2015, 06:37

Hi

I can confirm that a Samsung ua60hu6400 (2014 model 1080P) TV displays 10bit using Win7x64, AMD HD7750 (Driver 14.2), MPV-HCx86. I confirmed this by seeing banding in windowed mode and no banding in fullscreen exclusive mode, when I toggle the mode with right clicking. Also confirmed that there is no upstream dithering because the banding dissapears in windowed mode when I toggle dither on/off in madvr.

I can get 10bit output with Pixel format set to RGB Full+Limited and YbCrCb 4:4:4. When I set to YbCbCr 4:2:0 in CCC then I get banding. This is with AMD CC set to "preferred colour depth: 10 and ITC processing enabled". There are options for 8/10/12 preferred colour depth in CCC, but I've left it set to 10. ITC processing set to enabled (I don't actually know what it does).

Given that I am using a TV for display and only using my TV for movies (8bit NV12 4:2:0 mkv) with MadVR and nothing else what would you recommend for:

1. LAV Video: Output untouched vs 0-255 vs 16-235?
2. MadVR Device properties: 0-255 vs 16-235?
3. AMD CCC Pixel format: RGB Full vs RGB Limited vs YCbCr4:4:4 vs YCbCr4:2:2(8bit only)

4. Is there any test that I can use to see if my TV displays 0-255 or if it just accepts 0-255 and then crushes it down to 16-235.

5. Given that movies are always encoded as 16-235 8bit and the confusion as to whether my TV is truely 8bit vs 10bit it be best to have everything operate at 16-235 level 8bit?

Thanks
Kiwi

Asmodian

13th June 2015, 09:56

1. LAV Video: Output untouched vs 0-255 vs 16-235?

It doesn't matter, that setting is only used for YUV->RGB conversion in LAV (which isn't being done).

2. MadVR Device properties: 0-255 vs 16-235?

0-255

3. AMD CCC Pixel format: RGB Full vs RGB Limited vs YCbCr4:4:4 vs YCbCr4:2:2(8bit only)

RGB Full

4. Is there any test that I can use to see if my TV displays 0-255 or if it just accepts 0-255 and then crushes it down to 16-235.

I doubt this is happening, TVs usually down sample the color to 4:2:2 but they don't compress the range. You would need to change a setting or calibrate your TV differently for full/limited range input. Only if your TV cannot be setup for full range should you use limited. To use limited set madVR to limited but leave the AMD CCC Pixel format on RGB Full.

AVS HD Test Patterns (http://www.avsforum.com/forum/139-display-calibration/948496-avs-hd-709-blu-ray-mp4-calibration.html)

5. Given that movies are always encoded as 16-235 8bit and the confusion as to whether my TV is truely 8bit vs 10bit it be best to have everything operate at 16-235 level 8bit?

I suggest, if in doubt, set madVR and the GPU to 8-bit. By the time madVR is displaying a frame it is 16-bit RGB data but with its quality dithering madVR's 8-bit output is very good.

Even 8-bit YUV -> RGB results in >8-bit RGB, scaling has a similar effect, you need more bit-depth to keep all the precision so 10-bit display is beneficial for 8-bit sources. However, with all the bad ways madVR's 10-bit output could be converted to 8-bit (at best a second dithering step) sending good 8-bit in the first place is better. Never turn off madVR's dithering (except for testing, of course).

Qaq

13th June 2015, 11:20

Kiwi,
madVR: 0-255, 10 bit allow to keep source data as much as possible.
AMD Catalyst: RGB Full (0-255), 10 bit, with dithering (and all Video enhancements) disabled should help madVR to keep "pixel perfect".
TV: to expect RGB input (and prevent internal conversion to YCbCr, sometimes even to 4:2:2) you have to set it to "PC mode". In most TVs "PC mode" only works with 60Hz refresh rate, unfortunately. To except 0-255 range you have to set Black level to High. After that you can try some 0-255 and 4:4:4 patterns to make sure everything works as expected.
Notes: my OLED only switches to PC mode on 60Hz. MadVR works smooth enough on 60Hz, so I can stand it. With RGB Full (black level High) there is no dead black on my OLED anymore, so I have to keep RGB in Limited range for the whole setup.

kiwijunglist

14th June 2015, 07:33

feelingblue

14th June 2015, 08:27

Unfortunately those suggested settings are really bad for my situation, I think they are good for PC.

with the following settings
LAV: 0-255
MadVR: 0-255
CCC: 0-255
TV HDMI Black: Low or Normal

I get clipped black levels, I can't see 16-25 black level on test patterns on the TV, no matter how high I turn up the brightness. I think with this setting my madVR is expanding 16-235 to 0-255 and then my tv is discarding 0-16 information.

If I change MadVR to 16-235 then I can see 16-25 levels.

There is nothing wrong.
with all settings to 0-255 is normal that you cut BTB and WTW.

With a normal stand alone player the situation is a little different and spears and munsill reccomand to set player in limited and TV in expanded.

Qaq

14th June 2015, 08:31

So you either didn't set HDMI input to PC mode or its impossible to expand RGB from 16-235 to 0-255 after that. The latter looks weird to me. But ok, as I said, I use RGB limited myself.
Note: you shouldn't touch LAV colour format settings, its madVR's job to convert source colour format to RGB. LAV's default settings are perfectly matched with madVR.

huhn

14th June 2015, 12:22

sadly fullrange RGB is not possible with all TVs.

i will never understand why full range RGB support at all refreshrate isn't default for all TVs. when one mode can do it why can't all modes do it?

kiwijunglist

15th June 2015, 07:24

yeah i like to run my tv at 23.976 rather than use interpolation/repeated/dropped frames or re-sampling the audio (reclock).

the TV/GPU is pretty good in that regard, my refresh rate without custom timings or mods is 23.9766 which is pretty close to 23.976

huhn

15th June 2015, 19:06

not sure way people think you get a good clock when it is at 23.976hz. this whole topic is way more complicated and a perfect GPU clock is pretty meaningless.

kiwijunglist

18th June 2015, 04:50

I doubt this is happening, TVs usually down sample the color to 4:2:2 but they don't compress the range. You would need to change a setting or calibrate your TV differently for full/limited range input. Only if your TV cannot be setup for full range should you use limited. To use limited set madVR to limited but leave the AMD CCC Pixel format on RGB Full.

AVS HD Test Patterns (http://www.avsforum.com/forum/139-display-calibration/948496-avs-hd-709-blu-ray-mp4-calibration.html)

Thanks, I figured out what was happening. My pioneer avr can't tell the difference between rgb full and rgb limited when all video processing is set to off (passthrough). If it gets an RGB Full signal it disgards 0-16 and 235-255 and then passes the signal off as RGB Limited. It's very weird.

ryrynz

18th June 2015, 05:58

Removed.

XMonarchY

18th June 2015, 21:22

So 10bit+ only works with Direct3D 11?

XMonarchY

18th June 2015, 21:53

Wow, my Eizo Foris FG2421 is 8bit+FRC, but nVidia drivers only allow me to select 8bit. HOWEVER, FG2421 does pass the 10bit test and shows perfectly smooth gradient with FSE + D3D11 + 10bit in madVR + no madVR dithering, one much smoother than with FSE + D3D11 + 8bit in madVR + no madVR dithering. It looks no worse than true 10/12bit on my HDTV. I guess FRC does make a big difference!

huhn

18th June 2015, 21:57

Zachs

19th June 2015, 00:29

So 10bit+ only works with Direct3D 11?
No. The support started with Direct 3D 10.

James Freeman

19th June 2015, 08:56

huhn

19th June 2015, 12:47

My monitor (Dell U2410) switches to true 10bit mode when I select 10bit in nvidia control panel.
Also when madVR calls for 10bit my monitor switches to 10bit even if it was set to 8bit in nvidia control panel.

that's interesting AMD doesn't do that. but it's the correct choice of nvidia but makes the option to choice the output pretty much useless like i guessed before.

nevcairiel

19th June 2015, 12:55

that's interesting AMD doesn't do that. but it's the correct choice of nvidia but makes the option to choice the output pretty much useless like i guessed before.

You can force a higher mode even for desktop use, which avoids this switch and makes a window -> FSE switch faster. In this, its quite useful.

huhn

19th June 2015, 13:25

You can force a higher mode even for desktop use, which avoids this switch and makes a window -> FSE switch faster. In this, its quite useful.

that doesn't work for me. even with 12 bit it take the same time to enter FSE. same with AMD which never switches mode it just takes a long time switching modes.

nevcairiel

19th June 2015, 13:28

Its noticeably faster for me when I force 12-bit on my HTPC. If its set to 8-bit and I use 10-bit out in madVR, the switch is much slower.

Qaq

19th June 2015, 13:46

I experienced several crashes after exiting from madVR 10 bit to 8 bit desktop. Obviously it's better to keep display in same input bitdepth all the time.

XMonarchY

19th June 2015, 16:34

@XMonarchY

We assume/guess that if NVidia driver does not let you select 10bit in the control panel, when you switch to true 10bit in madVR, the driver dithers to 8bit.
But if the driver lets you select 10bit in control panel, we assume/guess that the GPU sends true 10bit if madVR/Directx11 calls for it.

My monitor (Dell U2410) switches to true 10bit mode when I select 10bit in nvidia control panel.
Also when madVR calls for 10bit my monitor switches to 10bit even if it was set to 8bit in nvidia control panel.

The Dell monitor shows that it switches inputs (small icon) when going to 10bit or back to 8bit.
By that I can tell that the GPU actually sends 10bit to the monitor and does not dither.
Maybe other monitors have clearer indicators that they switched to true 10bit mode like in the info menu?

I do not think so. I can see FCR dithering OUTSIDE of madVR when I view grayscale gradients, even though only 8bit option is selectable in NVidia CP. I use an ArgyllCMS 1DLUT and 8bit setting (no FCR dithering) on my HDTV shows some obvious banding (on picture tests, outside of madVR) , while my 8bit + FRC monitor does not, using the same 8bit setting.

I am not sure if all FCR monitors dither the same. I remember my 6bit + FCR ASUS VG248QE and dithering it had was very slow. On FG2421, dithering is extremely fast.

huhn

19th June 2015, 16:39

what is fast and what is slow dithering?

and how do you get more than 8 bit outside from madVR d3d11 FSE mode?

nevcairiel

19th June 2015, 16:52

I do not think so. I can see FCR dithering OUTSIDE of madVR when I view grayscale gradients, even though only 8bit option is selectable in NVidia CP.

Then the color processing in your monitor adds dithering. Every monitor does processing of some sort to map sRGB to its display panel.

James Freeman

19th June 2015, 17:08

I can see FCR dithering OUTSIDE of madVR when I view grayscale gradients.
Do you mean you can see the actual pixels move to create dithering in your true 8-bit lcd monitor? if so you are blessed with super vision.
...my HDTV shows some obvious banding (on picture tests, outside of madVR) , while my 8bit + FRC monitor does not, using the same 8bit setting.
That has nothing to do with dithering. Your TV just has poorer gradient management than you monitor.

Eizo Foris FG2421 is an 8bit monitor at the input, even though it does processing in "higher" 8bit+FRC.
Again, your monitor does not allow 10bit input, and its FRC most probably for internal processing only.
In your case, nvidia dithers down to 8bit when you switch to FSE 10bit no-dithering.

XMonarchY

20th June 2015, 13:49

Do you mean you can see the actual pixels move to create dithering in your true 8-bit lcd monitor? if so you are blessed with super vision.

That has nothing to do with dithering. Your TV just has poorer gradient management than you monitor.

Eizo Foris FG2421 is an 8bit monitor at the input, even though it does processing in "higher" 8bit+FRC.
Again, your monitor does not allow 10bit input, and its FRC most probably for internal processing only.
In your case, nvidia dithers down to 8bit when you switch to FSE 10bit no-dithering.

Yes, I can actually see pixels moving when I get real close to the monitor. I do agree that it is the monitor doing FSE dithering as a part of processing. The point I was trying to make is that good 8bit + FRC is almost as good as true 10bit when it comes down to grayscale gradient banding.

I also think that 10bit/12bit or at least 8bit + FRC dithering has a rather drastic impact on playback quality, at least with madVR processing. Gradients are tremendously smoother. However, I am not sure whether using 12bit setting in NVidia CP and 10bit setting in madVR makes the image look better with Error Diffusion.

I wonder whether selecting 12bit for my HDTV makes GPU work harder or affects performance.

huhn

20th June 2015, 13:50

Yes, I can actually see pixels moving when I get real close to the monitor. I do agree that it is the monitor doing FSE dithering as a part of processing. The point I was trying to make is that good 8bit + FRC is almost as good as true 10bit when it comes down to grayscale gradient banding.

but you are only sending the display 8 bit how can that be as good as 10 bit ?

XMonarchY

20th June 2015, 14:49

but you are only sending the display 8 bit how can that be as good as 10 bit ?

The effect on gradient banding is just as good when monitor uses FCR as true 10bit. Well, ALMOST as good. There is no banding visible with 8bit + FRC and with 10/12bit+.

huhn

20th June 2015, 15:18

but your monitor isn't getting 10 bit for it's 8bit+FRC is is just getting dithered 8 bit which should be about the same as 8 bit madVr output with enabled dither.

James Freeman

20th June 2015, 16:00

Yes, I can actually see pixels moving when I get real close to the monitor. I do agree that it is the monitor doing FSE dithering as a part of processing.
I think you have missed the part where I said your monitor does NOT use FRC to generate more gradients like other 8+FRC monitors.
Therefor if you see dithering grain when in 10bit mode in madVR you actually see Nvidia GPU dithering down to 8bit, not FRC.

You monitor clearly specifies:
16.77 million from a palette of 1.06 billion
Meaning 8bit out of 8bit+FRC internal processing.

AGAIN,
If nvidia CP does not let you select 10bit, then your monitor does NOT use 8bit+FRC to generate gradients.

The point I was trying to make is that good 8bit + FRC is almost as good as true 10bit when it comes down to grayscale gradient banding.
We can assume that because no one actually can see the difference.
Furthermore, 8+dithering/FRC might even look more like 12bit than 10bit...

codemaster

21st June 2015, 05:51

Hi,

Could someone please summarize state of findings regarding Panasonic ST60? I tried to search and find a definitive answer, but couldn't.

My own experiments using nVidia 970 directly connected to Panasonic ST60 with different cables were the following:

- Any resolution less than 1080p supports 12bpc even at 60Hz, such as 1080i@60Hz / RGB Full, 720p@60Hz / RGB Full, etc...

- I can get 12bpc on 1080p only when refresh rate is less than 50Hz, so 1080p@24Hz / RGB Full supports 12bpc.

- Changing RGB Full to Limited or YCrCb does not enable 12bpc with 1080p@60Hz.

Does someone have an idea why it's impossible to get 1080p@60Hz 12bpc on the TV? TV limitation?

Thanks!

James Freeman

21st June 2015, 06:39

I have a Panasonic ST60.
I see interesting results regarding Nvidia bid depth, range, and madVR.

I can select 12bpc in nvidia CP even in 60Hz 1080p, but there is visible banding.
When madVR changes to 10bit (FSE DX11) there are some change for the worse... can't exactly remember.

I ALWAYS use RGB so that the GPU will not do the conversion to YCbCr because the conversion effects color too much.
The gradient is smooth in RGB only in standard (16-235) mode and 8bit.

I'm currently at work so this info is from memory, I will report later when I'm home.
I will map the behavior of the ST60 in all bit depths.

ryrynz

21st June 2015, 06:39

Hi,

Could someone please summarize state of findings regarding Panasonic ST60? I tried to search and find a definitive answer, but couldn't.

Yes all of the above are limitations of your plasma. Personally I prefer to run yCbCr444 using TV range output on my VT50 because it offers overall better image quality (http://forum.doom9.org/showpost.php?p=1614315&postcount=17361) than outputting via RGB and only getting 4:2:0.

10/12 bit output is basically indistinguishable from 8 bit on our sets, so don't worry about it. My recommendation would be to do what I have done, unless you prefer full range output..

Apparently Nvidia hasn't exposed a way for software to change the color format, I'll post about that in the Nvidia forum as it would be nice to have the renderer change modes automatically so colors are accurate for the desktop/games without having to change it manually.

XMonarchY

21st June 2015, 16:05

I think you have missed the part where I said your monitor does NOT use FRC to generate more gradients like other 8+FRC monitors.
Therefor if you see dithering grain when in 10bit mode in madVR you actually see Nvidia GPU dithering down to 8bit, not FRC.

You monitor clearly specifies:
16.77 million from a palette of 1.06 billion
Meaning 8bit out of 8bit+FRC internal processing.

AGAIN,
If nvidia CP does not let you select 10bit, then your monitor does NOT use 8bit+FRC to generate gradients.

We can assume that because no one actually can see the difference.
Furthermore, 8+dithering/FRC might even look more like 12bit than 10bit...

Yes, and I disagree with that. I think FRC can come from monitor processing itself, not NVidia driver. Dithering OUTSIDE of madVR, like on JPG/PNG grayscale gradients (viewed normally as a picture, not through madVR/MPC-HC), IS visible and gradients are much smoother on my monitor with 8bit NVidia CP setting than they are on my HDTV with 8bit NVidia CP setting, and ALMOST as smooth as on my HDTV with 12bit NVidia CP setting.

NVidia CP does not have FRC settings and NVidia drivers do not control FRC either. 10bit settings is NOT the same as 8bit+FRC. 10bit setting is true 10bit. 8bit is true 8bit, but FRC can come from displays themselves. I mean its SO obvious when you look at grayscale gradients (again, OUTSIDE of MPC-HC/madVR, in normal Windows Photo Viewer, Internet sites, and even on desktop).

James Freeman

21st June 2015, 16:11

gradients are much smoother on my monitor with 8bit NVidia CP setting than they are on my HDTV with 8bit NVidia setting, and ALMOST as smooth as on my HDTV with 12bit NVidia setting.

It means that you Eizo monitor is better than your TV at gamma curve processing thus generating less banding.
Some monitors/tvs do it better than others, It is still only 8bit.

Cheers

XMonarchY

21st June 2015, 18:17

It means that you Eizo monitor is better than your TV at gamma curve processing thus generating less banding.
Some monitors/tvs do it better than others, It is still only 8bit.

Cheers

Except I can see obvious FRC dithering. Besides, 8bit + FRC dithering on monitors has been out there for quite some time and monitor review sites have long ago noticed FRC and talked about it. Thing is, back then, NVidia CP did not have 10bit setting, but only 8bit default. YET, FRC dithering was still noticed.

Again, NVidia CP and drivers do not control FRC dithering - it is done via the monitor's processing.

huhn

21st June 2015, 18:40

but is only 8 bit send what is so hard to understand about that?
and yet again this option is only cosmetic 10 bit/12 bit worked before

XMonarchY

21st June 2015, 18:56

but is only 8 bit send what is so hard to understand about that?
and yet again this option is only cosmetic 10 bit/12 bit worked before

Yes, 8bit signal from videocard/drivers + FRC from monitor = an excellent effect, almost as good as true 10bit signal.

James Freeman

21st June 2015, 19:13

XMonarchY,

You don't seem to understand that the FRC in that specific monitor is not to create 10bit from 8bit input... where did you get that?
The FRC noise you see is from internal processing of gamma and gamut calibration, at the output you only see noisy 8bit.
8bit Input & Noisy 8bit Output is NOT as smooth as 10bit, PERIOD.
What you may actually see is a standard 8bit monitor that does gradients smoother than a bad TV.
You probably did not have a proper monitor with smooth 8bit gradient up till this Eizo, that's why you think it is smoother than it should be.
8bit IS smooth if the processing is right and no banding occurs, but 10bit is 4 times smoother still.
Eizo are great monitors be happy about that, but know that yours is a good 8bit one.

A plasma has terrible dithering because that's just how plasma TV's works, but the input is only 8bit and the resulting picture is also in 8bit and extremely dithered.
I can't explain it simpler, the dithering you see does NOT mean your monitor is showing 10bit; it means it's showing noisy 8bit if it only accepts 8bit at input.

James Freeman

21st June 2015, 20:26

Could someone please summarize state of findings regarding Panasonic ST60? I tried to search and find a definitive answer, but couldn't.
Thanks!

My findings about the ST60:

RGB

8bit Limited range From GPU, Standard (16-236) range in TV in 4:4:4 (pixel direct):
Everything smooth as it should be.

8bit Full range From GPU, Nonstandard (0-255) range in TV in 4:4:4 (pixel direct):
Banding.

8bit Full range From GPU, Nonstandard (0-255) range in TV (pixel direct Off):
Smooth but not 4:4:4

12bit Limited range From GPU, Standard (16-236) range in TV in 4:4:4 (pixel direct):
Banding.

12bit Full range From GPU, Nonstandard (0-255) range in TV in 4:4:4 (pixel direct):
Banding.

12bit Full range From GPU, Nonstandard (0-255) range in TV (pixel direct Off):
Smooth but not 4:4:4

YCbCr444
* Always Limited Range.

8bit From GPU, 4:4:4 (pixel direct):
Everything smooth as it should be.

8bit From GPU, (pixel direct Off):
Smooth but not 4:4:4

12bit From GPU, 4:4:4 (pixel direct):
Banding.

12bit From GPU, (pixel direct Off):
Smooth but not 4:4:4

Conclusions:
8bit RGB Limited range From GPU, Standard (16-236) range in TV in 4:4:4 (pixel direct), PC levels in madVR:
I would also suggest RGB because we don't want the GPU to convert to YCbCr which is another conversion step between madVR and TV.
This will convert the OS desktop to limited range. Another conversion step.
Use this if you use the TV for computer stuff besides and along with madVR movie watching.

The absolute BEST way to do this is as follows:
Nvidia RGB Full range 8bit.
madVR TV Levels (16-235) under Properties.
ST60: Standard (16-235).
This will result in the least amount of conversion stages and retain BTB & WTW just like a high quality Blu-Ray player would. In fact, Luma will not be dithered at all!
But, other programs in OS will be clipped.
Use this if you only use madVR for perfect quality movie watching on your TV or using AVS709HD calibration patterns to set Contrast and Brightness like you would from a Blu-Ray player.

The ST60 is at its best at 8bit Limited range in 4:4:4, just stick to that and madVR dithering and we'll be fine for a few more years.
Hope this helped.

huhn

21st June 2015, 21:08

so the internal processing doesn't dither sometimes?

James Freeman

22nd June 2015, 04:27

so the internal processing doesn't dither sometimes?

Each pixel of the LCD is moved by a transistor with voltage applied to its gate, so it is completely analog.
What voltage is applied to the transistor to create a gamma curve is calibrated and stored in the displays processor.

For example:
The processor accepts only 8bit input (what you see in Nvidia CP).
Internally it can store data in 16bit for calibration (10bit in XMonarchY case).
It outputs only 8bit voltage steps from this 16bit range to move the lcd pixels.

Or in XMonarchY case, at the output the display uses FRC to recreate 10bit from the processor to the pixel voltages.
If the processor uses higher bit depth like 16bit, it does not need to use FRC to "choose from" 10bit limited pallet; it can map from 16bit directly to 8bit.
But at the input the processor receives only 8bit, thus at the output it only shows 8bit.

All this is very simplified for example only.

codemaster

22nd June 2015, 08:25

Thanks for posting your findings about ST60.

I was using 8bit / RGB Full Range / 4:4:4 (pixel direct), but I'll reconsider based on the findings. The problem is I use the PC for gaming as well, so switching to Limited may not be an option.

At least it seems there is no gain with 12bit, so that's one less option to consider :-)

huhn

22nd June 2015, 09:08

james the question was about your ST60 plasma.

James Freeman

22nd June 2015, 10:35

I was using 8bit / RGB Full Range / 4:4:4 (pixel direct), but I'll reconsider based on the findings. The problem is I use the PC for gaming as well, so switching to Limited may not be an option.

No no, it IS an option.
Just switch in Nvidia CP to Limited RGB, and the ST60 to Standard (16-235) 4:4:4.
This way you get PC games and madVR (0-255) to play correctly, BUT, the GPU will do the range conversion from 0-255 to 126-235.
Nvidia does this in high bit depth so I don't see any banding at all.
This IS the option to use with the ST60 if you play PC games and watch movies, just like a PC monitor.

james the question was about your ST60 plasma.
So the internal processing doesn't dither sometimes?

Hard to say.
I can assume that any TV with a good/working Color Management System has to be high bit depth internally, just like madVR is 16bit.

Several things are for sure:
With Pixel Direct On (4:4:4) the ST60 band-less only in 8bit Limited (Standard), and the CMS for Yellow Cyan and Magenta is completely disabled.
With Pixel Direct Off, there are no banding in any mode: Full, Limited, 8 or 12 bit and the CMS is fully functional and banding free.
From that I can conclude that the high bit depth processing in the ST60 is only used in 4:2:2 mode.
Any Plasma TV is a dithering monster, it dithers at the output for sure.

codemaster

22nd June 2015, 11:05

Thanks for clarification.

Then I guess it boils down to sacrificing color conversion (Full -> Limited) vs banding. I guess subjectively color conversion should work fine especially after calibration. Don't want to miss shadow details :-)

huhn

22nd June 2015, 11:23

No no, it IS an option.
Just switch in Nvidia CP to Limited RGB, and the ST60 to Standard (16-235) 4:4:4.
This way you get PC games and madVR (0-255) to play correctly, BUT, the GPU will do the range conversion from 0-255 to 126-235.
Nvidia does this in high bit depth so I don't see any banding at all.
This IS the option to use with the ST60 if you play PC games and watch movies, just like a PC monitor.

Hard to say.
I can assume that any TV with a good/working Color Management System has to be high bit depth internally, just like madVR is 16bit.

Several things are for sure:
With Pixel Direct On (4:4:4) the ST60 band-less only in 8bit Limited (Standard), and the CMS for Yellow Cyan and Magenta is completely disabled.
With Pixel Direct Off, there are no banding in any mode: Full, Limited, 8 or 12 bit and the CMS is fully functional and banding free.
From that I can conclude that the high bit depth processing in the ST60 is only used in 4:2:2 mode.
Any Plasma TV is a dithering monster, it dithers at the output for sure.

yeah they are "1 bit" displays they don't create a pixel using transistor and different total power at a pixel they let a pixel blink and the time is blink is the brightness of that pixel.

and i'm pretty sure a DAC is used for this.

James Freeman

22nd June 2015, 13:19

Then I guess it boils down to sacrificing color conversion (Full -> Limited) vs banding.
The conversion is in the GPU in very high bit depth so no visible "sacrificing" occurs.
Just use Limited to fulfill all your needs.
Besides, up until several versions ago it was the only option by default without the user ability to change it.

yeah they are "1 bit" displays they don't create a pixel using transistor and different total power at a pixel they let a pixel blink and the time is blink is the brightness of that pixel.

1bit but with super fast refresh rate...
If you compare a Plasma and 1bit+dithering in madVR there is a huge difference.
Because the plasma refresh rate for the 1bit dithering is A LOT faster than "change every frame" that madVR uses.

huhn

22nd June 2015, 15:41

1bit but with super fast refresh rate...
If you compare a Plasma and 1bit+dithering in madVR there is a huge difference.
Because the plasma refresh rate for the 1bit dithering is A LOT faster than "change every frame" that madVR uses.

it's the length of of "bit" and of cause it has nothing to do with madVR 1 bit.

XMonarchY

22nd June 2015, 18:43

huhn

22nd June 2015, 18:51

and how did you compared it to 8 bit only?

James Freeman

23rd June 2015, 13:03

I agree with almost everything. 8bit + FRC to ME looks ALMOST as smooth as true 10bit. It surely looks better than 8bit only.

For the last time and in your words,
Your monitor IS 8bit only.

If you can't select 10bit in Nvidia CP, your monitor don't actually use FRC to create 10bit.
Understand?

If you mean that DITHERED 8bit looks as good as 10bit, then you absolutely right.

XMonarchY

24th June 2015, 21:57

For the last time and in your words,
Your monitor IS 8bit only.

If you can't select 10bit in Nvidia CP, your monitor don't actually use FRC to create 10bit.
Understand?

If you mean that DITHERED 8bit looks as good as 10bit, then you absolutely right.

Isn't FRC = DITHERING? Its 8bit + dithering (outside of madVR) and I assumed such dithering means FRC...

huhn

24th June 2015, 22:43

dithering is a way to lowering the bit deep. but you never get 10 bit in the monitor. so the monitor dither is never dithering true 10 bit.

XMonarchY

24th June 2015, 23:37

dithering is a way to lowering the bit deep. but you never get 10 bit in the monitor. so the monitor dither is never dithering true 10 bit.

What is FRC then? I thought FRC = dithering. Whichever dithering is used by FG2421, its very very good at preventing 1DLUT banding.

huhn

24th June 2015, 23:51

XMonarchY

25th June 2015, 16:08

if you would send an 10 bit signal to the display(which is not possible with this display) the FRC from this display would be used to let it look like 10 bit.

but currently it is just dithering the error from the internal processing.

nvidia can dither an 10 bit input from madVR down to 8 bit but it is very unlikely that this dither is better than madVR dithering. i hope nvidia is using something like random dithering.

windows CMS 1D calibrations have a bad quality. so the 10 bit input may force nvidia to use 10 bit processing on it so the results on the 1D LUT looks better than normal 8 bit if this is true. 10 bit madVR output should look better than 8 bit output on nearly all displays. on the other hand madVR overlay mode should stomp these results with is 16 bit+ processing of 1D LUT.

I use ArgyllCMS (via dispcalGUI) 1DLUT calibration, which is as good as it gets. I think dithering comes from the monitor, not nVidia drivers. Otherwise there would be the same dithering on my HDTV in 8bit mode, but there isn't.

madVR dithering is probably better than dithering I get on FG2421, but it is still excellent at removing banding.

huhn

25th June 2015, 16:11

XMonarchY

25th June 2015, 20:59

it can't dither 10 bit if it never gets 10 bit sorry it is that simple. so no the driver is dithering in this case. if nvidia would send 10 bit than the display would do the dithering using FRC but that's simply not the case

TV are a whole different beasts. alone the possibility that they are 4:2:2 or 4:2:0 sub sampling makes 10 bit very helpful.

and not even argyllCMS can fix windows CMS/gamma ramp of the GPU.

Ugh, are we talking about the same thing here? Here's what I am saying:
1. Eizo Foris FG2421 @ 8bit setting produces dithering (uses DisplayPort)
2. Samsung HDTV @ 8bit setting does NOT produce dithering (uses High-Speed HDMI cable)

Why would FG2421 produce dithering with 8bit signal and HDTV would not? Is it because of DisplayPort vs. HDMI difference? Or is it because FG2421's internal processing is what produces non-FRC dithering?

I mean plasma HDTV's dither with 8bit signal because HDTV's themselves (internal processing) use dithering. Why is it so impossible that an MVA screen can do something similar via its internal processing? The dithering on FG2421 (outside of madVR or any media playback) is THERE and its OBVIOUS with 8bit setting.

huhn

25th June 2015, 21:25

XMonarchY

25th June 2015, 21:37

the issue is that the eizo doesn't accept 10 bit input that's why it can't dither it because it never gets the 10 bit for the 10 times. if it would be possible to send 10 bit to the eizo it would be possible to dither this signal using FRC. if you see moving dither noise with a still standing picture that's the FRC working after the internal processing and this just shows how bad FRC can be just more noise...

nvidia ignores your settings if you set output bit deep to 8 bit when 10 bit is inputted in the driver and the display supports 10/12 bit input. so you can not force nvidia to dither on displays that support 10 or 12 bit input.

see here:
http://forum.doom9.org/showpost.php?p=1726964&postcount=178

All I am saying is that my observations go against what you're trying to tell me.

Outside of madVR (on desktop) Eizo Foris FG2421 + 8bit NVidia setting does produce dithering and the overall gradient banding is a LOT smoother than my Samsung HDTV's gradient banding using the same 8bit NVidia setting. That's a fact no matter what the cause/reason for it is.

huhn

25th June 2015, 21:46

looks like your samsung is pretty bad.

the desktop is 8 bit anyway.

XMonarchY

26th June 2015, 01:04

looks like your samsung is pretty bad.

the desktop is 8 bit anyway.

No, its not pretty bad. Its as good as my other 8bit IPS monitor that shows no dithering, unlike FG2421. When I say Desktop, I mean viewing grayscale gradients on desktop. There is a significant difference between 8bit and 12bit as far as my HDTV goes. At 8bit, without any 1DLUT, I can see each of the 0-255 levels (or however many levels provided PNG shows). At 12bit, I do not or there are so many of levels that I do not notice each individual one. 8bit on FG2421 has dithering that blends 0-255 levels, better than IPS and HDTV, but obviously not as good as 12bit on HDTV.

huhn

26th June 2015, 01:51

so i assume with desktop you mean 8 bit not dithered from madVR?

you should see banding in this case on all display with 8 bit or higher. if you don't see it the display is processing it with an debanding filter or something like that. so it is hiding details and does something in the back. which is by the way bad this banding could be intentional too.

XMonarchY

26th June 2015, 19:02

Another thing that is so weird is that on FG2421, when I disable dithering in madVR, use Exclusive mode, and toggle between 8bit and 10bit (in madVR) with the provided gradient PNG file, 10bit setting provides drastically smoother gradient than 8bit setting. Again, NVidia CP only allows 8bit input for FG2421.

What does this mean?

huhn

26th June 2015, 20:16

XMonarchY

26th June 2015, 22:05

the nvidia driver is dithering in this case.

But the same thing does not happen when I set HDTV to 8bit in NVidia CP and select 10bit in madVR. With HDTV, 8bit NVidia CP setting + 10bit madVR setting = 8bit NVidia CP setting + 8bit madVR setting in terms of gradient smoothness. With FG2421, selecting 8bit in NVidia CP and 10bit in madVR looks MUCH smoother than selecting 8bit in NVidia CP and 8bit in madVR.

Why would NVidia driver dither on FG2421, but not on HDTV when 8bit setting in selected in NVidia CP and 10bit setting is selected in madVR?

huhn

26th June 2015, 22:32

But the same thing does not happen when I set HDTV to 8bit in NVidia CP and select 10bit in madVR. With HDTV, 8bit NVidia CP setting + 10bit madVR setting = 8bit NVidia CP setting + 8bit madVR setting in terms of gradient smoothness. With FG2421, selecting 8bit in NVidia CP and 10bit in madVR looks MUCH smoother than selecting 8bit in NVidia CP and 8bit in madVR.

Why would NVidia driver dither on FG2421, but not on HDTV when 8bit setting in selected in NVidia CP and 10bit setting is selected in madVR?

james said 10 bit is send anyway when possible regardless of the setting. so your results are wired ask nvidia why they round the 10 bit input in your case.

on all my 8 bit input display and my 12 bit input TV 10 bit madVR always looked better than madVR 8 bit without dithering. regardless of the setting chosen.

XMonarchY

27th June 2015, 12:59

james said 10 bit is send anyway when possible regardless of the setting. so your results are wired ask nvidia why they round the 10 bit input in your case.

on all my 8 bit input display and my 12 bit input TV 10 bit madVR always looked better than madVR 8 bit without dithering. regardless of the setting chosen.

So just because a display does not support 10bit input does not mean it isn't 10bit+.

huhn

27th June 2015, 14:36

So just because a display does not support 10bit input does not mean it isn't 10bit+.

the conclusion is high bit deep dithered down looks better than 8 bit undithered.

XMonarchY

27th June 2015, 15:30

the conclusion is high bit deep dithered down looks better than 8 bit undithered.

That makes ZERO sense...

Eizo Foris FG2421 monitor (DisplayPort):
- 8bit input setting in NVidia CP + 8bit setting in madVR + madVR dithering disabled = obvious bands/banding
- 8bit input setting in NVidia CP + 10bit setting in madVR + madVR dithering disabled = no noticeable banding

Samsung HDTV (High-Speed HDMI):
- 8bit input setting in NVidia CP + 8bit setting in madVR + disabled madVR dithering = obvious bands/banding
- 8bit input setting in NVidia CP + 10bit setting in madVR + disabled madVR dithering = obvious bands/banding
- 12bit input setting in NVidia CP + 10bit setting in madVR + disabled madVR dithering = no noticeable banding

ASUS IPS monitor (DisplayPort):
- 8bit input setting in NVidia CP + 8bit setting in madVR + disabled madVR dithering = obvious bands/banding
- 8bit input setting in NVidia CP + 10bit setting in madVR + disabled madVR dithering = obvious bands/banding

Please explain to me why on Eizo Foris FG2421 8bit input setting in NVidia CP + 10bit setting in madVR + disabled madVR dithering produces no noticeable bands/banding, while the same exact settings DO produce obvious bands/banding on both Samsung HDTV and ASUS IPS monitor.

James Freeman

27th June 2015, 16:55

That makes ZERO sense...
Please explain to me why on Eizo Foris FG2421 8bit input setting in NVidia CP + 10bit setting in madVR + madVR dithering disabled produces no noticeable bands/banding, while the same exact settings DO produce obvious bands/banding on both Samsung HDTV and ASUS IPS monitor.

If I understand correctly this is in FSE 10bit DX1 right?
Try the same experiment but enable Dithering in madVR in 8bit (not 10bit), that should send 8bit dithered signal into the displays.
Please try that and post what you see.

XMonarchY

27th June 2015, 18:54

If I understand correctly this is in FSE 10bit DX1 right?
Try the same experiment but enable Dithering in madVR in 8bit (not 10bit), that should send 8bit dithered signal into the displays.
Please try that and post what you see.

Yes in FSE with D3D11.
- 8bit NVidia setting + 8bit madVR setting + madVR ED1 dithering = no banding, BUT it isn't as smooth as 8bit NVidia setting + 10bit madVR setting + disabled madVR dithering.

Besides, how does this explain the situation? It does NOT explain why on Eizo Foris FG2421 8bit input setting in NVidia CP + 10bit setting in madVR + disabled madVR dithering produces no noticeable bands/banding, while the same exact settings DO produce obvious bands/banding on both Samsung HDTV and ASUS IPS monitor.

kolak

29th June 2015, 09:18

Eizo panel is 8bit, but they use advanced dithering, so gradients look fine. Dithering is happening in the Eizo monitor, so your experiment does make perfect sense, you just have to know how to interpret it.
Eizo has probably the best electronics from all the monitor manufactures. Even if 2 companies use the same panel you can still have good or crap monitor out of it. Panel is the most important but electronics behind it are also important.

huhn

29th June 2015, 11:22

it would be that easy if nvidia has a option to choice 10 bit. so it never gets the 10 bit just 8 bit it can't dither is to 8 bit so the input 8 bit has to be banding free or the driver is lying.

spacediver

9th July 2015, 23:39

Since driver version 353.06 users can select bit depth in the Nvidia Control Panel on all systems.
If you can't see 10bit option in the CP, Nvidia will dither down to the bit depth selected if it is lower.

In other words, If you can't choose 10bit in nvidia CP and keep it on 8bit, when you run madVR in 10bit FSE, nvidia WILL Dither and you'll see smooth gradient, not true 10bit.
If you can select 10bit in Nvidia CP, the driver will NOT dither and sent true 10bit signal to your display.

Just ran the 10 bit gradient test, and can definitely notice a difference between 8 and 10 bit, with dithering disabled. I have a feeling, however, that Nvidia is dithering.

I have a Sony GDM-FW900 which is a (very nice) CRT. So the display itself is definitely capable of 10+ bit color. I'm using the DVI-I port on my Geforce card, and that feeds directly into the VGA input in the CRT.

I'm using the latest Nvidia drivers, but there is no option to select output color depth in the control panel:

I'm guessing this might be because I'm using analog DVI.

Does anyone have any suggestions on how to enable the color output option for my video card/display combination?

If only there were a way to "force" the card to try to send out 10 bit information, regardless of whether a 10 bit display is detected or not.

Asmodian

10th July 2015, 08:24

10-bit isn't really a concept that agrees with an analog connection. You are getting VGA, there is no 8 or 10-bit.

You do get better precision using 10-bit in madVR because you are feeding the digital to analog system in the video card a higher bit-depth.

huhn

10th July 2015, 11:54

it's very unlikely that the DAC for analog output is 10 bit. why should they add such a part in a GPU when it is very unlikely that it will ever get 10 bit.

spacediver

10th July 2015, 15:03

it's very unlikely that the DAC for analog output is 10 bit. why should they add such a part in a GPU when it is very unlikely that it will ever get 10 bit.

I've done some tests (http://www.avsforum.com/forum/139-display-calibration/1606473-using-psychophysics-method-adjustment-calibrate-gamma-based-jnds.html#post25836793) that suggest that the DAC on my card is at least 10 bits

spacediver

10th July 2015, 15:08

10-bit isn't really a concept that agrees with an analog connection. You are getting VGA, there is no 8 or 10-bit.

Not sure what you mean by this. Analog or digital signals both contain information, and can be characterized by a particular number of bits, afaik.

nevcairiel

10th July 2015, 15:13

Not sure what you mean by this. Analog or digital signals both contain information, and can be characterized by a particular number of bits, afaik.

Not necessarily. Analog signals are continous, while digital signals are "sampled". The number of bits is the resolution of the sampler, ie. the DAC or ADC.

An analog signal has infinite precision, how much information that really gives you all depends on the hardware to generate and receive this signal.

What you can measure is the precision of the DAC (graphics card) and/or ADC (ie. your measurement instrument), not the "signal" itself.

spacediver

10th July 2015, 15:36

Not necessarily. Analog signals are continous, while digital signals are "sampled". The number of bits is the resolution of the sampler, ie. the DAC or ADC.

An analog signal has infinite precision, how much information that really gives you all depends on the hardware to generate and receive this signal.

Fair enough.

What you can measure is the precision of the DAC (graphics card) and/or ADC (ie. your measurement instrument), not the "signal" itself.

I've done this, and the DAC is capable of at least 10 bits of precision. To me, this means that if I were able to force Nvidia drivers to output a 10 bit (digital) signal, the DAC would produce an analog signal that contained enough information to produce 10 bit color in my CRT.

nevcairiel

10th July 2015, 16:12

The configuration in the NVIDIA control panel is about actual output, but you do not output digital, so you cannot configure any bitdepth. The fact is, you do not know which bitdepth is fed to the DAC. All you can ever do is feed a high bitdepth signal to the driver (ie. by using madVR in 10-bit mode), and judge the result.

spacediver

10th July 2015, 16:37

If I could force the Nvidia drivers to feed a 10 bit digital signal to the DAC, I'm thinking I'd be able to get 10 bit color. As has been discussed in this thread, if you feed a 10 bit signal via DirectX, but Nvidia isn't configured for 10 bit output, it very likely dithers down to 8 bit. My thinking is that it should be possible to force Nvidia for 10 bit digital output (output to the DAC).

huhn

10th July 2015, 17:11

if the DAC is 10 bit. but why would they even create such a DAC?

your test was with a colorimeter these meter easily think a 8 bit dithered image is 11 bit or more.

spacediver

10th July 2015, 17:27

if the DAC is 10 bit. but why would they even create such a DAC?

If the DAC was only 8 bit, then it would be impossible to adjust the gamma without crushing certain levels together (unless dithering was involved). You'd have a choice of 256 levels per channel out of a palette of only 256 levels. With a 10 bit DAC, you have a choice of 256 levels out of a palette of 1024 levels.

your test was with a colorimeter these meter easily think a 8 bit dithered image is 11 bit or more.

Well you'd probably need an oscilloscope to test whether it's dithered or not. If anyone has one, I can provide Matlab code to do the test.

spacediver

10th July 2015, 23:38

So I just discussed this with a friend (same guy responsible for some of the best input lag measurements (http://www.esreality.com/post/2691945/microsecond-input-lag-measurements/) out there), and for this fine piece of detective work (http://www.overclock.net/t/1545382/csgo-m-rawinput-0-drops-samples). He reminded me of a discussion (http://hardforum.com/showthread.php?p=1041074839#post1041074839) we'd had over on hardforum, where he discovered that the default windows LUT actually truncates the range of possible values, presumably to ensure evenly spaced voltages. He's pretty convinced the DAC is true 10 bit, else it's hard to explain how dithering can account for the extra brightness you get for peak luminance when you use all 1024 possible values, rather than just up to 1023.

He's going to do some testing tonight (I might replicate them also). His idea is as follows:

Take L to be the luminance function of the display. With a perfect black level, a normalized peak luminance of 1 unit, and a gamma of, 2.4, then:

L(0) = 0, L(1) = 0.00000169, L(2) = 0.00000893, etc.

Say you want to specify a level between L(1) and L(2). Dithering will achieve this by alternating frames between L(1) and L(2), resulting in a luminance exactly halfway between, resulting in a luminance of (0.00000169+0.00000893)/2 = 0.00000531.

If, however, the precision of the DAC is high enough to actually send a voltage halfway between L(1) and L(2), then the resulting luminance will be 0.00000444.

This discrepancy can be used to our advantage to test for dithering, in the following way:

Set the slope of the LUT to 64 (in the context of 16 bit specification). This will mean that only the first 256 usable levels (out of 1024 usable levels) will be used. Measuring the luminance of each grayscale level will reveal whether dithering is being employed.

If there is no dithering, and the DAC is true 10 bit, then each luminance value will reflect the natural gamma of the CRT (which in my case, is around 2.8 the way I have the voltages calibrated).

If there is dithering, then the luminance will also show, overall, a 2.8 gamma function, but the curve will not look smooth: it will look like 64 line segments, because three out of every four values are being (linearly) interpolated through dithering.

omarank

28th July 2015, 06:16

To everyone:

AMD cards dither the output by default, but you can disable it:

http://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?pid=3314#pid3314

HDMI_DisableDither for HDMI. Reboot after.

Only that can explain why I see a difference between 8 and 10 bit output on my 6-bit DELL U2212HM connected with DVI :)
Can I just put all the three entries (for DP, DVI and HDMI) in the registry and be assured that there would be no dithering done by AMD driver, when using madVR?

Is there a downside to using this hack in other programs/ games?

huhn

28th July 2015, 09:32

Can I just put all the three entries (for DP, DVI and HDMI) in the registry and be assured that there would be no dithering done by AMD driver, when using madVR?

Is there a downside to using this hack in other programs/ games?

only use this "hack" for testing nothing else.

if AMD has to change the output bit deep for what ever reason you will loose a ton of picture quality.

voyager6868

9th August 2015, 21:21

@voyager6868, huhn

I have done another test and you may be correct about this assumption, nvidia does dither from higher bitdepths if the display is set to 8bit in nvidia control panel.
But the question that arises is whether nvidia dithers if the software calls for 10bit (madVR) and the display actually supports 10bit?
Does nvidia dithers then or actually switches to 10bit mode which the display can receive according to its EDID?

I think nvidia does NOT dither when the display actually supports 10bit and the software calls for 10bit.
A simple indicator is that my Dell U2410 monitor switches modes and shows a different input icon (top left) as though it changed inputs when switching between 8 and 10 bit.
When I try the same with HDMI, I don't see this input changing behavior from my screen, the screen blacks out and back on much quicker than when it actually switches to 10bit mode with DisplayPort input.

I think what we need here is more people with 10bit screens that have clear indicators that the screen is actually receiving 10bit input.
It very well may be that nvidia only dithers when there is a missmatch from higher to lower bit depth, and does not when there is a match.

I have proof now that nVidia (or something in Windows) dithers down to 8-bit, even if the display supports 10-bit or higher (unless you explicitly choose 10-bit or high in nVidia control panel).

I recently bought a new receiver TX-NR545 that fully supports HDMI 2.0. I was surprised to see that it actually will show the bit depth of the video signal that is being input!

If I set 8-bit in the nVidia control panel and do this test (set my screen to 10-bit in madVR, disable dithering in madVR, and am using the direct3d11 overlay), I see a nice smooth pattern, but the receiver indicates that it's receiving a 24-bit signal. I confirmed everything with Ctrl-J in MPCHC (the output is 10-bit).

Clearly, this shows that something is dithering the output before it gets sent to the TV and nVidia does not change the bitdepth of its output simply because a 10-bit overlay is used.

When I set the output to 12-bit in the nVidia control panel, the receiver properly shows that a 36-bit signal is being used.

Note that this is all at 4K @ 24Hz. I ran the test in both YCbCr and RGB modes with identical results.

omarank

10th August 2015, 07:00

only use this "hack" for testing nothing else.

if AMD has to change the output bit deep for what ever reason you will loose a ton of picture quality.
Ok. Actually I meant to ask, is it a bad idea to use this hack with all three registry keys enabled for a dedicated HTPC with an AMD card and a TV that is able to accept 10 bit video and processes in 10 bit or higher?

I am using 13.12 drivers and they don’t offer the selection of output bit depth in the control panel settings. When I connect my TV to my laptop with AMD graphics, the TV shows 10 bit signal even for Windows output (which must 8 bit padded to 10 bit). In this scenario I don’t think AMD driver would need to change the output bit depth in any case. By using the registry hack I can assume that the AMD driver won’t add any additional noise to madVR’s 10 bit output (D3D11 FSE), right?

huhn

10th August 2015, 21:38

if amd does touch the image it should enabled and if amd isn't touching it it shouldn't matter so it's just save to leave it enabled.

omarank

11th August 2015, 06:11

I have all got all processing disabled in AMD control panel except for ITC processing. Now if I think about it, AMD driver may touch the image for ITC processing. Is there any downside to disabling the ITC processing?

Has anyone tested the ITC processing with 10 bit output from madVR?

Arm3nian

23rd August 2015, 04:38

My display supports 10bit (8+frc) but the only option I have in nvidia CP is 8bit. I do see the difference in the test though. Using W10 and 980ti.

huhn

24th August 2015, 09:29

because the driver is dithering.

for some reasons some displays are sold with 8 bit +FRC but without 10 bit input support.

do you have an AMD card to double check this issue?

Arm3nian

25th August 2015, 05:10

because the driver is dithering.

for some reasons some displays are sold with 8 bit +FRC but without 10 bit input support.

do you have an AMD card to double check this issue?

No but another user with the P2715q on the dell forums had an AMD card and he couldn't set it to 10bit output either, while his other Samsung display supported it on the same card.

Doesn't matter though, my unit has a defective panel, so it's going back for a refund.

Is there any point in using 10bit on programs like madvr if the driver is set to 8?

huhn

25th August 2015, 05:20

it's unlikely the dithering from 10 bit to 8 bit is better than the 16 bit to 8 bit from madVR. but they should be different.

in term of quality it is better to dither just one time.

Arm3nian

25th August 2015, 05:43

it's unlikely the dithering from 10 bit to 8 bit is better than the 16 bit to 8 bit from madVR. but they should be different.

in term of quality it is better to dither just one time.

So if you set madVR to output 10bit then it dithers from 16 to 10, and your gpu would dither from 10 to 8. So better to just set madVR output to 8bit and be done.

huhn

25th August 2015, 05:46

So if you set madVR to output 10bit then it dithers from 16 to 10, and your gpu would dither from 10 to 8. So better to just set madVR output to 8bit and be done.

that should be the case if 10 bit can't be send.
if it is possible to send 10 bit it will not be dithered to 8 bit or at least it shouldn't do that.

sswroom

26th August 2015, 17:44

I have bought a new display card recently. Aero cannot be turn on when using 10-bit display mode. Does this mean that MadVR does not support 10-bit output in this display card? (AMD FirePro)
After doing some searching, nVidia has the same situration. ( http://nvidia.custhelp.com/app/answers/detail/a_id/3049/~/how-to-enable-30-bit-color-on-windows-platforms )

I have proved that it is outputting 10-bit signal using OpenGL (Photoshop) and DirectDraw (Other video player).

XMonarchY

26th August 2015, 18:02

I think it is absolutely true that some 10bit displays do not come with 10bit input support and end up dithering. That is the ONLY way to explain why these settings result in perfectly smooth image:
- 8bit settings in NVidia CP
- 10bit setting in madVR
- no dithering of any kind in madVR
- D3D11 in madVR
- Fullscreen Exclusive in madVR
- no 3DLUT in madVR

If I select 8bit in madVR, then I see very obvious and distinct 0-255 levels. If I select 10bit in madVR, then the image is 100x smoother and 0-255 levels are invisible and ArgyllCMS detects the image as 10bit!

huhn

26th August 2015, 18:09

a dithered 8 bit picture usually reports 11 bit in argyllCMS.

and the GPU can easily dither the 10 bit input and i already test if nvidia is dithering and it can do it.

try it with an AMD card you can even disable dithering for these cards.

it is impossible to dither 10 bit in a display that never get this signal it is that simple.

XMonarchY

26th August 2015, 19:17

huhn

26th August 2015, 19:27

nussman

26th August 2015, 19:36

"Nvidia CP 8bit output"
How you can test anything 10bit related with this setting?

huhn

26th August 2015, 19:38

you can test if the driver handles this properly or not that's it.

nussman

26th August 2015, 19:41

I agree. And maybe if dithering is used or not by the driver.
But how the display handels 10bit input? No way imho ...

XMonarchY

27th August 2015, 00:46

if i set madVR to 10 bit on a display that doesn't support 10 bit as an input the result is still smooth...

if you really want to know test it with an AMD card. these card have full control of the output.

you can send even 6 bit with them when the display supports it.

just send 10 bit in the driver and disable AMD dithering in the registry.

You did not explain anything. If I set madVR to 10bit on my monitor that supports only 8bit input, then the result is very smooth gradient (100x more than just 255 levels). However, if I set madVR to 10bit and set my TV (NOT monitor) to 8bit input in NVidia CP, then the result is good old visible 255 gradients.

That means the monitor DOES dither. If it was the driver that was dithering then it would dither on BOTH - monitor AND TV, but dithering and super-smooth gradient with 8bit input occurs ONLY in my monitor.

Asmodian

27th August 2015, 02:44

You did not explain anything. If I set madVR to 10bit on my monitor that supports only 8bit input, then the result is very smooth gradient (100x more than just 255 levels). However, if I set madVR to 10bit and set my TV (NOT monitor) to 8bit input in NVidia CP, then the result is good old visible 255 gradients.

That means the monitor DOES dither. If it was the driver that was dithering then it would dither on BOTH - monitor AND TV, but dithering and super-smooth gradient with 8bit input occurs ONLY in my monitor.

You do see how this is impossible don't you? If your monitor does not support 10-bit input it does not have the 10-bit data to dither from.

Maybe your monitor is lower contrast so you do not notice 8-bit steps while your TV is higher contrast so you do notice them? Maybe Nvidia doesn't dither when sending to your TV but does when sending to your monitor (HDMI behaves differently?). Or your monitor could be doing something like GradFun3 or flash3kyuu_deband, increasing noise to mask banding.

Your monitor is not dithering 10-bit to 8-bit if you send it 8-bit data.

XMonarchY

27th August 2015, 15:57

You do see how this is impossible don't you? If your monitor does not support 10-bit input it does not have the 10-bit data to dither from.

Maybe your monitor is lower contrast so you do not notice 8-bit steps while your TV is higher contrast so you do notice them? Maybe Nvidia doesn't dither when sending to your TV but does when sending to your monitor (HDMI behaves differently?). Or your monitor could be doing something like GradFun3 or flash3kyuu_deband, increasing noise to mask banding.

Your monitor is not dithering 10-bit to 8-bit if you send it 8-bit data.

This monitor has about 4700:1 static contrast ratio after calibration. The only difference between TV and monitor is that TV uses High-Speed HDMI 1.3 cable and monitor uses DisplayPort. There is no noise on monitor either...

I am seriously tempted to just send this monitor to one of you guys to show you how it works, but regardless of the reason, this monitor DOES PASS 10bit support test via whichever means. I have Samsung Galaxy S5 and wonder whether the video quality is good enough for me to demonstrate all the settings I use and the results (0 banding).

huhn

27th August 2015, 16:44

even a 6 vit TN panel can produce a smooth ramp you simply deny to understand how thinks work.

and of cause there is noise you simply don't see it is a dithering display.

for example there is no 12 bit display they don't exist.

XMonarchY

27th August 2015, 18:06

huhn

27th August 2015, 18:22

like every TV.

XMonarchY

28th August 2015, 01:41

like every TV.

But you said it isn't true 12bit, correct?

TV:
- 8bit in NVidia CP + 8bit in madVR = visible 255 levels (does not pass 10bit test)
- 8bit in NVidia CP + 10bit in madVR = visible 255 levels (does not pass 10bit test)
- 12bit in NVidia CP + 10bit in madVR = very smooth gradient, 255 levels are not visible (passes 10bit test)

Monitor:
- 8bit in NVidia CP + 8bit in madVR = visible 255 levels (does not pass 10bit test)
- 8bit in NVidia CP + 10bit in madVR = very smooth gradient, 255 levels are not visible (passes 10bit test)

In bold are identical settings on different displays, but one passes 10bit test (monitor), while the other does not (TV).

huhn

28th August 2015, 05:51

the thing you show there is that nvidia isn't dithering in this case nothing else for what ever reason.

i can now go and send 10 bit a 6 bit TN panel with the driver set to 6 bit and i will get a smooth gradient. what does this tell us?

the 6 bit TN is 10 bit?

XMonarchY

28th August 2015, 18:45

Why is it not dithering on TV then???

Why should one use 8bit setting in madVR if 10bit setting provides much smoother gradient, regardless of NVidia CP setting?

This test was designed to see whether the display supports 10bit or not. If selecting 6bit or 8bit in NVidia CP and then selecting 10bit on madVR results in very smooth gradient (much smoother than if 8bit was selected in madVR), then this test FAILS.

nussman

28th August 2015, 19:07

Oh man ...
MadVR Output 10bit => convert. to 8bit by nvidia with/without dithering => output 8bit by nvidia => input 8bit (TV/Display)
vs
madVR output 8bit => output 8bit by nvidia => input 8bit (TV/Display)

Why do you think you can test a display for 10bit support this way?
You can test the processing chain for your system and thats it.

XMonarchY

28th August 2015, 19:43

huhn

28th August 2015, 20:30

true 10 bit on an 8 bit FRC. think about it. even with 10 bit input this isn|t true 10 bit.

XMonarchY

29th August 2015, 15:14

10bit setting in madVR and 8bit setting in NVidia CP on monitor looks IDENTICAL to 10bit setting in madVR and 12bit setting in NVidia CP on TV.

huhn

29th August 2015, 15:52

like it should.

the only thing that's strange is that you get banding which one of your displays. the rest is working as it should.

in all my test the nvidia option is ignored output settings and sanding a 12 bit signal anyway when 10 bit is outputted. nvidia is bad for testing this anyway...

just repeating over and over again the last pages...

6233638

31st August 2015, 16:39

10bit setting in madVR and 8bit setting in NVidia CP on monitor looks IDENTICAL to 10bit setting in madVR and 12bit setting in NVidia CP on TV.If the NVIDIA Control Panel is set to 8-bit, that's what you get.
madVR sending a 10-bit output to the driver causes it to output a dithered 8-bit signal.
The output has to be set to 10-bit (DisplayPort) or 12-bit (HDMI) to get a true 10-bit output from madVR.

If you are only able to send an 8-bit signal to your display, I would recommend setting madVR to 8-bit so that madVR has control over the dither that is applied.

XMonarchY

31st August 2015, 20:10

If the NVIDIA Control Panel is set to 8-bit, that's what you get.
madVR sending a 10-bit output to the driver causes it to output a dithered 8-bit signal.
The output has to be set to 10-bit (DisplayPort) or 12-bit (HDMI) to get a true 10-bit output from madVR.

If you are only able to send an 8-bit signal to your display, I would recommend setting madVR to 8-bit so that madVR has control over the dither that is applied.

That makes no sense again. If selecting 8bit in NVidia CP and 10bit in madVr results in madVR dithering 8bit and smooth gradient, then why set madVR to 8bit. Its the one dithering 8bit, so it has control one way or another.

huhn

31st August 2015, 20:35

if you set madVR to 10 bit the result is 10 bit and that is what the driver gets. if the driver can't send 10 bit to the display is has to change the 10 bit to 8 bit.

just as a reminder the nvidia setting is ignoring the setting anyway with 10 bit input. and that a reason nvidia is bad for testing this. this option is more to see if the display can handle high bit deep inputs the rest is not really important.

6233638

1st September 2015, 00:10

That makes no sense again. If selecting 8bit in NVidia CP and 10bit in madVr results in madVR dithering 8bit and smooth gradient, then why set madVR to 8bit. Its the one dithering 8bit, so it has control one way or another.No, madVR's output is still 10-bit if it is configured to be 10-bit.
What the GPU actually sends to the display is set in the NVIDIA Control Panel.

So if the Control Panel is set to 8-bit, the driver dithers the 10-bit input from madVR to an 8-bit output for the display.

This means that you have madVR processing in 16-bit, dithering to 10-bit, and then the driver dithering that to 8-bit.
Instead, what you should do is have madVR process in 16-bit, dither to 8-bit, and have the driver pass that to the display.
That way the driver does a straight pass-through of madVR's output: no additional dither is applied.

Unfortunately, NVIDIA seems to process the GPU LUT with as much precision as the output is set to and it is also undithered, so if you're using LUTs for calibration you need to be using madVR for that purpose to avoid banding.
I wouldn't use touch the GPU LUTs at all with an NVIDIA GPU if you're only sending an 8-bit signal to your display.

Apparently AMD process the GPU lut with more than 8-bits of precision and then (optionally?) dither to 8-bit. This means that you shouldn't get any banding if you use the GPU LUT for calibration.

if you set madVR to 10 bit the result is 10 bit and that is what the driver gets. if the driver can't send 10 bit to the display is has to change the 10 bit to 8 bit.

just as a reminder the nvidia setting is ignoring the setting anyway with 10 bit input. and that a reason nvidia is bad for testing this. this option is more to see if the display can handle high bit deep inputs the rest is not really important.It's not entirely clear to me what you are saying with "the nvidia setting is ignoring the setting anyway" but if the NVIDIA Control Panel is set to a 12-bit output (and I assume 10-bit as well - I don't have any DisplayPort displays here) then it does output a 12-bit signal to the display.
So with madVR, or any other software that can output a 10-bit signal, you do get true 10-bit gradation sent to the display.

What the NVIDIA driver seems to be doing is simply multiplying the input values to reach the desired output bit-depth. That output appears to be undithered on my display.
So a program outputting an 8-bit image should look identical whether the NVIDIA Control Panel is set to 8-bit or 12-bit - it won't harm image quality at all. (i.e. undithered 8-bit is still undithered when the output is set to 12-bit)
Setting the Control Panel to 12-bit just enables software to display more than 8-bits of gradation if supported.

huhn

1st September 2015, 07:15

6233638

1st September 2015, 10:16

with HDMI even when it is set to 8 bit it will stills send 12 bit when the driver input is 10 bit.

with other words you can't force it to send 8 bit with an 10 bit input when 12 bit is possible.
at least my sony clearly said 36 bit with and without output set to 12 bit and only as long as 10 bit was send to the driver. this option is still pretty new and even without this option it worked fine.

and all my displays without 10 bit or higher input get an dithered result when 10 bit is send to the driver.Interesting. My display (also a Sony TV) doesn't actually report the input bit-depth but I have been able to visually confirm that when the NVIDIA Control Panel is set to 8-bit, the 10-bit output from madVR is being dithered by the driver to 8-bit.
Perhaps the output from the GPU to the display is still a 12-bit signal, but the actual image being sent is definitely 8-bit, since I can see the dither being added.
And when the Control Panel is set to 12-bit, I'm getting true 10-bit gradation with no dither or banding.

It's difficult to show, but you should be able to make it out:

madVR set to a 10-bit undithered output in both cases.
12-bit HDMI: True 10-bit image. Any grain/noise visible here is the camera.
8-bit HDMI: Driver has dithered the 10-bit input to an 8-bit output. You can see that the input from madVR was still undithered though, as every fourth bar is a solid area of color. (equal to an 8-bit value)

http://abload.de/img/10-bitt8j11.gif

madVR set to an 8-bit output, with HDMI set to 8-bit. (though the results are the same with 12-bit)
No dither: Much wider banding. 4 bands in 10-bit = 1 band in 8-bit, as expected.
Random Dither: No banding at all, but noisy.

http://abload.de/img/8-bitgojo8.gif

I should have also taken a photo of 10-bit with Random Dither enabled, to show that it is equally free of banding, but has a lower noise level than 8-bit.
Note that only random dither will completely eliminate all banding, however this is at the cost of higher noise.
I have madVR set up with a profile so that windowed mode (8-bit) uses error diffusion dither (low noise) and fullscreen exclusive mode (10-bit) uses random dither, since that guarantees there will be no banding in FSE, and 10-bit random dither is lower noise than 8-bit error diffusion.

If the NVIDIA Control Panel does not have the option to output a 10-bit or 12-bit signal to your display, madVR should be set to an 8-bit output so that it has complete control over the dither being applied.
The exception to this might be if you're also using the GPU LUT for calibration rather than madVR's 3DLUT capabilities.
Since the driver seems to process the LUT with as much precision as the output, forcing it to process in 10-bit may result in a smoother output.

huhn

1st September 2015, 13:39

interesting nvidias behavior is very in consisted.

the 55w805b i own for about 2 hours. it has changed the hdmi to hdmi 36 bit when 10 bit was inputted in the driver.

i used a kelper 760 gtx for testing.

which 10 bit sony did you used?

6233638

1st September 2015, 15:49

It's an older Sony HX900 that I am testing with. It has a 10-bit panel (as you can clearly see) but it doesn't report the input bit-depth in the OSD for some reason.

So the GPU may still be sending it a "12-bit" signal when madVR's output is set to 10-bit and the Control Panel is set to 8-bit - I have no way to confirm that.
However it doesn't matter what bit-depth is reported on the display.
If the NVIDIA Control Panel is set to an 8-bit output, the image being displayed is an 8-bit dithered one.

huhn

1st September 2015, 18:56

older high end screen had some times a 10 bit panel before they found out what dithering is.

even through sony is know for 8 bit but with the best processing. in the end they buy them from over producer anyway.

XMonarchY

5th September 2015, 14:03

Interesting. My display (also a Sony TV) doesn't actually report the input bit-depth but I have been able to visually confirm that when the NVIDIA Control Panel is set to 8-bit, the 10-bit output from madVR is being dithered by the driver to 8-bit.
Perhaps the output from the GPU to the display is still a 12-bit signal, but the actual image being sent is definitely 8-bit, since I can see the dither being added.
And when the Control Panel is set to 12-bit, I'm getting true 10-bit gradation with no dither or banding.

It's difficult to show, but you should be able to make it out:

madVR set to a 10-bit undithered output in both cases.
12-bit HDMI: True 10-bit image. Any grain/noise visible here is the camera.
8-bit HDMI: Driver has dithered the 10-bit input to an 8-bit output. You can see that the input from madVR was still undithered though, as every fourth bar is a solid area of color. (equal to an 8-bit value)

http://abload.de/img/10-bitt8j11.gif

madVR set to an 8-bit output, with HDMI set to 8-bit. (though the results are the same with 12-bit)
No dither: Much wider banding. 4 bands in 10-bit = 1 band in 8-bit, as expected.
Random Dither: No banding at all, but noisy.

http://abload.de/img/8-bitgojo8.gif

I should have also taken a photo of 10-bit with Random Dither enabled, to show that it is equally free of banding, but has a lower noise level than 8-bit.
Note that only random dither will completely eliminate all banding, however this is at the cost of higher noise.
I have madVR set up with a profile so that windowed mode (8-bit) uses error diffusion dither (low noise) and fullscreen exclusive mode (10-bit) uses random dither, since that guarantees there will be no banding in FSE, and 10-bit random dither is lower noise than 8-bit error diffusion.

If the NVIDIA Control Panel does not have the option to output a 10-bit or 12-bit signal to your display, madVR should be set to an 8-bit output so that it has complete control over the dither being applied.
The exception to this might be if you're also using the GPU LUT for calibration rather than madVR's 3DLUT capabilities.
Since the driver seems to process the LUT with as much precision as the output, forcing it to process in 10-bit may result in a smoother output.

Again, I don't understand why that is needed. If 8bit is selected in NVidia CP and 10bit is selected in madVR, the image is much smoother than if 8bit is selected in madVR. All that assuming no madVR dithering and proper settings.

huhn

5th September 2015, 14:07

All that assuming no madVR dithering and proper settings.

yeah 8 bit rounded looks terrible. so of cause...

Arm3nian

6th September 2015, 21:29

What bit depth output do modern "consumer" nvidia gpus support? Lots of threads say you need a quadro to get 10bit but that sounds wrong.

aufkrawall

6th September 2015, 22:10

Are there any news regarding DWM bitdepth on Windows 10?

huhn

6th September 2015, 22:51

What bit depth output do modern "consumer" nvidia gpus support? Lots of threads say you need a quadro to get 10bit but that sounds wrong.

all GPU can output 10/12 bit and you can give the driver 10 bit with a fullscreen directx 10 surface for years.

Are there any news regarding DWM bitdepth on Windows 10?

no just rumors in the first place.

Asmodian

6th September 2015, 23:37

What bit depth output do modern "consumer" nvidia gpus support? Lots of threads say you need a quadro to get 10bit but that sounds wrong.

To expand on what huhn said. They are partially correct; you need a Quadro/FirePro to use 10-bit with OpenGL. There probably is one but I don't know of any video player that uses OpenGL. madVR using DX11 FSE to display 10-bit is the only way I know of to watch video in 10-bit on a PC and it works on any DX11 capable GPU.

Windows is always rendered in 8-bit, even with a Quadro.

edit: The above is not a comment about the Windows 10 DWM rumors, only that a Quadro does not change Windows' behavior.

Arm3nian

7th September 2015, 02:26

all GPU can output 10/12 bit and you can give the driver 10 bit with a fullscreen directx 10 surface for years.

To expand on what huhn said. They are partially correct; you need a Quadro/FirePro to use 10-bit with OpenGL. There probably is one but I don't know of any video player that uses OpenGL. madVR using DX11 FSE to display 10-bit is the only way I know of to watch video in 10-bit on a PC and it works on any DX11 capable GPU.

That's what I thought. So your gpu should not be a problem to get 10bit in madVR, unless it's ancient.

The problem then is actually selecting 10bit out. My P2715q did not have an option to select 10bit with my 980ti. I returned it since it had a defective panel, but it seems there is some type of hack to make it accept 10bit input. The user on the Dell forum had a quadro and he edited the EDID through NCP to select 10bit. But you can use a 3rd party program if you have don't have a workstation card.

I don't understand why some 10bit displays cannot accept a 10bit input signal by default. It must be due to driver problems. Isn't a 10bit panel basically useless if it cannot accept a 10bit input?

I will be getting the EA275UHD-BK from NEC soon and will report my results. The gpu supports 10bit, the panel supports 10bit, and the renderer supports 10bit, so you should be able to get 10bit easily on a proper display and not be held back by a random anomaly.

huhn

7th September 2015, 03:33

a 10 bit or 8 bit + FRC display with 8 bit input only can use this to lower the error on internal processing.

and yes well known problem: http://en.community.dell.com/support-forums/peripherals/f/3529/t/19615254

i don't know a 10 bit display that doesn't allow 10 bit input. 8 bit + FRC is more like a marketing thing to me anyway. i mean just look at a 6 bit + FRC it's smooth yes but it's nothing like a real 8 bit panel.

6233638

7th September 2015, 15:54

Again, I don't understand why that is needed. If 8bit is selected in NVidia CP and 10bit is selected in madVR, the image is much smoother than if 8bit is selected in madVR. All that assuming no madVR dithering and proper settings.It is smoother because you are comparing 8-bit dithered to 8-bit undithered.
The driver is doing the dithering from 10-bit to 8-bit instead of madVR.
To get an actual 10-bit output, the output in the NVIDIA Control Panel must be set to ≥ 10-bit.

What bit depth output do modern "consumer" nvidia gpus support? Lots of threads say you need a quadro to get 10bit but that sounds wrong.You need to be using Windows 7 with Aero disabled and a Quadro if you want a 10-bit OpenGL output from Adobe's applications.
I thought that you also needed a FirePro/FireGL card from AMD if you wanted 10-bit support there too.

A full-screen exclusive D3D11 output can support > 8-bit on consumer GPUs.
The only two applications I am aware of which use this mode are madVR and the game Alien: Isolation (http://store.steampowered.com/app/214490/).

I don't understand why some 10bit displays cannot accept a 10bit input signal by default. It must be due to driver problems. Isn't a 10bit panel basically useless if it cannot accept a 10bit input?It's not entirely useless if the display has an internal LUT for calibration.
The internal processing/calibration can still be ≥ 10-bit despite the input only being 8-bit.
Performing that sort of processing in 8-bit would result in a lot of banding/posterization.

It would, of course, be best to preserve as much precision throughout the process as possible and send them a 10-bit input though. (or > 10-bit)
Eizo displays have 16-bit internal processing for example, so you would always want to perform calibration inside the display, rather than the GPU LUT.

Arm3nian

7th September 2015, 21:16

a 10 bit or 8 bit + FRC display with 8 bit input only can use this to lower the error on internal processing.

i don't know a 10 bit display that doesn't allow 10 bit input. 8 bit + FRC is more like a marketing thing to me anyway. i mean just look at a 6 bit + FRC it's smooth yes but it's nothing like a real 8 bit panel.

It's not entirely useless if the display has an internal LUT for calibration.
The internal processing/calibration can still be ≥ 10-bit despite the input only being 8-bit.
Performing that sort of processing in 8-bit would result in a lot of banding/posterization.

Yeah this explains that: http://www.eizo.com/library/basics/maximum_display_colors/

Eizo displays have 16-bit internal processing for example, so you would always want to perform calibration inside the display, rather than the GPU LUT.

The NEC display I linked doesn't have a high bit LUT but it does have 14bit internal processing. Are you saying giving madVR a 3D LUT would degrade color quality? Or are you talking about the higher end displays like this one http://www.necdisplay.com/p/desktop-monitors/pa322uhd-bk that have a 14bit 3D LUT built in. Or is this something completely different.

huhn

7th September 2015, 21:30

using madVR with a 3D LUT to calibrate your screen isn't lowering the quality.
some high end displays for photo usage have a pretty good color correction which maybe better than a 3d LUT, but i doubt this... with madVR you can create a 16 bit 256³ 3D LUT which is hard to beat.

the GPU gamma ramp is a bad joke avoid this if possible and thanks to madVR you can avoid it.

6233638

7th September 2015, 22:19

using madVR with a 3D LUT to calibrate your screen isn't lowering the quality.It depends on what the display's capabilities are.
If it has a 10-bit panel, but only accepts an 8-bit input, you would be better doing the calibration inside the display.
Even if the display is 8-bit+FRC it may be better to use internal processing, as the FRC may be operating at a much higher frequency than madVR. (which only dithers once per frame)

huhn

7th September 2015, 22:23

i highly doubt the controls can provide an as accurate picture as a 3d LUT in the first place.

and madVR dithering should be higher quality too. taking response time of LCD display into account i don't see how FRC can be any good even with an crappy TN.

nevcairiel

7th September 2015, 22:25

i highly doubt the controls can provide an as accurate picture as a 3d LUT in the first place.

Maybe, maybe not. But if your TV offers any decent CMS features, you should still use them to get as close to a good result as you can, and the finish it with a 3DLUT.

XMonarchY

16th September 2015, 19:47

How is FRC different from 10bit to 8bit driver dithering? I thought FRC was a TYPE of dithering.

Asmodian

17th September 2015, 02:57

FRC is temporal dithering while driver (or madVR) dithering is spacial dithering. I prefer spacial dithering, at least for 8 to 6-bit on LCDs as I have never specifically tested 10 to 8-bit dithering methods, but both techniques work.

It depends on what the display's capabilities are.
If it has a 10-bit panel, but only accepts an 8-bit input, you would be better doing the calibration inside the display.
Even if the display is 8-bit+FRC it may be better to use internal processing, as the FRC may be operating at a much higher frequency than madVR. (which only dithers once per frame)

Given pixel transition times is it possible to have an LCD dither much faster than the frame times? Do the manufactures know the color displayed during the transition and account for it in the dither algorithm?

XMonarchY

17th September 2015, 16:39

So in your opinion, 8bit input + 10bit to 8bit dithering by the driver provides better picture quality / gradient transitions than 10bit input on an 8bit + FRC display?

Wouldn't drive dithering occur regardless of the input/output bit depth, even on top of FRC?

I was also told that 12bit TV's do not exist, yet my TV allows for a 12bit input/output. Does that mean it is only 10bit + FRC dithering + driver dithering?

huhn

17th September 2015, 16:41

internal processing in TVs is easily 10 or 12 bit

XMonarchY

17th September 2015, 22:14

internal processing in TVs is easily 10 or 12 bit

I do not understand... Did you not say that there are NO TV's that can do 12bit? Are you saying they are all internal processing @ 12bit and then the actual LCD is only 8bit? So there are no true 10bit TV's and displays out there? How do you know this for a fact?

Asmodian

17th September 2015, 22:27

So in your opinion, 8bit input + 10bit to 8bit dithering by the driver provides better picture quality / gradient transitions than 10bit input on an 8bit + FRC display?

In my opinion having madVR dither to 6-bit is better than sending a 6-bit+FRC monitor 8-bit. I do not know how this translates to an 8-bit+FRC display but I would suspect I would prefer 8-bit dithered by madVR to sending 10-bit to the display but I could be wrong. As I said I have not tested this. I do not know why I would ever have the driver do the dithering.

I do not understand... Did you not say that there are NO TV's that can do 12bit?

That was when discussing panel bit-depth, internal processing bit-depth is not the same as panel bit-depth.

10-bit is the most any panel can actually display but it is possible for a TV to accept 12-bit input, do any internal processing in 14-bit, and then dither to 10-bit for display.

baii

17th September 2015, 22:30

Internal processing range from say 8 to 16 bit. For consumer color display, there aren't any panel more than 1
0 bit. True 10bit VA aren't that rare.

Sent from my 306SH

huhn

17th September 2015, 22:42

Internal processing range from say 8 to 16 bit. For consumer color display, there aren't any panel more than 1
0 bit. True 10bit VA aren't that rare.

Sent from my 306SH

the are going to be standard soon.

XMonarchY

20th September 2015, 05:27

OK, so why is it NVidia drivers, in my case, dither ONLY my FG2421 display, but not my Samsung HDTV when 8bit is selected for both? TV is connected via High Speed HDMI and FG2421 via DisplayPort.

Asmodian

20th September 2015, 06:22

OK, so why is it NVidia drivers, in my case, dither ONLY my FG2421 display, but not my Samsung HDTV when 8bit is selected for both? TV is connected via High Speed HDMI and FG2421 via DisplayPort.

I suppose it is because Nvdia still doesn't quite understand what it means to output video correctly. Checking for correct dithering might be hard in their QC process. :p

This is one of the reasons I always have madVR dither to the output bit-depth. It is hard to beat ED 1 or 2 and they add very little visible noise even if there is further processing by the display. Even ordered dithering is quite good and it is extremely low noise. :)

omarank

20th September 2015, 08:19

Note that only random dither will completely eliminate all banding, however this is at the cost of higher noise.

What about Error Diffusion Option 2 (low noise) at 10 bit? At 8 bit, it tends to show patterns, but at 10 bit those patterns should not be visible. Do you find that this option still doesn’t completely remove banding at 10 bit output?

pankov

20th September 2015, 11:22

OK, so why is it NVidia drivers, in my case, dither ONLY my FG2421 display, but not my Samsung HDTV when 8bit is selected for both? TV is connected via High Speed HDMI and FG2421 via DisplayPort.
XMonarchY,
why don't you connect the monitor also via HDMI (may be not at the same time as the TV if you don't have multiple HDMI ouputs) so you can rule out the output type causing the difference?
After all it's been so long that you discuss this topic and you should do your best to compare apples to apples not to oranges.

huhn

20th September 2015, 11:25

he should use AMD for this.

pankov

25th September 2015, 23:39

huhn,
I'm not saying that he should judge the supported bitdepth of his monitor but simply try to find why the two displays he uses behave differently.
After all it does sound strange that only one of them dithers, doesn't it?

huhn

26th September 2015, 00:00

and that's why AMD is way better to test this.

you have full control over the output bitdeep 12 bit 10 bit 8 bit or even 6 bit if possible. you can disable the drivers dithering.

nvidia is more than strange even with output set to 8 bit it is still sending a 12 bit signal to the end device when the driver gets more than 8 bit as an input. according to 6233638 it looks different which doesn't make a lot of sense. so it either is ignoring this setting for my TV and not for 6233638 or it is send 8 bit in 6233638 case.

6233638

26th September 2015, 01:39

nvidia is more than strange even with output set to 8 bit it is still sending a 12 bit signal to the end device when the driver gets more than 8 bit as an input. according to 6233638 it looks different which doesn't make a lot of sense. so it either is ignoring this setting for my TV and not for 6233638 or it is send 8 bit in 6233638 case.NVCP 8-bit, madVR 8-bit: 8-bit signal, no GPU dither
NVCP 8-bit, madVR 10-bit: 8-bits precision displayed, GPU dithers 10-bit > 8-bit
NVCP 12-bit, madVR 8-bit: 12-bit signal with 8-bits precision displayed, no GPU dither
NVCP 12-bit, madVR 10-bit: 12-bit signal with 10-bits precision displayed, no GPU dither

I don't know how to make it any more concise.
I do wish the forum supported tables though, it would make formatting easier.

What about Error Diffusion Option 2 (low noise) at 10 bit? At 8 bit, it tends to show patterns, but at 10 bit those patterns should not be visible. Do you find that this option still doesn’t completely remove banding at 10 bit output?The issue seems to be that any value which is equal to one in the output bit-depth has "no error" and thus will not have any dither applied to it when using error diffusion.
These areas without dither are distinct when they are next to areas which do have dither.
So it results in visible "bands" in the image, even though they are not errors due to imprecision.
Only random dither seems to eliminate this.

This comparison hopefully demonstrates the issue. I know that it can be difficult to see.
http://abload.de/img/dither-comparet5oik.gif
This image has those undithered bands marked to highlight the area you should be looking at. (http://abload.de/img/dither-2w4urd.gif)

10-bits is not enough precision to eliminate this, in my testing.
But it may depend on how much you notice banding. Some people are more sensitive to it than others.

huhn

26th September 2015, 03:12

NVCP 8-bit, madVR 10-bit: 8-bit signal, GPU dithers 10-bit > 8-bit

in this case it is still sending 12 bit and this doesn't make sense.

6233638

26th September 2015, 03:48

in this case it is still sending 12 bit and this doesn't make sense.Your display is reporting a 12-bit input, or the display is capable of showing 12-bit gradation?

My display does not report the input bit-depth, so it is possible that the signal is 12-bit.
Irrespective of the signal bit-depth, there is only 8-bits of precision in use.

huhn

26th September 2015, 05:17

the display was reporting 12 bit.

we talked about this before. just showing nvidia behaviour isn't transparent.

XMonarchY

1st October 2015, 00:30

If madVR's 10bit settings on an 8bit display can force 10bit to 8bit dithering from NVidia driver, then can't other applications do? There's got to be a registry entry or something that force 10bit to 8bit dithering. I also know AMD cards allow selection of 10bit on all displays, regardless of display's true bit-depth. That setting triggers 10bit to 8bit dithering on 8bit display, doesn't it? NVidia needs to step up with these kind of features.

huhn

1st October 2015, 02:32

If madVR's 10bit settings on an 8bit display can force 10bit to 8bit dithering from NVidia driver, then can't other applications do?
in theory yes. 10 bit output is rarely used.
There's got to be a registry entry or something that force 10bit to 8bit dithering. I also know AMD cards allow selection of 10bit on all displays, regardless of display's true bit-depth. That setting triggers 10bit to 8bit dithering on 8bit display, doesn't it? NVidia needs to step up with these kind of features.

AMD only let you select the bit deep the screen allows as an input. 10 bit isn't always possible: http://abload.de/img/amdbitdeeprrs6z.png

if the input in the driver is higher than the selected or possible bit deep it will dither to the selected bit deep with AMD. nvidia should do the same. and at least for me it does.

it took nvidia years to add limited range and full range as an option in the driver so...

XMonarchY

1st October 2015, 04:33

huhn

1st October 2015, 06:14

Gotcha!

BTW, I can still select 12bit output for my Samsung TV even without post-processing using "PC Mode" (4:4:4 direct pass-through mode or 1:1 pixel mode - it has many names, depending on the manufacturer). Does that mean that in that mode there isn't any internal 12bit LUT processing? It passes 10bit madVR test when 12bit is selected in NVidia CP with TV's "PC Mode" enabled. UNLIKE my monitor, this TV does NOT pass when 8bit is selected in NVidia CP and 10bit is selected in madVR - there is no 10bit-to-8bit dithering. However, I am more curious about how and why "PC Mode" manages to pass 10bit madVR test when 12bit is selected in NVidia CP. That means it either bypasses internal 12bit processing and just uses pure 10bit mode, doesn't it?
it's a black box.

it could take the 12 bit with 10 bit information and always dither this to 8 bit in the first place before doing anything else.

or it could use 16 bit processing on it and dither at the end we don't know it a black box.

and setting at your TV shouldn't change the EDID and what the TV supports as input. but there is a chance a TV in gaming mode lowers internal processing for low input lag.
A few more odd things:
1. When I run ArgyllCMS bit-depth test (on desktop, not madVR), I get "unknown/undetermined" bit-depth result for my TV when its using 12bit setting in NVidia CP in BOTH - "Movie Mode" with post-processing (although all of it is disabled in TV options) and in "PC Mode". That means that "PC Mode" and "Movie Mode" both use internal 12bit processing. How can this be reconciled at all then?
you can't check internal processing with this test. the windows desktop is 8 bit and the picture send isn't worth anything more no matter if your meter reads this as 10 or 12 bit it just shows how powerful dither is.
2. Wen I use ArgyllCMS bit-depth test (on desktop, not madVR), I get "10bit depth" result for my Eizo monitor when it is using 8bit setting in NVidia CP!!! How is that possible? That would be possible only if NVidia dithers from 10bit-to-8bit by default, without madVR's request for 10bit, BUT that also makes no sense because in that case, 8bit NVidia setting and 8bit madVR setting would result in passing 10bit test (no visible banding on gradeints) since NVidia would dither from 10bit to 8bit by default, regardless of madVR's bit-depth setting!

as long as madVR isn't using d3d11 in FSE with 10 bit it is sending 8 bit (or lower) and if you haven't disabled dither it can be read easily as 11 or 12 bit. it doesn't matter what settings are used in NVIDIA the picture only holds 8 bit information nothing more in this case. it is technically not possible with the windows desktop

baii

1st October 2015, 16:30

Argyll bit depth test report video card gamma bit depth (dcg documentation). "The apparent VideoLUT entry number of significant bits." (From Argyll documentation)

Sent from my 306SH

panetesan2k6

2nd October 2015, 19:44

Hi.

I openend the gradient png in Photoshop. Even at 1:1 fullscreen I see banding. Then I follow the procedure and MadVR shows me no banding.

My equipment:

Win8.1 x64
GTX 970
Asus VS239 IPS

I gather that Windows only works in 8 bit color depth. There is no option to change color from 32bit to 40bit in the Nvidia panel.

Also, I understand that either the monitor accepts 10bit from MadVR FSE or the Nvidia driver is outputing 8bit after doing 10bit > 8bit+dithering.

huhn

2nd October 2015, 20:08

photoshop doesn't even dither and they want money for the tool?

panetesan2k6

2nd October 2015, 20:33

I moved on to test on my TV, this time through my laptop.

Win8.1 x64
Samsung B651 32"
Radeon Mobility HD5670

Before adding the "no dither" entry to the registry:

CCC: 8 bit RGB 4:4:4 Full
MadVR FSE = Smooth gradient.
MadVR no FSE = Banding gradients.

CCC: 10 bit RGB 4:4:4 Full
MadVR FSE = Smooth Gradient.
MadVR no FSE = Banding Gradient.

After adding the "no dither" entry to the registry:

CCC: 8 bit RGB 4:4:4 Full
MadVR FSE = Banding gradients.
MadVR no FSE = Banding gradients.

CCC: 10 bit RGB 4:4:4 Full
MadVR FSE = Smooth Gradient.
MadVR no FSE = Banding Gradient.

So...

-Either the display is not compatible with 8bit
-Either you need to set CCC to 10bit
-Either is not compatible with 8bit and setting CCC to 10bit only forces back dithering.

What do you think?

Tomorrow I will test the same TV with the GTX 970, just to see how interacts with the NVIDIA hardware.

huhn

2nd October 2015, 20:51

can you make a screen from the none FSE?

panetesan2k6

3rd October 2015, 03:22

can you make a screen from the none FSE?

I'm gonna make some more tests tomorrow and will take that screens.

I'm planning to cross tests between monitor/TV and laptop/desktop, just to try and narrow down what hardware is doing what.

So exciting :D

panetesan2k6

3rd October 2015, 04:16

Just wondering.

Let's assume I conclude that my Asus monitor can do 10 bit through this tests though it doesn't say so anywhere in specs... Why is not posible to set desktop color to 40bits? Is it because the EDID is telling the graphics card that the monitor can only do 8 bit? I would like to override this and try Windows in 40bit, mainly because photo editing.

huhn

3rd October 2015, 06:30

the reason is windows can't do 10 bit in desktop. you need a quadro card to do this with photpshop. and i guess an type of openGL overlay is used in this case to get 10 bit.

as long as the monitor EDID say it is 8 bit is will never get 10 bit from the GPU driver.

panetesan2k6

3rd October 2015, 12:07

Well, there you go.

http://s25.postimg.org/irhu62f0b/10bit_tests.jpg (http://postimg.org/image/irhu62f0b/)

I don't know what to think about the displays capabilities. Either:

A) Displays are capable of 10bit (assuming Nvidia is not dithering in any case) but Catalyst needs to be set to 10bit (if this NOT means bypassing the registry DWORD back to dithering...)
B) None of the displays are capable of 10bit; Nvidia is dithering always and Catalyst too, but if you disable dithering in the registry for Catalyst, it comes back on when selecting 10bit in CCC.

:rolleyes:

huhn

3rd October 2015, 20:07

the asus can't accept a 10 bit signal so nothing to bother about.

and did you disable dithering in madVR?

panetesan2k6

3rd October 2015, 20:17

the asus can't accept a 10 bit signal so nothing to bother about.

Then I have to assume that Nvidia dithered 10bit to 8bit, right?

If it were the monitor dithering, it would have done it as well in the other scenarios.

and did you disable dithering in madVR?

Yes.

huhn

3rd October 2015, 20:24

the monitor doesn't have an option to choice 10 bit so it never gets 10 bit.

everything is working as it should.

aufkrawall

3rd October 2015, 20:46

That AMD 8 bit dithering is probably also helpful in games?

Asmodian

3rd October 2015, 21:13

That AMD 8 bit dithering is probably also helpful in games?

No games are always rendered in 8-bit.

XMonarchY

3rd October 2015, 23:46

No games are always rendered in 8-bit.

Banding/gradients are smoother though. Also, some games, like Alien: Isolation, support 10bit and it can be enabled in options.

Asmodian

3rd October 2015, 23:58

Banding/gradients are smoother though. Also, some games, like Alien: Isolation, support 10bit and it can be enabled in options.

Maybe disabling AMD's dithering turns off dithering after a color calibration is applied?

When taking the 8-bit video rendered by a game and sending 8-bit to the monitor without processing a dithering step does not do anything.

That might be the only game that supports 10-bit output, I have never heard of a game that used >8-bit before.

That said I would never leave dithering disabled for normal use, you never know when there might be some processing that needs dithering after it.

panetesan2k6

4th October 2015, 11:36

the monitor doesn't have an option to choice 10 bit so it never gets 10 bit.

everything is working as it should.

Then, Nvidia was dithering when I got smooth gradients. No?

chros

4th October 2015, 11:47

i just tried my HD4400 with my TV.
madVR said the output is 10 bit but the FSE change is instant and the picture looks like undithered 8 bit.
so i guess the intel isn't outputting 10 bit at all.

it depends on gpu and display device.
for example,a playstation3(2006)can output 12bit full range through HDMI 1.3
and for my tv(a sony HX750),AMD card ouput bit depends on catalyst CC setting.NV card(a very old GT240) output 12bit in both 10bit/16bit D3D11 scan-out format.and Intel(HD4000) output 8bit in 10bit scan-out,and 12bit for 16bit scan-out format.
there is also a R10G10B10_XR_BIAS scan-out format mapping to xvYcc gamut.all 3 GPU above support that format but I can't comfirm if the HDMI signal is xvYcc.
So, has somebody managed to get 10bit output from an intel iGPU? (I have HD4000 with nvidia in muxless optimus mode, that means all the color properties are only in the intel control panel). Would xvColor setting help about this in intel control panel for my TV via HDMI? (my TV have the setting)
Thanks

omarank

5th October 2015, 06:01

The issue seems to be that any value which is equal to one in the output bit-depth has "no error" and thus will not have any dither applied to it when using error diffusion.
These areas without dither are distinct when they are next to areas which do have dither.
So it results in visible "bands" in the image, even though they are not errors due to imprecision.
Only random dither seems to eliminate this.

This comparison hopefully demonstrates the issue. I know that it can be difficult to see.

That’s a good demonstration. Does “change dither for every frame” option alleviate this issue of undithered bands?

6233638

7th October 2015, 18:30

That’s a good demonstration. Does “change dither for every frame” option alleviate this issue of undithered bands?No - that will change the pattern in any area which is dithered, but any area where there is "no error" would be unaffected by it.

XMonarchY

8th October 2015, 15:00

Maybe disabling AMD's dithering turns off dithering after a color calibration is applied?

When taking the 8-bit video rendered by a game and sending 8-bit to the monitor without processing a dithering step does not do anything.

That might be the only game that supports 10-bit output, I have never heard of a game that used >8-bit before.

That said I would never leave dithering disabled for normal use, you never know when there might be some processing that needs dithering after it.

There were a few other games that supported 10-bit color, but they were indeed very rare.

However, wouldn't 10bit to 8bit dithering or true 10bit still benefit gradients/banding in games?

huhn

8th October 2015, 16:48

Then, Nvidia was dithering when I got smooth gradients. No?

on the monitor yes.

XMonarchY

8th October 2015, 18:36

nevcairiel

8th October 2015, 23:20

Which dithering takes precedent though? Does 10bit-to-8bit NVidia dithering occur AFTER madVR utilizes its ED dithering or BEFORE? If 10bit-to-8bit NVidia dithering occur AFTER madVR dithering, then it is possible the result is worse since ED dithering is more than likely superior to 10bit-to-8bit NVidia dithering.

The driver is always last. Always. It controls the output afterall.
But that doesn't really matter though, unless you use bad options.

If the driver outputs 8-bit, you should set madVR to 8-bit. That way you get madVRs proper dithering, the driver only gets an 8-bit image and never has to dither --> Only madVR dithering is active.

If the driver outputs more than 8-bit, you get a choice. If you know that your TV does 10-bit, you can set madVR to 10-bit, and enjoy 2 bits more of precision. If you know your TV only has a 8-bit panel, it gets a bit more tricky, since the TV could still benefit from increased input bitdepth for processing (color management and whatnot), its probably best to test and look at the image - or just stay on the safe side and use 8-bit - but whichever option you choose, only madVR dithers, not the driver!

The only time you would get both dithering, madVR and the driver, is when the driver is set to 8-bit, and madVR to 10. madVR dithers to 10-bit, the driver to 8. You really don't want that option.

Then I am not sure anyone answered this question: If it is possible for madVR to request 10bit-to-8bit dithering from NVidia driver by selecting 10bit in madVR options, then shouldn't it be possible to request such dithering on desktop and / or games with some kind of a tweak / registry hack / software ???

The only way to do that is to do 10-bit D3D rendering like madVR in exclusive mode. Some games apparently support it, but its nothing you can "trick" anything into. If it doesn't render in 10-bit, there is nothing to dither.
However with games its rather questionable if it really adds anything of value, unless the game was designed from the ground up with 10-bit graphics in mind - which would probably make it quite a bit slower.

6233638

8th October 2015, 23:34

Which dithering takes precedent though? Does 10bit-to-8bit NVidia dithering occur AFTER madVR utilizes its ED dithering or BEFORE? If 10bit-to-8bit NVidia dithering occur AFTER madVR dithering, then it is possible the result is worse since ED dithering is more than likely superior to 10bit-to-8bit NVidia dithering.Anything that happens in madVR would happen before the driver's conversion from 10-bit to 8-bit.
I'd say that it would be preferable to have madVR dither to 8-bit, than have it output 10-bit and let the driver dither to 8-bit.

Then I am not sure anyone answered this question: If it is possible for madVR to request 10bit-to-8bit dithering from NVidia driver by selecting 10bit in madVR options, then shouldn't it be possible to request such dithering on desktop and / or games with some kind of a tweak / registry hack / software ??? The applications and the desktop compositor would have to support a 10-bit output.

Edit: beaten to it by Nevcariel.

However with games its rather questionable if it really adds anything of value, unless the game was designed from the ground up with 10-bit graphics in mind - which would probably make it quite a bit slower.Games are probably the source where banding is most common in my experience, and would be greatly improved by outputting 10-bit.
Most of them are already using >8-bit precision internally anyway for things like HDR.
I guess that the bigger issue is that they are not doing proper conversion from that to 8-bit, but improper conversion to 10-bit is a big improvement over improper conversion to 8-bit.

XMonarchY

9th October 2015, 00:43

The driver is always last. Always. It controls the output afterall.
But that doesn't really matter though, unless you use bad options.

If the driver outputs 8-bit, you should set madVR to 8-bit. That way you get madVRs proper dithering, the driver only gets an 8-bit image and never has to dither --> Only madVR dithering is active.

If the driver outputs more than 8-bit, you get a choice. If you know that your TV does 10-bit, you can set madVR to 10-bit, and enjoy 2 bits more of precision. If you know your TV only has a 8-bit panel, it gets a bit more tricky, since the TV could still benefit from increased input bitdepth for processing (color management and whatnot), its probably best to test and look at the image - or just stay on the safe side and use 8-bit - but whichever option you choose, only madVR dithers, not the driver!

The only time you would get both dithering, madVR and the driver, is when the driver is set to 8-bit, and madVR to 10. madVR dithers to 10-bit, the driver to 8. You really don't want that option.

The only way to do that is to do 10-bit D3D rendering like madVR in exclusive mode. Some games apparently support it, but its nothing you can "trick" anything into. If it doesn't render in 10-bit, there is nothing to dither.
However with games its rather questionable if it really adds anything of value, unless the game was designed from the ground up with 10-bit graphics in mind - which would probably make it quite a bit slower.

So that is exactly what happens when madVR dithering (Error Diffusion) is turned on, madVR is set to 10bit, and NVidia CP is set to 8bit, doesn't it? In that case madVR dithers to 10bit and NVidia driver dithers to 8bit. If you set NVidia CP to 8bit, then madVR will just dither to 8bit. Are you sure that is better? Do we know for sure driver-level 10bit-to-8bit dithering is of lower quality than madVR dithering?

Here's how I tested and it is quite easy:
- set NVidia CP to 8bit
- set madVR to 10bit
- enable madVR ED dithering (I use Type 2 and have bottom 2 boxes ticked)
- open grayscale gradient .mp4 file

Then all you have to do to compare madVR-ONLY dithering to madVR + NVidia 10bit-to-8bit dithering is compare the gradient in FSE mode and in non-FSE (fullscreen mode). Only FSE uses D3D11 and 10bit, which is when NVidia 10bit-to-8bit dithering occurs. In non-FSE mode, madVR uses 8bit and NVidia 10bit-to-8bit dithering does not happen.

I find that setting madVR to 10bit and NVidia CP to 8bit (which is the only option on this display), enabling ED dithering, and running in FSE mode provides SMOOTHER gradient than the one I see when madVR set to 8bit and NVidia 10bit-to-8bit dithering does not occur. In fact, I did not like that after applying my 3DLUT (used over 4000 patches...), madVR's ED dithering in 8bit mode still left some visible banding...

Is there a better way to compare?

Another thing that NOBODY believes me is that outside of madVR environment, on desktop, while moving my head very close to the screen and looking at a grayscale ramp like this one - http://www.lagom.nl/lcd-test/gradient.php - I see pixels move. I am either NUTS or pixels move while looking at a still image, like that exact ramp on Lagom.nl. What is this pixel movement? Is it SOME KIND of dithering??? NVdia CP is set to 8bit and 8bit is the only setting available. Again, this is NOT madVR related - it occurs outside any playback software / application. This movement also affects grayscale ramp banding (viewed in Windows Photo Viewer) caused by 1DLUT / ICC applied to desktop. What on Earth is that movement of pixels??? When I measure pixel depth with ArgyllCMS on desktop (not madVR), it reports 10bit, but that IMPOSSIBLE because this monitor only comes with 8bit input/output!

Asmodian

9th October 2015, 03:03

I find that setting madVR to 10bit and NVidia CP to 8bit (which is the only option on this display), enabling ED dithering, and running in FSE mode provides SMOOTHER gradient than the one I see when madVR set to 8bit and NVidia 10bit-to-8bit dithering does not occur. In fact, I did not like that after applying my 3DLUT (used over 4000 patches...), madVR's ED dithering in 8bit mode still left some visible banding...

Dithering twice, as is the case when you have madVR set to 10-bit and Nvidia set to 8-bit, results in higher noise than a single dithering step. Because noise masks banding your observations make perfect sense.

P.S. using too many patches can cause banding, try 1500, also try medium quality (instead of high) in Argyll. More isn't always better. It took me a long time and a lot of calibrations to believe this. :o

Another thing that NOBODY believes me is that outside of madVR environment, on desktop, while moving my head very close to the screen and looking at a grayscale ramp like this one - http://www.lagom.nl/lcd-test/gradient.php - I see pixels move. I am either NUTS or pixels move while looking at a still image, like that exact ramp on Lagom.nl. What is this pixel movement? Is it SOME KIND of dithering??? NVdia CP is set to 8bit and 8bit is the only setting available. Again, this is NOT madVR related - it occurs outside any playback software / application. This movement also affects grayscale ramp banding (viewed in Windows Photo Viewer) caused by 1DLUT / ICC applied to desktop. What on Earth is that movement of pixels??? When I measure pixel depth with ArgyllCMS on desktop (not madVR), it reports 10bit, but that IMPOSSIBLE because this monitor only comes with 8bit input/output!

That sounds like FRC dithering or similar, dithering internal to the display. It is actually a 6-bit panel? How do gradients look with madVR set to 6-bit?

Argyll's bit-depth report is for the GPU's 1D LUTs, not the display. Do not use a profile attached to your 3DLUT (use -a in collink) to avoid the GPU's 1D LUTs. The GPU will have to dither after applying the profile/windows calibration and it uses a lower bit-depth for processing compared to madVR. Do not use a profile when testing dithering options. Using Overlay will also bypass the LUTs for an easy way to compare pure madVR v.s. madVR's output after it went though the GPU's LUTs.

XMonarchY

9th October 2015, 03:32

Dithering twice, as is the case when you have madVR set to 10-bit and Nvidia set to 8-bit, results in higher noise than a single dithering step. Because noise masks banding your observations make perfect sense.

P.S. using too many patches can cause banding, try 1500, also try medium quality (instead of high) in Argyll. More isn't always better. It took me a long time and a lot of calibrations to believe this. :o

That sounds like FRC dithering or similar, dithering internal to the display. It is actually a 6-bit panel? How do gradients look with madVR set to 6-bit?

Argyll's bit-depth report is for the GPU's 1D LUTs, not the display. Do not use a profile attached to your 3DLUT (use -a in collink) to avoid the GPU's 1D LUTs. The GPU will have to dither after applying the profile/windows calibration and it uses a lower bit-depth for processing compared to madVR. Do not use a profile when testing dithering options. Using Overlay will also bypass the LUTs for an easy way to compare pure madVR v.s. madVR's output after it went though the GPU's LUTs.

No this is technically a 10bit MVA panel because officially, Eizo states that this monitor supports 1.07billion colors over DisplayPort. It is definitely not 6bit... What am I suppose to notice if I set madVR to 6bit?

I am aware of not using ICC profiles / 1DLUT's when 3DLUT's are applied - that is basic knowledge.

I didn't know that ArgyllCMS measured LUT bit-depth of GPU's. In fact, I am pretty sure than all GPU's at the moment can store only 255 grayscale steps, regardless of display's bit depth... I do know that on my HDTV (NOT the MVA monitor), I can set NVidia CP to 8bit depth and ArgyllCMS will report "8bit depth", but if I set NVidia CP to 12bit depth, then ArgyllCMS reports "Unknown bit-depth". Apparently, ArgyllCMS does measure display bit-depth.

Read this - http://display-corner.epfl.ch/index.php/EIZO_FORIS_FG2421#Color_resolution . This shows that this panel is an 8bit panel + FRC, so its 10bit, and yet everyone here keeps saying that it isn't possible because input is only 8bit.

This is officially from Eizo specs list:
Grayscale Tones - 256 tones (a palette of 1021 tones)
Display Colors - 16.77 million from a palette of 1.06 billion

Asmodian

9th October 2015, 03:52

8bit panel + FRC

Why are you surprised pixels move? That is what FRC means.

Your monitor has internal processing in >8-bit.

It gets 8-bit in from the GPU, does stuff to it, and then displays this higher internal precision at 8-bit + FRC dithering.

Your calibration/3DLUT has banding, more noise from double dithering masks this.

This explains all your observations.

panetesan2k6

9th October 2015, 06:55

on the monitor yes.

Ok, I got confused a little from the beginning, sorry.

I thought MadVR was able to change the bitdepth output when doing FSE. I read Asmodian here on the MadVR thread (http://forum.doom9.org/showpost.php?p=1742115&postcount=33434) noting that MadVR can't do that and you need to set the bitdepth on the driver.

So, as you said, I got 10-bit on the TV with both cards. Other matter would be knowing wether the TV is just accepting 10-bit input but processing it down to 8-bit.

huhn

9th October 2015, 07:31

panetesan2k6

9th October 2015, 09:18

it's pretty pointless with bt 709 and lossy 8 bit sources anyway so don't put to much time into it. internal processing in over 8 bit is the important part.

bt 2020 and HDR will change this and current 1080p TVs can't do this anyway.

Oh, sure. But you know that tinkering with our gadgets is always fun, jejeje :D

Thank you for your help ;)

XMonarchY

9th October 2015, 20:15

Why are you surprised pixels move? That is what FRC means.

Your monitor has internal processing in >8-bit.

It gets 8-bit in from the GPU, does stuff to it, and then displays this higher internal precision at 8-bit + FRC dithering.

Your calibration/3DLUT has banding, more noise from double dithering masks this.

This explains all your observations.

Nope, I was told numerous times that 8bit + FRC cannot occur if the input/output selection is only 8bit in NVidia CP. 8bit + FRC (10bit) is only possible if 10bit output/input can be selected in NVidia CP. I had like 3 or 4 people tell me that.

nevcairiel

9th October 2015, 20:24

Nope, I was told numerous times that 8bit + FRC cannot occur if the input/output selection is only 8bit in NVidia CP. 8bit + FRC (10bit) is only possible if 10bit output/input can be selected in NVidia CP. I had like 3 or 4 people tell me that.

Thats utterly wrong. The screen will perform the FRC no matter what. It still has its internal color processing and whatnot that can and will produce a higher bitdepth.

Asmodian

10th October 2015, 00:14

Nope, I was told numerous times that 8bit + FRC cannot occur if the input/output selection is only 8bit in NVidia CP. 8bit + FRC (10bit) is only possible if 10bit output/input can be selected in NVidia CP. I had like 3 or 4 people tell me that.

No, people told you that you cannot get 10-bit data from madVR to your display using 8-bit output from the GPU. The extra precision compared to madVR outputting dithered 8-bit is lost when the GPU converts madVR's 10-bit output to 8-bit.

That is not the same as your monitor creating >8-bit data internally and then displaying that as pseudo 10-bit using FRC dithering.

XMonarchY

10th October 2015, 19:12

Wow, this just reached a new level of confusion for me.

SO, by itself, without madVR, my monitor uses 8bit input/output + FRC dithering, correct? Then, if I select 10bit in madVR while NVidia CP shows 8bit color depth, then NVidia driver dithers from 10bit to 8bit on top of already-working FRC dithering?

Off-topic: What is the best way to calibrate a monitor with FRC dithering (for desktop use, not madVR 3DLUT)? I think it gets in the way of proper calibration and AFAIK there is no way to disable it...

Asmodian

11th October 2015, 00:11

I am not sure what you mean by "on top of already-working FRC dithering".

Your monitor doesn't use 8-bit input/output + FRC dithering, that doesn't make sense. You cannot attach the FRC dithering to the input/output bit-depth like that.

The FRC dithering of the display has nothing to do with the precision of the input data; the monitor's internal processing simply doesn't do as much damage to the precision of the pure 8-bit data it receives because it can display the modified image as 8-bit with FRC dithering. This is a good thing but the precision of the image displayed, relative to the source, is never higher than the pure 8-bit input data.

Off-topic:
You can only calibrate normally, there is nothing you can do about FRC, but try using fewer patches and/or medium quality. I have found that this really does reduce or eliminate banding which I couldn't solve any other way. This is trading absolute accuracy at each point for a smoother calibration. Usually, for me, the accuracy change is undetectable while the elimination of banding is obvious (viewing test patterns).

It is embarrassing to think about those many nights spent trying to eliminate banding when calibrating my old monitor using high quality and a 2500+ patch set when all I needed to do to eliminate it was use a 1000 patch set and medium quality (it wasn't a great monitor). :o

It is hard to believe lowering "quality" options can result in a better calibration but it looked much better, 0.3 dE better error on some colors is not worth any amount of visible banding.

Also make sure to use the newest version of Argyllcms, recent updates have greatly reduced banding at any patch count or quality level.

XMonarchY

11th October 2015, 19:02

OK, so that means FRC actually makes the image worse in this case. With 6bit + FRC monitor with 8bit input, FRC improves image by compensating for the missing 2bit. However, in this case, where the panel is 8bit + FRC and has 8bit input, the image only gets worse with FRC because the panel can already display 8bit signal without it. I mean what can FRC do on a true 8bit (+ FRC) panel with 8bit input?

Asmodian

11th October 2015, 19:44

XMonarchY

11th October 2015, 20:43

Usually monitors process the 8-bit input data somehow, e.g. RGB controls in the display. This creates >8-bit data the same way madVR's processing does. Displaying this modified image with FRC dithering is theoretically more precise than without FRC dithering. FRC is similar to madVR's dithering except it uses temporal noise (movement) instead of spacial noise.

I find claims of 8-bit+FRC dithering being equivalent to 10-bit to not be true (or 6-bit+FRC being equivalent to 8-bit). I prefer good spacial dithering to FRC dithering. Spacial resolution is better with FRC though and you can avoid double dithering, instead you get FRC dithering on top of madVR's dithering which doesn't multiply the noise added in the same way (one dither worth of spacial noise plus one dither worth of temporal noise).

I completely agree. My HDTV with 12bit input (10bit + internal processing, I think) provides better grayscale ramp gradient smoothness because there is no crawling. With 8bit + FRC, gradients are very smooth when the ramp is short and small, but once you zoom in, you can see individual levels with crawling, which does not happen with true 10bit, where the gradient stays smooth even when fully zoomed in.

However, if my TV uses 8bit input and madVR is set to 10bit (without any dithering), NVidia driver does not dither 10bit to 8bit and all 255 grayscale levels are very visible. I think I said that a few times before - it doesn't bother me, just makes me curious why NVidia dithers from 10it to 8bit on one display, but not the other... I tried to use different ports on my monitor, but the result is the same - NVidia dithers from 10bit to 8bit on monitor, but not TV. THIS what makes me think that there is a connection between this monitor's FRC dithering and NVidia driver applying 10bit to 8bit dithering. I realize, the input is only 8bit on this monitor, but MAYBE NVidia driver detects FRC somehow and dithers because FRC is available..?

Just to make it clear one more time about this monitor with 8bit + FRC dithering. When NVidia CP is set to 8bit and madVR set to 10bit, NVidia driver dithers from 10bit down to 8bit, doesn't it? IF FRC is a totally different dithering, not related to NVidia driver dithering, then does FRC dithering get applied AFTER 10bit to 8bit driver dithering or BEFORE 10bit to 8bit driver dithering?

6233638

11th October 2015, 22:21

Just to make it clear one more time about this monitor with 8bit + FRC dithering. When NVidia CP is set to 8bit and madVR set to 10bit, NVidia driver dithers from 10bit down to 8bit, doesn't it? IF FRC is a totally different dithering, not related to NVidia driver dithering, then does FRC dithering get applied AFTER 10bit to 8bit driver dithering or BEFORE 10bit to 8bit driver dithering?

Software
Drivers
Display

Asmodian

12th October 2015, 06:04

I completely agree. My HDTV with 12bit input (10bit + internal processing, I think) provides better grayscale ramp gradient smoothness because there is no crawling. With 8bit + FRC, gradients are very smooth when the ramp is short and small, but once you zoom in, you can see individual levels with crawling, which does not happen with true 10bit, where the gradient stays smooth even when fully zoomed in.

You miss-understand, a transfer format cannot have dithering. You cannot transmit 10-bit data + dithering information, that would simply be transmitting 12-bit. 12-bit input means 12-bit input.

However, if my TV uses 8bit input and madVR is set to 10bit (without any dithering), NVidia driver does not dither 10bit to 8bit and all 255 grayscale levels are very visible. I think I said that a few times before - it doesn't bother me, just makes me curious why NVidia dithers from 10it to 8bit on one display, but not the other... I tried to use different ports on my monitor, but the result is the same - NVidia dithers from 10bit to 8bit on monitor, but not TV. THIS what makes me think that there is a connection between this monitor's FRC dithering and NVidia driver applying 10bit to 8bit dithering. I realize, the input is only 8bit on this monitor, but MAYBE NVidia driver detects FRC somehow and dithers because FRC is available..?

Maybe it is because Nvidia detects your TV could accept more and never dithers below the max bit depth accepted? They assume if you wanted the best output possible (dithered) you would use the highest bit-depth possible?

But FRC is NOT available to the GPU. 8-bit input is 8-bit input, it is three sets of eight ones and zeros for every pixel. 24 ones and zeros. That is it; to access the FRC from the GPU requires sending 10-bit input.

Just to make it clear one more time about this monitor with 8bit + FRC dithering. When NVidia CP is set to 8bit and madVR set to 10bit, NVidia driver dithers from 10bit down to 8bit, doesn't it? IF FRC is a totally different dithering, not related to NVidia driver dithering, then does FRC dithering get applied AFTER 10bit to 8bit driver dithering or BEFORE 10bit to 8bit driver dithering?

FRC is applied after the GPU, it is the absolutely last processing step that happens immediately before you view the pixels.

Think of it like an assembly line. You cannot get any information from a previous step other than the information output by that step.

[LAV video decodes 10-bit H.264] -> [Outputs RAW YCbCr 4:2:0 10-bit] -> [madVR converts to 16-bit RGB, upscaling, calibration, etc.] -> [madVR dithers to 10-bit RGB] -> [GPU dithers/rounds to 8-bit RGB and sends it out the port] -> [Display converts 8-bit input to 14-bit RGB, video processing] -> [sends 10-bit RGB to the LCD panel] -> [8-bit panel displays 10-bit RGB using FRC dithering]

Dithering is simply a way of changing the value, within the output bit depth, of nearby (spacial dithering) or future (FRC dithering) pixels to better represent higher bit-depth information. There isn't actually any more information transmitted when using dithering, it just looks more like the higher bit-depth than it would have.

Think of a 10-bit gradient dithered to 8-bit. As we move below 50% the pixel values go from 512/1023 to 510/1023. When outputting 8-bit 510 becomes 127.5 but 8-bit is an integer format. We could simply round to 128 but then we get a hard line between 128 and 127 when we used to be able to have pixels with values of 127.75, 127.5, and 127.25 (511, 510, 509). So instead of two pixels set to 127.5 we set one to 128 and the other to 127. When looked at by a human every other pixel 127 or 128 looks almost exactly like all pixels at 127.5, but a bit noisier. For four pixels with values of 127.75 one is 127 with the other three being 128.

ED dithering uses a complex method to distribute the error but the result is effectively the same.

ashlar42

12th October 2015, 15:12

it's pretty pointless with bt 709 and lossy 8 bit sources anyway so don't put to much time into it. internal processing in over 8 bit is the important part.

bt 2020 and HDR will change this and current 1080p TVs can't do this anyway.This is interesting to me. Considering Exclusive Mode sometimes is a source of minor problems for me (focus and such), do you personally feel like 10 bit with current sources is not worth the hassle? Windowed overlay also seems to be quicker in switching res/refresh.

huhn

12th October 2015, 15:33

the error created by compression is already pretty big.

the difference between 10 bit and 8 bit output should be really small with BD sources.

madVR dithering is fine as it is.

if you don't see a clear benefit from it without test pictures like in this thread ignore it.

Arm3nian

13th October 2015, 05:20

Got my new display today and I can select 10bit.
http://i.imgur.com/nvtFBWM.png
I think the spyder 4 is a piece of garbage though so my calibrations are off. Pissing me off currently but 3d lut and 10bit looks really good.

huhn

13th October 2015, 06:14

it's an 8 bit FRC display with 10 bit processing.

Arm3nian

13th October 2015, 06:45

it's an 8 bit FRC display with 10 bit processing.

I know, but so is every other monitor in this category.
Supposedly it has an internal 14-bit 3D LUT. Cool in theory but idk what it actually does in reality.

huhn

13th October 2015, 07:07

Arm3nian

13th October 2015, 07:15

that's for calibration. to be more precise for calibration at the monitor.

it depends on a lot of things how useful it is and what you want to do. and if it is implement good or not.

for example for photo shop usage it is theoretically totally amazing.

I just can't seem to get a good calibration with the spyder 4. The results look bad. Tried many monitors and the native software and dispcal. But you need to calibrate to create a 3d lut. And madVR with a 3d lut looks totally different.

Without a 3d lut, people in the hobbit look yellow. With a 3d lut, you see rays of sunlight bouncing off their hair...

I think it also helps to bring out 10bit. Uncalibrated 10bit seems useless.

XMonarchY

13th October 2015, 16:22

I just can't seem to get a good calibration with the spyder 4. The results look bad. Tried many monitors and the native software and dispcal. But you need to calibrate to create a 3d lut. And madVR with a 3d lut looks totally different.

Without a 3d lut, people in the hobbit look yellow. With a 3d lut, you see rays of sunlight bouncing off their hair...

I think it also helps to bring out 10bit. Uncalibrated 10bit seems useless.

10bit isn't going to make your colors any more accurate than they would be with 8bit setting. It mostly helps with gradient banding.

Spyder 4 is garbage indeed. which is why on AVS Forums, i1Display Pro (or at the VERY least ColorMunki Display) is considered to be the minimum requirement for a semi-accurate calibration. IMHO, anyone who wants an acceptably calibrated display should use a spectrometer (such as i1Pro / ColorMunki Photo) + colorimeter (such asi1Display Pro / ColorMunki Display).

At the moment the cheapest combination would be to BUY ColorMunki Display colrorimeter on Amazon or eBay (for $175 + shipping) and profile it with ColorMunki Photo, which you can RENT @ https://www.lensrentals.com/rent/calibration/colormunki for $60 (3 day rent). Total is $175 (CMD) + $60 (CMP) + Shipping = ~ $250, which is a great investment. If you plan on buying any displays, then I would wait until ALL displays have arrived, and use that ColorMunki Photo to profile ColorMunki Display on ALL displays you have during that 3-day rent.

XMonarchY

13th October 2015, 16:48

You miss-understand, a transfer format cannot have dithering. You cannot transmit 10-bit data + dithering information, that would simply be transmitting 12-bit. 12-bit input means 12-bit input.

Maybe it is because Nvidia detects your TV could accept more and never dithers below the max bit depth accepted? They assume if you wanted the best output possible (dithered) you would use the highest bit-depth possible?

But FRC is NOT available to the GPU. 8-bit input is 8-bit input, it is three sets of eight ones and zeros for every pixel. 24 ones and zeros. That is it; to access the FRC from the GPU requires sending 10-bit input.

FRC is applied after the GPU, it is the absolutely last processing step that happens immediately before you view the pixels.

Think of it like an assembly line. You cannot get any information from a previous step other than the information output by that step.

[LAV video decodes 10-bit H.264] -> [Outputs RAW YCbCr 4:2:0 10-bit] -> [madVR converts to 16-bit RGB, upscaling, calibration, etc.] -> [madVR dithers to 10-bit RGB] -> [GPU dithers/rounds to 8-bit RGB and sends it out the port] -> [Display converts 8-bit input to 14-bit RGB, video processing] -> [sends 10-bit RGB to the LCD panel] -> [8-bit panel displays 10-bit RGB using FRC dithering]

Dithering is simply a way of changing the value, within the output bit depth, of nearby (spacial dithering) or future (FRC dithering) pixels to better represent higher bit-depth information. There isn't actually any more information transmitted when using dithering, it just looks more like the higher bit-depth than it would have.

Think of a 10-bit gradient dithered to 8-bit. As we move below 50% the pixel values go from 512/1023 to 510/1023. When outputting 8-bit 510 becomes 127.5 but 8-bit is an integer format. We could simply round to 128 but then we get a hard line between 128 and 127 when we used to be able to have pixels with values of 127.75, 127.5, and 127.25 (511, 510, 509). So instead of two pixels set to 127.5 we set one to 128 and the other to 127. When looked at by a human every other pixel 127 or 128 looks almost exactly like all pixels at 127.5, but a bit noisier. For four pixels with values of 127.75 one is 127 with the other three being 128.

ED dithering uses a complex method to distribute the error but the result is effectively the same.

THAAAANK YOU! I love you - you explained a lot to me!

FRC can be controlled either by GPU (10bit+ input required) OR by the display itself.

Do GPU's generally do better jobs at controlling FRC dithering than displays?

IMO:
True 10bit (12bit+ input / processing) > madVR's ED dithering (8bit input and 8bit madVR setting) > NVidia 10bit-to-8bit dithering > my monitor's FRC dithering . Obviously 10bit+ input (8bit+FRC or true 10bit) + madVR ED is the best there is.

I was just playing Witcher 3 on my 8bit input monitor + display's own FRC and took screenshots where some banding is present. I even enabled ReShade / SweetFX Ordered dithering, but banding was still quite obvious. Then I viewed the same screenshot in MPC-HC through madVR and even with 8bit setting (without NVidia's 10bit-to-8bit dithering) , banding was greatly improved. My monitor's FRC dithering is TOO SLOW, greatly reducing banding in one part of the screen, while letting it be in another parts of the screen. madVR ED dithering is 100000x+ times faster than my monitor's FRC dithering. If only ED could be integrated into ReShade / SweetFX as a shader... (it would probably be a huge performance hog).

I may be totally wrong, but several sites use the term "cross-hatching" to describe a faint cross-hatching pattern on some monitors, one of which is mine. This "cross-hatching" is mostly visible on light/white backgrounds when one's eyes are very close to the screen. I think this "cross-hatching" is actually dithering with a cross-hatching pattern! Unlike madVR's ED (Type I) dithering that does not leave any patterns, monitor's FRC dithering does leave patterns. This cross-hatching pattern stays the same, BUT the actual pixels move around.

huhn

13th October 2015, 17:18

THAAAANK YOU! I love you - you explained a lot to me!

FRC can be controlled either by GPU (10bit+ input required) OR by the display itself.

Do GPU's generally do better jobs at controlling FRC dithering than displays?

you should really read what he has written the GPU can't control FRC and doesn't care if it is there or not.

aufkrawall

13th October 2015, 17:22

Different topic: DXVA scaling is always 8 bit, no matter what GPU or driver?

huhn

13th October 2015, 17:23

as far as we know yes it is 8 bit.

aufkrawall

13th October 2015, 17:31

Thanks, so it's totally useless crap. Then I'd even rather go with bilinear scaling instead of DXVA lanczos on Intel.

XMonarchY

13th October 2015, 18:21

you should really read what he has written the GPU can't control FRC and doesn't care if it is there or not.

I thought FRC is not available to the GPU if the input is only 8bit, but if input is 10bit, then wouldn't FRC be available to the GPU?

What is the difference between 8bit+FRC display with 8bit input and 8bit+FRC display with 10bit input?

aufkrawall

13th October 2015, 18:33

You mix up what GPU and display do.
I think it would be helpful to call GPU dithering dithering and display dithering FRC, to avoid confusion.

huhn

13th October 2015, 18:35

Arm3nian

13th October 2015, 20:47

10bit isn't going to make your colors any more accurate than they would be with 8bit setting. It mostly helps with gradient banding.

Not really true. You want to keep as much information from the output of your gpu as possible. Plus you want 10bit output if the content you're viewing is native 10bit.

Spyder 4 is garbage indeed.
It's the small things that also make me question it. TFT reported that my monitor with stock settings has a CR of 1080:1, and the manufacturer states 1000:1. Yet my spyder 4 reports 624:1 and adjusting the slider on the monitor makes no difference in the reported value. Wth?

I haven't given up hope yet. Going to try a bit more. If it fails to give me a proper calibration then I'll just stick with the factory one, which is actually decent.

XMonarchY

14th October 2015, 00:19

Not really true. You want to keep as much information from the output of your gpu as possible. Plus you want 10bit output if the content you're viewing is native 10bit.

It's the small things that also make me question it. TFT reported that my monitor with stock settings has a CR of 1080:1, and the manufacturer states 1000:1. Yet my spyder 4 reports 624:1 and adjusting the slider on the monitor makes no difference in the reported value. Wth?

I haven't given up hope yet. Going to try a bit more. If it fails to give me a proper calibration then I'll just stick with the factory one, which is actually decent.

I meant in terms of grayscale and colorspace accuracy. Having 10bit display won't help you achieve lower dE for any of the 255 grayscale steps or colorspace measurements.

Regarding Spyder 4 - it makes perfect sense because Spyder series are known to not be able to accurate read low-light levels. Things may have changed with Spyder 5, but nobody knows for sure how accurate Spyder 5 is. Go with either ColorMunki Display or i1Display Pro. The rest is not worth it if you want an accurate calibration.

I also STRONGLY urge you to get a spectrometer like i1Pro to profile your i1Display Pro or ColorMunki Display and get that true accuracy, not one based off colorimeter tables. i1Pro is expensive - $400 used from eBay and I would stay away from used... You can, however, do a 3-day rent of ColorMunki Photo spectrometer, which is quite accurate (almost as accurate as i1Pro), for some $40 + $20 shipping! ColorMunki Display can be purchased for $175, which makes ColorMunki Display and ColorMunki Photo 2-3 day rent total $250 - a truly great deal for great accuracy.

XMonarchY

14th October 2015, 00:22

a display with 8 bit + FRC and 10 bit input can make use of 10 bit picture while a 8 bit + FRC with only 8 bit input can't.

FRC is never available to the GPU no matter what.

a display with 10 bit input support could be true 10 bit, 8 bit, 8 bit + FRC, or even lower bit deep. the GPU doesn't care and doesn't know.

Oooh! So its all about the source then... Now I think I got it. 8bit + FRC with 8bit input is not capable of using that FRC to dither 10bit to 8bit, but videocard drivers can.

I hope NVidia's input selection is correct. They used to offer only 8bit on all displays, even those with 12bit input...

Asmodian

14th October 2015, 04:14

Oooh! So its all about the source then... Now I think I got it. 8bit + FRC with 8bit input is not capable of using that FRC to dither 10bit to 8bit, but videocard drivers can.

That is correct. This is because there is no 10-bit to dither from after the GPU converted to 8-bit and sent it to the display. You cannot dither from 10-bit to 8-bit starting with 8-bit. ;)

I hope NVidia's input selection is correct. They used to offer only 8bit on all displays, even those with 12bit input...

Your observations about the way the GPU does not dither when outputting 8-bit to a device that would accept 12-bit makes me quite curious how Nvidia's >8-bit support works.

Dithering to 10-bit but outputting 8-bit (truncated? rounded?) when connected to a >8-bit capable device could be quite annoying. Do you remember what output bit-depth was default when connected to your TV?

huhn

14th October 2015, 05:03

It's the small things that also make me question it. TFT reported that my monitor with stock settings has a CR of 1080:1, and the manufacturer states 1000:1. Yet my spyder 4 reports 624:1 and adjusting the slider on the monitor makes no difference in the reported value. Wth?

I haven't given up hope yet. Going to try a bit more. If it fails to give me a proper calibration then I'll just stick with the factory one, which is actually decent.

the spider is fine and there is no way it can't read the "black" from a IPS panel.

before you calibrated check for white clipping and black clipping and manually check for the white point and correct it.

if the white point is totally wrong you can lose a lot of CR using a 3D LUT.

Asmodian

14th October 2015, 05:05

I also STRONGLY urge you to get a spectrometer like i1Pro to profile your i1Display Pro or ColorMunki Display and get that true accuracy, not one based off colorimeter tables. i1Pro is expensive - $400 used from eBay and I would stay away from used... You can, however, do a 3-day rent of ColorMunki Photo spectrometer, which is quite accurate (almost as accurate as i1Pro), for some $40 + $20 shipping! ColorMunki Display can be purchased for $175, which makes ColorMunki Display and ColorMunki Photo 2-3 day rent total $250 - a truly great deal for great accuracy.

A spectrometer gets especially important with displays with new or rare backlight technologies. Without a good spectral correction file for your colorimeter on your display tech the white point and colors will be off. Sometimes very off.

Sadly I have not found any spectral correction files for my i1 Display Pro newer than 2012 for LED backlights. I understand white LEDs are evolving quickly and various methods to produce white are used; three files for LED backlights isn't enough. Even if I could find correction files specifically for my display I would still want to buy a spectrometer because generic correction files are not as good as one made for a particular meter and display. The ColorMunki Display is also a colorimeter, very similar to the i1 Display Pro, not a spectometer. It is a nice one but you want a spectrometer to get a good calibration on a display both the meter and a spectrometer haven't been used on before.

This is one of the problems with the Spyder line; they don't want you to have to know what technology your monitor uses even though you would get better accuracy with a specific correction. At least that was true when I had a Spyder 3. :o

10-bit doesn't help this kind of accuracy at all. When the dither to 2-bit option was first added I was totally amazed by how well madVR can dither 16-bit to 2-bit after a 3DLUT, it measures pretty much perfect, white point and everything. Even 1-bit dithering looks like the calibrated white point using only 3x1DLUTs (emulated GPU LUTs when using Overlay) when far enough away. Of course a lot of spacial resolution is lost to noise when dithering down to 2-bit but color accuracy, when measured with a meter, is still great.

edit:
if the white point is totally wrong you can lose a lot of CR using a 3D LUT.

This is a good point. I usually recommend targeting the native white point unless you are doing professional color work or your display has a terrible white point but good contrast.

huhn

14th October 2015, 05:08

the spyder 4 supports corrections.

Arm3nian

14th October 2015, 06:42

the spider is fine and there is no way it can't read the "black" from a IPS panel.

before you calibrated check for white clipping and black clipping and manually check for the white point and correct it.

if the white point is totally wrong you can lose a lot of CR using a 3D LUT.

It's factory calibrated and comes with calibration results. White point seems just below 6500k on the paper that comes with it.

So how do you explain this:
http://i.imgur.com/pvos7U3.png
How can my contrast be 400+ units away from what TFT central got with the same settings. Bit off topic I know, no pun intended.

Asmodian

14th October 2015, 07:26

huhn

14th October 2015, 08:33

a dark room calibrated screen should have a brightness of 100-120 CM². people should look like plastic with such a high brightness.

baii

14th October 2015, 13:02

Regarding colorimeter, the spyder is known to read black level incorrectly, you can easily compare same monitor review using spyder vs i1d3/i1pro2.
For correction matrix, I recently bought a 27" 4k wled (auo ahva) and the stock i1d3 correction grey scale is about 200 klevin (about de of 2.x) off compare to i1pro profiled reading. This is higher compare to other wled I had before.

Sent from my 306SH

SweetLow

14th October 2015, 14:57

The only time you would get both dithering, madVR and the driver, is when the driver is set to 8-bit, and madVR to 10. madVR dithers to 10-bit, the driver to 8. You really don't want that option.

Very right but... Why we need first (16->10 bit) dithering in this situation? This is power consuming option (when executed in pixel shaders). So, we can disable dithering and still have 10 bit at driver input. And we really want this option if we don't want fаn noise :p
P.S. The best is have 16 bit at driver input in this situation, but madshi don't want this (now) ;)

huhn

14th October 2015, 19:16

we are talking about 0.71 we are not even close to black. there is no way a spyder can be this bad at "black" reading.

Arm3nian

14th October 2015, 19:56

450 cd/m^2 :eek:

That is very bright. This is why your contrast is so low, with the brightness that high your black level is very high. Try 160-220 cd/m^2. I use ~140 cd/m^2. :o

Or it could be backlight bleed? That can change the black level a lot.

a dark room calibrated screen should have a brightness of 100-120 CM². people should look like plastic with such a high brightness.

Black level goes up when you increase the brightness, but so does the white level, so the ratio stays constant. For my display, it's fairly uniform, according to my tests and this (http://www.tftcentral.co.uk/reviews/viewsonic_vp2780-4k.htm)

My display has some backlight bleed, as almost all IPS displays do, but it's on the edges and corners. The spyder is measuring in the center of the display, and I can't see any major bright spots in that location.

I tried different brightness/white level settings. Same results:

http://i.imgur.com/hlAAkZh.png

http://i.imgur.com/O6tTJH4.png

Regarding colorimeter, the spyder is known to read black level incorrectly, you can easily compare same monitor review using spyder vs i1d3/i1pro2.

The TFT review uses the i1 display pro and results are completely different:

http://i.imgur.com/BSdgIP0.png

Arm3nian

14th October 2015, 20:15

I noticed the TFT review luminance values are different than what I measured. They say 100 brightness level on their unit is about 411 cd/m2. But to get around 411 cd/m2 on mine I have to lower brightness to 87. I don't think the spyder is inaccurate in measuring white level because the calibration reports that came with the display also show the display reaching 450 cd/m2.

Here is the measurement to compare:

http://i.imgur.com/mnmb5us.png

Big difference in black point and CR. Maybe something internal is set too high and the black level can't keep up with the white level?

Asmodian

14th October 2015, 20:39

It is usual to have very different brightness between individual units. With four identical monitors I had to set each one to a different brightness to hit 120 cd/m^2 on all of them.

Do not use what TFTCentral set if you have your own meter, tweak the settings while measuring with the meter. It does sound like your black level is much too high, 0.65 is well above the ~0.3 cd/m^2 I would expect. Try moving the meter around on the screen a bit, I have seen displays with patches of very high black level. This would tell you what was wrong with the display but not help you solve it.

Arm3nian

14th October 2015, 20:59

My specific unit is 100 cd/m2 above what the manufacturer claims, seems a bit odd. I would have expected to LED backlight to be dead by now.

Do you think the spyder 4 is reporting accurate black levels? As huhn said, It would be unlikely that a popular unit like the spyder 4 couldn't report an accurate value on a fundamental measurement. I noticed in dispcal you can adjust black level. My first time through the calibration I had it on "as measured", so obviously the calibration didn't improve the contrast ratio. Would setting it to a specific value make any difference? The default target when you enable the control is 0.0001 cd/m2, which is insane. Maybe I should use the TFT review as a reference and try .12 cd/m2 black level at 120 cd/m2 white level.

XMonarchY

14th October 2015, 21:24

Arm3nian

14th October 2015, 21:35

A lot of seriously crappy things are popular - that doesn't make them good for what they should be doing. One way or another - ColorMunki Display is the absolute minimum for decent accuracy.

They're all the same gimmicky crap that hide in the shadow of professional equipment. There is no magic going on here, look at the electronics inside...

You might a get a little better accuracy in reference to something much better going from one brand to another and generation to generation, but all of them should be able to give you similar results. The main thing that changes is the bundled software and they are all awful, which is why everyone uses 3rd party applications.

Asmodian

14th October 2015, 21:39

Do you think the spyder 4 is reporting accurate black levels? As huhn said, It would be unlikely that a popular unit like the spyder 4 couldn't report an accurate value on a fundamental measurement. I noticed in dispcal you can adjust black level. My first time through the calibration I had it on "as measured", so obviously the calibration didn't improve the contrast ratio. Would setting it to a specific value make any difference?

I do not know about the Spyder 4 but 0.6 is very high, do your blacks look gray?

Contrast is simply [white level] / [black level], calibration can only make it worse.

Arm3nian

14th October 2015, 21:58

I do not know about the Spyder 4 but 0.6 is very high, do your blacks look gray?

Contrast is simply [white level] / [black level], calibration can only make it worse.

No the blacks look like the blacks on any other IPS monitor. Maybe even better than the P2715q I had before this. Perhaps something is wrong with the argy and spyder combo, as hcfr gives the same results.

I'm currently trying a calibration with adjusted black level, worth a shot I guess. I'm not going to buy another colorimeter and spectrometer as I already have one and the cal files for the spyder 4, it would be a waste of money, especially since the factory calibration doesn't even look that bad.

nevcairiel

14th October 2015, 21:59

Colorimeters are often very bad at accurately measuring low-light conditions, so an accurate black level may not be something it can do very well.

baii

15th October 2015, 00:15

Colorimeter is supposedly better at low light level :), and pretty much hold true for current products. I1pro1 vs i1d3. I1pro2 can read down there but it is "new gen."

The Spyder read black level wrong, period. Reviews using spyder constantly read 600ish :1 on 1000:1 monitors.

Sent from my SM-T700 using Tapatalk

Arm3nian

15th October 2015, 01:59

Colorimeter is supposedly better at low light level

That doesn't make much sense. Lower light levels mean the sensor needs to be more sensitive, and you run into big problems there (sensor quality, adc picking up noise, etc...), especially on low end equipment like consumer grade colorimeters. Black itself is difficult to measure, because it is the absence of light.

The Spyder read black level wrong, period. Reviews using spyder constantly read 600ish :1 on 1000:1 monitors.

Seems like it. I doubt my display actually has a CR of 640:1. I tried calibrating with the spyder software and the contrast decreased to 600:1 :angry:The blacks look pretty good with native settings.

The question is, how much of an impact would incorrect black level measurements have on the calibration as a whole.

baii

15th October 2015, 03:04

That doesn't make much sense. Lower light levels mean the sensor needs to be more sensitive, and you run into big problems there (sensor quality, adc picking up noise, etc...), especially on low end equipment like consumer grade colorimeters. Black itself is difficult to measure, because it is the absence of light.

That is compare to a spectro, It have something to do with SNR and temperature on a spectro, at least that is what I read. ofc there are higher end colorimeter and lower end, but low end doesn't mean bad, avs forum people (more like hcfr developer zoyd) have done extensive test on these so you can find info there.

Arm3nian

15th October 2015, 04:12

That is compare to a spectro, It have something to do with SNR and temperature on a spectro, at least that is what I read. ofc there are higher end colorimeter and lower end, but low end doesn't mean bad, avs forum people (more like hcfr developer zoyd) have done extensive test on these so you can find info there.

If there isn't any light, then there is nothing to measure. So you can imagine the more light there is, the more accurate your result will be. Kind of like how a camera works. You can have a great general use camera but it will perform better in good lighting vs dark scenes.

A colorimeter has a couple of filters and a photoresistor. A sprectrometer is a completely different beast.

You are right though in saying the black accuracy is not great on the spyder. Looks to be better on other meters. Shame.

Arm3nian

15th October 2015, 05:00

Maybe it is my display...

max brightness
http://i.imgur.com/kQn6ukC.jpg

Using my phone camera on a samsung VA tv is a completely dark picture...

Asmodian

15th October 2015, 06:39

That looks normal to me, probably 0.2-0.3 cd/m^2; you could tell if it was 0.6, that is a terrible black level. Based on reviews and including the fact that cell phone camera photos are basically impossible to judge. ;)

A bad black point measurement is possible to work around using Argyllcms but we should probably stop this in this thread. :o

Arm3nian

15th October 2015, 21:44

I guess we've learned two things. IPS panels can't display black. But it doesn't matter, because the spyder 4 can't read them :p

Back on topic. Using DP 1.2, I can get select 10 bit in NCP. But my display also has a hdmi 2.0 port, and so does my 980 ti. I can select 4k @60Hz but only 8 bpc with hdmi. The bandwidth should be enough. I wonder if this is limited by the specific display or hdmi spec, or maybe even the gpu.

nevcairiel

15th October 2015, 21:47

Back on topic. Using DP 1.2, I can get select 10 bit in NCP. But my display also has a hdmi 2.0 port, and so does my 980 ti. I can select 4k @60Hz but only 8 bpc with hdmi. The bandwidth should be enough.

HDMI 2.0 is limited to 8-bit when transmitting 4K, 60Hz, RGB.

Have a chart:
http://www.avsforum.com/photopost/data/2351937/9/97/97b5932c_HDMI2-Bandwidth.jpeg
(Nevermind the last entry)

Interestingly, one TV vendor (Panasonic) actually put a DisplayPort on their latest TV series. I hope that catches on and more do it!

XMonarchY

15th October 2015, 23:30

They're all the same gimmicky crap that hide in the shadow of professional equipment. There is no magic going on here, look at the electronics inside...

You might a get a little better accuracy in reference to something much better going from one brand to another and generation to generation, but all of them should be able to give you similar results. The main thing that changes is the bundled software and they are all awful, which is why everyone uses 3rd party applications.

No, i1Display Pro (also known as i1D3) has changed the whole "gimmicky crap" picture when it came out. Previous i1D1 and i1D2 colorimeters used different plastic-based technology and did not provide very accurate readings. However, i1D3 changed that drastically. It has been tested against $7000 Klein K-10 professional colorimeter on several displays and its readings were extremely close (within dE 0.6 or so). ColorMunki Display uses the same exact hardware i1Display Pro, but it lacks certain features, like software support, speed, ambient diffusion cap, and some other things.

XMonarchY

15th October 2015, 23:31

Colorimeters are often very bad at accurately measuring low-light conditions, so an accurate black level may not be something it can do very well.

No, colorimeters are much better at reading low-light levels than spectrometers, including i1Pro, ColorMunki Photo, and i1Pro 2. That is WHY it is advised to use spectro-profiled colorimeter to get accurate readings instead of just using spectrometer by itself.

nevcairiel

15th October 2015, 23:33

I have an i1Display Pro, and it seemed to always produce accurate values, at least judging with my eyes and what made logically sense. Like any meter it has issues with absolute black, but otherwise it seemed fine. Much better than the Spyder I had before.
Of course I never compared it to a proper "professional" device, as those things are just way too expensive.

XMonarchY

16th October 2015, 00:26

Arm3nian

16th October 2015, 01:53

colorimeters are much better at reading low-light levels than spectrometers
Source?

Asmodian

16th October 2015, 02:13

Source?

It is well known. e.g. The i1Pro has worse low light performance than the i1 Display Pro. It is best to have both a colorimeter and a spectrometer, you can use the spectrometer to calibrate the colorimeter on the display and then use the colorimeter to run the calibration.

http://www.tftcentral.co.uk/reviews/i1_pro.htm

One of the Cons: "More limited at the low luminance end than many colorimeters"

Arm3nian

16th October 2015, 03:01

Yeah it does seem colorimeters can read lower light levels. Even something like this (http://www.jeti.com/cms/index.php/instruments-55/radiometer/specbos/specbos-1211/40-products/radiometer/90-specbos-1211-uv) only goes down to .1 cd/m^2.

Damn I wish I had gotten an i1 instead of this crap spyder. I would even be ashamed to sell it on ebay based on its performance. I'd basically be lying to try and fund another device. I'll give it one more shot and if it doesn't work I'll just throw it out the window and order an i1.

Arm3nian

16th October 2015, 03:58

I sent their CS an email saying their product doesn't perform well at all. Maybe they'll send me a spyder 5 or something. Idk how I'm supposed to perform a calibration with a meter that can't see black or anything near it...

baii

16th October 2015, 04:22

I believe calibration work fine just that the reported number is disturbing? Though I haven't really seen any test/source that say either ways.

Sent from my 306SH

Asmodian

16th October 2015, 04:43

I believe calibration work fine just that the reported number is disturbing? Though I haven't really seen any test/source that say either ways.

Sent from my 306SH

If you are using BT.1886 (which I would recommended for a 1000:1 IPS) the gamma will be bad. :(

However, you can force the black point which should help a lot. The meter will be able to read close to black fine; luminance goes up very quickly as you move away from black.

Arm3nian

16th October 2015, 05:02

I already tried forcing black level, and it made no difference. I think it made it worse, because it skews the curves dramatically to try to reach the value, but it never can, because the meter always reads high...
Black point doesn't do anything either.

nevcairiel

16th October 2015, 08:30

When I calibrated with my Spyder back in the day I just discarded the values for the black, and that gave somewhat usable calibrations. Was not that big of a deal.

chros

16th October 2015, 13:11

Is there a step-by-step tutorial to calibrate my LCD TV (IPS panel) for madVR (using the above mentioned i1 Display Pro, ColorMunki Display)? I'm completely stupid about this topic.
Thanks

nevcairiel

16th October 2015, 13:45

This might get you started: http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html

XMonarchY

16th October 2015, 18:24

Spyder 1 is horrible... I once used it to calibrate plain old CCFL LCD color gamut and very low dE reading made red look orange. It may not be the case with all displays and Spyder 5 MAY be as good as i1Display Pro, but why go with MAYBE instead of what is known to be accurate, such as i1Display Pro or at least ColorMunki Display?

Arm3nian

16th October 2015, 20:08

Look at this response I got back:
thank you for your message. The contrast ratio can be based on different measurements, there is no standard and the manufacturers tech specifications are not a reference. In addition to that, such a measurement need to be done in a dark room with no reflections from walls etc. But to make long story short, please keep in mind that a photography workflow needs a contrast range that is much (very much) smaller than the capabilities of such a display. Switch off the light in your room and calibrate the monitor. That's all you need and it will deliver an accurate calibration result, as long as your operating system doesn't contain any other color adjusting tool.

CR is derived from White level / black level... that's how everyone in the industry does it. This guy basically said that the static contrast ratio spec a manufacturer provides is meaningless.

Then he claims the SI unit for luminance is not a reference...

Then his hypocrisy comes out when he says CR doesn't matter. What does that even have to do with the fact the spyder 4 can't read black levels. It doesn't mean the display's CR automatically goes down because a flawed piece of hardware can't do its job.

This company is an absolute joke.

XMonarchY

17th October 2015, 02:35

Look at this response I got back:

CR is derived from White level / black level... that's how everyone in the industry does it. This guy basically said that the static contrast ratio spec a manufacturer provides is meaningless.

Then he claims the SI unit for luminance is not a reference...

Then his hypocrisy comes out when he says CR doesn't matter. What does that even have to do with the fact the spyder 4 can't read black levels. It doesn't mean the display's CR automatically goes down because a flawed piece of hardware can't do its job.

This company is an absolute joke.

There IS a chance that its just a bad monitor unit. Does it also measure 600:1 CR before any kind of calibration? Use the most default settings with all auto-brightness, power-savings, and whatever crap modes there are. It is true that IPS monitors have very high black levels and even Spyder 4 SHOULD be able to read such high levels...

Arm3nian

17th October 2015, 05:56

There IS a chance that its just a bad monitor unit. Does it also measure 600:1 CR before any kind of calibration? Use the most default settings with all auto-brightness, power-savings, and whatever crap modes there are. It is true that IPS monitors have very high black levels and even Spyder 4 SHOULD be able to read such high levels...

I really doubt it's my monitor. But I guess the only way to find out is to buy an i1. I guess it's worth it if spending $700+ on a monitor to begin with right?

XMonarchY

17th October 2015, 17:31

I really doubt it's my monitor. But I guess the only way to find out is to buy an i1. I guess it's worth it if spending $700+ on a monitor to begin with right?

It is worth spending money on it. Period. You can use it on your current monitor, TV, projector, and future displays. Its a one-time buy and enjoy for a looong time without the need to update.

I would also advise profiling it with i1Pro if you can get your hands on it. If not, I strongly advice on rent ColorMunki Photo, which is just as accurate as i1Pro. You can rent it for 2-3 days for $40 + $20 shipping
from here - https://www.lensrentals.com/rent/calibration/colormunki . You only need 1 minute to profile i1Display Pro with ColorMunki Photo. As it was explained, spectrometers like i1Pro and ColorMunki Photo are more accurate than colorimeters like i1Display Pro because they read the actual light, while colorimeters have profiles/tables/presets that are based on display type, BUT these profiles are not always accurate for the exact display a person may have. When you profile your colorimeter with a spectrometer on your own display, you create a profile that is specific to your display and colorimeter. That way you will get awesome accuracy.

ryrynz

18th October 2015, 02:45

It is worth spending money on it.

Better off just buying it second hand or new, using it and then reselling it.. You'd lose less.

Arm3nian

18th October 2015, 07:43

I haven't tried a full on 4+ hour calibration yet, just quick ones for testing. I still think I can get a decent result if I leave the things related to black level alone. Obviously the spyder 4 is useless if trying to aim for a certain black level setting but I don't really have that requirement. Hard to justify spending $250 on something you technically already have. I wonder how something with a 14bit internal 3D LUT would respond to my specific calibration. Hopefully well.

When I calibrated with my Spyder back in the day I just discarded the values for the black, and that gave somewhat usable calibrations. Was not that big of a deal.

XMonarchY

18th October 2015, 15:16

Just to make sure - do have 0-255 (Full) range selected in your graphics card drivers?

spacediver

19th October 2015, 07:11

nothing wrong with a used i1 pro.

btw, the reason that colorimeters can read lower luminance levels is because each of the (three) sensors receives light that has been integrated across a relatively wide swath of the spectrum. Also, because you only need three sensors, they can be quite large and sensitive.

Good white paper over here (http://www.lumita.com/site_media/work/whitepapers/files/xrite-wp-3a.pdf).

If you want to read super low light levels, you could always try out this method (http://www.avsforum.com/forum/139-display-calibration/1717442-using-camera-measure-very-low-black-levels-methods-results.html). (I measured my CRT's black level at 0.0006 cd/m^2)

huhn

19th October 2015, 09:16

spectrometer/colorimeter getting inaccurate when they age. a i1d3 is the first meter i know that's relatively stable and doesn't age to fast.

but aren't we slowly done with calibration in the 10 bit output thread?

spacediver

19th October 2015, 17:14

The old DTP-94 (also known as MonacoOptix XR) is also a very stable colorimeter.

i1 pros (which is both a spectroradiometer and a spectrophotometer) are also very stable over time. If you do end up purchasing a used one, be sure to go for the revision D.

Arm3nian

20th October 2015, 07:23

Tried calibrating with a specific black level and CR got worse... 590:1

Is this the one you guys are talking about? (http://www.bhphotovideo.com/c/product/798930-REG/X_Rite_EODIS3_i1Display_Pro.html) I might as well just buy since the spyder 4 pro seems to be a useless piece of garbage. Besides the failure to measure black level, the calibration looks like absolute crap.

Is there no successor coming? i1 display pro is 4 years old.

huhn

20th October 2015, 07:53

i haven't heard anything from xrite.

but yes that's THE meter.

got quite expensive over the last years.

if i remember correctly i paid 150 euro now it's at 200 euro.

Arm3nian

20th October 2015, 08:41

Dispcal says the Colormunki Display is the same thing as i1 display pro, just slower. Probably worth saving $100, but why would it be slower if it's the same hardware...

Knowing my luck, the moment I buy the i1, the updated revision will come out, or the price will magically drop by $50. The problem with waiting is that I only got 15 more days to return my monitor if it's the problem. I would guess they would release something to compete with spyder 5 (probably crap).

spacediver

20th October 2015, 17:20

If you're comfortable using HCFR and/or ArgyllCMS, and don't mind the slower speeds that occur at higher luminances with the colormunki display, then you might as well save money and go with that. I believe the colormunki's speeds are intentionally crippled, but not 100% sure. Be aware, however, that the colormunki display will not work with commercial calibration software other than xrite's stuff. This isn't a big deal if you know how to use the free stuff like HCFR and ArgyllCMS.

Some info here (http://www.avsforum.com/forum/139-display-calibration/1845913-colormunki-display-i1-display-pro.html).

btw, just to clarify, the i1 pro is different from the i1 display pro (the former is a spectro, the latter is a colorimeter).

The i1 display pro / colormunki display is an excellent device.

XMonarchY

20th October 2015, 18:25

If you have high-refresh rate or light-strobing displays, I strongly advice i1Display Pro instead of ColorMunki Display because ColorMunki Display does not have "Refresh" mode and is not as good at adjusting to refresh rate speeds as i1Display Pro.

i1Display Pro is already very accurate - in many cases just as accurate as $7000 Klein K-10 colorimeter (reference level). Anything X-Rite may release that is even more accurate than i1Display Pro would provide a very VERY marginal benefit over i1Display Pro.

At this point - please PM either me or Spacediver or Asmodian because this thread if for 10-bit madVR discussion and we have off-tangent long enough!

Arm3nian

20th October 2015, 20:53

B&H photo said I can return the colorimeter within 30 days if I don't like it, so I just ordered the i1 display pro. We'll find out Friday what the problem is...
Back on topic everyone!:)

chros

22nd October 2015, 14:36

At this point - please PM either me or Spacediver or Asmodian because this thread if for 10-bit madVR discussion and we have off-tangent long enough!
Can you create a different topic for this? I'm (and probably not just me) interested in it. Thanks

Arm3nian

24th October 2015, 00:21

Well since there isn't much 10 bit discussion...

A quick update :D :D :D

http://i.imgur.com/vfcYug5.png

http://i.imgur.com/V8h0S02.png

Spyder 4 took a couple of minutes for that measurement. i1 display pro takes 5 seconds...

huhn

24th October 2015, 09:04

you know no one stops you from creating new threads.

XMonarchY

24th October 2015, 17:57

Can you create a different topic for this? I'm (and probably not just me) interested in it. Thanks

AVSForum - Display Calibration section is where you need to go to ask these types of questions. They have all the answers there!

Arm3nian

25th October 2015, 00:57

you know no one stops you from creating new threads.

http://forum.doom9.org/showthread.php?p=1744236#post1744236

I'll be expecting you. :devil:

Arm3nian

29th October 2015, 00:07

Would error diffusion dithering (versus ordered) have a bigger impact on 10bit output vs 8bit?

nevcairiel

29th October 2015, 00:08

Would error diffusion dithering (versus ordered) have a bigger impact on 10bit output vs 8bit?

Dithering gets less important the higher the native output bitdepth is.

Warner306

31st October 2015, 04:51

Would error diffusion dithering (versus ordered) have a bigger impact on 10bit output vs 8bit?

The difference between Ordered and Error Diffusion dithering is said to be very small, so, no, it wouldn't make much of a difference.

spacediver

31st October 2015, 20:24

I've just created what might be a much better test for determining whether your system is capable of 10 bit color. You'll need dispwin.exe from argyll to implement a LUT i've created, which simulates 1 bit color. You'll also need the attached gradient file. I've zipped up both and attached it to this post (will appear, pending approval).

Follow the same instructions as in the original post in this thread, but this time, don't disable the GPU ramp.

To load the LUT, create a batch file on your desktop that has the following lines:

cd c:\Users\spacediver

dispwin 1bit.cal

(obviously, put the appropriate directory in the first line).

Make sure that the 1bit.cal file is in that directory. In order for dispwin to work, you'll have need to installed Argyll. Latest version can be found here (http://www.argyllcms.com/). Installation instructions here (http://www.argyllcms.com/doc/Installing.html). If you don't install it properly, then it might still work so long as you copy dispwin.exe to that same directory where the LUT file is.

To reset the LUT to default, you'll need another batch file. This time, the line should read:

dispwin -c

(again, if you haven't installed argyll properly, you will need to add a line to navigate to the directory in which dispwin.exe is located).

Now, load up MadVR, and follow the instructions from the original post (being mindful to not disable GPU ramps).

If your system can output 10 bit color, then in exclusive mode, you will see five distinct shades of gray, ranging from black to white. If you're limited to 8 bit color, then you'll only see 2 shades: black and white.

What's happening is this:

The LUT only specifies two output values. 0 for the first 128 entries, and 1 for the last 128 entries.

When 10 bit is initialized, what seems to be happening is that the LUT is interpolated, so that instead of 2 distinct values, there are now 5. But it's not interpolating in an obvious manner. What happens is that the first 507 entries are coded as 0. the 508th entry is coded as what I presume is 0.25, the 509th entry is 0.5, the 510th entry is 0.75, and 511 to 1024 is coded as 1.

The 16 bit image png I've created has all five of these regions, each taking up a large amount of screen real estate. Great for seeing what's really going on (i.e dithering will be more visible when you have a large patch of screen to inspect).

Let me know if this works for you all.

edit: here (http://s000.tinyupload.com/index.php?file_id=89351674536241925457) is a working link to the zip file, until the attachment gets approved

spacediver

31st October 2015, 20:47

If I have time this wknd, I'll also create a test pattern that has only two adjacent values (to be viewed with a normal LUT). For those who have colorimeters and/or other instruments that can measure luminance, this will be a good test to see whether 10 bit precision is actually achieved (the test here will be to see whether the display can output two distinct luminances whose difference is smaller than the luminance increment in an 8 bit context).

spacediver

1st November 2015, 05:58

I've confirmed 10 bit precision by measuring the luminance of two images separated by 1 value (out of 1024). Tried making the image sequence into an avi (then using frame skipping to alternate between frames in mpc), but avi seems to be limited to 8 bit. Any suggestions on how to load a few pngs into an image sequence that can be readily stepped through in mpc? Would be much easier than having to load an image, measure, load another image, measure, etc.

huhn

1st November 2015, 12:29

vapoursynth image reader lossless x264 10 bit.

spacediver

1st November 2015, 15:13

thanks, although going through it all it might take me weeks to learn how to use it to achieve what I want. I don't know how to code in python (yet), I only know Matlab. And even if I did know python, I wouldn't know where to begin here. I gather it's all command line driven, so I'd need to figure out which plugin(s) to install, if any, how to load in the sequence of pngs, how to specify output parameters (lossless x264 10 or 16 bit), and then how to actually output it into a movie file. I'm a babe in the woods here.

chros

1st November 2015, 19:01

If your system can output 10 bit color, then in exclusive mode, you will see five distinct shades of gray, ranging from black to white. If you're limited to 8 bit color, then you'll only see 2 shades: black and white.
I wanted to try it out on my TV, but I can only see 3 colors (with or without 10 bit, OSD reports it in DXD11 FSE): white, grey, black. And the lut file is loaded fine, since I have very wierd colors on the desktop.

spacediver

1st November 2015, 19:42

chros

1st November 2015, 20:11

This is what occurs on my end when I load the 1 bit LUT. In the image below are three scenarios, depending on how you configure the bitdepth of your display in the madVR settings. The top row of each image shows the 10 bit video input level for that patch. Ignore the thin white vertical lines in the first two images - they're an inkscape artifact.

http://i65.tinypic.com/msjatz.png

Hhmm... Thanks for the pictures.
I got only similar to the 2nd one (9 bit) but all the middle 3 columns are the same grey (508 as well) in 8bit and in 10 bit. Don't know why.

spacediver

1st November 2015, 20:48

interesting. Might have something to do with the way the boundary in the 1 bit LUT is interpreted differently by the 10 bit processing in our systems. I'm using a CRT, so that might have something to do with it. Would be interesting to see what others report.

Do you have a colorimeter? If so, you can do the precision test I'm working on creating (which doesn't require a LUT manipulation).

spacediver

2nd November 2015, 04:09

K, here's (http://s000.tinyupload.com/index.php?file_id=59760266452481393460) another test pattern. This time, don't worry about LUT modifications.

It's a pattern that has 8 vertical bars, ranging from 10 bit code 0 to code 7. On my system, if I turn out the lights, I can clearly see each of the 8 bars. If I switch to 9 bit color, I see 5 bars, and with 8 bit color I see 3 bars.

Another note, all these test patterns I've been creating are 1920x1200. I'm not sure what happens exactly if you view these on a display that has a different resolution, but I doubt there'll be relevant scaling artifacts.

This is really cool - I compared this with an 8 bit test pattern going from 8 bit code 0 to code 7, and the difference is striking. In the 8 bit test pattern, the difference between adjacent bars is so much greater than in the 10 bit pattern.

Of course, the visibility of these gradations will depend on the EOTF (electro-optical transfer function) of your display. That's why it might be necessary to dark adapt before viewing.

XMonarchY

2nd November 2015, 18:24

If an 8bit output/input display has its own hardware-based dithering (non-FRC), then will it be detected as 8bit by your patterns?

spacediver

2nd November 2015, 18:58

huhn

2nd November 2015, 21:24

nevcairiel

2nd November 2015, 21:33

spacediver

2nd November 2015, 22:41

Yet if you look at the 10-bit pattern in madVR on a 8-bit display, it still is perfectly smooth, because dithering is powerful. So in conclusion, the 8-bit source image just doesn't use enough data. :)

yes, in fact I can't tell the difference between viewing the 10 bit gradient in 8 bit mode with dithering on, vs. viewing the 10 bit gradient in 10 bit mode without dithering.

But that's not really the purpose of these patterns. They're mainly meant to verify whether 10 bit is working or not, and they offer a perceptually striking way to do so. The test pattern in the original post works too, but is not as striking.

They also offer a way to probe what's actually going on behind the scenes.

spacediver

2nd November 2015, 22:48

i can see 6 shades in 8 bit window mode so not sure about this test.

That is strange. If you've turned dithering off, and have configured your display (within madVR settings) for 8 bit, then being able to see more than 3 or 4 bars means something is not right. Either dithering is being applied somehow on your end, or the test pattern is being decoded incorrectly.

Another possibility is that I've incorrectly encoded it. This is the general approach I've taken, and it seems to work perfectly on my end:

Say I want to encode a 10 bit grayscale gradient from 0 to 1023.

I first specify values from 1:1024.

I then multiply by 64, so they are properly scaled for a 16 bit file.

I then subtract 1, so that the range is 0 to 65,535.

I save the file as a 16 bit unsigned integer png file.

Quick question about madVR dithering. If the chosen dither style has a temporal component, does this get fully implemented when viewing a static png (or when a frame is paused, for that matter)?

nevcairiel

2nd November 2015, 22:51

But that's not really the purpose of these patterns. They're mainly meant to verify whether 10 bit is working or not, and they offer a perceptually striking way to do so. The test pattern in the original post works too, but is not as striking.

They also offer a way to probe what's actually going on behind the scenes.

Well, but you still couldn't really tell if something is just dithering to 8-bit, or if 10-bit are actually reaching your screen. Determining that is a near impossibility.
Of course you can use them to test if everything looks fine, though.

huhn

2nd November 2015, 22:57

yes, in fact I can't tell the difference between viewing the 10 bit gradient in 8 bit mode with dithering on, vs. viewing the 10 bit gradient in 10 bit mode without dithering.

But that's not really the purpose of these patterns. They're mainly meant to verify whether 10 bit is working or not, and they offer a perceptually striking way to do so. The test pattern in the original post works too, but is not as striking.

They also offer a way to probe what's actually going on behind the scenes.

we all ready now that the GPU driver is dithering. so how do you test with this test file if the screen is 10 bit?

spacediver

2nd November 2015, 23:07

Well, but you still couldn't really tell if something is just dithering to 8-bit, or if 10-bit are actually reaching your screen. Determining that is a near impossibility.
Of course you can use them to test if everything looks fine, though.

yep, this may be true, you'd probably need a high end oscilloscope for that.

The LUT method (http://forum.doom9.org/showpost.php?p=1745010&postcount=457), however, may offer a way to determine that without such an instrument.

In that method, the screen renders 3 intermediate shades of gray that are interpolated between 0 and 1 (in addition to the black and white regions).

Now, if a "true" 10 bit pipeline is actually being achieved here, then the intended interpolated values will be rendered at the appropriate luminance. So, for example, if the EOTF of the display is L = V^2.4, and suppose that the intended interpolated value for the middle shade of gray is 0.5, then the luminance will be 18.95 cd/m^2 (if we assume black level is 0 nits, and peak white is 100 nits).

If, however, dithering is being applied, and if the dithering is simply finding the average of the available luminances (the available luminances are 0 and 100 nits), then the luminance of the intermediate shade will be 50 nits.

Linear averaging would normally not be a problem with dithering, since the adjacent levels being averaged together are so close in luminance. But in this case, the simplicity would be exposed.

The key, of course, is to figure out how the 8 bit LUT is being interpolated when being transformed into a 10 bit LUT. That way, we can compare intended luminances vs actual luminances.

spacediver

2nd November 2015, 23:13

we all ready now that the GPU driver is dithering. so how do you test with this test file if the screen is 10 bit?

These patterns are mainly meant to provide a more striking visual difference than the pattern in the original post.

Also, I'm curious - how did people figure out that the GPU is dithering?

huhn

2nd November 2015, 23:27

take a screen that doesn't support 10 bit input and give the driver 10 bit.

the image from the first post does a good job.

and you can disable the GPU dithering with AMD.

ryrynz

3rd November 2015, 02:38

and you can disable the GPU dithering with AMD.

Does this work for Nvidia?

"search the registry for the 2D driver settings;

2D driver

Inside the registry location, create a DWORD value called DP_DisableDither and set it to 1"

spacediver

4th November 2015, 04:55

I'm gonna try and get my hands on a cheap 8 bit lcd display and do some experiments to see what's going with GPU dithering (will be the first LCD I've ever had, other than my old thinkpad).

spacediver

7th November 2015, 23:46

take a screen that doesn't support 10 bit input and give the driver 10 bit.

Just tested my original pattern with an old Dell 1908fp i borrowed from the lab. It does indeed dither like you said. Next step is to gain insight into the dithering by measuring the luminances, as detailed here (http://forum.doom9.org/showthread.php?p=1745220#post1745220). Hopefully, this will provide an objective way to determine whether the gpu is dithering or whether "true" 10 bit color is being produced. Will try to get to it this wknd if I have enough time.

huhn

8th November 2015, 01:42

8 bit dithered looks easily like 11 bit to a colorimeter so don't waste your time.

spacediver

8th November 2015, 05:08

8 bit dithered looks easily like 11 bit to a colorimeter so don't waste your time.

huh? Can you clarify? Again, here's the methodology I linked to:

The LUT method (http://forum.doom9.org/showpost.php?p=1745010&postcount=457), however, may offer a way to determine that without such an instrument.

In that method, the screen renders 3 intermediate shades of gray that are interpolated between 0 and 1 (in addition to the black and white regions).

Now, if a "true" 10 bit pipeline is actually being achieved here, then the intended interpolated values will be rendered at the appropriate luminance. So, for example, if the EOTF of the display is L = V^2.4, and suppose that the intended interpolated value for the middle shade of gray is 0.5, then the luminance will be 18.95 cd/m^2 (if we assume black level is 0 nits, and peak white is 100 nits).

If, however, dithering is being applied, and if the dithering is simply finding the average of the available luminances (the available luminances are 0 and 100 nits), then the luminance of the intermediate shade will be 50 nits.

Linear averaging would normally not be a problem with dithering, since the adjacent levels being averaged together are so close in luminance. But in this case, the simplicity would be exposed.

Asmodian

8th November 2015, 10:08

huh? Can you clarify? Again, here's the methodology I linked to:

Linear light or gamma light dithering? That sounds like it is assuming gamma light dithering.

madVR can hit a white point quite well, according to my meter, with only 1-bit for each color. Looking like more bits to a meter (eye) is why you dither and you cannot assume simple dithering methods. :)

spacediver

8th November 2015, 16:01

Linear light or gamma light dithering? That sounds like it is assuming gamma light dithering.

madVR can hit a white point quite well, according to my meter, with only 1-bit for each color. Looking like more bits to a meter (eye) is why you dither and you cannot assume simple dithering methods. :)

Yes, this proposed experiment only has the potential to reveal information. If the GPU is doing sophisticated dithering, then it will be indistinguishable. If, however, it's not, then the difference will be immediately apparent. In my opinion, it's an easy experiment worth doing. Do you agree?

If it turns out it's sophisticated dithering, I have another trick up my sleeve involving a high speed video camera.

edit: just to be clear, I think my test pattern and LUT method establish pretty conclusively that if the GPU is doing any dithering on my CRT, it's purely temporal.

XMonarchY

10th November 2015, 19:05

Is there a recommendation as far how far away one should sit to NOT see dithering? I have good vision and I can easily see it if I sit any closer than 6ft away from my 40" 1080p HDTV.

ryrynz

11th November 2015, 02:35

Is there a recommendation as far how far away one should sit to NOT see dithering? I have good vision and I can easily see it if I sit any closer than 6ft away from my 40" 1080p HDTV.

No, It'll vary for everyone based on their eyesight, screen size and type. You answered your own question basically.

omarank

25th November 2015, 16:25

Has anyone tested which is the more neutral texture filtering quality setting in AMD CCC - Standard or High Quality, for madVR?

hello_hello

25th November 2015, 22:48

Here's (http://s000.tinyupload.com/index.php?file_id=00601237761612169800) another cool demonstration. An 8 bit and a 10 bit gradient going from green (at an 8th 'brightness') to black. The 8 bit gradient has 32 steps, while the 10 bit gradient has 256 steps. Banding is clearly visible in the 8 bit case, and barely perceptible in the 10 bit case. This pattern is a good showcase for 10 bit color.

Could someone explain how this works please? I downloaded the images for a look and thought I'd try them even though the old XP PC I'm using at the moment is connected to my TV via VGA.

The two images display pretty much the same using Irfanview. 32 steps from left to right would probably be what I'm seeing, only the bands move a little to the right when displaying the 10 bit image. Irfanview says:
Original Colours: 48 bits per pixel
Current Colours: 24 bits per pixel.
A 10 bit image being displayed on an 8 bit screen (Plasma TV). That seems to make sense.

The 8 bit image displays the same way in MPC-HC but the 10 bit image looks nice and smooth, using the VMR9 renderer as well as MadVR (default settings).
So my question is, how is the 10 bit image being displayed smoothly on an 8 bit screen using MPC-HC? I'm probably being dense but the penny hasn't dropped.

The 10 bit image displays with the same banding as the 8 bit image using VLC, which I'd imagine points to the video card (8600GT) being the cause of it displaying smoothly in MPC-HC, given the video card settings normally don't effect VLC.

Thanks.

spacediver

6th December 2015, 20:31

So my question is, how is the 10 bit image being displayed smoothly on an 8 bit screen using MPC-HC? I'm probably being dense but the penny hasn't dropped.

Presumably the GPU is dithering to emulate 10 bits in an 8 bit environment.

chros

7th December 2015, 15:22

Presumably the GPU is dithering to emulate 10 bits in an 8 bit environment.
Or your display dithers. (As it turned out about mine, that it 10 bit(D) = 8bit+dither, so it dithers all the time. Maybe that's why I couldn't see your test properly.)

aufkrawall

23rd December 2015, 23:48

Edit: Forget what I said, I didn't disable deband filter...

Kirk Lazarus

24th December 2015, 00:19

chros

24th December 2015, 00:51

If somebody is unsure whether his display is 10bit capable then make sure you use full RGB output. I had to apply the RGB full range HDMI hack for the Intel iGPU then my TV passed the 16 bit gradient test.

huhn

24th December 2015, 11:51

this sound like the intel driver wasn't using dither for 0-255 -> 16-235 transform

aufkrawall

25th December 2015, 21:27

Is there visible banding with Windows 10 DWM when you select 10 bit output in the driver (and there is no banding when your display is showing undithered 10 bit input in FSE) and open the 16 bit test image in windowed mode without madVR converting it with dithering?
This is the case with plain 8 bit DL-DVI output. But I'd like to know if it makes a difference if you have a configuration where you can select 10 bit output in the driver.

huhn

26th December 2015, 14:15

banding of cause.

the desktop is still 8 bit only.
the driver never gets 10 bit.

aufkrawall

26th December 2015, 15:00

K, thanks.

XMonarchY

26th December 2015, 20:27

Does anyone know if Panasonic ST60 works with 10/12bit at 60Hz Limited or Full with NVidia's latest 361 drivers? My friend has the option to select 10bit with his HDMI High-Speed but it won't apply in Limited RGB or Full RGB range... Any ideas? There is now a remake of the film Se7en that is in 10bit!

XMonarchY

26th December 2015, 20:48

FYI: The OP Bottom Note for NVidia users about NVidia driver dithering from 10bit to 8bit (if 10bit is selected in madVR for display that only has 8bit output option in NVidia CP) is somewhat misleading. What the note says MAY happen, but not necessarily. It happens on my FG2421 monitor - the gradient is smoother when 8bit output is selected in NVidia CP and 10bit output is selected in madVR. However, the same does NOT happen on my HDTV. If I leave HDTV output @ 8bit in NVidia CP and select 10bit in madVR, the gradient will look exactly the same as if it would if I had selected 8bit output in NVidia CP and 8bit output in madVR. IMHO, that bottom note should say "MAY" more frequently.

ryrynz

27th December 2015, 03:01

chros

27th December 2015, 13:26

Does anyone know if Panasonic ST60 works with 10/12bit at 60Hz Limited or Full with NVidia's latest 361 drivers?
James Freeman stated here that it does: http://forum.doom9.org/showthread.php?p=1721663#post1721663

aufkrawall

27th December 2015, 19:56

banding of cause.

the desktop is still 8 bit only.
the driver never gets 10 bit.
AMD's "always on" dithering gets applied after DWM clipping, which makes it pointless in this case, right?

huhn

27th December 2015, 20:16

I don't know if it's always on but it doesn't matter in this case.
madVR presenting an 8 bit undithered frame to the GPU. dithering doesn't remove banding it simply doesn't add any banding.

so correct AMD dither is relative worthless in this case.

i don't know if AMD is even dithering every time.

it's known that in the past the image was changed with AMD but it is also known now that AMD is outputting 10 bit if possible by default this can be changed a now.

maybe 8 bit input with 8 bit output is now lossless.

but I don't have an full range RGB capture card to check it.

XMonarchY

29th December 2015, 19:08

Isn't 10bit+ output required to FULLY utilize / see 10bit content? If 10bit output is not required to fully utilize / see 10bit content, then what is the point of 10bit content? I assumed 10bit content would look better on displays with true 10bit+ output.

NVidia's previous drivers allowed me to select 8bit or 12bit output for my TV. The most recent 361.xx drivers now give me 3 choices - 8bit, 10bit, and 12bit. The problem I have is that selecting 10bit ends up resetting itself to either 8bit or 12bit. Any ideas why? I figured using 10bit output would be more sensible than to use 12bit output because the panel is only 10bit, and the other 2bits with 12bit setting is a "Black Box / Unknown", which could possibly be Internal Processing and / or Dithering that could increase input lag, something I'd like to keep at its minimum. Maybe it is a bug because my friend with Panasonic ST60 cannot NEITHER 12bit NOR 10bit to work with the latest 361.xx drivers even with High-Speed HDMI cable using any mix of settings (16-235 w/ RGB, 0-255 w/ RGB, 16-235 w/ YcbCr444, and 0-255 w/ YcbCr444) in 4:4:4 Direct Input mode (on other panels known as Pixel Perfect, PC Mode, etc.). However, what I can't figure out is whether he should be trying using 0-255 & 16-235 ranges through NVidia CP settings or through actual TV controls? Obviously he will need to re-calibrate to make 16-235 image accurate because right now it is in 0-255 RGB 8bit mode.

huhn

29th December 2015, 19:25

it mostly stops the encoder from creating banding and for SDR.

and for HDR 10 bit is really needed for the encode.

XMonarchY

29th December 2015, 23:12

10bit+ does that for 8bit sources too, so what's the point of doing it in 10bit? I guess anything above 8bit is worthless since ALL that 10bit+ does is reduce gradation effects, which is easily done by madVR dithering. I guess the same applies 16bit+. BUT then it makes me question - why does madVR use 16but 3DLUT processing and some other upscaling to 16bit and back to 8bit or whatever the correct term is. Is it JUST to reduce gradation visibility?

Some people say that higher color bit-depth actually increases accuracy, not just reduce gradation visibility.

Asmodian

30th December 2015, 01:11

10bit+ encoding is very nice because dithering doesn't survive lossy encodes (and 10-bit is more efficient) but 10-bit sent to the display is mostly worthless because madVR's dithering works so well.

The only time 10bit+ is useful is when you do notice the dithering noise at 8-bit, which this thread seems to agree isn't common; if you have to disable dithering to tell if 10-bit is working why bother getting 10-bit to work? HDR is different because the dynamic range is so high dithering noise is more visible.

Do not worry about sending 12-bit instead of 10-bit, input lag and further processing is not going to be different.

madVR uses 16-bit internally because that is what GPUs use natively and because there is a difference between processing and displaying. madVR has a lot of internal steps and dithering between every one would be slow and add a lot of noise in total.

10-bit does allow increased color accuracy but it is such a minor increase it is completely insignificant and entirely meaningless.

XMonarchY

30th December 2015, 04:09

In that case 10bit+ helps games' image quality more than it helps madVR's playback image quality. Here's my little thought train and I am 100% certain you, ASModian, know far more about this than I do:
- Just about any ICC profile (the grayscale "vcgt" / 1DLUT part to be precise) is going to produce visible banding on any 8bit monitor, even one made with ArgyllCMS High Quality setting/preset. ICC profiles do not include internal processing and / or dithering that can reduce banding like madVR's dithering.
- Aside from ICC profiles / 1DLUT's, ReShade TuningPalette shader allows for full grayscale and colorspace correction, but again, it does not include super-internal-processing like madVR because it is only a shader / effect, which means it also produces some banding in games (even with 4096x64 LUT).
- ReShade Dithering (or even Colored FilmGrain shader / effect from CustomFX) can be used, but Dithering / Film-Grain is applied BEFORE TuningPalette LUT / ICC profile (1DLUT). That's the opposite of what and how madVR applies Dithering, which it applies AFTER 3DLUT processing, reducing banding.
- That leaves 10bit+ as the only method to reduce banding in games and based on my personal tests, gradation smoothness difference is huge between 8bit output and 12bit output on my TV (although its only 10bit panel like all others). The big problem I see is that banding in games is rarely due to banding of adjacent levels. It is mostly due to crappy gradation where several grayscale levels are skipped, which results in very obvious banding that neither 12bit not 16bit nor any other Color Bit-Depth value can improve.

On a scale from 0-100/100, how much of the above did I actually get right?

Asmodian

30th December 2015, 06:57

That all sounds pretty much correct to me.

The only addition I have is that ICC profiles can not produce banding by allowing less accuracy for some colors so the difference between steps is not obvious or if the display doesn't need much correction. It is technically possible to apply an ICC profile in high bit depth and with high quality dithering afterwards to avoid adding banding, it is simply that most current implementations do not.

XMonarchY

2nd January 2016, 20:04

Panasonic ST60 10bit mode does not work for me at 60Hz, but it DOES work at 24Hz! When I try to select 10bit @ 60Hz, the setting simply does not stick. There is no way to select 12bit @ 60Hz. Why won't 10bit option stick at 60Hz??? Why isn't 12bit mode available at 60Hz? I had exactly the same problem on my other 12bit TV, but it was resolved when I purchased a High-Speed HDMI cable. I tried 2 different High-Speed HDMI cables for ST60, including the one that allowed 12bit @ 60hz on my other TV. Again, I can select 8/10/12bit @ 24Hz, but only 8/10bit is available for 60Hz and AFAIK there should be a 12bit option @ 60Hz, shouldn't there?

My Settings:

TV:
- Direct Pixel / PC 4:4:4 Mode
- Normal (16-235) Range

NVidia 361.43 Drivers:
- Limited (16-235) Range
- RGB

Here's what works:
- At 24Hz - 8bit OR 12bit - Full Range OR Normal/Limited Range - RGB OR YcbCr444 - any combination of these settings works as long as the refresh rate is set to 24Hz.

I know this isn't exactly a Display Hardware forum and thread, but I figured this is still a good place to ask about this issue I am having.

ryrynz

2nd January 2016, 21:15

Panasonic ST60 10bit mode does not work for me at 60Hz

That's because it's hardware limited in this respect. This has been mentioned before. (http://forum.doom9.org/showthread.php?p=1727228&highlight=st60#post1727228)
The benefits of 10 bit on this set are minor to insignificant, try a grey test pattern to see for yourself.

XMonarchY

3rd January 2016, 03:04

That's because it's hardware limited in this respect. This has been mentioned before. (http://forum.doom9.org/showthread.php?p=1727228&highlight=st60#post1727228)
The benefits of 10 bit on this set are minor to insignificant, try a grey test pattern to see for yourself.

And yet others DO get 1080p @ 60Hz to work with 10/12bit.

ryrynz

3rd January 2016, 03:32

And yet others DO get 1080p @ 60Hz to work with 10/12bit.
What others? If you can't do it, I can't do it and James can't do it then the limitations for our models are obvious.

XMonarchY

3rd January 2016, 04:11

What others? If you can't do it, I can't do it and James can't do it then the limitations for our models are obvious.

James says he CAN do it - that's my point.

ryrynz

3rd January 2016, 06:10

James says he CAN do it - that's my point.

He should comment on it again, I think It's very unlikely he actually had 10 bit accepted unless he is running a different model (different region) with different firmware (I assume you're running the latest fimrware)
You won't be able to "unlock" it if that's the case, If you can't get it now then I strongly believe you won't be able to get it at all and like I said.. it's not a big deal anyway.

KoD

3rd January 2016, 14:48

All plasma TVs use dithering all the time, it's inherent to this display technology. The discussion here about accepting 10 or 12 bit input for such TVs is moot, as they dither even 8 bit content. The strong point of plasma TVs was always their motion reproduction which is better than anything LED interpolation tech manages to do (there are always either artifacts or the "soap effect" - even though we get accustomed to the latter in time), and not their color reproduction.

Just think about it: irrespective of whether madVR or your GPU is doing dithering, your TV does it in addition to that all the time, no matter that you send it 8 or 10 or 12 bit per color. There is no way to escape the plasma image "noise" and all the other plasma tech effects. Complaining about not being able to send 10 bit is irrelevant as you have worse to worry than that.

As for whether the ST60 accepts or not 10 bit input, it might very well not because of hardware limitations. Panasonic was very late even to introduce full 4:4:4 color reproduction on their TV sets, and I think in the end it was only available on some models that had the "Pure Direct" setting. At least, that's what I remember from the reviews on hdtvtest dot co dot uk, or avforums. I have just looked now at the review for a ST60 model on hdtvtest, and when they carried the test there were sharpening issues when "Pure Direct" was enabled, so even this was not working properly - that might have been fixed in the meantime though.

chros

3rd January 2016, 15:14

Just think about it: irrespective of whether madVR or your GPU is doing dithering, your TV does it in addition to that all the time, no matter that you send it 8 or 10 or 12 bit per color. There is no way to escape the plasma image "noise" and all the other plasma tech effects. Complaining about not being able to send 10 bit is irrelevant as you have worse to worry than that.
And the same happens on my LCD CCFL IPS panel as well so it's not just about plasma.

KoD

3rd January 2016, 18:21

The plasma "dithering" is performed differently than on a LCD display though, and it's more visible. It's in fact, a side-effect of how these panels are driven, and the "noise" doesn't necessarily have a link to the actual color data.

But you are right, on any display which is driven with less than 8 bit, there will be dithering performed irrespective of technology. And in this case it's not worth bothering with 10 bit input, nothing of the extra info carried in those 10 bits will make it to the displayed image.

Warner306

4th January 2016, 04:57

My 2007 Panasonic Plasma will accept and output at 10-bits. I was able to confirm that using the test patterns in this thread. This is not surprising considering the panel is anything but thin and flimsy, and it was considered one of the top plasmas at the time. This is at 60 Hz, 4:2:2. Based on some reading here, outputting at 4:2:2 seems to be the key to proper 10-bit output -- at the cost of chroma downsampling.

I do notice the dithering introduced by plasma tech, particularly when connecting an Xbox and playing a game like NHL xx, which features a large filed of white. I wonder what the Xbox is sending? Still, motion is indeed superior to the LED in the house, as are its black levels and natural color.

huhn

5th January 2016, 06:49

you can't confirm that with that test pattern.

the only thing that can be confirmed with the test pattern is "is it possible to send 10 bit to the screen". but a lot of tricks are needed for this.

a plasma bit deep depends on the DAC. but even a 10 bit DAC isn't really worth 10 bit it's an analog signal with all of it's flaws.

in general i would avoid a high bit deep signal on a screen older than ~2009.

XMonarchY

5th January 2016, 22:12

This is so confusing. madVR uses dithering to not just remove/reduce banding, but increase accuracy. That is why it processes 3DLUT's in 16bit. If that is the case, why wouldn't 10bit+ output help Plasma TV's dither better and show more accurate colors?

Asmodian

5th January 2016, 22:42

That isn't really accurate, the 3DLUT is processed in 16-bit because that reduces or prevents banding due to the 3DLUT correction step.

The increase in accuracy isn't real because argyllcms didn't target 10-bit output steps. There is a theoretical increase but not a practical one. What I mean is that the >8-bit accuracy (from resizing or YUV to RGB conversion) is kept through the 3DLUT step but the white point isn't more precise.

The advantage for a Plasma TV, at best, would be reduced dithering noise but the noise added by the way plasma TV works is high enough you cannot tell the difference between 8 and 10-bit input.

FDisk80

28th January 2016, 07:32

Note for NVIDIA users:
Quote:
Since driver version 353.06 users can select bit depth in the Nvidia Control Panel on all systems.
If you can't see 10bit option in the CP, Nvidia will dither down to the bit depth selected if it is lower.

In other words, If you can't choose 10bit in nvidia CP and keep it on 8bit, when you run madVR in 10bit FSE, nvidia WILL Dither and you'll see smooth gradient, not true 10bit.
If you can select 10bit in Nvidia CP, the driver will NOT dither and sent true 10bit signal to your display.

Wait. What do you mean "If you can't choose 10bit in nvidia CP and keep it on 8bit".

I see only 8 and 12 options in the Nvidia control panel.

Asmodian

28th January 2016, 18:53

Wait. What do you mean "If you can't choose 10bit in nvidia CP and keep it on 8bit".

I see only 8 and 12 options in the Nvidia control panel.

Those options also depend on your display and what it accepts.

FDisk80

28th January 2016, 19:49

Those options also depend on your display and what it accepts.

I know. Not my question though.

I just don't understand the sentence "If you can't choose 10bit in nvidia CP and keep it on 8bit"

What does it mean?

Asmodian

28th January 2016, 23:04

EI know. Not my question though.

I just don't understand the sentence "If you can't choose 10bit in nvidia CP and keep it on 8bit"

What does it mean?

If you set the GPU to output 8-bit because there was not a 10-bit option in the Nvidia CP.

FDisk80

29th January 2016, 00:02

E

If you set the GPU to output 8-bit because there was not a 10-bit option in the Nvidia CP.

The options I have are 8bpc and 12bpc. There is no 10bpc.
So if I leave it at 8bpc and set 10bit in madvr nvidia driver will dither?

But if I set it to 12bpc and set madvr to 10bit nvidia driver should not dither?

Is that right?

I do see a difference in gradient test pattern when changing from 8bit to 10bit FCE in madvr with dithering in madvr disabled.

But how can I be sure that it's actually true 10bit and not nvidia's dithering kicking in instead of the madvr's dithering when I switch to 10bit FCE mode?

Asmodian

29th January 2016, 00:20

Just consider 12-bit = 10-bit for you. Nvidia will not dither 10-bit input when set to 12-bit. All else is the same, check the same way as anyone does in this thread.

Also remember to turn madVR's dithering on when you are done testing.

huhn

29th January 2016, 01:58

I do see a difference in gradient test pattern when changing from 8bit to 10bit FCE in madvr with dithering in madvr disabled.

But how can I be sure that it's actually true 10bit and not nvidia's dithering kicking in instead of the madvr's dithering when I switch to 10bit FCE mode?

when switching to 10 bit in madVR and switching to 10/12 bit in the GPU you are sending "10 bit" to the display.

and here is the next issue. how do you find out if your display is 10 bit or is 8 bit and just dithering. there is no clear answer to that.

in theory a 10 bit display should be a lot more smooth than a 8 bit screen. so the difference between sending 8 bit dithered or 10 bit dithered should be day/night. but in practice it isn't.

FDisk80

4th February 2016, 17:29

Something strange I noticed when using madVR. If I start a movie in 23.976Hz, 10-Bit FSE mode then I pause the video and let the monitor go in to standby mode, after waking it up the picture freezes (it also looks very pixelated) and only sound continues playing.
If I go out of FSE mode and back in again it continues as normal.
I'm thinking the monitor not initializing correctly by itself after a standby when running in this mode? And only restores itself to 10-Bit mode after triggering it manually?

Edit: Oops, meant to post this in madVR thread.

rivera

11th April 2016, 03:30

My config is:
- Z170-A (Intel HD Graphics 530);
- Win7x64
- madVR v0.90.17;
- latest MPC-HC;
- Panasonic PR65VT60 (not calibrated professionally).

All settings are according to the 1st post:
madVR: display->properties->10bit
madVR: display->properties->PC levels (0-255)
Panasonic: input = FullRGB
madVR: display->calibration->disable & disable GPU gamma ramp.
madVR: rendering-> general-> Direct3D 11 ON
madVR: rendering->dithering->none
madVR: rendering->general->automatic exclusive fullscreen mode (FSE)-> on
Windows: Aero = On (an appropriate theme is selected)
MPC-HC: Playback -> Repeat forever (otherwise the pleer leaves FS)

1. When I open .png file in MPC-HC there is a text in madVR OSD "fullscreen exclusive (10 bit)".
From 2.5 m from the TV screen I can see vertical stripes (about 3..5 mm width).
Same stripes I can see if "automatic exclusive fullscreen mode (FSE)-> off".
Seems there is no difference?

2. If I leave FS with "Alt-Enter" and go to FS again, then in madVR OSD there is a text "fullscreen exclusive (8 bit)".
Why it is not "10 bit"?

huhn

11th April 2016, 04:00

either your GPU, GPU driver or screen isn't able to properly dither the image.

rivera

11th April 2016, 04:06

either your GPU, GPU driver or screen isn't able to properly dither the image.
I asked TWO questions, which one are you talking about?

huhn

11th April 2016, 04:12

this one.

1. When I open .png file in MPC-HC there is a text in madVR OSD "fullscreen exclusive (10 bit)".
From 2.5 m from the TV screen I can see vertical stripes (about 3..5 mm width).
Same stripes I can see if "automatic exclusive fullscreen mode (FSE)-> off".
Seems there is no difference?

rivera

11th April 2016, 04:57

this one.
1. According to EDID, Panasonic PR65VT60 has a 10bit support:
Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
2. As for 10-bit support by Intel, I cannot find any info...

huhn

11th April 2016, 07:35

i never got it working on intel using a HD 4400.

BTW. i never saw a TV that doesn't have 12 bit input support. but that doesn't mean it is worth using.

you are most likely wasting your time on this. just by the way how a plasma works. even through there are 12 bit or higher DAC for plasma screens. doesn't really help them they are noising by nature.

i can't answer your second question this simply sounds like a bug.

rivera

11th April 2016, 08:26

you are most likely wasting your time on this.
As far as I understood from reading this thread, you are not so optimistic with the whole idea "let's try to output 10-bit"

huhn

11th April 2016, 08:52

happen when you have to 10 times tell someone you can't send 10 bit to a device if it doesn't support 10 bit input.

rivera

11th April 2016, 09:03

happen when you have to 10 times tell someone you can't send 10 bit to a device if it doesn't support 10 bit input.
You do not believe EDID?
Supports 30bpp........... Yes

huhn

11th April 2016, 09:11

no your screen supports for sure 10/12 bit input. no question.

Kirk Lazarus

13th April 2016, 07:49

Hi Guys,
I've an NVIDIA GTX 970 with latest drivers on Win 7 64bit and NVIDIA CP looks like this:

https://dl.dropboxusercontent.com/u/62605175/cp_nvidia.jpg

Like you can see I've not a 10bit selection option. Only 8bit or 12bit.

If I choose 12bit I'll have the graphic card that dither??:(

many thanks.

I guys, I reboot this post because in the first post of this thread James wrote:

"If you can't see 10bit option in the CP, Nvidia will dither down to the bit depth selected if it is lower."

So, in my case I do not have 10 bpc selection; only 8 or 12 bpc.
So if I select 12bpc do I've the nvidia dither??

Many thanks for a clarification.

kolak

13th April 2016, 17:47

in theory a 10 bit display should be a lot more smooth than a 8 bit screen. so the difference between sending 8 bit dithered or 10 bit dithered should be day/night. but in practice it isn't.

Not really true.
Well dithered 8bit can look very decent. I've done such a test on Sony broadcast OLED reference monitors over SDI. It's not day and night.

huhn

13th April 2016, 21:14

Not really true.
Well dithered 8bit can look very decent. I've done such a test on Sony broadcast OLED reference monitors over SDI. It's not day and night.

in theory a 10 bit display should be a lot more smooth than a 8 bit screen. so the difference between sending 8 bit dithered or 10 bit dithered should be day/night. but in practice it isn't.

thanks for making that clear.
I guys, I reboot this post because in the first post of this thread James wrote:

"If you can't see 10bit option in the CP, Nvidia will dither down to the bit depth selected if it is lower."

So, in my case I do not have 10 bpc selection; only 8 or 12 bpc.
So if I select 12bpc do I've the nvidia dither??

Many thanks for a clarification.

we don't know how nvidia is outputting 12 bit with an 10 bit input.

if nvidia isn't changing the image in any way it should add some 0 to the signal. that would be fine.

if nvidia is doing some processing like color correction in high bit deep than dithering would be welcome.

chros

14th April 2016, 21:10

All settings are according to the 1st post:
madVR: display->properties->10bit
madVR: display->properties->PC levels (0-255)
Panasonic: input = FullRGB
madVR: display->calibration->disable & disable GPU gamma ramp.
madVR: rendering-> general-> Direct3D 11 ON
madVR: rendering->dithering->none
madVR: rendering->general->automatic exclusive fullscreen mode (FSE)-> on
Windows: Aero = On (an appropriate theme is selected)
MPC-HC: Playback -> Repeat forever (otherwise the pleer leaves FS)

1. When I open .png file in MPC-HC there is a text in madVR OSD "fullscreen exclusive (10 bit)".
From 2.5 m from the TV screen I can see vertical stripes (about 3..5 mm width).
Same stripes I can see if "automatic exclusive fullscreen mode (FSE)-> off".
Seems there is no difference?
1. There's one more thing to set with intel drivers (at least I had to): set FullRGB output with the help of madleveltweaker (it's inside the madvr folder). Only after this I could manage to get 10bit output.

2. Always use fullscreen to check the image: just disable/enable D3D11 in options between runs.

huhn

14th April 2016, 22:32

1. There's one more thing to set with intel drivers (at least I had to): set FullRGB output with the help of madleveltweaker (it's inside the madvr folder). Only after this I could manage to get 10bit output.

2. Always use fullscreen to check the image: just disable/enable D3D11 in options between runs.

newer intel driver for hd 4400 or newer have an options for that in the driver.

chros

15th April 2016, 10:44

newer intel driver for hd 4400 or newer have an options for that in the driver.
Interesting, is it desktop or laptop?

huhn

15th April 2016, 11:04

desktop.

my hd 4400 has this option my hd 4000 doesn't have this option.

i haven't checked the hd 4000 in a long time.

rivera

15th April 2016, 20:40

1. There's one more thing to set with intel drivers (at least I had to): set FullRGB output with the help of madleveltweaker (it's inside the madvr folder). Only after this I could manage to get 10bit output.

2. Always use fullscreen to check the image: just disable/enable D3D11 in options between runs.
1. As it was mentioned above by another user, latest Intel drivers for Skylake have a corresponding option for "0-255" in Display control panel.
2. Of course I am checking this in FS exclusive.

chros

16th April 2016, 14:21

1. As it was mentioned above by another user, latest Intel drivers for Skylake have a corresponding option for "0-255" in Display control panel.
2. Of course I am checking this in FS exclusive.
OK. What's your panel string that reported by madvr? (Under devices) If it's not so specific then what's your model number of the TV?

rivera

16th April 2016, 14:41

OK. What's your panel string that reported by madvr? (Under devices) If it's not so specific then what's your model number of the TV?

1. Could you explain what you mean by "panel string"?
2. Panasonic PR65VT60.

chros

17th April 2016, 11:30

1. Could you explain what you mean by "panel string"?
2. Panasonic PR65VT60.
I was curious whether it has a 10bit panel (or 8+FRC) but it seems it has. The last idea: is "DeepColorHDMIDisable" is "0" in registry? (as it should by default) (You can check the valid path to this reg entry with the help of madleveltweaker.exe, after you drag it to the proper display.)

rivera

17th April 2016, 11:42

is "DeepColorHDMIDisable" is "0" in registry? (as it should by default)
Yes, it is 0

huhn

17th April 2016, 11:58

I was curious whether it has a 10bit panel (or 8+FRC) but it seems it has. The last idea: is "DeepColorHDMIDisable" is "0" in registry? (as it should by default) (You can check the valid path to this reg entry with the help of madleveltweaker.exe, after you drag it to the proper display.)

it's a plasma is doesn't have a real bit deep...

chros

17th April 2016, 18:02

Yes, it is 0

it's a plasma is doesn't have a real bit deep...

Then I'm out of ideas :(

rivera

17th April 2016, 18:31

Then I'm out of ideas :(
May be it works, I do not know for sure:1. When I open .png file in MPC-HC there is a text in madVR OSD "fullscreen exclusive (10 bit)".
From 2.5 m from the TV screen I can see vertical stripes (about 3..5 mm width).
Same stripes I can see if "automatic exclusive fullscreen mode (FSE)-> off".
Seems there is no difference?

chros

18th April 2016, 09:09

May be it works, I do not know for sure:
You could easily tell the difference so probably it means it doesn't work.
But this 10bit output is negligible compared to be able to get full 4:4:4 chroma output (which I can't get at all :( ).

rivera

18th April 2016, 10:36

You could easily tell the difference so probably it means it doesn't workMay be Intel Graphics 530 doesn't support 10 bit output?
Actually, there is no any info (positive or negative) for this on intel.com

chros

18th April 2016, 20:00

May be Intel Graphics 530 doesn't support 10 bit output?
Actually, there is no any info (positive or negative) for this on intel.com
I'm pretty sure it does unless something is broken in the driver. As we mentioned it's (>=10bit output) called Deep Color (it's available since HDMI v1.3) and there was also a registry entry for it in your reg.
https://en.wikipedia.org/wiki/Color_depth#Deep_color_.2830.2F36.2F48-bit.29

James Freeman

25th April 2016, 10:41

Just wanted to say that dithered 8bit looks like 12bit to the i1 Display Pro colorimeter.
If you don't see the pixels then it should looks like 12bit to your eye too.

Professional video editing software like Adobe After Effects dithers automatically the 32bit Floating workflow to 8bit at export if you choose 8bit.
The 16bit PNG test pattern looks smooth as silk when exported from AE in 8bit just like in madVR, although AE uses your typical Random Dithering like the similar setting in madVR.

James Freeman

25th April 2016, 10:55

James Freeman

25th April 2016, 12:06

Panasonic ST60 summery:
MadVR: No Dithering, PC Levels, 16bit Grey Ramp PNG.
DX11, Exclusive, 8bit or 10bit.

Banding = How the TV processes the image.
Steps = How the 16bit PNG looks without dithering in madVR (it should look like steps in 8bit w/o dithering, and smooth in 10bit w/o dithering).

YCbCr 4:4:4 8bit (always limited):
8bit = No Banding, Steps.
10bit = No Banding, Smooth (nvidia dithering).

YCbCr 4:4:4 12bit (always limited):
8bit = Banding, Steps.
10bit = Banding, Steps (nvidia quantizes it to 8bit).

RGB 8bit (Full):
8bit = Banding, Steps.
10bit = Banding, Smooth.

RGB 8bit (Limited):
8bit = Slight Banding, Steps.
10bit = Slight Banding, Smooth.

RGB 12bit (Full):
8bit = Banding, Steps.
10bit = Banding, Steps (nvidia quantizes it to 8bit).

RGB 12bit (Limited):
8bit = Banding, Steps.
10bit = Banding, Steps (nvidia quantizes it to 8bit).

Clear Winner: YCbCr 4:4:4 8bit NV-CPL, 8bit + Dithering in madVR.
TVs are made for YCbCr and it's where the best processing will probably be.

As you can see, only in YCbCr 4:4:4 8bit the ST60 doesn't generate banding.
You have a choice to get smooth steps, 10bit in madVR but nvidia will dither down to 8bit (unknown method of dithering), OR, 8bit in madVR + Dithering where Nvidia will not dither.
In a word, 10bit from madVR = Nivida dithering down to 8bit.
If nvidia dithers in 60fps then it will be better than madVR, if it is static, worse than madVR; but I have no means to verify that.

Only in 8bit (NV CPL) the 10bit in madVR is Smooth, so nvidia MUST be dithering from 10bit to 8bit when you set 8bit in CPL.
When in 12bit (NV CPL), 10bit in madVR is truncated/quantized to 8bit for some reason and it is always has steps.

huhn

25th April 2016, 12:28

BTW I can set my Dell 2410 to 10bit in Nvidia CPL, when I use display port, and indeed there is no banding when dithering is Off with the OP test.
But is the GTX series actually sending 10bit to the panel or it dithers to 8bit? Anyone actually found out?

EDIT:
After some testing, I found that the GTX dithers down to 8bit no matter what.

with amd i made 100 % sure the screen gets 10 bit.

thanks to the disable dither option.

i don't see a reason nvidia should dither down to 8 bit and still send a 12 bit signal.

in the past nvidia was sending 12 bit no matter what option was used in the CP as long as 10 bit was outputted to the driver. but i did this test nearly a year ago.

some screens can confirm what type of signal they get. so sending 12 bit but only using 8 is very unlikely.

to me it sounds like the Panasonic ST60 has broken/bad processing with high bit deep signals and that's it. the fact it shows banding with RGB 8 bit full range is a very clear indicator.

after a RGB -> YCbCr you have to dither too. YCbCr is always limited and even without that you have to dither.

nevcairiel

25th April 2016, 12:33

Panasonic ST60 summery:

Plasma TVs are not a very good reference for bitdepth measurements, as they are practically low bitdepth screens with temporal dithering.

James Freeman

25th April 2016, 12:56

I don't see a reason nvidia should dither down to 8 bit and still send a 12 bit signal.
To me it sounds like the Panasonic ST60 has broken/bad processing with high bit deep signals and that's it. the fact it shows banding with RGB 8 bit full range is a very clear indicator.
After a RGB -> YCbCr you have to dither too. YCbCr is always limited and even without that you have to dither.
Indeed, the ST60 has terrible processing in 12bit, and not the best in RGB.
The question remains whether nvidia dithers down to 8bit (as set in NV CPL) when a higher bitdepth signal is received like 10bit from madVR.
Still, nvidia's dithering is not bad at all, looks smooth, dithered 8bit can look as good as 12bit as I mentioned in the last post.
The process of RGB Full -> YCbCr 4:4:4 Limited has to be dithered alright, but it is in imperceptible.
As for 12bit NV-CPL and 10bit madVR = steps, only Jen-Hsun Huang knows what is going on in there....maybe.

Plasma TVs are not a very good reference for bitdepth measurements, as they are practically low bitdepth screens with temporal dithering.
Right, but the 8bit steps are still visible even on the plasma, so I can at least see if the input signal is smooth whether it is dithered or true high bitdepth.

huhn

25th April 2016, 13:05

Indeed, the ST60 has terrible processing in 12bit, and not the best in RGB.
The question remains whether nvidia dithers down to 8bit (as set in NV CPL) when a higher bitdepth signal is received like 10bit from madVR.
Still, nvidia's dithering is not bad at all, looks smooth, dithered 8bit can look as good as 12bit as I mentioned in the last post.

my old screen and my current screen don't show banding with 12 bit output.

the fact that your screen is showing banding with it and mine not is a indicator that nvidia isn't dithering down.

i tested my old screen with an AMD card with disabled dithering in the reg and with 10 bit output it wasn't showing banding so the screen was properly dithering down to 8 bit.

i'm kind of missing this totally flawless processing of my old very cheap Philips. it is so much better at this than my new screen...

so i say nvidia can send 10 bit worth of data to a screen.

James Freeman

25th April 2016, 13:27

You understand my difference between Banding and Steps right?
Banding = How the TV processes the image no matter how smooth it is (can look very smooth yet have banding).
Steps (gradations) = How the 16bit PNG looks without dithering in madVR (it should look like steps in 8bit w/o dithering, and smooth in 10bit w/o dithering).

The Banding on the ST60 is not like Steps, it is much more subtle, like slight color shifts in the smooth geryscale.
Here is a smooth madVR 8bit+Dither greyscale on the ST60 in YCbCr 4:4:4 8/12 bit HDMI.

The ST60 has worse banding in 12bit and in Full range.
RGB 8bit Limited has slightly worse banding than YCbCr 8bit, but not as bad as any mode in 12bit.
The ST60 prefers Limited to Full, 8bit to 12bit, YCbCr to RGB.
So YCbCr 8bit for the smoothest image on the ST60.

Have fun.

http://www.mediafire.com/convkey/8a18/9jlgclfe8rredmbzg.jpg
http://www.mediafire.com/convkey/ede1/b288i8wntw24si9zg.jpg

huhn

25th April 2016, 14:11

both screen show banding to me. (could be the camera i mean it is super noisy)

the second one is just terrible.

if you want to difference them fine by me.
i don't difference between both they are both banding to me.

James Freeman

25th April 2016, 14:26

Yes, camera is shit, TVs blacks are very dark.
The first one has no banding in real REALITY.
This information is for Panasonic plasma owners anyway.

James Freeman

26th April 2016, 08:04

Something really fishy going on with nvidia in higher bit depths.

This time with my trusty old Dell2410 10bit (8+FRC) monitor, I can select 8 or 10 bit in NV-CPL.
I disabled dithering in madVR, Video Frame (Double) and brightness to -100 in MPC-HC, and zoomed (numpad 6) and moved to the farthest left (Ctrl+Numpad 6), to clearly see the 10bit gradations (4 times as narrower).
I also had to turn the backlight to max on the monitor to see anything.
Screenshots were taken with 8 second exposure, ISO 64 for lowest noise, with my crap camera, in a completely dark room.

When nvidia control panel set to higher bit depth like 10bit (DP) or 12bit (HDMI), and madVR sends 10bit picture in exclusive mode, the result is terrible banding.

EDIT:
It might be the proof that nvidia does NOT dither when a higher bit depth is selected in NV-CPL, but simply maps it in 8bit no matter the settings in NV-CPL.
This is the worst thing that can be done when going from higher to lower bitdepth.

If set MPC-HC Brightness back to 0, the un-even gradations in "10bit NV-CPL, 10bit madVR", become even because the steps are equally divided to 4.
But if I set NV-CPL to 8bit they are always even, no matter if the brightness is manipulated and dithering is disabled in madVR, because nvidia dithers to 8bit when a higher bitdepth signal is received.

My guess is:
MadVR outputs true 10bit (no dithering) and relies on the next in chain to properly map the 10bit signal.
Nvidia receives this true 10bit signal and Dithers it to 8 bit, if 8bit is selected in NV-CPL.

But when Nvidia is set to higher bit depth (10 or 12) it just maps the received 10bit signal to 8bit without dithering therefor banding.
OR (second theory), the 10bit values madVR sends (DirectX 11 actually) mismatch the values nvidia expects, therefor maps 10bit to 10bit with slight mathematical error.

8bit NV-CPL, 8bit madVR:
http://www.mediafire.com/convkey/5d24/575leva3587o8clzg.jpg

8bit NV-CPL, 10bit madVR:
All OK as it should be, each 8bit step is now 4 steps.
Even gradations, I assume nvidia dithers down to 8bit.
http://www.mediafire.com/convkey/1c2c/w7fcqywahuzjn5kzg.jpg

10bit NV-CPL, 8bit madVR:
Same as 8bit NV-CPL, 8bit madVR.
http://www.mediafire.com/convkey/dab7/yjfg1liivbbvlqczg.jpg

10bit NV-CPL, 10bit madVR:
What is this? The gradations are not equal.
http://www.mediafire.com/convkey/a5e0/fedwr5om3ldxueuzg.jpg

huhn

26th April 2016, 12:38

i can test my cx700 again but the last time i did it it was smooth with 10 bit input.

if this is your screen it is just 8 bit. it has 10 bit processing. i didn't find a word about FRC.

http://www.tftcentral.co.uk/reviews/dell_u2410.htm

and i mean which LCD TV doesn't do 8 bit plus FRC these days?

James Freeman

26th April 2016, 12:51

Yes practically all displays have high bitdepth internal processing, but do not accept higher than 8bit input.
The Dell U2410 can actually accept 10bit input and show it. It's a wide gamut 10bit input monitor for color grading.
It's all dependent on the capability of the video card. The monitor can support 10bit colour via A-FRC dithering. If you get a graphics card capable of 10bit colour output and use the DisplayPort input on the U2410, the U2410 is capable of supporting and rendering (via dithering) 10bit colour values.

That is not the point.

The gradations I speak of have nothing to do with the display, but with Nvidia high bit depth output processing.
Apparently there is some mathematical error that causes banding if higher bit depths are selected in NV-CPL.

Please do test with your CX700 exactly as I explained.

nevcairiel

26th April 2016, 12:52

FRC is temporal dithering, so taking a single photo of something that changes over time may not do it justice. Its definitely more than 8-bit, but not quite the full 10-bit either way.
Your testing jumps to conclusions based on assumptions way to quickly.

James Freeman

26th April 2016, 12:56

8 seconds of exposure time is enough to eliminate all 1/60[s] changes don't you think?
I don't need the camera either, it's what I see with my own eyes.

Understand that it's nvidia that sends the 10bit signal to the display.
If the internal processing of nvidia has an error then that's what the display will show.
Besides, the gradients are HUGE in this test so the display is out of the question, it's something in the video card processing or driver.

I would be happy if someone could repeat my experiment with 10 or 12 bit settings in NV-CPL.

huhn

26th April 2016, 13:06

could be as simple as this:

the screen is doing processing in 10 bit. with some gamma correction is is already adding a lot of error in the image but the frame buffer is just 10 bit so some of the steps are gone even with dithering to 8 bit now.

with other words how can you show 10 steps with just 10 bit processing?

James Freeman

26th April 2016, 13:16

You might be right huhn.

nevcairiel

26th April 2016, 13:16

I just did, as I have a U2410 myself, using similar zoom setting as you (same zoom, slightly different position as it didnt want to move anymore).
I don't have any camera other than my phone, and thats not worth taking any image with.

At -100 brightness, in most areas of the screen I can see the small bars (1/4 of the 8-bit bars), in some others its pretty hard to make out all the bars as some "melt" together, which could just be the screen not being perfectly uniform, or the FRC dithering.
Of course this is all irrelevant when I turn on dithering in madVR, since the input is 16-bit, and even at 10-bit output it becomes perfectly smooth then. NVIDIA or the screen definitely do not introduce any new banding even when fed with 10-bit from madVR. So not sure what we're actually trying to proof now.

James Freeman

26th April 2016, 13:36

I tried to figure 2 things:

1. Whether nvidia dither in high bit depths, which clearly shows it does not if a lower or equal bitdepth is sent.
2. Whether the gradations I see with my Dell U2410 in 10bit NV and 10bit madVR, are from the Monitor or from Nvidia.

MadVR will output a perfectly smooth 10bit gradations with any processing applied on the 16bit pattern like -100 brightness with dithering disabled.
I think huhn is right and the old U2410 has only 10bit internal processing therefor has variable thickness banding even in 8bit.

I may jumped too early to conclusions, shoving nvidias head in the dirt... :D

huhn

26th April 2016, 13:40

8bit NV-CPL, 10bit madVR:
All OK as it should be, each 8bit step is now 4 steps.
Even gradations, I assume nvidia dithers down to 8bit.

if you ask me this looks like a perfect job from "nvidia".

nvidia doesn't need to use high bit deepo here if it doesn't touch the image with anything else than dither.

it is just doing 10 to 8 there is no need for high bit deep processing.

James Freeman

26th April 2016, 14:26

if you ask me this looks like a perfect job from "nvidia".
nvidia doesn't need to use high bit deepo here if it doesn't touch the image with anything else than dither.
it is just doing 10 to 8 there is no need for high bit deep processing.

Actually they DO dither down to 8bit, they are not that lazy.
I just tested it with my camera and they have 3 more shades of black between 0 and 1 out of 255 in 10bit.
And it's not switching my monitor to 10bit because it respects the NV-CPL setting of 8bit.
Furthermore, dithered 10bit to 8bit (by nvidia) looks much better on the U2410 than true 10bit to 10bit because the U2410 maps 10bit un-evenly.

So when a higher bit depth input like 10 bit from madVR (undithered) and 8bit in NV-CPL output, the result is similar to true 10bit because nvidia has nice down dithering.
But nvidia will not dither if the same bit depth is at the input as at the output, or lower input obviously.

I also learned today from huhn that the internal processing bitdepth of the display HAS to be higher than the highest input bitdepth the display supports, for the gradients to be smooth and equal.
The U2410 has 12bit processing (HERE (http://www.dell.com/ed/business/p/dell-u2410/pd)), bus still generates banding in 10bit input.

BluesFanUK

18th May 2016, 13:37

chros

19th May 2016, 11:27

Is there even much of a difference between 8 bit and 10 bit? I've just bought the Dell Ultrasharp U2515H (True 8 bit) and have a 980ti. MadVR for some reason allows you to select 10 bit in the control panel then it shows as 10 bit on screen. Surely it should be detected from the GPU direct?
How? :) There's no reliable way to do that. That's why you have to experiment yourself.
Is there a difference between 8 bit and 10 bit (8 bit + dithering)? Sorry if i'm being dense, but I couldn't notice a difference on my old Acer 4K S277HK (8 bit + dithering).
Visual quality wise: good question. If you don't see then it doesn't matter :) (I can't really see it either but I'm using it.)
Performance wise: definitely! 10 bit needs more bandwidth (especially when frame rate rises) than 8 bit. So this can be another reason to use 8 bit if your display doesn't support it!

kolak

19th May 2016, 12:11

Difference is quite small. If you use good dithering than it's hard to see.
I've done tests on pro equipment (Sony OLED reference monitors) and you really need to be looking for it (and have real 10bit next to it) to see the difference. It all depends on the footage, but on the real world sample with home viewing conditions it's not so obvious.

rivera

5th September 2016, 03:11

Regarding RGB48 checkbox in MPC-HC settings.
Shall I leave only this checkbox checked and rest of other ones - unchecked?

aufkrawall

5th September 2016, 16:00

You should enable all checkboxes to let madVR do the RGB conversion instead of LAV Filters.

rivera

5th September 2016, 16:26

You should enable all checkboxes to let madVR do the RGB conversion instead of LAV Filters.
Sorry, I can't see a logic.
How these checkboxes in LAV filter's settings are connected to madVR ?

Asmodian

5th September 2016, 17:01

Sorry, I can't see a logic.
How these checkboxes in LAV filter's settings are connected to madVR ?

Those control what LAV is allowed to send to madVR.

rivera

5th September 2016, 17:26

Those control what LAV is allowed to send to madVR.
So, if I select only RGB48 then doesn't that mean that only 16bit color will be used?

I have Nvidia GTX960 card.
In Nvidia Control Panel "12bit" color output is selected.
TV is Panasonic PR65VT60 plasma (10bit panel).

So, just in case I decided to permit only RGB48 output in MPC-HC.
In case of 1080p videos everything runs smooth.
But in case of 2160p videos (some test clips) no drops too, but it runs very slow (0..2 frames in a queue).
If not only RGB48 is selected (i.e RGB24, RGB32 are selected too) then 2160p videos run smooth.
So I wonder why these stuttering occurred.

CruNcher

11th September 2016, 21:27

Asmodian

12th September 2016, 00:35

Did anyone here looked deeper into the G-sync Module apart from the Variable V blank but more in the matter of the Scaling unit and FRC and into the possibility that they maybe temporarily interpolate frames on the fly gathered from the Sync Data with a G-sync Panel ?

and maybe even interpolate from a cheap 60 FPS Panel 120 and 144 HZ Signal results that their customers then sell as "real" 120 and 144 HZ Gamer Displays ?

FRC? The G-sync module doesn't do frame rate conversations, except for doubling frames when needed. You think it might be blending 144 Hz signals into a 60 Hz one to drive the panel? That seems far fetched. They also do not have a scaling unit.

It really does not seem like that is happening and TFTCentral's testing with high speed chase cams would surely show it.

There is a problem with frame "blending" but it is due to slow response times. On VA panels real response times can easily be 10ms or even higher so the panel is never fully caught up, the new frame comes before the pixels have fully set for the last one.

Why in the 10-bit thread? Even the newest G-sync modules will only accept 8-bit input, won't they?

CruNcher

12th September 2016, 20:54

I doubt they will stay at 8 bit with HDR incoming but yeah most probably to far fetched though i wondered if the Size of the FPGA Framebuffer could be enough if Nvidias DCC would be running on it additionally
Also seeing that Sony is doing the same in their driver box for the PSVR taking the 60 Hz input and FRC a 120 result and for VR it needs to be absolutely stable there you would be realizing motion misspredicitions pretty much instantly faster then you ever would on a Desktop Display.

iSeries

14th October 2016, 14:14

Hi,

For some reason I can't see 10bit in nvidia driver control panel (GTX950), only 8bit and 12bit. What happens if I set the driver to 12bit and have Madvr output 10bit? Does the driver just pad the signal with zeroes to 12bit, or does it do something undesirable? Also would anyone have an idea why I can't see 10bit in the driver? I could on my previous AMD card, with the same TV.

huhn

14th October 2016, 16:49

nvidia doesn't expose a 10 bit option if 12 bit is possible.

just hope it is padding no one knows this for sure what nvidia is doing.

Spc.

8th November 2016, 15:43

Hi everyone.
I have Dell U2410 monitor which supports 10bpc input, it has 8bit+FRC panel and i wanted to test 10bit input if it makes a difference in picture quality using method this thread mentions.

My Hardware:
Dell U2410
AMD RADEON PowerColor TurboDuo R9 280X 3GB GDDR5 OC (Tahiti)
16GB RAM
Core i7-3930k @ 4.4GHz
Windows Server 2016 Datacenter (MSDN)

Here's a test i made:

R9 280X (Tahiti) 6bpc > DisplayPort > U2410 (262144 Colors) (18 bits):
http://www.netsky.org/10bpc/6bpcamdeng.png

R9 280X (Tahiti) 8bpc > DisplayPort > U2410 (16777216 Colors) (24bits):
http://www.netsky.org/10bpc/8bpcamdeng.png

R9 280X (Tahiti) 10bpc > DisplayPort > U2410 (1073741824 Colors) (30bits):
http://www.netsky.org/10bpc/10bpcamdeng.png

I used Canon EOS 7D Mark II with EF 24-105mm L IS USM Lens (48bit RAW Files) to test image quality tests on my monitor.
As you can see image quality between 8bit and 8bit+FRC is huge.

** If you're viewing pictures in FireFox let me tell you that FireFox has a problem rendering 48bit png files, because it assumes all pictures on the web are sRGB so FireFox does read embeded ICC Color profile so you will see upper blue line as purple line, use google chrome to get exact colors, i hope FireFox fixes this bug soon. :(

I also wanted to test HDMI port on my Radeon, it does the same thing, 10bpc output on HDMI port gives me the same 10bpc quality.

On nvidia cards only Display Port connection works with higher than 8bpc settings.

While with AMD cards you can choose 10bpc on HDMI and DisplayPort, nvidia cards can only output 10bpc on DisplayPort.
If you select HDMI connection to Dell U2410 nvidia does not let you choose higher than 8bpc.

Here's a picture of R9 280X using a HDMI or Display Port:
http://www.netsky.org/10bpc/DELL+Tahiti.png

Here's a picture of GTX 960 using a Display Port:
http://www.netsky.org/10bpc/MaxwellGTX960DisplayPortU2410.png

If i choose HDMI connection, 10 bpc option disappears and I only get 8bpc option (nvidia).

My conclusion:
1. 8bit+FRC does look very good when using 10bit input and difference is very big in 8/10 input.
2. AMD Cards can use HDMI (EDID 1.3) or DisplayPort (EDID 1.4) to output 10bit per channel to monitor.
3. Nvidia Cards only work with Display Port (EDID 1.4) to output 10bpc, HDMI (EDID 1.3) does not work higher than 8bpc on DELL U2410.