JP4086728B2 - 画像通信方法及びシステム - Google Patents
画像通信方法及びシステム Download PDFInfo
- Publication number
- JP4086728B2 JP4086728B2 JP2003189575A JP2003189575A JP4086728B2 JP 4086728 B2 JP4086728 B2 JP 4086728B2 JP 2003189575 A JP2003189575 A JP 2003189575A JP 2003189575 A JP2003189575 A JP 2003189575A JP 4086728 B2 JP4086728 B2 JP 4086728B2
- Authority
- JP
- Japan
- Prior art keywords
- tile
- client
- request
- server
- viewport
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Facsimiles In General (AREA)
- Compression Of Band Width Or Redundancy In Fax (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は画像通信の分野に関する。特に、本発明は、通信チャネルを介した、画像の一部分と、関連したメタデータの通信に関する。
【０００２】
【従来の技術】
JPEG2000は、JPEG2000ファイルの全体を復号化することなく、画像の様々な領域、解像度、及び、品質レベルを利用できるようにするため設計された。多様なプログレッション順序が定義され、低速の通信チャネルを介して伝送されたファイルは、例えば、低解像度から高解像度へ、若しくは、低品質から高品質へ、ある種の方法で「進行（プログレス）」する。また、ファイルが蓄積された順序とは異なる順序で画像の一部を選択し得る機能も興味がある。一般的に、伝送のために画像の領域と品質が対話的に選択される。
【０００３】
仮想メディア(Vmedia)アクセス・プロトコルが提案され、Vmediaを用いる双方向性JPEG2000ブラウザが開発されている（例えば、非特許文献１を参照。）。
【０００４】
JPEG2000画像を伝送するためのクライアント／サーバ環境も規定されている（例えば、非特許文献２を参照。）。非特許文献２には、スマート・クライアント、ダム・クライアント、スマート・サーバ、ダム・サーバが規定され、「パン・アンド・ズーム」セッションでのJPEG2000バイト使用法の例が与えられ、インターネット・イメージング・プロトコル(IIP)、バージョン1.0.5、1997年10月6日に基づくプロトコルが記載されている。このプロトコルは、非特許文献３に記載されているアイデアの一部を拡張しているが、しかし、非特許文献４に記載されているような転送用のHTTPに基づいている。
【０００５】
JPEG2000画像はHTTPを使用して送信される（例えば、非特許文献５を参照。）。しかし、ヘッダ情報を含む別々のインデックス・ファイルが送信され、望ましい画像構成要素を得るためHTTPバイトレンジ要求（リクエスト）が使用される。このプロトコルは、要求のパイプライン化が可能であるが、割り込みはできない。インデックス・ファイルを取得するために余分なラウンド・トリップ時間を必要とする。それらの例は、非常に非効率的である。なぜならば、複数のバイトレンジが境界値を含む「コンテント−タイプ：マルチパート／バイトレンジ」によって送信されるからである。あるケースでは、４８バイトのデータに対して７０バイトのオーバーヘッドが存在する。
【０００６】
バイトjpボックス、j2kパケットのような値をもつHTTP「アクセプト−レンジ」が使用されている（例えば、非特許文献６を参照。）。このアプローチの主要な欠点は、補助的なレンジ・タイプをサポートするサーバを決定した後に、初期コネクションを終了し、新しいコネクションを開設しなければならないことである。
【０００７】
JPEG2000ファイル転送の基本要素としてプリーシンクト(precincts)及びコードブロックが使用されている（例えば、非特許文献７を参照。）。この文献では、バイナリ・コンテナを使用し、アクノリッジ及びセッション情報を指定し、基本リターンタイプとしてプリーシンクトのバイトレンジを使用するプロトコルが定義されている。これに対して、このプロトコルは、通信の基本要素として、セルフラベリング型タイルパーツを使用する。このようにして、クライアントとサーバの両方が有効なJPEG2000コードストリームの複製を入手する。
【０００８】
JPEG2000双方向プロトコル（JPIP)の提案の募集が発表されている（例えば、非特許文献８を参照。）。この文献には、ブラウザと共に使用され、効率の指標が求められるパンとズームのステップのシーケンスが記載されている。
【０００９】
この提案募集への回答として、完全なプロトコルと、JPEG2000ファイルの個別のコードブロック又はより大きい部分へのアクセスが規定されている（例えば、非特許文献９を参照。）。この提案には、プロトコル用のアプリケーション・プログラマーズ・インタフェース(API)も規定されている。
【００１０】
【非特許文献１】
J.Li, H.H.Sun著、“Virtual Media (Vmedia) Access Protocol and its Application in Interactive Image Browsing”、Proc. SPIE Conf. on Multimedia Computing and Networking、2001年1月22−23日、San Jose, CA、第4312巻、ｐ．９９−１１０
【非特許文献２】
M.Boliek, G.K.Wu, M.J.Gormish著、“JPEG2000 for Efficient Imaging in Client/Server Environment”、Proc. SPIE Conf. on App. of Digital Imaging、2001年7月31−8月3日、San Diego, CA、第4472巻、ｐ．２１２−２２３
【非特許文献３】
Boliek外、“JPEG 2000 for Efficient Imaging in Client/Server Environment”、Proc. SPIE Conf. on App. of Digital Imaging、2001年7月31日−８月3日、San Diego, CA、第4472巻、ｐｐ．２１２−２２３、
【非特許文献４】
R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, L.Masinter, P.Leach, T.Berners-Lee（編）、“Hypertext Transfer Protocol _ HTTP/1.1”、RFC2616、1999年6月
【非特許文献５】
Sachin Deshpande and Wenujn Zeng、“Scalable Streaming of JPEG2000 Images using Hypertext Transfer Protocol”、Proc. ACM Conf. on Multimedia、2001年10月2−4日、ｐ．３７２−３８１
【非特許文献６】
Wright, R.Clark, G.Colyer、“An implementation of JPIP based on HTTP”、ISO/IEC JTC 1/SC 29/WG 1 N2426、2002年2月14日、Elysium Ltd.、英国
【非特許文献７】
D.Taubman、“A Very Simple Proposal for JPIP”、ISO/IEC JTC 1/SC 29/WG 1 N2445、2002年3月13日、ニュー・サウズ・ウェールズ大学、オーストラリア
【非特許文献８】
R.Prandolini, S.Houchin, R.Clark、“Call for JPIP Technology Proposals”、ISO/IEC JTC 1/SC 29/WG 1 N2550、2002年3月21日
【非特許文献９】
Canon、“Proposal for JPIP Tier2 protocol”、WG1N2608、2002年6月28日
【００１１】
【発明が解決しようとする課題】
本発明は、コードストリームの一部分を通信メカニズムを用いて転送する方法及び装置を提供する。
【００１２】
【課題を解決するための手段】
一実施例によれば、本発明の方法は、ネットワークを介して要求を送信し、ネットワークから要求への応答（レスポンス）の一部のようなリターンタイプとしてJPEG2000に準拠したコードストリームのタイルパーツを受信する。
【００１３】
【発明の実施の形態】
本発明は、以下の詳細な説明と、本発明の様々な形態についての添付図面とからより十分に理解されるであろう。しかし、以下の説明及び添付図面は、本発明を特定の実施例に限定するために用いられるべきではなく、本発明の解説と理解だけのために用いられる。
【００１４】
JPEG2000画像（或いは、その他の圧縮画像）の一部分をネットワークを介して通信する方法及び装置を説明する。HTTPに基づき、画像及びオブジェクトのアクセスを可能にする要求及び応答の通信用シンタックスを説明する。ファイルフォーマット・オブジェクトは、ボックスを指定することによりアクセスされ、コードストリーム要素は、タイルパーツ、即ち、コードストリームの本来の要素で返される。要求シンタックスを解釈し、応答を定義するプロトコルも説明される。画像通信の試みを分割するアーキテクチャが提示される。
【００１５】
〔概要〕
図１は、画像アクセスを実現するトランスポート・プロトコルの説明図である。図１では、クライアントは、サーバ（例えば、アパッチ(Apache)サーバ、専用画像サーバなど）へ初期要求１０６を出す。サーバは、画像１０２を獲得するため伸長することができる少なくとも一つのJPEG2000コードストリームを含むJPEG2000ファイルを格納している。システムは、リターンチャネル１０４を介して、JPEG2000コードストリーム１０１の一部分（例えば、タイルパーツ）をクライアントへ配信する。このクライアントは、直前に受信したタイル１０３を正当なJPEG2000コードストリームとして使用し、画像のある部分を形成するためこのコードストリームを復号化することができる。クライアント側の画像は、例えば、空間領域が縮小され、品質が低下し、コンポーネントの個数が削減し、或いは、解像度が低下するなどのいく通りかの方法で、サーバ上の画像よりも小さくなる場合がある。配信は、ネットワーク（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、ワールド・ワイド・ウェブ（ＷＷＷ）など）のような通信設備を介して行われる。一実施例において、システムは、遠隔地からJPEG2000ファイルへアクセスするため、ある種のパラメータ及び拡張と共にHTTP/1.1を使用する。一実施例では、これを実現するため、HTTP/1.1とJPEG2000ファイルフォーマット及びコードストリームの両方の既存の機能が以下に詳述するように使用される。別の実施例では、システムは、JPEG2000ファイルへアクセスするため、例えば、TCP/IP、UDP、SONETのような他のプロトコルを利用する。
【００１６】
一実施例では、クライアントとサーバの間の様々な区分のためのサポートが存在する。クライアント側では、画像オブジェクトが使用され、起点サーバ側では（即ち、クライアントと起点サーバの間に中間サーバが存在し得る）、バイトレンジが使用される。一連のステージは、画像オブジェクトからバイトレンジへ進むため使用される。あるステージから次のステージへの移行は、ネットワーク経由で、HTTPコネクションによって、若しくは、ローカルに関数呼び出しを用いて行われる。クライアントとサーバの双方のためのプロトコル及び多重レベルＡＰＩは定義される。
【００１７】
非常に多種多様なクライアントは、ここでの教示を利用する。一実施例において、表示装置の外部にメモリを具備しないクライアントは、画像オブジェクトが供給される。他の実施例では、システムの一つ以上のクライアントは、典型的なサーバよりもJPEG2000について詳しく理解し、望ましいコードストリームの部分を指定する。
【００１８】
或いは、HTTPに基づいていないプロトコルを使用してもよい。しかし、HTTPに基づいていないプロトコルは、ファイアウォール通過、プロキシ及びキャッシング技術（例えば、ワールド・ワイド・ウェブ(WWW)で利用可能な技術）、セキュリティ、認証、並びに、文書変更時間判定技術のうちの一つ以上の機能を獲得する手法を提供する必要がある。
【００１９】
以下に説明するトランスポート技術は、任意のJPEG2000ファイル若しくはコードストリームで動作するが、タイルに分割されたこれらのコードストリームは、より効率的にトランスポートされる。一実施例において、JPEG2000ファイルは、プロトコルを使用する前にトランスポートのため準備される。したがって、ここで説明するプロトコルは、作成されるすべての種類のJPEG2000ファイルに対し最適化する必要はない。これにより、要求されるシンタックス要素の個数と、クライアント及びサーバ側で要求される処理は著しく減少する。
【００２０】
〔トランスポート・アーキテクチャ〕
図２は、トランスポート・プロトコル・ソフトウェア構造の一実施例の説明図である。クライアントとサーバの間の通信は、図２に示されるように４ステージを通過するものとして考えられる。一実施例において、これらの４ステージは、伸長器又はデコンプレッサ（ステージ１）と、ビューポート−画像マッパー（ステージ２）と、画像オブジェクト・ラッパー（ステージ３）と、画像オブジェクト要求−バイトレンジ・コンバータ（ステージ４）と、を含む。
【００２１】
図２を参照すると、クライアントは、ウェブ・ブラウザのようなアプリケーション２００を含み、サーバは、ファイルシステム若しくはオンザフライ画像発生器２０５を含む。一実施例において（例えば、図３を参照）、JPEG200ファイルを取り扱うすべてのJPEG2000機能は、サーバ上に存在し、即ち、第１ステージ２０１と、第２ステージ２０２と、第３ステージ２０３と、第４ステージ２０４とは、すべてファイルシステム２０５と同じシステム上に存在する。クライアント・アプリケーション２０１は、認識しているフォーマット（例えば、JPEGフォーマット）で完全な画像ファイルを送信する。これは、従来のクライアントに対して有効である。なぜならば、サーバは、クライアント・アプリケーション２０１が使用可能な画像を返すことが可能であるからである（JPEG若しくはPNGを返す）。或いは、これは、クライアント・アプリケーション２０１のメモリ若しくは計算能力が非常に制限されているとき、従来のクライアントに対して有効である。
【００２２】
図２に示された各ステージにおいて、要求タイプが一方のティアー（層）から別のティアーへ変換されるか、応答タイプが一方のティアーから別のティアーへ変換される。ここで、各ティアーは通信のタイプである。かくして、クライアント端の要求及び応答は、画像オブジェクトであると考えられる。一実施例において、画像オブジェクトは、画面の領域、又は、一枚の紙であり、そこに、これらの領域を埋める画像と圧縮されていないカラー変換ビットを配置することが望ましい。ファイルシステム側では、通信は、バイトレンジの形で行われる。一実施例では、バイトレンジ通信は、Ｃ言語プログラムが使用するfseek()呼び出し及びfread()呼び出しのシーケンスにより構成される。別の実施例では、バイトレンジ通信は、不必要なデータが捨てられたfread()呼び出しだけにより構成される。尚、本発明の教示はＣプログラミングには限定されず、その他のプログラミング言語若しくはシステム（並びに、関連した呼び出し）も使用される。例えば、ワシントン州レッドウッドのMicrosoft Computerは、異なる呼び出しの組を使用する製品をもっている。別の方式でバイトレンジ通信を実行するため、カリフォルニア州マウンテンビューのSun MicrosystemsのJava（登録商標）を使用することも可能である。また、ファイルは、メモリに取り込み、メモリアクセスを使用してもよい。
【００２３】
一実施例において、クライアントとサーバの間の区分は、図２に点線で示されている５箇所のいずれの箇所でも行うことができる。一実施例において、クライアントは、サーバとの通信が圧縮形式で行えるように第１ステージの処理を含む。クライアント（例えば、ウェブ・ブラウザ）は、ライブラリを用いてJPEG2000伸長を実行する。一実施例において、クライアントとサーバが特定の点線で区分されているとき、その点線を超える通信はHTTPを用いて行われる。このような場合、一実施例では、クライアント若しくはサーバが点線の両側を含んでいるならば、通信は関数呼び出しによる。
【００２４】
より詳細に説明すると、図２において、T1はバイトレンジ・アクセスを表し、T2はJPEG2000画像オブジェクト・アクセスを表し、T3はビューポート／完全画像アクセスを表す。クライアントとサーバの間の区分が第２ステージと第３ステージの間にあるとき、クライアントは、JPEG2000画像オブジェクトのhttp要求を行う。プロトコルの区分が第４ステージとファイルシステム２０５の間で行われるとき、クライアントは、すべてのJPEG2000の知識をもっている。
【００２５】
図３は、クライアントとサーバの間の区分がクライアント・アプリケーション２００と伸長器（第１ステージ）との間で行われる第３ティアー通信の説明図である。このコンフィギュレーションには多数の潜在的な用途が存在する。例えば、これは、キャッシュを具備せず、DCTベースのJPEGデコーダだけを具備しているクライアントに使用できる。この区分は、ローカル・サーバに接続されたアプリケーション用のAPI、又は、既存のブラウザへの下位互換性が要求される状況用のAPIにも使用される。
【００２６】
図４は、クライアントとサーバの間の区分が第１ステージと第２ステージの間で行われる第３ティアー要求及び第２ティアー応答の説明図である。このコンフィギュレーションの潜在的な用途には、簡単な要求及び効率的なトランスポートと、パンとズームのクライアントと、JPEG2000がプラグインされたブラウザ若しくは始めからJPEG2000をサポートするブラウザと、が含まれる。
【００２７】
図５は、クライアント２０１とサーバ２０２の間の区分が第２ステージと第３ステージの間で行われる第２ティアー要求及び第２ティアー応答の説明図である。このようなシステムは、クライアントがサーバよりもユーザのニーズを知っている場合に潜在的な用途がある。
【００２８】
図６は、クライアントとサーバの間の区分が第４ステージとファイルシステム２０５の間で行われる第１ティアー要求と第１ティアー応答の説明図である。これは、サーバがJPIPを認識しない場合に使用できる。
【００２９】
図７は、プロキシ・サーバが使用される状況の説明図である。図７を参照するに、第１ステージと第２ステージの間、並びに、第４ステージとファイルシステム２０５の間に区分が存在する。より詳しく説明すると、プロキシ・サーバ７０３は、第２ステージから第４ステージまでを担当する。一実施例において、ファイルシステム２０５は、Apacheサーバである。本実施例では、従来型のサーバ（例えば、バイトレンジ要求をサポートするApacheサーバなど）が使用され、JPEG2000クライアントのパン／ズームは、これまでに良く知られた形式でサポートされ、中間プロキシ・サーバが使用される。同図には、１台のプロキシ・サーバしか示されていないが、クライアントとサーバの間には、1段以上のステージを取り扱う２台以上のサーバを設けてもよい。或いは、プロキシ・サーバ７０３によって扱われるステージは、ステージ２からステージ４までよりも多くても少なくても構わない。
【００３０】
このアーキテクチャの場合、クライアントとサーバの相互作用は１回に限られない。例えば、クライアント・アプリケーションは、完全画像オブジェクトだけと通信するコードを含む。画像を表示するため、クライアント・アプリケーションは、ローカル・サーバと通信する。このローカル・サーバは、高帯域幅接続によって接続してもよい。これに対して、サーバは、第３ティアー要求を使用して低帯域幅接続を介して別のサーバと通信し、第２ティアー応答を受信する。この２番目のサーバは、画像の「発生元」サーバでもよく、或いは、高帯域通信を介して、バイトレンジ要求だけを認識する「ダム」サーバと通信してもよい。これらの各サーバは、キャッシュを保持することができる。
【００３１】
クライアント若しくはサーバ内の構成要素は、図示されるようなステージに分割することが可能であるが、必ずしもこのように分割しなくてもよい。サーバは、例えば、第２ステージから第４ステージまでの多数のステージを一括して取り扱う単一のコード本体部を収容してもよい。これにより、メインヘッダのようなある種の画像情報を様々なステージにおいて重複することなく１回だけ記憶することが可能になる。
【００３２】
〔第１ステージ：伸長器（デコンプレッサー）〕
一実施例において、伸長器ステージは、第２ティアー応答のシーケンス及び現在の「ビューポート」を画像データに変換する。ビューポートは、クライアントが着目している全画像のうちの一部分である。ビューポートは、屡々、コンポーネントの部分集合、低解像度、或いは、小さい空間領域である。本質的に、伸長器ステージは、受信データに対して「普通」のJPEG2000伸長器を動かし、クライアントが希望する領域を復号化する。一実施例において、伸長器は、完全（フル）解像度の全画像を生成するためデコーダを動かし、着目している領域までクロッピングし、着目している解像度まで拡大縮小すことによって実現される。一実施例では、望ましい解像度、領域、コンポーネント、及び、品質に必要なファイルの部分だけが復号化される。これにより、計算資源とメモリが節約される。代替的な実施例では、システムは、既に望ましいコンポーネント数及び望ましい解像度で画像全体を復号化している。
【００３３】
一実施例において、伸長器は、Kakadu式JPEG2000でデコーダを使用する。kdu_expandプログラムは、低解像度の復号化と、着目している領域の復号化と、コンポーネント数の削減とを可能にさせる。ウィンドウ問い合わせとデコーダのコマンドラインとの間には、ディレクション関係が存在する。
【００３４】
一実施例では、伸長器は、実際にkdu_expandプログラムをスタートさせるのではなく、等価的な機能が動的リンクライブラリ（DLL)に集められる。一実施例では、伸長器は、受信JPEG2000コードストリームと、画面に表示される復号化画像のための外部ファイルを使用する。これにより、クライアントが終了させられたとき、簡単にキャッシングが行える。一実施例では、復号化画像用の外部ファイルを使用するのではなく、画像をメモリに収容するため、JPEG2000ライブラリが呼び出される。これにより、応答速度を速めることが可能である。
【００３５】
その他のJPEG2000ライブラリをKakaduの代わりに使用してもよい。例えば、要求された領域を最近接のタイル境界へ拡張し、全タイルを復号化するライブラリを使用してもよい。クライアントは、タイル境界と交差することなくパンニングする際に、このライブラリを使用して、画像の表示速度を速めることが可能である。このライブラリを用いて復号化された画像は、ユーザに要求されたビューだけを見せるためにクロッピングされるが、ビューポートを僅かに変更することにより、既に復号化された画像の簡単な再クロッピングと表示が行われる。同様に、ユーザの領域要求が新しいタイルからの素材に含まれるとき、これらのタイルだけを復号化し、それらをメモリ内の再構成画像に追加することが可能である。この場合、完全なクライアントのビュー上でJPEG2000デコーダを動かすことは、新しい符号化データが受信されたときに、表示される画像の品質を向上させる場合に限り必要である。
【００３６】
〔第２ステージ：J2Kマッパーへのビューポート〕
このビューポート−JPEG2000マッパーのステージは、ビューポート要求をタイルパーツに変換するため、JPEG2000ファイルに関する情報を使用する。一実施例において、このステージは、未だヘッダ情報を取得していない場合には、そのヘッダ情報を要求する。一実施例では、このステージは画像ヘッダ情報のコピーを保持するので、未来のビューポートは、JPEG2000タイルパーツに直ぐに変換することが可能である。このステージは、既に第１ステージへ転送された画像オブジェクトの要求の繰り返しを避けるため、第１ステージへ転送された応答のリストを保持する。
【００３７】
タイルパーツによる通信のため、ビューポイントのタイルパーツの組へのマッピングが行われる。マッパーは、画像の望ましい領域を、JPEG 2000 Part 1 standard (ITU-T Rec. |800 ISO/IEC 15444-1:2002-JPEG 2000 Imaging Coding Standard)に規定されている「基準グリッド単位(reference grid units)」へ変換する。マッパーは、どのタイルパーツが着目している領域と交差しているかを判定するため、SIZマーカー・セグメントのXTsiz、YTsiz、XTOsiz、YTOsiz、XOsiz、及び、YOsiz部分を使用する。第３ティアー要求シンタックスから獲得された解像度、品質及び領域は、必要なタイルパーツを決定するため使用される。一実施例において、マッパーは、タイルパーツの場所を指定するSIZマーカーによって指定された場合に、（問い合わせ文字列によって指定されるような）着目している領域と交差するタイルパーツだけに注目する。
【００３８】
より詳細に説明すると、タイルパーツを用いた通信のため、ビューポイントがタイルパーツの組（集合）へマッピングされる。画像の部分（解像度、空間領域、品質及びコンポーネント）は、クライアント要求に、明示的に、若しくは、デフォルト値を用いて与えられる。マッパーは、画像の望ましい領域を、JPEG 2000 Part 1 standard (ITU-T Rec. |800 ISO/IEC 15444-1:2002-JPEG 2000 Imaging Coding Standard)に規定されている基準グリッド単位へ変換する。各タイルパーツの基準グリッド単位は、JPEG2000コードストリーム内のSIZマーカー・セグメントのXTsizパラメータ、YTsizパラメータ、XTOsizパラメータ、及び、YTOsizパラメータによって決定される。要求された領域と交差するタイルからのタイルパーツだけが送信される。タイルの中のどのタイルパーツを送信すべきであるかは、要求された解像度及び品質と、符号化データのタイルパーツへの編成の仕方と、に依存する。簡単な一実施例では、低解像度から高解像度までの解像度毎に一つのタイルパーツが使用される。この場合、配信されるタイルパーツの個数は、要求された解像度だけに依存する。
【００３９】
図９は、ビューポート問い合わせパラメータと、SIZマーカー・セグメント・パラメータとの間の対応関係の説明図である。図９を参照するに、XTOsiz、YTOsiz、XOsiz、XTsiz、YTsiz、Xsiz、及び、Ysizはすべて、SIZマーカー・セグメントから得られ、xo、yo、ｗ及びｈは、ビューポート要求パラメータである。二つのパラメータ集合の間の対応関係は次のようになる。Xsiz−XOsizが、問い合わせパラメータ空間内の水平方向で１．０に対応する基準グリッドサンプルの個数を表し、ｗ及びxoは、（Xsiz−XOsiz）で乗算することによって基準グリッド単位へ変換される。同様に、垂直方向に関して、ｈ及びyoは、Ysiz−YOsizを乗算することによって基準グリッド単位へ変換される。
【００４０】
一実施例において、各タイルパーツに関する情報は構造に記憶される。この構造は、第２ステージ用のメモリでもよい。この構造は２ビットの構造であり、一方のビットは、タイルパーツが現在要求に対するクライアントへ送信されるべきであるかどうかを指定し、他方のビットは、タイルパーツが送信され終えたかどうかを指定する。このように、タイルパーツ毎に２ビットが存在する。タイルパーツがキャッシュに存在する場合、２番目のビットがターンオンされ、タイルパーツは送信しなくてもよい旨が示される。タイルパーツがキャッシュに存在しない場合、１番目のビットによって示されるような必要に応じて、タイルパーツがクライアントへ送信され、再送信を防止するため２番目のビットがターンオンされる。或いは、この構造は、送信してもよいかどうかを示す１ビットだけを使用するのではなく、各タイルパーツの優先順位を表す情報を記憶するために拡張できる。
【００４１】
コードストリームから、SOTマーカーは、タイル索引の細部と、各タイルパーツに必要なバイト数と、を与える。一実施例では、コードストリームから、送信されるべきタイルパーツに対応した適切なバイトがクライアント側へ送信される。ビューポートが変化し、対応した関連するタイルが変化した場合、先に送信されていないタイルだけが表示画像を更新するために送信される。
【００４２】
〔第３ステージ：画像オブジェクト・ラッパー〕
第３ステージは、バイトレンジ応答を取得し、画像オブジェクトを作成する。一実施例において、画像オブジェクト・ラッパーは、画像オブジェクト要求のシーケンスを一時記憶する。その結果として、第４ステージからの応答、例えば、
HTTP/1.1 200 OK
[other header line]
Content-Range:200-500/23382
CRLF
Data
のような応答は、画像オブジェクト表現の応答に変換される。完全タイルパーツだけが返される場合、このステージは、HTTP応答から"Content-Range"行を削除するだけである。一実施例では、このステージは、異なるヘッダでデータを包む（ラップする）。
【００４３】
一実施例において、第３ステージ及び第４ステージは完全に統合される。この結合されたステージは、望ましいデータを取得し、返却されたデータをHTTP応答に包みこみ、第２ステージへ供給するため、fseek()呼び出しとfread()呼び出しを実行するであろう。
【００４４】
一実施例において、トランスポート・プロトコルは、タイルパーツ及びボックスとは異なり、セルフラベリングされないオブジェクトをサポートするように拡張される。この場合、画像オブジェクト・ラッパーは、返却されたデータを識別子で包み込む。一実施例では、このラッピングは、次の形式：
Packet:=0&layer=0&component=2&position=5&tile=7
のHTTPヘッダでもよい。この新しいヘッダは、符号化データよりも先行するメッセージ本体内のバイトのシーケンスでもよい。
【００４５】
〔第４ステージ：J2K−バイトレンジ・コンバータ〕
J2Kからバイトレンジへのコンバータ（第４ステージ）は、圧縮画像オブジェクト要求をバイトレンジ要求に変換する役割を担う。一実施例では、このために、メインヘッダ、様々なコードストリーム・ボックスの場所、及び、タイルパーツを獲得するため、幾つかのバイトレンジ要求を作成することが必要である。殆どの場合、このコンバータは、多重アクセスを防止するため、情報を一時記憶する。コンバータは、たとえ、JPEG2000ファイル内でのタイルパーツのバイトレンジを参照する要求の場所を決定するために多重読み出しが必要であるとしても、要求された画像オブジェクトだけを返す。
【００４６】
一実施例では、ヘッダを送信する前に、サーバは、JPEG2000コードストリームのヘッダに達するまで、JPEG2000ファイルの構文を解析する。このとき、サーバは、コードストリーム・ヘッダ、或いは、構文解析されたファイルを、コンバータへ送信する。このようにして、コンバータは、0x6A703263によって示されるコードストリーム・ボックス・ヘッダの開始よりも前のすべてのデータを無視する。コードストリーム内のすべてのタイルパーツは、SOTマーカー・セグメントから始まる。SOTマーカー・セグメントは、タイルパーツの長さを含む。コンバータは、タイルパーツの長さを得るため、SOTマーカーを読み、タイルパーツの長さ、及び、タイルパーツの場所をJPEG2000ファイルに保存し、コンバータは、次のSOTマーカーへ進む。したがって、ビューポイント−J2Kマッパーがタイルパーツの組を要求する旨を示した後、コンバータは、作成されたメモリ構造から、タイルパーツの対応したファイル場所を獲得する。即ち、コンバータは、ファイルを構文解析すると共に、タイルパーツをメモリに記憶し、タイルパーツをクライアントへ送信する。コードストリームのメインヘッダ内のTLMマーカーは、タイルパーツの場所及び長さを格納する。したがって、一実施例では、TLMマーカーは、JPEG2000ファイル内のタイルパーツの位置を決定するため使用される。
【００４７】
換言すると、バイトレンジ要求は、JPEG2000コードストリームのメインヘッダ内のTLMマーカー・セグメントを使用して、或いは、各TLTマーカーを読み出すこと（及び、次のTLTマーカー・セグメントへ進むこと）によって作成される。いずれの場合も、第４ステージは、タイル索引と、タイルパーツの個数と、ファイルの先頭からのオフセットと、タイルパーツの長さ、の４個のエントリーを含むリストを構築することが可能である。タイル索引、タイルパーツの個数、及び、長さは、すべて、TLTマーカー・セグメントの一部である。第４ステージが各TLTマーカー・セグメントを読み出すとき、第４ステージはファイルの先頭からのオフセットを保存することが可能である。次に、特定のタイル索引及び部分番号に対する要求が生成されるとき、第４ステージは、生成されたリスト内のタイルパーツを見つける。オフセット及び長さのリスト内のエントリーは、バイトレンジ要求のため使用される。
【００４８】
構文解析中に、コンバータは、JPEG2000コードストリームの前にすべてのバイトを読む。スピードアップは、「ボックス」ヘッダを読み出すことにより、即ち、「ボックス」タイプ及び「ボックス」長さを読み出し、関連していないボックスを飛ばすことにより、達成される。
【００４９】
一実施例において、コンバータは、ファイルシステムに接続され、ファイルを読むためにシステムコールを行う。コンバータは、JPIPをサポートしていないがバイトレンジ要求をサポートしているサーバ（例えば、Apacheサーバ）に接続される。或いは、このステージは、JPEG2000画像を蓄積する役割を担うデータベースに接続してもよい。
【００５０】
〔第３ティアーはJPEGファイル又はPNGファイルを返す〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、第３ティアー応答は、ビューポートを埋めるために適したPNGファイル若しくはJPEGファイルである。
【００５１】
〔第２ティアーはボックス及びタイルパーツを返す〕
第２ティアーは、更なるラッピングを行うことなく、ボックス及びタイルパーツを返すので、要求に対する応答は、有効なJPEG2000ファイル若しくはコードストリームを形成するために連結され得る。これは、典型的に、第１ステージを実行するクライアント若しくはコンピュータシステム、又は、装置によって行われる。クライアントは、PIP若しくはトランスポートを理解できないJPEG2000デコーダを利用することが可能である。ブラウザ用のローカル・ディスク・キャッシュは、他のディレクトリへコピーすることができる有効な画像で埋められ、有効な画像は他のディレクトリへコピーされない場合には、JPEG2000ファイルとして操作される。
【００５２】
一実施例において、トランスポート・プロトコルは、信頼性の高い順序付けされたチャネルを前提とするHTTPを使用する。これにより、クライアント若しくはステージは、ある程度のエラー検出を行わなくても済むようになる。
【００５３】
〔トランスポート・プロトコル定義〕
〔要求シンタックス〕
要求は、第３ティアー「全体の画像オブジェクト」、第２ティアー「符号化されたデータオブジェクトレベル」、及び、第１ティアー「バイトレンジ」の３種類のティアーで行われ得る。しかし、一実施例では、すべての要求は、HTTPシンタックスを使用し、一部のオーバーラップが生ずる。例えば、画像以外のデータ、例えば、JPEG2000におけるボックスに対する要求は、画像及びオブジェクトレベルで同一である。更に、クライアントは、画像レベルで殆どのデータへアクセスすることを望むかもしれないが、メタデータの一部分、例えば、画像に関連付けられた音（サウンド）は、（特に、他のチャネルの使用と干渉するかもしれない程度に大きいならば）バイトレンジでアクセスされる。例えば、約２０００バイト以上のメタデータが必要ではないときには、要求を作成するオーバーヘッドは補われる。ある種のデータにバイトレンジでアクセスすると、サーバが理解できないメタデータを含むJPEG2000ファイルは、ボックス全体よりも小さい単位でアクセスできるようになる。
【００５４】
〔第３ティアー要求〕
一実施例において、第３ティアーの要求は、
GET filnename.jp2?res=2 HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
のように表される。
【００５５】
これらはすべて、標準HTTP要求のコンポーネントである。"GET"はメソッドである。"filename.jp2"は、ファイル名、若しくは、より一般的には完全なURLであり、サーバのルート・ディレクトリからの完全なパスでもよい。"?"の後のすべての項目は、CGI相互作用に典型的な「名前＝値」のペアである。この問い合わせ文字列は、スペースを含まない（それらは、%20として組み込むことが可能である。）。HTTP rfc、例えば、Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee （編）、"Hypertext Transfer Protocol _ HTTP/1.1"、RFC 2616、1999年6月を参照せよ。この文献は、以下の説明では、HTTP標準と呼ぶ。最終的なHTTP/1.1は、プロトコルを規定する。プロトコルの一部は、バージョン１．１よりも前のバージョンのHTTPと連動する。HTTP要求は、２個のキャリッジリターンとラインフィードのペアによって終了する。"CRLF"は、キャリッジリターンとラインフィードを表現するが、本例の場合、その文字は、行内の唯一の文字ではない限り、各行の終わりで省略されている。
【００５６】
一実施例では、HTTP GET要求の問い合わせ文字列にパラメータを組み込む代わりに、パラメータは、HTTP POST要求の本体部に組み込まれる。これは、後述のオプションが長い場合に有効である。
【００５７】
一実施例において、POST要求の一例は、
POST /cgi-bin/j2k_server.cgi HTTP/1.1
Host: truew.crc.ricoh.com
Content-type: Application/x-www-form-urlencoded
Content-length: 26
CRLF
filename=picture.jp2&res=2
である。
【００５８】
第３ティアーのビューポートを記述するために利用可能なオプションは次の表１に掲載されている。要求に影響を与える補助パラメータは表２に掲載されている。これらのオプションは、getメソッドとpostメソッドに対して同一である。
【００５９】
【表１】
尚、これらのパラメータのすべてが必要というわけではない。一部のパラメータは、デフォルト値を取り、例えば、デフォルトですべてのコンポーネントは、画像にマッチする領域に関して送信される。一実施例では、それらをすべて省略してもよく、デフォルト値が使用される。
【００６０】
〔パラメータの説明〕
パラメータｘｏ、ｙｏ、ｗ及びｈは、画像の領域を指定する。０は左上の端を表し、１は右下を表す。幅及び高さは画像の画分を指定し、１は全高若しくは全幅を表す。かくして、一実施例において、ｘｏ＝０＆ｙｏ＝０＆ｗ＝１＆ｈ＝１は、画像の全体（デフォルト）を指定する。これに対して、画像の中央セクションは、ｘｏ＝０．２５＆ｙｏ＝０．２５＆ｗ＝０．５＆ｈ＝０．５によって与えられる。左端は、基準グリッド上のＸＯｓｉｚの位置に存在し、上端は、ＹＯｓｉｚの位置に存在するものとする。図９と、パート１の付録ＡにおけるSIZマーカーの定義[ITU-T Rec. T.800|IS 15444-1:2000、Information Technology _ JPEG 2000 image coding system: Core coding system]を参照のこと。
【００６１】
パラメータｒｅｓは、画像を縮小するための解像度の数である。ｒｅｓ＝１は、画像を水平方向並びに垂直方向に約２倍の倍率で縮小する。この縮小は、JPEG 2000の様式で行われるので、画像７のグリッド点の幅は、SIZマーカーのオフセットの値に依存して、４サンプル若しくは３サンプルの幅に縮小される。
【００６２】
パラメータｍａｘｗ及びｍａｘｈは、クライアントが受信することに関心をもっているサンプルの最大個数を指定する。これは、「ｒｅｓ＝」パラメータを使用して縮小の量を指定することの代わりである。例えば、原画像のサイズを知らないクライアントは、１２８サンプルを含む最大高若しくは最大幅の画像を要求する。サーバは解像度を低下させる。サーバは、要求が満たされるまで、或いは、ＬＬサブバンドだけが返されるまで、解像度を低下させる。かくして、ウェーブレット変換の零レベルが圧縮の際に利用されているならば、１２８×１２８の最大画像の要求は５１２×５１２の画像を返し続ける可能性がある（しかし、起こりそうにない。）。
【００６３】
コンポーネント・パラメータは、どのコンポーネントを組み込むかを指定する文字列である。一実施例において、コンポーネントは、零から番号が付けられる。レンジを使用してもよい。かくして、コンポーネント＝０−２、５は、例えば、コンポーネント０、１、２及び５を返す。
【００６４】
品質パラメータは、サーバが送信すべきデータの量を決定するために役立つ。サーバは、返却するレイヤの数として、品質値を使用することを選んでもよい。一実施例において、品質に関する０ｘＦＦＦＦの要求は、領域内のタイルパーツについてサーバが保有するすべてのデータを要求することである。
【００６５】
表２には、応答の他の面を制御するため、問い合わせと共に使用される補助的なパラメータの組が掲載されている。第３ティアー値は、"png"若しくはDCTベースのJPEGフォーマットの完全な画像として応答を要求する。
【００６６】
【表２】
ボックスパラメータは、クライアントが着目しているボックスのリストを指定するための一方法である。ボックスは、JPEG2000パート１、パート２、パート３及びパート６において様々のJPEG2000ファイルフォーマットに対して規定されている。これらは、コードストリームの一番上のレベルにある。ボックスの内部のボックスは、スーパーボックス及びサブボックスをリストにすることによって要求される。複数のボックスの場合、サーバは、そのタイプのすべてのボックスを返却するか、若しくは、そのタイプの最初のボックスだけを返却するかを選択する。ボックスのレンジは、括弧を用いて指定される。［０−］という形式のレンジは、サーバがこのタイプのすべてのボックスを返却することを保証する。
【００６７】
最大ボックスサイズパラメータは、指定されたバイト数に満たないすべてのボックスを返却させることができる。これにより、通信が非常に遅くならない限り、存在するであろうすべてのボックスを獲得できるようになる。
【００６８】
尚、許容可能なセットの範囲外の文字を使用するタイプのボックスは、URL符号化される。URL符号化に関する更なる情報は、RFC 2396のHTTP rfc［HTTP標準］を参照せよ。
【００６９】
ボックスもノットボックスもリストに掲載されていない場合、サーバは、返却すべきボックスを決定する。一実施例では、サーバは、すべてのボックスを返却すること、コードストリームより前のすべてのボックスを返却すること、画像をサーバに蓄積するときに画像の作成者が指定したすべてのボックスを返却すること、或いは、全くボックスを返却しないこと、を決定する。一実施例では、サーバのコンフィギュレーション・ファイルは、これらのオプションの任意の部分若しくは全部を許可する。コードストリームの一部分は、Notboxes=jp2cではない限り返却される。
【００７０】
要求パラメータ、値のペア、及び、それらの意味の例は以下の通りである。
boxes=jp2h
get the JP2 Heaser box.
boxes=jp2h/ihdr
get only the Image Header box within the JP2 Header box
boxes=uuid[5-7]
get the 5th 6th, and 7th UUID boxes (if they exists).
maxboxsize=4096
return boxes 4096 bytes or smaller
【００７１】
優先順位パラメータは、ある要求の他の要求に対する重要度を示す。新しい優先順位が前の優先順位と一致する場合、サーバは、新しい要求に関しても有効であるならば、旧い要求に関するバイトを送信し続ける。新優先順位と旧優先順位の差が１以上であるならば、サーバは、次の機会に旧い要求を停止し、新しい要求を開始する。優先順位が"Inf"である場合、サーバは新しい要求のために旧い要求を止める。サーバは、現在の要求に適用されるデータを送信し終えたとき、以前に中断された要求に関するデータを後で送信するように選択してもよい。
【００７２】
〔第３ティアーのための補助的なHTTPヘッダライン〕
次の表３には、クライアント側で利用可能なデータを指定するため使用可能な二つのヘッダラインが示されている。
【００７３】
【表３】
Ｔ３キャッシュ(T3cache)は、クライアントが現在のセッション又は前のセッションで既に受信した領域を指定できるようにする。サーバは、要求に対して送信されたタイルパーツが再度送信されることがないようにタイルパーツを計算するため、このＴ３キャッシュを使用する。サーバはこのパラメータを無視してもよい。例えば、認識する能力に欠けるサーバは、このパラメータを無視するであろう。
例：
T3chache: xo=0.0&yo=0.0&w=0.25&h=0.25&res=2
T3chache: maxw=128&maxh=128
【００７４】
尚、キャッシュの内容は、先行のビューポート要求への応答である。一実施例では、一つのＴ３キャッシュライン当たりに一つの要求が存在する。この要求は、問い合わせ文字列の一部としては送信されないが、HTTPヘッダラインとして送信される。Ｔ３キャッシュが使用されているならば、メインヘッダは受信されている、と考えられる。クライアントは、キャッシュされたすべての要求のリストを作成しなければならないわけではない。実際上、クライアントは、受信された各要求をリストに掲載し、このラインをアクノリッジとして使用する。サーバは、前の要求をタイルパーツのリストに翻訳し、これらのタイルを送信済みとしてマークすることができる。したがって、これらのタイルパーツは、現在の要求が翻訳されるときに、再送信されない。
【００７５】
Ｔ２キャッシュは、クライアントが受信されたタイルパーツのリストを作成できるようにする。シンタックスは次のように定義される。これは、タイルパーツを要求する典型的な方法に対応する。ここでも一実施例では、このラインは、問い合わせ文字列の一部分ではなく、HTTPヘッダラインである。一例は、次の通りである。
T2cache: 4.0, 4.1, 5.0-6.2
【００７６】
〔第２ティアー要求〕
第２ティアーは、第３ティアーと同じようにボックスに対する要求をサポートする。タイルパーツは、HTTPレンジヘッダを用いて明示的に要求され得る。タイルパーツに対する第２ティアー要求の効率的な用法は、符号化データのタイルパーツへのある分割に同意したクライアントとサーバに依存する。タイルは、あらゆる解像度若しくはあらゆるレイヤで、或いは、その他の方法でタイルパーツに分割しなければならない。一つの有効な分割法を次に詳しく説明する。第２ティアーの要求の例は、次の通りである。
GET file.jp2 HTTP/1.1
Host: truew.crc.ricoh.com
Range: tiles-parts=4.0, 5.0, 8.0-9.2
CRLF
【００７７】
ピリオドの前の値はタイル番号であり、ピリオドの後の値はタイルパーツ番号である。JPEG2000パート１の付録ＡからのIsot及びTPsotを参照のこと（文献：ITU-T Rec. T.800|IS 15444-1:2000, Information Technology _ JPEG 2000 image coding system: Core coding system)。尚、一実施例では、タイル番号及びタイルパーツ番号は、どちらも０から番号を付けられる。タイルパーツのレンジは、スタートタイルからストップタイルまでのすべてのタイルと、スタートからストップまでのこれらのタイルに関するすべての部分と、を含む。例えば、8.0-9.2は、8.0、8.1、8.2、9.0、9.1、9.2と等価的である。
【００７８】
一実施例では、タイルパーツは２個のパラメータ（タイルに対するIsotと部分に対するTPsot）をもつので、１次元のレンジのため設計された"Ranges"の代わりに、新しいHTTPヘッダラインを使用する方がよい。例えば、"Tile-part:"ヘッダは、
Tile-parts: 8.0, .8.1, 10.0-12.2
のように使用される。
【００７９】
〔第１ティアー要求シンタックス〕
第１ティアーの要求は、HTTP（HTTP標準）に規定されているように厳格なバイトレンジ要求である。例えば、
GET file .jp2 HTTP/1.1
Host: truew.crc.richo.com
Range: bytes=200-500, 1000-1500
CRLF
である。
【００８０】
上述の通り、要求は、位置２００で始まる３００バイトと、位置１０００で始める５００バイトである。このような要求は、典型的に、クライアントが所定のバイトレンジで期待すべきものを知っている場合に限り有効である。しかし、これらの要求は、例えば、画像に関連付けられたオーディオ・ストリームの全体を転送することなく、オーディオ・ストリームの一部分にアクセスするために有効である。
【００８１】
一実施例では、別々のラインでキャッシュ情報のリストを作成するのではなく、クライアントは、キャッシュ情報をHTTP問い合わせ文字列自体に組み入れることが可能である。例えば、ユーザが、以下の問い合わせ文字列：
GET filename.jp2?xo=0.0&Yo=0.0&w=0.25&h=0.25&res=2&maxx=750&maxy=750 HTTP/1.1
を入力する場合を考える。
【００８２】
クライアントは、第２ステージ（ビューポート・ツー・JPEG2000マッパー）で説明したようにサーバ側のファイルを解析したのと同様に、キャッシュ内のファイルを解析する。クライアントは、既にキャッシュ内に保有するタイルパーツのリストを形成し、サーバへ送信する前に問い合わせ文字列に付加する。したがって、サーバは、問い合わせ文字列：
GET filename.jp2xo=0.0&yo=0.0&w=0.25&h=0.25&res=2&maxx=750&maxy=750&T2cache=4.0, 5.0, 8.0, 8.1, 8.2, 8.3, 9.0, 9.1, 9.2, 9.3 HTTP/1.1
を取得する。
【００８３】
勿論、様々なシンタックスがビューポートを指定するため使用され得る。JPEG200パート９標準の最新版は、以下のシンタックスに類似したシンタックスを使用する。殆どのパラメータは、当業者が要求シンタックスの様々なタイプの間で翻訳できる。
【００８４】
【表４】
〔パラメータの説明〕
パラメータOffset=Px,Py及びSize=Sx,Syは、左端のPxサンプルから始まり、右側へサンプルPx個分だけ拡がり、一番上のPyサンプルから始まり、下方へサンプルPy個分だけ拡がる画像の領域を指定する。左端は基準グリッドのXOsizの位置にあり、一番上はYOsizの位置にある場合を考える。SIZマーカー・セグメントの定義については、JPEG2000パート１の付録Ａを参照のこと。これらのサンプルは、フレームサイズパラメータによって指定された解像度である。
【００８５】
パラメータFrame-size=Rx,Ryは、クライアントが画像を見ることを望む解像度である。Rx及びRyは、０から画像の寸法まで変化する。しかし、JPEG2000のドメインでは、復号化された画像は、有限のレベルの解像度でしか見ることができない。そのため、クライアントの要求に応じて、サーバは、R'x≧Rx並びにR'y≧Ryとなるような解像度R'x及びR'yを送信する。R'x及びR'yがRx及びRyとは異なる場合、サーバはこの情報をヘッダで送信する必要がある。JPEG2000パート１に記載されているように、解像度低下画像は、正確な位置に応じて、左端（左縁）と右端（右縁）で丸められる。例えば、画像７グリッド点幅は、SIZマーカーのオフセットの値に依存して、４サンプル分若しくは３サンプル分だけ幅が縮小する。
【００８６】
R'x及びR'yに依存して、要求された領域の左上隅のオフセット、幅、及び、高さは、
P'x=Px*R'x/Rx, P'y=Py*R'y/Ry, S'x=Sx*R'x/Rx, 及び S'y=Sy*R'y/Ry
のように変化し、ここで、P'x及びP'yは実際のオフセットを表し、S'x及びS'yはクライアント側のキャンバスに表示された画像の実際の幅及び高さを表す。
【００８７】
コンポーネントパラメータは、どのコンポーネントを取り入れるべきであるかを指定する整数のリストである。コンポーネントは０から順番に番号付けされている。レンジを使用してもよい。かくして、Components=0-2,5は、コンポーネント０、１、２及び５を返す。
【００８８】
L=qualityパラメータは、サーバが送信すべきデータの量を決定する際に役立つ。サーバは、返却すべきレイヤの数として品質値を使用することを選択することもある。いずれの場合でも、品質に対する0xFFFFの要求は、サーバが領域内のタイルパーツに関して保有するすべてのデータを要求する。
【００８９】
パラメータBh及びBsはオプションパラメータであり、サーバは、このパラメータを用いて、実際に送信されるバイト数に関するハードリミット若しくはソフトリミットを設定することができる。低解像度のタイルパーツが最初に送信され、高解像度のタイルパーツは、このリミットに達するまで送信される。このフィールドが存在しない場合、サーバは、特定の解像度で要求された領域を表示するために必要なタイルパーツを送信することができる。
【００９０】
フラグADDが肯定(yes)にセットされている場合、新しい要求を前に要求されたウィンドウと連結することができる。デフォルトとして、このフラグは、無効にされ、新しいウィンドウが要求されると、クライアントは前のウィンドウを置き換える。
【００９１】
〔応答シンタックス〕
〔第３ティアー応答〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、画像オブジェクトは、ビューポートを埋めるために適したPNGファイル若しくはJPGファイルである。このタイプの応答は以下のような応答である。
HTTP/1.1 200 OK
Content-type: image/jpeg
Content-length: 20387
CRLF
JPEG Compressed Image Data
【００９２】
尚、以下の第２ティアー応答に関して説明されるようなチャンク形式転送コーディングを使用することが好ましいが、チャンク形式転送コーディングを使用しなければならない訳ではない。
【００９３】
〔第２ティアー応答〕
第２ティアー応答は、HTTPヘッダでラップされチャンク形式転送エンコーディングを使用して送信された、要求されたボックスと、（前に送信されていならば）コードストリーム・メインヘッダと、連結されている要求されたタイルパーツと、により構成される。第２ティアー応答は、非常に大きくなり、送信するために非常に長い時間を要する可能性があるので、送信の途中で中断できることが重要である。例えば、１K×１Kのタイルを含む画像は、１．５メガバイトの応答を生ずる（遅いリンクを用いる場合、これは、長い時間を要する）。チャンク形式転送エンコーディングが指定されない限り、HTTP要求は、"Content-Length:"ヘッダの本体部の全長を指定するか、又は、接続を終えることによりデータの終了を示すことが必要である。どちらも実現可能ではあるが、望ましくはない。なぜならば、現在の応答を停止し、新しい要求のために同じコネクション上で更なるデータを送信することが望ましいからである。チャンク形式の場合、各チャンクの長さが送信され、応答を終了するため、長さ零が送信される。このように、一旦チャンクが開始されると、チャンクを終了させる必要があるが、応答を終了する前にすべての応答を完了させる必要はない。
【００９４】
以下にチャンク形式応答の例を示す。
HTTP/1.1 206 Partial Content
Content−Range: 0−2000, 4000−10200/867370
Transfer−Encoding: chunked
Content−type: image/jpeg2000
CRLF
1000
[4096 (or 1000 HEX−DECIMAL) bytes of JPEG 2000 data]
1000
[4096 (or 1000 HEX−DECIMAL) bytes of JPEG 2000 data]
8
[8 bytes of JPEG 2000 data]
0
【００９５】
上記の例の最初のヘッダラインは、応答が完全なファイルではないことを示すため「部分コンテンツPartial Content」ヘッダを使用する。"Content-Range"ヘッダは、ファイルのどの部分が送信されるかを示すため使用される。転送エンコーディング"Transfer−Encoding:"ヘッダは、データがチャンク形式であることを示すため使用される。データのタイプが与えられる。なぜならば、応答は、"image/jpeg2000"というタイプが与えられた復号可能なJPEG2000ファイルであるからである。他のタイプを使用してもよい。
【００９６】
１番目よりも後の応答の場合、応答は、有効なJ2Kコードストリームを格納していない（メインヘッダが含まれないことは非常に稀である。）。この場合、別のタイプ、例えば、"image/jPiP"を用いてそのことを示すことが望ましい。
【００９７】
一実施例において、４０９６バイトの第１のチャンクを送信した後に新しい要求が受信され、サーバが伝送を終了させることに決定した場合、サーバは、現在のボックス、メインヘッダ、若しくは、タイルパーツを完了し、長さ０のチャンクを示す。次に、新しい応答が新しいHTTPヘッダを用いて開始される。
【００９８】
〔第１ティアー応答〕
一実施例では、第１ティアー応答は、HTTP［HTTP標準］に規定されているバイトレンジ応答と同じである。データを簡単に終端できるように、チャンク形式転送エンコーディングを使用することが望ましい。
【００９９】
〔要求／応答セマンティックス〕
要求を受信した後、サーバはチャンクを送信している間に更なる要求を受信しようとしている。
【０１００】
サーバは、新しい要求の優先順位が十分であるならば、現在の応答を正常に終了し、新しい要求に応答し始める。一実施例では、十分な優先順位は、"Inf"優先順位の要求によって示される。サーバは、現在のタイルパーツを終え、現在の要求に対してこれ以上チャンクが送信されないことを示すチャンクサイズ０を送信する。一実施例において、サーバは、HTTPフッターを付加し、次の応答を開始する。
【０１０１】
サーバが"Inf"以外の優先順位を受信した場合、サーバは、現在の要求の中で継続すべき要求の量を決定する。現在の要求が新しい要求に対する良好な回答であるならば、アクションは必要ではない。例えば、新しい要求は異なるビューであっても、依然として同じ部分のセットが必要である場合がある。新しい要求の優先順位が前の要求の優先順位よりも１だけ高い場合、旧い要求は、新しい要求のために現在のタイルパーツの終わりで一時中断させることが提案される。
【０１０２】
最終的には、一実施例では、サーバは、すべての要求に適合する簡単な応答を送信する。或いは、応答が複数の要求に回答することを示すために規定されたシンタックスが使用される。この場合、サーバは、現在の転送を停止することなく、かつ、新しいHTTPヘッダから開始することなく、新しい要求若しくは旧い要求に関連したタイルパーツを送信し続ける。一実施例では、この場合、サーバは、拡張され得る要求を開始するときに、"Content−Range:"ヘッダを使用しない。
【０１０３】
〔サーバデータ記憶フォーマット〕
一実施例において、トランスポート・プロトコルは、すべてのJPEG2000ファイルフォーマット及びコードストリームで機能する。しかし、このような方式での機能は、必ずしも効率的ではない。例えば、タイルが使用されない場合、領域の要求は、コードストリーム全体を返すことがある。
【０１０４】
トランスポート・プロトコルと共に使用する最も効率的な画像圧縮方法は、期待されるアクセスの性質に依存する。"Call for JPIP technology proposals"[JPIP Editors (Prandolini, Houchin, Clark), Call for JPIP technology proposals, ISO/IEC JTC1/SC29/WG1 N 2550, 21 March 2002]に規定されているような「パン及びズーム」動作のシーケンスの場合、N/16×N/16のタイルサイズを使用することは、N×N画素のサイズの矩形画像に対して優れている。
【０１０５】
使用されるコードストリームに対する一つのプログレッション順序は、解像度−レイヤ−コンポーネント−位置（RLCP)である。タイルは、あらゆる解像度及びあらゆるレイヤでタイルパーツに分割可能である。一実施例において、低解像度のすべてのタイルパーツは、より高解像度のタイルパーツよりも前にファイルに保存される。これにより、低解像度部分は、最小回数のディスクアクセスで入手できるようになる。一実施例において、十分な品質は、タイル境界アーティファクトを回避するため、最初のレイヤに記憶される。
【０１０６】
場合によっては、無損失で保存された画像の低解像度バージョンをブラウズできることが望ましい。RLCP順の場合、画像が無損失に蓄積されるとは、低解像度画像のために多数のビットが使用されることを意味する。これは、クライアントとサーバの間の低速コネクションによる画像のパンとズームのブラウジングを遅くする。この問題は、画像をサーバに特殊な方法で格納することによって解決される。レイヤ−解像度−コンポーネント−位置(LRCP)プログレッション順序は、コードストリームのために使用されるが、最初のレイヤは、主として解像度順にデータを格納するため使用される。最後のレイヤは、画像の損失のない表現を記憶するため使用される。各レイヤには固有のタイルパーツが割り当てられるので、サーバは、完全なタイルパーツを送信することによって、望ましい解像度をクライアントに供給することが可能である。例えば、３レベルの解像度レベルのある単一の２５６×２５６タイルは、以下のように編成される。
【０１０７】
タイルパーツ０は、（すべてのコンポーネント及び位置に対して総計で）１２８バイトの解像度０のデータを格納するレイヤ０を収容する。これにより、かなり高品質であるが、依然として損失の多い画像（ビューイング解像度で１画素当たり１ビットと等価的な画像）がクライアントへ供給される。
【０１０８】
タイルパーツ１は、解像度０と解像度１の３８４バイトのデータを格納するレイヤ１を収容する。解像度０と解像度１のデータのバイト数は、解像度１の表示解像度で画質（画像品質）を最大にするように選択される。
【０１０９】
タイルパーツ２は、解像度０と解像度１と解像度２の１５３６バイトのデータを格納するレイヤ２を収容する。殆どのバイトは、解像度２であり、他の解像度は解像度２の表示解像度で最適な画質を得るために十分である。
【０１１０】
タイルパーツ３は、解像度０、１、２及び３の６１４４バイトのデータを格納するレイヤ３を収容する。タイルパーツ０〜３は、最適化された１ｂｐｐ画像を完全な解像度で格納する。
【０１１１】
タイルパーツ４は、損失の無い画像を得るために必要なすべての解像度の残りのデータを格納するレイヤ４を収容する。おそらく、階調画像については２４０００バイト、カラー画像についてはそれ以上のバイト数が必要である。勿論、タイルパーツは、２．０ビット／画素の画像と、損失の無い画像を得るため、補助的なタイルパーツに分割してもよい。或いは、ある最大タイルパーツサイズを維持するため、タイルパーツに分割してもよい。
【０１１２】
〔トランスポート・プロトコル性能〕
〔ディスクアクセスと要求される係数の数〕
以下の表４は、画像要求に応答するサーバによってアクセスされるファイル内の個別の場所の数のリストである。表４には、タイル全体又はプリーシンクトが要求に応じて送信されるならば、送信されるべき係数の数も掲載されている。勿論、送信されるべきバイト数は、主として圧縮比に依存するが、タイル若しくはプリーシンクトのサイズとは無関係に等しい圧縮を考慮すると、それらの値は応答サイズに関連付けられる。
【０１１３】
表４は、幾つかの異なるビューポイントに対するデータを表し、前の要求に対するデータが送信されたときに、新しいビューポイントに要求される補助的なアクセス／係数だけを表す。
【０１１４】
表４の値に対し、圧縮のため使用されるコマンドは以下の通りである。
Tiling: kdu_compress -i lena.bmp -o out.jp2 -rate -, 0.25 Clayers=30 Creversible=yes Stiles={128, 128}
Corder=RLCP
タイルサイズ：128×128；256×256；512×512；1024×1024 アンタイルに対する結果が表に掲載されている。
Precincts: kdu_compress -i lena.bmp -o out.jp2 -rate -, 0.25 Clayers=30 Creversible=yes Cprecincts={128, 128} corder=RPCL
プリーシンクトサイズ32×32；64×64；128×128；256×256；512×５１２に対する結果は表に掲載され、同じサイズのプリーシンクトが各解像度で使用される。
【０１１５】
表４は、プリーシンクトとタイルパーツの比較であるとみなすべきではない。なぜならば、プリーシンクトは、各解像度で、タイルに要求されるよりも小さいサイズを使用できるからである。
【０１１６】
【表５】
【０１１７】
【表６】
〔セッション持続性〕
一実施例において、プロトコルは、幾つかのメカニズムによって時間的に分離された多重接続上であってもデータの再送信を回避する。これは、既にクライアントへ送信されたデータを示すために、クライアントに、httpヘッダのうちの一つ（例えば、T2cache）を使用させることによって達成される。セッション持続性を与える代替的なメカニズムは、現在の多数の商業ウェブサイトで行われているように、セッションＩＤを維持するため、クッキー(cookie)を使用することである。勿論、サーバは、セッションの記録を残さないこともあり、クライアントが全く保存していないと考えられるコードストリームの部分を送信するに過ぎない。
【０１１８】
〔エラー処理〕
エラー処理に関して、HTTPは、エラー条件に対する様々な応答メッセージを含む。これらのすべては、このプロトコルと共に使用するために利用できる。エラーが検出された場合、ステージ間で再送信を要求することができる。HTTPフッターは、送信データのチェックサムを送信するため使用可能であり、これにより、エラーを検出する。
【０１１９】
〔速度（レート）制御〕
速度制御に関して、トランスポート・レベル・プロトコルと、ソケットを実現するライブラリは、例えば、典型的に、クライアントが処理できる速度よりも速い速度でクライアントにデータが送信されていないことを保証する。殆どのソケットライブラリにおいて、"send"呼び出しは、大量のデータが送信される場合、データが送信されるまでエラーを阻止するか、又は、エラーを返す。チャンク形式で大量の応答を送信することは、単一の"send"が非常に大きくなることを阻止するはずである。一実施例において、最大バイトパラメータのようなパラメータは、バイト数を制限するため使用される。また、クライアント及び／又はサーバは、速度制御を行うことが許可される。これにより、遅いリンク上のバッファの充填が制御されるであろう。
【０１２０】
トランスポート・プロトコルは、クライアントが有効な最大画像を指定できるようにするmaxhパラメータ及びmaxwパラメータを与えない。クライアントは、JPEG若しくはPNGへの翻訳を要求する。
【０１２１】
〔同時アクセスのためのサポート〕
ここで説明しているトランスポート・プロトコルは、サーバ上の同じ画像への同時アクセスを制限しない。一実施例では、単独のクライアントが同じサーバ上の同じリソースへ多重接続を開設する場合、各接続は、その接続についての要求の順序で扱われる。クライアントが望むならば、クライアントは、受信したT3cache若しくはT2cacheヘッダを用いて、所与の接続に要求していないデータを指定することができる。さもなければ、サーバは、二つの接続が全く同一のクライアントに対してなされていることを知ることができない。
【０１２２】
代替的な実施例では、セッション鍵は、別々の要求をつなぐため、要求及び応答のすべてのレベルに対するHTTPへ付加してもよい。これにより、上記のプロトコルは、HTTP1.1のデフォルトの「生かしておく（キープアライブ）」機能を用いることなく動作できる。また、これにより、信頼性の低いネットワーク上でもより巧く利用できるようになる。セッション内の要求を順番に並べるために要求番号を付加することが有効である。かくして、TCP上でHTTPを用いる場合であっても、多重接続を作成し使用することが可能である。セッション鍵は、クッキーヘッダを用いて、或いは、要求パラメータとして組み込むことが可能である。
【０１２３】
〔JPIP要求バインディング〕
HTTPは、TCP/IP以外のチャネルによっても搬送することができる。したがって、このプロトコルを、TCP/IP以外のHTTPをサポートするチャネルで使用することが望まれるならば、新しい定義は不要である。一実施例では、未訂正のエラー若しくはパケット損を含むチャネルに対してプロトコル・バインディングを指定することが望ましい場合、チャンク形式転送エンコーディングを使用する応答の各チャンクは、固有のネットワークパケットになる。他のすべての要求及び応答は、ネットワークパケット内に適合する。一実施例において、これらは、コネクション優先チャネルのため送出される順番にパケット番号が与えられる。尚、HTTP以外のプロトコルを使用しても構わないことにも注意する必要がある。
【０１２４】
〔キャパビリティ交換とネゴシエーション〕
一実施例では、キャパビリティは、応答のヘッダだけを要求するHTTPメソッド"HEAD"を用いて要求され、クライアントは、"GET"要求を用いて受信した応答のタイプを決定することが可能である。一例は、
HEAD filename.jp2?res=2 HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
のように表される。
【０１２５】
一実施例において、サーバのキャパビリティは、HTTPメソッド"OPTIOINS"、例えば、
OPTIONS * HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
を用いて要求される。
【０１２６】
一実施例において、特定の画像上の動作のキャパビリティは、
OPTIONS filename.jp2 HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
を用いて決定される。
【０１２７】
HTTP 1.1 RFCは、キャパビリティを示すメカニズムを含む。ここで説明されている画像プロトコルの場合、サーバは、以下のラインを含むヘッダを返す。
Accept-Ranges: bytes, tile-parts
Accept: image/jpeg2000;q=0.9 image/gif;q=0.5 imag/jpigT2;q=0.95 image/ jpipT3;q=0.1
Allow: GET, HEAD, POST, OPTIONS, TRACEVary: accept, *
【０１２８】
HTTP 1.1 RFCは、ここで説明されている画像プロトコルの場合、以下のようなヘッダが役に立つ。
Accept-Ranges: bytes, tile-parts
【０１２９】
"Accept-Ranges: bytes"は、正当なHTTP/1.1コマンドである。一実施例において、サーバは、直接バイトレンジ要求に応答する能力を示すため、トランスポート・プロトコルでこれを使用する。このような場合、洗練されたクライアントは、コードストリーム又はファイルフォーマットの望ましい部分を正確に抽出する。
【０１３０】
"Accept-Ranges: tile-parts"の使用は、サーバがタイルパーツに対する直接要求に応答する能力を示すための一つの方法である。
Accept: image/jpeg2000;q=0.9 image/gif;q=0.5 image/jpipT2;q=0.95 image/jpipT3;q=0.1
尚、HTTPは、Acceptヘッダ内で能力を示すだけではなく、優先度を示す。画像をトランスコードする能力を備えたJPEG 2000画像サーバは、クライアントとサーバの両方が最高優先度でサポートするタイプのビューポート要求を返す。或いは、サーバは、より優先度の低いタイプを返すことに決定してもよい。なぜならば、その方がサーバに対する負荷が軽いからである（例えば、サーバは、サーバの負荷が高い場合には、伸長及び再圧縮を必要としないタイプを返すかもしれない。）。或いは、サーバは、最終的に、多数の要求によって帯域幅が低下するかもしれない。
Allow: GET, HEAD, POST, OPTIONS, TRACE
【０１３１】
このHTTPラインは、サーバが許可するコマンドを示す。これらのコマンドは、今まで使用されていたのと同じように画像サーバで使用される。
Vary: accept, *
【０１３２】
Varyヘッダは、応答が、クライアントが許容することを示すリターンタイプに依存することを示す。"*"は、応答がhttpヘッダ以外のものに依存するかもしれないことを示す。ここで説明しているプロトコルを使用するシステムにおけるサーバにおいて、返却される正確な内容は、前の要求に依存するかもしれない。例えば、サーバは、既にクライアントが保有していることを確信するタイルパーツを返さない。これは、HTTPプロキシを実現するために重要である。なぜならば、返却されたデータは、同じタイルパーツの組をもたないクライアントからの等価的な要求に対して優れたデータではない可能性があるからである。
【０１３３】
〔画像の一意識別〕
HTTPは、リソースを一意に識別するメカニズムを備えていることに注意する必要がある。"Etag"は応答を一意に識別する（HTTP 1.1 RFC 2616[HTTP標準]のセクション14.19を参照。）。
【０１３４】
JPEG 2000パートＩは、UUIDボックスを識別する（ITU-T Rec. T.800|IS15444-1:2000, Information Technology _ JPEG 2000 imaging coding system: Core coding systemのセクションI.7.2を参照。）。ここで説明されるプロトコル要求シンタックスは、ボックスの返却を可能にさせ、このボックスは画像の一意性を判定するために要求され得る。
【０１３５】
"Expires"のようなHTTPヘッダを用いることにより、クライアントは、キャッシュされたデータが有効ではなくなるときを知ることができる。HTTP標準のセクション14.21を参照。
【０１３６】
〔サーバへの画像アップローディング〕
完全な画像は、HTTPメソッドPOSTを使用してアップロードできる。この場合、シンタックスは、他のファイルアップロードと全く同じようにみえる。トランスポート・プロトコルは、全タイルパーツのアップローディングを可能にさせる。この場合、ヘッダは、Tier２シンタックスを使用してアップロードされているタイルパーツがどのタイルパーツであるかを示す。クライアントは、アップロードされたタイル毎にすべてのタイルパーツを与える。サーバは、アップロードされたタイルのすべてのタイルパーツを削除し、新しいタイルパーツを格納する。サーバは、元のファイルの順序とは異なる順序でタイルパーツを格納するように選択する。更に、TLMを更新しなければならない。サーバは、PPMマーカー・セグメントを使用して画像を更新することを拒絶するように選択してもよい。勿論、サーバは、画像又はタイルパーツを全くアップロードしないように選択してもよい。一部のサーバは、HTTPメソッドDELETEをサポートすることを選択する。このメソッドの場合、JPEG2000画像に対して特別なシンタックスは要求されない。
【０１３７】
〔その他の能力〕
１回の要求の後に画像を返す能力は有用である。最も顕著な例は、インライン形イメージを含むウェブページである。画像タグは、画像の返却を可能にさせる。ウェブページの作成者は、組み込まれる画像と、ページのレイアウトについての知識があり、URLを設定しているので、おそらく、サーバの能力についても知っているであろう。「キャパビリティ交換(exchange capabilities）」と画像獲得の必要性はない。
【０１３８】
一実施例において、ブラウザがJPEG 2000画像を理解できるようにするため、個々で説明しているプロトコルは、
<img src="http://truew.crc.ricoh.com/name.jp2?res=2" width="128" height="115">
のような呼び出しをサポートする。このコールは、低解像度部分を含むjp2ファイルを返す。一実施例において、ブラウザは、JPEG画像及びGIF画像のように、作成者が望む128×115のウィンドウに巧く収まるように画像を拡大縮小する。
【０１３９】
すべてのブラウザが画像を読み取れることを保証するため、画像タグは、画像がPNG（或いは、GIF若しくはJPEG）に変換されることを要求できる。
<img src="http://truew.crc.ricoh.com/name.jp2?res=2&tier3=PNG" width="128" height="115">
【０１４０】
サーバがJP2ファイルにアクセスし続けるとしても、配信する前に変換されるであろう。
【０１４１】
〔拡張／代案〕
〔タイルパーツ「オンザフライ」を書き換えるためにPOCマーカーを使用〕
一実施例では、ここで説明するプロトコルは、サーバに現れるようなタイルパーツだけに役立つ。異なる領域をバラバラの順序でアクセスしてもよいが、すべてのタイルパーツは順番にアクセスされる。そのため、クライアントがコンポーネント２にアクセスすることを望み、コンポーネント０及び１が最初にタイルパーツに格納されるならば、すべての典型的なプログレッション順の場合と同様に、要求されていないデータが送信される。
【０１４２】
しかし、代替実施例では、サーバは、クライアントによって要求された順序通りになるように、タイル内でタイルパーツを再配置することができる。一実施例では、サーバは、解像度、レイヤ、及び、タイルパーツに格納されたコンポーネントを指定するため、各タイルパーツに関してJPEG2000標準のPOCマーカーを使用する。これは、サーバ側でのバッファリングを要求する。キャッシングの方がより一層難しい。なぜならば、サーバは、コードストリームが並べ替えられた状況を把握しているからである。一実施例では、これは、要求コマンドを追跡することによって行われる。一実施例において、サーバは、要求及び応答を行うため、内部データ構造を使用する。一実施例では、サーバは、クライアントが要求した順序でファイルのコピーを書き込む。
【０１４３】
サーバが、各解像度について１個ずつのタイルパーツがRLCP順に並べられている３コンポーネントJPEG2000ファイルを格納している場合を考える。さらに、一つのタイルパーツに関して１個のレイヤと１個のプリーシンクトだけが存在すると仮定する。このとき、タイルパーツデータは、
SOT marker segment(Tile 0, Length of tile-part, Part 0, Number of Part 0)
SOD marker
Packet Header/Body of Resolution 0, Layer 0, Component 0, Position 0(R0L0C0P0)
Packet Header/Body of R0L0C1P0
Packet Header/Body for R0L0C2P0
のように見えるであろう。
【０１４４】
クライアントが最初のコンポーネント（番号０）だけを要求する場合、サーバは、コンポーネント１及び２からのデータを含むすべてのタイルパーツを送信する。これは、望んでいないコンポーネントに対するデータが大量である場合には、非効率的である。そこで、サーバは、最初のコンポーネントだけを収容するファイルには実際に現れないタイルパーツを作成し、クライアントへ送信する。メインヘッダは、ファイル内に2個以上のコンポーネントが存在することを示すので、サーバは、このタイルパーツが１個のコンポーネントしか含まないことを示す。サーバは、数通りの方法を用いて、状況の順番を変えるためにファイルを変更することができる。
【０１４５】
プログレッション順は、CPRLに変更してもよく、クライアントは、最初にコンポーネント０が現れることを予想する。これは、クライアントが最初にコンポーネント２ではなく、コンポーネント０を要求する場合に機能する。
【０１４６】
他のコンポーネントに対するパケットは、零データを保有するように変更できる。これは、他のコンポーネントに対するデータが後のパケットまで現れないようにレイヤ割り当てを変更することと等価的である。しかし、プレースホルダーとしての役割を果たすためには、スキップされたパケット毎に１バイトパケットヘッダを組み込むことが依然として必要である。更に、他のコンポーネントからのデータが要求されるとき、パケットヘッダは、正しいレイヤ情報を組み込むために書き込まれなければならない。
【０１４７】
一実施例において、POCマーカー・セグメントは、タイルパーツヘッダに収容される。タイルパーツは、
SOT marker segment(Tile 0, Length of tile-part, Part 0, Number of Part 0)
POC marker segment(Resolution start=0, Component start=0, layer end=1, resolution end=1, component end=1)
SOD marker
Packet Header/Body of Resolution 0, Layer 0, Component 0, Position 0(R0L0C0P0)
のように表される。
【０１４８】
このタイルパーツは、要求されたデータだけを格納する。更なる要求によって、新しいタイルパーツが生成され、新しいタイルパーツは、要求されたデータだけを格納する新しいPOCマーカーを含む。
【０１４９】
パケット自体は変更する必要がなく、パケットを送信する順序だけが変更される。
【０１５０】
いずれにしても、この技術の一つの重要な利点は、クライアントが、受信したコードストリームの部分を追跡するための補助的な構造を用いることなく、常に正当なJPEG2000ファイルを保有し続けることである。
【０１５１】
〔補助的な用途の場合：メモリもデコーダも無いクライアント〕
非常に簡単なクライアントは、クライアントの表示エリアよりも少ないメモリしか備えていないにもかかわらず、非常に大きい画像をブラウズすることを望む場合がある。圧縮画像データをキャッシュすることは期待できない。クライアントはJPEG2000デコーダを具備しない場合もある。しかし、このクライアントは、JPEG2000サーバと通信し、Tier3要求を作成し、Tier3応答を受信することが可能である。
【０１５２】
〔典型的なコンピュータシステム〕
図８は、上記の一つ以上の動作を実行する典型的なコンピュータシステムのブロック図である。図８によると、コンピュータシステム８００は、典型的なクライアント若しくはサーバを構成する。コンピュータシステム８００は、情報を通信する通信メカニズム若しくはバス８１１と、バス８１１に接続され情報を処理するプロセッサ８１２と、を含む。プロセッサ８１２は、例えば、Pentium（登録商標）、PowerPC（登録商標）、Alpha（登録商標）などのマイクロプロセッサを含むが、これらのマイクロプロセッサには限定されない。
【０１５３】
システム８００は、バス８１１に接続され、情報を記憶し、プロセッサ８１２によって実行される命令を記憶するランダム・アクセス・メモリ（ＲＡＭ）、若しくは、ダイナミック記憶装置８０４（メインメモリと呼ばれる）を更に含む。メインメモリ８０４は、プロセッサ８１２による命令の実行中に、一時的な変数、若しくは、他の中間情報を記憶するためにも使用される。
【０１５４】
コンピュータシステム８００は、バス８１１に接続され、プロセッサ８１２のための静的情報及び命令を記憶するリード・オンリー・メモリ（ＲＯＭ）及び／又はその他のスタティック記憶装置８０６と、磁気ディスク若しくは光ディスク及び対応したディスクトドライブを備えたデータ記憶装置８０７と、を更に含む。データ記憶装置８０７は、バス８１１に接続され、情報と命令を記憶する。
【０１５５】
コンピュータシステム８００は、バス８１１に接続され、情報をコンピュータのユーザへ提示する陰極線管（ＣＲＴ）若しくは液晶ディスプレイ（ＬＣＤ）のような表示装置８２１に接続される。英数字キー及びその他のキーを備えた英数字入力装置８２２もバス８１１に接続され、情報及びコマンド選択をプロセッサ８１２へ通知する。補助的なユーザ入力装置は、マウス、トラックボール、トラックパッド、スタイラス、或いは、カーソル方向キーのようなカーソル制御装置８２３であり、バス８１１に接続され、方向情報及びコマンド選択をプロセッサ８１２へ通知し、表示装置８２１上のカーソルの動きを制御する。
【０１５６】
バス８１１に接続され得るその他の装置には、命令、データ、若しくは、その他の情報を、紙、フィルム、若しくは、類似したタイプの媒体などのような媒体に印刷するため使用されるハードコピー装置８２４が含まれる。更に、スピーカー及び／又はマイクロホンのような音声記録及び再生装置がバス８１１に接続され、コンピュータシステム８００との間で音声インタフェースを実現する場合もある。バス８１１に接続できる他の装置には、電話機、又は、ハンドヘルド型の手のひらサイズの装置若しくはコンピュータやサーバと通信する有線／無線通信設備８２５が含まれる。
【０１５７】
バスに接続できる別の装置は、例えば、デジタル信号プロセッサ（ＤＳＰ）若しくは特殊な圧縮（及び／又は伸長）ハードウェアを構成するコ・プロセッサ８３５である。
【０１５８】
システム８００と関連したハードウェアの一部若しくは全部が本発明で使用される。しかし、他のコンピュータシステムのコンフィギュレーションでも、一部若しくは全部の装置を収容できることが明らかである。
【０１５９】
上述の説明では、種々の特定の細部が本発明の全体の理解が得られるように解説されている。当業者に明らかであるように、本発明は、これらの特定の細部を用いることなく実施できる。別の例では、構造及び装置は、本発明がわかり難くなることを避けるためブロック図の形式で示されている。
【０１６０】
以下の詳細な説明の一部は、コンピュータメモリ内のデータビットに関する演算のアルゴリズム及び記号表現の形で与えられている。これらのアルゴリズム記述及び表現は、データ処理技術の当業者が自分の業績の要旨を他の当業者にできるだけ効率的に伝達するため使用する手段である。本明細書において、並びに、一般的に、アルゴリズムは、希望の結果を生ずる首尾一貫したステップ（手順）の系列であると考えられる。ステップは、物理量の物理的な操作を必要とする。通常、必須的ではないが、これらの量は、記憶、転送、合成、比較及びその他の操作を加えることができる電気信号若しくは磁気信号の形式をとる。主として慣用されているという理由から、これらの信号は、ビット、値、エレメント、シンボル、文字、項、数などのように呼ばれる。
【０１６１】
しかし、これらのすべての用語、並びに、類似した用語は、適切な物理量と関連付けられるべきであり、これらの量に適用された便利なラベルに過ぎない。特に断らない限り、以下の説明から明らかであるように、説明全体を通じて、「処理」、「コンピューティング」、「計算」、「決定」、「表示」などのような用語を利用する議論は、コンピュータシステム、若しくは、類似した電子コンピューティング装置の動作及び処理について言及するものであり、コンピュータシステムは、コンピュータシステムのレジスタ及びメモリ内で物理（電子的）量として表現されたデータを操作し、コンピュータシステムのメモリ若しくはレジスタ、或いは、他のこのような情報記憶装置、伝送装置又は表示装置内で物理量として同じように表現された他のデータに変換する。
【０１６２】
本発明は、上記の演算を実行する装置にも関する。この装置は、要求された目的のため特別に構築されるか、或いは、コンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ状態にされるか、又は、再構築される汎用コンピュータを具備する。このようなコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に保持される。コンピュータ読み取り可能な記録媒体の例には、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスクなどの任意のタイプのディスクと、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード若しくは光カード、或いは、電子命令を記憶するために好適である任意のタイプの媒体が含まれるが、これらの例に限定されるものではない。各媒体はコンピュータシステムのバスに接続される。
【０１６３】
以下の説明におけるアルゴリズム及びディスプレイは、特定のコンピュータ若しくはその他の装置に本来的に関連付けられていない。多様な汎用システムが、上記の教示に従うプログラムと共に使用され、或いは、要求された方法の手順を実行するために、より特殊化された装置を構築する方が好都合であることが判明することもある。これらの多様なシステムのため要求される構造は、上記の説明から明らかになるであろう。更に、本発明は、特定のプログラミング言語に関しては説明されていない。上述の本発明の教示を実施するため、種々のプログラミング言語が使用される。
【０１６４】
機械読み取り可能な媒体は、機械（たとえば、コンピュータ）によって読み取り可能な形式で情報を記憶若しくは伝送する任意のメカニズムを含む。たとえば、機械読み取り可能な媒体は、読み出し専用メモリ（ＲＯＭ）と、ランダム・アクセス・メモリ（ＲＡＭ）と、磁気ディスク記憶媒体と、光記憶媒体と、フラッシュメモリ装置と、電気的、光学的、音響的若しくはその他の形式の伝搬信号（たとえば、搬送波、赤外線信号、デジタル信号など）と、を含む。
【０１６５】
以上の説明から分かるように、本発明の多数の代替例及び変形例は当業者にとって明白であり、例示的に説明され図示された特定の実施例は本発明を限定することを意図したものではないことが理解されるべきである。したがって、様々な実施例の細部に関する記述は、本発明に不可欠であると考えられる事項のみが記載されている請求項に係る発明の範囲を限定するものではない。
【０１６６】
【発明の効果】
本発明によれば、効率的な画像通信が実現される。
【図面の簡単な説明】
【図１】簡単な画像アクセスの説明図である。
【図２】典型的なソフトウェア構造の説明図である。
【図３】クライアントとサーバの区分の例の説明図である。
【図４】クライアントとサーバの区分の例の説明図である。
【図５】クライアントとサーバの区分の例の説明図である。
【図６】クライアントとサーバの区分の例の説明図である。
【図７】クライアントとサーバの区分の例の説明図である。
【図８】コンピュータシステムの一実施例の構成図である。
【図９】ビューポート質問パラメータとＳＩＺマーカー・セグメント・パラメータの間の対応関係の説明図である。
【符号の説明】
２００ アプリケーション
２０１ 第１ステージ
２０２ 第２ステージ
２０３ 第３ステージ
２０４ 第４ステージ
２０５ ファイルシステム、オンザフライ画像発生器又はバイトレンジサーバ
８０４ メインメモリ
８０６ スタティック・メモリ
８０７ 大容量メモリ
８１１ バス
８１２ プロセッサ
８２１ 表示装置
８２２ キーボード
８２３ カーソル制御装置
８２４ ハードコピー装置
８２５ 無線／電話インタフェース
８３５ コ・プロセッサ
【発明の属する技術分野】
本発明は画像通信の分野に関する。特に、本発明は、通信チャネルを介した、画像の一部分と、関連したメタデータの通信に関する。
【０００２】
【従来の技術】
JPEG2000は、JPEG2000ファイルの全体を復号化することなく、画像の様々な領域、解像度、及び、品質レベルを利用できるようにするため設計された。多様なプログレッション順序が定義され、低速の通信チャネルを介して伝送されたファイルは、例えば、低解像度から高解像度へ、若しくは、低品質から高品質へ、ある種の方法で「進行（プログレス）」する。また、ファイルが蓄積された順序とは異なる順序で画像の一部を選択し得る機能も興味がある。一般的に、伝送のために画像の領域と品質が対話的に選択される。
【０００３】
仮想メディア(Vmedia)アクセス・プロトコルが提案され、Vmediaを用いる双方向性JPEG2000ブラウザが開発されている（例えば、非特許文献１を参照。）。
【０００４】
JPEG2000画像を伝送するためのクライアント／サーバ環境も規定されている（例えば、非特許文献２を参照。）。非特許文献２には、スマート・クライアント、ダム・クライアント、スマート・サーバ、ダム・サーバが規定され、「パン・アンド・ズーム」セッションでのJPEG2000バイト使用法の例が与えられ、インターネット・イメージング・プロトコル(IIP)、バージョン1.0.5、1997年10月6日に基づくプロトコルが記載されている。このプロトコルは、非特許文献３に記載されているアイデアの一部を拡張しているが、しかし、非特許文献４に記載されているような転送用のHTTPに基づいている。
【０００５】
JPEG2000画像はHTTPを使用して送信される（例えば、非特許文献５を参照。）。しかし、ヘッダ情報を含む別々のインデックス・ファイルが送信され、望ましい画像構成要素を得るためHTTPバイトレンジ要求（リクエスト）が使用される。このプロトコルは、要求のパイプライン化が可能であるが、割り込みはできない。インデックス・ファイルを取得するために余分なラウンド・トリップ時間を必要とする。それらの例は、非常に非効率的である。なぜならば、複数のバイトレンジが境界値を含む「コンテント−タイプ：マルチパート／バイトレンジ」によって送信されるからである。あるケースでは、４８バイトのデータに対して７０バイトのオーバーヘッドが存在する。
【０００６】
バイトjpボックス、j2kパケットのような値をもつHTTP「アクセプト−レンジ」が使用されている（例えば、非特許文献６を参照。）。このアプローチの主要な欠点は、補助的なレンジ・タイプをサポートするサーバを決定した後に、初期コネクションを終了し、新しいコネクションを開設しなければならないことである。
【０００７】
JPEG2000ファイル転送の基本要素としてプリーシンクト(precincts)及びコードブロックが使用されている（例えば、非特許文献７を参照。）。この文献では、バイナリ・コンテナを使用し、アクノリッジ及びセッション情報を指定し、基本リターンタイプとしてプリーシンクトのバイトレンジを使用するプロトコルが定義されている。これに対して、このプロトコルは、通信の基本要素として、セルフラベリング型タイルパーツを使用する。このようにして、クライアントとサーバの両方が有効なJPEG2000コードストリームの複製を入手する。
【０００８】
JPEG2000双方向プロトコル（JPIP)の提案の募集が発表されている（例えば、非特許文献８を参照。）。この文献には、ブラウザと共に使用され、効率の指標が求められるパンとズームのステップのシーケンスが記載されている。
【０００９】
この提案募集への回答として、完全なプロトコルと、JPEG2000ファイルの個別のコードブロック又はより大きい部分へのアクセスが規定されている（例えば、非特許文献９を参照。）。この提案には、プロトコル用のアプリケーション・プログラマーズ・インタフェース(API)も規定されている。
【００１０】
【非特許文献１】
J.Li, H.H.Sun著、“Virtual Media (Vmedia) Access Protocol and its Application in Interactive Image Browsing”、Proc. SPIE Conf. on Multimedia Computing and Networking、2001年1月22−23日、San Jose, CA、第4312巻、ｐ．９９−１１０
【非特許文献２】
M.Boliek, G.K.Wu, M.J.Gormish著、“JPEG2000 for Efficient Imaging in Client/Server Environment”、Proc. SPIE Conf. on App. of Digital Imaging、2001年7月31−8月3日、San Diego, CA、第4472巻、ｐ．２１２−２２３
【非特許文献３】
Boliek外、“JPEG 2000 for Efficient Imaging in Client/Server Environment”、Proc. SPIE Conf. on App. of Digital Imaging、2001年7月31日−８月3日、San Diego, CA、第4472巻、ｐｐ．２１２−２２３、
【非特許文献４】
R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, L.Masinter, P.Leach, T.Berners-Lee（編）、“Hypertext Transfer Protocol _ HTTP/1.1”、RFC2616、1999年6月
【非特許文献５】
Sachin Deshpande and Wenujn Zeng、“Scalable Streaming of JPEG2000 Images using Hypertext Transfer Protocol”、Proc. ACM Conf. on Multimedia、2001年10月2−4日、ｐ．３７２−３８１
【非特許文献６】
Wright, R.Clark, G.Colyer、“An implementation of JPIP based on HTTP”、ISO/IEC JTC 1/SC 29/WG 1 N2426、2002年2月14日、Elysium Ltd.、英国
【非特許文献７】
D.Taubman、“A Very Simple Proposal for JPIP”、ISO/IEC JTC 1/SC 29/WG 1 N2445、2002年3月13日、ニュー・サウズ・ウェールズ大学、オーストラリア
【非特許文献８】
R.Prandolini, S.Houchin, R.Clark、“Call for JPIP Technology Proposals”、ISO/IEC JTC 1/SC 29/WG 1 N2550、2002年3月21日
【非特許文献９】
Canon、“Proposal for JPIP Tier2 protocol”、WG1N2608、2002年6月28日
【００１１】
【発明が解決しようとする課題】
本発明は、コードストリームの一部分を通信メカニズムを用いて転送する方法及び装置を提供する。
【００１２】
【課題を解決するための手段】
一実施例によれば、本発明の方法は、ネットワークを介して要求を送信し、ネットワークから要求への応答（レスポンス）の一部のようなリターンタイプとしてJPEG2000に準拠したコードストリームのタイルパーツを受信する。
【００１３】
【発明の実施の形態】
本発明は、以下の詳細な説明と、本発明の様々な形態についての添付図面とからより十分に理解されるであろう。しかし、以下の説明及び添付図面は、本発明を特定の実施例に限定するために用いられるべきではなく、本発明の解説と理解だけのために用いられる。
【００１４】
JPEG2000画像（或いは、その他の圧縮画像）の一部分をネットワークを介して通信する方法及び装置を説明する。HTTPに基づき、画像及びオブジェクトのアクセスを可能にする要求及び応答の通信用シンタックスを説明する。ファイルフォーマット・オブジェクトは、ボックスを指定することによりアクセスされ、コードストリーム要素は、タイルパーツ、即ち、コードストリームの本来の要素で返される。要求シンタックスを解釈し、応答を定義するプロトコルも説明される。画像通信の試みを分割するアーキテクチャが提示される。
【００１５】
〔概要〕
図１は、画像アクセスを実現するトランスポート・プロトコルの説明図である。図１では、クライアントは、サーバ（例えば、アパッチ(Apache)サーバ、専用画像サーバなど）へ初期要求１０６を出す。サーバは、画像１０２を獲得するため伸長することができる少なくとも一つのJPEG2000コードストリームを含むJPEG2000ファイルを格納している。システムは、リターンチャネル１０４を介して、JPEG2000コードストリーム１０１の一部分（例えば、タイルパーツ）をクライアントへ配信する。このクライアントは、直前に受信したタイル１０３を正当なJPEG2000コードストリームとして使用し、画像のある部分を形成するためこのコードストリームを復号化することができる。クライアント側の画像は、例えば、空間領域が縮小され、品質が低下し、コンポーネントの個数が削減し、或いは、解像度が低下するなどのいく通りかの方法で、サーバ上の画像よりも小さくなる場合がある。配信は、ネットワーク（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、ワールド・ワイド・ウェブ（ＷＷＷ）など）のような通信設備を介して行われる。一実施例において、システムは、遠隔地からJPEG2000ファイルへアクセスするため、ある種のパラメータ及び拡張と共にHTTP/1.1を使用する。一実施例では、これを実現するため、HTTP/1.1とJPEG2000ファイルフォーマット及びコードストリームの両方の既存の機能が以下に詳述するように使用される。別の実施例では、システムは、JPEG2000ファイルへアクセスするため、例えば、TCP/IP、UDP、SONETのような他のプロトコルを利用する。
【００１６】
一実施例では、クライアントとサーバの間の様々な区分のためのサポートが存在する。クライアント側では、画像オブジェクトが使用され、起点サーバ側では（即ち、クライアントと起点サーバの間に中間サーバが存在し得る）、バイトレンジが使用される。一連のステージは、画像オブジェクトからバイトレンジへ進むため使用される。あるステージから次のステージへの移行は、ネットワーク経由で、HTTPコネクションによって、若しくは、ローカルに関数呼び出しを用いて行われる。クライアントとサーバの双方のためのプロトコル及び多重レベルＡＰＩは定義される。
【００１７】
非常に多種多様なクライアントは、ここでの教示を利用する。一実施例において、表示装置の外部にメモリを具備しないクライアントは、画像オブジェクトが供給される。他の実施例では、システムの一つ以上のクライアントは、典型的なサーバよりもJPEG2000について詳しく理解し、望ましいコードストリームの部分を指定する。
【００１８】
或いは、HTTPに基づいていないプロトコルを使用してもよい。しかし、HTTPに基づいていないプロトコルは、ファイアウォール通過、プロキシ及びキャッシング技術（例えば、ワールド・ワイド・ウェブ(WWW)で利用可能な技術）、セキュリティ、認証、並びに、文書変更時間判定技術のうちの一つ以上の機能を獲得する手法を提供する必要がある。
【００１９】
以下に説明するトランスポート技術は、任意のJPEG2000ファイル若しくはコードストリームで動作するが、タイルに分割されたこれらのコードストリームは、より効率的にトランスポートされる。一実施例において、JPEG2000ファイルは、プロトコルを使用する前にトランスポートのため準備される。したがって、ここで説明するプロトコルは、作成されるすべての種類のJPEG2000ファイルに対し最適化する必要はない。これにより、要求されるシンタックス要素の個数と、クライアント及びサーバ側で要求される処理は著しく減少する。
【００２０】
〔トランスポート・アーキテクチャ〕
図２は、トランスポート・プロトコル・ソフトウェア構造の一実施例の説明図である。クライアントとサーバの間の通信は、図２に示されるように４ステージを通過するものとして考えられる。一実施例において、これらの４ステージは、伸長器又はデコンプレッサ（ステージ１）と、ビューポート−画像マッパー（ステージ２）と、画像オブジェクト・ラッパー（ステージ３）と、画像オブジェクト要求−バイトレンジ・コンバータ（ステージ４）と、を含む。
【００２１】
図２を参照すると、クライアントは、ウェブ・ブラウザのようなアプリケーション２００を含み、サーバは、ファイルシステム若しくはオンザフライ画像発生器２０５を含む。一実施例において（例えば、図３を参照）、JPEG200ファイルを取り扱うすべてのJPEG2000機能は、サーバ上に存在し、即ち、第１ステージ２０１と、第２ステージ２０２と、第３ステージ２０３と、第４ステージ２０４とは、すべてファイルシステム２０５と同じシステム上に存在する。クライアント・アプリケーション２０１は、認識しているフォーマット（例えば、JPEGフォーマット）で完全な画像ファイルを送信する。これは、従来のクライアントに対して有効である。なぜならば、サーバは、クライアント・アプリケーション２０１が使用可能な画像を返すことが可能であるからである（JPEG若しくはPNGを返す）。或いは、これは、クライアント・アプリケーション２０１のメモリ若しくは計算能力が非常に制限されているとき、従来のクライアントに対して有効である。
【００２２】
図２に示された各ステージにおいて、要求タイプが一方のティアー（層）から別のティアーへ変換されるか、応答タイプが一方のティアーから別のティアーへ変換される。ここで、各ティアーは通信のタイプである。かくして、クライアント端の要求及び応答は、画像オブジェクトであると考えられる。一実施例において、画像オブジェクトは、画面の領域、又は、一枚の紙であり、そこに、これらの領域を埋める画像と圧縮されていないカラー変換ビットを配置することが望ましい。ファイルシステム側では、通信は、バイトレンジの形で行われる。一実施例では、バイトレンジ通信は、Ｃ言語プログラムが使用するfseek()呼び出し及びfread()呼び出しのシーケンスにより構成される。別の実施例では、バイトレンジ通信は、不必要なデータが捨てられたfread()呼び出しだけにより構成される。尚、本発明の教示はＣプログラミングには限定されず、その他のプログラミング言語若しくはシステム（並びに、関連した呼び出し）も使用される。例えば、ワシントン州レッドウッドのMicrosoft Computerは、異なる呼び出しの組を使用する製品をもっている。別の方式でバイトレンジ通信を実行するため、カリフォルニア州マウンテンビューのSun MicrosystemsのJava（登録商標）を使用することも可能である。また、ファイルは、メモリに取り込み、メモリアクセスを使用してもよい。
【００２３】
一実施例において、クライアントとサーバの間の区分は、図２に点線で示されている５箇所のいずれの箇所でも行うことができる。一実施例において、クライアントは、サーバとの通信が圧縮形式で行えるように第１ステージの処理を含む。クライアント（例えば、ウェブ・ブラウザ）は、ライブラリを用いてJPEG2000伸長を実行する。一実施例において、クライアントとサーバが特定の点線で区分されているとき、その点線を超える通信はHTTPを用いて行われる。このような場合、一実施例では、クライアント若しくはサーバが点線の両側を含んでいるならば、通信は関数呼び出しによる。
【００２４】
より詳細に説明すると、図２において、T1はバイトレンジ・アクセスを表し、T2はJPEG2000画像オブジェクト・アクセスを表し、T3はビューポート／完全画像アクセスを表す。クライアントとサーバの間の区分が第２ステージと第３ステージの間にあるとき、クライアントは、JPEG2000画像オブジェクトのhttp要求を行う。プロトコルの区分が第４ステージとファイルシステム２０５の間で行われるとき、クライアントは、すべてのJPEG2000の知識をもっている。
【００２５】
図３は、クライアントとサーバの間の区分がクライアント・アプリケーション２００と伸長器（第１ステージ）との間で行われる第３ティアー通信の説明図である。このコンフィギュレーションには多数の潜在的な用途が存在する。例えば、これは、キャッシュを具備せず、DCTベースのJPEGデコーダだけを具備しているクライアントに使用できる。この区分は、ローカル・サーバに接続されたアプリケーション用のAPI、又は、既存のブラウザへの下位互換性が要求される状況用のAPIにも使用される。
【００２６】
図４は、クライアントとサーバの間の区分が第１ステージと第２ステージの間で行われる第３ティアー要求及び第２ティアー応答の説明図である。このコンフィギュレーションの潜在的な用途には、簡単な要求及び効率的なトランスポートと、パンとズームのクライアントと、JPEG2000がプラグインされたブラウザ若しくは始めからJPEG2000をサポートするブラウザと、が含まれる。
【００２７】
図５は、クライアント２０１とサーバ２０２の間の区分が第２ステージと第３ステージの間で行われる第２ティアー要求及び第２ティアー応答の説明図である。このようなシステムは、クライアントがサーバよりもユーザのニーズを知っている場合に潜在的な用途がある。
【００２８】
図６は、クライアントとサーバの間の区分が第４ステージとファイルシステム２０５の間で行われる第１ティアー要求と第１ティアー応答の説明図である。これは、サーバがJPIPを認識しない場合に使用できる。
【００２９】
図７は、プロキシ・サーバが使用される状況の説明図である。図７を参照するに、第１ステージと第２ステージの間、並びに、第４ステージとファイルシステム２０５の間に区分が存在する。より詳しく説明すると、プロキシ・サーバ７０３は、第２ステージから第４ステージまでを担当する。一実施例において、ファイルシステム２０５は、Apacheサーバである。本実施例では、従来型のサーバ（例えば、バイトレンジ要求をサポートするApacheサーバなど）が使用され、JPEG2000クライアントのパン／ズームは、これまでに良く知られた形式でサポートされ、中間プロキシ・サーバが使用される。同図には、１台のプロキシ・サーバしか示されていないが、クライアントとサーバの間には、1段以上のステージを取り扱う２台以上のサーバを設けてもよい。或いは、プロキシ・サーバ７０３によって扱われるステージは、ステージ２からステージ４までよりも多くても少なくても構わない。
【００３０】
このアーキテクチャの場合、クライアントとサーバの相互作用は１回に限られない。例えば、クライアント・アプリケーションは、完全画像オブジェクトだけと通信するコードを含む。画像を表示するため、クライアント・アプリケーションは、ローカル・サーバと通信する。このローカル・サーバは、高帯域幅接続によって接続してもよい。これに対して、サーバは、第３ティアー要求を使用して低帯域幅接続を介して別のサーバと通信し、第２ティアー応答を受信する。この２番目のサーバは、画像の「発生元」サーバでもよく、或いは、高帯域通信を介して、バイトレンジ要求だけを認識する「ダム」サーバと通信してもよい。これらの各サーバは、キャッシュを保持することができる。
【００３１】
クライアント若しくはサーバ内の構成要素は、図示されるようなステージに分割することが可能であるが、必ずしもこのように分割しなくてもよい。サーバは、例えば、第２ステージから第４ステージまでの多数のステージを一括して取り扱う単一のコード本体部を収容してもよい。これにより、メインヘッダのようなある種の画像情報を様々なステージにおいて重複することなく１回だけ記憶することが可能になる。
【００３２】
〔第１ステージ：伸長器（デコンプレッサー）〕
一実施例において、伸長器ステージは、第２ティアー応答のシーケンス及び現在の「ビューポート」を画像データに変換する。ビューポートは、クライアントが着目している全画像のうちの一部分である。ビューポートは、屡々、コンポーネントの部分集合、低解像度、或いは、小さい空間領域である。本質的に、伸長器ステージは、受信データに対して「普通」のJPEG2000伸長器を動かし、クライアントが希望する領域を復号化する。一実施例において、伸長器は、完全（フル）解像度の全画像を生成するためデコーダを動かし、着目している領域までクロッピングし、着目している解像度まで拡大縮小すことによって実現される。一実施例では、望ましい解像度、領域、コンポーネント、及び、品質に必要なファイルの部分だけが復号化される。これにより、計算資源とメモリが節約される。代替的な実施例では、システムは、既に望ましいコンポーネント数及び望ましい解像度で画像全体を復号化している。
【００３３】
一実施例において、伸長器は、Kakadu式JPEG2000でデコーダを使用する。kdu_expandプログラムは、低解像度の復号化と、着目している領域の復号化と、コンポーネント数の削減とを可能にさせる。ウィンドウ問い合わせとデコーダのコマンドラインとの間には、ディレクション関係が存在する。
【００３４】
一実施例では、伸長器は、実際にkdu_expandプログラムをスタートさせるのではなく、等価的な機能が動的リンクライブラリ（DLL)に集められる。一実施例では、伸長器は、受信JPEG2000コードストリームと、画面に表示される復号化画像のための外部ファイルを使用する。これにより、クライアントが終了させられたとき、簡単にキャッシングが行える。一実施例では、復号化画像用の外部ファイルを使用するのではなく、画像をメモリに収容するため、JPEG2000ライブラリが呼び出される。これにより、応答速度を速めることが可能である。
【００３５】
その他のJPEG2000ライブラリをKakaduの代わりに使用してもよい。例えば、要求された領域を最近接のタイル境界へ拡張し、全タイルを復号化するライブラリを使用してもよい。クライアントは、タイル境界と交差することなくパンニングする際に、このライブラリを使用して、画像の表示速度を速めることが可能である。このライブラリを用いて復号化された画像は、ユーザに要求されたビューだけを見せるためにクロッピングされるが、ビューポートを僅かに変更することにより、既に復号化された画像の簡単な再クロッピングと表示が行われる。同様に、ユーザの領域要求が新しいタイルからの素材に含まれるとき、これらのタイルだけを復号化し、それらをメモリ内の再構成画像に追加することが可能である。この場合、完全なクライアントのビュー上でJPEG2000デコーダを動かすことは、新しい符号化データが受信されたときに、表示される画像の品質を向上させる場合に限り必要である。
【００３６】
〔第２ステージ：J2Kマッパーへのビューポート〕
このビューポート−JPEG2000マッパーのステージは、ビューポート要求をタイルパーツに変換するため、JPEG2000ファイルに関する情報を使用する。一実施例において、このステージは、未だヘッダ情報を取得していない場合には、そのヘッダ情報を要求する。一実施例では、このステージは画像ヘッダ情報のコピーを保持するので、未来のビューポートは、JPEG2000タイルパーツに直ぐに変換することが可能である。このステージは、既に第１ステージへ転送された画像オブジェクトの要求の繰り返しを避けるため、第１ステージへ転送された応答のリストを保持する。
【００３７】
タイルパーツによる通信のため、ビューポイントのタイルパーツの組へのマッピングが行われる。マッパーは、画像の望ましい領域を、JPEG 2000 Part 1 standard (ITU-T Rec. |800 ISO/IEC 15444-1:2002-JPEG 2000 Imaging Coding Standard)に規定されている「基準グリッド単位(reference grid units)」へ変換する。マッパーは、どのタイルパーツが着目している領域と交差しているかを判定するため、SIZマーカー・セグメントのXTsiz、YTsiz、XTOsiz、YTOsiz、XOsiz、及び、YOsiz部分を使用する。第３ティアー要求シンタックスから獲得された解像度、品質及び領域は、必要なタイルパーツを決定するため使用される。一実施例において、マッパーは、タイルパーツの場所を指定するSIZマーカーによって指定された場合に、（問い合わせ文字列によって指定されるような）着目している領域と交差するタイルパーツだけに注目する。
【００３８】
より詳細に説明すると、タイルパーツを用いた通信のため、ビューポイントがタイルパーツの組（集合）へマッピングされる。画像の部分（解像度、空間領域、品質及びコンポーネント）は、クライアント要求に、明示的に、若しくは、デフォルト値を用いて与えられる。マッパーは、画像の望ましい領域を、JPEG 2000 Part 1 standard (ITU-T Rec. |800 ISO/IEC 15444-1:2002-JPEG 2000 Imaging Coding Standard)に規定されている基準グリッド単位へ変換する。各タイルパーツの基準グリッド単位は、JPEG2000コードストリーム内のSIZマーカー・セグメントのXTsizパラメータ、YTsizパラメータ、XTOsizパラメータ、及び、YTOsizパラメータによって決定される。要求された領域と交差するタイルからのタイルパーツだけが送信される。タイルの中のどのタイルパーツを送信すべきであるかは、要求された解像度及び品質と、符号化データのタイルパーツへの編成の仕方と、に依存する。簡単な一実施例では、低解像度から高解像度までの解像度毎に一つのタイルパーツが使用される。この場合、配信されるタイルパーツの個数は、要求された解像度だけに依存する。
【００３９】
図９は、ビューポート問い合わせパラメータと、SIZマーカー・セグメント・パラメータとの間の対応関係の説明図である。図９を参照するに、XTOsiz、YTOsiz、XOsiz、XTsiz、YTsiz、Xsiz、及び、Ysizはすべて、SIZマーカー・セグメントから得られ、xo、yo、ｗ及びｈは、ビューポート要求パラメータである。二つのパラメータ集合の間の対応関係は次のようになる。Xsiz−XOsizが、問い合わせパラメータ空間内の水平方向で１．０に対応する基準グリッドサンプルの個数を表し、ｗ及びxoは、（Xsiz−XOsiz）で乗算することによって基準グリッド単位へ変換される。同様に、垂直方向に関して、ｈ及びyoは、Ysiz−YOsizを乗算することによって基準グリッド単位へ変換される。
【００４０】
一実施例において、各タイルパーツに関する情報は構造に記憶される。この構造は、第２ステージ用のメモリでもよい。この構造は２ビットの構造であり、一方のビットは、タイルパーツが現在要求に対するクライアントへ送信されるべきであるかどうかを指定し、他方のビットは、タイルパーツが送信され終えたかどうかを指定する。このように、タイルパーツ毎に２ビットが存在する。タイルパーツがキャッシュに存在する場合、２番目のビットがターンオンされ、タイルパーツは送信しなくてもよい旨が示される。タイルパーツがキャッシュに存在しない場合、１番目のビットによって示されるような必要に応じて、タイルパーツがクライアントへ送信され、再送信を防止するため２番目のビットがターンオンされる。或いは、この構造は、送信してもよいかどうかを示す１ビットだけを使用するのではなく、各タイルパーツの優先順位を表す情報を記憶するために拡張できる。
【００４１】
コードストリームから、SOTマーカーは、タイル索引の細部と、各タイルパーツに必要なバイト数と、を与える。一実施例では、コードストリームから、送信されるべきタイルパーツに対応した適切なバイトがクライアント側へ送信される。ビューポートが変化し、対応した関連するタイルが変化した場合、先に送信されていないタイルだけが表示画像を更新するために送信される。
【００４２】
〔第３ステージ：画像オブジェクト・ラッパー〕
第３ステージは、バイトレンジ応答を取得し、画像オブジェクトを作成する。一実施例において、画像オブジェクト・ラッパーは、画像オブジェクト要求のシーケンスを一時記憶する。その結果として、第４ステージからの応答、例えば、
HTTP/1.1 200 OK
[other header line]
Content-Range:200-500/23382
CRLF
Data
のような応答は、画像オブジェクト表現の応答に変換される。完全タイルパーツだけが返される場合、このステージは、HTTP応答から"Content-Range"行を削除するだけである。一実施例では、このステージは、異なるヘッダでデータを包む（ラップする）。
【００４３】
一実施例において、第３ステージ及び第４ステージは完全に統合される。この結合されたステージは、望ましいデータを取得し、返却されたデータをHTTP応答に包みこみ、第２ステージへ供給するため、fseek()呼び出しとfread()呼び出しを実行するであろう。
【００４４】
一実施例において、トランスポート・プロトコルは、タイルパーツ及びボックスとは異なり、セルフラベリングされないオブジェクトをサポートするように拡張される。この場合、画像オブジェクト・ラッパーは、返却されたデータを識別子で包み込む。一実施例では、このラッピングは、次の形式：
Packet:=0&layer=0&component=2&position=5&tile=7
のHTTPヘッダでもよい。この新しいヘッダは、符号化データよりも先行するメッセージ本体内のバイトのシーケンスでもよい。
【００４５】
〔第４ステージ：J2K−バイトレンジ・コンバータ〕
J2Kからバイトレンジへのコンバータ（第４ステージ）は、圧縮画像オブジェクト要求をバイトレンジ要求に変換する役割を担う。一実施例では、このために、メインヘッダ、様々なコードストリーム・ボックスの場所、及び、タイルパーツを獲得するため、幾つかのバイトレンジ要求を作成することが必要である。殆どの場合、このコンバータは、多重アクセスを防止するため、情報を一時記憶する。コンバータは、たとえ、JPEG2000ファイル内でのタイルパーツのバイトレンジを参照する要求の場所を決定するために多重読み出しが必要であるとしても、要求された画像オブジェクトだけを返す。
【００４６】
一実施例では、ヘッダを送信する前に、サーバは、JPEG2000コードストリームのヘッダに達するまで、JPEG2000ファイルの構文を解析する。このとき、サーバは、コードストリーム・ヘッダ、或いは、構文解析されたファイルを、コンバータへ送信する。このようにして、コンバータは、0x6A703263によって示されるコードストリーム・ボックス・ヘッダの開始よりも前のすべてのデータを無視する。コードストリーム内のすべてのタイルパーツは、SOTマーカー・セグメントから始まる。SOTマーカー・セグメントは、タイルパーツの長さを含む。コンバータは、タイルパーツの長さを得るため、SOTマーカーを読み、タイルパーツの長さ、及び、タイルパーツの場所をJPEG2000ファイルに保存し、コンバータは、次のSOTマーカーへ進む。したがって、ビューポイント−J2Kマッパーがタイルパーツの組を要求する旨を示した後、コンバータは、作成されたメモリ構造から、タイルパーツの対応したファイル場所を獲得する。即ち、コンバータは、ファイルを構文解析すると共に、タイルパーツをメモリに記憶し、タイルパーツをクライアントへ送信する。コードストリームのメインヘッダ内のTLMマーカーは、タイルパーツの場所及び長さを格納する。したがって、一実施例では、TLMマーカーは、JPEG2000ファイル内のタイルパーツの位置を決定するため使用される。
【００４７】
換言すると、バイトレンジ要求は、JPEG2000コードストリームのメインヘッダ内のTLMマーカー・セグメントを使用して、或いは、各TLTマーカーを読み出すこと（及び、次のTLTマーカー・セグメントへ進むこと）によって作成される。いずれの場合も、第４ステージは、タイル索引と、タイルパーツの個数と、ファイルの先頭からのオフセットと、タイルパーツの長さ、の４個のエントリーを含むリストを構築することが可能である。タイル索引、タイルパーツの個数、及び、長さは、すべて、TLTマーカー・セグメントの一部である。第４ステージが各TLTマーカー・セグメントを読み出すとき、第４ステージはファイルの先頭からのオフセットを保存することが可能である。次に、特定のタイル索引及び部分番号に対する要求が生成されるとき、第４ステージは、生成されたリスト内のタイルパーツを見つける。オフセット及び長さのリスト内のエントリーは、バイトレンジ要求のため使用される。
【００４８】
構文解析中に、コンバータは、JPEG2000コードストリームの前にすべてのバイトを読む。スピードアップは、「ボックス」ヘッダを読み出すことにより、即ち、「ボックス」タイプ及び「ボックス」長さを読み出し、関連していないボックスを飛ばすことにより、達成される。
【００４９】
一実施例において、コンバータは、ファイルシステムに接続され、ファイルを読むためにシステムコールを行う。コンバータは、JPIPをサポートしていないがバイトレンジ要求をサポートしているサーバ（例えば、Apacheサーバ）に接続される。或いは、このステージは、JPEG2000画像を蓄積する役割を担うデータベースに接続してもよい。
【００５０】
〔第３ティアーはJPEGファイル又はPNGファイルを返す〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、第３ティアー応答は、ビューポートを埋めるために適したPNGファイル若しくはJPEGファイルである。
【００５１】
〔第２ティアーはボックス及びタイルパーツを返す〕
第２ティアーは、更なるラッピングを行うことなく、ボックス及びタイルパーツを返すので、要求に対する応答は、有効なJPEG2000ファイル若しくはコードストリームを形成するために連結され得る。これは、典型的に、第１ステージを実行するクライアント若しくはコンピュータシステム、又は、装置によって行われる。クライアントは、PIP若しくはトランスポートを理解できないJPEG2000デコーダを利用することが可能である。ブラウザ用のローカル・ディスク・キャッシュは、他のディレクトリへコピーすることができる有効な画像で埋められ、有効な画像は他のディレクトリへコピーされない場合には、JPEG2000ファイルとして操作される。
【００５２】
一実施例において、トランスポート・プロトコルは、信頼性の高い順序付けされたチャネルを前提とするHTTPを使用する。これにより、クライアント若しくはステージは、ある程度のエラー検出を行わなくても済むようになる。
【００５３】
〔トランスポート・プロトコル定義〕
〔要求シンタックス〕
要求は、第３ティアー「全体の画像オブジェクト」、第２ティアー「符号化されたデータオブジェクトレベル」、及び、第１ティアー「バイトレンジ」の３種類のティアーで行われ得る。しかし、一実施例では、すべての要求は、HTTPシンタックスを使用し、一部のオーバーラップが生ずる。例えば、画像以外のデータ、例えば、JPEG2000におけるボックスに対する要求は、画像及びオブジェクトレベルで同一である。更に、クライアントは、画像レベルで殆どのデータへアクセスすることを望むかもしれないが、メタデータの一部分、例えば、画像に関連付けられた音（サウンド）は、（特に、他のチャネルの使用と干渉するかもしれない程度に大きいならば）バイトレンジでアクセスされる。例えば、約２０００バイト以上のメタデータが必要ではないときには、要求を作成するオーバーヘッドは補われる。ある種のデータにバイトレンジでアクセスすると、サーバが理解できないメタデータを含むJPEG2000ファイルは、ボックス全体よりも小さい単位でアクセスできるようになる。
【００５４】
〔第３ティアー要求〕
一実施例において、第３ティアーの要求は、
GET filnename.jp2?res=2 HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
のように表される。
【００５５】
これらはすべて、標準HTTP要求のコンポーネントである。"GET"はメソッドである。"filename.jp2"は、ファイル名、若しくは、より一般的には完全なURLであり、サーバのルート・ディレクトリからの完全なパスでもよい。"?"の後のすべての項目は、CGI相互作用に典型的な「名前＝値」のペアである。この問い合わせ文字列は、スペースを含まない（それらは、%20として組み込むことが可能である。）。HTTP rfc、例えば、Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee （編）、"Hypertext Transfer Protocol _ HTTP/1.1"、RFC 2616、1999年6月を参照せよ。この文献は、以下の説明では、HTTP標準と呼ぶ。最終的なHTTP/1.1は、プロトコルを規定する。プロトコルの一部は、バージョン１．１よりも前のバージョンのHTTPと連動する。HTTP要求は、２個のキャリッジリターンとラインフィードのペアによって終了する。"CRLF"は、キャリッジリターンとラインフィードを表現するが、本例の場合、その文字は、行内の唯一の文字ではない限り、各行の終わりで省略されている。
【００５６】
一実施例では、HTTP GET要求の問い合わせ文字列にパラメータを組み込む代わりに、パラメータは、HTTP POST要求の本体部に組み込まれる。これは、後述のオプションが長い場合に有効である。
【００５７】
一実施例において、POST要求の一例は、
POST /cgi-bin/j2k_server.cgi HTTP/1.1
Host: truew.crc.ricoh.com
Content-type: Application/x-www-form-urlencoded
Content-length: 26
CRLF
filename=picture.jp2&res=2
である。
【００５８】
第３ティアーのビューポートを記述するために利用可能なオプションは次の表１に掲載されている。要求に影響を与える補助パラメータは表２に掲載されている。これらのオプションは、getメソッドとpostメソッドに対して同一である。
【００５９】
【表１】
【００６０】
〔パラメータの説明〕
パラメータｘｏ、ｙｏ、ｗ及びｈは、画像の領域を指定する。０は左上の端を表し、１は右下を表す。幅及び高さは画像の画分を指定し、１は全高若しくは全幅を表す。かくして、一実施例において、ｘｏ＝０＆ｙｏ＝０＆ｗ＝１＆ｈ＝１は、画像の全体（デフォルト）を指定する。これに対して、画像の中央セクションは、ｘｏ＝０．２５＆ｙｏ＝０．２５＆ｗ＝０．５＆ｈ＝０．５によって与えられる。左端は、基準グリッド上のＸＯｓｉｚの位置に存在し、上端は、ＹＯｓｉｚの位置に存在するものとする。図９と、パート１の付録ＡにおけるSIZマーカーの定義[ITU-T Rec. T.800|IS 15444-1:2000、Information Technology _ JPEG 2000 image coding system: Core coding system]を参照のこと。
【００６１】
パラメータｒｅｓは、画像を縮小するための解像度の数である。ｒｅｓ＝１は、画像を水平方向並びに垂直方向に約２倍の倍率で縮小する。この縮小は、JPEG 2000の様式で行われるので、画像７のグリッド点の幅は、SIZマーカーのオフセットの値に依存して、４サンプル若しくは３サンプルの幅に縮小される。
【００６２】
パラメータｍａｘｗ及びｍａｘｈは、クライアントが受信することに関心をもっているサンプルの最大個数を指定する。これは、「ｒｅｓ＝」パラメータを使用して縮小の量を指定することの代わりである。例えば、原画像のサイズを知らないクライアントは、１２８サンプルを含む最大高若しくは最大幅の画像を要求する。サーバは解像度を低下させる。サーバは、要求が満たされるまで、或いは、ＬＬサブバンドだけが返されるまで、解像度を低下させる。かくして、ウェーブレット変換の零レベルが圧縮の際に利用されているならば、１２８×１２８の最大画像の要求は５１２×５１２の画像を返し続ける可能性がある（しかし、起こりそうにない。）。
【００６３】
コンポーネント・パラメータは、どのコンポーネントを組み込むかを指定する文字列である。一実施例において、コンポーネントは、零から番号が付けられる。レンジを使用してもよい。かくして、コンポーネント＝０−２、５は、例えば、コンポーネント０、１、２及び５を返す。
【００６４】
品質パラメータは、サーバが送信すべきデータの量を決定するために役立つ。サーバは、返却するレイヤの数として、品質値を使用することを選んでもよい。一実施例において、品質に関する０ｘＦＦＦＦの要求は、領域内のタイルパーツについてサーバが保有するすべてのデータを要求することである。
【００６５】
表２には、応答の他の面を制御するため、問い合わせと共に使用される補助的なパラメータの組が掲載されている。第３ティアー値は、"png"若しくはDCTベースのJPEGフォーマットの完全な画像として応答を要求する。
【００６６】
【表２】
【００６７】
最大ボックスサイズパラメータは、指定されたバイト数に満たないすべてのボックスを返却させることができる。これにより、通信が非常に遅くならない限り、存在するであろうすべてのボックスを獲得できるようになる。
【００６８】
尚、許容可能なセットの範囲外の文字を使用するタイプのボックスは、URL符号化される。URL符号化に関する更なる情報は、RFC 2396のHTTP rfc［HTTP標準］を参照せよ。
【００６９】
ボックスもノットボックスもリストに掲載されていない場合、サーバは、返却すべきボックスを決定する。一実施例では、サーバは、すべてのボックスを返却すること、コードストリームより前のすべてのボックスを返却すること、画像をサーバに蓄積するときに画像の作成者が指定したすべてのボックスを返却すること、或いは、全くボックスを返却しないこと、を決定する。一実施例では、サーバのコンフィギュレーション・ファイルは、これらのオプションの任意の部分若しくは全部を許可する。コードストリームの一部分は、Notboxes=jp2cではない限り返却される。
【００７０】
要求パラメータ、値のペア、及び、それらの意味の例は以下の通りである。
boxes=jp2h
get the JP2 Heaser box.
boxes=jp2h/ihdr
get only the Image Header box within the JP2 Header box
boxes=uuid[5-7]
get the 5th 6th, and 7th UUID boxes (if they exists).
maxboxsize=4096
return boxes 4096 bytes or smaller
【００７１】
優先順位パラメータは、ある要求の他の要求に対する重要度を示す。新しい優先順位が前の優先順位と一致する場合、サーバは、新しい要求に関しても有効であるならば、旧い要求に関するバイトを送信し続ける。新優先順位と旧優先順位の差が１以上であるならば、サーバは、次の機会に旧い要求を停止し、新しい要求を開始する。優先順位が"Inf"である場合、サーバは新しい要求のために旧い要求を止める。サーバは、現在の要求に適用されるデータを送信し終えたとき、以前に中断された要求に関するデータを後で送信するように選択してもよい。
【００７２】
〔第３ティアーのための補助的なHTTPヘッダライン〕
次の表３には、クライアント側で利用可能なデータを指定するため使用可能な二つのヘッダラインが示されている。
【００７３】
【表３】
例：
T3chache: xo=0.0&yo=0.0&w=0.25&h=0.25&res=2
T3chache: maxw=128&maxh=128
【００７４】
尚、キャッシュの内容は、先行のビューポート要求への応答である。一実施例では、一つのＴ３キャッシュライン当たりに一つの要求が存在する。この要求は、問い合わせ文字列の一部としては送信されないが、HTTPヘッダラインとして送信される。Ｔ３キャッシュが使用されているならば、メインヘッダは受信されている、と考えられる。クライアントは、キャッシュされたすべての要求のリストを作成しなければならないわけではない。実際上、クライアントは、受信された各要求をリストに掲載し、このラインをアクノリッジとして使用する。サーバは、前の要求をタイルパーツのリストに翻訳し、これらのタイルを送信済みとしてマークすることができる。したがって、これらのタイルパーツは、現在の要求が翻訳されるときに、再送信されない。
【００７５】
Ｔ２キャッシュは、クライアントが受信されたタイルパーツのリストを作成できるようにする。シンタックスは次のように定義される。これは、タイルパーツを要求する典型的な方法に対応する。ここでも一実施例では、このラインは、問い合わせ文字列の一部分ではなく、HTTPヘッダラインである。一例は、次の通りである。
T2cache: 4.0, 4.1, 5.0-6.2
【００７６】
〔第２ティアー要求〕
第２ティアーは、第３ティアーと同じようにボックスに対する要求をサポートする。タイルパーツは、HTTPレンジヘッダを用いて明示的に要求され得る。タイルパーツに対する第２ティアー要求の効率的な用法は、符号化データのタイルパーツへのある分割に同意したクライアントとサーバに依存する。タイルは、あらゆる解像度若しくはあらゆるレイヤで、或いは、その他の方法でタイルパーツに分割しなければならない。一つの有効な分割法を次に詳しく説明する。第２ティアーの要求の例は、次の通りである。
GET file.jp2 HTTP/1.1
Host: truew.crc.ricoh.com
Range: tiles-parts=4.0, 5.0, 8.0-9.2
CRLF
【００７７】
ピリオドの前の値はタイル番号であり、ピリオドの後の値はタイルパーツ番号である。JPEG2000パート１の付録ＡからのIsot及びTPsotを参照のこと（文献：ITU-T Rec. T.800|IS 15444-1:2000, Information Technology _ JPEG 2000 image coding system: Core coding system)。尚、一実施例では、タイル番号及びタイルパーツ番号は、どちらも０から番号を付けられる。タイルパーツのレンジは、スタートタイルからストップタイルまでのすべてのタイルと、スタートからストップまでのこれらのタイルに関するすべての部分と、を含む。例えば、8.0-9.2は、8.0、8.1、8.2、9.0、9.1、9.2と等価的である。
【００７８】
一実施例では、タイルパーツは２個のパラメータ（タイルに対するIsotと部分に対するTPsot）をもつので、１次元のレンジのため設計された"Ranges"の代わりに、新しいHTTPヘッダラインを使用する方がよい。例えば、"Tile-part:"ヘッダは、
Tile-parts: 8.0, .8.1, 10.0-12.2
のように使用される。
【００７９】
〔第１ティアー要求シンタックス〕
第１ティアーの要求は、HTTP（HTTP標準）に規定されているように厳格なバイトレンジ要求である。例えば、
GET file .jp2 HTTP/1.1
Host: truew.crc.richo.com
Range: bytes=200-500, 1000-1500
CRLF
である。
【００８０】
上述の通り、要求は、位置２００で始まる３００バイトと、位置１０００で始める５００バイトである。このような要求は、典型的に、クライアントが所定のバイトレンジで期待すべきものを知っている場合に限り有効である。しかし、これらの要求は、例えば、画像に関連付けられたオーディオ・ストリームの全体を転送することなく、オーディオ・ストリームの一部分にアクセスするために有効である。
【００８１】
一実施例では、別々のラインでキャッシュ情報のリストを作成するのではなく、クライアントは、キャッシュ情報をHTTP問い合わせ文字列自体に組み入れることが可能である。例えば、ユーザが、以下の問い合わせ文字列：
GET filename.jp2?xo=0.0&Yo=0.0&w=0.25&h=0.25&res=2&maxx=750&maxy=750 HTTP/1.1
を入力する場合を考える。
【００８２】
クライアントは、第２ステージ（ビューポート・ツー・JPEG2000マッパー）で説明したようにサーバ側のファイルを解析したのと同様に、キャッシュ内のファイルを解析する。クライアントは、既にキャッシュ内に保有するタイルパーツのリストを形成し、サーバへ送信する前に問い合わせ文字列に付加する。したがって、サーバは、問い合わせ文字列：
GET filename.jp2xo=0.0&yo=0.0&w=0.25&h=0.25&res=2&maxx=750&maxy=750&T2cache=4.0, 5.0, 8.0, 8.1, 8.2, 8.3, 9.0, 9.1, 9.2, 9.3 HTTP/1.1
を取得する。
【００８３】
勿論、様々なシンタックスがビューポートを指定するため使用され得る。JPEG200パート９標準の最新版は、以下のシンタックスに類似したシンタックスを使用する。殆どのパラメータは、当業者が要求シンタックスの様々なタイプの間で翻訳できる。
【００８４】
【表４】
パラメータOffset=Px,Py及びSize=Sx,Syは、左端のPxサンプルから始まり、右側へサンプルPx個分だけ拡がり、一番上のPyサンプルから始まり、下方へサンプルPy個分だけ拡がる画像の領域を指定する。左端は基準グリッドのXOsizの位置にあり、一番上はYOsizの位置にある場合を考える。SIZマーカー・セグメントの定義については、JPEG2000パート１の付録Ａを参照のこと。これらのサンプルは、フレームサイズパラメータによって指定された解像度である。
【００８５】
パラメータFrame-size=Rx,Ryは、クライアントが画像を見ることを望む解像度である。Rx及びRyは、０から画像の寸法まで変化する。しかし、JPEG2000のドメインでは、復号化された画像は、有限のレベルの解像度でしか見ることができない。そのため、クライアントの要求に応じて、サーバは、R'x≧Rx並びにR'y≧Ryとなるような解像度R'x及びR'yを送信する。R'x及びR'yがRx及びRyとは異なる場合、サーバはこの情報をヘッダで送信する必要がある。JPEG2000パート１に記載されているように、解像度低下画像は、正確な位置に応じて、左端（左縁）と右端（右縁）で丸められる。例えば、画像７グリッド点幅は、SIZマーカーのオフセットの値に依存して、４サンプル分若しくは３サンプル分だけ幅が縮小する。
【００８６】
R'x及びR'yに依存して、要求された領域の左上隅のオフセット、幅、及び、高さは、
P'x=Px*R'x/Rx, P'y=Py*R'y/Ry, S'x=Sx*R'x/Rx, 及び S'y=Sy*R'y/Ry
のように変化し、ここで、P'x及びP'yは実際のオフセットを表し、S'x及びS'yはクライアント側のキャンバスに表示された画像の実際の幅及び高さを表す。
【００８７】
コンポーネントパラメータは、どのコンポーネントを取り入れるべきであるかを指定する整数のリストである。コンポーネントは０から順番に番号付けされている。レンジを使用してもよい。かくして、Components=0-2,5は、コンポーネント０、１、２及び５を返す。
【００８８】
L=qualityパラメータは、サーバが送信すべきデータの量を決定する際に役立つ。サーバは、返却すべきレイヤの数として品質値を使用することを選択することもある。いずれの場合でも、品質に対する0xFFFFの要求は、サーバが領域内のタイルパーツに関して保有するすべてのデータを要求する。
【００８９】
パラメータBh及びBsはオプションパラメータであり、サーバは、このパラメータを用いて、実際に送信されるバイト数に関するハードリミット若しくはソフトリミットを設定することができる。低解像度のタイルパーツが最初に送信され、高解像度のタイルパーツは、このリミットに達するまで送信される。このフィールドが存在しない場合、サーバは、特定の解像度で要求された領域を表示するために必要なタイルパーツを送信することができる。
【００９０】
フラグADDが肯定(yes)にセットされている場合、新しい要求を前に要求されたウィンドウと連結することができる。デフォルトとして、このフラグは、無効にされ、新しいウィンドウが要求されると、クライアントは前のウィンドウを置き換える。
【００９１】
〔応答シンタックス〕
〔第３ティアー応答〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、画像オブジェクトは、ビューポートを埋めるために適したPNGファイル若しくはJPGファイルである。このタイプの応答は以下のような応答である。
HTTP/1.1 200 OK
Content-type: image/jpeg
Content-length: 20387
CRLF
JPEG Compressed Image Data
【００９２】
尚、以下の第２ティアー応答に関して説明されるようなチャンク形式転送コーディングを使用することが好ましいが、チャンク形式転送コーディングを使用しなければならない訳ではない。
【００９３】
〔第２ティアー応答〕
第２ティアー応答は、HTTPヘッダでラップされチャンク形式転送エンコーディングを使用して送信された、要求されたボックスと、（前に送信されていならば）コードストリーム・メインヘッダと、連結されている要求されたタイルパーツと、により構成される。第２ティアー応答は、非常に大きくなり、送信するために非常に長い時間を要する可能性があるので、送信の途中で中断できることが重要である。例えば、１K×１Kのタイルを含む画像は、１．５メガバイトの応答を生ずる（遅いリンクを用いる場合、これは、長い時間を要する）。チャンク形式転送エンコーディングが指定されない限り、HTTP要求は、"Content-Length:"ヘッダの本体部の全長を指定するか、又は、接続を終えることによりデータの終了を示すことが必要である。どちらも実現可能ではあるが、望ましくはない。なぜならば、現在の応答を停止し、新しい要求のために同じコネクション上で更なるデータを送信することが望ましいからである。チャンク形式の場合、各チャンクの長さが送信され、応答を終了するため、長さ零が送信される。このように、一旦チャンクが開始されると、チャンクを終了させる必要があるが、応答を終了する前にすべての応答を完了させる必要はない。
【００９４】
以下にチャンク形式応答の例を示す。
HTTP/1.1 206 Partial Content
Content−Range: 0−2000, 4000−10200/867370
Transfer−Encoding: chunked
Content−type: image/jpeg2000
CRLF
1000
[4096 (or 1000 HEX−DECIMAL) bytes of JPEG 2000 data]
1000
[4096 (or 1000 HEX−DECIMAL) bytes of JPEG 2000 data]
8
[8 bytes of JPEG 2000 data]
0
【００９５】
上記の例の最初のヘッダラインは、応答が完全なファイルではないことを示すため「部分コンテンツPartial Content」ヘッダを使用する。"Content-Range"ヘッダは、ファイルのどの部分が送信されるかを示すため使用される。転送エンコーディング"Transfer−Encoding:"ヘッダは、データがチャンク形式であることを示すため使用される。データのタイプが与えられる。なぜならば、応答は、"image/jpeg2000"というタイプが与えられた復号可能なJPEG2000ファイルであるからである。他のタイプを使用してもよい。
【００９６】
１番目よりも後の応答の場合、応答は、有効なJ2Kコードストリームを格納していない（メインヘッダが含まれないことは非常に稀である。）。この場合、別のタイプ、例えば、"image/jPiP"を用いてそのことを示すことが望ましい。
【００９７】
一実施例において、４０９６バイトの第１のチャンクを送信した後に新しい要求が受信され、サーバが伝送を終了させることに決定した場合、サーバは、現在のボックス、メインヘッダ、若しくは、タイルパーツを完了し、長さ０のチャンクを示す。次に、新しい応答が新しいHTTPヘッダを用いて開始される。
【００９８】
〔第１ティアー応答〕
一実施例では、第１ティアー応答は、HTTP［HTTP標準］に規定されているバイトレンジ応答と同じである。データを簡単に終端できるように、チャンク形式転送エンコーディングを使用することが望ましい。
【００９９】
〔要求／応答セマンティックス〕
要求を受信した後、サーバはチャンクを送信している間に更なる要求を受信しようとしている。
【０１００】
サーバは、新しい要求の優先順位が十分であるならば、現在の応答を正常に終了し、新しい要求に応答し始める。一実施例では、十分な優先順位は、"Inf"優先順位の要求によって示される。サーバは、現在のタイルパーツを終え、現在の要求に対してこれ以上チャンクが送信されないことを示すチャンクサイズ０を送信する。一実施例において、サーバは、HTTPフッターを付加し、次の応答を開始する。
【０１０１】
サーバが"Inf"以外の優先順位を受信した場合、サーバは、現在の要求の中で継続すべき要求の量を決定する。現在の要求が新しい要求に対する良好な回答であるならば、アクションは必要ではない。例えば、新しい要求は異なるビューであっても、依然として同じ部分のセットが必要である場合がある。新しい要求の優先順位が前の要求の優先順位よりも１だけ高い場合、旧い要求は、新しい要求のために現在のタイルパーツの終わりで一時中断させることが提案される。
【０１０２】
最終的には、一実施例では、サーバは、すべての要求に適合する簡単な応答を送信する。或いは、応答が複数の要求に回答することを示すために規定されたシンタックスが使用される。この場合、サーバは、現在の転送を停止することなく、かつ、新しいHTTPヘッダから開始することなく、新しい要求若しくは旧い要求に関連したタイルパーツを送信し続ける。一実施例では、この場合、サーバは、拡張され得る要求を開始するときに、"Content−Range:"ヘッダを使用しない。
【０１０３】
〔サーバデータ記憶フォーマット〕
一実施例において、トランスポート・プロトコルは、すべてのJPEG2000ファイルフォーマット及びコードストリームで機能する。しかし、このような方式での機能は、必ずしも効率的ではない。例えば、タイルが使用されない場合、領域の要求は、コードストリーム全体を返すことがある。
【０１０４】
トランスポート・プロトコルと共に使用する最も効率的な画像圧縮方法は、期待されるアクセスの性質に依存する。"Call for JPIP technology proposals"[JPIP Editors (Prandolini, Houchin, Clark), Call for JPIP technology proposals, ISO/IEC JTC1/SC29/WG1 N 2550, 21 March 2002]に規定されているような「パン及びズーム」動作のシーケンスの場合、N/16×N/16のタイルサイズを使用することは、N×N画素のサイズの矩形画像に対して優れている。
【０１０５】
使用されるコードストリームに対する一つのプログレッション順序は、解像度−レイヤ−コンポーネント−位置（RLCP)である。タイルは、あらゆる解像度及びあらゆるレイヤでタイルパーツに分割可能である。一実施例において、低解像度のすべてのタイルパーツは、より高解像度のタイルパーツよりも前にファイルに保存される。これにより、低解像度部分は、最小回数のディスクアクセスで入手できるようになる。一実施例において、十分な品質は、タイル境界アーティファクトを回避するため、最初のレイヤに記憶される。
【０１０６】
場合によっては、無損失で保存された画像の低解像度バージョンをブラウズできることが望ましい。RLCP順の場合、画像が無損失に蓄積されるとは、低解像度画像のために多数のビットが使用されることを意味する。これは、クライアントとサーバの間の低速コネクションによる画像のパンとズームのブラウジングを遅くする。この問題は、画像をサーバに特殊な方法で格納することによって解決される。レイヤ−解像度−コンポーネント−位置(LRCP)プログレッション順序は、コードストリームのために使用されるが、最初のレイヤは、主として解像度順にデータを格納するため使用される。最後のレイヤは、画像の損失のない表現を記憶するため使用される。各レイヤには固有のタイルパーツが割り当てられるので、サーバは、完全なタイルパーツを送信することによって、望ましい解像度をクライアントに供給することが可能である。例えば、３レベルの解像度レベルのある単一の２５６×２５６タイルは、以下のように編成される。
【０１０７】
タイルパーツ０は、（すべてのコンポーネント及び位置に対して総計で）１２８バイトの解像度０のデータを格納するレイヤ０を収容する。これにより、かなり高品質であるが、依然として損失の多い画像（ビューイング解像度で１画素当たり１ビットと等価的な画像）がクライアントへ供給される。
【０１０８】
タイルパーツ１は、解像度０と解像度１の３８４バイトのデータを格納するレイヤ１を収容する。解像度０と解像度１のデータのバイト数は、解像度１の表示解像度で画質（画像品質）を最大にするように選択される。
【０１０９】
タイルパーツ２は、解像度０と解像度１と解像度２の１５３６バイトのデータを格納するレイヤ２を収容する。殆どのバイトは、解像度２であり、他の解像度は解像度２の表示解像度で最適な画質を得るために十分である。
【０１１０】
タイルパーツ３は、解像度０、１、２及び３の６１４４バイトのデータを格納するレイヤ３を収容する。タイルパーツ０〜３は、最適化された１ｂｐｐ画像を完全な解像度で格納する。
【０１１１】
タイルパーツ４は、損失の無い画像を得るために必要なすべての解像度の残りのデータを格納するレイヤ４を収容する。おそらく、階調画像については２４０００バイト、カラー画像についてはそれ以上のバイト数が必要である。勿論、タイルパーツは、２．０ビット／画素の画像と、損失の無い画像を得るため、補助的なタイルパーツに分割してもよい。或いは、ある最大タイルパーツサイズを維持するため、タイルパーツに分割してもよい。
【０１１２】
〔トランスポート・プロトコル性能〕
〔ディスクアクセスと要求される係数の数〕
以下の表４は、画像要求に応答するサーバによってアクセスされるファイル内の個別の場所の数のリストである。表４には、タイル全体又はプリーシンクトが要求に応じて送信されるならば、送信されるべき係数の数も掲載されている。勿論、送信されるべきバイト数は、主として圧縮比に依存するが、タイル若しくはプリーシンクトのサイズとは無関係に等しい圧縮を考慮すると、それらの値は応答サイズに関連付けられる。
【０１１３】
表４は、幾つかの異なるビューポイントに対するデータを表し、前の要求に対するデータが送信されたときに、新しいビューポイントに要求される補助的なアクセス／係数だけを表す。
【０１１４】
表４の値に対し、圧縮のため使用されるコマンドは以下の通りである。
Tiling: kdu_compress -i lena.bmp -o out.jp2 -rate -, 0.25 Clayers=30 Creversible=yes Stiles={128, 128}
Corder=RLCP
タイルサイズ：128×128；256×256；512×512；1024×1024 アンタイルに対する結果が表に掲載されている。
Precincts: kdu_compress -i lena.bmp -o out.jp2 -rate -, 0.25 Clayers=30 Creversible=yes Cprecincts={128, 128} corder=RPCL
プリーシンクトサイズ32×32；64×64；128×128；256×256；512×５１２に対する結果は表に掲載され、同じサイズのプリーシンクトが各解像度で使用される。
【０１１５】
表４は、プリーシンクトとタイルパーツの比較であるとみなすべきではない。なぜならば、プリーシンクトは、各解像度で、タイルに要求されるよりも小さいサイズを使用できるからである。
【０１１６】
【表５】
【表６】
一実施例において、プロトコルは、幾つかのメカニズムによって時間的に分離された多重接続上であってもデータの再送信を回避する。これは、既にクライアントへ送信されたデータを示すために、クライアントに、httpヘッダのうちの一つ（例えば、T2cache）を使用させることによって達成される。セッション持続性を与える代替的なメカニズムは、現在の多数の商業ウェブサイトで行われているように、セッションＩＤを維持するため、クッキー(cookie)を使用することである。勿論、サーバは、セッションの記録を残さないこともあり、クライアントが全く保存していないと考えられるコードストリームの部分を送信するに過ぎない。
【０１１８】
〔エラー処理〕
エラー処理に関して、HTTPは、エラー条件に対する様々な応答メッセージを含む。これらのすべては、このプロトコルと共に使用するために利用できる。エラーが検出された場合、ステージ間で再送信を要求することができる。HTTPフッターは、送信データのチェックサムを送信するため使用可能であり、これにより、エラーを検出する。
【０１１９】
〔速度（レート）制御〕
速度制御に関して、トランスポート・レベル・プロトコルと、ソケットを実現するライブラリは、例えば、典型的に、クライアントが処理できる速度よりも速い速度でクライアントにデータが送信されていないことを保証する。殆どのソケットライブラリにおいて、"send"呼び出しは、大量のデータが送信される場合、データが送信されるまでエラーを阻止するか、又は、エラーを返す。チャンク形式で大量の応答を送信することは、単一の"send"が非常に大きくなることを阻止するはずである。一実施例において、最大バイトパラメータのようなパラメータは、バイト数を制限するため使用される。また、クライアント及び／又はサーバは、速度制御を行うことが許可される。これにより、遅いリンク上のバッファの充填が制御されるであろう。
【０１２０】
トランスポート・プロトコルは、クライアントが有効な最大画像を指定できるようにするmaxhパラメータ及びmaxwパラメータを与えない。クライアントは、JPEG若しくはPNGへの翻訳を要求する。
【０１２１】
〔同時アクセスのためのサポート〕
ここで説明しているトランスポート・プロトコルは、サーバ上の同じ画像への同時アクセスを制限しない。一実施例では、単独のクライアントが同じサーバ上の同じリソースへ多重接続を開設する場合、各接続は、その接続についての要求の順序で扱われる。クライアントが望むならば、クライアントは、受信したT3cache若しくはT2cacheヘッダを用いて、所与の接続に要求していないデータを指定することができる。さもなければ、サーバは、二つの接続が全く同一のクライアントに対してなされていることを知ることができない。
【０１２２】
代替的な実施例では、セッション鍵は、別々の要求をつなぐため、要求及び応答のすべてのレベルに対するHTTPへ付加してもよい。これにより、上記のプロトコルは、HTTP1.1のデフォルトの「生かしておく（キープアライブ）」機能を用いることなく動作できる。また、これにより、信頼性の低いネットワーク上でもより巧く利用できるようになる。セッション内の要求を順番に並べるために要求番号を付加することが有効である。かくして、TCP上でHTTPを用いる場合であっても、多重接続を作成し使用することが可能である。セッション鍵は、クッキーヘッダを用いて、或いは、要求パラメータとして組み込むことが可能である。
【０１２３】
〔JPIP要求バインディング〕
HTTPは、TCP/IP以外のチャネルによっても搬送することができる。したがって、このプロトコルを、TCP/IP以外のHTTPをサポートするチャネルで使用することが望まれるならば、新しい定義は不要である。一実施例では、未訂正のエラー若しくはパケット損を含むチャネルに対してプロトコル・バインディングを指定することが望ましい場合、チャンク形式転送エンコーディングを使用する応答の各チャンクは、固有のネットワークパケットになる。他のすべての要求及び応答は、ネットワークパケット内に適合する。一実施例において、これらは、コネクション優先チャネルのため送出される順番にパケット番号が与えられる。尚、HTTP以外のプロトコルを使用しても構わないことにも注意する必要がある。
【０１２４】
〔キャパビリティ交換とネゴシエーション〕
一実施例では、キャパビリティは、応答のヘッダだけを要求するHTTPメソッド"HEAD"を用いて要求され、クライアントは、"GET"要求を用いて受信した応答のタイプを決定することが可能である。一例は、
HEAD filename.jp2?res=2 HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
のように表される。
【０１２５】
一実施例において、サーバのキャパビリティは、HTTPメソッド"OPTIOINS"、例えば、
OPTIONS * HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
を用いて要求される。
【０１２６】
一実施例において、特定の画像上の動作のキャパビリティは、
OPTIONS filename.jp2 HTTP/1.1
Host: truew.crc.ricoh.com
CRLF
を用いて決定される。
【０１２７】
HTTP 1.1 RFCは、キャパビリティを示すメカニズムを含む。ここで説明されている画像プロトコルの場合、サーバは、以下のラインを含むヘッダを返す。
Accept-Ranges: bytes, tile-parts
Accept: image/jpeg2000;q=0.9 image/gif;q=0.5 imag/jpigT2;q=0.95 image/ jpipT3;q=0.1
Allow: GET, HEAD, POST, OPTIONS, TRACEVary: accept, *
【０１２８】
HTTP 1.1 RFCは、ここで説明されている画像プロトコルの場合、以下のようなヘッダが役に立つ。
Accept-Ranges: bytes, tile-parts
【０１２９】
"Accept-Ranges: bytes"は、正当なHTTP/1.1コマンドである。一実施例において、サーバは、直接バイトレンジ要求に応答する能力を示すため、トランスポート・プロトコルでこれを使用する。このような場合、洗練されたクライアントは、コードストリーム又はファイルフォーマットの望ましい部分を正確に抽出する。
【０１３０】
"Accept-Ranges: tile-parts"の使用は、サーバがタイルパーツに対する直接要求に応答する能力を示すための一つの方法である。
Accept: image/jpeg2000;q=0.9 image/gif;q=0.5 image/jpipT2;q=0.95 image/jpipT3;q=0.1
尚、HTTPは、Acceptヘッダ内で能力を示すだけではなく、優先度を示す。画像をトランスコードする能力を備えたJPEG 2000画像サーバは、クライアントとサーバの両方が最高優先度でサポートするタイプのビューポート要求を返す。或いは、サーバは、より優先度の低いタイプを返すことに決定してもよい。なぜならば、その方がサーバに対する負荷が軽いからである（例えば、サーバは、サーバの負荷が高い場合には、伸長及び再圧縮を必要としないタイプを返すかもしれない。）。或いは、サーバは、最終的に、多数の要求によって帯域幅が低下するかもしれない。
Allow: GET, HEAD, POST, OPTIONS, TRACE
【０１３１】
このHTTPラインは、サーバが許可するコマンドを示す。これらのコマンドは、今まで使用されていたのと同じように画像サーバで使用される。
Vary: accept, *
【０１３２】
Varyヘッダは、応答が、クライアントが許容することを示すリターンタイプに依存することを示す。"*"は、応答がhttpヘッダ以外のものに依存するかもしれないことを示す。ここで説明しているプロトコルを使用するシステムにおけるサーバにおいて、返却される正確な内容は、前の要求に依存するかもしれない。例えば、サーバは、既にクライアントが保有していることを確信するタイルパーツを返さない。これは、HTTPプロキシを実現するために重要である。なぜならば、返却されたデータは、同じタイルパーツの組をもたないクライアントからの等価的な要求に対して優れたデータではない可能性があるからである。
【０１３３】
〔画像の一意識別〕
HTTPは、リソースを一意に識別するメカニズムを備えていることに注意する必要がある。"Etag"は応答を一意に識別する（HTTP 1.1 RFC 2616[HTTP標準]のセクション14.19を参照。）。
【０１３４】
JPEG 2000パートＩは、UUIDボックスを識別する（ITU-T Rec. T.800|IS15444-1:2000, Information Technology _ JPEG 2000 imaging coding system: Core coding systemのセクションI.7.2を参照。）。ここで説明されるプロトコル要求シンタックスは、ボックスの返却を可能にさせ、このボックスは画像の一意性を判定するために要求され得る。
【０１３５】
"Expires"のようなHTTPヘッダを用いることにより、クライアントは、キャッシュされたデータが有効ではなくなるときを知ることができる。HTTP標準のセクション14.21を参照。
【０１３６】
〔サーバへの画像アップローディング〕
完全な画像は、HTTPメソッドPOSTを使用してアップロードできる。この場合、シンタックスは、他のファイルアップロードと全く同じようにみえる。トランスポート・プロトコルは、全タイルパーツのアップローディングを可能にさせる。この場合、ヘッダは、Tier２シンタックスを使用してアップロードされているタイルパーツがどのタイルパーツであるかを示す。クライアントは、アップロードされたタイル毎にすべてのタイルパーツを与える。サーバは、アップロードされたタイルのすべてのタイルパーツを削除し、新しいタイルパーツを格納する。サーバは、元のファイルの順序とは異なる順序でタイルパーツを格納するように選択する。更に、TLMを更新しなければならない。サーバは、PPMマーカー・セグメントを使用して画像を更新することを拒絶するように選択してもよい。勿論、サーバは、画像又はタイルパーツを全くアップロードしないように選択してもよい。一部のサーバは、HTTPメソッドDELETEをサポートすることを選択する。このメソッドの場合、JPEG2000画像に対して特別なシンタックスは要求されない。
【０１３７】
〔その他の能力〕
１回の要求の後に画像を返す能力は有用である。最も顕著な例は、インライン形イメージを含むウェブページである。画像タグは、画像の返却を可能にさせる。ウェブページの作成者は、組み込まれる画像と、ページのレイアウトについての知識があり、URLを設定しているので、おそらく、サーバの能力についても知っているであろう。「キャパビリティ交換(exchange capabilities）」と画像獲得の必要性はない。
【０１３８】
一実施例において、ブラウザがJPEG 2000画像を理解できるようにするため、個々で説明しているプロトコルは、
<img src="http://truew.crc.ricoh.com/name.jp2?res=2" width="128" height="115">
のような呼び出しをサポートする。このコールは、低解像度部分を含むjp2ファイルを返す。一実施例において、ブラウザは、JPEG画像及びGIF画像のように、作成者が望む128×115のウィンドウに巧く収まるように画像を拡大縮小する。
【０１３９】
すべてのブラウザが画像を読み取れることを保証するため、画像タグは、画像がPNG（或いは、GIF若しくはJPEG）に変換されることを要求できる。
<img src="http://truew.crc.ricoh.com/name.jp2?res=2&tier3=PNG" width="128" height="115">
【０１４０】
サーバがJP2ファイルにアクセスし続けるとしても、配信する前に変換されるであろう。
【０１４１】
〔拡張／代案〕
〔タイルパーツ「オンザフライ」を書き換えるためにPOCマーカーを使用〕
一実施例では、ここで説明するプロトコルは、サーバに現れるようなタイルパーツだけに役立つ。異なる領域をバラバラの順序でアクセスしてもよいが、すべてのタイルパーツは順番にアクセスされる。そのため、クライアントがコンポーネント２にアクセスすることを望み、コンポーネント０及び１が最初にタイルパーツに格納されるならば、すべての典型的なプログレッション順の場合と同様に、要求されていないデータが送信される。
【０１４２】
しかし、代替実施例では、サーバは、クライアントによって要求された順序通りになるように、タイル内でタイルパーツを再配置することができる。一実施例では、サーバは、解像度、レイヤ、及び、タイルパーツに格納されたコンポーネントを指定するため、各タイルパーツに関してJPEG2000標準のPOCマーカーを使用する。これは、サーバ側でのバッファリングを要求する。キャッシングの方がより一層難しい。なぜならば、サーバは、コードストリームが並べ替えられた状況を把握しているからである。一実施例では、これは、要求コマンドを追跡することによって行われる。一実施例において、サーバは、要求及び応答を行うため、内部データ構造を使用する。一実施例では、サーバは、クライアントが要求した順序でファイルのコピーを書き込む。
【０１４３】
サーバが、各解像度について１個ずつのタイルパーツがRLCP順に並べられている３コンポーネントJPEG2000ファイルを格納している場合を考える。さらに、一つのタイルパーツに関して１個のレイヤと１個のプリーシンクトだけが存在すると仮定する。このとき、タイルパーツデータは、
SOT marker segment(Tile 0, Length of tile-part, Part 0, Number of Part 0)
SOD marker
Packet Header/Body of Resolution 0, Layer 0, Component 0, Position 0(R0L0C0P0)
Packet Header/Body of R0L0C1P0
Packet Header/Body for R0L0C2P0
のように見えるであろう。
【０１４４】
クライアントが最初のコンポーネント（番号０）だけを要求する場合、サーバは、コンポーネント１及び２からのデータを含むすべてのタイルパーツを送信する。これは、望んでいないコンポーネントに対するデータが大量である場合には、非効率的である。そこで、サーバは、最初のコンポーネントだけを収容するファイルには実際に現れないタイルパーツを作成し、クライアントへ送信する。メインヘッダは、ファイル内に2個以上のコンポーネントが存在することを示すので、サーバは、このタイルパーツが１個のコンポーネントしか含まないことを示す。サーバは、数通りの方法を用いて、状況の順番を変えるためにファイルを変更することができる。
【０１４５】
プログレッション順は、CPRLに変更してもよく、クライアントは、最初にコンポーネント０が現れることを予想する。これは、クライアントが最初にコンポーネント２ではなく、コンポーネント０を要求する場合に機能する。
【０１４６】
他のコンポーネントに対するパケットは、零データを保有するように変更できる。これは、他のコンポーネントに対するデータが後のパケットまで現れないようにレイヤ割り当てを変更することと等価的である。しかし、プレースホルダーとしての役割を果たすためには、スキップされたパケット毎に１バイトパケットヘッダを組み込むことが依然として必要である。更に、他のコンポーネントからのデータが要求されるとき、パケットヘッダは、正しいレイヤ情報を組み込むために書き込まれなければならない。
【０１４７】
一実施例において、POCマーカー・セグメントは、タイルパーツヘッダに収容される。タイルパーツは、
SOT marker segment(Tile 0, Length of tile-part, Part 0, Number of Part 0)
POC marker segment(Resolution start=0, Component start=0, layer end=1, resolution end=1, component end=1)
SOD marker
Packet Header/Body of Resolution 0, Layer 0, Component 0, Position 0(R0L0C0P0)
のように表される。
【０１４８】
このタイルパーツは、要求されたデータだけを格納する。更なる要求によって、新しいタイルパーツが生成され、新しいタイルパーツは、要求されたデータだけを格納する新しいPOCマーカーを含む。
【０１４９】
パケット自体は変更する必要がなく、パケットを送信する順序だけが変更される。
【０１５０】
いずれにしても、この技術の一つの重要な利点は、クライアントが、受信したコードストリームの部分を追跡するための補助的な構造を用いることなく、常に正当なJPEG2000ファイルを保有し続けることである。
【０１５１】
〔補助的な用途の場合：メモリもデコーダも無いクライアント〕
非常に簡単なクライアントは、クライアントの表示エリアよりも少ないメモリしか備えていないにもかかわらず、非常に大きい画像をブラウズすることを望む場合がある。圧縮画像データをキャッシュすることは期待できない。クライアントはJPEG2000デコーダを具備しない場合もある。しかし、このクライアントは、JPEG2000サーバと通信し、Tier3要求を作成し、Tier3応答を受信することが可能である。
【０１５２】
〔典型的なコンピュータシステム〕
図８は、上記の一つ以上の動作を実行する典型的なコンピュータシステムのブロック図である。図８によると、コンピュータシステム８００は、典型的なクライアント若しくはサーバを構成する。コンピュータシステム８００は、情報を通信する通信メカニズム若しくはバス８１１と、バス８１１に接続され情報を処理するプロセッサ８１２と、を含む。プロセッサ８１２は、例えば、Pentium（登録商標）、PowerPC（登録商標）、Alpha（登録商標）などのマイクロプロセッサを含むが、これらのマイクロプロセッサには限定されない。
【０１５３】
システム８００は、バス８１１に接続され、情報を記憶し、プロセッサ８１２によって実行される命令を記憶するランダム・アクセス・メモリ（ＲＡＭ）、若しくは、ダイナミック記憶装置８０４（メインメモリと呼ばれる）を更に含む。メインメモリ８０４は、プロセッサ８１２による命令の実行中に、一時的な変数、若しくは、他の中間情報を記憶するためにも使用される。
【０１５４】
コンピュータシステム８００は、バス８１１に接続され、プロセッサ８１２のための静的情報及び命令を記憶するリード・オンリー・メモリ（ＲＯＭ）及び／又はその他のスタティック記憶装置８０６と、磁気ディスク若しくは光ディスク及び対応したディスクトドライブを備えたデータ記憶装置８０７と、を更に含む。データ記憶装置８０７は、バス８１１に接続され、情報と命令を記憶する。
【０１５５】
コンピュータシステム８００は、バス８１１に接続され、情報をコンピュータのユーザへ提示する陰極線管（ＣＲＴ）若しくは液晶ディスプレイ（ＬＣＤ）のような表示装置８２１に接続される。英数字キー及びその他のキーを備えた英数字入力装置８２２もバス８１１に接続され、情報及びコマンド選択をプロセッサ８１２へ通知する。補助的なユーザ入力装置は、マウス、トラックボール、トラックパッド、スタイラス、或いは、カーソル方向キーのようなカーソル制御装置８２３であり、バス８１１に接続され、方向情報及びコマンド選択をプロセッサ８１２へ通知し、表示装置８２１上のカーソルの動きを制御する。
【０１５６】
バス８１１に接続され得るその他の装置には、命令、データ、若しくは、その他の情報を、紙、フィルム、若しくは、類似したタイプの媒体などのような媒体に印刷するため使用されるハードコピー装置８２４が含まれる。更に、スピーカー及び／又はマイクロホンのような音声記録及び再生装置がバス８１１に接続され、コンピュータシステム８００との間で音声インタフェースを実現する場合もある。バス８１１に接続できる他の装置には、電話機、又は、ハンドヘルド型の手のひらサイズの装置若しくはコンピュータやサーバと通信する有線／無線通信設備８２５が含まれる。
【０１５７】
バスに接続できる別の装置は、例えば、デジタル信号プロセッサ（ＤＳＰ）若しくは特殊な圧縮（及び／又は伸長）ハードウェアを構成するコ・プロセッサ８３５である。
【０１５８】
システム８００と関連したハードウェアの一部若しくは全部が本発明で使用される。しかし、他のコンピュータシステムのコンフィギュレーションでも、一部若しくは全部の装置を収容できることが明らかである。
【０１５９】
上述の説明では、種々の特定の細部が本発明の全体の理解が得られるように解説されている。当業者に明らかであるように、本発明は、これらの特定の細部を用いることなく実施できる。別の例では、構造及び装置は、本発明がわかり難くなることを避けるためブロック図の形式で示されている。
【０１６０】
以下の詳細な説明の一部は、コンピュータメモリ内のデータビットに関する演算のアルゴリズム及び記号表現の形で与えられている。これらのアルゴリズム記述及び表現は、データ処理技術の当業者が自分の業績の要旨を他の当業者にできるだけ効率的に伝達するため使用する手段である。本明細書において、並びに、一般的に、アルゴリズムは、希望の結果を生ずる首尾一貫したステップ（手順）の系列であると考えられる。ステップは、物理量の物理的な操作を必要とする。通常、必須的ではないが、これらの量は、記憶、転送、合成、比較及びその他の操作を加えることができる電気信号若しくは磁気信号の形式をとる。主として慣用されているという理由から、これらの信号は、ビット、値、エレメント、シンボル、文字、項、数などのように呼ばれる。
【０１６１】
しかし、これらのすべての用語、並びに、類似した用語は、適切な物理量と関連付けられるべきであり、これらの量に適用された便利なラベルに過ぎない。特に断らない限り、以下の説明から明らかであるように、説明全体を通じて、「処理」、「コンピューティング」、「計算」、「決定」、「表示」などのような用語を利用する議論は、コンピュータシステム、若しくは、類似した電子コンピューティング装置の動作及び処理について言及するものであり、コンピュータシステムは、コンピュータシステムのレジスタ及びメモリ内で物理（電子的）量として表現されたデータを操作し、コンピュータシステムのメモリ若しくはレジスタ、或いは、他のこのような情報記憶装置、伝送装置又は表示装置内で物理量として同じように表現された他のデータに変換する。
【０１６２】
本発明は、上記の演算を実行する装置にも関する。この装置は、要求された目的のため特別に構築されるか、或いは、コンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ状態にされるか、又は、再構築される汎用コンピュータを具備する。このようなコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に保持される。コンピュータ読み取り可能な記録媒体の例には、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスクなどの任意のタイプのディスクと、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード若しくは光カード、或いは、電子命令を記憶するために好適である任意のタイプの媒体が含まれるが、これらの例に限定されるものではない。各媒体はコンピュータシステムのバスに接続される。
【０１６３】
以下の説明におけるアルゴリズム及びディスプレイは、特定のコンピュータ若しくはその他の装置に本来的に関連付けられていない。多様な汎用システムが、上記の教示に従うプログラムと共に使用され、或いは、要求された方法の手順を実行するために、より特殊化された装置を構築する方が好都合であることが判明することもある。これらの多様なシステムのため要求される構造は、上記の説明から明らかになるであろう。更に、本発明は、特定のプログラミング言語に関しては説明されていない。上述の本発明の教示を実施するため、種々のプログラミング言語が使用される。
【０１６４】
機械読み取り可能な媒体は、機械（たとえば、コンピュータ）によって読み取り可能な形式で情報を記憶若しくは伝送する任意のメカニズムを含む。たとえば、機械読み取り可能な媒体は、読み出し専用メモリ（ＲＯＭ）と、ランダム・アクセス・メモリ（ＲＡＭ）と、磁気ディスク記憶媒体と、光記憶媒体と、フラッシュメモリ装置と、電気的、光学的、音響的若しくはその他の形式の伝搬信号（たとえば、搬送波、赤外線信号、デジタル信号など）と、を含む。
【０１６５】
以上の説明から分かるように、本発明の多数の代替例及び変形例は当業者にとって明白であり、例示的に説明され図示された特定の実施例は本発明を限定することを意図したものではないことが理解されるべきである。したがって、様々な実施例の細部に関する記述は、本発明に不可欠であると考えられる事項のみが記載されている請求項に係る発明の範囲を限定するものではない。
【０１６６】
【発明の効果】
本発明によれば、効率的な画像通信が実現される。
【図面の簡単な説明】
【図１】簡単な画像アクセスの説明図である。
【図２】典型的なソフトウェア構造の説明図である。
【図３】クライアントとサーバの区分の例の説明図である。
【図４】クライアントとサーバの区分の例の説明図である。
【図５】クライアントとサーバの区分の例の説明図である。
【図６】クライアントとサーバの区分の例の説明図である。
【図７】クライアントとサーバの区分の例の説明図である。
【図８】コンピュータシステムの一実施例の構成図である。
【図９】ビューポート質問パラメータとＳＩＺマーカー・セグメント・パラメータの間の対応関係の説明図である。
【符号の説明】
２００ アプリケーション
２０１ 第１ステージ
２０２ 第２ステージ
２０３ 第３ステージ
２０４ 第４ステージ
２０５ ファイルシステム、オンザフライ画像発生器又はバイトレンジサーバ
８０４ メインメモリ
８０６ スタティック・メモリ
８０７ 大容量メモリ
８１１ バス
８１２ プロセッサ
８２１ 表示装置
８２２ キーボード
８２３ カーソル制御装置
８２４ ハードコピー装置
８２５ 無線／電話インタフェース
８３５ コ・プロセッサ
Claims (10)
- クライアントとサーバとから構成されるシステムであって、
前記クライアントは、
ディスプレイと、
画像データの部分である所望の領域を表示する要求を受付けると、当該所望の領域の画像オブジェクトを要求するビューポート要求をサーバに送信し、サーバからビューポート要求への応答としての画像オブジェクトを受信して、当該受信した画像オブジェクトを前記ディスプレイに表示するアプリケーションを実行するプロセッサとを備え、
前記サーバは、
画像データが構造的に圧縮されたＪＰＥＧ２０００コードストリームを格納する第１の記憶手段と、
前記ＪＰＥＧ２０００コードストリームを構成する複数のタイルと各々の前記タイルが前記クライアントに送信済みか否かを示すビットとを対応付けた、タイルパーツに関する情報を記憶する第２の記憶手段と、
前記クライアントから、前記ビューポート要求を受信し、該ビューポート要求が要求する画像データの所望の領域が前記ＪＰＥＧ２０００コードストリームのどのタイルを要求するものであるかを特定し、該特定されたタイルのうち前記タイルパーツに関する情報に基づいて前記クライアントに送信済みではないタイルを特定するビューポート−Ｊ２Ｋマッパーと、
前記ビューポート−Ｊ２Ｋマッパーにて前記ビューポート要求パラメータによって前記クライアントに送信済みではないと特定されたタイルのみを前記ＪＰＥＧ２０００ファイルから抽出するＪ２Ｋ−バイトレンジコンバータと、
前記Ｊ２Ｋ−バイトレンジコンバータによって抽出されたタイルパーツを受け取り、該タイルパーツを伸張して画像オブジェクトを生成する伸張器と、
前記伸張器にて伸張して生成された画像オブジェクトを前記ビューポート要求への応答として前記クライアントに送信する手段と、
を備えることを特徴とするシステム。 - 前記ビューポート要求は、前記画像データのファイル名と、所望の領域を指定するパラメータと、所望の領域の解像度を指定するパラメータと、所望の領域の品質を指定するパラメータと、を少なくとも含むことを特徴とする請求項１に記載のシステム。
- 前記所望の領域を指定するパラメータは、前記所望の領域の画像データへの水平オフセットおよび垂直オフセットと、前記所望の領域の高さおよび幅と、を含むことを特徴とする請求項２に記載のシステム。
- 前記ビューポート−Ｊ２Ｋマッパーは、
前記ビューポート要求が含む所望の領域を指定するパラメータに基づき、前記所望の領域を基準グリッド単位に変換して当該所望の領域と交差するタイルを判定し、当該判定結果と前記ビューポート要求が含む所望の領域の解像度を指定するパラメータおよび所望の領域の品質を指定するパラメータとに基づいて、前記ビューポート要求が前記ＪＰＥＧ２０００コードストリームのどのタイルを要求するものであるかを特定すること、
を特徴とする請求項２又は３に記載のシステム。 - 前記ビューポート要求およびビューポート要求への応答はＨＴＴＰプロトコルで行われることを特徴とする請求項１ないし４のいずれか１に記載のシステム。
- クライアントとサーバとから構成されるシステムで使用される方法であって、
前記クライアントのプロセッサでは、画像データの部分である所望の領域を表示する要 求を受付けると、当該所望の領域の画像オブジェクトを要求するビューポート要求をサーバに送信し、サーバからビューポート要求への応答としての画像オブジェクトを受信して、当該受信した画像オブジェクトを前記ディスプレイに表示するアプリケーションを実行するステップが行われ、
画像データが構造的に圧縮されたＪＰＥＧ２０００コードストリームを第１の記憶手段に格納するステップと、
前記ＪＰＥＧ２０００コードストリームを構成する複数のタイルと各々の前記タイルが前記クライアントに送信済みか否かを示すビットとを対応付けた、タイルパーツに関する情報を第２の記憶手段に格納するステップと、
前記クライアントから、前記ビューポート要求を受信し、該ビューポート要求が要求する画像データの所望の領域が前記ＪＰＥＧ２０００コードストリームのどのタイルを要求するものであるかを特定し、該特定されたタイルのうち前記タイルパーツに関する情報に基づいて前記クライアントに送信済みではないタイルをビューポート−Ｊ２Ｋマッパーで特定ステップと、
前記ビューポート−Ｊ２Ｋマッパーにて前記ビューポート要求パラメータによって前記クライアントに送信済みではないと特定されたタイルのみを前記ＪＰＥＧ２０００ファイルから、Ｊ２Ｋ−バイトレンジコンバータにより抽出するステップと、
前記Ｊ２Ｋ−バイトレンジコンバータによって抽出されたタイルパーツを受け取り、該タイルパーツを伸張して画像オブジェクトを伸張器で生成するステップと、
前記伸張器にて伸張して生成された画像オブジェクトを前記ビューポート要求への応答として前記クライアントに送信するステップとが前記サーバで行われるようにした方法。 - 前記ビューポート要求は、前記画像データのファイル名と、所望の領域を指定するパラメータと、所望の領域の解像度を指定するパラメータと、所望の領域の品質を指定するパラメータと、を少なくとも含むことを特徴とする請求項６に記載の方法。
- 前記所望の領域を指定するパラメータは、前記所望の領域の画像データへの水平オフセットおよび垂直オフセットと、前記所望の領域の高さおよび幅と、を含むことを特徴とする請求項７に記載の方法。
- 前記ビューポート−Ｊ２Ｋマッパーは、
前記ビューポート要求が含む所望の領域を指定するパラメータに基づき、前記所望の領域を基準グリッド単位に変換して当該所望の領域と交差するタイルを判定し、当該判定結果と前記ビューポート要求が含む所望の領域の解像度を指定するパラメータおよび所望の領域の品質を指定するパラメータとに基づいて、前記ビューポート要求が前記ＪＰＥＧ２０００コードストリームのどのタイルを要求するものであるかを特定すること、
を特徴とする請求項７又は８に記載の方法。 - 前記ビューポート要求およびビューポート要求への応答はＨＴＴＰプロトコルで行われることを特徴とする請求項６ないし９のいずれか１に記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US39337702A | 2002-07-03 | 2002-07-03 | |
| US10/273,734 US7734824B2 (en) | 2002-10-18 | 2002-10-18 | Transport of reversible and unreversible embedded wavelets |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004208266A JP2004208266A (ja) | 2004-07-22 |
| JP4086728B2 true JP4086728B2 (ja) | 2008-05-14 |
Family
ID=32829371
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003189575A Expired - Fee Related JP4086728B2 (ja) | 2002-07-03 | 2003-07-01 | 画像通信方法及びシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4086728B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2006046445A1 (ja) * | 2004-10-29 | 2008-05-22 | 松下電器産業株式会社 | ファイル転送システム、送信機器及び受信装置 |
| JP4530274B2 (ja) * | 2005-01-11 | 2010-08-25 | 株式会社リコー | 符号処理装置、符号処理方法、プログラム及び情報記録媒体 |
| JP4738869B2 (ja) | 2005-04-07 | 2011-08-03 | 株式会社リコー | 画像送信方法、画像送信プログラム、記録媒体及び画像送信装置 |
| JP4789192B2 (ja) * | 2006-04-12 | 2011-10-12 | 株式会社リコー | 符号処理装置、プログラム及び情報記録媒体 |
| KR101290275B1 (ko) | 2007-01-16 | 2013-08-07 | 삼성전자주식회사 | 그래픽 데이터 송수신 장치 및 방법 |
| JP4693803B2 (ja) | 2007-03-12 | 2011-06-01 | コニカミノルタビジネステクノロジーズ株式会社 | Ｈｔｔｐサーバ及びプログラム |
| JP2009147668A (ja) * | 2007-12-14 | 2009-07-02 | Murata Mach Ltd | 画像形成装置 |
| JP5167944B2 (ja) * | 2008-05-15 | 2013-03-21 | 株式会社リコー | 情報処理装置、情報処理方法、プログラム及び記録媒体 |
-
2003
- 2003-07-01 JP JP2003189575A patent/JP4086728B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004208266A (ja) | 2004-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7734824B2 (en) | Transport of reversible and unreversible embedded wavelets | |
| JP4709493B2 (ja) | 圧縮されたディジタル画像を通信する方法及び製造物 | |
| Taubman et al. | Architecture, philosophy, and performance of JPIP: Internet protocol standard for JPEG 2000 | |
| US7149370B2 (en) | Method and device for image surfing | |
| US9749713B2 (en) | Budget encoding | |
| JP5785582B2 (ja) | メディアデータ送信方法及び装置 | |
| US7460724B2 (en) | JPP-stream to JPEG 2000 codestream conversion | |
| US8209375B2 (en) | Communication of compressed digital images with restricted access and server/client hand-offs | |
| US20050123042A1 (en) | Moving picture streaming file, method and system for moving picture streaming service of mobile communication terminal | |
| US7260614B2 (en) | Methods and systems for scalable streaming of images with client-side control | |
| GB2571364A (en) | Method, device, and computer program for transmitting portions of encapsulated media content | |
| GB2583885A (en) | Method, device, and computer program for improving transmission of encoded media data | |
| JP4086728B2 (ja) | 画像通信方法及びシステム | |
| JP2009017527A (ja) | サーバにより駆動されるプログレッシブ画像伝送方法およびシステム | |
| US20020059458A1 (en) | Methods and systems for scalable streaming of images with server-side control | |
| JP2006295886A (ja) | 画像処理システム、プログラムおよび記録媒体 | |
| JP2005086362A (ja) | データ多重化方法、データ送信方法およびデータ受信方法 | |
| EP1076459A2 (en) | Data transfer system and method | |
| Hara | An implementation of JPEG 2000 interactive image communication system | |
| Chi et al. | Pervasive web content delivery with efficient data reuse | |
| JP2006339972A (ja) | 画像処理装置及びその制御方法、コンピュータプログラム、記憶媒体 | |
| WO2022189700A2 (en) | Timed media http request aggregation | |
| Huseby | Video on the World Wide Web: accessing video from WWW browsers | |
| Prandolini | JPIP–interactivity tools, APIs, and protocols (part 9) | |
| Ortiz | Interactive Browsing of Remote JPEG 2000 Images |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060417 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071113 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080111 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080212 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080219 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140228 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |