madVR - high quality video renderer (GPU assisted)

[madshi]

madVR now actually slightly beats out PDVD for those scenes for me. So, again, well done. That's pretty amazing since you weren't intending to "fix" anything! :D
Yes. Furthermore: This is just with the standard resamplers. Image quality should further improve when I implement some better quality upsamplers. (Not too soon, though.)

I'm using J. River's MC16 these days and when I hit stop MC16 crashes
Oh, this does look like a madVR problem, not an MC problem. Is this 100% reproducible?

post processing with FFDSHOW that way couldn't have been good for PQ, right?
I don't know, not sure how you configured ffdshow exactly. And no, I don't want to know... :p

New major issue: I cannot seem to get 4:2:0 into madVR now. Upsampling is being applied before the video gets into it.
Actually, the only problem is that "Nearest Neighbor" is broken. If you select "Nearest Neighbor", madVR accidently uses "Bilinear". Other than that there's nothing wrong.

Lumagen boxes do. (or at least did, when I was beta-testing the Radiance)
They do color correction in linear light. But they do not *scale* in linear light, AFAIK.

8-bit showed no movement, but 7-bit helped mask the edges a bit.
In that case I'd recommend staying with 8bit.

I had a few bugs disappear since i upgraded to 0.62. They were not in the changelog thou. Am I correct in assuming that not every optimization and bugfix to existing feateres is in the changelog but only actual changes like new feateres and options?
Important bugfixes are listed in the changelog, too. There might be a couple small bugfixes which I don't list in the changelog. Also, some things might be fixed "accidentally". Anyway, if a problem is gone for you, there's really no reason to wonder why... :)

Also are there any optimizations I can make to the new display properties settings in madvr? I do not know the calibration or bitdepth of my tv thou I have looked throu any documentation I could find.
Just stick to the defaults if you don't know.

But now, I can clearly say that I'm totally lost with all these options (no problem if it helps others). I'll stay with default settings.
Yes, staying with the default settings is a good idea if you don't understand the new options. Maybe I should introduce an "expert" mode and hide some of these settings there.

Why don't you correct the bug on the other side? :cool:
Because a day has only 24 hours. And because adding 10bit output is not at the top of my priority list.

Properties
primaries/gamut - Since it's very rare for any display without a hardware lut to have a perfect gamut, what should this be set to? To maintain accuracy without a 3dlut should I pick the closest option or 'Something Else'? What does madVR do (not do?) when 'Something Else' is selected? Does this setting do anything when using a 3DLUT?
If you use a 3dlut, the primaries/gamut setting on the "Properties" page has no effect. As I mentioned before, I plan to make gray out this option in the next madVR version, if you activate a 3dlut.

If you do not use a 3dlut, you should set this option to the closest match. The value "Something Else" means that madVR disables gamut correction, if no 3dlut is used.

gamma/transfer - I calibrate my gamma to an ambient light scaled REC.709 curve with Argyll CMS, and as I've learned this doesn't match how yCMS or Janos666's MPC-HC-mod calculates it, so I doubt it matched madVR shaders either... To maintain accuracy without a 3dlut should I pick the closest option or 'Something Else'? What does madVR do (not do?) when 'Something Else' is selected? Does this setting do anything when using a 3DLUT?
Same as with "primaries/gamut". Setting this to "Something Else" means that madVR treats your display as having the default Pure power curve of 2.2, though. This has no meaning, though, unless you modify the "Color & Gamma" settings.

Calibration & Color & Gamma
Color & Gamma appears to be some sort of Output Gamma setting? So if you are doing gamma correction in a 3dlut with something like grayscale measurements & gamma_curve, or don't want any gamma correction at all, madVR is forcing you to change it? I don't want anything to touch the gamma I may or may not have specified in a 3dlut, so this is a major problem for me.
If you keep all options to the default values madVR will not touch the gamma at all. That's the default behaviour. If you enable yCMS calibration (or use an external 3dlut file), madVR will still not touch the gamma at all, if you keep using the default settings on the "properties" and "color & gamma" pages.

Bug: The Color & Gamma section should not be used by default when using a 3dlut. Gamma corrections should be done with the 3dlut (if needed) when one is used. Currently madVR uses shaders on-top for the 3dlut. An 'Native' gamma option is needed to disable madVR's gamma modifications when using a 3dlut.
Let's say you want to use a 2.35 gamma for night time watching and a 2.2 gamma if there's some ambient light. How can you do that? With older madVR versions you had to create and then switch between different 3dlut files for that to work. Now with madVR v0.62 you create only one 3dlut file and you can do gamma adjustments on the fly. And you can do this with the same (or even better) quality than before.

The one standard 3dlut file created by madVR v0.62 defaults to a "Gamma_Curve" of a 2.2 pure power curve, which is also the default setting in the "color & gamma" settings page. If you want to achieve a different gamma curve, you can realize that by changing the "color & gamma" settings. Having the "color & gamma" settings set to the default values means that madVR is not doing any gamma processing at all.

Or in other words: v0.62 uses the 3dlut only to correct display faults. It does not use the 3dlut, anymore, to achieve specific gamma curves / values. So basically the yCMS command "Gamma_Curve" is what you can configure now in the "color & gamut" madVR settings page. This is done via shader math now, though. The purpose of this change is higher usability, because you only need one 3dlut, anymore, and you can switch "Gamma_Curve" on the fly, without delay.

Bug: When 'using yCMS' is selected, clicking edit in the yCMS tab doesn't load the template from the Color & Gamma sections. Same issue in both sections with the grayscale edit button.
The real bug is that the yCMS tab is visible sometimes when it should not be. It should only be visible if you've selected the "calibration" tab. The yCMS tab should not be visible in any other case.

Related question: Does madVR only accept yCMS settings separated by commas or can spaces be used like a normal yCMS config file?
If you edit it manually, you have to use commas. However, you can copy & paste the full "Gamma_Measurements" and "Grayscale_Measurements" sections from your 3dlut script to the madVR settings gamut/gamma sections and madVR will accept them as they are (with spaces). But for that to work, the "xxx_Measurements" header must be part of the copy & pasted text.

Bug: madVR shouldn't be creating 3dluts with Output_Transfer_Function set (currently always set to 1.0 0.0 0.45454545454545454545454545454545 0.0) since you are using yCMS presets. Do you have a reason for doing this? Will madVR misbehave is fed a 3dlut using the yCMS defaults for yRGB (no Output_Transfer_Function specified)?
I wasn't sure which output transfer function yCMS was using for yRGB, so I defined it, just to be safe. Since then yesgrey confirmed that the default yRGB output transfer function matches the one I manually defined. So I can remove that, but it won't make any practical difference.

Bug: madVR sets both input and output levels to RGB_Video (16-235) instead of RGB_PC (0-255). This will cause full-range videos to get clipped.
Are you sure? If that's true, I consider it a bug in yCMS. yCMS should not clip BTB/WTW, so it should also not clip full-range videos. That said, full-range videos are extremely rare.

Feature Request: Option to have madVR create a 3DLUT with an external yCMS config file and set the lut as the external 3DLUT after creation.
What extra options in the yCMS config file do you need? I think most users won't need this. So those few who do can create the 3dlut manually and use the "use external" option in madVR.

Hopefully you add an option to disable all these forced gamma corrections in madVR 0.63.
As explained above, with the default settings there is no forced gamma correction at all.

You've made things overly complex for something which should be very simple. I would like to see input settings grouped with their corresponding output settings, with an option to disable all this forced behavior and use defaults with identical behavior (taking yRGB into account) to versions prior to 0.62.
The problem is that there are various situations users can be in:

(1) They might have a meter and want to use yCMS.
(2) They might have a meter and use a different 3dlut creator.
(3) They might have no meter, but have their displays calibrated by an ISF calibrator to e.g. BT.709.
(4) They might have a display which is known to be mostly BT.709 calibrated out of the box.
(5) They might have a display with an unknown calibration.

I need to support all of that. And I want to offer all of these users the option to use both gamut correction (so both DVDs and Blu-Rays are shown with correct colors) and gamma adjustments (to match the ambient light level, or to match movies with a weird encoding).

If I would only have to take care of one of those 5 groups mentioned above, the settings dialog would be easier. But I don't really feel like creating 5 different versions of the settings dialog, either. So I have to find a solution which works for everyone. Of course it's going to be somewhat complicated. So help me optimize it. I'm open for suggestions.

My logic behind all this is that there are some settings which should be setup once and then never touched again ("properties" and "calibration") and there are other settings which users may want to tweak depending on ambient light level or movie ("color & gamma"). I think these settings should be separated into different tabs. Because of that I cannot put "input and output settings" into one tab, as you suggest.

[madshi]

I tried again with 0.62 and it still happens. When I leave only 1080i59, then it simply doesn't switch to anything for 59/60p content (tried from 23p and 50p). Happens both with LAV splitter and the MPC internal splitter.
Can I have a log, please?

My card can do 59i, it does work OK for 29/30p or 59/60i content, just not for 59/60p. Also, 59i is my default setting so my PC is more often than not at that rate (named 29i or 30i in CCC).
Maybe things are going wrong because of "59i" vs "29i". It's really the same thing, but maybe there's a misunderstanding between madVR and Windows because of that.

[Andy o]

I'll get you a log in a few mins. I'm not sure I explained myself very clearly so just to clear it up, madVR does change to 1080i59 when using 29/30p or 59/60i. So, madVR can tell Windows to switch just fine, it just doesn't seem to know to do it when getting 59/60p. And for some reason it switches to 24p if the 1080p24 option is also set.

[Andy o]

OK here's the log. My refresh rate was at 50Hz, and when playing that interframe 60p sample, it switched to 1080p24, instead of 1080i59.

http://www.filesonic.com/file/1141558744/madVR_-_log_50to24.zip

[madshi]

Wow, this is really a logic error in madVR, will fix that for the next build.

[Andy o]

Thanks.

[madshi]

Don't understand, though, why madVR does not switch to 1080i59 for you, if that's the *only* mode you're listing in the madVR option. That *must* work. Can you really reproduce that? If so, please create a log for that situation, too. Thx.

[STaRGaZeR]

Is it intended that all the options under devices->Mymonitor (display calibration, gamma, levels, etc.) affect RGB32 video as they do now? If so, what's the reason behind this behaviour? What should I do to get untouched RGB32 output?

BTW, congrats on finally making your renderer a video renderer, instead of a YV12 renderer ;)

[Andy o]

OK, here's the log for that situation. madVR just doesn't switch.

http://www.filesonic.com/file/1141895304/madVR_-_log.zip

BTW, it's not a huge problem personally cause I don't have a lot of 60p content.

Also, since you're tweaking the logic, is it possible for madVR, if 1080i59/60 and 1080p59/60 both are present, to switch 59i/60i content to 1080i instead of 1080p? My display will only apply auto IVTC up to 1080i.

[6233638]

Actually, the only problem is that "Nearest Neighbor" is broken. If you select "Nearest Neighbor", madVR accidently uses "Bilinear". Other than that there's nothing wrong.Thanks, when looking back on those images, I wondered if that might have been what was going on. (as it was happening to luma too)

It does make me want to wait until this is fixed, to verify that the Cyberlink DVD Decoder is still sending YV12/NV12 before spending a lot of time on it. (neither ffdshow nor LAV CUVID/splitter work with DVD)

[SamuriHL]

Yes. Furthermore: This is just with the standard resamplers. Image quality should further improve when I implement some better quality upsamplers. (Not too soon, though.)


That would be really nice. I'm at the beginning of a project that will likely take me all summer to complete. We ran out of shelf space in my living room, so, I took most of my DVD's and boxed them up. The plan is to get a couple external hard drives over the summer and rip all my DVD's to it. Probably as MKV's so I can use madVR. Upscaling is very important to me. That's why I'm so excited by what we're seeing already.


Oh, this does look like a madVR problem, not an MC problem. Is this 100% reproducible?


On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.

[yesgrey]

Are you sure? If that's true, I consider it a bug in yCMS. yCMS should not clip BTB/WTW, so it should also not clip full-range videos.
Since v1.6 yCMS is not clipping BTB/WTW anymore.

[madshi]

OK, here's the log for that situation. madVR just doesn't switch.

http://www.filesonic.com/file/1141895304/madVR_-_log.zip

BTW, it's not a huge problem personally cause I don't have a lot of 60p content.
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?

Also, since you're tweaking the logic, is it possible for madVR, if 1080i59/60 and 1080p59/60 both are present, to switch 59i/60i content to 1080i instead of 1080p? My display will only apply auto IVTC up to 1080i.
Hmmmm... That might be difficult, not sure. Will have to check if I can detect that the source is interlaced.

It does make me want to wait until this is fixed, to verify that the Cyberlink DVD Decoder is still sending YV12/NV12 before spending a lot of time on it. (neither ffdshow nor LAV CUVID/splitter work with DVD)
When using MPC-HC, you can check the connection format in the filter properties. But of course you can also wait...

On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.
Can you try cutting this file down to a very small sample? If the crash still occurs with the small sample, it might help me reproduce & fix the problem.

[noee]

On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.

I've been trying to get a log, but when I turn logging on in MC, it never fails....I think with MC logging on and the madVR debug, we should get something usable.

[madshi]

Is it intended that all the options under devices->Mymonitor (display calibration, gamma, levels, etc.) affect RGB32 video as they do now? If so, what's the reason behind this behaviour?
You seem to consider RGB32 video as "the truth" which must not be touched, anymore. That's not really correct, though. It is intentional (and IMHO absolutely correct) that madVR applies all of its calibration processing on RGB32 input, too. Why should it not do that? Do you have a scientific reasoning for that?

What should I do to get untouched RGB32 output?
Use the default settings, but change the "gamut / primaries" setting on the display "properties" page to "something else". That will make madVR not touch the RGB32 output. IMHO doing that is not correct, though. You will not get correct colors this way if you e.g. play SD video on your HD display.

[madshi]

I've been trying to get a log, but when I turn logging on in MC, it never fails....I think with MC logging on and the madVR debug, we should get something usable.
Unfortunately for crashes the madVR debug log usually doesn't help much (though if we're extremely lucky maybe this is an exception, you never know). Much better would be for me to get a sample with which the crash is 100% reproducable.

[janos666]

If I tell madVR that these are my supported display modes: 1080p23, 1080p24, 1080p25, 1080p29, 1080p30, 1080p50, 1080p59, 1080p60, 1080i29, 1080i59 then it switches to 1080p29 for 1080i30 BD materials (it could be correct if there would be a deinterlace filter in the graph which produces 29.97 progressive frames). And the result is very bad as madVR doesn't really deinterlace anything (yes, I know that it's not a bug but a missing feature with very low or zero priority witch I understand...)

If I disable auto-switching and manually set 1080i30Hz from the AMD CCC (which is interlaced 60.00Hz according to the madVR OSD) then the TV seems to understand it and correctly deinterlace it. Well, at least for a few seconds until something looses the sync and the video starts to jag like hell. It gets back to work if I pause the playback for some seconds.

So I tried to fill my display modes line with this: 1080i29, 1080i59 and madVR now switches to interlaced 59.941Hz (said by madVR OSD) for 1080i30 materials (29.970fps according to the source filter). And the TV still understand it and apply deinterlace. But it didn't solve the sync problem, it still starts to jag after a few seconds.

I am not sure if it's madVR or the TV which looses the sync but I guess it's madVR (why the pause/play cycle would help the TV? and the TV streams from coax work well...).

I am using the D3DFS mode and I tried to tick the DX11 presentation and a very strange thing happened: madVR switches to interlaced 50.00Hz now (for the same 1080i30 material).
So, I removed anything but 1080i59 from madVR's list and it still switches to interlaced 50Hz (and the same thing happens if I keep 1080i29 only)!

[SamuriHL]

Can you try cutting this file down to a very small sample? If the crash still occurs with the small sample, it might help me reproduce & fix the problem.

Yea, it might take a little bit. I've got some video editing to do on that machine. I'll try to get you a sample later today. Knowing my luck, cutting the file down will fix it and not repro it.

[nevcairiel]

Hmmmm... That might be difficult, not sure. Will have to check if I can detect that the source is interlaced.

If all you do is check media types, then that information is sadly not present. There are the "dwInterlaceFlags" in VIH2, however many decoders always set them even on progressive content, and set the actual type of the frames on the sample properties.

[cyberbeing]

If you use a 3dlut, the primaries/gamut setting on the "Properties" page has no effect. As I mentioned before, I plan to make gray out this option in the next madVR version, if you activate a 3dlut. If you do not use a 3dlut, you should set this option to the closest match. The value "Something Else" means that madVR disables gamut correction, if no 3dlut is used. Same as with "primaries/gamut".
In that case, you should consider changing "Something Else" to something less ambiguous.
Edit: As I noted below, it may be nice to have a "Custom" option which you could specify arbitrary values as well.

Setting this to "Something Else" means that madVR treats your display as having the default Pure power curve of 2.2, though. This has no meaning, though, unless you modify the "Color & Gamma" settings. If you keep all options to the default values madVR will not touch the gamma at all. That's the default behaviour. If you enable yCMS calibration (or use an external 3dlut file), madVR will still not touch the gamma at all, if you keep using the default settings on the "properties" and "color & gamma" pages.

As explained above, with the default settings there is no forced gamma correction at all.

Thanks for the confirmation that Pure-power 2.2 means gamma isn't touched. I initially changed things since they weren't the correct values for my display.
If "Something Else" means disabled in the properties page, could you add a "Something Else" to the Color & Gamma page as well. That would be less confusing (when you plan to set input=output), even if it does nothing different than setting Pure-power 2.2 there.

Just to confirm, the following both imply gamma correction is disabled and will have identical behavior?
Properties (pure-power 2.2) -> Color & Gamma (pure-power 2.2)
Properties (something else) -> Color & Gamma (pure-power 2.2)

Properties (inverse 2.2) -> Color & Gamma (inverse 2.2)
Properties (pure-power 2.35) -> Color & Gamma (pure-power 2.35)
Edit: Does madVR assume the 3dlut is a 2.2 power-curve, meaning these last two will do something? Would this have different behavior with shaders-only vs using a 3dlut?

Edit2: Thinking about this a bit, it may make sense to link changes to the Property page gamma to the Color & Gamma page. In other words, default to input=output gamma when a change is made to the Property page. At which point if someone wanted to apply a gamma adjustment, they could make the necessary change in the Color & Gamma page.

Let's say you want to use a 2.35 gamma for night time watching and a 2.2 gamma if there's some ambient light. How can you do that? With older madVR versions you had to create and then switch between different 3dlut files for that to work. Now with madVR v0.62 you create only one 3dlut file and you can do gamma adjustments on the fly. And you can do this with the same (or even better) quality than before.
I don't mind having the additional functionality available, but currently I have no use for it. When I'm not using something I want it obvious that it is indeed disabled and doing nothing. I'd still like to see a check-box by certain settings to disable and gray them out to be more intuitive than guessing the madVR defaults.

The one standard 3dlut file created by madVR v0.62 defaults to a "Gamma_Curve" of a 2.2 pure power curve, which is also the default setting in the "color & gamma" settings page. If you want to achieve a different gamma curve, you can realize that by changing the "color & gamma" settings. Having the "color & gamma" settings set to the default values means that madVR is not doing any gamma processing at all.

Or in other words: v0.62 uses the 3dlut only to correct display faults. It does not use the 3dlut, anymore, to achieve specific gamma curves / values. So basically the yCMS command "Gamma_Curve" is what you can configure now in the "color & gamut" madVR settings page. This is done via shader math now, though. The purpose of this change is higher usability, because you only need one 3dlut, anymore, and you can switch "Gamma_Curve" on the fly, without delay.
I realize what you are doing and why you set things up this way, but I don't like getting forced into using shader vs 3dlut for gamma correction. If for example a 3dlut is set with special Input_Transfer_Functions, Output_Transfer_Functions, Gamma_Curve, or even non-yRGB with YUV->RGB conversion, madVR should use it and bypass any shader code which duplicates functionality. It shouldn't be hard for madVR to parse the settings in the first few bytes of an externally loaded 3dlut and adapt accordingly. I like having the flexibility have a 3dlut which can be used anywhere and does all the corrections I need.


The real bug is that the yCMS tab is visible sometimes when it should not be. It should only be visible if you've selected the "calibration" tab. The yCMS tab should not be visible in any other case.
I've see both the yCMS and the Calibration tab show up on the Color & Gamma page, so don't forget to fix both.

If you edit it manually, you have to use commas. However, you can copy & paste the full "Gamma_Measurements" and "Grayscale_Measurements" sections from your 3dlut script to the madVR settings gamut/gamma sections and madVR will accept them as they are (with spaces). But for that to work, the "xxx_Measurements" header must be part of the copy & pasted text.
There is still a bug that clicking edit doesn't load a template for Grayscale_Measurments and forces you to manually edit.

I wasn't sure which output transfer function yCMS was using for yRGB, so I defined it, just to be safe. Since then yesgrey confirmed that the default yRGB output transfer function matches the one I manually defined. So I can remove that, but it won't make any practical difference.
I noticed you always used the same value when creating a 3dlut, so I assumed you were overriding something (which is the purpose of specifying that value). Does this mean yCMS uses also uses a 2.2 power-curve as the input_transfer_function in the preset as well? I'm not familiar with the intricacy of the changes yesgrey made for yRGB, but I assume the presets still default to using the same input & output transfer functions? Can you confirm?

Are you sure? If that's true, I consider it a bug in yCMS. yCMS should not clip BTB/WTW, so it should also not clip full-range videos. That said, full-range videos are extremely rare.
Unless yCMS ignores that value with yRGB (you'll need to ask yesgrey) or YUV->RGB has completely different behavior than RGB->RGB it is true. I'm not very familiar with yCMS RGB->RGB behavior, so you'll need confirm with yesgrey.

I see it as a bug as well, but yesgrey doesn't. He purposefully clips input to limited-range in his presets since fullrange videos are rare. You needed to explicitly specify input is full-range when creating a 3dlut. With the previous YUV->RGB 3dluts, you needed three different ones to support all types of videos.

YUV (16-235 clipped) -> RGB (0-255)
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16

YUV (16-235 clipped) -> RGB (16-235)
Input_Format HD YCbCr 8
Output_Format HD RGB_Video 16

YUV (0-255) -> RGB (0-255)
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16


What extra options in the yCMS config file do you need? I think most users won't need this. So those few who do can create the 3dlut manually and use the "use external" option in madVR.
I'm asking that madVR can be used to create that manual 3dlut file with an external yCMS config so I don't need to mess with the command prompt of batch files. This should be very simple for you to support. Pass the yCMS config file as-is to yCMS, just make the filename for the 3dlut the same as the config file, and let yCMS do its thing, creating the 3dlut and placing it in the madVR directory.

The problem still remains that you can create a 3dlut which conflicts with the madVR shaders. If a user is used to creating a 3dlut manually and doesn't realize this, they could make similar assumptions as I did, causing madVR to apply gamma corrections both with the 3dlut and shaders. Optimally madVR should support 3dlut only, shaders only, and 3dlut + shaders. Maybe adding a drop-down menu to pick your desired mode would be the best solution.


The problem is that there are various situations users can be in:

(1) They might have a meter and want to use yCMS.
(2) They might have a meter and use a different 3dlut creator.
(3) They might have no meter, but have their displays calibrated by an ISF calibrator to e.g. BT.709.
(4) They might have a display which is known to be mostly BT.709 calibrated out of the box.
(5) They might have a display with an unknown calibration.

I need to support all of that. And I want to offer all of these users the option to use both gamut correction (so both DVDs and Blu-Rays are shown with correct colors) and gamma adjustments (to match the ambient light level, or to match movies with a weird encoding).

If I would only have to take care of one of those 5 groups mentioned above, the settings dialog would be easier. But I don't really feel like creating 5 different versions of the settings dialog, either. So I have to find a solution which works for everyone. Of course it's going to be somewhat complicated. So help me optimize it. I'm open for suggestions.
Make a 'First-run Wizard' type of thing which asks simple questions about your needs and guides you through all the scenarios listed above, step-by-step, in a very simple way.

Supporting all these things is all well and good, but it should be more obvious how to make madVR meet your needs, especially for someone unfamiliar with such things and aren't very tech-savvy.

That gamma itself is relative could lead to trouble for users. Unless you are fully aware of the properties of your display and set everything correctly, the output gamma specified in madVR would never match the output gamma you actually see. A common example is if a display has a flawed power-curve gamma or an arbitrary gamma which doesn't match the scaling of the Rec709/601 shader logic. Changing gamma with in such cases will cause undesired behavior, since madVR would be making inaccurate assumptions about the properties of the display.

On another note, if you can now do Rec709/Rec601/PAL gamut adjustments in madVR, how difficult would it be to add custom gamut measurements to by applied by shaders? That would allow someone with a meter to take advantage of this new shader functionality more accurately, when not using a 3dlut. I imagine it would be trivial to support if you already have the framework in place.

My logic behind all this is that there are some settings which should be setup once and then never touched again ("properties" and "calibration") and there are other settings which users may want to tweak depending on ambient light level or movie ("color & gamma"). I think these settings should be separated into different tabs. Because of that I cannot put "input and output settings" into one tab, as you suggest.
Since you don't want to group them, can you label the Properties page as Input somewhere and the Color & Gamma page as Output somewhere? If that was there in the first place, I wouldn't have needed to ask some of these question and play with setting to trying to figure out what they do. My first impression was the Color & Gamma page was a yCMS setting, but this turned out not to be the case. Maybe pages should specify they are Shader Operations and yCMS 3dlut Operations as well (add color-coding, heh)...

[madshi]

If I tell madVR that these are my supported display modes: 1080p23, 1080p24, 1080p25, 1080p29, 1080p30, 1080p50, 1080p59, 1080p60, 1080i29, 1080i59 then it switches to 1080p29 for 1080i30 BD materials (it could be correct if there would be a deinterlace filter in the graph which produces 29.97 progressive frames). And the result is very bad as madVR doesn't really deinterlace anything (yes, I know that it's not a bug but a missing feature with very low or zero priority witch I understand...)

If I disable auto-switching and manually set 1080i30Hz from the AMD CCC (which is interlaced 60.00Hz according to the madVR OSD) then the TV seems to understand it and correctly deinterlace it. Well, at least for a few seconds until something looses the sync and the video starts to jag like hell. It gets back to work if I pause the playback for some seconds.

So I tried to fill my display modes line with this: 1080i29, 1080i59 and madVR now switches to interlaced 59.941Hz (said by madVR OSD) for 1080i30 materials (29.970fps according to the source filter). And the TV still understand it and apply deinterlace. But it didn't solve the sync problem, it still starts to jag after a few seconds.
Not sure where the sync problem comes from. Can I have a log from the "1080i29, 1080i59" situation where madVR switches to interlaced 59.941, please?

I am using the D3DFS mode and I tried to tick the DX11 presentation and a very strange thing happened: madVR switches to interlaced 50.00Hz now (for the same 1080i30 material).
Can I have a log from that, too?

[janos666]

I filled the modes line with this: 1080p23, 1080i50, 1080i59 (It covers all my need after all...)
BD with 1080p24 works (of course, they always worked from the bigging of the auto-switch)
HDTV streamrip with 1080i25 works without any deinterlace or sync problems (well, I let it run for a minute)
BD with 1080i30 works for a few seconds

Ok, I will try to capture a log.

[yesgrey]

Some possible bugs:
-after activating and selecting the external 3DLUT file for one of the displays, when activating the external 3DLUT file for the other it by defaults uses the same file from the other display. IMHO it should appear blank.
-In the calibration->yCMS tab the grayscale measurements edit button is disabled. It only is enabled after filling up the gamut measurements. I think both should be enabled.
-The Gamut_Measurements are not being accepted through copy/paste. The save button keeps disabled.

[janos666]

I used these settings: 1080p23, 1080i50, 1080i59 and the situation is the same with DX11: 1080i30_madvr_log.rar (http://www.mediafire.com/?k45u6y2eye6qi1h)

[madshi]

If all you do is check media types, then that information is sadly not present. There are the "dwInterlaceFlags" in VIH2, however many decoders always set them even on progressive content, and set the actual type of the frames on the sample properties.
Sample properties? Do you mean IMediaSample::GetMediaType()? Or do you mean IMediaSample2::GetProperties? Thx.

Just to confirm, the following both imply gamma correction is disabled and will have identical behavior?
Properties (pure-power 2.2) -> Color & Gamma (pure-power 2.2)
Properties (something else) -> Color & Gamma (pure-power 2.2)
Yes.

Properties (inverse 2.2) -> Color & Gamma (inverse 2.2)
Properties (pure-power 2.35) -> Color & Gamma (pure-power 2.35)
Inverse? You mean the BT.709 curve type? Anyway, if you set the Properties and Color & Gamma options to the same values, madVR will not do any gamma changes - if you don't use a 3dlut. If you do use a 3dlut:

Edit: Does madVR assume the 3dlut is a 2.2 power-curve, meaning these last two will do something?
If you do have a 3dlut madVR will assume it produces a pure-power curve of 2.2, because that's how madVR creates its own 3dluts. Which means, if you're using a 3dlut you need to set the Color & Gamma option to pure power 2.2 to have no processing.

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.

I realize what you are doing and why you set things up this way, but I don't like getting forced into using shader vs 3dlut for gamma correction. If for example a 3dlut is set with special Input_Transfer_Functions, Output_Transfer_Functions, Gamma_Curve, or even non-yRGB with YUV->RGB conversion, madVR should use it and bypass any shader code which duplicates functionality.
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.

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.

There is still a bug that clicking edit doesn't load a template for Grayscale_Measurments and forces you to manually edit.
Please recheck that with the next build. It works fine here. Might be fixed together with the other bugfixes.

I noticed you always used the same value when creating a 3dlut, so I assumed you were overriding something (which is the purpose of specifying that value). Does this mean yCMS uses also uses a 2.2 power-curve as the input_transfer_function in the preset as well? I'm not familiar with the intricacy of the changes yesgrey made for yRGB, but I assume the presets still default to using the same input & output transfer functions? Can you confirm?
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.

Unless yCMS ignores that value with yRGB (you'll need to ask yesgrey) or YUV->RGB has completely different behavior than RGB->RGB it is true. I'm not very familiar with yCMS RGB->RGB behavior, so you'll need confirm with yesgrey.
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.

I'm asking that madVR can be used to create that manual 3dlut file with an external yCMS config so I don't need to mess with the command prompt of batch files. This should be very simple for you to support. Pass the yCMS config file as-is to yCMS, just make the filename for the 3dlut the same as the config file, and let yCMS do its thing, creating the 3dlut and placing it in the madVR directory.
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.

Make a 'First-run Wizard' type of thing which asks simple questions about your needs and guides you through all the scenarios listed above, step-by-step, in a very simple way.
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.

That gamma itself is relative could lead to trouble for users. Unless you are fully aware of the properties of your display and set everything correctly, the output gamma specified in madVR would never match the output gamma you actually see. A common example is if a display has a flawed power-curve gamma or an arbitrary gamma which doesn't match the scaling of the Rec709/601 shader logic. Changing gamma with in such cases will cause undesired behavior, since madVR would be making inaccurate assumptions about the properties of the display.
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.

On another note, if you can now do Rec709/Rec601/PAL gamut adjustments in madVR, how difficult would it be to add custom gamut measurements to by applied by shaders? That would allow someone with a meter to take advantage of this new shader functionality more accurately, when not using a 3dlut. I imagine it would be trivial to support if you already have the framework in place.
If that someone does have a meter, why is he not using yCMS?

Since you don't want to group them, can you label the Properties page as Input somewhere and the Color & Gamma page as Output somewhere? If that was there in the first place, I wouldn't have needed to ask some of these question and play with setting to trying to figure out what they do. My first impression was the Color & Gamma page was a yCMS setting, but this turned out not to be the case. Maybe pages should specify they are Shader Operations and yCMS 3dlut Operations as well (heh)...
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.

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".

-after activating and selecting the external 3DLUT file for one of the displays, when activating the external 3DLUT file for the other it by defaults uses the same file from the other display. IMHO it should appear blank.
Agreed. Will check that.

-In the calibration->yCMS tab the grayscale measurements edit button is disabled. It only is enabled after filling up the gamut measurements. I think both should be enabled.
Are there people who provide grayscale measurements but not gamut measurements? What would be the purpose of that?

-The Gamut_Measurements are not being accepted through copy/paste. The save button keeps disabled.
Works for me. Can you post the exact text you've copy/pasted here for me to test with?

[madshi]

I used these settings: 1080p23, 1080i50, 1080i59 and the situation is the same with DX11: 1080i30_madvr_log.rar (http://www.mediafire.com/?k45u6y2eye6qi1h)
Thanks, another bug located.

[nevcairiel]

Sample properties? Do you mean IMediaSample::GetMediaType()? Or do you mean IMediaSample2::GetProperties? Thx.

IMS2::GetProperties

[STaRGaZeR]

You seem to consider RGB32 video as "the truth" which must not be touched, anymore. That's not really correct, though. It is intentional (and IMHO absolutely correct) that madVR applies all of its calibration processing on RGB32 input, too. Why should it not do that? Do you have a scientific reasoning for that?

First, let me say I have absolutely no background in video renderers and D3D stuff in the sense that I don't know what happens once I feed the renderer with a frame.

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. Processing in madVR is a bad idea, because it'll redo everything, messing up colors, levels, gamma, etc. as it does right now.

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.

RGB32 is a format that is intended to be displayed as-is, unless video renderers do something to the image that I'm not aware of before displaying it. Yet again, RGB32(ffdshow)->EVR and YV12->madVR look the same here (not counting the difference in processing quality of course) in both SD and HD. So I really think your processing should be disabled for RGB32/24, or at least you should offer an option to do so.

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.

Use the default settings, but change the "gamut / primaries" setting on the display "properties" page to "something else". That will make madVR not touch the RGB32 output. IMHO doing that is not correct, though. You will not get correct colors this way if you e.g. play SD video on your HD display.

I do get proper colors playing SD and HD videos if the RGB32 frames are untouched, as in EVR, as explained above.

[smsmasters]

I have a Core i5 + GT 420M laptop and MPC-HC crashes when switching to full screen exclusive mode, as if it can't keep up with buffering.

[groen]

madVR works great, not sure if already mentioned. But a few feature requests.

1) an option to disable reinit on display, this way i can drag between dual monitors without it glitching.
2) an option to set the amount of seconds that it goes in to exclusive mode, from four to any number.
3) dxva support, but only if the seek remains as good as it is now.
4) volume control to go with the cool seekbar.

[madshi]

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.

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.

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.

RGB32 is a format that is intended to be displayed as-is
Not true at all.

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.

[yesgrey]

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.

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 (http://ShareText.org/AHS2).

[groen]

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.

[madshi]

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.

It's too big to fit in a post. Grab it here (http://ShareText.org/AHS2).
Ah, the problem was that the Memo control didn't have a horizontal scrollbar. That resulted in unexpected line breaks, which confused by parser.

[cyberbeing]

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.

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.

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.

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.

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 :eek:
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.

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. ;)

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)


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.

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.

[madshi]

madVR v0.63 released

http://madshi.net/madVR.zip

* 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

[Andy o]

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/1144622104/madVR_-_log.zip

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]

oops beat me by a few mins, I'll try with 0.63.

[madshi]

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?

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.

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?

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.

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?

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.

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

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?

[e-t172]

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 (http://forum.doom9.org/showpost.php?p=1505475&postcount=13623). No promises.

[Andy o]

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]

Well, you could try my half-finished filter (http://forum.doom9.org/showpost.php?p=1505475&postcount=13623). No promises.

thanks, I'll try that when I have this other thing sorted out.

[STaRGaZeR]

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?


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.

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.

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!

[yesgrey]

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. ;)

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.

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.;)

@yesgrey, any comments?
See above.

[Andy o]

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

[nevcairiel]

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.

[yesgrey]

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? ;)

[Andy o]

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.

[cyberbeing]

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.

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.

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.


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.


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.


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.


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?

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.

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.

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.

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).

[STaRGaZeR]

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 :D

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.