Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
10th March 2014, 12:08 | #24701 | Link | |||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
(1) Neither gamma ramps nor 3dlut on the HTPC. madVR set to "disable calibration controls". I can only guess here which transfer function to use. (2) Neither gamma ramps nor 3dlut on the HTPC. madVR set to "this display is already calibrated". This is the easiest case. (3) Same as (1) and (2), but the display is calibrated by using GPU gamma ramps (but no 3dlut). This is very complicated because in Overlay mode the GPU gamma ramps are applied before dithering, while in Windowed and FSE modes the GPU gamma ramps are applied after dithering. Which means I'd have to ask the user for 2 different transfer functions, depending on rendering mode (Overlay vs. windowed/FSE)! (4) Display is calibrated by using a 3dlut, but no GPU gamma ramps. This is complicated because the 3dlut calibration is performed *before* dithering. Which means the dithering itself should be done with the transfer function of the uncalibrated display. But does the user even know that transfer function? And how to get this information from the user without confusing him? (5) Display is calibrated by using a 3dlut + GPU gamma ramps. Combine all the problems of (3) and (4) and make them extra difficult because every possible combination of (3) and (4) and different rendering modes has to be supported. I think you can see how achieving perfection would be a usability nightmare! I'd have to add several new transfer function setting controls, with very confusing descriptions (like "I know you calibrated your display with a 3dlut, but what transfer function does your display produce, if the 3dlut is not applied?"). This doesn't really make any sense, considering that the potential gain in image quality is so extremely small. So I've decided to choose the easy way out: Let's decide on one transfer function that I'll use for linear light dithering. It will always be used, to make things simple and comparable. Sorry, but making this adjustable just isn't worth the usability nightmares. I'm currently thinking of using BT.709 2.2. This will probably produce a too bright image on many displays, but it will be much nearer to the correct look on *all* displays compared to gamma dithering. Alternatively I could use a pure power curve of 2.2, or BT.709 2.4, but while these might look better on many displays, they will already be too dark for some monitors out there. So I'm thinking, maybe BT.709 2.2 would be the conservative and best solution. But if the majority of you guys think I should be using a pure power curve of 2.2 or BT.709 2.4 instead, that's fine with me, too. One additional argument for BT.709 2.2 is that it happens to be the encoding transfer function. That's not really important, though. Thoughts? |
|||||||||||||||
10th March 2014, 12:37 | #24702 | Link | |
Registered User
Join Date: Sep 2013
Posts: 919
|
Quote:
Agreed. I don't see the difference in 8-bit anyway so I'll be happy about any choice we finally make. IMO to save 10 pages of heated debate, just create a poll thread with test images and let users vote (who read this thread or not). Our goal is to find the average consumer TV/Monitor Gamma curve, which should be quite interesting to know. On the other hand (as an Advanced user), You can always put a LinearLight.ini file in the madVR directory which lets advanced users tweak this independently of what "situation" they use. Its by far the easiest option to satisfy all advanced users without being a coding nightmare for you nor clattering madVR settings window..
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. Last edited by James Freeman; 10th March 2014 at 13:10. |
|
10th March 2014, 12:53 | #24703 | Link | |
Registered User
Join Date: Dec 2013
Posts: 753
|
Quote:
Code:
#define depth 255 sampler s0 : register(s0); float4 main(float2 tex : TEXCOORD0) : COLOR { float4 c0 = tex2D(s0, tex); float4 low = floor(depth*c0)/depth; float4 hi = low+(1/depth); float4 gamma = max(1,g*low/(low+a)); float4 c1 = (pow(c0,gamma)-pow(low,gamma))/(pow(hi,gamma)-pow(low,gamma)); return low+(c1/depth); } Rec. 709: a = 0.099, g = 1/0.45 sRGB: a = 0.055, g = 2.4 any pure power curve: a = 0, g = gamma. |
|
10th March 2014, 12:58 | #24704 | Link | |
Registered User
Join Date: Sep 2013
Posts: 919
|
Quote:
Why not just create a LinearLight.ini file in the madVR directory which lets advanced users tweak this independently of what "situation" they use and without clattering madVR Settings control panel?
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. |
|
10th March 2014, 13:04 | #24705 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
10th March 2014, 13:04 | #24706 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
I've not measured my most recent calibration, but usually it's something like the following with Argyll CMS BT.709 curve scaled to 32lux ambient lighting on my CRT: Near-black = 1.90 avg gamma Mid-tones = 2.45 avg gamma Near-white = 2.60 avg gamma Remember I mentioned the L* (L*a*b* luminance) curve before? That's essentially what this matches, except near black. If I instead calibrate to BT.1886 it is usually: Near-black = 2.10 avg gamma Mid-tones = 2.35 avg gamma Near-white = 2.40 avg gamma Last edited by cyberbeing; 10th March 2014 at 14:17. |
|
10th March 2014, 13:20 | #24707 | Link |
Registered User
Join Date: Dec 2008
Posts: 496
|
madshi, could you at least provide us with a single test build with a checkbox selection for, say, sRGB 2.2, BT.709 2.2 and BT.709 2.4 so we can compare them directly to finally be able to make the decision to only select one transfer function easier.
It would be a lot easier (for me) when using actual test files and compare them first-hand, instead of having to guess how they might look like, because currently, we only have the hardcoded 1/0.45 to work with. I think BT.709 2.2 would probably be too bright again, but I'm not sure, because I've never seen it with actual test material on my display. Otherwise, my choice would be the current 1/0.45, since starting from 3bit the current linear light 1/0.45 transfer function already looks more accurate here than gamma light could ever look. I want to be absolutely sure that before suggesting something, it doesn't bite us in the ass at 8bit for some reason. Also, if we choose a linear light approach that resembles the bright gamma results, we would basically have not won anything and I just want to avoid that at all cost, because 1/0.45 was already giving us very good results. Just for references sake, on my iPad 3, which is factory calibrated to sRGB / Rec.709 and 2.20 gamma the middle and right grey rectangles are 100% identical. It looks like one big, even grey rectangle. Can't even see a difference when zoomed in. Perfect match. The current 1/0.45 seems to be perfect. Last edited by iSunrise; 10th March 2014 at 14:27. |
10th March 2014, 13:50 | #24708 | Link |
Registered User
Join Date: Feb 2013
Posts: 137
|
I understand, I'm still looking what I have in particular that can affect the refresh rate. I know you're very busy with dithering questions but when you have the time to make a test build, you can be sure I will be there to test it.
|
10th March 2014, 13:53 | #24709 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
The same settings look great on still images & TV, I like a dark gamma. Last edited by leeperry; 10th March 2014 at 13:56. |
|
10th March 2014, 14:13 | #24710 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Your gamma chart slants in the opposite direction of mine (BT.709 | BT.1886).
Personally, I don't think it makes practical sense to have a darker gamma near black and progressively brighter up to near-white like you are showing on your display. That's like the exact opposite of what should have a linear appearance to humans. Everything is subjective though, and maybe that's just a quirk of your display's calibration controls? |
10th March 2014, 14:21 | #24711 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
I think BT.709 2.2 is a reasonable compromise, that is the brightest of the three linear options and the closest to gamma. However, if I have a vote I vote for sRGB. sRGB is the default PC gamma as assumed by Photoshop, Firefox and the like. Something at ~2.4 gamma would look better to me at 2-bit but that is too far outside the "middle" for me to think it is a good candidate.
Quote:
What a strange gamma, it gets lower as it increases? All my BT.1886 calibrated gammas increase with brightness. You must like nice dark shadows. |
|
10th March 2014, 14:23 | #24712 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Well, my TV only comes with a global gamma setting that goes from -3 to +3, I don't like how clear -1 looks and -2 looks just great. And it's not a matter of GL looking too clear and compensating for my dark gamma AFAIK as both HD DVB-T from the built-in tuner and still images in Windows look equally great to me.
In that chart I only miss the two darkest shades, I'm used to the high native contrast of CRT and high ANSI contrast of DLP projectors, this gamma curve makes me plenty happy...sure, I'm cheating but I make do with the low 3.5K:1 native contrast. Now that I think of it, I vividly remember a friend of mine on HCFR using the same kind of sliding gamma curve on his 3K:1 DLP projector and being most happy with it. Last edited by leeperry; 10th March 2014 at 14:29. |
10th March 2014, 14:36 | #24714 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
A solution to what? I've already said that I've decided to use only one transfer function. The only question I need an answer to is which one transfer function should be used. Currently I tend to pick BT.709 2.2.
|
10th March 2014, 14:47 | #24715 | Link |
Registered User
Join Date: Dec 2008
Posts: 496
|
Now I know why cyberbeing and leeperry seem to prefer gamma light to linear light. I just connected our Samsung F6500, which I carefully calibrated on movie mode, to my iPad over Airplay and I agree with both of them. When I switch between the original 8bit avatar and the 2bit gamma, they are perfectly even, while everything else is way too dark. To my surprise, even linear BT.709 1/0.45 is way too dark.
Last edited by iSunrise; 10th March 2014 at 15:13. |
10th March 2014, 14:52 | #24716 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
10th March 2014, 14:59 | #24718 | Link | |
Registered User
Join Date: Dec 2008
Posts: 496
|
Quote:
cyberbeing basically said that on his CRT with perfect black reproduction, gamma light is a bit brighter, while the linear light ones are way too dark, which is almost exactly what I see here. Last edited by iSunrise; 10th March 2014 at 15:32. |
|
10th March 2014, 15:04 | #24719 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
This is a game-support release from the same r334 branch. It'll take a real new driver for that.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
10th March 2014, 15:30 | #24720 | Link | |||
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
The BT.709 transfer itself has a best-fit curve of 1.96 (1/0.51) Are you referring to using an exponent of 0.45 as "BT.709 2.2"? Or are you taking the BT.709 transfer function and then scaling it to 2.2? (^1.125) What do you mean when you say "BT.709 2.4"? (and how are you getting there?) Most of the papers I have read suggest that the system gamma should be 1.2 (~2.35) though Poynton suggests 1.25 (~2.45) and BT.1886 now targets 2.40 gamma, which is the first actual standard we have that defines what gamma should be on the display. Just about everything says that you should be using a pure power function rather than the inverse of the BT.709 camera gamma with its linear tail near black. Otherwise you are counteracting the entire point of it being there. Quote:
I seem to recall one calibration package that defaulted to it years ago, and it caused all sorts of problems. You are better off using a scaled BT.709 transfer than L* though I wouldn't recommend that either. BT.1886 should produce much better results than either of those, as it calculates the "just noticeable difference" values based on your display contrast/black level, and basically gets you as close to the ideal 2.40 as possible without crushing shadow detail. Quote:
This is the same reason why I was testing on a retina macbook - similar pixel density, which makes the comparison easier to do. However, if we have to settle for a single transfer function, an ideal display will be using a flat 2.40 calibration for video. Not 2.2 I would much rather it be based upon an ideal display than what looks fine on a crappy low contrast monitor. Airplay uses lossy compression and rescales the image, the results of this test are invalid. Last edited by 6233638; 10th March 2014 at 15:33. |
|||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|