Computer Vision System Toolbox(以下CVST)のMSERについて思ったことがあるのでだらだらと。
まず、MatlabのdetectMSERFeaturesはOpenCVの実装よりも、引数として与えるパラメータの数が少ない。 VLfeat（http://www.vlfeat.org/matlab/vl_mser.html）の引数と比べ、説明をよんでも、どうして減らしたのかよく分からない。たぶん、MinDiversityは関数の使いやすさ重視のために消えたのだろう。内部処理でなんかうまいことやっているのかな。detectMSERFeaturesの出力として、MSER用のオブジェクトが用意されている。中身を除いてみると、わかりやすい構造にはなっている。
ひとつの物体のみを撮影した256x256の画像でも、パラメータを調整すれば250点以上検出できる（テクスチャがあれば）。結果を比較してみてわかるのは、VLfeatの表記でいうところのdark-on-bright, bright-on-darkで検出される領域の両方を、detecMSERFeaturesは出力しているみたい。CVSTのdetectMSERではVLfeatのように引数でどちらかを指定することはできない（まあ、必要ないか）。
Distinguished Region(DR)の検出、transform covariant な特徴量の記述、そして得られた特徴同士のマッチング方法はそれぞれ分けて考え、適切なものを使用する方がよさげ。しかし、CVSTはaffine covariantな領域を抽出しているのに、extractFeature関数で得られるMSERsの特徴記述子はSURFのものとなっている（http://www.mathworks.co.jp/jp/help/vision/ref/extractfeatures.html）。特徴記述もaffine covariantなものを用意しないと意味ないよね。
DRを検出したら楕円フィッティングして、楕円領域を正円に正規化、明るさも正規化, そして極座標表示にしたのちFFTかけて虚部だけ使えば、それぞれの処理が拡大縮小+剪断変換, 照度変化、そして回転に不変な特徴記述を与える。SIFT, SURFの記述子の方がマッチングの計算が速いっていやぁ、まあそんなのかもしれない。CVSTにはこの処理を行う関数は用意されていないようだが、このくらいの処理、自分で実装しろってことなのかな。
detectHogeFeautres → extractFeatures → estimateGeometricTransformという順番で処理すれば、簡単に画像間の変換が求められるというのは便利(Hogeの部分にはFAST,BRISK,HOG,SURF,MSERなどが該当)。esimateGeometricTransformには、similarity, affine, projectiveのいずれかを画像間の変換のモデルとして指定できる。線型レジストレーションはこれでらくしょーですな（例はこのページ: http://www.mathworks.co.jp/jp/help/vision/examples/find-image-rotation-and-scale-using-automated-feature-matching.html）。
でも、affine変換と射影変換の推定可能な関数があるのに、画像間の対応点探索のためのaffine covariantな特徴記述子が実装されていないという罠。これでは自動的に処理するのは無理ですな。上述のMathWorksの例にしたって、回転と拡大縮小しか扱っていない。ランドマークベースのレジストレーションで、適切なランドマークの与え方がわかっていない、という状況に似ている。
追記 7/18
dark-on-bright と bright-on-darkがほぼ同じ領域を検出している場合、数だけみれば局所特徴量を多くとれているような気がするが、マッチングを考えると無意味。どちらか片方を検出するような引数は実装してほしかった(VLfeatでいいじゃん、もう・・・)。こんな状態でSURFの記述子つかってマッチングしたところで、結果は怪しいものだな。マッチングから幾何学的変換の推定までを丸っと書き直した。M-estimator sample consensus 使うなら、exactなマッチングなんていらんだろうに。
まあ、DRの中心および長軸・短軸がある基準で一致したらマージ、という処理を加えればいいのだけれど。
追記 7/22
なるべくexactなマッチングが出来る方が, やっぱりうれしいです。
