JP2004145759A - 画像処理方法 - Google Patents
画像処理方法 Download PDFInfo
- Publication number
- JP2004145759A JP2004145759A JP2002311763A JP2002311763A JP2004145759A JP 2004145759 A JP2004145759 A JP 2004145759A JP 2002311763 A JP2002311763 A JP 2002311763A JP 2002311763 A JP2002311763 A JP 2002311763A JP 2004145759 A JP2004145759 A JP 2004145759A
- Authority
- JP
- Japan
- Prior art keywords
- data
- area
- image
- metadata
- cache
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
【課題】メモリ容量が小さい端末では、画像を閲覧している途中にメモリ容量をオーバーし、ユーザの要求に応じた表示が不可能になってしまう。
【解決手段】符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、画像の注目領域が変更されることにより、画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えると判定されると、キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求め(S21)、その画像データに含まれるメタデータが付与されている画像領域を特定し(S23)、注目領域とメタデータが付与されている画像領域とに基づいて、キャッシュデータから削除するデータ領域を単位領域を単位として決定し(S24)、その削除すべきデータ領域に含まれるキャッシュデータを削除する(S27)。
【選択図】 図12
【解決手段】符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、画像の注目領域が変更されることにより、画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えると判定されると、キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求め(S21)、その画像データに含まれるメタデータが付与されている画像領域を特定し(S23)、注目領域とメタデータが付与されている画像領域とに基づいて、キャッシュデータから削除するデータ領域を単位領域を単位として決定し(S24)、その削除すべきデータ領域に含まれるキャッシュデータを削除する(S27)。
【選択図】 図12
Description
【0001】
【発明の属する技術分野】
本発明は、例えばサーバからの符号化データされた画像データをクライアントで断片的に受信してキャッシュして表示する技術に関するものである。
【0002】
【従来技術】
インターネット上でWWWサーバにWebブラウザからアクセスして、文書データや画像データ等を閲覧することが盛んに行われている。この仕組みは、インターネット上に情報を公開するWWWサーバと、その情報を閲覧する複数のクライアントがあり、各クライアントはWebブラウザを使用して、そのサーバの情報を閲覧するものである。このWWWサーバは、ホームページ(Home Page)といわれる公開したい情報をHTMLで記述した文書を有しており、それをクライアント側のWebブラウザが取り込んで、クライアントコンピュータに表示する。クライアント側のWebブラウザは、表示しているページ内のリンクを辿って行き、自分が必要な情報を得ることができる。
【0003】
更に、Webサーバが管理しているファイルをダウンロードする方法として、File Transfer Protocol (以下、FTPと略す)という方法がある。このFTPは、ネットワークを通して、サーバ上にあるファイルを1度にクライアントコンピュータに転送する仕組みである。
【0004】
また画像データファイルへ断片的にアクセスして表示するためのプロトコルとして、Flashpix/IIPがある。このIIPは、Flashpixという画像データファイルフォーマットに最適なプロトコルになっており、画像データの部分アクセスの単位はFlashpixのタイル単位に行うものである。
【0005】
一方、このIIPをそのままJPEG2000に適用した場合、JPEG2000の各スケーラビリティの符号化データは、そのスケーラビリティより1つ下のスケーラビリティのデータからの差分データであるため、クライアント側で受信した断片的な符号化データをキャッシュしておく必要がある。
【0006】
【発明が解決しようとする課題】
しかし、断片的な符号化データをクライアント側で全て保存すると、最終的にクライアントが最高解像度、最高SNRで画像全体をブラウズした場合に、サーバのJPEG2000ビットストリームの全データがクライアントにキャッシュされることになる。このことは、メモリ容量が小さい端末では、画像を閲覧している途中にメモリ容量をオーバーし、ユーザの要求に応じた表示が不可能になってしまうという問題がある。更に、JPEG2000は差分データであるので、メモリ容量が飽和し、新たに受信したデータが既にキャッシュされていたデータに上書きされるようなことが生じると、正確な画像表示(ユーザが望む表示)ができなることも起こり得る。
【0007】
本発明は上記従来例に鑑みてなされたもので、キャッシュしている符号化された画像データの内、再生画像に影響の少ないキャッシュデータを削除してキャッシュにおけるデータのオーバフローを防止しながらユーザの要求に応じた表示を行うようにすることを目的とする。
【0008】
【課題を解決するための手段】
上記目的を達成するために本発明の画像処理方法は以下のような工程を備える。即ち、
符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、を有することを特徴とする。
【0009】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【0010】
[実施の形態1]
図1は、本実施の形態に係るクライアントやサーバの構成を説明するブロック図で、この装置は例えばパーソナルコンピュータやワークステーション等で構成されていてもよい。
【0011】
CPU101は、システム全体の動作を制御しており、一次記憶102に格納されたプログラムに基づいて各種制御動作を実行する。一次記憶102は主にメモリ(RAM)であり、二次記憶103に記憶されたプログラムなどを読み込んで格納する。二次記憶103は、例えばハードディスクなどがこれに該当する。一般に一次記憶102の容量は二次記憶103の容量よりも小さく、一次記憶102に格納しきれないプログラムやデータなどは二次記憶103に格納される。また、長時間記憶しなければならないデータなども二次記憶103に格納される。本実施の形態では、プログラムを二次記憶103に格納しておき、そのプログラム実行時に一次記憶102に読み込んで格納し、その一次記憶102に記憶されているプログラムに従ってCPU101が処理を行う。入力デバイス104は、例えば、マウスやキーボードなどがこれに該当し、入力デバイス104が操作されることにより、プログラムなどに割り込み信号を発生して、所望のデータの入力を行うのに使用される。出力デバイス105は、例えば、モニタやプリンタなどが考えられる。この装置の構成方法は他にも様々な形態が考えられるが、本発明の主眼ではないので、それらの説明を省略する。
【0012】
図2は、本実施の形態に係るネットワークの概略を説明する図である。
【0013】
図において、201,202はそれぞれユーザ(クライアント)を示しており、図1で説明した装置構成を有する。ユーザ201或いは202は、有線、無線を問わず、ネットワーク203を介してサーバ204と通信することが可能である。サーバ204は、図1の構成を有し、二次記憶103に相当する画像ファイルを蓄積する大容量の記憶装置(ハードディスク)205を備えている。大容量の記憶装置205は、例えばハードディスクなどがこれに該当する。このハードディスクには、JPEG2000符号化方式により符号化された画像データが数多く格納されている。ユーザ201,202は、サーバ204が格納しているJPEG2000画像データから、断片化されたデータを受信して保存する。
【0014】
本実施の形態では、既に生成済みのJPEG2000ファイルのデータを断片的に受信し、それらをキャッシュしたクライアントが、それらキャッシュデータを削除する方法について説明する。
【0015】
各ユーザは、Windows(登録商標)マシンを使用してホームページを開いて、そこに書かれているJPEG2000の画像へのリンクをクリック(指示)することで、JPEG2000の画像をユーザの用途に適した画像サイズや解像度で表示するために必要な断片的なデータを取得し、それらのデータをキャッシュする。そして、ユーザのキャッシュ容量の制限値を越えると、キャッシュマネージャのような働きを持つプログラムが動き、ユーザのキャッシュデータを削除する場合を想定する。
【0016】
図3は、一般的なJPEG2000の符号化データを説明する図で、Layer−resolution level−component−position progression(以下、LRCPと記す)に沿って記録されたJPEG2000ファイルの構成を示している。このLRCPに準じた場合、layer / resolution / component / positionの順に記録される。このようなデータの並び方はprogression orderと呼ばれる。
【0017】
図4は、JPEG2000の符号化データにおける解像度(画像サイズ)とResolution番号との関係を示す図である。
【0018】
最も小さい解像度の画像のresolution番号を「0」とし、resolution番号が一つ増加するごとに画像の幅と高さが2倍になっていく。また、各layer内は、resolution番号の小さい順にデータが格納されている。Layer番号は復元する画像の原画に対するS/N比に対応し、layer番号が小さいほどS/N比が悪くなる。一つのJPEG2000ファイル内でのresolution番号とlayer番号、component番号の最大値は、エンコーダによって予め設定され、そのパラメータに従ってエンコードされており、その情報は符号化データの中に格納されている。各パケット(パケット)は、そのパケット内に格納されているコードブロック(code−block)の情報を管理しているパケットヘッダ部と、各code−blockの符号化データを含んでいる。
【0019】
このようなJPEG2000符号化データを使えば、各ユーザは、サーバ204にある全ての画像データを取得しなくても、必要な部分のデータのみをサーバ204から受信することが可能である。ユーザの受信データの単位としては、JPEG2000のパケット、或いはパケットよりも更に小さい符号化単位であるcode−block単位が考えられる。本実施の形態では、ユーザがサーバ204から受信するデータ単位としてパケット単位を想定する。
【0020】
図5は、パケット単位のリクエストおよびレスポンスの概念図を示す図である。
【0021】
ユーザ201は、サーバ204に画像のタイル番号とresolution levelとlayer,component,position番号を指定して、データを要求する。これによりサーバ204は、画像503のコードストリームを解析して、その指定されたタイル番号、resolution levelとlayer,component,position番号に相当するパケットデータを抜き出してユーザ201に送り返す。
【0022】
本実施の形態では、サーバ204にあるオリジナル画像は、最大解像度サイズ2048×2048[画素]、8×8からなる64枚のタイル(Tiles)に分割されており、component数が「3」で、resolution level 0 〜 3、即ち、4つの画像サイズ方向の階層を持っており、2つのlayerに分けられていると仮定する。
【0023】
図6は、オリジナル画像の各階層のデータ構造を説明する図である。
【0024】
図6に示すように、オリジナル画像を構成するそれぞれのタイルには、左上のタイルからシーケンスな番号が振ってある。さらに、オリジナル画像にはメタデータ(metadata)が付加されているものとする。このメタデータは、別ファイルになっていてもよいが、本実施の形態では、説明を簡単にするために、JPXフアイルで規定されているように、XML boxの中に入っているものとする。従って、サーバ204には、図7の701で示すようなデータが保存されている。
【0025】
図7は、サーバ204で管理されているJPEG2000符号化データの構成を説明する図で、703はメインヘッダ、702はタイル0の符号化データを示している。708は前述したメタデータである。
【0026】
[タイル単位でのデータの削除]
クライアント(ユーザ)201では、サーバ204から送られてきた断片的なJPEG2000ビットストリームをキャッシュする。この動作を図8のフローを用いて説明する。
【0027】
まずステップS1で、表示したいJPEG2000画像のメインヘッダ(mainheader)のデータとメタデータを受信する。JPXで規定されているメタデータは、図9に示すように、4つの論理的なグループ「Image Creation metadata box」902,「Content Description metadata box」903,「History box」904,「Intellectual Property Rights box」905に分かれている。これら全ての論理グループを含む「XML box」901を受信しても良いし、或いは、画像の内容について記述されている「Content Description metadata box」903のみを要求して受信しても良い。次にステップS2に進み、受信したメインヘッダ及びメタデータをキャッシュするとともに、それらを解析し、メタデータが記述されている部分領域をタイルを単位として取得する。
【0028】
図10(A)(B)は、メインヘッダの中のSIZマーカの構成を説明する図である。
【0029】
このメインヘッダの中にあるSIZマーカを解析することで、画像がどのようにタイル分割されているかを知ることができる。これは、メインヘッダのSIZマーカに記されている最高解像度の画像サイズを表すパラメータXsiz(1001),Ysiz(1002)及び、最高解像度時のタイルサイズを表すパラメータXTsiz(1003),YTsiz(1004)に基づいて計算できる。
【0030】
本実施の形態では、図6に示すように、2048×2048[画素]の画像を256×256[画素]のタイルに分割しているので、横方向に2048÷256=8[タイル]、縦方向にも同様に2048÷256=8[タイル]が並んでいると計算される。また、メタデータの「Content Description metadata box」903にある「PERSON」,「THING」,「ORGANIZATION」タグを解析することで、画像のどの位置にメタデータが書き込まれているかを知ることができる。
【0031】
図11は、「Person Description metadata」と「Position type」のスキーマを説明する図である。
【0032】
本実施の形態では、簡単のために、「PERSON」タグのみが使用されており、その中に「POSITION」タグが使用されており、更に、「POSITION」タグの中では「POINT」タグにより、点が指定されていたとする。「PERSON」タグの定義及び「POSITION」タグで使われている「Position type」のスキーマを図11の1101,1102にそれぞれ示す。
【0033】
例えば、メタデータの付与されているポイントとして、x座標が「0.7」、y座標が「0.1」となっている場合、最高解像度において座標をピクセル値で求めると、x座標として(0.7×2048=)「1434」、y座標として(0.1×2048=)「205」と求められる。従って、これをタイルに当てはめると、x座標÷タイルの幅=1434÷256=5.6より6列目、y座標÷タイルの高さ=205÷256=0.8より1行目となり、図6の601で示されるタイル5にメタデータが付与されていると判定できる。従って、タイル5がメタデータ領域Pとして特定される。
【0034】
本実施の形態では、「POSITION」タグは、「POINT」タグを使ってメタデータが付与されている領域が示されているが、「POINT」タグの代わりに「RECT」タグ或いは「REGION」タグが用いられた場合は、それによって特定される領域を含むタイルの全てがメタデータ領域Pとして特定される。
【0035】
次にステップS3に進み、ユーザ201のメモリ容量を取得し、キャッシュデータの削除が必要か否かを判断するスレッショルド値を決める。受信したJPEG2000のパケットデータをキャッシュするために、利用可能なメモリ容量の100%を充てるのであれば、スレッショルド値はメモリ容量と等しくなる。しかし、JPEG2000の断片的に受信したビットストリーム以外のデータ(例えば、画像のメタ情報など)も同じメモリ容量の中に保存する場合には、利用可能なメモリ容量の一部がJPEG2000符号データのキャッシュに利用される。また或いは、同じシステムで複数のJPEG2000符号データをキャッシュする場合には、ある画像に利用できるメモリ容量のスレッショルド値は、使用可能なメモリ容量よりも小さな値に設定される。例えば、メモリ容量が3M[バイト]に対して、この画像のキャッシュのスレッショルド値として2M[バイト]の値が設定される。キャッシュのスレッショルド値を決める場合、ハードディスクなどの2次記憶媒体でも良いが、本実施の形態では、説明を簡単にするためにメモリサイズを基準としてスレッショルド値を決めるものとする。
【0036】
ステップS4では、ユーザ201の望む条件で表示するために必要なパケットデータをサーバ204に要求する。ステップS5では、サーバ204から受信する断片化されたJPEG2000符号データのバイト数Xを取得する。次にステップS6に進み、ステップS4で取得した受信データのバイト数X分のデータをキャッシュすると、ステップS3で決定されたスレッショルド値を越えてしまうか判断する。つまり、スレッショルドの値から現在キャッシュされているデータ量を引いた値よりも、ステップS5で得られた値が大きければスレッショルド値を越えると判断し、ステップS5で得られた値が小さければスレッショルド値を越えないと判断する。こうしてステップS6で、スレッショルド値を越えると判断した場合はステップS7へ進み、越えないと判断した場合ステップS8へ進む。
【0037】
例えば、ステップS3で決定されたスレッショルド値が2M[バイト]で、既にキャッシュされているJPEG2000のパケットデータ量が1.95M[バイト]である場合、ステップS5で取得した受信データのバイト数Xが120K[バイト]であれば、受信データをそのままキャッシュするとスレッショルド値を越えてしまうと判断されてステップS7へ進むことになる。ステップS7では、ステップS5で取得したバイト数Xをキャッシュしても、キャッシュ容量がスレッショルド値以下になるように、キャッシュデータの中からタイル(Tile)単位でデータを削除する。
【0038】
例えば、ステップS5で取得したバイト数Xが120K[バイト]、ステップS3で決定されたスレッショルド値が2M[バイト]であるとき、ステップS7では、2M−120K=1.88M[バイト]以下になるまで、キャッシュデータの削除が行われる。こうしてステップS8では、受信したデータをキャッシュする。次にステップS9に進み、キャッシュされたデータをデコードして表示する。そしてステップS10に進み、この画像に対する要求が終了したか判断し、要求が終了していなければステップS4へ戻り、要求が終了すれば、このデータのキャッシュルーチンを終了する。
【0039】
図12は、図8のステップS7におけるキャッシュデータの削除処理を説明するフローチャートである。
【0040】
まずステップS21で、キャッシュから削除すべきデータ量Yを取得し、今回のデータ削除フローにおいて削除されたデータ量をカウントする変数Delに「0」を代入して初期化する。
【0041】
本実施の形態では、ユーザが既に、画像全体をresolution level 1の最大SNRで表示しており、現在、図6の602で示される領域を最大SNRで、即ち、タイル16,21,56,61で囲まれる36枚のタイル領域をresolution level 2、最大SNRで表示していたとする。このとき、キャッシュの中には、画像のヘッダ部分のデータ701、全タイルのresolution level 0,resolution level 1を構成するパケットデータと、領域602を構成する36枚のタイルのresolution level 2を構成するパケットデータが入っている。つまり、タイル16,21,56,61で囲まれる36枚のタイルに関しては、図13(B)の1302に示すように、各タイルのヘッダデータ707、各タイルのresolution level0を構成するパケット群704、および各タイルのresolution level 1を構成するパケット群705と、resolution level 2を構成するパケット群706が、ユーザ201のキャッシュメモリには保存されている。それ以外のタイルに対しては、図13(A)の1301に示すように、1302で示すキャッシュデータからresolution level 2を構成するパケット群706を除いたパケットデータがキャッシュされている。これらのデータを合わせたサイズが、1.95M[バイト]、スレッショルド値が2M[バイト]、受信したデータ量が120K[バイト]であった場合、削除すべきデータ量YはY=1.95+0.12−2.0=0.07M[バイト]=70K[バイト]として取得できる。つまり、70K[バイト]以上のデータを削除する必要があり、この値がキャッシュから削除すべきデータ量Yとして設定される。
【0042】
そしてステップS22に進み、今回のデータの受信により、表示している画像のどの部分領域が表示されるのかを把握し、その表示される領域を注目領域Fとして特定する。例えば、現在、図6の領域602をresolution level 2で表示していたユーザが、タイル42を中心として拡大表示を要求し、領域603をresolution level 3で表示することを望んだ場合、注目領域Fとしてタイル33〜35,41〜43,49〜51からなる9枚のタイルが注目領域Fとして取得される。
【0043】
次にステップS23に進み、図8のステップS2で取得したメタデータが付与されている領域Pを取得する。本実施の形態の場合、タイル5のみがメタデータが付与されている領域Pに該当するものとする。次にステップS24に進み、ステップS22で取得した注目領域Fと、ステップS23で取得したメタデータ領域Pを除く領域を、データ削除領域Rとして取得する。次にステップS25に進み、ステップS24で取得したデータ削除領域Rに含まれるタイルに対して、データを削除する順番を決定する。
【0044】
例えば、右上のタイルから左方向、および下方向にデータ削除の順番をつける場合、データが削除されるタイルの順番は、メタデータ領域Pとしてタイル5が特定されているので、図6において、タイル7、タイル6、タイル4、タイル3、タイル2、タイル1、タイル0、タイル15、タイル14、…という順番になる。次にステップS26に進み、データ削除順番をカウントする変数Xに「1」を代入する。そしてステップS27に進み、削除順番XのタイルT_Del(X)のキャッシュデータの中から、タイルヘッダ部分とresolution level 0,layer 1のパケットデータを除く全てのデータを削除する。
【0045】
例えば、X=1でT_Del(1)=タイル7であれば、タイル7のキャッシュデータは、図13(A)の1301で示すデータであるので、resolution 1を構成するパケット群705と、resolution 0,layer 2を構成するパケット群1303を削除する。
【0046】
次にステップS28に進み、この削除データフローで削除したデータ量を更新して保持する変数Delに、ステップS27で削除したデータ量を足す。そしてステップS29に進み、この削除フローで削除されたデータサイズDelと、このデータ削除フローで削除すべきデータ量Yとを比較し、実際に削除したデータ量Delが削除すべきデータ量Yを越えたら、このフローを終了する。まだ、越えていない場合にはステップS30に進み、データ削除順番をカウントする変数Xを1つインクリメントし、次のデータ削除順番に該当するタイルのキャッシュデータを削除するためにステップS27へ戻る。
【0047】
いま例えば、削除すべきデータ量Yが70K[バイト]、削除番号1のタイルT_Del(1)で削除したデータ量が50K[バイト]である場合、ステップS28において、Delの値が50K[バイト]になるため、ステップS29では、Y=70K>Del=50Kとなり、まだ削除すべきデータ量に達していないためステップS30に進み、変数Xが+1され「2」に変更される。そしてステップS27に戻って、T_del(2)=タイル6が削除されることになる。
【0048】
このようなデータ削除方法を採ることにより、現在の画像表示に重要な注目領域に相当する部分領域のタイルと、メタデータが付与されているタイルのデータが保持され、メタデータが付与されているわけでもなく、更に、現在の表示に直接関係のないタイルからキャッシュデータが削除される。また、タイル毎に一番データ量の少ないresolution level 0,layer 1のデータ以外のパケットデータを全て削除するため、各タイルの削除毎に大容量のデータを削除できるため、削除データの計算の負荷が軽減される。
【0049】
また、各タイルのresolution level 0,layer 1のデータを削除せずに保持しておくことで、全くキャッシュされていないタイルがなくなる。これにより、例えば、より高解像度の画像表示が要求された場合、キャッシュされているデータからデコードした画像を一時的に拡大して表示することができるため、画像表示の要求後、しばらく、その領域のタイルの画像が全く表示されないといった事態の発生を防止できる。また、いつでも画像全体を把握できる画像を直ちに表示できるという効果もある。
【0050】
尚、各タイルのキャッシュデータを削除する順番は、上記実施の形態で示したものに固定するものではなく、それ以外の順番で行っても良いことは容易に推察できる。
【0051】
また本実施の形態では、説明を簡単にするために、タイル単位で削除領域を特定したが、Precinctやcode−blockでも同様の考え方に基づいたキャッシュデータの削除を行うことができる。この場合、メタデータが付与された領域についても、それぞれ、Precinctやcode−blockを単位として特定することになる。Precinctの場合は、データの削除単位はタイルと同様にパケットとなり、code−blockの場合には、そのコードブロックのデータを構成するサブバンドからなる符号データが単位となる。
【0052】
更に上述の実施の形態では、メタデータが付与されている領域を1箇所としたが、これは説明を簡単にするためであり、当然、複数の領域にメタデータが存在することも考えられる。その場合も、本実施の形態の考え方は同様に適用できる。
【0053】
また、メタデータの取得に関しては、オリジナル画像に付随する全てのメタデータを一度に取得する方法、或いは、画像の内容について記述されている「Content Description metadata box」のみを取得する方法、或いは、「Content Description metadata box」の中でも、「POSITION」タグを利用する可能性がある「PERSON」、「THING」、「ORGANIZATION」タグのみを取得する方法なども考えられる。
【0054】
[実施の形態2]
[特定したタイルのパケット単位でのデータ削除]
前述の実施の形態1では、注目領域Fとメタデータ領域Pを除く領域を削除領域Rとし、その中のタイルに対して削除順番を決定し、削除領域Rのタイルの削除順番に従って一枚ずつ選び出したタイルの中のresolution level 0,layer 1のデータを除いた全てのパケットデータを削除した。しかし、削除対象として特定されたタイルのキャッシュデータに含まれるresolution level 0,layer 1を除く全てのパケットを単位としてではなく、領域内に含まれる全てのタイルに対して全体的なSNRや解像度を低くし、データ量を削減する方法も考えられる。この場合、前述の実施の形態1と異なるのは、図12のキャッシュデータ削除フローにおけるステップS26以下である。
【0055】
図14は、本発明の実施の形態2に係るキャッシュデータの削除処理を示すフローチャートで、前述の図12と同様の動作をするステップには図12と同じ番号をつけている。
【0056】
本実施の形態2では、ユーザは画像全体をresolution level 1で閲覧した後、図6のタイル16,21,56,61で囲まれる領域602をresolution level2で拡大表示しており、今回の要求で、さらに図6の領域603をresolution level 3で拡大表示するものとする。従って、現在、キャッシュデータとして、領域602に含まれる36枚のタイルは、図13(B)の1302で示されるようなデータとして保存されており、残りのタイルに関しては、図13(A)の1301に示されるようなデータとして保存されているものとする。
【0057】
図14のステップS21からステップS25までは、図12に示す実施の形態1と同様の動作をする。つまり、ステップS21では、キャッシュから削除すべきデータ量Yを取得し、今回のデータ削除フローにおいて削除されたデータ量をカウントする変数Delに「0」を代入する。ステップS22では、今回のデータの受信により、表示している画像のどの部分領域が表示されるのかを把握し、その表示される領域を注目領域Fとして特定する。
【0058】
本実施の形態2の場合、図6の領域603が注目領域Fとして取得される。ステップS23では、図8のステップS2で取得したメタデータが付加されている領域Pを取得する。ステップS24では、ステップS22で取得された、注目領域FとステップS23で取得されたメタデータ領域Pを除く領域をデータ削除領域Rとして取得する。例えば、ステップS23で取得したメタデータ付加領域がタイル5のみの場合には、タイル5と注目領域Fの領域603に含まれるタイルを除いた部分がデータ削除領域Rとして取得されることになる。そしてステップS25に進み、ステップS24で取得したデータ削除領域Rに含まれるタイルに対して、データを削除する順番を決定する。例えば、タイル番号の若い順に削除する順番をつけると、タイル0,1,2,3,4,6,7,…,のように削除順番が決定される。
【0059】
こうしてステップS31に進み、削除領域Rの中で、キャッシュデータの中で最も解像度の高いタイル群TRを特定する。
【0060】
本実施の形態2では、削除領域Rのうち、既にresolution level 2までのデータをキャッシュしている領域602に含まれる36枚のタイルから、注目領域Fとして特定された領域603の9枚のタイルを除いた27枚のタイルがタイル群TRとして特定される。つまり、図15の領域1501が、最も解像度の高いタイル群TRとして特定される。次にステップS32に進み、ステップS31で特定されたタイル群TRの中から、ステップS25で決定された削除の順番が最も小さいタイルTXを特定する。ステップS25で決定された順番がタイルの番号の若い順番であった場合は、図15の1501で示されるタイル群TRの削除されるタイルの順番は、順にタイル16,17,18,19,20,21,24,25,…のようになる。従ってステップS32では、タイルTXとして、まず、タイル16が特定される。次にステップS33に進み、タイルTXの最高解像度のデータを削除する。ステップS32で、タイルTXとしてタイル16が特定されていた場合は、タイル16は、図13の1302で示されるように、resolution level 2のパケットまでキャッシュされているので、resolution level 2を構成するパケット群706を削除する。
【0061】
そしてステップS28に進み、前述の実施の形態1と同様に、この削除データフローで削除されたデータ量をカウントする変数Delに、ステップS33で削除したデータ量を足す。そしてステップS29に進み、この削除済みのデータ量Delと削除すべきデータ量Yとを比較し、実際に削除したデータ量Delが削除すべき量Yを越えたらこのフローを終了する。まだ、越えていない場合にはステップS34に進み、ステップS33でデータを削除したタイルTXをタイル群TRから外す。つまり、本実施の形態2の場合、タイル16がタイル群TRから除外される。次にステップS35に進み、タイル群TRが空集合になったかどうかを判断する。まだタイル群TRに含まれるタイルが残っている場合にはステップS32へ戻って前述の処理を繰り返すが、タイル群TRに含まれるタイルが一枚も無くなるとステップS31に戻り、次のタイル群TRを特定する。
【0062】
例えば、削除領域Rがタイル0〜7であり、削除順番が一番目がタイル7、削除順番が2番目がタイル6、以下左方向に順に削除順番が決定されており、削除順番が8番目がタイル0となっており、更に、各タイルが図16(A)の1601に示すようにresolution level 2,layer 2までのデータをキャッシュしていたとする。
【0063】
図16(A)は、タイル7〜0のキャッシュデータを説明する図、図16(B)は、各タイルのresolution level,layer levelのキャッシュデータ量を説明する図である。
【0064】
ここで、120K[バイト]のデータを削除するためには、実施の形態1の方法の場合、タイル7,6,5のキャッシュデータの中で、resolution level 0、layer 1のデータを除く全てのパケット計165K[バイト]を削除する。このため、削除後は、図17(A)の1701で示すようなキャッシュデータとなる。
【0065】
これに対して本実施の形態2の方法の場合、タイル7、タイル6、タイル5、タイル4のキャッシュデータからresolution level 2を構成するパケット計120K[バイト](=30Kバイト×4)を削除することになる。そのため、削除後は、図17(B)の1702で示すようなキャッシュデータとなる。
【0066】
データ削除の順番は、上記実施の形態で示したものに固定するものではなく、それ以外の順をつけても良いことは容易に推察できる。
【0067】
また、前述の実施の形態2では、削除領域R内のデータを解像度方向に削除する方法を示したが、SNR方向に削除する方法でも本質的には同様である。その場合、ステップS31で特定されるタイル群TRは最もSNRが高い、即ち、キャッシュされているlayerが多いタイルの集合である。また、ステップS33では、タイルTXの中で最高SNRのデータが削除される。例えば、図13の1302で示すようなキャッシュデータがある場合、タイルの中で最も高いSNRのデータが削除されるので、layer 2を構成するパケットデータ1306,1305,1304が消去される。
【0068】
或いは、resolution level のデータを削除する場合の削除データ量と、SNRのデータを削除する場合の削除データ量を比較し、削除データ量が大きい方を削除する方法でも本質的には同様に実現できる。例えば、図13の1302に示される18個のパケットが保存されている時、resolution level方向で削除する場合には、図7の706で示される6個のパケットを削除することになり、layer方向で削除する場合には、layer 2を構成する図13の1304,1305,1306で示される9個のパケットを削除することになる。そこで、図7の706の6個のパケットのデータ量と、図13の1304,1305,1306の9個のパケットのデータ量を比較し、データ量が大きい方を削除することとなる。
【0069】
また前述の実施の形態では説明を簡単に行うために、タイル単位で削除領域を特定したが、Precinctやcode−blockでも同様の考え方に基づいたキャッシュデータの削除を行うことができる。この場合、メタデータが付与された領域についても、それぞれPrecinctやcode−blockを単位として特定することになる。Precinctの場合は、データの削除単位はタイルと同様にパケットとなり、code−blockの場合には、そのコードブロックのデータを構成するサブバンドからなる符号データが単位となる。
【0070】
更に、メタデータが付与されている領域も1箇所としたが、これは説明を簡単にするためであり、当然、複数の領域にメタデータが存在することも考えられる。その場合も、本実施の形態の考え方は同様に適用できる。
【0071】
[実施の形態3]
[既に利用されたメタデータが付与されている領域を保存する]
前述の実施の形態1及び2では、ユーザからのデータ要求の際に、メインヘッダと共に明示的にメタデータもサーバ204に要求して受信していた。しかしながら、画像の符号化データを受信して表示する際に、ユーザが必要に応じてメタデータを要求し、受信することも考えられる。このように、必要に応じて利用されたメタデータを使って削除領域を決定することも可能である。
【0072】
この実施の形態3において、前述の実施の形態1及び2と異なる部分は、最初のステップS1でメタデータの取得を行わない部分である。データ削除の際に、既に取得したメタデータが付与されている部分をメタデータの位置Pとすることで、以下、前述の実施の形態1及び2と同様に実現可能である。
【0073】
[他の実施の形態]
本発明の目的は前述したように、本実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ(又はCPUやMPU)が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ(登録商標)ディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM,CD−R、磁気テープ、不揮発性のメモリカード、ROMなどを用いることができる。
【0074】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれている。
【0075】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含む。
【0076】
尚、以上説明した本発明に係る画像処理方法及び装置は以下のような実施形態で表わすことができる。
【0077】
以上説明した構成は以下のような実施態様で表わすことが出来る。
【0078】
[実施態様1] 符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、
を有することを特徴とする画像処理方法。
【0079】
[実施態様2] 前記削除領域決定工程では、前記画像データを断片的に受信しキャッシュするメモリの残量と、前記注目領域を表示するためのデータ量とに基づいて、前記キャッシュされている画像データを削除する領域を削除単位領域を単位として決定することを特徴とする実施態様1に記載の画像処理装置。
【0080】
[実施態様3] 前記画像データはISO/IEC−15444に準拠したJPEG2000符号化データであることを特徴とする実施態様1又は2に記載の画像処理方法。
【0081】
[実施態様4] 前記画像データは、JPEG2000の断片化されたパケット単位であることを特徴とする実施態様3に記載の画像処理方法。
【0082】
[実施態様5] 前記単位領域は、JPEG2000のタイルに相当することを特徴とする実施態様3又は4に記載の画像処理方法。
【0083】
[実施態様6] 前記削除工程では、パケット単位で削除することを特徴とする実施態様5に記載の画像処理方法。
【0084】
[実施態様7] 前記削除工程では、resolution level 0、layer 1のパケットを除く全てのパケットのデータを削除することを特徴とする実施態様6に記載の画像処理方法。
【0085】
[実施態様8] 前記単位領域は、resolution level 0、layer 1を除くパケットであり、パケット単位で選択し1回以上数回に分けて削除されることを特徴とする実施態様5に記載の画像処理方法。
【0086】
[実施態様9] 前記単位領域は、JPEG2000のプリシンクト(precinct)であることを特徴とする実施態様3又は4に記載の画像処理方法。
【0087】
[実施態様10] 前記プリシンクトは、パケット単位に削除されることを特徴とする実施態様9に記載の画像処理方法。
【0088】
[実施態様11] 前記単位領域は、JPEG2000のコードブロック(code−block)であることを特徴とする実施態様3又は4に記載の画像処理方法。
【0089】
[実施態様12] 前記単位領域は、同じresolution、同じlayerを構成するために必要なサブバンドからLL成分を除いたデータから構成されるcode−blockのデータであることを特徴とする実施態様11に記載の画像処理方法。
【0090】
[実施態様13] 符号化された画像データを断片的に受信しキャッシュして再生する画像処理装置であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定手段と、
前記判定手段で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定手段と、
前記画像データに含まれるメタデータを取得するメタデータ取得手段と、
前記メタデータ取得手段により取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定手段と、
前記注目領域と前記メタデータ付与領域特定手段により特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定手段と、
前記削除領域決定手段により決定されたデータ領域に含まれるキャッシュデータを削除する削除手段と、
を有することを特徴とする画像処理装置。
【0091】
[実施態様14] 前記削除領域決定手段は、前記画像データを断片的に受信しキャッシュするメモリの残量と、前記注目領域を表示するためのデータ量とに基づいて、前記キャッシュされている画像データを削除する領域を削除単位領域を単位として決定することを特徴とする実施態様13に記載の画像処理装置。
【0092】
[実施態様15] 前記画像データはISO/IEC−15444に準拠したJPEG2000符号化データであることを特徴とする実施態様13又は14に記載の画像処理装置。
【0093】
[実施態様16] 前記画像データは、JPEG2000の断片化されたパケット単位であることを特徴とする実施態様15に記載の画像処理装置。
【0094】
[実施態様17] 前記単位領域は、JPEG2000のタイルに相当することを特徴とする実施態様15又は16に記載の画像処理装置。
【0095】
[実施態様18] 前記削除手段は、パケット単位で削除することを特徴とする実施態様17に記載の画像処理装置。
【0096】
[実施態様19] 前記削除手段は、resolution level 0、layer 1のパケットを除く全てのパケットのデータを削除することを特徴とする実施態様18に記載の画像処理装置。
【0097】
[実施態様20] 前記単位領域は、resolution level 0、layer 1を除くパケットであり、パケット単位で選択し1回以上数回に分けて削除されることを特徴とする実施態様17に記載の画像処理装置。
【0098】
[実施態様21] 前記単位領域は、JPEG2000のプリシンクト(precinct)であることを特徴とする実施態様15又は16に記載の画像処理装置。
【0099】
[実施態様22] 前記プリシンクトは、パケット単位に削除されることを特徴とする実施態様21に記載の画像処理装置。
【0100】
[実施態様23] 前記単位領域は、JPEG2000のコードブロック(code−block)であることを特徴とする実施態様15又は16に記載の画像処理装置。[実施態様24] 前記単位領域は、同じresolution、同じlayerを構成するために必要なサブバンドからLL成分を除いたデータから構成されるcode−blockのデータであることを特徴とする実施態様23に記載の画像処理装置。
【0101】
以上説明したように本実施の形態によれば、キャッシュされた断片的なJPEG2000の符号データを効率良く削除することができ、オリジナル画像を閲覧する際でも、そのオリジナル画像の符号データ量と同じか、それ以上の容量のメモリを必要としない。また、注目領域とメタデータが付与されている領域を特定し、それらの領域外のデータを削除対象とするため、複雑な計算を必要としない。
【0102】
また、メタデータが付与されている部分は、一般的にその他の部分領域よりも重要であると考えられるため、メタデータが付与されていない比較的重要度の低い領域のデータから削除することにより、重要度の高いデータをキャッシュに残しておくことも可能である。
【0103】
更に、キャッシュデータ削除の際に、resolution level 0、layer 1のデータを必ず残しておくことにより、ユーザの要求がキャッシュされているデータよりも、高解像度、高SNRであり、不足分のデータをダウンロードする場合にも、キャッシュされているデータを利用して、低解像度・低SNRの画像を一時的に表示することも可能であると言う利点がある。
【0104】
【発明の効果】
以上説明したように本発明によれば、キャッシュしている符号化された画像データの内、再生画像に影響の少ないキャッシュデータを削除してキャッシュにおけるデータのオーバフローを防止しながらユーザの要求に応じた表示を行うことができる。
【図面の簡単な説明】
【図1】本実施の形態に係るクライアントやサーバの構成を説明するブロック図である。
【図2】本実施の形態に係るネットワークの概略を説明する図である。
【図3】一般的なJPEG2000の符号化データを説明する図である。
【図4】JPEG2000の符号化データにおける解像度(画像サイズ)とResolution番号との関係を示す図である。
【図5】パケット単位のリクエストおよびレスポンスの概念図を示す図である。
【図6】オリジナル画像の各階層のデータ構造を説明する図である。
【図7】本実施の形態に係るサーバに保存されているJPEG2000符号化データを説明する図である。
【図8】本発明の実施の形態1に係る符号化データのキャッシュを説明するフローチャートである。
【図9】JPXファイルにおけるメタデータの論理的なグループの説明図である。
【図10】JPEG2000のメインヘッダ内のSIZマーカを説明する図である。
【図11】「Person Description metadata」及び「Position type」のスキーマの一例を示す図である。
【図12】実施の形態1に係る図8のステップS7のデータ削除処理を示すフローチャートである。
【図13】本実施の形態に係るクライアントにおけるタイルのキャッシュデータの一例を示す図である。
【図14】実施の形態2に係る図8のステップS7のデータ削除処理を示すフローチャートである。
【図15】実施の形態2において特定された領域TRを説明する図である。
【図16】実施の形態2に係る削除領域Rにおけるデータ削除前のキャッシュデータの一例を示す図である。
【図17】実施の形態2に係る削除領域Rにおけるデータ削除後のキャッシュデータの一例を示す図である。
【発明の属する技術分野】
本発明は、例えばサーバからの符号化データされた画像データをクライアントで断片的に受信してキャッシュして表示する技術に関するものである。
【0002】
【従来技術】
インターネット上でWWWサーバにWebブラウザからアクセスして、文書データや画像データ等を閲覧することが盛んに行われている。この仕組みは、インターネット上に情報を公開するWWWサーバと、その情報を閲覧する複数のクライアントがあり、各クライアントはWebブラウザを使用して、そのサーバの情報を閲覧するものである。このWWWサーバは、ホームページ(Home Page)といわれる公開したい情報をHTMLで記述した文書を有しており、それをクライアント側のWebブラウザが取り込んで、クライアントコンピュータに表示する。クライアント側のWebブラウザは、表示しているページ内のリンクを辿って行き、自分が必要な情報を得ることができる。
【0003】
更に、Webサーバが管理しているファイルをダウンロードする方法として、File Transfer Protocol (以下、FTPと略す)という方法がある。このFTPは、ネットワークを通して、サーバ上にあるファイルを1度にクライアントコンピュータに転送する仕組みである。
【0004】
また画像データファイルへ断片的にアクセスして表示するためのプロトコルとして、Flashpix/IIPがある。このIIPは、Flashpixという画像データファイルフォーマットに最適なプロトコルになっており、画像データの部分アクセスの単位はFlashpixのタイル単位に行うものである。
【0005】
一方、このIIPをそのままJPEG2000に適用した場合、JPEG2000の各スケーラビリティの符号化データは、そのスケーラビリティより1つ下のスケーラビリティのデータからの差分データであるため、クライアント側で受信した断片的な符号化データをキャッシュしておく必要がある。
【0006】
【発明が解決しようとする課題】
しかし、断片的な符号化データをクライアント側で全て保存すると、最終的にクライアントが最高解像度、最高SNRで画像全体をブラウズした場合に、サーバのJPEG2000ビットストリームの全データがクライアントにキャッシュされることになる。このことは、メモリ容量が小さい端末では、画像を閲覧している途中にメモリ容量をオーバーし、ユーザの要求に応じた表示が不可能になってしまうという問題がある。更に、JPEG2000は差分データであるので、メモリ容量が飽和し、新たに受信したデータが既にキャッシュされていたデータに上書きされるようなことが生じると、正確な画像表示(ユーザが望む表示)ができなることも起こり得る。
【0007】
本発明は上記従来例に鑑みてなされたもので、キャッシュしている符号化された画像データの内、再生画像に影響の少ないキャッシュデータを削除してキャッシュにおけるデータのオーバフローを防止しながらユーザの要求に応じた表示を行うようにすることを目的とする。
【0008】
【課題を解決するための手段】
上記目的を達成するために本発明の画像処理方法は以下のような工程を備える。即ち、
符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、を有することを特徴とする。
【0009】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【0010】
[実施の形態1]
図1は、本実施の形態に係るクライアントやサーバの構成を説明するブロック図で、この装置は例えばパーソナルコンピュータやワークステーション等で構成されていてもよい。
【0011】
CPU101は、システム全体の動作を制御しており、一次記憶102に格納されたプログラムに基づいて各種制御動作を実行する。一次記憶102は主にメモリ(RAM)であり、二次記憶103に記憶されたプログラムなどを読み込んで格納する。二次記憶103は、例えばハードディスクなどがこれに該当する。一般に一次記憶102の容量は二次記憶103の容量よりも小さく、一次記憶102に格納しきれないプログラムやデータなどは二次記憶103に格納される。また、長時間記憶しなければならないデータなども二次記憶103に格納される。本実施の形態では、プログラムを二次記憶103に格納しておき、そのプログラム実行時に一次記憶102に読み込んで格納し、その一次記憶102に記憶されているプログラムに従ってCPU101が処理を行う。入力デバイス104は、例えば、マウスやキーボードなどがこれに該当し、入力デバイス104が操作されることにより、プログラムなどに割り込み信号を発生して、所望のデータの入力を行うのに使用される。出力デバイス105は、例えば、モニタやプリンタなどが考えられる。この装置の構成方法は他にも様々な形態が考えられるが、本発明の主眼ではないので、それらの説明を省略する。
【0012】
図2は、本実施の形態に係るネットワークの概略を説明する図である。
【0013】
図において、201,202はそれぞれユーザ(クライアント)を示しており、図1で説明した装置構成を有する。ユーザ201或いは202は、有線、無線を問わず、ネットワーク203を介してサーバ204と通信することが可能である。サーバ204は、図1の構成を有し、二次記憶103に相当する画像ファイルを蓄積する大容量の記憶装置(ハードディスク)205を備えている。大容量の記憶装置205は、例えばハードディスクなどがこれに該当する。このハードディスクには、JPEG2000符号化方式により符号化された画像データが数多く格納されている。ユーザ201,202は、サーバ204が格納しているJPEG2000画像データから、断片化されたデータを受信して保存する。
【0014】
本実施の形態では、既に生成済みのJPEG2000ファイルのデータを断片的に受信し、それらをキャッシュしたクライアントが、それらキャッシュデータを削除する方法について説明する。
【0015】
各ユーザは、Windows(登録商標)マシンを使用してホームページを開いて、そこに書かれているJPEG2000の画像へのリンクをクリック(指示)することで、JPEG2000の画像をユーザの用途に適した画像サイズや解像度で表示するために必要な断片的なデータを取得し、それらのデータをキャッシュする。そして、ユーザのキャッシュ容量の制限値を越えると、キャッシュマネージャのような働きを持つプログラムが動き、ユーザのキャッシュデータを削除する場合を想定する。
【0016】
図3は、一般的なJPEG2000の符号化データを説明する図で、Layer−resolution level−component−position progression(以下、LRCPと記す)に沿って記録されたJPEG2000ファイルの構成を示している。このLRCPに準じた場合、layer / resolution / component / positionの順に記録される。このようなデータの並び方はprogression orderと呼ばれる。
【0017】
図4は、JPEG2000の符号化データにおける解像度(画像サイズ)とResolution番号との関係を示す図である。
【0018】
最も小さい解像度の画像のresolution番号を「0」とし、resolution番号が一つ増加するごとに画像の幅と高さが2倍になっていく。また、各layer内は、resolution番号の小さい順にデータが格納されている。Layer番号は復元する画像の原画に対するS/N比に対応し、layer番号が小さいほどS/N比が悪くなる。一つのJPEG2000ファイル内でのresolution番号とlayer番号、component番号の最大値は、エンコーダによって予め設定され、そのパラメータに従ってエンコードされており、その情報は符号化データの中に格納されている。各パケット(パケット)は、そのパケット内に格納されているコードブロック(code−block)の情報を管理しているパケットヘッダ部と、各code−blockの符号化データを含んでいる。
【0019】
このようなJPEG2000符号化データを使えば、各ユーザは、サーバ204にある全ての画像データを取得しなくても、必要な部分のデータのみをサーバ204から受信することが可能である。ユーザの受信データの単位としては、JPEG2000のパケット、或いはパケットよりも更に小さい符号化単位であるcode−block単位が考えられる。本実施の形態では、ユーザがサーバ204から受信するデータ単位としてパケット単位を想定する。
【0020】
図5は、パケット単位のリクエストおよびレスポンスの概念図を示す図である。
【0021】
ユーザ201は、サーバ204に画像のタイル番号とresolution levelとlayer,component,position番号を指定して、データを要求する。これによりサーバ204は、画像503のコードストリームを解析して、その指定されたタイル番号、resolution levelとlayer,component,position番号に相当するパケットデータを抜き出してユーザ201に送り返す。
【0022】
本実施の形態では、サーバ204にあるオリジナル画像は、最大解像度サイズ2048×2048[画素]、8×8からなる64枚のタイル(Tiles)に分割されており、component数が「3」で、resolution level 0 〜 3、即ち、4つの画像サイズ方向の階層を持っており、2つのlayerに分けられていると仮定する。
【0023】
図6は、オリジナル画像の各階層のデータ構造を説明する図である。
【0024】
図6に示すように、オリジナル画像を構成するそれぞれのタイルには、左上のタイルからシーケンスな番号が振ってある。さらに、オリジナル画像にはメタデータ(metadata)が付加されているものとする。このメタデータは、別ファイルになっていてもよいが、本実施の形態では、説明を簡単にするために、JPXフアイルで規定されているように、XML boxの中に入っているものとする。従って、サーバ204には、図7の701で示すようなデータが保存されている。
【0025】
図7は、サーバ204で管理されているJPEG2000符号化データの構成を説明する図で、703はメインヘッダ、702はタイル0の符号化データを示している。708は前述したメタデータである。
【0026】
[タイル単位でのデータの削除]
クライアント(ユーザ)201では、サーバ204から送られてきた断片的なJPEG2000ビットストリームをキャッシュする。この動作を図8のフローを用いて説明する。
【0027】
まずステップS1で、表示したいJPEG2000画像のメインヘッダ(mainheader)のデータとメタデータを受信する。JPXで規定されているメタデータは、図9に示すように、4つの論理的なグループ「Image Creation metadata box」902,「Content Description metadata box」903,「History box」904,「Intellectual Property Rights box」905に分かれている。これら全ての論理グループを含む「XML box」901を受信しても良いし、或いは、画像の内容について記述されている「Content Description metadata box」903のみを要求して受信しても良い。次にステップS2に進み、受信したメインヘッダ及びメタデータをキャッシュするとともに、それらを解析し、メタデータが記述されている部分領域をタイルを単位として取得する。
【0028】
図10(A)(B)は、メインヘッダの中のSIZマーカの構成を説明する図である。
【0029】
このメインヘッダの中にあるSIZマーカを解析することで、画像がどのようにタイル分割されているかを知ることができる。これは、メインヘッダのSIZマーカに記されている最高解像度の画像サイズを表すパラメータXsiz(1001),Ysiz(1002)及び、最高解像度時のタイルサイズを表すパラメータXTsiz(1003),YTsiz(1004)に基づいて計算できる。
【0030】
本実施の形態では、図6に示すように、2048×2048[画素]の画像を256×256[画素]のタイルに分割しているので、横方向に2048÷256=8[タイル]、縦方向にも同様に2048÷256=8[タイル]が並んでいると計算される。また、メタデータの「Content Description metadata box」903にある「PERSON」,「THING」,「ORGANIZATION」タグを解析することで、画像のどの位置にメタデータが書き込まれているかを知ることができる。
【0031】
図11は、「Person Description metadata」と「Position type」のスキーマを説明する図である。
【0032】
本実施の形態では、簡単のために、「PERSON」タグのみが使用されており、その中に「POSITION」タグが使用されており、更に、「POSITION」タグの中では「POINT」タグにより、点が指定されていたとする。「PERSON」タグの定義及び「POSITION」タグで使われている「Position type」のスキーマを図11の1101,1102にそれぞれ示す。
【0033】
例えば、メタデータの付与されているポイントとして、x座標が「0.7」、y座標が「0.1」となっている場合、最高解像度において座標をピクセル値で求めると、x座標として(0.7×2048=)「1434」、y座標として(0.1×2048=)「205」と求められる。従って、これをタイルに当てはめると、x座標÷タイルの幅=1434÷256=5.6より6列目、y座標÷タイルの高さ=205÷256=0.8より1行目となり、図6の601で示されるタイル5にメタデータが付与されていると判定できる。従って、タイル5がメタデータ領域Pとして特定される。
【0034】
本実施の形態では、「POSITION」タグは、「POINT」タグを使ってメタデータが付与されている領域が示されているが、「POINT」タグの代わりに「RECT」タグ或いは「REGION」タグが用いられた場合は、それによって特定される領域を含むタイルの全てがメタデータ領域Pとして特定される。
【0035】
次にステップS3に進み、ユーザ201のメモリ容量を取得し、キャッシュデータの削除が必要か否かを判断するスレッショルド値を決める。受信したJPEG2000のパケットデータをキャッシュするために、利用可能なメモリ容量の100%を充てるのであれば、スレッショルド値はメモリ容量と等しくなる。しかし、JPEG2000の断片的に受信したビットストリーム以外のデータ(例えば、画像のメタ情報など)も同じメモリ容量の中に保存する場合には、利用可能なメモリ容量の一部がJPEG2000符号データのキャッシュに利用される。また或いは、同じシステムで複数のJPEG2000符号データをキャッシュする場合には、ある画像に利用できるメモリ容量のスレッショルド値は、使用可能なメモリ容量よりも小さな値に設定される。例えば、メモリ容量が3M[バイト]に対して、この画像のキャッシュのスレッショルド値として2M[バイト]の値が設定される。キャッシュのスレッショルド値を決める場合、ハードディスクなどの2次記憶媒体でも良いが、本実施の形態では、説明を簡単にするためにメモリサイズを基準としてスレッショルド値を決めるものとする。
【0036】
ステップS4では、ユーザ201の望む条件で表示するために必要なパケットデータをサーバ204に要求する。ステップS5では、サーバ204から受信する断片化されたJPEG2000符号データのバイト数Xを取得する。次にステップS6に進み、ステップS4で取得した受信データのバイト数X分のデータをキャッシュすると、ステップS3で決定されたスレッショルド値を越えてしまうか判断する。つまり、スレッショルドの値から現在キャッシュされているデータ量を引いた値よりも、ステップS5で得られた値が大きければスレッショルド値を越えると判断し、ステップS5で得られた値が小さければスレッショルド値を越えないと判断する。こうしてステップS6で、スレッショルド値を越えると判断した場合はステップS7へ進み、越えないと判断した場合ステップS8へ進む。
【0037】
例えば、ステップS3で決定されたスレッショルド値が2M[バイト]で、既にキャッシュされているJPEG2000のパケットデータ量が1.95M[バイト]である場合、ステップS5で取得した受信データのバイト数Xが120K[バイト]であれば、受信データをそのままキャッシュするとスレッショルド値を越えてしまうと判断されてステップS7へ進むことになる。ステップS7では、ステップS5で取得したバイト数Xをキャッシュしても、キャッシュ容量がスレッショルド値以下になるように、キャッシュデータの中からタイル(Tile)単位でデータを削除する。
【0038】
例えば、ステップS5で取得したバイト数Xが120K[バイト]、ステップS3で決定されたスレッショルド値が2M[バイト]であるとき、ステップS7では、2M−120K=1.88M[バイト]以下になるまで、キャッシュデータの削除が行われる。こうしてステップS8では、受信したデータをキャッシュする。次にステップS9に進み、キャッシュされたデータをデコードして表示する。そしてステップS10に進み、この画像に対する要求が終了したか判断し、要求が終了していなければステップS4へ戻り、要求が終了すれば、このデータのキャッシュルーチンを終了する。
【0039】
図12は、図8のステップS7におけるキャッシュデータの削除処理を説明するフローチャートである。
【0040】
まずステップS21で、キャッシュから削除すべきデータ量Yを取得し、今回のデータ削除フローにおいて削除されたデータ量をカウントする変数Delに「0」を代入して初期化する。
【0041】
本実施の形態では、ユーザが既に、画像全体をresolution level 1の最大SNRで表示しており、現在、図6の602で示される領域を最大SNRで、即ち、タイル16,21,56,61で囲まれる36枚のタイル領域をresolution level 2、最大SNRで表示していたとする。このとき、キャッシュの中には、画像のヘッダ部分のデータ701、全タイルのresolution level 0,resolution level 1を構成するパケットデータと、領域602を構成する36枚のタイルのresolution level 2を構成するパケットデータが入っている。つまり、タイル16,21,56,61で囲まれる36枚のタイルに関しては、図13(B)の1302に示すように、各タイルのヘッダデータ707、各タイルのresolution level0を構成するパケット群704、および各タイルのresolution level 1を構成するパケット群705と、resolution level 2を構成するパケット群706が、ユーザ201のキャッシュメモリには保存されている。それ以外のタイルに対しては、図13(A)の1301に示すように、1302で示すキャッシュデータからresolution level 2を構成するパケット群706を除いたパケットデータがキャッシュされている。これらのデータを合わせたサイズが、1.95M[バイト]、スレッショルド値が2M[バイト]、受信したデータ量が120K[バイト]であった場合、削除すべきデータ量YはY=1.95+0.12−2.0=0.07M[バイト]=70K[バイト]として取得できる。つまり、70K[バイト]以上のデータを削除する必要があり、この値がキャッシュから削除すべきデータ量Yとして設定される。
【0042】
そしてステップS22に進み、今回のデータの受信により、表示している画像のどの部分領域が表示されるのかを把握し、その表示される領域を注目領域Fとして特定する。例えば、現在、図6の領域602をresolution level 2で表示していたユーザが、タイル42を中心として拡大表示を要求し、領域603をresolution level 3で表示することを望んだ場合、注目領域Fとしてタイル33〜35,41〜43,49〜51からなる9枚のタイルが注目領域Fとして取得される。
【0043】
次にステップS23に進み、図8のステップS2で取得したメタデータが付与されている領域Pを取得する。本実施の形態の場合、タイル5のみがメタデータが付与されている領域Pに該当するものとする。次にステップS24に進み、ステップS22で取得した注目領域Fと、ステップS23で取得したメタデータ領域Pを除く領域を、データ削除領域Rとして取得する。次にステップS25に進み、ステップS24で取得したデータ削除領域Rに含まれるタイルに対して、データを削除する順番を決定する。
【0044】
例えば、右上のタイルから左方向、および下方向にデータ削除の順番をつける場合、データが削除されるタイルの順番は、メタデータ領域Pとしてタイル5が特定されているので、図6において、タイル7、タイル6、タイル4、タイル3、タイル2、タイル1、タイル0、タイル15、タイル14、…という順番になる。次にステップS26に進み、データ削除順番をカウントする変数Xに「1」を代入する。そしてステップS27に進み、削除順番XのタイルT_Del(X)のキャッシュデータの中から、タイルヘッダ部分とresolution level 0,layer 1のパケットデータを除く全てのデータを削除する。
【0045】
例えば、X=1でT_Del(1)=タイル7であれば、タイル7のキャッシュデータは、図13(A)の1301で示すデータであるので、resolution 1を構成するパケット群705と、resolution 0,layer 2を構成するパケット群1303を削除する。
【0046】
次にステップS28に進み、この削除データフローで削除したデータ量を更新して保持する変数Delに、ステップS27で削除したデータ量を足す。そしてステップS29に進み、この削除フローで削除されたデータサイズDelと、このデータ削除フローで削除すべきデータ量Yとを比較し、実際に削除したデータ量Delが削除すべきデータ量Yを越えたら、このフローを終了する。まだ、越えていない場合にはステップS30に進み、データ削除順番をカウントする変数Xを1つインクリメントし、次のデータ削除順番に該当するタイルのキャッシュデータを削除するためにステップS27へ戻る。
【0047】
いま例えば、削除すべきデータ量Yが70K[バイト]、削除番号1のタイルT_Del(1)で削除したデータ量が50K[バイト]である場合、ステップS28において、Delの値が50K[バイト]になるため、ステップS29では、Y=70K>Del=50Kとなり、まだ削除すべきデータ量に達していないためステップS30に進み、変数Xが+1され「2」に変更される。そしてステップS27に戻って、T_del(2)=タイル6が削除されることになる。
【0048】
このようなデータ削除方法を採ることにより、現在の画像表示に重要な注目領域に相当する部分領域のタイルと、メタデータが付与されているタイルのデータが保持され、メタデータが付与されているわけでもなく、更に、現在の表示に直接関係のないタイルからキャッシュデータが削除される。また、タイル毎に一番データ量の少ないresolution level 0,layer 1のデータ以外のパケットデータを全て削除するため、各タイルの削除毎に大容量のデータを削除できるため、削除データの計算の負荷が軽減される。
【0049】
また、各タイルのresolution level 0,layer 1のデータを削除せずに保持しておくことで、全くキャッシュされていないタイルがなくなる。これにより、例えば、より高解像度の画像表示が要求された場合、キャッシュされているデータからデコードした画像を一時的に拡大して表示することができるため、画像表示の要求後、しばらく、その領域のタイルの画像が全く表示されないといった事態の発生を防止できる。また、いつでも画像全体を把握できる画像を直ちに表示できるという効果もある。
【0050】
尚、各タイルのキャッシュデータを削除する順番は、上記実施の形態で示したものに固定するものではなく、それ以外の順番で行っても良いことは容易に推察できる。
【0051】
また本実施の形態では、説明を簡単にするために、タイル単位で削除領域を特定したが、Precinctやcode−blockでも同様の考え方に基づいたキャッシュデータの削除を行うことができる。この場合、メタデータが付与された領域についても、それぞれ、Precinctやcode−blockを単位として特定することになる。Precinctの場合は、データの削除単位はタイルと同様にパケットとなり、code−blockの場合には、そのコードブロックのデータを構成するサブバンドからなる符号データが単位となる。
【0052】
更に上述の実施の形態では、メタデータが付与されている領域を1箇所としたが、これは説明を簡単にするためであり、当然、複数の領域にメタデータが存在することも考えられる。その場合も、本実施の形態の考え方は同様に適用できる。
【0053】
また、メタデータの取得に関しては、オリジナル画像に付随する全てのメタデータを一度に取得する方法、或いは、画像の内容について記述されている「Content Description metadata box」のみを取得する方法、或いは、「Content Description metadata box」の中でも、「POSITION」タグを利用する可能性がある「PERSON」、「THING」、「ORGANIZATION」タグのみを取得する方法なども考えられる。
【0054】
[実施の形態2]
[特定したタイルのパケット単位でのデータ削除]
前述の実施の形態1では、注目領域Fとメタデータ領域Pを除く領域を削除領域Rとし、その中のタイルに対して削除順番を決定し、削除領域Rのタイルの削除順番に従って一枚ずつ選び出したタイルの中のresolution level 0,layer 1のデータを除いた全てのパケットデータを削除した。しかし、削除対象として特定されたタイルのキャッシュデータに含まれるresolution level 0,layer 1を除く全てのパケットを単位としてではなく、領域内に含まれる全てのタイルに対して全体的なSNRや解像度を低くし、データ量を削減する方法も考えられる。この場合、前述の実施の形態1と異なるのは、図12のキャッシュデータ削除フローにおけるステップS26以下である。
【0055】
図14は、本発明の実施の形態2に係るキャッシュデータの削除処理を示すフローチャートで、前述の図12と同様の動作をするステップには図12と同じ番号をつけている。
【0056】
本実施の形態2では、ユーザは画像全体をresolution level 1で閲覧した後、図6のタイル16,21,56,61で囲まれる領域602をresolution level2で拡大表示しており、今回の要求で、さらに図6の領域603をresolution level 3で拡大表示するものとする。従って、現在、キャッシュデータとして、領域602に含まれる36枚のタイルは、図13(B)の1302で示されるようなデータとして保存されており、残りのタイルに関しては、図13(A)の1301に示されるようなデータとして保存されているものとする。
【0057】
図14のステップS21からステップS25までは、図12に示す実施の形態1と同様の動作をする。つまり、ステップS21では、キャッシュから削除すべきデータ量Yを取得し、今回のデータ削除フローにおいて削除されたデータ量をカウントする変数Delに「0」を代入する。ステップS22では、今回のデータの受信により、表示している画像のどの部分領域が表示されるのかを把握し、その表示される領域を注目領域Fとして特定する。
【0058】
本実施の形態2の場合、図6の領域603が注目領域Fとして取得される。ステップS23では、図8のステップS2で取得したメタデータが付加されている領域Pを取得する。ステップS24では、ステップS22で取得された、注目領域FとステップS23で取得されたメタデータ領域Pを除く領域をデータ削除領域Rとして取得する。例えば、ステップS23で取得したメタデータ付加領域がタイル5のみの場合には、タイル5と注目領域Fの領域603に含まれるタイルを除いた部分がデータ削除領域Rとして取得されることになる。そしてステップS25に進み、ステップS24で取得したデータ削除領域Rに含まれるタイルに対して、データを削除する順番を決定する。例えば、タイル番号の若い順に削除する順番をつけると、タイル0,1,2,3,4,6,7,…,のように削除順番が決定される。
【0059】
こうしてステップS31に進み、削除領域Rの中で、キャッシュデータの中で最も解像度の高いタイル群TRを特定する。
【0060】
本実施の形態2では、削除領域Rのうち、既にresolution level 2までのデータをキャッシュしている領域602に含まれる36枚のタイルから、注目領域Fとして特定された領域603の9枚のタイルを除いた27枚のタイルがタイル群TRとして特定される。つまり、図15の領域1501が、最も解像度の高いタイル群TRとして特定される。次にステップS32に進み、ステップS31で特定されたタイル群TRの中から、ステップS25で決定された削除の順番が最も小さいタイルTXを特定する。ステップS25で決定された順番がタイルの番号の若い順番であった場合は、図15の1501で示されるタイル群TRの削除されるタイルの順番は、順にタイル16,17,18,19,20,21,24,25,…のようになる。従ってステップS32では、タイルTXとして、まず、タイル16が特定される。次にステップS33に進み、タイルTXの最高解像度のデータを削除する。ステップS32で、タイルTXとしてタイル16が特定されていた場合は、タイル16は、図13の1302で示されるように、resolution level 2のパケットまでキャッシュされているので、resolution level 2を構成するパケット群706を削除する。
【0061】
そしてステップS28に進み、前述の実施の形態1と同様に、この削除データフローで削除されたデータ量をカウントする変数Delに、ステップS33で削除したデータ量を足す。そしてステップS29に進み、この削除済みのデータ量Delと削除すべきデータ量Yとを比較し、実際に削除したデータ量Delが削除すべき量Yを越えたらこのフローを終了する。まだ、越えていない場合にはステップS34に進み、ステップS33でデータを削除したタイルTXをタイル群TRから外す。つまり、本実施の形態2の場合、タイル16がタイル群TRから除外される。次にステップS35に進み、タイル群TRが空集合になったかどうかを判断する。まだタイル群TRに含まれるタイルが残っている場合にはステップS32へ戻って前述の処理を繰り返すが、タイル群TRに含まれるタイルが一枚も無くなるとステップS31に戻り、次のタイル群TRを特定する。
【0062】
例えば、削除領域Rがタイル0〜7であり、削除順番が一番目がタイル7、削除順番が2番目がタイル6、以下左方向に順に削除順番が決定されており、削除順番が8番目がタイル0となっており、更に、各タイルが図16(A)の1601に示すようにresolution level 2,layer 2までのデータをキャッシュしていたとする。
【0063】
図16(A)は、タイル7〜0のキャッシュデータを説明する図、図16(B)は、各タイルのresolution level,layer levelのキャッシュデータ量を説明する図である。
【0064】
ここで、120K[バイト]のデータを削除するためには、実施の形態1の方法の場合、タイル7,6,5のキャッシュデータの中で、resolution level 0、layer 1のデータを除く全てのパケット計165K[バイト]を削除する。このため、削除後は、図17(A)の1701で示すようなキャッシュデータとなる。
【0065】
これに対して本実施の形態2の方法の場合、タイル7、タイル6、タイル5、タイル4のキャッシュデータからresolution level 2を構成するパケット計120K[バイト](=30Kバイト×4)を削除することになる。そのため、削除後は、図17(B)の1702で示すようなキャッシュデータとなる。
【0066】
データ削除の順番は、上記実施の形態で示したものに固定するものではなく、それ以外の順をつけても良いことは容易に推察できる。
【0067】
また、前述の実施の形態2では、削除領域R内のデータを解像度方向に削除する方法を示したが、SNR方向に削除する方法でも本質的には同様である。その場合、ステップS31で特定されるタイル群TRは最もSNRが高い、即ち、キャッシュされているlayerが多いタイルの集合である。また、ステップS33では、タイルTXの中で最高SNRのデータが削除される。例えば、図13の1302で示すようなキャッシュデータがある場合、タイルの中で最も高いSNRのデータが削除されるので、layer 2を構成するパケットデータ1306,1305,1304が消去される。
【0068】
或いは、resolution level のデータを削除する場合の削除データ量と、SNRのデータを削除する場合の削除データ量を比較し、削除データ量が大きい方を削除する方法でも本質的には同様に実現できる。例えば、図13の1302に示される18個のパケットが保存されている時、resolution level方向で削除する場合には、図7の706で示される6個のパケットを削除することになり、layer方向で削除する場合には、layer 2を構成する図13の1304,1305,1306で示される9個のパケットを削除することになる。そこで、図7の706の6個のパケットのデータ量と、図13の1304,1305,1306の9個のパケットのデータ量を比較し、データ量が大きい方を削除することとなる。
【0069】
また前述の実施の形態では説明を簡単に行うために、タイル単位で削除領域を特定したが、Precinctやcode−blockでも同様の考え方に基づいたキャッシュデータの削除を行うことができる。この場合、メタデータが付与された領域についても、それぞれPrecinctやcode−blockを単位として特定することになる。Precinctの場合は、データの削除単位はタイルと同様にパケットとなり、code−blockの場合には、そのコードブロックのデータを構成するサブバンドからなる符号データが単位となる。
【0070】
更に、メタデータが付与されている領域も1箇所としたが、これは説明を簡単にするためであり、当然、複数の領域にメタデータが存在することも考えられる。その場合も、本実施の形態の考え方は同様に適用できる。
【0071】
[実施の形態3]
[既に利用されたメタデータが付与されている領域を保存する]
前述の実施の形態1及び2では、ユーザからのデータ要求の際に、メインヘッダと共に明示的にメタデータもサーバ204に要求して受信していた。しかしながら、画像の符号化データを受信して表示する際に、ユーザが必要に応じてメタデータを要求し、受信することも考えられる。このように、必要に応じて利用されたメタデータを使って削除領域を決定することも可能である。
【0072】
この実施の形態3において、前述の実施の形態1及び2と異なる部分は、最初のステップS1でメタデータの取得を行わない部分である。データ削除の際に、既に取得したメタデータが付与されている部分をメタデータの位置Pとすることで、以下、前述の実施の形態1及び2と同様に実現可能である。
【0073】
[他の実施の形態]
本発明の目的は前述したように、本実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ(又はCPUやMPU)が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ(登録商標)ディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM,CD−R、磁気テープ、不揮発性のメモリカード、ROMなどを用いることができる。
【0074】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれている。
【0075】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含む。
【0076】
尚、以上説明した本発明に係る画像処理方法及び装置は以下のような実施形態で表わすことができる。
【0077】
以上説明した構成は以下のような実施態様で表わすことが出来る。
【0078】
[実施態様1] 符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、
を有することを特徴とする画像処理方法。
【0079】
[実施態様2] 前記削除領域決定工程では、前記画像データを断片的に受信しキャッシュするメモリの残量と、前記注目領域を表示するためのデータ量とに基づいて、前記キャッシュされている画像データを削除する領域を削除単位領域を単位として決定することを特徴とする実施態様1に記載の画像処理装置。
【0080】
[実施態様3] 前記画像データはISO/IEC−15444に準拠したJPEG2000符号化データであることを特徴とする実施態様1又は2に記載の画像処理方法。
【0081】
[実施態様4] 前記画像データは、JPEG2000の断片化されたパケット単位であることを特徴とする実施態様3に記載の画像処理方法。
【0082】
[実施態様5] 前記単位領域は、JPEG2000のタイルに相当することを特徴とする実施態様3又は4に記載の画像処理方法。
【0083】
[実施態様6] 前記削除工程では、パケット単位で削除することを特徴とする実施態様5に記載の画像処理方法。
【0084】
[実施態様7] 前記削除工程では、resolution level 0、layer 1のパケットを除く全てのパケットのデータを削除することを特徴とする実施態様6に記載の画像処理方法。
【0085】
[実施態様8] 前記単位領域は、resolution level 0、layer 1を除くパケットであり、パケット単位で選択し1回以上数回に分けて削除されることを特徴とする実施態様5に記載の画像処理方法。
【0086】
[実施態様9] 前記単位領域は、JPEG2000のプリシンクト(precinct)であることを特徴とする実施態様3又は4に記載の画像処理方法。
【0087】
[実施態様10] 前記プリシンクトは、パケット単位に削除されることを特徴とする実施態様9に記載の画像処理方法。
【0088】
[実施態様11] 前記単位領域は、JPEG2000のコードブロック(code−block)であることを特徴とする実施態様3又は4に記載の画像処理方法。
【0089】
[実施態様12] 前記単位領域は、同じresolution、同じlayerを構成するために必要なサブバンドからLL成分を除いたデータから構成されるcode−blockのデータであることを特徴とする実施態様11に記載の画像処理方法。
【0090】
[実施態様13] 符号化された画像データを断片的に受信しキャッシュして再生する画像処理装置であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定手段と、
前記判定手段で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定手段と、
前記画像データに含まれるメタデータを取得するメタデータ取得手段と、
前記メタデータ取得手段により取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定手段と、
前記注目領域と前記メタデータ付与領域特定手段により特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定手段と、
前記削除領域決定手段により決定されたデータ領域に含まれるキャッシュデータを削除する削除手段と、
を有することを特徴とする画像処理装置。
【0091】
[実施態様14] 前記削除領域決定手段は、前記画像データを断片的に受信しキャッシュするメモリの残量と、前記注目領域を表示するためのデータ量とに基づいて、前記キャッシュされている画像データを削除する領域を削除単位領域を単位として決定することを特徴とする実施態様13に記載の画像処理装置。
【0092】
[実施態様15] 前記画像データはISO/IEC−15444に準拠したJPEG2000符号化データであることを特徴とする実施態様13又は14に記載の画像処理装置。
【0093】
[実施態様16] 前記画像データは、JPEG2000の断片化されたパケット単位であることを特徴とする実施態様15に記載の画像処理装置。
【0094】
[実施態様17] 前記単位領域は、JPEG2000のタイルに相当することを特徴とする実施態様15又は16に記載の画像処理装置。
【0095】
[実施態様18] 前記削除手段は、パケット単位で削除することを特徴とする実施態様17に記載の画像処理装置。
【0096】
[実施態様19] 前記削除手段は、resolution level 0、layer 1のパケットを除く全てのパケットのデータを削除することを特徴とする実施態様18に記載の画像処理装置。
【0097】
[実施態様20] 前記単位領域は、resolution level 0、layer 1を除くパケットであり、パケット単位で選択し1回以上数回に分けて削除されることを特徴とする実施態様17に記載の画像処理装置。
【0098】
[実施態様21] 前記単位領域は、JPEG2000のプリシンクト(precinct)であることを特徴とする実施態様15又は16に記載の画像処理装置。
【0099】
[実施態様22] 前記プリシンクトは、パケット単位に削除されることを特徴とする実施態様21に記載の画像処理装置。
【0100】
[実施態様23] 前記単位領域は、JPEG2000のコードブロック(code−block)であることを特徴とする実施態様15又は16に記載の画像処理装置。[実施態様24] 前記単位領域は、同じresolution、同じlayerを構成するために必要なサブバンドからLL成分を除いたデータから構成されるcode−blockのデータであることを特徴とする実施態様23に記載の画像処理装置。
【0101】
以上説明したように本実施の形態によれば、キャッシュされた断片的なJPEG2000の符号データを効率良く削除することができ、オリジナル画像を閲覧する際でも、そのオリジナル画像の符号データ量と同じか、それ以上の容量のメモリを必要としない。また、注目領域とメタデータが付与されている領域を特定し、それらの領域外のデータを削除対象とするため、複雑な計算を必要としない。
【0102】
また、メタデータが付与されている部分は、一般的にその他の部分領域よりも重要であると考えられるため、メタデータが付与されていない比較的重要度の低い領域のデータから削除することにより、重要度の高いデータをキャッシュに残しておくことも可能である。
【0103】
更に、キャッシュデータ削除の際に、resolution level 0、layer 1のデータを必ず残しておくことにより、ユーザの要求がキャッシュされているデータよりも、高解像度、高SNRであり、不足分のデータをダウンロードする場合にも、キャッシュされているデータを利用して、低解像度・低SNRの画像を一時的に表示することも可能であると言う利点がある。
【0104】
【発明の効果】
以上説明したように本発明によれば、キャッシュしている符号化された画像データの内、再生画像に影響の少ないキャッシュデータを削除してキャッシュにおけるデータのオーバフローを防止しながらユーザの要求に応じた表示を行うことができる。
【図面の簡単な説明】
【図1】本実施の形態に係るクライアントやサーバの構成を説明するブロック図である。
【図2】本実施の形態に係るネットワークの概略を説明する図である。
【図3】一般的なJPEG2000の符号化データを説明する図である。
【図4】JPEG2000の符号化データにおける解像度(画像サイズ)とResolution番号との関係を示す図である。
【図5】パケット単位のリクエストおよびレスポンスの概念図を示す図である。
【図6】オリジナル画像の各階層のデータ構造を説明する図である。
【図7】本実施の形態に係るサーバに保存されているJPEG2000符号化データを説明する図である。
【図8】本発明の実施の形態1に係る符号化データのキャッシュを説明するフローチャートである。
【図9】JPXファイルにおけるメタデータの論理的なグループの説明図である。
【図10】JPEG2000のメインヘッダ内のSIZマーカを説明する図である。
【図11】「Person Description metadata」及び「Position type」のスキーマの一例を示す図である。
【図12】実施の形態1に係る図8のステップS7のデータ削除処理を示すフローチャートである。
【図13】本実施の形態に係るクライアントにおけるタイルのキャッシュデータの一例を示す図である。
【図14】実施の形態2に係る図8のステップS7のデータ削除処理を示すフローチャートである。
【図15】実施の形態2において特定された領域TRを説明する図である。
【図16】実施の形態2に係る削除領域Rにおけるデータ削除前のキャッシュデータの一例を示す図である。
【図17】実施の形態2に係る削除領域Rにおけるデータ削除後のキャッシュデータの一例を示す図である。
Claims (1)
- 符号化された画像データを断片的に受信しキャッシュして再生する画像処理方法であって、
画像の注目領域が変更されることにより、前記画像データをキャッシュしているキャッシュデータ量がキャッシュメモリの許容量を越えるかどうかを判定する判定工程と、
前記判定工程で越えると判定されると前記キャッシュメモリに格納されているキャッシュデータから削除すべきデータ量を求める削除データ量決定工程と、
前記画像データに含まれるメタデータを取得するメタデータ取得工程と、
前記メタデータ取得工程で取得したメタデータから当該メタデータが付与されている画像領域を特定するメタデータ付与領域特定工程と、
前記注目領域と前記メタデータ付与領域特定工程で特定された前記画像領域に基づいて、前記キャッシュデータから削除するデータ領域を単位領域を単位として決定する削除領域決定工程と、
前記削除領域決定工程で決定されたデータ領域に含まれるキャッシュデータを削除する削除工程と、
を有することを特徴とする画像処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002311763A JP2004145759A (ja) | 2002-10-25 | 2002-10-25 | 画像処理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002311763A JP2004145759A (ja) | 2002-10-25 | 2002-10-25 | 画像処理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004145759A true JP2004145759A (ja) | 2004-05-20 |
Family
ID=32456890
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002311763A Withdrawn JP2004145759A (ja) | 2002-10-25 | 2002-10-25 | 画像処理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004145759A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103885753A (zh) * | 2014-03-03 | 2014-06-25 | 广州金山网络科技有限公司 | 缓存图片的管理方法、装置和客户端 |
CN105513005A (zh) * | 2015-12-02 | 2016-04-20 | 魅族科技(中国)有限公司 | 一种内存管理的方法及终端 |
-
2002
- 2002-10-25 JP JP2002311763A patent/JP2004145759A/ja not_active Withdrawn
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103885753A (zh) * | 2014-03-03 | 2014-06-25 | 广州金山网络科技有限公司 | 缓存图片的管理方法、装置和客户端 |
CN105513005A (zh) * | 2015-12-02 | 2016-04-20 | 魅族科技(中国)有限公司 | 一种内存管理的方法及终端 |
CN105513005B (zh) * | 2015-12-02 | 2019-01-29 | 魅族科技(中国)有限公司 | 一种内存管理的方法及终端 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7580577B2 (en) | Methods, apparatus and computer products for generating JPEG2000 encoded data in a client | |
EP3333715B1 (en) | Cache system and method for generating uncached objects from cached and stored object components | |
JP4377103B2 (ja) | サーバクライアント環境におけるjpeg2000のための画像処理 | |
US20060140494A1 (en) | Image processing method and image processing apparatus | |
US20030142871A1 (en) | Image processing method and apparatus | |
US6300959B1 (en) | Method and system condensing animated images | |
JP2011108102A (ja) | ウェブサーバ、ウェブブラウザおよびウェブシステム | |
JP2007234027A (ja) | 部分的な書類画像にアクセスするための方法、サーバー及びコンピュータプログラム | |
KR20020087482A (ko) | 포맷 적응를 이용한 오브젝트 전송 방법 | |
JP4789192B2 (ja) | 符号処理装置、プログラム及び情報記録媒体 | |
JP2005012685A (ja) | 画像処理方法、画像処理装置 | |
JP5524950B2 (ja) | メタデータ生成管理装置、メタデータ生成システム、メタデータ生成管理用集積回路、メタデータ生成管理方法、及びプログラム | |
CA2384674C (en) | Methods, apparatus, and systems for storing, retrieving and playing multimedia data | |
JP2004145759A (ja) | 画像処理方法 | |
Han et al. | Progressive vector data transmission | |
US20050005028A1 (en) | Automated image markup system and method | |
JP3897691B2 (ja) | スクロール表示方法及び装置 | |
JP4250401B2 (ja) | 画像処理装置及び前記装置におけるキャッシュ制御方法 | |
JP4109963B2 (ja) | 画像処理方法及び装置 | |
JP3768934B2 (ja) | 画像処理装置及びそのデータキャッシュ方法 | |
JP3958198B2 (ja) | 画像処理方法 | |
Weidmann et al. | Soft caching: Image caching in a rate-distortion framework | |
JP2012015596A (ja) | Htmlコンテンツ映像化装置およびその動作方法 | |
KR101589369B1 (ko) | 비 휘발성 메모리를 이용한 처리된 자원 캐싱 장치 및 방법 | |
JP4125087B2 (ja) | 画像処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060110 |