(57)【特許請求の範囲】
【請求項１】
アンカーフレームおよび該アンカーフレームに依存する少なくとも一つの従属フレームを含む複数のビデオフレームを、出力ビデオ信号を完全にデコードすることなく該出力ビデオ信号から抽出することができる独立にコード化された領域を有するよう圧縮する方法であって、
独立にコード化すべき少なくとも２つの領域が指定されることに応じて、前記ビデオフレームを動き補償されるブロックのシーケンスに分け、各ブロックを前記少なくとも２つの領域の一つに関連づけるステップを含み、前記少なくとも２つの領域のそれぞれは、複数のフレームで生じるオブジェクトおよび位置の領域であり、
従属フレームにおける前記少なくとも２つの領域の一つである第１の領域に関連づけられたブロックの動きベクトルが、アンカーフレーム内の対応する第１の領域に関連づけられたブロックのみを指すよう、動き補償を実行するステップと、
次に動き補償されるブロックが前記ブロックのシーケンスにおける直前の動き補償されたブロックとは異なる領域であるとき新たなスライスとして、動き補償されたブロックを重なりのないスライスにコード化するステップと、
前記スライスから前記出力ビデオ信号を生成するステップと、
を含む圧縮方法。
【請求項２】
独立にコード化された領域を持たない圧縮された入力ビデオ信号から少なくとも２つの独立にコード化された領域を持つ出力ビットストリームを生成するステップをさらに含み、前記出力ビットストリームの各スライスが一つの領域だけに関連し、他の領域に関連するイメージデータと重複しない、請求項１に記載の方法。
【請求項３】
前記少なくとも２つの領域の指定は、領域または特定のオブジェクトを選択する入力に応答して、ビデオの他のフレームにおける対応するデータを複数のフレームに生じる一つの領域の一部として同定するステップを含む、請求項１に記載の方法。
【請求項４】
前記同定するステップは、フレームからフレームへの前記オブジェクトの移動にかかわらず、前記複数のフレームにわたって対応するデータを検出してオブジェクトを追跡することを含む、請求項３に記載の方法。
【請求項５】
前記同定するステップは、前記複数のフレームにわたって同様の大きさで同様な配置の空間領域を規定することを含む、請求項３に記載の方法。
【請求項６】
アンカーフレームおよび該アンカーフレームに依存する少なくとも一つの従属フレームを含む複数のビデオフレームを、出力ビデオ信号を完全にデコードすることなく該出力ビデオ信号から抽出することができる独立にコード化された領域を有するよう圧縮する装置であって、
独立にコード化すべき少なくとも２つの領域の指定に応じてビデオフレーム中に該少なくとも２つの領域を定める領域選択手段を備え、前記少なくとも２つの領域のそれぞれは、複数のフレームで生じるオブジェクトおよび位置の領域であり、
前記ビデオフレームを動き補償されるブロックのシーケンスに分け、各ブロックを前記少なくとも２つの領域の一つに関連づけ、従属フレームにおける前記少なくとも２つの領域の一つである第１の領域に関連づけられたブロックの動きベクトルが、アンカーフレーム内の対応する第１の領域に関連づけられたブロックのみを指すよう、動き補償を行う動き補償手段と、
次に動き補償されるブロックが前記シーケンスにおける直前の動き補償されたブロックとは異なる領域であるとき新たなスライスとして、動き補償されたブロックを重なりのないスライスにコード化するコード化手段と、
を備える圧縮装置。
【請求項７】
入力ビデオ信号を空間ドメインにデコードして空間ドメインデータを生成するビデオデコーダを備え、独立にコード化された領域を持たない入力ビデオ信号をデコードして空間ドメインデータを生成し、前記領域選択手段により領域を定めて互いに独立な少なくとも２つの領域を有する出力ビットストリームを生成する、請求項６に記載の圧縮装置。
【発明の詳細な説明】
【０００１】
本発明は、画像シーケンスの圧縮に関する。特に、本開示は、独立してコード化された領域を利用して、必ずしも各フレーム中のすべての画像データを伸張する必要なく、画像オブジェクトの選択的抽出、または画像フレームの選択エリアの編集が可能な圧縮システムを提供する。本開示は、望みであれば、オブジェクトおよび領域を独立してコード化した、かつビデオシーケンスから抽出することができるように、複数のフレームにわたってオブジェクトおよび領域を追跡する機構も提供する。
【０００２】
[背景]
フィルム画像またはビデオ画像の従来の編集または他の処理は、画像の圧縮表現ではなく実際の画像における「空間」ドメインで行われる。このような編集または処理の最終生成物は圧縮されていない信号（典型的な「ＮＴＳＣ」テレビ信号等）であることが多いため、かかる編集または処理は、時に、今日のデジタルエディタおよびコンピュータを使用してリアルタイムで達成することが可能である。しかし、高精細度テレビ（「ＨＤＴＶ」）等高解像度ピクチャへの傾向が高まるに伴い、インターネット、ケーブル、テレビジョンネットワーク、および他のサービスプロバイダはすべて、編集の最終生成物として圧縮された信号の直接提供を開始する必要がありそうである。本明細書において用いる「ビデオ」という語は、デジタル、ＮＴＳＣ、それとも別のフォーマットであるかどうかに関わらず動画シーケンスを表すあらゆる電子信号を指す。
【０００３】
新しいデジタル規格に関連する１つの問題は、ビデオの効率的かつ高速での処理に関し、新規格下の圧縮フォーマットで格納または伝送されるビデオを使用する場合、ビデオを伸張し、そのビデオを空間ドメインにおいて処理し、次に出力ビデオを再圧縮することは計算に関して困難である。表示に先立つ圧縮ビデオ処理の例としては、高速先送り、巻き戻し、およびＶＣＲに通常関連する他の機能の提供が挙げられる。ビデオの生成または放送に関連する他の処理の例としては、色の補正、ロゴの挿入、ブルーバック処理（blue matting）、および他の従来のプロセスが挙げられる。
【０００４】
この計算の困難さの一例をとると、ロゴの挿入において地方テレビ局は、圧縮された衛星フィードを受信し、視聴者のＴＶセットで見られる画像の一角にそれぞれのテレビ局のロゴを挿入してから、ケーブルを介して、再び衛星を介して、または放送電波を通してＴＶ信号を放送する場合がある。従来、この処理は、画像の伸張、その画像の空間ドメインでの変更、および空間ドメイン信号（たとえば、圧縮されていないＮＴＳＣ信号）の送信が比較的容易であったため、リアルタイムで、または短い遅延をもって行うことができた。すべての伝送を圧縮フォーマットで行う必要のあるＨＤＴＶおよび他の新しいデジタル規格の場合、ビデオ信号の圧縮は計算に関して非常に高価であるため、この高速処理ははるかに難しくなる。
【０００５】
本開示中、上に挙げたビデオの例、たとえばロゴの挿入、色の補正、高速先送り、巻き戻し、ブルーバック処理、および同様の種類の編集および処理手順はすべて、集合的かつ交換可能に「編集」または「処理」と呼ばれる。「高速先送り」および一般にビデオカセットレコーダ（「ＶＣＲ」）に関連する同様の機能は、フレームの順序または表示速度を変更し（これにより、元のビデオ信号を変更する）、これら変更を含む新しい、圧縮された出力信号を出力することが望ましい場合があるため、このように呼ばれる。圧縮された出力信号では、フレームを順序替えし異なるフォーマットで再度符号化する必要があることが多い（たとえば、異なるフレームに依存するように）ため、１つの種類の「編集」とみなされる。
【０００６】
上記例の殆どでは、編集または処理は通常、全体的に空間ドメインにおいて行われるため、通常、ビデオ信号を全体的に空間ドメインに伸張してから、再度圧縮しなければならない。これら動作は通常、画像フレーム（またはフレームグループ）のわずかな部分しか編集されない場合であっても必要である。たとえば、ロゴを画像フレームの右下角に挿入する場合を考えると、圧縮されたビットストリームのどの部分がフレームの右下角を表すかを判定することは極めて困難であるため、通常、ビデオシーケンスの各フレーム全体が伸張され編集される。圧縮された出力信号を形成したい場合には、通常、編集された信号のフレームを再び圧縮しなければならない。
【０００７】
この点に関し、多くの圧縮フォーマットは、「動き推定」および「動き補償」に基づいている。これら圧縮フォーマットでは、「現」フレーム中のブロックまたはオブジェクトが、１つまたは２つの「アンカー」フレーム中の同様のブロックまたはオブジェクトから再現される。「動き推定」とは、コンピュータが、現フレームの各ブロックまたはオブジェクトごとに、各アンカーフレームの適当に大きなエリア内の同様の画像パターンを探索し、このエリア内で最も近いマッチングを決定する符号化プロセスの部分を指す。このプロセスの結果が、通常、アンカーフレームにおける最も近いマッチングの相対的な位置を記述する動きベクトルである。「動き補償」は、各ブロックまたはオブジェクト間の差分およびそれと最も近いマッチングがとられ、次に、これら差分（マッチングが「良好」の場合、理想的にはすべてゼロ）が、あるコンパクトな様式で、しばしば離散コサイン変換（「ＤＣＴ」）を使用して符号化される、符号化プロセスの別の部分を指す。これらプロセスは単に、アンカーフレームの同様に見える部分のロケーションならびに差分値を使用して、現フレームの各部分を殆ど正確に再構築することができることを暗に示すにすぎない。シーケンス中のあらゆるフレームがこのようにして圧縮されるわけではない。
【０００８】
動き推定は、計算に関して非常にコスト大である。たとえば、ＭＰＥＧ−２規格を適用する際、システムは通常８×８ピクセルの各ブロックを採用し、最も近いマッチングが予想されるロケーションを中心とする１５×１５ピクセル探索窓内で最も近いマッチングを探索する。このような探索は、最も近いマッチングを見つけるために６４の比較を含み、そして各比較では、６４の個別のマルチビット輝度値の減算が必要である。典型的な画像フレームが何千もの８×８ピクセルブロックを有することができ、この探索が通常、ビデオシーケンス中の大部分のフレームについて行われることを考えると、動き推定が計算に関してコスト大なタスクであることはかなり明白になる。
【０００９】
デジタルビデオおよびよりコンパクトな圧縮伝送フォーマットへの移行が予想されるに伴い、高速圧縮システム、および高速編集性能を提供するシステムに対する明確な必要性が存在することは明らかである。理想的には、かかるシステムは、圧縮された信号の復号化および編集（たとえば、ＶＣＲ機能、ロゴ挿入等）が可能であり、さらに、ＨＤＴＶおよび他の新しいデジタルシステムが許容可能な圧縮された編集済ビデオ信号をリアルタイムで構築し出力することが可能であるべきである。理想的には、かかるシステムは、既存のオブジェクトベースおよびブロックベースの規格および望ましい編集手順に適合して、たとえば、特に、圧縮された信号に挿入されるロゴ、ならびに他の形態の編集および処理を取り扱うことができるように動作する。さらにまた、かかるシステムは、理想的には、既存のコンピュータおよびビデオを処理する他のマシンに適合するように、可能な限りソフトウェアに実装されるべきである。本発明は、これら必要性を満たし、さらに、関連する利点を提供する。
【００１０】
[概要]
本発明は、独立してコード化された領域を有するシステムを提供することにより、上記必要性を解決する。これら領域を使用して、シーケンス全体を復号化し伸張する必要なく、選択オブジェクトの抽出または編集を空間ドメインで行うことができるように、データシーケンスを特に圧縮し符号化することができる。オブジェクトについて（たとえば、編集されたオブジェクトについて）変更されたデータを包含するように、圧縮された出力信号を変更することが望ましい場合、新しいデータを抽出されたオブジェクトの場所に適宜挿入することができ、オブジェクトが独立してコード化され、シーケンスの他の圧縮されたデータのすべて（たとえば、背景または他の特定オブジェクト）を正確に再使用することができる。リアルタイムでの適用では、この能力により、標準的なコンピュータおよび編集機器を使用して、圧縮された出力信号の編集および生成が促進される。したがって、わかるように、本発明は、制作、ポストプロダクション、ネットワークシンジケーション（syndication）、インターネット、および圧縮ビデオ、オーディオおよび他の信号の生成が必要な他の用途にすぐに使えるアプリケーションを有する。
【００１１】
本発明は、複数の圧縮データフレームを表す信号を生成する装置を提供する。本装置は、関連するデータフレームシーケンスとしての格納または伝送に適したオーディオ、ビデオ、または任意の他のタイプのデータに適用することができる。好ましい実施形態では、本発明の本形態は、圧縮ビデオフレームに適用されて、出力ビデオシーケンスの一部として独立してコード化される領域を生成する。好ましい実施形態は、ネットワークまたはビデオ制作ハウスにより、高速またはリアルタイムでの編集に最適化されるように、画像シーケンス（たとえば、衛星伝送、ＤＶＤ番組、ビデオテープ、または他のプログラム）を圧縮フォーマットで生成するために適用することができる。数例を挙げれば、圧縮画像シーケンスがすでに、独立コード化領域を有するように処理されている場合、画像シーケンス全体を完全に伸張し処理することなく、すなわち、１つまたは少数の独立コード化領域のみを処理するだけで、地方テレビ局はロゴを挿入し、ポストプロダクションハウスは色修正を提供することができる。あるいは、好ましい実施形態はまた、デジタルＶＣＲにおいても、また地方テレビ局により実施することも可能であり、ビデオシーケンス全体を完全に再符号化する必要なく、軽微な編集または処理（たとえば、信号混合、高速先送りのための順序替え、ロゴ挿入等）を実行することにより、これらエンティティは、デジタル（ＨＤＴＶ）出力信号をリアルタイムで、またはほぼリアルタイムでより容易に生成することができる。
【００１２】
本発明の第１の形態によれば、圧縮システムは、各従属フレームを１つまたは２つのアンカーフレームから再現することができるように、少なくとも１つのデータフレームをアンカーフレームとして、また少なくとも他の１つのデータフレームを独立したフォーマットで符号化する。本発明の本形態は、互いに独立して圧縮すべき少なくとも２つのデータセット（複数の画像フレームにわたって現れる）を識別する必要があり、また従属フレーム中の各データセットの動きベクトルが１つまたは２つのアンカーフレーム中の同じデータセットのみを指すように、動き探索および補償を制限する必要がある。「データセット」は、複数のフレームに現れるオブジェクト（オブジェクトの形状、サイズ、色、輝度等は変化しうる）、ならびに静止形状および位置（たとえば、画像コンテンツに関係なく、各画面の右下角）を指すことができる。
【００１３】
本発明の第２の形態では、一方は従属フレームとして圧縮され、他方はアンカーフレームとして圧縮される少なくとも２つのフレームがある。通常、従属フレームは、まずアンカーフレームを伸張して空間ドメインデータを生成し、次に、従属フレームに関連する動きベクトルおよび残余をとり、すでに伸張されたアンカーフレームの「部分」を使用して従属フレームのコンテンツを「構築」することにより、再現される。本発明の本形態は、従属フレーム中の空間ドメインデータを指定する能力をユーザに提供し、自動的にその他からのデータを、そのデータを有するアンカーフレーム関連づけ、従属フレームのすべての動きベクトルの依存性がアンカーフレームの関連データのみを指すよう制限された状態で、従属フレームが動きベクトルおよび残余のフォーマットで圧縮されるように出力シーケンスを圧縮することにより、圧縮出力信号を生成する必要がある。
【００１４】
本発明の他の形態は、各種方法、装置、および実施を含め、併記の特許請求の範囲に記載される。より特定の側面では、本発明のこれら形態は、ビデオまたはオーディオエンコーダ、トランスコーダ、および編集装置として実施することができる。
【００１５】
本発明は、添付図面と併せて読むべきである以下の詳細な説明を参照することにより、より良好に理解することができる。本発明の特定の一実施を構築し使用することができるように以下に記載する特定の好ましい実施形態の詳細な説明は列挙された特許請求の範囲を制限する意図はなく、それらの特定の例としての役割を果たすものである。
【００１６】
[詳細な説明]
上記に要約され併記の特許請求の範囲により定義される本発明は、添付図面と併せて読むべき以下の詳細な説明を参照することにより、より良好に理解することができる。本発明の特定の一実施を構築し使用することができるように以下に記載する特定の好ましい実施形態の詳細な説明は、併記の特許請求の範囲を制限する意図はなく、特定の例としての役割を果たすことを意図するものである。以下に記載する特定の例は、独立してコード化された領域を実施し、促進し、採用するいくつかのコンポーネントの好ましい実施である。しかし、本発明は、他の種類のシステムにも同様に適用することができる。
【００１７】
Ｉ．総論
本開示は、エンコーダ、デコーダ、およびいくつかの信号フォーマットについて記載する。これら各アイテムは、以下の説明から明白になる広範な用途を有する。
【００１８】
エンコーダは、離散フレームを有するデータシーケンスをとり、フレームの「領域」を独立して抽出し伸張することができるように格納または伝送するように、これらフレームを圧縮する。フレームは、これら領域に細分されてから、シーケンス中のあらゆるフレーム全体に必要な復号化をして復号化可能なように、特定の規則を使用して符号化される。エンコーダは、独立してコード化された領域（「ＩＣＲ」）を有するように「空間ドメイン信号」（すなわち、従来のアナログまたは表示可能入力信号）を新しく圧縮するために使用することができ、システムにおいて、圧縮された入力を受信し、ある様式でこの入力を変更し、次にエンコーダを適用して、望みに応じてＩＣＲを有する圧縮された出力信号を提供する「トランスコーダ」の形態でも適用することが可能である。このエンコーダの使用により、ＴＶネットワーク、ＴＶ局、ＴＶ放送業者、ポストプロダクションハウス、および他のエンティティにとって、圧縮信号の編集または処理、かつリアルタイムで、または略リアルタイムでの圧縮出力の提供が比較的容易になることが望ましい。たとえば、上述したようにエンコーダまたはトランスコーダを衛星信号配信に使用すると、ダウンストリームＴＶ局にとって、それぞれのロゴを挿入し、１つの関心のあるＩＣＲの挿入のみを編集し、編集された部分のみを再符号化することを通して、変更された信号を迅速に伝送することを比較的容易にすることができる。受信した信号がすでにこれらＩＣＲを有するように生成されている場合、エンコーダまたはトランスコーダは、地方ＴＶ局による高速編集を促進するためにも使用することができる。
【００１９】
これら各種要素の使用により、信号を処理し、リアルタイムで、または略リアルタイムで圧縮された出力信号を提供することのできるハードウェアおよびソフトウェアでのデジタルシステムの構築が比較的容易になることが望ましい。以下に述べる実施形態は、オーディオ信号またはフレームタイプのフォーマットでの伝送に適した他の情報に適用可能であるが、好ましい適用は、ビデオ、特にＨＤＴＶおよび圧縮フォーマットでの伝送または格納が必要なデジタル規格に対してである。以下に述べる好ましいシステムは、「ＭＰＥＧ−２」圧縮規格（「Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅｓ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ」）により提案された２番目の規格を示す）を使用して動作するが、本システムは、ＭＰＥＧ−１、ＭＰＥＧ−４、Ｈ．２６１、Ｈ．２６３、および他のタイプのフォーマットを含む任意の圧縮フォーマットに適用することが可能である。従来のシステムは、アナログテレビ信号で動作する（たとえば、デジタルビデオディスク（「ＤＶＤ」）プレーヤは通常アナログテレビ信号出力を提供する）が、特にインターネット放送およびＨＤＴＶの広がりに伴い、より多くのシステムが圧縮された入力を必然的に受け入れることになるものと予想され、本発明の１つの主要な適用は、処理または編集された圧縮出力信号をリアルタイムで提供するビデオ処理システム（ＶＣＲおよびディスクプレーヤ等）の促進に対してである。本発明の別の主な適用は、衛星伝送、ケーブルルーティング、インターネット放送、ネットワークまたはＴＶ局編集に使用されるビデオ放送システム、および圧縮されたビデオ信号が望ましい出力である同様のタイプのシステムに対してである。
【００２０】
したがって、ホームエンターテイメントシステム（テレビ、ＶＣＲ、ディスクプレーヤ、ビデオ信号用のホームルータまたはサーバ等）と、ビデオ録画（ネットワークによるもの、ライブスポーツイベント等など）と、ビデオ処理および編集（ネットワーク、ポストプロダクションハウス、スタジオ、ＴＶ局、インターネット放送、番組配信元等によるものなど）と、ＴＶ局およびケーブル等地方配信元によるものなどと、衛星サービスプロバイダと、を含め、以下に述べる要素および技術を適用可能な広範なシステムがあることは明白であるはずである。
【００２１】
本開示で使用する場合、次に識別する語は以下の意味を有する。
【００２２】
データの「フレーム」は、オーディオ、オーディオビジュアルデータ、および通常複数の離散フレームで伝送される他の任意のタイプのデータに適用されるものと解釈される。
【００２３】
「ソフトウェア」は、システムが提供する機能を電子的に制御する、格納されるあらゆる命令を含み、特に、ファームウェアならびにソフトウェアを含む。
【００２４】
「ビデオ」は、画像フレームシーケンスとして電子的に伝送され格納される画像データを含み、特に、フレームレート、色変調方式、および個々の規格を区別する他の特徴に関係なくすべてのテレビフォーマットを含む。たとえば、「ビデオ」は、どこで開発されるかに関係なく、ビデオ会議、コンピュータモニタ伝送、およびテレビフォーマットに使用されるフォーマットを含む。「ビデオ」は特に、デジタルフォーマット（たとえば、「ＤＶＤ」および「ＨＤＴＶ」）、異なる圧縮フォーマット（たとえば、「ＭＰＥＧ」方式、「Ｈ．２６１」および「Ｈ．２６３」）、および異なる従来のアナログテレビフォーマット（たとえば、「ＮＴＳＣ」、「ＰＡＬ」、および「ＳＥＣＡＭ」）を含む。
【００２５】
「アンカー」フレームは、別のフレームが再構築のために直接依存するあらゆるフレームを含み、独立フレームあるいは従属フレームのいずれかであることができる。非限定的な例として、従来の「ＭＰＥＧ」フォーマットでは、従属フレームは、独立した「Ｉ」フレームならびに予測「Ｐ」フレーム（それ自体、再構築について他のフレームに依存する）から再現することができ、これら「Ｉ」および「Ｐ」フレームは双方とも、再構築のために別のフレームにより使用される場合、アンカーフレームである。
【００２６】
「独立」フレームは、再構築について別のフレームに依存しないあらゆるフレームを含み、たとえば、独立フレームは、他の任意のフレームを伸張することなく画像コンテンツを完全に得ることができるように圧縮される。従来の「ＭＰＥＧ」フォーマットでは、「Ｉ」フレームのみが独立している。
【００２７】
「従属」フレームは、再構築について別のフレームに依存するあらゆるフレームを含む。従来の「ＭＰＥＧ」フォーマットでは、従属フレームは、「Ｐ」フレーム（それ自体、先に復号化される「Ｉ」あるいは「Ｐ」フレームのいずれかに依存する）ならびに「Ｂ」フレーム（それ自体、先に復号化される１つまたは２つの「Ｉ」または「Ｐ」フレームに依存する）を含むことができる。「Ｂ」フレームは２つのアンカーフレーム（このうちの一方はビデオシーケンスの後にあってもよい）に依存することができるため、このフレームは通常、順不同で格納または伝送される。たとえば、３つの連続フレームを「Ｉ」、「Ｂ」、および「Ｐ」フレームとしてそれぞれ符号化する場合、これらフレームは「ＩＰＢ」の順序で格納または伝送され、この順序で復号化されてから、表示のために順序替えされる。
【００２８】
「現」フレームは、現在処理中のあらゆるフレームを含む。たとえば、従属フレームを符号化中の場合、従属フレームが「現」フレームであり、対応する「アンカー」フレームはどれでも、現フレームの圧縮および再構築の直接参照として使用される１つまたは２つのフレームである。
【００２９】
「コード化」または「符号化」は、交換可能に使用され、画像フレームの圧縮フォーマットへの圧縮を指す。圧縮フォーマットは、各種「ＭＰＥＧ」規格によって定義される従来の「ＩＰＢ」フォーマット、圧縮されたビットストリーム（たとえば、次に量子化され、ハフマン符号化されるなどして、単純に数の羅列になる「Ｉ」、「Ｐ」、または「Ｂ」フレーム）または別のフォーマットであることができる。
【００３０】
「独立してコード化された領域」または「ＩＣＲ」は、ビデオシーケンスの一部のみを互いに依存して符号化できるように、限定的にコード化される画像データを含む。例として、「現」画像フレームを「Ｐ」フレーム（別の「Ｉ」フレームに依存する）として符号化し、背景画像から独立して俳優のセットを符号化したい場合、「独立してコード化された領域」が、俳優のセットおよび背景のそれぞれについて個別に作成される。すなわち、「Ｐ」フレームおよび「Ｉ」フレームそれぞれを２つの領域に分割し、他方の領域（背景または俳優、たとえば、この後者のデータは圧縮フォーマットのままで）を復号化する必要なく、各領域（たとえば、俳優のセットまたは背景）をビデオシーケンスから抽出し再現することができる。領域を編集して、たとえば、特定の俳優のシャツの色を変更したい場合、この「色補正」は、背景領域を復号化する必要なく達成することができ、色補正された信号を次に、ビットストリームフォーマットに再符号化し、俳優のセットについて元のビットストリームデータの代わりに挿入する。［この例では、背景データを変更する必要はないが、バッファサイズ等、画像フレームについてのいくつかのフロントエンドパラメータを変更する必要がある場合もある。］
「データグループ」または「領域グループ」は、いくつかのフレームにわたって共にグループ化すべき任意のデータセットを指し、データグループの個々のピクセル値は、フレーム毎に変化し得る。たとえば、動いているシーンの１つの背景画像として現れる山を独立してコード化することが望ましく、各フレームが山のわずかに異なる側面を表す場合、山は１つのデータグループであることができ、その相対的なサイズおよび色は、フレーム毎に変化し得るが、各フレーム中、そのデータは「領域」として共にグループ化され、各領域は、フレームシーケンスにわたって、他の圧縮データとは関係なく、山全体を選択して抽出し、復号化することができるように、各フレームにおいて個別に符号化される。
【００３１】
定義されるこれらおよび他の語は、以下にさらに説明、適用される。
【００３２】
ＩＩ．原理的な部分
図１〜図９は、エンコーダおよびトランスコーダの動作説明を助けるために使用される。エンコーダは、新しくビデオ信号を符号化するため、および圧縮された信号をＩＣＲフォーマットに変換するか、あるいは編集されたシーケンスを圧縮フォーマット中に再度組み入れるトランスコーダの一部として、双方に使用される。
【００３３】
理想的には、これらの（エンコーダまたはトランスコーダ）処理のいずれかの結果は、表示、またはさらに編集に使用することのできるＩＣＲ信号である。図１０〜図２４を参照して、この信号に好ましいいくつかのフォーマットを以下に述べる。１つのフォーマットは、出力信号内に直接埋め込まれた領域情報を含む。たとえば、番組撮影の際、電子「ブルーバック処理」を介して俳優またはオブジェクトを後に特定のシーン（たとえば、ジャングルのシーン）と組み合わせることができるように、俳優または他のオブジェクトを青い背景で撮影したいことがある。この例では、前景（俳優またはオブジェクト）を１つまたは複数のＩＣＲとしておよび背景を別のＩＣＲとして個別に符号化して、「ブルーバック処理」手順に必要な処理を最小に抑えることが望ましいことがある。本例での前景である俳優またはオブジェクトの位置は各フレームごとに移動し得るため、圧縮されたシーンのヘッダ情報において、そのフレームのビットストリームデータから各ＩＣＲを正確に見つけられるところを直接指定する必要があることがあり、各オブジェクトを各フレームのビットストリームデータから抽出することができるように「領域マップ」を提供する、いくつかのフォーマットについて以下に述べる。いくらか別様に述べると、この第１の「領域マップ」フォーマットは、出力信号を検査することができるように、ビットストリームヘッダ情報において各ＩＣＲを識別し、信号からＩＣＲ位置を導出し、この情報を使用して各フレームから各ＩＣＲを抽出することを含む。第２のフォーマットは、この埋め込まれた「領域マップ」情報を使用せず、代わりに、デフォルトすなわち一定の領域情報に頼る。たとえば、単純に、「ＧＯＰ」または画像シーケンスのすべてのフレームについて一定である静的データグループ（たとえば、各フレームの右下角等、静止オブジェクトまたは固定領域）を有することが望ましい場合もある。本例では、領域ロケーションについての情報は、ビデオディスクまたはテープのラベルに示されるユーザマニュアルで、またはある他の機構を介して提供することができ、各フレームについての特定のマップは必要ない。
【００３４】
最後に、残りの図は、ＩＣＲを有する信号およびデコーダのいくつかの使用を例示するためにそれぞれ使用される。たとえば、ＩＣＲ信号の１つの使用は、特定のデータグループのみを抽出し変更することにより、効率的かつ高速の編集を可能にすることである。ＩＣＲおよび指定された信号フォーマットを利用する技術およびシステムについては、図２５〜図２９を参照して最後に述べる。これらの図はまた、このように効率的かつ高速の編集に採用することのできる空間ドメインデータを生成するために使用可能なデコーダの動作も示す。
【００３５】
この説明を念頭に置き、次に、好ましいエンコーダおよびトランスコーダの構造および使用についてさらに述べる。
【００３６】
ＩＩＩ．好ましいエンコーダおよびトランスコーダの動作
Ａ．概観
図１は、本発明の原理を実施する基本的なエンコーダまたはトランスコーダの動作を示す。好ましくは、１つの画像処理システムは、双方の機能を達成し、（ａ）「生の」すなわち圧縮されていないビデオ１０３、（ｂ）処理されてＩＣＲフォーマットに変換される、ＩＣＲのないすでに圧縮されたビデオ１０５、または（ｃ）ある様式で編集または処理されるＩＣＲを有する、すでに圧縮されたビデオ１０７のいずれも受け入れる。ブロック１０９および１１１に示すように、圧縮されたビデオは、ＩＣＲが存在しない場合には全体をビットストリーム復号化しなければならず、ＩＣＲが存在する場合、選択的に編集すべきＩＣＲを復号化しなければならない。エンコーダまたはトランスコーダの１つの目的は、圧縮された出力信号を提供することであり、後述する手順の多くは、このような圧縮出力信号を導出するにあたり近道をとる（たとえば、処理速度を向上させる）ために利用されることに留意されたい。
【００３７】
符号化またはコード変換プロセスは通常、符号化プロセスを監督するユーザにいくつかの表示を提示することを含む。本開示の本項に適用される「ユーザ」は、エンコーダまたはトランスコーダを操作して、独立してコード化される領域の選択または再定義をする人を指す。通常、少なくとも１つの静的フレームが表示され、これにより、ユーザが、独立してコード化されるデータのグループを選択することができ、ユーザは、画像エリアにわたってカーソルを「ドロップアンドドラッグ」して、画面上の任意の領域を選択することができる。この領域は、選択されたすべてのフレームについて静的にしても、また複数のフレームを通してオブジェクトの移動を自動的に追跡し、また周知の追跡および画像検出ルーチンを使用してこれらのフレームを通して適した対応領域を選択するように動作する画像処理ソフトウェアを使用して、オブジェクトを最初に識別するために使用することもできる。これらルーチンの主な目的は、ユーザが指定したフレーム範囲に基づいて、オブジェクト境界の事前選択を提供することである。既存のビデオがすでにＩＣＲを有する場合、表示機能が、既存の各ＩＣＲをハイライトさせ、ユーザが既存の境界を変更する、またはＩＣＲを追加もしくは削除できるようにする。
【００３８】
重要なことに、視覚的にユーザに表示される各フレームは通常、復号化されなければならないが、図１に暗示されるように、シーケンスまたはプログラム中のすべてのフレームを表示または復号化する必要はない。たとえば、ユーザが各画像フレームの右下角（たとえば、すべてのフレームについて４×２マクロブロックエリア）を選択すると、符号化ソフトウェアが、ユーザに表示するために、そのフレーム範囲全体を復号化する必要なしに、関心のあるフレーム範囲全体を自動的に符号化することができる。
【００３９】
機能ブロック１１３は、表示を含む、領域選択に関連する各種機能を表し、これら機能についてはさらに後述する。
【００４０】
ユーザにより領域が選択され、関心のある所望のフレーム範囲にわたって定義されると、マスタ機能ブロック１１５に示すように、画像処理システムが、選択された範囲のビデオを符号化（またはコード変換）する。このプロセス中、先行圧縮データは、変更されなかったデータに利用可能であり、ブロック１１７に示すように、好ましくは、そのデータを再使用して、変更されない領域について新しい圧縮データを計算する際にデータを再使用しない場合には必要な時間を節約することができる。画像処理ソフトウェアが、どの画像フレームが変更されたか、およびどのように変更が行われたかを正確に追跡することができる１つのシステムに関して、詳細を後述する。好ましい符号化プロセスおよびフォーマットの一貫として、各ＩＣＲをどのように「スライス」すべきかを示すピクチャグループ（「ＧＯＰ」）の各フレームごとに、領域マップを作成することができる。次に、これら領域マップに従ってＧＯＰを圧縮し、理想的には、このプロセスの結果は、独立してコード化された領域を有するビットストリームである。これら動作は、ブロック１１９、１２１、および１２３にそれぞれ示される。そうして、ビットストリームは、格納または伝送に適したものとなり、かつオプションのプロセスブロック１２５に示すように、関心のある各フレーム全体を完全に復号化せず、ビットストリームの一部を任意選択的に編集することに本質的に適している。
【００４１】
図１の機能ブロック１１７に示すように、先行圧縮データが利用可能な場合、相当な時間的利点が信号圧縮において提供される。この趣旨で、編集された、あるいはそれ自体は編集されていないがアンカー領域に依存するデータの場合（アンカーフレームに依存するか、あるいはアンカー領域の実質的なコンテンツが編集された場合）、ブロック１２７、１２９、および１３１に示すように、かかるデータは、空間ドメインデータから新たに符号化されてから、再使用される先行圧縮データと組み合わせられる。ある依存画像フレームは、別の画像フレームに依存し、この別の画像フレームはまた別の画像フレームに依存する等々であり得るため、先行圧縮データを再使用することが可能かどうかは、追跡の問題である。好ましい実施形態におけるＩＣＲは、単独で互いに依存しなければならない、すなわち、あるフレーム中の動きベクトルは、アンカーフレーム中の同じオブジェクトしかポイントすることができないため、ＩＣＲ外の変更はいずれも、いずれの従属フレームにも影響を及ぼさない。しかし、フレームの順序替えを提供する、またはアンカーフレームのデータコンテンツを変更するあらゆる編集もまたおそらく、そのアンカーフレームに由来するすべての従属フレームに影響を及ぼす。したがって、追跡ソフトウェアは、好ましくは、現フレームの実際のコンテンツに対して行われた変更だけではなく、アンカーフレームの対応する領域に対して行われたあらゆる変更も追跡する。追跡ソフトウェアは、好ましくは、この追跡プロセス中に、圧縮入力ビデオ（もしあれば）を、出力信号の一部として直接再使用することができるかどうかを判定するために容易に使用可能なテーブルを作成する。再度述べるが、これら機能を包含する好ましい追跡ソフトウェアについてはさらに後述し、この追跡ソフトウェアの情報は、１９９９年１月２１日付けで、発明者Susie J. WeeおよびMarc P. Schuylerを代表して出願された「Image Compression Featuring Selective Re-Use of Prior Compression Data」という米国特許出願第０９／２３５，１０１号から収集することもでき、この出願を参照により本明細書に援用する。
【００４２】
図２は、エンコーダまたはトランスコーダ１０１の実装に使用される様々な物理的コンポーネントを示す。通常、システムは、関連するモニタ１３５と、コンピュータの動作を制御するソフトウェア１３７とを有する画像処理コンピュータ１３３をベースとする。コンピュータ１３３は、従来のコンピュータワークステーションであっても、またネットワーク、ポストプロダクションハウスおよび他によって使用される専用デジタル編集マシンであってもよい。通常、従来のワークステーションは、ＭＰＥＧデコーダと、ワークステーションのＣＰＵに付随して動作する各種フレームバッファおよびデジタル信号処理チップを含む、ビデオ処理を促進する他の機器（図２に示さず）と、を有するように改良される。フレームバッファはまた、従来のコンピュータメモリに実装されてもよいが、従来のワークステーションの場合、通常、復号化およびフレームメモリ管理機能でＣＰＵに負担をかけないことが望ましい。
【００４３】
コンピュータ１３３は、テープソース（ビデオ、テレシネ、または他の画像ソース）１３９等従来のビデオソース、ＤＶＤプレーヤ１４１等のディスクプレーヤ、あるいは衛星、ケーブル、または他の供給源１４３からビデオ入力を受信する。時に、前景画像（たとえば、ＴＶ局のロゴ）または背景画像等、別の画像をこのビデオ入力に組み合わせることが望ましい場合があり、かかるオプション的な第２の供給は、参照符号１４５で表される。［同様に第３および第４の供給があってもよく、たとえば、複数のコマーシャルをスポーツイベントのライブ供給中にスプライシング（ｓｐｌｉｃｅ）し、独立したさらなる供給源を介して各コマーシャルを供給し得ることが望ましいことがある。これらオプション的な供給は図２に示されず、参照符号１４５は、入力ビデオ１３９、１４１、または１４３と組み合わせる、または結合すべき任意のさらなる供給を表すことを理解されたい。]好ましい符号化／トランスコード化デバイスによって実行される処理の結果、出力信号が生成され、ビットストリームフォーマットに圧縮され、参照符号１４７および１４９に示すように、格納される（たとえば、テープ、コンピュータメモリ、またはディスクに）か、あるいはライブで伝送される（衛星により、またはインターネットを介して）。最後に、コンピュータ１３３は、マウス、キーボード、デジタル入力パッド、または他の機器を含むことができる従来のユーザインタフェース機器１５１からユーザコマンドを受信する。
【００４４】
図３もまた、好ましい符号化プロセスの流れを提供する。図３において、変数「Ｉ」は「画像」を指し、オペランド[ｎ]は、好ましいシステムが異なるフレームのデジタルサンプルに対して動作中であることを示し、ｎは、現フレームのデータを表し、ｎ−１は、直前のフレームのデータを表し、ｎ−２は、２つ前のフレームからのデータを表す。この場合、フレームｎ−１は、フレームｎのアンカーフレームであるものと想定され、フレームｎ−２は、アンカーフレームのアンカーフレームとなるものと想定される。変数Ｉ’は、量子化誤差を含む、再構築された（すなわち、復号化された）画像データを示す。
【００４５】
図３に示すように、符号化システムは、符号化すべきデジタル化ビデオ１６１を、領域選択情報１６３と一緒に受信する。デジタル化ビデオは、フレーム単位でバッファに格納され（好ましくは、いくつかのフレームを一度に保持する循環フレームバッファを使用して）、図３の参照符号１６９に示すように、動き補償および独立領域動き推定システム１６５および１６７により、データ推定のブロック（すなわち、「最も近いマッチング」）を計算する。この最も近いマッチングデータは、入力１８１および１８３により（これら入力は、ちょうどデコーダに見られるように、アンカーフレームの圧縮による量子化誤差を組み込む）供給される、伸張された画像データから提供される。最も近いマッチング情報は、第１の加算点１７１に渡され、第１の加算点１７１が、残差、たとえば、考慮中のデータブロックからアンカーフレームの「最も近いマッチング」を差し引くことによって得られる差分値のブロックを計算する。ここから、離散コサイン変換が残差に適用され、次に残差は量子化され（機能ブロック１７３に集合的に示すように）て、データブロックの左上角に集まった非ゼロエントリを有するデータブロックをもたらす。次に、この情報が独立領域（「ＩＲ」）コーダ１７５に渡され、独立領域コーダ１７５が、動き推定推定システム１６５からの動きベクトルを、量子化されたデータと一緒に符号化する。動きベクトルは、動き補償システムにより、適宜アンカーフレーム中の関連データのみをポイントするようにすでに制限されており、ＩＲコーダ１７５には、各領域が離散したスライスからなるように、スライスコードの適切な挿入のために領域選択情報１６３が供給される。ＩＲコーダは、ランレングス符号化およびハフマン符号化を量子化されたデータに適用し、適切なＭＰＥＧヘッダコード（さらに後述するように、スライスコードを含む）を挿入して、出力ビットストリーム１７７を生成する。
【００４６】
重要なことに、すべての画像フレームが動きベクトルを使用して圧縮されるわけではなく、ＭＰＥＧ−２プロセスを使用する場合、「Ｉ」フレーム内のすべてのデータは、動き推定および補償を使用することなく符号化され、「Ｐ」および「Ｂ」フレーム内の選択データブロックもまた、このようにして符号化することができる。すなわち、「Ｐ」フレームは、ヌル動きベクトルを有し、「Ｐ」フレームという指示に関わらず「Ｉ」フレームとして局所的または全体的にコード化することができ、「Ｂ」フレームは、一方向（前方または後方）だけのデータ依存性を有するか、またはいずれの依存性もなく、符号化することができる。制御ルーチン１７９は、ＭＰＥＧコード化のために開発された周知の手順およびアルゴリズムに従ってこの符号化を決定する。制御ルーチン１７９はまた、探索手順において動き推定を制限する。すなわち、従来の動き探索は、アンカーフレーム内の「最も近いマッチング」ロケーションに焦点を合わせ、そのロケーションに関して探索窓を定義するが、制御ルーチン１７９は、アンカーフレーム中の同じオブジェクトまたは領域に対応する「最も近いマッチング」ロケーションのみを許容し、探索窓もこのオブジェクトまたは領域内にあるように制限する。この点に関し、領域選択情報は、符号化システムが、（もしあれば）対応する領域がアンカーフレーム内のどこにあるかを「知る」ように、関心のあるシーケンス全体について予め計算されることが好ましく、ＩＣＲは、異なるフレームからの対応する領域を容易に関連付けることができる（たとえば、同じ名称を有する）ように、一意のネーミング属性で記述されることが好ましい。対応する領域がアンカーフレーム中にない場合、またはアンカーフレーム中の最も近い対応領域ロケーションの位置が、考慮中のデータブロックに相対してかなり異なる場合、制御ルーチン１７９は、関心のあるデータを独立してコード化する（すなわち、独立して「Ｐ」フレームのみを符号化する、または単一方向性の態様で「Ｂ」フレームを符号化する）ように決定することができる。
【００４７】
上述したように、入力１８１および１８３は、後続する従属フレームの圧縮に使用するために、動き推定および補償システムに提供され、これら入力は、デコーダで見られる様式と同様に、コード化されたばかりの圧縮ビデオから導出されて、伸張されたビデオを提供する。この手順（すなわち、不必要に見える、ビデオを符号化してから復号化すること）は、量子化手順が通常いくつかの値を丸め、量子化画像データが動き補償プロセスで使用されない限り、「雪だるま式」の誤差を導入し得ることから必要である。データの復号化は、機能ブロック１８５を介して図３に示される。次に、アンカー画像推定について結果として得られる残差ｎ−１が、符号化または現フレームｎに使用される。第２の加算点１８７は、アンカー画像残差１８９および、任意のアンカーフレームのアンカーフレームＩ’[ｎ−２]からの画像データ１９１の双方から、アンカー画像推定Ｉ’[ｎ−１]を構築するために使用される。
【００４８】
好ましいエンコーダおよびトランスコーダの動作をこうして提示したが、次に、領域選択および追跡についてさらに詳細に述べる。
【００４９】
Ｂ．好ましい実施形態における領域選択
領域選択は、好ましくは、コンピュータワークステーションソフトウェアと、マウスおよびコンピュータディスプレイモニタを含む標準的なユーザインタフェースツールと、を使用して達成される。理想的には、このソフトウェアは、圧縮されても、またされていなくてもよい入力、およびまだＩＣＲを持っていなくとも、またすでにＩＣＲを持っていてもよい圧縮された入力を含む、異なるタイプのビデオ入力を処理する。好ましくは、使用されるハードウェアは、ＭＰＥＧデコーダ、フレームグラッバ、または少数のフレームの局所的な格納および表示をリアルタイムで提供する同様の増設コンピュータハードウェアを備える。好ましい領域選択プロセス１１３は、図１からのブロック１１３内で実行されるさらなるステップを示す図４にさらに提示される。図４は、画像の初期処理、格納、および表示についての詳細を提示し、機能ブロック２１５は、実際の領域選択プロセスを表し、図６と併せてさらに説明される。
【００５０】
初めに、好ましいソフトウェアは、ビデオの先送り再生および巻き戻し再生、ビデオの停止および一時停止、表示されているビデオの高速先送りおよび高速巻き戻しを行う能力をユーザに提供することに留意されたい。加えて、好ましいソフトウェアは、特定のフレームを選択する能力（フレーム番号または時間に基づいて）、および選択されたフレームまで自動的にスクロールする能力をユーザに提供する。ソフトウェアは、上記ハードウェアと併せて、ディスプレイモニタ上に適宜画像を自動的に表示し、あらゆる復号化機能を提供して、ビデオの所望のフレームを表示する。
【００５１】
これら能力を装備して、ユーザは、図４のブロック２０１に示すように、特定フレームを選択することによって開始する。入力ビデオが圧縮フォーマットであった場合、たとえばブロック２０３、２０５、２０７、および２０９に示すように、選択されたフレームの圧縮されたＧＯＰおよび伸張されたＧＯＰの全体が双方とも（すなわち、先行フレームおよびアンカーフレームの双方を含む）、高速アクセスメモリに格納される。この時点において、好ましいソフトウェアは、図４のブロック２１１に示すように、表示されているフレーム中に存在する領域をいずれも識別し、この領域情報は、ビデオ信号内に埋め込まれる領域マップを介して供給されてもよく、また一定の地理的領域、たとえば、ロゴの挿入に使用される「ボックス」を表示するようにソフトウェアを構成してもよい。好ましくは、存在するあらゆる領域のハイライトされた輪郭は、領域番号またはネーミング属性の表示と併せて、表示されている画像上に重ねられる（このような表示は、後述する図５に示される）。［また後述するように、各領域は離散数の画像スライスとして符号化されるため、領域の輪郭は、マクロブロック境界にあるとかなり容易に導き出される。］画像表示ソフトウェアは、理想的には、ユーザがさらなるレベルの解像度で領域の境界を見ることができるように、ズーム機能２１３を提供する。この時点において、ユーザは、必要に応じてある量の画像データを復号化しており（好ましくは、ＧＯＰ全体）、領域を編集する可能性があるために、存在する領域がハイライトされた画像フレームの表示が提示される。新しい領域の作成または表示中の既存領域の編集は、ブロック２１５に表され、ここでも、ユーザが領域境界を微調整することが可能なように、このプロセス中にズーム機能２１３が提供される。
【００５２】
図５は、画像画面２１７に関連して領域をハイライトした表示の仮想的な図である。特に、画面の殆どを占め、「Ｒ２」という指示を表示する第１の領域２１９と、画面の右下角を占める第２の領域２２１（「Ｒ１」という指示を有する）と、を含む２つの領域が示される。かかる第２の領域は、たとえば、ロゴの挿入に使用されることがある。理想的には、ソフトウェアにより、カーソル許容差範囲「Ｄ」内に見られる上部境界等、境界を「ドラッグ」することによってこれら領域を調整することができ、領域境界は通常、マクロブロック境界にある。
【００５３】
図６は、ユーザがどのように新しい領域を選択するか、または既存の領域を変更するかについてのさらなる詳細を提供すると共に、図４のブロック２１５により実行される機能について詳しく述べる。
【００５４】
画面上に画像が表示されている状態で、ユーザは画面内のポイントを選択し、ソフトウェアは、そのポイントが領域境界に「十分近い」（上記許容差「Ｄ」内など）かどうかを決定する。この問合せに対する答えが肯定である場合、ソフトウェアは、ユーザが既存領域の境界を編集したいものと想定する。これら機能は、図６のブロック２２３、２２５、および２２７において様々に実行される。
【００５５】
機能ブロック２２９に示すように、ユーザ選択ポイントが領域境界に「十分近く」はない場合、ソフトウェアは、選択ポイント付近での画像属性に基づく新しい領域の「推測」に進む。この「推測」は、好ましくは、色相または輝度の類似性、エッジ検出、他の一般的な画像処理技術、またはこれらの任意の組み合わせ等、標準的な画像処理技術に基づく。好ましくは、重み付け機能２３１およびユーザ供給パラメータに基づく技術が強調されて、技術を組み合わせたものが適用され、このようにして、各ユーザは、自動化領域検出機能を各自の興味に合わせて調整することができる。「推測」は、ロゴの挿入に使用される長方形領域等、予め定義される幾何学的形状選択パラメータ（ボックス２３３に示される）にも基づくことができる。ユーザが、重複するように領域を選択する場合、ソフトウェアは、好ましくは、領域を細分して（たとえば、２つの重複する領域が３つ以上の領域になる）、重複を回避するが、この細分は必要なことではなく、領域が重複し得るかどうかについては、好ましい信号フォーマットを使用するオブジェクト境界処理と併せて後述する。
【００５６】
ユーザ選択ポイントまたはエリア、および領域の自動外挿に基づいて領域が自動的に「推測」されると、好ましくは、ソフトウェアにより、ユーザが、長方形あるいは非長方形の境界を「ドラッグ」することによって領域境界を調整することができる。［ここでもまた、ユーザは、カーソルを特定領域境界の「十分近く」に配置し、マウスをクリックすることによって既存の領域を選択する。］所望であれば、ユーザ選択領域がユーザが望む画像データを正確に包含することを確実にするため、ズーム機能（図６に示さず）を採用してもよい。さらに、所望であれば、ソフトウェアは、ユーザの領域選択をより正確に反映するように、ユーザ供給構成パラメータ（または１つのフレーム範囲について使用される一時的なコピー）を自動的に調整するフィードバック機能を含むことができる。領域が正確に定義されると、ユーザは、メニュー機能またはアイコン（図６に示さず）を選択して、領域基準を適用するフレーム範囲を定義する。たとえば、ブロック２３９に示すように、好ましくは、ユーザには、現フレームのみ、現フレームからＧＯＰの終わりまたは始まりまでの範囲、あるいは特定の数のフレームまで／からの、または特定のフレーム番号までの範囲を選択する選択権が与えられる。これら選択は例示的なものにすぎず、実際の実装は、ソフトウェア設計選択の問題である。フレーム範囲が選択されると、次にユーザは、メニュー機能またはアイコンを選択して、領域選択情報およびパラメータを選択されたフレーム範囲内のすべてのフレームに自動的に適用させ、ユーザは、所望であればかかるすべてのフレームの表示を通してスクロールすることができ（図５に示すようなハイライトされた領域境界の図的表示を提供する）、個々の境界をさらに微調整することができる。これらタスクは、図６の機能ブロック２３５、２３７、２３９、２４１、２４３、および２４９に示される。
【００５７】
符号２４５および２４７で参照するように、表示フレームが変更される度に、現在表示または処理されているフレーム中の各種領域の境界が、その特定のフレーム番号についてのすべての領域情報を有するＲＡＭテーブルに書き込まれる。たとえば、（好ましいように）各領域がマクロブロック境界にあるように制限される場合、ＲＡＭテーブルは、単に、マクロブロックが各領域に対応する識別（マクロブロック番号による）からなることができる。既存の領域（入力信号に反映される）が変更された場合、追跡目的のために、既存の領域専用のテーブルの値を設定することも望ましい。変更されたフレームがアンカーフレームである場合、ソフトウェアは、あらゆる従属フレームの領域を自動的に識別し、開始（当てはまる場合）するかこれらフレームにテーブル値を設定し、同様の値をこれらの領域に設定する。この機能は、任意の従属フレームの影響を受けた部分の圧縮解析をトリガするために使用され（従属フレーム内の画像データが変更されていない場合であっても）、追跡ソフトウェアと併せてさらに後述する。
【００５８】
最後に、作成されＧＯＰ全体またはシーケンス全体にマッピングされた領域の場合、関連する領域のグループが、ＡＳＣＩＩテキストを使用して、好ましくは記述的なネーミング属性（たとえば、特定の俳優名またはオブジェクト名）を使用してネーミングされることが好ましい。このネーミング属性は、好ましくは、好ましい信号フォーマットと併せて後述するなど、ＭＰＥＧシーケンスのヘッダ情報に含められる。この特徴の利用の例として、領域ネーミング情報を直接ビットストリームヘッダ情報に埋め込むと、符号化ビットストリームから直接編集する領域をダウンストリームで選択することが可能になる（たとえば、俳優のシャツを個別にネーミングし、後に、このネーミング属性により認識し、符号化ビットストリームから独立して抽出することができる）。また後述するように、好ましくは、領域は、２つの一般的な方法、すなわち「ローカル」領域グループ（たとえば、領域定義が単一のＧＯＰ以下のみに広がる）および「グローバル」領域グループ（たとえば、領域定義が複数のＧＯＰに広がる）のうちの一方としてグループ化される。２つのグローバル領域グループは、好ましくは、同じ名称を共有することが許されず、同じＧＯＰ中の２つのローカル領域グループは、好ましくは、同じ名称を共有することが許されない。ネーミング機能は、図６の参照符号２５１で示される。本明細書で使用する「領域グループ」は、共に関連する異なるフレームからの関連する領域を指し、たとえば、関心のある単一の画像エリアか、または圧縮ビットストリームから一単位として独立して抽出するためにコード化すべきアイテムの集まりを指し、通常、上記記述的な名称属性は、単一の領域グループを通して共有される。
【００５９】
重要なことに、上記タスクは、熟練したソフトウェア設計者により容易に実施される。画像検出ソフトウェアおよび処理技術は、当分野において周知であり、市販のソフトウェアに見られることが多い。同様の結果を提供するためのこれら特徴の実装、変更、または追加は、十分に当業者の能力内である。
【００６０】
Ｃ．出力信号の圧縮および形成
図１のブロック１１９と併せて示したように、領域選択が行われると、ソフトウェアは、関心のあるフレームの圧縮の準備をする。しかし、図４から、動き探索を制限するために、領域選択情報が必要なことが想起され、フレームの１つの領域からの動きベクトルはいずれも、同じ領域グループであるアンカーフレーム中のデータを指すことしかできない。このようにして動き探索を制限するために、まず、ビットストリーム圧縮するときに領域をどのようにスライスするかを決定することが望ましく、この機能は、図１および図３のブロック１１９に示され、図７を参照してさらに詳細に説明する。
【００６１】
特に、ソフトウェアはまず、フレーム中の厳密な領域の数をフレームごとに決定することへ進み、この情報は、図６と併せて上述したＲＡＭテーブルにより提供される。ソフトウェアはまた、元のビデオ入力がＩＣＲを有したかどうかも決定し、有していた場合、かつＩＣＲの数が変更されていた場合、ソフトウェアは、好ましい信号フォーマットと併せてローカル領域グループおよびグローバル領域グループの数についての情報を更新する目的のために、この情報を書き留める。［以下に示すように、この好ましいフォーマットでは、シーケンスまたはＧＯＰヘッダ情報が、適宜シーケンスまたは単一のＧＯＰの領域グループの総数を記載し、この情報を使用して、各フレームについての領域マップ（テーブル）サイズを決定する。］今識別した各種機能は、図７に参照符号２５３、２５５、および２５７で示される。
【００６２】
次に、ソフトウェアは、図６と併せて上述したＲＡＭテーブル情報を使用して、スライス境界を決定する。特に、ソフトウェアは、各画像スライスがどこで開始し、終了すべきか、および各スライスをどの領域に関連付けるべきかを決定する。次に、ソフトウェアは、空間ドメインに領域全体を変換するために復号化しなければならないフレームの各画像スライスを識別する、領域により索引付けされるマッピングを計算し、スライス境界をシーケンス中の各フレームごとにＲＡＭに格納すると共に、フレームのスライスの総数（フレームヘッダ情報に使用される）のインジケータも格納する。これら機能はそれぞれ、参照符号２５９、２６１、２６３、２６５、および２６５に示される。こうして領域情報が利用可能になると、ビデオを必要に応じて圧縮して、出力信号を生成することができる。
【００６３】
圧縮は、入力信号からの変更されていない先行圧縮データ（もし存在すれば）が、可能な場合には再使用され、また、結果として得られる動きベクトルポイントがいずれも関連する領域グループ外をポイントしないように、動きベクトル探索および圧縮が制限されることを除き、典型的な様式で行われる。この後者の機能は、いくつかの様式で行うことができる。第１に、新しい各候補について、あらゆるピクセル単位の比較の前に、探索アルゴリズムが決定ブロックを使用して、候補が領域グループ内にあるかどうかを決定することを除き、動き探索を通常の様式で行うことができる（所与のサイズの探索窓が走査されて、「最も近いマッチング」候補それぞれについての残差の絶対総和をもたらす場合）。候補が領域グループ外にある場合、ソフトウェアはその候補を破棄して次の候補に進み、ソフトウェアが、この手順を使用して可能な候補を見つけられない場合には、単純に、いずれのデータ依存性もなく問題となっているブロックを符号化する。この動作は、おそらく実施が最も単純であるため、好ましい。固定ステップ方法論の場合、探索アルゴリズムは、探索を適切な領域グループからより離れさせるステップ方向、ならびに領域グループ外からの「最も近いマッチング」選択をいずれも阻止することができる。圧縮ソフトウェアは、領域グループのロケーションの周囲に探索窓またはステップ戦略を構築することもできる。
【００６４】
次に、編集および、先行動きベクトルデータの再使用の追跡について、さらに説明し、このタスクは、図１に現れる機能ブロック１１７により識別される。特に、圧縮ソフトウェアは、編集および変更（双方とも現フレームおよびアンカーフレームに対しての）の追跡に依存して、先行ビットストリームデータまたは動きベクトルデータを出力の構築に再使用することができるかどうかを決定する。これを行うために、また上記参照した同時係属中の特許出願に概して記載されるように、「編集レジストリ」が編集された各フレームに採用され、予め存在するＩＣＲを有するフレームが復号化される都度、そのフレームの各領域に関連する２ビット値を使用して、テーブルがそのフレームについて作成される。テーブルは、編集、またはＩＣＲ作成のために伸張されたフレームについてのみ作成され、エントリは、いくつかの異なるタイプの編集を表すことができる。圧縮すべきフレームについてテーブルがないことは、先行ビットストリームデータをいずれも、フレームの出力にそのまま渡すことができることを示す。テーブルが存在する場合、ソフトウェアは、その領域の値をポーリングして、適切な処理を決定する。
【００６５】
第１に、（ａ）現フレーム、関連するアンカーフレーム（または複数のフレーム）の双方における領域が実質的に変更されていない（たとえば、領域が追加または再定義されていない）場合、かつ（ｂ）アンカーフレームの任意の対応領域への一時的な依存性も寸断されていない場合、ソフトウェアは、現領域のすべてのデータを再使用することができる。換言すれば、この場合のビットストリームデータもまた、そのまま出力信号に渡されるが、ヘッダ情報を改訂する必要があり得る。編集レジストリの値はまず、デフォルト（たとえば、「００」）に設定され、適宜変更される。
【００６６】
第２に、領域境界にいくらかの調整が行われた（たとえば、現フレームあるいは任意のアンカーフレームについての、既存領域の再定義または既存領域内での新規領域の作成）が画像コンテンツに変更がない場合、ソフトウェアは、動きベクトル単位で動いて進む。この点に関し、領域境界の変更は、入力信号の動きベクトルを無効にする場合も、また無効にしない場合もあり、ソフトウェアは、各動きベクトルをポーリングして、動きベクトルがなお領域グループ内をポイントしているかどうかを判定し、領域グループ境界をまたぐいずれの動きベクトルについても、新しい探索および動き補償を行う。このイベントにおけるビットストリーム形成は、調整された領域中のすべてのスライスに対して新しく行われる。このタイプの編集は、編集レジストリ中の「１１」等、二値コードで反映させることができる。
【００６７】
第３に、画像コンテンツが、任意の元の動きベクトルデータを無効にするように変更された（たとえば、信号混合またはロゴ挿入などにより、画像データが現フレームまたは任意の関連するアンカーフレームについて変更された）場合、領域および従属フレーム中の関連する領域はいずれも、好ましくは、空間ドメインから完全に再度圧縮される。次に、システムは、出力信号形成のために、このように再度圧縮されたデータから新しいビットストリームデータを作成する。この処理を促進するために、フレームコンテンツを実質的に変更するときに、ソフトウェアは、特に変更された領域について、別の特定の値、たとえばこの目的のために使用可能な二値「０１」等のコード、を編集レジストリに書き込む。ここで、ソフトウェアはまた、好ましくは、変更されたフレームに依存するすべてのフレームを追跡し、同様に、同様の値をこれら領域に書き込む。
【００６８】
第４に、土台をなす画像コンテンツが、元の動きベクトルのいずれにも深刻に影響を及ぼさないように変更された（たとえば、色の補正のみがフレームまたはアンカーフレームに対して行われた）場合、新しい残差を計算する間、元の動きベクトルを再使用することが可能であり得る。二値「１０」等のコードは、この目的のために使用することができ、ここでも、同じ領域グループ中の全ての従属領域に書き込まれる。
【００６９】
単一フレームの「編集レジストリ」２６９は、５つの仮定的な領域を示す図８に示される。第１の領域は、画像背景に現れるビルボード（たとえば、人気のあるソフトドリンク「ＣＯＣＡ−ＣＯＬＡ」のビルボード）を表し、第２の領域は、ロゴの挿入に使用する画面の右下角を表し、第３の領域は、俳優のオレンジ色のシャツ（前景に現れる）を表し、第４および第５の領域は、残りの前景および背景をそれぞれ表す。［この例では、信号フォーマットと併せてさらに後述するように、概して当てはまらないが、オブジェクトは常にマクロブロックの境界で終わり、画像オブジェクト間の境界領域はそれ自体を独立した領域として符号化することができるものと想定する。］この例の目的のために、（ａ）「ＣＯＣＡ−ＣＯＬＡ」の言葉を、代わりに中国語で対応する商標を反映するように変更し、（ｂ）ロゴを画面の右下角に挿入し、（ｃ）俳優のオレンジ色のシャツを代わりに白色に色補正したいものと想定すべきである。この例では、上記二値コードを使用すると、レジストリの値は図８に示すものになり得る。
【００７０】
特に、編集レジストリは、好ましくは、フレームの一時的な順序替えを示すいくつかの様式を含む（高速先送り、巻き戻し再生、および出力ビデオ信号に対する同様の効果を与えるために、入力ビデオの編集に必要とされ得るものなど）。このインジケータは、単一ビットすなわちフラグとすることができ、各編集レジストリについて作成され、現フレームが、依存性が「切断」された従属フレームである場合にのみ設定される。かかる一時的な順序替えがあった場合、現フレームは、好ましくは、完全に再圧縮され、空間ドメインから再符号化される。フレームの順序が単に逆になる（すなわち、依存性は切り離され（severed）ていない）場合、「Ｂ」フレームについては、動きベクトルは単純に交換され（すなわち、順方向動きベクトルが逆方向動きベクトルになり、またその逆も同様）、フレームの再々順序替えが「Ｐ」フレームに影響を及ぼす場合、「Ｐ」フレームが、好ましくは、空間ドメインに変換されてから、たとえば、「Ｉ」フレームとして再圧縮される。
【００７１】
図９は、図１のブロック１２１に示される流れ圧縮アルゴリズムおよび今述べたプロセスのいくつかについてのさらなる詳細を提供する。説明を容易にするため、図９は、ＩＣＲを入力ビデオに単に付与し、編集能力（既存領域の調整以外）をいずれも提供しない装置の実施を反映しており、編集装置は、好ましくは、今述べた機能のより完全なセットを採用する。
【００７２】
図９に見られるように、まず、スライス境界が、ブロック２７１に示すように、ＲＡＭから現フレームについて検索される。元の入力ビデオが圧縮されていた場合、先行圧縮データが潜在的に再使用に利用可能であり、利用可能な先行圧縮データがない場合、ソフトウェアは、フレームタイプ（「Ｉ」、「Ｐ」、または「Ｂ」）の決定、そして領域マップおよびスライス境界を使用してのフレームの圧縮に進み、フレームタイプが従属である場合、すでに述べたように、探索は、アンカーフレームの対応する画像エリアのみをポイントするように制限される。これら機能は、図９中の参照符号２７３、２７５、および２７７に反映される。
【００７３】
先行圧縮データが利用可能な場合、ソフトウェアは、フレームタイプ（「Ｉ」、「Ｐ」、または「Ｂ」）を検索し、同じフレームタイプを対応する出力フレームに仮に適用する。フレームのＲＡＭテーブルが存在しない（ＲＡＭテーブルは、比較に使用されるフレーム番号を示すべきである）場合、ソフトウェアは、ビデオ入力に変更がないものと想定し、元のビットストリームデータを出力信号に直接渡す。ＲＡＭテーブルが存在する場合、ソフトウェアは、領域単位で進み、テーブルを使用して処理のタイプを決定する。各領域ごとに、（ａ）その領域において実質的な編集（たとえば、境界移動、中での新規領域作成、色補正等）がなく、かつ（ｂ）関連する領域グループについての任意のアンカーフレーム領域に実質的な編集がない場合、領域およびスライスについての元のビットストリームデータが、出力ビデオストリームの一部として直接使用される。［フレーム中の他の領域の編集は、スライスの番号付けおよび他のヘッダ情報に影響を及ぼし得るため、フレームおよびスライスヘッダ情報は調整が必要な場合があり、この調整については、参照ブロック１２３に示すビットストリーム符号化機能と併せてさらに後述する。］
単に領域を作成するだけ（編集を実行しない）エンコーダ／トランスコーダのコンテキストでは、フレームコンテンツの実質的な変更はいずれも、単に領域境界の操作からなり、したがって、図９は、実質的なフレーム変更を有する領域の場合、ソフトウェアが、領域グループ境界が交差するかどうかを、動きベクトル単位で照会する。この照会に対する答えが「イエス」である場合、やっかいなデータブロックについての動き補償を再実行する必要があり、「イエス」ではない場合、動きベクトルおよび関連する残差が出力に渡される。これら機能はすべて、ブロック２７９、２８０、２８１、２８３、２８５、および２７７に示される。エンコーダ／トランスコーダが、編集されたビデオの処理に使用される実施では、上述したように、レジストリ値をチェックして、画像コンテンツが変更されたかどうかを決定する決定ブロック等、さらなる照会を行う必要があり得る。
【００７４】
ビットストリーム符号化は、図１のプロセス１２３により実行される機能について詳しく述べる図１０に記載の様式で処理される。特に、再使用されるビットストリームデータは、変更されていないフレームを表す場合、そのまま出力信号に渡され、この動作は、図１０のブロック２８７に示される。あるいは、元のビットストリームデータ（変更されていない領域について）と、動きベクトルおよび残存データ（領域定義または画像コンテンツについて実質的に変更された領域について）との組み合わせであるフレームデータの場合、ソフトウェアビットストリームは、動きベクトルおよび残存データを符号化し、フレームについて新しいスライスおよびフレームヘッダデータ（新しいスライス番号付けを含む）を計算し、理想的には、このデータを出力信号に渡し、ハフマン符号化がフレーム全体に対して共通であるため、ビットストリームデータを再コード化する必要がある場合があり、ソフトウェアはこの決定を、新しい残存データのポーリングに基づいて行う。ソフトウェアは、好ましくは、元のビットストリームデータを再使用するために、量子化（画質を犠牲にして）をいくらか適用するが、ソフトウェアにはまた、ビットストリームデータの再コード化を開始する能力が与えられる。完全に新しく圧縮されたフレームデータの場合（入力ビデオが元々圧縮されていなかったため、あるいは画像の組み合わせまたはロゴ挿入のため）、かかるデータは、周知の手順に従って完全に新しく符号化される。これら機能およびビットストリームフレームデータの加算は、図１０における参照符号２８７〜３１１に様々に示され、最終生成物は、所望によりＩＣＲを有する出力ビデオ信号３１３である。
【００７５】
エンコーダおよびトランスコーダの動作をこのように説明したが、次に、いくつかの異なる信号フォーマットについて考察する。
【００７６】
ＩＶ．ＩＣＲに関連する領域マップおよびコード化情報を有する特別な信号フォーマットの使用
上述したように、本発明は、「生の」圧縮されていないデータであるビデオをとり、それをＩＣＲフォーマットで符号化するために、そしてまた、符号化された圧縮ビデオをとり、それをＩＣＲフォーマットにコード変換するために適用することができる。この後者の動作は、特に、多数の異なるエンティティによる使用のために直接販売する、または配信する既に圧縮されたビデオに有用であり得る。あるいは、ビデオからオブジェクトを抽出するという、予見できる必要性がある場合、独立してコード化された領域フォーマットにビデオをコード変換したい場合がある。たとえば、青いスクリーン背景を背に（「ブルーバック処理（blue-matting）」目的のために）俳優のビデオが撮影される場合、通常、俳優を容易に抽出し、置換背景画像と組み合わせることができるように、俳優を独立してコード化することが望ましい。
【００７７】
後の編集またはオブジェクト抽出を念頭に置いて圧縮されたビデオは、好ましくは、各領域グループを定義し、各グループをテキストで記述する特別な信号フォーマットに配置される。このビデオに好ましいフォーマットについて、図１１〜図２４を参照して説明する。特に、このフォーマットは、特別な制御コード、シーケンスのユーザ定義部分に挿入することのできる情報、ピクチャグループ（ＧＯＰ）、およびＭＰＥＧビデオシーケンスのフレームレベルヘッダ情報を含む。この情報の使用により、圧縮された画像から、画面中の選択されたオブジェクトまたはロケーションを編集または抽出するために、画像フレームのスライスを復号化しなければならない信号自体をデコーダまたはエディタが認識することができ、より具体的には、このフォーマットの使用により、グループ中の個々の領域の相対位置がフレームごとに変化する場合であっても、複数のフレームを通して領域グループをデコーダまたはエディタが追跡することができる。
【００７８】
図１１は、ＭＰＥＧシーケンスおよびヘッダ情報の階層を説明するために使用される。図１２〜図１４は、飛んでいるボールの３つのフレームを含むビデオシーケンスの部分を示し、ボールは、これらフレームを通して右から左に移動して見える。好ましい信号フォーマットは、図１５〜図２０を用いて示すように、各フレームごとに領域マップ情報を含み、１つの領域グループは、ボールに対応するものと定義することができ、もう１つの領域グループは、いずれのボールもない背景に割り当てることができ、第３の領域グループは、ボールおよび背景の双方を有する画像部分に割り当てることができる。最後に、図２４は、ロゴ挿入のために、テレビ画像の右下角に捧げられた領域グループの使用を示すために使用される。
【００７９】
図１１は、いくつかの情報の層を含むＭＰＥＧシーケンス３１５を示す。特に、図１１は、シーケンスレベル層３１７、ＧＯＰレベル層３１９、フレームレベル層３２１、およびスライスレベル層３２３を示す。好ましい実施形態によれば、これら層のうちの最初の３つのヘッダ情報は、ビデオシーケンスからのＩＣＲの抽出を促進する制御コマンドおよび情報を含むようにフォーマットされる。すなわち、特定のデータフォーマットを使用して、ＩＣＲの使用を促進することが好ましい。図１２〜図１４に提示する例では、ビデオシーケンスは圧縮およびコード化され、これらの図に提示されるボールを抽出し、ボールの色を白から赤に変更したいものと想定する。修正されたボールを含むフレームすべての画像データすべてを伸張する必要はなく、圧縮された出力が望ましい場合、出力信号の再圧縮は時間がかかるため、エディタまたはデコーダは、好ましくは、ボールを含む領域グループのみを復号化し、これら領域グループを色についてのみ修正する。編集が完了すると、エディタまたはデコーダが、色補正された領域グループを圧縮し、これらの修正済領域グループを再び、ボールを表す元の情報の代わりに挿入する。エディタまたはデコーダはまた、他の画像と共に使用するために、選択領域におけるオブジェクト、たとえば図１２〜図１４に示すボールを抽出することができる。ボールは図１２〜図１４において各画像の少ない部分のみを占めて図示されるため、好ましい実施形態および好ましいデータフォーマットは、他の場合には圧縮および編集された出力信号を生成する必要があり得る処理時間を、実質的に短縮するよう動作することは明白であるべきである。
【００８０】
「シーケンス」３１５は、映画全体であっても、またはその一部であってもよく、図１２〜図１４の例では、シーケンスが、図示されていない極めて多数のフレームを含むものと想定される。各シーケンスは、シーケンス中に現れる画像を復号化および表示するために使用されるデジタルパラメータを含むヘッダ情報を含み、さらに各シーケンスヘッダは、ユーザ定義の制御コマンドおよび情報のためのスペースを含む。好ましい信号フォーマットと併せて、この情報（シーケンスレベルで）は、シーケンスを通して定義される多数のグローバル領域グループの定義を含む。たとえば、図１２〜図１４によって示されるビデオシーケンスが、子供のサッカー選手についての仮定的な映画の一部である場合、１つのグローバル領域グループを子供と定義し、別の領域をボールと定義することができる。実際には、グローバル領域グループは、好ましくは、たとえば、制御コードおよびＡＳＣＩＩテキストを使用して、シーケンスヘッダのユーザ定義部分内にテキストで定義される（たとえば、領域１＝ボール、領域２＝子供）。このようにして、画像シーケンスを編集したい人は、領域がどのように独立してコード化されたか、およびこれら領域が何を表すのかを正確に信号自体から知るには、シーケンス内の電子ヘッダ情報を検査するだけでよい。
【００８１】
図１１に見られるように、ＭＰＥＧフォーマットでのシーケンスの開始は、通常、符号化ビットストリームを検査し、２３個の連続した０の後に続く１個の「１」および８ビットシーケンス「１０１１０１０１」（１６進数では、この「シーケンス開始コード」値は「０００００１Ｂ５」であり、参照符号３２５で示される）を検出することによって認識される。次に、シーケンスヘッダ情報３２６は、ピクチャサイズ、ビットレート、バッファサイズ、ビデオ規格、および同様のパラメータ等の各種パラメータを含み、これらパラメータの手続きをする制御コードにより認識される。ユーザデータ開始コード３２７（２３個の先行ゼロの後に「１Ｂ２」が続く）が次に利用され、任意のグローバル領域グループ３２８を定義する特別なコードが後に続く。たとえば、特定のビットパターン（たとえば、２２個の先行ゼロの後に「１１００」が続くコード等のコード）を、グローバル領域グループのネーミングを示すために選ぶことができ、その後にテキストコメントおよび第２のグローバル領域グループのネーミング用の別のコードが続き、以下同様である。図１１は、「ｊ」個のグローバル領域グループ３２８の作成を示す。すべてのユーザ情報が完了すると、ＧＯＰ開始コード３２９を提示することができる。
【００８２】
典型的な画像シーケンスでは、ユーザ開始コードの後に、字幕情報等多くの異なるタイプの情報を続けることができる。本発明と併せて動作するエディタの状況では、この情報をスキップして、領域グループ定義および領域マップ情報に直接進むことが望ましい場合があるため、符号化ビットストリームを検査する際に、これらのタイプの情報が容易にわかるようにするコード化構成を使用することが好ましい。当業者は、他のユーザデータの中から領域情報を抽出することができるコード構成を容易に選択することができるはずであり、たとえば、ＭＰＥＧ開始コードは通常、２３個の先行ゼロの後に１個の１が続くことで開始するため、容易に検出可能な「領域情報」コード化構成は、２２個の先行ゼロの後に１個の１が続くもの、および（ａ）グローバル領域グループ定義（「１００」）、（ｂ）ローカル領域グループ定義（「１０１」）、（ｃ）現フレームのスライスの総数の定義（「００１」）、（ｄ）グループマッププリアンブルコード（「０１０」）、および（ｅ）領域マッププリアンブルコード（「０１１」）を表す２値パターンであることができる。これらコードは、特定タイプの領域情報の末尾が、２２個あるいは２３個の先行ゼロ（さらなる領域情報、あるいは別のＭＰＥＧ開始コードをそれぞれ示す）で示されるように、すでに画像シーケンス内にある任意のユーザデータの末尾に挿入することができる。
【００８３】
シーケンスは多数のＧＯＰ３３１を含み、多数のＧＯＰ３３１はそれぞれ、通常、１ダースから２ダース程度の画像フレーム３３２を有する。各ＧＯＰは、通常Ｉ、Ｐ、およびＢフレームを含むが、従属フレーム（ＰまたはＢ）がＧＯＰ外をポイントしないという意味において、自己完結型である。すなわち、ＧＯＰについてのすべてのアンカーフレームは、ＧＯＰ内でのみ見られる。各ＧＯＰはまたヘッダ情報３３３も含み、ヘッダ情報３３３は、２３個の先行ゼロの後に９ビットシーケンス「１１０１１１０００」が続く（１６進数では、このＧＯＰ開始コードは「０００００１Ｂ８」である）ＧＯＰ開始コード３２９を検出することによって認識される。好ましい信号フォーマットによるＧＯＰヘッダ情報はまた、グループマップ識別コードと、どのグローバル領域グループがＧＯＰに存在するかを示すグループマップとが後に続くユーザデータ開始コード３３４（「０００００１Ｂ２」）を含むことが好ましく、図１１は、各ＧＯＰについてのこのグループマップが、図１１中ｖ１〜ｖｊとラベルされる「ｊ」個の値を含むことを示す。
【００８４】
たとえば、図１２〜図１４には、３つの画像フレーム３３５、３３７、および３３９からなる１つの例示的なＧＯＰが提示される。シーケンス中に２つのグローバル領域グループしかなく、子供が図１２〜図１４のＧＯＰに存在しない場合、このＧＯＰのグループマップは、第１の領域（ボール）がこれら画像中に存在するが、第２の領域（子供）は存在せず、そのため個々のフレームの領域マップによって表されないことを示す値「１０」（図１６に見られる）等のビットパターンを含むことができ、例示的なグループマップ３４１は、図１６に示される。ＧＯＰのユーザ情報は、ローカルに定義される領域グループの領域グループ情報３４３も含み、たとえば、図１２〜図１４のＧＯＰは、第３の領域は飛んでいるボールに対する青空の背景であり、第４の領域は野球ボールと空の間のトランジッションであることを識別するＡＳＣＩＩテキスト情報を含むことができる。上述のように、ローカルに定義される領域グループは、２２個の先行ゼロの後に「１１０１」が続き、その後に領域グループをネーミングするＡＳＣＩＩテキストが続くことによって示すことができる。ＧＯＰレベルヘッダ情報が完了すると、ビットストリームは、フレーム開始コードを含む。領域グループ（グローバルおよびローカル）の総数は、図１１における量「Ｎ」で表される。
【００８５】
図１１に戻り、各ＧＯＰ３３１は、複数の画像フレームについての情報を含み、各画像フレームは、フレームタイプ（たとえば、Ｉ、Ｐ、またはＢ）等の重要なパラメータを定義するそれ自体のヘッダ情報３４５を含む。各フレームは、フレーム開始コード３４７（２３個の先行ゼロの後に１個のゼロ、その後に８個の後続ゼロ、すなわち１６進数での「０００００１００」）、フレームヘッダ情報、およびフレームについての画像コンテンツを含むいくつかの「画像スライス」３４９で開始される。この時点において、フレーム開始コード３４７（１６進数での「０００００１Ｂ２」）が使用され、この後に適切なコード、およびフレームの画像スライスの総数の定義３５３、先行コード、および特定フレームの領域マップ３５５が続く。領域マップは、どの画像スライスがＧＯＰの各領域グループに関連するかを識別し、換言すれば、領域マップは、所与の領域を特定のフレーム中の「どこ」で見つけることができるかを示す。各スライスもまた開始コード３５６を介して、２３個の先行ゼロの後に続く、０〜１７５のスライス番号を示す００−ＡＦ（１６進数）によって示される。
【００８６】
この点に関し、第２のグローバル領域（たとえば、子供）は図１２〜図１４の例に示されず、そのため、このＧＯＰには３つの領域グループ、すなわちボール、背景、およびボール／背景の組み合わせそれぞれしかないと上に述べた。したがって、これらフレームそれぞれについての領域マップは、好ましくは、ＧＯＰ中の各領域グループについて１つずつ、３つのテーブルからなり、各テーブルは、特定のフレーム中の各画像スライスに対応する１つのエントリを有する。[図１６のグループマップは、２つのグローバル領域のうち、一方はＧＯＰに存在し、もう一方は存在しないことを示すため、領域マップ中の第１のテーブルは第１のグローバル領域グループに対応するものと解釈され、後続する各テーブルは、定義された順序で、ローカルに定義された領域グループそれぞれに対応するものと解釈される。この点に関し、シーケンスを検査するエディタまたはビデオプロセッサは、現ＧＯＰについてブローバル定義された領域グループならびにローカルに定義された領域グループすべてを追跡する必要がある。この動作は、図１１では量「Ｎ’」で表され、少なくとも１つのグローバルに定義された領域を領域マップで表すことができないことを示す。]今述べたネーミングおよびコード構成に対する代替の変形として、当業者は、（たとえば、エディタに領域グループ定義および順序を追跡させる代わりに）エディタにおいて領域グループを追跡する異なるネーミングまたはコード構成および方法を実施することができ、たとえば、代替として、領域グループをあらゆるＧＯＰそれぞれについて再定義することができる。
【００８７】
図１４に提示する例では、総数１９枚の画像スライスがあり、したがって、そのフレームの各テーブルが１９個の１ビットエントリを有するものと想定する。図１５は、位置でグループ化し、符号「Ａ」、「Ｂ」、または「Ｃ」とラベルされる３つのデータタイプそれぞれの画像スライスの仮定的なロケーションを示す。データタイプ「Ａ」は、ボールの画像データを指し、データタイプ「Ｂ」は背景シーンの画像データを指し、データタイプ「Ｃ」はボールから背景への画像遷移の境界データを指す。各データタイプ（または「Ａ」、「Ｂ」、または「Ｃ」とラベルされるボックス）は、後述する２つの異なる領域マッピング方式のうちのいずれかを使用して符号化される。[重要なことに、ＭＰＥＧ−２フォーマットは、画像マクロブロックの後続行それぞれが新しいスライスとして符号化されるように制限するため、このフォーマットに対応する画像には１９枚よりも多くのスライスが表され、図１２〜図２３は、少数のスライスおよび領域のみを示し、例示目的のためにのみ使用される。従来、Ｍ.Ｐ.Ｅ.Ｇ.シーケンス中の各フレームは、最大１７５枚の画像スライスを有し、画像シーケンスは、ビットストリームにおいて個別に符号化され、２３個の先行ゼロの後に続く１個の１、その後に続く「１」〜「ＡＦ」（１７５）までの２バイト値からなるスライス開始コードで示される。従来のＭＰＥＧフォーマットには、画像データの各マクロブロックに関連する個別のコマンドレイヤもあるが、マクロブロックレベルの情報は、好ましい実施形態において特に使用されない。]
上述のように、２つの領域マッピング方式について、図１５に適用してそれぞれ説明する。第１の領域マッピング方式（図１７〜図１９に示す）では、各データタイプ「Ａ」、「Ｂ」、および「Ｃ」は、個別の領域として個々に符号化される。このマッピングを使用すると、たとえば、図１５の圧縮された表現からボールのみを抽出したい場合、ボールデータを含む領域「Ａ」および「Ｃ」の双方を識別および復号化する必要がある。第２の領域マッピング方式（図２０に示す）では、２つの領域グループのみが使用される。第１の領域グループは、ボールを有する任意の画像スライス（たとえば、データタイプ「Ａ」または「Ｃ」を有する任意のスライス）からのデータを含むものと識別されるが、第２の領域グループは、背景を有する任意の画像スライス（たとえば、データタイプ「Ｂ」または「Ｃ」を有する任意のスライス）からのデータを含むものと識別される。
【００８８】
図１６は、この「飛ぶボール」の例での仮定的なグループマップ３４１を示し、図１７〜図１９は、上記第１の領域マッピング方式の場合の個々のテーブル３５７、３５９、および３６１を示す。特に、図１７は、図１５に示す１９枚の画像スライスのうち、１１番目のスライスのみがこの領域（たとえば、いかなる背景もなく、ボールのみを有する画像の部分）に属するデータを有することを識別する。図１７は、１９枚のスライスのうち、７番目、１０番目、１１番目、１２番目、および１５番目の画像スライス以外は、すべて青空の背景のみを有することを示し、最後に、図１９は、７番目、１０番目、１２番目、および１５番目のスライスはボールおよび背景の双方を有することを示す。このフレーム中のボールに対して色の補正（たとえば）を行いたい人は、ボールに対応するすべての画像データを見つけるために、図１７および図１９のテーブルによって識別される領域をすべて復号化する必要があるが、純粋に背景のみを表す画像フレームのいずれの部分も復号化する必要はないであろう。
【００８９】
信号フォーマットは、上記ヘッダ情報だけではなく、ＩＣＲ自体の圧縮画像データも含む。各領域グループ、たとえば図１５における「Ａ」、「Ｂ」、および「Ｃ」それぞれについて３つの領域グループ方式は、これら領域内のデータの動きベクトルおよび残差が先行フレーム中の対応する領域のみをポイントするように、動き探索中、制限が必要である。たとえば、図１５は、図１２〜図１４の仮定的な３フレームＧＯＰにおける第３のフレームを表す一方、図２１は、ボールが画像フレームの右上側にある図１２に見られる第１のフレームを表す。図１５のフレームが従属「Ｐ」フレームを表す一方、図２１は独立「Ｉ」フレームを表す（図１２〜図１４がＧＯＰを表す場合にはそうならなければならないように）ものと想定する場合、動き探索制限は、図１５における「Ａ」データの領域におけるすべての動きベクトルが図２１における「Ａ」データを有する対応領域のみをポイントするように制限する。同様に、図１５において「Ｂ」データを有するあらゆる領域中のすべての動きベクトルは、図２１における「Ｂ」データを有するあらゆる対応領域内をポイントするように制限され、図１５における「Ｃ」データを有するあらゆる領域中のすべての動きベクトルは、図２１の「Ｃ」データを有するあらゆる対応領域内のみをポイントするように制限される。この相互独立性、すなわちその領域グループ内をポイントする動きベクトルおよび残差を領域グループ外からのデータが持つことができないという制限は、この制限なしでは、関心のある領域グループ中のデータ変更により、グループ外（の別のフレーム）からの動きベクトルおよび残存データを無効にし得るため、比較的重要である。好ましい信号フォーマットの画像スライスデータ（図１１の参照符号３６３で示される）内に含まれる動きベクトルおよび残存データは、これら制限に従ってフォーマットされる。
【００９０】
図２２および図２３は、図１２および図２１の仮定的なフレームに適用された、上記２つの領域マッピング方式を示す。特に、図２２は３領域方式を示し、すべての領域テーブルがここでは単一のマトリックス３６５に組み合わせられ、連続したデータ行（各行が領域テーブルである）として示される。図２１は、１８枚の画像スライスのみの例示的な場合を提示し、図２１のフレームのヘッダ情報は、スライスの総数（１８）を示し、領域マップ情報を解釈するソフトウェアは、１８個の１ビットエントリを各テーブルに使用する。図２３は第２の領域マッピング方式を示し、データタイプ「Ａ」または「Ｃ」に１つ、およびデータタイプ「Ｂ」または「Ｃ」に１つの、２つのみのテーブルのマトリックス３６７が使用される。この領域マップの場合も同様に、各画像スライスに１つずつ、１８個のエントリのみを使用する。上述したように、いくつかのＭＰＥＧ画像信号では、新しいスライスがマクロブロックの各行ごとに始まる必要があるため、実際の例は通常１８または１９よりも多くのスライスを有する。
【００９１】
上記からわかるように、シーケンス、ＧＯＰ、フレーム、またはスライスの開始は、符号化ビットストリームから直接認識することができる。同様に、ＩＣＲに関連するすべての情報はヘッダ情報に格納されるため、配信されるビデオは、独立コード化領域用に特別にフォーマットされた信号から、画像オブジェクトまたはロケーションを認識、復号化、かつ抽出することができるのに十分なデータをデジタル制御情報内に含む。たとえば、ロゴ挿入に関与する用途では、エンコーダ（ならびに関連するＧＯＰおよび領域マップ）は、画像画面の右下角を常に個別にスライスし、その角をグローバル領域グループとして定義するように定義することができる。ロゴ挿入を行うにあたり、エディタは、単に、符号化ビットストリームを監視して、（ａ）右下角に対応するグローバル領域グループ、たとえば「ＬＯＧＯ」という名称のグローバル領域グループの識別を決定し、（ｂ）このグローバル領域グループを有する各ＧＯＰの各フレームから、適切なグローバル領域グループに対応する領域マップのテーブルを抽出し、（ｃ）テーブルによって識別される各画像スライスを復号化する必要があるだけである。次に、ロゴ挿入が行われ、変更された画像データが、新しい動き推定および補償の対象となり、符号化され、ここで変更されたデータの代わりに元のビットストリームに挿入される。各領域グループは互いに他の領域グループから相互独立しているため、変更データの再挿入は任意の画像フレームの他の領域グループにはいずれも影響を及ぼさない。最後に、変更されたデータによりビットレートまたはバッファ情報が変更される場合には、特定のフレームまたはＧＯＰのビットレートまたはバッファサイズを変更する必要があり得る。
【００９２】
図２４は、右下角３７１が、図２４に示す地方テレビ局ロゴ「ＴＶ５」等、画像またはロゴ３７３の挿入のために確保された画像フレーム３６９を示す。この点に関し、配信および続く局所ロゴ挿入のために符号化された圧縮ビデオ信号を生成したい場合、小さな長方形領域が、シーケンス中の画像フレームすべてについて一定のロケーションに定義されることが好ましい。たとえば、シーケンスヘッダにおいて、グローバル領域グループを、図２４において参照符号３７１で示す角エリア等、幅６４ピクセル、高さ３２ピクセル（たとえば、４マクロブロック幅×２マクロブロック高）の右端下の長方形であると定義し、テキストで説明することができる。この場合、各フレームの領域マップは、この領域グループに属するものとして（マクロブロックの）最後の２ラインの最後の４つのマクロブロックのみを含むスライスを明確に列挙するテーブルを含む。
【００９３】
重要なことに、上記信号フォーマットは、領域を独立してコード化する唯一の方法ではなく、ビデオまたは他の画像信号に限って適用される必要はない。たとえば、ＭＰＥＧ技術はオーディオ信号にしばしば適用され、圧縮信号から選択特徴の抽出が可能な独立コード化領域の使用は、オーディオ信号に適用することができる。さらに、「領域マップ」の使用は、独立コード化領域のロケーションを伝える唯一の方法ではなく、領域ネーミングについての情報は、信号自体に含まれるテキスト以外の機構で配信することができる。この後者のポイントの例として、領域グループのテキスト定義は、マニュアル等、印刷されたテキストで行ってもよい。加えて、グループマップまたは領域マップは、独立コード化領域の多くの用途に必ずしも必要なものではなく、たとえば、ロゴ挿入用途では、最後の画像スライスが独立コード化の固定エリアを表すことを単に「理解」するだけであってもよく、エディタは、いずれのマッピング情報も抽出する必要はなく、単に、この画像スライスのみを抽出し復号化するように単にプログラムまたはユーザの制御下で動作してもよい。
【００９４】
領域情報を埋め込んだ信号の好ましい例についてこうして説明したが、次に、独立コード化領域への編集適用および使用についてさらに詳細に説明する。上述したように、以下に述べるプロセスは、信号が今述べた好ましいフォーマットに適合する信号であるかどうかに関係なく、独立コード化領域を有する任意の圧縮信号に対して使用可能であるものと想定すべきである。
【００９５】
Ｖ．考えられる編集適用
上述したように、本開示に記載する技術は、フィルムおよびビデオプロセスの様々な部分で使用することができ、本技術は、最初に画像シーケンスを取り込む際、または前に取り込まれたシーケンスを処理するために使用することができる。本技術は、フィルム転送と併せてポストプロダクションまたは編集ハウスにより（テレシネプロセス等）、またはインターネット放送ビデオ、衛星配信、または番組配信プロセスの他の部分に使用することができる。
【００９６】
本項に述べる技術は、ＩＣＲ信号がすでに作成され、入力として提供されるものと想定し、ビデオ出力もまた概してＩＣＲ信号であるが、行われたある種類の編集を反映して、ＩＣＲによって与えられる効率を利用する。
【００９７】
図２５は、ＩＣＲ信号のロゴ挿入への使用を示す（たとえば、地方テレビ局による）。元の圧縮ＩＣＲビデオ信号は、図２５において参照符号３７５で示され、平凡な画像画面３７７で図的に示される。ロゴまたは他の静止画像３７９をＩＣＲ信号の１つまた複数のフレームの所定の地理的領域に差し替えることが望まれる。
【００９８】
システムはまず、ロゴと組み合わせる適切なＩＣＲを選択することから開始する。ビデオ入力はすでに、この目的のためにＩＣＲを有しているものと想定されるため、好ましくは、適切なＩＣＲが自動的に検出される。［自動検出は、システムソフトウェアに所定のグローバル領域グループ名、たとえば「ＬＯＧＯ」を認識させることにより、あるいは編集機器のユーザに、挿入に使用する領域グループ空間を識別させることによって行われる。］領域が選択されると、機能ブロック３８１に示すように、ソフトウェアは、選択された領域グループを空間ドメインに変換する。重要なことに、この抽出は、好ましくは、符号化ビットストリームから直接、関心のある領域グループに対してのみ行われる。機能ブロック３８３に示すように、シーケンスの他の領域および画像データは圧縮されたフォーマットのままであり、この結果は、右下角３８７（復号化されたロゴ領域に対応する）が欠けた平凡な画像画面３８５によって図的に示される。これに対応して、図２５の右側は、拡大された画像画面右下角３９１にさらに示されるように、参照符号３８９における空間ドメインの存在を示す。
【００９９】
次に、ロゴまたは他の画像が、復号化された空間ドメインデータと組み合わせられる。通常、ロゴ画像のサイズおよび構成は、組み合わせられる画像エリアに正確に対応する。これが当てはまらない場合、ロゴ画像は、この基準に見合う画像として構成されることが好ましい。次に、空間ドメイン画像データとロゴ画像データが、参照符号３９３、３９５、および３９７に示すように、不透明度「ａ」を使用して組み合わせられる。この不透明度は、ロゴ自体が不透明であるか、半透明であるかを決定する。変数ａは、通常、すべての非ロゴデータについてはゼロであるため、原画像（１−ａで重み付けられる）は、ロゴが重複しないエリアでは影響を受けない。この画像組み合わせを行った後（通常、一度にＧＯＰ全体について）、新しい動き探索および補償が、新しい変更された空間ドメインデータに対して行われる（適切であれば、元のフレームタイプを使用して）。次に、このデータが、ビットストリーム符号化されて、編集プロセスのために空間ドメインに復号化された画像スライスに代わり、そして２つの信号が一緒に加算される。これらプロセスは、図２５の参照符号３９９、４０１、および４０３により様々に示される。適切であれば（たとえば、新しいデータが異なる圧縮統計を有する場合）、ソフトウェアは、ブロック４０５に示すように、従来の様式でフレームまたはＧＯＰのバッファサイズおよびビットレートパラメータを調整する。このプロセスの出力は、ここでは挿入されたロゴを含む圧縮ビデオ信号４０７であり、編集は、あらゆるフレームそれぞれの全体を空間ドメインに復号化することなく実行された。この新しい信号は、図２５において、網掛けした右下角を有する画像画面４０９で示される。
【０１００】
図２６は、色補正でのＩＣＲの使用に関連する。特に、特定の色を目により快い色で置換する（編集中に）という見込みの下でテレビ番組または映画を「撮影」することは珍しくない。図２６を参照して、俳優のシャツまたは胴体４１１が先にＩＣＲとして定義されているものと想定すべきである。図２６に示すプロセスは、ポストプロダクションハウスで実行され得る。
【０１０１】
図２６は、圧縮ビデオ４１３の入力を示し、画面４１５がそのビデオを図的に示しており、画面は、水平線パターンで集合的に示される１つまたは複数の特定の色を含むものとしてシャツ４１１を示す。これら仮定的な色の１つまたは複数を異なる１つまたは複数の色に補正することが望まれる。
【０１０２】
ＩＣＲのコンテキストにおいて色補正を考察する前に、まず、デジタル色補正プロセスについて総体的に説明することが有用であり得る。これを行うため、色補正システムでは一般的なように、編集システムのユーザは、ボックス４１７および４１９に示すように、色選択角ならびに置換色角を供給する。色選択角は、置換に選択される色相孤（hue arc）（極座標において）を表し、他の色平面ベースの関数（Ｙ−Ｂ、Ｙ−Ｒ）ならびに非色平面ベースの関数等、色を選択する他の多くの機構がある。色相トラップ（hue trap）４２１は、色選択角内にない特定の画像ピクセルを識別し、これらピクセルは、色補正のために処理されない。色選択角内に入るピクセル色４２３は、変換４２５を受け、変換は、置換色角によって定義される。
【０１０３】
この色補正がどのように動作するかの簡略化された例をとるために、シャツ４１１は、白、明るい赤、および暗い赤を含む３つの色を有するものと想定すべきである。色選択角４１７は、すべての赤を置換すべきであると示し、さらに、置換色角４１９は、狭い範囲の青、たとえば非常に明るい青からスカイブルーであり得る。この例では、変換の結果、広範囲の赤が狭い範囲の明るい青に変換されることになる。換言すれば、処理後のシャツの色は、明るい赤が非常に明るい青で置換され、暗い赤がスカイブルーで置換された状態で、白、非常に明るい青、およびスカイブルーとして現れる。
【０１０４】
次に、色変換されたピクセルが、加算点４２７を介して元のピクセルデータに再び組み合わされて、新しい画像データが作成される。
【０１０５】
ＩＣＲのコンテキストにおいて、色補正プロセスは、今しがた述べたロゴ挿入と非常によく似た様式で動作する。特に、図２６のブロック４２９に示すように、ユーザは、色補正の対象とする特定の領域を示し、これら領域は、圧縮ビットストリームから空間ドメインに復号化される（ブロック４３１に示すように）が、他の領域は圧縮されたままである。ここでも、圧縮領域は、ブロック４３３、および色補正のための領域の除去を象徴する空白点を有する画像画面４３５の絵により図２６の左側に示される。同様に、図２６の右側は、空間ドメイン４３７の存在および適切な領域の除去を象徴する、シャツ４１１の絵を示す。シャツは色補正のために処理され、新しい動き推定および補償（参照ブロック４３９により）が色補正された領域に対して行われ、その結果は、ブロック４４１に示すように、符号化されたビットストリームである。次に、結果得られる２つの圧縮ビットストリームが加算点４４３を介して共に組み合わされ、必要であれば（たとえば、参照ブロック４４５を参照）フレームバッファサイズおよびビットレートパラメータが調整される。最後に、色補正プロセスの結果は、色補正されたシャツを有する画面４４９に示す、色補正されたビデオを表す圧縮ビデオビットストリーム４４７である。
【０１０６】
図２７は、高速先送り機能および高速巻き戻し機能を説明するために使用される。これら機能を行う多くの方法があるが、図２７は、フレームをドロップし、「Ｑ」番目ごとのフレームのみを保持することにより、フレーム速度が倍数「Ｑ」だけ増大したプロセスを示す。図２７において、フレーム速度が２倍になり、したがって、偶数のフレーム４５１のみが保持され、ビデオ４５２は一定の変化しないフレームレートを有するものと想定する。図２７により説明されるプロセスは、特に、最初の画像シーケンスをとり、２番目の画像シーケンスを最初の画像シーケンスの１つまたは複数の領域に組み合わせるまたは置換したい場合、ＩＣＲ信号と併せて適用することができる。この機能については、図２９と併せてさらに後述する。
【０１０７】
図２７の左側は、１０個のフレームのシーケンス４５３を絵で示し、半分のフレーム４５５は陰影が付けられておらず（かつドロップされる）、半分のフレーム４５１には陰影が付けられ、保持される。保持されるフレームのいくつかは、ドロップされるアンカーフレームに依存するものと想定すべきであり、適切なビデオ伸張および再構築のためには、高速先送りまたは高速巻き戻しプロセス中、これらフレームを分離して処理して、寸断された依存性を取り除く必要がある。図２７において、参照符号４５９、４６１、４６３、および４６５は、この分離を示すために使用される。
【０１０８】
寸断された依存性を取り除くために、「Ｂ」フレームは、任意のアンカーフレームが保持されるかどうかに応じて、「Ｉ」、「Ｂ前方」、または「Ｂ後方フレームに変換され、「Ｐ」フレームは、独立フォーマットに変換される。この変換は、好ましくは、関心のあるフレームを空間ドメインに完全に伸張し、次に所望のフォーマットに再圧縮することによって行われる。代表として、発明者Susie J. WeeおよびBhaskaran Vasudevにおいて１９９８年４月２９日付で出願された「System for Editing Compressed Image Sequences」という米国特許出願第０９／０６９，５９６号に示唆されるように、この処理を圧縮ドメインで行う方法も存在し、この出願を参照により本明細書に援用する。これら変換プロセスは、図２７において参照符号４６７、４６９、および４７１により様々に示される。圧縮ビットストリームデータが変換されたフレームに利用可能になると、変更されていないフレームのビットストリームデータに再び組み合わせられて、圧縮ビデオ出力４７３が形成される。
【０１０９】
図２８もまた、ＩＣＲ信号、すなわち２つの画像シーケンスを共にスプライシングすることに特定ではないプロセスを示す。第１の画像シーケンス４７５は図２８の左側に示され、第２の画像シーケンス４７７は図２８の右側に示される。第１の画像シーケンスは、元の圧縮ビデオ入力４７９を形成し、ユーザが各シーケンスについてスプライスポイントを選択する。このスプライスポイントにより、１つまたは複数の依存性（アンカーフレームへの）が寸断される結果になり得るため、まず、影響を受けるフレームを変換して、影響を受ける依存性を取り除く必要がある。これを行うために、図２８は、第１および第２の画像シーケンスそれぞれから保持すべき斜めに網掛けしたフレーム４８１および４８３、ならびにスプライス４８５の影響を受けない保持フレームおよびスプライスの影響を受ける保持フレーム（参照符号４８７で示す）を絵で示す。ちょうど上で述べたプロセスと同様に、依存性は、空間ドメインあるいは圧縮ドメインにおいて、「Ｂ」フレームを独立した「Ｂ前方（B-Forward）」または「Ｂ後方(B-Backward)」フレームに適宜変換することにより、また影響を受ける「Ｐ」フレームを「Ｉ」フレームに変換することにより取り除かれる（たとえば、図２８のブロック４８９、４９１、および４９３を参照）。
【０１１０】
巻き戻し再生機能は、単に、圧縮ドメインにおいてフレームを順序替えし、今述べた変換を行うことによって行うことができる。しかし、「Ｂ」フレームは変換する必要がなく、単に、前方動きベクトルが後方動きベクトルになった、およびその逆を示すように、ヘッダ情報をいくらか変更する必要があるだけである。
【０１１１】
この処理背景を念頭に置き、次に、これらおよび他の機能の使用について、ＩＣＲ信号のコンテキストで説明し、図２９を参照して説明する。図２９において、圧縮ビデオ入力は、参照符号５０１および、ビルボード５０５を示すグラフィック５０３で示される。この例では、ビルボードが独立してコード化され、圧縮ビデオ入力と同じレートまたは異なるレートで再生することができる新しい第２の画像で、あるいは画像シーケンス５０７全体でビルボードを置換したいものと想定する。このプロセスの一例として、英語のサイン（たとえば、サッカーの試合の背景に広告として現れる）を中国語での等価物で置換したい場合がある。代替として、新しいビデオ画像をビルボードについて既存画像フレームにスプライスする、またはビルボードに意図される新しいビデオの再生速度を逆にするか変更するようにしたい場合もある。
【０１１２】
図２９に見られるように、システムは、圧縮ビデオシーケンス５０１を、領域選択情報５０９と共にユーザから受信する。領域選択情報を使用して、ブロック５１１に示すように、圧縮ビデオシーケンス中の領域のサブセットを復号化させる。残りの領域は圧縮されず、好ましくは、ブロック５１３および画面絵図５１５（ビルボード領域が欠けて象徴される）に示すようにビットストリームフォーマットのままである。
【０１１３】
第２の画像またはシーケンス５０７は、ユーザの望みに応じて変更され、好ましくは、第１の画像上に重なった第２の画像またはシーケンスを閲覧する機会、かつ第２の画像の全体像（perspective）をクロッピング、スケーリング、かつ変更する機会をソフトウェアがユーザに提供する。したがって、第２の画像またはシーケンスは、参照符号５１３および５１５に示すように、ユーザにより、ビデオ入力内の行き先におおまかに適合するように調整される。ソフトウェアは、第２の画像またはシーケンスをとり、その情報をユーザにより変更されたものとして、復号化された空間ドメインの寸法にマッピングし、置換画像データをビデオ入力の元の領域（または、少なくとも元の領域の選択されたオブジェクト内）に合わせる。好ましくは、ユーザには、（仮想表示、ズーム、およびマウス等のユーザインタフェースを介して）置換画像データをさらにクロッピングする、またはそのデータを原画像データ上で半透明にする機会が提供される。ソフトウェアはまた、好ましくは、原画像データに対して（たとえば、フレームドロップを介して）第２の画像（シーケンス）を加速または減速した表示をに合わせるか、またはビデオ入力に対して第２の画像（シーケンス）を巻き戻し再生するか、またはいくつかの画像シーケンスを共にスプライスして領域の置換画像データを形成するメニュー機能をユーザに提供する。これら機能は、参照符号５１７、５１９、５２１、および５２５に示される。
【０１１４】
図２９の右下側は、圧縮ビデオ入力に戻すかまたは組み合わせる置換を意図する編集されたデータまたはシーケンスを示す絵５２７を含む。このデータは、図２９に符号５２９および５３１で示すように、新しい動き推定および補償、またビットストリーム符号化の対象となる。データは、離散画像スライスにおいて符号化されて、元のビルボードを表した画像スライスの正確な位置をとる。図５３３および５３５は、双方の領域を組み合わせる最終ビデオ出力を表す。
【０１１５】
ＶＩ．結論
重要なことに、ビデオ、テレビ、および同様の分野における当業者は、本発明の原理から逸脱せずに、上記実施形態に変更を容易に行うことができることを認識されよう。たとえば、特定のＭＰＥＧ−２エンコーダおよびトランスコーダの使用について説明したが、他のビデオまたはオーディオ規格で動作可能な他の装置を、ＩＣＲを利用するように設計することが可能である。他の信号フォーマットおよび他のＩＣＲネーミング方式を使用することも可能であり得る。
【０１１６】
こうして本発明のいくつかの例示的な実施について説明したが、各種代替、変更、および改良が当業者には容易に思い付くことは明白であろう。かかる代替、変更、および改良は特に上述されていないが、本発明の趣旨および範囲内にあるものと意図され、含意される。したがって、上記説明は、例示のみを意図するものであり、本発明は、併記の特許請求の範囲およびその等価物によってのみ制限され定義される。
【図面の簡単な説明】
図１〜図１０は、本発明の原理を実施するエンコーダ／トランスコーダの構成および動作を示す。
【図１】エンコーダ／トランスコーダの主な機能を示す。
【図２】入力ビデオ信号を処理し出力ビデオ信号を生成するため、好ましい実施形態を実施するソフトウェアがどのように実装されるかを示す、コンポーネントレベルの図である。
【図３】独立してコード化された領域の状況でのＭＰＥＧ−２圧縮を示す流れ図である。
【図４】図１のブロック１１３内で実行されるさらなる機能を示す拡張した流れ図である。
【図５】既存の領域、フレーム順序を変更する、または新しい領域を追加するユーザに対して既存の領域がハイライトされる視覚表示の図である。
【図６】図４のブロック２１５内で実行されるさらなる機能を示す拡張した流れ図である。
【図７】図１のブロック１１９内で実行されるさらなる機能を示す拡張した流れ図である。
【図８】編集、すなわち以下にさらにラベル付けられる「編集レジストリ」を追跡するために、各フレームごとに使用し得るテーブルの図である。
【図９】図１のブロック１２１内で実行されるさらなる機能を示す拡張した流れ図である。
【図１０】図１のブロック１２３内で実行されるさらなる機能を示す拡張した流れ図である。
図１１〜図２４は、ビデオシーケンスの信号フォーマットを説明するために使用され、信号自体は、独立してコード化されたオブジェクトまたはフレームのロケーションの識別、およびシーケンス中のどの画像スライスが関心のあるオブジェクトの復号化を可能にするかの識別に十分な情報を含む。
【図１１】多くのピクチャグループ（ＧＯＰ）を有するビデオシーケンスを含む基本的なＭＰＥＧフォーマット信号の階層を示し、各ＧＯＰは複数のフレームを含み、各フレームは複数のスライスを含み、各スライスは圧縮された画像データを含み、また、シーケンス、ＧＯＰ、フレーム、およびスライスレベル層それぞれについてヘッダ情報のビットストリームコードも示し、さらに、どのように領域グループ定義および領域マップ情報をこの好ましい信号フォーマットに挿入することができるかを示す。
図１２〜図１４は、３つの画像フレームのグループを示し、ボールが右から左にこれらフレームを横切って移動して現れる。
【図１２】第１の画像フレームの右上角にあるボールを示す。
【図１３】第２の画像フレームの中央にあるボールを示す。
【図１４】第３の画像フレームの左側にあるボールを示す。
【図１５】第３の画像フレーム（図１４）に対応し、どのように領域をＭＰＥＧ−２フォーマットで作成しスライスすることができるかの１つの方法論を示し、領域「Ａ」はボールのみに対応し、領域「Ｂ」は青空である背景に対応し、領域「Ｃ」はボールおよび背景の双方を有する「境界」エリアに対応し、図１５の長方形は、１９枚の画像スライスを表し、スライスがこれら領域に属するデータを含むかどうかを示す目的のためだけに「Ａ」、「Ｂ」、または「Ｃ」とラベル付けられ、重要なことに、好ましいＭＰＥＧ−２フォーマットは通常、マクロブロックの新しいラインごとに新しい画像スライスを必要とするため、例示および説明のみのために使用される図１５に示す１９枚のスライスよりも、はるかに多くのスライスが示される。
【図１６】仮定的なグループマップを示し、２つのグローバルに画定される領域グループが、シーケンスごとに定義され（ボールおよび子供）、１ビットエントリが、グローバルに画定された領域グループそれぞれに提供され、図１２〜図１４のＧＯＰに存在するかどうかを示す［換言すれば、図１２〜図１４は、おそらく画像シーケンス中の他のどこかに現れる子供ではなくボールの画像を含むため、ビットエントリは、「１」（ボールがこのＧＯＰに存在することを示す）および「０」（子供がこのＧＯＰに存在しないことを示す）である］。
図１７〜図１９は、図１４および図１５の第３のフレームに対応するマッピング方式を示し、それぞれが領域マップの３つのテーブルのうちの異なる１つを示す。
【図１７】図１５の領域「Ａ」の第１のテーブルを示し、テーブルは、図１５に見られる各画像スライスについて１つずつ、１９個のエントリを有し、各エントリは、領域「Ａ」についての画像データが対応する画像スライス中で見つかるかどうかを示す。
【図１８】図１５の領域「Ｂ」のテーブルを示すことを除き、図１７と同様である。
【図１９】図１５の領域「Ｃ」のテーブルを示すことを除き、図１７と同様である。
【図２０】第２の領域マッピング方式を提示し、ボールおよび背景双方について遷移領域を個別に識別する代わりに（図１５、および図１７〜図２０に示すように）、２つのテーブルのみが使用され、図２０の一行目（すなわち、最初のテーブル）では、値が、対応する画像スライスが任意のボールデータを有するかどうか（背景データも存在するかどうか）を表し、２行目（すなわち、２番目のテーブル）は、対応する画像スライスが任意の背景データを有するかどうか（ボールデータも存在するかどうか）を示し、２つのマッピング方式の１つの相違は、図２０に示す第２のマッピング方式では、画像スライスを２つの異なる領域に関連付けることが可能なことであり、図２０のマッピング方式は、多くの領域が使用される（したがって、オブジェクト間の各境界専用の個別の領域を有することが面倒であり得る）場合に特に好ましい。
【図２１】図１２の第１のフレームについての第１のマッピング方式を示すことを除き、図１５と同様であり、図２１からわかるように、画像データは、第１の画像フレームの右上角におけるボールの位置を表し、図２１は、図１５の１９枚の画像スライスの代わりに１８枚の画像スライスを定義する。
【図２２】図２１の例に適用される第１のマッピング方式を示し、特に、１８枚の画像スライスに対応する１８個のデータ値をそれぞれ有する、図２１の領域「Ａ」、「Ｂ」、および「Ｃ」それぞれに１つずつ、３つのテーブルを含む領域マップ全体を示す。
【図２３】図２１の例に適用される第２のマッピング方式を示し、特に、ボールデータを有する各画像スライスごとに１つ（すなわち、「Ａ」または「Ｃ」とラベル付けられる領域）と、背景データを有する画像スライスごとに１つ（すなわち、「Ｂ」または「Ｃ」とラベル付けられる領域）との２つのテーブルを含む領域マップ全体を示す。
【図２４】画像フレームの右下角に挿入された地方テレビ局のロゴ「ＴＶ５」を示す仮想的な画像フレームであり、各画像フレームの右下角に対応する、グローバルに定義された領域グループの作成を説明するために使用され、かかるグローバル領域グループは、ビデオシーケンス中の各画像フレーム全体の復号化および伸張を完了することなく、各フレームの角がロゴ挿入実行可能なように固有に独立してコード化される、ロゴ挿入アプリケーションで定義される。
図２５〜図２９は、独立してコード化された領域の使用により促進されるいくつかの編集アプリケーションを説明するために使用される。
【図２５】ロゴ挿入の流れ図を提供し、図２５に関連して、圧縮ビデオ信号入力がすでに、各画像フレームの右下角における独立してコード化された領域を有するものと想定している。
【図２６】色補正の流れ図を提示し、図２６に関連して、シャツまたは俳優はすでに、圧縮ビデオ信号入力内に独立して符号化されており、俳優のシャツの色を変更したいものと想定している。
【図２７】高速先送り再生または高速巻き戻し再生の一方法を示す流れ図を提示する。
【図２８】２つの画像シーケンスのスプライシングを共に示す流れ図を提示する。
【図２９】画像シーケンスを画像または第２の画像シーケンスと共にスプライシングすることを示す流れ図を提示し、スローガン“ＥＡＴ  ＡＴ  ＪＯＥ’Ｓ”を特徴とするビルボードクローズアップとして表される画像または第２の画像シーケンスは、第１の画像シーケンスの独立してコード化された領域に組み合わされたものとして示され、図２７および図２８に表されるプロセスは、第２の画像シーケンスが第１の画像シーケンスの独立してコード化された領域に挿入される、２つの画像シーケンスを共に組み合わせる場合に採用することができる。
【図１】
0004777583.tif 000002
【図２】
0004777583.tif 000003
【図３】
0004777583.tif 000004
【図４】
0004777583.tif 000005
【図５】
0004777583.tif 000006
【図６】
0004777583.tif 000007
【図７】
0004777583.tif 000008
【図８】
0004777583.tif 000009
【図９】
0004777583.tif 000010
【図１０】
0004777583.tif 000011
【図１１】
0004777583.tif 000012
【図１２】
0004777583.tif 000013
【図１３】
0004777583.tif 000014
【図１４】
0004777583.tif 000015
【図１５】
0004777583.tif 000016
【図１６】
0004777583.tif 000017
【図１７】
0004777583.tif 000018
【図１８】
0004777583.tif 000019
【図１９】
0004777583.tif 000020
【図２０】
0004777583.tif 000021
【図２１】
0004777583.tif 000022
【図２２】
0004777583.tif 000023
【図２３】
0004777583.tif 000024
【図２４】
0004777583.tif 000025
【図２５】
0004777583.tif 000026
【図２６】
0004777583.tif 000027
【図２７】
0004777583.tif 000028
【図２８】
0004777583.tif 000029
【図２９】
0004777583.tif 000030