Log in

View Full Version : madVR - high quality video renderer (GPU assisted)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 [451] 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329

Soukyuu
5th February 2014, 01:08
I might be wrong, but didn't he answer that here?
The reason for that is that although DirectCompute in theory supports DX10 GPUs, too, it does so only with a very limited feature set. I'd have to use totally different code to make it all work on DX10 GPUs, and honestly, I think NVidia 2xx and AMD 4xxx users probably don't have the raw speed to make use of the new features, anyway, so I don't feel like spending a lot of additional development resources just to support DX10 GPUs. So I've limited support to native DX11 GPUs.

cyberbeing
5th February 2014, 01:16
Thanks, I missed that.

Kalanoch
5th February 2014, 01:28
Results from DirectCompute test build 3 vs test build 1:

720p->1440p with nnedi3 doubling 16 neurons, debanding and smooth motion on, no options checked in trade quality for performance. CPU queue size 24, GPU queue size 10, 4 backbuffers. Using Windows 7 and nVidia GTX 670.

OpenCL (0.87.4 release):
40.5 ms avg rendering time
1300 MB video memory used
94% GPU load

DC test build 1:
36 ms avg rendering time
1790 MB video memory used
83% GPU load

DC test build 3:
34 ms avg rendering time
1350 MB video memory used
77% GPU load

Works exactly as advertised, a drastic reduction in memory usage combined with a small increase in performance over the first test build. This brings memory usage back in line with OpenCL, but it is actually quite a bit faster now.

As a side note, this is with a file using h264, 10-bit 4:4:4, so Y410 surface. I'm curious, does this affect rendering times over the more common 4:2:0 (P010/NV12)? Like, are there any extra steps, or steps that are skipped?

cyberbeing
5th February 2014, 01:36
There seems to be a minor settings bug with NNEDI3 "chroma upscaling" which causes the last used to not be remembered when you disable it.

kasper93
5th February 2014, 01:36
Why do you even bother to ask about DX10? ED and NNEDI3 are very demanding even on new high-end GPUs. What do you expect with "ancient" GPUs? Like madshi said there would be not enough power. HD4xxx doesn't even gets drivers update from AMD for a year or something. Seriously, madVR will still work but without few features. It's time to move on or accept how things are.

Soon more and more software will drop XP support and I'm sure people will be whining about it, but really it is only trouble for developers to support deprecated APIs and other crap.

DragonQ
5th February 2014, 02:07
Uhm, according to madshi's post back here (http://forum.doom9.org/showthread.php?p=1665894#post1665894), it won't work on either nVidia 2xx nor ati 4xxx
I'm a bit sad about it, my 260GTX is still fully sufficient for my needs otherwise... but oh well.
Intel HD4000, not AMD.

mikecks
5th February 2014, 02:09
Just to clarify, to take advantage of the DirectCompute, I would uncheck 'use random dithering instead of OpenCL error diffusion' within the trade quality for performance options. But only when using the test build that madshi linked, is this correct? thanks.

DragonQ
5th February 2014, 02:14
Just to clarify, to take advantage of the DirectCompute, I would uncheck 'use random dithering instead of OpenCL error diffusion' within the trade quality for performance options. But only when using the test build that madshi linked, is this correct? thanks.
Yes..

cyberbeing
5th February 2014, 02:19
Why do you even bother to ask about DX10?
In my case, it was only pure curiosity about how harmful the limitations of the reduced Compute Shader 4.x API are, in a very general sense, compared to Compute Shader 5.0. I've personally never owned a GPU from the DX10 generation, so I'm unaffected by this either way as far as madVR is concerned. But it makes me wonder for other DirectCompute applications supporting only Compute Shader 4.x, if that harms performance significantly on DX11 GPUs.

ED and NNEDI3 are very demanding even on new high-end GPUs. What do you expect with "ancient" GPUs? Like madshi said there would be not enough power.

Yes they are, but it's not like DirectCompute or OpenCL can only be used for very demanding features. madshi had mentioned considering converting all shader operations in madVR to OpenCL eventually, most of which are very inexpensive in comparison. It makes me wonder now if DirectCompute would instead take this role, with the exception of DXVA, and what that means for future release GPU compatibility of old features in madVR.

drew_afx
5th February 2014, 02:51
dx9 implementation is polished as it can be afaik
old gpus can still run on "old" dx9 optimized madvr
new features not compatible with dx9 needs to be added to its own separate build...just like new gpu drivers are only supported on recent generation cards

ryrynz
5th February 2014, 03:01
It makes me wonder now if DirectCompute would instead take this role, with the exception of DXVA, and what that means for future release GPU compatibility of old features in madVR.

Guess they could just use old builds if it comes to that. Maybe madshi might even maintain older builds with whatever minor changes are made if everything goes OpenCL/DirectCompute.

I would expect though that anyone wanting the quality madVR delivers to have reasonably up to date hardware, it's a classic case of "Do you want to use the latest software? then use the latest hardware."

truexfan81
5th February 2014, 03:21
direct compute build 3 works with my gtx650, even with 24p content error diffusion doubles the gpu usage

Nachbar
5th February 2014, 06:08
I try to set the settings so when I play content my GPU won't go into high performance mode and error diffusion is just enough to do just that. To me, at least, it seems error diffusion is one of the last settings you would do as the other settings have a more noticeable impact.

Still pretty neat though and if directcompute decreases the performance hit on NNEDI3 i will be happy.

James Freeman
5th February 2014, 07:39
Just to clarify how good Error Diffusion is compared to Random Dithering.
These are actual screen shots from MPC-HC+MadVR.

http://www.mediafire.com/convkey/17dc/a42gcrd46hj3ycpfg.jpg

ryrynz
5th February 2014, 08:09
Nice illustration there. For those of you that can't see much of a difference between no dithering and error diffusion, look closer at error diffusion or turn up your brightness and you'll notice the wavy triangle pattern throughout.
It's a pretty big deal, Radeon upgrade for my HTPC in progress.

Wondering, considering the performance improvement from the DirectCompute build, what's the chances of a higher quality version of this being available? I can understand it not being of high priority..

bacondither
5th February 2014, 09:11
@madshi
The error diffusion algorithm creates a static pattern with no temporal dithering and can create strange "worm" patterns. Your code seems to hade static thresholds and could be improved as suggested at Cris's Image Analysis Blog (http://www.cb.uu.se/~cris/blog/index.php/archives/355)
Since this algorithm was published... The most simple and effective one is to add a little bit of randomness to the process, though this is unsuitable for some purposes. In the code above, change the threshold code to read:

% new = 255*(old >= 128);
new = 255*(old >= 128+(rand-0.5)*100);

Regular Floyd Steinberg (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg.png)

Floyd Steinberg with random (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg_noise.png)

I think it would be a cheap way to improve the quality of the error diffusion :)

andybkma
5th February 2014, 09:44
Here is my result with new DirectCompute Error Diffusion Trade Quality for Performance unchecked (v3 tested):

With SD material : (cuvid SD) In FSE mode I definitely see a better video quality but unfortunately my GPU load jumps up to a whopping 75% from 34% without the new DirectCompute dithering. Zoom Player shows slightly higher cpu consumption. Gosh that GPU load jump is just too much even with my overclocked 650M to almost 660M standards. But yes, the image for the SD material is definitely noticeably sharper and clearer and this is even after using avisynth script sharpener LSFMod. No dropped frames

With HD material (cuvid 720p): Again in FSE mode I definitely see better video quality but again my GPU load jumps up to 67% from 27% without the new DirectCompute dithering. Zoom Player shows about the same increase as SD slightly higher cpu consumption. No dropped frames. Note: With both SD & HD material I am also having occasional ZP crashing errors when switching out of FSE to window mode with the new DirectCompute dithering. Hopefully next time it happens I can catch the error number and report it.

But I really can't use this new dithering because it is just killing my gpu. The video quality improvement is great but I already know I will be having to leave this option checked (and use the less intensive random dithering instead). If this new dithering could become less GPU intensive that would be great

DarkSpace
5th February 2014, 09:54
Regular Floyd Steinberg (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg.png)

Floyd Steinberg with random (http://www.cb.uu.se/~cris/blog/matlabimages/dither_floydsteinberg_noise.png)

I think it would be a cheap way to improve the quality of the error diffusion :)
However you look at it, I very much prefer the regular Floyd-Steinberg image over the random one...
Also, it's been said before, but usually movies change every frame (except Anime or cartoons), so you shouldn't be able to see the pattern anyway.

PetitDragon
5th February 2014, 10:04
@madshi
The error diffusion algorithm creates a static pattern with no temporal dithering and can create strange "worm" patterns.....

I confirm that too. :cool:

For you guys want to compare the two dithering methods and see how well they help debanding in real world video, the following clip is a good example (320MB):

https://www.mediafire.com/?yo6brmh02mrjxrs

ryrynz
5th February 2014, 10:21
so you shouldn't be able to see the pattern anyway.

I don't have a powerful enough graphics card to test anime with the error diffusion, can anyone actually see the pattern during viewing?

James Freeman
5th February 2014, 10:21
Did anyone tried so see (zoom in) with actual video content and prove the ED pattern is static?
I don't think the ED pattern is static, its just the screenshots.

EDIT:
Just tested it, it is static.

Vyral
5th February 2014, 10:37
With DirectCompute (v3):

Bilinear (Image + chroma), no deband, error diffusion: 24% GPU load, no dropped frames
Jinc 3 + AR (Image + chroma), medium deband, random dithering: 55% GPU load, no dropped frames
Jinc 3 + AR (Image + chroma), medium deband, error diffusion: 73% GPU load, no dropped frames


Nice :D

Same graphic card and approximately same result. As long as I'm not using Smooth motion, I get no dropped/delayed frames with error diffusion (OpenCL or DirectCompute).
I mainly watch 720p-24/30fps Anime on my 1080p-60Hz monitor. I vaguely remember a discussion from last year about Smooth motion having no benefit with Anime. Therefore, I'm considering to disable smooth motion and to use error diffusion and/or NNEDI with DirectCompute.

I don't have a powerful enough graphics card to test anime with the error diffusion, can anyone actually see the pattern during viewing?
Compared to random dithering, I see no visible pattern.

bacondither
5th February 2014, 11:04
Did anyone tried so see (zoom in) with actual video content and prove the ED pattern is static?
I don't think the ED pattern is static, its just the screenshots.

The error diffusion is static with static input. Images taken with around 1 seconds between(playing a video file of a static pattern).
No contrast enhancements or brightening was applied only 700% zoom.

Image1 (http://s14.postimg.org/4gl94a3y9/ED2_0s.png)

Image2 (http://s8.postimg.org/qa9ntd591/ED2_1s.png)

nevcairiel
5th February 2014, 11:06
Yeah classic Error Diffusion only depends on the input. Give it the same frame and it gives you the same output. Which has both its up and downsides.

James Freeman
5th February 2014, 11:12
Yes, Just tested it.
ED is static and I much prefer it that way (no extra noise).


I just love it...
DeBanding makes video silky smooth for non natively dithered content (super compressed video without dithering, aka. everything you get from the internet).
Blu rays look fantastic with Error Diffusion (They are natively dithered from High-bit to 8-bit by the studios, so no need for DeBanding).
Smooth Motion makes 24p watchable on 60Hz.
Great user selectable Upscalers and Downscalers.

bacondither
5th February 2014, 11:24
This is a contrast enhanced and zoomed image of the error diffusion algorithm:

http://s28.postimg.org/xicvdo4u5/ED_0s.png

You want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness in the thresholds as suggested by Cris Luengo (http://www.cb.uu.se/~cris/blog/index.php/archives/355).

And random dithering (http://s23.postimg.org/kg2kjoyob/RD_0s.png) if someone want to compare.

DragonQ
5th February 2014, 11:45
Playing a 720x384p/25 file at 1080p/25 on Intel HD4000. Smooth Motion is off, scaling is Bicubic75AR and Lanczos3AR.

Random dithering:
- Deinterlace: 1.90 ms
- Split: 1.27 ms
- Rendering: 3.05 ms
- Present: 0.08 ms

Error diffusion:
- Deinterlace: 10.09 ms
- Split: 2.78 ms
- Rendering: 31.35 ms
- Present: 0.10 ms

James Freeman
5th February 2014, 11:50
You want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness.


No you don't.

With super enhanced contrast you can actually see the pattern because the distance between grays (you enhanced the distance),
but it is invisible without enhancements because the distance between shades is ONE STEP (the closes to it in 8-bit), not tens of steps.
This is what contrast enhancement does you know...

If you can see the difference between 127 vs 128 PIXEL THIN lines of grey, you are inhuman.
Take the Color Picker tool in you soft and check what colors the 18 zigzag lines are made of (ED dithered), I'll tell you, its made of 2 & 3 (out of 255).
If you can see that with you naked eye... please contact the UN straight away because you may be trained as a pilot.

I much prefer static picture to a noisy one.

Kalanoch
5th February 2014, 11:57
Even with that black and white 'Miss Korea' video I cannot find any difference at all between random dithering and error diffusion, either during playback or comparing still frames. If it wasn't for the rendering times I wouldn't even know which was which. Is this because of my monitor (HP zr30w), or am I just blind, or what?

Soukyuu
5th February 2014, 12:07
I couldn't see the static pattern when I tested ED (openCL version), didn't even see any difference between ED and RD (LG W2442PA), but seeing those comparisons, the worm pattern is quite ugly.

Intel HD4000, not AMD.Bah, what's with the confusing naming... Ignore me then :P

James Freeman
5th February 2014, 12:11
Kalanoch,

No you are not blind, everything's fine.
I too don't see the difference in actual movie watching, only in paused & enhanced pictures.

What you may see is a "calmer" less noisy picture (assuming your panel is 8-bit and MadVR set to 8-bit).

iSunrise
5th February 2014, 12:13
If you can see the difference between 127 vs 128 PIXEL THIN lines of grey, you are inhuman.
Take the Color Picker tool in you soft and check what colors the 18 zigzag lines are made of (ED dithered), I'll tell you, its made of 2 & 3 (out of 255).
If you can see that with you naked eye... please contact the UN straight away because you may be trained as a pilot.

I much prefer static picture to a noisy one.
This has nothing to do with what you can see or what you think is best. Itīs about what is representing a more even dithered result. And if you donīt want to see the worm patterns, then I would seriously question anything that is coming from you in the future.

I welcome that some people are actually visiting this thread and present us some great alternative methods.

I would very much prefer madshiīs thoughts on this and if the current ED is even possible to improve without much of a performance hit.

The only thing that I see as problematic in the presented alternative, is the single pixels that magically appear in the black area of the "fixed" ED image. These white pixels would probably be harmful when you want your backlight to dim as far as it can.

James Freeman
5th February 2014, 12:14
but seeing those comparisons, the worm pattern is quite ugly.

Please carefully read this post: Contrast Enhancement (http://forum.doom9.org/showpost.php?p=1666265&postcount=22536).

This has nothing to do with what you can see or what you think is best. Itīs about what is representing a better result.

Do you understand what you've just said?

nevcairiel
5th February 2014, 12:17
While its only clearly visible with enhanced contrast, there is nothing wrong with wanting to tweak the algorithm to avoid it. Any enhancements you can make to the contrast-enhanced version are also enhancements to the real watching experience, even if not clearly obvious.

leeperry
5th February 2014, 12:20
Blu rays look fantastic with Error Diffusion
Fully agreed, I've gone back to the point where I watch my settings more than the movie itself....that hadn't happened in a long time :D

*Touche*
5th February 2014, 12:23
Do you guys use debanding for your ripped Blu Rays or is it usefull only for low quality/SD content.

madshi
5th February 2014, 12:24
FWIW, when I implemented Error Diffusion in OpenCL, I played with adding some randomness into the picture, even differently from one frame to the next. But I found that if the pattern changes from one frame to the next, the noise level "feels" higher, although it's objectively the same. So I dumbed the algorithm back down to simple and stupid non-random Error Diffusion.

I might be willing to look into re-introducing a little bit of randomness, but I'll probably do that in such a way that it's the same for every frame, so that with static content the pattern stays the same. This might get rid of the worm artifacts without increasing the subjective noise level. However, it's not going to be free, performance wise. None of the computing platforms (OpenCL, DirectCompute) has a random function built in, so I'd have to create a random texture and read from it, which costs memory bandwidth. That said, Error Diffusion is supposed to be the high-quality alternative, so I guess a small increase in rendering times to get rid of the worm artifacts might be worth it, even if most people are not going to be able to see the difference without boosting the contrast.

iSunrise
5th February 2014, 12:27
While its only clearly visible with enhanced contrast, there is nothing wrong with wanting to tweak the algorithm to avoid it. Any enhancements you can make to the contrast-enhanced version are also enhancements to the real watching experience, even if not clearly obvious.
Exactly.

Do you understand what you've just said?
Yes, I do. Because I donīt think of myself to be the be all end all of things. Iīm only human and humans canīt see everything because of our limited perception of things. Our eyes are also never perfect, neither could you ever judge solely by what you see.

And I say it again, if you cannot see the worm patterns, then why do we even bother talking about this.

FWIW, when I implemented Error Diffusion in OpenCL, I played with adding some randomness into the picture, even differently from one frame to the next. But I found that if the pattern changes from one frame to the next, the noise level "feels" higher, although it's objectively the same. So I dumbed the algorithm back down to simple and stupid non-random Error Diffusion.

I might be willing to look into re-introducing a little bit of randomness, but I'll probably do that in such a way that it's the same for every frame, so that with static content the pattern stays the same. This might get rid of the worm artifacts without increasing the subjective noise level. However, it's not going to be free, performance wise. None of the computing platforms (OpenCL, DirectCompute) has a random function built in, so I'd have to create a random texture and read from it, which costs memory bandwidth. That said, Error Diffusion is supposed to be the high-quality alternative, so I guess a small increase in rendering times to get rid of the worm artifacts might be worth it, even if most people are not going to be able to see the difference without boosting the contrast.
Sounds great!

James Freeman
5th February 2014, 12:29
Do you guys use debanding for your ripped Blu Rays or is it usefull only for low quality/SD content.

Yes, for internet content (strenghth of debanding depends on size).

No, for full blu-rays (aka. Remux), or straight from disc.
Because the content is naturally dithered.

James Freeman
5th February 2014, 12:35
FWIW, when I implemented Error Diffusion in OpenCL, I played with adding some randomness into the picture, even differently from one frame to the next. But I found that if the pattern changes from one frame to the next, the noise level "feels" higher, although it's objectively the same. So I dumbed the algorithm back down to simple and stupid non-random Error Diffusion.

I might be willing to look into re-introducing a little bit of randomness, but I'll probably do that in such a way that it's the same for every frame, so that with static content the pattern stays the same. This might get rid of the worm artifacts without increasing the subjective noise level. However, it's not going to be free, performance wise. None of the computing platforms (OpenCL, DirectCompute) has a random function built in, so I'd have to create a random texture and read from it, which costs memory bandwidth. That said, Error Diffusion is supposed to be the high-quality alternative, so I guess a small increase in rendering times to get rid of the worm artifacts might be worth it, even if most people are not going to be able to see the difference without boosting the contrast.

IMO, its not worth it.

Nobody super enhances the contrast in actual movie watching.
Nobody can actually see the worm pattern with their naked eye.

Let me remind you that the worm pattern is visible ONLY in flat, static, zoomed, and super contrast enhanced test patterns.

Nevilne
5th February 2014, 12:38
Render times for 720p30>1080p30+SM on 75 hz, HD6870:
no dither: 11.4ms
random dither: 11.7ms
ED direct compute: 19ms
can't test opencl (need to stay on old drivers unrelated to madvr)




Do you understand what you've just said?


Yes, I do. Because I donīt think of myself to be the be all end all of things. Iīm only human and humans canīt see everything because of our limited perception of things. Our eyes are also never perfect, neither could you ever judge solely by what you see.


Don't worry sunrise, he doesn't know what he's talking about.

James Freeman
5th February 2014, 12:49
Don't worry sunrise, he doesn't know what he's talking about.

I take no offense by this third person comment.
Still, the question remains.

Can you actually see the difference with your own eyes?
Why fix something that is outside of your human perception and takes more resources?

Nobody else can see it (worm pattern), nor do they see huge difference between Random and ED.
Why do still insist on adding random noise to ED?

turbojet
5th February 2014, 12:53
Very high contrast and (near) static scenes are not uncommon and if a pattern or 'worm' starts to show people will look for a fix. Give it some time, it took nearly a year for me to spot a pattern in lumasharpen's default pattern and i immediately switched.

zhoufang (http://www.cb.uu.se/~cris/blog/matlabimages/dither_zhoufang.png) from cris' blog looks much better than ed+random fix. It's apparently just as fast too.

iSunrise
5th February 2014, 12:58
zhoufang (http://www.cb.uu.se/~cris/blog/matlabimages/dither_zhoufang.png) from cris' blog looks much better than ed+random fix. It's apparently just as fast too.
Yeah, I also saw that comment. Looks very promising, indeed (if the cost is also lower, why not).

DarkSpace
5th February 2014, 13:03
this is a contrast enhanced and zoomed image of the error diffusion algorithm:

[http://s28.postimg.org/xicvdo4u5/ed_0s.png]

you want to avoid the ugly worm pattern in 18, 20 ,24.
Every bar should look like number 21 via introducing some randomness in the thresholds as suggested by cris luengo (http://www.cb.uu.se/~cris/blog/index.php/archives/355).

And random dithering (http://s23.postimg.org/kg2kjoyob/rd_0s.png) if someone want to compare.
:eek: I see. If it can be done in a way that doesn't increase the noise level, I'm in favor. However, I still fear that there will be too much randomness in the end, and in that case, I'd rather take the current method as a smaller evil.
Also, I'm not so sure about the first two images you linked, I still find the pure Floyd-Steinberg one of those to be better... perhaps that was a less-than-optimal choice of examples? ;)

EDIT: Just saw the 2 comments above this, and it seems I'm just weird and your examples were all right...

JarrettH
5th February 2014, 13:05
Can we use a real world example instead of digits on a black background zoomed in 3200%? :scared:

James Freeman
5th February 2014, 13:10
Can we use a real world example instead of digits on a black background zoomed in 3200%? :scared:

BINGO !!!!

Tell me if you see any worm pattern.

Error Diffusion ON:

http://www.mediafire.com/convkey/86d1/54awu99luiwy3rifg.jpg

ryrynz
5th February 2014, 13:12
You won't get one that you can notice anything on, 'cos that's what it takes for it to stand out.
It's not that it's visible just that static patterns generally aren't desired.
Madshi's working on it, so it should be end of topic now. Did you really need to post that James? :P

iSunrise
5th February 2014, 13:13
Can you actually see the difference with your own eyes?
Why fix something that is outside of your human perception and takes more resources?
Again, very little of madshiīs algorithms (like chroma upscaling differences between Jinc and NNEDI3) can be seen with your human eyes when talking about watching actual movies. However, when zoomed in or enhanced, you will actually see that there are differences. And these differences donīt just magically disappear. They will be there even if you donīt see them. I donīt know why you keep arguing like that.

Why offer lossless audio, when 320kbit/s MP3 or 256kbit/s AAC is clearly better, because you cannot hear any differences. Thatīs the way you currently present your arguments.

You fix something, because it can be improved upon. And we donīt even know the performance hit, yet.

Why canīt you just wait a bit for madshi before making assumptions about things you cannot even know.

mindz
5th February 2014, 13:15
@James Freeman. Isnt alot of the settings in madVR (i.e. difference between Bicubic AR, Lanczos AR and Jinc AR chroma upsampling) about the best quality, and not about what we can see? There have always been images zoomed in 1000x in this thread to show a difference between new algorithms. Otherwise the whole idea of madVR wouldnt be valid and everyone would still be using Bilinear. I think that all the little tweaks (that do cost GPU resources) amount to a better picture in the end, maybe even visible with the naked eye.