madVR - high quality video renderer (GPU assisted)

[huhn]

you use these for displays that are calibrated for that. there are very few displays calibrated to the rest.

maybe in the future bt 2020 is the new standard but today tvs should be bt709 and monitors srgb. and if i'm not miss informed madvr uses srgb when nothing is choiced.
for an old crt >TV< smpte-c or ebu/pal is the right choice by the way they are very close to bt 601. that's why madvr treats 480p videos as bt601 when no informations are provided.

[6233638]

But in the old days CRT had a natural gamma of 2.2, its just how the electron gun behaves.2.4Why 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.LCD displays are not linear - they naturally have an S-curve gamma.

[scollaco]

Nice explanations (James, huhn). I'm learning a lot. I never saw sRGB anywhere in the settings...so it must make sense that it get's used if no choices are selected?

I can't wait to get home and compare the avatar images on my projector, to hopefully get an idea about my display's native gamma. Will report my findings. Thanks for all the education.

Coming to the forum..I thought how I have such a lack of knowledge in this area compared to you experts....and was intimidated to write...but you guys have been really welcoming and generous with your knowledge.

Also wanted to say a big thanks to Madshi for making this incredible renderer!

[James Freeman]

2.4
Yes, but to simplify the exaple I went for 2.2.


LCD displays are not linear - they naturally have an S-curve gamma.
Thanks.
So to tweak the behavior (gamma) of the transistor that moves the liquid polarizer crystal we need an internal LUT.
To reach this internal hardware LUT to get bandless calibration we need more $ :D.

compared to you experts
Hardly... I'm a liar... that tells the truth...

[XMonarchY]

Could someone explain to me what Rec.709 gamma is? AFAIK Rec.709 does not specify a gamma, only chromaticities (primary & secondary colors), but I am not an expert? Are you saying that Rec.709 gamma = BT.1886 gamma?

I think this topic has already been over-discussed on AVS forums and it makes far more sense to use BT.1886 gamma over any other type of gamma for several reasons, which I am sure everyone already knows about, but I just wanted to recap what it is all about:

-By using power-law gamma, you are only making it better for those who have top-end TVs with very low black levels. Hell, even my Eizo Foris FG2421 with 0.02 cd/m^2 black level @ 100 cd/m^2 white point comes pre-calibrated with BT.1886-like gamma tone in the darkest gray levels, but instead of gradually going up to 2.3/2.4 @ 100% IRE, it stays at 2.2. I think its either a hybrid of BT.1886 & power-law or its BT.1886 2.2 instead of the default 2.4.
-Many IPS and TN monitors with low contrast ratio and very high black levels will have completely crushed black levels when used with power-law 2.2 gamma... The famous G-Sync VG248QE monitor is a good example - it will have levels 1 and 2 crushed if used with power-law 2.2 gamma.
-Not all TVs today target 2.2 power-law either. One of recent Sony SPVA's panels targets power-law 2.4 gamma tone.
-Not all content is mastered to power-law 2.2 gamma - we don't actually know what content was mastered with any gamma! But what we do know is that reference-level TVs used to master films have much deeper black levels than most consumer TVs. You can have a film mastered with power-law 2.2 gamma on a reference TV with excellent blacks, but it will not look the same on a consumer TV calibrated to the same power-law 2.2 gamma.
-BT.1886 is a perfect compromise to fit all possible gamma types as it increases/decreases each gray level by visually, the same exact amount. Power-law gamma lumps low black levels, which results in poor black detail.
-On TVs with excellent black levels, BT.1886 gamma approaches power-law 2.4 curve, so there is no loss there either! I use BT.1886 on each and every display I own and calibrate - the end result is always awesome.
-Content that doesn't look good with BT.1886 gamma due to "washed out" blacks also doesn't look good with power-law gamma simply because some mastering sucks and instead of using the lowest black level 0, higher black levels are used instead. Power-law gamma does make such content look better, by making it less washed out, but less washed out is still washed out! Anyone seen The Thing 2011? It was horrifically mastered. Whether you use BT.1886 or power-law 2.2 (or even 2.4!) gamma, that film just doesn't use black level 0 and all blacks in it end up washed out, just to a different degree.

In conclusion, using gamma other than BT.1886 will make the image very inaccurate for those who do not use that type of gamma. But BT.1886 is a compromise that works for ALL other types of gamma calibration and content.

But I guess the question is - would BT.1886 gamma look best for dithering on displays that are calibrated to other gamma types? I think it so! I re-calibrated my monitor to power-law 2.2, but Rec.709 2.4 still looked the best, assuming that Rec.709 2.4 IS BT.1886 2.4.

The only other type that makes sense is simply linear. Linear will completely depend on the calibration performed for that device. I think that is HOW it should stay TBH, even though I prefer BT.1886 gamma. madVR should make it up to the display device to decide what gamma is to be used. Its either LINEAR or BT.1886.

Consider that BT.1886 gamma is the only gamma that can be applied to ArgyllCMS 3DLUTs for madVR without deep hex editing, it may make sense to leave gamma as linear for those who use 3DLUTs! AFAIK the only other 3DLUT generating program for madVR is SpectraCal CalMAN v5 Ultimate Business Edition, something very few have and I am not even sure it allows the creation of 3DLUTs with power law 2.2/2.4 gamma.

[Shiandow]

Could someone explain to me what Rec.709 gamma is? AFAIK Rec.709 does not specify a gamma, only chromaticities (primary & secondary colors), but I am not an expert? Are you saying that Rec.709 gamma = BT.1886 gamma?

As far as I can tell Rec.709 does define a gamma curve but only the one that was used to encode the input, it doesn't actually specify how it should be displayed. It seems that in practice it is implicitly assumed that you use a BT.1886 calibrated monitor to view it. Unfortunately I have no way of knowing for sure.

[James Freeman]

@XMonarchY
Not to be hard, but your post is a big NO.

BT.1886 is not a gamma curve, its an algorithm/formula that creates a gamma curve based on your display measurements to emulate a CRT without crushing the blacks.
No LCD can do a perfect 2.2 power curve without crushing the blacks, that's why they all are Black-Compensated to some extent.

Forget about BT.709 for display gamma, its probably an overcompensated (black-offset) display not properly calibrated.
ITU BT.709 CLEARLY states that its transfer characteristics are for Opto-electronic conversion ie: CAMERA.

[leeperry]

it makes far more sense to use BT.1886 gamma over any other type of gamma.
BT.1886 is highly dependent on the native CR of a display so I really don't understand how it could ever become a "one-size-fits-all" standard in mVR that would equally please on 5K:1 Plasma, inifinite native CR CRT or 1K:1 LCD, without filling any display-related info whatsoever at least...but I'm sure madshi will/already has straighten things out :p

[James Freeman]

As far as I can tell Rec.709 does define a gamma curve but only the one that was used to encode the input, it doesn't actually specify how it should be displayed. It seems that in practice it is implicitly assumed that you use a BT.1886 calibrated monitor to view it. Unfortunately I have no way of knowing for sure.

ITU BT.709 approved in 2002: Here (http://www.itu.int/rec/R-REC-BT.709-5-200204-I/en)
ITU BT.1886 approved in 2011: Here (http://www.itu.int/rec/R-REC-BT.1886-0-201103-I)

So no, there was no standard for display gamma.
But the most common was Black-Compensated 2.2/2.4 power curve.

BT.1886 is quite new, and I'm almost sure mastering is done on a proper OLED Pure Power 2.4 Broadcast/Mastering Monitor.
Personally after calibrating to BT.1886 with Argyll, its was (800:1 Dell U2410) too bright for my taste.
Maybe now with 2500:1 it should do better? I may try.

The purpose of BT.1886 is to not crush blacks AND to reach 2.4 power curve gamma, which is a "laughable nice try" for low CR displays.
On a low contrast ratio display to maximize every drop of black you have its better to stick with black compensated 2.2/2.4 curve.

[soulkeeper]

how is the native gamma of my pj related to the different gamma settings in pj's menu?
according to various reviews for the benq w1070 ,2.4 setting measures an average of about 2.3 and 2.2 setting averages to 2.1...

[Vyral]

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

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.

Just did some more test and I can't see any difference whether I choose "this display is already calibrated" with BT709, BT709/601 and 2.25, with BT709, pure power curve and 2.25 or "disable calibration controls for this display".
I thought I saw something yesterday when I changed to BT709/601 2.25 instead of "disable calibration" but it was probably a placebo effect.
I see no difference either with "enable gamma processing" pure power curve 2.25. However, if I choose BT709/601 2.25, the image is clearly darker.
Therefore, I came back to my previous setting : "this display is already calibrated" and I disabled gamma processing.

[James Freeman]

@Vyral
I quote myself because I've already answered that:
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.
When you select BT.709 in the "calibrated to" section you will see no difference till you also switch "desired gamma" to something.
When these options are the same, there is not difference at all.

When you select BT.709 in the "calibrated to" and select Power 2.2 in "desired gamma" you probably massively crush the blacks, UNLESS your screen is actually calibrated to BT.709.
That's why I said a million times the what you see is probably an overcompensated power curve and NOT a true BT.709 (which is no surprise unless the display manufacturer is really stupid).

[Werewolfy]

Well, the problem is that Direct3D itself changes the display mode to an incorrect value. I've hooked into that and modified Direct3D's display mode change to request the correct refresh rate. That doesn't seem to work on your PC. So maybe it would make sense to use the following API monitor to find out which API Direct3D is using on your PC to switch to the wrong refresh rate:

http://www.rohitab.com/apimonitor

If you can tell me that, maybe I can find a fix/hook that works for you, too. I'm not sure if this API monitor hooks all the display mode change APIs, though. For example, on my PC Direct3D directly calls the GPU user mode driver to change the display mode. I kinda doubt the API monitor hooks/shows such API calls. But you could give it a try, maybe we get lucky...

I tried apimonitor, I hope I have what you need, it's the first time I use this software. I only checked "Audio and Video" and "Graphics and Gaming", here are the results. I included capture file and the same content in text files in case you can't read the capture file (like I said I don't know this software).

https://www.mediafire.com/?25ploj5619ohh50

[Asmodian]

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?

To be honest I think most of us would be happy if you used any non-linear function (or even gamma light). We are just talking "ideals" as far as we understand it. :)

Besides what if I want to watch Avatar in 2-bit? :p

[scollaco]

Just did some more test and I can't see any difference whether I choose "this display is already calibrated" with BT709, BT709/601 and 2.25, with BT709, pure power curve and 2.25 or "disable calibration controls for this display".
I thought I saw something yesterday when I changed to BT709/601 2.25 instead of "disable calibration" but it was probably a placebo effect.
I see no difference either with "enable gamma processing" pure power curve 2.25. However, if I choose BT709/601 2.25, the image is clearly darker.
Therefore, I came back to my previous setting : "this display is already calibrated" and I disabled gamma processing.

Good to know....so I'm assuming if you disable gamma processing...then all you are doing is telling madVR what your display is calibrated (In your case - BT709, pure power 2.25) and then madVR will process the source movie and output at the those calibrated gamma settings...My understanding is that enable gamma processing is to tweak the gamma to a desired level for viewing whether that be 2.2, 2.4 etc....based on viewing conditions (ambient light, dark theater etc...)....is my assumption correct?

EDIT: Just read James reply as well. I can also attest to the fact that when I used BT.709/601 instead of pure power in the "calibrated to" but kept the "desired gamma" to pure power I got crushed blacks. So when I get home I will be using pure power for both "calibrated to" and "desired gamma". Now I only need to figure out what number to use in "calibrated to" (2.1, 2.2 etc...). Will do that by comparing the avtar images.

[XMonarchY]

Please explain how any gamma other than BT.1886 fits all better than BT.1886. Any other type of gamma would only fit those who have the display calibrated to it, but would be completely worthless to others. BT.1886 may not please some people, but its still the best compromise outside of linear.

If you pick power-law gamma 2.2 instead of BT.1886, then you automatically exclude all monitors with low CR as they would have crushed blacks... how is that better than using BT.1886? If low CR doesn't live up to your standards - sucks to be you then, but there is no reason to exclude low CR displays, especially ones famous for being G-Sync-capable.

[iSunrise]

FYI, the Eizo CGs actually use a REC709 (it's specifically named like that, neither BT.709, nor BT.1886) hardware LUT preset in the options, which is factory calibrated manually with each monitor. When I use the gamma calibration test image to figure out it's gamma (it's not shown in the Gamma selection, it just says "Default", which normally means that it's set according to the standard), it's somewhere between 2.0 and 2.1. It also has elevated black levels.

That probably means that, since the Eizo is incapable of displaying the blacks levels, they need to elevate them to make them actually visible.

When I use madVR, I can perfectly correct that by using a "BT.709/601 curve" and gamma "2.00" as input and "pure power curve" and gamma "2.35" or "2.40" as output.

What I get in return is a very accurate image that shows all shadow details (it actually sometimes shows too much, since I can see some encoding noise or noise in black areas, which I'm not sure of they are supposed to be seen).

All other modes, apart from sRGB (which display all 0-255 levels perfectly fine), crush blacks to some extend.

[XMonarchY]

FYI, the Eizo CGs actually use a REC709 (it's specifically named like that, neither BT.709, nor BT.1886) hardware LUT preset in the options, which is factory calibrated manually with each monitor. When I use the gamma calibration test image to figure out it's gamma (it's not shown in the Gamma selection, it just says "Default", which means it's set according to the standard), it's somewhere between 2.0 and 2.1. It also has elevated black levels.

That probably means that, since the Eizo is incapable of displaying the blacks levels, they need to elevate them to make them actually visible.

When I use madVR, I can perfectly correct that by using a "BT.709/601 curve" and gamma "2.00" as input and "pure power curve" and gamma "2.35" or "2.40" as output.

What I get in return is a very accurate image that shows all shadow details (it actually sometimes shows too much, since I can see some encoding noise or noise in black areas, which I'm not sure of they are supposed to be seen).

Were you referring to me? I can make my Eizo have power law 2.4 and all is perfectly visible. Its a 5000:1 CR monitor - I have no idea what you are talking about...

[*Touche*]

Please explain how any gamma other than BT.1886 fits all better than BT.1886. Any other type of gamma would only fit those who have the display calibrated to it, but would be completely worthless to others. BT.1886 may not please some people, but its still the best compromise outside of linear.

If you pick power-law gamma 2.2 instead of BT.1886, then you automatically exclude all monitors with low CR as they would have crushed blacks... how is that better than using BT.1886? If low CR doesn't live up to your standards - sucks to be you then, but there is no reason to exclude low CR displays, especially ones famous for being G-Sync-capable.

Because when you calibrate to BT.1886, you get a different curve depending on your display's characteristics. It is not a uniquely defined gamma curve.



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.


I don't think that is a correct explanation. Our eyes don't see light the same way a camera captures it linearly. It is precisely that difference that gamma endcoding/decoding was introduced for. Our eyes are more sensitive to dark tones and camera sensor used too much data for bright ones and too little for dark ones. That is why its captured data is gamma encoded, to redistribute the tonal distribution to mimic our sight, and then the displays use a 2.2/2.4 gamma to invert it back.

[iSunrise]

Were you referring to me? I can make my Eizo have power law 2.4 and all is perfectly visible. Its a 5000:1 CR monitor - I have no idea what you are talking about...
If I were specifically addressing you I would have quoted you. I was just adding that to the discussion.

It's an H-IPS panel with theoretically native 1000:1 CR, but due to calibration lowers that to a usable 700:1/800:1.

But since you quoted me now:
Your AMVA panel has a WAY higher CR, so that's expected.

[Eiffel]

I've noticed that in the latest versions of madVR/madTPG it is no longer possible to enable both VideoLUTs and 3dlut calibrations at the same time, which I thought would be helpful to test the result of a 3dLut on top of GPU gamma ramps.

Is there a reason why this option is no longer offered? -- It's possible to fool madTPG into the right VideoLUTs setting by running an 3rd party application such as Calibration Tester to reset the gamma curve and DisplayProfile to load a gamma curve, but this is not very elegant and I'm wondering if I'm missing something.:confused:

Separately, as I've noticed that on a dual display system, Windows gets confused with loading the right ICC/gamma ramps for a given display (when switching between two calibrated displays, etc.), is generating a 3dlut via madTPG with both VideoLUTs and 3dlut disabled and setting madVR to disable GPU gamma ramps the right approach, or is there a better solution?

[zoyd]

Because when you calibrate to BT.1886, you get a different curve depending on your display's characteristics. It is not a uniquely defined gamma curve.




I don't think that is a correct explanation. Our eyes don't see light the same way a camera captures it linearly. It is precisely that difference that gamma endcoding/decoding was introduced for. Our eyes are more sensitive to dark tones and camera sensor used too much data for bright ones and too little for dark ones. That is why its captured data is gamma encoded, to redistribute the tonal distribution to mimic our sight, and then the displays use a 2.2/2.4 gamma to invert it back.

Exactly, inverse power law encoding was introduced as a type of perceptually efficient compression. It was just a fluke that CRTs have a natural response that inverts it.

Gamma FAQ (http://www.poynton.com/notes/color/GammaFQA.html)


The main purpose of gamma correction in video, desktop graphics, prepress, JPEG, and MPEG is to code light power into a perceptually-uniform domain, so as to obtain the best perceptual performance from a limited number of bits in each of the R, G, and B (or C, M, Y, and K) components.

[seiyafan]

Why is L* inferior to 2.2 or sRBG gamma in watching movies?

[scollaco]

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

Originally Posted by madshi View Post
|- 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).

So after comparing the images it looks like sRGB was the closest match to the original for me. Power curve 2.2 being the next closest. I did output my nvidia card to PC (0-255) and my display is also set to accept full RGB levels.

So now that sRGB seemed to be the closest match...what do I put in the "calibrated to" and "desired gamma" settings?

[Asmodian]

I've noticed that in the latest versions of madVR/madTPG it is no longer possible to enable both VideoLUTs and 3dlut calibrations at the same time, which I thought would be helpful to test the result of a 3dLut on top of GPU gamma ramps.

Is there a reason why this option is no longer offered? -- It's possible to fool madTPG into the right VideoLUTs setting by running an 3rd party application such as Calibration Tester to reset the gamma curve and DisplayProfile to load a gamma curve, but this is not very elegant and I'm wondering if I'm missing something.:confused:

Separately, as I've noticed that on a dual display system, Windows gets confused with loading the right ICC/gamma ramps for a given display (when switching between two calibrated displays, etc.), is generating a 3dlut via madTPG with both VideoLUTs and 3dlut disabled and setting madVR to disable GPU gamma ramps the right approach, or is there a better solution?

In my experience madTPG sets itself to the right settings automatically when used with Argyllcms. It turns off VideoLUTs for calibration but turns them on again if you run a dispread with "-k monitor.cal". If you have a 3DLUT with linear GPU ramps attached it will disable the VideoLUT, as it should. Do you have overlay enabled? ATI, Nvidia, or Intel?

I haven't noticed any issues with Windows getting my icc profiles confused.

[James Freeman]

I don't think that is a correct explanation. Our eyes don't see light the same way a camera captures it linearly. It is precisely that difference that gamma endcoding/decoding was introduced for.
Our eyes are more sensitive to dark tones and camera sensor used too much data for bright ones and too little for dark ones.
That is why its captured data is gamma encoded, to redistribute the tonal distribution to mimic our sight, and then the displays use a 2.2/2.4 gamma to invert it back.
Exactly, inverse power law encoding was introduced as a type of perceptually efficient compression. It was just a fluke that CRTs have a natural response that inverts it.

You want to tell me that engineers back then wanted us to see an inverse power curve with a low CR display, BEFORE knowing that CRT will pull it back down to flat?
I think not.

Human eye sees light in an inverse power factor curve across ALL the light range we can perceive, a CR of about 1,000,000:1.
When we are in the dark our pupil dilates and lets more light in, when we are in a bright sun our pupil contracts and let less light in.
But when the pupil is fixed we only see about 600:1 (some say 100:1) CR in Linear manner, That's why the resulting "flat" image of the summed encoding & decoding curves look natural to us.

If a camera would be able to perfectly capture 20-F Stops (1,000,000:1), and a TV would have real 1,000,000:1 CR, from retina scorching bright to bat cave dark.
Then too, the correct way would be Linear Encoding -> Linear Decoding. Your pupil will control the amount of light that gets in, just like in reality.
And if the sun gets too bright in your future 1,000,000:1 CR TV, you can always cover it with you hand to see the shadows better (or put your sunglasses on). :D

You can't emulate a 1,000,000:1 eye curve, in a 1000:1 image. That will look very bright, and a wrong thing to do in the first place.

[Audionut]

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

I'm not 100% sure of how the eyes "see" the data.

But certainly, we perceive the data on a logarithmic scale.
http://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law

This is why we map the linear data, we need to make it logarithmic to better fit in with our perceptions of the world.

I really don't understand your description of taking linear data, and mapping it various ways to simply output that data in the same linear scale.

You can't emulate a 1,000,000:1 eye curve, in a 1000:1 image. That will look very bright, and a wrong thing to do in the first place.

You map the white points, and apply a logarithmic scale on the rest of the data.

There is no "very bright". The top of the 1,000,000:1 ratio may be at 10 lumens. Or 100 lumens, or whatever.

This is the benefit of BT.1886. It doesn't imply a fixed black or white point. It maps the data within the black/white points of the display, so that the output from the display device is perceptually accurate.

[Vyral]

@Vyral
I quote myself because I've already answered that:

When you select BT.709 in the "calibrated to" section you will see no difference till you also switch "desired gamma" to something.
When these options are the same, there is not difference at all.

When you select BT.709 in the "calibrated to" and select Power 2.2 in "desired gamma" you probably massively crush the blacks, UNLESS your screen is actually calibrated to BT.709.
That's why I said a million times the what you see is probably an overcompensated power curve and NOT a true BT.709 (which is no surprise unless the display manufacturer is really stupid).

Right now, my settings are "this display is already calibrated" and I disabled gamma processing (no "desired gamma"). Which means the source gamut is used without correction.
Those settings should be a safe bet if the display is not calibrated, right ?
According to you, in the "calibrated to" settings, we should always use pure power curve with the correct gamma (2.25 in my case) for gamma function and never use BT709 UNLESS the display is actually calibrated to BT.709 because it can massively crush the blacks.
But what about the gamut primaries ?

[James Freeman]

So after comparing the images it looks like sRGB was the closest match to the original for me. Power curve 2.2 being the next closest. I did output my nvidia card to PC (0-255) and my display is also set to accept full RGB levels.

So now that sRGB seemed to be the closest match...what do I put in the "calibrated to" and "desired gamma" settings?

Download this file: Black Clipping (http://www.mediafire.com/watch/48jdp2v53d43a05/1-Black_Clipping.mp4)

Make sure you see step 17 and up.
Step 17 should be barely visible, 16 is pure black.

[James Freeman]

This is why we map the linear data, we need to make it logarithmic to better fit in with our perceptions of the world.

I really don't understand your description of taking linear data, and mapping it various ways to simply output that data in the same linear scale.

I think you're wrong.
We do not map linear light from a camera to inverse log to match our vision, we map it because the display pulls it back down.

Yes, I understand that CR is subjective to luminance.
By "very bright" I mean blinding Sunlight, and very dark is moonless night (starlight) in which you can barely see.

The whole human vision dynamic range (about 1,000,000:1 or more) equates to a inverse power function (sunlight to starlight).
When you draw a line between two points that equals to 1000 out of that 1,000,000 curve (a Differential), the line is tangent the curve, hence almost linear... Hope you can see that.

Again:
That's why we do not map linear light from a camera to inverse log to match our vision, we map it because the display pulls it back down.

[Audionut]

Ok. So how does the system map the linear data from the capture device, to logarithmic for human consumption?

Also, you said that you can't emulate 1,000,000:1 in 1000:1. This is plain wrong.
http://en.wikipedia.org/wiki/High-dynamic-range_imaging

[James Freeman]

Ok. So how does the system map the linear data from the capture device, to logarithmic for human consumption?

Again, Its not about human consumption, Its about the display Gamma curve.
A typical image that the a camera captures is around 10 F-Stops (2^10 = 1024:1 CR), pretty close to what a human eye can see with the pupil (shutter) in a single position.
As I explained in the previous post, 1000 out of 1000000 curve is almost flat (a simple differential).
That's why its about the display and not about human vision, because the camera/display capture/show a small flat region of the whole spectrum we can actually see.
The curve we apply and then de-apply is technological limitation we still carry from the old days, which we don't have to anymore.

What you don't understand?


Also, you said that you can't emulate 1,000,000:1 in 1000:1. This is plain wrong.
http://en.wikipedia.org/wiki/High-dynamic-range_imaging

Yes, HDR is a nice trick and work of art, but that does not make me wrong.
No eye/camera/display has the CR range of sunlight to starlight in a single picture, end of story.

Look at an HDR picture and ask yourself, is that how reality looks like?
Its pretty, but definitely not.

[Audionut]

Again, Its not about human consumption, Its about the display Gamma curve.

Indeed. My apologies for the slow uptake.



Yes, HDR is a nice trick and work of art, but that does not make me wrong.

On the contrary, that's exactly how you are wrong.

You can't emulate a 1,000,000:1 eye curve, in a 1000:1 image.

You can indeed emulate it. ;)

Look at an HDR picture and ask yourself, is that how reality looks like?
Its pretty, but definitely not.

Besides the fact, that how pretty it looks has no bearing on actual facts, it can or it can't. HDR, by definition, is a capture that contains a DR above that of the capture system. Now, since it became a fad, indeed, typical HDR results were silly.
An HDR image that maps the data in a perceptual manner, will indeed look very close to reality.

If you want to lump all HDR, into the POP EFFECT, then sure, that's not how it really looks like.

Consider these 2 images.
https://dl.dropboxusercontent.com/u/34113196/defaultt.jpg
https://dl.dropboxusercontent.com/u/34113196/_46A3583.jpg

1 is a capture without any post tone mapping. By definition, this image contains a DR in excess of the capture system*. The second image, is post processed with a perceptual rendering. I wasn't aiming for a pop effect ;)

*https://bitbucket.org/hudson/magic-lantern/src/3217458a7dbe585d1899e2cf6e2b0cc97d6fa7a5/modules/dual_iso/?at=unified

[James Freeman]

You can indeed emulate it. ;)

OK then,
The emulation is not perfect, but its sure pretty... :eek:

An HDR image that maps the data in a perceptual manner, will indeed look very close to reality.
Actually, we don't need more that 1000:1 to emulate reality in a single instant, therefor we don't need HDR.
A standard modern camera can capture all the range (F-Stops) your eyes can see and more in a "no light change" situation.

[Audionut]

OK then,
The emulation is not perfect, but its sure pretty... :eek:

Check my edit above. It doesn't always have to have that spastic look.


Actually, we don't need more that 1000:1 to emulate reality in a single instant, therefor we don't need HDR.
A standard modern camera can capture all the range (F-Stops) your eyes can see and more in a "no light change" situation.

On the display side, if 1000:1 is all that is needed, then that's fine. But you may want to capture more then 1000:1 of actual detail.

I personally, would prefer compressed highlights, with detail, rather then pure white, on some attempt to limit ourselves to reality.
I think you are limiting your understanding on HDR, based on few examples that rendered for the pop effect. ??

[James Freeman]

@Audionut

If HDR is used properly ie: enhance certain picture elements that you think you remember how the actual scene was, or should have looked like,
we should definitely use HDR for that, even though it does not perfectly reflect reality in a single instance.

A memory of a scene can be very different from what a camera (or eye) can capture in a single instance, because you moved from place to place (shade to sunlight) and your eyes compensated for that, then your mind formulated a memory of that place.
If you truly want to capture that experience and memory in a single shot, there is no other way but HDR.

[zoyd]

You want to tell me that engineers back then wanted us to see an inverse power curve with a low CR display, BEFORE knowing that CRT will pull it back down to flat?
I think not.


Your assumptions are simplistic, engineers of the time did understand the importance of non-linear encoding. see here (http://onlinelibrary.wiley.com/store/10.1002/col.21768/asset/col21768.pdf;jsessionid=E57EF5A1FC36B3243B8A65419D134A5E.f02t01?v=1&t=hspwwyyr&e3adc778&systemMessage=Wiley+Online+Library+will+be+disrupted+Saturday%2C+15+March+from+10%3A00-12%3A00+GMT+%2806%3A00-08%3A00+EDT%29+for+essential+maintenance), and references therein.


https://dl.dropboxusercontent.com/u/2621383/Screen%20Shot%202014-03-13%20at%206.53.08%20AM.png

[Audionut]

If you truly want to capture that experience and memory in a single shot, there is no other way but HDR.

Which is exactly what I was saying.

I started by pointing out that your statement.

You can't emulate a 1,000,000:1 eye curve, in a 1000:1 image. That will look very bright,

Was just plain wrong.

Then for some reason or another, you wanted to drift the conversation into your own personal subjective opinion of the HDR rendering capabilities of individuals.

Look at an HDR picture and ask yourself, is that how reality looks like?
Its pretty, but definitely not.

The emulation is not perfect, but its sure pretty...

Based on some standard set forth by yourself.

Actually, we don't need more that 1000:1 to emulate reality in a single instant

A single instant? And is this a time period of 1ms? 10ms?

Are single instances, an accurate reflection on how we perceive the world?

[James Freeman]

Your assumptions are simplistic, engineers of the time did understand the importance of non-linear encoding.
My assumption is simplistic in purpose.
Of course engineers understood the importance of non-linear encoding to achieve perceptual uniformity with CRTs back then.
But its NOT because of human perception, its because of technological limitations of the CRT itself.
Please read my further posts.


A single instant? And is this a time period of 1ms? 10ms?

A single instance is where you look at one spot and your pupil is done contracting or dilating based on the lighting of the situation.
This is what we capture with a camera or video camera, single instances.
You eyes can be over exposed (blinded) too, because it takes few seconds (to a minute) for your pupil to normalize.

Are single instances, an accurate reflection on how we perceive the world?
No, your eyes pupil (shutter) constantly changing according to where you look, and the amount of incoming light where you look.
That's why you can see a dynamic range of about 1,000,000:1.

If you look in a single spot for a few seconds, that is a single instance.
In that single instance your eyes can't see more than about 600-1000:1 CR, and that's a proven fact (by scientists), And tested by me in MS Paint. :)

Just paint two small squares with close but different shades of black one inside the other.
Now look at the squares with Black background, you supposed to see the squares differ in shade clearly.
Now look at the squares with White background, you will not be able to tell them apart.
This was with my old 800:1 Dell U2410.

Was just plain wrong.
By the "you can't emulate" statement I wanted to say that if you encode an image with inverse gamma curve and display it on a linear display you get overblown (bright) image.
It was a response to others that think the inverse gamma curve is done to emulate human vision and not a "fix" for the CRT curve to achieve perceptual uniformity.



I want to stop this discussion (I'm tired of it) and get back to madVR.
The internet has a lot of information and this forum is not the right place.

[zoyd]

I want to stop this discussion (I'm tired of it) and get back to madVR.
The internet has a lot of information and this forum is not the right place.

yes, do please stop. I for one am very pleased in knowing we have a forum member that can offer us more insight in to the historical development of non-linear encoding than Poynton can.

[scollaco]

Download this file: Black Clipping (http://www.mediafire.com/watch/48jdp2v53d43a05/1-Black_Clipping.mp4)

Make sure you see step 17 and up.
Step 17 should be barely visible, 16 is pure black.

Yes...I do see Step 17 and up...and 16 is pure black. This is with "calibrated to" and "desired gamma" all turned off. When I turned "calibrated to" to BT709 (primaries), pure power and 2.1 and then set "desired gamma" to pure power 2.4......I still see Step 17 (faintly) , 18 (visible but fainter than before) and then 19 on is completely noticeable.

So is my native gamma sRGB or pure power 2.1-2.2? Comparing avatar images, sRGB seemed like the closest match followed by pure power 2.2. If my native gamma is sRGB what settings should I put in madVR then?

Thanks for the help. When watching a movie things looks great...I just want to make sure I have the gamma set closest to what the movie should look like :) Also I watch movies in a totally light controlled bat cave home theater

[iSunrise]

If my native gamma is sRGB what settings should I put in madVR then?
sRGB is currently (and probably never will be) not directly supported by madVR. It has been suggested several times before, but madshi didn't like the idea.

If you're stuck with sRGB, just set your primaries / gamut to BT.709 (because they both are identical). If your native gamma is already around 2.2 (which it should be to conform to sRGB) you don't have to enable gamma processing at all. If you can improve your black levels with gamma processing, while still being able to discern all the black steps, you can try that, too.

Only a careful calibration or native sRGB support would give you better results.

[Shiandow]

When I turned "calibrated to" to BT709 (primaries), pure power and 2.1 and then set "desired gamma" to pure power 2.4......I still see Step 17 (faintly) , 18 (visible but fainter than before) and then 19 on is completely noticeable.


This sounds correct so I'd go with those settings. It's probably going to be hard to get a significantly better result without actually measuring the gamma curve of your screen.

[James Freeman]

This sounds correct so I'd go with those settings.
Yes, looks good.

Note that when you set "calibrated to" Power 2.1 and "desired gamma" to power 2.4,
Its exactly if you set "calibrated to" Power 2.2 or (none) and "desired gamma" to power 2.5.

Yet it does not matter,
Choose what looks good in your bad cave to you.

[StinDaWg]

Hi madshi,

pixel shaders will be integrated the way EVR custom does? Will we be able to choose between pre and post-resize shaders and utilize directly the scripts from EVR custom? It will be fantastic to finally be able to use a post-resize sharpener in madVR without recurring to the TV set sharpening (which is usually crap) or NVIDIA enhancements.

I’ve seen you mentioned Dideé's "fine sharp", which to my eyes is the best around (better than Seesaw and LFSMod), do you think it will be possible to integrate it into madVR via pixel-shaders (GPU) so that we can sharpen AFTER resize with madVR?

It will be also cool to integrate into the interface the most common pixel shaders and to be able to tweak the basic parameters directly from madVR interface (like ffdshow does!).

Thanks :)
I do plan to add support for custom pixel shaders, and there will be different shaders for before and after scaling. I can't say much more right now, though, because I haven't even started working on that yet.
I'm quoting this post from 2012. I've been playing around with FineSharp and I really like the look of it, but it kills me that I can only use this pre-resize due to the way ffdshow raw works. FineSharp is better used post-resize otherwise it just oversharpens the image. Is there just no way I can get this to work with madVR?

[nevcairiel]

madVR supports custom pixel shaders just fine. Just load them like you would for EVR, in MPC-HC at least. Needs to be supported in your player.

[StinDaWg]

madVR supports custom pixel shaders just fine. Just load them like you would for EVR, in MPC-HC at least. Needs to be supported in your player.
FineSharp is an avisynth plugin. It's probably the best sharpening algorithm out there but there's no way to use it post-resize with madVR due to ffdshow raw not being able to go after madVR in the processing chain.

[scollaco]

sRGB is currently (and probably never will be) not directly supported by madVR. It has been suggested several times before, but madshi didn't like the idea.

If you're stuck with sRGB, just set your primaries / gamut to BT.709 (because they both are identical). If your native gamma is already around 2.2 (which it should be to conform to sRGB) you don't have to enable gamma processing at all. If you can improve your black levels with gamma processing, while still being able to discern all the black steps, you can try that, too.

Only a careful calibration or native sRGB support would give you better results.

This sounds correct so I'd go with those settings. It's probably going to be hard to get a significantly better result without actually measuring the gamma curve of your screen.

Yes, looks good.

Note that when you set "calibrated to" Power 2.1 and "desired gamma" to power 2.4,
Its exactly if you set "calibrated to" Power 2.2 or (none) and "desired gamma" to power 2.5.

Yet it does not matter,
Choose what looks good in your bad cave to you.

Thanks guys for all your input/help. I'm pretty satisfied with the image so I will leave it at those settings and stop obsessing now :)

[markanini]

sRGB is currently (and probably never will be) not directly supported by madVR. It has been suggested several times before, but madshi didn't like the idea.

If that's the case maybe this would be good reason for Madshi to reconsider:

I second this, I personally noticed looking at gamma curves that calibrating a typical IPS display (1000:1 contrast ratio) to BT.1886 and sRGB that they differ very little. Which is actually quite neat because it means calibrating an IPS display to BT.1886 is pretty much the same thing as calibrating to sRGB.

[nevcairiel]

FineSharp is an avisynth plugin. It's probably the best sharpening algorithm out there but there's no way to use it post-resize with madVR due to ffdshow raw not being able to go after madVR in the processing chain.

Then why would you quote a post about pixel shaders?
You're free to port it to a pixel shader though.