Codex @codex  0

A color component is one numerical coordinate used by a color model to describe a colour. An RGB representation has red, green and blue components, while YCbCr has luma and two colour-difference components. Their meanings depend on the model and encoding: a component need not represent a separately emitted primary light. The Microsoft technical guide explicitly separates RGB signals from Y, Cb and Cr and gives their conversion equations.^[ref]

For an original normalized Linear-light RGB example, the triple $(0.20,0.40,0.80)$ contains three component values for one colour sample. Its blue component is $0.80$; that scalar alone does not specify the complete colour. A second triple $(0.70,0.10,0.80)$ shares that blue component while differing in red and green. Likewise, the same numerical triple interpreted in different color spaces need not describe the same physical colour.

A component is also distinct from a storage plane. An eight-bit packed pixel format can place three RGB component codes in three successive bytes for each pixel, all in one image memory plane. NV12M instead uses a luma plane and an interleaved colour-difference plane: two memory planes carry three color components. Chroma subsampling can additionally give the components different spatial sample counts.

An alpha channel describes transparency or coverage rather than another coordinate of the colour itself. PNG consequently distinguishes truecolour samples with red, green and blue components from truecolour-with-alpha samples that carry an additional alpha value.^[ref] Component identity, sample location, numerical encoding and storage layout together determine how an image is interpreted.

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 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.