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. |
6th June 2011, 17:47 | #7981 | Link | ||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
NTSC, Blu-Ray and PAL all have different primary color coordinates. The differences are *NOT* dealt with by just using the correct YCbCr -> RGB matrix. E.g. if you take the color "red: 200; blue: 20; green: 20", this color is supposed to result in a different wavelength being produced by your display for NTSC content than for PAL or Blu-Ray. Practically that means, if you display an NTSC SD DVD you have to calibrate your display to BT.601 primaries. If you display a Blu-Ray, you have to calibrate your display to BT.709 primaries. If you display a PAL DVD, you have to calibrate your display to PAL primaries. If you don't do that, you'll get incorrect colors. All of this applies even if you convert YCbCr -> RGB with the correct matrices! The solution to this dilemma is to perform gamut correction. Basically if you have RGB data coming from an NTSC DVD, madVR converts this RGB in such a way that it no longer needs NTSC primaries, but instead it's converted to HD/BT.709 primaries. As a result you can display this NTSC on your BT.709 display now with correct colors. Which is *not* possible without gamut correction - unless you calibrate your display to BT.601 instead of BT.709. Quote:
Quote:
Not true at all. Quote:
The reason why EVR reacts to the monitor output range information when being fed with YCbCr, but not when being fed with RGB is that the GPU driver performs the video levels stretching when the video renderer calls the Direct3D StretchRect API to convert YCbCr -> RGB. This is purely a programatical thing, not a decision based on science or anything. |
||||
6th June 2011, 18:05 | #7982 | Link | ||
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Quote:
Quote:
|
||
6th June 2011, 18:34 | #7984 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Does that really make sense? Why would anyone who has a meter to get gamma measurements decide to not correct the gamut, too?
Sure, I can add support for that. But it's not as easy as it sounds. There are a lot of other controls depending on this. Also in my source code I've fixed that whenever a 3dlut is active, gamut is supposed to be handled by the 3dlut. Quote:
|
|
6th June 2011, 18:44 | #7985 | Link | ||||||||
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Quote:
RGB_Video is 16-235 (16-240), everything outside of that range is clipped. In order for yCMS to do proper color correction, a RGB_Video -> RGB_Video 3dlut would be needed for Limited-range video, and a RGB_PC -> RGB_PC 3dlut would be needed for Full-range video. I'm sure you understand what I'm saying and the problems, correct? If you are intent on using only a single 3dlut, using a RGB_PC -> RGB_PC one would be better so nothing is ever clipped. You would still get slightly incorrect color correction by the 3dlut, but I think that is better than things getting clipped or compressed to limited-range levels. In this case you would pad limited range videos to 0-255 and leave full-range videos as-is. You still really need two luts for gamut & grayscale correction to work as yCMS expects it to. Quote:
This basically just means madVR 0.62+ have more limited 3dlut functionality than previous 'dumb' versions. Most users won't care, but madVR 0.61 will forever be useful when creating a 3dlut which doesn't match the more limited use-case of 0.62+. If gaining yRGB support means loosing advanced 3dlut functionality and gaining benefits I have no use for, I'm not really seeing it as a good thing. Quote:
I'm also beginning to come around that more bare-bones 3dlut functionality with yRGB isn't necessarily a bad thing if it meets the core-needs of the majority of users. This means that madVR needs to make clear to users it's new 3dlut requirements and limitations by removing external 3dlut support. If the 3dlut files you make externally are forced to be identical to the ones madVR creates, force everybody to create them in madVR. Quote:
How about adding tool-tips to settings with brief descriptions of their purpose? That should only take only a few minutes (vs hours to build a Wizard), and would likely be helpful to new users. If it is too much work to simplify settings, they need to be clearly explained. As things currently stand, the setting in 0.62 aren't very intuitive, which has made usability go from bad->worse for new users. I'm sure you would gain back all the time spent implementing usability improvements, since people could figure things out for themselves and ask less questions. Quote:
I myself am making may assumptions about the new display chain, so I think you need to clarity the shader-only and 3dlut + shader display chain. I was under the impression that the shader display chain had additional functionality based on set gamut setting in the properties page, which you don't have when using a 3dlut. Your reply makes it sound like this is not the case. The following is what I assume the new display chain is, please correct any errors and fill in missing steps, so I have a better understanding: Shaders-only 709/601/PAL Video -> 709/601/PAL Display Conversion (if needed) YUV (16-235 or 0-255) -> yRGB (16-235 clipped) conversion Basic Gamut adjustments (if needed) yRGB -> RGB (0-255) Gamma adjustments (if needed) Resize video (if needed) 3dlut + Shaders YUV (16-235 or 0-255) -> yRGB (16-235 clipped) conversion Gamut adjustments via 3dlut yRGB (16-235) -> RGB (0-255) Gamma adjustments (if needed) Resize video (if needed) Quote:
Quote:
Output since these adjustments are made based on the input settings of Properties page (display). I think of Input as assumptions needed for adjustments, and Output as adjustments made based on those assumptions. Last edited by cyberbeing; 6th June 2011 at 19:10. Reason: typo |
||||||||
6th June 2011, 18:52 | #7986 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
madVR v0.63 released
http://madshi.net/madVR.zip Code:
* fixed: couple of bugs in the display mode changer * fixed: nearest neighbor in v0.62 was broken (bilinear was used instead) * fixed: removed nonsense 9bit/10bit display bitdepth options * fixed: yCMS tab in settings dialog is now only visible on calibration page * added: complaint when yCMS is selected, but no gamut measurements provided * added new "enable gamma processing" option (default = off) * renamed "something else" to "unknown" * moved gamut/gamma options from "properties" page to "calibration" page * gamut/gamma options in calibration page are now grayed out when using 3dlut * gamma processing can't be enabled if calibration -> gamma is set to "unknown" * added primary/gamut "sRGB" option |
6th June 2011, 19:04 | #7987 | Link | ||
Registered User
Join Date: Mar 2009
Posts: 962
|
Quote:
http://www.filesonic.com/file/114462...adVR_-_log.zip Quote:
|
||
6th June 2011, 19:13 | #7989 | Link | ||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
@yesgrey, any comments? Quote:
Quote:
Quote:
Quote:
(1) chroma upsampling (2) YCbCr -> RGB conversion (3) gamma adjustments and gamut conversion (4) scaling (5) PC levels stretching, if needed (6) dithering Quote:
(2) YCbCr -> RGB conversion (3) gamma adjustments and gamut conversion (4) 3dlut (5) scaling (6) PC levels stretching, if needed (7) dithering The only real difference is that the gamma adjustments and gamut conversion either convert to the display target, or to the 3dlut input spec. Please check v0.63. Maybe you'll find it an improvement? |
||||||||
6th June 2011, 19:15 | #7990 | Link | |
Registered User
Join Date: Jan 2008
Posts: 589
|
Quote:
Last edited by e-t172; 6th June 2011 at 19:17. |
|
6th June 2011, 19:36 | #7991 | Link |
Registered User
Join Date: Mar 2009
Posts: 962
|
Now it doesn't work at all with 1080i59 in there, but it works with 1080i29, if 1080p23 is not there. If 1080p23 or 1080p50 is there, then it switches to those instead, in that priority.
Here are the logs for when it does work (1080i29 by itself) and when it doesn't (1080p23 and 1080p50 in there as well). http://www.filesonic.com/file/1144805584/madVR_logs.zip megaupload link for the same file, just in case. http://www.megaupload.com/?d=YDQWDWNG |
6th June 2011, 19:39 | #7992 | Link | |
Registered User
Join Date: Mar 2009
Posts: 962
|
Quote:
|
|
6th June 2011, 19:40 | #7993 | Link | ||||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
Quote:
The renderer is not in position either. It has no way of knowing the original source levels, as far as I can see madVR just assumes TV levels for everything. Fraps and PC-range encoded H.264 sources will always be wrong as long as this behaviour doesn't change. ffdshow adapts to this because it has all the info, the renderer cannot, unless you offer an option not to process RGB input. So what do we do, let the renderer assume source properties it doesn't have, or let the decoder assume monitor properties it doesn't have? The trend when YCbCr conversion is done in the renderer is to assume source properties, and the trend when the YCbCr conversion is done in the decoder (RGB output) is to assume monitor properties and not touching it in the renderer. You can go against the trend, but that won't give you much success I'm afraid. Quote:
Quote:
Do you know of any filters that, when outputting RGB32, work without issues in madVR? I don't. That's the main point, how to make RGB32 not suck in madVR! |
||||
6th June 2011, 20:10 | #7994 | Link | |||
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Quote:
Quote:
As long as madshi performs right the stretching from 0-255 to 16-235 (16-240), and back after the processing, considering that the sources are 8 bit and shader math is 32 bit FP, you will not have any precision loss, and only one 3DLUT would be enough. Quote:
a simpler user experience, or else the users would need to use 6 3DLUT files. Just to make it clearer, madVR's new processing chain should give the same results as the previous one when using yCMS and the Gamma_Curve command, so don't worry about it. I agree that the GUI might need some improvements, but the processing chain was thoroughly discussed by us before being implemented. See above. |
|||
6th June 2011, 20:10 | #7995 | Link |
Registered User
Join Date: Mar 2009
Posts: 962
|
madshi, to add to my post above... 1080i59 doesn't work at all now, and 1080i29 only works with 60p content (the interframe sample). With 59i content (m2ts from the Dolby bluray) it switches to 1080p50, when 1080p23, 1080p50, 1080i29 are in the list. When I add to those 1080i59, it doesn't switch at all from other rates.
logs: http://www.filesonic.com/file/1144990954/madvrlogs.zip same, megaupload: http://www.megaupload.com/?d=KQHRI7BY |
6th June 2011, 20:12 | #7996 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
OPENVIDEOINFOHEADER needs to get some traction. PS: AFAIK from reading some ffdshow code, it only guesses based on the video resolution regarding 601/709, it isn't actually smart enough to do it properly, unless i've missed that part.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 6th June 2011 at 20:15. |
|
6th June 2011, 20:17 | #7998 | Link |
Registered User
Join Date: Mar 2009
Posts: 962
|
Also, if madVR can't tell when the video is interlaced, then would it be possible for madVR to give priority always to 1080i59/60 when both 1080i59/60 (or 1080i29/30) and 1080p59/60 are on the list? For 59/60p content, one could just make it switch manually by adding 59p or 60p to the file name (since there's a lot more interlaced content than 60p content, it would be less practical to add the manual switch to 60i filenames). Of course for people who prefer 60p, they don't have to add 1080i60 to the list, so everybody wins.
|
6th June 2011, 20:29 | #7999 | Link | ||||||||||
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
From what you've said so far madVR converts everything to 16-235 levels, so madVR should never be fed 0-255 data as input? I'll take a look by tomorrow, I'm thinking I may just sleep on what you've said and the changes made. You've been helpful and informative, but all this back and forth is tiring me out, and I'm sure you as well. Hopefully your next set of replies will ease the last confusion for the time being. As of right now, I still can't help this lingering feeling that 0.62+ is a downgrade from 0.61 functionality wise (3dlut stuff). For my needs, does 0.62+ offer any advantage over 0.61 which are worth the loss of 3dlut flexibility? I'm still not sure yet. In the best of worlds, I would have liked madVR's old 3dlut behavior to coexist with the new, but I assume you removed it to reduce the code/settings complexity needed for two unique 3dlut/shader render paths. Quote:
Quote:
Quote:
Last edited by cyberbeing; 6th June 2011 at 20:47. Reason: for yesgrey reply above |
||||||||||
6th June 2011, 21:17 | #8000 | Link | |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
A new header filled with useful info is nice, but unsupported. That's bad. Yep, based on resolution. It could read the 601/709 flags from H.264 streams too as it does with the levels flag, if someone feels like doing that. Customizable enough True. But since I'm not a color freak I don't need that level of perfection. Just want to use madVR's awesome vsync with my RGB32 sources, is that simple. |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|