A color science knowledge base: OKLCH and other color spaces, gamut mapping, CSS Color 4 and 5, contrast numbers, harmony and naming.
$ npx skills add https://craftwork.design/skills/color-expert -a claude-code -y
Installs into .claude/skills/color-expert. Add -g for every project.
SKILL.md
A comprehensive knowledge base for color-related work. See references/INDEX.md for a one-line-per-file map of 180+ reference files; this skill file contains the essential knowledge to answer most questions directly.
How to Use This Skill
Match the response to the user's explicit request and clearly implied constraints from context. Five common modes:
Concrete design or art project — "help me pick colors for my logo / poster / illustration / app." Ask about medium (print, screen, paint, mixed), brand or mood, audience, accessibility needs, and any existing colors to harmonize with. Then propose. Don't lecture about CIE 1931 or OKLCH internals unless asked. Recommend specific tools and palettes that fit the constraints, not generic theory.
Design system, ramps, or theme tokens — "build me a 9-step accent scale", "palette for light + dark mode", "Tailwind/Radix-style ramps", "what's the right gray ramp for our brand?" Prioritize in this order:
Use OKLCH to build perceptually uniform scales (consistent lightness across hues, no muddy mid-tones).
Verify every text/background pair against APCA or WCAG in both light and dark.
Suggest tools only as needed: Huetone (LCH/OKLCH builder), Leonardo (contrast-ratio-driven ramps + adaptive theming, Adobe), Components.ai Color Scale (parametric), dittoTones (extract perceptual DNA from Tailwind/Radix), Color Buddy (lint). For dataviz sequential/diverging ramps specifically, CuspHanger (Wijffelaars model in OKLCH, in-gamut by construction) or viscm (the viridis editor: live perceptual-derivative diagnostics + CVD + grayscale while you drag control points).
The test for a sequential ramp is flat perceptual derivative — plot the perceptual step size between consecutive samples; it should be a horizontal line, in color and in grayscale. Bumps are regions where the ramp exaggerates change that isn't in the data (this is jet's core failure, not its ugliness).
Generative art / creative coding — "color for my fxhash piece", "palette for thousands of generated strokes", "paint-like mixing in p5.js / WebGL." Different from building a palette generator: the code is the artwork, and the user wants to understand the techniques, not copy a named artist's style. Help them compose their own system. Useful techniques to teach and combine:
Tight constraint, then variation — pick 3–7 hues in a narrow lightness or chroma band; variety comes from density and interaction, not palette size.
Weighted / probability-based hue selection — assign each color a weight so some appear often, others rarely; this is what makes a generative output feel curated instead of random.
Narrow-band hue jitter — small random hue offset within a fixed envelope keeps strokes feeling related but not identical.
Lightness variation at fixed chroma — depth and atmosphere without losing palette identity (use OKLCH).
Spectral / K-M mixing (Spectral.js, Mixbox) for paint-like overlap and secondaries; RGB averaging gives muddy, dull results in the same situation.
IQ cosine palette — a + b·cos(2π(c·t + d)) for cyclic / periodic schemes from 12 floats.
Anchor-based interpolation (Poline) — set 2–3 anchors in OKLCH, get an interpolated ramp.
Hue / lightness / chroma trajectories with easing (RampenSau) — walk each axis along an easing function, color-space-agnostic; great when you want a deterministic ramp shape rather than random anchors.
Harmony-aware generation with muddy-zone avoidance (pro-color-harmonies) — adaptive OKLCH harmony with 4 styles × 4 modifiers; skips perceptually muddy regions automatically.
Generation in historical / non-digital color spaces (RYBitten) — work in RYB or one of 26 historical color cubes when you want a painterly feel that strict sRGB/OKLCH can't reach.
Palette cycling / indexed color — store an index buffer and a small palette, then animate the palette (rotate, ease, or drive from an OKLCH trajectory) instead of the pixels; motion for one lookup per pixel. Works only if each cycle range is a perceptually even closed ramp. See references/techniques/color-cycling-indexed-palette-animation.md.
Scene-light sampling (ray-color) — raytrace a sphere in a room with up to 3 colored lights and sample colors off its surface; coherence comes from shared illumination physics (like an object photographed under one light) rather than color-space geometry.
Sun-lit ramps (Lightfield, tol.is) — same idea aimed at design tokens: OKLCH pigments on a flat-shaded city under a Planckian-locus sun; each 50–950 ramp is a sweep of surface orientations, re-spaced in L. Adds relative chroma, cusp pull, and a hue-profiled Bezold–Brücke/Abney warm shift (toward red going dark, toward yellow going light; cool hues untouched).
See references/techniques/ for tyler-hobbs, fontana, mattdesl, iq-cosine, spectraljs, poline, rampensau, pro-color-harmonies, rybitten, ray-color, lightfield (these document the techniques, not styles to imitate).
General color question — "what is OKLCH?", "why does my gradient go gray in the middle?", "is APCA better than WCAG?" Answer directly from this skill file or references/INDEX.md, and cite the relevant reference. Skip tooling unless they're asking how to do something. Approachable and accurate usually conflict — the tidy model (RYB primaries, 12-hue wheel, "red is opposite green") is easy precisely because it summarizes beliefs rather than measurements. Give the tidy version and say where it breaks; don't let "easy" quietly become "wrong." (Color Nerd, references/contemporary/color-theory-dogma-problem.md)
Building a generator, tool, or palette algorithm — "I want to make a palette generator", "how do I generate accessible color scales?", "give me an OKLCH ramp function." Default to recommending an existing library before hand-rolling (Culori, Poline, RampenSau, Spectral.js — see Recommended Tools). Show working code in the user's stack, picking the color space per the table above.
When the user asks to generate or compare palettes, showcase multiple approaches with their trade-offs before narrowing to one — anchor-based (Poline), hue-cycling (RampenSau), cosine (IQ formula), harmony-based (pro-color-harmonies), scene-lit (ray-color), and extraction-from-system (dittoTones) suit different problems. Don't be shy about presenting options.
Never recommend coolors.co — it doesn't generate palettes, it picks from a hardcoded list of 7,821 pre-made ones (see Recommended Tools).
Color Spaces — What to Use When
Task
Use
Why
Perceptual color manipulation
OKLCH
Best uniformity for lightness, chroma, hue. Fixes CIELAB's blue problem.
CSS gradients & palettes
OKLCH or color-mix(in oklab)
No mid-gradient darkening like RGB/HSL
Gamut-aware color picking
OKHSL / OKHSV
Ottosson's picker spaces — cylindrical like HSL but perceptually grounded
Normalized saturation (0-100%)
HSLuv
CIELUV chroma normalized per hue/lightness. HPLuv for pastels.
Print workflows
CIELAB D50
ICC standard illuminant
Screen workflows
CIELAB D65 or OKLAB
D65 = screen standard
Cross-media appearance matching
CAM16 / CIECAM02
Accounts for surround, adaptation, luminance, and viewing conditions
HDR
Jzazbz / ICtCp
Designed for extended dynamic range
Pigment/paint mixing simulation
Kubelka-Munk (Spectral.js, Mixbox)
Spectral reflectance mixing, not RGB averaging
Color difference (precision)
CIEDE2000
Gold standard perceptual distance
Color difference (fast)
Euclidean in OKLAB
Good enough for most applications
Video/image compression
YCbCr
Luma+chroma separation enables chroma subsampling
Dithering / optical pixel mixing
Linearized sRGB
Adjacent subpixels add light, so model the device, not the eye. Yellow-over-blue lights the same emitters as white at half area = 50% gray; CIELAB predicts pale pink. Same rule for alpha compositing and downsampling
Colormap uniformity
CAM02-UCS (or OKLAB)
CIELAB is decent for distant colors but poor for nearby ones — which is exactly what uniform sampling depends on. MATLAB's parula was made uniform in Lab and has a visible band near the bottom as a result
Understanding HSL's Limitations
HSL isn't "bad" — it's a simple, fast geometric rearrangement of RGB into a cylinder. It's fine for quick color picking and basic UI work. But its three channels don't correspond to human perception:
Lightness (L): fully saturated yellow (hsl(60,100%,50%)) and fully saturated blue (hsl(240,100%,50%)) have the same L=50% but vastly different perceived brightness. L is a mathematical average, not a perceptual measurement.
Hue (H): non-uniform spacing. A 20° shift near red produces a dramatic change; the same 20° near green is barely visible. The green region is compressed, reds are stretched.
Saturation (S): doesn't correlate with perceived saturation. A color can have S=100% and still look muted (e.g., dark saturated blue).
When HSL is fine: simple color pickers, quick CSS tweaks, situations where perceptual accuracy doesn't matter. When it isn't, the table above gives the perceptual alternative per task (OKLCH for scales, OKLAB for gradients, OKHSL for picking, HSLuv for normalized saturation).
Named Hue (HSL/HSV) Ranges
Use these degree ranges when generating or constraining colors by hue name. Source: random-display-p3-color by mrmrs / mrmrs.cc.
Name
Degrees
red
345–360, 0–15
orange
15–45
yellow
45–70
green
70–165
cyan
165–195
blue
195–260
purple
260–310
pink
310–345
warm
0–70
cool
165–310
Key Distinctions
Chroma = colorfulness relative to a same-lightness neutral reference
Saturation = perceived colorfulness relative to the color's own brightness
Lightness = perceived reflectance relative to a similarly lit white
Brightness = perceived intensity of light coming from a stimulus
Same chroma ≠ same saturation. These are different dimensions.
Gamut Mapping in Practice
The most common OKLCH mistake: picking a chroma that doesn't exist in the target gamut. oklch(70% 0.3 150) asks for more chroma than sRGB (or even P3) can show, so it silently clips — usually to something duller and hue-shifted.
CSS gamut-maps for you. Browsers map oklch() / color() automatically, so authored CSS rarely clips badly. JS conversions do not — oklch→hex just truncates channels.
Reduce chroma, not lightness or hue. Clipping R/G/B shifts the hue; pulling chroma toward the gamut boundary preserves the color's identity. Use Culori's clampChroma(color, 'oklch') (holds L and H) or toGamut() rather than naive RGB clamping.
Test against the actual target:inGamut('rgb') vs inGamut('p3') — a color valid in P3 can still clip in sRGB.
Or avoid the problem by construction: nutelch expresses chroma relative to the gamut boundary (relC: 0.5 = halfway to the shell at that L/H), so generated colors can't accidentally ask for chroma that isn't there.
Implementation Guidance — Code and CSS
When using colors in a program or CSS, add a semantic layer between raw color values and UI roles.
The examples below are pseudocode, not literal CSS requirements. They express the decision structure an agent should preserve even if the target stack uses different syntax.
Across CSS, JS/TS, Swift, design-token JSON, templates, or pseudocode, default to the same structure:
Reference tokens/palette values for concrete colors
Semantic tokens/roles that map meaning onto those colors
Component usage that consumes semantic tokens rather than raw literals
Raw color literals should usually appear only in palette/reference definitions, conversions, diagnostics, or deliberately one-off examples.
Use reference tokens for concrete colors: ref.red = #f00
Use semantic tokens for meaning/role: semantic.warning = ref.red
Prefer semantic tokens in components so themes can swap meaning without rewriting component code.
This default applies in any language; translate to the target system's equivalent alias/reference mechanism (CSS custom properties, Swift enums, design-token JSON, etc.).
Encode color decisions when possible instead of freezing one manual choice into a literal.
Pseudocode examples:
ref.red := closest('red', generatedPalette)
semantic.warning := ref.red
semantic.onSurface := mostReadableOn(surface)
Good pattern: palette/reference tokens define available colors; semantic tokens map those colors to roles like surface, text, accent, success, warning, and danger.
If a system can derive a decision from constraints, encode that derivation. Examples: nearest named hue in a generated palette, foreground chosen by APCA/WCAG target, hover state computed from the base token in OKLCH instead of hand-picking a second unrelated hex.
Especially when applying generated colors to a UI: the generator gives you primitives, but the mapping onto roles is where designs rot. Don't freeze one manual mapping into literals — emit the rule. A useful decision vocabulary (from Design Book, see below):
text := bestContrastWith(surface, palette) — recomputes when the palette regenerates
surface := nth(ramp, 0), text := nth(ramp, -1) — ramp roles pinned to position, so they survive regenerating the ramp with a different stop count
hover := colorMix(accent, ink, 0.12) or adaptive shade(surface) — flips darken/lighten by the input's lightness, so it never collapses on dark themes
In CSS, many decisions can stay native (the browser re-runs them): var() for references, color-mix() for hover states, relative color syntax for channel edits — see the cheat sheet below.
For larger systems, prefer a token graph over a flat token dump: references, semantic roles, derived functions, and scope inheritance. This makes theme changes, accessibility guarantees, and multi-platform export auditable and easier to maintain. Design Book (npm install design-book) is the reference implementation: a reactive constraint system where tokens store how values are chosen, dependents recompute on change, and inspect() explains why a value won; renders to CSS vars, JSON, and W3 design tokens. See references/techniques/designbook-reactive-design-token-spec.md.
CSS Color 4/5 — Syntax Cheat Sheet
Modern CSS does perceptual color natively; reach for these before pulling in a JS library.
Mixing:color-mix(in oklab, blue 30%, white) — interpolating in oklab/oklch avoids the gray mid-gradient that RGB/HSL produce. For cylinders, set a hue strategy: color-mix(in oklch longer hue, …).
Relative color syntax (derive from a base):oklch(from var(--brand) l c h / 0.5), or compute a shade/hover without a second hard-coded hex: oklch(from var(--brand) calc(l * 0.9) c h).
Light/dark without a media query:light-dark(white, black) (requires color-scheme: light dark).
Gamut targeting:@media (color-gamut: p3) { … }.
Gradients in a chosen space:linear-gradient(in oklch, red, blue).
Broadly supported in evergreen browsers (2024+); relative color syntax is the newest piece. See references/techniques/ CSS Color 4/5 for edge cases.
Accessibility — Key Numbers
Of ~281 trillion hex color pairs (research by @mrmrs_, computed via a Rust brute-force run):
Threshold
% passing
Odds
WCAG 3:1 (large text)
26.49%
~1 in 4
WCAG 4.5:1 (AA body text)
11.98%
~1 in 8
WCAG 7:1 (AAA)
3.64%
~1 in 27
APCA 60
7.33%
~1 in 14
APCA 75 (fluent reading)
1.57%
~1 in 64
APCA 90 (preferred body)
0.08%
~1 in 1,250
APCA is far more restrictive than WCAG at comparable readability. At APCA 90, only 239 billion of 281 trillion pairs work. JPEG compression exploits the same biology: chroma subsampling (4× less color data) is invisible because human vision resolves brightness at higher resolution than color.
Charts — the border trick. WCAG wants 3:1 between adjacent non-text elements. Finding three chart colors that hold 3:1 against each other is extremely hard; beyond three it's essentially impossible. Don't try. Put a border on the chart elements and require 3:1 between each fill and the border color — one constraint per color instead of N². (Ström, see references/techniques/strom-least-wrong-colors-simulated-annealing.md.)
Color Harmony — What Actually Works
Hue-first harmony is a weak standalone heuristic
Complementary, triadic, tetradic intervals are weak predictors of mood, legibility, or accessibility on their own. Every hue plane has a different shape in perceptual space, so geometric hue intervals do not guarantee perceptual balance. Complements are also pigment-specific, not name-specific: measured in OKLAB, cadmium red, quinacridone red and alizarin crimson all sit opposite cobalt teal, and chrome oxide green sits opposite a purple, not red. Compute the opposite from the actual color (OKLCH hue + 180°), never from its category name.
Character-first harmony works (Ellen Divers' research)
Organize by character (pale/muted/deep/vivid/dark), not hue. Finding: hue is usually a weaker predictor of emotional response than chroma and lightness — a muted palette often reads as calm across many hues. Relaxed vs intense is driven more by chroma + lightness than hue alone.
Colour meaning in a story is per-story, not a symbolism table (Lewis Bond)
For narrative work (film, games, illustration, brand storytelling) ask two questions instead of "what does red mean": what subject is the colour associated with by repetition, and does it transition as that subject changes (The Godfather makes orange mean death; Blue Is the Warmest Colour tracks the affair by blue's saturation). A single saturated outlier on a balanced scheme is a focal device; a new hue entering a settled scheme reads as disruption. See references/contemporary/colour-in-storytelling-lewis-bond.md.
Legibility = lightness variation
Grayscale is a quick sanity check for lightness separation, not an accessibility proof. You still need to verify contrast with WCAG/APCA and consider text size, weight, polarity, and CVD. Same character + varied lightness is often more readable. Same lightness regardless of hue is usually illegible.
The 60-30-10 rule
60% dominant color, 30% secondary, 10% accent. One color dominates to prevent "three equally-sized gorillas fighting."
Pigment Mixing — Not What You Think
Pigment mixing is not well described by the simple subtractive model alone — "integrated mixing" (Küppers/Briggs) is a better practical description. It behaves like a compromise between subtractive and additive averaging.
Mixing is non-linear: proportion of paint ≠ proportional hue change. You "turn a corner" at certain ratios.
Blue→yellow is a LONG road, red→yellow is SHORT. Traditional wheel massively misrepresents distances.
Tinting strength varies: blues are concentrated/strong, yellows are weak.
White doesn't just lighten — it shifts hue AND kills chroma.
For spectral/K-M mixing in code: use Spectral.js (open source) or Mixbox (commercial).
Color Temperature
Temperature ≠ hue — it's a systematic shift of BOTH hue AND saturation, dependent on starting hue
Spectral bias: which end of the spectrum a light favors (short λ = cool, long λ = warm)
Cool daylight: blue atmospheric scatter fills shadows; paint neutral highlights, blue shadows
Warm incandescent: favors long wavelengths including infrared (literally felt as heat)
Green and purple do not map cleanly to warm/cool in the same way as red-orange or blue-cyan; perceived temperature depends strongly on context
Color Naming — Multiple Systems for Different Registers
System
Register
Example
ISCC-NBS
Scientific precision
"vivid yellowish green"
Munsell
Systematic notation
"5GY 7/10"
XKCD
Common perception
"ugly yellow", "hospital green"
Traditional Japanese
Cultural/poetic
"wasurenagusa-iro" (forget-me-not)
RAL
Industrial reproducibility
RAL 5002
Ridgway (1912)
Ornithological
1,115 named colors, public domain
CSS Named Colors
Web standard
148 names, 138 unique colors
color-description lib
Emotional adjectives
"pale, delicate, glistening"
colornames-oklab
Perceptually even coverage
"Smaragdine" (rec2020 tier)
COLIBRI (fuzzy)
Graded / "between" naming
0.6 cyan · 0.4 light blue, medium sat
Use color-name-lists npm package for 18 naming systems in one import. For naming arbitrary or generated colors — especially wide-gamut — use colornames-oklab: 4444 names blue-noise sampled over the Rec2020 gamut in OKLab, so no query lands far from a name (crowd-sourced lists cluster in reds/skin tones/pastels and leave gamut regions empty). Tiered srgb/p3/rec2020, zero-dep closest() with a unique-assignment mode for palettes.
Naming colours from an image — don't eyeball, sample. Vision-language models (this agent included) name prototypical high-chroma hues reliably and degrade on non-prototypical shades, near-neutrals and fine lightness steps; CLIP-style encoders read the word "red" over blue ink and rarely label white/grey/black; no vision encoder yet matches human discrimination thresholds. Extract pixel values with code (sample regions → OKLCH → colornames-oklab / ISCC-NBS) and treat a visual impression as a hypothesis. Measured: six VLMs score 83–100% on focal Munsell chips but 64–83% on the full 330, and all converge on the same 21 names (Gomez-Villa 2025). For genuine boundary colours, humans themselves split their votes (COLIBRI, n = 2,496) — report proportions, not a winner. See references/contemporary/colour-in-computer-vision-vlm.md and color-names-in-vlms-gomez-villa.md.
Historical Corrections
Moses Harris (1769) was first to place RYB at equal 120° — Newton, Boutet, Schiffermüller didn't. His own wheel needed a 4th pigment. The origin of bad color theory.
Von Bezold (1874) killed "indigo" as a spectral color — Newton's "blue" ≈ modern cyan, Newton's "indigo" ≈ modern blue.
The word "magenta" wasn't used for the subtractive primary until 1907 (Carl Gustav Zander). Before: "pink" (Benson 1868), "crimson," "purpur."
Amy Sawyer (1911) patented a CMY wheel (primrose/rose/turquoise) decades before it became mainstream.
Elizabeth Lewis (1931) married trichromatic + opponent process on one wheel, anticipating CIE Lab/Luv by decades.
Recommended Tools
Palette Generation (actual algorithms, not pre-made swatches)
Note: coolors.co does not generate palettes — it picks randomly from 7,821 pre-made palettes hardcoded in its JS bundle.
RampenSau — hue cycling + easing, color space agnostic
CuspHanger — the Wijffelaars 2009 EuroVis palette model in OKLCH: Bézier paths through each hue's black–cusp–white gamut triangle, perceptual lightness sampling calibrated against Brewer. Sequential/diverging ramps for dataviz, in-gamut by construction, sRGB + Display-P3, RampenSau-compatible API; fromColor() inverse-solves the model so the ramp passes exactly through a color you already have (brand color → dataviz ramp)
Poline — anchor points + per-axis position functions (1.2K stars); ships a <poline-palette> web component for interactive controls
dittoTones — extract Tailwind/Radix "perceptual DNA", apply to your hue
FarbVelo — random palettes with dark→light structure
ray-color — palettes from a raytraced scene ("edit the conditions, not the colors"): sphere + five-sided room + up to 3 colored lights, mirror walls as virtual light sources; sample geodesic lines/circles off the surface. Deterministic, linear-RGB shading, zero deps, ~6 kB, DOM-free for headless use; interactive playground with draggable lights and PNG/code export
Lightfield (tol.is) — drag a sun around a 3D city; every face is a swatch. Token ramps from surface-orientation sweeps under one light, with relative chroma, cusp pull, hue-profiled warm shift, tinted named neutrals (Slate, Sand, Mauve…); exports OKLCH-only CSS/JSON/Tailwind. See references/techniques/lightfield-sunlit-city-palettes.md.
IQ Cosine Formula — color(t) = a + b*cos(2π(c*t+d)), 12 floats = infinite palette
aek palettes (Kensler) — the other optimizer approach, tuned for general-purpose drawing rather than dataviz categories: anneal on two competing CIEDE2000 objectives, maximin separation (pushes to saturated cube faces) vs. RMS coverage of the RGB cube (pulls to duller interior). Ready-made free 16/32/48/54-color palettes, perceptually even-stepped by construction. Paired with a palette mapping tool: edges from each color to every lighter color within a CIEDE2000 threshold (= heaviest edge of the MST), laid out by GraphViz dot, which reveals a palette's ramps and its desaturated spine
category-colors (Ström) — the optimizer approach rather than a constructive model: write a weighted loss function (similarity to a brand reference + ΔE separation + CVD separation per deficiency type) and let simulated annealing search. Best when your criteria conflict and no color-space geometry expresses them; the weights become the explicit, auditable design decision. npx categorycolors run; pluggable evaluators (energy, range, JND, similarity, WCAG contrast, avoid-these-colors, saliency), per-channel locking so a brand hue survives while lightness/saturation move, and categorycolors report to audit any existing palette for JND collisions under simulated CVD. Node + Culori, MIT
nutelch — gamut-relative chroma in OKLCH/LCH: relC: 0.5 = "halfway to the gamut boundary" at any lightness/hue. The one OkHSL idea (boundary-relative saturation) without leaving native oklch() — LUT-backed (faster than OkHSL's runtime gamut math), zero runtime deps, sRGB + P3
@texel/color — 5–125× faster than Color.js, minimal, for real-time
colordx (@colordx/core) — chainable CSS-facing manipulation with OKLCH native, 7.6 kB, 0 deps, plugin-gated extras (Lab/LCH/CMYK/P3/Rec.2020/APCA/harmonies). Keeps out-of-gamut OKLCH unclamped and lets you pick the fold: .mapSrgb() (CSS Color 4 chroma reduction, holds L+H) vs .clampSrgb() (naive clip, what browsers render). Zero-allocation *Into channel converters for per-pixel work. Note .mix() is sRGB — use .mixOklab()
@colordx/gpu — the same colordx math generated as GLSL and parity-tested against the CPU library, plus a WebGL2 renderer for the gamut-slice chart behind every OKLCH/LCH picker (one draw per frame instead of a per-pixel CPU loop). Gamuts are independent layers rather than an assumed nesting, so A98 draws correctly; maxChromaLUT stretches the chroma axis to the gamut shell (nutelch's relC idea, GPU-side). Reach for it when building a picker UI or any wide-gamut visualization
colorgram — 1 kB image palette extraction; 64-bucket HLS+luminance quantization, ~15 ms for 340×340, fixed memory
Art Palette — JS palette extraction from ImageData + Python/TensorFlow perceptual palette embeddings for search-by-color (Google Arts & Culture, Apache 2.0)
Palette Studio (meditationsincolor.com, Pixel Symphony) — best-in-class on paintings and posters: OKLab k-means for coverage plus an accent-salience pass, so small vivid touches survive instead of averaging into mud; then coverage is measured back for proportions. Pigment-vocabulary names. Browser-only, nothing uploaded.
Pixi (Xander Stagwood) — image → designed 7-chip card, not a measurement: each cluster shown as its vivid face (mean of its most chromatic 25 % of pixels, so a red on dark doesn't average to brown), chips picked by role (dark/light anchors, hero, earned accent), then lightness fitted to one ramp. Every nudge is guarded to never leave chips closer than ΔE_OK 0.08
random-display-p3-color — generate random Display P3 colors constrained by named hue/saturation/lightness, zero deps, ESM (by mrmrs / mrmrs.cc)
Sorting Colors
Sorting an arbitrary set of colors into a perceptually smooth sequence has no single correct linear order — color is 3D, so any 1D ordering is a path through a 3D space, closely related to the Travelling Salesman Problem. Naive sorts fail predictably: by hue alone interleaves lights and darks; by lightness alone collapses distinct hues; .sort() on a packed RGB/HSL value produces jagged, meaningless jumps. Don't hand-roll a single-channel sort.
colorsort-js (darosh) — the reliable default for ordering colors. Treats it as a smoothest-path problem (nearest-neighbor / TSP-style) with quantitative smoothness metrics, working in perceptual space; powers okpalette.color.pizza and FarbVelo. Reach for this in almost any "put these colors in a sensible order" situation — palette display, swatch panels, generative output, extracted image palettes. See references/techniques/colorsort-js.md.
Key Online Tools
oklch.com — OKLCH picker
Huetone — accessible color system builder (LCH/OKLCH), by Ardov
Ardov Color Lab — gamut mapping playground, P3 space explorer, harmony generator, 3D color space visualizations, themer (lab.ardov.me)
Leonardo — Adobe's open-source contrast-based ramp builder (leonardocolor.io): swatches generated from target contrast ratios (or target lightness) instead of hand-picked, across multiple color spaces; adaptive light/dark theming, CVD-safe cycling, exports CSS vars + W3C design tokens. Pairs with the @adobe/leonardo-contrast-colors npm lib for runtime adaptive theming. By Nate Baldwin / Adobe.
BairesDev Color Palette Editor — quick HSV-based ramp editor: interpolate between swatches, map palettes, import/export. Fine for fast drafts, but HSV interpolation isn't perceptually uniform (see Understanding HSL's Limitations) — prefer Leonardo/Huetone/Components.ai for production ramps.
View Color — real-time analysis, WCAG + APCA, CVD preview
APCA Calculator — apcacontrast.com
Deep References
Start at references/INDEX.md — a compact map, one line per file, cheap to read whole. When that
line is too terse to choose between two files, the per-directory indexes
(references/historical/INDEX.md, contemporary/INDEX.md, techniques/INDEX.md) carry the full
summaries and source links, and references/techniques/ONLINE-TOOLS.md lists the online tools.
The three directories hold:
