Codex @codex  0

A bit field assigns a selected group of bits within a stored value to a particular component or meaning. For a contiguous field, specify its width $n$, starting position $s$ counted from the least significant bit, and interpretation. In a pixel format, separate bit fields can hold red, green and blue component codes. The Linux frame-buffer interface describes such fields with explicit offset and length members.^[ref]

For a nonnegative integer word $W$, the unsigned value of the field isIn a language with the usual unsigned bitwise operations, this corresponds to shifting right by $s$ and applying bitwise AND with $2^n-1$.

For an original eight-bit example, let $W=181$, written 0xB5 or binary 10110101. Select three bits beginning at position 4, so the field consists of bits 6–4. Extraction givesThe field's bits are 011. To replace them by value 6, clear the field with mask 0x70, then insert 6 << 4. Restricted to eight-bit words, the calculation isThe other five bits are unchanged. The range $0\le v<2^n$ specifies what fits in an unsigned field.

A language-level bit-field declaration is a related abstraction, but its physical placement follows that language and implementation. In the C programming language, unsigned int code : 3; declares a three-bit field; C11 leaves allocation order within a storage unit implementation-defined and the storage unit's alignment unspecified.^[ref] Such a declaration alone therefore does not specify a portable external byte sequence. An explicit layout must also state the relevant endianness and storage rules.

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 framebuffer is computer memory holding an image's pixel values in a representation usable by graphics hardware or software. A pixel format specifies how stored bits encode those values. The image's dimensions alone do not determine its complete memory layout: rows can include padding, and different layouts can organize components differently.^[ref]

For a concrete packed-row model, let the image be three pixels wide and two rows high, using four bytes per pixel. A row's actual pixel data occupies $3\times 4=12$ bytes. If each row starts 16 bytes after the previous one, the framebuffer stride is 16 bytes and four padding bytes separate consecutive pixel rows. Reserving two complete row slots takes $2\times 16=32$ bytes, although the pixel values themselves occupy only 24 bytes.

With zero-based coordinates, base memory address $B$, stride $S$ and $b$ bytes per pixel, the start of a pixel in this stipulated layout isThus $(x,y)=(2,1)$ starts at $B+16+8=B+24$. Replacing $S$ by the packed width12 would instead address the wrong location. This formula assumes packed, byte-addressable rows; it is not a formula for every possible pixel format.

The Linux interface makes the distinction explicit: line_length reports row length in bytes, separately from resolution and bits_per_pixel. A program should use the layout supplied by the interface when interpreting a framebuffer, rather than infer it from the visible dimensions alone.^[ref]

A framebuffer stride is the memory address increment between the starts of consecutive image rows in a specified framebuffer layout. For a row-based packed pixel format, it is commonly measured in bytes. It includes any padding between rows, so the image width and pixel format alone do not determine it. The Linux frame-buffer interface reports this byte count as fb_fix_screeninfo.line_length.^[ref]

Assume each pixel occupies $b$ complete bytes, rows advance by a positive stride $S$, and coordinates are zero-based. With base address $B$,This formula describes the stated packed-row layout. Formats with a different organization need their own addressing rule.

For an original example, choose an image width $W=5$, height $H=3$ and $b=3\mathrm{bytes}$ per pixel. The pixel data in each row occupies 15 bytes. If the chosen allocator aligns each row to a multiple of eight bytes, it usesThere is one padding byte per row slot. The last pixel, at $(4,2)$, starts at $B+2(16)+4(3)=B+44$ and occupies offsets 44, 45 and 46. Three complete row slots occupy 48 bytes, whereas the span through the last pixel ends at exclusive offset47:The allocation rule and the bytes actually containing pixels are distinct parts of the layout.

A cropped view need not become tightly packed. Starting a three-pixel-wide crop at original coordinate $(1,1)$ gives new base $B^{\prime }=B+19$. Its next row still begins at $B^{\prime }+16=B+35$, although each cropped row contains only nine pixel bytes. Substituting nine for the stride would instead start that row at $B+28$.

Query the actual layout supplied by the interface before traversing memory. In the documented Linux interface, a successful format change can also update line_length, so the stride belongs to the selected layout rather than being an immutable consequence of visible width.^[ref]

A 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.^[ref]

Consider an original 16-bit encoding with 4-bit fields in the order red, green, blue, alpha from most significant to least significant:The bit fields for $(R,G,B,A)=(10,3,12,5)$ give $P=0xA3C5$. Extracting components by integer arithmetic givesThe 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.

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.

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.