YCoCg: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
No edit summary
 
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Some modern video codecs (e.g. [[dirac]]) support the YCoCg colorspace. More correctly written this is YC<sub>o</sub>C<sub>g</sub>, with the 'o' and 'g' characters as subscripts. This is what the components represent:
Some modern video codecs (e.g. [[Dirac]], [[H.264|H.264 FRExt]]) support the YCoCg colorspace. The correct written expression for this colorspace is YC<sub>o</sub>C<sub>g</sub>, with the 'o' and 'g' characters as subscripts. It is also called YC<sub>g</sub>C<sub>o</sub>, following the component order found in [[YCbCr]].


    * Y = pseudo luminance, or intensity
== Technical Details ==
    * C<sub>o</sub> = "orange chrominance"
The various components of the name represent:
    * C<sub>g</sub> = "green chrominance"


This colorspace is invented to use similar encoding techniques as for [[YCbCr|YC<sub>b</sub>C<sub>r</sub>]] but with frames in [[RGB]] colorspace.
* Y  = pseudo luma
It is possible to transform lossless from [[RGB]] to YCoCg when two more bits than used for RGB are available for the YCoCg represantation. This way it is possible to lesslessly transform a 30-bit RGB (10 bits for each color) frame into 32 bits in YCoCg and back.
* C<sub>o</sub> = "orange chrominance"
* C<sub>g</sub> = "green chrominance"


Like with [[:Category:YCbCr Formats|YCbCr]] it is also possible to use different sized planes for each component. Thus, every pixel in an image of a YCoCg encodec frame is associated with one Y sample, but possibly groups of pixels share C<sub>o</sub> and C<sub>g</sub> samples.
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.


So this encodings are possible for instance
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 [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/2008_ColorTransforms_MalvarSullivanSrinivasan.pdf on the Kodak image set].
    * YCoCg 4:4:4
 
    * YCoCg 4:2:2
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|YC<sub>b</sub>C<sub>r</sub>]] but with frames in [[RGB]] colorspace.
    * ...
 
=== YCoCg-R ===
 
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 [[:Category:YCbCr Formats|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 C<sub>o</sub> and C<sub>g</sub> samples.
 
Possible encodings include:
* YCoCg 4:4:4, analogous to [[YCbCr 4:4:4]]
* YCoCg 4:2:2, analogous to [[YCbCr 4:2:2]]
* ...
 
== Algorithm ==
 
The algorithm is described in this paper: [http://escher.elis.ugent.be/publ/Edocs/DOC/P105_213.pdf YCoCg(-R) Color Space Conversion on the GPU].
 
And in the [http://diracvideo.org/download/specification/dirac-spec-latest.pdf 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 [https://stackoverflow.com/a/12146329 David Cary].
 
[[Category:Compression Theory]]

Latest revision as of 21:32, 16 July 2023

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

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:

Algorithm

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.