JP5069349B2 - 格納およびバスバンド幅の要求を最小限に抑える効率的な画像圧縮方式 - Google Patents

Description

この特許出願は、２００７年６月２８日に提出された米国仮出願第60/946,972号に基づく利益を主張するもので、それはここに引用することで本願に併合される。

この発明は、デジタルビデオの分野に関するもので、特に、格納およびバンド幅要求を最小限に抑える効率的なエンコード方式に関する。

数多くの新たなデジタル無線通信プロトコルの急速な進展と採用により、近年では無線エレクトロニクスの変革がなされている。例えば、符号分割多元接続（ＣＤＭＡ）および移動体通信用グローバルシステム（ＧＳＭ）はデジタルセルラ電話の人気を大きく押し上げていおり、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ａなどのＷｉ−Ｆｉローカルエリアネットワーク（ＬＡＮ）プロトコルは無線コンピュータネットワークに大変革を起こし、ブルートゥース（Bluetooth（登録商標））は多くの異なるデジタルデバイスに対して極めて有益な短距離無線デジタルプロトコルを提供している。

無線プロトコルにおける進展は、ますます増大する量のデータをダウンロードし表示し格納しおよび／または検索する能力を持った携帯電子デバイスの分野で、大きく広まっている。それゆえ、現代の移動体デバイスは、通常、種々なマルチメディアアプリケーションおよびデータを用いている。現代の携帯および／または移動体デバイスは、チップ上システムあるいはシステムオンチップ（ＳｏＣまたはＳＯＣ）テクノロジーを用いており、そこでは、コンピュータあるいは他の電子システムのコンポーネンツが多数、単一の集積回路すなわちＩＣチップへ有利に集積されている。この単一チップでは、デジタル、アナログ、混合信号、および、度々高周波（ＲＦ）機能を、全て、その１チップ上に含むことがよくある。組み込みシステムは、オンチップテクノロジーの利点を度々享受している。しかしながら、このようなシステムでは、特に格納および／またはバスバンド幅の領域で、能力の限界を持つのが普通である。

ところで、マルチメディアアプリケーションは、かなり大量のバンド幅と格納リソースを用いることができる。例えば、デジタルビデオフレームの送信および／または表示では、大量のビットをサポートできる、メモリ、バッファ、チャネル、およびバスを必要とする。通常、イメージデータは、多数の画素からなるフレーム内で表される。一般的に、高解像度イメージは大量の画素を用いる。さらに、各画素は、例えば色またはルミナンスまたはクロミナンスなどの画素特性を記述する係数のセットを用いて、表される。カラーイメージでは、８ビットの係数３つの各々が、通常、１つの画素に対して用いられる。赤・緑・青システム（ＲＧＢ）およびその変形システムでは各色を表すのに２４ビットが用いられ、それは時に２４ビット画素デプスと呼ばれることもある。解像度、表示サイズ、あるいはその他の放送品位が高まると、表示フレームサイズあるいはその他の要求もさらに増加する。特に、現代のデバイスおよび放送は、旧来のＱＶＧＡ、ＶＧＡないしＸＧＡフォーマットを超えるマルチメディア情報を扱えるようになっている。

より高いデータレートのブロードバンド送信は、システムにさらなる要求をしてくる。例えば、ＬＣＤコントローラが１００Ｈｚに近いリフレッシュレートでフレームバッファからの読み取りをサポートしなければならない場合、バンド幅の境遇は悪くなる。さらに、マルチメディアアプリケーションにより用いられるマルチメディアデータの格納および／または検索でも、似たような問題が生じる。上述した問題に対するこれまでの試みは、ランレングスエンコード（ＲＬＥ）およびランレングスエンコードの変形のような圧縮技術を用いていた。しかしながら、これら従前の試みには色々な欠点がある。

効率的なフレームバッファ圧縮方式は、移動体システム、特にチップ上のシステムを用いた移動体システムにおける、格納、バスバンド幅、および／または電力消費の要求を最小限にする。幾つかの実施形態では特に効率的なロスレスイメージ圧縮方式が用いられるが、幾つかの実施形態ではさらに、付加的にロッシーなエンコードステージを用いている。ロスレス圧縮アルゴリズムおよびオプションのロッシーステージはともにイメージに対するトータル格納スペースを減らす。このことは、システムバス上のリードライトバンド幅負荷を有利に減らすことにもなる。ロスレスステージもロッシーステージも、イメージおよび／またはビデオデータの再生品位を大きく低下させることはない。エンコードされたイメージデータはさらに、タイトなスペース節約フォーマットでもって、あるいは、例えばタイルベースもしくはストライブベースのフォーマットのような、ランダムにアドレスされおよび／またはアクセスされるフォーマットでもって、フレームバッファ内に選択的にパックされる。

したがい、データ圧縮方法は、イメージを受信しそのイメージをタイルのセットにタイルする。各タイルは画素のセットを含む。この方法は、第１のタイルを選択し、第１のタイル内の画素の値の第１セットを決定する。この方法は、第１のタイル内の各画素の決定された値を、複数のストリームに分ける。第１のストリームに対して、この方法は、バイアス値を決定し、ストリーム内の各値からバイアス値を差し引いて、引算された値のセットを発生する。通常、引算された値は、1以上の先行ゼロを持っている。この方法では、好ましくは、その先行ゼロの少なくとも幾つかを除去し、第１のストリーム内の引算された値を表すのに必要なビット数を減らす。すなわち、第１のストリーム内の１以上の値はより少ないビットでもって有利に表される。

特定の実施形態では、この方法はストリーム内の値の最小値を決定し、値のストリームのうちの最小値がバイアス値となる。この値のストリームは、一般的に、タイル内の画素に関係している。これらの値は、通常、画素の属性に対する係数を含んでいる。例えば、この値は、時には赤・緑・青（ＲＧＢ）カラーシステムに対する色値であったり、あるいは、ルミナンス、クロミナンス、またはその他のサンプルされ若しくはスケールされたシステム（ＹＣｒＣｂ）などに対する他のタイプの値であったりする。

幾つかの実施形態における方法は、エンコードおよび／または圧縮におけるマルチレベルを含んでいる。具体的には、これら実施形態のうちの幾つかは、引算された値を丸めたりおよび／または切り縮めたりして丸められまたは切り縮められた値を発生し、その丸められた値をあるファクタで割る。特定の実施形態では、値が最も近い偶数などの偶数に丸められ、それが２で割られる。好ましくは、この割算処理はビットをシフトすることにより行われる。一旦エンコードされると、イメージデータは、種々な手段を用いてフレームバッファ中にパックされる。フレームバッファで密にパッキングする際は、イメージタイルデータはフレームバッファ中に順次配置され、これにより格納スペースとバス利用が維持される。逆に、タイルデータを粗にパッキングすると、イメージ（画素）データの各タイルへのランダムアクセスが可能になる。あるいは、イメージデータは、ランダムにアクセスおよび／またはアドレス可能なフォーマットで、粗にパックされた中でストライプされる。
第１のストリームは、好ましくは、第１のタイルの画素に対して第１の色を示すための係数のセットを備えている。それゆえ、第１のストリームに対して、幾つかの実施形態では、第１の色を再構成するのに十分な係数情報をバイアス値が含むかどうかを決定している。もしバイアス値が第１の色を再構成するのに十分な係数情報を含むならば、これらの実施形態はバイアス値を用いて第１の色をパケットヘッダにエンコードするが、パケットボディ内の第１の色に対しては係数のエンコードを差し控えている。さらに、第１のタイルの第１の色を忠実に再構成するのに十分な画素情報をヘッダが含むかどうかを示すために、エンコードタイプが選択される。それゆえ、デコーダはパケットヘッダをフェッチしてエンコードタイプを受信し、そのエンコードタイプを用いて第１の色をデコードする。もし、第１の色を再構成するのに十分な情報をパケットヘッダが含むことをエンコードタイプが示すならば、この方法は、有利に、パケットボディから第１の色に対する情報をフェッチするステップを差し控える。
このようなことを考慮して、特定のインプリメンテーションにおけるエンコードタイプは、次のうちの１以上を含む。それは、第１のタイルのための色情報がパケットボディ内にエンコードされていない状況を示す第１の選択、１つの色のための情報がパケットボディ内にエンコードされている状況を示す第２の選択、２つの色のための情報がパケットボディ内にエンコードされている状況を示す第３の選択、および／または、３つの色のための情報がパケットボディ内にエンコードされている状況を示す第４の選択である。状況により、色情報は、例えば、ルミナンス値および／またはクロミナンス値を含む。
さらなる実施形態においては、エンコーダは、メモリおよびステータスブロックを持つ第１のステージを含む。メモリおよびステータスブロックの各々は、入力データのセットを受信する。１つのインプリメンテーションにおいて、入力データは、例えばタイルからのストリームに対応した画素係数のセットを含む。ステータスブロックは、例えば低い側から高い側へ向かって入力データをソートするように構成されている。このエンコーダはまた、メモリの出力およびステータスブロックの出力に接続された第１の引算器を含む。第１の引算器は、メモリの出力およびステータスブロックの出力に対して演算処理を行う。例えば、ある特定の場合、ステータスブロックは最小値を出力し、引算器はその最小値をメモリからのストリームの値から差し引く。好ましくは、その最小値、すなわちバイアス値は、ステータスブロックでもって実行されるソート機能により決定されるストリーム内の最小値とする。
エンコーダは、引算器に接続された第１の論理ユニットを含む。第１の論理ユニットは、引算器の出力を受信し、選択されたフォーマットを持つビットのセットを出力するように構成される。また、エンコーダは、選択されたフォーマット内のビットのセットを受信する論理ユニットに接続されたパッカー（packer）を持っている。このパッカーは、データパケットを形成するために選択されたビットのセットを用いる。好ましくは、第１の論理ユニットは、特定のデータストリームに基づいて減少されたビット数を出力するように構成される。例えば、幾つかのインプリメンテーションでは、第１の論理ユニットは、例えば、制御信号を用いて先行ゼロなしの減少されたビット数を出力するデコードユニットを含む。これらのインプリメンテーションにおける制御信号は、好ましくは、ステータスブロックにより提供される。付加的な実施形態は、送信、受信、表示、格納、および／または検索のために、減少されたビット数を用いてデータをエンコードするエンコーダと、システムと、そして、デコーダを含む。

この発明の新規な特徴は添付された請求項に示されている。しかしながら、説明のため、この発明に係る幾つかの実施形態が以下の図に示される。
図１は、この発明の幾つかの実施形態に従うプロセス１００を示す図である。 図２は、タイルイメージを示す図である。 図３は、特定タイル内の各画素に対して３色要素に分割された図２のタイルイメージを示す図である。 図４は、バイアスが除去された後の各画素に対する３色要素を示す図である。 図５は、幾つかの実施形態に従うエンコーダを示すである。 図６は、図４のデータストリームのためのパケットを示す図である。 図７は、マルチステージエンコーダを示す図である。 図８は、図７のエンコーダのためのパケットを示す図である。 図９は、この発明の実施形態に従うデコーダを示す図である。 図１０は、デコードプロセスを示す図である。 図１１は、フレームバッファ内で密にパックされたタイルを示す図である。 図１２は、フレームバッファ内で粗にパックされたタイルを示す図である。 図１３は、フレームバッファ内のストライプを示す図である。 図１４は、この発明の実施形態に従う幾つかのテストイメージを示す図である。 図１５は、幾つかの実施形態における別のエンコードシステムを示す図である。 図１６は、図１５のエンコード用のパケットを例示する図である。 図１７は、図１５のエンコードおよび／または図１６のパケット用のヘッダを例示する図である。 図１８は、幾つかの実施形態におけるエンコードシステムを示す図である。 図１９は、図１８のエンコード用のパケットを例示する図である。 図２０は、図１８のエンコードおよび／または図１９のパケット用のヘッダを例示する図である。 図２１は、幾つかの実施形態におけるデコードシステムを示す図である。 図２２は、エンコードフォーマットを例示する図である。

詳細な説明

以下の記述では、説明目的で多くの詳細や変形例が示されている。しかしながら、当業者ならこれらの詳細を用いずともこの発明を実施することは可能である。また、不必要に細かくすることで発明の記述が返って不明瞭にならないよう、周知の構成やデバイスはブロック形式で示すようにしている。

Ｉ．方法およびエンコーダ
この発明の幾つかの実施形態は、格納およびバンド幅要求を最小限にする効率的なロスレスイメージ圧縮方式を含んでいる。これらの実施形態は、特に、移動体システムのための１以上のチップ上システム（ＳＯＣｓ）で採用される。例えば、特定のインプリメンテーションは、イメージのためのトータル格納スペースを減らすために単純なロスレス圧縮アルゴリズムを含んでいる。イメージのために要求される減少された格納スペースは、付加的な利益をもたらす。例えば、バス上でのリードおよび／またはライトのバンド幅負荷が減るといった利益がある。このことはさらに、システムのオーバーオールパフォーマンスを有利に改善する。さらに記載されることとして、アルゴリズムの利点を享受するフレームバッファインプリメンテーションがある。

通常、処理されメモリに格納されるイメージはフルにサンプルされたタイプであり、色の画素を表すために８ビットを全て占有する。しかしながら、イメージ内の全ての画素が色の忠実な再現のために８ビット全てを必要とするわけではない。一般的に、イメージには、類似の色の画素あるいは係数値が狭い範囲内にある画素を持っている部分がある。幾つかの実施形態では、イメージのうち、色すなわち係数値の範囲が狭い領域の利点を享受している。これらの実施形態では、好ましくは、減少されたビット数を用いて色係数を量子化する。

この方式において重要な属性の１つであって、色の格納に用いるビット数を減らすことの助けになるものとして、イメージのある領域から他の領域への画素値の大きな遷移に限界をつけあるいは制限するところのタイリングプロセスがある。この発明の実施形態はさらに、好ましくは、ローパスフィルタにかけられたイメージおよび／または類似色の領域を多数持つイメージに対して、高い圧縮比を達成する。さらに、これらの実施形態は、例えばＹＣｂＣｒあるいはＲＧＢのような種々なデータフォーマットに適用可能である。

図１は、イメージを圧縮するプロセス１００を含む特定の実施形態を示す。同図に示すように、プロセス１００は、イメージが受信されタイルされるステップ１１０で始まる。好ましくは、タイリングイメージは、イメージ画素をディスクリートなセットに分割することを備えている。そして、プロセス１００は、タイル内の各画素に対する色が分離されるステップ１２０に遷移する。好ましくは、このタイルは、例えば赤、緑、および青といった３つのカラーストリームに分離される。

特定の実施形態では、各画素の色値は８ビットを用いて表され、タイルの色は８ビット値の３ストリームとして処理される。ここで１つのストリームは各色のために用意されている。それゆえ、もし各タイルのサイズがＭｘＭであるとすれば、８ビット値のＭ^２倍の３ストリームが存在することになる。好ましくは、各ストリーム（例えば赤、緑、および青用の）は、圧縮の際は別々に処理される。

タイル用の色およびストリームがステップ１２０で一旦決定されたら、プロセス１００はステップ１３０に遷移する。ここでは、カラーストリーム各々に対する最小値（バイアス）が決定され、それが各ストリームから差し引かれる。この値が差し引かれた結果のストリームは、減算による残りの値であり、通常は元のストリームよりも小さな値を含む。

次に、プロセス１００はステップ１４０に遷移する。ここでは、各カラーストリーム値から先行ゼロが除去される。これは有利なことで、減算後の各ストリーム内の値の幅がより少なくなり、少ないビット数で表されるようになる。これは、先行するゼロを取り除くことでなされるが、減算の残りにはその最大値がなお残留できるようになっている。このステップ１４０のあと、プロセス１００は終了する。

例えば、タイルが４画素掛ける４画素で構成されている場合、そのタイルに対する単一のカラーストリームは１６画素の色値を含む。例えば、もし赤ストリーム内の最大値が６しかないとすれば、先行ゼロを取り除くことにより、このストリーム内の各値を表すのに必要なビット数はたった３となる。というのも、このストリーム内の最大値は、例えば２進表示で“１１０”となるからである。

II．絵柄の例
図２は、上述した方法および／またはエンコーダの動作におけるイメージ２００の例を示す。同図に示すが、このイメージは、好ましくは、第１のタイル２０１で例示されるように、タイルに分割されている。前述したように、タイリングステップは、通常、ストリームの画素値内の変動を減らす。さらに、図２から気付くであろうが、イメージの領域は画素値内に大きな変動を持たず、タイル内の全ての色を表すのに、フル８ビット画素デプスの全ての値は必要でない。

図３および図４は、イメージ３００内の冗長な情報が、バイアスおよび／または先行ゼロの除去を介して、如何に減少されるかを図解している。図３に示すように、タイル３０１に対するカラーコンポーネンツは、３つのストリーム、すなわち、赤３０２、緑３０４、および青３０６のカラーストリームに分割される。ここでは、各カラーストリームに対する係数が、チャート形式で、グラフ表示されている。これらのチャートのｘ軸でさらに示されるように、４掛ける４のタイルは１６画素を持ち、そのｙ軸は各画素の強度に対応した係数値を含んでいる。図３では、生のイメージデータは通常通り８ビットフォーマットであり、それゆえ、係数値はおよそ０ないし２５５の幅を持っている。

図４は、各ストリームのバイアス値が決定されそれがストリームから差し引かれたあとの、各ストリーム４０２、４０４、および４０６のカラーコンポーネンツを示す。これは有利なことであるが、タイル内には各画素に対して差分情報が残されている。したがい、画素係数値の間の差分が図４ではより明確に示されている。さらに、図示するように、３つのストリーム（赤、緑、および青）内の最大値は６より大きくない。そのため、画素値を表す減算の残りをフルに表現するのに、８ビット全ては必要でなく、たった３ビットで済む。図１に関連して前述したように、一旦、バイアス値が各カラーコンポーネントの係数から差し引かれたならば、必要最小限のビット幅で、減算の残りを忠実に表すための計算を有利に行うことができる。さらに、図５ないし図８に関連してさらに後述するが、過剰な先行ゼロは好ましくは除去されもしくは連結される。

図５は、幾つかの実施形態におけるエンコーダ５００のブロック図を示す。このエンコーダ５００はエンコードされた色情報およびヘッダをタイルにパックする。ヘッダは、タイルをどのようにデコードするのかを記述している。以上を実現するために、エンコーダ５００は、それぞれが入力データストリームを受信するところの、メモリ５０２およびステータスブロック５０４を含んでいる。メモリ５０２は、通常、タイルに対するストリーム値を格納するのに十分な規模を持つランダムアクセスメモリ（ＲＡＭ）の形式を備えている。一方、ステータスブロック５０４は、例えば、低い側から高い側に向かってタイルの値を格納するように構成されている。

メモリ５０２は引算器５０６に出力し、この引算器はステータスブロック５０４からバイアス入力を受信する。通常、このバイアスは、ステータスブロック５０４により決定された、タイル内の最小値を備えている。引算器５０６は、メモリ５０２からのストリーム値からバイアスを差し引き、デコーダ５０８に出力する。デコーダ５０８は、引算器５０６の結果を表すのに必要な最小限のビット数を有利に出力するもので、そのビットをパッカー（packer）５１０に出力する。図示されたインプリメンテーションは１−８デコーダ（one-to-eight decoder）５０８を含んでおり、このデコーダはステータスブロック５０４から受信した格納サイズに基づき必要最小限のビットを出力する。しかしながら、当業者なら、バス幅およびビット数の変更を含め、システム５００のデコーダ５０８およびその他のコンポーネンツに対して別のインプリメンテーションが可能なことを認識するであろう。

パッカー５１０はまた、タイルスタートアドレス、バイアス、格納サイズ、およびタイルサイズを（ステータスブロック５０４から）受信し、特定のタイルに対して圧縮されたデータストリームを出力する。好ましくは、パッカー５１０の出力は１以上のパケット形式である。これら実施形態のパケットについては、図６に関連してさらに記述される。

図６は、図４のストリームに対する、パケット６００を示す。図６に示すように、パケット６００は、パケット６００のヘッダを構成するところのタイルサイズ６０２とバイアス６０４と格納サイズ６０６に対するフィールド、および、画素データ６０８に対するフィールドを、含んでいる。特定の図示された例では、タイルサイズと格納サイズを表すには３ビットあれば足りているが、バイアスに対しては８ビットを必要としている。残りを表すのに必要なバイアスおよびビットは、ヘッダにパックされ、各ストリーム（赤、緑、および青）に対する残りの値に連結される。

この例では、格納、検索、および／または表示のために、タイル当たり合計１８０ビットが必要となっている。この１８０ビットは、ヘッダに対する３６ビットと、各ストリームの画素データに対する４８ビットを含んでいる。
１８０ビット＝［３６ヘッダビット＋３ストリーム＊（３ビット／画素 ＊ １６画素／タイル）］
より具体的にいうと、この例のヘッダは、３つのパラメータ、すなわちバイアス、格納サイズ、およびタイルサイズに対して、次のフォーマットを用いている：
２４バイアスビット＝（各ストリームのバイアス値に対する８ビット＊３ストリーム）
９格納サイズビット＝（各ストリームに対する格納サイズ３＊３ストリーム）
３タイルサイズビット、というのも、この例における各ストリームは同じタイルサイズを用いていることから、３つのストリーム全てに対して１フィールドしか必要としないため。すなわち、この例の３つのストリームに対する合計ヘッダビットは、３６＝（２４バイアスビット＋９格納サイズビット＋３タイルサイズビット）となる。圧縮なしでは、同じイメージデータを格納するのに合計３８４ビット必要になる。
３８４ビット＝（１６画素／タイル ＊ ２４ビット／画素）
すなわち、圧縮比は（１８０ビット／２８４ビット）で４６．６％になる。
当業者なら、多くの変形が可能であることを認めるであろう。例えば、特定の実施形態の試験中に、４×４タイルサイズは、処理速度と圧縮比など品質と性能のバランスが特に良いことが認められた。それゆえ、幾つかの実施形態では、タイルサイズを４×４に固定し、ヘッダのオーバーヘッドにおいてタイルサイズパラメータのエンコードおよび／または通過をする。これらの実施形態では、それぞれのパケットヘッダ内で３ビットの節約をし、圧縮比および速度の面で改善をしている。

III．ロッシーステージのエンコード
エンコードの第２レベルは、圧縮比をさらに上げるために残りの値に対しオプションとして行われる。この圧縮の第２レベルでは、減算された値を丸めてその値をあるファクタで割ることにより、カラーストリーム内の各値のビット幅をさらに減らしている。例えば、特定の実施形態では、その値は最も近い偶数に丸められ、および／または２で割られる。それゆえ、第２の圧縮はロッシーとなる。なぜなら、元のタイル内の画素係数値からバイアスを差し引いたあと偶数値化された残りの値には、エンコードおよびデコードのプロセス（エンコーダにおける２による割算および、デコーダにおける２による掛算）中に、量子化レベルのあるいは最小桁ビット（LSB）の欠落が生じるからである。しかしながら、このインプリメンテーションでは、奇数の係数を持つ画素だけが僅かなロスを被るだけで、偶数の係数を持つ画素にはロスは生じない。

さらに、以下に述べるように、このインプリメンテーションをテストする実験では、情報のロスがあっても視覚上何ら目立つ効果は認められていない。その上、第２の圧縮ステージは、圧縮比において１２．５％もの有利な改善をもたらしている。さらにまた、第２の圧縮は、例えば所望のイメージ品質および／または所望の圧縮比に応じて、ソフトウエアにより、選択的に稼動状態（enabled）または非稼動状態（disabled）にされる。さらに、除数のファクタは、例えば、４，８，１６といった任意の２の倍数とすることが好ましい。より大きなファクタを用いるとより高いロッシーステージの圧縮が得られるが、それに対応した品質のロスも伴う。しかしながら、減少された画素情報による解像度の低下は、プレビューモード、ローパワーモード、および／またはスタンバイモードの場合のように、時には望ましいこともある。ビットシフタは、通常、デジタルロジック内に割算機能を提供する。これにより選択可能なNビットロッシーエンコーダのインプリメントが容易になる。１ビットロッシーエンコーダの場合は、シフタは１最小桁ビットをシフトする。

図７は、第１レベル（ロスレス）および第２レベル（ロッシー）のエンコーダ７００を含む実施形態を示す。同図に示すように、エンコーダ７００は、メモリ７０２、ステータスブロック７０４、引算器７０６、デコードユニット７０８、およびパッカー７１０を含んでいる。これらのコンポーネンツは、好ましくは、図５に関連して前述したように接続され動作する。

２ステージエンコーダ７００は、シフトモジュール７１２、引算器７１４、および２つのマルチプレクサ７１６および７１８を含む付加ステージを、さらに含んでいる。２つのマルチプレクサは、第１（ロスレス）ステージのエンコードのみか、第１（ロスレス）および第２（ロッシー）ステージの両方を行うエンコードのいずれかを選択するロッシーイネーブル信号を受信する。シフトモジュール７１２は、通常、丸めおよび／または切り縮め動作を提供するように構成されている。当業者ならわかるであろうが、選択的なビットのシフトによる割算はよく用いられている。例えば、１ビットの右シフトはレジスタ内のビット上で２による割算操作を都合よくもたらし、２ビットシフトは４による割算操作をもたらす。

シフトモジュール７１２およびマルチプレクサ７１６は、引算器７０６とデコーダ７０８の間に接続されている。この接続は、マルチプレクサ７１６が引算器７０６の出力とシフトモジュール７１２の出力を受信し、それらのいずれかの出力がロッシーイネーブル信号に応じてデコーダ７０８へ提供されるように、行われる。

引算器７１４およびマルチプレクサ７１８は、ステータスブロック７０４とパッカー７１０の間に接続されている。この接続は、マルチプレクサ７１８がステータスブロック７０４の出力または引算器７１４の出力を選択し、選択された出力が格納サイズとしてパッカー７１０へ提供されるように、行われる。引算器７１４は、ロッシーステージがイネーブルとなると、選択的に、格納サイズを１だけデクリメントする。

図８は、図７のエンコーダのためのパケット８００を例示している。パケット８００は、タイルサイズ８０２とバイアス８０４と格納サイズ８０６のフィールドを持つヘッダ、および、画素データ８０８のフィールドを含んでいる。同図に示すように、４画素掛ける４画素のタイルサイズが、たった２ビットに有利に減らされている。さらに、ロスレスおよびロッシーステージの両方が動作したあとは、各ストリームに対する格納サイズも僅か３ビットとなっている。前述したように、エンコード、送信、処理、および／または格納における付加的なオーバーヘッドの節約のために、固定されたおよび／または所定のタイルサイズを持つ実施形態では、タイルサイズフィールドは省略される。

III．デコーダ
図９は、幾つかの実施形態に係るデコーダ９００を示す。同図に示すように、デコーダ９００は、入力データを受信しアンパッカー９０４およびヘッダデコードモジュール９０６へ出力するデータフェッチ９０２を含んでいる。アンパッカー９０４は、受信された入力データ内の各画素に対して８ビット幅フォーマットを形成するために失われた先行ゼロの拡張を行い、８ビット幅データを加算器９０８へ出力する。

加算器９０８は、ヘッダフィールド内に含まれる情報を抽出するヘッダデコーダ９０６から、バイアスを受信する。この加算器９０８は、バイアス（８ビットフォーマット）を各画素に対する受信値に加算し、合計値をメモリ９１０へ出力する。前述したように、受信データは度々画素のタイルに対するストリームを備えている。それゆえ、これらの実施形態のメモリ９１０は、好ましくは、ヘッダデコードモジュール９０６から受信されるものとして、あるいは、システム９００内で予め定められおよび／または固定されたものとしての、画素タイルサイズのタイルの規模（dimensions）を持つ。メモリ９１０の出力は、特定タイルの特定ストリームに対してデコードされた画素値を持つ。それゆえ、デコーダ９００の図示されたインプリメンテーションは、前述したエンコーダとは逆のステップを実行する。

図１０は、図９のデコーダのステップを纏めたプロセス１０００を示す。このプロセス１０００は、やってくるビットのセットが受信されるステップ１０１０から始まる。その後、プロセス１０００はステップ１０２０へ遷移し、そこで、やってくるビットはヘッダを抽出するために解析される。一旦ヘッダが抽出されると、プロセス１０００はステップ１０３０へ遷移する。そこでは、ヘッダ内のビットが、例えばエンコードされたストリーム毎に使用されるビット数、バイアス、および／またはタイルサイズなどのシステム用パラメータのセットに関する情報を決定するために、使用される。次に、ステップ１０４０において、画素ビットがアンパックされてバイアスに加算される。こうして、やってくるビットのセット内で送信された特定タイルに属する、特定ストリームのためのデコードされた画素値が得られる。そして、プロセス１０００は終了する。

IV．フレームバッファインプリメンテーション
前述したエンコーダおよび／または圧縮方式の利点を享受するために、このセクションでは、２つの択一的インプリメンテーションが示される。これらのインプリメンテーションは、密にパックされたインプリメンテーション（tightly packed implementation）と、租にパックされたインプリメンテーション（loosely packed implementation）を含む。

Ａ．フレームバッファ内の密にパックされたタイル
第１のインプリメンテーションでは、１つの長いビットのストリーム内で、圧縮されたタイルが一緒に密にパックされるべきことが要求される。密にパックされたタイルは、順に、フレームバッファ内で密に格納される。フレームバッファ内の密にパックされたタイルの格納は、格納リソースを効率的に使用するもので、さらに、バスの最も効率的な使用も可能にする。例えば、密にパックされたフレームバッファを用いて、デコーダ内のデータフェッチユニットは、バス上の各トランザクションに対して最大のバーストサイズを用いることが可能になる。この密にパックされたインプリメンテーションはまた、メモリを効率的に使用し、フレームバッファ内のタイルにランダムにアクセスする必要がないアプリケーションに対して特に有用となる。密にパックされたフレームバッファを用いるであろう処理ブロックの１つとして、液晶表示（ＬＣＤ）コントローラがある。

図１１は、フレームバッファ１１００内の密にパックされたタイルを示す。同図に示すように、タイル１、タイル２、タイル３、…タイルＮのようにラベルが付されて示されている密にパックされたタイルは、元のフレームバッファ境界１１０２とは異なる境界１１０４を持っている。このパックされたタイルは、有利に、格納要求を減らしている。

しかしながら、密にパックされたフレームバッファにも不利な点はある。タイルにランダムアクセスする必要があるアプリケーションは、密にパックされたフレームバッファ内から要求されたタイルを見つけ出すために、フェッチエンジンがフレームバッファの先頭からサーチすることを要求する。このことは、大きな遅延をもたらし、バスの非効率的な使用に繋がる。

それゆえ、幾つかの実施形態では、個々のタイルのアドレスを、ある種のパラメータ、例えばタイルの幅（width）、高さ（height）、および／またはｙ幅（y-stride）を用いて算出できるようにして、租にパックされたフォーマットで圧縮されたタイルを格納するようにしている。

Ｂ．フレームバッファ内の租にパックされたタイル
第２のインプリメンテーション方式では、事前配分フォーマット（pre-allocated format）を用いて、メモリ内に圧縮されたタイルを配置する。例えば、これらのインプリメンテーションの幾つかは、隣接するタイルまたはタイルのストライプから一定のバイトオフセットを持つメモリ内の点から始まるように、各タイルの配置を行いまたはアドレスを付与している。各事前配分されたアドレスにおけるタイルは圧縮されており、メモリ内では事前配分されたときよりも少ない格納スペースしか要求しない。

このインプリメンテーションの有利な点は、フレームバッファ内のタイルまたはタイルのストライプ各々の開始点が、例えばｙ幅、タイルサイズ、および／またはストライプサイズなどの特定の属性を用いたアドレス計算により、容易に決定されることである。したがい、アプリケーションは、フレームバッファ内の個別タイルにランダムアクセスできるようになる。

図１２は、フレーム境界１２０２を持つフレームバッファ１２００内で租にパックされたタイルを示す。同図に示すように、フレームバッファ１２００は、サイズは可変であるが固定サイズのアドレスロケーションに配置された、圧縮タイル１ないしＮを含んでいる。各アドレス可能なロケーションは、所定の固定幅tile_wおよび高さtile_hを持っている。好ましくは、各アドレス可能なロケーション内の未使用スペースは、各ロケーションをランダムにアクセスできるようにするために、ブランクのままにしておく。図１２の図解では、ｙ幅パラメータはフレームバッファの幅として定義され、事前配分されたアドレスロケーションはフレームバッファの幅またはｙ幅の固定倍を占有する。

図１３は、圧縮されおよび／またはエンコードされた画素データがストライプされたフォーマットでフレームバッファ１３００に交替にパックされた様子を示す。同図に示すように、ストライプ１からストライプＮまでの各ストライプに対するアドレス可能なロケーションは、固定された規模（高さと幅）を持つ。図１３の図解では、ストライプはタイルの高さ（tile_height）×フレームバッファのフレーム幅（frame_width）として定義され、そのフレームバッファ１３００の幅がｙ幅となっている。

図１２に示すようなタイル境界ベースのパッキング方式においてタイルにアクセスする際は、１つのタイルだけアクセスされる。しかしながら、図１３に示すようなストライプ境界ベースのパッキング方式においてタイルにアクセスする際は、ストライブ全体が読み取られ、タイル上の操作を行う前に圧縮解凍される必要がある。図１３のストライプ構成には有利な点がある。例えば、ｙ幅すなわちイメージ幅がおよそ１０２４画素であるとき、４掛ける４画素のタイルサイズ（tile_size）に対しては、単一のストライブは好ましくは２５６のタイルを含む。このような構成では、例えばＳＤＲＡＭのページ負荷は２５６タイルの全てに有利に負荷されるが、このことは、バス、メモリ、およびページ負荷のより効率的な利用をもたらす。この効率には、イメージローディング速度の面とパワー効率の面の双方が係る。それというのも、ページメモリの各ローディングおよび／またはリフレッシュには、潜在的に、パワーおよび／または遅延が要求されるからである。

Ｖ．結果
ＲＧＢ８８８フォーマットの幾つかの異なるイメージはＭＡＴＬＡＢで記述されたコードを用いて圧縮され、その圧縮比が、他のロスレス圧縮方式、すなわち通常のランレングスエンコードにより得られる結果と比較された。そのシミュレーションにおいて幾つかの異なるタイルサイズが用いられ、前述した例と同様な４×４のタイルサイズでは良好な結果が得られた。以下の表１は、前述したレベル１（ロスレス）およびレベル２（ロッシー）エンコード方式を含めた、通常のＲＬＥ２４エンコードと本願発明の実施形態との間の比較例を示す。

V. Results
表１に示すように、タイル圧縮方式を評価するのに用いたテストイメージは、休み場所（roost）、モビル（mobile）、ｑｃ、Ｖプレーヤ（vplayer）、友達（friends）、指名手配（wanted）、星の船（starcraft）、ダイアブロ２（diablo2）、アドベテキスト（Adobe text）、アイコン（icons）、ｈｐ、ｈｐ１、およびｈｐ２を含んでいる。これらのイメージは、図１４では、アンパックされデコードされたグループ１４００として視覚的に示されているが、ここには知覚できるような画像品質の低下は殆どあるいいは全く見られない。

下記の表１は、通常のＲＬＥ２４エンコードを用いた場合と幾つかの実施形態のエンコードを用いた場合に得られる結果の例を示している。当業者なら、他の実施形態では圧縮比が変化することを認識するであろう。例えば、この発明の幾つかのインプリメンテーションではより大きな圧縮比を示している。

レベル１およびレベル２（ロッシー）のインプリメンテーションは、動画イメージあるいはビデオに対してさらに有利に適用される。表２では、テストムービークリップは左カラムにリストされ、各クリップに対する圧縮比は、１００フレームを超える平均として、右カラムに記載されている。

前述した実施形態のロッシー圧縮方式でもってエンコード（およびデコード）された表２の圧縮解凍ムービークリップは、インターネットあるいはその他のソースから入手可能である。

表１および２において、色における最大のエラーは、バイアスを差し引いた結果としての残り値において奇数値を持つ画素係数値を持った色に対する、１最小桁ビット（ＬＳＢ）、すなわち１量子化レベルである。バイアスを差し引いた後の残り値において偶数値を持つ画素を持った色に対しては、エラーは生じない。さらに、レベル２（ロッシー）圧縮のイメージであっても目立ったアーチファクト（artifact）は認められていない。したがい、この発明のインプリメンテーションは、品質において大きなトレードオフを伴わない圧縮を提供する。幾つかの実施形態により有利に達成される圧縮比は、次のように表される：

幾つかの実施形態ではデータパケットのヘッダ部分における冗長な情報も除去することにより、また幾つかの実施形態では例えばオプションのタイルサイズパラメータなど固定されたパラメータを含めることを差し控えることにより、上記よりさらに圧縮比を改善する。さらに、この発明の実施形態は、マルチレベルのエンハンスされたエンコードおよび／または圧縮の観点で、従前の技術に対して特定の長所を持つ。例えば表に示すように、ＹＣｂＣｒの例はＲＧＢの例よりも大きな圧縮を示す。これは、ＹＣｂＣｒフォーマットはそれ自身エンコードされたフォーマットであり、前述した実施形態は、存在するエンコードされたフォーマットに対して、大きな付加的マルチレベルエンコードの改善をもたらすからである。

付加的な実施形態についてさらに記載する。例えば、図１５は、幾つかの実施形態のエンコードシステム１５００の他例を示す。同図に示すように、エンコードシステム１５００はメモリ１５０２とステータスブロック１５０４を含み、これらは各々入力データストリームを受信する。このインプリメンテーションでは、データは、２４ビットの、すなわち３つの色各々に対して８ビットの、ＲＧＢ、ＹＣｂＣｒなどを含む。メモリ１５０２は、通常、タイルのストリーム値を格納するのに十分な規模を持つランダムアクセスメモリ（ＲＡＭ）形式を備え、一方、ステータスブロック１５０４は、例えば、低い側から高い側への値を格納するようになっている。特定のインプリメンテーションでは、メモリ１５０２は４×４のタイルを受信する。

ステータスブロック１５０４は、種々で有用な値を有利に決定する。例えば、ステータスブロック１５０４は、やってくる３色データ値（tri-chromatic data values）をソートし、好ましくは、色のバイアス値として各色の最小係数を用いる。このバイアス値は、２４ビットすなわち各色あたり８ビットを用いて出力される。ステータスブロック１５０４は、残り用の格納サイズをさらに決定し、それを９ビットを用いてパッカーに出力する。ステータスブロック１５０４は、圧縮されたタイル内のエンコードタイプとトータルバイトを決定し、これらをヘッダモジュール１５２０に出力する。ヘッダモジュール１５２０はまた、ステータスブロック１５０４からバイアス値を受信し、図１７に示すようなヘッダを発生する。

メモリ１５０２は、ステータスブロック１５０４からバイアス入力を受信する引算器１５０６へ、出力を行う。通常、このバイアスは、ステータスブロック１５０４により決定されたタイル内の最小値を備える。引算器１５０６は、メモリ１５０２からのストリーム値からバイアスを差し引いて、パッカー１５１０へ出力する。パッカー１５１０はまた、タイルスタートアドレス、バイアス、格納サイズ、およびタイルサイズ（ステータスブロック１５０４からの）を受信し、特定のタイルに対して圧縮されたデータストリームを出力する。この出力は、好ましくは、ステータスブロック１５０４から受信した格納サイズに基づき必要とされる最小ビット数を備える。当業者なら、バス幅およびビット数の変更を含め、パッカー１５１０およびシステム１５００のその他のコンポーネンツに対して異なるインプリメンテーションが可能なことを認識するであろう。

パッカー１５１０の出力は、１以上のパケットの形態であることが好ましい。これらの実施形態のパケットについては図１６に関連してさらに記述し、そのヘッダは図１７に示す。

図１６は、図１５のエンコードのためのパケット１６００を例示している。このパケット１６００は、好ましくは、９ビットの、すなわち、例えばｒサイズ、ｇサイズ、ｂサイズといった各色毎３ビットの、プレアンブルを持つ。同図に示すように、各色に必要なサイズは、３ビットコードフォーマットを用いて有利にエンコードされている。より具体的にいうと、各色をエンコードするためのビット数は、コード（例えば１ビットに対して０００、または８ビットに対して１１１）に応じて、１から８ビットまで変化する。そのボディはさらに、例えばＲＧＢインターリーブドフォーマットのような、圧縮されたタイル用のデータを含んでいる。

図１７は、図１５のエンコードおよび／または図１６のパケットのためのヘッダ１７００を例示している。同図に示すように、ヘッダ１７００は、エンコードタイプ、バイト数、および３色のバイアス値（tri-chromatic bias values）を含んでいる。このインプリメンテーションでは、ヘッダ１７００は、例えば、エンコードタイプ用の４ビット、たすバイト数用の４ビット、たす３つの色各々のバイアス用の８ビットすなわち２４ビットを、用いている。しかしながら、当業者であれば、このヘッダに対して別のインプリメンテーションが可能なことを認識するであろう。この図に示すように、バイト数のフィールドは、８バイト（０００１）から５６バイト（０１１１）までの、８ビットの倍数のサイズを表している。同様に、エンコードタイプのフィールドは、図示するように、複合エンコード方式（multiple encoding schemes）を許容している。

図１８は、幾つかの実施形態のエンコードシステム１８００を示す。具体的には、図１８は、第１レベル（ロスレス）および第２レベル（ロッシー）のエンコーダ１８００を含む実施形態を示している。同図に示すように、エンコーダ１８００は、メモリ１８０２、ステータスブロック１８０４、引算器１８０６、およびパッカー１８１０を含んでいる。これらのコンポーネンツは、好ましくは、図１５に関連して前述したように接続され動作する。

例えば、メモリ１８０２およびステータスブロック１８０４は各々入力データストリームを受信する。幾つかのインプリメンテーションでは、そのデータは、２４ビット、すなわちＲＧＢ、ＹＣｂＣｒなどの３色（three tri-chromatic colors）各々に対して８ビットを含んでいる。メモリ１８０２は、通常、タイルのストリーム値を格納するのに十分な規模のランダムアクセスメモリ（ＲＡＭ）形式を備えており、一方、ステータスブロック１８０４は、例えば低い側から高い側へタイルの値をソートするようになっている。特定のインプリメンテーションでは、メモリ１８０２は４×４のタイルを受信するようになっている。

ステータスブロック１８０４は、種々で有用な値を有利に決定する。例えば、ステータスブロック１８０４は、やってくる３色データ値（tri-chromatic data values）をソートし、好ましくは、色のバイアス値として各色の最小係数を用いる。ステータスブロック１８０４は、好ましくは、２４ビット、すなわち各色あたり８ビットを用いて、バイアス値を出力する。ステータスブロック１８０４はさらに、残りの格納サイズを決定し、９ビットを用いてそれを引算器１８１４およびマルチプレクサ１８１８へ出力する。以下これらについてさらに述べる。ステータスブロック１８０４は、圧縮されたタイルにおけるエンコードタイプおよびトータルバイトを決定し、それらをヘッダモジュール１８２０へ出力する。ヘッダモジュール１８２０はまた、ステータスブロック１８０４からバイアス値を受信し、図２０に示すようなヘッダを発生する。

メモリ１８０２は、ステータスブロック１８０４からバイアス入力を受信する引算器１８０６へ、出力を行う。通常、このバイアスは、ステータスブロック１８０４で決定されたタイル内の最小値を備える。引算器１８０６は、バイアス（ステータスブロック１８０４を介して受信されたもの）をメモリ１８０２からのストリーム値から差し引き、マルチプレクサ１８１６およびシフタ１８１２へ出力する。マルチプレクサ１８１６は、ロッシー圧縮イネーブル信号（lossy_comp_enable）に基づいて引算器１８０６の出力またはシフタ１８１２の出力を選択し、パッカー１８１０へ出力する。パッカー１８１０はまた、タイルスタートアドレス、タイルサイズ、および格納サイズ（ステータスブロック１８０４を介したもの）を受信し、ステータスブロック１８０４から受信した格納サイズに基づいて必要最小限のビット数で出力する。しかしながら、当業者なら、バス幅およびビット数の変更を含め、パッカー１８１０およびその他のコンポーネンツに対して異なるインプリメンテーションが可能なことを認識するであろう。

上述したように、パッカー１８１０は、特定のタイルに対して圧縮されたデータストリームを出力する。パッカー１８１０の出力は、１以上のパケットの形態であることが好ましい。これらの実施形態のパケットについては図１９に関連してさらに記述し、そのヘッダは図２０に示す。

それゆえ、２ステージのエンコーダ１８００は、シフトモジュール１８１２、引算器１８１４、および２つのマルチプレクサ１８１６および１８１８を含むところの付加ステージを、さらに含んでいる。この２つのマルチプレクサは、第１（ロスレス）ステージのエンコードだけ、または、第１（ロスレス）および第２（ロッシー）ステージの両方のエンコードを選択するロッシー圧縮イネーブル信号を、受信する。シフトモジュール１８１２は、通常は、丸め、および／または、２による割算もしくは切り縮め動作を提供するように、構成される。当業者なら認識するであろうが、割算は選択的なビットシフトにより容易に提供される。例えば、１ビットの右シフトはレジスタ内で２による割算動作を有利にもたらし、２ビットシフトは４による割算をもたらす。

シフトモジュール１８１２およびマルチプレクサ１８１６は、マルチプレクサ１８１６が引算器１８０６の出力とシフトモジュール１８１２の出力を受信し、ロッシー圧縮イネーブル信号に応じてその一方または他方の出力がパッカー１８１０に提供されるように、引算器１８０６およびパッカー１８１０の間に接続される。

引算器１８１４およびマルチプレクサ１８１８は、マルチプレクサ１８１８がステータスブロック１８０４の出力または引算器１８１４の出力を選択し選択された出力が格納サイズとしてパッカー１８１０に提供されるように、ステータスブロック１８０４およびパッカー１８１０の間に接続される。この図にさらに示されるように、ロッシーステージがイネーブルになると、引算器１８１４は、格納サイズを１だけ選択的にデクリメントする。当業者なら認識するであろうが、別の実施形態では、例えば１、２、３、４、若しくはその他の数Ｎのような、異なる量で格納サイズをデクリメントすることも可能である。

図１９は、図１８のエンコード用のパケット１９００を例示している。このパケット１９００は、好ましくは、９ビットの、すなわち例えばｒサイズ、ｇサイズ、ｂサイズというように各色毎３ビットのプレアンブルを持つ、ボディを含んでいる。同図に示すように、各色に必要なサイズは、３ビットコードフォーマットを用いて有利にエンコードされている。より具体的にいうと、各色をエンコードするためのビット数は、コード（例えば、１ビットに対して０００、または８ビットに対して１１１）に応じて、１から８ビットまで変化する。そのボディはさらに、例えばＲＧＢインターリーブドフォーマットのような、圧縮されたタイル用のデータを含んでいる。

図２０は、図１８のエンコードおよび／または図１９のパケット用のヘッダを例示している。同図に示すように、ヘッダ２０００は、エンコードタイプ、バイト数、および３色のバイアス値（tri-chromatic bias values）を含んでいる。このインプリメンテーションでは、ヘッダ２０００は、例えば、エンコードタイプ用の４ビット、たすバイト数用の４ビット、たす３つの色各々のバイアス用の８ビットすなわち２４ビットを、用いている。しかしながら、当業者であれば、このヘッダに対して別のインプリメンテーションが可能なことを認識するであろう。この図に示すように、バイト数のフィールドは、例えば、４ビットコードを用い、８バイト（０００１）から５６バイト（０１１１）までの８ビットの倍数でもって、サイズを表している。同様に、エンコードタイプのフィールドは、図示するように、複合エンコード方式を許容している。したがい、異なるインプリメンテーションにおけるヘッダおよび／またはパケットは、例えばロッシーおよび／またはロスレスエンコードステージのような単一ステージおよび／またはマルチステージのエンコードの出力を扱うための、フィールドと柔軟性を含む。特定の実施形態におけるデコードシステムは、種々なエンコードを扱う場合と同様に構成される。

例えば、図２１は幾つかの実施形態におけるデコードシステム２１００を示している。同図に示すように、デコーダ２１００は、通常はパケットの形式を持つ入力データを受信しパケットのボディをアンパッカー２１０４およびプレアンブルデコードモジュール２０１７へ出力する、ボディフェッチ２１０２を含んでいる。ヘッダフェッチ２１０５はまた、入力データを受信し、好ましくはヘッダを解析するヘッダデコードモジュール２１０６へ出力する。例えば、特定のヘッダデコードモジュール２１０６は、プレアンブルデコードモジュール２１０７へ４ビットのエンコードタイプを出力し、加算器２１０８へ２４ビットのバイアス（３つの色（three tri-chromatic colors）各々に対して８ビット）を出力する。

プレアンブルデコードモジュール２１０７は、アンパッカー２１０４へ９ビットを出力する。この９ビットは、好ましくは、例えば赤緑青を用いるシステムに対するｒｇｂサイズなどの３ビットコードフォーマットで、３色（three tri-chromatic colors）各々のサイズを示す。アンパッカー２１０４は、受信した入力データ内の各画素に対して８ビット幅のフォーマットが形成されるように失われた先行ゼロを拡張し、その８ビット幅データを前述した加算器２１０８へ出力する。

加算器２１０８は、ヘッダフィールドに含まれる情報を抽出するヘッダデコーダ２１０６からバイアスを受信する。加算器２１０８は、各画素に対する受信された値にそのバイアス（８ビットフォーマット）を加え、加算された値をメモリ２１１０へ出力する。前述したように、受信されたデータは、度々、画素のタイルに対するストリームを備えている。それゆえ、これら実施形態のメモリ２１１０は、好ましくは、画素のタイルの規模、すなわちヘッダデコードモジュール２１０６から受信されたものとしての、あるいは、システム２１００内で所定のおよび／または固定されたものとしての、タイルサイズを持つ。こうして、これら固定されたサイズを送信する必要性を有利に減らしている。

メモリ２１１０の出力は、特定タイルの特定ストリームに対するデコードされた画素値である。例えば、幾つかの実施形態は、３つの色各々に対して８ビットを含んだ２４ビットを出力する。メモリ２１１０は、好ましくは、マルチプレクサ２１１２および、例えばマルチプレクサ２１１２へ出力を行うＮ倍シフタ（multiply-by-N shifter）のようなシフタ２１１４へ、出力する。マルチプレクサ２１１２は、ロッシー圧縮イネーブル信号（lossy_comp_enable）に基づいて、メモリ２１１０の出力、または（マルチプレクサ２１１４を介した）シフト出力を選択する。それゆえ、デコーダ２１００の図示されたインプリメンテーションは、図１５および１８に関連して前述したエンコーダ１５００および１８００とは逆のステップを実行し、ロスレスおよび／またはロッシーエンコードのデコードに対してさらに選択性を提供する。

図２２は、エンコードされたフォーマット２２００を例示している。同図に示すように、非圧縮のタイルは、例えば前述した実施形態の幾つかを用いることにより、より小さなフォーマットへ有利に圧縮される。特定のインプリメンテーションでは、１６×１６の非圧縮タイルが４×４の圧縮タイルへ圧縮される。各タイルは、好ましくは、例えば４バイトのヘッダを含む。あるインプリメンテーションでは、そのヘッダは、３つの色（three tri-chromatic colors）各々のバイアスに対して３バイト、すなわち青バイアス、緑バイアス、および赤バイアス各々に対して８ビットを用いている。１バイトは、エンコードタイプおよびバイト数のフィールドのために設けられている。この場合、これらのフィールド各々は、２つのフィールドに対してそのバイトの４ビットを用いている。

図示された例においては、４８タイルが有利に圧縮され、フレームバッファにパックされる。より具体的には、図示されたインプリメンテーション２２００は、前述した速度とランダムアクセスの利点を含むところの、租にパックされたフォーマットを用いている。さらに、租にパックされたインプリメンテーションでは、各タイルに配分された未使用スペースは、意図的にブランクのままとされている。図示された特定のフレームバッファは、１２タイル幅と４タイル高となっている。それゆえ、４×４画素を持つタイルに対しては、フレームバッファは、１６画素幅３つ分、すなわち４８画素幅と、１６画素高となる。

種々な異なる科学技術および技法のいずれかを用いることにより情報および信号を表すことができることは、当業者ならば理解するであろう。例えば、上記の記述を通して参照することができるところの、データ、インストラクション、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、電磁場またはその粒子、光の場またはその粒子、もしくはそれらの任意の組合せにより、表されてもよい。

当業者はまた、次のことも認識するであろう。すなわち、ここに開示される実施形態に関連して記載された種々な論理ブロック、モジュール、回路、およびアルゴリズムのステップは、電子ハードウエア、コンピュータソフトウエア、あるいはそれら両方の組合せとしてインプリメントすることができる。このハードウエアとソフトウエアの互換性を明確に示すために、種々図解されたコンポーネンツ、ブロック、モジュール、回路、およびステップが、その機能性でもって一般的に説明されている。このような機能性がハードウエアとしてインプリメントされるのかソフトウエアとしてインプリメントされるのかは、システム全体に課せられる特定のアプリケーションおよび設計上の制約に依存する。経験を積んだ技術者なら、記載された機能性を個々の特定アプリケーションに対応して種々な方法でインプリメントできるだろうが、そのようなインプリメンテーションの決定はこの発明からの逸脱を意味するものではない。

ここに開示される実施形態に関連して記述され、図解された種々な論理ブロック、モジュール、および回路は、ここに記載された機能を実行するように設計された、汎用プロセサ、デジタル信号プロセサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、あるいはその他のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタロジック、ディスクリートハードウエアコンポーネンツ、またはそれらの任意の組合せにより、インプリメントすることができ、あるいは実行することができる。汎用プロセサとしてはマイクロプロセサがあるが、それに限らず、このプロセサは、一般的なプロセサ、コントローラ、もしくはステートマシンのどれでもよい。プロセサは、計算デバイスの組合せとして、例えば、ＤＳＰとマイクロプロセサの組合せ、複数のマイクロプロセサの組合せ、ＤＳＰコアに関連した１以上のマイクロプロセサの組合せ、あるいはそのような任意の構成の組合せとして、インプリメントすることもできる。

ここに開示される実施形態に関連して記述された方法あるいはアルゴリズムのステップは、直接ハードウエアで具現することができ、あるいはプロセサにより実行されるソフトウエアで具現することができ、あるいはそれら２つの組合せで具現することができる。ソフトウエアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、あるいは、当該技術分野で知られているその他の形態の格納媒体の中に存在できる。一例としての格納媒体は、プロセサがその格納媒体から情報を読むことができかつ情報を書き込むことができるように、プロセサに接続される。あるいは、その格納媒体はプロセサに組み込まれていてもよい。このプロセサおよび格納媒体はＡＳＩＣ内に存在していてもよい。このＡＳＩＣは、ユーザ端末、パーソナルコンピュータ、あるいは移動体計算機および／または電気通信デバイス内に存在していてもよい。あるいは、プロセサおよび格納媒体は、ユーザ端末内でディスクリートコンポーネンツとして存在していてもよい。

ここに開示された実施形態の上記記載は、どの当業者でもこの発明品を作成し使用することができるようにしている。これら実施形態の種々な変形が当業者にとって容易なことは明かであり、ここに定義される一般原則は、この発明の趣旨と範囲から逸脱することなく他の実施形態に適用できる。例えば、移動体デバイスのためのイメージおよび／またはビデオデータに関連して種々な実施形態が記載されている。しかしながら、当業者なら他のデータタイプや他のプラットフォームも認識できる。すなわち、この発明をここに示された実施形態に限定する意図はなく、この発明はここに記載された原理および新規な特徴に矛盾しない範囲で最大限広く扱われるべきである。
以下に、本願出願当初の特許請求の範囲に記載された発明を付記する。
［１］ 以下を備えたエンコード方法：
イメージを受信し、
前記イメージをタイルのセットにタイリングし、ここで各タイルは画素のセットを具備し、
第１のタイルを選択し、
前記第１のタイル内の画素に対する値の第１セットを決定し、
前記第１のタイル内の各画素の決定された値を複数のストリームに分け、
第１のストリームに対して、バイアス値を決定し、そして、
前記ストリーム内の各値からバイアス値を差し引いて、引き算された値のセットを発生する。
［２］ ［１］の方法において、前記引き算された値は１以上の先行ゼロを含み、この方法が、さらに以下を備える：
先行するゼロを除去し、前記第１のストリーム内の前記引き算された値を表すために要求されるビット数を減らして、
前記第１のストリーム内の値をより少ないビットで表す。
［３］ ［１］の方法が、さらに以下を備える：
ストリーム内の値に対して、最小の値を決定する、ここで前記バイアス値が前記最小の値を備える。
［４］ ［１］の方法が、さらに以下を備える：
前記引き算された値を丸めて、丸められた値のセットを発生し、そして、
前記丸められた値をあるファクタで割る。
［５］ ［４］の方法において、前記ファクタは２の倍数を備え、Ｎをシフトされた最小桁ビット数としたときに、Ｎビットロッシーエンコーダがインプリメントされるようにして、前記割り算がシフト動作により行われる。
［６］ ［１］の方法において、前記複数のストリームが、赤、緑、および青各々のストリームを備える。
［７］ ［１］の方法において、前記複数のストリームが、Ｙ、Ｃｒ、およびＣｂ各々のストリームを備える。
［８］ ［１］の方法が、さらに以下を備える：
フレームバッファ内において、タイルのエンコードされたセットをパッキングする。
［９］ ［８］の方法において、各タイルにより占有されるスペースが可変となるよう、前記
タイルが密にパックされる。
［１０］ ［８］の方法において、前記タイルは所定のアドレス可能な場所にパックされる。
［１１］ ［１］の方法において、前記第１のストリームは前記第１のタイルの画素に対する第１の色を示す係数のセットを備え、この方法が、さらに以下を備える： 前記第１のストリームに対して、前記第１の色を再構成するのに十分な係数情報を前記バイアス値が含むかどうかを、決定する。
［１２］ ［１１］の方法において、さらに以下を備える：前記バイアス値が前記第１の色を再構成するのに十分な係数情報を含むならば、
前記バイアス値を用いて前記第１の色をパケットヘッダにエンコードし、
パケットボディ内における前記第１の色に対する係数のエンコードを差し控え、
前記第１のタイルの前記第１の色を忠実に再構成するのに十分な画素情報をヘッダが含むかどうかを示すためのエンコードタイプを選択する。
［１３］ ［１２］の方法において、さらに以下を備える：前記パケットヘッダをフェッチし、
前記エンコードタイプを受信し、そして、
前記エンコードタイプを用いて前記第１の色をデコードする、ここで、前記第１の色を再構成するのに十分な情報を前記パケットヘッダが含むことを前記エンコードタイプが示すならば、この方法は、前記パケットボディから前記第１の色のための情報をフェッチする処理を差し控える。
［１４］ ［１２］の方法において、前記エンコードタイプが、以下のうちの少なくとも１つを備える：
前記パケットボディ内に前記第１のタイルのための色情報がエンコードされていないという状況に対する第１の選択、
前記パケットボディ内に１つの色のための情報がエンコードされていないという状況に対する第２の選択、
前記パケットボディ内に２つの色のための情報がエンコードされていないという状況に対する第３の選択、
前記パケットボディ内に３つの色のための情報がエンコードされていないという状況に対する第４の選択。
［１５］ ［１２］の方法において、前記係数情報はルミナンス値とクロミナンス値のうちの１つを備える。
［１６］ エンコードのためのプログラムを格納するコンピュータ読取可能媒体であって、前記プログラムが、以下のための命令を備える：
イメージを受信すること、
前記イメージをタイルのセットにタイリングすること、ここで各タイルは画素のセットを具備する、
第１のタイルを選択すること、
前記第１のタイル内の画素に対する値の第１セットを決定すること、
前記第１のタイル内の各画素の決定された値を複数のストリームに分けること、
第１のストリームに対して、バイアス値を決定すること、そして、
前記ストリーム内の各値からバイアス値を差し引いて、引き算された値のセットを発生すること。
［１７］ イメージ圧縮システムであって、このシステムが以下を備える：
イメージを受信する手段、
前記イメージをタイルのセットにタイリングする手段、ここで各タイルは画素のセットを具備する、
第１のタイルを選択する手段、
前記第１のタイル内の画素に対する値の第１セットを決定する手段、
前記第１のタイル内の各画素の決定された値を複数のストリームに分ける手段、
第１のストリームに対して、バイアス値を決定する手段、そして、
前記ストリーム内の各値からバイアス値を差し引く手段、これにより引き算された値のセットを発生する。
［１８］ 以下のものを持つ第1のステージを備えたエンコーダ：
入力データのセットを受信するメモリ、
前記入力データのセットを受信するステータスブロック、このステータスブロックは前記入力データをソートするように構成される、
前記メモリの出力および前記ステータスブロックの出力に接続される第1の引算器、この第1の引算器は前記メモリの出力および前記ステータスブロックの出力に対して演算処理を行う、
前記第1の引算器に接続される第1の論理ユニット、この第1の論理ユニットは前記第1の引算器の出力を受信し複数のビットを出力する、そして、
前記論理ユニットに接続され前記複数のビットを受信してデータパケットを形成するパッカー、
ここで前記第1の論理ユニットは特定のデータストリームに基づいて減少されたビット数を出力するように構成される。
［１９］ ［１８］のエンコーダにおいて、前記メモリはタイルからデータストリームを受信するように構成され、ここで、タイルは１以上のデータストリームを備え、前記メモリは前記タイルからのデータストリームに基づくサイズとされる。
［２０］ ［１８］のエンコーダにおいて、前記演算処理は前記ステータスブロックの出力を前記メモリの出力から差し引いて引き算された値を発生することを備え、この引き算された値が１以上の先行ゼロを備え、前記エンコーダはさらに以下のことをするように構成される：
先行ゼロを除去して、第１のストリーム内の引き算された値を表すのに必要なビット数を減らす、そして、
前記第１のストリーム内の値をより少ないビットで表す。
［２１］ ［１８］のエンコーダにおいて、前記第１の論理ユニットはデコードユニットを備え、このデコードユニットにより出力されるビット数はこのデコードユニットへの制御入力により決定されるようになっており、この制御入力は前記ステータスブロックにより提供される。
［２２］ ［１８］のエンコーダにおいて、前記ステータスブロックは前記入力データ内の値を用いてバイアス値を決定するように構成され、このステータスブロックは、さらに、前記第１の引算器による引算のためのバイアス値を提供するように構成される。
［２３］ 請求項１８のエンコーダはフレームバッファをさらに備え、このエンコーダは前記フレームバッファ内のタイルのエンコードされたセットをパッキングするように構成される。
［２４］ ［１８］のエンコーダは、以下のものを具備する第２のステージをさらに備える：
前記第１の引算器の出力に接続された第２の論理ユニット、この第２の論理ユニットは丸め機能と割算機能を提供するように構成されている、
前記第１の引算器および前記第２の論理ユニットに接続された第１のマルチプレクサ、この第１のマルチプレクサは前記第１の引算器および前記第２の論理ユニットの出力を選択的に提供するように構成されている、
前記ステータスブロックの出力に接続された第２の引算器、この第２の引算器は１づつデクリメントするように構成されている、
前記ステータスブロックおよび前記第２の引算器に接続された第２のマルチプレクサ、この第２のマルチプレクサは前記ステータスブロックおよび前記第２の引算器の出力を選択的に提供するように構成されている、
前記第１および第２のマルチプレクサ各々に接続されたロッシーイネーブルライン、ここで、
前記ロッシーイネーブルラインがある状態にあるときは、前記第１のマルチプレクサは前記第１の引算器の出力を提供し、前記第２のマルチプレクサは前記ステータスブロックの出力を提供し、
前記ロッシーイネーブルラインが他の状態にあるときは、前記第１のマルチプレクサは前記第２の論理ユニットの出力を提供し、前記第２のマルチプレクサは前記第２の引算器の出力を提供する。
［２５］ 以下のものを備えたシステム：
減少された数のデータビットを用いてデータをエンコードするように構成されたエンコーダを持つ送信機；
送信チャネル；そして、
次のものを備えたデコーダを含む受信機：
入力データを受信するデータフェッチ、
前記データフェッチに接続されたアンパッカー、前記データフェッチは前記アンパッカーに出力する、前記アンパッカーは、受信された入力データに対して所定のフォーマットを形成するように失われた先行ゼロを拡張して、８ビット幅のデータを出力する、
前記入力データからヘッダ情報を抽出するヘッダデコードモジュール、そして、
前記ヘッダデコードモジュールおよび前記アンパッカーに接続される加算器、この加算器は前記ヘッダデコードモジュールからバイアス値を受信しそのバイアス値を前記パッカーの出力に加算する。

Claims (8)

1. 以下を備えたエンコード方法：
   イメージを受信し、
   前記イメージをタイルのセットにタイリングし、ここで各タイルは画素のセットを具備し、
   第１のタイルを選択し、
   前記第１のタイル内の画素に対する値の第１セットを決定し、
   前記第１のタイル内の各画素の決定された値を複数のストリームに分け、
   第１のストリームに対して、バイアス値を決定し、
   前記ストリーム内の各値からバイアス値を差し引いて、引き算された値のセットを発生し、ここで、前記引き算された値は１以上の先行ゼロを含み、
   先行するゼロを除去し、前記第１のストリーム内の前記引き算された値を表すために要求されるビット数を減らして、
   前記第１のストリーム内の値をより少ないビットで表し、ここで、前記第１のストリームは、前記第１のタイルのための情報がパケットボディ内にエンコードされているかどうかを示すエンコードタイプおよび前記第１のストリームのバイアス値の情報を含むように構成されたヘッダを備える。
2. 請求項１の方法が、さらに以下を備える：
   ストリーム内の値に対して、最小の値を決定する、ここで前記バイアス値が前記最小の値を備える。
3. 請求項１の方法が、さらに以下を備える：
   前記引き算された値を丸めて、丸められた値のセットを発生し、そして、
   前記丸められた値をあるファクタで割る。
4. 請求項３の方法において、前記ファクタは２の倍数を備え、Ｎをシフトされた最小桁ビット数としたときに、Ｎビットロッシーエンコーダがインプリメントされるようにして、前記割り算がシフト動作により行われる。
5. 請求項１の方法において、前記複数のストリームが、赤、緑、および青各々のストリームを備える。
6. 請求項１の方法において、前記複数のストリームが、Ｙ、Ｃｒ、およびＣｂ各々のストリームを備える。
7. エンコードのためのプログラムを格納するコンピュータ読取可能媒体であって、前記プログラムが、以下のための命令を備える：
   イメージを受信すること、
   前記イメージをタイルのセットにタイリングすること、ここで各タイルは画素のセットを具備する、
   第１のタイルを選択すること、
   前記第１のタイル内の画素に対する値の第１セットを決定すること、
   前記第１のタイル内の各画素の決定された値を複数のストリームに分けること、
   第１のストリームに対して、バイアス値を決定すること、
   前記ストリーム内の各値からバイアス値を差し引いて、引き算された値のセットを発生すること、ここで、前記引き算された値は１以上の先行ゼロを含み、
   先行するゼロを除去し、前記第１のストリーム内の前記引き算された値を表すために要求されるビット数を減らすこと、
   前記第１のストリーム内の値をより少ないビットで表すこと、ここで、前記第１のストリームは、前記第１のタイルのための情報がパケットボディ内にエンコードされているかどうかを示すエンコードタイプおよび前記第１のストリームのバイアス値の情報を含むように構成されたヘッダを備える。
8. イメージ圧縮システムであって、このシステムが以下を備える：
   イメージを受信する手段、
   前記イメージをタイルのセットにタイリングする手段、ここで各タイルは画素のセットを具備する、
   第１のタイルを選択する手段、
   前記第１のタイル内の画素に対する値の第１セットを決定する手段、
   前記第１のタイル内の各画素の決定された値を複数のストリームに分ける手段、
   第１のストリームに対して、バイアス値を決定する手段、
   前記ストリーム内の各値からバイアス値を差し引く手段、これにより引き算された値のセットを発生する、ここで、前記引き算された値は１以上の先行ゼロを含む、
   先行するゼロを除去する手段、これにより前記第１のストリーム内の前記引き算された値を表すために要求されるビット数を減らす、
   前記第１のストリーム内の値をより少ないビットで表す手段、ここで、前記第１のストリームは、前記第１のタイルのための情報がパケットボディ内にエンコードされているかどうかを示すエンコードタイプおよび前記第１のストリームのバイアス値の情報を含むように構成されたヘッダを備える。

Images