madVR - high quality video renderer (GPU assisted)

[James Freeman]

Seriously, this is getting messy. And I think I'll cheap out with keeping things as they are.
Its not cheapping out, its conforming to a standard.
Stick with the standard 2.2 power curve for LL Dithering and Smooth Motion, and be done with it.
You can always change it if suddenly ITU comes with a new standard (or OLED's get extremely cheap ;)).

One curve cannot fit ALL displays, but all displays can be calibrated to ONE curve (if the display is capable enough).

[6233638]

Could we please stop these arguments? They don't go anywhere. I've decided to not add settings controls for dither transfer functions. This is set in stone. No further discussion needed. You may not like my decision. But you'll have to live with it.Yes, this is getting really tedious for what should amount to an almost imperceptible change.

It's not what I would prefer,but I assume it's going to be fixed at 1/0.45, which is fine.

[Ver Greeneyes]

Personally I think I'll vote for BT.1886 hardcoded to a contrast ratio of 1200:1 (best match for sRGB). I don't think the fact that the slope is a little steeper near zero is going to hurt anyone (even monitors with ridiculous contrast ratios) and it should be somewhat better in the reduced bitdepth modes near zero (so for people with 6-bit LCDs, say) while still being continuous (where sRGB is not). IMO these are the configurations we should be focusing on here, since the lower bitdepth modes benefit more from this (at 8-bit the difference from gamma light is miniscule).

But if you end up sticking with 1.0/0.45, I won't complain (like I said I can't tell the difference in 8-bit mode using 8-bit source material, which is all I regularly use).

[iSunrise]

Look: If I had simply ignored the whole linear light topic, we would have stopped at v0.87.6, and every one of you guys would still have been happy, isn't that right? Now the next build will give you even more quality than v0.87.6, but suddenly you're unhappy?
I would not interpret that as unhappyness, it's just that sometimes it is possible to compromise and satisfy everyone, while in this case, there are just too many variables.

I can only speak for myself here, madshi, but I already am very happy with the hardcoded 1/0.45 right now, because the improvements I see at lower bit depths and up easily were worth the time to include that.

If there would have been a "simple" fix for the dark areas, I guess that the majority would have never even thought about anything else.

Power users always want everything accurate in every case, which is not possible, because sRGB and BT.1886 were never meant for the same tasks.

Yes, this is getting really tedious for what should amount to an almost imperceptible change.

It's not what I would prefer,but I assume it's going to be fixed at 1/0.45, which is fine.
I agree.

[mindz]

Does the colored noise and change dither every frame work for all dither algorithms, or only for ED?

[madshi]

Its not cheapping out, its conforming to a standard.
Stick with the standard 2.2 power curve for LL Dithering and Smooth Motion, and be done with it.
Yes, this is getting really tedious for what should amount to an almost imperceptible change.

It's not what I would prefer,but I assume it's going to be fixed at 1/0.45, which is fine.
Personally I think I'll vote for BT.1886 hardcoded to a contrast ratio of 1200:1 (best match for sRGB). I don't think the fact that the slope is a little steeper near zero is going to hurt anyone (even monitors with ridiculous contrast ratios) and it should be somewhat better in the reduced bitdepth modes near zero (so for people with 6-bit LCDs, say) while still being continuous (where sRGB is not). IMO these are the configurations we should be focusing on here, since the lower bitdepth modes benefit more from this (at 8-bit the difference from gamma light is miniscule).

But if you end up sticking with 1.0/0.45, I won't complain (like I said I can't tell the difference in 8-bit mode using 8-bit source material, which is all I regularly use).
I would not interpret that as unhappyness, it's just that sometimes it is possible to compromise and satisfy everyone, while in this case, there are just too many variables.

I can only speak for myself here, madshi, but I already am very happy with the hardcoded 1/0.45 right now, because the improvements I see at lower bit depths and up easily were worth the time to include that.
Thanks, guys. FWIW, I'm currently considering using sRGB for bitdepths lower than 8bit, because display which don't natively support 8bit (mainly cheap LCD panels) probably also have rather bad contrast. For 8bit dithering I haven't fully decided yet. Could be a 2.2 power curve, or could be a BT.1886 curve with black & white levels set to match a good TV.

Does the colored noise and change dither every frame work for all dither algorithms, or only for ED?
Should work for all algorithms, except "none", of course.

[Qaq]

I've decided to not add settings controls for dither transfer functions.Probably pretty lame question but why not make dither transfer functions dependent on display calibration settings?

[6233638]

For 8bit dithering I haven't fully decided yet. Could be a 2.2 power curve, or could be a BT.1886 curve with black & white levels set to match a good TV.Well what do you consider a "good TV"? Because I don't like anything that can't do black, and when your black level gets below 0.01 (which many displays are) you then use 2.40 power.

I'd rather see 1/0.45 than some arbitrary BT.1886 curve.

[James Freeman]

i'd rather see 1/0.45 than some arbitrary bt.1886 curve.
...
+1

[Audionut]

Look: If I had simply ignored the whole linear light topic, we would have stopped at v0.87.6, and every one of you guys would still have been happy, isn't that right? Now the next build will give you even more quality than v0.87.6, but suddenly you're unhappy?

Not unhappy. Just making sure we're getting ever last miniscule percent :p


I'd rather see 1/0.45 than some arbitrary BT.1886 curve.

+1

[*Touche*]

Well what do you consider a "good TV"? Because I don't like anything that can't do black, and when your black level gets below 0.01 (which many displays are) you then use 2.40 power.

I'd rather see 1/0.45 than some arbitrary BT.1886 curve.

+1

Either 1/0.45 or pp2.4.

[QBhd]

i'd rather see 1/0.45 than some arbitrary bt.1886 curve.

...
+1

[Shiandow]

Ouch. It seems Shiandow was right.

Unfortunately this gets all very complicated very fast because again we don't necessarily know the transfer function of the display, and there might be calibration on the HTPC involved, which is performed *after* smooth motion processing, and then we have dithering involved, too, because we can't really send floating point pixels to the display.

Seriously, this is getting messy. And I think I'll cheap out with keeping things as they are. Unless you guys have great new ideas. But they would need to cover all the countless different situations, with internal and external calibrations, overlay mode, windowed mode, FSE mode. Unknown native display curves etc etc.

Well, FWIW I think that it doesn't really matter if you use the monitor's gamma curve after smooth motion or not, it's just somewhat convenient since you've got everything in linear light anyway. What does matter is how you eventually use the monitor's gamma curve, I'm reasonably sure that this should be done somewhere and preferably this should be before dithering and after smooth motion (you can also do it before smooth motion but then you've got to convert to linear light again so that's just a waste of time).

Now the problem is that I don't really know exactly how the different settings are applied. The easiest case seems to be "this display is already calibrated" where you directly get the gamma curve, then it's just a matter of applying this correctly. It gets more complicated when you've got a LUT, I fear that currently those don't exactly have the information you need. What you need is a table that tells you which pixel value has which colour, I fear the LUT does this the other way around. The linear interpolation I proposed also gets quite a lot harder in 3D and depends on whether you use monoColor or oppositeColor noise. I currently know no easy way to solve this. Also if the 3DLUT is created by linear interpolation then it also doesn't make sense to use the shader I proposed (you could technically run the shader using the 3DLUT as gamma curve, but that is probably infeasible.)

Anyway I don't think it makes sense to use that shader with a LUT, and I think it will be too hard to apply this LUT correctly (unless you can actually change the way the LUT is created but that's a different matter altogether). So I think that currently the best way to do it is to at least try and apply the "this display is already calibrated" setting 'correctly', otherwise if someone either has no calibration or displays at a low bitdepth then I'd use the shader with some well chosen gamma curve (Bt 1886 sounds reasonable). It might actually be possible to also apply the "calibrate this display by using yCMS" setting 'correctly' since you've got to input a gamma curve, but that will probably require you to change the code for that option entirely, so I don't think that's a good idea.

[DarkSpace]

Ok, let's think this through. Let's say we want to smooth motion blend a white and a black frame, 50% each. Let's say the source gamma is a pure power 2.2 curve and the display is externally calibrated to a pure power 2.4 curve, to make things simple. So currently smooth motion calculates the mixed gray in linear light by using "(pow(0.0, 2.2) + pow(1.0, 2.2)) / 2 = 0.5". Now if we convert this back to gamma light by using the source gamma we get "pow(0.5, 1 / 2.2) = 0.72974". If we convert it back to gamma light by using the display gamma we get "0.74915353843834075" instead. We send either value to the display, let's suppose we can do this in floating point. Now the display converts this back to linear light by using the display's gamma. So it does "pow(value, 2.4)". But we do want to end up with 0.5 in linear light.

Ouch. It seems Shiandow was right.
I see. Then, however, you will also have to gamma-correct the non-SM frames to have them match colors in case of identical images being sent from the decoder.
And I thought madVR's Gamma Correction (and 3D LUT Correction) features were supposed to take care of that, not Smooth Motion itself?

Anyway, what I was confident about was merely that you should use the same gamma curve to convert to and from LL in SM. And your example gives the exact same result when using a 2.4 Gamma Curve to convert to Linear Light, by the way (that's why I tried blending identical colors: I know what result to expect, while with your example, I'm not sure).

EDIT: I think I know why Shiandow and I have different opinions: I am under the impression that madVR mainly works in Gamma Light, and whenever it uses Linear Light, it converts the end result back to Gamma Light for the next step. I believe Shiandow thinks that madVR works in Linear Light and converts to and from Gamma Light whenever necessary (basically the exact opposite of what I think).

[Ver Greeneyes]

I'd rather see 1/0.45 than some arbitrary BT.1886 curve.Remember though that the constant offset introduced by BT.1886 with a specific contrast ratio doesn't matter for our purposes, since we only care about the (nonlinear) differences between colors. So the only effect of a different contrast ratio is that the slope changes. Since the drawback of using a pure power function is that black gets crushed, I think using a limited contrast is actually safer. It still gets most of the effect of using a nonlinear transfer function without the drawbacks of a pure power law or the discontinuity of sRGB.

That's my reasoning, anyway. I don't think the difference is big enough to make a big deal out of it though.

[madshi]

Probably pretty lame question but why not make dither transfer functions dependent on display calibration settings?
This has been discussed on the last 10 pages up and down, back and forth.

Well, FWIW I think that it doesn't really matter if you use the monitor's gamma curve after smooth motion or not, it's just somewhat convenient since you've got everything in linear light anyway. What does matter is how you eventually use the monitor's gamma curve, I'm reasonably sure that this should be done somewhere
Why? The normal CE playback path is this: Source device decodes video and passes it to the display untouched, in its original gamma encoding. That's it. No processing at all in the source device (except chroma upsampling from 4:2:0 to 4:2:2 because HDMI doesn't support 4:2:0). So why would madVR have to use the monitor's gamma curve at all?

Of course the situation changes if we're talking about doing calibration on the HTPC, or complicated processing (like smooth motion FRC) in linear light, or dithering in linear light. But all of those are strictly optional.

I see. Then, however, you will also have to gamma-correct the non-SM frames to have them match colors in case of identical images being sent from the decoder.
And I thought madVR's Gamma Correction (and 3D LUT Correction) features were supposed to take care of that, not Smooth Motion itself?

Anyway, what I was confident about was merely that you should use the same gamma curve to convert to and from LL in SM. And your example gives the exact same result when using a 2.4 Gamma Curve to convert to Linear Light, by the way (that's why I tried blending identical colors: I know what result to expect, while with your example, I'm not sure).

EDIT: I think I know why Shiandow and I have different opinions: I am under the impression that madVR mainly works in Gamma Light, and whenever it uses Linear Light, it converts the end result back to Gamma Light for the next step. I believe Shiandow thinks that madVR works in Linear Light and converts to and from Gamma Light whenever necessary (basically the exact opposite of what I think).
To be honest, I'm still half way confused about how it would have to be done for mathematically perfect results, in all the complicated combinations, taking possible internal and/or external calibration into account, and linear light dithering, and some processing steps being applied before calibration, and others after calibration etc etc. Probably we'd need a rocket scientist to figure all that out, and even the rocket scientist would have to ask the user all kinds of questions which most users wouldn't know the answer to, in order to be able to calculate the mathematically perfect algorithm.

[Shiandow]

Why? The normal CE playback path is this: Source device decodes video and passes it to the display untouched, in its original gamma encoding. That's it. No processing at all in the source device (except chroma upsampling from 4:2:0 to 4:2:2 because HDMI doesn't support 4:2:0). So why would madVR have to use the monitor's gamma curve at all?

For consistency? I think that ideally a video should look the same regardless of the monitor that's used to play it, up to some difference in brightness/contrast. And you've taken the trouble of asking people what their monitor's characteristics are, are you suggesting to completely ignore those settings? What is it exactly that you are doing with those settings now?

[madshi]

For consistency? I think that ideally a video should look the same regardless of the monitor that's used to play it, up to some difference in brightness/contrast. And you've taken the trouble of asking people what their monitor's characteristics are, are you suggesting to completely ignore those settings? What is it exactly that you are doing with those settings now?
Calibration is supposed to take ambient light levels into account. E.g. in a batcave with total light control you will calibrate your display differently than you would if there's a lot of ambient light. So with default settings it doesn't make sense for madVR to try and "undo" the display calibration by forcing the video to look the same on every display. Only if the HTPC is used to calibrate the display (e.g. through a 3dlut), only then it's up to the HTPC to define with which exact gamma curve the video should ideally be shown to the user. Or alternatively if the user tells madVR to modify the display's gamma curve. Otherwise it's the job of the display calibration to decide that.

Currently the settings in the "this display is already calibrated" section are only used for 2 things:

(1) If the source gamut differs from the display gamut, madVR converts the source gamut. This is necessary because the display doesn't know which gamut madVR is sending.

(2) If you enable gamma processing, madVR looks at the desired gamma curve and the display's native gamma curve to calculate a correction which converts the display to the desired gamma curve. But this is only done if you manually activate gamma processing. It's turned off by default. And it should be, IMHO.

[Shiandow]

Calibration is supposed to take ambient light levels into account. E.g. in a batcave with total light control you will calibrate your display differently than you would if there's a lot of ambient light. So with default settings it doesn't make sense for madVR to try and "undo" the display calibration by forcing the video to look the same on every display. Only if the HTPC is used to calibrate the display (e.g. through a 3dlut), only then it's up to the HTPC to define with which exact gamma curve the video should ideally be shown to the user. Or alternatively if the user tells madVR to modify the display's gamma curve. Otherwise it's the job of the display calibration to decide that.

Well I think I've isolated the confusing part, according to wikipedia:


"Rec. 709 is written as if it specifies the capture and transfer characteristics of HDTV encoding - that is, as if it were scene-referred. However, in practice it is output (display) referred with the convention of a 2.4-power function display."


Which seems to say that the luminance that was recorded is different from the one that should be displayed. Which is incredibly confusing... Anyway this seems to suggest doing the following:


Convert to linear light using a 2.4-power function (or whatever has been specified by the "use gamma processing option").
Blend the frames
Encode using the monitor's gamma curve.

Which would probably require a complete overhaul of the entire way gamma is currently processed. Anyway the above method would ensure that the output of the monitor will look like whatever monitor has been specified by the "use gamma processing" option. I'll leave it to you to decide whether it's worth the trouble to have technically correct output. I can't even judge if the above is compatible with 3DLUTs (I fear not).

[Vyral]

Calibration is supposed to take ambient light levels into account. E.g. in a batcave with total light control you will calibrate your display differently than you would if there's a lot of ambient light. So with default settings it doesn't make sense for madVR to try and "undo" the display calibration by forcing the video to look the same on every display. Only if the HTPC is used to calibrate the display (e.g. through a 3dlut), only then it's up to the HTPC to define with which exact gamma curve the video should ideally be shown to the user. Or alternatively if the user tells madVR to modify the display's gamma curve. Otherwise it's the job of the display calibration to decide that.

Currently the settings in the "this display is already calibrated" section are only used for 2 things:

(1) If the source gamut differs from the display gamut, madVR converts the source gamut. This is necessary because the display doesn't know which gamut madVR is sending.

(2) If you enable gamma processing, madVR looks at the desired gamma curve and the display's native gamma curve to calculate a correction which converts the display to the desired gamma curve. But this is only done if you manually activate gamma processing. It's turned off by default. And it should be, IMHO.

From where madVR retrieve the display's native gamma curve ?

And, if we use "disable calibration controls for this display" and don't enable gamma processing, the source gamut is used without correction ?

[madshi]

Well I think I've isolated the confusing part
That's just one small part of what's making this complicated, IMHO.

Which would probably require a complete overhaul of the entire way gamma is currently processed. Anyway the above method would ensure that the output of the monitor will look like whatever monitor has been specified by the "use gamma processing" option. I'll leave it to you to decide whether it's worth the trouble to have technically correct output. I can't even judge if the above is compatible with 3DLUTs (I fear not).
3dluts are another part of the complication. But the biggest part is the same list of problems I already posted several times in the dithering discussions: I do not know the native display's transfer function. And the user might often not know it, either. So the whole concept won't work.

From where madVR retrieve the display's native gamma curve ?
It doesn't. madVR does not know the display's native gamma curve - except if you switch madVR to "this display is already calibrated". But that's just one situation out of many.

And, if we use "disable calibration controls for this display" [...] the source gamut is used without correction ?
Yes.

[Vyral]

It doesn't. madVR does not know the display's native gamma curve - except if you switch madVR to "this display is already calibrated". But that's just one situation out of many.
[...]
Yes.
Thanks.
Now I think I understand why we use "enable gamma processing" together with "disable calibration controls for this display".
Thanks to this, if you can't/don't calibrate your monitor but you know the display's native gamma (like in my case), you can apply a correction to the source gamut to match with the display's native gamma. Am I right ?

EDIT : No, I'm not. After some testing I can clearly see that the colors are very different when we enable calibration without gamma processing and when we enable gamma processing with "disable calibration controls for this display". Both with the same transfert function and gamma.

[Shiandow]

That's just one small part of what's making this complicated, IMHO.

I'm afraid you're right.


3dluts are another part of the complication. But the biggest part is the same list of problems I already posted several times in the dithering discussions: I do not know the native display's transfer function. And the user might often not know it, either. So the whole concept won't work.

You could just use a default (like BT.1886). But this is all getting horribly complicated. At this point I don't think it makes sense to use the linear light correction when using a 3DLUT (in 8 bits). It think it only makes sense to do it if you use some gamma function to encode the result, or when you're displaying at a lower bitdepth.

But I still have two questions regarding that. Where and how is the gamma correction (if any) applied? And what transfer function does smooth motion use to go to and from linear light?

[scollaco]

I've been reading for awhile and trying to follow as much as I can this discussion. I just started using madVR and it is an amazing piece of software. I recently joined but couldn't post until 5 days of being a member.

Anyways....I had a complete noob question. How do I figure out the native gamma of my projector? I have a Panasonic PT-AE7000 3D projector...and no where in the manual can I find the native gamma. Right now in madVR...I've set "display is calibrated" to pure power curve "2.5" and enable gamma processing checked on with a pure power curve of "2.4". This "Looks" correct to me...but I would really like to know my projector's native gamma...and not have to do all sorts of calibration etc.....

[Shiandow]

Anyways....I had a complete noob question. How do I figure out the native gamma of my projector?

A quick check would probably be to view the images madshi posted a few pages back:


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

Whichever looks closest to the original is the one that uses your projector's gamma curve. Although if you have a gamma higher than 2.4 then you may need to search online for a better gamma check, such as this page (http://www.lagom.nl/lcd-test/gamma_calibration.php).

[markanini]

Do pure power gamma curves really reflect real world display devices better than sRGB or BT.1886 @ 1:1000? Full disclosure I'm a IPS fan but still.

[Qaq]

Whichever looks closest to the original is the one that uses your projector's gamma curve.Thanks a lot. I set my display to RGB 0-255 4:4:4 mode and found "linear (sRGB 2.4)" closest.

[scollaco]

A quick check would probably be to view the images madshi posted a few pages back:



Whichever looks closest to the original is the one that uses your projector's gamma curve. Although if you have a gamma higher than 2.4 then you may need to search online for a better gamma check, such as this page (http://www.lagom.nl/lcd-test/gamma_calibration.php).

Thanks I'll give it a try when I get home. To clarify ( I want to make sure I do this correctly..and I apologize for my total lack of knowledge in understanding how this works).

STEPS:
1) I cycle through the images using some kind of image viewer?. Whichever looks closet to the "original" image is the one that my projector uses.
2) Then with that info...Inside madVR settings...I set "display is calibrated" and then try select the gamma curve that closely matched the original image. Now do I also at the same time, "enable gamma processing" and set it to the same corresponding curve and value? Or do I leave that unchecked? So sorry for being totally clueless with this.

So hypotehtically as an example....if linear (pure power 2.4) was the image closest to the original...I would set madVR settings "display is already calibrated" to pure power 2.4 and then also "enable gamma processing" and set it to pure power 2.4..is that right?

[e-t172]

I do not know the native display's transfer function. And the user might often not know it, either. So the whole concept won't work.

I've said this before, but just as a reminder, ICC profiling is designed *precisely* to solve this very problem. ICC has one job and one job only: to describe the display's response. If madVR supported ICC color management (instead of manual 3DLUTs), this problem would go away entirely. madVR could achieve complete awareness of the display's transfer function.

[truexfan81]

New NVIDIA 335.23 driver released, still cannot use nnedi, just thought i would post an update.

[Shiandow]

STEPS:
1) I cycle through the images using some kind of image viewer?. Whichever looks closet to the "original" image is the one that my projector uses.
2) Then with that info...Inside madVR settings...I set "display is calibrated" and then try select the gamma curve that closely matched the original image. Now do I also at the same time, "enable gamma processing" and set it to the same corresponding curve and value? Or do I leave that unchecked? So sorry for being totally clueless with this.

Step 1 is correct, although beware that those images do not cover all possible cases, but it should give you a general idea nonetheless. In step 2 you don't have to choose the same, you can choose whichever gamma curve you'd like the monitor to have, I think the recommended settings there is pure power gamma, with a gamma of 2.4 (or lower if there's ambient light). But that is a matter of personal taste, so unfortunately there's not a unique correct answer. If your projector already has a pure power gamma curve with a gamma between 2.2 or 2.4, then you may not even need gamma processing.

[scollaco]

Step 1 is correct, although beware that those images do not cover all possible cases, but it should give you a general idea nonetheless. In step 2 you don't have to choose the same, you can choose whichever gamma curve you'd like the monitor to have, I think the recommended settings there is pure power gamma, with a gamma of 2.4 (or lower if there's ambient light). But that is a matter of personal taste, so unfortunately there's not a unique correct answer. If your projector already has a pure power gamma curve with a gamma between 2.2 or 2.4, then you may not even need gamma processing.

Great...that makes sense now to me. I have a really dark bat cave for movie watching so I'll see what looks best or if I need gamma processing at all. Thanks again for all your help!!

[James Freeman]

We're back :)

[scollaco]

Great...that makes sense now to me. I have a really dark bat cave for movie watching so I'll see what looks best or if I need gamma processing at all. Thanks again for all your help!!

Oh so glad we are back...was a bit worried.

Shiandow.. I found this page regarding my projector:

http://www.projectorcentral.com/panasonic_PT-AE7000U_home_theater_projector_review.htm?page=Charts-and-Measurements

It says the default gamma is 2.1. So with this information should I do the following in MadVR?

1) Set "display is calibrated" to on and selected primaries/gamut = BT.709. Choose gamma function to pure power curve and set it to 2.1
2) Then based on my viewing conditions...set "enable gamma processing" to pure power curve 2.4 or whatever looks best for my room lighting?

Is this the correct procedure? I noticed the other choice for gamma function is BT.709/601 when would this be the correct choice instead of pure power curve?

Anyways...sorry for all the novice questions and thanks again for all your help!!

[Shiandow]

1) Set "display is calibrated" to on and selected primaries/gamut = BT.709. Choose gamma function to pure power curve and set it to 2.1
2) Then based on my viewing conditions...set "enable gamma processing" to pure power curve 2.4 or whatever looks best for my room lighting?

Is this the correct procedure? I noticed the other choice for gamma function is BT.709/601 when would this be the correct choice instead of pure power curve?

Anyways...sorry for all the novice questions and thanks again for all your help!!

I think those two steps should give a reasonably good result, but you really need to check so yourself. As far as I can tell a BT. 709/601 gamma curve should be used for recording not displaying. But they should make the dark parts a bit lighter, which might look better in some cases. Anyway, I'd try the two steps you proposed and just experiment a bit. Good luck!

[James Freeman]

Oh so glad we are back...was a bit worried.
Don't worry, it happen here from time to time.

Shiandow.. I found this page regarding my projector:
http://www.projectorcentral.com/panasonic_PT-AE7000U_home_theater_projector_review.htm?page=Charts-and-Measurements

It says the default gamma is 2.1. So with this information should I do the following in MadVR?
Maybe the reviewd projector is 2.1 but yours might be something else...
1) Set "display is calibrated" to on and selected primaries/gamut = BT.709. Choose gamma function to pure power curve and set it to 2.1.
2) Then based on my viewing conditions...set "enable gamma processing" to pure power curve 2.4 or whatever looks best for my room lighting?
Yep

I noticed the other choice for gamma function is BT.709/601 when would this be the correct choice instead of pure power curve?
Absolutely not, it will elevate you blacks sky high.
I wonder what is it still doing in madVR.... madshi?

[Vyral]

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

If this test is correct, my display's gamma curve is BT709. I was using pure power curve until now. Moreover, I know that my display's gamma is 2.25.
Just tested this new settings and the colors seems a little bit brighter. This is barely noticeable on movies but anime seems more colorful. :)

Thanks Shiandow.

[Shiandow]

If this test is correct, my display's gamma curve is BT709. I was using pure power curve until now. Moreover, I know that my display's gamma is 2.25.
Just tested this new settings and the colors seems a little bit brighter. This is barely noticeable on movies but anime seems more colorful. :)
Thanks Shiandow.

Glad that it worked :) but beware that that test doesn't cover all possible cases.

[Ver Greeneyes]

Absolutely not, it will elevate you blacks sky high.It will elevate dark grays and make the difference between dark shades much more apparent as a result, but it shouldn't raise black.

[Vyral]

Glad that it worked :) but beware that that test doesn't cover all possible cases.

Yeah, this is all based on assumptions. I didn't calibrate my monitor so I should probably go with "disable calibration controls for this display" and without "enable gamma processing" to not take any risks.

[scollaco]

Don't worry, it happen here from time to time.


Maybe the reviewd projector is 2.1 but yours might be something else...

Yep


Absolutely not, it will elevate you blacks sky high.
I wonder what is it still doing in madVR.... madshi?

I think those two steps should give a reasonably good result, but you really need to check so yourself. As far as I can tell a BT. 709/601 gamma curve should be used for recording not displaying. But they should make the dark parts a bit lighter, which might look better in some cases. Anyway, I'd try the two steps you proposed and just experiment a bit. Good luck!

Thanks to you both for all the replies. I guess I'll be getting used to the forum going down from time to time :)

James...when you say the reviewed projector was 2.1 but mine might be different...aren't all projectors out of the factory calibrated the same? Or is there always some differences in gamma?

I recently was watching "Out of Furnace" on BD and noticed in SOME scenes the blacks looks a bit washed out....that got me wondering if that was deliberate or if my gamma was wrongly set. I've become really sensitive now to black levels. What gets me peeved even more is when I play a bluray and theblacks are so washed out..like it was a mistake in the factory and the movie was mastered at 32 instead of 16 for black point. Thank God for madVR's amazing input source level I can easily set it to double expanded and all is right with the world again :)

Anyways...when I get home I will give those two steps I outlined a try and see what everything looks like.

[leeperry]

Well, at this point I don't want to add this. The settings are not set in stone yet.
OK no sweat, I'll keep using that option with a reminder that I'll have uncheck it once the movie's over. Profiles would not help but fair enough, I guess it's not really the job of the VR to enable inverse PAL speed-up and I can't be hassled to mess with the pesky .vbs script of Reclock as 25@24 cannot be automatically detected anyway.

If I had simply ignored the whole linear light topic, we would have stopped at v0.87.6, and every one of you guys would still have been happy, isn't that right? Now the next build will give you even more quality than v0.87.6, but suddenly you're unhappy?
This has been true for every mVR build. We'd all be SOL & stuck with EVR or PotP's D3D surface renderers.....you have totally nailed down this niche market by now, the competition lags far behind and because you still refuse to take our money, we can only be most grateful and thankful for your unmatched expertise and the utmost privilege of standing on the bleeding edge of video rendering.

I know mVR's ED has been the icing on the cake for me and I'm looking forward to putting LL to good use as I can definitely tell that the picture looks "smoother"...I rest my case that GL's gamma errors come with artificial looking EE to my eyes when using mono-static A4, to the point that now that I've gotten the hang of LL it's become uneasy to look at.

Surely that EE comes in handy with anime but I hardly ever watch anime.

I presume that the final LL build might yield different/better results so I'm really looking foward to trying it :)

[scollaco]

If this test is correct, my display's gamma curve is BT709. I was using pure power curve until now. Moreover, I know that my display's gamma is 2.25.
Just tested this new settings and the colors seems a little bit brighter. This is barely noticeable on movies but anime seems more colorful. :)

Thanks Shiandow.

When I get home, I'll test comparing the images myself to see if I can figure out my display's native gamma.

Vyral...so I understand what change you made.....based on the image tests, your display's gamma curve is BT709...so does that mean In the "calibration" section you switched your gamma function from pure power to BT709/601? I thought James & Shiandow mentioned that shouldn't be used..correct? Or is there some other choice I'm not getting?

This is what I see:
In the calibration section:
For gamut primaries I see: BT709 (default), SMPTE etc... ec...
For gamma function I see : pure power(default) and BT709/601

In the gamma processing section:
I see a choice to enable gamma processing and choose either pure power (dafault) or BT709/601.

Which ones did you choose for YOUR display? Thanks

[huhn]

Yeah, this is all based on assumptions. I didn't calibrate my monitor so I should probably go with "disable calibration controls for this display" and without "enable gamma processing" to not take any risks.

you can change the gamma, what could happen? just use the gamma you like more. gamma should be choiced on lightning condions so do as you please.

[6233638]

On a completely different subject, might it be possible to increase the number of backbuffers in Windowed mode beyond 8?
They are some things on my PC which seem to "reset" the present/backbuffer queues (or drop a lot) and in FSE mode with 16 frames presented in advance it drops down to 1-15/16 or 0-15/16 but never seems to actually drop frames so playback remains smooth.
In Windowed mode where the limit is 8, this causes it to drop/repeat frames.

Going above 16 in FSE mode might be nice too.

[James Freeman]

In the gamma processing section:
I see a choice to enable gamma processing and choose either pure power (dafault) or BT709/601.


scollaco, Just to make it clearer;
Desired gamma is just it, what you want the picture to look like.
BT.709 is not an output curve for displays, Its an encoding gamma for the camera and should not be used for display in any case.


Here's how it works:

When a camera sensor is capturing light, it is captured linearly (light photons filling photosites in the sensor), your eyes see light in the same way.
But in the old days CRT had a natural gamma of 2.2, its just how the electron gun behaves.
Now days we have LCD which is Linear by nature (transistors) but calibrated to a gamma curve too emulate CRT behavior.

What image do you get when a linear (1.0) gamma image from the camera displayed on a 2.2 gamma screen (pulled down)?... A very dark image.
What do you do to fix it?... You encode the original image (from the camera) with the inverted gamma of the screen = 1/2.2 (brighten it).
Now what happens when you play the inverted gamma image on the same screen (one pulls up one pulls down)?.... You get back your Linear image which is what the camera captured and your eyes see.

So why today we encode the camera gamma with a Rec.709 and not the 1/2.2 like in the old days even if we still calibrate the display to 2.2?... To make the first few black steps darker.
How so?... The first few steps in the BT.709 curve are Linear (1.0 gamma), so that when your display "pulls down" the the image, its a little darker in the blacks compared to if the camera encoded with 1/2.2 gamma.
Why?... To hide the digital camera sensor noise in the blacks area which is strong compared to if it was captured on celluloid, nothing less nothing more.

Why not just leave the RAW camera gamma of 1.0 and the native LCD behavior also 1.0?..... Beats me, there will be no banding issues at all because there is no need to calibrate the LCD.
I guess old habits are hard to change.

Good Article: Here (http://www.wildlifeinpixels.net/blog/gamma-encoding/)
A better one: Here (http://www.cambridgeincolour.com/tutorials/gamma-correction.htm)

[scollaco]

scollaco, Just to make it clearer;
Desired gamma is just it, what you want the picture to look like.
BT.709 is not an output curve for displays, Its an encoding gamma for the camera and should not be used for display in any case.


Here's how it works:

When a camera sensor is capturing light, it is captured linearly (light photons filling photosites in the sensor), your eyes see light in the same way.
But in the old days CRT had a natural gamma of 2.2, its just how the electron gun behaves.
Now days we have LCD which is Linear by nature (transistors) but calibrated to a gamma curve too emulate CRT behavior.

What image do you get when a linear (1.0) gamma image from the camera displayed on a 2.2 gamma screen (pulled down)?... A very dark image.
What do you do to fix it?... You encode the original image (from the camera) with the inverted gamma of the screen = 1/2.2 (brighten it).
Now what happens when you play the inverted gamma image on the same screen (one pulls up one pulls down)?.... You get back your Linear image which is what the camera captured and your eyes see.

So why today we encode the camera gamma with a Rec.709 and not the 1/2.2 like in the old days even if we still calibrate the display to 2.2?... To make the first few black steps darker.
How so?... The first few steps in the BT.709 curve are Linear (1.0 gamma), so that when your display "pulls down" the the image, its a little darker in the blacks compared to if the camera encoded with 1/2.2 gamma.
Why?... To hide the digital camera sensor noise in the blacks area which is strong compared to if it was captured on celluloid, nothing less nothing more.

Good Article: Here (http://www.wildlifeinpixels.net/blog/gamma-encoding/)

Thanks for the explanation. I will read the article to get a better understanding...as I feel my eyes have opened to a whole new world. Before this I just thought of things in terms of brightness and contrast and gamma was something I never really thought about.

So when Vyral said that his display's gamma curve is BT709 and he was using pure power curve before...he changed it from "pure power" to "BT709/601" in the calibration section to get the desired gamma for his display? Would he then enable gamma processing also and set it to "BT709/601?" instead of "pure power"

I guess when I get a chance to compare images at home...I'll have a better idea of my projector's native gamma. I'll report back what image looked closest to the original.

[James Freeman]

So when Vyral said that his display's gamma curve is BT709 and he was using pure power curve before...he changed it from "pure power" to "BT709/601" in the calibration section to get the desired gamma for his display?
Would he then enable gamma processing also and set it to "BT709/601?" instead of "pure power"


No,

The "calibrated to" is to tell madVR what your display is calibrated to, for its calculations.
The "desired gamma" is what you wand to see, after madVR does the calculations according to the "calibrated to" you've selected.

No display should ever be calibrated to BT.709 gamma curve.
Many displays are over-compensating (brighten) the black area so that they may look like BT.709 but its a mistake, no display is actually calibrated to BT.709 at the factory.
The BT.709 in the "desired gamma" & "calibrated to" sections should technically not be there at all for gamma, only for color.

[scollaco]

No,

The "calibrated to" is to tell madVR what your display is calibrated to, for its calculations.
The "desired gamma" is what you wand to see, after madVR does the calculations according to the "calibrated to" you've selected.

No display should ever be calibrated to BT.709 gamma curve.
Many displays are over-compensating (brighten) the black area so that they may look like BT.709 but its a mistake, no display is actually calibrated to BT.709 at the factory.
The BT.709 in the "desired gamma" & "calibrated to" sections should technically not be there at all for gamma, only for color.

So "calibrated to" and "desired gamma" should both be at "pure power" NOT "BT.709/601". I guess that is why you asked Madshi why that was still needed in there and if it could be removed.

My other point of confusion then is in the "calibrated to" section...for "display is calibrated to the following primaries/gamut" we select BT.709 as default...what are those other options like SMTPE etc..(I can't remember all the other names) when do we use those?

[James Freeman]

So "calibrated to" and "desired gamma" should both be at "pure power" NOT "BT.709/601".
I guess that is why you asked Madshi why that was still needed in there and if it could be removed.
Not for gamma, only for color.
but I guess madshi has his own reasons, or maybe there are users who actually calibrate to BT.709 and like the extremely elevated shadows and noise?

My other point of confusion then is in the "calibrated to" section...for "display is calibrated to the following primaries/gamut" we select BT.709 as default...what are those other options like SMTPE etc..(I can't remember all the other names) when do we use those?

Its the color gamut/amount/volume/coordinates your display can actually show compared to the volume of color your eyes can see.

BT.709 is not only a camera gamma curve, its primarily a color space.
Most likely than not 99% of LCD displays on the market have BT.709 primaries (RGB coordinates) unless you are a professional colorist (in which you would probably know this ;)).

Sorry for the big pic:
*Note that not a single UHDTV covers the rec.2020 gamut and probably never will...
http://dotcolordotcom.files.wordpress.com/2012/12/rec2020-vs-rec709-001.png