madVR - high quality video renderer (GPU assisted)

[secvensor]

So I continued use the FSE 'Old Path' then.

[bacondither]

Aaaarrrrgggghhhh!.. Rum shortage? :sly:

@madshi
Could you please set the psuedo linear light gamma target(return pow(x,1/0.45)) using the "the displays is calibrated to the following transfer function / gamma:", in the next dither "addictive" build.

[James Freeman]

Rum shortage? :sly:

Shiver me timbers!
Never had meself a drop in me life. :D


@madshi
Could you please set the psuedo linear light gamma target(return pow(x,1/0.45)) using the "the displays is calibrated to the following transfer function / gamma:", in the next dither "addictive" build.

Can you please explain what do you mean?
Do you mean that when nothing (or 3DLUT) is selected LL is active, but when "the displays is calibrated to the following transfer function / gamma:" is selected Gamma Light is back?
Why pseudo?

[bacondither]

Can you please explain what do you mean?

As Shiandow said earlier, you want to set the psuedo linear light algorithm to use the same gamma as your displays decoding gamma.

A knob somewhere in the dithering settings dialog mabe would be better.

[Shiandow]

I believe the error should be calculated in linear light.

An example: a bright pixel wants a value of 230.4 in gamma light and the error is moved to a dark pixel with a value of 18.9 in gamma light.

If everything is done in gamma light the 18.9 becomes 19.3
If the error is calculated and added in linear light the 18.9 becomes 19.02055 in gamma light.
This is why gamma light dithering looks brighter; this is effect is bit depth independent, it is only more obvious at lower bit depths because the relative errors are higher.

It doesn't quite work that way. The method that is now used doesn't diffuse errors in linear light, and if it would then you're using the wrong exponent. The way it currently works is more or less as follows:

The value 18.9 is reinterpreted as the colour that is 9/10 of the way between 18 and 19. But this should be interpreted as 9/10 of the way in linear light, which means we can't simply dither 90% of the pixels to 18 and the other 10% to 19. To fix this we can simply modify the .9 to whatever percentage it should be. Assuming a gamma of 2.2 this should be:

(18.9^2.2 - 18.0^2.2)/(19^2.2 - 18^2.2) = 0.897

So we change the value to 18.897 to trick the dithering algorithm to round the correct percentage of pixels up or down. What this does not do is diffuse the error in linear light, this is partially because this requires more effort, but I'm also pretty sure that it will look wrong. Diffusing error in linear light would assume that a small error near white would be far more noticeable then one near black, which isn't true.

[James Freeman]

As Shiandow said earlier, you want to set the psuedo linear light algorithm to use the same gamma as your displays decoding gamma.

Oh, OK. Thanks.
I guess not everybody's calibrated to 2.20.
I think "The displays is calibrated to the following transfer function / gamma:" is not a good option because many use 3DLUT that they will want to keep.
A knob somewhere in the dithering settings dialog maybe would be better.
Good idea.

It doesn't quite work that way. I doesn't diffuse errors in linear light.
Thanks.

[StinDaWg]

I'm having a problem with the refresh rate switcher and interlaced content. If I play a 1080i29 file it will start at 59hz with video deinterlacing. If I hit a shortcut key to switch to film deinterlacing the video will pause and change to 23hz (actually changes to 24hz but I think that's a bug as mentioned before), but more than half of the time the audio will keep playing but there will be no video, just a black screen. The only way to get out is to force close, a little box shows up saying MPC-HC has crashed. This is kind of a big problem for me because I have a ton of 1080i videos and about half need film mode deinterlacing.

[huhn]

I'm having a problem with the refresh rate switcher and interlaced content. If I play a 1080i29 file it will start at 59hz with video deinterlacing. If I hit a shortcut key to switch to film deinterlacing the video will pause and change to 23hz (actually changes to 24hz but I think that's a bug as mentioned before), but more than half of the time the audio will keep playing but there will be no video, just a black screen. The only way to get out is to force close, a little box shows up saying MPC-HC has crashed. This is kind of a big problem for me because I have a ton of 1080i videos and about half need film mode deinterlacing.

http://bugs.madshi.net/view.php?id=171 :-)

[Shiandow]

I think "The displays is calibrated to the following transfer function / gamma:" is not a good option because many use 3DLUT that they will want to keep.

The Linear Light processing/dithering is after the 3DLUT has been applied. Using the display gamma curve should be correct, although it really shouldn't matter much if the gamma curve you're using is slightly wrong. The only part that is still somewhat worrisome is whether screens actually use an sRGB gamma curve (with a linear part near black) or if they have a pure power gamma curve, as far as I can tell is should be the latter but I'm not sure.

@madshi
On a somewhat unrelated note, apparently I made a mistake in which colours are not dithered. The 'depth' value that I used in the shader should be 2^k-1 not 2^k (where k is the bitdepth). Not sure if this is already fixed, but if not then it might have some odd consequences. Also, for some reason a value of 1.0/7.0 is still dithered slightly in 3bit if you use ordered dithering or ED1, not sure if this is just rounding errors or something different.

[James Freeman]

Shiandow,

Selecting "This display is already calibrated" removes the 3DLUT.
That's why the displays gamma curve for this LL dithering method should be selected elsewhere.

Can you please repost you shader (HLSL right?).
This shader should be used with the Gamma Light build (87.6), not the LL build madshi posted correct?

EDIT:
I found the shader code in page 1213.
With power of 1 (or disabled), it looks just like the untouched Gamma Light 87.6 build.
With power of 2.2 (my display calibration gamma) it looks much better and closer to the original, but a little dark in 5-bit and lower.

I'm still doing some testing.
I'll try to find the most balanced power value from 5 to 8 bit.

[Shiandow]

Shiandow,

Selecting "This display is already calibrated" removes the 3DLUT.
That's why the displays gamma curve for this LL dithering method should be selected elsewhere.

Oh I see, that sort of makes sense, but it becomes somewhat impossible to modify the shader such that it takes into account a 3DLUT as well.

Anyway here's a fixed version of the shader:


#define depth (pow(2,8)-1)
sampler s0 : register(s0);

float4 f(float4 x) { return pow(x,1/0.45); }

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
float4 low = floor(depth*c0)/depth;
float4 hi = ceil (depth*c0)/depth;
float4 c1 = (f(c0)-f(low))/(f(hi)-f(low));
return (low+(c1/depth));
}

for a different bitdepth k just change "pow(2,8)-1" to "pow(2,k)-1".

Edit: For an sRGB gamma curve you can just redefine the function 'f' to:


float4 f(float4 x)
{
return lerp(x/12.92, pow((x+0.055)/1.055,2.4),saturate(100000*(x-0.03928)));
}


It uses a bit of an hack to avoid having to deal with if statements, but it should work and it removes the discontinuity.

[James Freeman]

Oh I see, that sort of makes sense, but it becomes somewhat impossible to modify the shader such that it takes into account a 3DLUT as well.

Thanks for reposting the fixed code.

Aren't the pixel shaders are after the 3DLUT?

[Ver Greeneyes]

Maybe Ver Greeneyes could make some 16bit fullscreen color patches (with a key for the source 16bit RGB values encoded), which all fall on fractional random 8bit color values near-black, near-white, and midtones. It would be very simple at that point to see what's going on objectively. Take screenshot with gamma dither and linear dither in 8bit mode, open in Photoshop, take an average sample over a large surface area, and see which ends up closer to the expected 16bit color value from the key.So you want some patches of a single 16-bit color that's in between two 8-bit values? I don't think that would work, because photoshop would take the gamma light average value, so gamma light would always perform better. You'd have to transform to linear light in photoshop before measuring the average, and that depends on what gamma curve you choose. As long as we disagree with madshi on what curve to use (though I'm not sure madshi has said either way what he's using now) we're not going to see the average reflect the value that linear light ED was aiming for. At the same time, LL might still look better to our eyes since it's perceptually closer to linear.

It's a bit muddy either way because dithering happens after all other processing including 3DLUTs, so the gamma you're aiming for is the native gamma of your display - unless you have a videoLUT active. So for perceptual uniformity, you either want madVR to invert the native gamma of your display (e.g. via lookup table), or if you have a videoLUT active you want it to invert the specific curve you were aiming for in calibration (which is mathematically defined, but a lookup table might still be faster). It could be done, but it sounds complicated. So unless we go to those lengths, the question is: what curve is closest to the average gamma that displays use? I'd say that's probably going to be sRGB (see here (http://forum.doom9.org/showthread.php?p=1668426#post1668426)) or the effective gamma of sRGB (x^2.233337), because that's what most consumer hardware aims for, but I can't back that up with empirical data.

[Shiandow]

Aren't the pixel shaders are after the 3DLUT?

They should be, but what I meant was that in theory you should use the gamma curve defined by the 3DLUT. I can't think of an easy way to do this.

[James Freeman]

The following post is extremely important.

I have done some testing (lower bit depth) and found that Linear Light works (makes the gamma curve look good) only with Static dithering (or screenshots).
With Dynamic dithering & LL the picture becomes extremely dark.
On the other hand Gamma light (Standard 87.6 build) is perfect for Dynamic mode (looks like the original 8-bit).

To test this yourself you can select dynamic dithering mode ("change dithering for every frame") and Ordered Dithering.
Pause the video and hold the down button (volume) to refresh the screen and simulate dynamic dithering without changing the picture.

LL looks perfect for Static images.
But it's an absolute No-No for Dynamic dithering which most of the users use.

[Ver Greeneyes]

For Dynamic dithering the picture becomes extremely dark.
On the other hand Gamma light (Standard 87.6 build) is just right for Dynamic mode.I don't see anything like this, even in 3-bit mode.

To test this yourself you can select dynamic dithering mode, pause the video and hold the down button (volume) to refresh the screen and simulate dynamic dithering without changing the picture.I don't see this changing the dithering pattern in MPC-HC. I wouldn't really expect it to, either, since I thought it was based on the frame number.

[James Freeman]

Are you sure?
You have to select "change dithering for every frame" for dynamic mode.
For me every mouse wheel roll is different dithering pattern when paused.

EDIT:
OK, in Ordered Dithering Mode.
With ED the image does not move using this trick, BUT it immediately gets darker when the playback starts (Dithering starts to move).
So the problem with LL remains for Dynamic mode in playback with any of the dithering methods.

[Shiandow]

I have done some testing (lower bit depth) and found that Linear Light works (makes the gamma curve look good) only with Static dithering (or screenshots).
With Dynamic dithering & LL the picture becomes extremely dark.
On the other hand Gamma light (Standard 87.6 build) is perfect for Dynamic mode (looks like the original 8-bit).

As far as I know that effect is caused by the response time of your screen, it is the same reason that 'blinking' occurs. Unfortunately it is somewhat difficult to tell if this also happens with 8 bit, and to what degree. It probably doesn't happen on CRTs and projectors, or screens that have a very low response time. Also, madVR doesn't change the pattern for every vsync, so the effect should be less obvious than if you use a trick to change it every frame.

[James Freeman]

Shiandow that's not what I'm trying to convey.

The image gets even darker in Dynamic mode when the dithering is random and not static.
I really want you to acknowledge this because the difference of LL build with Dynamic vs Static is huge.

Pause the video, stretch MPC-HC to the right side of the screen (drag all the way to the right [Win7]),
Take a screenshot in 8bit and put it on the left side of the screen in MS paint.
Now you have two same images side by side, one in Paint one in MPC-HC.
Now you can play with the Dithering, Bit depth and really compare LL vs GL.

[6233638]

So unless we go to those lengths, the question is: what curve is closest to the average gamma that displays use? I'd say that's probably going to be sRGB (see here (http://forum.doom9.org/showthread.php?p=1668426#post1668426)) or the effective gamma of sRGB (x^2.233337), because that's what most consumer hardware aims for, but I can't back that up with empirical data.Very few consumer displays are even close to having a flat gamma response, and are typically using an s-curve gamma.
Some of the better monitors will be calibrated to ~2.22 gamma (1/0.45) as that's what is used on the desktop.
Displays which are properly calibrated for viewing films should be at or close to 2.4 gamma. (BT.1886)

In theory madVR should already know what your display's response is, and should assume 2.2 gamma if it has not been set.

[Ver Greeneyes]

In theory madVR should already know what your display's response is, and should assume 2.2 gamma if it has not been set.Yeah, actually I would somewhat expect the curve from "enable gamma processing" in the color & gamma section to be used for the linear transform that ED uses - but I'm not sure what that option even does. For instance I'm using a videoLUT (yes I know, 8-bit and all that) that calibrates my monitor to the BT.709 curve, and setting "enable gamma processing" to that curve seems to make video a bit darker. But I'm also using a 3DLUT for the profiling side, so should I be using "enable gamma processing" or would that apply the gamma twice? (there's also the equivalent option if you use "this display is already calibrated", and I assume that would cause it to be applied twice)

Edit: I guess it makes sense that the 3DLUT should apply the Rec.709-to-whatever-the-display-gamma-is conversion. You could probably get a good approximation by just taking the 256 points in the 3DLUT where R=G=B, then inverting that for conversion to Rec.709 (then from Rec.709 to linear RGB). Store that as a lookup table and use it during dithering (again probably too complicated to bother, but still).

[Shiandow]

Shiandow that's not what I'm trying to convey.

The image gets even darker in Dynamic mode when the dithering is random and not static.
I really want you to acknowledge this because the difference of LL build with Dynamic vs Static is huge.


I have no doubt that what you observed actually happened, it happens on my screen as well. But at this point I don't know if it also happens when the output is 8 bit and if it is merely a coincidence that it seems to 'correct' the gamma curve or if this is always the case.

[madshi]

Unfortunately you're right, it doesn't change anything. I noticed that other users are on Windows 8.1, I'm on Windows 8. Maybe it comes from there but I don't really want to install 8.1, some video games are not compatible with it...
My hook/hack should in theory also work in Windows 8, not sure why it's not working for you.

From the 3 times I observed it this afternoon before downgrading to 87.4, cpu ram was 600mb, 800mb, 400mb. When the cpu ram was highest, zoomplayer's crash was worse and required task manger to end process. Otherwise with the lower spikes I could 'esc' back to windowed mode and then click the zoomplayer 'x' to close it after it settled its self down. The video appears to still continue playing, audio can still be heard. I can click the screen once it goes black and playback will pause as normal and then resume with another click. No madvr crash reporter pops up, nor does zplayer crash window. Just a screen that goes black during playback, apparently at random.

This black screen, and very occasional white screen has never happened before in all my years of using zoomplayer and madvr.

With 0.87.4 this does not occur.
:(

How about the new test build (see bottom of this post)? Does the problem still occur with that build?

When it crashes, MPC-HC will open up, initialize a black screen with the correct video size, then madVR pops up the "Please wait a moment..." box and starts working, then everything stops and gets grayed out as windows gives me the standard "MPC-HC has stopped working" crash dialog. The audio starts playing for a split second before it crashes, also. Sometimes I can very briefly see the OSD before the crash, but usually not.

In any case, the test build you provided fixed the issue, including resizing/fullscreen windowed overlay. Also, the problem is being caused by my dual monitor setup, because I did some more testing with 0.87.6 and found that if I remove my second monitor I have no issues. Since I'm surely not the only person running madVR and dual monitors, perhaps it has something to do with my weird resolutions? (2560x1600 on primary and 1920x1200 on secondary)
Good to hear that this is fixed with the test build. The fix for this will be included in the next official build.

More test result:

(doubling neurons/quadrupling neurons)

[...]
Interesting! I like 64/32 and 128/32. Looks like going with 16 neurons for the quadrupling pass doesn't help much over using 32 neurons. However, this is with the 290X. With a slower GPU it might be different...

madshi, is madVR still using the "settings.bin" file or is it now working exclusively with the registry?
The settings are saved to both the registry and to settings.bin. When reading the settings, both registry and settings.bin are looked at, and whatever is newer is used. That will usually be the registry, but it doesn't have to be.

Do many people use Jinc 4 instead of Jinc 3? Why? Knee jerk or there is a visual difference they like?
I believe most people use Jinc3 AR.

My initial impression with mono-static A4 is that killed the impression of depth on 720p content so I just spent quite some time comparing both builds in mono-static mode, with A4 on the bluray of Captain Harlock and ED11 on very crisp 30fps 1080p video content and in both cases the new build kills the sense of depth to my eyes...the wow factor is gone, PQ is pretty dull.
That's too bad... :(

Call me a videophile but this one seems to me a huge step in right direction. MadVR's picture never looked THAT transparent.
:)

Well, the image is not brighter anymore but darker areas are darker then they should be.
To my eyes it looks exactly right.

Either way, it's problematic if madVR linear light dithering really is still causing any kind of output gamma shift (Input != Output) like bacondither seems to suggest.
The linear light dithering is definitely nearer to the correct output than gamma light dithering is.

So we should then use the "the displays is calibrated to the following transfer function / gamma:" to set the pseudo linear light target gamma?
That would probably be ideal, but it's not too easy to do. Especially if we're talking about displays calibrated through 3dluts or GPU gamma ramps. So I think using an approximation should be a reasonable compromise.

Well, you might detect some very small differences in gamma, but it really shouldn't affect the gamma curve that much. What I was trying to say is that since there are a lot of places where the 'effective' gamma curve is going to be identical to the gamma curve of the monitor, it shouldn't noticeably change the gamma. It can affect the 'local' gamma a bit, so we should check that this doesn't have weird consequences, but the original algorithm was worse in that respect since it's 'local' gamma was 1 almost everywhere.
Fully agreed.

At the end of the day, this just means that fractional 8-bit colors need to always average as close as possible to those optimal fractional values over a decent sized surface area. You'll only have a gamma shift (localized or otherwise) if the dithering algorithm fails to simulate the fractional 8bit color values of the correct target. If you have a 16-bit color half-way between 8-bit 1 & 2, the only correct answer is an average value of 1.5 after dithering.
Average how, though? Using simple math? That would produce wrong results. A value of 50% pixels with value 1 and 50% pixels with value 2 blended together in gamma light would produce 1.5, but not in linear light! Which means that 50%/50% is actually the incorrect solution for 1.5. Our eyes do not see that as 1.5!

Agreed. As I posted here (http://forum.doom9.org/showthread.php?p=1668400#post1668400) back when the first linear light build was introduced, the best fit pure power function gamma for BT.709 is 1.950477 (rounded for single precision floating point as used by shaders). That works out to about 1.0 / 0.512695, pretty close to your suggested value of 0.53 (and the best fit for the inverse transform, 1.924805, is even closer at 1.0 / 0.519533).
The problem is that using a best fit pure power function is not the right solution in this case, IMHO. Our eyes will mix the dithering dots together. And the final mixed result will depend on how the display is calibrated, as far as I understand. Because of that I believe we should ideally use the gamma curve the display is calibrated with, to calculate the correct amount of dither dots. However, if the display is calibrated with gamma ramps or a 3dlut, we're out of luck, because taking all that into account would be a major algorithmic problem. Because of that I think using a transfer function which comes near to how most displays are calibrated should be a good compromise, and I think a pure power curve of 2.222 should fit that bill.

At least from some of the short tests I did with actual movies, brightness-wise, 3bit linear dithered now matches 8bit gamma dithered, while 3bit gamma dithered just looks totally wrong in comparison (completely washed-out blacks). Also, again, brightness-wise, 3bit linear dithered now looks like 8bit linear dithered, so there´s also no brightness-change, anymore.
Yep, same here.

Question (maybe a silly one, but I´m curious):
Is this build expected to change anything, when we´re doing any gamma processing?
No, this build uses a hard coded 2.222 pure power curve for dithering.

Could you please set the psuedo linear light gamma target(return pow(x,1/0.45)) using the "the displays is calibrated to the following transfer function / gamma:", in the next dither "addictive" build.
That's not too easy, a lot of extra code and shader variants... :(

The Linear Light processing/dithering is after the 3DLUT has been applied. Using the display gamma curve should be correct, although it really shouldn't matter much if the gamma curve you're using is slightly wrong. The only part that is still somewhat worrisome is whether screens actually use an sRGB gamma curve (with a linear part near black) or if they have a pure power gamma curve, as far as I can tell is should be the latter but I'm not sure.
Well, there is BT.1886, which produces a curve which depends on the display's black level, which makes things quite complicated. If the display has perfect (zero light) black levels, BT.1886 produces a pure power curve, though.

On a somewhat unrelated note, apparently I made a mistake in which colours are not dithered. The 'depth' value that I used in the shader should be 2^k-1 not 2^k (where k is the bitdepth).
I didn't notice this bug, but I did implement it correctly in my code.

Anyway here's a fixed version of the shader:

#define depth pow(2,8)-1
sampler s0 : register(s0);
I think you may have to add a bracket like "(pow(2,8)-1)", otherwise you end up with "floor(pow(2,8)-1*c0)" which is now what we want.

I have done some testing (lower bit depth) and found that Linear Light works (makes the gamma curve look good) only with Static dithering (or screenshots).
With Dynamic dithering & LL the picture becomes extremely dark.
This does not happen on my display. Maybe it depends on the display technology, I don't know. But I think this will likely not occur in higher bitdepths.

As far as I know that effect is caused by the response time of your screen, it is the same reason that 'blinking' occurs. Unfortunately it is somewhat difficult to tell if this also happens with 8 bit, and to what degree. It probably doesn't happen on CRTs and projectors, or screens that have a very low response time.
That would be my guess, as well.

Very few consumer displays are even close to having a flat gamma response, and are typically using an s-curve gamma.
Some of the better monitors will be calibrated to ~2.22 gamma (1/0.45) as that's what is used on the desktop.
Displays which are properly calibrated for viewing films should be at or close to 2.4 gamma. (BT.1886)

In theory madVR should already know what your display's response is, and should assume 2.2 gamma if it has not been set.
So the current dithering with 1/0.45 sounds ok to you?

-------

Here's a new test build:

http://madshi.net/madVRlinearLightDither2.rar

Changes:

(1) Added support for 1bit and 2bit display bitdepth.
(2) There's now a "trade quality for performance" option to turn off linear light dithering.
(3) Fix for this serious dithering bug: http://bugs.madshi.net/view.php?id=175
(4) JFYI: Random dithering and "None" don't cut down the bitdepth, anymore, to maximize real world image quality. Which means you can't directly compare those to ordered dithering or error diffusion in lower bitdepths, anymore.

For those who doubt that linear light dithering is a good idea, switch the display to 4bit, display the following test image and then switch the new "trade quality for performance" option on/off:

http://www.lagom.nl/lcd-test/img/gradient-h.png

[6233638]

So the current dithering with 1/0.45 sounds ok to you?I would suggest using 1/0.45 if none of the calibration options are being used in madVR.
If "this display is already calibrated..." is selected, I would use whichever gamma value is specified there.
If a 3DLUT is being used for calibration, I would assume people are calibrating to BT.1886, which becomes a flat 2.40 gamma on a high contrast display.

The majority of what I watch in madVR is film, and that's all mastered for 2.40 gamma.

2.22 is for graphics work, not film viewing.


And if you're using a display calibrated for graphics work (2.20 gamma) and transforming that to 2.40 using the "color & gamma" options, would the dither use 2.40 or 2.20?

[Ver Greeneyes]

The problem is that using a best fit pure power function is not the right solution in this case, IMHO. Our eyes will mix the dithering dots together. And the final mixed result will depend on how the display is calibrated, as far as I understand. Because of that I believe we should ideally use the gamma curve the display is calibrated with, to calculate the correct amount of dither dots. However, if the display is calibrated with gamma ramps or a 3dlut, we're out of luck, because taking all that into account would be a major algorithmic problem. Because of that I think using a transfer function which comes near to how most displays are calibrated should be a good compromise, and I think a pure power curve of 2.222 should fit that bill.Yes, after thinking about it more I agree with you. I think the ideal solution would be to invert the neutral axis of the applied Rec.709 3DLUT then apply the Rec.709-to-linear-RGB transfer function and use the result for error diffusion. The question is how to do that efficiently (I mean, assuming you want to go that far at all).

One thing you could do is to build a lookup table when a 3DLUT is selected for use:
1) For n equidistantly spaced colors on the neutral axis (i.e. RGB(0.0,0.0,0.0) to RGB(1.0,1.0,1.0)), look up the corresponding color by applying the Rec.709 transfer function, then applying the 3DLUT. The resulting colors won't be equidistantly spaced.
2) Linearly interpolate the output colors to get a set of m equidistantly spaced output colors, and apply this linear interpolation to the input colors (so now the input colors won't be equidistantly spaced).

That should give you a lookup table that allows you to transform from the post-3DLUT output to linear RGB. Of course the second step is just an approximation, but if you use enough points in the first step (e.g. n = 4096), the linear interpolation should be a fairly good approximation.

Anyway, just something to consider for a rainy day really ;)

[iSunrise]

(4) JFYI: Random dithering and "None" don't cut down the bitdepth, anymore, to maximize real world image quality. Which means you can't directly compare those to ordered dithering or error diffusion in lower bitdepths, anymore.
Thanks for the new build and including 1bit and 2bit madshi.

I'm not sure about the quoted change though and I have at least 2 questions about this change.

(1) Can you clarify what you mean with 'not cut down the bit depth'? If I understand you correctly, both 'none ' and 'random dithering' will simply ignore the display properties bit depth setting? However, if they don't adhere to the display properties anymore, what actual bit depth are they working in in that case?

(2) If the madVR user base wants to effectively compare random dithering to the more correct ordered dithered and ED variants, no one can do valid comparisons, anymore, because when you're on an 8bit display, it's almost impossible to see actual differences, which would mean that this would mislead people into thinking that random dithering is 'just fine' and provides the same level of an accurate representation as do ordered dithering or the ED variants, when instead this is not the case, because people usually don't know what too look for. The same is true for 'none'. If a user selects 'none' and doesn´t run an 8bit panel, he is being mislead into thinking that 'none' looks better, just because it doesn´t adhere to the bit depth setting anymore, while ordered dithering and ED dithering does. IMHO this doesn´t make any sense and is also harmful, because while you´re intention may have been to improve image quality, for less knowledgable users, suddenly 'None' will do just fine and thus you´re effectively lowering image quality.

I also loved being able to directly see how much information is lost at the selected display bit depth, when you´re choosing 'None'. And I also used that as a comparison baseline for some things. Now what is left is that we can only compare ordered dithering and the ED variants. I really hope this change doesn´t stay.

I am particularly interested in your answer to (1), though, because that would give further implications and lead to further questions.

[Shiandow]

That should give you a lookup table that allows you to transform from the post-3DLUT output to linear RGB. Of course the second step is just an approximation, but if you use enough points in the first step (e.g. n = 4096), the linear interpolation should be a fairly good approximation.

Is this still about the linear light dithering? Because not performing the linear light correction effectively gives you a linear interpolation of the actual gamma curve, doing the linear light correction using a linear interpolation based on the 3DLUT sort of defeats the point.

[iSunrise]

I would suggest using 1/0.45 if none of the calibration options are being used in madVR.
If "this display is already calibrated..." is selected, I would use whichever gamma value is specified there.
Yes, I agree, madVR should only ever need to assume 1/0.45, if none of the calibration settings is selected. Also, in the current calibration settings, the gamma setting actually does nothing on it's own, meaning when not used together with the gamma processing gamma setting, so we would finally have a use for it and put it to good use.

If a 3DLUT is being used for calibration, I would assume people are calibrating to BT.1886, which becomes a flat 2.40 gamma on a high contrast display.
If possible, I would not assume anything, as that would automatically break it for other use cases.

The majority of what I watch in madVR is film, and that's all mastered for 2.40 gamma.

2.22 is for graphics work, not film viewing.


And if you're using a display calibrated for graphics work (2.20 gamma) and transforming that to 2.40 using the "color & gamma" options, would the dither use 2.40 or 2.20?
Thats exactly what I meant when I asked madshi about if there's an expected change when doing any active gamma processing. From his reply I gathered that he currently uses a hardcoded value, which definitely is NOT what we want, because that would totally break the gamma processing/dithering application altogether.

[6233638]

If possible, I would not assume anything, as that would automatically break it for other use cases.Well your option is to use 2.22 gamma or 2.40 gamma if 3DLUTs are enabled. The 3DLUT itself tells you nothing about the target response on the display.
Edit: or to add another preference to manually specify what the display is calibrated to.

The safest choice you could make, is to assume that people using an advanced feature like 3DLUTs are calibrating their displays to the proper spec for watching films.

[James Freeman]

madshi,
Thank you for the new build, with the ability to satisfy all the crowd and their crazy wishes.

(4) JFYI: Random dithering and "None" don't cut down the bitdepth, anymore, to maximize real world image quality. Which means you can't directly compare those to ordered dithering or error diffusion in lower bitdepths, anymore.
Pitty. :(
This was very useful.


For those who doubt that linear light dithering is a good idea, switch the display to 4bit, display the following test image and then switch the new "trade quality for performance" option on/off:
http://www.lagom.nl/lcd-test/img/gradient-h.png
I know its for me so I'll try to explain myself again.

I'm not saying that LL bad in any way, it does its job very good for Static dithering, It makes 4-bit look almost exactly like 8-bit.
But when Dynamic dithering is activated which I use, the image becomes darker compared to 8-bit.

I'm saying the 1/0.45 gamma fits Static dithering just right, but not Dynamic.
For dynamic the gamma should be higher to make 4-bit Dynamic look like 8-bit.

A better pattern to compare the LL vs GL & bitdepth is the Greyscale Ramp from AVS709HD because its a 24fps video file and not a static image.
Looking at this pattern you can clearly see that a LOT of the blacks are crushed in 4-bit LL Dynamic mode.
But in 4-bit LL Static looks as good as 8-bit.

Allowing the possibility to change this gamma value (free value like 1.52) in the Dithering options (or registry) will be ideal.
As I understand its 1/0.45 (2.22) hard coded now.

BTW the "display bitdepth - toggle" goes to endless negative (-1, -2, etc...) bit values.

Thanks.

The safest choice you could make, is to assume that people using an advanced feature like 3DLUTs are calibrating their displays to the proper spec for watching films.
Not really, I use Gamma 2.2 Relative.
No BT.1886 or BT.709 curves here.
I wound not like to know that madVR enforces some funky "proper spec" curve on my video experience.
Keep it as transparent as possible please.

[iSunrise]

...The safest choice you could make, is to assume that people using an advanced feature like 3DLUTs are calibrating their displays to the proper spec for watching films.
Yes, but that one spec is only theoretically achievable and not practical for most of todays (PC) monitors, for example, even for very expensive hardware calibrated screens, if I understood the past conversations about that correctly*. In practical use cases, automatically assuming some hardcoded value in this case wouldn't make much sense, IMHO.

But you're more knowledgeable than me in that area. I just don't think that assuming something, because in an optimal (but theoretical case) it should be like this all the time, for everyone. Even for people that are using a 3DLUT.

*Meaning, to really adhere to BT.1886, one would need a display that is capable of a very high, native, contrast ratio, for one.

[nevcairiel]

2.40 gamma also assumes everyone has a absolute dark basement room for their movie watching. :p

[iSunrise]

2.40 gamma also assumes everyone has a absolute dark basement room for their movie watching. :p
Well, you will always find and need to make some assumptions, even in the specs themselves, of course. :D

But in the case of 3DLUTs ONLY being used for a BT.1886/2.40 target seems a quite hefty assumption from a madVR standpoint to make, IMHO.

madVR is not only used for movies that are being watched in a dark room. It is also used to watch PC/RGB content where you would optimally not have a target of BT.1886 if I understand the spec correctly, because that spec is only meant (1) for actual movie watching (2) on capable movie displays (3) in a dark room.

But I'm just thinking out loud.

Not even the newest Eizo CG monitors have a BT.1886 preset, while all more 'common' specs are supported (even DCI-P3). That could also have something to do with the inability of the displays to adhere to requirements of BT.1886, though. I haven´t really talked to the engineers about BT.1886, yet.

BTW the "display bitdepth - toggle" goes to endless negative (-1, -2, etc...) bit values.
I´m not seeing this here. Only '1bit' through '8bit (or higher)' can be selected.

[YxP]

Do many people use Jinc 4 instead of Jinc 3? Why? Knee jerk or there is a visual difference they like?

My gut says most people would fail blind test which one is which - including me.

[EDIT]

Please, make one. Include one or two other algorithms as well.

[iSunrise]

Wow, the new 1bit and 2bit options really make a difference.

Went through some of my usual content examples quickly and ED11 really only dithers where it needs to, while with A4 there are very visible and extremely bright colored random dithering dots everywhere. Even in the black areas where there shouldn´t be any. This does not happen at all with ED11. This may not be directly transferable to higher bit depths, but it shows how the algorithms work when they are extremely bit depth starved.

I feel like my strong preference for ED11 now is even more justified. It is extremely impressive how good the picture still looks when I'm at 1bit.

Also, enabling the colored or dynamic option doesn´t improve the experience one bit for me, so I still highly prefer ED11 static.

Thanks again for including them, madshi!

[James Freeman]

I´m not seeing this here. Only '1bit' through '8bit (or higher)' can be selected.

http://www.mediafire.com/convkey/b51c/wp6uhk1v9gbi8kkfg.jpg

When I press the shortcut key.

[Ver Greeneyes]

Is this still about the linear light dithering? Because not performing the linear light correction effectively gives you a linear interpolation of the actual gamma curve, doing the linear light correction using a linear interpolation based on the 3DLUT sort of defeats the point.This linear interpolation only ensures the lookup table has equidistantly spaced points and can be done using any number of points. It's not perfect, but it's completely different from just doing dithering in gamma light (which isn't much like linear interpolation at all, really - you're intentionally introducing rounding errors to get a better result on average) because it changes the values that dithering works on.

Anyway, it honestly seems like too much work to bother unless madshi just feels like experimenting with it. I just wanted to work out how it could be done in theory.

[iSunrise]

http://www.mediafire.com/convkey/b51c/wp6uhk1v9gbi8kkfg.jpg

When I press the shortcut key.
Oh, you meant the toggle shortcut. Thought you were speaking about the toggle directly.

Yes, I can confirm. That clearly seems to be a bug.

[madshi]

I would suggest using 1/0.45 if none of the calibration options are being used in madVR.
If "this display is already calibrated..." is selected, I would use whichever gamma value is specified there.
If a 3DLUT is being used for calibration, I would assume people are calibrating to BT.1886, which becomes a flat 2.40 gamma on a high contrast display.
On a quick look your suggestion makes sense. But after thinking some more about it, I'm not so sure, anymore. BT.1886 produces different curves depending on the black level of the display, so unless I know the exact black level of the display, I cannot reproduce the exact gamma curve. Furthermore even if people say they have calibrated their display to "whatever", that is probably not perfectly accurate, either, because practically no display today has true zero light output black level, so a proper calibration probably does some sort of compensation for that (either through BT.1886 or through black point compensation or other manual tweaks). So how ever you see it, I can't possibly match the real gamma curve perfectly. Furthermore: If I adjust the dither transfer curve to the "this display is already calibrated" transfer curve, then this setting is "better" than when using a 3dlut calibration, which doesn't make too much sense, either. Of course if I wanted absolute perfection, I could add a gamma curve editor to the dithering page that lets you define the real gamma curve exactly. But I think we're really going WAY overboard here.

I think what the test build does now, using a simple 1/0.45 pure power curve is a fair approximation of how most displays are calibrated out there. Some may be calibrated to 2.4, but then, 2.222 is much nearer to 2.4 than 1.0 is. Some may have a linear segment near black. Ok, that is a somewhat problematic, but I don't see an easy solution for that. I think what the test build does now should be better than doing no linear light dithering at all, agreed? So I'm tempted to keep it simple and leave linear light dithering at 1/0.45. The real world difference is very small, anyway, especially at 8bit. At 8bit I don't really see a difference between gamma and linear light dithering, at least on my computer monitor. So what sense does it make to worry about differences between e.g. 2.222 and 2.4?

What we all need to remember is that all non-dithered shades (e.g. 256 grayscale steps in 8bit) are glued onto the correct spot on the display transfer function. We're only talking about how the dithering locally interpolates between all those glued on steps. So whatever transfer function we choose, we're not changing the overall transfer function at all, but we're just doing very local very small changes. Of course this only applies to "normal" bitdepths. If you go to 4bits or lower, the numbers of shades has gone so low that the dithering transfer function actually starts to define the overall look of the display transfer function. But remember, 4bits and lower is really only for testing, so we shouldn't worry about that too much.

Yes, after thinking about it more I agree with you. I think the ideal solution would be to invert the neutral axis of the applied Rec.709 3DLUT then apply the Rec.709-to-linear-RGB transfer function and use the result for error diffusion.
Uhm, maybe it's too late in the evening, but I don't really understand what you mean. Anyway, I don't want to make the algorithm too complicated. No lookup tables or anything like that, please.

(1) Can you clarify what you mean with 'not cut down the bit depth'? If I understand you correctly, both 'none ' and 'random dithering' will simply ignore the display properties bit depth setting?
First of all the "none" setting does nothing, anymore. It just renders and rounds to 8bit, and sends the data untouched to the display and it's up to the display how to handle that. And it makes sense this way, after all it's "none", so it should do "nothing". The versions v0.87.5-6 rounded the pixels down to the specified display bitdepth when selecting "none", to simulate a display with such a low native bitdepth (and no internal dithering). But this really only served the purpose of algorithm comparison, it didn't serve any image quality purposes.

Edit: Ok, I guess I could revert this change and let "none" round to the specified display bitdepth again. After all, nobody in his right mind should configure madVR to do "none" in the first place, especially not if the display is configured to less than 8bit. However, random dithering is a different topic.

The random dithering still does honor the display bitdepth setting. Meaning the amount of noise depends on the display bitdepth. However, madVR does this in 8bit, and leaves the rest to the display. So basically the display bitdepth just changes the amount of noise random dithering adds. Older madVR versions (prior to v0.87.5) behaved the same way. Only in v0.87.5-6 I artificially cut down the bitdepth to the specified display bitdepth, so comparisons would be fairer. But in the end the purpose of madVR is not to compare different algorithms, but to produce the best possible image quality. And there's no point artificially rounding random dithered content down to less than 8bit. It cannot improve image quality, it can only degrade it.

(2) If the madVR user base wants to effectively compare random dithering to the more correct ordered dithered and ED variants, no one can do valid comparisons, anymore, because when you're on an 8bit display, it's almost impossible to see actual differences, which would mean that this would mislead people into thinking that random dithering is 'just fine' and provides the same level of an accurate representation as do ordered dithering or the ED variants, when instead this is not the case, because people usually don't know what too look for.
I see the problem. But do you not agree that madVR's main purpose is to produce the best image quality? Rounding random dithered content down to less than 8bit can hurt image quality. Should I willingly accept a possible image quality loss just to make comparisons nicer?

I know its for me
No, my comment was not specifically directed at you.

I'm not saying that LL bad in any way, it does its job very good for Static dithering, It makes 4-bit look almost exactly like 8-bit.
But when Dynamic dithering is activated which I use, the image becomes darker compared to 8-bit.

I'm saying the 1/0.45 gamma fits Static dithering just right, but not Dynamic.
For dynamic the gamma should be higher to make 4-bit Dynamic look like 8-bit.
That is what you may experience on your display. But it is not what I experience on mine. I can only write algorithms that in theory produce correct results. If your display's technology for some reason screws up, that is outside of my control, and I will not adjust my algorithms for just your display, if there are other displays which behave differently. If I adjust the algorithms to look correct on your display, things will look wrong on my display. So I will only look at what is mathematically/scientifically correct.

[secvensor]

Say what is BT2020:
http://i33.fastpic.ru/big/2014/0308/67/daea1e91d48dd35506551fb8fb1a2e67.jpg

[Ver Greeneyes]

Uhm, maybe it's too late in the evening, but I don't really understand what you mean. Anyway, I don't want to make the algorithm too complicated. No lookup tables or anything like that, please.It would get complicated, so don't worry about it.

But for the record, what I meant was that the 3DLUT maps Rec.709 to the display gamma*, so we can cheat and take the 256 neutral axis entries in the 3DLUT to get three 1D curves**, then invert those curves to map the display gamma* back to Rec.709. Then we apply Rec.709-to-linear-RGB to that and store the results in a lookup table so we don't have to do it over and over again.

* or the videoLUT gamma

** Alternatively if the 3DLUT has a calibration appended, we can just use that (assuming the neutral axis of the 3DLUT will be linear), but the process would otherwise be the same.

[James Freeman]

That is what you may experience on your display. But it is not what I experience on mine.

madshi, it has nothing to do with the display.
Its about Dynamic/Static dithering and how the eye perceives the apparent gamma curve.

Greyscale Ramp from AVS709HD (http://www.mediafire.com/watch/rkvk3yypyy623do/6-Grayscale_Ramp_.mp4) 2.6MB

Play this video in 4-bit LL Dynamic dithering.
Now just pause the video, and play back again, pause and play back again.
Can you not see the change in the dark shades?

In LL or GL the dark shades are brighter when paused (or when Static dithering is used).
So basically we are over compensating the apparent gamma of Dynamic dithering with the 1/0.45 value and making it too dark.

If you can't see that, I have no other way to explain this...

[secvensor]

madshi
Make function of a hot command of a series of screenshots.
Like:
http://i33.fastpic.ru/big/2014/0308/13/aa489195d2691c8c724004ca68668d13.jpg
But with the full-size:
The permission and effects madvr settings
For quality comparison on screenshots.

[iSunrise]

Edit: Ok, I guess I could revert this change and let "none" round to the specified display bitdepth again. After all, nobody in his right mind should configure madVR to do "none" in the first place, especially not if the display is configured to less than 8bit. However, random dithering is a different topic.
Yes, please. That´s exactly how I think about it.

The random dithering still does honor the display bitdepth setting. Meaning the amount of noise depends on the display bitdepth. However, madVR does this in 8bit, and leaves the rest to the display. So basically the display bitdepth just changes the amount of noise random dithering adds. Older madVR versions (prior to v0.87.5) behaved the same way. Only in v0.87.5-6 I artificially cut down the bitdepth to the specified display bitdepth, so comparisons would be fairer. But in the end the purpose of madVR is not to compare different algorithms, but to produce the best possible image quality. And there's no point artificially rounding random dithered content down to less than 8bit. It cannot improve image quality, it can only degrade it.
Yes, I can actually follow you here, as this is clearly different from the 'None' discussion. I´m not entirely sure I understand this one, though. So what you´re saying is that you applied random dithering before by rounding it down to the target bitdepth. Now, you decoupled the 'noise' component from the 'random' component and while the 'noise' component still honors the selected bit depth, there´s no rounding anymore, because that doesn´t give a realistic comparison base? Meaning, what we saw with random dithering at lower bit depths before was wrong?

So in the end, we could still do comparisons with RD, but now with a more correct implementation at lower bit depths? It´s not easy to understand this, since this seems to behave so different than the other dithering variants according to your explanation.

I see the problem. But do you not agree that madVR's main purpose is to produce the best image quality? Rounding random dithered content down to less than 8bit can hurt image quality. Should I willingly accept a possible image quality loss just to make comparisons nicer?
I agree completely. In this case it is very conflicting, though, since even though your intentions to improve image quality are quite clear to me, less knowledgable users will always select options where they see no differences, and 'None' at least is an extreme case where this could be quite harmful to a broad user base.

[iSunrise]

madshi, it has nothing to do with the display.
Its about Dynamic/Static dithering and how the eye perceives the apparent gamma curve.

Greyscale Ramp from AVS709HD (http://www.mediafire.com/watch/rkvk3yypyy623do/6-Grayscale_Ramp_.mp4) 2.6MB

Play this video in 4-bit LL Dynamic dithering.
Now just pause the video, and play back again, pause and play back again.
Can you not see the change in the dark shades?

In LL or GL the dark shades are brighter when paused (or when Static dithering is used).
So basically we are over compensating the apparent gamma of Dynamic dithering with the 1/0.45 value and making it too dark.

If you can't see that, I have no other way to explain this...
Yes, there are differences, I can see them, too. It seems LL shows a lot less dithering dots in the dark shades when compared with GL. The higher you go with your bit depth, the less the "problem".

Not sure about this right now, since from real world examples 3bit linear light behaved exactly like 8bit gamma light, like I showed with the conan examples. Seems this is only visible on artifical gradients again. Need to test this further to come to the right conclusions.

@6233638:
If you have some time, can you quickly use your testing gradient comparison you did when we last tested LL vs. GL dithering with the new provided 1bit mode? What`s your stance on that?

[6233638]

BT.1886 produces different curves depending on the black level of the display, so unless I know the exact black level of the display, I cannot reproduce the exact gamma curve. Furthermore even if people say they have calibrated their display to "whatever", that is probably not perfectly accurate, either, because practically no display today has true zero light output black level, so a proper calibration probably does some sort of compensation for that (either through BT.1886 or through black point compensation or other manual tweaks).Well it's only 10,000:1 contrast where BT.1886 switches to a pure 2.40 gamma.
Most displays (televisions, not monitors) released in the last few years should be capable of that, and going forward that's only more likely to be true.

BT.1886 is a recent spec, and prior to that, things were just mastered to a flat 2.40 gamma. (which is approximately what any mastering-grade CRT should measure)

So how ever you see it, I can't possibly match the real gamma curve perfectly. Furthermore: If I adjust the dither transfer curve to the "this display is already calibrated" transfer curve, then this setting is "better" than when using a 3dlut calibration, which doesn't make too much sense, either. Of course if I wanted absolute perfection, I could add a gamma curve editor to the dithering page that lets you define the real gamma curve exactly. But I think we're really going WAY overboard here.Well I don't see the harm in making the "this display is already calibrated" option as good as it can be.

All I meant was to add a drop-down menu for the yCMS/3DLUT option similar to the one offered in the "this display is already calibrated" section so you are at least using a closer approximation to the display, even if it's not 100% matched. (i.e. 2.40 gamma rather than 2.20 gamma)

Failing that, I think using 2.40 would be better than 2.22.

I think what the test build does now, using a simple 1/0.45 pure power curve is a fair approximation of how most displays are calibrated out there.I disagree. CRTs used 2.4 gamma. With old low contrast LCDs, people were more likely to use a "black level compensated" calibration, often to "2.2 gamma", which was really nothing like a flat 2.22 gamma anyway.
Uncalibrated LCDs were neither 2.2 or 2.4, but used an s-curve gamma to boost the apparent contrast of the image.
With the high contrast displays we have today, gamma will be a lot closer to 2.4 again, as intended.

2.22 gamma is for monitors, not televisions or projectors.

I think what the test build does now should be better than doing no linear light dithering at all, agreed?Yes, I think we can agree on that.

[SecurityBunny]

Would someone be so kind and explain to a novice HTPC'er such as myself why dithering is necessary to have enabled? I always keep my IPS calibrated monitor in 8bit+ mode in madvr.

From my testing in very low bit-rate (1-3 bit) using LL dither build 2, I prefer Error Diffusion 1 with no options checked.
Dynamic option (change dither for every frame) produces a very noticeable flicker.
Colored noise produces more noticeable movement in the dither effect pixels which looks like it is artifacting.
Error diffusion option 2 looks to have more sporadic random movement all over the place which to my eyes looks like flashing.
Error diffusion option 1 has more noise, but it doesn't have the 'movement flickering' all over the place.

And of course, 'none' is the cleanest image and I can't seem to see a different with 'none' dithering in any bit rate. Which leads me to ask, if I am only playing back video in 8bit+ mode, is dithering necessary? Couldn't I just use 'none' for the clearest picture?

Settings for 2560x1440 playback.
Chroma Upscaling - NNEDI3 32 neurons
Image Doubling - Luma Double 32 neurons
Image Upscaling - Jinc3 AR
Image Downscaling - Catmull-Rom AR LL
Smooth motion enabled.
No trade quality for performance options checked.
Reduce banding artifacts set to low.
Calibrated using 3dlut.

[madshi]

Say what is BT2020
http://lmgtfy.com/?q=bt.2020

But for the record, what I meant was that the 3DLUT maps Rec.709 to the display gamma*, so we can cheat and take the 256 neutral axis entries in the 3DLUT to get three 1D curves**, then invert those curves to map the display gamma* back to Rec.709. Then we apply Rec.709-to-linear-RGB to that and store the results in a lookup table so we don't have to do it over and over again.
Ok, nice, but complicated... :p

Make function of a hot command of a series of screenshots.
Like: [...]
But with the full-size:
The permission and effects madvr settings
For quality comparison on screenshots.
Maybe some time in the future, but not soon. Too many other things to do.

it has nothing to do with the display.
I disagree.

Its about Dynamic/Static dithering and how they eye perceives the apparent gamma curve.
There's only one scientific reason that comes to my mind why dynamic dithering would produce a different gamma curve compared to static dithering: Which is that your display isn't able to reproduce dynamic dithering correctly. Maybe your display is too slow, or maybe Overdrive is overcompensating, or something like that.

Play this video in 4-bit LL Dynamic dithering.
Now just pause the video, and play back again, pause and play back again.
Can you not see the change in the dark shades?
The better test is to let it play, then switch between 4-bit LL Dynamic dithering and 8-bit while it plays. Looks almost identical to me on my monitor. 4bit just looks a bit rougher, but no change in brightness or gamma.

I´m not entirely sure I understand this one, though. So what you´re saying is that you applied random dithering before by rounding it down to the target bitdepth. Now, you decoupled the 'noise' component from the 'random' component and while the 'noise' component still honors the selected bit depth, there´s no rounding anymore, because that doesn´t give a realistic comparison base? Meaning, what we saw with random dithering at lower bit depths before was wrong?

So in the end, we could still do comparisons with RD, but now with a more correct implementation at lower bit depths?
No.

If you tell madVR that your display can only do 6bit, then madVR can adjust to that. The question is how to do that in the best possible way. If your display can only do 6bit, then when using random dithering, madVR has to compensate for the low bitdepth by adding lots of additional random noise. And that is what all madVR builds have done, past and future. No change there. Basically with your display bitdepth set to 7bit madVR adds twice as much noise as with it set to 8bit. And with your display set to 6bit madVR adds 4 times as much noise as if it's set to 8bit.

The difference between v0.87.5+6 and all other builds is that v0.87.5+6 put more weight on letting you compare nicely instead of producing the best possible image quality. Basically what v0.87.5+6 did was that they simulated a display which has the bitdepth you specified. So e.g. if you set your display to 6bit, madVR actually (after adding the right amount of random dithering noise) rounded the pixels down to 6bit. This is nice for comparing the algorithms. Because it's similar to how ordered dithering and error diffusion handle 6bit. However, there is no mathematical/scientific reason for madVR to actually round the pixels down to 6bit. If your display can really only handle 6bit, then your display will do the rounding down. So madVR doesn't have to do that. In theory it should not harm if madVR already rounds down to 6bit, if your display can only handle 6bit, anyway. However, that's only true if the display handles the rounding down in *exactly* the same way as madVR. If it does it differently, having a rounding down in both madVR and in the display could reintroduce banding artifacts. Because of that versions v0.87.4 and older - and v0.87.7 and newer do not round down to 6bit, when using random dithering. Because it's not necessary and *might* introduce artifacts. When doing comparisons, if your display really can do 8bit, and if you set madVR to 6bit, this means that nobody is rounding down to 6bit, anymore, which means the final image quality will be better than a real 6bit display would look like.

Ordered dithering and error diffusion internally work totally differently. If you tell madVR to dither to 6bit with ordered dithering or error diffusion, you really only get 6bit worth of data. So if your display can do 8bit, but you tell madVR to dither down to 6bit, with ordered dithering and error diffusion you really get results which looks like a native 6bit display.

Basically this means that v0.87.5+6 are nice for comparison random dithering to ordered dithering and error diffusion, because all 3 algorithms produce a true 6bit look. All other builds potentially produce better image quality when using random dithering, but are not good for comparing random dithering with the other algorithms, when setting your display to a lower bitdepth than it really has.

I disagree. CRTs used 2.4 gamma. With old low contrast LCDs, people were more likely to use a "black level compensated" calibration, often to "2.2 gamma", which was really nothing like a flat 2.22 gamma anyway.
Uncalibrated LCDs were neither 2.2 or 2.4, but used an s-curve gamma to boost the apparent contrast of the image.
With the high contrast displays we have today, gamma will be a lot closer to 2.4 again, as intended.

2.22 gamma is for monitors, not televisions or projectors.
Fair enough. But how much visible difference will there be between 2.222 and 2.4, when talking not about the whole transfer function, but *just* about the local interpolation between the 256 fixed shades of 8bit content? I can't even see any difference at all between 1.0 and 2.222 on my monitor (at 8bit)! I think you might be thinking too much about the overall transfer function (where the difference between 2.222 and 2.4 is very visible). The difference between 2.222 and 2.4 for dithering in 8bit will probably be extremely small, because the 256 shades of grayscale in 8bit are already glued onto the correct transfer function.

Have you compared linear light dithering vs. gamma light dithering in 8bit (!) on your display yet? Where you able to see a clear difference?

[madshi]

Would someone be so kind and explain to a novice HTPC'er such as myself why dithering is necessary to have enabled?
Because madVR processing is performed in 16bit+, while your GPU only sends 8bit to your display. So madVR has to convert the 16bit+ down to 8bit. Which mathematically needs dithering for max accuracy. If you have a decent display, you should set madVR to 8bit. Dithering with 8bit often does not produce a night-and-day difference over "none", but it's definitely better, so you should use it.

The low bitdepths like 1-5 are only there for testing, to make differences between the various dithering algorithms more obvious, they should not be used for real time playback.

From my testing in very low bit-rate (1-3 bit) using LL dither build 2, I prefer Error Diffusion 1 with no options checked.
Dynamic option (change dither for every frame) produces a very noticeable flicker.
Colored noise produces more noticeable movement in the dither effect pixels which looks like it is artifacting.
Error diffusion option 2 looks to have more sporadic random movement all over the place which to my eyes looks like flashing.
Error diffusion option 1 has more noise, but it doesn't have the 'movement flickering' all over the place.

And of course, 'none' is the cleanest image and I can't seem to see a different with 'none' dithering in any bit rate. Which leads me to ask, if I am only playing back video in 8bit+ mode, is dithering necessary? Couldn't I just use 'none' for the clearest picture?
The "none" option always does 8bit in the test build you were using, so it's not a fair comparison to the other algorithms when setting your display to a bitdepth lower than 8bit. Please do not use "none" for real video playback, it can only hurt image quality.

The flickering you were seeing with "dynamic" dithering only occurs in low bitdepths and only if the movie framerate doesn't match your display refresh rate. If you use a test clip which has the same framerate as your display refresh rate, the flickering will go away.

If you're trying to decide which algorithm you like most, I'd suggest to test e.g. in 6bit or maybe in 5bit. Use 4bit if all else fails, but I would not go lower than that. In 1-3bit there are some artifacts which are not visible in higher bitdepths, so I don't recommend basing your preferences on 1-3bit. I've just added those bitdepths to satisfy testing curiousity.

[SecurityBunny]

Because madVR processing is performed in 16bit+, while your GPU only sends 8bit to your display. So madVR has to convert the 16bit+ down to 8bit. Which mathematically needs dithering for max accuracy. If you have a decent display, you should set madVR to 8bit. Dithering with 8bit often does not produce a night-and-day difference over "none", but it's definitely better, so you should use it.

The low bitdepths like 1-5 are only there for testing, to make differences between the various dithering algorithms more obvious, they should not be used for real time playback.


The "none" option always does 8bit in the test build you were using, so it's not a fair comparison to the other algorithms when setting your display to a bitdepth lower than 8bit. Please do not use "none" for real video playback, it can only hurt image quality.

The flickering you were seeing with "dynamic" dithering only occurs in low bitdepths and only if the movie framerate doesn't match your display refresh rate. If you use a test clip which has the same framerate as your display refresh rate, the flickering will go away.

If you're trying to decide which algorithm you like most, I'd suggest to test e.g. in 6bit or maybe in 5bit. Use 4bit if all else fails, but I would not go lower than that. In 1-3bit there are some artifacts which are not visible in higher bitdepths, so I don't recommend basing your preferences on 1-3bit. I've just added those bitdepths to satisfy testing curiousity.

Thank you very much for the clarification. I shall re-evaluate my tests in a higher bit-rate.