Planar pixel format

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.

A bit plane collects one fixed bit position from every integer sample of a digital image. For an unsigned $n$-bit sample $p$, define its plane-$k$ entry byEach bit plane contains binary entries, while the powers of two determine their contribution to reconstruction. The Linux frame-buffer API uses this organization for FB_TYPE_PLANES, where plane $k$ stores bit $k$ of the pixel samples.^[ref]

For an original four-pixel row $(3,5,10,12)$ stored as four-bit unsigned samples, the bit planes from most significant to least significant areThe third pixel reconstructs as $8\cdot 1+4\cdot 0+2\cdot 1+1\cdot 0=10$. The same operation applies independently to every location in an image; bit-plane slicing extracts those binary images for inspection or processing.

If only the two most significant bit planes are retained, this row reconstructs as $(0,4,8,12)$. In general that truncation gives $4\lfloor p/4\rfloor$, so the discarded remainder lies between zero and three. This is a statement about integer code values; a nonlinear color space can make equal code changes correspond to unequal light changes.

A bit plane differs from a component plane. One eight-bit red component plane can itself be decomposed into eight bit planes. State the component encoding, bit significance and layout before combining planes; the visible binary pattern alone does not identify its significance. Bit planes need not form a progression from smooth shapes to noise for arbitrary images.

Bit-plane slicing extracts the same bit position from every integer sample of a digital image, producing one binary image per bit plane. For an unsigned $n$-bit sample $p$ and $0\le k<n$,Equivalently, bitwise AND with the mask $2^k$ isolates that position, and a bit shift or nonzero test converts it to zero or one. Linux's frame-buffer API describes the underlying bit-plane storage convention as plane $k$ carrying bit $k$ of every sample.^[ref]

For an original four-bit sample $p=13$, the binary digits are $1101$: the planes have $(b_3,b_2,b_1,b_0)=(1,1,0,1)$. Their contributions reconstruct $8+4+0+1=13$. Displaying each plane as a black-and-white image makes its pattern visible, but does not give every plane equal numerical significance.

Keeping only planes three and two gives $\hat{p}=4\lfloor p/4\rfloor$. The discarded remainder satisfies $0\le p-\hat{p}\le 3$, by integer division. A one-unit change from seven to eight nevertheless flips every one of the four bits, so the binary patterns need not vary smoothly as intensity codes change. Nor is a low bit plane automatically noise: it can encode a deliberately structured pattern, as the example shows.

Slicing is an operation on the stated integer encoding. Applying it to a floating-point number's stored bit pattern examines sign, exponent and fraction fields rather than the same unsigned intensity significance. The sample type and pixel format therefore belong in the definition of the operation.

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.