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. |
17th September 2012, 18:25 | #13901 | Link | |
Registered User
Join Date: Jan 2008
Posts: 589
|
Quote:
SetGammaRamp allows to set three 1D-LUTs (one for red, green, and blue). It's not one gamma ramp, it's three (3x1D-LUT). See D3DGAMMARAMP. When you set a ICC profile in the Windows color options, it doesn't do anything in itself. You need a ICC profile loader (such as xcalib - most calibration software come with something similar that runs at windows startup) to apply the profile to your video output. The loader usually takes the ICC profile set in the Windows color options (although that's just a design choice, technically it could just use any ICC profile), extracts the info it needs, and then calls SetGammaRamp to apply the profile to the video output. Of course, because SetGammaRamp only supports 3x1D-LUT, only part of the ICC profile is used and the result is not a complete calibration (white points and gamma is corrected, but hue and saturation stay untouched). There are also issues with some software like some games (e.g. Crysis) that erase the gamma ramps and don't restore them on exit; that's why I have a scheduled task that runs my calibration loader each minute to make sure it stays on. These gamma ramps have 16-bit precision per color (i.e. they convert from 8-bit to 16-bit). Not sure if all hardware use the extra 8 bits. Ideally the GPU should dither the results, but we would be lucky if they do. My dream would be to have an API like SetGammaRamp but with a better design (no hijacking from applications) and with 3DLUT capabilities. If we had that, then we could just apply a 3DLUT for the entire Windows desktop and be done with it. But I can only dream. Last edited by e-t172; 17th September 2012 at 18:31. |
|
17th September 2012, 18:26 | #13902 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
And yes, you're right. Switching to 59p would make more sense for this sample than switching to 23p. However, my current refresh rate changer is too stupid to actually care about which cadence was detected. As soon as you activate film mode with 59i content, the refresh rate changer thinks: Oh, this is a movie, so it must be 23p. And in 99.9% of all cases that's right. It even works for most Anime stuff. This 3:3 sample is one of a very rare exceptions. Well, it should play ok with 23p, too, but it should be a more fluid with 59p, of course. Anyway, not easy for me to fix. One of the problems is that cadences can break. What happens if a movie partially consists of 3:2 cadences and then switches to 3:3 cadences in between? Should madVR then switch from 23p to 59p and later back again? Not really sure how to handle this right now. I've some ideas for a future version, but it's not easy to fix right now, so you'll have to live with the current situation at the moment. I'll keep this in mind, though... |
|
17th September 2012, 18:30 | #13903 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
17th September 2012, 18:38 | #13904 | Link |
Registered User
Join Date: Jan 2008
Posts: 589
|
Indeed it is. As I said, you can still use 3x1D-LUTs to calibrate gamma and make sure white points follow the D65 illuminant. That's all it can do, but it's better than nothing IMO. You're out of luck for saturation and hue because fixing them would require (R, G, B) = f(r, g, b) (3D-LUT) instead of (R, G, B) = (f(r), f'(g), f''(b)) (3x1D-LUT).
That's why image editing software like Photoshop don't use hardware LUTs and use their own 3DLUT implementation like madVR does. You just have to be careful not to use both at the same time, for obvious reasons. |
17th September 2012, 19:11 | #13906 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
If that's ever considered, please be so kind as to make it optional because at this point there is no way to merge the 3x1D LUT data(such as a .cal file from Argyll) into a 3DLUT AFAIK, so both color corrections are required. Surely, if that's ever made possible, this option might come in handy to those who use 3DLUT's in mVR.....but I use a .cal file in Argyll in order to get my display to reach D65/2.4 in all Windows apps and 3DLUT files in ffdshow/avisynth to map gamuts, so I very much require mVR to not reset the graphic card's 10bit CLUT.
|
17th September 2012, 20:47 | #13908 | Link | |
Registered User
Join Date: May 2011
Posts: 94
|
Quote:
My set is in the basement and the room is always dimly lit. I will then keep it off. Thanks for taking the time to reply! |
|
18th September 2012, 09:31 | #13909 | Link |
Registered User
Join Date: Aug 2004
Posts: 29
|
mmm, I didn't read al the topic, it's too long, but I have a question:
ages ago I hit the limit of my gpu (GeForce8500GT) using madvr and scaling 720p content to full HD monitor res, but couldn't really afford a new gpu. right now I should be able to get a GeForce GT 610 for cheap, so I'd like to ask if it's powerful enough for madvr (lol, but yeah). Thanks. |
18th September 2012, 12:56 | #13910 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Maybe just fast enough for 1080p24 with 2-tap resizers. Probably not fast enough for anti-ringing lanczos and/or 1080p60. But I don't really know for sure. Of course you can always switch to "Bilinear" scaling, but that would be a really sad solution... |
|||
18th September 2012, 13:58 | #13911 | Link | |
Registered User
Join Date: Jun 2006
Posts: 452
|
Quote:
Just kidding.. |
|
18th September 2012, 14:19 | #13912 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Surely, if outputting TMDS and if there were an app allowing to merge my .cal Argyll file into a 3DLUT then resetting the graphic card's CLUT would theoritically be a better choice but sometimes I like to K.I.S.S. |
|
18th September 2012, 15:40 | #13913 | Link | |
Registered User
Join Date: Jul 2009
Posts: 19
|
Quote:
As I said, the issue is only present if vsfilter or xyvsfilter is handing the stream to madvr. I tested, and pc level rgb32 output directly from lav and cccp's ffdshow is properly handled by madvr. As a sort of off-topic side note: the fact that vsfilter doesn't support hi444pp currently means that it's converted to rgb by lav/ffdshow with the proper matrix, which means when hi444pp support will be added to xy/vsfilter, there won't be any need for the rec.601 hack with 4:4:4 videos! Last edited by mirkosp; 18th September 2012 at 15:45. |
|
18th September 2012, 17:38 | #13914 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
VSFilter & xy-VSFilter only support full-range RGB. If the decoder passes limited range RGB, subtitles will get double expanded by the video renderer. That said, it is a bit of a problem that madVR double-expands full-range RGB by default when a YCbCr bitstream is flagged as limited-range, and VSFilter is in the graph.
I ran into this problem as well when madshi was taking his break, but forgot to report it. The temporary workaround is to use CTRL+ALT+SHIFT+I & F2 change the default from auto-detect to PC range until you are done watching such files. For the next madVR version, I think it would be better if madVR always assumed RGB to be fullrange when connected to VSFilter. Last edited by cyberbeing; 18th September 2012 at 17:42. |
18th September 2012, 21:07 | #13916 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Well, with my sample it still happens using madVR antiringing v6, which is expected I guess since nothing else changed. Nevcairiel said this: Quote:
This reminds me of my other problem, that turned out to be potplayers video processing filter hacking image quality. So I disabled it and now I don't have brightness/contrast/saturation settings (also effects like mirror/rotate), but they still would be useful, because some files still don't reach black (or 16 I guess with cropped range). So basically modifying brightness is what I miss most from madVR at the moment. I suppose effects could be added by anyone when you add pixel shader script support. (Maybe its impossible for the player to modify brightness without butchering upscaling, but anyway it always does so. ) The recent anti-ringing builds make me wonder: is NNEDI3 resizing considered? You seemed to like it in the non-ringing Lanczos thread. (Me too.) |
||
18th September 2012, 21:09 | #13917 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Implementations so far are way too slow for realtime usage. Its sad.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
18th September 2012, 21:47 | #13919 | Link | |
Registered User
Join Date: Jan 2011
Posts: 107
|
Quote:
What we need is to abstract the algorithms to run in GPU hardware with CUDA |
|
18th September 2012, 22:18 | #13920 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
I'm not sure if it is well suited to the way GPUs work (every pixel should ideally run through the same code). I might look into this in the future, but probably not soon. |
||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|