JP3768934B2 - 画像処理装置及びそのデータキャッシュ方法 - Google Patents
画像処理装置及びそのデータキャッシュ方法 Download PDFInfo
- Publication number
- JP3768934B2 JP3768934B2 JP2002222021A JP2002222021A JP3768934B2 JP 3768934 B2 JP3768934 B2 JP 3768934B2 JP 2002222021 A JP2002222021 A JP 2002222021A JP 2002222021 A JP2002222021 A JP 2002222021A JP 3768934 B2 JP3768934 B2 JP 3768934B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- encoded data
- file
- dummy
- packet
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Image Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Compression Of Band Width Or Redundancy In Fax (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、符号化された画像データを送受して処理する画像処理装置及びそのデータキャッシュ方法に関するものである。
【０００２】
【従来の技術】
インターネットに接続可能なパーソナルコンピュータ（以下、単にコンピュータと称する）等の画像処理装置のユーザは、その装置が有するウエブブラウザの機能を利用して、インターネット上のＷＷＷ（World Wide Web）サーバにアクセスすることにより、各種の文書データや画像データ等の閲覧を行なっている。
【０００３】
このようなウエブブラウザを利用した情報の閲覧は、インターネット上において各種情報を公開するＷＷＷサーバ（以下、単にサーバと称する場合がある）と、その情報を閲覧するコンピュータ（ユーザ端末）等のクライアントとの間で行われ、クライアント側において、ユーザは、ウエブブラウザを操作することによってサーバ上の情報を閲覧することができる。
【０００４】
このＷＷＷサーバには、情報提供者がインターネット上での公開を希望する各種の情報が、所謂、ホームページといわれるＨＴＭＬ形式で記述された情報で格納されており、その情報は、クライアント側のウエブブラウザの機能により、クライアント側のコンピュータに表示される。またクライアント側のユーザは、ウエブブラウザを操作することにより、ディスプレイに表示されているホームページ内のリンクを辿ってユーザ所望の情報を得ることができる。
【０００５】
また、サーバにて管理されている各種のデータファイルをクライアント側のコンピュータにダウンロードする方法として、File Transfer Protocol（以下、ＦＴＰと略す）なる通信プロトコルを利用する方法がある。このＦＴＰは、通信ネットワークを介して、サーバ上にあるファイルをクライアント側のコンピュータに転送する手順を規定している。
【０００６】
これに対して、上述したＷＷＷサーバとウエブブラウザによってインターネット上で構成される情報閲覧システムにおいては、Hyper Text Transfer Protocol（以下、ＨＴＴＰと略す）なる通信プロトコルを用いて、サーバ／クライアント間の通信が行われており、このＨＴＴＰは、以下のように動作する。
【０００７】
例えば、クライアント側のユーザ端末でウエブブラウザを利用して、ユーザがあるホームページ内のリンク情報が張られている部分をクリックすると、ウエブブラウザは、そのクリックされた部分のリンク情報を解読すると共に、その解読結果に従って新しいＵＲＬ（Uniform Resource Locator）をオープンする。ここで、オープンとは、目的のサーバに対して、ドキュメント情報の送信リクエストを発行することである。
【０００８】
この送信リクエストを受けたサーバは、そのリクエストに対応するドキュメント全体をクライアントに返す。この時、サーバから送られてくるドキュメントは、ヘッダ情報とドキュメント情報本体とからなり、ウエブブラウザにてＵＲＬによって指定されたドキュメント全部のデータであって、当該サーバからクライアント側のコンピュータに一度に転送される文書データである。
【０００９】
この文書データを受信したクライアント側のウエブブラウザは、まず、サーバから受信した文書データに含まれるヘッダ情報を解析する。具体的には、ヘッダ情報に含まれるMIME−TYPEに従って、当該ヘッダ情報に続くドキュメント情報を開くことが可能なアプリケーションを特定する。その後、ウエブブラウザは、ユーザ端末に予めインストールされている、特定されたアプリケーションを起動し、このヘッダ情報の後に続くドキュメント情報本体を、その起動したアプリケーションに渡す。これにより、ウエブブラウザから受信した文書データ（ドキュメント）が、そのユーザ端末のディスプレイに表示され、ユーザによる閲覧が可能になる。
【００１０】
上述したようにＨＴＴＰでは、基本的にクライアント側からあるＵＲＬのオープン要求がサーバ側に伝えられると、サーバ側では、そのＵＲＬで指定されている文書データ全体をクライアント側に送信する動作が行われる。
【００１１】
これに対して、上述したＦＴＰでは、上記のＨＴＴＰの場合と同様に、ＵＲＬを利用してユーザが所望するドキュメントが指定されるが、ここで指定されるドキュメントは、サーバ内で管理されているファイルである。よって、このサーバは、指定されたファイル全体をクライアント側のコンピュータに転送し、クライアント側でファイルとして格納する。
【００１２】
【発明が解決しようとする課題】
上述したＨＴＴＰやＦＴＰ等の通信プロトコルでは、サーバでファイルとして管理されているドキュメントのうち、ダウンロード対象のドキュメントを構成する全データが、ユーザ端末からの送信リクエストに応じて、そのユーザ端末（コンピュータ）に送信されることになる。このため、そのドキュメント内に含まれる、ある画像データファイルだけにアクセスする等といった、あるドキュメントにおける部分的なデータのアクセスを、ユーザ端末から行なうことができないという問題がある。
【００１３】
係る状況に対して、ユーザ端末において所望の画像を表示するためのプロトコルとして、例えばFlashpix/IIPがある。このＩＩＰ（Internet Imaging Protocol）は、Flashpixという画像データのファイルフォーマットに最適なプロトコルになっており、画像データファイルへの部分的なアクセスを実現している。但し、このFlashpix/IIPにおいて、画像データに部分的にアクセスできる単位は、Flashpixで定められたタイル単位である。このFlashpixのタイルは、１つのタイルを構成する画像データ（圧縮されている場合を含む）のみで、そのタイルの画像データを復号（デコード）して再生できる構成になっている。このため、クライアント側のユーザ端末で起動される画像データのデコード及び表示用のアプリケーションは、その受信したタイル画像データを自装置内で一時的に保存（キャッシュ）しなくても、そのタイル単位で画像をデコードして表示できる。
【００１４】
また、近年においては、ISO/IEC-15444に準拠したJPEG(Joint Photographic Experts Group)2000方式の画像符号化の技術が提案されているが、インターネットを含む一般的な通信ネットワーク上に構成されたクライアント／サーバ環境において、上記のFlashpix/IIPをJPEG2000方式に基づいて符号化された画像データ（以下、符号化データ）にそのまま適用した場合、JPEG2000方式における各スケイラビリティの符号化データは、そのスケイラビリティより１つ下のスケイラビリティのデータに基づく差分データとなる。
【００１５】
従って、上述したようにFlashpixでは、１つのタイルを構成する画像データのみで、そのタイルの画像データをデコードできる構成になっているのに対して、JPEG2000方式に基づくデコードを行う場合には、クライアント側のコンピュータ（ユーザ端末）では、今回表示されるべき画像のスケイラビリティより下の符号化データも必要になる。
【００１６】
また、JPEG2000方式に基づく符号化データをクライアント側のコンピュータでキャッシュする場合、そのコンピュータは、サーバ側から部分的な符号化データを受信することになるため、受信した複数の部分的な符号化データを、１つの符号化データのデータファイルとして編成することができる。しかしながら、この場合は、クライアント側での編集処理等が煩雑になり、必要な機能を実現するソフトウエアのコストの低減が容易でないという問題がある。
【００１７】
また、サーバから受信した部分的な符号化データを、クライアント側のコンピュータにおいて独自形式のキャッシュファイルとして構成することも可能である。しかしこのような場合には、クライアントにおいて動作するJPEG2000方式のデコーダが、この独自形式のキャッシュファイルを読み取る処理が複雑になるという問題がある。
【００１８】
本発明は上記従来例に鑑みてなされたもので、所定形式で断片化された画像データを、その所定の形式に基づいてデコードし、キャッシュする画像処理装置とそのデータキャッシュ方法を提供することを目的とする。
【００１９】
【課題を解決するための手段】
上記目的を達成するために本発明の画像処理装置は以下のような構成を備える。即ち、
通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信手段と、
前記受信手段により受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出手段と、
前記算出手段により算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成手段と、
前記ダミーデータ生成手段によって設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換手段と、を有することを特徴とする。
【００２０】
上記目的を達成するために本発明の画像処理装置におけるデータキャッシュ方法は以下のような工程を備える。即ち、
通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置におけるデータキャッシュ方法であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信工程と、
受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出工程と、
前記算出工程で算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成工程と、
前記ダミーデータ生成工程で設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換工程と、を有することを特徴とする。
【００２１】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【００２２】
＜実施の形態１＞
図１は、本発明の実施の形態１に係る画像処理装置としてのコンピュータ機器の概略構成を示すブロック図である。
【００２３】
同図において、ＣＰＵ１０１は、一次記憶１０２に格納されたプログラムを実行して、このコンピュータ機器全体の動作制御を行なう。本実施の形態において、一次記憶ユニット（以下、一次記憶と略称する）１０２は、記憶媒体の一例として、主にメモリが想定され、二次記憶ユニット（以下、二次記憶と略称する）１０３に記憶されたプログラム等が読み込まれて格納される。この二次記憶１０３には、ハードディスク等の記憶媒体を利用することができる。
【００２４】
一般に、一次記憶１０２に格納可能なデータ容量は、二次記憶１０３に格納可能なデータ容量よりも小さく、一次記憶１０２に格納しきれないプログラムやデータ等は二次記憶１０３に格納される。また、長時間記憶しておかなければならないデータ等も二次記憶１０３に格納される。本実施の形態では、このコンピュータ機器の動作制御処理が記述されたソフトウエア・プログラムが二次記憶１０３に格納されており、係るソフトウエア・プログラムは、ＣＰＵ１０１による実行に先立って、一次記憶１０２に読み込まれる。
【００２５】
入力デバイス１０４は、例えば、マウス等の補助入力装置やキーボード等の入力装置であり、ユーザの操作をコンピュータに設定するために用いられる。出力デバイス１０５は、例えば、モニタやプリンタ等である。そして１０６は、外部装置との双方向の通信が可能な通信インターフェースである。
【００２６】
図１に示すこれら各部は、内部バス１０７によって相互にデータ転送可能に接続されており、ＣＰＵ１０１によるコンピュータ機器全体の動作制御を実現している。
【００２７】
本実施の形態に係る画像処理装置としてのコンピュータ機器の構成には、この他にも様々な形態が考えられるが、現在では一般的なコンピュータ機器及びその周辺デバイスを利用可能であり、本実施形態における詳細な説明は省略する。
【００２８】
図２は、本発明の実施の形態における通信ネットワークの概略を示す図であり、所謂サーバ・クライアント環境を示している。
【００２９】
同図において、２０１及び２０２は、クライアントとしてのユーザ端末であり、個々のユーザ端末は、図１を参照して上述した画像処理装置としてのコンピュータ機器（コンピュータシステム）である。ユーザ端末２０１及び２０２とサーバ２０４とは、インターネットを含む一般的な通信ネットワーク（以下、単にネットワークと称する）２０３を介して、互いにデータ通信を行なうことが可能である。
【００３０】
サーバコンピュータ（以下、単にサーバと称する）２０４は、画像ファイルを蓄積するハードディスク等の大容量の記憶装置２０５を備える。本実施の形態において、記憶装置２０５には、JPEG2000符号化方式に従って予め符号化された画像データが数多く格納されている。
【００３１】
以下の説明では、JPEG2000符号化方式に従って符号化された符号化画像データ（符号化データ）のデータファイルを、ユーザ端末２０１（２０２）でキャッシュする方法を具体的な例に従って詳述する。本実施の形態では、具体的に、ユーザ端末２０１（又は２０２）のユーザが、そのユーザ端末にて動作するウエブブラウザを操作しながら、ネットワーク２０３を介して、所望のホームページにアクセスすると共に、そのホームページに含まれるJPEG2000方式の画像データへのリンク部分をクリック（選択操作）することにより、その画像データをユーザが所望するサイズや解像度で取得し、当該ユーザ端末のディスプレイに表示する場合を例にして説明する。
【００３２】
ここで、本実施の形態に係るキャッシュ方法の理解を容易にすべく、一般的なJPEG2000方式の符号化データについて概説する。
【００３３】
図３は、JPEG2000方式の符号化データの構成を示す図であり、Layer-resolution level-component-position progression（以下、ＬＲＣＰと記す）に従って記録されたJPEG2000ファイル（JPEG2000方式の符号化データファイル）の構造を示す。
【００３４】
このＬＲＣＰに準じた場合、一般に、JPEG2000ファイルは、各種の記憶媒体において、レイヤ／resolution／コンポーネント（component）／位置（position）というデータブロックの順に記録される。このようなデータブロックの並び方（配列）は、progression order と呼ばれる。上記位置(position)の概念は、JPEG2000符号化方式では「precinct」という技術の中で考慮されており、ウェーブレット変換を施した後に得られる各解像度の周波数成分において、異なる周波数成分であっても、レイヤ／resolution／コンポーネントが同種／同レベルであれば、オリジナル画像において分割された同じ小領域の位置を示すデータ群として連続的に並ぶ様に配列される様になっている。
【００３５】
図４は、JPEG2000の解像度スケイラビリティを説明する図であり、解像度（画像サイズ）と、resolution番号との関係を示している。
【００３６】
同図に示すように、最も小さい解像度の画像のresolution番号を「０」とし、resolution番号が１つ大きくなると、その画像サイズは幅と高さがそれぞれ２倍になる。
【００３７】
また、図３に示す符号化データの構造において、レイヤ（Layer）番号に対応する各レイヤ内には、resolution番号の小さい順にデータが格納されている。レイヤ番号は、復元されるべき画像の原画（元画像）に対するＳ／Ｎ比に対応しており、レイヤ番号が小さい画像ほど原画に対するＳ／Ｎ比が悪化する傾向を有している。
【００３８】
１つのJPEG2000ファイルにおいて、resolution番号とレイヤ番号、並びにコンポーネント番号の最大値は、JPEG2000方式に準拠したエンコーダによって予め設定されており、それらパラメータは、符号化データに格納されている。各パケットは、そのパケット内に格納されているコードブロック（code-block）の情報を管理しているパケットヘッダ（packet header）部と、各コードブロックの符号化データとから構成されている。
【００３９】
［キャッシュファイルの作成］
図３及び図４に示すようなJPEG2000方式の符号化データを、本実施の形態において以下に説明するキャッシュ手順に従って、ユーザ端末２０１（２０２）においてファイルとして記憶すれば、サーバ２０４に存在する所望の画像に対応する全ての符号化データを当該ユーザ端末に取得しなくても、ユーザが必要な部分（解像度）の符号化データのみを当該サーバから受信して効率的に画像を閲覧することが可能になる。
【００４０】
ユーザ端末における受信データの単位としては、JPEG2000のパケット（パケット）、或いはパケットよりも更に小さい符号化単位であるコードブロック単位が考えられるが、本実施の形態では、ユーザ端末がサーバ２０４から受信するデータ単位としてパケット単位を想定する。
【００４１】
図５は、本発明の実施の形態におけるサーバ／クライアント間での通信プロトコルを説明する図であり、パケット単位のリクエスト及びレスポンスの概念を示している。
【００４２】
同図において、ユーザ端末２０１，２０２は、ユーザによる選択操作に応じて、画像のタイル（Tile）番号、resolution level、レイヤ、コンポーネント（component）、並びに位置（position）番号を指定して、対応する画像データをサーバ２０４に要求する。サーバ２０４は、この要求を受信すると、記憶装置２０５に格納されている画像データ５０３（図３に示すデータ構造と同様である）のコードストリームを解析した後、ユーザ端末より指定されたタイル番号、resolution levelとレイヤ、コンポーネント、位置番号に相当するパケットデータを取り出し、その取り出したパケットデータを、ユーザ端末に送信する。以下、この一連の動作を実現するユーザ端末の動作について説明する。
【００４３】
図３の例では、ユーザ端末からタイル１、resolution 0、レイヤ０、コンポーネント０，位置０のデータが要求されており、これを含むタイル１のパケット０のデータがサーバ２０４からユーザ端末に返送されている。
【００４４】
図６は、本発明の実施の形態１乃至６に係るユーザ端末（２０１又は２０２）における受信データのキャッシュ処理を示すフローチャートで、ＣＰＵ１０１が実行するソフトウエア・プログラムに記述された手順を示している。
【００４５】
同図において、まずステップＳ６０１において、ユーザ端末はネットワーク２０３を介して、複数の画像が格納されているサーバ２０４に対して、必要な画像の名前と、その画像データのメインヘッダとを要求する。次にステップＳ６０２に進み、ステップＳ６０１の要求に対してサーバ２０４から送信されるパケットデータのメインヘッダを受信したかを調べ、受信した場合はステップＳ６０３に進み、このユーザ端末は、その受信したメインヘッダに基づいて、図７に示すような画像全体の情報及びキャッシュファイルを管理するためのファイル（以下、メインファイルと記す）７０１を作成し、ステップＳ６０２で取得したメインヘッダを、メインファイル７０１の領域７０３に書き込む。
【００４６】
即ち、ユーザ端末は、メインヘッダを受信すると、ステップＳ６０３にて、図７に示すようなデータフォーマットを有する画像全体の情報を管理するメインファイル７０１を、二次記憶１０３の所望の領域（例えばＣドライブのTempフォルダ）内に、オリジナル画像の名前を先頭に挿入したファイル名のファイルを作成すべく、そのファイル名の入力操作を促す。例えば、ユーザが「image.jp2」ファイルを要求した場合、そのユーザ端末は、「image.iip2k」という名前のメインファイル７０１を二次記憶１０３のフォルダ内に作成する（尚、ステップＳ６０３における処理の詳細については、図９を参照して後述する）。
【００４７】
次にステップＳ６０４に進み、ユーザ端末におけるユーザの選択操作に応じて必要な画像の領域及びresolution、レイヤ、コンポーネントを、ネットワーク２０３を介してサーバ２０４に要求する。このステップＳ６０４におけるユーザの選択操作は、本願の主たる目的であるキャッシュ方法の本質には関係ないので、その説明を省略する。
【００４８】
これによりサーバ２０４は、ユーザ端末から指示された画像部分を、JPEG2000方式のパケット単位で、そのユーザ端末に送信する。
【００４９】
そしてステップＳ６０５に進み、そのパケット（packet）データを受信するとステップＳ６０６に進み、その受信したパケットデータをファイルとして編成し、ステップＳ６０３で作成したメインファイル７０１の当該パケットデータに関連する情報の記述部分を書き換える（尚、ステップＳ６０６における処理の詳細については、図１２を参照して後述する）。
【００５０】
次にステップＳ６０７に進み、更なる画像データを要求する操作がユーザによって行われたかを判断し、要求操作が検出された場合にはステップＳ６０４に戻り、要求操作が検出されない場合にはリターンする。
【００５１】
図９は、本発明の実施の形態１におけるメインファイルの作成処理（ステップＳ６０３）を示すフローチャートである。
【００５２】
同図において、ステップＳ９０１で、サーバ２０４から受信したメインヘッダ（main header）を解析することにより、原画像の高さと幅、最大解像度時のタイルの高さと幅及びresolution level数、レイヤ数、コンポーネント数、位置（position）数、progression orderを取得する。次にステップＳ９０２に進み、原画像の高さと幅、及び最大解像度時のタイルの高さと幅に基づいて、タイル数を計算する。次にステップＳ９０３に進み、ステップＳ９０１で取得したresolution level数、レイヤ数、コンポーネント数、並びに位置数に基づいて、各タイルに含まれるパケット数を計算する。次にステップＳ９０４に進み、JPEG2000方式の符号化データにおいて「zero length packet」であることを示す１バイトの値「０」が入っているファイル（以下、ゼロレングス・パケットファイルと記す）を、ステップＳ９０３で得られた、各タイルに含まれるパケット数と同じ数だけ作成する。例えば前述の「image.jp2」ファイルのタイル番号が「０」、パケット番号が「２」のパケットに対して、１バイトの値「０」が入った「image_tile00000_pkt0002.iip2k」という名前のファイルが、メインファイル「image.iip2k」と同じＣドライブのTempフォルダ（C:/Temp/）に作成される。即ち、このステップ９０４では、各パケットに対して、JPEG2000方式のビットストリーム・シンタックスで規定されているゼロレングス・パケットを示す値（ダミー符号化データ）を持ったメインファイル７０１が作成されることになる。
【００５３】
次にステップＳ９０５に進み、ステップＳ９０１にてメインヘッダを解析して得られたタイル数、resolution level数、レイヤ数、コンポーネント数等の原画像の基本情報、並びにメインヘッダのデータ長を、画像管理情報として、メインファイル７０１の領域７０６に書き込む。尚、このメインファイル７０１の領域７０３には、受信したメインヘッダのデータが書き込まれる。
【００５４】
次にステップＳ９０６に進み、メインファイル７０１の領域７０２に、図７の右側に拡大して示すような、各タイルの基本情報を作成する（尚、このステップＳ９０６の処理の詳細については、図１０を参照して後述する）。次にステップＳ９０７に進み、ステップＳ９０６で作成した各タイルの基本情報を、メインファイル７０１の領域７０２に書き込んで、このメインファイルの作成処理を終了する。
【００５５】
図１０は、本実施の形態１に係るタイル基本情報の作成処理（ステップＳ９０６）を示すフローチャートである。この図１０に示すフローチャートは、メインファイル７０１の作成時にのみ行われる処理を示すフローチャートであって、この処理は初期状態にのみ実行される。尚、ステップＳ９０６では、図１０に示すフローチャートの動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図７に示すメインファイル７０１の領域７０２が作成される。またこの領域７０２の詳細構成は、図８に示すような構成である。
【００５６】
図１０において、まずステップＳ１００１で、図９のステップＳ９０３で既に計算されている、各タイルに含まれるパケット数を取得する。この時点において、ユーザ端末は、サーバ２０４から未だパケットデータを受け取っておらず、上述したステップＳ９０４の処理が実行されることにより、メインファイル７０１の全てのパケットはゼロレングス・パケットである。そこで、ステップＳ１００２では、各タイルのデータ長を、
（タイルヘッダの長さ）＋（タイルに含まれるパケット数）×１バイト
により算出する。
【００５７】
例えば、タイルヘッダに含まれるマーカがSOTマーカのみで、１タイルに３６パケットが含まれている場合、このタイルのデータ長は、１４＋１×３６＝５０[バイト]となる。
【００５８】
次にステップＳ１００３に進み、タイルの番号及びタイルのデータ長から、JPEG2000方式においてタイルのヘッダに含まれるべきSOTマーカが作成される。タイル番号が「０」、含まれるパケット数が「３６」のタイルに対して作成されるSOTマーカの構成とそのデータサイズを図１１に示す。
【００５９】
次にステップＳ１００４に進み、メインファイル７０１に、タイルのデータ長８０４、タイル番号８０５及び、そのタイルに含まれるパケット数８０６、タイルが含むresolution数、レイヤ数、コンポーネント数等を、タイルデータ管理用データ７０４に書き込む。次にステップＳ１００５に進み、メインファイル７０１の領域７０５にタイルヘッダを書き込む。次にステップＳ１００６に進み、パケット番号に「０」を設定し、以後、パケットの番号順にステップＳ１００７以下の処理を繰り返し実行する。
【００６０】
まずステップＳ１００７では、原画像のprogression order に従って、パケット番号に相当するresolution level、レイヤ、コンポーネント、並びにposition番号を特定する。次にステップＳ１００８に進み、注目するパケットのデータ長１と、このパケットデータに対応するゼロレングス・パケットファイルへのポインタ、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル７０１の領域７０２の領域８０２に書き込む。このとき、ゼロレングス・パケットファイルへのポインタとしては、例えばファイル名「image_tile0000_pkt0002.iip2k」等、注目するパケットのデータが入っているファイルを特定する値を領域８０３に書き込む。次にステップＳ１００９に進み、注目すべきパケットのパケット番号を一つ進め、ステップＳ１０１０において、ステップＳ１００７からの一連の処理が、そのタイルに含まれる全てのパケットに対して行われたかどうかを判断し、全てのパケットに関して終わったと判断したらこの動作を終了する。例えば、パケット数が「３６」の場合には、ステップＳ１００９の後のパケット番号が「３６」だった場合は、このフローチャートを終了する。つまり、初期状態では、サーバ２０４の画像ファイルに含まれるパケットの数と同数のゼロレングス・パケットデータを持つデータファイルがユーザ端末にキャッシュされる。
【００６１】
ここまでの処理によって作成されたキャッシュファイルのデータ部分が、ユーザ端末のJPEG2000のデコーダに対してシーケンシャルに送られると、画像データの基本的な情報である画像サイズ等は、そのままの条件の値でデコード処理できる。つまりデコーダでは、全てのパケットは「無い」状態であると判断され、デコード可能である。
【００６２】
図１２は、本発明の実施の形態１に係る、図６のステップＳ６０６におけるメインファイル７０１の上書き処理を示すフローチャートである。
【００６３】
同図において、ステップＳ１２０１では、受信したパケットデータを含むタイル番号とそのパケットの番号とを取得する。例えば、図１３に示すようなバイナリ形式のレスポンスデータが、サーバ２０４からユーザ端末に送られてきた場合、TIdx（１３０１）、PIdx（１３０２）は、それぞれ受信したパケットデータを含むタイル番号とそのパケット番号を表しており、ステップＳ１２０１ではこれらの値が利用される。このレスポンスデータはバイナリ形式に限らず、ＸＭＬのようなテキスト形式でも可能である。ステップＳ１２０２では、受信したパケットデータが書き込まれたファイルを、メインファイル７０１が作成されたフォルダと同一のフォルダ内に作成する。例えば、「image.jp2」ファイルのタイル番号が「０」、パケット番号が「２」のパケットに対しては、上述した図９のステップＳ９０４において、「image_tile00000_pkt0002.iip2k」という名前のゼロレングス・パケットファイルがＣドライブのTempフォルダに作成されているので、そのファイルは新たに受信したパケットデータに書き換えられる。
【００６４】
次にステップＳ１２０３以下の各ステップにおいて、メインファイル７０１のこのパケット（注目するパケット）に関する情報が書き換えられる。ステップＳ１２０３では、メインファイル７０１の作成時に、注目するパケットのデータ長として「１」を書き込んでいた領域８０７を、サーバ２０４から実際に受信したパケットデータのデータ長に書き直す。次にステップＳ１２０４に進み、注目するパケットに対応するゼロレングス・パケットファイルを指し示すポインタ情報８０３を、当該注目するパケットデータが入っているファイルとして、ステップＳ１２０２で作成されたファイルへのポインタ情報に書き換える。例えば、ファイルへのポインタ情報としてファイル名が書かれており、図９のステップＳ９０４において、「image.jp2」ファイルのタイル番号が「０」、パケット番号が「２」のパケットに対して「image_tile00000_pkt0002.iip2k」という名前のゼロレングス・パケットファイルが作成されていて、図１２のステップＳ１２０２において、受信したパケットデータがそのファイルに上書きされた場合は、書き直す必要はない。
【００６５】
次にステップＳ１２０５に進み、注目するパケットが含まれているタイルのデータ長を新たに計算し直し、図８の領域８０１で示されるメインファイル７０１のタイルのデータ長が記述された領域８０４を書き換える。例えば、一度に１つのパケットデータしか更新されないと仮定すると、今回新たに受信したパケットデータのバイト数を５１２バイトとした場合、図８の領域８０４のタイルデータ長は、ゼロレングス・パケットの長さ「１」を引いて、新たに受け取ったバイト数「５１２」を足せばよいので、その値は「５１１」(＝５１２−１)に更新される。次にステップＳ１２０６に進み、パケットデータが含まれるタイルのSOTマーカ７０５のタイルデータ長を記述した部分、即ち図１１におけるＰsot（１１０１）を、領域８０４に上書きした値で更新する。
【００６６】
従って、例えばタイル数が「４」、各タイル内のパケット数が「３６」の場合、本実施の形態では、図１４に示すようなファイルがユーザ端末のＣドライブのTempフォルダに作成される。図６のステップＳ６０３において、メインファイル７０１とゼロレングス・パケットファイルをユーザが作成してからは、図１４に示されたキャッシュのファイル数（１＋３６×４＝）１４５個と、ファイル名とは変更されない。
【００６７】
上述した本実施の形態１に係るキャッシュ方法をユーザ端末２０１（又は２０２）で実行すれば、サーバ２０４に用意された全ての画像データ（差分符号化データ）を受信しなくても、未受信部分のパケットデータは、メインファイル７０１において、図９のステップＳ９０４の処理においてゼロレングス・パケットデータとして埋められるので、JPEG2000の所定フォーマットに準拠したストリームとして格納できる。従って、ユーザ端末では、データの一部を受け取った場合に、サーバ２０４から受信したメインヘッダを書き換えることなく、その作成したメインファイル７０１に含まれるメインヘッダ部分とタイルヘッダ部分とを、それぞれのパケットデータのファイルとして１つのファイルにつなぎ合わせることにより、一般的なJPEG2000デコーダでデコード可能なファイルを当該ユーザ端末において容易に編成することができる。
【００６８】
＜実施の形態２＞
上述した実施の形態１では、ユーザ端末２０１（又は２０２）が未だ受信していないパケットに対して作成されるゼロレングス・パケットファイルを、各パケット毎に作成していた。しかし、このこのゼロレングス・パケットファイルのデータは全て同じ値である。このため、１つの画像に対しては１つのゼロレングス・パケットファイルを作成し、パケットデータを受け取っていない全てのパケットがそのファイルを参照するように構成しても良い。この場合、上述の実施の形態１とは、図６で示したクライアント側（ユーザ端末）のキャッシュ作成処理を示すフローチャートのステップＳ６０３のメインファイル作成処理と、パケットデータ受信後のステップＳ６０６でメインファイルを書き換える処理とが異なる。本実施の形態２では、係る構成について説明する。
【００６９】
図１５は、本発明の実施の形態２に係るメインファイル７０１の作成処理を示すフローチャートであり、ステップＳ９０１乃至ステップＳ９０３、並びにステップＳ９０５及びステップＳ９０７の処理は、図９を参照して説明した前述の実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００７０】
ステップＳ１５０４では、JPEG2000方式の符号化データにおいてゼロレングス・パケットであることを示す１バイトの値「０」が入っているファイル、即ち、ゼロレングス・パケットファイルを１つだけ作成する。例えば、「image.jp2」ファイルに対しては、「image_zero.iip2k」という名前のファイルが、メインファイル「image.iip2k」と同じＣドライブのTempフォルダに作成される。即ち、１画像に対して１ファイルのゼロレングス・パケットが作成される。
【００７１】
そしてステップＳ１５０６では、図７に領域７０２で示すような各タイルの基本情報を作成するが、前述の実施の形態１において作成されたタイルの基本情報の構成とは少々異なるので、図１６を参照して説明する。
【００７２】
図１６は、本実施の形態２に係るタイル基本情報の作成処理（ステップＳ１５０６）を示すフローチャートであり、ステップＳ１００１乃至ステップＳ１００７、並びにステップＳ１００９及びステップＳ１０１０の処理は、図１０を参照して説明した実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００７３】
図１６に示すフローチャートは、前述の実施の形態１の場合と同様に、メインファイル７０１の作成時にのみ実行される処理を示すフローチャートであって、初期状態にのみ行われるフローチャートである。
【００７４】
図１５のステップＳ１５０６では、図１６に示すフローチャートの動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図７に示すメインファイル７０１の領域７０２が作成される。また、この領域７０２は、その内部において、図８に示すような詳細な構成を有する。
【００７５】
ステップＳ１６０８では、注目するパケットのデータ長１と、ゼロレングス・パケットファイルへのポインタ、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル７０１の領域８０２に書き込む。このとき、ゼロレングス・パケットファイルへのポインタとして、例えば「image_zero.iip2k」のようなファイル名等、そのパケットのデータが入っているファイルを特定する値を領域８０３に書き込む。
【００７６】
本実施の形態２では、上述したように、ゼロレングス・パケットファイルを１つしか作成していないので、初期状態においては、メインファイル７０１に書かれている全てのパケットデータファイルへのポインタ、即ち図８の領域８０３が指す示す先は「image_zero.iip2k」となる。
【００７７】
次に、本実施の形態２におけるメインファイル７０１の上書き処理（図６のステップＳ６０６）について、図１７を参照して説明する。
【００７８】
図１７は、本発明の実施の形態２に係るメインファイルの上書き処理を示すフローチャートであり、ステップＳ１２０１乃至ステップＳ１２０３、並びにステップＳ１２０５及びステップＳ１２０６の処理は、図１２を参照して説明した実施の形態１における同一ステップ番号の処理構成と同じであるため、そのステップの説明を省略する。
【００７９】
ステップＳ１７０４では、注目するパケットのデータが入っているファイルとして、ゼロレングス・パケットファイルを指し示していたポインタ８０３の情報を、ステップＳ１２０２で作成されたファイルへのポインタ情報に書き換える。例えば、ポインタ８０３に書き込まれていたファイル名「image_zero.iip2k」は、新たに作成した「image_tile00000_pkt0002.iip2k」というファイル名に書き換えられる。
【００８０】
本実施の形態２によって、ユーザ端末で作成されるキャッシュファイルの構成を図１８に示す。このようなキャッシュファイルの構成を採ることにより、初期状態ではメインファイル１８０１とゼロレングス・パケットファイル１８０２の２つのファイルのみが作成される。初期状態においては、メインファイル７０１のパケットデータファイルを指し示すポインタ８０３には、全てのパケットにおいてゼロレングス・パケットファイル１８０２へのポインタ情報が書かれており、その後、パケットデータをサーバ２０４から受信する度にファイルが増えていく。これにより、前述の実施の形態１の手順と比較して、作成すべきファイルの数を削減することができる。
【００８１】
＜実施の形態３＞
上述した実施の形態１及び２では、ユーザ端末２０１（又は２０２）に未だ受信していないパケットに対して作成される１バイトのゼロレングス・パケットファイルを作成していた。しかし、まだ受信していないパケットデータであることを示す値を、メインファイル７０１のパケットデータ管理部分８０２に明記しておき、ファイルを読み出す際に、１バイトの値「０」を返してもよい。従って本実施の形態３では、前述の実施の形態１及び２とは異なり、ゼロレングス・パケットファイルを作成しない方法について説明する。
【００８２】
本実施の形態３に係る処理構成において、実施の形態１及び２とは、図６に示すキャッシュ作成処理を示すフローチャートのステップＳ６０３で行われるメインファイル作成処理と、ステップＳ６０６で行われる受信パケットに関するデータを上書き処理とが異なる構成となる。
【００８３】
図１９は、本発明の実施の形態３に係るメインファイル７０１の作成処理（図６のＳ６０３に相当）を示すフローチャートであり、ステップＳ９０１乃至ステップＳ９０３、並びにステップＳ９０５及びステップＳ９０７の処理は、図９を参照して前述した実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００８４】
つまり、本実施の形態３におけるメインファイルの作成処理では、図９のステップＳ９０４、即ち、受信していないパケットに関するゼロレングス・パケットファイルを作成するステップを行う必要がない。また、この処理構成に対応して、本実施の形態３では、図１９のステップＳ１９０６において作成されるタイル基本情報は、前述の実施の形態１や２の場合と異なる。そこで、本実施の形態３におけるタイル基本情報の作成処理について、図２０を参照して説明する。
【００８５】
図２０は、本実施の形態３に係るタイル基本情報の作成処理（Ｓ１９０６）を示すフローチャートであり、ステップＳ１０１乃至ステップＳ１００７、並びにステップＳ１００９及びステップＳ１０１０の処理は、図１０を参照して説明した前述の実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００８６】
ステップＳ２００８では、注目するパケットのデータ長１と、このパケットがゼロレングス・パケットであることを示す値、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル７０１の領域８０２に書き込む。このゼロレングス・パケットファイルであることを指し示す値としては、例えば、ＮＵＬＬ等の値を８０３に書き込めばよい。
【００８７】
本実施の形態３では、ゼロレングス・パケットに対するファイルが作成されないので、図２０に示すフローチャートの処理を終了するに際して、初期状態においては、メインファイル７０１だけがユーザ端末で作成される。
【００８８】
ここまでの処理によって作成されたキャッシュファイル中のデータ部分と、各パケットに対応する値「０」とが、メインファイル７０１の記述に従って、JPEG2000のデコーダに対してシーケンシャルに送られると、画像データの基本的な情報である画像サイズ等は、そのままの条件でデコード処理できる。つまり、デコーダでは、全てのパケットは「無い」状態であると判断され、デコード可能である。
【００８９】
図２１は、本実施の形態３に係るメインファイルの上書き処理（Ｓ６０６）を示すフローチャートであり、ステップＳ１２０１乃至ステップＳ１２０３、並びにステップＳ１２０５及びステップＳ１２０６の処理は、図１２を参照して説明した前述の実施の形態１における同一ステップ番号の処理と同じであるため、その説明を省略する。
【００９０】
ステップＳ２１０４では、注目するパケットがゼロレングス・パケットであることを示す値が入っていた領域８０３を、ステップＳ１２０２で作成されたファイルへのポインタ情報に書き換える。例えば、ゼロレングス・パケットであることを示す値ＮＵＬＬが書かれていた領域８０３は、「image_tile00000_pkt0002.iip2k」という名前に書き換えられる。
【００９１】
このようなキャッシュ方法がユーザ端末において行なわれる本実施の形態３によれば、メインファイル７０１と、受信したパケットデータのファイルとだけが作成されるので、前述の実施の形態１及び２と比較して、作成すべきファイル数を削減することができる。
【００９２】
＜実施の形態４＞
上述した実施の形態１乃至３では、全てのファイルを、同一フォルダの下に作成していた。しかしながら、サーバ２０４から受信するパケット数が多い場合には、それらパケットを、複数のフォルダに分散して管理しても良い。
【００９３】
図２２は、本発明の実施の形態４に係る、パケットデータをタイル毎にフォルダに保存する例を説明する図であり、この例では、同一タイルに含まれるパケットデータのファイルが、同じフォルダ内に保存される。
【００９４】
図２２において、オリジナル（原画像）である画像２２０１が４つのタイルに分割されている。サーバ２０４は、ユーザ端末から受信した要求に応じて、画像データからパケットデータ２２０２だけを抜き出し、そのパケットデータ２２０２を当該ユーザ端末に送る。そして、このユーザ端末は、各タイルのために４つのフォルダ２２０３，２２０４，２２０５，２２０６を用意し、サーバ２０４から受信したパケットデータに対応するフォルダに、そのパケットデータから作成されたパケットデータファイルを保存する。
【００９５】
本実施の形態４が上述した実施の形態１乃至３と異なるのは、ユーザ端末がサーバ２０４から受信したデータをキャッシュする動作処理（図６）におけるステップＳ６０３の処理である。
【００９６】
図２３は、本実施の形態４に係る、メインファイル７０１の作成処理（Ｓ６０３）を示すフローチャートで、ステップＳ９０１乃至ステップＳ９０３、並びにステップＳ９０４乃至ステップＳ９０７の処理は、図９を参照して説明した前述の実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００９７】
ステップＳ２３０１では、ステップＳ９０３で得られたパケット数が所定数を超えているかを判断することにより、タイル毎にフォルダを作成するか否かを判断する。この判断は、必ずタイル毎のフォルダを作るというシステムならば必要ないが、例えば、ユーザ端末のＣＰＵ１０１の処理能力を表わす情報に基づいて、１つのフォルダで無理なく扱えるファイル数（閾値）を判断し、その閾値以上のパケット数がある場合にはタイル毎にフォルダを作る。この閾値を得る方法としては様々な方法が考えられるが、本願の特徴ではないので説明を省略する。
【００９８】
ステップＳ２３０１においてタイル毎のフォルダは作らないと判断した場合はステップＳ９０４に進む。一方、ステップＳ２３０１でタイル毎にフォルダを作成すると判断した場合はステップＳ２３０２に進み、ユーザ端末は、タイル数だけフォルダを作成する。例えば、「image.jp2」ファイルが５０個のタイルに分割されている場合、「image_tile0000」から「image_tile0049」という名前のフォルダが、メインファイル「image.iip2k」と同じ、ＣドライブのTempフォルダに作成される。
【００９９】
本実施の形態４では、各パケットに対応するゼロレングス・パケットファイルがそれぞれのフォルダ内に作成される。このため、図２３のステップＳ９０６において作成されるタイル基本情報の詳細な手順は、前述の実施の形態１におけるタイル基本情報の作成処理（図１０）と同様である。この場合、各パケットファイルを指し示すポインタ情報、即ちメインファイル７０１の領域８０３には、ファイル名、例えば「image_tile0000_pkt0002.iip2k」というファイル名が書き込まれても良いし、パスも含めて「C:/Temp/image_tile0000/image_tile0000_pkt0002.iip2k」が書き込まれても良い。
【０１００】
図２４は、本実施の形態４に係るキャッシュファイルの構成を示す概念図である。
【０１０１】
また本実施の形態４では、各パケットに１つのゼロレングス・パケットファイルが作成される実施の形態１と同様の方法のみを記述したが、前述の実施の形態２のように１つのゼロレングス・パケットファイルを作成する方法、或いは実施の形態３のように、ゼロレングス・パケットファイルを一切作らずに、ゼロレングス・パケットであることを示す値、例えばＮＵＬＬを、メインファイル７０１の領域８０３に書き込む方法によっても実現できる。また前述の実施の形態２と同様に、１つのゼロレングス・パケットファイルを作成する場合、そのファイルは、メインファイル７０１と同じフォルダ内、例えばＣドライブのTempフォルダに作成すればよい。
【０１０２】
更に、ユーザ端末において複数画像を扱う可能性がある場合には、画像毎にフォルダを作成しても良い。例えば、図２５に示すようにＣドライブのTempフォルダに画像別のフォルダを作り、更に、そのフォルダをタイル毎のフォルダに分けてもよい。画像別のフォルダの下は、上述した実施の形態１乃至４で説明したキャッシュファイルの作り方が可能である。
【０１０３】
このように本実施の形態４によれば、キャッシュファイルは複数のパケットデータファイルから構成されるが、タイル毎にフォルダに分割することにより、１つのフォルダ内で作成されるファイル数を制限することができるため、ファイルの作成、削除等のユーザ端末のＯＳ（オペレーションシステム）に依存する処理を、上述した他の実施の形態と比較して迅速に行うことができるという利点がある。
【０１０４】
＜実施の形態５＞
本実施の形態では、上述した実施の形態１，２，４において作成されたキャッシュファイルを読み出す方法について、図面を用いて具体的に説明する。
【０１０５】
図２６は、ユーザ端末においてキャッシュファイルを読み出す処理を示すフローチャートであり、上述した実施の形態１，２，４において、ユーザ端末に作成されたキャッシュファイルを読み出す処理の詳細を示す。
【０１０６】
まずステップＳ２６０１で、図６のステップＳ６０３で作成されたメインファイル７０１をオープンする。例えば、「image.jp2」に対して、ＣドライブのTempフォルダに「image.iip2k」というファイル名のメインファイルが作成された場合には、「C:/Temp/image.iip2k」が開かれる。次にステップＳ２６０２に進み、読み出し対象のデータがメインヘッダのデータであるかどうかを判断する。ここでメインヘッダを読まないと判断した時はステップＳ２６０４に進むが、メインヘッダを読むと判断した場合はステップＳ２６０３に進み、メインファイル７０１の、サーバ２０４から取得したメインヘッダのデータがそのまま書き込まれた領域７０３にファイルポインタを移動すると共に、そのメインヘッダのデータを読み出す。そしてステップＳ２６０４では、読み出し対象のデータがタイルヘッダのデータなのかを判断する。ここでタイルヘッダのデータを読み出すと判断した場合は、ステップＳ２６０５に進む。タイルヘッダのデータは読み出さないと判断した場合は、ステップＳ２６０６に進む。
【０１０７】
ステップＳ２６０５では、メインファイル７０１の、読み出し対象のタイルヘッダ７０５が記述されている部分にファイルポインタを移動させて、そのタイルヘッダのデータを読む。
【０１０８】
ここで例えば、ステップＳ２６０５において、タイル番号が「０」から始まっていて、読み出し対象のタイルヘッダがタイル番号１のヘッダの場合には、図７に示すメインファイル７０１の先頭から、画像情報７０６及びメインヘッダデータ７０３、及びタイル番号０に関するデータ７０２を読み飛ばした先に格納されているところの、タイル番号１のタイルに関するデータ７０２の先頭にファイルポインタを移動し、更に、その中のタイルデータの管理用データ７０４の次にあるタイルヘッダデータ７０５の先頭にファイルポインタを移動させ、その後、そのタイルヘッダ７０５のデータを読み出す。
【０１０９】
次にステップＳ２６０６に進み、読み出し対象のデータがパケットデータであるかを判断する。ここでパケットデータを読み出すと判断した場合にはステップＳ２６０７に進み、パケットデータを読み出さないと判断した場合はステップＳ２６０８へ進む。ステップＳ２６０７では、読み出し対象のパケットのデータが格納されているパケットファイルからデータを読み出す（尚、ステップＳ２６０７の詳細については、図２７を参照して後述する）。
【０１１０】
次にステップＳ２６０８に進み、読み出し対象のデータがあるかを判断し、読み出し対象のデータがあればステップＳ２６０２へ戻って前述の処理を繰り返す。一方、ステップＳ２６０８で、読み出し対象のデータを全て読んだと判断した場合にはステップＳ２６０９へ進み、オープンしていたメインファイル７０１をクローズして、この読み出し処理を終了する。
【０１１１】
図２７は、本発明の実施の形態５に係るパケットデータの読み出し処理（ステップＳ２６０７）を示すフローチャートである。
【０１１２】
同図において、まずステップＳ２７０１で、読み出し対象のパケットのデータが入っているファイルへのポインタ８０３の情報に従ってファイル名を取得する。例えば、タイル番号１のパケット番号０のデータを読み出す場合には、メインファイル７０１からタイル番号１に関するタイル情報が書かれている領域７０２を求め、その中からパケット番号が「０」のパケットデータ管理用データ８０２を検索する。そして、そのパケット管理用データ８０２の、そのパケットデータが記述されているファイルへのポインタ８０３の情報に基づいて、そのファイル名を取得する。
【０１１３】
次にステップＳ２７０２に進み、ステップＳ２７０１で取得したファイル名のファイルを開く。例えば、ステップＳ２７０２で取得したファイル名が、ＣドライブのTempフォルダのファイル「image_zero.iip2k」であれば、このフォルダのファイル「image_zero.iip2k」が開かれる。またステップＳ２７０２で取得したファイル名が「C:/Temp/Tile0001/image_tile0000_pkt0000.iip2k」であれば、ＣドライブのTempフォルダのTile0001フォルダにあるファイル「image_tile0000_pkt0000.iip2k」をオープンする。
【０１１４】
次にステップＳ２７０３に進み、ステップＳ２７０２でオープンされたファイル中のデータを読み出す。次にステップＳ２７０４に進み、ステップＳ２７０２でオープンされたファイルをクローズし、パケットデータの読み出し処理を終了する。
【０１１５】
このように本発明の実施の形態５に係る上述した読み出し方法では、パケットデータをユーザ端末が読み出す場合に、メインファイル７０１に記述されている、そのパケットファイルへのポインタ８０３の情報が指し示すファイルをオープンしてから、そのファイルのデータを読み出している。
【０１１６】
このような本実施の形態５によれば、上述した実施の形態１，２，４において作成されたキャッシュファイルを効率良く読み出すことができる。
【０１１７】
＜実施の形態６＞
上述した実施の形態１，２，４では、ユーザ端末に未だ受信していないパケットデータに対しても、ゼロレングス・パケットデータが作成されるので、全てのパケットデータは、ファイル中に書き込まれている。
【０１１８】
しかしながら前述の実施の形態３では、受信したパケットのみに対してファイルが作成されるので、未受信のパケットに対応するファイルは、当該ユーザ端末には存在しない。このため、上述した実施の形態５に係る読み出し方法では、読み出すことのできないパケットデータが存在する。そこで、本実施の形態６では、係る実施の形態３において作成されたキャッシュファイルの読み出し方法について説明する。
【０１１９】
本実施の形態６において、前述の実施の形態５で説明したキャッシュファイルの読み出し処理（図２６）とはステップＳ２６０７の処理構成が異なるので、以下の説明では、この点を中心に説明する。
【０１２０】
図２８は、本発明の実施の形態６に係る、パケットデータの読み出し処理を示すフローチャートであり、ステップＳ２７０２乃至ステップＳ２７０４の処理は、図２７を参照して説明した実施の形態５における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【０１２１】
同図において、まずステップＳ２８０１で、メインファイル７０１の読み出し対象のパケットに対するポインタ８０３の情報を取得する。次にステップＳ２８０２に進み、ステップＳ２８０１で取得したポインタ８０３の情報がパケットデータファイルへのポインタかどうか判断する。例えば、取得した情報が「C:/Temp/image_tile0000_pkt2.iip2k」というファイル名であれば、ファイルへのポインタ情報である判断し、取得した情報がＮＵＬＬだった場合には、ファイルを指し示していないと判断できる。そして、ステップＳ２８０２において、ポインタ情報８０３がファイルを指し示す情報であると判断した場合はステップＳ２７０２に進み、その後の処理は、実施の形態５と同様である。
【０１２２】
一方、ポインタ８０３がファイルを指し示していないと判断された場合には、ステップＳ２８０３に進み、パケットに対するファイルが存在しないので、未受信データであると判断し、ゼロレングス・パケットを示す１バイトの値「０」を読み出した情報として返す。
【０１２３】
このような本実施の形態６によれば、上述した実施の形態３において作成されたキャッシュファイルを効率良く読み出すことができる。
【０１２４】
尚、上述した本実施の形態６は、未受信データに対してゼロレングス・パケットファイルを作成しない場合の読み出し方法であるので、前述の実施の形態４で説明したように、タイル毎または画像毎にフォルダが作成される場合であっても、未受信データにゼロレングス・パケットファイルを作成しない場合には、同様の読み出し方法を適用できる。
【０１２５】
＜実施の形態７＞
上述した実施の形態１乃至６では、それぞれのパケットデータを一つのキャッシュファイルに保存して管理していたが、複数パケットを一つのファイルの中に保存して管理することも可能である。つまり、１つの画像に付き１つのキャッシュファイルで保存管理を行うことができる。
【０１２６】
図２９は、本発明の実施の形態７に係るユーザ端末（画像処理装置：２０１又は２０２）における受信データのキャッシュ処理を示すフローチャートである。尚、この図において、前述の図６と同様の動作をするステップには同じ番号を付している。
【０１２７】
まずステップＳ６０１において、ネットワーク２０３を介して、複数の画像が格納されているサーバ２０４に対して、ユーザ端末から必要な画像の名前と画像のメインヘッダとを要求する。これによりサーバ２０４から送られてくるパケットデータを受信し、ステップＳ６０２で、メインヘッダを受信したかを判断し、メインヘッダを受信するとステップＳ２９０３に進み、その受信したメインヘッダに基づいて、図７に示すような画像全体の情報及びキャッシュデータを管理するための情報、そしてキャッシュデータそのものを保存するファイル（以下、一括キャッシュファイル）を作成し、ステップＳ６０２で取得したメインヘッダを、一括キャッシュファイルの領域７０３に書き込む。ここで作成される一括キャッシュファイルは、前述の実施の形態１乃至４で作成されたメインファイル７０１と同様のデータ形式ではあるが（そのデータ構成は図７参照）、次の２点が異なる。
（１）実際のキャッシュデータそのものも書き込む
（２）図８のパケットデータの管理用データ８０２に含まれるポインタ８０３がオフセット値３００２（図３０）に変更されている。
【０１２８】
図３０は、本実施の形態７に係る一括キャッシュファイル７０１ａ（図３１）の領域７０２ａ（図８の領域７０２に対応）のパケット管理用データ８０２ａの構成を示す図である。
【０１２９】
つまりユーザ端末は、ステップＳ６０２でメインヘッダを受信するとステップＳ６０３に進み、一括キャッシュファイル７０１ａを、二次記憶１０３の所望の領域（例えばＣドライブのTempフォルダ）に、オリジナル画像の名前を先頭に挿入したファイル名のファイルとして作成する。例えば、ユーザが「image.jp2」ファイルを要求した場合、ユーザ端末は、「image.iip2k」というような名前の一括キャッシュファイルを二次記憶１０３のフォルダ内に作成する。
【０１３０】
次にステップＳ６０４に進み、ユーザの選択操作に応じて、必要な画像の領域及びresolution、レイヤ、コンポーネントを、ネットワーク２０３を介して、サーバ２０４に要求する。ここで、ステップＳ６０４におけるユーザの選択操作は、本願の主たる目的であるキャッシュ方法の本質には関らないので詳しい説明は省略する。
【０１３１】
これによりサーバ２０４は、ユーザ端末から指示された画像部分をJPEG2000方式のパケット単位で、そのユーザ端末に送信する。これによりステップＳ６０５で、そのパケットデータを受信するとステップＳ２９０６に進み、その受信したパケットデータに関するキャッシュデータを管理するための情報を書き換え、図３１に示すように、一括キャッシュファイル７０１ａの後ろにアペンドするような形式で、領域３１０１にパケットデータを書き込む。次にステップＳ６０７に進み、更なる画像データを要求する操作がユーザによって行なわれたかを判断し、要求操作が検出された場合にはステップＳ６０４に戻って前述の動作を実行するが、要求操作が検出されない場合にはリターンする。
【０１３２】
図３２は、図２９のステップＳ２９０３における一括キャッシュファイル７０１ａの作成処理を説明するフローチャートである。尚、図９に示すメインファイルの作成処理を示すフローチャートと同様の動作には同じ番号を付している。
【０１３３】
まずステップＳ９０１で、サーバ２０４から受信したメインヘッダを解析することにより、原画像の高さと幅、最大解像度時のタイルの高さと幅及びresolution level数、レイヤ数、コンポーネント数、position数、progression orderを取得する。次にステップＳ９０２に進み、原画像の高さと幅、及び最大解像度でのタイルの高さと幅に基づいてタイル数を計算する。次にステップＳ９０３に進み、ステップＳ９０１で取得したresolution level数、レイヤ数、コンポーネント数、並びにposition数に基づいて、各タイルに含まれるパケット数を計算する。
【０１３４】
次にステップＳ３２０４に進み、ステップＳ９０１にてメインヘッダを解析して得られたタイル数、resolution level数、レイヤ数、コンポーネント数等の原画像の基本情報、ゼロレングス・パケットのデータ、並びにメインヘッダのデータ長を、画像管理情報として、一括キャッシュファイル７０１ａの領域７０６ａ（図３１）に書き込む。この一括キャッシュファイル７０１ａの領域７０３ａには、受信したメインヘッダのデータが書き込まれる。次にステップＳ３２０５に進み、一括キャッシュファイル７０１ａの領域７０２ａに、図３０の右側に拡大して示すような、各タイルの基本情報を作成する。そしてステップＳ３２０６に進み、ステップＳ３２０５で作成された各タイルの基本情報を一括キャッシュファイル７０１ａに書き込んで、この一括キャッシュファイルの作成処理を終了する。
【０１３５】
図３３は、本実施の形態７に係る図３２のステップＳ３２０５におけるタイルの基本情報の作成処理を示すフローチャートで、前述の図１０に示すフローチャートと共通するステップには同じ番号を付している。尚、このステップＳ３２０５では、図３３のフローチャートで示された動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図３０に示す一括キャッシュファイル７０１ａの領域７０２ａが作成される。
【０１３６】
図３３において、まずステップＳ１００１で、図３２のステップＳ９０３で既に計算されている、各タイルに含まれるパケット数を取得する。この時点において、ユーザ端末はサーバ２０４からパケットデータを受け取っておらず、それらの未受信パケットは、全てゼロレングス・パケットとして処理されることが想定されているので、次のステップＳ１００２では、各タイルのデータ長を、
（タイルヘッダの長さ）＋（タイルに含まれるパケット数）×１バイト
により算出する。
【０１３７】
例えば、タイルヘッダに含まれるマーカがSOTマーカのみで、１タイルに３６パケットが含まれている場合、タイルのデータ長は、１４＋１×３６＝５０[バイト]となる。
【０１３８】
次にステップＳ１００３に進み、タイルの番号及びタイルのデータ長から、JPEG2000方式においてタイルのヘッダに含まれるべきSOTマーカを作成する。ここでタイル番号が「０」、含まれるパケット数が「３６」のタイルに対して作成されるSOTマーカの構成と、そのデータサイズ及び具体的な値を図１１に示す。
【０１３９】
次にステップＳ３３０４に進み、タイルのデータ長８０４ａ、タイルの番号８０５ａ及び含まれるパケット数８０６ａ、タイルが含むresolution数、レイヤ数、コンポーネント数等を、一括キャッシュファイル７０１ａのタイルデータ管理用データ７０４ａに書き込む。次にステップＳ３３０５に進み、一括キャッシュファイル７０１ａの領域７０５ａにタイルヘッダを書き込む。次にステップＳ１００６に進み、パケット番号に「０」を設定し、それ以後、パケットの番号順にステップＳ１００７以下の処理を繰り返す。
【０１４０】
ステップＳ１００７では、原画像のprogression order に従って、パケット番号に相当するresolution level、レイヤ、コンポーネント、並びにposition番号を特定する。次にステップＳ３３０８に進み、注目するパケットのデータ長１と、このパケットデータのオフセット値としてステップＳ３２０４で一括キャッシュファイル７０１ａの領域７０６ａに書き込まれたゼロレングス・パケットデータまでのオフセット値、resolution level、レイヤ、コンポーネント、position番号等の、現在注目しているパケットを管理する際に必要になる情報を、一括キャッシュファイル７０１ａの領域８０２ａに書き込む。
【０１４１】
次にステップＳ１００９に進み、注目すべきパケットのパケット番号を一つ進め、ステップＳ１０１０において、ステップＳ１００７からの一連の処理がタイルに含まれる全てのパケットに対して行われたかどうかを判断し、全てのパケットに関して終わったと判断したらこの動作を終了する。例えば、パケット数が「３６」の場合には、ステップＳ１００９の後のパケット番号が「３６」だった場合はこの処理を終了する。
【０１４２】
図３４は、図２９のステップＳ２９０６における一括キャッシュファイル７０１ａの上書きの処理を示すフローチャートで、前述の図１２に示す処理と共通する処理ステップには同じ番号を付している。
【０１４３】
まずステップＳ１２０１では、キャッシュに書き込むパケットが含まれるタイル番号とパケット番号を特定する情報を取得する。次にステップＳ３４０２に進み、一括キャッシュファイル７０１ａのファイル長（last_byte）を取得する。次にステップＳ３４０３に進み、一括キャッシュファイル７０１ａに書かれていたこのパケットデータの長さを、受信したパケット、つまり、これからキャッシュに書き込むパケットのデータ長に書き換える。次にステップＳ３４０４に進み、一括キャッシュファイル７０１ａで、このパケットのデータのオフセット値３００２に、ステップＳ３４０２で取得したlast_byteの値を上書きする。そしてステップＳ３４０５に進み、このパケットに含まれるタイルの情報として、一括キャッシュファイル７０１ａに書かれていた図３０の領域８０１ａのタイルのデータ長８０４ａを再度計算して上書きをする。例えば、キャッシュに書きこむパケットのデータ長が１２８バイトであった場合、この一括キャッシュファイル７０１ａでは、未受信パケットのデータ長をゼロレングス／パケットの長さである１バイトとして計算している。よって、ここで再計算されタイルのデータ長は（１２８−１）＝１２７[バイト]となる。この値を既に書かれていたタイルのデータ長８０４ａに足すことで、新たなタイルのデータ長を求める。次にステップＳ１２０６に進み、前述の図１２と同様に、タイルヘッダ内のタイル長を示す部分を、ステップＳ３４０５で再計算された値で書き換える。次にステップＳ３４０７に進み、一括キャッシュファイル７０１ａにパケットデータ３１０１をアペンドする。つまり、一括キャッシュファイル７０１ａの最後尾に、このパケットデータを書き込み、このルーチンを終了する。
【０１４４】
以上説明した本実施の形態７に係るキャッシュ方法を用いれば、一つの画像について一つのキャッシュファイルを管理すればよいので、データの管理が煩雑になることを避けることができる。
【０１４５】
＜実施の形態８＞
本実施の形態８では、上述した実施の形態７において作成された一括キャッシュファイル７０１ａを読み出す方法を、図面を用いて具体的に説明する。
【０１４６】
図３５は、本発明の実施の形態８に係るユーザ端末において、一括キャッシュファイル７０１ａを読み出す処理を示すフローチャートであり、上述した実施の形態７においてユーザ端末に作成されたキャッシュファイルを読み出す処理の詳細を示している。尚、前述の図２６と同様の動作をするステップには同じ番号を付している。この図２６と異なる点は、図２６でメインファイルと呼ばれていたテーブルだけを格納していたキャッシュファイルを読むのではなく、実施の形態７で一括キャッシュファイルと呼んでいた、テーブルデータと共にパケットデータもキャッシュしているキャッシュファイル７０１ａを読む点にある。従って、図３５のステップＳ３５０７では、ステップＳ２６０１でオープンしたファイルからパケットデータを読み出す点が異なる。
【０１４７】
図３６は、この実施の形態８に係る図３５のステップＳ３５０７におけるパケットデータ読み出し処理を示すフローチャートである。
【０１４８】
まずステップＳ３６０１で、このルーチンで読み出すパケットデータに関して、図３０に示すキャッシュ管理用データ８０２ａのデータ長８０７ａ及びオフセット値３００２から、パケットデータのデータ長（p_length）と一括キャッシュファイル７０１ａの先頭から実際にキャッシュされているパケットデータの先頭までのオフセット値（p_offset）をそれぞれ取得する。次にステップＳ３６０２に進み、ステップＳ３６０１で取得したオフセット値（p_offset）とデータ長（p_length）とを基に、目的のパケットデータを読み出して、この読み出し処理を終了する。
【０１４９】
つまり、一括キャッシュファイル７０１ａの先頭からオフセット値（p_offset）が示すバイトの位置までポインタを移動し、そのポインタ位置からデータ長（p_length）が示すバイト数のデータを読み出すことにより、目的のパケットデータを取得することができる。
【０１５０】
前述の実施の形態７で説明したキャッシュの書き込み方法と、本実施の形態８に係るキャッシュ読み込み方法を用いれば、未受信パケットデータに対応するデータが実際にキャッシュファイル７０１に書き込まれていれば、データ読み出しの際に未受信パケットデータか否かの条件分岐を設けることなく、全て同じ操作で、そのパケットデータを読み出すことができる
＜実施の形態９＞
前述の実施の形態７では、未受信パケットデータの位置にゼロレングス・パケットを挿入して、一括キャッシュファイル７０１ａの領域７０６ａにゼロレングス・パケットを書き込んだ。これに対して本実施の形態９では、未受信パケットデータに対応したゼロレングス・パケットのデータを実際に一括キャッシュファイル７０１ａに書き込むのではなく、未受信であることを示す値を図３０のパケットデータ管理用データ８０２ａのオフセット値を書き込む領域３００２に「NULL」を書き込む。
【０１５１】
このように作成したキャッシュファイル７０１ａを読み出す際に、前述の実施の形態８と異なるのは、図３５のステップＳ３５０７で示されるパケットデータの読み出し方法である。
【０１５２】
図３７は、本発明の実施の形態９に係る、パケットデータの読み出し処理を示すフローチャートで、前述の図３６と共通するステップには同じ番号を付している。この図３７のフローチャートが図３６のフローチャートと異なる点は、図３７におけるステップＳ３７０２の条件分岐以降である。
【０１５３】
ステップＳ３７０２では、ステップＳ３６０１で取得したオフセット値（p_offset）が「NULL」かどうかを判断し、そうであればステップＳ３７０４に進み、NULLでなければステップＳ３６０２に進む。つまりオフセット値（p_offset）がNULLであればこのパケットは未受信であると判断されてステップＳ３７０４に進み、NULL以外の値であれば、受信されキャッシュされているパケットであると判断してステップＳ３６０２に進む。このステップＳ３６０２の処理は、前述の図３６と同様の動作によりパケットデータを読み出す処理である。
【０１５４】
一方、ステップＳ３７０４では、未受信データであるのでキャッシュファイル７０１ａの中にはデータが存在しないため、未受信データの代わりとなるゼロレングス・パケットデータの読み出し用バッファに書き出す。
【０１５５】
本実施の形態９によれば、未受信データの読み出しのためのファイルのシークが削減されるため、データ読み出しの高速化が図れる。
【０１５６】
上述した説明では、便宜上、全てのキャッシュファイルまたは、キャッシュファイル用フォルダを、ＣドライブのTempフォルダに作成したが、キャッシュファイルやキャッシュ用のフォルダが作成される場所は、これに限定されるものではなく、環境変数に応じてキャッシュファイルを作成する場所を適宜変えることも可能である。
【０１５７】
以上説明した画像データのキャッシュ・リード・ライト方法（即ち、実施の形態１乃至４のキャッシュファイルの作成方法、実施の形態５，６に係るキャッシュファイルの読み出し方法、実施の形態７，９に係るキャッシュファイルの作成方法、及び実施の形態８，９に係るキャッシュファイル読み出し方法）によれば、断片的な符号化データを、ユーザ端末２０１（又は２０２）において容易に管理することができ、作成したキャッシュファイルをシーケンシャルにリードすることにより、表示すべき画像の断片的な符号化データを実際には全て受信していない場合であっても、JPEG2000符号化データの形式に準拠した１つの符号化データとして読み出すことが可能になる。このため、一般的な仕様のJPEG2000デコーダを当該ユーザ端末に用意しておけば、当該ユーザ端末は、ユーザ所望の解像度の画像を表示することができる。
【０１５８】
また、キャッシュファイルに１枚の画像の符号化データが完全に充填されていない状態であっても、上述した如くシーケンシャルにリードした結果、ユーザ端末の一次記憶１０２に読み込まれる符号化データは、JPEG2000符号化データ形式に完全に準拠した符号化データであり、このキャッシュファイル用の特別なJPEG2000デコーダは必要ないという利点がある。
【０１５９】
更に、サーバ２０４から断片的に送られてくる途中に符号化データを追加する場合であっても、該当するパケットデータのファイルを置きかえることで高速に追加できるという利点がある。
【０１６０】
［他の実施形態］
尚、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、上述した画像処理装置として動作する装置に供給し、それらシステム或いは装置のコンピュータ（またはＣＰＵやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。或いは、処理対象の画像データを外部より入手可能であって、且つディスプレイへの圧縮画像の表示までの処理であれば、パーソナル・コンピュータ等の一般的な情報処理装置においても、前述した実施形態の機能を実現するソフトウェアのプログラムコードを実行することにより、同目的は達成される。これらの場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体、並びに電気通信回線等を介してコンピュータプログラム製品として取得した当該プログラムコードは、本発明を構成することになる。
【０１６１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１６２】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１６３】
【発明の効果】
以上説明したように本発明によれば、所定形式で断片化された画像データを、その所定の形式に基づいてデコードし、容易にキャッシュすることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る画像処理装置であるコンピュータ機器の概略構成を示すブロック図である。
【図２】本実施の形態に係る通信ネットワークの概略を示す図である。
【図３】 JPEG2000方式の符号化データの構成を示す図である。
【図４】 JPEG2000の解像度スケイラビリティを説明する図である。
【図５】本実施の形態におけるサーバ／クライアント間での通信プロトコルを説明する図である。
【図６】本発明の実施の形態１乃至６に係るユーザ端末における受信データのキャッシュ処理を示すフローチャートである。
【図７】本実施の形態において画像情報全体を管理するメインファイルのデータ構成を説明する図である。
【図８】図７に示すメインファイルに含まれるタイルデータの管理用データの構成図である。
【図９】図６のステップＳ６０３におけるメインファイルの作成処理を示すフローチャートである。
【図１０】図９のステップＳ９０６におけるタイル基本情報の作成処理を示すフローチャートである。
【図１１】 SOTマーカの構成を説明する図である。
【図１２】図６のステップＳ６０６におけるメインファイルの上書き処理を示すフローチャートである。
【図１３】サーバからのレスポンスデータの構成例を示す図である。
【図１４】本実施の形態１におけるユーザ端末におけるキャッシュファイルの構成例を示す図である。
【図１５】本発明の実施の形態２におけるメインファイルの作成処理を示すフローチャートである。
【図１６】図１５のステップＳ１５０６におけるタイル基本情報の作成処理を示すフローチャートである。
【図１７】実施の形態２に係る、メインファイルの上書き処理を示すフローチャートである。
【図１８】実施の形態２に係るユーザ端末におけるキャッシュファイルのデータ構成を示す図である。
【図１９】本発明の実施の形態３に係るメインファイルの作成処理を示すフローチャートである。
【図２０】図１９のステップＳ１９０６で示すタイル基本情報の作成処理を示すフローチャートである。
【図２１】実施の形態３におけるメインファイルの上書き処理（Ｓ６０６）を示すフローチャートである。
【図２２】本発明の実施の形態４に係るパケットデータをタイル毎にフォルダに保存する例を説明する図である。
【図２３】実施の形態４におけるメインファイルの作成処理を示すフローチャートである。
【図２４】実施の形態４におけるキャッシュファイル構成の概念図である。
【図２５】実施の形態４に係る、画像毎のキャッシュ用フォルダを示す概念図である。
【図２６】本発明の実施の形態５に係る、ユーザ端末においてキャッシュファイルを読み出す処理を示すフローチャートである。
【図２７】図２６のステップＳ２６０７におけるパケットデータの読み出し処理を示すフローチャートである。
【図２８】本発明の実施の形態６に係るパケットデータの読み出し処理を示すフローチャートである。
【図２９】本発明の実施の形態７に係るユーザ端末における受信データのキャッシュ処理を示すフローチャートである。
【図３０】本実施の形態７に係る一括キャッシュファイル内のパケットデータの管理用データを説明する図である。
【図３１】実施の形態７に係る一括キャッシュファイル内へのパケットデータの書込み後の様子を説明する図である。
【図３２】図２９のステップＳ２９０３における一括キャッシュファイルの作成処理を示すフローチャートである。
【図３３】図３２のステップＳ３２０５におけるタイル基本情報の作成処理を示すフローである。
【図３４】図２９のステップＳ２９０６におけるキャッシュファイルの上書きを処理を示すフローである。
【図３５】本発明の実施の形態８に係るユーザ端末において、実施の形態７で作成された一括キャッシュファイルを読み出す処理を示すフローチャートである。
【図３６】実施の形態８に係る図３５のステップＳ３５０７におけるパケットデータ読み出し処理を示すフローチャートである。
【図３７】本発明の実施の形態９におけるパケットデータの読み出し処理を示すフローチャートである。
【発明の属する技術分野】
本発明は、符号化された画像データを送受して処理する画像処理装置及びそのデータキャッシュ方法に関するものである。
【０００２】
【従来の技術】
インターネットに接続可能なパーソナルコンピュータ（以下、単にコンピュータと称する）等の画像処理装置のユーザは、その装置が有するウエブブラウザの機能を利用して、インターネット上のＷＷＷ（World Wide Web）サーバにアクセスすることにより、各種の文書データや画像データ等の閲覧を行なっている。
【０００３】
このようなウエブブラウザを利用した情報の閲覧は、インターネット上において各種情報を公開するＷＷＷサーバ（以下、単にサーバと称する場合がある）と、その情報を閲覧するコンピュータ（ユーザ端末）等のクライアントとの間で行われ、クライアント側において、ユーザは、ウエブブラウザを操作することによってサーバ上の情報を閲覧することができる。
【０００４】
このＷＷＷサーバには、情報提供者がインターネット上での公開を希望する各種の情報が、所謂、ホームページといわれるＨＴＭＬ形式で記述された情報で格納されており、その情報は、クライアント側のウエブブラウザの機能により、クライアント側のコンピュータに表示される。またクライアント側のユーザは、ウエブブラウザを操作することにより、ディスプレイに表示されているホームページ内のリンクを辿ってユーザ所望の情報を得ることができる。
【０００５】
また、サーバにて管理されている各種のデータファイルをクライアント側のコンピュータにダウンロードする方法として、File Transfer Protocol（以下、ＦＴＰと略す）なる通信プロトコルを利用する方法がある。このＦＴＰは、通信ネットワークを介して、サーバ上にあるファイルをクライアント側のコンピュータに転送する手順を規定している。
【０００６】
これに対して、上述したＷＷＷサーバとウエブブラウザによってインターネット上で構成される情報閲覧システムにおいては、Hyper Text Transfer Protocol（以下、ＨＴＴＰと略す）なる通信プロトコルを用いて、サーバ／クライアント間の通信が行われており、このＨＴＴＰは、以下のように動作する。
【０００７】
例えば、クライアント側のユーザ端末でウエブブラウザを利用して、ユーザがあるホームページ内のリンク情報が張られている部分をクリックすると、ウエブブラウザは、そのクリックされた部分のリンク情報を解読すると共に、その解読結果に従って新しいＵＲＬ（Uniform Resource Locator）をオープンする。ここで、オープンとは、目的のサーバに対して、ドキュメント情報の送信リクエストを発行することである。
【０００８】
この送信リクエストを受けたサーバは、そのリクエストに対応するドキュメント全体をクライアントに返す。この時、サーバから送られてくるドキュメントは、ヘッダ情報とドキュメント情報本体とからなり、ウエブブラウザにてＵＲＬによって指定されたドキュメント全部のデータであって、当該サーバからクライアント側のコンピュータに一度に転送される文書データである。
【０００９】
この文書データを受信したクライアント側のウエブブラウザは、まず、サーバから受信した文書データに含まれるヘッダ情報を解析する。具体的には、ヘッダ情報に含まれるMIME−TYPEに従って、当該ヘッダ情報に続くドキュメント情報を開くことが可能なアプリケーションを特定する。その後、ウエブブラウザは、ユーザ端末に予めインストールされている、特定されたアプリケーションを起動し、このヘッダ情報の後に続くドキュメント情報本体を、その起動したアプリケーションに渡す。これにより、ウエブブラウザから受信した文書データ（ドキュメント）が、そのユーザ端末のディスプレイに表示され、ユーザによる閲覧が可能になる。
【００１０】
上述したようにＨＴＴＰでは、基本的にクライアント側からあるＵＲＬのオープン要求がサーバ側に伝えられると、サーバ側では、そのＵＲＬで指定されている文書データ全体をクライアント側に送信する動作が行われる。
【００１１】
これに対して、上述したＦＴＰでは、上記のＨＴＴＰの場合と同様に、ＵＲＬを利用してユーザが所望するドキュメントが指定されるが、ここで指定されるドキュメントは、サーバ内で管理されているファイルである。よって、このサーバは、指定されたファイル全体をクライアント側のコンピュータに転送し、クライアント側でファイルとして格納する。
【００１２】
【発明が解決しようとする課題】
上述したＨＴＴＰやＦＴＰ等の通信プロトコルでは、サーバでファイルとして管理されているドキュメントのうち、ダウンロード対象のドキュメントを構成する全データが、ユーザ端末からの送信リクエストに応じて、そのユーザ端末（コンピュータ）に送信されることになる。このため、そのドキュメント内に含まれる、ある画像データファイルだけにアクセスする等といった、あるドキュメントにおける部分的なデータのアクセスを、ユーザ端末から行なうことができないという問題がある。
【００１３】
係る状況に対して、ユーザ端末において所望の画像を表示するためのプロトコルとして、例えばFlashpix/IIPがある。このＩＩＰ（Internet Imaging Protocol）は、Flashpixという画像データのファイルフォーマットに最適なプロトコルになっており、画像データファイルへの部分的なアクセスを実現している。但し、このFlashpix/IIPにおいて、画像データに部分的にアクセスできる単位は、Flashpixで定められたタイル単位である。このFlashpixのタイルは、１つのタイルを構成する画像データ（圧縮されている場合を含む）のみで、そのタイルの画像データを復号（デコード）して再生できる構成になっている。このため、クライアント側のユーザ端末で起動される画像データのデコード及び表示用のアプリケーションは、その受信したタイル画像データを自装置内で一時的に保存（キャッシュ）しなくても、そのタイル単位で画像をデコードして表示できる。
【００１４】
また、近年においては、ISO/IEC-15444に準拠したJPEG(Joint Photographic Experts Group)2000方式の画像符号化の技術が提案されているが、インターネットを含む一般的な通信ネットワーク上に構成されたクライアント／サーバ環境において、上記のFlashpix/IIPをJPEG2000方式に基づいて符号化された画像データ（以下、符号化データ）にそのまま適用した場合、JPEG2000方式における各スケイラビリティの符号化データは、そのスケイラビリティより１つ下のスケイラビリティのデータに基づく差分データとなる。
【００１５】
従って、上述したようにFlashpixでは、１つのタイルを構成する画像データのみで、そのタイルの画像データをデコードできる構成になっているのに対して、JPEG2000方式に基づくデコードを行う場合には、クライアント側のコンピュータ（ユーザ端末）では、今回表示されるべき画像のスケイラビリティより下の符号化データも必要になる。
【００１６】
また、JPEG2000方式に基づく符号化データをクライアント側のコンピュータでキャッシュする場合、そのコンピュータは、サーバ側から部分的な符号化データを受信することになるため、受信した複数の部分的な符号化データを、１つの符号化データのデータファイルとして編成することができる。しかしながら、この場合は、クライアント側での編集処理等が煩雑になり、必要な機能を実現するソフトウエアのコストの低減が容易でないという問題がある。
【００１７】
また、サーバから受信した部分的な符号化データを、クライアント側のコンピュータにおいて独自形式のキャッシュファイルとして構成することも可能である。しかしこのような場合には、クライアントにおいて動作するJPEG2000方式のデコーダが、この独自形式のキャッシュファイルを読み取る処理が複雑になるという問題がある。
【００１８】
本発明は上記従来例に鑑みてなされたもので、所定形式で断片化された画像データを、その所定の形式に基づいてデコードし、キャッシュする画像処理装置とそのデータキャッシュ方法を提供することを目的とする。
【００１９】
【課題を解決するための手段】
上記目的を達成するために本発明の画像処理装置は以下のような構成を備える。即ち、
通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信手段と、
前記受信手段により受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出手段と、
前記算出手段により算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成手段と、
前記ダミーデータ生成手段によって設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換手段と、を有することを特徴とする。
【００２０】
上記目的を達成するために本発明の画像処理装置におけるデータキャッシュ方法は以下のような工程を備える。即ち、
通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置におけるデータキャッシュ方法であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信工程と、
受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出工程と、
前記算出工程で算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成工程と、
前記ダミーデータ生成工程で設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換工程と、を有することを特徴とする。
【００２１】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【００２２】
＜実施の形態１＞
図１は、本発明の実施の形態１に係る画像処理装置としてのコンピュータ機器の概略構成を示すブロック図である。
【００２３】
同図において、ＣＰＵ１０１は、一次記憶１０２に格納されたプログラムを実行して、このコンピュータ機器全体の動作制御を行なう。本実施の形態において、一次記憶ユニット（以下、一次記憶と略称する）１０２は、記憶媒体の一例として、主にメモリが想定され、二次記憶ユニット（以下、二次記憶と略称する）１０３に記憶されたプログラム等が読み込まれて格納される。この二次記憶１０３には、ハードディスク等の記憶媒体を利用することができる。
【００２４】
一般に、一次記憶１０２に格納可能なデータ容量は、二次記憶１０３に格納可能なデータ容量よりも小さく、一次記憶１０２に格納しきれないプログラムやデータ等は二次記憶１０３に格納される。また、長時間記憶しておかなければならないデータ等も二次記憶１０３に格納される。本実施の形態では、このコンピュータ機器の動作制御処理が記述されたソフトウエア・プログラムが二次記憶１０３に格納されており、係るソフトウエア・プログラムは、ＣＰＵ１０１による実行に先立って、一次記憶１０２に読み込まれる。
【００２５】
入力デバイス１０４は、例えば、マウス等の補助入力装置やキーボード等の入力装置であり、ユーザの操作をコンピュータに設定するために用いられる。出力デバイス１０５は、例えば、モニタやプリンタ等である。そして１０６は、外部装置との双方向の通信が可能な通信インターフェースである。
【００２６】
図１に示すこれら各部は、内部バス１０７によって相互にデータ転送可能に接続されており、ＣＰＵ１０１によるコンピュータ機器全体の動作制御を実現している。
【００２７】
本実施の形態に係る画像処理装置としてのコンピュータ機器の構成には、この他にも様々な形態が考えられるが、現在では一般的なコンピュータ機器及びその周辺デバイスを利用可能であり、本実施形態における詳細な説明は省略する。
【００２８】
図２は、本発明の実施の形態における通信ネットワークの概略を示す図であり、所謂サーバ・クライアント環境を示している。
【００２９】
同図において、２０１及び２０２は、クライアントとしてのユーザ端末であり、個々のユーザ端末は、図１を参照して上述した画像処理装置としてのコンピュータ機器（コンピュータシステム）である。ユーザ端末２０１及び２０２とサーバ２０４とは、インターネットを含む一般的な通信ネットワーク（以下、単にネットワークと称する）２０３を介して、互いにデータ通信を行なうことが可能である。
【００３０】
サーバコンピュータ（以下、単にサーバと称する）２０４は、画像ファイルを蓄積するハードディスク等の大容量の記憶装置２０５を備える。本実施の形態において、記憶装置２０５には、JPEG2000符号化方式に従って予め符号化された画像データが数多く格納されている。
【００３１】
以下の説明では、JPEG2000符号化方式に従って符号化された符号化画像データ（符号化データ）のデータファイルを、ユーザ端末２０１（２０２）でキャッシュする方法を具体的な例に従って詳述する。本実施の形態では、具体的に、ユーザ端末２０１（又は２０２）のユーザが、そのユーザ端末にて動作するウエブブラウザを操作しながら、ネットワーク２０３を介して、所望のホームページにアクセスすると共に、そのホームページに含まれるJPEG2000方式の画像データへのリンク部分をクリック（選択操作）することにより、その画像データをユーザが所望するサイズや解像度で取得し、当該ユーザ端末のディスプレイに表示する場合を例にして説明する。
【００３２】
ここで、本実施の形態に係るキャッシュ方法の理解を容易にすべく、一般的なJPEG2000方式の符号化データについて概説する。
【００３３】
図３は、JPEG2000方式の符号化データの構成を示す図であり、Layer-resolution level-component-position progression（以下、ＬＲＣＰと記す）に従って記録されたJPEG2000ファイル（JPEG2000方式の符号化データファイル）の構造を示す。
【００３４】
このＬＲＣＰに準じた場合、一般に、JPEG2000ファイルは、各種の記憶媒体において、レイヤ／resolution／コンポーネント（component）／位置（position）というデータブロックの順に記録される。このようなデータブロックの並び方（配列）は、progression order と呼ばれる。上記位置(position)の概念は、JPEG2000符号化方式では「precinct」という技術の中で考慮されており、ウェーブレット変換を施した後に得られる各解像度の周波数成分において、異なる周波数成分であっても、レイヤ／resolution／コンポーネントが同種／同レベルであれば、オリジナル画像において分割された同じ小領域の位置を示すデータ群として連続的に並ぶ様に配列される様になっている。
【００３５】
図４は、JPEG2000の解像度スケイラビリティを説明する図であり、解像度（画像サイズ）と、resolution番号との関係を示している。
【００３６】
同図に示すように、最も小さい解像度の画像のresolution番号を「０」とし、resolution番号が１つ大きくなると、その画像サイズは幅と高さがそれぞれ２倍になる。
【００３７】
また、図３に示す符号化データの構造において、レイヤ（Layer）番号に対応する各レイヤ内には、resolution番号の小さい順にデータが格納されている。レイヤ番号は、復元されるべき画像の原画（元画像）に対するＳ／Ｎ比に対応しており、レイヤ番号が小さい画像ほど原画に対するＳ／Ｎ比が悪化する傾向を有している。
【００３８】
１つのJPEG2000ファイルにおいて、resolution番号とレイヤ番号、並びにコンポーネント番号の最大値は、JPEG2000方式に準拠したエンコーダによって予め設定されており、それらパラメータは、符号化データに格納されている。各パケットは、そのパケット内に格納されているコードブロック（code-block）の情報を管理しているパケットヘッダ（packet header）部と、各コードブロックの符号化データとから構成されている。
【００３９】
［キャッシュファイルの作成］
図３及び図４に示すようなJPEG2000方式の符号化データを、本実施の形態において以下に説明するキャッシュ手順に従って、ユーザ端末２０１（２０２）においてファイルとして記憶すれば、サーバ２０４に存在する所望の画像に対応する全ての符号化データを当該ユーザ端末に取得しなくても、ユーザが必要な部分（解像度）の符号化データのみを当該サーバから受信して効率的に画像を閲覧することが可能になる。
【００４０】
ユーザ端末における受信データの単位としては、JPEG2000のパケット（パケット）、或いはパケットよりも更に小さい符号化単位であるコードブロック単位が考えられるが、本実施の形態では、ユーザ端末がサーバ２０４から受信するデータ単位としてパケット単位を想定する。
【００４１】
図５は、本発明の実施の形態におけるサーバ／クライアント間での通信プロトコルを説明する図であり、パケット単位のリクエスト及びレスポンスの概念を示している。
【００４２】
同図において、ユーザ端末２０１，２０２は、ユーザによる選択操作に応じて、画像のタイル（Tile）番号、resolution level、レイヤ、コンポーネント（component）、並びに位置（position）番号を指定して、対応する画像データをサーバ２０４に要求する。サーバ２０４は、この要求を受信すると、記憶装置２０５に格納されている画像データ５０３（図３に示すデータ構造と同様である）のコードストリームを解析した後、ユーザ端末より指定されたタイル番号、resolution levelとレイヤ、コンポーネント、位置番号に相当するパケットデータを取り出し、その取り出したパケットデータを、ユーザ端末に送信する。以下、この一連の動作を実現するユーザ端末の動作について説明する。
【００４３】
図３の例では、ユーザ端末からタイル１、resolution 0、レイヤ０、コンポーネント０，位置０のデータが要求されており、これを含むタイル１のパケット０のデータがサーバ２０４からユーザ端末に返送されている。
【００４４】
図６は、本発明の実施の形態１乃至６に係るユーザ端末（２０１又は２０２）における受信データのキャッシュ処理を示すフローチャートで、ＣＰＵ１０１が実行するソフトウエア・プログラムに記述された手順を示している。
【００４５】
同図において、まずステップＳ６０１において、ユーザ端末はネットワーク２０３を介して、複数の画像が格納されているサーバ２０４に対して、必要な画像の名前と、その画像データのメインヘッダとを要求する。次にステップＳ６０２に進み、ステップＳ６０１の要求に対してサーバ２０４から送信されるパケットデータのメインヘッダを受信したかを調べ、受信した場合はステップＳ６０３に進み、このユーザ端末は、その受信したメインヘッダに基づいて、図７に示すような画像全体の情報及びキャッシュファイルを管理するためのファイル（以下、メインファイルと記す）７０１を作成し、ステップＳ６０２で取得したメインヘッダを、メインファイル７０１の領域７０３に書き込む。
【００４６】
即ち、ユーザ端末は、メインヘッダを受信すると、ステップＳ６０３にて、図７に示すようなデータフォーマットを有する画像全体の情報を管理するメインファイル７０１を、二次記憶１０３の所望の領域（例えばＣドライブのTempフォルダ）内に、オリジナル画像の名前を先頭に挿入したファイル名のファイルを作成すべく、そのファイル名の入力操作を促す。例えば、ユーザが「image.jp2」ファイルを要求した場合、そのユーザ端末は、「image.iip2k」という名前のメインファイル７０１を二次記憶１０３のフォルダ内に作成する（尚、ステップＳ６０３における処理の詳細については、図９を参照して後述する）。
【００４７】
次にステップＳ６０４に進み、ユーザ端末におけるユーザの選択操作に応じて必要な画像の領域及びresolution、レイヤ、コンポーネントを、ネットワーク２０３を介してサーバ２０４に要求する。このステップＳ６０４におけるユーザの選択操作は、本願の主たる目的であるキャッシュ方法の本質には関係ないので、その説明を省略する。
【００４８】
これによりサーバ２０４は、ユーザ端末から指示された画像部分を、JPEG2000方式のパケット単位で、そのユーザ端末に送信する。
【００４９】
そしてステップＳ６０５に進み、そのパケット（packet）データを受信するとステップＳ６０６に進み、その受信したパケットデータをファイルとして編成し、ステップＳ６０３で作成したメインファイル７０１の当該パケットデータに関連する情報の記述部分を書き換える（尚、ステップＳ６０６における処理の詳細については、図１２を参照して後述する）。
【００５０】
次にステップＳ６０７に進み、更なる画像データを要求する操作がユーザによって行われたかを判断し、要求操作が検出された場合にはステップＳ６０４に戻り、要求操作が検出されない場合にはリターンする。
【００５１】
図９は、本発明の実施の形態１におけるメインファイルの作成処理（ステップＳ６０３）を示すフローチャートである。
【００５２】
同図において、ステップＳ９０１で、サーバ２０４から受信したメインヘッダ（main header）を解析することにより、原画像の高さと幅、最大解像度時のタイルの高さと幅及びresolution level数、レイヤ数、コンポーネント数、位置（position）数、progression orderを取得する。次にステップＳ９０２に進み、原画像の高さと幅、及び最大解像度時のタイルの高さと幅に基づいて、タイル数を計算する。次にステップＳ９０３に進み、ステップＳ９０１で取得したresolution level数、レイヤ数、コンポーネント数、並びに位置数に基づいて、各タイルに含まれるパケット数を計算する。次にステップＳ９０４に進み、JPEG2000方式の符号化データにおいて「zero length packet」であることを示す１バイトの値「０」が入っているファイル（以下、ゼロレングス・パケットファイルと記す）を、ステップＳ９０３で得られた、各タイルに含まれるパケット数と同じ数だけ作成する。例えば前述の「image.jp2」ファイルのタイル番号が「０」、パケット番号が「２」のパケットに対して、１バイトの値「０」が入った「image_tile00000_pkt0002.iip2k」という名前のファイルが、メインファイル「image.iip2k」と同じＣドライブのTempフォルダ（C:/Temp/）に作成される。即ち、このステップ９０４では、各パケットに対して、JPEG2000方式のビットストリーム・シンタックスで規定されているゼロレングス・パケットを示す値（ダミー符号化データ）を持ったメインファイル７０１が作成されることになる。
【００５３】
次にステップＳ９０５に進み、ステップＳ９０１にてメインヘッダを解析して得られたタイル数、resolution level数、レイヤ数、コンポーネント数等の原画像の基本情報、並びにメインヘッダのデータ長を、画像管理情報として、メインファイル７０１の領域７０６に書き込む。尚、このメインファイル７０１の領域７０３には、受信したメインヘッダのデータが書き込まれる。
【００５４】
次にステップＳ９０６に進み、メインファイル７０１の領域７０２に、図７の右側に拡大して示すような、各タイルの基本情報を作成する（尚、このステップＳ９０６の処理の詳細については、図１０を参照して後述する）。次にステップＳ９０７に進み、ステップＳ９０６で作成した各タイルの基本情報を、メインファイル７０１の領域７０２に書き込んで、このメインファイルの作成処理を終了する。
【００５５】
図１０は、本実施の形態１に係るタイル基本情報の作成処理（ステップＳ９０６）を示すフローチャートである。この図１０に示すフローチャートは、メインファイル７０１の作成時にのみ行われる処理を示すフローチャートであって、この処理は初期状態にのみ実行される。尚、ステップＳ９０６では、図１０に示すフローチャートの動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図７に示すメインファイル７０１の領域７０２が作成される。またこの領域７０２の詳細構成は、図８に示すような構成である。
【００５６】
図１０において、まずステップＳ１００１で、図９のステップＳ９０３で既に計算されている、各タイルに含まれるパケット数を取得する。この時点において、ユーザ端末は、サーバ２０４から未だパケットデータを受け取っておらず、上述したステップＳ９０４の処理が実行されることにより、メインファイル７０１の全てのパケットはゼロレングス・パケットである。そこで、ステップＳ１００２では、各タイルのデータ長を、
（タイルヘッダの長さ）＋（タイルに含まれるパケット数）×１バイト
により算出する。
【００５７】
例えば、タイルヘッダに含まれるマーカがSOTマーカのみで、１タイルに３６パケットが含まれている場合、このタイルのデータ長は、１４＋１×３６＝５０[バイト]となる。
【００５８】
次にステップＳ１００３に進み、タイルの番号及びタイルのデータ長から、JPEG2000方式においてタイルのヘッダに含まれるべきSOTマーカが作成される。タイル番号が「０」、含まれるパケット数が「３６」のタイルに対して作成されるSOTマーカの構成とそのデータサイズを図１１に示す。
【００５９】
次にステップＳ１００４に進み、メインファイル７０１に、タイルのデータ長８０４、タイル番号８０５及び、そのタイルに含まれるパケット数８０６、タイルが含むresolution数、レイヤ数、コンポーネント数等を、タイルデータ管理用データ７０４に書き込む。次にステップＳ１００５に進み、メインファイル７０１の領域７０５にタイルヘッダを書き込む。次にステップＳ１００６に進み、パケット番号に「０」を設定し、以後、パケットの番号順にステップＳ１００７以下の処理を繰り返し実行する。
【００６０】
まずステップＳ１００７では、原画像のprogression order に従って、パケット番号に相当するresolution level、レイヤ、コンポーネント、並びにposition番号を特定する。次にステップＳ１００８に進み、注目するパケットのデータ長１と、このパケットデータに対応するゼロレングス・パケットファイルへのポインタ、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル７０１の領域７０２の領域８０２に書き込む。このとき、ゼロレングス・パケットファイルへのポインタとしては、例えばファイル名「image_tile0000_pkt0002.iip2k」等、注目するパケットのデータが入っているファイルを特定する値を領域８０３に書き込む。次にステップＳ１００９に進み、注目すべきパケットのパケット番号を一つ進め、ステップＳ１０１０において、ステップＳ１００７からの一連の処理が、そのタイルに含まれる全てのパケットに対して行われたかどうかを判断し、全てのパケットに関して終わったと判断したらこの動作を終了する。例えば、パケット数が「３６」の場合には、ステップＳ１００９の後のパケット番号が「３６」だった場合は、このフローチャートを終了する。つまり、初期状態では、サーバ２０４の画像ファイルに含まれるパケットの数と同数のゼロレングス・パケットデータを持つデータファイルがユーザ端末にキャッシュされる。
【００６１】
ここまでの処理によって作成されたキャッシュファイルのデータ部分が、ユーザ端末のJPEG2000のデコーダに対してシーケンシャルに送られると、画像データの基本的な情報である画像サイズ等は、そのままの条件の値でデコード処理できる。つまりデコーダでは、全てのパケットは「無い」状態であると判断され、デコード可能である。
【００６２】
図１２は、本発明の実施の形態１に係る、図６のステップＳ６０６におけるメインファイル７０１の上書き処理を示すフローチャートである。
【００６３】
同図において、ステップＳ１２０１では、受信したパケットデータを含むタイル番号とそのパケットの番号とを取得する。例えば、図１３に示すようなバイナリ形式のレスポンスデータが、サーバ２０４からユーザ端末に送られてきた場合、TIdx（１３０１）、PIdx（１３０２）は、それぞれ受信したパケットデータを含むタイル番号とそのパケット番号を表しており、ステップＳ１２０１ではこれらの値が利用される。このレスポンスデータはバイナリ形式に限らず、ＸＭＬのようなテキスト形式でも可能である。ステップＳ１２０２では、受信したパケットデータが書き込まれたファイルを、メインファイル７０１が作成されたフォルダと同一のフォルダ内に作成する。例えば、「image.jp2」ファイルのタイル番号が「０」、パケット番号が「２」のパケットに対しては、上述した図９のステップＳ９０４において、「image_tile00000_pkt0002.iip2k」という名前のゼロレングス・パケットファイルがＣドライブのTempフォルダに作成されているので、そのファイルは新たに受信したパケットデータに書き換えられる。
【００６４】
次にステップＳ１２０３以下の各ステップにおいて、メインファイル７０１のこのパケット（注目するパケット）に関する情報が書き換えられる。ステップＳ１２０３では、メインファイル７０１の作成時に、注目するパケットのデータ長として「１」を書き込んでいた領域８０７を、サーバ２０４から実際に受信したパケットデータのデータ長に書き直す。次にステップＳ１２０４に進み、注目するパケットに対応するゼロレングス・パケットファイルを指し示すポインタ情報８０３を、当該注目するパケットデータが入っているファイルとして、ステップＳ１２０２で作成されたファイルへのポインタ情報に書き換える。例えば、ファイルへのポインタ情報としてファイル名が書かれており、図９のステップＳ９０４において、「image.jp2」ファイルのタイル番号が「０」、パケット番号が「２」のパケットに対して「image_tile00000_pkt0002.iip2k」という名前のゼロレングス・パケットファイルが作成されていて、図１２のステップＳ１２０２において、受信したパケットデータがそのファイルに上書きされた場合は、書き直す必要はない。
【００６５】
次にステップＳ１２０５に進み、注目するパケットが含まれているタイルのデータ長を新たに計算し直し、図８の領域８０１で示されるメインファイル７０１のタイルのデータ長が記述された領域８０４を書き換える。例えば、一度に１つのパケットデータしか更新されないと仮定すると、今回新たに受信したパケットデータのバイト数を５１２バイトとした場合、図８の領域８０４のタイルデータ長は、ゼロレングス・パケットの長さ「１」を引いて、新たに受け取ったバイト数「５１２」を足せばよいので、その値は「５１１」(＝５１２−１)に更新される。次にステップＳ１２０６に進み、パケットデータが含まれるタイルのSOTマーカ７０５のタイルデータ長を記述した部分、即ち図１１におけるＰsot（１１０１）を、領域８０４に上書きした値で更新する。
【００６６】
従って、例えばタイル数が「４」、各タイル内のパケット数が「３６」の場合、本実施の形態では、図１４に示すようなファイルがユーザ端末のＣドライブのTempフォルダに作成される。図６のステップＳ６０３において、メインファイル７０１とゼロレングス・パケットファイルをユーザが作成してからは、図１４に示されたキャッシュのファイル数（１＋３６×４＝）１４５個と、ファイル名とは変更されない。
【００６７】
上述した本実施の形態１に係るキャッシュ方法をユーザ端末２０１（又は２０２）で実行すれば、サーバ２０４に用意された全ての画像データ（差分符号化データ）を受信しなくても、未受信部分のパケットデータは、メインファイル７０１において、図９のステップＳ９０４の処理においてゼロレングス・パケットデータとして埋められるので、JPEG2000の所定フォーマットに準拠したストリームとして格納できる。従って、ユーザ端末では、データの一部を受け取った場合に、サーバ２０４から受信したメインヘッダを書き換えることなく、その作成したメインファイル７０１に含まれるメインヘッダ部分とタイルヘッダ部分とを、それぞれのパケットデータのファイルとして１つのファイルにつなぎ合わせることにより、一般的なJPEG2000デコーダでデコード可能なファイルを当該ユーザ端末において容易に編成することができる。
【００６８】
＜実施の形態２＞
上述した実施の形態１では、ユーザ端末２０１（又は２０２）が未だ受信していないパケットに対して作成されるゼロレングス・パケットファイルを、各パケット毎に作成していた。しかし、このこのゼロレングス・パケットファイルのデータは全て同じ値である。このため、１つの画像に対しては１つのゼロレングス・パケットファイルを作成し、パケットデータを受け取っていない全てのパケットがそのファイルを参照するように構成しても良い。この場合、上述の実施の形態１とは、図６で示したクライアント側（ユーザ端末）のキャッシュ作成処理を示すフローチャートのステップＳ６０３のメインファイル作成処理と、パケットデータ受信後のステップＳ６０６でメインファイルを書き換える処理とが異なる。本実施の形態２では、係る構成について説明する。
【００６９】
図１５は、本発明の実施の形態２に係るメインファイル７０１の作成処理を示すフローチャートであり、ステップＳ９０１乃至ステップＳ９０３、並びにステップＳ９０５及びステップＳ９０７の処理は、図９を参照して説明した前述の実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００７０】
ステップＳ１５０４では、JPEG2000方式の符号化データにおいてゼロレングス・パケットであることを示す１バイトの値「０」が入っているファイル、即ち、ゼロレングス・パケットファイルを１つだけ作成する。例えば、「image.jp2」ファイルに対しては、「image_zero.iip2k」という名前のファイルが、メインファイル「image.iip2k」と同じＣドライブのTempフォルダに作成される。即ち、１画像に対して１ファイルのゼロレングス・パケットが作成される。
【００７１】
そしてステップＳ１５０６では、図７に領域７０２で示すような各タイルの基本情報を作成するが、前述の実施の形態１において作成されたタイルの基本情報の構成とは少々異なるので、図１６を参照して説明する。
【００７２】
図１６は、本実施の形態２に係るタイル基本情報の作成処理（ステップＳ１５０６）を示すフローチャートであり、ステップＳ１００１乃至ステップＳ１００７、並びにステップＳ１００９及びステップＳ１０１０の処理は、図１０を参照して説明した実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００７３】
図１６に示すフローチャートは、前述の実施の形態１の場合と同様に、メインファイル７０１の作成時にのみ実行される処理を示すフローチャートであって、初期状態にのみ行われるフローチャートである。
【００７４】
図１５のステップＳ１５０６では、図１６に示すフローチャートの動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図７に示すメインファイル７０１の領域７０２が作成される。また、この領域７０２は、その内部において、図８に示すような詳細な構成を有する。
【００７５】
ステップＳ１６０８では、注目するパケットのデータ長１と、ゼロレングス・パケットファイルへのポインタ、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル７０１の領域８０２に書き込む。このとき、ゼロレングス・パケットファイルへのポインタとして、例えば「image_zero.iip2k」のようなファイル名等、そのパケットのデータが入っているファイルを特定する値を領域８０３に書き込む。
【００７６】
本実施の形態２では、上述したように、ゼロレングス・パケットファイルを１つしか作成していないので、初期状態においては、メインファイル７０１に書かれている全てのパケットデータファイルへのポインタ、即ち図８の領域８０３が指す示す先は「image_zero.iip2k」となる。
【００７７】
次に、本実施の形態２におけるメインファイル７０１の上書き処理（図６のステップＳ６０６）について、図１７を参照して説明する。
【００７８】
図１７は、本発明の実施の形態２に係るメインファイルの上書き処理を示すフローチャートであり、ステップＳ１２０１乃至ステップＳ１２０３、並びにステップＳ１２０５及びステップＳ１２０６の処理は、図１２を参照して説明した実施の形態１における同一ステップ番号の処理構成と同じであるため、そのステップの説明を省略する。
【００７９】
ステップＳ１７０４では、注目するパケットのデータが入っているファイルとして、ゼロレングス・パケットファイルを指し示していたポインタ８０３の情報を、ステップＳ１２０２で作成されたファイルへのポインタ情報に書き換える。例えば、ポインタ８０３に書き込まれていたファイル名「image_zero.iip2k」は、新たに作成した「image_tile00000_pkt0002.iip2k」というファイル名に書き換えられる。
【００８０】
本実施の形態２によって、ユーザ端末で作成されるキャッシュファイルの構成を図１８に示す。このようなキャッシュファイルの構成を採ることにより、初期状態ではメインファイル１８０１とゼロレングス・パケットファイル１８０２の２つのファイルのみが作成される。初期状態においては、メインファイル７０１のパケットデータファイルを指し示すポインタ８０３には、全てのパケットにおいてゼロレングス・パケットファイル１８０２へのポインタ情報が書かれており、その後、パケットデータをサーバ２０４から受信する度にファイルが増えていく。これにより、前述の実施の形態１の手順と比較して、作成すべきファイルの数を削減することができる。
【００８１】
＜実施の形態３＞
上述した実施の形態１及び２では、ユーザ端末２０１（又は２０２）に未だ受信していないパケットに対して作成される１バイトのゼロレングス・パケットファイルを作成していた。しかし、まだ受信していないパケットデータであることを示す値を、メインファイル７０１のパケットデータ管理部分８０２に明記しておき、ファイルを読み出す際に、１バイトの値「０」を返してもよい。従って本実施の形態３では、前述の実施の形態１及び２とは異なり、ゼロレングス・パケットファイルを作成しない方法について説明する。
【００８２】
本実施の形態３に係る処理構成において、実施の形態１及び２とは、図６に示すキャッシュ作成処理を示すフローチャートのステップＳ６０３で行われるメインファイル作成処理と、ステップＳ６０６で行われる受信パケットに関するデータを上書き処理とが異なる構成となる。
【００８３】
図１９は、本発明の実施の形態３に係るメインファイル７０１の作成処理（図６のＳ６０３に相当）を示すフローチャートであり、ステップＳ９０１乃至ステップＳ９０３、並びにステップＳ９０５及びステップＳ９０７の処理は、図９を参照して前述した実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００８４】
つまり、本実施の形態３におけるメインファイルの作成処理では、図９のステップＳ９０４、即ち、受信していないパケットに関するゼロレングス・パケットファイルを作成するステップを行う必要がない。また、この処理構成に対応して、本実施の形態３では、図１９のステップＳ１９０６において作成されるタイル基本情報は、前述の実施の形態１や２の場合と異なる。そこで、本実施の形態３におけるタイル基本情報の作成処理について、図２０を参照して説明する。
【００８５】
図２０は、本実施の形態３に係るタイル基本情報の作成処理（Ｓ１９０６）を示すフローチャートであり、ステップＳ１０１乃至ステップＳ１００７、並びにステップＳ１００９及びステップＳ１０１０の処理は、図１０を参照して説明した前述の実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００８６】
ステップＳ２００８では、注目するパケットのデータ長１と、このパケットがゼロレングス・パケットであることを示す値、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル７０１の領域８０２に書き込む。このゼロレングス・パケットファイルであることを指し示す値としては、例えば、ＮＵＬＬ等の値を８０３に書き込めばよい。
【００８７】
本実施の形態３では、ゼロレングス・パケットに対するファイルが作成されないので、図２０に示すフローチャートの処理を終了するに際して、初期状態においては、メインファイル７０１だけがユーザ端末で作成される。
【００８８】
ここまでの処理によって作成されたキャッシュファイル中のデータ部分と、各パケットに対応する値「０」とが、メインファイル７０１の記述に従って、JPEG2000のデコーダに対してシーケンシャルに送られると、画像データの基本的な情報である画像サイズ等は、そのままの条件でデコード処理できる。つまり、デコーダでは、全てのパケットは「無い」状態であると判断され、デコード可能である。
【００８９】
図２１は、本実施の形態３に係るメインファイルの上書き処理（Ｓ６０６）を示すフローチャートであり、ステップＳ１２０１乃至ステップＳ１２０３、並びにステップＳ１２０５及びステップＳ１２０６の処理は、図１２を参照して説明した前述の実施の形態１における同一ステップ番号の処理と同じであるため、その説明を省略する。
【００９０】
ステップＳ２１０４では、注目するパケットがゼロレングス・パケットであることを示す値が入っていた領域８０３を、ステップＳ１２０２で作成されたファイルへのポインタ情報に書き換える。例えば、ゼロレングス・パケットであることを示す値ＮＵＬＬが書かれていた領域８０３は、「image_tile00000_pkt0002.iip2k」という名前に書き換えられる。
【００９１】
このようなキャッシュ方法がユーザ端末において行なわれる本実施の形態３によれば、メインファイル７０１と、受信したパケットデータのファイルとだけが作成されるので、前述の実施の形態１及び２と比較して、作成すべきファイル数を削減することができる。
【００９２】
＜実施の形態４＞
上述した実施の形態１乃至３では、全てのファイルを、同一フォルダの下に作成していた。しかしながら、サーバ２０４から受信するパケット数が多い場合には、それらパケットを、複数のフォルダに分散して管理しても良い。
【００９３】
図２２は、本発明の実施の形態４に係る、パケットデータをタイル毎にフォルダに保存する例を説明する図であり、この例では、同一タイルに含まれるパケットデータのファイルが、同じフォルダ内に保存される。
【００９４】
図２２において、オリジナル（原画像）である画像２２０１が４つのタイルに分割されている。サーバ２０４は、ユーザ端末から受信した要求に応じて、画像データからパケットデータ２２０２だけを抜き出し、そのパケットデータ２２０２を当該ユーザ端末に送る。そして、このユーザ端末は、各タイルのために４つのフォルダ２２０３，２２０４，２２０５，２２０６を用意し、サーバ２０４から受信したパケットデータに対応するフォルダに、そのパケットデータから作成されたパケットデータファイルを保存する。
【００９５】
本実施の形態４が上述した実施の形態１乃至３と異なるのは、ユーザ端末がサーバ２０４から受信したデータをキャッシュする動作処理（図６）におけるステップＳ６０３の処理である。
【００９６】
図２３は、本実施の形態４に係る、メインファイル７０１の作成処理（Ｓ６０３）を示すフローチャートで、ステップＳ９０１乃至ステップＳ９０３、並びにステップＳ９０４乃至ステップＳ９０７の処理は、図９を参照して説明した前述の実施の形態１における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【００９７】
ステップＳ２３０１では、ステップＳ９０３で得られたパケット数が所定数を超えているかを判断することにより、タイル毎にフォルダを作成するか否かを判断する。この判断は、必ずタイル毎のフォルダを作るというシステムならば必要ないが、例えば、ユーザ端末のＣＰＵ１０１の処理能力を表わす情報に基づいて、１つのフォルダで無理なく扱えるファイル数（閾値）を判断し、その閾値以上のパケット数がある場合にはタイル毎にフォルダを作る。この閾値を得る方法としては様々な方法が考えられるが、本願の特徴ではないので説明を省略する。
【００９８】
ステップＳ２３０１においてタイル毎のフォルダは作らないと判断した場合はステップＳ９０４に進む。一方、ステップＳ２３０１でタイル毎にフォルダを作成すると判断した場合はステップＳ２３０２に進み、ユーザ端末は、タイル数だけフォルダを作成する。例えば、「image.jp2」ファイルが５０個のタイルに分割されている場合、「image_tile0000」から「image_tile0049」という名前のフォルダが、メインファイル「image.iip2k」と同じ、ＣドライブのTempフォルダに作成される。
【００９９】
本実施の形態４では、各パケットに対応するゼロレングス・パケットファイルがそれぞれのフォルダ内に作成される。このため、図２３のステップＳ９０６において作成されるタイル基本情報の詳細な手順は、前述の実施の形態１におけるタイル基本情報の作成処理（図１０）と同様である。この場合、各パケットファイルを指し示すポインタ情報、即ちメインファイル７０１の領域８０３には、ファイル名、例えば「image_tile0000_pkt0002.iip2k」というファイル名が書き込まれても良いし、パスも含めて「C:/Temp/image_tile0000/image_tile0000_pkt0002.iip2k」が書き込まれても良い。
【０１００】
図２４は、本実施の形態４に係るキャッシュファイルの構成を示す概念図である。
【０１０１】
また本実施の形態４では、各パケットに１つのゼロレングス・パケットファイルが作成される実施の形態１と同様の方法のみを記述したが、前述の実施の形態２のように１つのゼロレングス・パケットファイルを作成する方法、或いは実施の形態３のように、ゼロレングス・パケットファイルを一切作らずに、ゼロレングス・パケットであることを示す値、例えばＮＵＬＬを、メインファイル７０１の領域８０３に書き込む方法によっても実現できる。また前述の実施の形態２と同様に、１つのゼロレングス・パケットファイルを作成する場合、そのファイルは、メインファイル７０１と同じフォルダ内、例えばＣドライブのTempフォルダに作成すればよい。
【０１０２】
更に、ユーザ端末において複数画像を扱う可能性がある場合には、画像毎にフォルダを作成しても良い。例えば、図２５に示すようにＣドライブのTempフォルダに画像別のフォルダを作り、更に、そのフォルダをタイル毎のフォルダに分けてもよい。画像別のフォルダの下は、上述した実施の形態１乃至４で説明したキャッシュファイルの作り方が可能である。
【０１０３】
このように本実施の形態４によれば、キャッシュファイルは複数のパケットデータファイルから構成されるが、タイル毎にフォルダに分割することにより、１つのフォルダ内で作成されるファイル数を制限することができるため、ファイルの作成、削除等のユーザ端末のＯＳ（オペレーションシステム）に依存する処理を、上述した他の実施の形態と比較して迅速に行うことができるという利点がある。
【０１０４】
＜実施の形態５＞
本実施の形態では、上述した実施の形態１，２，４において作成されたキャッシュファイルを読み出す方法について、図面を用いて具体的に説明する。
【０１０５】
図２６は、ユーザ端末においてキャッシュファイルを読み出す処理を示すフローチャートであり、上述した実施の形態１，２，４において、ユーザ端末に作成されたキャッシュファイルを読み出す処理の詳細を示す。
【０１０６】
まずステップＳ２６０１で、図６のステップＳ６０３で作成されたメインファイル７０１をオープンする。例えば、「image.jp2」に対して、ＣドライブのTempフォルダに「image.iip2k」というファイル名のメインファイルが作成された場合には、「C:/Temp/image.iip2k」が開かれる。次にステップＳ２６０２に進み、読み出し対象のデータがメインヘッダのデータであるかどうかを判断する。ここでメインヘッダを読まないと判断した時はステップＳ２６０４に進むが、メインヘッダを読むと判断した場合はステップＳ２６０３に進み、メインファイル７０１の、サーバ２０４から取得したメインヘッダのデータがそのまま書き込まれた領域７０３にファイルポインタを移動すると共に、そのメインヘッダのデータを読み出す。そしてステップＳ２６０４では、読み出し対象のデータがタイルヘッダのデータなのかを判断する。ここでタイルヘッダのデータを読み出すと判断した場合は、ステップＳ２６０５に進む。タイルヘッダのデータは読み出さないと判断した場合は、ステップＳ２６０６に進む。
【０１０７】
ステップＳ２６０５では、メインファイル７０１の、読み出し対象のタイルヘッダ７０５が記述されている部分にファイルポインタを移動させて、そのタイルヘッダのデータを読む。
【０１０８】
ここで例えば、ステップＳ２６０５において、タイル番号が「０」から始まっていて、読み出し対象のタイルヘッダがタイル番号１のヘッダの場合には、図７に示すメインファイル７０１の先頭から、画像情報７０６及びメインヘッダデータ７０３、及びタイル番号０に関するデータ７０２を読み飛ばした先に格納されているところの、タイル番号１のタイルに関するデータ７０２の先頭にファイルポインタを移動し、更に、その中のタイルデータの管理用データ７０４の次にあるタイルヘッダデータ７０５の先頭にファイルポインタを移動させ、その後、そのタイルヘッダ７０５のデータを読み出す。
【０１０９】
次にステップＳ２６０６に進み、読み出し対象のデータがパケットデータであるかを判断する。ここでパケットデータを読み出すと判断した場合にはステップＳ２６０７に進み、パケットデータを読み出さないと判断した場合はステップＳ２６０８へ進む。ステップＳ２６０７では、読み出し対象のパケットのデータが格納されているパケットファイルからデータを読み出す（尚、ステップＳ２６０７の詳細については、図２７を参照して後述する）。
【０１１０】
次にステップＳ２６０８に進み、読み出し対象のデータがあるかを判断し、読み出し対象のデータがあればステップＳ２６０２へ戻って前述の処理を繰り返す。一方、ステップＳ２６０８で、読み出し対象のデータを全て読んだと判断した場合にはステップＳ２６０９へ進み、オープンしていたメインファイル７０１をクローズして、この読み出し処理を終了する。
【０１１１】
図２７は、本発明の実施の形態５に係るパケットデータの読み出し処理（ステップＳ２６０７）を示すフローチャートである。
【０１１２】
同図において、まずステップＳ２７０１で、読み出し対象のパケットのデータが入っているファイルへのポインタ８０３の情報に従ってファイル名を取得する。例えば、タイル番号１のパケット番号０のデータを読み出す場合には、メインファイル７０１からタイル番号１に関するタイル情報が書かれている領域７０２を求め、その中からパケット番号が「０」のパケットデータ管理用データ８０２を検索する。そして、そのパケット管理用データ８０２の、そのパケットデータが記述されているファイルへのポインタ８０３の情報に基づいて、そのファイル名を取得する。
【０１１３】
次にステップＳ２７０２に進み、ステップＳ２７０１で取得したファイル名のファイルを開く。例えば、ステップＳ２７０２で取得したファイル名が、ＣドライブのTempフォルダのファイル「image_zero.iip2k」であれば、このフォルダのファイル「image_zero.iip2k」が開かれる。またステップＳ２７０２で取得したファイル名が「C:/Temp/Tile0001/image_tile0000_pkt0000.iip2k」であれば、ＣドライブのTempフォルダのTile0001フォルダにあるファイル「image_tile0000_pkt0000.iip2k」をオープンする。
【０１１４】
次にステップＳ２７０３に進み、ステップＳ２７０２でオープンされたファイル中のデータを読み出す。次にステップＳ２７０４に進み、ステップＳ２７０２でオープンされたファイルをクローズし、パケットデータの読み出し処理を終了する。
【０１１５】
このように本発明の実施の形態５に係る上述した読み出し方法では、パケットデータをユーザ端末が読み出す場合に、メインファイル７０１に記述されている、そのパケットファイルへのポインタ８０３の情報が指し示すファイルをオープンしてから、そのファイルのデータを読み出している。
【０１１６】
このような本実施の形態５によれば、上述した実施の形態１，２，４において作成されたキャッシュファイルを効率良く読み出すことができる。
【０１１７】
＜実施の形態６＞
上述した実施の形態１，２，４では、ユーザ端末に未だ受信していないパケットデータに対しても、ゼロレングス・パケットデータが作成されるので、全てのパケットデータは、ファイル中に書き込まれている。
【０１１８】
しかしながら前述の実施の形態３では、受信したパケットのみに対してファイルが作成されるので、未受信のパケットに対応するファイルは、当該ユーザ端末には存在しない。このため、上述した実施の形態５に係る読み出し方法では、読み出すことのできないパケットデータが存在する。そこで、本実施の形態６では、係る実施の形態３において作成されたキャッシュファイルの読み出し方法について説明する。
【０１１９】
本実施の形態６において、前述の実施の形態５で説明したキャッシュファイルの読み出し処理（図２６）とはステップＳ２６０７の処理構成が異なるので、以下の説明では、この点を中心に説明する。
【０１２０】
図２８は、本発明の実施の形態６に係る、パケットデータの読み出し処理を示すフローチャートであり、ステップＳ２７０２乃至ステップＳ２７０４の処理は、図２７を参照して説明した実施の形態５における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【０１２１】
同図において、まずステップＳ２８０１で、メインファイル７０１の読み出し対象のパケットに対するポインタ８０３の情報を取得する。次にステップＳ２８０２に進み、ステップＳ２８０１で取得したポインタ８０３の情報がパケットデータファイルへのポインタかどうか判断する。例えば、取得した情報が「C:/Temp/image_tile0000_pkt2.iip2k」というファイル名であれば、ファイルへのポインタ情報である判断し、取得した情報がＮＵＬＬだった場合には、ファイルを指し示していないと判断できる。そして、ステップＳ２８０２において、ポインタ情報８０３がファイルを指し示す情報であると判断した場合はステップＳ２７０２に進み、その後の処理は、実施の形態５と同様である。
【０１２２】
一方、ポインタ８０３がファイルを指し示していないと判断された場合には、ステップＳ２８０３に進み、パケットに対するファイルが存在しないので、未受信データであると判断し、ゼロレングス・パケットを示す１バイトの値「０」を読み出した情報として返す。
【０１２３】
このような本実施の形態６によれば、上述した実施の形態３において作成されたキャッシュファイルを効率良く読み出すことができる。
【０１２４】
尚、上述した本実施の形態６は、未受信データに対してゼロレングス・パケットファイルを作成しない場合の読み出し方法であるので、前述の実施の形態４で説明したように、タイル毎または画像毎にフォルダが作成される場合であっても、未受信データにゼロレングス・パケットファイルを作成しない場合には、同様の読み出し方法を適用できる。
【０１２５】
＜実施の形態７＞
上述した実施の形態１乃至６では、それぞれのパケットデータを一つのキャッシュファイルに保存して管理していたが、複数パケットを一つのファイルの中に保存して管理することも可能である。つまり、１つの画像に付き１つのキャッシュファイルで保存管理を行うことができる。
【０１２６】
図２９は、本発明の実施の形態７に係るユーザ端末（画像処理装置：２０１又は２０２）における受信データのキャッシュ処理を示すフローチャートである。尚、この図において、前述の図６と同様の動作をするステップには同じ番号を付している。
【０１２７】
まずステップＳ６０１において、ネットワーク２０３を介して、複数の画像が格納されているサーバ２０４に対して、ユーザ端末から必要な画像の名前と画像のメインヘッダとを要求する。これによりサーバ２０４から送られてくるパケットデータを受信し、ステップＳ６０２で、メインヘッダを受信したかを判断し、メインヘッダを受信するとステップＳ２９０３に進み、その受信したメインヘッダに基づいて、図７に示すような画像全体の情報及びキャッシュデータを管理するための情報、そしてキャッシュデータそのものを保存するファイル（以下、一括キャッシュファイル）を作成し、ステップＳ６０２で取得したメインヘッダを、一括キャッシュファイルの領域７０３に書き込む。ここで作成される一括キャッシュファイルは、前述の実施の形態１乃至４で作成されたメインファイル７０１と同様のデータ形式ではあるが（そのデータ構成は図７参照）、次の２点が異なる。
（１）実際のキャッシュデータそのものも書き込む
（２）図８のパケットデータの管理用データ８０２に含まれるポインタ８０３がオフセット値３００２（図３０）に変更されている。
【０１２８】
図３０は、本実施の形態７に係る一括キャッシュファイル７０１ａ（図３１）の領域７０２ａ（図８の領域７０２に対応）のパケット管理用データ８０２ａの構成を示す図である。
【０１２９】
つまりユーザ端末は、ステップＳ６０２でメインヘッダを受信するとステップＳ６０３に進み、一括キャッシュファイル７０１ａを、二次記憶１０３の所望の領域（例えばＣドライブのTempフォルダ）に、オリジナル画像の名前を先頭に挿入したファイル名のファイルとして作成する。例えば、ユーザが「image.jp2」ファイルを要求した場合、ユーザ端末は、「image.iip2k」というような名前の一括キャッシュファイルを二次記憶１０３のフォルダ内に作成する。
【０１３０】
次にステップＳ６０４に進み、ユーザの選択操作に応じて、必要な画像の領域及びresolution、レイヤ、コンポーネントを、ネットワーク２０３を介して、サーバ２０４に要求する。ここで、ステップＳ６０４におけるユーザの選択操作は、本願の主たる目的であるキャッシュ方法の本質には関らないので詳しい説明は省略する。
【０１３１】
これによりサーバ２０４は、ユーザ端末から指示された画像部分をJPEG2000方式のパケット単位で、そのユーザ端末に送信する。これによりステップＳ６０５で、そのパケットデータを受信するとステップＳ２９０６に進み、その受信したパケットデータに関するキャッシュデータを管理するための情報を書き換え、図３１に示すように、一括キャッシュファイル７０１ａの後ろにアペンドするような形式で、領域３１０１にパケットデータを書き込む。次にステップＳ６０７に進み、更なる画像データを要求する操作がユーザによって行なわれたかを判断し、要求操作が検出された場合にはステップＳ６０４に戻って前述の動作を実行するが、要求操作が検出されない場合にはリターンする。
【０１３２】
図３２は、図２９のステップＳ２９０３における一括キャッシュファイル７０１ａの作成処理を説明するフローチャートである。尚、図９に示すメインファイルの作成処理を示すフローチャートと同様の動作には同じ番号を付している。
【０１３３】
まずステップＳ９０１で、サーバ２０４から受信したメインヘッダを解析することにより、原画像の高さと幅、最大解像度時のタイルの高さと幅及びresolution level数、レイヤ数、コンポーネント数、position数、progression orderを取得する。次にステップＳ９０２に進み、原画像の高さと幅、及び最大解像度でのタイルの高さと幅に基づいてタイル数を計算する。次にステップＳ９０３に進み、ステップＳ９０１で取得したresolution level数、レイヤ数、コンポーネント数、並びにposition数に基づいて、各タイルに含まれるパケット数を計算する。
【０１３４】
次にステップＳ３２０４に進み、ステップＳ９０１にてメインヘッダを解析して得られたタイル数、resolution level数、レイヤ数、コンポーネント数等の原画像の基本情報、ゼロレングス・パケットのデータ、並びにメインヘッダのデータ長を、画像管理情報として、一括キャッシュファイル７０１ａの領域７０６ａ（図３１）に書き込む。この一括キャッシュファイル７０１ａの領域７０３ａには、受信したメインヘッダのデータが書き込まれる。次にステップＳ３２０５に進み、一括キャッシュファイル７０１ａの領域７０２ａに、図３０の右側に拡大して示すような、各タイルの基本情報を作成する。そしてステップＳ３２０６に進み、ステップＳ３２０５で作成された各タイルの基本情報を一括キャッシュファイル７０１ａに書き込んで、この一括キャッシュファイルの作成処理を終了する。
【０１３５】
図３３は、本実施の形態７に係る図３２のステップＳ３２０５におけるタイルの基本情報の作成処理を示すフローチャートで、前述の図１０に示すフローチャートと共通するステップには同じ番号を付している。尚、このステップＳ３２０５では、図３３のフローチャートで示された動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図３０に示す一括キャッシュファイル７０１ａの領域７０２ａが作成される。
【０１３６】
図３３において、まずステップＳ１００１で、図３２のステップＳ９０３で既に計算されている、各タイルに含まれるパケット数を取得する。この時点において、ユーザ端末はサーバ２０４からパケットデータを受け取っておらず、それらの未受信パケットは、全てゼロレングス・パケットとして処理されることが想定されているので、次のステップＳ１００２では、各タイルのデータ長を、
（タイルヘッダの長さ）＋（タイルに含まれるパケット数）×１バイト
により算出する。
【０１３７】
例えば、タイルヘッダに含まれるマーカがSOTマーカのみで、１タイルに３６パケットが含まれている場合、タイルのデータ長は、１４＋１×３６＝５０[バイト]となる。
【０１３８】
次にステップＳ１００３に進み、タイルの番号及びタイルのデータ長から、JPEG2000方式においてタイルのヘッダに含まれるべきSOTマーカを作成する。ここでタイル番号が「０」、含まれるパケット数が「３６」のタイルに対して作成されるSOTマーカの構成と、そのデータサイズ及び具体的な値を図１１に示す。
【０１３９】
次にステップＳ３３０４に進み、タイルのデータ長８０４ａ、タイルの番号８０５ａ及び含まれるパケット数８０６ａ、タイルが含むresolution数、レイヤ数、コンポーネント数等を、一括キャッシュファイル７０１ａのタイルデータ管理用データ７０４ａに書き込む。次にステップＳ３３０５に進み、一括キャッシュファイル７０１ａの領域７０５ａにタイルヘッダを書き込む。次にステップＳ１００６に進み、パケット番号に「０」を設定し、それ以後、パケットの番号順にステップＳ１００７以下の処理を繰り返す。
【０１４０】
ステップＳ１００７では、原画像のprogression order に従って、パケット番号に相当するresolution level、レイヤ、コンポーネント、並びにposition番号を特定する。次にステップＳ３３０８に進み、注目するパケットのデータ長１と、このパケットデータのオフセット値としてステップＳ３２０４で一括キャッシュファイル７０１ａの領域７０６ａに書き込まれたゼロレングス・パケットデータまでのオフセット値、resolution level、レイヤ、コンポーネント、position番号等の、現在注目しているパケットを管理する際に必要になる情報を、一括キャッシュファイル７０１ａの領域８０２ａに書き込む。
【０１４１】
次にステップＳ１００９に進み、注目すべきパケットのパケット番号を一つ進め、ステップＳ１０１０において、ステップＳ１００７からの一連の処理がタイルに含まれる全てのパケットに対して行われたかどうかを判断し、全てのパケットに関して終わったと判断したらこの動作を終了する。例えば、パケット数が「３６」の場合には、ステップＳ１００９の後のパケット番号が「３６」だった場合はこの処理を終了する。
【０１４２】
図３４は、図２９のステップＳ２９０６における一括キャッシュファイル７０１ａの上書きの処理を示すフローチャートで、前述の図１２に示す処理と共通する処理ステップには同じ番号を付している。
【０１４３】
まずステップＳ１２０１では、キャッシュに書き込むパケットが含まれるタイル番号とパケット番号を特定する情報を取得する。次にステップＳ３４０２に進み、一括キャッシュファイル７０１ａのファイル長（last_byte）を取得する。次にステップＳ３４０３に進み、一括キャッシュファイル７０１ａに書かれていたこのパケットデータの長さを、受信したパケット、つまり、これからキャッシュに書き込むパケットのデータ長に書き換える。次にステップＳ３４０４に進み、一括キャッシュファイル７０１ａで、このパケットのデータのオフセット値３００２に、ステップＳ３４０２で取得したlast_byteの値を上書きする。そしてステップＳ３４０５に進み、このパケットに含まれるタイルの情報として、一括キャッシュファイル７０１ａに書かれていた図３０の領域８０１ａのタイルのデータ長８０４ａを再度計算して上書きをする。例えば、キャッシュに書きこむパケットのデータ長が１２８バイトであった場合、この一括キャッシュファイル７０１ａでは、未受信パケットのデータ長をゼロレングス／パケットの長さである１バイトとして計算している。よって、ここで再計算されタイルのデータ長は（１２８−１）＝１２７[バイト]となる。この値を既に書かれていたタイルのデータ長８０４ａに足すことで、新たなタイルのデータ長を求める。次にステップＳ１２０６に進み、前述の図１２と同様に、タイルヘッダ内のタイル長を示す部分を、ステップＳ３４０５で再計算された値で書き換える。次にステップＳ３４０７に進み、一括キャッシュファイル７０１ａにパケットデータ３１０１をアペンドする。つまり、一括キャッシュファイル７０１ａの最後尾に、このパケットデータを書き込み、このルーチンを終了する。
【０１４４】
以上説明した本実施の形態７に係るキャッシュ方法を用いれば、一つの画像について一つのキャッシュファイルを管理すればよいので、データの管理が煩雑になることを避けることができる。
【０１４５】
＜実施の形態８＞
本実施の形態８では、上述した実施の形態７において作成された一括キャッシュファイル７０１ａを読み出す方法を、図面を用いて具体的に説明する。
【０１４６】
図３５は、本発明の実施の形態８に係るユーザ端末において、一括キャッシュファイル７０１ａを読み出す処理を示すフローチャートであり、上述した実施の形態７においてユーザ端末に作成されたキャッシュファイルを読み出す処理の詳細を示している。尚、前述の図２６と同様の動作をするステップには同じ番号を付している。この図２６と異なる点は、図２６でメインファイルと呼ばれていたテーブルだけを格納していたキャッシュファイルを読むのではなく、実施の形態７で一括キャッシュファイルと呼んでいた、テーブルデータと共にパケットデータもキャッシュしているキャッシュファイル７０１ａを読む点にある。従って、図３５のステップＳ３５０７では、ステップＳ２６０１でオープンしたファイルからパケットデータを読み出す点が異なる。
【０１４７】
図３６は、この実施の形態８に係る図３５のステップＳ３５０７におけるパケットデータ読み出し処理を示すフローチャートである。
【０１４８】
まずステップＳ３６０１で、このルーチンで読み出すパケットデータに関して、図３０に示すキャッシュ管理用データ８０２ａのデータ長８０７ａ及びオフセット値３００２から、パケットデータのデータ長（p_length）と一括キャッシュファイル７０１ａの先頭から実際にキャッシュされているパケットデータの先頭までのオフセット値（p_offset）をそれぞれ取得する。次にステップＳ３６０２に進み、ステップＳ３６０１で取得したオフセット値（p_offset）とデータ長（p_length）とを基に、目的のパケットデータを読み出して、この読み出し処理を終了する。
【０１４９】
つまり、一括キャッシュファイル７０１ａの先頭からオフセット値（p_offset）が示すバイトの位置までポインタを移動し、そのポインタ位置からデータ長（p_length）が示すバイト数のデータを読み出すことにより、目的のパケットデータを取得することができる。
【０１５０】
前述の実施の形態７で説明したキャッシュの書き込み方法と、本実施の形態８に係るキャッシュ読み込み方法を用いれば、未受信パケットデータに対応するデータが実際にキャッシュファイル７０１に書き込まれていれば、データ読み出しの際に未受信パケットデータか否かの条件分岐を設けることなく、全て同じ操作で、そのパケットデータを読み出すことができる
＜実施の形態９＞
前述の実施の形態７では、未受信パケットデータの位置にゼロレングス・パケットを挿入して、一括キャッシュファイル７０１ａの領域７０６ａにゼロレングス・パケットを書き込んだ。これに対して本実施の形態９では、未受信パケットデータに対応したゼロレングス・パケットのデータを実際に一括キャッシュファイル７０１ａに書き込むのではなく、未受信であることを示す値を図３０のパケットデータ管理用データ８０２ａのオフセット値を書き込む領域３００２に「NULL」を書き込む。
【０１５１】
このように作成したキャッシュファイル７０１ａを読み出す際に、前述の実施の形態８と異なるのは、図３５のステップＳ３５０７で示されるパケットデータの読み出し方法である。
【０１５２】
図３７は、本発明の実施の形態９に係る、パケットデータの読み出し処理を示すフローチャートで、前述の図３６と共通するステップには同じ番号を付している。この図３７のフローチャートが図３６のフローチャートと異なる点は、図３７におけるステップＳ３７０２の条件分岐以降である。
【０１５３】
ステップＳ３７０２では、ステップＳ３６０１で取得したオフセット値（p_offset）が「NULL」かどうかを判断し、そうであればステップＳ３７０４に進み、NULLでなければステップＳ３６０２に進む。つまりオフセット値（p_offset）がNULLであればこのパケットは未受信であると判断されてステップＳ３７０４に進み、NULL以外の値であれば、受信されキャッシュされているパケットであると判断してステップＳ３６０２に進む。このステップＳ３６０２の処理は、前述の図３６と同様の動作によりパケットデータを読み出す処理である。
【０１５４】
一方、ステップＳ３７０４では、未受信データであるのでキャッシュファイル７０１ａの中にはデータが存在しないため、未受信データの代わりとなるゼロレングス・パケットデータの読み出し用バッファに書き出す。
【０１５５】
本実施の形態９によれば、未受信データの読み出しのためのファイルのシークが削減されるため、データ読み出しの高速化が図れる。
【０１５６】
上述した説明では、便宜上、全てのキャッシュファイルまたは、キャッシュファイル用フォルダを、ＣドライブのTempフォルダに作成したが、キャッシュファイルやキャッシュ用のフォルダが作成される場所は、これに限定されるものではなく、環境変数に応じてキャッシュファイルを作成する場所を適宜変えることも可能である。
【０１５７】
以上説明した画像データのキャッシュ・リード・ライト方法（即ち、実施の形態１乃至４のキャッシュファイルの作成方法、実施の形態５，６に係るキャッシュファイルの読み出し方法、実施の形態７，９に係るキャッシュファイルの作成方法、及び実施の形態８，９に係るキャッシュファイル読み出し方法）によれば、断片的な符号化データを、ユーザ端末２０１（又は２０２）において容易に管理することができ、作成したキャッシュファイルをシーケンシャルにリードすることにより、表示すべき画像の断片的な符号化データを実際には全て受信していない場合であっても、JPEG2000符号化データの形式に準拠した１つの符号化データとして読み出すことが可能になる。このため、一般的な仕様のJPEG2000デコーダを当該ユーザ端末に用意しておけば、当該ユーザ端末は、ユーザ所望の解像度の画像を表示することができる。
【０１５８】
また、キャッシュファイルに１枚の画像の符号化データが完全に充填されていない状態であっても、上述した如くシーケンシャルにリードした結果、ユーザ端末の一次記憶１０２に読み込まれる符号化データは、JPEG2000符号化データ形式に完全に準拠した符号化データであり、このキャッシュファイル用の特別なJPEG2000デコーダは必要ないという利点がある。
【０１５９】
更に、サーバ２０４から断片的に送られてくる途中に符号化データを追加する場合であっても、該当するパケットデータのファイルを置きかえることで高速に追加できるという利点がある。
【０１６０】
［他の実施形態］
尚、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、上述した画像処理装置として動作する装置に供給し、それらシステム或いは装置のコンピュータ（またはＣＰＵやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。或いは、処理対象の画像データを外部より入手可能であって、且つディスプレイへの圧縮画像の表示までの処理であれば、パーソナル・コンピュータ等の一般的な情報処理装置においても、前述した実施形態の機能を実現するソフトウェアのプログラムコードを実行することにより、同目的は達成される。これらの場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体、並びに電気通信回線等を介してコンピュータプログラム製品として取得した当該プログラムコードは、本発明を構成することになる。
【０１６１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１６２】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【０１６３】
【発明の効果】
以上説明したように本発明によれば、所定形式で断片化された画像データを、その所定の形式に基づいてデコードし、容易にキャッシュすることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る画像処理装置であるコンピュータ機器の概略構成を示すブロック図である。
【図２】本実施の形態に係る通信ネットワークの概略を示す図である。
【図３】 JPEG2000方式の符号化データの構成を示す図である。
【図４】 JPEG2000の解像度スケイラビリティを説明する図である。
【図５】本実施の形態におけるサーバ／クライアント間での通信プロトコルを説明する図である。
【図６】本発明の実施の形態１乃至６に係るユーザ端末における受信データのキャッシュ処理を示すフローチャートである。
【図７】本実施の形態において画像情報全体を管理するメインファイルのデータ構成を説明する図である。
【図８】図７に示すメインファイルに含まれるタイルデータの管理用データの構成図である。
【図９】図６のステップＳ６０３におけるメインファイルの作成処理を示すフローチャートである。
【図１０】図９のステップＳ９０６におけるタイル基本情報の作成処理を示すフローチャートである。
【図１１】 SOTマーカの構成を説明する図である。
【図１２】図６のステップＳ６０６におけるメインファイルの上書き処理を示すフローチャートである。
【図１３】サーバからのレスポンスデータの構成例を示す図である。
【図１４】本実施の形態１におけるユーザ端末におけるキャッシュファイルの構成例を示す図である。
【図１５】本発明の実施の形態２におけるメインファイルの作成処理を示すフローチャートである。
【図１６】図１５のステップＳ１５０６におけるタイル基本情報の作成処理を示すフローチャートである。
【図１７】実施の形態２に係る、メインファイルの上書き処理を示すフローチャートである。
【図１８】実施の形態２に係るユーザ端末におけるキャッシュファイルのデータ構成を示す図である。
【図１９】本発明の実施の形態３に係るメインファイルの作成処理を示すフローチャートである。
【図２０】図１９のステップＳ１９０６で示すタイル基本情報の作成処理を示すフローチャートである。
【図２１】実施の形態３におけるメインファイルの上書き処理（Ｓ６０６）を示すフローチャートである。
【図２２】本発明の実施の形態４に係るパケットデータをタイル毎にフォルダに保存する例を説明する図である。
【図２３】実施の形態４におけるメインファイルの作成処理を示すフローチャートである。
【図２４】実施の形態４におけるキャッシュファイル構成の概念図である。
【図２５】実施の形態４に係る、画像毎のキャッシュ用フォルダを示す概念図である。
【図２６】本発明の実施の形態５に係る、ユーザ端末においてキャッシュファイルを読み出す処理を示すフローチャートである。
【図２７】図２６のステップＳ２６０７におけるパケットデータの読み出し処理を示すフローチャートである。
【図２８】本発明の実施の形態６に係るパケットデータの読み出し処理を示すフローチャートである。
【図２９】本発明の実施の形態７に係るユーザ端末における受信データのキャッシュ処理を示すフローチャートである。
【図３０】本実施の形態７に係る一括キャッシュファイル内のパケットデータの管理用データを説明する図である。
【図３１】実施の形態７に係る一括キャッシュファイル内へのパケットデータの書込み後の様子を説明する図である。
【図３２】図２９のステップＳ２９０３における一括キャッシュファイルの作成処理を示すフローチャートである。
【図３３】図３２のステップＳ３２０５におけるタイル基本情報の作成処理を示すフローである。
【図３４】図２９のステップＳ２９０６におけるキャッシュファイルの上書きを処理を示すフローである。
【図３５】本発明の実施の形態８に係るユーザ端末において、実施の形態７で作成された一括キャッシュファイルを読み出す処理を示すフローチャートである。
【図３６】実施の形態８に係る図３５のステップＳ３５０７におけるパケットデータ読み出し処理を示すフローチャートである。
【図３７】本発明の実施の形態９におけるパケットデータの読み出し処理を示すフローチャートである。
Claims (26)
- 通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信手段と、
前記受信手段により受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出手段と、
前記算出手段により算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成手段と、
前記ダミーデータ生成手段によって設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換手段と、
を有することを特徴とする画像処理装置。 - 前記ダミーデータ生成手段による前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成手段を更に備え、
前記データ置換手段は、前記ダミー符号化データと前記符号化データとを、前記管理ファイルを用いて記憶媒体の内部で別々の領域参照情報に基づいて管理すると共に、前記領域参照情報を書き換えることにより前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項１に記載の画像処理装置。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであることを特徴とする請求項１又は２に記載の画像処理装置。
- 前記ダミー符号化データは、前記JPEG2000方式に準拠したビットストリーム・シンタックスで規定されているzero length packetのデータであることを特徴とする請求項３に記載の画像処理装置。
- 前記ダミーデータ生成手段は、前記zero length packetのデータを前記パケット毎にそれぞれ設定することを特徴とする請求項４に記載の画像処理装置。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成手段は、前記zero length packetのデータを、１つのキャッシュ中では１つのファイルで構成しており、前記データ置換手段は、前記パケット単位の前記符号化データを管理する前記管理ファイルのファイル名に従って前記１つのファイルを参照することを特徴とする請求項２に記載の画像処理装置。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成手段は、前記zero length packetのデータとしてＮＵＬＬを設定することを特徴とする請求項２又は６に記載の画像処理装置。
- 前記ダミーデータ生成手段は、前記符号化データの数量としての前記パケットの個数に応じて、それらパケットを複数のフォルダに分散して格納することを特徴とする請求項３に記載の画像処理装置。
- 前記ダミーデータ生成手段は、前記符号化データ毎にフォルダを生成することを特徴とする請求項３に記載の画像処理装置。
- 更に、前記データ置換手段によって置き換えがなされたキャッシュファイルをシーケンシャルに読み出すと共に、読み出したデータを前記所定形式に準拠したデコード手順に基づいてデコードするデコード手段を備えることを特徴とする請求項１乃至９のいずれか１項に記載の画像処理装置。
- 前記ダミーデータ生成手段による前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成手段を更に備え、
前記データ置換手段は、前記ダミー符号化データと前記符号化データとを、前記管理ファイルと同一のファイル内で保存すると共に、前記管理ファイル内の領域参照情報を書き換えることにより、前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項１に記載の画像処理装置。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成手段は１つのキャッシュ中では１つのzero length packetデータを生成し、
前記データ置換手段は、パケット単位の前記符号化データの保存場所を指し示すオフセット情報に従って前記zero length packetのデータを参照することを特徴とする請求項１１に記載の画像処理装置。 - 通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置におけるデータキャッシュ方法であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信工程と、
受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出工程と、
前記算出工程で算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成工程と、
前記ダミーデータ生成工程で設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換工程と、を有することを特徴とする画像処理装置におけるデータキャッシュ方法。 - 前記ダミーデータ生成工程での前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成工程を更に備え、
前記データ置換工程では、前記ダミー符号化データと前記符号化データとを、前記管理ファイルを用いて記憶媒体の内部で別々の領域参照情報に基づいて管理すると共に、前記領域参照情報を書き換えることにより前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項１３に記載のデータキャッシュ方法。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであることを特徴とする請求項１３又は１４に記載のデータキャッシュ方法。
- 前記ダミー符号化データは、前記JPEG2000方式に準拠したビットストリーム・シンタックスで規定されているzero length packetのデータであることを特徴とする請求項１５に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程では、前記zero length packetのデータを前記パケット毎にそれぞれ設定することを特徴とする請求項１６に記載のデータキャッシュ方法。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成工程では、前記zero length packetのデータを、１つのキャッシュ中で１つのファイルで構成しており、前記データ置換工程では、前記パケット単位の前記符号化データを管理する前記管理ファイルのファイル名に従って前記１つのファイルを参照することを特徴とする請求項１４に記載のデータキャッシュ方法。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成工程では、前記zero length packetのデータとしてＮＵＬＬを設定することを特徴とする請求項１４又は１８に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程では、前記符号化データの数量としての前記パケットの個数に応じて、それらパケットを複数のフォルダに分散して格納することを特徴とする請求項１５に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程では前記符号化データ毎にフォルダを生成することを特徴とする請求項１５に記載のデータキャッシュ方法。
- 更に、前記データ置換工程で置き換えがなされたキャッシュファイルをシーケンシャルに読み出すと共に、読み出したデータを前記所定形式に準拠したデコード手順に基づいてデコードする工程を備えることを特徴とする請求項１３乃至２１のいずれか１項に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程における前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成工程を更に備え、
前記データ置換工程では、前記ダミー符号化データと前記符号化データとを、前記管理ファイルと同一のファイル内で保存すると共に、前記管理ファイル内の領域参照情報を書き換えることにより、前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項１３に記載のデータキャッシュ方法。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成工程は１つのキャッシュ中では１つのzero length packetデータを生成し、
前記データ置換工程は、パケット単位の前記符号化データの保存場所を指し示すオフセット情報に従って前記zero length packetのデータを参照することを特徴とする請求項２３に記載のデータキャッシュ方法。 - 請求項１３乃至２４の何れか１項に記載のデータキャッシュ方法を実行させるようにコンピュータを動作させることを特徴とするコンピュータプログラム。
- 請求項２５に記載のコンピュータプログラムを格納したことを特徴とする、コンピュータにより読み取り可能な記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002222021A JP3768934B2 (ja) | 2001-08-30 | 2002-07-30 | 画像処理装置及びそのデータキャッシュ方法 |
| US10/231,206 US20030067627A1 (en) | 2001-08-30 | 2002-08-30 | Image processing method and its data cache method |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001261799 | 2001-08-30 | ||
| JP2001-261799 | 2001-08-30 | ||
| JP2002222021A JP3768934B2 (ja) | 2001-08-30 | 2002-07-30 | 画像処理装置及びそのデータキャッシュ方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003179760A JP2003179760A (ja) | 2003-06-27 |
| JP3768934B2 true JP3768934B2 (ja) | 2006-04-19 |
Family
ID=26621313
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002222021A Expired - Fee Related JP3768934B2 (ja) | 2001-08-30 | 2002-07-30 | 画像処理装置及びそのデータキャッシュ方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3768934B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7711834B2 (en) | 2002-12-13 | 2010-05-04 | Ricoh Co., Ltd. | Network access to partial document images |
| JP2006191159A (ja) | 2004-12-28 | 2006-07-20 | Canon Inc | 画像処理方法及び画像処理装置 |
| JP4716949B2 (ja) | 2005-09-02 | 2011-07-06 | 株式会社リコー | 画像処理装置および画像処理方法 |
| JP2007142614A (ja) * | 2005-11-16 | 2007-06-07 | Ricoh Co Ltd | 画像処理装置、画像処理方法、プログラム及び情報記録媒体 |
| JP2009122847A (ja) | 2007-11-13 | 2009-06-04 | Ricoh Co Ltd | ファイルアクセス装置 |
-
2002
- 2002-07-30 JP JP2002222021A patent/JP3768934B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003179760A (ja) | 2003-06-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20030067627A1 (en) | Image processing method and its data cache method | |
| US6711572B2 (en) | File system for distributing content in a data network and related methods | |
| US5838927A (en) | Method and apparatus for compressing a continuous, indistinct data stream | |
| US8868690B2 (en) | System and method for support wireless device access to external storage | |
| JP4975882B2 (ja) | コンピュータ・システムにおけるオブジェクトの別のストレージ・ロケーションへの部分的移動 | |
| US7636765B2 (en) | Data transfer scheme using caching technique for reducing network load | |
| KR100512388B1 (ko) | 정보전송방법및장치 | |
| CN110401724B (zh) | 文件管理方法、文件传输协议服务器及存储介质 | |
| US8555324B2 (en) | Video download mechanism for transferring large data | |
| JP3560758B2 (ja) | データ管理方法およびそれを用いたデータ管理装置 | |
| US20040003117A1 (en) | Method and apparatus for dynamic optimization and network delivery of multimedia content | |
| KR100855997B1 (ko) | 전자 문서의 구성 가능한 변환 방법 | |
| US20100023594A1 (en) | Content processing apparatus, content processing method, and recording medium | |
| US20170010824A1 (en) | Previewing File Information Over a Network | |
| JP7105675B2 (ja) | 送信装置、サーバ装置、送信方法およびプログラム | |
| JP2000222088A (ja) | 情報提供サーバ，仲介サーバ，および閲覧端末 | |
| US7069297B2 (en) | Data transfer scheme using re-direct response message for reducing network load | |
| US20150089181A1 (en) | Use of wireless devices external storage | |
| JP2007025843A (ja) | データ記憶装置及びバージョン管理プログラム | |
| JP2006191159A (ja) | 画像処理方法及び画像処理装置 | |
| US20020129373A1 (en) | Contents playback method and apparatus | |
| JP3768934B2 (ja) | 画像処理装置及びそのデータキャッシュ方法 | |
| US20190026047A1 (en) | Random file i/o and chunked data upload | |
| Seshan et al. | Benefits of transparent content negotiation in HTTP | |
| JP3768866B2 (ja) | 符号化データの作成方法及びその装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040611 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051122 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060111 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060202 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3768934 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110210 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120210 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140210 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |