(57)【要約】【課題】  所望の画像を得るために必要な符号化データのデータサイズの上限値を指定して、この符号化データを得るための技術を提供すること。【解決手段】  所望の画像を得るために必要な符号化データの送信要求を受信し（Ｓ８０１）、送信要求に応じて返信すべきタイルの符号化データのデータ量の上限値が指定されているか否かを判断し（Ｓ８０２）、上限値が指定されている場合、返信すべき各タイルの符号化データを所望のタイル順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、送信要求に応じた論理単位のデータ、及び論理単位のヘッダデータをメモリに出力し、出力する順にデータのサイズを計数し、計数結果が上限値を超えるまでに出力したデータ群を返信する（Ｓ８０６，Ｓ８０７）。【選択図】  図８
2005130470.tif 000002
【特許請求の範囲】
【請求項１】
複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持し、外部装置からの要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置に送信する画像処理装置が行う画像処理方法であって、
所望の画像を得るために必要な符号化データの送信要求を受信する受信工程と、
前記送信要求に応じて前記外部装置に送信すべきタイルの符号化データのデータ量の上限値が、前記外部装置より指定されているか否かを判断する判断工程と、
前記上限値が前記外部装置より指定されている場合、前記外部装置に送信すべき各タイルの符号化データを所望のタイル順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力する出力工程と、
前記出力工程で出力する順に各論理単位のデータ、及び各論理単位のヘッダデータのサイズを計数し、計数結果が前記上限値を超えるまでに前記出力工程で出力した論理単位のデータ群、及び各論理単位のヘッダデータ群を前記外部装置に送信する送信工程と
を備えることを特徴とする画像処理方法。
【請求項２】
前記判断工程では、前記外部装置から前記送信要求を示すデータ群に、前記外部装置が要求する符号化データのデータ量の上限値を指定しているデータが含まれているか否かを判断し、当該データが含まれている場合には、当該データが示す数値を前記上限値として解釈することを特徴とする請求項１に記載の画像処理方法。
【請求項３】
前記出力工程では、前記外部装置に送信すべき各タイルの符号化データを前記所望の画像の中心位置に近い順番に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力することを特徴とする請求項１に記載の画像処理方法。
【請求項４】
前記出力工程では、前記外部装置に送信すべき各タイルの符号化データにおいて、メタデータが付与されているタイルの符号化データ、メタデータが付与されていないタイルの符号化データの順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力することを特徴とする請求項１に記載の画像処理方法。
【請求項５】
前記出力工程では、前記外部装置に送信すべき各タイルの符号化データにおいて、メタデータが付与されたタイルにより構成される領域のうち、前記所望の画像に完全に含まれる領域を構成するタイルの符号化データ、前記領域と重なっている部分のタイルの符号化データ、メタデータが付与されていないタイルの符号化データの順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力することを特徴とする請求項４に記載の画像処理方法。
【請求項６】
前記出力工程では、前記外部装置に送信すべき各タイルの符号化データにおいて、暗号化されているタイルの符号化データ、暗号化されていないタイルの符号化データの順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力することを特徴とする請求項１に記載の画像処理方法。
【請求項７】
前記出力工程では、前記外部装置に送信すべき各タイルの符号化データにおいて、暗号化されていないタイルの符号化データ、暗号化されているタイルの符号化データの順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力することを特徴とする請求項１に記載の画像処理方法。
【請求項８】
更に、各タイル毎に外部装置からのアクセス回数を管理する管理工程を備え、
前記出力工程では、前記外部装置に送信すべき各タイルの符号化データをアクセス回数の多い順番に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力することを特徴とする請求項１に記載の画像処理方法。
【請求項９】
複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持する外部装置に対する要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置から受信する画像処理装置が行う画像処理方法であって、
所望の画像を得るために必要な符号化データの送信要求を前記外部装置に送信する第１の送信工程と、
前記送信要求に応じて前記外部装置から送信されるタイルの符号化データのデータ量の上限値を指定するデータを前記外部装置に送信する第２の送信工程とを備え、
前記送信要求に応じた符号化データで、且つ前記上限値以下のデータ量である符号化データを受信し、復号し、所定の装置に出力することを特徴とする画像処理方法。
【請求項１０】
複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持し、外部装置からの要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置に送信する画像処理装置であって、
所望の画像を得るために必要な符号化データの送信要求を受信する受信手段と、
前記送信要求に応じて前記外部装置に送信すべきタイルの符号化データのデータ量の上限値が、前記外部装置より指定されているか否かを判断する判断手段と、
前記上限値が前記外部装置より指定されている場合、前記外部装置に送信すべき各タイルの符号化データを所望のタイル順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力する出力手段と、
前記出力手段が出力する順に各論理単位のデータ、及び各論理単位のヘッダデータのサイズを計数し、計数結果が前記上限値を超えるまでに前記出力手段が出力した論理単位のデータ群、及び各論理単位のヘッダデータ群を前記外部装置に送信する送信手段と
を備えることを特徴とする画像処理装置。
【請求項１１】
複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持する外部装置に対する要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置から受信する画像処理装置であって、
所望の画像を得るために必要な符号化データの送信要求を前記外部装置に送信する第１の送信手段と、
前記送信要求に応じて前記外部装置から送信されるタイルの符号化データのデータ量の上限値を指定するデータを前記外部装置に送信する第２の送信手段とを備え、
前記送信要求に応じた符号化データで、且つ前記上限値以下のデータ量である符号化データを受信し、復号し、所定の装置に出力することを特徴とする画像処理装置。
【請求項１２】
コンピュータに請求項１乃至９の何れか１項に記載の画像処理方法を実行させることを特徴とするプログラム。
【請求項１３】
請求項１２に記載のプログラムを格納することを特徴とする、コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データの送受信に係る技術に関するものである。
【背景技術】
【０００２】
インターネット上では、クライアント端末装置上で動作するＷｅｂブラウザを用いてＷＷＷサーバにアクセスし、Ｗｅｂブラウザを介してクライアント端末装置側で文書データや画像データ等を閲覧することが盛んに行われている。このWWWサーバは、ホームページといわれる公開したい情報をHTMLで記述した情報を保持しており、それをクライアント端末装置側のWebブラウザが解釈して、クライアント端末装置が有する表示装置の表示画面上に表示する。クライアント端末装置側のWebブラウザは、表示装置に表示されているホームページ中のリンク部分がユーザによって指示されると、このリンク部分が示すリンク先を辿って行き、必要な情報を得ることができる。
【０００３】
さらに、サーバが管理しているファイルをダウンロードする方法として、File Transfer Protocol (以下FTPと略す)という方法がある。このFTPとは、ネットワークを通して、サーバ上にあるファイルを一度にクライアント端末装置に転送する仕組みである。
【０００４】
また、画像ファイル全体を一度に転送する技術の中には、サーバ側で送信データの順序を制御する技術がある（例えば特許文献１を参照）。この場合、サーバ側で一部の領域を重要領域であるとあらかじめ設定し、他の領域情報より先行するように順序付けて符号化しておくことにより、クライアントは、伝送の早い段階でその画像の要・不要を判断でき、途中でデータの受信を中断することが可能である。
【０００５】
またあるいは、画像データファイルへ断片的にアクセスして表示するためのプロトコルとして、Flashpix／IIPがある。このIIP(Internet Imaging Protocol)は、Flashpixという画像データファイルフォーマットに最適なプロトコルになっており、画像データの部分アクセスの単位はFlashpixのタイル単位に行うものとなっている。このIIPプロトコルを使用する技術としては従来からいくつかが開示されている（例えば特許文献２を参照）。
【０００６】
しかし、これらのいずれのプロトコルでも、クライアント端末装置はサーバ側にレスポンスデータのサイズを制限する要求を送信する手段は無い。
【特許文献１】特開２０００-５０２６１公報
【特許文献２】特開２００２-４９５１４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
また、２００３年６月現在、JPEG２０００ファイルへ断片的にアクセスして表示するためのプロトコルとして、JPEG２０００ image coding system − Part ９: Interactivity tools, APIs and protocols(以下、JPIPと記す)が検討されている。JPEG２０００とJPIPを利用すれば、FlashpixとIIPを用いた場合と同様に、画像の部分領域へのアクセスや解像度の選択も可能になる。さらに、画質の変更、カラー／モノクロの切り替え、レスポンスデータの制限サイズの設定も、クライアントの要求によって簡単にできる。JPIPを使ってJPEG２０００の画像データを断片的に送信した場合、クライアント側で画像をデコードするためには、受信した断片的な符号化データをキャッシュして置く必要がある。これは、JPEG２０００の各スケーラビリティの符号化データは、そのスケーラビリティより１つ下のスケーラビリティのデータからの差分データであるためである。
【０００８】
クライアントがIIPやJPIPのような対話的な画像通信プロトコルにより、画像の部分領域の要求、解像度、画質、さらには、カラー／モノクロの切り替えを行うような多様なリクエストに対しては、特開２０００-５０２６１のようにサーバ側であらかじめ決められた領域を重要領域として設定しておくような技術では、リクエストを受信するごとにサーバは重要領域の設定、及び再エンコードをする必要があり、対応しきれない。
【０００９】
また、クライアント側で受信できる、あるいは、キャッシュ可能なレスポンスデータサイズに制限がある場合には、クライアントがその制限サイズでデータの受信を打ち切ることが考えられる。特開２０００-５０２６１のように、クライアント側の受信データの制限サイズを考慮せずに、サーバがあらかじめ設定された送信順序でデータを送信すれば、クライアントが受信データをデコードしたときに、要求領域のほんの一部の領域のみが高精細で表示され、残りの部分のデータが全く表示されていないことも考えられる。あるいは、表示領域の中で一部の領域のみが非常に高精細であり、その隣の領域の解像度が極端に落ち、違和感のある表示がなされる可能性もある。
【００１０】
本発明は以上の問題に鑑みて成されたものであり、所望の画像を得るために必要な符号化データのデータサイズの上限値を指定して、この符号化データを得るための技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の目的を達成するために、例えば本発明の画像処理方法は以下の構成を備える。
【００１２】
即ち、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持し、外部装置からの要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置に送信する画像処理装置が行う画像処理方法であって、
所望の画像を得るために必要な符号化データの送信要求を受信する受信工程と、
前記送信要求に応じて前記外部装置に送信すべきタイルの符号化データのデータ量の上限値が、前記外部装置より指定されているか否かを判断する判断工程と、
前記上限値が前記外部装置より指定されている場合、前記外部装置に送信すべき各タイルの符号化データを所望のタイル順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力する出力工程と、
前記出力工程で出力する順に各論理単位のデータ、及び各論理単位のヘッダデータのサイズを計数し、計数結果が前記上限値を超えるまでに前記出力工程で出力した論理単位のデータ群、及び各論理単位のヘッダデータ群を前記外部装置に送信する送信工程と
を備えることを特徴とする。
【００１３】
本発明の目的を達成するために、例えば本発明の画像処理方法は以下の構成を備える。
【００１４】
即ち、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持する外部装置に対する要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置から受信する画像処理装置が行う画像処理方法であって、
所望の画像を得るために必要な符号化データの送信要求を前記外部装置に送信する第１の送信工程と、
前記送信要求に応じて前記外部装置から送信されるタイルの符号化データのデータ量の上限値を指定するデータを前記外部装置に送信する第２の送信工程とを備え、
前記送信要求に応じた符号化データで、且つ前記上限値以下のデータ量である符号化データを受信し、復号し、所定の装置に出力することを特徴とする。
【００１５】
本発明の目的を達成するために、例えば本発明の画像処理装置は以下の構成を備える。
【００１６】
即ち、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持し、外部装置からの要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置に送信する画像処理装置であって、
所望の画像を得るために必要な符号化データの送信要求を受信する受信手段と、
前記送信要求に応じて前記外部装置に送信すべきタイルの符号化データのデータ量の上限値が、前記外部装置より指定されているか否かを判断する判断手段と、
前記上限値が前記外部装置より指定されている場合、前記外部装置に送信すべき各タイルの符号化データを所望のタイル順に参照し、参照するタイルの符号化データを構成する論理単位のデータのうち、前記送信要求に応じた論理単位のデータ、及び当該論理単位のヘッダデータをメモリに出力する出力手段と、
前記出力手段が出力する順に各論理単位のデータ、及び各論理単位のヘッダデータのサイズを計数し、計数結果が前記上限値を超えるまでに前記出力手段が出力した論理単位のデータ群、及び各論理単位のヘッダデータ群を前記外部装置に送信する送信手段と
を備えることを特徴とする。
【００１７】
本発明の目的を達成するために、例えば本発明の画像処理装置は以下の構成を備える。
【００１８】
即ち、複数の論理単位から成るタイル単位で分割された画像の符号化データで、かつ、当該符号化データのフォーマットが論理単位の並べる順番が複数種類可能である画像の符号化データを保持する外部装置に対する要求に応じたタイル中の、当該要求に応じた論理単位のデータを前記外部装置から受信する画像処理装置であって、
所望の画像を得るために必要な符号化データの送信要求を前記外部装置に送信する第１の送信手段と、
前記送信要求に応じて前記外部装置から送信されるタイルの符号化データのデータ量の上限値を指定するデータを前記外部装置に送信する第２の送信手段とを備え、
前記送信要求に応じた符号化データで、且つ前記上限値以下のデータ量である符号化データを受信し、復号し、所定の装置に出力することを特徴とする。
【発明の効果】
【００１９】
本発明の構成により、所望の画像を得るために必要な符号化データのデータサイズの上限値を指定して、この符号化データを要求すると共に、所望のタイル程、より多くの論理単位のデータを得ることができる。
【発明を実施するための最良の形態】
【００２０】
以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
【００２１】
［第１の実施形態］
図１はＰＣ（パーソナルコンピュータ）やワークステーションなどにより構成される、本実施形態に係る画像処理装置の基本構成を示すブロック図である。
【００２２】
ＣＰＵ１０１は一次記憶メモリ１０２にロードされたプログラムやデータを用いて本装置全体の制御を行うと共に後述の各部の動作の制御を行う。
【００２３】
一次記憶メモリ１０２はＲＡＭに代表される主記憶装置であって、二次記憶メモリ１０３からロードされたプログラムやデータを一時的に記憶するエリアを備えると共に、ＣＰＵ１０１が各種の処理を行うために使用するエリアを備える。
【００２４】
二次記憶メモリ１０３は、ハードディスクドライブに代表される大記憶容量を有する情報記憶装置であって、ここにＯＳ（オペレーティングシステム）や後述の各処理をＣＰＵ１０１が実行するためのプログラムやデータを保存させておくことができ、ＣＰＵ１０１による制御によって、要求されたプログラムやデータを一次記憶メモリ１０２に出力（ロード）する。
【００２５】
入力デバイス１０４は、例えばマウスやキーボードなどに代表される指示入力装置であって、この入力デバイス１０４により、本装置のユーザは各種の指示をＣＰＵ１０１に入力することができる。
【００２６】
出力デバイス１０５は、例えばディスプレイやプリンタに代表される装置であって、本装置で処理した画像を表示やプリントアウト等、様々な形態で出力することのできる装置である。
【００２７】
ネットワークインターフェース（Ｉ／Ｆ）１０６は、外部の装置とデータ通信を行うためにＩ／Ｆとして機能するものである。１０７は上記各部を繋ぐバスである。本実施形態に係る画像処理装置の基本構成は以下の説明上図１に示した構成とするが、これ以外の構成を適用することも可能であり、図１に示した構成に限定されるものではない。
【００２８】
図２は、上記画像処理装置を含むシステムの概要を示す図である。２０１，２０２は夫々クライアント端末装置であって、上記画像処理装置としてのサーバ装置２０４とネットワーク２０３を介して各種のデータ通信を行うことができる。
【００２９】
２０３はネットワークで、インターネットやＬＡＮなどの有線のネットワーク、無線のネットワークを含むものである。
【００３０】
２０４はサーバ装置で、上述の通りネットワーク２０３を介してクライアント端末装置２０１，２０２とデータ通信を行うことができ、例えばクライアント端末装置２０１やクライアント端末装置２０２から所望の画像の要求があった場合には、画像の符号化データを大量に保存する記憶装置２０５（上記二次記憶メモリ１０３に相当）から要求された分だけのデータをネットワーク２０３を介して返信するものである。この記憶装置２０５は例えばハードディスクドライブ装置や、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどの記憶媒体からプログラムやデータを読み取る装置がこれに該当する。
【００３１】
本実施形態ではこの記憶装置２０５には、ＪＰＥＧ２０００に従った符号化方式で符号化された画像のデータが複数保存されているものとする。従ってクライアント端末装置２０１，２０２はサーバ装置２０４に、記憶装置２０５が保存している画像の符号化データの中から、所望の符号化データについて、所望の画像を得るために必要な分だけを要求する。
【００３２】
以下では、サーバ装置２０４がクライアント端末装置から要求された画像の符号化データを、このクライアント端末装置に送信する為に行う処理について説明する。クライアント端末装置が記憶装置２０５に保存されている画像をダウンロードするためには、Ｗｅｂブラウザを用いてサーバ装置２０４にアクセスする必要がある。サーバ装置２０４はこのアクセスを受け、記憶装置２０５に保存されている画像の一部もしくは全部の画像を例えばサムネイル形式でクライアント端末装置に提示する。これによりＷｅｂブラウザにはこれらの画像が表示されることになる。
【００３３】
このＷｅｂブラウザに表示された画像群の中から、クライアント端末装置のユーザがマウスやキーボードといった入力デバイスを用いて所望の画像を指示すると、クライアント端末装置は条件（画面サイズや表示形態など）に応じた画像サイズや解像度に従って、所望の画像のデータ中の断片的なデータの送信要求をサーバ装置２０４に対してJPIPの仕組みを使って送信する。
【００３４】
また、このとき本実施形態では、クライアント端末装置は、現在の自身のメモリの空き容量や、ネットワーク１０３の回線容量などに応じて、要求するデータのサイズを所定値（上限値）以下に納めるように要求することができる。即ち、クライアント端末装置は、サーバ装置２０４に、所望の画像を得るためのデータを要求すると共に、サーバ装置２０４が送信するデータのサイズを所定量以下にするよう要求することができる。
【００３５】
この上限値の指定方法は特に限定するものではないが、例えばクライアント端末装置側でキーボードやマウスを用いて指定しても良いし、様々なデータ転送速度に応じた上限値が登録されているテーブルの中から、クライアント端末装置が現在使用するモデムなどの性能に応じた上限値を特定し、これを用いるようにしてもよい。
【００３６】
そしてサーバ装置２０４はこの要求に応じた断片的なデータをクライアント端末装置に送信するので、クライアント端末装置はこれを受信し、バッファにキャッシュする。
【００３７】
そして受信した画像を表示する際には、キャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、その後、そのビットストリームをデコードして表示する。デコードした画像の出力形態はこれ以外にも、例えば、不図示のプリンタや複写機などに出力してプリントアウトしたりすることもできる。
【００３８】
次に、一般的なＪＰＥＧ２０００に従ったビットストリームについて説明する。図３はＬａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ  ｐｒｏｇｒｅｓｓｉｏｎ（以下、ＬＲＣＰと記す）に従ったＪＰＥＧ２０００のビットストリームの構成を示す図である。ＪＰＥＧ２０００のビットストリームにはメインヘッダ（Ｍａｉｎ  Ｈｅａｄｅｒ）、タイルヘッダ（Ｔｉｌｅ  Ｈｅａｄｅｒ）、データ（Ｄａｔａ）が含まれており、このデータの部分に画像符号化データが記録されることになる。またタイルヘッダは、圧縮符号化元の画像を所定のサイズの矩形（タイル）毎に分割し、夫々のタイルの圧縮符号化データを生成した場合に、夫々のタイルの圧縮符号化データに対して作成されるものである。メインヘッダ、タイルヘッダについては公知の技術によるものであるのでここでの説明は省略する。
【００３９】
ＬＲＣＰに準じた場合、画像の符号化データ（同図において”Ｄａｔａ”で示された部分）は、Ｌａｙｅｒ／Ｒｅｓｏｌｕｔｉｏｎ／Ｃｏｍｐｏｎｅｎｔ／Ｐｏｓｉｔｉｏｎの順にデータが配置された構成を備える。このような構成はｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒ（プログレッションオーダ）と呼ばれる。また、ここで記されているｐｏｓｉｔｉｏｎとは、ＪＰＥＧ２０００符号化データにおけるｐｒｅｃｉｎｃｔのことである。
【００４０】
ＪＰＥＧ２０００の符号化データは大まかにはLayer毎のデータに分けることができる。各Layerのデータは公知のビットプレーン符号化による各ビットプレーンの符号化データで、ＭＳＢ側のビットプレーン（Ｌａｙｅｒ０）から順にＬＳＢのビットプレーン（ＬａｙｅｒＬ）までが配置される。Layer番号は復元する画像の原画に対するＳ／Ｎ比に対応し、Layer番号が小さいほどＳ／Ｎ比が悪く（低く）なる。すなわち、同図のＪＰＥＧ２０００のデータは、Ｓ／Ｎの悪い順に各Ｌａｙｅｒのデータが配置されていることになる。
【００４１】
更に各Ｌａｙｅｒのデータは各Ｒｅｓｏｌｕｔｉｏｎのデータにより構成されている。各Ｒｅｓｏｌｕｔｉｏｎのデータは解像度（画像のサイズ）に応じたＲｅｓｏｌｕｔｉｏｎ番号に従った順序で配置されている。解像度とＲｅｓｏｌｕｔｉｏｎ番号との関係を図４に示す。最も小さい解像度の画像のＲｅｓｏｌｕｔｉｏｎ番号を０とし、Ｒｅｓｏｌｕｔｉｏｎ番号が一つ増加するごとに画像の幅と高さが倍になっていく。各Ｌａｙｅｒ内は、Ｒｅｓｏｌｕｔｉｏｎ番号の小さい順にデータが格納されている。
【００４２】
図３に戻って、各Ｒｅｓｏｌｕｔｉｏｎのデータは各Ｃｏｍｐｏｎｅｎｔのデータにより構成されている。各Ｃｏｍｐｏｎｅｎｔのデータは画像の各色データに対応しており、例えば画像がＲＧＢの各データにより構成されている場合には、Ｃｏｍｐｏｎｅｎｔ０のデータはＲ成分のデータ、Ｃｏｍｐｏｎｅｎｔ１のデータはＧ成分のデータ、Ｃｏｍｐｏｎｅｎｔ２のデータはＢ成分のデータである、すなわち、Ｃｏｍｐｏｎｅｎｔ数は画像の色空間の次元数に一致する。
【００４３】
また各Ｃｏｍｐｏｎｅｎｔデータには圧縮符号化元の画像における空間的な各位置のデータ（Ｐｏｓｉｔｉｏｎデータ）が順番に記録されており、各Ｐｏｓｉｔｉｏｎデータには、空間的な順番通りに番号（ポジション番号）が付けられている（例えば画像の左上隅を０として画像の右方向に１つずつ番号が増加し、右端に達したら１つ下、且つ左端からまた画像右方向に番号が増加する）。
【００４４】
一つのＪＰＥＧ２０００ファイル内でのＲｅｓｏｌｕｔｉｏｎ番号とレイヤ番号、コンポーネント番号、ｐｏｓｉｔｉｏｎ番号の最大値は、エンコーダによって予め設定されており、圧縮符号化元の画像はそのパラメータに従ってエンコードされており、その情報はメインヘッダに記録されている。また各パケット（ｐａｃｋｅｔ）は、そのパケットに格納されているコードブロック（ｃｏｄｅ−ｂｌｏｃｋ）の情報を管理しているパケットヘッダ（ｐａｃｋｅｔ  ｈｅａｄｅｒ）部と、各コードブロックの符号化データから構成されている。同図では１つのＰｏｓｉｔｉｏｎデータがパケットに相当する。この「パケット」なるものは、論理単位の一種である。
【００４５】
このような構造を有するＪＰＥＧ２０００ファイルがサーバ装置に保持されていれば、サーバ装置は、クライアント端末装置が要求する解像度等に応じた符号化データのみをこのクライアント端末装置に供給することができる。本実施形態の場合には、JPIPによってデータの送受信を行うため、供給するデータの単位としては、ＪＰＥＧ２０００のタイル単位、或いはＪＰＥＧ２０００のパケット（ｐａｃｋｅｔ）単位が考えられる。本実施形態では、クライアント端末装置がサーバ装置から受信するデータ単位としてパケット単位を想定する。
【００４６】
このパケット単位でのリクエスト及びレスポンスの概念図を図５に示す。同図ではサーバ装置５０３、クライアント端末装置５０１間のリクエスト、レスポンスについて示している。
【００４７】
同図は、画像がタイル分割されており、各タイルの符号化データ（同図ではTile０〜TileＮまでの各データ）がＪＰＥＧ２０００ビットストリーム５０４としてサーバ装置５０３に接続されている記憶装置５０２に格納されている状態で、クライアント端末装置５０１から所望のタイル、所望の解像度、所望のレイヤ、所望のコンポーネント、そして所望の空間的な位置の符号化データを要求する場合に、サーバ装置５０３とクライアント端末装置５０１との間で行われる通信を示すものである。
【００４８】
ここで例えばクライアント端末装置５０１がタイル番号は「１」、解像度番号は「０」、レイヤ番号は「０」、コンポーネント番号は「０」、そしてポジション番号は「０」である符号化データをサーバ装置５０３に要求した場合、サーバ装置５０３は記憶装置５０２に保存しているＪＰＥＧ２０００ビットストリーム５０４を解析して、要求に相当する部分（要求されたタイル番号、解像度番号、レイヤ番号、コンポーネント番号、ポジション番号に相当する部分）、すなわち、タイル番号１のパケット０をレスポンスデータとして抜き出し、クライアント端末装置５０１に返信する。
【００４９】
このように本実施形態ではサーバ装置とクライアント端末装置との間の画像データの送受信にはＪＰＩＰを用い、パケット単位で画像の符号化データをサーバ装置からクライアント端末装置に送信する。
【００５０】
次に、JPIPを使ってデータを送受信する場合の、レスポンスデータの構成について説明する。図６（ａ）はprecinct data−binと呼ばれるJPEG2000のpacketデータの塊の構成を示す図である。JPIPでは６０１に示すように、precinct data−binと呼ばれるＪＰＥＧ２０００のpacketデータの塊を基本としてレスポンスデータを作成する。precinct data−binとは、Tile tnの中のprecinct pnのresolution level rn、 component番号cnを構成する全てのlayerのpacketを、layer番号が昇順になるように並べてつなげたデータの塊である。
【００５１】
このｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎを使って、ＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａが作成される。図６（ｂ）は図６（ａ）に示すｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎを用いて作成されたＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａの構成を示す図である。ＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａは、ｍｅｓｓａｇｅ  ｈｅａｄｅｒ６０８とｍｅｓｓａｇｅ  ｂｏｄｙ６０９から構成される。ｍｅｓｓａｇｅ  ｂｏｄｙ６０９には、要求されたタイル、解像度に応じてｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ６０１から切り出された１つもしくは複数パケット（図６（ａ）に示すＰａｃｋｅｔ（ｔｎ，ｒｎ，ｃｎ，ｐｎ，ｑ））のデータがレスポンスデータとして入る。
【００５２】
ｍｅｓｓａｇｅ  ｈｅａｄｅｒ６０８は、６つのパラメータを格納する領域から構成されている。最初の領域６０５に格納されるパラメータは、ｍｅｓｓａｇｅ  ｂｏｄｙ６０９内のパケットのデータが属していたｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ（ここでは図６（ａ）に示すｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ）に対するｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ  ＩＤ（ＰｒＩＤ）である。２番目の領域６０４に格納されるパラメータは、ｍｅｓｓａｇｅ  ｂｏｄｙ６０９に入っているデータがｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎであることを示す識別子である。このＰｒＩＤは、タイル番号ｔｎ，ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ番号ｒｎ，ｃｏｍｐｏｎｅｎｔ番号ｃｎ，ｐｒｅｃｉｎｃｔ番号ｐｎから一意に決まり、次式で求めることができる。
【００５３】
ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）＝ｔｎ＋（ｃｎ＋ｓ×（ｃｏｍｐｏｎｅｎｔ数））×ｔｉｌｅ数
ただし、
ｓ＝ｐｎ＋ｔｎ×（ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ｒｎにおける１タイルあたりのｐｒｅｃｉｎｃｔ数）＋（ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０から（ｒｎ−１）までのタイルｔｎのｐｒｅｃｉｎｃｔ数の総和）
３番目の領域６１０に格納されるパラメータは、ｍｅｓｓａｇｅ  ｂｏｄｙ６０９に含まれるデータがどのコードストリームから抜き出されたものかを示すコードストリーム番号である。
【００５４】
４番目の領域６０６に格納されるパラメータは、ｍｅｓｓａｇｅ  ｂｏｄｙ６０９中の各パケットのデータ（１つの場合はそれ自身のデータ）がｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎの先頭からどれだけオフセットされた位置にあったものかを示すオフセット値ＰｒＯｆｆｓｅｔ（図６（ａ）を参照）である。
【００５５】
５番目の領域６０７に格納されるパラメータは、ｒｅｓｐｏｎｓｅ  ｄａｔａ、つまり、ｍｅｓｓａｇｅ  ｂｏｄｙ６０９のバイト長ＲｅｓＬｅｎ［ｂｙｔｅ］（図６（ｂ）を参照）である。
【００５６】
６番目の領域６１１に格納されるパラメータは、ｍｅｓｓａｇｅ  ｂｏｄｙ６０９のデータの補助情報である。領域６０４、６１０、６１１は省略可能なパラメータである。
【００５７】
次に、本実施形態に係る画像処理装置がサーバ装置として、送信要求のあった装置（以下、クライアント端末装置）に対してこのようなＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａ（以下、単にレスポンスデータと呼称する場合がある）を作成し、送信する処理について説明する。なお、以下、本実施形態に係る画像処理装置をその機能上、サーバ装置と呼称する。
【００５８】
なお、本実施形態では、サーバ装置２０４が管理する（記憶装置２０５に保存している）画像のエンコード条件は以下の通りとする。
【００５９】
ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ数：３（ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ０〜２）
ｌａｙｅｒ数：５（ｌａｙｅｒ０〜４）
ｃｏｍｐｏｎｅｎｔ  数：３（ｃｏｍｐｏｎｅｎｔ０〜２）
ｔｉｌｅ数：６×６＝３６（ｔｉｌｅ０〜３５）
ｐｏｓｉｔｉｏｎ数：１  ｐｏｓｉｔｉｏｎ／１  ｔｉｌｅ
ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ２における画像サイズ：７６８×７６８［ｐｉｘｅｌ］
ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ２におけるタイルサイズ：１２８×１２８［ｐｉｘｅｌ］
従って、サーバ装置２０４は、以上のエンコード条件でもって符号化したことで得られる画像の符号化データを二次記憶メモリ１０３に保持しており、必要に応じて一次記憶メモリ１０２に読み出す。なお、このようなエンコード条件を示す情報は周知の通り、ヘッダ情報として符号化データに付加されているものであり、このヘッダ情報を参照することで、この符号化データの上記エンコード条件は得られるものである。
【００６０】
図７は、サーバ装置２０４が保持する符号化データが表す画像においてタイルと解像度の関係を示す図である。なお、本実施形態では、１タイルにつき１ｐｏｓｉｔｉｏｎであるので、ｐｏｓｉｔｉｏｎの表記は、図７では省略する。
【００６１】
上述の通り、サーバ装置２０４は１つの画像につき、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ０から２までの各ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌの符号化データを保持している。また、各ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌにおける画像は複数のタイルに分割されている（同図では３６個のタイル）。同図では各タイルには番号が付いているが、これは各タイルに対して固有に付いているインデックスである。
【００６２】
ここで、クライアント端末装置側では以下の説明上、図７に示したｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ毎の画像の符号化データをひとまとめにした符号化データのうち、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ０，ｌａｙｅｒ４で全てのコンポーネントによる色でもって画像全体を表示するために必要な分だけをサーバ装置２０４からダウンロードし、自身のメモリにキャッシュしているとする。
【００６３】
そして次に、クライアント端末装置から、画像の左上の領域をｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ  ４で全てのコンポーネントによる色でもって表示するための符号化データの送信要求をサーバ装置２０４に送信したとする。本実施形態ではクライアント端末装置は更にこの送信要求と共に、レスポンスデータ（この送信要求に応じてサーバ装置２０４が返信すべきデータ）であるＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａの総データサイズ、つまり、ｍｅｓｓａｇｅ  ｈｅａｄｅｒ６０８とｍｅｓｓａｇｅ  ｂｏｄｙ６０９を合わせたデータサイズ、の上限値が３６０ｋ［ｂｙｔｅ］となるように、レスポンスデータを送信するよう、サーバ装置２０４に指示するためのデータもサーバ装置２０４に送信することができる。
【００６４】
つまり、図７の領域７０１および、領域７０２のデータの中から、レスポンスデータが３６０ｋ［ｂｙｔｅ］以内に納めたデータを要求したものとする。本実施形態では、上記送信要求、及びレスポンスデータのデータサイズの上限値の指定を以下に示す文字列の送信でもって行う。
【００６５】
ＧＥＴ  ｔａｒｇｅｔ＝ｉｍａｇｅ．ｊｐ２＆ｆｓｉｚ＝７６８，７６８＆ｒｏｆｆ＝０，０＆ｒｓｉｚ＝５１２，３８４＆ｔｙｐｅ＝ｊｐｐ−ｓｔｒｅａｍ＆ａｌｉｇｎ＝ｙｅｓ＆ｌｅｎ＝３６００００＆ｎｅｅｄ＝ｒ１，ｒ２
この文字列において、“ｉｍａｇｅ．ｊｐ２”の部分はクライアント端末装置がサーバ装置２０４に送信要求する画像の符号化データの名前（ファイル名）を表し、“ｆｓｉｚ＝７６８，７６８”の部分はサーバ装置２０４に送信要求する符号化データのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌの上限値が２の符号化データ（図７を参照）であることを表す。即ち、送信要求する符号化データのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌは０〜２までのものである。
【００６６】
“ｒｏｆｆ＝０，０＆ｒｓｉｚ＝５１２，３８４”の部分はサーバ装置２０４に送信要求する符号化データが、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ２の符号化データのうち、左上隅の座標値が（０，０）で、サイズが５１２×３８４である領域（図７では領域７０１）の符号化データであることを表す。上述の通り、送信要求する符号化データのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌは０〜２までのものであるので、他のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌについても、領域７０１に位置的に対応する領域（例えばｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ１の場合は領域７０２）も送信要求の対象となる。
【００６７】
“ｔｙｐｅ＝ｊｐｐ−ｓｔｒｅａｍ＆ａｌｉｇｎ＝ｙｅｓ”の部分はｐａｃｋｅｔを単位としたレスポンスデータの要求を表し、“ｌｅｎ＝３６００００”の部分はレスポンスデータのデータサイズの上限値を３６０ｋ［Ｂｙｔｅ］に指定することを表す。
【００６８】
また、“ｎｅｅｄ＝ｒ１，ｒ２”の部分は、取得済みのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０以外のデータを要求することを表している。
【００６９】
以上の文字列をリクエストデータとしてサーバ装置２０４に送信することで、サーバ装置２０４はこのリクエストデータを解釈し、指定されたバイト数以下で、要求された符号化データをクライアント端末装置に返信する処理を行う。
【００７０】
以下では、このリクエストデータを受信したサーバ装置２０４が行う処理についてより詳細に説明する。
【００７１】
図８は、サーバ装置２０４がクライアント端末装置から以上のようなリクエストデータを受信した場合に行うメインの処理のフローチャートである。なお、同図のフローチャートに示したプログラムは二次記憶メモリ１０３に保存されており、一次記憶メモリ１０２にロードされ、ＣＰＵ１０１がこれを実行することにより、サーバ装置２０４は、以下説明する各処理を実現することになる。
【００７２】
まずステップＳ８０１で、サーバ装置２０４はクライアント端末装置から送信されたリクエストデータを受信する。受信したリクエストデータは一次記憶メモリ１０２に一時的に記憶する。
【００７３】
ステップＳ８０２では、ステップＳ８０１で受信したリクエストデータを解析し、要求されているｌａｙｅｒ，ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ，ｃｏｍｐｏｎｅｎｔ，ｐｏｓｉｔｉｏｎおよびｔｉｌｅの範囲を特定する。ｌａｙｅｒ，ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ，ｃｏｍｐｏｎｅｎｔ，ｐｏｓｉｔｉｏｎの要求範囲の最小値・最大値を、それぞれ、Ｌｙ＿ｌｏｗ，Ｌｙ＿ｕｐ，Ｒｓ＿ｌｏｗ，Ｒｓ＿ｕｐ，Ｃｐ＿ｌｏｗ，Ｃｐ＿ｕｐ，Ｐｓ＿ｌｏｗ，Ｐｓ＿ｕｐとし、要求された範囲に含まれるタイル数をＮとすると、夫々の変数が表す値は本実施形態では以下のようになる。
【００７４】
Ｌｙ＿ｌｏｗ＝０，Ｌｙ＿ｕｐ＝４
Ｒｓ＿ｌｏｗ＝０，Ｒｓ＿ｕｐ＝２
Ｃｐ＿ｌｏｗ＝０，Ｃｐ＿ｕｐ＝２
Ｐｓ＿ｌｏｗ＝０，Ｐｓ＿ｕｐ＝０
Ｎ＝１２
即ち、上述の通り、クライアント端末装置がサーバ装置２０４に対してｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ  ４で全てのコンポーネントによる色でもって表示するための符号化データを要求するのであるから、送信要求すべきｌａｙｅｒの範囲はｌａｙｅｒ０〜４、送信要求すべきｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌの範囲はｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ０〜２、送信要求すべきｃｏｍｐｏｎｅｎｔの範囲はｃｏｍｐｏｎｅｎｔ０〜２、送信要求すべきｐｏｓｉｔｉｏｎの範囲はｐｏｓｉｔｉｏｎ０のみとなる。
【００７５】
また、タイル数Ｎの特定については、リクエストデータの“ｒｏｆｆ＝ｘ１，ｙ１＆ｒｓｉｚ＝ｘ２，ｙ２”の記述を参照し、左上隅の座標値が（ｘ１，ｙ１）で、右下隅の座標値が（ｘ１＋ｘ２，ｙ１＋ｙ２）の領域を包含する最小の「タイル単位の領域」を特定し、そして特定した領域内のタイルの数をカウントすることにより求めることができる。本実施形態の場合、この包含する最小のタイル単位の領域は即ち領域７０１であるので、換言すれば、本実施形態では図７に示す画像のうち、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌが２の画像の符号化データのうち、領域７０１の部分に該当する符号化データを要求したのであるから、インデックスが０，１，２，３，６，７，８，９，１２，１３，１４，１５のタイルの符号化データ、即ち１２個のタイルのデータを要求したことになる。従って上記変数Ｎ＝１２となる。
【００７６】
尚、ステップＳ８０２における処理を含め、以降説明する各処理においても、求めた結果を示すデータは一時的に一次記憶メモリ１０２に一時的に記憶されており、後続の処理の為に用いることができる。
【００７７】
更に、要求しているタイルの各インデックスを昇順に一次元配列Ｐｔに保持する。配列Ｐｔは以下のようになる。
【００７８】
Ｐｔ［０］＝０，Ｐｔ［１］＝１，Ｐｔ［２］＝２，Ｐｔ［３］＝３
Ｐｔ［４］＝６，Ｐｔ［５］＝７，Ｐｔ［６］＝８，Ｐｔ［７］＝９
Ｐｔ［８］＝１２，Ｐｔ［９］＝１３，Ｐｔ［１０］＝１４，Ｐｔ［１１］＝１５
次に、ステップＳ８０３では、レスポンスデータにサイズ制限があるかどうかを判定する。本実施形態では、リクエストデータ中のテキストを解析し、”ｌｅｎ＝”の記述があるか否かをチェックし、ある場合には、レスポンスデータにサイズ制限があると判定する。そして解析の結果、”ｌｅｎ＝”の記述が無い場合には、処理をステップＳ８０４に進める。ステップＳ８０４では、クライアント端末装置がサーバ装置２０４に要求する全てのデータ、即ち、“ｉｍａｇｅ．ｊｐ２”で特定される符号化データで、且つインデックスが０，１，２，３，６，７，８，９，１２，１３，１４，１５のタイルの符号化データのうち、ｌａｙｅｒが０〜４，ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌが１〜２，ｃｏｍｐｏｎｅｎｔが０〜２，ｐｏｓｉｔｉｏｎが０に該当する部分の符号化データを一次記憶メモリ１０２中に設けられている送信バッファにレスポンスデータとして書き込む。なお、ステップＳ８０４における処理の詳細については図９を用いて後述する。
【００７９】
一方、”ｌｅｎ＝”の記述がある場合には、処理をステップＳ８０５に進める。本実施形態の場合、”ｌｅｎ＝３６００００”の記述があるので、サイズ制限があると判定する。
【００８０】
ステップＳ８０５では、リクエストデータから、レスポンスのデータサイズの上限値（ｂｙｔｅ＿ｌｉｍｉｔ）を取得する。本実施形態の場合には”ｌｅｎ＝３６００００”という記述から、ｂｙｔｅ＿ｌｉｍｉｔ＝３６０ｋ［Ｂｙｔｅ］となる。
【００８１】
ステップＳ８０６では、クライアント端末装置がサーバ装置２０４に要求する全てのデータのうち、ステップＳ８０５で取得したｂｙｔｅ＿ｌｉｍｉｔ［Ｂｙｔｅ］以下のデータをレスポンスデータとして送信バッファへ書き込む処理を行う。なお、ステップＳ８０６における処理の詳細については図１０を用いて後述する。
【００８２】
ステップＳ８０７では、送信バッファに書き出されたレスポンスデータをクライアント端末装置に送信する処理を行う。
【００８３】
次に、上記ステップＳ８０４における処理の詳細、即ち、レスポンスデータにサイズ制限が指定されていない場合に、サーバ装置２０４が行う処理について、同処理のフローチャートである図９を参照して説明する。
【００８４】
ステップＳ９０１において、レスポンスデータ作成の際に利用するｌａｙｅｒ用のカウンタ変数ＬｙにステップＳ８０２で取得した返送データの最小ｌａｙｅｒ番号Ｌｙ＿ｌｏｗを代入する。
【００８５】
ステップＳ９０２では、レスポンスデータ作成の際に利用するｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ用のカウンタ変数ＲｓにステップＳ８０２で取得した返送データの最小ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ番号Ｒｓ＿ｌｏｗを代入する。
【００８６】
ステップＳ９０３では、レスポンスデータ作成の際に利用するｃｏｍｐｏｎｅｎｔ番号用のカウンタ変数Ｃｐに、ステップＳ８０２で取得した返送データの最小ｃｏｍｐｏｎｅｎｔ番号Ｃｐ＿ｌｏｗを代入する。
【００８７】
ステップＳ９０４では、レスポンスデータ作成の際に利用するｐｏｓｉｔｉｏｎ用のカウンタ変数ＰｓにステップＳ８０２で取得した返送データの最小ｐｏｓｉｔｉｏｎ番号Ｐｓ＿ｌｏｗを代入する。
【００８８】
ステップＳ９０５では、レスポンスデータ作成の際に利用する返送タイルのインデックスを格納した配列の番号用のカウンタ変数ｎに０を代入し、初期化する。
【００８９】
ステップＳ９０６では、タイルＰｔ［ｎ］のｌａｙｅｒ番号Ｌｙ、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ番号Ｒｓ、ｃｏｍｐｏｎｅｎｔ番号Ｃｐ、ｐｏｓｉｔｉｏｎ番号Ｐｓで特定されるパケットデータＰａｃｋｅｔ（Ｐｔ［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）が返送すべきデータであるか判定する。
【００９０】
そして、返送すべきデータであれば処理をステップＳ９０８に進め、返送データでなければ処理をステップＳ９０９に進める。本実施形態の場合、最初にステップＳ９０６における処理を実行する場合には、Ｐａｃｋｅｔ（Ｐｔ［０］＝０，Ｌｙ＝０，Ｒｓ＝０，Ｃｐ＝０，Ｐｓ＝０）が判定の対象となるが、リクエストデータには“ｎｅｅｄ＝ｒ１，ｒ２”なる記述が含まれており、この記述は上述の通り、既に取得済みのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０以外のデータを要求しているため、Ｐａｃｋｅｔ（Ｐｔ［０］＝０，Ｌｙ＝０，Ｒｓ＝０，Ｃｐ＝０，Ｐｓ＝０）は返送データではないと判断され、処理はステップＳ９０９へ進む。
【００９１】
また、カウンタが進んでＰａｃｋｅｔ（Ｐｔ［０］＝０，Ｌｙ＝０，Ｒｓ＝１，Ｃｐ＝０，Ｐｓ＝０）となった場合、“ｎｅｅｄ＝ｒ１，ｒ２”の記述により、このパケットは、まだクライアント端末装置が取得していないものであって、要求しているデータであると解釈されるので、ステップＳ９０６ではこのパケットは返送データと判断され、処理をステップＳ９０８に進める。
【００９２】
ステップＳ９０８では、ｐａｃｋｅｔ（Ｐｔ［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）のデータを送信バッファに読み出し、図６（ｂ）に示すようなJPIP response dataを作成する。
【００９３】
ステップＳ９０９では、配列Ｐｔのカウンタ変数であるｎの値を１つインクリメントする。そしてインクリメントした変数ｎの値と返送タイル数Ｎから１をひいた値（Ｎ-１）と比較し、（Ｎ−１）より大きければ、処理をステップＳ９１０へ進め、（Ｎ−１）以下である場合には、処理をステップＳ９０６に進める。
【００９４】
ステップＳ９１０では、Ｐｏｓｉｔｉｏｎ用のカウンタ変数Ｐｓの値を１つインクリメントし、ステップＳ８０２で取得したｐｏｓｉｔｉｏｎの最大番号Ｐｓ＿ｕｐと比較する。もし、インクリメントした結果、Ｐｓの値がＰｓ＿ｕｐよりも大きい値になった場合には処理をステップＳ９１１に進め、Ｐｓ＿ｕｐ以下の値であれば、処理をステップＳ９０５に戻す。
【００９５】
本実施形態ではＰｓ＿ｕｐ＝０であるので、ステップＳ９１０でＰｓがインクリメントされれば必ずＰｓ＿ｕｐを越えた値になるため、必ずステップＳ９１１へ進むことになる。
【００９６】
ステップＳ９１１では、ｃｏｍｐｏｎｅｎｔ用のカウンタ変数Ｃｐを一つインクリメントし、ステップＳ８０２で取得した返送ｃｏｍｐｏｎｅｎｔ番号の最大値Ｃｐ＿ｕｐと比較する。比較した結果、ＣｐがＣｐ＿ｕｐ以下の値なら処理をステップＳ９０４に戻し、Ｃｐ＿ｕｐより大きい値なら処理をステップＳ９１２に進める。
【００９７】
ステップＳ９１２では、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ用のカウンタＲｓを１つインクリメントし、ステップＳ８０２で取得した返送ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ番号の最大値Ｒｓ＿ｕｐと比較する。比較した結果、ＲｓがＲｓ＿ｕｐ以下の値であれば処理をステップＳ９０３に戻し、Ｒｓ＿ｕｐより大きい値なら処理をステップＳ９１３に進める。
【００９８】
ステップＳ９１３では、ｌａｙｅｒ用のカウンタ変数Ｌｙを１つインクリメントし、ステップＳ８０２で取得した返送ｌａｙｅｒ番号の最大値Ｌｙ＿ｕｐと比較する。比較した結果ＬｙがＬｙ＿ｕｐ以下の値であれば処理をステップＳ９０２に戻し、ＬｙがＬｙ＿ｕｐより大きい値であれば、クライアント端末装置から要求された符号化データが全て送信バッファに読み出されたものと判断し、本処理を終了し、処理をステップＳ８０７に進める。
【００９９】
次に、上記ステップＳ８０６における処理の詳細、即ち、レスポンスデータにサイズ制限が指定されている場合に、サーバ装置２０４が行う処理について、同処理のフローチャートである図１０を参照して説明する。尚、同図に示した各ステップにおいて、図９に示したステップと同じステップには同じステップ番号を付けており、その説明は省略する。
【０１００】
先ずステップＳ１００１では、配列Ｐｔが保持する「クライアント端末装置に送信する符号化データが属する各タイルのインデックス」を優先度の高い順に並べなおし、配列Ｐｔ’に格納する処理を行う。このステップＳ１００１における処理の詳細については後述する。
【０１０１】
次にステップＳ１００２では、レスポンスデータとして送信バッファに格納されたデータサイズをカウントするための変数ｌｅｎｇｔｈに０を代入して初期化し、上述したステップＳ９０１からステップＳ９０５までの各処理を行う。
【０１０２】
ステップＳ９０１からステップＳ９０５までの各処理が完了すると、処理をステップＳ１００３に進め、ステップＳ１００３では、タイルインデックスがＰｔ’［ｎ］のｌａｙｅｒ番号Ｌｙ、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ番号Ｒｓ、ｃｏｍｐｏｎｅｎｔ番号Ｃｐ、ｐｏｓｉｔｉｏｎ番号ＰｓのパケットデータであるＰａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）が返送すべきデータであるかを判定する。
【０１０３】
そして、返送すべきデータであれば処理をステップＳ１００４に進め、返送データでなければ処理をステップＳ９０９に進める。本実施形態の場合、最初にステップＳ１００３における処理を実行する場合には、Ｐａｃｋｅｔ（Ｐｔ’［０］＝０，Ｌｙ＝０，Ｒｓ＝０，Ｃｐ＝０，Ｐｓ＝０）が判定の対象となるが、リクエストデータには“ｎｅｅｄ＝ｒ１，ｒ２”なる記述が含まれており、この記述は上述の通り、既に取得済みのｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０以外のデータを要求しているため、Ｐａｃｋｅｔ（Ｐｔ’［０］＝０，Ｌｙ＝０，Ｒｓ＝０，Ｃｐ＝０，Ｐｓ＝０）は返送データではないと判断され、処理はステップＳ９０９へ進む。
【０１０４】
また、カウンタが進んでＰａｃｋｅｔ（Ｐｔ’［０］＝０，Ｌｙ＝０，Ｒｓ＝１，ＣＰｐ＝０，Ｐｓ＝０）となった場合、“ｎｅｅｄ＝ｒ１，ｒ２”の記述により、このパケットは、まだクライアント端末装置が取得していないものであって、要求しているデータであると解釈されるので、ステップＳ１００３ではこのパケットは返送データと判断され、処理をステップＳ１００４に進める。
【０１０５】
ステップＳ１００４では、Ｐａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）のデータ長Ｐｌｅｎを取得する。Ｐｌｅｎの取得方法については、各ｐａｃｋｅｔのデータ長Ｐｌｅｎが記述されたファイルから読み込んでも良いし、あるいは、メタデータとして各ｐａｃｋｅｔのデータ長Ｐｌｅｎを記述した部分から読み込んでも良いし、あるいは、実際にｐａｃｋｅｔヘッダを解析しｐａｃｋｅｔのデータ長Ｐｌｅｎを求めても良い。
【０１０６】
次にステップＳ１００５では、Ｐａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）のｍｅｓｓａｇｅ  ｈｅａｄｅｒ６０８の長さＭｓｇＨｌｅｎを取得する。ＭｓｇＨｌｅｎは、ｍｅｓｓａｇｅ  ｈｅａｄｅｒ６０８に含まれる３つの要素、
Ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎであることを示す識別子、
コードストリーム番号、
補助情報
のそれぞれについて、レスポンスデータに含めるか否かを決定し、実際に、含める要素と、同様にｍｅｓｓａｇｅ  ｈｅａｄｅｒ６０８に含まれる下記の３つの要素
ＰｒＩＤ（Ｐｔ’［ｎ］，Ｒｓ，Ｃｐ，Ｐｓ）、
ＰｒＯｆｆｓｅｔ、
ＲｅｓＬｅｎのデータ長
を計算により求め、足し合わせることで容易に取得できる。
【０１０７】
ステップＳ１００６では、ステップＳ１００４で取得したデータ長ＰｌｅｎとステップＳ１００５で取得したｍｅｓｓａｇｅ  ｈｅａｄｅｒ長ＭｓｇＨｌｅｎを足し合わせた値と、ステップＳ８０５で取得したレスポンスのデータサイズの上限値ｂｙｔｅ＿ｌｉｍｉｔから既に送信バッファに書き込んだデータサイズｌｅｎｇｔｈを引いた値とを比較する。つまり、Ｐａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）をＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａとして、送信バッファに書き込んだ結果、送信バッファが保持するデータ長が上限値であるｂｙｔｅ＿ｌｉｍｉｔを越えないか否かを判定する。
【０１０８】
（Ｐｌｅｎ＋ＭｓｇＨｌｅｎ）が（ｂｙｔｅ＿ｌｉｍｉｔ−ｌｅｎｇｔｈ）以下であれば、Ｐａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）から作られるＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａを送信バッファに書き込んでも上限値ｂｙｔｅ＿ｌｉｍｉｔを越えないと判断し、処理をステップＳ１００７に進め、（Ｐｌｅｎ＋ＭｓｇＨｌｅｎ）が（ｂｙｔｅ＿ｌｉｍｉｔ−ｌｅｎｇｔｈ）より大きければ、Ｐａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）から作られるＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａを送信バッファに書き込むと上限値ｂｙｔｅ＿ｌｉｍｉｔを越えると判断し、本処理を終了して、処理をステップＳ８０７に進める。
【０１０９】
ステップＳ１００７では、ｐａｃｋｅｔ（Ｐｔ’［ｎ］，Ｌｙ，Ｒｓ，Ｃｐ，Ｐｓ）のデータを送信バッファに読み出し、図６（ｂ）に示すようなJPIP response dataを作成する。
【０１１０】
そしてステップＳ１００８では、送信バッファに格納されたレスポンスデータのデータサイズをカウントする変数ｌｅｎｇｔｈに、ステップＳ１００７で送信バッファに書き込んだＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａのバイト数、即ち（Ｐｌｅｎ＋ＭｓｇＨｌｅｎ）を足し、処理をステップＳ９０９に進め、以降、上述したステップＳ９０９からステップＳ９１３までの処理を行う。
【０１１１】
以上説明した処理によって、サーバ装置２０４は、ステップＳ８０４、及びステップＳ８０６で、ｌａｙｅｒ方向（画質方向）のスケーラビリティでデータを返送していることになる。
【０１１２】
次に、ステップＳ１００１における処理の詳細、即ち、配列Ｐｔが保持する「クライアント端末装置に送信する符号化データが属する各タイルのインデックス」を優先度の高い順に並べなおし、配列Ｐｔ’に格納する処理の詳細について、同処理のフローチャートである図１１を参照して説明する。
【０１１３】
まずステップＳ１１０１では、画像の符号化データに含まれるヘッダを参照し、そこに書き込まれている各情報を参照して「画像の水平方向のタイル数Ｔｗｉｄｔｈ」を取得する。本実施形態では、サーバ装置２０４が管理する（記憶装置２０５に保存している）画像の符号化データのエンコード条件が
ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２における画像サイズ：７６８画素×７６８画素
ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２におけるタイルサイズ：１２８画素×１２８画素
であるので、ヘッダ情報を参照することで、このエンコード条件情報を得、その結果、Ｔｗｉｄｔｈ＝７６８／１２８＝６と計算することで、「画像の水平方向のタイル数Ｔｗｉｄｔｈ」を取得することができる。
【０１１４】
次にステップＳ１１０２では、クライアント端末装置からのリクエスト領域内の水平方向のタイル数Ｔｘ、及び垂直方向のタイル数Ｔｙを求める。これらの値は、ＪＰＥＧ２０００のｍａｉｎ  ｈｅａｄｅｒから得られるタイルサイズと、リクエストデータを解析した結果得られるリクエスト領域の大きさから、容易に求めることができる。
【０１１５】
本実施形態では、リクエストデータが示す文字列中の”ｆｓｉｚ＝７６８，７６８＆ｒｏｆｆ＝０，０＆ｒｓｉｚ＝５１２，３８４”なる記述から、リクエスト領域として領域７０１が要求されていることがわかるので、Ｔｘ＝５１２／１２８＝４，Ｔｙ＝３８４／１２８＝３を計算することにより、Ｔｘ、Ｔｙを求めることができる。
【０１１６】
次に、ステップＳ１１０３では、リクエスト領域内の中心領域Ｃ（水平方向タイル数Ｔｃｘ、垂直方向タイル数Ｔｃｙ）を確定し、確定した中心領域Ｃの左上隅のタイルのインデックス（タイル番号）Ｔｔｌを取得する。中心領域Ｃの確定方法の詳細については、図１２を用いて後述する。
【０１１７】
次に、ステップＳ１１０４では、配列Ｐｔ’用の要素番号を示す為のカウンタ変数ｎに０を代入して初期化する。
【０１１８】
ステップＳ１１０５では、中心領域Ｃの一番外側に位置するタイル（即ち、中心領域Ｃの上下左右端に位置するタイル）のインデックスを昇順にして配列Ｐｔ’［ｎ］に格納する。ステップＳ１１０５における処理の詳細については図１３を用いて後述する。
【０１１９】
ステップＳ１１０６では、中心領域Ｃの垂直方向のタイル数Ｔｃｙとリクエスト領域の垂直方向のタイル数Ｔｙを比較する。そしてＴｃｙ＝Ｔｙであれば本処理を終了し、処理をステップＳ１００２に進める。即ち、Ｔｃｙ＝Ｔｙであれば、後述する処理をし終えた中心領域Ｃのサイズがリクエスト領域と一致していると判断することができるので、本処理を終了し、処理をステップＳ１００２に進める。
【０１２０】
一方、ＴｃｙとＴｙとが夫々異なる値であれば、処理をステップＳ１１０７に進める。即ち、後述する処理をし終えた中心領域Ｃのサイズがリクエスト領域よりも小さく、まだ処理すべき領域があると判断できるので、処理をステップＳ１１０７に進める。
【０１２１】
ステップＳ１１０７では、中心領域Ｃの水平方向のタイル数Ｔｃｘ、および垂直方向のタイル数Ｔｃｙにそれぞれ２を足し、中心領域Ｃのサイズを上下左右に１タイル分だけ大きくする。中心領域Ｃのサイズの更新に伴って、当然、中心領域Ｃの左上隅のタイルのインデックスも変化することになるが、これは現在のインデックスＴｔｌから（Ｔｗｉｄｔｈ＋１）を引くことで、サイズが変化した中心領域Ｃの左上隅のタイルのインデックスを求めることができる。
【０１２２】
次に、上記ステップＳ１１０３でリクエスト領域の中心領域Ｃを設定する処理の詳細について、同処理の詳細を示すフローチャートを示す図１２を用いて説明する。
【０１２３】
先ずステップＳ１２０１では、リクエスト領域の水平方向タイル数Ｔｘが偶数か奇数かを判断し、偶数であれば処理をステップＳ１２０２に進め、奇数であれば処理をステップＳ１２０３に進める。水平方向タイル数Ｔｘが偶数である場合には、ステップＳ１２０２で、これから設定する中心領域Ｃの水平方向のタイル数Ｔｃｘとして２を設定し、中心領域Ｃの左上隅のタイルのインデックスＴｔｌとして、Ｐｔ［（Ｔｘ−２）／２］を設定する。
【０１２４】
一方、Ｔｘが奇数であれば、ステップＳ１２０３で、これから設定する中心領域Ｃの水平方向のタイル数Ｔｃｘとして１を設定し、中心領域Ｃの左上隅のタイルのインデックスＴｔｌとしてＰｔ［Ｔｘ／２の商］を設定する。
【０１２５】
図１４は、中心領域Ｃの設定について説明するための図である。また図１４において（ａ）はリクエスト領域の縦、横のタイル数が偶数の場合に中心領域Ｃの設定について説明する図で、（ｂ）はリクエスト領域の縦、横のタイル数が奇数の場合に中心領域Ｃの設定について説明する図である。
【０１２６】
例えば図１４（ａ）に示す領域１４０１がリクエスト領域であるとすると、水平方向タイル数Ｔｘが６であり、Ｔｘは偶数であるので、図１２に示すフローチャートに従った処理では、ステップＳ１２０１から処理をステップＳ１２０２に進めることになる。そしてステップＳ１２０２では上述の通りＴｃｘ、Ｔｔｌは夫々、Ｔｃｘ＝２、Ｔｔｌ＝Ｐｔ［（６−２）／２］＝Ｐｔ［２］と設定される。ここでＰｔ［２］は図１４（ａ）では１４０６で表しているタイルのインデックスを示す。
【０１２７】
例えば図１４（ｂ）に示す領域１４１１がリクエスト領域であるとすると、水平方向タイル数Ｔｘが５であり、Ｔｘは奇数であるので、図１２に示すフローチャートに従った処理では、ステップＳ１２０１から処理をステップＳ１２０３に進めることになる。そしてステップＳ１２０３では上述の通りＴｃｘ、Ｔｔｌは夫々、Ｔｃｘ＝１、Ｔｔｌ＝Ｐｔ［５／２の商］＝Ｐｔ［２］と設定される。ここでＰｔ［２］は図１４（ｂ）では１４１６で表しているタイルのインデックスを示す。
【０１２８】
このように、ステップＳ１２０２，Ｓ１２０３では、水平方向タイル数Ｔｘが偶数、奇数の何れの場合であっても、Ｔｃｘには中心領域Ｃの水平方向タイル数が設定される。また、Ｔｔｌには中心領域Ｃの左上隅のタイルと同じ行で一番上の列のタイルのインデックスが設定されることになる。
【０１２９】
次の処理では、中心領域Ｃの垂直方向タイル数をＴｃｙに設定し、中心領域Ｃの左上隅のタイルと同じ行、且つ同じ列のタイル（即ち、中心領域Ｃの左上隅のタイル）のインデックスをＴｔｌに設定する処理を行う。
【０１３０】
ステップＳ１２０４では、リクエスト領域の垂直方向タイル数Ｔｙが偶数か奇数かを判断し、偶数であれば処理をステップＳ１２０５に進め、奇数であれば処理をステップＳ１２０６に進める。垂直方向タイル数Ｔｙが偶数である場合には、ステップＳ１２０５で、これから設定する中心領域Ｃの垂直方向のタイル数Ｔｃｙとして２を設定し、中心領域Ｃの左上隅のタイルのインデックスＴｔｌとして、上記処理で設定したインデックスＴｔｌに更にＴｗｉｄｔｈ×（Ｔｙ−２）／２を加算した結果を新たにＴｔｌに設定する処理を行う。即ち、ステップＳ１２０５の処理によって、インデックスＴｔｌには、中心領域Ｃの左上隅のタイルのインデックスが設定されることになり、更に、これまでの処理で中心領域Ｃの水平方向、垂直方向のタイル数を求めることができたので、本処理を終了し、処理をステップＳ１１０４に進める。
【０１３１】
一方、Ｔｙが奇数であれば、ステップＳ１２０６で、これから設定する中心領域Ｃの水平方向のタイル数Ｔｃｙとして１を設定し、中心領域Ｃの左上隅のタイルのインデックスＴｔｌとして、上記処理で設定したインデックスＴｔｌに更にＴｗｉｄｔｈ×（Ｔｙ／２の商）を加算した結果を新たにＴｔｌに設定する処理を行う。即ち、ステップＳ１２０６の処理によって、インデックスＴｔｌには、中心領域Ｃの左上隅のタイルのインデックスが設定されることになり、更に、これまでの処理で中心領域Ｃの水平方向、垂直方向のタイル数を求めることができたので、本処理を終了し、処理をステップＳ１１０４に進める。
【０１３２】
ステップＳ１２０４，１２０５，１２０６の処理を上記図１４を用いてより具体的に説明する。例えば図１４（ａ）に示す領域１４０１がリクエスト領域であるとすると、垂直方向タイル数Ｔｙが６であり、Ｔｙは偶数であるので、図１２に示すフローチャートに従った処理では、ステップＳ１２０４から処理をステップＳ１２０５に進めることになる。そしてステップＳ１２０５では上述の通りＴｃｙ＝２となり、Ｔｔｌには、１０×（６−２）／２＝２０をステップＳ１２０２で求めたＴｔｌの値に加算するので、１４０６で示したＰｔ［２］の位置から２列下の列の位置、即ち１４０４で示す位置のタイルのインデックスがＴｔｌに設定されることになる。
【０１３３】
例えば図１４（ｂ）に示す領域１４１１がリクエスト領域であるとすると、垂直方向タイル数Ｔｙが５であり、Ｔｙは偶数であるので、図１２に示すフローチャートに従った処理では、ステップＳ１２０４から処理をステップＳ１２０６に進めることになる。そしてステップＳ１２０６では上述の通りＴｃｙ＝１となり、Ｔｔｌには、１０×（５／２の商）＝１０×２＝２０をステップＳ１２０３で求めたＴｔｌの値に加算するので、１４１６で示したＰｔ［２］の位置から２列下の列の位置、即ち１４１４で示す位置のタイルのインデックスがＴｔｌに設定されることになる。
【０１３４】
このように、ステップＳ１２０５，Ｓ１２０６では、垂直方向タイル数Ｔｙが偶数、奇数の何れの場合であっても、Ｔｃｙには中心領域Ｃの垂直方向タイル数が設定される。また、Ｔｔｌには中心領域Ｃの左上隅のタイルのインデックスが設定されることになる。
【０１３５】
本実施形態の場合、リクエスト領域が図７に示す領域７０１であるので、図１２に示すフローチャートに従った処理を行えば、Ｔｃｘ、Ｔｃｙ、Ｔｔｌは夫々、Ｔｃｘ＝２，Ｔｃｙ＝１，Ｔｔｌ＝７と設定される。
【０１３６】
また、図１１に示したフローチャートに従った処理をより具体的に図１４を用いて説明すると、同図（ａ）において１４０２で示す領域がステップＳ１１０３における処理（即ち図１２に示したフローチャートに従った処理）でもって中心領域Ｃとして設定され、ステップＳ１１０７における処理を初めて行うとすると、本ステップでは上述の通り、領域１４０２のサイズを上下左右に１タイル分だけ大きくするので、ステップＳ１１０７の処理によって同図１４０３で示す領域が新たに中心領域Ｃとして得られる。
【０１３７】
更に、中心領域Ｃ（１４０２）の左上隅のタイルのインデックスＴｔｌには、同図に示す用に「３３」が設定されているのであるが、ステップＳ１１０７により処理を初めて行うと、中心領域Ｃは領域１４０３に更新されるので、更新後の中心領域Ｃの左上隅のタイルのインデックスＴｔｌには上述の計算、即ちＴｔｌ＝Ｔｔｌ−（Ｔｗｉｄｔｈ＋１）を計算することで、Ｔｔｌ＝３３−１０−１＝２２となり、新たにＴｔｌに「２２」が設定されることになる。
【０１３８】
ステップＳ１１０７における処理を終了すると、処理はステップＳ１１０５に戻る。領域１４０３が中心領域Ｃとして設定された後、処理をステップＳ１１０５に戻し、ステップＳ１１０６まで処理が完了すると、Ｔｃｙ＝４≠Ｔｙ＝６であるので、ステップＳ１１０６による処理によって、処理をステップＳ１１０７に進め、中心領域Ｃ（１４０３）のサイズを上下左右に１タイル分だけ大きくし、同図リクエスト領域１４０１が新たに中心領域Ｃとして得られる。そして処理はステップＳ１１０５に戻る。その後処理がステップＳ１１０６に進むと、Ｔｃｙ＝Ｔｙ＝６であるので、本処理を終了すると判断され、処理はステップＳ１００２に進むことになる。
【０１３９】
本実施形態の場合、１回目に設定される中心領域Ｃとして領域７０３が特定され、Ｔｃｘ＝２，Ｔｃｙ＝１，Ｔｔｌ＝７と計算される。そしてその後、２回目に設定される中心領域Ｃとして領域７０１が特定され、Ｔｃｘ＝４，Ｔｃｙ＝３，Ｔｔｌ＝０と計算される。すなわち、２回目に設定される中心領域Ｃはリクエスト領域と重なるものとなる。
【０１４０】
次に、上述のステップＳ１１０５の処理の詳細について、同処理のフローチャートである図１３を参照して説明する。
【０１４１】
ステップＳ１３０１では、中心領域Ｃ内の垂直方向タイルの数をカウントするための変数（カウンタ）ｙに１を代入し、初期化を行う。ここで変数ｙが取りうる値の範囲は１（最も上の行）〜Ｔｃｙ（最も下の行）である。
【０１４２】
ステップＳ１３０２では、中心領域Ｃの上からｙ行目の左端のタイルのインデックスを格納するための変数ｌｅｆｔに変数Ｔｔｌの値を代入し、初期化する。ステップＳ１３０２の時点では、ｙ＝１であるので、中心領域Ｃの１行目の左端、すなわち、左上隅のタイルのインデックスＴｔｌを初期値として変数ｌｅｆｔに代入すればよい。
【０１４３】
ステップＳ１３０３では、中心領域Ｃ内の変数ｙの値を調べ、ｙが１、もしくはＴｃｙであれば処理をステップＳ１３０４に進め、それ以外の値であれば処理をステップＳ１３０８に進める。即ち、この処理により、現在注目すべきタイルが、中心領域Ｃの一番上の行、または一番下の行に位置する場合には処理をステップＳ１３０４に進め、それ以外であれば処理をステップＳ１３０８に進める。
【０１４４】
ステップＳ１３０２からステップＳ１３０３へ進んだ場合には、ｙ＝１であるので、処理はステップＳ１３０４へ進む。
【０１４５】
ステップＳ１３０４では、中心領域Ｃ内の注目タイルのインデックスを示すための変数ｘに上記変数ｌｅｆｔの値を代入し、初期化する。ステップＳ１３０５では、配列Ｐｔ’［ｎ］に変数ｘの値を格納する。ステップＳ１３０６では、注目タイルのインデックスｘに１を足して、注目タイルを一つ右にずらし、さらに、配列Ｐｔ’の要素をカウントしている変数ｎを１つインクリメントする。
【０１４６】
ステップＳ１３０７では、変数ｘの値と値（Ｔｔｌ＋Ｔｃｘ−１）を比較し、ｘ＞（Ｔｔｌ＋Ｔｃｘ−１）の場合には処理をステップＳ１３０９に進め、ｘ≦（Ｔｔｌ＋Ｔｃｘ−１）の場合には処理をステップＳ１３０５に戻す。即ち、１行分のタイルの各インデックスを配列Ｐｔ’に代入するまではステップＳ１３０５，Ｓ１３０６の処理を繰り返す。
【０１４７】
そしてステップＳ１３０９では、変数ｙの値を１つインクリメントし、中心領域Ｃにおける注目すべき行を一つ下に移動させる。さらに、注目すべき行を示す変数ｙが変更されたことによって、ｙ行目の左端のタイル番号を示す変数ｌｅｆｔの値に、画像全体の幅に相当するタイル数Ｔｗｉｄｔｈを足して、変数ｌｅｆｔが保持する値を更新する。
【０１４８】
ステップＳ１３１０では、変数ｙと中心領域Ｃの垂直方向のタイル数Ｔｃｙを比較し、ｙ＞Ｔｃｙの場合、即ち、全ての行のタイルのインデックスを配列Ｐｔ’に代入し終えた場合には、本処理を終了し、処理をステップＳ１１０６に進める。
【０１４９】
一方、ｙ≦Ｔｃｙの場合、即ち、全ての行のタイルのインデックスをまだ配列Ｐｔ’に代入し終えていない場合には、処理をステップＳ１３０３に戻し、以降の処理を繰り返す。
【０１５０】
ここで、ステップＳ１３０３でｙ≠１、もしくはｙ≠Ｔｃｙである場合には上述の通り処理をステップＳ１３０８に進めるのであるが、ステップＳ１３０８では、配列Ｐｔ’［ｎ］に、ｌｅｆｔを代入し、Ｐｔ’［ｎ＋１］に値（ｌｅｆｔ＋Ｔｃｘ−１）を代入し、ｎに２を足して更新し、処理をステップＳ１３０９に進める。即ち、配列Ｐｔ’［ｎ］には、注目している行の中心領域Ｃの左端にあるタイルのインデックスを代入し、Ｐｔ’［ｎ＋１］には、注目している行の中心領域Ｃの右端にあるタイルのインデックスを代入することになる。
【０１５１】
つまり、同図のフローチャートに従った処理を行うと、中心領域Ｃのタイルのインデックスを左から右、上から下方向にシーケンシャルに配列Ｐｔ’［ｎ］に格納するのであるが、その際に、中心領域Ｃの一番外側に位置するタイルのインデックスのみがＰｔ’［ｎ］に格納される。これは、例えば、図１４（ａ）に示すように、１回目の中心領域Ｃ１４０２が２回目の中心領域Ｃ１４０３に含まれるため、内側のタイルは既に配列Ｐｔ’［ｎ］に格納されている。そのため、各回における中心領域Ｃの外側のタイルのインデックスのみを、Ｐｔ’［ｎ］に格納する。
【０１５２】
従って本実施形態の場合、まず１回目の注目領域Ｃ（７０３）のタイルのインデックス７、８が配列Ｐｔ’［０］、Ｐｔ’［１］に代入される。その次に、２回目の注目領域Ｃ（７０１）のタイルのインデックスが配列Ｐｔ’［ｎ］に順に、０, １, ２, ３, ６, ９, １２, １３, １４, １５と代入される。そして最終的に配列Ｐｔ’［ｎ］が格納する各値は以下のようになる。
【０１５３】
Ｐｔ’［０］＝７，Ｐｔ’［１］＝８，
Ｐｔ’［２］＝０，Ｐｔ’［３］＝１，Ｐｔ’［４］＝２，Ｐｔ’［５］＝３
Ｐｔ’［６］＝６，Ｐｔ’［７］＝９，
Ｐｔ’［８］＝１２，Ｐｔ’［９］＝１３，Ｐｔ’［１０］＝１４，Ｐｔ’［１１］＝１５
ここで、図１５に示すようなデータサイズの画像の符号化データをサーバ装置２０４が管理している（記憶装置２０５に保存されている）場合、以上説明したリクエストデータを受信したサーバ装置２０４が、リクエスト領域内のタイルインデックス順にlayer方向のスケーラビリティで返送した場合と、上述のようにリクエスト領域内の中心から順にタイルのインデックスを並べ直し、並べ直したインデックスの順番でlayer方向のスケーラビリティで返送した場合のレスポンスデータを比較する。計算を簡単にするために、全てのタイル、コンポーネントに関して、各ｌａｙｅｒ，  ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌのｐａｃｋｅｔに、ｍｅｓｓａｇｅ  ｈｅａｄｅｒを付加したときのデータサイズは、図１５（ｂ）に示す表に従ったものとする。
【０１５４】
layer方向のスケーラビリティで返送する場合、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  １，ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２の各ｌａｙｅｒの１２タイル分のデータサイズは、それぞれ、以下のようになる。
【０１５５】
layer ０: (０.４ ＋ ０.８) × ３ component × １２ tile ＝ ４３.２ [kbyte]
layer １: (０.６ ＋ １.２) × ３ component × １２ tile ＝ ６４.８ [kbyte]
layer ２: (０.８ ＋ １.６) × ３ component × １２ tile ＝ ８６.４ [kbyte]
layer ３: (１.０ ＋ ２.０) × ３ component × １２ tile ＝ １０８.０ [kbyte]
layer ４: (１.２ ＋ ２.４) × ３ component × １２ tile ＝ １２９.６ [kbyte]
ここで、ｌａｙｅｒ０〜３の夫々のデータサイズを全て加算した結果、
４３．２＋６４．８＋８６．４＋１０８．０＝３０２．４  ［ｋｂｙｔｅ］
となり、レスポンスデータの上限値である３６０［ｋｂｙｔｅ］よりの小さいので、ｌａｙｅｒ０〜３のデータについてはレスポンスデータに含めることができる。
【０１５６】
そして更にｌａｙｅｒ４のデータについてもレスポンスデータに含めるのであるが、ここで、レスポンスデータのサイズの上限値は３６０［ｋｂｙｔｅ］であるので、ｌａｙｅｒ４のデータについては３６０．０−３０２．４＝５７．６［ｋｂｙｔｅ］分だけしかレスポンスデータに含めることができない。
【０１５７】
ここで、ｌａｙｅｒ４のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ１のデータサイズは、１.２×３  component×１２ tile＝４３.２［ｋｂｙｔｅ］であるので、ｌａｙｅｒ４のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ１のデータはレスポンスデータに含めることができる。これで、ｌａｙｅｒ０〜３のデータ、及びｌａｙｅｒ４のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ１のデータをレスポンスデータに含めると、まだレスポンスデータに含めることのできるデータのサイズは３６０.０−３０２.４−４３.２＝１４.４［ｋｂｙｔｅ］となる。この１４．４［ｋｂｙｔｅ］分の部分には、ｌａｙｅｒ４、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２のタイルのデータが丁度２枚分（２.４×３ component×２ tile＝１４.４  ［ｋｂｙｔｅ］）含めることができる。この２枚分は、リクエスト領域内の中心から順にタイルのインデックスを並べ直した順番でタイルを参照した場合に、先頭（リクエスト領域内の中心に近い方から見て先頭）から２枚分を示す。
【０１５８】
図２１に、このレスポンスデータの構成を表にして示す。同図に示すように、最終的にレスポンスデータに含めることができるのは、ｌａｙｅｒ０〜３のデータ、及びｌａｙｅｒ４のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ１のデータ、及びｌａｙｅｒ４、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２の２枚分のタイルのデータとなる。
【０１５９】
サーバ装置２０４が、リクエスト領域内のタイルインデックス順にlayer方向のスケーラビリティで返送した場合、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルは、リクエスト領域の左上、tile ０およびtile １となる。それに対して本実施形態では、リクエスト領域内の中心から順にタイルのインデックスを並べ直し、並べ直したインデックス順にlayer方向のスケーラビリティで返送するので、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルは、リクエスト領域の中心部分にあたるtile ７およびtile ８となる。それぞれの場合のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを図１６（ａ）、（ｂ）に示す。
【０１６０】
図１６（ａ）はリクエスト領域の左上から順に各タイルのデータを送信する場合に、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図で、上述の通り、タイル０，１がこの返送タイルに該当する。図１６（ｂ）は本実施形態に係る方法でタイルのデータを送信する場合に、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図で、中心領域Ｃで、且つ２つ分のタイル、即ち、タイル７，８のデータが上記返送タイルに該当する。
【０１６１】
画像への観察者の注目箇所は一般に画像の中心部分であることが多いため、データサイズの上限値に起因して送信できるタイルの数が限定された場合、この中心部分に近いものほど送信すべき優先度は高い。当然、リクエスト領域を指定した場合についても同様で、このリクエスト領域の中心部分ほど、観察者の関心度は高い。
【０１６２】
従って本実施形態ではそのような背景を鑑み、画像全体、もしくはリクエスト領域の中心部に位置するタイルほど、より多くのデータ、即ちより高画質にするためのデータをレスポンスデータに含めるようにしている。
【０１６３】
これにより、制限されたデータサイズのレスポンスデータサイズの中で、リクエスト領域の中心部分のデータを周辺部分のデータよりも多くデータサイズを割り当てることができ、中心部分ほど、より高画質に再現することができる。
【０１６４】
またこの割り当てを、画質の一番高い部分だけで調節するため、指定されたレスポンスデータサイズを最大限に生かしながら、リクエスト領域内で極端に画質あるいは解像度の違いが起こる可能性を低く押さえることができ、これによる違和感が少ない画像を提供することができる。
【０１６５】
また、本実施形態に係る上記処理は、リクエスト領域が指定されていなくても（もしくは画像全体を指定した場合でも）実施可能で、その場合、このリクエスト領域を画像全体と見なすことにより、この画像の中心部ほど画質を高くし、且つ指定されたデータサイズ以下のレスポンスデータを作成することができる。
【０１６６】
［第２の実施形態］
第１の実施形態では、クライアント端末装置から受信したリクエストデータのみを利用して、各タイルの送信順序を決定していた。しかし、リクエスト領域に含まれるタイルの幾つかに、メタデータが付与されている場合、これらのデータを基に、各タイルの送信順序を決定する方法も考えられる。この場合、第１の実施形態と異なるのは、図１０におけるステップＳ１００１、即ち、タイルのインデックスを並べるステップである。
【０１６７】
本実施形態では、図１７に示すように、インデックスが６，７、１５、１６、２１、２２、３０、３１である８つのタイルにメタデータが付与されているものとする。以下ではこのような場合に、タイルの送信順序を決定する処理について説明する。
【０１６８】
これらは３つのメタデータ付与領域１７０１、１７０２、１７０３である。メタデータ付与領域１７０１はタイル６と７であり、リクエスト領域７０１に完全に含まれている。メタデータ付与領域１７０２は、タイル１５、１６、２１、２２であり、リクエスト領域７０１と一部重なっている。メタデータ付与領域１７０３は、タイル３０と３１であり、リクエスト領域７０１と重なる部分は全くない。
【０１６９】
この場合にステップＳ１００１で行うべき、タイルのインデックスの並び替え処理を、同処理のフローチャートを示す図１８を参照して以下説明する。
【０１７０】
先ずステップＳ１８０１では、画像のメタデータが付与されている領域（メタデータ付与領域）、即ち、メタデータが付与されているタイル群により構成される領域のうち、リクエスト領域に完全に含まれてしまうメタデータ付与領域を構成するタイルのインデックスをＰｔ’に格納する。
【０１７１】
これは即ち、先ず、隣接する「メタデータが付与されたタイル」をひとまとめにして１つのメタデータ付与領域として管理し、そして領域７０１を構成するタイルのインデックスを格納する配列Ｐｔを参照し、管理する各メタデータ付与領域毎に、メタデータ付与領域を構成するタイルのインデックスが全て配列Ｐｔに格納されているか否かを判断し、全て格納されている場合には、このメタデータ付与領域は領域７０１に完全に含まれていると判断することができる。
【０１７２】
このようにしてステップＳ１８０１では、領域７０１に完全に含まれているメタデータ付与領域を構成するタイルのインデックスを配列Ｐｔ’に格納する。図１７に示す例では、領域１７０１を構成するタイルのインデックスのみがステップＳ１８０１で配列Ｐｔ’に格納する対象となる。従ってこの場合、ステップＳ１８０１では、Ｐｔ’［０］＝６，Ｐｔ’［１］＝７となる。
【０１７３】
次に、ステップＳ１８０２では、リクエスト領域と一部が重なるメタデータ付与領域のタイルのうち、リクエスト領域に含まれるタイルのインデックスを配列Ｐｔ’に、ステップＳ１８０１で格納したデータに後続する形態で格納する。
【０１７４】
これは即ち、領域７０１を構成するタイルのインデックスを格納する配列Ｐｔを参照し、管理する各メタデータ付与領域毎に、メタデータ付与領域を構成するタイルのインデックスのうち１以上が配列Ｐｔに格納されているか否かを判断し、１つ以上が格納されている場合には、このメタデータ付与領域は領域７０１と一部が重なっていると判断することができる。
【０１７５】
このようにしてステップＳ１８０２では、領域７０１と一部が重なっているメタデータ付与領域を構成するタイルのインデックスを配列Ｐｔ’に格納する。図１７に示す例では、領域１７０２を構成するタイルのうちインデックスが１５のタイルのインデックス（即ち１５）のみがステップＳ１８０２で配列Ｐｔ’に格納する対象となる。従ってこの場合、ステップＳ１８０２では、Ｐｔ’［２］＝１５となる。
【０１７６】
次に、ステップＳ１８０３では、配列Ｐｔに格納されているインデックスと、ステップＳ１８０１及びステップＳ１８０２で既に配列Ｐｔ’に格納されたインデックスとを比較し、まだ、配列Ｐｔ’に格納されていないインデックスを、インデックス順に配列Ｐｔ’に格納し、本処理を終了する。従って図１８に示すフローチャートに従った処理を完了すると、配列Ｐｔ’には以下に示すようなデータがこの順で格納されていることになる。
【０１７７】
Ｐｔ’［０］＝６，Ｐｔ’［１］＝７，Ｐｔ’［２］＝１５，
Ｐｔ’［３］＝０，Ｐｔ’［４］＝１，Ｐｔ’［５］＝２，Ｐｔ’［６］＝３，
Ｐｔ’［７］＝８，Ｐｔ’［８］＝９，
Ｐｔ’［９］＝１２，Ｐｔ’［１０］＝１３，Ｐｔ’［１１］＝１４
なお、本実施形態では、メタデータ付与領域の特定方法は、どのような方法でも構わない。例えば、ISO／IEC １５４４４-２  Annex Nに記されているようなXMLで、画像の部分領域にメタデータを付与した場合には、画像ファイル内のXMLが記述された部分から、それぞれのメタデータのPOSITION elementを解析することで、メタデータが付与されている領域を特定することが可能である。
【０１７８】
この他にもメタデータの付与方法によって、メタデータが付与されている部分領域を特定する方法は様々考えられるが、それぞれのメタデータ付与方法によって最適な特定方法は異なるので、ここでは、説明を割愛する。
【０１７９】
従って、図１５に示すようなデータサイズの画像の符号化データをサーバ装置２０４が管理している（記憶装置２０５に保存されている）場合、本実施形態のようにリクエスト領域内のメタデータ付与領域に含まれるタイルからタイル番号を並べ直し、layer方向のスケーラビリティで返送した場合、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルは、メタデータが付与されている領域７０１のタイル６、７となる。本実施形態の場合のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを図１６（ｃ）に示す。
【０１８０】
図１６（ｃ）は本実施形態に係る方法でタイルのデータを送信する場合に、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図で、タイル６，７のデータが上記返送タイルに該当する。
【０１８１】
一般に、メタデータ部分が付与されている領域は、その画像の中でも意味のある、あるいは重要な領域であることが多い。そのため、データを送信する時のタイルの順番をこのような方法で決めることで、レスポンスデータのデータサイズが制限されている場合でも、比較的重要であると考えられる領域のデータを、その他の部分よりも多く返送することができる。
【０１８２】
また、メタデータ付与領域を１ｌａｙｅｒ分としても、他の部分よりも画質が良くなり、特別にROIを設定するような符号化を用いなくても、簡易的にROIのような効果を期待できる。この簡易的なROIの効果は、再エンコードの必要がない。そのため、他の部分よりも意図的に少しでも画質が向上した状態でクライアント端末装置に提示したい場合には、メタデータの付与領域を変更するだけであるので、非常に容易にクライアント端末装置側に見せたい部分をコントロールできる。
【０１８３】
［第３の実施形態］
第２の実施形態では、メタデータの有無の情報を基にデータの送信順序を決める方法であったが、暗号化されている部分の有無の情報を基にデータの送信順序を決める方法も考えられる。
【０１８４】
一般に、重要な部分には暗号化が施されていると考えて、暗号化領域のデータをなるべく多く返送するように考えると、図１８の各ステップに記載されているメタデータ付与領域の代わりに、暗号化領域を当てはめて考えれば、同様のフローになる。
【０１８５】
逆に、暗号化部分のデータをなるべくクライアント側に残さないという方針であれば、暗号化されていない領域のデータをなるべく多く返送するように考えると、図１８の各ステップに記載されているメタデータ付与領域の代わりに、非暗号化領域を当てはめて考えれば、同様のフローになる。
【０１８６】
あるいは、クライアント端末装置が復号鍵を利用できるか否かの情報を基に、上記２つのフローを切り替えても良い。つまり、復号鍵を利用できるクライアント端末装置には暗号化部分を優先させた送信順序とし、逆に、復号鍵を利用できないクライアント端末装置に対しては、非暗号化部分を優先させた送信順序とする。
【０１８７】
暗号化領域の特定には、画像ファイルに付与されている情報を基にする特定する方法や、ビットストリームを実際に解析して特定する方法、別ファイルに保存されている情報を基に特定する方法、認証サーバなどの第３者から情報を得る方法など様々考えられるが、暗号化領域の特定は主眼ではないので、詳しい説明は割愛する。
【０１８８】
よって以上説明した本実施形態に係る方法を用いれば、サーバ装置は既に施されている暗号化の情報を基に、リクエスト領域内のタイルの送信順序を決定できるので、暗号化処理を行った人の意図を、データ送信の際にも容易に反映させることができる。また、クライアント端末装置の復号鍵利用権利の情報と組み合わせることで、個々のクライアント端末装置に応じたデータ配信方法が容易に行える。
【０１８９】
［第４の実施形態］
第１の実施形態では、クライアント端末装置のリクエスト領域のみから、第２，３の実施形態では、画像のビットストリームあるいはファイルの情報から、データの送信順序を決めていたが、各部分領域のアクセス数をサーバ装置側で保存し、その統計量を基にデータの送信順序を決定する方法も考えられる。この場合、第１の実施形態と異なるのは、図１０におけるステップＳ１００１、即ち、タイルのインデックスを並べるステップである。
【０１９０】
本実施形態では、図１９（ａ）に示すように、各タイル毎のアクセス回数をテーブル形式でもって管理しているものとする。このテーブルのデータは二次記憶メモリ１０３に保存されており、必要に応じて一次記憶メモリ１０２にロードされるものとする。以下ではこのような場合に、タイルの送信順序を決定する処理について説明する。
【０１９１】
本実施形態では、アクセス数の多いもの順にタイルのインデックスを並び替える。この処理についてより詳細に説明するため、本実施形態に係るステップＳ１００１で行うべき、タイルのインデックスの並び替え処理を、同処理のフローチャートを示す図２０を参照して以下説明する。
【０１９２】
先ず、ステップＳ２００１では、リクエスト領域に含まれる全タイル、つまり配列Ｐｔに格納されているインデックスで特定される全てのタイルへのアクセス数を図１９（ａ）に示すテーブル１９０１を参照して取得する。リクエスト領域が図７に示す領域７０１である場合に、取得したアクセス数のデータを図１９（ｂ）に示す。
【０１９３】
図１９（ｂ）に示すように、領域７０１をリクエスト領域とした場合、インデックスが０，１，２，３，６，７，８，９，１２，１３，１４，１５の１２タイル分の夫々に対するアクセス数のデータが取得される。取得したアクセス数のデータは一次記憶メモリ１０２に一時的に記憶される。
【０１９４】
次に、ステップＳ２００２において、ステップＳ２００１で取得したアクセス回数を参照し、アクセス回数の大きいものから順にインデックスを並べ直し、配列Ｐｔ’に格納し、本処理を終了する。アクセス回数を基準にして降順にデータを並べなおす方法としては、バブルソート、クイックソート、ヒープソートなど様々な方法が考えられるが、主眼ではないので割愛する。本実施形態では、領域７０１の各タイルに対するアクセス数が図１９（ｂ）に示した数値であるとするので、図２０に示したフローチャートに従った処理が完了すると、配列Ｐｔ’には以下のような値が格納されていることになる。
【０１９５】
Ｐｔ’［０］＝８，Ｐｔ’［１］＝９，Ｐｔ’［２］＝１４，Ｐｔ’［３］＝１５
Ｐｔ’［４］＝７，Ｐｔ’［５］＝１３，Ｐｔ’［６］＝２，Ｐｔ’［７］＝３
Ｐｔ’［８］＝１，Ｐｔ’［９］＝６，Ｐｔ’［１０］＝１２，Ｐｔ’［１１］＝０
なお、本実施形態では、アクセス数が同じタイルについては、インデックスが小さい方を先に配列Ｐｔ’に格納するものとする。
【０１９６】
従って、本実施形態のようにリクエスト領域内のアクセス数の多い順にタイル番号を並べ直しlayer方向のスケーラビリティで返送した場合、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ４，ｌａｙｅｒ２の返送タイルは、最もアクセス数が多い上位２つの領域７０１のタイル８、９となる。本実施形態の場合のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを図１６（ｄ）に示す。
【０１９７】
なお、アクセス数のカウント方法については、ステップＳ８０２における解析処理の結果得られた、クライアント端末装置が要求する各タイルについて、サーバ装置が管理しているアクセス数をカウントアップすれば良い。従って、サーバ装置は、
ｔｉｌｅＣｏｕｎｔ［Ｐｔ［ｎ］］＝ｔｉｌｅＣｏｕｎｔ［Ｐｔ［ｎ］］＋１
の演算処理（カウントアップ処理）を、ステップＳ８０２において要求タイルが確定した時点で行えばよい。ここで、ｔｉｌｅＣｏｕｎｔ［Ｐｔ［ｎ］］は、タイルＰｔ［ｎ］のアクセス数である。
【０１９８】
一般に、アクセス数の多い領域は、その画像の中でも意味のある、あるいは重要な領域であることが多い。そのため、データを送信する時のタイルの順番をこのような方法で決めることで、レスポンスデータのデータサイズが制限されている場合でも、一般的に、ユーザにとって重要であると考えられる領域のデータを、その他の部分よりも多く返送することができる。
【０１９９】
また、アクセス数をただ累積するだけでなく、前日、あるいは、過去数日間の統計量を用いてデータの送信順序を決定すれば、ユーザの嗜好が徐々に変わって、アクセス数が変化していても、嗜好の変化に合わせて、送信順序を自動的に変更していくことも容易に可能になる。
【０２００】
また、以上のアクセス数のカウント方法では、要求layerに応じた重み付けを行っていないが、最高layerへのリクエストのときのみ、アクセス数をカウントアップすることもできる。従って、クライアントからのリクエストが最高layerであれば、上記カウントアップ処理を実行し、リクエストが最高layerに対するものでなければ、カウントアップ処理は行わない。このようなアクセス数のカウント方法を用いることで、最高画質へのアクセスのみを重要なアクセスであったと判断することになり、最高画質でのアクセスがあった領域を、その他の部分よりも多く返送することができる。
【０２０１】
また、以上の実施形態では、１タイル１positionであったため、タイルを基本として、データの返送順序を決めていたが、画像全体が１タイル、すなわち、画像を複数タイルに分割しておらず、ＪＰＥＧ２０００のｐｏｓｉｔｉｏｎのみで分割している場合には、ｐｏｓｉｔｉｏｎを基本としてデータの返送順序を決めても良い。また、画像全体がタイル分割され、かつ、各タイルが複数ｐｏｓｉｔｉｏｎに分割されている場合には、ｐｏｓｉｔｉｏｎ単位でデータの送信順序を決めても良い。
【０２０２】
以上の実施形態によって、レスポンスデータのデータサイズに制限があっても、サーバ装置側でなるべくデータを多く返すべきだと判断した重要領域のデータを、他の部分領域よりも１ｌａｙｅｒ分多く返送することができる。
【０２０３】
また、重要領域の画質が周辺部と極端に異なるわけではないため、違和感を少なくすることができる。
【０２０４】
さらに、各タイル、各resolution level、各layerが独立に符号化されているJPEG２０００データを使用することで、サーバ装置側で送信順序決定後に、データを再エンコードし直す必要がないため、送信順序制御に伴うサーバ装置側の負荷を小さくすることができる。その上、再エンコードすること無く、解像度・画質・部分領域・コンポーネント等の異なる様々な要求に応じて、動的に対応が可能である。
【０２０５】
さらに、クライアント端末装置側で要求したデータ制限サイズ以内に、サーバ装置側が意図的に送信データサイズを制限し、layer-resolutionのスケーラビリティでデータの送出を行うため、クライアント端末装置側で一部分だけが高精細に表示されてしまうという不自然な状態になる可能性が低くなる。
【０２０６】
［その他の実施形態］
本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【０２０７】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０８】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０９】
本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【図面の簡単な説明】
【０２１０】
【図１】ＰＣ（パーソナルコンピュータ）やワークステーションなどにより構成される、本発明の実施形態に係る画像処理装置の基本構成を示すブロック図である。
【図２】画像処理装置を含むシステムの概要を示す図である。
【図３】Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ  ｐｒｏｇｒｅｓｓｉｏｎに従ったＪＰＥＧ２０００のビットストリームの構成を示す図である。
【図４】解像度とＲｅｓｏｌｕｔｉｏｎ番号との関係を示す図である。
【図５】パケット単位でのリクエスト及びレスポンスの概念図である。
【図６】（ａ）はprecinct data−binと呼ばれるJPEG2000のpacketデータの塊の構成を示す図、（ｂ）は（ａ）に示すｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎを用いて作成されたＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａの構成を示す図である。
【図７】サーバ装置２０４が保持する符号化データが表す画像においてタイルと解像度の関係を示す図である。
【図８】サーバ装置２０４がクライアント端末装置から以上のようなリクエストデータを受信した場合に行うメインの処理のフローチャートである。
【図９】ステップＳ８０４における処理の詳細、即ち、レスポンスデータにサイズ制限が指定されていない場合に、サーバ装置２０４が行う処理のフローチャートである。
【図１０】ステップＳ８０６における処理の詳細、即ち、レスポンスデータにサイズ制限が指定されている場合に、サーバ装置２０４が行う処理のフローチャートである。
【図１１】ステップＳ１００１における処理の詳細、即ち、配列Ｐｔが保持する「クライアント端末装置に送信する符号化データが属する各タイルのインデックス」を優先度の高い順に並べなおし、配列Ｐｔ’に格納する処理のフローチャートである。
【図１２】ステップＳ１１０３でリクエスト領域の中心領域Ｃを設定する処理の詳細を示すフローチャートである。
【図１３】ステップＳ１１０５の処理のフローチャートである。
【図１４】中心領域Ｃの設定について説明するための図である。
【図１５】符号化データのデータサイズの一例を示す図である。
【図１６】（ａ）はリクエスト領域の左上から順に各タイルのデータを送信する場合に、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図、（ｂ）は本発明の第１の実施形態に係る方法でタイルのデータを送信する場合に、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図、（ｃ）は本発明の第２の実施形態の場合のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図、（ｄ）は本発明の第４の実施形態の場合のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２，ｌａｙｅｒ４の返送タイルを示す図である。
【図１７】メタデータが付与されたタイルのデータを説明するための図である。
【図１８】本発明の第２の実施形態でステップＳ１００１で行うべき、タイルのインデックスの並び替え処理のフローチャートである。
【図１９】（ａ）は各タイル毎のアクセス回数を管理するためのテーブルを示す図、（ｂ）は、リクエスト領域が図７に示す領域７０１である場合に、取得したアクセス数のデータを示す図である。
【図２０】本発明の第４の実施形態でステップＳ１００１で行うべき、タイルのインデックスの並び替え処理のフローチャートである。
【図２１】本発明の第１の実施形態におけるレスポンスデータの構成を示す図である。
【図１】
2005130470.tif 000003
【図２】
2005130470.tif 000004
【図３】
2005130470.tif 000005
【図４】
2005130470.tif 000006
【図５】
2005130470.tif 000007
【図６】
2005130470.tif 000008
【図７】
2005130470.tif 000009
【図８】
2005130470.tif 000010
【図９】
2005130470.tif 000011
【図１０】
2005130470.tif 000012
【図１１】
2005130470.tif 000013
【図１２】
2005130470.tif 000014
【図１３】
2005130470.tif 000015
【図１４】
2005130470.tif 000016
【図１５】
2005130470.tif 000017
【図１６】
2005130470.tif 000018
【図１７】
2005130470.tif 000019
【図１８】
2005130470.tif 000020
【図１９】
2005130470.tif 000021
【図２０】
2005130470.tif 000022
【図２１】
2005130470.tif 000023