Codex @codex  0

A component plane stores samples of one component of an image separately from its other components. A three-plane RGB color model layout can hold a red array, a green array and a blue array, each indexed by image location. Intel's planar-format table records this arrangement explicitly.^[ref] A component plane stores component samples, which can occupy several bits; a bit plane stores only one bit position from each sample.

For an original $2\times 2$ image, takeAt row one, column zero, using zero-based indices, the pixel is $(70,80,90)$. If each component uses one byte and row-major order, the active red bytes are 10 40 70 100. A routine that changes the red component plane can leave the green and blue arrays untouched.

The three active arrays contain $3\cdot 2\cdot 2=12$ bytes. With a separately declared four-byte framebuffer stride for each plane's row, storage instead occupies $3\cdot 2\cdot 4=24$ bytes, including padding. The image values are unchanged. A plane's dimensions, base address and row stride are therefore distinct parts of its layout description.

Other colour representations need not have three equal-sized, separate component arrays. Intel's table includes formats with differently sized planes and formats that interleave two colour components in one plane.^[ref] A semiplanar pixel format combines a separate plane with such an interleaved plane. Thus an API's memory-plane count alone need not equal the number of colour components. A component plane is a statement about data organization, separate from the color space that interprets its numerical samples.

NV12 is an eight-bit YCbCr semiplanar pixel format with 4:2:0 chroma subsampling. A full-resolution plane holds luma samples. The following plane stores alternating Cb and Cr samples, with half as many sample positions in each spatial direction. Linux specifies ordinary untiled NV12 with adjacent planes; the separately allocated variant is NV12M.^[ref]

For even dimensions $W,H$, active samples occupy $WH$ luma bytes plus $WH/2$ interleaved colour-difference bytes. This is $3WH/2$ bytes, or an average of 12 bits per original pixel. It does not give every pixel its own three-component triple: neighbouring pixels share the lower-resolution colour-difference samples.

For an original address calculation, choose width six, height four and an eight-byte framebuffer stride in both planes. Put the first luma row at address 1000. The luma allocation occupies $4(8)=32$ bytes, so the colour-difference plane starts at 1032 and occupies another $2(8)=16$ bytes. There are 36 active bytes in 48 allocated bytes, including row padding.

With zero-based indices, luma position $(r,c)=(3,5)$ is at $1000+3(8)+5=1029$. Its associated subsampled grid cell has indices $(\lfloor r/2\rfloor ,\lfloor c/2\rfloor )=(1,2)$ in this declared layout. That cell's Cb and Cr bytes are at 1044 and 1045. Colour reconstruction additionally needs a sampling-location and filtering convention; these address calculations alone do not specify it.

The pixel format identifies storage. A decoder must also know the YCbCr matrix and code ranges to interpret the numbers as colour.

NV21 is an eight-bit YCbCr semiplanar pixel format using 4:2:0 chroma subsampling. It has a full-resolution luma plane followed by interleaved colour-difference samples in Cr, Cb order. NV12 uses the reverse pair order, Cb, Cr. The separately allocated Linux variant is NV21M.^[ref]

An original $4\times 2$ tightly stored image has eight luma bytes followed by four colour-difference bytes. Suppose the latter are 200 40 150 90. Under NV21, the two pairs are $(C_r,C_b)=(200,40)$ and $(150,90)$. Reading the same bytes as NV12 instead assigns $(C_b,C_r)=(200,40)$ and $(150,90)$. The buffer length remains correct while its colour-difference channels are exchanged.

Converting this declared NV21 buffer to NV12 requires swapping adjacent bytes in the interleaved plane, giving 40 200 90 150, while retaining the luma data. This is a layout conversion, not a conversion to the RGB color model. The numerical colour interpretation still depends on the declared YCbCr encoding.

The active footprint is $3WH/2$ bytes for even width $W$ and height $H$ under eight-bit 4:2:0 sampling. Framebuffer stride can add padding, so the next row need not start immediately after the last active sample. A converter must apply the actual row and plane boundaries: swapping pairs across padding or across the luma plane would corrupt the image rather than exchange the intended channels.

NV21M is a two-memory-plane semiplanar pixel format for eight-bit YCbCr with 4:2:0 chroma subsampling. Like NV21, its colour-difference plane stores Cr before Cb in each pair. Unlike ordinary contiguous NV21, the two image memory planes can have independent allocations.^[ref]

For an original example, stipulate an accepted width-four, height-four layout whose luma plane begins at 1000 with an eight-byte framebuffer stride, while its Cr/Cb plane begins at 5000 with a four-byte stride. Luma position $(3,3)$ is at $1000+3(8)+3=1027$. The corresponding subsampled cell $(1,1)$ has Cr at $5000+1(4)+2(1)=5006$ and Cb at 5007. This ordering is the reverse of NV12M.

The active sample count is $4(4)+2(2)(2)=24$ bytes. The declared allocation sizes are $4(8)+2(4)=40$ bytes because luma rows have padding. Neither 40 nor 24 is an offset that can replace the explicitly supplied second-plane base.

A layout conversion to NV12M can exchange the two bytes in each active colour-difference pair while respecting each plane's stride. It does not require changing luma values or reducing the colour sample count. By contrast, choosing a different YCbCr matrix would be a colour conversion.

The distinction between a multi-planar format and the V4L2 multi-planar API matters here: the interface can carry formats with different memory organizations, while the format identifies which organization the supplied descriptors represent.^[ref]