(57)【特許請求の範囲】
【請求項１】
色サンプリングレートが輝度サンプリングレートの半分のビデオ・ピクチャーのビデオ圧縮方法において、
ビデオ・ピクチャーの輝度の動きを表す輝度動きベクトル及び色動きベクトルを推定し、
前記推定された色動きベクトルについて切り捨て又は切り上げの丸めを選択的に行い、
前記輝度動きベクトルに、前記丸めの切り捨て又は切り上げの決定を表す付加的ビットを付加した、動きベクトル処理を含むビデオ圧縮方法。
【請求項２】
請求項１に記載のビデオ圧縮方法において、
色動きベクトルが輝度動きベクトルの分割によって２つに分割され、その分割に続いて、もし丸め決定が必要ならば、輝度動きベクトルの付加ビットのディジタル値に応答してその決定がなされる、動きベクトル処理を含むビデオ圧縮方法。
【請求項３】
請求項１又は２に記載のビデオ圧縮方法において、
前記丸め決定が、輝度及び色エラーの自乗の和を含む動きベクトル推定の平均自乗エラーに基いてなされる、動きベクトル処理を含むビデオ圧縮方法。
【請求項４】
請求項１，２又は３の何れか１つに記載のビデオ圧縮法において、
前記輝度動きベクトルが、そのディジタル値が水平方向の丸めを表す１つの付加ビットを含む、動きベクトル処理を含むビデオ圧縮方法。
【請求項５】
請求項１，２又は３の何れか１つに記載のビデオ圧縮方法において、
前記輝度動きベクトルが、そのディジタル値が垂直方向の丸めを表す１つの付加ビットを含む、動きベクトル処理を含むビデオ圧縮方法。
【請求項６】
請求項１，２又は３の何れか１つに記載のビデオ圧縮方法において、
前記輝度動きベクトルが、夫々のディジタル値が水平及び垂直方向の両方の丸めを表す第１及び第２の付加ビットを含む、動きベクトル処理を含むビデオ圧縮方法。
【請求項７】
前記請求項の何れか１つに説明された方法で動作するビデオ圧縮装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ビデオ圧縮方法及び装置に関し、特に、動きベクトル圧縮技術と関連するビデオ圧縮方法及び装置に関する。
【０００２】
【発明が解決しようとする課題】
ＭＰＥＧとして知られている１つのディジタル圧縮標準は、国際標準機関（ＩＳＯ）のMotion Picture Expart Group(動画エクスパート  グループ）によって提唱され、それにちなんで命名されたものである。
【０００３】
ＭＰＥＧ１として知られている一つの形において、ドラフトされた初期の版では、１つのビデオ信号の過去と現在のフレームの間の順方向予測を用いていた。ＭＰＥＧ１の後の形であり、ＭＰＥＧ２として知られたものにおいては、この標準は付加的に、双方向予測を使っている。即ち、順方向及び逆方向予測フレームの平均として作られた予測と順方向及び逆方向予測の結合を用いている。
【０００４】
動き補償を使うことは、ＭＰＥＧ符号化の重要な観点である。動き補償は、フレーム間の動きに対する補償を行うことによって異なったフレームのエラー信号を最小化することをもくろんでいる。
【０００５】
この動き補償のプロセスは下記の２つの別々のプロセスを含んでいる。
（ｉ）フレーム対の間の動きオフセットが計算される動きベクトル推定（ＭＶＥ）を行う。
（ii）ＭＶＥ計算の結果を用いて最小の人為作業で異なった信号を作る。
【０００６】
下記のような考慮すべき、ＭＶＥ及びＭＶＣの幾つかの観点がある。
（ｉ）許されている動きの種類。ＭＰＥＧ及び他の同様のシステムにおいては、動きの種類は従来のＸ及びＹ軸におけるベクトルに限られている。他の分野の研究者は、回転、スキュー及びサイズ等の他の種類の動きを使ってきた。
【０００７】
この作業の利点は、明らかでない。なぜならば、もっと複雑な形の比較によれば異なったピクチャーにおける信号を減らすことができるが、形パラメータを送信するためにもっとデータを要求する。
【０００８】
（ii）マクロブロックのサイズは、より良い符号化効率であるが高いマクロブロック・データレートを有する小さなブロックと、符号化効率は悪いが低いマクロブロック・データレートを有するより大きなブロックの間の妥協点である（ここで、マクロブロックは、動き推定及び補償のために使われるブロックサイズである）。
【０００９】
(iii）輝度（Ｙ）及び色（Ｃ）ブロック整合の結果を如何にして結合するか。Ｙ及びＣ動きベクトルに完全に別々のベクトルが使われていれば、マクロブロック・データレートは２倍となり、Ｙ及びＣベクトルの整合の悪さによって、画像が乱れる可能性がある。Ｙ及びＣベクトルを結合すれば、低いマクロブロック・データレートが得られるが、符号化効率が若干落ちるかもしれない。
【００１０】
（iv）サブシステム推定及び補償の使用。しばしば、フレーム間の動きは、整数ピクセル距離には現われないので、ある種の型のサブピクセルＭＶＥ及びＭＶＣは有益であろう。送信又は受信されるために、もっと多くのベクトルデータが発生され、そのデータの増加は非常に小さいが、簡単なハーフピクセル推定がピクセル基準の推定器の計算パワーを少なくとも４倍要求し、これが考慮されなければならない。
【００１１】
６４５Ｋｂｐｓから２Ｍｂｐｓの領域における低いビットレートのシステムを強調した、動き補償符号化における更なる発展が必要である。
【００１２】
【課題を解決するための手段】
多くの動き補償予測システムは、動きベクトル発生及び補償に対して輝度情報のみを使用している。しかし、実例として、動きの詳細の多くが色データにあるピクチャーがある。
【００１３】
そのような実例においては、輝度信号と色信号に対して別々の動きベクトルが計算される。もし、輝度と色ピクセルレートが同じであれば、輝度と色信号の両方に対して単一動きベクトルを計算するようにすることができる。しかし、色ピクセルレートは、水平及び垂直軸において輝度レートの半分である。
【００１４】
本発明によれば、動きベクトル処理を含むビデオ圧縮方法が準備されている。そこでは、色サンプリングレートが輝度サンプリングレートの半分であり、ビデオ・ピクチャーの輝度の動きを表す輝度動きベクトルを推定すること、対応する色動きベクトルについて丸め決定を選択的に行うこと、輝度動きベクトルに付加的ビットを含めること、付加ビットのディジタル値が丸め決定を表していること、を含む。
【００１５】
色動きベクトルが輝度動きベクトルの分割によって２つに分割され、その分割に続いて、もし丸め決定が必要ならば、輝度動きベクトルの付加ビットのディジタル値に応答してその決定がなされる。
【００１６】
好ましい実施の形態においては、もし必要ならば、正確な輝度及び色動きベクトルを確実にするために、各軸に１つの付加ビットを付加した動きベクトルを発生し、適用することができる。実験結果は、色データに対して特に改善がみられる。
【００１７】
【発明の実施の形態】
次に、添付図面を参照して、本発明を例示的に説明する。各図面を通じて同様な部分は同様な参照記号で表してある。
【００１８】
動き補償とともに３つのサイズのピクチャー（画像）が使われてきた。
（ｉ）ＶＩＤファイル：７２０＊５７６ピクセル（及び７０４＊５７６）、約４Ｍｂｐｓのターゲットビットレート
（ii）ＳＩＦファイル：約１Ｍｂｐｓ（ビデオのみ）のターゲットビットレートを有する３５２＊２８８ピクセル
(iii）ＱＩＦファイル：約２２０Ｋｂｐｓ（ビデオのみ）のターゲットビットレートを有する１７６＊１４４ピクセル
【００１９】
各場合において、色ピクセルサイズは各成分に対して各軸の半分である。
上記システムの各々に対する最適マクロブロックサイズを見つけるために実験がなされた。各場合に、その位置は明らかであり、輝度に対する１６＊１６ピクセル、各色に対する８＊８のマクロブロックサイズが最良結果を作った。
【００２０】
上記３つの場合の全てにおいて、Ｙに対する８＊８、Ｃに対する４＊４等の小さなマクロブロックは、ベクトルデータが多すぎる結果となり、Ｙに対する２４＊２４及びＣに対する１２＊１２等の大きなマクロブロックは、マクロブロックデータがローレベルになるが、異なったピクチャーにエラー信号が多くなる。この点で、ＭＰＥＧは、最適動きベクトルブロックサイズを正しくセットする。
【００２１】
伝送されるべきベクトルデータは、ピクチャーサイズに依存するが、次の計算はベクトル伝送に要求されるデータレートに対するガイドとして使われた。
【００２２】
ケース１：ＶＩＤファイル、７２０＊５７６ピクセル
マクロブロックの数＝４５＊３６＝１６２０／フレーム
対数時間削減構造および、Ｙデータに対し＋／−３１ピクセル／フレームのベクトルレンジ制限、８フレームＧＯＰ（絵素のグループ）に対して：
0003799099.tif 000002
【００２３】
エントロピー符号化によってこれを約５０％低下できるとすると、全体のベクトルビットレートは、約９００Ｋｂｐｓに減らすことができる。イントロダクションで述べたとおり、もしＹとＣベクトルが結合すると、このデータレートは更に減少して約５００Ｋｂｐｓになることができる。結合の方法についてのもっと詳しくは次のセクションで述べる。
【００２４】
ケース２：ＳＩＦファイル、３５２＊２８８ピクセル
マクロブロックの数＝２２＊１８＝３９６／フレーム
ベクトルレンジ制限は＋／−１５ピクセル／フレームに減らすことができることを心に留めて、ＶＩＤ画素符号化と類似の計算が続く：
0003799099.tif 000003
エントロピー符号化及びＹ／Ｃベクトル結合を使えば、これは約１００Ｋｂｐｓまで減らすことができる。
【００２５】
ケース３：ＳＩＦファイル、１７６＊１４４ピクセル
マクロブロックの数＝１１＊９＝９９／フレーム
ＱＩＦ符号化に対して、そのように低い解像度のソースを使うと動きエラーがもっとずっとクリティカルになるのでＳＩＦ画像に対してベクトルレンジ制限を用いれば、総合ビットレートは：
３１２＊２５／８＊９９＝９６．５Ｋｂｐｓ
になる。
これは、エントロピー削減及びＹ／Ｃベクトル結合を用いると、約２５Ｋｂｐｓまで減る。
【００２６】
上記の各場合において、ベクトルデータレートは、総合要求ビットレートの約１０％であり、これは合理的な許容値であり、その動きベクトルが第１符号化方法を厳しく制限するレベルではない。上記で使われたサイズの１／４のマクロブロックを使えば、ベクトルデータレートを総合データレートの約４０％に増加し、符号化効率に対する厳しいオーバーヘッドとなる。
【００２７】
１／４の大きさのマクロブロックを使うことにより得られる利益は、主符号化領域に及ぼす品質のロスよりも少ない。同様にして、もっと大きなマクロブロックを使えば、ベクトルデータレートを減らすことができるが、他の符号化領域に対して小さな利益を得るのみである。
【００２８】
そのような、大きなマクロブロックは、残余の符号要素においてそれほど容易に補償できないもっと大きな相違の画像エラーとなる。
サブピクセル・ベクトルを使えば、マクロブロックＧＯＰ当たり余分の１４ビットに等しい少量の余分のデータを要求する。
【００２９】
Ｙ及びＣに対して別々のベクトルを送るとデータ帯域幅の無駄となり、輝度及び色情報の配列誤りにつながる可能性があるといわれてきた。色成分の動きベクトルはほとんどいつも輝度成分に従うという事実が一般に観察される。例外もあるが、これらは非常にまれである。
【００３０】
更に、Ｂ−ＹおよびＲ−Ｙ成分は、同じ動きベクトルを持つ傾向にある。従って、１セットの３つのベクトルは、この簡単な仮定のもとに容易に１つに帰することができる。
【００３１】
この仮定についての問題点は、色サブサンプリングの性質の結果である。各色成分は、輝度成分の半分のサンプリングレートを有し、そのことが図１に示されたサンプリンググリッドに通じる。
【００３２】
そこで、もし或ベクトル値が奇数輝度ピクセル値を持てば、色ベクトル値における丸めの問題がある。何故ならば、そのベクトルは色ピクセル・サイト（現場）を直接指定しないからである。最初、簡単な丸めが適用できるように見えるかもしれず、最初の実験ではこれを使った。
【００３３】
しかし、後のテストにおいて、切り上げ又は切り捨てを選べば、色符号化において著しい性能の変化がもたらされることが解った。丸めはマクロブロック・ベースで選択されなければならない。ベクトルに対して２つの軸があるので、図２に示すような幾つかの丸めの組み合わせがある。
【００３４】
第１の場合においては、図２に示されているように、水平ベクトルは偶数値、垂直ベクトルは奇数値になる。そこで、水平色ベクトルは単純に輝度ベクトルの半分である。しかしながら、奇数値の垂直ベクトルは同図に示されているように、切り上げ又は切り捨てができる。
【００３５】
垂直ベクトルが偶数値で水平ベクトルが奇数値である第２の場合にも同様なことがいえる。この場合、水平の丸めは、図示されているとおり、切り上げ又は切り捨てである。最後の場合は、水平及び垂直ベクトルは奇数とし、図示のとおり４つの可能な丸めオプションになる。
【００３６】
もし、色データが輝度データと同じサイズに補間されたとすると、マクロブロック・ベースで動的に丸めを行う方法は、避けることができる。しかし、これは高価であり余分のお金を使う。
【００３７】
この代わりの方法は、良く働き、各輝度ベクトルに付加的に１ビット追加することによって、簡単に実施することができる。
もし、そのビットがゼロであれば、色ベクトルの丸めは「切り捨て」であり、もし、そのビットが１ならば、その丸めは「切り上げ」である。
【００３８】
この小さなオーバーヘッドは、図２に示された全てのオプションをカバーし、独立の色ベクトルデータを送るために要求されるよりもずっと低いオーバーヘッドである。この技術は、ＭＶＥとＭＶＣプロセスの両方に適用されることに注目すべきである。
【００３９】
更に他の問題は、ＭＶＥに対し、ＭＳＥ（又はＭＡＤ）値を発生するためのＹ及びＣ値のスケーリングの間の関係に関する。Ｙ及びＣの両方が使われ、これはベクトルが両方の成分を表し、例えば、輝度成分のブロック比較があまり相違がないことを示す場所では、色相違値はベクトル選択のバランスを保持することができる。
【００４０】
色々な実験において、この率はあまり厳格であるとは思われない。プロジェクトタイムスケールにおける種々の点でベクトル選択のために、下記の表現の両方が使われた。
ＭＳＥ（ａ）＝（Ｙｅ）2 ＋（Ｃｅ）2 
ＭＳＥ（ｂ）＝（Ｙｅ）2 ＋２＊（Ｃｅ）2 
【００４１】
どちらに対してもあまり有益であるとは思われないので、その簡単さのために第１のケースが推奨されるべきである。
サブピクセルＭＶＥ及びＭＶＣの利益を評価するために行われた実験においては、１／２ピクセルのみが考慮された。
【００４２】
ＶＩＤファイルを使うと、ビデオがインターレースされるという問題があり、垂直補間の最善方法について、問題が生じる。
【００４３】
ＳＩＦ及びＱＩＦ画像ソースを使うと、簡単な線形補間処理を与える。何故ならば、両方とも１秒当たり２５フレームで効率よくフレーム基準プログレッシブ（漸進）スキャンされるからである。しかしながら、フィルタ・リンギング・アーティファクトが益々目に見えてくるのでピクセルサイズが減ってしまうから、フィルタの次数が重要な問題になる。
【００４４】
全ての補間フィルタは、ハーフバンド・フィルタに基づいてきた。下記に示すように、タップ長の増加と急峻な遷移バンドを与えるために４タイプが使われた。
（１）                          1    2    1
（２）                 -1  0    9   16    9  0   -1
（３）          3  0  -16  0   77  128   77  0  -16  0  3
（４）  -6  0  26  0  -79  0  315  512  315  0  -79  0  26  0  -6
【００４５】
これらのフィルタは夫々１，２，３及び４として参照される。
第１のテスト結果は、交番Ｔ及びＢフレームを用いた２フレームＳＸシステムを用いて圧縮されたＶＩＤ画像を使った。
【００４６】
これらの結果は、第１水平補間のみの適用の効果を示し、それから、或フレーム（フィールドではなく）に垂直補間が適用された場所での水平及び垂直補間を示している。
【００４７】
【表１】
0003799099.tif 000004
【００４８】
この水平フィルタは、タイプ３にセットされ、垂直フィルタはタイプ１にセットされた。結果は、次のパラメータを有するシステムに対して表１に示すとおりである。
ソース画像  ：  モービル及びカレンダー
圧縮のタイプ：  Ｉ−Ｂ，３段ウェーブレット空間削減を使った２フレーム
量  子  化  ：  Ｑ＝１０７０，量子化器ビュー高さ＝３Ｈ
【００４９】
この表から、水平サブピクセル動き補償の追加は、（Ｓ／Ｎは同様な値に留まるが）全ビットレートにおける著しい低下につながる価値があることが明らかである。しかしながら、垂直サブピクセル動き補償を付け加えることは、何も付加せず、パーフォマンス（性能）を悪くする。垂直サブピクセル動きの補償の利益は、従って、インターレースされた走査画素ソースに対して正当化することは難しい。
【００５０】
しかしながら、ＳＩＦ及びＱＩＦ画像は、フレーム基準であり、インターレースに関して何等問題ない。両タイプの画像ソースについての実験では、サブピクセル動き補償を適用すると、水平及び垂直方向の両方において等しく有効であり、それなりに、同じフィルタが両軸の補間に使われる。
【００５１】
第２セットの結果は、ウェーブレット空間次元で８フレームＧＯＰを基準にして０．４ｂｐｐ（〜１Ｍｂｐｓ）でコード化されたＳＩＦ画像の使用に基づくピクセル及びサブピクセル動き補償のもっと包括的な比較であった。
結果は、下記の表２に与えられている。
【００５２】
【表２】
0003799099.tif 000005
【００５３】
注１：色は輝度に比べて半分の数のピクセルしか持たないので、和のビットレートの計算はＹ＋Ｃ／２である。
注２：補間フィルタは水平及び垂直軸の両方に対してタイプ４（最も複雑）のものであった。
【００５４】
結果は、サブピクセル・ベクトルを使った効果を明確に示している。以前の例よりもむしろ明らかであり、サブピクセル動きベクトルを使うと視覚テストにおける画質の目に見えた改善を作る。
【００５５】
この応用の為にターゲットとされた低いビット・パー・ピクセルで使えるどんな有用な結果をも作るために、適用できる全ての方法が要求されるので、ＱＩＦ符号化のテストは、サブピクセル動きベクトル補償にいつも使われる。従って、ＱＩＦ符号化に比較測定は用いることができない。
【００５６】
前のセクションの調査によれば、現在遂行されている動きベクトル推定の見解に異常を示した。これが符号化遂行に悪影響を示すか否かは明らかでなかった。
この異常は、Ｂフレームに影響するだけで、Ｐフレームには影響しない。
【００５７】
各Ｂフレームは一対の動きベクトルに関連をもっており、一つは、時間的に背後のフレームを指しており、もう一つは、先行フレームを指している。ベクトルの選定は、現在のフレームのマクロブロックを他のフレームのマクロブロックと比較することにより行われるが、Ｘ−Ｙ座標オフセットによってオフセットされる。
【００５８】
これは、通常は独立計算によって、順方向及び逆方向に計算される。しかしながら、Ｂフレームは、Ｂフレームの順方向及び逆方向のフレームにおけるマクロブロックから作られた平均マクロブロックを取ることにより作られる。即ち、
Ｂ1 ＝Ｉ1 −Ｉ0 ／２−Ｉ2 ／２
これは、ハイパスフィルタ：−１，２，−１と等価である。
【００５９】
フレームＩ0 及びＩ2 は常時は独立に計算される。これは１，−１タイプのフィルタを使うのと等価である。ＭＶＥに対して使われるフィルタはＭＶＣに対して使われるものではない。ＭＶＥの現在の方法と関係する重大な問題を起こしかねない特別なパターンを心に描くことが可能である。
【００６０】
Ｉ1 フレームを各側のベクトルオフセットの全結合と比較することによって、この問題を克服するＭＶＥの方法を心に描くこともまた容易である。しかしながら、＋／−Ｖのベクトルレンジに対して、独立ベクトル計算は
２＊（Ｖ2 ）
に比例するが、両方向サーチを使えば、この計算は
（Ｖ2 ）2 ＝Ｖ4 
に比例するようになり、数倍大きい。
【００６１】
正規ベクトル推定が厳しい計算上の問題である場所では、Ｂフレーム計算に対する双方向ベクトル推定の予想は禁じられている。このエリアでは如何なる正式な作業もなされない。ＭＳＥ値によって与えられた指示はＭＶＥ発生の正規方法が双方向値に近い結果を作ることを示し、殆どの場合、ゲインが得られないことが想像される。
【００６２】
しかし、或動きシーケンスに関して、そのことが目立つようにするこの問題に設計者は気付くべきである。このエリアをもっと詳しくのぞき込むことが必要になれば、処理インパクトを最小にする、即ち、最初の推定の独立の結果を用い、しかる後、双方向サーチを基準として、最小を探すための各ベクトルセットに対する小さなサーチサブエリアを採用することに注目すべきである。
【００６３】
この双方向サーチは、符号化のための関数にすぎず、複合器（デコーダ）には影響を与えず、エンコーダに対して改装できる特色である。
整数動きベクトル推定のほぼ全ての結果は、最小ベクトル近傍の比較的ゆっくりとした変化を示す。
【００６４】
このことは、その信号よりはむしろベクトル相関プロファイルに対して補間フィルタを適用することによって、サブピクセルベクトルを決定するためのフィルタを使うという期待を起こさせる。そのコンセプトについて図３に簡単に図示されている。
【００６５】
この補間フィルタは、フィルタ１−４として始めのほうで定義した半バンド型のものとすべきである。補間フィルタは、補間されたベクトル値が最小にならないであろう負の値の係数を有することが必要である。
【００６６】
このエリアの初めの作業は、この技術の潜在能力を証明したが、作業の他のエリアは、この技術がサブピクセル動きベクトルを発生するピクチャーを補間する標準的な方法全般に亘って確立されてはいなかったことを意味する。
【００６７】
この技術は、それが従来の方法と同じくらい信頼性のあるベクトルを作るかどうかを確かめるための作業を更に必要とする。この利益は、サブピクセルベクトル結果を作るためにとられる計算時間がかなり削減されることである。
【００６８】
動きベクトル補償の著しい観点は、マクロブロック構造にソフトウィンドウを適用するという観点である。１ＭｂｐｓのＳＩＦ符号化されたピクチャーについてテストしている間は、急速な動きのエリアにおいてはマクロブロック構造は目に見えるようになることが注目された。
【００６９】
これは、フレーム毎のシーケンスを通って歩進する時にはっきりと証明される。このマクロブロックはＱＩＦピクチャーを使う２５６Ｋｂｐｓのローレートで、もっとずっと可視的になった。そこでは、マクロブロックは、１１＊９のアレイサイズを占め、ＶＩＤ符号化ピクチャーのエリアの１６倍である。
【００７０】
そのように低いビットレートでは、マクロブロック・エラー可視性を改善する方法を考えることが必要になってきた。前に述べたとおり、もっと小さな寸法のマクロブロックを使うことは不可能である。何故ならば、もっと大きな数のベクトルによってとられる過剰ビットレートのためである。
【００７１】
しかしながら、ウィンドウ化技術を用いることによりマクロブロック・エラーの可視性を著しく減らすことは可能である。マクロブロックの基本的な大きさは、輝度に対して１６＊１６（色に対して８＊８）に留まるが、ベクトルに援助されたフレーム差計算のために２４＊２４（色に対し１２＊１２）のウィンドウが使われている。
【００７２】
全ての推定ピクチャーが等しいゲインを持つためには、ウィンドウのエッジは図４に示されるようにテーパーが付けられており、同図はＹ及びＣマクロブロックに対するウィンドウ機能を示す。
【００７３】
図４に示されたウィンドウは、図５に図示されたような全フラット面を形成するために互に重ね合わされることができるタイルを形成する。図４に与えられた１−Ｄテンプレートを使い、下記の表現によりウィンドウを表す。
for(x=0; x<24; x++)  window[x]=template[x];
そこで、２−Ｄウィンドウは次の表現で与えられる。
for(x=0; x<24; x++)
for(y=0; y<24; y++)
window[x][y]=template[x]*template[y];
【００７４】
１−Ｄウィンドウは値１６だけ尺度付けされ、２−Ｄウィンドウはファクタ２５６だけ尺度付けされている。
動き推定及び動き補償プロセスの両方に於いて使われたウィンドウ化された動きベクトルの有効性を評価するために、テストが行われる。これらの結果は表３及び４に要約されており、これらの図は異なったタイプのシーケンスに対してそれぞれ示している。
【００７５】
（ｉ）ブロックに基づくＭＶＥの使用、及びブロックに基づくＭＶＣとウィンドウに基づくＭＶＣの比較
（ii）ウィンドウに基づくＭＶＣの使用、及びブロックに基づくＭＶＥとウィンドウに基づくＭＶＥの比較
【００７６】
【表３】
0003799099.tif 000006
【００７７】
【表４】
0003799099.tif 000007
【００７８】
ウィンドウ化されたＭＶＣを実施するコストは比較的小さく、実用的なオプションである。特にブロック基準ＭＶＣについて得られたかなりの質の改善をみるとそうである。この改善は、表３のスージーについての結果の最後の２行において、数値的に最も注目される。他の行は殆ど変化がないかやや悪い結果となっている。ウィンドウ化されたＭＶＣの視覚的効果はいつもブロックに基づくＭＶＣよりも良い。
【００７９】
表４の結果に戻ると、その比較の結果は、ある種のシーケンスにおいて小さな相違を示すがウィンドウ化されたＭＶＥの実施はもっとずっと幅広いエリアに亘る計算を含むので非常に高価である。
【００８０】
これはソフトウェア・ランタイムに跳ね返りブロック基準のＭＶＥよりもかなり遅くなる。このファクタは、表５の結果と共に、ウィンドウに基づくＭＶＥとウィンドウに基づくＭＶＣの両方を使う努力がやりがいのあることではないことを、はっきりと示している。
【００８１】
視覚的な改善もほとんどない。しかしながら、ブロックに基づくＭＶＥとウィンドウに基づくＭＶＣを使えば、非常に利益があり、前に受け入れ難かったピクチャー品質（特にスージー  シーケンス）をもっとずっと受け入れ得る品質レベルに変える。
【００８２】
ブロックに基づくＭＶＥとウィンドウに基づくＭＶＣの結合が、類似の品質改善を持った１ＭｂｐｓでＳＩＦ符号化されたピクチャーにも同様に適用された。高いデータレートで（例えば、ＶＩＤピクチャーに対しては４Ｍｂｐｓ）でその改善する価値があることはいまだ確立したものではなく、その利益はまだ存在するが低いレベルであることもあり得る。
【図面の簡単な説明】
【図１】輝度及び色のサンプルグリッドの模式図である。
【図２】色ベクトル推定のために使われる丸め（ROUNDING) 処理を説明するためのグリッド模式図である。
【図３】サブピクセルベクトルを作る補間フィルタの使用を説明するための波形図である。
【図４】輝度及び色マクロブロックのためのウィンドウ機能を示すブロック図である。
【図５】１及び２次元における動きベクトルウィンドウのオーバーレイを示す説明図である。
【符号の説明】
Ｙ  輝度、Ｃ  色
【図１】
0003799099.tif 000008
【図２】
0003799099.tif 000009
【図３】
0003799099.tif 000010
【図４】
0003799099.tif 000011
【図５】
0003799099.tif 000012