(57)【要約】      （修正有）【課題】画像データの変換中は人工物（artefacts）の作成を防止する。【解決手段】ブロックが隣接し合うアレーの形態で、画像に関するデータの元のセットを受信する工程、および、所定の変換アルゴリズムに従って、それぞれのブロックのデータを、アレー内のそれぞれのすぐ隣のブロックのデータと一緒に処理することにより、ブロック境界人工物が実質的にない変換されたデータのそれぞれのブロックを作成する工程、を包含する。【選択図】図１２
2010022006.tif 000002
【特許請求の範囲】
【請求項１】
画像データの変換中は人工物（artefacts）の作成を防止する方法であって、
ブロックが隣接し合うアレーの形態で、画像に関するデータの元のセットを受信する工程、および
所定の変換アルゴリズムに従って、それぞれのブロックのデータを、アレー内のそれぞれのすぐ隣のブロックのデータと一緒に処理することにより、ブロック境界人工物が実質的にない変換されたデータのそれぞれのブロックを作成する工程、
を包含することを特徴とする方法。
【請求項２】
前記ブロックのそれぞれにある変換されたデータを別々に圧縮する工程をさらに包含することを特徴とする、請求項１に記載の方法。
【請求項３】
圧縮されたデータのブロックを順次送信する工程をさらに包含することを特徴とする、請求項２に記載の方法。
【請求項４】
圧縮されたデータの送信されたブロックを受信し、それぞれのブロックを順次解凍して
前記変換されたデータを再生する工程をさらに包含することを特徴とする、請求項３に記載の方法。
【請求項５】
逆のアルゴリズムに従って前記再生された変換データをさらに圧縮する工程をさらに包含することを特徴とする、請求項４に記載の方法。
【請求項６】
前記データの元のセットは画像信号の全体のフレームの画素を構成していることを特徴とする、請求項１から５のいずれかに記載の方法。
【請求項７】
それぞれのブロックは、１０２４個の画素を備えることを特徴とする、請求項６に記載の方法。
【請求項８】
請求項１に記載の方法に従って処理された隣接し合うブロックのアレーの形態の画像に関連するデータの元のセットを再生して変換データのブロックを作成する方法であって、
前記所定の変換アルゴリズムの逆であるアルゴリズムに従って変換データのそれぞれのブロックを処理することで、アレー内のそれぞれのすぐ隣のブロックのデータと一緒にそれぞれのブロックのデータを再生する工程と、
得られた処理済ブロックを組み合わせることで元の画像を再生する工程と、を包含することを特徴とする方法。
【請求項９】
前記所定の変換アルゴリズムは、ウェーブレット変換を備えることを特徴とする、請求項１から８のいずれかに記載の方法。
【請求項１０】
前記ウェーブレット変換は、２／１０変換であることを特徴とする、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理の方法に関し、より詳細には、画像に関するデータの処理方法に関する。本発明は特に、但しそれに限定されるわけではないが、データ圧縮の方法に関する。
【背景技術】
【０００２】
［圧縮の問題］
電子画像がすでにデジタル形式であると仮定すると、画像圧縮は、画像を表現するのに必要とされるデータビットの数を大幅に削減する手段である。典型的なパラメータは次の通りである。
【０００３】
色パラメータ        ３（例えば、ＲＧＢまたはＹＵＶ）
色当たりのビット    ８（例えば、４、１０、１２）
水平画素  １４００（または、例えば、７２０、１０２４、１６００、１９２０）
垂直画素  １０５０（または、例えば、５８８、７６８、１２００）
秒当たりのフレーム  ６０（または、例えば、２４、３０、８５）
従って、６０Ｈｚで稼動するＳＸＧＡ＋（１４００×１０５０）画像の場合、非圧縮データ速度は例えば次の通りであり、これは最上位モデル製品の典型的な要件であり得る。
【０００４】
３×８×１４００×１０５０×６０＝２，１１６，８００，０００ビット／秒
元々はアナログ時代に導入されたものであるが、実際には現在にも等しく適用できる帯域幅縮小の「典型的な」方法としては、（ａ）代替の色空間を使うことによる色の縮小（例えば、縮小された彩度情報）、および（ｂ）フレームごとのデータ縮小（例えば、それぞれが全フレーム解像度の半分である「インターレースされた」画像を使うことによって行うが、それでも動作を行うための高いフレーム速度が可能である）が挙げられる。
【０００５】
従って、（いわゆる１９２０ｉフォーマットに基づく）「高品位」画像データ速度は次のようになり得る。
【０００６】
１６×１９２０×１０２４×３０＝９４３，７１８，４００ビット／秒
しかしながら、かかる構成は、せいぜいよくても部分的に問題点を緩和するにすぎない。明らかに、さらにもっと積極的な方法が必要である。映像からＵＸＧＡにわたる画像のための目標ビット速度は、動作量が変動する状態で、０．５から１００Ｍｂ／秒にわたるが、１０Ｍｂ／秒未満の速度に重点を置く。
【０００７】
［圧縮の基礎］
画像圧縮には、空間的圧縮と時間的圧縮の２つのタイプがある。空間的圧縮は、単一画像フレームを記述するのに必要とされる情報量を削減するものであり、時相的圧縮は、フレームごとに全フレームデータを送る必要を少なくしつつも圧縮されていない画像における動きは維持したままとするものである。
【０００８】
空間圧縮を使って単一画像フレームを圧縮するための望ましい方法は次の通りである。
（ａ）画像をより効率的または「簡便な」やり方で記述できる方法を見出す。例えば、広い領域が緑色で着色されている場合、ただ単にこの領域を限られた数の座標で定義し、これを画素ごとに記録するのではなく「緑」とコード化する。
（ｂ）必要に応じて、人間の視覚の公知の特徴を利用し、見る人物には見えないかもしれない画像の局面に関するデータを排除するかまたは少なくする、および、
（ｃ）得られた数値データを取りこれを、例えば冗長なゼロを抑制するまたはランレングス符号化のような標準的な損失なしのデータ圧縮技術によって、より効率的に記録する。
【０００９】
時間的圧縮のための主な方法は、連続的な画像を比較し、１つの画像と他の画像との変化に対して送信される情報を制限することである。かかる方法を使用する場合、全フレーム画像またはその等価物を周期的に送って画像の復元が正しいデータから確実に起こるようにする方法がなければならない。
【００１０】
［圧縮システムの必要な属性］
特定の用途向けの圧縮システムを開発する際、数多くの優先すべき事項を次のように特定できる。
（ａ）システムは最小限の待ち時間でリアルタイムに作動しなければならない。
（ｂ）システムはさまざまな「ビット深さ」に適さなければならない。８ビット画素が典型的に使用されるが、特定の用途ではシステムを１０または１２ビット画素まで拡張するのが望ましいであろう。
（ｃ）システムは空間的解像度の点でスケーラブルでなくてはならない。最も高い現行の解像度は１６００×１２００（ＵＸＧＡ）であるが、原則としてシステムはより高い解像度が導入された場合これらにも対応できるべきである。
（ｄ）ハードウェアの点で、システムは「対称的」である必要がある、すなわち、符号器を実現する費用は復号器を実現する費用と大幅に異なるべきではない、（ただし用途によってはソフトウェアベースの復号器の場所もあることが認識される）。
（ｅ）システムは標準的なコンポーネントを使って実現できなければならない（ただし大容量用途向けにはＡＳＩＣバージョンが考えられるであろう）。
（ｆ）高解像度画像データ全体を処理する必要なしに、高解像度画像の低解像度バージョンを抽出できるまたは高解像度画像の一部を抽出できなければならない。かかる特徴は非常に重要である。
【００１１】
［ウェーブレット変換の選択］
実用的な空間的画像圧縮システムは、画像情報中の冗長性を簡単に識別でき排除できる方法を必要とする。理論的には元の画素数値データを分析することは可能であるが、現実にはこれは非効率的であり計算的に集約されてしまう。
【００１２】
現状の手法は、元の画素データを他のフォーマットに「変換」することである。新しいフォーマット自身は画像を表現するのに必要なデータ量を少なくすることはしないが、これが行うのは、冗長な情報を簡単に識別し排除できるようにデータを表示するということである。この新しいフォーマットはまた、効率的に符号化できるやり方でのデータ表示もする。
【００１３】
変換の考え方は、フーリエ法則によって例示される。この法則は、調和して関連し合う振幅の変動する数多くの正弦波を一緒にすることによって、どのような複雑な波形でも再生できることを示している。使用する高調波の数が多いほど、得られる結果は元の波形に近くなる。従って、例えば、「矩形波」は、その振幅が等間隔でゼロから最大値まで変化しそして再び戻るものとして示される「時間」ドメインか、または元の波形の基本周波数のそれぞれの高調波に当てはまる１組の係数が規定される「周波数」ドメインのいずれかで記述できる。
【００１４】
変換の概念は、矩形波の例によりほぼ近い形で図示される。高調波の振幅を周波数に対して描く場合、結果はＳｉｎｘ／ｘ関数である。
【００１５】
図１は、このような「変換対」を示している。左側の波形が時間に対する振幅を表す場合、右側のものは周波数の分布を示しているが、これが逆であっても同じことが当てはまる。すなわち、左側のものが周波数の分布を示す場合、右側のものはその結果得られる、時間に対する振幅である。
【００１６】
図示される変換対の特徴は、左側の関数が狭くなるほど右側の関数が広くなるということである。このことは、もし狭い範囲の周波数だけがある場合、得られる振幅分布は「広く平坦になる」であろうと言うのに等しい。周波数分布がゼロになる場合の限界点では、結果は長さが無限大の平坦な線、すなわち「直流」になる。
【００１７】
この変換対の例について興味深い点は、これがどのように時間／周波数変換を作成することができるかについての手がかりを提供することである。左側の関数がフィルタの帯域幅を表す場合は、右側の関数はフィルタのインパルス応答を表す。
【００１８】
画像圧縮は、実際に、まさに周波数ドメインの考え方を使うものである。通常の構成では、画像を複数のブロックに分割し、ブロックはそれぞれが画素のアレーからなる。そして、周波数分布についてそれぞれのブロックを検討する。画像の「縁」では「高い」周波数が生じるが、均一な「輝度」の領域は「低い」周波数を示す。
【００１９】
画像圧縮のためのもっとも公知の変換は離散コサイン変換（ＤＣＴ）であり、これはフーリエ変換の空間版である。その原理は、広い範囲の周波数に対して画像データを「試験」し、それぞれについて係数を生成するというものである。このプロセスは、それ自体が原則的に無限の正弦波（ただし実際には必ず上が切り取られた状態になる）である基底関数の使用を必要とする。ＤＣＴの特徴は周波数ドメインを等しい増分に分割する点であり、このことの当然の帰結として、基底関数は周波数に従った異なるサイクル数を含む。
【００２０】
ＤＣＴに代わるものとしてウェーブレット変換が普及しており、これは入力帯域幅を半分に分割する、カスケード状に配列された一連の補完的な高いおよび低いパスフィルタを使って実行されるものである。それぞれのフィルタの出力は図２に図示されるように２分の１にダウンサンプルされるため、カスケードの出力データは入力データと同じ大きさである。ハイパスフィルタのインパルス応答は「ウェーブレット」である。
【００２１】
ウェーブレットの特徴は、この文脈では、ウェーブレット基底関数が、周波数に関わりなくすべて同じサイクル数を含んでいることであり、このことはこれらが異なる長さであることを意味する。図示されるカスケード構成では、ウェーブレットのセットは、それぞれのステージで２分の１に変倍された１つの単一のウェーブレットから導き出されている。
【００２２】
カスケードの終わりには、厳重に帯域が制限された信号がある。前回の周波数帯域から係数を追加すると利用できる解像度が２倍になり、処理が繰り返されると、解像度が再び２倍になる。このことはウェーブレット変換の３つの属性を表している、すなわち、
（ａ）当然ながら変倍可能である。
（ｂ）周波数ドメインが等しい増分ではなくオクターブに分割される。
（ｃ）画像処理の状況では、利用可能なデータの一部だけを使うことによって画像の低解像度版を得ることが可能である。
【００２３】
簡単な例を挙げると、もし１６個の入力サンプルが４つのステージのカスケードに供給されると、最初のステージでは差分の８つのサンプルを作成することになる。次のステージでは４つの、その次の２つの、そして最終的には差分の１つのサンプルを、単一の値とともに生成することになる。この単一の値はローパスフィルタのシーケンスから由来するもので、１６個すべてのサンプルの平均的な「輝度」とみなすことができる（直流成分）。出力サンプルの総数は入力総数と同じである、すなわち、
（８＋４＋２＋１）個の差分＋（１）個の平均値＝１６
画像の高周波数成分は数多くの短いウェーブレットによって記述され、低周波数部分は数少ない長いウェーブレットによって記述される。
【００２４】
ウェーブレット変換は、時期が合う一連の離散的信号とみなすことができ、これらの離散的信号はそれぞれが画像の複数の解像度分析を提供するものである。変換の目的は、画像をより重要性の大きな係数またはより重要性の低い係数に分解することである。そして、あまり重要でない係数は量子化または排除できる。ウェーブレット変換は（他の変換と比べると）有意の係数をもっともよい形でコンパクト化するものである。
【００２５】
電子画像は「１次元的」ではなく、２次元的画素アレーからなる。従って、画像圧縮では、変換プロセスを２次元で行う必要がある。単一段ウェーブレット分解のプロセスを図３に示す。元の画像はろ過されて４つの周波数帯となる、すなわち、ＬＬは、水平および垂直方向の両方にローパスフィルタ化されサブサンプル化された元の画像である。ＨＬは、残りの垂直周波数、すなわち、元の画像とＬＬ画像との間の差の垂直成分からなる。同様に、ＬＨは残りの水平周波数からなり、垂直および水平両方のフィルタリングの高周波数成分からなるＨＨは、残りの斜め周波数を表している。
【００２６】
実際には、多段分解が生じる。ＬＬは解像度が低くされた全体の画像（または画像の一部）を表しているため、ここでＬＬ画像に対しフィルタリングプロセスを行って第２レベルの分解を行う。損失なしの変換（すなわち、情報内容が失われることのない変換）を行うためには、個々の画素の空間的な等価物までプロセスを繰り返す必要がある。
【００２７】
従って、例えば、プロセスを４×４画素ブロックに適用する場合、「レベル１」変換を想定できる。この場合、水平および垂直方向の両方にフィルタ対を適用することによって４つの係数が導かれる。そして、「レベル２」変換でローパスフィルタの出力を表している情報の４分の１に対し同じプロセスを行う、これは空間的な意味では画素レベルである。（ブロックがより大きかった場合は、損失なしの変換を行うのにより大きな「レベル」が必要になると思われる。）
【００２８】
変換の復号化（「再構築」）は符号化（「分解」または「破壊」）プロセスの逆であり、どのような現実の実行でも高度に対称的であることを指す。簡素なフィルタ対レベルでは、もし２つの入力の流れが２倍にアップサンプル化され、その後、ろ過されそして再度組み合わされると、得られる結果は元の空間的データである。完全な再構築が起こるためには、復号化フィルタは符号化フィルタの応答と正確に一致しなければならず、「レベル」数が同じでなければならない。
【００２９】
好ましい圧縮法の基礎としてウェーブレット変換が選択された。なぜなら、
（ａ）固有のスケーラビリティを持つ、
（ｂ）有意な変換係数をもっともよい形でコンパクト化する、
（ｃ）イメージデータ全体を処理せずして画像の低解像度バージョンを簡単に導き出せる、
（ｄ）高速平行処理に変更可能である、
（ｅ）効率的な符号化に変更可能である、そして
（ｆ）（変換へのまたは変換からの）符号化および復号化プロセスが対称的であるからである。
【００３０】
ウェーブレット変換に基づいて圧縮システムを実現する際、システムが標準的な機材を使って実現するよう実行可能でありまた市場のニーズを満たすことを確実にするための、多数の重要な実行上の点を考慮に入れるべきである。
【００３１】
設計に多大な影響を及ぼすいくつかの特定の点としては次のものが挙げられる、
（ａ）システムは損失なしの（典型的な実現される割合は２：１）から視覚的に損失なしの（おそらく３０：１と高い）にわたり損失ありの（５０：１以上）までに及ぶ広い範囲の空間的圧縮比に対応できなければならない。
（ｂ）符号化および復号化プロセスの作業は、画像の複雑さに関わりなくこれらが定義された時間サイクル内で作動しなければならない意味で決定的でなければならない。明らかに、これらは「リアルタイム」に作動しなければならない。
（ｃ）フルモーション「ビデオ」画像および高解像度「グラフィック」画像の異なるニーズを全面的に考慮しなければならない。
【００３２】
システム全体の説明はセクションに分割でき、次のように要約される。
（ａ）入力システム、色空間の選択、
（ｂ）ウェーブレット変換エンジン、
（ｃ）得られたデータの符号化
（ｄ）一時的圧縮のための符号化
（ｅ）ネットワーク接続、および
（ｆ）復号化
画像入力からデータストリーム出力までの異なるステージを図５に図示する。
【００３３】
実際のシステムは、実行可能である限り、既存の標準に基づいていなければならない。従って、好ましいシステムへの「入力」は現在のデジタル画像標準、主にコンピュータグラフィック画像のためのＤＶＩ標準、およびビデオおよび高品位ビデオ画像のためのＳＤＩおよびＨＤＳＤＩ標準に基づいている。ＤＶＩそれ自体は事実上１６００×１２００（画素当たり２４ビット）の画像解像度に制限されているが、複数のＤＶＩ信号をいくつかの組に編成してより大きな画像を記述することが可能である。明らかに、いずれの実際のシステムもより高い解像度および新しいトランスポート基準に、それらが利用可能となると同時に適合するように設計されていなければならない。
【００３４】
電子画像は通常、色パラメータＲＧＢ（赤、緑、青）によって記述される。従って、原則的にはいずれの圧縮システムも３部構成で作動しなければならない。すなわち、色パラメータそれぞれ対して１つの「チャネル」である。これは、一般にＹＵＶと呼ばれる他の色空間に使うのに都合がよいもので、この場合、Ｙは「輝度」または「白色明るさ」値であり、ＵおよびＶは一括して「クロミナンス」または「色差」値と呼ばれる２つの「色差」値である。ＲＧＢからＹＵＶへの基本的な変換ではデータ量が減ることはないが、実際には、人間の目は輝度空間的解像度に比べるとクロミナンス空間的解像度に対する感度が鈍い。従って、この事実がカラーテレビ帯域軽減の手段としてその発足当初から使用されてきた。
【００３５】
ＹＵＶの使用に限られるわけではないが、好ましいシステムはこれに基づいている、なぜならこれを使用することでクロミナンスおよび輝度情報について微分符号化速度が可能となり、その結果、人間の目の応答性を利用して圧縮効率が改善されるからである。ＲＧＢとＹＵＶとの間の変換は簡単な演算のように見受けられるが、画像の劣化かデータ量の増加のいずれかを招く可能性のある落とし穴がある。
【００３６】
ＣＣＩＲ６０１標準は以下のマトリックスによって成分ビデオを定義している。
【００３７】
【数１】
2010022006.tif 000003
【００３８】
このマトリックスは、それ自体は損失なしの可逆転換には適さない、なぜなら転換要因として非整数を使用するからである。従って、好ましいシステムは以下の数式を使用する。この数式はＣＣＩＲマトリックスの近似を表しており、損失なしの可逆転換を実現するものである。ここで、Ｙ、Ｕ、よびＶは可逆輝度およびクロミナンス値である。
【００３９】
【数２】
2010022006.tif 000004
【００４０】
上述の数式で、記号eｘuは「床」関数と呼ばれるもので、ｘ以下の最大整数として定義されるものである。上述の数式は以下の属性を持つ。
（ａ）入力がＮビットのＲＧＢであれば、損失なしの変換もまたＮビットを持つＹｒとなるが、ＵｒおよびＶｒ成分はＮ＋１ビットを持つ。
（ｂ）その後、成分が逆転されると、結果はＮビットのＲＧＢ信号である。
【００４１】
本発明の背後には開発の一部として２つの問題が生じる。すなわち、
（ａ）ウェーブレット変換に適用した場合、クロミナンス成分における余分なビットの生成を損失なしの性能を失うことなく吸収することは可能であるか。
（ｂ）損失ありの圧縮が必要な場合、数式を改変して性能を最適化すべきか。
【００４２】
１つの重要な発見は、損失なしの動作を行うための色変換およびウェーブレット変換ビット成長は両方とも、組み合わされた結果を精度保存の特性（ＰＰＰ）と呼ばれる特性に適用することによって省けるであろうということであった。この技術のさらなる詳細は、非特許文献１に見出すことができる。しかしながら、上述の数式およびＰＰＰ技術は両方とも、損失なしの変換だけに適用されるものである。
【００４３】
損失ありの変換が必要な場合は、他の技術を使用する。ここで、その目的はただ単に元の範囲を保存し確実にビット成長がないようにするだけである。これは以下の数式を使って実現される。
【００４４】
【数３】
2010022006.tif 000005
【先行技術文献】
【非特許文献】
【００４５】
【非特許文献１】１９９７年１２月Hongyang Chao, Paul Fisher, Zeyi Hua著「An Approach to the Integer Wavelet Transformations for Lossless Image Compression（損失なしの画像圧縮のための整数ウェーブレット変換の方法）」
【発明の概要】
【発明が解決しようとする課題】
【００４６】
データの有効な符号化を可能とし、損失なし、または損失ありのいずれかである得る空間的および時間的両方の画像データ圧縮の方法を提供することにある。
【課題を解決するための手段】
【００４７】
本発明によると、画像データの転送中は人工物の作成を防止する方法が提供されている。この方法は、ブロックが隣接し合うアレーの形態の画像に関するデータの元のセットを受信する工程、および所定の変換アルゴリズムに従って、それぞれのブロックのデータを、アレー内のそれぞれのすぐ隣のブロックのデータと一緒に処理することにより、ブロック境界人工物が実質的にない変換されたデータのそれぞれのブロックを作成する工程を包含する。
【００４８】
前記ブロックのそれぞれにある変換されたデータは別々に圧縮される。このことは、ひいては、得られた圧縮データは別々に解凍できることを意味し、これによりいくつかの圧縮されたブロックだけを解凍する目的で選択できる。
【００４９】
本方法は、好ましくは、圧縮されたデータのブロックを順次送信する工程をさらに包含する。
【００５０】
本発明は、圧縮されたデータの送信されたブロックを受信し、それぞれのブロックを順次解凍して前記変換されたデータを再生する工程にも及んでいる。
【００５１】
本発明は好ましくは、逆のアルゴリズムに従って前記再生された変換データをさらに圧縮する工程をさらに包含する。
【００５２】
前記データの元のセットは画像信号の全体のフレームの画素を構成し得る。この場合、それぞれのブロックは１０２４個の画素を備え得る。
【００５３】
本発明のさらなる側面によると、上述の方法に従って処理された隣接し合うブロックのアレーの形態の画像に関連するデータの元のセットを再生して変換データのブロックを作成する方法が提要される。この方法は、前記所定の変換アルゴリズムの逆であるアルゴリズムに従って変換データのそれぞれのブロックを処理することで、アレー内のそれぞれのすぐ隣のブロックのデータと一緒にそれぞれのブロックのデータを再生する工程、および得られた処理済ブロックを組み合わせることで元の画像を再生する工程を包含する。
【００５４】
前記所定の変換アルゴリズムは、２／１０変換のようなウェーブレット変換を備え得る。
【発明の効果】
【００５５】
本発明によれば、画像データの転送中において人工物の作成を防止することができる。
【図面の簡単な説明】
【００５６】
【図１】「変換対」の一例を図示している。
【図２】カスケードになった１セットのフィルタを使ってどのようにウェーブレット変換が実行されるかを図示している。
【図３】単一段のウェーブレット分解を示している。
【図４】復号器における単一段のウェーブレット再構築を示している。
【図５】好ましい符号器内のプロセスを図示している。
【図６】５レベル分解を図示している。
【図７】ブロックベースのハール変換を図示している。
【図８】変換の動作を図示するための画素アレーの一例を示している。
【図９】数式１および２を図８のアレーに適用した結果を図示しており、これら数式はｒ＝０…９およびｃ＝０…４の範囲で解かれている。
【図１０】数式５、６、９および１０を図９示す水平変換データに適用した結果を図示しており、範囲はｒ＝０…４およびｃ＝０…４であり、例示的な画素アレーのためのハール変換を表している。
【図１１】２／１０変換数式をサンプル画素アレーに適用した結果を図示している。
【図１２】符号化システム全体のアーキテクチャを示すブロック図である。
【図１３】好ましい変換エンジンを詳細に図示している。
【図１４】メモリにおける連続的な書き換えを図示している。
【図１５】どのようにして係数データが分析されるかを示すＣＫＬ−ツリーを図示している。
【図１６】６４ＬタイプからなるＬツリーを図示しており、２４が図上の「Ｌボックス」として示されており、残りの４０はレベル３ＬＨおよびＨＨＬタイプの子供として暗示されている。
【図１７】８つすべてのデータ面を複合物として検討することにより符号化損失を省く概念を図示している。
【図１８】５レベル変換に適用される重み付け要因の概念を図示しており、典型的にはａ＝２である。
【図１９】どのようにして１ビット面の係数データの組織がウェーブレット変換に直接関連するかを図示している。
【図２０】好ましいＬ符号器を図示している。
【図２１】好ましいＣＳ符号器を図示している。
【図２２】ＬＫＣＳパスを図示している。
【図２３】好ましい一時的符号化プロセスの図式化である。
【図２４】標準的なイーサネット（登録商標）で使用されるＩＥＥＥ８０２．３フレームフォーマットを図示している。
【図２５】圧縮された画像ストリームのＩＰパケットへの変換を図示している。
【図２６】ビットストリームの一部を示しており、２つの連続的な画像ブロックを、互いに同期言語、および画像内のブロック位置を特定する指標番号が関連し合った状態で示している。
【発明を実施するための形態】
【００５７】
ここで本発明の好ましい実施態様を、添付の図面を参照しながら詳細に説明する。
【００５８】
［ウェーブレット変換エンジン］
好ましい設計の大きな利点は、画像の破壊および再構築に同じ「エンジン」を使用することができる点である。この設計は、リアルタイムに２次元で５レベル変換を実行する単一フィルタバンクからなるアーキテクチャを使用する。
【００５９】
上述から、５レベル変換を使用することにより３２×３２画素ブロックを記述するデータが得られることがわかる。しかしながら、もしこれが文字通り符号化段階における場合であったなら、最終的な結果は「濃淡のむらのある（blocky）」画像（特に高い圧縮割合では）となるであろう。ブロックの端にある画素に関連するデータが隣接するブロックの画素のエネルギーを完全に考慮することを確実にするには、変換プロセスは画素アレー全体を「掃引」しなければならない。従って、得られるデータは、実際には一連の３２×３２ブロックを表すものとしてフォーマットされるが、このようにして得られた画像情報それ自体はブロックベースではない。
【００６０】
図６は、５レベル変換プロセスの目的を示している。レベル３には１６個の係数があり、レベル４には４つの係数があり、レベル５には１つの係数がある。ウェーブレット変換が信号をさまざまなサブ帯域に分解できる方法はいくつかある。かかる方法としては、均一な分解、オクターブ帯域分解、および適応またはウェーブレットパケット分解が挙げられる。これらのうち、オクターブ帯域分解がもっとも広く使用されている。これは不均一帯域分裂法であり、より周波数の低い部分をより狭い帯域に分解し、それぞれのレベルのハイパス出力にはさらなる分解を全くせずしてそのまま残すものである。
【００６１】
システムをさまざまな供給源材料に最適なものにするために、好ましいシステムは２つの異なるウェーブレット変換を使用するようセットアップされる。ハール変換は鮮明な切れ目または「エッジ」の定義が正確である必要がある場合に材料に使用され、「ツー／テン」またはＴＴ変換は、「円滑な」結果がより喜ばしい場合にビデオ画像を移動するための別の方法として提供されるものである。
【００６２】
ハール変換は、鮮明な切れ目（実際には細い線など）の一体性を維持することが非常に重要なグラフィック画像の圧縮に最良である。移動しているビデオ画像をともなう場合、異なる変換を使用すると恩恵があり、好ましいシステムは、使用されている画像のタイプに従ってハール変換をとるか「ツー／テン」（またはＴＴ、または２／１０）変換をとるかの選択が可能である。
【００６３】
過酷な圧縮を行うと、画像を再構築した場合、画像人工物がブロック境界に現れる傾向がある。２／１０変換はより多くの画素をハイパスフィルタで処理するがこれには画像を「円滑化する」効果があり、ビデオ内容において視覚的により許容される結果を与える。
【００６４】
ブロックベースのハール変換では、画像は３２×３２画素ブロックで処理され、１つのブロックがＹ、ＵおよびＶそれぞれのためのものである。このことを図７に図面によって示す。実際には、画素はそれぞれが２画素×２画素の１６×１６重複なしブロックとして処理される。実際の処理、およびそれが２／１０変換に必要とされる処理に類似する点を以下に説明する。
【００６５】
両方の変換で、２段処理を使用する。第１段では、１次元的変換で画素データから２つの係数ＬおよびＨが導き出され、そして第２段では、２次元的変換によりＬＬ、ＬＨ、ＨＬおよびＨＨ値が導き出される。実際のところ、当初のローパスフィルタリングのための数式は両方の変換について同じである。ハイパスフィルタリングも似通ってはいるが、２／１０変換の場合、既存の導き出されたローパス値を観察した結果導き出されるさらに別の「予測」値がある。このことは得られる画像を「平滑化」する効果がある。
【００６６】
以下の数式では、Ｐを使ってもとの画素データを表している。接尾辞ｒ、ｃは縦および横の座標をそれぞれ表しており、ｐは予測子を示している。
【００６７】
数式１．ハールおよび２／１０変換両方のためのＬの誘導
【００６８】
【数４】
2010022006.tif 000006
【００６９】
数式２．ハール変換におけるＨの誘導
【００７０】
【数５】
2010022006.tif 000007
【００７１】
数式３．２／１０変換における予測子ｐＨの誘導
【００７２】
【数６】
2010022006.tif 000008
【００７３】
数式４．２／１０変換におけるＨの誘導
【００７４】
【数７】
2010022006.tif 000009
【００７５】
数式５．ハール変換および２／１０変換の両方のためのＬＬの誘導
【００７６】
【数８】
2010022006.tif 000010
【００７７】
数式６．ハール変換におけるＬＨの誘導
【００７８】
【数９】
2010022006.tif 000011
【００７９】
数式７．２／１０変換における予測子ｐＬＨの誘導
【００８０】
【数１０】
2010022006.tif 000012
【００８１】
数式８．２／１０変換におけるＬＨの誘導
【００８２】
【数１１】
2010022006.tif 000013
【００８３】
数式９．ハール変換および２／１０変換の両方のためのＨＬの誘導
【００８４】
【数１２】
2010022006.tif 000014
【００８５】
数式１０．ハール変換におけるＨＨの誘導
【００８６】
【数１３】
2010022006.tif 000015
【００８７】
数式１１．２／１０変換における予測子ｐＨＨの誘導
【００８８】
【数１４】
2010022006.tif 000016
【００８９】
数式１２．２／１０変換におけるＨＨの誘導
【００９０】
【数１５】
2010022006.tif 000017
【００９１】
［稼働中の変換数式の例］
上述の数式の動作は例によってもっともよく理解される。図８は、Ｐについていくつかの任意の値を持つ１０×１０画素の画素アレーを示している。レイアウトは純粋に２／１０変換およびハール変換のはたらきに注意を引くための一例である。１０×１０アレーは２／１０を例示するために使用できる最小限度のものでありその他の意味合いはない。
【００９２】
数式１および２を図８のアレーに適用した場合、結果は図９に示すとおりである。ここで、留意すべき点は、
（ａ）変換プロセスによりコラム数が半減する(数式はｒ＝０....９およびｃ＝０…４について解かれる)。
（ｂ）とはいえ、画像データ全体の量は同じままである（これは２セットの係数ＬおよびＨを持つためである）。
【００９３】
図９の結果は第１パスの「１次元的」水平変換を表している。図９の結果を数式５、６、９、および１０に適用すると、第２の「２次元的」垂直変換が完了する。結果全体は完全なハール変換であり、図１０のような形態である。ここで、どのようにして縦および横データが半分にされているか、しかしふたたびここでもデータ全体の量は同じままということに留意するべきである。
【００９４】
ハール変換がアレー全体に適用されることがわかるが、２／１０変換を使う状況は全く違ったものである。ハール変換は２×２画素ブロックで作用するが、２／１０はより数多くのデータ画素を必要とする。そして、実際のところ、例の場合、アレーの４つの中央の画素についてしか有効な結果を提供できない（すなわち、図８の値が８０、４８、４５、１１０の画素）。
【００９５】
ｃ＝４..５およびｒ＝２の範囲の数式１、３、および４を適用すると、ＬおよびＨについて２／１０値が得られる。その後、数式５、７、８、９、１１、および１２を解くと、ＬＬ、ＬＨ，ＨＬおよびＨＨについて２／１０値が導き出される。
【００９６】
図１１は、実施例の場合のこれらの解答を示している。左側にはＬおよびＨについての解答を示し、右側にはＬＬ、ＬＨ、ＨＬおよびＨＨについての解答を示している。図１１の右側の情報が、元の画素データを確実に回復可能とするのに転送されねばならない最小限のものである点に留意するべきである。
【００９７】
［逆方向変換］
ハールおよび２／１０変換は両方とも可逆であり、損失なしおよび損失ありの圧縮両方に適している。しかしながら、説明した形態の上述の数式を使う場合、「詳細」出力にはビット成長がある（ＬＬまたは「平滑」出力にはビット成長はない）。かかる理由により、好ましいシステムでは、出力変換データは上ですでに参照した「精度保存の特性」の原則を使って演算され、これにより損失なし性能を維持しつつもビット成長はなくなる。（このようにして適用される精度保存の特性（ＰＰＰ）はHongyang, FisherおよびZeyiによるものである）
【００９８】
変換数式に関して理解すべき重要な点は、これらがすべて整数ドメインで演算されるがそれでも損失なしの結果を生み出す点である。ここでの洞察はPearlmanによるものであり、またRicohのGormishらにもよるものである。
【００９９】
ウェーブレット変換を実行するために設定される数式は上ですでに提供済みである。ここではプロセスを逆転させ画素データを回復するための対応する数式がその後に引き続く。
【０１００】
図１０および図１１に示す変換結果が以下に続く数式（適切な範囲にわたって演算される）に供給されると、現れる画素データはまさに図８に示すとおりのものになるであろう。
【０１０１】
数式セット１３．ＬおよびＨを回復するための垂直逆転ハール変換
【０１０２】
【数１６】
2010022006.tif 000018
【０１０３】
数式セット１４．画素を回復するための水平逆転ハール変換
【０１０４】
【数１７】
2010022006.tif 000019
【０１０５】
数式セット１５．ＬおよびＨを回復するための垂直逆転２／１０変換
【０１０６】
【数１８】
2010022006.tif 000020
【０１０７】
数式セット１６．画素を回復するための水平逆転２／１０変換
【０１０８】
【数１９】
2010022006.tif 000021
【０１０９】
［変換エンジンの動作］
変換エンジンを実際に実現するにあたっての最も基本的かつ重要な点は、タスクを、それぞれ１つずつが完全に決定的な方法で動作する多数の簡素な工程にまで分解することである。解決すべきいくつかの問題点は次のとおりである。
（ａ）２／１０変換が必要とする「ブロック外」画素データを取り扱うこと（ハール変換に関しては、３２×３２ブロックはそれ自体で処理できるが、２／１０は、３２×３２変換を完成させるのにブロック全体および部分的なブロックからの画素からのデータを必要とする。）
（ｂ）変換エンジン成分には垂直データを取り扱っているのか水平データを取り扱っているのかが「分からなくても」よいようにタスクを簡素化すること。それぞれの素子はただ単に簡素な算術的タスクを実行するだけにとどまるべきである。
（ｃ）処理時間を短縮するための方策を見出すこと。５レベル２次元的変換処理には、続けざまにオペレーションを実行する必要性が内在しているため、単一フレーム分に相当する画素データを処理するのにかかる時間が複数となる。明らかに、１つのフレームを変換し符号化するプロセス全体がすべてもとのフレーム時間より短い時間内で実行できることが確実である必要がある。
【０１１０】
図１２は、符号化システムアーキテクチャ全体のブロック図であるが、ただしこのステージではアイテム１から７だけを説明することにする。ＹＵＶ変換処理はすでに上で説明済みである。符号器およびパケタイザを以下に説明する。適正な変換エンジン、これは実際には２つの変換エンジンおよび大型メモリからなるものであるが、における主なプロセスをここで説明する。
【０１１１】
１．画像データは変換エンジンの２つの画素に同時に入り、最初のタスクはレベル１水平変換である。これにより数式１、および数式２または数式４のいずれかに従ってＬおよびＨデータが生成される。Ｈ数式は、予測子を除いて同じであるため、ハール変換の場合であればｐをゼロに設定した状態で単一セットの数式を使うことが可能なことがわかる。図１３は、どのようにして典型的な画素ｎについてのデータが導き出されるかを示している。ｓ（ｎ）およびｄ（ｎ）の値を導き出すためのフィルタ数式を以下に示す。図１３は、どのようにして２／１０変換の場合の予測子ｐが導き出されるかを示している。変換エンジンそれ自体は座標には関与しないため数式はｓまたは「平滑な」成分、および／または「詳細」成分を示す簡素化された形態で表される。このステージでは、これらはＬおよびＨに対応する。
【０１１２】
【数２０】
2010022006.tif 000022
【０１１３】
２．図１２は８ビット色を想定しているため、変換エンジンへの入力は４８ビット幅で示されている（一度に２つの画素が読み取られる）。これが現れるときは、符号の追加により５４ビット幅になっている。「１８」から「３６」ボックスが４つの変換係数のデータを組み合わせることによってデータを１０８ビット幅に変換する。これはメモリをローディングするのにかかる時間を短縮するための策略であるため、後続の２次元変換に必要とされるメモリに対する複数のパスアクセスを行うための時間がかせげる。
【０１１４】
３．２つの変換エンジン１、５が大型ＤＤＲ（二重データ速度）メモリ３によって供給される。メモリ３の入力および出力には多重スイッチ（ＭＵＸ）が備わっている。入力側のスイッチは２つの変換エンジンの出力からのデータのいずれかを選択し、出力側のスイッチは第２の変換エンジンまたはコーダのいずれかにデータを送信する。メモリ３はデータの２つの画像フレームの等価物を含むのに十分な大きさである。連続的な奇数番号のフレームからの変換データはメモリ３の第１のセクションに保存され、偶数番号のフレームからの変換データは第２のセクションに保存される。
【０１１５】
４．第１の変換の出力からのデータは３２×３２フォーマットでメモリ３から読み出される。後続のレベルの変換を実行するにはデータが第２の変換エンジンを通る複数のパスを経ることが必要である。エンジン自体が「ダム」となることができそれが横列のデータを処理しているのか縦列のデータを処理しているのかには無関係であるために、変換エンジンの外部には横列および縦列の制御が設けられている。変換エンジンに到着する前に、データは５４ビット幅に並び戻される。
【０１１６】
５．外部の横列および縦列制御を使うという概念は、第２の変換エンジン（５）を第１の変換エンジンと同一にするというものである。これ自身は単一次元でのみ機能するが、横列および縦列データを連続して取り扱うことで２次元的変換を生み出す。５レベル変換を生み出すには、ＹＵＶブロックデータは変換エンジンを通る複数のパスを持っていなければならない。これがフレーム時間内で可能な理由は、レベル１変換が時間の大部分を占める（約７５％）ためである。後続のレベルは、複数のパスを必要とするものの、実際にはあまり時間をとることはない、なぜなら係数の数がずっと少ないからである（図６を参照のこと）。２／１０変換を実行するには、再循環されたデータは「ブロック外」係数を含んでいなければならない点に留意する。
【０１１７】
６．第２変換エンジンの出力はメモリに戻される前に１０８ビット幅に並び戻される。図１４は、メモリ内における連続的な書き換えの概念を示している。左側はレベル１変換の結果であり、レベル２変換が完了すると、レベル１データのＬＬ部分だけがレベル２データで上書きされる。この図面から、なぜ再循環されたデータの量がそれぞれのレベルの変換が完了するごとに少なくなるのなのかが明らかである。いったんレベル１の２次元的変換が完了すると、係数は図面の左側に従って保存される。その後、ＬＬ係数がレベル２についての新しいセットの係数によって上書きされる。これらは右側に描かれるようにメモリ内でまさに同じ空間を占める。このプロセスがレベル５まで繰り返される。
【０１１８】
７．完成されたＹＵＶブロック変換データはＭＵＸによって符号器セクションに解放される。
【０１１９】
次の点に留意することが重要である。まず第１には、元のＹＵＶデータがＲＧＢオリジナルに関して本質的に損失のないものであることを確認し、このデータすべてが変換プロセスへと進むことを確認する点。このことは専門的なビデオ用語ですべての処理が「４：４：４」である、と言うのに等しく、「縁部」での色漏れが絶対にないようにするものである。そして、第２には、変換ステージではブロック間で２／１０係数を保存する概念によりフレームベースの変換の数多くの等価物が実現される点。これにより、最終的に得られる結果はブロックのない画像忠実度である。しかしながら、すべての変換管理およびすべてのその後のコード化はブロックドメイン内で行われる。このことは効率的かつ決定的な動作を得るにあたって鍵である。
【０１２０】
［得られたデータの符号化］
上で述べたように、変換の当初の効果はデータの量を少なくすることではなく、圧縮をより効率的にするような形態でデータを提示することにすぎない。
【０１２１】
データ圧縮は標準的な数学的方法（用途によって全く左右される）を使って行えるが、下層データの性質を利用するとよりよい結果を得ることができる。ウェーブレット変換データは、データが「ツリー」構造に組織されている場合、効率的な損失のない圧縮および損失のある圧縮に非常に向いている。
【０１２２】
「ツリー」の使用の背後にある基本的な概念は、画像内の隣接し合う画素が似る傾向にあることである。変換ドメイン内では、このことは別のやり方で表わされる。分解のより高いサブ帯域におけるウェーブレット係数の大きさが特定のしきい値に対してあまり重要でない場合、同じ空間的位置を持つがより低いサブ帯域に関連しているウェーブレット係数もまたあまり重要ではない見込みがある。さらに、ウェーブレット「ピラミッド」のもっとも高いレベルからもっとも低いレベルへと進む場合、ウェーブレット係数の変動は小さくなる。このことにより、数多くの重要でないウェーブレット係数のコード化を非常に効率的に行えるという概念に結び付く。
【０１２３】
公知の方法としては、空間オリエンテーションツリーまたはＳＯＴ（Shapiro）、およびヒエラルキーツリーにおけるパーティションニングセットＳＰＩＨＴ（Pearlman）が挙げられる。これら方法の両方が抱える問題点は、１回より多くデータを訪問する必要があることである。好ましい方法はまた、「４分ツリー」形態のツリー原則も使用するが、データを一回だけ訪問するだけでよいやり方でこれを使用する。これにより、正確に定義されたサイクルでタスクを実行するリアルタイムの単一パス圧縮エンジンの生成が可能となる。
【０１２４】
システムの目的は、２つの異なるタイプの情報をコード化することである。１つの情報は「制御」またはコード化情報であり、他方は「データ」である。コード化情報はデータに先駆けて送信されるため、復号化システムはその後に続くデータをどのように取り扱うかを前もって知る。基本的な符号化システムは損失なしであるが、正確に定義されたレベルの損失あり圧縮に非常に向いている。
【０１２５】
［ＬＫＣＳ符号化］
個々の画像に関するデータは３２×３２ウェーブレット係数のブロックに分割される。そしてこのブロックデータは９つの面、すなわち８つのデータ面と１つの符号面に分離される。そしてそれぞれの面は、図１９に示し以下により詳細に説明するように１６ビットの６４列に並べ替えられる。
【０１２６】
図１５は、どのようにしてこのような１つの列が「ＣＫＬ−ツリー」に符号化されるかを示している。話を簡素化するために１６個の係数のデータビットを一列に示しているが、これらは実際には２次元的アレーについて言及していることを心に留めておかねばならない。これら１６個の係数は４つのセットに分割され、それぞれのセットが「Ｋ型ツリー」に接続される。セット内のすべての係数がゼロであれば、対応するＫ型もまたゼロであり、Ｋ型を保持するだけでよい。もしセットがゼロでなければ、元の係数およびＫ型を保持する必要がある。（ブール項では、Ｋツリーは４つの入力を持つＯＲゲートである。出力が０であれば、Ｋ＝０の情報だけが保持される。出力が１であれば、Ｋ＝１の情報および４つの個々のデータビットを保持しなければならない。）
【０１２７】
４つのＫ型もまた１つのセットを形成しており、同じ確率法則に従うため、ツリー概念を繰り返すことが可能である。Ｋ型セットはツリーをＬ型に形成する。従って、Ｋ型セットがゼロであれば、Ｌ型だけを保持する必要がある。
【０１２８】
次のステップは、ここのビット面内でＬ型ツリーを符号化することである。それぞれのＬ型は６４横列ブロック内の横列を表しており、これは６４Ｌ型のＬツリー構造に完全に合う。図１６は、これがどのようにして起こるかを示しており、またＬ型がどのように元に変換データ（ＨＬ、ＬＨおよびＨＨ）に関連するかも示している。図面は、レベル１および２における２０個のＬ型、およびレベル３、４、および５における４つの最終的なＬ型を示している。これらはまた図面に示すようにレベル１および２におけるＬＨおよびＨＨそれぞれについての２０個のＬ型でもある。
【０１２９】
Ｌツリーはやはり類似の可能性を利用する。符号化はツリーの底部（レベル１）からレベル４／５へと行われる。ヒエラルキー用語で、レベル４／５は「親」とみなすことができ、レベル３，２および１はそれに対して「子」の関係を持つ。符号化手順は上と同じである。
【０１３０】
符号化「ノード」の正確な動作を図１６に示す。プロセスはＬ２＿０と印が付けられているノードを考慮することによって図示できる。ここで、ブール演算は入力が５つのＯＲゲートのものであり、入力のうち４つがＬ１＿０からＬ１＿３データであり、５番目の入力がＬ２＿０データである。上で述べたように、ゲートの出力が１であれば、Ｌ型および前のデータを保持しなければならないが、もし０であれば、Ｌ型だけを保持する。そしてレベル３ノードからレベル４／５までプロセスを繰り返す。
【０１３１】
ゼロ係数がある広い領域があると、非常に大型の符号化ゲインが実現されることがわかる。そして極端な場合、１つのビット面にあるすべての係数がゼロであれば、レベル４／５だけが保持される。
【０１３２】
ここで、コード化プロセスによりデータを大幅に縮小できるが、ＬおよびＫ値を保持しなければならない付帯部分があることがわかる。ＬおよびＫビット自体は元のデータに対する付け加えである、すなわち、ツリープロセスが元のデータを縮小する一方で、制御データの追加もできる。コード化ゲインのいくらかは失われるため、この損失を最小限にすることが望ましい。このことは、８つのデータ面のすべての概要を把握することによって行われる。図１７は面の概念を示しており、面７が最上位であり面０が最下位である。ウェーブレット変換のおかげで、面７はゼロのほとんどを含んでいるため、この面では係数のほとんどがゼロであろうにもかかわらずＫおよびＬ構造がコード化ゲインの意味で最も効率的となっている。
【０１３３】
ＫおよびＬ型を見て調べるやり方の１つは、これらが面における係数の有意性の記録を提供することである。この記録は１つの面から他の面へと手渡され、対応するＫまたはＬ型がいつ有意になったか（すなわち１に等しくなったか）を判断するのに使用できる。いったんこれが検出されると、もはや後続の面のために型を保存する必要はない（なぜならデータはいずれにしろ保持されているからである）。この手順は冗長なＬ型およびＫ型を排除するものである。
【０１３４】
連続的な面を走査するプロセスも使って符号面（面８）をコード化する。変換プロセスでは８ビット画素データが９ビットとなるが、これは±２５５の範囲を示している。符号面では、１０２４個の係数が０によって正に指定されており、１によって負に指定されている。符号データは有意性に基づいてコード化されているため、（冗長なＫおよびＬ型を排除するために）有意性の走査が行われると、有意な係数だけが符号化された符号データを持つ（なぜなら、明らかに、すでに廃棄されているゼロ係数に符号データをコード化することは冗長と思われるからである）。
【０１３５】
今や全体の符号化プロセスはＬＫＣＳデータの生成として要約でき、この場合、それぞれの面は一連の４つのセクションでコード化される。ここで、
Ｌ＝Ｌ型ツリー
Ｋ＝Ｋ型ツリー
Ｃ＝係数データ
Ｓ＝符号
である。
【０１３６】
損失のない符号化を行うには、「最悪の場合」、すなわち、元の画像が非常に複雑であるため実際にはコード化ゲインがない場合について符号化データを計画する必要がある。従って、プロセスは次のとおりである。
（ａ）Ｌツリーは６４個までのビットデータによってコード化され、Ｌ型に対応する。これら自体はＫ型の知識から導き出されるが、このセクションがビットストリームの最初でなければならない。これは、復号器はどの横列が送信されておりどの横列が送信されていないか（有意でないか）を前もって知る必要があるからである。Ｌ型ビットは、圧縮プロファイル（以下を参照のこと）とともに、復号器にＬ型ツリーを再構築させる。
（ｂ）次に、Ｋ型が２５６個のＫ型に対応する２５６個までのビットデータによってコード化される。復号器は再構築されたＬツリーを使ってＫ型のマップを復号化する。
（ｃ）次に、もとの係数データＣが１０２４個までのビットによってコード化される。復号器は再構築されたＬおよびＫ型を使ってＣデータのマップを復号化する。
（ｄ）最後に、符号データＳが１０２４個までのビットデータによってコード化される。復号器を使ってＣデータを再構築してＳデータのマップを復号化する。
【０１３７】
８つの画像面のそれぞれについてＬＫＣＳプロセス全体が繰り返される。
【０１３８】
［空間的圧縮のための符号化］
明らかに、上述のプロセスがいったん完了すると、実際の符号化されたデータの長さが可変であるという状況が生じる。符号化損失があるという状況さえもあるということは統計学的にはあり得ない（不可能でさえある）ものの、損失なしのコード化により可変の結果がもたらされ、かかる結果は、意図するリアルタイム用途で管理するのは困難と思われる場合がそうである。
【０１３９】
ビット速度の意味で、より予測可能な結果を実現しまた高いコード化ゲインを持つ損失のない圧縮を導くために、ＬＫＣＳデータは圧縮プロファイルを受ける。原則として、これは解像度およびビット面数に基づくデータの除去にすぎない。このプロファイルはヘッダとしてビットストリームに送付され、その結果、復号器はどれが削除されたかを前もって知る。
【０１４０】
連続的なプロファイルの傾向は、ほとんどの積極的な削除を面０およびレベル１に適用し、レベルおよび面の上昇につれて削除を累進的に少なくするというものである。実際には、圧縮プロファイルはＣＫおよびＬツリーのコード化のときに適用されるもので、このことは望ましくない係数データおよび対応するＫおよびＬ型のいずれも削除することを意味する。このことは重要である、なぜならこれにより元のデータおよび圧縮されつつある制御情報の両方が得られるからである、さもなければ高い圧縮レベルでは制御情報が優勢になるという状況が生じたであろう。
【０１４１】
［圧縮プロファイル］
圧縮プロファイルは、人間の目の視覚的知覚特徴を活用する重み付け方法を使用する。原則として、人間の目は高周波数の損失にはあまり敏感ではないため、どのような圧縮体系でも、高周波数成分を排除することによってまた量子化ノイズの効果も確実にやはり排除することによって始まる。
【０１４２】
重み付け体系はウェーブレット変換のサブ帯域レベルに合わされており、その概念を図１８に示す（図６と比較すべきものである）。これを言い換えると、圧縮は元のデータではなくＬツリーに適用される。
【０１４３】
図１８で、簡単な（そして典型的な）例として「ａ」をａ＝２とする。すると、いずれのレベルのＨＨも対応するＬＨおよびＨＬの圧縮の２倍を持つことがわかる。さらに、累進的により小さい圧縮を、より重要な情報が存在しているより高いレベルに適用する。
【０１４４】
好ましい重み付け方法は、「ａ」の値を変動させて広い範囲の圧縮比を得ることである。図１８は、適用される相対的な重みを運搬する点で概念的であるが、実際には、圧縮の範囲は符号器で適用される１セットの個々のプロファイルの形態である。ユーザーは所定のプロファイルのうちの１つを選択できるかまたはカスタムプロファイルを定義さえもできる。
【０１４５】
プロファイルを定義するにあたりその目的は、再構築された画像が最小限の間違いしか持たず、同時に最も高い知覚品質を持つ（すなわち、画像が見る者によって「自然だ」と知覚される）ことを確実にすることである。このことにより必然的にいくつかの妥協が生じ、実際には、知覚的品質はより低いビット速度でより重要である。
【０１４６】
重み付け体系は簡素で、効率的で、実際の画像には左右されない。この体系は、Ｌ型ツリーの１つのビット面に直接関連する１６ビットプロファイルパラメータによって成し遂げられる。このことを表１に示す。もしある１つのビットが０であれば、データは取り除かれ、そのビットが１に等しければ、データは保持される。プロセスは「Ｌツリーの伐採」と記述でき、Ｌ型の単数または複数のビットを使う論理ＡＮＤ演算によって実行される。
【０１４７】
例えば、ビット１０＝０であれば、Ｌ＿ＬＨ２の４つすべてのビットはゼロとされるであろうが、もしビット１０＝１であれば、Ｌ＿ＬＨ２のうち値が１のビットだけが保持されるであろう。
【０１４８】
「スペアビット」の存在を説明する必要がある。元の構造では、Ｌ＿４／５の個々の成分のために空間が見込まれていた。実際には、これはすべての通常の画像にとって冗長であるが、万が一、後の開発（おそらく非常に大型の画像をともなう）でこれら余分のビットが必要とされる場合に備えて機能が保持されている。チップ設計はこれらを使用するための機能を保持しているが、体系が冗長なデータを送信することはない。
【０１４９】
Ｌ型ツリーの制御により非常に効率的な圧縮を行うことができる、なぜならより多くのゼロが形成される場合、データおよび制御の両方ともプロファイルパラメータによって取り除かれるからである。
【０１５０】
［プロファイルの例］
表２および表３は、圧縮プロファイルの例を示している。表２は、視覚的に損失のない画像を提供する圧縮プロファイルの実際の例である。１または０に設定されるビットを検討することにより、プロファイルの重み付けの概念を得ることが可能であり、有意な面およびレベルには圧縮がかけられていないことが直ちに明らかである。かかるプロファイルは２０：１から３０：１の範囲の空間的圧縮を提供できる。
【０１５１】
表３は、範囲が５０：１から１００：１の激しい圧縮の一例であり、より多くのデータが廃棄されていることが明白である。すべての面についてＬ４／５データが保持されており、これは、かかるデータのどのような損失も画像品質に重大な影響を及ぼすと思われるからであるが、かたやビット速度には限界的な削減しか行われていない点に留意する必要がある。
【０１５２】
プロファイルを定義する場合、特定の解像度レベルに関するすべてのデータが確実にビット面内で除去されるようなやり方でデータの除去を行うことが重要である。なぜなら、さもなければ得られる画像は不均一的な空間品質を持つことになると思われるからである。目はかかる潜在的な人工物に敏感である、例えば、人間の顔面を見ている場合、目は均一な品質を期待しているが、もし顔面の異なる部分が異なる品質を持っていればとまどう。
【０１５３】
［符号化エンジン］
これまで行ってきた符号化プロセスの説明では数多くの離散プロセスを説明してきた。図１２および図１３には、ウェーブレット変換を実行するための「変換エンジン」の概念をいくらか詳細に示した。しかしながら、図１２では、コード化プロセスがただ単にブロック図内の機能として示されていたにすぎず、符号器がどのように作動するかについての詳細はまったくなかった。
【０１５４】
［変換データの並べ替え］
変換プロセスの結果は３２×３２ブロックの画像係数であり（３セットのかかるブロック、すなわちＹ、Ｕ、およびＶがある）、ブロック内で、レベル５データから始めに係数データが整列され、レベル１データで終わる。
【０１５５】
それぞれのビット面について、データが、最初にそれぞれが１６ビットの６４横列並び替えられる、なぜならこうするとＬツリーを簡単に導き出すことができるからである。係数データに対する組織およびその関係は以下の図面ではっきりとわかる。
【０１５６】
［Ｌ−符号器］
上で述べたように、Ｌツリーがまず最初に導き出される、なぜならＬツリーはまず最初に復号化プロセスに必要でありまた最も多い量の係数データの廃棄ももたらすからである。「Ｌツリーコード化エンジン」のタスクは非常に複雑である、なぜならこれは３次元で作動しなければならないからである。
（ａ）論理ＡＮＤ演算をデータに行って所望の圧縮プロファイルをかけるようにしなければならない。
（ｂ）Ｌタイプの引き出し自体は非常に簡素である、なぜならこれはデータの単一の横列に対する論理ＯＲ演算であり、横列６３から横列０まで作用するものである。
（ｃ）もし係数データが有意であることがすでにわかっているのであれば、Ｌ型を指定することは冗長であるため、プロセスは最上位の面の下流で作用しなければならない。
（ｄ）所望の最終結果はすべての有意でない係数データの廃棄、および残りの係数データの保持、およびすべてのＬ型の位置のコンパクトな記述である。
（ｅ）エンジンは、データを「再訪問」してはならないという点で、単一のパスをベースとして機能しなければならない。
【０１５７】
図２０は、プロセスをブロック図の形態で示している。Ｌ  ＦＯＲＭＡＴは１つの面の６４×１６係数ビットから６４個のＬを構築している。
【０１５８】
Ｌ  ＴＲＥＥは８つの面を生成する。すなわち、最上位の面７から最下位の面０まで機能するＬ＿ＣＵＲ［６３..０］、Ｌ＿ＭＳＫ［６３..０］およびＬ＿ＳＩＧ［３..０］である。圧縮ファイルがこのステージでどのように適用されるかに留意すること。これらのアイテムはＬ符号器の「出力」を表している。ここで、
Ｌ＿ＣＵＲ［６３..０］は現在の面のＬツリー状態である。
【０１５９】
Ｌ＿ＭＳＫ［６３..０］は、どのＬ＿ＣＵＲビットを送信すべきでないかを決定するマスクである。
【０１６０】
Ｌ＿ＳＩＧ［３..０］はＬ  ＳＩＧＮＩＦＩＣＡＮＣＥであり、Ｋ、ＣおよびＳパスによって使用されるもので、どの横列を送信すべきでないかを示している。
【０１６１】
Ｌ  ＡＣＣはＬ＿ＡＣＣ［６３..０］を生成する。これはすべての以前の面の現在のＯＲ化された状態の記録である。
【０１６２】
Ｌ符号器で使用される数式は次のとおりである。
【０１６３】
［Ｌ＿ＣＵＲおよびＬ＿ＳＤＩＧの定義］              ［圧縮プロファイル］
【０１６４】
【数２１】
2010022006.tif 000023
【０１６５】
［Ｌ＿ＣＵＲ［６３..０］ＵＰ  Ｌツリーを算出するための論理数式］
数式                                                        コメント
【０１６６】
【数２２】
2010022006.tif 000024
【０１６７】
Ｌ＿ｃｕｒ［ｎ］は１つの面についてのみ有意である（有意への遷移）。有意になる点を超えるとＬコード化は停止する点に留意すること。
【０１６８】
［Ｌ＿ＳＩＧを算出するための論理数式］
Ｌ＿ＳＩＧはＫ、ＣおよびＳパスによって使用されるもので、どの横列を送信しないかを示している。Ｌｎ＿ＸＸ＿ｓｉｇ＝０の場合、横列は送信されない。Ｌｓｉｇ［３..０］は４つの横列をマップする、すなわち、１６サイクルＫ、ＣおよびＳパスを処理するための１６セットのシーケンスがあり、ここでｓｅｌ［０］からｓｅｌ［１５］がそのシーケンスを選択する。
【０１６９】
【数２３】
2010022006.tif 000025
【０１７０】
Ｌ＿ｓｉｇ［３..０］は４つの有意値をそれぞれの（４＊１６）Ｋ、Ｃ、Ｓ言語に手渡す。それぞれのタイプ（Ｋ、Ｃ、Ｓ）について１６の３つのパスがある。
【０１７１】
【数２４】
2010022006.tif 000026
【０１７２】
［Ｌ＿ＭＳＫを算出するための論理数式］
これを使ってＬ＿ｃｕｒ［６３..０］のどのＬビットを送信しないかを決定する。Ｌビットは、その親が０である場合またはそのＣ＿ｐｒｏｆ［］が０の場合は送信されない。これは下降（上から下向き）ツリーを組み込んでいる。それぞれのパスは平面であり、最上位から最下位へと実行される（面７から面０）。
【０１７３】
コメント
【０１７４】
【数２５】
2010022006.tif 000027
【０１７５】
［ＣＳ符号器］
図２１はＣＳ符号器を示している。この内部では、次のことが行われる。
【０１７６】
ＣＳ  ＦＯＲＭＡＴが元の１６ビット横列フォーマット［１５..０］をａ×４横列フォーマット、すなわち［６３..０］に変換する。これを行うことでデータを６４ビットに合致させ、その結果、符号化エンジンの最終的な部分が６４ビットベースでのみ機能できるようになる。
【０１７７】
すべての係数面について符号データが平行して複写される。これは、すべてのＣ面について符号が利用可能である必要がある次のステージにとって必要である。
【０１７８】
Ｃ  ＡＣＣはそれぞれの係数が有意となった点を記録するもので、符号をいつ符号化すべきかを決定するのに次のステージで使用される。
【０１７９】
［ＬＫＣＳパス］
図２２は符号化エンジン全体を示している。ここで、Ｌ  ＥＮＣＯＤＥおよびＣＳ  ＥＮＣＯＤＥはすでに上で説明したプロセスである。
【０１８０】
ＭＸ  ＬＤＰＳは符号化エンジンである。その所望の出力は、ＭＸ＿ＣＵＲ［６３..０］およびＭＸ＿ＭＳＫ［６３..０］からなる。図２２に示されるその他の出力は中間データで、出力を算出するのに使用されるものであり以下に示す数式に現れる。
【０１８１】
リアルタイム符号化エンジンは６４サイクルベースで機能するため、最大値にあるＬ、Ｋ、ＣおよびＳのそれぞれの理論上の最悪のケースが実際に「合う」ことが確実なことが重要である。このことは、次のことがらを理解することで試験される。
【０１８２】
Ｌ＿ＰＡＳＳ＝面あたり１×Ｌ＿ＣＵＲ［６３..０］
Ｋ＿ＰＡＳＳ＝面あたり１６×Ｋ＿ＣＵＲ［１５..０］
Ｃ＿ＰＡＳＳ＝面あたり１６×Ｃ＿ＣＵＲ［６３..０］
Ｓ＿ＰＡＳＳ＝面あたり１６×Ｓ＿ＣＵＲ［６３..０］
従って、ＭＸ＿ＣＵＲおよびＭＸ＿ＭＳＫを生成するには、Ｌ、Ｋ、ＣおよびＳパスのすべてのシーケンスが必要である、すなわち、
１＋１６＋１６＋１６＝面あたり４９サイクル
これは十分に６４サイクルの許容範囲内である。
【０１８３】
出力ＭＸ＿ＭＳＫ［６３..０］はＬ、Ｋ、ＣおよびＳ＿ＣＵＲ［］のそれぞれのどのビットを符号化すべきかを選択するためのマスクである。
【０１８４】
ＬＫＣＳパスで使用される数式はここで次のとおりである。
【０１８５】
［Ｃ累算からのＫ累算の導出］
【０１８６】
【数２６】
2010022006.tif 000028
【０１８７】
［Ｃ＿ｃｕｒからのＫ型の累算］
【０１８８】
【数２７】
2010022006.tif 000029
【０１８９】
［Ｋパス］
Ｋ＿ｃｕｒの導出（Ｋ＿パスおよびＣ＿パスの両方に必要である）
【０１９０】
【数２８】
2010022006.tif 000030
【０１９１】
［Ｋ＿パスマスクの作成］
【０１９２】
【数２９】
2010022006.tif 000031
【０１９３】
［Ｃパス］
Ｃ＿ｃｕｒの導出
【０１９４】
【数３０】
2010022006.tif 000032
【０１９５】
［Ｃ＿パスマスクの準備および作成］
【０１９６】
【数３１】
2010022006.tif 000033
【０１９７】
［Ｓパス］
【０１９８】
【数３２】
2010022006.tif 000034
【０１９９】
［ＭＸ  ＬＫＣＳ］
【０２００】
【数３３】
2010022006.tif 000035
【０２０１】
［復号化エンジン］
復号化エンジンは、符号化フォーマットを鏡写しにすることによって「１つのパス」符号化解答を提供する１セットの決定的原則に基づいている。このフォーマットは、先駆けて知っておくべき後続のデータのための１セットのポインタを見込んだ累進的な計算を規定している。従属的なフィードバック素子を含むパイプライン化された論理構造では、将来のデータの位置を前もって知ることは必須要件である、さもなければ遅延（パイプライン）によりリアルタイムでない復号器となる。
【０２０２】
符号器と同様に、復号器は面あたり６４ビット×６４サイクルベースで機能する。復号器は埋め込まれた制御およびデータをそれが符号化された順序と同じ順序、すなわちＬＫＣＳで累進的に復号する。
【０２０３】
［Ｌ復号器］
Ｌ制御ビット［６３..０］の復号は２つのパスで行われる。
【０２０４】
Ｌパス１＝レベル４、３，２＝Ｌ［１５..０］
Ｌパス２＝レベル１＝Ｌ［６３..１６］
Ｌパス１は、どの面についてもシリアルデータｄ［１５..０］の最初の１６ビットで機能する。次の入力、
L_acc[15..0]
C_prof[15..0] 
と一緒になって、次の８つの面を生成する、すなわち、
L_cur[15..0]
L4_sig
L3_LH_sig
L3_HL_sig
L3_HH_sig
L2_LH_sig[3..0]
L2_HL_sig[3..0]
L2_HH_sig[3..0]
これらパラメータの定義は符号化エンジンにおいて定義される。
【０２０５】
［Ｌ＿パス１数式］
Ｌデータのためのポインタ
【０２０６】
【数３４】
2010022006.tif 000036
【０２０７】
［Ｌデータ］
レベル４および３のためのＬ＿ｃｕｒ［３..０］
【０２０８】
【数３５】
2010022006.tif 000037
【０２０９】
レベル２  Ｌデータの位置範囲（［１５..４］）
【０２１０】
【数３６】
2010022006.tif 000038
【０２１１】
レベル２のためのＬ＿ｃｕｒ［１５..４］
【０２１２】
【数３７】
2010022006.tif 000039
【０２１３】
【数３８】
2010022006.tif 000040
【０２１４】
【数３９】
2010022006.tif 000041
【０２１５】
【数４０】
2010022006.tif 000042
【０２１６】
Ｌ＿パス２は、Ｌ＿パスのデータの最後からあらかじめ指定されているデータｄ［６３..１６］の範囲で機能する。次の入力、
L_acc[63..16]
L2_LH_sig[3..0]
L2_HL_sig[3..0]
L2_HH_sig[3..0]
C_prof[15..0]
とともに、次の８つの面を生成する、すなわち、
L_cur[63..16]
L_acc[63..16]
L1_LH_sig[15..0]
L1_HL_sig[15..0]
L1_HH_sig[15..0]
これらのパラメータは符号化エンジンにおいて定義される。
【０２１７】
【数４１】
2010022006.tif 000043
【０２１８】
［Ｋ復号器］
Ｋ＿パスは、Ｌ＿パス２のデータの最後からあらかじめ指定されているデータの範囲で機能する。次の入力、
16 x d[15..0]
16 x C_acc[63..0]
16 x L_sig[3..0]
但し、Ｌ＿ｓｉｇ［３．０］は、（パラメータ）から（パラメータ）への順次的な四重マッピングである。
とともに、
面あたり１６×Ｋ＿ｃｕｒ［１５..０］
面あたり１６×Ｋ＿ｍｓｋ［１５..０］
を生成する。
【０２１９】
［Ｃ累算からのＫ累算］
【０２２０】
【数４２】
2010022006.tif 000044
【０２２１】
［Ｃ復号器］
Ｃ＿パスは、Ｌ＿パスのデータの最後からあらかじめ指定されているデータの範囲で機能する。次の入力、
16 x d[63..0]
16 x C_acc[63..0]
16 x K_msk[15..0]
16 x L_sig[3..0]
とともに、
面あたり１６×Ｃ＿ｃｕｒ［６３..０］
面あたり１６×Ｓ＿ｍｓｋ［６３..０］
を生成する。
【０２２２】
【数４３】
2010022006.tif 000045
【０２２３】
［Ｓ復号器］
Ｓ＿パスは、Ｃ＿パスのデータの最後からあらかじめ指定されているデータの範囲で機能する。次の入力、
16 x d[63..0]
16 x S_msk[63..0]
とともに、
16 x S_cur[63..0]     per plane
S_cur[63..0] = (d[63..0] & S_msk[63..0]) & S_pass_en ;
を生成する。
【０２２４】
［一時的な圧縮のための符号化］
一時的な圧縮は、高い圧縮比を実現するための鍵である。しかしながら、方法によっては計算上集約的なものがあり、処理時間が画像内容に大きく左右される。好ましい体系では、次の２つの優先度に対応している。
（ａ）どのような方法を使おうとも、変換の決定性およびコード化エンジンを保持しなければならない。このようにすると、プロセス全体が簡素化され、内容を符号化するのにかかる時間が正確に定義される。
（ｂ）ストリーム化すべきデータは「絶対的」でなければならない。言い換えると、画像は受け取ったデータだけを使って再構築され、画像の履歴または将来の予測には依存しない。絶対的なデータの概念によりネットワークエラーに対する高い免疫が提供され、特に、画像待ち時間を延長することがない。（延長された画像待ち時間、すなわち、符号化および復号化の間における複数のフレーム遅延は画像のグループ全体にわたって複雑な計算を必要とするシステムではどのようなものにおいても不可避である。）
【０２２５】
好ましい一時的圧縮体系の基礎は、変更のあった映像情報だけをコード化することである。この体系は、映像内容の領域は、その体系が検出しコード化しないいくつかのフレームにわたって静止したままにできるという事実を活用する。このようにすると、大きなコード化ゲインが実現される。この体系が実行可能なものとなるには、変更を正確かつ確実に検出することは最も重要な点である、なぜなら変更をどのように誤って検出しても明らかなエラーにつながり、これは復号化された画像の「凍結した」領域としてはっきりと示されるものである。
【０２２６】
動きを確実に検出することは体系の核心である。しかしながら、絶対的データの送信の基づいた体系を考案することは、変化の間の違いを送信することだけに頼る体系（例えば、ＭＰＥＧを使って行われているように）を使うことに比べるとはるかに困難である。画像にノイズがあるため困難が生じるため、その結果、真の映像内容とノイズとを区別する問題がある。ノイズは２つの主な理由により生じる。すなわち、カメラセンサノイズ（特に、証明レベルの低い場面）およびアナログからデジタル信号変換から生じる量子化ノイズである。
【０２２７】
ノイズと画像内容とを区別する好ましい方法の基礎は、ウェーブレットドメインにおいて、すなわち、コード化の前に、変換出力において動き検出を処理することである。ウェーブレットドメインにおける「脱ノイズ」は、ウェーブレット変換は信号ドメインにおけるノイズを変換におけるノイズにマップするということに気づいた人物であるＤｏｎｏｈｏによって最初に提案された概念に基づいている。
【０２２８】
どのような所定の画像でも、信号エネルギーは変換ドメインの係数にはほとんど集中しないが、ノイズエネルギーはそうではない。ノイズから信号の分離を可能とするのはこの重要な原則であり、ウェーブレット係数を「しきい値処理」することによって実現される。ノイズは有意の係数よりもレベルが非常に低いため、インテリジェントな低レベルしきい値処理を適用することで、ノイズと思われる低レベルの係数だけを取り除くことができる。しきい値処理は、最適なノイズ抑制を実現するために変換レベル全体にわたって動的である。好ましい体系は新規である、なぜなら信号は非線形手段によってノイズから分離されるからである。そしていくつかのやり方においては、プロセスは、上で説明した圧縮プロファイルに使用され適用される方法に類似である。
【０２２９】
好ましい一時的な圧縮体系では、最上位の係数の貧弱なセットだけをノイズ除去のための基礎として使用する。かかる積極的なやり方は、動きを検出するための非常にきれいな「ウェーブレット署名」を得るように設計されている。この「署名」は認識可能な映像に似る必要はなく、ただ単に有効な変更検出の手段であればよい。
【０２３０】
［一時的な圧縮の定義］
一時的な圧縮アルゴリズムの目的は、必要な計算を最小限とすることである。好ましいシステムでは、当初の色空間変換の性質を利用する。
【０２３１】
動きを定義するための境界は、３２×３２係数のＹＵＶ変換されたブロックである。それぞれのブロックは画像フレーム内で自身の位置を定義するようなやり方で番号付けされている。フレーム間で対応し合うブロックを比較し、これらが異なる場合だけ、コード化し送信される。Ｙ自体はＵおよびＶから導き出されると考えることができるため、動きを査定するにはＹ係数だけを使えば十分である。このことは動きの計算およびフレーム保存の要件を、もし計算がＹＵＶ（またはＲＧＢ）画像全部について行われた場合に比べたった３分の１にまで少なくする効果がある。
【０２３２】
一時的な符号化のプロセスを図１９に図示しており、これはプロセスにおける次のステップを示している。
【０２３３】
１．Ｙ変換情報を３２×３２ブロックで抽出する。それぞれのブロックについて位置情報を割り当てる。
【０２３４】
２．ノイズしきい値をデータに適用する。これによりプログラムされた値未満のすべての係数を排除する。この「しきい値」は非常に低く、ノイズレベルにある有意でない係数を排除することだけを目的としている。
【０２３５】
３．最上位の係数の大きさおよび位置を検出する。このプロセスでは、５レベル変換を形成している１６個のサブ帯域をそれぞれろ過して最上位の係数およびその関連する位置を選択する。
【０２３６】
４．１６個の得られた係数から、最上位なものを選択する。選択される個数はプログラム可能で、実際には最大８つで十分であることがわかっている。この体系の背後にある概念は、信頼性のある動き検出を保証するのに十分な情報を得るが、それと同時に、最上位の係数のグループの大きさに上限を設けることにより最大のノイズ免疫を実現するというものである。有意な係数および対応する位置データを要約するこの情報は「ウェーブレット署名」と呼ばれる。
【０２３７】
５．得られた「署名」を以前の画像フレーム内の対応するブロックのものと比較する。このステージでは、別のプログラム可能なしきい値が適用される。この「異なるしきい値」によりある一定の比較が可能となり得るが、この比較が正しいと思われるかどうかはまだ定かでない。このしきい値は、係数間の小さなピーク変調差を見込んでおり、大きさ情報だけに適用され、位置情報には適用されない。
【０２３８】
６．比較の結果、もし署名が同じであれば送信はない。もし署名が異なれば、コード化のためのデータ送信がある点に留意すること。コード化のために前進するデータは下のＹＵＶ変換データである。これは重要な原則である、なぜならこれにより（圧縮プロファイルの制約内で）最も高いと思われる画像品質が保持されること、およびコード化／復号化プロセスが静止している画像データと移動している画像データとを区別しなくてよいことが保証されるからである。
【０２３９】
［参照フレームデータ］
一時的な圧縮体系はまた、（単数または複数の）復号器を符合器の現状に同期させるための参照フレームデータを出力するためにも組織される。このプロセスは「背景」画像リフレッシュ機能を提供するものと考えられる。
【０２４０】
この機能は、ステップ６（上記を参照のこと）で取られた決定に関わりなく、確実にブロックの全ＹＵＶ変換データが間隔をあけて送信されるようにするものである。この間隔はプログラム可能で、確実に参照フレームデータの送信が出力ネットワークにおいてデータフローに対し最小限の影響を持つようになっている。パラメータは「ｘ個の通常のブロックごとに送信される１つの参照ブロック」によって定義される。ｘは典型的には１００以上である。
【０２４１】
このリフレッシュ機構は画像解像度とは無関係であり、画像における一時的な変更とは非対称であるため、画像内容とは無関係である。この機構はただ単に、１つのブロックについて最新の更新を送信するに過ぎず、このブロックは現在のフレーム内のブロックの指標によって支配されている。高い解像度の画像全体をリフレッシュするのにこのやり方では数秒間かかる場合があることがわかる。しかし、かかるシステムは静止画像に悪影響を及ぼすエラー（例えばネットワークの問題から生じるエラー）に効果的に対処し、例えば、新しいユーザーがログオンする場合に複数のユーザーをサポートする、さもなければこれら複数のユーザーは元の画像が変更されるまで静止画像データを受信することはないであろう。
【０２４２】
［ネットワーク接続］
ここでのタスクは、圧縮データをイーサネットネットワーク全体にわたって渡すことのできる形態へと変換することである。画像データはコード化された「画像ブロック」の形態であり、これらはそれぞれが画素の３２×３２アレーを記述している。かかるブロックは必ずしもイーサネットのペイロード仕様に一致するわけではない。加えて、デジタルオーディオデータを最終的なデータストリームに多重化するための規定がなくてはならない。
【０２４３】
それぞれのＹＵＶブロックは最上位のデータを先頭とし最下位のデータを追跡することをベースに符号化される。ブロックフォーマットを表４に示す。
【０２４４】
【表１】
2010022006.tif 000046
【０２４５】
［ユーザーデータグラムプロトコル（ＵＤＰ）の選択］
本発明の背後にある開発プログラムの初期には、デジタルリンク全体にわたって画像データを多重化し送信する数多くの異なる方法が考慮された。しかし、その後、インターネットプロトコルを使う汎用のイーサネットネットワークに乗じることにするという決定が下された。そして、システムが確実に「現実世界」で機能しまた実行する上でどのような困難も絶対に引き起こさないことが重要であった。
【０２４６】
その結果、ネットワーク全体にわたってデータを送信する方法を定義する際の手引きとなる原則は次のとおりである。
（ａ）目的は、同期画像送達の要件と食い違ってネットワークは事実上、非同期であるという事実にもかかわらず、リアルタイム画像の信頼性があり効率的なトランスポートである。
（ｂ）システムは既存のネットワークトランスポート基準およびプロトコルに基づいていなければならない。
（ｃ）ネットワーク全体にわたってシステムの複雑性が低くなければならない。
（ｄ）システムはマルチノードシステムとして機能しなければならない（すなわち、典型的には１つの画像供給源が複数の「ユーザー」または「視聴者」に分配されている）。
（ｅ）上述したことの当然の帰結として、（単数または複数の）ディスプレイノードをいかなるやり方でも管理するのに（単数または複数の）捕獲ノードは不必要でなければならない。これによりノードの計算上の複雑性が最小となり、（この実行において）スケーラビリティが提供される。
【０２４７】
技術上の要件は、図２４に示すように、データを、ＩＥＥＥ８０２．３メディアアクセスコントロール（ＭＡＣ）フレームに一致するフォーマットに取り入れることである。上述の最後の要件は、「マルチキャスト」法を指しており、これを実現するのに利用可能な方法は、ＭＡＣ「ペイロード」を、ユーザーデータグラムプロトコル（ＵＤＰ）に準拠する「データグラム」の形態にあるインターネットプロトコル（ＩＰ）に従わせることである。マルチキャストメッセージは特別なマルチキャスト「目的地アドレス」を持っている。最大データパケットサイズは１５００バイトであり、これはなんらかのプロトコルオーバーヘッドを備えていなければならない点に留意すること。より大きなパケットはギガバイトイーサネットで可能である。
【０２４８】
ＵＤＰは、簡素さおよび最小のデータオーバヘッドという最大の長所をもっている。しかしながら、ＩＰと同じく、これはコネクションレス型プロトコルでありそれ自体は信頼性のある通信をなんら保証もせず、どのような形態のエラー訂正または回復、またはどのような種類のメッセージフロー制御も行わない。通信は「最大努力」であり、欠点を克服する何らかの手段がアプリケーションに存在しなければならない。
【０２４９】
双方向通信（信頼性のあるポイント間通信を提供する、接続重視のプロトコルトランスポートコントロールプロトコル（ＴＣＰ）で使用されているような）の必要を完全に省くために、好ましいシステムはパケット損失に対して頑丈なように設計されている。表４は、特有のやり方でコード化された同期ワードによってそれぞれのデータブロックが分離されていることを示している。万が一、１つのブロックまたは一連のブロックからのデータが破損された場合に備えて、同期ワードがエラーの伝播を捕獲するように設計されている。同期ワードを使ってエラーを「くるみ」、これにより復号化されたビットストリームが不要情報を表示するのを防止する。（単数または複数の）エラーが生じた場合は、最新の手付かずの１つのブロックまたは複数のブロックが表示され続ける。
【０２５０】
［ＩＰパケットへの変換］
画像データのＩＰ／ＵＤＰへの準拠は２ステージプロセスである。最初のステージは元のコード化ＹＵＶブロックデータを一連の標準化データパケットに変換することである。あらゆる付随のオーディオが画像データで多重化されるのはこの時点である。オーディオはＡＥＳ／ＳＰＤＩＦ標準に従い非圧縮デジタルオーディオとして搬送される（ドルビーＡＣ３もまた搬送できる）。表５はパケットフォーマットを示している。
【０２５１】
【表２】
2010022006.tif 000047
【０２５２】
得られたビットストリームをバッファメモリに入れられ、そして必要なヘッダをつけた状態でイーサネットペイロードに変換される。プロセス全体を図２５に示す。
【０２５３】
図２５にはっきりと示されていないアイテムは、さらに別のリアルタイムプロトコル（ＲＴＰ）ヘッダで、これはトランスポート層ヘッダとトランスポート層ペイロードとの間で搬送されるものである。
【０２５４】
「ビデオのためのデータ開始」はフレーム開始を示し、１つのフレームに必要な可変の数のパケットにおける最初のパケットを示している。（１つのフレームに必要なパケットの数は、画像の性質、圧縮プロファイルおよび一時的な圧縮の影響により変わる。）もとの画像ブロックとパケット境界との間では位置合わせがなされていないため、最後のパケットは部分的にしか満たされていない場合がある。このような場合、パケットにはゼロをつめこんでパケットサイズを作り上げる。
【０２５５】
［ネットワークローディング］
上述のことから、圧縮画像を保持しているネットワークに提示されている「ローディング」は画像の性質によって可変であることが明らかである。事実上、どのような所定の画像解像度および圧縮プロファイルの場合でも、平均ビット速度はまったく一定のままであることがわかっている。これは、どのような現実のアプリケーションにおいても画像のために十分なネットワーク容量が確実にあるようにすることは簡単であることを意味しており、このことは特に複数の画像が保持されている場合に言えることである、なぜなら統計学的に全体のビット速度は非常に狭い制限内で一定のままとなるであろうからである。
【０２５６】
全体のシステムの「プログラム可能な」側面は個々のフレームベースで適用できる点に留意すべきである。これは、圧縮パフォーマンスが変更できるため平均ビット速度も「進行中に」変更できることを意味する。その結果、システムが一定のビット速度を提供することはないが、予測可能なパフォーマンス、および必要が生じると直ちにビット速度を変更する能力は提供する。
【０２５７】
［復号化オプション］
好ましいシステムの目的とする原則は、符号化および復号化プロセスが対称的であるということである。従って、復号化プロセスを普通に実行すると図１２に示すものの逆になることになり、類似のハードウェハ構造に基づかせることができる。要するに、
（ａ）入ってくるデータの流れは「脱パケット化」、すなわち、ＵＤＰフォーマットとエラー訂正とに関連しているすべてのオーバーヘッドデータが取り除かれ、コード化されたＹＵＶブロックデータが回復される。
（ｂ）圧縮プロファイル情報をまず最初に受信することにより、その後この情報を圧縮化ブロックデータに適用することが可能であり、そしてこれにより完全なＬＫＣＳ情報を回復することが可能となる。多くの場合、完全な「ツリー」はコード化された状態の単一のビットだけによって表される場合があるが、復号化を行う場合、すべての「かくれた」値が復元される点に留意すること。
（ｃ）ＬＫＣＳ情報を使って完全なセットのウェーブレット係数を作成する。
（ｄ）このデータは逆変換され、数式１３および１５を使ってＬおよびＨ値を回復する。符号化プロセスと同じく、これを行う場合には、レベル１の「垂直」に到達するまで何度も逆変換エンジンを経る必要がある。符号化プロセスの場合のように、「横列および縦列」制御を使えば簡素な１次元逆変換エンジンを使える。
（ｅ）回復されたデータはその後、水平なレベル１次元でのみ作用する第２の逆変換エンジンにかけられ、個々の画素データを回復する。
（ｆ）画素データ（個々では２つの画素ごとに１６ビットに戻っている）がＹＵＶから８ビットＲＧＢに変換し戻される。
【０２５８】
［パケット損失の対処］
現実のネットワークでは、データパケットが無くなる重大な機会がある。例えば、ＩＴＵが推奨するＹ．１５４１（ＩＰベースのサービスのためのネットワークパフォーマンス目標）はＩＰネットワークにおける１×１０−３のＩＰＬＲ（ＩＰパケット損失比）を想定している。明らかに、これは受信した画像に対して壊滅的な影響を持ち得る場合がある。しかしながら、複雑な前向きエラー訂正（帯域および待ち時間の両方を増加させると思われる）により生じるであろうさらなるオーバーヘッドを回避するために、好ましいシステムはそれ自身の画像ブロックフォーマット（表４）を使うことで、パケット損失の結果生じる汚染されたデータを破棄する方法を提供する。
【０２５９】
データストリームは連続的であるが、同期ワードは一連の１６ビット値の１として簡単に区別できる。図２６は、ＹＵＶデータの２つの連続的なブロックを示しており、すべて良好であれば、それぞれのブロックはそれ自身の同期ワードを持つが、ブロックの末端には次のブロックの同期ワードがあることがわかる。
【０２６０】
ＩＰネットワークでは、それぞれのＩＰパケットはＣＲＣチェックサムを使って検証される。ＩＰパケットは、無効であれば廃棄される。図面に示される画像ビットストリームの影響は、ある１つのセクションが切り離され、典型的には、無関係のブロックデータの２つのロットが１つにされる可能性があるというものである。
【０２６１】
ブロックの長さは可変であるが、画像データの「ツリー」の性質は、復号器には画像再構築を完成させるのに十分なデータをいつ受信したか「わかって」おり、従って、いつ次の同期ワードに出会うかを予測するというものである。かかる機能を利用してブロックデータを、ディスプレイメモリに送られる前に検証する。
【０２６２】
そのメカニズムは、ＹＵＢ  ＢＬＯＣＫｍの形態のブロックデータはそれ自身のＳＹＮＣ  ＷＯＲＤｍおよびそのすぐ隣のＳＹＮＣ  ＷＯＲＤｎ’によって検証されるというものである。復号器内の「ＹＵＶブロック送付モジュール」は、復号化されているＹＵＶブロックを保存しており、もし復号化されているＹＵＶブロックの末端に後続のＳＹＮＣワードが存在していれば、モジュールはＹＵＶブロックをディスプレイメモリへと通過させる。もし存在していなければ、復号化されているＹＵＶブロックは破棄される。
【０２６３】
画像フレーム内の最後のブロックの特別なケースは、通常は次の同期ワードに出会うことはないのであるが、フレームの最後にさらに別の同期ワードを挿入することによって対処される。これにより、有効なＹＵＶブロックだけをディスプレイへと確実に通過させることができる。この方法が機能するのは、ＹＵＶブロックが絶対的画像データを含んでおり、履歴または順方向データのいずれにも依存しないからである。万が一、ある１つのブロックが破棄される場合は、ディスプレイシステムは以前の「良好な」ＹＵＶ画像ブロックを示し続ける。典型的なディスプレイフレーム速度（２４−６０Ｈｚ）で作動するシステムでは、パケットの損失により生じるランダムエラーは、実際には注目に値するものではない。
【０２６４】
［ソフトウェア復号］
好ましいシステムの目的とするアプリケーションは、ほとんどの場合、ハードウェア復号を使って決定的なパフォーマンスを確実なものにするというものであろう。しかしながら、これまでの説明から、符号化プロセスの「出力」は１つの画像またはセットになった画像のビットストリームであることは明らかである。従って、理論上は、ビットストリーム構文を知っていれば誰でもソフトウェア方法だけを使ってそれを復号化する手段を考案できるであろうと思われる。
【０２６５】
特定の市場ニーズを満たすように「ソフトウェア復号」生成物を開発できると思われる。かかるニーズは（例えば、低い解像度で画像を受信するまたは部分的な画像を検討するために）より低レベルのパフォーマンスが受け入れられやすい場合に見込まれるものである。
【０２６６】
［圧縮された画像フォーマットの利点］
これまでの説明ではｃｏｄｅｃ（コード器−復号器）を説明してきた。これは、符号化および復号化プロセスで対称的にディスプレイを行う、すなわち決定的であり、（ただし一時的な圧縮プロセスにおけるビット速度は除く）また最小限の待ち時間しか招かないというものであった。明らかに、特に復号ステージにおいてさらに別の画像処理機能を導入する可能性もある。コード化されたデータは基礎をなす画像の非常に経済的な「短縮化された」記述を表し、これは画素ドメイン内で計算上集約的であると思われる動作は、コード化されたブロックドメイン内の最小の資源で実行できることを意味する。このことは特に、単一のｃｏｄｅｃユニットを使って複数の画像を同時に処理する場合にいえることである（例えば、業界で標準的なＦＰＧＡを使って実現されたｃｏｄｅｃは同時に８つの標準的なビデオ画像を処理できる）。
【０２６７】
いくつかの可能性として次のものが挙げられる。
（ａ）異なる画像ストリームから必要なブロックだけを選択することによって複数の画像表示を組み立て、並べ替えて必要なディスプレイフォーマットを生成する。
（ｂ）（変換のすべてのレベルを復号するわけではないと選択することで）異なる画像忠実度を選択する。
（ｃ）ディスプレイノードの能力に合致するように画像ブロックを選択する（例えば、画像ストリームは１６００×１２００の等価物を持ち得るが、ディスプレイは８００×６００だけしか表示できない）。このことはサイズ変更を意味するのではない点に注意すること。それはまた別の主題である。
【０２６８】
重要な理論上のポイントは、コード化ブロックレベルで行われるどのような処理または並べ替えもリアルタイムよりも高速で行われるものとして考えることができるということである。例えば、もし画像が２０：１で圧縮されていれば、どのような処理でも、対応する処理が画素レベルで生じた場合の２０分の１で起こることになる。
【０２６９】
［要約］
ウェーブレット変換に基づく画像圧縮の好ましい実施の有利な特徴のいくつかの要約は以下のとおりである。
（ａ）ＲＧＢからＹＵＶへの変換とウェーブレット変換との組み合わせにより得られる結果に精度維持の特性を使うことで、ビット成長のない全体的に可逆な損失なしの変換が提供される。
（ｂ）平行パイプラインアーキテクチャに基づく高速スケーラブル変換エンジン。変換の選択がプログラム可能なことからグラフィックおよび移動画像用途のどちらについても最適な結果が得られる。変換処理は決定的である、すなわち正確なサイクル時間で実行され画像内容から全く独立している。待ち時間を最小限にできる。
（ｃ）全フレーム変換の結果を実現して画像を移動させつつ実際にはブロックドメイン内ですべての処理を実行する方法（「ブロック外」変換データの使用）。
（ｄ）効率的な圧縮を導くことができるウェーブレット変換の特徴を利用できるように設計された新規の「ＬＫＣＳ」コード化アレンジメント。
（ｅ）損失のない、視覚的に損失のない、また、高い空間的圧縮効率で高い圧縮を提供できるプログラム可能な圧縮プロファイル。たとえば最も遅いビットストリーム速度に対する最も速いビットストリーム速度の割合は１０００：１である。
（ｆ）ウェーブレット署名のアプリケーションに基づく新規のプログラム可能な一時的圧縮体系。絶対的なコード化で、画像履歴または順方向予測を必要としない。画像待ち時間の延長がない。参照フレームを使って送信エラーの影響を排除する。
（ｇ）ビットストリームを自己記述することで、コード化画像ブロックデータを保持する。
（ｈ）システム出力はコネクションレスネットワークオペレーションのために構成されており、スケーラブルな複数の画像ネットワークの構成を規定している。ネットワーク送信エラーに対する高い免疫性。
（ｉ）符号化ビットストリームの性質を利用した、ＩＰパケット損失を検出する新規の方法。
【図１】
2010022006.tif 000048
【図２】
2010022006.tif 000049
【図３】
2010022006.tif 000050
【図４】
2010022006.tif 000051
【図５】
2010022006.tif 000052
【図６】
2010022006.tif 000053
【図７】
2010022006.tif 000054
【図８】
2010022006.tif 000055
【図９】
2010022006.tif 000056
【図１０】
2010022006.tif 000057
【図１１】
2010022006.tif 000058
【図１２】
2010022006.tif 000059
【図１３】
2010022006.tif 000060
【図１４】
2010022006.tif 000061
【図１５】
2010022006.tif 000062
【図１６】
2010022006.tif 000063
【図１７】
2010022006.tif 000064
【図１８】
2010022006.tif 000065
【図１９】
2010022006.tif 000066
【図２０】
2010022006.tif 000067
【図２１】
2010022006.tif 000068
【図２２】
2010022006.tif 000069
【図２３】
2010022006.tif 000070
【図２４】
2010022006.tif 000071
【図２５】
2010022006.tif 000072
【図２６】
2010022006.tif 000073