madVR - high quality video renderer (GPU assisted)

[Ver Greeneyes]

Originally Posted by 6233638

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]

Originally Posted by 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.

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]

Originally Posted by Werewolfy

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.

Originally Posted by JonnyRedHed

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?

Originally Posted by Kalanoch

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.

Originally Posted by seiyafan

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

Originally Posted by TheShadowRunner

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.

Originally Posted by NicolasRobidoux

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.

Originally Posted by leeperry

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

Originally Posted by Qaq

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

Originally Posted by bacondither

Well, the image is not brighter anymore but darker areas are darker then they should be.

To my eyes it looks exactly right.

Originally Posted by cyberbeing

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.

Originally Posted by bacondither

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.

Originally Posted by Shiandow

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.

Originally Posted by cyberbeing

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!

Originally Posted by Ver Greeneyes

Agreed. As I posted here 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.

Originally Posted by iSunrise

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.

Originally Posted by iSunrise

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.

Originally Posted by bacondither

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

Originally Posted by Shiandow

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.

Originally Posted by Shiandow

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.

Originally Posted by Shiandow

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.

Originally Posted by James Freeman

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.

Originally Posted by Shiandow

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.

Originally Posted by 6233638

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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

Originally Posted by Ver Greeneyes

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]

Originally Posted by 6233638

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.

Originally Posted by 6233638

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.

Originally Posted by 6233638

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]

Originally Posted by iSunrise

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.

Originally Posted by madshi

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

Originally Posted by madshi

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.

Originally Posted by 6233638

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]

Originally Posted by 6233638

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

[iSunrise]

Originally Posted by nevcairiel

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

Well, you will always find and need to make some assumptions, even in the specs themselves, of course.

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.

Originally Posted by James Freeman

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]

Originally Posted by NicolasRobidoux

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]

Originally Posted by iSunrise

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

When I press the shortcut key.

[Ver Greeneyes]

Originally Posted by Shiandow

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]

Originally Posted by James Freeman

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]

Originally Posted by 6233638

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.

Originally Posted by Ver Greeneyes

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.

Originally Posted by iSunrise

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

Originally Posted by iSunrise

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

Originally Posted by James Freeman

I know its for me

No, my comment was not specifically directed at you.

Originally Posted by James Freeman

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: