(57)【要約】【課題】  クライアント上で実行される多様なアプリケーションに合わせて適切な画像データを提供することを可能にする技術を提供する。【解決手段】  本発明によれば、複数のレイヤから構成された画像データの要求であって、少なくともレイヤ数の指定が含まれる要求を受け付ける受付手段と、指定された前記レイヤ数と、要求された前記画像データのレイヤの数とが一致するか否かを判定する判定手段と、前記判定手段において一致しないと判定された場合に、前記画像データを、指定された前記レイヤ数で構成される画像データに変換する変換手段と、を備えることを特徴とする情報処理装置が提供される。【選択図】  図９
2006345452.tif 000002
【特許請求の範囲】
【請求項１】
複数のレイヤから構成された画像データの要求であって、少なくともレイヤ数の指定が含まれる要求を受け付ける受付手段と、
指定された前記レイヤ数と、要求された前記画像データのレイヤの数とが一致するか否かを判定する判定手段と、
前記判定手段において一致しないと判定された場合に、前記画像データを、指定された前記レイヤ数で構成される画像データに変換する変換手段と、を備えることを特徴とする情報処理装置。
【請求項２】
前記変換手段は、
前記画像データを構成する複数の前記レイヤを、指定された前記レイヤ数のグループに分類し、該グループ毎に、当該グループを構成する前記レイヤの集合を１つのレイヤに合成する合成手段を備え、
指定された前記レイヤ数が、要求された前記複数のレイヤから構成された画像データのレイヤの数よりも小さい場合、前記合成手段を利用して前記変換を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記グループを構成する前記レイヤの個数は、各グループについて、等しい、又は、１異なることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記画像データを構成する前記レイヤは、１以上のビットプレーンから構成され、
前記装置内に前記レイヤを構成する前記ビットプレーンの境界の位置情報を保持し、
前記変換手段は、
指定された前記レイヤ数が、要求された前記複数のレイヤから構成された画像データのレイヤの数よりも大きい場合、前記位置情報に基づいて、前記レイヤを、前記ビットプレーンの境界で分割することにより、前記変換を行うことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記情報処理装置は、ネットワークを経由して外部装置に接続されたサーバ装置であって、
前記受付手段は前記外部装置から前記要求を受け付け、
変換された前記画像データを前記外部装置へ送出する送出手段を更に備えることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記画像データに基づいて処理を行うアプリケーション実行手段を更に備え、
前記受付手段は前記アプリケーション実行手段から前記要求を受け付け、
変換された前記画像データを前記アプリケーション実行手段へ受け渡す受渡手段を更に備えることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項７】
前記複数のレイヤから構成された画像データは、ＪＰＥＧ２０００方式に基づく符号化データであることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
複数のレイヤから構成された画像データの要求であって、少なくともレイヤ数の指定が含まれる要求を受け付ける受付工程と、
指定された前記レイヤ数と、要求された前記画像データのレイヤの数とが一致するか否かを判定する判定工程と、
前記判定工程において一致しないと判定された場合に、前記画像データを、指定された前記レイヤ数で構成される画像データに変換する変換工程と、を備えることを特徴とする情報処理装置の制御方法。
【請求項９】
コンピュータを請求項１乃至７のいずれかに記載の情報処理装置として機能させるためのコンピュータプログラム。
【請求項１０】
請求項９に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は階層化された画像データを送受信する技術に関する。
【背景技術】
【０００２】
近年、２００万〜５００万画素程度の画像を撮像可能な家庭用デジタルカメラが普及している。業務用のデジタルカメラは、１０００万画素クラスのものが普及している。デジタルカメラは、今後も高精細化されていくと想定される。
【０００３】
また、デジタルカメラ等で撮影した画像データを、ネットワーク経由で受け取り、該画像データをネットワーク上で公開する、オンラインのアルバムサービスが普及している。アルバムサービスは、受け取った画像データを公開するサーバと、ネットワーク経由でサーバにアクセスし、公開された画像データを閲覧するクライアントからなるシステムによって実現される。
【０００４】
このようなクライアント・サーバシステムにおけるクライアント機器として、近年、ＰＤＡ（Personal Digital Assistance）端末等の、携帯型の情報処理端末（携帯情報機器）も用いられるようになってきた。
【０００５】
一方、アルバムサービスの上位アプリケーションでは、サムネイル画像による一覧表示を行い、一覧表示した画像中から、拡大して表示したい画像の選択を受け付け、選択された画像をサムネイル画像よりも大きく表示するインタフェースが一般的に採用されている。
【０００６】
しかし、大きな画素数を持つ近年のデジタルカメラにより撮像された画像データを、拡大表示のたびに全てサーバからダウンロードするような構成においては、拡大画像を要求してからクライアント端末に画像が表示されるまでに、長い待ち時間を必要とする。
【０００７】
このような問題を解決するために、複数の解像度レベル毎に複数のレイヤ（階層）から構成され、さらに各解像度レベルのデータを複数のタイルに分割し符号化した画像データをサーバに保存し、表示に必要な部分データのみをダウンロードしてクライアント上に表示する技術が開発されている。このような技術として、ＪＰＥＧ２０００（Joint Photographic Experts Group 2000）やＪＰＩＰ（JPEG2000 image coding system - Part 9: Interactivity tools, APIs and protocols）等を利用した構成が知られている。
【０００８】
ＪＰＥＧ２０００とは、２００１年に標準化された画像符号化方式である。この方式によれば、画像データは、複数の解像度レベル毎に複数のレイヤから構成され、更にタイル分割されるように符号化される。ここで、レイヤとは、複数の画質で画像を閲覧可能なように、グループ分けされた符号化データのまとまりである。レイヤ構造においては、閲覧者に伝達する情報量への寄与が大きい符号順に上位レイヤから下位レイヤへと符号化データが配置されている。そして、ある下位レイヤの符号化データは、そのレイヤの上位のレイヤにおける符号化データに対する差分の情報が記述されている。このため、上位のレイヤの符号化データをデコードすれば、ある程度の情報量を伝達することが可能な画像を提供できる一方、下位のレイヤまでデコードすれば、より高画質の画像を提供することができる。
【０００９】
ＪＰＩＰとは、ＪＰＥＧ２０００の方式で符号化された画像ファイルへアクセスし、画像データをレイヤ、解像度レベル、タイル等の単位の所望の単位で取得して表示するための、クライアント・サーバ間のプロトコル、ＡＰＩ（Application Interface）、ツール等を規格化したものであり、現在、仕様策定中である。
【００１０】
ＪＰＥＧ２０００を利用した構成として、特許文献１には、ＪＰＥＧ２０００で符号化された画像データの部分データをサーバ・クライアントで送受信するシステムが開示されている。この構成において、クライアントは、サーバに格納されているコードストリームのどの部分が、既にクライアントのバッファに格納されているかを判別し、未だバッファに格納していない圧縮データの部分をサーバに要求する。一方、サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。クライアントは、受信したデータと既にバッファに格納されたデータを統合することで、画像を取得する。
【００１１】
また、特許文献２には、サーバ側に格納されているＪＰＥＧ２０００符号データを、クライアント側で高速にプログレッシブ表示するための技術が開示されている。この構成において、クライアントは、欲しい解像度レベルを指定するリクエストを発行し、サーバへ送出する。サーバは、クライアントから指定された解像度レベルのサブバンド符号データを、格納された画像ファイルから取り出してクライアントに送信する。クライアントは、表示している画像の解像度レベルの、復号化されたサブバンドの係数と、サーバから受信した符号データを復号して得られたサブバンドの係数とに基づいて画像データを復元することで、プログレッシブ表示を実現している。
【００１２】
また、特許文献３には、ＪＰＥＧ２０００画像データの一部のデータをクライアントにおいてキャッシュし、キャッシュデータからＪＰＥＧ２０００符号化データを作成する構成が開示されている。
【００１３】
上記のようなＪＰＥＧ２０００を利用した構成では、クライアントからの要求に応じて、ユーザの望む画像サイズ（解像度レベル）、レイヤ、部分領域（タイル）のデータを、サーバ側に格納されているＪＰＥＧ２０００符号化データから抜き出して、送受信する。
【００１４】
また、上記の構成において、サーバ・クライアント間でＪＰＥＧ２０００の画像データを効率的に送受信するために、クライアントは、受信したデータをキャッシュ（保存）しておく必要がある。これは、ＪＰＥＧ２０００符号化データにおいては、ある解像度レベルの画像データは、その解像度より１レベル低い解像度レベルの画像データに対する差分として表現されるためである。また、上述のように、ある下位レイヤの符号化データは、そのレイヤの上位のレイヤにおける符号化データに対する差分として構成されているためである。
【００１５】
このように、既に受信したデータをクライアント側でキャッシュしておくことで、拡大したり、画質を向上させたりする際に、クライアント・サーバ間で送受信するデータは、受信済みのデータとの差分データのみとなる。これにより、クライアント・サーバ間の通信データ量を削減することができる。
【特許文献１】特開２００３−２３６３０号公報
【特許文献２】特開２００４−４０６７４号公報
【特許文献３】特開２００３−１７９７６０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかし、上記従来の構成においては、サーバに格納された画像データを構成するレイヤ数に対応するようにクライアントを設計する必要がある。サーバに格納された画像データを構成するレイヤ数と、クライアントが想定するレイヤ数とが異なる場合、設計されたユーザビリティが満たされない場合がある。
【００１７】
例えば、サーバ側に５つの画質を持つようにエンコードされたＪＰＥＧ２０００画像が格納されている場合、このサーバに対して、３段階の画質選択肢をもつＵＩを備えたアプリケーションを実行するクライアントが要求を出す際には、５つの画質を３段階にマッピングする必要がある。逆に、サーバ側には２つの画質を持つようにエンコードされたＪＰＥＧ２０００画像が格納されている場合において、このサーバに対して、３段階の画質選択肢をもつＵＩを備えたアプリケーションを実行するクライアントが要求を出す場合、クライアントは、３つではなく、２つの画質しか選択することができない。
【００１８】
このように、上記従来の構成においては、クライアントのＵＩ設計者の意図を反映したサービスを提供することができない場合があった。
【００１９】
本発明は上記問題に鑑みなされたものであり、クライアント上で実行される多様なアプリケーションに合わせて適切な画像データを提供することを可能にする技術を提供する。
【課題を解決するための手段】
【００２０】
本発明によれば、
複数のレイヤから構成された画像データの要求であって、少なくともレイヤ数の指定が含まれる要求を受け付ける受付手段と、
指定された前記レイヤ数と、要求された前記画像データのレイヤの数とが一致するか否かを判定する判定手段と、
前記判定手段において一致しないと判定された場合に、前記画像データを、指定された前記レイヤ数で構成される画像データに変換する変換手段と、を備えることを特徴とする情報処理装置が提供される。
【発明の効果】
【００２１】
本発明によれば、クライアント上で実行される多様なアプリケーションに合わせて適切な画像データを提供することを可能にする技術を提供することができる。
【発明を実施するための最良の形態】
【００２２】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００２３】
〔第１実施形態〕
本実施形態のサーバ・クライアントシステムは、サーバ・クライアント間でセッションを維持することにより通信を行う。サーバは、既に生成済みの複数のＪＰＥＧ２０００ファイルを保有しており、クライアントから指定されたレイヤ（画質、階層）の数に基づいて、ＪＰＥＧ２０００データを変換し、セッションが終了するまで、変換されたＪＰＥＧ２０００データを保持し、そのクライアントからの要求に応じて、変換後のＪＰＥＧ２０００データからデータを抜き出して返送する。そして、サーバはそのセッションの維持が解除されるまで、送信したデータの情報(ファイル名、解像度、画質など)を保持する。
【００２４】
クライアントは、ＪＰＥＧ２０００画像を扱う上位アプリケーションのサービスが提供するレイヤ（画質）の選択肢数を取得し、サーバに通知する。その後、アプリケーションからの表示要求に基づいて、サーバにＪＰＥＧ２０００画像データを要求し、返送されたデータをキャッシュし、アプリケーションに表示用画像を渡す。尚、本実施形態の構成においては、通信対象のデータとしてＪＰＥＧ２０００ファイルを想定するが、階層化された、即ち、複数の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（コンポーネント）番号の最大値は、エンコーダによって予め設定され、そのパラメータにしたがってエンコードされており、その情報は符号化データの中に格納されている。
【００４２】
図４はレイヤとビットプレーンとの関係を示した図である。レイヤは、量子化されたＤＷＴ（Discrete Wavelet Transform、離散ウェーブレット変換）係数（ビットプレーン）をＭＳＢ（Most Significant Bit、最上位ビット）側からグループ化したものであり、レイヤ０は、ＭＳＢを含む複数のビットプレーンから構成され、レイヤの番号が上がるほどＬＳＢ（Least Significant Bit、最下位ビット）に近いビットプレーンを含むことになる。図４の場合、３つのレイヤに分けた例を示しており、レイヤ０で最も粗い画像が、レイヤ０とレイヤ１のデータで少し画質が良くなり、レイヤ０, レイヤ１およびＬＳＢを含むレイヤ２を全てデコードすると高画質な画像が得られる。ビットプレーンの分け方は決まっておらず、エンコード条件に左右される。
【００４３】
なお、packet body３０５は、図４に示すグループ化されたビットプレーン群をコードブロックと呼ばれる符号化単位で配列したものである。また、packet header３０４には、packet body３０５に含まれるデータに関して、コードブロック単位のデータ長やデータ位置を示す符号化データが格納されている。
【００４４】
このようなＪＰＥＧ２０００符号化データを用いることで、クライアントはサーバに格納された全ての画像データを取得せず、要求される画質に基づいて必要なデータのみをサーバから受信することが可能である。ユーザの受信データの単位としては、ＪＰＥＧ２０００のパケット、あるいは、パケットよりも大きい符号化単位であるタイル単位等を採用することができる。
【００４５】
本実施形態では、クライアントがサーバから受信するデータ単位としてパケット単位を想定する。図５は、パケット単位のリクエスト（要求）およびレスポンス（応答）の対応関係を示した図である。クライアント５０１はサーバ５０２に画像のタイル番号と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] （tileサイズ：２５６×２５６[pixel]）
解像度レベル１: ８００×６００[pixel] （tileサイズ：１２８×１２８[pixel]）
解像度レベル０: ４００×３００[pixel] （tileサイズ：６４×６４[pixel]）
＜ファイル名：example.jp2＞
最大画像サイズ：１６００×１２００[pixel]
タイルサイズ：２５６×２５６[pixel]
タイル数：３５＝（７×５）
レイヤ数：５
解像度レベル数：３
各解像度レベルの画像サイズ：
解像度レベル２: １６００×１２００pixel] （tileサイズ：２５６×２５６[pixel]）
解像度レベル１: ８００×６００[pixel] （tileサイズ：１２８×１２８[pixel]）
解像度レベル０: ４００×３００[pixel] （tileサイズ：６４×６４[pixel]）
上記２つのファイル、sample.jp2とexample.jp2のエンコード条件の相違点は、レイヤ数である。前者が２レイヤ、後者が５レイヤでエンコードされている。
【００５６】
（基本処理）
本実施形態では、サーバは、クライアント・サーバ間でセッションを維持した状態で、画像データの送受信に先立ち、クライアント側から提供する画像データの画質（レイヤ）数（以下、提供画質数と呼ぶ）の通知を取得し、その値に合わせて、サーバが保有している画像データのレイヤ数を変更する。その後、ＪＰＩＰを利用して画像データを送受信する。
【００５７】
このようなサーバの動作について、図８を参照して説明する。図８は、サーバ装置の処理の流れを示したフローチャートである。尚、本実施形態のクライアントは３つの画質選択肢を持つアプリケーションを搭載しているものとするが、本構成の適用範囲はこれに限られない。
【００５８】
まず、ステップＳ８０１では、クライアントとの間でセッションを開始する。セッションの開始は、ＴＣＰ／ＩＰ等の公知の手法を適用することができる。
【００５９】
次に、ステップＳ８０２では、クライアントに提供画質数Ｍを問い合わせ、その数を取得する。本実施形態の場合、クライアントは３つの画質選択肢を持つアプリケーションであるので、Ｍ＝３となる。
【００６０】
次に、ステップＳ８０３では、クライアントからのリクエストを受信する。リクエストには、サーバのＵＲＬ、画像ファイル名、解像度レベル、画質（レイヤをどこまで取得するか）等の情報が含まれる。尚、ステップＳ８０２で取得する提供画質数Ｍは、例えば、このリクエストに含めるようにしてもよい。
【００６１】
次に、ステップＳ８０４では、ステップＳ８０３で受信したリクエストを解析する。即ち、リクエストに含まれる、サーバのＵＲＬ、画像ファイル名、解像度レベル、画質等の情報の値を取得する。
【００６２】
次に、ステップＳ８０５では、ステップＳ８０４で取得した、画像ファイル名を取得し、その画像ファイルへの要求がこのセッションにおいて初めてのアクセスであるか否かを判断する。初めてのアクセスの場合（ステップＳ８０５でＹＥＳ）は、ステップＳ８０６へ進み、初めてではない、即ち、既に要求された画像ファイルがこのセッション内でアクセスがあったファイルの場合（ステップＳ８０５でＮＯ）はステップＳ８０７へ進む。なお、ここでは、画像ファイル名、もしくは、画像データに付けられた識別子が一致するリクエストを受信したか否かで、リクエストが初めてか否かを判定する。
【００６３】
本実施形態で、クライアントから送られたリクエストが
http://www.image.com/JPIP.cgi?target＝sample.jp2&・・・
とあれば、sample.jp2へのアクセスであり、
http://www.image.com/JPIP.cgi?target＝example.jp2&・・・
とあれば、example.jp2へのアクセスである。以下、いずれかの画像データに対して初めてのリクエストがなされた場合、即ち、ステップＳ８０６へ進む場合について例示的に説明する。
【００６４】
ステップＳ８０６では、返送コードストリームを設定、即ち、既にサーバに格納された画像データを、クライアントへ送出するための画像データ（返送コードストリーム）に変換する。この設定処理については、図９を参照して、後に説明する。そして、ステップＳ８０７へ進む。
【００６５】
ステップＳ８０７では、ステップＳ８０４で解析した結果に基づいて、ステップＳ８０６で設定された返送コードストリームから返送すべきデータを抜き出し、返送データを作成し、送信する。ステップＳ８０７においては、例えば、通常のＪＰＩＰにおける処理と同様の処理を適用することができる。
【００６６】
ステップＳ８０８では、セッションを閉じるかどうかを判断する。クライアントからのセッションクローズの要求があったり、セッション開始から所定の時間が経過してタイムアウトが発生した等により、セッションを閉じると判断した場合（ステップＳ８０８でＹＥＳ）ステップＳ８０９へ進み、まだ、セッションを維持すると判断した場合（ステップＳ８０８でＮＯ）、ステップＳ８０３へ戻って、クライアントからのリクエストを受信可能に動作する。
【００６７】
ステップＳ８０９では、クライアントとのセッションを閉じる処理を行う。次に、ステップＳ８１０では、返送コードストリームとオリジナルファイルの符号化データが同じであったか否かを判断する。同じである場合（ステップＳ８１０でＹＥＳ）はこのフロー（処理）を終了し、異なる場合（ステップＳ８１０でＮＯ）には、ステップＳ８１１へ進む。ステップＳ８１１では、オリジナルファイルとは別に返送コードストリームが作成されているため、この返送コードストリームを削除する。そして、処理を終了する。
【００６８】
（返送コードストリーム設定処理）
次に、ステップＳ８０５の返送コードストリーム設定処理について、図９を参照して説明する。図９は、返送コードストリーム設定処理の流れを示したフローチャートである。
【００６９】
まず、ステップＳ９０１では、要求されたファイル、即ち、サーバに格納されたオリジナルファイルのレイヤ数Ｑを取得する。この値は、オリジナルファイルの、main headerのＣＯＤマーカを解析して取得する。
【００７０】
図１１はＣＯＤマーカの構成を模式的に示した図である。図１１に示すように、ＣＯＤマーカは５つの部分、ＣＯＤ, Ｌｃｏｄ, Ｓｃｏｄ, ＳＧｃｏｄ, ＳＰｃｏｄ、から構成される。その中のＳＧｃｏｄ１１０１は、更に３つのパート、１１０２、１１０３、１１０４から構成される。最初のパート１１０２には、コードストリームのprogression orderが記述されている。２番目のパート１１０３には、レイヤ数が記述されている。３番目のパート１１０４には、色変換の情報が記述されている。したがって、本実施形態の場合、sample.jp2のＳＧｃｏｄ１１０１の２番目のパート１１０３にはレイヤ数２が記述されており、example.jp2の１１０３にはレイヤ数５が記述されている。
【００７１】
次に、ステップＳ９０２では、ステップＳ８０２で取得したクライアントの提供画質数ＭとステップＳ９０１で取得したレイヤ数Ｑの値とが等しい否か判断する。等しい場合（ステップＳ９０２でＹＥＳ）、オリジナルのコードストリームを変換する必要が無いので、ステップＳ９０６へ進み、異なる場合（ステップＳ９０２でＮＯ）、オリジナルのコードストリームを提供画質数Ｍに合わせて変換する必要があるので、ステップＳ９０３へ進む。
【００７２】
ステップＳ９０６では、オリジナルのコードストリームを変換する必要が無いため、返送用コードストリーム名にオリジナルファイル名を設定し、このフロー（処理）を終了する。
【００７３】
上記の例では、sample.jp2（Ｑ＝２）への要求であっても、example.jp2（Ｑ＝５）への要求であっても、提供画質数Ｍ＝３とは異なる値であるので、ステップＳ９０３へ進むことになる。
【００７４】
ステップＳ９０３では、提供画質数Ｍとレイヤ数Ｑの値を比較し、レイヤ数Ｑが小さい場合（ステップＳ９０３でＮＯ）はステップＳ９０７へ進み、レイヤ数Ｑが大きい場合（ステップＳ９０３でＹＥＳ）はステップＳ９０４へ進む。上記の例の場合、sample.jp2への要求であれば、Ｑ＝２＜Ｍ＝３であるので、ステップＳ９０７へ進み、example.jp2への要求であれば、Ｑ＝５＞Ｍ＝３であるので、ステップＳ９０４へ進むことになる。
【００７５】
ステップＳ９０４では、画質提供数Ｍよりもレイヤ数Ｑが多い場合であるため、レイヤ数をＭに減らしたファイルtmp_decを作成するレイヤ合成処理を行う。ファイルtmp_decには、例えば、オリジナルのファイル名と、変更したレイヤ数を反映したファイル名（e.g. example_3.jp2）をつける。例えば、変換後のレイヤ数をオリジナルファイル名の後ろにつけた名前を用いることで、あるクライアントのセッション中に、同じ画質提供数Mを持つ他のクライアントが同じ画像ファイルにリクエストを発行した場合に、このデータを再利用することができる。このtmp_dec作成、即ち、レイヤ合成処理については、図１０を参照して後に説明する。
【００７６】
次に、ステップＳ９０５では、返送用コードストリーム名にステップＳ９０４で作成したtmp_decを設定してこのフロー（処理）を終了する。
【００７７】
ステップＳ９０７では、提供画質数Ｍよりもレイヤ数Ｑが少ない場合であるため、再エンコードするために、オリジナルの画像データを一度デコードする。
【００７８】
次に、ステップＳ９０８では、ステップＳ９０７でデコードされた画像データを、レイヤ数がＭとなるようにエンコードしなおしたファイルtmp_incを作成する。ファイル名tmp_incは、tmp_decと同様に、オリジナルのファイル名に変更後のレイヤ数を用いて名前（e.g. sample_3.jp2）をつける。ファイルtmp_incの作成処理は、例えば、公知の手法を適用することができる。
【００７９】
次に、ステップＳ９０９では、返送用コードストリーム名にステップＳ９０８で作成したtmp_incを設定し、このフローを終了する。
【００８０】
以上のように、返送コードストリーム設定処理を実行後、返送用コードストリームは、提供画質数Ｍとレイヤ数Ｑが一致したコードストリームになる。
【００８１】
（レイヤ合成処理）
次に、ステップＳ９０４のレイヤ数をＭに減らすファイル変換処理について、図１０を参照して説明する。図１０は、ファイル変換処理の流れを示したフローチャートである。上記の例では、クライアントがexample.jp2を要求した場合に、このフローを実行することになる。
【００８２】
まず、ステップＳ１００１では、オリジナルのコードストリームからmain headerを抜き出し、レイヤ数をＭに書き換え、tmp_decファイルに保存する。具体的には、図１１に示す、ＣＯＤマーカ中１１０３に格納された数字をＭに書き換える。これは、このフローによって、作成されるtmp_decのレイヤ数が、提供画質数Ｍと一致するように作成されるためである。上記の例では、ＣＯＤマーカ１１０３には、値５が格納されているので、この処理によって値３に書き換えることになる。
【００８３】
次に、ステップＳ１００２では、オリジナルコードストリームのレイヤ数Ｑを、提供画質数Ｍで割ったときの商ｂと余りｘを求める。上記の例の場合、Ｑ＝５, Ｍ＝３であるので、ｂ＝１, ｘ＝２となる。
【００８４】
次に、ステップＳ１００３では、オリジナルコードストリームのタイル数ＴＮを取得する。これは、main headerを解析することで、容易に計算できる。上記の例の場合、ＴＮ＝３５である。
【００８５】
次に、ステップＳ１００４では、一時記憶１０２等の所定の記憶装置に、タイル用の変数ｔのための領域を確保し、値０を代入して初期化する。
【００８６】
次に、ステップＳ１００５では、一時記憶１０２等の所定の記憶装置に、オリジナルコードストリームのレイヤ番号をカウントする変数ｑのための領域を確保し、値０を代入して初期化する。
【００８７】
次に、ステップＳ１００６では、一時記憶１０２等の所定の記憶装置に、tmp_decのレイヤ番号をカウントする変数ｎｑのための領域を確保し、値０を代入して初期化する。
【００８８】
次に、ステップＳ１００７では、タイルｔのレイヤｑ〜レイヤ（ｑ＋ｂ−１）のレイヤ（レイヤｑ、レイヤｑ＋１、レイヤｑ＋２、・・・、レイヤ（ｑ＋ｂ−１））をオリジナルコードストリームから抜き出し、１レイヤに変換する処理を行う。そして、変換されたレイヤをtmp_decのレイヤｎｑとする。尚、複数のレイヤを１つにする処理は、例えば、それぞれのpacket body３０５を抜き出し、ビットプレーンを並べ直し、パケットヘッダを作成しなおす手法を採用することができる。このような手法を採用することで、逆ＤＷＴ（離散ウェーブレット変換）を実行するする必要がないので、レイヤを統合する変換処理が軽減される。
【００８９】
次に、ステップＳ１００８では、変数ｑにｂを加え、さらに変数ｎｑに１を加える。
【００９０】
次に、ステップＳ１００９では、ｎｑと（Ｍ−ｘ）とを比較し、同じ値の場合（ステップＳ１００９でＹＥＳ）はステップＳ１０１０へ進み、異なる値、つまり、ｎｑが（Ｍ−ｘ）に達していない場合（ステップＳ１００９でＮＯ）は、ステップＳ１００７へ戻り、ステップＳ１００７、Ｓ１００８の処理を繰り返す。
【００９１】
上記のように、ステップＳ１００７〜Ｓ１００９の処理では、オリジナルコードストリームを構成するレイヤがｂ個存在するグループを、（Ｍ−ｘ）個作成し、各グループ毎に、グループを構成するレイヤの集合を１つのレイヤに合成する処理を行っている。従って、ステップＳ１００７〜Ｓ１００９において、処理が適用される、オリジナルコードストリームのレイヤの数はｂ×（Ｍ−ｘ）である。
【００９２】
上記の例の場合、ｂ＝１であるので、ｑ＝（ｑ＋ｂ−１）＝ｑとなるので、ステップＳ１００７で対象となるのは、１レイヤずつである。さらに、Ｍ＝３, ｘ＝２であるので、ステップＳ１００８を一度通過すると、ｎｑ＝１＝（Ｍ−ｘ）＝（３−２）となり、ステップＳ１０１０へ処理を進めることになる。つまり、オリジナルコードストリームのレイヤ０がtmp_decにおいてもレイヤ０に対応することになる。
【００９３】
次に、ステップＳ１０１０では、変数ｎｑとＭを比較し、値が等しい場合（ステップＳ１０１０でＹＥＳ）はステップＳ１０１３へ進み、異なる値である場合（ステップＳ１０１０でＮＯ）はステップＳ１０１１へ進む。もし、ステップＳ１００２でオリジナルコードストリームのレイヤ数Ｑを、提供画質数Ｍで割り切る場合は、ステップＳ１０１１、ステップＳ１０１２の処理をせずに、ステップＳ１０１３へ進むことになる。
【００９４】
上記の例では、レイヤ数Ｑ（＝５）を提供画質数Ｍ（＝３）で割った余りｘ＝２≠０であるので、ステップＳ１０１１へ進むことになる。
【００９５】
ステップＳ１０１１では、タイルｔのレイヤｑ〜レイヤ（ｑ＋ｂ）のレイヤ（レイヤｑ、レイヤｑ＋１、レイヤｑ＋２、・・・、レイヤ（ｑ＋ｂ））を１レイヤに変換し、tmp_decのレイヤｎｑとする。レイヤの変換処理は、ステップＳ１００７における処理と同様の手法を採用することができる。
【００９６】
次に、ステップＳ１０１２では、変数ｑに（ｂ＋１）を加え、さらに、変数ｎｑに１を加え、ステップＳ１０１０へ進む。
【００９７】
上記のように、ステップＳ１０１０〜Ｓ１０１２の処理では、オリジナルコードストリームを構成するレイヤが（ｂ＋１）個存在するグループを、ｘ個作成し、各グループ毎に、グループを構成するレイヤの集合を１つのレイヤに合成する処理を行っている。従って、ステップＳ１０１０〜Ｓ１０１２において、処理が適用される、オリジナルコードストリームのレイヤの数は（ｂ＋１）×ｘである。
【００９８】
また、ステップＳ１００７〜Ｓ１００９、ステップＳ１０１０〜Ｓ１０１２の処理により、合成処理が適用されるオリジナルコードストリームのレイヤの総数はｂ×（Ｍ−ｘ）＋（ｂ＋１）×ｘ＝ｂＭ＋ｘ＝Ｑであり、合成処理は、オリジナルコードストリームの全てのレイヤに対し適用されることが理解される。尚、上記のように構成したことで、グループを構成するレイヤの個数は、各グループについて、等しい、又は、１異なる。
【００９９】
上記の例では、ステップＳ１０１１に初めて処理が移ったとき、ｑ＝１, ｎｑ＝１であり、また、ステップＳ１００２でｂ＝１となるので、レイヤ１, レイヤ２から１レイヤに変換されたレイヤがtmp_decのレイヤ１になり、レイヤ３, レイヤ４から１レイヤに変換されたレイヤがtmp_decのレイヤ２となる。そして、ステップＳ１０１３へ進むことになる。
【０１００】
ステップＳ１０１３では、タイルｔのタイルヘッダを書き換える。つまり、ステップＳ１００７やステップＳ１０１１で複数レイヤを１レイヤに変換した場合、変換前後における、それぞれのパケット長が異なるため、タイルのデータ長が変化する。この変化したタイルのデータ長に基づいてタイルヘッダの値を更新する処理を行う。
【０１０１】
次に、ステップＳ１０１４では、タイルｔから作成した、レイヤ数を減らしたデータをtmp_decに保存する。具体的には、ステップＳ１００７、ステップＳ１０１１で作成したレイヤ０〜レイヤＭ、及び、ステップＳ１０１３で書き換えたタイルヘッダをtmp_decに保存する。
【０１０２】
次に、ステップＳ１０１５では、タイル用の変数ｔを１つ増やし、ステップＳ１０１６へ進む。
【０１０３】
ステップＳ１０１６では、変数ｔとタイル数ＴＮを比較する。変数ｔとタイル数ＴＮが同じ値である場合（ステップＳ１０１６でＹＥＳ）、tile０〜tile（ＴＮ−１）の全てのタイルについて変換処理を終えたと判断し、この処理を終了する。逆に、変数ｔとタイル数ＴＮが異なる場合（ステップＳ１０１６でＮＯ）には、まだ、変換処理をすべきタイルが残っているものと判断して、ステップＳ１００５へ戻り処理を継続する。
【０１０４】
上記のように、本実施形態のサーバは、クライアントから通知された提供画質数に合わせて画像データのレイヤ数を変換するため、クライアントは、サーバのレイヤ数から画質選択肢へのマッピング等の作業をすることなく、通知した画質選択肢と同じ数のレイヤをもつＪＰＥＧ２０００画像を入手できる。また、クライアント上のＵＩとしてデザインされた画質選択肢の中で、サーバがサービスを提供できない画質が存在することもない。
【０１０５】
また、レイヤ合成処理においては、画像を完全にデコードすることなく、ＤＷＴ係数を取得するところまでデコードし、レイヤを作成しなおせばよいため、レイヤ数変換に伴う負荷は小さい。
【０１０６】
さらに、サーバ側では、クライアントとのセッションを開始してから、セッションをクローズするまで変換したコードストリームを保存しておくため、同一セッション内での２回目以降の画像データ通信においては、返送時間を短縮することができる。
【０１０７】
尚、変換コードストリームは、セッション毎に作成され、セッション毎に消去される。したがって、サーバ側で、１つのコードストリームに対して膨大な種類のコードストリームを保存しておくことがないため、サーバ側の記憶容量を圧迫することもない。
【０１０８】
もちろん、用途や目的に応じて変換コードストリームを長期間保持するための記憶装置を構成し、このデータを保存しておいても良い。その場合、同じ提供画質レベル数を持つ他のクライアントに対して、作成済みのコードストリームから返送データを作成することができるので、レスポンス時間を短縮することができる。
【０１０９】
本実施形態では、サーバ・クライアント間で通信の間、セッションを維持する必要があるが、これは、例えば、ＴＣＰ／ＩＰ等の公知の手法を適用することができる。例えば、ＨＴＴＰヘッダにＳＳＬ情報を追加する手法や、ステートレスなシステムを用いたＣｏｏｋｉｅベースによるセッション維持の手法、或いは、送信元ＩＰアドレス情報を利用する手法等を適用することができる。ただし、ステートレスなシステムを利用する場合には、図８のステップＳ８０８におけるセッションクローズの検出は、アクセスのない時間が所定時間経過する、タイムアウトイベントの発生によって行うことになる。
【０１１０】
〔第２実施形態〕
第１実施形態では、画質提供数Ｍがレイヤ数Ｑより大きい場合、一度、オリジナルのＪＰＥＧ２０００データをデコードし、レイヤ数Ｑになるように再エンコードを行った。しかし、図４を参照して説明したように、画像データを構成するレイヤは、１以上のビットプレーンから構成されるため、各パケットについて、１つのレイヤを構成するビットプレーンの境界の位置情報を取得し、その情報に基づいて、レイヤをビットプレーンの境界で分割することにより、画質提供数Ｍにレイヤ数を分割するように構成してもよい。本実施形態では、例えば、画質選択肢数（画質提供数）Ｍが３であるクライアントが、レイヤ数Ｑ＝２のsample.jp2を要求した場合を想定して、説明する。
【０１１１】
本実施形態においては、返送コードストリームを設定する処理が第１実施形態と異なる。基本処理は第１実施形態と同様に、図８のフローチャートに基づいて実行される。
【０１１２】
本実施形態の返送コードストリーム設定処理を、図１２を参照して説明する。図１２は、返送コードストリーム設定処理の流れを示したフローチャートである。ただし、ここでは、第１実施形態の図９との相違点を中心に説明し、第１実施形態と同様の処理については、同じ番号を付して説明を省略する。
【０１１３】
図１２において、ステップＳ９０１からステップＳ９０６は、第１実施形態と同様の処理であるので、説明を省略する。
【０１１４】
ステップＳ９０３で提供画質数Ｍよりレイヤ数Ｑが小さいと判断された場合（ステップＳ９０３でＮＯ）は、ステップＳ１２０１へ進む。
【０１１５】
ステップＳ１２０１では、各パケットについて、１つのレイヤを複数のレイヤに分割することが可能な、画像データの区切れ（ビットプレーンの境界）の位置の情報を取得する。この情報は、別ファイルとして保持するように構成してもよいが、同じファイル（画像データファイル）の中に保存しておいてもよい。本実施形態では、ベンダー定義の情報として、UUID boxの中に独自の形式で、位置情報を保存しているものとする。
【０１１６】
ステップＳ１２０２では、ステップＳ１２０１で取得した情報を参照して、サーバに格納された画像データのレイヤを分割し、返送用コードストリームtmp_incに変換する。この処理については、図１３を参照して後述する。ステップＳ１２０２でtmp_incを作成後、ステップＳ９０９へ進み、返送用コードストリーム名にtmp_incを設定して、この処理を終了する。
【０１１７】
（レイヤ分割処理）
次に、図１３を参照して、レイヤを分割するレイヤ分割処理について説明する。図１３は、レイヤ分割処理の流れを示したフローチャートである。ただし、第１実施形態の図１０に示したレイヤ合成処理と同様の処理をするステップについては、図１０と同じ番号を付し、詳しい説明を省略する。
【０１１８】
まず、ステップＳ１００１では、第１実施形態と同様、オリジナルのコードストリームからmain headerを抜き出し、レイヤ数をＱからＭに書き換え、保存する。
【０１１９】
次に、ステップＳ１３０１では、第１実施形態と同様、レイヤ数Ｑで画質選択肢数Ｍを割った時の、商ｂと余りｘを求める。上記の例の場合、Ｑ＝２, Ｍ＝３であるので、ｂ＝１, ｘ＝１となる。そして、ステップＳ１００３へ進む。
【０１２０】
ステップＳ１００３からステップＳ１００６は、第１実施形態の図１０と同様の処理なので、説明を省略する。上記の例の場合、ステップＳ１００３で取得されるタイル数ＴＮは３５である。ステップＳ１００６の処理を終了すると、ステップＳ１３０２へ進む。
【０１２１】
ステップＳ１３０２では、ステップＳ１３０１で求めた余りｘが０より大きいか否かを判定する。余りｘが０よりも大きい場合（ステップＳ１３０２でＹＥＳ）はステップＳ１３０３へ進み、余りｘよりも大きくない、即ち、０と等しい場合（ステップＳ１３０２でＮＯ）はステップＳ１３０５へ進む。つまり、画質選択肢数Ｍがレイヤ数Ｑで割り切れたかどうかを調べ、割り切れる場合（ステップＳ１３０２でＮＯ）はステップＳ１３０５へ処理を進め、割り切れない場合（ステップＳ１３０２でＹＥＳ）は、余りｘの回数だけステップＳ１３０３、ステップＳ１３０４の処理を繰り返す。
【０１２２】
上記の例の場合、ステップＳ１００６からステップＳ１３０２の処理に入った時点では、ｘ＝１であるので、ステップＳ１３０３へ進むことになる。
【０１２３】
ステップＳ１３０３では、ステップＳ１２０１で取得した、各パケットのレイヤに分割できるビットプレーンの境界の位置情報に基づいて、レイヤをビットプレーンの境界で分割することにより、タイルｔのレイヤｑを（ｂ＋１）のレイヤに分割し、それぞれをtmp_incのタイルｔのレイヤｎｑ〜レイヤ（ｎｑ＋ｂ）とするする。つまり、パケットｑのパケットヘッダを解析し、ステップＳ１２０１で取得した、レイヤ分割できるポイントが、パケットｑのどの位置に当たるのかを特定する。その特定された箇所で、packet bodyを分割し、それぞれのpacket bodyに対応するpacket headerを新たに作成し、packet bodyとあわせることで、パケットを分割する。
【０１２４】
次に、ステップＳ１３０４では、オリジナルコードストリームのレイヤ番号のカウンタｑを１つ増やし、temp_incのレイヤ番号の変数ｎｑに（ｂ＋１）を加え、さらに、余りｘを１減らし、ステップＳ１３０２に処理を戻す。
【０１２５】
上記の例の場合、初めてステップＳ１３０３に入った時点では、ｑ＝０, ｂ＝１であるので、オリジナルコードストリームのレイヤ０は２レイヤに分割され、それぞれtmp_incのレイヤ０, レイヤ１になる。その後、ステップＳ１３０４でｑ＝１, ｎｑ＝２, ｘ＝０となり、ステップＳ１３０２に処理を戻すことになる。ステップＳ１３０２に戻った時点では、ｘ＝０になっているので、ステップＳ１３０５に進むことになる。
【０１２６】
ステップＳ１３０５では、タイルｔのレイヤｑをｂ個のレイヤに分割し、tmp_incのレイヤｎｑ〜レイヤ（ｎｑ＋ｂ−１）とする処理を行う。この処理もステップＳ１３０３と同様に、ステップＳ１２０１で取得した、各パケットのレイヤに分割できるビットプレーンの境界の位置情報に基づいて、レイヤをビットプレーンの境界で分割することにより、分割処理を行う。
【０１２７】
次に、ステップＳ１３０６では、オリジナルコードストリームのレイヤ番号の変数ｑに１を加え、tmp_incのレイヤ番号変数ｎｑにｂを加える。
【０１２８】
ステップＳ１３０７では、tmp_incのレイヤ番号変数ｎｑが、画質選択肢数Ｍと等しいか否かを判定する。ｎｑ＝Ｍの場合（ステップＳ１３０７でＹＥＳ）は、Ｍ個のレイヤに分割し終えたと判断し、ステップＳ１０１３へ進む。ｎｑとＭが等しくない場合（ステップＳ１３０７でＮＯ）は、オリジナルコードストリームのレイヤをさらに分割する必要があると判断し、ステップＳ１３０５へ処理を戻し、さらに、ステップＳ１３０５、Ｓ１３０６の処理を継続する。
【０１２９】
上記の例の場合、ステップＳ１３０２からステップＳ１３０５へ移った時点で、ｑ＝１, ｎｑ＝２, ｂ＝１となっているので、ステップＳ１３０５でオリジナルコードストリームのレイヤ １を１つのレイヤに分割する。この場合は、分割前後でレイヤ数が変化しないため、オリジナルコードストリームのレイヤ１を分割する必要が無く、そのまま、tmp_incのレイヤ ２となる。
【０１３０】
そしてステップＳ１３０６では、ｑ＝２, ｎｑ＝２＋１＝３となり、ステップＳ１３０７でｎｑ＝Ｍ＝３から、ｎｑとＭは等しい（ステップＳ１３０７でＹＥＳ）と判断され、ステップＳ１０１３へ処理を進めることになる。
【０１３１】
ステップＳ１０１３からステップＳ１０１６までは、第１実施形態の図１０の処理と同様であるので、説明は省略する。
【０１３２】
上記のように、本実施形態では、予め、各パケットについてレイヤ分割できるビットプレーンの境界の位置情報を解析しておき、レイヤ分割処理において、この情報を用いてパケットの分割処理を行うように構成したことで、コードストリームの変換の処理を簡略化することができ、変換時間をさらに短縮することができる。即ち、完全にデコードした状態から再エンコードするのではなく、レイヤ分割できるビットプレーンの境界の位置情報に基づいて、ＤＷＴ係数の段階でパケットの分割を行うことで、コードストリームの変換時間を更に短縮することができる。
【０１３３】
〔第３実施形態〕
第１、第２実施形態では、サーバ側でクライアントの上位アプリケーションが提供する画質選択肢数に合わせて、コードストリームの変換を行っていた。このコードストリーム変換は必ずしもサーバで行う必要はなく、クライアント側で行うように構成してもよい。  本実施形態では、アプリケーションの画質選択肢数に合わせて、クライアントが変換コードストリームを作成する。まず、アプリケーションの画質選択肢に、サーバにあるＪＰＥＧ２０００符号化データのレイヤをマッピングする。その後、アプリケーションの表示要求に基づいてＪＰＩＰリクエストを作成し、サーバにデータを要求する。サーバから返送されたデータを、サーバ側のエンコード条件のままキャッシュする。そのキャッシュデータからアプリケーションに表示用コードストリームを渡す際に、画質選択肢数に合わせて、コードストリーム変換を行う。尚、サーバ側が保持するＪＰＥＧ２００画像データには、第２実施形態と同様に、各パケットの中でレイヤに分割できるビットプレーンの境界の位置情報がベンダー定義の情報として、それぞれのファイルのUUID boxの中に独自の形式で格納されているものとする。クライアントは、この分割位置（ビットプレーンの境界の位置）の情報を利用してコードストリーム変換を行う。
【０１３４】
（クライアント処理）
このような動作をするクライアントについて、図１４を参照して説明する。図１４は、クライアント処理の流れを示したフローチャートである。
【０１３５】
まず、ステップＳ１４０１では、クライアント上の上位アプリケーションから提供画質選択肢数Ｍを取得する。以下、低・中・高の３つの画質選択肢数を持つ場合について例示的に説明する。
【０１３６】
次に、ステップＳ１４０２では、上位アプリケーションから画像データの表示要求を取得する。ここでは、表示したい画像ファイルの名前、その画像全体のサイズや、その中の表示したい部分領域の位置と大きさ及び、画質などに関する要求事項を取得する。なお、提供画質選択肢数ＭをステップＳ１４０１ではなく、この要求事項に含めて取得するように構成してもよい。
【０１３７】
次に、ステップＳ１４０３では、ステップＳ１４０２でアプリケーションから受け取った要求事項に記述された画像データに対応するファイルが、クライアント上の所定の記憶装置（例えば、一時記憶１０２、二次記憶１０３等）に存在するか否かを判定する。キャッシュデータが存在しない場合（ステップＳ１４０３でＹＥＳ）はステップＳ１４０４へ進み、キャッシュデータが存在する場合（ステップＳ１４０３でＮＯ）はステップＳ１４０６へ進む。
【０１３８】
ステップＳ１４０４では、ステップＳ１４０２で取得した要求事項に基づいて、表示したい画像のmain headerと各パケット情報を含む、画像の送信要求（リクエスト）情報をサーバに送出する。このパケット情報とは、１レイヤを複数のレイヤに分割可能な位置の情報、即ち、ビットプレーンの境界の位置情報であり、本実施形態の場合、UUID boxがこれに相当する。
【０１３９】
次に、ステップＳ１４０５では、サーバから返送されたmain headerとパケット情報を受信し、クライアント上の所定の記憶装置（例えば、一時記憶１０２、二次記憶１０３等）にキャッシュとして保存する。そして、ステップＳ１４０６へ進む。
【０１４０】
ステップＳ１４０６では、キャッシュされたmain headerを解析し、サーバから受信した画像データを構成するレイヤ数Ｑを取得する。これは、ＣＯＤマーカを解析することで得られる。
【０１４１】
次に、ステップＳ１４０７では、ステップＳ１４０６で取得したレイヤ数ＱとステップＳ１４０１で取得した提供画質数Ｍの対応関係を作成する。この対応関係の作成処理については、図１５を参照して後述する。上記の例の場合、sample.jp2が要求されていれば、低レベルおよび中レベルの画質に対応するのはレイヤ０、高レベルの画質はレイヤ１となる。example.jp2が要求されていれば、低レベルにはレイヤ０とレイヤ１、中レベルにはレイヤ２とレイヤ３、高レベルにはレイヤ４が対応する。
【０１４２】
次に、ステップＳ１４０８では、ステップＳ１４０７で作成された対応関係から、表示要求画質をレイヤにマッピングする。表示要求画質が複数のレイヤと対応付けられている場合には、その中で最も高画質なレイヤにマッピングする。上記の例では、例えば、アプリケーションがexample.jp2を中レベルで表示したいと要求した場合、レイヤ２とレイヤ３のうち、高画質のレイヤであるレイヤ３にマッピングすることになる。
【０１４３】
次に、ステップＳ１４０９ではキャッシュデータを参照し、上位アプリケーションから要求された表示を行うために、キャッシュされたデータで不足がないか否かを判定する。不足データがあると判定した場合（ステップＳ１４０９でＹＥＳ）は、ステップＳ１４１０へ進み、不足データがないと判定した場合（ステップＳ１４０９でＮＯ）は、ステップＳ１４１２に進む。
【０１４４】
ステップＳ１４１０では、ＪＰＩＰリクエストを作成し、サーバに送信する。ＪＰＩＰリクエストの作成処理は、例えば、通常のＪＰＩＰクライアントが行う処理と同様の処理を採用することができる。
【０１４５】
次に、ステップＳ１４１１では、サーバからのレスポンスデータを受信し、キャッシュする。キャッシュ手法については、例えば、特許文献３で開示されている手法を用いてもよいし、その他の手法を用いてもよい。キャッシュ手法については、本件の主眼ではないので、説明は省略する。そして、ステップＳ１４１２へ進む。
【０１４６】
ステップＳ１４１２では、キャッシュデータから表示用のコードストリームを作成し、画像の表示要求を出したアプリケーションに表示用コードストリームを提供する。この際、レイヤ数Ｑを提供画質選択肢数Ｍと同一にするように変換する。これは、第１、第２実施形態と同様の処理で実現できる。つまり、Ｑ＝Ｍの場合は変換しない。Ｑ＞Ｍの場合には図１０に示した処理（レイヤ合成処理）と同様の処理を行う。Ｑ＜Ｍの場合には、図１３に示した処理（レイヤ分割処理）と同様の処理を行う。
【０１４７】
次に、ステップＳ１４１３では、上位アプリケーションが、ステップＳ１４１２で作成されたコードストリームを受け取り、そのコードストリームをデコードして出力デバイス１０５に画像を表示する。
【０１４８】
次に、ステップＳ１４１４では、新しい表示要求があるか否かを判定し、新たな表示要求がある場合（ステップＳ１４１４でＹＥＳ）はステップＳ１４１５へ進み、表示要求が無い場合（ステップＳ１４１４でＮＯ）は、このフローを終了する。
【０１４９】
ステップＳ１４１５では、アプリケーションからの新たな表示要求を取得し、ステップＳ１４０８へ処理を戻す。
【０１５０】
（対応関係作成処理）
次に、ステップＳ１４０７における、レイヤ数Ｑと提供画質数Ｍの対応関係作成処理について、図１５を参照して説明する。図１５は、対応関係作成処理の流れを示したフローチャートである。
【０１５１】
ステップＳ１５０１では、提供画質カウンタｉとレイヤカウンタｑの双方に０を代入して、初期化する。これらの値は、一時記憶１０２等に領域を確保して一時的に記憶するものとする。
【０１５２】
次に、ステップＳ１５０２では、レイヤ数Ｑと提供画質数Ｍが等しいか否かを判定し、等しい場合（ステップＳ１５０２でＹＥＳ）はステップＳ１５０３へ進み、異なる場合（ステップＳ１５０２でＮＯ）はステップＳ１５０６へ進む。
【０１５３】
ステップＳ１５０３以降の処理では、レイヤ数Ｑと提供画質数Ｍが同数であるので、レイヤと提供画質を１対１に対応させる処理を行う。
【０１５４】
ステップＳ１５０３では、各提供画質レベルに対応するレイヤ番号を格納する配列ｍ[ｉ]にレイヤ番号ｑを代入する。この配列ｍ[ｉ]も、一時記憶１０２等に領域を確保して一時的に記憶するものとする。
【０１５５】
次に、ステップＳ１５０４では、提供画質カウンタｉ、およびレイヤカウンタｑの値をそれぞれ１増やす。次に、ステップＳ１５０５では、提供画質カウンタｉの値と提供画質数Ｍの値を比較し、等しい場合（ステップＳ１５０５でＹＥＳ）はこのフローを終了し、異なる場合（ステップＳ１５０５でＮＯ）はステップＳ１５０３へ処理を戻し、更にステップＳ１５０３、Ｓ１５０４の処理を繰り返す。
【０１５６】
上記の例の場合、sample.jp2のレイヤ数は２、example.jp2のレイヤ数は５、提供画質数は３であるので、sample.jp2、example.jp2のいずれのファイルへの要求であっても、ステップＳ１５０２からステップＳ１５０６へ処理を進める（ステップＳ１５０２でＮＯ）ことになる。
【０１５７】
ステップＳ１５０６では、レイヤ数Ｑと提供画質数Ｍの大小を比較する。ＱがＭよりも大きい場合（ステップＳ１５０６でＹＥＳ）はステップＳ１５０７へ進み、ＱがＭよりも小さい場合（ステップＳ１５０６でＮＯ）はステップＳ１５１４へ進む。上記の例の場合、sample.jp2への要求であれば、Ｑ＝２＜Ｍ＝３であるので、ステップＳ１５１４へ進み、example.jp2への要求であれば、Ｑ＝５＞Ｍ＝３であるので、ステップＳ１５０７へ進むことになる。
【０１５８】
ステップＳ１５０７では、レイヤ数Ｑを提供画質数Ｍで割り、商をｂ、余りをｘとする。
【０１５９】
次に、ステップＳ１５０８では、各提供画質レベルに対応するレイヤ番号を格納する配列ｍ[ｉ]にレイヤｑ〜レイヤ（ｑ＋ｂ−１）の番号ｑ〜（ｑ＋ｂ−１）を格納する。配列ｍ[ｉ]は、例えば、一時記憶１０２に必要な領域を確保し、一時的に値を保持するようにする。
【０１６０】
次に、ステップＳ１５０９では、提供画質レベル用カウンタｉに１加え、レイヤカウンタｑにｂを加える。
【０１６１】
次に、ステップＳ１５１０では、提供画質レベル用カウンタｉと、提供画質数ＭからステップＳ１５０７で求めた余りｘを引いた値とを比較し、値が等しい場合（ステップＳ１５１０でＹＥＳ）はステップＳ１５１１へ進み、値が異なる場合（ステップＳ１５１０でＮＯ）はステップＳ１５０８へ処理を戻し、さらにステップＳ１５０８、Ｓ１５０９の処理を繰り返す。このような処理を行うことで、（Ｍ−ｘ）個の画質レベルに、ｂ個のレイヤを割り当てることになる。
【０１６２】
ステップＳ１５１１では、値ｘが０より大きいか否かを判定する。０より大きい場合（ステップＳ１５１１でＹＥＳ）はステップＳ１５１２へ進み、そうでない場合（ステップＳ１５１１でＮＯ）はこのフローを終了する。
【０１６３】
ステップＳ１５１２では、各提供画質レベルに対応するレイヤ番号を格納する配列ｍ[ｉ]にレイヤｑ〜レイヤ（ｑ＋ｂ）の番号ｑ〜（ｑ＋ｂ）
次に、ステップＳ１５１３では、提供画質レベル用カウンタｉに１を加え、レイヤカウンタｑに（ｂ＋１）を加え、ｘの値を一つ減らす。
【０１６４】
つまり、ｘはステップＳ１５０７で求めた余りｘの値であるので、Ｑ÷Ｍが割り切れる場合は、ステップＳ１５１２およびステップＳ１５１３の処理を一度も実行せずにこのフローを終了し、割り切れない場合は、余りｘの回数だけ、ステップＳ１５１２とステップＳ１５１３の処理を繰り返すことになる。
【０１６５】
上記の例では、example.jp2への要求を行った場合、Ｑ＝５, Ｍ＝３であるので、Ｑ÷Ｍ＝５÷３＝１余り２となる。したがって、ステップＳ１５１１までに、最初のレベル（レベル低）にレイヤ０が割り当てる処理を行う。さらに、ステップＳ１５１１〜Ｓ１５１３によって、２番目のレベル（レベル中）にレイヤ１とレイヤ２を、３番目のレベル（レベル高）にレイヤ３とレイヤ４を割り当てる処理を行う。
【０１６６】
上述のように、本実施形態において、sample.jp2への要求を行った場合、Ｑ＝２＜Ｍ＝３であるため、処理はステップＳ１５０６からステップＳ１５１４へ進められる。
【０１６７】
ステップＳ１５１４では、提供画質数Ｍをレイヤ数Ｑで割り算し、商をｂ、余りをｘとする。
【０１６８】
次に、ステップＳ１５１５では、各提供画質レベルに対応するレイヤ番号を格納する配列ｍ[ｉ]〜ｍ[ｉ＋ｂ−１]にレイヤｑの番号ｑを代入する。配列ｍ[ｉ]は、上記と同様に、例えば、一時記憶１０２に必要な領域を確保し、一時的に値を保持するように構成する。
【０１６９】
次に、ステップＳ１５１６では、提供画質レベル用カウンタｉにｂを加える処理を行う。
【０１７０】
次に、ステップＳ１５１７では、ｘの値が０より大きいか否かを判定する。ｘの値が０より大きい場合（ステップＳ１５１７でＹＥＳ）はステップＳ１５１８へ進み、そうでない場合（ステップＳ１５１７でＮＯ）はステップＳ１５２０へ進む。
【０１７１】
ステップＳ１５１８では、各提供画質レベルに対応するレイヤ番号を格納する配列ｍ[ｉ]にレイヤｑの番号ｑを代入する。
【０１７２】
次に、ステップＳ１５１９では、提供画質レベル用カウンタｉに１を加え、ｘの値を一つ減らす。そして、ステップＳ１５２０へ進む。
【０１７３】
ステップＳ１５２０では、レイヤカウンタｑに１を加える。
【０１７４】
次に、ステップＳ１５２１では、提供画質レベル用カウンタｉと提供画質数Ｍの値を比較する。提供画質レベル用カウンタｉと提供画質数Ｍが等しい場合（ステップＳ１５２１でＹＥＳ）はこのフローを終了し、異なる場合（ステップＳ１５２１でＮＯ）には、処理をステップＳ１５１５へ戻し、ステップＳ１５１５〜Ｓ１５２０の処理を繰り返す。つまり、ステップＳ１５１４で求めた余りｘと同数のレイヤまでは、１つのレイヤを（ｂ＋１）個の提供画質レベルに分割し、残りの（Ｑ−ｘ）個のレイヤは、１つのレイヤをｂ個の提供画質レベルで分割することになる。
【０１７５】
上記の例においてsample.jp2へ要求を行った場合、Ｑ＝２, Ｍ＝３であるので、Ｍ÷Ｑ＝３÷２＝１余り１となる。したがって、レイヤ０を２個の提供画質レベル（レベル低、中）に分割して割り当て、レイヤ１を１個の提供画質レベル（レベル高）に割り当てることになる。
【０１７６】
上記のように、本実施形態の構成においては、クライアント側でコードストリームの変換の処理を行うことで、オリジナルコードストリームのレイヤ数と、クライアントの上位アプリケーションが想定する画質レベル数とが一致しない場合においても、クライアント上の上位アプリケーションは予め設計された画質レベル数の画像データを取得、表示することができる。
【０１７７】
また、クライアント上にキャッシュされたコードストリームをアプリケーションに渡すコードストリームに変換する際に、アプリケーションが必要とする画質数に変換するように構成したことで、異なるデザインを持つ複数のアプリケーション間で、一つのキャッシュデータを共有することができる。即ち、同一のキャッシュデータから、アプリケーションの様々な用途に合わせて多様なコードストリームを生成することができる。このため、クライアントのキャッシュの容量は、オリジナルコードストリームを格納できる程度の容量があればよい。
【０１７８】
〔第４実施形態〕
第１乃至第３実施形態では、ネットワークを介してＪＰＥＧ２０００画像を断片的に送受信するサーバ／クライアントシステムについて述べた。しかし、ネットワークを経由せず、クライアントに接続された、或いは、クライアントに備えられた、ＣＤ−ＲＯＭ等のメディアや外部記憶装置等から画像データをダウンロードし、上位アプリケーションに画像データを渡し、表示処理を実行する際に、アプリケーションに合わせて、レイヤ数を変換するように構成してもよい。
【０１７９】
（ダウンロードデータの変換処理）
ＪＰＥＧ２０００画像のデータをダウンロードし、必要に応じてレイヤ数を変換する処理（ダウンロードデータの変換処理）について、図１６を参照して説明する。図１６は、ダウンロードデータの変換処理の流れを示したフローチャートである。
【０１８０】
ステップＳ１６０１では、画像データを利用する（例えば、表示する等）アプリケーションが提供する、画質数Ｍを取得する。
【０１８１】
次に、ステップＳ１６０２では、表示する全ての画像データファイルをＣＤ−ＲＯＭ等のメディアや外部記憶装置等からダウンロードする。
【０１８２】
次に、ステップＳ１６０３では、ステップＳ１６０２でダウンロードした画像のmain headerを解析し、レイヤ数Ｑを取得する。
【０１８３】
次に、ステップＳ１６０４では、ステップＳ１６０１で取得した提供画質数Ｍに合わせて、ステップＳ１６０２でダウンロードしたファイルのレイヤ数Ｑを変更した画像データを作成する。この処理は、例えば、第１乃至第３実施形態の処理のいずれかを採用することができる。
【０１８４】
次に、ステップＳ１６０５では、ステップＳ１６０４で作成した画像データを、上位アプリケーションに転送し、このフローを終了する。画像データを受け取った上位アプリケーションは、レイヤ数が変更された画像データを利用して処理を行うことができる。
【０１８５】
本実施形態の構成においては、外部記憶装置から画像データをファイル単位でダウンロードし、そのレイヤ数をアプリケーション（のＵＩデザイン）が想定する画質レベル数に基づいて変更してからアプリケーションに渡すため、レイヤの分割配信を伴うことなく、１回の変換処理により画像データをアプリケーションに対応したレイヤ数に変換することができる。
【０１８６】
〔その他の実施形態〕
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１８７】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１８８】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【０１８９】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１９０】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０１９１】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１９２】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。  また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１９３】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１９４】
【図１】本実施形態の構成における、サーバ及びクライアントのハードウェア構成を示したブロック図である。
【図２】本実施形態の構成におけるシステムの概略を示した模式図である。
【図３】ＪＰＥＧ２０００の符号化データの概略図である。
【図４】レイヤとビットプレーンとの関係を示した図である。
【図５】パケット単位のリクエストおよびレスポンスの対応関係を示した図である。
【図６】precinct data-binの構造の概略図である。
【図７】ＪＰＩＰ Response Dataの一例を示す図である。
【図８】サーバ装置の処理の流れを示したフローチャートである。
【図９】返送コードストリーム設定処理の流れを示したフローチャートである。
【図１０】ファイル変換処理の流れを示したフローチャートである。
【図１１】ＣＯＤマーカの構成を模式的に示した図である。
【図１２】返送コードストリーム設定処理の流れを示したフローチャートである。
【図１３】レイヤ分割処理の流れを示したフローチャートである。
【図１４】クライアント処理の流れを示したフローチャートである。
【図１５】対応関係作成処理の流れを示したフローチャートである。
【図１６】ダウンロードデータの変換処理の流れを示したフローチャートである。
【図１】
2006345452.tif 000003
【図２】
2006345452.tif 000004
【図３】
2006345452.tif 000005
【図４】
2006345452.tif 000006
【図５】
2006345452.tif 000007
【図６】
2006345452.tif 000008
【図７】
2006345452.tif 000009
【図８】
2006345452.tif 000010
【図９】
2006345452.tif 000011
【図１０】
2006345452.tif 000012
【図１１】
2006345452.tif 000013
【図１２】
2006345452.tif 000014
【図１３】
2006345452.tif 000015
【図１４】
2006345452.tif 000016
【図１５】
2006345452.tif 000017
【図１６】
2006345452.tif 000018