起因#
年初的时候在一家互联网公司实习，当时我们有一个场景在 Android 端使用了 OpenCV 里的 Guided Filter。有一天，老板说让实现一下Fast Guided Filter，看看会比Guided Filter快多少。
准备#
在经过了短暂的调研后，我发现 OpenCV 里并没有集成 Fast Guided Filter。网上倒是有一些人做的给 OpenCV 使用的 Fast Guided Filter，但这些 “插件” 要引入很多第三方代码，我觉得不够优雅：
然后我读了一下 Fast Guided Filter 的论文，发现它与 Guided Filter 的区别仅仅是在处理过程中加入了下采样和上采样的过程。而 OpenCV 里 Guided Filter 的实现出现的比较早，在 Fast Guided Filter 之前，所以就没有包含，也算可以理解的。不过令人奇怪的是为什么这么多年过去了，还没人给 OpenCV 提供这个能力。
经过#
2024.01 提交代码#
于是我直接给 OpenCV 的 Guided Filter 接口加了个参数scale，代表重采样的倍数。很快代码就改完了，经过测试，结果确实符合预期；将整个算法的时间复杂度从降低到了。
于是当天我就把Pull Request发到了 OpenCV 的 GitHub 仓库，当时跑了几个流水线，看着都通过了，于是我就理所当然地把这件事抛在脑后了。
2024.02 评审#
一周后，我看 PR 还是没有动静，于是就看了几个其他人的 PR。我发现其他人的 PR 被跑了新的流水线，然后我的流水线在重新跑的过程中超时了，于是有点吃醋（INFP 人格发作了），就艾特了一下启动流水线的人。
又过了一周；在春节的时候，总算有人给我回复了；他提了几个比较简单的修改意见，我也很快给改完了。其中主要是单测很难实现，因为很难有一种比较容易量化的手段来检测生成的图片是否符合预期。
在想了很久后，我最终使用了一种很折衷的手段：以应用拉普拉斯算子后的图片的方差作为评定标准，Fast Guided Filter 的结果应该比直接下采样再上采样的结果大（即 Fast Guided Filter 比 Naive 方法保留的细节更多）。而且，Fast Guided Filter 的结果与 Guided Filter 的结果不应该差别太多（即，不会丢失太多细节）。这里，调节参数其实是在测试了 N 次失败以后随便敲定的一个值。。。感觉好在 reviewer 没有刨根问底。
2024.05 合入#
后来几个月都没有得到回复，我就又把这件事忘了。五月份的一天，这个 PR 突然被合入了；于是我就去官网看了一下最新的文档，结果却发现有了一个语法错误：
我勒个豆啊，怎么把 scale 的描述打错了，写了个to speeds up？？哦，原来是最开始写的speeds up，后来斟酌了一下想改成to speed up，结果没改全。。。真是吐血了。OpenCV 的维护者基本都是俄罗斯人，估计也没有注意到这种细节。
结果#
所以现在 OpenCV 有 Fast Guided Filter 可以用啦，再也不用引入来源不明的第三方代码勒。好耶。在这里吹一下 OpenCV 的文档系统，只要在 cpp 源码里写出合适的注释，就会自动生成相应的文档，甚至连 python 的 api 文档豆给生成了。咱也不知道这用的是什么神奇的工具。
总地来说，这次的体验还是很好的。美中不足的地方是 PR 合入的比较慢，以及最后因为自己的锅导致官网文档上有了一个 typo。不过 OpenCV 的维护者看起来人手不太够的样子，所以这样子也可以理解啦。
所以，现在我也有 OpenCV 的Contributortag 啦！！！
うれしいです～