{"id":171,"date":"2025-10-14T09:44:20","date_gmt":"2025-10-14T16:44:20","guid":{"rendered":"https:\/\/videoq.com\/blog2\/?p=171"},"modified":"2025-10-14T09:44:20","modified_gmt":"2025-10-14T16:44:20","slug":"rgb-yuv-convenient-nicknames","status":"publish","type":"post","link":"https:\/\/videoq.com\/blog2\/2025\/10\/14\/rgb-yuv-convenient-nicknames\/","title":{"rendered":"RGB, YUV & Media Ambit"},"content":{"rendered":"\n

RGB<\/strong> is the convenient and simple designation of additive color model used for more than 100 years in colorimetry,\u00a0 photography, cinematography, color TV and other areas. Does it means something particular<\/em><\/strong>?<\/p>\n\n\n\n

Not at all!<\/strong>

There are so many variants of hardly compatible systems, using RGB as convenient label for light levels, screen pixels, analog or digital signals, or even the group of sub-channels within multi-channel video data processor.

Adding subscript and superscript indices, extra explanatory letters and\u00a0 exponential values are not necessarily helpful.<\/p>\n\n\n\n\n\n\n\n

The academic pedants insist on these cumbersome additions and they are keen to append more and more symbols<\/strong>\u00a0 all the way from the camera lens to the display screen, thus making video engineers’ life<\/strong> really difficult.<\/p>\n\n\n\n

The terminology committees have one very good rule:
If some feature<\/strong> of the term is well known and assumed by default<\/strong>, then such feature should be excluded <\/strong>from the term itself. The scientific name for this procedure is ellipsis<\/strong><\/em>\u00a0 (from the Greek: \u1f14\u03bb\u03bb\u03b5\u03b9\u03c8\u03b9\u03c2<\/span>, \u00e9lleipsis<\/i>, “omission”).<\/p>\n\n\n\n

E.g. if the whole exhibition is dedicated to electric <\/strong>cars, then the presenter may say “this wonderful car”, omitting “electric<\/em><\/strong>“.<\/p>\n\n\n\n

Thus, we have full right to designate the Red channel signal simply R<\/strong>\u00a0 if we know for sure<\/strong>, that we are talking about some particular<\/strong> flavor <\/strong>of this wonderful signal.<\/p>\n\n\n\n

For example:\u00a0Full Range 10 bit , decompressed, full bandwidth, gamma-corrected, color-corrected R component of HDR-PQ RGB data, originated in assumption of BT.2020 Primaries and D65 White Point, taken at the output of the color enhancement stage of the production workflow using Master Display in the\u00a0 DCI-P3 Primaries mode.<\/span><\/em>
Oof! The provided statement offers us a nice self-explanatory<\/strong> and short <\/strong>definition of the signal in question, thank you very much<\/em>.<\/p>\n\n\n\n

The YUV<\/strong> signals group consists of the luminance signal Y<\/strong> (weighted sum of  R, G and B signals) and two color difference signals  B-Y, and R-Y. Color difference signals are scaled to fit the available  data levels range, e.g. 8, 10, 12  or 16 bit. The scaled versions of B-Y and R-Y signals are traditionally designated as Cb & Cr or U<\/strong> & V<\/strong>.<\/p>\n\n\n\n

In comparison with the RGB signals typical processing and compression distortions of YUV signals are less noticeable.<\/p>\n\n\n\n

However, it should be noted that in some conditions, e.g. if bit depth is not high enough, the\u00a0 RGB\u21d2YUV\u21d2RGB conversion itself may go wrong, i.e. the\u00a0reconstructed<\/strong> <\/em>RGB images may significantly differ from the original RGB images.<\/p>\n\n\n\n

The scope of the widely used terms\u00a0Y,B-Y,R-Y,\u00a0 YUV,\u00a0YCbCr,\u00a0 YIQ, YDrDb, YPbPr, etc., is ambiguous <\/strong>and overlapping<\/strong>.<\/p>\n\n\n\n

We recommend to use widespread abbreviation YUV,<\/strong>\u00a0 thus ignoring the academic pedants\u00a0claim that the only legal<\/strong> name for this group of digital signals is pretty awkward Y’CbCr.<\/p>\n\n\n\n

However, if necessary, we may and should specify extra details; e.g. slightly longer name\u00a0YUV420p10le<\/strong>\u00a0designates\u00a0420 sampling structure of YUV data, planar memory array format and use of 10 bit little-endian code-word per component.\u00a0<\/em><\/p>\n\n\n\n

By some obscure reasons, rather weird term “pixel format” (pix_fmt) is often used to designate this group of parameters.<\/p>\n\n\n\n

However, even such “extended label” as YUV420p10le does not cover all<\/strong> vitally important parameters of YUV data.<\/p>\n\n\n\n

To get good images at the workflow output we should include in the YUV data specification the specification of RGB data from which they are derived<\/strong>.<\/p>\n\n\n\n

For example:\u00a0HDR-PQ RGB data\u00a0originated<\/strong> in assumption <\/strong>of BT.2020 Primaries and D65 White Point, taken at the output of the color enhancement stage of the production workflow using Master Display in the\u00a0 DCI-P3 Primaries mode. <\/em><\/span><\/p>\n\n\n\n

YUV data specification must<\/strong><\/span><\/span>\u00a0also include description <\/strong>of RGB to YUV conversion<\/strong> parameters<\/strong>.\u00a0<\/span><\/p>\n\n\n\n

For example:\u00a0<\/span>12 bit Full Range RGB data converted to 10 bit Narrow Range YUV data using BT.2020<\/strong> Color Encoding Matrix in its linear Non-Constant Luminance version<\/strong>.<\/span><\/em><\/p>\n\n\n\n

Shall we accept this large group of interrelated parameters as ‘simple, easy and comprehensive description’ of YUV data stream?<\/p>\n\n\n\n

Yes!<\/p>\n\n\n\n

On condition<\/strong> that all these important\u00a0 “birth certificate and life history” details are not included<\/strong> in the YUV label<\/strong> itself, but:<\/p>\n\n\n\n