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