前言

色带（Banding）其实是8bitYUV格式视频不可避免的一个问题。常见的色带包括明度（Y）色带和色度（UV）色带。

色带是什么？

色带就是由于在平滑的渐变区域，由于颜色变化小，导致用于量化这段颜色的编码值数量不够，从而在显示器上把渐变反映成了色阶的样子。下图展示了一个典型的例子。

这张图的左上角到右下角是一个从浅绿到深绿的渐变，可以比较明显的看到颜色之间的分界线（右上到左下）

量化是什么？

前面我们提到一个词，渐变的颜色量化（quantize）到编码值（code）的时候，编码值数量不够导致色带出现。量化就是把一个高精度的东西（比如亮度的实际值，常用尼特nits衡量）对应到数字化的编码上的过程。常用的8bit编码值是0~(2^8-1)的整数，非常有限，对于从纯黑到纯白的大范围过渡来说是远远不够用的。特别是在后期制作的时候，随手一拉就是明显的色带。

顺带一提，现在大部分的显示器都是8bit面板，但是你却比较少能在上面发现色带，第一个原因是大部分显示器的亮度并不会很高，从而让你聪明的眼睛也很难发现亮度相差很小的两个颜色；第二个原因则是我们下面要说到的，显示器上大部分内容都有天然的抖动（dither），比如你所拍摄的照片中，噪点就是一种抖动，很好的掩盖了色带。

明度色带常出现在一些动画制作时，在低色深下拉伸亮度对比度（比如白色相簿1的BD）；色度色带常出现在实际录像的大片纯白区域，比较明显的表现是出现UV的象限色。（见下图右侧）

为什么色带是这样（鬼畜）的颜色？

想要回答这个问题，就必须了解色度（UV）平面到底是怎么表现颜色的。这两个平面单独拿出来看都是灰度。从深到浅，U分量是青到红，V分量是黄到紫。这两者正交，所以可以表示一个完整的色彩平面。并定义两个平面均为50%灰时为白色。（见下图3，UV分量在模拟领域又叫CbCr分量，注意两个对角线上的颜色，橙-蓝和绿-洋红，这两者也是正交的，是不是想起了CameraRaw里面的某个面板？）

我们常见到的这种色带一般都呈现为四个象限色和四个轴向色。我们知道，图中墙体接近白色但仍不完全是白色，由于8bit精度不够，(0,0)到附近八个点的色彩差异虽然微小，对于表现墙体上细微的环境光变化是不够的，这就导致了色带。H264的压缩更加加重了色带（为什么？还记得我们前面说噪点可以掩盖色带吗，H264压缩会比较主动的干掉UV平面上的噪点（或者说，色度平面的量化(qp)更高），从而呈现出上面这个一团乱麻的结果）。

去色带（Deband）的基本思路

基础知识准备完了，现在我们要真正开始去色带了。我们已经知道，色带就是由于色彩精度不够导致的，所以我们在AVS里面的处理应该全程在16bits下进行，使用ConvertBits(16)转化到16bits色深。上面已经说过，噪点会掩盖色带，这不仅表现在会掩盖人眼的认知，也会干扰程序判断色带。所以第二步就是降噪。在本例中，我直接套了个DFTTest，色度平面降噪略微给大一点。降噪完结果如下图（U平面，20x对比度）

降噪完毕之后就应该开始去色带了。目前常用的去色带滤镜主要有两个，GradFun3和F3kdb。F3kdb的去色带范围相对较小，不适合这种面积比较大的色带。本例中我把radius设到了64。Deband后结果如下图。（U平面，20x对比度）

是不是很震惊！整个色带被完全平滑了。但是你还记得，我们的Deband是在16bits下进行的吗？16bits没有实际的封装意义。真正要用的时候还是10bits为主。所以我们需要ConvertBits(10)，然后我们可以得到下图。（U平面，20x对比度）

这这这……这是什么东西，色带不又回来了吗。这时候你切换到YUV模式：

好吧，这个去色带还是有用的，但是恼人的边缘还是有，虽然比之前好多了，但是强迫症不能忍啊！

怎么办？这时候你取U平面上的颜色，发现：左边最深的阶梯颜色是512，往下一个阶梯，颜色变为513……也就是说，10bits的潜力已经被你挖完了，这个阶梯在10bits下不可避……

聪明的你一定想到，上面你不是说加入噪点可以掩盖色带问题吗？说的不错，但是这个位置无脑加噪会导致后续H264压制的时候，码率无法控制。这里我们有一个更巧妙的“加噪”方法——抖动（Dither）。

抖动是什么？

刚刚我们说到了，我们已经把10bits的色阶潜力挖掘完了，512、513、514……每一个编码值都有一个颜色，但是色阶仍然存在。这个时候，抖动出现了。它说，我可以只用这几个编码值，做出比这平滑得多的效果。

废话不多说，让我们看看抖动是怎么实现这样效果的。让我们放大我那张令人震惊的Deband效果图：

看到这张图，相信我也不用多说了。原理很简单，就是一个式子：(512+513)/2=512.5。在远处看的时候，这种做法可以有效地欺骗你的眼睛，让你看到更多的颜色。

图示的是有序抖动（Ordered Dither），当然在算法上还有很多种比如：Floyd-Steinbery误差扩散（error diffusion）、Stucki 误差扩散……不同算法的区别只是在加噪方式的不同，但是本质都是一样的：牺牲空间分辨率换取位深。在本例中选择有序抖动，是因为其抖动模式图案更加容易在H264的压缩中被离散余弦变换（DCT）算法保留下来。从而在有损压缩中保留更好的效果。

ConvertBits已经自带了有序抖动算法，只需要加上参数：dither=0即可。

这样我们就完成了整个去色带，最终结果见下图。（YUV，Y以330为中心，10x对比度；UV20x对比度）

副作用

Deband有没有副作用呢？有的，本质这是一种平滑模糊算法。虽然在处理的过程中Deband滤镜会使用一个蒙版（mask）来防止抹掉细节，但是问题就出在这个mask不一定准确，所以使用的时候还是需要精心调节mask的阈值。

下面给出此例用的参数（比较重口味，但是本来也没啥细节）

DFTTest(y=false, sigma=4, tbsize=3, sbsize=8, sosize=3)

DFTTest(u=false, v=false, sstring="0.0:0.0 0.4:0.0 1.0:1.0", tbsize=1)

注解：①本来是只想让y降一点高频噪的，但是后来（开始写文章了）才发现这个y降噪参数没调好，没起到啥效果，还好没怎么影响deband。

②uv平面的空域开窗开小一点（默认12改到了8），主要是因为：uv本身噪“点”都成块了，如果开窗太大，这种块会平滑得过了头，不利于后续GradFun3识别色带。

③y平面没有开时域降噪（tbsize=1），主要是出于保留细节的考虑。

GradFun3(thr=0.5,thrc=0.7,elastc=5,radius=48,radiusc=64,thr_det=4,lsb=true, lsb_in=true)

注解：①色度的deband力度比较大，体现在threshold和radius上。

②GradFun3还是个老滤镜，需要用Stacked的高位深表示方法。用AVS+的ConvertToStacked()和ConvertFromStacked()两个方法即可。

③蒙版的阈值（thr_det）需要根据源来定。使用debug=1参数可以让GradFun3输出生成的mask。

原始数据送给x264进行有损压缩

虽然说有序抖动比较容易被保留下来，但是还是比较消耗码率的。经过我（反复调参（笑）），发现：crf=16、psy-trellis=0.5、aq-strength=0.9体积很小（12Mbps@1080p10）抖动的pattern没了但是，它的block比较碎（见下图）也能起到类似的dither效果，虽然整体看起来还是有点惨不忍睹。

当crf降到8的时候（Y的qp=18，UV的qp=-8（对这个参数就是很变态但是实际上加不了多少体积）40Mbps@1080p10），抖动pattern就能保留的比较好了。见下图。

本例用的压制参数

--crf 8 --preset slower --output-depth 10 --psy-rd 0.95:0.5 --aq-mode 2 --aq-strength 0.9 --ipratio 1.2 --qcomp 0.7 --qpstep 6 --chroma-qp-offset -8 --cplxblur 5 --merange 28 --ref 5 --no-dct-decimate --input-range pc --ssim --deblock 1:-1

注解：x264很奇怪，在qp很高的时候毫无疑问，画面会全是block，随着qp的下降，block开始变碎，直到达到我上图crf16的效果。再继续下降，block重新变得整齐，但是没有保留dither，也就是还原了文中不加dither 的台阶状，反而更加难看。再继续下降到上文crf8的情况，就好得多了。

增加trellis的目的主要还是为了增加总体能量，在qp高的情况下比较有用（可以一定程度上保留比较碎的block）

全文注解：

①所有的色度拉伸都是Nearest Neighbor.

②全文用到的图基本都有统一的对比度拉伸，注意这个10x、20x是非常极端了，如果我不做这个拉伸，全是8bits的图片啥都看不出来。这也告诉我们所以其实（除了强迫症和重度调色，谁用得上这个啊）后面的dither部分做不做都还好，10bits已经很够用了，dither之后基本上能等效到12bits。

本文测试中生成的原始图片下载：度：s/1oIphHP【】SrEKVwp【】FV0Xn【】Sd6g   码: 27dq

（全文完）