Looking for help in understanding conversion to/from YUV and linear/non-linear RGB

[wonkey_monkey]

(Title should really say just "from YUV to linear RGB", as that's my primary focus right now)

I've been reading up and trying to understand all the intricacies of colour conversion, specifically conversion to linear RGB.

Suppose we have YUV video and the values have been normalised (taking limited range into account) to:

Y: [0, 1]
UV: [-0.5, 0.5]

The next step is to apply the BT.709 matrix to get non-linear RGB values:

https://i.ibb.co/Fqc64VQx/image.png

The resulting RGB values are non-linear (should really be marked as R', G', B' in the image above). This seems to be as far as, for example ConvertToRGB(matrix = "rec709") goes. The values (now in the range [0,255]) are displayed as is on what is usually an sRGB display, so it's essentially assuming the values are sRGB-non-linear and writing them directly to the screen.

This also seems to be MPC-HC's approach.

That's like applying the sRGB EOTF:

https://i.ibb.co/HpLr540s/image.png

and then displaying the resulting linear values.

But shouldn't it, instead, be using the BT.709 EOTF (if that's what it's called)? This one:

https://i.ibb.co/GQ4sQRq7/image.png

This results in a noticeably brighter image, due to the difference in the curves:

https://i.ibb.co/nMQFVTqW/image.png

sRBG | BT.709

What's the correct approach here? Is it one of those things like aspect ratios/nominal analogue blanking where the technically-incorrect approach has become the standard? Or have I misunderstood something?

---

On a similar note, if I have BT.601 YUV and I want to convert it to linear RGB for display on an sRGB display, shouldn't there also be a primary-conversion step, since BT.601 and sRGB primaries are different?

[huhn]

there is no point in linear for displaying. linear is for processing.
bt.709 has no eotf it only has an oetf so we can ignore that.
bt 709 has no generally accepted gamma or eotf. the only written down one and one that is considered a spec is bt 1886 that doesn't mean mastering studios are using it. gamma usually range from 2.2 to 2.4 sometimes bt 1886 we don't know. actually we know it is not bt 1886 cause they have usually perfect black displays.

sRGB is not a video standard. it is a computer display standard which is the default in windows up to this day and no one cares. while no one is obviously an overstatement it is really not used much outside of specific application gamma 2.2 is used more then actual sRGB for sRGB.

next thing what is your display what is the lightning in your room? if there is one thing i know then i know that it isn't linear.

btw. you have two times that show the same math for the same EOTF while both bt 709 OETF and sRGB EOFT have a linear part they are not linear.

[wonkey_monkey]

there is no point in linear for displaying. linear is for processing.

Which is what I'm doing. But then the results also still have to be displayed at some point, which I'm trying to keep simple by just giving the linear RGB image to the GPU, which then displays the image according to the display's characteristics (i.e. usually sRGB).

bt.709 has no eotf it only has an oetf so we can ignore that.

Not if we want linear RGB at some point. Wouldn't the EOTF just be the inverse of the OETF, even if it isn't explicitly specified in any literature?

the only written down one and one that is considered a spec is bt 1886

I found that here: https://en.wikipedia.org/wiki/ITU-R_BT.1886 and the curve produced is closer to sRGB than the inverse of BT.709, albeit even darker and without a linear section.

That page, along with https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-E.pdf, seems to imply that its purpose is to mimic a CRT's response to non-linear BT, rather than to reproduce what was originally captured by the camera.

That seems to imply, to me, that the images usually produced for viewing end up curved darker than reality - or that there's some additional implicit curve applied to values somewhere.

So I'm just trying to get a grasp on this apparent disconnect between what's captured by the camera and what's output by the display, and figure out what I'm supposed to do to get the "right" "linear" RGB values to the GPU.

It sounds like I should apply the BT.1886 EOTF to the non-linear R'G'B' values to get pseudo-linear RGB (not exactly linear compared to what hit the camera's sensor?), which the GPU will then display, and which should then look the same or at least close to any other program's output.

But (assuming that's correct), it would be nice to know exactly the hows and whys of why it's like that..

btw. you have two times that show the same math

Fixed.

[huhn]

Which is what I'm doing. But then the results also still have to be displayed at some point, which I'm trying to keep simple by just giving the linear RGB image to the GPU, which then displays the image according to the display's characteristics (i.e. usually sRGB).
there is one "broken" d3d11 path that expects linear light and converts that to sRGB. you are just adding errors. sRGB is also barely if ever actually used in any display. but if you would take a typical 2.4 source and apply a reverse sRGB on it the function would then return it to 2.4 on an sRGB calibrated display. the image is actually never linear here you are just tricking the pipeline.

outside of that you just end up with trash.
Not if we want linear RGB at some point. Wouldn't the EOTF just be the inverse of the OETF, even if it isn't explicitly specified in any literature?
the short and wrong answer is OETF camera EOTF display. they have nothing todo with each other. you can capture in PQ with a camera and then release that stuff on a DVD it is a DVD it does not matter if it was HDR at one point.
I found that here: https://en.wikipedia.org/wiki/ITU-R_BT.1886 and the curve produced is closer to sRGB than the inverse of BT.709, albeit even darker and without a linear section.
no it is 2.4. the oetf in there is just a reminder that the "camera" spec hasn't changed.
That page, along with https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-E.pdf, seems to imply that its purpose is to mimic a CRT's response to non-linear BT, rather than to reproduce what was originally captured by the camera.
yes that's an SDR EOTF spec that doesn't mean it is used. but that one is written down. i have not seen talks about it in calibration threads in a long time. it is pretty much side lined.
That seems to imply, to me, that the images usually produced for viewing end up curved darker than reality - or that there's some additional implicit curve applied to values somewhere. they have perfect black displays they just use 2.4. bt 1886 on a perfect black display is 2.4 and that the usual calibration target for dark rooms. it is not written down like bt 1886 but that's one of the EOTF that is actually used.

So I'm just trying to get a grasp on this apparent disconnect between what's captured by the camera and what's output by the display, and figure out what I'm supposed to do to get the "right" "linear" RGB values to the GPU.
they have barely if nothing todo with each other. that's why mastering is done. cameras can use what ever transfer it does not matter for the final video that is shared.
It sounds like I should apply the BT.1886 EOTF to the non-linear R'G'B' values to get pseudo-linear RGB (not exactly linear compared to what hit the camera's sensor?), which the GPU will then display, and which should then look the same or at least close to any other program's output.
do nothing and have a calibrated display and you get the creators intend as close as you could have guess the transfer function is always just a guess for SDR.

if you have self recorded stuff you need a calibrated display and use a industry used EOTF that is usually 2.2 or 2.4 for video.
But (assuming that's correct), it would be nice to know exactly the hows and whys of why it's like that..
if you don't touch the transfer it can not change. that's the fix.