madVR - high quality video renderer (GPU assisted)

[agustin9]

i vote for pure power 2.22, i think it's the most common one in computers

[6233638]

I'd certainly be happy with that right now, since I'm using a videoLUT calibrated to that targetHow did you choose that as a target? Because a lot of programs are changing the exponent in the BT.709 function, which is the wrong way to do it.
And the BT.709 curve is not intended to be used on displays. It's expected that a power curve will be used.

Here's my vote FWIW and not doing any actual testing. I would pick a BT.1886 transfer function with black level 0.03 cd/m^2 and white level 120 cd/m^2 as your standard. This is a good compromise between high-end and mid-range displays. Average power law gamma for this display above 5% stimulus is 2.25 but it will give you a BT.1886 interpolated dither between your anchor points.That seems quite arbitrary to me. 0.03 cd/m2 is what you would expect from televisions six or seven years ago.
A cheap Panasonic ST60 will give you an 0.005 cd/m2 black level. (high enough contrast to use 2.40)

One part that still puzzles me about this entire discussion is that noone has mentioned anything about these colour inaccuracies before, yet as far as I can tell smooth motion has been using a pure power gamma curve the entire time.I thought smooth motion did its blending in linear light already?
I haven't been able to use it since its introduction though, as it activates when 25p content is output at 24Hz.

That's mathematically more expensive. I'm changing all the constants including the exponent, which produces the same overall result. That's why I still like to talk about BT.709 with 1/0.45 or 2.4 exponent.You can't change the exponent without changing the linear tail, or the results are disastrous. (or my calculations were wrong - but I don't think they were)

But camera gamma was never intended to be used on the display. The intent when the standards were created was that BT.709 content would be viewed on a CRT.

CRTs naturally have ~2.40 gamma.
This is the reason why the BT.1886 spec targets it.

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

linear (pure power 2.4) (http://madshi.net/avatar2bitPurePower24.png)Seems like a clear winner to me...
Edit: though I might be getting thrown off by the fact that the new images are not using colored dither.

[sexus]

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

nope , still getting green screen crap with NNEDI3 enabled in chroma upscaling , the one and only way to test NEEDI3 functioning , fn hell how long does it take to fix this , there gotta be some solution , i wanna use NNEDI3 again , damn it and i dont wann go back to older drivers either since these are pretty nice with recent games :angry:

[Ver Greeneyes]

How did you choose that as a target? Because a lot of programs are changing the exponent in the BT.709 function, which is the wrong way to do it.
And the BT.709 curve is not intended to be used on displays. It's expected that a power curve will be used.I used dispcal with |-g709 -a64| which takes the BT.709 curve and converts it from the (studio lighting) viewing conditions it was made to represent to the 64 lux background light viewing conditions of sRGB (which matches my room pretty well at least in terms of luminance). It sounds pretty reasonable to me (if complicated) and Graeme seemed to think so as well.

[bacondither]

Well BT.1886 becomes 2.40 gamma when used on a good display.
Well yes, if the display has a infinite contrast ratio and is placed in a pitch black room with 100% light absorbing walls. Not exactly a realistic situation.

If your display has a real contrast ratio of ~1000:1, ambient light included. The BT1886 gamma curve is almost identical to sRGB gamma.

[madshi]

The problem with choosing an gamma curve based on what high end screens use is that the effect of linear light dithering is most obvious on a screen which can only display 6 bits, which isn't exactly high-end.
Good point. Well, I guess I could use BT.1886 with different black levels for different bitdepths. E.g. for 6bit I could use a blacklevel that is typical for such display. For 8bit I could assume a better black level.

madshi, I'm curious: Earlier, you said that you dislike the idea of having the dynamic dithering mode change the pattern at "video rate" (once for every frame the decoder outputs and the Smooth Motion blended frames) and changed the dithering pattern and screen refresh rate. However, you hinted (and I just confirmed it by playing a 5 fps video at 1 bit dithering) that the new version of madVR changes its dithering pattern only at "video rate" rather than screen refresh rate. Why?
There's really no good alternative to changing the dynamic dither pattern at "video rate". Changing it at refresh rate would require a lot of extra code and programming effort, and it would slow performance down quite noticeably. It's not something I plan on implementing.

There seems to be something wrong with the "pure power 2.4" screenshot though?
Not sure, I thought I did it right, but maybe I made a mistake, I don't know...

That seems quite arbitrary to me. 0.03 cd/m2 is what you would expect from televisions six or seven years ago.
A cheap Panasonic ST60 will give you an 0.005 cd/m2 black level.
Yeah, but how many users have a plasma compared to an LCD TV? Look at the sales numbers. Of course with LCD TVs there's the problem whether to target local dimming black levels or native panel black levels. In any case, we need a compromise. The majority of today's displays still has mediocre black levels.

You can't change the exponent without changing the linear tail
I know. I said "all the constants".

But camera gamma was never intended to be used on the display. The intent when the standards were created was that BT.709 content would be viewed on a CRT.
I know. But LCDs can't compete with the black levels of good CRTs.

CRTs naturally have ~2.40 gamma.
I know. They could, because their black levels and contrast supported that.

Well BT.1886 becomes 2.40 gamma when used on a good display.
I know. With a perfect display under perfect conditions, at least.

If your display has a real contrast ratio of ~1000:1, ambient light included. the BT1886 gamma curve is almost identical to sRGB gamma.
It is? With an sRGB power exponent of 2.4? I would have expected the BT.1886 image to be brighter with such a contrast ratio.

[Mangix]

My vote goes for pure power. It looks the most accurate on my uncalibrated display.

[nautilus7]

i vote for pure power 2.22, i think it's the most common one in computers

That's what looks best on my pc monitor as well. But isn't madVR intended for big monitors/projectors? What fits best to them?

[XMonarchY]

That seems quite arbitrary to me. 0.03 cd/m2 is what you would expect from televisions six or seven years ago.
A cheap Panasonic ST60 will give you an 0.005 cd/m2 black level. (high enough contrast to use 2.40)

LOL, wut? Are you dismissing all non-high-end plasma display owners just like that? Modern SPVA TV's @ 120 cd/m^w white point usually have a 0.05-0.04 cd/m^2 black point. Only plasma owners have it lower. Hell, some mid/low-range plasma TVs being sold today have 0.03 cd/m^ black point. What about monitor users with 750:1 - 2500:1 contrast ratio? Even the top-end Eizo Foris FG2421 gaming VA monitor panel with 5000:1 CR does about 0.025 cd/m^2 for black point.

It really doesn't matter what CR/black point you have when it comes to BT.1886 gamma. Its a perceptual curve, meant to be used on displays with ANY possible black point level. Its the ONLY gamma that makes sense since it accommodates content mastered with any gamma, but power-law gamma does not accommodate those with low contrast ratio.

[turbojet]

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

Wish I could try but cru doesn't see the tv and nvidia cp has custom resolution disabled when the tv is selected. On hdmi out with either cru or nvidia cp custom resolution 48hz was limited while 50 was full range. Custom resolution trick probably doesn't work any more.


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

It didn't work for me with hdmi, neither did the inf driver hack which essentially adds to the registry. NV_RGBFullRangeToggle worked though it took about 10-15 seconds to run, it also appears to just be adding a bunch of registry entries. Maybe some are getting missed by your tool?

Anyhow I've sorted out the hdmi now. Madvr's overlay always seems to display full range, no matter what the display is set to in madvr. Does this have to do with madvr, windows or video driver?

EDIT: On crt overlay is much darker than full range, maybe another 16 steps lower. Is there a way to capture the overlay output?

Originally Posted by madshi View Post
Alright. The 2 new screenshots are now made with monoColor, the others remain in oppositeColor:

|- gamma -|- original -|- linear (pure power 2.22) -|- linear (pure power 2.4) -|- linear (sRGB 2.4) -|- linear (BT.709 2.22) -|- linear (BT.709 2.4) -|

sRGB looked closest to original to me on 2 lcd monitors, an lcd tv and a crt.

[James Freeman]

I've done some calibration testing and comparison with these pictures.

When calibrated to Gamma 2.2 Relative, the Pure Power 2.22 is a perfect match.
When calibrated to sRGB, the sRGB 2.4 is a perfect match.
No surprise here.

My uncalibrated PC monitor falls somewhere between those two.
As my final vote I'd go for Pure Power 2.2 with my PC Monitor.

Calibrating to BT.709 resulting in very elevated low end that emphasizing the noise even at the cleanest blu-rays.
I don't think it should be used at all for any display device (by definition or by choice).

In my opinion the lower blacks should NOT be linear so that they are clearly visible like in sRGB or BT.1886.
They should be on the edge of visibility without crushing, as called "Power Curve with Compensated blacks".

[Shiandow]

I thought smooth motion did its blending in linear light already?
I haven't been able to use it since its introduction though, as it activates when 25p content is output at 24Hz.


It does do its blending in linear light, but as far as I know it just uses a pure power 1/0.45 gamma curve. In this case you've got the same problem that ideally the gamma curve that's used should match the display's. Except it's even worse since you don't just have to 'blend' adjacent colours but in the worst case you have to blend white and black. So the result depends on the behaviour of the entire gamma curve and not just what it looks like locally. I was just wondering why nobody noticed this when it should be far more obvious. I suspect that it is because it's only inaccurate if the image changes rapidly, but I'm also starting to wonder if it's even humanly possible to notice the difference (except at low bitrates).

@madshi
If you want to choose a fixed gamma curve then you should change the one that's used for smooth motion as well. If not then smooth motion will darken/lighten the image slightly which means that you can lose a large part of the accuracy you gained by choosing a 'better' gamma curve. This effect should occur regardless of the actual gamma curve of the monitor, so if they are not both the same then it will always look worse, even if one of them is the actual gamma curve.

[bacondither]

It is? With an sRGB power exponent of 2.4? I would have expected the BT.1886 image to be brighter with such a contrast ratio.

Yes, according the BT1886CalcV3.xls (http://www.sendspace.com/file/8c860q) made by HDTVChallenged @avsforum.
I haven't checked the math but i think it is sound.

~1100:1 contrast ratio they look pretty alike.

[6233638]

Well yes, if the display has a infinite contrast ratio and is placed in a pitch black room with 100% light absorbing walls. Not exactly a realistic situation.From what I remember, once you hit 0.01cd/m2 black level, you switch to using 2.40 gamma. You do not need a display with "infinite contrast"LOL, wut? Are you dismissing all non-high-end plasma display owners just like that? Modern SPVA TV's @ 120 cd/m^w white point usually have a 0.05-0.04 cd/m^2 black point.I'd be more concerned about the black level than what should be an almost imperceptible change in 8-bits.

If Madshi doesn't want to target an ideal display (2.4 power curve) then I think 1/0.45 power is the best compromise.
What about monitor users with 750:1 - 2500:1 contrast ratio?Well even 2.2 gamma would be too much for most of them.
It really doesn't matter what CR/black point you have when it comes to BT.1886 gamma. Its a perceptual curve, meant to be used on displays with ANY possible black point level. Its the ONLY gamma that makes sense since it accommodates content mastered with any gamma, but power-law gamma does not accommodate those with low contrast ratio.Yes, but that requires user input which madshi wants to avoid.When calibrated to Gamma 2.2 Relative, the Pure Power 2.22 is a perfect match."Relative" means that it's not actually going to measure 2.2 gamma at all. It's compensated for black level and will lower the gamma to prevent clipping.Calibrating to BT.709 resulting in very elevated low end that emphasizing the noise even at the cleanest blu-rays.Yes - it's not intended to be used on a display. They intentionally use a linear section near black in the camera gamma, so that it masks the noise near black when you view it on a display with a power curve gamma.

[madshi]

If you want to choose a fixed gamma curve then you should change the one that's used for smooth motion as well. If not then smooth motion will darken/lighten the image slightly which means that you can lose a large part of the accuracy you gained by choosing a 'better' gamma curve. This effect should occur regardless of the actual gamma curve of the monitor, so if they are not both the same then it will always look worse, even if one of them is the actual gamma curve.
I think I have to disagree here. Smooth motion blending is performed in linear light, but the final result is converted back to gamma light. Basically we're creating new source frames, so to say, so the mixing should be done in the source's transfer function, I think. The interpretation of the gamma pixels is still fully up to the display's gamma processing. Basically the mixed colors will also run through the display's gamma processing. I think it doesn't matter for smooth motion blending how the display is calibrated.

Dithering is very different because the amount of dither pixels between shade 1 and shade 2 is stamped into the image and won't be reinterpreted by calibration or by the display's gamma processing, anymore. So because of that we have to use the display's actual transfer function, otherwise the amount of dither pixels will be incorrect.

Yes, according the BT1886CalcV3.xls (http://www.sendspace.com/file/8c860q) made by HDTVChallenged @avsforum.
I i haven't checked the math but i think it is sound.

~1100:1 contrast ratio they look pretty alike.
Hmmmm... Interesting. Then maybe sRGB could be a good candidate, after all. At least for less than 8bit. For 8bit maybe something nearer to a pure power curve (but not quite there) would be best. Basically a BT.1886 curve with a "better" black level...

[e-t172]

Yes, according the BT1886CalcV3.xls (http://www.sendspace.com/file/8c860q) made by HDTVChallenged @avsforum.
I haven't checked the math but i think it is sound.

~1100:1 contrast ratio they look pretty alike.

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.

[James Freeman]

"Relative" means that it's not actually going to measure 2.2 gamma at all. It's compensated for black level and will lower the gamma to prevent clipping.
Are you sure that that is what ArgyllCMS is doing?
What about Absolute?

The manual explains it vaguely.
Something at 50% Input Relative vs Absolute behavior is different.

[*Touche*]

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


Gamma and both BT.709 - way too bright

Pure power 2.2 and 2.4 - a bit darker

sRGB - a bit brighter, but would prefer it over pure power's crushed blacks

My plasma is currently calibrated to 2.2 (plan to redo it to BT.1886 later), but the real gamma is questionable due to APL, so my results may not be that useful.



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

I can confirm that they look very similar.

[Shiandow]

I think I have to disagree here. Smooth motion blending is performed in linear light, but the final result is converted back to gamma light. Basically we're creating new source frames, so to say, so the mixing should be done in the source's transfer function, I think. The interpretation of the gamma pixels is still fully up to the display's gamma processing. Basically the mixed colors will also run through the display's gamma processing. I think it doesn't matter for smooth motion blending how the display is calibrated.

Well I might be wrong here, it can get really confusing which part should be in which colour space. My reasoning that those gamma curves should be the same is as follows:

Let's say that dithering uses a gamma curve A. If dithering is done correctly then we can basically forget that we used dithering and just assume we have a 16bit monitor with gamma curve A. Now if smooth motion blends two frames according to some different gamma curve B, then the result generally won't be blended linearly in gamma curve A. So why would we still expect the result to be blended correctly if output by a monitor with gamma curve A?

Edit: After thinking some more about it, I guess smooth motion should use the source gamma to go to linear light, but use the monitor gamma to convert it back. I'm reasonably sure that the gamma should change somewher and after or during smooth motion seems the most reasonable place to do it since up to that point we've been modifying the source but after that we're working on generating the output. Does this vaguely make sense?

[leeperry]

Having more thoughts about it, what I would need for inverse PAL-speedup movies is a second "treat 25p movies as 24p" that wouldn't be saved and would only be effective for the current movie so I could open my 25p movie, check this, mVR would roll 24Hz and forget it once I close my media player. Most ppl in the EU have both genuine PAL material and sped up movies so a permanent option doesn't help IMHO.

Not sure if that would qualify as s a feature request but it sure would prove to be extremely handy :o

I realize that LL looks smoother but I can't really understand why Captain Harlock looks so dull with it, oh well I'll see how the final LL algorithm fares and will take it from there(possibly using that PS script to mess with it a bit further).

:thanks:

[DarkSpace]

There's really no good alternative to changing the dynamic dither pattern at "video rate". Changing it at refresh rate would require a lot of extra code and programming effort, and it would slow performance down quite noticeably. It's not something I plan on implementing.
I see, thanks for elaborating. I didn't bother to test it earlier, but I was under the impression that the dither test builds you posted a while back for dynamic used refresh rate, not video rate, to change patterns. This was, obviously, a misunderstanding, then.

[markanini]

Yes, according the BT1886CalcV3.xls (http://www.sendspace.com/file/8c860q) made by HDTVChallenged @avsforum.
I haven't checked the math but i think it is sound.

~1100:1 contrast ratio they look pretty alike.

Damn, my 7yo IPSs BT.1886 target has an average gamma of 2.03.

@Madshi could you consider adding a sRGB option to "enable gamma processing"?

[Ver Greeneyes]

It is? With an sRGB power exponent of 2.4? I would have expected the BT.1886 image to be brighter with such a contrast ratio.Yes, according the BT1886CalcV3.xls (http://www.sendspace.com/file/8c860q) made by HDTVChallenged @avsforum.
I haven't checked the math but i think it is sound.

~1100:1 contrast ratio they look pretty alike.I did some experiments in Mathematica to confirm this. The following numbers are the optimal contrast ratios for different optimization goals:Minimizing the RMS (2-norm) of the error: 1199.55:1
Minimizing the maximum absolute value (∞-norm) of the error: 1290.26:1These minimize the difference between sRGB and BT.1886. So the claim of 1000:1 or 1100:1 isn't far off if we look at the absolute error, but 1200:1 or 1290:1 is optimal (as far as fitting to sRGB is concerned). Choosing between the two I'd pick 1200:1: the maximum error is still only 0.08336% and the average is much better. I also looked at optimizing the relative error (more precise near black) and that points to much higher contrast ratios - but then, one could question how objective/sensible that linear segment in sRGB really is.

Edit: Optimizing the relative error, the optimal contrast ratio gets higher the more points I use (at 2^16 it's around 400k:1), so I don't think it's particularly useful as a metric.

[madshi]

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

Well I might be wrong here, it can get really confusing which part should be in which colour space.
It *is* complicated. I'm sometimes getting confused, too.

Edit: After thinking some more about it, I guess smooth motion should use the source gamma to go to linear light, but use the monitor gamma to convert it back. I'm reasonably sure that the gamma should change somewher and after or during smooth motion seems the most reasonable place to do it since up to that point we've been modifying the source but after that we're working on generating the output. Does this vaguely make sense?
I don't really know. My bed is calling, and I'm tired, so I'm not in the condition to really think this through, anymore. Maybe somebody else can figure this out.

Having more thoughts about it, what I would need for inverse PAL-speedup movies is a second "treat 25p movies as 24p" that wouldn't be saved and would only be effective for the current movie so I could open my 25p movie, check this, mVR would roll 24Hz and forget it once I close my media player.
Shouldn't a refresh rate / file name tag take care of this?

[leeperry]

Shouldn't a refresh rate / file name tag take care of this?
Tagging silver discs is out of the question and sometimes you don't know that a movie comes with the chipmunk disease before you open it, so an on-the-fly temporary option would really hit the spot IMO :)

Reclock was designed to forget what fps overriding setting you chose if you don't check the "locked" box, that works great. It's really too bad James can't be hassled to make mVR & Reclock play nice.

Of course, a 24p tag wouldn't hurt.

[DarkSpace]

Edit: After thinking some more about it, I guess smooth motion should use the source gamma to go to linear light, but use the monitor gamma to convert it back. I'm reasonably sure that the gamma should change somewher and after or during smooth motion seems the most reasonable place to do it since up to that point we've been modifying the source but after that we're working on generating the output. Does this vaguely make sense?
Maybe somebody else can figure this out.
I believe that for Smooth Motion, you should use the same gamma curve for converting to and from linear light:
Say you are blending together two identical frames. Then you effectively convert color A to linear light and then convert it back to gamma light. However, if you use a different curve to convert back to gamma light, you will change the color. Furthermore, if your refresh rate is high enough to display the frame without blending also (e.g. perfect 24p at 60 Hz), you will have color B (which is color A after blending) and then untouched color A for the exact same image.
Further, I believe (but I'm not too confident about this) that using the source gamma for Smooth Motion should be correct, because Smooth Motion is applied before any 3D LUT or Gamma correction. So to say, SM is done in "Source RGB" while Dithering is done in "Target RGB", so SM should use "Source Gamma" while Dithering should use "Target Gamma".

[wOxxOm]

Is it okay for madVR's IVTC (deint = film mode) to match wrong fields and show combed frames on a soft-telecined dvd half of the time comparing to avisynth tfm() filter (I have to use FFDShow for that)?

[QBhd]

For me... on my un-calibrated Plasma (4:2:2) 2Bit Linear (pure power 2.22) is the best... although both 2.4 variations are also very close (sRGB 2.4 is way way off!). Images viewed in MS Paint at a 1:1 pixel zoom

QB

[Shiandow]

I don't really know. My bed is calling, and I'm tired, so I'm not in the condition to really think this through, anymore. Maybe somebody else can figure this out.

You should probably put off reading the following post untill tomorrow. I'll also check if it still makes sense to me after I wake up.

I believe that for Smooth Motion, you should use the same gamma curve for converting to and from linear light:...

I'd argue that smooth motion is done entirely in linear light, how we got there and what we do with the result is entirely irrelevant. Basically smooth motion just tells us the relative brightness of the pixels, to achieve this we need to take into account the monitor's gamma curve. Anyway the following post might make things somewhat clearer (hopefully).

So, basically the chain should look something like this:


Get source
Process source (using the source's gamma curve when needed)
Convert to linear light (using source's gamma curve)
Smooth motion
Apply monitor's gamma curve
Dither
Send to monitor.
Up to smooth motion everything uses the source's gamma curve, smooth motion itself is done in linear light, and then for the output the monitor's gamma curve is used. So far this sounds pretty reasonable.

The only problem is that dithering subtly 'changes' the monitor's gamma curve for the dithered values. This can be solved in three different ways:


Use a shader to correct the values and then dither. This is the method that is used now.
Do the dithering in linear light, this was tried and didn't improve the PQ.
Instead of applying the monitor's gamma curve directly, only use it for the colours that are used as output and linearly interpolate the other values. Let's try this using an example:

Let's say you have a curve which simply tells you how bright a pixel is (from 0 to 1) when the monitor outputs a specific value, for simplicity's sake let's say that the monitor has 2 bits, then it has 4 different values and the gamma curve simply specifies how bright these values are, for instance let's say we measure the outputs: (0.12,0.34,0.56,0.78) for the values (0,1,2,3) respectively. So if we want to output 0.4 then we see that this is 27% of the way between the brightnesses corresponding to 1 and 2 so we output 1.27. Now we can also check that this gives us the correct dithered output. The value 1.27 will be dithered to 2, 27% of the time and to 2 the other 73% of the time, so the resulting brightness is indeed 0.27*0.34 + 0.73*0.56 = 0.4.

And, this realisation may be a bit late :o but isn't this method exactly how the 3DLUT is applied? The main difference is that the 3DLUT is used somewhat incorrectly if you output less than 8 bits. And I guess that some settings (like pure power gamma) don't use this kind of interpolation at all, which they apparently should.

Now I'm not sure where and how the monitor's gamma curve setting is currently applied but it seems that if you do it's done in just the right way and at the right time then the result should be exact and everybody can sleep easy:D

[Mangix]

Recently upgraded to nvidia's latest drivers and felt like testing NNEDI3. Previous versions would just freeze the image. But now I get this:

no NNEDI3: http://i.imgur.com/EHVT37a.png

NNEDI3: http://i.imgur.com/euu4q32.png

slight improvement?

edit: Can you add an if (0) and if (1) support to the profile groups? I want to set up NNEDI3 for when it starts working properly. Since it "kind of" works right now.

edit: how do I use scalingFactor.x/y? I've tried if (scalingFactor) < 2 "blah" but it doesn't work.

[sexus]

same here ,another issue when i play movies i get a display but with green overlay and with image doubling enabled and Error Diffusion i get a black screen , i got the official whql 335.23 drivers as well on a titan gtx , when i switch to another chroma upscaling algorithm the problem disappears, no green overlay, but image doubling with error diffusion gives a black screen with or without NNEDI3 chroma upscaling , so all in all opencl is still broken , fuck , hope someone can fix this , perhaps port NNEDI3 to DirectCompute, since most nvidia users are gona be on the latest drivers exspecially for people that use theyre cards to actually play games as well , hence require the latest drivers to make them work, and something tells me nvidia is NEVER gona fix what theyve broken

[Anime Viewer]

Like other Nvidia users with current drivers I haven't been able to experience NNEDI3's image doubling in the past (usually a black screen occurs when NNEDI3 is enabled, and the screen is maximized). However, I just noticed something I found interesting. :sly: If I set image upscaling to DXVA2 then image doubling using NNEDI3 - NNEDI3 (for image doubling) appears to work correctly. Now if we could just find a work around to get NNEDI3 chroma upscaling to work (I don't expect Nvidia to do anything on their end any time soon).

[Mangix]

same here , but one issue when i play anime mkv files i get a display but with green overlay

Why would you use NNEDI3 for chroma upscaling? That is just useless.

And I just realized that I'm an idiot. That was the chroma information that was present in my screenshot. Setting NNEDI3 to work on both luma and chroma produces no image.

@Anime Viewer: NNEDI3 is incompatible with DXVA2 scaling.

[sexus]

it isnt ive notice quite abit higher detail overall using NNEDI3 x64 chroma upscaling , compared to jinc3 with AR , perhaps my mind is just playing tricks on me , wich would surprise me since ive got very good eyesight, but yeah guys someone has to find a solution we cant expect nvidia to give two shits , sad truth , all they care about is adding more sli profiles that nobody gives a shit about if at all, its as if theyve got a singular 10 year old working on his own in the driver dev department fuckin pathetic

heres an older thread seemingly dead as fuck


https://forums.geforce.com/default/topic/680591/opencl-has-been-broken-since-327-23-drivers-/

[Kalanoch]

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

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

Looking at these test images and ranking in terms of brightness:

pure power 2.4 < pure power 2.22 < sRGB < original < BT.709 2.4 < BT.709 2.22 < Gamma

Pure power 2.4 and 2.22 are almost identical. SRGB is brighter than either pure power and slightly darker than the original but definitely the best match. BT.709 2.4 is slightly brighter than the original, BT.709 2.22 even brighter still, and gamma is so much brighter it is just washed out.

[G_M_C]

madshi can you please repeat the link to the last test-build? Id like to test the ED / dithering versions on my my ISF calibrated panasonic plasma, using my favourite clip (chapter 4 from Samsara, when monks create a Mandala).

[Anime Viewer]

but yeah guys someone has to find a solution we cant expect nvidia to give two shits , sad truth , all they care about is adding more sli profiles that nobody gives a shit about if at all, its as if theyve got a singular 10 year old working on his own in the driver dev department fuckin pathetic

heres an older thread seemingly dead as fuck


https://forums.geforce.com/default/topic/680591/opencl-has-been-broken-since-327-23-drivers-/

Since part of the problem with self patching the driver(s) may be the nvopencl.dll version checking (according to that thread) if we could find someway to edit the version number embedded in the file that might do the trick). Something similar to the way a HEX editor modifies files might work to edit the file.

Here is another article on dll version checking and getting around it:
http://forums.devx.com/showthread.php?75418-Re-Binary-Compatibility-DLL-or-Exe-contains-a-parameter-type-or-return-type-whose-definition-cannot

[Asmodian]

Up to smooth motion everything uses the source's gamma curve, smooth motion itself is done in linear light, and then for the output the monitor's gamma curve is used. So far this sounds pretty reasonable.

I think smooth motion should to use the monitors gamma curve for both into and out of linear light. It cannot use a different gamma for converting from and to gamma light.

I think about it like this:

- I am using a 3DLUT that is expecting to work on gamma light values and I do not want the output of this LUT to be different if I have smooth motion on. This means I need to use the same gamma for into and out of linear light so un-blended frames do not change.
- A blend of frame 1 and frame 2 should look correct on my screen.
- Smooth motion is like dither but only between two points and temporal instead of spatial; the relative brightness of frame 1 and frame 2 is dependent on my monitors gamma.

An exact simulation of 60% frame 1 and 40% frame 2 would need to take into account my display's gamma. Frame 1.4 should not be 60% frame 1 and 40% frame 2 in the source's gamma but in my display's gamma as that is where the apparent ratio will judged.

Now we need a way to specify our display's gamma for all gamma->linear->gamma conversions used in madVR. ;)

Or, given that smooth motion looks great, we could simply stick with the current pure power 2.22. :)

I am starting to think that a curve without any linear section should be used. I like zoyd's suggestion of a "default" BT.1886 because it doesn't have a linear section but it also has a way to avoid crushed blacks. Maybe use that for smooth motion too. :D

I do agree when talking about this small of an improvement we should target reasonably good displays, at least we should not worry about achieving ideal results on a 6-bit TN.

[Audionut]

I hear you. But there are serious problems. There are multiple different situations:

Most of these situations, imo, should just have a blanket default applied. Whatever one you decide.



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

Guessing is fine. If the user is not interested in taking some control over calibration, then the user probably doesn't care either way. If the user cares enough, then the user should take appropriate actions.


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

Don't ask the user anything. Here, the user has made half an attempt at proper calibration, so half an attempt to apply the correct transfer function is appropriate. Here, I would apply the (any) transfer function in a background task.



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

Here, the user is making a significant effort to ensure correct display response, so here, madVR should make a significant attempt to apply the correct transfer function. Or at least, allow the user to specify the correct transfer function.

Can the correct transfer function be determined during 3dlut calibration?
Wouldn't the transfer function be determined by the calibration itself? In which case, the dithering should be done on the transfer function of the calibrated display.

Either way, isn't this a case of using the report on calibrated/uncalibrated display in dispcal?

edit: Noticed your response on the last page. Still, should be easy for the user to get the correct results.


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

Apply blanket transfer function, and warn the user that this is not optimal. A user who has gone to the effort of creating a 3dlut, is probably going to be interested in ensuring optimal results. The warning will imply that further investigation is required.



I think you can see how achieving perfection would be a usability nightmare!

IMO, you're giving to much consideration to the lowest common denominator.
I use madVR, because afaik, it provides the most accurate rendering. Applying a blanket transfer function, does not imply, accuracy.

From a usability standpoint, as a power user, the more input I have as a user, the better. I understand that not everyone is interested in specifying a thousand options, and for this we have blanket cases.

edit: I've just made the switch to win8, and I haven't calibrated the display apart from some basic adjustments in the display itself. BT.709 (2.2) is almost an exact match for the original here. The only (significant) difference looks to be the dither pattern. It appears to be slightly darker then the original, this makes sense afaik, since my uncalibrated gamma is 1.92.

[Asmodian]

Somehow the "this display is calibrated to the following transfer function / gamma:" entry on the calibration tab seems like a great source of this information without adding more controls/options. Of course it would need more preset curves in it, sRGB, a few BT.1886s, and maybe even linear. It would also need moving to allow it to be set when other calibrations are set. Maybe a "my display's calibration is best approximated by the following transfer function / gamma:" on the calibration page. :devil:

Edit: madVR would still need to ask for two ideally, the after calibration gamma for smooth motion and dither in FSE or windowed and the native gamma for dither in overlay or when using a 3DLUT with linear ramps. It would be possible to always ask for them both and use each as needed but weather or not it would be worth it I cannot say. :)

[Farfie]

Can I get philosophical for a second, madshi?

I think we need to remember our roots for a moment. Most of us are here because we didn't think VLC was a good media player. You also probably made madVR because you couldn't find a video renderer to do what you want. You probably thought that the current iterations were absolutely terrible in fact, and that it practically needed to be done. If you would have found a madvr like program, would you have still made madvr?

What I'm getting at is that we're here to be... well, advanced users. I'm not saying you should do bt1886 and require craploads of user input, but what I'm seeing from you right now is like a company that is suddenly going viral with their advanced program, and next year it has turned into something just like every other program because it meets average expectations. If average expectations we're what we wanted, we'd all go back to VLC and turn on bicubic resizing. No scratch that, we wouldn't even look at the options - we would just install and use it.

So my opinion is that: it's fine to have a blanket solution for things, but you should NOT actually go for the average here, you should go for above average users in your design philosophy. Here's why:
1. Everyone here will appreciate it more.
2. Even though it's not the average, quite a few people already have nice monitors, and these are going to be the people that actually care about having software designed with them in mind. Also, OLED will be mass market eventually, and it's already starting. 2 years isn't that long. Why develop without the future in mind now? Isn't that another good reason why we're here? Again, if we want to stagnate, let's reinstall VLC.
3. These users with "average" monitors aren't going to care about whether or not they're being blanketed with pure power curve or any transfer function. If they care about picture quality, they would read the thread, buy a nice monitor, and calibrate it themselves. And at that point, they could still rest easy that madVR was being designed for them, and not the average!

Hope this made sense, just don't want to see you turn this software more and more away from what I think is the roots of open source software that is supposed to be bleeding edge. I mean, I guess I could be assuming all of this, but whatever. I'm about to sleep as well, but I believe I have good intentions in this post.

And yeah, the pure power curve should be 2.4 instead of 2.2, change my vote :)

[Ver Greeneyes]

I would like to add that although I will happily theorize about theoretically optimal solutions, I can't see any difference between linear and gamma light dithering in 8-bit mode*. I'd like madVR to be as accurate as possible and I like fiddling with settings, but I can only hope that every little thing ends up adding together to make the experience better, because individually I can't tell the difference anyway :P

* at least, using 8-bit source material. I can see a difference using my test patterns, but only very close to black, so I'm inclined to say that doesn't count.

[James Freeman]

The de-facto standard broadcast monitor gamma is 2.22 in US, or 2.35 in EU.
Most if not all movies are mastered on a proper (high-$) broadcast monitors (most of them OLED by now) with ideal pure power curve.
Like These: Pro SONY Broadcast/Mastering monitors (http://pro.sony.com/bbsc/ssr/cat-monitors/cat-oledmonitors/)
Or This: TVLogic Mastering Monitor (http://www.tvlogicusa.com/product/product.php?model=LEM-250A)
Or This: FSI Broadcast/Mastering Monitor (http://www.shopfsi.com/CM250-p/cm250.htm)

Great article about gamma and calibration: Here (http://www.negativespaces.com/blog/2013/5/12/recommendations-for-display-gamma.html)

Rec.709 is out of the question, it should not be used anywhere besides encoding.
sRGB will compensate for the crushed blacks (elevate them). It may be OK for the Internet, Picture Editing and OS use, but it too much for movie
watching because it elevates the blacks to be perfectly visible where most of the noise is in compressed video and video cameras.
BT.1886 is a compensating algorithm that gets more like pure power curve as the CR grows.

IMO, future consumer displays with huge/endless CR like OLED will not be calibrated to anything but Pure Power Curve standard.
Why would they calibrate to anything that elevates the blacks?

Considering the fact that Movies & Television are mastered on an ideal power curve (2.2-2.4) Mastering Monitors,
and most consumer displays (TV's and Monitors) calibrated to a gamma of 2.2-2.4 (yes, with Black Compensation but nowhere near BT.1886, and definitely not to rec.709).

I may be mistaken but we should go for a non compensating Standard.
Or simply Pure Power 1/0.45.

As I understand, every monitor has a difference Black Offset (Black Compensation) so every user will choose what fits his display,
The question is whether the users display is over compensating the blacks thus making them choose the over bright BT.709 or Gamma Light,
or calibrates his display device that way on purpose to brighten the dark shades to suit his environment.

I think we should go for a SOLID Standard (BT.1886 is not solid, its display dependent) which everybody should conform to regardless of personal choice, factory/user calibration, or current display capabilities.
That Standard is what the movie/tv studios master their content on, and its probably pure Power Curve (no Black Compensation) of 2.2 or 2.4 on an OLED Broadcast Monitor.

[6233638]

The de-facto standard broadcast monitor gamma is 2.22 in US, or 2.35 in EU.CRT monitors all measured ~2.4
OLED monitors are 2.4
The projectors used in production are all 2.4

The only monitors which were set to 2.2 were LCD monitors, which barely anyone uses, because they are so low contrast.
Barco's LCDs were calibrated to 2.35 out of the box.

2.2 gamma has basically not been used in production on main mastering monitors.
This is why the BT.1886 target is ultimately 2.40 gamma on an ideal display
IMO, future consumer displays with huge/endless CR like OLED will not be calibrated to anything but Pure Power Curve standard.
Why would they calibrate to anything that elevates the blacks?This is already true of full array local dimming LED and Plasma. We now have OLEDs on the market and their price continues to drop.

[markanini]

Can I get philosophical for a second, madshi?

I think we need to remember our roots for a moment. Most of us are here because we didn't think VLC was a good media player. You also probably made madVR because you couldn't find a video renderer to do what you want. You probably thought that the current iterations were absolutely terrible in fact, and that it practically needed to be done. If you would have found a madvr like program, would you have still made madvr?

What I'm getting at is that we're here to be... well, advanced users. I'm not saying you should do bt1886 and require craploads of user input, but what I'm seeing from you right now is like a company that is suddenly going viral with their advanced program, and next year it has turned into something just like every other program because it meets average expectations. If average expectations we're what we wanted, we'd all go back to VLC and turn on bicubic resizing. No scratch that, we wouldn't even look at the options - we would just install and use it.

So my opinion is that: it's fine to have a blanket solution for things, but you should NOT actually go for the average here, you should go for above average users in your design philosophy. Here's why:
1. Everyone here will appreciate it more.
2. Even though it's not the average, quite a few people already have nice monitors, and these are going to be the people that actually care about having software designed with them in mind. Also, OLED will be mass market eventually, and it's already starting. 2 years isn't that long. Why develop without the future in mind now? Isn't that another good reason why we're here? Again, if we want to stagnate, let's reinstall VLC.
3. These users with "average" monitors aren't going to care about whether or not they're being blanketed with pure power curve or any transfer function. If they care about picture quality, they would read the thread, buy a nice monitor, and calibrate it themselves. And at that point, they could still rest easy that madVR was being designed for them, and not the average!

Hope this made sense, just don't want to see you turn this software more and more away from what I think is the roots of open source software that is supposed to be bleeding edge. I mean, I guess I could be assuming all of this, but whatever. I'm about to sleep as well, but I believe I have good intentions in this post.

And yeah, the pure power curve should be 2.4 instead of 2.2, change my vote :)

Dude, were're talking about differences which have a small chance of being visible on low-end displays, smaller still on higher end.

[James Freeman]

CRT monitors all measured ~2.4
OLED monitors are 2.4
The projectors used in production are all 2.4

The only monitors which were set to 2.2 were LCD monitors, which barely anyone uses, because they are so low contrast.
Barco's LCDs were calibrated to 2.35 out of the box.

2.2 gamma has basically not been used in production on main mastering monitors.
This is why the BT.1886 target is ultimately 2.40 gamma on an ideal display


Old CRT broadcast monitors are around 2.4,
OLED Broadcast Monitors can be set to any gamma curve, but 2.4 or 2.2 is the default.
Its the choice of the studio to master to whatever gamma they want, and most likely its 2.4 or 2.2 power curve.
This Mastered content is expected to be viewed on the same equipment or calibrated to the same Standard to get the same picture.

Its exactly the same with Audio (having a home studio myself), Flat Studio Monitors (speakers) will give you exactly what the audio engineer Mixed/Mastered the music on.
Regardless if you use crappy old PC speakers, or 20,000$ Boutique stereo system, to get the same signal you have to conform to a standard.

If most of the content is mastered on an ideal 2.4 power curve CRT/OLED Mastering monitors, we should probably conform to that, regardless of our current displays.

[web2312]

Hi,
I was testing dithering algorithms in 1-bit mode using the lastest test build.
I found the viewing angle of my sony lcd tv (VA panel) was a lot improved when dithering in 1-bit mode, which is amazing!
(No VA off-centre gamma shift)

By the way, i can see the dithering patterns (looks like horizontal lines) with dynamic ED1. Is it expected?
(Somewhat like this - http://i.imgur.com/DkEFVE7.jpg)

When using dynamic ordered dithering, there are still occasional flickers happened with 60fps test clips.


Steps to reproduce

1. Download the test image below and put it under C:\
http://www.lagom.nl/lcd-test/img/blacktest.png

2. Create an empty *.avs (AviSynth Script), paste the following then save.

ImageSource("C:\blacktest.png", end = 6000000, fps = 60)

3. Use mpc-hc to play the *.avs.



Sorry for my english. It's not my native language.

Thanks :)

[Ver Greeneyes]

By the way, i can see the dithering patterns (looks like horizontal lines) with dynamic ED1. Is it expected?
(Somewhat like this - http://i.imgur.com/DkEFVE7.jpg)I wouldn't say it's expected, but I noticed it before in 4-bit mode. It's impossible to spot in 8-bit mode though and only happens near black (of course, very low bitdepth modes are always 'near black' since they don't have a lot of values to work with) so I told madshi not to worry about it. Still, perhaps he could more easily figure out what's causing it now that we have down to 1-bit available.

[madshi]

Tagging silver discs is out of the question and sometimes you don't know that a movie comes with the chipmunk disease before you open it, so an on-the-fly temporary option would really hit the spot IMO :)
Well, at this point I don't want to add this. The settings are not set in stone yet. Some things will change, and maybe profiles will come to your rescue sooner or later.

Is it okay for madVR's IVTC (deint = film mode) to match wrong fields and show combed frames on a soft-telecined dvd half of the time comparing to avisynth tfm() filter (I have to use FFDShow for that)?
No, that's definitely not ok. Can I get a sample of that DVD, please?

Can you add an if (0) and if (1) support to the profile groups? I want to set up NNEDI3 for when it starts working properly. Since it "kind of" works right now.
You can use a dummy expression like "if (srcWidth < 1)" or "if (srcWidth > 0)" to simulate "if (0)" and "if (1)". I guess I could add support for "if (0)" etc, too, but I'm kinda busy with other stuff atm...

edit: how do I use scalingFactor.x/y? I've tried if (scalingFactor) < 2 "blah" but it doesn't work.
You need to explicitly use either "scalingFactor.x" or "scalingFactor.y". They're different values, so if you just use "scalingFactor", madVR does not know how to interpret that.

madshi can you please repeat the link to the last test-build?
http://madshi.net/madVRlinearLightDither2.rar

Now we need a way to specify our display's gamma for all gamma->linear->gamma conversions used in madVR. ;)

Or, given that smooth motion looks great, we could simply stick with the current pure power 2.22. :)
Haha!

I found the viewing angle of my sony lcd tv (VA panel) was a lot improved when dithering in 1-bit mode, which is amazing!
(No VA off-centre gamma shift)
Haha, that is funny!

By the way, i can see the dithering patterns (looks like horizontal lines) with dynamic ED1. Is it expected?
(Somewhat like this - http://i.imgur.com/DkEFVE7.jpg)

When using dynamic ordered dithering, there are still occasional flickers happened with 60fps test clips.
At 1-2 bits some horizontal (and maybe also vertical) lines with error diffusion are to be expected, because error diffusion is performed in 16x16 sized pixel blocks (the error isn't spread outside of those blocks), and the algorithms cannot fully hide that fact. This should not be a problem at reasonably high bitdepths, though. I already cannot see this at 3 bit, anymore. Which is one of the reasons I was avoiding offering 1-2 bits at first.

I can't reproduce the flickering with the 60fps AviSynth script here. Works fine here without any flickering. I guess the flickering might occur when a frame is stopped/repeated.


Here, the user is making a significant effort to ensure correct display response, so here, madVR should make a significant attempt to apply the correct transfer function. Or at least, allow the user to specify the correct transfer function.

Can the correct transfer function be determined during 3dlut calibration?
Wouldn't the transfer function be determined by the calibration itself? In which case, the dithering should be done on the transfer function of the calibrated display.

Either way, isn't this a case of using the report on calibrated/uncalibrated display in dispcal?
I'd need to know the transfer function of the display *without* 3dlut processing. If the display was not calibrated externally at all, it might not actually follow any specific transfer function, but have a totally "wild" behaviour. In any case, there's a good chance the user doesn't know this. And the 3dlut doesn't contain this information.

Somehow the "this display is calibrated to the following transfer function / gamma:" entry on the calibration tab seems like a great source of this information without adding more controls/options. Of course it would need more preset curves in it, sRGB, a few BT.1886s, and maybe even linear. It would also need moving to allow it to be set when other calibrations are set. Maybe a "my display's calibration is best approximated by the following transfer function / gamma:" on the calibration page. :devil:

Edit: madVR would still need to ask for two ideally, the after calibration gamma for smooth motion and dither in FSE or windowed and the native gamma for dither in overlay or when using a 3DLUT with linear ramps. It would be possible to always ask for them both and use each as needed but weather or not it would be worth it I cannot say. :)
Do you see what you're asking for? There are already many changes to the settings dialog you're suggesting. Which means usability will suffer.

Can I get philosophical for a second, madshi?

I think we need to remember our roots for a moment. Most of us are here because we didn't think VLC was a good media player. You also probably made madVR because you couldn't find a video renderer to do what you want. You probably thought that the current iterations were absolutely terrible in fact, and that it practically needed to be done. If you would have found a madvr like program, would you have still made madvr?

What I'm getting at is that we're here to be... well, advanced users. I'm not saying you should do bt1886 and require craploads of user input, but what I'm seeing from you right now is like a company that is suddenly going viral with their advanced program, and next year it has turned into something just like every other program because it meets average expectations. If average expectations we're what we wanted, we'd all go back to VLC and turn on bicubic resizing. No scratch that, we wouldn't even look at the options - we would just install and use it.

So my opinion is that: it's fine to have a blanket solution for things, but you should NOT actually go for the average here, you should go for above average users in your design philosophy. Here's why:
1. Everyone here will appreciate it more.
2. Even though it's not the average, quite a few people already have nice monitors, and these are going to be the people that actually care about having software designed with them in mind. Also, OLED will be mass market eventually, and it's already starting. 2 years isn't that long. Why develop without the future in mind now? Isn't that another good reason why we're here? Again, if we want to stagnate, let's reinstall VLC.
3. These users with "average" monitors aren't going to care about whether or not they're being blanketed with pure power curve or any transfer function. If they care about picture quality, they would read the thread, buy a nice monitor, and calibrate it themselves. And at that point, they could still rest easy that madVR was being designed for them, and not the average!

Hope this made sense, just don't want to see you turn this software more and more away from what I think is the roots of open source software that is supposed to be bleeding edge. I mean, I guess I could be assuming all of this, but whatever. I'm about to sleep as well, but I believe I have good intentions in this post.
IMO, you're giving to much consideration to the lowest common denominator.
I use madVR, because afaik, it provides the most accurate rendering. Applying a blanket transfer function, does not imply, accuracy.
I do sympathize with your general sentiment. However, I think I need to put this a bit into perspective:

AFAIK, before madVR existed, nobody in the HTPC world used dithering *at all* for video. madVR introduced this concept. And still today, I believe most consumer electronics devices don't use dithering. The Lumagen Radiance is the only exception I know, and it applies simple random dithering. Even the eeColor calibration box does *not* do dithering at all. Practically this means even the simplest and most ugly form of dithering is already significantly better than what you'd get by using typical consumer electronics devices.

Skip forward to v0.87.6 and not only do you get simple random dithering, but you get dynamic ordered dithering with a specially optimized 32x32 dither pattern. You also get error diffusion which to my best knowledge nobody else on this planet is using for video playback. And you don't just get normal Floyd-Steinberg error diffusion with its worm artifacts, but you get specially optimized algorithms which totally get rid of worm artifacts and which still keep noise down nicely etc. And you get "colored noise" which is a special algorithm to reduce luma noise. And you get dynamic error diffusion which is also something nobody else uses, AFAIK. So basically the dithering algorithms you get in v0.87.6 are already miles ahead of every other video playback product.

Now we're talking about linear light dithering, which is another improvement over what v0.87.6 already offers. It's a concept I've rarely seen addressed on the internet yet. So basically we're not resting on what is already better than what everybody else uses, but we continue chasing the best possible solution, which is good.

But here comes the catch: With real video content in many scenes many users already see no difference with dither turned on/off. And that difference is much bigger than the difference between random dithering and error diffusion. And that difference again is much bigger than the difference between gamma light error diffusion and linear light error diffusion. And that difference again is much bigger than the difference between various linear light error diffusion curves. Basically every step we take increases image quality by a much smaller amount than the previous step. So we're really talking about incredibly small differences here, especially at 8bit. So forgive me if I'm not willing to buy a 0.000000000000000001% quality improvement with a lot of extra development time, a more complicated settings dialog and the average user becoming confused by all the weird options. Usability is important to me, too.

-------

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.

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?

[madshi]

I believe that for Smooth Motion, you should use the same gamma curve for converting to and from linear light:
Say you are blending together two identical frames. Then you effectively convert color A to linear light and then convert it back to gamma light. However, if you use a different curve to convert back to gamma light, you will change the color. Furthermore, if your refresh rate is high enough to display the frame without blending also (e.g. perfect 24p at 60 Hz), you will have color B (which is color A after blending) and then untouched color A for the exact same image.
Further, I believe (but I'm not too confident about this) that using the source gamma for Smooth Motion should be correct, because Smooth Motion is applied before any 3D LUT or Gamma correction. So to say, SM is done in "Source RGB" while Dithering is done in "Target RGB", so SM should use "Source Gamma" while Dithering should use "Target Gamma".
What you say is logical and matches my own original thoughts, but after thinking about it more, I think it might not be correct. See below.

I'd argue that smooth motion is done entirely in linear light, how we got there and what we do with the result is entirely irrelevant. Basically smooth motion just tells us the relative brightness of the pixels, to achieve this we need to take into account the monitor's gamma curve. Anyway the following post might make things somewhat clearer (hopefully).

So, basically the chain should look something like this:


Get source
Process source (using the source's gamma curve when needed)
Convert to linear light (using source's gamma curve)
Smooth motion
Apply monitor's gamma curve
Dither
Send to monitor.
Up to smooth motion everything uses the source's gamma curve, smooth motion itself is done in linear light, and then for the output the monitor's gamma curve is used. So far this sounds pretty reasonable.
It sounds reasonable, but then it sounds weird to use two different gamma curves for converting gamma -> linear and then linear -> gamma. Does that mean you're changing the overall gamma response of the video frame? That sounds wrong.

Instead of applying the monitor's gamma curve directly, only use it for the colours that are used as output and linearly interpolate the other values.
But what are "colors that are used as output"? Where would I get them from? I don't really understand how such an algorithm would work, or where I would get the colors from etc...

Now I'm not sure where and how the monitor's gamma curve setting is currently applied but it seems that if you do it's done in just the right way and at the right time then the result should be exact and everybody can sleep easy:D
The monitor's gamma curve is currently applied by the monitor itself. When no processing needs to be done, basically madVR simply passes through a possible RGB source to the display untouched. So it's the display itself which applies the display's gamma curve. But I'm not sure if that's what you mean?

-------

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.

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.