動画像に対する動き解析/推定
--- 画像の各部がどの程度動いているのかを検出する技術
---
次の画像は，テスト動画像”フラワーガーデン”の第1および第2フレームです．
以下，
マークのついた画像は動画像です．画像をクリックすると
動画として御覧頂けます．
(a) フラワーガーデン第1フレーム |
(b) フラワーガーデン第2フレーム |
両フレーム間の各部の動きは比較的小さなものですが，良く見ると，
手前の幹が左側に移動すると共に，背景の花壇や家なども
僅かに左側に移動しています．いま，
- 第1フレームと第2フレーム間の各部の動きを求める
（動き推定）．
- 第1フレームの各部を対応する動き分だけシフトする
（動き補償）．
という処理により，第1フレームから第2フレームの
予測画像 を作ることができます．次の左側の画像(c)がこうして作った予測画像です．
では，この予測画像はどの程度正確なのでしょうか？
それは，原画像(b)と予測 画像(c)の差をとってみれば判ります．(d)が両者の差です．幹の両端など
隠れている部分が表に出たり，逆に表に出ている部分が隠れたりすると
予測は困難となり，誤差は大きくなります．しかし，まあまあ満足のいく予測画像が
得られています．
(c) 第2フレームの予測画像 |
(d) (b)と(c)の差分（予測誤差） |
ところで，動画像を符号化する際の最も簡単な手法は，(a)，(b)のような連続する
2枚のフレームをそれぞれ静止画像として単独に符号化するものです．しかし，MPEGな
どではさらに効率の良い手法が用いられています．それは，
- 最初のフレームのみ，静止画像として符号化する
- 直前のフレームを参照して，対象フレームの各部の動きを
表す動きパラメータ求める （動き推定）．
- 直前のフレームの各部を求めた動きの分だけシフトし，対象フレームの
予測画像を求める（動き補償）．
- 符号化対象フレームと予測画像の差分画像を求める．
- 差分画像を静止画像として符号化する．
という手順です．これを 「動き補償に基づく予測符号化」 等と呼びます．このような手法を用いる理由は簡単で，
となり，動きパラメータと差分画像を符号化する方がデータ量が小さく済むからです．
画像の各部の動きを求める手法 --- 動き推定 --- の 最大の応用分野は，このような 動画像の符号化 です．
では，実際には「動き推定」は，どのように実行されるのでしょうか？
あまり凝った「動き推定」を行なうと，
- 推定に要する計算時間/計算量が膨大となり，実用性が失われる．
- 動きパラメータ量が増え過ぎ，せっかくの利点が失われる．
ことにもなりかねませんから注意が必要です．そこで，MPEGなどでは，
ブロックマッチングという単純なアルゴリズムが 用いられています．
ブロックマッチングは，
- 画像内の動きは，ほぼ「並行移動」として近似できると仮定する．
- 画像を適当なサブブロックに分割し，サブブロック単位で並行移動分を求める
というアルゴリズムです．具体的手順は次のようになります．(f)は動きパラメータ
を求める対象フレーム，(e)はその前のフレームです．
- 対象フレームを適当なサブブロックに分割する．MPEGでは，縦×横＝16×16の
ブロックが用いられます．
- 一つのブロックに着目し，これを前フレーム(e)上でスライドさせて，最も
よくマッチする部分を捜し出す．実際には，ブロック間の 距離関 数を定義し，この距離が最小になるブロックを見つけます．通常，距離には，
絶対値誤差や2乗誤差が用いられます．
- 前フレーム上での対象ブロックのシフト量をベクトルとして求める．
これを 「動きベクトル（MV）」と呼びます．
- 対象フレーム上のすべてのブロックに対するMVを求める．
一方，動き補償により予測画像を作成する手順も単純で，対象フレームのMVに従って
前フレーム上のブロックを切り出し，予測画像上に張り付けるだけです．
下の(g)は，このようなブロックマッチングによって求めた(b)の
フラワーガーデン第2フレームの動きベクトル場です．
(g) フラワーガーデン第2フレームの動きベクトル(MV)場
さて，ここからが我々の研究の中心部分です．MPEGなどの画像では，上図(g)の
ような動きベクトル場を各フレームが持っていますが，これは，
符号化のためだけではなく， 他の応用にも非常に便利なデータ と考えられます．例えば，
- 画像中から動いている部分のみを切り出す．一種の
セグメンテーション です．
- 動き量に応じて画像を検索する ．「背景が静止で中心部分が人が左側に動いている場面を探す」などです．
- 画面内の物体の運動解析を行なう．移動速度や方向を計算するなど．
です．しかしながら，
ブロックマッチングで得られた動きベクトル（MV）は，本当に各部の動きを正確に
表しているのでしょうか？？？？？
答えはノーです．それは，
ブロックマッチングは，対象フレームと予測フレーム間の誤差を最小とす
る（時間方向の相関を最も良く除去する）ベクトルを求めるアルゴリズムであって，
このベクトルが各部の動きに対応するとは限らない．
からです．実際，上図(g)の動きベクトル場では，特に
- ブロック内がフラットで輝度変換が乏しい場合．前フレーム上のどこにでも
マッチングするため，正確な動きは求まらない．
- ブロックが単一のエッジのみを含む場合，このエッジに並行な動きは求められな
い．
等の問題のため，実際の動きとは異なったベクトルが検出されています．この
ベクトルを符号化に応用する場合にはこれで問題はないのですが，上に示した
画像検索やセグメンテーションに用いる場合には誤差の原因となり，好ましくありま
せん．
そこで，我々は，
-
符号化の効率を大きく損なうことなく
-
極力実際の各部を反映させた「動きベクトル」を検出する手法
を研究しています．(h)は，当研究室で研究したアルゴリズムによって
求めた(b)のフレームに対する動きベクトル場です．(g)に比べ，「暴れている」動き
ベクトルが減少し，全体として 精度とコヒーレンスの高い 動きベクトル場が 得られています．また，(i)は，他の動画像---特に動きベクトル が「暴れる」原因となるフラットな部分の多い画像---
に対して同じ手法を適 用した結果です．(j)の従来のブロックマッチングの結果と比べ，全体の精度が改善さ
れています．しかも，MPEGに用いた場合， 提案法の(i)の方が効率が良い のです（理由は，動きベク トルを符号化する符号量が減少するからです）．
(h) 提案法によるフラワーガーデン第2フレームの動きベクトル場
(i) 提案法 |
(j) 従来のブロックマッチング法 |
我々は，提案手法を用いて動画像をMPEGエンコードすることにより精度の高い
動きベクトル場が得られるため，これ を 動画像検索に応用しています．
提案法で用いている手法等，詳細については，発表文献を御参照下さい．
