企业官网建设流程全解析

这些天又捡起MTK平台的Camera调优项目，把AWB这块重新过了一遍。上一篇小结把整体框架和基本概念讲得差不多了，这篇打算换个接地气的写法，主要说说我在实际调MTK平台AWB时走的弯路、用的工具、以及最后沉淀下来的那套调试方法和判断标准。老规矩，不写教科书内容，写的都是能直接拿来用的。

我知道打开这篇文章的兄弟，大概率已经被手里的项目折磨过一轮了。要么是刚接手一个MTK平台的项目，对着sensor tuning文件一脸懵；要么是遇到预览偏色、拍照颜色发闷、场景一切换白平衡就乱跳这种疑难杂症。无论你是刚入门想搞懂AWB到底在干什么，还是已经调了半年想找点排查思路，这篇小结应该都能给你一点参考。

MTK平台这几年在Camera调试上的工具链其实已经相当成熟了，但问题也恰恰出在“成熟”这两个字上——参数太多了，文档太散了，新手根本不知道从哪里下手。我自己刚接触的时候，光搞明白tuning数据里那些参数文件的关系就花了不少时间。这篇东西与其说是教程，不如说是我自己踩坑之后的经验沉淀。

1. AWB在MTK影像链路里的真实位置

1.1 从RAW到YUV，AWB到底卡在哪一步

很多人做AWB调试做了好几周，但你要问他AWB在ISP pipeline里到底嵌在哪个环节，他反而是含糊的。这个不是小问题，因为对链路位置的理解，直接决定了你遇到问题时的排查方向。

MTK ISP的处理流程大体上是这样：Sensor把RAW数据送进来，经过坏点校正、镜头阴影校正、黑电平校正，然后就到了白平衡增益应用这一步。这个增益是怎么来的？是靠上一帧的RAW统计信息通过AWB算法计算得到的。再往后，才轮到去马赛克、色彩校正矩阵、Gamma、降噪这些环节。也就是说，AWB作用的位置在RAW域，作用的方式就是对R、G、B三个通道乘一组增益系数，目标是把场景中的中性色拉回到R=G=B的状态。

实际调试时这个“位置感”很重要。我遇到过几次偏色问题，排查了半天以为是AWB参数不对，最后发现是CCM矩阵或者色彩增强模块在捣鬼。原因就是我在预览流里看到的是经过完整pipeline的图像，如果AWB已经把白平衡校得很准了，但画面依然偏色，那问题大概率在后面那些戏台环节，而不是AWB本身。这个你在debug的时候一定要有数，别一个方向怼到底。

MTK的ISP统计模块会按区域把画面划分成网格，然后输出每一个格子的R、B与G的比例关系。AWB算法看到的就是这一张统计表。这张表的采集密度、曝光状态、增益状态，都会直接影响AWB的输入质量。所以有时候AWB不准，还真不是AWB的锅，而是你AE给的曝光不好，统计信息质量太差。

1.2 MTK项目的AWB相关文件与数据流

MTK平台的tuning体系这些年变化不小，老平台和新平台之间路径差异比较大，但思路是相通的。一般来说，Camera的tuning数据会放在vendor目录下，内容和sensor型号、模组厂、光学校准相关。AWB的参数通常不在单独一个文件里，而是散落在整个sensor tuning文件、以及3A相关的公共配置里。

我得强调一个很容易踩的坑：同一个sensor在不同的模组上，或者同一个模组搭配不同的镜头，AWB参数可能差异很大。别想着直接拿别人项目的tuning文件过来凑合，那样十有八九会翻车。MTK平台里偶有prj对sensor做统一配置的情况，但你作为调试者，最好还是逐个模组确认。

从数据流的角度讲，AWB参数的来源大致是这么一个链条：DCC工具初始化校准数据，产线或者实验室会通过金机拍图获得光源样本，生成光源坐标和增益曲线，最后这些数据被编译进固件或者tuning文件。等到机器跑起来，ISP每帧出统计信息，3A算法根据这些统计信息和当前光源环境的判断，输出一组AWB增益。

明白这个链条之后，你拿到一个偏色的机器，第一反应应该是：当前机器有没有加载正确的tuning？是不是金机标定数据没生效？别上来就开DCC工具去改参数。我有一次debug，改了一下午AWB增益，预览颜色死活不对，最后发现机器的tuning分区选错了，压根没加载我的改动。这种低级错误浪费的血泪时间，是最不值得的。

2. MTK AWB的核心逻辑与参数体系

2.1 色温、光强与R/G、B/G空间

要说AWB算法，绕不开的就是色温和光强这两个概念。但真正在算法内部，不是直接用“色温”这个值来算的，而是用RGB通道之间的比例关系来描述的。

人眼看到一块白色的纸，在暖黄的光线下会看到“偏黄的白色”，到了阴天又看到“偏蓝的白色”——但人脑知道它是一张白纸，会自动把环境光的影响扣掉。AWB算法的目标就是这个：把不同光源下原本应该是中性色的物体，保持成中性色。MTK的AWB算法内部维护着一个坐标系，横轴是B/G的比例，纵轴是R/G的比例，不同光源在不同色温下会落在这张图的不同位置。

D65标准光源大概是6500K的色温，R/G和B/G的比例比较接近1比1；而A光源，就是那种白炽灯，色温大概2856K，R/G比例明显升高，B/G明显下降。实际算法里，MTK会在DCC工具里预设一组标准光源的位置，比如D65、A光、TL84、CWF、Horizon等等，然后根据当前帧的统计信息，看它落在这些已知光源轨迹的哪个位置，再通过插值的方式推算出一个当前环境的增益。

这套逻辑的好玩之处在于，如果现场的光源在标定的时候没覆盖到，或者场景里压根没有中性色物体，AWB就开始“猜”了。猜得准不准，跟你标定的光源区域划分有直接关系。我之前遇到一个场景，室内是暖色LED，窗外是阴天日光，AWB在两者之间来回摆动，就是因为标定数据中这两个光源之间的过渡区域划分太宽泛，给了算法太多“自由发挥”的空间。

2.2 区域划分与光源判断的工程细节

MTK DCC工具里有一块专门做AWB配置的地方，核心的工作就是调整光源之间的区域划分。这块调得好不好，直接决定了机器在不同环境下切换的平滑度。

DCC工具会把R/G-B/G平面划分成很多区域，每个区域会绑定一个增益值或者一个色温倾向。如果你的区域划分太粗，算法在边界附近会非常纠结，表现为取景时白平衡轻微抖动；如果划分太细，又容易造成环境细微变化时白平衡过分敏感。所以这个度要自己把握，经验法则是在你最常用的场景下尽可能稳定，在不重要的边缘场景下允许算法“猜错”。

光源判断的逻辑本质上是一个概率模型。MTK的AWB库里，一般会维护多个候选光源，每个光源有一个置信度，最后根据置信度加权得到最终的AWB增益。这个置信度跟什么有关？跟统计信息落点为光源中心点的距离有关，距离近置信度高，距离远置信度低。

调试的时候，我最常用的一个手法就是对着灯箱切光源，观察切光瞬间AWB的响应速度和最终收敛颜色。响应太快，往往会抖动；响应太慢，就会被人拍出明显的偏色，两者要平衡。MTK工具里一般会有相应的阈值的调节项，但每个平台的参数名不一样，这边不具体指向某一个，你在自己项目源码里搜wb相关配置，找到响应速度控制的参数就对了。

2.3 别忽视那些“不起眼”的门槛参数

AWB不是只有一个区域划分就能完工的。实操中你会发现，还有一堆门槛参数躲在配置文件的角落里，但正是这些参数，决定了用户体验的成败。

比如低照度下的AWB锁定策略。环境光暗到一定程度，统计信息的信噪比急剧下降，这时候如果还按照正常策略做AWB，结果就是颜色乱飘。MTK平台通常会做一个策略：当亮度低过某个阈值后，直接锁定前一帧的AWB增益或者切到固定色温的增益。这个阈值和策略的行为是需要你根据项目实际去调校的。

再比如闪频带来的影响。室内荧光灯下，如果曝光时间没有避开市电频率的倍数，画面亮度会有波动，统计信息也跟着波动，AWB就会被带着走。MTK的AE模块一般有防闪频的机制，但AWB这边如果没有对应的滤波逻辑，还是会出现彩条或者偏色。所以调试AWB之前，先确保AE的防闪频配置是正确的。

还有“灰点”条件。AWB统计信息里并不是所有像素都能作为参考的。颜色太饱和的点、亮度太亮或太暗的点，这些都应该被排除掉。MTK平台会提供一套类似阈值的东西，这些阈值控制允许参与白平衡统计的像素范围。有时候画面中大面积纯色物体存在，比如一堵红墙占满画面，AWB就会把红色当成环境光，导致整个画面偏青。这种场景下你就可以适当收紧灰点范围，让过于饱和的像素不参与统计，但代价是低照度下可用的统计点可能不够。需要用调试确定一个平衡点。

3. DCC工具下的AWB标定实操

3.1 前期准备：金机、灯箱、灰卡一个都不能少

做AWB标定，实验室准备工作极其重要。我见过不少人在线上环境直接拿手机拍几下就开始改参数，我只能说，这种玩法出来的东西基本靠运气。

一台靠谱的“金机”是做标定的前提。什么叫金机？就是硬件状态经过验证、没有偏色、HAL和内核版本都正常、温漂也在可控范围内的参考样机。这台机器本身就是一个标尺，你得先把它的AWB调准了，拿它做基准去标定不同光源下的参数，然后才能在它基础上调试其余机器。

灯箱这块，如果是做手机或平板的Camera调优，一般至少需要一个能提供D65、A光、TL84、CWF、Horizon这些标准光源的对色灯箱。DNP、Judge II或者国产的一些灯箱都能用，关键是光源切换要方便，并且灯箱内部空间要够大，方便你放测试图卡。不要以为只有一个D65就能搞AWB标定，真实环境里用户用得最多的其实是室内混合光。

最容易被忽略的其实是灰卡和色卡。灰卡用来定义中性白，而色卡（比如24色卡）可以顺便用来验证色彩还原。我自己的习惯是，在每轮标定之前先把灰卡拍一遍，确认当前光源下灰卡的RGB统计值是否符合理论值，然后再继续。这样能避免因为灯箱老化或者光源不稳定导致的标定误差。

3.2 标定的步骤记录与关键参数说明

MTK DCC工具的具体界面每次平台换代都会改，但整个操作流程是很经典的。我来说一下我通常的做法，你可以根据手头工具微调。

第一步，选对传感器配置文件。在DCC工具里先加载当前项目对应的sensor tuning文件，紧接着连接金机，确认工具能正常读到ISP的统计信息。

第二步，拍摄并捕获原始RAW图。这一步的目标是采集到足够干净的RAW数据。每切换一个光源，都等光源稳定之后再拍摄，拍摄时保证画面上有一个标准灰卡区域，最好是画面中心位置。如果灯箱有多个灯管，确保灰卡表面没有反光斑点。这个RAW图是后续所有标定的基础数据，你得保证它的质量。

第三步，在DCC工具里导入RAW图，工具会自动统计出灰卡区域的R/G和B/G实际值。这里有一个关键操作，就是要检查这个统计结果的合理性。比如在D65光源下，R/G和B/G如果严重偏离1比1，那说明灰卡区域选取有问题，或者当前光源色温不准，别急着继续，先查明原因。

第四步，把统计出的坐标点添加为当前光源的样本点。每个光源最好采集5到8个不同亮度的样本，形成一个分布区域。如果只采一两个点，算法很容易过拟合，换个光照角度就不准了。样本点的亮度分布最好覆盖从偏暗到正常曝光的范围，这样才能帮助算法理解不同曝光下的增益变化。

第五步，全部光源样本采集完成后，在DCC工具里调整光源间的区域边界。这一步骤最考验经验和感觉。工具会显示每个光源样本点分布的范围，你要做的就是把相邻光源的边界放到它们之间的“谷底”位置。边界放得太靠光源中心，切换就会太敏感；放得太远，则会响应迟钝。

第六步，导出配置文件并验证。标定完成之后，把参数写入tuning文件，重新编译或者以调试模式推到金机上，然后恢复到你最初的场景，重新验证每个光源下的白平衡表现。注意验证的时候一定也要看切换过程，而不只是盯着一帧静止画面。

3.3 一个案例：为什么同样的环境，预览和拍出来的AWB差异这么大

这是一个我实际遇到过的案例，说多了都是泪。一个项目在实验室标定的时候，灯箱D65下预览的颜色非常正，客户也很满意。结果样机一到现场，客户在办公室日光灯管下拍了几张照片，反馈说颜色偏黄。我第一反应是是不是TL84下的标定数据没生效？回实验室复测一切正常。

最后排查了半天发现，问题出在“预览”和“拍照”走的是不同的AWB路径。MTK平台在某些设置下，preview模式为了流畅度，AWB算法的迭代频率和统计窗口大小可能和capture模式不一样。实验室里我盯着预览看，自然觉得没问题；但客户按快门之后，capture阶段重新计算了白平衡，计算方式跟preview不同，于是拍出来的照片和预览完全不同。

这个问题不只能在MTK上遇到，但MTK平台确实是有自己的配置开关。解决方案是在preview和capture之间做参数一致性校验，或者在DCC工具里同步两者的AWB相关配置。遇到类似情况，你可以先从这边入手排查，别一上来就去调光源坐标，白费力气。

4. 调试图谱：从光源判断到场景适应

4.1 一个典型调试场景的全流程复盘

好的AWB调试，不是对着工具点点点，而是先在脑子里过一遍“我要用户看到什么”。下面用一个典型流程来复盘。

假设你正在调试一款主打人像拍摄的项目，卖点是肤色自然。用户最常拍的是什么？室内、室外、逆光、夜景，以及各种自拍。那你做AWB调优的时候，重心就应该向这些场景倾斜，而不是只对着灯箱里的标准光源较劲。

室外阳光场景相对简单。D65光源下，AWB大概率是准的，你需要关注的就是在树荫下、建筑物阴影里这些“实际上色温偏高”的区域，算法是否有足够的光源覆盖。阴影下的色温通常在7000K以上甚至更高，如果标定数据里没有覆盖这个范围，画面就会偏蓝。

室内场景是重灾区。现在的商用照明鱼龙混杂，所谓“白光LED”很多色温都在4000K到5000K之间，与TL84和D65之间差距很大。如果你只在TL84下做了标定，实际到了现场就会偏黄。我的建议是，室内场景宁可在多个色温点都加样本，也别嫌麻烦。

夜景和低光场景，AWB的目标不是“绝对准”，而是“看起来舒服”。因为统计信息质量差，强求准确很容易导致颜色飘忽不定。这种时候MTK平台都会有一套往暖色方向偏移的策略，美其名曰“氛围感”。你实际调的时候可以保留一定偏移，但不要太多，否则夜景人像会成黄脸婆。

4.2 混光与低照度：两个最让人头大的场景

混光环境，本质上一个画面里出现了两个色温差异很大的光源。比如室内是暖光，窗边是冷色日光。这种情况人眼很自然地能判断出“这束光是暖的，那边是冷的”，但相机里的AWB不得不做一个全局决策：整张图只能选一个白平衡增益。

MTK平台在这种场景下的处理思路一般是以主体区域为主、其他区域为辅。比如在人像模式下，如果算法能检测到人脸区域，会给画面中心或者人脸区域加更高的权重，优先保证人脸的颜色正确。这也是为什么有些场景背景颜色会略有色偏，但人物肤色正常——这其实是刻意为之的策略，不是什么bug。

调试混光场景时，我的建议是不要试图做到“全画面都准”。没有厂商能做到这个，因为算法没有一键分离光源的能力。你需要做的是定义清楚画面的“优先级中心”，然后让AWB围绕这个中心来决策。

低照度场景的AWB难点在于统计数据的信噪比低。我实测过一个场景，环境照度只有5 lux左右，画面大部分区域都是偏暗的噪声，统计出来的灰点东一块西一块，AWB结果每帧都在跳。这种时候，直接在参数层面加滤波不如在策略层面加限制。MTK平台一般都有低照度锁定或者低照度下固定色温的策略选项，你要做的是找到这个选项并配置好阈值。

顺便说一句，如果你在低照度下发现颜色偏品红或者偏绿，排除AWB因素之后，记得检查sensor的暗电流补偿和黑电平校正。这两个模块如果有问题，会让暗部的偏色蔓延到整个画面的颜色感知上。这不是AWB能解决的。

4.3 动态范围对AWB统计信息的干扰

高动态范围场景对AWB的影响，平时聊的人不多，但实际很常见。比如逆光人像，背景很亮、人脸很暗。如果AE把曝光压在背景上，人脸就变成了一团黑色；如果提亮人脸，背景又过曝。AWB统计很容易被大面积过曝区域干扰。

MTK的ISP统计模块一般可以配置对过曝区域或者欠曝区域做“忽略”处理。你调AWB的时候，一定要看这些区域被排除后的统计结果是否干净。有时候画面偏色，就是因为你把一大块过曝的白色墙壁也纳入了AWB统计。过曝区域的RGB比例已经失真了，用它来算白平衡，结果可想而知。

我在DCC工具里调整AWB时，通常会做一件事：打开统计窗口的可视化显示，过曝区域用红色标记，欠曝区域用蓝色标记，这样能直观看清楚当前配置下哪些区域被纳入了AWB统计。这个习惯帮我避免了大量“看起来参数没问题但上机就是偏色”的尴尬。

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

5.1 偏色、抖动的排查顺序不能乱

这一节直接给排查路径，你在现场照着做就行，能省掉不少弯路。

第一步，确认加载的tuning文件版本对不对。这个可以查log，确认当前机器加载的sensor tuning路径和编译时间。很多偏色问题压根不是参数问题，而是你改了半天，机器根本没在跑你改的那份参数。这个确认动作应该花不到10分钟，但它能挡住80%的无用功。

第二步，确认当前场景的光源信息。用我们已经验证过的金机在同一个场景下拍照，看金机是否偏色。如果金机也偏色，说明这个场景的光源本身就需要特殊处理，或者超出了你的标定范围；如果金机正常，那问题出在你手上这台机器自身，可能是硬件差异或者tuning偏差。

第三步，看AWB统计信息。切到ISP的debug模式，输出当前帧的AWB统计信息，看输出的R/G和B/G值落在坐标系的哪个位置。如果统计信息本身是收敛的但输出画面偏色，问题可能在CCM或者gamma那边；如果统计信息一直在跳来跳去，那就是AWB算法收敛的问题。

第四步，看AE的曝光情况。曝光异常会导致统计信息质量变差，影响AWB判断。先确认AE是稳定的，再回头找AWB的问题。

这个排查顺序我称之为“先环境、后机器、再软件、再曝光”。你别颠倒顺序，否则很容易陷入“改了下AWB参数好像好了、换个场景又坏了”的死循环。

5.2 常见典型问题速查表

这张表可以当手术前检查单用。每个问题对应的解决方案不一定一次就能到位，但排查顺序是对的，最坏情况也就是多花点时间调参数，不会迷失方向。

5.3 一些日常调试中容易被忽略的操作细节

调试MTK AWB没有太多神秘技巧，但有一些操作细节能帮你减少很多返工。我列几个自己一直在用的习惯。

第一，每次修改参数之后，做记录。不是简单记一下“改了什么”，而是记“为什么改、期望达到什么效果、上机验证结果如何”。AWB参数往往互相牵连，调这个可能影响那个。没有记录的习惯，三天之后你回头看自己改的参数，根本想不起来当初为什么要这么改。

第二，专门准备一台“陪测机”和“验证机”。陪测机用来干活，验证机只在关键节点烧录测试。很多人就是一台机器反复烧、反复测，最后机器老化带来的偏色问题混入了AWB调试问题，徒增烦恼。

第三，关注系统时间信息。3A日志里的时间戳、曝光时间、增益值这些细节，在复现问题的时候非常有用。如果你是在多次尝试后才能复现一个偏色问题，建议把相关log完整保存下来再开始排查，别等到问题再出现才到处找log。

第四，不要迷信“金机标定数据直接套”。每一台手机之间sensor本身的暗电流、镜头的穿透率都存在微小的个体差异。产线的标定数据（比如镜头校准、白平衡校准）在量产时是需要的，但实验室调试阶段，你先把金机的参数弄准，再拿普通样机对比差异，这才是正常的节奏。

6. 一些工程协作中的额外心得

6.1 别让其他模块的“邻居问题”耽误了AWB

MTK平台上做Camera调试，经常会被一些跟AWB没有直接关系的异常牵着鼻子走。比如有人反馈预览黑屏、开机Camera闪退、adb连接不上，这些大概率是平台集成的问题，跟AWB参数没有任何关系。

我自己的习惯是，如果AWB问题迟迟没法复现，就停下来思考一下是不是平台本身有别的幺蛾子。比如我印象很深的，有个项目在某个SDK版本上，GPIO配置有问题，导致Camera模组的供电时序不稳，预览偶尔会出现奇怪的偏色条纹，看起来特别像AWB故障。排查半天，最后是修改了GPIO初始化顺序解决的。

所以在你的调试流程里，建议第一步先用老化测试和压力测试把硬件稳定性跑一遍。如果连稳定预览都做不到，就别急着调AWB参数。这根弦绷紧了，可以帮你省下大量时间，不然你会在一条黑路上越走越远。

6.2 团队协作时的AWB参数管理

如果你的项目有多个工程师在同时调试，AWB参数的管理会很快变成一个痛点。每个人都改一版，合在一起冲突不断。我自己比较推荐的做法是建立一个简单的“版本基线”机制。

首先约定谁是代码库的主干维护者，所有AWB参数改动都通过这个主干工程师合并。其次每次版本合入必须附带修改说明，说明内容包括修改的光源范围、期望解决的场景、验证机器的序列号。最后，在每次大的版本合入后，指定一个人专门做回归测试，把所有标准场景过一遍。这样看起来好像多了一些流程，但实际执行下来比大家各改各的、最后来回去对齐要高效得多。

不要只用一个excel记参数变化，那个东西很快会过时。直接在代码注释和提交说明里写清楚，比什么文档都好用。

6.3 一个额外的小技巧：用RAW分析来校验AWB结果

最后分享一个小技巧，是我最近在做的：拿RAW文件做AWB的离线分析。具体做法是在出问题的现场拍摄RAW格式照片，然后在电脑上用工具对RAW做黑电平补偿和线性化，再手动调节R/G/B增益，直到画面里的灰卡变得中性。这样你就能在没有真机的情况下，快速算出一张照片“应该”呈现的AWB增益，然后再回实验室把这个增益值跟实机输出的统计做对比。

这个方法的好处是不会受到ISP后续流程的影响。因为RAW就是最原始的数据，你手动算出来的增益是理论上的目标值，它不会欺骗你。最近几次AWB疑难杂症都是靠这个方式最终定位到真凶的。

当然，这个方法也有个前提，你得确认RAW确实没有被AWB预处理过。MTK平台的RAW dump一般可以关掉ISP的一些自动处理，你一定要在抓RAW之前把相关选项确认好。如果RAW本身已经被AWB调过了，那你离线分析出来的结果就没什么参考价值了。

总的来说，MTK平台AWB调试这件事，核心不在于你有多熟悉工具按钮，而在于你能不能理解算法背后的逻辑，能不能形成一套自己的排查体系。这篇小结记录的这些经验，都是我实际项目中一遍遍试出来的。工具每年都在变，但底层逻辑和分析方法不会过时。希望这篇东西对你手头的项目有帮助。