(57)【要約】【課題】  エンコードオプションを利用してエンコードされた画像データを、エンコードオプションに対応していないデコーダを備えた情報処理装置が利用可能にする技術を提供する。【解決手段】  本発明によれば、メインヘッダと１以上のタイルデータから構成される画像データを記憶する記憶手段であって、該タイルデータはそれぞれタイルパートヘッダと１以上のパケットデータから構成され、該画像データは１以上の前記パケットデータにそれぞれ対応する１以上のパケットヘッダを含む、記憶手段と、外部装置から前記画像データの送信要求を受信する受信手段と、前記パケットデータと当該パケットデータに対応する前記パケットヘッダとが交互に配列するように前記画像データを再構成する第１の再構成手段と、再構成された前記画像データを前記外部装置に送出する送出手段と、を備えることを特徴とするサーバ装置が提供される。【選択図】  図１２
2007053444.tif 000002
【特許請求の範囲】
【請求項１】
メインヘッダと１以上のタイルデータから構成される画像データを記憶する記憶手段であって、該タイルデータはそれぞれタイルパートヘッダと１以上のパケットデータから構成され、該画像データは１以上の前記パケットデータにそれぞれ対応する１以上のパケットヘッダを含む、記憶手段と、
外部装置から前記画像データの送信要求を受信する受信手段と、
前記パケットデータと当該パケットデータに対応する前記パケットヘッダとが交互に配列するように前記画像データを再構成する第１の再構成手段と、
再構成された前記画像データを前記外部装置に送出する送出手段と、を備えることを特徴とするサーバ装置。
【請求項２】
前記１以上のパケットヘッダは前記メインヘッダに含まれることを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記１以上のパケットヘッダは、当該パケットヘッダに対応する前記パケットデータが含まれる前記タイルデータの前記タイルパートヘッダに含まれることを特徴とする請求項１に記載のサーバ装置。
【請求項４】
前記受信手段は前記外部装置から前記メインヘッダの送信要求を更に受信し、
前記メインヘッダに前記パケットヘッダが含まれる場合は、該パケットヘッダを削除して該メインヘッダを再構成する第２の再構成手段を更に備え、
前記送出手段は、更に、再構成された前記メインヘッダを前記外部装置に送出することを特徴とする請求項１乃至３のいずれか１項に記載のサーバ装置。
【請求項５】
前記受信手段は前記外部装置から前記タイルパートヘッダの送信要求を更に受信し、
前記タイルパートヘッダに前記パケットヘッダが含まれる場合は、該パケットヘッダを削除して該タイルパートヘッダを再構成する第３の再構成手段を更に備え、
前記送出手段は、更に、再構成された前記タイルパートヘッダを前記外部装置に送出することを特徴とする請求項１乃至４のいずれか１項に記載のサーバ装置。
【請求項６】
前記画像データはＪＰＥＧ２０００方式に基づく符号化データであることを特徴とする請求項１乃至５のいずれか１項に記載のサーバ装置。
【請求項７】
前記受信手段、及び、前記送出手段は、ＪＰＩＰに基づいて前記外部装置と通信を行うことを特徴とする請求項１乃至６のいずれか１項に記載のサーバ装置。
【請求項８】
メインヘッダと１以上のタイルデータから構成される画像データを記憶する記憶手段であって、該タイルデータはそれぞれタイルパートヘッダと１以上のパケットデータから構成され、該画像データは１以上の前記パケットデータにそれぞれ対応する１以上のパケットヘッダを含む、記憶手段を備えたサーバ装置の制御方法であって、
外部装置から前記画像データの送信要求を受信する受信工程と、
前記パケットデータと当該パケットデータに対応する前記パケットヘッダとが交互に配列するように前記画像データを再構成する再構成工程と、
再構成された前記画像データを前記外部装置に送出する送出工程と、を備えることを特徴とするサーバ装置の制御方法。
【請求項９】
コンピュータを請求項１乃至８のいずれかに記載のサーバ装置として機能させるためのコンピュータプログラム。
【請求項１０】
請求項９に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像データを送受信する技術に関する。
【背景技術】
【０００２】
近年、コンピュータの表示装置等に用いられるディスプレイの解像度が向上している。かつて普及していたディスプレイの解像度は、ＶＧＡ(６４０×４８０画素)、ＳＶＧＡ(８００×６００画素)程度以下であった。これに対し、現在ではノートＰＣ（Personal Computer）でさえ、ＸＧＡ(１０２４×７６８画素)以上のディスプレイを備えている。デスクトップＰＣ等に外付けされるディスプレイにいたっては、ＳＸＧＡ(１２８０×１０２４画素), ＵＸＧＡ(１６００×１２００画素)程度の解像度を備えたものが普及している。今後、ＱＸＧＡ, ＱＵＸＧＡ等の高解像度をサポートするディスプレイが普及することは、容易に推察できる。
【０００３】
一方、デジタルカメラ等により撮影された多数の画像データをサムネイル画像（縮小画像）として並べて表示し、所定のイベントに基づいてその中の１つを元画像のサイズで詳細表示するアプリケーションが知られている。このようなアプリケーションはズームやスクロールなどの表示技術を利用していることが一般的である。
【０００４】
このようなアプリケーションにおいて、多数の画像データを同時に表示する場合には高速性が重要視されるため、主画像データとは異なる予め作成されたサムネイル画像データを用いることが多い。一方、そのサムネイル表示から選択された画像データの１枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズあるいは、ディスプレイ装置に表示できるまでは、画像全体を表示することが多い。それ以上の拡大表示については画像の一部分を表示することが多い。
【０００５】
このような、１枚の画像データを表示する際に、元画像データの画像サイズより小さい画像サイズの画像データを複数種類使用するようなアプリケーションにおいては、次のような処理を行っていた。即ち、必要に応じてデコード処理を行い、１度元画像データの画像サイズを再現し、その後、目的の画像サイズになるように、画像データを縮小する処理を行っていた。
【０００６】
一方、画像データは、非圧縮かあるいはＪＰＥＧ baselineのようなシーケンシャルの符号化方式で圧縮されていた。或いは、画像データを階層符号化方式で画像圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装していた。
【０００７】
階層符号化方式としては、例えば、ＪＰＥＧ２０００符号化方式がある。ＪＰＥＧ２０００は、１枚の画像データを１つ以上のタイルに分割し、その分割されたタイル毎に、１つ以上の解像度の画像を階層的に保持する階層符号化方式である。ＪＰＥＧ２０００は、２００１年にＩＳＯ／ＩＴＣで標準化された画像符号化方式としても知られている。
【０００８】
ＪＰＥＧ２０００符号化方式には、エンコード時のエンコード・オプションが数多く存在する。しかし、全ての機能をサポートしたデコーダは、多大な開発コストを要し、また、動作させるために通常よりも高度な演算リソース（ＣＰＵクロック、メモリ容量等）を要する。
【０００９】
また、ネットワーク上でこのＪＰＥＧ２０００で符号化された符号データファイルに対して断片的に必要な部分のみをアクセスする時のプロトコルとしてＪＰＩＰが知られており、現在策定中である。ただし、ＪＰＩＰは、JPEG2000 image coding system - Part 9: Interactivity tools, APIs and protocolsの略称である。
【００１０】
また、ＪＰＩＰを利用したサーバ、クライアントからなる画像配信システムが知られている。
【００１１】
特許文献１には、ＪＰＥＧ２０００で符号化された画像データの部分データをサーバ・クライアントで送受信するシステムが開示されている。この構成において、クライアントは、サーバに格納されているコードストリームのどの部分が、既にクライアントのバッファに格納されているかを判別し、未だバッファに格納していない圧縮データの部分をサーバに要求する。クライアントが要求するデータの単位は、例えば、ＪＰＥＧ２０００符号内のパケット、タイル、コードブロックから選択可能であり、或いは、バイト単位での要求も可能である。一方、サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。クライアントは、受信したデータと既にバッファに格納されたデータを統合してデコードを行い、画像を取得する。
【００１２】
また、特許文献２には、サーバ側に格納されているＪＰＥＧ２０００符号データを、クライアント側で高速にプログレッシブ表示するための技術が開示されている。この構成において、クライアントは、欲しい解像度レベルを指定するリクエストを発行し、サーバへ送出する。サーバは、クライアントから指定された解像度レベルのサブバンド符号データを、格納された画像ファイルから取り出してクライアントに送信する。クライアントは、表示している画像の解像度レベルの、復号化されたサブバンドの係数と、サーバから受信した符号データを復号して得られたサブバンドの係数とに基づいて画像データを復元することで、解像度方向のプログレッシブ表示を行うことができる。
【特許文献１】特開２００３-０２３６３０号公報
【特許文献２】特開２００４-０４０６７４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上述のように、ＪＰＥＧ２０００の階層符号化方式にはエンコードオプションが数多く存在する。しかしながら、デコーダ側でオプションに対応していない場合、そのデコーダはエンコードオプションを利用してエンコードされた画像をデコードすることができない。
【００１４】
例えば、ＪＰＥＧ２０００符号化方式にはＰＰＭマーカセグメントを利用するオプションやＰＰＴマーカセグメントを利用するオプションがある。ただし、ＰＰＭはPacked Packet headers, Main headerの、ＰＰＴはPacked Packet headers, Tile-part headerのそれぞれ略称である。以下、これらについて例示的に概説する。
【００１５】
ＪＰＥＧ２０００符号化方式によって符号化された画像データはパケットという符号化単位データの集まりとして構成される。そして、各パケットはそれぞれパケットヘッダとパケットデータから構成される。このように、通常の符号化モードにおいては、パケットヘッダとパケットデータのペアが論理的なパケットを構成し、１以上のパケットの集合としてＪＰＥＧ２０００の画像データが構成される。
【００１６】
ところが、ＰＰＭマーカセグメントを利用するオプションが選択された場合、画像データを構成する全てのパケットのパケットヘッダがメインヘッダのＰＰＭマーカセグメントに格納される。そして、符号データが格納される部分にはパケットヘッダは含まれず、パケットデータのみが格納される。
【００１７】
また、ＰＰＴマーカセグメントを利用するオプションが選択された場合、画像データのタイルを構成する全てのパケットのパケットヘッダがそのパケットが属するタイルのタイルパートヘッダのＰＰＴマーカセグメントに格納される。そして、符号データが格納される部分にはパケットヘッダは含まれず、パケットデータのみが格納される。
【００１８】
このように、ＰＰＭマーカセグメントやＰＰＴマーカセグメントを利用した符号化データは通常のモードにおける符号化データとコーディングブロックの配置が異なっている。このため、上記のオプションに対応したデコーダしかＰＰＭマーカセグメントやＰＰＴマーカセグメントを利用した符号化データをデコードすることができない。例えば、特許文献１、特許文献２に開示されたようなシステムにおいては、クライアント側のデコーダが上記のようなオプションに対応していない限り、画像データをデコードすることができない。
【００１９】
また、ＰＰＭマーカセグメントを利用している場合パケットヘッダは可変長である。そして、符号データ内に存在する全てのパケットのパケットヘッダがＰＰＭマーカセグメントのデータとして格納されている。このため、クライアントからメインヘッダを要求した場合、サーバから返送されてくるデータのサイズは非常に大きい（例えば、数百〜数千バイト以上）可能性がある。
【００２０】
したがって、クライアントは通信時間も推測できない。また、サーバへリクエストを送信しその応答を受け取らない限り、画像データがＰＰＭマーカセグメントを利用した形式なのか否かが判別できない。このため、クライアントのバッファ処理に係る負荷が大きいという問題がある。
【００２１】
同様に、ＰＰＴマーカセグメントを使用している場合は、どのタイルのデータに対してこのＰＰＴマーカセグメントを使用しているかをクライアント側で判断できない。このため、クライアントは全てのタイルに対してタイルパートヘッダを含むタイルパートヘッダを要求する必要があり、クライアントの処理が複雑になってしまうという問題がある。
【００２２】
本発明は上記問題に鑑みなされたものであり、エンコードオプションを利用してエンコードされた画像データを、エンコードオプションに対応していないデコーダを備えた情報処理装置が利用可能にする技術を提供することを目的とする。
【課題を解決するための手段】
【００２３】
上記目的を達成するため、本発明によるサーバ装置は以下の構成を備える。即ち、
メインヘッダと１以上のタイルデータから構成される画像データを記憶する記憶手段であって、該タイルデータはそれぞれタイルパートヘッダと１以上のパケットデータから構成され、該画像データは１以上の前記パケットデータにそれぞれ対応する１以上のパケットヘッダを含む、記憶手段と、
外部装置から前記画像データの送信要求を受信する受信手段と、
前記パケットデータと当該パケットデータに対応する前記パケットヘッダとが交互に配列するように前記画像データを再構成する第１の再構成手段と、
再構成された前記画像データを前記外部装置に送出する送出手段と、を備える。
【発明の効果】
【００２４】
本発明によれば、エンコードオプションを利用してエンコードされた画像データを、エンコードオプションに対応していないデコーダを備えた情報処理装置が利用可能にする技術を提供することができる。
【発明を実施するための最良の形態】
【００２５】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００２６】
＜＜第１実施形態＞＞
（システム構成）
まず、本実施形態におけるシステムの構成について図１を参照して説明する。図１は、インターネットに代表されるネットワーク上に複数のコンピュータが接続されている様子を示した図である。
【００２７】
図１において、１００はインターネットに代表されるネットワークである。
【００２８】
１０１はサーバ・コンピュータ（サーバ）であり、ＷＷＷサーバとして機能するために必要なソフトウエアがインストールされている。このようなソフトウエアには、例えば、画像データを送信するためのＪＰＥＧ２０００用の通信プロトコルであるＪＰＩＰサーバとして機能するためのプログラムが含まれる。サーバ１０１は、例えば、ワークステーション（ＷＳ）、パーソナルコンピュータ（ＰＣ）等の情報処理装置によって実現される。
【００２９】
また、１０４は大容量の画像データを格納するＨＤ（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（コンポーネント）番号の最大値は、エンコーダによって予め設定され、そのパラメータにしたがってエンコードされており、その情報は符号化データの中に格納されている。
【００４４】
次に、ＪＰＥＧ２０００符号化データのより詳細な構造について図４を参照して説明する。図４は、ＪＰＥＧ２０００符号データ全体をマーカセグメント単位で模式的に示した図である。
【００４５】
図４に示すように、ＪＰＥＧ２０００符号データは先頭のＳＯＣマーカ４０１と最後のＥＯＣマーカ４０２に挟まれて構成される。さらにＳＯＣマーカ４０１の後ろには、メインヘッダマーカ４０３が存在する。図４のように、ＳＯＣマーカ４０１とメインヘッダマーカ４０３は合わせてメインヘッダ４０４を構成する。
【００４６】
メインヘッダ４０４とＥＯＣマーカ４０２との間には、それぞれタイルパートヘッダ４０５とビットストリーム（符号データ）４０６（図３のデータ３０２に相当）から構成される、１以上のタイル４０７が存在する。図４の例では、タイル４０７ａ、タイル４０７ｂの２つのタイルが存在する。
【００４７】
図４のように、タイルパートヘッダ４０５はそれぞれ、ＳＯＴマーカセグメント４０８、タイルパートヘッダ・マーカセグメント４０９、ＳＯＤマーカ４１０から構成される。ＳＯＴマーカ４０８、ＳＯＤマーカ４１０は、それぞれタイルパートヘッダの先頭、ビットストリーム・データの先頭を意味する。このＳＯＴマーカセグメント４０８から符号データ４０６までで構成されるタイルパート用の符号データは、エンコードオプションにより必要な個数格納されている。例えば、画像データをタイルに分割した場合は、タイルの個数分格納されることになる。またＳＯＴマーカセグメント４０８とＳＯＤマーカ４１０に挟まれた部分４０９が各タイルのタイルパートヘッダにあたる部分である。
【００４８】
次に、メインヘッダ４０４の詳細なマーカセグメントの構成について図５を参照して説明する。図５はメインヘッダ４０４のマーカセグメントの構成を模式的に示した図である。
【００４９】
図５のように、メインヘッダ４０４は、必須のマーカセグメントとして、ＳＯＣマーカ４０１、ＳＩＺマーカセグメント５０１、ＣＯＤ５０２、ＱＣＤ５０３を含む。図５におけるその他のマーカはオプションであり、エンコードオプションに基づいて挿入される場合がある。このオプションマーカの中に前述したパケットヘッダを集めて格納するためのＰＰＭマーカセグメント５０４が存在する。
【００５０】
次に、タイルパートヘッダ４０５の詳細なマーカセグメントの構成について図６を参照して説明する。図６はタイルパートヘッダ４０５のマーカセグメントの構成を模式的に示した図である。
【００５１】
タイルパートヘッダ４０５においては、ＳＯＴマーカセグメント４０８とＳＯＤマーカ４１０以外は全てオプションであり、エンコードオプションにより挿入される場合がある。ここに前述のＰＰＴマーカセグメント６０１が存在する。
【００５２】
次に、ＰＰＭおよびＰＰＴマーカセグメントの詳細な構造について図７を参照して説明する。図７はＰＰＭ（図７（ａ））およびＰＰＴ（図７（ｂ））のそれぞれのマーカセグメントの構造を示した模式図である。
【００５３】
ＰＰＭマーカセグメントは、全てのタイルにおけるパケットヘッダを集めてメインヘッダに記述するマーカセグメントである。ＰＰＭマーカセグメントに全てのタイルにおけるパケットヘッダをまとめて記述する場合、符号データ４０６にはパケットヘッダを記述しない。
【００５４】
ＰＰＭマーカセグメントは、ＰＰＭマーカセグメントを示す情報７０１、Lppmフィールド７０２、Zppmフィールド７０３、Nppm(i)フィールド７０４、Ippm(i,j)フィールド７０５から構成される。
【００５５】
ＰＰＭマーカセグメントを示す情報７０１は１６ビット長の値0XFF60で示される。Lppmフィールド７０２はマーカセグメントのバイト数を１６ビット長で示すものである。Zppmフィールド７０３はＰＰＭマーカの識別番号であり、８ビット長で示される。Nppm(i)フィールド７０４はｉ番目のタイル部分におけるIppmのバイト数であり、３２ビット長で示される。Ippm(i,j)フィールド７０５はｉ番目のタイル部分におけるｊ番目のパケットヘッダであり、そのサイズは可変長である。なお、Ippm(i,j)フィールドに格納されたパケットヘッダは所定の圧縮アルゴリズムによって圧縮されている。
【００５６】
一方、ＰＰＴマーカセグメントは、画像を構成するタイル毎に、そのタイル部分におけるパケットヘッダをタイルパートヘッダに集めて記述するマーカセグメントである。ＰＰＴマーカセグメントにそのタイルにおけるパケットヘッダをまとめて記述する場合も、符号データ４０６にはパケットヘッダを記述しない。
【００５７】
ＰＰＴマーカセグメントは、ＰＰＴマーカセグメントを示す情報７１１、Lpptフィールド７１２、Zpptフィールド７１３、Ippt(i)フィールド７１４から構成される。
【００５８】
ＰＰＴマーカセグメントを示す情報７１１は１６ビット長の0XFF61で示される。Lpptフィールド７１２はマーカセグメントのバイト数を１６ビット長で示すものである。Zpptフィールド７１３はＰＰＴマーカの識別番号であり、８ビット長で示される。Ippt(i)フィールド７１４はタイル部分におけるｉ番目のパケットヘッダであり、そのサイズは可変長である。Ippt(i)フィールドに格納されたパケットヘッダも所定の圧縮アルゴリズムによって圧縮されている。
【００５９】
他のマーカセグメントは本実施形態に係る構成には直接関係ないので、その詳細な構造の説明は省略する。
【００６０】
（ＪＰＩＰ通信）
次に、サーバ１０１（に接続されたＨＤ装置１０４）に格納されたＪＰＥＧ２０００符号化データをクライアント１０２へ送出する場合の通信の概要について、図８を参照して説明する。図８は、画像データに係るリクエスト（要求）とレスポンス（応答）の対応を示した概念図である。
【００６１】
本実施形態に係る構成では、画像データ（符号データ）の通信をＪＰＩＰを利用して行う。これによりクライアント１０２は圧縮画像データの全てを取得するのではなく、必要な部分のデータのみを取得することが可能である。
【００６２】
クライアント１０２が受信するデータの単位としては、ＪＰＥＧ２０００のパケット、或いは、パケットよりも大きい符号化単位であるタイル単位が考えられる。ここでは送受信するデータの単位をパケット単位とした場合について例示的に説明する。図８では、送受信するデータの単位がパケット単位である場合の、リクエストおよびレスポンスの様子を示している。
【００６３】
クライアント１０２はサーバ１０１に、画像のタイル番号、解像度レベル、レイヤ、コンポーネント、ポジション番号等の情報を指定して、データを要求する。要求８０１を受け取ると、サーバ１０１は、画像８０３のコードストリームを解析して、指定されたタイル番号、解像度レベルとレイヤ、コンポーネント、ポジション番号に相当するパケットデータを抜き出す。そして、これらの情報を含む応答８０２をクライアント１０２に送り返す。
【００６４】
次に、ＪＰＩＰを使ってパケットデータを送信単位として、データを送受信する場合のレスポンス（応答）データの構成を、図９および図１０を使って説明する。
【００６５】
図９は、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と呼ぶ。precinct data-binから作成されたＪＰＩＰ messageをprecinct data-bin messageと呼ぶ。また、メインヘッダから作成されたＪＰＩＰ messageをmain header data-bin messageと呼ぶ。
【００６７】
precinct data-bin messageのメッセージボディ１００３には、precinct data-bin ９０１から切り出されたＪＰＥＧ２０００符号化データが格納される。例えば、図９のPacket(tn, rn, cn, pn, １)９０３を抜き出してＪＰＩＰ 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]１００４の値が格納される。
【００７２】
（全体処理）
次に、本実施形態に係るサーバ１０１が実行する処理の詳細を説明する。本実施形態では、ＰＰＭマーカセグメントが存在する画像データを、ＰＰＭマーカセグメントに対応していないクライアント１０２もデコード可能なように変換し、送出するサーバ１０１の構成について述べる。
【００７３】
まず、説明を簡単にするための前提事項について説明する。処理対象の画像データは、５１２×５１２画素であり、タイル数は１、解像度方向の階層は３、画質方向の階層は１、色数は１、ポジションは１で符号化されたＪＰＥＧ２０００符号データとする。この場合、符号データは以下のサブバンドから構成される。
・解像度番号０のＬＬ              （画像サイズ  １２８×１２８画素）
・解像度番号１のＨＬ, ＬＨ, ＨＨ  （画像サイズ  ２５６×２５６画素）
・解像度番号２のＨＬ, ＬＨ, ＨＨ  （画像サイズ  ５１２×５１２画素）。
そして、７個のパケットから構成される。本実施形態では、この符号データがＰＰＭマーカセグメントを利用して符号化されているとする。
【００７４】
また、クライアント１０２はＪＰＩＰプロトコルに従い、
“http://www.image.com/jpip.cgi?target=d.jp2&fsiz=256,256&type=jpp-stream”
というリクエストを発行し、サーバ１０１へ送出したとする。このリクエストはサーバ１０１に”d.jp2”というファイル名の符号データを要求するものであり、画像の大きさが２５６×２５６画素程度、返送されるデータ形式が”jpp-stream”であることを指定している。
【００７５】
なお、上記の画像データの条件やリクエスト内容は以下の説明を行うための一例であり、これに限られない。
【００７６】
次に、本実施形態に係るサーバ１０１が実行する処理のフローについて、図１１を参照して説明する。図１１は、サーバ１０１が実行する全体処理のフローを示したフローチャートである。
【００７７】
まず、ステップＳ１１０１において、サーバ１０１は、例えば上記のようなクライアント１０２からのリクエストを受信する。
【００７８】
次に、ステップＳ１１０２において、サーバ１０１は、ステップＳ１１０１で受信したリクエストの文字列を解析する。具体的には、指定された画像ファイル名や、サイズ、データ形式等の指定を取得する。ここでの解析結果は、次のステップＳ１１０３において利用される。
【００７９】
次に、ステップＳ１１０３において、ステップＳ１１０２での解析結果に基づいてレスポンスデータを作成する。このステップの処理の詳細については後述する。
【００８０】
次に、ステップＳ１１０４において、クライアント１０２へレスポンスデータを返信する。そして、サーバ１０１はクライアント１０２に対する処理を終了する。
【００８１】
（レスポンスデータ作成処理）
次に、ステップＳ１１０３において実行するレスポンスデータの作成処理の詳細について図１２を参照して説明する。図１２は、サーバ１０１が実行するレスポンスデータ作成処理の流れを示したフローチャートである。
【００８２】
まず、ステップＳ１２００において、ステップＳ１１０２で解析した解析結果から、ファイル名”d.jp2”のファイルをオープンする。そして、オープンしたファイルのメインヘッダを解析する。
【００８３】
このメインヘッダの解析の処理の詳細について図１３を参照して説明する。図１３はメインヘッダ解析処理の流れを示したフローチャートである。
【００８４】
まず、ステップＳ１３００において、先頭のＳＯＣマーカを処理する。即ち、コードストリームの先頭を認識する。
【００８５】
次に、ステップＳ１３０１でＳＩＺマーカセグメントを処理する。即ち、符号データのエンコードオプションなどを解析し、画像サイズや解像度方向の階層数等を取得する。上記の例では、最大解像度の画像サイズは５１２×５１２画素であり、解像度方向の階層数は３である等の情報を取得する。
【００８６】
次に、ステップＳ１３０２で次のマーカコード取得する。即ち、解析済みのマーカセグメントに続くマーカセグメントのマーカコードを取得する。
【００８７】
次に、ステップＳ１３０３において、ステップＳ１３０２で取得したマーカコードがＳＯＴマーカか否かを判定する。上述のように、ＳＯＴマーカはタイルパートヘッダの先頭を意味する。このため、マーカコードがＳＯＴマーカの場合（ステップＳ１３０３でＹＥＳ）はこのメインヘッダ解析処理を終了する。一方、ＳＯＴマーカではない場合（ステップＳ１３０３でＮＯ）は、ステップＳ１３０４へ進む。
【００８８】
ステップＳ１３０４においては、ステップＳ１３０２で取得したマーカコードがＰＰＭマーカか否かを判定する。ここでＰＰＭマーカの場合（ステップＳ１３０３でＹＥＳ）はステップＳ１３０６へ進み、ＰＰＭマーカでない場合（ステップＳ１３０３でＮＯ）はステップＳ１３０５へ進む。
【００８９】
ステップＳ１３０５では、次のマーカコードまでマーカセグメントをスキップする。そして、ステップＳ１３０２へ戻り、次のマーカコードを取得して同様の処理を繰り返す。  一方、ステップＳ１３０６では、ＰＰＭマーカセグメントの解析処理を行う。即ち、Lppmフィールド、Zppmフィールド、Nppm(i)フィールド、Ippm(i,j)フィールドを取得する。そしてステップＳ１３０２へ戻る。
【００９０】
以上のメインヘッダ解析処理を終了すると、図１２のステップＳ１２０１へ進む。
【００９１】
ステップＳ１２０１においては、ステップＳ１３０１において取得した解像度方向の階層数に基づいて返信するパケットの数を求める。例えば今回は、要求されている画像サイズが２５６×２５６画素である。このため、符号データ内では、
解像度番号０（画像サイズ１２８×１２８画素）のＬＬ、解像度番号１（画像サイズ  ２５６×２５６画素）のＨＬ, ＬＨ, ＨＨの４つのパケットを返信すればよいことがわかる。
【００９２】
次に、ステップＳ１２０２において、ステップＳ１２００での解析結果から、リクエストに係る画像データにＰＰＭマーカセグメントが存在するか否かを判定する。ＰＰＭマーカセグメントが存在しない場合（ステップＳ１２０２でＮＯ）は、ステップＳ１２０８に進む。ステップＳ１２０８では、符号データに対し通常のパケットの取り出し処理を行い、レスポンスデータ作成処理を終了して、図１１のステップＳ１１０４へ進む。一方、ＰＰＭマーカセグメントが存在した場合（ステップＳ１２０２でＹＥＳ）は、ステップＳ１２０３に進む。
【００９３】
ステップＳ１２０３では、クライアント１０２へ返送するパケットを特定する処理を行う。上記の例の場合は、まず、解像度番号０のＬＬに対応するパケットを特定する。解像度番号０のＬＬに対応するパケットについて既にステップＳ１２０３乃至ステップＳ１２０６の処理がなされている場合は、解像度番号１のＨＬのパケットを特定する。このように、解像度番号０のＬＬ、解像度番号１のＨＬ、ＬＨ、ＨＨ、解像度番号２のＨＬ、ＬＨ、ＨＨの順にパケットを１つずつ特定していく。
【００９４】
次にステップＳ１２０４では、ステップＳ１２０３で特定されたパケットのパケットヘッダをＰＰＭマーカセグメントから取り出す処理を行う。この処理の詳細については後述する。
【００９５】
次に、ステップＳ１２０５において、ステップＳ１２０４で取り出したパケットヘッダに対応するパケットデータを符号データから取り出す。この処理の詳細については後述する。
【００９６】
次に、ステップＳ１２０６において、パケットヘッダとパケットデータを結合し、返信用のパケットを生成する。
【００９７】
次に、ステップＳ１２０７では、返信するパケットの全てについて処理が終了したか否かを判定する。終了した場合（ステップＳ１２０７でＹＥＳ）はレスポンスデータ作成処理を終了し、図１１のステップＳ１１０４へ進む。終了していない場合（ステップＳ１２０７でＮＯ）はステップＳ１２０３へ戻り、全てのパケットについて処理が終了するまで上記の処理を継続する。
【００９８】
（パケットヘッダの取り出し処理）
次に、図１２のステップＳ１２０４においてＰＰＭマーカセグメントからが該当するパケットヘッダを取り出す処理について、図１４を参照して説明する。図１４は、パケットヘッダの取り出し処理の流れを示したフローチャートである。
【００９９】
まず、ステップＳ１４００では、ステップＳ１３０６で解析処理したＰＰＭマーカセグメントから、このマーカセグメントのバイト数であるLppmの値を取得する。
【０１００】
次に、ステップＳ１４０１でＰＰＭマーカの識別番号を取得する。即ち、Zppmの値を取得する。
【０１０１】
次に、ステップＳ１４０２では、その後に読み取るパケットヘッダのバイト数を取得する。即ち、Nppm(i)フィールドの値を取得する。尚、上述のように、Nppm(i)はｉ番目のタイル部分におけるIppmのバイト数を示しているが、本実施形態ではステップＳ１４０２乃至ステップＳ１４０６の処理を、全てのタイルについてそれぞれ実行する。つまり、タイルの総数をＴとすると、ｉ＝１，２，・・・，ＴのそれぞれステップＳ１４０２乃至ステップＳ１４０６の処理を行う。以下、ｉ番目のタイル部分について処理を行うものとして説明を進める。
【０１０２】
次に、ステップＳ１４０３において、各Ippmフィールドに圧縮されて格納されたパケットヘッダについて解凍処理を行う。この解凍結果であるパケットデータのバイト数は、後の処理で使用するため、メモリ（ＲＯＭ２０４、ＲＡＭ２０５、ハードディスク２０６等）上など、後から参照できる場所に格納しておく。
【０１０３】
尚、上述のように、Ippm(i,j)はｉ番目のタイル部分におけるｊ番目のパケットヘッダを示しているが、本実施形態ではステップＳ１４０４乃至Ｓ１４０５の処理を、ｉ番目のタイル部分における全てのパケットヘッダについてそれぞれ実行する。つまり、ｉ番目のタイル部分におけるパケットヘッダの総数をＰとすると、ｊ＝１，２，・・・，ＰのそれぞれステップＳ１４０４乃至ステップＳ１４０５の処理を行う。以下、ｊ番目のパケットヘッダについて処理を行うものとして説明を進める。
【０１０４】
次に、ステップＳ１４０４において、参照しているパケットが取り出すパケット、即ち、図１２のステップＳ１２０３で特定されたパケットか否かを判定する。特定されたパケットである場合（ステップＳ１４０４でＹＥＳ）はステップＳ１４０７へ進む。ステップＳ１４０７では当該パケットヘッダを取得し、パケットヘッダ取り出しの処理を終了し図１２のステップＳ１２０５へ進む。一方、特定されたパケットではない場合（ステップＳ１４０４でＮＯ）は、ステップＳ１４０５へ進む。
【０１０５】
ステップＳ１４０５では、ステップＳ１４０２で取得したｉ番目のタイルに含まれる全てのパケットについて処理を行ったか否かを判定する。これは、例えば、ｊの値がＰに等しいか否かを判定することと等価である。全てのパケットについて処理していない場合、即ち、ｊの値がＰに等しくない場合（ステップＳ１４０５でＮＯ）は、ステップＳ１４０３に戻る。ステップＳ１４０３ではｊの値をインクリメントして同様の処理を行う。一方、全パケットを処理した場合、即ち、ｊの値がＰに等しい場合（ステップＳ１４０５でＹＥＳ）は、ステップＳ１４０６へ進む。
【０１０６】
ステップＳ１４０６では、このＰＰＭマーカセグメントに格納されている全てのタイルについて上記の処理を行ったか否かを判定する。全てのタイルについて処理を行っていない、即ち、未処理のタイルがある場合（ステップＳ１４０６でＮＯ）は、ステップＳ１４０２に戻る。ステップＳ１４０２ではｉの値をインクリメントして同様の処理を行う。全てのタイルについて処理を行った場合（ステップＳ１４０６でＹＥＳ）はステップＳ１２０３で特定されたパケットに相当するパケットヘッダが存在しないことを意味するため、所定のエラー発生処理を実行して本パケットヘッダ取出処理を終了する。ただし、エラー発生処理には、例えば、エラーが発生したことをログに残す等の処理が含まれる。
【０１０７】
（パケットデータの取り出し処理）
次に、図１２のステップＳ１２０５において実行するパケットデータの取り出しに関する処理に関して、図１５を参照して説明する。図１５はパケットデータの取り出し処理の流れを示したフローチャートである。
【０１０８】
まず、ステップＳ１５００において、符号データファイル内において、実際にリード（ＲＥＡＤ）する符号データが格納されている部分の先頭位置に、処理対象のデータを指す参照ポインタを移動する。この処理は、例えばファイルをリードする場合は、ファイルのSeek()関数などを利用して実行する。
【０１０９】
以下、ステップＳ１５０１乃至ステップＳ１５０４において、符号データファイルをパケット単位で先頭位置から順に参照し、図１２のステップＳ１２０３で特定されたパケットに対応するデータを取得する処理を実行する。例えば、ステップＳ１５０１の処理を初めて実行するときは、符号データファイルの先頭位置に存在するパケットについてステップＳ１５０１以下の処理を実行することになる。
【０１１０】
ステップＳ１５０１において、図１４のステップＳ１４０３で解凍したパケットヘッダを参照し、処理中のパケットのパケットデータ長（バイト数）を取得する。より具体的には、処理中のパケットに対応するパケットヘッダの解凍結果から、このパケットのパケットデータ長を取得する。例えば、ステップＳ１５０１の処理を初めて実行するときは、符号データファイルの先頭位置に存在するパケットのパケットデータ長を取得することになる。
【０１１１】
次に、ステップＳ１５０２において、処理中のパケットが取得すべきパケット、即ち、図１２のステップＳ１２０３で特定されたパケットであるか否かを判定する。取得すべきパケットの場合（ステップＳ１５０２でＹＥＳ）はステップＳ１５０４へ進み、パケットデータを取得する。そして、このパケットデータ取り出し、パケットデータ取り出しの処理を終了して、図１２のステップＳ１２０６へ進む。一方、取得すべきパケットではない場合（ステップＳ１５０２でＮＯ）は、ステップＳ１５０３で処理中のパケットデータをスキップする処理をおこなう。これはステップＳ１５０１で取得したバイト数分をスキップすればよい。その後、ステップＳ１５０１に戻り、処理を繰り返す。
【０１１２】
以上のように、本実施形態に係るサーバ１０１においては、ＰＰＭマーカセグメントの有無を判定し、ＰＰＭマーカセグメントが存在する場合は、パケットヘッダとパケットデータを取りだして画像データ（符号データ）を通常の形式に再構成する。より具体的には、ＰＰＭマーカセグメントに格納されているパケットヘッダと符号データ部分に格納されているパケットデータを対の形式、すなわち通常のパケットの形式に変換する。
【０１１３】
このような処理を実行することにより、オリジナルデータにはＰＰＭマーカセグメントが存在する画像データについて、ＰＰＭマーカをサポートしていないクライアント１０２もデコードが可能な符号データとしてデコードが行うことができる。この時、クライアント１０２側では特別な処理をすることなく、通常の処理を行うだけでよい。
【０１１４】
上記の説明では、ＰＰＭマーカセグメントから該当するパケットのパケットヘッダを取り出す処理をパケットヘッダが必要になる度に取り出す構成について説明したが、これに限られない。例えば、初めの１回のＰＰＭマーカセグメントのスキャンで、必要となるパケットヘッダをすべて取り出すように構成してもよい。
【０１１５】
尚、クライアント１０２からメインヘッダを要求された場合、本実施形態に係るサーバ１０１は、要求された符号データ（画像データ）のメインヘッダからＰＰＭマーカセグメントを削除し、当該ＰＰＭマーカセグメントが削除されたメインヘッダを返送する。このように処理することで、仮にＰＰＭマーカセグメントのサイズが数百〜数千バイト以上であっても、通常のバイト数でメインヘッダを返送することができる。このため、返送データのバイト数や通信時間が小さくなり、クライアント１０２上の受信バッファも小さくてよい。
【０１１６】
このＰＰＭマーカセグメントを省いてメインヘッダを返送する処理は、単にメインヘッダ内のＰＰＭマーカセグメントをスキップして返送用のデータを作成するだけである。このため、この処理に係る負荷は非常に小さい。
【０１１７】
尚、上記の構成においては、サーバ１０１は、クライアント１０２の能力に関わらず常に画像データ（符号データ）を通常の形式に再構成するように動作していたが、これに限られない。例えば、クライアント１０２がＰＰＭマーカセグメントに対応していない場合にのみ再構成するようにしてもよい。
【０１１８】
このような処理を実現するためには、例えば、次のように構成する。即ち、ＰＰＭマーカセグメントに対応していないクライアント１０２は画像のリクエスト情報とともに、ＰＰＭマーカセグメントに対応していない旨の情報をサーバ１０１へ送付する。サーバ１０１は、リクエストを受信したときに、リクエスト情報とともにＰＰＭマーカセグメントに対応していない旨の情報を受信したか否かを判定する。受信していない場合は、ＰＰＭマーカセグメントが含まれたまま画像データを送出する。受信した場合は、図１１乃至１５のフローチャートに従って上述の動作を実行する。
【０１１９】
このように構成することでＰＰＭマーカセグメントへの対応・未対応に関わらずクライアント１０２のデコード能力に合わせて適切な画像データを送出することができる。
【０１２０】
なお、同様に継のように構成してもよいことは明らかである。即ち、ＰＰＭマーカセグメントに対応しているクライアント１０２が画像のリクエスト情報とともに、対応している旨の情報をサーバ１０１へ送付するように構成する。そして、サーバ１０１はリクエスト情報とともにＰＰＭマーカセグメントに対応している旨の情報が送付されたか否かに基づいて画像データの再構成をするか否かを判定するように構成してもよい。
【０１２１】
＜＜第２実施形態＞＞
第１実施形態では、ＰＰＭマーカセグメントが存在する画像データを、ＰＰＭマーカセグメントに対応していないクライアントもデコード可能なように変換し、送出するサーバ１０１の構成について述べたが、本発明に係る実施の形態はこれに限られない。本実施形態では、タイルパートヘッダ内にＰＰＴマーカセグメントの形式でパケットヘッダが格納された画像データについて、ＰＰＴマーカセグメントに対応していないクライアントもデコード可能なように変換・送出するサーバ１０１の構成について説明する。尚、画像データのタイルパートヘッダ内にＰＰＴマーカセグメントの形式でパケットヘッダが格納されている場合、メインヘッダ内にはＰＰＭマーカセグメントは格納されておらず、タイルパートヘッダにのみＰＰＴマーカセグメントが挿入される。
【０１２２】
このような、ＰＰＴマーカセグメントの形式でパケットヘッダが格納された画像データについて適宜変換を行うサーバ１０１の処理について、以下説明する。以下、特に断らない限り、本実施形態に係るハードウェア及び機能構成は第１実施形態に係る構成と同様であり、相違する点についてのみ言及する。また、本実施形態に係るサーバ１０１が実行する全体処理は第１実施形態と同様であり、図１１のフローチャートに基づいて実行される。
【０１２３】
図１６は本実施形態に係るサーバ１０１が実行する、レスポンスデータ作成処理の流れを示したフローチャートである。図１６中において第１実施形態で説明した図１２中の各ステップと同じ処理をするものに関しては、同一の番号を付しその説明を省略する。
【０１２４】
図１６のフローチャートと、第１実施形態の図１２との相違点は、ステップＳ１６００とステップＳ１６０１を実行することと、ステップＳ１２０４におけるパケットヘッダ取り出し処理である。
【０１２５】
本実施形態では、ステップＳ１２０２において、ＰＰＭマーカセグメントが存在しないと判断された場合（ステップＳ１２０２でＮＯ）は、ステップＳ１６０１へ進む。
【０１２６】
ステップＳ１６０１ではＰＰＴが存在するか否かを判定し、存在する場合（ステップＳ１６０１でＹＥＳ）はステップＳ１６００へ進み、存在しない場合（ステップＳ１６０１でＮＯ）はステップＳ１２０８へ進む。
【０１２７】
ステップＳ１６００においては後述するタイルパートヘッダ解析の処理を実行する。ステップＳ１２０８やその他の部分の処理は第１実施形態と同様であるため、説明は省略する。
【０１２８】
次に、ステップＳ１６００のタイルパートヘッダ解析の詳細な処理フローを図１７を参照して説明する。図１７は、タイルパートヘッダ解析の処理の流れを示したフローチャートである。
【０１２９】
本実施形態に係るサーバ１０１は、要求された画像データの全てのタイルに対して、画像データ中の先頭のタイルから順に、ステップＳ１７００乃至ステップＳ１７０６の処理を実行する。従って、初めて図１７のタイルパートヘッダ解析の処理を実行する場合は、１つ目のタイルパートヘッダが処理対象のタイルとなる。尚、１つ目のタイルパートヘッダは、メインヘッダの直後にある。よって図１６で説明したフローの中のメインヘッダ解析に続いて符号データをリード（ＲＥＡＤ）することで１つ目のタイルパートへヘッダをリード（ＲＥＡＤ）することができる。
【０１３０】
まず、ステップＳ１７００では処理対象のタイルの参照位置、即ち、参照ポインタが指す位置におけるマーカコードを取得する。
【０１３１】
次に、ステップＳ１７０１において、ステップＳ１７００で取得したマーカコードがＳＯＤマーカコードであるか否かを判定する。ＳＯＤマーカコードの場合（ステップＳ１７０１でＹＥＳ）はステップＳ１７０５へ進み、ＳＯＤマーカコードではない場合（ステップＳ１７０１でＮＯ）はステップＳ１７０２へ進む。
【０１３２】
前述のように、ＳＯＤマーカコードはこのタイルパートヘッダ部分の終了を意味する。このためステップＳ１７０５では、次のタイルパートヘッダに移動するための処理を行う。即ち、タイルパートヘッダ内に格納されているタイルパートのバイト数から参照位置の移動量を計算し、次のタイルパートヘッダの先頭に参照ポインタを移動する。
【０１３３】
次に、ステップＳ１７０６では、ステップＳ１７０５で参照ポインタを移動した後に全てのタイルについて処理が終了したか否かを判定する。この判定は、例えば、参照ポインタがファイルの終端を指しているか否かを判定することによって行うことができる。処理が終了している場合（ステップＳ１７０６でＹＥＳ）はタイルパートヘッダ解析の処理を終了し、図１６のステップＳ１２０７へ進む。終了していない場合（ステップＳ１７０６でＮＯ）は、ステップＳ１７００に戻り処理を継続する。
【０１３４】
一方、ステップＳ１７０２においては、ステップＳ１７００で取得したマーカコードがＰＰＴマーカコードであるか否かを判定する。ここでＰＰＴマーカコードではない場合（ステップＳ１７０２でＮＯ）は、ステップＳ１７０３に移動し、次のマーカコードの先頭に移動するためのスキップ処理をする。即ち、参照ポインタを次のマーカコードの先頭に移動する。
【０１３５】
一方、ステップＳ１７０２でＰＰＴマーカコードの場合（ステップＳ１７０２でＹＥＳ）は、ステップＳ１７０４に進む。
【０１３６】
ステップＳ１７０４では、ＰＰＴマーカセグメントの処理を行なう。即ち、Lpptフィールド、Zpptフィールド、Ippt(i)フィールドを取得する。この処理により全てのタイルパートをスキャンしてＰＰＴマーカセグメントを処理することが可能となる。そしてステップＳ１７００へ戻る。
【０１３７】
次に、図１６のステップＳ１２０４において実行するパケットヘッダ取り出し処理、即ち、ＰＰＴマーカセグメントからパケットヘッダを取り出す処理について、図１８を参照して説明する。図１８はパケットヘッダ取り出し処理の流れを示したフローチャートである。
【０１３８】
前述のように、ＰＰＴマーカセグメントは各タイル毎の情報であるため、メインヘッダ内のＰＰＭマーカセグメントとはフォーマットが異なっている。しかしパケットヘッダ取り出しの基本的な処理は、ＰＰＭマーカセグメント解析内でのタイル番号についての制御が無いことを除いて、図１４の処理と類似している。
【０１３９】
まず、ステップＳ１８００では、ステップＳ１７０４で解析処理したＰＰＴマーカセグメントから、このマーカセグメントのバイト数であるLpptの値を取得する。
【０１４０】
次に、ステップＳ１８０１ではＰＰＴマーカセグメントの識別番号Zpptを取得する。
【０１４１】
以下、ステップＳ１８０２乃至Ｓ１８０４、Ｓ１４０７の処理を、全てのパケットについて実行する。即ち、パケットヘッダの総数をＰとすると、ｉ＝１，２，・・・，ＰのそれぞれステップＳ１８０２乃至Ｓ１８０４、Ｓ１４０７の処理を行う。以下、ｉ番目のパケットヘッダについて処理を行うものとして説明を進める。
【０１４２】
次に、ステップＳ１８０２において、Ippt(i)フィールドに圧縮されて格納されたパケットヘッダのデータについて解凍処理を行なう。この解凍結果であるパケットデータのバイト数は、後の処理で使用するため、メモリ（ＲＯＭ２０４、ＲＡＭ２０５、ハードディスク２０６等）上など、後から参照できる場所に格納しておく。
【０１４３】
次に、ステップＳ１８０３において、参照しているパケットが取り出すパケット、即ち、図１６のステップＳ１２０３で特定されたパケットか否かを判定する。
【０１４４】
特定されたパケットである場合（ステップＳ１８０３でＹＥＳ）はステップＳ１４０７へ進む。ステップＳ１４０７では第１実施形態と同様に、当該パケットヘッダを取得し、パケットヘッダ取り出しの処理を終了し、図１６のステップＳ１２０５へ進む。一方、特定されたパケットではない場合（ステップＳ１８０３でＮＯ）は、ステップＳ１８０４へ進む。
【０１４５】
ステップＳ１８０４では、全てのパケットについて処理を行ったか否かを判定する。これは、例えば、ｉの値がＰに等しいか否かを判定することと等価である。全てのパケットについて処理していない場合、即ち、ｉの値がＰに等しくない場合（ステップＳ１８０４でＮＯ）は、ステップＳ１８０２に戻る。ステップＳ１８０２ではｉの値をインクリメントして同様の処理を行う。一方、全パケットを処理した場合、即ち、ｉの値がＰに等しい場合（ステップＳ１８０４でＹＥＳ）は、パケットヘッダ取り出しの処理を終了し、図１６のステップＳ１２０５へ進む。
【０１４６】
図１６のステップＳ１２０５において実行する、符号データからパケットデータを取り出す処理は第１実施形態と同じであるため、説明を割愛する。
【０１４７】
以上のように、本実施形態に係るサーバ１０１においては、ＰＰＴマーカセグメントの有無を判定し、ＰＰＴマーカセグメントが存在する場合は、パケットヘッダとパケットデータを取りだして画像データ（符号データ）を通常の形式に再構成する。より具体的には、ＰＰＴマーカセグメントに格納されているパケットヘッダと符号データ部分に格納されているパケットデータを対の形式、すなわち通常のパケットの形式に変換する。
【０１４８】
このような処理を実行することにより、オリジナルデータにはＰＰＴマーカセグメントが存在する画像データについて、ＰＰＴマーカをサポートしていないクライアント１０２もデコードが可能な符号データとしてデコードが行うことができる。この時、クライアント１０２側では特別な処理をすることなく、通常の処理を行うだけでよい。
【０１４９】
尚、クライアント１０２からタイルパートヘッダを要求された場合、本実施形態に係るサーバ１０１は、要求されたタイルのタイルパートヘッダからＰＰＴマーカセグメントを削除し、当該ＰＰＴマーカセグメントが削除されたメインヘッダを返送する。このように処理することで、仮にＰＰＴマーカセグメントのサイズが大きくても、通常のサイズでタイルパートヘッダを返送することができる。このため、返送データのバイト数や通信時間が小さくなり、クライアント１０２上の受信バッファも小さくてよい。
【０１５０】
このＰＰＴマーカセグメントを省いてタイルパートヘッダを返送する処理は、単にタイルパートヘッダ内のＰＰＴマーカセグメントをスキップして返送用のデータを作成するだけである。このため、この処理に係る負荷は非常に小さい。
【０１５１】
上記の説明では、ＰＰＴマーカセグメントから該当するパケットのパケットヘッダを取り出す処理をパケットヘッダが必要になる度に取り出す構成について説明したが、これに限られない。例えば、初めの１回のＰＰＴマーカセグメントのスキャンで、必要となるパケットヘッダをすべて取り出すように構成してもよい。
【０１５２】
以上説明したように、本発明に係る実施の形態として例示した第１、第２の実施形態の構成においては、クライアント１０２側のデコーダは、ＰＰＭマーカセグメントやＰＰＴマーカセグメントをサポートする必要がなく、最低限の機能を備えていればよい。このため、オリジナルデータがＰＰＭマーカセグメントやＰＰＴマーカセグメントを利用している場合であっても、クライアント１０２のデコードの能力に関わらずデータ配信を行うことができる。このため様々なクライアント１０２をサポートすることが可能となる。
【０１５３】
また、ＪＰＩＰなどの通信プロトコルを利用してクライアント１０２が符号データを断片的に取得する場合、クライアント１０２は符号データのメインヘッダなどのヘッダ情報を取得する必要がある。この時、上記の構成によれば、メインヘッダを取得する場合に、ＰＰＭマーカセグメントが返送されることがない。このため、返送データのバイト数や通信時間が小さくなり、クライアント１０２上の受信バッファも小さくてよい。
【０１５４】
また、上記の構成によれば、ＰＰＴマーカセグメントも返送されないため、各タイルのタイルパートヘッダを要求する場合においても、同様に返送されるデータのバイト数が少なくなり、ヘッダの送受信にかかるコストを削減することができる。
【０１５５】
ヘッダの送受信にかかるコストの低減による効果は、例えば、クライアント１０２においてサムネイル画像を表示するアプリケーションにおいて特に顕著となる。なぜなら、このサムネイル画像の表示には特に高速性が求められるからである。
【０１５６】
サムネイル画像を表示するアプリケーションを実行する場合、クライアント１０２はサーバ１０１にに対し、初めに画像サイズが小さい画像データ（サムネイル画像データ）を要求する。この時、クライアント１０２は、画像データ部分の符号データを要求する前に、まずメインヘッダを含むヘッダ情報を要求し、受信したヘッダ情報を解析して、画像データ部分の符号データの要求を行なう。しかし、画像データ（符号データ）にＰＰＭ／ＰＰＴマーカセグメントが挿入されている場合は、ヘッダ情報のサイズが大きくなっているため、ヘッダ情報の取得に時間がかかってしまい、結果としてユーザに対するレスポンス時間が遅くなってしまう。
【０１５７】
上記のように、第１，第２実施形態に係る構成によれば、ＰＰＭ／ＰＰＴマーカセグメントが挿入されている場合でもヘッダのサイズは変わらないため、通常の場合と同じレスポンス時間でデータの送受信と画像表示を行なうことが可能となる。
【０１５８】
尚、上記の構成においては、サーバ１０１は、クライアント１０２の能力に関わらず常に画像データ（符号データ）を通常の形式に再構成するように動作していたが、これに限られない。例えば、クライアント１０２がＰＰＴマーカセグメントに対応していない場合にのみ再構成するようにしてもよい。このような処理は第１実施形態の手法と同様の手法によって実現することができる。
【０１５９】
＜＜その他の実施形態＞＞
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１６０】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１６１】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【０１６２】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１６３】
プログラムを供給するための記録媒体としては、例えば、次のものが含まれる。即ち、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）等が含まれる。
【０１６４】
その他、プログラムの供給形態としては、次のようなものも考えられる。即ち、クライアント装置のブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明に係るコンピュータプログラム、或いは、圧縮され自動インストール機能を含むファイルをＨＤ等の記録媒体にダウンロードする形態も考えられる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１６５】
また、次のような供給形態も考えられる。即ち、まず、本発明に係るプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報の使用により暗号化されたプログラムを実行してコンピュータにインストールさせて本発明に係る構成を実現する。このような供給形態も可能である。
【０１６６】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他次のような実現形態も想定される。即ち、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１６７】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づいも前述した実施形態の機能が実現される。即ち、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１６８】
【図１】ネットワーク上に複数のコンピュータが接続されている様子を示した図である。
【図２】サーバのハードウェア構成を示したブロック図である。
【図３】ＪＰＥＧ２０００の符号化データの概略図である。
【図４】ＪＰＥＧ２０００符号データ全体をマーカセグメント単位で模式的に示した図である。
【図５】メインヘッダのマーカセグメントの構成を模式的に示した図である。
【図６】タイルパートヘッダのマーカセグメントの構成を模式的に示した図である。
【図７】ＰＰＭおよびＰＰＴのそれぞれのマーカセグメントの構造を示した模式図である。
【図８】画像データに係るリクエストとレスポンスの対応を示した概念図である。
【図９】precinct data-binの構造の概略図である。
【図１０】ＪＰＩＰ Response Dataの一例を示した図である。
【図１１】サーバが実行する全体処理のフローを示したフローチャートである。
【図１２】サーバが実行するレスポンスデータ作成処理の流れを示したフローチャートである。
【図１３】メインヘッダ解析処理の流れを示したフローチャートである。
【図１４】パケットヘッダの取り出し処理の流れを示したフローチャートである。
【図１５】パケットデータの取り出し処理の流れを示したフローチャートである。
【図１６】レスポンスデータ作成処理の流れを示したフローチャートである。
【図１７】タイルパートヘッダ解析の処理の流れを示したフローチャートである。
【図１８】パケットヘッダ取り出し処理の流れを示したフローチャートである。
【図１】
2007053444.tif 000003
【図２】
2007053444.tif 000004
【図３】
2007053444.tif 000005
【図４】
2007053444.tif 000006
【図５】
2007053444.tif 000007
【図６】
2007053444.tif 000008
【図７】
2007053444.tif 000009
【図８】
2007053444.tif 000010
【図９】
2007053444.tif 000011
【図１０】
2007053444.tif 000012
【図１１】
2007053444.tif 000013
【図１２】
2007053444.tif 000014
【図１３】
2007053444.tif 000015
【図１４】
2007053444.tif 000016
【図１５】
2007053444.tif 000017
【図１６】
2007053444.tif 000018
【図１７】
2007053444.tif 000019
【図１８】
2007053444.tif 000020