(57)【要約】【課題】符号化データを受信してキャッシュする場合に、キャッシュしたデータに対してアクセスする際に要する時間や回数を軽減させること。【解決手段】複数のパケットから成るタイル単位で分割された画像の符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数のパケットのデータを受信する場合に、受信する各パケットを管理するための管理情報を作成し、受信した各々のパケットを、夫々のパケットが属するタイルの番号に従って並び替え（Ｓ１３０４）、更に、同じタイルに属する夫々のパケットをこのタイル中の順番に従って並び替え（Ｓ１３０５）、並び替えたパケットのデータを管理情報に順次付加すると共に、付加したパケットのデータと管理情報とを含むキャッシュデータ中の、各パケットのデータの配置に関する情報を管理情報に登録する（Ｓ１３０６）。【選択図】  図１３
2005012686.tif 000002
【特許請求の範囲】
【請求項１】
複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数の論理単位のデータを受信する画像処理装置が行う画像処理方法であって、
受信する各論理単位を管理するための管理情報を作成する管理情報作成工程と、
受信した各々の論理単位を、夫々の論理単位が属するタイルの番号に従って並び替え、更に、同じタイルに属する夫々の論理単位を当該タイル中の順番に従って並び替える並び替え工程と、
前記並び替え工程で並び替えた論理単位のデータを前記管理情報に順次付加すると共に、付加した論理単位のデータと前記管理情報とを含むキャッシュデータ中の、各論理単位のデータの配置に関する情報を前記管理情報に登録する登録工程と
を備えることを特徴とする画像処理方法。
【請求項２】
受信した論理単位が属するタイルの番号、及び当該論理単位の当該タイル中の順番は、論理単位の受信に先立って受信したヘッダ情報、及び受信した論理単位のデータを解析することにより得られることを特徴とする請求項１に記載の画像処理方法。
【請求項３】
前記管理情報作成工程では、各タイルについて、ＪＰＥＧ２０００のプログレッションオーダーに従った論理単位の並びを管理する為の管理情報を作成することを特徴とする請求項１に記載の画像処理方法。
【請求項４】
前記登録工程では更に、前記並べ替え工程で並べ替えた夫々の論理単位が、夫々の論理単位が属するタイル内で連続した順番であるかを示す情報を前記管理情報に登録することを特徴とする請求項１に記載の画像処理方法。
【請求項５】
複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数の論理単位のデータを受信する画像処理装置であって、
受信する各論理単位を管理するための管理情報を作成する管理情報作成手段と、
受信した各々の論理単位を、夫々の論理単位が属するタイルの番号に従って並び替え、更に、同じタイルに属する夫々の論理単位を当該タイル中の順番に従って並び替える並び替え手段と、
前記並び替え手段が並び替えた論理単位のデータを前記管理情報に順次付加すると共に、付加した論理単位のデータと前記管理情報とを含むキャッシュデータ中の、各論理単位のデータの配置に関する情報を前記管理情報に登録する登録手段と
を備えることを特徴とする画像処理装置。
【請求項６】
コンピュータに請求項１乃至４の何れか１項に記載の画像処理方法を実行させるためのプログラム。
【請求項７】
請求項６に記載のプログラムを格納するコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数のパケットから成るタイル単位で分割された画像の符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数のパケットのデータを受信し、これを管理するための技術に関するものである。
【０００２】
【従来技術】
インターネット上では、クライアント端末装置上で動作するＷｅｂブラウザを用いてＷＷＷサーバにアクセスし、Ｗｅｂブラウザを介してクライアント端末装置側で文書データや画像データ等を閲覧することが盛んに行われている。このＷＷＷサーバは、ホームページといわれる公開したい情報をＨＴＭＬで記述した情報を保持しており、それをクライアント端末装置側のＷｅｂブラウザが解釈して、クライアント端末装置が有する表示装置の表示画面上に表示する。クライアント端末装置側のＷｅｂブラウザは、表示装置に表示されているホームページ中のリンク部分がユーザによって指示されると、このリンク部分が示すリンク先を辿って行き、必要な情報を得ることができる。
【０００３】
さらに、サーバが管理しているファイルをダウンロードする方法として、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  （以下ＦＴＰと略す）という方法がある。このＦＴＰとは、ネットワークを通して、サーバ上にあるファイルを一度にクライアント端末装置に転送する仕組みである。
【０００４】
あるいは、画像データファイルへ断片的にアクセスして表示するためのプロトコルとして、Ｆｌａｓｈｐｉｘ／ＩＩＰがある。このＩＩＰ（Ｉｎｔｅｒｎｅｔ  Ｉｍａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）は、Ｆｌａｓｈｐｉｘという画像データファイルフォーマットに最適なプロトコルになっており、画像データの部分アクセスの単位はＦｌａｓｈｐｉｘのタイル単位に行うものとなっている。このＩＩＰプロトコルを使用する技術としては従来からいくつかが開示されている（例えば特許文献１を参照）。
【０００５】
これらのいずれのプロトコルであっても、サーバから送信されるデータは、それぞれ独立した符号データである。そのため、サーバ側では、送信データの順番を考慮して返送する必要がなかった。
【０００６】
また、ＪＰＥＧ２０００に従って符号化されたファイルへ断片的にアクセスして表示するためのプロトコルとして、ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ  −  Ｐａｒｔ  ９：  Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，  ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓ（以下、ＪＰＩＰと記す）が検討されている。このようなプロトコルを使ってＪＰＥＧ２０００の画像データをクライアント端末装置に断片的に送信した場合、送信された画像データをクライアント端末装置がデコードするためには、受信した断片的な符号化データを１つのファイルにキャッシュする必要がある。これは、ＪＰＥＧ２０００の各スケーラビリティの符号化データは、そのスケーラビリティより１つ下のスケーラビリティのデータからの差分データであるためである。
【０００７】
このように断片的に受信したＪＰＥＧ２０００データを１つのファイルにキャッシュする際に、受信した順番にデータをキャッシュファイルにアペンドする方法がある。この場合、簡単にひとつのファイルにキャッシュデータを書き込むことができる。その際、キャッシュされたデータを管理するために、各データの識別データとオフセット値及びデータ長を書き込んでいた。
【０００８】
このＪＰＩＰを利用してデータを要求するクライアントは、レスポンスデータの返送方法に関して、次の２種類の要求が可能になっている。
【０００９】
１）  ｆｕｌｌｗｉｎｄｏｗ：  レスポンスデータの送信順序はサーバに一任する変わりに、要求データを全て確実に返送することを要求
２）  ｐｒｏｇｒｅｓｓｉｖｅ：  要求データの一部を削減しても良いから、画質方向のスケーラビリティ（ｌａｙｅｒ  ｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒ）で返送することを要求
従って、クライアントは、要求したデータの全てを確実に受信したい場合には、上記のｐｒｏｇｒｅｓｓｉｖｅでの要求をおこうため、サーバは、クライアント側の処理を考慮せずに、サーバの実装方針に従って、返送していた。
【００１０】
【特許文献１】
特開２００２−４９５１４
【００１１】
【発明が解決しようとする課題】
しかし、サーバから送られてくるパケットデータは、必ずしもサーバにある画像のオリジナルのｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒの順番ではない。また、クライアント端末装置が複数のスレッドを立ち上げて、１つのＪＰＥＧ２０００ファイルから一度に複数のスレッドでパケットデータを取得した場合には、送られてくるパケットデータはｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒの順番である可能性は、ますます小さくなる。
【００１２】
そのため、パケットデータを送られてきた順番どおりにキャッシュファイルに書き込むと、キャッシュされたデータを管理する情報へのアクセスがランダムになり、キャッシュデータを書き込む際にキャッシュファイル内のシーク回数が多くなり、時間がかかってしまうという問題が発生する。
【００１３】
さらに、このようにＪＰＥＧ２０００の断片的なデータを受信したクライアント端末装置が受信したデータをデコードし、表示する時には、キャッシュデータからデコーダが処理できるデータの順番にキャッシュデータを並べ直して、読み出す必要がある。例えば、ＪＰＥＧ２０００の汎用的なデコーダを利用する場合には、ＪＰＥＧ２０００ビットストリームシンタックスに沿ってキャッシュデータを読み出して、一本のビットストリームを作成する。したがって、従来の方法のように、受信した順番にデータをアペンドしていくと、キャッシュデータを読み出す際にも、キャッシュファイル内のシーク回数が多くなり、時間がかかってしまう問題が発生する。
【００１４】
本発明は以上の問題に鑑みて成されたものであり、符号化データを受信してキャッシュする場合に、キャッシュしたデータに対してアクセスする際に要する時間や回数を軽減させる様な形態でキャッシュを行うことを目的とする。
【００１５】
【課題を解決するための手段】
本発明の目的を達成するために、例えば本発明の画像処理方法は以下の構成を備える。
【００１６】
すなわち、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数の論理単位のデータを受信する画像処理装置が行う画像処理方法であって、
受信する各論理単位を管理するための管理情報を作成する管理情報作成工程と、
受信した各々の論理単位を、夫々の論理単位が属するタイルの番号に従って並び替え、更に、同じタイルに属する夫々の論理単位を当該タイル中の順番に従って並び替える並び替え工程と、
前記並び替え工程で並び替えた論理単位のデータを前記管理情報に順次付加すると共に、付加した論理単位のデータと前記管理情報とを含むキャッシュデータ中の、各論理単位のデータの配置に関する情報を前記管理情報に登録する登録工程と
を備えることを特徴とする。
【００１７】
本発明の目的を達成するために、例えば本発明の画像処理装置は以下の構成を備える。
【００１８】
すなわち、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である符号化データを保持する装置から、各タイルについて所望の画像を得るために必要な数の論理単位のデータを受信する画像処理装置であって、
受信する各論理単位を管理するための管理情報を作成する管理情報作成手段と、
受信した各々の論理単位を、夫々の論理単位が属するタイルの番号に従って並び替え、更に、同じタイルに属する夫々の論理単位を当該タイル中の順番に従って並び替える並び替え手段と、
前記並び替え手段が並び替えた論理単位のデータを前記管理情報に順次付加すると共に、付加した論理単位のデータと前記管理情報とを含むキャッシュデータ中の、各論理単位のデータの配置に関する情報を前記管理情報に登録する登録手段と
を備えることを特徴とする。
【００１９】
【発明の実施の形態】
以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
【００２０】
［第１の実施形態］
図１はＰＣ（パーソナルコンピュータ）やワークステーションなどにより構成される、本実施形態に係る画像処理装置の基本構成を示すブロック図である。
【００２１】
ＣＰＵ１０１は一次記憶メモリ１０２にロードされたプログラムやデータを用いて本装置全体の制御を行うと共に後述の各部の動作の制御を行う。
【００２２】
一次記憶メモリ１０２はＲＡＭに代表される主記憶装置であって、二次記憶メモリ１０３からロードされたプログラムやデータを一時的に記憶するエリアを備えると共に、ＣＰＵ１０１が各種の処理を行うために使用するエリアを備える。
【００２３】
二次記憶メモリ１０３は、ハードディスクドライブに代表される大記憶容量を有する情報記憶装置であって、ここにＯＳ（オペレーティングシステム）や後述の各処理をＣＰＵ１０１が実行するためのプログラムやデータを保存させておくことができ、ＣＰＵ１０１による制御によって、要求されたプログラムやデータを一次記憶メモリ１０２に出力（ロード）する。
【００２４】
入力デバイス１０４は、例えばマウスやキーボードなどに代表される指示入力装置であって、この入力デバイス１０４により、本装置のユーザは各種の指示をＣＰＵ１０１に入力することができる。
【００２５】
出力デバイス１０５は、例えばディスプレイやプリンタに代表される装置であって、本装置で処理した画像を表示やプリントアウト等、様々な形態で出力することのできる装置である。
【００２６】
ネットワークインターフェース１０６は、他の装置が送信した画像や文字などの情報を、インターネットやＬＡＮなどのネットワークを介して本装置が受信するためのインターフェースである。
【００２７】
１０７は上記各部を繋ぐバスである。本実施形態に係る画像処理装置の基本構成は以下の説明上図１に示した構成とするが、これ以外の構成を適用することも可能であり、図１に示した構成に限定されるものではない。
【００２８】
図２は、上記画像処理装置を含むシステムの概要を示す図である。２０１，２０２は夫々上記画像処理装置を適用するクライアント端末装置であって、後述するサーバ装置２０４とネットワーク２０３を介して各種のデータ通信を行うことができる。
【００２９】
２０３はネットワークで、インターネットやＬＡＮなどの有線のネットワーク、無線のネットワークを含むものである。
【００３０】
２０４はサーバ装置で、上述の通りネットワーク２０３を介してクライアント端末装置２０１，２０２とデータ通信を行うことができ、例えばクライアント端末装置２０１やクライアント端末装置２０２から所望の画像の要求があった場合には、画像の符号化データを大量に保存する記憶装置２０５から要求された分だけのデータをネットワーク２０３を介して返信するものである。この記憶装置２０５は例えばハードディスクドライブ装置や、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどの記憶媒体からプログラムやデータを読み取る装置がこれに該当する。
【００３１】
本実施形態ではこの記憶装置２０５には、ＪＰＥＧ２０００に従った符号化方式で符号化された画像のデータが複数保存されているものとする。従ってクライアント端末装置２０１，２０２はサーバ装置２０４に、記憶装置２０５が保存している画像のデータの中から所望の画像について要求する。
【００３２】
以下の説明では、サーバ装置２０４から受信した画像のデータをクライアント端末装置がキャッシュする方法について説明する。クライアント端末装置が記憶装置２０５に保存されている画像をダウンロードするためには、Ｗｅｂブラウザを用いてサーバ装置２０４にアクセスする必要がある。サーバ装置２０４はこのアクセスを受け、記憶装置２０５に保存されている画像の一部もしくは全部の画像を例えばサムネイル形式でクライアント端末装置に提示する。これによりＷｅｂブラウザにはこれらの画像が表示されることになる。
【００３３】
このＷｅｂブラウザに表示された画像群の中から、クライアント端末装置のユーザが入力デバイス１０４を用いて所望の画像を指示すると、クライアント端末装置は条件（画面サイズや表示形態など）に応じた画像サイズや解像度に従って、所望の画像のデータ中の断片的なデータの送信要求をサーバ装置２０４に対して送信する。サーバ装置２０４はこの要求に応じた断片的なデータをクライアント端末装置に送信するので、クライアント端末装置はこれを受信し、バッファにキャッシュする。
【００３４】
そして受信した画像を表示する際には、それらのキャッシュデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、その後、そのビットストリームをデコードして表示する。
【００３５】
次に、一般的なＪＰＥＧ２０００に従ったビットストリームについて説明する。図３はＬａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ  ｐｒｏｇｒｅｓｓｉｏｎ（以下、ＬＲＣＰと記す）に従ったＪＰＥＧ２０００のビットストリームの構成を示す図である。ＪＰＥＧ２０００のビットストリームにはメインヘッダ（Ｍａｉｎ  Ｈｅａｄｅｒ）、タイルヘッダ（Ｔｉｌｅ  Ｈｅａｄｅｒ）、データ（Ｄａｔａ）が含まれており、このデータの部分に画像符号化データが記録されることになる。またタイルヘッダは、圧縮符号化元の画像を所定のサイズの矩形（タイル）毎に分割し、夫々のタイルの圧縮符号化データを生成した場合に、夫々のタイルの圧縮符号化データに対して作成されるものである。メインヘッダ、タイルヘッダについては公知の技術によるものであるのでここでの説明は省略する。
【００３６】
ＬＲＣＰに準じた場合、画像の符号化データ（同図において”Ｄａｔａ”で示された部分）は、Ｌａｙｅｒ／Ｒｅｓｏｌｕｔｉｏｎ／Ｃｏｍｐｏｎｅｎｔ／Ｐｏｓｉｔｉｏｎの順にデータが配置された構成を備え、この構成はｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒと呼ばれる。また、ここで記されているｐｏｓｉｔｉｏｎとは、ＪＰＥＧ２０００符号化データにおけるｐｒｅｃｉｎｃｔのことである。
【００３７】
ＪＰＥＧ２０００の符号化データは大まかにはＬａｙｅｒ毎のデータに分けることができる。各Ｌａｙｅｒのデータはすなわち公知のビットプレーン符号化による各ビットプレーンの符号化データで、ＭＳＢ側のビットプレーン（Ｌａｙｅｒ１）から順にＬＳＢのビットプレーン（ＬａｙｅｒＬ）までが配置される。Ｌａｙｅｒ番号は復元する画像の原画に対するＳ／Ｎ比に対応し、Ｌａｙｅｒ番号が小さいほどＳ／Ｎ比が悪く（低く）なる。すなわち、同図のＪＰＥＧ２０００のデータは、Ｓ／Ｎの悪い順に各Ｌａｙｅｒのデータが配置されていることになる。
【００３８】
更に各Ｌａｙｅｒのデータは各Ｒｅｓｏｌｕｔｉｏｎのデータにより構成されている。各Ｒｅｓｏｌｕｔｉｏｎのデータは解像度（画像のサイズ）に応じたＲｅｓｏｌｕｔｉｏｎ番号に従った順序で配置されている。解像度とＲｅｓｏｌｕｔｉｏｎ番号との関係を図４に示す。最も小さい解像度の画像のＲｅｓｏｌｕｔｉｏｎ番号を０とし、Ｒｅｓｏｌｕｔｉｏｎ番号が一つ増加するごとに画像の幅と高さが倍になっていく。各Ｌａｙｅｒ内は、Ｒｅｓｏｌｕｔｉｏｎ番号の小さい順にデータが格納されている。
【００３９】
図３に戻って、各Ｒｅｓｏｌｕｔｉｏｎのデータは各Ｃｏｍｐｏｎｅｎｔのデータにより構成されている。各Ｃｏｍｐｏｎｅｎｔのデータは画像の各色データに対応しており、例えば画像がＲＧＢの各データにより構成されている場合には、Ｃｏｍｐｏｎｅｎｔ０のデータはＲ成分のデータ、Ｃｏｍｐｏｎｅｎｔ１のデータはＧ成分のデータ、Ｃｏｍｐｏｎｅｎｔ２のデータはＢ成分のデータである、すなわち、Ｃｏｍｐｏｎｅｎｔ数は画像の色空間の次元数に一致する。
【００４０】
また各Ｃｏｍｐｏｎｅｎｔデータには圧縮符号化元の画像における空間的な各位置のデータ（Ｐｏｓｉｔｉｏｎデータ）が順番に記録されており、各Ｐｏｓｉｔｉｏｎデータには、空間的な順番通りに番号（ポジション番号）が付けられている（例えば画像の左上隅を０として画像の右方向に１つずつ番号が増加し、右端に達したら１つ下、且つ左端からまた画像右方向に番号が増加する）。
【００４１】
一つのＪＰＥＧ２０００ファイル内でのＲｅｓｏｌｕｔｉｏｎ番号とレイヤ番号、コンポーネント番号の最大値は、エンコーダによって予め設定されており、圧縮符号化元の画像はそのパラメータに従ってエンコードされており、その情報はメインヘッダに記録されている。また各パケット（ｐａｃｋｅｔ）は、そのパケットに格納されているコードブロック（ｃｏｄｅ−ｂｌｏｃｋ）の情報を管理しているパケットヘッダ（ｐａｃｋｅｔ  ｈｅａｄｅｒ）部と、各コードブロックの符号化データから構成されている。同図では１つのＰｏｓｉｔｉｏｎデータがパケットに相当する。この「パケット」なるものは、論理単位の一種である。
【００４２】
このような構造を有するＪＰＥＧ２０００ファイルがサーバ装置に保持されていれば、クライアント端末装置は必要な解像度等、要求する部分の画像のみをサーバ装置から受信することができる。本実施形態の場合には、ＪＰＩＰによってデータの送受信を行うため、受信するデータの単位としては、ＪＰＥＧ２０００のタイル単位、或いはＪＰＥＧ２０００のパケット（ｐａｃｋｅｔ）単位が考えられる。本実施形態では、クライアント端末装置がサーバ装置から受信するデータ単位としてパケット単位を想定する。
【００４３】
このパケット単位でのリクエスト及びレスポンスの概念図を図５に示す。同図ではサーバ装置５０２、クライアント端末装置５０１間のリクエスト、レスポンスについて示している。
【００４４】
同図は、画像がタイル分割されており、各タイルの符号化データ（同図ではＴｉｌｅ０〜ＴｉｌｅＮまでの各データ）がＪＰＥＧ２０００ビットストリーム５０４としてサーバ装置１０２に接続されている記憶装置５０３に格納されている状態で、クライアント端末装置５０１から所望のタイル、所望の解像度、所望のレイヤ、所望のコンポーネント、そして所望の空間的な位置の符号化データを要求する場合に、サーバ装置５０２とクライアント端末装置５０１との間で行われる通信を示すものである。
【００４５】
ここで例えばクライアント端末装置５０１がタイル番号は「１」、解像度番号は「０」、レイヤ番号は「１」、コンポーネント番号は「０」、そしてポジション番号は「０」である符号化データをサーバ装置５０２に要求した場合、サーバ装置５０２は記憶装置５０３に保存しているＪＰＥＧ２０００ビットストリーム５０４を解析して、要求に相当する部分（要求されたタイル番号、解像度番号、レイヤ番号、コンポーネント番号、ポジション番号に相当する部分）、すなわち、タイル番号１のパケット０をレスポンスデータとして抜き出し、クライアント端末装置５０１に返信する。
【００４６】
このように本実施形態ではサーバ装置とクライアント端末装置との間の画像データの送受信にはＪＰＩＰを用い、パケット単位で画像の符号化データをサーバ装置からクライアント端末装置に送信する。
【００４７】
またその際、サーバ装置はＪＰＩＰにおけるｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ  ＩＤの順番にパケットを返送するものとする。このｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎについて、図６（ａ）、（ｂ）を用いて簡単に説明する。図６（ａ）、（ｂ）はｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎを説明するための図である。
【００４８】
ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎとは図６（ａ）に示すように、Ｔｉｌｅ  ｔｎの中のｐｒｅｃｉｎｃｔ  ｐｎのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ｒｎ、  ｃｏｍｐｏｎｅｎｔ番号ｃｎを構成する全てのｌａｙｅｒのパケットを、ｌａｙｅｒ番号が昇順になるように並べてつなげたデータの塊である。サーバ装置からクライアント端末装置への（ＪＰＩＰの）レスポンスデータは、このｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎを基にして作成され、レスポンスデータに記述されたｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ  ＩＤ（ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）と表す）で、夫々のデータを識別できる。ＰｒＩＤ（ｔｎ，  ｒｎ，  ｃｎ，  ｐｎ）は、次式により求めることができる。
【００４９】
ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）＝ｔｎ＋（ｃｎ＋ｓ×（ｃｏｍｐｏｎｅｎｔ数））×ｔｉｌｅ数
ただし、
ｓ＝ｐｎ＋ｔｎ×（ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ｒｎにおける１ｔｉｌｅあたりのｐｒｅｃｉｎｃｔ数）＋（ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０から（ｒｎ−１）までのタイルｔｒのｐｒｅｃｉｎｃｔ数の総和）
従って例えば、２つのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌを持ち、３つのｃｏｍｐｏｎｅｎｔ、４つのタイル、そして、１タイルにつき１ｐｏｓｉｔｉｏｎであるような画像の場合、ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）は、
ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）＝ｔｒ＋（ｃ＋３ｓ）×４
で求められ、各ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ、各ｃｏｍｐｏｎｅｎｔにおける各タイルのデータには図６（ｂ）に示すような番号が付けられる。このようにして、ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ中の各ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ、各ｃｏｍｐｏｎｅｎｔにおける各タイルのデータには固有の番号であるＰｒＩＤが付けられるので、夫々のタイルのデータを識別することができる。
【００５０】
また、記憶装置２０５に保持されている画像の符号化データは、以下のエンコード条件に従って作成されているものとする。
【００５１】
最大解像度時の画像サイズ：２０４８×２０４８［ｐｉｘｅｌ］
Ｔｉｌｅ分割：８×８＝６４  ｔｉｌｅに分割
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ数：  ４  （ｉ．ｅ．  ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０〜３）
Ｌａｙｅｒ数：３  （ｉ．ｅ．  ｌａｙｅｒ  ０〜２）
Ｐｏｓｉｔｉｏｎ数：１  ｐｏｓｉｔｉｏｎ  ／  １  ｔｉｌｅ
Ｃｏｍｐｏｎｅｎｔ数：３  （ｉ．ｅ．  ｃｏｍｐｏｎｅｎｔ  ０〜２）
Ｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒ：  Ｒｅｓｏｌｕｔｉｏｎ−Ｌａｙｅｒ−Ｃｏｍｐｏｎｅｎｔ−Ｐｏｓｉｔｉｏｎ
図７は、このようなエンコード条件で符号化された画像の符号化データ、即ちＪＰＥＧ２０００のビットストリームの構成を示す図である。また同図において各タイルに付けられた番号は、図８に示すように、符号化元の画像の左上から順番に付けられたものである。
【００５２】
次に、図２に示したクライアント端末装置２０１（２０２でも良い）が行う、サーバ装置２０４から所望の画像の符号化データを受信してキャッシュするまでの処理について以下説明する。
【００５３】
図９は、後述するキャッシュファイルを作成する為の処理のフローチャートである。なお同図のフローチャートに従ったプログラムは二次記憶メモリ１０３に保存されており、ＣＰＵ１０１による制御の下で一次記憶メモリ１０２にロードされ、ＣＰＵ１０１がこれを実行することで、クライアント端末装置２０１（２０２でも良い）は以下説明する処理を行うことになる。
【００５４】
まずクライアント端末装置２０１はサーバ装置２０４に、これから表示しようとする画像の符号化データを含むビットストリーム中のメインヘッダの送信を要求する（ステップＳ９０１）。
【００５５】
受信したメインヘッダは一次記憶メモリ１０２に記憶され、ＣＰＵ１０１はメインヘッダの受信を検知すると（ステップＳ９０２）、このメインヘッダを解析し、これから表示しようとする画像の基本情報、即ち、この画像の高さＩｈと幅Ｉｗ、タイル数ＴＮ、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ数ＲＮ、ｌａｙｅｒ数ＬＮ、ｃｏｍｐｏｎｅｎｔ数ＣＮ、各ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ｒにおいて１タイルあたりのｐｏｓｉｔｉｏｎ数ＰｏＮ（ｒ）、１タイルあたりに含まれるｐａｃｋｅｔ数ＰａＮを求める（ステップＳ９０３）。これらの値は、メインヘッダの中のＳＩＺマーカ及びＣＯＤマーカを解析することで、容易に得られる。本実施形態では画像の基本情報を、
Ｉｈ＝Ｉｗ＝２０４８
ＴＮ＝６４、
ＲＮ＝４
ＬＮ＝３
ＣＮ＝３
ＰｏＮ（０）＝ＰｏＮ（１）＝ＰｏＮ（２）＝ＰｏＮ（３）＝１
ＰａＮ＝３６
であると仮定するが、以下の説明の趣旨はこれらの値に限定されるものではない。
【００５６】
次に、ステップＳ９０３で得られた画像の基本情報、これから受信する各パケットデータを管理するためのデータ、及びステップＳ９０２で受信したメインヘッダを書き込んだキャッシュファイルのデータを一次記憶メモリ１０２上に作成する（ステップＳ９０４）。
【００５７】
図１０は本実施形態に係るキャッシュファイルの概略構成を示す図である。１００１はキャッシュファイル本体であり、上述の通り、キャッシュファイルには画像の基本情報、メインヘッダ、そしてこれから受信する各パケットに関する情報を登録し、管理するための情報（管理情報）が含まれる。タイル１を例に取り、このタイル１に含まれるパケットを管理するための情報１００２の詳細を同図の右側に示す。
【００５８】
タイル１に含まれるパケットを管理するための情報として、夫々のパケットについて以下の４つの情報を管理する。
【００５９】
・  キャッシュファイルの先頭から、このキャッシュファイルに以降付加（キャッシュ）されていく各パケットのデータまでのオフセット値（Ｏｆｆｓｅｔ）
・  パケットのデータ長（Ｌｅｎｇｔｈ）
・  タイル内での各パケットの順番を示す番号ｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（ＳｅｑＮｕｍｂｅｒ）
・  各パケットのデータの連続性を示すフラグ（ＳｅｑＦｌａｇ）
即ち情報１００２内には、タイル１に含まれる各パケットについて上記４つの情報のセットが登録されることになる。上記４つの各情報の詳細については後述する。
【００６０】
また上述のＯｆｆｓｅｔ、Ｌｅｎｇｔｈ、ＳｅｑＦｌａｇについては、ステップＳ９０４における作成時には、Ｏｆｆｓｅｔ＝０、Ｌｅｎｇｔｈ＝０、ＳｅｑＦｌａｇ＝ＮＯＮ＿ＩＮ＿ＳＥＱＵＥＮＣＥと初期化されており、ＳｅｑＮｕｍｂｅｒについてはＰａＮ＝３６であるため、先頭から通し番号０〜３５が付けられる。この初期化された状態の管理情報を図１１（ａ）に示す。
【００６１】
以上の処理により、管理情報を初期化することができ、この初期化された管理情報に以降受信する各パケットに関する上記４つの情報を管理情報に登録することができる。
【００６２】
次にクライアント端末装置２０１がサーバ装置２０４に画像の符号化データを要求し、要求に応じてサーバ装置２０４がパケット毎に送信する画像の符号化データを受信し、受信した画像の符号化データをデコードして表示装置としての出力デバイス１０５に表示するまでの処理の詳細について、同処理のフローチャートを示す図１２を参照して以下説明する。なお同図のフローチャートに従ったプログラムは二次記憶メモリ１０３に保存されており、ＣＰＵ１０１による制御の下で一次記憶メモリ１０２にロードされ、ＣＰＵ１０１がこれを実行することで、クライアント端末装置２０１は以下説明する処理を行うことになる。
【００６３】
まず、入力デバイス１０４を用いてユーザから指示された画像の表示要求を取得する（ステップＳ１２０１）。ＣＰＵ１０１はこの要求に基づいて画像全体をどのような解像度で表示するのかといったことを示すデータ（要求データ）を作成し、サーバ装置２０４に送信する（ステップＳ１２０２）。本実施形態では画像全体をｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  １、ｌａｙｅｒ  ０で表示するので、要求データはサーバ装置２０４に対してｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０〜１、ｌａｙｅｒ  ０、ｃｏｍｐｏｎｅｎｔ  ０〜２のパケットデータを送信するよう、要求するためのものである。
【００６４】
従ってサーバ装置２０４はこの要求を受けて、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０〜１、ｌａｙｅｒ  ０、ｃｏｍｐｏｎｅｎｔ  ０〜２のパケットデータを全タイルに関してクライアント端末装置２０１に送信することになるので、クライアント端末装置２０１はサーバ装置２０４からのパケット単位でのデータ（レスポンスデータ）を受信すると（ステップＳ１２０３）、後述する方法でキャッシュする（ステップＳ１２０４）。受信した各パケットのデータは一次記憶メモリ１０２の受信バッファに記憶されるものとする。なおステップＳ１２０４に関する処理についての詳細は後述する。
【００６５】
そして要求した全てのパケットのデータを受信すると（ステップＳ１２０５）、キャッシュファイルからＪＰ２ビットストリームを作成し（ステップＳ１２０６）、ＪＰ２ビットストリームをデコードし、出力デバイス１０５に表示する（ステップＳ１２０７）。
【００６６】
ここで上記ステップＳ１２０４における処理、即ちサーバ装置２０４からパケット単位で受信した画像の符号化データをキャッシュする処理の詳細について、図１３を参照して説明する。図１３は、サーバ装置２０４からパケット単位で受信した画像の符号化データをキャッシュする処理の詳細のフローチャートである。
【００６７】
まず、受信すべき総パケット数Ｒｅｓｐ＿ｎｕｍｂｅｒを取得する（ステップＳ１３０１）。取得の方法としては例えば上記要求データが示す内容から求めても良いし（ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０〜１、ｌａｙｅｒ  ０、ｃｏｍｐｏｎｅｎｔ  ０〜２のパケットの数を求める）、実際に受信したパケットの数をカウントしても良い。
【００６８】
なお本実施形態では１タイルでｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０〜１、ｌａｙｅｒ  ０、ｃｏｍｐｏｎｅｎｔ  ０〜２を構成するパケットの数、すなわち６個のパケットがサーバ装置２０４から送信されるので、受信すべき総パケット数は６（１タイルあたりのパケット数）×６４（総タイル数）＝３８４となる。
【００６９】
次に、サーバ装置２０４から送信される夫々のパケットに関する情報を一時的に格納するための配列Ｉｎｆｏを作成する（ステップＳ１３０２）。配列Ｉｎｆｏに格納するための「パケットに関する情報」は以下の４つの項目から成る。
【００７０】
・  パケットが属するタイルの番号（Ｔｉｎｄｅｘ）
・  属するタイル内での順番を表す番号Ｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（ｓｅｑＮｕｍｂｅｒ）
・  上記受信バッファの先頭から、パケットのデータまでのオフセット値（Ｂｏｆｆｓｅｔ）
・  パケットのデータ長（Ｌｅｎｇｔｈ）
図１４は配列Ｉｎｆｏの構成を示す図である。同図に示すとおり、配列Ｉｎｆｏは、上記４つの情報を１セットとし、このセットを各パケットについて格納するための配列である。上述の通り、送信すべき総パケット数は３８４であるので、配列Ｉｎｆｏは３８４個設けられている。
【００７１】
同図においてＩｎｆｏ［０］は最も小さいタイル番号（本実施形態では０）のタイルにおいて順番が最初のパケットに関する上記４つの情報を格納するための領域で、１４０１，１４０２，１４０３，１４０４は夫々同図に示すとおり、最も小さいタイル番号のタイルにおいて順番が最初のパケットに対するＴｉｎｄｅｘ、ｓｅｑＮｕｍｂｅｒ、Ｂｏｆｆｓｅｔ、Ｌｅｎｇｔｈを格納するための領域である。
【００７２】
各パケットについてのこれら４つの情報は、上記受信バッファに記憶している各パケットのデータを解析したり、上記ＰｒＩＤを求める式を用いたりして求めることができる。
【００７３】
よって、クライアント端末装置２０１はパケットの受信順に従って、パケットに関する上記４つの情報を配列Ｉｎｆｏに格納する（ステップＳ１３０３）。
【００７４】
本実施形態ではサーバ装置２０４は、ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ順にレスポンスデータを送信するので、配列ＩｎｆｏにおけるＴｉｎｄｅｘ、ｓｅｑＮｕｍｂｅｒは以下のような並びになる。
【００７５】
2005012686.tif 000003
次に、配列Ｉｎｆｏをタイル番号順にソートする（ステップＳ１３０４）。すなわち、配列Ｉｎｆｏ［ｘ］（ｘ＝０，１，２，，，３８３）のＴｉｎｄｅｘを参照し、値が小さい順に配列Ｉｎｆｏ［ｘ］を並び替える。ソートの方法としては、クイックソートなどの方法が考えられるが、その方法については特に限定するものではない。
【００７６】
本実施形態ではステップＳ１３０４における並び替えの処理によって、配列Ｉｎｆｏの並びが以下のようになったとする。
【００７７】
2005012686.tif 000004
次に、タイル番号が同じ配列Ｉｎｆｏ同士を、ｓｅｑＮｕｍｂｅｒが示す番号順にソートする（ステップＳ１３０５）。例えば配列Ｉｎｆｏの上記並びにおいてＴｉｎｄｅｘが０である配列は先頭から６つあるので、この６つの配列をｓｅｑＮｕｍｂｅｒが示す値が小さい順に並び替える。同様の処理をＴｉｎｄｅｘが１以降についても行う。この場合のソートの方法としても、クイックソートなどの方法が考えられるが、その方法については特に限定するものではない。
【００７８】
ステップＳ１３０４、ステップＳ１３０５による処理の結果、配列Ｉｎｆｏは各タイル内でｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ順に並んでいたので、このステップＳ１３０４、ステップＳ１３０５による処理の前後で配列Ｉｎｆｏの並びは上記並びと同じである。
【００７９】
なお図示していないがステップＳ１３０４，ステップＳ１３０５では、受信バッファに記憶されている各パケットのデータも同様に並び替えるものとする。即ち、受信バッファに記憶されている各パケットのデータを、含まれるタイルの番号順に並び替え、更に、含まれるタイル内の順番に従って並び替える。
【００８０】
次に、並び替えられた各パケットのデータを、並び替えた順番で上記キャッシュファイルに付加すると共に、各パケットを管理するための情報としての上記管理情報に上記付加された夫々のパケットに関する情報を登録する（ステップＳ１３０６）。
【００８１】
次に、上記ステップＳ１３０６における処理の詳細を図１５に示すフローチャートを参照して以下説明する。図１５は、ステップＳ１３０６における処理の詳細を示すフローチャートである。
【００８２】
まず受信した各パケットをカウントする為の変数Ｉに１を代入して初期化する（ステップＳ１５０１）。次に、配列Ｉｎｆｏにおいて、同じＴｉｎｄｅｘの値を有し、且つｓｅｑＮｕｍｂｅｒが連続する数をカウントする為の変数Ｘに１を代入して初期化する（ステップＳ１５０２）。
【００８３】
次に、（Ｉ−１）番目の配列Ｉｎｆｏのタイル番号ＴｉｎｄｅｘとＩ番目の配列Ｉｎｆｏのタイル番号Ｔｉｎｄｅｘとを比較し、夫々が同じ値であるか否か、換言すれば、（Ｉ−１）番目の配列ＩｎｆｏとＩ番目の配列Ｉｎｆｏとが、同じタイルに含まれるパケットに関する情報を格納しているのかを否かを判断する（ステップＳ１５０３）。
【００８４】
（Ｉ−１）番目の配列Ｉｎｆｏのタイル番号ＴｉｎｄｅｘとＩ番目の配列Ｉｎｆｏのタイル番号Ｔｉｎｄｅｘとが同じ値、即ち、（Ｉ−１）番目の配列ＩｎｆｏとＩ番目の配列Ｉｎｆｏとが、同じタイルに含まれるパケットに関する情報を格納している場合には処理をステップＳ１５０４に進め、（Ｉ−１）番目の配列ＩｎｆｏのｓｅｑＮｕｍｂｅｒが示す値に１を加えた値とＩ番目の配列ＩｎｆｏのｓｅｑＮｕｍｂｅｒが示す値とを比較し、夫々が同じ値であるか否か、換言すれば、（Ｉ−１）番目の配列ＩｎｆｏとＩ番目の配列Ｉｎｆｏとが、順番が連続している（順番が隣接している）パケットに関する情報を格納しているのかを否かを判断する（ステップＳ１５０４）。
【００８５】
（Ｉ−１）番目の配列ＩｎｆｏのｓｅｑＮｕｍｂｅｒが示す値に１を加えた値とＩ番目の配列ＩｎｆｏのｓｅｑＮｕｍｂｅｒが示す値とが同じ値、即ち、（Ｉ−１）番目の配列ＩｎｆｏとＩ番目の配列Ｉｎｆｏとが、順番が連続している（順番が隣接している）パケットに関する情報を格納している場合には処理をステップＳ１５０５に進め、上記変数Ｘ、Ｉ夫々に１を加えて更新する（ステップＳ１５０５）。
【００８６】
一方、ステップＳ１５０３における判断の結果、（Ｉ−１）番目の配列Ｉｎｆｏのタイル番号ＴｉｎｄｅｘとＩ番目の配列Ｉｎｆｏのタイル番号Ｔｉｎｄｅｘとが異なる値、即ち、（Ｉ−１）番目の配列ＩｎｆｏとＩ番目の配列Ｉｎｆｏとが、夫々異なるタイルに含まれるパケットに関する情報を格納している場合、もしくは、ステップＳ１５０４における判断の結果、（Ｉ−１）番目の配列ＩｎｆｏのｓｅｑＮｕｍｂｅｒが示す値に１を加えた値とＩ番目の配列ＩｎｆｏのｓｅｑＮｕｍｂｅｒが示す値とが異なる値、即ち、（Ｉ−１）番目の配列ＩｎｆｏとＩ番目の配列Ｉｎｆｏとが、順番が連続していない（順番が隣接していない）パケットに関する情報を格納している場合には処理をステップＳ１５０８に進め、後述するキャッシュファイルの更新処理を行う（ステップＳ１５０８）。ステップＳ１５０８における処理の詳細については後述する。
【００８７】
そしてキャッシュファイルの更新処理の後、上記変数Ｘに１を代入して初期化し、更に変数Ｉに１を加えて更新する（ステップＳ１５０９）。そしてステップＳ１５０５，ステップＳ１５０９の何れの処理の後にも変数Ｉが示す値が受信すべき総パケット数Ｒｅｓｐ＿ｎｕｍｂｅｒと同じ値であるか否かを判断する（ステップＳ１５０６）。同じでない場合には処理をステップＳ１５０３に戻し、以降の処理を行う。
【００８８】
一方、同じでない場合には処理をステップＳ１５０７に進め、ステップＳ１５０８と同じキャッシュファイルの更新処理を行う。ステップＳ１５０７における処理はステップＳ１５０８における処理と同じであるので、以下、まとめてこれらの処理について説明する。
【００８９】
図１６はステップＳ１５０７，ステップＳ１５０８におけるキャッシュファイルの更新処理の詳細を示すフローチャートである。キャッシュファイルの更新処理とは上述の通り、同じタイルに含まれ、且つ同じタイル内で順番が連続したパケット群のデータをキャッシュファイルに順次付加（キャッシュ）し、更に、このパケット群に関する情報をキャッシュファイルに含まれる管理情報に登録する処理である。管理情報に対して登録する情報は、配列Ｉｎｆｏ［Ｉ−Ｘ］からＩｎｆｏ［Ｉ−１］に格納されている。
【００９０】
なお、本実施形態の場合、配列Ｉｎｆｏにおいて最初にこのキャッシュファイルの更新処理の対象となるのは、配列Ｉｎｆｏ［０］，Ｉｎｆｏ［１］，Ｉｎｆｏ［２］であって、夫々の配列におけるＴｉｎｄｅｘ、ｓｅｑＮｕｍｂｅｒ、Ｌｅｎｇｔｈは以下の通りとなる。
【００９１】
2005012686.tif 000005
また、これらの配列に対するキャッシュファイルの更新処理を行う時点での変数Ｘ、Ｉの値は共に３である。
【００９２】
キャッシュファイルの更新処理において、まずキャッシュファイルのファイルサイズＦｓｉｚｅを取得する（ステップＳ１６０１）。本実施形態では、Ｆｓｉｚｅ＝３８６３０［ｂｙｔｅ］と仮定する。
【００９３】
次に、配列Ｉｎｆｏの番号をカウントする変数ａｎに（Ｉ−Ｘ）が示す値を代入し、更に、キャッシュファイルの先頭から、このキャッシュファイルに以降付加（キャッシュ）されていく各パケットのデータの先頭までのオフセット値を代入するための変数ｓｐにステップＳ１６０１で取得したファイルサイズＦｓｉｚｅが示す値を代入し、初期化する（ステップＳ１６０２）。
【００９４】
本実施形態ではこの時点で
ａｎ＝０
ｓｐ＝３８６３０
となっている。
【００９５】
そして以下説明するステップＳ１６０３からステップＳ１６０８までの処理を対象とする全てのパケット（上記並び替えられたパケットのうち、（Ｉ−Ｘ）番目から（Ｉ−１）番目のパケット）に対して行うことで、対象とする全てのパケットに関する情報を管理情報に登録することができると共に、対象とする全てのパケットのデータをキャッシュファイルに順次付加（キャッシュ）することができる。以下、ステップＳ１６０３からステップＳ１６０８までの各処理について説明する。
【００９６】
先ず管理情報において、Ｉｎｆｏ［ａｎ］．Ｔｉｎｄｅｘをタイル番号とするタイルにおいて、Ｉｎｆｏ［ａｎ］．ｓｅｑＮｕｍｂｅｒで表される順番のパケット（以下、パケットａｎと呼称する）を管理するための情報（Ｏｆｆｓｅｔ，Ｌｅｎｇｔｈ，ＳｅｑＮｕｍｂｅｒ，ＳｅｑＦｌａｇ）において、Ｏｆｆｓｅｔに上記変数ｓｐが示す値を代入し、ＬｅｎｇｔｈにＩｎｆｏ［ａｎ］．Ｌｅｎｇｔｈが示す値を代入する（ステップＳ１６０３）。
【００９７】
本実施形態では最初にタイル番号が０，ｓｅｑＮｕｍｂｅｒが０のパケットを管理するための情報が更新され、このパケットに関する情報のうちＯｆｆｓｅｔに上記変数ｓｐが示す値３８６３０が代入され、ＬｅｎｇｔｈにＩｎｆｏ［０］．Ｌｅｎｇｔｈが示す値６４が代入される。
【００９８】
これにより、キャッシュファイルの先頭から３８６３０バイト目以降、６４バイト分のところにタイル番号が０，ｓｅｑＮｕｍｂｅｒが０のパケットのデータが付加（キャッシュ）されるという旨、即ちタイル番号が０，ｓｅｑＮｕｍｂｅｒが０のパケットのデータのキャッシュファイルにおける配置情報を登録することができる。
【００９９】
次に、管理情報におけるパケットａｎのＳｅｑＦｌａｇを更新する。いうまでもなく、配列Ｉｎｆｏ［Ｉ−Ｘ］から配列Ｉｎｆｏ［Ｉ−１］までの各配列には連続した順番のパケットに関する情報が格納されている。従って、ａｎが（Ｉ−１）でない限り、管理情報においてパケットａｎを管理するための情報の次には連続してパケット（本実施形態の場合タイル番号が０，ｓｅｑＮｕｍｂｅｒが１のパケット）を管理するための情報が登録されることになるので、パケットａｎのＳｅｑＦｌａｇにはこのことを示す値ＩＮ＿ＳＥＱＵＥＮＣＥ（パケットａｎの次に連続してパケットを管理するための情報が登録されない場合にはＮＯＮ＿ＩＮ＿ＳＥＱＵＥＮＣＥ）を代入する。
【０１００】
このことから、図１６に示すフローチャートでは、変数ａｎが示す値が（Ｉ−１）が示す値と同じであるか、即ち、処理が対象とする最後のパケットまで達しているのかを判断する（ステップＳ１６０４）。達していない場合（本実施形態ではａｎ＝０，１の場合）には処理をステップＳ１６０５に進め、達している場合（本実施形態ではａｎ＝２の場合）にはステップＳ１６０５をスキップして処理をステップＳ１６０６に進める。
【０１０１】
そして上述の通り、達していない場合（本実施形態ではａｎ＝０，１の場合）にはパケットａｎのＳｅｑＦｌａｇには値ＩＮ＿ＳＥＱＵＥＮＣＥを代入する（ステップＳ１６０５）。本実施形態ではタイル番号が０、ｓｅｑＮｕｍｂｅｒが０，１であるパケットについてはＳｅｑＦｌａｇには値ＩＮ＿ＳＥＱＵＥＮＣＥが代入される。
【０１０２】
次に、変数ｓｐにパケットａｎの長さを示す変数Ｉｎｆｏ［ａｎ］．Ｌｅｎｇｔｈを加え、キャッシュファイルの先頭からパケット（ａｎ＋１）の先頭までのオフセット値を求めて再度変数ｓｐに代入する（ステップＳ１６０６）。本実施形態ではａｎ＝０の時にはｓｐ＝３８６３０＋Ｉｎｆｏ［０］．Ｌｅｎｇｔｈ＝３８６３０＋６４＝３８６９４となり、これがキャッシュファイルの先頭からタイル番号が０，ｓｅｑＮｕｍｂｅｒが１のパケット（上記パケット（ａｎ＋１）に相当）のデータの先頭までのオフセット値となる。
【０１０３】
そして次のパケットであるパケット（ａｎ＋１）に関する情報を管理情報に登録する対象とするために、変数ａｎに１を加える（ステップＳ１６０７）。そして次に、変数ａｎが示す値が変数Ｉが示す値と同じであるか、即ち、配列Ｉｎｆｏ［Ｉ−Ｘ］から配列Ｉｎｆｏ［Ｉ−１］までの各配列に格納されたパケットに関する情報を管理情報に登録したかを判断し（ステップＳ１６０８）、全て登録していない場合には処理をステップＳ１６０３に戻し、以降の処理を繰り返す。
【０１０４】
一方、全て登録した場合には処理をステップＳ１６０９に進め、受信バッファに記憶された、並び替えられた各パケットのデータのうち、（Ｉ−Ｘ）番目からＸ個分（（Ｉ−１）番目まで）の各パケットのデータを順番にキャッシュファイルに付加（キャッシュ）する（ステップＳ１６０９）。
【０１０５】
受信バッファに記憶された、並び替えられた各パケットのデータのうち、キャッシュファイルに付加（キャッシュ）するパケットのデータの特定については、上記受信バッファの先頭から、Ｉｎｆｏ［ｚ］．Ｂｏｆｆｓｅｔバイト目のデータからＩｎｆｏ［ｚ］．Ｌｅｎｇｔｈバイト分のデータを抜き出し、キャッシュファイルに付加する（ただし、ｚは（Ｉ−Ｘ）から（Ｉ−１）までの値である）。
【０１０６】
以上の処理により、図１１（ａ）に示した管理情報は、図１１（ｂ）に示した管理情報に更新される。同図に示すように、キャッシュファイルの最後に付加した各パケットのデータのキャッシュファイルにおける配置については管理情報にＯｆｆｓｅｔ、Ｌｅｎｇｔｈとして登録されている。本実施形態の場合、０番目から２番目までのパケットのデータ、即ち、タイル番号が０で、ｐａｃｋｅｔ  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒが０，１，２の各パケットのデータがこの順番でキャッシュファイルに付加されることになる。
【０１０７】
以上の説明により、本実施形態によって、受信した各パケットのデータを連続して、順番にキャッシュすることができるので、これらのパケットを読み出す際にはまとめて読み出すことができる。これにより読み出しのためのキャッシュファイルへのアクセス数が軽減される。
【０１０８】
また、読み出す際に、キャッシュファイル中の各パケットのデータの配置が管理情報に登録されているので、キャッシュファイル中における各パケットのデータの位置を特定することが容易となり、各パケットのデータを読み出す処理をより高速に行うことができる。
【０１０９】
［第２の実施形態］
本実施形態では、第１の実施形態で生成したキャッシュファイルから、ＪＰＥＧ２０００のビットストリームを生成する処理について説明する。なお、以下ではキャッシュファイル中のメインヘッダは第１の実施形態で取得したメインヘッダ、そしてパケットのデータはｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  １、ｌａｙｅｒ  ０、３  ｃｏｍｐｏｎｅｎｔを構成するパケットのデータとするが、以下説明する趣旨はこれに限定されるものではない。ただし、未受信のパケットのデータの部分には、ｚｅｒｏ  ｌｅｎｇｔｈ  ｐａｃｋｅｔをダミーデータとして利用する。
【０１１０】
図１７は、キャッシュファイルから、各タイルのパケットのデータを出力ファイルに読み出す処理のフローチャートである。なお同図のフローチャートに従ったプログラムは二次記憶メモリ１０３に保存されており、ＣＰＵ１０１による制御の下で一次記憶メモリ１０２にロードされ、ＣＰＵ１０１がこれを実行することで、クライアント端末装置２０１（２０２でも良い）は以下説明する処理を行うことになる。
【０１１１】
まずキャッシュファイルから画像の基本情報を取り出し、タイル数ＴＮを取得する（ステップＳ１７０１）。本実施形態ではキャッシュファイルは第１の実施形態で作成されたものを用いるので、画像の基本情報も当然第１の実施形態で説明したものと同じであるので、ＴＮ＝６４である。
【０１１２】
次に、キャッシュファイルからメインヘッダデータを読み出し、出力ファイルに出力する（ステップＳ１７０２）。なお、出力ファイルは一次記憶メモリ１０２上に作成されるものとする。この出力ファイルには後述の処理によってタイル毎にパケットのデータを出力するので、夫々のタイルの番号をカウントする為の変数が必要となる。よってこの変数をｔとし、この変数ｔを０に初期化する（ステップＳ１７０３）。
【０１１３】
次に、タイル番号ｔのタイルヘッダを取得し、出力ファイルに書き込む（ステップＳ１７０４）。本実施形態では、全てのタイルが同じエンコード条件のため、タイルの管理情報から、タイル番号、キャッシュから作成されるタイルのデータ長を取得することで、タイルヘッダを簡単に作成・取得することができる。
【０１１４】
次に、画像の基本情報を参照し、タイル番号ｔのタイルに含まれるパケットの総数ＰａＮを取得する（ステップＳ１７０５）。画像の基本情報は当然第１の実施形態で説明したものと同じであるのでＰａＮ＝３６となる。そしてキャッシュファイルから読み出すパケットのデータをカウントする為の変数ｋを０に初期化する（ステップＳ１７０６）。
【０１１５】
そして次に、キャッシュファイル中の各パケットを管理するための情報（管理情報）から、タイル番号ｔのタイル中のパケット群で上記変数ｋが示す値と同じ値であるｓｅｑＮｕｍｂｅｒに対応するパケットの情報（Ｏｆｆｓｅｔ，Ｌｅｎｇｔｈ，ＳｅｑＮｕｍｂｅｒ，ＳｅｑＦｌａｇ）をキャッシュファイルから取得する（ステップＳ１７０７）。
【０１１６】
まず各変数ｔ、ｋは共に０に初期化されているので、本実施形態では次のデータを取得することになる（図１１（ｂ）に示した管理情報において、最初のパケットの情報、即ち、タイル番号０のタイル中のｓｅｑＮｕｍｂｅｒが０であるパケットの情報）。
【０１１７】
Ｏｆｆｓｅｔ        ＝  ３８６３０
Ｌｅｎｇｔｈ        ＝  ６４
ＳｅｑＮｕｍｂｅｒ  ＝  ０
ＳｅｑＦｌａｇ      ＝  ＩＮ＿ＳＥＱＵＥＮＣＥ
次に以下説明する各変数を初期化する（ステップＳ１７０８）。キャッシュファイルに付加した各パケットのデータにおいて、同じタイルに含まれ、且つ同じタイル内で順番が連続したパケットの数をカウントする為の変数ｙに１を代入して初期化する。
【０１１８】
また、キャッシュファイルの先頭から読み出すパケットのデータの先頭までのオフセット値、即ち、これから読み出そうとするパケットのデータのキャッシュファイルにおける読み出し位置を保持するための変数ＲｅａｄＰｏｉｎｔに、ステップＳ１７０７で取得したＯｆｆｓｅｔが示す値を代入する。
【０１１９】
また、読み出すパケット群（ｓｅｑＮｕｍｂｅｒの値が連続する値であるパケット群）のデータ長を保持するための変数ＲｅａｄＢｙｔｅに、ステップＳ１７０７で取得したＬｅｎｇｔｈが示す値を代入する。本実施形態ではｔ＝０，ｋ＝０の場合には、これら３つの変数が示す夫々の値は以下のようになる。
【０１２０】
ｙ                  ＝  １
ＲｅａｄＰｏｉｎｔ  ＝  ３８６３０
ＲｅａｄＢｙｔｅ    ＝  ６４
次に、ステップＳ１７０７で得られたｓｅｑＦｌａｇが示す値が、ＩＮ＿ＳＥＱＵＥＮＣＥであるか（換言すれば、タイル番号ｔのタイル中のｓｅｑＮｕｍｂｅｒがｋであるパケットのデータとタイル番号ｔのタイル中のｓｅｑＮｕｍｂｅｒが（ｋ＋１）であるパケットのデータとが連続してキャッシュファイルに付加されているか）を判断する（ステップＳ１７０９）。
【０１２１】
ｓｅｑＦｌａｇがＩＮ＿ＳＥＱＵＥＮＣＥである場合には、処理をステップＳ１７１０に進め、そうでない場合には処理をステップＳ１７１３に進める。例えばｔ＝０，ｋ＝０の場合、本実施形態では図１１に示すとおりｓｅｑＦｌａｇはＩＮ＿ＳＥＱＵＥＮＣＥであるので、処理はステップＳ１７１０に進めることになる。そして上記変数ｋ、ｙが保持する値を一つインクリメントし（ステップＳ１７１０）、次のパケット（タイル番号が０のタイル中のパケット群でインクリメントされた変数ｋ（＝１）が示す値と同じ値であるｓｅｑＮｕｍｂｅｒに対応するパケット）の情報（Ｏｆｆｓｅｔ，Ｌｅｎｇｔｈ，ＳｅｑＮｕｍｂｅｒ，ＳｅｑＦｌａｇ）をキャッシュファイルから取得する（ステップＳ１７１１）。
【０１２２】
変数ｔ＝０、ｋ＝１であるので、本実施形態では次のデータを取得することになる（図１１（ｂ）に示した管理情報において、次のパケットの情報、即ち、タイル番号０のタイル中のｓｅｑＮｕｍｂｅｒが１であるパケットの情報）。
【０１２３】
Ｏｆｆｓｅｔ        ＝  ３８６９４
Ｌｅｎｇｔｈ        ＝  ７２
ＳｅｑＮｕｍｂｅｒ  ＝  １
ＳｅｑＦｌａｇ      ＝  ＩＮ＿ＳＥＱＵＥＮＣＥ
そして次に、読み出すパケット群（ｓｅｑＮｕｍｂｅｒの値が連続する値であるパケット群）のデータ長を保持するための変数ＲｅａｄＢｙｔｅに、ステップＳ１７１１で取得した情報に含まれるＬｅｎｇｔｈが示す値を加算する（ステップＳ１７１２）。ステップＳ１７１０からステップＳ１７１２までの処理をステップＳ１７１１で取得した情報におけるｓｅｑＦｌａｇがＩＮ＿ＳＥＱＵＥＮＣＥである限り、即ち、ｓｅｑＮｕｍｂｅｒが連続した数値である限り繰り返して行う。
【０１２４】
この切り返し処理により、変数ＲｅａｄＢｙｔｅには、タイル番号がｔで、読み出すパケット群（ｓｅｑＮｕｍｂｅｒの値が連続する値であるパケット群）のデータ長が格納されることになる。
【０１２５】
本実施形態ではｔ＝０，ｋ＝２になった場合に、処理をステップＳ１７１３に進める。本実施形態でステップＳ１７１３に進んだ時における各変数が示す値は以下のようになっている。
【０１２６】
ｔ＝０，  ｋ＝２
Ｏｆｆｓｅｔ        ＝  ３８７６８
ＳｅｑＮｕｍｂｅｒ  ＝  ２
ＳｅｑＦｌａｇ      ＝  ＮＯＮ＿ＩＮ＿ＳＥＱＵＥＮＣＥ
ｙ                  ＝  ３
ＲｅａｄＰｏｉｎｔ  ＝  ３８７６８
ＲｅａｄＢｙｔｅ    ＝  １７４
次に、変数ＲｅａｄＰｏｉｎｔの値が０であるか否かを判断する（ステップＳ１７１３）。ＲｅａｄＰｏｉｎｔの値が０ではない場合には処理をステップＳ１７１４に進め、キャッシュファイルの先頭からＲｅａｄＰｏｉｎｔバイト目からＲｅａｄＢｙｔｅバイト分のデータを読み出し、出力ファイルに書き込む（ステップＳ１７１４）。本実施形態の場合、キャッシュファイルの先頭から３８７６８バイト目から１７４バイト分のデータ、即ち、タイル番号が０でｓｅｑＮｕｍｂｅｒが０，１，２のパケットのデータをキャッシュファイルから読み出し、出力ファイルに書き込む。
【０１２７】
一方、ＲｅａｄＰｏｉｎｔの値が０である場合には処理をステップＳ１７１５に進め、パケットのデータはないと判断し、ｚｅｒｏ  ｌｅｎｇｔｈ  ｐａｃｋｅｔデータを出力ファイルに書き込む（ステップＳ１７１５）。そして次に読み出すパケットをカウントする為の変数ｋの値を一つインクリメントし（ステップＳ１７１６）、インクリメント後の変数ｋの値がタイル番号ｔのタイルに含まれるパケットの総数ＰａＮに達したか否かを判断する（ステップＳ１７１７）。
【０１２８】
ｋ＝ＰａＮの場合、タイル番号ｔのタイルに含まれるパケットのデータは全て出力ファイルに出力したものと判断し、次のタイルを処理対象とする為に、タイル番号を表す変数ｔの値を一つインクリメントする（ステップＳ１７１８）。本実施形態ではｋ＝ＰａＮ＝３６となった場合に、タイル番号０のタイル中の３６個のパケットのデータが出力ファイルに書き込まれたものと判断する。
【０１２９】
一方、ｋ＜ＰａＮの場合、タイル番号ｔのタイルに含まれるパケットのデータは全て出力ファイルに出力されていないと判断し、処理をステップＳ１７０６に戻し、以降の処理を行う。
【０１３０】
そしてｋ＝ＰａＮの場合、インクリメント後の変数ｔの値がタイル数ＴＮに達したか否かを判断し（ステップＳ１７１９）、ｔ＝ＴＮの場合、全てのタイルについてパケットのデータを出力ファイルに書き込んだものと判断し、本処理を終了する。一方、ｔ＜ＴＮの場合、全てのタイルについてパケットのデータを出力ファイルに書き込んでいないものと判断し、次にタイルについてパケットのデータの出力ファイルへの書き込み処理を行うために、処理をステップＳ１７０４に戻し、以降の処理を行う。
【０１３１】
以上の処理によって出力ファイル、換言すればＪＰＥＧ２０００のビットストリームが生成されることになる。
【０１３２】
以上の説明により、本実施形態によれば、連続してキャッシュされているパケットのデータを１回のファイルリードで取得することができる。これによりファイルのシーク回数を減らすことができ、キャッシュファイルからＪＰＥＧ２０００のビットストリームを生成する処理がより高速化されることになる。
【０１３３】
［第３の実施形態］
本実施形態では、上記ｓｅｑＦｌａｇを用いずに、第１，２の実施形態と同様の目的を達成する画像処理について説明する。
【０１３４】
まずキャッシュファイルの作成処理について説明すると、本実施形態ではｓｅｑＦｌａｇは用いない。従って本実施形態に係るキャッシュファイルの作成処理のフローチャートは、図９に示したフローチャートのステップＳ９０４において、各パケットについてｓｅｑＦｌａｇを除く他の３つについてのみ管理情報に含めるように変更したものとなる。またこれに伴って、本実施形態に係るキャッシュファイルの更新処理のフローチャートは図１８に示すように、図１６に示したフローチャートにおいて、ｓｅｑＦｌａｇに係る処理即ちステップＳ１６０４，Ｓ１６０５を省いたものとなり、その他については同じである。
【０１３５】
従ってこのような処理によって作成されるキャッシュファイルの構成は図１９（ｂ）に示すようになる。図１９（ｂ）は本実施形態に係るキャッシュファイルの作成処理によって作成されたキャッシュファイルの構成を示す図で、図１９（ａ）は、第１の実施形態に係るキャッシュファイルの作成処理によって作成されたキャッシュファイルの構成を示す図である。双方を比較しても分かるように、例えばあるタイルの１番目のパケットの管理情報を比較しても、管理情報１００３にはｓｅｑＦｌａｇが含まれているのに対して、管理情報１９０２にはｓｅｑＦｌａｇが含まれておらず、その他については管理情報１００３と同じである。
【０１３６】
次に、本実施形態に係るキャッシュファイルから、ＪＰＥＧ２０００のビットストリームを生成する処理について説明する。図２０は、キャッシュファイルから、各タイルのパケットのデータを出力ファイルに読み出す処理のフローチャートである。なお同図のフローチャートに従ったプログラムは二次記憶メモリ１０３に保存されており、ＣＰＵ１０１による制御の下で一次記憶メモリ１０２にロードされ、ＣＰＵ１０１がこれを実行することで、クライアント端末装置２０１（２０２でも良い）は以下説明する処理を行うことになる。なお図２０において、図１７に示した各ステップと同じものについては同じステップ番号を付けており、その説明は既に説明済みであることから、ここではその説明は省略する。
ステップＳ１７０１からステップＳ１７０７までの処理では第２の実施形態と同様の処理を行う。次に以下説明する各変数を初期化する（ステップＳ２００１）。
【０１３７】
キャッシュファイルに付加した各パケットのデータにおいて、同じタイルに含まれ、且つ同じタイル内で順番が連続しているかを判定する為の変数ＪにステップＳ１７０７で取得したＯｆｆｓｅｔの値を代入して初期化する。
【０１３８】
また、キャッシュファイルに付加した各パケットのデータにおいて、同じタイルに含まれ、且つ同じタイル内で順番が連続したパケットの数をカウントする為の変数ｙに０を代入して初期化する。
【０１３９】
また、キャッシュファイルの先頭から読み出すパケットのデータの先頭までのオフセット値、即ち、これから読み出そうとするパケットのデータのキャッシュファイルにおける読み出し位置を保持するための変数ＲｅａｄＰｏｉｎｔに、ステップＳ１７０７で取得したＯｆｆｓｅｔが示す値を代入する。
【０１４０】
また、読み出すパケット群（ｓｅｑＮｕｍｂｅｒの値が連続する値であるパケット群）のデータ長を保持するための変数ＲｅａｄＢｙｔｅに０を代入して初期化する。
【０１４１】
次に、上記初期化処理が終了すると、連続パケットカウント用変数ｙの値とパケットカウント用変数ｋの値を夫々一つインクリメントし、更に、連続性を判定する為の変数ｊが有する値と、読み出すパケット群（ｓｅｑＮｕｍｂｅｒの値が連続する値であるパケット群）のデータ長を保持するための変数ＲｅａｄＢｙｔｅが有する値とに夫々Ｌｅｎｇｔｈの値を足す（ステップＳ２００２）。
【０１４２】
変数ｊの値にＬｅｎｇｔｈの値を足すことで変数ｊには、キャッシュファイルの先頭から、タイル番号ｔのタイル中のパケット群で変数ｋが示す値と同じ値であるｓｅｑＮｕｍｂｅｒに対応するパケット（これをパケットｋと呼称する）のすぐ後にキャッシュファイルに付加されたパケット（これをパケット（ｋ＋１）と呼称する）の先頭までのオフセット値が格納されていることになる。
【０１４３】
次に、変数ｋの値がタイル番号ｔのタイルに含まれるパケットの総数ＰａＮに達したか否かを判断する（ステップＳ２００３）。
【０１４４】
ｋ＝ＰａＮの場合、タイル番号ｔのタイルに含まれるパケットのデータは全て出力ファイルに出力したものと判断し、処理をステップＳ１７１３に進める。
【０１４５】
一方、ｋ＜ＰａＮの場合、タイル番号ｔのタイルに含まれるパケットのデータは全て出力ファイルに出力されていないと判断し、処理をステップＳ２００４に進め、パケット（ｋ＋１）の管理情報を取得する（ステップＳ２００４）。即ち、ステップＳ１７０７で取得したパケット（パケットｋ）の管理情報の次のパケット（パケット（ｋ＋１））の管理情報を取得する。
【０１４６】
そしてここで変数Ｊの値がＯｆｆｓｅｔの値と同じであるかを判断する（ステップＳ２００５）。Ｊ＝Ｏｆｆｓｅｔの場合、これは即ち、パケットｋとパケット（ｋ＋１）とが連続してキャッシュファイルに付加されていることを意味する。従って、処理をステップＳ２００２に戻し、更に連続して付加されているパケットのデータが存在するかをチェックする。
【０１４７】
一方、Ｊ≠Ｏｆｆｓｅｔの場合、これは即ち、パケットｋとパケット（ｋ＋１）とが連続してキャッシュファイルに付加されていないことを意味する。従って、処理をステップＳ１７１３に進める。
【０１４８】
なお、本実施形態ではステップＳ１７１３以降の処理は図１７と比べてステップＳ１７１６が存在しないだけでその他については図１７と同じである。
【０１４９】
このように本実施形態によればｓｅｑＦｌａｇを用いないので、上記実施形態と比べてもキャッシュファイルのサイズを小さくすることができる。このｓｅｑＦｌａｇは上記第１，２の実施形態では各パケット毎に存在していたので、パケットの数が多ければそれだけの数必要となっていた。しかし本実施形態ではｓｅｑＦｌａｇは用いないので、パケットの数が多ければ多いほど、その効果はより大きなものとなる。
【０１５０】
［その他の実施形態］
本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【０１５１】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５２】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５３】
本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【０１５４】
【発明の効果】
以上の説明により、本発明によって、符号化データを受信してキャッシュする場合に、キャッシュしたデータに対してアクセスする際に要する時間や回数を軽減させることができる。
【図面の簡単な説明】
【図１】ＰＣ（パーソナルコンピュータ）やワークステーションなどにより構成される、本発明の第１の実施形態に係る画像処理装置の基本構成を示すブロック図である。
【図２】図１に示した画像処理装置を含むシステムの概要を示す図である。
【図３】Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ  ｐｒｏｇｒｅｓｓｉｏｎ（以下、ＬＲＣＰと記す）に従ったＪＰＥＧ２０００のビットストリームの構成を示す図である。
【図４】解像度とＲｅｓｏｌｕｔｉｏｎ番号との関係を示す図である。
【図５】パケット単位でのリクエスト及びレスポンスの概念図である。
【図６】（ａ）、（ｂ）はｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎを説明するための図である。
【図７】本発明の第１の実施形態に係るエンコード条件で符号化された画像の符号化データ、即ちＪＰＥＧ２０００のビットストリームの構成を示す図である。
【図８】各タイルに付けられた番号を説明するための図である。
【図９】本発明の第１の実施形態に係るキャッシュファイルを作成する為の処理のフローチャートである。
【図１０】本発明の第１の実施形態に係るキャッシュファイルの概略構成を示す図である。
【図１１】（ａ）は、初期化された状態の管理情報を示す図で、（ｂ）は更新された管理情報を示す図である。
【図１２】クライアント端末装置２０１がサーバ装置２０４に画像の符号化データを要求し、要求に応じてサーバ装置２０４がパケット毎に送信する画像の符号化データを受信し、受信した画像の符号化データをデコードして表示装置としての出力デバイス１０５に表示するまでの処理のフローチャートである。
【図１３】サーバ装置２０４からパケット単位で受信した画像の符号化データをキャッシュする処理の詳細のフローチャートである。
【図１４】配列Ｉｎｆｏの構成を示す図である。
【図１５】ステップＳ１３０６における処理の詳細を示すフローチャートである。
【図１６】ステップＳ１５０７，ステップＳ１５０８におけるキャッシュファイルの更新処理の詳細を示すフローチャートである。
【図１７】キャッシュファイルから、各タイルのパケットのデータを出力ファイルに読み出す処理のフローチャートである。
【図１８】本発明の第３の実施形態に係るキャッシュファイルの更新処理のフローチャートである。
【図１９】（ａ）は本発明の第１の実施形態に係るキャッシュファイルの作成処理によって作成されたキャッシュファイルの構成を示す図で、（ｂ）は本発明の第３の実施形態に係るキャッシュファイルの作成処理によって作成されたキャッシュファイルの構成を示す図である。
【図２０】キャッシュファイルから、各タイルのパケットのデータを出力ファイルに読み出す処理のフローチャートである。
【図１】
2005012686.tif 000006
【図２】
2005012686.tif 000007
【図３】
2005012686.tif 000008
【図４】
2005012686.tif 000009
【図５】
2005012686.tif 000010
【図６】
2005012686.tif 000011
【図７】
2005012686.tif 000012
【図８】
2005012686.tif 000013
【図９】
2005012686.tif 000014
【図１０】
2005012686.tif 000015
【図１１】
2005012686.tif 000016
【図１２】
2005012686.tif 000017
【図１３】
2005012686.tif 000018
【図１４】
2005012686.tif 000019
【図１５】
2005012686.tif 000020
【図１６】
2005012686.tif 000021
【図１７】
2005012686.tif 000022
【図１８】
2005012686.tif 000023
【図１９】
2005012686.tif 000024
【図２０】
2005012686.tif 000025