= Packed pixel format
A \b[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.<The Frame Buffer Device API in the Linux Kernel documentation>[§2, FB_TYPE_PACKED_PIXELS, FB_TYPE_PLANES and line_length]{ref}
Consider an original 16-bit encoding with 4-bit fields in the order red, green, blue, alpha from most significant to least significant:
$$
P=2^{12}R+2^8G+2^4B+A,\qquad R,G,B,A\in\{0,\ldots,15\}.
$$
The <bit fields> for $(R,G,B,A)=(10,3,12,5)$ give $P=\mathtt{0xA3C5}$. Extracting components by integer arithmetic gives
$$
R=\lfloor P/2^{12}\rfloor,\quad G=\lfloor P/2^8\rfloor\bmod16,\quad B=\lfloor P/2^4\rfloor\bmod16,\quad A=P\bmod16.
$$
The 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>.
Back to article page
