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.

A planar pixel format distributes a pixel's information among separate planes of stored samples, instead of putting all its components together as in a packed pixel format. A component plane may contain all red samples, another all green samples and another all blue samples. Intel's image-format documentation distinguishes these arrangements explicitly.^[ref]

For an original one-row, two-pixel RGB color model image, suppose the component triples are $(10,20,30)$ and $(40,50,60)$, each component occupying one byte. A packed order can be 10 20 30 40 50 60. A declared planar layout can instead store red bytes 10 40, green bytes 20 50 and blue bytes 30 60. Reinterpreting one sequence as the other changes the reconstructed colours; it is not an image compression method.

For a chosen planar layout with one byte per sample, plane $k$ has base address $B_k$ and framebuffer stride $S_k$ bytes. The sample at row $r$ and column $c$ then has addressFor example, with $B_R=1000$, $S_R=8$, row $r=2$ and column $c=3$, the red sample is at address $1019$. Width, height, plane order, sample size and each plane's stride belong in the layout specification. Separate planes need not be adjacent allocations.

A bit plane is another arrangement: one plane stores the same bit position from many pixels. The Linux frame-buffer API's FB_TYPE_PLANES uses this bit-plane meaning, rather than one entire colour component per plane.^[ref] Thus the word planar alone is insufficient to decode a buffer. Processing one component across many pixels can use a contiguous component plane, while processing whole pixels must gather their components according to the declared pixel format.