1. 从"颜色加深"这个叫法说起：它到底是不是你想的那个滤镜
今天这个打卡内容，其实是被产品经理逼出来的。用户一直在问：能不能把卧室背景一键换成马尔代夫？在美颜相机这类项目里，这就是典型的背景替换需求，底层靠的正是 GPUImageChromaKeyBlendFilter。我平时跟组里人聊的时候习惯叫它颜色加深混合滤镜，但严格来说，这个名字是有点误导的，它真正的身份是色度键混合滤镜。这两者差的可不是一星半点：Photoshop 里那种颜色加深（Color Burn）混合模式，是把底图颜色按照特定公式向暗部压深；而 ChromaKeyBlendFilter 是让画面中某个特定颜色区域"消失"，露出下面垫着的另一张图。一个是调色思路，一个是抠图思路。
1.1 为什么用户总想把背景换掉
在美颜相机里，换背景不是刚需，但一旦有人问，回应起来就特别麻烦。你可以给用户上百个滤镜，都抵不过"把我身后那堆快递箱抹掉"来得直接。我们调研过一小批活跃用户，其中将近四成的人拍摄环境是卧室和出租屋，背景里挂着衣架、排插、半开的衣柜门。这些画面在照片里还好，一到视频预览就很出戏。所以背景替换成了美颜之外最被念叨的功能，而实现它绕不开色度键处理。
所谓色度键，就是绿幕、蓝幕这类纯色背景被识别后，把纯色区域透明化，再把另一张背景图从底下"透"出来。这个过程在实时预览里必须用 GPU 做，CPU 抽帧抠图根本跑不动 30 帧。GPUImage 这个开源框架之所以适合我们，是因为它的滤镜链设计得很直白：输入纹理进链，每个滤镜处理完丢给下一个，中间不用反复回读像素。而 ChromaKeyBlendFilter 就是链上负责"抠"的那一环。
1.2 ChromaKeyBlendFilter 的真实身份
这个滤镜的全名拆开看就很清楚了：ChromaKey（色度键）+ Blend（混合）。网上很多教程只讲 ChromaKeyFilter，也就是输出透明通道的版本，但那个版本在 GPUImage 里输出的是带 alpha 的结果，后续还得再接 Blend 滤镜把透明区域和背景叠起来。ChromaKeyBlendFilter 把这两步合并了：它有两个输入纹理，一个是要被抠的前景，一个是垫底的背景，内部直接算出混合结果输出。这省掉一次纹理拷贝和一次绘制，在移动端是实打实的性能节省。
真正让我觉得它"值得单独写一篇"的，是它在颜色空间上的处理。它不是简单比 RGB 三个通道的差值，而是先把颜色转到类似 YCrCb 的亮度-色度表示，再去比较色度分量。这个细节直接决定了抠图对光照的容忍度，后面我会专门拆解。
2. 把着色器拆开看：色度键匹配的每一步
2.1 YCrCb 颜色空间，为什么不直接比较 RGB
如果你只是想把"绿色"去掉，第一反应肯定是判断像素 RGB 里 G 是否显著大于 R 和 B。这种做法在纯色背景、均匀光照、不追求边缘质感的时候勉强能跑，但一遇到反光、阴影、现场灯光偏绿偏黄，就会漏掉一大片或者把肤色给抠穿。原因是 RGB 三个通道相关性太高，人对"绿色"的感知也不是单看 G 通道。GPUImage 的做法是把颜色映射到 YCrCb 这类空间：Y 代表亮度，Cr 和 Cb 代表两个色度分量。这样亮度变化被单独隔离出去了，绿色阴影即使变暗了，它的 Cb、Cr 依然和标准绿幕很接近，不会因为亮度一降就被判定为"非绿色"。
不管是用自适应还是固定公式转换，核心都在于：抠像比较的是"颜色长相"，不是"颜色深浅"。这就好比你在人群里找一个穿绿衣服的人，判断依据是他衣服的色相，而不是衣服被灯光照得亮不亮。亮度变了你还认得出那件绿衣服，颜色空间转换就是为了让算法也这样"认人"。
2.2 smoothstep 与边缘过渡的计算逻辑
ChromaKeyBlendFilter 的着色器里，最关键的是这一段逻辑：把当前像素的 CbCr 和预设绿色幕布的 CbCr 算一个距离，再把这个距离扔进 smoothstep，得到 0 到 1 之间的混合权重。距离小说明它是绿色幕布，权重趋于 0；距离大说明它是要保留的前景内容，权重趋于 1。
smoothstep 有三个参数，实际用起来是阈值下限、阈值上限、距离值。低于下限直接返回 0，高于上限直接返回 1，中间则做平滑曲线过渡。这就是为什么边缘不会像硬切那样出现一条像素锯齿。我们调参时管这叫"羽化量"：smoothing 越大，边缘过渡越宽，但过渡太宽会把头发丝、衣服边缘的半透明感也一块儿吃掉；smoothing 越小，边缘越干净利落，但光照不均的绿幕上容易出现一块一块的残留。默认参数 0.4 的 thresholdSensitivity 和 0.1 的 smoothing 只适合理想环境，到了实际拍摄场景必须按光调。
2.3 混合公式的两种写法
很多人在网上搜这个滤镜的源码，会看到两种看起来不太一样的实现。一种是用 mix(textureColor, textureColor2, blendValue) 做最终混合，另一种是先算出 mask，再用 mask 乘前景、用 (1 - mask) 乘背景相加。这两种写法数学上等价，唯一的差别在于精度表现。GPUImage 里用 mix 多一些，因为它在底层会映射到硬件混合指令，执行更快。如果你自己写 GLSL，我建议也优先用 mix，别手动做乘法，不然在低端机上可能出现颜色偏移。
顺便提一个容易看错的地方：输入的 textureColor 是底图背景，textureColor2 才是有绿幕的前景。混合权重靠近 0 时输出背景，靠近 1 时输出前景。很多第一次读源码的人把这俩搞反了，结果抠出来的画面背景全变成前景图了。我第一天调试时就栽在这儿，画面怎么都不对，后来查纹理绑定顺序才发现。
3. Android 端的接入与管线下沉
3.1 依赖引入与滤镜链设计
Android 端接入 GPUImage 不算复杂，但项目里要有一个整体规划，不能直接 new 完就扔进预览链。我们的美颜管线大致是 Camera 纹理 → 原图缩放 → 磨皮美白 → 色度键混合 → 滤镜调色 → 输出。ChromaKeyBlendFilter 在这个链里属于"中间层"，它前面要有美颜处理，后面还要接调色，因为它输出的边缘质量会影响后续滤镜的颗粒感。
我在项目里把它单独抽成一个 BackgroundReplacementFilter 的封装类，内部持有 GPUImageChromaKeyBlendFilter 实例，对外只暴露两个方法：setBackgroundBitmap 和 setChromaKeyColor。这样做的好处是上层 UI 完全不用关心滤镜细节，产品换背景图只要传 Bitmap，换抠像色只要传色值。串到滤镜链里时也只暴露这一个封装对象，将来换成自定义着色器，影响面能控制在一个类里。
3.2 两路纹理输入的桥接细节
ChromaKeyBlendFilter 是典型的双输入滤镜，也就是说它除了主纹理，还需要第二个纹理输入源。GPUImage 框架里这类滤镜大多数叫 GPUImageTwoInputFilter 的派生类，使用时要把背景图转成 GPUImagePicture 再 addTarget 给混合滤镜。这个操作本身不复杂，但有个隐坑：背景图分辨率如果和相机预览分辨率不一致，滤镜不会帮你自动缩放对齐。所以传给它的背景图必须预先按预览分辨率裁好。
我实际用的缩放策略是"封面裁剪"，也就是背景图按预览宽高比居中裁剪后缩放，避免拉伸变形。这个裁剪不能放在 UI 线程做，否则切图瞬间会掉帧。我把裁剪放到后台，裁完再回主线程 setBitmap。一旦背景图准备就绪，混合滤镜会立刻用新纹理替换，不需要重建滤镜链，视觉上就是背景瞬间切换，这也是 GPUImage 这类框架最顺手的地方。
3.3 预览、拍照、录屏三态下的参数同步
美颜相机里最容易被忽略的是三种输出状态下的参数一致性。预览时 SurfaceView 或 GLSurfaceView 的尺寸可能不是相机原始尺寸，到了拍照走的是相机全尺寸输出，录屏则可能走的是另一个编码分辨率。如果每次都用同一组 thresholdSensitivity 和 smoothing，三种状态下绿幕残留程度会不一样，因为降采样会掩盖一部分边缘噪点，全尺寸输出时这些噪点全部现形。
我们的做法是：对外暴露的调参逻辑全部基于"绿幕均匀度"和"边缘羽化偏好"，在内部做映射。预览时把参数略微调激进一点，让边缘看起来干净；拍照时恢复标准值，并且拍完会立即在后台用拍照的原图重新过一遍滤镜，避免把预览的激进参数用在成片上。这个细节虽然小，但对成片质量影响非常明显。
4. 调参实战：把一块绿幕干净地"吃"掉
4.1 理想环境下的效果与参数区间
我在测试时专门借了一支打光灯和一块还算平整的绿幕布，模拟相对理想的拍摄环境：绿色幕布占画面大约 70% 以上，主体离幕布半米左右，灯光从左右 45 度打到主体身上，不在幕布上留下明显阴影。这种条件下参数宽容度挺高的，thresholdSensitivity 放在 0.35 到 0.45 之间都能出干净结果，smoothing 放在 0.08 到 0.15 边缘都比较舒服。
具体来说，我用 thresholdSensitivity = 0.4、smoothing = 0.1 的时候，绿幕基本被吃干净，人物的肩膀、头发边缘保留完整，只有极细的碎发处有一点绿边。调成 0.35 和 0.15 之后，绿边几乎消失，但代价是人物边缘多了一圈微弱的光晕，这是因为过渡区间把部分半透明前景也抹掉了。所以"干净"和"自然"在调参上是对着干的，你得知道用户更在意哪头。
4.2 光照不均匀时怎么救
现实场景根本没有理想绿幕。家里拉个窗帘、床头灯一开，幕布上就是一片亮一片暗。这种时候如果还用默认参数，暗部绿幕会抠不干净，亮部则可能把人物肩膀附近的肤色误伤。我针对这种环境调了一套"抢救参数"：thresholdSensitivity 降到 0.25 甚至 0.2，让算法对色度差异更敏感，同时 smoothing 提高一点到 0.18 左右，用来软化暗部边缘的残留。
但这里要提醒一下，thresholdSensitivity 调低不是万能的。它本质上是让"接近绿色"的判定范围变宽，范围变宽后，浅绿色的衣服、偏黄的肤色也会被波及。我在一台测试机上试过，用户穿了一件军绿色卫衣站在不均匀光照的绿幕前，threshold 压到 0.2 之后卫衣直接变成半透明。所以面对真实环境，更稳妥的方案是加强打光，或者退而求其次，接受边缘有一点残留，通过后续的模糊滤镜把它淡化。
4.3 边缘残留和半透明抖动的取舍
提到边缘残留，就不得不说视频预览下的"半透明抖动"。这个问题在静态图里根本看不出，一录视频就特别明显：人物边缘一圈像素在透明和不透明之间反复横跳，看起来像边缘在抖。根因是预览画面的噪声让 CbCr 距离刚好卡在 smoothstep 的过渡区间里，一帧算出来权重是 0.45，下一帧噪声一跳变成 0.52，透明度就跟着跳了。
我实测下来的缓解办法是给混合结果加一个时域上的稳定：不是每帧单独算权重，而是把上一帧的权重缓存下来，当前帧的权重和上一帧做线性插值。这个操作可以在滤镜外部做，也可以在自定义着色器里用 uniform 传入上一帧权重。我们最后选了第二种，在着色器里加了 prevBlendValue 的 uniform，每帧更新。插值系数取 0.3 到 0.5 之间，既能压住抖动，又不会让边缘拖出残影。
5. 真正的颜色加深混合：两个滤镜一起用的进阶玩法
5.1 ChromaKeyBlendFilter 与 ColorBurnBlendFilter 的分工
标题里既然挂了"颜色加深混合滤镜"几个字，就不得不聊一下 GPUImage 里另一个名为 GPUImageColorBurnBlendFilter 的滤镜。它在移动端图像处理里也挺常用，实现的是颜色加深混合模式，会让底图暗部更暗、亮部保留原样，公式核心是反相、相除、再反相那一套。它和 ChromaKeyBlendFilter 完全是两回事，但在我的滤镜链里，两者可以配合出现。
我把它们的分工讲清楚：ChromaKeyBlendFilter 负责"去掉你不想要的东西"，ColorBurnBlendFilter 负责"让留下的东西更有氛围"。举个例子，用户想把自己放到一张傍晚海边的背景图里，抠像完成后整张画面偏亮、没有黄昏感，这时候再接一个 ColorBurnBlendFilter，把夕阳云层的暗部压深一点，人物的轮廓和背景的暗部就融在一起了，代入感会强很多。
5.2 叠加效果示例：复古暗调背景替换
我在测试时做过一个很直观的叠加实验。先用 ChromaKeyBlendFilter 把绿幕去掉，替换成一张深色木质墙面的背景图；然后再叠加一层 ColorBurnBlendFilter，权重设在 0.3 到 0.4 之间。最终人物的皮肤稍微压暗了一点，木质墙面的纹理纹路变得更清楚，整体出来是那种偏复古、偏质感的暗调风格，和单独用 ChromaKeyBlendFilter 出来的"贴图感"完全是两码事。
顺带说一句，ColorBurnBlendFilter 叠加在整个滤镜链的哪个位置也是有讲究的。如果放在色度键混合之前，它对原图的改动会直接影响到抠像的颜色判断，让原本纯正的绿幕颜色变掉，导致抠不干净。我统一把它放在色度键混合之后、最终调色滤镜之前，这样它只作用于已经抠好的合成图，不会反向干扰抠像逻辑。
5.3 性能开销在手机上的真实表现
说了这么多，性能才是能不能落地的关键。我们把滤镜链从"磨皮美白直出"改成"磨皮美白 → ChromaKeyBlend → ColorBurn → 输出"之后，在一台中端机上做了 30 分钟压力测试。1080p 预览分辨率下，GPU 负荷大约增加了 18% 到 25%，整体帧率从 60 帧掉到了 44 帧左右。这个幅度说实话有点肉痛，并不是每一台手机都能接受。
后来我做了两个优化：第一个是把 ColorBurnBlendFilter 的混合权重降到 0.3，让它在低端机上可以直接跳过，只在高端机开启；第二个是把背景图的分辨率限制在预览分辨率的一半，因为背景图是静态的，降到 540p 肉眼几乎看不出差别，GPU 纹理采样压力却小了一截。优化之后中端机可以稳定在 52 帧左右，算是达到了可上线标准。
6. 第二十一天的踩坑记录与下一步计划
6.1 纹理翻转和预览/成片不一致
这一天的调试里最折腾的是纹理翻转。Android 相机出来的纹理坐标方向和 GLSurfaceView 的显示坐标偶尔不一致，导致抠像区域对不上：绿幕没被抠掉，人物的脸倒是被抠成了透明。这个问题很多教程提过一嘴，但没人说清楚什么时候会遇到。我后来定位到，问题出在相机传感器方向、预览旋转角度和 GPUImage 内部纹理坐标共同作用的结果，不同测试机的表现都不一样。
解决办法其实有点笨：在 setBackgroundBitmap 之后，对背景图纹理坐标做一次方向校正。我写了一个开关，默认关闭，遇到某品牌机型再手动打开，然后针对该机型的预览和成片分别记录方向偏移量。这个做法不优雅，但胜在稳，至少不需要为每台手机单独写一套坐标变换矩阵。
6.2 内存与纹理回收
另一个碰到的坑是 Bitmap 回收。背景图是不断切换的，每切一次就 new 一张 Bitmap 喂给 GPUImagePicture，如果不主动回收，内存涨得飞快。我在测试中连续切换了 50 张背景图，内存直接多了接近 300MB，其中大部分是 GPUImagePicture 内部缓存的纹理没有释放。解决方案是每次 setBackgroundBitmap 之前，先把旧的 GPUImagePicture 从滤镜链上 removeTarget，再调用销毁接口释放纹理，最后再 new 新的。基线测下来，连续切换 50 张图之后内存只涨了不到 20MB，这个数字才是正常的。
6.3 下一步：边缘羽化与肤色保护
第二十一天做完，背景替换这条线算是跑通了，但离真正好用还差两件事。第一是边缘羽化不够精细，目前 smoothstep 的参数是全局的，遇到发丝这种细节多的区域，边缘容易糊成一片；下一步准备做局部自适应参数，让边缘区域单独用更强的羽化。第二是肤色保护，thresholdSensitivity 调低之后黄皮肤容易被误伤，这需要把肤色区域先从抠像范围里排除出去，或者引入一个人脸肤色的先验 mask。这两块做出来，背景替换才算没有明显短板。
进度上，这个系列已经从滤镜堆叠走到画面合成，再往后就是把这套滤镜链整理成可配置的模板方案，让产品不用发版就能调参上线。等边缘羽化和肤色保护做完，我会把完整的参数模型和测试机数据一起整理出来分享。
