MTK平台上的AWB（自动白平衡）调试，说难不难，说简单也绝对不简单。我这两年大部分时间都在跟MTK的ISP和Camera Tuning打交道，AWB又是3A里最需要耐心的一项，写这篇小结（二）是想把从统计源头到最终参数落地这条链路再理一遍。上一篇讲了AWB的基本概念和灰世界、白点检测这些基础，这次重点放在工程实现和问题定位上，适合手头有MTK平台调试任务、或者刚接触Camera Tuning又想少走弯路的朋友。

AWB这个事，看起来好像只是“让白色变成白色”，但真正做下来你会发现，每个项目的偏色背后都是一长串模块的连锁反应。MTK平台的AWB不是独立存在的，它和AE、LSC、噪声抑制、色彩校正甚至是人脸检测都有耦合。这篇小结不会给一套万能参数，因为平台版本和模组差异太大，我更多想分享的是调试思路和排查路径，这些经验放到哪个项目上都适用。

1. MTK平台的AWB调试，到底在调什么

1.1 AWB在ISP管线中的位置，以及为什么它容易偏

MTK的camera hal里，AWB和AE、AF是并列的3A模块，但AWB对sensor原始数据的依赖程度最高。它不像AF那样有高频信息作为明确的“对焦评价”，也不像AE那样有亮度直方图这样直观的反馈。AWB吃的是每个block上的R/G/B平均值，一旦这些平均值因为镜头shading、sensor crosstalk、ISP坏点校正不过关而失真，AWB判断就会出错。所以调试AWB前，我通常会先确认前面几级ISP模块，比如OB（Black Level）、LSC（Lens Shading Correction）、BPC（Bad Pixel Correction）以及Noise Reduction是否已经调到一个可用状态。否则你会陷入“AWB怎么调都偏色”的死循环。

很多新人在调MTK平台时，第一步就打开AWB的表格去改色温曲线，这是本末倒置的。AWB在ISP管线的位置决定了它只能根据输入统计去做估计，如果统计源本身就已经有了几十个LSB的偏移，后面无论如何优化坐标都是治标不治本。我自己的习惯是先拍一张均匀光源下的灰卡raw，然后用MTK工具导出来看每个block的R/G、B/G分布是否集中，如果分布散得离谱，先回头处理shading和black level，不要急着动AWB参数。

1.2 白点统计与增益映射的关系

MTK平台通常会输出基于block的R/G/B/Y统计数据，AWB引擎会先根据亮度和色比做一次筛选，挑出“疑似白点”的block，再用这些白点的平均色比估算当前光源色温，最后生成Rgain、Bgain和Ggain回写到ISP。这个过程里，白点判定条件、不同色温下的白点坐标、以及最终增益的平滑策略，就是我们能调的核心参数。

很多刚上手的人容易把AWB的gain想象成一个简单的“1/平均色比”。实际不是这样。为了防止场景中只有一个大面积彩色物体时误判，AWB引擎会参考预设的已知光源坐标，把计算出的白点色比往最接近的标准光源方向拉一点。也就是说，最终增益是“统计白点均值”和“已知光源先验”的融合结果。理解这一点很重要，因为你会遇到一种情况：raw里灰卡的颜色看起来是准的，但最终出图却偏了，就是融合比例或者光源坐标设置得不对。

另外一个容易忽略的点是MTK统计窗口的权重。大部分平台支持对画面不同区域给予不同权重，比如中心区域更高、边缘区域更低；也支持人脸检测结果反馈进来，让人脸区域获得额外权重。这些联动功能很方便，但也会引入新的不确定性。我遇到过一个案例，画面中有人脸时AWB正常，人脸移出画面后立刻偏得非常厉害，就是因为HAL层把face区域强制拉高到了超过画面一半的权重，一旦没有人脸，统计失去了主心骨，白点分布直接失衡。

2. MTK AWB调试流程：从raw图到参数落地

2.1 调试前要准备什么

工欲善其事，必先利其器。MTK平台调试AWB，我基本离不开这几样：标准光源箱，至少包含D65、TL84、A光源，有条件的再加Horizon、U30；灰卡或者X-Rite ColorChecker；一台支持YUV/RAW dump的MTK调试机；MTK Camera Tool或者NVRAM editor；以及大量用来分析raw的Python脚本。要强调的是，光源箱的均匀性和色温准确性直接影响校准结果。我见过有人拿普通白炽灯当A光源用，折腾了一个月参数到了客户现场还是偏红，后来才发现光源本身色温就不对。这个坑只能靠正规的光源箱和色温计来避免。

除了标准光源，还有一个很容易被忽略的准备工作：确认sensor的AE收敛状态。AWB调试时如果AE还在来回波动，同一个光源下raw的亮度可能差好几档，这样统计出来的白点坐标会带有一层曝光残留，尤其是暗部噪声在不同曝光下变化很大。我一般会在固定色温、固定亮度下提前锁定AE，或者至少让AE完全稳定后再开始抓raw。这样调出来的AWB参数才不会被曝光变化干扰。

2.2 标准流程：拍摄、统计、调参、回写

我个人的标准流程可以拆成六步，每一步都有各自要盯的指标。

第一步，在标准光源箱里用目标模组装到MTK调试板上，用最新的固件和关闭所有其他颜色增强功能的状态下拍摄raw。每个光源至少拍灰卡、白墙、人像、静物各一组，画面不要有纯黑或者大面积反光物体，避免统计样本失真。

第二步，用MTK Camera Tool打开raw，选择对应的model，导出AWB统计信息。这一步能直接看到每个block的R/G、B/G值，以及AWB引擎判定出的白点。很多人会跳过这一步直接看效果，其实这时候才是发现问题的最早时机。

第三步，把已知光源的理论白点坐标叠加上去，检查raw实际统计的位置和理论值差多少。标准D65光源下，sensor raw的中性灰block应该在某个很小的范围内；如果偏差大，说明sensor calibration或者LSC还有问题。这个步骤本质上是在验证“输入是否可信”。

第四步，微调白点阈值和光源坐标，让每个光源下的raw都落在正确范围。白点阈值决定引擎会听谁的，光源坐标决定引擎认为什么颜色是“标准白”。两个要一起调，缺一不可。

第五步，生成NVRAM参数，刷入机器，在真实场景里做主观验证。注意真实场景和光源箱之间会有很大的环境差异，尤其是混合光源和反射光，一定要多换几个地方试。

第六步，回归测试。把之前整理好的历史场景库全部跑一遍，确认改动某一个光源不会引起其他场景的回归。这一步最容易被偷懒，但恰恰是AWB调试里最能体现功力的地方。

2.3 工具与参数的“地名手册”

MTK的工程文件在不同SDK里名称差异很大。有的平台把AWB参数放在awb_para里，有的叫awb_golden，还有一些新平台直接在vendor目录下的json或者xml里。调试前第一件事就是确认当前项目到底读的是哪个文件、哪一份配置。我吃过亏，连着调了两天参数，后来发现机器加载的根本不是我改的那份文件，而是模组flash里的备份，白白浪费了很多时间。

如果你手上是老旧一些的MTK方案，可能会看到一组名为r_gain、b_gain和gb_gain的校准值，这就是sensor默认的AWB补偿。不同色温下这组值应该成一个平滑的曲线，如果有跳点，通常说明光源标定或者sensor响应本身有异常。新平台则可能把AWB调色板拆成“golden sensor”和“module sensor”两套，“golden”用于研发基准，“module”用于产线校准，两者是相乘关系，拿到项目先分清主次。

工具方面，MTK提供的Camera Calibration Tool（CCT）适合做sensor级标定，另一个Camera Tuning Tool负责在线调参和raw回放。我习惯把两者配合起来用：CCT标定出sensor本征响应，Tuning Tool再去调场景相关参数。如果你的平台还带有AWB统计回放功能，一定要用起来，这个功能可以把一段实拍视频的每一帧统计点和最终gain变化画出来，比看静态raw高效得多。

3. 常见问题与排查技巧实录

3.1 场景切换时白平衡在色温之间来回跳

现象：D65光源下正常，面板换成暖色灯时Rgain/Bgain起伏大，画面一会冷白一会暖黄。

这种问题最常见的根因是白点检测阈值设得太宽，导致暖色光源下墙面、皮肤、木质桌面都被判定成“准白色”，AWB在多个候选光源之间反复摇摆。另外一个容易被忽视的诱因是AE变化：场景亮度一变，暗部噪声水平变化，参与统计的block集合也变了，AWB引擎就会重新评估色温，造成肉眼可见的跳变。

处理思路是先看统计日志，把每一帧的Rgain/Bgain和评估色温画成曲线，定位跳变发生在画面内容变化之前还是之后。如果发生在内容变化前，多半是阈值问题；如果发生在内容变化后，可能是场景检测或者光源切换的滞后不够。你可以调高帧间滤波强度，让AWB不会因为一两个异常帧就大幅调整增益，也可以调整不同光源的置信度权重。MTK新平台里关于multi-scene AWB的切换帧数建议不要小于15帧，否则在混合光源下很容易来回横跳。

3.2 暗光环境偏色，尤其是偏绿

暗光下最典型的偏色是偏绿，这几乎是所有CMOS sensor的通病。原因是低照度下sensor噪声会明显抬升G通道，让白点检测产生一个偏绿的偏移；同时暗部信噪比低，统计意义减弱，很多平台默认的暗区排除阈值又不够狠，导致大量噪声点进入白点统计。

排查时可以先看raw的亮度直方图，确认暗部是否还有有效信息。如果暗部几乎是纯噪声，那AWB再准也没用，这时候需要调低暗区亮度阈值，让极暗的block不参与白点统计。接着检查ISP的NR设置，过强的空间降噪会把彩噪磨成色块，反而让颜色产生色染，这时不应该靠AWB硬拉，而是回到降噪环节调整亮度噪声和色度噪声的平衡。

另外，暗光下AWB的gain通常会推到最大值附近，如果推满之后画面还是色偏，说明问题已经不在AWB，而是在CMOS色彩矩阵或者色彩校正矩阵。你可以做一个实验：关闭AWB，固定一组标准增益，拍一张暗光灰卡，看看RGB三通道是不是真的平衡。如果这一层的响应就是偏的，那AWB调破天也没有用。

3.3 强逆光或高光溢出导致偏色

大逆光或拍带强高光的金属物体时，画面高光区域会变成一片死白或彩色光斑，AWB有时候会往奇怪的方向偏。我遇到过一次在夕阳逆光下拍人，白平衡直接跳到9000K，整张脸都是蓝的，就是因为背景过曝区域把白点均值拉过去了。

发生这种情况时，首先要确认过曝的block有没有被正确排除。很多MTK平台有high light weight这一类参数，专门控制高亮block的权重，建议直接调低到接近0。但只调权重不够，你还要检查AE目标亮度是否合理，如果整个画面都在过曝边缘，那AWB和AE需要一起配合，而不是单独靠AWB的参数去救。

如果你正在调试HDR或多帧合成，AWB的统计必须基于合并后的raw，而不是单帧RAW。这一点很关键，因为HDR合成对不同曝光的RGB通道处理方式不同，直接拿单帧统计结果去套多帧合成后的数据，色温大概率是错的。MTK新平台对HDR和AWB的协同有专门的配置项，需要确认当前project是否开启了正确模式。

3.4 换一批模组后AWB全部偏色

同一个项目，换了一批模组之后，白平衡普遍偏黄或偏红，这种现象在量产中经常发生。原因倒不复杂：不同批次的镜头IR滤镜透过率可能有差异，sensor表面的滤色膜工艺也未必完全一致，所以基于golden sensor标定的AWB参数不能直接套用到所有模组上。

对于这种情况，正常做法是对每一批或每颗模组做单独的AWB标定，至少要在D65和A光源下各拍一组灰卡，算出Rgain/Bgain的偏移量，然后写入模组对应的校准区。MTK平台一般支持在产线做R/G/B gain微调，工厂端通过二维码或者测试工位的数据写进去。

另一个更隐蔽的问题来自镜头shading。如果换模组后LSC参数没有跟着变，画面四周的白点坐标会往某个方向飘，AWB看统计也没用，因为它在四周看到了大量“假色偏”。所以换模组后出现AWB异常，先别急着改AWB文件，花十分钟跑一遍LSC校准，往往比研究一天的AWB参数效率高。

3.5 人脸肤色偏色，但灰卡白平衡正常

这种问题在手机项目里尤其常见。用户在同一场景下拍灰卡，颜色是对的，一拍人像，脸却是蜡黄或者发灰的。原因多半是AWB统计和肤色检测之间没有做好联动，或者色彩校正矩阵在肤色区域出现了过饱和。

MTK平台通常支持在AWB统计中加入肤色权重，让肤色区域的block在判断白点时有更高的优先级。但这里有个度的问题，如果权重太高，一旦画面里没有肤色，算法会失效；如果权重太低，肤色区域的颜色又会被整体环境色温带跑。我的做法是先在标准光源下拍不同人种的肤色板，找出肤色block在R/G、B/G图上的分布区域，再反向调整肤色权重和多场景切换策略。另外，肤色偏色还可能是CCM（颜色校正矩阵）在低饱和区域过冲，这和AWB没关系，需要到CCM模块去排查。

4. 从原理层面理解MTK AWB的几个关键点

4.1 白点检测的阈值和区域划分

MTK的AWB统计里，每个block会计算出一个R/G和一个B/G值，本质上就是把每个区域投影到一个二维色比空间里。所谓“白点检测”，就是在这个二维空间里圈一个范围，落在范围内的block才会被用来估计白平衡。这个范围通常由一组阈值或者多边形顶点定义，不同色温下的标准白点会形成一条曲线，范围就是围绕这条曲线的tube。

阈值卡得越紧，检出白点越少，误检率低但容易漏检；阈值卡得越宽，检出白点多，覆盖率好但误检也高。我常用的方法是：先放宽到所有光源下都能看到一大片白点云，然后在包含单色物体（如大片红色墙）的场景里测试，慢慢缩小范围直到纯色物体不再被误判成白点为止。这个过程没有捷径，就是拿场景迭代。注意不同亮度下白点云的形状会变化，所以阈值还需要跟着亮度分段，不能只用一个静态区域。

4.2 光源坐标和校准矩阵为什么要分开看

AWB引擎之所以需要“光源坐标”，是因为它要在统计白点均值的基础上做先验融合。每个标准光源都会有一个理论上的R/G、B/G坐标，MTK平台引擎拿到这些坐标后，会结合当前统计值判断“画面最像哪个光源”，再决定最终增益。如果你改错了光源坐标，统计出的结果就算正确，最终输出也会被拉偏。

这里面最容易犯的错是把AWB的偏色都归咎于光源坐标不准，然后去硬调坐标。实际上，很多“光源坐标不准”的假象来源于更前面的sensor校准偏差。你拿一颗sensor在D65下用积分球拍灰卡，如果R/G、B/G本身就不在理论位置，那么无论你怎么调AWB坐标，最后出图还是偏的。所以CCT校准和AWB调试是两件事，不要混在一起。先确保sensor层面响应一致，再去看AWB层面是否需要修正。

4.3 帧间稳定性与场景识别如何权衡

AWB的帧间平滑也是MTK调试中一个绕不开的模块。简单说，如果每一帧都完全独立地估计光源，那画面一旦出现轻微晃动或者物体进入画面，增益就会跟着跳动，观感非常差。所以AWB引擎通常会对上一帧的增益做低通滤波，也就是所谓的smooth factor，这个值越大画面越稳定，但响应越慢。

我在实际项目里的经验是：从亮处切到暗处时，收敛可以慢一点，因为人眼进入暗处后本身也需要适应，轻微的偏色不会立刻被察觉；但从暗处切到亮处时，收敛一定要快，否则用户举起手机一看还是偏的，会立刻觉得成像差。MTK平台如果允许分开配置不同亮度方向的收敛速度，尽量分开调。如果只能配一个全局值，我会优先保证从暗到亮的响应，因为这种场景更容易被用户抓住问题。

另外，场景识别和AWB策略也是联动关系。风景模式可能更偏向全局灰世界，人像模式会让肤色区域占的权重更高，夜景模式则会把低照度下的噪声排除做得更激进。MTK的新平台会把这部分做成一个策略表，由场景检测结果来切换。调参时一定要确认当前项目是否开启了场景检测，如果没有场景检测，很多新平台的AWB参数实际只走了一半，效果自然不对。

5. 一点经验与后续可以继续做的事

5.1 调试过程中最值得养成的几个习惯

第一个习惯，每次调参前都备份一份可用的AWB配置。我在本地用git管理所有项目的NVRAM配置，虽然听起来很土，但能让你在改出问题时大胆回退。很多工程师喜欢直接覆盖，结果一个光源调好了，另外两个光源全崩了，想回退又找不到上一版，只能靠记忆恢复，非常痛苦。

第二个习惯，记录“光源-白点分布-最终gain”的截图，形成一个数据库。AWB的问题很多时候不是“这次调好了”就结束，而是会在几个月后换一批模组、换一个场景再次出现。如果你有历史资料，几分钟就能对比出差异，不需要重新推导一遍。我通常会在每个项目下建三个文件夹：raw_origin、stats_debug、final_parameters，后者里面存最终发布的配置文件和历史版本。

第三个习惯，别只对着灰卡调。灰卡只会告诉你中性色的绝对正确，但用户实际拍的是人脸和物体，场景都带颜色。所以每轮调试除了在光源箱拍灰卡，必须在实景中做人眼主观验证。尤其要拍建筑外墙、绿植、肤色这几个“敏感又高频”的场景，主观感受比任何客观指标都更接近最终用户。

5.2 接下来可以尝试的方向

如果是在MTK新平台上做AWB，强烈建议研究一下AI AWB和场景识别这块。神经网络模型能根据整幅画面内容判断光源，对大面积色块、夜景这些传统统计最难搞的场景会有明显改善。但要注意，AI AWB的训练数据和你实际项目的场景分布直接挂钩，不是平台自带的模型就一定适合你的客户偏好，往往需要做针对性重训或微调。

另外可以做一个小工具，把产线测试数据拉下来，自动算每颗模组的AWB偏移并生成校准值。这个方法能大幅减少换模组批次后的调试成本。直接读raw的R/G、B/G，和golden sample做差，再把差值生成一个补偿文件，整个流程只要脚本化，半小时就能跑完一个批次的模组。

AWB这个方向的深度还远不止这些，包括dual LED闪光灯下的AWB融合、变焦切换时的白平衡接力、屏幕补光模式下的色温补偿，这些都是实际项目中会遇到的新课题。每一个都可以单独拿出来写一篇小结。这篇先到这里，后面有机会我再把“多摄切换和AWB联动”这块踩过的坑整理出来。

我个人感受最深的一点：AWB不像AE那样用一两个指标就能验收，它太依赖“场景感受”了。有时候客观数据全绿，用户就是觉得“不对味”，所以多留一些现场主观测试的影像资料，比什么都管用。最后说一个小习惯：每次拿到新raw，我会先在电脑上把它转成16bit TIFF，再用脚本画一张R/G vs B/G的散点图。这既是调试的第一步，也是排查所有色彩问题的第一步。