[请教]DVDRIP的较色问题

在用AVIUtl进行DVDRIP制作的时候,在进阶调色里有一个 电视 -> 电脑 的选项
就是否要勾这个我和细细吵了好长时间,也没得出结论[/KH]
请教一下,是否有必要勾上这个捏?

为了搞清这个问题，重新看了大神bible的视频知识系列，看到中间忽然瞬间醒悟，实际可以用一种非常简单的想法去考虑，被自己越搞越复杂了。

再看silky这句话：
"MS MPEG-4 Codec，DivX Codec，XviD Codec 这几个 Codec 都是假设收到的数据是0~255，会先做 Y/C 压缩的动作。"

还有这两句：
“...Y/C 伸张，也就是将 Y/C 的动态由原来的16~235 扩展到 0~255，然后转为 RGB 0~255”
“...Y/C 压缩，把目前 RGB 0~255 的数据压缩为 16~235，然后转为 YCbCr 16~235”

可能我断章取义了，不过这样比较容易解决问题。只要简单理解为：

只认为RGB(模拟)<->YUV(数字)转换的时候才有伸张和压缩问题（转换RGB(a)到YCbCr(d)只存在YC压缩问题，转换YCbCr(d)到RGB(a)只存在YC伸张问题），就够解决所有事情了。

这样想的话，当输出给XVID编码的是YUY2或YV12的时候，根本不存在RGB->YUV的转换，不可能有YC压缩的动作，所以实际上是自己误解了大神的话，这句话本身就是说RGB的，因为只有RGB才认为存在RGB->YCbCr的YC压缩，YCbCr不管转什么，或者什么也不转，都不认为它有YC压缩和伸张问题。RGB(0-255)->RGB(16-235)即使看着数字是压缩了，也不认为是YC压缩。

比如说RGB(0-255)->PC2TV->RGB(16-235)->YUV(16-235)这个过程，RGB(0-255)->PC2TV->RGB(16-235)仅仅作为转换过程的一部分去理解，RGB(0-255)->YUV(0-255)->PC2TV->YUV(16-235)整个过程才理解为YC压缩，这样事情就简单化了。

“转换至内部YCbCr时，y从1-254转换至-256－4445，uv从1-254转换至cbcr -2341－2633，这样的话yuy2读入，y由16-235转换至内部0-4095，uv从16-240转换至内部 -2048－2047，但是rgb却不同，rgb读入时是0-255，但是转换完成后却同样是0－4095和 -2048－2047”

这段话的意思再想一下，可以这样理解。

aviutl将YUY2和RGB转换至内部YUV48时，分别使用了两套转换公式，也即YUY2<->YUV48和RGB<->YUV48,因为没有RGB和YUV之间转换的问题，所以认为根本不存在伸张和压缩，只有不同的转换公式，也即：

读入时：
YUY2->YUV48(y=16-235,uv=16-240到y＝0-4095，cbcr＝-2048－2047)
RGB->YUV48(rgb=0-255到y＝0-4095，cbcr＝-2048－2047)

YUY2(16-235,16-240)和RGB(16-255)转换出来的结果一样，YUY2相对于转换出相同结果的RGB是相对伸张关系，RGB相对于转换出相同结果的YUY2是相对压缩关系，但同样作为输入端的二者之间没有绝对的伸张和压缩关系。但是：

M2V以RGB直接转换读入(16-235)->YUV48->逆转换到RGB(16-235)->XVID编码做YC压缩(因为收到的是RGB，所以存在YC压缩问题)

这样的话，最早由M2V读入的RGB和最后XVID压出来的YUV就有了YC压缩的关系，在这个例子里就造成错误。所以可以简单地去理解为：前提是DVD的源的时候，最后送给XVID的只要是RGB信号，中间任何过程中的伸张和压缩抵消后就必须是伸张一次；最后送给XVID的只要是YV12或者YUY2信号，中间所有过程的伸张和压缩就必须全部抵消。

预览时可能有两种情况：
YUV48->RGB逆转换(y＝0-4095，cbcr＝-2048－2047到rgb=0-255)->GDI
或：
YUV48->YUY2逆转换(y＝0-4095，cbcr＝-2048－2047到y=16-235,uv=16-240)->DirectDraw YUY2 Overlay

但是2ch那篇帖子，是说走GDI而非Overlay；滤镜作者的帖子也有说，YUY2读入要看到完全实际播放的情况，还要单开Overlay看，因为aviutl自己做的YUV48->RGB转换和Overlay还是略有不同；另外我的想法，aviutl里面是可以任意切的，切完的东西不只是非MOD32，单数双数什么都可能，Overlay应该没法适应，所以综合来看，预览画面走GDI的可能性大。（可能一般软件的预览都是这样吧，我不是理论强人，这个不清楚了）

输出时：
YUV48->不选YUY2压缩->RGB逆转换(y＝0-4095，cbcr＝-2048－2047到rgb=0-255)->XVID编码同时做YC压缩(因为给编码的是RGB，所以才存在YC压缩问题)

YUV48->选择YUY2压缩->YUY2逆转换(y＝0-4095，cbcr＝-2048－2047到y=16-235,uv=16-240)->XVID编码直接输出，不做YC压缩(因为给编码的是YUY2，认为根本不存在YC压缩问题)

当使用YUY2 filter mode时，如果要把转换理解为不同的两个转换式，那么内部空间就必须是YUY2（模拟），否则RGB读入时应该是压缩了，RGB输出时应该是再伸张回去了。

也许实际就是这么简单，也许是我这么去理解而变得简单了，今天就理解到这一步，如果有新的理解，再说。

这次回的比较长，分两个帖子写。

上网查了一下，发现这个话题以前有过类似的讨论，看了以后更明白了一点，但是也可以说更不明白了一些，因为似乎存在两种观点，第一种观点来自2ch上的一篇老帖（其中有junmperさん参与），第二种观点是一个au滤镜作者写的，两种说法有一定差别，目前很难断定哪种更有说服力。

第一种观点（2ch老帖）

讨论中有人做了一个试验，用0.16.235.255的bmp图在Premiere导入，然后分别用DivX，huffyuv，canopusDV三种编码输出avi

huffyuv DivX的情况：
压缩为avi时
RGB0-255->codec内部YUY16-235压缩->YUY16-235范围的AVI
AviUtl读入时
YUY读入: YUY16-235->以YUY16-235范围传递给AviUtl->AviUtl来做RGB0-255伸张的画面
RGB读入: YUY16-235->codec做RGB0-255伸张->直接输出RGB0-255的画面

canopusDVcodec的情况：
压缩为avi时
RGB0-255->直接转换至YUY0-255->YUY0-255范围的AVI
AviUtl读入时
YUY读入: YUY0-255->以YUY0-255范围传递给AviUtl->AviUtl来做RGB0以下，255以上的过度伸张画面
RGB读入: YUY0-255->直接转换RGB0-255->直接输出RGB0-255的画面

因为canopusDVcodec本身实际要求的源是RGB16-235，符合这个标准的话：
压缩为avi时
RGB16-235->直接转换至YUY16-235->YUY16-235范围的AVI
AviUtl读入时
YUY读入: YUY16-235->以YUY16-235范围传递给AviUtl->AviUtl来做RGB0-255的伸张画面
RGB读入: YUY16-235->直接转换RGB16-235->直接输出RGB16-235的画面

以下为猜想

因为是这样的结果，或许可以猜想M2V直接转换是类似于canopusDVcodec（解码不自动伸张），而D2V类似于DivX（解码自动伸张），两者性质不同，即：

M2V以直接转换RGB读入(16-235)->以YUY16-235范围传递给AviUtl->直接输出RGB16-235的画面->压缩为mpeg4时yc再压缩（错误）

M2V以601转换RGB读入(0-255)->以YUY0-255范围传递给AviUtl->直接输出RGB0-255的画面->压缩为mpeg4时yc压缩（正确）

D2V以RGB读入(解码伸张至0-255)->以YUY0-255范围传递给AviUtl->直接输出RGB0-255的画面->压缩为mpeg4时yc压缩（正确）

因此66的观点按这个解释是正确的。

但是也有问题存在，后面又有人指出预览画面和内部YUV并不同，所以具体是否如猜想，并不明确。

其中有人说到：

YUY2展开、压缩设定的意思是：
选中：由Aviutl来做压缩和伸张
不选：有codec按该codec内部规定的计算式来做RGB<->YUV转换（某些编码存在压缩和伸张问题）

又有人翻出以前的aviutl的log来：

输入输出由codec完成转换的时候（不选YUY2展开、压缩），输入输出为RGB
输入输出经过VFAPI的时候，输入输出为RGB
输入输出为RGB时，RGB24<>YUV的转换由aviutl来进行，RGB<>YUV时会产生误差不用说，数据精度还会由于运算过程而降低
早期的一部分内建滤镜（扩张色调补正？）是以RGB24来处理的

输入输出由Aviutl完成转换的时候（选YUY2展开、压缩），输入输出为YUY2
输入输出经过.aui的时候，输入输出为YUY2
输入输出为YUY2的时候，YUY2->YUV48的mapping由Aviutl来做，没有色彩变换误差，但是YUV48->YUY2 mapping的时候，数据精度会由于运算过程而降低
YUY2展开、压缩时，早期的一部分内建滤镜（扩张色调补正？）仍然是以RGB24来处理的

Aviutl的YUY2 filter mode，内部色彩空间变为YUY2，输入输出情况仍然遵从原来的默认空间情况

这两段比较有意思。

仔细想了一下，66是有道理的，不过有些问题按照这个道理还是不明：

[M2V vfp 直接变换解出的是] RGB(-1) [不伸張]--> YUV(-1)--> [AviUtl 的視窗顯示的是] RGB(-1)

[M2V vfp 601解出的是] RGB(0) [YC 伸張]--> YUV(0)--> [AviUtl 的視窗顯示的是] RGB(0)

如果这样的话，由于au的D2V reader读入时是RGB，但实际上不管之前选pc scale还是tv scale做出来的d2v，结果完全一样，都是显示RGB(0)，这样的话，d2v reader读入时到底做了什么？忽略pc和tv一律不伸张，还是忽略pc和tv一律伸张？如果按上面M2V的情况，就是应该一律伸张。否则不能显示RGB(0)。但实际上d2v reader有没有这样做？是第一个不明。

另一方面来说，au存在yuy2 filter mode，在这个模式中读入，和在默认模式中读入所见到的预览完全一样。这样的话只能是：

[D2V reader解出的是] RGB(0) [YC 伸張]-->YUY2(0)--> [AviUtl 的視窗顯示的是] RGB(0)

压缩时：

[D2V reader解出的是] RGB(0) [YC 伸張]-->YUY2(0)-->YC压缩(自动做)-->YUY2滤镜处理-->YUY2(-1)

或者是压缩时：

[D2V reader解出的是] RGB(0) [YC 伸張]-->YUY2(0)-->YUY2滤镜处理-->YC压缩(自动做)-->YUY2(-1)

既然YUY2模式的意义是kenkun开始尝试全过程YUY2处理，那么为什么要做不符合601的YUY2空间，增加中间的转换过程？

或者是这样的：

遇到任何RGB(0)自动YC压缩-->YUY2(-1)-->YUY2滤镜处理-->YUY2(-1)

还是非常诡异，但最可能的情况还是只存在YUY2(-1)，因为kenkun最可能希望的情况应该是：

YUY2读入[YUY2(-1)]-->YUY2(-1)空间-->YUY2滤镜处理-->YUY2(-1)输出

那么怎样解释这个时候的预览图？既然这个时候预览仍然显示RBG(0)，那么就必须在滤镜处理后对处理结果做伸张然后显示出来。

这样的话，又和你说的情况，即读入0，显示0，读入-1，显示-1不同，也就是说kenkun需要对两个模式的预览做两个流程，这种情况让人很在意，觉得奇怪。这是第二个不明。

预览的过程：
DVD2AVI读入plugin解出的是RGB(-1)-->YUV(-1)-->滤镜处理-->AviUtl 的視窗顯示的是YC伸張到RGB(0)[伸张仅仅用于显示]

压缩的过程：
DVD2AVI读入plugin解出的是RGB(-1)-->YUV(-1)-->滤镜处理-->YUV(-1)[既无伸张也无压缩]

压缩的信号并非预览信号做yc压缩，这个过程是不存在的。只要是预览正确的，就正确了，没有其他那么多理由。au的d2v读入plugin是rgb，但是为了适应au的色空间肯定要转，m2v有yuy2的问题，也一样要转到au的色空间。

@ 紧箍咒
你說的是這篇嗎?還是看原文的吧...
貼圖的後3張和前2張對比有明顯的stairs..
http://jumper-x.hp.infoseek.co.jp/study/6/index.html
另外引用Silky的話
"MS MPEG-4 Codec，DivX Codec，XviD Codec 这几个 Codec 都是假设收到的数据是0~255，会先做 Y/C 压缩的动作。"

YUV(-1) 代表 Y: 16~235, UV: 16~240
YUV(0) 代表經過 YC 伸張 Y: 0~255, UV: 0~255
RGB(0) 代表 RGB: 0~255，在電腦上看，要顯示 RGB(0) 才是正常的顏色
RGB(-1) 代表 RGB: 16~235，經過壓縮後的 RGB

[DVD2AVI 解出的是] YUV(-1) [YC 伸張]--> YUV(0)--> [AviUtl 的視窗顯示的是] RGB(0) [壓縮前先經過 RGB 壓縮]--> RGB(-1) [然後]--> YUV(-1)

播放 YUV(-1) [顯示卡的色空間轉換或 MS MPEG4 Codec 都會做 PC Scale]--> YUV(0)--> RGB(0) 顯示正常

如果不做 ITU-R BT.601 補正
[DVD2AVI 解出的是] YUV(-1)--> [AviUtl 的視窗顯示的是] RGB(-1) [壓縮前先經過 RGB 壓縮]--> RGB(-2) [然後]--> YUV(-2)

則播放的時候 YUV(-2)--> YUV(-1)--> RGB(-1) 顯示錯誤

所以可以再補一次 ITU-R BT.601 補正 救回來
[做錯的] YUV(-2) [MS MPEG4 Codec 伸張]--> YUV(-1)--> [AviUtl 的視窗顯示的是] RGB(-1) [再伸張一次]--> RGB(0) [喔喔，正常了] [壓縮前先經過 RGB 壓縮]--> RGB(-1) [然後]--> YUV(-1)

有没有一种方法使读入后即不伸张也不压缩，呈现MPEG2中颜色的本来面貌？

引用

最初由 tct66 发布
（M2V -> RGB 時選 BT.601 Range 伸張一次
AviUtl 電視->電腦色調 修正又伸張一次
or
D2V -> RGB 時選 PC Scale 伸張一次
AviUtl 電視->電腦色調 修正又伸張一次
這樣會做二次 YC 伸張，都是錯誤的做法）

这句话你确实没说是谁做错了，我误会你了。

是啊，任何时候读入正确但是用滤镜做tv->pc都是错误的，但是选601和选pc scale然后rgb入都没错。

就象我前帖说的，以vfp读入的情况选601正确，而选full还要做伸张才行。aui读入完全无关，而tv scale和pc scale对于aviutl来说，直接读入d2v的结果几乎完全一样，它是根本不管你选什么scale的。

再说说你贴图的问题

你可能对au不够了解，au的“rgb”和“预览画面”都是模拟伸张后的，因为要让你看到放出来的大致样子，不要被骗了，选601才是正确的，601是伸张，但是是相对于“full range”的伸张，这个full range不是真的“直接转换”，而是yc压缩。

从你这个图来讲，rgb表示出的情况在模拟伸张后应该是0-255，而16-235是yc压缩的画面在模拟伸张后的情况，这个值是让你知道最终压好后的片子在播放时的情况，而不是目前的情况，这个值和内部的yc实际是不同的。实际上日本人对这个问题早在几年前就有过试验证明。

这个设定实际是au人性化的一个缩影，它就是让你所见即所得，有据可循，如果错误地理解了，反倒糟了。