top of page
搜尋

从拜耳阵列到HDR

  • 作家相片: 坂本ユウスケ
    坂本ユウスケ
  • 2022年8月12日
  • 讀畢需時 6 分鐘

已更新:2022年8月20日

从拜耳阵列到图像显示


图像捕捉原理


Step1. 光照在物体反射

Step2. 镜头汇聚

Step3. 【添加色彩滤波阵列】Sensor光电转换(光信号to模拟信号)

Step4. ADC数模转换(模拟信号to数字信号)

Step5. ISP芯片对色彩滤波阵列进行计算转换为RGB信息

Step6. 将RGB信息编码封装为JPEG/PNG/HEIF等文件。

Step7. 将JPEG/PNG/HEIF文件解码为RGB信息并显示在屏幕上。


常见的色彩滤波阵列


RGGB阵列

RGGB阵列是指,以一个红色像素,两个绿色像素和一个蓝色像素,作为一个集合,每个像素仅过滤一种颜色的色彩滤波阵列,也是目前相机最普遍的色彩滤波阵列。


从Bayer转换为RGB需要ISP进行计算,计算差值有很多算法,这里举例的是最容易理解的,最简单的,OpenCV的算法。




RYYB阵列

RYYB阵列是指,以一个红色像素,两个黄色像素和一个蓝色像素,作为一个集合,每个像素仅过滤一种颜色的色彩滤波阵列,相比于RGGB提升了夜光下的表现,但是ISP计算还原时,有偏色风险,目前部分华为手机和其他影像设备搭载。


RGBW阵列

RGBW阵列是指,以一个红色像素,一个绿色像素,一个蓝色像素和一个白色像素,作为一个集合,每个像素仅过滤一种颜色的色彩滤波阵列,相比于RGGB提升了进光量,降低了噪点。属于用彩度换亮度的一个方案。


图像显示


目前我们接触到的主流屏幕大致可以分为LCD和OLED屏幕。LCD是背光+滤光片的解决方案,OLED是主动发光像素的解决方案。





大部分LCD都是采用标准的RGB排列,但是OLED由于主动发光的特性,蓝色衰减较快,就迅速步入了八仙过海各显神通的局面。


除了LG的W-OLED是以RGBW的经典亮度换彩度的情况外,目前大部分的OLED屏幕(天马、BOE、友达、三星)都是通过拆分绿色像素,做大红蓝像素,来维持屏幕寿命。


但这里的RGGB并不是拍摄中的四个像素,而是这RGGB的四个子像素构成了一个像素。因而也只有一个RGB值。



颜色通道与堆栈原理


像素颜色通道的引入





若涉及到多张照片堆栈的话,要确定一个照片上的像素应该是由(Num,X,Y,R,G,B)六个数据构成的。第一个确定是第几张照片,前两个数据确定了二位画面上像素的位置;后三个数据确定了像素的色彩。



最大值堆栈

最大值一般用于拍摄星空,光轨等等


则最大值的堆栈实现方式就是,针对(Num)值1~n,单个(X,Y)的R,G,B最大值。即可获取整组照片中,该像素点的最高值。


整组照片使用最大值堆栈,使得在整组照片中,明暗变化不大的区域有较为恒定的像素,而明暗反差大的区域,可以保留最亮的像素,因而可以把黑夜中的光点记录下来,多张叠放,便形成了光轨。


平均值堆栈


平均值一般用于模拟拖影长曝光中的拖影,减少杂色;


平均值的堆栈实现方式就是,针对(Num)值1~n,单个(X,Y)的R,G,B平均值。即可获取整组照片中,该像素点的平均值。




整组照片使用平均值堆栈,使得在整组照片中,所有图片的像素都参与了运算。在物体非运动时,像素的通道值较为恒定,取得通道平均数数值和平时拍照保持一致。而运动的物体,在运动掠过的像素每一次都参与了运算,因而会留下看起来透明的拖影。


中间值堆栈


中间值一般用于删除多余的物体,如移动的路人


平均值的堆栈实现方式就是,针对(Num)值1~n,单个(X,Y)的R,G,B平均值。即可获取整组照片中,该像素点的平均值。



整组照片使用中间值堆栈,使得在整组照片中,偶数数量的话,仅中间值相邻像素参与了运算;奇数数量的话甚至不涉及运算。在物体非运动时,像素的通道值较为恒定,取得通道中间值数值和平时拍照保持一致。而运动的物体,在运动掠过的像素不参与运算,因而无法保留。


视频抽帧堆栈


我们都知道,视频就是一连串照片的集合,以中间值堆栈去路人为例,若是以视频抽帧堆栈,岂不是会变得效率极高呢?


答案是看视频时长和抽帧的设定。在逐帧计算的时候,确实很容易去路人。我们所想到的是,若是在不运动的地方,1秒钟生成了60张照片,像素通道值都大致相等,很容易就可以算出中间值。



更棒的情况是,我们可以透过视频抽帧堆栈实时预览堆栈效果。


但是视频抽帧堆栈也有其局限


1秒钟抽帧60张照片,听起来就是一个很吃算力的活动。因而第一个局限就是,在进行抽帧和堆栈的时候非常吃性能。


另一方面,视频的清晰度和处理方式也与照片不同,使得大部分手机或者相机能够拍摄6K甚至1亿像素的照片,却只能录制4K30帧的视频,因而视频的画质不如连拍的单张。这里可能要提到OPPO的马里亚纳X的ISP芯片,其声称就是针对录制视频中的每一帧单独计算,从而使得每一帧的处理上可以比照或者追上单张照片,因而获得更好的视频录制效果。


中间值堆栈不仅仅是要考量保持静止的地方,还要考虑运动的地方,1秒钟生成60张照片,这60张照片里人若是运动的很快,当然也可以很轻易的透过中间值堆栈,将运动的人去掉。但是人运动得速度较慢的情况下,可能会使得好几十甚至上百个像素始终都是被人体占用,因而导致不理想的结果。


对颜色通道和堆栈原理的高级使用——HDR


AEB解决方案


AEB解决方案,又称自动包围曝光解决方案。有相当一部分的软硬件厂商都使用的包围曝光HDR的解决方案,包括Apple。这里的举例是insta360的HDR,这是公开的专利。


其原理是使用包围曝光,也就是连续拍摄三张照片,其中一张过曝(保留暗部细节);一张正常曝光(用于对齐和参考);一张欠曝(保留高光细节)。


在获取三张照片后,针对三张照片的曝光程度,生成权值图。


最后根据权值图,对每一个像素的通道值进行加权计算,将三张照片合成一张高动态范围的照片。


Google HDR+


Google HDR+为什么选择单曝光



  • 立即。即使相机没有连接(有线或无线),系统也必须在几秒钟内生成照片并将其显示在相机上。这意味着我们不能将处理推迟到桌面计算机或云。

  • 自动。该方法必须是无参数且完全自动的。摄影师应该在不知道用于拍摄或图像处理的策略的情况下拍摄更好的照片。

  • 自然。我们拍摄的照片必须忠实于场景的外观。在高动态范围的情况下,我们必须限制我们为避免卡通或超现实主义图像而做的局部色调映射量。在光线很暗的场景中,我们不能使图像变亮以至于它会改变明亮的照明或显示过度的噪音。

  • 保守。应该可以将此用作缺省拍照模式。这意味着所拍摄的照片不得包含伪影,并且必须始终至少与传统照片一样好。而且,在极端的情况下,它必须逐渐退化为传统的照片。 鉴于这种保守的限制,我们发现最可靠的连拍摄影方法是以相同的曝光时间捕捉连拍中的每个图像。


Google式环曝光


在原先的HDR+一直是单曝光HDR的佼佼者,但是由于一些局限,Google也采取了全新的环曝光HDR。


原本单曝光HDR+的拍摄策略是基于曝光不足,避免高光细节丢失。虽然这种策略是以阴影中的噪点为代价的,但 HDR+ 通过使用连拍摄影来抵消增加的噪点,但是单曝光的HDR有所局限。


每次捕获一帧时,传感器都会引入第二种类型的噪声,即读取噪声。读取噪声不取决于捕获的光量,而是取决于拍摄的帧数——也就是说,每拍摄一帧,都会添加额外的固定数量的读取噪声。


Google式的环曝光,并不是简单的拍摄欠曝光,正常曝光和过曝光的三张照片,而是遵循了Google原先的在用户点击拍摄之前进行多张短曝光,在用户点击拍摄之后生成一张长曝光的照片。



欠曝光合成的HDR


如果我们曝光不足太多,即使我们合并多个帧,照片也会很嘈杂。由于捕捉和合并需要时间和力量,我们无法捕捉到无限的数字。


Google创建了一个使用传统HDR包围拍摄的场景数据库,当使用我们的色调映射方法进行渲染时,Google已经手动调整以使其看起来尽可能自然。这种方法的成功取决于涵盖消费者可能遇到的各种场景。我们的数据库包含约5,000个场景,这些场景是在几年内收集的,手动标记了两个参数,对应于短时间和长时间曝光,产生最佳的最终再现。


一旦Google找到了一组候选匹配场景,我们计算出这些场景的手动调整自动曝光的加权混合。这种混合最终会产生两个参数:短暂的曝光时间以及在色调映射期间应用的长时间曝光。


从拜耳阵列到HDR


其实本来是作为标题的,结果没想到真的能写到这里。


Google HDR+利用Camera2 API,可以绕过ISP,访问拜耳原始图像。有以下几个优点:

  • 增加动态范围。原始图像中的像素通常为10位,而移动ISP产生的YUV(或RGB)像素通常为8位。实际优势小于2位,因为raw是线性的,而YUV已经有gamma曲线,但它不可忽略。

  • 线性。减去黑色电平偏移后,原始图像与场景亮度成正比,而ISP输出的图像包含非线性色调映射。线性使我们能够精确地模拟传感器噪声,这使得对齐和合并更加可靠,并且还使得自动曝光更容易。

  • 可移植性。合并由ISP生成的图像需要对其处理进行建模和逆向处理,这是专有和场景相关的。从原始图像开始,我们可以省略这些步骤,这使得将我们的系统移植到新相机更容易。


由于能力不足,对HDR的解读只能流于表面。而更深的信息,期待更多人的挖掘。


更多参考信息:

 
 
 

Comments


 © ACES 2018-2024 by Sakamoto Yuusuke. 

bottom of page