madVR 10-bit Display Support Test

[huhn]

Then, Nvidia was dithering when I got smooth gradients. No?

on the monitor yes.

[XMonarchY]

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.

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

BTW, I found out that on my Eizo Foris FG2421 monitor, 10bit-to-8bit NVidia dithering occurs ONLY through DisplayPort.

[nevcairiel]

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]

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]

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]

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]

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]

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]

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]

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.

[panetesan2k6]

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]

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]

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]

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]

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]

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]

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]

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

[XMonarchY]

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]

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]

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]

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]

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]

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]

it's an 8 bit FRC display with 10 bit processing.

[Arm3nian]

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]

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.

[Arm3nian]

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]

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]

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]

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]

Different topic: DXVA scaling is always 8 bit, no matter what GPU or driver?

[huhn]

as far as we know yes it is 8 bit.

[aufkrawall]

Thanks, so it's totally useless crap. Then I'd even rather go with bilinear scaling instead of DXVA lanczos on Intel.

[XMonarchY]

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]

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]

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.

[Arm3nian]

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]

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]

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]

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]

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]

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]

the spyder 4 supports corrections.

[Arm3nian]

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]

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.

[huhn]

a dark room calibrated screen should have a brightness of 100-120 CM². people should look like plastic with such a high brightness.

[baii]

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]

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]

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.