fireattack

非sRGB色彩空间图像的问题和处理

先来一些非常粗略的背景介绍。尽量保证没有大的概念上的错误，不过依然仅供辅助阅读，详情请自行查阅资料。

我们知道计算机图像是通过量化模拟信号的方式，来用一组数字（比特）来保存实际的颜色。最常见的24位色图，即使用RGB三个通道每通道各256种不同的颜色（256=2^8，即8位）来保存每个pixel的颜色。

但是计算机图像是无法涵盖眼睛能识别到所有颜色的，所以“色彩空间”这个概念就描述了在某个标准下，每个通道从0到255这256^3种组合（假设8bit/ch）所能涵盖的色域。色彩空间的标准有很多，其中最常见、也是最通用的就是sRGB。不过由于sRGB涵盖的色彩空间很局限，所有有很多其他标准流行，其中摄影、美工界用的最广的应该是Adobe RGB (1998)这个标准。

Source: Wikipedia

上面这张图对比了两者涵盖范围的区别。背景的马蹄形是所谓的CIE1931色彩空间，大致是人眼能识别到所有颜色。（注意：很显然这张图本身是sRGB的，外加显示器显示能力的限制，这张图上的颜色是不可能准确的，仅仅是示意图而已。）

我们这里姑且不论Adobe RGB比sRGB广、导致部分颜色用sRGB完全无法表达的问题，更重要的是对于两者都涵盖的同样的一个颜色（感官颜色），其对应的R/G/B数值是并不相同的。

（题外话：因为Adobe RGB色域比sRGB广，我们可以看到如果用同样的位深，Adobe RGB会更容易出现banding——因为相邻两个数值之间的颜色“距离”更大。这也是为什么经常会配合更高位深譬如16bit/ch使用的缘故之一。）

譬如下面两张图：

如果你的浏览器设置正常（现在主流浏览器默认应该都对ICC有支持），应该是呈现一样的颜色；但是其图像文件的pixel的RGB数值并不相同，分别是175,20,67（Adobe RGB）以及205,12,66（sRGB）（这里的数值是指文件内部的真实数值——不要用截图取色来比较（Photoshop等专业软件里取色则可以））。如果硬要把其中之一的数值用另外一个色彩空间来显示，颜色自然就不对。因为sRGB一般是默认值，所以常见的问题是一个Adobe RGB图像，由于丢失了ICC，会依然按照175,20,67的数值、但是在sRGB色彩空间里来找对应的颜色来显示，那么就变成了下面这样：

aRGB_wrong
“Adobe RGB” w/o ICC

了解了这一点，我们就很好说明现在常见的一个问题是什么了。

如上所说，现在工业界无论是摄影还是美工，前期编辑、处理一般都用Adobe RGB 来进行。一般而言，在最终出图尤其是网络用图时，最兼容的方法应该是全部转换成sRGB。虽然会因此损失一些色域，但是要知道现在大部分用户的显示器根本没有显示sRGB以外色域的能力，外加软件兼容性的一团乱麻，所以即使提供了也大抵是白费功夫（当然，这点应该会逐渐改变）。

即使是要用Adobe RGB来出图，那最低限度也应该提供正确的embedded ICC profile。否则，谁知道你这图是什么色彩空间？只会fallback到默认的sRGB去。举个实际例子的话： 

不幸的事实是，网站上、尤其是日本网站上大量存在AdobeRGB直接抹去ICC变sRGB的现象。举最明显的例子的话，iTunes提供的几乎所有封面图都有这个问题。可以对比iTunes提供的僵尸色（左）和索尼提供的正确颜色（右）：

   

由于对这个问题关注已久，我几乎已经练就了不需要对比，仅仅看图片的饱和度多寡就可以看出这图是不是Adobe RGB硬抹掉ICC变sRGB的本领（苦笑）。我们来道练习题——虽然Sony家一般官网的图大多是对的，但是也有出岔子的时候——下面这个截图里哪些CD封面颜色是对的，哪些不对？

zaa.png

（答案：『365×LOVE』和『トクベツいちばん!!』的正确，其他错误。）

上面说到如果有正确的embed ICC profile，那会好不少，首先至少网页里会显示正确。可惜，大部分软件对于ICC的支持还极其有限。最简单的例子，本地的图片浏览器我用的ACDSee的quickview查看器就完全不支持ICC，完整版部分支持（根据我观察，好像JPG内嵌支持但是PNG内嵌ICC不支持，很迷）；XnView那边，是需要开启一个选项即可。另外，如果直接复制图片到QQ里，也会导致ICC丢失。

不过移动端的OS由于封闭性较强，倒是支持的程度好一些，不少看图软件的支持度都还可以。我顺便试了下把有ICC的AdobeRGB图嵌入到音频文件里放手机播放（我用的比较多的一个使用场景），Google Play Music和BubbleUPnP都能正常显示，Foobar2000倒是败了。

对于一个已经丢掉ICC的Adobe RGB图，可以使用一些常见的元数据工具（ICC profile应该是在XMP里描述）来无损（不二次压缩）地把ICC嵌回去。如果不在乎无损或者反正还要进行其他处理，则可以直接用PS处理：打开图片后，先“指定配置文件”为Adobe RGB (1998)，再（可选步骤）“转换为配置文件…”成sRGB即可。

 

另外，这个问题绝不仅限于Adobe RGB：比如现在的iOS，无论是拍照还是截图，都会使用非sRGB色彩空间（Display P3？）；所以所有的图都会有类似的问题。这也是为什么大多数iOS用户发到QQ里的截图都看起来饱和度很低的缘故。

CMYK也一样——稍微好点（？）的是CMYK直接强制丢掉ICC会出现极为可怕的效果，所以一般人还能察觉并纠正（即使如此，在日本网站上并不罕见……一个范例 ）。相比之下Adobe RGB的问题就在于，和正确的颜色差别不大，很多人可能受害多年但是从未发现。

不过，CMYK有个独有的问题是，由于CMYK有四个通道，所以强制转换之后会经常出现K通道直接彻底丢失的问题。这样基本没可能再准确还原原来的色彩。我个人制作了一个PS action来还原这种图——对于K通道，我采用的方式是强制把图转换一次CMYK来单独提取K通道复制回来，这样至少比较接近。

另外，由于CMYK的色域比RGB还小，所以一个图哪怕是正确地转换成CMYK，饱和度也会有下降，在一些比较鲜艳的图里很明显。不过和Adobe RGB丢失ICC那种感觉还不同，因为不会丢失太多明度，只是不那么饱和而已：

（上图都是我模拟的，为了保证显示效果一致，最后又都转回了sRGB。注意最后那个鬼畜的颜色。）

 

说了这么多，最后反正还是得一边骂一边天天手动改专辑封面颜色（

fireattack

杂记两则：YouTube直播多摄像头和Tumblr吐槽

没什么关系的两个topic，只是发现好久没写blog了随便记记。

YouTube直播多摄像头

工作原因需要搞一个小网站，要用摄像头直播某个工作区域。本来是想正儿八经的在web server搞，结果搜了下php+win平台几乎完全找不到轮子可以用。那能想到的自然是用YouTube直播然后iframe嵌进去了：虽然有点延迟，但是对即时性要求不高。

YouTube直播非常简单，可以用OBS之类的软件上传，甚至直接打开 https://www.youtube.com/webcam 调用摄像头直播。账号方面倒是要注意权限够直播外加够启用embedded直播，这俩是分开的权限；我本来不想用个人账号，但是开的小号就没有第二个选项，嵌入到别的网页里是无法工作的（而且我甚至不知道后者怎么获得……大号反正有）。

为了懒省事，一开始没有选择用OBS，而直接用网页那个。后来需求增加到三个摄像头，也如法炮制开三个/webcam（里面可以选设备）。然后嵌入三个iframe到网页中。

这里遇到俩问题：第一个是如果其中一个摄像头被占用，那个webcam直播的网页会提示摄像头被占用从而开不起第二个直播（明明还有设备两个空闲！）。这个我小弟给搞定了，所以细节不详。

但是第二个问题就比较严重：一旦开启了2个摄像头之后，第三个就怎么都没有画面。

经过一番搜索，发现原因可能是因为三个摄像头满分辨率直播的情况下，带宽太大，USB bus无法承载。但是YouTube自带的那个webcam功能自然很薄弱，无法设置分辨率。

既然如此，我们就只能上OBS了。在OBS里可以设置每个捕捉设备的分辨率（如果全都用默认果然还是有问题，我索性全改成了240p），然后你甚至可以把三个画面同时显示在一起，这样也不用开三个直播流了，听上去很完美。

结果一实践就发现了问题。原来，使用encoder（至少OBS是这样）上传的情况下，不管你实际是什么视频比例，都会被YouTube加黑边强制转换成16：9；这里可以通过观看Live->右键查看视频详细信息确认：

QQ图片20190213200629

而且Y2B另外一个地方可以看到我确实是1080×1920的流传到YouTube的：

2

在我的需求下，这三个视频是需要做到竖排成9:16的竖屏形状放在网页的一侧的。YouTube这么加了pillarbox的黑边之后，画面变成横向宽屏；iframe嵌入到一个纵向区域里就会缩到中间一条，又加上上下的letterbox黑边，整个实际可视范围就只有中心的一小坨了。

顺便一提，如果用/webcam直播则没有这个强制比例的问题：虽然不能调整分辨率，但是会使用webcam的原生分辨率（有几个比较老的是4:3），而不会强行变16:9。

经过四处搜索（其实几乎搜不到什么东西），这个问题确实存在，而且无解（理论上有这个：用event setup muliple cameras，但是我试了下似乎根本没法）。

那么接下来能想到的几个办法：

  1. 开3个encoder直播（这样我可以在网页里从上到下排开三个iframe）：YouTube不支持；
  2. 一个用webcam直播，两个左右并排的用OBS直播，然后把俩iframe叠起来。这个实践成功了，但是由于两种办法的处理速度有时间差，导致视频不in sync，不行。

最后想到一个笨方法：还是那个横屏有黑边的视频流，在iframe外面套一个div开启overflow: hidden;，然后通过调整iframe的左margin为负数加指定宽高，来强制把黑边溢出到不可见的范围内，从而实现了视频可以无黑边充满一个纵向区域的目的。

试了下确实好使……嗯唯一的小毛病是YouTube工具栏一部分就挡住了，但是够用了（至少播放键在中间能点到，233！）。

Tumblr的吐槽

除了一直用Tumblr发扫图之外，还开了个小号记录一些TrySail的信息归档用。说是归档，就是看到一些第三方发的链接或者照片（尤其是后者）复制一份发进去以后好找（官方的就不记录了）。一直以来都是用电脑投链接，昨天用手机app发了一条，发现两者怎么长得不一样？

3
在主页面的效果
4
在Archive页面的效果

尝试一下编辑…结果发现电脑上直接无法编辑App的投稿：

5

如果用开发者工具模拟成手机网页版，倒是能编辑，不过是HTML源代码：

6

（Tumblr发帖很自由基本可以用各种HTML代码。从这里看出其实就是系统自动给你套了个模板。）

用App编辑网页版发的Link帖倒是可以，不过UI和编辑App版发的贴有明显区别：

网页版发的帖
App发的帖

网上搜下也有人抱怨，说是强行push用户用App；我倒是觉得只是Tumblr的技术力太弱智了而已……

fireattack

Epson V370和V550的简单对比

上一台扫描仪（V370）虽然扫描的分辨率方面毫无问题，但是种种毛病，终于忍无可忍，买了台refurbished的V550。

先说下上一台的具体问题…

1：扫描有色带，中间区域偏黄，这个最不能忍，扫描浅色的东西非常明显：

color banding

（此图是扫两次拼成。可以看到在上下传过身体处各有一道非常明显的黄色色带。如果看不出来你的显示器也该换了w）

2：某个像素点（扫出来就是一列）会无故偶尔坏掉呈现粉色或者绿色。重启几次就能修复，不知道为什么。

3：各种奇怪的机械故障，比如扫到最后一点就卡住、发出巨大噪音等等。

上手V550之后，首先是自然是调整配置，这里有必要先提一下我之前的配置和我个人的一些看法。

扫描仪个人用配置

我扫三次元图时，颜色方面一般色阶砍到22-239，保证留有足够的余地进行进一步编辑（即保证所有常见印刷材料不会clip color/过爆的问题），也不会有明显的黑位白位问题（即颜色没有伸张开），偷懒的时候甚至可以直出而不用后期二次调整。曲线方面我稍微加了点亮度（调整曲线上秃一点点）。Epson这个扫描软件极其弱智的一点是不同扫描仪的设置是不通用的，连导出都不能，我只能凭感觉拉曲线了，不能保证和老的完全一致（也没必要就是了……强迫症）。

后处理方面，其实这是个philosophy的问题了。对于大量色块的二次元图，处理确实可以很aggressive，但是对于相机拍出来的图我是持保留态度的。很显然，用常见的去噪滤镜（比如教程里经常看到的Noiseware——当然这个滤镜的质量本身还是很高的）多轰几遍，再拉曲线拉到稍微过爆，哪出来的效果自然是好——和开了美图秀秀似的，但是损失掉的细节呢？经过多次取舍，我个人的倾向还是把滤镜开到最低限度，尤其是缩图之后有点噪点反而很有“feel”。

我原来甚至是完全零filter党的——即关闭所有扫描仪软件带的后处理。但是后来扫太多真的懒，而且三次元图我也没有什么非常想认真处理的欲望，干脆直接开去网纹轰算了（选“常规”，其他的效果极差，还不如不开）。不过，这个去网纹对于锐度损失太大（对于文字之类的高DPI印刷的部分影响尤其大），我一般是配合USM（unsharpen masking，一种常见的锐化滤镜，具体算法请参见DIP教科书）开到最大（高），基本能维持一个和什么都不开类似的锐度（稍微有点haloing，但是能忍）。

最后的问题就是DPI了。我个人觉得300dpi对于绝大多数印刷物就够了，再多真的是数screening；但是这里有个技术问题：扫描仪使用低DPI模式高速扫描时，光学精度会很低，在某些screening比较粗犷的情况下甚至会出现摩尔纹！因此，直接扫300DPI的效果远差于扫高DPI然后用高质量算法缩图的效果（当然也要慢很多）。

在使用老的V370的时候，我发现一个很有趣的trick：如果开启了“去网纹”，无论你使用什么DPI，实质都是用一个很高（~600左右？）的DPI进行的光学扫描（从扫描速度就可以明显看出），然后后处理之后再由扫描仪软件缩成你想要的DPI出图。这么设定可能是因为其去网纹算法仅能工作在慢速模式？无论如何，这对于我的需求这简直是天作之合：我并不想在电脑里存大量的高DPI图，所以这样相当于一键实现了高DPI扫图+缩图了。所以，我一直使用这种办法扫了蛮多图。

对比：硬件篇

V550的硬件布局首先就和V370区别很大。大家都知道的双灯管就不提了（还加了一层半透明材料使得光线更柔和），门变成了从后方开启而不是右侧，这显然是个Plus。但是，扫描的范围变成右上角对齐——这个我个人觉得有点烦。因为保证少出血，我一边是不顶边扫图的——而是会把传感器无法识别的最边上2mm左右预留出来。改在右上角之后就很难看清到底在对齐哪里了。对于非拆扫尤其不方便。

另外由于方向的问题（从里向外扫），不盖盖子扫非常刺眼。我现在暂时侧着放感受一下方便与否。

对比：软件篇

前面我提到过的那个trick——开了去网纹之后自动变成实质高DPI扫描——这里也好使，但是阈值提升了：经过简单的测试，用400DPI和600DPI扫图时间基本一致，但是300DPI则快很多（低精度扫描）。也就是说，如果你用300dpi+去网纹+USM，出来的效果会很差：主要表现在锐度低上。

这里有个时间对比：

V370
去网纹+USM+300：36.60s
去网纹+USM+600：36.15s

V550
去网纹+USM+300：16.48s
去网纹+USM+400：53.88s
去网纹+USM+600：53.81s

可以明显看出V370在300/600的实际扫描速度是一样的，同理400/600于V550（300则不同）。

所以，如果要用V550进行这一套tricky的操作，只要使用400dpi及其以上的分辨率扫描即可（补充：后来经过测试，应该是只要大于340dpi就会使用“慢速扫描”）。

至于效果，下面有三张图对比（统一缩成300dpi+然后再NN放大到200%便于对比）。注意字体的锐度。

  • V370 300DPI
  • V550 300DPI
  • V550 400DPI

在同样的高分情况下，降噪的结果其实差不多，V550的降噪力度更轻一些，在某些地方比如纯色区域还是挺明显。

其他方面，两者的镜头畸变有肉眼可见的区别（图像比例），但是很难讲哪个更好了。颜色则是V550要偏红一点，gamma=0.95基本可以调整到和V370一样的感觉。个人觉得V370的稍微好些（我比较倾向于冷色调），但也不会专门去调整到和V370的一样就是了。

fireattack

一张主力光驱无法复制的DVD

尝试性地长话短说……因为这事儿我没啥定论。

今天在rip刚买的azusa Music Video & Live DVD ~visuel~ #1这套碟，就像往常一样打开DVD Decrypter，但是发现每次拷贝到VTS_01_1.vob这个文件就会报错“L-EC Uncorrectable Error”。

QQ截图20180920000816

试了下其他几个别人推荐的软件，无论是MakeMKV、ImgBurn（不带破解功能但是能复制）还是ISOBurster，全都一样，而且错误都一样，我怀疑他们底层用的是同一套lib/code。

换了DISC2，发现也是一样，在VTS_01_1.vob处报错。

播放倒是都没问题，但是不太能说明什么，毕竟我没有完整播放测试，而且播放的容错本来就比clone要relax许多。

难道是光驱坏了？我把老的USB DVD only的光驱翻出来，果然没问题。

但是，我还是很难相信刚买的光驱就会坏，而且之前抓别的碟明明OK的。我不死心，先升级了下固件（1.50->1.51），但是还是没用。那么，我先用USB光驱慢慢地复制着DISC1的ISO（USB光驱速度很慢，只有2x左右），然后找了久仰大名的DVDFab来试试另外一张碟。这软件是收费的，可以试用三次。

DVDFab果然厉害，无论是全盘内容复制、还是克隆ISO都成功。但是我对比了下用备用光驱和DVDFab抓取的版本，发现一个奇怪的现象。

首先得说说这碟，本身结构就很奇怪。其实际体积只有4G左右，但是如果你打开VIDEO_TS，里面的VTS系列文件居然有从01到11整整11组，每个体积都是整个碟的体积，如果你解压，居然会出来40多G的文件，可想而知，这每个VTS的内容都是重复的。

QQ图片20180920001505

自然，这些文件并不都是有效的，估计是使用了类似symbolic link的东西，亦或DVD的文件结构（我们知道是UDF）本来就和windows不怎么兼容才映射出这种奇怪的样子（同样的、但是没这么严重的现象之前也发现过就是）。那么DVDFab的做法呢？被DVDFab提取出来的ISO长这样：

QQ截图20180920001831

可以看到，只有一个VTS组被保留了，其他都被“废掉”了。如果你试图播放，是不会有任何问题的，但是我觉得DVDFab也是会自行对IFO进行修改来保证这点的。

从这个角度来说，DVDFab读取出来的版本虽然并不和原版一致，但是等效——可以认为是一个“脱水版”。

有趣的是，如果你用MakeMKV去读DVDFab制作出来ISO，会有个警告：

QQ截图20180920002127

但是点掉之后还是可以用。MakeMKV然后提取到的Title也有点区别，比起原版镜像/物理碟少了一个，但是那个Title是一个长度1分钟、完全黑屏的奇怪玩意，所以其实也没什么卵用。[见更新]

那么问题来了：DVDFab为啥会对这镜像进行这套奇怪的操作呢？有两个可能：和这套碟的特殊文件结构有关，也就是前面提到的“脱水”；2：和我光驱无法正常读取那些文件有关，换句话说那些文件也许就是无法正常读取，所以DVDFab比较鲁棒地无视了罢了。

如果是前者，可能这套文件结构也是导致我的蓝光光驱无法正确clone的罪魁祸首？如果是后者，那使用DVDFab+我的备用光驱，会产生出怎样的镜像？可惜，我在测试过程中已经用尽了3次copy的试用，这软件的UI的愚蠢程度也让我很难有再去想办法绕过trial限制去测试的欲望。所以既然我们最终也相对无损地抓到了碟，那么就这样算了吧。

最后不得不提个很蛋疼的问题：在我折腾了半天之后，现在我的蓝光光驱读碟的状态卡住了根本不更新了（容量，卷标，etc.）：

QQ图片20180920003324

还好重启电脑+读了另外一张碟后，恢复了。

关于DVD本身：

Azusa是我非常喜欢的一位Anison歌手，可惜早早隐退。这张DVD收录了应该是所有的MV外加一场Live，也算是Azusa最后的波纹了，只要3000多日元可以说是非常超值了。不过值得一提的是，Live那场里的「告白」不知道为什么不是现场收声版而是替换了CD音源（Amazon评论也有人提到），这点有点遗憾。可能是现场收音出了什么事故造成的。

 

更新：今天发现DVDFab（+主力光驱）克隆出来的ISO果然有问题：除了上述的黑屏title没了之外，还少了一个隐藏的title（是DVD的彩蛋——MV的making，在azusa的blog有提到。根据BK上的提示，要在菜单处输入密码“usagi”进入，但是我用PC播放完全不知道如何输入，试了好几个播放器都不行）。所以果然MakeMKV的警告不是吓唬我的！（见下图，1是那个全黑屏的title，倒数第二个就是彩蛋了。）

未标题-1

另外这里最后一个title，这个虽然没被DVDFab破坏，但是这个title（是Azusa的简单talk，介绍了下碟子的内容）正常播放时我也不知道怎么进！DVD的文件结构真的是个玄学…

哦说是还有另外一个彩蛋是什么“スペシャル音源”，要输入“azmix”，我也不知道是在DISC 1还是2，反正我没找到就是了（或者是找到了没认出来）。

但是同时又发现另外一个蛋疼的问题……用DVD Decrypter+旧光驱抓出来的ISO直接虚拟光驱加载播放会有杂音（就好像没有破解一样）。用MakeMKV抓内容倒是没问题。

fireattack

DVD视频模式详解+微型数据库

介于之前多次研究过DVD的多个方面，FPS啊、AR啊等等，而且情况非常混乱，所以想建立一个数据库，呃其实就是个table，来收集一下各个厂商的DVD制作情况。说是数据库可能有点夸张了，无非就是把自己收过DVDISO的那些情况描述下搞个spreadsheet罢了。

在建立过程中，发现关于DVD的视频模式得先说清楚一点，否则自己都老搞糊涂。

日本的DVD都是NTSC格式，也就是说帧率都是29.97，这点是不会变。但是之前多次提到，有些DVD会直接塞进所谓的“film”——即23.976帧率的progressive视频，然后使用soft-telecine（所谓soft，就是不动视频流只加个flag，让播放器自行telecine）的方式来伪装成NTSC/29.97。对于这种，我们压制或者说播放的时候自然应该还原成其本来的面貌。播放方面，我试了下，主流播放器都不会有问题，实际的播放帧率都是23.976，也就是说不会去尝试soft-telecine；压制方面自然是当做progressive来搞，不额外加滤镜。

对于真·29.97的视频（DGIndex称之为“video”），有多种情况：

  1. 逐行（progressive）；
  2. 交错（interlaced）；
  3. Film telecine上去的，5烂2
  4. Film插帧上去的，逐行但是每5帧有一帧重复

标准的处理方式是1不处理、2进行deinterlace（保持帧率不变或者倍帧）、3进行IVTC（帧率变为4/5，即23.976）、4进行1-in-5的decimate。

顺便一提，handbrake并没有decimate滤镜，但是可以用强制指定CFR=23.976的方式来实现。其算法在改进一次之后比较智能，降FPS时会自动选取重复帧删除。

一般而言，判断视频到底是哪种类型，有很多种方式。我个人一般使用如下流程：

先直接pot播放DVD，要开启pot内置滤镜（这样才能看到真实FPS），这样可以很容易看出soft-telecine或者说film的部分——因为FPS不是~30而是~24。

QQ截图20180916002656.png

第二步我一般用megui的AVS script creator。这个工具有个挺厉害的功能，是deinterlacing自动analyse（在第二选项卡）。使用的方法是heuristic的（根据帧画面判断），基本上是非常准确的。另外，利用AVS script creator带的预览，可以自己逐帧观看，也能手动很方便地区分这四者（完全无交错就是progressive，每5帧固定烂2帧的是telecine，其他一动起来就交错的则是一般的interlaced）。

但是这里有个问题一定要注意——我被坑过一次。对于大多数DVD，不同的视频模式是不会混在同一个title的——比如音雨旗下的mocho、nansu的单曲的DVD，一般都是title0是MV、film，title1是CM、hard-telecined的模式。用megui的AVS script creator预览这俩title，会分别得出source type：“progressive”和“film”[*]的结果（准确地说，后者其实是“partially film”，因为过场logo等部分不是），自己逐帧拉，也是一样。

但是，有些很少见的DVD，会把两种视频模式混合在一起。这里的例子就是TS的一专《Sail Canvas》的DVD了——这个DVD上来是MV，然后是一个20分钟的特典（各种making），但是两者是在同一个title里的。而且，两者使用了不同的模式：MV部分是23.976的film，making部分则是29.97的progressive。对于这种混合film和NTSC的视频，AVS script creator的识别是有bug的——他会把前面的MV部分按照soft-telecine后的结果来取帧（而不是取原始帧画面），结果就得出这部分是“film”的结论，如果你手动拉帧，也会看到不该存在的交错：

QQ截图20180916004256.png

其实这个BUG的原因也很简单了。megui是调用DGIndex来索引DVD视频的，而DGIndex在检测到film超过95%的情况下，会自动启用“force film”flag（也就是d2v里的Field_Operation=1，详细说明），来按照23.976生成d2v文件：

DGIndexProjectFile16
1
D:\PUMPKIN_MEAT_PIE\VIDEO_TS\PUMPKIN_MEAT_PIE_VTS_01_1_1.VOB

Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=720x480
Field_Operation=1
Frame_Rate=23976 (24000/1001)
Location=0,0,0,22290

但是如果像这个例子一样两种混合在一起，那就达不到95%了，结果则会按照“Honor Pulldown Flags”（Field_Operation=0）加Frame_Rate=29970来处理，所以23.976的部分会被soft-telecine到29.97。如果手动运行DGIndex，并选择“Ignore Pulldown Flags”，则可以看到Raw的帧画面，规避这一问题（不过选择了“Ignore Pulldown Flags”仅仅是不会Pulldown而已，film的部分还是会以29.97的速度加速播放）：

QQ图片20180916010459.png

其他的解决方法有：

  • 把视频先用makemkv做成MKV，然后再用AVS script creator（用FFMSIndex或者L-SMASH都无所谓）读取，他们不像DGIndex，完全不会搞什么Soft-telecine。如果全部一起压制的话，推荐转换成VFR视频（或者分割成多段CFR视频）。
  • 或者直接VOB用Pot播放，但是在LAV那边强制输出progressive tag（并且关掉Pot的内置滤镜防止他自作多情反交错，因为据我所知Pot才不管你upstream的tag是啥都会进行反交错），然后肉眼逐帧收货即可。

既然说到DGIndex就提一下，他这里面的判断还是比较阳春的，就是根据MPEG stream里的flag判断而已，比如有pulldown flag的部分就会识别成film/progressive，否则就会识别成video/interlaced，不管实际是真的interlaced还是hard-telecined、还是progressive，和megui里那个根据画面来analyse的不同。

[*] 专门提一下film这个词，在DGIndex里和本文里说的“film”，是指这视频是按film（23.976+progressive）存储（否则叫“video”）；但是在megui的analyse那边，如果出来的结果是“film”，那是指你这视频本来应该是film、但是已经hard-telecined了，所以要IVTC。这俩概念可别混淆了。DGIndex语境那个film在megui的analyse这边出的结果会是“progressive”（嗯，因为他是根据画面来检测的，所以无论是23.976的还是29.97的都会出progressive的结果）。

把这几个概念厘清了，我们可以做表格了。几种视频模式的名称，我用了以下方案：

  1. Film
  2. NTSC/p
  3. NTSC/i
  4. NTSC/t
  5. NTSC/p (dupe f)

NTSC的部分是强调是标准NTSC视频（29.97），和Film视频区分，斜杠后面的则是画面分析出的结果（而不是靠metadata识别）。

完整注释版的话大概应该是这样，表格里肯定不会写这么长，但是就当解释用了：

  1. Film，23.976+pulldown (soft-telecine) flag
  2. NTSC/Progressive，29.97（源为逐行video）
  3. NTSC/Interlaced，29.97（源为隔行video）
  4. NTSC/Hard-telecined，29.97（源为film，telecine）
  5. NTSC/Progressive with duplicate frames，29.97（源为film，插帧）

数据库

所谓的数据库，就是这个目前只有十几条的表格啦XD

https://docs.google.com/spreadsheets/d/1q0hOFMl_D7MGVmh2yjCmg-wEGS_2teLx3xGKCcnuwaE/edit?usp=sharing

也加了一些不是DVD的，比如我发现mora的视频都是插帧插出来的……直接用23.976 fps不好吗。