关于深度学习:圆桌实录-为什么不约而同选择了大-Kernel

在 3.19 日的 “Large Kernel Makes CNN Great Again” 专题 Meetup 中，咱们组织了一次圆桌探讨，心愿能通过探讨一些比拟有共性的问题，碰撞出更多新想法。本篇为文字实录，enjoy~\
视频回顾见 01:42:40 Large Kernel Makes CNN Great Again

嘉宾介绍

主持： 许怅然 | 旷视天元 MegEngine 负责人

嘉宾：

刘壮 | UC Berkeley 博士生，ConvNeXt 作者
张祥雨 | 旷视研究院 Base Model 组负责人
丁霄汉 | 旷视研究院 Base Model 组实习生、清华大学博士生
王彪 | 旷视天元 MegEngine 异构计算组负责人

Q1: ConvNeXt 论文里提到用 7x7 Kernel 之后性能饱和，而 RepLKNet 里提到越大越好，两篇论文论断差异可能是因为什么？

主持 – 许怅然

非常感谢大家能参加到这次圆桌，这次第一个问题是我集体想问的，在 ConvNeXt 外面其实提到了 7×7 Kernel 之后性能饱和，而 RepLKNet 恰恰相反—— Kernel 越大性能越好。导致两篇论文论断差异的起因是什么？只是上下游工作评估不一样吗，还是有什么别的起因？

Q1: ConvNeXt 论文里提到用 7x7 Kernel 之后性能饱和，而 RepLKNet 里提到越大越好，两篇论文论断差异可能是因为什么？

主持 – 许怅然

嘉宾 – 刘壮

其实咱们也有想过持续再增大 Kernel，可能的确能够更好。咱们发现在 ImageNet 1K 分类这个问题上，其实它跟网络 regularization（正则化）的强度是十分无关的。咱们整个试验中次要调的一个参数就叫 stochastic depth（随机深度），其余的参数根本没有调过，都用的是以前别的论文用的。这个参数越大，网络 overfiting（过拟合）的水平就越低，而后咱们发现它和 kernel size 之间相互影响很大。你扭转一个值，另外一个值的 optimal value（最优值）就会扭转。所以 7x7 只能说是在这一个特定 regularization 强度的状况下是最优。如果加大你的 regularization ，那么持续加大的 Kernel size 可能会更好，因为它不会那么 overfiting。我发现在从 7x7 往上再增大到 9 和 11 的时候，网络的 training loss（训练损失）仍然在升高，然而 test accruacry（测试准确率）就不再升高了。

还有一个问题就是上下游的问题：在 ADE20k 下面，我发现它的最优 Kernel size 也是不止 7x7 ——它到 9 的时候仍然有晋升。所以这跟旷视的 RepLKNet 也是类似的发现。

当然还有一个最重要的起因：用 7x7 是为了和 Swin Transformer^[1]他们保持一致，因为它的 window size 是 7。其余参数，咱们都根本和 Swin Transformer 保持一致。

主持 - 许怅然

对此，霄汉和祥雨看有什么认识？

嘉宾 - 张祥雨

我来简略发表一下咱们这边的察看和一些观点。

其实咱们这项钻研，其实首要目标并不是为了找一个在某项工作上最优的一个 Kernel size，而是指出一个方向——你想让网络达到更大的感触野，实现更好的性能，那么你的 Kernel size 的总体趋势是要越变越大，次要是一个趋势的问题。

至于在现有的数据集、现有的 training setting（训练设置）下，哪个 size 最好，这个是要看状况的。比如说 segmentation（宰割），它是特地须要很大感触野的，这种状况下，更大的 Kernel size 就更为重要；并且现有的一些工作也展现出这个趋势，比如说大家可能会相熟 Swin Transformer v2^[2]，还有像 CSwin^[3] 这类改良的 window transformer，你会发现它的总体趋势也是感触野越来越大。具体来说，CSwin 的窗口是 3 乘以整个图像尺寸这么大，Swin Transformer v2 也应用了好几十的 window size。另一方面，随着 window size 越大，咱们的优化就越艰难，很有可能你在优化上吃到一些负面的影响。但如果你能解决优化问题，比方像 RepLKNet 里应用 reparam 或者用更大的数据集、更强的 augumentation（样本增广），只有把优化问题解决的话，你会发现大 Kernel 的下限可能更高。

嘉宾 – 丁霄汉

方才刘壮说 stochastic depth，咱们也是发现这个货色比其余的影响更大，其余的参数基本上都跟 swin 差不多。这个参数咱们过后好好调了调，然而最初也没有发现说大 Kernel 要比 Swin 或者比别的模型要更容易过拟合。咱们最初用的这些 stochastic depth 的值也都是 0.3 到 0.5，是一个常见的取值范畴，并没有发现大 Kernel 显著地比其余模型更容易过拟合，可能会更容易过拟合一点，然而并没有差异很大。

主持 - 许怅然

好的，看起来这可能是一个后续能够摸索的中央。

Q2：大 Kernel 是否会导致优化更艰难的问题？怎么解决？过大的 Kernel 是否有可能让模型更容易过拟合？如果有，有没有发现须要增大正则化，或者扭转其余训练的配置去解决这一问题？

主持 - 许怅然

第二个问题，其实是刘壮之前发的问题，而后联合了另外一个大 Kernel 导致优化更艰难的问题。方才祥雨也提到了，比如说对于这些正则化或者优化更艰难的，看看对这个问题，霄汉和祥雨还有没有其余的解决思路？

嘉宾 – 张祥雨

我来先开个头，对于大 Kernel 是不是会导致优化更艰难，其实相似的景象大家在 ViT 这个系列曾经发现了。过后 ViT 刚出的时候，社区里有很多人批评说 ViT 跟一般 CNN 的比照齐全不偏心——用像一般 ResNet 这种规范的 training setting，它其实成果是比不过的。所以有人就以此来批评 ViT 其实并不实质。

然而起初大家发现：尽管用比拟弱的这种 training setting 它成果是比拟差，然而一旦你用更强的 training setting 解决了它地优化问题，它其实能够展现出比 CNN 更高的下限。因而，可见大 Kernel 可能导致优化艰难这件事的确是客观存在的，

那大家是怎么解决的呢？在 ViT 外面咱们晓得当初有很多 ViT 加卷积地混合结构，那么这种加卷积的做法其实十分相似于咱们在 RepLKNet 外面通过 reparam 加小卷积核的这种做法，通过引入更多的 inductive bias（演绎偏置）来解决优化的问题。

还有就比如说像 Google 它在 ViT 可能会应用 JFT 这种十分大的数据集做 pretrain 来解决优化的问题。还有哪些？比如说最近十分火的基于 MIM（即 Masked Image Modeling）pretrain这种办法——像 BeIT^[4]、MAE^[5]、SimMIM^[6] 等等这一系列工作通过自监督预训练的办法，让 Kernel 大体上预训练地比拟好，它们也能解决优化问题。

而后咱们最近发现，所有这些解决方案其实在大 Kenel 的 CNN 上也失去了验证，进一步就阐明大 Kernel 跟大 window size 或者 global 的 ViT，它们具备十分强的相似之处，也进一步佐证大 Kernel 很可能是 self-attention（自注意力）的一个十分好的代替。

至于“过大的 Kernel 是否使模型更容易过拟合”，其实这里咱们发现一个乏味的景象，就是对于上游来说，它的确体现为更容易 overfit，对于上游来说可能相对而言反而会好一些，这其实有点反直觉——咱们直觉是上游往往数据集比拟小，更容易过拟合；而上游的话数据集越大，它反而不容易过拟合。

最近咱们一些钻研就发现过拟合很可能是（后面几位讲者都提到了）和相对地位信息的泄露无关。因为在上游的时候 image size（图片尺寸）比拟小，而后咱们晓得大 Kernel 的话，它的 padding 是很大的，padding 会泄露很多相对地位信息。比方，在上游训练中你要分类一个苹果，如果说苹果呈现在左上角，那么如果你不泄露相对地位信息，那么它就会严格依据苹果的 appearance（外观）来进行分类，那么在你测试的时候把苹果移到右下里，模型应该也能辨认；然而如果你泄露了相对地位信息，那么就相当于它只能记住左上角的苹果应该怎么分类，它可能就不晓得右下角的苹果是要怎么分类，因而这可能是过大的 Kernel 的一个副作用。

当然想解决这件事也是非常简单的，只须要在上游在训练的时候采纳 multiscale 训练，让它在各种 padding 都见过一次，这样的话就能够杜绝一些相对地位信息泄露带来的问题。

另外，相对地位信息泄露其实很多时候不肯定是好事。比如说大家可能会相熟在上游的检测算法 DeTR^[7]。在 DeTR 里，因为它的 query 是须要在全图尺度进行主动训练，如果你的 backbone（骨干网络）不蕴含相对地位信息，那么它 query 的对应地位的学习就会变得十分艰难。所以之前也有很多钻研 positional embedding 的工作也指出了，如果你上游应用 ViT-like 的这种构造的话，你必须要进行相对地位编码，不能只应用绝对地位编码，这样能力达到比拟好的成果。

Q3：大 Kernel 和小 Kernel 是对抗关系吗？比方是否存在更偏好在浅层应用大 Kernel / 深层更偏向小 Kernel 之类的？

主持 – 许怅然

感激祥雨给出了很多的倡议。上面这个问题，就是大 Kernel 跟小 Kernel 是否为一个很对抗的关系，是否存在一种比如说：在浅层更偏好用大 Kernel，深层更偏向于用小 Kernel 等等这一类。是否有一些网络设计构造上的不同地位的偏好？请霄汉先发表一下认识。

嘉宾 – 丁霄汉

首先大 Kernel 跟小 Kernel 它必定不是对抗的关系，咱们在这个文章外面只用了大 Kernel，咱们用小 Kernel 只是拿它用来做重参数化而已。然而如果你想到某种机制，比如说像 SKNet^[8] 那样，找到某种机制把大 Kernel 和小 Kernel 的更好的联合起来，那必定是能够的。

咱们临时没有发现浅层和深层有什么广泛的法则。咱们在浅层用比拟大的 Kernel，只是因为它浅层的通道数比拟少，而且 feature map 比拟大，所以咱们用了大的 Kernel，深层用的略微小一点的，但也是 13×13 这样的 Kernel。然而咱们并没有察看到什么显著的法则，说在什么样的层上用多大的 Kernel 更好。因为毕竟炼丹还是一个玄学实质的货色，这都是须要进一步的尝试才晓得的。

主持 – 许怅然

那么，在设计整个 ConvNeXt 的时候，因为不同的 block 其实当初用了构造都是一样的，比方是 7×7 都是 7×7，是 3×3 都是 3×3。这个中央比如说有试过，不同地位大小不一样之类的这种操作吗。

嘉宾 – 刘壮

其实没有，咱们还是所有从简。

嘉宾 – 张祥雨

我简略评论一下，其实从示意能力来说，大 Kernel 必定是严格高于小 Kernel，然而大 Kernel 如果你训练不好，它不容易失去好的性能，这也阐明了这外面大 Kernel 和小 Kernel 的差距，它并不是在示意能力方面，而是在优化方面。其实这给咱们提出了一个更广宽泛的一个课题，就是说到底当初这些CNN咱们须要用哪些优化伎俩能力把它优化得更好？

咱们晓得当初大家广泛应用的优化器都是 SGD、SGDM，或者是 Adam 。这些优化器都是跟架构无关的，属于通用的、gradient-base 的优化器，它没有思考架构自身的个性。但事实上对于卷积神经网络这种非凡的构造，它具备很不同的感触野、不同的分辨率，咱们在优化 Kernel 的时候必定是要思考架构自身的因素。

其实咱们在这次 CVPR2022 也投了一篇工作，尽管很遗憾被拒了，然而我感觉论断是十分乏味的。就是说咱们只通过改优化器的伎俩，而后既不改架构、也不利用像 reparam 这种 trick（技巧），就仅仅是通过改优化器，就把像 VGG-like 的一个直筒状的构造，达到了 84% 的程度，这其实预示的是，大 Kernel 这件事，其实在揭示咱们当前可能要更多的关注优化，而不是架构自身。这篇工作也是十分荣幸跟霄汉还有我的另一个实习生一起做的，我感觉可能是代表了下一代神经网络架构设计的新方向：咱们不只有思考表征（示意能力），还要思考优化。

主持 – 许怅然

其实这给我带来一个感觉，因为极其状况下，咱们齐全能够把整个网络看成一个全连贯，只不过咱们当初不论是大 Kernel、小 Kernel 还是 conv 的这些操作，都只是对它进行了一些特定的束缚，感觉大 Kernel 就是把束缚略微放宽了一点，而后它的优化就变得很艰难。极其状况下我就是一个超大全连贯，而后只有我能优化得进去，他肯定表达能力比 conv 强。

Q4: Kernel 变大之后，stride 能够做的更大吗？在精度上有什么损失么？计算效率方面能晋升么？

主持 – 许怅然

因为其实咱们之前没有探讨过 stride 的相干问题，而后像 swin 里边其实就能够认为它 stride 跟 Kernel 差不多，就相当于它跳着往前走，间接一次走 7 个格。而后想晓得如果 stride 做的更大的话，在精度上会有什么损失吗？以及在实现效率方面有什么晋升吗？王彪在计算效率这方面感觉有什么更好或者更坏的影响。

嘉宾 – 王彪

计算效率方面其实次要跟试验办法是相干的。比如说咱们就像用 implicit batched matmal 去算的话，实际上它的 stride 的影响并不是很大。在相似英伟达 GPU 这种架构上面它的影响不是很大；然而如果你在嵌入式或者在一些比拟低端的板卡上，因为它的 stride 大了，访存会受一些影响，所以它计算效率方面必定是不如 stride 等于 1 的。然而咱们能够尽量的做到一个最优的性能，就是优化总是做不到止境的。

主持 – 许怅然

看起来随着变大了之后，反而这块更算起来效率更低了，如同这块就没有必要探讨它在算法精度上的益处了。

而后这里引申了另外一个问题，就是当初咱们的卷积核变大了之后，还依然都是奇数，比如说 11×11、13×13。如果这个中央变成 32×32，在代码优化上会轻松很多，因为它其实会十分的参差。这一点想问问三位网络设计的同学，在 Kernel 这么大了之后，还保持用奇数有什么思考吗？用偶数会有什么不好吗？

嘉宾 – 刘壮

我的了解这是比拟 technical 的问题。奇数的话，如果把一个像素看成一个小网格的话，卷积能够正对网格的核心。这样的话你就能够做到 input、output 地位是齐全 align（对齐）的。如果是偶数比如说 2×2 的话，这样的话左上角 4 个像素的交叉点是下一层左上角第一个像素 feature 的核心，所以如果层数多了之后，它可能缓缓的跟原始的输出图像就会有一些偏移。

因而，之所以用奇数不必偶数，其实是当 input、output 像素一样时候，上一层和下一层的边界处能不能 align 的问题。如果在分类工作可能没有那么重要，然而在上游工作那种对于 input 和 output 一致性要求比拟高的状况下，可能奇数是一个比拟适合的抉择，如果偶数的话可能你要做一些 interpolation（插值）或者是 sampling（采样）这样子的，这就是我的了解。

嘉宾 – 张祥雨

对，的确如刘壮所说，奇数它最大的益处就是能够做到对齐，当然如果你成心不想对齐那也是能够的。我想讲一个故事，是咱们过后做 ResNet 的时候，其实就特地思考到这一点。大家能够计算一下， ResNet 的话它的 (0, 0）那个 pixel 刚好对应 output feature map（特色图）的那个 (0, 0) 的 pixel；然而反过来，它的最左边就是(223, 223)，那个 pixel 它并不对应最初一层 feature map (6, 6) 那个 pixel，它会对应到里面去。

这种网络咱们外部的说法叫做左对齐网络，它的左右是不对称的，就是说它右边是 (0, 0) 对应到 (0, 0)，左边它并不是对应的。而同期间还有一些其余的网络，比如说 VGG，咱们把它叫做核心对齐网络，就是说它的右边那个 pixel 它刚好对应到 feature map 的右边，而是它输出的正中间的地位刚好对应输入的正中间。

为什么这样设计？过后做 ResNet 的时候，这样做也是无意为之。因为咱们发现很多做上游工作的人，比如说做 detection 或者做 segmentation 的人，并没有这种意识，他不晓得核心地位的 padding 要怎么计算。他只会就比拟 naive 的，比如说输出是线段长度 32，它对应到输入 stride 是 16，我就简略的除个 16，就是只会这种等比例放缩。但按道理说你是要加一个 offset，能力实现对齐，所以说如果你不晓得这个货色，那么其实在做的时候就会显著的掉点。为了避免这些用户因为这个起因，把咱们 ResNet 上游的点报低了，所以成心做成了左对齐网络。

其实大家能够看到，过后很多网络都不是属于这种左对齐，比如说 GoogleNet，它的核心 pixel 大略在 (5, 5) 那个中央，也就是说你在做 detection 的时候，整体 offset 要加一个 5，如果你不做这个就会显著的掉点。对于 VGG 来说，它 offset 的大略是 (7, 7) 左右。然而反过来，左对齐网络总体上来说就给人感觉就不是很make sense是吧？右边和左边它都不对称，所以这也呈现了一个景象，大家做 test time augmentation 的时候会用到一个叫 flip（翻转），沿两头 flip 一下，而后 average 一下，大家发现很多网络是能够涨点的。其实这个都是因为左对齐网络，它在右边的关注中心点和左边是不一样的，它对图像右边的关注要高于左边，所以你把左边的一些概念给它 flip 到右边，你会发现它再 ensemble 一下它常常能够涨点。

然而毕竟这是一个不好的个性，所以我认为，在当前咱们可能还是更偏向于用这种核心对齐的网络来设计，核心对齐当然有各种办法，然而把 Kernel 变成偶数，就是一个绝对比较简单的计划。

主持人 – 许怅然

十分有意思，感觉这个中央后续咱们能够试一试。

Q5：在嵌入式设施上，DDR 带宽更低，大 Kernel 是不是计算性能就上不来了？

主持人 – 许怅然

下一个问题想请王彪来答复一下：在 GPU 设施上，依据 roofline model 的剖析 depthwise conv 都是卡在访存这一块的，所以你通过大 Kernel 减少计算它是很值的；然而在嵌入式这些设施上，它的 DDR 的带宽要显著的低的多，比方比 CUDA 上是低 10 倍以上还是很容易的，大 Kernel 是不是计算性能就上不来了？就是说会不会呈现在嵌入式设施上 dwconv kenel 间接在小 kernel 状况下就曾经就卡在计算而不是访存的这种状况呢？

嘉宾 – 王彪

是有可能的，然而跟 DDR 带宽可能关系不是很大。要综合看设施上的实践峰值，看饱和点在什么中央，如果你 3×3 的 deconv conv 曾经饱和了，你再做大 Kernel 其实没有多大意义了，因为性能不会有太大的晋升了。然而实际上咱们所看到的这些 ARM 上的板子，就是 dw conv 它的性能还是不饱和的。

主持 – 许怅然

这个问题可能将来对于像 NPU 类的设计会有比拟大的影响，因为 NPU 的算力很猛，然而 DDR 其实跟 ARM 这些设施其实差的也不算太多。

嘉宾 – 王彪

是的。

Q6：如果应用全局大小的 Kernel，是否能够用最近 GFNet 中的 FFT 模块代替？FFT 和全局卷积数学上是等价的

主持 – 许怅然

最初想聊聊全局大小的 Kernel，因为最近 GFNet^[9]之中有 FFT ，而后能不能用FFT 的模块代替之前，王彪曾经在算力这个角度上曾经答复完了，而后从算法角度上来说，想看看霄汉有没有什么认识。

嘉宾 – 丁霄汉

这外面首先一个问题就是 FFT 它不肯定特地好实现，再一个就是 FFT 它等价于一个全局视角的卷积，但可能单层去做全局的卷积也不是一个最优解。咱们把小 Kernel 变大，然而也不肯定要极其到要和输出一样大，可能也不是一个最优解。而且咱们也看到 GFNet 外面，它也并没有展现出上游工作上的性能，因而也并不确定这样的做法，它到底在上游工作和更大量级的模型上是不是一个更好的做法。

嘉宾 – 张祥雨

我评估一下。首先，刚刚有个中央说的不太对，其实 GFNet 是 benchmark 了上游，还能够。然而 GFNet 有几个中央是跟大 Kernel 卷积是不太一样的。

如果你间接应用 FFT，就像他 paper 里说的那样，而不应用 padding 的话，它其实等价的不是一般的咱们说的大 Kernel 卷积，而是大 Kernel 循环卷积，就是说右边它要循环到左边，下面要转一个圈到下边，这件事其实不是特地的 make sense，咱们尝试过其实成果也不是很好。

如果要严格实现等价的全局大小的 Kernel 的话，那么须要对 GFNet 的做一些批改。比如说人为加一些大的 padding，这时候它的确是跟全局在数学上是等价。能够认为，这是全局卷积的一种高效的实现形式。

然而就跟刚刚霄汉说的一样，全局卷积目前来说它的必要性证据还不是很足，因为次要有两点：

第一，随着卷积和越大，它优化就会变得越来越艰难。咱们到 31 的时候曾经须要一些像 reparam 这种策略来帮忙它优化，然而如果再大的话，其实咱们也不是很分明要用什么样的形式能力让它优化的更好，但兴许是重要的。

第二个问题我感觉更重要，就是咱们把外围的卷积和扩充，它是为了晋升感触野，然而感触野能够类比为在 ViT 或者 transformer 里，大家都十分关怀的叫做长程依赖。然而在视觉外面，其实咱们很多时候所须要的不只是长程依赖，咱们要的是高阶的长程依赖，就是说不只是依赖的范畴重要，依赖的阶数也重要。

什么叫依赖的阶数？比如说 a 点 b 点和 c 点它属于一个物体，那么 a 间隔 b 它的特色是比拟像，咱们能够认为它是一个物体， b 和 c 它的间隔也是比拟靠近了，咱们认为它是一个物体，然而 a 和 c 绝对比拟远。那么我要想造成一个整体的宰割 mask，其实我须要从 a 和 b 相近的关系和 b 和 c 相近的关系推导出 a 和 c 相近，这是一个二阶的逻辑。更显著的咱们可能还要用三阶、四阶这种更高的逻辑能力推导出一个物体从最右边到最左边像素的类似度或者它们之间的关系。如果你间接一步看过来，从感触野的角度那是齐全足够，但从关系的阶数角度可能还是不够的，须要多建模几层。

其实咱们之前有两篇工作叫做 Tree Filter^[10]^[11]。比拟具体的提出了这个问题，并且咱们发现在 segmentation 这样的工作，的确高阶的长程阶段是更为要害的。如果大家想不太明确这个问题是为什么，能够再构想一个问题叫解迷宫。咱们输出一个迷宫。而后输入一个 segmentation mask，就是从入口到进口，大家想这个问题必定是须要长程依赖能力解决，因为它是个 non-local 的问题，然而，是不是我就间接应用十分大的 Kernel，或者是应用一个 attention 就能够解决，从进口看到入口呢。那显然不行，我得从两头一步一步跟过来。事实上，咱们发现，为理解这种问题，中等尺度然而有肯定层数的卷积反而是比拟要害的，单层的大 Kernel或者是大的 attention 可能反而不行。

主持 – 许怅然

好的，那么以上就是本次圆桌重点想交换的问题，感激几位的分享。谢谢大家。

参考文献

[1] Liu, Ze, et al. "Swin transformer: Hierarchical vision transformer using shifted windows." Proceedings of the IEEE/CVF International Conference on Computer Vision. 2021.

[2] Liu, Ze, et al. "Swin Transformer V2: Scaling Up Capacity and Resolution." arXiv preprint arXiv:2111.09883 (2021).

[3] Dong, Xiaoyi, et al. "Cswin transformer: A general vision transformer backbone with cross-shaped windows." arXiv preprint arXiv:2107.00652 (2021).

[4]Bao, Hangbo, Li Dong, and Furu Wei. "Beit: Bert pre-training of image transformers." arXiv preprint arXiv:2106.08254 (2021).

[5]He, Kaiming, et al. "Masked autoencoders are scalable vision learners." arXiv preprint arXiv:2111.06377 (2021).

[6]Xie, Zhenda, et al. "Simmim: A simple framework for masked image modeling." arXiv preprint arXiv:2111.09886 (2021).

[7]Carion, Nicolas, et al. "End-to-end object detection with transformers." European conference on computer vision. Springer, Cham, 2020.

[8]Li, Xiang, et al. "Selective kernel networks." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2019.

[9]Rao, Yongming, et al. "Global filter networks for image classification." Advances in Neural Information Processing Systems 34 (2021).

[10]Song, Lin, et al. "Learnable tree filter for structure-preserving feature transform." Advances in neural information processing systems 32 (2019).

[11]Song, Lin, et al. "Rethinking learnable tree filter for generic feature transform." Advances in Neural Information Processing Systems 33 (2020): 3991-4002.