JP2004208266A - Picture communication method and system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method and an apparatus for transporting a part of codestream via a communication mechanism. <P>SOLUTION: In one embodiment, the method comprises sending a request via a network and receiving tile-parts of a JPEG 2000 compliant codestream from the network as a return type as a part of a response to the request. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

尚、これらのパラメータのすべてが必要というわけではない。一部のパラメータは、デフォルト値を取り、例えば、デフォルトですべてのコンポーネントは、画像にマッチする領域に関して送信される。一実施例では、それらをすべて省略してもよく、デフォルト値が使用される。
【００６０】
〔パラメータの説明〕
パラメータｘｏ、ｙｏ、ｗ及びｈは、画像の領域を指定する。０は左上の端を表し、１は右下を表す。幅及び高さは画像の画分を指定し、１は全高若しくは全幅を表す。かくして、一実施例において、ｘｏ＝０＆ｙｏ＝０＆ｗ＝１＆ｈ＝１は、画像の全体（デフォルト）を指定する。これに対して、画像の中央セクションは、ｘｏ＝０．２５＆ｙｏ＝０．２５＆ｗ＝０．５＆ｈ＝０．５によって与えられる。左端は、基準グリッド上のＸＯｓｉｚの位置に存在し、上端は、ＹＯｓｉｚの位置に存在するものとする。図９と、パート１の付録ＡにおけるＳＩＺマーカーの定義［ＩＴＵ−Ｔ Ｒｅｃ． Ｔ．８００｜ＩＳ １５４４４−１：２０００、Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ ＿ ＪＰＥＧ ２０００ ｉｍａｇｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ： Ｃｏｒｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ］を参照のこと。
【００６１】
パラメータｒｅｓは、画像を縮小するための解像度の数である。ｒｅｓ＝１は、画像を水平方向並びに垂直方向に約２倍の倍率で縮小する。この縮小は、ＪＰＥＧ２０００の様式で行われるので、画像７のグリッド点の幅は、ＳＩＺマーカーのオフセットの値に依存して、４サンプル若しくは３サンプルの幅に縮小される。
【００６２】
パラメータｍａｘｗ及びｍａｘｈは、クライアントが受信することに関心をもっているサンプルの最大個数を指定する。これは、「ｒｅｓ＝」パラメータを使用して縮小の量を指定することの代わりである。例えば、原画像のサイズを知らないクライアントは、１２８サンプルを含む最大高若しくは最大幅の画像を要求する。サーバは解像度を低下させる。サーバは、要求が満たされるまで、或いは、ＬＬサブバンドだけが返されるまで、解像度を低下させる。かくして、ウェーブレット変換の零レベルが圧縮の際に利用されているならば、１２８×１２８の最大画像の要求は５１２×５１２の画像を返し続ける可能性がある（しかし、起こりそうにない。）。
【００６３】
コンポーネント・パラメータは、どのコンポーネントを組み込むかを指定する文字列である。一実施例において、コンポーネントは、零から番号が付けられる。レンジを使用してもよい。かくして、コンポーネント＝０−２、５は、例えば、コンポーネント０、１、２及び５を返す。
【００６４】
品質パラメータは、サーバが送信すべきデータの量を決定するために役立つ。サーバは、返却するレイヤの数として、品質値を使用することを選んでもよい。一実施例において、品質に関する０ｘＦＦＦＦの要求は、領域内のタイルパーツについてサーバが保有するすべてのデータを要求することである。
【００６５】
表２には、応答の他の面を制御するため、問い合わせと共に使用される補助的なパラメータの組が掲載されている。第３ティアー値は、”ｐｎｇ”若しくはＤＣＴベースのＪＰＥＧフォーマットの完全な画像として応答を要求する。
【００６６】
【表２】

ボックスパラメータは、クライアントが着目しているボックスのリストを指定するための一方法である。ボックスは、ＪＰＥＧ２０００パート１、パート２、パート３及びパート６において様々のＪＰＥＧ２０００ファイルフォーマットに対して規定されている。これらは、コードストリームの一番上のレベルにある。ボックスの内部のボックスは、スーパーボックス及びサブボックスをリストにすることによって要求される。複数のボックスの場合、サーバは、そのタイプのすべてのボックスを返却するか、若しくは、そのタイプの最初のボックスだけを返却するかを選択する。ボックスのレンジは、括弧を用いて指定される。［０−］という形式のレンジは、サーバがこのタイプのすべてのボックスを返却することを保証する。
【００６７】
最大ボックスサイズパラメータは、指定されたバイト数に満たないすべてのボックスを返却させることができる。これにより、通信が非常に遅くならない限り、存在するであろうすべてのボックスを獲得できるようになる。
【００６８】
尚、許容可能なセットの範囲外の文字を使用するタイプのボックスは、ＵＲＬ符号化される。ＵＲＬ符号化に関する更なる情報は、ＲＦＣ ２３９６のＨＴＴＰ ｒｆｃ［ＨＴＴＰ標準］を参照せよ。
【００６９】
ボックスもノットボックスもリストに掲載されていない場合、サーバは、返却すべきボックスを決定する。一実施例では、サーバは、すべてのボックスを返却すること、コードストリームより前のすべてのボックスを返却すること、画像をサーバに蓄積するときに画像の作成者が指定したすべてのボックスを返却すること、或いは、全くボックスを返却しないこと、を決定する。一実施例では、サーバのコンフィギュレーション・ファイルは、これらのオプションの任意の部分若しくは全部を許可する。コードストリームの一部分は、Ｎｏｔｂｏｘｅｓ＝ｊｐ２ｃではない限り返却される。
【００７０】
要求パラメータ、値のペア、及び、それらの意味の例は以下の通りである。
ｂｏｘｅｓ＝ｊｐ２ｈ
ｇｅｔ ｔｈｅ ＪＰ２ Ｈｅａｓｅｒ ｂｏｘ．
ｂｏｘｅｓ＝ｊｐ２ｈ／ｉｈｄｒ
ｇｅｔ ｏｎｌｙ ｔｈｅ Ｉｍａｇｅ Ｈｅａｄｅｒ ｂｏｘ ｗｉｔｈｉｎ ｔｈｅ ＪＰ２ Ｈｅａｄｅｒ ｂｏｘ
ｂｏｘｅｓ＝ｕｕｉｄ［５−７］
ｇｅｔ ｔｈｅ ５^ｔｈ ６^ｔｈ， ａｎｄ ７^ｔｈ ＵＵＩＤ ｂｏｘｅｓ （ｉｆ ｔｈｅｙ ｅｘｉｓｔｓ）．
ｍａｘｂｏｘｓｉｚｅ＝４０９６
ｒｅｔｕｒｎ ｂｏｘｅｓ ４０９６ ｂｙｔｅｓ ｏｒ ｓｍａｌｌｅｒ
【００７１】
優先順位パラメータは、ある要求の他の要求に対する重要度を示す。新しい優先順位が前の優先順位と一致する場合、サーバは、新しい要求に関しても有効であるならば、旧い要求に関するバイトを送信し続ける。新優先順位と旧優先順位の差が１以上であるならば、サーバは、次の機会に旧い要求を停止し、新しい要求を開始する。優先順位が”Ｉｎｆ”である場合、サーバは新しい要求のために旧い要求を止める。サーバは、現在の要求に適用されるデータを送信し終えたとき、以前に中断された要求に関するデータを後で送信するように選択してもよい。
【００７２】
〔第３ティアーのための補助的なＨＴＴＰヘッダライン〕
次の表３には、クライアント側で利用可能なデータを指定するため使用可能な二つのヘッダラインが示されている。
【００７３】
【表３】

Ｔ３キャッシュ（Ｔ３ｃａｃｈｅ）は、クライアントが現在のセッション又は前のセッションで既に受信した領域を指定できるようにする。サーバは、要求に対して送信されたタイルパーツが再度送信されることがないようにタイルパーツを計算するため、このＴ３キャッシュを使用する。サーバはこのパラメータを無視してもよい。例えば、認識する能力に欠けるサーバは、このパラメータを無視するであろう。
例：
Ｔ３ｃｈａｃｈｅ： ｘｏ＝０．０＆ｙｏ＝０．０＆ｗ＝０．２５＆ｈ＝０．２５＆ｒｅｓ＝２
Ｔ３ｃｈａｃｈｅ： ｍａｘｗ＝１２８＆ｍａｘｈ＝１２８
【００７４】
尚、キャッシュの内容は、先行のビューポート要求への応答である。一実施例では、一つのＴ３キャッシュライン当たりに一つの要求が存在する。この要求は、問い合わせ文字列の一部としては送信されないが、ＨＴＴＰヘッダラインとして送信される。Ｔ３キャッシュが使用されているならば、メインヘッダは受信されている、と考えられる。クライアントは、キャッシュされたすべての要求のリストを作成しなければならないわけではない。実際上、クライアントは、受信された各要求をリストに掲載し、このラインをアクノリッジとして使用する。サーバは、前の要求をタイルパーツのリストに翻訳し、これらのタイルを送信済みとしてマークすることができる。したがって、これらのタイルパーツは、現在の要求が翻訳されるときに、再送信されない。
【００７５】
Ｔ２キャッシュは、クライアントが受信されたタイルパーツのリストを作成できるようにする。シンタックスは次のように定義される。これは、タイルパーツを要求する典型的な方法に対応する。ここでも一実施例では、このラインは、問い合わせ文字列の一部分ではなく、ＨＴＴＰヘッダラインである。一例は、次の通りである。
Ｔ２ｃａｃｈｅ： ４．０， ４．１， ５．０−６．２
【００７６】
〔第２ティアー要求〕
第２ティアーは、第３ティアーと同じようにボックスに対する要求をサポートする。タイルパーツは、ＨＴＴＰレンジヘッダを用いて明示的に要求され得る。タイルパーツに対する第２ティアー要求の効率的な用法は、符号化データのタイルパーツへのある分割に同意したクライアントとサーバに依存する。タイルは、あらゆる解像度若しくはあらゆるレイヤで、或いは、その他の方法でタイルパーツに分割しなければならない。一つの有効な分割法を次に詳しく説明する。第２ティアーの要求の例は、次の通りである。
ＧＥＴ ｆｉｌｅ．ｊｐ２ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
Ｒａｎｇｅ： ｔｉｌｅｓ−ｐａｒｔｓ＝４．０， ５．０， ８．０−９．２
ＣＲＬＦ
【００７７】
ピリオドの前の値はタイル番号であり、ピリオドの後の値はタイルパーツ番号である。ＪＰＥＧ２０００パート１の付録ＡからのＩｓｏｔ及びＴＰｓｏｔを参照のこと（文献：ＩＴＵ−Ｔ Ｒｅｃ． Ｔ．８００｜ＩＳ １５４４４−１：２０００， Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ ＿ ＪＰＥＧ ２０００ ｉｍａｇｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ： Ｃｏｒｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ）。尚、一実施例では、タイル番号及びタイルパーツ番号は、どちらも０から番号を付けられる。タイルパーツのレンジは、スタートタイルからストップタイルまでのすべてのタイルと、スタートからストップまでのこれらのタイルに関するすべての部分と、を含む。例えば、８．０−９．２は、８．０、８．１、８．２、９．０、９．１、９．２と等価的である。
【００７８】
一実施例では、タイルパーツは２個のパラメータ（タイルに対するＩｓｏｔと部分に対するＴＰｓｏｔ）をもつので、１次元のレンジのため設計された”Ｒａｎｇｅｓ”の代わりに、新しいＨＴＴＰヘッダラインを使用する方がよい。例えば、”Ｔｉｌｅ−ｐａｒｔ：”ヘッダは、
Ｔｉｌｅ−ｐａｒｔｓ： ８．０， ．８．１， １０．０−１２．２
のように使用される。
【００７９】
〔第１ティアー要求シンタックス〕
第１ティアーの要求は、ＨＴＴＰ（ＨＴＴＰ標準）に規定されているように厳格なバイトレンジ要求である。例えば、
ＧＥＴ ｆｉｌｅ ．ｊｐ２ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｈｏ．ｃｏｍ
Ｒａｎｇｅ： ｂｙｔｅｓ＝２００−５００， １０００−１５００
ＣＲＬＦ
である。
【００８０】
上述の通り、要求は、位置２００で始まる３００バイトと、位置１０００で始める５００バイトである。このような要求は、典型的に、クライアントが所定のバイトレンジで期待すべきものを知っている場合に限り有効である。しかし、これらの要求は、例えば、画像に関連付けられたオーディオ・ストリームの全体を転送することなく、オーディオ・ストリームの一部分にアクセスするために有効である。
【００８１】
一実施例では、別々のラインでキャッシュ情報のリストを作成するのではなく、クライアントは、キャッシュ情報をＨＴＴＰ問い合わせ文字列自体に組み入れることが可能である。例えば、ユーザが、以下の問い合わせ文字列：
ＧＥＴ ｆｉｌｅｎａｍｅ．ｊｐ２？ｘｏ＝０．０＆Ｙｏ＝０．０＆ｗ＝０．２５＆ｈ＝０．２５＆ｒｅｓ＝２＆ｍａｘｘ＝７５０＆ｍａｘｙ＝７５０ ＨＴＴＰ／１．１
を入力する場合を考える。
【００８２】
クライアントは、第２ステージ（ビューポート・ツー・ＪＰＥＧ２０００マッパー）で説明したようにサーバ側のファイルを解析したのと同様に、キャッシュ内のファイルを解析する。クライアントは、既にキャッシュ内に保有するタイルパーツのリストを形成し、サーバへ送信する前に問い合わせ文字列に付加する。したがって、サーバは、問い合わせ文字列：
ＧＥＴ ｆｉｌｅｎａｍｅ．ｊｐ２ｘｏ＝０．０＆ｙｏ＝０．０＆ｗ＝０．２５＆ｈ＝０．２５＆ｒｅｓ＝２＆ｍａｘｘ＝７５０＆ｍａｘｙ＝７５０＆Ｔ２ｃａｃｈｅ＝４．０， ５．０， ８．０， ８．１， ８．２， ８．３， ９．０， ９．１， ９．２， ９．３ ＨＴＴＰ／１．１
を取得する。
【００８３】
勿論、様々なシンタックスがビューポートを指定するため使用され得る。ＪＰＥＧ２００パート９標準の最新版は、以下のシンタックスに類似したシンタックスを使用する。殆どのパラメータは、当業者が要求シンタックスの様々なタイプの間で翻訳できる。
【００８４】
【表４】

〔パラメータの説明〕
パラメータＯｆｆｓｅｔ＝Ｐｘ，Ｐｙ及びＳｉｚｅ＝Ｓｘ，Ｓｙは、左端のＰｘサンプルから始まり、右側へサンプルＰｘ個分だけ拡がり、一番上のＰｙサンプルから始まり、下方へサンプルＰｙ個分だけ拡がる画像の領域を指定する。左端は基準グリッドのＸＯｓｉｚの位置にあり、一番上はＹＯｓｉｚの位置にある場合を考える。ＳＩＺマーカー・セグメントの定義については、ＪＰＥＧ２０００パート１の付録Ａを参照のこと。これらのサンプルは、フレームサイズパラメータによって指定された解像度である。
【００８５】
パラメータＦｒａｍｅ−ｓｉｚｅ＝Ｒｘ，Ｒｙは、クライアントが画像を見ることを望む解像度である。Ｒｘ及びＲｙは、０から画像の寸法まで変化する。しかし、ＪＰＥＧ２０００のドメインでは、復号化された画像は、有限のレベルの解像度でしか見ることができない。そのため、クライアントの要求に応じて、サーバは、Ｒ’ｘ≧Ｒｘ並びにＲ’ｙ≧Ｒｙとなるような解像度Ｒ’ｘ及びＲ’ｙを送信する。Ｒ’ｘ及びＲ’ｙがＲｘ及びＲｙとは異なる場合、サーバはこの情報をヘッダで送信する必要がある。ＪＰＥＧ２０００パート１に記載されているように、解像度低下画像は、正確な位置に応じて、左端（左縁）と右端（右縁）で丸められる。例えば、画像７グリッド点幅は、ＳＩＺマーカーのオフセットの値に依存して、４サンプル分若しくは３サンプル分だけ幅が縮小する。
【００８６】
Ｒ’ｘ及びＲ’ｙに依存して、要求された領域の左上隅のオフセット、幅、及び、高さは、
Ｐ’ｘ＝Ｐｘ＊Ｒ’ｘ／Ｒｘ， Ｐ’ｙ＝Ｐｙ＊Ｒ’ｙ／Ｒｙ， Ｓ’ｘ＝Ｓｘ＊Ｒ’ｘ／Ｒｘ， 及び Ｓ’ｙ＝Ｓｙ＊Ｒ’ｙ／Ｒｙ
のように変化し、ここで、Ｐ’ｘ及びＰ’ｙは実際のオフセットを表し、Ｓ’ｘ及びＳ’ｙはクライアント側のキャンバスに表示された画像の実際の幅及び高さを表す。
【００８７】
コンポーネントパラメータは、どのコンポーネントを取り入れるべきであるかを指定する整数のリストである。コンポーネントは０から順番に番号付けされている。レンジを使用してもよい。かくして、Ｃｏｍｐｏｎｅｎｔｓ＝０−２，５は、コンポーネント０、１、２及び５を返す。
【００８８】
Ｌ＝ｑｕａｌｉｔｙパラメータは、サーバが送信すべきデータの量を決定する際に役立つ。サーバは、返却すべきレイヤの数として品質値を使用することを選択することもある。いずれの場合でも、品質に対する０ｘＦＦＦＦの要求は、サーバが領域内のタイルパーツに関して保有するすべてのデータを要求する。
【００８９】
パラメータＢｈ及びＢｓはオプションパラメータであり、サーバは、このパラメータを用いて、実際に送信されるバイト数に関するハードリミット若しくはソフトリミットを設定することができる。低解像度のタイルパーツが最初に送信され、高解像度のタイルパーツは、このリミットに達するまで送信される。このフィールドが存在しない場合、サーバは、特定の解像度で要求された領域を表示するために必要なタイルパーツを送信することができる。
【００９０】
フラグＡＤＤが肯定（ｙｅｓ）にセットされている場合、新しい要求を前に要求されたウィンドウと連結することができる。デフォルトとして、このフラグは、無効にされ、新しいウィンドウが要求されると、クライアントは前のウィンドウを置き換える。
【００９１】
〔応答シンタックス〕
〔第３ティアー応答〕
第３ティアー応答は、完全な画像オブジェクトである。一実施例において、画像オブジェクトは、ビューポートを埋めるために適したＰＮＧファイル若しくはＪＰＧファイルである。このタイプの応答は以下のような応答である。
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ｉｍａｇｅ／ｊｐｅｇ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ： ２０３８７
ＣＲＬＦ
ＪＰＥＧ Ｃｏｍｐｒｅｓｓｅｄ Ｉｍａｇｅ Ｄａｔａ
【００９２】
尚、以下の第２ティアー応答に関して説明されるようなチャンク形式転送コーディングを使用することが好ましいが、チャンク形式転送コーディングを使用しなければならない訳ではない。
【００９３】
〔第２ティアー応答〕
第２ティアー応答は、ＨＴＴＰヘッダでラップされチャンク形式転送エンコーディングを使用して送信された、要求されたボックスと、（前に送信されていならば）コードストリーム・メインヘッダと、連結されている要求されたタイルパーツと、により構成される。第２ティアー応答は、非常に大きくなり、送信するために非常に長い時間を要する可能性があるので、送信の途中で中断できることが重要である。例えば、１Ｋ×１Ｋのタイルを含む画像は、１．５メガバイトの応答を生ずる（遅いリンクを用いる場合、これは、長い時間を要する）。チャンク形式転送エンコーディングが指定されない限り、ＨＴＴＰ要求は、”Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：”ヘッダの本体部の全長を指定するか、又は、接続を終えることによりデータの終了を示すことが必要である。どちらも実現可能ではあるが、望ましくはない。なぜならば、現在の応答を停止し、新しい要求のために同じコネクション上で更なるデータを送信することが望ましいからである。チャンク形式の場合、各チャンクの長さが送信され、応答を終了するため、長さ零が送信される。このように、一旦チャンクが開始されると、チャンクを終了させる必要があるが、応答を終了する前にすべての応答を完了させる必要はない。
【００９４】
以下にチャンク形式応答の例を示す。
ＨＴＴＰ／１．１ ２０６ Ｐａｒｔｉａｌ Ｃｏｎｔｅｎｔ
Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ： ０−２０００， ４０００−１０２００／８６７３７０
Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ： ｃｈｕｎｋｅｄ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ｉｍａｇｅ／ｊｐｅｇ２０００
ＣＲＬＦ
１０００
［４０９６ （ｏｒ １０００ ＨＥＸ−ＤＥＣＩＭＡＬ） ｂｙｔｅｓ ｏｆ ＪＰＥＧ ２０００ ｄａｔａ］
１０００
［４０９６ （ｏｒ １０００ ＨＥＸ−ＤＥＣＩＭＡＬ） ｂｙｔｅｓ ｏｆ ＪＰＥＧ ２０００ ｄａｔａ］
８
［８ ｂｙｔｅｓ ｏｆ ＪＰＥＧ ２０００ ｄａｔａ］
０
【００９５】
上記の例の最初のヘッダラインは、応答が完全なファイルではないことを示すため「部分コンテンツＰａｒｔｉａｌ Ｃｏｎｔｅｎｔ」ヘッダを使用する。”Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ”ヘッダは、ファイルのどの部分が送信されるかを示すため使用される。転送エンコーディング”Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ：”ヘッダは、データがチャンク形式であることを示すため使用される。データのタイプが与えられる。なぜならば、応答は、”ｉｍａｇｅ／ｊｐｅｇ２０００”というタイプが与えられた復号可能なＪＰＥＧ２０００ファイルであるからである。他のタイプを使用してもよい。
【００９６】
１番目よりも後の応答の場合、応答は、有効なＪ２Ｋコードストリームを格納していない（メインヘッダが含まれないことは非常に稀である。）。この場合、別のタイプ、例えば、”ｉｍａｇｅ／ｊＰｉＰ”を用いてそのことを示すことが望ましい。
【００９７】
一実施例において、４０９６バイトの第１のチャンクを送信した後に新しい要求が受信され、サーバが伝送を終了させることに決定した場合、サーバは、現在のボックス、メインヘッダ、若しくは、タイルパーツを完了し、長さ０のチャンクを示す。次に、新しい応答が新しいＨＴＴＰヘッダを用いて開始される。
【００９８】
〔第１ティアー応答〕
一実施例では、第１ティアー応答は、ＨＴＴＰ［ＨＴＴＰ標準］に規定されているバイトレンジ応答と同じである。データを簡単に終端できるように、チャンク形式転送エンコーディングを使用することが望ましい。
【００９９】
〔要求／応答セマンティックス〕
要求を受信した後、サーバはチャンクを送信している間に更なる要求を受信しようとしている。
【０１００】
サーバは、新しい要求の優先順位が十分であるならば、現在の応答を正常に終了し、新しい要求に応答し始める。一実施例では、十分な優先順位は、”Ｉｎｆ”優先順位の要求によって示される。サーバは、現在のタイルパーツを終え、現在の要求に対してこれ以上チャンクが送信されないことを示すチャンクサイズ０を送信する。一実施例において、サーバは、ＨＴＴＰフッターを付加し、次の応答を開始する。
【０１０１】
サーバが”Ｉｎｆ”以外の優先順位を受信した場合、サーバは、現在の要求の中で継続すべき要求の量を決定する。現在の要求が新しい要求に対する良好な回答であるならば、アクションは必要ではない。例えば、新しい要求は異なるビューであっても、依然として同じ部分のセットが必要である場合がある。新しい要求の優先順位が前の要求の優先順位よりも１だけ高い場合、旧い要求は、新しい要求のために現在のタイルパーツの終わりで一時中断させることが提案される。
【０１０２】
最終的には、一実施例では、サーバは、すべての要求に適合する簡単な応答を送信する。或いは、応答が複数の要求に回答することを示すために規定されたシンタックスが使用される。この場合、サーバは、現在の転送を停止することなく、かつ、新しいＨＴＴＰヘッダから開始することなく、新しい要求若しくは旧い要求に関連したタイルパーツを送信し続ける。一実施例では、この場合、サーバは、拡張され得る要求を開始するときに、”Ｃｏｎｔｅｎｔ−Ｒａｎｇｅ：”ヘッダを使用しない。
【０１０３】
〔サーバデータ記憶フォーマット〕
一実施例において、トランスポート・プロトコルは、すべてのＪＰＥＧ２０００ファイルフォーマット及びコードストリームで機能する。しかし、このような方式での機能は、必ずしも効率的ではない。例えば、タイルが使用されない場合、領域の要求は、コードストリーム全体を返すことがある。
【０１０４】
トランスポート・プロトコルと共に使用する最も効率的な画像圧縮方法は、期待されるアクセスの性質に依存する。”Ｃａｌｌ ｆｏｒ ＪＰＩＰ ｔｅｃｈｎｏｌｏｇｙ ｐｒｏｐｏｓａｌｓ”［ＪＰＩＰ Ｅｄｉｔｏｒｓ （Ｐｒａｎｄｏｌｉｎｉ， Ｈｏｕｃｈｉｎ， Ｃｌａｒｋ）， Ｃａｌｌ ｆｏｒ ＪＰＩＰ ｔｅｃｈｎｏｌｏｇｙ ｐｒｏｐｏｓａｌｓ， ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１ Ｎ ２５５０， ２１ Ｍａｒｃｈ ２００２］に規定されているような「パン及びズーム」動作のシーケンスの場合、Ｎ／１６×Ｎ／１６のタイルサイズを使用することは、Ｎ×Ｎ画素のサイズの矩形画像に対して優れている。
【０１０５】
使用されるコードストリームに対する一つのプログレッション順序は、解像度−レイヤ−コンポーネント−位置（ＲＬＣＰ）である。タイルは、あらゆる解像度及びあらゆるレイヤでタイルパーツに分割可能である。一実施例において、低解像度のすべてのタイルパーツは、より高解像度のタイルパーツよりも前にファイルに保存される。これにより、低解像度部分は、最小回数のディスクアクセスで入手できるようになる。一実施例において、十分な品質は、タイル境界アーティファクトを回避するため、最初のレイヤに記憶される。
【０１０６】
場合によっては、無損失で保存された画像の低解像度バージョンをブラウズできることが望ましい。ＲＬＣＰ順の場合、画像が無損失に蓄積されるとは、低解像度画像のために多数のビットが使用されることを意味する。これは、クライアントとサーバの間の低速コネクションによる画像のパンとズームのブラウジングを遅くする。この問題は、画像をサーバに特殊な方法で格納することによって解決される。レイヤ−解像度−コンポーネント−位置（ＬＲＣＰ）プログレッション順序は、コードストリームのために使用されるが、最初のレイヤは、主として解像度順にデータを格納するため使用される。最後のレイヤは、画像の損失のない表現を記憶するため使用される。各レイヤには固有のタイルパーツが割り当てられるので、サーバは、完全なタイルパーツを送信することによって、望ましい解像度をクライアントに供給することが可能である。例えば、３レベルの解像度レベルのある単一の２５６×２５６タイルは、以下のように編成される。
【０１０７】
タイルパーツ０は、（すべてのコンポーネント及び位置に対して総計で）１２８バイトの解像度０のデータを格納するレイヤ０を収容する。これにより、かなり高品質であるが、依然として損失の多い画像（ビューイング解像度で１画素当たり１ビットと等価的な画像）がクライアントへ供給される。
【０１０８】
タイルパーツ１は、解像度０と解像度１の３８４バイトのデータを格納するレイヤ１を収容する。解像度０と解像度１のデータのバイト数は、解像度１の表示解像度で画質（画像品質）を最大にするように選択される。
【０１０９】
タイルパーツ２は、解像度０と解像度１と解像度２の１５３６バイトのデータを格納するレイヤ２を収容する。殆どのバイトは、解像度２であり、他の解像度は解像度２の表示解像度で最適な画質を得るために十分である。
【０１１０】
タイルパーツ３は、解像度０、１、２及び３の６１４４バイトのデータを格納するレイヤ３を収容する。タイルパーツ０〜３は、最適化された１ｂｐｐ画像を完全な解像度で格納する。
【０１１１】
タイルパーツ４は、損失の無い画像を得るために必要なすべての解像度の残りのデータを格納するレイヤ４を収容する。おそらく、階調画像については２４０００バイト、カラー画像についてはそれ以上のバイト数が必要である。勿論、タイルパーツは、２．０ビット／画素の画像と、損失の無い画像を得るため、補助的なタイルパーツに分割してもよい。或いは、ある最大タイルパーツサイズを維持するため、タイルパーツに分割してもよい。
【０１１２】
〔トランスポート・プロトコル性能〕
〔ディスクアクセスと要求される係数の数〕
以下の表４は、画像要求に応答するサーバによってアクセスされるファイル内の個別の場所の数のリストである。表４には、タイル全体又はプリーシンクトが要求に応じて送信されるならば、送信されるべき係数の数も掲載されている。勿論、送信されるべきバイト数は、主として圧縮比に依存するが、タイル若しくはプリーシンクトのサイズとは無関係に等しい圧縮を考慮すると、それらの値は応答サイズに関連付けられる。
【０１１３】
表４は、幾つかの異なるビューポイントに対するデータを表し、前の要求に対するデータが送信されたときに、新しいビューポイントに要求される補助的なアクセス／係数だけを表す。
【０１１４】
表４の値に対し、圧縮のため使用されるコマンドは以下の通りである。
Ｔｉｌｉｎｇ： ｋｄｕ＿ｃｏｍｐｒｅｓｓ −ｉ ｌｅｎａ．ｂｍｐ −ｏ ｏｕｔ．ｊｐ２ −ｒａｔｅ −， ０．２５ Ｃｌａｙｅｒｓ＝３０ Ｃｒｅｖｅｒｓｉｂｌｅ＝ｙｅｓ Ｓｔｉｌｅｓ＝｛１２８， １２８｝
Ｃｏｒｄｅｒ＝ＲＬＣＰ
タイルサイズ：１２８×１２８；２５６×２５６；５１２×５１２；１０２４×１０２４ アンタイルに対する結果が表に掲載されている。
Ｐｒｅｃｉｎｃｔｓ： ｋｄｕ＿ｃｏｍｐｒｅｓｓ −ｉ ｌｅｎａ．ｂｍｐ −ｏ ｏｕｔ．ｊｐ２ −ｒａｔｅ −， ０．２５ Ｃｌａｙｅｒｓ＝３０ Ｃｒｅｖｅｒｓｉｂｌｅ＝ｙｅｓ Ｃｐｒｅｃｉｎｃｔｓ＝｛１２８， １２８｝ ｃｏｒｄｅｒ＝ＲＰＣＬ
プリーシンクトサイズ３２×３２；６４×６４；１２８×１２８；２５６×２５６；５１２×５１２に対する結果は表に掲載され、同じサイズのプリーシンクトが各解像度で使用される。
【０１１５】
表４は、プリーシンクトとタイルパーツの比較であるとみなすべきではない。なぜならば、プリーシンクトは、各解像度で、タイルに要求されるよりも小さいサイズを使用できるからである。
【０１１６】
【表５】

【０１１７】
【表６】

〔セッション持続性〕
一実施例において、プロトコルは、幾つかのメカニズムによって時間的に分離された多重接続上であってもデータの再送信を回避する。これは、既にクライアントへ送信されたデータを示すために、クライアントに、ｈｔｔｐヘッダのうちの一つ（例えば、Ｔ２ｃａｃｈｅ）を使用させることによって達成される。セッション持続性を与える代替的なメカニズムは、現在の多数の商業ウェブサイトで行われているように、セッションＩＤを維持するため、クッキー（ｃｏｏｋｉｅ）を使用することである。勿論、サーバは、セッションの記録を残さないこともあり、クライアントが全く保存していないと考えられるコードストリームの部分を送信するに過ぎない。
【０１１８】
〔エラー処理〕
エラー処理に関して、ＨＴＴＰは、エラー条件に対する様々な応答メッセージを含む。これらのすべては、このプロトコルと共に使用するために利用できる。エラーが検出された場合、ステージ間で再送信を要求することができる。ＨＴＴＰフッターは、送信データのチェックサムを送信するため使用可能であり、これにより、エラーを検出する。
【０１１９】
〔速度（レート）制御〕
速度制御に関して、トランスポート・レベル・プロトコルと、ソケットを実現するライブラリは、例えば、典型的に、クライアントが処理できる速度よりも速い速度でクライアントにデータが送信されていないことを保証する。殆どのソケットライブラリにおいて、”ｓｅｎｄ”呼び出しは、大量のデータが送信される場合、データが送信されるまでエラーを阻止するか、又は、エラーを返す。チャンク形式で大量の応答を送信することは、単一の”ｓｅｎｄ”が非常に大きくなることを阻止するはずである。一実施例において、最大バイトパラメータのようなパラメータは、バイト数を制限するため使用される。また、クライアント及び／又はサーバは、速度制御を行うことが許可される。これにより、遅いリンク上のバッファの充填が制御されるであろう。
【０１２０】
トランスポート・プロトコルは、クライアントが有効な最大画像を指定できるようにするｍａｘｈパラメータ及びｍａｘｗパラメータを与えない。クライアントは、ＪＰＥＧ若しくはＰＮＧへの翻訳を要求する。
【０１２１】
〔同時アクセスのためのサポート〕
ここで説明しているトランスポート・プロトコルは、サーバ上の同じ画像への同時アクセスを制限しない。一実施例では、単独のクライアントが同じサーバ上の同じリソースへ多重接続を開設する場合、各接続は、その接続についての要求の順序で扱われる。クライアントが望むならば、クライアントは、受信したＴ３ｃａｃｈｅ若しくはＴ２ｃａｃｈｅヘッダを用いて、所与の接続に要求していないデータを指定することができる。さもなければ、サーバは、二つの接続が全く同一のクライアントに対してなされていることを知ることができない。
【０１２２】
代替的な実施例では、セッション鍵は、別々の要求をつなぐため、要求及び応答のすべてのレベルに対するＨＴＴＰへ付加してもよい。これにより、上記のプロトコルは、ＨＴＴＰ１．１のデフォルトの「生かしておく（キープアライブ）」機能を用いることなく動作できる。また、これにより、信頼性の低いネットワーク上でもより巧く利用できるようになる。セッション内の要求を順番に並べるために要求番号を付加することが有効である。かくして、ＴＣＰ上でＨＴＴＰを用いる場合であっても、多重接続を作成し使用することが可能である。セッション鍵は、クッキーヘッダを用いて、或いは、要求パラメータとして組み込むことが可能である。
【０１２３】
〔ＪＰＩＰ要求バインディング〕
ＨＴＴＰは、ＴＣＰ／ＩＰ以外のチャネルによっても搬送することができる。したがって、このプロトコルを、ＴＣＰ／ＩＰ以外のＨＴＴＰをサポートするチャネルで使用することが望まれるならば、新しい定義は不要である。一実施例では、未訂正のエラー若しくはパケット損を含むチャネルに対してプロトコル・バインディングを指定することが望ましい場合、チャンク形式転送エンコーディングを使用する応答の各チャンクは、固有のネットワークパケットになる。他のすべての要求及び応答は、ネットワークパケット内に適合する。一実施例において、これらは、コネクション優先チャネルのため送出される順番にパケット番号が与えられる。尚、ＨＴＴＰ以外のプロトコルを使用しても構わないことにも注意する必要がある。
【０１２４】
〔キャパビリティ交換とネゴシエーション〕
一実施例では、キャパビリティは、応答のヘッダだけを要求するＨＴＴＰメソッド”ＨＥＡＤ”を用いて要求され、クライアントは、”ＧＥＴ”要求を用いて受信した応答のタイプを決定することが可能である。一例は、
ＨＥＡＤ ｆｉｌｅｎａｍｅ．ｊｐ２？ｒｅｓ＝２ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
のように表される。
【０１２５】
一実施例において、サーバのキャパビリティは、ＨＴＴＰメソッド”ＯＰＴＩＯＩＮＳ”、例えば、
ＯＰＴＩＯＮＳ ＊ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
を用いて要求される。
【０１２６】
一実施例において、特定の画像上の動作のキャパビリティは、
ＯＰＴＩＯＮＳ ｆｉｌｅｎａｍｅ．ｊｐ２ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ
ＣＲＬＦ
を用いて決定される。
【０１２７】
ＨＴＴＰ １．１ ＲＦＣは、キャパビリティを示すメカニズムを含む。ここで説明されている画像プロトコルの場合、サーバは、以下のラインを含むヘッダを返す。
Ａｃｃｅｐｔ−Ｒａｎｇｅｓ： ｂｙｔｅｓ， ｔｉｌｅ−ｐａｒｔｓ
Ａｃｃｅｐｔ： ｉｍａｇｅ／ｊｐｅｇ２０００；ｑ＝０．９ ｉｍａｇｅ／ｇｉｆ；ｑ＝０．５ ｉｍａｇ／ｊｐｉｇＴ２；ｑ＝０．９５ ｉｍａｇｅ／ ｊｐｉｐＴ３；ｑ＝０．１
Ａｌｌｏｗ： ＧＥＴ， ＨＥＡＤ， ＰＯＳＴ， ＯＰＴＩＯＮＳ， ＴＲＡＣＥ
Ｖａｒｙ： ａｃｃｅｐｔ， ＊
【０１２８】
ＨＴＴＰ １．１ ＲＦＣは、ここで説明されている画像プロトコルの場合、以下のようなヘッダが役に立つ。
Ａｃｃｅｐｔ−Ｒａｎｇｅｓ： ｂｙｔｅｓ， ｔｉｌｅ−ｐａｒｔｓ
【０１２９】
”Ａｃｃｅｐｔ−Ｒａｎｇｅｓ： ｂｙｔｅｓ”は、正当なＨＴＴＰ／１．１コマンドである。一実施例において、サーバは、直接バイトレンジ要求に応答する能力を示すため、トランスポート・プロトコルでこれを使用する。このような場合、洗練されたクライアントは、コードストリーム又はファイルフォーマットの望ましい部分を正確に抽出する。
【０１３０】
”Ａｃｃｅｐｔ−Ｒａｎｇｅｓ： ｔｉｌｅ−ｐａｒｔｓ”の使用は、サーバがタイルパーツに対する直接要求に応答する能力を示すための一つの方法である。
Ａｃｃｅｐｔ： ｉｍａｇｅ／ｊｐｅｇ２０００；ｑ＝０．９ ｉｍａｇｅ／ｇｉｆ；ｑ＝０．５ ｉｍａｇｅ／ｊｐｉｐＴ２；ｑ＝０．９５ ｉｍａｇｅ／ｊｐｉｐＴ３；ｑ＝０．１
尚、ＨＴＴＰは、Ａｃｃｅｐｔヘッダ内で能力を示すだけではなく、優先度を示す。画像をトランスコードする能力を備えたＪＰＥＧ ２０００画像サーバは、クライアントとサーバの両方が最高優先度でサポートするタイプのビューポート要求を返す。或いは、サーバは、より優先度の低いタイプを返すことに決定してもよい。なぜならば、その方がサーバに対する負荷が軽いからである（例えば、サーバは、サーバの負荷が高い場合には、伸長及び再圧縮を必要としないタイプを返すかもしれない。）。或いは、サーバは、最終的に、多数の要求によって帯域幅が低下するかもしれない。
Ａｌｌｏｗ： ＧＥＴ， ＨＥＡＤ， ＰＯＳＴ， ＯＰＴＩＯＮＳ， ＴＲＡＣＥ
【０１３１】
このＨＴＴＰラインは、サーバが許可するコマンドを示す。これらのコマンドは、今まで使用されていたのと同じように画像サーバで使用される。
Ｖａｒｙ： ａｃｃｅｐｔ， ＊
【０１３２】
Ｖａｒｙヘッダは、応答が、クライアントが許容することを示すリターンタイプに依存することを示す。”＊”は、応答がｈｔｔｐヘッダ以外のものに依存するかもしれないことを示す。ここで説明しているプロトコルを使用するシステムにおけるサーバにおいて、返却される正確な内容は、前の要求に依存するかもしれない。例えば、サーバは、既にクライアントが保有していることを確信するタイルパーツを返さない。これは、ＨＴＴＰプロキシを実現するために重要である。なぜならば、返却されたデータは、同じタイルパーツの組をもたないクライアントからの等価的な要求に対して優れたデータではない可能性があるからである。
【０１３３】
〔画像の一意識別〕
ＨＴＴＰは、リソースを一意に識別するメカニズムを備えていることに注意する必要がある。”Ｅｔａｇ”は応答を一意に識別する（ＨＴＴＰ １．１ ＲＦＣ ２６１６［ＨＴＴＰ標準］のセクション１４．１９を参照。）。
【０１３４】
ＪＰＥＧ ２０００パートＩは、ＵＵＩＤボックスを識別する（ＩＴＵ−Ｔ Ｒｅｃ． Ｔ．８００｜ＩＳ１５４４４−１：２０００， Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ ＿ ＪＰＥＧ ２０００ ｉｍａｇｉｎｇ ｃｏｄｉｎｇ ｓｙｓｔｅｍ： Ｃｏｒｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍのセクションＩ．７．２を参照。）。ここで説明されるプロトコル要求シンタックスは、ボックスの返却を可能にさせ、このボックスは画像の一意性を判定するために要求され得る。
【０１３５】
”Ｅｘｐｉｒｅｓ”のようなＨＴＴＰヘッダを用いることにより、クライアントは、キャッシュされたデータが有効ではなくなるときを知ることができる。ＨＴＴＰ標準のセクション１４．２１を参照。
【０１３６】
〔サーバへの画像アップローディング〕
完全な画像は、ＨＴＴＰメソッドＰＯＳＴを使用してアップロードできる。この場合、シンタックスは、他のファイルアップロードと全く同じようにみえる。トランスポート・プロトコルは、全タイルパーツのアップローディングを可能にさせる。この場合、ヘッダは、Ｔｉｅｒ２シンタックスを使用してアップロードされているタイルパーツがどのタイルパーツであるかを示す。クライアントは、アップロードされたタイル毎にすべてのタイルパーツを与える。サーバは、アップロードされたタイルのすべてのタイルパーツを削除し、新しいタイルパーツを格納する。サーバは、元のファイルの順序とは異なる順序でタイルパーツを格納するように選択する。更に、ＴＬＭを更新しなければならない。サーバは、ＰＰＭマーカー・セグメントを使用して画像を更新することを拒絶するように選択してもよい。勿論、サーバは、画像又はタイルパーツを全くアップロードしないように選択してもよい。一部のサーバは、ＨＴＴＰメソッドＤＥＬＥＴＥをサポートすることを選択する。このメソッドの場合、ＪＰＥＧ２０００画像に対して特別なシンタックスは要求されない。
【０１３７】
〔その他の能力〕
１回の要求の後に画像を返す能力は有用である。最も顕著な例は、インライン形イメージを含むウェブページである。画像タグは、画像の返却を可能にさせる。ウェブページの作成者は、組み込まれる画像と、ページのレイアウトについての知識があり、ＵＲＬを設定しているので、おそらく、サーバの能力についても知っているであろう。「キャパビリティ交換（ｅｘｃｈａｎｇｅ ｃａｐａｂｉｌｉｔｉｅｓ）」と画像獲得の必要性はない。
【０１３８】
一実施例において、ブラウザがＪＰＥＧ ２０００画像を理解できるようにするため、個々で説明しているプロトコルは、
＜ｉｍｇ ｓｒｃ＝”ｈｔｔｐ：／／ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ／ｎａｍｅ．ｊｐ２？ｒｅｓ＝２” ｗｉｄｔｈ＝”１２８” ｈｅｉｇｈｔ＝”１１５”＞
のような呼び出しをサポートする。このコールは、低解像度部分を含むｊｐ２ファイルを返す。一実施例において、ブラウザは、ＪＰＥＧ画像及びＧＩＦ画像のように、作成者が望む１２８×１１５のウィンドウに巧く収まるように画像を拡大縮小する。
【０１３９】
すべてのブラウザが画像を読み取れることを保証するため、画像タグは、画像がＰＮＧ（或いは、ＧＩＦ若しくはＪＰＥＧ）に変換されることを要求できる。
＜ｉｍｇ ｓｒｃ＝”ｈｔｔｐ：／／ｔｒｕｅｗ．ｃｒｃ．ｒｉｃｏｈ．ｃｏｍ／ｎａｍｅ．ｊｐ２？ｒｅｓ＝２＆ｔｉｅｒ３＝ＰＮＧ” ｗｉｄｔｈ＝”１２８” ｈｅｉｇｈｔ＝”１１５”＞
【０１４０】
サーバがＪＰ２ファイルにアクセスし続けるとしても、配信する前に変換されるであろう。
【０１４１】
〔拡張／代案〕
〔タイルパーツ「オンザフライ」を書き換えるためにＰＯＣマーカーを使用〕
一実施例では、ここで説明するプロトコルは、サーバに現れるようなタイルパーツだけに役立つ。異なる領域をバラバラの順序でアクセスしてもよいが、すべてのタイルパーツは順番にアクセスされる。そのため、クライアントがコンポーネント２にアクセスすることを望み、コンポーネント０及び１が最初にタイルパーツに格納されるならば、すべての典型的なプログレッション順の場合と同様に、要求されていないデータが送信される。
【０１４２】
しかし、代替実施例では、サーバは、クライアントによって要求された順序通りになるように、タイル内でタイルパーツを再配置することができる。一実施例では、サーバは、解像度、レイヤ、及び、タイルパーツに格納されたコンポーネントを指定するため、各タイルパーツに関してＪＰＥＧ２０００標準のＰＯＣマーカーを使用する。これは、サーバ側でのバッファリングを要求する。キャッシングの方がより一層難しい。なぜならば、サーバは、コードストリームが並べ替えられた状況を把握しているからである。一実施例では、これは、要求コマンドを追跡することによって行われる。一実施例において、サーバは、要求及び応答を行うため、内部データ構造を使用する。一実施例では、サーバは、クライアントが要求した順序でファイルのコピーを書き込む。
【０１４３】
サーバが、各解像度について１個ずつのタイルパーツがＲＬＣＰ順に並べられている３コンポーネントＪＰＥＧ２０００ファイルを格納している場合を考える。さらに、一つのタイルパーツに関して１個のレイヤと１個のプリーシンクトだけが存在すると仮定する。このとき、タイルパーツデータは、
ＳＯＴ ｍａｒｋｅｒ ｓｅｇｍｅｎｔ（Ｔｉｌｅ ０， Ｌｅｎｇｔｈ ｏｆ ｔｉｌｅ−ｐａｒｔ， Ｐａｒｔ ０， Ｎｕｍｂｅｒ ｏｆ Ｐａｒｔ ０）
ＳＯＤ ｍａｒｋｅｒ
Ｐａｃｋｅｔ Ｈｅａｄｅｒ／Ｂｏｄｙ ｏｆ Ｒｅｓｏｌｕｔｉｏｎ ０， Ｌａｙｅｒ ０， Ｃｏｍｐｏｎｅｎｔ ０， Ｐｏｓｉｔｉｏｎ ０（Ｒ０Ｌ０Ｃ０Ｐ０）
Ｐａｃｋｅｔ Ｈｅａｄｅｒ／Ｂｏｄｙ ｏｆ Ｒ０Ｌ０Ｃ１Ｐ０
Ｐａｃｋｅｔ Ｈｅａｄｅｒ／Ｂｏｄｙ ｆｏｒ Ｒ０Ｌ０Ｃ２Ｐ０
のように見えるであろう。
【０１４４】
クライアントが最初のコンポーネント（番号０）だけを要求する場合、サーバは、コンポーネント１及び２からのデータを含むすべてのタイルパーツを送信する。これは、望んでいないコンポーネントに対するデータが大量である場合には、非効率的である。そこで、サーバは、最初のコンポーネントだけを収容するファイルには実際に現れないタイルパーツを作成し、クライアントへ送信する。メインヘッダは、ファイル内に２個以上のコンポーネントが存在することを示すので、サーバは、このタイルパーツが１個のコンポーネントしか含まないことを示す。サーバは、数通りの方法を用いて、状況の順番を変えるためにファイルを変更することができる。
【０１４５】
プログレッション順は、ＣＰＲＬに変更してもよく、クライアントは、最初にコンポーネント０が現れることを予想する。これは、クライアントが最初にコンポーネント２ではなく、コンポーネント０を要求する場合に機能する。
【０１４６】
他のコンポーネントに対するパケットは、零データを保有するように変更できる。これは、他のコンポーネントに対するデータが後のパケットまで現れないようにレイヤ割り当てを変更することと等価的である。しかし、プレースホルダーとしての役割を果たすためには、スキップされたパケット毎に１バイトパケットヘッダを組み込むことが依然として必要である。更に、他のコンポーネントからのデータが要求されるとき、パケットヘッダは、正しいレイヤ情報を組み込むために書き込まれなければならない。
【０１４７】
一実施例において、ＰＯＣマーカー・セグメントは、タイルパーツヘッダに収容される。タイルパーツは、
ＳＯＴ ｍａｒｋｅｒ ｓｅｇｍｅｎｔ（Ｔｉｌｅ ０， Ｌｅｎｇｔｈ ｏｆ ｔｉｌｅ−ｐａｒｔ， Ｐａｒｔ ０， Ｎｕｍｂｅｒ ｏｆ Ｐａｒｔ ０）
ＰＯＣ ｍａｒｋｅｒ ｓｅｇｍｅｎｔ（Ｒｅｓｏｌｕｔｉｏｎ ｓｔａｒｔ＝０， Ｃｏｍｐｏｎｅｎｔ ｓｔａｒｔ＝０， ｌａｙｅｒ ｅｎｄ＝１， ｒｅｓｏｌｕｔｉｏｎ ｅｎｄ＝１， ｃｏｍｐｏｎｅｎｔ ｅｎｄ＝１）
ＳＯＤ ｍａｒｋｅｒ
Ｐａｃｋｅｔ Ｈｅａｄｅｒ／Ｂｏｄｙ ｏｆ Ｒｅｓｏｌｕｔｉｏｎ ０， Ｌａｙｅｒ ０， Ｃｏｍｐｏｎｅｎｔ ０， Ｐｏｓｉｔｉｏｎ ０（Ｒ０Ｌ０Ｃ０Ｐ０）
のように表される。
【０１４８】
このタイルパーツは、要求されたデータだけを格納する。更なる要求によって、新しいタイルパーツが生成され、新しいタイルパーツは、要求されたデータだけを格納する新しいＰＯＣマーカーを含む。
【０１４９】
パケット自体は変更する必要がなく、パケットを送信する順序だけが変更される。
【０１５０】
いずれにしても、この技術の一つの重要な利点は、クライアントが、受信したコードストリームの部分を追跡するための補助的な構造を用いることなく、常に正当なＪＰＥＧ２０００ファイルを保有し続けることである。
【０１５１】
〔補助的な用途の場合：メモリもデコーダも無いクライアント〕
非常に簡単なクライアントは、クライアントの表示エリアよりも少ないメモリしか備えていないにもかかわらず、非常に大きい画像をブラウズすることを望む場合がある。圧縮画像データをキャッシュすることは期待できない。クライアントはＪＰＥＧ２０００デコーダを具備しない場合もある。しかし、このクライアントは、ＪＰＥＧ２０００サーバと通信し、Ｔｉｅｒ３要求を作成し、Ｔｉｅｒ３応答を受信することが可能である。
【０１５２】
〔典型的なコンピュータシステム〕
図８は、上記の一つ以上の動作を実行する典型的なコンピュータシステムのブロック図である。図８によると、コンピュータシステム８００は、典型的なクライアント若しくはサーバを構成する。コンピュータシステム８００は、情報を通信する通信メカニズム若しくはバス８１１と、バス８１１に接続され情報を処理するプロセッサ８１２と、を含む。プロセッサ８１２は、例えば、Ｐｅｎｔｉｕｍ（登録商標）、ＰｏｗｅｒＰＣ（登録商標）、Ａｌｐｈａ（登録商標）などのマイクロプロセッサを含むが、これらのマイクロプロセッサには限定されない。
【０１５３】
システム８００は、バス８１１に接続され、情報を記憶し、プロセッサ８１２によって実行される命令を記憶するランダム・アクセス・メモリ（ＲＡＭ）、若しくは、ダイナミック記憶装置８０４（メインメモリと呼ばれる）を更に含む。メインメモリ８０４は、プロセッサ８１２による命令の実行中に、一時的な変数、若しくは、他の中間情報を記憶するためにも使用される。
【０１５４】
コンピュータシステム８００は、バス８１１に接続され、プロセッサ８１２のための静的情報及び命令を記憶するリード・オンリー・メモリ（ＲＯＭ）及び／又はその他のスタティック記憶装置８０６と、磁気ディスク若しくは光ディスク及び対応したディスクトドライブを備えたデータ記憶装置８０７と、を更に含む。データ記憶装置８０７は、バス８１１に接続され、情報と命令を記憶する。
【０１５５】
コンピュータシステム８００は、バス８１１に接続され、情報をコンピュータのユーザへ提示する陰極線管（ＣＲＴ）若しくは液晶ディスプレイ（ＬＣＤ）のような表示装置８２１に接続される。英数字キー及びその他のキーを備えた英数字入力装置８２２もバス８１１に接続され、情報及びコマンド選択をプロセッサ８１２へ通知する。補助的なユーザ入力装置は、マウス、トラックボール、トラックパッド、スタイラス、或いは、カーソル方向キーのようなカーソル制御装置８２３であり、バス８１１に接続され、方向情報及びコマンド選択をプロセッサ８１２へ通知し、表示装置８２１上のカーソルの動きを制御する。
【０１５６】
バス８１１に接続され得るその他の装置には、命令、データ、若しくは、その他の情報を、紙、フィルム、若しくは、類似したタイプの媒体などのような媒体に印刷するため使用されるハードコピー装置８２４が含まれる。更に、スピーカー及び／又はマイクロホンのような音声記録及び再生装置がバス８１１に接続され、コンピュータシステム８００との間で音声インタフェースを実現する場合もある。バス８１１に接続できる他の装置には、電話機、又は、ハンドヘルド型の手のひらサイズの装置若しくはコンピュータやサーバと通信する有線／無線通信設備８２５が含まれる。
【０１５７】
バスに接続できる別の装置は、例えば、デジタル信号プロセッサ（ＤＳＰ）若しくは特殊な圧縮（及び／又は伸長）ハードウェアを構成するコ・プロセッサ８３５である。
【０１５８】
システム８００と関連したハードウェアの一部若しくは全部が本発明で使用される。しかし、他のコンピュータシステムのコンフィギュレーションでも、一部若しくは全部の装置を収容できることが明らかである。
【０１５９】
上述の説明では、種々の特定の細部が本発明の全体の理解が得られるように解説されている。当業者に明らかであるように、本発明は、これらの特定の細部を用いることなく実施できる。別の例では、構造及び装置は、本発明がわかり難くなることを避けるためブロック図の形式で示されている。
【０１６０】
以下の詳細な説明の一部は、コンピュータメモリ内のデータビットに関する演算のアルゴリズム及び記号表現の形で与えられている。これらのアルゴリズム記述及び表現は、データ処理技術の当業者が自分の業績の要旨を他の当業者にできるだけ効率的に伝達するため使用する手段である。本明細書において、並びに、一般的に、アルゴリズムは、希望の結果を生ずる首尾一貫したステップ（手順）の系列であると考えられる。ステップは、物理量の物理的な操作を必要とする。通常、必須的ではないが、これらの量は、記憶、転送、合成、比較及びその他の操作を加えることができる電気信号若しくは磁気信号の形式をとる。主として慣用されているという理由から、これらの信号は、ビット、値、エレメント、シンボル、文字、項、数などのように呼ばれる。
【０１６１】
しかし、これらのすべての用語、並びに、類似した用語は、適切な物理量と関連付けられるべきであり、これらの量に適用された便利なラベルに過ぎない。特に断らない限り、以下の説明から明らかであるように、説明全体を通じて、「処理」、「コンピューティング」、「計算」、「決定」、「表示」などのような用語を利用する議論は、コンピュータシステム、若しくは、類似した電子コンピューティング装置の動作及び処理について言及するものであり、コンピュータシステムは、コンピュータシステムのレジスタ及びメモリ内で物理（電子的）量として表現されたデータを操作し、コンピュータシステムのメモリ若しくはレジスタ、或いは、他のこのような情報記憶装置、伝送装置又は表示装置内で物理量として同じように表現された他のデータに変換する。
【０１６２】
本発明は、上記の演算を実行する装置にも関する。この装置は、要求された目的のため特別に構築されるか、或いは、コンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ状態にされるか、又は、再構築される汎用コンピュータを具備する。このようなコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に保持される。コンピュータ読み取り可能な記録媒体の例には、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスクなどの任意のタイプのディスクと、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード若しくは光カード、或いは、電子命令を記憶するために好適である任意のタイプの媒体が含まれるが、これらの例に限定されるものではない。各媒体はコンピュータシステムのバスに接続される。
【０１６３】
以下の説明におけるアルゴリズム及びディスプレイは、特定のコンピュータ若しくはその他の装置に本来的に関連付けられていない。多様な汎用システムが、上記の教示に従うプログラムと共に使用され、或いは、要求された方法の手順を実行するために、より特殊化された装置を構築する方が好都合であることが判明することもある。これらの多様なシステムのため要求される構造は、上記の説明から明らかになるであろう。更に、本発明は、特定のプログラミング言語に関しては説明されていない。上述の本発明の教示を実施するため、種々のプログラミング言語が使用される。
【０１６４】
機械読み取り可能な媒体は、機械（たとえば、コンピュータ）によって読み取り可能な形式で情報を記憶若しくは伝送する任意のメカニズムを含む。たとえば、機械読み取り可能な媒体は、読み出し専用メモリ（ＲＯＭ）と、ランダム・アクセス・メモリ（ＲＡＭ）と、磁気ディスク記憶媒体と、光記憶媒体と、フラッシュメモリ装置と、電気的、光学的、音響的若しくはその他の形式の伝搬信号（たとえば、搬送波、赤外線信号、デジタル信号など）と、を含む。
【０１６５】
以上の説明から分かるように、本発明の多数の代替例及び変形例は当業者にとって明白であり、例示的に説明され図示された特定の実施例は本発明を限定することを意図したものではないことが理解されるべきである。したがって、様々な実施例の細部に関する記述は、本発明に不可欠であると考えられる事項のみが記載されている請求項に係る発明の範囲を限定するものではない。
【０１６６】
【発明の効果】
本発明によれば、効率的な画像通信が実現される。
【図面の簡単な説明】
【図１】簡単な画像アクセスの説明図である。
【図２】典型的なソフトウェア構造の説明図である。
【図３】クライアントとサーバの区分の例の説明図である。
【図４】クライアントとサーバの区分の例の説明図である。
【図５】クライアントとサーバの区分の例の説明図である。
【図６】クライアントとサーバの区分の例の説明図である。
【図７】クライアントとサーバの区分の例の説明図である。
【図８】コンピュータシステムの一実施例の構成図である。
【図９】ビューポート質問パラメータとＳＩＺマーカー・セグメント・パラメータの間の対応関係の説明図である。
【符号の説明】
２００ アプリケーション
２０１ 第１ステージ
２０２ 第２ステージ
２０３ 第３ステージ
２０４ 第４ステージ
２０５ ファイルシステム、オンザフライ画像発生器又はバイトレンジサーバ
８０４ メインメモリ
８０６ スタティック・メモリ
８０７ 大容量メモリ
８１１ バス
８１２ プロセッサ
８２１ 表示装置
８２２ キーボード
８２３ カーソル制御装置
８２４ ハードコピー装置
８２５ 無線／電話インタフェース
８３５ コ・プロセッサ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to the field of image communication. In particular, the invention relates to communicating a portion of an image and associated metadata over a communication channel.
[0002]
[Prior art]
JPEG2000 was designed to allow for the use of various regions, resolutions, and quality levels of an image without decoding the entire JPEG2000 file. A variety of progression orders are defined, and files transmitted over slow communication channels are "progressed" in some way, for example, from low resolution to high resolution, or from low quality to high quality. I do. Also interesting is the ability to select a portion of an image in a different order than the order in which the files were stored. Generally, the area and quality of the image are interactively selected for transmission.
[0003]
A virtual media (Vmedia) access protocol has been proposed, and a bidirectional JPEG2000 browser using Vmedia has been developed (for example, see Non-Patent Document 1).
[0004]
A client / server environment for transmitting JPEG2000 images is also specified (for example, see Non-Patent Document 2). Non-Patent Document 2 defines a smart client, a dumb client, a smart server, and a dumb server, and gives an example of JPEG2000 byte usage in a “pan and zoom” session. A protocol based on Protocol (IIP), version 1.0.5, October 6, 1997, is described. This protocol extends some of the ideas described in [3], but is based on HTTP for transport as described in [4].
[0005]
JPEG2000 images are transmitted using HTTP (for example, see Non-Patent Document 5). However, a separate index file containing the header information is sent and an HTTP byte range request is used to obtain the desired image component. This protocol allows requests to be pipelined, but not interrupts. Requires extra round trip time to get the index file. These examples are very inefficient. This is because a plurality of byte ranges are transmitted by “content-type: multipart / byte range” including a boundary value. In some cases, there is 70 bytes of overhead for 48 bytes of data.
[0006]
HTTP "accept-range" with values such as byte jp box and j2k packet is used (for example, see Non-Patent Document 6). The major disadvantage of this approach is that after deciding which server supports the auxiliary range type, the initial connection must be terminated and a new connection must be opened.
[0007]
Precincts and code blocks are used as basic elements of JPEG2000 file transfer (for example, see Non-Patent Document 7). This document defines a protocol that uses a binary container, specifies acknowledgment and session information, and uses a precinct byte range as a basic return type. In contrast, this protocol uses self-labeling tile parts as a basic element of communication. In this way, both the client and the server obtain a valid copy of the JPEG2000 codestream.
[0008]
A call for proposals for the JPEG2000 two-way protocol (JPIP) has been announced (for example, see Non-Patent Document 8). This document describes a sequence of pan and zoom steps used with a browser and for which an index of efficiency is sought.
[0009]
In response to this call for proposals, a complete protocol and access to individual code blocks or larger portions of the JPEG2000 file are specified (see, for example, Non-Patent Document 9). The proposal also specifies an application programmer's interface (API) for the protocol.
[0010]
[Non-patent document 1]
J. Li, H .; H. Sun, "Virtual Media (Vmedia) Access Protocols and Applications Application in Interactive Image Browsing", Proc. SPIE Conf. on Multimedia Computing and Networking, January 22-23, 2001, San Jose, CA, Vol. 4312, p. 99-110
[Non-patent document 2]
M. Boliek, G .; K. Wu, M .; J. Gormish, "JPEG2000 for Efficient Imaging in Client / Server Environment", Proc. SPIE Conf. on App. of Digital Imaging, July 31-August 3, 2001, San Diego, CA, Vol. 4472, p. 212-223
[Non-Patent Document 3]
Boliek et al., “JPEG 2000 for Efficient Imaging in Client / Server Environment”, Proc. SPIE Conf. on App. of Digital Imaging, July 31-August 3, 2001, San Diego, CA, Vol. 212-223,
[Non-patent document 4]
R. Fielding, J.M. Gettys, J.M. C. Mogul, H .; Flystyk, L.A. Masinter, P .; Leach, T .; Berners-Lee (eds.), "Hypertext Transfer Protocol_HTTP / 1.1", RFC2616, June 1999.
[Non-Patent Document 5]
Sachin Deshpande and Wenujn Zeng, “Scalable Streaming of JPEG2000 Images Using Hypertext Transfer Protocol”, Proc. ACM Conf. on Multimedia, October 2-4, 2001, p. 372-381
[Non-Patent Document 6]
Wright, R .; Clark, G .; Polymer, "An implementation of JPIP based on HTTP", ISO / IEC JTC 1 / SC 29 / WG 1 N2426, February 14, 2002, Elysium Ltd. , UK
[Non-Patent Document 7]
D. Taubman, "A Very Simple Proposal for JPIP," ISO / IEC JTC 1 / SC 29 / WG1 N2445, March 13, 2002, University of New South Wales, Australia
[Non-Patent Document 8]
R. Prandolini, S .; Houchin, R .; Clark, "Call for JPIP Technology Proposals", ISO / IEC JTC 1 / SC 29 / WG 1 N2550, March 21, 2002
[Non-Patent Document 9]
Canon, "Proposal for JPIP Tier2 protocol", WG1N2608, June 28, 2002
[0011]
[Problems to be solved by the invention]
The present invention provides a method and apparatus for transferring a portion of a code stream using a communication mechanism.
[0012]
[Means for Solving the Problems]
According to one embodiment, the method of the present invention comprises transmitting a request over a network and converting a tile part of a JPEG2000 compliant code stream as a return type, such as part of a response from the network to the request. Receive.
[0013]
BEST MODE FOR CARRYING OUT THE INVENTION
The invention will be more fully understood from the following detailed description and the accompanying drawings, which illustrate various aspects of the invention. However, the following description and accompanying drawings should not be used to limit the invention to any particular embodiment, but only for explanation and understanding of the invention.
[0014]
A method and apparatus for communicating a portion of a JPEG2000 image (or other compressed image) via a network will be described. A description will be given of a request and response communication syntax that enables access to images and objects based on HTTP. The file format object is accessed by specifying a box, and the codestream elements are returned in tile parts, ie, the original elements of the codestream. A protocol that interprets the request syntax and defines the response is also described. An architecture for splitting an image communication attempt is presented.
[0015]
〔Overview〕
FIG. 1 is an explanatory diagram of a transport protocol for realizing image access. In FIG. 1, the client issues an initial request 106 to a server (eg, an Apache server, a dedicated image server, etc.). The server stores a JPEG2000 file that includes at least one JPEG2000 codestream that can be decompressed to obtain image 102. The system delivers a portion (eg, tile parts) of the JPEG2000 codestream 101 to the client via the return channel 104. The client can use the previously received tile 103 as a legitimate JPEG2000 codestream and decode this codestream to form a portion of the image. The image on the client side is smaller than the image on the server in some way, for example, the spatial area is reduced, the quality is reduced, the number of components is reduced, or the resolution is reduced. There is. The distribution is performed via a communication facility such as a network (eg, a local area network (LAN), a wide area network (WAN), the Internet, the World Wide Web (WWW), etc.). In one embodiment, the system uses HTTP / 1.1 with certain parameters and extensions to access the JPEG2000 file from a remote location. In one embodiment, to accomplish this, existing features of both the HTTP / 1.1 and JPEG2000 file formats and codestreams are used as detailed below. In another embodiment, the system utilizes other protocols, such as, for example, TCP / IP, UDP, SONET, to access JPEG2000 files.
[0016]
In one embodiment, there is support for various partitions between the client and the server. On the client side, an image object is used, and on the origin server side (ie, there may be an intermediate server between the client and the origin server), a byte range is used. A series of stages is used to go from the image object to the byte range. The transition from a certain stage to the next stage is performed via a network, by an HTTP connection, or locally using a function call. Protocols and multi-level APIs for both clients and servers are defined.
[0017]
A very wide variety of clients make use of the teachings herein. In one embodiment, clients that do not have memory external to the display device are provided with image objects. In another embodiment, one or more clients of the system have a better understanding of JPEG2000 than a typical server and specify the desired codestream portions.
[0018]
Alternatively, a protocol that is not based on HTTP may be used. However, protocols that are not based on HTTP include firewall traversal, proxy and caching technologies (eg, those available on the World Wide Web (WWW)), security, authentication, and document modification time determination technologies. There is a need to provide a way to acquire more than one function.
[0019]
Although the transport techniques described below operate on any JPEG2000 file or codestream, these codestreams divided into tiles are transported more efficiently. In one embodiment, a JPEG2000 file is prepared for transport before using the protocol. Therefore, the protocols described herein need not be optimized for all types of JPEG2000 files created. This significantly reduces the number of required syntax elements and the processing required on the client and server side.
[0020]
[Transport architecture]
FIG. 2 is an explanatory diagram of one embodiment of the transport protocol software structure. Communication between the client and the server can be thought of as going through four stages as shown in FIG. In one embodiment, these four stages include a decompressor or decompressor (stage 1), a viewport-image mapper (stage 2), an image object wrapper (stage 3), an image object request-byte range A converter (stage 4).
[0021]
Referring to FIG. 2, the client includes an application 200, such as a web browser, and the server includes a file system or on-the-fly image generator 205. In one embodiment (see, eg, FIG. 3), all JPEG2000 functions for handling JPEG200 files reside on the server, ie, a first stage 201, a second stage 202, a third stage 203, and a second stage. All the four stages 204 exist on the same system as the file system 205. The client application 201 sends a complete image file in a recognized format (eg, JPEG format). This is valid for conventional clients. This is because the server can return an image that can be used by the client application 201 (return JPEG or PNG). Alternatively, this is useful for conventional clients when the memory or computing power of the client application 201 is very limited.
[0022]
At each stage shown in FIG. 2, the request type is converted from one tier (tier) to another or the response type is converted from one tier to another tier. Here, each tier is a type of communication. Thus, client end requests and responses are considered to be image objects. In one embodiment, the image object is an area of the screen, or a piece of paper, on which it is desirable to place the image that fills these areas and the uncompressed color conversion bits. On the file system side, the communication is performed in the byte range. In one embodiment, byte-range communication consists of a sequence of fseek () and read () calls used by a C language program. In another embodiment, byte-range communication consists solely of a free () call with unnecessary data discarded. It should be noted that the teachings of the present invention are not limited to C programming, but other programming languages or systems (and associated calls) may be used. For example, Microsoft Computer of Redwood, Washington has a product that uses a different set of calls. It is also possible to use Java from Sun Microsystems of Mountain View, California to perform byte range communication in another manner. Also, the file may be loaded into memory and use memory access.
[0023]
In one embodiment, the partition between the client and the server can be made at any of the five locations shown in dotted lines in FIG. In one embodiment, the client includes a first stage process so that communication with the server can occur in a compressed format. A client (eg, a web browser) performs JPEG2000 decompression using the library. In one embodiment, when the client and server are separated by a particular dotted line, communications beyond that dotted line are performed using HTTP. In such a case, in one embodiment, if the client or server includes both sides of the dotted line, the communication is by function call.
[0024]
More specifically, in FIG. 2, T1 represents byte-range access, T2 represents JPEG2000 image object access, and T3 represents viewport / full image access. When the partition between the client and the server is between the second and third stages, the client makes an http request for a JPEG2000 image object. When the partitioning of the protocol takes place between the fourth stage and the file system 205, the client has all the JPEG2000 knowledge.
[0025]
FIG. 3 is an explanatory diagram of the third tier communication in which the division between the client and the server is performed between the client application 200 and the decompressor (first stage). There are many potential uses for this configuration. For example, it can be used for clients that do not have a cache and only have a DCT-based JPEG decoder. This partition is also used for APIs for applications connected to the local server or for situations where backward compatibility with existing browsers is required.
[0026]
FIG. 4 is an explanatory diagram of a third tier request and a second tier response in which the division between the client and the server is performed between the first stage and the second stage. Potential applications for this configuration include simple and efficient transport, pan and zoom clients, and browsers with JPEG2000 plug-in or native support for JPEG2000.
[0027]
FIG. 5 is an explanatory diagram of a second tier request and a second tier response in which the division between the client 201 and the server 202 is performed between the second stage and the third stage. Such a system has potential applications where the client knows the needs of the user more than the server.
[0028]
FIG. 6 is an explanatory diagram of the first tier request and the first tier response in which the division between the client and the server is performed between the fourth stage and the file system 205. This can be used if the server does not recognize JPIP.
[0029]
FIG. 7 is an explanatory diagram of a situation in which a proxy server is used. Referring to FIG. 7, there are partitions between the first stage and the second stage, and between the fourth stage and the file system 205. More specifically, the proxy server 703 is responsible for the second to fourth stages. In one embodiment, file system 205 is an Apache server. In this embodiment, a conventional server (eg, an Apache server that supports byte range requests) is used, and the pan / zoom of the JPEG2000 client is supported in a well-known format, and an intermediate proxy server. Is used. Although only one proxy server is shown in the figure, two or more servers that handle one or more stages may be provided between the client and the server. Alternatively, the number of stages handled by the proxy server 703 may be more or less than stages 2 to 4.
[0030]
With this architecture, the client-server interaction is not limited to one time. For example, the client application contains code that communicates only with the full image object. To display an image, a client application communicates with a local server. This local server may be connected by a high bandwidth connection. In contrast, the server communicates with another server over a low bandwidth connection using a third tier request and receives a second tier response. This second server may be the "origin" server of the image, or may communicate via high bandwidth communication with a "dumb" server that only recognizes byte range requests. Each of these servers can maintain a cache.
[0031]
The components within the client or server can be divided into stages as shown, but need not be. The server may house, for example, a single code body that collectively handles a number of stages from the second stage to the fourth stage. This makes it possible to store certain image information such as a main header only once without duplication in various stages.
[0032]
[First stage: Stretcher (decompressor)]
In one embodiment, the decompressor stage converts the second tier response sequence and the current "viewport" into image data. The viewport is a part of the entire image of interest of the client. Viewports are often a subset of components, low resolution, or a small spatial area. In essence, the decompressor stage runs a "normal" JPEG2000 decompressor on the received data and decodes the region desired by the client. In one embodiment, the decompressor is implemented by running a decoder to produce a full image at full resolution, cropping to the region of interest, and scaling to the resolution of interest. In one embodiment, only the portions of the file that are needed for the desired resolution, region, components, and quality are decoded. This saves computational resources and memory. In an alternative embodiment, the system has already decoded the entire image with the desired number of components and the desired resolution.
[0033]
In one embodiment, the decompressor uses a decoder in Kakadu style JPEG2000. The kdu_expand program enables low-resolution decoding, decoding of a focused area, and reduction of the number of components. There is a directional relationship between the window query and the command line of the decoder.
[0034]
In one embodiment, the decompressor does not actually start the kdu_expand program, but instead gathers equivalent functions into a dynamic link library (DLL). In one embodiment, the decompressor uses the received JPEG2000 codestream and an external file for the decoded image displayed on the screen. This allows easy caching when the client is terminated. In one embodiment, rather than using an external file for the decoded image, the JPEG2000 library is called to store the image in memory. Thereby, the response speed can be increased.
[0035]
Other JPEG2000 libraries may be used instead of Kakadu. For example, a library that extends the requested region to the nearest tile boundary and decodes all tiles may be used. Clients can use this library to speed up image display as they pan without intersecting tile boundaries. Images decoded using this library are cropped to show only the view requested to the user, but with a slight change in the viewport, a simple re-cropping of the already decoded image Display is performed. Similarly, when the user's area request is included in material from new tiles, it is possible to decode only those tiles and add them to the reconstructed image in memory. In this case, running the JPEG2000 decoder on the complete client's view is only necessary to improve the quality of the displayed image when new encoded data is received.
[0036]
[2nd stage: Viewport to J2K Mapper]
This viewport-JPEG2000 mapper stage uses information about the JPEG2000 file to convert the viewport request into tile parts. In one embodiment, this stage requests header information if it has not already obtained it. In one embodiment, this stage holds a copy of the image header information so that future viewports can be immediately converted to JPEG2000 tile parts. This stage maintains a list of responses that have been transferred to the first stage to avoid repetition of requests for image objects already transferred to the first stage.
[0037]
For communication by tile parts, mapping of a viewpoint to a set of tile parts is performed. The mapper defines a desired area of the image as a "reference grid units" defined in JPEG 2000 Part 1 standard (ITU-T Rec. | 800 ISO / IEC 15444-1: 2002-JPEG 2000 Imaging Coding Standard). ) ". The mapper uses the XTsiz, YTsiz, XTOsiz, YTOsiz, XOsiz, and YOsiz portions of the SIZ marker segment to determine which tile part intersects the region of interest. The resolution, quality and area obtained from the third tier request syntax are used to determine the required tile parts. In one embodiment, the mapper focuses only on tile parts that intersect the region of interest (as specified by the query string) when specified by an SIZ marker that specifies the location of the tile part.
[0038]
More specifically, the viewpoint is mapped to a set of tile parts for communication using the tile parts. Portions of the image (resolution, spatial domain, quality and components) are provided to the client request either explicitly or using default values. The mapper converts a desired area of the image into a reference grid unit specified in JPEG 2000 Part 1 standard (ITU-T Rec. | 800 ISO / IEC 15444-1: 2002-JPEG 2000 Imaging Coding Standard). The reference grid unit of each tile part is determined by the XTsiz parameter, the YTsiz parameter, the XTOsiz parameter, and the YTOsiz parameter of the SIZ marker segment in the JPEG2000 codestream. Only tile parts from tiles that intersect the requested area are sent. Which tile part of a tile to send depends on the required resolution and quality and how the encoded data is organized into tile parts. In one simple embodiment, one tile part is used for each resolution from low to high. In this case, the number of tile parts to be distributed depends only on the requested resolution.
[0039]
FIG. 9 is an explanatory diagram of the correspondence between the viewport inquiry parameter and the SIZ marker segment parameter. Referring to FIG. 9, XTOsiz, YTOsiz, XOsiz, XTsiz, YTsiz, Xsiz, and Ysiz are all obtained from the SIZ marker segment, and xo, yo, w, and h are viewport request parameters. The correspondence between the two parameter sets is as follows. Xsiz−XOsiz represents the number of reference grid samples corresponding to 1.0 in the horizontal direction in the query parameter space, and w and xo are converted to reference grid units by multiplying by (Xsiz−XOsiz). Similarly, for the vertical direction, h and yo are converted to reference grid units by multiplying by Ysiz-YOsiz.
[0040]
In one embodiment, information about each tile part is stored in a structure. This structure may be a memory for the second stage. This structure is a two-bit structure, one bit specifies whether the tile part should be sent to the client for the current request, and the other bit specifies whether the tile part has been sent. I do. Thus, there are two bits for each tile part. If the tile part is present in the cache, the second bit is turned on, indicating that the tile part need not be transmitted. If the tile part is not in the cache, the tile part is sent to the client as needed, as indicated by the first bit, and the second bit is turned on to prevent retransmission. Alternatively, this structure can be extended to store information indicating the priority of each tile part, instead of using only one bit indicating whether transmission is allowed.
[0041]
From the codestream, the SOT markers give the details of the tile index and the number of bytes required for each tile part. In one embodiment, from the codestream, the appropriate bytes corresponding to the tile parts to be transmitted are transmitted to the client side. When the viewport changes and the corresponding associated tile changes, only the tiles that have not been transmitted earlier are transmitted to update the displayed image.
[0042]
[Third stage: Image object wrapper]
The third stage obtains a byte range response and creates an image object. In one embodiment, the image object wrapper temporarily stores a sequence of image object requests. As a result, the response from the fourth stage, for example,
HTTP / 1.1 200 OK
[Other header line]
Content-Range: 200-500 / 23382
CRLF
Data
Is converted to an image object representation response. If only complete tile parts are returned, this stage will only remove the "Content-Range" line from the HTTP response. In one embodiment, this stage wraps (wraps) the data in different headers.
[0043]
In one embodiment, the third and fourth stages are fully integrated. This combined stage will execute fseek () and read () calls to obtain the desired data, wrap the returned data in an HTTP response, and supply it to the second stage.
[0044]
In one embodiment, the transport protocol is extended to support non-self-labeled objects, unlike tile parts and boxes. In this case, the image object wrapper wraps the returned data with the identifier. In one embodiment, this wrapping has the form:
Packet: = 0 & layer = 0 & component = 2 & position = 5 & tile = 7
HTTP header may be used. This new header may be a sequence of bytes in the message body that precedes the encoded data.
[0045]
[Fourth stage: J2K-byte range converter]
The J2K to byte range converter (4th stage) is responsible for converting compressed image object requests to byte range requests. In one embodiment, this requires making several byte range requests to obtain the main header, the location of the various codestream boxes, and the tile parts. In most cases, this converter temporarily stores information to prevent multiple accesses. The converter returns only the requested image object, even if multiple reads are needed to determine the location of the request that references the byte range of the tile part in the JPEG2000 file.
[0046]
In one embodiment, before sending the header, the server parses the JPEG2000 file until the header of the JPEG2000 codestream is reached. At this time, the server sends the codestream header or the parsed file to the converter. In this way, the converter ignores all data before the start of the codestream box header, indicated by 0x6A703263. All tile parts in the codestream start with a SOT marker segment. The SOT marker segment contains the length of the tile part. The converter reads the SOT marker to obtain the length of the tile part, saves the length of the tile part and the location of the tile part in a JPEG2000 file, and the converter proceeds to the next SOT marker. Thus, after the viewpoint-J2K mapper indicates that it requires a set of tile parts, the converter obtains the corresponding file location of the tile parts from the created memory structure. That is, the converter parses the file, stores the tile parts in the memory, and sends the tile parts to the client. The TLM marker in the main header of the code stream stores the location and length of the tile part. Thus, in one embodiment, the TLM marker is used to determine the location of a tile part in a JPEG2000 file.
[0047]
In other words, the byte range request is made using a TLM marker segment in the main header of the JPEG2000 codestream or by reading each TLT marker (and proceeding to the next TLT marker segment). . In any case, the fourth stage can build a list including four entries: the tile index, the number of tile parts, the offset from the beginning of the file, and the length of the tile parts. . The tile index, the number of tile parts, and the length are all part of the TLT marker segment. As the fourth stage reads each TLT marker segment, the fourth stage can save the offset from the beginning of the file. Next, when a request is generated for a particular tile index and part number, the fourth stage finds the tile part in the generated list. The entries in the offset and length lists are used for byte range requests.
[0048]
During parsing, the converter reads all bytes before the JPEG2000 codestream. Speedup is achieved by reading the "box" header, that is, by reading the "box" type and "box" length and skipping unrelated boxes.
[0049]
In one embodiment, the converter is connected to a file system and makes a system call to read a file. The converter is connected to a server that does not support JPIP but does support byte range requests (eg, Apache server). Alternatively, this stage may connect to a database responsible for storing JPEG2000 images.
[0050]
[The third tier returns a JPEG file or PNG file]
The third tier response is a complete image object. In one embodiment, the third tier response is a PNG or JPEG file suitable for filling the viewport.
[0051]
[2nd tier returns box and tile parts]
Since the second tier returns the box and tile parts without further wrapping, the response to the request can be concatenated to form a valid JPEG2000 file or codestream. This is typically performed by a client or computer system or device that performs the first stage. The client can use a JPEG2000 decoder that does not understand PIP or transport. The local disk cache for the browser is filled with valid images that can be copied to another directory, and if the valid images are not copied to another directory, they are manipulated as JPEG2000 files.
[0052]
In one embodiment, the transport protocol uses HTTP, which assumes a reliable ordered channel. As a result, the client or the stage does not need to perform some error detection.
[0053]
[Transport protocol definition]
[Request syntax]
The request may be made in three tiers: a third tier "whole image object", a second tier "encoded data object level", and a first tier "byte range". However, in one embodiment, all requests use HTTP syntax and some overlap occurs. For example, a request for data other than an image, for example, a box in JPEG2000 is the same at the image and object levels. In addition, while the client may want to access most data at the image level, some of the metadata, such as the sound associated with the image, (particularly may interfere with the use of other channels) It is accessed in byte range (if it is large enough to do so). For example, when no more than about 2000 bytes of metadata are needed, the overhead of making the request is compensated. Accessing certain types of data in the byte range allows JPEG2000 files containing metadata that the server does not understand to be accessible in smaller units than the entire box.
[0054]
[Third Tier Request]
In one embodiment, the third tier request is:
GET filmname. jp2? res = 2 HTTP / 1.1
Host: true. crc. ricoh. com
CRLF
Is represented as
[0055]
These are all components of a standard HTTP request. "GET" is a method. "Filename.jp2" is a file name or, more generally, a complete URL, and may be a complete path from the server's root directory. All items after the “?” Are “name = value” pairs typical of CGI interactions. This query string does not include spaces (they can be embedded as% 20). HTTP rfc, for example, Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee (eds.), "Hypertext Transfer Protocol. This document will be referred to as the HTTP standard in the following description. The final HTTP / 1.1 defines the protocol. Some of the protocols work with versions of HTTP earlier than version 1.1. The HTTP request ends with two carriage return and line feed pairs. “CRLF” represents a carriage return and a line feed, but in this example, that character is omitted at the end of each line unless it is the only character in the line.
[0056]
In one embodiment, instead of including the parameters in the query string of the HTTP GET request, the parameters are included in the body of the HTTP POST request. This is effective when the options described later are long.
[0057]
In one embodiment, an example of a POST request is:
POST / cgi-bin / j2k_server. cgi HTTP / 1.1
Host: true. crc. ricoh. com
Content-type: Application / x-www-form-urlencoded
Content-length: 26
CRLF
filename = picture. jp2 & res = 2
It is.
[0058]
The options available for describing the third tier viewport are listed in Table 1 below. The auxiliary parameters that affect the requirements are listed in Table 2. These options are the same for the get and post methods.
[0059]
[Table 1]

Note that not all of these parameters are required. Some parameters take default values, for example, by default all components are sent for regions that match the image. In one embodiment, they may all be omitted and default values are used.
[0060]
[Description of parameters]
The parameters xo, yo, w, and h specify the area of the image. 0 represents the upper left end, and 1 represents the lower right. The width and height designate a fraction of the image, and 1 represents the total height or the total width. Thus, in one embodiment, xo = 0 & yo = 0 & w = 1 & h = 1 specifies the entire image (default). In contrast, the central section of the image is given by xo = 0.25 & yo = 0.25 & w = 0.5 & h = 0.5. The left end is located at the position of XOsiz on the reference grid, and the upper end is located at the position of YOsiz. FIG. 9 and the definition of SIZ marker in Appendix A of Part 1 [ITU-T Rec. T. 800 | IS 15444-1: 2000, Information Technology_JPEG 2000 image coding system: Core coding system].
[0061]
The parameter res is the number of resolutions for reducing the image. res = 1 reduces the image horizontally and vertically by a factor of about two. Since this reduction is performed in the JPEG2000 manner, the width of the grid point of the image 7 is reduced to 4 or 3 samples depending on the value of the offset of the SIZ marker.
[0062]
The parameters maxw and maxh specify the maximum number of samples that the client is interested in receiving. This is an alternative to using the “res =” parameter to specify the amount of reduction. For example, a client that does not know the size of the original image requests a maximum height or width image containing 128 samples. The server reduces the resolution. The server reduces the resolution until the request is satisfied or only the LL subband is returned. Thus, if the zero level of the wavelet transform is utilized during compression, a 128 × 128 maximum image request may continue to return a 512 × 512 image (but is unlikely).
[0063]
The component parameter is a character string that specifies which component to incorporate. In one embodiment, components are numbered from zero. A range may be used. Thus, component = 0-2,5 returns, for example, components 0,1,2 and 5.
[0064]
The quality parameters help the server determine the amount of data to send. The server may choose to use the quality value as the number of layers to return. In one embodiment, the requirement of 0xFFFF for quality is to request all data held by the server for tile parts in the region.
[0065]
Table 2 lists a set of auxiliary parameters that are used with the query to control other aspects of the response. The third tier value requires a response as a complete image in "png" or DCT based JPEG format.
[0066]
[Table 2]

The box parameter is one way to specify a list of boxes that the client is looking at. Boxes are defined for various JPEG2000 file formats in JPEG2000 Part 1, Part 2, Part 3, and Part 6. These are at the top level of the codestream. Boxes inside boxes are requested by listing the superboxes and subboxes. For multiple boxes, the server chooses to return all boxes of that type or only the first box of that type. The range of the box is specified using parentheses. A range of the form [0-] guarantees that the server will return all boxes of this type.
[0067]
The maximum box size parameter can cause all boxes less than the specified number of bytes to be returned. This will allow you to get all the boxes that will be present, unless the communication gets very slow.
[0068]
It should be noted that boxes of the type that use characters outside the range of the acceptable set are URL encoded. For more information on URL encoding, see RFC 2396, HTTP rfc [HTTP standard].
[0069]
If neither the box nor the knot box is listed, the server determines which box to return. In one embodiment, the server returns all boxes, returns all boxes prior to the codestream, returns all boxes specified by the creator of the image when storing the image on the server. Or return no boxes at all. In one embodiment, the server's configuration file allows any or all of these options. Portions of the codestream are returned unless Notboxes = jp2c.
[0070]
Examples of required parameters, value pairs, and their meanings are as follows.
boxes = jp2h
get the JP2 Hearser box.
boxes = jp2h / ihdr
get only the Image Header box without the JP2 Header box
boxes = uuid [5-7]
get the 5 ^th 6 ^th , And 7 ^th UUID boxes (if the exists).
maxboxsize = 4096
return boxes 4096 bytes or smallr
[0071]
The priority parameter indicates the importance of one request to another. If the new priority matches the previous priority, the server will continue to send bytes for the old request, if valid for the new request. If the difference between the new priority and the old priority is 1 or more, the server stops the old request at the next opportunity and starts a new request. If the priority is "Inf", the server stops old requests for new requests. When the server has finished sending data that applies to the current request, the server may choose to send data for a previously interrupted request later.
[0072]
[Auxiliary HTTP header line for third tier]
Table 3 below shows two header lines that can be used to specify data available on the client side.
[0073]
[Table 3]

The T3 cache allows the client to specify a region already received in the current session or a previous session. The server uses this T3 cache to calculate tile parts so that tile parts sent in response to a request are not sent again. Servers may ignore this parameter. For example, a server that lacks the ability to recognize will ignore this parameter.
Example:
T3chae: xo = 0.0 & yo = 0.0 & w = 0.25 & h = 0.25 & res = 2
T3chache: maxw = 128 & maxh = 128
[0074]
The content of the cache is a response to the preceding viewport request. In one embodiment, there is one request per T3 cache line. This request is not sent as part of the query string, but is sent as an HTTP header line. If a T3 cache is used, the main header is considered to have been received. The client does not have to create a list of all cached requests. In effect, the client lists each request received and uses this line as an acknowledgment. The server can translate the previous request into a list of tile parts and mark these tiles as sent. Therefore, these tile parts are not resubmitted when the current request is translated.
[0075]
The T2 cache allows the client to create a list of received tile parts. The syntax is defined as follows: This corresponds to the typical method of requesting tile parts. Again, in one embodiment, this line is not part of the query string, but an HTTP header line. An example is as follows.
T2cache: 4.0, 4.1, 5.0-6.2
[0076]
[Second Tier Request]
The second tier supports requests for boxes in the same way as the third tier. Tile parts can be explicitly requested using an HTTP range header. Efficient use of the second tier request for tile parts depends on the client and server agreeing to divide the encoded data into tile parts. Tiles must be divided into tile parts at any resolution or any layer, or otherwise. One effective partitioning method is described in detail below. An example of the second tier request is as follows.
GET file. jp2 HTTP / 1.1
Host: true. crc. ricoh. com
Range: tiles-parts = 4.0, 5.0, 8.0-9.2.
CRLF
[0077]
The value before the period is the tile number, and the value after the period is the tile part number. See Isot and TPsot from Appendix A of JPEG2000 Part 1 (Literature: ITU-T Rec. T. 800 | IS 15444-1: 2000, Information Technology_JPEG 2000 image coding system: Core coding system. In one embodiment, the tile number and the tile part number are both numbered from 0. The range of tile parts includes all tiles from the start tile to the stop tile, and all parts for these tiles from start to stop. For example, 8.0-9.2 is equivalent to 8.0, 8.1, 8.2, 9.0, 9.1, 9.2.
[0078]
In one embodiment, the tile part has two parameters (Isot for tiles and TPsot for parts), so it is better to use a new HTTP header line instead of "Ranges" designed for a one-dimensional range. Good. For example, the “Tile-part:” header is
Tile-parts: 8.0,. 8.1, 10.0-12.2.
Used like.
[0079]
[First Tier Request Syntax]
The first tier request is a strict byte range request as specified in HTTP (HTTP standard). For example,
GET file. jp2 HTTP / 1.1
Host: true. crc. richo. com
Range: bytes = 200-500, 1000-1500
CRLF
It is.
[0080]
As described above, the request is 300 bytes starting at position 200 and 500 bytes starting at position 1000. Such a request is typically only valid if the client knows what to expect in a given byte range. However, these requests are useful, for example, for accessing a portion of an audio stream without transferring the entire audio stream associated with the image.
[0081]
In one embodiment, rather than creating a list of cache information on a separate line, the client can incorporate the cache information into the HTTP query string itself. For example, if the user has the following query string:
GET filename. jp2? xo = 0.0 & Yo = 0.0 & w = 0.25 & h = 0.25 & res = 2 & maxxx = 750 & maxy = 750 HTTP / 1.1
Consider the case of inputting
[0082]
The client analyzes the file in the cache in the same way as analyzing the file on the server side as described in the second stage (viewport to JPEG2000 mapper). The client forms a list of tile parts already held in the cache and adds the list to the query string before sending it to the server. Thus, the server sends the query string:
GET filename. jp2xo = 0.0 & yo = 0.0 & w = 0.25 & h = 0.25 & res = 2 & maxxx = 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
To get.
[0083]
Of course, various syntaxes can be used to specify the viewport. The latest version of the JPEG200 Part 9 standard uses a syntax similar to the following syntax. Most parameters can be translated by those skilled in the art between the various types of request syntax.
[0084]
[Table 4]

[Description of parameters]
The parameters Offset = Px, Py and Size = Sx, Sy are regions of the image starting from the leftmost Px sample, extending to the right by Px samples, starting from the top Py sample, and extending downward by Py samples. Is specified. The case where the left end is at the position of XOsiz of the reference grid and the top is at the position of YOsiz is considered. See Appendix A of JPEG2000 Part 1 for the definition of the SIZ marker segment. These samples are at the resolution specified by the frame size parameter.
[0085]
The parameter Frame-size = Rx, Ry is the resolution at which the client wants to see the image. Rx and Ry vary from 0 to the dimensions of the image. However, in the JPEG2000 domain, the decoded image can only be viewed at a finite level of resolution. Therefore, in response to the client's request, the server transmits the resolutions R'x and R'y such that R'x≥Rx and R'y≥Ry. If R'x and R'y are different from Rx and Ry, the server needs to send this information in the header. As described in JPEG2000 Part 1, the reduced resolution image is rounded at the left (left) and right (right) edges, depending on the exact location. For example, the width of the grid points of the image 7 is reduced by four or three samples depending on the offset value of the SIZ marker.
[0086]
Depending on R'x and R'y, the offset, width and height of the upper left corner of the requested area are:
P'x = Px * R'x / Rx, P'y = Py * R'y / Ry, S'x = Sx * R'x / Rx, and S'y = Sy * R'y / Ry
Where P'x and P'y represent the actual offset and S'x and S'y represent the actual width and height of the image displayed on the client-side canvas.
[0087]
The component parameter is a list of integers that specifies which components should be taken. Components are numbered sequentially from 0. A range may be used. Thus, Components = 0-2,5 returns components 0,1,2 and 5.
[0088]
The L = quality parameter helps the server determine the amount of data to send. The server may choose to use the quality value as the number of layers to return. In any case, a request of 0xFFFF for quality requires all data that the server has about tile parts in the region.
[0089]
The parameters Bh and Bs are optional parameters, and the server can use these parameters to set a hard limit or a soft limit on the number of bytes actually transmitted. Low-resolution tile parts are transmitted first, and high-resolution tile parts are transmitted until this limit is reached. If this field is not present, the server can send the required tile parts to display the requested area at a particular resolution.
[0090]
If the flag ADD is set to yes (yes), a new request can be linked to a previously requested window. By default, this flag is disabled and when a new window is requested, the client replaces the previous window.
[0091]
[Response syntax]
[Third Tier Response]
The third tier response is a complete image object. In one embodiment, the image object is a PNG or JPG file suitable for filling the viewport. This type of response is as follows:
HTTP / 1.1 200 OK
Content-type: image / jpeg
Content-length: 20387
CRLF
JPEG Compressed Image Data
[0092]
Note that it is preferable to use chunked transfer coding as described with respect to the second tier response below, but it is not necessary to use chunked transfer coding.
[0093]
[2nd tier response]
The second tier response consists of the requested box wrapped in the HTTP header and sent using chunked transfer encoding, the codestream main header (if previously sent), and the concatenated request. Tile parts. It is important that the second tier response can be interrupted in the middle of the transmission as it can be very large and take a very long time to transmit. For example, an image containing 1K × 1K tiles will give a 1.5 megabyte response (this takes a long time if using slow links). Unless the chunked transfer encoding is specified, the HTTP request needs to specify the full length of the body of the "Content-Length:" header or indicate the end of the data by closing the connection. Both are feasible, but not desirable. This is because it is desirable to stop the current response and send more data on the same connection for a new request. In the case of chunk format, the length of each chunk is transmitted, and a zero length is transmitted to end the response. Thus, once a chunk is started, it is necessary to end the chunk, but it is not necessary to complete all responses before ending the response.
[0094]
An example of a chunk format response is shown below.
HTTP / 1.1 206 Partial Content
Content-Range: 0-2000, 4000-10200 / 870370
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
[0095]
The first header line in the above example uses the "Partial Content Part" header to indicate that the response is not a complete file. The "Content-Range" header is used to indicate which part of the file will be transmitted. The transfer encoding "Transfer-Encoding:" header is used to indicate that the data is in chunk format. Given the type of data. This is because the response is a decodable JPEG2000 file given the type "image / jpeg2000". Other types may be used.
[0096]
In the case of the response after the first, the response does not store a valid J2K code stream (it is very rare that the main header is not included). In this case, it is desirable to indicate this using another type, for example, "image / jPiP".
[0097]
In one embodiment, if a new request is received after sending the first chunk of 4096 bytes and the server decides to end the transmission, the server completes the current box, main header, or tile part And indicates a zero-length chunk. Next, a new response is started with a new HTTP header.
[0098]
[First Tier Response]
In one embodiment, the first tier response is the same as the byte range response specified in HTTP [HTTP Standard]. It is desirable to use chunked transfer encoding so that the data can be easily terminated.
[0099]
[Request / Response Semantics]
After receiving the request, the server is trying to receive further requests while sending the chunk.
[0100]
If the priority of the new request is sufficient, the server will successfully terminate the current response and begin responding to the new request. In one embodiment, sufficient priority is indicated by an "Inf" priority request. The server finishes the current tile part and sends a chunk size 0 indicating that no more chunks will be sent for the current request. In one embodiment, the server adds the HTTP footer and initiates the next response.
[0101]
If the server receives a priority other than "Inf", the server determines how much of the current request should be continued. If the current request is a good answer to the new request, no action is needed. For example, a new request may be a different view, but still require the same set of parts. If the priority of the new request is one higher than the priority of the previous request, it is proposed that the old request be suspended at the end of the current tile part for the new request.
[0102]
Finally, in one embodiment, the server sends a simple response that matches all requests. Alternatively, a specified syntax is used to indicate that the response answers multiple requests. In this case, the server continues to send tile parts associated with the new or old request without stopping the current transfer and starting with a new HTTP header. In one embodiment, in this case, the server does not use a "Content-Range:" header when initiating a request that can be extended.
[0103]
[Server data storage format]
In one embodiment, the transport protocol works with all JPEG2000 file formats and codestreams. However, the function in such a scheme is not always efficient. For example, if no tiles are used, a request for a region may return the entire codestream.
[0104]
The most efficient image compression method to use with the transport protocol depends on the nature of the expected access. "Call for JPIP technology proposals" [JPIP Editors (Prandolini, Houchin, Clark), Call for JPIP technology proposals and zooms such as "JP for the 21st and 200th class of ISO / IEC2200 / IEC2J1J2SC / J2J1J2J1J2TC / J2M1J2J1J2J1J2J1 / J2J1J2J1C / J2J1J2J1J2JC / J2M1J2JTC / MJ1J2JC1J2JTC / MJ1J2JCJ2J1J2JC1M2J1J2JTC / MJ1J2JTCJM25J1J2JTCJMCJTCJM2J1J2JTC" For a sequence of operations, using a tile size of N / 16 × N / 16 is superior for rectangular images of size N × N pixels.
[0105]
One progression order for the codestream used is resolution-layer-component-position (RLCP). Tiles can be divided into tile parts at any resolution and at any layer. In one embodiment, all low resolution tile parts are saved to a file before higher resolution tile parts. As a result, the low resolution portion can be obtained by the minimum number of disk accesses. In one embodiment, sufficient quality is stored in the first layer to avoid tile boundary artifacts.
[0106]
In some cases, it is desirable to be able to browse a low-resolution version of a stored image without loss. In the case of RLCP order, lossless image accumulation means that many bits are used for low resolution images. This slows down image pan and zoom browsing due to the slow connection between the client and server. This problem is solved by storing the images on the server in a special way. The layer-resolution-component-position (LRCP) progression order is used for the codestream, but the first layer is mainly used for storing data in resolution order. The last layer is used to store a lossless representation of the image. Since each layer is assigned a unique tile part, the server can provide the desired resolution to the client by sending the complete tile part. For example, a single 256 × 256 tile with three resolution levels is organized as follows.
[0107]
Tile part 0 contains layer 0, which stores 128 bytes of resolution 0 data (total for all components and positions). This provides a fairly high quality but still lossy image (image equivalent to one bit per pixel at viewing resolution) to the client.
[0108]
Tile part 1 contains layer 1 that stores 384-byte data of resolution 0 and resolution 1. The number of bytes of the resolution 0 and resolution 1 data is selected so as to maximize the image quality (image quality) at the display resolution of resolution 1.
[0109]
The tile part 2 contains layer 2 that stores 1536-byte data of resolution 0, resolution 1, and resolution 2. Most bytes have a resolution of 2 and other resolutions are sufficient to obtain optimal image quality at a display resolution of resolution 2.
[0110]
The tile part 3 accommodates a layer 3 that stores 6144 bytes of data having resolutions of 0, 1, 2, and 3. Tile parts 0 to 3 store the optimized 1 bpp image at full resolution.
[0111]
The tile part 4 contains a layer 4 that stores the remaining data of all the resolutions required to obtain a lossless image. Possibly, 24000 bytes are required for a tone image and more bytes for a color image. Of course, the tile part may be divided into auxiliary tile parts in order to obtain a 2.0-bit / pixel image and a lossless image. Alternatively, it may be divided into tile parts in order to maintain a certain maximum tile part size.
[0112]
[Transport protocol performance]
[Disk access and number of required coefficients]
Table 4 below is a list of the number of distinct locations in the file that are accessed by the server responding to the image request. Table 4 also lists the number of coefficients to be transmitted if the entire tile or precinct is transmitted on demand. Of course, the number of bytes to be transmitted depends mainly on the compression ratio, but given equal compression regardless of the size of the tile or precinct, their values are related to the response size.
[0113]
Table 4 represents the data for several different viewpoints, and only shows the auxiliary access / coefficients required for the new viewpoint when the data for the previous request was sent.
[0114]
For the values in Table 4, the commands used for compression are as follows:
Tiling: kdu_compress-ilena. bmp-o out. jp2-rate-, 0.25 Layers = 30 Reversible = yes Stilles = {128, 128}
Corder = RLCP
Tile size: 128 x 128; 256 x 256; 512 x 512; 1024 x 1024 The results for the untiles are listed in the table.
Precincts: kdu_compress-ilena. bmp-o out. jp2 -rate-, 0.25 Layers = 30 Reversible = yes Cprecincts = {128, 128} corder = RPCL
The results for the precinct sizes 32x32; 64x64; 128x128; 256x256; 512x512 are listed in the table, and the same size precincts are used for each resolution.
[0115]
Table 4 should not be taken as a comparison of precincts and tile parts. This is because precincts can use smaller sizes at each resolution than required for the tile.
[0116]
[Table 5]

[0117]
[Table 6]

[Session persistence]
In one embodiment, the protocol avoids retransmission of data, even on multiple connections separated in time by some mechanism. This is achieved by having the client use one of the http headers (eg, T2cache) to indicate the data that has already been sent to the client. An alternative mechanism for providing session persistence is to use a cookie to maintain the session ID, as is done on many commercial websites today. Of course, the server may not keep a record of the session and will only send those parts of the codestream that the client does not consider to have stored at all.
[0118]
[Error processing]
For error handling, HTTP includes various response messages to error conditions. All of these are available for use with this protocol. If an error is detected, retransmission can be requested between stages. The HTTP footer can be used to transmit a checksum of the transmitted data, thereby detecting errors.
[0119]
[Speed (rate) control]
With respect to speed control, the transport-level protocols and libraries that implement sockets, for example, typically ensure that data is not being sent to the client at a rate faster than the client can handle. In most socket libraries, the "send" call blocks or returns an error until a large amount of data is sent, until the data is sent. Sending a large number of responses in chunk form should prevent a single "send" from becoming too large. In one embodiment, parameters such as the maximum bytes parameter are used to limit the number of bytes. Further, the client and / or the server are permitted to perform speed control. This will control the filling of buffers on slow links.
[0120]
The transport protocol does not provide maxh and maxw parameters that allow the client to specify a valid maximum image. The client requests translation into JPEG or PNG.
[0121]
[Support for simultaneous access]
The transport protocol described here does not restrict simultaneous access to the same image on the server. In one embodiment, if a single client opens multiple connections to the same resource on the same server, each connection is handled in the order of the requests for that connection. If the client desires, the client can use the received T3cache or T2cache header to specify data that is not required for a given connection. Otherwise, the server will not know that the two connections are made to the exact same client.
[0122]
In an alternative embodiment, the session key may be appended to HTTP for all levels of request and response to concatenate separate requests. This allows the above protocol to operate without using the default "keep alive" function of HTTP 1.1. This also allows for better use on unreliable networks. It is effective to add a request number in order to arrange requests in a session in order. Thus, even when HTTP is used over TCP, multiple connections can be created and used. The session key can be embedded using a cookie header or as a request parameter.
[0123]
[JPIP request binding]
HTTP can also be carried over channels other than TCP / IP. Therefore, if it is desired to use this protocol on a channel that supports HTTP other than TCP / IP, no new definition is needed. In one embodiment, if it is desirable to specify a protocol binding for a channel that contains uncorrected errors or packet loss, each chunk of the response using chunked transfer encoding will be a unique network packet. All other requests and responses fit within the network packet. In one embodiment, they are given packet numbers in the order sent for the connection priority channel. It should be noted that a protocol other than HTTP may be used.
[0124]
[Capacity exchange and negotiation]
In one embodiment, the capability is requested using the HTTP method "HEAD", which requests only the header of the response, and the client can determine the type of response received using the "GET" request. . One example is
HEAD filename. jp2? res = 2 HTTP / 1.1
Host: true. crc. ricoh. com
CRLF
Is represented as
[0125]
In one embodiment, the capability of the server is the HTTP method "OPTIOINS", eg,
OPTIONS * HTTP / 1.1
Host: true. crc. ricoh. com
CRLF
Is required.
[0126]
In one embodiment, the capabilities of an action on a particular image are:
OPTIONS filename. jp2 HTTP / 1.1
Host: true. crc. ricoh. com
CRLF
Is determined using
[0127]
HTTP 1.1 RFC includes a mechanism to indicate capabilities. For the image protocol described here, the server returns a header containing the following lines:
Accept-Ranges: bytes, tile-parts
Accept: image / jpeg2000; q = 0.9 image / giff; q = 0.5 image / jpigT2; q = 0.95 image / jpipT3; q = 0.1
Allow: GET, HEAD, POST, OPTIONS, TRACE
Vary: accept, *
[0128]
The HTTP 1.1 RFC uses the following headers for the image protocol described here:
Accept-Ranges: bytes, tile-parts
[0129]
“Accept-Ranges: bytes” is a valid HTTP / 1.1 command. In one embodiment, the server uses this in a transport protocol to indicate its ability to respond directly to byte range requests. In such cases, sophisticated clients will accurately extract the desired portion of the codestream or file format.
[0130]
The use of "Accept-Ranges: tile-parts" is one way to indicate the server's ability to respond to direct requests for tile parts.
Accept: image / jpeg2000; q = 0.9 image / gifp; q = 0.5 image / jpipT2; q = 0.95 image / jpipT3; q = 0.1
Note that HTTP indicates not only the capability in the Accept header but also the priority. A JPEG 2000 image server with the ability to transcode images returns a type of viewport request that both the client and the server support at the highest priority. Alternatively, the server may decide to return a lower priority type. This is because the load on the server is lighter (for example, the server may return a type that does not require decompression and recompression when the server load is high). Alternatively, the server may eventually lose bandwidth due to a large number of requests.
Allow: GET, HEAD, POST, OPTIONS, TRACE
[0131]
This HTTP line indicates a command permitted by the server. These commands are used on the image server in the same way as previously used.
Vary: accept, *
[0132]
The Vary header indicates that the response depends on the return type indicating what the client will allow. "*" Indicates that the response may depend on something other than the http header. At the server in the system using the protocol described here, the exact content returned may depend on previous requests. For example, the server does not return a tile part that it is certain that the client already has. This is important for implementing an HTTP proxy. This is because the returned data may not be excellent data for an equivalent request from a client that does not have the same set of tile parts.
[0133]
[Unique identification of image]
It should be noted that HTTP has a mechanism to uniquely identify resources. "Etag" uniquely identifies the response (see section 14.19 of HTTP 1.1 RFC 2616 [HTTP standard]).
[0134]
JPEG 2000 Part I identifies UUID boxes (see ITU-T Rec. T. 800 | IS 15444-1: 2000, Information Technology_JPEG 2000 imaging coding system: Core coding system). . The protocol request syntax described herein allows for the return of a box, which may be required to determine the uniqueness of the image.
[0135]
By using an HTTP header such as "Expires", the client can know when the cached data is no longer valid. See section 14.21 of the HTTP standard.
[0136]
[Image uploading to server]
The complete image can be uploaded using the HTTP method POST. In this case, the syntax looks exactly like any other file upload. The transport protocol allows for the uploading of all tile parts. In this case, the header indicates which tile part is the tile part uploaded using the Tier2 syntax. The client gives all tile parts for each tile uploaded. The server deletes all tile parts of the uploaded tile and stores the new tile parts. The server chooses to store the tile parts in an order different from the order of the original files. In addition, the TLM must be updated. The server may choose to refuse to update the image using the PPM marker segment. Of course, the server may choose not to upload any images or tile parts. Some servers choose to support the HTTP method DELETE. For this method, no special syntax is required for JPEG2000 images.
[0137]
[Other abilities]
The ability to return an image after a single request is useful. The most prominent example is a web page containing an inline image. The image tag allows the image to be returned. The creator of the web page has knowledge of the images to be included, the layout of the page, and has set the URL, so he probably knows the capabilities of the server as well. There is no need for "exchange capabilities" and image acquisition.
[0138]
In one embodiment, in order for a browser to understand JPEG 2000 images, the protocols described individually include:
<Img src = "http://true.crc.ricoh.com/name.jp2?res=2" width = "128" height = "115">
Support calls like This call returns a jp2 file containing the low resolution part. In one embodiment, the browser scales the image, such as a JPEG image and a GIF image, to fit nicely into the 128 × 115 window desired by the author.
[0139]
To ensure that all browsers can read the image, the image tag can require that the image be converted to PNG (or GIF or JPEG).
<Img src = "http://true.crc.ricoh.com/name.jp2?res=2&tier3=PNG" width = "128" height = "115">
[0140]
Even if the server continues to access the JP2 file, it will be converted before delivery.
[0141]
[Extension / Alternative]
[Use POC markers to rewrite tile parts "on the fly"]
In one embodiment, the protocols described herein are useful only for tile parts that appear on the server. Different areas may be accessed in a random order, but all tile parts are accessed in a sequential order. Thus, if the client wants to access component 2 and components 0 and 1 are initially stored in the tile part, unsolicited data will be sent, as in all typical progression orders. You.
[0142]
However, in an alternative embodiment, the server can rearrange the tile parts within the tile so that they are in the order requested by the client. In one embodiment, the server uses JPEG2000 standard POC markers for each tile part to specify the resolution, layers, and components stored in the tile part. This requires buffering on the server side. Caching is even more difficult. This is because the server knows the situation where the code stream is rearranged. In one embodiment, this is done by tracking the request command. In one embodiment, the server uses internal data structures to make requests and responses. In one embodiment, the server writes the copies of the file in the order requested by the client.
[0143]
Consider a case where the server stores a three-component JPEG2000 file in which one tile part is arranged in RLCP order for each resolution. Further assume that there is only one layer and one precinct for one tile part. At this time, the tile part data is
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
Will look like.
[0144]
If the client requests only the first component (number 0), the server sends all tile parts containing data from components 1 and 2. This is inefficient when there is a large amount of data for components that you do not want. Therefore, the server creates a tile part that does not actually appear in the file containing only the first component, and transmits it to the client. The main header indicates that there are two or more components in the file, so the server indicates that this tile part contains only one component. The server can modify the file to reorder the situation using several methods.
[0145]
The progression order may be changed to CPRL, and the client expects component 0 to appear first. This works if the client requests component 0 instead of component 2 first.
[0146]
Packets for other components can be modified to carry zero data. This is equivalent to changing the layer assignment so that data for other components does not appear until a later packet. However, to serve as a placeholder, it is still necessary to include a one byte packet header for each skipped packet. In addition, when data from other components is required, the packet header must be written to incorporate the correct layer information.
[0147]
In one embodiment, the POC marker segment is contained in a tile part header. The tile parts are
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)
Is represented as
[0148]
This tile part stores only requested data. Further requests create new tile parts, which include new POC markers that store only the requested data.
[0149]
The packets themselves do not need to be changed, only the order in which they are sent.
[0150]
In any case, one important advantage of this technique is that the client always keeps a valid JPEG2000 file without using an auxiliary structure to keep track of the portion of the received codestream. .
[0151]
[For auxiliary use: Client without memory and decoder]
A very simple client may want to browse very large images, even though it has less memory than the client's display area. Cached compressed image data cannot be expected. The client may not have a JPEG2000 decoder. However, the client can communicate with the JPEG2000 server, create a Tier3 request, and receive a Tier3 response.
[0152]
[Typical computer system]
FIG. 8 is a block diagram of a typical computer system that performs one or more of the operations described above. Referring to FIG. 8, a computer system 800 comprises a typical client or server. Computer system 800 includes a communication mechanism or bus 811 for communicating information, and a processor 812 coupled with bus 811 for processing information. The processor 812 includes, for example, a microprocessor such as, but not limited to, Pentium (registered trademark), PowerPC (registered trademark), and Alpha (registered trademark).
[0153]
System 800 further includes a random access memory (RAM) coupled to bus 811 for storing information and storing instructions for execution by processor 812, or dynamic storage 804 (referred to as main memory). Main memory 804 is also used to store temporary variables or other intermediate information during execution of instructions by processor 812.
[0154]
Computer system 800 is coupled to bus 811 and has read-only memory (ROM) and / or other static storage 806 for storing static information and instructions for processor 812, as well as magnetic or optical disks and the like. And a data storage device 807 having a disc drive. The data storage device 807 is connected to the bus 811 and stores information and instructions.
[0155]
Computer system 800 is connected to bus 811 and to a display device 821 such as a cathode ray tube (CRT) or liquid crystal display (LCD) that presents information to a computer user. An alphanumeric input device 822 with alphanumeric keys and other keys is also connected to the bus 811 to inform the processor 812 of information and command selections. An auxiliary user input device is a cursor control device 823, such as a mouse, trackball, trackpad, stylus, or cursor direction key, connected to the bus 811 to notify the processor 812 of direction information and command selection. , The movement of the cursor on the display device 821 is controlled.
[0156]
Other devices that may be connected to the bus 811 include a hardcopy device 824 used to print instructions, data, or other information onto media, such as paper, film, or similar types of media. Is included. Further, an audio recording and reproducing device such as a speaker and / or a microphone may be connected to the bus 811 to realize an audio interface with the computer system 800. Other devices that can be connected to the bus 811 include a telephone, a handheld palm-sized device, or a wired / wireless communication facility 825 that communicates with a computer or server.
[0157]
Another device that can be connected to the bus is, for example, a digital signal processor (DSP) or co-processor 835 that implements special compression (and / or decompression) hardware.
[0158]
Some or all of the hardware associated with system 800 may be used in the present invention. However, it is clear that other computer system configurations can accommodate some or all of the devices.
[0159]
In the above description, various specific details are set forth in order to provide an overall understanding of the invention. As will be apparent to those skilled in the art, the present invention may be practiced without these specific details. In another example, structures and devices are shown in block diagram form in order to avoid obscuring the present invention.
[0160]
Portions of the following detailed description are provided in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithm descriptions and representations are the means used by those skilled in the data processing arts to communicate a summary of their work to others skilled in the art as efficiently as possible. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. Steps require physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals to which storage, transfer, synthesis, comparison, and other operations can be applied. These signals are referred to as bits, values, elements, symbols, characters, terms, numbers, and the like, primarily because they are commonly used.
[0161]
However, all these terms, as well as similar terms, should be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise noted, as will be apparent from the description below, discussions using terms such as "processing,""computing,""calculation,""determining," and "displaying" Reference is made to the operation and processing of a computer system or similar electronic computing device, which operates on data expressed as physical (electronic) quantities in registers and memories of the computer system, It is converted to other data, which is also represented as a physical quantity in a memory or register of the system or other such information storage device, transmission device or display device.
[0162]
The present invention also relates to an apparatus for performing the above operations. The apparatus comprises a general-purpose computer specially constructed for the required purposes, or selectively activated or reconfigured by a computer program stored on the computer. Such a computer program is stored in a computer-readable recording medium. Examples of the computer-readable recording medium include any type of disk such as a flexible disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), It includes, but is not limited to, EPROM, EEPROM, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Each medium is connected to a computer system bus.
[0163]
The algorithms and displays in the following description are not inherently associated with a particular computer or other device. A variety of general purpose systems may be used with programs in accordance with the above teachings, or it may prove advantageous to construct more specialized apparatus to perform the required method steps. . The required structure for a variety of these systems will appear from the description above. In addition, the present invention is not described with reference to any particular programming language. Various programming languages are used to implement the teachings of the present invention described above.
[0164]
A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (eg, a computer). For example, machine readable media include read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, electrical, optical, and acoustic Target or other types of propagated signals (eg, carrier waves, infrared signals, digital signals, etc.).
[0165]
As can be seen from the foregoing description, many alternatives and modifications of the present invention will be apparent to those skilled in the art, and the specific embodiments illustrated and described are not intended to limit the invention. It should be understood that there is no. Accordingly, the description of the details of the various embodiments does not limit the scope of the claimed invention, which describes only what is considered essential to the invention.
[0166]
【The invention's effect】
According to the present invention, efficient image communication is realized.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram of simple image access.
FIG. 2 is an explanatory diagram of a typical software structure.
FIG. 3 is an explanatory diagram of an example of division between a client and a server.
FIG. 4 is an explanatory diagram of an example of division between a client and a server.
FIG. 5 is an explanatory diagram of an example of division between a client and a server.
FIG. 6 is an explanatory diagram of an example of division between a client and a server.
FIG. 7 is an explanatory diagram of an example of division between a client and a server.
FIG. 8 is a configuration diagram of an embodiment of a computer system.
FIG. 9 is an explanatory diagram of a correspondence relationship between a viewport question parameter and an SIZ marker segment parameter.
[Explanation of symbols]
200 applications
201 First stage
202 Stage 2
203 Stage 3
204 Stage 4
205 file system, on-the-fly image generator or byte-range server
804 main memory
806 static memory
807 Large capacity memory
811 Bus
812 processor
821 display device
822 keyboard
823 Cursor control device
824 Hard Copy Device
825 wireless / telephone interface
835 coprocessor

Claims (111)

Sending the request over the network;
Receiving from the network a JPEG2000 compliant codestream tile part as a return type, such as part of a response to a request;
A method that includes The network may include a network selected from the group consisting of a local area network (LAN), a wide area network (WAN), the Internet, and the World Wide Web (WWW). The method of claim 1. The method of claim 1, wherein the response comprises an HTTP response. 4. The method of claim 3, further comprising using HTTP chunked transfer encoding. 5. The method of claim 4, further comprising terminating the response without closing the HTTP channel. The method of claim 5, further comprising the step of initiating a new response to a new request if the user changes the viewport within an image corresponding to the codestream. The method of claim 1, further comprising uploading at least one tile part to a server using HTTP. Sending the request over the network;
Receiving from the network a JPEG2000 compliant codestream tile part as a return type, such as part of a response to a request;
A program for causing a computer to execute. The network may include a network selected from the group consisting of a local area network (LAN), a wide area network (WAN), the Internet, and the World Wide Web (WWW). 8. The program according to 8. 9. The program according to claim 8, wherein the response includes an HTTP response. Means for sending the request over the network;
Means for receiving a JPEG2000 compliant codestream tile part as a return type, such as a part of a response to a request, from a network;
An apparatus having The network may include a network selected from the group consisting of a local area network (LAN), a wide area network (WAN), the Internet, and the World Wide Web (WWW). An apparatus according to claim 11, The apparatus of claim 11, wherein the response comprises an HTTP response. Client and
A server connected to the client and exchanging a portion of the compressed code stream over the network using a protocol;
Has,
Requests and responses from the server processed by the client include image objects,
A system in which requests and responses from clients processed at the server include byte ranges. 15. The system of claim 14, wherein the byte range is specified using a program call. The system of claim 15, wherein the program comprises a C language program. 17. The system of claim 16, wherein the program call comprises a sequence of fseek () and read () calls. The system of claim 14, wherein the response comprises an HTTP response. 15. The system of claim 14, wherein the server and the client use HTTP chunked transfer encoding to exchange requests and responses. 15. The system of claim 14, wherein at least one response is terminated without closing the HTTP channel. A method of transporting a code stream of compressed data between a client and a server using a series of stages,
A first stage for converting a sequence of compressed image object responses and viewports into image data;
A second stage for converting the viewport request into a compressed data object request, a third stage for creating a compressed image object in response to the byte range response,
A fourth stage of converting the compressed image object request into a byte range request;
Having a method. 22. The method of claim 21, wherein two or more stages are performed at a single location. 23. The method of claim 22, wherein the two or more stages are performed by a proxy server communicatively connected between the server and the client. The method of claim 23, wherein two or more stages comprise a second stage. The method of claim 23, wherein two or more stages comprise a third stage. 22. The method of claim 21, wherein the first, second, third, and fourth stages are performed on a server. The method of claim 21, wherein the first stage is performed at a client. The method of claim 21, wherein the second, third, and fourth stages are performed on a server. The method of claim 21, wherein the first and second stages are performed at a client. The method of claim 21, wherein the third and fourth stages are performed on a server. 22. The method of claim 21, wherein the first, second, third, and fourth stages are performed on a client. 22. The method of claim 21, further comprising a decompression stage operating the decoder on received data. 33. The method of claim 32, wherein the decoder decodes the region of interest. The method of claim 33, wherein the region of interest is a region of interest specified by the client. The method of claim 32, wherein the decoder comprises a JPEG2000 decompressor. 33. The decoder is capable of generating a full-resolution image, generating a cropped image by cropping a region of interest in the full-resolution image, and scaling the cropped image to another resolution. The described method. 33. The method of claim 32, wherein the decoder decodes only those portions of the codestream required for desired resolution, region of interest, components and quality. 22. The method of claim 21, wherein during the second stage, maintaining a list of responses that are moved to the first stage. 22. During the second stage, the desired region of interest of the image is converted into reference grid units, tiles that intersect with the region of interest are determined, and tile parts are selected using the specified resolution and quality. the method of. 22. The method of claim 21, storing, during the second stage, one bit indicating whether the tile part should be transmitted to the client and one bit indicating whether the tile part has been transmitted. 22. The method according to claim 21, wherein during the second stage, auxiliary information indicating a priority for each tile part is stored. 22. The method of claim 21, wherein during a third stage, a sequence of image object requests is temporarily stored. During the third stage,
Get the desired data,
Wrap the returned data with an HTTP response,
Sending an HTTP response containing the returned data to the second stage,
The method of claim 21. 22. The method according to claim 21, wherein during the third stage, the returned data is wrapped with an identifier. The method of claim 44, wherein the identifier comprises a new header. The method of claim 44, wherein the identifier is comprised of a sequence of types in a message body that precedes encoded data in the response. 22. The method of claim 21, wherein during the fourth stage, the requested image object is returned only if multiple reads were used to determine the location of the request. During the fourth stage,
Read the SOC marker and SIZ marker of the main header,
Read the SOT marker to get the length of each tile part,
Generate a byte range request by using a list of the start and length of each tile part to identify the range,
The method of claim 21. 22. The method of claim 21, wherein the response is concatenated with the request to form a JPEG2000 codestream that is decoded by a JPEG2000 decoder. 50. The method of claim 49, wherein the JPEG2000 decoder is a protocol incomprehensible decoder. A first procedure for converting a sequence of compressed image object responses and viewports into image data;
A second procedure for converting the viewport request into a compressed data object request;
A third procedure for creating a compressed image object according to the byte range response;
A fourth procedure for converting the compressed image object request into a byte range request;
For causing a computer to execute and transport a code stream of compressed data between a client and a server using a series of stages. 52. The program of claim 51, wherein two or more procedures are performed at a single location. 53. The program of claim 52, wherein the two or more procedures are performed by a proxy server communicatively connected between the server and the client. 54. The program according to claim 53, wherein two or more procedures constitute a second procedure. 54. The program according to claim 53, wherein two or more procedures form a third procedure. The program according to claim 51, wherein the first procedure, the second procedure, the third procedure, and the fourth procedure are executed by a server. 52. The program according to claim 51, wherein the first procedure is executed on a client. The program according to claim 51, wherein the second procedure, the third procedure, and the fourth procedure are executed by a server. The program according to claim 51, wherein the first procedure and the second procedure are executed by a client. The program according to claim 51, wherein the third procedure and the fourth procedure are executed by a server. The program according to claim 51, wherein the first procedure, the second procedure, the third procedure, and the fourth procedure are executed by a client. 52. The program of claim 51, further causing the computer to perform a decompression procedure that operates a decoder on the received data. An apparatus for transporting a code stream of compressed data between a client and a server using a series of stages,
A first stage for converting a sequence of compressed image object responses and viewports into image data;
A second stage for converting the viewport request into a compressed data object request;
A third stage for creating a compressed image object according to the byte range response;
A fourth stage of converting the compressed image object request into a byte range request;
An apparatus having 64. The apparatus of claim 63, wherein two or more stages are performed at a single location. 64. The apparatus of claim 63, wherein the two or more stages are performed by a proxy server communicatively connected between the server and the client. The apparatus of claim 65, wherein two or more stages comprise a second stage. 67. The apparatus of claim 65, wherein two or more stages comprise a third stage. 64. The apparatus of claim 63, wherein the first, second, third, and fourth stages are performed on a server. 64. The apparatus of claim 63, wherein the first stage is performed on a client. 64. The apparatus of claim 63, wherein the second, third, and fourth stages are performed on a server. 64. The apparatus of claim 63, wherein the first stage and the second stage are performed on a client. The apparatus of claim 63, wherein the third and fourth stages are performed on a server. 64. The apparatus of claim 63, wherein the first, second, third, and fourth stages are performed on a client. 64. The apparatus of claim 63, further comprising a decompression stage operating the decoder on the received data. The steps by which the server receives the request;
A procedure in which the server generates a tile part that can be connected to a code stream compliant with JPEG2000,
Including, methods. 78. The method of claim 75, wherein the step of generating a tile part that can be linked to a JPEG2000 compliant code stream by the server includes using a POC marker to enable the tile part to be mapped to a main header of the code stream. Method. Instructions for receiving the request at the server;
Generating a tile part that can be connected to a JPEG2000-compliant code stream on a server;
To make a computer realize 78. The method of claim 77, wherein generating a tile part that can be linked to a JPEG2000 compliant code stream at the server comprises using a POC marker to enable the tile part to be mapped to a main header of the code stream. program. Means for receiving the request;
Means for generating a tile part that can be connected to a JPEG2000-compliant code stream by a server;
An apparatus, including: 80. The apparatus of claim 79, wherein the means for generating tile parts that can be linked to a JPEG2000 compliant codestream includes means for using a POC marker to enable the tile parts to be mapped to a main header of the codestream. Storing the tile parts in a server in a first order;
The server receiving a request from the client for a tile part specifying a second order that the client expects as the order of the tile part;
The server reordering the tiles in the tile in a second order;
Sending the sorted tile parts over the network;
Having a method. The method of claim 81, further comprising the step of the server writing the POC marker using the portion of the returned tile part. 83. The method of claim 82, wherein the POC marker specifies a resolution, layer, and component stored for each tile part. A method for transporting a part of a JPEG2000 image that is a part of a JPEG2000 code stream via a network,
Requesting a part of the JPEG2000 code stream;
Receiving a part of the JPEG2000 code stream as a tile part;
Having a method. The method of claim 84, wherein a portion of the JPEG2000 code stream is received using an HTTP response. The method of claim 84, wherein requesting a portion of the JPEG2000 codestream comprises requesting a tile part using a range header. The method of claim 84, wherein the range header comprises an HTTP range header. 85. The method of claim 84, further comprising the step of indicating data available at the client to enable the server to determine that tile parts are only data that must be sent to the client to satisfy the request. 89. The method of claim 88, wherein the available data includes a region previously received by the client. 91. The method of claim 88, wherein the available data includes tile parts previously received by the client. 85. The method of claim 84, further comprising storing the codestream in a server-side file in progressive order such that the lower resolution tile parts are stored before the higher resolution tile parts. The method of claim 91, wherein the progression order is a resolution-layer-component-position (RLCP) order. 93. The method of claim 92, wherein the progression order is such that the tile parts are split at every resolution and every layer. The method of claim 91, wherein the progression order is a layer-resolution-component-position (LRCP) order. The method of claim 94, wherein the progression order is such that at least one tile is divided into tile parts only at layer boundaries. The method of claim 94, wherein the progression order includes encoded data for lossless representation. 97. The method of claim 96, wherein the encoded data for lossless representation is stored in a last tile part in a progressive order. The method of claim 84, further comprising concatenating the response into a plurality of requests to form a codestream. 85. The method of claim 84, further comprising specifying one or more boxes for a parameter of the third tier request to indicate one or more boxes of interest to the client. 100. The method of claim 99, further comprising specifying one or more sub-boxes. 85. The method of claim 84, further comprising requesting image-level data and at least a portion of the metadata in the byte range. A transport method that uses a series of stages to handle client to server requests and server to client responses,
The steps for using a series of stages are:
Converting viewport requests into tile parts by mapping the viewport to a set of tiles;
Converting the image object request into a byte range request;
Generating a byte range response;
Creating an image object from the byte range response,
including,
Transport method. 103. The transport method according to claim 102, further comprising the step of operating a decompressor on the image object. Instructions for generating a full resolution image,
Steps to crop the full resolution image to get the region of interest,
A procedure for scaling the region of interest to a predetermined region of interest,
103. The transport method according to claim 102, further comprising: Converting viewport requests into tile parts by mapping the viewport to a set of tiles;
Converting the image object request into a byte range request;
Generating a byte range response;
Creating an image object from the byte range response,
A program for causing a computer to execute. The program according to claim 105, further causing the computer to execute a procedure for operating the decompressor on the image object. Instructions for generating a full resolution image,
Steps to crop the full resolution image to get the region of interest,
A procedure for scaling the region of interest to a predetermined region of interest,
The program according to claim 105, further causing the computer to implement: Means for converting viewport requests into tile parts by mapping the viewport to a set of tiles;
Means for converting the image object request into a byte range request;
Means for generating a byte range response;
Means for creating an image object from the byte range response;
including,
apparatus. 109. The apparatus of claim 108, further comprising means for operating a decompressor on the image object. Means for generating a full resolution image;
Means for cropping the full resolution image to obtain a region of interest;
Means for scaling the region of interest to a predetermined region of interest;
111. The apparatus of claim 108, further comprising: A recording medium storing the program according to any one of claims 8 to 10, 51 to 62, 77, 78, and 105 to 107.

Images