madVR - high quality video renderer (GPU assisted)

[James Freeman]

I just tried that test and I really cannot see a difference in gamma at 1 bit, 2 bit, or 4 bit between playing and paused ED2 mono dynamic. I think you have to accept it is an artifact of your display, do you have another screen you could test on?

EDIT:
It does not happen on a (brothers) quicker IPS or TN.
Only on my AMVA which apparently is extremely slow (and have off center contrast shift).
It will be replaced ASAP (even though it does 72Hz).

Yep, LL looks good with Dynamic or Static (on a good monitor that I currently don't have :( ).

Meanwhile all the tests I've done that related to display response time (like Dynamic Dithering or Smooth motion blur) are unreliable.
So I'll remain low profile till I'll have a better display.
Consider my previous posts about that matter obsolete.

[cyberbeing]

I think it is not missing shades in linear dithering vs gamma dithering it is just that madVR thinks the increase in brightness of 2 compared to 1 is larger than it actually is on your display. Do you have a very flat native response near black? Can you make out bar 17 in a black clipping test video?
Well it's reference grade CRT, so I'd say yes. The gamma and tone response is smooth and predicable across the entire luminance range. I can also see all steps in the test here (http://www.drycreekphoto.com/Learn/Calibration/monitor_black.htm) and make out the differences in the last 1 value difference row here (http://www.drycreekphoto.com/Learn/Calibration/monitor_sensitivity.html).

As you can kind of see from my calibrated ramp (right) vs linear ramp (left), the adjustments near-black are rather aggressive to reproduce that near-black response of BT.709. It just doesn't function correctly with linear dithering (4bit), since such calibration curves assume a gamma response. It doesn't really matter though, since this should only be a problem with low bitdepth dithering. I'm only following up on it because madshi requested I test 4bit as proof the linear light dithering is superior, while I came to the exact opposite conclusion with my calibration.

With 8bit dithering I don't think it would be an issue, at least not to this extent. As I've said before, this obsession with low bitdeph dithering really needs to go. How they behave in 8bit is where it counts.


#GammaRamp #GammaRamp
0 0 0 0 0 664 0 56
1 257 257 257 1 1015 219 429
2 514 514 514 2 1363 586 799
3 771 771 771 3 1706 948 1164
4 1028 1028 1028 4 2046 1306 1525
5 1285 1285 1285 5 2383 1661 1882
6 1542 1542 1542 6 2716 2011 2235
7 1799 1799 1799 7 3046 2358 2584
8 2056 2056 2056 8 3372 2700 2929
9 2313 2313 2313 9 3695 3039 3270
10 2570 2570 2570 10 4015 3373 3607
11 2827 2827 2827 11 4333 3705 3942
12 3084 3084 3084 12 4647 4031 4272
13 3341 3341 3341 13 4958 4352 4598
14 3598 3598 3598 14 5265 4669 4919
15 3855 3855 3855 15 5570 4982 5237
16 4112 4112 4112 16 5871 5291 5550
17 4369 4369 4369 17 6171 5597 5862
18 4626 4626 4626 18 6470 5899 6171
19 4883 4883 4883 19 6769 6199 6478
20 5140 5140 5140 20 7067 6497 6782
21 5397 5397 5397 21 7364 6792 7084
22 5654 5654 5654 22 7661 7086 7385
23 5911 5911 5911 23 7956 7378 7683
24 6168 6168 6168 24 8250 7669 7980
25 6425 6425 6425 25 8542 7958 8274
26 6682 6682 6682 26 8832 8245 8567
27 6939 6939 6939 27 9122 8533 8859
28 7196 7196 7196 28 9409 8818 9149
29 7453 7453 7453 29 9696 9104 9439
30 7710 7710 7710 30 9981 9388 9726
31 7967 7967 7967 31 10265 9672 10013
32 8224 8224 8224 32 10548 9956 10299
33 8481 8481 8481 33 10829 10238 10584
34 8738 8738 8738 34 11109 10520 10867
35 8995 8995 8995 35 11387 10801 11149
36 9252 9252 9252 36 11663 11080 11429
37 9509 9509 9509 37 11937 11359 11709
38 9766 9766 9766 38 12208 11637 11987
39 10023 10023 10023 39 12476 11914 12262
40 10280 10280 10280 40 12741 12188 12536
41 10537 10537 10537 41 13002 12460 12807
42 10794 10794 10794 42 13260 12730 13076
43 11051 11051 11051 43 13515 13000 13343
44 11308 11308 11308 44 13766 13267 13608
45 11565 11565 11565 45 14013 13533 13871
46 11822 11822 11822 46 14258 13797 14131
47 12079 12079 12079 47 14500 14060 14389
48 12336 12336 12336 48 14739 14320 14645
49 12593 12593 12593 49 14975 14579 14898
50 12850 12850 12850 50 15208 14837 15151
51 13107 13107 13107 51 15440 15093 15402
52 13364 13364 13364 52 15671 15349 15651
53 13621 13621 13621 53 15901 15603 15899
54 13878 13878 13878 54 16131 15856 16147
55 14135 14135 14135 55 16360 16110 16394
56 14392 14392 14392 56 16590 16362 16641
57 14649 14649 14649 57 16821 16613 16888
58 14906 14906 14906 58 17052 16865 17134
59 15163 15163 15163 59 17285 17117 17381
60 15420 15420 15420 60 17519 17368 17630
61 15677 15677 15677 61 17756 17621 17880
62 15934 15934 15934 62 17996 17873 18131
63 16191 16191 16191 63 18238 18126 18383
64 16448 16448 16448 64 18484 18378 18635
65 16705 16705 16705 65 18731 18630 18888
66 16962 16962 16962 66 18981 18882 19142
67 17219 17219 17219 67 19232 19133 19394
68 17476 17476 17476 68 19486 19384 19647
69 17733 17733 17733 69 19740 19633 19899
70 17990 17990 17990 70 19993 19882 20150
71 18247 18247 18247 71 20247 20130 20401
72 18504 18504 18504 72 20501 20377 20651
73 18761 18761 18761 73 20752 20621 20899
74 19018 19018 19018 74 21003 20866 21146
75 19275 19275 19275 75 21253 21110 21393
76 19532 19532 19532 76 21501 21352 21638
77 19789 19789 19789 77 21747 21594 21881
78 20046 20046 20046 78 21991 21835 22125
79 20303 20303 20303 79 22232 22074 22368
80 20560 20560 20560 80 22471 22312 22609
81 20817 20817 20817 81 22708 22549 22850
82 21074 21074 21074 82 22943 22785 23091
83 21331 21331 21331 83 23175 23021 23332
84 21588 21588 21588 84 23407 23257 23572
85 21845 21845 21845 85 23637 23490 23809
86 22102 22102 22102 86 23866 23724 24047
87 22359 22359 22359 87 24092 23954 24283
88 22616 22616 22616 88 24319 24186 24518
89 22873 22873 22873 89 24544 24416 24753
90 23130 23130 23130 90 24768 24645 24985
91 23387 23387 23387 91 24993 24875 25218
92 23644 23644 23644 92 25216 25103 25449
93 23901 23901 23901 93 25442 25331 25679
94 24158 24158 24158 94 25669 25559 25908
95 24415 24415 24415 95 25894 25784 26136
96 24672 24672 24672 96 26121 26010 26364
97 24929 24929 24929 97 26349 26236 26592
98 25186 25186 25186 98 26578 26462 26820
99 25443 25443 25443 99 26807 26687 27047
100 25700 25700 25700 100 27036 26912 27274
101 25957 25957 25957 101 27265 27136 27499
102 26214 26214 26214 102 27495 27360 27725
103 26471 26471 26471 103 27724 27583 27950
104 26728 26728 26728 104 27953 27806 28175
105 26985 26985 26985 105 28182 28029 28400
106 27242 27242 27242 106 28411 28252 28625
107 27499 27499 27499 107 28642 28475 28851
108 27756 27756 27756 108 28873 28698 29076
109 28013 28013 28013 109 29105 28921 29303
110 28270 28270 28270 110 29338 29146 29530
111 28527 28527 28527 111 29572 29372 29760
112 28784 28784 28784 112 29807 29599 29989
113 29041 29041 29041 113 30045 29827 30219
114 29298 29298 29298 114 30281 30054 30447
115 29555 29555 29555 115 30517 30280 30676
116 29812 29812 29812 116 30751 30505 30904
117 30069 30069 30069 117 30984 30730 31133
118 30326 30326 30326 118 31215 30953 31360
119 30583 30583 30583 119 31446 31178 31589
120 30840 30840 30840 120 31674 31402 31818
121 31097 31097 31097 121 31902 31628 32049
122 31354 31354 31354 122 32128 31853 32280
123 31611 31611 31611 123 32356 32081 32512
124 31868 31868 31868 124 32586 32310 32746
125 32125 32125 32125 125 32814 32538 32979
126 32382 32382 32382 126 33044 32769 33215
127 32639 32639 32639 127 33274 33000 33450
128 32896 32896 32896 128 33505 33232 33686
129 33153 33153 33153 129 33735 33464 33922
130 33410 33410 33410 130 33968 33699 34161
131 33667 33667 33667 131 34201 33934 34400
132 33924 33924 33924 132 34434 34169 34640
133 34181 34181 34181 133 34669 34406 34881
134 34438 34438 34438 134 34905 34645 35124
135 34695 34695 34695 135 35141 34884 35368
136 34952 34952 34952 136 35377 35123 35613
137 35209 35209 35209 137 35614 35364 35858
138 35466 35466 35466 138 35852 35607 36104
139 35723 35723 35723 139 36090 35850 36350
140 35980 35980 35980 140 36328 36092 36594
141 36237 36237 36237 141 36566 36334 36839
142 36494 36494 36494 142 36804 36577 37084
143 36751 36751 36751 143 37043 36820 37328
144 37008 37008 37008 144 37282 37062 37572
145 37265 37265 37265 145 37520 37304 37815
146 37522 37522 37522 146 37760 37546 38058
147 37779 37779 37779 147 37999 37788 38300
148 38036 38036 38036 148 38239 38030 38543
149 38293 38293 38293 149 38477 38271 38784
150 38550 38550 38550 150 38716 38514 39027
151 38807 38807 38807 151 38954 38755 39270
152 39064 39064 39064 152 39193 38999 39514
153 39321 39321 39321 153 39431 39242 39758
154 39578 39578 39578 154 39671 39488 40004
155 39835 39835 39835 155 39911 39734 40248
156 40092 40092 40092 156 40152 39981 40493
157 40349 40349 40349 157 40394 40228 40738
158 40606 40606 40606 158 40637 40476 40984
159 40863 40863 40863 159 40881 40725 41230
160 41120 41120 41120 160 41125 40973 41475
161 41377 41377 41377 161 41370 41224 41721
162 41634 41634 41634 162 41613 41474 41968
163 41891 41891 41891 163 41857 41725 42216
164 42148 42148 42148 164 42102 41978 42466
165 42405 42405 42405 165 42348 42231 42718
166 42662 42662 42662 166 42596 42485 42971
167 42919 42919 42919 167 42845 42740 43225
168 43176 43176 43176 168 43096 42996 43480
169 43433 43433 43433 169 43349 43252 43736
170 43690 43690 43690 170 43602 43508 43991
171 43947 43947 43947 171 43855 43765 44247
172 44204 44204 44204 172 44107 44021 44502
173 44461 44461 44461 173 44359 44278 44759
174 44718 44718 44718 174 44611 44536 45017
175 44975 44975 44975 175 44863 44796 45275
176 45232 45232 45232 176 45116 45056 45535
177 45489 45489 45489 177 45370 45318 45794
178 45746 45746 45746 178 45624 45581 46051
179 46003 46003 46003 179 45876 45842 46306
180 46260 46260 46260 180 46127 46102 46560
181 46517 46517 46517 181 46376 46360 46813
182 46774 46774 46774 182 46624 46616 47065
183 47031 47031 47031 183 46871 46870 47316
184 47288 47288 47288 184 47118 47123 47567
185 47545 47545 47545 185 47365 47375 47818
186 47802 47802 47802 186 47611 47626 48069
187 48059 48059 48059 187 47858 47877 48320
188 48316 48316 48316 188 48105 48128 48570
189 48573 48573 48573 189 48351 48379 48820
190 48830 48830 48830 190 48596 48628 49070
191 49087 49087 49087 191 48841 48878 49320
192 49344 49344 49344 192 49085 49127 49570
193 49601 49601 49601 193 49331 49378 49821
194 49858 49858 49858 194 49579 49629 50074
195 50115 50115 50115 195 49827 49880 50326
196 50372 50372 50372 196 50078 50134 50581
197 50629 50629 50629 197 50329 50388 50835
198 50886 50886 50886 198 50581 50643 51089
199 51143 51143 51143 199 50832 50899 51344
200 51400 51400 51400 200 51082 51155 51598
201 51657 51657 51657 201 51332 51413 51854
202 51914 51914 51914 202 51581 51672 52110
203 52171 52171 52171 203 51831 51931 52366
204 52428 52428 52428 204 52082 52192 52622
205 52685 52685 52685 205 52334 52452 52879
206 52942 52942 52942 206 52588 52714 53137
207 53199 53199 53199 207 52843 52978 53397
208 53456 53456 53456 208 53099 53243 53657
209 53713 53713 53713 209 53356 53509 53918
210 53970 53970 53970 210 53614 53775 54176
211 54227 54227 54227 211 53872 54041 54435
212 54484 54484 54484 212 54127 54305 54692
213 54741 54741 54741 213 54380 54567 54948
214 54998 54998 54998 214 54634 54829 55205
215 55255 55255 55255 215 54885 55090 55461
216 55512 55512 55512 216 55136 55350 55716
217 55769 55769 55769 217 55384 55609 55970
218 56026 56026 56026 218 55630 55867 56226
219 56283 56283 56283 219 55878 56125 56482
220 56540 56540 56540 220 56127 56383 56739
221 56797 56797 56797 221 56377 56642 56996
222 57054 57054 57054 222 56628 56900 57254
223 57311 57311 57311 223 56879 57159 57510
224 57568 57568 57568 224 57131 57418 57766
225 57825 57825 57825 225 57384 57677 58023
226 58082 58082 58082 226 57636 57935 58278
227 58339 58339 58339 227 57890 58193 58533
228 58596 58596 58596 228 58146 58453 58790
229 58853 58853 58853 229 58401 58713 59046
230 59110 59110 59110 230 58657 58973 59301
231 59367 59367 59367 231 58914 59233 59556
232 59624 59624 59624 232 59171 59494 59811
233 59881 59881 59881 233 59428 59754 60066
234 60138 60138 60138 234 59685 60014 60321
235 60395 60395 60395 235 59943 60275 60575
236 60652 60652 60652 236 60202 60536 60830
237 60909 60909 60909 237 60461 60798 61085
238 61166 61166 61166 238 60721 61061 61340
239 61423 61423 61423 239 60981 61325 61596
240 61680 61680 61680 240 61243 61590 61852
241 61937 61937 61937 241 61505 61854 62107
242 62194 62194 62194 242 61768 62120 62363
243 62451 62451 62451 243 62033 62387 62619
244 62708 62708 62708 244 62297 62654 62874
245 62965 62965 62965 245 62563 62921 63130
246 63222 63222 63222 246 62830 63189 63385
247 63479 63479 63479 247 63099 63458 63640
248 63736 63736 63736 248 63368 63726 63895
249 63993 63993 63993 249 63637 63994 64147
250 64250 64250 64250 250 63907 64262 64400
251 64507 64507 64507 251 64177 64529 64651
252 64764 64764 64764 252 64448 64796 64902
253 65021 65021 65021 253 64719 65062 65151
254 65278 65278 65278 254 64991 65329 65401
255 65535 65535 65535 255 65263 65535 65535

[madshi]

I was thinking about this option and I'm not sure if it makes sense at all but isn't it possible to only rerender frames one by one and substitute them in the queues one by one so if madVR runs out of time for rerendering all of them not to drop frames but to use the ones rendered at the lower debanding strength?
Possible in theory, very very complicated in practise, due to the queue design.

Right, but I'm sure you could easily detect that an "image source" filter is fueling the graph?
And what happens if you view images through LAV Splitter?

LL corrected dither looks amazing, when watching anime even 3-bit looks pretty good. At 4-bit (ED2 colored, dynamic) the image is only a bit noisy. Wow, think of those 256 color images from 1995, they could have looked so much better.

Using the linear2 build and playing with 1-bit dither I noticed colored dots even with "use colored noise" disabled, is this expected? I can see faint pink dots in the 1-Grayscale Ramp.mp4 even at 4-bit. The colored dots do become more numerous with "use colored noise" enabled. This is without my 3DLUT active; "this display is already calibrated" is selected.

EDIT: Ah! this is due to my gamma ramps. I am using overlay mode, of course, so both my 3DLUT or gamma ramps happen before dithering. At 1 bit any attempt to correct the white point by removing blue or adding red become little spots of color. This is actually a very nice way to visualize a calibration. :D
With "disable gamma ramps" enabled all extra colors go away. The 1-bit colored dither does manage to do a pretty good job hitting the white point too, amazing. :eek:
:)

I tested this and Gamma dithering wins by a large margin in 4bit. Linear produces lots of banding and crushes colors near-black.
Linear Looks better to me on your two comparison links... just saying :)
Wow, on my display Source vs. Linear looks much better than Source vs. Gamma too.
Linear Light looks better by far here as well...
I agree with QBhd, Asmodian and nautilus7, your linear light screenshot looks much better here.

I don't think using 1-bit or any lower bitdepth is the best to prove a point one way or the other. I mean with 1bit, sure gamma dithering (left) appears too bright, but linear dither (right) in the latest build appears too dark for what should be 50% gray (center).
Seriously?!? The center gray in your screenshot is **NOT** 50% gray. 50% would be 128,128,128, while in your screenshot the center gray is 149,149,149, which totally skews the screenshot to your favour. Here's a proper comparison:

http://madshi.net/ditherTest2.png

If you step away far enough from the screen to make the dither noise disappear, the linear light dithering looks near to the correct gray shade, while the gamma light dithering looks totally wrong. (Maybe the linear light dithering is a touch too dark, I'm not sure, can't step away far enough from my screen, already have my back to the wall).

I agree that testing with low-bitdepths is not ideal. But sometimes it helps to go to extremes to prove a point. The point is: With a 1.5 value, using 50% pixels of each dithering shade does not correctly reproduce how our eyes work. I believe this is an important point to make, and I think I sufficiently proved this.

So to me it looks like gamma light consistently brightens the source - 4-bit looks like the original but with brighter dots layered on top. Linear light actually looks closer in terms of average brightness, although because it introduces more darker dots it looks like the average 'error' is greater.

Near black, gamma light clearly wins for me as well, and I think that does have to do with the transfer function not including a linear section (where my monitor, which is calibrated to Rec.709, expects one). I suspect that the average would still be correct if my monitor was calibrated to a straight up power law transfer function, though I'd have to recalibrate to confirm it.
Yes, this is to be feared at low bitdepths: If your display is calibrated with a linear segment, linear light dithering in low bitdepths (with the current 2.222 pure power curve) will make dark areas too dark. But I think this should not be a problem at 8bit.

With my display calibration enabled, the Gamma screenshot is perfectly smooth and a near identical match to the Source screenshot. Linear screenshot has banding.

With my display calibration disabled, the Linear screenshot is perfectly smooth and a near identical match to the Source screenshot. Gamma screenshot has banding.
Are you using windowed, windowed overlay, or FSE?

I notice different dither behavior if I let madVR dither after my calibration corrections (overlay) vs before them. I also have my screen calibrated close to BT.1886 but it is an IPS LCD. (dispcal -g2.4 -f0 -k0)
Good catch, Asmodian. I'm not sure I would have thought of that.

General conclusion: Linear light dithering is unsuitable for use with a GPU gamma ramp enabled, or any other adjustments applied after madVR performs dithering. If I use Overlay mode with madVR applying my gamma ramp via shaders, there is no issues with linear light dithering (as expected). Unfortunately, this is not as practical for madVR to do with Windowed or FSE mode.
I can fully agree with this general conclusion, at least when talking about low bitdepth tests. I'm not sure if the same is true for 8bit. But in any case, I've always recommended that calibrations should be done without using the GPU gamma ramps. Overlay mode applies the 1D gamma ramps in the best possible way. Since you get a noticeably different result in Overlay mode compared to windowed mode that just goes to show how bad the GPU hardware is at applying the gamma ramps.

It's understandable that if the GPU gamma ramps are applied after dithering, they will modify the exact shades that were used for dithering. Which screws up the careful math madVR has done. Ideally madVR's output should be left untouched. But then, this is probably only a problem at rather low bitdepths. I suppose at 8bit, the problem with the GPU gamma ramps affecting the dithering shades will be much smaller (if visible at all).

The key point I was trying to make in my discussion with you is that gamma dithering is simply not correct (at any bitdepth), and linear light dithering is generally better suited to let our eyes see the correct shades. Ok, so you found circumstances in which linear light dithering (maybe only at low bitdepths) runs into trouble, caused by the GPU wreaking havoc on madVR's output. But this doesn't change the fact that scientifically, linear light dithering generally produces more correct results for our eyes. Which exact transfer function should be used is another topic for discussion, of course.

@madshi did anything ever come of that hybrid 8bit 3DLUT + attached 16bit RGB Gamma ramp (for madVR to load via shaders) format you were talking about long ago with Graeme? I haven't been paying attention to recent developments.
ArgyllCMS now has a -H switch (IIRC) which appends the GPU gamma ramps to the 3dlut file, which will result in madVR automatically loading the GPU gamma ramps into the GPU. This feature was added based on user request, and with Graeme's strong support. Personally, I don't like the GPU gamma ramps *at all*. With digital output, they are doing their work at 8bit, which is a catastrophe.

Otherwise, maybe it would be useful to have a special toggle to have madVR disable the active GPU gamma ramp and reload it via madVR shaders with Windowed and FSE mode as well. Last time I tested this though (long ago), I had superior results with my GPU's hardware gamma ramp compared to madVR applying the ramp via shaders.
I don't understand why this would be preferable over using a straight 3dlut without any GPU gamma ramps. In both cases during video playback the GPU gamma ramps would be set to linear, so in both cases desktop applications would not be calibrated at all as long as video plays. So why using 1D ramps for madVR at all? I'd recommend to instead create a clean and simple 3dlut for madVR with no separate 1D ramps.

madshi, did you ever try out Rec.709 or sRGB for the transfer function used for linear light dithering? Here they are again in shader-friendly form:

Rec.709:return (gammaValue < 0.081 ? 0.2215435 * gammaValue : pow(0.9099181 * (gammaValue + 0.099), 2.222222));
sRGB:return (gammaValue < 0.03928571 ? 0.07738015 * gammaValue : pow(0.9478673 * (gammaValue + 0.055), 2.4));

I suspect either of these will look much better on my monitor, but maybe I should just bite the bullet and recalibrate to a different target..
I didn't try. But yes, at low bitdepths of course there's a great benefit to be had by matching the dithering transfer function to your display calibration. But this benefit should mostly vanish at 8bit because due to the way the linear light dithering tweak works, in 8bit all 256 8bit integer steps are not dithered at all and thus perfectly reproduce your display's calibrated transfer function. So I think in 8bit there will probably not be a visible difference between using a pure power curve or using a BT.709 transfer function for linear light dithering. The important thing is to get away from the incorrect 1.0 gamma curve gamma dithering uses.

Not sure if this is useful..however, here is how I saw the comparisons between linear and gamma:

Viewing them via Screenshot Comparison I was positive something was amiss. Linear was noticeably smoother than gamma - banding in gamma was more noticeable in the darker region. The dithering seemed to extend right up to the black edge. It was in reverse to what you claimed to see - to the point I was going to ask that perhaps you had reversed the images.

I downloaded and viewed them in the Picasa image viewer. At native resolution I had the same impression. Then I zoomed..it was very apparent that the linear shot had quite severe banding while gamma remained fairly smooth.
You need to be very careful with zooming heavily dithered images. You will only get correct results when doing the zooming in linear light, which no usual image viewer does. You should only view dithered images in 100%. Or if you have to zoom in, use nearest neighbor scaling, because nearest neighbor does not modify the dithering shades.

Strange... I can still change dithering depth from the menu with Random Dithering (it takes effect).
Isn't that supposed to be gone with the latest LinearLight2 test build?
I've explained it in very very high detail in one of my recent posts in this thread. Just look back 2-4 pages or so.

I just tried that test and I really cannot see a difference in gamma at 1 bit, 2 bit, or 4 bit between playing and paused ED2 mono dynamic.
Same here.

[qduaty]

I have the following problem: cannot quadruple DVD content with nnedi3 at 50 fps, by any means. The card is GTX 660, and the best rendering time I achieved with madVRfinalDither4 was 27 ms. So it is clear that nnedi3 needs to be faster. I got some random thoughts.

@madshi, what do you think:

1. Isn't reading weights from const __global pointer, slower compared to __constant?
2. Implementing nnedi3 as a pixel shader, and dealing with four additional draws instead of interop cost?

[James Freeman]

Strange... I can still change dithering depth from the menu with Random Dithering (it takes effect).
Isn't that supposed to be gone with the latest LinearLight2 test build?
I've explained it in very very high detail in one of my recent posts in this thread. Just look back 2-4 pages or so.

Thanks, found it.



I just tried that test and I really cannot see a difference in gamma at 1 bit, 2 bit, or 4 bit between playing and paused ED2 mono dynamic.
Same here.

I've updated my conclusion about this matter: Here (http://forum.doom9.org/showthread.php?p=1672664#post1672664)
You got iron patience madshi, and I appreciate you for that very much.

[6233638]

Seriously?!? The center gray in your screenshot is **NOT** 50% gray. 50% would be 128,128,128, while in your screenshot the center gray is 149,149,149, which totally skews the screenshot to your favour. Here's a proper comparison:

http://madshi.net/ditherTest2.png

If you step away far enough from the screen to make the dither noise disappear, the linear light dithering looks near to the correct gray shade, while the gamma light dithering looks totally wrong. (Maybe the linear light dithering is a touch too dark, I'm not sure, can't step away far enough from my screen, already have my back to the wall).Which is supposed to be which? I assume the one on the right is Linear Light, as it looks much closer to the center patch.

Edit: Blurred:
http://abload.de/img/blurredt6pk0.png

[madshi]

1. Isn't reading weights from const __global pointer, slower compared to __constant?
I had already tried that myself, it wasn't any faster on my AMD, and for some GPUs the weight array is too large to fit into the constant memory. According to my tests, the real performance cost comes from all the math, not from reading the pixels or weights.

2. Implementing nnedi3 as a pixel shader, and dealing with four additional draws instead of interop cost?
I had tried implementing NNEDI3 as a pixel shader many months ago, performance was atrocious. Like 100x times slower or something like that. When using a pixel shader, I'd have to read 32 source pixels for each output pixel, plus all the weights. This slows everything down to a crawl. The OpenCL NNEDI3 kernel uses shared memory to buffer the pixel reads. Which means the bottleneck is now the math. The pixel shader was limited by memory reads instead.

EDIT:
It does not happen on my quicker IPS or TN.
Only on my AMVA which apparently is extremely slow (and have off center contrast shift).
Makes sense. I'm on IPS here. FWIW, I believe this problem you noticed only occurs with low bitdepths. E.g. at 1bit dynamic dithering can change one pixel from black to white from one frame to the next, and then back to black one frame later. Your panel might be too slow for that. But at 8bit, dynamic dithering will only change pixels from e.g. 128 to 129 and back. Your display will probably have no problems with that.

Which is supposed to be which? The one on the right looks much closer to the center patch.
Sorry, probably should have made it clear. The one on the right is linear light dithering. The one on the left gamma light dithering.

-------

@cyberbeing, here's another try. Which dithered image looks nearer to the original?

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (http://madshi.net/avatar2bitLinear.png) -|

Yes, it's a very low bitdepth (2bit) again, but this really does help to prove the point.

Edit: Please make sure you watch these at 100%.

[nevcairiel]

Which is supposed to be which? I assume the one on the right is Linear Light, as it looks much closer to the center patch.

I agree, if you take a step back and then squint at the screen, it'll make middle and right look nearly identical.
So if right is linear, then its clearly superior.

[iSunrise]

Seriously?!? The center gray in your screenshot is **NOT** 50% gray. 50% would be 128,128,128, while in your screenshot the center gray is 149,149,149, which totally skews the screenshot to your favour. Here's a proper comparison:

http://madshi.net/ditherTest2.png

If you step away far enough from the screen to make the dither noise disappear, the linear light dithering looks near to the correct gray shade, while the gamma light dithering looks totally wrong. (Maybe the linear light dithering is a touch too dark, I'm not sure, can't step away far enough from my screen, already have my back to the wall).
Yep, same here. The linear light dithered rectangle is a lot closer to the source brightness than the gamma light one. Also, in all of the tests I did, I get the exact the same results like in this example you just gave. Gamma light dithering is too bright when viewed at lower bit depths, the positive though, is that you can see more details, which - by increasing the bit depth slowly - the linear light dithering will quickly make up for when you´re increasing the bit depth again.

Which exact transfer function should be used is another topic for discussion, of course.
Indeed.

I didn't try. But yes, at low bitdepths of course there's a great benefit to be had by matching the dithering transfer function to your display calibration. But this benefit should mostly vanish at 8bit because due to the way the linear light dithering tweak works, in 8bit all 256 8bit integer steps are not dithered at all and thus perfectly reproduce your display's calibrated transfer function. So I think in 8bit there will probably not be a visible difference between using a pure power curve or using a BT.709 transfer function for linear light dithering. The important thing is to get away from the incorrect 1.0 gamma curve gamma dithering uses.
Couldn´t you just do this by coupling the appropriate transfer functions to the "this display is currently calibrated to the following primaries / gamut" drop-down box? For optimal sRGB settings we would need to add sRGB in that case, though.

[James Freeman]

@cyberbeing, here's another try. Which dithered image looks nearer to the original?

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (http://madshi.net/avatar2bitLinear.png) -|

Yes, it's a very low bitdepth (2bit) again, but this really does help to prove the point.

Edit: Please make sure you watch these at 100%.

Gamma looks closer.
I think 2.2 (1/0.45) is too dark and 1 (GL) is too bright.

We should test more with Asmodian's shader and see what gamma actually fits the original.

[iSunrise]

@cyberbeing, here's another try. Which dithered image looks nearer to the original?

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (http://madshi.net/avatar2bitLinear.png) -|

Yes, it's a very low bitdepth (2bit) again, but this really does help to prove the point.

Edit: Please make sure you watch these at 100%.
I don´t think that this one does particular help to prove your previous point, it´s quite the opposite for me. In that comparison, IMHO the gamma light shot looks a lot closer to the original. It´s not even close.

I´m viewing these shot with sRGB calibration (with a perfect step reproduction of all values from 0-255) on my IPS LCD.

BUT this is at 2bit.

[6233638]

@cyberbeing, here's another try. Which dithered image looks nearer to the original?

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (http://madshi.net/avatar2bitLinear.png) -|

Yes, it's a very low bitdepth (2bit) again, but this really does help to prove the point.Gamma is far too light, but Linear is also too dark compared to the original.

Blurred and resized (in linear light) to make the comparison easier.

Gamma (abload.de/img/gamma-lightfyorf.jpg) -|- Linear (http://abload.de/img/linear-lightu6r27.jpg) -|- Original (http://abload.de/img/original4xrlu.jpg)

Perhaps try 1/0.51 (or better yet, the BT.709 curve, rather than an approximation)

[madshi]

Couldn´t you just do this by coupling the appropriate transfer functions to the "this display is currently calibrated to the following primaries / gamut" drop-down box?
We've discussed this before (see last 10 pages or so).

Gamma looks closer.
I believe you probably watched these zoomed and not at 100%. Try again... :p

I don´t think that this one does particular help to prove your previous point, it´s quite the opposite for me.

In that comparison, IMHO the gamma light shot looks a lot closer to the original. It´s not even close.
Argh. Come on, guys. Which part of "Please make sure you watch these at 100%" did you not understand?

Gamma is far too light, but Linear is also too dark compared to the original.

Blurred and resized (in linear light) to make the comparison easier.
Did you do the blurring in linear light, too? And which gamma curve did you use to convert between gamma <-> linear? These things make a big difference.

[Ver Greeneyes]

here's another try. Which dithered image looks nearer to the original?

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (http://madshi.net/avatar2bitLinear.png) -|
Linear light does great on midtones and highlights, but terrible near black. Gamma light brightens the image across most of the range but maintains the details in dark areas. (and yes, I looked at them in 100%)

[iSunrise]

Argh. Come on, guys. Which part of "Please make sure you watch these at 100%" did you not understand?
ARGH, sorry, didn´t realize you did them at 1:1 movie size and that I could zoom into them. You´re right. Linear light is closer, overall. It really takes a bit getting used to the thought of completely incorrect results when not viewed at the native resolution.

Ver Greeneyes posted a good summary of what we´re seeing here. The overall image looks more accurate, while we lose detail especially in the black areas. And gamma light seems to brighten up the whole image to such an extend that the dithering seems to be more accurate at darker areas.

If there´s a way to improve this, I think we would all be satisfied with linear light.

[6233638]

Did you do the blurring in linear light, too? And which gamma curve did you use to convert between gamma <-> linear? These things make a big difference.Yes, when you use Photoshop in 32-bit mode (rather than 8-bit) it performs all operations in linear light.

I suppose it will have used their sRGB profile, as they are untagged images.
I'm not sure if that's 1/0.45 or the actual sRGB curve. (probably the latter?)

[James Freeman]

madshi, no mater how you turn it, 1/0.45 clearly does not cut it.
It should be a little brighter.

[madshi]

Linear light does great on midtones and highlights, but terrible near black. Gamma light brightens the image across most of the range but maintains the details in dark areas. (and yes, I looked at them in 100%)
True, but this again just poses the question which transfer function to use, and not whether gamma dithering would be better. The point I'm trying to make is that linear light dithering is generally more accurate than gamma light dithering. Which transfer function should be used for linear light dithering is a topic of its own.

Yes, when you use Photoshop in 32-bit mode (rather than 8-bit) it performs all filters in linear light.

I suppose it will have used their sRGB profile, as they are untagged images.
I'm not sure if that's 1/0.45 or the actual sRGB curve. (probably the latter?)
I'm not sure. In any case the choice of the transfer curve will influence how bright/dark the final image will get. So I don't think your blurring & zooming trick properly shows whether the linear light dithered image is darker than the original or not. In real life this depends mostly on whether the transfer function used by madVR for linear light dithering matches the display calibration. If it does, the overall brightness will be perfect, otherwise it will be slightly off (too dark or too bright).

[iSunrise]

madshi, no mater how you turn it, 1/0.45 clearly does not cut it.
It should be a little brighter.
Certainly not for all the values, though. The problem is that the linear part at lower bit depth bites us in the ass with the currently used transfer function, while with brighter values it quickly makes up for the overall WAY too bright gamma light image.

[cyberbeing]

Seriously?!? The center gray in your screenshot is **NOT** 50% gray. 50% would be 128,128,128, while in your screenshot the center gray is 149,149,149, which totally skews the screenshot to your favour.
You're correct, but I'm not sure how that happened... :confused: I think it was a Photoshop quirk with pasting images it detects as grayscale (and applies custom gray gamma). It wasn't intentional in any case, I just wasn't paying close enough attention to re-verify the values.


Here's a proper comparison:

http://madshi.net/ditherTest2.png

If you step away far enough from the screen to make the dither noise disappear, the linear light dithering looks near to the correct gray shade, while the gamma light dithering looks totally wrong. (Maybe the linear light dithering is a touch too dark, I'm not sure, can't step away far enough from my screen, already have the back to the wall).
The linear light one is arguably closer, but definitely still appears much much darker than the center block. But that's 1bit dithering, so what can you expect.

I agree that testing with low-bitdepths is not ideal. But sometimes it helps to go to extremes to prove a point. The point is: With a 1.5 value, using 50% pixels of each dithering shade does not correctly reproduce how our eyes work. I believe this is an important point to make, and I think I sufficiently proved this.
...
I can fully agree with this general conclusion, at least when talking about low bitdepth tests. I'm not sure if the same is true for 8bit. But in any case, I've always recommended that calibrations should be done without using the GPU gamma ramps. Overlay mode applies the 1D gamma ramps in the best possible way. Since you get a noticeably different result in Overlay mode compared to windowed mode that just goes to show how bad the GPU hardware is at applying the gamma ramps.

It's understandable that if the GPU gamma ramps are applied after dithering, they will modify the exact shades that were used for dithering. Which screws up the careful math madVR has done. Ideally madVR's output should be left untouched. But then, this is probably only a problem at rather low bitdepths. I suppose at 8bit, the problem with the GPU gamma ramps affecting the dithering shades will be much smaller (if visible at all).

The key point I was trying to make in my discussion with you is that gamma dithering is simply not correct (at any bitdepth), and linear light dithering is generally better suited to let our eyes see the correct shades. Ok, so you found circumstances in which linear light dithering (maybe only at low bitdepths) runs into trouble, caused by the GPU wreaking havoc on madVR's output. But this doesn't change the fact that scientifically, linear light dithering generally produces more correct results for our eyes. Which exact transfer function should be used is another topic for discussion, of course.
Yeah, it just seems that for GPU gamma ramps to function as expected they need "gamma light" dithering. With linear light dithering they seem to battle against each other, at least with gamma ramps which were calibrated explicitly to achieve a visually linear response (like L*). Even in 8-bit, something unexpected could still occur which ruins effectiveness of a linear dither. To play it safe, I'd probably just stick with gamma dither when using a GPU gamma ramp, and use linear dither otherwise.

ArgyllCMS now has a -H switch (IIRC) which appends the GPU gamma ramps to the 3dlut file, which will result in madVR automatically loading the GPU gamma ramps into the GPU. This feature was added based on user request, and with Graeme's strong support. Personally, I don't like the GPU gamma ramps *at all*. With digital output, they are doing their work at 8bit, which is a catastrophe.
Meh, if madVR doesn't load the ramp via shaders, this feature isn't useful to me.

I don't understand why this would be preferable over using a straight 3dlut without any GPU gamma ramps. In both cases during video playback the GPU gamma ramps would be set to linear, so in both cases desktop applications would not be calibrated at all as long as video plays. So why using 1D ramps for madVR at all? I'd recommend to instead create a clean and simple 3dlut for madVR with no separate 1D ramps.
Honestly, applying a calibration directly to an 8bit 3DLUT behaves horribly with Argyll CMS. Using a 3DLUT without a GPU gamma ramp doesn't allow me to target the custom gamma response I desire. I strongly encourage you to consider an option for loading a GPU gamma ramp with madVR via shaders for Windowed & FSE mode as well:

[X]Disable GPU Gamma Ramp Globally
....[X]Reload GPU Gamma Ramp via Shaders

[James Freeman]

I've disabled the LL in the settings and Enabled Asmodian's shader to find the perfect value.
1.90 is much closer than 2.20 (in my experience).

But what really bothers us is the tail in the black region.

[turbojet]

What could cause overlay to be much darker and saturated then windowed and fse on a tv?

Overlay looks fine with the same setup on a monitor.

[cyberbeing]

@cyberbeing, here's another try. Which dithered image looks nearer to the original?

|- gamma (http://madshi.net/avatar2bitGamma.png) -|- original (http://madshi.net/avatar8bit.png) -|- linear (http://madshi.net/avatar2bitLinear.png) -|

Yes, it's a very low bitdepth (2bit) again, but this really does help to prove the point.

Edit: Please make sure you watch these at 100%.

I concur that Gamma light looks closer to the original there. In some ways I actually prefer it over the original since it enhances shadow detail. Linear light is way too dark, crushed shadow detail, and all those green color tones are thrown way off their original hues and saturations.

[James Freeman]

What could cause overlay to be much darker and saturated then windowed and fse on a tv?
Overlay looks fine with the same setup on a monitor.

darker and saturated?
Sounds like windows is changing to 16-bit in overlay mode with the TV.
Or an HDMI range problem.

[Ver Greeneyes]

True, but this again just poses the question which transfer function to use, and not whether gamma dithering would be better. The point I'm trying to make is that linear light dithering is generally more accurate than gamma light dithering. Which transfer function should be used for linear light dithering is a topic of its own.Yeah, I honestly don't know what to make of it. It's clear that linear light loses some of the detail near black - but is this because it's objectively wrong in some sense or is it just that this amount of detail is the best that can be achieved in that bit depth without brightening the image as gamma light does? I can say that linear light dithering is visibly different near black even in 8-bit on my monitor (probably most noticeable on a gradient test pattern though), but my calibration might just be emphasizing differences near black beyond what the encoding intended.

FWIW, the transfer function I calibrated my monitor to is Rec.709 but with the viewing conditions adjusted to those of sRGB (dispcal -g709 -a64). This should be a close match for the 'intended' viewing conditions, and should also be similar to BT.1886 (which doesn't have the linear segment, but does start out more steeply the higher your monitor's black point is). With linear light dithering it seems I would be better off calibrating to x^1/0.45 with an output offset - although I wonder whether enabling linear light dithering during calibration (is ordered dithering affected?) would automatically compensate.

[James Freeman]

I concur that Gamma light looks closer to the original there. It some ways I actually prefer it over the original since it enhances shadow detail. Linear light is way too dark with crushed shadow detail.

madshi, try 1.90 (1/0.52) much better.

Some parts look a little dark others look a little bright.

[6233638]

I'm not sure. In any case the choice of the transfer curve will influence how bright/dark the final image will get. So I don't think your blurring & zooming trick properly shows whether the linear light dithered image is darker than the original or not. In real life this depends mostly on whether the transfer function used by madVR for linear light dithering matches the display calibration. If it does, the overall brightness will be perfect, otherwise it will be slightly off (too dark or too bright).You're right - I just tried it after assigning different profiles to the images prior to the linear light conversion step and it is using whichever profile is assigned to the image. (sRGB for untagged images)
After using a profile with a 2.2 gamma, it does still look too dark near black.

However, viewing on a retina macbook at 100% size from a distance, to make it as small as possible, the linear light image actually seems too bright near black.

If possible, I would like to see the results from 0.51, the BT.709 curve, and maybe 2.4 gamma though.

[madshi]

I've disabled the LL in the settings and Enabled Asmodian's shader to find the perfect value.
1.90 is much closer than 2.20 (in my experience).
You know what this *really* means? It means that your display is probably calibrated to about 1.90.

Honestly, applying a calibration directly to an 8bit 3DLUT behaves horribly with Argyll CMS. Using a 3DLUT without a GPU gamma ramp doesn't allow me to target the custom gamma response I desire.
The trick is to do a 1D gamma ramp calibration first via ArgyllCMS, but then to "merge" the final 1D gamma ramps into the 3dlut. That's what the "-a" switch (IIRC) is for instead of "-H". Basically the end result is similar to what you probably get now in Overlay mode - except that letting ArgyllCMS do all this will end up being even more exact, because ArgyllCMS will do the math in 64bit floating point and madVR can then perform the whole thing in one step (which means less LUT interpolations).

What could cause overlay to be much darker and saturated then windowed and fse on a tv?
Probably Overlay outputs 0-255 and windowed and FSE outputs 16-235. Just a guess, though.

I concur that Gamma light looks closer to the original there. It some ways I actually prefer it over the original since it enhances shadow detail. Linear light is way too dark with crushed shadow detail.
"concur" suggests that you agree with the others. But everybody else changed their opinion after I pointed out to them that they accidently viewed the images zoomed even though I explicitly stated that you need to take extra care to view them at 100%. If you don't view them at 100% you'll get totally incorrect results because the browser scales them in gamma light, and scaling heavily dithered images in gamma light produces totally incorrect results. Did you view them at 100%?

Please don't concentrate on shadow detail, only. Of course brightening up dark areas will improve shadow detail. But the key thing to look at is if the overall image looks correct (in terms of brightness and gamma response). Shadow detail at 2bit dithering of course is expected to suffer. FWIW, watching this in motion with 2bit dithering (especially using the "dynamic" option) greatly improves shadow detail. It's much better in motion than it appears on the screenshots.

Yeah, I honestly don't know what to make of it. It's clear that linear light loses some of the detail near black - but is this because it's objectively wrong in some sense or is it just that this amount of detail is the best that can be achieved in that bit depth without brightening the image as gamma light does? I can say that linear light dithering is visibly different near black even in 8-bit on my monitor (probably most noticeable on a gradient test pattern though), but my calibration might just be emphasizing differences near black beyond what the encoding intended.
Hmmmm...

-------

Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

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

Again, make sure you watch these at 100%. Having your browser zoom these will totally screw up everything.

The key point to take from this screenshot comparison is that dithering in gamma light is not correct. I hope everybody can agree with that now? Which image looks best to you will directly depend on how your display is calibrated. The image created with the transfer function nearest to your display calibration should look nearest to the original 8bit image to your eyes.

[James Freeman]

Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

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


sRGB 2.4 looks closest (much better than 2.2), still just a tad dark.
Gamma Light is out of the question.

Can you edit and add sRGB 2.2 too?

I can de-focus my retina at will for these tests, so no wall climbing for me... :D

[6233638]

I think what is throwing people off, is that the images dithered in gamma light do preserve the most amount of shadow detail, and make that all the more obvious by brightening it up.
From that selection, the pure power 1/0.45 is definitely closest to the original - though it does still look a bit bright when I compare it on the macbook.

The thing is, you really have to view it on a small screen from a distance so that you are focused on the image and not the dithering.
When I get too close to my screen, my preference changes.

[turbojet]

Originally Posted by turbojet View Post
What could cause overlay to be much darker and saturated then windowed and fse on a tv?
Probably Overlay outputs 0-255 and windowed and FSE outputs 16-235. Just a guess, though.

You are probably right. If I set tv to 16-235 in madvr it looks better but still a bit dark but then I get crushed blacks in windowed/fse. nvidia cp setting had no effect, is there any way to fix this here or is it a madvr issue?

[James Freeman]

When I get too close to my screen, my preference changes.
Yep,
What will translate better in 8-bit, Sharp or Defocused?

[iSunrise]

Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

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

The key point to take from this screenshot comparison is that dithering in gamma light is not correct. I hope everybody can agree with that now? Which image looks best to you will directly depend on how your display is calibrated. The image created with the transfer function nearest to your display calibration should look nearest to the original 8bit image to your eyes.
Thanks a lot for these. They are perfect examples where you can see that linear light does a huge difference (at least for me).

If I view these with a sRGB calibration target, the "linear (sRGB 2.4)" is simply perfect. No brightness change whatsoever, just a perfect reproduction of the original with the few bits that are available (extremely impressive to look at).

In comparison, the "linear (pure power 1/0.45)" loses a lot of detail again and is darker, but this seems to be expected, cause I am calibrated to sRGB.

So I would say that we finally nailed it. Now you just need to include this into madVR and I think we should all be satisfied.

[6233638]

Yep,
What will translate better in 8-bit, Sharp or Defocused?I think people will pick the sRGB image if they are too close to their display.
The 1/0.45 image is the one which is actually closest to the source though. (yet it is still too bright near black)

This is why I'm doing testing at 100% size on a retina macbook. The image is only about 6x4" in size, so I can make the comparison without defocusing my eyes.

[iSunrise]

I think people will pick the sRGB image if they are too close to their display.
The 1/0.45 image is the one which is actually closest to the source though. (yet it is still too bright near black)
I actually tested both to be sure. Very close to the display and at 3-4 meters distance from it.

And for both of these cases, the sRGB 2.4 example is a very tiny amount brighter in darker shades (almost indetectable), while the 1/0.45 image is _noticeably_ darker.

That´s on a display with perfect reproduction of all 0-255 shades of grey and sRGB calibration. Results may differ if the display is not able to show really dark shades or if someone chose a customized sRGB target, though.

[James Freeman]

If I view these with a sRGB calibration target, the "linear (sRGB 2.4)" is simply perfect.
In comparison, the "linear (pure power 1/0.45)" loses a lot of detail again and is darker, but this seems to be expected, cause I am calibrated to sRGB.
Agreed.
sRGB 2.4 definitely better than Pure Power 2.2.

I think people will pick the sRGB image if they are too close to their display.
The 1/0.45 image is the one which is actually closest to the source though. (yet it is still too bright near black)
This is why I'm doing testing at 100% size on a retina macbook. The image is only about 6x4" in size, so I can make the comparison without defocusing my eyes.

I think defocustin is a big part of this test because we are testing how the eye sees light not detail.

And for both of these cases, the sRGB 2.4 example is a very tiny amount brighter (almost indetectable),
For me its brighter when focused and darker when defocused... What will equate better at higher bit depths?
Still much better than Power Curve.

[cyberbeing]

The trick is to do a 1D gamma ramp calibration first via ArgyllCMS, but then to "merge" the final 1D gamma ramps into the 3dlut. That's what the "-a" switch (IIRC) is for instead of "-H".
That's not a trick, that "-a" switch is what I was talking about which always gave horrible results every time I tested it. I've given up on it.

Basically the end result is similar to what you probably get now in Overlay mode - except that letting ArgyllCMS do all this will end up being even more exact, because ArgyllCMS will do the math in 64bit floating point and madVR can then perform the whole thing in one step (which means less LUT interpolations).

I strongly disagree. madVR loading the Gamma ramp in 16bit via Overlay yields superior results to Argyll CMS's attempts at merging it into an 8bit 3DLUT.

madVR loading gamma ramp via shaders = expected results
Gamma ramp loaded into GPU = expected results
Dispcal Calibration merged into 3DLUT with "-a" switch = unexpected results
3DLUT created with gamma which doesn't match your display = unexpected results

Did you view them at 100%?

Please don't concentrate on shadow detail, only. Of course brightening up dark areas will improve shadow detail. But the key thing to look at is if the overall image looks correct (in terms of brightness and gamma response). Shadow at 2bit dithering of course is expected to suffer.
Yes, I viewed them at 100%, outside my browser. The linear light version looks extremely wrong. The colors tones are no longer even close to the original, as I stated before. All the colors in the gamma light version look similar to the hues and saturation of the original. There is really no contest there.


Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

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

Again, make sure you what these at 100%. Having your browser zoom these will totally screw up everything.

The key point to take from this screenshot comparison is that dithering in gamma light is not correct. I hope everybody can agree with that now? Which image looks best to you will directly depend on how your display is calibrated. The image created with the transfer function nearest to your display calibration should look nearest to the original 8bit image to your eyes.

I still find Gamma wins in these new comparisons, as it's closest to hue and saturation of the original. The only image from the linear ones which is not horrible seems to be "linear (BT.709 1/0.45)", but it's still way off in its color tones.

Gamma >> linear (BT.709 1/0.45) >>> linear (sRGB 2.4) >>>>>>> linear (pure power 1/0.45)

P.S. It may be helpful if you did your next comparison with monoColor dithering, to ensure the oppositeColor dithering isn't at fault for these color issues. Also try including a (BT.709 2.4) & (BT.709 2.6) image. One of those curves may come decently close to my calibration, depending how you scale the curves vs Argyll ambient scaling.

[JonnyRedHed]

Ok, there are still 2 things you could do to help find the cause of this problem:

(1) In the situation where playback doesn't work, anymore, create a freeze report (Ctrl+Alt+Shift+Break), and mail it to me. The freeze report should appear as a text file on your desktop. It might take a couple of seconds after you pressed those keys.

(2) Activate the madVR debug mode by double clicking "activate debug mode.bat". After doing this madVR will log everything down to a big log file on your desktop. Be careful, the file will grow very large very quickly. If it takes too long to reproduce the problem, it might make sense to stop zoomPlayer, delete the log file and try again. Otherwise the log file might grow too big (several GBs). Once the problem has occurred, stop zoomPlayer right away. Then zip up the log file (it will compress very well) and send it to me. If the log file is too big to send, you can delete everything until the last maybe 200MB of text. Of course you'll need a tool which can do that. E.g. the freeware HxD should be able to. Zipped up it should be less than 10MB, I think.

Thanks!


:D


I've emailed the log and freeze reports. Log (zipped) was about 14mb.

[madshi]

You are probably right. If I set tv to 16-235 in madvr it looks better but still a bit dark but then I get crushed blacks in windowed/fse. nvidia cp setting had no effect, is there any way to fix this here or is it a madvr issue?
The easiest solution would probably be to use the madLevelsTweaker.exe shipping with madVR to force your GPU to output 0-255 in all modes.

Now you just need to include this into madVR and I think we should all be satisfied.
Which is not what I wanted... :(

That's not a trick, that "-a" switch is what I was talking about which always gave horrible results every time I tested it. I've given up on it.

I strongly disagree. madVR loading the Gamma ramp in 16bit via Overlay yields superior results to Argyll CMS's attempts at merging it into an 8bit 3DLUT.
Ok. When did you last test this? Did madTPG already exist then? If not, it might be worth a try testing this again, just to double check the problem still occurs. madTPG changes things a bit because the whole calibration (even 1D lut creation) runs through madVR this way, using high bitdepth rendering. Even when using ArgyllCMS to create GPU gamma ramps, when using madTPG the GPU gamma ramps are never actually used.

Yes, I viewed them at 100%, outside my browser. The linear light version looks extremely wrong. The colors tones are no longer even close to the original, as I stated before. All the colors in the gamma light version look similar to the hues and saturation of the original. There is really no contest there.

I still find Gamma wins in these new comparisons, as it's closest to hue and saturation of the original. The only image from the linear ones which is not horrible seems to be "linear (BT.709 1/0.45)", but it's still way off in its color tones.
You're looking at everything (shadow detail, hues, saturations) except what I wanted you to look at :), namely overall brightness and gamma response. But I guess it's my fault for using oppositeColor which I knew you hated.

Maybe you can test this yourself with an appropriate movie on your display? Using monoColor, in 2-4bit, then in motion toggle linear light dithering on/off, and also switch between 2-4bit and 8bit. I think you will find that linear light dithering is overall nearer to the original, even if it might not be perfect. At least that's what everybody seems to agree on atm. But then, most users also liked oppositeColor, which you don't like. And leeperry is on your side this time, too. So maybe it is a matter of taste again. But FWIW, I'm sure that linear light dithering produces a more correct overall image brightness and gamma response compared to gamma light dithering.

I've emailed the log and freeze reports. Log (zipped) was about 14mb.
Yeah, thanks, got them. Will look at them later today.

[nevcairiel]

Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

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

Again, make sure you watch these at 100%. Having your browser zoom these will totally screw up everything.

Watching on my PC screen, BT.709 looks the closest watched from a distance for me, although only Gamma has a very obvious difference, for the others its just minimal.

[Audionut]

Looks to me like linear light has less noise, and better preserves edge detail.

edit: Linear (pure power) also has the best overall luminance match.

[James Freeman]

Now you just need to include this into madVR and I think we should all be satisfied.
Which is not what I wanted... :(
What have you planned for us... ;)

The results are all over the place... Gamma for cyberbeing, Power for 6233638, Rec.709 for nevcairiel, sRGB for iSunrise,
I like sRGB with 2.2 or Power with 1.92.
The wanted power values are also ranging from 1.92 to 2.60.

[turbojet]

Quote:
Originally Posted by turbojet View Post
You are probably right. If I set tv to 16-235 in madvr it looks better but still a bit dark but then I get crushed blacks in windowed/fse. nvidia cp setting had no effect, is there any way to fix this here or is it a madvr issue?
The easiest solution would probably be to use the madLevelsTweaker.exe shipping with madVR to force your GPU to output 0-255 in all modes.

Tried that in both user mode and admin mode, which should it be? It had no effect.

[leeperry]

And what happens if you view images through LAV Splitter?
PotP won't let me select the image source filter AFAIK, it'll always be "Image source". It would be most amazing if you could nail down the name of the still images source filters used in PotP & MPC and provide a picture-viewer mode in mVR that would kill all black frames(that keep coming and going more or less randomly, making it very hard to use) and allow to setup a custom profile with 256 neurons all the way :devil:

you're looking at everything (shadow detail, hues, saturations) except what I wanted you to look at, namely overall brightness and gamma response. But I guess it's my fault for using oppositeColor
I also much prefer GL in all the screenshots you posted(at 100% scaling) but then again OC is not my thang :p

[madshi]

Watching on my PC screen, BT.709 looks the closest watched from a distance for me, although only Gamma has a very obvious difference, for the others its just minimal.
Yeah, makes sense.

edit: Linear (pure power) also has the best overall luminance match.
That matches what I see here, but it depends on the display calibration.

Tried that in both user mode and admin mode, which should it be? It had no effect.
Did you reboot after using madLevelsTweaker? If that doesn't help then something else is going on. Make sure you disable (and set to neutral values) all options in the GPU control panel like color/gamma adjustments, dynamic contrast, skin tone adjustments, etc etc. Maybe a driver cleaning and reinstall will help? I'm not sure what else to suggest...

[iSunrise]

If I switch from the sRGB to my Rec.709 calibration target, the BT.709 example suddenly is also closest (which is expected, I guess).

So this really is directly bound to the calibration itself.

[Werewolfy]

My hook/hack should in theory also work in Windows 8, not sure why it's not working for you.


If you have any idea later, I can test or make a debug log for everything you want. I tried different settings, desactivated Reclock, ffdshow,... but it doesn't change anything. I would like to use FSE mode, it's frustrating to see that when the movie begins, madVR switches correctly to 24hz but at the moment I go in full screen it switches to 23hz whatever I do.

To all users on Windows 8 : does it work for you? I can't be the only one... I guess. It's really weird because my setup is very close to 6233638's setup.


Here's the Avatar dithering comparison again, with added images using different transfer functions for linear light dithering:

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

Again, make sure you watch these at 100%. Having your browser zoom these will totally screw up everything.

The key point to take from this screenshot comparison is that dithering in gamma light is not correct. I hope everybody can agree with that now? Which image looks best to you will directly depend on how your display is calibrated. The image created with the transfer function nearest to your display calibration should look nearest to the original 8bit image to your eyes.

Personnally I find too that linear light is far closer to the original than gamma light. Between the three, pure power 1/0.45 is the closest one followed by sRGB 2.4 and then BT.709 1/0.45.

[cyberbeing]

Ok. When did you last test this? Did madTPG already exist then? If not, it might be worth a try testing this again, just to double check the problem still occurs. madTPG changes things a bit because the whole calibration (even 1D lut creation) runs through madVR this way, using high bitdepth rendering. Even when using ArgyllCMS to create GPU gamma ramps, when using madTPG the GPU gamma ramps are never actually used.
I've yet to attempt a calibration with madTPG, as I keep forgetting to enable it. I'll eventually run though everything again, but Argyll still seems to have issues with creating 3DLUTs which fail BTB/WTW clipping tests. I'm not particularly encouraged to spend lot of time testing, until that issue is resolved once and for all.

Haha, you're looking at everything (shadow detail, hues, saturations) except what I wanted you to look at, namely overall brightness and gamma response.
None of the images you posted thus far are all that close to overall brightness and gamma response of the original when viewed on my display.

Gamma is brighter than the original. BT.709 2.2 is darker than original. The rest are much, much darker.

Maybe you can test this yourself with an appropriate movie on your display? Using monoColor, in 2-4bit, then in motion toggle linear light dithering on/off, and also switch between 2-4bit and 8bit. I think you will find that linear light dithering is overall nearer to the original, even if it might not be perfect.
What I'd really like to see is a test build which allows me to change the inverse curve used with linear dithering. Please remember that my display is calibrated to a BT.709 curve scaled to ambient light. Essentially it matches BT.709 near-black, and matches L* across the rest of the luminance range. The inverse power curve you are defaulting to with linear dithering, I suspect will always give an extremely inaccurate gamma/brightness result in low bitdepth on my display.

[6233638]

That matches what I see here, but it depends on the display calibration.Perhaps the solution is to have it follow the settings chosen in "this display is already calibrated" then, and add a selection when loading 3DLUTs?

1/0.45 looks best to me from the images you have posted, and not by a small margin. The others are all too bright.

I think it's very difficult to judge on larger screens, because the dithering is not as effective there.

If I switch from the sRGB to my Rec.709 calibration target, the BT.709 example suddenly is also closest (which is expected, I guess). What are you calibrating your screen to? BT.709 content should be viewed using the BT.1886 transfer function (which becomes a flat 2.40 gamma on high contrast displays) and never the BT.709 transfer function, which is intended for capture, not playback.

[James Freeman]

So this really is directly bound to the calibration itself.
Yep,

Now the question remains what would madshi do about it with madVR.

There should be a Standard setting (don't touch if you don't know what it is).
And Customization options for more advanced users or ones that read the thread.

What is the standard gamma curve of modern LCD TVs?