因为上次有关色彩的那篇帖子，我自己用一些方法对现在有的一些视频文件进行了一些实验。。。。
不知道有多少人会如我这样子。。。。总之我是很不能忍了。。。
注：最简单的解决办法见第二页第一楼。。。。
虽然其实这也是暴风这类播放器的默认设置。
但是对于完美解码，还有MPC这类一开始选择的是VMR渲染器的播放器来说，需要把设置改回Overlay Mixer。但是后果是会丧失截图功能这些。。。。可以参考MPC输出设置的描述。。。。
我们都知道计算机显示系统中色彩的表达是通过RGB三原色的数值来描述的。0,0,0就是纯黑，而255,255,255则是白色。首先呢，我们不考虑三个数值。我们只考虑一个灰度数值。那么我们可以说我们的屏幕的 色彩动态范围 是0-255。
在标准的电视广播中，所使用并非也是RGB数值进行视频传输。原因是RGB三个值比较分散，无法进行有效的压缩，并且占用太大的带宽。因为这个原因，广播上使用的是YCbCr的色彩编码。Y是亮度信息，而Cb和Cr则负责表现色彩。因为人眼对亮度最敏感，所以这个模式比较的有效。
但是问题就有了，我们从TV或HDTV的信号源获得的片源，是不是也是全动态范围的呢？本质来说，YCbCr实际上是一个将RGB模型的色彩立方体做了等比例旋转以后得到的。但是实际上，TV和HDTV的信号源，因为首要考虑的是电视这种放映设备。对于本来的CRT来说，电子枪扫描模式的色彩范围并非是能达到0-255这样的动态范围的。因此，实际广播的信号的动态范围，是缩小的。现在的广播标准中，主要有两大YCbCr的色彩模型标准，分别称为ITU-R BT.601和ITU-R BT.709。前者主要应用于标准电视信号传输。后者则多用于HDTV等现代播放设备。这两者的区别在于YCbCr与RGB的转换公式中的两个参数Kr和Kb的定义不同，以及定义了不同的Scaling。具体来说呢，电视的动态范围并非是如我们显示器这样的0-255。ITU-R BT.601中定义的模拟量的是[0;1]范围，Y在[0;1]中，Cb和Cr在[-0.5;0.5]。在数字化的标准中，这个范围被定义了一定的headroom和footroom，即RGB输入是{0,1,2,...,255}，Y的范围是{16,17,...,235}，Cb和Cr的范围是{16,17,...,240}。ITU-R BT.709也有这个headroom和footroom。对染601和709的YCbCr到RGB是有不同的推算公式的，但是色彩的区别这个公式并非是最主要的。色彩的转换是解码器和渲染设备共同定义的。放在我们平常的时候，就是我们使用的解码器和渲染器两个项目对画面的色彩有作用。
这个问题稍微复杂，原因是不同的渲染器，不同的解码器都有可能对颜色做不同的处理。目前来看，Windows上两大主流渲染器，系统默认的VR(Video Render)和另一个常用VMR(Video Mixing Render)要求的输入数值是不同的。VR的输入范围是16-235，而VMR则使用0-255。如果片源是16-235，在VR上看色彩是正常的，但是在VMR上看色彩就会发灰。另一方面，解码器也会有相关的色彩输出控制选项。CoreAVC可以根据流的标签自动检测是不是全色彩范围的视频，如果是，那么就用0-255作为输入范围，输出范围则是根据使用的渲染器，VMR用0-255，VR或者其他使用16-235。然后根据这两个范围确定如何映射色彩空间。因此，相对来说CoreAVC的色彩会鲜艳一些。而RMVB就稍微倒霉。由于解码器不会进行这样的处理，由于大部分源的动态范围是16-235，RMVB如果输出到VMR上，那么色彩就会变灰。因此相同的源，似乎VR是一个不错的选择，在各个不同的来源上都会有比较准确的色彩表现。但是会丧失VMR提供的更方便的功能。而另一方面，片源的色彩输入也不见得是100%完全符合标准的。某些片源的色彩动态是10-230。这样的输入范围如果按照16-235来输入，会有clipping出现。这对于色彩表现是很不应该的。
怎么解释上面这些呢？在比较好的条件下，我们可以认为，电视上的纯黑和纯白，与我们在显示器上看到的在视觉上是一样的。但是，这看起来相同的黑白，在数字描述的时候却是不同的。电视上的纯黑是16，纯白是235。而我们的显示器，则是0和255。这意味着，如果我们把电视上看起来是纯黑和纯白的物体拿到显示器上看，我们实际上看不到显示器应该表现出的纯黑和纯白。造成了视觉上差距。这就是为何相同的视频，电视上和电脑上看起来也不一样。就算是都用电脑播放。
那么我们希望，我们能在电脑的屏幕上看到电视的效果，就需要将这个差距通过映射解决，即，我们将电视的16-235的色彩动态，均衡映射到0-255的范围。不过由于色彩表现无法使用浮点，换句话说也是离散的，因此其实会有一些颜色缺失。但是至少，我们看到的颜色是与电视上看到的具有相同的视觉感觉。
下面是动态范围的一个区别。。。
比较的分别是16,16,16和0,0,0的黑，以及235,235,235和255,255,255的白。如果在你的显示器上可以明显看出区别。。。那么恭喜，我们都被蒙在鼓里很久了。。。
下面是些截图。我通过自定义Filter Graph，在输出端和解码器间插入了一个ffdshow raw video filter，借以观察Histogram。使用的是VMR，截图的右边经过了手动的动态范围控制和映射。。。不同动态范围的片源，区别很明显，有的时候甚至有点致命。。。
使用的实验Filter Graph。大致都相同，只是使用不同的解码器和文件源。视频输出及截图来源统一VMR9，所有视频只处理右边一半。左边未经色彩映射处理。色彩控制和Histogram视觉化使用ffdShow raw video filter。由于使用了自定义的Filter Graph，因此才可以对RMVB进行色彩调整。
1.INDEX 第七话。片源HDTV+x264，MKV。使用解码器CoreAVC，输入输出检测关闭（其实是设成Autodetect但是在Filter Graph中未起作用。选择了输入输出均为TV的模式，不在CoreAVC中进行色彩映射）。
Histogram，动态下限判定：
Histogram，动态上限判定：
截图：
2.空之境界第二话，片源DVDRIP+x264，MKV，使用解码器CoreAVC，设定如上。
Histogram，动态下限判定：
Histogram，动态上限判定：
截图：
3.Kannagi 07，片源TV+RMVB，分离器使用MPC RealMedia Splitter。
Histogram，动态下限判定：
Histogram，动态上限判定：
截图：
目前绝大多数的动画片源的色彩范围是16-235。原因和采集的信号显然是有关系的。并且为了后期处理方便，一般不会在片源处进行色彩映射，而是保留原本的动态范围。但是，这个范围对于片源是可变的。因此，很多时候，虽然用VR更方便，但是VR本身无法控制的色彩映射可能会使原本的视频出现clipping。因为如果动态范围有变化，话都不说就只把16-235映射到0-255会出现些问题。。。
对于RMVB来说，目前如果单纯使用播放器，是无法进行色彩控制的。而对于H264，XVID这类片源，则需要考虑解码器设置和渲染器的选择。VR模式下我无法截图，但是从个人感官上来看，VR渲染的换面明显偏亮。估计与其映射算法有关系。感觉不如通过手动调整得到的映射更加精确。
不过无论如何，我还是觉得。。。好可怕啊。居然看了这么久色彩完全不对的动画。。。
这不是屏幕的问题，而是输入输出，数值转换的问题了。。。
