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.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th June 2011, 17:47   #7981  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by STaRGaZeR View Post
What you call "the truth" is what ffdshow RGB32 outputs, or what Fraps lossless outputs, for example. These 2 decoders output RGB32. Why do I think that this output should not be touched? Because both of them compute the RGB32 frames using the correct matrices for 601/709, SD/HD, levels, etc. They do (in ffdshow you can configure it, Fraps is always 709/PC range) what you do in madVR when feeded with YV12, so their RGB32 output is comparable to the RGB32 output of madVR to the graphics card.
No, that's actually not true.

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:
Originally Posted by STaRGaZeR View Post
Processing in madVR is a bad idea, because it'll redo everything, messing up colors, levels, gamma, etc. as it does right now.
madVR doesn't redo everything. madVR only performs those conversions which are necessary to achieve correct results. If there's double processing the reason for that is simply that madVR wasn't informed properly that another filter already performed the same operation before.

Quote:
Originally Posted by STaRGaZeR View Post
The most interesting effect happens with the levels setting. My monitor is a PC monitor, so 0-255 of course. When PC levels is selected in madVR the videos are double expanded: by ffdshow/fraps (because they assume no further conversions will be done) and then by madVR, yet I'm telling madVR the truth, my monitor is PC range. This option doesn't have a "something else" setting, so I have to lie to madVR and tell it my monitor uses TV range to get proper levels.
The real fault here is in ffdshow/fraps. They can not assume that no further conversion will be done because it's the duty of the video renderer to care about display levels. ffdshow/fraps don't even know on which display the output will be shown!!!! If you have a dual monitor setup and one monitor needs PC levels while the other monitors needs video levels, how would ffdshow/fraps know what is needed?? They are not in a position to make such decisions. Only the video renderer is. Configure ffdshow to leave levels alone and the double stretching will go away.

Quote:
Originally Posted by STaRGaZeR View Post
RGB32 is a format that is intended to be displayed as-is
Not true at all.

Quote:
Originally Posted by STaRGaZeR View Post
On a side note, in MPC-HC you can tell EVR your monitor's output range, and it does work when EVR itself does the YCbCr->RGB conversion. However, if you feed EVR with RGB32 the setting will have no effect, like it should be.
You're actually using EVR behaviour to proof a point? Are you serious!?

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.
madshi is offline   Reply With Quote
Old 6th June 2011, 18:05   #7982  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by madshi View Post
Are there people who provide grayscale measurements but not gamut measurements? What would be the purpose of that?
People that only want to correct the gamma. Furthermore, I see no point of having it disabled... It looks quite strange.

Quote:
Originally Posted by madshi View Post
Works for me. Can you post the exact text you've copy/pasted here for me to test with?
It's too big to fit in a post. Grab it here.
yesgrey is offline   Reply With Quote
Old 6th June 2011, 18:08   #7983  |  Link
groen
Registered User
 
Join Date: May 2011
Posts: 16
Bug, When using the seekbar and exclusive mode, when watching a xvid with 6 channel ac3. Using the seekbar seems to freeze the play. Which means I have had to disable the seekbar.
groen is offline   Reply With Quote
Old 6th June 2011, 18:34   #7984  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by yesgrey View Post
People that only want to correct the gamma.
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:
Originally Posted by yesgrey View Post
It's too big to fit in a post. Grab it here.
Ah, the problem was that the Memo control didn't have a horizontal scrollbar. That resulted in unexpected line breaks, which confused by parser.
madshi is offline   Reply With Quote
Old 6th June 2011, 18:44   #7985  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
Ok, I can see that this might be confusing overall. I'll try to improve on that. Maybe I can add an option "don't process" or something like that to the "color & gamut" option and use that as default.
Thank you. That should help.

Quote:
Originally Posted by madshi View Post
I'm sorry, but this is not possible. madVR has strict requirements on the 3dlut. It *MUST* be yRGB RGB_Video input, or else you will not get proper results. In the same way older madVR versions had a strict requirement that the 3dlut *MUST* be YCbCr. Older madVR versions were a bit "stupid" in that they naively sent all content to the 3dlut, not caring whether the 3dlut matched the source or not. Now with v0.62, madVR requires the 3dlut to have a specific "input" format. That way madVR can do the necessary conversions to make any content compatible to the 3dlut. So in other words: The 3dlut input side is defined and you can't change it, if you want to get proper results. But the output side is still more or less flexible. Output must be 16bit RGB_Video, but other than that madVR will accept whatever you want as 3dlut output.

The new 3dlut concept is to let madVR convert any source format to "yRGB RGB_Video". If the source is full range, the proper madVR behaviour would be to stretch the source to video levels before feeding it into the 3dlut. This is not implemented in madVR yet, though.
So you've decided not to support full-range video in madVR version >0.61? I really think this should somehow be supported. madVR compressing 0-255 to 16-235, passing it to a 3dlut as 16-235, and then expanding back to 0-255, is very messy and won't result in proper color correction with the 3dlut since it requires the input levels of the source properly defined.

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:
Originally Posted by madshi View Post
I think the new concept is good and I don't really see any disadvantage in having the 3dlut input side strictly defined. If you see any disadvantages of that (in real life), please let me know.

The transfer function depends on which input "format" you choose. If you use "yRGB" this will automatically default to a 2.2 pure power transfer function. If you use "HD" that will default to a BT.709 curve, I think. Same with output.
To achieve proper linerization for color-correction, the 3dlut needs to be created taking the video gamma and/or display gamma into account. By yRGB you are forced to pick a global input_transfer_function (yCMS defaults to a 2.2 power-curve), which won't be technically accurate for all videos. This unfortunately is unsolvable when using yRGB 3dlut which combines color-spaces. The other issue arises when those like Janos666 using an input_transfer_function for a 2.35 gamma power-curve. This is advanced yCMS usage, but I just see madVR assuming things as bad, since the shader gamma settings will get skewed or become invalid.

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:
Originally Posted by madshi View Post
It's not a matter of how easy it is for me to implement. The real question for me is how many people would use it. I don't want to add controls to the settings dialog which only a handful of people will ever use. The problem is not my programming time, but the usability of the settings dialog.
Everybody that is specifying an external 3dlut would potentially use it. As it currently stands (see my comments above), I think it's best that you don't support external 3dluts, so madVR has full control over lut creation to match its fixed needs. Using a 3dlut which doesn't match madVR's assumptions is just going to cause problems.

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:
Originally Posted by madshi View Post
Sure. Can you please ask God to extend my days to 48hours each? Seriously, wizards are nice and might come at some time. But there are so many other things I need to do which are more important.
48 hour days
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:
Originally Posted by madshi View Post
If the display has a flawed gamma curve then without a meter + measurements + yCMS correction the display will stay flawed, no matter if I change the gamma via shader math or not. The user can try modifying the gamma with madVR's shader math gamma tweaks. Eventually it might make the image quality better or worse overall. I'll leave that up to the user. E.g. just imagine a user has a display which has a flawed but ok gamma curve, which is just way too bright. If he has no meter, madVR should still allow him to bring the overall gamma curve down to a more reasonable level. Of course it won't be "accurate". But it would still be a noticeable improvement.
Letting people define a custom gamma curve adjustment with a graph of a gamma curve where you can specify and drag points of the curve would be kind of cool. 48 hour days, I know, I'm not really serious, but that would enable people to achieve better results with a non-standard gamma. For example, I would finally have a way to mimic the scaled BT709 gamma curve which Argyll CMS creates.

Quote:
Originally Posted by madshi View Post
If that someone does have a meter, why is he not using yCMS?
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:
Originally Posted by madshi View Post
You're seeing this with your experience with yCMS. But if you think about a new user, seeing this for the first time, he won't care what is done via yCMS and what is done via shader math. I don't want to design the settings dialog after technical things like that.
I was half-joking with that comment. It doesn't change the fact that new users seeing madVR 0.62 for the first time wouldn't have a clue what to do with all the new settings and functionality. Even I needed to asks lots of questions attempting to figure out settings and make sure madVR 0.62 is doing what I want it to, new users have no hope. Chances are high they will set things wrong without realizing things are wrong.

Quote:
Originally Posted by madshi View Post
What exactly do you understand as "Input" in this context, btw? It is not clear to me. Why would the "Properties" page be "Input"? Do you mean input into the display? Or input into madVR? Or input into yCMS? Or input into the 3dlut? I don't think marking the "Properties" page as "input" would be of any help. It wouldn't help myself, at least, because I don't see the connection between "Properties" and "input".
Input since the properties page defines settings (of the display) which are needed for the output settings of the Color & Gamma page.
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
cyberbeing is offline   Reply With Quote
Old 6th June 2011, 18:52   #7986  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
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
madshi is offline   Reply With Quote
Old 6th June 2011, 19:04   #7987  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 928
Quote:
Originally Posted by madshi View Post
I don't understand that. The log says that madVR actually tries to activate the 1080i59 mode, but Windows returns with an error code of "bad mode".

Can you send another log where madVR actually manages to switch from a different mode to 1080i59?
OK, here is the log
http://www.filesonic.com/file/114462...adVR_-_log.zip

Quote:
Hmmmm... That might be difficult, not sure. Will have to check if I can detect that the source is interlaced.
I'm thinking that if madVR can't receive interlaced content, then unless the decoder is doing IVTC and sending 24p to madVR my display would not do IVTC (by frame inspection). The puzzling thing is that when Windows is refreshing at 59i, my display does IVTC with madVR (though it seems to work only half the time, or I have to re-seek, sort of it has to jump just to the right frame/field for it to work). I don't think the decoders (ffdshow and CoreAVC) do IVTC?
Andy o is offline   Reply With Quote
Old 6th June 2011, 19:05   #7988  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 928
oops beat me by a few mins, I'll try with 0.63.
Andy o is offline   Reply With Quote
Old 6th June 2011, 19:13   #7989  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by cyberbeing View Post
So you've decided not to support full-range video in madVR version >0.61? I really think this should somehow be supported. madVR compressing 0-255 to 16-235, passing it to a 3dlut as 16-235, and then expanding back to 0-255, is very messy and won't result in proper color correction with the 3dlut since it requires the input levels of the source properly defined.
I don't understand why it wouldn't result in proper color correction. Can you explain?

Quote:
Originally Posted by cyberbeing View Post
RGB_Video is 16-235 (16-240), everything outside of that range is clipped.
No, according to yesgrey it's not clipped anymore since yCMS v1.6.

Quote:
Originally Posted by cyberbeing View Post
To achieve proper linerization for color-correction, the 3dlut needs to be created taking the video gamma and/or display gamma into account.
If the 3dlut were the only place where conversions are done then you would be right. But the source data is already converted by shader math before sending it to the 3dlut. If the shader math correctly converts any source format to yRGB with a pure power curve of 2.2, then the 3dlut should be able to properly process the data further. I don't really see the problem?

@yesgrey, any comments?

Quote:
Originally Posted by cyberbeing View Post
By yRGB you are forced to pick a global input_transfer_function (yCMS defaults to a 2.2 power-curve), which won't be technically accurate for all videos.
It would ill not be accurate if you fed the videos into the 3dlut without modification. But that's not what happens.

Quote:
Originally Posted by cyberbeing View Post
The other issue arises when those like Janos666 using an input_transfer_function for a 2.35 gamma power-curve.
What purpose does that have? Setting the input_transfer_function to 2.35 is a lie because the source doesn't really have that transfer function, or am I wrong? Isn't that even invalid yCMS usage?

Quote:
Originally Posted by cyberbeing View Post
Everybody that is specifying an external 3dlut would potentially use it. As it currently stands (see my comments above), I think it's best that you don't support external 3dluts, so madVR has full control over lut creation to match its fixed needs. Using a 3dlut which doesn't match madVR's assumptions is just going to cause problems.

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.
External 3dlut support is not only for manually created yCMS 3dluts. There might be other external tools which create 3dlut files, too. We've intentionally made the 3dlut format open source and free.

Quote:
Originally Posted by cyberbeing View Post
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)
No. It's like this:

(1) chroma upsampling
(2) YCbCr -> RGB conversion
(3) gamma adjustments and gamut conversion
(4) scaling
(5) PC levels stretching, if needed
(6) dithering

Quote:
Originally Posted by cyberbeing View Post
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)
(1) chroma upsampling
(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?
madshi is offline   Reply With Quote
Old 6th June 2011, 19:15   #7990  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 568
Quote:
Originally Posted by Andy o View Post
I'm thinking that if madVR can't receive interlaced content, then unless the decoder is doing IVTC and sending 24p to madVR my display would not do IVTC (by frame inspection). The puzzling thing is that when Windows is refreshing at 59i, my display does IVTC with madVR (though it seems to work only half the time, or I have to re-seek, sort of it has to jump just to the right frame/field for it to work). I don't think the decoders (ffdshow and CoreAVC) do IVTC?
Well, you could try my half-finished filter. No promises.

Last edited by e-t172; 6th June 2011 at 19:17.
e-t172 is offline   Reply With Quote
Old 6th June 2011, 19:36   #7991  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 928
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
Andy o is offline   Reply With Quote
Old 6th June 2011, 19:39   #7992  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 928
Quote:
Originally Posted by e-t172 View Post
Well, you could try my half-finished filter. No promises.
thanks, I'll try that when I have this other thing sorted out.
Andy o is offline   Reply With Quote
Old 6th June 2011, 19:40   #7993  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,307
Quote:
Originally Posted by madshi View Post
No, that's actually not true.

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.
I don't really know about this stuff, but are you saying that, since no renderer does gamut correction besides madVR, all of them will only display 1 type of content (NTSC, PAL, etc.) properly, assuming the display is locked to one of them? That rises the question: how does madVR know which correction it has to apply? You tell it your monitor properties, but how does it decide between the source options?

Quote:
Originally Posted by madshi View Post
The real fault here is in ffdshow/fraps. They can not assume that no further conversion will be done because it's the duty of the video renderer to care about display levels. ffdshow/fraps don't even know on which display the output will be shown!!!! If you have a dual monitor setup and one monitor needs PC levels while the other monitors needs video levels, how would ffdshow/fraps know what is needed?? They are not in a position to make such decisions. Only the video renderer is. Configure ffdshow to leave levels alone and the double stretching will go away.
ffdshow does "know" on which display the output will be shown, you can change it in the settings. Default is PC range. Fraps is hardcoded, as all material recorded by it is PC range and virtually 100% of it will be displayed in PC monitors.

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:
Originally Posted by madshi View Post
madVR doesn't redo everything. madVR only performs those conversions which are necessary to achieve correct results. If there's double processing the reason for that is simply that madVR wasn't informed properly that another filter already performed the same operation before.
And how does madVR know which corrections are necessary and which aren't, when it doesn't know the original properties of the video? The corrections madVR does now with all known (by me) RGB sources are incorrect because of this. That's the point, no filter I know of tells the renderer any of this info. The same issue happens when resizing SD content to HD, the renderer doesn't know that the source is SD and converts it with HD settings, you know the result. The common trend among renderers is to convert assuming their input resolution is the source resolution, just like the common trend is to not touch RGB input because it's assumed to be properly processed. There's no paper or anything that tells us where this should be done, but making asumptions nobody else does is a very bad idea IMHO, specially when there's no absolute right or wrong decission.

Quote:
Originally Posted by madshi View Post
You're actually using EVR behaviour to proof a point? Are you serious!?
Nope. Just telling that madVR won't work correctly with any known RGB32/24 content, while EVR, VMR, Haali, etc. will work without issues. EVR was just an example.

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!
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 6th June 2011, 20:10   #7994  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by madshi View Post
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.
OK. I didn't think that other things would depend on it, but no problem, it won't affect me. I'm creating my own manually.

Quote:
Originally Posted by cyberbeing View Post
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.
Nothing is clipped, as long as you maintain 16-235 on both input and output of 3DLUTs, like madshi is doing.

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:
Originally Posted by cyberbeing View Post
To achieve proper linerization for color-correction, the 3dlut needs to be created taking the video gamma and/or display gamma into account. By yRGB you are forced to pick a global input_transfer_function (yCMS defaults to a 2.2 power-curve), which won't be technically accurate for all videos.
You're missing one thing. The gamut correction from PAL/NTSC/HD to yRGB is performed on linear light. For that, madVR converts to linear light using each standard's transfer function. Then, it encodes the linear light again to gamma light to minimize quantization errors when accessing the 3DLUT. yRGB uses a pure power function 2.2 gamma curve, so, yCMS will get exactly the same linear light data as before. We created this intermediate color space (yRGB) just to allow
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.

Quote:
Originally Posted by madshi View Post
@yesgrey, any comments?
See above.
yesgrey is offline   Reply With Quote
Old 6th June 2011, 20:10   #7995  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 928
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
Andy o is offline   Reply With Quote
Old 6th June 2011, 20:12   #7996  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,761
Quote:
Originally Posted by STaRGaZeR View Post
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-
madVR can do a much better YUV->RGB conversion then any decoder i've seen, so clearly the optimal solution is to just teach the decoder to tell madVR what the source format really was, and you would never again need YUV->RGB conversion in a decoder.

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.
nevcairiel is offline   Reply With Quote
Old 6th June 2011, 20:17   #7997  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by STaRGaZeR View Post
I don't really know about this stuff, but are you saying that, since no renderer does gamut correction besides madVR, all of them will only display 1 type of content (NTSC, PAL, etc.) properly, assuming the display is locked to one of them?
Not quite. If you use t3dlut and a 3DLUT file for each source you could get proper colors using other video renderers, but why would you do it if you can have it much simpler with madVR?
yesgrey is offline   Reply With Quote
Old 6th June 2011, 20:17   #7998  |  Link
Andy o
Registered User
 
Join Date: Mar 2009
Posts: 928
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.
Andy o is offline   Reply With Quote
Old 6th June 2011, 20:29   #7999  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
I don't understand why it wouldn't result in proper color correction. Can you explain?
You would probably be better off asking yesgrey. I seem to remember being told that setting the input levels correctly were needed for yCMS gamut/gamma corrections to be accurate.

Quote:
Originally Posted by madshi View Post
No, according to yesgrey it's not clipped anymore since yCMS v1.6.
I misspoke. Input RGB_Video wouldn't be clipped, but WTW/BTB would be compressed to limited-range levels when passed through the 3dlut with RGB_Video output. In other words if you fed 0-255 video to a RGB_Video -> RGB_Video, 0-255 would be compressed by the 3dlut to 16-235, get processed as 16-235, and output as 16-235.

Quote:
Originally Posted by madshi View Post
If the 3dlut were the only place where conversions are done then you would be right. But the source data is already converted by shader math before sending it to the 3dlut. If the shader math correctly converts any source format to yRGB with a pure power curve of 2.2, then the 3dlut should be able to properly process the data further. I don't really see the problem?
So madVR is treating all videos as a 2.2 power-curve (which is a reasonable guess, but isn't necessarily correct)? The problem would be if you wanted your videos to be linearized with the assumption they were something other than a 2.2 power-curve, like a REC709 curve or some other arbitrary gamma which is unique to the source.


Quote:
Originally Posted by madshi View Post
It would ill not be accurate if you fed the videos into the 3dlut without modification. But that's not what happens.
Then what does happen? madVR linearizes REC601 with a REC601 curve, REC709 with a REC709 curve, PAL with a PAL curve and then coverts to a gamma of 2.2? If that is really what you are doing, that gamma of 2.2 intermediary gamma should be configurable when used with a 3dlut.


Quote:
Originally Posted by madshi View Post
What purpose does that have? Setting the input_transfer_function to 2.35 is a lie because the source doesn't really have that transfer function, or am I wrong? Isn't that even invalid yCMS usage?
I don't believe so, yesgrey seemed to think it was a valid use-case of the option. janos666 was using the input_transfer_function to describe his display rather than the transfer function of the video.


Quote:
Originally Posted by madshi View Post
External 3dlut support is not only for manually created yCMS 3dluts. There might be other external tools which create 3dlut files, too. We've intentionally made the 3dlut format open source and free.
If that is the reason you left it in, so be it. There would be little incentive to anybody else to implement an application for creating 3dlut files for madVR with the input format requirements being so limited. Sure the gamut adaption could be different, but you've cut out madVR's ability to use 90% of the 3dlut functionality in 0.62+. I still don't like that you are limiting the usefulness and flexibility of the 3dlut compared to shaders.


Quote:
Originally Posted by madshi View Post
No. It's like this:

(1) chroma upsampling
(2) YCbCr -> RGB conversion
(3) gamma adjustments and gamut conversion
(4) scaling
(5) PC levels stretching, if needed
(6) dithering


(1) chroma upsampling
(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.
Thanks for this. I'm still a bit confused how madVR is dealing with 16-235 input vs 0-255 input. Can you explain? How does madVR processing of 16-235 YUV input differ from 0-255 YUV input? How does madVR processing of 16-235 RGB input differ from 0-255 RGB input?

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?

Quote:
Originally Posted by madshi View Post
Please check v0.63. Maybe you'll find it an improvement?
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:
Originally Posted by yesgrey View Post
Nothing is clipped, as long as you maintain 16-235 on both input and output of 3DLUTs, like madshi is doing.

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.
Is that really true that conversion from 0-255 to 16-235 to 0-255 in 32 bit FP math is lossless? It seems like it would be lossy to some extent.

Quote:
Originally Posted by yesgrey View Post
You're missing one thing. The gamut correction from PAL/NTSC/HD to yRGB is performed on linear light. For that, madVR converts to linear light using each standard's transfer function. Then, it encodes the linear light again to gamma light to minimize quantization errors when accessing the 3DLUT. yRGB uses a pure power function 2.2 gamma curve, so, yCMS will get exactly the same linear light data as before. We created this intermediate color space (yRGB) just to allow
a simpler user experience, or else the users would need to use 6 3DLUT files.
Does madVR actually do this? If it does, this conversion to 2.2 still bothers me. I'll need to do some testing. If I'm not able to get madVR 0.62+ to produce a video which looks identical to 0.61 then something is wrong. Sleep first, then I'll test.

Quote:
Originally Posted by yesgrey View Post
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.
I don't use the Gamma_Curve command, which is why I am stressing about it. I've gotten to the point that I don't want anything to touch my gamma (except linearizing for gamut correction).

Last edited by cyberbeing; 6th June 2011 at 20:47. Reason: for yesgrey reply above
cyberbeing is offline   Reply With Quote
Old 6th June 2011, 21:17   #8000  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,307
Quote:
Originally Posted by nevcairiel View Post
madVR can do a much better YUV->RGB conversion then any decoder i've seen, so clearly the optimal solution is to just teach the decoder to tell madVR what the source format really was, and you would never again need YUV->RGB conversion in a decoder.

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.
Very true. However, there are postprocessing steps that for optimal quality require non-chroma subsampled formats, and this stuff becomes a mess. Also, how do you teach every decoder out there to communicate properly with a renderer made by a random guy in a random forum? That would be awesome, and people here would do it, but I'll be yet another hack in a world full of hacks.

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

Quote:
Originally Posted by yesgrey View Post
Not quite. If you use t3dlut and a 3DLUT file for each source you could get proper colors using other video renderers, but why would you do it if you can have it much simpler with madVR?
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.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.