上周帮一个做电商的朋友收拾烂摊子事情很小一张产品主图在设计师的显示器上是一种偏冷的奶白到运营的笔记本上发黄传到手机上又变成另一种感觉。三个人对着同一张图争了一下午谁都觉得自己看到的是对的。最后查下来问题根本不在谁的眼睛有问题而是三件被混为一谈的事光怎么混出来的、设备能显示多大范围的颜色、像素数值怎么换算成光强。这三件事分别对应三基色原理、色域边界和传递函数统称起来就是彩色空间。我把这套东西给团队里几个新人讲了一遍发现绝大多数人卡住的地方不是公式而是缺一根主线为什么要有这么多色彩空间RGB 不够用吗HSV 又是干嘛的所以下面这篇我按自己的理解顺序讲从三基色的物理底子开始一路走到工程里天天踩的那几个坑。适合做前端、图像处理、视频、UI 设计、印刷对接的同学看也适合任何被颜色对不上折磨过的人。看完至少能做到一件事下次色偏时知道该往哪个方向查而不是靠猜。1. 三种颜色调不出所有颜色但能骗过眼睛先把最容易误解的一点掰开三基色不是用三种颜色能配出所有颜色而是用三种颜色能让人眼认为它是所有颜色。这两句话差别巨大前者是物理事实后者是生理事实。搞混了后面所有的色彩管理逻辑都会跟着歪。1.1 加法与减法两条完全不同的混色路径屏幕是加法混色。每个像素由红、绿、蓝三个子像素组成各自发多少光就贡献多少能量三个都拉满就是白。你关掉房间灯看手机屏幕屏幕依然是亮的因为它自己在发光。印刷是减法混色纸本身不发光靠环境光照上去油墨的作用是吸收掉某一段波长剩下的反射回来。青吸收红、品红吸收绿、黄吸收蓝三种油墨叠在一起理论上把可见光全吸收掉得到黑——这就是减色法。这两条路径的数学结构完全不同。加法混色的原色是三个发光体混得越多越亮减法混色的原色是三个滤光体混得越多越暗。所以你会看到一个反直觉的现象屏幕上的红绿蓝三原色和颜料盒里的红黄蓝三原色根本不是同一套东西。美术课上教的红黄蓝是一套历史沿革下来的习惯用法方便儿童理解它并不严格满足减色法模型真拿它去推印刷配色会翻车。工业印刷用的是青、品红、黄再加一个黑。为什么明知道青品黄能合成黑还要单独加一个黑版这里有个很实际的工程原因。第一颜料不纯三种油墨叠出来的黑偏褐、密度不够暗部压不下去第二三色叠印意味着同一处要过三次墨套印误差会累积细小的黑色文字边缘会发虚第三纯黑文字用单色黑印刷成本低、边缘锐利。所以 K 版的存在首先是工程妥协其次才是色彩需求。1.2 为什么必须是三而不是四或者二人眼视网膜上有三类对不同波段敏感的锥细胞习惯上叫 L、M、S峰值响应大致落在长波、中波、短波区域。任何一束光进入眼睛最终被压缩成的就是这三个通道的响应强度。你的大脑拿到的从来不是光谱而是三个数。这就是为什么三基色在原理上够用——不是自然界只有三种颜色而是我们的接收器只有三种。这个事实带来一个非常关键的推论不同的光谱分布只要三类锥细胞的响应相同人看起来就是同一个颜色。这叫同色异谱。它是整个色彩工业的地基——如果人眼能分辨光谱显示器这东西压根不可能存在因为你没法用三个发光体去还原一个连续光谱。反过来讲同色异谱也是无数麻烦的源头。两块屏幕用了不同的发光材料在标准观察者眼里的三刺激值可能一样但换一个观察者、换一个视角、换一种环境光匹配就崩了。两个人对着同一块屏幕说这不是一个颜色有时候真的不是谁眼睛有问题而是他们的锥细胞响应曲线本来就有个体差异。做色彩评定时要求多人交叉确认、要求标准光源、要求中性灰环境本质上都是在压制这个变量。1.3 选哪三种颜色是个工程权衡而非物理必然理论上你可以选任意三个不共线的颜色作为原色只要它们线性无关就能张成一个色域三角形。选红绿蓝是因为这三个位置张出来的三角形能覆盖比较大的可见色区域同时对应的发光材料在工程上做得到、效率够高、寿命够长。这是一次典型的够用就好的取舍不是最优解。严格的单色光原色比如特定波长的激光能张成最大的色域但成本、体积、散斑问题都不现实。实际显示器用的是有一定带宽的发光体色域三角形因此比理论极限小一圈。这也是为什么不同面板的色域覆盖率差得那么多——原色的纯度不一样三角形顶点位置就不一样。另外还有个常被忽略的点色域三角形再大也只是可见色域那条马蹄形曲线围起来的区域的一部分。没有任何一个三原色系统能覆盖全部可见色。想要更大只能加原色四原色、六原色的方案在实验室和高端显示设备里都出现过代价是驱动复杂度、成本、以及内容生态完全不支持。生态不支持这件事比技术难度更致命——你的设备能显示但没人给你生产这样的内容。2. 同一个 (255, 0, 0)在两块屏上不是同一个红我在带新人的时候经常会问一个问题rgb(255, 0, 0)是什么颜色十个人里有九个会答红色。这个答案在代码层面成立在物理层面完全不成立。这串数字只说明这个通道开到最大了至于最大是多大、对应的光是什么波长、亮度多少全都没有约定。这就是设备相关色的本质数值本身没有绝对含义必须挂在一个具体的色彩空间上才有意义。2.1 一个色彩空间到底约定了哪几件事把色彩空间拆开它其实是三份约定的打包原色坐标、白点、传递函数。三样缺一不可任何一样不同同一个数值就对应不同的实际颜色。组成部分约定的内容换了会怎样原色坐标红绿蓝三个顶点的色度位置三角形大小和形状变了色域覆盖范围跟着变白点三通道都拉满时呈现的白是哪一种白整体色温偏冷或偏暖肤色最敏感传递函数数值到光强的换算曲线中间调明暗关系变了渐变过渡手感不一样白点这件事值得单独说。同样是白正午日光、阴天、白炽灯下的白纸色温差别很大。sRGB 采用的白点接近日常显示环境下的标准白色温约 6500K。如果把一段按较低色温白点制作的内容直接丢到按较高色温白点渲染的环境里画面整体会偏冷人脸会发青。这是跨设备色偏里最常见的一种比色域不匹配还常见。传递函数则是被误解最深的一项。很多人以为 gamma 是个调节明暗的旋钮实际上它是编码规则。早期显示设备的物理响应天然接近一个幂函数为了让存储的数值和最终亮度呈线性关系制作端提前做了反向补偿把幂次抵消掉。显示端再按物理特性还原两边一配合人看到的明暗关系才是对的。问题在于这个补偿曲线各家做得不完全一样于是同一个数值在不同标准下的实际亮度略有差异——平时看不出来做渐变、做暗部细节、做多层叠加的时候就会露馅。2.2 线性光与编码值一个必须分清的岔路口这里有个概念我要重点强调因为它导致的 bug 极其隐蔽你代码里拿到的像素值绝大多数情况下不是光强而是光强的编码。这两者的关系是非线性的。举个能算出来的例子。把纯黑和纯白取平均直觉上应该得到中灰。如果直接在编码值上算(0 255) / 2 127.5大约 128。但如果先还原成线性光强再平均黑是 0白是 1平均得 0.5再按标准编码规则转回数值结果是 188 左右。差了整整 60 个灰阶肉眼一眼就能看出来——前者偏暗后者才是视觉上真正的中间。这个差异影响哪些操作所有涉及混合多个像素的操作缩放、模糊、抗锯齿、半透明叠加、光照计算、法线贴图、粒子发光。在线性空间里做这些运算才是物理正确的在编码空间里做会系统性偏暗尤其是高光和暗部同时出现的场景画面会显得脏、发灰、对比度塌陷。我踩过最典型的一次坑是做图片缩放。一批带透明背景的图标直接按常规方式缩放边缘出现了一圈发暗的描边。排查了半天以为是抗锯齿参数问题最后发现是混色发生在编码空间透明像素的 RGB 是 0黑和不透明像素做插值时黑色被混了进去。正确做法有两种一是预乘 alpha二是先转到线性空间再缩放。两种都能解决但预乘 alpha 更省事、更适合实时渲染管线。一个快速自查法如果你的画面在暗部和高光交界处总是显得脏渐变有明显的断阶感或者在深色背景上叠加半透明元素时边缘发灰优先怀疑是不是该在线性空间做的运算做到了编码空间。2.3 色域不匹配比色偏更棘手色域不匹配的表现和色偏不一样。色偏是整体挪了一个方向色域不匹配是部分颜色被削掉了。当你把一段广色域内容直接丢进窄色域环境渲染超出边界的颜色不会报错而是被硬切到边界上——结果是高饱和的红变成橙红、鲜艳的绿变成黄绿、荧光色系整体发闷。这种损失是不可逆的因为超界的部分已经没了。反过来把窄色域内容放到广色域环境里显示如果没做正确的标记和映射颜色会被拉伸饱和度虚高看着艳但不对。这就是为什么很多广色域屏幕在没做色彩管理时看普通网页会觉得颜色特别浓实际上是把该收敛的东西放大了。正确的做法只有一条内容带上色彩空间标记显示端读取标记并做映射。图片里嵌 ICC 配置文件视频里带色彩原色和传递特性的元数据网页里通过 CSS 声明色彩空间。听起来很标准实际执行中经常断链——一张图从设计软件导出、经过压缩工具、上传到图床、再被 CDN 处理中间任何一个环节丢了标记整条链路就废了。情况表现处理方向未标记内容进广色域屏饱和度虚高看着艳得不对补标记或按默认标准解释广色域内容进窄屏高饱和区域被硬切颜色发闷做色域映射或在制作端收敛白点不一致整体偏冷或偏暖肤色发青发黄统一白点或在转换时做色适应传递函数不一致中间调明暗关系偏移统一编码规则检查元数据3. HSV 和 HSL 不是更好的 RGB是操作手柄很多教程会把 HSV 说成更符合人类直觉的色彩空间这话只对了一半。它确实更贴近人描述颜色的方式——什么样的色相、多浓、多亮但它不是感知均匀的也不适合做色彩计算。理解它的定位比记住那套换算公式有用得多。3.1 它解决的是调节手感问题RGB 三个通道是耦合的。你想让一个颜色变亮一点理论上三个通道都要动你想让红更红改的不只是红通道。这种耦合让调节这件事变得非常别扭——取色器如果只有 RGB 三个滑块用户根本没法凭直觉找到一个更亮的橙色。HSV 把颜色拆成了色相、饱和度、明度三个正交的手柄转色相就是沿色环走一圈拉饱和度就是从灰往纯色推拉明度就是从黑往亮推。三个操作互不干扰手感立刻就对了。它存在的意义是交互不是计算。HSL 和 HSV 的区别在于第三维的定义方式。同样的色相和饱和度HSV 里明度拉满就是纯色HSL 里亮度拉到 50% 才是纯色拉到 100% 会变成白。这导致同一个颜色在两套模型里的数值完全不同做跨工具对接时经常对不上。我见过有人照着 A 工具的 HSL 数值往 B 工具的 HSV 里填出来的颜色完全不是一回事查了半天以为是工具 bug。还有一个实践中的坑HSV 里做线性插值做出来的渐变视觉上并不均匀。比如从红到绿色相从 0 转到 120中间经过的黄看起来会更亮、更扎眼而两端的红绿反而显得厚重。这不是错觉是模型本身的问题。做渐变、做配色方案生成的时候如果对观感要求高应该转到感知均匀的空间里插值或者手动调整中间关键帧。3.2 Lab 系列把看起来差多少变成可计算的数感知均匀是另一套诉求。业务上经常需要回答这类问题这两个颜色差多少能不能算作同一个色号客户的品牌色和我做出来的差多少算合格在 RGB 里算欧氏距离是没意义的因为 RGB 空间里的等距离不代表等视觉差异。Lab 系列就是为了解决这个。它建立在设备无关的三刺激值基础上经过非线性压缩让数值上的距离大致对应视觉上的差异。L 表示明度a 表示绿到红的对立轴b 表示蓝到黄的对立轴。这套对立色轴的设计不是随便定的它对应视觉系统的处理机制——你没法同时感知又红又绿但可以同时感知红且蓝紫。有了这个基础色差就可以量化了。最早的算法直接算欧氏距离简单但不够准尤其在饱和度高的区域。后来陆续有了加权版本、再后来有了更复杂的修正公式把明度、彩度、色相各自的权重分开处理。做工业质检、印刷品控、屏幕一致性校验用的都是这套。用途推荐空间原因取色器、调色面板HSV / HSL三个手柄正交调节手感好色差判定、色号比对Lab 系列数值距离近似视觉差异跨设备精确换算三刺激值空间设备无关是所有转换的中转站图像运算、混合、模糊线性 RGB物理上正确的光强叠加视频编码传输亮度色度分离空间便于压缩节省带宽3.3 三个L其实不是一个东西这是我在代码评审里见过最容易混的地方。HSV 的 V、HSL 的 L、Lab 的 L三个都叫亮度或明度含义完全不同。HSV 的 V 是这个颜色里最大的那个通道值它衡量的是纯色程度的上限。HSL 的 L 是这个颜色离黑和白各有多远它衡量的是在纯色和极值之间的位置。而 Lab 的 L 是经过感知校正的明度它跟人眼对亮度的主观感受大致成正比。拿 HSV 的 V 当亮度去做亮度对比度判断结论会错得很离谱——一个深蓝和一个深红V 可能一样但视觉明度差很远。做无障碍对比度检测的时候尤其要注意这一点。主流的对比度算法用的是相对亮度也就是线性光强的加权和跟 V 完全不是一回事。有人图省事直接用 HSV 的 V 去算算出来的通过率是假的。4. 视频链路里的色彩空间为什么要把亮度单独拆出来前面讲的空间都是给静态图像和界面用的。到了视频这条链路上色彩空间的设计目标完全变了——不是为了准确表达是为了省带宽。理解了这个动机后面那些看起来奇怪的规则就都顺了。4.1 拆分亮度与色度一次基于生理特性的压缩人眼对亮度细节的分辨能力远高于对颜色细节的分辨能力。你能看清一臂距离外一根头发丝的轮廓但未必能说清那根头发在某个极小区域里的色相偏移。视频编码利用了这个不对称把亮度单独拿出来满分辨率传输色度降分辨率传输人眼基本察觉不到损失码率却省下了一大截。这个思路的数学形式就是把 RGB 线性变换成一个亮度分量加两个色差分量。变换系数跟着标准走不同年代的系数不一样新一代标准为了匹配更广的色域调整了权重。这里有个必须注意的点系数选错了颜色不会报错只会微妙地偏移。整条链路里只要有任何一个环节用了不匹配的系数肤色就会偏而且偏得很隐蔽容易被当成拍摄时的白平衡问题。我在排查过一次直播画面偏色从采集卡到编码器到播放器逐段比对最后发现是某一段用了上一代标准的系数。单看任何一段的画面都还行串起来就是不对劲。这类问题的排查方法很土但有效做一个纯色测试图把标准色块逐个比对看偏差方向是否一致。4.2 色度抽样到底丢了什么常见的色度抽样格式里最常用的是每四个像素共用一组色度值的那种。也就是说一个 2×2 的像素块亮度各算各的色度只有一个。信息量上色度只剩四分之一。丢掉的到底是什么是颜色变化的锐利边界。一个红色文字压在黑色背景上如果色度被降采样文字边缘会出现彩色的晕俗称色 bleed。同理饱和的红色细线、细小的彩色图标、字幕边缘都是重灾区。这也解释了为什么做 UI 截图、做带文字的图标、做精细线条的插画绝对不能用有损的视频编码格式去存。文字边缘那种彩边一旦产生就没法还原了。真要压缩用无损或者接近无损的图像格式别图省事。还有一个反直觉的现象色度降采样对大面积平滑渐变几乎无损对高频细节破坏很大。所以自然风景、人像这类内容可以放心压界面截图、图表、代码截图这类内容压完就是灾难。4.3 有限范围与全范围那个让画面发灰的经典坑这是我看过出现频率最高的一个坑没有之一。数字视频在历史上沿用了模拟时代的电平约定亮度不占满整个编码范围两头各留一截作为保护带色度也一样。而计算机图形那边从来都是占满全范围的。两套约定一撞问题就来了。错配情况画面表现原因有限范围内容按全范围解释整体发灰、对比度低、黑不下去保护带被当成了有效数据全范围内容按有限范围解释暗部死黑、高光死白、细节全丢有效数据被削掉了两头只有亮度错、色度对明暗不对但颜色正常两个分量的范围标记不一致最坑的地方在于这两种错配都不报错。播放器照常播编码器照常编只有人的眼睛能发现不对。而在小屏幕上、在环境光很亮的情况下发灰的画面很容易被误判成这片子拍得就是这种风格。排查方法很简单找一个已知含纯黑和纯白的测试片段看终端上黑是不是真的黑、白是不是真的白。如果黑是深灰基本可以确定是范围标记的问题。修的时候要注意范围标记要跟着内容一路传下去从采集、剪辑、导出到播放任何一环改了标记都会重新引入问题。5. 落到实操转换顺序、位深和几个必须记住的检查点原理讲完最后这部分是我觉得最值钱的都是踩出来的。5.1 转换路径要短而且要挑对中转站色彩空间之间不是两两直连的标准做法是经过一个设备无关的中转空间。RGB 转 Lab、RGB 转印刷空间中间都要过一遍三刺激值。这条路径是明确的不要自作聪明去搞什么直接公式换算误差会累积。更重要的原则是转换次数越少越好。每一次转换尤其是经过 8 位整数的转换都会引入量化误差。转三次和转一次肉眼看单张图可能没差别但批量处理几百张、或者做多轮迭代的时候误差会肉眼可见地放大。我见过一个流程把图片在三个空间之间来回倒了五遍最后出来的图整体发灰、饱和度掉了一截查了半天以为是压缩参数问题。还有个不可逆的问题值得提。8 位精度下广色域转窄色域再转回来超界的颜色回不来了。同理色度抽样后的视频转回全分辨率丢掉的色度细节也回不来。凡是先转一下再转回来的操作都要问一句这一趟有必要吗5.2 位深是被低估的变量色域越大8 位精度越不够用。原因很直白色域变宽了但编码值的数量没变相邻两个值之间对应的实际颜色差距变大了渐变里的台阶就更容易被看出来。这就是为什么广色域工作流通常要求更高的位深。位深每通道级数适用场景8 位256窄色域交付、网页、普通截图10 位1024广色域显示、HDR、视频制作16 位65536中间调色、深度合成、印刷输出前实际操作里的建议是中间环节用高位深交付时再降到目标位深。调色、合成、模糊这些操作在高位深下做能显著减少色带和累积误差。反过来如果素材本身是 8 位中间过程升到 16 位并不会凭空变出细节但至少不会继续恶化。还有个细节加抖动可以在 8 位输出时打散色带用极小幅度的噪声换取视觉上的平滑过渡。代价是文件体积略增、压缩效率下降。做渐变背景、做天空、做暗部大面积纯色的时候这个手段很有效。5.3 一份我每次交付前都会过一遍的清单下面这几条是我自己的习惯不保证权威但确实帮我挡掉过很多返工。确认内容的色彩空间标记是否存在且正确。图片看 ICC 配置视频看元数据网页看 CSS 声明。没有标记的内容一律按默认标准处理并且明确告知对接方。确认显示环境和内容是否匹配。设计稿在广色域屏上做的交付给窄色域终端前必须做一次收敛预览不能只看自己屏幕。确认混合运算发生在哪个空间。缩放、模糊、透明叠加、抗锯齿这四类操作优先在线性空间做。确认位深足够。大面积渐变、暗部细节、广色域内容8 位容易出事。确认范围标记一致。视频链路尤其要看有限范围和全范围混用是发灰的头号元凶。确认转换次数。能一步到位就别绕路绕路就会掉精度。最后再分享一个我觉得挺有用的小习惯做任何涉及颜色的项目先花十分钟做一张测试图——包含纯黑、纯白、中性灰阶梯、肤色块、高饱和红绿蓝、以及一段平滑渐变。这张图在每条链路上跑一遍比对结果。比对着成品图猜问题快得多也省得跟人吵到底是谁的屏幕不对。我自己那张测试图用了好几年从图像处理换到视频换到前端一直没换过。