关于shake软件的色彩空间转换过程中出现的错误的分析
1、在分析这个问题之前首先应该先了解一下当前启用的ITU-R BT.601标准(CCIR601是ITU-R BT.601的前身)。根据ITU-R BT.601标准的建议，其数据范围（动态范围）为 Y（亮度）16~235，C（色度）以 128 为中心代表无色，范围 16~240。（见图1）
2、下面列出的则是CCIR601推荐的rgb转yuv的算式的变形（u、v做了平移）。
Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B+128
V = 0.615R - 0.515G - 0.100B+128
在上面这个公式（不用花太多的纸来计算，网上到处都搜得到）当中可以显而易见的算出，当r、g、b的取值范围是0～255的时候，y的取值范围也是（0～255），U的取值范围是（16.82~239.18），V的取值范围是（-28.8～284.8）。这显然超出了“ITU-R BT.601标准”所规定的范围。
超出了怎么办？截止吗？“CCIR601”和“ITU-R BT.601”都没有允许在软件计算的时候将超出范围的数据截掉，这样会造成不可逆的损失！所以，我们只能有两个选择：
1，严格执行CCIR601的标准，并且保全所有数据，不管他是否超出0～255这个范围。
2，严格执行“ITU-R BT.601标准”，将0～255的Y信号“压缩”到16～235之间。
绝大多数的合成软件在8bit运算的时候取值范围都在0~255,所以第一条肯定无法实现，那就应改执行第二条——将所有的数据“压”到规定范围内！
应该如何“压”呢？稍有数学常识的人都清楚，应该给（Y = 0.299R + 0.587G + 0.114B）这个公式的右侧乘以一个系数：（235-16）/255=0.8588，也就是Y= 0.257R+0.504G+0.098B，别忘了Y的取值底线是16，所以最后Y的公式应该是：Y= 0.257R+0.504G+0.098B+16。同样原理，对U和V也的计算有些麻烦，在U = -0.147R - 0.289G + 0.436B+128这个公式中，当R＝G＝0、B＝255时，U的取值最大，此时U＝238.65，新的U系数为：240/238.65= 1.0068。新的U计算公式为：U=-0.148R-0.291G+0.439B+128，V则要算最小值，要将原来得－28.8的最小取值变成16，新的系数为0.7147。新的V计算公式为：V=0.439R-0.368G-0.071B+128。
最后得出的正确的压缩公式是：
Y= 0.257R+0.504G+0.098B+16
U=-0.148R-0.291G+0.439B+128
V=0.439R-0.368G-0.071B+128
这就是CCIR656所规定的算式，也是目前包括ae等相当多的软硬件支持的算式。
对于CCIR601算式的理解必须是全面的，要用就要完整的用，你不能只用它的算式但又擅自变更甚至截止它的取值范围。这种做法根本就不是什么“严格执行CCIR601公式”。（见图2）
3、正因为shake在8bit和16bit模式下的色彩空间转换错误的理解了CCIR601公式，其结果就是上面这个样子。示波器图形如上。（见图3）
把一个简单的100％彩条转成这个样子，无论如何掩盖也无法回避这的确是shake的一个错误。并且shake的教程中介绍DV抠像技巧的时候用到了这个虑镜，介绍的时候并没有说明——纯红和饱和青色要小心，必须在floit模式下用等等警告。
网友评论