Confounded by YUV<->RGB Conversaion

[wswartzendruber]

What the devil is going on here...

https://wikimedia.org/api/rest_v1/media/math/render/svg/9d783bf1ed1edbda3e8e87d3d9067bd156a5e75b

I took that from Wikipedia. The article it's from specifically states that Y is linear light and that Y' is gamma-corrected, perceptual light. It also states specifically that RGB is linear light.

So how in blue blazes do you get a gamma-corrected Y' value for output when taking linear-light values in as input...using nothing but multiplication?

[Sharc]

I would follow the original ITU-R BT.601-7 and ITU-R BT.709-6 specification rather than one of its many interpretations. Perhaps it helps to clarify your questions.
There are some doubts and questions about this article in its 'talk' page by the way .....

[wswartzendruber]

I would like to convert from linear, full-range YCbCr to linear, full-range RGB....and back.

[Sharc]

You may find the answer here:
http://poynton.ca/notes/colour_and_gamma/ColorFAQ.html#RTFToC18
see also para. 7. .... 12.

https://web.archive.org/web/20120403123714/http:/www.equasys.de/colorconversion.html
http://poynton.ca/notes/colour_and_gamma/GammaFAQ.html

[jpsdr]

Have you checked if you can use my avs plugin here (http://forum.doom9.org/showthread.php?t=175488) for doing what you want ? (Maybe also check zimg).
I've also added a pdf document to try to explain the linear/non-linear part in my plugin.

[Sharc]

What the devil is going on here...

https://wikimedia.org/api/rest_v1/media/math/render/svg/9d783bf1ed1edbda3e8e87d3d9067bd156a5e75b

I took that from Wikipedia. The article it's from specifically states that Y is linear light and that Y' is gamma-corrected, perceptual light. It also states specifically that RGB is linear light.

So how in blue blazes do you get a gamma-corrected Y' value for output when taking linear-light values in as input...using nothing but multiplication?
Perhaps the answer is given here:
http://poynton.ca/papers/SMPTE_98_YYZ_Luma/index.html
Since 1953, we have been using the wrong block diagram for color video! The principles of color science dictate that we mix linear RGB to make true luminance, denoted Y. This is known as the Principle of Constant Luminance. But in video we depart from that principle, and implement an engineering approximation: We mix nonlinear ("gamma corrected") R'G'B' to make what I call luma, denoted Y'. (Many video engineers carelessly call this luminance.) To form luma, we use the theoretical coefficients of color science, but we use them in the wrong block diagram: We apply gamma correction before the mixing, instead of after. This alteration in the block diagram is more or less inconsequential in practice, though the departure from theory is apparent in the dark band seen between the green and magenta color bars of the standard video test pattern.

[wswartzendruber]

I ended up assuming that the HOWTO on Wikipedia was irrational. I wrote my own method for RGB->YCbCr using strictly linear light. From that, I then refined an inverse of YCbCr->RGB.

https://github.com/wswartzendruber/pgs-tools/blob/main/pgsmod/src/rgb.rs

Note that my bt1886_oetf function there should really be bt1886_ieotf.

[DTL]

Perhaps the answer is given here:
http://poynton.ca/papers/SMPTE_98_YYZ_Luma/index.html
we have been using the wrong block diagram for color video!


With unlimited precision (and zero noise) it looks it no matter where to put TF-domain compression device - before linear matrix or after. The RGB linear data channels are also not pure natural datasource but the integration of natural scene spectrum via pass-band filters.
The bad things happens when processing of different outputs of YUV matrix performed in different frequency bands paths (like sub-sampled chroma to 4:2:2 or 2:0 or 1:1 etc). To completely reverse operations the equal data channels required.

It is shadows from the poor old days when frequency spectrum and bitspeeds where very limited and engineers designed lots of compression stages to moving pictures data - interlace, gamma, chroma subsampling and mpeg. But not all of compression stages are fully-reversible. From modern systems interlace is mostly killed and I think the chroma subsampling need to be killed too. Though it makes less visible distortions in compare with interlace scan and mostly at the
transients of very saturated colours that is rare at natural scenes.

[Balling]

What the devil is going on here...

https://wikimedia.org/api/rest_v1/media/math/render/svg/9d783bf1ed1edbda3e8e87d3d9067bd156a5e75b

I took that from Wikipedia. The article it's from specifically states that Y is linear light and that Y' is gamma-corrected, perceptual light. It also states specifically that RGB is linear light.

So how in blue blazes do you get a gamma-corrected Y' value for output when taking linear-light values in as input...using nothing but multiplication?

I added those there. There is no evidence those were ever used by ATSC. Ever. And there is talk page info there. https://en.wikipedia.org/wiki/Talk:YUV#Did_ATSC_1.0,_2.0,_3.0_really_use_analog_Umax,_Vmax_scaled_BT.709?

Those are using analog Y'U'V', NOT Y'Cb'Cr'!! Nobody needs it no longer. This is just for historical info. The BT.709 /BT.2020 matricies and inverses are in YCbCr article (also added by me).

As for how. This is just a typo, though linear RGB were also in use in russian SECAM IV, but then you get linear YUV. Fixed.

About linear RGB is also just a typo, long since removed.

[DTL]

'the dark band seen between the green and magenta color bars of the standard video test pattern'

The old and current ITU motion pictures imaging systems do have build-in bugs for colour imaging but they are expected to be rarely seen because of:
1. Natural imaging rarely have saturated colours.
2. If ever saturated colours happens - they much more rare close to each and form high saturated colour transient.
So colour bars test pattern is sort of never-happen in reality image. Just sad bug for colour imaging systems of old days and todays.

Unfortunately the designers of synthetic images are not knows these limitations so typical broadcast 4:2:0 TV are highly loaded with top-saturated advertisements and clips and shows and displays these bugs.