起因#
年初的時候在一家互聯網公司實習，當時我們有一個場景在 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 啦！！！
うれしいです～