JP2004274758A - Ｊｐｐ−ストリームからｊｐｅｇ２０００符号ストリームへの変換方法及び変換装置 - Google Patents

Abstract

【課題】 本発明の課題はＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法及び装置を提供することである。
【解決手段】 この方法は、出力ＪＰＥＧ２０００符号ストリームへ主ヘッダデータ−ビンをレイヤプログレッションが最後のプログレッション順序の使用を規定するマーカセグメントともに書き込む。各タイルについて、正規のタイルヘッダを書き込み、前記各タイルの各コンポーネント、位置及び、解像度について、完全に受信されたレイヤの数を決定し、出力ＪＰＥＧ２０００符号ストリームへ、完了されたレイヤに対応するプレシンクトデータビンのバイトを書き込み、完了していない各レイヤの各パケットに対して、空のパケットヘッダを書き込む。また各タイルに対して、パケットデータのバイト数へ長さを調整するためにＳＯＴマーカセグメントを更新する。出力ＪＰＥＧ２０００符号ストリームの最後にＥＯＣマーカを書き込むことを含む。
【選択図】 図５

Description

本発明は、圧縮されたディジタル画像の分野に関連し、特に、本発明は、圧縮されたディジタル画像の処理と共に通信の使用に関連する。

ディジタル画像の更なる使用がなされそしてディジタル画像はサイズが大きくなるにつれて、画像の部分を通信する能力が、効率的な且つ高速な通信に必須である。確かにジョイントフォトグラフィックエキスパートグループ（ＪＰＥＧ）は、ＪＰＥＧ２０００画像圧縮規格の設計に種々のアクセス特徴の重要性を認識する。ＪＰＥＧ２０００は、ＪＰＥＧ２０００ファイル内のヘッダ情報を読むことにより、画像の関連する部分の符号ストリーム内の位置の決定を可能とし、これは、ローカルファイルへの効率的なアクセスを可能とする。しかしながら、多くの画像通信がある種のネットワークを介して発生し、そして、多くの異なるクライアントが、同じ画像の部分へアクセスし得る。従って、ネットワークを介して圧縮された画像の部分を通信する標準的なプロトコルを有することが重要である。ＪＰＥＧ国際規格委員会は、現在、ＪＰＩＰとも呼ばれる、最終的にネットワークを介した画像の通信の標準となるであろう、”ＪＰＥＧ２０００画像符号化システム−パート９：インターラクティビティツール、ＡＰＩ及びプロトコル”を開発している。

ＪＰＥＧ２０００の背景
ＪＰＥＧ２０００システムのある部分を示す、図３には、ＪＰＥＧ２０００からのある重要なアイデアが示されている。オリジナルの画像は、正方形のタイルに分割される。これらのタイルは、独立に圧縮される。このように、上方左側からの符号化されたデータは、上方左側部分の画像を再構成するのに十分である。同様に、どの領域も、その領域と交差する全てのタイルからのデータを得てそしてそれらを復号することにより再構成されることが可能である。

ＪＰＥＧ２０００符号化器は、各タイルに２次元のウェーブレット変換を実行する。これは、サブバンドにグループ化されたウェーブレット係数の組みを導く。サブバンドの１つは、画像の低解像度版であり、−−全体の画像に特定の低域通過フィルタとサブサンプリングを行うことにより得られうるのと正確に同じ画像である。重要なのは、そのサブバンドは、画像の中間解像度版を構成するために他のサブバンドと結合されることが可能である。このように、ＪＰＥＧ２０００符号ストリームは低解像度及び、画像の最大解像度までの、水平と垂直に２倍だけ解像度の大きい画像へのアクセスを提供する。

ウェーブレット変換係数は、”プレシンクト（ｐｒｅｃｉｎｃｔｓ、区）”に再グループ化される。これらのプレシンクト（区）は、画像の空間領域にアクセスする代わりの機構を構成する。画像の上方左側部分を復号するために、各サブバンドの上方左側部分のプレシンクトについての符号化されたデータが得られそして、復号される。ウェーブレット変換係数は、画像内の複数の画素に影響を及ぼすので、そして、異なるサブバンド内の係数は異なる数の画素に影響を及ぼすので、そして、各画素は複数の係数により影響されるので、画像の特定の領域を復号するのに必要な全てのプレシンクトを、注意深く決定する必要がある。

タイルとプレシンクトは、画像を圧縮するときに両方ともに使用されることが可能である。両方が使用される場合には、タイルは画像の領域への粗い粒子のアクセスを提供し、一方、プレシンクトは更に局所的な領域へのアクセスを提供する。

最後に、プレシンクトは符号ブロックに分割されそして、ウェーブレット係数のこれらの符号ブロックは、最大桁ビットで開始しそして、小さい桁のビットへ進む、複数のパスで圧縮される。これらの”符号化−パス”は、無損失の方法で統計的な冗長性を除去する。例えば、多くの数のゼロビットは、非常に短い符号により置換される。ウェーブレット係数の固定のサイズのブロックは、このように、符号化されたデータの可変長のセグメントになる。セグメントの第１の部分は、ウェーブレット係数の最大桁ビットに対応するので、最も重要な部分である。符号化されたデータセグメントの後者の部分が復号器に利用できない場合には、画像は得られるが、低品質である。

”符号ストリーム”は、ＪＰＥＧ２０００パート１で定義される。それは、データが続く、符号ストリーム内のデータの次の部分を識別する２バイトコードが必須である、一連の”マーカセグメント”により構成される。”ＳＯＣ”及び”ＳＩＺ”マーカセグメントで開始する”主ヘッダ”がある。ＳＩＺマーカセグメントは、画像コンポーネントの幅と高さについての情報を含む。”ＣＯＤ”と”ＣＯＣ”マーカセグメントは、圧縮されたデータはどの様に復号されるべきかを示すパラメータを含む。主ヘッダーの後に、一連の”タイルパート”がある。各タイルパートは、特定のタイルと部分を識別する”ＳＯＴ”マーカセグメントで始まる。各タイルパートについて符号化されたデータには、”ＳＯＤ”マーカセグメントが先行する。符号ストリームは、画像についての全てのエントロピー符号化されたデータと、その符号化されたデータを復号するために使用されるべき方法を記述するデータを含む。符号ストリームは、使用されるウェーブレット変換に関する情報、タイルのサイズ、プレシンクトのサイズ、解像度に関する情報、ファイル内のパケットの順序等を含む。符号ストリームは、エントロピー符号化されたデータを画像サンプルに復号するのに必要な全てのパラメータを含まなければならない。符号ストリームは、例えば、パケットの長さのような、符号化されたデータの部分への高速アクセスを提供する情報も含みうる。

”ファイル−フォーマット”は、１つ又はそれ以上の符号ストリームについての包みである。ＪＰＥＧ２０００パート１は、シンプル”ＪＰ２”ファイルフォーマットを定義する。ＪＰＥＧ２０００パート２は、更に複雑な情報を格納する”ＪＰＸ”フォーマットの定義を含む。ＪＰＥＧ２０００パート３は、モーションＪＰＥＧ２０００についての”ＭＪ２”ファイルフォーマットを定義する。ＪＰＥＧ２０００パート６は、複合文書についての”ＪＰＭ"ファイルフォーマットを定義する。ＪＰＥＧ２０００符号ストリームを含みうる、ＪＰＥＧ２０００委員会により定義されていないファイル−フォーマットもある。例えば、ＤＩＣＯＭファイルフォーマットは、医療分野で広く使用される。ＴＩＦＦ及びＰＤＦは、既に複数の圧縮形式を許しそして、ＪＰＥＧ２０００符号ストリームを許すように簡単に拡張されうるファイルフォーマットである。ファイル−フォーマットは典型的には、例えば、オーディオ、ＸＭＬ情報符号及び、画像捕捉状態のような、ストリームに含まれる画像データに関連する、”メタ−データ”を提供する。ファイルフォーマットは、一般的には、複合される画像データの色空間に関する情報も含む。

ＪＰＩＰ背景
要求
ＪＰＩＰは、要求を作成する際にクライアントにより使用されうる幾つかのパラメータを定義する。これらの要求は、クライアントが興味をもっているのはどのサブ画像かを示す。要求は、サーバーはデータを繰返さないように、クライアントにより既に受信された圧縮されたデータについての情報も含みうる。要求は、クライアントが興味を持っているのはどのメタ−データかについての情報及び、サーバにより与えられる応答の形式を制御する情報も供給し得る。幾つかのこれらのパラメータは、フレームサイズ、領域オフセット、及び、領域サイズを含む。

幾つかの例では”ｆｓｉｚ＝１２８，１２８”で現れる、フレーム−サイズパラメータは、クライアントが領域をアクセスするのに使用したい全体の画像のサイズを示す。領域サイズパラメータがない場合には（以下を参照）、フレーム−サイズは単純に、クライアントの望む画像のサイズである。例えば、５１２かける５１２サンプルで４レベルのウェーブレット変換で符号化された画像は、５１２かける５１２、２５６かける２５６、１２８かける１２８、６４かける６４又は、３２かける３２のフレームサイズでアクセスされることが可能である。サーバへの第１の要求では、クライアントは有効な実際のフレーム−サイズを知らない。この場合には、クライアントは望ましいサイズと丸め方法を示すことができそして、サーバは最も近い利用できるサイズを戻す（そして、他のパラメータは使用される実際のフレームサイズに合うようにスケーリングされる）。

”ｒｏｆｆ＝６４，６４”として使用されうる、領域オフセットパラメータは、クライアントは全体の画像には興味がないが、しかし、要求で与えられる２つの値により規定されたオフセットで始まる領域にのみ興味があることを示す。このオフセットは、要求フレーム−サイズに関連する。

”ｒｓｉｚ＝６４，６４”として使用されうる、領域パラメータは、クライアントにより望まれる領域のサイズを示す。３つのパラメータｆｓｉｚ、ｒｓｉｚ及び、ｒｏｆｆを提供する代わりに、クライアントは、”ｒｏｉ”パラメータで、興味のあるファイル−又は、サーバ−定義の領域に興味があることを示しうる。ｒｏｉパラメータは、ファイルフォーマットボックスの１つで識別される名称の付された領域を要求するのに使用されることが可能である。この値は、サーバがクライアントの知識に基づいて適切な領域を選択すべきであることを示すために、”ｒｏｉ＝ｄｙｎａｍｉｃ”でのように”動的”に設定される。

セッション管理
ＪＰＩＰは、サーバ内のメモリ無しに動作できる。この場合に効率的にするために、クライアントは、各質問で関連する受信されたデータのリストを提供することが必要である。これは、”ｍｏｄｅｌ”、”ｔｐｍｏｄｅｌ”又は、”ｎｅｅｄｓ”パラメータでなされる。セッションを開始するために、クライアントは、”ｃｉｄ＝０”のチャネル−ｉｄに対する要求を発行しうる。サーバ応答はチャネルについて使用される値を示す。同じチャネルを使用するすべての将来の要求は、同じキャッシュを有するとみなされる。同じ画像の複数のサブ画像は、異なるチャネルで使用されることにより平行して要求され且つ受信される。

応答
ＪＰＩＰ応答は、完全な画像ファイル、タイルパートストリーム又は、プレシンクトストリームの、３つの主な形式をとる。完全な画像ファイル戻り形式は、本質的に、要求に基づいて発生されたカスタムファイルを戻すのに似ている。２つのストリーム戻り形式は、一連の小”メッセージ”よりなる複合応答である。各メッセージは、その形式、その形式内のインデックス、その形式とインデックスを有する”データ−ビン”へのメッセージのオフセット、及び、メッセージ長を識別する、ヘッダを有する。データ−ビンは、サーバ上の資源についてクライアントが要求した全ての情報を表すとして考えることができる。単一の要求に応答して、サーバは、幾つかの異なるデータ−ビンの部分を送りうる。メッセージは、典型的には、完全なデータービンを含まず、代わりに、クライアントへまだ送られていないデータ−ビンの一部を含む。小メッセージサイズは、画像の異なる部分のデータをインターリーブすることを可能とし、そして、従って、クライアントにより規定された領域は、品質的に均一に成長しうる。同様に、画像データは、メタ−データとインターリーブされても良い。各メッセージの長さを供給することは、いずれのメッセージの最後でも、ストリームを優雅に終了することを可能とする。これは、サーバが１つの要求へ応答することを停止しそして、同じ通信チャネルの新たな要求に応答することを開始することを可能とする。

タイルパート戻り形式
ＪＰＩＰは、ＪＰＩＰタイルパートストリームの省略形としてＪＰＴ−ストリームと呼ばれる、タイルパートの組みとしてのサブ画像を戻す方法を規定する。タイルパートはＪＰＥＧ２０００パート１規格に規定されている。各タイルパートは、タイルについての圧縮されたデータの部分を含む。標準のＪＰＥＧ２０００復号器は、いずれの順序で供給されたタイルを扱えなければならないので、タイルパートを受信するＪＰＩＰクライアントは、正規のＪＰＥＧ２０００符号ストリームを得るためにそれらを連結でき、これは、標準復号器が画像を生成するのに使用できる。タイルパートは、ＪＰＥＧ２０００符号ストリームの自己ラベルの付された部分であるので、サーバは単純に前に存在するファイルの部分を選択できそして、要求に応じてそれらを送ることができる。更に複雑なサーバは、要求に基づいて、タイルパートの異なる分割へ、ファイルを再書き込みでき、これは、サーバの計算を費やして、更に効率的な応答を提供できる。

プレシンクト戻り形式
ＪＰＩＰは、ＪＰＩＰプレシンクトストリームの省略形としてＪＰＰ−ストリームとも呼ばれる、プレシンクトのバイト範囲の組みとしてサブ画像を戻す方法を規定する。プレシンクトは、ＪＰＥＧ２０００パート１規格で規定されている。クライアントは、同じプレシンクトに対応する全てのバイト範囲を集めそしてこれらをプレシンクト識別子を理解する特別なＪＰＩＰプレシンクト復号器へ送らねばならない。この特別目的の復号器は、復号するどのプレシンクトがサブ画像を発生するか決定する。プレシンクトは、各解像度でサイズが変わりそしてプレシンクトのバイト範囲は低オーバーヘッドを有するので、この方法は、連続する要求での画像の連続する改善に非常に精密な粒状制御を提供する。

図６は、プレシンクトデータ−ビンの構造を示す。全体のプレシンクトデータ−ビンがファイル内に存在する場合には、一連のパケットヘッダ（図６のＰＨ）とパケットデータ（図６のＰＤ）より構成される。パケットヘッダは、どの符号ブロックがパケットのパケットデータ部分内のデータを有するかに関する情報、各符号ブロックに格納されたバイト数に関する情報、及び、各符号ブロックについての符号化パスの数を含む。パケットヘッダには、どのコンポーネント、位置、解像度、タイル又は、それが属するレイヤを識別する情報はない。パケットヘッダの長さに関する明確な情報はない。パケットデータの長さは、パケット内の全ての符号ブロックにデータの長さを加算することにより決定できる。パケットヘッダの長さは、復号によってのみ決定される。図６のＰＤボックス内の短い線は、符号ブロック間の分割を示す。

最も低い解像度のパケットについては、符号ブロックは、全てＬＬサブバンドについてである。他の解像度については、１つはＨＬサブバンドについて、１つはＬＨサブバンドについて、そして、１つはＨＨサブバンドについての、各レイヤについて３パケットある。図６は更に高い解像度も示し、そして、従って、下のラベルは、各レイヤに関連する３つのパケットを示す。

データ−ビンは、完全なパケットで送られる必要はない。ＪＰＰ−ストリームは、メッセージのシーケンスより構成される。各メッセージは、含まれるデータ−ビン情報の形式を示す（主ヘッダ、メタ−データ、プレシンクト、又は、タイルヘッダ）。メッセージがデータ−ビンについてのデータの最終部分を含む場合には、指示もある。各メッセージは、データ−ビン内の開始位置とメッセージの長さも示す。最後に、各プレシンクトデータ−ビンは、データ−ビンがどのタイル、コンポーネント、位置及び、解像度データビンに対してであるかを示す識別子を含む。これらのメッセージは図６の上方部に示されている。メッセージは、どの順序でも受信されうるが、しかし同じプレシンクトについての各メッセージは、開始位置と長さを示す。図６に示されたように、受信されるデータ内にギャップが存在しうる。

全画像戻り形式
クライアントの観点からの最も簡単なＪＰＩＰ戻り形式は、その中にクライアントが興味のあるサブ画像のみの完全な画像である。これは、サーバに、画像の関連部分を復号させそして、クライアントにより理解できるフォーマットで再符号化させることにより得ることが可能であり、例えば、サーバは伝統的なＪＰＥＧ、ポータブルネットワークグラフィック画像（ＰＮＧ）又は、ＪＰＥＧ２０００画像を戻しうる。全画像を戻す利点は、修正無しに且つＪＰＥＧ２０００又はＪＰＩＰの知識無しに、現在のクライアントで動作できることである。しかしながら、この戻り形式は、サーバにより多くの計算がなされることを要求する。クライアントがＪＰＥＧ２０００を理解する（復号できる）場合には、サーバが、ＪＰＥＧ２０００画像を”解析し”且つ、クライアントが興味のある部分についてのデータのみを有する、正規のＪＰＥＧ２０００ファイルを戻すことがしばしば可能である。解析されたＪＰＥＧ２０００画像戻り形式は、画像の同じ部分が何度も戻されうるので、複数のサブ画像要求に対して効率的でない。

このように、ＪＰＥＧ２０００は、特定の空間領域、特定の色コンポーネント、特定の空間解像度及び、特定の品質レイヤに関連するデータを抽出するためにアクセスできる、符号ストリームを提供する。ＪＰＩＰは、特定の領域、コンポーネント、解像度、及び、品質についての要求を行う方法を提供する。ＪＰＩＰは、クライアントが、受信されたデータの部分を識別でき、それらの部分を復号し且つ画像を生成することのできるように、ＪＰＥＧ２０００符号ストリームのサブセットを戻す機構をも定義する。

ＪＰＩＰの予想された使用
ＪＰＩＰ規格のエディタはインターラクティブ画像通信についての種々の潜在的な使用を集めた。これらの”使用事例”は、２００２年7月１５日に発行されたＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１Ｎ２６５６に詳細に記載されている。ＪＰＩＰの応用の１つの重要な領域は、大きな画像のブラウジングである。多くの画像は数千画素幅であり、そして、ある小さな携帯表示装置（例えば、携帯電話、携帯情報端末等）は、１００画素かける１００画素のみを表示する。ＪＰＩＰは、これらの大きな画像の低解像度版又は部分を見る方法を提供する。システムは、スクリーンの正確な位置に対応する高解像度データで小スクリーンを自動的に更新するグローバルポジショニングシステム（ＧＰＳ）を想像した。このデータは、非常に大きなＪＰＥＧ２０００画像内から抽出されうる。

航空画像、医療画像及び、プリプレス画像を含む、ＪＰＩＰ能力についての応用の幾つかの領域がある。ネットワークの性質も、大きく変わる（例えば、エラーフリー対頻繁なエラー、広帯域幅対低帯域幅）。民生品市場では、ＪＰＩＰは、写真をブラウズするのに使用されうると予想され、そして、ＪＰＩＰサーバを伴なうディジタルカメラを想像できる。ＪＰＩＰは、”通常の”状態で低解像度／品質画像が観測されるがしかし、何かが起こったときに、高解像度／品質画像が必要とされる、アプリケーションを監視するのに有益である。ある場合（例えば、セキュリティカメラ）には、複数の画像が対象である。

ＪＰＩＰは、文書画像（テキストとグラフィックスの混合）で使用されることが予想される。ＪＰＩＰは、特別目的のサーバを、主ＪＰＩＰサーバの一部であるようにすることを可能とする方法を含む（即ち、特別の形式の画像（例えば、ＪＰＭ文書）についてのＪＰＩＰサーバへのプラグイン）。代わりに、ＪＰＩＰは、主サーバ（例えば、ＪＰＩＰプラグインを有するアパッチ（Ａｐａｃｈｅ）サーバ）又はＰＤＦファイル内の画像の搬送のためにＪＰＩＰを使用するＰＤＦサーバ内で使用されうる。ＪＰＩＰは、ＪＰ２、ＪＰＸ、ＪＰＭ及び、ＭＪ２スタイルのファイルフォーマット（類似の”ボックス”構造の全てのファイルフォーマット）を扱う特別の設備を有するが、ＪＰＩＰは、他のファイル構成（例えば、ＤＩＣＯＭ、ＳＶＧ、遠隔検知ファイルフォーマット、等）内に格納された符号ストリームを送るのにも使用される。

現行のブラウザに役立つように画像を符号変換することによる後方互換性能力
ＪＰＩＰは、ＪＰＥＧからＪＰＥＧ２０００への移動を提供する。現在のブラウザは、ＪＰＥＧ２０００画像又は、ＪＰＩＰをプラグイン無しでサポートしない。しかしながら、サーバは、それらの画像の部分が要求されたときに、ＪＰＥＧ２０００画像をＪＰＥＧ画像に変換することを指定できる。ＨＴＴＰを介して、ＪＰＥＧへ、”ｉｍａｇｅ．ｊｐ２”の２５６画素かける２５６画素のスケーリング版を要求する現在のシンタックスは、

である。

そのような要求は、以下の形式のＨＴＭＬファイル内の画像タグに出くわすときに、ブラウザにより自動的に発生される。

このように、現在のブラウザは、プラグイン無しにＪＰＥＧ２０００ファイルにアクセスできそして、それらを表示できる。

能力の制御された画像応答
サーバが特定のウインド要求に対して提供する応答は幾つかのファクタに依存しうることは予想される。例えば、サーバが、クライアントが制限された解像度又は制限された色能力を有すると決定する場合には、サーバは、能力に一致する応答内で送信されるデータを選択しうる。クライアントがサーバの決定する領域を（”ｒｏｉ＝ｄｙｎａｍｉｃ”要求パラメータを使用して）要求する場合には、サーバはクライアントの能力に基づいて戻す画像の空間部分を選択することもできる。クライアントがコンポーネント当り１ビットの画像をのみを処理できそして特定の供給者の特徴（ｖｆ）も有することを示す要求は、

のようである。

ＪＰＩＰ前に画像の部分を通信するシステムがあった。例えば、ＦｌａｓｈＰｉｘファイルへアクセスを提供される、１９９７年１０月６日のインターネット画像プロトコル（ＩＩＰ）、第１．０．５版である。ＦｌａｓｈＰｉｘは同じ画像の複数の解像度を冗長的格納するので、ＪＰＩＰは、ＩＰＰとＦｌａｓｈＰｉｘより更に効率的であることが期待される。

非特許文献１は、ＪＰＥＧ２０００画像を搬送するクライアント／サーバ環境を定義しそして、”パン及びズーム”セッションでのＪＰＥＧ２０００バイトの使用の例を提供し、そして、１９９７年１０月６日のインターネット画像プロトコル（ＩＩＰ）、第１．０．５版に基づくプロトコルを開示する。

非特許文献２に挙げられたサブ画像を反訴する幾つかの他の技術があり、ＪＰＩＰ規格のためにＪＰＥＧ委員会に提出された。

ＪＰＩＰの作業中の草案は、非特許文献３である。
２００１年７月３１日から８月３日、ＣＡ、サンディエゴ、ＳＰＩＥ ディジタル画像の応用に関する会議、Ｍ．Ｂｏｌｉｏｅｋ、Ｇ．Ｋ． Ｗｕ及び、Ｍ．Ｊ．Ｇｏｒｍｉｓｈ、"クライアント／サーバ環境で効率的な画像化のためのＪＰＥＧ２０００（ＪＰＥＧ２０００ ｆｏｒ Ｅｆｆｉｃｉｅｎｔ Ｉｍａｇｉｎｇ ｉｎ Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ Ｅｎｖｉｒｏｎｍｅｎｔ）" ２００３年７月３日、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９ＷＧ１ Ｎ２６０２、"ＴＲＵＥＷ：Ｔｒａｎｓｐｏｒｔ ｏｆ Ｒｅｖｅｒｓｉｂｌｅ ａｎｄ Ｕｎｒｅｖｅｒｓｉｂｌｅ Ｅｍｂｅｄｄｄｅｄ Ｗａｖｅｌｅｔｓ （Ａ ＪＰＩＰ Ｐｒｏｐｏｓａｌ）" ２００３年２月２８日、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９ＷＧ１ Ｎ２８３４、"ＪＰＥＧ２０００画像符号化システム−パート９：インタラクティビティツール、ＡＰＩ及び、プロトコル−ワーキングドラフト第３．０版"

ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法及び装置を提供することである。

ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法及び装置が開示される。一実施例では、この方法は、出力ＪＰＥＧ２０００符号ストリームへ、主ヘッダデータ−ビンを、レイヤプログレッションが最後のプログレッション順序の使用を規定するマーカセグメントともに書き込むことを含む。この方法はまた、各タイルについて、正規のタイルヘッダを書き込み、そして、前記各タイルの各コンポーネント、位置及び、解像度について、完全に受信されたレイヤの数を決定し、出力ＪＰＥＧ２０００符号ストリームへ、完了されたレイヤに対応するプレシンクトデータビンの１つ又はそれ以上のバイトを書き込み、そして、完了していない各レイヤの各パケットに対して、空のパケットヘッダを書き込む。また各タイルに対して、この方法は、パケットデータのバイト数へ長さを調整するためにＳＯＴマーカセグメントを更新することを含む。この方法は更に、出力ＪＰＥＧ２０００符号ストリームの最後に、ＥＯＣマーカを書き込むことを含む。

本発明は、以下の詳細な説明と本発明の種々の実施例の添付の図面から更に完全に理解されるが、しかし、これは、本発明を特定の実施例に限定するものではなく、説明と理解のためのみのものである。

以下の説明は、発生しようとしているＪＰＩＰ規格又は同様な画像通信プロトコルの実効又はアプリケーションに有益である技術を開示する。本発明の幾つかは、ＨＴＴＰに関して説明されるが、しかし、ＪＰＩＰが他のプロトコルで動作できるように修正するように、他のプロトコルに簡単に修正されうる。ＪＰＩＰ規格のシンタックスは、現在は流動的であるが、しかし、これらの技術は、ＪＰＩＰ規格のシンタックスの変化を反映するために、単純な修正で動作することに、注意する。ここに記載された多くの技術は、ＪＰＩＰ以外の他の画像プロトコルにも有益であることにも注意する。

以下の説明では、本発明に従った更に徹底的な説明を提供するために、多くの詳細が説明される。しかしながら、本発明は、これらの特定の詳細無しで実行されうることは当業者には、明らかである。他の場合には、既知の構造と装置が、本発明を曖昧にすることを避けるために、むしろ詳細では無くブロック図の形式で示されている。

次の詳細な説明の幾つかの部分は、コンピュータメモリ内のデータニットに関する操作のアルゴリズム又は記号的表現に関して示されている。これらのアルゴリズム的な記述と表現は、他の当業者に、仕事の実体を最も効率的に伝えるための、データ処理技術で当業者により使用される手段である。ここで、アルゴリズムは、一般的には、望ましい結果を導く、自己完結のステップのシーケンスであると考えられる。ステップは、物理的な量の物理的な操作を必要とする。通常は、しかしながら必要はないが、これらの量は、蓄積され、転送され、結合され、比較されそしてその他の操作がされる、電気的又は磁気的な信号の形式をとる。これらの信号を、ビット、値、要素、シンボル、キャラクタ、期間、数又は、同様なものと呼ぶことは、原理的に一般的な使用のために、しばしば便利であることが分かる。

しかしながら、これらの全ての又は同様な用語は、適切な物理的な量と関連され、そして、これらの量に与えられる単に便利なラベルであることは、憶えておくべきである。以下の説明で、明らかなように、特に述べない限り、記載を通して、”処理する”又は、”計算する”又は、”決定する”又は、“表示する”又は同様なことのような用語を使用する説明は、コンピュータシステムのレジスタとメモリ内の物理的な（電子的な）量として示されたデータを、コンピュータシステムのメモリ又はレジスタ又は、他のその羽陽な情報記憶装置、伝送又は表示装置内で物理的な量として同様に表される他の量へ、操作しそして変換するコンピュータシステム又は同様な電子計算装置の動作と処理を指すと理解される。

本発明は、ここの動作を実行する装置にも関連する。この装置は、要求された目的のために特に構成され、又は、それは、コンピュータ内に格納されたコンピュータプログラムにより選択的に活性化され又は再構成される汎用コンピュータを含みうる。そのようなコンピュータプログラムは、限定はされないが、フレキシブルディスク、光ディスク、ＣＤ−ＲＯＭ、及び、光磁気ディスクのような任意の形式のディスク、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光カード、又は、電子的命令を格納するのに適する他の形式の媒体のようなそして、各々はコンピュータシステムバスに接続された、コンピュータ読み出し可能な蓄積媒体に格納されうる。

ここで示されたアルゴリズムと表示は、特定のコンピュータ又はたの装置に固有に関連はしない。種々の汎用システムは、ここの技術に従ってプログラムと共に使用されえ、又は、要求された方法ステップを実行するために更に特化された装置を構成することが便利であるとわかる。種々のこれらのシステムについての要求された構造は、以下の説明から明らかとなろう。更に、本発明は、特定のプログラミング言語を参照して記述されてはいない。種々のプログラミング言語は、ここに記載の本発明の教示を実行するために使用されうることは、理解されよう。

機械読み出し可能な媒体は、機械（例えば、コンピュータ）により読み出し可能な形式で情報を格納し又は伝送する機構を含む。例えば、機械読み出し可能な媒体は、読み出し専用メモリ（”ＲＯＭ”）、ランダムアクセスメモリ（”ＲＡＭ”）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電気的、光学的、音響的又は、他の形式の伝搬信号（例えば、搬送波、赤外信号ディジタル信号とう）、等を含む。

クライアント、サーバ、及びネットワーク
図１は、圧縮された画像のクライアント及びサーバ通信に使用されうるネットワーク環境の一実施例を示す。図１を参照すると、サーバ１０２は、典型的には、全体の画像を有し、又は、少なくともそれの有する画像の部分へのアクセスを提供する。サーバ１０２は、ある種のネットワークを介してクライアント１０１のような少なくとも１つのクライアントに接続されている。クライアント１０１は、しばしば、人間のユーザにより制御される”プログラム”であるが、しかし、完全に自動化されたシステムでも良い。クライアント１０１は、ある画像のサブセットに対する要求１１０のような、要求を発行し、そして、要求１１０にある方法で対応する圧縮された画像データを含む、応答１１１のような応答を受信する。ネットワークの帯域幅又はサーバ１０２の資源又は、ファイル要求の構造のために、クライアント１０１は要求された画像の部分以外のおおよそのデータを受信し得る。クライアント１０１は、典型的には、画像の異なる部分に対する要求を発行しそして、前に受信されたデータを増加する更なる符号化されたデータを受信する。ＪＰＩＰへの基本は、クライアントが既に受信したデータを繰返すことを避ける能力である。このデータの再送信を避ける２つの方法がある。

ある場合には、クライアント１０１は、サーバ１０２へ送られた要求内で既に受信されたデータについての情報を含み、それにより、サーバ１０２は冗長なデータを送信して戻す必要がない。これは、サーバ１０２に、”状態無し”の方法で、即ち、前の相互動作の記憶が必要無しで、動作することを可能とする。他の場合には、クライアント１０１とサーバ１０２は、”セッション”を確立し、そして、サーバ１０２は、クライアント１０１へ前に送られたデータを憶えている。クライアント１０１は、前に要求したデータの全てを受信する前にさえも、興味のある画像の部分を変更し得る。あるサーバは、これらの変更する興味を扱うために、前の要求に対する応答を割り込みすることができる。

図２は、典型的なネットワークを示す。図２を参照すると、ネットワークは、複数のクライアント（例えば、クライアント２２１，２２２，２２３）と複数のサーバを含む。単一のサーバは、数１００万の異なるクライアントへ同じ画像の異なる部分を扱い得る。単一のクライアントは、画像と他のデータ（例えば、ＨＴＭＬページ）を、幾つかのサーバから受信する。プロキシサーバは、オリジナルサーバと通信すること無しに幾つかの要求への素早い応答を可能とするために、ネットワーク内に存在しうる。有効な帯域幅と帯域幅のコストは、異なるクライアントと同じサーバの間で又は、異なるサーバの間で広く変わる。

最も一般的に使用されるネットワークは、インターネット又はワールドワイドウェブであるが、しかし、ＪＰＩＰとこの発明は、ローカルエリアネットワーク又は、どのような一般的な相互接続システムに適用できる。同様に、ＪＰＩＰは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）の上で”最も一般的に転送されるが、しかし、ＴＣＰ／ＩＰ及びＵＤＰを含む他の転送プロトコルと共に使用されると予想される。

現行のＪＰＩＰのドラフト規格は、画像データと画像メタデータの両方の要求と応答を規定する。種々の方法で圧縮された画像データを転送することが可能であるが、ＪＰＥＧ２０００は画像とファイルの種々の部分へのアクセスを許すので、ＪＰＩＰは、主にＪＰＥＧ２０００圧縮されたデータに関連する。

部分画像のアップロード
ＪＰＩＰワーキングドラフトの現行版は、サブ画像をアプロードする詳細な記述を提供しない。もちろん、完全なファイルは、ＨＴＴＰ ＰＵＴコマンド、ＦＴＰ ｐｕｔコマンド、ＷｅｂＤＡＶ、及び、ＮＦＳ、ＳＡＭＢＡ、ＡｐｐｌｅＳｈａｒｅ等のようなファイル共有システムを含むファイル転送に現在使用される種々の方法を使用してサーバへアップロードされる。これらの方法のいずれもが、サブ画像を転送し、且つ、サーバ上で既に利用できる画像データとそれを統合する能力が無い。

そのような部分画像のアップロードについての１つの使用は、無線接続性のあるディジタルカメラで起こり得る。低解像度画像は、画像を素早く見ることを提供するために、アップロードされうる。しかしながら、完全な画像は、例えば、無線接続のような、より広帯域な接続が利用できるまで、アップロードされない。この場合には、無線ネットワークへ接続した後に、無線リンクで既にアップロードされたデータ部分を繰返すよりも、画像のより高い解像度部分のみをアップロードすることが望まれる。

部分画像のアップロードの第２の使用は、図４に示されたように、遠隔編集状況で発生する。この場合には、遠隔クライアントは、画像の部分をダウンロードし、編集される特定の領域を決定し、局所的に編集を適用し、そして、変更された部分を圧縮し、そして、変更された部分をサーバへアップロードできる。各ステップについて、サーバへの要求と応答がある。おおよそ、部分画像データについてのタイルパート、要求と応答についてのＪＰＩＰのようなシンタックス及び、トランスポートについてのＨＴＴＰを使用する図４に対応する、例示の編集セッションが続く。

第１に、クライアントは、低解像度で部分的な画像について、サーバへ初期要求を行う。このクライアントは、サーバへ、”ｃｉｄ＝０”パラメータ：

を含むことにより、セッションを開始することを要求する。

サーバは、全体の画像に対応するがしかし低解像度のみのタイルパートで応答する。

[チャンクされた転送フォーマットでの、符号化されたＪＰＩＰタイルパートストリームデータ]
サーバは、ライン内に特定のチャネル識別子”ＪＰＩＰ−ｃｉｄ：５３７８９９３”を提供することに注意する。このｉｄは、このクライアントに以前に何のデータが送られたかを思い出させることを可能とするために、将来の要求内に供給される。サーバは、”チャンクされた”転送符号化内でデータを戻すことも注意する。このフォーマットは、ＨＴＴＰ仕様内に定義されそして、サーバに前もって長さを示すこと無しに応答を送ることを許す。それはまた、クライアントが、サーバが１つの応答を終了しそして次の質問へ応答を開始したかどうかを決定することを許す。幾つかのチャンクされたデータを受信した後に、クライアントは低解像度画像を表示できる。

ディスプレイを使用して、ユーザは赤目の問題があることを決定し、そして、画像の部分をズームインする。クライアントは、画像の実際のサイズを知ること無しに第１の要求を発行したが、第１の応答後に、クライアントは、全画像のサイズとユーザの望むズームに対応する正確な領域を決定できる。クライアントは、低解像度画像上で選択された位置から、次のような：

全解像度のデータについての新たな要求（ある場合には、異なる解像度での画像をユーザが見たので複数の要求の場合がある）を発行できる。

クライアントが、第１の要求の中でチャネルｉｄ（”ｃｉｄ＝０”）を要求し、第２の要求にチャネルｉｄ（ｃｉｄ＝５３７８９９３）を含めたので、サーバは、クライアントに送られたタイルパートのリストを維持し、そして、第２の応答内で新たに要求されたタイルパートのみを送る。クライアントは、既に受信されたタイルパートをサーバに教えることにより、同じ動作を達成できる。いずれの場合にも、サーバは、更なるデータ：

[チャンクされた転送フォーマットでの、符号化されたＪＰＩＰタイルパートストリームデータ]
を提供する。

一実施例では、クライアントは、ユーザが編集しようとしている領域について、全データが受信されるまで、エンドユーザが画像を編集することを妨げる。これは、例えば、描画ツールの選択をディスエーブルすることによりなされうる。代わりに、ユーザは、部分的に受信された画像を編集できないことを警告する、ダイアログボックスが表示されうる。クライアントが全てのタイルパートを待たない場合には、編集は量子化された復号されたデータに起こりそして、アップロードは、サーバに、高品質タイルを、編集されたたがしかし低品質なタイルと置換することを起こさせる。この損失は、次のように防ぐことができる。各タイル部分は、インデックス（Ｉｓｏｔ）、タイル内のパート番号（ＴＰｓｏｔ）及び、タイルパートの数が未知の場合にはゼロであるがしかし最後のタイルパートについては非ゼロである、そのタイルについてのタイルパートの数（Ｎｓｏｔ）（ＪＰＥＧ２０００パート１を参照する）を含む。クライアントは、タイルについてＴＰｓｏｔがＮｓｏｔ−１に等しい時に、最後のタイルパートが受信されたことを知る。

一旦クライアントがリージョンオブインテレスト（興味の領域）についての全てのデータを受信し、そして、ユーザが編集を終了すると、クライアントはアップロードのために変更された領域を準備する必要がある。一実施例では、クライアントは受信されたタイルが圧縮されたのと同じ方法で、即ち、ウェーブレット変換のレベルの同じ数、同じウェーブレットフィルタ、同じ符号ブロックサイズ等で、編集されたタイルの全てを圧縮する。そして、クライアントは編集されたタイルについて全てのタイルパートをアップロードする。代わりに、クライアントは、編集されたタイルについての最初の数タイルパートのみをアップロードするように選択できるが、しかし、結果は、サーバが低品質画像を有することである。クライアントのアップロードは：

[１５０６７８バイトのＪＰＴ−ストリームデータ]
のようである。

サーバがこの要求を受信するときには、それはダウンロードについての要求よりはアップロードの要求であると決定する。一実施例では、そして、この例では、その情報は、質問ストリング内のアップロードパラメータにより提供される。代わりに、サーバは、”Ｃｏｎｔｅｎｔ−ｔｙｐｅ：”ラインから、これは要求ではなかったことが分かる。画像データについてのＰＯＳＴ要求の”Ｃｏｎｔｅｎｔ−ｔｙｐｅ：”は、ｊｐｔ−ストリーム／要求又は、”ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ”である。サーバは、クライアントがアップロードする許可を有するかどうかを決定するために、設定された何の方法も使用する（これは、ＪＰＩＰ規格の外であるが、しかし典型的なＨＴＴＰ法が使用できる）。例えば、サーバは、ユーザがＨＴＴＰ ＰＵＴ要求を実行するかどうかを決定するために使用される、同じ方法を使用しうる。一実施例では、クライアントが許可を有する場合には、サーバは、それに対してアップロードされたデータストリーム内のタイルパートがある現在のファイル内の全てのタイルパートを除去し、そして、アップロードされたタイルパートを残りのタイルパートと結合する。代わりに、サーバは、符号ストリームの最後に新たなタイルパートを加えることを選択しうるか又は、サーバは、サーバにより好まれる順序で全体の符号ストリームを書きかえうる。符号ストリームが情報的なマーカセグメント（例えば、ＴＬＭ又は、ＰＬＴマーカセグメント）を有する場合には、これらは、除去され、又は、（新たなタイルパート又はプレシンクトの長さに基づいて）補正されるように調整される。最後に、ファイルフォーマットラッパーは、新たな符号ストリームを含むように調整される。例えば、符号ストリームの長さを有する隣接する符号ストリームボックスは、調整される長さを有することを必要としうる。

ＪＰＰ−ストリームでの部分画像のアップロード
画像の部分をダウンロードし、それらを編集し、そして、アップロードする同じ手順は、ＪＰＰ−ストリーム形式で使用できる。この場合には、クライアントは、”完了されたプレシンクトデータ−ビンクラスコード”（ＪＰＩＰ規格内で述べられている）が受信されたときに、全体のプレシンクトについてのデータが受信されたことを検出する。クライアントにとっては、オーバラップ効果により、プレシンクトが完全に受信されたことを決定するのはさらに難しいが、しかし、計算は、所定のウインドウ要求とプレシンクトデータを戻すときにサーバがするのと同じである。

再び、クライアントが全ての関連するデータを有する時に、編集が進行する。圧縮がオリジナルファイルと同じ方法でなされるべきである。再び、一実施例では、サーバはそれに対して新たなデータがアップロードされるプレシンクトについての全データを消去する。最後に、サーバは新たなプレシンクトデータから正規の符号ストリームを再生成する。サーバは、ＪＰＥＧ２０００符号ストリームについてのデータ−ビンを置換しそして、以下に示されるファイルを生成する。

サーバはときどき、ディスク上に格納されたＪＰＥＧ２０００符号ストリームと異なるプレシンクトサイズでクライアントへ画像を供給することに注意する。この場合には、サーバはアップロードを受け付けることを拒絶する。代わりに、サーバは、受信されたプレシンクトサイズをディスク記憶装置に使用されるサイズへ戻して変換符号化し、これは、パケットヘッダを書き替えることを含むが、しかし、符号ブロックについての圧縮されたデータは変更されない。

完全な画像形式を使用する部分画像のアップロード
サーバは、全体の画像として符号化されたサブ画像のアップロードを受け付けることも可能である。例えば、クライアントは、画像の一部を編集しそして、（ＪＰＥＧ２０００でなく）ＪＰＥＧを使用して、編集された領域を圧縮しうる。正規のファイルに加えて、クライアントは、編集された領域の全体の画像内の位置を提供する。これは、次のようになされる：

[５０６９８バイトのＪＰＥＧ ＤＣＴデータ]
この場合には、サーバはアップロードされたサブ画像を逆圧縮し、サーバ上の全体の画像のある部分を逆圧縮し、空間領域（未圧縮）で画素を置換し、空間画像により影響される全てのタイルとプレシンクトを再圧縮し、そして、クライアントが正しく圧縮された画像を提供したかのように、同じ方法で再圧縮された部分をマージする。しかし、この技術は、サーバ上で更なる計算を要求し、クライアントが互換性のない方法で画像を圧縮する可能性を低下させる（例えば、誤った数のレベルのウェーブレット変換）。そのような互換性の無いことは、アップロードされたサブ画像をサーバ上で使用できなくする。

ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換
ＪＰＩＰについてのタイルパートを使用することの主な利点の１つは、プロトコルの知識からＪＰＥＧ２０００符号ストリームの知識を分離することである。クライアントが幾つかの異なる領域要求からタイルパートを受信するときには、それらは、前に受信されたタイルパートと正規のＪＰＥＧ２０００符号ストリームの結果と連結されうる。クライアントがプレシンクトのバイト範囲を受信するときには、各”プレシンクトデータ−ビン”は、そのプレシンクトについて受信されたデータのリンクされたリストである。ＪＰＥＧ２０００符号ストリームと”プレシンクトデータ−ビン”の両方を復号するＪＰＥＧ２０００復号器を構築することが可能であるが、しかし、これは、ＪＰＥＧ２０００コーデックの幾つかの部分へ変更を必要とする。そのような変更は、同じデータフォーマットを使用すると仮定することにより、復号器とプロトコルハンドラーを結び付けるようである。それゆえに、”プレシンクトデータ−ビン”又はＪＰＰ−ストリームの集合を正規のＪＰＥＧ２０００符号ストリームへ変換することが有益である。

サーバは、ＪＰＥＧ２０００符号ストリームから生成されたＪＰＰ−ストリームを提供するが、サーバは符号ストリームから幾つかの情報マーカを除外し又は、クライアントがパケットについて異なる順序を使用しうるので、クライアントは典型的には、ＪＰＰ−ストリームを符号ストリームに変換するときに、同じＪＰＥＧ２０００符号ストリームを再生成しない。しかしながら、完全なプレシンクトが、領域に影響する全てのプレシンクトについてクライアントにより受信された場合には、クライアントのＪＰＥＧ２０００符号ストリームから復号されたサブ画像は、サーバのＪＰＥＧ２０００符号ストリームからの同じ符号により復号された同じサブ画像と同一であるが、しかし、符号ストリーム内のデータの順序は、非常に異なっているようである。

ＪＰＰ−ストリームを復号する直接の試みについては、主及びタイルヘッダ内の情報は、ＪＰＰ−ストリームをＪＰＥＧ２０００符号ストリームへ変換するために使用される。復号されるデータと共に、主ヘッダの全てとタイルヘッダの全てを受信すれば十分である。ＪＰＰ−ストリームは、メッセージヘッダ内の異なるデータ−ビンクラスコードを使用することにより、データ−ビンの最後のバイトが受信されたことを示す。クライアントは、”完了された”クラスコードが受信され且つ受信されたバイト範囲にギャップがない場合には、データ−ビンの全てのデータが受信されたことを知る。多くの場合に、全ての主ヘッダ又はタイルパートヘッダを有すること無しに、意味のある画像を復号することが可能である。例えば、ヘッダ内のいずれかのコメントマーカーセグメント（ＣＯＭ）は、画像を復号する能力に影響しない。同様に、特定のコンポーネントについての符号化状態を有するマーカセグメント（ＣＯＣ）は、そのコンポーネントについてデータが復号されない場合には、必要ない。

ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換をする動作の単純な組みは、以下で与えられる。これらは、ハードウェア（例えば、回路、専用論理）、ソフトウェア（汎用コンピュータシステム又は専用マシンで実行するような）又は、両方の組合せを含みうる処理回路により行われうる。
１．主ヘッダデータ−ビンを出力に書き込むがしかし、ＣＯＤマーカセグメント内のプログレッション順序をＣＰＲＬへ変更する。出力は、生成されているＪＰＥＧ２０００符号ストリームを参照しうる。用語は、ここでは、符号ストリームについての、メモリ、ディスク又は、記憶装置を参照するためにも使用される。
２．各タイルについて：
３．ＳＯＴマーカセグメントを出力へ書き込み（次のタイルパートへのポインタのために０を使用）、
４．タイルヘッダデータ−ビンのコンテンツを出力に書き込み（ＣＯＤマーカセグメントで、プログレッション順序をＣＰＲＬに変更する）、
５、ＳＯＤマーカセグメントを出力に書き込み、
６．タイル内の各コンポーネント、位置及び、解像度について、プログレッションの順序（ＣＰＲＬ）で：
７．完全に受信されたレイヤの数を決定し、
８．それらの完了したレイヤに対応する現在のコンポーネント、位置及び、解像度について、プレシンクトについて、プレシンクトデータ−ビンのバイトを出力に書き込み、
９．完了していない各レイヤの各パケットについて空のパケットヘッダ（０バイト）を書き込み、
１０．ＳＯＴマーカセグメントを更新しそして動作９で実際に書き込まれた空のパケットについて書き込まれた０バイトを含むパケットデータのバイトの数へ長さを調整し、
１１．ＥＯＣマーカを符号ストリームの最後に書き込む。

動作１では、プログレッション順序が、最後の要素として品質レイヤをわたるプログレッションを有するものに変更される。プログレッション順序ＲＰＣＬ又はＰＣＲＬは、ＣＰＲＬの代わりに使用もされうる。レイヤプログレッションを最後に有することは、各プレシンクトデータ−ビンが動作６−９で丁度１回で扱われることを可能とする。動作６−９で書き込まれるデータ−ビンの順序であるＲＰＣＬ又はＰＣＲＬを使用するための変更のみが、規定のプログレッション順序と一致する。

動作３では、ＳＯＴマーカセグメントが各タイルに付加される。ＪＰＰ−ストリームの現在の定義は、効率の理由のためにタイルヘッダデータ−ビン内にこれらを含まないためである。一実施例では、新たなＳＯＴマーカセグメントを生成するために、変換ルーチンは正しいタイル番号を使用する。一実施例では、この技術のために、全てのパートがともに出力され、それにより、ＳＯＴ内のタイルパートインデックスは０であるべきであり、そして、タイルパートの数は１であるべきである。ＳＯＤマーカセグメントは、ＪＰＰ−ストリーム内で使用されておらず、そして、動作５で追加される。

動作７では、完全なレイヤが受信されなかった幾つかの理由がある。ＪＰＰ−ストリームは、典型的には、増加して送られ、従って、最も新しいレイヤは、完全に受信されていない場合もある。更に、データ−ビンへの幾つかの貢献が受信されなかったことが可能である（おそらくパケット損失を経験するチャネルを介しての伝送のため）。おそらく、要求されたサブ画像のみがそれらのいくつかの符号ブロックを必要とするので、サーバは意図的にプレシンクト内のいくつかの符号ブロックについて符号化されたデータのみを送ることさえも可能である。

受信されたデータ−ビンの各パートは、長さとオフセットを規定するので、データ−ビンのどの部分が有効であるかを決定するのは容易である。例えば、バイト０−２００、３５８−４７３及び、５００−６２０は、１つのプレシンクトデータ−ビンについて受信されうる。完全に有効なレイヤの数は、動作の組みにより決定されることが可能である。第１に、データ−ビン内の失われたデータ後のデータは、完全に有効なレイヤの一部ではないので、無視される。データ内のそのようなギャップは図６に示され、例えば、ＪＰＰ−ストリームメッセージ６０２とＪＰＰ−ストリームメッセージ６０３の間にギャップがある。そして、第１のギャップの前のレイヤの数と、完了されたレイヤ内の最後のバイトの位置が、決定される。レイヤの数を決定するために、パケットヘッダが、ＪＰＥＧ２０００パート１に記載されているように復号される。パケットヘッダを復号することは、符号ブロックについてエントロピー符号化されたデータを復号するよりも非常に少ない計算が必要とされる。パケットヘッダを復号することは、パケットヘッダとパケットヘッダに続くパケットデータの長さを決定することを許す。符号ブロックについての全てのデータが存在はしない場合には、全体のレイヤが、無視されそして、ＪＰＥＧ２０００符号ストリーム出力へ書き込まれない。

ＪＰＥＧ２０００復号器は、主又はタイルヘッダ内に示されている幾つかのレイヤに依存するいくつかのパケットを期待しているので、一実施例では、空のパケットは、プレシンクトデータ−ビン内で失われるレイヤについて追加される。一実施例では、書き込むレイヤの数は、主ヘッダ内のＣＯＤを超えて優先するタイルＣＯＤ内の情報を有する、主及び現在のタイルヘッダ内のＣＯＤマーカセグメントを試験することにより決定される。ＣＯＤマーカセグメントにより示されたレイヤの数により要求される、しかし、それについてデータが有効でない、いずれのレイヤについて、各パケットについて０バイトが書き込まれる。このバイトは、パケットヘッダが無くそしてパケットについてデータがないことを示す。最も低い解像度については、ＬＬサブバンドに対応するレイヤ当り１つの空のパケットがある。更に高い解像度については、ＬＨ，ＨＬ及び、ＨＨサブバンドに対応する例や当り３パケットがある。

代案
種々の利益を有する変換アルゴリズムに関する可能な幾つかの変形がある。

単一レイヤ出力
１つの代案は、ＪＰＰ−ストリームの全てのレイヤが、出力ＪＰＥＧ２０００符号ストリームの単一の品質レイヤに変換されることである。これは、マーカセグメント内にリストで記述されているレイヤの数（タイル又は主ヘッダＣＯＤ）を１に変更することによりなされることが可能である。多レイヤプレシンクトデータ−ビンを単一のレイヤへ変換する例示の手順は、図７に示されている。図７は、最も低い解像度レベルについての符号ブロックのみを有するプレシンクトデータ−ビンを示す。このように、全てのパケットは、（図６のＨＬ、ＬＨ及びＨＨサブバンドよりは、）ＬＬサブバンドに属する。図７の一番上の部分は、そのプレシンクトについて受信されたパケットヘッダとパケットデータを有する４つのレイヤを示す。第１に、全てのパケットヘッダはＪＰＥＧ２０００パート１に規定されているように、復号される。これは、パケットデータ内の各符号ブロックについてのデータの長さと符号化パスの数に関する情報を提供する。プレシンクト内の各符号ブロックについて、各パケットからのデータは連結される。幾つかのパケットは、特定の符号ブロックについて、データを含まない。例えば、図７では、第３パケットは第１符号ブロックについてデータを有しない。各符号ブロックについて、一旦全てのデータが結合されると、パケットヘッダは、結合されたデータについて書き込まれる。このパケットヘッダは、符号ブロックは、結合されたパケットのいずれかに含まれていた場合には、含まれることを示す。新たなパケットヘッダ内に格納された符号ブロックについてのデータの長さは、結合されたパケット内の符号ブロックについての長さの合計である。新たなヘッダ内の符号化パスの数は、結合されたパケット符号化ブロックからの符号化パスの合計である。

このようにレイヤを結合することの１つの利点は、ＪＰＥＧ２０００ファイルはより小さい：サブバンド当り１つのパケットヘッダのみである、ことである。ＪＰＥＧ２０００符号は、１つのパケットヘッダを復号ことのみなので、多レイヤファイルよりも速く結合されたファイルを復号しそうである。最後に、１つのレイヤのみであるので、動作９の空のパケットバイトは、不要である（プレシンクトのすべてについてデータがないのでなければであり、そのような場合にはパケットが書き込まれる１つの例やがなければならない）。

ギャップを有するプレシンクトデータの使用又は不完全なレイヤ
上述の技術の他の変形は、プレシンクトデータ−ビン内の更なる受信されたデータを使用することである。一実施例では、上述の記載された技術は、完全なレイヤの部分でないデータを無視するが、しかし、サーバは完全なパケットヘッダを送り、そして、幾つかの符号ブロックのみについて符号ブロックデータを含むことが、可能である。一実施例では、そのようなデータを使用するために、ＪＰＰ−ストリーム変換器は、全ての完全なパケットヘッダを復号する。プレシンクトデータ−ビン内の符号ブロックデータ内にギャップがある場合には、これらのギャップは、更なるパケットヘッダを復号するためにスキップされる。（パケットヘッダそれ自身内にギャップがある場合には、パケットヘッダの長さと追加のパケットヘッダの位置が決定できないので、通常は復号は停止する。）ギャップを有するプレシンクトデータビンから正規のＪＰＥＧ２０００符号ストリームを作るために、新たなパケットヘッダが有効なデータについて書き込まれる。有効なデータがない符号ブロックは、新たなパケットヘッダ内で示される。部分的に有効なデータを有する符号ブロックは、正しい長さが、出力パケットヘッダに書き込まれる。ギャップが１つのパケットについて符号ブロック内で発生する場合には、後のパケットの同じ符号ブロックについてのデータは、復号器により正しく使用できないので、無視される。例えば、図８を参照する。

不完全なレイヤを無視しない主な利点は、より高い品質の画像である。

他のプログレッション順序の使用
上述の変換技術は、主ヘッダデータ−ビンとタイルヘッダデータ−ビン内のマーカセグメントにより示されたプログレッションに関わらず、ＣＰＲＬプログレッション順序を使用した。ＣＰＲＬは、レイヤが最後に来るので、使用するのに便利なプログレッション順序である。これは、ＪＰＥＧ２０００符号ストリーム内のパケットが、プレシンクトデータ−ビンと同じ順序で正確に現れることを意味する。レイヤプログレッションが最後の他のプログレッション順序（ＰＣＲＬ，ＲＰＣＬ）は、等しく良好に使用できる。他の２つのプログレッションＬＲＣＰ，ＲＬＣＰの１つ又は、ＰＯＣマーカとともに利用できる複雑なプログレッションを有する出力を発生するために、異なるデータ−ビンからのパケットが、出力でインターリーブされる。このように、ＬＲＣＰについて、第１のレイヤ（ＬＬサブバンドについて１パケット、ＬＨ、ＨＬ及び、ＨＨについて３パケット）は、各解像度、コンポーネント及び、位置についての出力内に含まれる。そして、第２のレイヤが出力に追加される、等である。１つのデータビンが特定のレイヤについて完全なパケットを有しない場合には、１つのゼロバイトがＬＬについての出力に含まれそして、３つのゼロバイトが、ＬＨ、ＨＬ及び、ＨＨについての出力に含まれる。

更新の代わりの計算
ＪＰＰ−ストリームをＪＰＥＧ２０００符号ストリームへ変換するために記載された技術は、一実施例では、動作３で、ＳＯＴセグメントのポインタフィールドに”０”値を書き込む。出力符号ストリームに１つのタイルのみがある場合には、これは、正規の値でありそして、動作１０で値を訂正する必要はない。複数のタイルがある場合には、ＳＯＴマーカセグメントは、最後のものを除いて、全てのタイルパートについて正しいポインタを含む。この技術は、出力がファイル又は、テープの出力のような、”リワインディング”を記述する。出力がメモリの場合には、ＳＯＴマーカセグメントを更新することは平凡なことである。しかし、”リワインディング”が必要でないようにデータを出力に書き込む前に、マーカセグメントの正しい長さを計算することは望ましい。

制限されたアクセス
標準的なＨＴＴＰ認証方法は、画像の部分への選択的なアクセスを提供するインターラクティブプロトコルと共に使用されることが可能である。例えば、低解像度データは、全ての人が利用できるが、しかし、高解像度データはパスワードを有するユーザのみに制限されうる。要求が制限された及び制限されていないデータの両方を含む画像の領域についてなされる場合には、サーバが応答する２つの方法がある。

寛大なサーバは、要求について適切な、全ての制限されていないデータを戻すことができるが、しかし制限されたデータは戻すことができない。そして、制限されたデータのみを戻す結果となる、新たな要求がなされる場合には、サーバは、認証を要求する、エラーメッセージを発行する。これは、”偶然に”制限されたデータを要求しないようにクライアントに注意させること無しに、制限された画像をブラウズすることを可能とする。しかしながら、それは、実際に制限されていないデータのみが受信された時に、クライアントは要求された領域についての全てのデータを受信したという印象を導きうる。このように、クライアントは、ユーザに認証を求めることに失敗し、全てのデータが受信されたように動作する。

制限されたサーバは、制限されたデータを含む要求がなされたときに、エラーを戻す。応答の本体では、サーバは、新たな認証無しで受け付けられる要求についての情報を含みうる。この技術の問題は、混合された要求をするクライアントは、最初にデータを戻さず、そして、ユーザはまずく書かれたブラウザによりエラーメッセージを示されない。

対話の例は次のようである：
最初に、低解像度画像のデータの要求。

がある。

サーバは、このサブ画像を表示するのに必要なデータで応答する。一実施例では、ＪＰＰ−ストリームが使用されそして、そして、チャンクされた転送符号化が使用され、これは、最初の要求についての全ての可能なデータを送っていなくても、次の要求に応答するために、サーバに、その開始を示すことを許すことに注意する。

[１２８かける１２８低解像度画像についてのデータ]
クライアントは、より高い解像度のデータを要求する（ｆｓｉｚパラメータについてのより大きな値に注意する）。

クライアントが制限されたデータを望むことを決定したサーバは、応答として画像データを供給する代わりに認証について促す。

[要求された認証を説明する追加のｈｔｍｌメッセージ]
このデータの受信に際し、クライアントは、典型的には、ユーザに名前とパスワードを供給するように求める、ダイアログボックスを表示する。クライアントが、一旦この情報を受信すると、クライアントは、認証情報とともに、この要求を繰返す。

サーバは、再び、要求は制限されたデータについてであることを決定する。このときに、サーバは”Ａｕｔｈｏｒｉｚａｔｉｏｉｎ：”ヘッダラインを検査し、そして、符号化された名前とパスワードを検査する。これらは正しくそして要求されたデータへのアクセスを提供することに同意すると仮定すると、サーバは追加のデータを戻す。

[２０４８かける２０４８低解像度画像についてのデータ]
選択的なアクセスは、追加の安全性又は効率のために、サーバのハンド−オフ（受け渡し）（以下に詳細に説明する）と結合される。認証の異なるレベルについて有効な画像の部分は、異なるサーバ上に格納される。例えば、低解像度データは、アクセス制限の無い１つのサーバから供給されるが、しかし、高解像度データが望まれる場合には、サーバは、認証又は、ＨＴＴＰＳのような安全なプロトコルによる通信を要求しうる、更に安全なサーバへ発行する。

サーバハンドオフ（受け渡し）
サーバとクライアントはしばしば、図２に示されたようにネットワーク上の異なる点の間に異なる帯域幅と帯域幅コストで、大規模ネットワーク上に存在する。図２のクライアント２０１は、サーバ２０１上の一連のＨＴＭＬページをブラウジングしうる。サブ画像の部分に興味がある場合には、クライアント２２１は、画像の中間解像度版を得るために、サーバ２０１とＪＰＩＰセッションを開始しうる。要求は：

のようである。

サーバ２０１は、中間解像度画像を生成するために必要なデータを含む応答を発生し得る。

[チャンクされたデータは、低又は中間解像度画像を提供し、セロ長のチャンクにより終端される]
クライアントは、より高い解像度画像に興味がありそして、次の要求を発行することを決定する。

この点で、サーバは、むしろ異なるサーバに高解像度データを供給させることを決定しうる。これが起きるのには幾つかの理由がある。”ウェブサイト”は、１つのサーバから利用できる全てのＨＴＭＬページと低解像度画像を有するように、しかし異なるサーバにより高い解像度の画像を格納するように設定されうる。高解像度画像は、安全の理由又は、ディスク空間バランシング又は、ロードバランシングのために、異なるサーバに格納されうる。サーバは、クライアントをクライアントに近いサーバにリダイレクト（向け直し）しうる（これによりクライアントについての応答を改善する）。

ＨＴＴＰでクライアントをリダイレクト（向け直し）する１つの方法は、資源（この場合ｉｍａｇｅ．ｊｐ２）が除去されたことをクライアントへ通知することである。この移動は、同じサーバ上の異なる名前へ、異なるサーバ上の同じ名前へ、又は、異なるサーバ上の異なる名前へであろう。”一時的に移動された”ＨＴＴＰエラーコードが、使用され、それにより、（サーバが異なるサーバにそれらを向け得る点で、）新たなクライアントは将来の要求で中央サーバへ戻りそうである。クライアントの要求への応答は：

のようである。

クライアントは、新たなサーバへ要求を繰返すがしかし、サーバ２０１が有するクライアントキャッシュのモデルを有しないので、サーバ２０２は、おそらくクライアントが既に受信したデータ再送信する。この冗長データの再伝送を避けるために、一実施例では、クライアントは、例えば、”ｍｏｄｅｌ”又は”ｔｐｍｏｄｅｌ”質問パラメータ：

を有する、クライアントキャッシュに関する情報を含む。

この新たなサーバは、更なるデータで応答を継続する。

[チャンクされたデータはより高い解像度画像を供給し、ゼロ長のチャンクで終端される]
クライアントキャッシュ情報の代わりのサーバハンドオフ
そのキャッシュについて、新たなサーバに知らせることをクライアントに要求する代わりに、一実施例では、サーバ２０１は、クライアント２０１について有するキャッシュモデルを、サーバ２０２へ供給する。このためのシンタックスは、ＪＰＩＰ規格により規定されていないが、しかし、サーバ２０１とサーバ２０２の実装により同意されることのみを必要とする。１つの方法は、クライアントがそのクライアントを識別するための情報と共に供給する同じ種類の”ｍｏｄｅｌ”パラメータをいれることである。一実施例では、リダイレクション応答のクライアントは、新たなサーバとチャネル又はセッションｉｄを使用することを継続することを告げ、例えば：

である。

クライアントへのリダイレクト（向け直し）をサーバに発行させそして他のサーバにクライアントキャッシュモデルについて伝えることの欠点は、ある不一致が第２のサーバとクライアントの間で発生しうることである。例えば、一実施例では、サーバが第１のサーバからのキャッシュモデルステートメントを処理する前に、クライアントは、新たなサーバへ要求を発行する。第１のサーバは、クライアントへの応答を発行する前に、第２のサーバと処理を完了することにより、問題を減少できる。いずれの場合にも、第２のサーバが正確なキャッシュモデルを有しない場合には、第１のサーバからクライアントが既に受信したデータを繰返しそうである。

クライアントハンドオフ
ＪＰＩＰ要求に応答してあるデータを受信したクライアントは、クライアントが受信したデータで他のクライアントを開始させ且つサーバへ追加の要求をさせることを望み得る。例えば、デスクトップコンピュータは、スクリーンの解像度で画像をブラウズしそして、ユーザは印刷することを決定する。プリンタは、より高い解像度で印刷することを望むが、しかし、デスクトップコンピュータにより既にダウンロードされた画像データダウンロードすることを避けたいと望む。これを行うためのＪＰＩＰ規格に記載の明確な方法は無いが、しかし、規格に規定された方法を使用する幾つかの可能性がある。

クライアントが、要求：

を発行し、そして、応答を受信したとする。クライアント２２１は、受信されたＪＰＰ−ストリーム又はＪＰＴ−ストリームを、その画像のＵＲＬと共に、クライアント２２２（プリンタ）へ供給できる。一実施例では、クライアント２２２は、そして、更なる画像の要求を発行し、既に受信されたファイルの部分についての情報を提供する：

代わりに、クライアント２２１は、受信されたＪＰＰ−ストリーム又はＪＰＴ−ストリームとそのクライアントがクライアント２２２へ使用したチャネル−ｉｄを供給する。この場合には、サーバは、それが第１のクライアントへまだデータを送信していると信じる。このために、クライアント２２１は、同じセッションに対応するチャネルを使用することを継続してはならず；そうでなければ、クライアント２２２へ供給されたデータはクライアント２２１へ供給されたと信じるので、サーバは後続の要求についての全ての要求されたデータを送り戻さない。この場合に、クライアント２２２によりなされた要求は：

であろう。

クライアント２２１とクライアント２２２が同じ種類の内部データ構造を共有する場合には、おそらくＪＰＩＰ機能は同じライブラリで提供されるので、ＪＰＴ−ストリーム又はＪＰＰ−ストリームの代わりに内部データ構造転送することは可能であろう。これは、クライアント２２２が転送されたストリームを解析する努力を節約する。

ビデオサムネール
ＪＰＩＰは、”ｆｓｉｚ”要求パラメータを使用することにより、単純に、全体の画像の低解像度版を要求する方法を提供する。非常に低解像度について、これらの版は、”サムネール”又は”アイコン”に適する。同様な小さな概要は、ビデオについても形成される。この場合には、フレームサイズが重要なだけで無く、ビデオフレームのあるサブセットを選択することも重要である。

ＪＰＰ−ストリームとＪＰＴ−ストリームメッセージの両方は、メッセージが対応するのはどの符号ストリームかを示す情報を含むことが可能である。モーションＪＰＥＧ２０００画像シーケンスの画像部分は、符号ストリームのシーケンスを復号することにより供給される。従って、完全なビデオの幾つかのフレームのみにつての符号ストリームを含めることにより、ＪＰＰ−ストリーム又はＪＰＴ−ストリームである”ビデオサムネール”を生成することは単純である。一実施例では、メッセージは、各符号ストリームについての低解像度サブ画像のみ又は低及び中解像度を含む。

現在のＪＰＩＰ規格は、単一の符号ストリームについて発行される要求のみを許し；しかしながら、拡張が予想される。１つの単純な拡張は、同じウインドウパラメータが、符号ストリームの範囲のリストで使用されることを許すことである。例えば、秒当り１５フレームのモーションＪＰＥＧ２０００ファイルから１秒離れた間隔の５フレームについてのＨＴＴＰ要求は：

のように発行される。

代わりに、中間のサイズの真中からビデオの部分を得ることを望み得る。一実施例では、定義の拡張で、これは以下の要求：

でなされることが可能である。

範囲のリストを使用する代わりに、ＪＰＩＰ規格への拡張は、複数の符号ストリームから情報を得るために特別な名前を提供されうる。例えば、名称”１ｆｐｓ”は、秒当り１フレームのビデオの概要を受信することを望むことを示しうる。これは、つぎのように：

使用されうる。

現在のＪＰＩＰ規格は、どのオーディオがそのような要求と共に戻されるべきかを規定しない。第２の要求と共に使用されうる１つの技術は、要求された同じフレームに対応するオーディオを戻すことである。第１の要求については、広く間隔のあけられたフレームで、サーバは、第１から最後のフレームをカバーする時間範囲についてのオーディオを戻すことを又は、全くオーディオのないことを選択しうる。

ディスカバリプロトコルを有するＪＰＩＰ
ＪＰＩＰワーキングドラフトは、ＪＰＩＰサーバが供給することを了解したファイルを決定する機構を有しない。現在のデモンストレーションシステムは、典型的には、ＨＴＭＬページを介してのＪＰＥＧ２０００ファイルへのパス又は、クライアントへ前もって知られたＵＲＬを示す。サブ画像のＪＰＩＰトランスポートを開始する最も一般的な方法は、ウェブページのＨＴＴＰ搬送のようなある他のプロトコルのようである。ＪＰＩＰをＪＩＮＩ、Ｒｅｎｄｅｖｏｕｓ又はＧｎｕｔｅｌｌａのようなディスかバリプロトコルと対にすることも有益である。ピア−ツー−ピアプロトコルは、ＪＰＩＰサーバ又はＪＰＩＰデータ形式（ＪＰＰ−ストリームとＪＰＴ−ストリーム）を識別されている資源の形式として認識する必要がある、これは、クライアントが、”近くの”サーバから利用できる画像を見つけることを可能とする（近くの意味はディスカバリプロトコルにより使用される）。異なるサブ画像を異なるクライアントへ送るＪＰＩＰの能力は、特に、異なるディスプレイサイズを有するクライアントが、同じ画像を発見している状況で有益であり、これはそれらがサーバの近くへ移動しているためである。

画像の集合のＪＰＩＰ
ＪＰＩＰは、同じＪＰＥＧ２０００ファイルからサブ画像又は複数のサブ画像を要求する方法を提供する。ファイルの集合から同様なサブ画像を要求する明確な機構はない。しかしながら、特定の実行は、ディレクトリ内の各ファイルについてのサブ画像要求への集められた応答を提供しうる。

例えば、要求は、次の：

である。この要求は、単一のＪＰＥＧ２０００ファイルの低解像度サブ画像を戻す。クライアントは、ディレクトリに同様な要求：

を発行する。

サーバはＵＲＬを資源に変換する責務があるので、サーバは、画像が特定の画像よりもディレクトリを参照することを決定できる。典型的には、サーバは、資源が格納されているファイルシステムを検査することにより、これを行う。ＵＲＬがファイルコンポーネントで終わる場合には、要求はそのファイル上にあり；ＵＲＬがディレクトリで終わる場合には、要求はそのディレクトリ上にある。

サーバは、ディレクトリ内の各ファイルに関する要求を発行し、応答を集めそして、それらをマルチパートＭＩＭＥ応答として戻し、応答の各パートは全体の画像又は、ＪＰＰ−ストリーム又はＪＰＴ−ストリームである。

図９は、ここに記載の１つ又はそれ以上の動作を実行する例示のコンピュータシステムのブロック図である。図９を参照すると、コンピュータシステム９００は、例示のクライアント９５０又はサーバ９００コンピュータシステムを含む。コンピュータシステム９００は、情報を通信する通信機構又はバス９１１、及び、情報を処理するためにバス９１１に接続されたプロセッサ９１２を含む。プロセッサ９１２は、マイクロプロセッサを含むが、しかし例えば、Ｐｅｎｔｉｕｍ（登録商標）、ＰｏｗｅｒＰＣ（登録商標）、Ａｌｐｈａ（登録商標）等のようなプロセッサには限定されない。

システム９００は、更に、情報とプロセッサ９１２により実行される命令を格納するためにバス９１１に接続されたランダムアクセスメモリ（ＲＡＭ）又は、他のダイナミック記憶装置９０４（主メモリと呼ばれる）を有する。主メモリ９０４は、プロセッサ９１２による命令の実行中に一時変数又は他の中間情報を格納するのにも使用されうる。

コンピュータシステム９００は、スタティック情報とプロセッサ９１２についての命令を格納するバス９１１に接続された読み出し専用メモリ（ＲＯＭ）及び／又は他のスタティック記憶装置９０６、及び、磁気ディスク又は光ディスク及びその対応するディスクドライブのようなデータ記憶装置９０７も有する。データ記憶装置９０７は、情報と命令を格納するためにバス９１１に接続されている。

コンピュータシステム９００は、更に、コンピュータユーザへ情報を表示するために，バス９１１に接続された、陰極線管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）のような、表示装置９２１に接続されうる。英数字又は他のキーを有する英数字入力装置９２２は、プロセッサ９１２へ情報を通信し且つコマンドを選択するために、バス９１１にも接続されている。追加のユーザ入力装置は、プロセッサ９１２へ方向情報とコマンド選択を通信し、そして、ディスプレイ９２１上でのカーソルの移動を制御するために、バス９１１に接続された、マウス、トラックボール、トラックパッド、スタイラス又は、カーソル方向キーのような、カーソルコントロール９２３である。

バス９１１に接続された他の装置は、又は、命令、データ又は、他の情報を、紙、フィルム又は、同様な形式の媒体のような媒体上に印刷するのに使用される、ハードコピー装置９２４である。更に、スピーカ及び／又はマイクロフォンのような、音声記録及び再生装置が、オーディオをコンピュータシステム９００とインターフェースするために、オプションでバス９１１に接続される。９１１に接続された他の装置は、電話又は携帯パーム装置と通信する有線／無線通信能力９２５である。

システム９００のどのすべての構成要素と関連するハードウェアは、本発明で使用されうることに注意する。しかしながら、コンピュータシステムの他の構成はいくつかの又は全ての装置を含みうることは、理解されよう。

本発明の多くの代案と修正は、前述の記載を読めば当業者には明らかとなり、例により示され且つ説明された特定の実施例は、限定すると考えるべきではないことは理解されよう。従って、種々の実施例の詳細への参照は、本発明に必須であると考えられる特徴を記載する請求項の範囲を限定するものではない。

圧縮された画像の通信のためのクライアントとサーバを示す図である。 典型的なネットワークを示す図である。 ＪＰＥＧ２０００システムの構成要素を示す図である。 遠隔編集とアップロードされた圧縮されたサブ画像を示す図である。 ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換を示す図である。 プレシンクトデータ−ビンの構造を示す図である。 最も低い解像度レベルに対するコードブロックのみを有するプレシンクトデータ−ビンを示す図である。 ギャップを有するデータ−ビンを変換すること示す図である。 例示のコンピュータシステムのブロック図である。

符号の説明

１０１ クライアント
１０２ サーバ
２０１、２０２、２０３ サーバ
２２１，２２２，２４０ クライアント
９００ サーバ
９０４ 主メモリ
９０６ スタティック記憶装置
９０７ データ記憶装置
９１１ バス
９１２ プロセッサ
９２１ 表示装置
９２４ ハードコピー装置
９５０ クライアント

Claims (28)

1. ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法であって、
   出力ＪＰＥＧ２０００符号ストリームへ、主ヘッダデータ−ビンを、レイヤプログレッションが最後のプログレッション順序の使用を規定するマーカセグメントともに書き込み、
   各タイルについて、
   正規のタイルヘッダを書き込み、
   前記各タイルの各コンポーネント、位置及び、解像度について、
   完全に受信されたレイヤの数を決定し、
   出力ＪＰＥＧ２０００符号ストリームへ、完了されたレイヤに対応するプレシンクトデータビンの１つ又はそれ以上のバイトを書き込み、
   完了していない各レイヤの各パケットに対して、空のパケットヘッダを書き込み、
   パケットデータのバイト数へ長さを調整するためにＳＯＴマーカセグメントを更新し、且つ、
   出力ＪＰＥＧ２０００符号ストリームの最後に、ＥＯＣマーカを書き込む、
   ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
2. レイヤは、完了したレイヤを含む、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
3. 正規のタイルヘッダは、
   出力ＪＰＥＧ２０００符号ストリームへ、ＳＯＴマーカセグメントを書き込み、
   出力ＪＰＥＧ２０００符号ストリームへ、タイルヘッダデータ−ビンの内容を書き込み、
   出力ＪＰＥＧ２０００符号ストリームへ、ＳＯＤマーカヘッダセグメントを書き込むことを含む、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
4. レイヤプログレッションが最後のプログレッション順序は、ＣＰＲＬ、ＲＰＣＬ及び、ＰＣＲＬよりなるグループから選択されものである、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
5. ＳＯＴマーカセグメントは、０のタイルパートインデックスと１に等しい幾つかのタイルパートで書き込まれる、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
6. 各パケットについて空のパケットヘッダを書き込むことは、各パケットへ０バイトを書き込むことを含む、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
7. 更に、書き込むレイヤの数を決定するために、主ヘッダと現在のタイルヘッダ内のＣＯＤマーカセグメントを試験する、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
8. 更に、ＪＰＰ−ストリーム内の全てのレイヤを出力ＪＰＥＧ２０００符号ストリーム内の単一の品質レイヤへ変換することを含む、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
9. ＪＰＰ−ストリーム内の全てのレイヤを出力ＪＰＥＧ２０００符号ストリーム内の単一の品質レイヤへ変換することは、
   マーカセグメント内に記述されたレイヤの数を１に変更し、
   各プレシンクトについてのコードブロックデータを集め、
   各サブバンドに対して、コードブロックの累積長を含む、新たなパケットヘッダを書き込む、
   ことを含む、請求項８に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
10. 不完全なレイヤに関連するデータに対するパケットヘッダを書き込み、
    主ヘッダコードブロック内に、利用できるデータが無いことを示し、
    利用できる部分的なデータを有するコードブロックに対して主ヘッダ内に長さを書き込む、
    請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
11. 出力ＪＰＥＧ２０００符号ストリームが１タイルのみを含む場合には、パケットデータのバイトの数の長さを調整するためにＳＯＴマーカセグメントへリワインドすることが実行されない、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
12. マーカセグメントはＣＯＭマーカセグメントである、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
13. 出力ＪＰＥＧ２０００符号ストリームが１タイルのみを含む場合には、パケットデータのバイトの数へ長さを調整するためにＳＯＴマーカセグメントへ更新することが実行されない、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
14. マーカセグメントはＣＯＭマーカセグメントである、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換方法。
15. 格納された命令を有する１つ又はそれ以上の記録可能な媒体を有する製造物であって、その命令が、システムにより実行されたときに、
    出力ＪＰＥＧ２０００符号ストリームへ、主ヘッダデータ−ビンを、レイヤプログレッションが最後のプログレッション順序の使用を規定するマーカセグメントともに書き込み、
    各タイルについて、
    正規のタイルヘッダを書き込み、
    前記各タイルの各コンポーネント、位置及び、解像度について、
    完全に受信されたレイヤの数を決定し、
    出力ＪＰＥＧ２０００符号ストリームへ、完了されたレイヤに対応するプレシンクトデータビンの１つ又はそれ以上のバイトを書き込み、
    完了していない各レイヤの各パケットに対して、空のパケットヘッダを書き込み、
    パケットデータのバイト数へ長さを調整するためにＳＯＴマーカセグメントを更新し、且つ、
    出力ＪＰＥＧ２０００符号ストリームの最後に、ＥＯＣマーカを書き込む、
    ことにより、そのシステムが、ＪＰＰ−ストリームをＪＰＥＧ２０００符号ストリームへ変換するようにする、ＪＰＰ−ストリームをＪＰＥＧ２０００符号ストリームへ変換する、製造物。
16. レイヤは、完了したレイヤを含む、請求項１５に記載の製造物。
17. その命令は、その命令が、実行されたときに、
    出力ＪＰＥＧ２０００符号ストリームへ、ＳＯＴマーカセグメントを書き込み、
    出力ＪＰＥＧ２０００符号ストリームへ、タイルヘッダデータ−ビンの内容を書き込み、
    出力ＪＰＥＧ２０００符号ストリームへ、ＳＯＤマーカヘッダセグメントを書き込むことにより、システムに、正規のタイルヘッダを発生させる命令を含む、請求項１５に記載の製造物。
18. レイヤプログレッションが最後のプログレッション順序は、ＣＰＲＬ、ＲＰＣＬ及び、ＰＣＲＬよりなるグループから選択されものである、請求項１５に記載の製造物。
19. ＳＯＴマーカセグメントは、０のタイルパートインデックスと１に等しい幾つかのタイルパートで書き込まれる、請求項１５に記載の製造物。
20. 各パケットについて空のパケットヘッダを書き込むことは、各パケットへ０バイトを書き込むことを含む、請求項１５に記載の製造物。
21. その命令は、その命令が、実行されたときに、システムに、
    ＪＰＰ−ストリーム内の全てのレイヤを出力ＪＰＥＧ２０００符号ストリーム内の単一の品質レイヤへ変換させる命令を含む、請求項１に記載の製造物。
22. その命令は、その命令が、実行されたときに、システムに、
    不完全なレイヤに関連するデータに対するパケットヘッダを書き込み、
    主ヘッダコードブロック内に、利用できるデータが無いことを示し、
    利用できる部分的なデータを有するコードブロックに対して主ヘッダ内に長さを書きこむ、
    ことをさせる命令を含む、請求項１に記載の製造物。
23. ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置であって、
    出力ＪＰＥＧ２０００符号ストリームへ、主ヘッダデータ−ビンを、レイヤプログレッションが最後のプログレッション順序の使用を規定するマーカセグメントともに書き込む手段と、
    正規のタイルヘッダを書き込む手段を有する、各タイルに処理を実行する手段と、
    前記各タイルの各コンポーネント、位置及び、解像度について、完全に受信されたレイヤの数を決定する手段と、
    前記各タイルの各コンポーネント、位置及び、解像度について、出力ＪＰＥＧ２０００符号ストリームへ、完了されたレイヤに対応するプレシンクトデータビンの１つ又はそれ以上のバイトを書き込む手段と、
    前記各タイルの各コンポーネント、位置及び、解像度について、完了していない各レイヤの各パケットに対して、空のパケットヘッダを書き込む手段と、
    パケットデータのバイト数へ長さを調整するためにＳＯＴマーカセグメントを更新する手段と、
    出力ＪＰＥＧ２０００符号ストリームの最後に、ＥＯＣマーカを書き込む手段と、
    を有する、ＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置。
24. レイヤは、完了したレイヤを含む、請求項２３に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置。
25. 正規のタイルヘッダを発生する手段は、
    出力ＪＰＥＧ２０００符号ストリームへ、ＳＯＴマーカセグメントを書き込む手段と、
    出力ＪＰＥＧ２０００符号ストリームへ、タイルヘッダデータ−ビンの内容を書き込む手段と、
    出力ＪＰＥＧ２０００符号ストリームへ、ＳＯＤマーカヘッダセグメントを書き込む手段と、
    を有する、請求項１に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置。
26. レイヤプログレッションが最後のプログレッション順序は、ＣＰＲＬ、ＲＰＣＬ及び、ＰＣＲＬよりなるグループから選択されものである、請求項２３に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置。
27. 更に、ＪＰＰ−ストリーム内の全てのレイヤを出力ＪＰＥＧ２０００符号ストリーム内の単一の品質レイヤへ変換する手段を含む、請求項２３に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置。
28. 更に、
    不完全なレイヤに関連するデータに対するパケットヘッダを書き込む手段と、
    主ヘッダコードブロック内に、利用できるデータが無いことを示す手段と、
    利用できる部分的なデータを有するコードブロックに対して主ヘッダ内に長さを書き込む手段と、
    を有する、請求項２３に記載のＪＰＰ−ストリームからＪＰＥＧ２０００符号ストリームへの変換装置。
    
    

Images