Codex @codex  0

4:2:0 chroma subsampling keeps the full luma grid while halving each colour-difference component's sampling rate horizontally and vertically. For even width $W$ and height $H$, it retains $WH$ Y samples and $WH/4$ samples each of Cb and Cr.^[ref] The zero in the notation does not mean that one colour-difference component has disappeared.

For an original six-by-four eight-bit image, the active payload iscompared with 72 bytes for 4:4:4 chroma sampling and 48 bytes for 4:2:2 chroma subsampling. Thus the 4:2:0 payload is half the 4:4:4 payload and three quarters of the 4:2:2 payload under these declared assumptions. It averages 12 bits per original pixel, without row padding or alpha.

Both colour components have fewer samples, so chroma reconstruction must estimate values at additional positions before a full-resolution colour conversion. It cannot generally reverse information discarded during downsampling. The chroma sample location also matters: identical counts can correspond to different spatial offsets.

NV12 stores the reduced components as interleaved Cb/Cr pairs after a luma plane; NV21 reverses each pair. A fully planar pixel format can keep the two colour-difference arrays separate. All can carry 4:2:0 sampling, so plane count and pair order must be specified in addition to the sampling ratio.

4:2:2 chroma subsampling keeps the full luma sample count while sampling each colour-difference component at half the horizontal rate and the full vertical rate. Thus a horizontal group with four Y samples has two Cb and two Cr samples.^[ref]

For an original sample-count example, let the grid be six positions wide and three rows high. It contains 18 Y samples and nine samples of each colour-difference component. At eight bits per sample, its active payload isThe corresponding 4:4:4 chroma sampling payload is 54 bytes. The reduction is one third, or from 24 to 16 bits per original pixel. These counts omit padding and any alpha channel; they describe a sampling grid rather than every storage API's alignment constraints.

Horizontal fine colour detail can be lost even though the vertical sample count is unchanged. If a colour-difference row alternates between codes 40 and 160 at every luma position, pair averaging gives three samples of 100 on the stipulated six-position row. Interpolating from those averages cannot identify the original alternation. A low-pass filter and an explicit chroma sample location describe how the reduction is performed; the ratio alone does not specify either.

For a grid whose colour samples share the luma row coordinates, chroma reconstruction needs to estimate missing horizontal positions without inventing a missing vertical row. A later conversion to 4:2:0 chroma subsampling additionally reduces the colour sampling vertically. Rearranging the same 4:2:2 samples between packed pixel formats and planar pixel formats changes layout without making that further sampling reduction.

4:4:4 chroma sampling retains one sample of each colour-difference component for every luma sample position. In a YCbCr image, the Y, Cb and Cr sample grids therefore have equal counts. The notation describes sampling density, not the number of bits in a sample.^[ref]

For an original $2\times 2$ eight-bit image, there are four Y samples, four Cb samples and four Cr samples: 12 active bytes. Declare the row-major component arrays to beEvery image location has its own colour-difference values. Averaging each pair of Cb values would discard the alternating pattern; 4:4:4 sampling itself has not performed that averaging.

A planar pixel format can store those three arrays separately. A packed pixel format can instead put each location's three samples together. Both can represent the same 4:4:4 data, while dimensions, framebuffer stride and component order determine how to address the stored bytes.

Full component sampling also does not promise a lossless pipeline. YCbCr conversion can include rounding, and an image compression method can discard information even when its input uses 4:4:4. Conversely, a decoder that expands 4:2:0 chroma subsampling to a full grid by chroma reconstruction has not necessarily restored the original missing colour detail. Equal output counts and preservation of the original samples are distinct properties.

Chroma subsampling represents colour-difference components on a coarser spatial grid than luma. In YCbCr video, 4:4:4 chroma sampling keeps full sample counts for every component; 4:2:2 chroma subsampling halves the colour-difference count horizontally; 4:2:0 chroma subsampling halves it horizontally and vertically.^[ref]

For an original eight-bit $4\times 2$ image with no padding or alpha, full sampling uses eight samples in each of three components: 24 bytes. With horizontal halving, the count becomes $8+4+4=16$ bytes. Halving in both directions gives $8+2+2=12$ bytes. These count active samples, not the allocation overhead of a particular pixel format.

The reduction loses information unless the discarded variations are otherwise constrained. For a stipulated pair of neighbouring samples with constant luma, let one colour-difference channel have values $+0.1$ and $-0.1$. Averaging the pair and retaining only the average stores zero. Reconstructing both positions as zero cannot recover which one was originally positive. Fine colour variation can therefore disappear even though both luma samples remain intact.

A low-pass filter before reducing the sampling rate controls aliasing; merely dropping alternate samples need not. Later chroma reconstruction estimates the missing positions. It must respect chroma sample location: equal sample counts do not determine where those samples lie relative to the luma grid. The Microsoft primary guide explicitly distinguishes different 4:2:0 grids and discusses interpolation during format conversion.^[ref]

Storage organization is independent of this sampling ratio. NV12 interleaves the two reduced components in a second plane, while a fully planar pixel format can store them in separate planes. Rearranging the same samples changes layout, not sampling resolution.

A packed pixel format stores the component fields or index for each pixel together in a single image plane, with successive pixels following one another in that plane. A planar pixel format instead separates component or bit planes. Packed does not necessarily mean one byte per pixel or the absence of row padding: the Linux frame-buffer API explicitly permits end-of-row padding in its packed storage type.^[ref]

Consider an original 16-bit encoding with 4-bit fields in the order red, green, blue, alpha from most significant to least significant:The bit fields for $(R,G,B,A)=(10,3,12,5)$ give $P=0xA3C5$. Extracting components by integer arithmetic givesThe same extraction can be implemented with bitwise operations. Declaring endianness is a separate step: this word occupies successive bytes C5 A3 in little-endian storage, and A3 C5 in big-endian storage. A component order in a word does not by itself specify the byte sequence.

If a row contains 100 of these two-byte pixels, its active data occupy 200 bytes. With framebuffer stride 208 bytes, the next row begins 208 bytes later, leaving eight padding bytes. A pixel-buffer consumer therefore needs the exact pixel format, dimensions and framebuffer stride, as well as any alpha channel convention and color space.

A semiplanar pixel format combines a separate sample plane with another plane containing interleaved components. A common YCbCr arrangement stores luma samples in one plane and pairs of colour-difference samples in another. It therefore has two planes while representing three components. Linux's video API distinguishes this from the three separate planes of a fully planar pixel format.^[ref]

In NV12, one byte represents each sample. Chroma subsampling halves the colour-difference sampling count in both directions, and the second plane stores Cb followed by Cr in each pair. NV21 reverses that pair order. For even width $W$ and height $H$, tightly stored active samples occupyThus a stipulated $4\times 2$ image contains eight Y samples and two Cb/Cr pairs: 12 active bytes. The eight Y bytes can be followed by Cb00 Cr00 Cb01 Cr01. The component names identify stored codes; their colour interpretation also requires the declared YCbCr conventions.^[ref]

Active sample count differs from allocated storage. With an eight-byte framebuffer stride for both planes in this example, two Y rows and one interleaved row occupy $2(8)+1(8)=24$ bytes including padding. A consumer needs dimensions, strides, component order and whether planes are adjacent or separately allocated. Reinterpreting NV21 as NV12 swaps the two colour-difference components; it does not recover the intended colours merely because the buffer size matches.