[cyberbeing]

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

Sure. Can you please ask God to extend my days to 48hours each? Seriously, wizards are nice and might come at some time. But there are so many other things I need to do which are more important.

48 hour days
How about adding tool-tips to settings with brief descriptions of their purpose? That should only take only a few minutes (vs hours to build a Wizard), and would likely be helpful to new users. If it is too much work to simplify settings, they need to be clearly explained. As things currently stand, the setting in 0.62 aren't very intuitive, which has made usability go from bad->worse for new users. I'm sure you would gain back all the time spent implementing usability improvements, since people could figure things out for themselves and ask less questions.

Originally Posted by madshi

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.

Originally Posted by madshi

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)

Originally Posted by madshi

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.

Originally Posted by madshi

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.