What is the historical reason of using different YUV matrices?

[Z2697]

As it appears to me, matrices are only used to convert between YUV and RGB numbers, and YUV is only a intermediate format for compression, doesn't affect other part of the process.
Why not use a separately designed matrix, instead of using matrices derived from each standard?

(Let's not talk about some "mixture" matrices, like BT.2020-CL which requires transfer function)

==========

Original content:
Especially the more common ones, BT.601, BT.709 and BT.2020, I can guess why something like YCgCo was considered.
They are ultimately similar. BT.709 is more shifted towards green, which was already have high weight in BT.601. BT.2020 shifted some green (and more blue) back to red... for what reason?
BT.601 is more "well-balanced" in my opinion
(In cases where you have RGB source, I don't think converting from other matrices will do anything)

Original title: "What was the real reason people made different YUV matrices?"

[wswartzendruber]

Are you asking about why we have different color gamuts?

[Z2697]

No, color gamuts have easier to understand goals.
Matrices are looking like they just arbitrarily juggling numbers around.

[rwill]

stackoverflow.com/questions/53952959/why-were-the-constants-in-yuv-rgb-chosen-to-be-the-values-they-are

??

[huhn]

it is very simple.
bt 709 and such are colorspaces they define colors brightness of these colors.
YCgCo and YCbCr are just mathematical models not or container someone else will give you the correct name. YCgCo for example is not that powerful it is just easy to calculate. itp super seeds YCbCr and is barely used. the idea is to get all luma information into the Y or I channel (i say ytp all the time btw.) itp does a pretty good job compared to the rest ever so slightly improving image compression.

and it does not matter if something is bt 601 bt 709 or bt 2020 on a bt 2020 calibrated device all will look the same you will only get difference when you are showing colors outside of bt 601 that bt 709 can do and so on for the rest nothing changes nothing is more natural nothing is more balanced this is just a calibration issue.

they are just bigger colorspaces giving more freedom to creators.

[Z2697]

I guess I was asking for a history lesson of why YUV matrices need to be a result of other things really.
Because as it appears to me, (nowadays) the matrices are converting RGB and YUV numbers, YUV signals are like middlegrounds, they don't seem to affecting other parts?

[huhn]

yuv exist so you can compress the not that important chroma information more compared to the massively more important luma information and it allows subsampling.

the number are just models to make as much of luma information into the Y channel that's pretty much it. the other stuff is there to represent a different colorspace.

[Z2697]

That's what I mean, YUV only exists as a intermediate format for compression nowadays.
A separately designed matrix can be used pretty much no problem, like YCgCo.
So what's the historical reason that the "traditional" matrices are the way they are, coming out from each standards?

[huhn]

analogue is different and i know not much about it.
but digital it is just for compression there was never a device that could display YCbCr. it is just there to allow subsampling and to put as much important information into Y.

YCgCo is terrible it just newer and made to be as easy to calculate as possible i saw a spec talking about the use in DSC many many years ago i do not know if it is actually used in DSC.

[Z2697]

I not saying YCgCo is better, it's just an example of a matrix designed separately. And it can be used without problem, aside from the "fact" that it may be poorly designed.

[GeoffreyA]

From reading on Wikipedia, what I understand is that BT.601 was made to encode analogue signals in a digital format, carrying the legacy luma-chroma system along with it. With BT.709, it was primarily digital and RGB-based.

[huhn]

Originally Posted by Z2697

I not saying YCgCo is better, it's just an example of a matrix designed separately. And it can be used without problem, aside from the "fact" that it may be poorly designed.

it's terrible for quality or to be a bit more precise it harms quality.

it does exactly what it was design to do been super fast. if it is used without subsampling it will have its applications.

Originally Posted by GeoffreyA

From reading on Wikipedia, what I understand is that BT.601 was made to encode analogue signals in a digital format, carrying the legacy luma-chroma system along with it. With BT.709, it was primarily digital and RGB-based.

yes i do not know the analogue history. first color TV used some tricks to be backwards compatible with black and white TVs and that's about it what i know about the YUV from analogue stuff.

[Sharc]

Originally Posted by GeoffreyA

From reading on Wikipedia, what I understand is that BT.601 was made to encode analogue signals in a digital format, carrying the legacy luma-chroma system along with it...

Yes. Note that there exist plenty of matrices (=set of equations) which define RGB<->YUV conversions, like 601, 709, 2020, Adobe etc. Main purpose of the transformation RGB->YUV was to provide a solution which warrants backwards compatibility of color TV broadcast with exisiting B&W TV sets when colorTV was introduced. Second purpose was bandwidth reduction (in analog domain for the U,V components) or data reduction by chroma subsampling in the digital domain. YUV are no real colors, one can't "see" YUV, and as TV/PC monitors work on "real" RGB colors only YUV has to be converted back to RGB for viewing, using the inverse matrix.
Important is to use the correct inverse matrix, otherwise color distortions result.

[Z2697]

Originally Posted by huhn

it's terrible for quality or to be a bit more precise it harms quality.

it does exactly what it was design to do been super fast. if it is used without subsampling it will have its applications.


yes i do not know the analogue history. first color TV used some tricks to be backwards compatible with black and white TVs and that's about it what i know about the YUV from analogue stuff.

Subsampling is a mistake to begin with.
Or maybe more precisely, the lack of the usage of YUV444 is a mistake. (in the "industry")

And YCgCo isn't really that bad as you described, even when subsampling is considered.

[Balling]

Originally Posted by Z2697

I guess I was asking for a history lesson of why YUV matrices need to be a result of other things really.
Because as it appears to me, (nowadays) the matrices are converting RGB and YUV numbers, YUV signals are like middlegrounds, they don't seem to affecting other parts?

Well, ideally BT.2020 matrix is used with BT.2020 primaries. Matrix moved the data from YCbCr to R'G'B' (BT.2020 matrix in this case) and then when you get RGB --> XYZ using the Bt.2020 primaries NPM (normalised primaries matrix) you get the XYZ where Y is mosty the same as Y' original. This is called near constant luminance, and that is why the two matrices (the chroma matrix and the NPM) need to be related to each other (https://colour.readthedocs.io/en/lat...ry_matrix.html).

[DTL]

Matrices are different because colour primaries in different systems are different (not very much in Standard colour gamuts and more in Wide). And YUV data domain adjusted to get more or less good Y (luma) black and white data channel and not very bad UVs in terms of absolute amplitude (to have best or at least good signal to noise ratio in analog and digital domains (where low level of data cause more banding)). It looks matrices coeffs selection also some trade between banding and out of range colors so we have such issues like out of nominal RGBs from some in-range (valid YUV) triplets.

[Ingram112]

The differences in YUV matrices often come down to display standards and color reproduction accuracy. For example, BT.601 was designed for SD content, while BT.709 targets HD content with a slightly different green weighting. Each matrix aims to optimize perceived color on its intended display, which explains why conversions between matrices are sometimes necessary in professional workflows.

[wonkey_monkey]

Thanks ChatGPT.

[Emulgator]

I felt so too ;-)
https://forum.doom9.org/showthread.p...21#post2027921
https://forum.doom9.org/showthread.p...22#post2027922
https://forum.doom9.org/showthread.p...19#post2028019

[Atak_Snajpera]

Originally Posted by Emulgator

I felt so too ;-)
https://forum.doom9.org/showthread.p...21#post2027921
https://forum.doom9.org/showthread.p...22#post2027922
https://forum.doom9.org/showthread.p...19#post2028019

Time for BAN AI SLOP NOT ALLOWED!