先说一个我面试新人的经典问题：调试ISP时，工具里给你同一帧画面的三张图，一张灰绿带马赛克、一张有颜色但发暗、一张看着最“正常”，这三张分别是什么？能答上来的不算多。这个问题不是考记忆力，而是因为如果你分不清ISP处理中的Raw域、RGB域、YUV域，后面调起图像来就像闭着眼睛开车——看到一个现象，根本不知道是pipeline里哪一级搞出来的。
做图像工程师这几年，我越来越觉得，对这三个域的认知深度，直接决定了你在ISP调试里的定位速度。很多人一上来就背pipeline框图，把黑电平、坏点矫正、去马赛克、白平衡、CCM、gamma、降噪、锐化这些名词记得滚瓜烂熟，但真要处理一张偏色或者满是噪点的图时，还是不知道从哪里下手。原因很简单：没有建立起“哪个域的故障长什么样”的条件反射。
这篇文章我想把Raw域、RGB域、YUV域这几个概念彻底拆开讲一遍，包括每个域的底层数据形态、核心算法、调试要点，以及那些我在实际项目里踩过的坑。不管你是刚接触ISP的应届生，还是做了几年嵌入式、FPGA、相机调试的老手，如果能耐心看完，至少下次看到一张异常图，能先判断出问题出在哪个域。
1. 三个域到底指什么：先从一张Raw图说起
1.1 一个最常见的理解误区
很多教程喜欢把ISP画成一长串框图，然后标记“这里是Raw域，这里是RGB域，这里是YUV域”。框图画得没错，但问题是，如果只记名字不记数据形态，一到实战就会傻眼。
举个我自己经历过的例子。早年在做一颗车载sensor的调试，当时需要把sensor输出的裸数据用工具导出来看，我第一次打开那张raw图时，整个人都不好了。整张图灰蒙蒙的，带着明显的暗绿色调，放大后还能看到密密麻麻的方格纹理。我当时第一反应是数据通道配置错了，但反复检查寄存器都没有问题。后来带我的师傅说了一句让我记到今天的话：你看到的这一切，都是Raw数据最正常的样子。
Raw域、RGB域、YUV域这三个词，本质上描述的是图像数据在ISP流水线不同阶段的存在形式。Raw域是sensor直接吐出来的单通道Bayer数据，RGB域是每个像素都有完整R、G、B三分量的彩色数据，YUV域则把颜色拆成亮度Y和两个色差分量U、V。它们不是一个东西经过简单调色后的不同版本，而是数据组织方式完全不同的三个世界。
1.2 为什么图像工程师必须把三者分开看
说到底，区分这三个域是为了回答一个问题：某个算法应该在什么数据形态下执行，效果才最正确，或者说，效果才不会被破坏。
这个道理和做饭有点像。买菜、洗菜、切菜、炒菜是不同的阶段，每个阶段处理食材的方式不一样，你不能在切菜阶段就想着把菜炒熟，也不能在炒菜阶段才想起来洗菜。ISP也一样，黑电平、坏点矫正是Raw域做的，去马赛克、白平衡、CCM是过渡到RGB域后做的，降噪、锐化、饱和度调整放在YUV域更合适。如果忘记了这个先后关系，把算法放错位置，轻则效果不佳，重则会把图像处理出不可逆的伪影。
所以这篇文章不会只讲概念，我会把每个域的数据特征、典型算法、调试手法和踩坑记录都串起来讲，希望能给你搭一个完整的认知框架。
2. Raw域：一切从sensor输出的单通道数据开始
2.1 为什么Raw图看起来灰蒙蒙、绿油油的
先回答开头那个问题。很多人第一次看Raw图，都会被它的“丑”吓到。但这份丑是有原因的。
第一，Raw数据是线性光响应数据。sensor上的光电二极管把光子转成电子，电子数量跟光强在很大范围内是线性关系。这意味着，一个亮度值为200的像素，它实际接收到的光量就是亮度值100像素的两倍。听起来很合理对吧？但问题在于，我们平时看习惯了经过gamma校正和色彩增强的sRGB图像，那种图像在暗部会提亮，在高光会压缩，整体对比度和观感都更接近人眼。Raw数据没有经过这些处理，直接把线性响应摊在0到1023（10bit）或者0到16383（14bit）的数值范围里，所以在普通显示器上看起来会特别暗，暗部细节几乎看不清。
第二，Raw图看起来发绿，是因为Bayer pattern里绿色像素占了整整一半。常见的RGGB排布中，一个2x2的小方块里有两个G，只有一个R和一个B。如果按灰度图去显示Raw数据，绿色像素位置的灰度值天然就会更亮一些，整张图就会呈现出一种偏绿褐的色调。这不是sensor有病，而是Bayer阵列的固有特征。
第三，你放大Raw图看到的“方格纹理”，其实是马赛克本身。每个像素只记录了R、G、B三色中的一种，显示时人为用灰度去渲染，就会留下规则的格子状图案。这也是Raw域最本质的特征：它不是一张完整的彩色图像，而是一堆还没拼好的拼图碎片。
2.2 Raw域的核心算法：黑电平、坏点矫正、镜头阴影
sensor吐出来的Raw数据虽然“原始”，但并不能直接用于后续处理，必须先在Raw域做几个基础校正。
第一个是黑电平校正（Black Level Correction）。sensor的电路在完全没有光照时，输出并不是严格的0，而是会有一个偏置值，这个偏置就是黑电平。它来源于暗电流、像素复位噪声和读出电路的偏置。如果不把这个偏置减掉，整幅图像的黑色就不纯，而且在进行白平衡增益时还会把误差一起放大。黑电平的标定方法很简单，就是把镜头完全盖住，让sensor在全黑环境下输出，统计每个通道的平均值，这个值就是黑电平。注意，R、G、B通道的黑电平不一定完全一样，需要分开统计。
第二个是坏点矫正（DPC，Defect Pixel Correction）。传感器在制造和长期使用过程中，难免会有个别像素输出异常：有的恒亮，有的恒暗，有的输出值明显偏离真实光照。坏点分两种：静态坏点和动态坏点。静态坏点出厂时已经标定好，一般在初始化阶段加载一张坏点表去修；动态坏点则是在运行时实时检测，基本思路是拿当前像素和周围邻居做比较，差异超过阈值就认定为坏点，用邻域值替代。动态坏点的阈值调起来很讲究：调大了漏检，画面上会留白点；调小了误杀，正常的高频细节比如头发丝、树叶边缘会被当成坏点磨掉，产生模糊和“水彩化”痕迹。
第三个是镜头阴影校正（LSC，Lens Shading Correction）。镜头的边缘进光量天然小于中心，所以Raw图四周会比中心暗，这种亮度衰减叫lens shading，有些镜头还会带来颜色阴影，也就是中心和边缘的色温不一致。校正思路是存一张逐像素的增益图，然后在Raw域把四周的像素乘上对应的增益。这里有个关键点：因为Raw是线性数据，乘法增益能够真实恢复光强度。如果放到gamma之后再做，非线性变换已经改变了增益和亮度之间的对应关系，边缘的正中心亮度可能恢复了，但中间调和高光部分会出现非常奇怪的亮带。
2.3 Raw域的调试技巧与常见坑
关于Raw域的调试，我有一条铁律：先确认原始数据是干净的，再谈后面怎么调。具体来说，我拿到任何一颗新sensor，都会先做三件事。
第一，确认Bayer排布。RGGB、BGGR、GRBG、GBRG，这四种排布必须从sensor datasheet或寄存器配置里确认清楚。排布写错是灾难性的，后面去马赛克出来的颜色会整体花掉，很多人会误导成CCM或AWB的问题，调半天发现是排布错了。第二，盖镜头盖看黑电平统计值。如果Raw平均值离标称黑电平很远，先查寄存器配置，别急着动算法。第三，拍一张均匀亮度的灰卡或者对着白墙，找固定位置的亮点和暗点。如果发现固定位置的坏点，先查DPC有没有生效。
还有一个非常常见的坑：直接在普通看图软件里打开Raw文件，看到一片乱码就以为数据坏了。正确做法是使用ISP调试工具，比如海思、高通、安霸的tuning工具，或者用Python的cv2、rawpy之类的库做bayer预览，或者干脆先按灰度显示，用人眼去检查局部的异常纹理。
我再说一个看Raw图的心理建设：不要用sRGB的审美标准去评价Raw图。看到它暗、看到它绿、看到它花，都是正常的。如果一个Raw图看起来直接就很鲜艳透亮，反而要怀疑数据是不是已经被处理过或者被错误地转成了RGB显示。
3. RGB域：彩色世界从去马赛克开始重建
3.1 去马赛克：从Bayer到真彩色的插值艺术
Raw域是单通道的，要变成真正的彩色图像，第一步就是去马赛克（Demosaic）。它的任务是：每个像素自己只记录了一种颜色，需要用周围的像素信息把另外两个缺失的颜色猜出来。
最简单的去马赛克算法是双线性插值，就是取周围同色像素的平均值。速度快，但后果很典型：边缘会出现锯齿，有高频细节的区域会出现彩色的摩尔纹。稍微讲究一点的做法会先判断边缘方向，沿着边缘方向插值而不是横跨边缘插值，这样边缘就能保持锐利。再高级一点的做法会做色彩一致性约束，尽量减少边缘处的伪彩。
去马赛克的质量直接决定整张图的上限。后面所有算法做的都是“锦上添花”，但在去马赛克这一步丢失的细节，后面再努力也找不回来。这就是为什么现在很多高端设备开始使用AI去马赛克，本质上就是用更强的先验知识去重建缺失的颜色信息。
如果你是在FPGA上做ISP，去马赛克还有一个工程层面的难点。Bayer数据是按行输出的，每行只保留一种颜色，要计算出某个像素的RGB，必须等它周围几行数据全部到位。所以硬件上一般要准备三行甚至更多的行缓存（line buffer）。很多FPGA ISP的边缘花屏、横纹问题，追根溯源都是行缓存没做够或者跨时钟域没有处理好。
3.2 白平衡为什么要在线性RGB域做
去马赛克之后，图像变成了每个像素都有R、G、B三分量的RGB图，但这个RGB图的颜色还不准。这里有两大误差源：一是光源色温，二是sensor自身的光谱响应。
先解决光源色温问题。人眼有很强的色彩恒常性，一张白纸在暖黄灯光下看着是白的，在阴天冷光下看着也是白的，但sensor没有这个能力，它忠实记录光线的原始颜色，所以在低色温暖光下，白纸拍出来就是偏黄的。白平衡（AWB）要做的，就是估计当前光源色温，然后给R、G、B三个通道分别乘上不同的增益，让中性色重新变成中性色。
这里有一个关键问题：白平衡增益在哪个域做？答案是在线性光的RGB域做，或者等效地，在Raw域直接做。为什么必须在线性域？因为人眼对亮度的感知和光的物理强度不是线性关系，如果数据已经做了gamma校正，那么此时去乘通道增益，不同亮度区域的改变幅度是不一样的，会导致高光出现奇怪的色晕，阴影部分颜色又拉不回来。实际ISP实现中，AWB增益大多数是在demosaic之前直接乘在Raw数据上，这在线性数学上是等效的，逻辑上也可以看作线性RGB域的操作。
调试白平衡有一个非常朴素但高效的方法：拍一张标准的灰卡或白纸，看R、G、B三通道的直方图是否重合。如果三个通道直方图错开，那肯定先查AWB增益，不要急着动别的参数。
3.3 CCM色彩校正与Gamma映射
AWB解决了光源色温导致的偏色，但sensor自身的光谱响应曲线和人眼并不完全一致。即便白平衡已经准确，很多颜色拍出来还是不够正，红色不够纯、绿色偏黄、蓝色偏紫。这时候需要CCM（Color Correction Matrix），它本质上是一个3x3矩阵，把sensor的色彩空间映射到标准色彩空间，比如sRGB。CCM一般要针对不同色温分别标定，调试工具里通常会有多组CCM用于不同光照环境。
CCM之后是gamma校正。gamma做了一件看起来很简单但意义重大的事：把线性光映射为非线性编码。标准和常用的sRGB gamma值大约是2.2，它接近人眼对亮度的感知特性。之所以必须做这个非线性变换，是因为8bit图像总共只有256个灰度级，如果采用线性编码，暗部从0到10的灰度差异在显示器上会非常粗糙，色阶断裂肉眼可见。gamma校正把更多的编码空间分配给了暗部，让暗部过渡更细腻。
但gamma带来了一个非常重要的“禁令”：一旦数据过了gamma，它就不再是线性光了。所有必须在线性域完成的处理，比如白平衡增益、镜头阴影校正、CCM，都必须严格放在gamma之前。如果处理顺序错了，比如在gamma之后的非线性RGB域做白平衡或者CCM，就会出现我在3.2里说的那种诡异的亮度相关偏色。这条规则是ISP调试里不可破坏的底线。
3.4 RGB域调试时该怎么看图
RGB域是色彩问题的高发区，也是新手最容易瞎调参数的环节。我的建议是，按顺序排查，永远不要跳步。
第一步，灰卡测试。拍灰卡，看RGB三通道直方图是否重叠。如果不重叠，先查AWB，把三个通道的增益调到位。第二步，白平衡准确后再看色卡。用标准24色色卡，在调试工具里看每个色块在色度图上的位置，和目标坐标对比。如果某一组颜色偏差明显，比如肤色偏红或者天空偏青，再用CCM去修。注意CCM是强耦合的矩阵，改一个系数，整个色域都会受到影响，所以每次调整的幅度要小，并且要反复确认其他颜色没有被带偏。
我见过太多人一上来就调CCM，结果越调越乱。记住：AWB没有校正之前，你在CCM里看到的颜色偏差是不可信的，因为光源偏色和色彩响应误差混在一起。先把中性色调准，剩下的颜色误差才是CCM要解决的问题。
RGB域的另一个重要判断点是：线性和非线性的分界线。在调试工具里，demosaic刚出来的RGB图是线性的，看起来会比较暗，此时先去判断AWB、CCM。gamma之后的RGB图看起来已经接近人眼感知了，这时候的颜色调整要非常克制，因为这时你看到的偏差很可能不是RGB域的问题，而是YUV域色调映射的问题，盲目调整只会把前面的成果毁掉。
4. YUV域：把图像转成人眼更舒服的格式
4.1 从RGB到YUV：亮度与色彩分离的本质
经过gamma之后，RGB图像已经是一张能看的彩色图了，但ISP的pipeline到这儿通常不会结束。接下来，大部分相机和视频系统会把RGB转成YUV，然后才输出给编码器或显示器。这一步不是多此一举，而是有非常实际的理由。
人眼对亮度信息的敏感度远高于对颜色信息的敏感度。YUV格式恰好把亮度Y和色度U、V完全分开，这样我们就可以针对性地做处理：细节、纹理、边缘主要放在Y通道管；颜色偏差、彩色噪声主要放在UV通道调整。更关键的是，YUV格式天然支持色度子采样，比如视频里最常见的YUV 4:2:0，UV通道的分辨率只有Y通道的四分之一，直接省掉一半的带宽和存储空间，而人眼基本察觉不到。
RGB到YUV的转换是一个标准的线性变换。以BT.709为例，大致是Y = 0.2126R + 0.7152G + 0.0722B，UV分量则通过RG差值来构造。这个变换没有信息损失，在理想情况下是可逆的。不过在实际工程里，由于位深和量化精度的限制，来回转换会产生误差积累，所以好的ISP设计会尽量减少重复的往返转换。
4.2 YUV域的核心算法：降噪、锐化、饱和度
YUV域里最常见的算法有三个：降噪（NR）、锐化、饱和度调整。
降噪是YUV域的拿手好戏。sensor的噪声在弱光和高ISO下特别明显，表现为亮度噪声和色度噪声两种形态。亮度噪声是颗粒感，色度噪声是彩色斑点。在RGB域做降噪的问题在于，RGB三通道的噪声相互关联，你压制一个通道的噪声可能让另一个通道出现颜色偏差；而在YUV域，你可以对Y通道做适中强度的降噪来保持细节，对UV通道则可以放心大胆地做更强的平滑，因为人眼对彩色噪声的容忍度很低，但对色度细节的丢失并不敏感。这就是为什么几乎所有成熟ISP都在YUV域做降噪。
锐化也一样。锐化的本质是增强边缘处的局部对比度，但这个增强如果作用在RGB三通道上，很容易在边缘两侧形成过冲，产生彩色边纹。正确做法是在Y通道上做锐化，因为人眼的边缘感知几乎完全来自亮度信息，UV通道不需要做额外增强。
饱和度调整则主要作用于UV分量。UV幅值越大，颜色越浓郁；UV幅值越小，颜色越清淡。这个调节看起来直观，但调过头会让颜色溢出、肤色失真。特别是肤色，它是人眼最敏感的颜色之一，饱和度稍微超标就会被用户评价为“假”。
4.3 调试YUV域的实用方法
YUV域的图看起来最“正常”，反而最容易麻痹人。我的经验是，在调试工具里一定要把Y通道和UV通道拆开来看。
只显示Y通道，你会看到一张黑白图，这时候检查亮度噪声、边缘过渡、纹理细节最清楚。如果Y通道看着很干净，但整体画面发闷，那可能是对比度或锐化没调好；如果Y通道有颗粒状噪声，说明降噪没压住亮度噪声。再显示UV通道，也就是色度通道，这时候画面上出现大量彩色噪点的区域会非常抢眼。UV的伪彩色显示在这种检查里特别好用。
调降噪和锐化时要有耐心，它们是一对需要平衡的组合。我自己总结的经验是：先让降噪把明显的噪声压到“不干扰观看”的程度，然后让锐化把纹理细节拉回来，一次调一档，反复对比。千万不要把降噪拉到最猛，那样画面确实干净得像镜子，但纹理也全磨平了，走近看就像一张塑料。
5. 三域边界与最常踩的坑
5.1 处理放错域会出什么问题
我前面反复强调，每个算法要在对的域里做，这不是洁癖，而是处理效果的天壤之别。下面举几个真实发生过的案例。
镜头阴影校正放错域，是我见过最典型的例子。有人图省事，不校正Raw域的lens shading，而是把整个画面在RGB域直接乘一个增益图，想着也能把四周提亮。结果因为代码运行在gamma之后的数据上，靠近画面边缘的地方，高光区域因为增益过大直接过曝，还出现了明显的色偏。本来一个线性问题，在非线性域里硬做，就变成了一个亮度相关的非线性病。
锐化放错域也很常见。如果把锐化加在RGB三通道上，在物体的高对比边缘，RGB三个通道的过渡起点和终点不一样，锐化的过冲会放大这种差异，形成非常难看的彩色边纹。而同样的锐化强度放到Y通道上，边缘就干净利落，没有彩边。这个对比我做过很多次演示，每次都能让新人直观地理解“域”的重要性。
白平衡放到gamma之后做，表现则更加隐蔽。画面整体色温看着正常了，但高光区域出现了粉色或者青色的晕染，暗部区域的色偏却怎么都拉不回来。这就是因为gamma已经改变了通道间的比例关系，你在非线性域乘增益，不同亮度区域得到的颜色变化是不均匀的。遇到这种“亮度相关偏色”，第一个排查方向永远是：pipeline里有没有哪个处理被错误地放到了非线性域。
5.2 一图定位：偏色、噪点、白边到底哪个域的问题
实战中，拿到一张有问题的图，怎么快速定位？我整理了一张速查表，平时查问题基本靠它。
| 现象 | 优先怀疑的域 | 常见原因 |
|---|---|---|
| 全图暗部发绿、整体偏色 | Raw / RGB | 黑电平不准、AWB增益异常 |
| 固定位置亮点或暗点 | Raw | DPC失效、坏点表未加载 |
| 四周发暗（暗角） | Raw | LSC参数不佳 |
| 灰卡下RGB直方图不重合 | RGB（线性） | AWB增益不对 |
| 特定色块偏色明显 | RGB | CCM系数需要重新标定 |
| 高ISO彩色噪点多 | YUV | UV降噪强度不足 |
| 物体边缘出现彩色边 | YUV / RGB | 锐化加错通道、demosaic伪彩 |
| 画面清楚但颜色发闷 | YUV | 饱和度过低或UV范围被压缩 |
这张表的核心价值不是给你标准答案，而是帮你把排查范围缩小。很多ISP问题不是单一原因，但如果你能先锁定“哪个域最可疑”，再去翻那一级的中间图像，效率会高很多。
5.3 三域速查表
最后送你一张我是真的倒背如流的速查表，建议存下来或者贴显示器边上。
| 特性 | Raw域 | RGB域 | YUV域 |
|---|---|---|---|
| 数据形态 | Bayer单通道，马赛克 | 每像素3通道 | Y+UV分离 |
| 典型位深 | 10/12/14bit | 8/10/12bit | 8/10bit，常有子采样 |
| 亮度关系 | 线性光 | 前段线性、后段非线性 | 接近人眼感知 |
| 人眼观感 | 暗、绿、花 | 有色彩，可能偏暗/偏亮 | 最接近最终成片 |
| 核心算法 | 黑电平、坏点矫正、镜头阴影 | 去马赛克、白平衡、CCM、gamma | 降噪、锐化、饱和度、编码前置 |
| 调试重点 | 数据是否干净、排布是否正确 | 中性色是否准确、色卡是否达标 | 噪点平衡、锐化是否引入伪影 |
这张表看着简单，但每次我遇到一个复杂问题，都会回来扫一眼。它帮我避免了很多“在错误的地方找问题”的时间浪费。
再分享一个我个人的习惯：拿到任何一张有问题的图，我从来不靠猜，而是会打开全链路每一级输出的中间图像，从Raw、demosaic后的RGB、gamma后的RGB、YUV域的Y和UV，一路看下来，问题在哪一级开始出现，就锁定了哪个域。这个习惯帮我少调了无数冤枉参数，也让我在带新人的时候能非常快速地指出他们的问题到底出在pipeline的哪一段。希望你们也能养成这个“顺着链路找问题”的调试习惯。
