画像の圧縮及び／又は復元
画像の複数のバージョンが圧縮される画像圧縮方法であって、各バージョンは異なる画像解像度を有する。方法は、画像の１つ又は複数の圧縮バージョンについて、復元画像データを生成するために、その圧縮バージョンを復元するステップと、画像の解像度のより高いバージョンと復元画像データとの画像差分を検出するステップと、検出された画像差分に応じて、差分データを圧縮するステップとを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像の圧縮及び／又は復元に関する。
【背景技術】
【０００２】
三次元（３Ｄ）コンピュータグラフィックス（ＣＧ）システムでは、様々な技術を使用して、表示画面上に２Ｄビューとして表示する際の３Ｄオブジェクトの形状を決定する。次に、多くの場合、「シェーダ」と呼ばれる機構が、オブジェクトの表面外観を決定する。これは、一般に、描画されたオブジェクトに表面「テクスチャ」を適用すること、並びにオブジェクトの反射性及びそのオブジェクトに対する光源の位置（仮想環境内の）を考慮することを含む。
【０００３】
表面テクスチャの適用は、「テクスチャマップ」（オブジェクトの所望の表面外観を表す）と呼ばれる事前に準備及び記憶された画像を３Ｄ形状に投影することを含む。これは確立された技術であり、グラフィカルに生成された３Ｄ形状に投影するための記憶されたテクスチャマップのセットに対する一般要件に関連する以外、本明細書において詳細に説明しない。テクスチャマップは単なる画像データである。これらの画像は、たまたまＣＧオブジェクトに適用すべき表面パターンを表しており、基本的には単に画像データを表す。例えば、コンピュータゲームシステムでは、多くの場合、非常に多くのこのようなテクスチャマップが必要とされる。これは、実際には、テクスチャマップを圧縮した形態で（例えば、コンピュータゲームディスクに）記憶する必要があることを意味する。
【０００４】
多くのＣＧシステム、特にパーソナルコンピュータ又はゲーム機内のハードウェアアクセラレート３Ｄ ＣＧ装置は、リアルタイムで動作する。すなわち、表示（フレーム）周期毎に１回、表示する新しい画像を生成する。これを達成するためには、記憶されているテクスチャマップに高速アクセスする必要があり、ひいては記憶されているテクスチャマップの比較的単純で高速の復元を可能にする圧縮／復元技術が必要である。
【０００５】
画像圧縮技術によっては、この特徴を提供するように、すなわち、復元プロセスに必要な処理及びメモリアクセスが比較的少ないように特別に設計されるものがある。一例は、S3 Graphics Ltdによって開発され、以下の非特許文献１及び特許文献１において説明されているＤＸＴｎ（但し、ｎは１〜５である）と呼ばれることが多いＳ３テクスチャ圧縮技術（S3 Texture Compression technique）のファミリである。
【０００６】
基本形態のＤＸＴ１は、２４ビットＲＧＢ（赤−緑−青）カラーデータの６：１固定圧縮を提供し、それによって、４×４ピクセルブロック（３８４ビット）は６４ビットデータ量に圧縮される。各ピクセルブロックは、５６５精度（すなわち、赤５ビット、緑６ビット、及び青５ビット）で「開始」カラー及び「終了」カラーを選択し、開始カラーと終了カラーとの間に（ＲＧＢ色空間内の直線上で）均等に分散するものとして定義することができる最高で２つの最高精度中間色を考慮することによって圧縮される。したがって、中間色は、開始カラー及び終了カラーから導出することができ、中間色は、圧縮データの部分として明示的に符号化する必要がない。次に、４×４ピクセルブロック内の各ピクセルが、これらの４色のうち最も近い色の選択として２ビットインデックスを使用して符号化される。したがって、４×４ピクセルブロックの符号化に使用されるビット総数は、（１６ピクセル×２ビット／ピクセル）＋（２基準色×（５＋６＋５）ビット／基準色）＝６４ビットである。
【０００７】
ピクセルブロックを復元する場合に必要なのは、開始カラー及び終了カラーを検出し、色空間内で開始カラーと終了カラーとの間に均等に分散した２つの中間色を補間し、それから、各ピクセルに提供される２ビットインデックスと共にルックアップテーブル内のこれらの４色を使用することだけである。このようにして、圧縮／復元処理のよりプロセッサ集約的な態様（例えば、開始カラー及び終了カラーの選択）を圧縮側で処理し、復元を比較的単純な処理動作として残すことができる。
【０００８】
ＤＸＴ１の他の変形及びＤＸＴｎファミリ技術の他のメンバは同様の手法を使用し、ピクセルブロックに関連するいわゆるアルファチャンネル（透明度）情報を処理することもできる。説明を容易にするために、ＤＸＴ１が例として本明細書において考察されるが、これから説明する技術が残りのＤＸＴ技術及び添付の特許請求の範囲内にある他の圧縮技術の両方に適用可能なことが理解されるであろう。
【０００９】
上述したＤＸＴ１圧縮システムは、ＣＧシステムにおいて使用するために、特定の画像サイズで単一のテクスチャマップを圧縮する効率的な方法を提供する。しかし、テクスチャマップが投影される３Ｄオブジェクトのサイズは様々であり得る。サイズは、単純なレベルでは、表現されている物体がどれだけ大きいか、及びオブジェクトが仮想環境において仮想視点からどの程度離れて配置されるかに依存する。仮に単一のテクスチャマップのみが記憶された場合、テクスチャマップの画像サイズは、恐らく、３Ｄオブジェクトに正しくマッピングするために必要なサイズに合わないであろう。しかし、仮にテクスチャマップが、可能性のある各オブジェクトスケール毎に記憶された場合、ストレージ要件は実用的でない大きさになるだろう。したがって、従来の解決策は、異なるスケールから選択された少数のテクスチャマップが記憶され、特定のオブジェクトに対して、所要のスケールのテクスチャマップ（又はむしろ、テクスチャマップの関連部分）が、スケールが所要のスケールに最も近い１つ又は２つの記憶されているマップから補間される。一般に、この目的は、最も所要のスケールが一対の記憶されているマップスケールの間に入るのに十分に広い範囲の記憶されているマップを有することである。表示されたオブジェクトが仮想視点に対して移動しているため、スケールの異なるテクスチャマップが各フレームで必要かもしれず、この状況に対処するために、この補間プロセスをリアルタイムで実行することができる。
【００１０】
複数のスケールのテクスチャマップの使用は、「ＭＩＰマッピング」（ＭＩＰは、「小さな空間に多くのもの」を意味するラテン語句multum in parvoの頭字語である）と呼ばれることがある。用語「ＭＩＰマップ」は、一般に、異なるスケールのテクスチャマップセットを指すために使用される。多くの場合、スケールは等比級数を形成するため、（例えば）、各スケールは次に高いスケールのサイズの１／４（各次元の５０％）である。一例として、テクスチャマップが２５６×２５６ピクセルという基本サイズを有する場合、関連付けられるＭＩＰマップは、そのテクスチャマップの８つのバージョン、画像サイズ１２８×１２８、６４×６４、３２×３２、１６×１６、８×８、４×４、２×２、及び１×１ピクセル、をさらに含み得る。ＭＩＰマップのストレージ要件の合計は、基本（２５６×２５６）テクスチャマップのストレージ領域の４／３倍に非常に近い。
【００１１】
シェーダは、ＭＩＰマップを使用して、一般に、ＭＩＰマップ内の２つの最も近いスケール間を補間することによって、所要のスケールのテクスチャ情報を生成する。したがって、例えば、オブジェクトの表示サイズが、４０×４０ピクセルのスケールサイズのテクスチャマップが必要であることを意味する場合、シェーダは、ＭＩＰマップ内の６４×６４画像と３２×３２画像とから、所望のテクスチャ部分を補間する。
【００１２】
０．２５等比級数における上に列挙したスケールセットは、当然ながら、ＭＩＰマップの使用の単なる一例である。
【００１３】
この技術は、かなり高い空間周波数情報を含むテクスチャマップに対しては上手く働くが、平滑な勾配を有する（比較的低い空間周波数詳細を表す）テクスチャマップに対してはあまり上手く働かないものと考えられる。このような低い周波数詳細を有するテクスチャマップの一例は、オブジェクトの照明を表すテクスチャマップである。低空間周波数テクスチャマップでは、ＤＸＴ圧縮においてブロック単位で開始カラー及び終了カラーを選択する必要性によってもたらされる不連続を表すこともある圧縮アーチファクト（compression artefacts）が見える可能性がある。
【００１４】
ＭＩＰマップ内に多くの画像を含むこともある他の様々なスケールセットも、表示されたオブジェクトのレンダリングされる外観の改良を図るために提案されている。別の可能性は、圧縮システムにＲＧＢと異なる色空間を使用することである。しかし、これらの試みは、ストレージ要件の大幅な増大、又は復元ステージでの処理オーバーヘッドの望ましくない追加という欠点のいずれかを有することが分かっている。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】米国特許第５９５６４３１号明細書
【非特許文献】
【００１６】
【非特許文献１】http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt
【発明の概要】
【００１７】
本発明は、画像の複数のバージョンが圧縮される画像圧縮方法であって、各バージョンは異なる画像解像度を有し、当該方法は、画像の１つ又は複数の圧縮バージョンについて、復元画像データを生成するために、その圧縮バージョンを復元するステップと、画像の解像度のより高いバージョンと復元画像データとの画像差分を検出するステップと、検出された画像差分に応じた差分データを圧縮するステップとを含む、方法を提供する。
【００１８】
また、本発明は、画像の複数の圧縮バージョンが提供される画像復元方法であって、各バージョンは、復元画像バージョンと解像度のより高い各画像バージョンとの画像差分に依存する圧縮差分データと共に、異なる画像解像度を有し、当該方法は、１つ又は複数の画像バージョンを選択するステップと、選択された画像バージョンに関連する圧縮画像データを復元するステップと、選択された画像バージョンよりも高い各解像度に関連する差分データを復元するステップと、所要の出力解像度の出力画像を生成するために復元画像データと復元差分データとを結合するステップとを含む、方法を提供する。
【００１９】
選択された画像バージョンは、例えば、結果として生成される差分データが所要の出力解像度に広がる解像度を表すようなものであってよい。
【００２０】
本発明は、ＣＧアプリケーションでのリアルタイムでの使用に特に適し（しかし、排他的に適するものではない）、メモリ又は処理オーバーヘッドを殆ど増大させずに向上した出力画質を提供することができる画像データ圧縮／復元技術を提供する。特に、同様のストレージ要件及び処理要件で、平滑照明勾配等の低空間周波数画像情報が符号化されている状況において、視認することができるノイズを低減することができる（従来の技術と比較して、この技術を使用することによって）。
【００２１】
本発明の様々な他の態様及び特徴は添付の特許請求の範囲において規定される。
【００２２】
本発明の実施形態について、単なる例として、添付図面を参照しながらこれより説明する。
【図面の簡単な説明】
【００２３】
【図１】データ処理装置の概略図である。
【図２】グラフィックスカードの概略図である。
【図３】ＭＩＰマップを概略的に示す図である。
【図４】本発明の実施形態によるＭＩＰマップの生成を概略的に示す図である。
【図５】図４によって生成されたＭＩＰマップからの所望のテクスチャマップ値の補間を概略的に示す図である。
【発明を実施するための形態】
【００２４】
これより図１を参照すると、データ処理装置は、システムユニット１０と、ディスプレイ２０と、マウス、キーボード、ゲームコントローラ等、又はこれらの組み合わせのような入力装置３０とを備える。ディスプレイ及び入力装置はデータ処理装置の周辺機器であり、当然ながら、データ処理装置はこれらアイテムなしで市販されてもよい。
【００２５】
データ処理装置は、例えば、パーソナルコンピュータ、Ｓｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ ３（登録商標）家庭用娯楽機器等のコンピュータゲーム機、又はＳｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ Ｐｏｒｔａｂｌｅ（登録商標）娯楽機器等のハンドヘルド機器であってよい。
【００２６】
システムユニット１０は、バス構造４０によって相互接続されたいくつかのアイテム、すなわち、中央演算処理装置（ＣＰＵ）５０、ランダムアクセスメモリ（ＲＡＭ）６０、読み取り専用メモリ（ＲＯＭ）７０、リムーバブル及び／又は固定ディスクストレージ（光ディスクストレージ等）８０、入力装置３０等の周辺機器と連結するための入出力（Ｉ／Ｏ）インタフェース９０、ネットワーク及び／又はインタネット接続１２０と連結するための有線及び／又は無線ネットワークインタフェース１００、並びにグラフィックスカード１１０を備える。
【００２７】
データ処理装置の２つの動作モードについて後述する。これらは、グラフィカル画像を後で生成する際に使用するための圧縮テクスチャマップの準備及びテクスチャをグラフィカルオブジェクトに適用するための圧縮テクスチャマップの復元である。概して、これらは、同一のデータ処理装置によって実行されることができる。だが、これらプロセスのうちの最初のプロセスが、いわゆるデベロッパーキットのような強力な非可搬式システム又は強力なパーソナルコンピュータによって実行され、第２のプロセスは、上述した娯楽機器のうちの１つ等の消費者機器によって実行される可能性のほうが高いことが理解されよう。以下の説明のために、図１に示す装置がいずれかのプロセスを実行可能な装置を表すものと仮定する。
【００２８】
動作に際して、コンピュータプログラムコードが、ディスクストレージ８０から、ＲＯＭ７０から、且つ／又はネットワーク接続１２０を介して読み取られ、ＲＡＭ６０にロードされ、恐らくは、入力装置３０から受信される信号に応答して、ＣＰＵ５０によって実行される。ＣＰＵ５０はデータ出力を生成し、このデータ出力はグラフィックスカード１１０に渡される。
【００２９】
グラフィックスカード１１０は、ＣＰＵ５０から受信されたデータに対して作用して、ディスプレイ２０に表示される画像を準備又は「レンダリング」する。グラフィックスカード１１０について以下でより詳細に説明する。概して、グラフィックスカード（当然ながら、カード形状である必要はなく、又は装置の残りの部分への接続に関して取り外し可能である必要さえもない）は、マイクロプロセッサ、及び関連付けられるメモリ、及び効率的な出力画像のレンダリングに固有の処理タスクの処理を専用とする他のハードウェアを備える。
【００３０】
図２は、グラフィックスカード１１０の概略図である。グラフィックスカードが、それ自体、非常に強力な計算装置であることができ、したがって、図２が単に、ＣＧ技術の包括的な説明の基本を形成するのではなく、グラフィックスカードの機能の、本説明に関連する部分の概観であることが理解されよう。ＰｌａｙＳｔａｔｉｏｎ ３（登録商標）娯楽機器のグラフィックスカードは、ＮＶＩＤＩＡ（登録商標）７８００（商標）グラフィックスカードに基づく。
【００３１】
したがって、概観として、グラフィックスカード１１０は、データをＣＰＵ５０から受信し、そのデータから、ディスプレイバッファ１８０に記憶される出力画像を生成する。プリミティブレンダラ１３０が、プリミティブとして知られている小さな画像部分を生成し、そこから、出力画像が構築される。各プリミティブは、例えば、出力画像内のオブジェクト又は画像背景の部分を形成する小さなポリゴンを表し得る。「深度」又は「ｚ」値が各プリミティブの各ピクセルに関連付けられて、最終画像内でのレンダリングされる他のプリミティブへの相対的な深度を示す。深度値は深度バッファ１４０に記憶される。同様に、透明度又は「α」値は各ピクセルに関連付けられて、透明さの程度を定義する。このようにして、最終画像は、背景ピクセルが非透明の前景ピクセルの背後に隠れるのに対して、同じ表示位置にある前景ピクセルが完全又は部分的に透明である場合、背景ピクセルが全体的又は部分的に見えるように構築することができる。
【００３２】
シェーダ１６０は、テクスチャマップバッファ１７０に記憶されたテクスチャマップを使用して、表面テクスチャをレンダリングされたプリミティブのうちのいくつか又はすべてに適用する。これらのテクスチャマップは、（例えば）ディスクストレージ８０、ＲＯＭ７０、ＲＡＭ６０から、又はネットワーク接続１２０を介して検索することができ、アクセスの容易さ及び速度のためにテクスチャマップバッファ１７０にローカルに記憶される。シェーダは、テクスチャマップデータのオリジナルソースから直接、すなわちローカルストレージを必要とすることなく働いてもよいが、このような構成は確実に、ローカルストレージにテクスチャマップデータをキャッシュするよりもかなり遅くなることが理解されよう。実際に、深度バッファ１４０、テクスチャマップバッファ１７０、及びディスプレイバッファ１８０は、図２に示されていないグラフィックスカードの他のストレージ要件と共に、動作速度のためにグラフィックスカード内又はグラフィックスカードの非常に近くに設けられるグラフィックスカードのローカルストレージ１５０の部分を形成する。
【００３３】
シェーダは、そのオブジェクトに適用すべき表面仕上げ又は表面外観を適用するために、レンダリングされるオブジェクトの性質又は表面や、仮想環境での任意の照明の反射性及び性質及び位置等の他の要因を考慮に入れる。頂点シェーディング、ピクセルシェーディング、ジオメトリシェーディング等のような多くの異なるシェーダ技術が提案及び開発されてきた。これらはすべて当該技術分野において既知であり、本実施形態は、テクスチャマップデータが適用される特定の技術にではなく、シェーダによって適用されるテクスチャマップデータの生成に関連するため、本明細書において詳細に説明しない。
【００３４】
シェーダは、通常、シェーダの機能に特に関連する特徴を有する特別に設計されたプログラミング言語であるシェーディング言語を使用して実装される。シェーダ言語で書かれたいくつかの機能例を以下に挙げる。Ｓｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ ３（登録商標）娯楽機器に使用されるグラフィックスカードは、毎秒７５０億回のシェーダ演算が可能であると報告されている。
【００３５】
図３は、前もって処理されたＭＩＰマップを示す概略図である。
【００３６】
用語「ＭＩＰマップ」は、本明細書では、異なるスケールのテクスチャマップセットを指すために使用される。本例では、スケールは、各スケール（解像度）が次に高いスケールのサイズの１／４（各次元が５０％）であるように、幾何（すなわち、対数）級数又は集合を形成する。特に、テクスチャマップ２００は２５６×２５６ピクセルという基本サイズを有する。ＭＩＰマップは、最高で８つのバージョンのテクスチャマップをさらに含み、そのテクスチャマップは、画像サイズ１２８×１２８、６４×６４、３２×３２、１６×１６、８×８、４×４、２×２、及び１×１ピクセルである。図３では、図面を明確にするために、最初の５つのスケールのみ、すなわち、２５６×２５６（テクスチャマップ２００）、１２８×１２８（テクスチャマップ２１０）、６４×６４（テクスチャマップ２２０）、３２×３２（テクスチャマップ２３０）、及び１６×１６（テクスチャマップ２４０）が示される。９つすべてのバージョンがある場合、ＭＩＰマップのストレージ要件の合計は、基本（２５６×２５６）テクスチャマップ２００のストレージ領域の４／３倍に非常に近い。
【００３７】
ＭＩＰマップ内の異なるテクスチャマップバージョンはすべて、（この例では）ＤＸＴ１圧縮を使用して圧縮されている。
【００３８】
シェーダは、ＭＩＰマップを使用して、一般にＭＩＰマップ内の２つの最も近いスケール間の補間によって所要のスケールのテクスチャ情報を生成する。このための様々な補間方法が提案されており、具体的な補間技術は本実施形態にとって重要ではない。異なるスケールのテクスチャマップバージョンが最初に生成され、アンチエイリアシング処理が実行された場合、この段階での補間が有利である。
【００３９】
テクスチャマップの所要のスケールは、レンダリング中のオブジェクトの表示サイズに依存し、表示サイズは、基本サイズ及びオブジェクトが仮想視点から（仮想環境内で）表示される距離に依存する。既知の技術が使用されて、補間されるテクスチャマップの所要のスケールが確立される。所要のスケールのテクスチャマップ全体を補間するのではなく、一般に、オブジェクトの表示に必要なこれらの部分のみが補間される。補間される部分のこの選択は、ピクセル単位で行うことができる。
【００４０】
したがって、例えば、オブジェクトの表示サイズが、（例えば）１６０×１６０ピクセルのスケールのテクスチャマップ２５０が必要であることを意味する場合、シェーダは、ＭＩＰマップ内の、２５６×２５６バージョン２００及び１２８×１２８ピクセルバージョン２１０からテクスチャの必要な部分を補間する。ＤＸＴ１圧縮は、圧縮画像の特定のブロックにローカルである（すなわち、ブロックの復元には、他のいかなるブロックの復元も必要としない）ため、復元する必要があるのは、補間プロセスに関連するバージョンのこれらの部分のみである。一例を図３に示し、部分２５２（シェーダによって従来通りに導出されるマップ内座標（ｕ，ｖ）によって定義される）が、シェーダ１６０において実行されている補間プロセス２６０によって、ＭＩＰマップ内の各画像バージョンの復元された部分２０２及び２１２から補間される。
【００４１】
図３は、ＭＩＰマップ技術を使用して前に提案されたシェーダに関連付けられる処理を表した。本発明の実施形態によるＭＩＰマップの生成及び使用と、シェーダ技術とに関連するプロセスについて、図４及び図５を参照してこれより説明する。
【００４２】
図４は、本発明の実施形態によるＭＩＰマップの生成を概略的に示す。これらの動作は、画像のリアルタイム表示ではなくデータの準備を指すため、一般に、グラフィックスカード１１０によって実行されない。むしろ、これらの動作は、通常、プログラム制御下のＣＰＵ５０によって実行される。
【００４３】
「基本」テクスチャマップ３００（例えば、２５６×２５６ピクセル）から、ＭＩＰマップが、テクスチャマップのより小さなバージョンシリーズ３１０、３２０、３３０、３４０、・・・を生成するために、オプションとして既知のアンチエイリアシング処理を含む既知の技術を使用して生成される。図３を参照して上述したように、シリーズは１×１ピクセルのバージョンまで可能であるが、最小バージョンは、単に図面を明確にするために、図４に示されない。
【００４４】
テクスチャマップは圧縮され（例えば、ＤＸＴ１圧縮を使用して）、それから、以下の処理のために復元される。続けて記憶又は送信されるテクスチャマップについては（マップ３００以外−以下参照）、圧縮された形態で記憶又は送信される。
【００４５】
基本テクスチャマップ３００は、最終的に破棄される。すなわち、記憶又は送信され、後にシェーダ１６０によって参照されるＭＩＰマップにおいて使用されない。しかし、基本テクスチャマップ３００は、ＭＩＰマップの準備に使用されるため、図４には破線で示される。
【００４６】
「差分」テクスチャマップシリーズが生成される。これらは図４において差分マップ３５０、３６０、３７０、及び３８０として示される。基本テクスチャマップ３００のサイズに対応する１つの差分マップ３５０があり、最小テクスチャマップサイズを除き、それよりも低い各テクスチャマップサイズ毎に１つの差分マップがある。
【００４７】
差分マップが生成される方法についてこれより説明する。各ＭＩＰマップレベル３１０、・・・、３３０毎に、ＣＰＵ５０はマップを復元し、以下のプログラムプロセスステップ３４２、３４４、３４６、及び３４８を実行する。
（ステップ３４２）倍率４で次に低い解像度画像バージョンを画像拡張（すなわち、スケーリング）する（すなわち、現在レベルと同じサイズにする）。
（ステップ３４４）現在レベルのピクセルと画像拡張された次に低いレベルのピクセルとの差分をピクセル単位で計算（すなわち、検出）する。
（ステップ３４６）差分を利得係数（スケーリング定数）で乗算し、オフセット（例えば、１２８＝ピクセル値の全範囲の半分）を適用する。
（ステップ３４８）ＤＸＴ１又は他の圧縮を使用して、差分画像を圧縮する。
【００４８】
利得係数は、例えば、圧縮／復元品質を向上させるために、４又は８であってよい。これは、差分値のすべてが（オフセットが適用される前）適度にゼロに近くなるため可能である。オフセットは、負の差分値を扱うために適用される。
【００４９】
画像拡張プロセスは、既知の双線形フィルタリングプロセスであってよい。
【００５０】
基本形態のＤＸＴ１圧縮は、２４ビットＲＧＢカラーデータの６：１固定圧縮を提供し、それによって、４×４ピクセルブロック（３８４ビット）は６４ビットデータ量に圧縮される。各ピクセルブロックは、５６５精度（すなわち、赤５ビット、緑６ビット、及び青５ビット）で開始カラー及び終了カラーを（既知の技術を使用して）選択し、開始カラーと終了カラーとの間に（ＲＧＢ色空間内の直線上で）均等に分散するものとして定義することができる最高で２つの最高精度中間色を考慮することによって圧縮される。それから、ブロック内の各ピクセルは、これらの４色のうち最も近い色の選択として２ビットインデックスを使用して符号化される。したがって、４×４ピクセルブロックの符号化に使用されるビット総数は、（１６ピクセル×２ビット／ピクセル）＋（２基準色×（５＋６＋５）ビット／基準色）＝６４ビットである。
【００５１】
ピクセルブロックが後に復元される場合に必要なのは、開始カラー及び終了カラーを検出し、色空間内で開始カラーと終了カラーとの間に均等に分散した２つの色を補間し、それから、各ピクセルに提供される２ビットインデックスと共にルックアップテーブル内のこれらの４色を使用することだけである。
【００５２】
図４を参照して、差分画像３６０の生成を概略形態で示す。テクスチャマップバージョン３２０が、テクスチャマップバージョン３１０と同じサイズに画像拡張される。上述したように、これら２つの差分が確立され、スケーリング、及びオフセットされて、差分画像３６０が生成され、それから、差分画像３６０はＤＸＴ１圧縮を受ける。対応する技術が使用されて、図４に示される他の差分画像が生成される。説明した技術が、最小テクスチャマップよりも１レベル（等比級数で）大きな最小差分画像をもたらすことが分かる。
【００５３】
基本テクスチャマップ３００が差分画像３５０の生成に使用されるが、後で使用するために記憶又は送信されないことが分かる。
【００５４】
テクスチャマップバージョン３１０、・・・、３４０もＤＸＴ１圧縮を受ける。
【００５５】
図４において生成されたすべてのデータは（好ましくは、本処理に関わる限り、破棄される最高解像度マップ３００は別として）、圧縮された形態で、ネットワークを介して送信することができ、且つ／又は光ディスク等の記憶媒体に記憶することができる。
【００５６】
図５は、図４に従って生成されたＭＩＰマップ（テクスチャマップ等の画像の複数の圧縮バージョンと、復元された画像バージョンとより高い各解像度画像バージョンとの画像差分に依存する差分データと、を含む）からの所要のテクスチャマップ値の補間を概略的に示す。これらの動作は、一般に、シェーダ１６０によってリアルタイムで実行される。
【００５７】
図５では、テクスチャマップバージョン３１０、・・・、３４０が、差分画像３５０、・・・３８０と共に提供される。ここでも、図面を明確にするために、少数の最小テクスチャマップバージョン及び差分画像が示されていないことに留意されたい。基本テクスチャマップ３００（図４）が提供されていないことにも留意されたい。
【００５８】
任意のサイズの所要のテクスチャマップスケール３９０の所要のテクスチャマップエリア３９２を生成する基本プロセスについて、これより説明する。本例では、所要のテクスチャマップスケールは、基本サイズ２５６×２５６ピクセルと次に低いサイズ１２８×１２８ピクセルとの間にある。
【００５９】
２つの補間プロセス４００、４１０がシェーダ１６０によって実行される。
【００６０】
補間プロセス４００は、シェーダ１６０によってこの目的のために選択された２つのテクスチャマップ内、すなわち（所要のスケール３９０から次に低い）テクスチャマップバージョン３１０及び（また次に低い）３２０内の領域３１２及び３２２を復元し、これら領域の間に作用して、所要の領域３９２に対応するが、所要のスケールの１／４（すなわち、ＭＩＰマップ構造内で１レベル下）の補間ピクセル又は領域を生成する。
【００６１】
補間プロセス４１０は、所要のスケール３９０の両側のスケールの各差分画像３５０、３６０内の領域３５２、３６２を復元し、これら領域の間に作用する。したがって、差分データの補間は、テクスチャデータの補間に使用された解像度より次に高い解像度の差分データを使用して行われる。
【００６２】
補間プロセス４００（すなわち、図５の例においてテクスチャマップバージョン３１０及び３２０に適用されるプロセス）は、所要の出力スケール３９０の出力ピクセルを生成するように、２つのテクスチャマップバージョン間を補間する。したがって、補間プロセス４００は、補間プロセス４１０に対してアップスケールすることを含むと考えることができる（しかし、実際には、両プロセスは単に、２つのＭＩＰバージョンを入力としており、所要のスケール３９０の出力を生成するように、シェーダの機能を使用して構成される）。
【００６３】
２つの補間プロセス４００、４１０の結果は、ここでもシェーダ１６０によって実施される結合プロセス４２０に渡される。結合プロセスは、以下のように２つの補間領域をとり、これらの補間領域を結合する。
差分画像ピクセル値を利得係数（上記参照）で除算し、オフセットを減算し、
差分画像ピクセル値及び補間テクスチャマップ内の対応するピクセル位置を加算して、所要の解像度の出力テクスチャマップを生成する。
【００６４】
各コマンドの説明と共に、シェーダプログラミング言語で実行されるこのプロセスの一例は以下である。
half3 base = tex2Dbias(baseTex, in_uv, bias_amount).xyz
half3は、続く変数名の種別を定義し、したがって、変数baseは半精度３構成要素（ＲＧＢ）変数である。
tex2Dbiasは、現在必要とされているスケールにバイアスＭＩＰレベルbias_amount（上記例では１であるが、他の実施形態では異なる数であってもよい）を加算したＭＩＰマップからピクセル値を生成するコマンドである。
baseTexは、テクスチャマップに対応するＭＩＰマップを識別する（この例では、マップ３１０、・・・、３４０）。
in_uvは、テクスチャマップ内の座標を表す。
.xyzは、引数の最初の３つの構成要素（ＲＧＢ）を結果として渡すべきであることを示す。
したがって、このコマンドは、別の方法で選択されたスケールよりも１つ低い（ＭＩＰチェーン内で）テクスチャマップスケールを使用して、所要のピクセルを生成する。
half3 diff = tex2D(diffTex, in_uv).xyz
tex2Dは、所要のスケールでの（オフセットなし）ＭＩＰマップからのピクセル値を生成するコマンドであり、
diffTexは、差分画像（すなわち、この例では画像３５０、・・・、３８０）に対応するＭＩＰマップを識別する。
half3 combined = base + scale.xxx * (diff-offset.xxx)
combinedは出力ピクセル値である。
scale（１／利得係数、を表す）及びoffsetについては図４を参照して上述した。
.xxxは、関連する変数の３つの構成要素の表現を示す。
【００６５】
可能な発展では、見ることができる細部がより少ない、より遠いオブジェクトを（通常）表す、所要のスケールがより小さい場合、差分マップの使用を低減するか、又は完全に回避し、それに代えて、所要の出力スケールの両側のスケールを有するテクスチャマップ間の単に従来の補間を使用することができる。したがって、例えば、仮に、所要の出力スケールが特定のレベルよりも小さい場合、従来の技術を使用することができるのに対し、所要の出力スケールがこのような閾値よりも大きい場合、差分ベースの技術を使用することができる。又は、従来の技術の結果と新しい技術の結果との加重和を使用してもよく、重み付けは、一般に、所要のスケールの増大に伴って新しい（差分画像）技術を優先するように増大する。これらの２つの可能性を組み合わせてもよく、すなわち、加重され閾値処理されるシステムであってもよく、重み付けは閾値スケールを超えて適用される。当然ながら、最大テクスチャマップバージョンが上述したように破棄されていると仮定して、従来の技術は、２番目のＭＩＰレベルよりも高い所要スケールでは適用することができない。
【００６６】
図４に示す技術を使用して生成されたＭＩＰマップのストレージ要件は、図３のＭＩＰマップのストレージ要件よりもわずかに高くなり得る。特に、この要件は基本マップ２００、３００のサイズの約５／３であり得る。しかし、ストレージ内のこの小さな増大によって、大幅に改良された画質を提供することができる。
【００６７】
まとめると、上述した実施形態は、ＣＧアプリケーションでのリアルタイムでの使用に特に適し（しかし、排他的に適するものではない）、メモリ又は処理オーバーヘッドを殆ど増大させずに向上した出力画質を提供することができる画像データ圧縮／復元技術を提供する。特に、同様のストレージ要件及び処理要件で、平滑照明勾配等の低空間周波数画像情報が符号化されている状況において、視認することができるノイズを低減することができる（従来の技術と比較して、この技術を使用することによって）。
【００６８】
上記実施形態は、適切なソフトウェアの制御下で動作した場合、上述した機能ステップを実行する手段を提供する図１のデータ処理装置によって実施することができる。特に、データ処理装置は、データ圧縮器、データ復元器、選択器、検出器、結合器、生成器等を提供し、これらはすべて上記技術において使用可能である。結果として、図４に関して説明したプロセスによって生成されるＭＩＰマップデータは、例えばコンピュータゲームの部分として、又はコンピュータゲームに関連して、ネットワークを介して送信することができ、且つ／又は記憶媒体に記憶することができる。
【技術分野】
【０００１】
本発明は、画像の圧縮及び／又は復元に関する。
【背景技術】
【０００２】
三次元（３Ｄ）コンピュータグラフィックス（ＣＧ）システムでは、様々な技術を使用して、表示画面上に２Ｄビューとして表示する際の３Ｄオブジェクトの形状を決定する。次に、多くの場合、「シェーダ」と呼ばれる機構が、オブジェクトの表面外観を決定する。これは、一般に、描画されたオブジェクトに表面「テクスチャ」を適用すること、並びにオブジェクトの反射性及びそのオブジェクトに対する光源の位置（仮想環境内の）を考慮することを含む。
【０００３】
表面テクスチャの適用は、「テクスチャマップ」（オブジェクトの所望の表面外観を表す）と呼ばれる事前に準備及び記憶された画像を３Ｄ形状に投影することを含む。これは確立された技術であり、グラフィカルに生成された３Ｄ形状に投影するための記憶されたテクスチャマップのセットに対する一般要件に関連する以外、本明細書において詳細に説明しない。テクスチャマップは単なる画像データである。これらの画像は、たまたまＣＧオブジェクトに適用すべき表面パターンを表しており、基本的には単に画像データを表す。例えば、コンピュータゲームシステムでは、多くの場合、非常に多くのこのようなテクスチャマップが必要とされる。これは、実際には、テクスチャマップを圧縮した形態で（例えば、コンピュータゲームディスクに）記憶する必要があることを意味する。
【０００４】
多くのＣＧシステム、特にパーソナルコンピュータ又はゲーム機内のハードウェアアクセラレート３Ｄ ＣＧ装置は、リアルタイムで動作する。すなわち、表示（フレーム）周期毎に１回、表示する新しい画像を生成する。これを達成するためには、記憶されているテクスチャマップに高速アクセスする必要があり、ひいては記憶されているテクスチャマップの比較的単純で高速の復元を可能にする圧縮／復元技術が必要である。
【０００５】
画像圧縮技術によっては、この特徴を提供するように、すなわち、復元プロセスに必要な処理及びメモリアクセスが比較的少ないように特別に設計されるものがある。一例は、S3 Graphics Ltdによって開発され、以下の非特許文献１及び特許文献１において説明されているＤＸＴｎ（但し、ｎは１〜５である）と呼ばれることが多いＳ３テクスチャ圧縮技術（S3 Texture Compression technique）のファミリである。
【０００６】
基本形態のＤＸＴ１は、２４ビットＲＧＢ（赤−緑−青）カラーデータの６：１固定圧縮を提供し、それによって、４×４ピクセルブロック（３８４ビット）は６４ビットデータ量に圧縮される。各ピクセルブロックは、５６５精度（すなわち、赤５ビット、緑６ビット、及び青５ビット）で「開始」カラー及び「終了」カラーを選択し、開始カラーと終了カラーとの間に（ＲＧＢ色空間内の直線上で）均等に分散するものとして定義することができる最高で２つの最高精度中間色を考慮することによって圧縮される。したがって、中間色は、開始カラー及び終了カラーから導出することができ、中間色は、圧縮データの部分として明示的に符号化する必要がない。次に、４×４ピクセルブロック内の各ピクセルが、これらの４色のうち最も近い色の選択として２ビットインデックスを使用して符号化される。したがって、４×４ピクセルブロックの符号化に使用されるビット総数は、（１６ピクセル×２ビット／ピクセル）＋（２基準色×（５＋６＋５）ビット／基準色）＝６４ビットである。
【０００７】
ピクセルブロックを復元する場合に必要なのは、開始カラー及び終了カラーを検出し、色空間内で開始カラーと終了カラーとの間に均等に分散した２つの中間色を補間し、それから、各ピクセルに提供される２ビットインデックスと共にルックアップテーブル内のこれらの４色を使用することだけである。このようにして、圧縮／復元処理のよりプロセッサ集約的な態様（例えば、開始カラー及び終了カラーの選択）を圧縮側で処理し、復元を比較的単純な処理動作として残すことができる。
【０００８】
ＤＸＴ１の他の変形及びＤＸＴｎファミリ技術の他のメンバは同様の手法を使用し、ピクセルブロックに関連するいわゆるアルファチャンネル（透明度）情報を処理することもできる。説明を容易にするために、ＤＸＴ１が例として本明細書において考察されるが、これから説明する技術が残りのＤＸＴ技術及び添付の特許請求の範囲内にある他の圧縮技術の両方に適用可能なことが理解されるであろう。
【０００９】
上述したＤＸＴ１圧縮システムは、ＣＧシステムにおいて使用するために、特定の画像サイズで単一のテクスチャマップを圧縮する効率的な方法を提供する。しかし、テクスチャマップが投影される３Ｄオブジェクトのサイズは様々であり得る。サイズは、単純なレベルでは、表現されている物体がどれだけ大きいか、及びオブジェクトが仮想環境において仮想視点からどの程度離れて配置されるかに依存する。仮に単一のテクスチャマップのみが記憶された場合、テクスチャマップの画像サイズは、恐らく、３Ｄオブジェクトに正しくマッピングするために必要なサイズに合わないであろう。しかし、仮にテクスチャマップが、可能性のある各オブジェクトスケール毎に記憶された場合、ストレージ要件は実用的でない大きさになるだろう。したがって、従来の解決策は、異なるスケールから選択された少数のテクスチャマップが記憶され、特定のオブジェクトに対して、所要のスケールのテクスチャマップ（又はむしろ、テクスチャマップの関連部分）が、スケールが所要のスケールに最も近い１つ又は２つの記憶されているマップから補間される。一般に、この目的は、最も所要のスケールが一対の記憶されているマップスケールの間に入るのに十分に広い範囲の記憶されているマップを有することである。表示されたオブジェクトが仮想視点に対して移動しているため、スケールの異なるテクスチャマップが各フレームで必要かもしれず、この状況に対処するために、この補間プロセスをリアルタイムで実行することができる。
【００１０】
複数のスケールのテクスチャマップの使用は、「ＭＩＰマッピング」（ＭＩＰは、「小さな空間に多くのもの」を意味するラテン語句multum in parvoの頭字語である）と呼ばれることがある。用語「ＭＩＰマップ」は、一般に、異なるスケールのテクスチャマップセットを指すために使用される。多くの場合、スケールは等比級数を形成するため、（例えば）、各スケールは次に高いスケールのサイズの１／４（各次元の５０％）である。一例として、テクスチャマップが２５６×２５６ピクセルという基本サイズを有する場合、関連付けられるＭＩＰマップは、そのテクスチャマップの８つのバージョン、画像サイズ１２８×１２８、６４×６４、３２×３２、１６×１６、８×８、４×４、２×２、及び１×１ピクセル、をさらに含み得る。ＭＩＰマップのストレージ要件の合計は、基本（２５６×２５６）テクスチャマップのストレージ領域の４／３倍に非常に近い。
【００１１】
シェーダは、ＭＩＰマップを使用して、一般に、ＭＩＰマップ内の２つの最も近いスケール間を補間することによって、所要のスケールのテクスチャ情報を生成する。したがって、例えば、オブジェクトの表示サイズが、４０×４０ピクセルのスケールサイズのテクスチャマップが必要であることを意味する場合、シェーダは、ＭＩＰマップ内の６４×６４画像と３２×３２画像とから、所望のテクスチャ部分を補間する。
【００１２】
０．２５等比級数における上に列挙したスケールセットは、当然ながら、ＭＩＰマップの使用の単なる一例である。
【００１３】
この技術は、かなり高い空間周波数情報を含むテクスチャマップに対しては上手く働くが、平滑な勾配を有する（比較的低い空間周波数詳細を表す）テクスチャマップに対してはあまり上手く働かないものと考えられる。このような低い周波数詳細を有するテクスチャマップの一例は、オブジェクトの照明を表すテクスチャマップである。低空間周波数テクスチャマップでは、ＤＸＴ圧縮においてブロック単位で開始カラー及び終了カラーを選択する必要性によってもたらされる不連続を表すこともある圧縮アーチファクト（compression artefacts）が見える可能性がある。
【００１４】
ＭＩＰマップ内に多くの画像を含むこともある他の様々なスケールセットも、表示されたオブジェクトのレンダリングされる外観の改良を図るために提案されている。別の可能性は、圧縮システムにＲＧＢと異なる色空間を使用することである。しかし、これらの試みは、ストレージ要件の大幅な増大、又は復元ステージでの処理オーバーヘッドの望ましくない追加という欠点のいずれかを有することが分かっている。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】米国特許第５９５６４３１号明細書
【非特許文献】
【００１６】
【非特許文献１】http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt
【発明の概要】
【００１７】
本発明は、画像の複数のバージョンが圧縮される画像圧縮方法であって、各バージョンは異なる画像解像度を有し、当該方法は、画像の１つ又は複数の圧縮バージョンについて、復元画像データを生成するために、その圧縮バージョンを復元するステップと、画像の解像度のより高いバージョンと復元画像データとの画像差分を検出するステップと、検出された画像差分に応じた差分データを圧縮するステップとを含む、方法を提供する。
【００１８】
また、本発明は、画像の複数の圧縮バージョンが提供される画像復元方法であって、各バージョンは、復元画像バージョンと解像度のより高い各画像バージョンとの画像差分に依存する圧縮差分データと共に、異なる画像解像度を有し、当該方法は、１つ又は複数の画像バージョンを選択するステップと、選択された画像バージョンに関連する圧縮画像データを復元するステップと、選択された画像バージョンよりも高い各解像度に関連する差分データを復元するステップと、所要の出力解像度の出力画像を生成するために復元画像データと復元差分データとを結合するステップとを含む、方法を提供する。
【００１９】
選択された画像バージョンは、例えば、結果として生成される差分データが所要の出力解像度に広がる解像度を表すようなものであってよい。
【００２０】
本発明は、ＣＧアプリケーションでのリアルタイムでの使用に特に適し（しかし、排他的に適するものではない）、メモリ又は処理オーバーヘッドを殆ど増大させずに向上した出力画質を提供することができる画像データ圧縮／復元技術を提供する。特に、同様のストレージ要件及び処理要件で、平滑照明勾配等の低空間周波数画像情報が符号化されている状況において、視認することができるノイズを低減することができる（従来の技術と比較して、この技術を使用することによって）。
【００２１】
本発明の様々な他の態様及び特徴は添付の特許請求の範囲において規定される。
【００２２】
本発明の実施形態について、単なる例として、添付図面を参照しながらこれより説明する。
【図面の簡単な説明】
【００２３】
【図１】データ処理装置の概略図である。
【図２】グラフィックスカードの概略図である。
【図３】ＭＩＰマップを概略的に示す図である。
【図４】本発明の実施形態によるＭＩＰマップの生成を概略的に示す図である。
【図５】図４によって生成されたＭＩＰマップからの所望のテクスチャマップ値の補間を概略的に示す図である。
【発明を実施するための形態】
【００２４】
これより図１を参照すると、データ処理装置は、システムユニット１０と、ディスプレイ２０と、マウス、キーボード、ゲームコントローラ等、又はこれらの組み合わせのような入力装置３０とを備える。ディスプレイ及び入力装置はデータ処理装置の周辺機器であり、当然ながら、データ処理装置はこれらアイテムなしで市販されてもよい。
【００２５】
データ処理装置は、例えば、パーソナルコンピュータ、Ｓｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ ３（登録商標）家庭用娯楽機器等のコンピュータゲーム機、又はＳｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ Ｐｏｒｔａｂｌｅ（登録商標）娯楽機器等のハンドヘルド機器であってよい。
【００２６】
システムユニット１０は、バス構造４０によって相互接続されたいくつかのアイテム、すなわち、中央演算処理装置（ＣＰＵ）５０、ランダムアクセスメモリ（ＲＡＭ）６０、読み取り専用メモリ（ＲＯＭ）７０、リムーバブル及び／又は固定ディスクストレージ（光ディスクストレージ等）８０、入力装置３０等の周辺機器と連結するための入出力（Ｉ／Ｏ）インタフェース９０、ネットワーク及び／又はインタネット接続１２０と連結するための有線及び／又は無線ネットワークインタフェース１００、並びにグラフィックスカード１１０を備える。
【００２７】
データ処理装置の２つの動作モードについて後述する。これらは、グラフィカル画像を後で生成する際に使用するための圧縮テクスチャマップの準備及びテクスチャをグラフィカルオブジェクトに適用するための圧縮テクスチャマップの復元である。概して、これらは、同一のデータ処理装置によって実行されることができる。だが、これらプロセスのうちの最初のプロセスが、いわゆるデベロッパーキットのような強力な非可搬式システム又は強力なパーソナルコンピュータによって実行され、第２のプロセスは、上述した娯楽機器のうちの１つ等の消費者機器によって実行される可能性のほうが高いことが理解されよう。以下の説明のために、図１に示す装置がいずれかのプロセスを実行可能な装置を表すものと仮定する。
【００２８】
動作に際して、コンピュータプログラムコードが、ディスクストレージ８０から、ＲＯＭ７０から、且つ／又はネットワーク接続１２０を介して読み取られ、ＲＡＭ６０にロードされ、恐らくは、入力装置３０から受信される信号に応答して、ＣＰＵ５０によって実行される。ＣＰＵ５０はデータ出力を生成し、このデータ出力はグラフィックスカード１１０に渡される。
【００２９】
グラフィックスカード１１０は、ＣＰＵ５０から受信されたデータに対して作用して、ディスプレイ２０に表示される画像を準備又は「レンダリング」する。グラフィックスカード１１０について以下でより詳細に説明する。概して、グラフィックスカード（当然ながら、カード形状である必要はなく、又は装置の残りの部分への接続に関して取り外し可能である必要さえもない）は、マイクロプロセッサ、及び関連付けられるメモリ、及び効率的な出力画像のレンダリングに固有の処理タスクの処理を専用とする他のハードウェアを備える。
【００３０】
図２は、グラフィックスカード１１０の概略図である。グラフィックスカードが、それ自体、非常に強力な計算装置であることができ、したがって、図２が単に、ＣＧ技術の包括的な説明の基本を形成するのではなく、グラフィックスカードの機能の、本説明に関連する部分の概観であることが理解されよう。ＰｌａｙＳｔａｔｉｏｎ ３（登録商標）娯楽機器のグラフィックスカードは、ＮＶＩＤＩＡ（登録商標）７８００（商標）グラフィックスカードに基づく。
【００３１】
したがって、概観として、グラフィックスカード１１０は、データをＣＰＵ５０から受信し、そのデータから、ディスプレイバッファ１８０に記憶される出力画像を生成する。プリミティブレンダラ１３０が、プリミティブとして知られている小さな画像部分を生成し、そこから、出力画像が構築される。各プリミティブは、例えば、出力画像内のオブジェクト又は画像背景の部分を形成する小さなポリゴンを表し得る。「深度」又は「ｚ」値が各プリミティブの各ピクセルに関連付けられて、最終画像内でのレンダリングされる他のプリミティブへの相対的な深度を示す。深度値は深度バッファ１４０に記憶される。同様に、透明度又は「α」値は各ピクセルに関連付けられて、透明さの程度を定義する。このようにして、最終画像は、背景ピクセルが非透明の前景ピクセルの背後に隠れるのに対して、同じ表示位置にある前景ピクセルが完全又は部分的に透明である場合、背景ピクセルが全体的又は部分的に見えるように構築することができる。
【００３２】
シェーダ１６０は、テクスチャマップバッファ１７０に記憶されたテクスチャマップを使用して、表面テクスチャをレンダリングされたプリミティブのうちのいくつか又はすべてに適用する。これらのテクスチャマップは、（例えば）ディスクストレージ８０、ＲＯＭ７０、ＲＡＭ６０から、又はネットワーク接続１２０を介して検索することができ、アクセスの容易さ及び速度のためにテクスチャマップバッファ１７０にローカルに記憶される。シェーダは、テクスチャマップデータのオリジナルソースから直接、すなわちローカルストレージを必要とすることなく働いてもよいが、このような構成は確実に、ローカルストレージにテクスチャマップデータをキャッシュするよりもかなり遅くなることが理解されよう。実際に、深度バッファ１４０、テクスチャマップバッファ１７０、及びディスプレイバッファ１８０は、図２に示されていないグラフィックスカードの他のストレージ要件と共に、動作速度のためにグラフィックスカード内又はグラフィックスカードの非常に近くに設けられるグラフィックスカードのローカルストレージ１５０の部分を形成する。
【００３３】
シェーダは、そのオブジェクトに適用すべき表面仕上げ又は表面外観を適用するために、レンダリングされるオブジェクトの性質又は表面や、仮想環境での任意の照明の反射性及び性質及び位置等の他の要因を考慮に入れる。頂点シェーディング、ピクセルシェーディング、ジオメトリシェーディング等のような多くの異なるシェーダ技術が提案及び開発されてきた。これらはすべて当該技術分野において既知であり、本実施形態は、テクスチャマップデータが適用される特定の技術にではなく、シェーダによって適用されるテクスチャマップデータの生成に関連するため、本明細書において詳細に説明しない。
【００３４】
シェーダは、通常、シェーダの機能に特に関連する特徴を有する特別に設計されたプログラミング言語であるシェーディング言語を使用して実装される。シェーダ言語で書かれたいくつかの機能例を以下に挙げる。Ｓｏｎｙ（登録商標）ＰｌａｙＳｔａｔｉｏｎ ３（登録商標）娯楽機器に使用されるグラフィックスカードは、毎秒７５０億回のシェーダ演算が可能であると報告されている。
【００３５】
図３は、前もって処理されたＭＩＰマップを示す概略図である。
【００３６】
用語「ＭＩＰマップ」は、本明細書では、異なるスケールのテクスチャマップセットを指すために使用される。本例では、スケールは、各スケール（解像度）が次に高いスケールのサイズの１／４（各次元が５０％）であるように、幾何（すなわち、対数）級数又は集合を形成する。特に、テクスチャマップ２００は２５６×２５６ピクセルという基本サイズを有する。ＭＩＰマップは、最高で８つのバージョンのテクスチャマップをさらに含み、そのテクスチャマップは、画像サイズ１２８×１２８、６４×６４、３２×３２、１６×１６、８×８、４×４、２×２、及び１×１ピクセルである。図３では、図面を明確にするために、最初の５つのスケールのみ、すなわち、２５６×２５６（テクスチャマップ２００）、１２８×１２８（テクスチャマップ２１０）、６４×６４（テクスチャマップ２２０）、３２×３２（テクスチャマップ２３０）、及び１６×１６（テクスチャマップ２４０）が示される。９つすべてのバージョンがある場合、ＭＩＰマップのストレージ要件の合計は、基本（２５６×２５６）テクスチャマップ２００のストレージ領域の４／３倍に非常に近い。
【００３７】
ＭＩＰマップ内の異なるテクスチャマップバージョンはすべて、（この例では）ＤＸＴ１圧縮を使用して圧縮されている。
【００３８】
シェーダは、ＭＩＰマップを使用して、一般にＭＩＰマップ内の２つの最も近いスケール間の補間によって所要のスケールのテクスチャ情報を生成する。このための様々な補間方法が提案されており、具体的な補間技術は本実施形態にとって重要ではない。異なるスケールのテクスチャマップバージョンが最初に生成され、アンチエイリアシング処理が実行された場合、この段階での補間が有利である。
【００３９】
テクスチャマップの所要のスケールは、レンダリング中のオブジェクトの表示サイズに依存し、表示サイズは、基本サイズ及びオブジェクトが仮想視点から（仮想環境内で）表示される距離に依存する。既知の技術が使用されて、補間されるテクスチャマップの所要のスケールが確立される。所要のスケールのテクスチャマップ全体を補間するのではなく、一般に、オブジェクトの表示に必要なこれらの部分のみが補間される。補間される部分のこの選択は、ピクセル単位で行うことができる。
【００４０】
したがって、例えば、オブジェクトの表示サイズが、（例えば）１６０×１６０ピクセルのスケールのテクスチャマップ２５０が必要であることを意味する場合、シェーダは、ＭＩＰマップ内の、２５６×２５６バージョン２００及び１２８×１２８ピクセルバージョン２１０からテクスチャの必要な部分を補間する。ＤＸＴ１圧縮は、圧縮画像の特定のブロックにローカルである（すなわち、ブロックの復元には、他のいかなるブロックの復元も必要としない）ため、復元する必要があるのは、補間プロセスに関連するバージョンのこれらの部分のみである。一例を図３に示し、部分２５２（シェーダによって従来通りに導出されるマップ内座標（ｕ，ｖ）によって定義される）が、シェーダ１６０において実行されている補間プロセス２６０によって、ＭＩＰマップ内の各画像バージョンの復元された部分２０２及び２１２から補間される。
【００４１】
図３は、ＭＩＰマップ技術を使用して前に提案されたシェーダに関連付けられる処理を表した。本発明の実施形態によるＭＩＰマップの生成及び使用と、シェーダ技術とに関連するプロセスについて、図４及び図５を参照してこれより説明する。
【００４２】
図４は、本発明の実施形態によるＭＩＰマップの生成を概略的に示す。これらの動作は、画像のリアルタイム表示ではなくデータの準備を指すため、一般に、グラフィックスカード１１０によって実行されない。むしろ、これらの動作は、通常、プログラム制御下のＣＰＵ５０によって実行される。
【００４３】
「基本」テクスチャマップ３００（例えば、２５６×２５６ピクセル）から、ＭＩＰマップが、テクスチャマップのより小さなバージョンシリーズ３１０、３２０、３３０、３４０、・・・を生成するために、オプションとして既知のアンチエイリアシング処理を含む既知の技術を使用して生成される。図３を参照して上述したように、シリーズは１×１ピクセルのバージョンまで可能であるが、最小バージョンは、単に図面を明確にするために、図４に示されない。
【００４４】
テクスチャマップは圧縮され（例えば、ＤＸＴ１圧縮を使用して）、それから、以下の処理のために復元される。続けて記憶又は送信されるテクスチャマップについては（マップ３００以外−以下参照）、圧縮された形態で記憶又は送信される。
【００４５】
基本テクスチャマップ３００は、最終的に破棄される。すなわち、記憶又は送信され、後にシェーダ１６０によって参照されるＭＩＰマップにおいて使用されない。しかし、基本テクスチャマップ３００は、ＭＩＰマップの準備に使用されるため、図４には破線で示される。
【００４６】
「差分」テクスチャマップシリーズが生成される。これらは図４において差分マップ３５０、３６０、３７０、及び３８０として示される。基本テクスチャマップ３００のサイズに対応する１つの差分マップ３５０があり、最小テクスチャマップサイズを除き、それよりも低い各テクスチャマップサイズ毎に１つの差分マップがある。
【００４７】
差分マップが生成される方法についてこれより説明する。各ＭＩＰマップレベル３１０、・・・、３３０毎に、ＣＰＵ５０はマップを復元し、以下のプログラムプロセスステップ３４２、３４４、３４６、及び３４８を実行する。
（ステップ３４２）倍率４で次に低い解像度画像バージョンを画像拡張（すなわち、スケーリング）する（すなわち、現在レベルと同じサイズにする）。
（ステップ３４４）現在レベルのピクセルと画像拡張された次に低いレベルのピクセルとの差分をピクセル単位で計算（すなわち、検出）する。
（ステップ３４６）差分を利得係数（スケーリング定数）で乗算し、オフセット（例えば、１２８＝ピクセル値の全範囲の半分）を適用する。
（ステップ３４８）ＤＸＴ１又は他の圧縮を使用して、差分画像を圧縮する。
【００４８】
利得係数は、例えば、圧縮／復元品質を向上させるために、４又は８であってよい。これは、差分値のすべてが（オフセットが適用される前）適度にゼロに近くなるため可能である。オフセットは、負の差分値を扱うために適用される。
【００４９】
画像拡張プロセスは、既知の双線形フィルタリングプロセスであってよい。
【００５０】
基本形態のＤＸＴ１圧縮は、２４ビットＲＧＢカラーデータの６：１固定圧縮を提供し、それによって、４×４ピクセルブロック（３８４ビット）は６４ビットデータ量に圧縮される。各ピクセルブロックは、５６５精度（すなわち、赤５ビット、緑６ビット、及び青５ビット）で開始カラー及び終了カラーを（既知の技術を使用して）選択し、開始カラーと終了カラーとの間に（ＲＧＢ色空間内の直線上で）均等に分散するものとして定義することができる最高で２つの最高精度中間色を考慮することによって圧縮される。それから、ブロック内の各ピクセルは、これらの４色のうち最も近い色の選択として２ビットインデックスを使用して符号化される。したがって、４×４ピクセルブロックの符号化に使用されるビット総数は、（１６ピクセル×２ビット／ピクセル）＋（２基準色×（５＋６＋５）ビット／基準色）＝６４ビットである。
【００５１】
ピクセルブロックが後に復元される場合に必要なのは、開始カラー及び終了カラーを検出し、色空間内で開始カラーと終了カラーとの間に均等に分散した２つの色を補間し、それから、各ピクセルに提供される２ビットインデックスと共にルックアップテーブル内のこれらの４色を使用することだけである。
【００５２】
図４を参照して、差分画像３６０の生成を概略形態で示す。テクスチャマップバージョン３２０が、テクスチャマップバージョン３１０と同じサイズに画像拡張される。上述したように、これら２つの差分が確立され、スケーリング、及びオフセットされて、差分画像３６０が生成され、それから、差分画像３６０はＤＸＴ１圧縮を受ける。対応する技術が使用されて、図４に示される他の差分画像が生成される。説明した技術が、最小テクスチャマップよりも１レベル（等比級数で）大きな最小差分画像をもたらすことが分かる。
【００５３】
基本テクスチャマップ３００が差分画像３５０の生成に使用されるが、後で使用するために記憶又は送信されないことが分かる。
【００５４】
テクスチャマップバージョン３１０、・・・、３４０もＤＸＴ１圧縮を受ける。
【００５５】
図４において生成されたすべてのデータは（好ましくは、本処理に関わる限り、破棄される最高解像度マップ３００は別として）、圧縮された形態で、ネットワークを介して送信することができ、且つ／又は光ディスク等の記憶媒体に記憶することができる。
【００５６】
図５は、図４に従って生成されたＭＩＰマップ（テクスチャマップ等の画像の複数の圧縮バージョンと、復元された画像バージョンとより高い各解像度画像バージョンとの画像差分に依存する差分データと、を含む）からの所要のテクスチャマップ値の補間を概略的に示す。これらの動作は、一般に、シェーダ１６０によってリアルタイムで実行される。
【００５７】
図５では、テクスチャマップバージョン３１０、・・・、３４０が、差分画像３５０、・・・３８０と共に提供される。ここでも、図面を明確にするために、少数の最小テクスチャマップバージョン及び差分画像が示されていないことに留意されたい。基本テクスチャマップ３００（図４）が提供されていないことにも留意されたい。
【００５８】
任意のサイズの所要のテクスチャマップスケール３９０の所要のテクスチャマップエリア３９２を生成する基本プロセスについて、これより説明する。本例では、所要のテクスチャマップスケールは、基本サイズ２５６×２５６ピクセルと次に低いサイズ１２８×１２８ピクセルとの間にある。
【００５９】
２つの補間プロセス４００、４１０がシェーダ１６０によって実行される。
【００６０】
補間プロセス４００は、シェーダ１６０によってこの目的のために選択された２つのテクスチャマップ内、すなわち（所要のスケール３９０から次に低い）テクスチャマップバージョン３１０及び（また次に低い）３２０内の領域３１２及び３２２を復元し、これら領域の間に作用して、所要の領域３９２に対応するが、所要のスケールの１／４（すなわち、ＭＩＰマップ構造内で１レベル下）の補間ピクセル又は領域を生成する。
【００６１】
補間プロセス４１０は、所要のスケール３９０の両側のスケールの各差分画像３５０、３６０内の領域３５２、３６２を復元し、これら領域の間に作用する。したがって、差分データの補間は、テクスチャデータの補間に使用された解像度より次に高い解像度の差分データを使用して行われる。
【００６２】
補間プロセス４００（すなわち、図５の例においてテクスチャマップバージョン３１０及び３２０に適用されるプロセス）は、所要の出力スケール３９０の出力ピクセルを生成するように、２つのテクスチャマップバージョン間を補間する。したがって、補間プロセス４００は、補間プロセス４１０に対してアップスケールすることを含むと考えることができる（しかし、実際には、両プロセスは単に、２つのＭＩＰバージョンを入力としており、所要のスケール３９０の出力を生成するように、シェーダの機能を使用して構成される）。
【００６３】
２つの補間プロセス４００、４１０の結果は、ここでもシェーダ１６０によって実施される結合プロセス４２０に渡される。結合プロセスは、以下のように２つの補間領域をとり、これらの補間領域を結合する。
差分画像ピクセル値を利得係数（上記参照）で除算し、オフセットを減算し、
差分画像ピクセル値及び補間テクスチャマップ内の対応するピクセル位置を加算して、所要の解像度の出力テクスチャマップを生成する。
【００６４】
各コマンドの説明と共に、シェーダプログラミング言語で実行されるこのプロセスの一例は以下である。
half3 base = tex2Dbias(baseTex, in_uv, bias_amount).xyz
half3は、続く変数名の種別を定義し、したがって、変数baseは半精度３構成要素（ＲＧＢ）変数である。
tex2Dbiasは、現在必要とされているスケールにバイアスＭＩＰレベルbias_amount（上記例では１であるが、他の実施形態では異なる数であってもよい）を加算したＭＩＰマップからピクセル値を生成するコマンドである。
baseTexは、テクスチャマップに対応するＭＩＰマップを識別する（この例では、マップ３１０、・・・、３４０）。
in_uvは、テクスチャマップ内の座標を表す。
.xyzは、引数の最初の３つの構成要素（ＲＧＢ）を結果として渡すべきであることを示す。
したがって、このコマンドは、別の方法で選択されたスケールよりも１つ低い（ＭＩＰチェーン内で）テクスチャマップスケールを使用して、所要のピクセルを生成する。
half3 diff = tex2D(diffTex, in_uv).xyz
tex2Dは、所要のスケールでの（オフセットなし）ＭＩＰマップからのピクセル値を生成するコマンドであり、
diffTexは、差分画像（すなわち、この例では画像３５０、・・・、３８０）に対応するＭＩＰマップを識別する。
half3 combined = base + scale.xxx * (diff-offset.xxx)
combinedは出力ピクセル値である。
scale（１／利得係数、を表す）及びoffsetについては図４を参照して上述した。
.xxxは、関連する変数の３つの構成要素の表現を示す。
【００６５】
可能な発展では、見ることができる細部がより少ない、より遠いオブジェクトを（通常）表す、所要のスケールがより小さい場合、差分マップの使用を低減するか、又は完全に回避し、それに代えて、所要の出力スケールの両側のスケールを有するテクスチャマップ間の単に従来の補間を使用することができる。したがって、例えば、仮に、所要の出力スケールが特定のレベルよりも小さい場合、従来の技術を使用することができるのに対し、所要の出力スケールがこのような閾値よりも大きい場合、差分ベースの技術を使用することができる。又は、従来の技術の結果と新しい技術の結果との加重和を使用してもよく、重み付けは、一般に、所要のスケールの増大に伴って新しい（差分画像）技術を優先するように増大する。これらの２つの可能性を組み合わせてもよく、すなわち、加重され閾値処理されるシステムであってもよく、重み付けは閾値スケールを超えて適用される。当然ながら、最大テクスチャマップバージョンが上述したように破棄されていると仮定して、従来の技術は、２番目のＭＩＰレベルよりも高い所要スケールでは適用することができない。
【００６６】
図４に示す技術を使用して生成されたＭＩＰマップのストレージ要件は、図３のＭＩＰマップのストレージ要件よりもわずかに高くなり得る。特に、この要件は基本マップ２００、３００のサイズの約５／３であり得る。しかし、ストレージ内のこの小さな増大によって、大幅に改良された画質を提供することができる。
【００６７】
まとめると、上述した実施形態は、ＣＧアプリケーションでのリアルタイムでの使用に特に適し（しかし、排他的に適するものではない）、メモリ又は処理オーバーヘッドを殆ど増大させずに向上した出力画質を提供することができる画像データ圧縮／復元技術を提供する。特に、同様のストレージ要件及び処理要件で、平滑照明勾配等の低空間周波数画像情報が符号化されている状況において、視認することができるノイズを低減することができる（従来の技術と比較して、この技術を使用することによって）。
【００６８】
上記実施形態は、適切なソフトウェアの制御下で動作した場合、上述した機能ステップを実行する手段を提供する図１のデータ処理装置によって実施することができる。特に、データ処理装置は、データ圧縮器、データ復元器、選択器、検出器、結合器、生成器等を提供し、これらはすべて上記技術において使用可能である。結果として、図４に関して説明したプロセスによって生成されるＭＩＰマップデータは、例えばコンピュータゲームの部分として、又はコンピュータゲームに関連して、ネットワークを介して送信することができ、且つ／又は記憶媒体に記憶することができる。
【特許請求の範囲】
【請求項１】
画像の複数のバージョンが圧縮される画像圧縮方法であって、各バージョンは異なる画像解像度を有し、該方法は、
前記画像の１つ又は複数の圧縮バージョンについて、
復元画像データを生成するために、その圧縮バージョンを復元するステップと、
前記画像の解像度のより高いバージョンと前記復元画像データとの画像差分を検出するステップと、
前記検出された画像差分に応じた差分データを圧縮するステップと、
を含む、方法。
【請求項２】
前記画像差分を検出するステップの前に、前記復元画像データを前記画像の解像度のより高い各バージョンの画像解像度に等しい画像解像度にスケーリングするステップを含む、請求項１に記載の方法。
【請求項３】
前記画像バージョンは、異なる各画像解像度を有するバージョンセットとして構成され、
前記検出するステップは、前記復元画像データと前記バージョンセット内で次に高い解像度を有する画像バージョンとの画像差分を検出するように構成される、請求項１又は２に記載の方法。
【請求項４】
前記バージョンは、特定の画像バージョンについて、前記次に高い解像度の画像バージョンが、その画像バージョンの解像度の所定の倍数である解像度を有するように、対数級数によって関連する各画像解像度を有する、請求項３に記載の方法。
【請求項５】
前記圧縮画像バージョン及び前記圧縮差分データを記憶及び／又は送信するステップを含み、その構成は、最高解像度画像バージョンについては圧縮画像データが後に使用するために記憶又は送信されないようなものである、先行するいずれか一項に記載の方法。
【請求項６】
前記差分データは、スケーリング定数を乗算した前記検出された画像差分に応じるものである、先行するいずれか一項に記載の方法。
【請求項７】
画像の複数の圧縮バージョンが提供される画像復元方法であって、各バージョンは、復元画像バージョンと解像度のより高い各画像バージョンとの画像差分に応じた圧縮差分データと共に、異なる画像解像度を有し、該方法は、
１つ又は複数の画像バージョンを選択するステップと、
前記選択された画像バージョンに関連する前記圧縮画像データを復元するステップと、
前記選択された画像バージョンよりも高い各解像度に関連する前記差分データを復元するステップと、
所要の出力解像度の出力画像を生成するために、前記復元画像データと前記復元差分データとを結合するステップと、
を含む、方法。
【請求項８】
前記画像バージョンは、異なる各画像解像度を有するバージョンセットとして構成され、
復元される前記差分データは、前記選択された画像バージョンよりも次に高い各解像度に関連する、請求項７に記載の方法。
【請求項９】
前記結合するステップは、前記出力画像の前記所要の解像度に応じて、該出力画像の生成に使用される前記復元差分データの割合を変更するように構成される、請求項８に記載の方法。
【請求項１０】
前記結合するステップは、実質的に、所要の出力解像度が低いほど前記出力画像が前記差分データに応じる程度が低くなるように構成される、請求項９に記載の方法。
【請求項１１】
前記所要の出力解像度が所定の最低範囲の場合、前記出力画像は前記差分データから独立する、請求項１０に記載の方法。
【請求項１２】
データ処理装置で実行されるとき、該データ処理装置に、先行するいずれか一項に記載の方法を実行させるプログラムコードを有するコンピュータソフトウェア。
【請求項１３】
請求項１２に記載のソフトウェアを提供する媒体。
【請求項１４】
請求項１３に記載の媒体であり、前記媒体は記憶媒体である。
【請求項１５】
請求項１３に記載の媒体であり、前記媒体は伝送媒体である。
【請求項１６】
画像の複数の圧縮バージョンを提供する圧縮画像セットであって、各バージョンは、異なる画像解像度と、圧縮バージョン毎に、復元時の該バージョンと前記画像の次に解像度の高いバージョンとの画像差分を表す差分データとを有する、圧縮画像セット。
【請求項１７】
請求項１６に記載の圧縮画像セットを保持する記憶媒体。
【請求項１８】
画像の複数のバージョンが圧縮される画像圧縮装置であって、各バージョンは異なる画像解像度を有し、該装置は、前記画像の１つ又は複数の圧縮バージョンについて、
復元画像データを生成するためにその圧縮バージョンを復元し、
前記画像の解像度のより高いバージョンと前記復元画像データとの画像差分を検出し、
前記検出された画像差分に応じた差分データを圧縮する、
ように動作可能である、画像圧縮装置。
【請求項１９】
画像の複数の圧縮バージョンが提供される画像復元装置であって、各バージョンは、復元画像バージョンと解像度のより高い各画像バージョンとの画像差分に応じた圧縮差分データと共に、異なる画像解像度を有し、該装置は、
１つ又は複数の画像バージョンを選択する選択器と、
前記選択された画像バージョンに関連する前記圧縮画像データを復元すると共に、前記選択された画像バージョンよりも高い各解像度に関連する前記差分データを復元する復元器と、
所要の出力解像度の出力画像を生成するために、前記復元画像データと前記復元差分データとを結合する結合器と、
を備える、装置。
【請求項１】
画像の複数のバージョンが圧縮される画像圧縮方法であって、各バージョンは異なる画像解像度を有し、該方法は、
前記画像の１つ又は複数の圧縮バージョンについて、
復元画像データを生成するために、その圧縮バージョンを復元するステップと、
前記画像の解像度のより高いバージョンと前記復元画像データとの画像差分を検出するステップと、
前記検出された画像差分に応じた差分データを圧縮するステップと、
を含む、方法。
【請求項２】
前記画像差分を検出するステップの前に、前記復元画像データを前記画像の解像度のより高い各バージョンの画像解像度に等しい画像解像度にスケーリングするステップを含む、請求項１に記載の方法。
【請求項３】
前記画像バージョンは、異なる各画像解像度を有するバージョンセットとして構成され、
前記検出するステップは、前記復元画像データと前記バージョンセット内で次に高い解像度を有する画像バージョンとの画像差分を検出するように構成される、請求項１又は２に記載の方法。
【請求項４】
前記バージョンは、特定の画像バージョンについて、前記次に高い解像度の画像バージョンが、その画像バージョンの解像度の所定の倍数である解像度を有するように、対数級数によって関連する各画像解像度を有する、請求項３に記載の方法。
【請求項５】
前記圧縮画像バージョン及び前記圧縮差分データを記憶及び／又は送信するステップを含み、その構成は、最高解像度画像バージョンについては圧縮画像データが後に使用するために記憶又は送信されないようなものである、先行するいずれか一項に記載の方法。
【請求項６】
前記差分データは、スケーリング定数を乗算した前記検出された画像差分に応じるものである、先行するいずれか一項に記載の方法。
【請求項７】
画像の複数の圧縮バージョンが提供される画像復元方法であって、各バージョンは、復元画像バージョンと解像度のより高い各画像バージョンとの画像差分に応じた圧縮差分データと共に、異なる画像解像度を有し、該方法は、
１つ又は複数の画像バージョンを選択するステップと、
前記選択された画像バージョンに関連する前記圧縮画像データを復元するステップと、
前記選択された画像バージョンよりも高い各解像度に関連する前記差分データを復元するステップと、
所要の出力解像度の出力画像を生成するために、前記復元画像データと前記復元差分データとを結合するステップと、
を含む、方法。
【請求項８】
前記画像バージョンは、異なる各画像解像度を有するバージョンセットとして構成され、
復元される前記差分データは、前記選択された画像バージョンよりも次に高い各解像度に関連する、請求項７に記載の方法。
【請求項９】
前記結合するステップは、前記出力画像の前記所要の解像度に応じて、該出力画像の生成に使用される前記復元差分データの割合を変更するように構成される、請求項８に記載の方法。
【請求項１０】
前記結合するステップは、実質的に、所要の出力解像度が低いほど前記出力画像が前記差分データに応じる程度が低くなるように構成される、請求項９に記載の方法。
【請求項１１】
前記所要の出力解像度が所定の最低範囲の場合、前記出力画像は前記差分データから独立する、請求項１０に記載の方法。
【請求項１２】
データ処理装置で実行されるとき、該データ処理装置に、先行するいずれか一項に記載の方法を実行させるプログラムコードを有するコンピュータソフトウェア。
【請求項１３】
請求項１２に記載のソフトウェアを提供する媒体。
【請求項１４】
請求項１３に記載の媒体であり、前記媒体は記憶媒体である。
【請求項１５】
請求項１３に記載の媒体であり、前記媒体は伝送媒体である。
【請求項１６】
画像の複数の圧縮バージョンを提供する圧縮画像セットであって、各バージョンは、異なる画像解像度と、圧縮バージョン毎に、復元時の該バージョンと前記画像の次に解像度の高いバージョンとの画像差分を表す差分データとを有する、圧縮画像セット。
【請求項１７】
請求項１６に記載の圧縮画像セットを保持する記憶媒体。
【請求項１８】
画像の複数のバージョンが圧縮される画像圧縮装置であって、各バージョンは異なる画像解像度を有し、該装置は、前記画像の１つ又は複数の圧縮バージョンについて、
復元画像データを生成するためにその圧縮バージョンを復元し、
前記画像の解像度のより高いバージョンと前記復元画像データとの画像差分を検出し、
前記検出された画像差分に応じた差分データを圧縮する、
ように動作可能である、画像圧縮装置。
【請求項１９】
画像の複数の圧縮バージョンが提供される画像復元装置であって、各バージョンは、復元画像バージョンと解像度のより高い各画像バージョンとの画像差分に応じた圧縮差分データと共に、異なる画像解像度を有し、該装置は、
１つ又は複数の画像バージョンを選択する選択器と、
前記選択された画像バージョンに関連する前記圧縮画像データを復元すると共に、前記選択された画像バージョンよりも高い各解像度に関連する前記差分データを復元する復元器と、
所要の出力解像度の出力画像を生成するために、前記復元画像データと前記復元差分データとを結合する結合器と、
を備える、装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１０−５１４３１０（Ｐ２０１０−５１４３１０Ａ）
【公表日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願番号】特願２００９−５４２２０３（Ｐ２００９−５４２２０３）
【出願日】平成１９年１２月１８日（２００７．１２．１８）
【国際出願番号】ＰＣＴ／ＧＢ２００７／００４８６２
【国際公開番号】ＷＯ２００８／０７５０２７
【国際公開日】平成２０年６月２６日（２００８．６．２６）
【出願人】（５０２０７０６７９）ソニー コンピュータ エンタテインメント ヨーロッパ リミテッド (40)
【Ｆターム（参考）】
【公表日】平成２２年４月３０日（２０１０．４．３０）
【国際特許分類】
【出願日】平成１９年１２月１８日（２００７．１２．１８）
【国際出願番号】ＰＣＴ／ＧＢ２００７／００４８６２
【国際公開番号】ＷＯ２００８／０７５０２７
【国際公開日】平成２０年６月２６日（２００８．６．２６）
【出願人】（５０２０７０６７９）ソニー コンピュータ エンタテインメント ヨーロッパ リミテッド (40)
【Ｆターム（参考）】
[ Back to top ]