FORUMS: list search recent posts

# @Jeremy: The Matrix (no the movie).

VIEW ALL
 @Jeremy: The Matrix (no the movie). on Sep 11, 2012 at 11:30:28 am

Jeremy:
I'm sorry. I was posting at 3 AM, bit zombie, and anyway i write too slow to fallow the discussion in RT.
So now that, I hope, everybody is having a good sleep from New York to California, I'll try to write more calmly.
And better to start a new thread.

FIRST TO SAY:
We have been messing things very much talking about color spaces, LUTs, or even codecs.
We are dealing with something much older than that, and that exists before any working RGB color format has been even formulated.

Is about how VIDEO CAMERAS and TV sets works since the first analog TV Color system. So haven't changed since 1940.

We are talking about video matrix, so the maths that a video processor makes to convert the Red, Green and Blue (cached by mean of tubes, CCDs or CMOS) to video components (YUV, YCbCr) and how those components are decoded back to RGB on a Color TV or monitor.

THE VIDEO MATRIX:
I think this is not difficult to fallow being a bit "graphic:

Think of the matrix like a box with three cables getting IN (RGB) and three cables getting OUT (YUV).

Simplifying (a lot), this is the way an SD video matrix works:

For every RGB value that you enter in the box, the matrix apply three basic formulas:

Y = 0.299 R + 0.587 G + 0.114 B
U= 0,493 (B-Y)
V= 0,877 (R-Y)

So if your camera sensor is catching: R= a, G =b, B= c, you only need to substitute "a", "b" and "c" instead of R, G and B in those equations to get the correspondent Y, U, and V values: (Y= d, U= e, V= f )

When you feed with the video signal a color TV or color monitor, the matrix works the opposite.
You enter in the box three YUV values and you get three RGB values.

The box will apply exactly the same equations:

Y = 0.299 R + 0.587 G + 0.114 B
U= 0,493 (B-Y)
V= 0,877 (R-Y)

So if the box you gets IN Y= d U= e V= f, applying the same formulas will put OUT: R= a, G= b, B=c , so the original color.

And this is all about the Rec-601 and Rec-709.
Both are two slightly different set of formulas/equation to convert RGB to YUV and back YUV to RGB.

The Difference Between Rec-601 and Rec709, is not a big deal.
The essential difference is that they use a different coefficients in the formula to calculate "Y".

- Rec-601 uses: Y = 0.299 R + 0.587 G + 0.114 B (SD Standard)

- Rec-709 uses: Y = 02126 R + 0,7158 G + 0,0722 (HD Standard)

(More in: http://en.wikipedia.org/wiki/YUV)

But applying one matrix instead of the other is nothing wrong as long as you are consistent.
Just need to apply the same matrix when going RGB to YUV and when going back YUV to RGB in order to recover the original colors.

So, from my point of view, the Canon is not doing something intrinsically wrong.
Is just not using the expected matrix (Rec-709) when converting RGB to YUV, but a different one (Rec-601)
And this is not a problem if YOU (your application) use the same matrix to convert back YUV to RGB.
If is done this way, once the footage is again RGB, can be converted to Rec-709 without lose.

WHICH MATRIX IS BETTER?:
Read what Wikipedia say on the Rec-709 matrix (LUMA COEFFICIENTS) (http://en.wikipedia.org/wiki/Rec._709)

"HDTV according to Rec. 709 forms luma (Y’) using R’G’B’ coefficients 0.2126, 0.7152, and 0.0722. This means that unlike Rec. 601, the coefficients match the primaries and white points, so luma corresponds more closely to luminance. Some experts feel that the advantages of correct matrix coefficients do not justify the change from Rec. 601 coefficients. Although worldwide agreement on a single R’G’B’ system was achieved upon the adoption of Rec. 709, adoption of different luma coefficients created a second flavour of Y’CBCR".

So the Rec-709 should represent better the "bright" of the real life objects (this is video), But the last commentary leads me to think that in the practice, the difference might be too subtle to appreciate it visually in some cases.

In the same article (TRANSFER CHARACTERISTICS), says:
"….Rec. 709 and sRGB share the same primary chromaticities and white point chromaticity; however, sRGB is explicitly output (display) referred with an average gamma of 2.2.."

Again, this leads me to think that Rec-709 and sRGB, are basically interchangeable and so, if the "Color Space Override" in FCPX works on video clips, changing between Rec-601/709/sRGB, the effect may be too subtle to appreciate it bare eyes on FCPX canvas.
Rafa

http://www.nagavideo.com

 Re: @Jeremy: The Matrix (no the movie).on Sep 11, 2012 at 6:01:56 pm

One wrinkle is that any RGB-processing application will not be performing the YCbCr/RGB transfer itself; the H.264 decoder does that and passes RGB to the application.

So if you had 601-encoded RGB that you transfer to YCbCr then transfer back to RGB with the 709 matrix, is that mathematically equivalent to transforming from RGB in 601 to RGB in 709?

I'm not sure that the intermediate YCbCr space is display-independent, so I'm not sure that you can use a standard profile after the fact to transform the incorrectly-decoded RGB. I'd welcome correction.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events

 Re: @Jeremy: The Matrix (no the movie).on Sep 12, 2012 at 2:19:54 am

[Walter Soyka] "One wrinkle is that any RGB-processing application will not be performing the YCbCr/RGB transfer itself; the H.264 decoder does that and passes RGB to the application.

So if you had 601-encoded RGB that you transfer to YCbCr then transfer back to RGB with the 709 matrix, is that mathematically equivalent to transforming from RGB in 601 to RGB in 709?"

That's a good question Walter.
What is clear is that H264 supports Rec-601 and Rec-709 , and, I guess, that's independent of the picture size.
The x264 QT Component (also Handbrake, if I'm not wrong) allows to chose the matrix and flag the file accordingly.
So if the decoder works properly should apply the same matrix when coding and decoding.

Don't you think that might be a way to access the raw YUV information overriding the decoder?
I know that 5DtoRGb claimed they have their own engine to translate the H264 to RGB.
rafael

http://www.nagavideo.com