(57)【要約】  本発明は、シーケンスで動画を構成するようにシーンを描写する画像のシーケンスを処理する方法及びシステムに関する。この方法は、後続の画像を個々に前処理して、前処理された画像のシーケンスを得るステップと、個々の画像が符号化されることなく通過することを定期的に可能にし、シーケンスにおける未圧縮の画像間の中間画像を、これらの中間画像を差分と置き換えることによって符号化することによって、前処理された画像の圧縮のために符号化するステップとを含む。この方法は、中間画像の符号化の前に、中間画像のうちの少なくとも１つにおいて、中間画像が変化していないか又は少なくとも大幅に変化していないエリアを識別するステップと、識別されたエリアを、最も近時に通過した未圧縮の画像からの対応するエリアに置き換えるステップとを更に含む。【選択図】図９および図１０
2014509481.tif 000002
【特許請求の範囲】
【請求項１】
画像のシーケンスを処理して送信する方法及び／又は記録する方法であり、各画像は前記シーケンスで動画を構成するようにシーンを描写しており、該方法は、
量子化、マクロブロック分割、及び変換、例えば離散コサイン変換のうちの少なくとも１つのように、後続の画像を個々に前処理するステップであって、前処理された画像のシーケンスを得るものである、前処理するステップと、
送信又は記録の前に、
個々の画像が符号化されることなく送信又は記録に移ることを定期的に可能にし、
前記シーケンスにおける未圧縮の画像間の中間画像を、これらの中間画像を最も近時に通過した未圧縮の画像に対する差分と置き換えることによって符号化する、
ことによって、前記前処理された画像の圧縮のために符号化するステップであって、前記前処理された画像のシーケンスの送信又は記録に必要とされる送信容量又は記録容量を減少させる、符号化するステップと
を含む方法であって、
前記中間画像の符号化の前に、
前記中間画像のうちの少なくとも１つにおいて、前記中間画像が、前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別するステップと、
前記中間画像内の前記識別されたエリアを、前記最も近時に通過した未圧縮の画像からの対応するエリアに置き換えるステップであって、これらのエリアは、前記未圧縮の画像及び前記中間画像のうちの少なくとも一方による前記シーン内のロケーションが一致している、置き換えるステップと
を含むことを特徴とする、画像のシーケンスを処理して送信する方法及び／又は記録する方法。
【請求項２】
前記中間画像内の前記エリア及び前記未圧縮の画像内の前記エリアは、サイズが一致している、請求項１に記載の方法。
【請求項３】
前記未圧縮の画像及び前記中間画像は、整数個のエリアを含む、請求項１又は２に記載の方法。
【請求項４】
前記エリアは、２０×１５ピクセル、２４×１８ピクセル、及び３２×３２ピクセルを含む群からのサイズのうちの１つのサイズを有する、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記中間画像が前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していない前記エリアを識別するステップは、前記中間画像と、元の画像の形態の前記未圧縮の画像とを比較することを含む、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記中間画像が前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していない前記エリアを識別するステップは、前記中間画像と、輝度チャネルの前記未圧縮の画像とを比較することを含む、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記中間画像が前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していない前記エリアを識別するステップは、前記中間画像と、彩度チャネルのうちの少なくとも１つの前記未圧縮の画像とを比較することを含む、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記中間画像が前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していない前記エリアを識別するステップは、前記中間画像と前記未圧縮の画像とをエリアごとに比較することを含む、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記中間画像が前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していない前記エリアを識別するステップは、前記中間画像及び前記未圧縮の画像の少なくとも関連のあるエリア間の差分を規定することと、前記差分を所定の閾値と比較することと、前記差分が前記閾値未満である場合に、１つのエリアが置き換えられるべきであると判定することとを含む、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記差分は、輝度チャネル及び彩度チャネルのうちの少なくとも一方における１つのエリア内でのピクセルごとの比較に基づく関数を含む、請求項９に記載の方法。
【請求項１１】
前記差分は、１つのエリア内又は複数のエリア間の統計的解析に基づく関数を含む、請求項９又は１０に記載の方法。
【請求項１２】
前記関数において光沢又は反射の影響を抑制するステップを含み、前記関数は光沢補償係数を含む、請求項１０又は１１に記載の方法。
【請求項１３】
前記関数において照明の変化又はカメラが誘発したホワイトバランスの変化の影響を抑制するステップを含み、前記関数は照明及びホワイトバランスの正規化係数を含む、請求項１０〜１２のいずれか１項に記載の方法。
【請求項１４】
前記関数においてカメラが誘発したカラーバランスの変化の影響を抑制するステップを含み、前記関数はカラーバランスの正規化係数を含む、請求項１０〜１３のいずれか１項に記載の方法。
【請求項１５】
画像のシーケンスを送信及び／又は記録するためのシステムであり、各画像は前記シーケンスで動画を構成するようにシーンを描写しており、該システムは、
量子化、マクロブロック分割、及び変換、例えば離散コサイン変換のうちの少なくとも１つのように、後続の画像を個々に前処理して、前処理された画像のシーケンスを得るように構成されたプリプロセッサと、
送信及び／又は記録の前に、
個々の画像が符号化されることなく送信又は記録に移ることを定期的に可能にし、
前記シーケンスにおける未圧縮の画像間の中間画像を、これらの中間画像を最も近時に通過した未圧縮の画像に対する差分と置き換えることによって符号化する、
ことによって、前記前処理された画像を圧縮して、前記前処理された画像のシーケンスの送信又は記録に必要とされる送信容量又は記録容量を減少させるように構成された符号器と
を備えるシステムであって、
前記中間画像の符号化の前に、前記中間画像のうちの少なくとも１つにおいて、前記中間画像が、前記最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別するように構成された識別器と、
前記中間画像内の前記識別されたエリアを、前記最も近時に通過した未圧縮の画像からの対応するエリアに置き換えるように構成されたレプリケータであって、これらのエリアは、前記未圧縮の画像及び前記中間画像のうちの少なくとも一方による前記シーン内のロケーションが一致している、レプリケータと
を備えることを特徴とする、画像のシーケンスを送信及び／又は記録するためのシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、それぞれ請求項１及び１５のプリアンブルに記載の画像のシーケンスを処理して送信する方法、及び／又は、画像のシーケンスを記録する方法及びデータを圧縮する方法、並びに画像のシーケンスを処理して送信するシステムに関する。
【背景技術】
【０００２】
そのような方法及びシステムは、一般に知られている。例えば、標準規格ＭＰＥＧ２、ＭＰＥＧ４、ｍｊｐｅｇ、Ｈ．２６Ｘ、並びに以下の特定の非限定的な例としてＨ．２６４及びＸ．２６４、並びに他の多くのアルゴリズム及び標準規格も、シーケンス内の後続の画像における情報の冗長性に基づく、記録又は送信のためのビットストリームの圧縮に依拠している。ほとんどの場合、そのような標準規格及びアルゴリズムによれば、そのような冗長性は、現在の画像内の情報の量を差分情報のみに削減することによって利用される。この差分情報は、その現在の画像内のピクセルとシーケンス内の先行する画像又は今後の画像内の対応するピクセルとの間の差分にのみ関する情報を提供するものである。そのような標準規格及びアルゴリズムによれば、未圧縮画像が記録又は送信される。この画像は、幾つかの刊行物ではＩフレームと呼ばれる場合がある一方、中間の圧縮画像は、多くの場合、Ｐフレーム又はＢフレームと呼ばれる。ただし、本発明は、そのような表現にも特徴にも限定されるものではない。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
従来技術の方法及びシステムは、依然として、いずれの送信又は記録の方法及び／又はシステムについてもかなりの負荷を呈する。なぜならば、既知の方法に起因する情報の量及び既知のシステムに由来する情報の量は、依然としてかなりのものであり、特に帯域幅が乏しく、場合によっては、例えば、監視によって取得された画像を記録又はより好ましくは制御室等に直ちに送信する必要がある監視カメラの場合のようにリモートでありうる使用分野では、依然として少なくともネットワーク、レコーダ及び送信機の過負荷の一因となる場合がある。一方、本発明は、そのようないずれの適用分野にも特に制限されない。なぜならば、好ましくは画質の劣化が全くないか又は少なくとも更なる画質の劣化若しくは追加の画質の劣化がないデータ圧縮又は少なくとも削減が、デジタル化された画像の処理及び記録又は送信のいずれの使用分野においても常に目的であるからである。
【０００４】
本発明は、従来技術の方法及びシステムの不都合を改善又は少なくとも軽減するとともに、データ圧縮及び／又は削減を更に（一層）改良することを目的として開発された。そのため、本発明は、それぞれ請求項１及び１５の特徴部の顕著な特徴を有する方法及びシステムに関する。
【課題を解決するための手段】
【０００５】
本発明は、カメラ、若しくはカメラに接続されたコンピュータ等の画像処理構成物、又は画像を記録するためのカメラ以外の任意のデバイスに具現化することができることに留意されたい。得られた画像のストリームは、（ハード）ディスク又は他の記録担体に記録することもできるし、ネットワークを介して送信することもできる。このネットワークは、無線とすることができる。
【０００６】
本発明は、従来技術による差分画像処理が送信又は記録のための最大のデータ圧縮及び／又は削減を実用的に既に提供していると広く支持された確信に反するものである。
【０００７】
しかしながら、それにもかかわらず、本発明によれば、特に、画像のシーケンスが、当該画像のシーケンスによる描写シーンにおいて変化をほとんど含まない場合、かなりの利得が達成可能である。
【０００８】
本発明による方法及びシステムは、多くの好ましい実施の形態を有することができ、これらの実施の形態のうちの選択したもののみが、従属請求項に規定されている。
【０００９】
加えて、本発明による方法及びシステムは、例えば、中間画像内のエリア及び未圧縮の画像内のエリアが、サイズが一致しているという特徴を示すことができる。これによって、未圧縮の画像の画像エリアと中間（以下では、現在と呼ばれる場合がある）画像の画像エリアとの比較が容易になる。
【００１０】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、未圧縮の画像及び中間画像が整数個のエリアを含むという特徴を示すことができる。
【００１１】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、エリアが、２０×１５ピクセル、２４×１８ピクセル、及び３２×３２ピクセルを含む群からのサイズのうちの１つであるサイズを有するという特徴を示すことができる。以下に説明する用途では、３２×３２のエリアサイズが好ましいが、他の用途では、代替的なサイズが好ましい場合がある。
【００１２】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、エリアを、可能なサイズを有する長方形にグループ化することができるという特徴を示すことができる。この可能なサイズは、２０×１５ブロック又は２４×１８ブロックのうちの一方であるが、これらの値に限定されるものではない。
【００１３】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、中間画像が最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別することは、中間画像と、元の画像の形態の未圧縮の画像とを比較することを含むという特徴を示すことができる。
【００１４】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、中間画像が最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別することは、中間画像と、輝度チャネルの未圧縮の画像とを比較することを含むという特徴を示すことができる。
【００１５】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、中間画像が最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別することは、中間画像と、彩度チャネルのうちの少なくとも１つの未圧縮の画像とを比較することを含むという特徴を示すことができる。
【００１６】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、中間画像が最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別することは、中間画像と、未圧縮の画像とをエリアごとに比較することを含むという特徴を示すことができる。
【００１７】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、中間画像が最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別することは、中間画像と未圧縮の画像とを統計的解析方法を用いて比較することを含むという特徴を示すことができる。
【００１８】
加えて及び／又は一代替形態として、本発明による方法及びシステムは、例えば、中間画像が最も近時に通過した未圧縮の画像に対して変化していないか又は少なくとも大幅に変化していないエリアを識別することは、中間画像及び未圧縮の画像の少なくとも関連のあるエリア間の差分を規定することと、差分を所定の閾値と比較することと、差分が閾値未満である場合に、エリアが置き換えられるべきであると判定することとを含むという特徴を示すことができる。
【００１９】
差分と、その差分を閾値と比較することとを伴うそのような好ましい実施の形態では、本発明による方法及びシステムは、例えば、差分が、輝度チャネル及び彩度チャネルのうちの少なくとも一方における１つのエリア内でのピクセルごとの比較に基づく関数を含むという特徴を示すことができる。
【００２０】
差分を規定する関数を伴うそのような好ましい実施の形態では、本発明による方法及びシステムは、例えば、この関数において光沢（sparkles）又は反射の影響を抑制するという特徴を示すことができ、ここで、この関数は、光沢補償係数を含む。
【００２１】
差分を規定する関数を伴うそのような好ましい実施の形態では、本発明による方法及びシステムは、例えば、この関数において照明の変化又はカメラが誘発したホワイトバランスの変化の影響を抑制するという特徴を示すことができ、ここで、この関数は、照明及びホワイトバランスの正規化係数を含む。
【００２２】
差分を規定する関数を伴うそのような好ましい実施の形態では、本発明による方法及びシステムは、例えば、この関数においてカメラが誘発したカラーバランスの変化の影響を抑制するという特徴を示すことができ、ここで、この関数は、カラーバランスの正規化係数を含む。
【００２３】
本発明は、図面に示されるとともに図面及び特定のアルゴリズム又は標準規格を参照することによって説明されるような本発明の特定の実施形態を参照して以下に明らかにされる。しかしながら、その図面も説明も、本発明の保護の範囲に対する限定として解釈されるべきではなく、本発明は、結局のところ、添付の特許請求の範囲において排他的に規定される。
【図面の簡単な説明】
【００２４】
【図１】符号化及びその結果得られるデータ削減圧縮（data compression of reduction）が実行される際に従うレベル及びプロファイルへの、本発明を用いることができる一例示のプロトコルの分割を示す図である。
【図２】シーンを描写する画像の分割と、輝度（Ｙ）平面と２つの色差平面（彩度Ｃｒ及び彩度Ｃｂ）とに画像を分割する方法とを示す図である。
【図３】幾つかの従来のマクロブロックを含むエリア（本明細書において「スーパブロック」と呼ばれる場合がある）への画像の、本発明による分割と、それらのエリアへの彩度ブロックのオプションの追加とを示す図である。
【図４】８×８ピクセルブロックからのｊｐｅｇビットストリームの従来の生成方法を一般的に示す図である。
【図５】フレームのシーケンス内に配列されている未圧縮のＩフレーム画像並びに圧縮されたＰフレーム画像及びＢフレーム画像の構成を示す図である。
【図６】Ｉフレーム、Ｐフレーム及びＢフレームの間の相互関係を示す図である。
【図７】従来のデータ圧縮におけるシーン（の一部分）の移動を補償する従来のベクトル適応を示す図である。
【図８】輝度平面における現在の画像（処理及び圧縮される）と直前の先行するフル（Ｉフレーム）画像との間の比較（差分ビュー（differential view））を示す図である。
【図９】大きな変化が２つの比較される画像間、すなわち、図８に示すような輝度平面に発生したエリアの現在のフル（Ｉフレーム）画像及び最も近時に通過したフル（Ｉフレーム）画像の双方におけるエリアの識別を示す図である。
【図１０】最も近時に通過したフル（Ｉフレーム）画像のどの部分が、処理及びデータ圧縮のために、最も近時に通過したフル（Ｉフレーム）画像から現在の画像にコピーされるのかを示す図である。
【発明を実施するための形態】
【００２５】
本発明のより詳細な説明の前に、限定ではなく一例として、Ｘ．２６４／Ｈ．２６４プロトコルの枠組みを、本発明を実施することができる枠組みの範囲内の１つの枠組みとして説明する。その結果として、本発明は、他のアルゴリズム及びプロトコルにおいても少なくとも等しく適用可能である。
【００２６】
Ｘ．２６４プロトコル
Ｘ．２６４／Ｈ．２６４ライブラリは、様々な新しい符号化プロトコルと、既にＨ．２６３又はＭＰＥＧ４の一部分であった旧式のプロトコルとを実施する。２０を超えるいわゆる拡張部分を有する完全なＭＰＥＧ４仕様は、膨大であり、その全内容をここで議論することはできないことに留意されたい。しかしながら、本発明について、プロトコルの定義の基本的な理解だけは、本発明の適切な理解のために必要である。この例示のプロトコル／標準規格が以下のものに基づいていることを確認することは重要である。
−マクロブロックの修正ＤＣＴ空間変換、
−ＤＣマクロブロック係数の第２段階アダマール変換（以下ではこれ以上議論しない）、
−マクロブロックの長方形分割、
−色差符号化定義（４：２：０、４：２：２又は４：４：４）、
−拡張された基準フレーム定義を有するＩフレームタイプ、Ｐフレームタイプ及びＢフレームタイプ、
−オプションとしての可変ブロックサイズ動き補償、並びに、
−エントロピー符号化システムＣＡＢＡＣ及びＣＡＶＬＣ（以下ではこれ以上議論しない）。
【００２７】
Ｈ．２６４仕様に存在するこれらの特徴よりもはるかに多くの特徴が存在するが、これらの特徴は、本発明に関係するものではない。技法／特徴のうちの幾つかのより詳細な議論は、本発明を説明及び明確化するのに役立つと考えられる限りにおいて、以下で与えられる。
【００２８】
言及すべき重要なＨ．２６４仕様の１つの態様は、図１に概略的に示すように、プロトコル１が、当業者によく知られた方法で、レベル及びプロファイルに分割されるということである。符号化及び結果として生じるデータ削減は、これらのレベル及びプロファイルに従って実行される。サポートされるプロファイルは、どの圧縮技法が用いられるのかを示し、サポートされるレベルは、復号器が何をどのような速度で処理できなければならないのかを示す。この場合も、詳細は、ここではそれほど重要ではなく、重要なことは、種々の圧縮方法又は他の圧縮方法について本発明を用いた任意の代替的なプロトコルと本発明を用いない任意の代替的なプロトコルとの間の比較がこれを考慮に入れなければならず、そうでなければ、公平な比較を行うことができないということを認識することである。
【００２９】
問題を幾分、より深く掘り下げると、用いられる圧縮機能だけが重要であるわけではなく、それらを調整する方法も重要である。中でも、画像の質及びビットストリームの量に関して最終結果に膨大な差を生み出すパラメータが符号化において設定される。カメラでは、これらのパラメータは、通例、固定値に設定されるが、これらの固定値は、問題になっている任意の特定の用途に適切である場合もあるし、適切でない場合もある。
【００３０】
この問題について本発明に関する手法は、非依存型の（agnostic）ものである。本発明による方法及びシステムは、Ｈ．２６４を強化し、内部パラメータの更なる微調整に応じて、全体的な利得をより小さくもより大きくもすることができる。
【００３１】
詳細な内容に入る前に、ここで、以下の議論は、Ｈ．２６４プロトコルの定義全体の完全な概略を提供することではなく、本発明による方法及びシステムを明らかにすることのみを意図していることに留意されたい。また、本発明は、このプロトコルにも他のいずれのプロトコルにも制限も限定もされない。簡潔にするために、ここでは、Ｈ．２６４プロトコルが参照され、その結果、このプロトコルは、引用することによって本明細書の一部をなすものとする。
【００３２】
色差符号化定義（４：２：０、４：２：２又は４：４：４）
図２に概略的に示されている赤、緑及び青の色からなるフルカラー画像２が、Ｙ「平面」と呼ばれる１つの輝度平面３（黒／白画像を担持する）並びに彩度「Ｃｒ」平面及び彩度「Ｃｂ」平面と呼ばれる２つの色差平面４の３つの新たな「平面」に変換される。
【００３３】
この変換プロセスは、データ削減をもたらさないが、眼は、色情報よりも輝度に対する知覚がはるかに鋭敏であるので、この分離によって、各平面を異なるように圧縮することが可能になる。上述した平面に符号化するための３つの異なる符号化方式４：２：０、４：２：２又は４：４：４が用いられる。最後のものは、全ての情報が圧縮に用いられることを示すのに対して、４：２：２及び４：２：０は、ピクセルを単に除去することによって又は或る種の補間方式を用いることによって２分の１又は４分の１にピクセル数を削減する。その結果、ピクセルバッファもサイズが異なる。これは、本発明に関して重要である。なぜならば、上記平面は、本発明による方法及びシステムでは、別々に取り扱わなければならないからである。これは、以下の説明からより明らかになる。
【００３４】
マクロブロック
全体画像２は、図３に概略的に示すように、マクロブロック５に分解される。これらのマクロブロックは、正方形又は長方形を形成する近接ピクセルのグループである。これは、平面ごとに行われる。マクロブロックは、タイプに応じて、サイズが１６×１６ピクセル、１６×８ピクセル、８×１６ピクセル、８×８ピクセルである。正方形マクロブロックは、修正ＤＣＴ変換の基本として用いられる。マクロブロックは、サイズ８×８、８×４、４×８、４×４のサブマクロブロックに分割することができる。全てのタイプを動き補償に用いることができる。
【００３５】
図３には、１６０×１１２ピクセル画像及び色分離のプロセスが示されている。このピクセル画像は、マクロブロック５へと分解される。ここで、色符号化は４：２：０であり、輝度（Ｙ）平面における１６×１６輝度ブロック６と、Ｃｒ及びＣｂの彩度平面における４×４彩度ブロック７、８が得られる。
【００３６】
ここで、図３の実施形態では、最大のエンティティが１６×１６ピクセルのマクロブロックエンティティであることに気付くことは重要である。しかしながら、本発明によれば、スーパブロックと呼ばれる上部構造が定義され、このスーパブロック内に、全てのマクロブロック及びサブマクロブロックが包含される。例えば、寸法３２×３２のピクセルを有するスーパブロックを選ぶ。このスーパブロックは、図３における白の正方形９によって示されている。しかしながら、この数字は、原理的には自由に選択可能であり、本発明によるスーパブロックは、マクロブロックと同じサイズを有することもできるし、それよりも小さくすることさえもできる。スーパブロックのサイズは、自由に選択可能である。なぜならば、このような方法で、スーパブロックのエッジにわたる境界効果を少なくとも或る程度は防止することができるからである。スーパブロックのサイズの選択は、そのような境界効果を最小にするためのツールとして用いることができる。
【００３７】
ＤＣマクロブロック係数のＤＣＴ変換
図４に示すようなＨ．２６４において用いられるＤＣＴ（「離散コサイン変換」）１０は、離散コサイン変換の完全形の概数バージョンであり、この概数バージョンは、整数を用いて動作するように作成されている。
【００３８】
整数を用いた計算は、特に、本来一般に知られているＡＲＭプロセッサのようなＲＩＳＣプロセッサ上では、通例、はるかに高速である。図４の左側には、マクロブロック用の修正ＤＣＴ１０の２次元基底関数が表示され、右側には、８×８マクロブロックの簡略化された変換のプロセスが表示されている。ＤＣＴ変換１０は、本来、基底関数上への画像の投影であり、係数行列を生成する。平滑な画像部分しか含まないマクロブロックの場合、ほとんどの係数はゼロであるか、又はゼロに近い。
【００３９】
量子化１１を用いて、これらの係数は符号化され、既に小さいそれらの係数はゼロに設定される。ここで、圧縮の大部分が行われる。その後、係数は、ジグザグ形式１２で読み取られ、効率的なランレングス符号化のために、ゼロが最後にあることが確認される。当業者によく知られたステップを幾つか更に行った後、送信及び／又は記録のための０及び１の系列からなるデータストリーム１３が生成される。このプロセスステップの一般表現が図４に示されている。
【００４０】
拡張された基準フレーム定義を有するＩフレームタイプ、Ｐフレームタイプ及びＢフレームタイプ
画像が色平面に分割され、その後、マクロブロックに分割され、ＤＣＴ変換され、そして圧縮された後、個々に符号化された画像のストリームが得られる。
【００４１】
しかしながら、ストリーム内の画像は、通例、相互間に多くの相関を有する。このことは、３つのよく知られたタイプのフレーム、すなわち、図５においてそれぞれ１４、１５及び１６として示されたいわゆるＩフレーム、Ｐフレーム及びＢフレームを定義することによって、送信及び／又は記録のための圧縮又はデータ削減に利用することができる。これらのＩフレーム１４、Ｐフレーム１５及びＢフレーム１６は、通例、図５及び図６に示すように、順序Ｉ，Ｂ，Ｂ，Ｐ，Ｂ，Ｂ，Ｐ，．．．，Ｉ等に配列される。シーケンス内のＩフレーム、Ｐフレーム及びＢフレームを決定するための可能なアルゴリズムが、特に図６に示されている。
【００４２】
特に図６に概略的に表されているように、Ｉフレーム１４は、完全な画像を含み、Ｐフレーム１５は、前のＩフレーム１４と符号化された画像との間の差分を含み、Ｂフレーム１６は、２つのＰフレーム１５又は１つのＰフレーム１５とＩフレーム１４との間の差分を含む。
【００４３】
差分のみを続けて送信することが過度に長い間持続すると、ストリームは連続的に劣化するので、時々、新しいＩフレームが送信される。
【００４４】
可変ブロックサイズ動き補償
場合によっては、画像上でブロックをシフトさせて、或るシーンについて２つの後続の画像内で同じである対応するブロックを見つけることを通じて等しい部分を探索することによって、フレーム間の冗長性が更に利用される。ブロックのＤＣＴ係数を２倍含めるよりも、変換ベクトル１７を既に知られているデータのブロックに格納する方が、はるかに効率的である。ここで、画像のこれらの類似の部分をどのようにして見つけるのかは、実際には重要ではなく、図７に示すように、そのことのみが起こることが重要である。現在のフレームからの部分Ｂは、基準フレームからの部分Ａと一致し、したがって、変換ベクトル１７を符号化するだけでよい。
【００４５】
したがって、基準フレームにおけるシーンと現在のフレームにおけるシーンとの間の類似点をデータ削減又は圧縮に利用するいずれの方法も、画像ストリームの効率的な符号化をもたらすことになる。
【００４６】
例示のＨ．２６４プロトコルの態様に関する上述の議論の後、本発明の一実施形態を用いることができる可能な環境をより良く理解するために、次に、本発明自体を以下でより詳細に説明する。
【００４７】
本発明による方法は、本明細書では、ＤＳＢＭ（差分スーパブロックマスキング）とも呼ばれる。図３を説明するときに上記に示したように、本発明によるスーパブロックは、そのサイズ及びロケーションを従来のマクロブロックのサイズ及びロケーションと同じに選ぶことができたとしても、従来のＨ．２６４方法のマクロブロックとは異なるものである。この方法及びシステムがどのように機能するのかについての詳細は、以下で議論される。
【００４８】
ここで、本発明による方法がＨ．２６４の仕様内に留まるようにＸ．２６４プロトコル上の追加モジュール（アドオン）としてこの方法を実装することができることに留意することは重要である。これは、受信機側において、又はデータストリームが送信されるのではなく記録された場合にはプレイヤの側において、伸長／復号化及び再構成された画像のその後の提示に特別な措置を取る必要がないという結果を有する。
【００４９】
画像解析
上記で議論したように、シーケンス又はストリーム内の画像は、或る程度の冗長性を示す。すなわち、ほとんどの場合、シーケンスでは、近接画像は、少数の相違を除いてほとんど等しい。これは、特に監視カメラからの画像シーケンスに当てはまる。Ｉフレーム１４、Ｐフレーム１５及びＢフレーム１６のシステムは、この現象を既に或る程度利用しており、そのため、このシステムに改良の余地はないように見え得る。これが、これまで当業者が認識していたものであり、偏見でもあった。
【００５０】
しかしながら、例えば、一方で動画（movie）の激しく変化する画像のシーケンスと、動画の及び監視カメラからのゆっくりと変化するか又はほとんど変化しない画像のシーケンスとの間には、重要な相違がある。その相違は、それらの画像の用いられ方にある。ユーザは、通常のビデオを鑑賞している間、流れるようなクリアな画像を期待し、画像のあらゆる細部が重要となる。もちろん、監視カメラの場合も、細部は重要であり、ぼやけた画像は、確かに望まれないが、これらの画像のシーケンスの実質的に静止した部分については、画像が近時のものであるか又は多少以前のものである場合、細部は実際に重要であるとは限らない。これらのより近時の画像とそれよりも以前の画像との間の差分は、通例、雑音及びシーンの照明でしかない。これらは、ユーザにとっては重要ではないが、送信及び／又は記録にとっては、意外にも情報の大部分をデータストリームに与えることが分かっている。
【００５１】
本発明によれば、カメラからのストリーム内の２つの連続した又は接近した実質的に同一の映像が減算される場合、雑音及び照明変化を除いて、情報をあまり含まないか又は全く含まない差分映像が得られる。
【００５２】
したがって、データストリームのサイズを更に削減するための重要なアイデアは、どの部分が十分に不変であるのかを識別することである。これらの部分については、Ｉフレーム１４等の以前の画像からのマクロブロックを単位とした一部分又は一部分片が単に用いられ、その結果、現在の画像のその部分又は部分片に関して情報は全く送信されない。現在の画像の一部分は、雑音、照明の相違しかないとき又は他の無関係な変化が起こった場合に、十分に不変であると識別される。
【００５３】
例えば図８等の差分表現では、輝度平面内の２つの画像、すなわち、座っている主体の人物を有する１つの画像と、その主体の人物が立ち上がって腕を広げている後続の画像との比較に基づいて、立ち上がったことの効果が明らかに認識可能である。座っている人物と腕を広げて立ち上がっている人物との双方が、この図において識別可能であり、その全体的なエリアが１８として示されている。
【００５４】
その結果、この画像変化は、関連部分が大幅に異なるので、マクロブロックごとに又は画像全体について自動的に検出可能でもある。このことが利用され、そのため、本発明によれば、スーパブロックは、マクロブロックに対して、必ずしもそうではないが場合によっては異なるエンティティとして定義される。
【００５５】
スーパブロック分解
したがって、関連のある変化を探索することが、本発明の１つの可能な実施形態では、画像をスーパブロックに分割することによって行われる。これらのブロックは、必ずしもそうではないが好ましくは、Ｈ．２６４、又は本発明が利用される際に用いられる他のアルゴリズム若しくはプロトコルによって用いられる任意のブロックアルゴリズムを包含するほど十分大きい。そのようなスーパブロックのサイズの１つの可能な選択肢は、３２×３２ピクセルであるが、それ以外のものに決定する理由が存在する場合もある。ほとんどの画像は、６４０×４８０、７６８×５７６又はそれよりも大きいので、スーパブロック２０×１５、２４×１８又はそれよりも大きなものが整数個だけ常に存在する。
【００５６】
しかしながら、本発明によれば、スーパブロックが互いに排他的である要件は存在せず、特定のピクセルは、２つ以上のスーパブロックにも存在することができ、また、１つの画像に整数個のスーパブロックを有する要件も存在しない。結局のところ、スーパブロックは、主として（本質的にはそうではない）、画像のどの部分を以前のフル画像、例えばＩ画像の一部分と置き換えることができるのかの検出にのみ用いられて、送信される情報の容量を削減し、したがって、その結果得られるビットストリームを圧縮する。計算及び処理を簡単にするために、フレーム又は画像ごとに整数個のスーパブロックを有するとともに、どの１つのピクセルも１つのスーパブロックにしか存在することができないという意味でのスーパブロックの相互排他性を有することが好ましい場合があることに留意されたい。
【００５７】
ここで、４：２：０サンプリングの場合、スーパブロックは、輝度平面では３２×３２ピクセルであり、彩度平面では１６×１６ピクセルであることに留意されたい。これらについては、特別な注意を払わなければならない。
【００５８】
輝度チャネル及び彩度チャネルにおける比較
ストリームからの任意の現在のフレームＣについて、最も近時に通過したフル画像又はフレーム（あるいは、Ｈ．２６４若しくはＸ．２６４又はＭＰＥＧ２若しくはＭＰＥＧ４等の従来の意味でのＩフレーム）が、基準画像として選ばれる。現在のＣ画像及び基準Ｉ画像の双方が、スーパブロックに分割され、それらのスーパブロックは、現在のフレーム又は画像内の各スーパブロックと最も近時に通過した未圧縮のフレーム又は画像内の対応するスーパブロックとについて、スーパブロック単位で比較される。「対応する」という表現は、最も近時のＩフレーム又はＩ画像内のスーパブロックと現在のＣフレーム又はＣ画像内のスーパブロックとが、これらの最も近時に通過したフルフレーム及び現在のフレームに従って描写されるシーン内のロケーションに関して対応していることを示すように意図されている。
【００５９】
スーパブロックが僅かにしか異なっていないことが判明した場合、現在のフレームＣ内のスーパブロックは、元の、すなわち通過したフルフレーム又はフル画像の対応するスーパブロックに置き換えられる。このサブプロセスは、あらゆるＤＣＴ圧縮又は動き補償の前に実行される。１つの同一のスーパブロックは、結果として、４つの同一のマクロブロックになり、Ｈ．２６４の動き補償は、最も近時のＩフレームのマクロブロックと現在の（後続の）フレームＣのマクロブロックとの間に大きな類似点を認識することになり、その結果、符号化が非常に効率的になり、したがって、最終的に生成されるデータストリームのデータの量が削減される。
【００６０】
この手法に起因して、データストリームが増加する可能性はないことに留意されたい。最悪の場合、生成されたデータストリームは、本発明による方法及びシステムを組み込まずに行ったのと同じ容量を有することになる。
【００６１】
図８と類似している図９のビューには、重要な移動が発生し、以下に説明するアルゴリズムを用いて検出されたスーパブロックが、これらのスーパブロックが輝度平面において差分に基づいて十分に「異なる」と認識されたので、組み合わせて輪郭で描かれている。このスーパブロック１９のセットは、図８の概略的な輪郭よりも詳細である。なぜならば、図８の表現は、図９のスーパブロック後の検出された輪郭１９ではなく、概略的で直観的な輪郭１８を示しているからである。これらは、現在の画像Ｃに保持されている、組み合わせたスーパブロック１９であり、他の全て（顕著な変化を有しない）は、最も近時の完全に通過したフレーム、特にＩフレームからのスーパブロックに置き換えられる。このＩフレーム２０が図１０に示されているか、又は少なくとも、関連のある現在のフレームＣにコピーされるＩフレームの一部分が図１０に示されている。図１０のこの画像における「ホール」２１は、図８及び図９に関して説明したように、関連のある移動が検出された、図９の差分画像におけるスーパブロック１９の輪郭と一致する。これらのスーパブロックは、画像内の人物が（非常に）素早く立ち上がったので異なるものと認識された。そのような非常に素早い変化は、画像シーケンス内の連続画像又は互いに接近した画像において発生する可能性は低いが、本発明を明らかにするために、この誇張は正当なものとみなされる。
【００６２】
上記に示したように、画像間の差分の検出は、この実施形態では、輝度平面における画像を比較することによって行われる。ここで、代替的に又は加えて、差分検出は、彩度平面に基づいて行うこともできるし、更には画像（の一部分）の一般的な統計的特性に基づいて行うこともできることに留意されたい。
【００６３】
１つの平面（輝度又は彩度）において画像の特定の箇所で比較を実行するとき、この比較が輝度の比較のみ又は彩度の比較のみに基づいて行われる場合、変化が直接隣接した画像間で発生したのか又はそれよりも遠隔の画像間で発生したのかを判定するのに、差分の対比が不十分な場合があることが指摘されてきた。したがって、本発明は、所望されかつ有用である場合には、これらの比較及び／又は他の任意の比較の双方を行う可能性も包含している。他の任意の比較は、統計的特性（ただし、これに限定されるものではない）等である。
【００６４】
次に、残りの課題は、現在のフレームからのスーパブロックが最後のＩフレームのスーパブロックと異なるか否かをどのように判断するのかである。
【００６５】
そのために、現在のフレームＣの（ｉ，ｊ）スーパブロックＳＣをＣｉ，ｊと定義し、最も近時のＩフレームのスーパブロックＳＩをＩｉ，ｊと定義することにする。さらに、尺度ｄ（ＳＰ，ＳＱ）を、スーパブロックのベクトル空間におけるスーパブロックＳＰとＳＱとの間の距離（差分）と定義することにする。スーパブロックは、以下の式が成立する場合に、同一であると定義される。
【数１】
2014509481.tif 000003
【００６６】
スーパブロックＣｉ，ｊ及びＩｉ，ｊが、この意味において同一である場合、フレームＣ内のスーパブロック（ｉ，ｊ）は、フレームＩ内のスーパブロック（ｉ，ｊ）に置き換えられることになる。
【００６７】
したがって、焦点は、閾値ｄ（ＳＰ，ＳＱ）の定義にある。この閾値を定義するのに、多くの種類（shapes）及び形態を用いることができ、全てが本発明の範囲内にある。以下では、可能な実施形態を説明する。この実施形態は、決して本発明の限定として提示されるものではない。スーパブロックＳの輝度ピクセルをＳ［Ｌ］ｎ，ｍと定義するものと仮定し、ここで、本ケースでは、３２×３２のスーパブロックサイズの場合、０≦ｎ＜３２及び０≦ｍ＜３２である。彩度ピクセルをＳ［Ｃｒ］ｎ，ｍ及びＳ［Ｃｂ］ｎ，ｍと定義し、ここで、４：２：０サンプリング方法の場合、０≦ｎ＜１６及び０≦ｍ＜１６である。各ピクセルＳｎ，ｍの（整数）値は、範囲０≦Ｓｎ，ｍ＜Ｖｍａｘ内にあり、ここで、Ｖｍａｘ＝２５６である。この場合、最適な関数（ｄ［２］）の更に緻密な近似における閾値ｄは、以下のように定義することができる。
【数２】
2014509481.tif 000004
式中、
ｘ≦−１の場合  Ｕ（ｘ)＝−１
１＜ｘ＜−１の場合  Ｕ（ｘ)＝０
ｘ≧１の場合  Ｕ（ｘ)＝１
であり、スーパブロックＳＰ，［ｘ］及びＳＱ，［ｘ］は、同じ（輝度又は彩度）平面ｘから選ばれる。これは常に当てはまり、そのため、以下では、平面を繰り返し識別しないことにする。
【００６８】
閾値を定義する最初の試験的試みにおいて、閾値尺度を輝度平面にのみ適用し、試験した後に値ｄｍａｘ＝２に設定した。この値は、最適な結果をもたらすものとみなされた。
【００６９】
この閾値は、受信機／プレイヤへのデータストリームのかなりの削減を試験することに既に提供されたが、受信機／プレイヤ側で再生された画像のシーケンスの著しい劣化はほとんどなかった。しかしながら、閾値に対するこの差分関数は、幾つかの不都合も示している。先ず最初に、高いコントラスト、例えば窓を通る日光を有する画像によって、多くのスーパブロックは、閾値を超え、送信される可能性がある。しかし、これらのスーパブロックは、実際には特別に問題となるものではない。これは、例えば、画像によるシーン内の反射面からの（ランダムな）光沢に起因している場合がある。さらに、この近似された閾値レベルにおいては、画像内の微妙で小さなコントラスト差は、真の差分と認識されなかった。
【００７０】
この閾値は、実際に用いられるカメラ及び他の状況にパラメータを調整することができるように、パラメータを有するより複雑な関数として規定することもできる。すなわち、ホワイトバランス及び雑音レベルが、差分関数及び／又は閾値の適切な選択に異なる効果を有することが分かった。本発明の更に洗練された可能な実施形態として、以下の差分関数を提案する。
【数３】
2014509481.tif 000005
式中、Ｂｌ及びＢｈは、光沢の効果を補償するパラメータである。したがって、この閾値関数は、光沢補償を含む。
【００７１】
この関数の試験から、実際に用いられるカメラ等の特定の状況についてであるが、照明状況等からの効果についても、妥当な値は、Ｂｌ＝１６及びＢｈ＝３２（他のカメラ、特にそれらのカメラのホワイトバランス及びそれらのカメラによって生成される雑音レベルに対して変化し得る）であることが判明した。この補正された差分関数は、線形関数であるが、カメラ及び／又は他の状況に応じて、二次補正を行うことが必要な場合もある。
【００７２】
上記に提供して説明した例におけるスーパブロックに関する計算は、輝度平面においてのみ行った。しかしながら、移動物体が色のみ異なる状況、又は主として色が異なる状況がある。したがって、本発明によれば、代替的に又は加えて、差分関数を計算し、それを彩度平面（複数の場合もある）の閾値と比較することも可能である。そのために、尺度ｄ［１］（特定の固定値）を用いることができる。このとき、チャネルのうちの１つが閾値ｄｍａｘを超えている場合、そのスーパブロックのみをそのままにしておき、その関連のあるスーパブロックを、以前の通過したフル画像（最も近時のＩフレーム）からの対応するスーパブロックと置き換えてはならない。
【００７３】
補正技法
一方、上記で説明したような光沢補正された差分関数は、シーンの照明のみが変化した場合に、ほとんど全てのスーパブロックが変化したように見えるが、現在の画像Ｃと先行する画像Ｉとの間には、実際に対象となることは何も起こっていないという性質を示す。同じことは、色バランスに当てはまる。カメラは、照明が変化すると、ホワイトバランスを自動的に変化させる傾向を有し、これは、更に、色バランスのシフトをもたらす場合がある。これは、例えば、天候が曇っているときに、非常に頻繁に起こる可能性がある。
【００７４】
そのような規則的な出来事が、画像を送信するビットレートの達成される削減又は所望の削減に影響を与えることを防止する対抗措置として、照明及び色バランスの正規化をここに提案する。この正規化は、スーパブロックごとに実行される。
【００７５】
最初に、以下のように、平均化された照明が計算される。
【数４】
2014509481.tif 000006
そのため、置き換えスーパブロックＳＮは、次のものとなる。
【数５】
2014509481.tif 000007
これによって、この式が、更に変更された閾値関数ｄ［３］において適用されると、以下の式が得られる。
【数６】
2014509481.tif 000008
そして、この式は、現在の画像内のスーパブロックを、最も近時のＩ画像からの対応するスーパブロックに置き換えることができるか否かを判定するのに用いることができる。このアルゴリズムは、輝度Ｌ平面及び彩度Ｃｒ平面、Ｃｂ平面に等しく用いることができる。
【００７６】
画像アーティファクト
画質について言えることは何か？  画像自体は、Ｈ．２６４以外の方法では処理されないので、Ｈ．２６４ビデオストリームに通常存在する全てのアーティファクトを予想することができる。しかしながら、画像の一部分をそれよりも以前の部分に置き換えることは、画像の歪として目に見える多くの効果をもたらす場合がある。これらは以下のものである。
−タイリング：スーパブロック境界上のエッジ効果、
−強いタイリング：隣接したスーパブロック間の色差分及び／又は輝度差分、
−ゴースト：欠陥のあるスーパブロックの置き換え。
【００７７】
実際に最初に関係するものは効果である。以前の画像からのスーパブロックが用いられ、現在のスーパブロックの全体的な輝度及び平均の色値にのみ補正され、それによって、基礎となるマクロブロックのＤＣＴに１つの係数しか導入されないようにする。通例、これで十分なはずであるが、特に近接したスーパブロックのエッジでは、照明状況におけるより高次の変動が可視的になる場合がある。これらの効果は、或る役割を常に果たすことになるが、パラメータの最適化及び調整によって削減することができる。また、Ｉ画像をリフレッシュするための短い周期を選択することが役立つ。
【００７８】
対照的に、そのような不都合は、必ずしも問題を提起するわけではないことに留意されたい。特に、本発明が、例えば監視カメラの状況で用いられる場合に、これらの効果は、画像の内容に何の影響もなく、概ね審美的であり、実際に真の不都合を形成しない。
【００７９】
しかしながら、上述した３つの効果のうちの最後のものは、より重大な問題であり、現在の画像Ｃ内のスーパブロックを、この置き換えが行われるべきでないＩフレームのスーパブロックに置き換えるアルゴリズムに起因している。
【００８０】
この場合、画像の一部分が欠落しているか又は正しくないように見える。これは、これらがユーザに関心のあるものであるときに特に痛手である。これは、ほとんどの場合、パラメータの正しくない調整の結果である。妥当な値を超えてビットストリームを圧縮するために、これらのパラメータが過度に厳密に設定される場合、現在の画像からの重要なスーパブロックが、それほど重要でないスーパブロックとともに、最も近時のＩ画像からの対応するスーパブロックに置き換えられる。閾値関数のパラメータのそのような調整は、ほとんどの場合、カメラのタイプに依存しているので、パラメータの調整は、注意して行わなければならない。慎重かつ適切に行うと、欠陥のあるスーパブロック置き換えをほとんど回避することが可能になるはずである。
【００８１】
例えば、画像のシーケンスの再生の際、パラメータが誤って設定されている場合、この効果が発生する場合がある。再生された画像には、正しくない（spurious）ブロックが存在する場合もあるし、他の映像には、物体の一部分、例えば、人物の腕（の一部分）、欠落が存在する場合さえある。これは、物体のそのような一部分がその周囲との高いコントラストを示していなかったときに発生する場合があり、色差検出はオフに切り替えられる。
【００８２】
発明の効果
測定結果及びストリームサイズ
先ず、Ａｘｉｓ２１００ネットワークカメラを用いた測定結果を示す。これらの測定は、通常の日光の条件下及び少ない日光の条件下で行った。少ない日光の状況では、より多くの雑音が発生し、そのため、その結果得られる画像は、通例、圧縮するのがより困難である。これに対処するために、カメラのフレームレートは、周辺光の量に依存するようにされている。少ない光の条件の場合、ほぼ１０フレーム／秒（ｆｐｓ）のフレームレートを選択することができ、通常の光の条件の場合、約１５ｆｐｓを選択することができる。変更される他の唯一のパラメータは、Ｂフレームの数である。画像のデジタル化のための量子化閾値等の他のパラメータは、デフォルト又は「工場出荷時の設定値（factory values）」に設定され、不変のままである。一般的な用途では、各Ｐ部分画像サイクル（後続のＰフレーム間のフレーム数に換算した周期）におけるＢフレームの数は、概ね２である。本発明の有用性を判断するために、極端な値、すなわち０及び４においても試験を行った。測定は約１分間行った。
【００８３】
実験結果Ｉ
第１のタイプのカメラ（Ａｘｉｓ２１００ネットワークカメラ）について、少ない日光の状況下、すなわち、１０ｆｐｓのフレームレートにおいて、先ず本発明を適用せずに基準用に性能を測定し、以下の結果を得た。
標準規格Ｘ．２６４、＃Ｂフレーム＝０の場合、１６５ＫＢ／ｓ
標準規格Ｘ．２６４、＃Ｂフレーム＝４の場合、１１６ＫＢ／ｓ
【００８４】
その後、本発明について同じ実験及び測定を行い、以下の結果を得た。
本発明を用いたＸ．２６４、＃Ｂフレーム＝０の場合、５５ＫＢ／ｓ
本発明を用いたＸ．２６４、＃Ｂフレーム＝４の場合、４５ＫＢ／ｓ
【００８５】
そこで、少ない光の条件場合、Ｂフレームが存在しないときは、１６５ＫＢ／ｓから５５ＫＢ／ｓへのビットストリームサイズの削減（削減６６％又は３．０倍の利得）があることが分かり、１つのＰフレーム当たり４つのＢフレームがあるときは、１１６ＫＢ／ｓから４５ＫＢ／ｓへのビットストリームサイズの削減（削減６１％又は２．６倍の利得）があることが分かる。
【００８６】
この同じ第１のタイプのカメラ（Ａｘｉｓ２１００ネットワークカメラ）について、通常の日光の状況下での１５ｆｐｓにおける測定結果は、以下のとおりである。
標準規格Ｘ．２６４、＃Ｂフレーム＝０の場合、１１８ＫＢ／ｓ
標準規格Ｘ．２６４、＃Ｂフレーム＝４の場合、７５ＫＢ／ｓ
一方、本発明を用いると、得られた結果は、以下のとおりである。
本発明を用いたＸ．２６４、＃Ｂフレーム＝０の場合、５１ＫＢ／ｓ
本発明を用いたＸ．２６４、＃Ｂフレーム＝４の場合、３５ＫＢ／ｓ
【００８７】
通常の照明条件では、Ｂフレームが存在しないとき（＃Ｂフレーム＝０）、１１８ＫＢ／ｓから５１ＫＢ／ｓへのビットストリームサイズの削減が達成され、これは、５７％の削減又は２．３倍の利得を構成し、１つのＰフレーム当たり４つのＢフレームを有する場合には、７５ＫＢ／ｓから３５ＫＢ／ｓへのビットストリームサイズの削減（削減５３％又は２．１倍の利得）が達成される。
【００８８】
本発明の更なる調整が可能であると考えられるが、所望の用途、並びに上述したアルゴリズムに基づいて送信されたビットストリームの再生時における、結果の画質及び信頼性に大きく依存する。それにもかかわらず、本発明を用いると、１つのＰフレーム当たり４つのＢフレームを有する場合には、ビットレートを２３．５ＫＢ／ｓもの低いビットレートに削減すること（削減６９％又は３．２倍の利得）が可能であるように思われたことは注目に値する。しかしながら、これらの設定については、画質が依然としてその用途について当面許容可能であるか否かを判断することが必要である。
【００８９】
実験結果ＩＩ
同様の結果が、第２のタイプのカメラ（Ａｘｉｓ２１３ネットワークカメラ）を用いた測定から得られる。この測定は、通常の日光の状況下で行った。この第２のタイプのカメラの画像サイズは、第１のタイプのカメラ（Ａｘｉｓ２１００）の画像サイズよりも大きいので、記録するＰＣが動作し続けることができるように、フレームレートを最初に強制的に低くした。しかしながら、ここに示す測定結果は、全て相対的な特性を有するので、このことは、これらの結果の解釈を実際に変更するものではない。
Ａｘｉｓ２１３、通常の日光の状況、５ｆｐｓ：
標準規格Ｘ．２６４、＃Ｂフレーム＝０の場合、９７ＫＢ／ｓ
標準規格Ｘ．２６４、＃Ｂフレーム＝４の場合、７８ＫＢ／ｓ
しかし、本発明を適用すると：
本発明を用いたＸ．２６４、＃Ｂフレーム＝０の場合、４４ＫＢ／ｓ
本発明を用いたＸ．２６４、＃Ｂフレーム＝４の場合、２２ＫＢ／ｓ
【００９０】
Ｂフレームが存在しないとき、９７ＫＢ／ｓから４４ＫＢ／ｓへのビットストリームサイズの削減（削減５５％又は２．２倍の利得）が達成され、１つのＰフレーム当たり４つのＢフレームがあるとき、７８ＫＢ／ｓから２２ＫＢ／ｓへのビットストリームサイズの削減（削減７２％又は３．５倍の利得）が達成される。これらの数字を、Ａｘｉｓ２１００を用いて得られた数字と比較した場合、Ｂフレーム（Ｂ＞０）を利用するとき、利得がより大きくなることが分かる。この理由は、送信に必要とされるビットレートの削減は、シーン及び存在する雑音に大きく依存するからである。Ａｘｉｓ２１３は、より優れたカメラであり、雑音がより少なく、ホワイトバランスがより安定しており、画像におけるシーンは、Ａｘｉｓ２１００ネットワークカメラを用いて本発明を試験するために用いられるシーンと比較して、より簡単に比較されていた可能性がある。
【００９１】
また、ＤＳＢＭの更なる調整がこの状況において可能であり、１つのＰフレーム当たり４つのＢフレームを有する場合に、ビットレートを１３．８ＫＢ／ｓもの低いビットレートに削減すること（削減８２％又は５．６倍の利得）が可能であることが判明した。しかしながら、これらの設定については、画質が依然としてその用途について当面許容可能であるか否かを判断することが必要である。
【００９２】
更なる比較のために、ここで、Ａｘｉｓ２１３ネットワークカメラは、ＡＶＣプロトコルなしではあるが、ＭＰＥＧ４ストリームを生成する可能性も提供することに留意されたい。５ｆｐｓの現在の設定及び上記で用いたものと同じ解像度を用いると、このストリームは、４６ＫＢ／ｓで進み続ける。しかしながら、これが最良の直接的な結果であると仮定すると、本発明が適用されたＨ．２６４の最良の結果は、依然としてＭＰＥＧ４ストリームよりも３．３倍優れている。
【００９３】
画質の感動を与えるために、より極端な状況についての測定結果が取得されており、したがって、それらの測定結果は比較することができる。
【００９４】
実装
本発明による方法及びシステムは、幾つかの方法で実装することができる。上記で議論したように、プレイヤ／受信機も備えるシステムの画像記録側、厳密に言えば送信機のみが、変更を受ける必要がある。Ｈ．２６４を処理することが可能ないずれのプレイヤ（受信機）も、本発明に従って構築されると、受信した画像ストリームを復号化することができることになる。記録側すなわち送信機側には、この新しい技法を実装する幾つかの選択肢がある。
【００９５】
最も単純な方法は、Ｈ．２６４を用いて画像ストリームを符号化するのに用いられるソフトウェアを適合させることである。自由にプログラム可能であり、Ｈ．２６４について符号化することができるいずれのデバイスも、本発明に必要な追加の命令を実行することが可能である。もちろん、そのモジュール自体が、ソフトウェアを幾分より大きくし、それ自体の一部のＲＡＭを消費することになるが、Ｈ．２６４自体の実装と比較すると、そのようないずれの増加も軽微であることが分かる。例えば、Ｈ．２６４が実装されたＡＲＭ９（ＭＣＵである）は、本発明も同様に実行することができる。
【００９６】
Ｈ．２６４がＦＰＧＡ内に実装されるとともに、ユーザがＶＨＤＬ又はＶｅｒｉｌｏｇのソースにアクセスすることができる限りにおいて、本発明を組み込むようにこれらを変更することができる。幾つかの余分のメモリが、画像処理に必要とされる場合があるが、必要量は多くなく、カメラのハードウェア又は接続されたプロセッサに既に存在する可能性がある。
【００９７】
最後に、幾つかの状況では、Ｈ．２６４符号化を実行する専用のクローズドチップ（closed chip）のみが利用可能である。そのようなチップは、ベア（bare）画像信号を必要とし、「他方の側」でＨ．２６４符号化ストリームを生成する。この場合、その専用チップと次のような前処理を行うプリプロセッサとの間でＩフレーム、Ｐフレーム及びＢフレームの選択を同期させることが可能である場合には、この専用チップに送信される画像のシーケンスを前処理することによって、依然として、本発明を実施することができる。
【００９８】
本発明は、現在のＨ．２６４技術又は他の任意の差分ベースの従来技術と比較して、より効率的な圧縮を可能にする。現在、主要な適用分野は監視カメラである。この分野（ただし、事実上、可能であれば他の使用分野（本発明はＨ．２６４に限定されるものではない）でも同様である）では、本発明（上記の本明細書では、差分スーパブロックマスキングＤＳＢＭと呼ばれることもある）は、特に良好な結果を与え、標準規格Ｈ．２６４圧縮アルゴリズムに「アドオン」として実装することができる。
【００９９】
本発明は、本明細書において、Ｈ．２６４プロトコル仕様とともに一実施形態で開示されている。なお、本発明は、このＨ．２６４プロトコル仕様にも同様に限定されるものではない。したがって、標準規格Ｈ．２６４の画像ストリーム（又は同等のプロトコル若しくは仕様に従った同様の画像ストリーム）を表示することが可能ないずれの復号器も、本発明による変更されたストリームを表示することが可能になる。したがって、受信側において適合を行う必要はない。
【０１００】
例示のコード
上記の方法は、ＶＬＣコード（ビデオＬＡＮ  ＶＬＣメディアプレイヤ）で実装されている。以下に、試験、補正及びスーパブロックの置き換えを行うルーチンを列挙している。このコードは、生成コードではなく、単に一例としての役割を果たしているにすぎない。このコードを、ＶＬＣコード自体によって用いられるＸ．２６４ライブラリに統合することは、本発明のこの開示内容には提供されていない。なぜならば、これは、多くの要素に依存する場合があり、これらの要素は、そのような関連のある要素の範囲内で目的を達成するために、当業者の十分手の届く範囲内にあるからである。
【数７Ａ】
2014509481.tif 000009
【数７Ｂ】
2014509481.tif 000010
【数７Ｃ】
2014509481.tif 000011
【図１】
2014509481.tif 000012
【図２】
2014509481.tif 000013
【図３】
2014509481.tif 000014
【図４】
2014509481.tif 000015
【図５】
2014509481.tif 000016
【図６】
2014509481.tif 000017
【図７】
2014509481.tif 000018
【図８】
2014509481.tif 000019
【図９】
2014509481.tif 000020
【図１０】
2014509481.tif 000021
【国際調査報告】
2014509481.tif 000022
2014509481.tif 000023