Different values for color primaries, transfer, and matrix coefficients ?

[ganymede]

Hi,

According to http://mewiki.project357.com, here is the meaning of some x264 parameters :

• colorprim stands for "color primaries for converting to RGB"
• transfer stands for "the opto-electronic transfer characteristics to use. (Sets the gamma curve to use for correction.)"
• colormatrix stands for "the matrix coefficients used in deriving the luma and chroma from the RGB primaries"

These parameters can also be found in mediainfo output for H.264 video streams (respectively "Color primaries", "Transfer characteristics" and "Matrix coefficients").

As far as I understand, a "color matrix" is a set of coefficients used to convert YUV color values to RGB (e.g. to display video on screen), and vice versa. Different sets of coefficients have been standardized ; most of the time SD video uses BT.601 / BT 470 B,G coefficients, while HD video uses BT.709.

But, on some H.264 streams, these parameters can have differents values. Example from one of my Canon DSLR's MOV files :

Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.601

Since this is HD video, I would have expected all these parameters to have the "BT.709" value. How can these parameters have different values ? Is this file somewhat "incorrect" ? Does this mean that BT.601 was used to derive luma and chroma values from the sensor's RGB data, but that BT.709 must be used to convert back YUV data to RGB ?

[hello_hello]

I don't know the answer but if there's a reason for it I'd be interested to fins out.

Handbrake/Vidcoder does a similar thing when re-encoding DVD video. It sets the Colour Primaries and Matrix Coefficients to BT.601 and the Transfer Characteristics to BT.709. I asked about it in the Vidcoder thread but didn't get a response.

[raffriff42]

BT.601 and BT.709 compatibility benchmark

Regarding the flags, "Transfer characteristics" did not have an effect on any player. "Matrix coefficients" was the one that mattered in proper BT.601/BT.709 reproduction..."Color primaries" had an effect only on Quick Time...

See also:
Color coefficients and Colormatrix usage summary

every HDTV I have ever heard of uses Rec 709 primaries

So my working rule is that as far as players are concerned, Matrix Coefficients matter, Primaries and Transfer Characteristics don't (except as noted above) - but set them all anyway when encoding, as required by the spec.

EDIT (to answer your question) I think the settings get mismatched when the encoder fails to explicitly set all three parameters, leaving those not set to either their previous or default values.

[Warperus]

Is this file somewhat "incorrect" ?

File definition of discussed settings are correct, what is inside is another question, but there is quite common combination for it (sRGB->YUV with BT.601 conversion matrix).

Recommendations BT.601 and BT.709 use same definition for transfer characteristics, h.262 and h.264 don't have different coding for it, they both define only BT.709. Also this coding is more than similar to sRGB definition. So, BT.709 for transfer characteristics is absolutely correct.

Recommendation BT.601 defines 2 possibilities for color primaries. One (for PAL) is similar to Recommendation ITU-R BT.470-2 System B, G. Another one (NTSC) is similar to SMPTE 240M (1987). Strictly said they are not compatible with sRGB, that is computer can't correctly show these colors. So in digital world old color primaries are not being widely used. As standards h.262 and h.264 allow separate coding for color matrix and color primaries it's ok to mix values from different origins. So, setting color primaries to BT.709 is valid, even though it might be incorrect for some weird sources captured in original BT.601 color primaries (but it's the responsibility of capturer to set color primaries correctly in this case).

Does this mean that BT.601 was used to derive luma and chroma values from the sensor's RGB data, but that BT.709 must be used to convert back YUV data to RGB ?

Nope, BT.601 color matrix must be used to convert YUV data back to RGB, but this RGB will be BT.709-compatible RGB.
For computer processing/presentation it will end up in sRGB in fact instead of BT.709 RGB. Strictly said they are different, but difference was judged to be non-significant during sRGB development.

[ganymede]

@raffriff42 and Warperus : thank you for your very informative answers.

BT.601 color matrix must be used to convert YUV data back to RGB

That makes sense, but is surprising because these Canon MOV files are HD.

As practical consequences, when editing this kind of footage, am I safe to assume that :

• if I don't resize the video stream, I should convert color matrix to BT.709 (eg. with avisynth ColorMatrix or vapoursynth fmtconv) to ensure that it will be displayed correctly on most players ?
• but in case I downsize from HD to SD, I don't have to apply any color matrix filter, and can just flag the edited stream as BT.601 ?

There is indeed a possibility that these files are incorrectly flagged, as raffriff42 suggests, but it would be a surprizing mistake from Canon, and I'm under the impression that colors were more "right" on my calibrated monitor when displayed as a BT.601 YUV stream than as a BT.709 one... Of course, it's not exact science

[raffriff42]

>I'm under the impression that colors were more "right" on my calibrated monitor when displayed as a BT.601
There you go, this confirms to me that "Matrix coefficients: BT.601" is valid, and the other flags are not *as* significant.

Why 601 and not 709 in HD? To indulge in wild speculation, Canon may may chosen to keep Rec.601 for historical reasons, to be compatible with their own and existing 3rd party decoders.