JP2006339972A - 画像処理装置及びその制御方法、コンピュータプログラム、記憶媒体 - Google Patents

Abstract

【課題】 リソースに制約が課せられた携帯情報機器においても高画質の画像データを閲覧可能とする技術を提供する。
【解決手段】 本発明によれば、複数のレイヤから構成された画像データを解像度レベル毎に記憶する記憶手段と、外部装置から、少なくとも前記画像データの前記解像度レベルと領域の大きさとの指定が含まれる送信要求を受信する受信手段と、指定された前記解像度レベルと前記領域の大きさとの少なくともいずれかに基づいて、指定された前記解像度レベルに対応する複数のレイヤの合成を行うか否かを判定する判定手段と、前記判定手段において前記合成を行うと判定された場合に、指定された前記解像度レベルに対応する複数のレイヤを合成して、１レイヤで構成される画像データを生成する合成手段と、生成された前記１レイヤで構成される画像データを前記外部装置へ送出する送出手段と、を備えることを特徴とする画像処理装置が提供される。
【選択図】 図１１

Description

本発明は階層化された画像データを送受信する技術に関する。

近年、２００万〜５００万画素程度の画像を撮像可能な家庭用デジタルカメラが普及している。業務用のデジタルカメラは、１０００万画素クラスのものが普及している。デジタルカメラは、今後も高精細化されていくと想定される。

また、デジタルカメラ等で撮影した画像データを、ネットワーク経由で受け取り、該画像データをネットワーク上で公開する、オンラインのアルバムサービスが普及している。アルバムサービスは、受け取った画像データを公開するサーバと、ネットワーク経由でサーバにアクセスし、公開された画像データを閲覧するクライアントからなるシステムによって実現される。

このようなクライアント・サーバシステムにおけるクライアント機器として、近年、ＰＤＡ（Personal Digital Assistance）端末等の、携帯型の情報処理端末（携帯情報機器）も用いられるようになってきた。

一方、アルバムサービスのアプリケーションでは、サムネイル画像による一覧表示を行い、一覧表示した画像中から、拡大して表示したい画像の選択を受け付け、選択された画像をサムネイル画像よりも大きく表示するインタフェースが一般的に採用されている。

しかし、大きな画素数を持つ近年のデジタルカメラにより撮像された画像データを、拡大表示のたびに全てサーバからダウンロードするような構成においては、拡大画像を要求してからクライアント端末に画像が表示されるまでに、長い待ち時間を必要とする。

このような問題を解決するために、複数の解像度レベル毎に複数のレイヤから構成され、さらに各解像度レベルのデータを複数のタイルに分割し符号化した画像データをサーバに保存し、表示に必要な部分データのみをダウンロードしてクライアント上に表示する技術が開発されている。このような技術として、ＪＰＥＧ２０００（Joint Photographic Experts Group 2000）やＪＰＩＰ（JPEG2000 image coding system - Part 9: Interactivity tools, APIs and protocols）等を利用した構成が知られている。

ＪＰＥＧ２０００とは、２００１年に標準化された画像符号化方式である。この方式によれば、画像データは、複数の解像度レベル毎に複数のレイヤから構成され、更にタイル分割されるように符号化される。ここで、レイヤとは、複数の画質で画像を閲覧可能なように、グループ分けされた符号化データのまとまりである。レイヤ構造においては、閲覧者に伝達する情報量への寄与が大きい符号順に上位レイヤから下位レイヤへと符号化データが配置されている。そして、ある下位レイヤの符号化データは、そのレイヤの上位のレイヤにおける符号化データに対する差分の情報が記述されている。このため、上位のレイヤの符号化データをデコードすれば、ある程度の情報量を伝達することが可能な画像を提供できる一方、下位のレイヤまでデコードすれば、より高画質の画像を提供することができる。

ＪＰＩＰとは、ＪＰＥＧ２０００の方式で符号化された画像ファイルへアクセスし、画像データをレイヤ、解像度レベル、タイル等の所望の形態で取得して表示するための、クライアント・サーバ間のプロトコル、ＡＰＩ（Application Interface）、ツール等を規格化したものであり、現在、仕様策定中である。

ＪＰＥＧ２０００を利用した構成として、特許文献１には、ＪＰＥＧ２０００で符号化された画像データの部分データをサーバ・クライアントで送受信するシステムが開示されている。この構成において、クライアントは、サーバに格納されているコードストリームのどの部分が、既にクライアントのバッファに格納されているかを判別し、未だバッファに格納していない圧縮データの部分をサーバに要求する。一方、サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。クライアントは、受信したデータと既にバッファに格納されたデータを統合することで、画像を取得する。

また、特許文献２には、サーバ側に格納されているＪＰＥＧ２０００符号データを、クライアント側で高速にプログレッシブ表示するための技術が開示されている。この構成において、クライアントは、欲しい解像度レベルを指定するリクエストを発行し、サーバへ送出する。サーバは、クライアントから指定された解像度レベルのサブバンド符号データを、格納された画像ファイルから取り出してクライアントに送信する。クライアントは、表示している画像の解像度レベルの、復号化されたサブバンドの係数と、サーバから受信した符号データを復号して得られたサブバンドの係数とに基づいて画像データを復元することで、プログレッシブ表示を実現している。

上記のようなＪＰＥＧ２０００を利用した構成では、クライアントからの要求に応じて、ユーザの望む画像サイズ（解像度レベル）、レイヤ、部分領域（タイル）のデータを、サーバ側に格納されているＪＰＥＧ２０００符号化データから抜き出して、送受信する。

また、上記の構成において、サーバ・クライアント間でＪＰＥＧ２０００の画像データを効率的に送受信するために、クライアントは、受信したデータをキャッシュ（保存）しておく必要がある。これは、ＪＰＥＧ２０００符号化データにおいては、ある解像度レベルの画像データは、その解像度より１レベル低い解像度レベルの画像データに対する差分として表現されるためである。また、上述のように、ある下位レイヤの符号化データは、そのレイヤの上位のレイヤにおける符号化データに対する差分として構成されているためである。

このように、既に受信したデータをクライアント側でキャッシュしておくことで、拡大したり、画質を向上させたりする際に、クライアント・サーバ間で送受信するデータは、受信済みのデータとの差分データのみとなる。これにより、クライアント・サーバ間の通信データ量を削減することができる。
特開２００３−２３６３０号公報 特開２００４−４０６７４号公報

しかし、クライアント機器としてネットワークや公衆回線に接続するための通信手段を備えた携帯型の情報処理端末（携帯情報機器）が用いられる場合、携行性、電池駆動時間等の制約条件から携帯情報機器の演算処理性能、記憶容量等のリソースに大幅な制約が課せられることになる。このため、サーバ側から複雑な情報が転送されても、クライアント上で正常に処理できない事態が想定される。

特に、ＪＰＥＧ２０００方式に基づく符号化データはその構造が複雑であるため、携帯情報機器のクライアントは全ての機能をサポートしたデコーダを搭載していない可能性がある。例えば、クライアントに搭載されたデコーダは、画質方向のスケーラビリティに対応していない、即ち、複数のレイヤから構成された画像データを復元して画像を再生できない可能性がある。この場合、複数のレイヤを持つＪＰＥＧ２０００画像データを保有するサーバに対して、最高画質の画像データを要求すると、上記従来の構成においては、サーバに格納されている画像データから該当するデータを抜き出して返送するため、１layerの画像データ（最初の画質データ）のみしかデコードできないクライアントは、低画質で粗い画像しか見ることが出来ない。

また、上記従来の構成においては、クライアント上で、解像度レベル、レイヤ（画質）、タイルの３つの要素によって分解された部分データをキャッシュし、次のインタラクティブな操作に利用する必要がある。この場合、クライアントはキャッシュデータを管理する仕組みを搭載しなければならないが、リソースに制約が課せられた携帯情報機器にとってこれらの処理は大きな負荷となる。

本発明は上記問題に鑑みなされたものであり、リソースに制約が課せられた携帯情報機器においても高画質の画像データを閲覧可能とする技術を提供することを目的とする。

上記目的を達成するため、本発明による画像処理装置は以下の構成を備える。即ち、
複数のレイヤから構成された画像データを解像度レベル毎に記憶する記憶手段と、
外部装置から、少なくとも前記画像データの前記解像度レベルと領域の大きさとの指定が含まれる送信要求を受信する受信手段と、
指定された前記解像度レベルと前記領域の大きさとの少なくともいずれかに基づいて、指定された前記解像度レベルに対応する複数のレイヤの合成を行うか否かを判定する判定手段と、
前記判定手段において前記合成を行うと判定された場合に、指定された前記解像度レベルに対応する複数のレイヤを合成して、１レイヤで構成される画像データを生成する合成手段と、
生成された前記１レイヤで構成される画像データを前記外部装置へ送出する送出手段と、を備える。

本発明によれば、リソースに制約が課せられた携帯情報機器においても高画質の画像データを閲覧可能とする技術を提供することができる。

以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。

〔第１実施形態〕
本実施形態では、既に生成済みの複数のＪＰＥＧ２０００ファイルを保有しているサーバが、クライアントからの要求を受け付け、その要求を解析し、その解析結果に基づいて、階層化された、即ち、複数のlayer（レイヤ、階層）としてエンコードされたＪＰＥＧ２０００符号化データを、１レイヤで構成される画像データに合成し、クライアントに送信する構成について説明する。例えば、ユーザが、Ｗｉｎｄｏｗｓ（登録商標）等のＯＳがインストールされたクライアント装置を操作し、閲覧ソフトウェアを利用して、サーバが公開しているＪＰＥＧ２０００画像が埋め込まれたホームページを開く状況を想定する。この場合、クライアントは、ＪＰＥＧ２０００画像を取得するためのリンク情報に従って、ＪＰＥＧ２０００画像の要求をサーバに送信し、ＪＰＩＰの仕組みを使って、ＪＰＥＧ２０００の拡大表示や部分領域の表示などを行う。尚、本実施形態の構成においては、通信対象のデータとしてＪＰＥＧ２０００ファイルを想定するが、複数のレイヤから構成された画像データであればどのようなものに対しても本実施形態の構成を適用できる。

（情報処理装置のハードウェア構成）
図１は、本実施形態の構成における、サーバ及びクライアントのハードウェア構成を示したブロック図である。サーバ及びクライアントは、それぞれ、例えば、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）、或いは、携帯電話、ＰＨＳ、携帯情報端末（ＰＤＡ）等で実現される情報処理装置である。

図１において、CPU１０１は、システム全体の動作をコントロールし、一次記憶装置１０２に格納されたプログラムの実行などを行う。一次記憶装置１０２は、ＲＡＭ、ＲＯＭ等のメモリであり、二次記憶装置１０３に記憶されたプログラムなどを読み込んで格納する。

二次記憶装置１０３は例えば、ハードディスク等の大容量記憶装置である。一般に一次記憶装置１０２の容量は二次記憶装置１０３の容量より小さく、一次記憶装置１０２に格納しきれないプログラムやデータなどは二次記憶装置１０３に格納される。また、長時間記憶しなければならないデータなども二次記憶装置１０３に格納される。本実施形態では、プログラムを二次記憶装置１０３に格納し、プログラム実行時に一次記憶１０２に読み込んでCPU１０１が実行処理を行う。

尚、一次記憶装置１０２、二次記憶装置１０３は、それぞれ、例えば、所定のメディアと、当該メディアへのアクセスを実現するための外部記憶ドライブとによって構成してもよい。このようなメディアには、例えば、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等を採用することができる。

入力デバイス１０４はユーザからの指示入力を受け付ける装置であり、例えば、マウスやキーボード等がこれに該当する。指示入力に基づいてプログラムなどに割り込み信号を送ったりする。出力デバイス１０５は情報処理装置の応答を出力する表示装置であり、例えば、モニタ（ディスプレイ）やプリンタ等によって構成することができる。

Ｉ／Ｆ１０６は、インターフェイス（Interface）であり、情報処理装置は、このＩ／Ｆ１０６を介して外部装置とのデータのやり取りを行う。システムバス１０７は、情報処理装置内のデータの流れを司る役割を果たす。

尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。

また、本実施形態では、説明の便宜のため、本実施形態に対応する情報処理装置を１つの装置で実現した構成について述べるが、複数の装置にリソースを分散した構成によって実現してもよい。例えば、記憶や演算のリソースを複数の装置に分散した形に構成してもよい。或いは、情報処理装置上で仮想的に実現される構成要素毎にリソースを分散し、並列処理を行うようにしてもよい。

（システム構成）
図２は、本実施形態の構成におけるシステムの概略を示した模式図である。２０１はクライアント１、２０２はクライアント２をあらわしており、それぞれ図１で説明したハードウェア構成を有する。このシステムでは、クライアント１（２０１）、クライアント２（２０２）のようなクライアントが、有線、無線を問わず、ネットワーク２０３を経由して、サーバ２０４と通信することが可能である。サーバ２０４は解像度レベル毎に複数のレイヤから構成された画像ファイルを蓄積する大容量の記憶装置２０５を備えている。大容量の記憶装置２０５は、例えばハードディスク等によって実現される。このハードディスク２０５には、ＪＰＥＧ２０００符号化方式により符号化された、複数のレイヤから構成された画像データが格納されている。クライアント２０１、２０２は、サーバ２０４が格納しているＪＰＥＧ２０００画像データから、レイヤを順に受信し、閲覧、保存する。

（ＪＰＥＧ２０００符号化データの構成）
次に、一般的なＪＰＥＧ２０００の符号化データの概略について、図３を参照して説明する。図３は、ＪＰＥＧ２０００の符号化データの概略図である。

図３のように、ＪＰＥＧ２０００符号化データは、先頭のMain Header（メインヘッダ）データ３０１と１以上のタイル（Tile）データ３０２から構成される。

メインヘッダデータ３０１には、Resolution Level数、Layer数など画像全体の符号化条件についての情報が記述されている。

タイルデータ３０２は、それぞれ、タイルヘッダ（Tile Header）３０２と、符号化データ３０６から構成される。タイルヘッダ３０２は、タイルの符号化条件を記述したヘッダデータである。

タイルヘッダ３０２に後続する符号化データ３０６は、１以上のPacket（パケット）３０３という符号化単位データから構成される。

図３は、Layer-Resolution level-Component-Position progression（ＬＲＣＰ）に沿ってパケットデータが記録されたＪＰＥＧ２０００ファイルを例示している。図３のように、ＬＲＣＰに準じた場合、符号化データはLayer / Resolution / Component / Positionの順で構成される。このようなデータの並び方をProgression Orderと呼ぶ。また、ここで記されているPosition（ポジション、位置）とは、ＪＰＥＧ２０００符号化データにおけるPrecinct（プリシンクト）のことである。

図３のようにProgression OrderがＬＲＣＰの場合、各Layer（レイヤ）内は、Resolution（解像度）番号の小さい順にデータが格納されている。レイヤ番号は復元する画像の原画に対するS/N比に対応し、レイヤ番号が小さいほどS/N比が悪くなる。一つのＪＰＥＧ２０００ファイル内でのResolution番号とレイヤ番号、Component（コンポーネント）番号の最大値は、エンコーダによって予め設定され、そのパラメータにしたがってエンコードされており、その情報は符号化データの中に格納されている。

図４は、画像サイズとResolution（解像度）番号との関係を模式的に示した図である。本実施形態の構成においては、最も小さい解像度の画像の解像度番号を０とし、解像度番号が一つ増加するごとに画像の幅と高さが２倍になっていく。

このようなＪＰＥＧ２０００符号化データを使えば、クライアントはサーバにある全ての画像データを取得せず、必要な部分のデータのみをサーバから受信することが可能である。クライアントの受信データの単位としては、ＪＰＥＧ２０００のパケット、あるいはパケットよりも大きい符号化単位であるタイル単位が考えられる。

本実施形態では、クライアントがサーバから受信するデータ単位としてパケット単位を想定する。図５は、パケット単位のリクエスト（要求）およびレスポンス（応答）の概念図である。クライアント５０１はサーバ５０２に画像のタイル番号とResolution Level（解像度レベル）とレイヤ、コンポーネント、ポジション番号を指定して、データを要求する。サーバ５０２は、画像５０３のコードストリームを解析して、指定されたタイル番号、解像度レベルとレイヤ、コンポーネント、ポジション番号に相当するパケットデータを抜き出し、応答してクライアント５０１に送り返す。

（ＪＰＩＰレスポンスデータの構成）
次に、ＪＰＩＰを使ってパケットデータを送信単位として、データを送受信する場合のレスポンス（応答）データの構成を、図６および図７を使って説明する。

図６は、precinct data-binの構造の概略図である。ＪＰＩＰでは、図６の６０１に示すように、precinct data-binと呼ばれるＪＰＥＧ２０００のパケットデータの塊を基本としてレスポンスデータ（Response Data）を作成する。precinct data-binとは、タイル番号tnの中の、プリシンクト番号pnの解像度レベル rn、 コンポーネント番号cnを構成する全てのレイヤのパケットを、レイヤ番号が昇順になるように並べてつなげたデータの塊である。

図６に示すprecinct data-binから抜き出したPacket（tn, rn, cn, pn, １）を使って、作成されたＪＰＩＰ Response Dataの例を図７に示す。図７は、ＪＰＩＰ Response Dataの一例を示す図である。ここで、Packet（tn, rn, cn, pn, qn）とは、タイルtnの解像度レベルがrn, コンポーネント番号がcn, ポジション番号がpn, レイヤ番号がqnのパケットを示す。ＪＰＩＰ Response Dataは、message header ７０１と message body ７０３から構成される。message headerとmessage bodyを合わせて、ＪＰＩＰ messageと呼ぶ。precinct data-binから作成されたＪＰＩＰ messageをprecinct data-bin messageと呼び、メインヘッダから作成されたＪＰＩＰ messageをmain header data-bin messageと呼ぶ。

precinct data-bin messageのmessage body ７０３には、precinct data-bin ６０１から切り出されたＪＰＥＧ２０００符号化データが格納される。例えば、図６のPacket（tn, rn, cn, pn, １）６０３を抜き出してＪＰＩＰ Response Dataを作成する場合、Packet（tn, rn, cn, pn, １）６０３がmessage body ７０３に格納される。

message header ７０１は、４つのパラメータから構成される。即ち、１番目のパラメータは、message body ７０３に入っているデータが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 ６０２である。つまり、message body７０３に入っているデータが、PrID（tn, rn, cn, pn）のprecinct data-bin６０１において何Byte目からのデータであるのかを示す値であり、図６の６０２の値と等しい。

message header ７０１の４番目のパラメータは、Response Data（レスポンスデータ）のバイト長、即ち、message body ７０３のバイト長である。つまり、ResLen７０２には、ResLen[byte]７０４の値が格納される。

（サーバの動作概要）
次に、本実施形態におけるサーバの動作の概要について説明する。本実施形態では、サーバには、次のようなエンコード条件の画像sample.jp2が格納されているものとする。
最高解像度時の画像サイズ：２２７２×１７０４[pixel]
最高解像度時のタイルサイズ：５１２×５１２[pixel]
解像度レベル数：４
解像度レベル：３・・・画像 ２２７２×１７０４[pixel], タイル５１２×５１２[pixel]
解像度レベル：２・・・画像 １１３６×８５２[pixel], タイル２５６×２５６[pixel]
解像度レベル：１・・・画像 ５６８×４２６[pixel], タイル１２８×１２８[pixel]
解像度レベル：０・・・画像 ２８４×２１３[pixel], タイル６４×６４[pixel]
レイヤ数：各解像度レベルにつき３（レイヤ ０〜２）
コンポーネント数：３
ポジション数：１タイルにつき１ポジション
図８は、サーバに格納された画像データ（sample.jp2）の構造を模式的に示した図である。図９は、画像データ（sample.jp2）の、タイル分割の様子とタイル番号を示した図である。図９に示されているように、この画像は、５×４＝２０枚のタイル（０〜１９）に分割されている。

本実施形態において、サーバは、クライアントからリクエストを受信し、そのリクエストを解析して、例えば、以下のようにデータの生成、及び、送信の方針を決定する。
（処理１）クライアントからの要求画像の解像度が低い（画像サイズが小さい）と判断した場合には、サーバ側ではレイヤの合成を行わず、複数のレイヤで構成される画像データにつき、上位レイヤから順にクライアントへ送信する。この場合、たとえクライアントが複数のレイヤから構成された画像データを復元して画像を再生できないために、最上位レイヤの粗い画像しか表示することができなくても、表示画像自体が小さいため、ユーザに知覚される影響は小さいと考えられる。
（処理２）クライアントからの要求画像の解像度が高く（画像サイズが大きく）、画像中の広い領域を要求していると判断した場合には、サーバ側ではレイヤの合成を行わず、複数のレイヤで構成される画像データにつき、上位レイヤから順にクライアントへ送信する。この場合、クライアントは、解像度レベルが高く領域の広い画像データを要求しているため、クライアントの処理性能は高く、クライアントは複数のレイヤから構成された画像データを復元して画像を再生することができると考えられる。従って、サーバ側での合成を行う必要がないとみなせる。
（処理３）クライアントからの要求画像の解像度が高く（画像サイズが大きく）、画像中の狭い領域を要求していると判断した場合には、サーバ側で合成して該１レイヤで構成される画像データをクライアントに送信する。この場合、クライアントの表示画面は小さく、その処理性能は低いことが想定される。このため、クライアントは複数のレイヤから構成された画像データを復元して画像を再生することができないと考えられる。

尚、上記のデータの生成、送信の方針は一例であり、用途や目的に応じて適宜条件を設定することができる。例えば、上記の（処理１）の場合にのみレイヤの合成は行わず、その他の場合は１つのレイヤからなる画像データを合成する構成等を採用してもよい。

また、いずれの場合も、サーバはtarget IDを返送（応答、レスポンス）データと共に返送する。ここで、target ID（tid）とは、１レイヤに変換されたコードストリームと、複数のレイヤからなるオリジナルのコードストリームとを識別する情報である。本実施形態においては、「sample_unify」が１レイヤに変換されたコードストリームを表すtarget ID、「sample_original」がオリジナルのコードストリームを表すtarget IDである。このため、サーバがtarget IDをデータと共に送信することで、レイヤ数を１つにしたＪＰＥＧ２０００符号化データ、つまりオリジナルデータから作成しなおした（合成した）符号化データから抜き出したデータなのか、オリジナルのＪＰＥＧ２０００符号化データから抜き出したデータなのかを、クライアントに通知することができる。

（クライアントのリクエスト）
次に、本実施形態においてクライアントがサーバへ送出する、リクエストについて説明する。ここでは、クライアントは、既に、解像度レベル０で画像全体を表示しており、その返送データより、target IDがsample_originalであることが分かっているものとする。また、クライアント側には、メインヘッダと各タイルのタイルヘッダと、さらに各タイルの解像度レベル０、レイヤ０〜２のパケットがキャッシュデータとして存在するものとする。図１０は、このようなクライアントのキャッシュデータの構造を模式的に示した図である。尚、図１０において、１００１は取得された画像データのファイル名が"sample.jp2"、１００２は取得されたコードストリームがオリジナルのコードストリーム（sample_original）であることを意味する。

このクライアントが、画像の中央部を２倍に拡大し、３２０×２４０の表示画面に表示するために、次のようなリクエストをサーバに送った場合を想定して説明する。
http://www.image.com/JPIP.cgi?target=sample.jp2&tid=sample_original&fsiz=568,426&roff=93,124&rsiz=320,240&need=t*r1&type=jpp-stream
上記のリクエストにおいて、“target=sample.jp2”は、クライアントがsample.jp2という名前の画像を指定していることを意味する。

また、”tid=sample_original”は、sample.jp2に対応するコードストリームで、識別子が”sample_original”というコードストリームのデータを要求していることを意味する。”fsiz=568,426&roff=93,124&rsiz=320,240”は、画像の全体が５６８×４２６[pixel]のサイズのデータ、つまり解像度レベル１のデータから、画像の左上を原点とし、９３×１２４[pixel]の位置から、サイズが３２０×２４０[pixel]の画像を抜き出すように指定していることを意味する。ただし、ここでは”need=t*r１”と指定することにより、その画像データ全てではなく、既に、クライアント側にあるキャッシュ情報から、今回の要求に含まれている全てのタイルのうち、解像度レベル１のデータのみを要求している。

また、パラメータ”type”は、返送データ単位を指定するものであり、例示したリクエストの場合、”jpp-stream”が指定されており、これはpacketベースとしたデータを要求していることを意味する。

（サーバの処理の流れ）
このようなリクエストを受信したサーバの動作を、図１１を参照して説明する。図１１は、サーバの処理の流れを示したフローチャートである。

ステップＳ１１０１では、クライアントからのリクエストを受信し、解析する。上述の例の場合には、画像の全体が５６８×４２６[pixel]のサイズのデータ、つまり解像度レベル１のデータから、画像の左上を原点とし、９３×１２４[pixel]の位置から、３２０×２４０[pixel]の画像を抜き出すように指定している、と解釈できる。したがって、要求している範囲は、図９の領域９０１である。

ステップＳ１１０２では、受信したリクエストから、返送メディアタイプ（type）がＪＰＩＰ定義のjpp-streamであるか否かを判定する。jpp-streamの場合（ステップＳ１１０２でＹＥＳ）はステップＳ１１０６へ進み、それ以外の場合（ステップＳ１１０２でＮＯ）はステップＳ１１０３へ進む。ステップＳ１１０６以降では画像データを構成するレイヤを合成するか否かの判定を行って、判定結果に基づいた処理を実行することになる。

ステップＳ１１０３では、返送メディアタイプがＪＰＥＧ２０００であるか否かを判定する。ＪＰＥＧ２０００の場合（ステップＳ１１０３でＹＥＳ）はステップＳ１１０４へ進み、それ以外のメディアタイプの場合（ステップＳ１１０３でＮＯ）はステップＳ１１０５へ進む。

例えば、リクエストにおいてtype=jp2となっていれば、ＪＰＥＧ２０００ part１ファイルフォーマットでの返送をクライアントは望んでおり、type=rawと書いてあれば、ＪＰＥＧ２０００コードストリームでの返送をクライアントは望んでいるので（ステップＳ１１０３でＹＥＳ）、どちらの場合もステップＳ１１０４へ進む。例えば、リクエストにおいてtype=jpegとなっている場合は、ＪＰＥＧ２０００以外のデータが要求されているため（ステップＳ１０３でＮＯ）、ステップＳ１１０５へ進む。

ステップＳ１１０４では、返送すべきデータを、１レイヤのＪＰＥＧ２０００に変換して返送データを作成し、ステップＳ１１１２へ進む。ステップＳ１１０４の処理を行う場合、返送メディアタイプはjpp-streamではない（ステップＳ１１０２でＮＯ）ため、クライアントは断片的なデータによる返送を望んでいない。従って、このリクエスト以降に、画像データの取得に関してインタラクティブな操作は発生しないと予想される。そのため、レイヤに分割することをせず、１レイヤにまとめて送信する。上述の例のsample.jp2の場合には、本来は３レイヤのデータであるが、それを１レイヤのＪＰＥＧ２０００に変換することになる。変換処理自体は公知の適切な手法を適宜適用する。

ステップＳ１１０５では、例えばＪＰＥＧのような、指定されたメディアタイプにデータを変換して、返送データを作成し、ステップＳ１１１２へ進む。メディアタイプの変換処理は公知の適切な手法を適宜適用する。

クライアントからのリクエストが（クライアントのリクエスト）で例示したものである場合、リクエストの”type=jpp-stream”という記述から、jpp-streamでの返送をクライアントが望んでいるため（ステップＳ１１０２でＹＥＳ）、ステップＳ１１０２において、ステップＳ１１０６へ進むことになる。

ステップＳ１１０６では、ステップＳ１１０１の解析結果に基づいて、要求されている画像サイズを画像ファイルの解像度レベルにマッピングし、要求解像度レベルを特定する。上述の例の場合、画像全体のサイズが５６８×４２６[pixel]の画像を要求しているので、解像度レベル１にマッピングすることになる。

次に、ステップＳ１１０７では、ステップＳ１１０６で得られた要求解像度レベルの画像サイズと、ＱＶＧＡサイズとを比較し、要求解像度レベルの画像サイズがＱＶＧＡサイズと等しいか、それよりも小さい場合（ステップＳ１１０７でＹＥＳ）はステップＳ１１１０へ進み、ＱＶＧＡよりも大きい場合（ステップＳ１１０７でＮＯ）はステップＳ１１０８へ進む。ただし、ＱＶＧＡサイズとは、３２０×２４０[pixel]の大きさである。上述の例の場合、解像度レベル１の要求であるので、画像サイズは５６８×４２６[pixel]であり、ＱＶＧＡサイズ、３２０×２４０[pixel]より大きいので、ステップＳ１１０８へ進む。ステップＳ１１０７でＹＥＳと分岐した場合の処理は、上記の（処理１）に対応する。

ステップＳ１１０８では、要求されている領域の大きさがＱＶＧＡサイズと同じか、それよりも小さいサイズであるか否かを判定する。ＱＶＧＡサイズ以下の場合（ステップＳ１１０８でＹＥＳ）はステップＳ１１０９へ進み、ＱＶＧＡサイズより大きい場合（ステップＳ１１０８でＮＯ）はステップＳ１１１０へ進む。この判定は、ＱＶＧＡサイズの３２０×２４０[pixel]とリクエスト中にあるrsizフィールドの値を比較することで簡単に調べられる。尚、上述の例の場合、”rsiz=３２０,２４０”であるので、要求領域サイズとＱＶＧＡサイズが同じであるため、ステップＳ１１０９へ進むことになる。ステップＳ１１０８でＹＥＳと分岐した場合の処理は上記の（処理３）に対応し、ＮＯと分岐した場合の処理は上記の（処理２）に対応する。

尚、ステップＳ１１０７及びＳ１１０８におけるサイズの比較は、例えば以下のように行うことができる。比較対象の画像データ（又は領域）のうち一方の縦方向の長さが他方の縦方向の長さ以上であり、かつ、前者の横方向の長さが後者の横方向の長さ以上の場合に、前者のサイズが後者のサイズよりも大きいと判定する。ただし、縦方向の長さと横方向の長さの両方が等しい場合、両者のサイズは等しいと判定する。尚、サイズの比較方法はこれに限られず、用途や目的に応じて適宜適切なものを採用してよい。例えば、画像データ（又は領域）の面積の大小によってサイズを比較するように構成してもよい。

ステップＳ１１０９では、レイヤ合成フラグflagにレイヤの合成、即ち、画像データを１レイヤに変換して送出することを示す値”１”を代入し、さらに、返送するコードストリームのtarget IDを保存する変数RetIDに、１レイヤに変換されたコードストリームを示すtarget IDを代入し、ステップＳ１１１１へ進む。ただし、レイヤ合成フラグflagとは、オリジナルのＪＰＥＧ２０００符号化データを１レイヤに合成するかどうかを示すフラグであり、値”１”はオリジナルのＪＰＥＧ２０００符号化データを１レイヤに合成すること、値”０”はレイヤを合成しないことを意味する。フラグflagは、一時記憶装置１０２や二次記憶装置１０３等に領域を確保して保持する。なお、上述のように、本実施形態においては、sample_unifyが１レイヤに変換されたコードストリームを表すtarget IDである。従って、上述の例の場合には、返送するコードストリームのtarget IDとして、１レイヤに合成されたコードストリームを表すsample_unifyをRetIDに代入する。

ステップＳ１１０７で要求解像度レベルの画像サイズがＱＶＧＡ以下であると判断された場合（ステップＳ１１０７でＹＥＳ）、或いは、ステップＳ１１０８で解像度レベル０よりも大きい画像サイズをクライアントが要求しているが、その要求表示領域がＱＶＧＡサイズより大きいと判断された場合（ステップＳ１１０８でＮＯ）には、ステップＳ１１１０へ進む。

ステップＳ１１１０では、レイヤ合成フラグflagに、レイヤを合成しないことを示す値”０”を代入し、さらに、返送するコードストリームのtarget IDを保存する変数RetIDに、オリジナルのコードストリームを示すtarget IDを代入し、ステップＳ１１１１へ進む。上述のように、本実施形態においては、sample_originalがオリジナルのコードストリームを表すtarget IDである。

ステップＳ１１１１では、ステップＳ１１０１のリクエスト解析の結果に基づいて、該当するデータをオリジナルの画像コードストリームから抜き出し、図７に示すようなＪＰＩＰ messageを作成する。この処理の詳細については、図１２を参照して後に説明する。ステップＳ１１１２では、ステップＳ１１０４、ステップＳ１１０５または、ステップＳ１１１１で作成された返送データを、クライアントに送信して、この処理を終了する。

次に、図１２を参照して、ステップＳ１１１１において、データを抜き出し、レスポンスデータを作成する処理について、説明する。図１２は、レスポンスデータをＪＰＥＧ２０００データから抜き出し、生成する処理の流れを示したフローチャートである。

まず、ステップＳ１２０１では、リクエスト中にtarget IDの指定があったか否かを判定する。target IDの指定があった場合（ステップＳ１２０１でＹＥＳ）には、ステップＳ１２０２へ進み、target IDの指定が無かった場合（ステップＳ１２０１でＮＯ）には、ステップＳ１２０３へ進む。

ステップＳ１２０２では、リクエスト中で指定されたtarget IDがステップＳ１１０９またはステップＳ１１１０で決定された、返送用のRetIDと等しいか否かを判定する。返送用のRetIDと等しい場合（ステップＳ１２０２でＹＥＳ）はステップＳ１２０４へ進み、異なる場合（ステップＳ１２０２でＮＯ）はステップＳ１２０３へ進む。

ステップＳ１２０３では、ステップＳ１１０９またはステップＳ１１１０で決定されたRetIDの値を使って、”JPIP-tid”レスポンスヘッダを作成する。

上述の例の場合には、リクエストの中に、”tid=sample_original”が存在するので、ステップＳ１２０１からステップＳ１２０２へ処理を進める。さらに、ステップＳ１１０９で、sample_unifyがRetIDに代入されているので、ステップＳ１２０２からステップＳ１２０３へ処理を進める。ステップＳ１２０３では、”JPIP-tid: sample_unify”というＪＰＩＰレスポンスヘッダを作成し、ステップＳ１２０４へ処理を進める。

尚、ステップＳ１２０３の処理を行わない場合、即ち、ステップＳ１２０２でＹＥＳの場合は、クライアントの要求したtarget idと、サーバが返送するデータを抜き出した符号化データのtarget idが等しいことを意味するため、”JPIP-tid”レスポンスヘッダを返送する必要がない。

ステップＳ１２０４では、メインヘッダを返送する必要があるか否かを判定し、返送する必要がある場合（ステップＳ１２０４でＹＥＳ）はステップＳ１２０５へ進み、返送する必要が無い場合（ステップＳ１２０４でＮＯ）はステップＳ１２０９へ進む。メインヘッダを返送する必要があるか否かの判断は、例えば、通常のＪＰＩＰの処理において用いる処理と同様の手法を適用する。

上述の例の場合、リクエストで指定しているtarget IDは、sample_originalであり、返送コードストリームのtarget IDは、sample_unifyであり、両者は異なる。そのため、sample_unifyのデータを送信するサーバは、クライアントのリクエスト中にあるキャッシュ情報（need＝t*r１）を無視し、メインヘッダデータやタイルヘッダも返送する必要があると判断する。従って、メインヘッダを返送する必要があると判断し（ステップＳ１２０４でＹＥＳ）、ステップＳ１２０５へ進むことになる。

ステップＳ１２０５では、サーバに格納されたオリジナルのコードストリームからメインヘッダを抜き出す。そして、ステップＳ１２０６へ進む。

ステップＳ１２０６では、レイヤ合成flagの値が１であるか否かを判定する。flag=１の場合（ステップＳ１２０６でＹＥＳ）には、レイヤを一つにすべきと判断されているため、ステップＳ１２０７へ進む。flag≠１の場合（ステップＳ１２０６でＮＯ）には、レイヤの合成は必要ないので、ステップＳ１２０８へ進む。

上述の例では、ステップＳ１１０９でflagに１が代入されているので、ステップＳ１２０７へ進むことになる。
ステップＳ１２０７では、メインヘッダのレイヤ数の情報を１に書き換える。レイヤ数の情報は、メインヘッダに含まれるＣＯＤマーカに記述されている。

図１３はＣＯＤマーカの構成を示す概略図である。図１３に示すように、ＣＯＤマーカは５つの部分、ＣＯＤ, Ｌｃｏｄ, Ｓｃｏｄ, ＳＧｃｏｄ, ＳＰｃｏｄ、から構成される。その中のＳＧｃｏｄ１３０１は、更に３つのパート、１３０２、１３０３、１３０４から構成される。最初のパート１３０２には、コードストリームのProgression Orderが記述されている。２番目のパート１３０３には、レイヤ数が記述されている。３番目のパート１３０４には、色変換の情報が記述されている。したがって、ＳＧｃｏｄ１３０１の２番目のパート１３０３の値を１に書き換える。

上述の例の場合、１３０３には、３という値が格納されていたが、この値を１に書き換えることになる。

次に、ステップＳ１２０８では、ステップＳ１２０５乃至Ｓ１２０７の処理で得られたメインヘッダデータからmain header data-bin messageを作成する。main header data-bin messageは、図７で示したprecinct data-bin messageと同様に、メインヘッダを表す識別子や、返送データに含まれるメインヘッダの長さなどをmessage headerとし、message bodyにメインヘッダを格納したＪＰＩＰのレスポンス形式である。main header data-bin messageは、ＪＰＩＰで定義されているデータ形式であるので、詳しい構造の説明は省略する。

次にステップＳ１２０９では、タイルヘッダを返送する必要があるかを判定する。返送する必要がある場合（ステップＳ１２０９でＹＥＳ）はステップＳ１２１０へ進み、返送する必要が無い場合（ステップＳ１２０９でＮＯ）はステップＳ１２１２へ進む。タイルヘッダを返送する必要があるか否かの判断は、例えば、通常のＪＰＩＰの処理において用いる処理と同様の手法を適用する。

上述の例の場合には、リクエストで指定しているtarget ID “sample_original”と、返送コードストリームのtarget ID ”sample_unify”は異なる。そのため、sample_unifyのデータを送信するサーバは、クライアントのリクエスト中にあるキャッシュ情報（need=t*r１）を無視し、タイルヘッダも返送する必要があると判断する。したがって、この例では、返送する必要がある場合（ステップＳ１２０９でＹＥＳ）に該当し、ステップＳ１２１０へ進むことになる。

ステップＳ１２１０では、ステップＳ１１０１のリクエスト解析結果に基づいて、要求領域に含まれるタイルを特定し、それらのタイルヘッダをオリジナルのＪＰＥＧ２０００データから抜き出す処理を行う。そして、ステップＳ１２１１へ進む。

上述の例の場合、リクエスト解析結果より、図９の領域９０１が要求されているので、領域９０１に含まれる９タイル、タイル１、２、３、６、７、８、１１、１２、１３、のタイルヘッダを抜き出す。

ステップＳ１２１１では、ステップＳ１２１０で抜き出したタイルヘッダから、tile header data-bin messageを作成する。tile header data-bin messageも、図７で示したprecinct data-bin messageと同様に、tile headerを表す識別子や、そのtile headerを抜き出したタイルの番号、返送データに含まれるtile headerの長さなどをmessage headerとし、message bodyにtile headerを格納したＪＰＩＰのレスポンス形式である。tile header data-bin messageは、ＪＰＩＰで定義されているデータ形式であるので、詳しい構造の説明は省略する。

次に、ステップＳ１２１２では、ステップＳ１１０１のリクエスト解析結果に基づいて、返送用precinct data-binを特定する。上述の例の場合、９タイルに対して、解像度レベル０の３コンポーネントおよび、解像度レベル１の３コンポーネントを返送する必要があるので、９タイル×３コンポーネント×２解像度レベル×１ポジション／タイル＝５４より、５４個のprecinct data-binが返送データとして特定されることになる。

ステップＳ１２１３では、ステップＳ１２１２で特定された返送用precinct data-binを１つ取り出し、そのprecinct data-binに含まれる全てのレイヤのパケットを抜き出す。

上述の例の場合、sample.jp2は３つのレイヤから構成されているので、１つのprecinct data-binにつき３つのパケットを抜き出すことになる。つまり、タイル１、解像度レベル０、コンポーネント０、ポジション０によるprecinct data-binを構成する、レイヤ０, レイヤ１, レイヤ２の３つのパケットを抜き出す。

ステップＳ１２１４では、ステップＳ１２０６の処理と同様に、レイヤ合成フラグflagの値が１であるか否かを判定する。flag=１の場合（ステップＳ１２１４でＹＥＳ）には、レイヤを一つにすべきと判断されるため、ステップＳ１２１５へ進み、flag≠１の場合（ステップＳ１２１４でＮＯ）には、レイヤの合成は必要ないので、ステップＳ１２１６へ進む。

ステップＳ１２１５では、ステップＳ１２１３で抜き出したパケットを１レイヤに合成する。パケットデータは、図３に示すようにpacket header ３０４とpacket body ３０５から構成される。レイヤを１つに合成するには、各パケットからpacket body ３０５を抜き出し、レイヤ０からレイヤ番号が昇順になるように、抜き出したpacket body ３０５を順に並べる。そして、このpacket body ３０５を並べたデータに対するpacket header ３０４を作成する。上述の例の場合には、３つのレイヤ（レイヤ０、レイヤ１、レイヤ２）を１レイヤに合成することになる。そして、ステップＳ１２１６へ進む。

ステップＳ１２１６では、図７に示すようなprecinct data-bin messageを作成する。precinct data-binの作成は、通常のＪＰＩＰサーバと同様の処理によって行えるため、詳しい説明は省略する。

次に、ステップＳ１２１７では、返送すべきprecinct data-binを全て抜き出したか否かを判定する。全てを抜き出していない場合（ステップＳ１２１７でＮＯ）には、ステップＳ１２１３へ戻り、まだ抜き出していないprecinct data-binを抜き出し、ステップＳ１２１４乃至Ｓ１２１６の処理を繰り返す。全てを抜き出した場合（ステップＳ１２１７でＹＥＳ）には、ステップＳ１２１８へ進む。

上述の例の場合、５４個のprecinct data-binデータが抜き出されたら、ステップＳ１２１８へ進むことになる。

ステップＳ１２１８では、ＪＰＩＰレスポンスヘッダを作成する。ＪＰＩＰレスポンスヘッダの作成は、通常のＪＰＩＰサーバと同様の処理によって行えるため、詳しい説明は割愛する。

上述の例の場合、ステップＳ１２０３で既にJPIP-tidレスポンスヘッダを作成しているので、ステップＳ１２１８では、それ以外のＪＰＩＰレスポンスヘッダを作成することになる。

図１４は、上述の例の場合において、サーバとの通信後における、クライアントのキャッシュデータの構造を模式的に示した図である。図１４に示すように、サーバとの通信後において、クライアントには、タイル１、２、３、６、７、８、１１、１２、１３の９タイルに関して、１レイヤからなる解像度レベル０および１のデータをキャッシュすることになる。尚、図１４において、１４０１は取得した画像データのファイル名が"sample.jp2"、１４０２は取得したコードストリームが１レイヤに変換されたコードストリーム（sample_unify）であることを意味する。

上記のステップＳ１２１３乃至Ｓ１２１６の処理のように、本実施形態の構成では、リクエストを受け取るたびにオリジナルデータを１レイヤの画像データに変換して送出するため、クライアントの多様なリクエストに応じて画像データを再構成、送出するために、サーバが常時保持しなければならないデータは、オリジナル画像データのコードストリームのみでよい。

上記の構成では、"type=jpp-stream"、即ち、パケット単位での返送データが要求された場合に、インタラクティブ通信を想定したレスポンスデータの生成、送信を行ったが、インタラクティブ通信を想定した処理を行うのは、返送データの形式がパケット単位である場合に限られない。例えば、タイル単位で返送データを要求するjpt-streamの時も、同様に扱うことができる。

例えば、図１１のステップＳ１１０２での、返送メディアタイプの判定基準にjpt-streamを加える。さらに、図１２のステップＳ１２０９乃至ステップＳ１２１７の処理では、パケットの代わりに、該当するタイル, 解像度レベルのレイヤが含まれる全てのタイルパートを抜き出し、レイヤを１つにする処理を行う。このように構成することで、タイル単位で返送データを要求する場合も、インタラクティブ通信を想定した処理を行うことができる。尚、この場合、レイヤを１つにする処理量の観点から、タイルパートは、解像度レベル毎に分けて構成されることが望ましい。

また、サーバが１レイヤに変換する判断は、リクエスト内容にのみ基づいて行うので、上記の構成は、statelessシステム、statefulシステムのどちらのシステムにも適用することができる。

さらに、レスポンスデータを作成したコードストリームの識別子targetID（”tid”）を、サーバはレスポンスデータと共にクライアントに送るため、クライアントでは、変換されたコードストリームのデータと、そうではないデータを容易に区別することができる。したがって、例えば、クライアントが同じ画像に対して異なる条件で要求を発行した場合に、サーバがあるリクエストには、１レイヤに変換したコードストリームから、別のリクエストには複数レイヤを持つコードストリームからデータを返送したとしても、クライアントは、識別子targetIDを参照することで、別データとしてキャッシュすることができる。

尚、サーバ側はリクエスト中のtargetIDと返送コードストリームのtargetIDが異なるときには、リクエスト中のキャッシュ情報を無視するため、図１２のステップＳ１２０４、Ｓ１２０９で、メインヘッダやタイルヘッダを送信する必要があると判断し、差分データではなく、表示に必要な全てのデータを送信するので、クライアント側で表示に必要なデータが不足することは無い。

上記のように、本実施形態の構成においては、解像度レベル、画像領域を含む、クライアントからのリクエストの内容に基づいてクライアントの能力を予測し、画質方向のスケーラビリティに対応していない可能性があるデコーダを搭載しているクライアントに対しては、１レイヤの画像に変換したデータを返送する。このため、クライアントのデコーダの機能が１レイヤの画像のみしか扱えない場合でも、高精細な画像を見ることが出来る。

また、従来技術のように、解像度、画質、タイルの３つの要素によって分解された部分データをキャッシュし、次のインタラクティブな操作に利用しようとすれば、そのキャッシュデータを管理する仕組みも搭載しなければならない。しかし、本実施形態の構成にように、サーバがレイヤを１つにしたデータをクライアントに送信することで、クライアントでは、解像度とタイルの２要素によるキャッシュデータ管理が可能になるため、キャッシュデータの管理に伴うクライアントの負荷を軽減することができる。

また、複数のレイヤから１つのレイヤに変換する処理は、対象となるパケットのpacket bodyをつなぎ合わせ、packet headerのみを作成しなおすだけで良いので、画像のエンコードを行うよりも少ない処理量で実行することができる。

〔その他の実施形態〕
第１実施形態では、１レイヤにするか判断するための、画像サイズ、画像の領域サイズを共にＱＶＧＡサイズとしたが、このサイズに限られない。また、画像サイズの基準値、画像領域サイズの基準値を同一にする必要も無い。例えば、画像サイズをＱＶＧＡ、画像の領域サイズを１６０×１２０[pixel]とした構成にしてもよい。

また、第１実施形態では、リクエスト処理の度に、１レイヤに変換していたが、１レイヤに変換されたコードストリームをあらかじめサーバ側で保存しておいても良い。この場合、１つのＪＰＥＧ２０００ファイルにつき２つのコードストリームを用意し管理する必要があるが、サーバ側のリクエスト処理の負荷を軽減し、レスポンス速度を向上することができる。

また、全てのクライアントからのリクエストについて変換処理を実行せず、インタラクティブな通信を行うだけのマシンパワーがあると予測されるクライアントに対してのみ符号化データを変換するように構成することで、サーバ側の符号化データの変換に伴う負荷を軽減することができる。そして、インタラクティブな通信を行うだけのマシンパワーがあると予測されるクライアントに対しては、画質の選択の余地を与えることができる。

以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。

本実施形態の構成における、サーバ及びクライアントのハードウェア構成を示したブロック図である。 本実施形態の構成におけるシステムの概略を示した模式図である。 ＪＰＥＧ２０００の符号化データの概略図である。 画像サイズと解像度番号との関係を模式的に示した図である。 パケット単位のリクエストおよびレスポンスの概念図である。 precinct data-binの構造の概略図である。 ＪＰＩＰ Response Dataの一例を示す図である。 サーバに格納された画像データの構造を模式的に示した図である。 画像データの、タイル分割の様子とタイル番号を示した図である。 クライアントのキャッシュデータの構造を模式的に示した図である。 サーバの処理の流れを示したフローチャートである。 レスポンスデータをＪＰＥＧ２０００データから抜き出し、生成する処理の流れを示したフローチャートである。 ＣＯＤマーカの構成を示す概略図である。 サーバとの通信後における、クライアントのキャッシュデータの構造を模式的に示した図である。

Claims (12)

1. 複数のレイヤから構成された画像データを解像度レベル毎に記憶する記憶手段と、
   外部装置から、少なくとも前記画像データの前記解像度レベルと領域の大きさとの指定が含まれる送信要求を受信する受信手段と、
   指定された前記解像度レベルと前記領域の大きさとの少なくともいずれかに基づいて、指定された前記解像度レベルに対応する複数のレイヤの合成を行うか否かを判定する判定手段と、
   前記判定手段において前記合成を行うと判定された場合に、指定された前記解像度レベルに対応する複数のレイヤを合成して、１レイヤで構成される画像データを生成する合成手段と、
   生成された前記１レイヤで構成される画像データを前記外部装置へ送出する送出手段と、を備えることを特徴とする画像処理装置。
2. 前記記憶手段は解像度レベルについての第１基準値と、領域についての第２基準値とを更に記憶し、
   前記判定手段は、指定された前記解像度レベルと前記第１基準値との比較結果と、指定された前記領域の大きさと前記第２基準値との比較結果と、の少なくともいずれかに基づいて前記判定を行うことを特徴とする請求項１に記載の画像処理装置。
3. 前記判定手段は、指定された前記解像度レベルが前記第１基準値よりも大きく、かつ、指定された前記領域の大きさが前記第２基準値よりも小さい場合に、前記合成を行うと判定することを特徴とする請求項２に記載の画像処理装置。
4. 前記判定手段は、指定された前記解像度レベルが前記第１基準値よりも小さい場合に、前記合成を行わないと判定し、
   前記送出手段は、前記指定された解像度レベルに対応する、前記複数のレイヤで構成される画像データを前記外部装置へ送出することを特徴とする請求項２又は３に記載の画像処理装置。
5. 前記判定手段は、指定された前記解像度レベルが前記第１基準値よりも大きく、かつ、指定された前記領域の大きさが前記第２基準値よりも大きい場合に、前記合成を行わないと判定し、
   前記送出手段は、前記指定された解像度レベルに対応する、前記複数のレイヤで構成される画像データを前記外部装置へ送出することを特徴とする請求項２乃至４のいずれか１項に記載の画像処理装置。
6. 前記複数のレイヤから構成された画像データは、ＪＰＥＧ２０００方式に基づく符号化データであることを特徴とする請求項１乃至５のいずれか１項に記載の画像処理装置。
7. 前記第１基準値と前記第２基準値とは等しいことを特徴とする請求項２乃至６のいずれか１項に記載の画像処理装置。
8. 前記受信手段、及び、前記送出手段は、ＪＰＩＰに基づいて前記外部装置と通信を行うことを特徴とする請求項１乃至７のいずれか１項に記載の画像処理装置。
9. 前記送出手段は更に、生成された前記１レイヤで構成される画像データの識別子を前記外部装置へ送出することを特徴とする請求項１乃至８のいずれか１項に記載の画像処理装置。
10. 複数のレイヤから構成された画像データを解像度レベル毎に記憶する記憶手段を備えた画像処理装置の制御方法であって、
    外部装置から、少なくとも前記画像データの前記解像度レベルと領域の大きさとの指定が含まれる送信要求を受信する受信工程と、
    指定された前記解像度レベルと前記領域の大きさとの少なくともいずれかに基づいて、指定された前記解像度レベルに対応する複数のレイヤの合成を行うか否かを判定する判定工程と、
    前記判定工程において前記合成を行うと判定された場合に、指定された前記解像度レベルに対応する複数のレイヤを合成して、１レイヤで構成される画像データを生成する合成工程と、
    生成された前記１レイヤで構成される画像データを前記外部装置へ送出する送出工程と、を備えることを特徴とする画像処理装置の制御方法。
11. コンピュータを請求項１乃至９のいずれかに記載の画像処理装置として機能させるためのコンピュータプログラム。
12. 請求項１１に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。

Images