图像工程师的色彩认知：从色彩空间到视觉算法的完整链路解析-代码聚汇网

图像工程师的色彩认知：从色彩空间到视觉算法的完整链路解析

Llenlleawg·2026-09-02·阅读 22 GEO检测（免费）

色彩空间白平衡Gamma

|难度：普通|阅读约 34 分钟

我一直觉得，做图像这行久了，会养成一种职业病：别人看颜色靠感觉，我们看颜色靠数值。设计师说“这个蓝不够高级”，我的第一反应是打开取色器看RGB通道分布；客户说“照片拍出来发灰”，我脑子里先过一遍白平衡和Gamma曲线；现场反馈“检测系统颜色误判”，我下意识会追问光源色温和相机色彩空间。颜色这东西，在外行眼里是审美玄学，在图像工程师手底下，是一条从物理光谱到像素值、再到算法特征的完整链路。

这篇文章就聊聊图像工程师是怎么理解色彩与视觉的。它不是玄学，而是可测量、可计算、可调试的工程对象。我会从色彩科学基础讲到颜色传感器，再聊图像复原、视觉SLAM、大模型这些进阶方向里颜色扮演的角色，最后结合日常工具链给出一些实操经验。适合刚转图像算法的工程师、做工业视觉检测的现场人员，也想帮正在学视觉SLAM或图像处理的学生建立一套完整的颜色认知框架。

1. 颜色的主观是错觉，工程师眼里的颜色全是可计算量

1.1 颜色不是物体的属性，而是“光线-物体-观察者”三者的函数

很多人以为颜色是物体自带的性质，比如“苹果是红色的”。严格说，苹果本身没有颜色，它只是反射了一部分光谱。当一束光打到苹果表面，果皮吸收了大部分短波和中波能量，把长波能量反射出来，这些反射光进入人眼，经过感光细胞和大脑的解码，才产生了“红色”的知觉。

这就引出一个关键结论：颜色是“光源光谱、物体反射率、观察者光谱响应”三个变量的函数。光源换掉，颜色就变；观察者换掉，颜色也变。这也是为什么工业现场明明指示灯是同一颗红色LED，不同人拍出来却效果各异——相机传感器响应、白平衡策略、色彩编码全都参与了颜色生成。

在工程上，我们不需要哲学式地讨论“颜色的本质”，只需要把它定量化。CIE 1931色彩空间干的事，就是把“人眼的平均响应”变成一张查找表：任意一束光谱功率分布，通过XYZ三刺激值加权积分，就得到一个唯一的坐标。这个坐标不依赖主观描述，可以在色度图上被精确标定。所以当我说“这块区域的色度坐标是x=0.45、y=0.41”时，它比“这是橙色”严谨得多。

这类知识的价值，不只体现在学术论文里。我在做工业色差检测时，判定标准就写在“Lab色差值Delta E小于2”这类量化指标上，而不是“看起来差不多”。如果你正在做检测类项目，建议早点把颜色度量的思路建立起来，不然客户一句“颜色不对”而你只能凭肉眼调参，那才是真的玄学。

1.2 Gamma：像素值128并不等于50%亮度

再往深一层，像素值本身也不等于物理亮度。CRT时代的显示器和后来的各类屏幕，为了在有限的8bit精度里更好地利用人眼对暗部更敏感的特性，对亮度信号做了一次非线性编码，这个编码曲线就是Gamma。

sRGB标准里的Gamma大约是2.2。也就是说，某个像素值128存储的，并不是最大亮度的一半，而是约21.4%的线性亮度。反过来，当图像处理算法直接在sRGB像素值域里做加减乘除，结果往往不符合物理直觉。

举个非常实际的例子：给图像做高斯模糊。如果在sRGB空间对像素值直接做邻域平均，暗部区域会明显“变亮”，亮部区域会“变暗”，整体的饱和度还会偏移。正确做法是先把sRGB像素值通过de-gamma变换还原成线性光强，在线性空间里做模糊，最后再编码回sRGB。这个细节在图像融合、HDR合成、降噪、超分低层特征处理里都会遇到，处理和不处理的视觉差异，你放一张黄昏天空的照片对比一下就知道，差别大到离谱。

所以我的建议是：任何涉及像素运算的算法模块，先问自己一句，当前数据处在什么颜色空间、是否线性的。如果项目里还没有色彩管线图，赶紧补一张，把“采集→去马赛克→白平衡→Gamma编码→算法处理→输出显示”每一段标清楚，它能帮你避免八成说不清道不明的颜色bug。

1.3 白平衡：给颜色恒常性做一个工程近似

人眼有个特牛的能力叫颜色恒常性：一张白纸在日光下是白的，在烛光下你依然觉得它是白的，因为大脑会基于场景光源做自动补偿。相机没有这个本事，它只忠实记录光谱能量分布。在钨丝灯下拍照，整张图会偏黄；在阴天户外，偏蓝。这些偏差全部来自光源色温变化。

工程师解决这个问题的方法是白平衡。灰世界假设是其中一种：如果一张图里所有颜色的平均值是灰的，那么R、G、B三通道的均值应当相等，不相等就说明有光源偏色，用增益系数补偿回去。工业相机通常还支持自定义白平衡，拿标准灰卡放在目标位置采一帧，让相机记住“这个场景里什么才是白”。

白平衡这件事必须排在视觉算法前面，因为它直接决定后续颜色特征提取的阈值是否可靠。我在一个印刷品检测项目里遇到过：同样的墨色判定算法，上午OK下午NG，查到最后是车间窗户透进来的自然光随时间变化，导致白平衡漂移。后来在相机前加了偏振片、固定了光源色温，问题彻底消失。这个经验蛮多同事都踩过，颜色相关项目，环境光照控制永远优先于算法调参。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 设备端如何“看见”颜色：传感器、色彩空间与光源选型

2.1 颜色传感器是把颜色变成电路信号的工业级方案

除了相机，工业上还有一种更直接的“看颜色”设备——颜色传感器。比如TCS34725这类RGB传感器，内部集成了滤光片阵列和光电二极管，把入射光分成红、绿、蓝、透明四个通道，输出原始ADC值。它没有复杂的镜头和去马赛克过程，本质上是对目标区域光谱做一次低分辨率的积分采样，适合检测物体表面颜色、测量光源色温、区分物料类别。

用这类传感器有个细节：原始输出值并不等于标准色度值。首先需要做暗电流校正，盖上镜头盖记录零光照下的底噪；其次要做白平衡校正，用标准白板条件下测得的R、G、B增益归一化到同一水平。只有完成这两步，后续的色差计算才有意义。

我见过很多只用“原厂demo”就上线的项目，发现传感器读数漂得厉害，最后排查下来就是没有做黑电平和白增益校准。所以无论你用的是低成本RGB传感器还是高精度分光测色仪，第一次上电先别急着看颜色测量结果，而是花半小时把标定流程跑通。

2.2 为什么工程上首选HSV而不是RGB做颜色提取

到算法层，最常做的事是“把某种颜色的区域从图像里抠出来”。新手通常会直接在RGB空间设定阈值，比如“红色是R>200且G<80且B<80”。这种办法在现场光照稍微变一变就失效了，因为RGB三个通道是高度相关的，亮度一变，三个值一起变，阈值的鲁棒性很难保证。

工程上更常用的方案是转HSV空间。H代表色相，S代表饱和度，V代表亮度。色相把“这是哪种颜色”单独拎了出来，对光照变化的敏感度大大降低。这也是很多视觉库、颜色传感器的内置算法偏好使用HSV或Lab的原因。

一个典型的红色圆点识别流程大概是这样的：

python复制import cv2
import numpy as np

img = cv2.imread("red_dot.jpg")
hsv = cv2.cvtColor(img, cv2.COLOR_BGR2HSV)

# OpenCV的H范围是0~179，S和V范围是0~255
lower_red1 = np.array([0, 80, 80])   # 靠近0度的红色
upper_red1 = np.array([10, 255, 255])
lower_red2 = np.array([170, 80, 80]) # 靠近180度的红色，和0度接壤
upper_red2 = np.array([179, 255, 255])

mask1 = cv2.inRange(hsv, lower_red1, upper_red1)
mask2 = cv2.inRange(hsv, lower_red2, upper_red2)
mask = cv2.bitwise_or(mask1, mask2)

# 形态学去噪
mask = cv2.morphologyEx(mask, cv2.MORPH_OPEN, np.ones((3,3), np.uint8))

这里有一个非常容易踩的坑：OpenCV的HSV取值范围不是教科书里的0~360、0~1。H被压缩到了0~179，S和V是0~255。如果你拿着别的参考代码直接套，阈值大概率算错。另外，红色的H值跨越了0度两端，单用一段阈值会漏掉一半区域，正确做法是用两段阈值取或。

下表是我常用到的色彩空间选型对照：

色彩空间	主要特点	典型场景
RGB	直观、设备相关，通道间相关性高	图像存储、显示、深度学习输入
HSV	色相与亮度分离，对光照相对鲁棒	颜色阈值分割、目标提取
Lab	感知均匀，Delta E色差可计算	色差检测、色彩测量、印刷品质检
YCbCr	亮度与色度分离，兼容压缩标准	视频编码、肤色检测

2.3 环境光不可控，视觉光源才是颜色的“裁判”

在工业视觉现场，“颜色识别不准”的根因里，环境光的影响经常排第一。自然光一天之内色温变化极快，车间里日光灯还会频闪，这些都会让相机采集到的颜色不稳定。所以现场应用基本不会依赖环境光，而是主动打光，用受控的光源去照亮目标。

不同的颜色检测任务，光源选型逻辑差别很大。如果是区分绿色PCB和红色元件，用白色环形光即可；如果目标颜色偏暗、对比度不够，可以考虑用目标色的补色光来压低背景干扰；背光模式下目标通常成黑色剪影，此时讨论颜色就不是重点了。还有一种常见做法是给镜头加偏振片，消除反光带来的高光区域，让颜色表面呈现更均匀。

光源的色温本身也要稳定。我遇到过用普通LED灯做的项目，灯珠老化后色温漂移，本来调试好的HSV阈值逐渐失效。后来换了恒流驱动的标准光源，色温漂移小了两个数量级，系统才稳定下来。做视觉引导机器人的朋友更要留意，机械臂运动过程中可能会改变当前工位的受光角度，同样的算法在不同位姿下拍出的颜色特征会差很多，这类场景建议做在线光照归一化或增加补光。

3. 图像复原与增强里的颜色失真：比模糊更难对付的工程问题

3.1 超分辨率为什么容易出现色偏与“塑料感”

图像超分辨率重建这几年被炒得很热，尤其基于深度学习的方案，确实能把低分辨率图像放大出惊人的细节。但用过ESRGAN这类生成式模型的朋友肯定有体会：模型输出经常出现颜色过饱和、边缘色带、局部区域偏青偏紫的现象。

原因也不复杂。很多生成式超分模型是在sRGB像素域训练的，损失函数里如果对感知质量权重过大，模型会倾向于“编造”锐利细节来取悦人类视觉，而颜色通道的空间分布一旦被高频成分污染，就会表现为伪彩边缘。尤其是原图经过重采样、压缩、去马赛克三道工序后，Chroma子通道的噪声早就被放大了，超分模型再在上面做纹理合成，颜色自然容易崩塌。

有人问“nafnet-light可以用于提升图像分辨率吗”，我还真试过。NAFNet主打高效去噪和复原，light版本用轻量结构做超分任务是可行的，优势是速度快、伪影少，但它的算法目标是保持内容结构，不是像GAN那样追求视觉锐度，所以放大纹理细节的观感可能不够“惊艳”。如果你做的是监控图像增强这类对颜色保真度要求高的场景，这类面向复原的模型反而是更好的选择，因为它的颜色漂移小很多。

给一个通用建议：超分模型的输出不要直接当最终结果用，建议接一个轻量的颜色校正后处理，比如把输出图像的全局均值RGB对齐到输入图，或者做一次基于Lab空间的色度直方图匹配，能在保留细节的同时拉回整体色感。

3.2 去模糊与去噪中的振铃：颜色像水波纹一样振荡

去模糊是另一类容易“颜色翻车”的任务。经典的Richardson-Lucy反卷积和Wiener滤波，本质上都在做逆滤波运算，会把噪声放大成振铃伪影。这种伪影在灰度图上看是明暗条纹，在彩色图上会升级为彩色条纹，因为R、G、B三个通道会分别振荡，相位错开后就变成了一圈圈的彩虹边。

规避的做法通常有两个方向。第一是尽量在亮度通道上做反卷积处理：把图像从RGB转到YCbCr或Lab，只对L或Y通道执行去模糊算法，Cb/Cr通道做轻量去噪甚至不动，这样振铃现象只会表现为明暗变化，不会出现刺眼的伪彩色。第二是引入正则化约束，比如全变分正则项，限制像素梯度不能无限制增长，从源头上压低振铃的能量。

类似的问题也会出现在低照度增强里。夜间图像直方图集中在暗部，直接展开直方图会让暗部噪声一起被放大，而噪声在彩色通道上的表现就是密密麻麻的彩色噪点。用多尺度Retinex做增强时，如果没有颜色恢复环节，增强后的图像经常发灰发白。我个人经验是：低照度增强的管线里，先降噪再增强、亮度分量单独增强、色度分量做适度饱和恢复，这三步顺序不要乱，顺序错了就是另一个项目事故。

3.3 批量图像处理时，如何解决颜色不一致

单张图调得再好看，放到批量数据里就露馅了。医学图像、遥感影像、电商商品图，只要是不同批次、不同设备采集的数据，颜色分布难免有差异。做深度学习的训练集如果颜色分布不一致，模型性能会明显波动。

这个问题有一个非常实用的离线解决方案：直方图匹配。选一张颜色标准的参考图，把目标图像的累计直方图映射到参考图的累计直方图上，R、G、B三通道分别做一次映射。下面是简化版思路：

python复制import cv2
import numpy as np

def match_histogram(src, ref):
    matched = np.zeros_like(src)
    for c in range(3):
        src_hist = cv2.calcHist([src], [c], None, [256], [0,256])
        ref_hist = cv2.calcHist([ref], [c], None, [256], [0,256])
        src_cdf = np.cumsum(src_hist) / src_hist.sum()
        ref_cdf = np.cumsum(ref_hist) / ref_hist.sum()
        # 找到src每个灰度级映射到ref的哪个灰度级
        map_table = np.interp(src_cdf, ref_cdf, np.arange(256)).astype(np.uint8)
        matched[..., c] = map_table[src[..., c]]
    return matched

这里要留意：直方图匹配是统计层面的全局映射，如果两张图的内容差异巨大（比如一张星空一张人脸），匹配结果会显得很假。实际项目里，更稳妥的做法是先做白平衡归一化和曝光归一化，再对色彩分布做对齐。另外，最优传输理论在图像恢复和颜色迁移中的应用也越来越广，OT在数学上比逐通道直方图匹配更优雅，能同时考虑通道间的联合分布，做出来的颜色迁移效果更自然，但计算成本也高不少，小批量场景下看需求取舍。

4. 从2D到3D、从像素到语义：颜色在高级视觉任务中的角色

4.1 SLAM特征点为什么要先灰度化

视觉SLAM是很多图像工程师进阶的方向，初学者拿《视觉SLAM十四讲》啃到特征提取那章，都会遇到一个问题：ORB、SIFT这些特征点，怎么第一步就把彩色图转成灰度图？颜色信息难道不是现成的免费线索吗？

原因在于，经典特征点描述子关注的是图像的梯度结构，而不是颜色绝对数值。ORB的BRIEF描述子对像素对做亮度比较，SIFT统计梯度方向直方图，这些设计都基于一个假设：场景的纹理结构比颜色更稳定。彩色图转灰度后再做特征提取，计算量减少，程序流程统一，而且特征点提取结果对光照色温变化更鲁棒。

但付出的代价也很明显：一个只有颜色对比、没有亮度对比的场景，比如白墙上贴了块红布，灰度化之后红布和白墙可能混成一片，特征点就丢了。所以现在的语义SLAM系统，通常会在前端并行跑一个轻量语义分割，用颜色辅助区分“地面、墙面、物体”，再和几何特征融合。做无人机视觉感知的朋友更清楚，高空俯视场景里，大片农田的颜色差异恰恰是关键线索，纯几何特征会失效。

我的建议是：做SLAM不要排斥颜色，但要清楚它在管线里是“辅助线索”而不是“主要依赖”。用颜色做语义先验可以，别拿像素颜色值直接进位姿优化，那是把鸡蛋放在一个特别不稳定的篮子里。

4.2 颜色属性在视觉关系任务中的价值

视觉关系数据集，比如Visual Genome，把图片描述成“物体-关系-物体”的三元组，例如“人-骑-马”“杯子-放在-桌子上”。在这些三元组里，物体的属性——尤其是颜色——经常是关系推理的关键。比如“红色的车在白色的车前面”，如果模型忽略了颜色属性，两辆车都是“车”，关系就变得难以区分。

这种任务里，颜色不是低级特征，而是实例消歧的语义线索。很多视觉关系模型会把颜色属性当作一个类别标签参与注意力计算，帮助模型回答“哪一个物体是关系的主体”。做2D视觉、图像描述、视觉问答的同行，在设计特征编码时应该把颜色属性当成独立通道，而不是让它在CNN主干网络的深层被抽象稀释掉。

4.3 大模型“看”颜色的方式和人类不太一样

这两年视觉大语言模型火得不行，大家发现它居然能准确说出“这只猫是橙色的”“这件衣服是蓝色的”。但用多了会发现，它对细粒度颜色的判断远不如人类稳定。你问它“这是什么红”，它也许能说出“朱红”“玫红”，但换一张光照不同的图，它可能就改口了。

原因是多模态大模型对颜色的理解，本质是把图像特征和文本里频繁共现的颜色词做对齐，它的颜色知识来自图文语料，而不是光谱测量。语料里“红色”出现频率最高，模型对高频颜色词有稳定的把握；而“琥珀色”“藕荷色”这类低频词，它只能靠文本上下文猜测，容易翻车。

所以做视觉大模型应用的朋友，提示词里描述颜色时，尽量用“大红色、深蓝色、浅绿色”这种高频词，别用文艺形容词。如果你要做的任务是精确颜色分类，别直接让大模型出答案，让它先做区域定位，再让传统颜色测量算法去判定，两者结合既聪明又可靠。

5. 日常工具链中的色彩调试：我常踩的坑和一些顺手方案

5.1 OpenCV的BGR陷阱和Halcon的通道顺序

要说图像处理最常见的颜色坑，OpenCV的BGR绝对排第一。cv2.imread读进来的图片，通道顺序是BGR，而matplotlib.pyplot.imshow默认认为数据是RGB，直接把BGR数组丢给它显示，红色和蓝色会互换，整张图立马“赛博朋克化”。

解决方案就是一行代码：

python复制img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB)

但比转换更重要的，是建立通道顺序意识：深度学习框架的预处理、图像分割的标签可视化、图像生成模型的输入输出，每一层都在关心“数组的最后一维到底是什么顺序”。我处理过一个图像分割项目，标注图是RGB格式的，模型输出却默认排成BGR，最后可视化时所有类别颜色全错位了，查了很久才发现是这半个字节的细节。

Halcon的通道顺序问题更隐蔽。用read_image读图后，彩色图像的通道顺序和相机、文件格式都有关系，gen_image3构造三通道图像时也要显式指定R、G、B的顺序。此外，Halcon里一部分算子的输入输出约定是interleaved还是planar，也直接影响颜色分量是否正确。做工业视觉的朋友，拿到Halcon的彩色图，第一步永远是手动检查三个通道的内容，别假设它自动正确。

5.2 可视化配色：MATLAB、Origin、VS Code这些“小破事”

颜色调试不只发生在算法里，图像工程师的日常出图、汇报、写文档，同样处处是颜色问题。

MATLAB里，imagesc显示图像后如果忘记axis image，图像比例会变形，虽然这是几何问题，但配合默认colormap确实容易让人误判。2014b之后的MATLAB把默认colormap从jet换成了parula，原因就是jet的彩虹色在灰度打印和红绿色盲场景下几乎不可读。我建议做数据可视化的朋友，除非有特殊需求，尽量用parula或viridis这类感知均匀的colormap。

Origin里画3Y轴图时，换颜色的操作很碎：双击曲线打开Plot Details，在Line标签页的Color处分配颜色，多条曲线想统一配色方案，可以用Colormap/Contours选项卡里的索引色映射。VS Code的主题颜色调整，则是在settings.json里配置workbench.colorCustomizations和editor.tokenColorCustomizations，这个纯属个人审美，但有一个原则：文本色和背景色的对比度至少要保证长时间盯代码不累。

这几件事看起来都是“小破事”，但工程师每天都在跟这些工具打交道，配色顺手了，效率能提升不少。而且，出图配色规范这件事挺影响专业度的，同一个实验室出来的报告，一套配色肉眼可见地比另一套“高级”，这不玄学，是色彩工程学的应用。

5.3 ComfyUI、HEIF与遥感标注中的色彩管理

最近的生成式工作流里，ComfyUI是很多人离不开的工具。用ComfyUI做图的时候，偏色问题很常见。我总结了几条排查顺序：先看VAE是不是对应的，模型和VAE不匹配会导致整体色罩；再检查保存节点有没有把图像格式从RGB转回目标格式，很多自定义节点在内部是线性RGB或RGBA，直接输出到JPEG会偏灰；最后看加载器有没有做色彩空间转换，加载sRGB图片进线性流程，再输出不转回来，颜色肯定不对。

还有背景移除节点，一般输出RGBA，A通道是透明度，如果你把RGBA直接当RGB接进后续生成链路，颜色会奇怪。记得用Split RGBA节点把Alpha通道拆出来，或者用Composite节点把透明区域合成到白底/黑底上。

HEIF图像扩展也是最近常被问到的。HEIF支持10bit甚至更高位深和广色域，相比JPEG的8bit sRGB，对色彩过渡平滑的高清图优势非常明显。Windows系统没装HEIF扩展时，看图软件直接打不开这类文件，安装扩展后还要注意颜色管理是否正确，否则广色域图在sRGB屏幕上会显得过饱和。做图像数据集整理的朋友，建议检查一下数据源里是否混着HEIF，它的色彩空间元数据和JPEG不完全一样，预处理管线要考虑这一点。

遥感图像标注里也有个颜色共识问题：遥感影像通常不只RGB三个波段，还有近红外等多个波段。我们日常看到的自然色遥感图，是R、G、B三个波段合成的结果；而植被分析常用的假彩色合成，是把近红外、红、绿波段映射到R、G、B通道，此时绿色的植被会呈现红色。如果不清楚合成规则，光看颜色就会误判地物类型。标注团队对假彩色影像的标签体系，一定要和自然色影像分开定义。

另外说个冷门但真实的问题：NIfTI格式的医学分割图像另存为NRRD时，文件体积突然变大。这个现象和颜色关系不大，根本原因在于两种格式的压缩方式和元数据存储方式差异，NIfTI默认可能用了gzip压缩，NRRD往往是未压缩存储，同样的体数据存储体积当然会骤增。处理这类数据时，先确认压缩设置，别让存储容量意外超标。

6. 串起一条完整链路：色环电阻分拣项目里的颜色处理实战

理论说再多，不如走一遍完整项目。我拿一个常见的工业场景——色环电阻颜色识别分拣——来复盘颜色和视觉是怎么串成一条链路的。

第一步，采集端校准。电阻表面是陶瓷基体加色环颜料，有一定反光。现场使用标准D65光源加环形无影光，相机做自定义白平衡，拍一张标准白板做参考。这里用颜色传感器TCS34725做辅助验证，确保光源色温稳定在6500K附近。注意，这一步不是可有可无的，光源不稳定，后面所有阈值都会漂移。

第二步，颜色提取。读图后用HSV空间分割色环像素，根据每个色环的H值区间分类，红、棕、绿、蓝、紫、灰、金、银都有对应的色调范围。为了避免色环边缘的渐变区域干扰，先做形态学开运算，再对每个色环区域提取均值H值，用均值去做分类判断，比逐像素判断稳得多。

第三步，色差测量。对分类结果存疑的区域，转成Lab空间，和标准色板上的颜色做Delta E计算。Delta E小于3判定为合格。这一步可以很好地解决“红色和棕色在强光下混淆”的问题，因为Lab空间的色差计算和视觉主观感受相关度最高。

第四步，数据回传。把分类结果和置信度输出给PLC，由机械臂完成分拣。置信度低于阈值时，系统自动触发复检。整个过程里，颜色信号从物理光谱→传感器响应→HSV特征→Lab色差，每一层都有明确的量化依据。

做完这个项目我有一个特别深的体会：颜色视觉系统调试，百分之七十的时间花在校准和控制上，只有百分之三十花在算法本身。光源、白平衡、色彩空间、样本标定，这些环节里任何一个疏忽，都会在最终颜色判定上放大成不可接受的错误。

最后分享一个个人经验：遇到颜色问题，别急着调阈值、换模型，先把采集端到算法端的整条颜色链路走一遍。问自己三个问题：光源稳不稳？白平衡准不准？当前数据的色彩空间和算法假设是否一致？大多数颜色玄学，排查完这三步都变成了大白话。图像工程师和普通人的区别，大概就在于我们愿意相信，任何颜色问题背后，都有一条可以被测量和修复的因果关系。