| Y；輝度 | ここからRGB信号（光の３原色）を復元する。 |
| Cb；色差 (U) Blue - Y | |
| Cr；色差 (V) Red - Y |
復元はTVのお仕事。てゆうかブラウン管の蛍光体にYUV信号あてて出るのがRGB（光の３原色）だったような、、、。
TV電波がRGBを使わないのは、Y,Cb,Crのほうが電波の節約になるから。
で、人間の目は色の変化よりも明るさの変化に敏感という特徴があるので、UとVは少し「省略」してもあまり見た目が変わらない。
YUV 4:4:4とかYUV4:2:0とか言うのは、UとVをどのくらい省略してあるかの比率を示している。
TVとDVDはYUV4:2:0。なので、このYUV4:2:0フォーマットが大概のソフトの基盤になっている。
例えばx264cliは自前のデコーダを持たないので、素のままでは無圧縮YUV4:2:0しか受け付けない。
このYUV4:2:0はインターレース信号との絡みで容易に理解しにくいので、YUV 4:4:4から順に説明を試みる。
SDTV（720x480）の場合。
YUV 4:4:4
Y,Cb,Crは全画素とも1ピクセルずつ持っている。データ量が大きいわりに画質が良くない。
医療とかデジタルシネマのカメラとかのスゴい世界で使う(H.264/AVCではFRExtが対応)。
図では輝度と色差をレイヤーっぽく描いてみたが、こういう図は見かけないのでなにかマズいかも。
YUV 4:2:2
TV局とかで使う。
図では画面の大きさが同じだが、Cb,Crは同じ大きさの画面を目の粗い方眼紙で区切る、みたいな感じ。
Cb,Crのピクセルは横幅がYのピクセルの２倍。Yから見ると２ピクセルでCb,Crの値を共用。
(これもH.264/AVCでは要FRExt)。
YUV 4:1:1
DVカメラ/キャプチャが使う。
cb,crはそれぞれ360x240。Yから見ると４ピクセルがCb,Crを共用。
拡大すっとたぶんこんな感じ。
Yの値４個あたりCb一個、Crも一個。色情報はこのくらい削ってもDVなみの画質になるわけだ。
cb,crはそれぞれ360x240。Yから見ると４ピクセルがCb,Crを共用。
拡大すっとたぶんこんな感じ。
|
|
|
YUV 4:2:0
cb,crはそれぞれ360x240。DVと同
じだがインターレース用であるらしく、ちょいと厄介だ。
・http://e-words.jp/w/YUV420.htmlに よると、
・『改訂版 H.264/AVC 教科書』から理解できた範囲では、
上図のように輝度と色差信号をレイヤーっぽい理解ではマズい印象がある。
・MEncoder Documentsの説明では、走査線が図になっている。
続いてインターレースド。
これでフィールドを合成すると、こうなる。
これでCb,Crは実は別レイヤーにあるんだよと言う事なら、ほぼYUV4:1:1と等価になる。
実際YUV4:1:1とYUV4:2:0はどっちも1ピクセル当たり12ビットのデータ量になるので、ひとまとめにYUV12とも呼ばれる。
ほぼ等価、というのは、上段のL,Cbと下段のL,Crの間には時間軸上で1フィールド分のズレ（約６０分の１秒、0.0166...sec）があるか ら。
となると、MPEG2キャプチャとDVキャプチャでは別のインタレ解除フィルタを使うべき？
・http://e-words.jp/w/YUV420.htmlに よると、
2x2の4画素の最初のラインの2ピクセルからU（Cb）成分を1サンプル、次のラインの2 ピクセルからV(Cr)成 分を1サンプル採る方式。
・『改訂版 H.264/AVC 教科書』から理解できた範囲では、
フィールド信号の切り替えタイミングは不規則に変わるようなので、Crが奇数・Cbが偶数と決まっているわけでもないだろう。輝度の走査線の間にCb,Cr信号が挿入される。 奇数ラインに挿入されたCrは次の偶数ラインでも使われる。 偶数ラインに挿入されたCbは次の奇数ラインでも使われる。 その結果、輝度信号と色差信号の位置は一致しない。
上図のように輝度と色差信号をレイヤーっぽい理解ではマズい印象がある。
・MEncoder Documentsの説明では、走査線が図になっている。
クロップの注意事項から抜粋。
まず、ノンインターレース。
まず、ノンインターレース。
通常のYUVフォーマット,4:2:0は、色差情報を、 サブサンプリングされた形で保存しています。これは、色差情報は輝度（強度）情報の半分しかサンプリングされて無いという事です。次の図を見て下さい。L はluma(輝度)、Cはchroma(彩度・色差)です。このCがCbなのかCrなのかまでは書いてない。まさかフレーム単位でCbとCrが交互配置ぢゃねーだろーな。
ご覧のように、映像の横行と縦列はペアになっています。ですから、クロップする際には開始位置と縦横の数値は、偶 数でなければなりません。 もし奇数にした場合は色差情報がきちんと輝度情報にマッチしなくなってしまいます。理論上は、クロップの開始位置を奇数値にする事は可能ですが、この場 合、輝度情報のリサンプリングが必要になるので潜在的に画質劣化の危険があります。また、cropフィルタはこれをサポートしていません。
L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L
続いてインターレースド。
次に、インターレースド映像は下図のようにサンプリングされています。これは、こういう意味なんじゃないだろうか。
ご覧のように、パターンは４行単位です。ですからインターレースド映像をクロップする場合、y-offset とクロップ範囲の高さは4の倍数でなければなりません。
Top field Bottom field L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L
| Top field | Bottom field | ||||||||
|
|
||||||||
| L | L |
| Cb/Cr | |
| L | L |
実際YUV4:1:1とYUV4:2:0はどっちも1ピクセル当たり12ビットのデータ量になるので、ひとまとめにYUV12とも呼ばれる。
ほぼ等価、というのは、上段のL,Cbと下段のL,Crの間には時間軸上で1フィールド分のズレ（約６０分の１秒、0.0166...sec）があるか ら。
となると、MPEG2キャプチャとDVキャプチャでは別のインタレ解除フィルタを使うべき？
余談
ややこしさの原因は、
白黒放送のスキマにカラー信号をなんとかねじ込んだってあたりのようだ。
ついでにその時に30.000fpsが29.970fpsにもなっている。
厳密には30000/1001≒29.97002997003って感じなんで、何分かおきに「うるうフレーム(フィールド？)」みたいのがあるらしい。
TVのカラー化ってすっげぇ作業だったんだなぁ。いや難儀だども。
なお、パソコンのディスプレイはRGB形式なので、DVDだろうがTVキャプチャだろうが、画面に出る前にどっかでYUV-RGB変換が入っている。
さらに、YUVとRGBでは表現できる色の幅（カラースペースとか色空間とか言う）が地味に違う。映像ソフトはプロ用でも注意しないと内部的にYUVか RGBかどっちかしか扱えなかったりして要注意とAppleのサイトにあった。素材がYUVならYUVを扱えるソフトでワークフローを組まなきゃいかん よ、と。
さらにさらに、当たり前だが印刷屋さんが使うCYMKともカラースペースは違う。
まとめて面倒見てくれるColorSyncが便利な気もするし、パソコンで扱うデータはほとんどモニタに映すのだからとRGBに特化したWinの方が実は 楽そうな気もする。
そんなわけで自分は色調整は一切やらないのであった。この方面は自分には地雷すぎる。
、、、ま、イロイロですな（自信満々）。
白黒映画が圧縮しにくい件。
xvidもx264もchroma_meみたいな名前のオプションがある。Motion Estimation（動き予測）に色差（彩度）情報を援用して精度を向上させるものだ（これ抜きだと輝度情報しか使わない）。
グレイスケール・エンコードでは完全に色味が変わってしまう事から、Cb,Crも入っている事は確実だが、どうも見やすさの為に一律に着色してあるっぽ い。従って色差信号を動き予測に使ってもあまり役に立たない。
なので、白黒が縮まない理由は、
と、なると、ビットレートを上げるより、時間を差し出して輝度成分の動き予測を厳しくするほうが効果がある鴨。
ついでにその時に30.000fpsが29.970fpsにもなっている。
厳密には30000/1001≒29.97002997003って感じなんで、何分かおきに「うるうフレーム(フィールド？)」みたいのがあるらしい。
TVのカラー化ってすっげぇ作業だったんだなぁ。いや難儀だども。
なお、パソコンのディスプレイはRGB形式なので、DVDだろうがTVキャプチャだろうが、画面に出る前にどっかでYUV-RGB変換が入っている。
さらに、YUVとRGBでは表現できる色の幅（カラースペースとか色空間とか言う）が地味に違う。映像ソフトはプロ用でも注意しないと内部的にYUVか RGBかどっちかしか扱えなかったりして要注意とAppleのサイトにあった。素材がYUVならYUVを扱えるソフトでワークフローを組まなきゃいかん よ、と。
さらにさらに、当たり前だが印刷屋さんが使うCYMKともカラースペースは違う。
まとめて面倒見てくれるColorSyncが便利な気もするし、パソコンで扱うデータはほとんどモニタに映すのだからとRGBに特化したWinの方が実は 楽そうな気もする。
そんなわけで自分は色調整は一切やらないのであった。この方面は自分には地雷すぎる。
、、、ま、イロイロですな（自信満々）。
白黒映画が圧縮しにくい件。
xvidもx264もchroma_meみたいな名前のオプションがある。Motion Estimation（動き予測）に色差（彩度）情報を援用して精度を向上させるものだ（これ抜きだと輝度情報しか使わない）。
グレイスケール・エンコードでは完全に色味が変わってしまう事から、Cb,Crも入っている事は確実だが、どうも見やすさの為に一律に着色してあるっぽ い。従って色差信号を動き予測に使ってもあまり役に立たない。
なので、白黒が縮まない理由は、
- 動き予測の精度がカラーより低い（YUVそれぞれが256段階あるとして、Cb,Crが殆ど動き予測の役に立たない）
- フィルム傷、ノイズが酷いものが多い。
- 出来上がりも、カラーならRGBそれぞれ256レベルがあるので目立たないアラが、輝度256段階オンリーでは目に留まりやす い。
と、なると、ビットレートを上げるより、時間を差し出して輝度成分の動き予測を厳しくするほうが効果がある鴨。
