（胡渊鸣）（1）基于RL和GAN实现无穷分辨率白箱图片处理（2）从TensorFlow到Taichi

前段时间胡渊鸣大神的文章《99行代码的《冰雪奇缘》》特别的火，现在突然发现大神早在18年就有过一个关于Taichi的报告视频，我闲着没事看了一下。这个视频的前部分介绍了他本科在MSRA时候的毕业设计，报告的后半部分则是关于TaiChi的闲聊。

 

Part 1

这篇文章使用RL和GAN来进行一种类似图像后处理的操作，并且这个处理具有以下方面的优点：1.不依赖于分辨率，如果分辨率很高的话，采CNN方法来处理会导致训练成本很高，如果不依赖于分辨率，那么会带来性能上的一定提升。2. 不用提供输入输出的图片，模型也可以进行学习3.可以知道其中各操作做了什么，普通的模型是放进去一堆数据然后训练出来一张图片，但是训练者对其中进行了什么操作并不清楚，而这片文章可以反向的知道这些训练在背后做了什么，比如某部分训练是进行了饱和度调整的学习，另一部分训练是进行Gamma修正的学习。4.End-to-edn Processing

CycleGAN解决了没有配对的问题。CycleGAN输入一张图片，给出对应的一张输出图片，但是在训练过程中没有配对关系。

对抗生成网络分为两部分，一部分是Generator，不断输入图片，输出处理过的图。另一部分是Discriminator ，将处理过的图和真图比较。形象的解释就是，Generator在不断地造假币，而Discriminator在不断地鉴别假币，在这个对抗过程中，双方的能力都获得了提升。

Cycle GAN中间用了U-Net用一张分辨率比较高的图片通过不断地卷积和降采样，把它的分辨率不断降下来，外加一些跳跃连接，来保存前面一些层次细节比较高的部分到后面。不过这本质上还是一个编码和解码的过程，会带来一些细节上的损失。

 

上述这三个都不能完全满足上面的四个要求。

这里对图像后处理操作进行建模的灵感来自于人类处理图像的过程，人类处理图片是并非一步直接完成的，而是分成很多步，而这其中很重要的一部分就是每一步后的反馈，就是处理图像后的效果：哪一部分处理的好，哪一部分还需要调整等等。

上面提到的步骤和RL很相似，RL中的Agent不断根据每个策略进行操作，环境负责给Agent进行反馈，如果Agent的某个行为策略导致环境正的奖赏(强化信号)，那么Agent以后产生这个行为策略的趋势便会加强。

RL中的Action，大部分的Filters其实都是一种可微的操作。

负责反馈的环境使用了Wasserstein GAN，Discrimination部分采用了和CNN相似的架构，而Generation部分把CNN模型换成了一个可微的Retouching Model。

训练过程

处理结果

Part 2 Taichi

这个开源库作者在18年报告时说道已经开发两三年了。

图形学在底层的工具方面很耗精力，“在SIGGRAPH社区里，造工具的和用工具的，是一帮人。或者说，好用的工具，很大程度上并没有分离出来，大部分还停留在“一次性”的阶段，所有人都要把底层的知识重新学一遍”，一个例子即使是输出一张图片也需要一些工具或者库，这就造成门槛的提高。这个图片我看了下是在清华CG课程下面的留言，在B站上有这门课的视频，不过日期是很久之前的了，建议和CMU的CG课一起食用：一个是有视频讲解没代码，另一个是有代码没讲解。

 

上图给出了一些常见的库比如渲染中的Mistuba、PBRT，几何处理中的Libigl，CGAL和模拟中的Bullet，ODE。但是不幸的是，很多情况下我们需要自己实现一些比较底层的东西。

甚至我们就算build一个库也很难。他给出了一个例子说一位同学求助自己build cgal，然后帮这位同学build完成后，这位同学回复道“Yuanming is a genius”。这里我深有感触，之前做数据结构课设的时候想用CGAL来做一个Voronoi图和Delaunay三角剖分，然后我在配CGAL库上卡了两天。这个配置过程是真的让人揪心，网上配置教程都和实际过程有点出入，出现过各种错误，我甚至都想不做这块了。

创新的想法、快速的开发、代码的强健性很难同时获得。如果想追求迅速的开发和代码的重用性，那么很难实现很高的效果；如果追求innovation ideas和快速开发的话，那么代码很难保证重用性，别人很难复现代码。

“Why do we need something tailored for graphics? Why not just reuse Boost or Eigen?”由于Eigen并非为图形学定值的库，它在存储上做了一定优化，但是时间性能上优化不足，而图形学则比较关注性能，很少关注存储。

C++在性能上更加友好，但是它同样存在着一些不足，比如：比较复杂，可移植性差，编译时间长等等。python对用户更加友好。Taichi将两88者结合了起来，在Kernel部分使用C++，在用户层面使用Python，中间用pybind11来连接它们。

上图右方是一个88行实现的一个MPM。Taichi只需要两个文件就够了，一个是自己的demo，另个一是Taichi.h,不需要Makefiles和CmakeLists，虽然没并行化，但是依然比Python和MATLAB快。