Pixel format

A 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.^[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: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.^[ref] Report the actual format alongside dimensions and stride when exchanging pixel buffers.