(57)【要約】【課題】  解像度が低いサムネイル画像等についてはタイル数が少ないデータを返送してファイルシーク回数を減少でき、拡大要求により解像度が高い画像についてはタイル数が多いデータを返送するので、必要な部分画像に好適にアクセスすることでき、無駄なデータ転送を抑えることができる画像処理方法及び画像処理装置を提供する。【解決手段】  画像を複数のタイルに分割して階層符号化された符号化データを、クライアントからのリクエストに応じて、サーバが断片的に送信する。サーバは、クライアントから要求された画像の表示領域の全体に占める割合を算出し、その割合がしきい値以下の場合には多くのタイル数で分割された符号化データを選択し、それ以外の場合には少ないタイル数で分割された符号化データを選択し、表示領域に相当する部分を抽出してクライアントに送信する。【選択図】  図１０
2006191159.tif 000002
【特許請求の範囲】
【請求項１】
画像を複数のタイルに分割して階層符号化された符号化データを、クライアントからの要求に応じて、サーバが断片的に送信するサーバ／クライアントシステムにおける画像処理方法であって、前記サーバが、
前記クライアントから要求された前記画像の所定領域を表示するためのリクエストを受信する受信工程と、
受信した前記リクエストを解析する解析工程と、
前記リクエストの解析結果に基づいて、前記クライアントから要求された前記画像の表示領域の画像全体に占める割合を算出する算出工程と、
前記サーバが保持している第１のタイル数で分割して階層符号化された第１の符号化データとは分割タイル数が異なる第２のタイル数で前記画像を分割して階層符号化された第２の符号化データを生成する生成工程と、
前記割合が所定値以下の場合には前記第１及び第２の符号化データのうち、より多いタイル数で前記画像が分割された符号化データを選択し、該割合が前記所定値以上の場合には前記第１及び第２の符号化データのうち、より少ないタイル数で前記画像が分割された符号化データを選択する選択工程と、
選択された前記符号化データから前記表示領域に相当する符号化データを抽出する抽出工程と、
抽出された前記符号化データを前記クライアントに送信する送信工程と
を有することを特徴とする画像処理方法。
【請求項２】
前記クライアントが、
前記サーバに対して、前記画像の所定領域を表示するための前記リクエストを送信する工程と、
前記サーバから送信された前記表示領域に相当する前記符号化データを受信する工程と、
前記符号化データを復号して表示する工程と
をさらに有することを特徴とする請求項１に記載の画像処理方法。
【請求項３】
前記選択工程による符号化データ選択時に使用された前記所定値を前記クライアントに通知する通知工程をさらに有することを特徴とする請求項１又は２に記載の画像処理方法。
【請求項４】
前記生成工程が、前記サーバが保持する前記第１のタイル数で分割して階層符号化された前記第１の符号化データにおいて、隣接する複数のタイルから１枚のタイルを生成して再符号化することによって該第１のタイル数よりも少ないタイル数の前記第２のタイル数で前記画像を分割して階層符号化された前記第２の符号化データを生成することを特徴とする請求項１から３までのいずれか１項記載の画像処理方法。
【請求項５】
前記選択手段は、前記割合が所定値以下の場合には前記第１の符号化データを選択し、該割合が前記所定値以上の場合には前記第２の符号化データを選択することを特徴とする請求項４に記載の画像処理方法。
【請求項６】
前記生成工程が、前記サーバが保持する前記第１のタイル数で分割して階層符号化された第１の符号化データの各タイルを複数のタイルに分割して再符号化することによって、該第１のタイル数よりも多いタイル数の前記第２のタイル数で前記画像を分割して階層符号化された前記第２の符号化データを生成することを特徴とする請求項１から３までのいずれか１項記載の画像処理方法。
【請求項７】
前記選択手段は、前記割合が所定値以下の場合には前記第２の符号化データを選択し、該割合が前記所定値以上の場合には前記第１の符号化データを選択することを特徴とする請求項６に記載の画像処理方法。
【請求項８】
前記クライアントが、前記サーバに対して、該クライアントが保存していない符号化データの送信を前記リクエストとして要求することを特徴とする請求項１から７までのいずれか１項に記載の画像処理方法。
【請求項９】
前記符号化データが、ＪＰＥＧ２０００符号化方式に基づいて符号化されたデータであることを特徴とする請求項１から８までのいずれか１項に記載の画像処理方法。
【請求項１０】
前記サーバが前記クライアントに対して断片的に送信する前記符号化データが、ＪＰＥＧ２０００符号化方式におけるパケット単位で送信されることを特徴とする請求項１から９までのいずれか１項に記載の画像処理方法。
【請求項１１】
前記サーバが前記クライアントに対して断片的に送信する前記符号化データが、ＪＰＥＧ２０００符号化方式におけるタイル単位で送信されることを特徴とする請求項１から９までのいずれか１項に記載の画像処理方法。
【請求項１２】
前記符号化データの送受信を行う際のリクエストレスポンスとしてＪＰＩＰを使用することを特徴とする請求項１から１１までのいずれか１項に記載の画像処理方法。
【請求項１３】
画像を複数のタイルに分割して階層符号化された符号化データを、他装置からの要求に応じて、断片的に送信する画像処理装置であって、
前記他装置から要求された前記画像の所定領域を表示するためのリクエストを受信する受信手段と、
受信した前記リクエストを解析する解析手段と、
前記リクエストの解析結果に基づいて、前記他装置から要求された前記画像の表示領域の画像全体に占める割合を算出する算出手段と、
第１のタイル数で分割して階層符号化された第１の符号化データを保持する保持手段と、
前記第１の符号化データとは分割タイル数が異なる第２のタイル数で前記画像を分割して階層符号化された第２の符号化データを生成する生成手段と、
前記割合が所定値以下の場合には前記第１及び第２の符号化データのうち、より多いタイル数で前記画像が分割された符号化データを選択し、該割合が前記所定値以上の場合には前記第１及び第２の符号化データのうち、より少ないタイル数で前記画像が分割された符号化データを選択する選択手段と、
選択された前記符号化データから前記表示領域に相当する符号化データを抽出する抽出手段と、
抽出された前記符号化データを前記他装置に送信する送信手段と
を備えることを特徴とする画像処理装置。
【請求項１４】
画像を複数のタイルに分割して階層符号化された符号化データを、他装置からの要求に応じて、断片的に送信するコンピュータに、
前記他装置から要求された前記画像の所定領域を表示するためのリクエストを受信する受信手順と、
受信した前記リクエストを解析する解析手順と、
前記リクエストの解析結果に基づいて、前記他装置から要求された前記画像の表示領域の画像全体に占める割合を算出する算出手順と、
第１のタイル数で分割して階層符号化された第１の符号化データとは分割タイル数が異なる第２のタイル数で前記画像を分割して階層符号化された第２の符号化データを生成する生成手順と、
前記割合が所定値以下の場合には前記第１及び第２の符号化データのうち、より多いタイル数で前記画像が分割された符号化データを選択し、該割合が前記所定値以上の場合には前記第１及び第２の符号化データのうち、より少ないタイル数で前記画像が分割された符号化データを選択する選択手順と、
選択された前記符号化データから前記表示領域に相当する符号化データを抽出する抽出手順と、
抽出された前記符号化データを前記他装置に送信する送信手順と
を実行させるためのプログラム。
【請求項１５】
請求項１４に記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数解像度を有し、各解像度のデータを複数のタイルに分割して符号化した画像を保持する装置から、所望の解像度の画像から一部あるいは画像全体を得るために、画像データを要求したクライアントに対して、その要求領域の全体に占める割合から、必要に応じてタイル数を変更した画像データを作成し、画像データの部分データを送受信するための技術に関するものである。
【背景技術】
【０００２】
近年、普及が目覚しいデジタルカメラは、取り扱う画素数も膨大になりつつあり、例えば２００万画素から５００万画素程度のものが汎用のカメラにおいて一般的になりつつある。また、専門家向けのデジタルカメラになると、１０００万画素クラスのものが普及し始めてきており、今後もより一層高精細化が進むと考えられる。
【０００３】
この一方で、デジタルカメラで撮影された画像を、インターネット上のオンラインのアルバムサービスにアップロードして楽しむユーザも増えてきている。このようなシステムでは、様々な種類の画像の閲覧ソフトが存在するが、一般には、サムネイル画像による一覧表示を行って、その中から拡大して表示したい画像をユーザが選択して、サムネイル画像よりも大きく表示することがある。
【０００４】
しかしながら、上述したような近年のデジタルカメラで撮影した大きな画素数で構成される画像データを拡大表示するようにユーザの選択の度にサーバからダウンロードするような場合、クライアントの端末に当該画像が表示されるまでには非常に長い待ち時間が必要である。
【０００５】
このような問題を解消するために、複数解像度を持ち、各解像度のデータを複数のタイルに分割し符号化した画像データを予めサーバに保存しておき、ユーザの選択による表示の際に必要な部分データのみをダウンロードして表示するような技術が開発されている。このような技術の代表的なものとして、例えば、ＦｌａｓｈｐｉｘとＩＩＰを組み合わせた技術や、ＪＰＥＧ２０００を利用した技術等が知られている。すなわち、このような技術によれば、各画像データが解像度を複数持つことでクライアントの表示サイズの変更に対応することができ、それらをタイル分割することでクライアントが画像の一部の領域にランダムにアクセスすることを実現可能にしている。さらに、分割するタイルの大きさを小さくすることにより、無駄な転送データ量を削減することもできる。
【０００６】
ここで、Ｆｌａｓｈｐｉｘとは、Ｄｉｇｉｔａｌ  ｉｍａｇｉｎｇ  ｇｒｏｕｐ（ＤＩＧ）によって規格化された画像ファイルフォーマットである。Ｆｌａｓｈｐｉｘは複数解像度を持っており、各々は６４×６４［ｐｉｘｅｌ］のタイルに分割されている。また、ＩＩＰとは、Ｉｎｔｅｒｎｅｔ  Ｉｍａｇｉｎｇ  ｐｒｏｔｏｃｏｌの略であり、Ｆｌａｓｈｐｉｘの解像度とタイルを指定することで、クライアントはＦｌａｓｈｐｉｘデータの中から必要なデータのみを取得できるプロトコルである。
【０００７】
さらに、ＪＰＥＧ２０００を利用した技術としては、ＪＰＥＧ２０００とＪＰＩＰを使用したものがある。ＪＰＥＧ２０００は、複数解像度を持ち、タイル分割されている画像符号化方式として、２００１年に標準化された画像符号化方式である。尚、ＪＰＩＰとは、ＪＰＥＧ２０００に従って符号化されたファイルへ断片的にアクセスして表示するためのプロトコルとして、現在策定中の、ＪＰＥＧ２０００  ｉｍａｇｅ  ｃｏｄｉｎｇ  ｓｙｓｔｅｍ−Ｐａｒｔ  ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ  ｔｏｏｌｓ，ＡＰＩｓ  ａｎｄ  ｐｒｏｔｏｃｏｌｓのことである。
【０００８】
また、同様の技術が特開２００３−２３６３０公報（特許文献１）や特開２００４−４０６７４公報（特許文献２）にも開示されている。
【０００９】
特許文献１には、サーバに格納されているＪＰＥＧ２０００で符号化された画像データの部分データを送受信するサーバ／クライアントシステムに関する技術が開示されている。当該技術によれば、クライアントは、サーバに格納されているコードストリームのどの部分が既にクライアントのバッファに格納されているかという情報に基づいて、未だバッファに格納されていない圧縮データの部分をサーバに要求する。一方、サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。そして、最終的に、クライアント側で受信したデータと既に格納してあったデータを統合し、画像を得るというシステムが開示されている。
【００１０】
一方、特許文献２には、サーバ側に格納されているＪＰＥＧ２０００符号データをクライアント側で高速にプログレッシブ表示するための技術が開示されている。当該技術によれば、サーバは、クライアントから指定された解像度レベルのサブバンド符号データを、ファイルから取り出してクライアントに送信する。一方、クライアントは、サーバに対して所望の解像度レベルを指定するリクエストを発行し、現在表示している画像の解像度レベルの復号化されたサブバンドの係数と、サーバから受信した符号データを復号して得られたサブバンドの係数とを合わせて画像データを復元し、プログレッシブ表示を実現している。
【００１１】
しかし、上述したＦｌａｓｈｐｉｘとＪＰＥＧ２０００とでは、それぞれ使用されるタイルが大きく異なっている。すなわち、Ｆｌａｓｈｐｉｘでは、各解像度においてタイルサイズは固定の６４×６４［ｐｉｘｅｌ］であるため、解像度が低くなるほど（画像サイズが小さくなるほど）タイルの数が少なくなる。これに対して、ＪＰＥＧ２０００では、各解像度においてタイルの数が固定になるため、解像度が低く（画像サイズが小さく）なってもタイルの数は変わらない。すなわち、１２８×１２８［ｐｉｘｅｌ］の画像を表示するために、Ｆｌａｓｈｐｉｘでは４タイルを必要とし、ＪＰＥＧ２０００では１００以上のタイルが必要ということもあり得る。
【特許文献１】特開２００３−２３６３０公報
【特許文献２】特開２００４−４０６７４公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
一方、クライアント側の画面解像度は、一般的には、３２０×２４０［ｐｉｘｅｌ］程度〜２０４８×１５３６［ｐｉｘｅｌ］程度である。また、インタラクティブな操作によってサーバに格納されている画像をクライアントの表示画面に表示する際には、画面全体に表示するよりも、むしろ、ある種のビューワ（Ｖｉｅｗｅｒ）の中に表示することが多い。すなわち、画像を表示する領域は、一般的にはクライアント装置の画面よりも狭くなると考えられる。従って、クライアントは、画像全体を表示するような場合は解像度の小さいものを選択してサーバに要求し、画像の一部のみを拡大する場合には解像度の高いものを選択してサーバに要求することになる。
【００１３】
ここで、特開２００３−１７９７６０公報には、断片的に受信したデータからＪＰＥＧ２０００符号化データを作成してデコードする方法が開示されている。このような場合、各タイルの先頭をシークしてデコードすることになる。従って、表示に必要な領域が含むタイル数が多くなればなるほど、ファイルシーク回数が増加し、デコードに時間がかかるということになる。
【００１４】
そこで、ＪＰＥＧ２０００画像においては、画像全体を表示するときにタイル数が多くなる。そのため、解像度の低い（画像サイズの小さい）画像の画像全体をデコードすると、サイズが小さい（解像度が低い）画像にも関わらず、デコード時間が非常に長くかかってしまうという問題が生じる。
【００１５】
これに対して、上述した特許文献１及び特許文献２のいずれも、サーバ側に格納されているＪＰＥＧ２０００符号化データから、クライアントの要求どおりに抜き出したデータを送受信する技術が記載されているだけである。サーバ／クライアントシステムにおいて、タイルサイズをある程度小さくすることは、無駄な転送データ量を削減するという効果をもたらすが、安易にＪＰＥＧ２０００画像のタイル数を少なくすると、サーバ／クライアントにおいては扱いにくいデータとなってしまう。
【００１６】
従って、解像度が低い（画像サイズが小さい）画像のデコード時間を短縮すると共に、無駄な転送データ量を削減するようなタイル分割方法が要求されている。
【００１７】
本発明は、このような事情を考慮してなされたものであり、解像度が低いサムネイル画像等についてはタイル数が少ないデータを返送してファイルシーク回数を減少でき、拡大要求により解像度が高い画像についてはタイル数が多いデータを返送するので、必要な部分画像に好適にアクセスすることでき、無駄なデータ転送を抑えることができる画像処理方法及び画像処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、本発明は、画像を複数のタイルに分割して階層符号化された符号化データを、クライアントからの要求に応じて、サーバが断片的に送信するサーバ／クライアントシステムにおける画像処理方法であって、前記サーバが、
前記クライアントから要求された前記画像の所定領域を表示するためのリクエストを受信する受信工程と、
受信した前記リクエストを解析する解析工程と、
前記リクエストの解析結果に基づいて、前記クライアントから要求された前記画像の表示領域の画像全体に占める割合を算出する算出工程と、
前記サーバが保持している第１のタイル数で分割して階層符号化された第１の符号化データとは分割タイル数が異なる第２のタイル数で前記画像を分割して階層符号化された第２の符号化データを生成する生成工程と、
前記割合が所定値以下の場合には前記第１及び第２の符号化データのうち、より多いタイル数で前記画像が分割された符号化データを選択し、該割合が前記所定値以上の場合には前記第１及び第２の符号化データのうち、より少ないタイル数で前記画像が分割された符号化データを選択する選択工程と、
選択された前記符号化データから前記表示領域に相当する符号化データを抽出する抽出工程と、
抽出された前記符号化データを前記クライアントに送信する送信工程と
を有することを特徴とする。
【００１９】
また、上記課題を解決するために、本発明は、画像を複数のタイルに分割して階層符号化された符号化データを、他装置からの要求に応じて、断片的に送信する画像処理装置であって、
前記他装置から要求された前記画像の所定領域を表示するためのリクエストを受信する受信手段と、
受信した前記リクエストを解析する解析手段と、
前記リクエストの解析結果に基づいて、前記他装置から要求された前記画像の表示領域の画像全体に占める割合を算出する算出手段と、
第１のタイル数で分割して階層符号化された第１の符号化データを保持する保持手段と、
前記第１の符号化データとは分割タイル数が異なる第２のタイル数で前記画像を分割して階層符号化された第２の符号化データを生成する生成手段と、
前記割合が所定値以下の場合には前記第１及び第２の符号化データのうち、より多いタイル数で前記画像が分割された符号化データを選択し、該割合が前記所定値以上の場合には前記第１及び第２の符号化データのうち、より少ないタイル数で前記画像が分割された符号化データを選択する選択手段と、
選択された前記符号化データから前記表示領域に相当する符号化データを抽出する抽出手段と、
抽出された前記符号化データを前記他装置に送信する送信手段と
を備えることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、解像度が低いサムネイル画像等についてはタイル数が少ないデータを返送してファイルシーク回数を減少でき、拡大要求により解像度が高い画像についてはタイル数が多いデータを返送するので、必要な部分画像に好適にアクセスすることでき、無駄なデータ転送を抑えることができる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して、本発明に係るサーバ／クライアントシステム内における画像処理方法の好適な実施形態について具体的に説明する。
【００２２】
＜第１の実施形態＞
第１の実施形態では、既に生成済みの複数のＪＰＥＧ２０００ファイルを保有しているサーバが、クライアントからの要求を受け付けるとその要求を解析し、指定されたＪＰＥＧ２０００画像から要求に応じたレスポンスデータを作成し、クライアントに送信する方法について説明する。
【００２３】
以下では、クライアントを操作するユーザがインターネット上のあるホームページを開いて、そこに表示されているＪＰＥＧ２０００画像を取得するためのリンク情報に従ってサムネイル画像を表示し、次いで画像全体を表示し、さらに画像の一部の領域を拡大表示する動作を行う場合について説明する。そして、このような画像表示をするために、クライアントはＪＰＩＰの仕組みを使用して、サーバからデータを取得する。尚、ＪＰＩＰによるデータ送信単位をパケット（ｐａｃｋｅｔ）とする。
【００２４】
図１は、本発明の第１の実施形態に係るサーバ／クライアントシステムを実現するためのコンピュータの構成の概略を示すブロック図である。図１において、ＣＰＵ１０１は、システム全体の動作をコントロールし、一次記憶装置１０２に格納されたプログラムの実行等を行う。一次記憶装置１０２は、主にメモリであり、二次記憶装置１０３に記憶されたプログラム等を読み込んで格納する。二次記憶装置１０３は、例えばハードディスク等がこれに該当する。一般に、一次記憶装置１０２の容量は二次記憶装置１０３の容量よりも小さく、一次記憶装置１０２に格納しきれないプログラムやデータ等は二次記憶装置１０３に格納される。また、長時間記憶しなければならないデータ等も二次記憶装置１０３に格納される。本実施形態では、プログラムを二次記憶装置１０３に格納し、プログラム実行時に一次記憶装置１０２に読み込んでＣＰＵ１０１が実行処理を行うものとする。
【００２５】
一方、図１において、入力デバイス１０４は、例えば、マウスやキーボード等がこれに該当する。すなわち、入力デバイス１０４は、プログラム等に割り込み信号を送る等の操作を行うために用いる。さらに、出力デバイス１０５は、例えば、モニタやプリンタ等が該当する。尚、当該コンピュータの構成方法は他にも様々な形態が考えられるが、本発明の主眼ではないので説明を省略する。
【００２６】
図２は、本発明の第１の実施形態を実現するサーバ／クライアントシステムの概略構成を示す図である。図２において、２０１、２０２は、それぞれユーザ１、ユーザ２が操作するクライアントであり、図１で示したコンピュータを使用する。ユーザ１が使用するクライアント２０１又はユーザ２が使用するクライアント２０２は、ネットワーク２０３を介してサーバ２０４と通信することが可能である。ここで、図２では、２人のユーザのコンピュータのみがネットワーク２０３に接続されているが、それ以上のユーザのコンピュータが同様に接続されていてもよい。また、ネットワーク２０３は、有線或いは無線のいずれで実現されるネットワークであってもよい。
【００２７】
サーバ２０４は、画像ファイルを蓄積する大容量の記憶装置２０５を内蔵、或いは外部接続等が可能である。大容量の記憶装置２０５は、例えば、ハードディスク等が該当する。このハードディスクには、ＪＰＥＧ２０００符号化方式により符号化された画像データが数多く格納されている。そして、クライアント２０１のユーザ１やクライアント２０２のユーザ２は、サーバ２０４が管理（或いは、格納）しているＪＰＥＧ２０００画像データから、断片化されたデータを受信し、保存する。
【００２８】
図３は、一般的なＪＰＥＧ２０００の符号化データの構成を説明するための図である。ＪＰＥＧ２０００符号化データは、「メインヘッダ（Ｍａｉｎ  Ｈｅａｄｅｒ）３０１」と呼ばれる画像全体の符号化条件について記述されたデータを先頭部分に保持しており、その後に、タイルデータが並んでいる。タイルデータは、「タイルヘッダ（Ｔｉｌｅ  Ｈｅａｄｅｒ）３０２」と呼ばれるタイルの符号化条件を記述したヘッダデータを保持しており、その後にタイルの符号化データを構成する「パケット（ｐａｃｋｅｔ）３０３」と呼ばれる符号化単位データを保持している。尚、図３で記されている「Ｐｏｓｉｔｉｏｎ」とは、ＪＰＥＧ２０００符号化データにおけるｐｒｅｃｉｎｃｔのことである。
【００２９】
図４は、画像における解像度（画像サイズ）とＲｅｓｏｌｕｔｉｏｎ番号との関係を示すＪＰＥＧ２０００の解像度スケーラビリティを示す図である。図４に示すように、最も小さい解像度の画像のＲｅｓｏｌｕｔｉｏｎ番号を０とし、Ｒｅｓｏｌｕｔｉｏｎ番号が一つ増加するごとに画像の幅と高さが２倍になる。また、各Ｌａｙｅｒ内は、Ｒｅｓｏｌｕｔｉｏｎ番号の小さい順にデータが格納されている。ここで、Ｌａｙｅｒ番号は、復元する画像の原画に対するＳ／Ｎ比に対応し、Ｌａｙｅｒ番号が小さいほどＳ／Ｎ比が悪くなる。尚、一つのＪＰＥＧ２０００ファイル内でのＲｅｓｏｌｕｔｉｏｎ番号とＬａｙｅｒ番号、Ｃｏｍｐｏｎｅｎｔ番号の最大値は、エンコーダによって予め設定され、そのパラメータに従ってエンコードされており、その情報は符号化データの中に格納されている。
【００３０】
上述したようなＪＰＥＧ２０００符号化データを用いることで、ユーザは、サーバにある全ての画像データを取得せず、必要な部分のデータのみをサーバから受信することが可能である。尚、ユーザの受信データの単位としては、ＪＰＥＧ２０００のｐａｃｋｅｔ、或いはｐａｃｋｅｔよりも大きい符号化単位であるタイル単位が考えられる。本実施形態では、ユーザがサーバから受信するデータ単位として、上述したようにｐａｃｋｅｔ単位を想定する。
【００３１】
図５は、サーバ／クライアント間での通信プロトコルをＰａｃｋｅｔ単位のリクエスト及びレスポンスの関係を用いて説明するための概念図である。すなわち、ユーザが、クライアント５０１からサーバ５０２に対し、画像のタイル番号とＲｅｓｏｌｕｔｉｏｎ  ＬｅｖｅｌとＬａｙｅｒ、Ｃｏｍｐｏｎｅｎｔ、Ｐｏｓｉｔｉｏｎ番号を指定して、データを要求する。これに対し、サーバ５０２は、画像５０３のコードストリームを解析して、指定されたタイル番号、Ｒｅｓｏｌｕｔｉｏｎ  ＬｅｖｅｌとＬａｙｅｒ、Ｃｏｍｐｏｎｅｎｔ、Ｐｏｓｉｔｉｏｎ番号に相当するｐａｃｋｅｔデータを抜き出し、クライアント５０１に送り返す。
【００３２】
次に、ＪＰＩＰを使ってｐａｃｋｅｔデータを送信単位として、データを送受信する場合のレスポンスデータの構成を、図６及び図７を参照して説明する。図６は、Ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎの概念図である。また、図７は、ＪＰＩＰレスポンスデータの概念図である。
【００３３】
ＪＰＩＰでは、図６に示すように、「ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ」と呼ばれるＪＰＥＧ２０００のｐａｃｋｅｔデータの塊を基本としてレスポンスデータ６０１を作成する。ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎとは、Ｔｉｌｅ  ｔｎの中のｐｒｅｃｉｎｃｔ  ｐｎのＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ｒｎ、Ｃｏｍｐｏｎｅｎｔ番号ｃｎを構成する全てのＬａｙｅｒのＰａｃｋｅｔを、Ｌａｙｅｒ番号が昇順になるように並べて連結したデータの塊である。
【００３４】
図７には、図６に示すｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎから抜き出したＰａｃｋｅｔ（ｔｎ，ｒｎ，ｃｎ，ｐｎ，１）を使って作成されたＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａの例を示す。ＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａは、ｍｅｓｓａｇｅ  ｈｅａｄｅｒ７０１と  ｍｅｓｓａｇｅ  ｂｏｄｙ７０３とから構成される。
【００３５】
ｍｅｓｓａｇｅ  ｂｏｄｙ７０３には、ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ６０１から切り出されたＪＰＥＧ２０００符号化データが入る。すなわち、図６に示すＰａｃｋｅｔ（ｔｎ，ｒｎ，ｃｎ，ｐｎ，１）６０３を抜き出してＪＰＩＰ  ｒｅｓｐｏｎｓｅ  ｄａｔａを作成すると、Ｐａｃｋｅｔ（ｔｎ，ｒｎ，ｃｎ，ｐｎ，１）６０３がｍｅｓｓａｇｅ  ｂｏｄｙ７０３に入る。
【００３６】
また、ｍｅｓｓａｇｅ  ｈｅａｄｅｒ７０１は、４つのパラメータから構成されている。１番最初のパラメータは、ｍｅｓｓａｇｅ  ｂｏｄｙ７０３に入っているデータがｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎであることを示す識別子が入る。次いで、２番目のパラメータには、ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ  ＩＤ（ＰｒＩＤ）が入る。これは、タイル番号ｔｎ，Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ番号ｒｎ，ｃｏｍｐｏｎｅｎｔ番号ｃｎ，ｐｒｅｃｉｎｃｔ番号ｐｎから一意に決まり、次式で求めることができる。
【００３７】
ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）＝ｔｎ＋（ｃｎ＋ｓ×（ｃｏｍｐｏｎｅｎｔ数））×ｔｉｌｅ数    ・・・・・  （１）
但し、
ｓ＝ｐｎ＋ｔｎ×ｐ（ｒｎ）＋ｐ（ｔｒ）、
ｐ（ｒｎ）：Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ｒｎにおける１ｔｉｌｅあたりのｐｒｅｃｉｎｃｔ数、
ｐ（ｔｒ）：Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ０から（ｒｎ−１）までのＴｉｌｅ  ｔｒのｐｒｅｃｉｎｃｔ数の総和、
である。
【００３８】
さらに、３番目のパラメータは、レスポンスデータのｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎにおけるオフセット値ＰｒＯｆｆｓｅｔ６０２である。すなわち、ｍｅｓｓａｇｅ  ｂｏｄｙ７０３に入っているデータは、ＰｒＩＤ（ｔｎ，ｒｎ，ｃｎ，ｐｎ）のｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎ６０１において何Ｂｙｔｅ目からのデータであるのかを示す値であり、図６のＰｒＯｆｆｓｅｔ６０２の値と同じである。そして、ｍｅｓｓａｇｅ  ｈｅａｄｅｒ７０１の最後のパラメータは、ｒｅｓｐｏｎｓｅ  ｄａｔａ、すなわちｍｅｓｓａｇｅ  ｂｏｄｙ７０３のバイト長である。従って、ＲｅｓＬｅｎ７０２には、ＲｅｓＬｅｎ［ｂｙｔｅ］７０４の値が入ることとなる。
【００３９】
本実施形態では、サーバは、ランダムアクセス性を考慮して、タイルによる画像の分割数を多くしたＪＰＥＧ２０００画像データを保持しているものとする。尚、サーバが保持しているＪＰＥＧ２０００画像データは、
最大画像サイズ：４０６４×２７５２［ｐｉｘｅｌ］
タイルサイズ：１２８×１２８［ｐｉｘｅｌ］
タイル数：７０４（＝３２×２２）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ数：５
各Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌの画像サイズ：
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ４：４０６４×２７５２［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：１２８×１２８［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ３：２０３２×１３７６［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：６４×６４［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ２：１０１６×６８８［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：３２×３２［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ１：５０８×３４４［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：１６×１６［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ０：２５４×１７２［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：８×８［ｐｉｘｅｌ］）
のエンコード条件であるとする。
【００４０】
図８は、サーバが保持するＪＰＥＧ２０００画像の構成を示す概念図である。図８に示すように、Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ０〜４の全ての画像において、画像は７０４タイルに分割されているが、それぞれのタイルには左上からシーケンシャルにタイル番号がついている。尚、図９は、サーバに保持されている画像のタイルとタイル番号との関係を示す図である。図９において、画像９０１で示すタイルは初期状態のタイルを示しており、全部で７０４タイルに分かれている。また、画像９０２に示すタイルは４つのタイルを１タイルに変換した１７６タイルを示すものである。
【００４１】
本実施形態におけるサーバは、クライアントからの要求を解析して、要求されている表示領域が画像全体に占める割合を計算する。そして、当該サーバは、その値（占める割合）とあらかじめ決められたしきい値とを比較し、しきい値よりも大きい場合（すなわち、表示領域の画像全体に占める割合が大きい場合）は、タイル数を削減（タイルサイズを大きく）したコードストリームを作成し（例えば、画像９０２）、作成されたコードストリームから画像データをクライアントに返送する。
【００４２】
一方、要求された表示領域の画像全体に占める割合が上記しきい値よりも小さい場合、すなわち表示領域の画像全体に占める割合が小さい場合には、オリジナルの符号化データ（例えば、画像９０１）から画像データをクライアントに返送する。また、どちらの場合においても、オリジナルのタイル数を持つコードストリームとタイル数が削減されたコードストリームの両方に、異なる識別子を割り当てておき、その両方の識別子、どちらのコードストリームから画像データが返送されたかを示す値、及び判定に使われたしきい値とをクライアントに通知するようにする。
【００４３】
本実施形態におけるクライアントは、表示したい画像のデータのファイル名をＪＰＩＰで指定し、ＪＰＥＧ２０００にリクエストする。その後、サーバからの返送データを受信したクライアントは、返送データをキャッシュすると共に、返送データを解析して、上述した２つの識別子を取得する。そして、クライアントは、その後の通信において、自装置からの表示要求に応じて、２つの識別子を使い分けて要求をサーバに発行する。
【００４４】
以下では、上述したようなサーバとクライアントの動作について、それぞれ図面を参照して説明する。
【００４５】
≪サーバの動作≫
まず、本実施形態におけるサーバの動作の詳細について説明する。図１０は、本発明の第１の実施形態におけるサーバ２０４の動作を説明するためのフローチャートである。
【００４６】
まず、サーバ２０４は、クライアント（クライアント２０１等）からのリクエスト文字列を受信する（ステップＳ１００１）。本実施形態では、以下に示すような、サムネイル画像取得のためのリクエストを受信したものとする。
【００４７】
http://www.image.com/jpip.cgi?target=sample.jp2&fsiz=320,240&type=jpp-stream
尚、上記リクエスト文字列は、ｔａｒｇｅｔによって要求するファイル名を、ｆｓｉｚによって画像全体の大きさを、ｔｙｐｅによって返送データ形式を指定している。
【００４８】
次いで、サーバ２０４は、ステップＳ１００１で受信したリクエスト文字列を解析する（ステップＳ１００２）。これにより、要求されている画像ファイルの名前、返送データ形式、及び表示したい画像の条件等を知ることができる。尚、本実施形態の場合、ｓａｍｐｌｅ．ｊｐ２という画像ファイルを、画像全体が３２０×２４０［ｐｉｘｅｌ］に収まるサイズで要求しており、その返送データ形式はＪＰＩＰのｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎであると解析することができる。
【００４９】
そして、サーバ２０４は、要求された表示領域の画像全体に占める割合ｐｃｔを算出する（ステップＳ１００３）。本実施形態の場合、３２０×２４０［ｐｉｘｅｌ］の画像の中の３２０×２４０［ｐｉｘｅｌ］の領域、すなわち、画像全体を要求しているので、ｐｃｔ＝１００となる。
【００５０】
さらに、サーバ２０４は、要求された画像のオリジナル符号化データに対する識別子ＩＤｍと、タイル数を削減した符号化データに対する識別子ＩＤｄを取得する（ステップＳ１００４）。尚、これらの識別子のつけ方については、オリジナルファイル名に基づいてあらかじめ用意した文字列としたり、リクエストやクライアントに基づいて作成した文字列としたりすることが考えられるが、本発明の主眼ではないのでここでは説明を省略する。本実施形態の場合、オリジナル符号化データに対する識別子ＩＤｍをｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４とし、タイル数が削減された符号化データに対する識別子ＩＤｄをｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６とする。
【００５１】
次いで、サーバ２０４は、ステップＳ１００３で求めた要求表示領域の画像全体に占める割合ｐｃｔとしきい値Ｔｈとの大きさを比較する（ステップＳ１００５）。その結果、しきい値Ｔｈよりも割合ｐｃｔの値の方が大きい場合（Ｙｅｓ）はステップＳ１００６へ進み、しきい値Ｔｈよりも割合ｐｃｔの値の方が小さい場合（Ｎｏ）はステップＳ１００８に進む。尚、ステップＳ１００８において、サーバ２０４は、返送データ作成用符号化データの識別子ＩＤｔにオリジナルの符号化データを示す識別子ＩＤｍをセットし、ステップＳ１００９に進む。
【００５２】
本実施形態では、しきい値Ｔｈを例えば２５とする。すなわち、要求表示領域が画像全体の４分の１より大きい場合はステップＳ１００６へ進み、４分の１以下であればステップＳ１００８へ進むようにする。従って、画像全体を要求している本実施形態のリクエストは、ｐｃｔ（＝１００）＞Ｔｈ（＝２５）となるので、ステップＳ１００６へ処理を進めることになる。
【００５３】
ステップＳ１００６において、サーバ２０４は、返送データ作成用符号化データの識別子ＩＤｔにタイル数を削減した符号化データを示す識別子ＩＤｄをセットする。そして、サーバ２０４は、タイル数を削減した符号データＣｄをオリジナルの符号データから作成する（ステップＳ１００７）。ここで作成される符号化データは、タイルサイズ以外のエンコード条件、すなわち、Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ数、ｂｉｔ深さ、ｌａｙｅｒ数等は、オリジナルの符号化データと同じとする。尚、ステップＳ１００４で取得した識別子ＩＤｄは、ここで作成される符号データに対応する識別子である。
【００５４】
本実施形態では、隣接する４枚のタイルから１枚のタイルを作成することで、タイル数を４分の１に削減したコードストリームＣｄを作成する。すなわち、図９の画像９０１のタイル０、１、３２、３３をデコードし、その結果を１タイルとし、オリジナルの符号化データのタイルサイズを１２８×１２８から２５６×２５６にし、その他のエンコード条件は同じでエンコードする。同様に、画像９０２のタイル２、３、３４、３５の４タイルから１タイルを生成し、順に、画像全体の符号化データを作成し直す。そして、最終的に、図９の画像９０２に示すように、１７６枚のタイルに分割された符号化データＣｄが作成される。
【００５５】
ステップＳ１００９では、サーバ２０４は、識別子ＩＤｔの符号化データからステップＳ１００２の解析によって得られた結果に基づいて、要求表示領域のデータを抜き出す。尚、このデータの抜き出し方法については、図１１を用いて後述する。次いで、サーバ２０４は、ＪＰＩＰのレスポンスデータを作成する（ステップＳ１０１０）。尚、ステップＳ１０１０の詳細については、図１２を用いて後述する。
【００５６】
さらに、サーバ２０４は、ステップＳ１０１０で作成したレスポンスデータ、すなわち、ＪＰＩＰレスポンスヘッダ、ＪＰＩＰ  ｍｅｓｓａｇｅ、及び、本発明に対応した情報ヘッダをクライアントに送信し（ステップＳ１０１１）、処理を終了する。
【００５７】
図１１は、第１の実施形態におけるサーバ２０４の返送データ抜き出し処理（ステップＳ１００９）の細部処理手順を説明するためのフローチャートである。まず、サーバ２０４は、ステップＳ１００２で解析したリクエストにｔａｒｇｅｔ  ＩＤ（コードストリーム識別子）の指定が含まれていたかどうかを判定する（ステップＳ１１０１）。その結果、指定が含まれていると判定された場合（Ｙｅｓ）はステップＳ１１０２へ進み、指定が含まれていないと判定された場合（Ｎｏ）はステップＳ１１０５へ進む。
【００５８】
上記サーバ２０４の判定は、具体的には、ｔｉｄフィールドがリクエストに含まれており、かつ、その値が０でなければ、ｔａｒｇｅｔ  ＩＤ（コードストリーム識別子）の指定が含まれていると判定する。一方、ｔｉｄフィールドの値が０の時は、返送データを抜き出したコードストリームのｔａｒｇｅｔ  ＩＤ（すなわち、コードストリーム識別子）を返送時にクライアントに通知することを求める要求であるため、ｔａｒｇｅｔ  ＩＤの値が指定されていないとみなす。また、ｔｉｄフィールドがリクエスト中に無い場合も、サーバ２０４は、コードストリーム識別子の指定が無いものと判定する。本実施形態の場合、ｔａｒｇｅｔ  ＩＤ（コードストリーム識別子）の指定はリクエストに含まれていないので、ステップＳ１１０５に進むこととなる。
【００５９】
ステップＳ１１０５では、サーバ２０４は、クライアントのキャッシュ情報を使用することなく、識別子ＩＤｔのコードストリームからデータを抜き出す。すなわち、サーバ２０４は、ｐａｃｋｅｔデータやタイルデータの他に、ｍａｉｎ  ｈｅａｄｅｒやｔｉｌｅ  ｈｅａｄｅｒも抜き出すことになる。尚、クライアントのキャッシュ情報の取得は、リクエストの解析によって得られる。具体的には、ｎｅｅｄフィールド、ｍｏｄｅｌフィールド、ｔｐｎｅｅｄフィールド、ｔｐｍｏｄｅｌフィールドのいずれかを含む場合には、今回要求した表示領域に関するクライアントのキャッシュ情報をサーバ２０４は知ることができる。そして、ステップＳ１１０５の処理を終了すると、前述したステップＳ１０１０に進む。
【００６０】
ここで、ステップＳ１１０１において、ｔａｒｇｅｔ  ＩＤ（コードストリーム識別子）の指定がリクエストに含まれている判断された場合（Ｙｅｓ）は、ステップＳ１１０２へ進むこととなる。そして、ステップＳ１１０２では、リクエスト内で指定されているｔａｒｇｅｔ  ＩＤが返送データを抜き出す対象となっているコードストリームの識別子ＩＤｔと同一であるか否かを判定する。その結果、指定されたｔａｒｇｅｔ  ＩＤがＩＤｔと一致する場合（Ｙｅｓ）はステップＳ１１０３へ進み、一致しない場合（Ｎｏ）は前述のようにステップＳ１１０５へ進む。
【００６１】
ステップＳ１１０３では、ステップＳ１００２のリクエスト解析からクライアントのキャッシュ情報を取得する。そして、サーバ２０４は、ステップＳ１１０３で取得されたクライアントのキャッシュ情報と、ステップＳ１００２の解析で得られた画像の表示要求とを比較して、クライアント側にキャッシュされていない画像データを識別子ＩＤｔのコードストリームから抜き出す（ステップＳ１１０４）。
【００６２】
尚、ステップＳ１１０５におけるキャッシュ情報を使用せずにデータを抜き出す処理も、ステップＳ１１０４におけるキャッシュされていないデータのみを抜き出す処理も、通常のＪＰＩＰサーバの処理と同様であるので、ここでの説明は省略する。尚、本実施形態の場合、画像全体のサイズが２５４×１７２［ｐｉｘｅｌ］であるＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ０のデータが抜き出されることとなる。
【００６３】
図１２は、第１の実施形態におけるサーバ２０４のレスポンスデータの作成処理（ステップＳ１０１０）の細部処理手順を説明するためのフローチャートである。サーバ２０４は、まず、クライアントからのリクエストにターゲットＩＤのフィールド、具体的にはｔｉｄフィールドが含まれていたかどうかを判定する（ステップＳ１２０１）。その結果、含まれている場合（Ｙｅｓ）はステップＳ１２０２へ進み、含まれていない場合（Ｎｏ）はステップＳ１２０３に進む。尚、この判定は、ステップＳ１００２の解析結果に基づいて行う。
【００６４】
ステップＳ１２０２において、サーバ２０４は、リクエストのターゲットＩＤと返送用データ作成用の符号化データの識別子ＩＤｔとを比較する。その結果、同じであると判定された場合はステップＳ１２０４へ進み、異なると判定された場合（Ｎｏ）はステップＳ１２０３へ進む。
【００６５】
ステップＳ１２０３において、サーバ２０４は、ターゲットＩＤ用のレスポンスヘッダ、具体的には、ＪＰＩＰ−ｔｉｄヘッダに識別子ＩＤｔを書き込み、ステップＳ１２０４に進む。すなわち、リクエストに含まれるターゲットＩＤが識別子ＩＤｔと一致するときのみ、ＪＰＩＰ−ｔｉｄヘッダを作成しなくても良い。
【００６６】
本実施形態では、クライアントからのリクエストにｔｉｄフィールドが含まれていないので、ステップＳ１２０１の分岐からステップＳ１２０３へ進み、
ＪＰＩＰ−ｔｉｄ：ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６
で示されるＪＰＩＰレスポンスヘッダが作成される。
【００６７】
次に、ステップＳ１２０４において、サーバ２０４は、ターゲットＩＤのＪＰＩＰレスポンスヘッダ（ＪＰＩＰ−ｔｉｄ）以外のＪＰＩＰレスポンスヘッダを作成する。すなわち、サーバ２０４は、ステップＳ１００２の解析で得られたリクエストのパラメータと、ステップＳ１００９で抜き出したデータの値が異なるものに対しては、ＪＰＩＰレスポンスヘッダを作成する。尚、この動作は通常のＪＰＩＰサーバと同様であるため、詳しい説明は省略する。
【００６８】
本実施形態では、
ＪＰＩＰ−ｆｓｉｚ：２５４，１７２
ＪＰＩＰ−ｒｓｉｚ：２５４，１７２
で示されるＪＰＩＰレスポンスヘッダが作成される。
【００６９】
上記ＪＰＩＰレスポンスヘッダの１行目は、返送画像データの画像全体のサイズを示しており、リクエストによって指定された３２０×２４０と異なるために記述されている。また、ＪＰＩＰレスポンスヘッダの２行目は、返送データ領域の大きさを示しており、リクエストで指定されたデータ領域３２０×２４０と異なるために記述されている。
【００７０】
次いで、ステップＳ１２０５において、サーバ２０４は、しきい値Ｔｈとレスポンスデータの作成に使われなかったコードストリームの識別子から、
ａｎｏｔｈｅｒ−ｔｉｄ：ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４
ｔｈｒｅｓｈｏｌｄ：２５
で示される情報ヘッダを作成する。
【００７１】
上記情報ヘッダの１行目は、今回のレスポンスデータ作成に使われなかったコードストリームの識別子を記述している。すなわち、本実施形態においては、オリジナルの符号化データの識別子ＩＤｍがそれに相当する。また、本実施形態とは逆に、オリジナル符号化データから返送データが抜き出された場合には、識別子ＩＤｄを記述することになる。また、情報ヘッダの２行目は、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６とｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４とを切り替えるしきい値を記述している。
【００７２】
次いで、ステップＳ１２０６において、サーバ２０４は、ステップＳ１００９で抜き出された画像データから図７に示すＪＰＩＰ  ｍｅｓｓａｇｅの形式のデータを作成してこの処理フローを終了する。尚、このＪＰＩＰ  ｍｅｓｓａｇｅ作成の動作も、通常のＪＰＩＰサーバの動作と同様であるため、細部説明は省略する。
【００７３】
上述したように、本実施形態のステップＳ１２０６において、サーバ２０４は、ステップＳ１００７で抜き出された符号化データを、ｊｐｐ−ｓｔｒｅａｍの形式に変更し、図７に示すＪＰＩＰ  ｍｅｓｓａｇｅの形式のデータを作成する。すなわち、サーバ２０４は、ステップＳ１００９で抜き出された画像データから図７に示すＪＰＩＰ  ｍｅｓｓａｇｅの形式のデータを作成し、さらに、ＪＰＩＰの定義に従ってＪＰＩＰレスポンスヘッダを作成し、さらに、情報ヘッダを作成する。
【００７４】
この際、ＪＰＩＰレスポンスヘッダの方には、画像データを抜き出したコードストリームに対応する識別子を記述する。一方、情報ヘッダの方には、今回画像データを抜き出さなかったコードストリームの識別子と、しきい値を記述する。従って、本実施形態の場合、図１２を用いて説明した処理フローにより、
ＪＰＩＰ−ｔｉｄ：ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６
ＪＰＩＰ−ｆｓｉｚ：２５４，１７２
ＪＰＩＰ−ｒｓｉｚ：２５４，１７２
ａｎｏｔｈｅｒ−ｔｉｄ：ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４
ｔｈｒｅｓｈｏｌｄ：２５
［ｊｐｐ−ｓｔｒｅａｍによるｂｉｎａｒｙ  ｄａｔａ］
で示されるようなレスポンスデータが作成される。
【００７５】
以上、説明したように、本実施形態に係るサーバ２０４は、クライアントからのリクエストのｔｉｄフィールドを検証し、ｔｉｄフィールドが含まれていない場合には、クライアントがどのコードストリームから返送されるのか分からない状態であると判断して、表示に必要なデータを全て返送する。
【００７６】
また、サーバ２０４は、リクエストにｔｉｄフィールドが含まれているが、サーバが返送用コードストリームとして設定したコードストリームの識別子と異なる識別子をクライアントが指定した場合、クライアントがリクエストによってサーバに通知したクライアント側のキャッシュデータが、返送データのコードストリームとは異なるコードストリームから抜き出したものであると判断し、そのキャッシュデータを使わずに、表示に必要なデータを全て返送する。さらに、サーバ２０４は、リクエストに指定されたｔｉｄとサーバ返送用コードストリームとして設定したコードストリーム識別子とが同一である場合に限り、クライアントからのキャッシュデータの通知を有効とし、クライアントがキャッシュしていないと判断できる部分の画像データを抜き出す。
【００７７】
また、本実施形態に係るサーバ／クライアントシステムに対応していないクライアントが、上述したような返送データを受け取った場合でも、上述した情報ヘッダを認識できない拡張ＨＴＴＰ  ｅｎｔｉｔｙヘッダとして無視することができる。また、ＪＰＩＰ−ｔｉｄレスポンスヘッダによって示されるコードストリーム識別子が、それ以前に返送されたコードストリーム識別子と異なる場合には、クライアントはそれまでのキャッシュを捨て、新しく受信したデータによって表示することになる。その場合、サーバからの返送データには、ｍａｉｎ  ｈｅａｄｅｒを含む表示に必要なデータを全てが含まれているので、クライアント側で要求した表示条件によって画像を表示できないということはない。
【００７８】
≪クライアントの動作≫
次に、本実施形態におけるクライアント（図２のクライアント２０１又はクライアント２０２）の動作の詳細について説明する。図１３は、本発明の第１の実施形態におけるクライアントのリクエスト発行手順を説明するためのフローチャートである。サーバとクライアントの間では、事前にコードストリームが切り替わるしきい値についての取り決めはなく、クライアントは、ｓａｍｐｌｅ．ｊｐ２への初めてのアクセスであり、３２０×２４０［ｐｉｘｅｌ］程度のサイズで画像全体を表示するための要求をクライアントが発行すると仮定する。
【００７９】
まず、クライアントは、ユーザによる表示要求を取得する（ステップＳ１３０１）。すなわち、クライアントは、表示したい画像の名前、画像全体の大きさ、表示したい部分領域等を取得する。本実施形態の場合、画像名はｓａｍｐｌｅ．ｊｐ２であり、表示したい画像全体の大きさは３２０×２４０［ｐｉｘｅｌ］程度のサイズであり、表示したい領域は画像全体である。
【００８０】
次いで、クライアントは、ステップＳ１３０１で取得した画像ファイルに対応するしきい値Ｔｈを取得する（ステップＳ１３０２）。そして、しきい値Ｔｈが取得できた場合（Ｙｅｓ）はステップＳ１３０３へ進み、取得できなかった場合（Ｎｏ）はステップＳ１３０６へ進む。尚、本実施形態の場合、ｓａｍｐｌｅ．ｊｐ２へのアクセスが初めてであり、サーバとクライアントの間で事前にしきい値Ｔｈが決められていないので、ステップＳ１３０６へ進む。
【００８１】
ステップＳ１３０６において、クライアントは、要求コードストリームの識別子ＩＤｑに０を設定する。次に、クライアントは、対応キャッシュデータがあるかどうかを判断する（ステップＳ１３０７）。その結果、対応キャッシュデータがあると判断された場合（Ｙｅｓ）はステップＳ１３０８へ進み、対応キャッシュデータがないと判断された場合（Ｎｏ）はステップＳ１３１０へ進む。尚、本実施形態の場合、ｓａｍｐｌｅ．ｊｐ２への初めてのアクセスであるので、キャッシュデータは存在せずにステップＳ１３１０へ進む。
【００８２】
ステップＳ１３１０において、クライアントは、ステップＳ１３０１で得られたユーザの表示要求とキャッシュデータを参照した結果からリクエストを作成する。尚、このリクエスト文字列の作成は、通常のＪＰＩＰクライアントの動作であるため、詳しい動作についての説明は省略する。
【００８３】
本実施形態において作成されるリクエスト文字列は、
http://www.image.com/jpip.cgi?target=sample.jp2&fsiz=320,240&type=jpp-stream&tid=0
で示される。
【００８４】
その後、クライアントは、ステップＳ１３１０で作成したリクエストをサーバ２０４に送出し（ステップＳ１３１１）、本リクエスト発行フローを終了する。  次に、クライアントは、既に、Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ０で画像全体を表示しており、そのデータを保存しているものとする。図１４は、本発明の第１の実施形態におけるサムネイル取得後のクライアントのキャッシュデータの一例を示す概念図である。以下では、図１４に示すようなキャッシュデータをクライアントが保存した上で、５１２×５１２［ｐｉｘｅｌ］の領域に画像の左上の領域をＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ２で表示する場合を想定して説明する。
【００８５】
そして、上述したように、クライアントはしきい値Ｔｈ（＝２５）を取得し（ステップＳ１３０２）、ステップＳ１３０３に進む。尚、クライアントは、サーバ２０４と通信を行った際に取得した情報ヘッダを解析することで、容易にしきい値Ｔｈを知ることができる。そして、ステップＳ１３０３において、クライアントは、しきい値Ｔｈとコードストリーム識別子との対応関係を取得する。その結果、対応関係が取得できた場合（Ｙｅｓ）はステップＳ１３０４へ進み、取得できなかった場合（Ｎｏ）はステップＳ１３０６へ進む。尚、この対応関係を取得する方法については、図１５に示すクライアントにおける返送データ受信手順のフローチャートを用いて後述する。
【００８６】
本実施形態において、クライアントは、しきい値Ｔｈ（＝２５）よりも表示領域の画像全体に占める割合ｐｃｔが大きい場合には、要求すべきコードストリームの識別子はｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６であり、小さい場合にはｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４である、という対応関係を取得することができる。
【００８７】
そして、ステップＳ１３０４において、クライアントは、ステップＳ１３０１で取得したユーザの表示要求から、表示したい領域が画像全体に占める割合ｐｃｔを算出する。本実施形態の場合、Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ２のサイズが１０１６×６８８［ｐｉｘｅｌ］であり、表示したい領域はその左上部分の領域５１２×５１２［ｐｉｘｅｌ］であるので、
ｐｃｔ＝１００×（５１２×５１２）／（１０１６×６８８）＝３７．５
が得られる。
【００８８】
次いで、クライアントは、ステップＳ１３０４で算出された表示領域の割合ｐｃｔとステップＳ１３０２で取得したしきい値Ｔｈとを比較して、その結果とステップＳ１３０３で取得したしきい値Ｔｈとコードストリーム識別子との対応関係から、要求すべきコードストリームの識別子ＩＤｑを取得する（ステップＳ１３０５）。尚、本実施形態では、ｐｃｔ（＝３７．５）＞Ｔｈ（＝２５）であるため、要求すべきコードストリームの識別子ＩＤｑは、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６となる。
【００８９】
次いで、クライアントは、対応するキャッシュデータが存在するか否かを特定する（ステップＳ１３０７）。その結果、存在することが特定できた場合（Ｙｅｓ）はステップＳ１３０８へ進み、存在しないことが特定できた場合（Ｎｏ）はステップＳ１３１０へ進む。
【００９０】
本実施形態では、ステップＳ１３０５で特定された識別子ＩＤｑは、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６であるので、ステップＳ１３０７では、この識別子に対応するキャッシュデータが存在するかを特定する。ここで、クライアントは、既にＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ０で画像全体を表示する際に、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６を識別子として持つコードストリームからのデータを受信しているので、図１４に示すようなキャッシュデータ１４０１が存在する。そのため、ステップＳ１３０７の判定では、ステップＳ１３０８に進むこととなる。
【００９１】
ステップＳ１３０８において、クライアントは、対応キャッシュデータを参照してステップＳ１３０１で取得された表示要求と比較し、不足データを特定する。本実施形態の場合、キャッシュには図１４に示すキャッシュデータ１４０１が存在している。さらに、ユーザは、５１２×５１２［ｐｉｘｅｌ］の領域に画像の左上の領域をＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ２で表示する、すなわち、タイル０、１、１６、１７の画像をＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ２で表示するので、特定された不足データは、タイル０、１、１６、１７の４タイルのＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  １及びＲｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ  ２であることがわかる。
【００９２】
次いで、クライアントは、ステップＳ１３０８の処理で特定された不足データがあるか否かを判断する（ステップＳ１３０９）。その結果、不足データがあると判断された場合（Ｙｅｓ）はステップＳ１３１０へ進み、不足データがないと判断された場合（Ｎｏ）は、キャッシュデータのみでユーザの表示要求を満たすことができるので、この処理を終了する。尚、ステップＳ１３１０及びそれに続くステップＳ１３１１での処理は上述した通りであるので、ここでの説明は省略する。
【００９３】
従って、図１３に示す処理フローを経て、本実施形態に係るクライアントは、  http://www.image.com/jpip.cgi?target=sample.jp2&tid=sample_derive_176&fsiz=1016,688&rsiz=512,512&need=r1-2&type=jpp-stream
で示されるようなリクエストをサーバ２０４に送信することになる。
【００９４】
次に、サーバ２０４からのレスポンスデータを受信したクライアントの動作について説明する。図１５は、本発明の第１の実施形態に係るクライアントのデータ受信処理手順を説明するためのフローチャートである。
【００９５】
クライアントは、ｓａｍｐｌｅ．ｊｐ２への初めてのアクセスであり、３２０×２４０［ｐｉｘｅｌ］程度のサイズで画像全体を表示するための要求を発行する。そして、以下では、
ＪＰＩＰ−ｔｉｄ：ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６
ＪＰＩＰ−ｆｓｉｚ：２５４，１７２
ＪＰＩＰ−ｒｓｉｚ：２５４，１７２
ａｎｏｔｈｅｒ−ｔｉｄ：ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４
ｔｈｒｅｓｈｏｌｄ：２５
［ｊｐｐ−ｓｔｒｅａｍによるｂｉｎａｒｙ  ｄａｔａ］
で示される返送データがサーバ２０４から送信されてきた場合について説明する。
【００９６】
クライアントは、サーバ２０４から送信されてきた上記返送データを受信する（ステップＳ１５０１）。次いで、クライアントは、受信データに含まれているＪＰＩＰレスポンスヘッダを解析して、どのような画像データが送られてきたのかを認識する（ステップＳ１５０２）。尚、ＪＰＩＰレスポンスヘッダの解析及び解釈は、通常のＪＰＩＰクライアントと同様の動作であるので、ここでの詳しい説明は省略する。
【００９７】
本実施形態では、ステップＳ１５０２の解析によって、返送画像データが、２５４×１７２［ｐｉｘｅｌ］サイズの画像の全体であることが分かる。さらに、その返送データを抜き出したコードストリームのＩＤ（識別子）は、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６であることが分かる。
【００９８】
次いで、クライアントは、ステップＳ１５０２の解析から返送データのコードストリーム識別子ＩＤｇを取得する（ステップＳ１５０３）。本実施形態の場合、コードストリーム識別子ＩＤｇはｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６となる。
【００９９】
さらに、クライアントは、しきい値Ｔｈとコードストリーム識別子との対応関係を、当該クライアントが既に保存しているかどうかを判定する（ステップＳ１５０４）。その結果、対応関係を保存していると判定された場合（Ｙｅｓ）はステップＳ１５０８へ進み、保存していないと判定された場合（Ｎｏ）はステップＳ１５０５へ進む。ここで、本実施形態では、クライアントは、ｓａｍｐｌｅ．ｊｐ２に対して初めてのアクセスであり、しきい値Ｔｈとコードストリーム識別子との対応関係を保存していないものとし（ステップＳ１５０４でＮｏ）、ステップＳ１５０５へ進むものとする。
【０１００】
ステップＳ１５０５において、クライアントは、返送データに含まれる情報ヘッダを解析する。本実施形態の場合、「ａｎｏｔｈｅｒ−ｔｉｄ：ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４」より、今回の返送データ作成に使われなかったｓａｍｐｌｅ．ｊｐ２のコードストリームに付けられた識別子がｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４であり、「ｔｈｒｅｓｈｏｌｄ：２５」より、コードストリームの切り替えは、画像全体に占める表示領域の割合が２５％を境界として、２つのコードストリーム「ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４」と「ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６」とが切り替わることが分かる。
【０１０１】
次いで、クライアントは、ステップＳ１５０１で得られるＪＰＩＰレスポンスヘッダの解析結果から、画像全体に占める表示領域の割合ｐｃｔを算出する（ステップＳ１５０６）。本実施形態の場合、ＪＰＩＰレスポンスヘッダ「ＪＰＩＰ−ｆｓｉｚ：２５４，１７２」と「ＪＰＩＰ−ｒｓｉｚ：２５４，１７２」より、画像全体を表示領域として返送してきているので、ｐｃｔ＝１００である。
【０１０２】
さらに、クライアントは、ステップＳ１５０５の解析結果とステップＳ１５０６で得られるｐｃｔから、しきい値Ｔｈとコードストリームとの関係を保存する（ステップＳ１５０７）。本実施形態の場合、ｐｃｔ（＝１００）＞Ｔｈ（＝２５）の状態でｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６の識別子をもつコードストリームから返送データが作成されている。従って、ｐｃｔがＴｈ以上の場合はｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６が対象コードストリームの識別子であり、ｐｃｔがＴｈ以下の場合はｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４が対象コードストリームの識別子であるという関係が導出され、この結果を保存することになる。
【０１０３】
さらに、クライアントは、識別子ＩＤｇに対応するキャッシュに返送データを保存する（ステップＳ１５０８）。尚、返送データのキャッシュ方法については、例えば、特開２００３−１７９７６０公報に記述されているような方法でも良いし、他の方法であっても良い。このキャッシュ方法については、本願発明の主眼ではないので、詳しい説明は省略する。本実施形態では、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６に対応するキャッシュに返送データを保存することになる。しかし、クライアントは、ｓａｍｐｌｅ．ｊｐ２に対して初めてのアクセスであるため、ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１７６に対応するキャッシュを新規に作成して保存することになる。
【０１０４】
次いで、クライアントは、ステップＳ１５０８保存した識別子ＩＤｇのコードストリームのキャッシュデータからＪＰＥＧ２０００データを生成する（ステップＳ１５０９）。そして、クライアントは、ステップＳ１５０９で生成されたＪＰＥＧ２０００データをデコードした後、表示して（ステップＳ１５１０）、この受信フローを終了する。
【０１０５】
尚、本実施形態に対応していないサーバに対して、本実施形態に対応したクライアントがリクエストを送出した場合は、クライアントから送られる要求がＪＰＩＰに則っているため、通常のリクエストとして処理されることとなる。
【０１０６】
上述したように、本実施形態に係るサーバ／クライアントシステムを用いることによって、表示される領域がサムネイル表示に代表されるような画像全体に占める割合が大きい場合には、クライアントはタイル数の少ない符号化データの部分データを受信・表示することができる。一方で、拡大表示に代表されるような表示される領域が画像全体に占める割合が小さい場合には、タイル数の多い符号化データの部分データを受信・表示することができる。
【０１０７】
従って、比較的小さい画像を表示する場合には、キャッシュデータから作成されるＪＰＥＧ２０００符号化データはタイル数が少ないため、ファイル内のシーク回数が軽減され、表示までの時間を短縮する効果が得られる。また、大きな画像の一部分を表示する場合には、小さいタイルから構成される画像データのために転送データ量が削減され、通信時間を削減する効果が得られる。
【０１０８】
＜第２の実施形態＞
上述した第１の実施形態では、サーバ２０４が保有する画像として、ランダムアクセス性を考慮し、多くのタイルによって画像を分割したＪＰＥＧ２０００画像を想定していた。
【０１０９】
ここで、システムによっては、多くの画像をある程度小さいサイズのまま一覧表示によって利用することがほとんどであり、そのうち数枚のみに拡大等の操作が行われるような場合があり得る。このような場合、分割タイル数が少ないＪＰＥＧ２０００画像をサーバが保有しておき、必要に応じてタイル数を増やすようにしてもよい。そこで、本実施形態では、サーバが保有しているＪＰＥＧ２０００画像データは、以下のようなエンコード条件とする。
【０１１０】
最大画像サイズ：４０６４×２７５２［ｐｉｘｅｌ］
タイルサイズ：２５６×２５６［ｐｉｘｅｌ］
タイル数：１７６（＝１６×１１）
Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌ数：５
各Ｒｅｓｏｌｕｔｉｏｎ  Ｌｅｖｅｌの画像サイズ：
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ４：４０６４×２７５２［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：２５６×２５６［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ３：２０３２×１３７６［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：１２８×１２８  ［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ２：１０１６×６８８［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：  ６４×６４  ［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  １：５０８×３４４［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：３２×３２  ［ｐｉｘｅｌ］）
Ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ  ０：２５４×１７２［ｐｉｘｅｌ］  （ｔｉｌｅサイズ：１６×１６  ［ｐｉｘｅｌ］）
尚、第２の実施形態では、サーバ及びクライアントの各構成並びにサーバ／クライアントシステムの構成は、図１及び図２で示されるような第１の実施形態におけるものと同様とする。
【０１１１】
上述したような画像データを用いる場合、前述した第１の実施形態と異なる部分はサーバ２０４側の処理であって、図１０のフローチャートで示されるサーバ側の動作のステップＳ１００４〜Ｓ１００８の間の処理内容及び手順である。図１６は、本発明の第２の実施形態におけるサーバ２０４の動作を説明するためのフローチャートである。尚、図１６に示すフローチャートにおいて、第１の実施形態で説明した図１０に示すフローチャートと同様の動作については、図１０と同じステップ番号を付しており、その詳細な説明は省略する。
【０１１２】
第２の実施形態に係るサーバ２０４は、第１の実施形態と同様に、クライアントからのリクエストを受信し（ステップＳ１００１）、当該リクエストを解析し（ステップＳ１００２）、表示領域の画像全体に占める割合ｐｃｔを算出する（ステップＳ１００３）。
【０１１３】
次いで、サーバ２０４は、オリジナルの符号化データに対する識別子ＩＤｍとタイル数を増加させた符号化データに対する識別子ＩＤｄを取得する（ステップＳ１６０１）。そして、表示領域の画像全体に占める割合ｐｃｔが、あらかじめ決められたしきい値Ｔｈよりも大きいか否かを判定する（ステップＳ１００５）。その結果、割合ｐｃｔがしきい値Ｔｈよりも大きいと判定された場合（Ｙｅｓ）、サーバ２０４は、返送データ作成用符号化データの識別子ＩＤｔに、オリジナルの符号データに対する識別子ＩＤｍをセットする（ステップＳ１６０２）。すなわち、第２の実施形態においては、１７６タイルに分割された画像のコードストリームに付けられた識別子の値をＩＤｔとする。
【０１１４】
一方、ステップＳ１００５において、表示領域の画像全体に占める割合ｐｃｔがあらかじめ決められたしきい値Ｔｈ以下と判定された場合（Ｎｏ）、サーバ２０４は、返送データ作成用符号化データの識別子ＩＤｔにタイル数を増加させた画像のコードストリームにつけられた識別子ＩＤｄをセットする（ステップＳ１６０３）。そして、サーバ２０４は、オリジナルの符号化データからタイル数を増加させた符号化データＣｉを作成する（ステップＳ１６０４）。尚、ステップＳ１６０４で作成された符号化データに対する識別子がＩＤｄである。
【０１１５】
本実施形態では、１枚のタイルから４枚のタイルを作成することで、タイル数を４倍に増加させたコードストリームＣｉを作成する。すなわち、図９の画像９０２のタイル０をデコードしてタイルを４分割し、オリジナルの符号化データのタイルサイズを２５６×２５６から半分の１２８×１２８にして、その他のエンコード条件は同一にしてエンコードする。同様に、画像９０２のタイル１から４タイルを生成し、順に画像全体の符号化データを作成し直す。そして、最終的には、図９の画像９０１に示すように、７０４枚のタイルに分割された符号化データＣｉが作成される。
【０１１６】
ステップＳ１６０２及びステップＳ１６０４の処理の後、サーバ２０４は、第１の実施形態と同様に、識別子ＩＤｔの符号化データから要求表示領域のデータを抜き出し（ステップＳ１００９）、レスポンスデータを作成し（ステップＳ１０１０）、レスポンスデータを送信する（ステップＳ１０１１）。
【０１１７】
上述したように、タイル数が少ない場合はタイルヘッダの数やｐａｃｋｅｔの数が削減されるために、ＪＰＥＧ２０００符号データのデータサイズが小さくなる。そのため、サーバ側が保有する画像の容量を削減する効果が得られる。
【０１１８】
また、電子カタログのように、ある程度の大きさの画像一覧を見て、気に入った商品のみを拡大して表示するようなシステムにおいては、本実施形態に係る方法を用いることで、サーバ側の変換処理の回数を少なくすることができ、負荷を減らす効果が得られる。
【０１１９】
＜第３の実施形態＞
上述した第１の実施形態及び第２の実施形態では、サーバ２０４が保有するデータのエンコード条件は統一されていた。ここで、システムによってはエンコード条件を統一することも可能である。但し、様々な画像がアップロードされるようなシステムでは、画像のエンコード条件を統一することは難しい。
【０１２０】
本実施形態では、サーバ側に様々なエンコード条件の画像データが存在するものとする。尚、第３の実施形態では、サーバ及びクライアントの各構成並びにサーバ／クライアントシステムの構成は、図１及び図２で示されるような第１及び第２の実施形態におけるものと同様とする。
【０１２１】
本実施形態では、サーバ２０４は、第１及び第２の実施形態と同様に、クライアントからのリクエストに基づいて、表示領域の画像全体に占める割合ｐｃｔを算出し、あらかじめ決められたしきい値Ｔｈと比較する。その結果、当該しきい値Ｔｈよりも割合ｐｃｔの値が大きい場合、すなわち、画像全体に占める表示領域の割合の方が大きい場合は、あらかじめ決められたタイル数Ｎ未満に画像を分割する。一方、しきい値Ｔｈよりも割合ｐｃｔの値が小さい場合、すなわち、画像全体に占める表示領域の割合が小さい場合は、あらかじめ決められたタイル数Ｎ以上のタイルに画像を分割する。尚、本実施形態では、あらかじめ決められたタイル数Ｎを４００とする。
【０１２２】
このような条件で処理を行う場合、前述した第１及び第２の実施形態と異なる部分、サーバ側の処理であり、図１０のステップＳ１００４〜Ｓ１００８間の処理内容及び手順である。図１７は、本発明の第３の実施形態におけるサーバ２０４の動作を説明するためのフローチャートである。尚、図１７に示すフローチャートにおいて、第１の実施形態で説明した図１０に示すフローチャートと同様の動作については、図１０と同じステップ番号を付しており、その詳細な説明は省略する。
【０１２３】
第３の実施形態に係るサーバ２０４は、第１の実施形態と同様に、クライアントからのリクエストを受信し（ステップＳ１００１）、当該リクエストを解析し（ステップＳ１００２）、表示領域の画像全体に占める割合ｐｃｔを算出する（ステップＳ１００３）。
【０１２４】
次いで、サーバ２０４は、タイル数Ｎ以上の符号化データに対する識別子ＩＤｕｐとタイル数Ｎ未満の符号化データに対する識別子ＩＤｌｏを取得する（ステップＳ１７０１）。本実施形態の場合、タイル数４００以上の符号化データに対してはｓａｍｐｌｅ＿ｕｐｐｅｒという識別子が取得され、タイル数４００未満の符号化データに対してはｓａｍｐｌｅ＿ｌｏｗｅｒという識別子が取得できたものとする。
【０１２５】
そして、サーバ２０４は、表示領域の画像全体に占める割合ｐｃｔが、あらかじめ決められたしきい値Ｔｈよりも大きいか否かを判定する（ステップＳ１００５）。その結果、割合ｐｃｔがしきい値Ｔｈよりも大きいと判定された場合（Ｙｅｓ）、サーバ２０４は、返送データ作成用符号化データの識別子ＩＤｔにＩＤｌｏをセットする（ステップＳ１７０２）。尚、本実施形態においては、ＩＤｔ＝ｓａｍｐｌｅ＿ｌｏｗｅｒである。
【０１２６】
次いで、サーバ２０４は、識別子ＩＤｌｏとなる符号化データを特定し（ステップＳ１７０３）、ステップＳ１００９に進む。尚、ステップＳ１７０３の動作の詳細については図１８を用いて後述する。
【０１２７】
一方、ステップＳ１００５で、表示領域の画像全体に占める割合ｐｃｔがしきい値Ｔｈよりも小さいと判定された場合（Ｎｏ）、サーバ２０４は、返送データ作成用符号化データの識別子ＩＤｔにＩＤｕｐをセットする（ステップＳ１７０４）。尚、本実施形態においては、ＩＤｔ＝ｓａｍｐｌｅ＿ｕｐｐｅｒである。次いで、サーバ２０４は、識別子ＩＤｕｐとなる符号化データを特定し（ステップＳ１７０５）、ステップＳ１００９に進む。尚、ステップＳ１７０５における動作の詳細については図１９を用いて後述する。
【０１２８】
ステップＳ１７０３及びステップＳ１７０５の処理の後、サーバ２０４は、第１の実施形態と同様に、識別子ＩＤｔの符号化データから要求表示領域のデータを抜き出し（ステップＳ１００９）、レスポンスデータを作成し（ステップＳ１０１０）、レスポンスデータを送信する（ステップＳ１０１１）。
【０１２９】
図１８は、第３の実施形態におけるサーバ２０４の識別子ＩＤｌｏとなる符号化データの特定処理（ステップＳ１７０３）の細部処理手順を説明するためのフローチャートである。サーバ２０４は、まず、オリジナルの符号化データのタイル数と、あらかじめ決められたタイル数Ｎとを比較する（ステップＳ１８０１）。その結果、オリジナル符号化データのタイル数のほうが小さい場合（Ｙｅｓ）はステップＳ１８０２へ進み、それ以外の場合（Ｎｏ）はステップＳ１８０３へ進む。尚、本実施形態では、あらかじめ決められたタイル数Ｎは４００であるため、例えば、図９の画像９０１のような画像データであればステップＳ１８０３に進み、図９の画像９０２のような画像データであればステップＳ１８０２に進むことになる。
【０１３０】
ステップＳ１８０２において、サーバ２０４は、オリジナル符号化データに識別子ＩＤｌｏを割り当ててこのフローを終了し、ステップＳ１００９に進む。一方、ステップＳ１８０３において、サーバ２０４は、オリジナル符号化データからタイル数Ｎ未満になるような符号化データＣｌｏを作成する。尚、本実施形態では、タイル数Ｎは４００であるため、図９の画像９０１のようなデータであれば、第１の実施形態と同様に４つのタイルから１つのタイルを作成することで、タイル数を４００未満にすることができる。次いで、サーバは、ステップＳ１８０３で作成した符号化データＣｌｏに識別子ＩＤｌｏを割り当て（ステップＳ１８０４）、このフローを終了してステップＳ１００９に進む。
【０１３１】
図１９は、第３の実施形態におけるサーバ２０４の識別子ＩＤｕｐとなる符号化データの特定処理（ステップＳ１７０５）の細部処理手順を説明するためのフローチャートである。サーバ２０４は、まず、オリジナルの符号化データのタイル数と、あらかじめ決められたタイル数Ｎとを比較する（ステップＳ１９０１）。その結果、オリジナル符号化データのタイル数のほうが大きい場合（Ｙｅｓ）はステップＳ１９０２へ進み、それ以外の場合（Ｎｏ）はステップＳ１９０３へ進む。本実施形態では、あらかじめ決められたタイル数Ｎは４００であるため、例えば、図９の画像９０１のような画像データであればステップＳ１９０２へ進み、図９の画像９０２のような画像データであればステップＳ１９０３へ進むこととなる。
【０１３２】
ステップＳ１９０２において、サーバ２０４は、オリジナルの符号化データに識別子ＩＤｕｐを割り当ててこの処理フローを終了し、ステップＳ１００９に進む。一方、ステップＳ１９０３において、サーバ２０４は、タイル数Ｎ以上になるようにオリジナルの符号化データから符号化データＣｕｐを作成する。ここで、本実施形態では、タイル数Ｎは４００であるため、図９の画像９０２に示すようなデータの場合は前述した第２の実施形態と同様に１つのタイルから４つのタイルを作成することで、タイル数を４００以上にすることができる。
【０１３３】
その後、サーバ２０４は、ステップＳ１９０３で作成した符号化データＣｕｐに識別子ＩＤｕｐを割り当てて（ステップＳ１９０４）、このフローを終了してステップＳ１００９に進む。
【０１３４】
上記第３の実施形態で説明したような方法を用いることによって条件分岐等が増える。一方で、サーバ側の負荷が多少は増加するものの、様々なエンコード条件を持つ画像データをサーバに追加するような場合においても、前述した第１及び第２の実施形態と同様の効果を得ることができる。すなわち、比較的小さい画像を表示する場合には、クライアント側で作成されるＪＰＥＧ２０００符号化データはタイル数が少ないため、ファイル内のシーク回数が軽減し、表示までの時間を短縮する効果が得られる。一方、大きな画像の一部分を表示する場合には、小さいタイルから構成される画像データのために転送データ量が削減され、通信時間を削減する効果が得られる。
【０１３５】
＜その他の実施形態＞
上述した第１、第２及び第３の実施形態では、サーバ／クライアント間のデータ転送単位は、ＪＰＥＧ２０００のｐａｃｋｅｔとしたが、タイル単位であっても同様の効果が得られる。
【０１３６】
また、上記実施形態では、タイル数の増加、或いは削減を決定するためのしきい値として、画像全体の４分の１に当たる２５％を選択して説明したが、この値に限られるものではない。また、しきい値は１つであるとは限らず、一つの画像データからタイル数の異なる３種類以上の符号化データを生成して、クライアントの要求に応じて、比較するようにしても良い。
【０１３７】
さらに、上記実施形態では、しきい値とコードストリーム識別子との対応関係を記述する方法として、
ｃｏｄｅｓｅｌｅｃｔ：［画像全体に対する表示領域の割合］／［コードストリーム識別子］
のような記述方法をしても良い。
【０１３８】
すなわち、画像全体に対する表示領域の割合が２５％以下の場合は、識別子ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４のコードストリームから、２５％以上５０％以下の場合は、識別子ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿２０４のコードストリームから、５０％以上７５％以下の場合は、識別子ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿４８のコードストリームから、７５％以上１００％以下の場合は、識別子ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１２のコードストリームからデータを返送するように通知する場合には、
ｃｏｄｅｓｅｌｅｃｔ：０−２５／ｓａｍｐｌｅ＿ｍａｓｔｅｒ＿７０４
ｃｏｄｅｓｅｌｅｃｔ：２５−５０／ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿２０４
ｃｏｄｅｓｅｌｅｃｔ：５０−７５／ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿４８
ｃｏｄｅｓｅｌｅｃｔ：７５−１００／ｓａｍｐｌｅ＿ｄｅｒｉｖｅ＿１２
で示されるような記述になる。
【０１３９】
また、タイル数の削減方法として上記実施形態では、４枚のタイルから１枚のタイルを生成することでタイル数を約４分の１にしたが、それ以外にも隣接する６枚のタイル、９枚のタイル、１６枚のタイル等を使って、それぞれタイル数を約６分の１、約９分の１、約１６分の１に削減するようにしても良い。
【０１４０】
さらに、しきい値がサーバとクライアントの間で事前に決まっている場合には、サーバは当該しきい値を返送データと共にクライアントに通知する必要はない。
【０１４１】
さらにまた、上記実施形態では、いずれの場合もタイル数を増減させており、タイル数を基準としていたが、タイルのサイズを基準としてコードストリームを作成した場合であっても同様の効果が得られる。例えば、要求された領域の割合が２５％以上であれば、タイルサイズを最高解像度時で２５６×２５６［ｐｉｘｅｌ］以上のサイズになるようにコードストリームを変換し、２５％以下であれば、タイルサイズを１２８×１２８［ｐｉｘｅｌ］以下のサイズになるようにコードストリームを変換する。この場合も、隣接する４枚タイルから１枚のタイルを生成し、タイルサイズを大きくしたり、或いは１枚のタイルを９分割してタイルサイズを小さくしたりする方法が有効である。
【０１４２】
さらにまた、タイルサイズを基準値とする場合には、クライアントの要求領域サイズに応じて、基準とするタイルサイズを決定しても良い。例えば、要求された領域の割合が２５％以下の場合には、要求領域のサイズの１６分の１サイズにタイルサイズを変更するようにする。
【０１４３】
以上説明した実施形態で例示できる本発明を用いることによって、解像度が低い画像はタイル数が少ない画像データからデータが返送されるので、ファイルシーク回数が減少し、サムネイル表示等の小さいサイズで画像全体を表示する際には、高速にデコードすることができる。その一方で、拡大要求により返送される解像度が高い画像はタイル数が多い画像であるので、画像の部分領域に含まれるタイルも細かくなり、ランダムアクセス性を維持して無駄なデータ転送を抑えることができる。
【０１４４】
従って、解像度が低い（画像サイズが小さい）画像に対してタイル数を少ないデータにしてデコード時間を短縮でき、拡大画像の部分領域転送の際にはタイル数が多いデータを使用して無駄な転送データ量を削減するという効果を得ることができる。
【０１４５】
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体（記録媒体）等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１４６】
尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１４７】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１４８】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１４９】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０１５０】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１５１】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１５２】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１５３】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１５４】
【図１】本発明の第１の実施形態に係るサーバ／クライアントシステムを実現するためのコンピュータの構成の概略を示すブロック図である。
【図２】本発明の第１の実施形態を実現するサーバ／クライアントシステムの概略構成を示す図である。
【図３】一般的なＪＰＥＧ２０００の符号化データの構成を説明するための図である。
【図４】画像における解像度（画像サイズ）とＲｅｓｏｌｕｔｉｏｎ番号との関係を示すＪＰＥＧ２０００の解像度スケーラビリティを示す図である。
【図５】サーバ／クライアント間での通信プロトコルをＰａｃｋｅｔ単位のリクエスト及びレスポンスの関係を用いて説明するための概念図である。
【図６】Ｐｒｅｃｉｎｃｔ  ｄａｔａ−ｂｉｎの概念図である。
【図７】ＪＰＩＰレスポンスデータの概念図である。
【図８】サーバが保持するＪＰＥＧ２０００画像の構成を示す概念図である。
【図９】サーバに保持されている画像のタイルとタイル番号との関係を示す図である。
【図１０】本発明の第１の実施形態におけるサーバ２０４の動作を説明するためのフローチャートである。
【図１１】第１の実施形態におけるサーバ２０４の返送データ抜き出し処理（ステップＳ１００９）の細部処理手順を説明するためのフローチャートである。
【図１２】第１の実施形態におけるサーバ２０４のレスポンスデータの作成処理（ステップＳ１０１０）の細部処理手順を説明するためのフローチャートである。
【図１３】本発明の第１の実施形態におけるクライアントのリクエスト発行手順を説明するためのフローチャートである。
【図１４】本発明の第１の実施形態におけるサムネイル取得後のクライアントのキャッシュデータの一例を示す概念図である。
【図１５】本発明の第１の実施形態に係るクライアントのデータ受信処理手順を説明するためのフローチャートである。
【図１６】本発明の第２の実施形態におけるサーバ２０４の動作を説明するためのフローチャートである。
【図１７】本発明の第３の実施形態におけるサーバ２０４の動作を説明するためのフローチャートである。
【図１８】第３の実施形態におけるサーバ２０４の識別子ＩＤｌｏとなる符号化データの特定処理（ステップＳ１７０３）の細部処理手順を説明するためのフローチャートである。
【図１９】第３の実施形態におけるサーバ２０４の識別子ＩＤｕｐとなる符号化データの特定処理（ステップＳ１７０５）の細部処理手順を説明するためのフローチャートである。
【符号の説明】
【０１５５】
１０１  ＣＰＵ
１０２  一次記憶装置
１０３  二次記憶装置
１０４  入力デバイス
１０５  出力デバイス
２０１、２０２  クライアント
２０３  ネットワーク
２０４  サーバ
２０５  大容量ハードディスク
【図１】
2006191159.tif 000003
【図２】
2006191159.tif 000004
【図３】
2006191159.tif 000005
【図４】
2006191159.tif 000006
【図５】
2006191159.tif 000007
【図６】
2006191159.tif 000008
【図７】
2006191159.tif 000009
【図８】
2006191159.tif 000010
【図９】
2006191159.tif 000011
【図１０】
2006191159.tif 000012
【図１１】
2006191159.tif 000013
【図１２】
2006191159.tif 000014
【図１３】
2006191159.tif 000015
【図１４】
2006191159.tif 000016
【図１５】
2006191159.tif 000017
【図１６】
2006191159.tif 000018
【図１７】
2006191159.tif 000019
【図１８】
2006191159.tif 000020
【図１９】
2006191159.tif 000021