AWB调试中(Tuning)的几个问题

第一,颜色的准确不仅取决于AWB模块,这是系统性的工程

比如,一个车载项目,囿于其使用环境,日夜切换不能满足,只得用双通滤光片,但是该滤光片红色波段截止不彻底,导致在650-700波段仍有透过,
结果就是在低色温下黑色物体偏蓝,其他颜色(除了蓝色)均出现不同程度的偏色,整个色卡看起来发“蒙”。
这个问题其实包含三个问题,其一,为何黑色偏蓝;其二,为何只有黑色偏;其三,为何是F光源偏。
经过分析,得出以下初步结论:其一,黑色偏蓝是因为RAW上R偏多,导致偏青,表现出来就是蓝;其二,黑色是因为吸收能力强,所以,偏色状况最右下角黑最严中,左边灰块次之。
也不仅仅是黑色偏,整体RAW都会偏红(少量绿),因为感红sensor在长波段很多,所以像在长波段分布比较多的红色块,黄色块,绿色快等等都偏的很厉害。
其三,F光源出现问题是因为低色温光源在长波段能量占比更多所以受到的影响最大,如图1所示:
AWB调试中(Tuning)的几个问题_第1张图片
以上只是一个例子。

另外,我原来以为亮度对颜色(色度)是没有影响的,在理论上来说,很多算法都是二维色度的估计,这是可行的(当然,也有一些理论表明亮度对最后的光源估计有影响,比如[1]把二维贝叶斯拓展到了三维,提高了一点估计准确度)。
但是在实际当中并非如此,代码中,亮度和曝光增益是联动的,而增益值又和黑电平有关,所以,亮度对最后估计得到的gain值是有影响的,虽说影响不大,但是也不容忽视。
像海思平台,根据曝光增益来估计室内室外从而选择AWB模式,这间接上影响了最后的颜色值。除了曝光,引起颜色问题的还有sensor,滤光片,镜头,甚至是罩子…系统参数配置等等。

结论:

想把颜色做准,需要了解整个系统。

第二,CCM的调试问题。

之前的AWB理论学习让我根本没有意识到颜色还原还有这个步骤,
因为理论假设认为,只要场景中的白(灰)作准,那么其他颜色就会作准,
但这个假设的前提是人眼的sensor,所以CCM的出现,本质是颜色空间的转换。
由机器的sensor转为人眼的sensor
实现手段是sensor RGB转为XYZ再转为sRGB空间和标准比对拟合得到。
使用的工具,步骤是,直接导入RAW,先进行AWB,再导入gamma,再比较,通过其内部算法得到最后的一个3*3全矩阵。
这里面隐含了很多信息,软件首先自动帮你做了CFA
(我不明白有些平台把AWB放在RAW域而不是RGB域做的目的,去马赛克可以去掉一些高光点,可以做一些去噪……没有害处只有好处),
自动把RGB转为XYZ,之后转到sRGB,之后再gamma,这时就可以和“标准图片”进行对比,得出一个3*3的校正CCM全矩阵。
这里有个点让我困扰——根本没有所谓“标准光源”,我们理论假设D65,但实际的sensor在该光源下成像依旧偏的厉害,所以此处对比的“标准图片”,也是D65AWB过后的图片。具体步骤大致如下:
在这里插入图片描述
所谓“图像风格”调试,除了饱和度调整,就是对CCM中参数增(减)达到控制特定颜色的目的,但是scale要把控好,不然很容易在另外一些场景下偏色。
结论:

CCM的操作本质是颜色空间转换

第三,伴随着CCM校正出现的一个问题是Gamma校正问题。

GammaISP中的作用,传统说法是:内存紧张。
因为动态范围有限,而人眼又对暗部细节比较敏感,在动态范围有限的情况下,牺牲一些高亮信息也是可以的。
出于此策略,在ISPgamma encoding,在displaygamma decoding,逻辑上好像没有错误。
但是display一般解释是CRT显示器,如下:
AWB调试中(Tuning)的几个问题_第2张图片
因果关系不可错乱。
但是这种显示器很少见了。又有人说,即使是LCD,也是在生产时特意的人为加上一个decoding(恳请做显示器的专家出来证实一下),这样好像可以比较恰当的解释,目前我给自己的解释也是这样的。
与此对应的是我在调WDR下的CCM时导入的Gamma变成了线性,也就是说,不需要进行Gamma校正。这也算是间接佐证了上述Gamma内存紧张的说法。

需要注意的是,以上提到的Gamma校正是指的sRGB中的全局性的Gamma,在一些所谓tone curve中使用局部Gamma只是为了提升局部的亮度(甚至它也会使用全局Gamma),目的是为了使图像“更好看”而不是弥补显示器的Gamma。两者不可混淆。

结论:

基本上可以把Gamma校正认为是人眼对暗部更加敏感而硬件内存又不足下的妥协。
但是还有几处Gamma值,详细起来非常复杂。没见过有 说的很清楚的,可以参考下

第四,训练光源区域确定问题。

海思,安霸,高通,Ti,这些平台,使用的算法基本一致,都是找白块。比如,海思算法,是三个色温确定普朗克轨迹,再加两个平行曲线确定相关色温范围,最后,再添加一些特殊区域(极端色温)或者抠出一些区域(室外绿区);又比如,在安霸平台,就是把海思的曲线换成了框。诡异的在于,这些“相关色温”的范围确定问题,根本没有科学依据,全凭个人经验,很“邪乎”。理论上来说,为了找到尽量多的色温,光源需要足够多,拿到一款sensor后要录视频好几天,再截取不同时间的RAW数据从而获取该时刻的光源……理论上来说,这是最保险的做法。但是一般调试人员为了简便,只是抓取几个场景,便根据“经验”画出训练域,这些经验里,通常是倾向于将框做大,殊不知大了也有误差。

画框时,一般是找在白块为中心,左右两边扩展0.2,为了更好的确立落入其中的点,使用了一个六边形框,这样便于求距离,确定点位置。如图2所示:
AWB调试中(Tuning)的几个问题_第3张图片
鉴于调试人员总是认为包含越多比不包含要好,所以倾向于把框画的尽可能大一些,这里会出现问题,因为框画的偏大,导致更有可能出现估计值A_esti点,实际上是A_real点,显然,都在框内,但是还是有误差。所以有时候会有些问题排查不出来,灰点都在,但是依旧偏色。此时往往被认为是“固有问题”而搁置。但是好在这种问题并不多见,本质原因还是安防场景的AWB要求比较低而场景又大部分比较理想(灰点多),所以没出现大问题,不被重视。为了打破这种不精确的画框经验,我使用理论研究中经常使用的光源,真实的sensor曲线拟合出光源点,这样可以看出一款senor的大致走向,而不至于乱抓乱画,如下所示(横坐标为G/R.纵坐标为G/B):
AWB调试中(Tuning)的几个问题_第4张图片
AWB调试中(Tuning)的几个问题_第5张图片
AWB调试中(Tuning)的几个问题_第6张图片
从以上可以看出,这个范围是低色温框“宽”些,高色温“窄”,不是安霸的中筒形,对应的,也不是海思的间隔一致的平行曲线。或许是为了程序实现的方便,训练光源范围都成了规范图形,这点或许不太好改,但是可以参考我第三篇文章中提到的算法,对这种平台算法找灰点得到的值进行约束,也一定可以得到更好的效果。

结论:

所以,以后不管是什么平台,画训练光源域时,都可以用厂家提供的sensor,使用网站上提供的光源,先拟合一下,做到心中大致有数,不至于偏大或者偏小。
上述拟合只能让你稍微画精确一点,不至于走向不可控。但是曲线形状为了便于硬件实现基本固定了,可以调的空间不大,这时可以想到拟合的方法,第三篇文章中所述,它不能让算法有质的改变,但是可以让算法更精准。厂商在PK的时候,如果是使用第三方平台算法,谁也不能领先友商一大截,或许在这种地方的改进能够有所帮助。

第五,混合光源问题。理论研究中我学习的不多,大部分算法都集中在单光源。但实际中这个问题很突出,比我预想的还突出。对着室内场景,室内室外光源不一致,可以明显的看到窗口处偏色,很严重。目前并没有很好的解决方案,很大一个原因是硬件的掣肘,每次只是输出一个全局的R_gainB_gain,这样的结果是,室外的白多室外就作准,室内偏色,相反,室外偏色。
那么,我们能不能采取一种迭代的算法,第一次,至少做准了一边,此时对校正过后的图像再一次处理,将R_gainB_gain相差不大的点(使用一个经验阈值Tmask掉(已经校正过了),再做处理,此时会估计到室外白点从而继续作准室外,如此,只需要循环不超过n次,就差不多能提高一些效果。
为了进一步简化,这是在我们默认已知为混合光源场景下的策略,具体在产品中,就是在web上加一个“混合光源”的选项。这只是一个非常简单的想法,里面存在的问题,比如,在做完一次校正之后如何保证剩余的白点和其他彩色点的相对数量,mask时阈值选取的问题,但是这种思路,我认为可行,下一步在公司的自研算法中我会稍稍尝试下。

结论:

在已知为混合色温的场景下,可以尝试使用一种简单的迭代策略对偏色进行校正。阈值的选取,需要一些数据训练得到。

第六,大面积单色问题。我必须承认这和理论研究有大的差异。实践中所谓大面积单色,其实也就是超过1/3的某种颜色,
但实际上灰仍然很多,而我先前认为的大面积单色,真的是几乎没有灰点,理论中的很多寻找true gray point的算法在这里都显得很苍白,这也是我真正体会到理论和实际差距所在的地方。

究其原因,还是硬件问题,做不到像素级处理,只得分块,使用每个块的平均通道值当做一个像素点的通道值。
这就使得在求全局gain时成了一个统计,那么,占据点数较多,和日光轨迹又比较一致的单色(一般是绿色),就很容易做上去,导致偏色。而我们理论上都是进行的像素级处理,有些算法精准到甚至只有0.1%的灰,依旧能够找出来……然并卵。
这就是安防里面的AWB算法脆弱的地方,稍微一点大面积,立马偏色。
即使你分为了室外模式将绿色区暴力抠出,在遇到其他场景色时依旧失效。
理论中对大面积单色效果比较好的算法是基于梯度的,虽然存在硬件困扰(比如紫边光晕等),但是预处理做的好的话可以试着做一下。gamut mapping除了计算量稍大,也算是一类比较好的解决方案。
我下一篇文章会重点梳理基于gamut mapping的庞大的一类算法的发展脉络。

结论:

平台算法太脆弱。基于edge的改进算法,基于gamut mapping的简单算法或许能够用上。

你可能感兴趣的:(isp)