请求对3.7节Compositing的翻译校对

[tumluliu]

在这一节的翻译中，考虑到原文的介绍性文字太少，我加入了一些背景与解释。但由于关于Compositing的中文资料很少（我只找到一本译作《数字合成的科学与艺术》，原书是五星经典，但中文版翻译质量不清楚，译者们来自nudt五院），所以到了后面的各个合成操作的解释时我已经把持不住了，烦请各位帮忙整理校对。多谢！

SHA: b1db474

@yarray @xiaohou122 @nuoshidini

[yarray]

收到，最近抽空看一下。
这个composition最常见的应用应该是在photoshop里？

[tumluliu]

从原文中的内容看，他们尽量通过与PS的对比来让读者明白comp-op的用法。wiki上的相关页面：

• Compositing
• Photomontage

我感觉最相关的参考文献The Art and Science of Digital Compositing 2nd edition。有中文版，但不知道翻译质量如何（翻译是四个人加一个“等”，是nudt5院的。。）

其实主要是那些具体的操作的解释让人蛋疼。

On Tue, Mar 31, 2015 at 5:04 PM yarray notifications@github.com wrote:

收到，最近抽空看一下。
这个comp-op最常见的应用应该是在photoshop里？

—
Reply to this email directly or view it on GitHub
#3 (comment).

[yarray]

@tumluliu 我觉得有些混乱的来源是原始文档自己的。

比如 source 和 destination 的概念本来是很清楚的，就是源图像和目标图像，至多到 photoshop 里改为源图层和目标图层。mapnik 或者 cartocss 里其实概念完全是一样的，就是不同样式渲染出不同图层（也是图像）后，在图像级进行运算，到这一步就和 style 或者 symbolizer 一点关系都没有了，它偏搅一起，就有了这样的句子：

The source is the style or symbolizer that the comp-op property is applied to, and the destination is the rest of the image that is drawn below that.

（引自： https://www.mapbox.com/tilemill/docs/guides/comp-op/ ）

这根本不对啊…… source 是 style 和 symbolizer，destination 是 image，俩不同世界的东西怎么运算？

不过我也没想好怎么处理这个问题，再想想吧

[yarray]

@tumluliu 以及我大概整体看了一下，感觉很多纠结点都出在原始文档表述不清上，结合自己的学习使用经验，我觉得就现版本而言不管 CartoCSS 还是 Mapnik 都有意无意地采用了类 photoshop 的图层抽象，只不过图层不扁平而是有几层嵌套。但遗憾的是 Mapbox 并没有在文档里一直强调这个抽象。一般认为样式是数据到显示的映射，但我觉得就 CartoCSS 的设计而言，这变换的两端过于异构，还不如看成一种从样式域到图层域的映射，不管是样式、从属样式还是符号都最终映射成图层，这样这些图层的层级关系与样式符号的层级关系同构。

这里要注意：

1. CartoCSS 隐含了对一个样式中同种符号类 (symbolizer) 的合并，所以如果同时写 polygon-fill 和 polygon-opacity 其实是在描述同一个符号
2. 这里的图层是结果的图层，与数据的所谓 “layer” 毫无关系，比如一个选择器选中多个数据 layer ，出来的也只是一个图层

按照这种抽象其实都很好理解了：

样式 = {符号类} + 图层合成策略
符号类 = {符号类属性} + 图层合成策略

从属样式不过是一种制造子样式的方法。

最终绘制的结果取决于符号类属性和图层合成策略，前者决定了被选中的数据如何绘成图层，后者决定了绘成的图层如何与其它图层叠加。

[tumluliu]

@yarray cartocss中的概念体系的确不清晰，缺乏对其中用到的概念、抽象、隐喻以及关系的一个总的介绍，所以后面的内容中就没有个准谱，给人感觉不成系统，很散。这也是我后来决定要补一个原创“概述”的原因，但感觉特别不好写。原因之一是这不但涉及到了CartoCSS中的一些概念，而且还有Mapnik中的一些概念。比如Compositing在Mapnik中就是分为feature-level的和style-level（参考），而在CartoCSS中又被称为symbolizer-level和style-level。它们应该是对应的，但问题是Mapnik里面也有symbolizer，CartoCSS里也有feature，这些东西的含义都应该事先明确。可是作为一本CartoCSS的指南，还是应该把Mapnik的细节隐藏起来好一些，要不就hold不住了，但把握到什么程度也没想好。

样式 = {符号类} + 图层合成策略（策略，操作，还是运算？）
符号类 = {符号类属性} + 图层合成策略

前一个我同意。但在第二个级别上，每个符号也还对应图层么？如果把这里的symbolizer理解成和Mapnik中的feature对应的话，粒度是不是太细了？

另外，CartoCSS既是一套样式描述语言，还有时会指代carto解释器，这个也需要在概述中明确。如果按照解释器理解，carto的作用是将地图样式高级语言翻译成低级语言。你提到的从样式域到图层域，我觉得从结构关系上对应的比较合适，但中间是谁完成的这个映射？也就是“样式域”-->?-->“图层域”，是CartoCSS语言，还是carto解释器？

我觉得翻译的时候越想就越有不清楚的地方。我这现在tilemill和mapbox studio都还编不过，tilemill是因为不支持node 0.12，mbstudio是npm install永远无法正常完成，我还在努力的试。加上整个mapbox都是被墙的，我的梯子又孱弱不堪，经常傻傻分不清楚到底是墙的问题，还是别的问题

[yarray]

@tumluliu 这里的 feature 我觉得也不很妥当，feature 给人一种逐个 feature 的感觉，其实是 feature collection。相应的，不是符号对应图层，是符号的 collection 对应图层，并不过细。举例来说

#building[type="park"] {
  line-color: blue;
  line-width: 0.5;

  polygon-fill: #cccccc;
  polygon-comp-op: screen;

  comp-op: multiply;
}

这个样式对应一个图层，选择器 #building[type="park"] 对应一个 feature collection，设为 D，样式里有两个 symbolizer S_line 和 S_polygon（line symbolizer 包含两个属性，polygon symbolizer 包含一个属性—），所以有两个子图层 L_line 和 L_polygon，分别是由 D 转换成的线符号集合和面符号集合（symbol collection）。可以看到以下一一对应的关系：

D ~ S_line ~ L_line
D ~ S_polygon ~ L_polygon

所以 feature (collection) level 和 symbolizer level 的 comp-op 本质上是一样的，都是 L_line 或者 L_polygon 的 comp-op 方式。

我之前说的样式域到图层域的变换对 CartoCSS 转换成 mapnik 这个步骤毫不关心，CartoCSS 的抽象语言规范规定了样式域的可能结构，carto解释器是个抽象层次不同的东西，在这里没有位置。你的 ? 可以看成抽象的绘制方法，在实现的层次上约等于 carto 解释器 + mapnik 渲染引擎的总和，只是不做最后的叠合。整体可以把 CartoCSS -> 图像的过程看成两段：

没试过编译这俩货…… 印象里依赖非常多……

[tumluliu]

@yarray 图不错，赞一个！idraw还是inkscape？

你看Mapnik里面关于feature-level合成的解释：

Feature-level compositing, during rendering, means that for every geometry processed the multiply operation will be used to blend the rendered pixels of the polygon against the destination pixels (all data previously rendered on the canvas whether from previous layers or just another polygon from the same style). (ref)

所以我觉得，至少是在Mapnik最后绘制的实现层面上，feature-level（或者说symbolizer-level）的comp-op是在绘制每一个feature的时候都要和主画布进行的。与之不同的是，style-level的是先把这个样式块对应的所有feature全绘制在一个临时的画布上，再和主画布进行comp-op。

你的意思我大致明白，把CartoCSS中的每一个

#map_layer[filter="something"] {
  symbolizer-attr: some-value;
  symbolizer-level-comp-op: some-comp-op; /* default is src-over */

  style-level-comp-op: some-comp-op;  /* default is none */
}

这样的样式块都对应一个图层，而这个图层的概念是我们为了便于读者理解CartoCSS的工作过程而提出来的。在CartoCSS、carto解释器和Mapnik的文档中都没有，或者说至少没有强调这个抽象。

如果我的理解没问题的话，那么我个人觉得这样理解是ok的。但是后面问题就来了：要落实到书里啊，要在概述中写出来啊，还得在后面的各章节中强调啊，贯穿全书啊，有木有。这样的工作量投入一本Openbook。。。咱们还是联系人邮社，加入图灵xx系列吧。。XD

[yarray]

@tumluliu 都不是，省事用了 gliffy ...

哦根据这段 mapnik 的文档确实我之前的理解是有问题的，这里 comp-op 算子对 symbol collection 的作用大概类似于一个 reduce 操作了，所以 reduce 的顺序还是由 feature 在数据集中的排序决定的？子图层概念我觉得还是可以用的，无非是从 feature collection / symbol collection 的层面变成了 feature / symbol 的层面，然后 symbolizer 指定 comp-op 其实是应用到每一个 feature 对应的 symbol 了。anyway 我觉得不在图层的抽象下理解 comp-op 几乎不可能清晰…… 而且其它有不少概念比如 attachment 啥的也比较容易在图层概念下理解。

主画布其实是个比较蛋疼的概念，因为总要考虑在画一个东西之前已经画了多少东西上去，但其实不必那么麻烦，comp-op 作为图层算子应该是符合结合律的，所以只要相对顺序不变，概念完全可以按方便对被 comp-op 的单元们进行分组。如果这个算子符合交换律（比如 multiply），那就连顺序都可以怎么方便怎么来了。

工作量确实是个大问题，自己写本书还是算了…… 我觉得理清概念对翻译的主要好处其实是两个：

1. 辨别哪些是翻译能解决的问题，哪些是本身文档写的不好，很难靠翻译解决的问题，对后者不花太多时间纠结词句
2. 对于后者那种情况，可以补充材料或根据我们自己的理解写译者注

[yarray]

@tumluliu 突然发现我犯了个严重的错误，不同 comp-op 算子基本不可能符合结合律…… 那么其实 feature level 的 comp-op 的目标不是主画布而是当前 style 对应的图层画布吧？要不然这时 style level 的 comp-op 还有啥用？

如果是这样那么图层-子图层的 hierarchy 本身没问题，只不过反而变成唯一正确的 hierarchy 了。

[tumluliu]

@yarray 是的，是符合不了结合律的。feature-level的comp-op的目标就是_主画布_，因为默认情况下style-level的comp-op是src-over，也就是什么也不用干，所以不需要创建临时画布。而如果style-level的comp-op被显式定义为其它值，那么此时就会把所有feature先画到一个临时画布上了，画完之后再把临时画布和主画布做comp-op。这些内容都是Mapnik的Compositing文档中介绍的。

• 图层，对应每个样式块
• 子图层，对应每个样式块中的从属样式

这个关系可以接受。但instance又如何正确理解呢，或者说它存在的意义是为了应对哪种case？

关于翻译的计划，我认为我们的想法是一致的，就是以它的文档为蓝本，翻着很痛苦的地方就适当补充。我现在也是这么做的。但有的章节确实hold不住，像4.2配色那节恐怕又得你来了。。。

[tumluliu]

对了，从属样式/子图层之间是不是也可以comp-op？我去，那样的话好像更复杂了，feature级的，attachment级的，还有style级的。。