View Full Version : madVR - high quality video renderer (GPU assisted)
leeperry
19th February 2014, 13:49
There are ppl who get free electricity for various reasons(such as working for the national energy supplier as it is the case in my country) and others might bet on BTC to keep growing but dedicated mining hardware makes more sense indeed, OTOH their ROI doesn't appear to be fully warrantied and the entry ticket seems rather high.
Also, OCL is starting to be used in Photoshop and other graphic apps FWIR...hopefully AMD will cash up on what their GPU's do so well. Apparently B4 was optimized and originally designed for that Mantle stuff so their marketing team doesn't appear to be resting on its laurels(unlike you know who ;)).
DragonQ
19th February 2014, 13:51
There are ppl who get free electricity for various reasons(such as working for the national energy supplier as it is the case in my country) and others might bet on BTC to keep growing but dedicated mining hardware makes more sense indeed, OTOH their ROI doesn't appear to be fully warrantied and the entry ticket seems rather high.
I do have some old, cheap hardware that I could bring to work and mine there (free electricity) and I did briefly consider that. However, I'd still need a case and some kind of HDD in addition to a GPU. It just doesn't seem worth it.
cyberbeing
19th February 2014, 14:03
Hmm, maybe I should be waiting until the new generation of cards is out before upgrading then. All of my 720p content is 60fps. (16.67ms)
I think you may be waiting longer than this upcoming generation of GPUs for that if you wanted NNEDI3 64 Luma + NNEDI3 32 ChromaRGB + Error-Diffusion...
That's surprising, I would have expected aliasing to be a real problem when displaying chroma 1:1.
Well at least as far as I'm aware, 4:2:0 chroma is not inherently aliased any more than normal 50% downscaling produces. If you are downscaling luma with Catmull-Rom, I'd actually expect a very close match to the downscaling used on the encoded 4:2:0 chroma. If the added complexity makes it worthwhile to implement in madVR, who knows. 4K content isn't yet common enough to make this anywhere near an urgent need.
What remains to be seen is the performance/watt ratio as that BTC study I mentioned earlier made rather clear that nvidia not only costs more for the same OCL performance but also increases the electric bill drastically, but I see that Maxwell would improve on that point.
Somewhat off-topic, but I've seen reports that NVIDIA is actually half-decent at Litecoin mining now, after the recent updates made this year to cudaMiner.
Shiandow
19th February 2014, 14:19
Thank you for your answer. For example, with bluray material in chroma settings, i can't decide if it is better jinc3+AR or Needi3:confused: . I can't decide if it is better jinc3+ar+image doubling or Needi3 too :( Have I to think that the sharpest is the best? ehhhmmmm, for me there is a lot of confusion and i'm waiting for a seriuos testing. Has someone the answer?
Thank you, Fabio
In my opinion using Needi3 for chroma isn't really worth it, Jinc3 should be more than enough and you can even use bicubic 75 without much loss in quality. Using image doubling (with as many neurons as your GPU can handle) gives a far more noticeable improvement in image quality.
andyvt
19th February 2014, 14:56
The really big one is Anandtech, there are smaller ones like missingremote (http://missingremote.com/review/intel-hd-4600-madvr-performance). Maybe I shouldn´t have used the word "major" in the same sentence though. ;)
No need to be cruel ;)
I think the problem for review sites in general is that they are not sure how to integrate madVR within their tests, because they also need something like GPU-Z / MSI Afterburner and know some basics about madVR benchmarking. Was there actually talk between you and Anand when he started to use madVR in his reviews?
Ganesh handles the madVR/HTPC aspects of most of Anandtech's GPU reviews. There was some discussion a while back around creating a madVR benchmark, but I think that didn't materialize because it was too difficult for madshi to maintain it (but my memory could be faulty here).
I think the more general problem is that not enough people use HTPC, and in that group many don't want to do the work to understand what madVR is and how it benefits users (probably doesn't help that most people don't really care about PQ either). Also, despite the amazing strides madVR has made in the last couple years it's still not as approachable as it needs to be for broader acceptance. There are too many knobs and dials, and "trust your eyes" answers for the general population to embrace it. TBC, I don't think that's a bad thing (I love the flexibility it provides) just that the lack of drop-dead-simple settings (good, better, best) makes it difficult for users to embrace. If users don't embrace it, there isn't much reason to benchmark it.
madshi
19th February 2014, 15:06
There are too many knobs and dials, and "trust your eyes" answers for the general population to embrace it.
Believe me, I hate too many knobs and dials. But people here ask me all the times to make things as flexible as possible. It's hard to make everybody happy. If I hadn't already said "no" to many many requests, the settings dialog would be even more complicated than it is right now.
Anyway, for now I'm concentrating on trying different things, offering many different algorithms, etc. So for now madVR is for tweakers and powerhouse users. In the long run I do plan to find ways to make it easier to use for "simple" users, too. But it's still too early for that. Once all planned features are implemented, I can revisit which knobs and dials are still needed, and which I could automate or replace, which algorithms I might be able to remove etc. Doesn't make sense to do that kind of stuff before all features are implemented. In the same way it doesn't make too much sense to write a help/documentation now, because too many things are still changing from one version to the next.
As I keep saying, madVR still hasn't reached v1.0 yet. So a not-yet-perfect user interface and some rough edges are to be expected...
andyvt
19th February 2014, 15:14
Believe me, I hate too many knobs and dials. But people here ask me all the times to make things as flexible as possible. It's hard to make everybody happy. If I hadn't already said "no" to many many requests, the settings dialog would be even more complicated than it is right now.
Anyway, for now I'm concentrating on trying different things, offering many different algorithms, etc. So for now madVR is for tweakers and powerhouse users. In the long run I do plan to find ways to make it easier to use for "simple" users, too. But it's still too early for that. Once all planned features are implemented, I can revisit which knobs and dials are still needed, and which I could automate or replace, which algorithms I might be able to remove etc. Doesn't make sense to do that kind of stuff before all features are implemented. In the same way it doesn't make too much sense to write a help/documentation now, because too many things are still changing from one version to the next.
As I keep saying, madVR still hasn't reached v1.0 yet. So a not-yet-perfect user interface and some rough edges are to be expected...
FWIW, I didn't mean that as a criticism just documenting what I see as a barrier to more mainstream adoption (which would probably be more PITA than benefit for you). Because madVR isn't v1.0 yet, I think it makes sense to focus (as you have) on capability instead usability - that can come later.
When you're ready for a wider, less tolerant, audience I can't imagine that it would be that difficult to use a GPU database to provide the good, better, best simple UI for them and the current "advanced" UI for the rest of us who want to have a play.
cyberbeing
19th February 2014, 15:20
There was some discussion a while back around creating a madVR benchmark, but I think that didn't materialize because it was too difficult for madshi to maintain it (but my memory could be faulty here).
There actually was a madVR benchmark (http://madshi.net/madVR%20%5Bbenchmark%5D.zip) created for an Anandtech Review (http://www.anandtech.com/show/4380/discrete-htpc-gpus-shootout/14) years ago, but your memory is correct that madshi never maintained it to support newer madVR releases.
madshi
19th February 2014, 15:42
FWIW, I didn't mean that as a criticism just documenting what I see as a barrier to more mainstream adoption
Yeah, I know. Just wanted to say that I absolutely share your sentiments about having too many knobs and dials etc.
Q-the-STORM
19th February 2014, 16:39
As I keep saying, madVR still hasn't reached v1.0 yet. So a not-yet-perfect user interface and some rough edges are to be expected...
exactly...
once everything is implemented and it reaches v1.0 you can let the user select "simple" or "expert" settings.. e.g. the user has the choice to select "normal" "good" and "best" quality and in simple settings and more specific stuff (like we have now) in expert settings... but why go to the trouble of trying to figure out which settings to put in what category when madVR is still changing so fast...
leeperry
19th February 2014, 17:13
There are too many knobs and dials, and "trust your eyes" answers for the general population to embrace it.
Running a HTPC has always been a major PITA to setup IMHO, but at least these days it's well worth the trouble :cool:
IME learning the tricks of the trade of video calibration also required quite a bit of work but this was also well worth it.
madshi could easily get mVR to be as KISS-compliant as EVR and yet (far) more satisfying PQ-wise, hopefully he'll stop acting as a philanthropist someday and will finally decide to get paid for his unmatched work. Keeping it niche wouldn't help.
OTOH, yeah.....most ppl do not care about PQ otherwise nobody would buy IPS TV's. I tried to mess with the OSD of 46" LG TV's a few times, the utterly low CR was a major deal breaker...the picture looked so darn dull. I guess the major concern of LG TV's owners is not the VR they use and LG have recently become the largest OEM maker of LCD panels FWIR.
cyberbeing
19th February 2014, 17:36
In a few short months, madVR will soon have the honor of being in Beta longer than Gmail. ;)
noee
19th February 2014, 17:46
....I guess the major concern of LG TV's owners is not the VR they use and LG have recently become the largest OEM maker of LCD panels FWIR.
Hey now, I resemble that remark and I can tell you, my major concern is feeding these things (http://www.transcendentsound.com/Transcendent/Subwoofer.html), as I made the decision on madVR many moons ago. ;)
Seriously, though, you're right about the LG, IMO, CR and blacks on the LG IPS are not good. I wonder, however, sometimes if this is why the magic of NEEDI3 and the new ED are so clearly evident. Maybe just a little bit of the madVR magic is enough to overcome the shortcomings of even the lowliest panel to eek out incrementally better performance.
DragonQ
19th February 2014, 17:55
If you care about PQ, want deep blacks, and aren't rich, then you should buy a plasma. :)
James Freeman
19th February 2014, 18:07
Madshi,
MadTPG is not working with Error Diffusion (Direct Computing).
Is there any benefit calibrating with MadVR 16-bit workflow vs ArgyllCMS native?
madshi
19th February 2014, 18:10
I love "is not working" error reports. That's about the most general description possible, without even one small bit of information. What is the problem? Does your computer explode? Do you get a blue screen? Does madTPG delete itself?
Yes, using madTPG is beneficial over the native ArgyllCMS test pattern generator, if that's what you're asking.
James Freeman
19th February 2014, 18:14
heh, sorry about that.
The area inside MadTPG window is completely black, whether it should be a black square inside grey borders.
When switching ED off in madvr control panel, the "insides" reappear instantly without even restarting madTPG.
Can you please elaborate how MadTPG is more beneficial compared to ArgyllCMS?
madshi
19th February 2014, 18:18
Ok, thanks. Can you please create a bug entry in the bug tracker for this?
James Freeman
19th February 2014, 18:19
No problem,
Madshi,
Please make the link for "Bug Tracking" in the first post clickable.
leeperry
19th February 2014, 18:42
you're right about the LG, IMO, CR and blacks on the LG IPS are not good. I wonder, however, sometimes if this is why the magic of NEEDI3 and the new ED are so clearly evident.
Life is too short, you are missing a lot by not feeding mVR to a >=3K:1 CR screen IMHO. You would find your efforts far better rewarded, especially with a perfect REC709 calibration(and BFI if that's a LCD)...you can rest assured that ED & NNEDI will look even more outstanding than on an IPS panel. My point is that the rabbit hole goes deeper :devil:
*Touche*
19th February 2014, 18:58
When I got my new HTPC and plasma, I've cranked up the settings and rewatched a dozen movies for the Nth time just to enjoy the experience :)
burfadel
19th February 2014, 20:35
In a few short months, madVR will soon have the honor of being in Beta longer than Gmail. ;)
There's different ways of doing things, madVR is probably using the same scenario for its releases as x264 in that there is no 'release' version, you just use the latest one.
GREG1292
19th February 2014, 20:58
When I got my new HTPC and plasma, I've cranked up the settings and rewatched a dozen movies for the Nth time just to enjoy the experience :):goodpost:
I agree with the massive improvements it is like watching
the Nth time seem like the first time.
leeperry
19th February 2014, 22:00
I haven't run very extensive tests with NNEDI on native 1080p chroma but so far 32x looks too sharp and quite artificial, J3AR is a breeze of fresh air in comparison IME. Of course for luma it's a no-brainer.
kstuart
19th February 2014, 22:05
Is there anything that will notify a user if there is a new madVR version (0.87.5 and so forth) ?
Since my GPU won't support the load from NNEDI or Error Diffusion, then most of the current posts in the thread are not relevant to my use (although it's good that other people are refining all of that). So, it is not a good use of my time to read the thread, especially if there is any other notification method.
Thanks !
MistahBonzai
19th February 2014, 22:08
Assistance please: Having problems activating the "madTestPatternSource" utility. I can't seem to find the proper sequence of registrations needed to make the files display. After DL'ing a fresh copy of the folder I've run uninstall.bat in the "madTestPatternSource" folder as administrator and then again in MadVR. Then registering in the reverse order. No joy despite a positive acknowledgement in the status pop-up.
Dragging a ".ytp" file into MadVR results in a blank screen (no apparent activity). Doing so while a video is being displayed with MadVR active results in the current video stopping and again a blank screen is displayed in the MPC-HC display window. Google has been no help above and beyond that what is offered in the "madTestPatternSource"/readme.txt Anyone? TIA :-)
Oh yeah, this is with the latest Win7 64 bit with all 32 bit applications - MPC-HC 1.7.3.23 and LAV 0.60.1.22 along with MadVR 87.4 with Directcompute adaptive4 enabled and OpenCL error diffusion set on (no check).
mark0077
19th February 2014, 23:47
madshi, I found a regression in performance in 0.87.4 around loading PGS subtitles. After briefly speaking with cyberbeing on the xySubFilter thread, I decided it was best to create this bug report with a sample and explanation
http://bugs.madshi.net/view.php?id=153
Thought I would post here incase you were still interested in regressions / bugs introduced in 0.87.4+
huhn
20th February 2014, 03:28
Well, not really (http://forum.doom9.org/showpost.php?p=1649687&postcount=16243)(hopefully even James Freeman will see the difference http://forum-images.hardware.fr/images/perso/2/harley_quinn.gif).
CUVID and deint nearly gives you the same picture if not the same. i have to say the difference in the linked pictures are more than huge so i was tring the same. first of all CUVID is a simple BOB/IVTC deint and it creates judder with a 3:2 cadence. atleast with the scource i tested.
i used a gtx 760 with 334.89 driver. all screens are done without dither and default madvr settings. the option "deinterlacing use inverse telecine" was checked in the driver and CUVID was at high quality and 50p/60p.
i mean good luck. both bobed frames inculed in this 3:2 cadence part: comparison (http://screenshotcomparison.com/comparison/63427/picture:1)
madvr ivtc the worst in this case (http://abload.de/img/ivtczqy2j.png)
are these even the same frames in the linked post? or is the dxva deint from my 760 gtx better? maybe a problem with dxva decoding or the source?
and an deint error (http://abload.de/img/cuviddeinterroru0xzu.png) in both CUVID and NVIDIA deint because they are the same?? ivtc was fine. so not sure if CUVID/nvidia deint is even good...
i did a bd test too, but there was nothing to see. can upload it if you like.
StinDaWg
20th February 2014, 05:55
I'm trying to setup keyboard shortcuts in madVR so I can quickly change deinterlacing method between film/video. I'm trying to map this to the number 1 so that I can control it via my remote during playback. I have tried "1", "number 1", "numpad 1", and "Num 1" but I can't get madVR to recognize this command.
In MPC-HC keyboard shortcuts, "Num 1" works fine on my remote control/keyboard, so why won't madVR recognize it?
mindbomb
20th February 2014, 07:17
you have to not use dxva native to switch between them.
turbojet
20th February 2014, 07:57
Does a GTX 760, 770 and/or HD7850 do 720p60 test (http://www.mediafire.com/download/hc735axdmtal66o/720p60.mpg) -> 1080p with nnedi3 chroma 32, lanczos4AR luma upscaling, nnedi3 32 doubling and ED without dropping frames?
Also since it was reported to work how are people using virtumvp to use a an igp and discrete together with madvr? I've added potplayermini and madhcctrl and no matter how I set up virtumvp madvr always uses the discrete (display).
It would be interesting to see a comparison between ati and nvidia dxva deinterlacing. IMO cuvid isn't noticeably better than nvidia dxva. Also concerning deinterlacing, this is something to consider in the future. (http://forum.doom9.org/showthread.php?p=1668877#post1668877)
huhn
20th February 2014, 08:30
Does a GTX 760, 770 and/or HD7850 do 720p60 test (http://www.mediafire.com/download/hc735axdmtal66o/720p60.mpg) -> 1080p with nnedi3 chroma 32, lanczos4AR luma upscaling, nnedi3 32 doubling and ED without dropping frames?
i just tested it with a 760 i can't even do 30 fps (about 42 ms) with these settings so you need double this power i'm pretty sure not even a 780 ti is this fast.
btw nnedi give a picture with the new driver it's just in green
Also since it was reported to work how are people using virtumvp to use a an igp and discrete together with madvr? I've added potplayermini and madhcctrl and no matter how I set up virtumvp madvr always uses the discrete (display).
some one reported that this worked?
It would be interesting to see a comparison between ati and nvidia dxva deinterlacing. IMO cuvid isn't noticeably better than nvidia dxva. Also concerning deinterlacing, this is something to consider in the future. (http://forum.doom9.org/showthread.php?p=1668877#post1668877)
it's the same see above. CUVID/NVDIA use the same deint for 99 %.
i can do a nvidia/amd deint comparison later. but amd got a lot of Deint modes (all are just bob or wave if i remenber correct.. but still)
MistahBonzai
20th February 2014, 09:46
Does a GTX 760, 770 and/or HD7850 do 720p60 test (http://www.mediafire.com/download/hc735axdmtal66o/720p60.mpg) -> 1080p with nnedi3 chroma 32, lanczos4AR luma upscaling, nnedi3 32 doubling and ED without dropping frames?
I knew immediately that, at least on my water cooled win7 64bit/i7-3770 3.4Ghz/HD-7850(1GHz/1.225Ghz/1.21V) w/Catalyst Version 14.1, there was no way it would pull that kind of load almost solely with the GPU. However I gave it whirl...
You can 'pick 1' - either ED or nnedi3 chroma 32 or nnedi3 32 doubling. I can provide specific figures if you need them but it's not even close for me. And if you managed to squeeze 2 of the 3 (say both the nnedi's) you would be running the GPU right up against the wall. That is OK for tweaking and benchmarks but I can't see watching a movie that way. I see some folks make what I consider outrageous claims about how they can crank up almost all the 'nnedi' settings and have room for ED but it makes me wounder if they are truly up scaling a quality 720p video on a 1080p display. Maybe so but I don't see how...
This rig does well on the OpenCL benchmarks, runs solid and has no extraneous crap running in the back ground (it's a clean machine)- not that it matters cuz the CPU is barely being used (7-8%) with that configuration.
I'm into avisynth/plugins/scripts trying to fine tune 'smooth video' solutions which is fairly CPU intensive. What I do is split the load keeping the nnedi plugins, interframe2 and filters on the CPU. The nnedi* plugins and associated scripts give one a lot of room to tweak/fine tune while still leaving plenty of headroom on the i7. MadVR utilizes the GPU for ED and the other goodies. That usually splits the load about 50%/50 across the GPU & CPU with a 720p '24fps' -> 1080p '59fps' running. This also gives you some leeway as to where/what/when to filter versus scaling. I like to feed MadVR at least 720P and let it complete the scaling.
Of course the purists will wonder how could I do that to 'pristine' video, that's not true to the directors artistic intentions... But so be it cuz my goals are different than those of many others :-) I no longer have the attention span for a video much longer than ~10 minutes (unless it is a 'white paper' presentation). But I sure enjoy restoring butchered p0rn :-)
MokrySedeS
20th February 2014, 11:00
i have to say the difference in the linked pictures are more than huge so i was tring the same.
Can you try again with a sample provided by leeperry (sample2.mkv (https://mega.co.nz/#!HtgAzZ7K!c8OIEjFDgv9qrU9L-MxM2XGvNug2tWbaExxIQ8LHEAg))?
are these even the same frames in the linked post?
Of course. I tested this again just now and I got the same results.
maybe a problem with dxva decoding
Software decoding + dxva deinterlacing and cuvid decoding + dxva deinterlacing look exactly the same as dxva2cb decoding + dxva deinterlacing, so imo it's not a decoding issue.
Also, I checked with EVR-CP. Here's a comparison:
DXVA2-CB decoding with DXVA2 deinterlacing in madVR
http://thumbnails110.imagebam.com/30919/dbe265309185656.jpg (http://www.imagebam.com/image/dbe265309185656)
CUVID decoding and deinterlacing in LAV Video rendered in madVR
http://thumbnails110.imagebam.com/30919/18c98a309185696.jpg (http://www.imagebam.com/image/18c98a309185696)
DXVA2-CB rendered in EVR-CP
http://thumbnails111.imagebam.com/30919/21cc22309185806.jpg (http://www.imagebam.com/image/21cc22309185806)
cyberbeing
20th February 2014, 11:34
Does a GTX 760, 770 and/or HD7850 do 720p60 test (http://www.mediafire.com/download/hc735axdmtal66o/720p60.mpg) -> 1080p with nnedi3 chroma 32, lanczos4AR luma upscaling, nnedi3 32 doubling and ED without dropping frames?
The my GTX 770 can do nnedi3 32 chroma upscaling. lanczos4AR luma upscaling, and ED without dropping frames. 73% GPU load, 13.3ms avg render time. Adding NNEDI3 doubling of any kind on top is a complete no-go.
btw nnedi give a picture with the new driver it's just in green
I guess that explains Anandtech's green tinge bug.
huhn
20th February 2014, 12:24
Can you try again with a sample provided by leeperry (sample2.mkv (https://mega.co.nz/#!HtgAzZ7K!c8OIEjFDgv9qrU9L-MxM2XGvNug2tWbaExxIQ8LHEAg))?
looks like a bug in madvr. for me everything is working fine.
did you check "don't use "copyback" for dxva deinterlacing(intel, nvidia)?
nvidia
http://abload.de/thumb/samplenvidiadeint3qsas.png (http://abload.de/image.php?img=samplenvidiadeint3qsas.png)
CUVID
http://abload.de/thumb/samplecuviddeint65s7h.png (http://abload.de/image.php?img=samplecuviddeint65s7h.png)
i hope i got the same frames this source looks terrible and i'm not used to a non anime source but it's obvious the huge difference you got are not in the screens! i think you got this problem on the hole video right? so even if i missed the right frame this should do be ok?
they look like clones the file size is 7 kb bigger with cuvid. these screens are done again without dither but with spline 3 ar/ spline 3 ar
madshi
20th February 2014, 12:27
Is there anything that will notify a user if there is a new madVR version (0.87.5 and so forth) ?
Just check the first post of this page to see if there's a new (release non-test) version. It's always updated.
Assistance please: Having problems activating the "madTestPatternSource" utility. I can't seem to find the proper sequence of registrations needed to make the files display. After DL'ing a fresh copy of the folder I've run uninstall.bat in the "madTestPatternSource" folder as administrator and then again in MadVR. Then registering in the reverse order. No joy despite a positive acknowledgement in the status pop-up.
Dragging a ".ytp" file into MadVR results in a blank screen (no apparent activity). Doing so while a video is being displayed with MadVR active results in the current video stopping and again a blank screen is displayed in the MPC-HC display window. Google has been no help above and beyond that what is offered in the "madTestPatternSource"/readme.txt Anyone? TIA :-)
Oh yeah, this is with the latest Win7 64 bit with all 32 bit applications - MPC-HC 1.7.3.23 and LAV 0.60.1.22 along with MadVR 87.4 with Directcompute adaptive4 enabled and OpenCL error diffusion set on (no check).
I can reproduce graphical corruption with some of the test patterns. Which I will need to fix (of course). But other than that, it seems to work fine here. No sure what's going on on your PC. If all else fails, try to open the ytp files with notepad and add some dummy text in there. Some media players refuse to open files with 0 bytes length.
I'm trying to setup keyboard shortcuts in madVR so I can quickly change deinterlacing method between film/video. I'm trying to map this to the number 1 so that I can control it via my remote during playback. I have tried "1", "number 1", "numpad 1", and "Num 1" but I can't get madVR to recognize this command.
In MPC-HC keyboard shortcuts, "Num 1" works fine on my remote control/keyboard, so why won't madVR recognize it?
"numpad1" should work.
Does a GTX 760, 770 and/or HD7850 do 720p60 test (http://www.mediafire.com/download/hc735axdmtal66o/720p60.mpg) -> 1080p with nnedi3 chroma 32, lanczos4AR luma upscaling, nnedi3 32 doubling and ED without dropping frames?
I'd drop nnedi3 chroma upscaling from the list. The advantage in image quality is IMHO not big enough, if you're short on GPU power.
Can you try again with a sample provided by leeperry (sample2.mkv (https://mega.co.nz/#!HtgAzZ7K!c8OIEjFDgv9qrU9L-MxM2XGvNug2tWbaExxIQ8LHEAg))?
Of course. I tested this again just now and I got the same results.
Looks like something that should be added to the madVR bug tracker.
The my GTX 770 can do nnedi3 32 chroma upscaling. lanczos4AR luma upscaling, and ED without dropping frames. 73% GPU load, 13.3ms avg render time. Adding NNEDI3 doubling of any kind on top is a complete no-go.
Why use nnedi3 chroma upscaling, but not nnedi3 image doubling? I think the other way round will give an overall better image quality (if your GPU can handle that).
madshi
20th February 2014, 12:35
About error diffusion:
I'm still waiting for more feedback about which adaptive build you guys prefer. So far it seems adaptive 4 is preferred by more people than other builds.
There's still something else we need to test: All the previous error diffusion builds were mono-colored and static. Which means they used the same random values for each color channels (resulting in gray ramps staying completely gray), and they used the same random values for each frame. We should put both things to the test. So here are 4 test builds based on "adaptive 4":
http://madshi.net/madVRed4.rar
monoColored: same random numbers for every color channel
multiColored: every color channel gets different random numbers
static: every frame is processed with the same random numbers
dynamic: random numbers change for every frame
Please note that the static vs dynamic decision can not be made by looking at screenshots. To make it easier for you guys you can force these 4 new test builds into 4 bit dithering mode by creating an empty file (or folder) with the name "4bit" on your desktop. This should make the dithering clearly visible to your eyes during real life watching. Please let me know which of the 4 builds you prefer. Please don't put too much weight into gray ramps. Real movie content is more important. So while mono-colored may look better for gray ramps, I'm more interested in how multi-colored vs mono-colored compares with real life movie content.
Thanks!
cyberbeing
20th February 2014, 13:02
Why use nnedi3 chroma upscaling, but not nnedi3 image doubling? I think the other way round will give an overall better image quality (if your GPU can handle that).
Unfortunately, even using NNEDI3 32 neurons luma doubling alone without ED or chroma upscaling is a no-go with 720p60 -> 1080p on this GPU. From what MistahBonzai said, it sounds like AMD GPUs may behave more favorably with NNEDI3 on higher framerate content.
@MistahBonzai
What were your render times and GPU load % using NNEDI3 32 neurons luma doubling alone with that 720p60 -> 1080p60 test?
nautilus7
20th February 2014, 13:15
After some limited tests in my non calibrated cheap TN monitor, my inexperience eyes see a clear winner: Multicolored Dynamic. But feel free to ignore me.
madshi
20th February 2014, 13:20
After some limited tests in my non calibrated cheap TN monitor, my inexperience eyes see a clear winner: Multicolored Dynamic. But feel free to ignore me.
Every feedback is welcome, thanks.
Shiandow
20th February 2014, 13:28
Just did a quick test and in my case the dynamic multiColored build seems to be closest to the original, Although I did need to lower the bitdepth to 4bit to make it noticeable. I suspect that the multiColored wasn't really noticeable because adjacent pixels merge into one colour anyway (otherwise you'd see red green and blue dots instead) and the response time of my screen is pretty high so the temporal noise was probably dampened somewhat.
By the way, the lack of gamma correction became pretty noticeable in 4 bits.
DragonQ
20th February 2014, 13:42
Can the AMD HD7950 handle NNEDI3?
Ver Greeneyes
20th February 2014, 14:18
To make it easier for you guys you can force these 4 new test builds into 4 bit dithering mode by creating an empty file (or folder) with the name "4bit" on your desktop.Cool :D
FWIW, I can make some versions of my test patterns that don't vary in brightness, but still run at 30fps. So it should be possible to assess the difference between static and dynamic as long as you're not using screenshots. Of course, they're still artificial test patterns.
static grayscale pattern (dark) (http://www.mediafire.com/?52hf13389hv7k80), static multicolor pattern (dark) (http://www.mediafire.com?hveze60w6mqk303)
static grayscale pattern (bright) (http://www.mediafire.com?4om41bkr35r95zl), static multicolor pattern (bright) (http://www.mediafire.com?k7x324dyjbin40b)
Looking at it in 8-bit mode, I can't say I have a strong preference. With the test patterns above I can definitely see a bit of motion in the dynamic versions, but at the same time they eliminate the graininess of the static versions. Switching back and forth between the multicolor and monocolor dynamic versions, I don't really see any difference. I'm sure other people will have stronger opinions though ;)
MS-DOS
20th February 2014, 15:02
Please note that the static vs dynamic decision can not be made by looking at screenshots. To make it easier for you guys you can force these 4 new test builds into 4 bit dithering mode by creating an empty file (or folder) with the name "4bit" on your desktop. This should make the dithering clearly visible to your eyes during real life watching. Please let me know which of the 4 builds you prefer. Please don't put too much weight into gray ramps. Real movie content is more important. So while mono-colored may look better for gray ramps, I'm more interested in how multi-colored vs mono-colored compares with real life movie content.
Did some 4bit mode tests with Star Trek: Voyager on my IPS monitor, and Multi-Colored dynamic one is a clear winner to me:
Mono-Colored (http://i4.imageban.ru/out/2014/02/20/ff4af591dbab5fa262f2e3959c2effe2.png)
Multi-Colored (http://i2.imageban.ru/out/2014/02/20/32f5f0af33184c268e3984c80ff33cc7.png)
StinDaWg
20th February 2014, 15:04
"numpad1" should work.
It doesn't. I get this message-
"Error: this keyboard shortcut is invalid."
Edit: I tried "1" and it didn't give an error message. However, pressing the button during playback does not register any command.
leeperry
20th February 2014, 15:19
here are 4 test builds based on "adaptive 4":
http://madshi.net/madVRed4.rar
monoColored: same random numbers for every color channel
multiColored: every color channel gets different random numbers
static: every frame is processed with the same random numbers
dynamic: random numbers change for every frame
I haven't tried the 4bit trick but here are my observations after quite a lot of testing:
-the goal of dithering is to be as transparent as possible IMO, in order to not temper with the sharpness and clarity of the movie. Dithering should not distract the viewer, you should not "see" or even notice its work and your brain shouldn't have to fight against it.
-the multicolor stuff is adding a thick multicolored noise veil that does the exact opposite of what we want to my eyes, my brain has to dig behind all this mess trying to reassemble the actual details of the movie. Clarity is very poor.
-the good side of monoColor_dynamic is that it brings "life" to the original movie grain so it's pretty cool on low-bitrate movies but it's more of a special effect than dithering anymore to my eyes...I guess this is sort of what you would expect from a "movie grain" DSP but the flip side of the coin is that it also drastically kills clarity & the impression of depth.
-The nice thing about monoColor_static is that the dithering noise is as non-invasive as possible, my brain can easily get used to its pattern and it's the least harmful to the movie original grain. This also provides the best sense of depth by a very long shot as I'm not watching the dithering dancing around anymore.
Of course on bit-starved movies, the GIGO principle applies and monoColor_dynamic looks more realistic but this is not actual reel grain and the noisier the lower the dynamics. Definitely not what I expect from a dithering process.
Regarding the latter, you said "resulting in gray ramps staying completely gray", that's exactly how I expect them to look like.
Ver Greeneyes
20th February 2014, 15:41
One thing I noticed, looking at static multicolor pattern (dark) (http://www.mediafire.com/?hveze60w6mqk303) in 4-bit mode using madVR_monoColor_dynamic or madVR_multiColor_dynamic, is that the bright dots seem to be somewhat centered in each 16x16 pixel block. For the test pattern, this means that each colored band is divided up into four horizontal bands, though it's only really visible using the dynamic versions (human pattern detection and all that) and only near black. Could there be an error bias toward the center of each block?
In 4-bit mode, monocolor dynamic looks a bit more grainy (more luma noise?), but multicolor dynamic does look a bit.. dirty, or messy as leeperry put it. This was still using my test pattern though (and in 4-bit mode), so take that with a grain of salt.
Oh, and I wonder if you could tweak the amount of randomness between frames as opposed to the amount of randomness within frames? e.g. reuse the random number from the last frame, but add a random number to it within a tighter range* (clamping to the original limit). I don't know how well this lends itself to tweaking though :)
* something like: range1 = 0.5 / 255.0;
range2 = 0.25 / 255.0;
random_diff = 2.0 * range2 * rand() - range2;
random_new = clamp(random_old + random_diff, -range1, range1);
sajara
20th February 2014, 15:45
1. dynamic multicolored
2. dynamic mono
static versions very noticeable dithering
madshi
20th February 2014, 16:24
It doesn't. I get this message-
"Error: this keyboard shortcut is invalid."
Oh, that seems to be a bug in the settings dialog. Will be fixed in the next official build.
the goal of dithering is to be as transparent as possible IMO, in order to not temper with the sharpness and clarity of the movie. Dithering should not distract the viewer, you should not "see" or even notice its work and your brain shouldn't have to fight against it.
The goal of dithering is to simulate a native higher bitdepth as well as possible.
One thing I noticed, looking at static multicolor pattern (dark) (http://www.mediafire.com/?hveze60w6mqk303) in 4-bit mode using madVR_monoColor_dynamic or madVR_multiColor_dynamic, is that the bright dots seem to be somewhat centered in each 16x16 pixel block. For the test pattern, this means that each colored band is divided up into four horizontal bands, though it's only really visible using the dynamic versions (human pattern detection and all that) and only near black. Could there be an error bias toward the center of each block?
I don't seem to be able to see that here, but it might be because my LCD monitor swallows a lot of shadow detail.
The last line of each 16x16 block is somewhat at a disadvantage because it can't spread the error to the first line of the next 16x16 block. I'm trying to compensate for that a bit by spreading a larger portion of the error to the next pixels in the same line. But there's still a bit of the error lost. This may be responsible for the problem you're seeing. I'm not sure if I can fix this without causing other artifacts.
Oh, and I wonder if you could tweak the amount of randomness between frames as opposed to the amount of randomness within frames? e.g. reuse the random number from the last frame, but add a random number to it within a tighter range* (clamping to the original limit). I don't know how well this lends itself to tweaking though :)
* something like: range1 = 0.5;
range2 = 0.25;
clamp(random_previous + (2.0 * range2 * rand() - range2), -range1, range1);
I don't think that would make much difference. Either the dither pattern is changing from one frame to the next, or it's not changing. Both options are possible and have a different look. I don't think you can have the pattern "half change".
Just did a quick test and in my case the dynamic multiColored build seems to be closest to the original
Looking at it in 8-bit mode, I can't say I have a strong preference. With the test patterns above I can definitely see a bit of motion in the dynamic versions, but at the same time they eliminate the graininess of the static versions. Switching back and forth between the multicolor and monocolor dynamic versions, I don't really see any difference. I'm sure other people will have stronger opinions though ;)
-the multicolor stuff is adding a thick multicolored noise veil that does the exact opposite of what we want to my eyes, my brain has to dig behind all this mess trying to reassemble the actual details of the movie. Clarity is very poor.
-the good side of monoColor_dynamic is that it brings "life" to the original movie grain so it's pretty cool on low-bitrate movies but it's more of a special effect than dithering anymore to my eyes...I guess this is sort of what you would expect from a "movie grain" DSP but the flip side of the coin is that it also drastically kills clarity & the impression of depth.
-The nice thing about monoColor_static is that the dithering noise is as non-invasive as possible, my brain can easily get used to its pattern and it's the least harmful to the movie original grain. This also provides the best sense of depth by a very long shot as I'm not watching the dithering dancing around anymore.
In 4-bit mode, monocolor dynamic looks a bit more grainy (more luma noise?), but multicolor dynamic does look a bit.. dirty, or messy as leeperry put it. This was still using my test pattern though (and in 4-bit mode), so take that with a grain of salt.
1. dynamic multicolored
2. dynamic mono
static versions very noticeable dithering
Thanks for the feedback.
Here's my own impression: The multiColor builds seem to lower the luma noise a bit on the cost of having slightly higher chroma noise. This might be a matter of taste, but I find the dither pattern to be less visible with the multiColor builds. The dynamic builds make the image appear slightly more noisy, IMHO, which is a negative, but on the other hand the dynamic builds get rid of any static noise patterns, which the static builds do show. When watching at the static builds in motion, it feels to me as if my LCD screen were slightly dirty, because there's a dither pattern which seems to stay static on the same place, even if the objects/persons in the movie move. I find this to be distracting. However, the static builds do appear less noisy. So it might again be a matter of taste: Does the higher subjective noise level bother us more (the objective noise level should be the same)? Or the "dirty screen" effect of the static builds?
I think my current favorite is the multiColor dynamic build, because it's less noisy than the monoColor builds, and without the "dirty screen" effect of the static builds. To my eyes the multiColor dynamic build seems to achieve the best approximation of how a native higher bitdepth looks like. My 2nd place goes to the monoColor static build. For some reason I prefer it over the other remaining options.
But these are only my own subjective impressions. I'm very much interested in hearing more opinions about this.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.