madVR - high quality video renderer (GPU assisted)

[madshi]

If you have any idea later, I can test or make a debug log for everything you want. I tried different settings, desactivated Reclock, ffdshow,... but it doesn't change anything. I would like to use FSE mode, it's frustrating to see that when the movie begins, madVR switches correctly to 24hz but at the moment I go in full screen it switches to 23hz whatever I do.
Well, I guess I could make a test build to try out some things, but this is going to be *really* hard to fix without being able to reproduce it.

madshi: are you interested in a log for this issue? I'm all out of ideas here. Even the old rendering path has the exact same issue on my system.
Interested? I don't think it would be of help for madVR development because I don't think it's madVR's fault and there's probably nothing I can do about it. But I'd be willing to look into a debug log to help you. Although I think what I'll find will probably be an unexplained period where either the GPU rendered very slowly, or where madVR got no CPU time. Do you have any software running which might be using the GPU? Try closing that. Are there any background processes or services which might stress the CPU every once in a while? Try stopping them, too. Also try giving the media player process a higher priority. Maybe any of that helps?

It wasn't actually overlay issues with the 650>hdmi>lcd tv. It' nvidia's drivers forcing pc levels on 25, 30, 50, 60hz and tv levels on 24 and 48 hz over hdmi. I had it setup to enable overlay only when ivtc was enabled so I thought overlay was the culprit like it has been for a long time on svideo. nvidia seems to be forcing pc levels on all dvi out, tv levels on s-video.
Ok, I guess the madLevelsTweaker only works for digital HDMI. Before we found that registry tweak (used by madLevelsTweaker) the solution to the levels problem with NVidia GPUs was to create custom resolutions for all display modes / refresh rates. This also effectively forced the GPU to output 0-255. Maybe that trick also works for s-video?

The level tweaker doesn't seem to have an effect on hdmi or s-video out with nvidia gpus, haven't tested dvi yet.
It definitely works for HDMI, at least when talking about the digital part of HDMI. That's the very thing the levels tweaker is for.

If I switch from the sRGB to my Rec.709 calibration target, the BT.709 example suddenly is also closest (which is expected, I guess).

So this really is directly bound to the calibration itself.
Yes.

Am I the only one that thinks perceived the tone response is downright atrocious with gamma in the avatar comparison?
I think the overall look fo the gamma image is very very wrong (much too brightened up). The majority of users agrees with that. However, as was said before, this all depends very much on how your display is calibrated. If your display were calibrated to a 1.0 gamma curve (which it definitely should not be) then the gamma light dithered image would look very near to the original.

My TV is calibrated to Rec709/sRGB with BT.1886 gamma curve using ArgyllCMS LUT. The best image that mimics the original is the Linear BT.709 and the next best one is Gamma. Others are too dark. I know Graeme firmly considers BT.1886 gamma to be THE gamma to use, but I am not sure how it relates to dithering gamma...
Did you use BT.1886 with a 2.2 or 2.4 gamma value?

I may have missed something, but "use colored noise" doesn't seem to have effect on ED. But works for others...
The effect for the low-noise ED algorithm is slight, but it should be there. The medium-noise ED algorithm should show a noticeable difference with "use colored noise" enabled - at least in gray scale test images.

IMHO people need to stop judging too much at low bitdepth.
At 8-bit, any of the linear ones will probably solve the issue that Gamma presents, since the effect is miniscule there.
Agreed.

Gamma is brighter than the original. BT.709 2.2 is darker than original. The rest are much, much darker.
This suggests that your overall calibration is very "bright". If BT.709 2.2 is already darker than the original for you then your calibration is noticeably brighter than the standards recommend for a light controlled room. Did you do the calibration this way to account for ambient lighting?

What I'd really like to see is a test build which allows me to change the inverse curve used with linear dithering.
Perhaps the solution is to have it follow the settings chosen in "this display is already calibrated" then, and add a selection when loading 3DLUTs?
And Customization options for more advanced users or ones that read the thread.
Isn't dithering the final step before rendering? In that case, shouldn't it (luminance) map to whatever the device is calibrated too? Based on the settings in the calibration tab.
I agree, it should follow the calibration tab. (and 3DLUTs will need a preference to set what their display is calibrated to)
I hear you. But there are serious problems. There are multiple different situations:

(1) Neither gamma ramps nor 3dlut on the HTPC. madVR set to "disable calibration controls". I can only guess here which transfer function to use.
(2) Neither gamma ramps nor 3dlut on the HTPC. madVR set to "this display is already calibrated". This is the easiest case.
(3) Same as (1) and (2), but the display is calibrated by using GPU gamma ramps (but no 3dlut). This is very complicated because in Overlay mode the GPU gamma ramps are applied before dithering, while in Windowed and FSE modes the GPU gamma ramps are applied after dithering. Which means I'd have to ask the user for 2 different transfer functions, depending on rendering mode (Overlay vs. windowed/FSE)!
(4) Display is calibrated by using a 3dlut, but no GPU gamma ramps. This is complicated because the 3dlut calibration is performed *before* dithering. Which means the dithering itself should be done with the transfer function of the uncalibrated display. But does the user even know that transfer function? And how to get this information from the user without confusing him?
(5) Display is calibrated by using a 3dlut + GPU gamma ramps. Combine all the problems of (3) and (4) and make them extra difficult because every possible combination of (3) and (4) and different rendering modes has to be supported.

I think you can see how achieving perfection would be a usability nightmare! I'd have to add several new transfer function setting controls, with very confusing descriptions (like "I know you calibrated your display with a 3dlut, but what transfer function does your display produce, if the 3dlut is not applied?"). This doesn't really make any sense, considering that the potential gain in image quality is so extremely small.

So I've decided to choose the easy way out: Let's decide on one transfer function that I'll use for linear light dithering. It will always be used, to make things simple and comparable. Sorry, but making this adjustable just isn't worth the usability nightmares. I'm currently thinking of using BT.709 2.2. This will probably produce a too bright image on many displays, but it will be much nearer to the correct look on *all* displays compared to gamma dithering. Alternatively I could use a pure power curve of 2.2, or BT.709 2.4, but while these might look better on many displays, they will already be too dark for some monitors out there. So I'm thinking, maybe BT.709 2.2 would be the conservative and best solution. But if the majority of you guys think I should be using a pure power curve of 2.2 or BT.709 2.4 instead, that's fine with me, too. One additional argument for BT.709 2.2 is that it happens to be the encoding transfer function. That's not really important, though.

Thoughts?

[James Freeman]

So I've decided to choose the easy way out: Let's decide on one transfer function that I'll use for linear light dithering.
(as a novice):
Agreed.
I don't see the difference in 8-bit anyway so I'll be happy about any choice we finally make.
IMO to save 10 pages of heated debate, just create a poll thread with test images and let users vote (who read this thread or not).
Our goal is to find the average consumer TV/Monitor Gamma curve, which should be quite interesting to know.

On the other hand (as an Advanced user),
You can always put a LinearLight.ini file in the madVR directory which lets advanced users tweak this independently of what "situation" they use.
Its by far the easiest option to satisfy all advanced users without being a coding nightmare for you nor clattering madVR settings window..

[Shiandow]

I think you can see how achieving perfection would be a usability nightmare! I'd have to add several new transfer function setting controls, with very confusing descriptions (like "I know you calibrated your display with a 3dlut, but what transfer function does your display produce, if the 3dlut is not applied?"). This doesn't really make any sense, considering that the potential gain in image quality is so extremely small.

Thoughts?

You can get a reasonable estimate of most transfer functions using just two variables, this requires more effort from the users but might be worth it. The basic idea is not to try to use the entire gamma curve but only approximate the local gamma. You could cover a very wide range of use cases to a reasonable accuracy using only the following code:


#define depth 255
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float4 low = floor(depth*c0)/depth;
float4 hi = low+(1/depth);
float4 gamma = max(1,g*low/(low+a));
float4 c1 = (pow(c0,gamma)-pow(low,gamma))/(pow(hi,gamma)-pow(low,gamma));
return low+(c1/depth);
}

You just need to change the constants g and a to get a different curve, for instance:

Rec. 709: a = 0.099, g = 1/0.45
sRGB: a = 0.055, g = 2.4
any pure power curve: a = 0, g = gamma.

[James Freeman]

You could cover a very wide range of use cases to a reasonable accuracy using only the following code:


#define depth 255
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float4 low = floor(depth*c0)/depth;
float4 hi = low+(1/depth);
float4 gamma = max(1,g*low/(low+a));
float4 c1 = (pow(c0,gamma)-pow(low,gamma))/(pow(hi,gamma)-pow(low,gamma));
return low+(c1/depth);
}

You just need to change the constants g and a to get a different curve, for instance:

Rec. 709: a = 0.099, g = 1/0.45
sRGB: a = 0.055, g = 2.4
any pure power curve: a = 0, g = gamma.

madshi,
Why not just create a LinearLight.ini file in the madVR directory which lets advanced users tweak this independently of what "situation" they use and without clattering madVR Settings control panel?

[madshi]

You can get a reasonable estimate of most transfer functions using just two variables, this requires more effort from the users but might be worth it. The basic idea is not to try to use the entire gamma curve but only approximate the local gamma. You could cover a very wide range of use cases to a reasonable accuracy using only the following code
The problem is not the algorithm/code. The problem is usability, adding setting controls, needing different settings for different rendering modes etc. Please read the big list of problems I posted in my previous comment again. Your comment does not address any of those problems.

[cyberbeing]

This suggests that your overall calibration is very "bright". If BT.709 2.2 is already darker than the original for you then your calibration is noticeably brighter than the standards recommend for a light controlled room. Did you do the calibration this way to account for ambient lighting?
You have that reversed. My overall calibration if anything would be "dark" so to speak (avg gamma ~2.40), except near-black to account for behavior of the BT.709 curve.

I've not measured my most recent calibration, but usually it's something like the following with Argyll CMS BT.709 curve scaled to 32lux ambient lighting on my CRT:

Near-black = 1.90 avg gamma
Mid-tones = 2.45 avg gamma
Near-white = 2.60 avg gamma

Remember I mentioned the L* (L*a*b* luminance) curve before? That's essentially what this matches, except near black.


If I instead calibrate to BT.1886 it is usually:

Near-black = 2.10 avg gamma
Mid-tones = 2.35 avg gamma
Near-white = 2.40 avg gamma

[iSunrise]

madshi, could you at least provide us with a single test build with a checkbox selection for, say, sRGB 2.2, BT.709 2.2 and BT.709 2.4 so we can compare them directly to finally be able to make the decision to only select one transfer function easier.

It would be a lot easier (for me) when using actual test files and compare them first-hand, instead of having to guess how they might look like, because currently, we only have the hardcoded 1/0.45 to work with.

I think BT.709 2.2 would probably be too bright again, but I'm not sure, because I've never seen it with actual test material on my display. Otherwise, my choice would be the current 1/0.45, since starting from 3bit the current linear light 1/0.45 transfer function already looks more accurate here than gamma light could ever look.

I want to be absolutely sure that before suggesting something, it doesn't bite us in the ass at 8bit for some reason. Also, if we choose a linear light approach that resembles the bright gamma results, we would basically have not won anything and I just want to avoid that at all cost, because 1/0.45 was already giving us very good results.

Edit: Blurred:
http://abload.de/img/blurredt6pk0.png
Just for references sake, on my iPad 3, which is factory calibrated to sRGB / Rec.709 and 2.20 gamma (http://www.displaymate.com/Surface_RT_ShootOut_1.htm) the middle and right grey rectangles are 100% identical. It looks like one big, even grey rectangle. Can't even see a difference when zoomed in. Perfect match. The current 1/0.45 seems to be perfect.

[Werewolfy]

Well, I guess I could make a test build to try out some things, but this is going to be *really* hard to fix without being able to reproduce it.


I understand, I'm still looking what I have in particular that can affect the refresh rate. I know you're very busy with dithering questions but when you have the time to make a test build, you can be sure I will be there to test it.

[leeperry]

My overall calibration if any thing would be "dark" so to speak (avg gamma ~2.40)
My average gamma reads 2.41 in HCFR: http://thumbnails110.imagebam.com/31334/0a0b00313337938.jpg (http://www.imagebam.com/image/0a0b00313337938)

The same settings look great on still images & TV, I like a dark gamma.

[cyberbeing]

My average gamma reads 2.41 in HCFR: http://thumbnails110.imagebam.com/31334/0a0b00313337938.jpg (http://www.imagebam.com/image/0a0b00313337938)

Your gamma chart slants in the opposite direction of mine (BT.709 | BT.1886). :p

Personally, I don't think it makes practical sense to have a darker gamma near black and progressively brighter up to near-white like you are showing on your display. That's like the exact opposite of what should have a linear appearance to humans. Everything is subjective though, and maybe that's just a quirk of your display's calibration controls?

[Asmodian]

I think BT.709 2.2 is a reasonable compromise, that is the brightest of the three linear options and the closest to gamma. However, if I have a vote I vote for sRGB. sRGB is the default PC gamma as assumed by Photoshop, Firefox and the like. Something at ~2.4 gamma would look better to me at 2-bit but that is too far outside the "middle" for me to think it is a good candidate. :)

I've not measured my most recent calibration, but usually it's something like the following with Argyll CMS BT.709 curve scaled to 32lux ambient lighting on my CRT:

Near-black = 1.90 avg gamma
Mid-tones = 2.45 avg gamma
Near-white = 2.60 avg gamma


Odd cyberbeing, these gamma values are almost exactly the same as the gamma I measure but sRGB or pure power looks the best to me. Amazing how different CRTs are vs IPS.

My average gamma reads 2.41 in HCFR: http://thumbnails110.imagebam.com/31334/0a0b00313337938.jpg (http://www.imagebam.com/image/0a0b00313337938)

The same settings look great on still images & TV, I like a dark gamma.

What a strange gamma, it gets lower as it increases? All my BT.1886 calibrated gammas increase with brightness. You must like nice dark shadows. :)

[leeperry]

Well, my TV only comes with a global gamma setting that goes from -3 to +3, I don't like how clear -1 looks and -2 looks just great. And it's not a matter of GL looking too clear and compensating for my dark gamma AFAIK as both HD DVB-T from the built-in tuner and still images in Windows look equally great to me.

In that chart (http://a.imageshack.us/img510/6814/ghostingtestblanc100.jpg) I only miss the two darkest shades, I'm used to the high native contrast of CRT and high ANSI contrast of DLP projectors, this gamma curve makes me plenty happy...sure, I'm cheating but I make do with the low 3.5K:1 native contrast. Now that I think of it, I vividly remember a friend of mine on HCFR using the same kind of sliding gamma curve on his 3K:1 DLP projector and being most happy with it.

[James Freeman]

Nobody's actually offering a solution?

[madshi]

A solution to what? I've already said that I've decided to use only one transfer function. The only question I need an answer to is which one transfer function should be used. Currently I tend to pick BT.709 2.2.

[iSunrise]

Now I know why cyberbeing and leeperry seem to prefer gamma light to linear light. I just connected our Samsung F6500, which I carefully calibrated on movie mode, to my iPad over Airplay and I agree with both of them. When I switch between the original 8bit avatar and the 2bit gamma, they are perfectly even, while everything else is way too dark. To my surprise, even linear BT.709 1/0.45 is way too dark.

[madshi]

I just connected our Samsung F6500, which I carefully calibrated on movie mode, to my iPad over Airplay and I agree with both of them. When I switch between the original 8bit avatar and the 2bit gamma, they are perfectly even, while everything else is way too dark.
Honestly, if that's the case then either your calibration is messed up, or you watched the images zoomed again (instead of at 100%). leeperry only tests in 8bit and comments more on things like subjective pop-effect, edge enhancement and color tones and less on gamma curves and brightness. And cyberbeing already said that the gamma 2bit image is too bright.

[James Freeman]

3 of the PC displays I have are closer to sRGB 2.4,
2 of the TVs are closer to BT.709.

[iSunrise]

Honestly, if that's the case then either your calibration is messed up, or you watched the images zoomed again (instead of at 100%). leeperry only tests in 8bit and comments more on things like subjective pop-effect, edge enhancement and color tones and less on gamma curves and brightness. And cyberbeing already said that the gamma 2bit image is too bright.
I'm still sitting in front of the screen, I made sure that they are at 100%. Can't explain it either, didn't expect that at all to be honest. The Samsung also already had an extremely good calibration out of the box, I didn't change much at all, so this is still relatively close to the factory mode, not sure how I could mess this up, I would have noticed that already. I also disabled every post-processing option, black optimizer, dynamic contrast, etc. so this is as good as it gets for a natural image.

cyberbeing basically said that on his CRT with perfect black reproduction, gamma light is a bit brighter, while the linear light ones are way too dark, which is almost exactly what I see here.

[nevcairiel]

http://www.geforce.com/whats-new/articles/nvidia-geforce-335-23-whql-titanfall-drivers

Does 335.23 fix OpenCL for Nvidia users?

It does not, which is no surprise.
This is a game-support release from the same r334 branch.

It'll take a real new driver for that.

[6233638]

I'm currently thinking of using BT.709 2.2. This will probably produce a too bright image on many displays, but it will be much nearer to the correct look on *all* displays compared to gamma dithering. Alternatively I could use a pure power curve of 2.2, or BT.709 2.4, but while these might look better on many displays, they will already be too dark for some monitors out there. So I'm thinking, maybe BT.709 2.2 would be the conservative and best solution. But if the majority of you guys think I should be using a pure power curve of 2.2 or BT.709 2.4 instead, that's fine with me, too. One additional argument for BT.709 2.2 is that it happens to be the encoding transfer function. That's not really important, though.I'm unclear on what you mean by "BT.709 2.2"
The BT.709 transfer itself has a best-fit curve of 1.96 (1/0.51)

Are you referring to using an exponent of 0.45 as "BT.709 2.2"?
Or are you taking the BT.709 transfer function and then scaling it to 2.2? (^1.125)
What do you mean when you say "BT.709 2.4"? (and how are you getting there?)


Most of the papers I have read suggest that the system gamma should be 1.2 (~2.35) though Poynton suggests 1.25 (~2.45) and BT.1886 now targets 2.40 gamma, which is the first actual standard we have that defines what gamma should be on the display.

Just about everything says that you should be using a pure power function rather than the inverse of the BT.709 camera gamma with its linear tail near black. Otherwise you are counteracting the entire point of it being there.

Remember I mentioned the L* (L*a*b* luminance) curve before? That's essentially what this matches, except near black.L* should not be used on a display, and is far too bright near black.

I seem to recall one calibration package that defaulted to it years ago, and it caused all sorts of problems.
You are better off using a scaled BT.709 transfer than L* though I wouldn't recommend that either.

BT.1886 should produce much better results than either of those, as it calculates the "just noticeable difference" values based on your display contrast/black level, and basically gets you as close to the ideal 2.40 as possible without crushing shadow detail.

Just for references sake, on my iPad 3, which is factory calibrated to sRGB / Rec.709 and 2.20 gamma (http://www.displaymate.com/Surface_RT_ShootOut_1.htm) the middle and right grey rectangles are 100% identical. It looks like one big, even grey rectangle. Can't even see a difference when zoomed in. Perfect match. The current 1/0.45 seems to be perfect.Well the iPad 3 has a good 2.2 gamma calibration out of the box, a small screen size and a high pixel density which would do a good job of minimizing the dither artifacts, so I can see why that would be the case.
This is the same reason why I was testing on a retina macbook - similar pixel density, which makes the comparison easier to do.

However, if we have to settle for a single transfer function, an ideal display will be using a flat 2.40 calibration for video. Not 2.2
I would much rather it be based upon an ideal display than what looks fine on a crappy low contrast monitor.

...over Airplay...Airplay uses lossy compression and rescales the image, the results of this test are invalid.

[iSunrise]

Airplay uses lossy compression and rescales the image, the results of this test are invalid.
Direct audio and video playback is lossless if they are within specs, airplay mirroring over an AppleTV is definitely lossy though, since it needs to be encoded by the iPad itself. Also, the rescaling part is true, since the iPad and TV resolution and aspect ratio differ. Indeed, you are right, maybe not the best example.

[madshi]

I just connected our Samsung F6500, which I carefully calibrated on movie mode, to my iPad over Airplay
or you watched the images zoomed again (instead of at 100%)
I'm still sitting in front of the screen, I made sure that they are at 100%.
Airplay uses lossy compression and rescales the image, the results of this test are invalid.
Nope, Airplay is lossless, at least for audio, the rescaling part is true, though, because the iPad resolution and the TV resolution and aspect differ, so that may indeed not be the best example.
Please make sure you do valid tests before posting. This is the 2nd time you posted results with zoomed images, although I have repeatedly stated that you have to take *extra* care to make sure to view them unscaled.

cyberbeing basically said that on his CRT with perfect black reproduction, gamma light is a bit brighter, while the linear light ones are way too dark
You've just skewed what he said to fit better to your previous comment. Here's what he wrote word-by-word:

"Gamma is brighter than the original. BT.709 2.2 is darker than original. The rest are much, much darker."

Now can we please stop this?

I'm unclear on what you mean by "BT.709 2.2"
I mean using the exact encoding transfer function, 1/0.45 on the power part of the BT.709 curve, IIRC.

Just about everything says that you should be using a pure power function rather than the inverse of the BT.709 camera gamma with its linear tail near black. Otherwise you are counteracting the entire point of it being there.
If you look at the feedback from the users here about the 2bit Avator screenshots, it was all over the place. There were quite a lot of votes for either BT.709 or sRGB (both of which have a linear segment), and also a lot of votes for the pure power curve image.

If we all had displays with perfect black levels, everybody would calibrate to a pure power curve. But that's not the reality. In reality displays are calibrated with all sorts of different black level compensation tweaks, BT.1886 just being one of many in practical use today. So because of that I personally think using a BT.709 curve for dithering might be a reasonable compromise, bringing us in safe distance from the incorrect gamma dithering, but without going too far for *any* of the half way properly calibrated displays. Yes, dithering to the BT.709 encoding function is not far enough away from gamma dithering for well calibrated displays with good black levels. But then, since I've decided to only support one transfer function for linear light dithering, I have to find a good compromise.

So 6233638, I suppose you're voting for 1/0.45 pure power?

[cyberbeing]

L* should not be used on a display, and is far too bright near black.
...
You are better off using a scaled BT.709 transfer than L* though I wouldn't recommend that either.
You didn't read my posts clear enough. I am using a BT.709 transfer function with Argyll CMS ambient light scaling. This just happens to match L* very closely from levels 64-255.

From what I remember, a true L* curve is far too dark near black (~2.6 gamma), rather than too bright.

It's the sRGB & BT.709 curves which are comparatively brighter near-black. BT.1886 is as well, but usually to a lesser extent than the other two.

BT.1886 should produce much better results than either of those, as it calculates the "just noticeable difference" values based on your display contrast/black level, and basically gets you as close to the ideal 2.40 as possible without crushing shadow detail.
I go back and forth, but overall I prefer the appearance of an ambient scaled BT.709 curve.

BT.709 2.4
Could you post one last linear dither image using that BT.709 2.4 transfer function? And maybe another with a 2.4 power-curve?

[Farfie]

I'm going to have to agree with 6233638: my vote's for pure power.
Well, assuming his vote is for pure power, but it does seem that way. Either way, that's my vote.

[Ver Greeneyes]

Most of the papers I have read suggest that the system gamma should be 1.2 (~2.35) though Poynton suggests 1.25 (~2.45) and BT.1886 now targets 2.40 gamma, which is the first actual standard we have that defines what gamma should be on the display.Are those just the desired curves, or are they also the best match for what consumer hardware actually does? Remember, unless you use a videoLUT while watching videos in madVR, or unless madVR took the 1D LUTs into account as well, this linear light transform should be targeting the native transfer function of your monitor. If most consumer hardware natively uses an s-style gamma curve, that would be the ideal target.

If BT.1886 is a good fit for consumer hardware, it could be implemented with a single parameter to indicate the contrast (= [measured luminance of black] / [measured luminance of white])*. Then madVR's linear light transform could doconst float glcontrast = pow(contrast, 1.0 / 2.4);
const float a = pow(1.0 - glcontrast, 2.4);
const float b = glcontrast / (1.0 - glcontrast);
return a * pow(max(color + b, 0.0), 2.4);Of course a and b could all be calculated in advance.

* maybe that doesn't match contrast as people intuitively understand it. You could make it [measured luminance of white] / [measured luminance of black] and then use glcontrast = 1.0 / contrast internally.

[madshi]

Could you post one last linear dither image using that transfer function?
I thought you already found the 2.2 BT.709 too dark? Of course the 2.4 will be even darker...

my vote's for pure power.
K, thanks.

[iSunrise]

This is the 2nd time you posted results with zoomed images, although I have repeatedly stated that you have to take *extra* care to make sure to view them unscaled.
I took extra care. I just forgot that the iPad has to rescale when mirroring, instead of doing a lossless transfer. I already explained that I was wrong, no need to remind me again.

You've just skewed what he said to fit better to your previous comment. Here's what he wrote word-by-word:

"Gamma is brighter than the original. BT.709 2.2 is darker than original. The rest are much, much darker."

Now can we please stop this?
I really hope you're kidding. Are you seriously accusing me of deliberately skewing the results? Jesus, something is seriously wrong with you today.

Please stop with the personal attacks and stay on topic. You're way out of line.

I already made pretty clear that I would choose BT.709 (2.2 or 2.4) and that the current 1/0.45 is very accurate already. It's still your decision, not sure why you suddenly think I would even think about trying to fool you into something. I would never do that.

[cyberbeing]

I thought you already found the 2.2 BT.709 too dark? Of course the 2.4 will be even darker...
Don't you have that reversed? Won't the dithering be brighter since it's intended to be correct when viewed on a "darker" 2.4 gamma display?

[seiyafan]

hmm... I calibrated my monitor gamma to L* using basICColor, but I also had sRGB and 2.2 options, which do you guys prefer for watching movies?

[Asmodian]

Don't you have that reversed? Won't the dithering be brighter since it's intended to be correct when viewed on a "darker" 2.4 gamma display?

The dither is being distributed to match the shades of the gamma curve. At 2.2 each step near black is further apart so the dither uses more 1's to hit 1.5 than it would at 2.4. At least this is how I think the effect works. :)

hmm... I calibrated my monitor gamma to L* using basICColor, but I also had sRGB and 2.2 options, which do you guys prefer for watching movies?

2.2 but if you get crushed blacks try sRGB.

[madshi]

I really hope you're kidding. Are you seriously accusing me of deliberately skewing the results?
It's not that uncommon in forums (or politics, or even real life) for people to slightly skew quotes to support their argument. No need for you to feel personally attacked. I apologize if you didn't skew the quote intentionally, but your quote was not fully accurate. Of course you could have avoided that by taking the time to look up his exact quote, but you didn't, while I did.

The reason I'm slightly on edge right now is that it's going on my nerves that I have to spend time on commenting on incorrect tests and inaccurate quotes, and then getting replies to my comments which are still incorrect, while all the time my comments were spot on. Time is running through my fingers, and I would really like to spend it more useful than this. I'm generally very patient. But the one thing I absolutely hate is if my time goes wasted.

Don't you have that reversed? Won't the dithering be brighter since it's intended to be correct when viewed on a "darker" 2.4 gamma display?
Hmmmm... Good question. I'm slightly confused about this right now. Wait. The dithering is not supposed to "undo" the display's gamma curve. It's supposed to interpolate the missing shades in such a way that it looks similar to your display's transfer function. With 2bit dithering, those 4 grayramp values are fixed to your display's transfer function and madVR dithers the other possible shades so that the interpolation nicely fits between those 4 fixed values. Which means in theory the better the madVR linear light dithering transfer function matches your display calibration function, the better the end result should look like. But I do wonder right now in which situation which screenshot should look darker or brighter. I'm not sure if my previous thoughts about this are correct.

In any case, since the linear light dithering uses the transfer function to interpolate in the same way as the display is calibrated, this definitely means that using a higher gamma value makes the dithered image darker. Which is confirmed by looking at the gamma dithered image, which with a pure power curve of 1.0 is the brightest of them all. So it follows that the BT.709 2.4 image would be darker than the BT.709 2.2 image.

[Asmodian]

The dither is being distributed to match the shades of the gamma curve. At 2.2 each step near black is further apart so the dither uses more 1's to hit 1.5 than it would at 2.4. At least this is how I think the effect works. :)

Ah I think I see where this logic went wrong. With a gamma of 2.2 1.5 is supposed to be brighter vs 1 than it is with a gamma of 2.4.

[cyberbeing]

Hmmmm... Good question. I'm slightly confused about this right now. Wait. The dithering is not supposed to "undo" the display's gamma curve. It's supposed to interpolate the missing shades in such a way that it looks similar to your display's transfer function. With 2bit dithering, those 4 grayramp values are fixed to your display's transfer function and madVR dithers the other possible shades so that the interpolation nicely fits between those 4 fixed values. Which means in theory the better the madVR linear light dithering transfer function matches your display calibration function, the better the end result should look like. But I do wonder right now in which situation which screenshot should look darker or brighter. I'm not sure if my previous thoughts about this are correct.

In any case, since the linear light dithering uses the transfer function to interpolate in the same way as the display is calibrated, this definitely means that using a higher gamma value makes the dithered image darker. Which is confirmed by looking at the gamma dithered image, which with a pure power curve of 1.0 is the brightest of them all. So it follows that the BT.709 2.4 image would be darker than the BT.709 2.2 image.

Whatever the case may be, I'd still be interested in seeing how linear dither compares using an inverse transfer function of a 2.4 power-curve (vs 2.2 power-curve) and BT.709 2.4 (vs BT.709 2.2). That would instantly clear up any confusion on the matter. If linear dithering is matching the appearance of the encoding/image gamma, then 2.4 linear dither would be brighter than 2.2 linear dither. If linear dithering is matching the appearance of the decoding/display gamma, then 2.4 linear dither would be darker than 2.2 linear dither.

[6233638]

I mean using the exact encoding transfer function, 1/0.45 on the power part of the BT.709 curve, IIRC.Ah I see. That would be linear (the inverse of the BT.709 signal, system gamma of "1") but closer to 1.96 gamma as previously mentioned. (1/0.51)

To change those values, you change the system gamma and not the exponent.
Apply ^1.125 to the values output from the BT.709 curve for "2.2 gamma" (1.125/0.51 ≈ 2.2) ^1.2 for 2.35 gamma (1.2/0.51 ≈ 2.35) etc.


I guess that this means that the current implementation of the "BT.709" curve options is not correct. (at least when set to anything but 2.20)
If we all had displays with perfect black levels, everybody would calibrate to a pure power curve. But that's not the reality. In reality displays are calibrated with all sorts of different black level compensation tweaks, BT.1886 just being one of many in practical use today.Well I'm going to be strongly in favor of using 2.40 gamma because my display does have perfect black levels.

And you don't need "perfect" black levels, only 0.01cd/m2, which many displays are exceeding today.

Full array local dimming LCDs are returning this year, and a year or two from now, the price on OLEDs will have dropped and be more mass-market.

If you're targeting monitors or cheap edge-lit screens, sure they won't hit 10,000:1 but I don't see videophiles chasing after the best they can get using those.
So because of that I personally think using a BT.709 curve for dithering might be a reasonable compromise, bringing us in safe distance from the incorrect gamma dithering, but without going too far for *any* of the half way properly calibrated displays. Yes, dithering to the BT.709 encoding function is not far enough away from gamma dithering for well calibrated displays with good black levels. But then, since I've decided to only support one transfer function for linear light dithering, I have to find a good compromise.It seems that the people complaining about shadow detail in the 2-bit images are the ones who prefer the results from using gamma-light dithering rather than linear-light dithering anyway, so I don't know that I would try and compromise between the two.

If you're going to base it on the BT.709 transfer, I would at least like to see the values scaled to 2.2 gamma (^1.125) if not 2.4 (^1.225)

So 6233638, I suppose you're voting for 1/0.45 pure power?Well I would vote for 2.40 pure power rather than 2.22, though that option seems to be off the table.

1/0.45 seems to be the best of the options you have presented so far though.

Are those just the desired curves, or are they also the best match for what consumer hardware actually does?Just about any high-end projector or flat panel should exceed 10,000:1 contrast, so they should be able to hit a pure power 1/0.45

[Ver Greeneyes]

Just about any high-end projector or flat panel should exceed 10,000:1 contrast, so they should be able to hit a pure power 1/0.45My crappy monitor does just 300:1 ;_; But that's neither here nor there, really. So you're saying 1/0.45 should be a pretty good match for (uncalibrated) display devices today?

[6233638]

So you're saying 1/0.45 should be a pretty good match for (uncalibrated) display devices today?Yes, it's probably the best match if the goal is to target an "average" display rather than a properly calibrated high-end display.


I suspect a lot of people might be happy with the BT.709 transfer scaled to ~2.2 gamma though. (possibly preferred to 1/0.45)
But that wouldn't be my choice.

[markanini]

sRGB(spot on)>Linear(dark)>709(bright)
No big surprise here, my browser is color managed and the monitor is calibrated and profiled to sRGB.

MadVR uses a 3DLUT targeting BT.1886 2.4, so I'm not sure what this is supposed to tell me.

[Ver Greeneyes]

I suspect a lot of people might be happy with the BT.709 transfer scaled to ~2.2 gamma though. (possibly preferred to 1/0.45)
But that wouldn't be my choice.I'd certainly be happy with that right now, since I'm using a videoLUT calibrated to that target ;) But after I recalibrate (taking all this new stuff into account) I'm going to try the windowed overlay mode again and at that point, I would expect 1/0.45 to be a better match since it won't be affected by the videoLUT (I hope, assuming everything works as people have said).

[zoyd]

Here's my vote FWIW and not doing any actual testing. I would pick a BT.1886 transfer function with black level 0.03 cd/m^2 and white level 120 cd/m^2 as your standard. This is a good compromise between high-end and mid-range displays. Average power law gamma for this display above 5% stimulus is 2.25 but it will give you a BT.1886 interpolated dither between your anchor points.

[Shiandow]

The problem is not the algorithm/code. The problem is usability, adding setting controls, needing different settings for different rendering modes etc. Please read the big list of problems I posted in my previous comment again. Your comment does not address any of those problems.

I was trying to suggest adding a (hidden) option that allows you to change those two constants, since they are more or less the only ones you need. Unfortunately I have no idea how you'd easily explain what those two constants are. But it solves the problem of having to deal with every possible case of different calibrations etc. although it does this by making the (advanced) users do this work... You could also just tell users that if they want to do this then they should just use a shader, since the linear light code was designed as a shader in the first place.

One part that still puzzles me about this entire discussion is that noone has mentioned anything about these colour inaccuracies before, yet as far as I can tell smooth motion has been using a pure power gamma curve the entire time. This should cause far worse inaccuracies since it depends on the entire gamma curve, not just a small part of it. Also nobody seems to have noticed that in 8 bit the difference between gamma light an linear light processing requires more than 16bit processing to cause any difference once you get to pixel values above 30 or so. It would make sense to just blame the entire discussion on the placebo effect and just pick a curve. I'd be in favour of using an sRGB curve though, most monitor's I've seen had a gamma close to sRGB and for those calibrated to BT. 709 the linear segment of sRGB should remove the most obvious differences.


const float glcontrast = pow(contrast, 1.0 / 2.4);
const float a = pow(1.0 - glcontrast, 2.4);
const float b = glcontrast / (1.0 - glcontrast);
return a * pow(max(color + b, 0.0), 2.4);Of course a and b could all be calculated in advance.


The constant 'a' shouldn't change the result, so you don't even need to calculate that one. Also interestingly, this seems to have exactly the same local gamma as an sRGB like gamma curve, except with slightly different constants and without a linear segment and with a cutoff at white.

[*Touche*]

I agree with 6233638. BT.1886 should be the target, which would mean 2.4 pure power as the closest practical choice. Any miniscule differences, if any at all, would certainly be more appreciated on good TVs than crappy monitors.

[madshi]

To change those values, you change the system gamma and not the exponent.
That's mathematically more expensive. I'm changing all the constants including the exponent, which produces the same overall result. That's why I still like to talk about BT.709 with 1/0.45 or 2.4 exponent.

I was trying to suggest adding a (hidden) option that allows you to change those two constants, since they are more or less the only ones you need.
But that doesn't address the problem that when using GPU gamma ramps, in Overlay mode you'd need different constants than in windowed/FSE mode. And as you say, if those options aren't properly named, nobody would know how to set them "properly".

Here's my vote FWIW and not doing any actual testing. I would pick a BT.1886 transfer function with black level 0.03 cd/m^2 and white level 120 cd/m^2 as your standard. This is a good compromise between high-end and mid-range displays. Average power law gamma for this display above 5% stimulus is 2.25 but it will give you a BT.1886 interpolated dither between your anchor points.
Interesting. Maybe something like this would really make sense. After all BT.1886 is the recommended way to calibrate. But then, the question is which assumed black level and white levels produce the best results for the majority of displays out there. This might be hard to figure out...

I agree with 6233638. BT.1886 should be the target, which would mean 2.4 pure power as the closest practical choice. Any miniscule differences, if any at all, would certainly be more appreciated on good TVs than crappy monitors.
Well, I don't think 6233638 suggested BT.1886, he suggested a pure power curve. But your last sentence does make sense! And zoyd suggested to use BT.1886 with "reasonable" black/white levels. Which does make some sense to me.

Whatever the case may be, I'd still be interested in seeing how linear dither compares using an inverse transfer function of a 2.4 power-curve (vs 2.2 power-curve) and BT.709 2.4 (vs BT.709 2.2). That would instantly clear up any confusion on the matter. If linear dithering is matching the appearance of the encoding/image gamma, then 2.4 linear dither would be brighter than 2.2 linear dither. If linear dithering is matching the appearance of the decoding/display gamma, then 2.4 linear dither would be darker than 2.2 linear dither.
Alright. The 2 new screenshots are now made with monoColor, the others remain in oppositeColor:

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (pure power 2.22) (http://madshi.net/avatar2bitLinear.png) -|- linear (pure power 2.4) (http://madshi.net/avatar2bitPurePower24.png) -|- linear (sRGB 2.4) (http://madshi.net/avatar2bitSRGB.png) -|- linear (BT.709 2.22) (http://madshi.net/avatar2bit709.png) -|- linear (BT.709 2.4) (http://madshi.net/avatar2bit709_24.png) -|

[zoyd]

Interesting. Maybe something like this would really make sense. After all BT.1886 is the recommended way to calibrate. But then, the question is which assumed black level and white levels produce the best results for the majority of displays out there. This might be hard to figure out...



In terms of color difference errors those assumptions split the difference between pure power 2.2 and pure power 2.4. White level has a very small effect on the overall function so anywhere from 100-200 cd/m^2 is about the same. The tougher one is black level and the value I chose (around 3000:1 contrast) is a good middle ground for what's out there.

[madshi]

In terms of color difference errors those assumptions split the difference between pure power 2.2 and pure power 2.4. White level has a very small effect on the overall function so anywhere from 100-200 cd/m^2 is about the same. The tougher one is black level and the value I chose (around 3000:1 contrast) is a good middle ground for what's out there.
Sounds good to me. But let me double check: Which black level do average DLP projectors have? I think we should not choose a black level better than what average DLP projectors can do.

[Shiandow]

Well, I don't think 6233638 suggested BT.1886, he suggested a pure power curve. But your last sentence does make sense! And zoyd suggested to use BT.1886 with "reasonable" black/white levels. Which does make some sense to me.


The problem with choosing an gamma curve based on what high end screens use is that the effect of linear light dithering is most obvious on a screen which can only display 6 bits, which isn't exactly high-end. That said I have no idea how much difference it would make, if BT. 1886 is more or less in between a pure power gamma of 2.2 and 2.4 then it should probably look alright on most 'low end' 6 bit monitors as well.

[DarkSpace]

madshi, I'm curious: Earlier, you said that you dislike the idea of having the dynamic dithering mode change the pattern at "video rate" (once for every frame the decoder outputs and the Smooth Motion blended frames) and changed the dithering pattern and screen refresh rate. However, you hinted (and I just confirmed it by playing a 5 fps video at 1 bit dithering) that the new version of madVR changes its dithering pattern only at "video rate" rather than screen refresh rate. Why?

Regarding the ongoing discussion about linear light dithering, I guess I'll just take whatever I'll get in the end, as on my laptop screen I prefer the sRGB dithered version, while on my TV, I prefer the pure power dithered version. Furthermore, none of those screens is calibrated, so I'm not even certain that what I'm seeing is "correct" (I do see a great improvement over gamma dithering, though).

[cyberbeing]

Alright. The 2 new screenshots are now made with monoColor, the others remain in oppositeColor:

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (pure power 2.22) (http://madshi.net/avatar2bitLinear.png) -|- linear (pure power 2.4) (http://madshi.net/avatar2bitPurePower24.png) -|- linear (sRGB 2.4) (http://madshi.net/avatar2bitSRGB.png) -|- linear (BT.709 2.22) (http://madshi.net/avatar2bit709.png) -|- linear (BT.709 2.4) (http://madshi.net/avatar2bit709_24.png) -|
Thanks, the "BT.704 2.4" dithering is definitely producing a darker image than the "BT.709 2.22". It's as you suspected.

There seems to be something wrong with the "pure power 2.4" screenshot though? It looks identical to the "linear (pure power 2.22)" screenshot, taking into account monoColor vs oppositeColor differences. Though at least this confirms that the increase in saturation and shifted color hues in the linear dithering images isn't caused by oppositeColor dither.

[XMonarchY]

IMHO Linear Rec.709 2.4 is again the closes to the original image.
Is Linear Rec.709 2.4 same as BT.1886? I am not an expert on this, but AFAIK Rec.709 does not specify a gamma, so using Rec.709 2.4 is a bit misleading, but what do I know...

[XMonarchY]

BTW, new drivers from nVidia are out - 335.23, but release notes do not mention any OpenCL <-> D3D9 interop information. I will check them out and let you know if NNEDI3 works with them.

[seiyafan]

2.2 but if you get crushed blacks try sRGB.

Thanks, I will calibrate my monitor to 2.2