このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。 この記事は[[H.265]]の記事から派生しているコラム的記事です。 （2009/10/28:追加）動き補償とDCTの併用について追記。 !!!DCT vs DWT 画像・映像の圧縮方式は様々あるが、現代主流の方式はフレームをブロックに分割し、''フーリエ変換の一種、DCT''を使うものだ。 対して、新興の圧縮方式では''ウェーブレット変換の一種、DWT''を使用するものが出てきている。 [[H.265]]の記事にも書いたように、今現在の潮流としてはDCT系のものが有利という評価が多数派だ。 しかし、筆者自身は、''将来的にはDWTが採用されていく''と見ている。 あくまで'''個人的見解'''ではあるが、その理由を書いてみたい。 なお、この記事では''DWTの一般的な特性は解説していない''。 H.265の記事を参照するか、JPEG2000について調べてもらえればわかるだろう。 この記事では、あくまでDWTの将来性のみを''個人的な思いこみ''で語る。 !!要点 DCT＋ブロック分割の技術は、解像度に対するスケーラビリティに劣り、''高解像度環境に適さなくなっていく''と考えられる。ここで言う将来とは10年単位、もしかしたら50年も先の話だ。 解像度（画素数）が上がれば上がるほど、DCT系よりDWT系が有利になっていくだろう。 !!詳細 !計算量 [[H.265]]で64x64のSupermacroblockの追加が検討されたり、x264でb4x4がサポートされずp4x4が評価されないのを見てもわかる通り、''ブロックサイズは解像度に対して適切なサイズが選択されることが重要''で、その絶対的な大きさが重要なのではない。 より高解像度に適するよう''ブロックサイズを大きく取った場合、DCTの特性として計算量が肥大''する。例えば32x32のブロックをDCTにかける場合、そのままDCTをかける場合と16個の8x8ブロックに対してDCTをかけるのでは、アルゴリズム的に10:6の計算量の違いがある。これは''解像度（画素数）が増したこととは別に増加する計算量''である。 また、最適なブロック分割方法を検索するのも大変な話だ。仮にマクロブロックサイズが128x128になった場合、パーティション分割パターンはいったいいくつになるのだろうか。考えたくもないのは間違いない。 一方DWTは、基本的に解像度によってアルゴリズムが左右されない。解像度（画素数）に比例して（正確には線形比例ではなく対数比例だろう）計算量は増えるが、''アルゴリズムの特性による余計な計算量の増加はない''。現在の解像度ではDWTはDCTよりも重い処理であるが、ある点（解像度）からはDWTの方が有利になることも考えられる。 !圧縮のしやすさ DCT系のブロック分割方式では、動き補償のために、参照ブロックからの移動距離を表す''動きベクタ(MV)''を符号化する必要がある。 一般にエントロピー圧縮（CABACやCAVLC）ではゼロに近い値が多いほど圧縮性能（圧縮率）が向上するので、MVも小さいに越したことはない。 しかし高解像度になれば、MVの最大値を大きく取らざるを得ないし、実際''大きなMVが発生する''だろう。 ちょっと想像してみれば分かるが、例えば画面の半分の量だけ横に移動する物体は、320x240なら160px移動するわけだが、1920x1080では960px移動することになる。 これはブロック単位で動き補償を行うDCT系の圧縮技術にとって、''とても非効率''な事象だ。 一方DWT系の技術ではどうなるか。 筆者はDWT系の動き補償処理に詳しいわけではないが、''DWTの特性を活かした動き補償''を''想像''してみたい。 事前知識として、DWTは、基本的に''「多段階の拡大（デコード時）・縮小（エンコード時）」''を行う処理だということを知っていてほしい。例えばDWTのデコード処理は、サムネイル画像を拡大したものに詳細部分を足し、また拡大し詳細を足す、という作業を繰り返すような処理だ。これを知らないと、以下の筆者の想像は理解しづらいだろう。なお、あくまでも'''想像'''なので実際のDWT系コーデックがこのようにしているとは限らないことに注意。 ---- '''＝＝以下、想像＝＝''' DWTのデコード時の動き補償を考えてみる。DWT自体の特徴として、大きさの異なるサムネイル画像のようなものが生成されることが挙げられる。このサムネイルを活用するべきだろう。 ''サムネイルの段階で動き補償''を行えば、画像自体が小さいのと同じであり、MVの値は小さなものになるはずだ。つまり、圧縮効率が良いと考えられる。エンコード時の検索の範囲も、小さなものになるだろう。 MPEG-4 Part2 Video（いわゆるDivXやxvid）で''GMC''(Global Motion Compensation)というのがあったのを覚えている方もいるだろうが、考え方はこれに近い。 ただし、GMCと違って動いてる部分のみを大まかに扱えるので、パンなど画面全体の動きにしか適さなかった''GMCよりも効率が良い''だろう。 DCT系には少しでもMVを省略するための''Direct MB''という機能がある。 しかしこれは特定の近隣ブロックのMVに依存し、それらと同じMVとするもので、そのヒット率は十分とは言えない。''「当たればラッキー」''なレベルのものだ。 それに対し、DWT系の特性を活かした動き補償では、より''「近隣ブロック全体の傾向」を反映''することが可能だろう。 '''＝＝以上、想像＝＝''' ---- この想像が正しいとして、DCT系とDWT系の違いは、やはり高解像度になればなるほど際立ってくる。 なお、上記想像の表記では理解のしやすさのために敢えて省いている部分がある。それらを以下に列挙しておく。 *動き補償は各サムネイルの段階でなされることになると思う。 *動き補償を行う単位は不明。既存は「ブロック」の概念ありき。 **DCTの併用を考えればモジュール流用で4x4,8x8,16x16等に落ち着きそうか。 *各段階で動き補償の対象となるのは、「追加される詳細部分同士」だろう。 **拡大されたコア部分は荒いレベルの動き補償が実施済み。 *各段階では上位のMVを継承し、MV木(tree)ができる。 **MV-treeを上位に辿り(MV-chain)ながら参照範囲を特定する。 *法が2（1段＝2x）のベーシックな考え方なら… *精度はサムネイルレベルでの1pxに対するものになるだろう。 **1px未満の補償はより低位（詳細レベル）で行われるから。 **最終段のみhpel/qpel/hqpel精度になるかもしれない。 *最上位レベルを除き各段階のMVの要素は[-1,0,1]で表される。 **より大きな単位（1px以上）はより上位レベルで補償されるため。 **つまり、MVは2次元なのでx方向2bit、y方向2bit。 ***3x3=9通りに対してxy合計4bit（16通り）は無駄なので何か工夫が必要か。 *画素数と処理量の関係は二次(2D)関数で検索範囲が増えるDCT系より対数的なDWT系が有利か。 !実装の複雑さ 単純な計算量だけの話ではなく、実装の複雑さとしてもDWTが有利だ。 DCT系では実行速度の観点からそれぞれのブロックサイズに個別の処理を書くが、DWTでは汎用的なコードがペナルティなくそのまま使いまわせる。 ''一度書いたコードがほとんどそのまま高解像度に適用できる''と思ってよい。 DCTももちろん様々な工夫である程度共通化はできるし、しているが、DWTの汎用性には敵わない。 DCTではブロックサイズの選択肢が増えればその分判定処理が増え、処理は重く、実装も複雑になるが、DWTではその心配はない。 ''DWTは解像度（画素数）に依存しない、シンプルなソリューション''である。 !DWTの弱点に関して DWT系の圧縮方式は、中程度の圧縮において、''画像の質感に問題がある''と指摘されている。これは解像度（画素数）が解決していくだろう。 先ほども書いたように、DCT系では適切なブロックサイズは解像度に依存する。具体的には、解像度が大きくなれば、より大きなブロックサイズで大まかに扱うほうが、データ量に対する画質が良くなる。これは読み替えれば、''高解像度なら多少の質感を削ったとしても、全体としての画質はよくなる''ということだ。この経験則と読み替えが正しければ、解像度の向上がDWTの弱点を覆い隠すことになる。 今後解像度（画素数）が増加の一途を辿ることは間違いない。そしてある程度画素数の増加が進むと、次に起こるのは''ドットピッチの縮小''だ。 現在、PCでもTVでも、液晶でもブラウン管でも、表示装置のドットピッチは100dpi以下の物が殆どだろう。 単純な画素数が十分なレベル（恐らく3300万画素以上）になれば、精細感を求めて商業印刷レベルの''300dpi程度までは進化する''と思われる。 そしてドットピッチが縮小すると、''視覚のレベルで「画素混合」が起こる''ことになり、人間の目でドットが認識されないようになってくる。そうなれば多少の「のっぺり」感は問題にならなくなってくる。 このように、''解像度（画素数）が上がり、ドットピッチが縮小すればするほど、DCT系よりDWT系が有利になっていく''と、筆者は予測している。 !!組み合わせが最強か？ さらに、DWTとDCTは全く相容れないものではなく、''組み合わせることも可能''だ。具体的には、''大まかにはDWT系で処理し、詳細をDCT系で補完する''方法が良いのではないだろうか。 つまり16x16や8x8のブロック内はDCTで処理し、ブロックのDC成分または1/2・1/4・1/8レベルの縮小画像をDWTにかけるという方式なら、両者の長所を活かせそうだ。 この場合、解像度が増加する分はDWTがスケーラビリティを活かして処理し、詳細部分はDCTが質感を残して処理することになる。 素人の全く当てずっぽうな予測になるが、1/4縮小画像をDWTで処理し16x16ブロックをDCTで処理すると、適度にローパスフィルタが掛かった状態になりデブロックも不要でいいんじゃないかと思える。 DWT側の動き補償（実際の処理方法は知らないが）が上手く効けばDCT側の量子化を余り強くする必要がなくなる、またはかなりの部分がSkip MBになることも期待できるので、RD性能が飛躍的に改善しそうだ。 何れにせよキモはDWTで、DCTは質感を補うための補助になりそうだ。