Color Spaces

A color space is a specification of a coordinate system, together with a mapping, that lets a numeric tuple correspond to a unique physical or perceptual color. Because human color vision is trichromatic — the retina has three classes of cone cells with overlapping spectral sensitivities — any color humans can distinguish can be matched by mixing just three suitably chosen primary lights. This is why color spaces are almost always three-dimensional: RGB uses three primaries directly, HSV re-parametrizes those same three numbers cylindrically, and CIE-based spaces use three standardized "imaginary primaries" (X, Y, Z) fit to human perception. The key distinction to internalize is between device-dependent and device-independent spaces. RGB, as stored in a JPEG or read from a camera sensor, is device-dependent: the actual color a pixel value `(255, 0, 0)` produces depends on the display's specific red phosphor or LED. HSV is derived from RGB, so it inherits this device dependence — it is a reparametrization, not a perceptual correction. CIE XYZ, by contrast, is defined directly from the 1931 CIE standard observer color-matching functions, making it device-independent: a given XYZ triple denotes the same physical color regardless of the display. CIE Lab is a nonlinear remapping of XYZ specifically engineered so that Euclidean distance in Lab space approximates perceived color difference (this approximate perceptual uniformity is Lab's entire reason for existing). A second key distinction is additive vs. subtractive mixing. RGB (and XYZ) are additive: combining wavelengths of light adds their intensities, matching how screens and the human eye work. CMYK is subtractive, modeling how inks absorb light — relevant for printing but not covered further here since it is not camera- or display-native. This article focuses on the three families most relevant to computer vision pipelines: RGB (sensor/display native), HSV/HSL (intuitive, hue-based), and CIE XYZ/Lab (perceptually motivated).

The RGB cube

RGB represents a color as a weighted additive mixture of red, green, and blue primaries, each in `[0, 1]` (or `[0, 255]` for 8-bit images). Geometrically, all representable colors form a unit cube: `(0,0,0)` is black, `(1,1,1)` is white, and the main diagonal between them is the achromatic (gray) axis. RGB is what a camera sensor produces (after demosaicing a Bayer filter) and what a display consumes directly, so it requires no conversion for capture or rendering — its cost is that "distance" in the cube does not track perceived similarity, and brightness, saturation, and hue are all tangled together in every channel.

RGB → HSV

HSV (Hue, Saturation, Value) re-expresses the RGB cube as a cylinder, separating what color (hue), how pure (saturation), and how bright (value). Given normalized `R, G, B ∈ [0,1]`: ``` function RGB_to_HSV(R, G, B): Cmax = max(R, G, B) Cmin = min(R, G, B) Delta = Cmax - Cmin // --- Hue --- if Delta == 0: H = 0 // undefined hue; convention: 0 else if Cmax == R: H = 60 (((G - B) / Delta) mod 6) else if Cmax == G: H = 60 (((B - R) / Delta) + 2) else: // Cmax == B H = 60 * (((R - G) / Delta) + 4) if H < 0: H = H + 360 // keep hue in [0, 360) // --- Saturation --- if Cmax == 0: S = 0 // pure black: undefined, convention 0 else: S = Delta / Cmax // --- Value --- V = Cmax return (H, S, V) ``` The intuition: `V = Cmax` says brightness is dominated by the strongest color channel. `S = Delta / Cmax` measures how far the color is from gray relative to its brightness — if `R=G=B`, `Delta=0` and the color is perfectly gray (`S=0`), regardless of how bright it is. Hue is computed by figuring out which primary dominates and using the relative imbalance of the other two to place the color on a 360° wheel (0°=red, 120°=green, 240°=blue), with `60×` scaling because each of the six "sectors" of the wheel spans 60°.

HSV → RGB

The inverse recovers RGB from `(H, S, V)`: ``` function HSV_to_RGB(H, S, V): C = V S // chroma Hp = H / 60 X = C (1 - abs(Hp mod 2 - 1)) if 0 <= Hp < 1: (R1,G1,B1) = (C, X, 0) else if 1 <= Hp < 2: (R1,G1,B1) = (X, C, 0) else if 2 <= Hp < 3: (R1,G1,B1) = (0, C, X) else if 3 <= Hp < 4: (R1,G1,B1) = (0, X, C) else if 4 <= Hp < 5: (R1,G1,B1) = (X, 0, C) else: (R1,G1,B1) = (C, 0, X) m = V - C return (R1 + m, G1 + m, B1 + m) ```

RGB → XYZ → Lab

Perceptual spaces require two stages. First, linearize the RGB (undo gamma/sRGB companding), since standard 8-bit RGB values are nonlinear (perceptually, not physically, uniform): ``` function inverse_gamma(c): // c in [0,1], sRGB companding if c <= 0.04045: return c / 12.92 else: return ((c + 0.055) / 1.055) ^ 2.4 ``` Then apply the fixed linear transform (sRGB, D65 white point) to get device-independent CIE XYZ: ``` function linearRGB_to_XYZ(r, g, b): X = 0.4124r + 0.3576g + 0.1805b Y = 0.2126r + 0.7152g + 0.0722b Z = 0.0193r + 0.1192g + 0.9505b return (X, Y, Z) ``` Note `Y` alone is the standard relative luminance — this is why grayscale conversion from RGB commonly uses weights close to `(0.21, 0.71, 0.07)`, not a naive average. Finally, XYZ is nonlinearly warped into <strong>Lab</strong>, using a reference white point `(Xn, Yn, Zn)`: ``` function f(t): delta = 6/29 if t > delta^3: return t ^ (1/3) else: return t / (3 delta^2) + 4/29 function XYZ_to_Lab(X, Y, Z, Xn, Yn, Zn): fx = f(X / Xn) fy = f(Y / Yn) fz = f(Z / Zn) L = 116 fy - 16 a = 500 (fx - fy) b = 200 * (fy - fz) return (L, a, b) ``` `L` (0–100) is perceived lightness, `a` runs green(−) to red(+), and `b` runs blue(−) to yellow(+). The cube-root-like `f` compresses large values and linearizes near black, mimicking how human perception compresses brightness differences roughly logarithmically (a form of Weber–Fechner scaling) — this is exactly what makes Euclidean distance in Lab approximate the perceived color difference, unlike raw RGB or XYZ distance.

Time complexity. Every conversion described — RGB↔HSV, RGB→linear→XYZ→Lab — is a fixed, closed-form function of at most three input numbers, using only comparisons, arithmetic, and a constant number of transcendental calls (one cube root, one power, in the perceptual pipeline). Each per-pixel conversion is therefore `O(1)`. Applying a conversion to an image of `n = W×H` pixels costs `O(n)` time, since each pixel is processed independently and exactly once, and this is optimal: any algorithm that must inspect every pixel's color at least once needs `Ω(n)` time.

Space complexity. All conversions can be done in place or with one output buffer of the same size as the input, giving `O(n)` space for a full-image conversion, or `O(1)` auxiliary space beyond the input/output buffers (no data structure grows with problem size, no recursion, no auxiliary arrays beyond the image itself).

Correctness of RGB↔HSV. The HSV formulas are not approximations; they are an exact geometric re-derivation of the RGB cube in cylindrical coordinates. The chroma `Delta = Cmax − Cmin` measures the "spread" of the three RGB values, which is zero exactly on the gray diagonal and increases with distance from it — this is precisely the geometric definition of saturation as distance from the achromatic axis, scaled by `Cmax` to normalize for brightness. The hue formula partitions the RGB cube's six triangular faces (each corresponding to one channel being max) into six 60°-wide sectors; the piecewise `60×(...)` expressions are the unique way to make hue continuous across the sector boundaries, so that as `R,G,B` sweep the boundary between two dominant channels, `H` changes smoothly rather than jumping. Applying `HSV_to_RGB` after `RGB_to_HSV` reproduces the original `(R,G,B)` up to floating-point rounding, which is a direct algebraic check: substituting the sector definitions back and simplifying `C`, `X`, `m` recovers `Cmax`, `Cmin`, and the middle value exactly.

Correctness of RGB→XYZ→Lab. The RGB→XYZ matrix is not derived by the algorithm; it is a fixed change-of-basis matrix determined once by colorimetric measurement (matching the sRGB primaries and D65 white point against the CIE standard observer). Its correctness is empirical/definitional, not something to "prove" — it is by definition the transform that makes XYZ agree with the standardized human color-matching data. The nonlinearity `f(t)` in the Lab step is designed (and, again, fixed by the CIE standard) so that equal Euclidean steps in `(L,a,b)` correspond approximately to equal steps in human-perceived color difference; this is validated empirically via datasets of human-judged "just noticeable differences," not derived from first principles — hence Lab is only approximately perceptually uniform, a caveat worth remembering.

Tradeoffs. RGB costs nothing to obtain (it's what the sensor delivers) but its "distance" is not meaningful perceptually. HSV is nearly free to compute and dramatically better for intuitive tasks like "find pixels that are reddish, regardless of brightness," but it inherits every calibration flaw of the underlying RGB (it is a coordinate change, not a color correction) and it has a hue wraparound problem: hue is circular (0° and 360° are identical), so naive averaging or thresholding across the 0°/360° seam silently fails. Lab is the most perceptually meaningful but costs a matrix multiply and two nonlinear function evaluations per pixel, and it depends on knowing the display's gamma and white point, information not always reliably available from consumer images.

Take a muted "brick red" pixel, `RGB = (178, 34, 34)` in 8-bit, i.e., `(0.698, 0.133, 0.133)` normalized.

Step 1 — HSV. ``` Cmax = 0.698 (R), Cmin = 0.133, Delta = 0.565 Cmax == R, so: H = 60 (((G - B)/Delta) mod 6) = 60 ((0/0.565) mod 6) = 60 * 0 = 0° S = Delta / Cmax = 0.565 / 0.698 ≈ 0.809 V = Cmax = 0.698 ``` So `HSV ≈ (0°, 0.81, 0.70)` — pure red hue, high saturation, moderately bright. This matches intuition: brick red is a saturated, mid-bright red.

Step 2 — XYZ (with sRGB linearization). Applying `inverse_gamma` to each channel (all above the 0.04045 threshold):

Then: ``` X = 0.41240.4385 + 0.35760.0157 + 0.18050.0157 ≈ 0.1899 Y = 0.21260.4385 + 0.71520.0157 + 0.07220.0157 ≈ 0.1057 Z = 0.01930.4385 + 0.11920.0157 + 0.9505*0.0157 ≈ 0.0253 ```

Step 3 — Lab. Using D65 white `(Xn, Yn, Zn) ≈ (0.9505, 1.0, 1.089)`: ``` X/Xn ≈ 0.1998, Y/Yn ≈ 0.1057, Z/Zn ≈ 0.0232 f(0.1998) ≈ 0.585, f(0.1057) ≈ 0.472, f(0.0232) ≈ 0.285 (all > delta^3 ≈ 0.0083, use cube root branch) L = 1160.472 - 16 ≈ 38.8 a = 500(0.585 - 0.472) ≈ 56.5 b = 200*(0.472 - 0.285) ≈ 37.4 ``` So `Lab ≈ (38.8, 56.5, 37.4)`: a mid-low lightness (dark-ish), strongly positive `a` (toward red), positive `b` (toward yellow) — consistent with a dark, warm red. Compare a second color, "tomato" `RGB = (255, 99, 71)`, which a naive RGB-distance computation might call "very different" from brick red because the green and blue channels differ by 65 and 37 respectively, while Lab distance (worked the same way) correctly reports these as much closer in perceived color than, say, brick red versus a dark forest green with a similar RGB "distance."

The point of the table: RGB distance ranks these two comparisons as nearly identical, while Lab distance — designed for this purpose — correctly separates "same hue family" from "different hue family," illustrating exactly why perceptual spaces exist.

The scientific foundation of all modern color spaces is the CIE's 1931 standardization of human color matching, built on decades of trichromatic color-matching experiments tracing back to Thomas Young and Hermann von Helmholtz in the 19th century, and formalized by the color-matching experiments of W. David Wright and John Guild that the CIE committee synthesized. HSV-style hue/saturation/value models were popularized in computer graphics in the 1970s, notably by Alvy Ray Smith, as an interface designed for artists and programmers who found RGB unintuitive to manipulate directly.

Color spaces are load-bearing infrastructure across nearly every image-based system. Digital cameras and image sensors capture in a Bayer-filtered RGB-like space and apply gamma correction before storing sRGB JPEGs — the exact linearization step used above. Video codecs (JPEG, MPEG, H.264) convert RGB to YCbCr, a luma/chroma space closely related in spirit to HSV, because separating luminance from chrominance lets encoders compress color information more aggressively than brightness, exploiting the fact that human vision is less sensitive to chroma detail. Print pipelines convert through Lab as a device-independent intermediate when mapping between very different RGB and CMYK gamuts. Computer vision segmentation and tracking systems (including classic and modern skin-detection, traffic-light detection, and industrial color-sorting pipelines) routinely convert to HSV specifically to threshold on hue while ignoring lighting-induced brightness swings. Perceptual color spaces underlie automated image-quality metrics, color-consistency checks in printing and manufacturing, and the "color difference" (ΔE) formulas used in textile, paint, and display calibration industries. Every one of these systems depends on the same idea developed here: pick coordinates for color so that the operation you care about (compress, threshold, compare, print) becomes geometrically simple in those coordinates — a principle that carries directly into how Image Histograms are built (per-channel vs. hue histograms) and how Point Operations like contrast stretching are applied per-channel or per-value depending on the chosen space.

Ask the tutor: Why does converting a shadowed region of an image often shift its hue in HSV even though the object's true color hasn't changed?