= Pixel format
A \b[pixel format] specifies how stored <bits> represent a pixel value: its components or table index, the allocation of bits to those components, and the applicable representation conventions. A complete image layout also needs dimensions and row organization, including <framebuffer stride>. The Linux frame-buffer API separates storage type from color interpretation and describes component offsets and lengths explicitly.<The Frame Buffer Device API in the Linux Kernel documentation>[Sections2–4, types and visuals; bits_per_pixel and fb_bitfield offset/length]{ref}
For an original <packed pixel format>, place red, green and blue codes in a 16-bit unsigned word $P$, with widths 5, 6 and 5 bits respectively. Declare the red component to occupy bits15–11, green10–5 and blue4–0:
$$
P=2^{11}R+2^5G+B,\qquad
0\leq R,B\leq31,\quad0\leq G\leq63.
$$
These non-overlapping <bit fields> specify a particular encoding. Setting $(R,G,B)=(31,0,0)$ gives $P=63488$, or `0xF800` in <hexadecimal>. Knowing only “16 bits per pixel” would not identify those component positions.
<Endianness> then controls how the word occupies byte-addressed <computer memory>. Little-endian storage of `0xF800` gives successive bytes `00 F8`; big-endian storage gives `F8 00`. Reading the little-endian bytes as a big-endian word instead produces `0x00F8`. Under the same declared component fields, that decodes to $(R,G,B)=(0,7,24)$ rather than $(31,0,0)$. Bit significance in the word and byte order in memory are separate specifications.
Bit allocation also limits representable component codes: the red and blue fields have 32 levels each, while green has 64. If normalized codes are defined as $R/31$, $G/63$ and $B/31$, their respective increments are $1/31$, $1/63$ and $1/31$. These are code increments, not a claim that emitted light varies linearly with the stored number. The <RGB color model> and an appropriate <color space> supply further interpretation.
Other formats can store an <image lookup table> index or include an <alpha channel> for transparency. The frame-buffer documentation likewise distinguishes pseudocolor indices from direct component fields.<The Frame Buffer Device API in the Linux Kernel documentation>[Section2, FB_VISUAL_PSEUDOCOLOR and component-based visuals; section4, transparency and colorspace fields]{ref} Report the actual format alongside dimensions and stride when exchanging pixel buffers.
Back to article page
