上周有个朋友甩给我一串十六进制颜色值，说想在一排LED灯上复现出那种“很正的蓝”。我按RGB思路调了一整晚，从#1D4ED8调到#1E50E8，怎么看都不对：要么发紫，要么发灰。后来干脆换到HSV模式，只动了一下色相和一个饱和度参数，两分钟就调出来了。这真不是玄学，而是我们最常用的RGB颜色模型，在“让人理解颜色”这件事上天生就不擅长。
这篇内容我打算把RGB、HSV、HSI三个颜色模型一次性讲透：它们分别解决什么问题、为什么会出现这么多套模型、怎么互相换算，以及真正干活的时候该选谁。如果你是做视觉识别的、调LED灯效的、写前端或者做UI设计的，甚至只是想知道屏幕上十六进制颜色到底什么意思，这篇都适合。我不堆术语，会把原理、公式、踩坑经验放一起讲，尽量说人话。
1. 先分清：RGB是色光拼盘，HSV/HSI是人对颜色的直觉
1.1 颜色不是物体的固有属性
我们先说一个容易绕晕的点：颜色并不是物体自带的标签，它更像是光和你眼睛之间的约定。太阳光打到一个苹果上，苹果把一部分波长吸收、一部分反射出来，反射光进入眼睛后，视锥细胞对不同波长产生强弱不等的三路信号，大脑再把这三路信号合成我们说的“红色”。
计算机要复现这个体验，最直接的办法就是让屏幕也发出三路光，分别刺激你的三种视锥细胞。所以RGB模型本质上是在模拟这套“三路刺激”。红色、绿色、蓝色三束光可以按不同亮度叠加，叠出你能看到的绝大多数颜色。三路全开且等亮时，视锥细胞收到平衡刺激，看起来就是白色或灰色；完全不开就是黑色。这叫加色混合，越加越亮，和颜料、打印墨水的减色混合正好相反——油漆混得越多越黑，因为吸收的光越来越多。
这也就解释了为什么同一个颜色在屏幕上看和打印出来看经常对不上：屏幕靠加色，纸面靠减色，物理基础完全不同。印刷行业用CMYK是另一套故事，我们先把焦点放回RGB、HSV、HSI这三个模型上。
1.2 三套模型的定位：一个给机器，一个给交互，一个给处理
可问题是，RGB虽然在物理上正确，在人类直觉里却很不友好。你看到一只橘红色的晚霞，很难说出它的RGB分量应该是什么，但你能很自然地说：颜色偏红橙、挺鲜艳、亮度不错。HSV和HSI就是把这句感性的描述拆成三个数：色相H、饱和度S、以及亮度或强度。它们把“颜色本身”和“颜色的浓淡、明暗”分开，方便人描述，也方便程序按属性做筛选。
打个比方。RGB像用经纬度和海拔去定位一个地方，精确、可测量、机器可以直接用；HSV/HSI像“下了高速往东三公里、半山腰那栋小楼”，对你来说更直观，但要实际导航还是得换算回经纬度。这不是谁替代谁的问题，而是不同层干不同活。
1.3 为什么会有那么多颜色模型
其实不止RGB、HSV、HSI，视频压缩那边还有YUV/YCbCr，打印那边有CMYK，印刷行业还有Lab。模型越来越多，不是因为技术倒退，而是每个环节都希望用一种“本地语言”来描述颜色。显示器端需要RGB，因为硬件就是三个小灯管；人机交互需要HSV/HSI，因为人的描述习惯是“色相+浓淡+明暗”；压缩存储需要YUV，因为人眼对亮度更敏感，可以把色度信息多砍一点。
理解了这一点，你再看各种“颜色模型对比”就不会慌，它们不是什么门派之争，而是一套颜色在不同场景下的不同方言。
2. RGB：显示器和数字图像的骨架，难用是先天设计
2.1 一个像素为什么是三个0~255
先看数字世界里最常见的形态：一个像素拆成R、G、B三个通道，每个通道用8bit整数表示，范围0到255，组合出256×256×256≈1670万种颜色。8bit不是拍脑袋定的，它正好凑一个字节，内存对齐、硬件设计都很方便；另一个原因是在正常显示亮度下，256级灰阶已经能骗过大多数人眼的色阶辨别能力。
这里有个新手容易忽略的点：RGB三个通道等值时不一定是“中性灰”，只是在你屏幕经过标准校正的前提下才接近中性。而且人眼对三原色的敏感度并不相等，绿色的贡献最大，所以很多灰度算法用0.299R + 0.587G + 0.114B，而不是简单的(R+G+B)/3。这从侧面说明RGB三分量虽然叫“三原色”，但不代表三种等权重的感知原料，只看数值容易误判亮暗。
2.2 Gamma：为什么手动调RGB经常翻车
还有个更隐蔽的问题：显示器亮度对数值不是线性关系。一个像素存的数值从128提到255，亮度并不是线性翻倍，而是大致遵循一条幂曲线，输出前还要做gamma解码和编码。换句话说，存储里的0~255并不是人眼感知的0~255灰度阶梯，更像一种为了抵消显示器和人眼特性而做的编码。
这就导致想用RGB滑块把颜色调亮一点时，不能单纯三个通道同时加20，因为不同通道原来的相对位置不一样，换算成实际亮度后偏移完全不同；想调饱和一点，把非目标通道整体压低，效果又会被gamma曲线扭曲。你在一层一层的非线性变换里“盲调”，自然容易翻车。这也是为什么交互调色场景里，大家纷纷转投HSV/HSB。
2.3 RGB仍然是整个数字影像的底层语言
尽管难调，RGB的统治地位依然稳固。显示器每个像素就是红绿蓝三个子像素通电发光；GPU做光照、阴影、混合时也默认用RGBA做线性计算；很多图像文件解完码，最终也是给显示器送RGB。视频压缩常把RGB转成YUV/YCbCr来削减视觉冗余，编码解码结束后还是要转回RGB显示。
你完全可以这么理解：RGB是机器和机器之间传递颜色的语言，HSV/HSI是人和机器商量颜色时的翻译层。
3. HSV与HSI：把颜色拆成三个旋钮，但这两个模型别搞混
3.1 H：色相是个环，红色在0°
HSV/HSI里最让人熟悉的是色相H。它用一个角度来描述颜色种类：0°红、60°黄、120°绿、180°青、240°蓝、300°洋红，转一圈回到0°。把颜色按彩虹顺序围成一个环，是因为光谱颜色本来就能按波长排序，剩下的洋红这类非光谱色刚好用来把环的开口接上。
这个环的设计很关键：它把“颜色种类”从“亮暗”和“浓淡”中剥离开。H=0°是红色，但它同时也等于360°。别小看这个边界，后面做颜色分割时，红色目标会在阈值上让你吃一次大亏。
3.2 S：饱和度是离灰轴的距离
饱和度S描述的是颜色有多“纯”。S=0时，颜色基本是灰色或白色，只有明暗变化；S拉满时，颜色是最鲜艳的纯色。任何颜色往里面掺入白色或灰色，都会降低饱和度。这也是调色时特别有用的旋钮：想“去灰”就提S，想“柔和”就降S。
注意，饱和度和亮度是两回事。一个浅粉色是低饱和高亮；一个暗红色是高饱和低亮。千万不要看见“不够鲜艳”就一味补S，有时候你需要调的是V或者I。
3.3 V和I：一个是最大值，一个是平均值
先看HSV里的V，通常写作Value，取值是三通道里的最大值：V=max(R,G,B)。纯红、纯黄、纯青、纯白，V都等于255，因为三通道中至少有一个处于最大强度。它的直观含义是“这个颜色里最强的一路能顶到多亮”，所以拖动明度滑块提高V时，颜色会显得更亮更冲。
再看HSI里的I，写作Intensity，取的是三通道算术平均：I=(R+G+B)/3。纯红色的强度其实只有85左右，远没有V看起来那么高。I更像一张“经典灰度图”的底子，它把亮度信息从彩色信息里分离出来，适合做直方图均衡、亮度归一化这类图像处理操作。
简单说，V是为了调色直觉，I是为了图像处理中把亮度当成独立分量。很多文章把HSI的I和HSL的L混在一起，其实都不相等。HSL的L=(max+min)/2，介于两者之间，在不少设计软件里也很常见。模型一多就容易乱，下面放个表，方便你一眼分清它们。
3.4 一张表分清RGB/HSV/HSL/HSI
| 模型 | 分量含义 | 亮度/强度定义 | 直观形状 | 典型场景 |
|---|---|---|---|---|
| RGB | 三色刺激强度 | 三通道并列 | 立方体 | 屏幕显示、存储、渲染 |
| HSV/HSB | 色相/饱和度/明度 | max(R,G,B) | 圆锥/圆柱 | 人工调色、颜色阈值分割 |
| HSL | 色相/饱和度/亮度 | (max+min)/2 | 双锥体 | 老设计软件调色面板 |
| HSI | 色相/饱和度/强度 | (R+G+B)/3 | 双锥近似 | 图像强度与色彩分离处理 |
看到这你会发现，HSV/HSI名字很像，实际分量定义却不一样。搞不清时就用表里的核心公式判断，不要凭感觉。
4. RGB到HSV/HSI的换算：公式记不住没关系，逻辑要懂
4.1 先看RGB到HSV：max、min、delta三段话讲清
我记不住公式，但算法逻辑其实很朴素。第一步，找到R、G、B里的最大值max和最小值min；第二步，V就是max；第三步，饱和度S就是(max-min)/max，意思是“彩色分量占最大强度的比例”；第四步，色相H按照哪个通道是最大值决定落在哪个色段：max是R找红到黄色段，max是G找绿到青色段，max是B找蓝到洋红段。
拿橙黄色(255,128,0)来说，max=255，min=0，S=1；max是R，用(G-B)/delta=128/255≈0.5，乘以60°，得到约30°。橙色在红和黄之间，符合直觉。纯红是0°，纯黄是60°，两者之间就是橙，这个分段公式跟肉眼感受相当贴合。
4.2 RGB到HSI：平均值带来的不同结果
HSI换算的核心差别在于：I只是平均值，S的常见写法是1 - 3*min/(R+G+B)。当纯红时S=1，等灰时S=0；H依旧沿用色相环角度思路，看哪个通道占优、中间通道相对差值是多少。因为H的计算和HSV那套基本一致，很多库干脆共用底层实现，只把V换成I、把S公式换成平均值版本。
实际动手前，一定要先确认你说的是哪一种定义。同一个纯红，HSV里V=255，HSI里I=85；饱和度公式不同，结果也能差出几个百分点。不同文章和代码混着抄，最后做出来的mask完全对不上。
4.3 一份可以直接跑的最小实现
给你一段不依赖任何第三方图像库的纯Python版本，方便理解核心逻辑：
def rgb_to_hsv(r, g, b): r /= 255.0 g /= 255.0 b /= 255.0 cmax = max(r, g, b) cmin = min(r, g, b) delta = cmax - cmin v = cmax if delta == 0: h = 0.0 s = 0.0 else: s = delta / cmax if cmax == r: h = 60.0 * (((g - b) / delta) % 6) elif cmax == g: h = 60.0 * (((b - r) / delta) + 2) else: h = 60.0 * (((r - g) / delta) + 4) return h, s, v print(rgb_to_hsv(255, 128, 0)) # 大约 (30.0, 1.0, 1.0) print(rgb_to_hsv(0, 255, 128)) # 大约 (150.0, 1.0, 1.0)这是最小演示版。实际工程里，图像库的接口会一次性处理整张图，还会顺便把H压到0~180或0~255范围内，避免把浮点角度转成整数时占用额外存储。
4.4 转换里容易踩的隐藏坑
- H范围不统一：有的库用0~360，有的用0~180，有的用0~255。跨库比对前必须先确认。
- S/V范围不统一：常见0~1和0~255两种尺度，别拿255的阈值去套0~1的数据。
- 整数溢出：uint8像素强行做加减可能溢出，0减1会变成255，得先把数据转成浮点。
- 反复转换：多次RGB到HSV再到RGB的往返会有舍入误差，比较颜色时最好只转换一次，全部用浮点保存。
5. 实战选型：视觉分割、调色交互、光照处理各用谁
5.1 做颜色识别分割：HSV阈值法现场调参记录
有一次做视觉识别，目标是找画面里的橙色乒乓球。我第一反应是用RGB框设置范围，结果发现完全不行：不同光照下，同一个橙子的R/G/B会一起浮动，阈值很难钉死。后来我把整帧图从BGR转到HSV，再用阈值做掩码，问题立刻变简单。
H范围设在10~25，S下限80，V下限60（按0~255刻度），高光和阴影处的误检明显变少。为什么？因为RGB判断颜色要靠两个通道组合，还要担心光照同时改变三通道；HSV把色相单独拿出来，光照变化更多体现在V分量上，H相对稳定。所以只要H范围给宽一点，再补上S和V的下限，就能获得稳定区域。最后再配合形态学操作：开运算去掉孤立噪点，闭运算把碎片接起来，只保留面积最大的连通域。如果不用形态学，单纯阈值出来的掩码会有大量小孔，后面求轮廓会非常不稳。
5.2 HSI在光照场景的价值：把I分量和颜色分量分开
再说HSI。实际用下来，它在整体光照缓慢变化的场景里很好用：颜色信息主要集中在H，亮度集中在I。可以先把I分量做归一化或直方图均衡，再和H、S合回去，阴影的影响会小很多。但遇到高光、镜面反射时，H和S也会被污染，别指望一个模型包治百病。
我自己的选择习惯是：如果任务是“把特定颜色的东西从画面里挖出来”，首选HSV；如果任务偏“平衡光照、增强对比度”这类图像增强，会先用HSI的I分量做预处理，再继续后续逻辑。
5.3 人眼调色交互：HSB滑块远比RGB舒服
到设计或者调灯环节，我基本不用RGB滑块。选色器里的色盘就是照着HSV/HSB做的：先挑一类色相，再调饱和度和明度。比如LED灯效要一个“偏紫的深蓝”，我操作起来就是：色相拉到240附近再偏紫一点，饱和度保持在80%左右，明度降到比较暗的那一段。
而RGB模式想调同样的效果，要同时改三个数值，还得处理gamma的非线性，试错成本高很多。这也是为什么几乎所有图像软件的“拾色器”都默认提供HSB/HSV面板，而不是只给RGB数字框。
5.4 别忘了RGB仍在底层扛活
选型不是说谁比谁高级。屏幕发光、芯片驱动、3D渲染、编解码还原，全都在RGB或者从RGB派生的空间里运转。HSV/HSI更像一层“翻译”，帮人把颜色描述成可理解的维度。真正把信号送到显示器的那一刻，还是得变回RGB三路电压。
| 具体任务 | 推荐模型 | 理由 |
|---|---|---|
| 屏幕显示/渲染 | RGB | 硬件直接使用 |
| 调色/选色交互 | HSV/HSB | 三个旋钮符合直觉 |
| 彩色目标识别分割 | HSV | 色相与亮度分离，阈值稳定 |
| 光照变化下的图像增强 | HSI | I分量可独立处理 |
| 视频压缩 | YUV/YCbCr | 提升压缩效率 |
6. 新手最容易踩的几个坑：H断裂、亮度干扰和“假饱和”
6.1 红色的区间断裂：H=0和H=360其实挨着
色相环上，红色既在0°也在360°，用连续阈值会出现一个尴尬局面：“红色”被切成两截。比如某图像库H是0~180，红色既出现在0~10，又出现在170~180。写红色目标识别程序时，如果只写一个h < 10的区间，就会漏掉另一半——不是代码有问题，而是H环首尾相接的性质决定的。
处理方式不复杂：把范围拆成多个区间，逐个合并。做红色目标识别时，我经常会输出两个掩码再求并集，最后做形态学处理。第一次踩进去的人会以为是阈值写错了，其实是模型边界理解不到位。
6.2 只设H不设V，暗部噪声会教做人
HSV阈值三件套里，H管色相、S管浓淡、V管明暗。新手常见失误是只设H。问题是暗处和噪声区域，因为传感器噪声，三个通道比例随机，H会乱跑；如果S和V下限不设，这些乱七八糟的暗像素容易被当成目标颜色。
实践建议：做目标颜色分割时，S和V都设置一个下限，比如S>40、V>40（按0~255），再排掉小连通域。宁可把阈值卡紧一点导致漏检，也比满屏噪声强。漏检还能靠形态学补，噪声会把结果完全毁掉。
6.3 “假饱和”：深色和浅色不能互相冒充
另一个坑是“饱和度可信度”。S很低时，H没有稳定意义，它只是灰色区域里的垃圾角；S很高，也不代表肉眼看着鲜艳，因为V还在参与感知。一个暗红色的HSV可能是(0°，0.75，0.2)，饱和度其实不低，但整体太暗，肉眼只会觉得它发黑发紫。
反过来，浅粉色S很低，但V很高，看着是柔和浅色。判断颜色时一定要把S和V放在一起读。很多人被“饱和度越高越鲜艳”这种简化说法害惨了：高饱和加低亮度，颜色照样沉闷；低饱和加高亮度，颜色反而清爽。
6.4 送自己一个小练习：用实物建立色相直觉
如果看完这些概念还是记不住，我个人建议做一个很土的练习：找三个有明显颜色的物体，比如橙子、青椒、深蓝笔记本，先肉眼估计它们的HSV范围，再用取色器或者读出像素值验证。坚持两三周，你对色相角度的直觉会变得非常准。以后再遇到颜色识别、调灯效、选配色，速度都会快很多。
颜色这件事，看着是数值问题，其实更多是模型选择问题。RGB让你“算颜色”，HSV/HSI让你“说颜色”。把每个模型该干的活分清楚，你调试时走的弯路会少一大半。
