Nuke 的 intermediate result 与 final result的关系

Intermediate result（中间结果）
显示该节点当前处理阶段的输出，而不是该节点最终完成所有操作后的结果。
在一些多步骤操作（比如某些 GPU 节点、ScanlineRender、深度处理）中，节点可能有多级缓存或分阶段处理，这时 intermediate result 就是未完成计算的版本。
主要用于 调试或性能优化，因为可以更快预览。

Final result（最终结果）
节点完成所有计算、应用全部操作之后的输出。
渲染、合成、导出都会使用 final result，无论你 Viewer 选择 intermediate 还是 final。
最终输出（Write 节点写文件…[查看更多]

可以加呀，keylight本身可以处理，当然也可以在keylight之后使用任何的Nuke节点来进行边缘处理，边缘与背景的反光处理等，都是可以做的，Nuke的最大特点就是灵活，自定义流程。

Shuffle Copy的通道交换细节已经补充到流程里面啦，动手练习，加油⛽️

直接串行连接，在下方顺序添加着走~~，比较简单，针对不复杂得素材有效。再复杂一点点得素材，推荐社区内使用并行连接方式分别提取不同区域遮罩，最后进行合成得过程。

【Nuke抠像】使用keylight与keyer提取美女头发丝【节点图】

楼上正解，是干货，非常棒。在此进一步延伸并做补充：（Nuke，达芬奇默认使用32位浮点计算，且Nuke仅支持32位运算）

许多人曾问我，输出视频、音频的时候，选择什么格式好呢？为什么？

有些作品直接往网上传的建议输出成JPG或者PNG，而需要交给下一个环节处理的，我们仅仅输出LUT或者XML交换文件，或者直接就是工程交互（费劲心思）。那同事们就问，为什么呢？为什么昨天还说需要JPG序列，今天就变成了需要DPX序列，而前天还在需要ApplePress，此刻又需要嵌套工程文件了。

正如这篇文章里所说的编码的问题，在计算机领域永远存在一个问题：精度与容量的矛盾，计算能力与计算时间的矛盾，且这个冲突会一直延续下去，永远是在这两个问题之间寻找平衡，由不同的用途也就出现了不同的格式。

【图形理论…

[查看更多]

第四步、在ramp1、Ramp2节点上输入表达式，使其自动跟随输入视频尺寸，X轴的数值=输入视频的宽度（Width）；Y轴的数值=输入视频的高度（Height）。

在X、Y轴分别输入表达式（可以直接复制）：
Stmap_format.width
curves

同上，在第二个ramp输入表达式（继续复制）：
curves
Stmap_format.height

到此，大功告成啦，随意更改输入端的尺寸，整个节点都会跟随变化，并生成正确尺寸的ST-Map啦～～啧啧，很神奇😄

好啦，今天十七的教程就到这里啦，大家可以尝试一下，按教程的思路做出其他节点之间的交互效果，在此也算抛砖引玉 😄。

如有疑问，可以跟帖留言会尽快回复噢。点击十七的头像可以查看更多精…[查看更多]

第三步、将两个Ramp连接起来，我们就得到ST-Map啦，R通道渐变与G通道渐变后交融的结果：（每一个颜色像素代表一个坐标：X，Y）

红色与绿色交融会产生了二次色（什么是二次色呢？请戳👇这里）：黄色，看起来非常的漂亮，啧啧，实际上这个图片里对应分布存储的是4K大小的文件的坐标信息。

假设这时候，我们连接输入的视频大小变成2k，我们手动更改两个Ramp中的参数为当前视频的宽高即可。

那有没有自动化的方法呢？不管输入的视频尺寸是多大，都会自动跟随当前输入视频的大小自动更改？

答案当然是肯定的，接下来我们开始让其变得“智能化”一些：

第二步、在Constant节点上继续添加一个Ramp（渐变）节点，使用G（绿色）通道来存储Y轴的坐标信息，Ramp节点设置如下：

G通道的Ramp节点设置：

第一步、在Nuke中新建Constant节点，并在下方添加一个Ramp节点用于记录X轴信息，节点图如下：

在Ramp中，我们使用R通道来存储X轴的坐标信息，则在Ramp节点上的设置参数如下：（若还步明白，继续补习楼上原理😄）

原理详解：4K分辨率的St-Map生成，分辨率宽度为 X轴（宽度）：0到4096；Y轴（高度）：0到2160。

色彩的0–1对应的分辨率X，Y：

0是无穷小，1是无穷大，0–1之间的数值可以是无穷的（这点非常非常重要），用颜色信息来存储4K坐标位置，对应实例如下：

色彩变化（每通道）
0
…..
0.5
……
1

分辨率坐标X轴
0
…..
2048
……
4096

分辨率坐标Y轴
0
…..
1080
……
2160

下面我们开始用Nuke来执行以上原理：