= Planar pixel format
A \b[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.<Pixel and Planar Image Formats by Intel>[Pixel-Order Image Formats and Planar Image Formats tables, RGB rows]{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 address
$$
A_k(r,c)=B_k+rS_k+c.
$$
For 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.<The Frame Buffer Device API in the Linux Kernel documentation>[§2, FB_TYPE_PLANES and FB_TYPE_INTERLEAVED_PLANES]{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>.
Back to article page
