JPH0775090A - ビデオデータを圧縮する方法及びシステム - Google Patents

ビデオデータを圧縮する方法及びシステム

Info

Publication number
JPH0775090A
JPH0775090A JP5354832A JP35483293A JPH0775090A JP H0775090 A JPH0775090 A JP H0775090A JP 5354832 A JP5354832 A JP 5354832A JP 35483293 A JP35483293 A JP 35483293A JP H0775090 A JPH0775090 A JP H0775090A
Authority
JP
Japan
Prior art keywords
block
frame
value
tolerance
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP5354832A
Other languages
English (en)
Other versions
JP3306207B2 (ja
Inventor
Stuart T Laney
ティー レイニー スチュアート
Eric Ledoux
レドゥー エリック
David M Maymudes
エム メイムーデス ディヴィッド
Daniel J Miller
ジェイ ミラー ダニエル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JPH0775090A publication Critical patent/JPH0775090A/ja
Application granted granted Critical
Publication of JP3306207B2 publication Critical patent/JP3306207B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H04N9/8045—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction using predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/15—Data rate or code amount at the encoder output by monitoring actual compressed data size at the memory before deciding storage at the transmission buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/182—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a pixel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
    • H04N19/192—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding the adaptation method, adaptation tool or adaptation type being iterative or recursive
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/577—Motion compensation with bidirectional frame interpolation, i.e. using B-pictures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/13—Adaptive entropy coding, e.g. adaptive variable length coding [AVLC] or context adaptive binary arithmetic coding [CABAC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums

Abstract

(57)【要約】 （修正有） 【目的】フレーム内及びフレーム間の圧縮スキーマを用
いて規定のターゲットサイズまでビデオムービーデータ
を圧縮するための方法。 【構成】フレーム内圧縮においては、ムービーフレーム
は、同じフレーム内の隣接する画素を比較して圧縮し、
フレーム間圧縮は、隣接するフレームの類似した形で位
置づけられた画素を比較して圧縮する。損失の無い圧縮
が充分でない状況の下では、さらなる圧縮を達成するた
め、閾値又は許容差を利用する。画素間でのカラーのば
らつきが許容差以下では単一のカラー値を用いて２つの
画素をコード化する。ターゲット範囲内で圧縮を達成す
るべく許容差を加減する。圧縮の結果、受諾できない質
の画像が生み出される場合、生データを半分に分割し、
各データ部分を別々に圧縮する。第１フレームの後のフ
レームは一般にフレーム内及びフレーム間圧縮の組合せ
を用いて圧縮する。

Description

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

Claims (33)

    【特許請求の範囲】
  1. 【請求項１】 複数の画素によって形成されているビデ
    オデータを圧縮するための方法において、 （ａ） 複数の画素群を形成する段階； （ｂ） 各画素群について１つの特性値を決定する段
    階； （ｃ） 許容差を特定する段階； （ｄ） 画素群の特性値間のばらつきを決定する段階； （ｅ） 決定されたばらつきが許容差内にある場合、画
    素群を表わす規定の特性値を特定し、、各画素群の特性
    値を規定の特性値に設定する段階、及び （ｆ） 同じ規定の特性値をもつ連続した画素群の数を
    計数し、ビデオデータの圧縮バーションの形で計数した
    数と規定の特性値を記憶する段階 を含む方法。
  2. 【請求項２】 − ビデオデータの圧縮バージョンのた
    めのターゲット範囲を特定する段階；及び − ビデオデータの圧縮バージョンがターゲット範囲内
    にくるまで、許容差を反復的に調整する段階、 を含む、請求項１に記載の方法。
  3. 【請求項３】 許容差を反復的に調整する段階には、 − ビデオデータの圧縮バージョンのサイズを決定する
    段階及び − 決定されたサイズがターゲット範囲内にない場合、
    許容差を調整し、調整された許容差を用いて段階（ｅ）
    −（ｆ）を反復する段階、 を反復的に実行することが含まれている、請求項２に記
    載の方法。
  4. 【請求項４】 許容差を調整する段階には、 − 許容差範囲を識別すること、 − 識別された許容差範囲から新しい許容差値を選択す
    ること；及び − 新たに選択された許容差に等しい限界を有するもの
    として許容できる許容差の範囲を再度定義づけすること が含まれている、請求項３に記載の方法：
  5. 【請求項５】 新しい許容差を選択する段階には； − 予め定められた値を、以前に使用した許容差のうち
    の１つに付加すること、が含まれる、請求項４に記載の
    方法。
  6. 【請求項６】予め定められた値が、許容差の各反復的調
    整毎に増大させられる、請求項５に記載の方法。
  7. 【請求項７】 複数の画素で形成されている複数の生ビ
    デオフレームにより形成されている１つのビデオをマッ
    ピングするための方法において、 （ａ） 各生データフレームの画素から複数の画素群を
    形成する段階； （ｂ） 各画素群について１つの特性値を決定する段
    階； （ｃ） 許容差を特定する段階； （ｄ） 画素群の特性値の間のばらつきを決定する段
    階；及び （ｅ） 決定されたばらつきが許容差内にある場合、画
    素群を表わす規定の特性値を特定し、各画素群の特性値
    を規定の特性値に設定する段階、 を含む方法。
  8. 【請求項８】 （ｆ） 許容差範囲を特定する段階； （ｇ） マッピングされたビデオのための受諾できる解
    像度の範囲を特定する段階； （ｈ） マッピングされたビデオの解像度を決定する段
    階；及び （ｉ） 決定された解像度が受諾できる解像度の範囲内
    に無い場合、規定の許容差範囲内から新しい許容差を選
    択し、選択された新しい許容差に等しい末端限界をもつ
    ものとして許容差範囲を再度定義づけする段階、及び （ｊ） マッピングされたビデオが受諾できる解像度の
    範囲内にくるまで、段階（ｅ）、（ｈ）及び（ｉ）を反
    復的にくり返す段階、 を含む、請求項７に記載の方法。
  9. 【請求項９】 新しい許容差が許容差範囲のほぼ中間点
    から選択される、請求項８に記載の方法。
  10. 【請求項１０】 新しい許容差が、前に使用された許容
    差の１つに対して予め定められた値を付加することによ
    って選択される、請求項８に記載の方法。
  11. 【請求項１１】 予め定められた値が許容差の各反復的
    調整毎に増大させられる、請求項１０に記載の方法。
  12. 【請求項１２】 複数の画素により形成される複数の生
    データビデオフレームにより形成されている１つのビデ
    オを圧縮するための方法において、 （ａ） 各生データフレームの画素から複数の画素群を
    形成する段階、 （ｂ） 各画素群について１つの特性値を決定する段
    階； （ｃ） 許容差を特定する段階； （ｄ） 画素群の特性値の間のばらつきを決定する段
    階； （ｅ） 決定されたばらつきが許容差内にある場合、画
    素群を表わす規定の特性値を特定し、各画素群の特性値
    を規定の特性値に設定する段階、及び （ｆ） 同じ規定の特性値をもつ連続した画素群の数を
    計数し、圧縮されたデータビデオフレーム内に計数した
    数と規定の特性値を記憶する段階、 を含む方法。
  13. 【請求項１３】 − 圧縮されたデータビデオフレーム
    のためのターゲット範囲を特定する段階；及び、 − 圧縮されたデータビデオフレームがターゲット範囲
    内にくるまで許容差を反復的に調整する段階、 を含む、請求項１２に記載の方法。
  14. 【請求項１４】 許容差を反復的に調整する段階には、 − 圧縮されたデータビデオフレームのサイズを決定す
    る段階、及び − 決定されたサイズがターゲット範囲内に無い場合、
    許容差を調整し、調整された許容差を用いて段階（ｅ）
    −（ｆ）を反復する段階、 を反復的に実行することが含まれている、請求項１３に
    記載の方法。
  15. 【請求項１５】 許容差を反復的に調整する段階には、 − 前に決定された有効許容差を識別する段階； − 有効許容差を用いて段階（ｅ）−（ｆ）を反復し、
    圧縮されたデータビデオフレームのサイズを決定する段
    階； − 有効許容差を用いて決定されたサイズがターゲット
    範囲内に無い場合、最大許容差を特定し、最大許容差を
    用いて段階（ｅ）−（ｆ）を反復し、圧縮データビデオ
    フレームのサイズを決定する段階、及び − 最大許容差を用いて決定されたサイズがターゲット
    範囲内に無い場合、発見的に決定された許容差を特定
    し、この発見的に決定された許容差を用いて段階（ｅ）
    −（ｆ）を反復し、圧縮データビデオフレームのサイズ
    を決定する段階、 が含まれている、請求項１３に記載の方法。
  16. 【請求項１６】 − 最大値を特定する段階；及び、 − 許容差が最大値より大きい場合、生データビデオを
    複数の生データ部分に分割する段階； − 生データフレームとして各生データ部分を用いて段
    階（ａ）−（ｆ）を反復する段階；及び − 分割生データフレームに続く生データフレームのう
    ちの１つに生データ部分のうちの１つを置換する段階、 を含む、請求項１３に記載の方法。
  17. 【請求項１７】 複数の画素により形成されている複数
    の生データビデオフレームによって形成されているビデ
    オを圧縮するための方法において、 （ａ） 各生データフレームの画素から複数の画素群を
    形成する段階、 （ｂ） 各画素群について１つの特性値を決定する段
    階； （ｃ） フレーム間許容差を特定する段階； （ｄ） 複数の相応するフレーム間画素について、フレ
    ーム間画素群の特性値間のフレーム間ばらつきを決定す
    る段階； （ｅ） 決定されたフレーム間ばらつきがフレーム間許
    容差内にある連続したフレーム間画素群の数を計数する
    段階、及び （ｆ） 圧縮データビデオフレーム内で連続するフレー
    ム間画素群の計数された数を表わすデータをコード化す
    る段階、 を含む方法。
  18. 【請求項１８】 デルタをコード化する段階には、 − 受諾できるデルタ値の範囲を選択する段階；及び − 連続するフレーム間画素群の計数された値がデルタ
    値の範囲内にある場合、デルタを計数された数としてコ
    ード化する段階、 が含まれている、請求項１７に記載の方法。
  19. 【請求項１９】 − 連続するフレーム間画素群の計数
    された数がデルタ値の範囲内にない場合、エスケープシ
    ーケンス、即ち計数された数及び付加的な位置づけ情報
    を用いてデルタをコード化する段階が含まれる、請求項
    １８に記載の方法。
  20. 【請求項２０】 特性値がカラー値であり、画素群の各
    々が単一の画素によって形成されている、請求項１７に
    記載の方法。
  21. 【請求項２１】 − 決定されたフレーム間ばらつきが
    フレーム間許容差（ｔｈａｎ不要？）内にない場合、フ
    レーム内許容差を特定し、複数のフレーム内画素群につ
    いてフレーム内画素群の特性値間のフレーム内ばらつき
    を決定する段階； − 決定されたフレーム内ばらつきがフレーム内許容差
    内にある場合、各フレーム内画素群を表わすべく規定の
    特性値を特定し、各フレーム内画素群の特性値を規定の
    特性値に設定する段階； − 同じ規定の特性値を有する連続したフレーム内群の
    数を計数する段階；及び − 計数された数及び規定の特性値を圧縮データビデオ
    フレーム内に記憶する段階 を含む、請求項１７に記載の方法。
  22. 【請求項２２】 −圧縮データビデオフレームのための
    ターゲット範囲を特定する段階； − 圧縮データビデオフレームのサイズを決定する段
    階；及び − 決定されたサイズがターゲット範囲内にない場合、
    フレーム間許容差を調整し、調整されたフレーム間許容
    差を用いて段階（ｃ）−（ｆ）を反復する段階、 が含まれている、請求項２１に記載の方法。
  23. 【請求項２３】 フレーム間許容差を調整する段階に
    は； − フレーム間許容差の範囲を特定すること、 − フレーム間許容差の特定された範囲から新しいフレ
    ーム間許容差値を選択すること、及び − 新しい選択されたフレーム間許容差に等しい限界を
    もつものとしてフレーム間許容差の範囲を再度定義づけ
    すること、 が含まれている、請求項２１に記載の方法。
  24. 【請求項２４】 − 最大値を特定する段階；及び − 許容差のうち少なくとも１つが最大値よりも大きい
    場合、複数の生データ部分に生データフレームを分割
    し、生データフレームとして各生データ部分を用いて段
    階（ａ）−（ｆ）を反復する段階 を含む、請求項２１に記載の方法。
  25. 【請求項２５】 − 圧縮データビデオフレームのため
    のターゲット範囲を特定する段階； − 圧縮データビデオフレームのサイズを決定する段
    階；及び − 決定されたサイズがターゲット範囲内に無い場合、
    フレーム間又はフレーム内許容差のうち少なくとも１つ
    を調整し、この調整された許容差を用いて段階（ｅ）−
    （ｆ）を反復する段階； が含まれている、請求項２１に記載の方法。
  26. 【請求項２６】 − 圧縮データビデオフレームについ
    てターゲット範囲を特定する段階； − 圧縮データビデオフレームのサイズを決定する段
    階； − 決定されたサイズがターゲット範囲内に無い場合、
    許容差のうち少なくとも１つを調整し、調整された許容
    差を用いて段階（ｅ）−（ｆ）を反復する段階； − 最大値を特定する段階；及び − 許容差のうちの少なくとも１つが最大値よりも大き
    い場合、生データフレームを複数の生データ部分に分割
    し、生データフレームとして生データ部分の各々を用い
    て段階（ａ）−（ｆ）を反復する段階、 が含まれている、請求項２１に記載の方法。
  27. 【請求項２７】 − 周期的キーフレーム間隔を特定す
    る段階； − 周期的キーフレーム間隔の終結時点でキーフレーム
    として生データフレームを指定する段階；及び − キーフレームの複数のフレーム内画素群について、
    フレーム内画素群の間の特性値間のばらつきを決定し、
    決定されたばらつきがフレーム内許容差内にある場合フ
    レーム内画素群を表わすべく特性値を特定し、各フレー
    ム内画素群の特性値を規定の特性値に設定し、同じ規定
    の特性値をもつ連続したフレーム内画素群の数を計数
    し、圧縮データビデオフレーム内に、計数された数及び
    規定の特性値を記憶する段階、 を含む、請求項２１に記載の方法。
  28. 【請求項２８】 第１のデータ群内の同一に位置づけさ
    れたデータ単位に類似したものである第２のデータ群内
    の連続したデータ単位の数（原文ｏｆ抜け）を表わすデ
    ルタをコード化する方法において、 − 受諾できるデルタ値の範囲を選択する段階； − 連続するデータ単位の数を決定する段階；及び − 決定された連続するデータ単位の数がデルタ値の範
    囲内にある場合、連続するデータ単位の決定された数と
    してデータをコード化する段階、 を含む方法。
  29. 【請求項２９】 − 決定された連続するデータ単位の
    数がデルタ値の範囲内に無い場合、エスケープシーケン
    ス、即ち計数された数及び付加的な位置づけ情報を用い
    てデルタをコード化する段階、 を含む、請求項２８に記載の方法。
  30. 【請求項３０】 − 方向的オフセットを決定する段
    階、及び − 単一の値すなわち方向的オフセットの絶対値を表わ
    す値としてデルタをコード化する段階、 を含む、データをコード化するための方法。
  31. 【請求項３１】 デルタが最大デルタ値を有し、 − 第１のランレングス値を定義づけするためランの長
    さの値に対し最大デルタ値を付加する段階； − 第１のランレングス値をコード化する段階； − 第２のランレングス値を定義づけするため特性値を
    決定する段階；及び − 第２のランレングス値をコード化する段階、 を含む、請求項３０に記載の方法。
  32. 【請求項３２】 各々１つの特性値及び１つの比例絶対
    値で形成された複数のランレングスデータ群及び各々可
    能なかぎり最大のデルタ値をもつ複数のデルタによって
    形成されている複数の圧縮データ群から、ビデオデータ
    の圧縮解除バージョンを作り出す方法において、 − 圧縮データ群を検索する段階； − 圧縮データ群がランレングス表示である場合、この
    表示の特性値を決定し、比例絶対値から可能なかぎり最
    大のデルタ値を減算することによってこの表示のランレ
    ングス値を決定し、ランレングス値に等しい数につい
    て、ビデオデータの圧縮解除バージョンの一定数のデー
    タ記憶場所の中に特性値を書き込む段階；及び − 圧縮データ群がデルタ単位である場合、デルタ単位
    の値を決定しデルタ単位の値に等しい数のデータ単位
    （原文ｏｆ抜け）だけ位置づけポインタを移動させる段
    階、 を含む方法。
  33. 【請求項３３】 ビデオデータの圧縮されたバージョン
    からビデオデータの圧縮解除されたバージョンを作り出
    すための方法において； − ビデオデータの圧縮されたバージョンから圧縮デー
    タ群を検索する段階； − 受諾できるデルタ値の範囲を識別する段階； − 圧縮データ群の絶対値を決定する段階；及び − 圧縮データ群の絶対値が受諾可能なデルタ値の範囲
    内にある場合、圧縮デルタ群の絶対値に等しいデータ値
    の数だけ位置づけポインタを移動させる段階、 を含む方法。
JP35483293A 1992-12-22 1993-12-22 ビデオデータを圧縮する方法及びシステム Expired - Lifetime JP3306207B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US07/995504 1992-12-22
US07/995,504 US5467134A (en) 1992-12-22 1992-12-22 Method and system for compressing video data

Publications (2)

Publication Number Publication Date
JPH0775090A true JPH0775090A (ja) 1995-03-17
JP3306207B2 JP3306207B2 (ja) 2002-07-24

Family

ID=25541903

Family Applications (1)

Application Number Title Priority Date Filing Date
JP35483293A Expired - Lifetime JP3306207B2 (ja) 1992-12-22 1993-12-22 ビデオデータを圧縮する方法及びシステム

Country Status (4)

Country Link
US (1) US5467134A (ja)
EP (1) EP0606629A3 (ja)
JP (1) JP3306207B2 (ja)
CA (1) CA2112051A1 (ja)

Families Citing this family (111)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06149990A (ja) * 1992-11-02 1994-05-31 Fujitsu Ltd 画像圧縮方法及び画像処理装置
JPH07154795A (ja) * 1993-12-01 1995-06-16 Canon Inc 動画像符号化装置
EP0665513B1 (en) * 1994-01-31 2002-11-20 Canon Kabushiki Kaisha Motion image editing apparatus and method
US5625712A (en) * 1994-12-14 1997-04-29 Management Graphics, Inc. Iterative compression of digital images
JPH08275170A (ja) * 1995-03-30 1996-10-18 Canon Inc 画像処理装置
US5612900A (en) * 1995-05-08 1997-03-18 Kabushiki Kaisha Toshiba Video encoding method and system which encodes using a rate-quantizer model
AU5556496A (en) * 1995-05-09 1996-11-29 Apple Computer, Inc. Method and apparatus for compressing image data
JPH09247671A (ja) * 1996-03-04 1997-09-19 Mitsubishi Electric Corp デジタル画像復号装置
US6215910B1 (en) * 1996-03-28 2001-04-10 Microsoft Corporation Table-based compression with embedded coding
US6571016B1 (en) * 1997-05-05 2003-05-27 Microsoft Corporation Intra compression of pixel blocks using predicted mean
BR9702270A (pt) 1996-05-17 1999-07-20 Matsushita Electric Ind Co Ltd Aparelho de codificacão de imagem aparelho de codificacão de imagem método de codificacão de imagem meio de gravacao do programa de codificacão de imagem
US5794010A (en) * 1996-06-10 1998-08-11 Lsi Logic Corporation Method and apparatus for allowing execution of both compressed instructions and decompressed instructions in a microprocessor
US6038590A (en) 1996-07-01 2000-03-14 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system
US5848246A (en) 1996-07-01 1998-12-08 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system
US5987245A (en) 1996-07-01 1999-11-16 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework
US6434598B1 (en) 1996-07-01 2002-08-13 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system
US6272555B1 (en) 1996-07-01 2001-08-07 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system
US6266709B1 (en) 1996-07-01 2001-07-24 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server failure reporting process
US6424991B1 (en) 1996-07-01 2002-07-23 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server communication framework
US6304893B1 (en) 1996-07-01 2001-10-16 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system
US5999972A (en) 1996-07-01 1999-12-07 Sun Microsystems, Inc. System, method and article of manufacture for a distributed computer system framework
US5745890A (en) * 1996-08-09 1998-04-28 Digital Equipment Corporation Sequential searching of a database index using constraints on word-location pairs
US5864681A (en) * 1996-08-09 1999-01-26 U.S. Robotics Access Corp. Video encoder/decoder system
US6745194B2 (en) 2000-08-07 2004-06-01 Alta Vista Company Technique for deleting duplicate records referenced in an index of a database
US5724033A (en) * 1996-08-09 1998-03-03 Digital Equipment Corporation Method for encoding delta values
US5990852A (en) * 1996-10-31 1999-11-23 Fujitsu Limited Display screen duplication system and method
US5974182A (en) * 1997-04-24 1999-10-26 Eastman Kodak Company Photographic image compression method and system
US6091850A (en) * 1997-04-30 2000-07-18 Fujitsu Microelectronics, Inc. Method of compressing and decompressing graphic images
US6181821B1 (en) * 1997-04-30 2001-01-30 Massachusetts Institute Of Technology Predictive source encoding and multiplexing
WO1999033242A1 (en) 1997-12-19 1999-07-01 British Telecommunications Public Limited Company Data communications
US6005503A (en) * 1998-02-27 1999-12-21 Digital Equipment Corporation Method for encoding and decoding a list of variable size integers to reduce branch mispredicts
GB9806767D0 (en) * 1998-03-31 1998-05-27 Philips Electronics Nv Pixel colour valve encoding and decoding
US6549652B1 (en) 1998-09-11 2003-04-15 Cirrus Logic, Inc. Method and apparatus for reducing noise during lossy transformation processes
US7158681B2 (en) * 1998-10-01 2007-01-02 Cirrus Logic, Inc. Feedback scheme for video compression system
US6310978B1 (en) 1998-10-01 2001-10-30 Sharewave, Inc. Method and apparatus for digital data compression
US6304339B1 (en) 1998-11-16 2001-10-16 Hewlett-Packard Company Compound document page data processing
US6373583B1 (en) * 1998-11-16 2002-04-16 Hewlett-Packard Company Compound document page data compression
US6624761B2 (en) 1998-12-11 2003-09-23 Realtime Data, Llc Content independent data compression method and system
US6601104B1 (en) 1999-03-11 2003-07-29 Realtime Data Llc System and methods for accelerated data storage and retrieval
US7050503B2 (en) * 1999-04-17 2006-05-23 Pts Corporation Segment-based encoding system using residue coding by basis function coefficients
US20010047473A1 (en) 2000-02-03 2001-11-29 Realtime Data, Llc Systems and methods for computer initialization
GB0007782D0 (en) * 2000-03-30 2000-05-17 Sony Uk Ltd Data compression
US6633969B1 (en) 2000-08-11 2003-10-14 Lsi Logic Corporation Instruction translation system and method achieving single-cycle translation of variable-length MIPS16 instructions
US8692695B2 (en) 2000-10-03 2014-04-08 Realtime Data, Llc Methods for encoding and decoding data
US9143546B2 (en) 2000-10-03 2015-09-22 Realtime Data Llc System and method for data feed acceleration and encryption
US7149878B1 (en) 2000-10-30 2006-12-12 Mips Technologies, Inc. Changing instruction set architecture mode by comparison of current instruction execution address with boundary address register values
US7268903B2 (en) * 2001-01-22 2007-09-11 Matsushita Electric Industrial Co., Ltd. Data transfer method, image processing method, data transfer system and image processor
US7386046B2 (en) 2001-02-13 2008-06-10 Realtime Data Llc Bandwidth sensitive data compression and decompression
US7206453B2 (en) * 2001-05-03 2007-04-17 Microsoft Corporation Dynamic filtering for lossy compression
US7107439B2 (en) * 2001-08-10 2006-09-12 Mips Technologies, Inc. System and method of controlling software decompression through exceptions
US20030086118A1 (en) * 2001-09-05 2003-05-08 Miller Steven O. Compound document page data processing
US7171444B2 (en) * 2001-11-14 2007-01-30 Sharp Laboratories Of America, Inc. Remote desktop protocol compression system
US7027982B2 (en) * 2001-12-14 2006-04-11 Microsoft Corporation Quality and rate control strategy for digital audio
CN101448162B (zh) 2001-12-17 2013-01-02 微软公司 处理视频图像的方法
US20050281470A1 (en) * 2001-12-26 2005-12-22 Adams Michael A System and method for streaming media
US7003035B2 (en) 2002-01-25 2006-02-21 Microsoft Corporation Video coding methods and apparatuses
US20040001546A1 (en) 2002-06-03 2004-01-01 Alexandros Tourapis Spatiotemporal prediction for bidirectionally predictive (B) pictures and motion vector prediction for multi-picture reference motion compensation
US7016547B1 (en) 2002-06-28 2006-03-21 Microsoft Corporation Adaptive entropy encoding/decoding for screen capture content
US6980695B2 (en) * 2002-06-28 2005-12-27 Microsoft Corporation Rate allocation for mixed content video
US7280700B2 (en) 2002-07-05 2007-10-09 Microsoft Corporation Optimization techniques for data compression
US7154952B2 (en) 2002-07-19 2006-12-26 Microsoft Corporation Timestamp-independent motion vector prediction for predictive (P) and bidirectionally predictive (B) pictures
US7433824B2 (en) * 2002-09-04 2008-10-07 Microsoft Corporation Entropy coding by adapting coding between level and run-length/level modes
DE60330198D1 (de) 2002-09-04 2009-12-31 Microsoft Corp Entropische Kodierung mittels Anpassung des Kodierungsmodus zwischen Niveau- und Lauflängenniveau-Modus
US7343291B2 (en) 2003-07-18 2008-03-11 Microsoft Corporation Multi-pass variable bitrate media encoding
US7609763B2 (en) 2003-07-18 2009-10-27 Microsoft Corporation Advanced bi-directional predictive coding of video frames
US7830963B2 (en) * 2003-07-18 2010-11-09 Microsoft Corporation Decoding jointly coded transform type and subblock pattern information
US7383180B2 (en) * 2003-07-18 2008-06-03 Microsoft Corporation Constant bitrate media encoding techniques
US7502415B2 (en) * 2003-07-18 2009-03-10 Microsoft Corporation Range reduction
US10554985B2 (en) 2003-07-18 2020-02-04 Microsoft Technology Licensing, Llc DC coefficient signaling at small quantization step sizes
US8064520B2 (en) 2003-09-07 2011-11-22 Microsoft Corporation Advanced bi-directional predictive coding of interlaced video
US8014450B2 (en) 2003-09-07 2011-09-06 Microsoft Corporation Flexible range reduction
US7724827B2 (en) * 2003-09-07 2010-05-25 Microsoft Corporation Multi-layer run level encoding and decoding
US7782954B2 (en) * 2003-09-07 2010-08-24 Microsoft Corporation Scan patterns for progressive video content
US7688894B2 (en) * 2003-09-07 2010-03-30 Microsoft Corporation Scan patterns for interlaced video content
US7707389B2 (en) * 2003-10-31 2010-04-27 Mips Technologies, Inc. Multi-ISA instruction fetch unit for a processor, and applications thereof
WO2005078989A1 (en) * 2004-02-15 2005-08-25 Matrixview Limited Repetition coded compression for encrypting highly correlated data
US7649539B2 (en) * 2004-03-10 2010-01-19 Microsoft Corporation Image formats for video capture, processing and display
US7684981B2 (en) 2005-07-15 2010-03-23 Microsoft Corporation Prediction of spectral coefficients in waveform coding and decoding
US7599840B2 (en) 2005-07-15 2009-10-06 Microsoft Corporation Selectively using multiple entropy models in adaptive coding and decoding
US7693709B2 (en) 2005-07-15 2010-04-06 Microsoft Corporation Reordering coefficients for waveform coding or decoding
US7933337B2 (en) 2005-08-12 2011-04-26 Microsoft Corporation Prediction of transform coefficients for image compression
US8599925B2 (en) 2005-08-12 2013-12-03 Microsoft Corporation Efficient coding and decoding of transform blocks
US7565018B2 (en) 2005-08-12 2009-07-21 Microsoft Corporation Adaptive coding and decoding of wide-range coefficients
US7830800B1 (en) 2006-01-12 2010-11-09 Zenverge, Inc. Architecture for combining media processing with networking
US8102916B1 (en) 2006-01-12 2012-01-24 Zenverge, Inc. Dynamically changing media compression format in compressed domain
US7873212B2 (en) * 2006-01-24 2011-01-18 Nokia Corporation Compression of images for computer graphics
US8144363B2 (en) 2006-03-22 2012-03-27 Kabushiki Kaisha Toshiba Image process system, image process method and image process program
US8711925B2 (en) 2006-05-05 2014-04-29 Microsoft Corporation Flexible quantization
US8880571B2 (en) * 2006-05-05 2014-11-04 Microsoft Corporation High dynamic range data format conversions for digital media
US8085274B2 (en) * 2006-07-18 2011-12-27 Via Technologies, Inc. Video data compression
US8311114B1 (en) 2006-12-06 2012-11-13 Zenverge, Inc. Streamlined transcoder architecture
US8238424B2 (en) 2007-02-09 2012-08-07 Microsoft Corporation Complexity-based adaptive preprocessing for multiple-pass video compression
US8054886B2 (en) * 2007-02-21 2011-11-08 Microsoft Corporation Signaling and use of chroma sample positioning information
US8184710B2 (en) 2007-02-21 2012-05-22 Microsoft Corporation Adaptive truncation of transform coefficient data in a transform-based digital media codec
US7774205B2 (en) * 2007-06-15 2010-08-10 Microsoft Corporation Coding of sparse digital media spectral data
US8254455B2 (en) 2007-06-30 2012-08-28 Microsoft Corporation Computing collocated macroblock information for direct mode macroblocks
US8750390B2 (en) * 2008-01-10 2014-06-10 Microsoft Corporation Filtering and dithering as pre-processing before encoding
US8265168B1 (en) 2008-02-01 2012-09-11 Zenverge, Inc. Providing trick mode for video stream transmitted over network
WO2009097284A1 (en) * 2008-02-01 2009-08-06 Zenverge, Inc. Intermediate compression of reference frames for transcoding
US8160132B2 (en) 2008-02-15 2012-04-17 Microsoft Corporation Reducing key picture popping effects in video
US8179974B2 (en) 2008-05-02 2012-05-15 Microsoft Corporation Multi-level representation of reordered transform coefficients
US8325800B2 (en) 2008-05-07 2012-12-04 Microsoft Corporation Encoding streaming media as a high bit rate layer, a low bit rate layer, and one or more intermediate bit rate layers
US8379851B2 (en) 2008-05-12 2013-02-19 Microsoft Corporation Optimized client side rate control and indexed file layout for streaming media
US7925774B2 (en) 2008-05-30 2011-04-12 Microsoft Corporation Media streaming using an index file
US8897359B2 (en) 2008-06-03 2014-11-25 Microsoft Corporation Adaptive quantization for enhancement layer video coding
US8406307B2 (en) 2008-08-22 2013-03-26 Microsoft Corporation Entropy coding/decoding of hierarchically organized data
US9571856B2 (en) 2008-08-25 2017-02-14 Microsoft Technology Licensing, Llc Conversion operations in scalable video encoding and decoding
US8265140B2 (en) 2008-09-30 2012-09-11 Microsoft Corporation Fine-grained client-side control of scalable media delivery
US8189666B2 (en) 2009-02-02 2012-05-29 Microsoft Corporation Local picture identifier and computation of co-located information
JP2015005835A (ja) * 2013-06-19 2015-01-08 シャープ株式会社 画像処理装置、画像形成装置及び記録媒体
KR101832418B1 (ko) * 2015-12-31 2018-02-26 네이버 주식회사 이미지 압축 품질을 최적화 하기 위한 방법 및 시스템

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1189982A (en) * 1966-06-15 1970-04-29 Xerox Corp Binary Encoding
US4897717A (en) * 1988-03-30 1990-01-30 Starsignal, Inc. Computer-based video compression system
US4958225A (en) * 1989-06-09 1990-09-18 Utah State University Foundation Full-search-equivalent method for matching data and a vector quantizer utilizing such method
US5136374A (en) * 1990-04-03 1992-08-04 At&T Bell Laboratories Geometric vector quantization
JP2549013B2 (ja) * 1990-10-08 1996-10-30 日本ビクター株式会社 データ圧縮装置
US5235418A (en) * 1991-11-19 1993-08-10 Scientific-Atlanta, Inc. Method and apparatus for low frequency removal in vector quantization
US5159449A (en) * 1991-12-26 1992-10-27 Workstation Technologies, Inc. Method and apparatus for data reduction in a video image data reduction system
US5272529A (en) * 1992-03-20 1993-12-21 Northwest Starscan Limited Partnership Adaptive hierarchical subband vector quantization encoder

Also Published As

Publication number Publication date
EP0606629A2 (en) 1994-07-20
JP3306207B2 (ja) 2002-07-24
US5467134A (en) 1995-11-14
CA2112051A1 (en) 1994-06-23
EP0606629A3 (en) 1996-02-21

Similar Documents

Publication Publication Date Title
JPH0775090A (ja) ビデオデータを圧縮する方法及びシステム
US8022963B2 (en) Method, system and software product for color image encoding
US6031937A (en) Method and apparatus for video compression using block and wavelet techniques
JP3464075B2 (ja) ディジタル画像の圧縮および圧縮解除のためのシステムおよび方法
Hang et al. Interpolative vector quantization of color images
US4319267A (en) Picture coding and/or decoding equipment
US7843998B2 (en) Method for improved entropy coding
US7675969B2 (en) Adaptive rate control for digital video compression
US5867221A (en) Method and system for the fractal compression of data using an integrated circuit for discrete cosine transform compression/decompression
EP1341126A2 (en) Image compression using a shared codebook
US6836564B2 (en) Image data compressing method and apparatus which compress image data separately by modifying color
US20040218825A1 (en) Method and apparatus for video compression using microwavelets
AU2005236504A1 (en) Method, system and software product for color image encoding
JP2002507354A (ja) 効率的なルックアップテーブルに基づく視覚的に無損失の画像圧縮方式
WO1994006098A1 (en) Improved preprocessing and postprocessing for vector quantization
CA2545414A1 (en) Image processing
US6738074B2 (en) Image compression system and method
EP1324618A2 (en) Encoding method and arrangement
CN1155256C (zh) 使用分级图象分割技术编码视频信号的装置
US5594503A (en) Image information compressing method, compressed image information recording medium and compressed image information reproducing apparatus
JP3462867B2 (ja) 画像圧縮方法および装置、画像圧縮プログラムならびに画像処理装置
US5896467A (en) Method and apparatus for encoding a contour image of an object in a video signal
CN114930815A (zh) 基于上下文和特征的视频编码预分析比特预算
US20030219167A1 (en) Method and system for forming HCVQ vector library
KR950009460B1 (ko) 부호화된 칼라 비데오 데이타를 감압하는 방법 및 시스템

Legal Events

Date Code Title Description
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20020327

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090510

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100510

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110510

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110510

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120510

Year of fee payment: 10

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130510

Year of fee payment: 11

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130510

Year of fee payment: 11

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term