Color Matrix question

[kolak]

HDR RGB data converted to YUV over Rec.709 matrix then back to RGB with inverse 709 and then again to YUV over Rec.2020 is as good as direct conversion to Rec.2020?
Is there any meaningful loss?

[MysteryX]

You can try it and do a mt_makediff to see whether there's any difference. It shouldn't in theory, but you may want to do it in 16-bit-depth.

[kolak]

It's more a theoretical question.
We assume precision is 16bit or even float.
Cool- thanks.

[groucho86]

Theoretically, one matrix operation is cleaner than 3. You're losing a little bit of precision every time.

[kolak]

Yes, I get this (not worried about some tiny rounding etc.).
But from math point Rec.709 steps don't limit original data in any way?

If were to do Rec.2020 ->Rec.709 gamut conversion ->Rec.2020 I would loose a lot.
My mentioned path is nothing like this, yes?
We just do pintles conversion, but it's not loosing data in meaningful way.

[groucho86]

Working in integer, you run the risk of clipping negative numbers (ie, out of gamut values). Working in float, you'll be safe.

[kolak]

So if I have SDI card which does not support Rec.2020 matrix and I want to push HDR data through it then safest way is to avoid going to YUV (which a lot of SDI card need to do due to bandwidth limits) and stay with RGB (so data is 1:1 copy).

[FranceBB]

So if I have SDI card which does not support Rec.2020 matrix and I want to push HDR data through it then safest way is to avoid going to YUV (which a lot of SDI card need to do due to bandwidth limits) and stay with RGB (so data is 1:1 copy).

Ah, right, this question came up at work as well for 10bit planar capable cards which cannot write BT2020.
Yes, I would say to stay in RGB and then go to YUV with something that is BT2020 aware. A bit of a pain but hey, you would have to re-encode the stream anyway, so...
Also make sure you're writing the right transfer characteristics in the final file since you mentioned HDR.


P.s in our case the signal was coming as 4:2:2 10bit planar 50p BT2020nc HLG, EVS saves it as it is by re-encoding to AVC Intra Class flagging it as BT709 SDR, then FFMpeg remuxes changing the metadata of the colormatrix and transfer characteristics and that's pretty much it. Easy peasy.

[kolak]

Metadata is handled manually. It's all about not loosing real data during such a convoluted conversion.

[Balling]

YCbCr is much bigger than RGB even if it is full RGB to full YCbCr (you are using limited though, right? Only DV profile 5 is full range). 8 bit RGB require 10 bit YCbCr to preserve it and 10 bit RGB require 12 bit.

Some dumb example, even if you are using YCbCr BT.709 limited values 139, 151, 24 that is RGB -21, 182, 181. That is out-of-gamut for BT.709, obviously since negative RGB. Okay? But all 3 components are inside 16-235, 16-240, 16-240 range for Y, Cb, Cr.

[kolak]

Gamut should not matter as long as same matrix is used when converting from and to RGB, no ? There won't be any processing in YUV so no place to create bad YUV combinations.

RGB (with P3 gamut inside Rec.2020) -> YUV (over 709) -> RGB (reverse 709) -> final RGB treated as Rec.2020

[Blankmedia]

Some tyme when I'm using masktool, my frame goes green and script clip throws an error about having no clue what _colormatrix is and I'm out of idea.

Last thing I did was to converty video so maybe it would proper set de matrix :converttoyuv444(rec709).converttoyv12(rec709)


Have a good night!
..

[StainlessS]

BlankMedia, start new thread and post your script.

[Balling]

Gamut should not matter as long as same matrix is used when converting from and to RGB, no ? There won't be any processing in YUV so no place to create bad YUV combinations.


No. Both down chroma sampling and lossy codec introduce out-of-gamut values and those values are not "bad".