color-expert

色彩专家

一个全面的色彩相关工作知识库。请参阅 references/INDEX.md，其中按每个文件一行列出了 180 多个参考文件；此技能文件包含了直接回答大多数问题所需的核心知识。

如何使用此技能

根据用户的明确要求和上下文中清楚暗示的约束调整回复。常见模式有五种：

具体的设计或艺术项目——“帮我为徽标／海报／插画／应用挑选颜色。”询问媒介（印刷、屏幕、颜料或混合）、品牌或氛围、受众、无障碍需求，以及需要协调搭配的现有颜色，然后再提出建议。除非用户主动询问，否则不要讲解 CIE 1931 或 OKLCH 的内部原理。根据具体约束推荐合适的工具和调色板，而不是泛泛讲理论。

设计系统、色阶或主题令牌——“为我构建一个 9 阶强调色阶”“浅色 + 深色模式的调色板”“Tailwind/Radix 风格的色阶”“什么样的灰色色阶适合我们的品牌？”按以下优先顺序处理：

• 使用 OKLCH 构建感知均匀的色阶（不同色相的亮度一致，不会出现浑浊的中间色调）。
• 构建令牌关系图：引用令牌（调色板）→ 语义令牌（表面、表面上文字、强调色、成功、警告、危险）→ 组件用法；请参阅下文的 实现指南。
• 使用 APCA 或 WCAG 检查浅色和深色模式下每一组文字／背景搭配。
• 仅在需要时推荐工具：Huetone（LCH/OKLCH 构建器）、Leonardo（由对比度比驱动的色阶 + 自适应主题，Adobe）、Components.ai Color Scale（参数化工具）、dittoTones（提取 Tailwind/Radix 的感知特征）、Color Buddy（代码检查工具）。专用于数据可视化的顺序色阶／发散色阶时，可使用 CuspHanger（在 OKLCH 中采用 Wijffelaars 模型，通过构建确保色域内）或 viscm（viridis 编辑器：拖动控制点时实时诊断感知导数 + CVD + 灰度）。

顺序色阶的检验标准是感知导数平坦——绘制相邻样本之间的感知步长，应呈水平线，并且在彩色和灰度下都如此。凸起表示色阶夸大了数据中并不存在的变化区域（这是 jet 的核心缺陷，而非它不美观）。

生成艺术／创意编程——“为我的 fxhash 作品选色”“为数千条生成笔画设计调色板”“在 p5.js / WebGL 中实现颜料般的混色。”这与构建调色板生成器不同：代码本身就是艺术作品，用户想了解的是技法，而不是照搬某位知名艺术家的风格。帮助他们构建自己的系统。可教授并组合的实用技法包括：

• 先严格约束，再增加变化——选取 3–7 种明度或彩度范围较窄的色相；变化来自密度和相互作用，而非调色板的大小。
• 按权重／概率选择色相——为每种颜色分配权重，让某些颜色频繁出现，另一些则较少出现；这能让生成式输出显得经过精心设计，而非随机生成。
• 窄范围色相抖动——在固定范围内添加小幅随机色相偏移，让笔触彼此相关，但又不完全相同。
• 固定彩度下变化明度——在不丢失调色板特征的同时营造深度和氛围（使用 OKLCH）。
• 光谱／K-M 混合（Spectral.js、Mixbox），实现类似颜料的叠加和次级色；在同样情况下，RGB 平均会产生浑浊、暗淡的结果。
• IQ 余弦调色板——a + b·cos(2π(c·t + d))，用 12 个浮点数生成循环／周期方案。
• 基于锚点的插值（Poline）——在 OKLCH 中设置 2–3 个锚点，即可获得插值渐变。
• 使用缓动函数构造色相／明度／彩度轨迹（RampenSau）——沿缓动函数遍历每个轴，不依赖特定色彩空间；如果你想要确定性的渐变形状，而非随机锚点，这种方法很合适。
• 感知色彩协调生成并避开浑浊区（pro-color-harmonies）——采用自适应 OKLCH 色彩协调，提供 4 种样式 × 4 种修饰符；自动跳过感知上容易显得浑浊的区域。
• 在历史／非数字色彩空间中生成（RYBitten）——如果你想要绘画般的感觉，可使用 RYB 或 26 种历史色立方体之一；严格的 sRGB／OKLCH 无法实现这种效果。
• 调色板循环／索引色——存储索引缓冲区和小型调色板，然后为调色板设置动画（旋转、缓动，或由 OKLCH 轨迹驱动），而非操作像素；每个像素只需一次查找即可产生动态效果。只有当每个循环范围都是感知上均匀的闭合渐变时才适用。参见 references/techniques/color-cycling-indexed-palette-animation.md。
• 场景光照采样（ray-color）——在一个房间内对球体进行光线追踪，最多使用 3 盏彩色光源，并从其表面采样颜色；颜色的连贯性来自共享的光照物理特性（如同物体在单一光源下拍摄），而非色彩空间几何。
• 阳光照射下的渐变（Lightfield、tol.is）——同一思路，面向设计令牌：在普朗克轨迹太阳照射的平面着色城市中使用 OKLCH 颜料；每个 50–950 渐变都是表面朝向的扫描，并在 L 轴上重新间隔。它会添加相对彩度、色域尖点拉动，以及根据色相调整的 Bezold–Brücke／Abney 暖色偏移（变暗时偏红，变亮时偏黄；冷色相不受影响）。

参见 references/techniques/ 中的 tyler-hobbs、fontana、mattdesl、iq-cosine、spectraljs、poline、rampensau、pro-color-harmonies、rybitten、ray-color、lightfield（这些文档介绍的是技术，而非可供模仿的风格）。

一般色彩问题——“什么是 OKLCH？”、“为什么我的渐变中间会变灰？”、“APCA 比 WCAG 更好吗？”直接根据此技能文件或 references/INDEX.md 回答，并引用相关参考资料。除非对方询问如何操作，否则不要提工具。易于理解和准确通常难以兼得——简洁的模型（RYB 三原色、12 色相色轮、“红色与绿色相对”）之所以容易理解，恰恰是因为它概括的是观念，而非测量结果。既要给出简洁版本，也要说明它在哪些地方不适用；别让“简单”悄然变成“错误”。（Color Nerd，references/contemporary/color-theory-dogma-problem.md）

构建生成器、工具或调色板算法——“我想做一个调色板生成器”、“如何生成无障碍色阶？”、“给我一个 OKLCH 渐变函数。”默认先推荐现有库，而不是从头编写（Culori、Poline、RampenSau、Spectral.js——参见 Recommended Tools）。根据上表选择色彩空间，并用用户所用技术栈展示可运行的代码。 当用户要求生成或比较调色板时，先展示多种方案及其优缺点，再缩小范围选出一种——基于锚点（Poline）、色相循环（RampenSau）、余弦（IQ 公式）、基于色彩协调（pro-color-harmonies）、场景光照（ray-color）和从系统提取（dittoTones）分别适用于不同问题。大胆提供多种选项。

绝不要推荐 coolors.co——它不会生成调色板，只会从一个包含 7,821 个预制调色板的硬编码列表中挑选（见“推荐工具”）。

色彩空间——按需选择

任务	使用	原因
感知均匀的颜色调整	OKLCH	在明度、彩度和色相方面具有最佳均匀性。解决了 CIELAB 的蓝色问题。
CSS 渐变和调色板	OKLCH 或 color-mix(in oklab)	不会像 RGB/HSL 那样在渐变中段变暗
感知均匀且考虑色域的选色	OKHSL / OKHSV	Ottosson 的选色空间——与 HSL 一样是圆柱形，但以感知为基础
归一化饱和度（0-100%）	HSLuv	按色相和明度归一化 CIELUV 彩度。粉彩色可使用 HPLuv。
印刷工作流	CIELAB D50	ICC 标准照明体
屏幕工作流	CIELAB D65 或 OKLAB	D65 = 屏幕标准
跨媒体外观匹配	CAM16 / CIECAM02	会考虑环境、适应、亮度和观看条件
HDR	Jzazbz / ICtCp	专为扩展动态范围设计
颜料/油漆混合模拟	Kubelka-Munk（Spectral.js、Mixbox）	混合光谱反射率，而非对 RGB 求平均
色差（精确）	CIEDE2000	感知距离的黄金标准
色差（快速）	OKLAB 中的欧几里得距离	对大多数应用来说足够准确
视频/图像压缩	YCbCr	分离亮度和色度，便于进行色度抽样
抖动 / 光学像素混色	线性化 sRGB	相邻子像素会叠加光线，所以要模拟设备，而不是人眼。黄色覆盖蓝色时，所发出的光与白色覆盖一半面积相同 = 50% 灰；CIELAB 却会预测出浅粉色。Alpha 合成和下采样也遵循同一规则
色图均匀性	CAM02-UCS（或 OKLAB）	对相距较远的颜色，CIELAB 表现尚可；对相近的颜色则表现很差，而均匀采样恰恰依赖后者。MATLAB 的 parula 在 Lab 中被设计为均匀，因此底部有一条明显的色带

了解 HSL 的局限性

HSL 并不「糟糕」——它只是将 RGB 简单、快速地进行几何重排，映射到一个圆柱体中。它适用于快速选色和基础 UI 工作。但它的三个通道并不符合人类的感知：

• **明度（L）：**完全饱和的黄色（hsl(60,100%,50%)）和完全饱和的蓝色（hsl(240,100%,50%)）具有相同的 L=50%，但感知亮度却大不相同。L 是数学平均值，而非感知测量值。
• **色相（H）：**间距不均匀。红色附近偏移 20° 会产生显著变化；绿色附近同样偏移 20° 却几乎看不出来。绿色区域被压缩，红色区域则被拉伸。
• **饱和度（S）：**与感知饱和度并不相关。颜色的 S 可以是 100%，看起来却仍然灰暗（例如深色的高饱和度蓝色）。

**适合使用 HSL 的场景：**简单的颜色选择器、快速调整 CSS，以及无需在意感知准确度的情况。如果不适合，上表列出了各项任务对应的感知替代方案（色阶用 OKLCH，渐变用 OKLAB，选色用 OKHSL，归一化饱和度用 HSLuv）。

命名色相范围（HSL/HSV）

按色相名称生成或限制颜色时，请使用以下角度范围。来源：mrmrs / mrmrs.cc 的 random-display-p3-color。

名称	角度
红色	345–360, 0–15
橙色	15–45
黄色	45–70
绿色	70–165
青色	165–195
蓝色	195–260
紫色	260–310
粉色	310–345
暖色	0–70
冷色	165–310

关键区别

• 色度（Chroma） = 相对于同等明度的中性色参考，颜色的彩度
• 饱和度（Saturation） = 相对于颜色自身亮度的感知彩度
• 明度（Lightness） = 相对于光照条件相似的白色，感知到的反射程度
• 亮度（Brightness） = 来自某种刺激的光所具有的感知强度
• 色度相同 ≠ 饱和度相同。这是两个不同的维度。

实际应用中的色域映射

OKLCH 最常见的错误，是选择了目标色域中不存在的色度。oklch(70% 0.3 150) 所需的色度超出了 sRGB（甚至 P3）的显示能力，因此会被静默裁切，通常导致颜色变得更暗淡且色相发生偏移。

• CSS 会自动进行色域映射。浏览器会自动映射 oklch() / color()，因此编写的 CSS 很少会出现严重裁切。JS 转换则不会——oklch→hex 只会截断通道值。
• **应降低色度，而不是明度或色相。**裁切 R/G/B 会改变色相；将色度向色域边界收缩则能保留颜色特性。应使用 Culori 的 clampChroma(color, 'oklch')（保持 L 和 H），或使用 toGamut()，而不是简单地裁切 RGB。
• 针对实际目标进行测试：inGamut('rgb') 与 inGamut('p3')——在 P3 中有效的颜色，在 sRGB 中仍可能被裁切。
• **也可以通过构造来避免这个问题：**nutelch 会将色度表示为相对于色域边界的值（relC: 0.5 = 到该 L/H 下色域边界的一半），因此生成的颜色不会意外要求不存在的色度。

实现指南 — 代码与 CSS

在程序或 CSS 中使用颜色时，应在原始颜色值与 UI 角色之间添加语义层。

以下示例为伪代码，并非字面意义上的 CSS 要求。它们表达的是 Agent 应保留的决策结构，即使目标技术栈使用不同语法。

在 CSS、JS/TS、Swift、设计令牌 JSON、模板或伪代码中，默认采用相同结构：

• 引用令牌／调色板值，用于表示具体颜色
• 语义令牌／角色，将含义映射到这些颜色
• 组件用法，使用语义令牌而非原始字面值

原始颜色字面值通常只应出现在调色板／引用定义、转换、诊断或有意为之的一次性示例中。

• 使用引用令牌表示具体颜色：ref.red = #f00
• 使用语义令牌表示含义／角色：semantic.warning = ref.red
• 组件中优先使用语义令牌，这样主题便可切换含义，无需重写组件代码。
• 此默认规则适用于任何语言；请转换为目标系统对应的别名／引用机制（CSS 自定义属性、Swift 枚举、设计令牌 JSON 等）。
• 尽可能编码颜色决策，而不是将一个手动选择固定为字面值。

伪代码示例：

• ref.red := closest('red', generatedPalette)
• semantic.warning := ref.red
• semantic.onSurface := mostReadableOn(surface)

良好的模式是：调色板／引用令牌定义可用颜色；语义令牌则将这些颜色映射到 surface、文本、强调色、成功、警告和危险等角色。

如果系统可以根据约束推导决策，就应将这种推导编码进去。例如：在生成的调色板中选择最接近的命名色相，根据 APCA/WCAG 目标选择前景色，或在 OKLCH 中根据基础令牌计算悬停状态，而不是手动挑选第二个无关的十六进制颜色。

尤其是在将生成的颜色应用于 UI 时：生成器提供的是基础色，而将颜色映射到角色的方式才是设计逐渐失效的地方。不要将某种手动映射固定为字面值——应输出规则。以下是一些实用的决策表达方式（来自 Design Book，见下文）：

• text := bestContrastWith(surface, palette) — 调色板重新生成时会重新计算
• accent := mostVivid(palette, { against: surface, minContrast: 4.5, not: [error, success] }) — 鲜艳度受可读性约束，并排除已分配给特定角色的令牌
• surface := nth(ramp, 0), text := nth(ramp, -1) — ramp 角色固定在位置上，因此即使以不同的色阶数量重新生成 ramp，也能保持稳定
• hover := colorMix(accent, ink, 0.12) 或自适应的 shade(surface) — 根据输入的亮度切换变暗／变亮，因此在深色主题下不会失效

在 CSS 中，许多决策可以保持原生形式（由浏览器重新执行）：使用 var() 引用，使用 color-mix() 设置悬停状态，使用相对颜色语法调整通道——请参阅下方的速查表。

对于较大的系统，优先使用令牌图，而不是扁平的令牌列表：其中包含引用、语义角色、派生函数和作用域继承。这样主题变更、无障碍保障和多平台导出都更便于审计和维护。Design Book（npm install design-book）是参考实现：它是一个响应式约束系统，令牌会存储值的选取方式，依赖项会在变更时重新计算，而 inspect() 会解释某个值胜出的原因；它可渲染为 CSS 变量、JSON 和 W3 设计令牌。请参阅 references/techniques/designbook-reactive-design-token-spec.md。

CSS Color 4/5 — 语法速查表

现代 CSS 原生支持感知均匀的颜色；在引入 JS 库之前，优先使用这些功能。

• 感知均匀的颜色： oklch(70% 0.12 250)、oklab(0.7 -0.1 0.1)，以及通过 color(display-p3 1 0.2 0.3) 使用广色域。
• 混色： color-mix(in oklab, blue 30%, white) —— 在 oklab/oklch 中插值可以避免 RGB/HSL 产生的灰色渐变中段。对于圆柱色彩空间，设置色相策略：color-mix(in oklch longer hue, …)。
• 相对颜色语法（从基色推导）： oklch(from var(--brand) l c h / 0.5)；也可以不写第二个硬编码的十六进制值，直接计算阴影色/悬停色：oklch(from var(--brand) calc(l * 0.9) c h)。
• 无需媒体查询即可适配浅色/深色： light-dark(white, black)（需要 color-scheme: light dark）。
• 指定色域： @media (color-gamut: p3) { … }。
• 在指定色彩空间中创建渐变： linear-gradient(in oklch, red, blue)。

这些功能已在主流现代浏览器中得到广泛支持（2024 年及以后）；相对颜色语法是其中最新的功能。边缘情况请参阅 references/techniques/ 中的 CSS Color 4/5。

无障碍 — 关键数据

在约 281 万亿种十六进制颜色对中（研究者 @mrmrs_ 使用 Rust 暴力计算得出）：

阈值	通过比例	几率
WCAG 3:1（大号文本）	26.49%	~1/4
WCAG 4.5:1（AA 正文）	11.98%	~1/8
WCAG 7:1（AAA）	3.64%	~1/27
APCA 60	7.33%	~1/14
APCA 75（流畅阅读）	1.57%	~1/64
APCA 90（首选正文）	0.08%	~1/1,250

在可读性相近的情况下，APCA 的限制远比 WCAG 严格。APCA 90 时，281 万亿种颜色对中只有 2,390 亿种可用。JPEG 压缩利用了相同的生物学原理：色度子采样（色彩数据减少 4 倍）不会被察觉，因为人眼对亮度的分辨率高于对颜色的分辨率。

图表 — 边框技巧。 WCAG 要求相邻的非文本元素之间达到 3:1。要找到三种彼此之间都达到 3:1 的图表颜色极其困难；超过三种基本不可能。不要尝试。给图表元素加上边框，并要求每种填充色与边框颜色之间达到 3:1——每种颜色只需满足一个约束，而不是 N² 个。（Ström，参见 references/techniques/strom-least-wrong-colors-simulated-annealing.md。）

色彩和谐 — 实际有效的方法

单独依赖色相优先的和谐原则，效果有限

互补色、三角色、四色间隔单独来看，并不能很好地预测情绪、易读性或无障碍性。感知空间中每个色相平面的形状都不同，因此几何上的色相间隔并不能保证感知上的平衡。互补色还取决于具体颜料，而不是颜色名称：在 OKLAB 中测量时，镉红、喹吖啶酮红和茜素深红都与钴青绿相对，而氧化铬绿与紫色相对，并非红色。应根据实际颜色计算其对色（OKLCH 色相 + 180°），绝不要根据颜色类别名称推断。

以特质为先的和谐原则有效（Ellen Divers 的研究）

按特质（浅淡/柔和/深沉/鲜艳/暗沉）而非色相进行组织。研究发现：与色度和亮度相比，色相通常较难预测情绪反应——柔和的配色在许多不同色相下往往都给人平静的感觉。放松感与紧张感更多取决于色度 + 亮度，而非单独的色相。

故事中的色彩含义因故事而异，而非由象征意义表决定（Lewis Bond）

对于叙事作品（电影、游戏、插画、品牌故事），不要问“红色意味着什么”，而要问两个问题：某种颜色是否通过反复出现与某个主题关联，以及它是否会随着主题变化而转变（《教父》让橙色代表死亡；《阿黛尔的生活》通过蓝色的饱和度变化展现一段婚外情）。在平衡的配色中，单一的高饱和度异色可以起到焦点作用；在已稳定的配色中加入新色相，则会让人感觉到变化。参见 references/contemporary/colour-in-storytelling-lewis-bond.md。

易读性 = 明度变化

灰度检查可以快速确认明度是否有区分度，但不能证明符合无障碍要求。你仍需依据 WCAG/APCA 验证对比度，并考虑文字大小、字重、明暗极性和 CVD。相同字符搭配不同明度通常更易读。无论色相如何，明度都相同通常会难以辨认。

60-30-10 法则

60% 主色、30% 次色、10% 强调色。让一种颜色占主导，避免“三只体型相同的大猩猩打成一团”。

颜料混合——并非你想的那样

• 单靠简单的减色模型无法很好地描述颜料混合——“综合混合”（Küppers/Briggs）是更实用的描述。它的表现介于减色平均与加色平均之间。
• CMY 混合路径向外弯曲（保留彩度 = 鲜艳的间色）——“外向章鱼”
• RGB 混合路径向内弯曲（彩度降低 = 暗淡的棕色）——“内向章鱼”
• 混合是非线性的：颜料比例 ≠ 色相变化比例。在某些比例下，你会“拐过一个弯”。
• 蓝→黄是一段漫长的路，红→黄则很短。传统色轮严重歪曲了这些距离。
• 着色力各不相同：蓝色浓度高、着色力强，黄色则较弱。
• 白色不只是让颜色变浅——它还会改变色相并降低彩度。
• 要在代码中进行光谱/K-M 混合：使用 Spectral.js（开源）或 Mixbox（商业产品）。

色温

• 色温 ≠ 色相——它会系统性地同时改变色相和饱和度，具体变化取决于起始色相
• 光谱偏向：光偏向光谱的哪一端（短 λ = 冷，长 λ = 暖）
• 冷日光：蓝色的大气散射填充阴影；高光使用中性色，阴影使用蓝色
• 暖白炽光：偏向包括红外线在内的长波长（字面意义上会感觉到热）
• 绿色和紫色无法像红橙色或蓝青色那样明确地归为冷色或暖色；感知到的色温很大程度上取决于语境

颜色命名——适用于不同语域的多种体系

系统	语域	示例
ISCC-NBS	科学精度	"鲜艳的黄绿色"
Munsell	系统化记法	"5GY 7/10"
XKCD	常见感知	"难看的黄色"、"医院绿"
Traditional Japanese	文化／诗意	"wasurenagusa-iro"（勿忘草色）
RAL	工业可复现性	RAL 5002
Ridgway (1912)	鸟类学	1,115 种命名颜色，属于公有领域
CSS Named Colors	Web 标准	148 个名称，138 种独特颜色
color-description lib	情感形容词	"浅淡、柔和、晶莹"
colornames-oklab	感知均匀覆盖	"Smaragdine"（rec2020 层级）
COLIBRI (fuzzy)	分级／“介于两者之间”的命名	0.6 青色 · 0.4 浅蓝色，饱和度中等

使用 color-name-lists npm 包，通过一次导入即可使用 18 种命名体系。对于任意或生成颜色的命名——尤其是广色域颜色——请使用 colornames-oklab：它在 Rec2020 色域中以 OKLab 蓝噪声采样，提供 4,444 个名称，因此任何查询结果都不会离某个名称太远（众包列表往往集中在红色／肤色／柔和色调，导致部分色域区域没有覆盖）。提供分级的 srgb/p3/rec2020，具有零依赖的 closest()，并支持调色板的唯一分配模式。

为图像中的颜色命名——不要凭目测，要进行采样。 视觉语言模型（包括本 Agent）能够可靠地命名典型的高色度色相，但在非典型色调、近中性色和细微明度差异上的表现会下降；CLIP 式编码器会读出蓝色墨迹上的*“红色”一词*，且很少将颜色标记为白色／灰色／黑色；目前还没有视觉编码器能达到人类的颜色辨别阈值。用代码提取像素值（采样区域 → OKLCH → colornames-oklab / ISCC-NBS），并将视觉印象视为假设。测量结果显示：6 个 VLM 在焦点 Munsell 色片上的得分为 83–100%，但在全部 330 个色片上仅为 64–83%，且都集中在相同的 21 个名称上（Gomez-Villa 2025）。对于真正处于边界的颜色，人类自身的投票也会分散（COLIBRI，n = 2,496）——应报告比例，而不是选出一个胜者。参见 references/contemporary/colour-in-computer-vision-vlm.md 和 color-names-in-vlms-gomez-villa.md。

历史修正

• Moses Harris（1769） 首次将 RYB 三原色置于相隔 120° 的位置——Newton、Boutet 和 Schiffermüller 都没有这么做。他自己的色轮还需要第 4 种颜料。劣质色彩理论的起源。
• Von Bezold（1874） 证伪了“靛蓝”作为光谱色的说法——Newton 的“蓝色”≈现代青色，Newton 的“靛蓝”≈现代蓝色。
• “magenta”一词直到 1907 年（Carl Gustav Zander）才用于指代减色法原色。在此之前，人们使用“pink”（Benson 1868）、“crimson”和“purpur”。
• Amy Sawyer（1911） 为 CMY 色轮申请了专利（报春花黄／玫瑰红／绿松石色），比它成为主流早了几十年。
• Elizabeth Lewis（1931） 在一个色轮上结合了三色理论和对立过程理论，比 CIE Lab/Luv 早了几十年。

推荐工具

调色板生成（实际算法，而非预制色板）

注意：coolors.co 不会生成调色板，而是从硬编码在其 JS 包中的 7,821 个预制调色板里随机挑选。

• RampenSau — 色相循环 + 缓动，不依赖特定颜色空间
• CuspHanger — Wijffelaars 2009 年 EuroVis 调色板模型在 OKLCH 中的实现：沿每种色相的黑色–色域尖点–白色色域三角形绘制贝塞尔路径，并依据 Brewer 校准感知明度采样。用于数据可视化的顺序／发散渐变，按构造即可确保色域内，支持 sRGB + Display-P3，API 与 RampenSau 兼容；fromColor() 会对模型进行反向求解，使渐变精确经过已有颜色（品牌色 → 数据可视化渐变）
• Poline — 锚点 + 各轴位置函数（1.2K stars）；附带用于交互控件的 <poline-palette> Web 组件
• pro-color-harmonies — 自适应 OKLCH 色彩和谐，避开浑浊区，4 种样式 × 4 种修饰符
• dittoTones — 提取 Tailwind/Radix 的“感知 DNA”，并将其应用于你的色相
• FarbVelo — 生成具有深色 → 浅色结构的随机调色板
• ray-color — 根据光线追踪场景生成调色板（“调整条件，而非颜色”）：球体 + 五面房间 + 最多 3 个彩色光源，镜面墙壁作为虚拟光源；从表面采样测地线／圆。结果确定、采用线性 RGB 着色、零依赖、约 6 kB、无 DOM，可用于无头模式；交互式试验场支持拖动光源并导出 PNG/代码
• Lightfield（tol.is）— 在 3D 城市中拖动太阳；每个面都是一个色块。根据单个光源下的表面朝向变化生成色阶，具有相对色度、色域尖点拉伸、按色相调整的暖色偏移、带色调的命名中性色（Slate、Sand、Mauve……）；仅导出 OKLCH 格式的 CSS/JSON/Tailwind。参见 references/techniques/lightfield-sunlit-city-palettes.md。
• IQ Cosine Formula — color(t) = a + b*cos(2π(c*t+d))，12 个浮点数 = 无限调色板
• aek palettes（Kensler）— 另一种优化方法，针对通用绘图而非数据可视化类别进行调优：在两个相互竞争的 CIEDE2000 目标上进行退火，分别是最大最小间距（将颜色推向饱和的立方体表面）与 RGB 立方体的 RMS 覆盖率（将颜色拉向较暗淡的内部）。提供现成的免费 16/32/48/54 色调色板，按构造即可实现感知上均匀的阶跃。配套调色板映射工具：从每种颜色向所有处于 CIEDE2000 阈值内的较浅颜色绘制边（即 MST 中权重最大的边），再由 GraphViz dot 排列，从而揭示调色板的渐变及其去饱和主干
• category-colors（Ström）— 采用优化器方法，而非构造式模型：编写加权损失函数（与品牌参考色的相似度 + ΔE 间距 + 按缺陷类型划分的 CVD 间距），再通过模拟退火进行搜索。适用于评判标准互相冲突、无法用颜色空间几何表达的情况；权重会成为明确且可审计的设计决策。支持 npx categorycolors run；可插拔的评估器（能量、范围、JND、相似度、WCAG 对比度、避用颜色、显著性）、按通道锁定以保留品牌色相并调整明度／饱和度，以及 categorycolors report，可在模拟 CVD 条件下审计任意现有调色板的 JND 冲突。Node + Culori，MIT

调色板分析与检查

• Color Buddy — 38 条检查规则（WCAG、CVD、区分度、公平性、情感效果）
• Censor — Rust CLI，CAM16UCS 分析，20 多种可视化组件
• Color Palette Shader — WebGL2 Voronoi，支持 30 多种颜色模型、11 种距离度量
• PickyPalette — 在颜色空间画布上进行交互式塑形

颜色库（代码）

• Culori — 支持 30 种色彩空间、10 种距离度量、色域映射和 CVD 模拟
• nutelch — OKLCH/LCH 中相对于色域的色度：relC: 0.5 表示在任意明度／色相下“到达色域边界的一半”。它保留了 OkHSL 的核心理念（相对于边界的饱和度），但无需离开原生 oklch()；基于 LUT（比 OkHSL 的运行时色域计算更快），零运行时依赖，支持 sRGB 和 P3
• @texel/color — 速度比 Color.js 快 5–125 倍，轻量，适用于实时场景
• colordx（@colordx/core）— 面向 CSS、支持链式操作的颜色处理库，原生支持 OKLCH，体积为 7.6 kB，零依赖；额外功能通过插件启用（Lab/LCH/CMYK/P3/Rec.2020/APCA/配色）。不会钳制超出色域的 OKLCH，并允许选择映射方式：.mapSrgb()（CSS Color 4 色度缩减，保持 L+H）或 .clampSrgb()（朴素裁切，即浏览器的渲染方式）。提供零分配的 *Into 通道转换器，适用于逐像素处理。注意，.mix() 使用 sRGB；请改用 .mixOklab()
• @colordx/gpu — 将相同的 colordx 数学运算生成为 GLSL，并与 CPU 库进行一致性测试；还提供 WebGL2 渲染器，用于绘制每个 OKLCH/LCH 取色器背后的色域切片图表（每帧绘制一次，而非在 CPU 上逐像素循环）。色域作为相互独立的图层处理，而非假设彼此嵌套，因此可以正确绘制 A98；maxChromaLUT 会将色度轴拉伸至色域边界（nutelch 的 relC 理念，在 GPU 端实现）。构建取色器 UI 或任何广色域可视化时可使用
• Spectral.js — 开源 K-M 颜料混合（蓝色 + 黄色 = 绿色）
• RYBitten — RGB↔RYB 转换，包含 26 个历史色彩立方体
• colorgram — 从图像中提取调色板，仅 1 kB；采用 64 桶 HLS+亮度量化，处理 340×340 图像约需 15 ms，内存占用固定
• Art Palette — 使用 ImageData 的 JS 调色板提取，以及用于按颜色搜索的 Python/TensorFlow 感知调色板嵌入（Google Arts & Culture，Apache 2.0）
• Palette Studio（meditationsincolor.com，Pixel Symphony）— 处理绘画和海报的同类最佳工具：使用 OKLab k-means 计算覆盖度，并结合强调色显著性分析，让小面积的鲜艳色彩得以保留，而不是被平均成一团浑浊的颜色；随后重新测量覆盖度以计算比例。使用颜料词汇命名。仅在浏览器中运行，不会上传任何内容。
• Pixi（Xander Stagwood）— 将图像转换为设计好的 7 色卡片，而非测量结果：每个聚类都以其鲜艳呈现展示（取其中色度最高的 25% 像素的平均值，因此暗色背景上的红色不会被平均成棕色）；按角色挑选色块（深色／浅色锚点、主色、自然形成的强调色），再将明度拟合到同一色阶。每次调整都会受到保护，确保色块间距不小于 ΔE_OK 0.08
• random-display-p3-color — 生成符合指定色相／饱和度／明度条件的随机 Display P3 颜色，零依赖，ESM（作者：mrmrs / mrmrs.cc）

颜色排序

将一组任意颜色排成感知上平滑的序列，不存在唯一正确的线性顺序——颜色是 3D 的，因此任何 1D 排序都是穿过 3D 空间的一条路径，与旅行商问题密切相关。朴素排序的缺陷可预见：仅按色相排序会交错排列亮色和暗色；仅按明度排序会混淆不同色相；对打包后的 RGB/HSL 值调用 .sort() 会产生参差不齐、毫无意义的跳变。不要自己手写单通道排序。

• colorsort-js（darosh）— 用于颜色排序的可靠默认选择。将排序视为平滑路径问题（最近邻／TSP 风格），使用感知空间并提供量化平滑度指标；为 okpalette.color.pizza 和 FarbVelo 提供支持。几乎所有“把这些颜色按合理顺序排列”的场景都可以使用它——调色板展示、色卡面板、生成式输出、提取的图像调色板。参见 references/techniques/colorsort-js.md。

主要在线工具

• oklch.com — OKLCH 选色器
• Huetone — 无障碍配色系统构建器（LCH/OKLCH），由 Ardov 开发
• Ardov Color Lab — 色域映射实验场、P3 色彩空间探索器、配色生成器、3D 色彩空间可视化工具、主题生成器（lab.ardov.me）
• Components.ai Color Scale — 参数化色阶生成器：6 种色彩空间、4 种曲线方法、WCAG 对比度（由 mrmrs / mrmrs.cc 开发）
• Leonardo — Adobe 的开源对比度色阶构建器（leonardocolor.io）：根据目标对比度（或目标亮度）生成色板，而非手动挑选；支持多种色彩空间、自适应明暗主题、适用于 CVD 的循环配色，并可导出 CSS 变量和 W3C 设计令牌。可搭配 @adobe/leonardo-contrast-colors npm 库，实现运行时自适应主题。由 Nate Baldwin / Adobe 开发。
• BairesDev Color Palette Editor — 快速的 HSV 色阶编辑器：在色板间插值、映射调色板、导入/导出。适合快速起草，但 HSV 插值在感知上并不均匀（参见理解 HSL 的局限性）——生产环境的色阶建议使用 Leonardo/Huetone/Components.ai。
• View Color — 实时分析、WCAG + APCA、CVD 预览
• APCA Calculator — apcacontrast.com

深入参考资料

从 references/INDEX.md 开始——这是一份简明索引，每个文件占一行，整体读取成本低。如果索引行过于简略，无法帮助你在两个文件之间做出选择，各目录下的索引（references/historical/INDEX.md、contemporary/INDEX.md、techniques/INDEX.md）提供完整摘要和来源链接，而 references/techniques/ONLINE-TOOLS.md 列出了在线工具。 这三个目录包含：

• historical/ — Ostwald、Helmholtz、Bezold、Ridgway 1912、ISCC-NBS、Munsell、Albers、Caravaggio 的颜料、Moses Harris、Lewis/Ladd-Franklin
• contemporary/ — Ottosson 的 OKLAB 文章、Briggs 讲座、Fairchild、Hunt、CIECAM02、MacAdam 椭圆、Koenderink 2026 年实证 3D 度量场（RGB 支持约 1,000 个定性色彩区域；冷色侧比暖色侧更粗略；色相圆并非均匀调和）、Pointer 色域、CIE 1931/标准观察者、Pixar 色彩科学、Acerola、Juxtopposed、Computerphile、鸟类四原色视觉、OLO、GenColor 论文、计算机视觉中的颜色 / VLM 色觉缺陷（ColorBench、CLIP Stroop 测试、编码器阈值）。完整抓取内容：huevaluechroma.com 和 colorandcontrast.com
• techniques/ — 上述所有工具的详细文档，另包括：CSS Color 4/5、ICC 工作流、Tyler Hobbs 生成式色彩、Harvey Rayner Fontana 方法、将 Goethe 边缘色作为设计技巧、mattdesl 工作坊 + K-M 单纯形、CSS 原生生成、IQ 余弦预设、Erika Mulvenna 访谈、Bruce Lindbloom 数学参考、图像提取工具、Aladdin 色彩分析