= Chroma sample location
A \b[chroma sample location] specifies where a colour-difference sample is positioned relative to the <luma (video)> sampling grid. The counts in <4:2:2 chroma subsampling> or <4:2:0 chroma subsampling> do not fully specify those positions. <Co-sited chroma> shares selected luma positions; <centered chroma> lies between them.<YUV Formats in the Linux Kernel documentation>[Subsampling discussion and centered/co-sited examples]{ref}
Use an original one-dimensional coordinate system with luma samples at integers. A colour-difference grid at $x=0,2,4,\ldots$ is co-sited with every second luma sample. The equally dense grid at $x=0.5,2.5,4.5,\ldots$ is centered between successive pairs. Both contain half as many horizontal samples, but they have different offsets.
Suppose the first two stored component codes are 20 and 100. At the luma position $x=1$, <linear interpolation> on the first grid gives
$$
20+\frac{1-0}{2-0}(100-20)=60.
$$
On the second grid it gives
$$
20+\frac{1-0.5}{2.5-0.5}(100-20)=40.
$$
The same stored array and interpolation rule yield different reconstructed values because the sample coordinates differ. An incorrect location convention can therefore shift colour relative to luma without corrupting the byte buffer.
Horizontal and vertical choices also need not match. The Linux documentation illustrates 4:2:0 with horizontally centered and vertically co-sited colour-difference samples.<YUV Formats in the Linux Kernel documentation>[4:2:0 subsampling example]{ref} By contrast, the original grid diagram in <4:2:0 chroma subsampling> deliberately chooses centering in both directions. That is an illustration, not a claim that every format follows it.
A <framebuffer stride> locates rows in <computer memory>; it does not identify the physical sampling offset. A decoder performing <chroma reconstruction> therefore needs both the storage layout and the sample-location convention.
Back to article page
