[cyberbeing]

Originally Posted by madshi

madVR:
(1) input = 8bit Y'CbCr, 709 primaries, 709 gamma
(2) convert -> 32bit float R'G'B', 709 primaries, 709 gamma
(3) convert -> 32bit float RGB, 709 primaries, linear light
(4) convert -> 32bit float RGB, yRGB primaries, linear light
(5) convert -> 32bit float R'G'B', yRGB primaries, pure power 2.2 gamma
3dlut:
(6) input = 8bit float R'G'B', yRGB primaries, pure power 2.2 gamma (with trilinear interpolation)
(7) convert -> 64bit float RGB, yRGB primaries, linear light
(8) convert -> 64bit float RGB, display primaries, linear light
(9) convert -> 16bit int R'G'B', display primaries, display corrected gamma
madVR:
(10) input = 16bit int R'G'B', display primaries, display corrected gamma
(11) dither down to 8bit R'G'B', display primaries, display corrected gamma

Where in this chain do you see any reason for problems? The steps (5) and (7) are exactly the opposite of each other, so they equal each other out.

The problem wouldn't (5) or (7), it would potentially be (9). What does 'display corrected gamma' default to with gamma correction disabled? In the above example it should be 709 gamma, so there is no change from (1). Converting to anything else other than (1) in step (9) would result in a change of gamma.

Originally Posted by madshi

IIRC at that time janos666 did that because it produced better results with test patterns. In the meanwhile yesgrey has made this the default yCMS behaviour. So the special tweak used by janos666 is no longer necessary. At least that's IIRC.

Seeing the more detailed workflow you posted, it appears (2) became the functional replacement of 3dlut input_transfer_function in prior versions. In which case it would be (2), the curve you initially choose the linearize the video with, which would need to be tweak-able. The janos666 'special-tweak' would be setting (2) to your display gamma. I personally never did this, so I like it as you currently have it.

Originally Posted by madshi

There's already one other CMS software supporting 3dlut creation for madVR. The author of that software has already confirmed that he'll add support for yRGB and madVR v0.62+.

Interesting. Which software is this? Do you have a link?

Originally Posted by madshi

And I still don't see any practical situation where v0.62+ limits your 3dlut usage. Can you give me a practical example?

I don't doubt there is a practical example, but I would have to think of a use-case, since it's nothing I'm using currently. I just have a feeling that if you don't re-add support for the previous four 3dlut 'dumb' functionality soon to complement the new yRGB+Shaders, we will be stuck this way, even if a need arises in the future.

The non-practical example would be if you wanted to manipulate the video in a non-standard way. You could look at how the film industry uses 3dluts during post-processing to give you an idea of the possibilities. In version 0.61 you could feed madVR such a 3dlut and it would get processed correctly. In 0.62+ you are forced to make 3dluts which are practical for common playback needs.

I suspect you rightfully see this as a non-issue, but the ways a 3dlut can be used in 0.62+ are more limited.

Originally Posted by madshi

madVR doesn't deal with it at all at the moment. madVR strictly expects all input content to be "video levels".

Just to confirm, this applies to RGB input as well? You should probably make a note of this in the Readme.txt or something.

Originally Posted by madshi

Yes, that's an approach I like.

Well I finally got around to testing today. I can't get 0.61 to match 0.65 when using a 8 bit 3dlut. It appears other people are having issues as well, but I unfortunately see no improvement from madVRprecision1, madVRprecision2, or madVRprecision3.

Gamut_Measurements 2
44.879 24.456 2.3025
31.815 65.848 10.537
18.241 9.5207 95.101
95.1206 99.9977 108.75

After doing some measurements, it appears to be a bug in how madVR is adapting the RED primary to yRGB. I see where the mistake is, and it appears it should be easy for you to fix.


madVR 0.61 on the left and 0.65 precision 3 on the right.

Uncorrected RED primary 0.626474x 0.3413855y
REC709 RED primary 0.640x 0.330y

With 0.61 the RED primary is 0.626326x 0.341512y
With 0.65 the RED primary is 0.604817x 0.329905y


The bug appears to affect GREEN and BLUE as well, but to a lesser extent. You should be aiming to maximize and bind to the edges of the gamut triangle whenever possible, as yCMS does.

Originally Posted by madshi

The "trade quality for performance" section allows you to use a 7bit or 6bit 3dlut, which might fix that nasty 3dlut stuttering you get with out-of-gamut scenes in Avatar etc.

I don't know if this is good news or bad news. 8bit and 7bit had the bug, but 6bit didn't.

Is this even worth it quality-wise? You'll need to explain how madVR deals with a 6 bit lut. I hope madVR is giving the 3dlut 8bit color data, at which point it does color corrections on the 8 bit color data with 6 bit precision (same adjustment to colors which fall within 4x4x4 blocks of color), while converting to 16 bit. If instead madVR is converting the video to 6 bit color before feeding it to the 3dlut, it would be very lossy and kind of pointless. I have the feeling yCMS does the latter, but you'll need to check with yesgrey...

Even though it fixes the rare 3dlut performance issue, I'm unsure this is the best answer to the problem. I hope it at least gives you an idea of what the bottleneck may be, and are able to come up with a higher quality solution.

ps. I like the changes you made to settings dialog. Everything is much less confusing now. My only request would be duplicating the bit-depth selection for the 3dlut into the Calibration or yCMS tab so all the settings are in one place, and you can just click apply to create it when done.