Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th October 2012, 18:33 | #14861 | Link | |
Registered User
Join Date: Dec 2010
Posts: 62
|
Quote:
But I fear the driver revision might also make a difference. |
|
18th October 2012, 19:00 | #14862 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
Jinc is quite hard for the video card, 8-tap brings processing to it's knees even with a GTX 680. When resizing to 2650x1440 even 4-tap Jinc uses ~30% GPU with the GTX680 at full power. Nvidia's deinterlacing is quite good but also takes quite a bit of GPU so I am not at all surprised the HTPC friendly cards cannot handle it and Jinc at the same time. Would love to try these on a GK-110 card.
|
18th October 2012, 20:45 | #14863 | Link | ||
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
Quote:
8-tap Jinc (or Lanczos) are completely unusable no matter whether the GPU can handle them or not - they look terrible! More ≠ better. |
||
18th October 2012, 21:06 | #14864 | Link | |
Registered User
Join Date: Jun 2006
Posts: 452
|
Quote:
I'm sure it'll work for 6233638 too, since I've have an almost identical setup as him, based on GTX-570 and i7-9xx CPU on W7 x64. I wonder if somehow the PotPlayer author found a work around the Macrovision thing, or PotPlayer did work "out the box" with LAV + MadVR for DVD playback. If the first, then I would be *very* interested in what he did to make it work. |
|
18th October 2012, 21:13 | #14865 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
Quote:
I know you really hate ringing, no need to go over it yet again. lol |
|
18th October 2012, 22:30 | #14867 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
So do I, 6233638 thinks about this in a more rigorous way and probably has a better eye for details than I do.
I have learned a lot from all of you, it is wonderful being able to look over the shoulders of people who know what they are doing and then play with the some of results myself. |
19th October 2012, 01:19 | #14868 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Hi madshi, I finally pulled the trigger on a 399€ 1080p 46" TV set and it's flawless for mVR use: 3200:1 native CR calibrated at D65/2.5, it supports 24/25/29.97/48/50/59.94Hz and has a 3 levels noise reduction filter(processed in 10bit?) that does wonders on noisy SD so my endless headaches have finally paid off
Quote:
So I'm now feeding YV12 and so far the SD upscale autodection from ffdshow seems to work flawlessly but I was wondering if you could slightly polish the gamut mapping part please? 1) 25fps SD is guessed as SMPTE-C, it very much is EBU. Could you please fix that? 2) My display is calibrated via an 11kb 3x1DLUT .cal file generated by ArgyllCMS, I guess it would be quite a bit of work for you but would that make any sense to be able to import it into mVR and have it processed at the RGB conversion stage in 16bit? Of course you would need to bypass the graphic card's CLUT, but when outputting TMDS24 it might very much improve the PQ 3) ATM, it's not possible to input custom display primaries for a display, and my TV set is pretty much dead on the HDTV gamut: If I were able to input its exact RGBW coordinates and have a "best guess" primaries detection for EBU/SMPTE-C/HDTV gamuts, that'd be too awesome for words! I might also fancy a rule for 23.976/25/29.97 HD so I can force SMPTE-C/EBU/HDTV in this order if any possible, and possibly a quick access option to switch between them when I don't have a keyboard easily reachable. Hardcore example: I've got a SD 29.97fps video that needs REC.709 primaries and HDTV gamut, it's an endless keyboard shortcut madness atm....if you could add two simple "toggle matrix" and "toggle gamut" buttons under "edit settings" and "show tray icon", this would be sooo convenient Last edited by leeperry; 19th October 2012 at 05:37. |
|
19th October 2012, 02:28 | #14869 | Link | |
Registered User
Join Date: May 2009
Posts: 212
|
Quote:
The major difference is about FP64 calculation performance for Tesla product line. For scientific math calculation purpose, FP64 precision is often required. GK104 is weak at this part (about 1/6 of FP32 throughput) and even slower than Fermi-based GF110. The retina hand-held and 4Kx2K TV display devices will become more and more common. But the content's resolution will not catch up so fast. Thus I think these real-time high-quality scaling algorithm with reasonable gate-count cost + power-consumption is always needed. |
|
19th October 2012, 02:32 | #14870 | Link | ||
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
Quote:
Quote:
Not sure how a normal user would like seeing those options though, maybe only if madshi implements an "advanced user" mode. I vote for high-quality over gate-count cost + power-consumption myself but I would be interested in what method the iPad 3 uses as it has to resize everything. I think NicolasRobidoux and madshi are showing how it can be done better, getting their ideas into hardware is another step. Last edited by Asmodian; 19th October 2012 at 02:42. |
||
19th October 2012, 03:21 | #14871 | Link | |
Registered User
Join Date: Aug 2008
Posts: 86
|
Quote:
|
|
19th October 2012, 04:57 | #14873 | Link | ||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Well, the idea of 16bit 96MB 3DLUT's originally came up because tritical's gamut mapping Avisynth plugins were too CPU hungry, then madshi decided to support them because he wanted to delegate all the CMS work to someone else.
The thing is that gamut mapping is a trivial job for a PS script: http://www.avsforum.com/t/912720/ These days, 96MB 3DLUT's only really make sense if you wanna convert YUY2 to RGB for instance IMHO. They are way overkill for something as simple as gamut mapping and madshi finally took the bull by the horns and added PS-based gamut mapping in mVR. The only problem is that it doesn't allow custom RGBW coordinates and as you can see my 46" LCD is only a few ΔE's away from the REC.709 gamut: Quote:
I would also appreciate an option to leave the display gamma curve untouched because FWIU video content is encoded in 2.2 but there is no hard rule about the display gamma itself. A good rule of thumb seems to go 2.2 if your display has a poor native CR or 2.4/2.5 if you can afford it. Well, it's processed in 8bit when outputting TMDS24, on top of mVR's dithered output so it will potentially induce banding and noise. I would very much fancy the idea of being able to import a 11kb .cal file instead of a 96MB 3DLUT: you get PS-based gamut mapping(which already exists in mVR) and 1D LUT text based color correction. No need to wait for a 96MB LUT to be loaded or the endless headaches that go along with building and storing 3DLUT's And you can't merge a .cal file into a 3DLUT anyway AFAIK. Besides yCMS hasn't been updated in a while, yRGB is not a finalized standard and Graeme Gill(Argyll's coder) has all the time and experience to assist madshi if need be. Quote:
There's really only 3 gamuts we care for: -EBU for PAL SD -SMPTE-C for NTSC SD -REC709/HDTV/sRGB for HD and FRAPS videos Of course, some ppl claim that HD mastered in the US still uses SMPTE-C due to the fact that it's calibrated on CRT's and that HD done in the EU runs EBU.....everyone has his own opinion and this is out of the scope: http://www.avsforum.com/t/1038602/ The cherry on the cake would be the ability to choose the source gamut for HD depending on its framerate, for the conspiracy theory believers amongst us It's currently a crazy keyboard shortcuts story(that won't even work with the m$ virtual keyboard) when you want to cycle through decoding matrixes and gamuts, so some quick access buttons would be highly appreciated. But well, I recently got ahold of one of these on ebay for 20 bucks, so I could always assign its top buttons for matrix/gamut/levels toggling et voilà What I would really need at this point is SD PAL from ffdshow to be recognized as EBU and the ability to input the actual RGBW coordinates of my display....so mVR could do its magic for me all over again! The additional noise of my gamut mapping Avisynth scripts was OK'ish on CRT/DLP because those two technologies are a noise/mosquito feast but a crisp LCD screen connected in TMDS24 is merciless with noise...so I'm afraid I can't afford ffdshow/avisynth 8bit processing anymore Last edited by leeperry; 19th October 2012 at 07:22. |
||
19th October 2012, 05:28 | #14874 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
Check out the yCMS section, I just write my RGBW primaries into madVR and it takes care of the rest.
Code:
Red,Yxy,33.035683,0.654655,0.341453 Green,Yxy,86.717087,0.267918,0.663321 Blue,Yxy,13.308223,0.148377,0.064612 White,Yxy,42.328707,0.314018,0.326278 It isn't a performance hit, at least on my system. Last edited by Asmodian; 19th October 2012 at 05:31. |
19th October 2012, 05:47 | #14875 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Nice! but it's asking to download yCMS so I presume that it will build a 96MB yRGB 16bit 3DLUT when I could easily get away with PS-based gamut mapping. I guess I'm so close to REC.709 that I'll just stick to it if allowing custom coordinates isn't to be considered without the use of a 96MB 3DLUT file
|
19th October 2012, 13:34 | #14876 | Link | |||||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Jinc3 AR Ok, there's a tiny bit of ringing left in the image, but it's really not much, and the image is oh so much sharper than EWA quadratic and VSQBS and also less aliased than EWQ quadatric. Quote:
|
|||||||||||||||||
19th October 2012, 13:38 | #14877 | Link | ||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Yes, that sounds like a very likely explanation.
Quote:
Quote:
For now... (And no, that does not necessarily mean that there's more demanding stuff coming *soon*. But some day...) Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
That settings page with those two buttons was just meant to be a helper page to get access to the full madExcept settings dialog in case you have the tray icon disabled. I don't plan to add any more buttons to that settings page. |
||||||||||||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|