【発明の詳細な説明】

【産業上の利用分野】本発明は、データ圧縮及び圧縮解除に関し、特に、圧縮画像のサイズの特定の目標の範囲にビデオデータを符号化するための方法及びシステムに関する。

【従来の技術】マルチメディアのパーソナルコンピュータ（ＭＰＣ）の到来は、家庭用娯楽産業に変革をもたらすと思える。 一般に、ＭＰＣは、例えばインテル３８６
マイクロプロセッサといった強力なマイクロプロセッサ、ＶＧＡモニタ、サウンドカード、少なくとも２ＭバイトのＲＡＭ及びＣＤ−ＲＯＭドライプを含む。 アプリケーションプログラムがＭＰＣの潜在力を完全に実現するためには、これらの構成要素をその能力いっぱいまで使用しなければならない。 システムの構成要素を最大に利用しながら、ＭＰＣでのビデオ映画を楽しみたいという希望は、本発明の発端となった。 ビデオ映画を見てきれいであるためには、１５フレーム毎秒の速度で作動すればよい。 しかし、標準のＣＤ−ＲＯＭドライブは、１
５０Ｋバイト毎抄のデータを提供することができるのみである。 従って、ＭＰＣで表示するに適する映画を作るためには、圧縮方法は、映画の各フレームを約１０Ｋバイトに圧縮する必要がある：〔（１５０Ｋバイト／秒）
／（１５フレーム／抄）＝１０ＫバイトＢ／フレーム〕。 しかし、フレームをこのサイズに一貫性をもって圧縮可能とする方法を開発することは−−情報の実質的な量を失わないで−−複雑な手順となる。 この手順は、
二つの基本的な理由で複雑となる。 まず、元の生データのサイズは、映画から映画で大幅に異なり、例えば、３
２０Ｘ２４０ピクセルのビデオ映画のフレームは、１７
５Ｋバイトの生データとなるが、１６０Ｘ１２０ピクセルのビデオ映画のフレームは、２５Ｋバイトの生データに過ぎない。 第二に、同じ映画でさえも、フレームのいくつかは、他のフレームよりも圧縮しにくい。 例えば、
明るい色の草原を描くフレームは、薄暗い通りを描くフレームより、必然的により細かくなる。 従って、圧縮方法は、画像の品質をかなり落とさなくては、草原のフレームを１０Ｋバイトに符号化することはできない。

【発明が解決しようとする課題】従来技術は、ＭＰＣでの再生用に、ビデオ映画を符号化するための固定圧縮率を使用している。 しかし、この方法は、深刻な欠陥を有す。 即ち、固定圧縮率による方法は、ビデオデータを恒常的に過剰圧縮を起こすかあるいは圧縮不足を起こす。
例えば、生データを生データの元のサイズの２０％に圧縮する圧縮法は、２５Ｋバイトの生データフレームを５
Ｋバイトに圧縮する。 従って、従来技術の圧縮法は、不要に５Ｋバイトのデータを破壊してしまう可能性がある。 その結果、圧縮データは、拡大されると、劣化した品質の画像を生成する。 一方、同じ圧縮方法は、１７５
Ｋバイトのビデオデータを３５Ｋバイトに圧縮する。 この場合、得られた圧縮データは、ＭＰＣで使用するには大きすぎる。 更に、従来技術の圧縮方法のあるものは、
非標準フォーマットで圧縮データを符号化している。 これら従来の圧縮方法は、殆どのＭＰＣのアプリケーションで、非標準の圧縮データをアプリケーションがデータをＭＰＣ上へ表示する前に既知のフォーマットへ変換しなければならないので問題を伴う。 従って、再生用のビデオデータやその他のデータをあるデータ速度で満足に圧縮することを可能とする方法とシステムに対する必要性があった。

【課題を解決するための手段】フレーム内及びフレーム間圧縮技術を使用して、ビデオデータのフレームを特定の目標サイズへ圧縮する方法を開示する。 フレーム内圧縮を使用する場合は、この方法は、一フレームのビデオデータをそのフレームに含まれるそのデータに対してのみ圧縮する。 一方、フレーム間圧縮を使用する場合は、
本発明は、現在圧縮過程にあるフレームの直前のビデオデータのフレームに対して一フレームのビデオデータを圧縮する。 より具体的には、フレーム内圧縮に付いては、圧縮方法は、ビデオデータのフレームを構成するピクセルから複数のピクセルグループを形成することで始まる。 次に、本発明は、例えば色、強度等といったのグループの特性に基づいて二つのグループの間の変化値を計算する。 計算後、その変化値を特定のフレーム内許容値と比較する。 変化値がフレーム内許容値に等しいかまたはそれより小さい場合は、本発明は両グループの特徴を表す一つの値を指定する。 この計算と比較は、この方法でフレームの全てのグループを調べるまで継続される。 本発明によれば、同じ特徴値を有す連続したピクセルグループの数を計数することによりそのフレームを圧縮する。 本方法によれば、計数を完了すると計数値及び特徴値をビデオフレームの圧縮バージョンとして記憶する。 フレーム間圧縮も同様な方法で動作する。 この場合は、しかし、二つの連続したフレームの類似した状況のピクセルグループを比較する。 本発明では、指定したフレーム間許容値内にある連続したフレーム間ピクセルグループの数が計数される。 次に、連続したフレーム間ピクセルグループのこの数を示すデルタを符号化する。 更に、本圧縮法は、フレーム内及びフレーム間の両方の組み合わせを使用する。 使用する圧縮法にかかわらず、本方法は、得られた圧縮ビデオフレームと指定目標範囲と比較している。 圧縮ビデオフレームが指定目標範囲にない場合は、本方法では、許容値の一つまたは両方を調整し、データを既に述べた方法で再度圧縮する。 更に、本方法により、ビデオ画像の質を大きく損なわないでは、
指定目標範囲に圧縮できない場合は、生データのビデオフレームを半分に分割し、各半分を別々に圧縮する。

【実施例】本発明は、目標範囲内にビデオデータを圧縮するために、ランレングス符号化及び反復許容値を使用する。 本発明は、基本的に、類似の特徴、例えば、類似の色を有すピクセルを統合することによってビデオデータを圧縮する。 まず第一に、発明はピクセル対をなすピクセル間の差に基づく変化値を計算する。 第二に、この変化値を許容値と比較する。 変化値が許容値より小さいか同じの場合は、本発明では、両ピクセルは、単一の特徴値で記述されて、例えば、二つの連続した非常に薄い青色のピクセルの隣に二つの連続した薄い青色のピクセルがある場合、これらは四つの連続した薄い青色のピクセルとして記述される。 本実施例では、フレーム内圧縮かまたはフレーム間圧縮を利用してビデオ映画のフレームの圧縮を行う。 フレーム内圧縮を用いる場合は、本発明はその特定のフレーム内に含まれるデータのみを使用してフレームを圧縮する。 一方、フレーム間圧縮を用いる場合は、本発明は、直前のフレームに対してフレームを圧縮する。 例えば、本発明は、ビデオ映画のフレーム（ｎ＋１）を、フレーム（ｎ）から実質的に変化しているピクセルのみを記憶することにより圧縮する。 映画の殆どのフレームは、動きの錯覚を作り出すために、前後のフレームに類似しているので、フレーム間圧縮は、極めて効果的な手法である。 再生では、フレーム（ｎ＋
１）のフレーム間符号化データは、フレーム（ｎ）に直接に重なって表示されるので、動きの錯覚は、維持される。 しかし、本発明が必要なものは、フレーム（ｎ＋
１）に更新されねばならないフレーム（ｎ）のピクセルに素早くアクセスする手段である。 本発明は、この条件を、フレームの圧縮バージョンに於いて、デルタとして知られる、特別のバイトグループを符号化することによって満足している。 基本的に、デルタは、フレーム（ｎ
＋１）を生成するために更新を必要とするフレーム（ｎ）のピクセルに対して、ピクセルを着色するの使用される器具であるブラシを移動させる。 本発明は、多くのやり方でもってデルタを符号化する。 一つのデルタ符号化法は、デルタ符号化のために４バイトグループを使用する方法がある。 この方法は、（１）２バイトのエスケープシーケンスと、（２）水平オフセットと、（３）
垂直オフセットとをフレームの圧縮バージョンに記憶する。 ２バイトエスケープシーケンスは、符号化されたバイトをデルタとして認識するのに使用される。 水平及び垂直オフセットは、ピクセル更新前に、圧縮解除ルーチンがブラシを移動させるべきピクセルの数を単に記述しているのみである。 図９を参照（水平及び垂直オフセットを使用したデルタ符号化処理を説明している）。 この符号化技術は、ブラシを適当なピクセルヘ移動させるには有効であるが、場合によってはメモリの最も効果的な使用法とならない場合がある。 圧縮ビデオデータで発生するデルタの大部分は、ゼロの垂直オフセットを有す。
更に、殆どのデルタの水平オフセットは、相対的に短く、即ち１６ピクセルより短い。 このような場合は、本発明はデルタを１バイトとして符号化し、このバイトは、水平オフセットの大きさを示す。 図１４を参照（単バイトを使用するデルタ符号化処理を説明している）。
図１４のデルタ符号化法は、従って、図９のデルタ符号化法より７５％少ないバイトを用いる。 更に、圧縮ビデオデータでデルタは頻繁に起こるので、各デルタで得られる７５％の節約は、圧縮ビデオデータの全体サイズでは、２０％の節約に相当する。 しかし、本発明がどのデルタ符号化法を適用するかにより、フレーム間圧縮は、
貴重な圧縮ツールとなる。 更に、フレーム内圧縮と組み合わせてフレーム間圧縮を使用することにより本発明は、極めて高解像度の圧縮フレームを形成することが可能である。 例えば、フレーム（ｎ＋１）の７０％が、実質的にフレーム（ｎ）から変化していないとすると、本発明はビデオフレームの残り３０％を記憶する約１０Ｋ
のメモリを有す。 従って、フレーム内圧縮及び小さい許容値を用いることにより、本発明は非常な細部に付きデータの残り３０％を記憶することが可能となる。 ある場合は、フレーム間圧縮を使用して得られる細部のデータ量にかかわらず、本発明はフレーム内圧縮を使用してフレームを符号化する。 このフレームをキーフレームと呼ばれる。 キーフレームは、ビデオ映画のランダムフレームに対するユーザのアクセス性を高める。 例えば、ユーザが、ビデオ映画で約１０分間ほど経過した時点で発生したフレームにアクセスを希望すると、希望フレームは、約９，０００の先行フレームがある。 本発明により、フレーム間圧縮を使用して第一フレームを除く全てを符号化する場合、フレーム９，０００へアクセスすることは多大な処理時間を必要とし、即ち、本発明は、希望フレームを表示する前に９，０００フレームを符号化し、表示する必要がある。 この問題を回避するために、
本発明は、映画全体を通じて一定間隔をおいて、例えば、３０秒毎にキーフレームを挿入する。 従って、映画に１０分より若干少ない時間経過した時点で発生するフレームを表示するには、本発明は、映画の中の９−１／
２分経過した時点で圧縮されたキーフレームを直ちに指示する。 （１）キーフレーム及び（２）キーフレームと希望フレームとの間を圧縮解除することによって、本発明は視聴者の指定フレームを素早く表示する。 全体フレームが一旦圧縮されると、圧縮データのサイズと目標範囲が比較される。 圧縮データが目標範囲の上限より大きい場合は、本発明は（１）許容値を増加させるか、または（２）ビデオデータを小さく分割する。 本発明は、増加させた許容値か、または低減したデータ量を使用してデータを再圧縮する。 本発明は、データの圧縮バージョンが目標範囲となるまでこの再圧縮処理を繰り返す。 一方、圧縮データが目標範囲より小さい場合は、本発明は、許容値を低減し、フレームを再圧縮する。 この方法で、本発明は、指定された目標範囲の最適情報量を含む圧縮ビデオデータを生成する。 図示されているように、
本発明は、ビデオ映画を圧縮し、圧縮解除するための方法及びシステムで実施されている。 しかし、本発明による圧縮及び圧縮解除は、他の種類のデータを圧縮するのにも使用可能である。 一般に、ビデオ映画は、複数のビデオフレームで形成されている。 また、各フレームはというと、複数のピクセルで形成されている。 一般に、各ピクセルは、関連した特徴値、例えば色、強度他を有す。 更に、ピクセルのグループは、そのグレースケール及び主色を有す。 本発明は、個別ピクセルまたはピクセルグループの特徴値を比較することによって圧縮することを想定する。 はっきりさせるために、図１から図１４
の説明では個別ピクセルの色値を用いて圧縮及び圧縮解除が実行される。 殆どの着色法では、各ピクセルの色は、多数の色成分により表現される。 色成分のよく使用される組み合わせは、ＲＧＢセットであり、Ｒは赤成分、Ｇは緑成分、Ｂは青成分を表す。 一つのピクセルの成分を表すために下付き文字２を使用し、他のピクセルの成分を表すために下付き数字１を使用して、本発明の実施例は、以下の式を使用してピクセル対の変化値を計算する。 変化値＝（Ｒ _２ −Ｒ _１ ） ^２ ＋（Ｇ _２ −Ｇ _１ ） ^２ ＋（Ｂ _２
−Ｂ _１ ） ^２これより、本発明は、以下の式を使用して圧縮を目標として二つのピクセルが類似した色であるかどうかを決定する。 変化値≦許容値 変化値が以上の式を満足した場合は、本発明は両ピクセルは単一の色値として参照される。 一方、変化値が許容値より大きい場合は、本発明は、ピクセル対の各ピクセルを二つの異なった色値を使用して参照する。 説明の実施例では、各フレームまたは複数のフレームの各ラインでの全ての連続したピクセル対につき上述の比較法を用いることによってビデオデータを圧縮する。 更に、本実施例では、フレーム間圧縮及びフレーム内圧縮で異なって許容値を使用する。 これらの許容値は、フレーム間許容値及びフレーム内許容値としてそれぞれ呼称される。
これらの二つの許容値を以下に詳述する。 許容値を調整するか、または（２）フレームの生データを分割するかによって、本発明は、指定された目標範囲内に生ビデオデータを圧縮する。 圧縮法ルーチン ビデオ映画を圧縮するルーチンのフローチャートは、図１に示される。 ブロック１００がビデオ映画のフレームを生データとして受信すると圧縮処理が開始する。 ブロック１０５では、ルーチンが、ルーチンによりまだ圧縮されていない映画の少なくとも一フレームがあるかどうか判断する。 生データフレームが存在すると、ルーチンは、ブロック１１０のサブルーチン圧縮フレームを呼び出す。 このようにして、ブロック１１０は、生データフレームの圧縮バージョンを生成する。 この圧縮処理は、
図２を参照して詳細に説明される。 ブロック１２０は、
ブロック１１０のサブルーチンにより戻された圧縮フレームのサイズを判断する。 圧縮フレームが、目標の範囲にない場合は、ルーチンは、制御をブロック１３０へ移管する。 ブロック１３０は、フレームが分割されるべきかどうかを決定する。 本実施例では、ブロック１３０
は、フレーム間許容値を最大許容値と比較することによって、この決定を実行する。 フレーム間許容値が最大許容値より大きければ、ブロック１３０は、処理制御をブロック１５０へ移管する。 ブロック１５０は、図６の分割フレームルーチンを使用して、元の生データフレームを二つの生データフレームへ分割し、制御をブロック１
１０へ移管する。 一方、フレーム間許容値が、最大許容値より小さい場合は、ブロック１３０は、制御をブロック１４０へ移管する。 ブロック１４０は、修正バイナリ探索法を使用してフレーム間許容値を増加または低減している。 一般に、バイナリ探索は、可能な値のより狭い範囲の大体の中心点からのテスト値を繰り返し選択することによって理想値を素早く見いだす。 探索法がテスト値を選択すると、探索法は、その選択値が理想値より大きいが小さいかを決定する。 選択値が理想値より大きい場合は、探索法は、第二テスト値を選択する。 探索法は、範囲の元の最小値と先に選択された値により定義された、範囲の中心点から第二のテスト値を選択する。 逆に、選択値が理想値より小さい場合は、探索法は、先に選択された値と、範囲の元の最大値により定義される範囲の中心点から第二のテスト値を選択する。 値の範囲をより狭め中心点の値を繰り返し選択することによって、
バイナリ探索法は、素早く理想値を求める。 しかし、本発明は、バイナリ探索法をビデオデータ圧縮に理想的に適切となるように適合化させる。 本発明は、目標範囲内のビデオフレームの圧縮バージョンを生成する許容値を求めるために、修正バイナリ探索法を使用する。 本発明による第一の修正は、本方法が選択する第一のテスト値は、許容値の全体の許容範囲の中心点にはない。 例えば、ＲＧＢ色値を使用して、許容値の許容できる範囲は、ゼロから１９５，０７５（この値を含む）までである。 （２５５ ^２ ＋２５５ ^２ ＋２５５ ^２ ）。 従って、第一の選択許容値は、ゼロと１９５，０７５の中心である９
７，５３７．５０としてもよいかもしれない。 理論的には、これは有効である。 しかし、ビデオデータに付いては、本発明者等は、許容値２，０００及び２５０がそれぞれ理想フレーム間及びフレーム内許容値での理想的な第一推測値であることをヒューリスティックに求めている。 または、許容値１，０２４及び１２８がうまく使用できた。 バイナリ探索への第二の修正は、最終推測値が理想許容値より小さかった場合の本発明による次の推測許容値の決定である。 厳密なバイナリ探索理論は、以下の関係を使用して次の推測値を決定する： 次の推測値＝（先行の推測値＋許される最大特性値）／
２ しかし、許される最大許容値１９５，０７５は、ビデオデータの質を非常に劣化させるので、実際には使用されることは稀である。 従って、次の推測値を求めるのに変数として許される最大許容値を使用すると、ビデオデータを許容できない程度までに劣化させる許容値を生成させる。 しかし、実験によれば、次の関係は、真のバイナリ探索を十分に近似することが分かった。 次のフレーム間許容推測値＝先行のフレーム間 許容推測値＋２ ^ｎ ＊（２０４８） 上式に於いて、値“ｎ”は、始めは０に設定され、後続フレーム間許容推測値の各後続の計算毎に増分される。
例えば、この式を用いて、先行フレーム間許容推測値へ加える第一の三つの数が２０４８、４０９６、８１９２
である。 上述の関係を用いて、本発明は目標範囲内にビデオデータを圧縮するために使用できるフレーム間許容値を素早く決定することができる。 このようにして、本発明により、新規のフレーム間許容値が計算されると、
次に新規のフレーム内許容値が計算される。 本発明によれば、有効なフレーム間許容値及びフレーム内許容値の間の、ヒューリスティックに求めた関係を使用して、新規のフレーム内許容値が計算される： フレーム内許容値＝（フレーム間許容値）／８ 従って、第一のフレーム内許容推測値は、第一のフレーム間許容推測値を８で除したものである。 ブロック１４
０は、この修正バイナリ探索法を使用して許容値を調整する。 ブロック１４０が許容値を調整すると、制御は、
ブロック１１０に返されて、そこでフレームは再圧縮される。 ブロック１１０、１２０、１３０、１４０及び１
５０からなるループは、ブロック１２０が圧縮データが目標範囲に納まるまで継続される。 その時点で、ルーチンは、制御をブロック１０５へ戻し、ブロック１０５
は、他の生データフレームのチェックをする。 このようにして、本発明は、目標範囲内に映画の全フレームを圧縮する。 ルーチンが全フレームを圧縮し終わると、制御をブロック１８０へ移管する。 ブロック１８０は、発明の処理を呼びだしたアプリケーションに戻る。 圧縮フレーム・ルーチン 図１のブロック１１０に依ってコールされる、圧縮フレーム・ルーチンのフロー・ダイアグラムが図２に図示されている。 ルーチンは、ルーチンが相互フレームまたは内部フレーム圧縮を呼び出すかどうかについて決定する、シリーズのテストを実施することに依って、プロセスを開始する。 まず、ブロック２００は、ルーチンがムービーの最初のフレームを圧縮しているかどうかについて確認するテストを行う。 このケースで、相互フレームは不可能である。 相互フレーム圧縮は２つのフレームを要求し、ここで、発明は使用できる１つのフレームしか搭載していない。 ブロック２１０は、ルーチンがフレームをキー・フレームとして圧縮するかどうかについて確認するテストを行う。 例えば、コール・ルーチンが発明はキー・フレームを１５０フレームごとに１回生成することを指定している場合、ルーチンは、カウンターに１
５０の値をロードして、カウンターの値を全てフレーム圧縮の後に減少する。 ルーチンがカウンターをゼロまで下げると、それは、次のフレームがキー・フレームとして圧縮されるべきであることを指示するフラグをセットする。 次に、ルーチンはカウンターに１５０の圧縮を再びロードする。 このようにして、発明は、キー・フレームを頻度ごとに、または、コール・プログラムに依って指定される、キー・フレーム間隔で生成する。 最終的に、ブロック２３０は、相互フレーム圧縮が使用できる唯一のタイプの圧縮であるかどうかについて確認するテストを実施する、例えば、圧縮方法をコールするアプリケーションが任意の相互フレーム圧縮を使用しないことを指定している場合があるかも知れない−−これは、圧縮されるデータが、相互フレーム圧縮を再び分類せすに、ターゲット・レンジにルーチンで入ることができるケースであるかも知れないからである。 ブロック２０
０、２１０、または２３０で行われる任意のテストが肯定的である場合、ルーチンはコントロールをブロック２
５０にパスする。 ブロック２５０は、次に説明される、
サブルーチン内部フレーム圧縮をコールする。 図５（内部フレーム圧縮ルーチンのフロー・ダイアグラム）を参照すること。 一方、ブロック２００、２１０、２３０で行われるテストの全てが否定的である場合、ルーチンは、次に説明されるサブルーチン相互フレーム圧縮をコールするブロック２４０にコントロールを進める。 図３
と４（相互フレーム圧縮ルーチンのフロー・ダイアグラム）を参照すること。 ブロック２４０またはブロック２
５０がフレームを圧縮した後に、ルーチンは、図１のブロック１１０にリターンするブロック２６０にコントロールを進める。 相互フレーム圧縮ルーチン 相互フレーム圧縮ルーチンのフロー・チャートが図３と４に図示されている。 図２のブロック２４０（相互フレーム圧縮ルーチンのコール）を参照すること。 前述のように、相互フレーム圧縮は、ビデオ・データのフレームを直前のフレームに相応して、例えば、今のフレーム、
フレームｎ＋１を前のフレーム、フレームｎに相応して圧縮することに依ってエンコードする。 相互フレーム圧縮ルーチンは、２つの許容値を用いて、すなわち、相互フレーム許容値と内部フレーム許容値を用いて、フレームｎ＋１をフレームｎに相応して圧縮する。 発明は、相互フレーム許容値を用いて、２つの隣接するフレームと類似の位置に設定されているピクセルが、圧縮に対して全く同じと見なされるカラーに十分に似ているかどうかについて決定する。 同様に、発明は、内部フレーム許容値を用いて、同じフレームの２つの連続するピクセルが、圧縮に対して全く同じと見なされるカラーに十分に似ているかどうかについて決定する。 相互フレーム圧縮ルーチンは、今のフレームの圧縮を図３のブロック３０
０から始める。 ブロック３００は、今のフレームにビデオ・データの圧縮されていないラインが残っているかどうかについて決定する。 ルーチンが今のフレームの全てのラインを圧縮すると、ブロック３００は、コントロールを、図２のブロック２６０にリターンするブロック３
０５に送る。 一方、ビデオ・データの少なくとも１つの圧縮されていないラインが今のフレームに残っている場合、ブロック３００はコントロールをブロック３０７に送る。 順に、ブロック３０７は、前のフレーム・ピクセル・ポインタの内容を、前のフレームの次の圧縮されていないラインの最初のピクセルのアドレスにセットする。 同様に、ブロック３１０は、今のピクセル・ポインタの内容を、今のフレームの次の圧縮されていないラインの最初のピクセルのアドレスにセットする。 次に、ブロック３２０はデルタ・オフセットをゼロに初期設定する。 ここで、ブロック３３０は、今と前のフレーム・ピクセル・ポインタの内容から参照されるピクセルが、有効な相互フレーム・ピクセル・ペアを形成しているかどうかについて、すなわち、ピクセルの列の末端が到達されたかどうかについて確認するテストを行う。 ペアが有効な時に、ルーチンは、ブロック３４０のペアの変動値を、例えば、変動値＝（Ｒ２−Ｒ１）２＋（Ｇ２−Ｇ
１）２＋（Ｂ２−Ｂ１）２の関係式を用いて計算する。
ルーチンは、次に、変動値と相互フレーム許容値を比較する。 相互フレーム許容値が決定された変動値より大きいか等しい場合、ブロック３５０はコントロールをブロック３５２に送る。 順に、ブロック３５２はデルタ・オフセットを更新する、例えば、ブロック３５２は水平オフセットを増加する（このプロセスは次の例で更に詳細に説明される）。 ブロック３５２がデルタ・オフセットを更新した後に、それはコントロールをブロック３５４
に送る。 ブロック３５４は、前のフレーム・ピクセル・
ポインタの内容を増加して、コントロールをブロック３
５６に送る。 ブロック３５６は、今のフレーム・ピクセル・ポインタの内容を増加して、コントロールをブロック３３０に送る。 ブロック３３０は、再び、別の有効な相互フレーム・ピクセル・ペアのテストを行う。 一方、
ブロック３５０が変動値が相互フレーム許容値より大きいと決定すると、ブロック３５０は、コントロールをブロック３６０に送る。 ブロック３６０はデルタ・オフセットの値を調べる。 水平と垂直の両方のデルタ・オフセットがゼロに等しい場合、ブロック３６０は、コントロールを図４のブロック４０７に送る。 一方、少なくとも１つのデルタ・オフセットがゼロでない時に、図３のブロック３６０は、コントロールをブロック３６５に送る。 （１）垂直デルタ・オフセットがゼロに等しくて、
なおかつ、（２）水平オフセットが指定されたデルタの最小値より小さい場合、ブロック３６５はコントロールをブロック３８０に送る。 順に、ブロック３８０は、絶対モードのデルタ・オフセットに依ってカバーされるピクセルをエンコードする。 図９（絶対モードについて説明している）を参照すること。 本質的に、絶対モードは、ピクセルのカラー・インデックスの前の２バイト・
エスケープ・シーケンスを用いて、ピクセルをエンコードする。 図１０（カラー・ルックアップ・テーブル）を参照すること。 絶対モードで、２バイト・エスケープ・
シーケンスの第１バイトはゼロになる。 第２バイトは絶対エンコード・ピクセルの数を示している。 これらの２
つのバイトの次に、各々絶対エンコード・ピクセルは、
ピクセルのカラーを示すインデックスに依って表される。 図１０（カラー・ルックアップ・テーブル）を参照すること。 例えば、図９と１０を見ると、３つのピクセルは、各々同じＲＧＢカラー値−−（２３５，２０，２
０）を備えていて、次のバイト・グループ〔００ ０３
４０ ４０ ４０〕から表される。 前述のように、第１
バイト（００）はエスケープコードである。 第２バイト（０３）は、３つのピクセルのカラー値を示す、３つのバイトが、この２バイト・エスケープ・シーケンスに準じていることを示している。 次の３つのバイト（４０，
４０，４０）はピクセルのカラー・インデックスを説明している。 図１０（カラー・ルックアップ・テーブル）
を参照すること、この手順を用いて、図３のブロック３
８０は、（１）垂直デルタ・オフセットがゼロに等しくて且つ（２）水平オフセットが指定されたデルタの最小値より小さい場合に、ピクセルをエンコードする。 一方、（１）垂直デルタ・オフセットがゼロでなく、なおかつ、（２）水平オフセットが指定されたデルタの最小値より大きい場合、ブロック３６５はコントロールをブロック３７０に送る。 水平オフセットは、適正エンコーディングのために指定されたデルタの最小値についてテストされる。 この方法は、２つのバイトを用いて、絶対エンコードのためにエスケープ・シーケンスをエンコードする（図９を参照）、すなわち、デルタをエンコードするために１つまたは４つのバイトを使用する。 図９と１４を参照すること。 従って、小さいジャンプのデルタをエンコードすることは、コスト経済的でない。 この非効率的な例として、デルタを２つだけのピクセルのジャンプのためにエンコードする効果について考えてみる。
このようなエンコーディングは４バイトまでのコートを要すると思われる、すなわち、２バイト・デルタ・エスケープ・シーケンスと絶対エンコードを再開する２バイトである。 この例を図示するために、デルタ・エンコーディングは、４０のカラー・インデックスをもつ３つのピクセルに依って何れかの側に置かれる４４のカラー・
インデックスをもつ２つのピクセルの上にジャンプすると想定してみる。 図９のエンコーディング技術を用いると、デルタをこの状態でエンコードするために、１４バイト、すなわち、〔００ ０３ ４０ ４０ ４０〕
〔００ ０２ ０２００〕〔００ ０３ ４０ ４０
４０〕が必要になる。 明確にするために区分けされる、
第１バイト・グループは、各々が４０のカラー・インデックスをもつ、３つのピクセルの絶対エンコードになる。 第２バイト・グループは、２の水平オフセットとゼロの垂直オフセットをもつデルタになる。 図９を参照すること。 最後のバイト・グループは、各々が４０のカラー・インデックスをもつ、３つのピクセルの別の絶対エンコードになる。 代わりに、純粋に水平のデルタのためにシングル・バイト・エンコーディングを用いる、図１
４のエンコーディング技術は、更に効果的であるが、まだ１１バイト、すなわち、〔００ ０３ ４０ ４０
４０〕〔０２〕〔００ ０３ ４０ ４０ ４０〕を依然として必要とする。 このエンコーディングの場合、第１と第３のバイト・グループは前述のグループと同じである。 中間のバイト・グループ、シングル・バイト・デルタは、図９の方法に対して３バイト節約できる。 この節約は、しかし、デルタのエンコードを正当化しない。
デルタをエンコードしないので、発明は、図９の方法に関して４バイト且つ図１４の方法に関して１バイト節約できる。 このシーケンスのストレートな絶対エンコードは１０バイトしか要求しない、すなわち〔００ ０８
４０ ４０ ４０ ４４ ４４ ４０ ４０ ４０〕である。 前述の例から指摘された理由のために、発明の今の実施態様は、長さで４ピクセルより小さい水平ジャンプに対してデルタをエンコードしない。 しかし、図３のブロック３７０は、図９または図１４で定める手順に基づいて、デルタの最小値より大きいジャンプに対して、
デルタをエンコードしない。 ルーチンがピクセル・インフォーメーションをデルタすると、図３のブロック３７
０またはブロック３８０に依って、ルーチンは、コントロールを図４のブロック４０７にパスする。 前述のように、全てのデルタ・オフセットがゼロの時に、ブロック３６０は、コントロールを図４のブロック４０７に直接移す。 ブロック４０７はラン変数の長さを１に初期設定する。 ルーチンは、ラン変数の長さを用いて、ビデオ・
データの連続するピクセルの数をカウントするが、そこでは、そのカラーは内部フレーム許容値より大きくならない。 次に、ブロック４１０は、ルーチンが内部フレーム圧縮を用いてフレームを圧縮するかどうかについて決定する。 内部フレーム圧縮が有効な時に、ルーチンはコントロールをブロック４２０にパスする。 ブロック４２
０は、圧縮の決定を、ラン変数の長さの今の値とラインに残っている圧縮されていないピクセルの数に基づいて行う。 ランの長さの最小値は、絶対モードと逆に、ランの長さでピクセルのストリングを効果的にエンコードできるかどうかについて、ルーチンが決定するために用いるスレショルド値である。 ランの長さの最小値より小さいか等しい値の場合、絶対モード・エンコーディングからランの長さのエンコーディングに向けてブレークすることは、コスト経済的でない。 従って、小さいランの長さは前述の絶対値モード方法を用いてエンコードされる。 図９と１４（絶対モード・エンコーディングについて説明している）と前述のデルタの最小値の説明（同じ効率性）を参照すること。 代わりに、ランの長さの最小値より大きいランの長さの場合、ラン変数の長さに依って表されるピクセルをランの長さのエンコーディングとしてエンコードすると、コスト経済的になる。 図４のブロック４２０が（１）ラインに残っているピクセルの数にラン変数の長さの値をプラスした数値がランの長さの最小値より小さいか等しい或いは（２）ラインに残っているピクセルの数がゼロに等しい場合、ルーチンは、コントロールをブロック４６５に送る。 ブロック４６５はラン変数の長さの大きさを評価する。 ラン変数の長さがランの長さの最小値より大きいか等しい場合、ブロック４６５は、ピクセルをランの長さのエンコーディングとしてエンコードするブロック４６８にコントロールをパスする。 図９と１４（ランの長さのエンコーディングについて説明している）を参照すること。 ブロック４６８
は、このランの長さを状態の数でエンコードする。 ランの長さをエンコードする１つの方法が図９に図示されている。 この方法の場合、２つのバイトがランの長さのエンコーディングを意味するために用いられている。 １〜
２５５の範囲のプラスの値をもつ、第１バイトは、ランの長さの大きさを意味している。 ０〜２５５の範囲のプラスの値をもつ、第２バイトは、ピクセルのカラー・インデックスを意味している。 図１０（カラー・ルックアップ・テーブル）を参照すること。 別にランの長さをエンコードする技術が図１４に図示されている。 図１４の技術は、２つのバイトがランの長さを意味しているところが図９の技術と似ている。 第２の技術の場合、しかし、第１バイトは１５〜２５５だけの範囲しかもっていない。 この範囲の制限は、前述のように、数値１−１４
が水平デルタをエンコードするために確保されているので必要になる。 図１４の方法を用いると、ランの長さの大きさは１４をランの長さのエンコーディングの第１バイトから減算して求められる。 ランの長さのエンコーディングの第２バイトは、図９を用いて既に説明された同様の状態でピクセルのカラー・インデックスを意味している。 図解のために、ラン変数の長さが５の値をもち且つ今のフレームのピクセル・ポインタが（２５５，０，
０）のＲＧＢ値をもつピクセルを表していると想定してみる。 図１０のカラー・ルックアップ・テーブルに従って、これらのＲＧＢ値は４３のカラー・インデックスに依って表される。 図１０（カラー・ルックアップ・テーブル）を参照すること。 従って、図９のエンコーディング方法は、ランの長さをバイト・グループ〔０５ ４
３〕としてエンコードする。 すなわち、第１バイト（０
５）はランの長さの大きさであり、第２バイト（４３）
はピクセルのカラー・インデックスになる。 同様に、図１４のエンコーディング方法は、ランの長さをバイト・
グループ〔１９ ４３〕としてエンコードする。 すなわち、第１バイト（１９）はランの長さの大きさを（実際のランの長さの大きさは１４をこの値から減算して求められる）意味し、第２バイト（４３）はピクセルのカラー・インデックスになる。 図１０（カラー・ルックアップ・テーブル）を参照すること、これらの２つの技術の中の１つを用いて、ブロック４６８はランの長さのエンコーディングを作成する。 逆に、ラン変数の長さがランの長さの最小値より小さい時に、ブロック４６５はコントロールをブロック４６９にパスする。 ブロック４６９
は、絶対モード・エンコーディングを用いて、ピクセル・インフォーメーションを記号化する。 図９と１４（絶対モード・エンコーディングについて説明している）を参照すること。 ルーチンがピクセル・インフォーメーションをエンコードすると、図４のブロック４６８または４６９を経由して、ルーチンは、コントロールを図３のブロック３００に戻す。 一方、ブロック４２０は（１）
ラインに残っている圧縮されていないピクセルの数にラン変数の長さの値をプラスした数値がランの長さの最小値より大きくて且つ（２）ラインに残っている圧縮されていないピクセルの数がゼロと等しくないと決定すると、ブロック４２０はコントロールをブロック４２５にパスする。 ブロック４２５は、変動値＝（Ｒ２−Ｒ１）
２＋（Ｇ２−Ｇ１）２＋（Ｂ２−Ｂ１）２の関係式を用いて、次に内部フレームピクセル・ペアの変動値を計算する。 内部フレーム許容値が計算された変動値より大きいか等しい時に、ブロック４３０は、コントロールをブロック４５５にパスする。 ブロック４５５は、ラン変数の長さを増加して、コントロールをブロック４２０にリターンする。 ブロック４２０，４２５，４５５から形成されるプロセスは、（ａ）ブロック４３０が内部フレーム・ピクセル・ペアの変動値が内部フレーム許容値に入っていないと決定するまで、または（ｂ）ブロック４２
０が（１）ラインに残っている圧縮されていないピクセルの数にラン変数の長さの値をプラスした数値がランの長さの最小値より小さいか等しい或いは（２）ラインに残っている圧縮されていないピクセルの数がゼロに等しいと決定するまで、継続する。 ブロック４３０が内部フレーム許容値より大きい変動値を見いだすと、ルーチンはコントロールをブロック４３５にパスする。 ブロック４３５は、次に、指定されたランの長さの最小値に相応するラン変数の長さの値を調べる。 ラン変数の長さが指定されたランの長さの最小値より小さい時に、ルーチンはコントロールをブロック４３６にパスする。 順に、ブロック４３６は、絶対モードのピクセルを、前述の方式でエンコードする。 図９と１４（絶対モード・エンコーディングについて説明している）を参照すること。 代わりに、ラン変数の長さが指定されたランの長さの最小値より大きいか等しい時に、ルーチンはコントロールをブロック４３７にパスする。 次に、ブロック４３７は、ピクセルをランの長さのエンコーディング・バイト・グループとして（図９の方法または図１４の方法を用いて）
エンコードする。 ブロック４３６またはブロック４３７
が関連するピクセル・インフォーメーションをビデオ・
データの圧縮されたバージョンでエンコードすると、ルーチンはコントロールをブロック４３８に送る。 ブロック４３８は（１）ラン変数の長さをゼロにセットして（２）コントロールをブロック４４０に送る。 ブロック４４０は、前のフレームのピクセル・ポインタに搭載されているアドレスを、ランの変数の長さをそのアドレスに加えて更新する。 次に、ブロック４４０は、今のフレームのピクセル・ポインタを同じ形式で更新するブロック４４５にコントロールをパスする。 ルーチンはコントロールを図３のブロック３２０に送る。 ここで、ブロック３２０は、相互フレーム圧縮プロセスを、デルタ・オフセットをゼロにリセットして再開する。 ブロック３３
０が全ての内部フレーム・ピクセル・ペアを比較したと判断すると、それはコントロールをブロック３３１に送る。 順に、ブロック３３１，３３２，３３３は、ピクセル・インフォーメーションを前述のブロック３６５，３
７０，３８０と同じ方式でエンコードする方法を決定する。 ルーチンがピクセル・インフォーメーションをエンコードすると、ルーチンはコントロールを図３のブロック３００に戻す。 次に、ブロック３０５は図２のブロック２６０にリターンする。 内部フレーム圧縮 内部フレーム圧縮ルーチンのフロー・チャートが図５に図示されている。 ブロック２５０の図２（図５のルーチンをコールする）を参照すること。 内部フレーム圧縮ルーチンはブロック５００のプロセスから始める。 ブロック５００は、フレームにビデオ・データの任意に残っている圧縮されていないラインがあるかどうかについて決定する。 ルーチンがフレームの全てのラインを圧縮すると、ブロック５００はコントロールをブロック５０２に送る。 次に、ブロック５０２は、コントロールを図２のブロック２６０にリターンする。 一方、図５のブロック５００は、圧縮されていないビデオ・データの少なくとも１つの残っているラインがあると決定すると、ブロック５００は、コントロールをブロック５０５に送る。 ブロック５０５で、ルーチンは、今のピクセル・ポインタの内容を、圧縮されていない生のビデオ・データの次のラインの最初のピクセルのアドレスにセットする。 次に、ルーチンは、ラン変数の長さを１に初期設定する、
ブロック５１０にコントロールを送る。 前述のように、
ルーチンは、ラン変数の長さを用いて、内部フレーム許容値に入っている連続するピクセルの数を記録する。 次に、ブロック５１５は、（１）ラインに残っている圧縮されていないピクセルの数にラン変数の長さをプラスした値がランの長さの最小値より大きいかどうかについて、なおかつ、（２）ラインに残っている圧縮されていないピクセルの数がゼロでないかどうかについて決定する。 ブロック５１５の両方のテストが肯定的である場合に、ブロック５１５はコントロールをブロック５２０に送る。 順に、ブロック５２０は、（１）今のピクセル・
ポインタのアドレスと（２）今のピクセル・ポインタにラン変数の長さの値をプラスしたアドレスから表されるピクセルのペア変動値を計算する。 次に、ブロック５２
５は変動値を内部フレーム許容値に基づいて評価する。
内部フレーム許容値が変動値より大きいか等しい時に、
ブロック５２５は、コントロールをブロック５４０に送る。 ブロック５４０は、ラン変数の長さを増加して、コントロールをブロック５１５に戻す。 ブロック５１５，
５２０，５２５，５４０は、（１）ブロック５２５が、
変動値が内部フレーム許容値より大きいピクセルのペアを見いだすか、または（２）ブロック５２５が（ａ）ラインに残っている圧縮されていないピクセルの数にラン変数の長さの値をプラスした数値がランの長さの最小値より小さいか等しい或いは（ｂ）ラインに残っている圧縮されていないピクセルの数がゼロに等しいと決定するまで、内部フレーム・ピクセルのペアの比較を続ける。
ルーチンが、変動値が内部フレーム許容値より大きい、
ピクセルのペア発見すると、ブロック５２５はコントロールをブロック５３０に送る。 ブロック５３０は、ラン変数の長さが指定されたランの長さの最小値より大きいか等しい値をもつかどうかについて決定する。 前述のように、ランの長さの最小値は、絶対モードと逆のランの長さとしてピクセルのストリングをエンコードできるかどうかについて決定するために、ルーチンが使用するスレショルド値である（図４のブロック４６８に関する説明を参照）。 ブロック５３０が指定されたランの長さの最小値より大きいか等しいランの長さを発見すると、ブロック５３０は図９のランの長さのエンコード方法または図１４のランの長さのエンコード方法を用いて、ランの長さをエンコードするブロック５３１にコントロールを送る（図４のブロック４６８の説明で既に述べられた方法）。 一方、ブロック５３０がランの長さが指定されたランの長さの最小値より小さいことを発見すると、ブロック５３０はコントロールをブロック５３２に送る。
順に、ブロック５３２は、ピクセル・インフォーメーションを前述の方式の絶対モードでエンコードする。 図９
と１４（絶対モード・エンコーディングについて説明している）を参照すること。 ルーチンがピクセルをエンコードすると、ブロック５３１を経由するランの長さのエンコーディングに依って、またはブロック５３２を経由する絶対モードのエンコーディングに依って、ルーチンは、コントロールをブロック５３５に送る。 ブロック５
３５は、今のピクセル・ポインタを更新して、次の圧縮されていないピクセルを生のデータ・フレームで示す。
次に、ルーチンは、内部フレーム圧縮プロセスを、ラン変数の長さを１に初期設定して更新するブロック５１０
にコントロールをリターンする。 一方、ブロック５１５
が（１）ラインに残っている圧縮されていないピクセルの数にラン変数の長さの値をプラスした数値がランの長さの最小値より小さいか等しい或いは（２）ラインに残っている圧縮されていないピクセルの数がゼロに等しいと決定すると、ルーチンは、コントロールをブロック５
４５に送る。 ブロック５４５，４５６，４５７はピクセル・インフォーメーションを、前述のように、ブロック５３０，５３１，５３２と同じ方式でエンコードする。
ルーチンがピクセル・インフォーメーションをエンコードすると、それは、圧縮されていないデータの更なるラインをチェックするブロック５００にコントロールを戻す。 スプリット・フレーム・ルーチン スプリット・フレーム・ルーチンのフロー・ダイアグラムが図６に図示されている。 図１のブロック１５０（図６のルーチンをコール）を参照すること。 本質的に、図１のルーチンは、それがエンコードされるイメージの品質を不当に損ねずに、与えられたターゲット・レンジに相応してフレームを圧縮できない時に、すなわち、許容範囲を拡大するとルーチンに最小許容分解能レベルより低い圧縮されたフレームを生成させる場合に、このスプリット・フレーム・ルーチンをコールするだけである。
これらの状態の時に、発明の今の実施態様は生のデータを２つの部分に分割する。 いちど分割されると、生のデータの各々半分が分離して圧縮される。 スプリット・プロセスは、今のフレームの生のデータをテンプフレームにリネームするブロック６１０から始まる。 ブロック６
２０はテンプフレームのデータを半分に分割する。 次に、ブロック６３０は、“今のフレーム”のネームをテンプフレーム・データの上半分に再び指定する。 同様に、ブロック６４０は“次のフレーム”のネームをテンプフレーム・データの下半分に再び指定する。 ルーチンが今のフレームと次のフレームをこの形式で設定すると、ブロック６５０は、図１のブロック１１０にコントロールをリターンする。 圧縮解除方法 本発明の圧縮解除ルーチンのフロー・チャートが図７に図示されている。 本質的に、このルーチンは、図１−６
のルーチンに依って圧縮されるフレームをとり、それらを表示可能なフォーマットに拡大する。 圧縮解除プロセスは、ビデオ・ムービーの圧縮データを受け取るブロック７００から始まる。 次に、ブロック７１０は、ルーチンがビデオ・ムービーのエンコードされたフレームの全ての圧縮を解除したかどうかについて決定する。 少なくとも１つのフレームが圧縮された状態で残っている時に、ブロック７１０は、圧縮されたフレームを検索するブロック７２０にコントロールを送る。 次に、ブロック７３０は、実際にフレームの圧縮を解除するサブルーチンをコールする。 順に、ブロック７４０は、最後に圧縮されたフレームが単純に生のデータ・フレームの上半分であったかどうかについて決定する。 最後に圧縮を解除されたフレームが生のデータ・フレームの上半分だけだった場合、ルーチンは、それがフレームの下半分の圧縮を解除するまで、圧縮を解除されたデータの表示を遅延する。 ブロック７４０は、コントロールをディスプレイ・ブロック７５０の代わりにブロック７２０に送って、
この遅延を行う。 次に、ブロック７２０はスプリッド・
フレームの下半分を検索する。 ブロック７３０は、生のデータ・フレームの下半分の圧縮を解除する、圧縮解除フレーム・サブルーチンをコールする。 ブロック７３０
のサブルーチンがリターンすると、ブロック７５０はフレームを例えばビデオ・モニターの上に表示する。 ブロック７５０がフレームを表示した後に、それはコントロールをブロック７１０にリターンする。 このようにして、ルーチンは、圧縮を解除して、ムービーのフレームの全てを表示する。 ルーチンが全体のムービーを表示すると、ブロック７６０は、圧縮解除ルーチンをコールしていたアプリケーションにリターンする。 圧縮解除フレーム・ルーチン 圧縮解除フレーム・ルーチンのフロー・チャートが図８
に図示されている。 図７のブロック７３０（図８のルーチンをコールする）を参照すること。 圧縮解除フレーム・ルーチンのプロセスはブロック８１０から始まる。 ブロック８１０で、ルーチンは、バイト・グループを圧縮を解除されたビデオ・データから検索する。 次に、ブロック８１５は、バイト・グループをテストして、それがビットマップ・エンコーディングの最後であるかどうかについて確認する。 ブロック８１５がバイト・グループがビットマップ・エンコーディングの最後であると決定すると、ルーチンはコントロールをブロック８４０にパスする。 ビットマップの最後はフレームに関して圧縮されたデータの最後を示すので、ブロック８４０は、図７
のブロック７４０にリターンする。 しかし、ユニットがビットマップ・エンコーディングの最後でない時に、ブロック８１５は、コントロールをブロック８２０に送る。 ブロック８２０が、バイト・グループがライン・エンコーディングの最後であると決定すると、ルーチンは、コントロールをブロック８４５に送る。 順に、ブロック８４５は、ブラッシュをビデオ・データの圧縮を解除されたバージョンの次のラインに移す。 ブロック８４
５がブラッシュを移すと、ルーチンはコントロールをブロック８１０に送る。 一方、バイト・グループがライン・エンコーディングの最後でない時に、ブロック８２０
は、コントロールをブロック８２５に送る。 ブロック８
２５がバイト・グループがデルタ・エンコーディングであると決定すると、ルーチンはブロック８５０に移る。
順に、ブロック８５０は、ブラッシュをデルタ・オフセットに依って指示されるロケーションに移す。 例えば、
デルタは５の水平オフセットとゼロの垂直オフセットをエンコードしていたかも知れない。 このケースで、ルーチンは、ブラッシュを５ピクセル、その今のポジションから水平に移動する。 ブロック８５０がブラッシュを移すと、ルーチンは、コントロールをブロック８１０に送る。 代わりに、バイト・グループがデルタ・エンコーディングでない時に、ブロック８２５はコントロールをブロック８３０に送る。 ブロック８３０がバイト・グループがランの長さのエンコーディングであると決定すると、ブロック８３０はコントロールをブロック８５５に送る。 ブロック８５５は、次に使用できるピクセルを圧縮を解除されたデータで着色して、コントロールをブロック８６０に送る。 ブロック８６０は、ランの長さの残りの大きさを減少して、コントロールをブロック８６５
に送る。 次に、ブロック８６５は、ランの長さの残っている大きさについてヌル値をテストする。 ランの長さの残っている大きさがヌル値である時に、ルーチンはランの全てのピクセルに着色して、ブロック８６５はコントロールをブロック８１０に送る。 一方、ランの長さの残っている大きさがゼロでない時に、ブロック８６５はコントロールをブロック８５５に戻す。 このようにして、
ブロック８５５，８６０，８６５は、エンコードされたランの長さと関連するカラーの値から指示される全てのピクセルに着色する。 バイト・グループがランの長さのエンコーディングでない時に、ブロック８３０はコントロールをブロック８８０に移す。 ブロック８８０が、バイト・グループが絶対モード・エンコーディングであると決定すると、ブロック８８０はコントロールをブロック８８５に移す。 ブロック８８５は、次のカラー・インデックスを絶対モード・エンコーディングから検索して、次に使用できるピクセルを圧縮を解除されたデータで、コントロールをブロック８９０に移す前に着色する。 順に、ブロック８９０は、絶対モードでエンコードされたピクセルの残っている数を示すバイトを値を減算して、コントロールをブロック８６５に移す。 図９と１
４（絶対モード・エンコーディングについて説明している）を参照すること。 次に、図８のブロック８６５は減算されたバイトの値についてヌル値をテストする。 絶対モードでエンコードされたピクセルの残っている数を示すバイトの値がゼロの時に、ルーチンは、絶対エンコード・ピクセルの全てに着色する。 そこで、ブロック８９
５は、コントロールをブロック８１０にリターンする。
一方、絶対モードでエンコードされたピクセルの残っている数を示すバイトの値がゼロでない時に、ブロック８
９５は、コントロールをブロック８８５に戻す。 このようにして、ブロック８８５，８９０，８９５は、バイト・グループに依って指示された全ての絶対エンコード・
ピクセルに着色する。 最後に、ブロック８８０がバイト・グループを絶対エンコーディングとして認識しない時に、ルーチンは、コントロールをブロック８１０に移すことに依って、データを無視する。 圧縮フレーム 図１１と１２は、例を用いて、ビデオ・ムービーの発明の圧縮を示している。 例について、次に詳細にわたって説明される。 しかし、読者の便宜を考えて、次に示す例の概略的な説明が用意されている。 簡潔にするために、
例のムービーは僅か２つのフレームの長さであり、なおかつ、各々フレームはシングルの１０のピクセル・ラインに組み込まれている。 図１１を参照すること（ブロック１１００と１１２５は、２つのフレーム・ムービーの、各々、フレームｎとｎ＋１に対して生のビデオ・データを示している）。 更に、発明は、圧縮されるデータのために６−１１バイトを包含するターゲット・レンジを使用している。 圧縮されたデータをエンコードする時に、発明は、図１０のカラー・ルックアップ・テーブルを使用して、圧縮されたデータが（１）図９のエンコーディング技術と（２）図１４のエンコーディング技術の両方から表示される様子を示している。 図１４の優れた特性は、２つのエンコーディング技術の結果を対比することに依って明らかになる。 その今の実施態様に於いて、発明は、ビデオ・データのフレームをロストレスでエンコードすることを試みて、例えば、ゼロの内部フレームと相互フレームの許容値を用いて開始する。 発明がロストレスでフレームをターゲット・レンジにエンコードできない場合、発明は、いま圧縮されているフレームの前のフレームに対してターゲット・レンジで圧縮を行った許容値を用いて圧縮する、すなわち、発明が今フレーム“ｎ”を圧縮していた場合、発明は、フレーム“ｎ
−１”の最終許容値を用いて、圧縮を始めると思われる。前述の許容値でフレーム“ｎ”を与えられたターゲット・レンジに圧縮できない場合、今の実施態様は、最大許容値を用いてフレームを圧縮する。発明は、時間を節約するために、すなわち、フレームが分割されなければならないかどうかについて瞬時に決定するために、これを行う。ユーザがフレームの分割を希望していないので、使用可能な最大許容値がない場合、発明は、前述の第１推定値、すなわち、内部フレーム許容値に対して２
５０の第１推定値と相互フレーム許容値に対して２００
０の第１推定値を用いて、フレームの圧縮を試みる。 簡潔にするため、この例は最大許容値を使用する圧縮について説明しない。 代わりに、発明は、まず、ロストレス・エンコーディング、すなわち、ゼロの許容値を、フレームｎに対してだけ試みる。 次に、この例は、第１推定値、すなわち、２５０の内部フレーム許容値を用いて、
フレームｎの圧縮を試みる。 フレームｎ＋１を圧縮している時に、この例は、フレームｎのために作動していた内部フレーム許容値から誘導された許容値を使用して、
圧縮を開始する。 更に、この例は、１，５００が最大内部フレーム許容値であると想定している。 圧縮の例は、
フレームｎのロストレスのランの長さのエンコーディング（図１１のブロック１１００）から始まる。 発明は、
ゼロの内部フレーム許容値を用いてフレームｎのデータをロストレスでエンコードする。 しかし、このケースで、発明は、フレームｎを６−１１バイトのターゲット・レンジにロストレスで圧縮できない。 フレームｎの圧縮されたバージョンをターゲット・レンジで行うとする時に、発明は、２５０の内部フレーム許容値を用いてフレームを再び圧縮する（前述のように、２５０は実験から適切な初期の内部フレーム許容値であると決定されている）。 ２５０の許容値で用いて、発明は、フレームｎ、ブロック１１００を、ターゲット・レンジで圧縮する。 例はフレームｎ＋１（図１２のブロック１１２５）
の圧縮を続ける。 発明は、２５０の内部フレーム許容値と２，０００の相互フレーム許容値を用いて、フレームｎ＋１を圧縮する。 発明は、その数値がフレームｎの圧縮で巧みに作動していたので、２５０を内部フレーム許容値として使用することを続ける（フレームｎ＋１はフレームｎと類似していると思われる）。 発明は、２，０
００の相互フレーム許容値を用いて、相互フレーム圧縮を開始する、何故ならば、前述のように、内部フレーム許容値の値の８倍の相互フレーム許容値は適切であったと発見手法的に決定されていたからである。 これらの２
つの許容値と図９のエンコード方法を用いて、発明は、
フレームｎ＋１、図１２のブロック１１２５を、ターゲット・レンジで圧縮する。 図１２、ブロック１２１０を参照すること。 しかし、これらの同じ２つの許容値を用いて、図１４のエンコード方法は、フレームｎ＋１、ブロック１１２５を、ターゲット・レンジのフロアより低く、すなわち６バイト未満に圧縮する。 図１２、ブロック１２２０を参照すること。 その結果、発明は、相互フレーム許容値を１０００に（前述の修正されたバイナリ・サーチを用いて）減少して、フレームｎ＋１を再び圧縮する。 新しい相互フレーム許容値と図１４のエンコード方法を用いると、発明は、フレームをターゲット・レンジで圧縮することができる。 更に、発明は、フレームｎ＋１を図９のエンコード方法より図１４のエンコード方法を用いて圧縮すると、より多くのインフォーメーションをエンコードすることができる。 図１２のブロック１２１０と１２３０を比較してみること。 その例について、ここで詳細にわたって説明される。 図１と１１の両方を見ると、圧縮プロセスは図１のブロック１００から始まっている。 図１のブロック１００は、ムービーの生のビデオ・データ（図１１のブロック１１００と１１２
５）を受け取る。 次に、図１のブロック１００は、図１
のブロック１１００を次の生のデータ・フレームと判定して圧縮する。 その結果、図１のブロック１００は、図２の圧縮フレーム・ルーチンをコールするブロック１１
０にコントロールを送る。 順に、図２のブロック２００
は、図１１のブロック１１００が圧縮されたビデオ・ムービーの第１フレームであることを発見する。 そこで、
図２のブロック２００はコントロールをブロック２５０
に移す。 ブロック２５０は図５の内部フレーム圧縮ルーチンをコールする。 前半の注記事項で説明されたように、発明は、生のデータをターゲット・レンジでロストレスでエンコードすることを試みて、すなわち、ランの長さのエンコーディングをゼロの内部フレーム許容値で使用して、内部フレーム圧縮プロセスを開始する。 まず、図５のブロック５００は図１１のブロック１１００
がビデオ・データの圧縮されていないラインであることを決定すると、次に図５のブロック５０５はコントロールをブロック５１０に移す。 順に、ブロック５０５は、
今のピクセル・ポインタの内容を図１１のブロック１１
００のピクセル１１０１のアドレスにセットして、ラインのロストレスの圧縮を開始する。 次に、図５のブロック５１０は、ラン変数の長さを１に初期設定して、コントロールをブロック５１５にパスする。 ブロック５１５
は、（１）ラインに残っている圧縮されていないピクセルの数にラン変数の長さの値をプラスした数値がランの長さの最小値より大きいか、または（２）ラインに残っている圧縮されていないピクセルの数がゼロに等しいかどうかについて決定する。 このケースで、ラインに残っている圧縮されていないピクセルの数（１０）にラン変数の長さの値（１）をプラスした数値は、ランの長さの最小値（４）より大きくなる。 その結果、ブロック５１
５はコントロールをブロック５２０に移す。 順に、ブロック５２０は、変動値を図１１のピクセル１１０１と１
１０２のカラー属性に基づいて計算する（（１）今のピクセル・ポインタの内容と（２）今のピクセル・ポインタの内容にラン変数の長さをプラスした数値に依って表されるピクセル）。 この実施態様で、発明は２つのピクセルの各々カラー要素の差の平方を合計して変動値を計算する、すなわち、変動値＝（２５５−２５５）２＋
（０−０）２＋（０−０）２＝０になる。 この場合、ゼロの変動値は内部フレーム許容値と等しくなる。 そこで、図５のブロック５２５はコントロールをブロック５
４０に移す。 順に、ブロック５４０は、ラン変数の長さを増加して、コントロールをブロック５１５にリターンする。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（８）にラン変数の長さの値（２）をプラスした数値がランの長さの最小値（４）より大きいかどうかについて決定し、なおかつ、その結果、ブロック５１５はコントロールをブロック５２０に移す。 ブロック５２０は図１１のピクセル１１０１と１
１０３の変動値を計算する。 やはり、この値はゼロになる（０＝（２５５−２５５）２＋（０−０）２＋（０−
０）２）。 次に、図５のブロック５２５は、コントロールをブロック５１５にパスする前に、ラン変数の長さを３に増加する、ブロック５４０にコントロールをパスする。 再び、ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（７）にラン変数の長さの値をプラスした数値（３）がランの長さの最小値（４）より大きいかどうかについて決定する。 この判定に対応して、ブロック５１５は、コントロールをブロック５２０
にパスする。 ブロック５２０は、図１１のピクセル１１
０１と１１０４の変動値を計算する。 このケースで、計算された変動値はゼロになる、すなわち（０＝（２５５
−２５５）２＋（０−０）２＋（０−０）２）。 ペアの変動値は内部フレーム許容値より大きくないので、図５
のブロック５２５は再びコントロールをブロック５４０
にパスする。 順に、ブロック５４０はラン変数の長さを４に増加する。 次に、ブロック５４０はコントロールをブロック５１５にパスする。 ラインに残っている圧縮されていないピクセルの数（６）にラン変数の長さの値をプラスした数値（４）は、ランの長さの最小値（４）より大きいので、ブロック５１５は、コントロールをブロック５２０にパスする。 順に、ブロック５２０は、図１
１のピクセル１１０１と１１０５の変動値を計算する。
その値は、６２，３７７になる。 すなわち、（６２，３
７７＝（１７８−２５５）２＋（１６８−０）２＋（１
６８−０）２）。 この値はゼロの内部フレーム許容値より□かに大きいので、図５のブロック５２５はコントロールをブロック５３０に送る。 ブロック５３０はラン変数の長さの大きさを調べる。 このケースで、ラン変数の長さは、ランの長さの最小値に等しい値（４の値）をもつ。 そこで、ブロック５３０はコントロールをブロック５３１に送る。 ブロック５３１は図１１のピクセル１１
０１，１１０２，１１０３，１１０４をランの長さのエンコーディングとしてエンコードする。 図９と１４は、
ランの長さのエンコーディングを生成できる２つの可能性のある方法を示している。 完璧にするために、この例は両方の方法を示している。 図１１のブロック１１４
０，１１５０，１１６０と図１２のブロック１２１０は図９のエンコード方法を使用しているが、図１１のブロック１１７０，１１８０，１１９０と図２１のブロック１２２０，１２３０，１２４０は図１４のエンコード方法を使用している。 通常の条件のもとで、しかし、１つのエンコード方法だけアプリケーションで用いられると思われる。 図１１のブロック１１４０は、図９に依って開示されるエンコード方法を用いて生成される、ブロック１１００のロストレスで圧縮されたデータの部分的なエンコードである。 図１１のブロック１１４０の内部のバイト・グループ１１４１は、ピクセル１１０１，１１
０２，１１０３，１１０４のランの長さのエンコーディングである。 このグループの第１バイト（０４）はランの長さの大きさになる。 このグループの第２バイト（４
３）は、（２５５，０，０）のＲＧＢカラー値のために、図１０のカラー・ルックアップ・テーブルから導かれるカラー・インデックスである。 同様に、図１１のブロック１１７０は、図１４に依って開示されるエンコード方法を用いて、生成されるブロック１１００のロストレスで圧縮されたデータの部分的なエンコードである。
図１１のブロック１１８０の内部のバイト・グループ１
１７１は、ピクセル１１０１，１１０２，１１０３，１
１０４のランの長さのエンコーディングである。 このグループの第１バイト（１８）は、ランの長さの大きさに比例する。 ランの長さの実際の大きさは、１４をバイトから減算して求められる。 このグループの第２バイト（４３）は、ピクセル１１０１，１１０２，１１０３，
１１０４のカラー・インデックスである。 図１０（カラー・ルックアップ・テーブル）を参照すること。 図５のブロック５３１がランの長さをエンコードすると、ブロック５３５は、今のピクセル・ポインタの内容を更新して、発明が調べた最後のピクセル、このケースでは、図１１のピクセル１１０５を示す。 図５のブロック５３５
がポインタで更新すると、それは、ラン変数の長さを１
に再び初期設定するブロック５１０にコントロールをリターンする。 次に、ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（６）にラン変数の長さ（１）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 その結果、ブロック５１５はコントロールをブロック５２０にパスする。 ブロック５２０は図１１のピクセル１１０５と１１０６の変動値を計算する。 このケースで、変動値は１００になる〔１００＝（１６８−１７８）２＋（１６８−１６
８）２＋（１６８−１６８）２〕。 １００はゼロの内部フレーム許容値より大きいので、ブロック５２５は、コントロールをブロック５３０に送る。 順に、ブロック５
３０は、ラン変数の長さ（１）がランの長さの最小値（４）より小さいことを決定して、コントロールをブロック５３２に送る。 ブロック５３２はピクセル・インフォーメーションを絶対モードでエンコードする。 効率的にするために、絶対モード・エンコーディングは、３つのピクセルの中の最小値を記号化する、すなわち、絶対モード・エスケープ・シーケンスそのものは２つのバイトを続けるので、３つのバイトをエンコードして、１つのピクセルをエンコードすることは無駄と考えられるからである。 更に、エスケープ・シーケンス〔００ ０
１〕と〔００ ０２〕、１と２のバイトの絶対モード・
エンコーディングのためのロジカル・エスケープ・シーケンスは、ビットマップとデルタ・エンコーディングに対して既に用いられている。 図９と１４（絶対とビットマップの最後とデルタ・エンコーディングについて説明している）を参照すること。 これらの効率性の問題のために、発明は、図９の方法を用いて、図１１とピクセル１１０５，１１０６，１１０７を、ブロック１１４０の１１４２のバイト・グループとしてエンコードする。 同様に、図１４の方法を用いて、発明は、図１１のピクセル１１０５，１１０６，１１０７を、ブロック１１７０
のバイト・グループ１１７２としてエンコードする。 図９と図１４の絶対エンコード方法は同じなので、図１１
のバイト・グループ１１４２と１１７２も同じになる。
各々グループの最初の２つのバイト（００ ０３）は、
次の３つのバイト（４８，４２，４２）を、絶対エンコード・ピクセルとして識別する。 （４８）と（４２）
は、各々（１７８，１６８，１６８）と（１６８，１６
８，１６８）のＲＧＢ値のカラー・インデックスになる。 図１０（カラー・ルックアップ・テーブル）を参照すること。 図５のブロック５３２が図１１のピクセル１
１０５，１１０６，１１０７をエンコードすると、図５
のブロック５３２は、コントロールをブロック５３５にパスする。 順に、ブロック５３５は、今のピクセル・ポインタの内容を更新して、調査される次のピクセル、すなわち図１１のピクセル１１０８を示す。 次に、図５のブロック５３５はコントロールをブロック５１０にパスする。 ブロック５１０は、ラン変数の長さを１に再び初期設定して、コントロールをブロック５１５にパスする。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（３）にラン変数の長さの値（１）
をプラスした数値がランの長さの最小値（４）より大きくないと決定する、するとブロック５１５は、次にコントロールをブロック５４５にパスする。 ブロック５４５
は、ラン変数の長さの値がランの長さの最小値より小さいことを発見して、コントロールをブロック５４７にパスする。 順に、ブロック５４７は、ラインの残っているピクセル、すなわち、図１１のブロック１１００のピクセル１１０８，１１０９，１１１０を絶対モードでエンコードする。 効率的にするために、図５のブロック５４
７は、既に絶対モードでエンコードされていたピクセル、すなわち、図１１のブロック１１００のピクセル１
１０５，１１０６，１１０７（各々、ブロック１１４０
と１１７０のバイト・グループ１１４２と１１７２に既にエンコードされていたピクセル１１０５，１１０６，
１１０７）と、それらを組み合わせて、これらのピクセルをエンコードする。 その結果、ピクセル１１０５，１
１０６，１１０７，１１０８，１１０９，１１１０はシングル・バイト・グループに依って表される。 図９の方法を用いて、図１１のブロック１１５０のバイト・グループ１１５２は、これらのピクセルを示している。 同様に、図１４の方法を用いて、ブロック１１８０のバイト・グループ１１８２は、これらのピクセルを示している。 前述のように、絶対エンコードの場合、図９と１４
に依って表される方法は同じである。 従って、図１１のバイト・グループ１１５２と１１８２は同じである。 各々グループの最初の２つのバイト（００ ０６）は、次の６バイト（４８，４２，４２，４８，４２，４２）を絶対エンコード・ピクセルと識別する。 （４８）と（４
２）は、各々（１７８，１６８，１６８）と（１６８，
１６８，１６８）のＲＧＢ値のカラー・インデックスになる。 図１０（カラー・ルックアップ・テーブル）を参照すること。 図５のブロック５４７がこれらのピクセルをエンコードした後に、ブロック５４７は、ビットマップ・エスケープ・コードの最後をエンコードして、フレームの最後を送る（ブロック１１５０のバイト・グループ１１５３とブロック１１８０のバイト・グループ１１
８３）。 このエンコーディングは、図９と１４に依って明瞭に説明される。 図５のブロック５４７がビットマップ・バイト・グループの最後をエンコードすると、図１
１のブロック１１００のデータのロストレスの圧縮は完璧になる。 次に、図５のブロック５００は、（１）圧縮されていないビデオ・データのラインが図１１のブロック１１００にないことを認めて、（２）コントロールを図５の５０２に送る。 順に、ブロック５０２はコントロールを図２のブロック２６０にリターンする。 このポイントから、ブロック２６０は、コントロールを図１のブロック１２０にリターンする。 ブロック１２０は、ロストレスでエンコードされて圧縮されたデータのサイズを調べる「図１１のブロック１１５０（図９の方法を用いて圧縮）と図１１のブロック１１８０（図１４の方法を用いて圧縮）」。 このケースで、図１のブロック１２０
は、図１１の両方のブロック１１５０と１１８０が、各々１２バイトのデータを搭載していて、ターゲット・レンジの上限（上限は１１バイトに等しい）より大きいと決定する。 その結果、ブロック１２０は、コントロールをブロック１３０にパスする。 ブロック１３０は、フレームが分割されるべきかどうかについて決定する。 最初に用いられた内部フレーム許容値がゼロであり且つ１５
００の最大内部フレーム許容値より大きくなかったので、ブロック１３０は、コントロールをブロック１４０
にパスする。 順に、ブロック１４０は、内部フレーム許容値を２５０に増加して、コントロールをブロック１１
０にパスする（前述のように、２５０は実験に依って内部フレーム許容値に適した第１推定値と決定されていた）。 順に、ブロック１１０は、図２の圧縮フレーム・
ルーチンをコールする。 図２のブロック２００は、図１
１のブロック１１００がムービーの最初のフレームであることを決定して、コントロールを図２のブロック２５
０にパスする。 ブロック２５０がコントロールをもつと、それは図５の内部フレーム圧縮ルーチンをコールする。 もう一度、図５のブロック５００は、（１）図１１
のブロック１１００がビデオ・データの圧縮されていないラインであることを決定して、（２）コントロールを図５のブロック５０５に送る。 ブロック５０５は、今のピクセル・ポインタの内容を図１１のブロック１１００
のピクセル１１０１のアドレスにセットする。 次に、図５のブロック５１０は、ラン変数の長さを１に初期設定して、コントロールをブロック５１５にパスする。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（１０）にラン変数の長さの値（１）をプラスした数値がランの長さの最小値（４）より大きいと決定すると、コントロールをブロック５２０にパスする。
順に、ブロック５２０は、変動値を図１１のピクセル１
１０１と１１０２のカラー属性に基づいて計算して、コントロールを図５のブロック５２５にパスする。 このケースで、ピクセルの変動値はゼロ〔０ー（２５５−２５
５）２＋（０−０）２＋（０−０）２〕になるので、２
５０の内部フレーム許容値より小さくなる。 そこで、ブロック５２５はコントロールをブロック５４０に送る。
順に、ブロック５４０は、ラン変数の長さを２に増加して、コントロールをブロック５１５にリターンする。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（８）にラン変数の長さの値（２）をプラスした数値がランの長さの最小値（４）より大きいと決定すると、その結果、ブロック５１５はコントロールをブロック５２０にパスする。 ブロック５２０は図１１のピクセル１１０１と１１０３の変動値を計算する。 再び、この値はゼロ〔０＝（２５５−２５５）２＋（０−
０）２＋（０−０）２〕になる。 図５のブロック５２５
は、計算された変動値が内部フレーム許容値より小さいことを認めて、コントロールをブロック５４０にパスする。 順に、ブロック５４０はラン変数の長さを３に増加する。 再び、ブロック５２５は、ラインに残っている圧縮されていないピクセルの数（７）にラン変数の長さの値（３）をプラスした数値がランの長さの最小値（４）
より大きいことを決定すると、次に、ブロック５１５はコントロールをブロック５２０にパスする。 順に、ブロック５２０は、図１１のピクセル１１０１と１１０４の変動値を計算する。 計算された変動値はゼロ〔０＝（２
５５−２５５）２＋（０−０）２＋（０−０）２〕になる。 ペアの変動値は内部フレーム許容値より大きくないので、図５のブロック５２５は、再び、コントロールをブロック５４０にパスする。 順に、ブロック５４０は、
コントロールをブロック５１５にパスする前に、ラン変数の長さを４に増加する。 ラインに残っている圧縮されていないピクセルの数（６）にラン変数の長さの値をプラスした数値（４）は、ランの長さの最小値（４）より大きいので、ブロック５１５は、コントロールをブロック５２０にパスする。 順に、ブロック５２０は、図１１
のピクセル１１０１と１１０５の変動値を計算するが、
このケースで、その値は６２，３７７になる、すなわち、（６２，３７７＝（１７８−２５５）２＋（１６８
−０）２＋（１６８−０）２）。 この値は２５０の内部フレーム許容値より□かに大きいので、図５のブロック５２５はコントロールをブロック５３０に送る。 ブロック５３０はラン変数の長さの大きさを調べる。 このケースで、ラン変数の長さは、ランの長さの最小値に等しい値（４の値）をもつ。 そこで、ブロック５３０はコントロールをブロック５３１に送る。 ブロック５３１はピクセル１１０１，１１０２，１１０３，１１０４をブロック１１６０と１１９０のランの長さのエンコーディングとしてエンコードする。 ブロック１１６０は（１）２５
０の内部フレーム許容値と（２）図９のエンコード方法で生成されたブロック１１００の圧縮されたデータである。 図１１のブロック１１６０の内部のバイト・グループ１１６１は、ピクセル１１０１，１１０２，１１０
３，１１０４をランの長さのエンコーディングとして表している。 前述のように、このグループの第１バイト（０４）はランの長さの大きさであり、第２バイト（４
３）は図１０のカラー・ルックアップ・テーブルから導かれるピクセルのカラー・インデックスである。 同様に、図１１のブロック１１９０は（１）２５０の内部フレーム許容値と（２）図１４のエンコード方法で生成されたブロック１１００のデータである。 図１１のブロック１１９０の内部のバイト・グループ１１９１は、ピクセル１１０１，１１０２，１１０３，１１０４をランの長さのエンコーディングとして表している。 ブロック１
１７０に対して既に説明されたように、このグループの第１バイト（１８）は、ランの長さの大きさに比例する（ランの長さの実際の大きさは１４をバイトから減算して求められる）。 このグループの第２バイト（４３）はピクセルのカラー・インデックスである。 図１０（カラー・ルックアップ・テーブル）を参照すること。 図５のブロック５３１がランの長さをエンコードすると、ブロック５３５は、今のピクセル・ポインタの内容を更新して、発明が調べた最後のピクセル、すなわち、図１１のピクセル１１０５を示す。 図５のブロック５３５がポインタを更新した後に、ルーチンは、ラン変数の長さを１
に再び初期設定するブロック５１０に、コントロールをリターンする。 次に、ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（６）にラン変数の長さ（１）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 その結果、ブロック５１５は、コントロールをブロック５２０にパスする。
ブロック５２０は、図１１のピクセル１１０５と１１０
６の変動値を計算する。 このケースで、変動値は１００
（１００＝（１６８−１７８）２＋（１６８−１６８）
２＋（１６８−１６８）２）になる。 前に行われたロストレスの圧縮と対照的に、この変動値は、もはや内部フレーム許容値より大きくない（内部フレーム許容値はゼロから２５０に図１のブロック１４０に依って増加していた）。 その結果、図５のブロック５２５は、コントロールをブロック５１５に送る前に、ラン変数の長さを２
に増加する、ブロック５４０にコントロールを送る。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（４）にラン変数の長さの値（２）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 その結果、ブロック５１５は、コントロールをブロック５２０にパスする。 順に、ブロック５２０
は、図１１のピクセル１１０５と１１０７の変動値を計算する。 やはり、変動値は１００（１００＝（１６８−
１７８）２＋（１６８−１６８）２＋（１６８−１６
８）２）になる。 １００は２５０の内部フレーム許容値より小さいので、図５のブロック５２５は、（１）ラン変数の長さを３に増加して、（２）コントロールをブロック５１５にパスする、ブロック５４０にコントロールを送る。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（３）にラン変数の長さの値（３）をプラスした数値がランの長さの最小値（４）より大きいことを決定すると、コントロールをブロック５
２０にパスする。 ブロック５２０は図１１のピクセル１
１０５と１１０８の変動値を計算する。 このケースで、
変動値はゼロになる、すなわち（０＝（１７８−１７
８）２＋（１６８−１６８）２＋（１６８−１６８）
２）である。 ゼロは２５０の内部フレーム許容値より小さいので、図５のブロック５２５は、（１）ラン変数の長さを４に増加して、コントロールをブロック５１５にパスする、ブロック５４０にコントロールを送る。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（２）にラン変数の長さの値（４）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 そこで、ルーチンは、コントロールをブロック５２０にパスする。 順に、ブロック５２０は、図１１
のピクセル１１０５と１１０９の変動値を計算する。 このケースで、変動値は１００（１００＝（１６８−１７
８）２）＋（１６８−１６８）２＋（１６８−１６８）
２）になる。 １００は２５０の内部フレーム許容値より小さいので、図５のブロック５２５は、（１）ラン変数の長さを５に増加して、コントロールをブロック５１５
にパスする、ブロック５４０にコントロールを送る。 ブロック５１５は、ラインに残っている圧縮されていないピクセルの数（１）にラン変数の長さの値（５）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 この決定に対応して、ルーチンはコントロールをブロック５２０にパスする。 ブロック５２０がコントロールをもつと、それは、図１１のピクセル１１０
５と１１１０の変動値を計算する。 このケースで、変動値は１００になる、すなわち、（０＝（１６８−１７
８）２＋（１６８−１６８）２＋（１６８−１６８）
２）になる。 １００は２５０の内部フレーム許容値より小さいので、図５のブロック５２５は、（１）ラン変数の長さを６に増加して、コントロールをブロック５１５
にパスするブロック５４０にコントロールを送る。 ここで、ブロック５１５は、ラインに残っている圧縮されていないピクセルの数がゼロであることを決定して、コントロールをブロック５４５にパスする。 順に、ブロック５４５は、ラン変数の長さの値（６）がランの長さの最小値（４）より大きいことを発見して、コントロールをブロック５４６にパスする。 その結果、ブロック５４６
は、図１１のピクセル１１０５，１１０６，１１０７，
１１０８，１１０９，１１１０を、ランの長さのエンコーディングとしてエンコードする。 このランの長さのエンコーディングは（１）図１１のブロック１１６０のバイト・グループ１１６２と（２）図１１のブロック１１
９０のバイト・グループ１１９２に依って表される（前述のように、ブロック１１６０は図９のエンコード方法を示し、ブロック１１９０は図１４のエンコード方法を示している）。 図１１のバイト・グループ１１６２に関して、グループの第１のバイト（０６）はランの長さの大きさである。 グループの第２バイト（４８）は（２５
５，０，０）のＲＧＢカラー値のカラー・インデックスでる。 図１０（カラー・ルックアップ・テーブル）を参照すること。 同様に、図１１のバイト・グループ１１９
２に関して、グループの第１バイト（２０）はランの長さの大きさに比例する。 ランの長さの実際の大きさは１
４をバイトから減算して求められる。 バイト・グループ１１６２の第２バイトと同様に、バイト・グループ１１
９２の第２バイト（４８）は（２５５，０，０）のＲＧ
Ｂカラー値のカラー・インデックスである。 図１０（カラー・ルックアップ・テーブル）を参照すること。 図５
のブロック５４６が図１１のピクセル１１０５，１１０
６，１１０７，１１０８，１１０９，１１１０をランの長さのエンコーディングとしてエンコードした後に、図５のブロック５４６は、ビットマップ・エスケープ・コードの最後をエンコードする（ブロック１１６０のバイト・グループ１１６３とブロック１１９０のバイト・グループ１１９３）。 ビットマップ・エンコーディングの最後は図９と１４から明瞭に説明される。 図５のブロック５４６がこれらの最後の２つのバイト・グループをエンコードすると、ブロック５００はコントロールをブロック５０２に送る。 次に、ブロック５０２はコントロールを図２のブロック２６０にリターンする。 このポイントから、ブロック２６０はコントロールを図１のブロック１２０にリターンする。 ブロック１２０は、圧縮されたデータのサイズ（図１１のブロック１１６０（図９の方法を用いて圧縮）と図１１のブロック１１９０（図１
４の方法を用いて圧縮））を調べる。 このケースで、図１のブロック１２０は、図１１のブロック１１５０と１
１８０の両方が、各々６バイトのデータを搭載していて、６−１１バイトのターゲット・レンジに入っていることを決定する。 その結果、図１のブロック１２０はコントロールをブロック１０５に送る。 順に、図１のブロック１０５は、図１２のブロック１１２５を、圧縮に必要な生のデータのフレームとして認識する。 そこで、ブロック１１０は、図２の圧縮フレーム・ルーチンをコールする。 図２の圧縮フレーム・ルーチンは、ブロック２
００，２１０，２３０に依って図示されているように、
データに関するシリーズのテストを行う。 図１２のブロック１１２５のデータはムービーの最初のフレームでないので、ブロック２００はコントロールをブロック２１
０に送る。 この例は、図１の圧縮方法をコールするアプリケーション・プログラムが、ブロック１１２５の図１
２データのブロック１１２５のデータをキー・フレームとして圧縮することを指定していなかったことを想定している。 従って、図２のブロック２１０はコントロールをブロック２３０に送る。 同様に、この例は、図１の圧縮方法をコールするアプリケーション・プログラムが内部フレーム圧縮だけ用いてムービーを圧縮することを指定していなかったので、図２のブロック２３０は、コントロールをブロック２４０に送ることを想定している。
順に、ブロック２４０は図３と４の内部フレーム圧縮ルーチンをコールする。 例で概略的に示されたように、図３と４の内部フレーム圧縮ルーチンは、各々、２５０と２，０００の内部フレームと相互フレームの許容値を使用している。 この例は、２５０の内部フレーム許容値を使用している、何故ならば、この値は、図１２のブロック１１００のデータを圧縮する際に、好ましい結果を示して作動していたからである。 同様に、この例は２，０
００の内部フレーム許容値を使用している、何故ならば、効果的な相互フレーム許容値は成功した内部フレーム許容値の一般的に８倍だったことを、実験が示唆していたからである。 図３のブロック３００から開始して、
ルーチンは、図１２のブロック１１２５が圧縮されていないデータのラインであることを決定して、コントロールを図３のブロック３０７にパスする。 ブロック３０７
は、前のフレームのピクセル・ポインタの内容をセットして、図１２のブロック１１００のピクセル１１０１を示す。 同様に、図３のブロック３１０は、今のフレームのピクセル・ポインタの内容を図１２のブロック１１２
５のピクセル１１２６にセットする。 次に、図３のブロック３２０は、デルタ・オフセットをゼロに初期設定する。 相互フレーム圧縮プロセスの中心部は、ブロック３
３０，３４０，３５０，３５２，３５４，３５６から形成されるループである。 このループは、ペアの変動値が相互フレーム許容値より大きくなるので、相互フレーム・ピクセル・ペアのカラーの値を比較する。 この例の場合、ループは、ブロック３３０が図１２のピクセル１１
０１と１１２６が有効な相互フレーム・ピクセル・ペアを形成していると決定すると開始する。 次に、図３のブロック３４０は、これらのピクセルの変動値を、図５のブロック５２０と同じ方式で、すなわち、変動値の関係式＝（８４−２５５）２＋（８４−０）２＋（８４−
０）２＝４３，３５３を用いて決定する。 順に、ブロック３６０は、両方のデルタ・オフセットがゼロに等しいと決定して、コントロールを図４のブロック４０７にパスする。 ブロック４０７がコントロールをもつと、それは、ラン変数の長さを１に初期設定して、コントロールをブロック４１０にパスする。 この例は、図１の圧縮方法をコールするアプリケーションが、ハイブリッド圧縮、すなわち、相互フレームと内部フレームの圧縮の混合を可能にすることを想定している。 この想定に基づいて、図４のブロック４１０は、コントロールをブロック４２０に送る。 ブロック４２０は、（１）ラインに残っている圧縮されていないピクセルの数にラン変数の長さをプラスした数値がランの長さの最小値より大きいか、
または（２）ラインに残っている圧縮されていないピクセルの数がゼロに等しいかどうかについて決定する。 このケースで、ラインに残っている圧縮されていないピクセルの数（１０）にラン変数の長さの値（１）をプラスした数値は、ランの長さの最小値（４）より大きい。 その結果、ブロック４２０は、変動値を図１２のピクセル１１２６と１１２７のカラー属性に基づいて計算する。
ブロック４２５にコントロールを送る（（１）今のフレームのピクセル・ポインタの内容と（２）今のフレームのピクセル・ポインタの内容にラン変数の長さをプラスした値に依って表されるピクセル）。 このケースで、ピクセルの変動値はゼロ〔０＝（８４−８４）２＋（８４
−８４）２＋（８４−８４）２〕になる。 ゼロの変動値は２５０の内部フレーム許容値より小さいので、図４のブロック４３０はコントロールをブロック４５５に送る。 順に、ブロック４５５は、ラン変数の長さを２に増加して、コントロールをブロック４２０にリターンする。 ブロック４２０は、ラインに残っている圧縮されていないピクセルの数（８）にラン変数の長さ（２）をプラスした数値がランの長さの最小値（４）より大きいと決定すると、その結果、ブロック４２０は、コントロールをブロック４２５にパスする。 ブロック４２５は、図１２のピクセル１１２６と１１２８の変動値を計算する。 再び、この値はゼロ〔０＝（８４−８４）２＋（８
４−８４）２＋（８４−８４）２〕になる。 その結果、
図４のブロック４３０は、ラン変数の長さを３に増加する、ブロック４５５にコントロールをパスする。 次に、
ブロック４５５は、コントロールをブロック４２０にパスする。 再び、ブロック４２０は、ラインに残っている圧縮されていないピクセルの数（７）にラン変数の長さの値（３）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 次に、ブロック４２
０はコントロールをブロック４２５にパスする。 順に、
ブロック４２５は図１２のピクセル１１２６と１１２９
の変動値を計算する。 ピクセルの計算された変動値はゼロ〔０＝（２５５−２５５）２＋（０−０）２＋（０−
０）２〕になる。 ペアの変動値は内部フレーム許容値より大きくないので、図４のブロック４３０はコントロールをブロック４５５にパスする。 そこで、ブロック４５
５はラン変数の長さを４に増加する。 次に、ブロック４
５５はコントロールをブロック４２０にパスする。 ブロック４２０は、ラインに残っている圧縮されていないピクセルの数（６）にラン変数の長さの値（４）をプラスした数値がランの長さの最小値（４）より大きいことを決定する。 その結果、ブロック４２０はコントロールをブロック４２５にパスする。 順に、ブロック４２５は、
図１２のピクセル１１２６と１１３０の変動値を計算する。 再び、この値はゼロ〔０＝（８４−８４）２＋（８
４−８）２＋（８４ー８４）２〕になる。 次に、図４のブロック４３０は、ラン変数の長さを５に増加する、ブロック４５５にコントロールをパスする。 次に、ブロック４５５はコントロールをブロック４２０にパスする。
ブロック４２０は、ラインに残っている圧縮されていないピクセルの数（５）にラン変数の長さ（５）をプラスした数値がランの長さの最小値（４）より大きいと決定すると、その結果、ブロック４２０はコントロールをブロック４２５にパスする。 順に、ブロック４２５は図１
２のピクセル１１２６と１１３１の変動値を計算する。
ここでしかし、計算された変動値は１０，４４３〔１
０，４４３＝（１４３−８４）２＋（１４３−８４）２
＋（１４３−８４）２〕になる。 この値は２５０の内部フレーム許容値より□かに大きいので、図４のブロック４３０は、コントロールをブロック４３５に送る。 ブロック４３５はラン変数の長さの大きさを調べる。 このケースで、ラン変数の長さの値（５）はランの長さの最小値（４）より大きい。 そこで、ブロック４３５は、コントロールをブロック４３７に送る。 ブロック４３７は、
ピクセル１１２６，１１２７，１１２８，１１２９，１
１３０をランの長さのエンコーディングとしてエンコードする。 図１１のブロック１１００の既に圧縮されていたデータと同様に、図９のエンコード方法と図１４のエンコード方法が共に図１２に図示されている。 図１２のブロック１２１０は図９のエンコード方法を使用しているが、ブロック１２２０と１２３０は図１４のエンコード方法を使用している。 やはり、通常の条件のもとで、
１つだけのエンコード方法がアプリケーションに依って用いられると思われる。 図１２のブロック１２１０の内部のバイト・グループ１２１１は、図９の方法を使用するピクセル１１２６，１１２７，１１２８，１１２９，
１１３０のランの長さのエンコーディングである。 このグループの第１バイト（０５）はランの長さの大きさである。 このグループの第２バイト（４１）は、ピクセル１１２６，１１２７，１１２８，１１２９，１１３０のカラー・インデックスである。 図１０（（８４，８４，
８４）のＲＧＢカラー値のカラー・インデックスとして４１を示すカラー・ルックアップ・テーブル）を参照すること。 同様に、図１２のブロック１２２０の内部のバイト・グループ１２２１は、図１４の方法を使用するピクセル１１２６，１１２７，１１２８，１１２９，１１
３０のランの長さのエンコーディングである。 このグループの第１バイト１８はランの長さの大きさに比例する。 ランの長さの実際の大きさは１４をバイトから減算して求められる。 図１２のブロック１２１０のバイト・
グループ１２１１の第２バイトと同様に、ブロック１２
２０のバイト・グループ１２２１の第２バイト４１は、
ピクセル１１２６，１１２７，１１２８，１１２９，１
１３０のカラー・インデックスである。 図１０（（８
４，８４，８４）のＲＧＢカラー値のカラー・インデックスとして４１を示すカラー・ルックアップ・テーブル）を参照すること。 図４のブロック４３７がランの長さをエンコードすると、ブロック４３７はコントロールをブロック４２８に送る。 ブロック４３８は（１）ラン変数の長さをゼロにセットして（２）コントロールをブロック４４０に送る。 ブロック４４０は、今のフレームのピクセル・ポインタの内容を更新して、調査される必要がある図１２のブロック１１２５の次のピクセル、すなわち、ピクセル１１３１を示す。 同様に、ブロック４
４５は、前のフレームのピクセル・ポインタの内容を更新して、図１２のブロック１１００の対応するピクセル、すなわち、ピクセル１１０６を示す。 図４のブロックが前のフレームのピクセル・ポインタを更新すると、
ブロック４４５は、コントロールを図３のブロック３２
０に送る。 ブロック３２０は、デルタ・オフセットをゼロにリセットして、コントロールをブロック３３０にパスする。 ブロック３３０は、図１２のブロック１１００
のピクセル１１０６と、図１２のブロック１１２５の１
１３１を、有効な相互フレームピクセル・ペアとして認識する。 その結果、図３のブロック３４０は、ペアに対して１，８７５の変動値を計算する〔１，８７５＝（１
４３−１６８）２＋（１４３−１６８）２＋（１４３−
１６８）２〕。 ブロック３５０は、この値を２，０００
の相互フレーム許容値より小さいものと認識して、コントロールをブロック３５２にパスする。 ブロック３５２
は、デルタ・オフセットを更新する、すなわち、水平デルタ・オフセットを１に増加して行い、コントロールをブロック３５４に送る。 ブロック３５４は、前のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３５６に送る。 類似の方式で、ブロック３
５６は、今のフレームのピクセル・ポインタの内容に増加して、コントロールをブロック３３０に送る。 ブロック３３０は、図１２のブロック１１００のピクセル１１
０７と、図１２のブロック１１２５の１１３２を、有効な相互フレーム・ピクセル・ペアとして認識する。 その結果、図３のブロック３４０は、ペアに対して６７５の変動値を計算する〔６７５＝（１５３−１６８）２＋
（１５３−１６８）２＋（１５３−１６８）２〕。 ブロック３５０は、この値を２１，０００の相互フレーム許容値より小さいものと認識して、コントロールをブロック３５２にパスする。 再び、ブロック３５２はデルタ・
オフセットを更新する。 ここでは、水平デルタ・オフセットを２に増加して行う。 順に、ブロック３５４は、前のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３５６に送る。 同じ方式で、ブロック３５６は、今のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３３０に送る。
ブロック３３０は、図１２のブロック１１００のピクセル１１０８と、図１２のブロック１１２５の１１３３
を、有効な相互フレーム・ピクセル・ペアとして認識する。 その結果、図３のブロック３４０は、ペアに対して１，０７５の変動値を計算する〔１，０７５＝（１５３
−１７８）２＋（１５３−１６８）２＋（１５３−１６
８）２〕。 ブロック３５０は、この値を２，０００の相互フレーム許容値より小さいものと認識して、コントロールをブロック３５２にパスする。 ブロック３５２は、
デルタ・オフセットを更新する、すなわち、水平デルタ・オフセットを３に増加して行い、次に、コントロールをブロック３５４に送る。 ブロック３５４は、前のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３５６に送る。 類似の方式で、ブロック３５６は、今のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３３０に送る。 ブロック３３０は、図１２のブロック１１００のピクセル１
１０９と、図１２のブロック１１２５の１１３４を、有効な相互フレーム・ピクセル・ペアとして認識する。 その結果、図３のブロック３４０は、ペアに対して１，８
７５の変動値を計算する〔１，４７５＝（１５３−１６
８）２＋（１４３−１６８）２＋（１４３−１６８）
２〕。 ブロック３５０は、この値を２，０００の相互フレーム許容値より小さいものと認識して、コントロールをブロック３５２にパスする。 ブロック３５２は、デルタ・オフセットを更新する、すなわち、水平デルタ・オフセットを４に増加して行って、コントロールをブロック３５４に送る。 ブロック３５４は、前のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３５６に送る。 類似の方式で、ブロック３５６
は、今のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３３０に送る。 ブロック３
３０は、図１２のブロック１１００のピクセル１１１０
と、図１２のブロック１１２５の１１３５を、有効な相互フレーム・ピクセル・ペアとして認識する。 その結果、図３のブロック３４０は、ペアに対して６７５の変動値を計算する〔６７５＝（１５３−１６８）２＋（１
５３−１６８）２＋（１５３−１６８）２〕。 ブロック３５０は、この値を２，０００の相互フレーム許容値より小さいものと認識して、コントロールをブロック３５
２にパスする。 ブロック３５２は、デルタ・オフセットを更新する、すなわち、水平デルタ・オフセットを５に増加して行って、コントロールをブロック３５４に送る。 ブロック３５４は、前のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３５６
に送る。 類似の方式で、ブロック３５６は、今のフレームのピクセル・ポインタの内容を増加して、コントロールをブロック３３０に送る。 ブロック３３０がコントロールをもつと、しかし、それは、今のフレームのピクセル・ポインタと前のフレームのピクセル・ポインタが生のビデオ・データの境界を越えている（図１２のブロック１１００と１１２５を越えている）ことを認識する。
その結果、図３のブロック３３０は、コントロールをブロック３３１に送る。 ブロック３３１は、水平デルタの値（５）のデルタの最小値（４）より大きいことを決定して、コントロールをブロック３３２に送る。 ブロック３３２は、図１２のピクセル１１３１，１１３２，１１
３３，１１３４，１１３５のデルタをエンコードする。
図９のデルタ・エンコード方法は図１２のブロック１２
１０のバイト・グループ１２１２に依って表される。 このグループの最初の２つのバイト（００と０２）はデルタ・エスケープ・シーケンスを意味している。 次のバイト（０５）は水平デルタ・オフセットの大きさである。
同様に、最終バイト（００）は、垂直デルタ・オフセットの大きさである。 従って、図９の方法は、デルタをエンコードするために、４バイトを要求する。 図１４のデルタ・エンコード方法は、しかし、シングル・バイトだけ要求する。 図１２のブロック１２２０のバイト・グループ１２２２を参照すること。 このグループの唯−のバイト（０５）はデルタ・オフセットの大きさである。 前述のように、図１４のエンコード方法は、１〜１４の範囲の値をもつ、全てのシングル・バイトが水平デルタであると想定している。 この方式で、図１４のエンコード方法は、図９の方法と比べると、データを２０％節約してルーチンで圧縮する。 図３のブロック３３２がデルタをエンコードした後に、ブロック３３２はビット・マップ・エスケープ・コードの最後（ブロック１２１０のバイト・グループ１２１３とブロック１２２０のバイト・
グループ１２２３）をエンコードする。 ピットマップ・
エンコーディングの最後は、図９と１４から明瞭に説明される。 このポイントで、図３のブロック３００は、発明がフレームｎ＋１（図１２のブロック１２２０）をブロックのフレームｎ（図１２のブロック１１００）に相応して完全に圧縮したことを認識する。 その結果、図３
のブロック３０５は、コントロールを図１のブロック２
６０にリターンする。 順に、ブロック２６０は、コントロールを図１のブロック１２０にリターンする。 ブロック１２０は、圧縮されたデータのサイズを６−１１バイトのターゲット・レンジに相応して調べる。 図９のエンコード方法はデータを８バイトに圧縮していた。 図１２
のブロック１２１０を参照すること。 対照的に、図１４
のエンコード方法はデータを５バイトに圧縮していた。
図１２のブロック１２２０を参照すること。 そこで、図９の方法を使用してエンコードされたデータは、６−１
１バイトのターゲット・レンジのほぼ中間にある。 一方、図１４の方法を使用してエンコードされたデータはターゲット・レンジのフロアより低い、すなわち、５バイトは６バイトのフロアより低い。 その結果、ブロック１２０は、２つの異なるコースのアクションを、エンコード方法が用いられていた何れかのアクションに基づいて実施する。 図９のエンコード方法に関して、ブロック１２０はコントロールをブロック１０５に送る。 ブロック１０５は、ルーチンが生のビデオ・データの全てを圧縮していたことを決定する。 その結果、ブロック１０５
はコントロールをブロック１８０に送る。 順に、ブロック１８０は図１の圧縮方法をコールしていたアプリケーションにリターンする。 一方、図１４のエンコード方法に関して、図１のブロック１２０はコントロールをブロック１３０に送る。 ブロック１３０は、ルーチンがフレームをスプリットすべきかどうかについて決定する。 発明はフレームをターゲット・レンジのフロアより低く圧縮していたので、フレームを分解する必要はなく、ブロック１３０はコントロールをブロック１４０にパスする。 この例で、ブロック１４０は、既に説明済みの修正されたバイナリ・サーチ方法を用いて、両方の許容値を減少する。 従って、新しい相互フレーム許容値は１，０
００になり、新しい内部フレーム許容値は１２５になる。 許容値の調整後に、ブロック１４０はコントロールをブロック１１０に送る。 順に、ブロック１１０は、図２の圧縮フレーム・ルーチンをコールする。 図２の圧縮フレーム・ルーチンは、ブロック２００，２１０，２３
０に依って図示されているように、データに関するシリーズのテストを実施する。 前述のように、これらのテストの各々は否定にリターンして、ルーチンは、図３と４
の相互フレーム圧縮ルーチンをコールする、ブロック２
４０にコントロールを最終的にパスする。 図３のブロック３００から開始して、ルーチンは、図１２のブロック１１２５が圧縮されていないデータのラインであることを決定して、コントロールを図３のブロック３０７にパスする。 ブロック３０７は、前のフレームのピクセル・
ポインタの内容をセットして、図１２のブロック１１０
０のピクセル１１０１を示す。 同様に、図３のブロック３１０は、今のフレームのピクセル・ポインタの内容をセットして、図１２のブロック１１２５のピクセル１１
２６を示す。 次に、図３のブロック３２０は、デルタ・
オフセットをゼロに初期設定する。 次に、ブロック３３
０は、図１２のピクセル１１０１と１１２６が有効な相互フレーム・ピクセル・ペアを形成していることを決定する。 そこで、図３のブロック３４０はピクセルの変動値を決定する。 このケースで、ピクセルの変動値は４
３，３５３になる、すなわち〔４３，３５３＝（８４−
２５５）２＋（８４−０）２＋（０−８４）２〕である。 この値は新しい相互フレーム許容値１，０００より大きいので、図３のブロック３５０はコントロールをブロック３６０に送る。 順に、ブロック３６０は、両方のデルタ・オフセットがゼロに等しいことを決定して、コントロールを図４のブロック４０７にパスする。 ブロック４０７がコントロールをもつと、それは、ラン変数の長さを１に初期設定して、コントロールをブロック４１
０にパスする。 前述のように、この例は、図１の圧縮方法をコールするアプリケーションが、ハイブリッド圧縮、すなわち、相互フレームと内部フレームの圧縮の混合を可能にすることを想定している。 そこで、図４のブロック４１０は、コントロールをブロック４２０に送る。 ブロック４２０は、（１）ラインに残っている圧縮されていないピクセルの数にラン変数の長さをプラスした数値がランの長さの最小値より大きいか、または（２）ラインに残っている圧縮されていないピクセルの数がゼロに等しいかどうかについて決定する。 このケースで、ラインに残っている圧縮されていないピクセルの数（１０）にラン変数の長さの値（１）をプラスした数値は、ランの長さの最小値（４）より大きい。 その結果、ブロック４２０は、変動値を図１２のピクセル１１
２６と１１２７のカラー属性に基づいて計算する、ブロック４２５にコントロールを送る（（１）今のフレームのピクセル・ポインタの内容と（２）今のフレームのピクセル・ポインタの内容にラン変数の長さをプラスした値に依って表されるピクセル）。 この場合、画素のばらつき値はゼロである〔０＝（８４−８４） ^２ ＋（８４−
８４） ^２ ＋（８４−８４） ^２ 〕。 ゼロの「ばらつき値」
は、１２５という新しい「フレーム内許容差」よりも小さいことから、図４のブロック４３０は制御をブロック４５５まで移送する。 ブロック４５５の方は、「ランレングス」変数を２まで増分し、制御をブロック４２０へ戻す。 ブロック４２０は、ライン内に残された未圧縮画素の数（８）に「ランレングス」変数（２）を加算した数が「ランレングス最小値」（４）よりも大きいことを決定し、結果としてブロック４２０は制御をブロック４
２５へ移行させる。 ブロック４２５は、図１２の画素１
１２６及び１１２８についての「ばらつき値」を計算する：ここでも又この値はゼロである：〔０＝（８４−８
４） ^２ ＋（８４−８４） ^２ ＋（８４−８４） ^２ 〕。 その結果、図４のブロック４３０は、制御をブロック４５５
へと移行させ、このブロック４５５は「ランレングス」
変数を３まで増分する。 これに続いて、ブロック４５５
は制御をブロック４２０まで移行させる。 さらにもう１
度、ブロック４２０は、ライン内に残った未圧縮画素数（７）に「ランレングス」変数の値（３）を加えたものが「ランレングス最小値」（４）よりも大きいことを決定する。 それに続いて、ブロック４２０は制御をブロック４２５まで移行させる。 ブロック４２５は、図１２の画素１１２６及び１１２９について「ばらつき値」を計算する。 ここで再び、画素の計算上の「ばらつき値」はゼロ〔０＝（２５５）−２５５） ^２ ＋（０−０） ^２ ＋
（０−０） ^２ 〕である。 この対の「ばらつき値」は１２
５という新しい「フレーム内許容差」より小さいことから、ブロック４３０は再び制御をブロック４５５まで移行させる。 ブロック４５５の方は、「ランレングス」変数を４まで増分させる。 これに続いて、ブロック４５５
は制御をブロック４２０まで移行させる。 ブロック４２
０は、ライン内に残っている未圧縮画素の数（６）に「ランレングス」変数の値（４）を加えたものが「ランレングス最小値」（４）よりも大きいことを決定する。
その結果、ブロック４２０は制御をブロック４２５へと移行させる。 ブロック４２５の方は、図１２の画素１１
２６及び１１３０についての「ばらつき」値を計算する。 ここでも又、この値は、ゼロである〔０＝（８４−
８４） ^２ ＋（８４−８４） ^２ ＋（８４−８４） ^２ 〕。 その結果、図４のブロック４３０は制御をブロック４５５
まで移行させ、このブロック４５５は、「ランレングス」変数を５まで増分させる。 これに続いて、ブロック４５５は制御をブロック４２０まで移行させる。 ブロック４２０は、ライン内に残された未圧縮画素の数（５）
に「ランレングス」変数（５）を加えたものが「ランレングス最小値」（４）よりも大きいことを決定し、その結果、ブロック４２０は、制御をブロック４２５まで移行させる。 ブロック４２５の方は、図１２の画素１１２
６及び１１３１についての「ばらつき値」を計算する。
しかしながら今回は、計算された「ばらつき値」は、１
０，４４３〔１０，４４３＝（１４３−８４） ^２ ＋（１
４３−８４） ^２ ＋（１４３−８４） ^２ 〕である。 この値は、１２５という新しいフレーム内許容差よりもはるかに大きいことから、図４のブロック４３０は制御をブロック４３５まで移送する。 ブロック４３５は「ランレングス」変数の絶対値を検査する。 この場合、「ランレングス」変数の値（５）は、ランレングス最小値」よりも大きい。 従って、ブロック４５３は制御をブロック４３
７へ移送する。 ブロック４３７は、ランレングスコード化として、図１２の画素１１２６、１１２７、１１２
８、１１２９及び１１３０をコード化する。 ブロック１
２３０のバイト群１２３１は、画素１１２６、１１２
７、１１２８、１１２９及び１１３０のランレングスコード化表示である。 （ブロック１２２１は、図１４の方法を用いてコード化される…図９の方法はターゲット範囲内で前に圧縮されており、従ってもはや使用されない）。 前述のとおり、この群の最初のバイト（１８）はランレングスの絶対値に正比例する：すなわち、ランレングスに対する実際の絶対値は、このバイトから１４を減算することによって得られる。 図１２のバイト群１２
２１の第２のバイト４１は、画素１１２６、１１２７、
１１２８、１１２９及び１１３０に対する色指数である。 図１０参照のこと。 （カラー参照用テーブルは、
（８４、８４、８４）というＲＧＢカラー値についての色指数として４１を示している）。 図４のブロック４３
７は、ひとたびランレングスをコード化すると、制御をブロック４２８まで移送する。 ブロック４３８は、
（１）「ランレングス」変数をゼロに設定し、（２）制御をブロック４４０まで移送する。 ブロック４４０は、
圧縮を受ける必要のある図１２のブロック１１２５の次の画素すなわち画素１１３１を指すよう、「現行フレーム画素ポインタ」の内容を更新する。 同様にして、図４
のブロック４４５は、図１２のブロック１１００の相応する画素すなわち画素１１０６を指すよう「先行フレーム画素ポインタ」の内容を更新する。 その後、ブロック４４５は制御を図３のブロック３２０まで移送する。 ブロック３２０は、デルタオフセットをゼロにリセットし、ブロック３３０へと制御を移行させる。 ブロック３
３０は、図１２のブロック１１００内の画素１１０６及び図１２のブロック１１２５内の画素１１０６を、有効なフレーム間画素対として認識する。 その結果、ブロック３４０は、この対について１８７５という「ばらつき値」を計算する〔１，８７５＝（１４３−１６８） ^２ ＋
（１４３−１６８） ^２ ＋（１４３−１６８） ^２ 〕。 しかしながら、この「ばらつき値」はこのとき１０００という新しい「フレーム間許容差」よりも大きくなる。 その結果、ブロック３５０は制御をブロック３６０へと移行させる。 ブロック３６０の方は、両方のデルタオフセットがゼロに等しいことを決定し、制御を図４のブロック４０７まで移行させる。 ブロック４０７は、ひとたび制御を手中にすると、「ランレングス」変数を１に初期設定し、制御をブロック４１０に移行させる。 前述のとおり、この例は、フレーム間とフレーム内の圧縮の混合が有効であることを仮定している。 従って図４のブロック４１０は制御をブロック４２０に移送する。 ブロック４
２０は、ライン内に残っている未圧縮画素の数（５）に「ランレングス」変数の値（１）を加えたものが「ランレングス最小値」（４）よりも大きいことを決定する。
その結果、ブロック４２０は制御をブロック４２５に移行させ、ブロック４２５は、図１２の画素１１３１及び１１３２（（１）「現行フレーム画素ポインタ」の内容及び（２）「現行フレーム画素ポインタ」の内容に「ランレングス」変数を加えたものによって参照指示されている画素）のカラー属性に基づき「ばらつき値」を計算する。 この場合、画素の「ばらつき値」は、３００〔３
００＝（１５３−１４３） ^２ ＋（１５３−１４３） ^２ ＋
（１５３−１４３） ^２ 〕である。 １２５という新しい「フレーム内許容差」よりも大きい「ばらつき値」のため、図４のブロック４３０は、制御をブロック４３５に移行させる。 ブロック４３５は、「ランレングス」変数の絶対値（１）が「ランレングス最小値」（４）よりも小さいことを決定し、制御をブロック４３６へ移送する。 ブロック４３６は、絶対モードで画素１１３１、１
１３２及び１１３３をコード化する。 （前述のとおり、
絶対モードコード化は、３つの画素の最小値をコード化する）。 図１４の方法を用いたこれらの画素の絶対コード化は、図１２のブロック１２３０においてバイト群１
２３２により表示されている。 この群の最初の２つの（００及び０３）バイトは、絶対的にコード化された画素として次に続く３つのバイト４９、５０及び５０を識別する：（４９）及び（５０）は、それぞれ（１４３、
１４３、１４３）及び（１５３、１５３、１５３）のＲ
ＧＢ値についての色指数である。 図１０（カラー参照用テーブル）を参照のこと。 図４のブロック４３６は、図１１の画素１１３１、１１３２及び１１３３をひとたびコード化すると、ブロック４３８まで制御を移行させる。 ブロック４３８は、「ランレングス」変数をゼロに設定し、制御をブロック４４０に移行させる（原文 抜け）。 ブロック４４０は、検査を受ける必要のある図１
２のブロック１１２５の次の画素すなわち画素１１３４
を指すように「現行フレーム画素ポインタ」の内容を更新する。 同様にして、図４のブロック４４５は、図１２
のブロック１１００の相応する画素すなわち画素１１０
９を指すように先行フレーム画素ポインタ」の内容を更新する。 図４のブロック４４５は、「先行フレーム画素ポインタ」をひとたび更新すると、制御を図３のブロック３２０まで移送する。 ブロック３２０は、デルタオフセットをゼロにリセットし、制御をブロック３３０まで移行させる。 ブロック３３０は、図１２のブロック１１
００内の画素１１０９及び図１２のブロック１１２５内の１１３４を有効なフレーム間画素対として認識する。
その結果、図３内のブロック３４０は、この対について１４７５という「ばらつき値」を計算する〔１，４７５
＝（１５３−１６８） ^２ ＋（１４３−１６８） ^２ ＋（１
４３＝１６８） ^２ 〕。 しかしながら、ここでも、この「ばらつき値」はこのとき１０００という新しい「フレーム間許容差」よりも大きくなる。 その結果、ブロック３５０は制御をブロック３６０へと移行させる。 ブロック３６０の方は、両方のデルタオフセットがゼロに等しいことを決定し、図４のブロック４０７に制御を移行させる。 ブロック４０７は、ひとたび制御を手中にすると、「ランレングス」変数を１に初期設定し、制御をブロック４１０へと移行させる。 上述のように、この例では、フレーム間及びフレーム内の圧縮の混合が有効であることが仮定されている：かくして、図４のブロック４
１０は、制御をブロック４２０へと移送させる。 しかしながらこの時点で、ブロック４２０は、ライン内に残された未圧縮画素の数（２）に「ランレングス」変数の値（１）を加えたものが「ランレングス最小値」（４）よりも小さいことを決定する。 その結果、ブロック４２０
はブロック４６５に制御を移送する。 ブロック４６５
は、「ランレングス」変数の絶対値を評価し、その値が１であることを決定した時点で、制御をブロック４６９
へと移送する。 ブロック４６９は、ブロック１２３０の絶対コード化された群１２３２と組合わせることによって、図１２のブロック１１２５内の画素１１３４及び１
１３５をコード化する。 画素１１３１、１１３２及び１
１３３と組合わさった状態での（これらの画素はブロック１２３０のバイト群１２３２として以前にコード化されている）画素１１３３及び１１３４のバイト群は、図１２のブロック１２４０内でバイト群１２４２により表示されている。 この群の最初の２つのバイト（００及び０５）は、絶対的にコード化された画素として次に続く５つのバイト（４９、５０、５０、４９及び５０）を識別する：（４９）及び（５０）は、それぞれ（１４３、
１４３、１４３）及び（１５３、１５３、１５３）のＲ
ＧＢ値に対する色指数である。 図１０（カラー参照用テーブル）を参照のこと。 図４のブロック４６９が図１２
のブロック１２４０内の１２４２のバイト群を作り出した後、図４のブロック４６９は、ビットマップの終りのエスケープコート（ブロック１２４０内のバイト群１２
４３）をコード化する。 ビットマップの終りのコード化は、１４により直接的に説明されている。 図４の１つのブロック４６９はこの最後のバイト群をコード化し、ルーチンは制御を図３のブロック３００へと移行させる。
図１２のブロック１１２５の圧縮が完全であることから、図３のブロック３００は制御をブロック３０５に移行させる。 その後、ブロック３０５は制御を図２のブロック２６０へと戻す。 この時点からブロック２６０は制御を図１のブロック１２０へと戻す。 ブロック１２０
は、６〜１１バイトのターゲット範囲に関する圧縮されたデータのサイズ（図１２のブロック１２４０）を検査する。 このパスで、図１４のコード化方法は１１バイト（すなわちターゲット範囲の最高限度）までデータを圧縮することができた。 かくして、図１４のコード化方法は、ターゲット範囲内で図１２のブロック１２４０のデータを圧縮した。 その上、図１４のコード化方法は、図９のコード化方法よりもはるかに詳細をコード化した。
図１２のブロック１２１０を図１２のブロック１２４０
と比較されたい。 図１のブロック１２０は図１２のブロック１２４０をターゲット範囲内にあるものとして認識することから、図１のブロック１２０はブロック１０５
へと移行する。 ブロック１０５は、全てのルーチンが全ての生ビデオデータを圧縮したことを認識する。 その結果、ブロック１０５は、制御をブロック１８０まで移送させる。 ブロック１８０は、図１の圧縮方法を呼出したアプリケーションまで戻る。 この時点で、両方のデータフレームがターゲット範囲内で圧縮されている状態で、
圧縮例は完成する。 圧縮解除例 一例として、図１１及び１２において圧縮されているビデオデータのフレームのための圧縮解除プロセスが図１
３に示されている。 この例について以下で説明するが、
読者のために、この例の以下のような概観が提供されている。 まず第１に、この例は、図９の方法を用いてコード化されたデータの圧縮解除を例示する（図１３のブロック１６０、１３１０、１２１０及び１３２０）。 第２
に、この例は、図１４の方法を用いてコード化されたデータの圧縮解除を例示する（図１３のブロック１１９
０、１３４０、１２４０及び１３６０）。 これらの方法の両方について、圧縮解除プロセスは、図９の「圧縮解除方法」ルーチン及び図８の「圧縮解除フレーム」ルーチンを追跡している。 その上、圧縮例の場合と同様に、
圧縮解除例は図１０のカラーテーブルを使用し続ける。
まず第１に、この例はフレームｎの圧縮されたデータを圧縮解除する。 第２にフレームｎのデータがひとたび圧縮解除された時点で、フレームｎ＋１のデータは圧縮解除され、フレームｎの上部に直接書き込まれてフレームｎ＋１の圧縮解除されたバージョンを生成する。 図９のコード化されたデータの圧縮解除に関しては、プロセスは図７の「圧縮解除方法」ルーチンで始まる。 ブロック７００で始まって、ルーチンはビデオムービーの圧縮されたデータを受諾する。 その後、ブロック７１０が、圧縮解除を必要としているフレームが２つあることを決定し、制御をブロック７２０まで移行させる。 ブロック７
２０の方は、第１のフレーム、図１３のブロック１１６
０を検索する。 その後、図７のブロック７３０は図８の「圧縮解除フレーム」ルーチンを呼出す。 図８のブロック８１０は、圧縮ビデオデータからの第１のバイト群すなわち図１３のブロック１１６０内のバイト群１１６１
を検索する。 図８のブロック８１０がこのバイト群をひとたび検査すると、ブロック８１５、８２０、８２５、
８３０及び８８０が、図１３のバイト群１１６１の性質を決定するべくデータについて一連のテストを行なう。
この場合、図８のブロック８３０は、ランレングスコード化として図１３のバイト群１１６１を認識する。 その後、図８のブロック８３０は、制御をブロック８５５まで移送させる。 図１０のカラー参照用テーブルを用いて、ランレングスの色指数（４１）がＲＧＢ値（２５
５、０、０）を表わしていることを決定する。 従って、
図８のブロック８５５は、図１３のブロック１３１０内の画素１３０１をペイントする。 （ブロック１３１０
は、フレームｎの圧縮解除バージョンを表わす）。 次に、図８のブロック８６０は、ルーチンが図８のブロック８６５まで制御を移行させる前に、ブロック１１６０
内のバイト群１１６１の第１のバイトによりもともと表示されていたランレングスの残りの絶対値を減分させる。 この場合、ブロック８６５は、ブロック８６０がランレングスの残りの絶対値を４から３へ減分させたことを決定する。 その結果、ブロック８６５はブロック８５
５まで制御を戻すことになる。 この要領で、ブロック８
５５、８６０及び８６５により形成されたループは、図１３のブロック１３１０内の画素１３０１−１３０４をペイントする。 図８のブロック８５５、８６０及び８６
５によって形成されたループがひとたび図１３の画素１
３０１〜１３０４をペイントすると、図８のブロック８
６５は制御をブロック８１０まで戻す。 ブロック８１０
の方は、圧縮ビデオデータから次のバイト群すなわち図１３のブロック１１６０内のバイト群１１６２を検索する。 ここでも又図８のブロック８３０はこのバイト群をランレングスコード化として認識する。 その結果、ブロック８５５、８６０及び８６５により形成されたループは、図３のブロック１３００内の画素１３０５、１３０
５、１３０７、１３０８、１３０９及び１３１０をペイントする。 このループがひとたびこれらの画素すべてをペイントした時点で、図８のブロック８６５は制御をブロック８１０に戻す。 ここでも又、ブロック８１０は、
圧縮ビデオデータからの次のバイト群すなわち図１３のブロック１１６０内のバイト群１１６３を検索する。 この場合、図８のブロック８１５は、ビットマップの終りのコード化として図１３のバイト群１１６３を認識し、
図８のブロック８４０まで制御を移送する。 結果として、ブロック８４０は図７のブロック７４０に制御を戻すことになる。 ブロック７４０は、新たに圧縮解除されたフレーム（図１３のブロック１３１０）を検査して、
それが分割フレームの上半分のみであるか否か決定する。 この場合、図１３のブロック１３１０は分割フレームの上半分ではない。 その結果、図７のブロック７４０
はブロック７５０まで制御を移送させる。 ブロック７５
０の方は、例えばビデオモニター上にフレームを表示する。 ブロック７５０は、ひとたびフレームを表示すると、制御をブロック７１０まで移送させる。 圧縮解除プロセスは、ブロック７１０がフレームｎ＋１すなわち図１３のブロック１２１０が圧縮解除を必要としていることを決定した時点で、続行する。 その結果、ブロック７
２０は、（１）図１３のブロック１２１０を検索し、
（２）図７のブロック７３０に制御を移送する。 その後、ブロック７３０が図８の「圧縮解除フレーム」ルーチンを呼出す。 図８のルーチンは、ブロック１３１０
（フレームｎ）の上部で直接図１３のブロック１２１０
を圧縮解除する。 この要領で、このルーチンはブロック１３２０（フレームｎ＋１）を生成する。 フレームｎ＋
１の実際の圧縮解除は、図８のブロック８１０が図１３
のブロック１２１０からのバイト群１２１１を検索した時点で開始する。 図８のブロック８３０の方は、（５）
という絶対値及び４１という色指数をもつランレングスコード化として図１３のバイト群１２１１を認識する。
図１０のカラーテーブルを用いて、ルーチンは、（４
１）という色指数が（８４、８４、８４）というＲＧＢ
値を説明していることを決定する。 従って、図８のブロック８５５、８６０及び８６５は、ブロック１３２０内の次に利用可能な５つの画素すなわち画素１３２１、１
３２２、１３２３、１３２４及び１３２５をペイントする。 ループがこれらの画素をひとたびペイントすると、
図８のブロック８６５は制御をブロック８１０まで戻す。 その後、ブロック８１０は圧縮ビデオデータから次のバイト群すなわち図１３のブロック１２１０内のバイト群を検索する。 従って、図８のブロック８２５はデルタコード化として図１３のバイト群１２１２を認識する。 その結果、ブロック８２５は制御をブロック８５０
に移送する。 ブロック８５０は水平及び垂直データオフセットの絶対値を検査する。 この場合、水平デルタオフセットは５という絶対値を有し、垂直デルタオフセットはゼロという絶対値を有する。 その結果、ルーチンはブラシを図１３のブロック１３００内で５画素分だけ右へつまり画素１３１０まで移動させる。 図８のブロック８
４５がひとたびブラシを移動させたならば、ルーチンは制御をブロック８１０まで戻す。 さらにもう一度ブロック８１０は、圧縮ビデオデータからの次のバイト群すなわち図１３のブロック１２１０内のバイト群１２１３を検索する。 図８のブロック８１５は、図１３のバイト群１２１３をビデオマップの終りのコード化として解釈し、制御を図８のブロック８４０まで移送する。 ブロック８４０の方は制御を図７のブロック７４０まで戻す。
ブロック７４０は、図１３のブロック１３２０が分割フレームの上半分のみではないことを決定し、結果としてブロック７５０まで制御を移送する。 ブロック７５０
は、図１３のブロック１３２０を表示、図７のブロック７１０まで制御を移送する。 この時点で、ルーチンはブロック７１０を介して、それがムービーの全フレームを圧縮解除したことを発見し、制御をブロック７６０まで移送する。 ブロック７６０は、図７の圧縮解除ルーチンを呼出したアプリケーションまで戻る。 この時点で、図９の方法を用いたフレームｎとフレームｎ＋１のコード化されたバージョンが圧縮解除され表示されている。 次に、この例は、図１４の方法を用いてコード化されたデータのための圧縮解除プロセスを例示する。 ここでも又、プロセスは図７のブロック７００で始まる。 ブロック７００は圧縮ムービーデータすなわち図１３のブロック１１９０（フレームｎ）及び１２４０（フレームｎ＋
１）を受諾する。 その後ブロック７１０は、フレームｎ
が圧縮解除を必要としていることを決定し、制御をブロック７２０まで移送する。 ブロック７２０の方は、図１
３のブロック１１９０を検索し、図７のブロック７３０
に制御を移行させる。 ブロック７３０は図８の「圧縮解除されたフレーム」ルーチンを呼出す。 「フレーム圧縮解除」ルーチンはブロック８１０でその圧縮解除を開始する。 ブロック８１０は、図１３のブロック１１９０内のバイト群１１９１を検索する。 図８のブロック８３０
の方は、（４）という絶対値及び（４３）という色指数をもつランレングスコード化としてこのバイト群を認識する（ランレングスコード化の絶対値は、第１のバイトの値から１４を減算することつまり１８−１４＝４によって得られる）。 図１０のカラー参照用テーブルを参照することによって、ブロック８５５、８６０及び８６５
により形成されたループは、図１４のブロック１３４０
内の画素１３４１、１３４２、１３４３及び１３４４をペイントする。 このルーチンがこれらの画素をひとたびペイントしたならば、図８のブロック８６５は制御をブロック８１０まで戻す。 ブロック８１０の方は、圧縮されたビデオデータから次のバイト群すなわち図１３のブロック１１９０内のバイト群１１９２を検索する。 ここで、もう１度、ブロック８３０は、ランレングスコード化としてこのバイト群を認識し、制御をブロック８５５
へと移行させる。 図１０のカラー参照用テーブルを用いて、図８のブロック８５５は、フレームｎの圧縮解除されたバージョン内の次に利用可能な画素すなわち図１３
のブロック１３４０内の画素１３４５を着色する。 その後ブロック８６０は、ランレングスコード化の最初のバイトの値を減分することによって、ランレングスの残りの絶対値を減分する。 ブロック８６５の方は、ナル値に対するランレングスの残りの絶対値を検査する。 この要領で、ブロック８５５、８６０及び８６５により形成されたループは図１３のブロック１３４０内の画素１３４
５、１３４６、１３４７、１３４８、１３４９及び１３
５０をペイントする。 これらの画素全てがひとたひペイントされると、ブロック８６５は制御をブロック８１０
まで移送する。 この時点で、ブロック８１０は圧縮ビデオデータからの次のバイト群すなわち図１３のブロック１１９０内のバイト群１１９３を検索する。 この場合、
ブロック８１５はビットマップの終りのコード化としてバイト群を認識し、制御をブロック８４０に移送する。
ブロック８４０の方は制御を図７のブロック７４０まで戻す。 ブロック７４０は、図１３のブロック１３４０が分割フレームの上半分でないことを決定し、その後制御をブロック７５０まで移送する。 ブロック７５０は、
（１）フレームを表示し、（２）制御をブロック７１０
まで戻す。 この時点で、ブロック７１０は、ルーチンがフレームｎ＋１（図１３のブロック１２４０）を圧縮解除しなかったことを決定する。 その結果図７のブロック７１０はブロック７２０まで制御を移送する。 ブロック７２０の方は、（１）図１３のブロック１２４０（フレームｎ＋１）を検索し、（２）制御を図７のブロック７
３０まで移送する。 その後、ブロック７３０は図８の「フレーム圧縮解除」ルーチンを呼出す。 フレームｎ＋
１の圧縮解除は、ブロック８１０が図１３のブロック１
２４０内でバイト群１２２１を検索するときに開始する。 その後、図８のブロック８３０は、（５）という絶対値及び（４）という色指数をもつランレングスコード化としてこのバイト群を認識する。 図１０のカラー参照用テーブルを参照すると、図８のブロック８５５はこの指数をＲＧＢ値（８４、８４、８４）を表わすものとして認識する。 その結果、図８のブロック８５５、８６０
及び８６５は、図１３のブロック１３５０内で画素１３
６１、１３６２、１３６３、１３６４及び１３６５をペイントする。 このループがひとたびこれらの画素をペイントすると、図８のブロック８６５は制御をブロック８
１０に戻す。 この時点で、ブロック８１０は、圧縮ビデオデータから次のバイト群すなわち図１３のブロック１
２４０内のバイト群１２４２を検索する。 ブロック８８
０の方はこのバイト群を絶対モードコード化として認識し、制御をブロック８８５に移送する。 ブロック８８５
は、最初の絶対コード化された画素の色指数すなわち４
９を検索する。 この時点から、ブロック８８５は、図１
０の色指数テーブルを用いて画素のＲＧＢ値すなわち（１４３、１４３、１４３）を決定する。 その後、図８
のブロック８８５は、次の利用可能な画素すなわち図１
３のブロック１３６０内の画素１３６６を着色する。 次に、ブロック８９０は、ペイントすべき絶対コード化された画素の残数を減分する。 この場合、ブロック８９０
は、図１３のバイト群１２４２内の第２のバイトを減分することによってこのタスクを達成する。 （第２のバイト、０５、は絶対コード化された画素の数を表わす）。
図８のブロック８９０がひとたびこのバイトを減分すると、ブロック８９５の方は、ブロック８８５、８９０及び８９５によって形成されたループが絶対コード化された全ての画素をペイントしたか否かを決定するため、第２のバイトの残りの値を検査する。 この要領で、ループは、図１３のブロック１３６０の画素１３６６、１３６
７、１３６８、１３６９及び１３７０をペイントする。
その後、ブロック８９５は制御をブロック８１０まで戻す。 この時点で、ブロック８１０は、圧縮ビデオデータからの次のバイト群すなわち図１３のブロック１２４０
内のバイト群１２４３を検索する。 図８のブロック８１
５はこのバイト群をビットマップの終りのコード化として認識し、制御をブロック８４０に移送する。 ブロック８４０の方は図７のブロック７４０に制御を戻す。 ブロック７４０は、図１３のブロック１３６０が分割フレームの上半分でなかったことを決定し、制御をブロック７
５０に移送する。 その後、ブロック７５０はフレームを表示し制御をブロック７１０に移送する。 この時点で、
ブロック７１０は、ルーチンがムービーの全てのフレームを圧縮解除したことを認識する。 その結果、ブロック７１０は制御をブロック７６０まで移送する。 ブロック７６０は、圧縮解除方法を呼出したアプリケーションプログラムまで戻る。 この時点で、この方法は、図１４の方法を用いて圧縮されたフレームｎ及びｎ＋１を表わすデータを圧縮解除した。 図１４のコード化方法の有利性は、図１３のブロック１３２０（図９の方法を用いて圧縮、圧縮解除されたフレームｎ＋１）に比べて、図１３
のブロック１３６０（図１４の方法を用いて圧縮、圧縮解除されたフレームｎ＋１）のデイテールが強化されているということによって明示されている。

【図面の簡単な説明】

【図１】圧縮ルーチンのフローチャートである。

【図２】図１の圧縮フレームルーチンのフローチャートである。

【図３】図のフレーム間及びフレーム内圧縮ルーチンのフローチャートである。

【図４】図３に続くフローチャートである。

【図５】図２のフレーム内圧縮ルーチンのフローチャートである。

【図６】図１の分割フレームルーチンのフローチャートである。

【図７】圧縮解除のフローチャートである。

【図８】図７の従来例で利用可能なルーチンである、圧縮解除フレームルーチンのフローチャートである。

【図９】本発明と共に使用される従来技術の符号化法を示すチャートである。

【図１０】本発明と共に使用される色参照用テーブルである。

【図１１】図５のフレーム内圧縮ルーチンを使用した圧縮データの生成を示す。

【図１２】図３及び図４のフレーム間圧縮ルーチンを使用した圧縮データの生成をしめす。

【図１３】図８の圧縮解除フレームルーチンを使用したフレーム内圧縮データ及びフレーム間圧縮データの両方の圧縮解除を示す。

【図１４】本発明と共に使用される新規の符号化法を示すチャートである。

フロントページの続き (72)発明者 エリック レドゥー アメリカ合衆国 ワシントン州 98052 レッドモンド １ ワンハンドレッドアン ドセヴンティフィフス アベニュー ノー スイースト 3841 (72)発明者 ディヴィッド エム メイムーデス アメリカ合衆国 ワシントン州 98112 シアトル イースト ヘレン ストリート 2614 (72)発明者 ダニエル ジェイ ミラー アメリカ合衆国 ワシントン州 98052 レッドモンド ノースイースト シックス ティフィフス コート 14607