在 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 里提到越大越好，两篇论文结论差别可能是因为什么？

主持 – 许欣然

非常感谢大家能参与到这次圆桌，这次第一个问题是我个人想问的，在 ConvNeXt 里面其实提到了 7×7 Kernel 之后性能饱和，而 RepLKNet 恰恰相反—— Kernel 越大性能越好。导致两篇论文结论差别的原因是什么？只是上下游任务评价不一样吗，还是有什么别的原因？

嘉宾 – 刘壮

其实我们也有想过继续再增大 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 可能反而不行。

主持 – 许欣然

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

附

更多 MegEngine 信息获取，您可以：

查看文档、 MegEngine 官网和 GitHub 项目，或加入 MegEngine 用户交流 QQ 群：1029741705

参考文献

[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.