From MultimediaWiki
Jump to navigation Jump to search

Some modern video codecs (e.g. Dirac, H.264 FRExt) support the YCoCg colorspace. The correct written expression for this colorspace is YCoCg, with the 'o' and 'g' characters as subscripts. It is also called YCgCo, following the component order found in YCbCr.

Technical Details

The various components of the name represent:

  • Y = pseudo luma
  • Co = "orange chrominance"
  • Cg = "green chrominance"

Unlike YCbCr, this colorspace is defined using whole binary fractions, so it is possible to losslessly transform from RGB to YCoCg when using 2 more bits for YCoCg representation than for RGB. E.g., it is possible to losslessly transform a pixel from a 30-bit RGB frame into a pixel in a 32-bit YCoCg 4:4:4 frame and back. This assumes that each R, G, and B component will have 10 bits of information which Y will have 10 bits and Co and Cg will each have 11 bits.

The use of whole binary fractions is a departure from the human vision model, but do remember that YCbCr "luma" was already a departure from the correct luminance formula. This departure does not make YCoCg worse at separating colors into unrelated components: it actually makes more coding gain on the Kodak image set.

In contrast to YCbCr, this colorspace isn't based on the human vision model. This colorspace was invented to use similar encoding techniques as YCbCr but with frames in RGB colorspace.


YCoCg-R is the version that takes fewer (2 extra) bits to be losslessly reversible, as opposed to the original version that took 5 extra bits. In modern encoding standards, only YCoCg-R is ever used, so even if you see "ycgco", it's probably the new one.

It is possible to squeeze a bit harder and use no extra bits, as wraparounds from modulo arithmetic is unambiguous in YCoCg. However, the wraparound causes a discontinuity in the generated components, potentially confusing a codec's predictors and making compression worse. (Remember, YCC pixels is only an intermediate format; making them smaller does not guarantee smaller final sizes!) As a result, no video codec uses this variant.

Possible Formats

Like with YCbCr it is also possible to use different plane sizes (chroma subsampling) for each component. Thus, every pixel in an image of a YCoCg encoded frame is associated with one Y sample, but possibly groups of pixels share Co and Cg samples.

Possible encodings include:


The algorithm is described in this paper: YCoCg(-R) Color Space Conversion on the GPU.

And in the dirac spec in section F.1.5.2.

From RGB to YCoCg:

Co = R - B
 t = B + (Co >> 1)
Cg = G - t
 Y = t + (Cg >> 1)

and back from YCoCg to RGB:

 t = Y  - (Cg >> 1)
 G = Cg + t
 B = t  - (Co >> 1)
 R = Co + B

The three-byte variant is described by David Cary.