(57)【要約】【課題】  階層的に符号化された画像データを送受信する構成において、データ受信側に要求されるハードウェア要件を低減する技術を提供する。【解決手段】  本発明によるサーバ装置は、１以上のパケットから構成された画像データを解像度レベル毎に記憶する記憶手段と、外部装置から、画像データの解像度レベルの指定が含まれる送信要求と、外部装置の記憶可能容量に係る容量情報とを受信する受信手段と、画像データのサイズと容量情報との比較に基づいて所定の処理を実行するか否かを決定する決定手段と、決定手段において処理を実行すると決定された場合、指定された解像度レベル以下の解像度レベルに含まれるパケットを返送データに追加し、解像度レベルに含まれないパケットを長さがＺＬＰで置き換えて返送データに追加することによって、返送データを生成する処理を実行する生成手段と、生成された返送データを外部装置へ送出する送出手段とを備える。【選択図】  図８
2007053445.tif 000002
【特許請求の範囲】
【請求項１】
１以上のパケットから構成された画像データを解像度レベル毎に記憶する記憶手段と、
外部装置から、少なくとも前記画像データの前記解像度レベルの指定が含まれる送信要求と、該外部装置の記憶可能容量に係る容量情報とを受信する受信手段と、
前記画像データのサイズと前記容量情報との比較に基づいて前記画像データに対して所定の処理を実行するか否かを決定する決定手段と、
前記決定手段において処理を実行すると決定された場合、指定された前記解像度レベル及び当該指定された解像度レベルよりも低い解像度レベルに含まれる前記パケットを返送データに追加し、前記解像度レベルに含まれない前記パケットを長さが０であることを示すパケットで置き換えて該返送データに追加することによって、返送データを生成する処理を実行する生成手段と、
生成された前記返送データを前記外部装置へ送出する送出手段と、を備えることを特徴とするサーバ装置。
【請求項２】
１以上のパケットから構成された画像データを解像度レベル毎に記憶する記憶手段と、
外部装置から、少なくとも前記画像データの前記解像度レベルの指定が含まれる送信要求と、該外部装置の記憶可能容量に係る容量情報とを受信する受信手段と、
前記画像データのサイズと前記容量情報との比較に基づいて前記画像データに対して所定の処理を実行するか否かを決定する決定手段と、
前記決定手段において処理を実行すると決定された場合、指定された前記解像度レベル及び当該指定された解像度レベルよりも低い解像度レベルに含まれる前記パケットを返送データに追加することによって、返送データを生成する処理を実行する生成手段と、
生成された前記返送データを前記外部装置へ送出する送出手段と、を備えることを特徴とするサーバ装置。
【請求項３】
１以上のパケットから構成された画像データを解像度レベル毎に記憶する記憶手段と、
外部装置から、少なくとも前記画像データの前記解像度レベルの指定が含まれる送信要求と、該外部装置の記憶可能容量に係る容量情報とを受信する受信手段と、
前記画像データのサイズと前記容量情報との比較に基づいて前記画像データに対して所定の処理を実行するか否かを決定する決定手段と、
前記決定手段において処理を実行すると決定された場合、指定された前記解像度レベル及び当該指定された解像度レベルよりも低い解像度レベルに含まれる前記パケットを合成して、指定された前記解像度レベルの画像データを生成する処理を実行する生成手段と、
生成された前記返送データを前記外部装置へ送出する送出手段と、を備えることを特徴とするサーバ装置。
【請求項４】
前記複数のレイヤから構成された画像データは、ＪＰＥＧ２０００方式に基づく符号化データであることを特徴とする請求項１乃至３のいずれか１項に記載のサーバ装置。
【請求項５】
前記受信手段、及び、前記送出手段は、ＪＰＩＰに基づいて前記外部装置と通信を行うことを特徴とする請求項１乃至４のいずれか１項に記載のサーバ装置。
【請求項６】
前記送出手段により送出される前記返送データのデータ形式は、ＪＰＩＰのRAW又はjp2の形式であることを特徴とする請求項５記載のサーバ装置。
【請求項７】
１以上のパケットから構成された画像データを解像度レベル毎に記憶する記憶手段を備えたサーバ装置の制御方法であって、
外部装置から、少なくとも前記画像データの前記解像度レベルの指定が含まれる送信要求と、該外部装置の記憶可能容量に係る容量情報とを受信する受信工程と、
前記画像データのサイズと前記容量情報との比較に基づいて前記画像データに対して所定の処理を実行するか否かを決定する決定工程と、
前記決定工程において処理を実行すると決定された場合、指定された前記解像度レベル及び当該指定された解像度レベルよりも低い解像度レベルに含まれる前記パケットを返送データに追加し、前記解像度レベルに含まれない前記パケットを長さが０であることを示すパケットで置き換えて該返送データに追加することによって、返送データを生成する処理を実行する生成工程と、
生成された前記返送データを前記外部装置へ送出する送出工程と、を備えることを特徴とするサーバ装置の制御方法。
【請求項８】
コンピュータを請求項１乃至７のいずれかに記載のサーバ装置として機能させるためのコンピュータプログラム。
【請求項９】
請求項８に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像データを送受信する技術に関する。
【背景技術】
【０００２】
近年、コンピュータの表示装置等に用いられるディスプレイの解像度が向上している。かつて普及していたディスプレイの解像度は、ＶＧＡ(６４０×４８０画素)、ＳＶＧＡ(８００×６００画素)程度以下であった。これに対し、現在ではノートＰＣ（Personal Computer）でさえ、ＸＧＡ(１０２４×７６８画素)以上のディスプレイを備えている。デスクトップＰＣ等に外付けされるディスプレイにいたっては、ＳＸＧＡ(１２８０×１０２４画素), ＵＸＧＡ(１６００×１２００画素)程度の解像度を備えたものが普及している。今後、ＱＸＧＡ, ＱＵＸＧＡ等の高解像度をサポートするディスプレイが普及することは、容易に推察できる。
【０００３】
一方、デジタルカメラ等により撮影された多数の画像データをサムネイル画像（縮小画像）として並べて表示し、所定のイベントに基づいてその中の１つを元画像のサイズで詳細表示するアプリケーションが知られている。このようなアプリケーションはズームやスクロールなどの表示技術を利用していることが一般的である。
【０００４】
このようなアプリケーションにおいて、多数の画像データを同時に表示する場合には高速性が重要視されるため、主画像データとは異なる予め作成されたサムネイル画像データを用いることが多い。一方、そのサムネイル表示から選択された画像データの１枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズあるいは、ディスプレイ装置に表示できるまでは、画像全体を表示することが多い。それ以上の拡大表示については画像の一部分を表示することが多い。
【０００５】
このような、１枚の画像データを表示する際に、元画像データの画像サイズより小さい画像サイズの画像データを複数種類使用するようなアプリケーションにおいては、次のような処理を行っていた。即ち、必要に応じてデコード処理を行い、１度元画像データの画像サイズを再現し、その後、目的の画像サイズになるように、画像データを縮小する処理を行っていた。
【０００６】
一方、画像データは、非圧縮かあるいはＪＰＥＧ baselineのようなシーケンシャルの符号化方式で圧縮されていた。或いは、画像データを階層符号化方式で画像圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装していた。
【０００７】
階層符号化方式としては、例えば、ＪＰＥＧ２０００符号化方式がある。ＪＰＥＧ２０００は、１枚の画像データを１つ以上のタイルに分割し、その分割されたタイル毎に、１つ以上の解像度の画像を階層的に保持する階層符号化方式である。ＪＰＥＧ２０００は、２００１年にＩＳＯ／ＩＴＣで標準化された画像符号化方式としても知られている。
【０００８】
ＪＰＥＧ２０００符号化方式には、エンコード時のエンコード・オプションが数多く存在する。しかし、全ての機能をサポートしたデコーダは、多大な開発コストを要し、また、動作させるために通常よりも高度な演算リソース（ＣＰＵクロック、メモリ容量等）を要する。
【０００９】
また、ネットワーク上でこのＪＰＥＧ２０００で符号化された符号データファイルに対して断片的に必要な部分のみをアクセスする時のプロトコルとしてＪＰＩＰが知られており、現在策定中である。ただし、ＪＰＩＰは、JPEG2000 image coding system - Part 9: Interactivity tools, APIs and protocolsの略称である。
【００１０】
また、ＪＰＩＰを利用したサーバ、クライアントからなる画像配信システムが知られている。
【００１１】
特許文献１には、ＪＰＥＧ２０００で符号化された画像データの部分データをサーバ・クライアントで送受信するシステムが開示されている。この構成において、クライアントは、サーバに格納されているコードストリームのどの部分が、既にクライアントのバッファに格納されているかを判別し、未だバッファに格納していない圧縮データの部分をサーバに要求する。クライアントが要求するデータの単位は、例えば、ＪＰＥＧ２０００符号内のパケット、タイル、コードブロックから選択可能であり、或いは、バイト単位での要求も可能である。一方、サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。クライアントは、受信したデータと既にバッファに格納されたデータを統合してデコードを行い、画像を取得する。
【００１２】
また、特許文献２には、サーバ側に格納されているＪＰＥＧ２０００符号データを、クライアント側で高速にプログレッシブ表示するための技術が開示されている。この構成において、クライアントは、欲しい解像度レベルを指定するリクエストを発行し、サーバへ送出する。サーバは、クライアントから指定された解像度レベルのサブバンド符号データを、格納された画像ファイルから取り出してクライアントに送信する。クライアントは、表示している画像の解像度レベルの、復号化されたサブバンドの係数と、サーバから受信した符号データを復号して得られたサブバンドの係数とに基づいて画像データを復元することで、解像度方向のプログレッシブ表示を行うことができる。
【特許文献１】特開２００３−０２３６３０号公報
【特許文献２】特開２００４−０４０６７４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記のように階層的に符号化された画像データを送受信する構成においては、データ伝送を効率よく行うために、クライアントが１度受信した符号データをキャッシュしておき、未受信部分の符号データのみをサーバに要求するように制御する。しかし、このような構成を実現するためには、クライアントは大容量の記憶装置を有している必要がある。
【００１４】
例えば、上記のような構成において、クライアント側で画像データを追加要求をせずに全て表示できた場合には、サーバに格納されている圧縮画像データが全てクライアント側に送信されている。つまり、このような場合には、サーバに格納されている圧縮画像データのファイルと同サイズ、あるいはそれ以上のキャッシュ容量をクライアント側が有していることを意味する。
【００１５】
また、キャッシュデータをＪＰＥＧ２０００の符号データに変換する場合は、キャッシュデータと符号データとの２種類のデータを作成／管理する必要がある。このため、クライアント側ではサーバに格納されている圧縮画像ファイルサイズの２倍以上のメモリあるいはファイル容量を必要とすることになる。
【００１６】
画像データのサイズについて具体例を挙げて説明する。ここで、サーバにある圧縮画像ファイルの画像サイズがとても大きい場合、例えば、画像サイズが１０２４０×１０２４０画素×３色の場合を考えると、非圧縮状態での画像データは、３００Ｍバイトになる。１０２４００×１０２４００画素×３色の場合は、３００００Ｍバイト、即ち約３０Ｇバイトとなる。これを１／２０に圧縮したとして前者は１５Ｍバイト、後者は１５００Ｍバイトになる。
【００１７】
このようなデータサイズの大きいデータは、クライアント装置がパーソナルコンピュータ（ＰＣ、パソコン）で実現されている場合は、処理可能かもしれない。しかしながら、小型のＰＣ、ＰＤＡや携帯端末等のようなデバイスの場合では、メモリ容量あるいはファイル容量等の記憶装置の制限に加えて、ＣＰＵ性能の制限においても扱えない場合が多い。
【００１８】
また、クライアントが通常のＰＣによって実現された場合においても、画像通信の処理をその他の様々な処理と並行して行なう場合、画像通信に割り当てられるハードウェア・リソースが制限され、大容量の画像データ処理が現実的に困難になる可能性がある。さらに通常のＰＣにおいても、一時的なファイルやメモリとして１Ｇバイトを超えるファイルを作成することは容易ではなく、ましてやメモリ上にこの容量の領域を確保することは極めて困難である。
【００１９】
また、受信した符号データをキャッシュしないでＪＰＥＧ２０００のデコード作業を途中で停止し、差分の符号データを追加してデコードを続ける構成も可能である。しかし、このような構成の場合は、演算の途中結果であるＤＷＴ係数を保持する必要がある。各画素が８ビットの場合でも、このＤＷＴ係数は１６ビット以上であり通常の実装では３２ビットである。よってこのＤＷＴ係数を保持することは、デコード後の画像データを保持する以上のメモリ容量を必要とする。即ち、符号データをキャッシュする場合よりはるかに大きいメモリ容量を必要とすることを意味する。
【００２０】
特許文献１に開示された構成は、クライアント側でキャッシュすることを前提としているため、要求した圧縮画像データファイルのバイト数以上のキャッシュ容量を必要とする。そのため要求した圧縮画像データファイルのファイルサイズがクライアントの能力を超えて大きい場合は、クライアントは処理を継続することができない場合がある。
【００２１】
また、特許文献２に開示された構成においては、デコード処理を途中で止めて、デコード処理で使用したＤＷＴ係数を保持する。このため、符号データを保持する場合に比べて、ＤＷＴ計数の保持のための大容量メモリを要する。また、デコード作業を途中で停止したり、サブバンドのデータを追加するためには、特殊なデコーダを要する。
【００２２】
さらには、要求する画像データのファイルサイズは、現状のＪＰＩＰのリクエスト／レスポンスのデータフォーマットからは取得することができない。このため、クライアント側で符号データを要求する前にファイルサイズ等を調べることができない。
【００２３】
上記のように、階層的に符号化された画像データを送受信する従来の構成においては、クライアント装置に要求されるハードウェア要件が非常に高かった。特に、画像データのデータサイズが大きい場合にこの問題が顕著であった。
【００２４】
本発明は上記問題に鑑みなされたものであり、階層的に符号化された画像データを送受信する構成において、データ受信側に要求されるハードウェア要件を低減する技術を提供することを目的とする。
【課題を解決するための手段】
【００２５】
上記目的を達成するため、本発明によるサーバ装置は以下の構成を備える。即ち、
１以上のパケットから構成された画像データを解像度レベル毎に記憶する記憶手段と、
外部装置から、少なくとも前記画像データの前記解像度レベルの指定が含まれる送信要求と、該外部装置の記憶可能容量に係る容量情報とを受信する受信手段と、
前記画像データのサイズと前記容量情報との比較に基づいて前記画像データに対して所定の処理を実行するか否かを決定する決定手段と、
前記決定手段において処理を実行すると決定された場合、指定された前記解像度レベル及び当該指定された解像度レベルよりも低い解像度レベルに含まれる前記パケットを返送データに追加し、前記解像度レベルに含まれない前記パケットを長さが０であることを示すパケットで置き換えて該返送データに追加することによって、返送データを生成する処理を実行する生成手段と、
生成された前記返送データを前記外部装置へ送出する送出手段と、を備える。
【発明の効果】
【００２６】
本発明によれば、階層的に符号化された画像データを送受信する構成において、データ受信側に要求されるハードウェア要件を低減する技術を提供することができる。
【発明を実施するための最良の形態】
【００２７】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００２８】
＜＜第１実施形態＞＞
（システム構成）
まず、本実施形態におけるシステムの構成について図１を参照して説明する。図１は、インターネットに代表されるネットワーク上に複数のコンピュータが接続されている様子を示した図である。
【００２９】
図１において、１００はインターネットに代表されるネットワークである。
【００３０】
１０１はサーバ・コンピュータ（サーバ）であり、ＷＷＷサーバとして機能するために必要なソフトウエアがインストールされている。このようなソフトウエアには、例えば、画像データを送信するためのＪＰＥＧ２０００用の通信プロトコルであるＪＰＩＰサーバとして機能するためのプログラムが含まれる。サーバ１０１は、例えば、ワークステーション（ＷＳ）、パーソナルコンピュータ（ＰＣ）等の情報処理装置によって実現される。
【００３１】
また、１０４は大容量の画像データを格納するＨＤ（Hard Disk）装置であり、ＪＰＥＧ２０００符号化方式で符号化された圧縮画像データが保存されている。ＨＤ装置１０４はサーバ１０１と通信可能に接続されている。
【００３２】
１０２及び１０３はクライアント・コンピュータ（以下、まとめてクライアント１０２と称する）である。クライアント１０２は、例えば、ＰＣやＷＳ、或いは、携帯電話、ＰＨＳ、携帯情報端末（ＰＤＡ）等で実現される。クライアント１０２には、Ｗｅｂページを閲覧するために必要なＷｅｂブラウザ等のソフトウエア、ＪＰＥＧ２０００符号化データをデコード／表示するためのソフトウエア、ＪＰＩＰのクライアント機能を実装したソフトウエア等がインストールされている。
【００３３】
（情報処理装置の構成）
次に、サーバ１０１の構成について図２を参照して説明する。図２は、サーバ１０１のハードウェア構成を示したブロック図である。
【００３４】
２０１はＣＰＵ（Central Processing Unit）であり、システム全体の制御などを行う。２０２はキーボードであり、２０１ａのマウスと共に、ユーザがシステムに情報等を指示入力するために使用される。
【００３５】
２０３は表示部であり、ＣＲＴ（Cathode Ray Tube）や液晶ディスプレイなどで構成される。２０４はＲＯＭ（Read Only Memory）、２０５はＲＡＭ（Random Access Memory）であり、システムの記憶装置を構成し、システムが実行するプログラムやシステムが利用するデータを記憶する。
【００３６】
２０６はハードディスク装置、２０７はフロッピー（登録商標）ディスク装置であり、システムのファイルシステムに使用される外部記憶装置を構成する。
【００３７】
２０８はプリンタである。２０９はネットワークを制御する部分であり、ここからインターネットなどのネットワーク上に接続されているクライアント１０２などの外部装置と通信する。
【００３８】
尚、本実施形態において、クライアント１０２もサーバ１０１と同様に、図２に示したハードウェア構成を備えるものとする。
【００３９】
（ＪＰＥＧ２０００符号化データ）
次に、一般的なＪＰＥＧ２０００の符号化データの概略について、図３を参照して説明する。図３は、ＪＰＥＧ２０００の符号化データの概略図である。
【００４０】
図３のように、ＪＰＥＧ２０００符号化データは、先頭のMain Header（メインヘッダ）データ３０１と１以上のタイル（Tile）データから構成される。
【００４１】
メインヘッダデータ３０１には、Resolution Level（解像度レベル）数、Layer（レイヤ）数など画像全体の符号化条件についての情報が記述されている。
【００４２】
タイルデータは、それぞれ、タイルパートヘッダ（Tile Header）３０２と、符号化データ３０６から構成される。タイルパートヘッダ３０２は、タイルの符号化条件を含む情報を記述したヘッダデータである。
【００４３】
タイルパートヘッダ３０２に後続する符号化データ３０６は、１以上のPacket（パケット）３０３という符号化単位データから構成される。図３のように、パケット３０３は、Packet Header（パケットヘッダ）３０４とPacket Body（パケットボディ、パケットデータ）３０５から構成される。パケットヘッダ３０４は当該パケットの符号化条件を含む情報が格納されている。このような情報には、例えば、コードブロックの存在の有無、０ビットプレーン情報、符号化パス数、コードブロックの圧縮データ長等が含まれる。パケットデータ（パケットボディ）３０５には当該パケット内に存在するコードブロックの圧縮データが格納されている。
【００４４】
図３は、Layer-Resolution level-Component-Position progression（ＬＲＣＰ）に沿ってパケットデータが記録されたＪＰＥＧ２０００ファイルを例示している。図３のように、ＬＲＣＰに準じた場合、符号化データはLayer / Resolution / Component / Positionの順でネスト（入れ子）状に構成される。このようなデータの並び順をProgression Orderと呼ぶ。Progression Orderには、ＬＲＣＰの他にも、例えば、SNR Progression等の符号順が存在する。本実施形態では、説明を簡単にするため、Resolution ProgressionのＪＰＥＧ２０００符号化データについて例示的に説明する。尚、ここで記されているPosition（ポジション、位置）とは、ＪＰＥＧ２０００符号化データにおけるPrecinct（プリシンクト）のことである。
【００４５】
図３のようにProgression OrderがＬＲＣＰの場合、各Layer（レイヤ）内は、Resolution（解像度）番号の小さい順にデータが格納されている。このため、ＬＲＣＰはResolution Progressionとも呼ばれる。レイヤ番号は復元する画像の原画に対するＳ／Ｎ比に対応し、レイヤ番号が小さいほどＳ／Ｎ比が悪くなる。一つのＪＰＥＧ２０００ファイル内での解像度番号とレイヤ番号、Component（コンポーネント）番号の最大値は、エンコーダによって予め設定され、そのパラメータにしたがってエンコードされており、その情報は符号化データの中に格納されている。
【００４６】
次に、解像度とサブバンドの関係について図４を参照して説明する。図４は、decomposition level(分割レベル)＝４の場合の、解像度とサブバンドの関係を模式的に示した図である。
【００４７】
図４において、４０１乃至４０５はＮL（分割レベル数）がそれぞれ０乃至４のサブバンドである。例えば、ＬＬ(ＮL＝０)４０１のサブバンドをデコードすることで解像度レベルが０の画像データを再現することができる。更に、ＨＬ(ＮL＝１)４０２ａ, ＬＨ(ＮL＝１)４０２ｂ, ＨＨ(ＮL＝１)４０２ｃの３つのサブバンドをデコードすることで解像度レベルが１の画像を再現することができる。同様に、ＮL＝２乃至４のサブバンドまでデコードすることで、それぞれ解像度レベルが２乃至４の画像を再現することができる。このように、再現したい解像度レベル及びその解像度レベルよりも低い解像度レベルに含まれるデータ（パケット）に基づいて、所望の解像度レベルの画像データを取得することができる。
【００４８】
図４のように、ＪＰＥＧ２０００符号化方式においては、解像度レベル番号が１増加する毎に、再現される画像データの画像サイズが幅、高さ共に２倍になっていく。図３で示したResolution Progressionの場合は、１つの解像度レベルの符号データは、レイヤ番号が小さい順に、コンポーネント番号が小さい順に、ポジション番号が小さい順になるように配列される。ここでのレイヤ番号は復元する画像の原画に対するＳ／Ｎ比に対応し、レイヤ番号が小さいほどＳ／Ｎ比が悪い、即ち、低解像度の画像データを再現することになる。
【００４９】
（ＪＰＩＰ通信）
次に、サーバ１０１（に接続されたＨＤ装置１０４）に格納されたＪＰＥＧ２０００符号化データをクライアント１０２へ送出する場合の通信の概要について、図５を参照して説明する。図５は、画像データに係るリクエスト（要求）とレスポンス（応答）の対応を示した概念図である。
【００５０】
本実施形態に係る構成では、画像データ（符号データ）の通信をＪＰＩＰを利用して行う。これによりクライアント１０２は圧縮画像データの全てを取得するのではなく、必要な部分のデータのみを取得することが可能である。
【００５１】
クライアント１０２が受信するデータの単位としては、ＪＰＥＧ２０００のパケット、或いは、パケットよりも大きい符号化単位であるタイル単位が考えられる。ここでは送受信するデータの単位をパケット単位とした場合について例示的に説明する。図５では、送受信するデータの単位がパケット単位である場合の、リクエストおよびレスポンスの様子を示している。
【００５２】
クライアント１０２はサーバ１０１に、画像のタイル番号、解像度レベル、レイヤ、コンポーネント、ポジション番号等の情報を指定して、データを要求する。要求５０１を受け取ると、サーバ１０１は、画像５０３のコードストリームを解析して、指定されたタイル番号、解像度レベルとレイヤ、コンポーネント、ポジション番号に相当するパケットデータを抜き出す。そして、これらの情報を含む応答５０２をクライアント１０２に送り返す。
【００５３】
次に、ＪＰＩＰを使ってパケットデータを送信単位として、データを送受信する場合のレスポンス（応答）データの構成を、図６および図７を使って説明する。
【００５４】
図６は、precinct data-binの構造の概略図である。ＪＰＩＰでは、図６の６０１に示すように、precinct data-binと呼ばれるＪＰＥＧ２０００のパケットデータの塊を基本としてレスポンスデータ（Response Data）を作成する。precinct data-binとは、タイル番号tnの中の、プリシンクト番号pnの解像度レベル rn、 コンポーネント番号cnを構成する全てのレイヤのパケットを、レイヤ番号が昇順になるように並べてつなげたデータの塊である。
【００５５】
図６に示すprecinct data-binから抜き出したPacket(tn, rn, cn, pn, 1)を使って、作成されたJPIP Response Dataの例を図７に示す。図７は、JPIP Response Data（応答データ）の一例を示した図である。ここで、Packet(tn, rn, cn, pn, qn)は、タイルtnの解像度レベルがrn, コンポーネント番号がcn, ポジション番号がpn, レイヤ番号がqnのパケットを示す。応答データは、message header（メッセージヘッダ）７０１とmessage body（メッセージボディ）７０３から構成される。メッセージヘッダとメッセージボディを合わせて、JPIP messageと呼ぶ。precinct data-binから作成されたJPIP messageをprecinct data-bin messageと呼ぶ。そして、メインヘッダから作成されたJPIP messageをmain header data-bin messageと呼ぶ。
【００５６】
precinct data-bin messageのメッセージボディ７０３には、precinct data-bin ６０１から切り出されたＪＰＥＧ２０００符号化データが格納される。例えば、図６のPacket(tn, rn, cn, pn, １)６０３を抜き出してJPIP Response Dataを作成する場合、Packet(tn, rn, cn, pn, １)６０３がメッセージボディ７０３に格納される。
【００５７】
メッセージヘッダ７０１は、４つのパラメータから構成される。即ち、１番目のパラメータは、メッセージボディ７０３に入っているデータがprecinct data-binであるか否かを示す識別子が格納される。
【００５８】
２番目のパラメータには、precinct data-bin ID(PrID)が格納される。これは、タイル番号tn, 解像度レベル番号rn, コンポーネント番号cn, プリシンクト番号pnから次式により一意に定まるパラメータである。
PrID(tn, rn, cn, pn)＝tn＋(cn＋s×(コンポーネント数))×タイル数
ただし、
s＝pn＋tn×(解像度レベルrnにおける１タイルあたりのプリシンクト数)
＋(解像度レベル０から(rn−１)までのタイルtnのプリシンクト数の総和)。
【００５９】
３番目のパラメータは、レスポンスデータのprecinct data-binにおけるオフセット値PrOffset ６０２である。つまり、メッセージボディ７０３に入っているデータが、PrID(tn, rn, cn, pn)のprecinct data-bin６０１において何Byte目からのデータであるのかを示す値であり、図６の６０２の値と等しい。
【００６０】
メッセージヘッダ７０１の４番目のパラメータは、Response Data（レスポンスデータ）のバイト長、即ち、メッセージボディ７０３のバイト長である。つまり、ResLen７０２には、ResLen[byte]７０４の値が格納される。
【００６１】
（諸条件例）
次に、本実施形態に係るシステムにおいて想定する画像データの符号化条件やクライアント１０２のスペック等についての諸条件について説明する。以下の諸条件は説明の便宜のために例示的に取り上げるものであり、本発明に係る実施形態がこれらの条件に限定されるわけではない。
【００６２】
サーバ１０１に格納されている圧縮画像データは、ファイル名が"a.jp2"であり、ＪＰＥＧ２０００符号化方式を用いて以下の条件で符号化されているものとする。
【００６３】
［符号化条件］
ファイル名：a.jp2
画像サイズ：６５５３６×６５５３６画素
タイルサイズ：５１２×５１２画素
タイル数：(６５５３６／５１２)×(６５５３６／５１２)＝１２８×１２８＝１６３８４個
色数：１
レイヤ数：１
解像度レベル数：９（０〜８）
解像度レベル８の画像サイズ：６５５３６×６５５３６画素
解像度レベル７の画像サイズ：３２７６８×３２７６８画素
解像度レベル６の画像サイズ：１６３８４×１６３８４画素
解像度レベル５の画像サイズ：８１９２×８１８２画素
解像度レベル４の画像サイズ：４０９６×４０９６画素
解像度レベル３の画像サイズ：２０４８×２０４８画素
解像度レベル２の画像サイズ：１０２４×１０２４画素
解像度レベル１の画像サイズ：５１２×５１２画素
解像度レベル０の画像サイズ：２５６×２５６画素
非圧縮時の画像のデータサイズ：６５５３６×６５５３６＝４０９６Ｍバイト
ファイルサイズ：  ５１２Ｍバイト（１／８の圧縮時）。
【００６４】
また、クライアント１０２に備えられた記憶装置の空き容量は画像データのサイズに比べて小さいものとする。ファイル”a.jp2”のデータサイズは圧縮時に５１２Ｍバイトであるが、クライアント１０２の記憶装置の空き容量は、例えば、２５６Ｍバイトであるとする。ただし、記憶装置の空き容量とは、例えば、ＲＡＭ２０５やハードディスク２０６等の空き容量の合計値である。
【００６５】
クライアント１０２は、ＪＰＩＰで受信した断片的な符号データをキャッシュし、新たな画像表示の指示がユーザから入力されたときに、キャッシュに無い符号データをサーバ１０１に要求する。このキャッシュデータは、受信した符号データを管理するための情報などが必要であり、符号データの追加や削除などの処理を簡単に行うような形式で管理されるべきである。このため、ＪＰＥＧ２０００符号データの形式とは別の形式で管理される場合が多い。
【００６６】
本実施形態に係る構成においても、クライアント１０２上のキャッシュデータはＪＰＥＧ２０００符号データとは別の形式で管理される。このため、ＪＰＥＧ２０００のデコーダで符号データをデコードするには、このキャッシュ形式で管理された符号データをＪＰＥＧ２０００準拠の符号データの形式に変換する必要がある。
【００６７】
このようなキャッシュ機構を設ける場合、変換の際に生成される一時的なファイルを考慮すると、クライアント１０２はキャッシュデータを管理する領域とＪＰＥＧ２０００符号データを管理する領域の両方を記憶装置上に有している必要がある。このことは、クライアント１０２が必要な記憶容量は、サーバ１０１で保管されているＪＰＥＧ２０００ファイルのバイト数の２倍必要であることを意味する。例えば、サーバ１０１でのファイルサイズが５１２Ｍバイトの場合、クライアント１０２が必要な記憶装置の空き容量は、例えば、約１０２４Ｍバイトとなる。従って、クライアント１０２の記憶装置の空き容量が２５６Ｍバイトの場合、全てのキャッシュファイルを作成することもできず、キャッシュからＪＰＥＧ２０００符号データを作成することができない。
【００６８】
本実施形態に係る構成は、上記のような環境においてもクライアント１０２が画像データをデコードし、表示することを可能にするものである。以下、サーバ１０１がクライアント１０２にファイル”a.jp2”をＪＰＩＰを利用して送信し、クライアント１０２がデコード・表示等を行う場合における、サーバ１０１の動作について説明する。
【００６９】
（全体処理）
本実施形態において、サーバ１０１は、ある解像度の画像データの送信要求をクライアン１０２から受け取った場合、その解像度の画像をデコードするのに必要でない部分の符号データを全て長さが０のパケットに置き換えてクライアント１０２へ送出する。長さが０のパケットは”Zero Length Packet”と呼ばれ、以下、ＺＬＰと称する。
【００７０】
以下、クライアント１０２が、レベル１の解像度、すなわち５１２×５１２画素の画像を表示すべくサーバ１０１へリクエストを送出した場合について例示的に説明する。この時、クライアント１０２によって発行されるリクエストの内容は、例えば、次のようなＪＰＩＰコマンドの記述となる。
http://www.image.com/JPIP.cgi?target=a.jp2&fsize=512,512&type=jpp-stream
以下、このコマンドをＪＰＩＰコマンド１と呼ぶ。
【００７１】
次に、図８を参照してサーバ１０１が実行する全体処理の流れについて説明する。図８は、サーバ１０１処理の全体のフローを示したフローチャートである。
【００７２】
まず、ステップＳ８００ではクライアント１０２からの通信要求の受信に対応して、クライアント１０２とのセッションを開く処理を行う。
【００７３】
次に、ステップＳ８０１において、クライアント１０２に対して符号ファイル最大容量（以下、ＢＳと称する）を、例えば、バイト数単位で問い合わせを行い、その値を取得する。これは、例えば、ＢＳを問い合わせる旨のパケットをクライアント１０２へ送出し、その応答を受信、解析することによって行う。
【００７４】
ステップＳ８０１に対応して、クライアント１０２は、上述のようにキャッシュデータと符号データの２種類のファイル群を管理する場合には、クライアント１０２側の記憶容量の半分の値を符号データとして確保できるサイズとして返す。本実施形態の場合は、一時ファイルの容量が２５６Ｍバイトであるため、符号データとして利用できる容量は半分の１２８Ｍバイトである、
次に、ステップＳ８０２において、クライアント１０２から上記ＪＰＩＰコマンドを受信する。
【００７５】
次に、ステップＳ８０３では、ステップＳ８０２で受信したＪＰＩＰコマンドの解析を行う。具体的には、要求された画像ファイルや、解像度レベル等の情報を取得する。
【００７６】
次に、ステップＳ８０４では、ステップＳ８０３でのコマンド解析結果に基づき、要求されたファイルから返送に必要な符号データを切り抜き、返送符号データを作成する返送符号データ作成処理を行う。この処理の詳細は後述する。
【００７７】
次に、ステップＳ８０５では、ステップＳ８０４で作成した返送データをクライアント１０２に送信する。
【００７８】
次に、ステップＳ８０６で今回のセッションを終了するか否かを判定する。この判定は、例えば、クライアント１０２から最後のパケットを受信してから所定の時間が経過したか否かや、クライアント１０２からセッション終了の旨のパケットを受信したか否か等に基づいて行う。
【００７９】
セッションを終了しないと判定した場合（ステップＳ８０６でＮＯ）には、ステップＳ８０２に戻り、ステップＳ８０２乃至Ｓ８０５の処理を繰り返す。一方、セッションを終了すると判定した場合（ステップＳ８０６でＹＥＳ）には、ステップＳ８０７へ進む。
【００８０】
ステップＳ８０６においては、クライアント１０２とのセッションを閉じる処理を行う。例えば、クライアント１０２との通信を行うために一時的に作成したオブジェクト等をメモリから解放する等の処理を行う。そして、サーバ１０１での処理を終了する。
【００８１】
（返送符号データ作成処理）
次に図９を参照して、ステップＳ８０４で実行する返送符号データ作成の詳細なフローを説明する。図９は返送符号データ作成処理の流れを示したフローチャートである。
【００８２】
まず、ステップＳ９００では、ステップＳ８０３において解析結果を参照して、今回要求されているターゲットファイルのバイト数を取得する。そして、ステップＳ８０１で取得したクライアント１０２側の符号データ最大容量ＢＳの値と、要求されているターゲットファイルのバイト数との大小を比較する。
【００８３】
この比較の結果、ＢＳの値がターゲットファイルのバイト数以上の場合（ステップＳ９０４でＮＯ）はステップＳ９０４に進み、ステップＳ８０３でのコマンド解析結果の基づいて、通常の処理により返送用のデータを作成する処理を行う。その後、ステップＳ９０５にて、ステップＳ９０４で作成した返送用データの用のＪＰＩＰヘッダを作成する。これらの処理は公知であるため、詳細な説明は割愛する。ステップＳ９０５の処理の後、サーバ１０１は返送符号データ作成処理を終了して、図８のステップＳ８０５へ進む。
【００８４】
一方、ステップＳ９００において、値ＢＳがファイルサイズより小さい場合（ステップＳ９０４でＹＥＳ）、ステップＳ９０１へ進む。
【００８５】
ステップＳ９０１では、クライアント１０２側で今回のターゲットファイルは全てキャッシュする能力がないと判断し、クライアント１０２においてキャッシュレスで処理できるように、キャッシュレスデータを生成する処理を行う。この処理の詳細については、後に図１０を用いて詳細に説明する。
【００８６】
次にステップＳ９０２では、ステップＳ９０１で作成したキャッシュレスデータ用の返送用のＪＰＩＰヘッダを生成する。具体的にはサーバ１０１でtypeパラメータを”type=RAW”、あるいは”type=jp2”に変更したレスポンスヘッダを作成する。例えば、本実施形態の場合、クライアント１０２は前述したＪＰＩＰコマンド１のように”jpp-stream”を要求しているが、”type=RAW”、あるいは”type=jp2”に変更する。このＪＰＩＰレスポンスヘッダを受け取ったクライアント１０２は、このＪＰＩＰレスポンスヘッダを参照することによって、受信したデータを、キャッシュをせずに直接ＪＰＥＧ２０００のデコーダで処理するものと判断することができる。
【００８７】
ステップＳ９０２の処理の後、サーバ１０１は返送符号データ作成処理を終了して、図８のステップＳ８０５へ進む。
【００８８】
（キャッシュレスデータ作成処理）
次に、図１０を参照して、図９のステップＳ９０１において実行するキャッシュレスデータ作成処理について説明する。図１０は返送符号データ作成処理において実行するキャッシュレスデータ作成処理の流れを示したフローチャートである。
【００８９】
まず、ステップＳ１０００において、ターゲットファイルのＪＰＥＧ２０００符号データのメインヘッダをリード、解析し、エンコード条件等の情報を取得する。
【００９０】
次に、ステップＳ１００１では、ステップＳ８０３で解析したＪＰＩＰコマンドで要求されている符号データがターゲットファイル内のどのパケットに対応するかを判断し、返送するパケットを特定する。この特定の処理は公知技術と知られているため詳細な説明は割愛する。例えば、前述したＪＰＩＰコマンドの場合は、解像度レベル１までの全てのタイルを構成するパケットを返送するパケットとして特定する。
【００９１】
次に、ステップＳ１００２では、ターゲットファイルのヘッダをそのまま返信データに追加する。
【００９２】
次に、ステップＳ１００３−１乃至ステップＳ１００７−５の処理によって、要求された解像度レベルの画像を復号するために必要なパケットを返送データに追加し、それ以外のパケットはＺＬＰに置き換える処理を行う。
【００９３】
このような処理を画像データを形成する全てのパケットについて行うために、まず、ステップＳ１００３−１乃至ステップＳ１００３−５において、参照するパケットを特定するパラメータ変数を初期化する処理を行う。即ち、まず、ステップＳ１００３−１では、タイル特定するための変数Ｔを値０にして初期化する。次に、ステップＳ１００３−２では、レイヤを特定するための変数Ｌを値０にして初期化する。次に、ステップＳ１００３−３では、解像度レベルを特定するための変数Ｒを値０にして初期化する。次に、ステップＳ１００３−４では、コンポーネント（Component）を特定するための変数Ｃを値０にして初期化する。次に、ステップＳ１００３−５では、ポジション（Position）を特定するための変数Ｐを値０にして初期化する。
【００９４】
次に、ステップＳ１００５では、上記各変数（Ｔ，Ｌ，Ｒ，Ｃ，Ｐ）で識別されるパケットが、ステップＳ１００１で特定されたパケット（即ち、返送パケット）に該当するか否かを判定する。
【００９５】
返送パケットに該当しない場合（ステップＳ１００５でＮＯ）はステップＳ１００８へ進み、各変数（Ｔ，Ｌ，Ｒ，Ｃ，Ｐ）で識別されるパケットをＺＬＰに置き換える処理を行う。一方、ステップＳ１００５で返送パケットであると判断された場合（ステップＳ１００５でＹＥＳ）には、ステップＳ１００６へ進み、返送データに各変数（Ｔ，Ｌ，Ｒ，Ｃ，Ｐ）で識別されるパケットを追加する。ステップＳ１００８、Ｓ１００６の処理が終了したら、それぞれステップＳ１００７−１へ進む。
【００９６】
ステップＳ１００７−１からステップＳ１００７−５までは、各変数をインクリメントし、最後まで処理したか否かを判断する。
【００９７】
即ち、ステップＳ１００７−１においては、変数Ｐをインクリメント、即ち、１増加する。そして、この時点で変数Ｃで識別されるコンポーネント中の、全てのポジションについて、ステップＳ１００５とそれに続く処理を行ったか否かを判定する。処理を行った場合（ステップＳ１００７−１でＹＥＳ）はステップＳ１００７−２へ進む。処理を行っていない場合（ステップＳ１００７−１でＮＯ）はステップＳ１００５へ戻り、処理を繰り返す。
【００９８】
ステップＳ１００７−２においては、変数Ｃをインクリメント、即ち、１増加する。そして、この時点で変数Ｒで識別される解像度レベルにおける画像データ中の、全てのコンポーネントについて、ステップＳ１００５とそれに続く処理を行ったか否かを判定する。処理を行った場合（ステップＳ１００７−２でＹＥＳ）はステップＳ１００７−３へ進む。処理を行っていない場合（ステップＳ１００７−２でＮＯ）はステップＳ１００３−５へ戻り、処理を繰り返す。
【００９９】
ステップＳ１００７−３においては、変数Ｒをインクリメント、即ち、１増加する。そして、この時点で変数Ｌで識別されるレイヤ中の、全ての解像度レベルの画像データについて、ステップＳ１００５とそれに続く処理を行ったか否かを判定する。処理を行った場合（ステップＳ１００７−３でＹＥＳ）はステップＳ１００７−４へ進む。処理を行っていない場合（ステップＳ１００７−３でＮＯ）はステップＳ１００３−４へ戻り、処理を繰り返す。
【０１００】
ステップＳ１００７−４においては、変数Ｌをインクリメント、即ち、１増加する。そして、この時点で変数Ｔで識別されるタイル中の、全てのレイヤについて、ステップＳ１００５とそれに続く処理を行ったか否かを判定する。処理を行った場合（ステップＳ１００７−４でＹＥＳ）はステップＳ１００９へ進む。処理を行っていない場合（ステップＳ１００７−４でＮＯ）はステップＳ１００３−３へ戻り、処理を繰り返す。
【０１０１】
ステップＳ１００９においては、各タイルの先頭にあるタイルパートヘッダを調整する。即ち、タイルパートヘッダにはタイルパートを構成する全パケット長を記述する部分があるが、ＺＬＰへの置き換えによって変動したタイルパートの長さに合わせてパケット長の記述を修正する。そして、ステップＳ１００７−５へ進む。
【０１０２】
ステップＳ１００７−５においては、変数Ｔをインクリメント、即ち、１増加する。そして、画像データ中の全てのタイルについて、ステップＳ１００５とそれに続く処理を行ったか否かを判定する。処理を行った場合（ステップＳ１００７−５でＹＥＳ）はキャッシュレスデータ作成処理を終了し、図９のステップＳ９０２へ進む。処理を行っていない場合（ステップＳ１００７−５でＮＯ）はステップＳ１００３−２へ戻り、処理を繰り返す。
【０１０３】
以上の処理により、要求された解像度レベルの全てのタイルを構成するパケットが含まれ、要求されなかったパケットはＺＬＰで置き換えられた、返送データとしてのＪＰＥＧ２０００符号データを作成することができる。例えば、上記の例では、解像度レベル０から解像度レベル１までを構成する全てのパケットが追加され、それ以外のパケットはＺＬＰに置き換えられた返送データを作成することができる。
【０１０４】
この場合、クライアント１０２は、キャッシュを行う必要なく、サーバ１０１から受け取った符号データをそのままデコードし、画像を表示することが可能となる。また本実施形態の場合、不必要な部分のパケットをＺＬＰで置き換えるだけで、再エンコードを行っていないため、要求した部分に関しては、画質劣化などは全くない。さらにサーバ１０１の処理は、基本的に、不必要な部分のパケットをＺＬＰで置き換えるのみであるため、サーバ１０１に要する処理の負荷は比較的小さい。
【０１０５】
＜＜第２実施形態＞＞
第１実施形態では、メインヘッダを変更しないで、不要な部分のパケットをＺＬＰで置き換える構成について説明した。本実施形態では、要求された部分の符号データのみから構成される、即ち、ＺＬＰすらも返送データに含まれない返送データを作成する構成について説明する。本実施形態の構成においては、返送データが要求された部分の符号データのみから構成されるようにするために、メインヘッダを適宜変更する処理を行う。
【０１０６】
本実施形態に係る構成は特に断らない限り第１実施形態の構成と同様であり、構成や処理の相違点についてのみ説明を行う。本実施形態に係る構成が実行する全体処理と返送符号データ作成処理は第１実施形態と同様であり、それぞれ図８，９のフローチャートで示される処理を実行する。
【０１０７】
本実施形態に係る構成が実行するキャッシュレスデータ作成処理について、図１１を参照して説明する。図１１は、本実施形態に係る構成が実行するキャッシュレスデータ作成処理の流れを示したフローチャートである。
【０１０８】
図１１において、図１０で説明したフローと同じ動作をする部分については、同一の番号を付しており、説明を省略する。第１実施形態と異なる部分は、ステップＳ１００５の判断で返送パケット以外であると判断された場合（ステップＳ１００５でＮＯ）の処理と、ステップＳ１００２の代わりにステップＳ１１００を実行することである。
【０１０９】
ステップＳ１００５で返送パケット以外と判断された場合（ステップＳ１００５でＮＯ）、本実施形態の場合は、要求されたパケットのみ返送するため、なにも処理しないで単にステップＳ１００６を進むように動作すればよい。
【０１１０】
ステップＳ１１００では、ステップＳ８０３及びステップＳ１００１の結果から符号データのメインヘッダを変更する処理を実行する。メインヘッダの変更について図１２乃至１４を参照して説明する。図１２はメインヘッダ３０１のマーカセグメントの構成を模式的に示した図である。
【０１１１】
図１２のように、メインヘッダ３０１は、必須のマーカセグメントとして、ＳＯＣマーカ、ＳＩＺマーカセグメント１２０１、ＣＯＤ１２０２、ＱＣＤ、ＰＯＣを含む。図１２におけるその他のマーカはオプションであり、エンコードオプションに基づいて挿入される場合がある。
【０１１２】
ステップＳ１１００では、図１２に示すメインヘッダ内のＳＩＺマーカセグメント１２０１と、ＣＯＤマーカセグメント１２０２内の該当するフィールドを変更する。
【０１１３】
ＳＩＺマーカセグメント１２０１には画像データの画像サイズ、リファレンスグリッドの縦横長、タイルの縦横長、コンポーネント数等の情報が記述される。図１３はＳＩＺマーカセグメントの詳細な構成を模式的に示した図である。図１３において、”Xsiz”１３０１と“Ysiz”１３０２が画像データの画像サイズを記入するフィールドである。ステップＳ１１００では、この２つのフィールドを変更する。これ以外のフィールドは変更する必要はない。
【０１１４】
ＣＯＤマーカセグメント１２０２には分割レベル数、符号化スタイル、レイヤ化の情報等が記述される。図１４はＣＯＤマーカセグメントの詳細な構成を模式的に示した図である。
【０１１５】
この図の中の、”Number of decomposition levels”（分割レベル数）１４０１が解像度方向の階層数が記入されるフィールドである。ステップＳ１１００では、適宜この値を変更する。ＣＯＤマーカセグメントの他のフィールドは変更する必要はない。
【０１１６】
例えば、上記に例示した画像データの場合、各フィールドにセットする値は次のようになる。即ち、ＳＩＺマーカ・セグメント内のXsizフィールド１３０１には”５１２”を、Ysizフィールド１３０２には”５１２”をセットする。そして、ＣＯＤマーカ・セグメント内の”Number of decomposition levels”（分割レベル数）フィールド１４０１には、”１”をセットする。ステップＳ１１００では、このように値をセットした後、新しいメインヘッダとして出力する。
【０１１７】
この符号データを受け取ったクライアント１０２は、このメインヘッダを解析し、画像サイズが５１２×５１２で、階層数が１の符号データとして識別する。そして、この識別結果に基づいて画像データをデコードする。メインヘッダに続くデータは、この識別結果に合致して配列されているためクライアント１０２は画像データをデコードし、表示することができる。
【０１１８】
本実施形態の場合でも、符号データの再エンコードを行っていないため、画質劣化はない。また、本実施形態に係る構成によって生成される返送データはクライアント１０２から要求されたパケットのみから構成されＺＬＰを含まないため、第１実施形態の構成に比較して、返送データのサイズを更に小さくすることができる。
【０１１９】
また、サーバ１０１の処理は、基本的に、必要な部分のパケットを返送データに追加し、メインヘッダ内の固定フィールドのみを変更するだけであり、サーバ１０１に要する処理の負荷は比較的小さい。
【０１２０】
＜＜第３実施形態＞＞
第１、第２実施形態に係る構成において生成される返送データには、解像度方向の階層は残ったままであった。これは、要求された画像データをデコードするための必要な部分のパケットデータを、基本的には、サーバ１０１に格納されている構造のまま返送データを構成するからである。
【０１２１】
本実施形態に係る構成は、画像データの、クライアント１０２から要求された部分を再エンコードし、最低解像度データのみの構造、すなわちＬＬサブバンドのみの形式で返送する。即ち、指定された解像度レベル及び指定された解像度レベルよりも低い解像度レベルに含まれるパケットを合成して、指定された解像度レベルの画像データを生成する処理を実行して、返送データを生成する。
【０１２２】
なお、本実施形態に係る構成においても、第２実施形態と同様に、返送データがクライアント１０２から要求された部分のみの符号データになるようにメインヘッダなどを変更する。また、クライアント１０２からのＪＰＩＰコマンドは、第２実施形態と同様に、第１実施形態で示したもの（ＪＰＩＰコマンド１）と同じとする。
【０１２３】
本実施形態に係る構成は特に断らない限り第１実施形態の構成と同様であり、構成や処理の相違点についてのみ説明を行う。本実施形態に係る構成が実行する全体処理と返送符号データ作成処理は第２実施形態と同様であり、それぞれ図８，９のフローチャートで示される処理を実行する。
【０１２４】
図１５は、本実施形態に係る構成が実行するキャッシュレスデータ作成処理の流れを示したフローチャートである。図１５中、図１１で説明したフローと同じ動作をする部分については、同一の番号を付けてある。
【０１２５】
まず、ステップＳ１０００では、第１実施形態および第２実施形態と同様に、ターゲットファイルのＪＰＥＧ２０００符号データのメインヘッダをリード、解析し、エンコード条件等の情報を取得する。
【０１２６】
次に、ステップＳ１５００では、ステップＳ１０００で解析したターゲットファイルのメインヘッダとステップＳ８０３での解析結果に基づいて、要求された画像データを取得するためにデコードが必要なターゲットファイルの部分を特定する。具体的には、デコードが必要な解像度方向の階層や、要求された画像データの領域が含まれるタイル等の情報を取得する。第１実施形態で取り上げたＪＰＩＰコマンドの例の場合、デコードするタイルは全てのタイルであり、デコードする解像度方向の階層数は１までである。
【０１２７】
次に、ステップＳ１５０１、Ｓ１５０２において、指定された解像度レベル及び指定された解像度レベルよりも低い解像度レベルに含まれるパケットを合成して、指定された解像度レベルの画像データを生成する処理を実行する。
【０１２８】
ステップＳ１５０１ではステップＳ１５００で特定したパラメータに基づいてターゲットファイルをデコードし、画像データを取得する。
【０１２９】
次に、ステップＳ１５０２において、ステップＳ１５０１で得た画像データをＬＬサブバンドのみの形式でエンコードする。即ち、「タイル分割なし」、「画像サイズは要求された領域を含むタイル境界のサイズ」、「解像度方向の階層数はなし」のエンコード条件でエンコードする。そして、エンコードして取得されたデータを返送する符号データ（返送データ）とする。
【０１３０】
尚、エンコード時には、メインヘッダ内のパラメータも返送データの特性に合わせて適宜修正されるようにエンコードのパラメータを設定してエンコードを行う。例えば、上述した例の場合、ＳＩＺマーカセグメント１２０１内のXsizフィールド１３０１には”５１２”を、Ysizフィールド１３０２には”５１２”を、XTsizフィールドには”５１２”を、YTsizフィールドには”５１２”をセットする。これにより、クライアント１０２から要求された画像データを、ＬＬサブバンドで再エンコードした符号データとして作成することができる。
【０１３１】
本実施形態の場合は、クライアント１０２側のデコード処理対象は、ＬＬサブバンドのみでかつ、タイル分割もない符号データである。このため、クライアント１０２はデコード処理を高速に実行することができる。またサーバ１０１が実行するエンコード処理はＬＬサブバンドについてのみであるため、高速に実行することができる。
【０１３２】
以上説明したように、本発明に係る実施形態の構成においては、クライアント１０２側のコンピュータの性能、特に一時ファイルとして作成できる記憶装置の容量に応じて、“RAW”あるいは、”JP2”モードの返送データを作成する。具体的には、クライアント１０２の記憶容量がターゲットファイルのファイルサイズ以上（具体的には２倍以上のバイト数）確保できない場合は、ＪＰＩＰコマンドに指定された返送画像タイプに関係なく、必ず“RAW”あるいは、”JP2”モードで返送する。これにより、クライアント１０２はデータをキャッシュする必要が無く、サーバ１０１から受け取った符号データを直接デコードし、表示することが可能となる。この結果、クライアント１０２側の処理を軽減することができる。
【０１３３】
一方、サーバ１０１側の処理に係る負荷も上記のように小さい。このため、サーバ１０１側での処理が多少増えても、従来の、クライアント１０２側でキャッシュデータからＪＰＥＧ２０００の符号データを再構築した後にデコード、表示する場合の構成よりも、本発明に係る実施形態の構成のスループットのほうが良好である。即ち、クライアント１０２が、サーバ１０１に対して要求を発行してから、通信し、結果を表示するまでの時間を短縮することが可能となる。
【０１３４】
また、本発明に係る実施形態の構成によれば、クライアント１０２のデコードに係る負荷を軽減することができるため、ＣＰＵ性能等の演算能力が低いクライアント１０２も高速に画像データのデコード、表示を行うことができる。
【０１３５】
特に、サーバ１０１側でＬＬサブバンドのみの符号データに変換する場合は、クライアント１０２側でのデコード時間を、階層デコードする場合に比べ、大幅に短縮することが可能となる。例えば、サムネイル表示を行うようなアプリケーションにおいては、画像の全体を高速で表示する必要がある。このようなアプリケーションにおいては、タイル分割されておらずＬＬサブバンドのみの符号データを提供することが特に有効である。
【０１３６】
＜＜その他の実施形態＞＞
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３７】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１３８】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【０１３９】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１４０】
プログラムを供給するための記録媒体としては、例えば、次のものが含まれる。即ち、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）等が含まれる。
【０１４１】
その他、プログラムの供給形態としては、次のようなものも考えられる。即ち、クライアント装置のブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明に係るコンピュータプログラム、或いは、圧縮され自動インストール機能を含むファイルをＨＤ等の記録媒体にダウンロードする形態も考えられる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１４２】
また、次のような供給形態も考えられる。即ち、まず、本発明に係るプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報の使用により暗号化されたプログラムを実行してコンピュータにインストールさせて本発明に係る構成を実現する。このような供給形態も可能である。
【０１４３】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他次のような実現形態も想定される。即ち、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１４４】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づいも前述した実施形態の機能が実現される。即ち、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１４５】
【図１】ネットワーク上に複数のコンピュータが接続されている様子を示した図である。
【図２】サーバのハードウェア構成を示したブロック図である。
【図３】ＪＰＥＧ２０００の符号化データの概略図である。
【図４】解像度とサブバンドの関係を模式的に示した図である。
【図５】画像データに係るリクエストとレスポンスの対応を示した概念図である。
【図６】precinct data-binの構造の概略図である。
【図７】JPIP Response Dataの一例を示した図である。
【図８】サーバ処理の全体のフローを示したフローチャートである。
【図９】返送符号データ作成処理の流れを示したフローチャートである。
【図１０】第１実施形態におけるキャッシュレスデータ作成処理の流れを示したフローチャートである。
【図１１】第２実施形態におけるキャッシュレスデータ作成処理の流れを示したフローチャートである。
【図１２】メインヘッダのマーカセグメントの構成を模式的に示した図である。
【図１３】ＳＩＺマーカセグメントの詳細な構成を模式的に示した図である。
【図１４】ＣＯＤマーカセグメントの詳細な構成を模式的に示した図である。
【図１５】第３実施形態におけるキャッシュレスデータ作成処理の流れを示したフローチャートである。
【図１】
2007053445.tif 000003
【図２】
2007053445.tif 000004
【図３】
2007053445.tif 000005
【図４】
2007053445.tif 000006
【図５】
2007053445.tif 000007
【図６】
2007053445.tif 000008
【図７】
2007053445.tif 000009
【図８】
2007053445.tif 000010
【図９】
2007053445.tif 000011
【図１０】
2007053445.tif 000012
【図１１】
2007053445.tif 000013
【図１２】
2007053445.tif 000014
【図１３】
2007053445.tif 000015
【図１４】
2007053445.tif 000016
【図１５】
2007053445.tif 000017