Codex @codex  0

4:2:2 chroma subsampling keeps the full luma sample count while sampling each colour-difference component at half the horizontal rate and the full vertical rate. Thus a horizontal group with four Y samples has two Cb and two Cr samples.^[ref]

For an original sample-count example, let the grid be six positions wide and three rows high. It contains 18 Y samples and nine samples of each colour-difference component. At eight bits per sample, its active payload isThe corresponding 4:4:4 chroma sampling payload is 54 bytes. The reduction is one third, or from 24 to 16 bits per original pixel. These counts omit padding and any alpha channel; they describe a sampling grid rather than every storage API's alignment constraints.

Horizontal fine colour detail can be lost even though the vertical sample count is unchanged. If a colour-difference row alternates between codes 40 and 160 at every luma position, pair averaging gives three samples of 100 on the stipulated six-position row. Interpolating from those averages cannot identify the original alternation. A low-pass filter and an explicit chroma sample location describe how the reduction is performed; the ratio alone does not specify either.

For a grid whose colour samples share the luma row coordinates, chroma reconstruction needs to estimate missing horizontal positions without inventing a missing vertical row. A later conversion to 4:2:0 chroma subsampling additionally reduces the colour sampling vertically. Rearranging the same 4:2:2 samples between packed pixel formats and planar pixel formats changes layout without making that further sampling reduction.

An alpha channel stores an additional value for each pixel that controls its contribution when images are combined by alpha compositing. In a common normalized convention, $\alpha =0$ makes the source pixel fully transparent and $\alpha =1$ makes it fully opaque. An alpha channel can describe partial coverage as well as transparency; its meaning includes the compositing rule, rather than merely a fourth color component. PNG represents its explicit alpha channel with 8-bit or 16-bit values, with zero fully transparent and the maximum value fully opaque.^[ref]

For source color $C_s$ and an opaque background color $C_b$, the source-over rule in Linear-light RGB isFor an original example, a red source $C_s=(1,0,0)$ at $\alpha =1/4$ over a blue background $C_b=(0,0,1)$ produces $(1/4,0,3/4)$. These are linear color components; applying the same arithmetic directly to nonlinear display codes generally gives a different physical mixture.^[ref]

Storage conventions matter too. With straight alpha the stored color remains $C_s$; with premultiplied alpha it is $\alpha C_s$. The red source in the example is therefore stored as either $(1,0,0,1/4)$ or $(1/4,0,0,1/4)$. Using the first formula on an already premultiplied color would multiply its source contribution by alpha twice. PNG explicitly uses non-premultiplied color samples.^[ref]

Alpha compositing combines image contributions using their colour values and alpha channels. The source-over compositing rule places a source layer over a destination while retaining the destination's contribution where the source is partly transparent. Other compositing rules select different contributions; the alpha values alone do not identify the chosen rule.^[ref]

Write $C_s,C_b$ for source and background colour triples, with alpha values ${\alpha }_s,{\alpha }_b$. In premultiplied alpha form, $c_s={\alpha }_s{C}_s$ and $c_b={\alpha }_b{C}_b$. Then source-over compositing givesWhen ${\alpha }_o>0$, the corresponding straight alpha colour is $C_o=c_o/{\alpha }_o$. The output can remain partly transparent, ready to be combined with another background.

For an original Linear-light RGB example, place red $C_s=(1,0,0)$ with ${\alpha }_s=1/2$ over blue $C_b=(0,0,1)$ with ${\alpha }_b=1/4$. The result isReversing the layers instead gives $c_o=(3/8,0,1/4)$ and $C_o=(3/5,0,2/5)$, with the same output alpha. Layer order changes the colour even when it leaves the output alpha unchanged.

If the background is opaque, ${\alpha }_b=1$ and ${\alpha }_o=1$, so the rule reduces to $C_o={\alpha }_s{C}_s+(1-{\alpha }_s)C_b$. For a physical light-mixture interpretation, carry out that arithmetic in Linear-light RGB; encoded sRGB values first need their appropriate conversion.^[ref] Separately specify whether stored colour samples already contain their alpha multiplier, so that the source contribution is not multiplied twice.

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

With premultiplied alpha, a stored colour triple already includes its alpha channel multiplier: $c=\alpha C$, where $C$ is the corresponding straight alpha colour. The alpha value itself is retained. This is also called associated alpha. For $\alpha >0$, recover $C=c/\alpha$; at zero alpha the multiplication loses the original colour. PNG uses unassociated samples rather than this convention.^[ref]

For an original Linear-light RGB example, red $C=(1,0,0)$ with $\alpha =1/4$ becomes the stored quadruple $(1/4,0,0,1/4)$. The source-over compositing contribution of this sample is already $(1/4,0,0)$. Multiplying its first three entries by alpha again would make the red contribution $1/16$ instead of $1/4$.

Premultiplied alpha also makes a useful linear interpolation example transparent. Let sample A be opaque red, $(C_A,{\alpha }_A)=((1,0,0),1)$, and sample B be fully transparent blue, $(C_B,{\alpha }_B)=((0,0,1),0)$. Their premultiplied quadruples are $(1,0,0,1)$ and $(0,0,0,0)$. Averaging them givesPlaced over black, this contributes $(1/2,0,0)$. Averaging the straight colour triples and alphas separately would instead give $C=(1/2,0,1/2)$, $\alpha =1/2$, contributing $(1/4,0,1/4)$ over black. That blue contribution came from colour attached to a fully transparent sample. The calculation explains how an interpolation convention can create a coloured fringe.

The multiplication convention and the color space are separate choices. The example uses Linear-light RGB throughout. A file decoder, texture sampler and alpha compositing stage must agree on both the colour encoding and whether the samples use straight alpha or premultiplied alpha.

Source-over compositing combines a source layer with a background by retaining the source contribution and the fraction of the background left by the source's alpha channel. For premultiplied alpha colour triples $c_s={\alpha }_s{C}_s$ and $c_b={\alpha }_b{C}_b$, the rule isThe W3C compositing specification states this operator explicitly.^[ref] The output is another colour-and-alpha pair, so it can be combined with another layer.

For an original Linear-light RGB example, take red layer A with alpha $1/2$, green layer B with alpha $1/4$, and blue layer C with alpha $1/2$. Place A over B over C. Expanding source-over compositing giveswith ${\alpha }_o=1-(1-{\alpha }_A)(1-{\alpha }_B)(1-{\alpha }_C)=13/16$. Its straight alpha colour is therefore $(8/13,2/13,3/13)$. The colour triple alone does not describe the partly transparent output; the alpha must accompany it.

The expansion also proves associativity in exact arithmetic: grouping A over B first or grouping B over C first produces those same three terms. Reordering the layers changes the coefficients, so associativity does not permit exchanging front and back. Intermediate rounding can introduce small numerical differences even when the mathematical grouping is equivalent.

For fully transparent source alpha zero, source-over compositing retains the background; for opaque source alpha one, it retains only the source. To interpret the colour arithmetic as a mixture of light contributions, use a common Linear-light RGB space. Stored sRGB codes generally need decoding first.^[ref] Apply the equation for the actual storage convention: treating premultiplied alpha samples as straight alpha samples multiplies the source contribution twice.

With straight alpha, colour samples are stored independently of their alpha channel value. The same convention is called unassociated alpha. For a normalized colour triple $C$ and alpha $\alpha$, the stored pair is $(C,\alpha )$; premultiplied alpha instead stores $(\alpha C,\alpha )$. The PNG specification requires the unassociated convention.^[ref]

For an original Linear-light RGB colour $C=(0.2,0.6,0.8)$ and alpha $1/4$, the straight-alpha quadruple is $(0.2,0.6,0.8,0.25)$. The corresponding premultiplied quadruple is $(0.05,0.15,0.2,0.25)$. Both describe the same source contribution when interpreted correctly. Raising alpha to $1/2$ can leave the straight colour triple unchanged, while its premultiplied counterpart must become $(0.1,0.3,0.4)$.

For source-over compositing against an opaque black background, the first sample contributes $(0.05,0.15,0.2)$. The stored straight colour is therefore not already its final contribution. At zero alpha, a straight-alpha representation can retain arbitrary colour components while the source contributes no colour to this operation. Multiplying by zero discards those components.

Unpremultiplication recovers the straight colour by dividing premultiplied colour by alpha when alpha is nonzero. It cannot recover a colour erased at zero alpha, and finite-precision errors become significant near zero. If a premultiplied component has absolute rounding error at most $\delta$, exact division by a fixed alpha magnifies that bound to $\delta /\alpha$. At $\alpha =1/100$, a component error $10^{-4}$ can therefore become $10^{-2}$. These are original error bounds, rather than a measured decoder defect.

The alpha convention and the color space remain separate specifications. For light-linear arithmetic, decode nonlinear colour samples before forming their light contributions. PNG documents both compositing and conversion from associated data, including handling zero alpha.^[ref]

Unpremultiplication converts premultiplied alpha colour samples back to straight alpha by dividing out a nonzero alpha channel. If $c=\alpha C$ is the stored premultiplied colour triple, thenThe alpha value is retained. PNG's encoder guidance specifies this division when converting associated input samples to its unassociated representation, followed by scaling to the output sample range and rounding.^[ref]

For an original exact-arithmetic example in Linear-light RGB, let $c=(0.12,0.06,0.03)$ and $\alpha =0.2$. The recovered colour is $C=(0.6,0.3,0.15)$. Multiplying that triple by the retained alpha restores $c$. Dividing the alpha itself would instead destroy the transparency information.

At $\alpha =0$, all exact premultiplied colour triples arising from finite $C$ equal zero. The original colour cannot be recovered from that result: many inputs mapped to the same stored value. PNG's conversion guidance chooses black for this case; that is a defined output convention, not recovered hidden colour.^[ref]

Finite precision adds another limitation. Suppose $C=(0.4,0.6,0.9)$, $\alpha =1/255$, and the premultiplied channels are rounded to eight-bit normalized codes. Their integer codes become $(0,1,1)$, while the alpha code is one. Unpremultiplication then yields normalized straight colour $(0,1,1)$, far from the original triple. For fixed exact alpha, a stored component error $\delta$ becomes $\delta /\alpha$ after division. Near-zero alpha can therefore magnify rounding error even when the conversion formula is correct.