BT.709 is for "HD"; What is HD?

[Alwyn]

I've been doing some reading regarding the BT.709 and REC. 601 colour spaces. I will admit a lot of this stuff goes over my head but one thing is clear; Rec. 601 is for SD video and BT.709 is for HD video.

To quote from the BT.709 wiki:

Recommendation ITU-R BT.709-6 defines a common image format (CIF) where picture characteristics are independent of the frame rate. The image is 1920x1080 pixels, for a total pixel count of 2,073,600.[6]

In the context of upscaling SD to 1440x1080, is this considered "HD", or does "HD" refer the width, meaning 1920 is HD?

Any thoughts would be appreciated.

[poisondeathray]

In the context of upscaling SD to 1440x1080, is this considered "HD"

Yes.

By convention, >576 height is considered "HD"

Many media players will use Rec709 for display if the height is >576, Rec601 if height <=576 , if there are no other instructions such as VUI stating the colormatrix

[DB83]

In PAL land, HD can be ANY vertical resolution, but typically 720 or 1080, greater than 576. And, equally, in NTSC land the yard stick is 480.

So we see the comments 'HD' and 'Full HD'.


Horizontal resolution is, AFAIK, no player in this game.

[jagabo]

There's no exact definition of when video stops being SD and becomes HD. And both SD ad HD can use either matrix (for example, some still camera's produce HD video with rec.610 colors). Yes, generally, 720 lines and above is considered HD, 576 and below is considered SD for PAL, 486 and below SD for NTSC (some capture devices capture 486 lines, not just 480). But there are many in-between cases. If you take a letterboxed HD 2.35:1 1280x720 video and crop away the black borders you get 1280x544. Is that now SD because it's less than 720 lines? It's even less than the 576 lines of SD PAL.

Different players use different thresholds. Some players just use 602 for everything. Some use 709 for everything. It's a wild west.
You usually want to use rec.601 576/480 and below, rec.709 for 720 and above. But specify the matrix flag when you encode. That gives you a best chance of getting the correct colors on playback. Better players will follow the flag, regardless of the resolution of the video -- and only fall back to resolution (whatever threshold they use) when the matrix isn't flagged.

[Alwyn]

Thanks all.

[Bwaak]

I suppose the spec is about broadcast formats, and there have been only two digital HD broadcast formats: 720p and 1080i. 1080p50 has been introduced in Europe around 2016. 625p50 was considered HD in Australia, I wonder whether it used 709 or 601?

I believe the reason for 709 is that it allows wider color gamut, which I suppose was influenced by switching from CRT to plasma and then LCD, which offered higher dynamic range and color gamut. I don't think this standard is related to whatever people do with their files, but I suppose as long as the content matches the header, and the playback device can make sense of it, any of the two can be used.

Now thinking of it, since we use LCD panels, does it make sense to use 709 for everything?

On a second thought, I searched online and 601 looks very similar to 709. Looking at the numbers, they are practically identical, 709 has slightly more in the green channel. So, I guess who cares, use one or another. Compared to 2020 or other formats, the difference between 601 and 709 is negligible (expecting lollo doing frame subtraction comparison in 3... 2... 1... seconds).

EDIT: an interesting article about multi-primary displays: WCG Standards Needed for Multi-Primary Displays

[lollo]

(expecting lollo doing frame subtraction comparison in 3... 2... 1... seconds)

0…

If you do not want to see the difference is useless

[Sharc]

601 an 709 constitute rules how to transform RGB <-> Y'CbCr. Purpose of the transformation is to reduce bandwidth and support backward compatibility with legacy B&W TV. Broadcast eventually just transmits Y'CbCr tristimuli, not knowing or caring how these were produced. It's just a matter of the decoder in the TV set to decide how the receiced Y'CbCr tristimuli are being converted to RGB for viewing on the TV monitor.

The differences are visible. See the posts where people wonder about "unexplained" color differences (in addition to full range/limited range issues).

Whether it was a good idea to introduce 709 after 601 is a different question ......

[Bwaak]

@Sharc, assuming that one can accept the small difference between 601 and 709 in the green channel, is 709 more, um, correct or predictable when transforming RGB <-> Y'CbCr, in particular when full range values are used? I looked at the messages regarding color space and it seems that some of the conversions one way or another produce out of bounds values or something?

[jagabo]

rec.601 and rec.709 are different rotations of the RGB color cube inside the YUV cube:

https://www.intel.com/content/www/us/en/docs/ipp/developer-reference/2021-7/color-mode...uage=en#FIG6-5

The inner cube is the full valid RGB space, the outer cube is the larger YUV space. Rec.601 and rec.709 are slightly different rotations of that inner cube. Using the wrong matrix on conversion will produce out of gamut colors near the edges of the RGB space. Fortunately, most software and devices deal with that fairly well these day, just crushing the out of gamut colors against the edge of the cube -- not like long ago where you might get gross errors (for example, in 8 bit RGB the brightest any component can be is 255, so an over bright white which should have been RGB=256,256,256 wrapped around to RGB=0,0,0, something that should have been white became black).

It's not just greens that are effect by rec.601 vs rec.709. Pretty much all colors are effected:

https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback#post2045830

Fortunately, it's not a huge difference. Most people probably wouldn't notice the difference unless A/B flipping between the two.

[poisondeathray]

I don't think this standard is related to whatever people do with their files, but I suppose as long as the content matches the header, and the playback device can make sense of it, any of the two can be used.

On a second thought, I searched online and 601 looks very similar to 709. Looking at the numbers, they are practically identical, 709 has slightly more in the green channel. So, I guess who cares, use one or another. Compared to 2020 or other formats, the difference between 601 and 709 is negligible (expecting lollo doing frame subtraction comparison in 3... 2... 1... seconds).

Many people "care" , otherwise there wouln't be so many threads about the "wrong color" and Rec601/709 mismatches

The delta can be around 30 for the green channel for 8bit. Not massive, but not "negligible" either

There is a higher chance of that wrong colors for playback if you use Rec601 for HD, even if you flag the colorimetry.

e.g. Youtube is major source for this. If you use Rec601, flag it correctly, you will still have the wrong colors for HD video

Many people want correct colors. Skin tones, logos, flags, known object colors in family videos will be slightly off.

The highest chance for correct colors in all scenarios is to use 709 for HD, and set the colorimetry VUI properly .

is 709 more, um, correct or predictable when transforming RGB <-> Y'CbCr, in particular when full range values are used?

Full range 709 preserves about 3.5% more unique original colors than Full range 601 for an 8bit integer round trip RGB=>YCbCr=RGB

[Bwaak]

Many people want correct colors. Skin tones, logos, flags, known object colors in family videos will be slightly off.

Practically no one watches their videos on a calibrated monitor in a light-controlled room...

Full range 709 preserves about 3.5% more unique original colors than Full range 601 for an 8bit integer round trip RGB=>YCbCr=RGB

Thanks!

[poisondeathray]

Many people want correct colors. Skin tones, logos, flags, known object colors in family videos will be slightly off.

Practically no one watches their videos on a calibrated monitor in a light-controlled room...

Ok, but why would anyone choose to have slighly off colors more frequently ? 1-3% color error might be "negligible". 12-17% error in some cases is a bit too high and more % of "general public" begin to notice

It's not as if you're jumping through hoops in some convoluted workflow . 709 is the standard for HD anyways

[Bwaak]

Sure, 12%-17% is more than I thought. No arguing, correct color is important.

[Sharc]

@Sharc, assuming that one can accept the small difference between 601 and 709 in the green channel, is 709 more, um, correct or predictable when transforming RGB <-> Y'CbCr, in particular when full range values are used? I looked at the messages regarding color space and it seems that some of the conversions one way or another produce out of bounds values or something?

Yes, this may happen, as others have explained.

Here an example for RGB transformed to YUV using the 601 matrix and decoded to using the 709 matrix:
Source is RGB(10,230,10) -> using 601 matrix -> YCbCr(135,64,47)
Decoding YCbCr(135,64,47) -> using 709 matrix -> RGB(-7,195,3) => R(-7) is out of gamut -> clipped to RGB(0,195,3)


[Attachment 73038 - Click to enlarge]

[sophisticles]

Ok, but why would anyone choose to have slightly off colors more frequently ?s

For the same reason video and photos shot for professional purposes are usually shot flat and then graded, because quite often you don't want what actually was but what you would have preferred it was.

[poisondeathray]

Ok, but why would anyone choose to have slightly off colors more frequently ?s

For the same reason video and photos shot for professional purposes are usually shot flat and then graded, because quite often you don't want what actually was but what you would have preferred it was.

Not really, that's bad analogy

Rec709 /Rec601 is for end delivery , after it's been graded and "dumbed down", not for acquisition . So why would anybody choose to have their end delivery with slightly off colors more frequently ?

Acquisition for higher end video (and photo) is usually done in RAW , not with a Rec709 transfer curve "baked" in