Why would someone want to store images as YCbCr instead of RGB in RAM or in GPU memory?


2 Answers 2


Chroma subsampling is usually used with YCbCr, that makes pics smaller. Say, 512x512 pic in rgb takes 768 kb. While same pic in YCbCr with 4:2:0 subsampling will take 384 kb. Sure, that's good only for photos, or video-like images.
Other reasons might include image processing/analysis, when luma/chroma components needs to be separate.
Or when you play video, and compression scheme involves luma/chroma separation (and optionally subsampling). It's much faster then to compose RGB image in pixel shader, rather than decode pic fully on cpu.

  • \$\begingroup\$ Please show calculation formula for 384KB. Is it used in MPEG? \$\endgroup\$
    – user68854
    Jul 17, 2016 at 9:45
  • \$\begingroup\$ In case of 4:2:0 subsampling, chroma components is twice smaller on each side. So 512x512 pic takes 512*512 bytes for Y, and 256*256 bytes for Cr and Cb. Total would be 512*512+2*256*256 = 384kb. Yes, it is used in MPEG/JPEG/H26x/etc. See en.wikipedia.org/wiki/Chroma_subsampling \$\endgroup\$
    – Vlad
    Jul 17, 2016 at 11:36

Vlad covered the common cases above. There's one other neat way I know of to take advantage of a chroma/luma split for compression, when using GPU-friendly compressed formats like S3TC, so I figured I'd add it on here:

DXT1 compression breaks an image into 4x4-texel blocks, and stores two endpoint colours per block, representing each texel inside as a blend somewhere between these two endpoints.

This can cause errors if, say, the block contains both red and green, each in light and dark varieties. The compressed format can only handle variation along one line in colour space, so about the best the compressor can do is blend between bright green and dark red, getting the wrong colour in places that want dark green or bright red.

DXT1 compressed image from NVIDIA paper linked below

Example of DXT1 cmpression - note colour bleeding & floating reddish texels around the edges of the face and life jacket.

The more heavyweight DXT5 compression stores colour information as DXT1 blocks, but also has an independent alpha channel.

We can use a colour model that splits out luma and chroma components to take advantage of this, storing only chroma information in the DXT1 colour block, and luma information in the alpha block. Now a single 4x4 block of the image can represent colours varying on two axes - the DXT1 block representing shifts in hue/saturation, and the alpha block representing shifts in lightness - better representing areas of the block with separate transitions in both chroma and luma. We also get higher precision devoted to the luma channel, which helps because our vision is more sensitive to luma differences.

Same image compressed with YCoCo DXT5, from NVIDIA paper linked below

Example of using this luma-chroma splitting technique to improve S3TC compression. The result is almost indistinguishable from the uncompressed source image, identical in resolution but one quarter the file size, and can be decoded fully on the GPU (the hardware handling the DXT5 decode, and a simple fragment shader converting back to RGB).

The images above are from this paper from NVIDIA detailing a technique for realtime compression into YCoCg-DTX5. YCoCg isn't exactly the same as YCbCr, but shares the core concept of expressing colours along luma and chroma axes rather than RGB.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .