JP4716949B2 - 画像処理装置および画像処理方法 - Google Patents

Description

この発明は、キャッシュモデルを用いて部分画像の符号化データをアクセスする画像処理装置に関し、特に、キャッシュなどの記憶装置上に保存されている符号データの符号列（パケット）間の関係を示す階層構造を推定し、該階層構造に基づいて保存された符号データの符号列を参照し、キャッシュなどの記憶装置上のデータ参照構造を生成する画像処理装置に関するものである。

一般に、階層構造に基づいて保存された部分画像の符号化データをキャッシュモデルを用いてアクセスする画像処理装置が知られている。そして、次世代の画像符号化方式であるＪＰＥＧ２０００に準拠した符号化処理を全てハードウェア回路で実現する画像処理装置が提案されている。
ここで、符号データは、一般的に符号データを構成する符号列（パケット）単位にキャッシュに保存される。キャッシュ上の符号列を使用する場合は符号列（パケット）単位に必要な符号列を集めて参照する。

次に、ＪＰＥＧ２０００の基本となる階層符号化アルゴリズムについて説明する。
図２５は、ＪＰＥＧ２０００の基本となる階層符号化アルゴリズムの説明図である。２次元ウェーブレット変換・逆変換部、量子化・逆量子化部、エントロピー符号化・復号化部、タグ処理部で構成されている。ＪＰＥＧアルゴリズムと比較して、最も大きく異なる点の一つは変換方法である。ＪＰＥＧでは離散コサイン変換（以下、ＤＣＴ：Discrete Cosine Transform）を、階層符号化アルゴリズムでは離散ウェーブレット変換（以下、ＤＷＴ：Discrete Wavelet Transform）を、各々用いている。ＤＷＴはＤＣＴに比べて、高圧縮領域における画質が良いという長所が、ＪＰＥＧ（Joint Photographic Expert Group）の後継アルゴリズムであるＪＰＥＧ２０００で採用された大きな理由の一つとなっている。また、他の大きな相違点は、ＪＰＥＧ２０００では、処理の最終段に符号形成をおこなうために、タグ処理部と呼ばれる機能ブロックが追加されていることである。この部分で、符号化動作時には符号データがコード・ストリームとして生成され、復号動作時には復号に必要なコード・ストリームの解釈が行われる。そして、コード・ストリームによって、ＪＰＥＧ２０００は様々な便利な機能を実現できるようになった。例えば、図２６に示した様に、ブロック・ベースでのＤＷＴにおけるオクターブ分割に対応した任意の階層（デコンポジション・レベル）で、静止画像の圧縮伸長動作を自由に停止させることができるようになる。

なお、原画像の入出力部分には、色空間変換部が接続されることが多い。例えば、原色系のＲ（赤）／Ｇ（緑）／Ｂ（青）の各コンポーネントからなるＲＧＢ表色系や、補色系のＹ（黄）／Ｍ（マゼンタ）／Ｃ（シアン）の各コンポーネントからなるＹＭＣ表色系から、ＹＵＶあるいはＹＣｂＣｒ表色系への変換又は逆の変換を行う部分がこれに相当する。

以下、ＪＰＥＧ２０００アルゴリズムについて、少し詳しく説明する。
カラー画像は、一般に、図２７に示すように、原画像の各コンポーネント（ここではＲＧＢ原色系）が、矩形をした領域（タイル）によって分割される。そして、個々のタイル、例えば、Ｒ００、Ｒ０１、…、Ｒ１５／Ｇ００、Ｇ０１、…、Ｇ１５／Ｂ００、Ｂ０１、…、Ｂ１５が、圧縮伸長プロセスを実行する際の基本単位となる。従って、圧縮伸長動作は、コンポーネント毎、そしてタイル毎に、独立に行なわれる。
符号化時には、各コンポーネントの各タイルのデータが、図２５の色空間変換部に入力され、色空間変換を施されたのち、２次元ウェーブレット変換部で２次元ウェーブレット変換（順変換）が適用されて周波数帯に空間分割される。

図２６には、デコンポジション・レベル数が３の場合の、各デコンポジション・レベルにおけるサブ・バンドを示している。すなわち、原画像のタイル分割によって得られたタイル原画像（０ＬＬ）（デコンポジション・レベル０）に対して、２次元ウェーブレット変換を施し、デコンポジション・レベル１に示すサブ・バンド（１ＬＬ、１ＨＬ、１ＬＨ、１ＨＨ）を分離する。そして引き続き、この階層における低周波成分１ＬＬに対して、２次元ウェーブレット変換を施し、デコンポジション・レベル２に示すサブ・バンド（２ＬＬ、２ＨＬ、２ＬＨ、２ＨＨ）を分離する。順次同様に、低周波成分２ＬＬに対しても、２次元ウェーブレット変換を施し、デコンポジション・レベル３に示すサブ・バンド（３ＬＬ、３ＨＬ、３ＬＨ、３ＨＨ）を分離する。更に図２６では、各デコンポジション・レベルにおいて符号化の対象となるサブ・バンドを、グレーで表してある。例えば、デコンポジション・レベル数を３とした時、グレーで示したサブ・バンド（３ＨＬ、３ＬＨ、３ＨＨ、２ＨＬ、２ＬＨ、２ＨＨ、１ＨＬ、１ＬＨ、１ＨＨ）が符号化対象となり、３ＬＬサブ・バンドは符号化されない。

次いで、指定した符号化の順番で符号化の対象となるビットが定められ、図２５の量子化部で対象ビット周辺のビットからコンテキストが生成される。
量子化の処理が終わったウェーブレット係数は、個々のサブバンド毎に、「プレシンクト」と呼ばれる重複しない矩形に分割される。これは、インプリメンテーションでメモリを効率的に使うために導入されたものである。図２８に示した様に、一つのプレシンクトは、空間的に一致した３つの矩形領域からなっている。更に、個々のプレシンクトは、重複しない矩形の「コード・ブロック」に分けられる。これは、エントロピー・コーディングを行う際の基本単位となる。

エントロピー符号化部（図２５参照）では、コンテキストと対象ビットから確率推定によって、各コンポーネントのタイルに対する符号化を行う。こうして、原画像の全てのコンポーネントについて、タイル単位で符号化処理が行われる。
エントロピー符号化部で形成される符号データの最小単位は、パケットと呼ばれる。パケットは、プログレッシブ順にシーケンス化され、これが画像ヘッダセグメントのなかの１つで示される。パケットは、あるプログレッシブ順データたとえば、それぞれ、領域、解像度、レイヤ、および色成分によって配列される。即ち、ＪＰＥＧ２０００規格では、画質（レイヤ（Ｌ））、解像度（Ｒ）、コンポーネント（Ｃ）、位置（プレシンクト（Ｐ））という４つの画像の要素の優先順位を変更することによって、以下に示す５通りのプログレッションが定義されている。

ＬＲＣＰプログレッション：プレシンクト、コンポーネント、解像度レベル、レイヤの順序に復号されるため、レイヤのインデックスが進む毎に画像全面の画質が改善されることになり、画質のプログレッションが実現出来る。レイヤプログレッションとも呼ばれる。
ＲＬＣＰプログレッション：プレシンクト、コンポーネント、レイヤ、解像度レベルの順序に復号されるため、解像度のプログレッションが実現出来る。
ＲＰＣＬプログレッション：レイヤ、コンポーネント、プレシンクト、解像度レベルの順序に復号されるため、ＲＬＣＰ同様、解像度のプログレッションであるが、特定位置の優先度を高くすることが出来る。
ＰＣＲＬプログレッション：レイヤ、解像度レベル、コンポーネント、プレシンクトの順序に復号されるため、特定部分の復号が優先されるようになり空間位置のプログレッションが実現出来る。
ＣＰＲＬプログレッション：レイヤ、解像度レベル、プレシンクト、コンポーネントの順序に復号されるため、例えばカラー画像のプログレッシブ復号の際に最初にグレーの画像を再現するようなコンポーネントのプログレッションが実現出来る。

このようにＪＰＥＧ２０００規格では、画像は領域（タイルまたはプレシンクトといった画像構成要素）、解像度、階層（レイヤ）、色成分に分割され、夫々が独立してパケットとして符号化される。これらのパケットはデコードすることなしに、コード・ストリームから識別され抽出され得るところに特徴がある。

最後にタグ処理部（符号列形成部）は、エントロピコーダ部からの全符号化データを１本のコード・ストリームに結合するとともに、それにタグを付加する処理を行う。図２９には、コード・ストリームの構造を簡単に示した。コード・ストリームの先頭と各タイルを構成する部分タイルの先頭にはヘッダと呼ばれるタグ情報が付加され、その後に、各タイルの符号化データが続く。そして、コード・ストリームの終端には、再びタグが置かれる。

一方、復号化時には、符号化時とは逆に、各コンポーネントの各タイルのコード・ストリームから画像データを生成する。図２５を用いて簡単に説明する。この場合、タグ処理部は、外部より入力したコード・ストリームに付加されたタグ情報を解釈し、コード・ストリームを各コンポーネントの各タイルのコード・ストリームに分解し、その各コンポーネントの各タイルのコード・ストリーム毎に復号化処理が行われる。コード・ストリーム内のタグ情報に基づく順番で復号化の対象となるビットの位置が定められるとともに、逆量子化部で、その対象ビット位置の周辺ビット（既に復号化を終えている）の並びからコンテキストが生成される。エントロピー復号化部で、このコンテキストとコード・ストリームから確率推定によって復号化を行い対象ビットを生成し、それを対象ビットの位置に書き込む。このようにして復号化されたデータは各周波数帯域毎に空間分割されているため、これを２次元ウェーブレット逆変換部で２次元ウェーブレット逆変換を行うことにより、画像データの各コンポーネントの各タイルが復元される。復元されたデータは色空間逆変換部によって元の表色系のデータに変換される。
サーバにあるＪＰＥＧ２０００仕様に基づいて符号化された符号データをアクセスする方式としてＪＰＩＰ（JPEG2000 image coding system-Part9：Interactivity tools, APIs and protocols）がある。その仕様には、既にクライアント側に受信された符号データは新たに転送することなく使用することで高速にアクセスできるような仕組みとして、クライアント上に符号データの一部を保存するキャッシュの機能を備えている。

なお、先行技術としては、特許文献１は、複数のパケットから成るタイル単位で分割された画像の符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数のパケットのデータを受信する場合に、受信する各パケットを管理するための管理情報を作成し、受信した各々のパケットを、夫々のパケットが属するタイルの番号に従って並び替え、更に、同じタイルに属する夫々のパケットをこのタイル中の順番に従って並び替え、並び替えたパケットのデータを管理情報に順次付加すると共に、付加したパケットのデータと管理情報とを含むキャッシュデータ中の、各パケットのデータの配置に関する情報を管理情報に登録する技術が開示されている。

また特許文献２として、出力ＪＰＥＧ２０００符号ストリームへ主ヘッダデータ−ビンをレイヤプログレッションが最後のプログレッション順序の使用を規定するマーカセグメントともに書き込み、各タイルについて正規のタイルヘッダを書き込み、前記各タイルの各コンポーネント、位置及び、解像度について、完全に受信されたレイヤの数を決定し、出力ＪＰＥＧ２０００符号ストリームへ、完了されたレイヤに対応するプレシンクトデータビンのバイトを書き込み、完了していない各レイヤの各パケットに対して、空のパケットヘッダを書き込み、また各タイルに対して、パケットデータのバイト数へ長さを調整するためにＳＯＴマーカセグメント（Start of tile-part）を更新し、出力ＪＰＥＧ２０００符号ストリームの最後にＥＯＣマーカを書き込むことを含む技術が開示されている。ＳＯＴマーカセグメントとは、タイルパートの先頭を意味し、タイルのインデックス、タイルパートのインデックスを示すものである。また、ＥＯＣマーカ（End of codestream）とは、コード・データの最後尾を示すものである。

特許文献３として、クライアントは、サーバが管理する符号データのうち、第１の符号データを格納しており、ＪＰＥＧ２０００符号データの作成に必要となる符号データと第１の符号データとから、不足する第２の符号データを算出し、そして、サーバから第２の符号データを取得し、そのヘッダ情報を解析して、符号データを複数の独立した符号データに分割し、さらに、分割された単位毎に、独立した符号データの全てのデータが格納されていない場合、ダミー符号データを格納し、その符号データをＪＰＥＧ２０００符号データとする技術が開示されている。

特許文献４として、断片化された符号化データを受信してメモリに格納しておき、ユーザの表示要求に基づいてProgression Orderを判断し、その判断に基いてヘッダ情報を変更し、その変更したヘッダ情報に基づいて、メモリに該当する符号化データが格納されているかどうかを判定し、メモリに格納されていると判定された断片化された符号化データを読み出して、その表示要求に適したProgression Orderに変換するとともに、メモリに格納されていない符号化データにはＺＬＰを適用してＪＰＥＧ２０００準拠の符号化データを作成する技術が開示されている。
特開２００５−１２６８６公報 特開２００４−２７４７５８公報 特開２００４−２４２２７３公報 特開２００３−１６９２１６公報

しかしながら、上記従来のＪＰＥＧ２０００に準拠する符号化処理を全てハードウェア回路で実現する画像処理装置には、以下のような問題点があった。
すなわち、ＪＰＩＰ（JPEG2000 image coding system-Part9：Interactivity tools, APIs and protocols）など部分画像の符号データをダウンロードして復号する場合、符号データは断片化された部分符号データであるために、ダウンロードされた（あるいは、ロードされキャッシュなどの記憶装置上に保存された）符号データが、符号データを構成する全ての符号列（パケット）を全て備えている場合は少ない。部分画像の符号データは、符号データを構成する一部の符号列しか含んでいないからである。

ところで、ＪＰＩＰでは、サーバ側からクライアント側へ転送された部分画像の符号データの符号列をキャッシュ（記憶装置）に保存しておいて再利用し、クライアント側での効率的な再生を施す仕組みが備わっている。典型的には、サーバ側からクライアント側へ転送された部分画像の新たな符号列を順次保存する。 ところが、一般的に、キャッシュメモリに保存される符号データは、符号データを構成する最小の単位であるパケット単位に保存されるなど、先に示したように、部分画像の符号データは、断片的な符号データの一部を構成しているので、保存される符号列も断片的である。そのため、キャッシュに保存された符号列を利用する場合には、効率的な利用ができなかった。

また、部分画像の符号データを参照するＪＰＩＰ（JPEG2000 image coding system-Part9：Interactivity tools, APIs and protocols）においては、データクセス単位は構造化要素単位でまとまったものではなく、符号データの最小基本単位であるパケットである。そのため、構造化要素単位でデータをアクセスしようとする場合、その都度構造化要素単位を構成するのに必要なパケットを集め、全体が過不足無く充足しているかをチェックしキャッシュメモリ上にデータが存在するかどうかを識別し復号再生する必要があった。符号列が欠けているかどうかの判断も、符号列の全体構成がわからないために、効率的な符号データの符号列の参照ができないという問題があった。
また、ＪＰＩＰなど部分画像の符号データをロードして復号する場合、符号データは断片化された部分符号データであるために全ての符号データが完備されている場合は少ない。符号データが部分的に欠けているような場合もあるため、効率的なアクセスができないということもあった。

本発明は、上記従来の問題点を解決するためになされたものであって、その目的は、断片的な部分符号データから元階層符号データの階層構造を推定することによって、構造化符号データのある特定の領域の符号データだけをアクセス（参照あるいは読み込み）する場合の処理効率を高めることができる画像処理装置を提供することである。

上述の目的を達成するために、請求項１記載の発明は、部分符号データを通信回線を介してロードする画像処理装置であって、前記部分符号データに含まれる符号列が、タイル、コンポーネント、位置、及び解像度を階層として、該階層のどのレベルのデータであるかを符号列毎に抽出する抽出手段と、前記抽出手段で抽出した符号列毎の階層レベルに基づき、符号列毎の階層レベルを推定する階層レベル推定手段と、前記推定手段で推定した符号列毎の最高階層レベルを管理テーブルに書き込む書込手段と、前記推定手段で推定した最高階層レベルを、各階層ごとに最高階層レベルをもつように階層データテーブルを作成する作成手段と、を有し、前記書込手段は、前記管理テーブルに記述してある各階層毎のレベルと、新たに受信した部分符号データに含まれる符号列毎の階層レベルとを比較し、前記管理テーブルに書き込まれている符号列毎の階層レベルより前記新たに受信した部分符号データに含まれる符号列毎の各階層レベルが大きい場合、前記新たに受信した部分符号データに含まれる符号列毎の階層レベルを前記管理テーブルに書き換えることを特徴とする。
また、請求項２記載の発明は、前記部分符号データは、ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリーム等の階層化符号データであることを特徴とする。

また、請求項３記載の発明は、前記階層レベル抽出手段は、前記部分符号データがＪＰＥＧ２０００のコード・ストリームや、ＪＰＩＰのストリームである場合は、それぞれストリームのデータを参照することによって階層レベルを算出することを特徴とする。
また、請求項４記載の発明は、部分符号データを通信回線を介してロードする画像処理方法であって、
前記部分符号データに含まれる符号列が、タイル、コンポーネント、位置、及び解像度を階層として、該階層のどのレベルのデータであるかを符号列毎に抽出する抽出工程と、前記抽出手段で抽出した符号列毎の階層レベルに基づき、符号列毎の階層レベルを推定する推定工程と、前記推定工程で推定した符号列毎の最高階層レベルを管理テーブルに書き込む書込手段と、前記推定工程で推定した最高階層レベルを、各階層ごとに最高階層レベルをもつように階層データテーブルを作成する作成工程と、を有し、前記書込工程は、前記管理テーブルに記述してある各階層毎のレベルと、新たに受信した部分符号データに含まれる符号列毎の階層レベルとを比較し、前記管理テーブルに書き込まれている符号列毎の階層レベルより前記新たに受信した部分符号データに含まれる符号列毎の各階層レベルが大きい場合、前記新たに受信した部分符号データに含まれる符号列毎の階層レベルを前記管理テーブルに書き換えることを特徴とする。
また、請求項５の発明は、前記部分符号データは、ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリームであることを特徴とする。
また、請求項６の発明は、前記抽出工程は、前記ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリームである場合は、夫々のストリームを参照することで階層レベルを算出することを特徴とする。

本発明によれば、断片的な部分符号データから元の階層符号データの階層構造を推定することにより、構造化符号データのある特定の領域の符号データだけをアクセス（参照あるいは読み込み）する場合の処理効率を高めることができる。
また、本発明によれば、推定された階層構造を活用して、構造化符号データを参照する場合に、構造化文書の構造を反映した区切り単位で管理することにより、キャッシュなどの符号データ記憶装置に保存されている符号データを構成する符号列として欠けているものが容易に把握できる。保存されている符号列の再利用が効率的になる。空き時間に欠けている符号列のアップロードが可能となる。構造化要素単位ごとに部分符号データを参照し復号化処理が効率的にできる。
また、本発明によれば、ＪＰＩＰの実現方式において、部分符号データのアクセスが効率的にできる。

また、本発明によれば、符号データ記憶装置に保存された階層符号データのデータ構成として、符号データの構成をツリー構造で構成し、構成要素に含まれる符号データの最小基本単位であるパケットへのポインタを保持する構成とする。
また、本発明によれば、構造化符号データは、構造化要素単位（符号データ階層レベル単位）でまとまったデータのアクセス（参照あるいは読み込み）がなされるため、構造化要素単位（符号データ階層レベル単位）で、符号列が保存されているかいないかを識別する機能を提供し、効率的に符号データをアクセスするデータ参照構造を生成し、構成要素毎に容易に参照できる構成となる。
また、本発明によれば、処理の空き時間にバックグラウンドでクライアント側で未受信である符号列データを受信する仕組みを提供するので、アクセス頻度が高いと思われる符号列データから優先的に受信する仕組みを提供できる。

以下に添付の図を参照してこの発明の実施形態を詳細に説明する。
＜実施例＞
まず、本発明の実施形態について説明する前に、ＪＰＩＰにおける符号データのやり取りについて説明する。
サーバにあるＪＰＥＧ２０００符号から、必要な符号だけを受信するためのプロトコルとして国際規格ＪＰＩＰ（JPEG2000 image coding system - Part 9：Interactivity tools, APIs and protocols）がある。このような、階層的な画像を部分的にアクセスするためのプロトコルは、古くは、画像の多重解像度表現であるＦｌａｓｈＰｉｘと、それにアクセスするためのプロトコルであるＩＩＰ（Internet Imaging Protocol）に見ることができる。ＪＰＩＰに係る特許文献としては、特開２００４−２７４７５８がある。

ＪＰＩＰにおいては、クライアントからの要求（リクエスト）に応じて、サーバは完全な画像ファイル、タイルパートストリーム（ＪＰＴ−ストリーム）またはプレシンクトストリーム（ＪＰＰ−ストリーム）の形式をもつ符号データをクライアントに出力する（応答する）。ＪＰＴ−ストリームは、ＪＰＥＧ２０００パート１規格で規定されるタイルパートの組としてサブ画像の符号データをクライアントに出力する方法である。一方、ＪＰＰ−ストリームは、ＪＰＥＧ２０００パート１規格で規定されるプレシンクトの組としてサブ画像の符号データをクライアントに出力する方法である。ＪＰＴ−ストリームにより順次アクセスした符号データを再生する場合は、タイル分割されたタイル領域毎に順次完全に再生するのに対して、ＪＰＰ−ストリームにより順次アクセスした符号データを再生する場合は、タイル領域に跨った広い領域で、小さい領域（プレシンクト）単位に徐々に再生することができる。すなわち、ＪＰＴ−ストリームのアクセスによる再生では、一時に再生する範囲が画像全体の中であるタイル領域に限定されているのに対し、ＪＰＰ−ストリームのアクセスによる再生では、一時に再生する範囲はタイル領域に限定されず画像全体での再生が可能なのである。

このように、ＪＰＩＰのクライアントは、受信された符号データの部分を識別でき、それらの部分を復号し且つ画像を生成することのできるように、タイルパートストリーム又は、プレシンクトストリームの形式で、ＪＰＥＧ２０００コード・ストリームのサブセットを戻す機能を提供する。
すなわち、ＪＰＰ−ストリームはＪＰＥＧ２０００コード・ストリームへ変換されＪＰＥＧ２０００デコーダで復号することができる。前記変換は、復号されるデータと共に、メインヘッダの全てとタイルヘッダの全てを受信すれば十分である。

ＪＰＰストリームは、メッセージのシーケンスより構成される（図２３参照）。各メッセージは、含まれるデータビン情報の形式を示す（メインヘッダ、メタデータ、プレシンクト、又は、タイルヘッダ）。各メッセージは、データビン内の開始位置とメッセージの長さも示す。各メッセージは、その形式、その形式内のインデックス、その形式とインデックスを有する“データビン”へのメッセージのオフセット、及び、メッセージ長を識別するヘッダを有する。メッセージは、典型的には、データビン全てを含まず、データビンの一部を含む。メッセージには、データビンがどのタイル、コンポーネント、位置及び、解像度データビンに対してであるかを示す識別子を含む。本発明では、タイル、コンポーネント、位置及び、解像度を階層としており、データビンに含まれる符号列（パケット）は、各階層のどのレベル（階層レベル）のデータであるかという情報が対応している。例えば、データビンに含まれるある符号列がタイルＡでコンポーネントがＣｂで位置４で解像度１レベルであることが示されている。

プレシンクトデータビンは、一連のパケットヘッダ（ＰＨ）とパケットデータ（ＰＤ）より構成される（図２４参照）。パケットヘッダは、どのコード・ブロックがパケットのパケットデータ部分内のデータを有するかに関する情報、各符号ブロックに格納されたバイト数に関する情報、及び、各符号ブロックについての符号化パスの数を含む。ＪＰＩＰの標準仕様では、パケットヘッダには、どのコンポーネント、位置、解像度、タイル、あるいは、それが属するレイヤを識別する情報（階層レベル情）はもってない。本発明の一実施例として、先に示したメッセージデータを解析して、パケット単位の階層レベル情報をパケットヘッダに記録してもかまわない。クライアント側でＪＰＰ−ストリーム受信後、これらの情報を記録することもできる。
同様に、ＪＰＩＰの標準仕様では、パケットヘッダの長さに関する明確な情報はも持たない。パケットデータの長さは、パケット内の全てのコード・ブロックにデータの長さを加算することにより決定できる。本発明の一実施例として、パケットヘッダにこれらのデータ長を計算した結果を保存する構成にすることができる。ＪＰＰ−ストリームに規定された構成によりパケットを抽出することができる。

ＪＰＩＰのプロトコルは、二つの異なるタイプの要求をもっている。サーバがキャッシュモデルを維持する必要がないという意味におけるステートレスリクエストとそれ以外のリクエストがある。サーバのキャッシュモデルには、それまでにサーバに送信したことについての情報の記録がなされている。クライアントのキャッシュには、サーバから受信した符号データが保存され、サーバは、キャッシュモデルを用いることによって、既に転送した符号データをクライントに転送することなく、再利用できる。典型的には、クライアントは、断片的に受信したＪＰＥＧ２０００の符号データを、受信した順番にデータをアペンドしキャッシュに保存する。続いて、前述したようにキャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、そのビットストリームをデコードする。

次に、本発明の実施形態について説明する。
図１は、クライアント及びサーバ間で符号データを通信するネットワーク環境におけるクライアントサーバモデルの一実施形態のブロック構成図である。
図１に示すように、サーバ１０２は、ネットワークを介して少なくとも１つのクライアント１０１に接続されている。クライアント１０１は、ある画像のサブセットに対する要求（リクエスト）１１０を発行し、要求１１０に示された方法で対応する符号データを含む、応答１１１のような応答を受信する。
ネットワークの帯域幅又はサーバ１０２の資源又はファイル要求の構造のために、クライアント１０１は、要求された画像の部分符号データ以外のおおよその符号データを受信し得る。クライアント１０１は、キャッシュを用いて、画像の異なる部分の出力に対する要求を発行し、前に受信された符号データに対する追加分の符号データを受信する。

ＪＰＩＰの基本的特徴の一つは、クライアントが既に受信した符号データを繰り返すことを避ける能力である。この符号データの再送信を避けるために、以下のような２つの方法がある。
一つ目の方法としては、クライアント１０１が、サーバ１０２へ送信されクライアントで既に受信された符号データについての情報をもつことで、クライント１０１は冗長なデータの配信をサーバ１０２に要求しないで済ませ、それにより、サーバ１０２は冗長な符号データを送信しないで済ます方法である。
ここでは、サーバ１０２が、ステートレスで動作する場合にあっては、それまでの相互動作を記憶することなく動作する。サーバ１０２が、それまでの相互動作を記憶する特別なキャッシュモデルを維持する必要がないことから、一般的には、ステートレスで動作しているということが多い。

二つ目の方法としては、図２に示すように、クライアント１０１とサーバ１０２は、“セッション”を確立し、サーバ１０２は、クライアント１０１へ送られた符号データを記憶しておくキャッシュモデル１０６をもっている。すなわち、サーバ１０２のキャッシュモデル１０６には、それまでにサーバ１０２に送信したことについての情報の記録がなされている。クライアント１０１のキャッシュ１０３には、サーバ１０２から受信した符号データが保存され、サーバ１０２は、キャッシュモデル１０６を用いることによって、既に転送した符号データをクライント１０１に転送することなく、再利用できる。典型的には、クライアント１０１は、断片的に受信したＪＰＥＧ２０００の符号データを、受信した順番に符号データをアペンドしキャッシュ１０３に保存する。続いて、前述したようにキャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、そのビットストリームをデコードする。

本発明は、主に、ステートレスな要求を処理するクライアントサーバモデルに係り、図１の実施形態に示すように、クライアント１０１側にキャッシュ管理部１０８を有することで、キャッシュ１０３のキャッシュデータを管理するところに特徴がある。
ここでは、クライアント１０１は、それまでに要求した符号データの全てを受信する前でも、ユーザーが指定した画像の部分に対応する符号データを変更し得る。あるサーバは、これらの変更を扱うために、前の要求に対する応答を割り込みすることができる。

図３は、図１に示したキャッシュ管理部１０８の詳細を示したブロック構成図である。図３に示すように、キャッシュ上の符号列を管理するために、キャッシュ管理部１０８には、符号データ解析部１０１０、管理テーブル構造テーブル生成処理部１０１１、同変更処理部１０１２、同参照処理部１０１３、符号データ保存処理部１０１４、を備えている。

図４は、クライアントサーバネットワークモデルのブロック図である。図４に示すように、ネットワーク２５０は、複数のクライアント（例えば、クライアント２０１、２０２、２２１、２２２）と複数のサーバ２０３を含む。このサーバは、数１００万の異なるクライアントへ同じ画像の異なる部分を扱い得る。このクライアントは、画像と他のデータ（例えば、ＨＴＭＬページ）を、幾つかのサーバから受信する。プロキシサーバは、オリジナルサーバと通信すること無しに幾つかの要求への素早い応答を可能とするために、ネットワーク内に存在しうる。有効な帯域幅と帯域幅のコストは、異なるクライアントと同じサーバの間で又は、異なるサーバの間で広く変わる。

ここで、最も一般的に使用されるネットワークは、インターネット又はワールドワイドウェブである。しかし、ＪＰＩＰは、ローカルエリアネットワーク又は、どのような一般的な相互接続システムに適用できる。同様に、ＪＰＩＰは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）の上で“最も一般的に転送されるが、しかし、ＴＣＰ／ＩＰ及びＵＤＰを含む他の転送プロトコルと共に使用されると予想される。
以上のことから、ＪＰＩＰストリームの符号フォーマット（メッセージ）を分析することで、コンポーネント数、レイヤ数、プレシンクトサイズ、デコンポジション分割数などの階層符号データを構成する各階層のレベル数がわかる。また、プログレッション順序についても知ることができる。

図５は、ＪＰＩＰを使用した場合の出力表示画面例を示す説明図である。図５に示すように、最上位画面では、２つのタイルからなるデータが表示されていて、例えば、それぞれのタイルをクリックすることによって画像データが表示され、中図のような画質の劣ったタイル４枚からなる画像となる。さらに、右下をクリックすることによって、そのタイルの部分画像の解像度が変倍され、部分画質レベルが向上する。このように、部分画像データを参照する場合に使用される。部分画像データを参照する都度、表示クライント側からサーバ側へ符号データを転送要求し再生する。
このようにＪＰＩＰにおいては、クライアント（出力側）では、全ての（階層）符号データではなく、部分符号データを必要としていることを前提としている。

次に、ＪＰＥＧ２０００のコード・ストリームのフォーマットについて説明すると、ＪＰＥＧ２０００のコード・ストリームは、画像についての全てのエントロピー符号化されたデータと、その符号化されたデータを復号するために使用されるべき方法を記述するデータを含む。コード・ストリームは、使用されるウェーブレット変換に関する情報、タイルのサイズ、プレシンクトのサイズ、解像度に関する情報、ファイル内のパケットの順序等を含む。コード・ストリームは、エントロピー符号化されたデータを画像サンプルに復号するのに必要な全てのパラメータを含まなければならない。コード・ストリームは、例えば、パケットの長さのような、符号化されたデータの部分への高速アクセスを提供する情報も含みうる。

図６は、ＪＰＥＧ２０００のコード・ストリームのフォーマットの概略構成を示す説明図である。図６に示すように、ＪＰＥＧ２０００の“コード・ストリーム”には、いくつかのマーカセグメントをもっている。マーカセグメントとは、一つの２バイト長よりなるマーカとそれに付随するパラメータ群から構成されている。各マーカセグメントには機能、用途、データ長が表されている。コード・ストリームのフォーマットは符号データの始まりを示すＳＯＣ（Start of codestream）マーカで始まる。ＳＯＣマーカの後には、符号化のパラメータや量子化のパラメータ等を記述したメインヘッダが続き、その後に実際の符号データが続く。

図６に示すように、メインヘッダはＣＯＤ（Coding style default）、ＱＣＤ（Quantization default）の必須マーカセグメントとＣＯＣ（Coding style component）、ＱＣＣ（Quantization component）、ＲＧＮ（Region of interest）、ＰＯＣ（Progressive order change）、ＰＰＭ（Packed packet headers、main header）、ＴＬＭ（Tile-part length）、ＰＬＭ（Packet length、main header）、ＣＲＧ（Component registration）、ＣＯＭ（Comment）のオプションマーカセグメントで構成される。ここで、ＳＩＺマーカセグメントには、コンポーネント数とかタイルサイズなどの非圧縮時の画像の情報が記述され画像コンポーネントの幅と高さについての情報を含む。ＣＯＤとＣＯＣマーカセグメントは、圧縮されたデータはどの様に復号されるべきかを示すパラメータを含む。ＣＯＤマーカにはプログレッション順序、レイヤ数、プレシンクトサイズ、デコンポジション分割数が記述されている。ＱＣＤマーカは量子化に係る情報が記載されている。またＣＯＭマーカはコメント等の情報を付加したいときに利用するマーカで、メインヘッダ、タイルヘッダの双方で使用することが可能である。

メインヘッダの後に、一連の“タイルパート”がある。各タイルパートは、特定のタイルと部分を識別する“ＳＯＴ”マーカセグメントで始まる。各タイルパートについて符号化されたデータには、“ＳＯＴ”マーカセグメントが先行する。“ＳＯＴ”マーカセグメントには、タイルパート数に係る情報を含んでいる。
実際の符号データは、図７に示すように、ＳＯＴ（Start of tile-part）マーカで始まり、タイルヘッダ、ＳＯＤ（Start of data）マーカ、タイルデータ（符号）で構成される。これら画像全体に相当する符号データの後に、符号の終了を示すＥＯＣ（End of codestream）マーカが付加される。メインヘッダはＣＯＤ、ＱＣＤの必須マーカセグメントとＣＯＣ、ＱＣＣ、ＲＧＮ、ＰＯＣ、ＰＰＭ、ＴＬＭ、ＰＬＭ、ＣＲＧ、ＣＯＭのオプションマーカセグメントで構成される。
図７は、ＪＰＥＧ２０００のコード・ストリームの一例である。

図６の右端２つに、タイルヘッダ構成を示す。図６は、タイルデータの先頭に付加されるマーカセグメント列であり、ＣＯＤ、ＣＯＣ、ＱＣＤ、ＱＣＣ、ＲＧＮ、ＰＯＣ、ＰＰＴ、ＰＬＴ、ＣＯＭのマーカセグメントが使用可能である。
一方、図６の右下は、タイル内が複数に分割されている場合における分割されたタイルパートの先頭に付加されるマーカセグメント列であり、ＰＯＣ、ＰＰＴ、ＰＬＴ、ＣＯＭのマーカセグメントが使用可能である。タイルヘッダでは必須マーカセグメントはなく、すべてオプションである。
タイルデータ（符号）は、連続したパケットで構成される。コード・ストリーム中のパケットの順番をプログレッション順序と呼んでいる。
以上のことから、ＪＰＥＧ２０００コードフォーマットを分析することで、コンポーネント数、レイヤ数、プレシンクトサイズ、デコンポジション分割数などの階層符号データを構成する各階層のレベル数がわかる。また、プログレッション順序についても知ることができる。

次に、符号データを構成する断片的な符号列によって符号データの階層構造を推定する動作について説明する。
図８は、キャッシュ管理に係る処理フローチャートである。
図８に示すように、まず、クライアントからの処理要求待ちとなり（Ｓ１）、クライアントから復号出力処理の要求があると復号出力処理要求処理となり、出力要求ファイル名、又はファイル名と出力範囲とが指定される（Ｓ２）。次に、クライアント内のキャッシュ（あるいは外部記憶装置）の符号データ検査処理を行い（Ｓ３）、クライアントが要求した対象の符号データがある場合（Ｓ４）、対象の符号データを読み出し（Ｓ５）、復号化処理を行う（Ｓ６）。

また、クライアントが要求した対象の符号データがキャッシュにない場合（Ｓ７）、サーバへ符号データのアップロード要求を行い、サーバからクライアントは要求した対象の符号データを受信し（Ｓ８）、新たにアップロードした符号データをキャッシュ又は外部記憶装置に保存し（Ｓ９）、復号化処理を行なって（Ｓ６）、出力処理を行う（Ｓ１０）。
また、クライアントが要求した対象の符号データがキャッシュにあるが、符号データを構成する一部の符号列のみがキャッシュにないような場合がある。そのような場合、キャッシュに存在しない符号列のみを要求するのが一般的である。しかしながら、一部の符号データのみがキャッシュにないような場合であっても、全ての符号列が揃っていない場合には、全ての符号列のロードを要求する。

次に、断片的な符号列（パケット）群よりの構造推定について説明する。
図９は、断片的な符号列（パケット）群より構造を把握する概念図である。
Ａ．サーバからクライアントへ部分符号データを出力する。出力された部分符号データは階層化符号データであり、たとえば、前述したような、ＪＰＥＧ２０００のコード・ストリームであったり、ＪＰＩＰのストリームである。
Ｂ．クライアントは、部分符号データに含まれる符号列の階層レベルを符号列ごとに抽出する。先に述べたように、部分符号データがＪＰＥＧ２０００のコード・ストリームや、ＪＰＩＰのストリームである場合は、それぞれストリームのデータを参照することによって算出できる。

この図で示した例では、２つの符号列が抽出されており、ひとつの符号列は、第一階層がレベル２、第二階層がレベル１、第三階層がレベル１である。もうひとつの符号列は、第一階層がレベル２、第二階層がレベル１、第三階層がレベル２である。
Ｃ．上記部分符号データに含まれる符号列の階層レベルに基づき符号列の階層レベルを推定する。
Ｄ．クライアントが有するキャッシュデータ管理テーブルに符号列の最高階層レベルを書き込む。各階層ごと最高階層レベルをもつように階層データテーブルを作成する。次に符号列をキャッシュに保存し、その符号列へのポインタを書き込む。符号列へのポインタを記載している構造データの項目は、初期値がＮＵＬＬであり、符号データがない列はＮＵＬＬとなる。

続いて、Ｅ．新しい部分符号データをサーバからクライアントに出力する。
Ｆ．クライアントは、部分符号データに含まれる符号列の階層レベルを符号列ごとに抽出する。この例では、新たに新しい符号列が３つ受信した場合を示す。
Ｇ．同様に、部分符号データに含まれる符号列の階層レベルを使用して符号列の階層レベルを推定する。先に作成し書き込んだキャッシュデータ管理テーブルに記述してある各階層毎のレベルと比較して大きい場合は書き換える。この例では、第二階層の階層レベル３が大きな値であり３に書き換わっている。
Ｈ．同様に、キャッシュデータ管理テーブルへ符号列の最高階層レベルを書き込む。各階層ごと最高階層レベルをもつように階層データテーブルを作成する。
このような部分符号データに含まれる符号列から符号データの構造が推定できる。上に示したように、本推定方式によれば、構造情報の順次更新する機能を有する。

図１０は、キャッシュ更新生成処理概略フローチャートである。ここでは、符号データの構造を推定する部分を含んでおり、符号列の各階層ごとの階層レベルを調べ、その最大値を、符号データのその階層の階層レベルの最大値であると推定する。
図１０に示すように、部分符号データに含まれる符号列の階層レベルを抽出し（Ｓ１１）、キャッシュデータ管理テーブルへ符号列の最高階層レベルを書き込んだ（Ｓ１２）後、構造テーブルの更新（Ｓ１３）及び符号データの書き込みを行い（Ｓ１４）、処理を終了する。

図３は、構造データ管理テーブルの構成例である。特徴的なところは、キャッシュの符号列を管理するために、キャッシュ管理部１０８には、符号データ解析部１０１０、管理テーブル構造テーブル生成処理部１０１１、同変更処理部１０１２、同参照処理部１０１３、符号データ保存処理部１０１４、を備えている。
符号データ解析部１０１０では、符号データを解析し、構造を推定するために必要な各符号列の情報（階層数と各階層ごとのその符号列の属するレベル）を抽出する。管理テーブル構造テーブル生成処理部１０１１では、図９で説明したように、各符号列の情報（部分符号データに含まれる符号列の階層レベル）に基づき管理テーブルと構造テーブルとを生成する。このとき、符号列は符号データ保存処理部１０１４で保存する。

図１１は、キャッシュ管理処理フローチャートである。ここでは、キャッシュ更新生成要求処理１０１１、キャッシュ構造変更処理１０１２、追加保存要求処理１０１１、参照要求処理１０１３を含む。
図１１に示すように、まず、クライアントによりキャッシュ管理処理が開始されると（Ｓ２０）、キャッシュ管理要求解析が行われ（Ｓ２１）、キャッシュ更新処理の要求があった場合（Ｓ２２）、キャッシュ更新生成要求処理が行われて（Ｓ２３）終了する。次に、キャッシュ構造変更の要求があったの場合（Ｓ２４）、符号データの最上位階層レベルの使用頻度に基づき、最も使用頻度の多い階層レベルを算出し（Ｓ２５）、キャッシュ又は外部記憶装置の構造データを変更し（Ｓ２６）、復号処理の許容プログレッションに対応するように構造データを変更して（Ｓ２７）、処理を終了する。次に、追加保存の要求があった場合（Ｓ２８）、構造データに基づいて追加符号データの保存位置を特定し（Ｓ２９）、符号データを保存して（Ｓ３０）、処理を終了する。次に、参照要求があった場合（Ｓ３１）、構造データに基づいて符号データの範囲の符号データを参照し（Ｓ３２）、処理を終了する。

次に、キャッシュデータの構造管理について説明する。
本発明の特徴の１つは、符号データの階層構造を推定し、キャッシュ管理テーブル、構造テーブルを生成することである。
図１２は、キャッシュデータ（符号列構造）管理のためのデータ構造の基本構成図である。キャッシュデータ（符号列構造）管理のためのデータ構造は、管理テーブルと構造テーブルと符号列保存部よりなる。本実施例では、構造テーブルは表形成であるが、後述する別の実施例（図１５）ではツリー構造をもっている。管理テーブルは、符号データ名（ファイル名）、階層数、各階層毎の階層レベル数（階層レベルの最大値）、構造データへのアドレス（ポインタ）により構成されている。階層数により階層レベル数の項目の数が変更される。
構造テーブルは、階層レベル数の各階層分の組み合わせの全ての項目を含む。符号列の属する各階層の階層レベルに該当する符号データへのポインタの部分に該符号列が保存されている。

図１３は、別のデータ構造の基本構成図である。管理テーブルとしてファイル（符号データ）が、サブファイル（サブ符号データ）により構成されるような場合である。
全体の文書画像に絵柄などの画像データが組み込んであるような構造化文書画像の符号化などで、符号データもこのような階層構造を持たせる場合がある。このような場合にあっては、キャッシュを管理するためのデータ構造も、本実施例のように、符号データの階層関係にしたがって管理テーブルも階層構造をもたせて実現する。それぞれのサブファイルが、それぞれ独立の構造テーブルをもたせることで、符号列間の関係（構造）が管理でき、構造化文書画像にも対応することができる。

図１４は、キャッシュデータの構造化処理フローチャートである。
図１４に示すように、まず、クライアントによりキャッシュデータの更新生成処理１が開始されると（Ｓ４０）、対象符号データの符号列を順次取り出し（Ｓ４１）、全ての符号列を終了すると（Ｓ４２）、Ｓ４３へ進む。次に、部分符号データに含む符号列の階層レベルを抽出し符号データの各階層の最高階層レベル番号を算出し（Ｓ４３）、各階層の最高階層レベルを持つ全ての階層レベルの組み合わせパターンをもつ構造テーブルを作成する（Ｓ４５）。次に、対象符号データの符号列を順次取り出し（Ｓ４３）、全ての符号列終了し（Ｓ４７）、該符号列を保存し（Ｓ４８）、符号列の階層レベルを調べ、構造テーブルの該階層レベルの符号列へのポインタに符号列のアドレスを書込み（Ｓ４９）、処理を終了する。
なお、キャッシュデータの更新生成処理の場合に、上記図１２、図１３などのデータ構造を生成し、キャッシュ上に符号列を順次保存する。すなわち、本発明の特徴の１つは、キャッシュに符号列を保存する前段階で前述した構造の推定をするところである。
このような処理により、推定機能により推定した階層構造に基づいて保存する階層符号データを構成する符号列（パケット）を管理する手段を提供することができる。

次に、キャッシュモデルのアクセス単位を階層符号データの階層単位とするデータ構造について説明する。
図１５は、ツリー構造のキャッシュ管理テーブル、構造テーブルの基本構成図である。このツリー構造は、前述した図１２、図１３のテーブル構造とは互換性がある。すなわち、テーブル構造は、ツリー構造へ変換することも、逆も任意に変更することができる。ツリー構造をもつ構造テーブルは、階層ノードにより構成されている。各階層ノードは、階層レベルＮｏと下位階層レベルへの全てのポインタと情報項目より構成されている。最下位の階層では、各階層ノードは階層レベルＮｏと符号列へのポインタ格納領域をもっている。下位階層レベルへの全てのポインタはもっていない。また、符号列がない場合は、該ポインタ格納領域はＮＵＬＬになっている。
本実施形態では、管理テーブルには、次の最上位の階層の階層ノードへのポインタをもっている。係る最上位の階層の階層ノードへのポインタをもつ特別な階層ノードを設け、管理テーブルがその特別な階層ノードへのポインタをもつような構成であってもかまわないが、本実施例の方が、符号列を参照する場合に特別な余分な階層ノードが存在しない分高速に実現できる。

図１６は、別のキャッシュデータの構造化処理フローチャートである。
図１６に示すように、まず、クライアントによりキャッシュデータの更新生成処理２が開始されると（Ｓ５０）、対象符号データの符号列を順次取り出し（Ｓ５１）、全ての符号列を終了してＳ５３へ進む。次に、部分符号データに含まれる符号列の階層レベルを抽出し符号データの各階層の最高階層レベル番号を算出し（Ｓ５４）、各階層の最高階層レベルを持つ全ての階層レベルの組み合わせパターンをもつ構造テーブル作成する（Ｓ５５）。
次に、構造テーブルへ符号列へのポインタの書き込みを行い（Ｓ５３）、キャッシュデータ管理テーブル上の各階層のレベル数を読み込み（Ｓ５３−１）、前記レベル数をもつ階層ノードデータを作成する（Ｓ５３−２）。ここで、階層ノードデータは、（i）階層レベルＮｏ、（ii）下位階層の階層ノードデータへのポインタ、（iii）下位階層データ有無フラグ項目よりなる）。

次に、各階層ノードデータの（i）階層レベルＮｏを記載し（Ｓ５３−３）、各階層ノードデータの（ii）下位階層の階層ノードデータへのポインタを記載する（Ｓ５３−４）。この時、最下位階層ノードデータの（ii）下位階層の階層ノードデータへのポインタの初期値はＮＵＬＬとしておく。また、（iii）下位階層データ有無フラグは０とする。
次に、保存対象とする符号列毎に順次以下の処理をする（Ｓ５３−５）。
すなわち、符号列を保存し（Ｓ５３−５−１）、階層ノードデータを上位階層から下位階層へと辿りながら、その符号列の各階層レベルで（i）階層レベルＮｏと一致する最下位の階層ノードデータを探し、該最下位の階層ノードデータの（ii）下位階層の階層ノードデータへのポインタ先を、符号列が保存されているアドレスとする（Ｓ５３−５−２）。この時、上位階層の階層ノードデータから（ii）下位階層の階層ノードデータへのポインタ先を辿っていった時の階層レベルＮｏが、その符号の階層レベルであるようになっている。
次に、階層ノードデータを上位階層から下位階層へと辿りながら、該最下位の階層ノードデータの（ii）下位階層の階層ノードデータへのポインタを書き込む時に、辿られた階層ノードデータの（iii）下位階層データ有無フラグを＋１する（Ｓ５３−５−３）。

図１６のキャッシュデータの生成処理において、図１５に記載のツリー構造をもつ構造テーブルを生成する処理例を示す。各階層ノードは、情報項目をもつが、図１５では、下位階層の符号列の有無を示す。符号列を保存するときに、その符号列の属する階層レベルにあたる階層ノードの同項目の値をカウントアップすることによって生成する。各階層毎にそれ以下の階層に符号データを有するかどうかを判別する識別子を使用することによって、構造データを辿ることで上位階層を調べるだけで、それ以下の階層に符号データがないことが判別できるので、階層構造データで参照される符号データの高速な参照が容易にできる。階層構造データの効率的な参照が可能となる。

ところで、図１５あるいは、図１２、図１３で示した構造データを使用することによって、ある階層レベルに属する符号列を参照することは容易である。符号列に対応してそれの属する階層レベルを知ることが容易であり、かつ、階層毎に階層レベルによって体系化された形式で保存されているからである。例えば、最上位階層の階層レベルが１である符号データは、符号データに対応した同階層の階層レベルが１である符号列を探せばよいが、図１２、図１３のテーブルタイプの構造データにおいては、連続的に並んでいるため参照は高速にできる。一方、図１５の構造データにおいては、階層ノードの該当する階層の階層レベル番号が１である階層ノードから下位階層ノードへのポインタをたどっていくことで該符号列を参照できる。
このような構造データの調整により、保存される符号化データの符号列の制御単位を部分符号データのアクセス単位とすることができる。部分符号データのアクセス効率を高められる。
また、要求している符号データの中に、クライアントのキャッシュ上にない符号列が存在する場合には、欠落符号列の再送を要求する。

次に、欠落符号列の処理について説明する。
図１７は、図１５記載のツリー構造をもつ構造テーブルを解析して、欠落符号列を判別処理する処理フローチャートである。このようにして、階層符号化された符号データの部分符号データの中で欠けている符号列を算出できる。
図１７に示すように、まず、クライアントにより欠落符号列の判別処理が開始されると（Ｓ６０）、キャッシュデータ管理テーブル上の各階層のレベル数を読み込む（Ｓ６１）。ここで、下からｍ番目の階層でＤ（ｍ）個のレベル数とし、ｍ＝１〜Ｎとし、Ｎはキャッシュデータ管理テーブル上の階層数とする。

次に、指定の階層レベルＳの階層ノードデータを上位階層から下位階層へと辿りながら（Ｓ６２）、Ｍ番目の階層の階層ノードデータの（ｉｉｉ）下位階層データ有無フラグの値Ｐについて、Ｐ＜Ｄ（１）×Ｄ（２）…×Ｄ（Ｍ−１）で（Ｓ６２−１）、指定の階層レベルＳを構成する符号列には欠落符号列を含んでいる場合は、終了し、それ以外の場合は、指定の階層レベルＳを構成する符号列には欠落符号列を含んでいない（Ｓ６２−２）。
なお、サーバクライアントシステムにおいては、例えば、クライアントは、サーバから、階層符号データの部分符号データを受信し、上記手段によって受信された部分符号データの欠落符号列を算出し、前記欠落符号列を含む部分符号データを受信する。

図１８は、キャッシュ管理に係る処理フローチャートである。
図１８に示すように、まず、クライアントによりキャッシュ管理に係る処理が開始されると（Ｓ７０）、処理要求待ちとなり（Ｓ７１）、キャッシュ管理要求を受信すると（Ｓ７２）、キャッシュ管理処理へ移り（Ｓ７３）、復号出力処理要求を受信すると（Ｓ７４）、復号出力処理要求処理へ移り（Ｓ７５）、終了要求を受信すると（Ｓ７６）、終了する。
ところで、先に説明したように、本発明の構造データを使用して符号列を参照する実施例においては、特定の階層のあるレベルを構成符号列を特定することが容易に実現でき、上記欠落符号列を含むかどうかの判定方法を使用して、特定の階層の符号データが全て揃っている（キャッシュ上にある）かどうかの判別が容易にできる。そこで、クライアントは、特定の階層の符号データが全て揃っていない場合にその符号列を全てロードすることもできる。まとめて使用される可能性の高い符号列を入手する手段を提供し、利用価値を高められる。
ところで、クライアントにおける欠落符号列のロードは、使用者からの部分符号データのロード要求時だけで実行するに限らず、処理のバックグラウンドで実行することもできる。

図１９は、バックグランドキャッシュ処理フローチャートである。
図１９に示すように、まず、クライアントによりバックグランドキャッシュ処理が開始されると（Ｓ８０）、処理要求待ちとなり（Ｓ８１）、復号出力処理要求を受信すると（Ｓ８２）、復号出力処理要求処理となり（Ｓ８３）、終了要求を受信すると（Ｓ８４）、終了する。
次に、キャッシュ構造変更処理要求がなされると（Ｓ８５）、欠落符号列の把握がなされ（Ｓ８６）、欠落符号列を含む部分符号データをアップロードし（Ｓ８７）、追加保存要求処理要求がなされる（Ｓ８８）。
次に、キャッシュデータの構造の入れ替え制御について説明する。
階層符号データのプログレッションの使用頻度を利用することで、階層毎の重要度を推定する。一般に使用者は、階層符号データを使用する場合にあって、重要な階層要素を上位レベルの階層とするプログレッションをもつ符号データを使用する場合が多いことに基づく。本発明の一実施例では、階層毎の重要度に合わせて本発明のキャッシュデータの構造データを最頻度のプログレッションをもつように置き換えておくことで、参照頻度の高い部分符号データのロード要求の処理が実現できる。効率的なキャッシュ管理を実現する。

図２０は、使用頻度により階層レベルの重要度によってキャッシュ管理する場合のクライアントサーバシステムの構成例を示す図である。キャッシュ管理部１０８に階層別使用頻度設定処理部１０１５があることが特徴的である。階層別使用頻度設定処理部１０１５では、高頻度に使用されている符号データのプログレッションを反映して、符号データの階層毎の重要順を設定している。
図２１に示すように、管理テーブルに階層毎の重要度データを保存している。階層毎の重要順は、使用頻度等重要度によって設定する。
図１１の処理フローでは、階層毎の使用頻度によって、必要であれば、構造データの変更を加えキャッシュ上の符号列の参照範囲を調整する。使用時の階層の重要性に基づいて符号データをロードする手段を提供する。

図２２は、キャッシュ上の符号データのプログレッションオーダの変更をする方法を説明するための概念図である。構造テーブルしては、図１２で説明したテーブルタイプのものを示すが、図１５で示したツリータイプのものであっても同様である。互いに相互変換可能であるからである。構造テーブルの入れ替えとしては、階層レベルＮｏの記載された行の値によって列単位の順番を入れ替えることで実現する。すなわち、最上位の階層の階層レベル順に列単位のデータを並びかえ、続いて、次の階層の階層レベル順を上位階層のレベル順が損なわないように並び替え、続いて、同様な並び替えを下階層の階層レベルまで繰り返して処理する。
ところで、別実施形態として、階層構造化して保存した階層符号データを管理するか、階層構造化しないで保存した階層符号データを管理するかを、階層符号データの使用頻度により制御することもできる。

図２０では、階層別使用頻度設定処理部１０１５で、符号データのプログレッションオーダの使用頻度を算出することを説明したが、同時に、階層符号データであるかないかの使用頻度を集計することによって、簡単に実現できる。階層符号データが使用される頻度が多い場合にのみ本発明の保存符号データ構造を階層構造化して制御することで、処理パフォーマンスを高めることができる。
以上、キャッシュデータに存在しない符号データの送信要求をする応用実施例を中心に説明したが、本発明の構造データを使用することによって符号列の順番を簡単に置き換えることができるため、デコーダで許されるプログレッションオーダになるように符号列の順番を調整することもできる。

クライアント及びサーバ間で符号データを通信するネットワーク環境におけるクライアントサーバモデルの一実施形態のブロック構成図である。 キャッシュを持ったクライアントサーバモデルのブロック構成図である。 図１に示したキャッシュ管理部１０８の詳細を示したブロック構成図である。 典型的なクライアントサーバネットワークモデルのブロック図である。 ＪＰＩＰを使用した場合の出力表示画面例を示す説明図である。 ＪＰＥＧ２０００のコード・ストリームのフォーマットの概略構成を示す説明図である。 ＪＰＥＧ２０００のコード・ストリームの一例を示す図である。 典型的なキャッシュ管理に係る処理フローチャートである。 断片的な符号列（パケット）群より構造を把握する概念図である。 キャッシュ更新生成処理概略フローチャートである。 キャッシュ管理処理フローチャートである。 キャッシュデータ（符号列構造）管理のためのデータ構造の基本構成図である。 別のデータ構造の基本構成図である。 キャッシュデータの構造化処理フローチャートである。 ツリー構造のキャッシュ管理テーブル、構造テーブルの基本構成図である。 別のキャッシュデータの構造化処理フローチャートである。 図１５記載のツリー構造をもつ構造テーブルを解析して、欠落符号列を判別処理する処理フローチャートである。 キャッシュ管理に係る処理フローチャートである。 バックグランドキャッシュ処理フローチャートである。 使用頻度により階層レベルの重要度によってキャッシュ管理する場合のクライアントサーバシステムの構成例を示す図である。 使用頻度等重要度に基づいた保存符号データの構造切り替えの概念図である。 キャッシュ上の符号データのプログレッションオーダの変更をする方法を説明するための概念図である。 プレシンクトデータビンとメッセージとの関係を示す図である。 プレシンクトデータビンの一例を示す図である。 ＪＰＥＧ２０００の基本となる階層符号化アルゴリズムの説明図である。 ブロック・ベースでのＤＷＴにおけるオクターブ分割に対応した任意の階層（デコンポジション・レベル）で、静止画像の圧縮伸長動作を自由に停止させる動作説明図である。 原画像の各コンポーネント（ここではＲＧＢ原色系）が、矩形をした領域（タイル）によって分割された場合の説明図である。 一つのプレシンクトが空間的に一致した３つの矩形領域からなっている場合の説明図である。 コード・ストリームの構造を示した図である。

符号の説明

１０１…クライアント、１０２…サーバ、１０３…キャッシュ、１０６…キャッシュモデル、１０８…キャッシュ管理部、１１０…要求、１１１…応答、２０１、２０２…クライアント、２０３…サーバ、２５０…ネットワーク、１０１０…符号データ解析部、１０１１…キャッシュ更新生成要求処理、１０１１…管理テーブル構造テーブル生成処理部、１０１１…追加保存要求処理、１０１２…キャッシュ構造変更処理、１０１２…同変更処理部、１０１３…参照要求処理、１０１３…同参照処理部、１０１４…符号データ保存処理部、１０１５…階層別使用頻度設定処理部

Claims (6)

1. 部分符号データを通信回線を介してロードする画像処理装置であって、
   前記部分符号データに含まれる符号列が、タイル、コンポーネント、位置、及び解像度を階層として、該階層のどのレベルのデータであるかを符号列毎に抽出する抽出手段と、
   前記抽出手段で抽出した符号列毎の階層レベルに基づき、符号列毎の階層レベルを推定する階層レベル推定手段と、
   前記推定手段で推定した符号列毎の最高階層レベルを管理テーブルに書き込む書込手段と、
   前記推定手段で推定した最高階層レベルを、各階層ごとに最高階層レベルをもつように階層データテーブルを作成する作成手段と、
   を有し、
   前記書込手段は、
   前記管理テーブルに記述してある各階層毎のレベルと、新たに受信した部分符号データに含まれる符号列毎の階層レベルとを比較し、前記管理テーブルに書き込まれている符号列毎の階層レベルより前記新たに受信した部分符号データに含まれる符号列毎の各階層レベルが大きい場合、前記新たに受信した部分符号データに含まれる符号列毎の階層レベルを前記管理テーブルに書き換えることを特徴とする画像処理装置。
2. 前記部分符号データは、ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリームであることを特徴とする請求項１に記載の画像処理装置。
3. 前記階層レベル抽出手段は、
   前記ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリームである場合は、夫々のストリームを参照することで階層レベルを算出することを特徴とする請求項２に記載の画像処理装置。
4. 部分符号データを通信回線を介してロードする画像処理方法であって、
   前記部分符号データに含まれる符号列が、タイル、コンポーネント、位置、及び解像度を階層として、該階層のどのレベルのデータであるかを符号列毎に抽出する抽出工程と、
   前記抽出手段で抽出した符号列毎の階層レベルに基づき、符号列毎の階層レベルを推定する推定工程と、
   前記推定工程で推定した符号列毎の最高階層レベルを管理テーブルに書き込む書込手段と、
   前記推定工程で推定した最高階層レベルを、各階層ごとに最高階層レベルをもつように階層データテーブルを作成する作成工程と、
   を有し、
   前記書込工程は、
   前記管理テーブルに記述してある各階層毎のレベルと、新たに受信した部分符号データに含まれる符号列毎の階層レベルとを比較し、前記管理テーブルに書き込まれている符号列毎の階層レベルより前記新たに受信した部分符号データに含まれる符号列毎の各階層レベルが大きい場合、前記新たに受信した部分符号データに含まれる符号列毎の階層レベルを前記管理テーブルに書き換えることを特徴とする画像処理方法。
5. 前記部分符号データは、ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリームであることを特徴とする請求項４に記載の画像処理方法。
6. 前記抽出工程は、
   前記ＪＰＥＧ２０００のコード・ストリーム又はＪＰＩＰのストリームである場合は、夫々のストリームを参照することで階層レベルを算出することを特徴とする請求項５に記載の画像処理方法。

Images