(57)【要約】【課題】メモリ容量が小さい端末では、画像を閲覧している途中にメモリ容量をオーバーし、ユーザの要求に応じた表示が不可能になってしまう。【解決手段】符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、画像の注目領域が変更されることにより、画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えると判定されると、キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求め（Ｓ２１）、その画像データに含まれるメタデータが付与されている画像領域を特定し（Ｓ２３）、注目領域とメタデータが付与されている画像領域とに基づいて、キャッシュデータから削除するデータ領域を単位領域を単位として決定し（Ｓ２４）、その削除すべきデータ領域に含まれるキャッシュデータを削除する（Ｓ２７）。【選択図】　図１２
2004145759.tif 000002
【特許請求の範囲】
【請求項１】
符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、
を有することを特徴とする画像処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばサーバからの符号化データされた画像データをクライアントで断片的に受信してキャッシュして表示する技術に関するものである。
【０００２】
【従来技術】
インターネット上でＷＷＷサーバにＷｅｂブラウザからアクセスして、文書データや画像データ等を閲覧することが盛んに行われている。この仕組みは、インターネット上に情報を公開するＷＷＷサーバと、その情報を閲覧する複数のクライアントがあり、各クライアントはＷｅｂブラウザを使用して、そのサーバの情報を閲覧するものである。このＷＷＷサーバは、ホームページ（Ｈｏｍｅ　Ｐａｇｅ）といわれる公開したい情報をＨＴＭＬで記述した文書を有しており、それをクライアント側のＷｅｂブラウザが取り込んで、クライアントコンピュータに表示する。クライアント側のＷｅｂブラウザは、表示しているページ内のリンクを辿って行き、自分が必要な情報を得ることができる。
【０００３】
更に、Ｗｅｂサーバが管理しているファイルをダウンロードする方法として、Ｆｉｌｅ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ　（以下、ＦＴＰと略す）という方法がある。このＦＴＰは、ネットワークを通して、サーバ上にあるファイルを１度にクライアントコンピュータに転送する仕組みである。
【０００４】
また画像データファイルへ断片的にアクセスして表示するためのプロトコルとして、Ｆｌａｓｈｐｉｘ／ＩＩＰがある。このＩＩＰは、Ｆｌａｓｈｐｉｘという画像データファイルフォーマットに最適なプロトコルになっており、画像データの部分アクセスの単位はＦｌａｓｈｐｉｘのタイル単位に行うものである。
【０００５】
一方、このＩＩＰをそのままＪＰＥＧ２０００に適用した場合、ＪＰＥＧ２０００の各スケーラビリティの符号化データは、そのスケーラビリティより１つ下のスケーラビリティのデータからの差分データであるため、クライアント側で受信した断片的な符号化データをキャッシュしておく必要がある。
【０００６】
【発明が解決しようとする課題】
しかし、断片的な符号化データをクライアント側で全て保存すると、最終的にクライアントが最高解像度、最高ＳＮＲで画像全体をブラウズした場合に、サーバのＪＰＥＧ２０００ビットストリームの全データがクライアントにキャッシュされることになる。このことは、メモリ容量が小さい端末では、画像を閲覧している途中にメモリ容量をオーバーし、ユーザの要求に応じた表示が不可能になってしまうという問題がある。更に、ＪＰＥＧ２０００は差分データであるので、メモリ容量が飽和し、新たに受信したデータが既にキャッシュされていたデータに上書きされるようなことが生じると、正確な画像表示（ユーザが望む表示）ができなることも起こり得る。
【０００７】
本発明は上記従来例に鑑みてなされたもので、キャッシュしている符号化された画像データの内、再生画像に影響の少ないキャッシュデータを削除してキャッシュにおけるデータのオーバフローを防止しながらユーザの要求に応じた表示を行うようにすることを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために本発明の画像処理方法は以下のような工程を備える。即ち、
符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、を有することを特徴とする。
【０００９】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【００１０】
［実施の形態１］
図１は、本実施の形態に係るクライアントやサーバの構成を説明するブロック図で、この装置は例えばパーソナルコンピュータやワークステーション等で構成されていてもよい。
【００１１】
ＣＰＵ１０１は、システム全体の動作を制御しており、一次記憶１０２に格納されたプログラムに基づいて各種制御動作を実行する。一次記憶１０２は主にメモリ（ＲＡＭ）であり、二次記憶１０３に記憶されたプログラムなどを読み込んで格納する。二次記憶１０３は、例えばハードディスクなどがこれに該当する。一般に一次記憶１０２の容量は二次記憶１０３の容量よりも小さく、一次記憶１０２に格納しきれないプログラムやデータなどは二次記憶１０３に格納される。また、長時間記憶しなければならないデータなども二次記憶１０３に格納される。本実施の形態では、プログラムを二次記憶１０３に格納しておき、そのプログラム実行時に一次記憶１０２に読み込んで格納し、その一次記憶１０２に記憶されているプログラムに従ってＣＰＵ１０１が処理を行う。入力デバイス１０４は、例えば、マウスやキーボードなどがこれに該当し、入力デバイス１０４が操作されることにより、プログラムなどに割り込み信号を発生して、所望のデータの入力を行うのに使用される。出力デバイス１０５は、例えば、モニタやプリンタなどが考えられる。この装置の構成方法は他にも様々な形態が考えられるが、本発明の主眼ではないので、それらの説明を省略する。
【００１２】
図２は、本実施の形態に係るネットワークの概略を説明する図である。
【００１３】
図において、２０１，２０２はそれぞれユーザ（クライアント）を示しており、図１で説明した装置構成を有する。ユーザ２０１或いは２０２は、有線、無線を問わず、ネットワーク２０３を介してサーバ２０４と通信することが可能である。サーバ２０４は、図１の構成を有し、二次記憶１０３に相当する画像ファイルを蓄積する大容量の記憶装置（ハードディスク）２０５を備えている。大容量の記憶装置２０５は、例えばハードディスクなどがこれに該当する。このハードディスクには、ＪＰＥＧ２０００符号化方式により符号化された画像データが数多く格納されている。ユーザ２０１，２０２は、サーバ２０４が格納しているＪＰＥＧ２０００画像データから、断片化されたデータを受信して保存する。
【００１４】
本実施の形態では、既に生成済みのＪＰＥＧ２０００ファイルのデータを断片的に受信し、それらをキャッシュしたクライアントが、それらキャッシュデータを削除する方法について説明する。
【００１５】
各ユーザは、Ｗｉｎｄｏｗｓ（登録商標）マシンを使用してホームページを開いて、そこに書かれているＪＰＥＧ２０００の画像へのリンクをクリック（指示）することで、ＪＰＥＧ２０００の画像をユーザの用途に適した画像サイズや解像度で表示するために必要な断片的なデータを取得し、それらのデータをキャッシュする。そして、ユーザのキャッシュ容量の制限値を越えると、キャッシュマネージャのような働きを持つプログラムが動き、ユーザのキャッシュデータを削除する場合を想定する。
【００１６】
図３は、一般的なＪＰＥＧ２０００の符号化データを説明する図で、Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ　ｐｒｏｇｒｅｓｓｉｏｎ（以下、ＬＲＣＰと記す）に沿って記録されたＪＰＥＧ２０００ファイルの構成を示している。このＬＲＣＰに準じた場合、ｌａｙｅｒ　／　ｒｅｓｏｌｕｔｉｏｎ　／　ｃｏｍｐｏｎｅｎｔ　／　ｐｏｓｉｔｉｏｎの順に記録される。このようなデータの並び方はｐｒｏｇｒｅｓｓｉｏｎ　ｏｒｄｅｒと呼ばれる。
【００１７】
図４は、ＪＰＥＧ２０００の符号化データにおける解像度（画像サイズ）とＲｅｓｏｌｕｔｉｏｎ番号との関係を示す図である。
【００１８】
最も小さい解像度の画像のｒｅｓｏｌｕｔｉｏｎ番号を「０」とし、ｒｅｓｏｌｕｔｉｏｎ番号が一つ増加するごとに画像の幅と高さが２倍になっていく。また、各ｌａｙｅｒ内は、ｒｅｓｏｌｕｔｉｏｎ番号の小さい順にデータが格納されている。Ｌａｙｅｒ番号は復元する画像の原画に対するＳ／Ｎ比に対応し、ｌａｙｅｒ番号が小さいほどＳ／Ｎ比が悪くなる。一つのＪＰＥＧ２０００ファイル内でのｒｅｓｏｌｕｔｉｏｎ番号とｌａｙｅｒ番号、ｃｏｍｐｏｎｅｎｔ番号の最大値は、エンコーダによって予め設定され、そのパラメータに従ってエンコードされており、その情報は符号化データの中に格納されている。各パケット（パケット）は、そのパケット内に格納されているコードブロック（ｃｏｄｅ−ｂｌｏｃｋ）の情報を管理しているパケットヘッダ部と、各ｃｏｄｅ−ｂｌｏｃｋの符号化データを含んでいる。
【００１９】
このようなＪＰＥＧ２０００符号化データを使えば、各ユーザは、サーバ２０４にある全ての画像データを取得しなくても、必要な部分のデータのみをサーバ２０４から受信することが可能である。ユーザの受信データの単位としては、ＪＰＥＧ２０００のパケット、或いはパケットよりも更に小さい符号化単位であるｃｏｄｅ−ｂｌｏｃｋ単位が考えられる。本実施の形態では、ユーザがサーバ２０４から受信するデータ単位としてパケット単位を想定する。
【００２０】
図５は、パケット単位のリクエストおよびレスポンスの概念図を示す図である。
【００２１】
ユーザ２０１は、サーバ２０４に画像のタイル番号とｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌとｌａｙｅｒ，ｃｏｍｐｏｎｅｎｔ，ｐｏｓｉｔｉｏｎ番号を指定して、データを要求する。これによりサーバ２０４は、画像５０３のコードストリームを解析して、その指定されたタイル番号、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌとｌａｙｅｒ，ｃｏｍｐｏｎｅｎｔ，ｐｏｓｉｔｉｏｎ番号に相当するパケットデータを抜き出してユーザ２０１に送り返す。
【００２２】
本実施の形態では、サーバ２０４にあるオリジナル画像は、最大解像度サイズ２０４８×２０４８［画素］、８×８からなる６４枚のタイル（Ｔｉｌｅｓ）に分割されており、ｃｏｍｐｏｎｅｎｔ数が「３」で、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０　〜　３、即ち、４つの画像サイズ方向の階層を持っており、２つのｌａｙｅｒに分けられていると仮定する。
【００２３】
図６は、オリジナル画像の各階層のデータ構造を説明する図である。
【００２４】
図６に示すように、オリジナル画像を構成するそれぞれのタイルには、左上のタイルからシーケンスな番号が振ってある。さらに、オリジナル画像にはメタデータ（ｍｅｔａｄａｔａ）が付加されているものとする。このメタデータは、別ファイルになっていてもよいが、本実施の形態では、説明を簡単にするために、ＪＰＸフアイルで規定されているように、ＸＭＬ　ｂｏｘの中に入っているものとする。従って、サーバ２０４には、図７の７０１で示すようなデータが保存されている。
【００２５】
図７は、サーバ２０４で管理されているＪＰＥＧ２０００符号化データの構成を説明する図で、７０３はメインヘッダ、７０２はタイル０の符号化データを示している。７０８は前述したメタデータである。
【００２６】
［タイル単位でのデータの削除］
クライアント（ユーザ）２０１では、サーバ２０４から送られてきた断片的なＪＰＥＧ２０００ビットストリームをキャッシュする。この動作を図８のフローを用いて説明する。
【００２７】
まずステップＳ１で、表示したいＪＰＥＧ２０００画像のメインヘッダ（ｍａｉｎｈｅａｄｅｒ）のデータとメタデータを受信する。ＪＰＸで規定されているメタデータは、図９に示すように、４つの論理的なグループ「Ｉｍａｇｅ　Ｃｒｅａｔｉｏｎ　ｍｅｔａｄａｔａ　ｂｏｘ」９０２，「Ｃｏｎｔｅｎｔ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ　ｂｏｘ」９０３，「Ｈｉｓｔｏｒｙ　ｂｏｘ」９０４，「Ｉｎｔｅｌｌｅｃｔｕａｌ　Ｐｒｏｐｅｒｔｙ　Ｒｉｇｈｔｓ　ｂｏｘ」９０５に分かれている。これら全ての論理グループを含む「ＸＭＬ　ｂｏｘ」９０１を受信しても良いし、或いは、画像の内容について記述されている「Ｃｏｎｔｅｎｔ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ　ｂｏｘ」９０３のみを要求して受信しても良い。次にステップＳ２に進み、受信したメインヘッダ及びメタデータをキャッシュするとともに、それらを解析し、メタデータが記述されている部分領域をタイルを単位として取得する。
【００２８】
図１０（Ａ）（Ｂ）は、メインヘッダの中のＳＩＺマーカの構成を説明する図である。
【００２９】
このメインヘッダの中にあるＳＩＺマーカを解析することで、画像がどのようにタイル分割されているかを知ることができる。これは、メインヘッダのＳＩＺマーカに記されている最高解像度の画像サイズを表すパラメータＸｓｉｚ（１００１），Ｙｓｉｚ（１００２）及び、最高解像度時のタイルサイズを表すパラメータＸＴｓｉｚ（１００３），ＹＴｓｉｚ（１００４）に基づいて計算できる。
【００３０】
本実施の形態では、図６に示すように、２０４８×２０４８［画素］の画像を２５６×２５６［画素］のタイルに分割しているので、横方向に２０４８÷２５６＝８［タイル］、縦方向にも同様に２０４８÷２５６＝８［タイル］が並んでいると計算される。また、メタデータの「Ｃｏｎｔｅｎｔ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ　ｂｏｘ」９０３にある「ＰＥＲＳＯＮ」，「ＴＨＩＮＧ」，「ＯＲＧＡＮＩＺＡＴＩＯＮ」タグを解析することで、画像のどの位置にメタデータが書き込まれているかを知ることができる。
【００３１】
図１１は、「Ｐｅｒｓｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ」と「Ｐｏｓｉｔｉｏｎ　ｔｙｐｅ」のスキーマを説明する図である。
【００３２】
本実施の形態では、簡単のために、「ＰＥＲＳＯＮ」タグのみが使用されており、その中に「ＰＯＳＩＴＩＯＮ」タグが使用されており、更に、「ＰＯＳＩＴＩＯＮ」タグの中では「ＰＯＩＮＴ」タグにより、点が指定されていたとする。「ＰＥＲＳＯＮ」タグの定義及び「ＰＯＳＩＴＩＯＮ」タグで使われている「Ｐｏｓｉｔｉｏｎ　ｔｙｐｅ」のスキーマを図１１の１１０１，１１０２にそれぞれ示す。
【００３３】
例えば、メタデータの付与されているポイントとして、ｘ座標が「０．７」、ｙ座標が「０．１」となっている場合、最高解像度において座標をピクセル値で求めると、ｘ座標として（０．７×２０４８＝）「１４３４」、ｙ座標として（０．１×２０４８＝）「２０５」と求められる。従って、これをタイルに当てはめると、ｘ座標÷タイルの幅＝１４３４÷２５６＝５．６より６列目、ｙ座標÷タイルの高さ＝２０５÷２５６＝０．８より１行目となり、図６の６０１で示されるタイル５にメタデータが付与されていると判定できる。従って、タイル５がメタデータ領域Ｐとして特定される。
【００３４】
本実施の形態では、「ＰＯＳＩＴＩＯＮ」タグは、「ＰＯＩＮＴ」タグを使ってメタデータが付与されている領域が示されているが、「ＰＯＩＮＴ」タグの代わりに「ＲＥＣＴ」タグ或いは「ＲＥＧＩＯＮ」タグが用いられた場合は、それによって特定される領域を含むタイルの全てがメタデータ領域Ｐとして特定される。
【００３５】
次にステップＳ３に進み、ユーザ２０１のメモリ容量を取得し、キャッシュデータの削除が必要か否かを判断するスレッショルド値を決める。受信したＪＰＥＧ２０００のパケットデータをキャッシュするために、利用可能なメモリ容量の１００％を充てるのであれば、スレッショルド値はメモリ容量と等しくなる。しかし、ＪＰＥＧ２０００の断片的に受信したビットストリーム以外のデータ（例えば、画像のメタ情報など）も同じメモリ容量の中に保存する場合には、利用可能なメモリ容量の一部がＪＰＥＧ２０００符号データのキャッシュに利用される。また或いは、同じシステムで複数のＪＰＥＧ２０００符号データをキャッシュする場合には、ある画像に利用できるメモリ容量のスレッショルド値は、使用可能なメモリ容量よりも小さな値に設定される。例えば、メモリ容量が３Ｍ［バイト］に対して、この画像のキャッシュのスレッショルド値として２Ｍ［バイト］の値が設定される。キャッシュのスレッショルド値を決める場合、ハードディスクなどの２次記憶媒体でも良いが、本実施の形態では、説明を簡単にするためにメモリサイズを基準としてスレッショルド値を決めるものとする。
【００３６】
ステップＳ４では、ユーザ２０１の望む条件で表示するために必要なパケットデータをサーバ２０４に要求する。ステップＳ５では、サーバ２０４から受信する断片化されたＪＰＥＧ２０００符号データのバイト数Ｘを取得する。次にステップＳ６に進み、ステップＳ４で取得した受信データのバイト数Ｘ分のデータをキャッシュすると、ステップＳ３で決定されたスレッショルド値を越えてしまうか判断する。つまり、スレッショルドの値から現在キャッシュされているデータ量を引いた値よりも、ステップＳ５で得られた値が大きければスレッショルド値を越えると判断し、ステップＳ５で得られた値が小さければスレッショルド値を越えないと判断する。こうしてステップＳ６で、スレッショルド値を越えると判断した場合はステップＳ７へ進み、越えないと判断した場合ステップＳ８へ進む。
【００３７】
例えば、ステップＳ３で決定されたスレッショルド値が２Ｍ［バイト］で、既にキャッシュされているＪＰＥＧ２０００のパケットデータ量が１．９５Ｍ［バイト］である場合、ステップＳ５で取得した受信データのバイト数Ｘが１２０Ｋ［バイト］であれば、受信データをそのままキャッシュするとスレッショルド値を越えてしまうと判断されてステップＳ７へ進むことになる。ステップＳ７では、ステップＳ５で取得したバイト数Ｘをキャッシュしても、キャッシュ容量がスレッショルド値以下になるように、キャッシュデータの中からタイル（Ｔｉｌｅ）単位でデータを削除する。
【００３８】
例えば、ステップＳ５で取得したバイト数Ｘが１２０Ｋ［バイト］、ステップＳ３で決定されたスレッショルド値が２Ｍ［バイト］であるとき、ステップＳ７では、２Ｍ−１２０Ｋ＝１．８８Ｍ［バイト］以下になるまで、キャッシュデータの削除が行われる。こうしてステップＳ８では、受信したデータをキャッシュする。次にステップＳ９に進み、キャッシュされたデータをデコードして表示する。そしてステップＳ１０に進み、この画像に対する要求が終了したか判断し、要求が終了していなければステップＳ４へ戻り、要求が終了すれば、このデータのキャッシュルーチンを終了する。
【００３９】
図１２は、図８のステップＳ７におけるキャッシュデータの削除処理を説明するフローチャートである。
【００４０】
まずステップＳ２１で、キャッシュから削除すべきデータ量Ｙを取得し、今回のデータ削除フローにおいて削除されたデータ量をカウントする変数Ｄｅｌに「０」を代入して初期化する。
【００４１】
本実施の形態では、ユーザが既に、画像全体をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　１の最大ＳＮＲで表示しており、現在、図６の６０２で示される領域を最大ＳＮＲで、即ち、タイル１６，２１，５６，６１で囲まれる３６枚のタイル領域をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２、最大ＳＮＲで表示していたとする。このとき、キャッシュの中には、画像のヘッダ部分のデータ７０１、全タイルのｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０，ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　１を構成するパケットデータと、領域６０２を構成する３６枚のタイルのｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２を構成するパケットデータが入っている。つまり、タイル１６，２１，５６，６１で囲まれる３６枚のタイルに関しては、図１３（Ｂ）の１３０２に示すように、各タイルのヘッダデータ７０７、各タイルのｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ０を構成するパケット群７０４、および各タイルのｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　１を構成するパケット群７０５と、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２を構成するパケット群７０６が、ユーザ２０１のキャッシュメモリには保存されている。それ以外のタイルに対しては、図１３（Ａ）の１３０１に示すように、１３０２で示すキャッシュデータからｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２を構成するパケット群７０６を除いたパケットデータがキャッシュされている。これらのデータを合わせたサイズが、１．９５Ｍ［バイト］、スレッショルド値が２Ｍ［バイト］、受信したデータ量が１２０Ｋ［バイト］であった場合、削除すべきデータ量ＹはＹ＝１．９５＋０．１２−２．０＝０．０７Ｍ［バイト］＝７０Ｋ［バイト］として取得できる。つまり、７０Ｋ［バイト］以上のデータを削除する必要があり、この値がキャッシュから削除すべきデータ量Ｙとして設定される。
【００４２】
そしてステップＳ２２に進み、今回のデータの受信により、表示している画像のどの部分領域が表示されるのかを把握し、その表示される領域を注目領域Ｆとして特定する。例えば、現在、図６の領域６０２をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２で表示していたユーザが、タイル４２を中心として拡大表示を要求し、領域６０３をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　３で表示することを望んだ場合、注目領域Ｆとしてタイル３３〜３５，４１〜４３，４９〜５１からなる９枚のタイルが注目領域Ｆとして取得される。
【００４３】
次にステップＳ２３に進み、図８のステップＳ２で取得したメタデータが付与されている領域Ｐを取得する。本実施の形態の場合、タイル５のみがメタデータが付与されている領域Ｐに該当するものとする。次にステップＳ２４に進み、ステップＳ２２で取得した注目領域Ｆと、ステップＳ２３で取得したメタデータ領域Ｐを除く領域を、データ削除領域Ｒとして取得する。次にステップＳ２５に進み、ステップＳ２４で取得したデータ削除領域Ｒに含まれるタイルに対して、データを削除する順番を決定する。
【００４４】
例えば、右上のタイルから左方向、および下方向にデータ削除の順番をつける場合、データが削除されるタイルの順番は、メタデータ領域Ｐとしてタイル５が特定されているので、図６において、タイル７、タイル６、タイル４、タイル３、タイル２、タイル１、タイル０、タイル１５、タイル１４、…という順番になる。次にステップＳ２６に進み、データ削除順番をカウントする変数Ｘに「１」を代入する。そしてステップＳ２７に進み、削除順番ＸのタイルＴ＿Ｄｅｌ（Ｘ）のキャッシュデータの中から、タイルヘッダ部分とｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０，ｌａｙｅｒ　１のパケットデータを除く全てのデータを削除する。
【００４５】
例えば、Ｘ＝１でＴ＿Ｄｅｌ（１）＝タイル７であれば、タイル７のキャッシュデータは、図１３（Ａ）の１３０１で示すデータであるので、ｒｅｓｏｌｕｔｉｏｎ　１を構成するパケット群７０５と、ｒｅｓｏｌｕｔｉｏｎ　０，ｌａｙｅｒ　２を構成するパケット群１３０３を削除する。
【００４６】
次にステップＳ２８に進み、この削除データフローで削除したデータ量を更新して保持する変数Ｄｅｌに、ステップＳ２７で削除したデータ量を足す。そしてステップＳ２９に進み、この削除フローで削除されたデータサイズＤｅｌと、このデータ削除フローで削除すべきデータ量Ｙとを比較し、実際に削除したデータ量Ｄｅｌが削除すべきデータ量Ｙを越えたら、このフローを終了する。まだ、越えていない場合にはステップＳ３０に進み、データ削除順番をカウントする変数Ｘを１つインクリメントし、次のデータ削除順番に該当するタイルのキャッシュデータを削除するためにステップＳ２７へ戻る。
【００４７】
いま例えば、削除すべきデータ量Ｙが７０Ｋ［バイト］、削除番号１のタイルＴ＿Ｄｅｌ（１）で削除したデータ量が５０Ｋ［バイト］である場合、ステップＳ２８において、Ｄｅｌの値が５０Ｋ［バイト］になるため、ステップＳ２９では、Ｙ＝７０Ｋ＞Ｄｅｌ＝５０Ｋとなり、まだ削除すべきデータ量に達していないためステップＳ３０に進み、変数Ｘが＋１され「２」に変更される。そしてステップＳ２７に戻って、Ｔ＿ｄｅｌ（２）＝タイル６が削除されることになる。
【００４８】
このようなデータ削除方法を採ることにより、現在の画像表示に重要な注目領域に相当する部分領域のタイルと、メタデータが付与されているタイルのデータが保持され、メタデータが付与されているわけでもなく、更に、現在の表示に直接関係のないタイルからキャッシュデータが削除される。また、タイル毎に一番データ量の少ないｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０，ｌａｙｅｒ　１のデータ以外のパケットデータを全て削除するため、各タイルの削除毎に大容量のデータを削除できるため、削除データの計算の負荷が軽減される。
【００４９】
また、各タイルのｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０，ｌａｙｅｒ　１のデータを削除せずに保持しておくことで、全くキャッシュされていないタイルがなくなる。これにより、例えば、より高解像度の画像表示が要求された場合、キャッシュされているデータからデコードした画像を一時的に拡大して表示することができるため、画像表示の要求後、しばらく、その領域のタイルの画像が全く表示されないといった事態の発生を防止できる。また、いつでも画像全体を把握できる画像を直ちに表示できるという効果もある。
【００５０】
尚、各タイルのキャッシュデータを削除する順番は、上記実施の形態で示したものに固定するものではなく、それ以外の順番で行っても良いことは容易に推察できる。
【００５１】
また本実施の形態では、説明を簡単にするために、タイル単位で削除領域を特定したが、Ｐｒｅｃｉｎｃｔやｃｏｄｅ−ｂｌｏｃｋでも同様の考え方に基づいたキャッシュデータの削除を行うことができる。この場合、メタデータが付与された領域についても、それぞれ、Ｐｒｅｃｉｎｃｔやｃｏｄｅ−ｂｌｏｃｋを単位として特定することになる。Ｐｒｅｃｉｎｃｔの場合は、データの削除単位はタイルと同様にパケットとなり、ｃｏｄｅ−ｂｌｏｃｋの場合には、そのコードブロックのデータを構成するサブバンドからなる符号データが単位となる。
【００５２】
更に上述の実施の形態では、メタデータが付与されている領域を１箇所としたが、これは説明を簡単にするためであり、当然、複数の領域にメタデータが存在することも考えられる。その場合も、本実施の形態の考え方は同様に適用できる。
【００５３】
また、メタデータの取得に関しては、オリジナル画像に付随する全てのメタデータを一度に取得する方法、或いは、画像の内容について記述されている「Ｃｏｎｔｅｎｔ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ　ｂｏｘ」のみを取得する方法、或いは、「Ｃｏｎｔｅｎｔ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ　ｂｏｘ」の中でも、「ＰＯＳＩＴＩＯＮ」タグを利用する可能性がある「ＰＥＲＳＯＮ」、「ＴＨＩＮＧ」、「ＯＲＧＡＮＩＺＡＴＩＯＮ」タグのみを取得する方法なども考えられる。
【００５４】
［実施の形態２］
［特定したタイルのパケット単位でのデータ削除］
前述の実施の形態１では、注目領域Ｆとメタデータ領域Ｐを除く領域を削除領域Ｒとし、その中のタイルに対して削除順番を決定し、削除領域Ｒのタイルの削除順番に従って一枚ずつ選び出したタイルの中のｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０，ｌａｙｅｒ　１のデータを除いた全てのパケットデータを削除した。しかし、削除対象として特定されたタイルのキャッシュデータに含まれるｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０，ｌａｙｅｒ　１を除く全てのパケットを単位としてではなく、領域内に含まれる全てのタイルに対して全体的なＳＮＲや解像度を低くし、データ量を削減する方法も考えられる。この場合、前述の実施の形態１と異なるのは、図１２のキャッシュデータ削除フローにおけるステップＳ２６以下である。
【００５５】
図１４は、本発明の実施の形態２に係るキャッシュデータの削除処理を示すフローチャートで、前述の図１２と同様の動作をするステップには図１２と同じ番号をつけている。
【００５６】
本実施の形態２では、ユーザは画像全体をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　１で閲覧した後、図６のタイル１６，２１，５６，６１で囲まれる領域６０２をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ２で拡大表示しており、今回の要求で、さらに図６の領域６０３をｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　３で拡大表示するものとする。従って、現在、キャッシュデータとして、領域６０２に含まれる３６枚のタイルは、図１３（Ｂ）の１３０２で示されるようなデータとして保存されており、残りのタイルに関しては、図１３（Ａ）の１３０１に示されるようなデータとして保存されているものとする。
【００５７】
図１４のステップＳ２１からステップＳ２５までは、図１２に示す実施の形態１と同様の動作をする。つまり、ステップＳ２１では、キャッシュから削除すべきデータ量Ｙを取得し、今回のデータ削除フローにおいて削除されたデータ量をカウントする変数Ｄｅｌに「０」を代入する。ステップＳ２２では、今回のデータの受信により、表示している画像のどの部分領域が表示されるのかを把握し、その表示される領域を注目領域Ｆとして特定する。
【００５８】
本実施の形態２の場合、図６の領域６０３が注目領域Ｆとして取得される。ステップＳ２３では、図８のステップＳ２で取得したメタデータが付加されている領域Ｐを取得する。ステップＳ２４では、ステップＳ２２で取得された、注目領域ＦとステップＳ２３で取得されたメタデータ領域Ｐを除く領域をデータ削除領域Ｒとして取得する。例えば、ステップＳ２３で取得したメタデータ付加領域がタイル５のみの場合には、タイル５と注目領域Ｆの領域６０３に含まれるタイルを除いた部分がデータ削除領域Ｒとして取得されることになる。そしてステップＳ２５に進み、ステップＳ２４で取得したデータ削除領域Ｒに含まれるタイルに対して、データを削除する順番を決定する。例えば、タイル番号の若い順に削除する順番をつけると、タイル０，１，２，３，４，６，７，…，のように削除順番が決定される。
【００５９】
こうしてステップＳ３１に進み、削除領域Ｒの中で、キャッシュデータの中で最も解像度の高いタイル群ＴＲを特定する。
【００６０】
本実施の形態２では、削除領域Ｒのうち、既にｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２までのデータをキャッシュしている領域６０２に含まれる３６枚のタイルから、注目領域Ｆとして特定された領域６０３の９枚のタイルを除いた２７枚のタイルがタイル群ＴＲとして特定される。つまり、図１５の領域１５０１が、最も解像度の高いタイル群ＴＲとして特定される。次にステップＳ３２に進み、ステップＳ３１で特定されたタイル群ＴＲの中から、ステップＳ２５で決定された削除の順番が最も小さいタイルＴＸを特定する。ステップＳ２５で決定された順番がタイルの番号の若い順番であった場合は、図１５の１５０１で示されるタイル群ＴＲの削除されるタイルの順番は、順にタイル１６，１７，１８，１９，２０，２１，２４，２５，…のようになる。従ってステップＳ３２では、タイルＴＸとして、まず、タイル１６が特定される。次にステップＳ３３に進み、タイルＴＸの最高解像度のデータを削除する。ステップＳ３２で、タイルＴＸとしてタイル１６が特定されていた場合は、タイル１６は、図１３の１３０２で示されるように、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２のパケットまでキャッシュされているので、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２を構成するパケット群７０６を削除する。
【００６１】
そしてステップＳ２８に進み、前述の実施の形態１と同様に、この削除データフローで削除されたデータ量をカウントする変数Ｄｅｌに、ステップＳ３３で削除したデータ量を足す。そしてステップＳ２９に進み、この削除済みのデータ量Ｄｅｌと削除すべきデータ量Ｙとを比較し、実際に削除したデータ量Ｄｅｌが削除すべき量Ｙを越えたらこのフローを終了する。まだ、越えていない場合にはステップＳ３４に進み、ステップＳ３３でデータを削除したタイルＴＸをタイル群ＴＲから外す。つまり、本実施の形態２の場合、タイル１６がタイル群ＴＲから除外される。次にステップＳ３５に進み、タイル群ＴＲが空集合になったかどうかを判断する。まだタイル群ＴＲに含まれるタイルが残っている場合にはステップＳ３２へ戻って前述の処理を繰り返すが、タイル群ＴＲに含まれるタイルが一枚も無くなるとステップＳ３１に戻り、次のタイル群ＴＲを特定する。
【００６２】
例えば、削除領域Ｒがタイル０〜７であり、削除順番が一番目がタイル７、削除順番が２番目がタイル６、以下左方向に順に削除順番が決定されており、削除順番が８番目がタイル０となっており、更に、各タイルが図１６（Ａ）の１６０１に示すようにｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２，ｌａｙｅｒ　２までのデータをキャッシュしていたとする。
【００６３】
図１６（Ａ）は、タイル７〜０のキャッシュデータを説明する図、図１６（Ｂ）は、各タイルのｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ，ｌａｙｅｒ　ｌｅｖｅｌのキャッシュデータ量を説明する図である。
【００６４】
ここで、１２０Ｋ［バイト］のデータを削除するためには、実施の形態１の方法の場合、タイル７，６，５のキャッシュデータの中で、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０、ｌａｙｅｒ　１のデータを除く全てのパケット計１６５Ｋ［バイト］を削除する。このため、削除後は、図１７（Ａ）の１７０１で示すようなキャッシュデータとなる。
【００６５】
これに対して本実施の形態２の方法の場合、タイル７、タイル６、タイル５、タイル４のキャッシュデータからｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　２を構成するパケット計１２０Ｋ［バイト］（＝３０Ｋバイト×４）を削除することになる。そのため、削除後は、図１７（Ｂ）の１７０２で示すようなキャッシュデータとなる。
【００６６】
データ削除の順番は、上記実施の形態で示したものに固定するものではなく、それ以外の順をつけても良いことは容易に推察できる。
【００６７】
また、前述の実施の形態２では、削除領域Ｒ内のデータを解像度方向に削除する方法を示したが、ＳＮＲ方向に削除する方法でも本質的には同様である。その場合、ステップＳ３１で特定されるタイル群ＴＲは最もＳＮＲが高い、即ち、キャッシュされているｌａｙｅｒが多いタイルの集合である。また、ステップＳ３３では、タイルＴＸの中で最高ＳＮＲのデータが削除される。例えば、図１３の１３０２で示すようなキャッシュデータがある場合、タイルの中で最も高いＳＮＲのデータが削除されるので、ｌａｙｅｒ　２を構成するパケットデータ１３０６，１３０５，１３０４が消去される。
【００６８】
或いは、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　のデータを削除する場合の削除データ量と、ＳＮＲのデータを削除する場合の削除データ量を比較し、削除データ量が大きい方を削除する方法でも本質的には同様に実現できる。例えば、図１３の１３０２に示される１８個のパケットが保存されている時、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ方向で削除する場合には、図７の７０６で示される６個のパケットを削除することになり、ｌａｙｅｒ方向で削除する場合には、ｌａｙｅｒ　２を構成する図１３の１３０４，１３０５，１３０６で示される９個のパケットを削除することになる。そこで、図７の７０６の６個のパケットのデータ量と、図１３の１３０４，１３０５，１３０６の９個のパケットのデータ量を比較し、データ量が大きい方を削除することとなる。
【００６９】
また前述の実施の形態では説明を簡単に行うために、タイル単位で削除領域を特定したが、Ｐｒｅｃｉｎｃｔやｃｏｄｅ−ｂｌｏｃｋでも同様の考え方に基づいたキャッシュデータの削除を行うことができる。この場合、メタデータが付与された領域についても、それぞれＰｒｅｃｉｎｃｔやｃｏｄｅ−ｂｌｏｃｋを単位として特定することになる。Ｐｒｅｃｉｎｃｔの場合は、データの削除単位はタイルと同様にパケットとなり、ｃｏｄｅ−ｂｌｏｃｋの場合には、そのコードブロックのデータを構成するサブバンドからなる符号データが単位となる。
【００７０】
更に、メタデータが付与されている領域も１箇所としたが、これは説明を簡単にするためであり、当然、複数の領域にメタデータが存在することも考えられる。その場合も、本実施の形態の考え方は同様に適用できる。
【００７１】
［実施の形態３］
［既に利用されたメタデータが付与されている領域を保存する］
前述の実施の形態１及び２では、ユーザからのデータ要求の際に、メインヘッダと共に明示的にメタデータもサーバ２０４に要求して受信していた。しかしながら、画像の符号化データを受信して表示する際に、ユーザが必要に応じてメタデータを要求し、受信することも考えられる。このように、必要に応じて利用されたメタデータを使って削除領域を決定することも可能である。
【００７２】
この実施の形態３において、前述の実施の形態１及び２と異なる部分は、最初のステップＳ１でメタデータの取得を行わない部分である。データ削除の際に、既に取得したメタデータが付与されている部分をメタデータの位置Ｐとすることで、以下、前述の実施の形態１及び２と同様に実現可能である。
【００７３】
［他の実施の形態］
本発明の目的は前述したように、本実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ，ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００７４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれている。
【００７５】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含む。
【００７６】
尚、以上説明した本発明に係る画像処理方法及び装置は以下のような実施形態で表わすことができる。
【００７７】
以上説明した構成は以下のような実施態様で表わすことが出来る。
【００７８】
［実施態様１］　符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、
を有することを特徴とする画像処理方法。
【００７９】
［実施態様２］　前記削除領域決定工程では、前記画像データを断片的に受信しキャッシュするメモリの残量と、前記注目領域を表示するためのデータ量とに基づいて、前記キャッシュされている画像データを削除する領域を削除単位領域を単位として決定することを特徴とする実施態様１に記載の画像処理装置。
【００８０】
［実施態様３］　前記画像データはＩＳＯ／ＩＥＣ−１５４４４に準拠したＪＰＥＧ２０００符号化データであることを特徴とする実施態様１又は２に記載の画像処理方法。
【００８１】
［実施態様４］　前記画像データは、ＪＰＥＧ２０００の断片化されたパケット単位であることを特徴とする実施態様３に記載の画像処理方法。
【００８２】
［実施態様５］　前記単位領域は、ＪＰＥＧ２０００のタイルに相当することを特徴とする実施態様３又は４に記載の画像処理方法。
【００８３】
［実施態様６］　前記削除工程では、パケット単位で削除することを特徴とする実施態様５に記載の画像処理方法。
【００８４】
［実施態様７］　前記削除工程では、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０、ｌａｙｅｒ　１のパケットを除く全てのパケットのデータを削除することを特徴とする実施態様６に記載の画像処理方法。
【００８５】
［実施態様８］　前記単位領域は、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０、ｌａｙｅｒ　１を除くパケットであり、パケット単位で選択し１回以上数回に分けて削除されることを特徴とする実施態様５に記載の画像処理方法。
【００８６】
［実施態様９］　前記単位領域は、ＪＰＥＧ２０００のプリシンクト（ｐｒｅｃｉｎｃｔ）であることを特徴とする実施態様３又は４に記載の画像処理方法。
【００８７】
［実施態様１０］　前記プリシンクトは、パケット単位に削除されることを特徴とする実施態様９に記載の画像処理方法。
【００８８】
［実施態様１１］　前記単位領域は、ＪＰＥＧ２０００のコードブロック（ｃｏｄｅ−ｂｌｏｃｋ）であることを特徴とする実施態様３又は４に記載の画像処理方法。
【００８９】
［実施態様１２］　前記単位領域は、同じｒｅｓｏｌｕｔｉｏｎ、同じｌａｙｅｒを構成するために必要なサブバンドからＬＬ成分を除いたデータから構成されるｃｏｄｅ−ｂｌｏｃｋのデータであることを特徴とする実施態様１１に記載の画像処理方法。
【００９０】
［実施態様１３］　符号化された画像データを断片的に受信しキャッシュして再生する画像処理装置であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定手段と、
前記判定手段で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定手段と、
前記画像データに含まれるメタデータを取得するメタデータ取得手段と、
前記メタデータ取得手段により取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定手段と、
前記注目領域と前記メタデータ付与領域特定手段により特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定手段と、
前記削除領域決定手段により決定されたデータ領域に含まれるキャッシュデータを削除する削除手段と、
を有することを特徴とする画像処理装置。
【００９１】
［実施態様１４］　前記削除領域決定手段は、前記画像データを断片的に受信しキャッシュするメモリの残量と、前記注目領域を表示するためのデータ量とに基づいて、前記キャッシュされている画像データを削除する領域を削除単位領域を単位として決定することを特徴とする実施態様１３に記載の画像処理装置。
【００９２】
［実施態様１５］　前記画像データはＩＳＯ／ＩＥＣ−１５４４４に準拠したＪＰＥＧ２０００符号化データであることを特徴とする実施態様１３又は１４に記載の画像処理装置。
【００９３】
［実施態様１６］　前記画像データは、ＪＰＥＧ２０００の断片化されたパケット単位であることを特徴とする実施態様１５に記載の画像処理装置。
【００９４】
［実施態様１７］　前記単位領域は、ＪＰＥＧ２０００のタイルに相当することを特徴とする実施態様１５又は１６に記載の画像処理装置。
【００９５】
［実施態様１８］　前記削除手段は、パケット単位で削除することを特徴とする実施態様１７に記載の画像処理装置。
【００９６】
［実施態様１９］　前記削除手段は、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０、ｌａｙｅｒ　１のパケットを除く全てのパケットのデータを削除することを特徴とする実施態様１８に記載の画像処理装置。
【００９７】
［実施態様２０］　前記単位領域は、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０、ｌａｙｅｒ　１を除くパケットであり、パケット単位で選択し１回以上数回に分けて削除されることを特徴とする実施態様１７に記載の画像処理装置。
【００９８】
［実施態様２１］　前記単位領域は、ＪＰＥＧ２０００のプリシンクト（ｐｒｅｃｉｎｃｔ）であることを特徴とする実施態様１５又は１６に記載の画像処理装置。
【００９９】
［実施態様２２］　前記プリシンクトは、パケット単位に削除されることを特徴とする実施態様２１に記載の画像処理装置。
【０１００】
［実施態様２３］　前記単位領域は、ＪＰＥＧ２０００のコードブロック（ｃｏｄｅ−ｂｌｏｃｋ）であることを特徴とする実施態様１５又は１６に記載の画像処理装置。［実施態様２４］　前記単位領域は、同じｒｅｓｏｌｕｔｉｏｎ、同じｌａｙｅｒを構成するために必要なサブバンドからＬＬ成分を除いたデータから構成されるｃｏｄｅ−ｂｌｏｃｋのデータであることを特徴とする実施態様２３に記載の画像処理装置。
【０１０１】
以上説明したように本実施の形態によれば、キャッシュされた断片的なＪＰＥＧ２０００の符号データを効率良く削除することができ、オリジナル画像を閲覧する際でも、そのオリジナル画像の符号データ量と同じか、それ以上の容量のメモリを必要としない。また、注目領域とメタデータが付与されている領域を特定し、それらの領域外のデータを削除対象とするため、複雑な計算を必要としない。
【０１０２】
また、メタデータが付与されている部分は、一般的にその他の部分領域よりも重要であると考えられるため、メタデータが付与されていない比較的重要度の低い領域のデータから削除することにより、重要度の高いデータをキャッシュに残しておくことも可能である。
【０１０３】
更に、キャッシュデータ削除の際に、ｒｅｓｏｌｕｔｉｏｎ　ｌｅｖｅｌ　０、ｌａｙｅｒ　１のデータを必ず残しておくことにより、ユーザの要求がキャッシュされているデータよりも、高解像度、高ＳＮＲであり、不足分のデータをダウンロードする場合にも、キャッシュされているデータを利用して、低解像度・低ＳＮＲの画像を一時的に表示することも可能であると言う利点がある。
【０１０４】
【発明の効果】
以上説明したように本発明によれば、キャッシュしている符号化された画像データの内、再生画像に影響の少ないキャッシュデータを削除してキャッシュにおけるデータのオーバフローを防止しながらユーザの要求に応じた表示を行うことができる。
【図面の簡単な説明】
【図１】本実施の形態に係るクライアントやサーバの構成を説明するブロック図である。
【図２】本実施の形態に係るネットワークの概略を説明する図である。
【図３】一般的なＪＰＥＧ２０００の符号化データを説明する図である。
【図４】ＪＰＥＧ２０００の符号化データにおける解像度（画像サイズ）とＲｅｓｏｌｕｔｉｏｎ番号との関係を示す図である。
【図５】パケット単位のリクエストおよびレスポンスの概念図を示す図である。
【図６】オリジナル画像の各階層のデータ構造を説明する図である。
【図７】本実施の形態に係るサーバに保存されているＪＰＥＧ２０００符号化データを説明する図である。
【図８】本発明の実施の形態１に係る符号化データのキャッシュを説明するフローチャートである。
【図９】ＪＰＸファイルにおけるメタデータの論理的なグループの説明図である。
【図１０】ＪＰＥＧ２０００のメインヘッダ内のＳＩＺマーカを説明する図である。
【図１１】「Ｐｅｒｓｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　ｍｅｔａｄａｔａ」及び「Ｐｏｓｉｔｉｏｎ　ｔｙｐｅ」のスキーマの一例を示す図である。
【図１２】実施の形態１に係る図８のステップＳ７のデータ削除処理を示すフローチャートである。
【図１３】本実施の形態に係るクライアントにおけるタイルのキャッシュデータの一例を示す図である。
【図１４】実施の形態２に係る図８のステップＳ７のデータ削除処理を示すフローチャートである。
【図１５】実施の形態２において特定された領域ＴＲを説明する図である。
【図１６】実施の形態２に係る削除領域Ｒにおけるデータ削除前のキャッシュデータの一例を示す図である。
【図１７】実施の形態２に係る削除領域Ｒにおけるデータ削除後のキャッシュデータの一例を示す図である。
【図１】
2004145759.tif 000003
【図２】
2004145759.tif 000004
【図３】
2004145759.tif 000005
【図４】
2004145759.tif 000006
【図５】
2004145759.tif 000007
【図６】
2004145759.tif 000008
【図７】
2004145759.tif 000009
【図８】
2004145759.tif 000010
【図９】
2004145759.tif 000011
【図１０】
2004145759.tif 000012
【図１１】
2004145759.tif 000013
【図１２】
2004145759.tif 000014
【図１３】
2004145759.tif 000015
【図１４】
2004145759.tif 000016
【図１５】
2004145759.tif 000017
【図１６】
2004145759.tif 000018
【図１７】
2004145759.tif 000019