JP2009017527A - サーバにより駆動されるプログレッシブ画像伝送方法およびシステム - Google Patents

Abstract

【課題】この発明のシステムおよび方法は画像を表すプログレッシブコードストリームを生成する。
【解決手段】画像を表すパケットのコードストリームが解析され、解析されたパケットと各解析パケットに対するメタデータとを得る。上記メタデータとプログレッシブトランスミッションポリシーにしたがって、上記解析パケットが分解パケットに分解される。上記メタデータと上記トランスミッションポリシーにしたがって上記分解パケットを順番に配列された複数のセグメントに割り当て、各セグメントはヘッダを含み、また上記コードストリームにおける上記パケットの配列は上記複数のセグメントにおける上記分解パケットの配列と異なる。クライアントは、該クライアントにおける画像を順次再構成するために、上記セグメントにおけるヘッダにしたがって上記分解パケットを構成する。
【選択図】図１

Description

この発明は一般に、イメージ（画像）およびビデオ（映像）の伝送に関し、特にサーバ側のプログレッシブイメージトランスミッション（漸次画像伝送）に関する。

ビデオ監視、携帯電話、デジタルカメラ、プリンタ、スキャナ、ファクシミリ、コピー機、メディカルイメージング（医療診断画像）、衛星イメージング、インターネット、およびコンパウンドドキュメント（複合文書）は、画像（イメージ）および映像（ビデオ）のアプリケーションに対する需要を増大させた。メモリや、プロセッサや、ネットワーク帯域幅等の制限されたリソースにより、高品位画像を保存し、処理し、伝送し、レンダリング（描写）することは、しばしば可能ではない。

画像の品質は、画像おけるピクセル数、および各ピクセルに割り当てられるビット数に依存する。たとえば、１０２４×１０２４のピクセルで、各ピクセル当たり２４ビットの画像は２５Ｍｂの高品質であるが、１ピクセル当たり１ビットを有する１０×１０ピクセルの画像は１００ビットの低品質の白黒画像である。ここで、品質差は５桁よりも大きい。

ＪＰＥＧ２０００（たとえば、ＩＳＯ／ＩＥＣ１５４４４ー１規格／−１、「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−ＪＰＥＧ ２０００ ｉｍａｇｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ−Ｐａｒｔ １：Ｃｏｒｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ（情報技術−ＪＰＥＧ２０００イメージコーディングシステムーパート１：コアコーディングシステム）」、初版、２０００、およびＤ．Ｔａｕｂｍａｎ、Ｍ．Ｍａｒｃｅｌｌｉｎ、「ＪＰＥＧ ２０００：Ｉｍａｇｅ Ｃｏｍｐｒｅｓｓｉｏｎ Ｆｕｎｄａｍｅｎｔａｌｓ，Ｓｔａｎｄａｒｄｓ ａｎｄ Ｐｒａｃｔｉｃｅ（ＪＰＥＧ２０００：画像圧縮ファンダメンタルズ、スタンダードおよびプラクティス）」、Ｋｌｕｗｅｒ Ａｃａｄｅｍｉｃ Ｐｕｂｌｉｓｈｅｒｓ、ボストン、２００２を参照）等の圧縮標準は、画像データの異なる品質、レゾルーション（解像度）、コンポーネント（構成要素）および位置を容易に保存し、処理し、伝送し、描写することができるように、スケーラブルな方法で設計されている。
ＪＰＥＧ２０００はウェーブレットベースの圧縮方式を使用する。

ＪＰＥＧ２０００は、元のＤＣＴベースのＪＰＥＧ（ジェーペグ）標準より高い圧縮比で、エイリアシングアーティファクトを生じることなく作動する。また、ＪＰＥＧ２０００はプログレッシブ（漸次）ダウンロードを可能にする。画像は複数のタイルに分割される。二次元ウェーブレット変換が、様々な解像度でサブバンド（副帯域）にグループ化された一組のウェーブレット係数を生成するために、各タイルで行なわれる。ウェーブレット変換係数は、「複数のプレシンックト（区域）」に再編成される。区域は画像の空間的な部位へのアクセスを可能にする。区域はコードストリームとしての圧縮のために複数のコードブロックに分割される。

コードストリームは画像データを含むセグメントを識別するためのマーカーセグメントを含む。ヘッダは、画像成分の幅寸法と高さ、および圧縮データがどのように復号されるべきであるかを説明するパラメータに関する情報を含む。タイル部はヘッダの後に続く。コードストリームは、全てのエントロピー（平均情報量）コード化画像データと、データを復号するにための方法を示す情報とを含む。また、コードストリームは、使用されたウェーブレット変換、タイルのサイズ、区域サイズ、解像度の数、およびパケットの配列に関する情報を含む。また、コードストリームは、画像データへの直接アクセスを可能にするパケット長情報を含む。

コードストリームとしてのスケーラブルなコード化された画像のプログレッシブ伝送は、画像の或る（幾つかの）部分が最初に伝送されるプロセスについて言及する。たとえば、人間を含むフォアグラウンドリージョン（前面領域）は、バックグラウンドリージョン（背景領域）の前に伝送される。また、品質や解像度等の他の要素を考えることもできる。たとえば、プログレッシブ品質は、きめが粗く量子化された画像のサンプルを最初に伝送し、続いて、精細化された画像のサンプルを伝送することによって実現される。ネットワーク帯域幅が制限されているとき、これは、ユーザが短い時間で画像の比較的低品質のバージョンを視聴することを効果的に可能にする。より多くのデータが受信されるにつれて、画像品質は時間の経過とともに向上する。

画像のプログレッシブコード化および送信は、ＪＰＥＧ（ジェーペグ）とＪＢＩＧ（ジェービグ）ファイルフォーマット（形式）標準によってサポートされる（Ａ．Ｎ．Ｎｅｔｒａｖａｌｉ、Ｂ．Ｇ．Ｈａｓｋｅｌｌ、「Ｄｉｇｉｔａｌ Ｐｉｃｔｕｒｅｓ − Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ａｎｄ Ｃｏｍｐｒｅｓｓｉｏｎ（ディジタル画像−表示と圧縮）」、第２版、ニューヨーク、ロンドン、プレナムプレス、１９９５、およびＷ．Ｐｅｎｎｅｂａｋｅｒ、Ｊ．Ｍｉｔｃｈｅｌｌ、「ＪＰＥＧ Ｓｔｉｌｌ Ｉｍａｇｅ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ Ｓｔａｎｄａｒｄ（ジェーペグ静止画データ圧縮標準）」、Ｖａｎ Ｎｏｓｔｒａｎｄ Ｒｅｉｎｈｏｌｄ、ニューヨーク、１９９３を参照）。画像の配列は、全体の画像に対してグローバルに定義される。標準は、単一の配列で十分である場合には、制限された数（少数）の可能なプログレッシブ配列（順序）を許容し、また有効なアプリケーションを制限する。

ＪＰＥＧ２０００は、フレキシブルなプログレッシブ配列や画像タイリングのような、高度のフィーチャー（特徴）に対するより良好な圧縮とサポートとにより、より古いジェーペグファイル形式標準を改良する。プログレッシブ配列は、コードストリーム中に置かれたマーカーによって、コードストリームの部分に対してグローバルに、またローカルに、定義される。マーカーはプログレッシブ配列における変化を示す。しかし、マーカーの付加は、ストリームのサイズを増大させ、また、画像のあらゆる領域の独立制御を許容しない。

この問題を減少させるため、画像のタイリングが、画像を独立して圧縮される複数の領域に分割するのに使用される。そして、プログレッシブな方法で、それらの領域を独立して保存し、処理し、伝送し、描写することができる。また、画像タイリングはコードストリームのサイズを増大させる。多くのタイルが必要とされるアプリケーションでは、サイズの増大は、大きい場合がある。また、タイリング領域は、プログレッシブ配列（順序付け）の１つのスタイルである、画像の空間的な区分化により整列された区域で、長方形に制限される。

ジェーペグのインタラクティブ（対話型）プロトコル（ＪＰＩＰ）は、ＪＰＥＧ２０００標準のパート９として標準化されている（参照：ＩＳＯ／ＩＥＣ１５４４４−９、「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−ＪＰＥＧ ２０００ ｉｍａｇｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ−Ｐａｒｔ ９：Ｉｎｔｅｒａｃｔｉｖｉｔｙ ｔｏｏｌｓ，ＡＰＩｓ ａｎｄ ｐｒｏｔｏｃｏｌｓ（情報技術−ＪＰＥＧ２０００画像コーディングシステムーパート９：対話性ツールズ、ＡＰＩおよびプロトコル）」、初版、２００５、およびＤ．Ｔａｕｂｍａｎ、Ｒ．Ｐｒａｎｄｏｌｉｎｉ、「Ａｒｃｈｉｔｅｃｔｕｒｅ，ｐｈｉｌｏｓｏｐｈｙ ａｎｄ ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ＪＰＩＰ：ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｓｔａｎｄａｒｄ ｆｏｒ ＪＰＥＧ２０００（ＪＰＩＰのアーキテクチャ、原理および性能：ＪＰＥＧ２０００に対するインターネットプロトコルの標準）」、Ｐｒｏｃ．ＳＰＩＥ Ｃｏｎｆ．ｏｎ Ｖｉｓｕａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｍａｇｅ Ｐｒｏｃｅｓｓｉｎｇ，ＳＰＩＥ ｖｏｌｕｍｅ ５１５０，ｐｐ．６４９−６６３，２００３を参照）。

ＪＰＩＰは、クライアントコンピュータ（クライアント）がサーバコンピュータ（サーバ）からの伝送のために画像の部分を選択するのを可能にする要求応答プロトコルである。

利点として、各クライアントは特定用途要求条件に対して画像のフォーマットを選択できる。具体的には、各クライアントは１つまたは複数のＨＴＴＰ ＧＥＴ要求をする。それらの要求は画像リソースの名前と要求するクエリフィールドとを含む。フィールドは、レイヤ、解像度、コンポーネント（構成要素）、プレシンックト（区域）、視界窓、セッション、キャッシュされたデータ等の多くの可能な画像フィーチャー（特徴）を記載している。

プロトコルはインタラクティブ（対話型）の方法で行なわれ、これにより、クライアントは要求を出し或る（幾つかの）画像データを受信し、そして、クライアントは次に何を要求したらよいかを決める。ＪＰＩＰは、クライアントまたはサーバの動作ではなく、サーバに対してクライアントによって開始される対話型プロトコルを定義するだけであることに注意することが重要である。双方向の通信が必要になるので、このクライアント駆動のプロトコルの処理および信号化のオーバヘッドは比較的高い。ＪＰＩＰでは、コード化画像データに対する要求はクライアントに起因する。そのような対話性は、「Ｒｅｍｏｔｅ Ｂｒｏｗｓｉｎｇ ｏｆ ＪＰＥＧ ２０００ Ｉｍａｇｅｓ（ＪＰＥＧ２０００イメージズのリモートブラウシング）」、Ｐｒｏｃ．ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｉｍａｇｅ Ｐｒｏｃｅｓｓｉｎｇ，ｖｏｌ．１，ｐｐ．２２９−２３２，２００２、に記載されているように、巨大画像のリモート（遠隔）ブラウシングに対して有用である。

また、対話型画像ブラウシングはバイトレンジング（ｂｙｔｅ ｒａｎｇｉｎｇ）技術（ＤｅｓｈｐａｎｄｅおよびＺｅｎｇ、「Ｓｃａｌａｂｌｅ ｓｔｒｅａｍｉｎｇ ｏｆ ＪＰＥＧ ２０００ ｉｍａｇｅｓ ｕｓｉｎｇ ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ（ハイパーテキスト転送プロトコルを使用したＪＰＥＧ２０００画像のスケーラブルなストリーミング）」、Ｐｒｏｃ．ＡＣＭ Ｍｕｌｔｉｍｅｄｉａ，ｐｐ．３７２−２８１，２００１を参照）を使用することもできる。その方法は、バイトレンジ（バイト領域）アクセスに対してＨＴＴＰ／１．１を使用して、クライアントが要求される関連圧縮データの位置（バイトレンジ）とヘッダ情報を推論できるインデックステーブルの送信を必要とする。

プログレッシブ画像伝送に関する従来の作業の多くはクライアント駆動であり、クライアントからの対話型の要求がサーバからクライアントへのコード化された画像の伝送を誘導する。しかし、クライアント駆動の要求を必要としない、多くのプログレッシブ伝送アプリケーションが存在する。したがって、フレキシブルなプログレッション（進行）を促進し、且つ最小量の信号化オーバヘッドおよび処理要件を有するサーバ駆動のプログレッシブ画像伝送に対する必要性がある。

以下の用語は、ＪＰＥＧ２０００仕様により定義され、本明細書中で使用される。

ビットストリーム：一連の符号のコード化に起因するビットの実際の順序。
それは、メインおよびタイル部ヘッダのマーカーまたはマーカーセグメントまたはＥＯＣマーカーを含まない。それはストリームマーカーにおける如何なるパケットヘッダも含み、またメインヘッダまたはタイル部ヘッダの中で見出されなかったマーカーセグメントを含む。

コードストリーム：１つまたは複数のビットストリームとメインヘッダ、タイル部ヘッダ、およびそれらの画像データへの復号化および伸張するために必要とされるＥＯＣの集合。
これは、信号化の全てを復号するのに必要になる圧縮形式の画像データである。

圧縮画像データ：ビットストリームの一部または全部。
また、コードストリームの一部または全部においてビットストリームの集合を表すことができる。

プログレッション（進行）：連続した各ビットの復号化が画像の「より良好な」再構成に寄与するコードストリームの配列（順序）。再構成を「より良く」するものは、アプリケーションの機能である。プログレッションの幾つかの例は、解像度を増大すなわちサンプル忠実度を向上させている。

この発明のシステムおよび方法は画像を表すプログレッシブコードストリームを生成する。画像を表すパケットのコードストリームが解析され、解析されたパケット（以下、解析パケットと呼ぶ）と各解析パケットに対するメタデータとを得る。

上記メタデータとプログレッシブトランスミッションポリシーにしたがって、上記解析パケットが分解パケットに分解される。

上記メタデータと上記トランスミッションポリシーにしたがって上記分解パケットを順番に配列された複数のセグメントに割り当て、各セグメントはヘッダを含み、また上記コードストリームにおける上記パケットの配列は上記複数のセグメントにおける上記分解パケットの配列と異なる。

クライアントは、該クライアントにおける画像を順次再構成するために、上記セグメントにおけるヘッダにしたがって上記分解パケットを構成する。

この発明の実施の形態は、順次画像を生成して、サーバからクライアントへ伝送するための方法を提供する。本方法は、サーバ駆動であり、作動するためにクライアントからの入力を必要としない。この発明は、最小量の信号化オーバヘッドでさまざまなプログレッションを促進する。また、この発明は、最小遅延でクライアントでの再構成画像のインクリメンタル（増分的）なデコーディング（復号化）およびレンダリングを可能にする。

この発明と従来のＪＰＩＰプロトコルの主要な差異は、インタラクティブ（対話型）モードである。ＪＰＩＰは、クライアント駆動の要求応答プロトコルと定義される。
対照的に、この発明による方法は、サーバによって完全に定められたプログレッシブな配列で画像をクライアントに提供する。従来のＪＰＩＰでは、これは、同じような望ましい配列を実現するためには、クライアントによる何千もの要求を潜在的に必要とするかもしれない。この発明は、クライアントでの何らかの要求プロトコルを必要とし、また要求応答ペア（対）による如何なる送信要求オーバヘッドもまたは往復遅延も付加しない。コードストリームを配列（順序付け）は完全にサーバにより、および／またはサーバ上で実行するアプリケーションにより、決められる。

顔認証アプリケーションにおける例に対して、望ましい伝送配列（順序）は、顔だけを含む画像の注目領域（ＲＯＩ）を、恐らく低下した品質で、最初に伝送する。次に、その領域における顔の品質が、プログレッシブレイヤで時間経過とともに改良される。従来のＪＰＩＰでこれを実現するためには、クライアントは、最初に、サーバによってクライアントへ伝送されるコードストリームの望ましい配列（順序）を決めるために、全体の画像にアクセスする必要があるが、これは実用的ではない。

方法およびシステムの概要
図１は、この発明の実施の形態による、ネットワーク１０３を介してサーバ１０１からクライアント１０２へプログレッシブ（漸次）に画像を生成して、伝送するための方法およびシステムを示す。本方法はサーバ駆動である。

サーバ
サーバ１０１は、パーサ／トランスコーダ１１０およびデコンポーザー（分解器）５００を含む。本方法はサーバで開始される。本方法に入力されるのは、１つ以上の画像から得られたコードストリーム１０４と、プログレッシブトランスミッションポリシー１０５である。コードストリームは、何らかの画像から得られた従来のＪＰＥＧ２０００コードストリームでもよい。コードストリームは、サーバアプリケーション１０８により生成されてもよい。上記ポリシーは、そのアプリケーションで一部決めることができる。そのポリシーの他の部分は、利用可能なシステムリソース１０９（メモリ、バッファ、バンド幅等）に関連し得るが、サーバにより決めることができる。そのポリシーは、たとえば、対応するセグメントのヘッダおよびＪＰＥＧ２０００パケット等のセグメント１１６として伝送されるパケットのプログレッシブな伝送順序を特定する。また、伝送順序をプログレッシブトランスミッションポリシーと呼ぶこともできる。

トランスコーダ
パーサ／トランスコーダ１１０は、解析されたコードストリーム１１１およびメタデータ３００（図３を参照）を生成する。また、ポリシー１０５およびメタデータ３００にしたがって、入力コードストリーム１０４をコード変換することができる。メタデータは、解析されたコードストリームにおける各パケットに関する記述的な情報を示す。

解析コードストリーム１１１はメタデータ３００およびポリシー１０５にしたがって分解（１１５）されて、セグメント１１６を生成する。セグメント１１６は、ネットワーク１０３上を介して、クライアント１０２へプログレッシブ伝送される。

解析／コード変換されたコードストリーム１１１は、減少したデータレート（転送速度）、減少した品質、トリミングされた画像、または変更されたプログレッシブ順序を有することができる。プログレッシブ順序を変えるのは、分解の複雑さを減少させて、以下に詳細に記載されるように、オーバヘッドを最小にするために有用である。本方法は、如何なる既知のトランスコーダも使用できる。好ましい符号変換方法は、本明細書中に引用して援用する米国特許公開２００６０１２０６１０「Ｉｍａｇｅ Ｔｒａｎｓｃｏｄｉｎｇ（画像符号変換）」に記載されている。

セグメント１１６は、ＪＰＩＰ標準に適合（準拠）しないかもしれない解析コードストリームの部分である。各セグメント１１６は、セグメントに含まれるパケットに関する記述的な情報を提供する１つ以上のヘッダを含んでいる。

クライアント
セグメント１１６はクライアント１０２により受信される。キャッシュ１３０またはメモリバッファでセグメントを保存することができる。構成動作５００は、従来のコードストリーム１２２を再構成するために、セグメント１１６で受信されたパケットを再配列（順序付け）し、必要に応じて、空のパケットを挿入する。構成プロセス（処理）は、新しいセグメントが受信される毎に、呼び出される。ユーザに対して画像１２６を生成するために、再構成されたコードストリーム１２２を描写１２４することができる。なお、再構成の間にパケットを番号順に配列（順序付け）することは、コードストリームにおける元の近接する番号順の配列（順序付け）から異なる場合がある。

この発明をＪＰＥＧ２０００仕様にしたがって説明したが、この発明は、より一般に、どのようにプログレッシブ（漸次）にコード化された画像またはビデオにも適用する。

分解
図２は分解動作２００に関するフローチャートである。分解プロセスはポリシー１０５にしたがって動作する。分解プロセスは解析コードストリーム１１１のパケットおよび対応するメタデータ３００を読み込む（２１０）。パケットは、如何なるサイズのコードストリームの次の近接する部分からも来る。コードストリームが完全に処理されると、次に、スキャン２２０が行われる（２３０）。

もっと多くのパケットがあれば、プロセス（処理）は、ポリシー１０５にしたがって、次のセグメントを選択（２４０）して、そのセグメントのパケットをセグメント１１６に割り当てる。或るセグメントのパケットがどのセグメントにも割り当てられないことが、起こるかもしれない。この場合、そのセグメントは効果的に捨てられる。

そのセグメントが含まれるべきであるならば、プロセスは、コードストリームデータのこのセグメントについて記述するために、正しいヘッダタイプを選択（２５０）する。次に、プロセスはヘッダのフィールドを決定し（２６０）（図４参照）、セグメント１１６に対してヘッダを書き込む（２７０）。そのセグメントのパケットがセグメント１１６に書き込まれる（２８０）。そして、プロセスは次のセグメントを読み出す（２１０）。

図２は、１回のスキャン（すなわち解析コードストリーム１１１の１回の走査（横断））で生成される全てのセグメント１１６を示している。しかし、種々の回数のスキャンで様々な数のセグメントを生成するように、プロセス（処理）を変更することができる。

分解プロセス２００は、どのような再配列（再順序付けされた）コードストリームをもコード化するための一般解を提供する。このプロセスを使用して、プログレッシブ伝送およびレンダリングの順序を変えることができ、また、特定の品質レイヤ、解像度レベルまたは構成要素に対応するパケットを削除することができる。このようにして、空間的な対象領域のプログレッシブトランスミッション（伝送）を実現することができる。

メタデータ
図３はメタデータ３００の構造を示す。解析コードストリームにおける各パケット１１１に対して１ブロックのメタデータ３００がある。この情報は、サーバに対して内部にあり、解析コードストリーム１１１のパケットを分解（２００）して分解されたパケットをセグメント１１６に割り当てるのに使用されるだけである。

メタデータは、品質レイヤインデックス（Ｌ）３０１と、解像度レベルインデックス（Ｒ）３０２と、構成要素インデックス（Ｃ）３０３と、プリーシンクト（区域）インデックス（Ｐ）３０４と、バイト２０５で表現されるデータサイズと含む。すなわち、メタデータは階層的なＬＲＣＰ順序で配列される。セグメントがＲＯＩ領域の一部であるときに、オプション（任意）のＩｓＲＯＩビット３０６はトルー（真実）である。オプションのＩｓＵｓｅｄビット３０７は何れのセグメント１１６にも含まれるセグメントを追跡する。

ヘッダ
図４はセグメント１１６に対するヘッダを示す。各セグメントは、セグメントヘッダ４０１で始まり、その後にセグメントパケット４０２が続き、恐らく更に多くのヘッダ４０１と、更に多くのパケット４０２とが続く。

ヘッダ４０１の全てのまたは幾つかのフィールドは、必要なければ、またはクライアントにより予測できるならば、省略することができる。第１のフィールドは「タイプ」４１１であり、それはたとえば、長い１２バイトのフォーマットまたは短い６バイトのフォーマット等のヘッダの型を意味し、何れかの省略されたヘッダフィールドも示す。「ＩＤ」４１２はセグメント中のパケットに対するインデックスである。「カウント」４１３は、コードストリームデータセグメントにおける後続のシーケンシャル（順次）ＩＤの数を含んでいる。「サイズ」４１４は後続のコードストリームパケットのバイト数である。これらのフィールドは、パケットへの直接アクセスを可能にし、また、クライアントで順次復号されて描写されることができる有効なコードストリームの再構成を可能にする。

構成
図５は、スタート５０１で始まるクライアント１０２での構成動作５００に関するフロー図である。構成動作の第１段階はセグメントを読み出すことである。有効なヘッダが読み出されたならば（５１０）、ヘッダが順序付きリスト６００へ挿入（５５０）される（図６を参照）。次に、そのセグメントのパケットが読み出され（５９５）、順序付けされているセグメントリスト６００に挿入（５５０）される。そして、構成プロセスは次のヘッダを読み出そうとする。これは、ファイルの終り５２０に遭遇して、全ての利用可能なヘッダとセグメントとが読み出されるまで続く。

構成プロセスの第２段階は、順序付けされたセグメントリスト６００から再構成されたコードストリーム１２２を生成することである。構成プロセスは、ソートされたセグメントリスト６００をスキャン（５３０）する。スキャンがリストの終端５４０に達したならば、そのプロセスを終える。リストの終端に達しないならば、そのプロセスは、そのセグメントが再構成されたコードストリームに含まれる（５７０）べきであるか否か決める。
それが含まれるべきであるならば、このセグメント中のパケットが、再構成されたコードストリームの一部として書き込まれる（５８０）。セグメントが含まれるべきでないならば、空のパケットが、再構成されたコードストリームの一部として書き込まれる（５９０）。次に、ソートされたセグメントリストにおける次のセグメントがスキャンされ、そして、全てのセグメントが、再構成されたコードストリーム１２２に包含されるべきか否かについて調べられるまで、そのプロセスは繰り返す。

構成動作５００は、本質的には、それら自身では必ずしもデコーダに適合しない、または重要ではないセグメントから、適合するコードストリームを再構成する。

セグメントリスト
図６はソートされたセグメントリスト６００を示す。このリンクされたリストは、リストエレメント（ＬｉｓｔＥｌｅｍｅｎｔｓ）６０１と次のポインタ（Ｎｅｘｔ ｐｏｉｎｔｅｒｓ）６０２のリンク（連鎖）を含んでいる。各リストエレメント（ＬｉｓｔＥｌｅｍｅｎｔ）は、セグメント１１６のセグメント（パケット）４０２のヘッダ４０１を指し示すヘッダフィールド６１１およびデータ６１２を含んでいる。

分解／構成例
図７〜図１２はこの発明の実施の形態によるプログレッシブコードストリームの様々の例を示す。フィールドの数が多いため、参照番号は明瞭化のため省略された。命名されたフィールドは前述と同様である。

図７は、位置（Ｐ）と品質レイヤ（Ｌ）にしたがって再配列（再順序付け）されたパケットを示す。入力コードストリーム１０２は、ＪＰＥＧ２０００コードストリームのメインヘッダに対応するＪＰＣヘッダで始まり、パケット１からパケット２４まで続く。最初の６つのパケットは位置０に対応する。このために、位置０に関する全ての情報が最初に配列（順序付け）され、そして、コードストリームは位置によって配列（順序付け）されるものとして言及される。パケット｛１、２｝は位置０で品質レイヤ０を表し、パケット｛３、４｝は位置０で品質レイヤ１を表し、パケット｛５、６｝は位置０で品質レイヤ２を表す。
位置１、２および３に対する全てのデータが同じフォーマットで後続する。なお、ヘッダが各組の数値的に近接するパケットに先行することに注意すべきである。

次に、入力コードストリームは３つの品質レイヤに対応する３つのセグメント７００に分解される。セグメント０レイヤ０はセグメントヘッダから始まり、入力コードストリームからのＪＰＣヘッダおよびパケット｛１、２｝により後続される。次に、パケット｛７、８｝により後続される別のセグメントヘッダが挿入さる。このパターンがコードストリームデータのその後の位置に対して続く。これは、特定のセグメント内の位置によって順序付けされた、全ての位置に対する全ての品質レイヤ０を含むセグメント０を完成する。

同様に、セグメント１レイヤ１は位置によって順序付けされた全ての位置に対する品質レイヤ１パケットの全てを含んでおり、また、セグメント２レイヤ２は位置によって順序付けされた全ての位置に対する品質レイヤ２パケットの全てを含んでいる。これらの３つのセグメントが整列した状態でクライアントに伝送される。

図８〜図１０は上述した分解例に対する構成プロセスを示す。最初に、図８に示されるように、セグメント０がクライアントにより受信される。セグメントヘッダおよび含まれるコードストリームパケットに基づいて、全ての位置の品質レイヤ０に対応する再構成されたコードストリームが生成される。再構成されたコードストリームは、ＪＰＣメインヘッダで始まり、そして、パケット｛１、２、７、８、１３、１４、１９、２０｝を含んでいる。

空のパケットが、欠けているパケット｛３−６、９−１２、１５−１８、２１−２４｝に対して挿入された。その結果、ＪＰＥＧ２０００標準に完全に適合し、且つ、全ての位置に対する品質レイヤ０に対応するコードストリームデータとその他の品質レイヤに対する空のパケットとのみを含むコードストリームが生成される。このために、圧縮画像は、入力コードストリーム１０２にコード化されたように、最初に位置０ではなく、最初に品質レイヤ０でクライアントに受信される。

構成プロセスは、セグメント１を受信する際に、図９に続く。セグメントヘッダおよび含まれたコードストリームデータに基づいて、再構成されたコードストリームは、全ての位置に対する品質レイヤ１にも対応するパケットを含むように増大される。この場合、再構成されたコードストリームはＪＰＣメインヘッダで始まり、そしてパケット｛１−４、７−１０、１３−１６、１９−２２｝を含む。空のパケットが、欠けているパケット｛５、６、１１、１２、１７、１８、２３、２４｝に対して挿入された。その結果、ＪＰＥＧ２０００標準に完全に適合し、且つ、全ての位置に対する品質レイヤ０および１に対応するコードストリームデータとその他の品質レイヤに対する空のパケットとのみを含むコードストリームが生成される。

構成プロセスの最終段階が図１０に示されており、そこでは、セグメント３が受信される。セグメントヘッダおよび含まれるコードストリームデータに基づいて、再構成されたコードストリームは、全ての位置に対して品質レイヤ２にも対応するそれらのパケットを含むように再び増大される。このプロセスの完了後、再構成されたコードストリームは全ての位置に対する全ての品質レイヤを含む。

図１１は、混合配列（順序）で分解される、位置によって順序付けされたコードストリームの例、すなわち位置１が最初に来て、その後にレイヤで順序付けされたセグメントが続く例、を示す。この例は、図７に記載されたものと同一の、位置によって順序付けされたコードストリームを使用する。プログレッションの各ステージに対して再構成されたコードストリームは、図１１に示されるように、第一段階で位置１パケットから始まり、そして、残りの位置に対応するパケットを含む、３つの品質レイヤセグメントにより後続される。最終的に再構成されたコードストリームは、最初に入力された、位置によって順序付けされたコードストリームと再び同じになる。

図１２は、プログレッシブ順序がレイヤプログレッシブコードストリーム（ＬＲＣＰ）からレゾルーション（解像度）プログレッシブ（ＲＬＣＰ）に変更された例を示す。この例は２つのセグメントのみを示しており、ここで、セグメント０は解像度（レゾルーション）０だけを含んでおり、また、セグメント１は解像度（レゾルーション）１だけを含んでいる。

ＲＯＩプログレッシブ配列（順序）
図１３Ａ〜図１３Ｉはこの発明による方法の実施の形態で可能なサンプルＲＯＩプログレッションを示す。図１３Ａは、最初にＲＯＩの内部で、次にＲＯＩの外部での品質レイヤプログレッションである。

図１３Ｂは、最初にＲＯＩの内部で、次にＲＯＩの外部でのレゾルーション（解像度）プログレッションである。図１３Ｃは、最初にＲＯＩの内部で、次にＲＯＩの外部での構成要素プログレッションである。図１３Ｄは、最初にＲＯＩの内部で、次に２つの外部位置での位置プログレッションである。図１３Ｅは、最初にＲＯＩの内部で、次に４つの外部位置での位置プログレッションである。図１３Ｆは、最初にＲＯＩの内部で、次にＲＯＩの外部での品質レイヤプログレッションである。図１３Ｇは、最初にＲＯＩの内部で、次にＲＯＩの近くでの品質レイヤプログレッションである。図１３Ｈは、最初にＲＯＩの内部で、次にフレームの中心での品質レイヤプログレッションである。図１３Ｉは、最初に各ＲＯＩの内部で、次にバックグラウンド（背景）での品質レイヤプログレッションである。

この発明は、メモリまたはバンド幅を減少させるために、画像を再配列（再順序付け）することにより、または画像の或る部分を省略することによって、サーバが画像のピクセルを最優先させることを可能にする。これは、画像が大きいときに、重要である。また、以上に述べた方法は、プログレッシブ順序（配列）を決めるために、画像に表されたシーンについて取得された、より高いレベルの知識を考慮することができる。

例示したビデオは、開いているキャッシュレジスタ（金銭登録機）でのシーンを示す。
サーバアプリケーションは、引出しの開いている金銭登録機をカバーする、画像の特定の領域に対して充分な品質と解像度を維持するように決めてもよい。ドアが開いたならば、サーバは、入り口のエリアを含む画像の特定の領域を優先的に取り扱うようにし、また、ドアが閉じられるときには、その領域に低い優先度を割り当てるように決めてもよい。また、異なる画像からの複数のＲＯＩを、サーバにより制御することもできる。新しい顔が画像に検出されるときには、顔検出アプリケーションはＲＯＩに高い優先度を割り当てることができる。他のアプリケーションでは、モーション（運動）情報が画像系列から抜粋される。モーション（動き）優先の順序付けをすることを、画像の全ての領域に亘って、適用することができる。この場合、サーバは、動きまたは他の基準に基づいて画像の各候補ＲＯＩに重み付けを適用することができる。

発明の効果
この発明のプログレッシブ画像伝送のためのサーバ駆動による方法は、低い信号化オーバヘッドを有する。この発明の他の効果は、プログレッシブに受信されたコード化画像の迅速なインクリメンタル（増分的）な復号化およびレンダリングが可能なことである。この発明では、コード化画像のセグメントが伝送される。最初のセグメントはメインヘッダを含んでいる。クライアントにより第１のセグメントを受信した後に、クライアントは、まだ受信されていない、欠けている如何なるパケットに対しても空のパケットを挿入することができる。このような方策により、コードストリームが受信途中であるときでさえ、クライアントは部分的なコードストリームから適合するＪＰＥＧ２０００コードストリームを形成することが可能である。また、これにより、伝送エラーで欠落したり無くなったパケットに対して、クライアントに回復力を持たせることができる。クライアントにおける空のパケットの挿入により、サーバは、伝送サイズを減少させたり、コード化画像データを切り捨てたりするために、コード化画像データの一部分を再配列したり、抑制したり、または捨てることが可能になる。

この発明の追加の効果は、多くの異なる形式のプログレッションを可能にすることである。この発明は、画像データが多くの（様々な）配列（順序）で伝送されるのを許容して、その結果、サーバがほとんど無制限な数のプログレッションを生成することを可能にする一般的な解法について記述している。これらは、簡単なフレーム配列（順序付け）、またはＲＯＩが最初に来る配列、またはより複雑な混合プログレッションを含むことができる。その上、複数のＲＯＩが同じ画像で定義されるとき、サーバは、どのＲＯＩを最初に送るか、また各ＲＯＩにどれくらいのバンド幅を割り当てるか、および画像の残りの部分、をそれぞれ定義して、各ＲＯＩに対して異なる優先順位を選択する柔軟性を有する。

この発明は好適な実施の形態を例に挙げて説明したが、この発明の精神および範囲内で種々の他の改変および変更を行うことができることを理解すべきである。したがって、添付クレームの目的はこの発明の真実の精神および範囲に含まれるような全ての変形例および変更例をカバーすることである。

この発明の実施の形態によるサーバ駆動のプログレッシブ伝送方法およびシステムのブロック図である。 この発明の実施の形態によるコードストリーム分解プロセスのフロー図である。 この発明の実施の形態によるメタデータのブロック図である。 この発明の実施の形態によるコードストリームのフォーマットのブロック図である。 この発明の実施の形態によるプログレッシブコードストリームを再構成するためのプロセスのフロー図である。 この発明の実施の形態によるセグメントリストのブロック図である。 この発明の実施の形態によるコードストリームのブロック図である。 この発明の実施の形態によるコードストリームのブロック図である。 この発明の実施の形態によるコードストリームのブロック図である。 この発明の実施の形態によるコードストリームのブロック図である。 この発明の実施の形態によるコードストリームのブロック図である。 この発明の実施の形態によるコードストリームのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。 この発明の実施の形態による例示プログレッションのブロック図である。

Claims (15)

1. 画像を表すプログレッシブコードストリームを生成するためにサーバにより駆動されるプログレッシブ画像伝送方法であって、
   前記方法は、
   画像を表すパケットのコードストリームを解析して解析パケットと各解析パケットに対するメタデータとを得る工程と、
   前記メタデータと前記プログレッシブトランスミッションポリシーにしたがって前記解析パケットを分解パケットに分解する工程と、
   前記メタデータと前記トランスミッションポリシーにしたがって前記分解パケットを複数の順番に配列されたセグメントに割り当てる工程とを含み、各セグメントはヘッダを含み、また前記コードストリームにおける前記前記パケットの配列は前記複数のセグメントにおける分解パケットの配列と異なる、方法。
2. 前記コードストリームはＪＰＥＧ２０００コードストリームである、請求項１の方法。
3. 前記プログレッシブトランスミッションポリシーは前記サーバのアプリケーションにより決められる、請求項１の方法。
4. 前記プログレッシブトランスミッションポリシーはシステムリソースに依存する、請求項１の方法。
5. 前記メタデータにより前記解析パケットを符号変換する工程をさらに備える、請求項１に記載の方法。
6. 前記符号変換は前記プログレッシブトランスミッションポリシーにしたがって前記解析パケットの再配列を行なう、請求項５の方法。
7. 前記順番に配列された複数のセグメントをクライアントにプログレッシブ伝送する工程をさらに備える、請求項１に記載の方法。
8. 前記クライアントにおける画像をプログレッシブ再構成するために前記セグメントにおけるヘッダにしたがって前記分解パケットを構成する工程をさらに備える、請求項７に記載の方法。
9. 数値的に近接する分解パケットの各ブロックはヘッダを有する、請求項１の方法。
10. 前記パケットは数値的に近接する、請求項１の方法。
11. 各パケットに対するメタデータは、品質レイヤインデックス、解像度レベルインデックス、構成要素インデックス、およびプリーシンクトインデックスを含む、請求項１の方法。
12. 前記ヘッダは、前記セグメントにおける数値的に近接する分解パケットの位置に関連するインデックス付け情報をコード化する、請求項９の方法。
13. 前記ヘッダは、前記セグメントにおける数値的に近接する分解パケットに対するデータサイズ情報をコード化する、請求項９の方法。
14. 画像を表すプログレッシブコードストリームを生成するためにサーバにより駆動されるプログレッシブ画像伝送システムであって、
    前記システムはサーバを備え、
    前記サーバは、
    画像を表すパケットのコードストリームを解析して解析パケットと各解析パケットに対するメタデータとを得るための手段と、
    前記メタデータとプログレッシブトランスミッションポリシーにより前記解析パケットを分解パケットに分解する手段と、
    前記メタデータおよび前記トランスミッションポリシーにしたがって前記分解パケットを複数の順番に配列されたセグメントに割り当てるための手段とを備え、各セグメントはヘッダを含み、また前記コードストリームにおける前記パケットの配列は前記複数のセグメントにおける前記分解パケットの配列と異なる、システム。
15. クライアントにおける画像をプログレッシブ再構成するために、前記セグメントにおけるヘッダにより前記分解パケットを構成する手段からなるクライアントをさらに備える、請求項１４に記載のシステム。

Images