XAVC and Rec. 2020

[Jack Zhang]

Just curious, because UHD specs currently specify Rec. 2020, is XAVC compatible with it in terms of colorimetry or is it still Rec. 709 colorimetry at those resolutions? I'm aware that RAW recording with the AXS recorders might solve that problem.

[Alister Chapman]

It's not really about the codec but gamma curve and color space. SLog2 and Sgamut should exceed BT2020.

[Bruce Watson]

My reading of the wikipedia page on Rec.2020 is that Rec.2020 is significantly different (bigger) that Rec.709. Considerably bigger gamut, 10bit/channel minimum, no interlacing, etc.

XAVC is limited to H.264 which Rec.2020 recognizes. So I'm guessing that XAVC should work fine in a Rec.2020 world. But it'll mostly be used for Rec.709 work. People are going to want and need X.265 to do serious 4k work IMHO, which means a different CODEC than XAVC uses now.

[Alister Chapman]

XAVC is a codec.

Codecs and color spaces are two very different things provided the codec has the bit depth to carry the color space/gamma/gamut you can use any codec you wish.

While BT2020 has a bigger color space than BT709 when encoding this is primarily just a difference in the values that colors are mapped to. For example, with an 8 bit codec we only have 235 levels for each color. In BT709 we map or deepest blue to bit 255, we could also take the even deeper blue of BT2020 and also map this to bit 255. Provided the decoder knows what the source is this will work just fine. The difference would be that the BT709 color space (color range) would be smaller but precision greater, while BT2020 the color range bigger, but precision lower. This is why the primary consideration for high quality BT2020 is 10 bit or greater encoding.

While XAVC is from the H264 family, it is 10 bit, it is 4:2:2 and as a result it can easily carry BT2020 color space, dynamic range etc. These things will depend on the dynamic range, gamma and gamut of the camera. The codec has relatively little effect provided it can transport the signal. XAVC was developed with 4K and BT2020 in mind.

X265 is an open source branch of the HEVC/H265 standard. It's only 8 bit and only 420, 10 bit is possible but not optimised, so X265 would be a poor choice for BT2020.

HEVC/H265 is all about efficiency improvements for broadcasting and distribution. It is not designed as an acquisition codec, it requires a significant amount of processing power to encode. The aim of HEVC is to offer image quality that is perceptually the same as H264 with 50% less bandwidth. One of the key aims is to enable 4K broadcasts using no more bandwidth than current HD broadcasts.
Originally H264 was also designed for distribution rather than acquisition, so perhaps in the future we may see the use of H265 in cameras, but there is a limit to how much data you can discard before it becomes too difficult to reconstruct an image good enough to withstand a tough post production path.

[Jack Zhang]

HEVC also lacks a High Profile at the moment. (High tier IMHO is not High Profile)

I completely agree it is only a delivery format for now. There isn't enough info to determine if it's Long-GOP only or if there are I-frame options coming down the line.

[Steffen Sailer]

Originally Posted by Alister Chapman

XAVC is a codec.

Codecs and color spaces are two very different things provided the codec has the bit depth to carry the color space/gamma/gamut you can use any codec you wish.

While BT2020 has a bigger color space than BT709 when encoding this is primarily just a difference in the values that colors are mapped to. For example, with an 8 bit codec we only have 235 levels for each color. In BT709 we map or deepest blue to bit 255, we could also take the even deeper blue of BT2020 and also map this to bit 255. Provided the decoder knows what the source is this will work just fine. The difference would be that the BT709 color space (color range) would be smaller but precision greater, while BT2020 the color range bigger, but precision lower. This is why the primary consideration for high quality BT2020 is 10 bit or greater encoding.

While XAVC is from the H264 family, it is 10 bit, it is 4:2:2 and as a result it can easily carry BT2020 color space, dynamic range etc. These things will depend on the dynamic range, gamma and gamut of the camera. The codec has relatively little effect provided it can transport the signal. XAVC was developed with 4K and BT2020 in mind.

X265 is an open source branch of the HEVC/H265 standard. It's only 8 bit and only 420, 10 bit is possible but not optimised, so X265 would be a poor choice for BT2020.

HEVC/H265 is all about efficiency improvements for broadcasting and distribution. It is not designed as an acquisition codec, it requires a significant amount of processing power to encode. The aim of HEVC is to offer image quality that is perceptually the same as H264 with 50% less bandwidth. One of the key aims is to enable 4K broadcasts using no more bandwidth than current HD broadcasts.
Originally H264 was also designed for distribution rather than acquisition, so perhaps in the future we may see the use of H265 in cameras, but there is a limit to how much data you can discard before it becomes too difficult to reconstruct an image good enough to withstand a tough post production path.

Hi Alister,

thank you for your comment.
But as far as I know, the "seeing" of colour is a hardware thing, how the colour filter array in front of the sensor is built.

The F5 f.e. has an array for REC 709, same as FS700. The camera won't see the REC 2020 colours, even if it has a mode that does a kind of calculation. The sensor through the different colour filter array of the F55 respective the F65 can realy "see" the wider colour gammut.

I wonder how the RED Sensors are seeing the world?
Please correct me if I'm wrong.

see also Sony’s PMW-F5 and F55: Defining CFA | CineTechnica

[Steffen Sailer]

... and then, the processing of this colours will occur exactly as you have described.
I see that you have posted on Abel Cine on this topic as well. I thought, I could add this here to make REC 2020 clearer, and that it's also hardware-related.
Sorry,

Steffen

[Tom Roper]

If that were true there would be an array of 1024 for each of the primary colors. Thats not the case. The color filter is exactly the same for 8-bit and 10 bit. The a/d converter reads the sensor voltage with 10 bit precision for xavc acquisition, for each of the primary colors, rgb. Any color is represented by mixing of the three primary colors, so the color filter is the same but represents more shades of each primary color. Red camera (or any) will have a different look owing to the cutoff frequency of the dichroic filter, as every filter passes a slight amount of the other two primary colors.

But to address the original question of whether xavc is rec-2020 compliant is getting ahead. It potentially could represent the rec-2020 gamut because it's 10 bit. But it could also be its own unique 10 bit gamut because at this point it's only an acquisition codec, not as yet a broadcast one. Either way, transcoding the gamut to rec-709 doesn't require knowing because the 10 bit addressable space just constructs around the rec709 8 bit space.

[Alister Chapman]

The F5's colour gamut in S-Gamut far exceeds Rec-709. The filters are designed to match most other typical broadcast cameras, so when shooting in 709, just the 709 range is used and the look will be similar to most other Sony cameras, but the colour filters used allow the camera to see well beyond 709. Not as far as, or with as much separation as the F55 and F65, but still much greater than 709, hence the need to use S-Gamut to capture the cameras full range.

Tom the F5/F55's A/D is at least 16bit as the camera outputs 16bit raw. There is no dichroic filter in a bayer camera, the filters are normally absorption filters. Dichroic's are used in 3 chip prism cameras where the filter must pass one colour through while reflecting the others to the other 2 sensors.

Codecs have absolutely nothing to do with Gamut. A codec is a bucket or a container. You can put anything you want in that bucket, plain water (rec 709) or finest champagne (BT2020). The bucket (codec) will hold either just as well. Almost any codec can contain almost any gamut. 8 bit, 10 bit, 16 bit. The bit depth doesn't change the colour space or gamut only the precision within the colour space. Changing the bucket from a plastic one to a glass one won't change the water into champagne or vice versa. It's what you put in the codec that determines the gamut, not the codec itself.

Rec 2020 specifies a 10 bit codec to avoid banding and other artefacts with a wide gamut and dynamic range. 8 bit would struggle.

[Tom Roper]

I should have been at your seminar, thanks Alister. Hope the weather was cooperating.

Some h.264 encoders allow a color space to be specified. Whether this is informational or transformational I can't say, I would assume it is both.

[Tom Roper]

Command, line example:

x264 -- bitrate 28000 -- colorprim "bt709" -- transfer "bt709" -- colormatrix "bt709" -o targetfile.264 sourcefile.mov

[Alister Chapman]

That's just metadata about what should be in the file. It does not necessarily mean that is what is in the file. When a codec is working correctly you encode a data level on the input and then hopefully get the same data value when you decode the codec. But the codec doesn't really know or care what colour that value represents. It is the display device and it's gamut that will determine what colour the data value will represent.
That's why we are able to use the same codec to record different gammas and colour spaces. For example XAVC in an F5/F55 might one day be recording 709, the next minute Hypergamma, then perhaps SLog2 and S-Gamut.
Play back the 709 footage on a 709 monitor and it will have natural contrast, play back the SLog2/S-Gamut on a 709 monitor and the contrast and colours will be off. But play back the SLog2/S-Gamut on a monitor with SLog/S-Gamut and again we will have natural contrast and colours. It's the cameras and display devices that determine the Gamut, not the codec.