在瑞芯微平台上做isp调试尤其是白平衡调试AWB说实话是个“入门容易、做精很难”的活。很早之前我在RK3568上接一颗OV5695的sensor第一次拿到RAW图时整块画面明显偏品红客户截图发过来第一句话就是“白平衡调一下吧”。我当时第一反应也是AWB但后来花了一整个下午把BLC、LSC、AWB、CCM、GAMMA逐级分开排查才发现真正的问题藏在LSC标定数据和镜头光学特性不匹配里AWB本身其实已经算得很准。这篇文章我把围绕瑞芯微isp调试里AWB模块的完整经验整理出来内容包括AWB在ISP pipeline中的工作边界、IQ配置文件里每个关键字段的实际用途、从抓RAW到不同色温全覆盖的完整调参流程以及几个真实项目里踩过的深坑和排查思路。适合手里拿着RK3568/RK3588/RV1106这类板子、sensor能正常出图但颜色不对、想自己动手调AWB的朋友参考。1. 开始调试AWB前先搞清楚ISP链路里谁管颜色、谁管亮度1.1 读懂ISP pipeline为什么AWB排在这个位置才算合理瑞芯微的ISP pipeline以rkisp/rkaiq这套体系为例在RAW域上大致是这么一条链sensor把RAW数据送进来先做黑电平校正BLC把感光底噪和不均匀的暗电流拉掉再做镜头阴影校正LSC把四角亮度差异和偏色拉平下一步就是AWB在原始Bayer数据上把R、G、B三个通道的响应差拉回中性。再往后才是去马赛克demosaic、色彩校正矩阵CCM、gamma、降噪、锐化这些模块。关键点在于AWB必须放在demosaic之前处理。因为Bayer数据里每个像素只有一种滤色片R、G、B三个通道在空间上是错开的。白平衡本质上是在RAW域给R通道和B通道乘一个系数让灰卡上R/G、B/G的比例落到参考值附近。如果在demosaic和CCM之后再做这件事那就不叫白平衡增益了得在RGB空间里对每个像素做矩阵运算效果差还容易把CCM调出来的饱和度和色调一起带偏。我一开始调AWB时踩过最典型的观念坑就是总觉得“反正显示端也可以拉颜色图像后端调也行”。实际上瑞芯微这套ISP架构里sensor标定的wbgain、IQ文件里的r_gain/b_gain、g_gain这些配置都会直接影响后端CCM和gamma的输入顺序一旦错位后面怎么调都别扭。1.2 画面偏色问题不一定在AWB先做模块隔离很多人拿到偏色图就直接开调AWB结果调了半天发现边缘又偏了、暗部又紫了。我的习惯是先拍一张固定光源下的灰卡照片根据偏色的空间分布和亮度特性把所有嫌疑模块排一遍。现象嫌疑模块验证动作整个画面均匀偏红/蓝中心和四角一致AWB增益/CCM抓RAW后算R/G、B/G对比r_aiq参考点四角明显偏暗且偏色中心正常LSC换一套LSC标定数据或临时关闭LSC再抓同一场景暗部发绿或发紫高光偏品BLC或CCM/gamma盖住镜头看黑电平是否接近0用灰卡全灰阶扫一遍只有某个光源下偏色换光源就正常AWB参考点覆盖不足单独切换光源类型验证这个排查表看着简单但非常管用。比如前面我说那个“画面偏品红”的例子它其实有个隐藏特征灰卡在画面中央时颜色接近正常但把灰卡移到边缘立刻品红。这种空间分布特征直接指向LSC而不是AWB。如果你不先做模块隔离单纯在AWB里加增益哪怕把r_gain推到顶边缘还是品的而且中央也可能会被推绿。1.3 调试AWB的正确心态先恢复中性再谈偏好关于AWB我有一个很明确的经验AWB的职责是“物理还原中性灰”不是“表达风格”。很多项目喜欢在AWB里强行把画面调得偏暖或者偏冷比如为了“氛围感”把r_gain故意调高。这种做法在当时的光源下看着很舒服换个光源就全乱因为算法会基于错误的参考点去猜色温结果就是反复横跳。风格的表达应该交给CCM和gamma去处理。CCM矩阵里包含饱和度、色调偏移这些东西它可以让红色更红、绿色更绿并且在不同光源下保持一致性。AWB先把灰还原成灰CCM再给画面“上色”两个模块各干各的才不容易互相牵制。记住这个原则后面调参的时候你会少走很多弯路。2. 环境准备让RK3568的sensor和ISP先稳定出图2.1 设备树与驱动确认串口进板子后先查这几样AWB调试准备工作的第一步不是去调IQ文件而是先确认sensor和ISP这条链路已经稳定。我一般通过串口终端登录开发板先做几个基础确认。首先是设备树。RK3568设备树里要正确配置sensor节点、CSI D-PHY节点和ISP节点。以OV5695这颗5MP sensor为例设备树节点大致长这样i2c2 { status okay; ov5695: ov569536 { compatible ovti,ov5695; reg 0x36; pinctrl-names default; pinctrl-0 ov5695_rst_gpio ov5695_mclk; reset-gpios gpio1 RK_PB2 GPIO_ACTIVE_LOW; rockchip,camera-module-index 0; rockchip,camera-module-facing back; rockchip,camera-module-name default; rockchip,camera-module-lens-name default; port { ov5695_out: endpoint { remote-endpoint mipi_in_ucam0; ># 查看所有video节点名字确认sensor和isp节点存在 for v in /sys/class/video4linux/video*; do echo $v: $(cat $v/name); done # 查看media拓扑 media-ctl -d /dev/media0 -p # 确认sensor驱动加载 dmesg | grep ov5695如果这些都正常再用v4l2-ctl直接抓一帧看看有没有图像。很多偏色问题其实是sensor出图就不完整比如MIPI lane数配少了、时钟频率不对导致花屏那些问题在AWB之前就必须解决。2.2 用v4l2和rkisp抓帧不同场景下的抓图姿势sensor和ISP链路稳定之后接下来就是抓帧。瑞芯微平台上有两种抓帧方式一种是通过media-ctl把sensor到ISP的链路建立好然后从ISP的输出节点直接抓另一种是使用SDK里自带的rkisp_demo这类工具抓帧并保存RAW。用v4l2的方式大致是# 配置media链路把sensor数据路由到rkisp mainpath media-ctl -d /dev/media0 -r media-ctl -d /dev/media0 -l ov5695 2-0036:0 - rkisp-mipi-is0:0 [1] # 从mainpath抓一帧RAW v4l2-ctl -d /dev/video0 --set-fmt-videowidth2560,height1920,pixelformatRGGB --stream-mmap --stream-count1 --stream-toframe_raw.raw抓帧时有两点特别重要第一AWB调试需要的是RAW图或者至少是ISP统计前的结果不能直接拿预览图因为预览图已经过CCM、gamma这些模块没法反推原始增益。第二尽量连metadata一起保存里面带有3A统计信息和当前AWB增益值调试时可以直接对数据。如果是在Linux主机上用vscode远程连到开发板做调试也可以配合gdb直接跟用户态的rk_aiq服务比如在参数加载阶段抓一下调用栈看它到底加载的是不是自己预期的那份IQ文件。这个技巧在排查“改了配置但画面没变化”的问题时特别好用。2.3 上电、光源、图卡调试AWB的目标环境布置调试环境这一步外行人往往不重视但恰恰是决定调参质量的关键。AWB是和色温强相关的模块你要让它有据可依就必须在明确的光源条件下调试。有条件的建议用标准光源箱至少包含D656500K日光、TL844000K商场冷白、A光源2856K白炽灯这几种。没有标准灯箱也可以拿晴天窗边光、白炽灯、荧光灯凑合但一定要提前记录光源类型并保证测试期间光源不变化、不闪烁。图卡方面一张18%中性灰卡必不可少。用灰卡而不是彩色色卡去调AWB是因为灰卡在所有色温下都应该是中性的你只需要对比它在中性灰坐标上的数值就行。调AWB时让灰卡占画面50%以上确保统计区域里大部分像素都落在灰卡上。同时最好把sensor固定在手动曝光、手动增益模式避免AE因为场景亮度变化而自动调节曝光导致画面统计噪声和亮度权重来回变化让AWB结果不稳定。3. IQ配置文件里的AWB字段逐个说清它是干嘛的3.1 rkaiq的结构为什么每个sensor都要配一个IQ文件瑞芯微的rk_aiq跑在用户空间每个sensor对应一套IQ配置文件常见路径在开发板固件的/etc/iqfiles或者/oem/etc/iqfiles下面。文件名一般包含sensor型号和lens信息。这套文件不只是AWB参数BLC、LSC、CCM、gamma、降噪、锐化全都写在里面所以你别指望只改一个文件就能解决所有颜色问题。每个sensor要单独配一套IQ文件根本原因在于不同sensor的CFA滤色片光谱透过率不一样同一盏灯照在灰卡上A相机读出的R/G值是0.50B相机可能是0.43。这些差异只能靠每个sensor自己的标定数据去补偿。换镜头也一样LSC和AWB参考点都可能要重新过一遍。如果你在板子上看到多个IQ文件比如ov5695_default.xml和ov5695_night.xml注意看应用启动时到底加载了哪一个。我看过太多人改了白天用的配置结果应用加载的是夜间配置画面纹丝不动就以为调的参数没用。3.2 AWB的核心字段拆解与调参误区不同SDK版本里AWB配置字段名会略有差异我这里用一套通用的结构说明实际以你板子IQ文件为准awb statistic window enable1 x0 y0 w1 h1/ /statistic algorithm modeauto/mode refPoint ct2800 rg0.52 bg0.86/ refPoint ct4000 rg0.47 bg0.80/ refPoint ct6500 rg0.42 bg0.71/ /algorithm gainLimit rMin0.5/rMin rMax3.0/rMax bMin0.5/bMin bMax3.0/bMax /gainLimit /awb这里从实用角度拆解一下每个字段的作用字段作用调错之后的典型后果statistic/window决定AWB统计哪些区域像素计入高光溢出或天空反光色温估计被干扰refPoint定义灰卡在某个色温下RAW域的R/G、B/G响应和sensor实际响应不一致时AWB系统性偏色gainLimit/rMin等限制增益输出范围防止极端光源下算法失控上限太小白炽灯下依然偏黄下限太大日光下偏品mode选择自动、锁定、手动等AWB模式切换错误后增益不更新画面颜色固定在错误色温AWB算法的内部逻辑本质上是把画面切成很多小块统计每个小块的R/G、B/G找出那些接近灰点分布的块再根据不同色温参考点的位置做加权估算出当前光源色温。所以refPoint准不准直接决定算法猜色温猜得准不准。这里最容易犯的错是从网上抄一份参考值就用不针对自己的sensor重新标定。即便同一颗sensor型号不同批次的滤色片透过率也可能有微小差异照抄的后果就是微偏色怎么调都摸不着头脑。3.3 关于增益范围和统计窗口容易搞混的两处细节增益范围这玩意看起来很简单就是上下限嘛其实里面藏着AWB收敛速度和稳定性的平衡。上限调太大低照度下算法可能输出一个很高的增益把本来微弱的色噪声放大成色斑上限调太小在2700K的白炽灯下B通道需要的增益往往接近2.5甚至更高限制死了偏黄就永远压不回来。我的建议是先依sensor数据手册的响应估算一个粗范围再通过实测不同光源下“固定增益”抓RAW的结果去修正不要凭感觉设一个数。统计窗口的坑则更隐蔽。默认情况下AWB统计会做整个画幅的像素但实际场景里往往会存在高光点、镜面反射、或者直射的太阳区域。这些区域在RAW域上的R/G、B/G值严重偏离灰线会把统计结果往错误方向拉。尤其是有LED屏幕或者金属反光的监控场景AWB疯狂漂移多半就是统计窗口里混入了不该参与统计的像素。处理方式就是把统计window裁剪到画面中央区域或者至少把已知的高光反射区域排除掉。4. 白平衡调试的实操流水线从原始RAW到不同色温全覆盖4.1 用灰卡做基准计算当前增益离目标差多少实操流程的第一步是把AWB增益固定为1:1:1也就是让R、G、B三个通道都不做增益补偿直接抓一张RAW。然后在D65光源下放灰卡让灰卡占满画面中央统计灰卡区域的Bayer均值。举个例子假设我抓回来RAW统计灰卡区域得到R92、G200、B1568bit数值。那么当前RAW域的响应比例是R/G 92 / 200 0.46B/G 156 / 200 0.78再看IQ文件里D65色温的refPoint。如果写的是rg0.46、bg0.78那就完美匹配AWB在D65下应该输出近似1:1的增益。如果测出来是R/G0.55、B/G0.65说明R通道响应高了B通道响应低了要让灰卡恢复中性就需要把R通道增益压低、B通道增益抬高。计算公式很简单以G为基准r_gain 1 / R_G如果用RAW响应比例的话b_gain 1 / B_G比如R/G0.55那需要的r_gain就是1/0.55≈1.82b_gain是1/0.65≈1.54。这个数值不是让你直接塞进去而是作为参考点修正的依据。这个计算逻辑在每一步调试里都会用到建议先彻底搞懂。4.2 推参考点还是推增益曲线同一颗sensor在不同色温下RAW域的R/G、B/G响应是连续变化的。所以正确做法是采集3-5个色温点把每一点的实测响应作为refPoint填进IQ文件算法在任意色温下都通过插值得到参考值。这比单独调某一条增益曲线更稳定、更合理。我遇到很多新手喜欢直接去改AWB输出端的“白平衡增益表”也就是让算法在某个色温下固定输出一个增益值。这种做法的坏处是你只修了这一个点的显示结果但相邻色温下算法插值时会把突变带进去导致光照稍微一变颜色就跳一下。更麻烦的是你很可能在掩盖这个色温下CCM或者LSC的真实问题。所以我的调试顺序是先固定增益抓RAW确定sensor真实响应用实测值更新refPoint如果refPoint已经和实测一致但AWB输出仍然偏色才考虑去检查下游CCM。记住refPoint描述的是“传感器的事实”增益表描述的是“算法的输出”事实不能去迁就算法输出。4.3 不同光源下的巡回验证与记录表单个色温调准不算完AWB必须到多光源下去回归验证。常规三光源是D656500K、TL844000K、A光源2856K。每换一个光源重复上一步操作固定增益抓RAW、测灰卡响应、比对refPoint、修改配置、重新运行确认。我自己的记录表大概是下面这样光源目标色温灰卡R/G实测灰卡B/G实测refPoint修正值AWB收敛时间备注D656500K0.460.780.46/0.781.2s正常TL844000K0.490.800.49/0.801.5s正常A光源2856K0.530.870.53/0.872.0s略慢待优化如果某个光源下AWB收敛时间明显偏长多半是相邻色温参考点的差值设置过大导致算法在判断光照到底落在哪个区间时犹豫不决。可以考虑在两个色温之间再插一个中间参考点让过渡更平滑。这里还要特别提醒一个场景混合光源。比如画面一半是从窗户进来的日光一半是室内白炽灯AWB永远无法同时满足两个光源下的中性。这时候你要根据项目实际需求做取舍是保画面主体入射光还是保全场平均不偏得离谱。瑞芯微的AIQ里一般也有混合光源处理策略但不管选哪个策略你都必须明确告诉客户“这种场景没有完美解”而不是反复去调参数期望魔法发生。5. 真实项目里踩过的AWB深坑附完整排查思路5.1 坑一边缘偏色AWB显示已收敛但画面仍难看现象是灰卡在画面中央时AWB统计显示已经收敛R/G、B/G都在参考点附近但肉眼看整个画面四角还是明显偏红偏紫。这个问题在产品整机测试时最容易暴露。我当时的排查链路是这样的先看AWB统计窗口默认是全画幅平均下来灰卡中央数值被边缘带偏导致算法以为已经中性了。但单看边缘色块它的Bayer响应统计和中央差别极大。这说明问题的根源不在AWB而在于LSC没有把镜头本身的色彩阴影打平。重新跑了LSC标定再用新参数去抓同一场景四角偏色基本消失AWB的统计也稳定了。这个案例再次验证了模块隔离的重要性。如果一上来就把AWB统计窗口缩到中间让中心参考点收敛得“更准”其实是把LSC的问题掩盖了恢复了LSC之后AWB参数反而不用大动。5.2 坑二冷暖光切换时AWB来回横跳、收敛慢现象是在D65光源下拍完切到白炽灯AWB用了四五秒才稳定期间画面在偏黄和偏蓝之间来回大幅度摆动监控视频录下来像抽风一样。排查时我先看了增益日志发现单帧增益步进特别大第一帧还是1.1第二帧直接跳到2.3第三帧又掉回1.4整个系统在震荡。这个问题的根子有两个一是帧间滤波没生效AWB对每一帧统计结果过于信任二是D65和2800K参考点之间隔着一段没有合适的中间值算法在“到底是哪种光”之间反复横跳。处理方案也很直接把帧间滤波系数调大让单帧统计结果对最终增益的影响降低再在4000K左右补一个参考点让色温估计曲线过渡平滑。修完之后收敛时间压到了1.5秒以内没有再出现抖动。这类振荡问题一定要看统计日志和增益日志只看预览画面很难分清到底是算法问题还是光源本身波动。5.3 坑三低照度高增益下AWB误判严重现象是晚上光线很暗环境大概几百勒克斯以下AWB把原本6500K的灯下场景误判成3000K画面被补偿得偏蓝人脸色发青。这个问题的本质在于低照度下sensor噪声变大尤其高增益做上去之后噪声在色度统计里被当成有效信号。灰点检测算法本来应该排除那些亮度太低的块但默认阈值往往按正常光照设计低亮度块的R/G、B/G分布发散得很厉害AWB就会在色温轴上乱猜。我的处理是在统计端增加亮度下限阈值把低信噪比的块从灰点候选中剔除同时把灰点检测的色度置信区间稍微放宽避免过度依赖噪声大的区域。还有一个联动点查看一下低照度时AE是不是把增益推到很高如果是建议限制sensor最大模拟增益把亮度不足的部分交给补光或者接受噪点而不是让AWB在这种条件下硬猜。低光AWB永远没有完美解关键在于设一个“算不准就保持上次值”的阻尼逻辑而不是频繁跳变。5.4 坑四预览和抓帧颜色不一致截图都查不出根源现象是在应用界面上看预览画面颜色正常但用抓帧工具存出来的图偏色把两张图放一起对比怎么也找不到规律。这个问题我排查了很久后来发现预览链路和抓帧链路走的不是同一套IQ配置。预览模式经过rk_aiq完整处理后输出到显示抓帧模式在某些SDK版本里直接走了bypass跳过了一部分3A统计或者用了不同的demosaic参数。还有个可能是抓帧时分辨率不同ISP对不同分辨率的处理路径有差异导致CCM和gamma的查找表也不一样。遇到这类问题别再对着图猜了。先确认你抓的帧是不是从同一个ISP输出节点出来的确认抓帧时有没有带metadata。把预览和抓帧的metadata放在一起对比看里面的wbgain、ccm矩阵、gamma表是否一致差异在哪里基本就一目了然。这个排查思路几乎可以复制到所有“显示和抓帧不一致”的场景。6. 把调试结果固化进产线AWB从开发板走向量产的注意事项6.1 IQ文件的管理与打包路径AWB参数在开发板上调好之后下一步是把它固化到固件里。瑞芯微平台通常的做法是把这套IQ文件放到系统镜像的固定目录下应用启动时去扫描加载。为了避免开发和生产脱节我强烈建议对IQ文件做版本管理文件名里带上映像传感器型号、镜头型号、日期和修改人。等到产线反馈颜色问题你能第一时间知道这批机器刷的是哪一版配置。启动加载IQ文件的逻辑也要确认清楚。有些应用通过命令行参数指定路径有些从环境变量读还有些写死在代码里。如果你改了文件但应用还是加载旧配置多半是加载路径写死到了另一个目录。调试阶段就在加载代码里加一行日志打印实际加载的文件路径能省掉后面无数排查时间。6.2 产线标定时如何设计光源工位产线标定AWB最怕的是光源不标准。普通日光灯管色温漂移很大显色指数也低拍出来的灰卡本身就不灰标出来的参数自然对不上。我见过比较靠谱的产线工位是这样设计的用一个封闭或半封闭的标定箱内部用高显色指数光源至少CRI 95以上D65和TL84各一组光源到标定板距离固定标定相机到标定板距离固定所有几何条件不随人员变动。标定工位最好和环境光隔离或者安排在暗室。标定顺序上我建议先做LSC标定再做AWB标定最后人工目视确认色彩表现。LSC标定没做AWB的统计会被边缘阴影干扰先做哪个都不如先做LSC。另一个经验是产线标定用的灰卡要和开发调试用的同一批次灰卡本身用旧了、脏了反光特性变了标出来的参数也会慢慢漂移。6.3 批次一致性与后续线上抽检不同批次的sensor和镜头光学特性会有细微差异。所以量产阶段别只标一台定版要在同一批次里抽5到10台机器做灰卡测试记录每台的R/G、B/G和wbgain数据看看离散度有多大。如果离散度明显超过预期优先查镜头批次因为镜头的光谱透过率差异通常比sensor批次更明显。线上抽检环节可以让产线工位拍一张灰卡脚本自动计算画面中央的R/G、B/G设置一个容忍范围超出范围的报警拦截。这个自动化脚本不复杂但对控制批次一致性非常有效。千万注意产线发现问题时不要图快直接调产线机器的AWB参数正确做法是把当批的RAW数据拿回实验室统一分析之后在IQ文件版本上修再重新下发。我在实际项目里体会到AWB调试的心态和流程比参数本身重要得多。只要你愿意先做模块隔离、固定光源、用灰卡做基准、按不同色温巡回验证哪怕你的板子不是瑞芯微这套方法论也能直接用。最忌讳的就是拿到偏色图就凭感觉甩增益那样大概率会把AWB、CCM、LSC的问题搅成一团后面改到崩溃。最后再分享一个小技巧每次修改完AWB配置把抓的RAW图、对应IQ文件版本、光源条件放在同一个目录存好同一光照条件测三次确认结果一致再收口。之后无论客户反馈问题还是产线要排查你都能在十分钟内找到对应的测试基线少走很多弯路。