Medium shot (MS) （中景镜头）

中等镜头从腰部向上勾勒出角色，有时也称为腰部拍摄。这是一个通用的镜头。

旨在引导观众对角色和动作的意图，而不是环境。

Medium long shot (MLS) （中远景镜头）

也被称为三分之三镜头，指的是从膝盖向上构造一个角色。这种特定的镜头类型比中景镜头更远并且比远镜头更近，允许多个角色和元素同时在框架内，同时足够接近对话。

Extreme long shot (ELS) / Very long shot (VLS) （超全景镜头）

超极全景镜头，这种类型的镜头用于建立场景，通常是角色或主体可能的地理位置。只要存在足够的视差和低失真，由于视角较大，ELS可能潜在地提供许多可跟踪的特征。

拍摄尺寸（Shot Size）是什么？与运动匹配有啥关系？

表面看起来，镜头尺寸（Shot Size）可能不会影响后期的追踪匹配，就像前文讲过的摄像机运动一样。但它可以为运动匹配（MatchMovement）提供真正有用的数据。

镜头大小决定角色或主体相对于周围环境的大小。

一般情况下，导演/ DOP为场景选择适合的焦距，并将相机地前后移动（物理距离方式），直到达到正确的镜头尺寸。

阿尔弗雷德·希区柯克（Alfred Hitchcock）在他的大多数电影中使用50毫米焦段镜头来拍摄制作电影，以适应焦距。

固定焦距和固定镜头焦段方法的好处是所有镜头的失真、畸变都是一致的，非常利于后期大规模匹配制作。

1、有时由于场景的物…[查看更多]

Stabilised / 稳定器拍摄镜头

通常安装在Steadicam，万向节或两者的组合上或者是当前比较流行的三轴陀螺仪上。 经过稳定处理的摄像机在场景中移动，即使不能去除所有的抖动移动，但能够移除高频移动。

具有线性运动的平滑，稳定的拍摄通常更容易匹配。

Handheld / 手持式镜头

手持设备拍摄就像它听起来一样，相机操作员手持相机通常肩扛或悬挂腋下。 由于没有机械轴向限制，摄像机的运动完全自由。 在Paul Greengrass的电影中可以找到手持相机工作的一些很好的案例。

当尝试匹配手持拍摄时，运动模糊是一个需要处理的难点，也是匹配精确所必备的一个环节，由于其非线性特性，运动也很难预测。

Pan＆Tilt / 双轴同时旋转

这是来自固定点的水平和垂直运动的组合。 镜头可能跟随一个角色，从一个房间的一端走到另一个位置，并在跟拍他们时候，相机既上下旋转同时也做了左右旋转。

Nodal Pan /环拍（环绕被拍摄中心运动）

环拍与标准中心定点拍摄非常相似。 不同之处在于，使用Nodal Pan（环拍）会围绕光学器件（镜头）的入射光中心点进行移动。 这种类型的相机移动可以消除镜头中的视差。

这种类型的移动对于将背景拼接在一起用于VFX镜头，或产生大视角镜头。 过去有时会使用此移动方式来拍摄前景微缩模型。

Nodal Pan /环拍（环绕被拍摄中心运动）的镜头一般很难准确反求出摄像机运动，因为场景几乎没有深度。

Pan / 中心定点旋转拍摄

定点平移拍摄将涉及相机向给定起始位置的右侧或左侧的横向移动。 取决于焦距的选择，会夸大光学器件(镜头)附近和远处的物体的相对位置。

广角镜头会使远处的物体移动缓慢并且看起来很远，长焦镜头会使距离内的物体看起来更近并且看起来更快。

通过良好的Parallax Matchmoving（视差匹配），平移镜头可以相对容易。

在这种拍摄条件下，最重要的参数就是：焦段、焦距。

Static（静止机位）/ Lock off（摄影支架上的所有旋转关节均为锁定🔒状态）

有时被称为锁定的固定镜头，根本没有任何的相机移动。 表面上看，这对Matchmove（运动匹配）来说似乎很容易，因为相机没有运动。但是、在与CG模型或者场景匹配嵌套时候，精确的匹配透视会很棘手，因为我们不知道，场景对应的三维物体的坐标参考。

所以在拍摄静态场景的时候，必须要拍一些倾斜摄影的场景图片，以方便后期反求计算场景参考坐标。

可以使用PFTrack等应用程序准确地消除追踪系统的运算判断工作并准确定位静态相机，虽然相机没有运动，但需要使用多个相机来解算拍摄场景。

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

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

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

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

【图形理论…

[查看更多]

在3DEqualizer中不能生成ST-Map，其配套有一个镜头畸变渲染工具：warp4，在安装根目录下的bin文件夹可以找到，其可以渲染多种模式的镜头畸变处理结果。 一般而言在这里输出矫正过的画面可以在Maya或者Houdini等三维软件中（五镜头畸变环境中）用于检测实景与三维动画之间的匹配精度使用。

在后期合成中，我们往往需要将镜头畸变数据逆变回去，即给制作好三维动画…

[查看更多]

第四步、在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节点上的设置参数如下：（若还步明白，继续补习楼上原理😄）