[madshi]

Originally Posted by nevcairiel

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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:

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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?

Originally Posted by cyberbeing

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

Originally Posted by yesgrey

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

Originally Posted by yesgrey

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

Originally Posted by yesgrey

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