2014年4月29日火曜日

回路を学ぶ 電流・電圧・抵抗・電力 の基礎

CPUを自作するために、電気回路を学ぶ。

電流とか電圧、中学校の時依頼だったかな。。。


I (電流) = E (電圧) / R (抵抗)

P (電力) = I (電流) x E (電圧)

2014年4月27日日曜日

OpenCVは64bit版を使おう

OpenCV は 32 bit 、64 bit どちらのアプリケーションを作ることもできる。

WEBで情報を見ると、32 bit版を使いましょう。という文章をよく見かけるが、これからは64bit版を使おう。

必ずそうということでは無くて、やりたい処理によるということ。

1枚の画像を加工するだけなら、32bit版で良い。

複数の画像を処理する物体認識なら、64bit版で無いと大きなデータは扱えない。

というのも、32 bit版だと使用できるメモリ容量が制限されてしまうからだ。

さらに、大量のデータだと一度で倍処理出来るのは大きい。


VS2012であれば、構成マネージャーの名前を x64 に変更するこで 64 bit 版のビルドが可能。

後は、OpenCVの64bit版 dll , lib を使用すればよい。

メモリ制限の問題で悩んでいたけど、大したことなかった。

32bit CPU のモバイルで動作させたいときは、そのたびにコンパイルするしかないか、と今は考えている。


2014年4月26日土曜日

OpenCVを使って一般物体認識エンジンを作成する

画像中の物体のクラスを認識する処理を、一般物体認識という。

一方、同インスタンスを認識する処理を特定物体認識という。

画像の feature や 機械学習手法をある程度勉強すれば、OpenCVを用いてどちらの識別器をつくることも可能だ。

今回は、一般物体認識の識別器をつくる方法をまとめる。

以下の準備が必要だ。

1.画像の収集
2.環境の準備
3.訓練
4.検証

順に、はまった点なども含めて記載していこうと思う。

1.画像の収集

認識したいクラスの画像(正事例)を少なくとも 3000 枚程度集める。
(例えば車を横からとらえた画像であれば、様々な種類の車、撮影角度、明るい、暗い、などの条件で収集する。)

これは Microsoft のBING APIを使うと、無料で5000回のリクエストを投げることが出来るので、便利だ。

画像を集めたら、画像中からクラスを表す部分を出来るだけ正確に抜き出す。
出来るだけ認識したい部分だけを、欠けること無く切りだすと良い。

また、認識したクラス以外の画像(負事例)もたくさんあつめる。少なくとも正事例画像の半分は集めること。
また、正事例として切り出した画像の倍程度の解像度で使用することを前提に切り出すと良い。


画像を切り出したら、学習に必要なファイルを作成する。
正事例と負事例では、異なるフォーマットのファイルが必要だ。

正事例

以下のフォーマットでsamplesファイルを作成しておく。

[画像ファイルへのパス] [N(画像中の物体の個数)] [クラスを囲む矩形の左上座標x] [クラスを囲む矩形の左上座標y] [width] [height] …N回繰り返し

(画像枚数分の行)

ex)
./positive/img.jpg 2 110 150 45 45  40 30 20 20

これは画像が切り出せていれば簡単なプログラムで出力すれば良いだろう。

負事例

正事例と違い、クラスを囲む矩形の矩形の情報はいらない。以下のフォーマットとなる。

[画像ファイルへのパス]
ex)
./negative/img.jpg

以上で、訓練画像の実体とそれらを示す samples ファイルが出来た。



2.環境の準備


OpenCV環境を使用する。

Androidで動作させたい場合は、OpenCV 2.4.1 までを使用すれば、OpenCV Manager をインストールする必要はない。(その変わりアプリサイズは大きくなる)
用途に合わせてバージョンを選択すれば良いだろう。

今回は、OpenCV Managerを使わずに、iPhone、Android端末上で動作させたかったので、
OpenCV 2.4.1 を使用した。

Windows環境を前提とする。

OpenCVの公式サイトからダウンロードする。

訓練環境はWindowsで作成する。
・Windows
以下から、2.4.1を選ぼう。

http://opencv.org/downloads.html


Androidに搭載したいので、以下をダウンロードしておく。
(Android開発環境ADTは構築済みとする)
・Android
http://sourceforge.net/projects/opencvlibrary/files/opencv-android/2.4.1/


OpenCVをビルドする

まずは、OpenCVをビルドする。RAMを贅沢に使える環境が増えているので、32bit版を使用していても 1 GB制限を外したいことが主な理由だが、ソースコードを書き換えて使う場合、ビルドは必須だ。

CMakeのダウンロードと使い方。

CMakeをダウンロードする。
http://www.cmake.org/

CMakeを使って、OpenCVのコードをvisualstudioのプロジェクトファイルを作成する。

以下が詳しくてありがたい。(3つ)
  • http://cvwww.ee.ous.ac.jp/oc20inst.html
  • http://ameblo.jp/banquet-of-merry-widow/entry-11105368931.html
  • http://blogs.yahoo.co.jp/nobuyuki_tsukasa/2803954.html
visualstudioのプロジェクトファイルが出来たら、開けばソースからビルド出来る。
(割りと時間がかかる。)

x32のOpenCVを使った方がはまりづらいが、RAM使用量の制限がうざい。
解除するには以下のサイトが参考になる。
http://d.hatena.ne.jp/manji602/20111214/1323834770


次に、学習用のプロジェクトをビルド使用。moduleに含まれている。

visualstudioを使ったが、インクルードするディレクトリなどは、mkファイルを参照しながら
追加した。
※以下は、opencv241_winにOpenCV2.4.1のソースを展開した前提。

○haartraining opencv visual studio(VC++)
○createsamples opencv visual studio(VC++)

・インクルードディレクトリ
C:\opencv241_win\build\include;C:\opencv241_win\build\include\opencv;C:\opencv241_win\build\include\opencv2;

・ライブラリディレクトリ
C:\opencv241_win\build\x86\vc10\lib;C:\opencv241_win\build\common\tbb\intel64\vc10;

opencv_imgproc241.lib;opencv_highgui241.lib;opencv_features2d241.lib;opencv_objdetect241.lib;opencv_calib3d241.lib;opencv_core241.lib;


○traincascade opencv visual studio(VC++)
・インクルードディレクトリ
C:\opencv241_win\build\include;C:\opencv241_win\build\include\opencv;C:\opencv241_win\build\include\opencv2;

・ライブラリディレクトリ
C:\opencv241_win\build\common\tbb\ia32\vc10;C:\opencv241_win\build\x86\vc10\lib;

opencv_core opencv_ml opencv_imgproc opencv_objdetect opencv_highgui opencv_calib3d opencv_video opencv_features2d opencv_flann opencv_legacy

・ライブラリ
opencv_imgproc241.lib;opencv_highgui241.lib;opencv_features2d241.lib;opencv_objdetect241.lib;opencv_calib3d241.lib;opencv_core241.lib;opencv_flann241.lib;opencv_contrib241.lib;opencv_ml241.lib;opencv_video241.lib;opencv_legacy241.lib


VC++のうざい警告が出るので、以下でやめさせる。

指定した警告を無視するで以下を指定。
4290;4996

また、デバッグビルドだとうまく動作せず、以下のエラーが出た。
http://grayhole.blogspot.jp/2012/04/isctypec-expression-unsignedc-1-256.html

リリースビルドだと動作したのでとりあえず放置。


学習用正事例サンプルの作成


正事例データを作成するために、createsampleプロジェクトを使用する。

createsamplesの使い方


> createsamples.exe -info samples.txt -vec ./positives/vec/positive_samples.vec -num 2 -h 10 -w 10

samples.txtは1の②で作成したファイルを使用する。


・h, wは 10~50 が良いらしい


作成されたsamplesの確認方法


> createsamples.exe -vec ./positives/vec/positive_samples.vec -w 10 -h 10

・h, wは 作成時の値を指定する


学習

createsamplesの出力したvecファイルを正事例用に使用する。

①haartrainingを使用する。
1世代前の学習。Haar-like特徴のみ使用できる。
②traincascadeを使用する。
最新の学習プログラム。以下のアルゴリズムを指定できる。
Haar-like
HOG
LBP

②のほうが新しく書き直されたもので、①も含むので基本②を使えば良い。
というか、②しか使ったことが無い。

traincascade

重要なパラメータは以下。


  • data:出力先ディレクトリ(つくってくれないので、事前につくっておくこと)
  • vec:positiveサンプルのvecファイル
  • bg:negativeサンプルのリストファイル
  • numPos:採用するポジティブサンプルの数
  • numNeg:採用するネガティブサンプルの数
  • numStages:AdaBoostステージ数
  • w:横(positive vecに合わせる)
  • h:縦(positive vecに合わせる)
  • min_hit_rate:各ステージの最少ヒット率
  • maxFalseAlarmRate:半分を超えない識別機は意味がないので排除する
  • bgcolor:認識したい物体の背景に多い輝度を指定(または認識したい物体と遠い輝度)



訓練が成功すると学習結果が出来上がる。
辞書がうまく成長しない場合、以下をチェックする。


  • 正事例数
  • 負事例数
  • 正事例と負事例の解像度比
  • 特徴量
  • ステージ数


AndroidでOpenCVを使う

CDTは入れておこう!
EclipseのNew Software Instoreから入れる。
nativeのソースをコンパイルしたいので、windows用OpenCVのlibsにあるlibとdllを指定する。
デフォルトだと以下、OpenCVをローカルでビルドした場合、build先のディレクトリにする。
各種lib → [OpenCV展開ディレクトリ]\build\x86\vc10\lib
各種dll → [OpenCV展開ディレクトリ]\build\x86\vc10\bin


NDKもダウンロードしておこう!
ダウンロードして、好きな場所に展開したら、
NDKの場所をEclipseに設定出来るので、ディレクトリを設定する。
さらに、ndkのビルドをwindows用のコマンドに変更する。

SurfaceViewは理解しておこう!
http://qiita.com/croquette0212/items/24dc2b6de3730e831aab


CDTでインクルードに成功し、追加ライブライを追加できたら、Android.mkファイルを手直しする必要があるかもしれない。
必要であれば、mkファイルでインクルードするOpenCVのライブラリの場所を、ローカルのOpenCVのパスに変更する。

2014年4月16日水曜日

Windows開発環境に入れておきたいアプリケーション


Windowsのエクスプローラはショートカットをまとめても結構使いづらいものです。
たくさんのWindowを開くのも、ノートPCなどスペースが限られていると面倒です。
そんな場合は、以下のソフトを入れるとスペースもすっきりして良いです。

お気に入りも Chrome like に管理・アクセスできます。
  • Clover 3 http://ejie.me/ :エクスプローラにChrome風のタブを追加するソフトウェア

Windowsだと、環境変数の設定も昔から不便です。
編集画面にたどり着くためのステップが多いだけでなく、編集用テキストフィールドが狭かったり、セパレータを自分で記述する必要があったりと面倒です。
以下が便利です。GUIでエクスプローラ式に環境変数を設定・管理できます。

コマンドを充実させる人も多いようですが、私の場合は Cygwin か cmd.exe で今のところ不便は感じていないので、上記だけでもけっこうスムースに作業が出来ます。

2014年4月8日火曜日

Fast Color-Based Object Recognition Independent Of Position and Orientation from Giessen and Schmidhuber セクション4以降 論文翻訳修行

Fast Color-Based Object Recognition Independent Of Position and Orientation from Giessen and Schmidhuber の翻訳後編。

論文の信頼性を確認する方法を教わった。

まず、査読されているか(査読が必要なジャーナルに投稿されたかどうか)。
また、簡単に通らない査読かどうか(信頼のおけるジャーナルかどうか)を確認する。

今回翻訳した論部は、SpringerのLNCSというシリーズのもの。

信頼のおける論文であれば、Abstructを読んで、Introduction、Conclusion、Figure の順で確認し、必要な論文か確かめる。

それでは、後半の実験結果についての翻訳。

この過程で、画像認識でよく使われる実験サンプルを手に入れた。

4. Experimental Results 実験結果


4.1 ZuBuD Building Database(Zurich Building Image Database)

http://www.vision.ee.ethz.ch/showroom/zubud/index.en.html

私たちは、特別な簡素化処理を行わない、320×240にリサンプリングした実世界の画像で
構成されたデータベースを使って、認識精度とスピードをテストしました。
私たちははじめ、ZuBuDデータベースを使いました。チューリッヒにある201のビルの
1005枚の写真を含んでいます。外から様々な気象条件の下で撮影されたものです。
DBは115枚のクエリ画像(画質の低いjpegで、320×240ピクセルにリサンプリングしています)
全てのクエリ画像で、私たちのアルゴリズムでマッチした 5 位までをリストしました。
画質の低いクエリ画像にも関わらず、82画像で正解し、29画像で5位に入り、4画像で
5位に入らなかった。
クエリ画像内の色情報は、クエリ画像とDB画像から同じ建物の画像をとってきて並べた図2を
見て明確にみられるように、非常に低品質です。
この信頼できる色情報の欠如は、正しい認識を妨げます。
図3の最初の行にあるクエリ画像は、私たちのアルゴリズムが例えば木のような障害物に
鈍感であることがわかります。
我々は、(小型モバイルロボットで簡単に動く)高品質の画像上でのパフォーマンスを
テストするために、201オブジェクトのそれぞれ4つの画像を使って新しいDBを構築しました。
私たちは、クエリ画像としてすべてのオブジェクトの5番目の画像を使用しました。

改善された画質は大きな認識率向上につながりました。
201のうち、正解:183、13個が5位に含まれる、5個が5位以内に入りませんでした。
図3の2行目は私たちのアルゴリズムの位置や方向に依存していないことがわかります。

5つの失敗と5位までのいくつかの完全でない結果の理由は、2つあると考えられます。
一つ目の理由は、DBとQeuryもしくはどちらか一方が主に保持する領域の彩度が非常に低いです。
二つ目の理由は、クエリ画像のいくつかは、オブジェクトのごく一部だけしか含まないことです。
図3の最後の行は、彩度がとても低いために失敗した1例です。
適応型リカレントニューラルネットワークのSVSを搭載した学習ロボットの場合、これらのミスは
大きな問題を提起しません。


4.2 Coil-100 Object Database

私たちの方法は、ZuBuDデータベースでを専門にしていません。
広く適用適用可能なように設計されています。
私たちはほとんどのパラメータをチューニングしていません。ただ一つ、3.1 の閾値を
物体認識処理を高速化するために可能な限り小さく選択しなければなりません。
メソッドの一般性を示すために、100個の物体をさまざまな角度から撮影したCoil-100データベースに
適応しました。
私たちは、0度, 100度, 215度, 270度, 325度 のアングルで撮影した画像をデータベースに配置し、
25度のアングルの画像をクエリとして使いました。
84個物体認識出来、12個が5位までに入りました。4つが5位圏外でした。
認識に失敗した画像は、様々なグレーを主に含み、少ない色情報は破棄されました。

4.3 パフォーマンス速度

私たちはPentium 4 (2.8GHz) 計算機で結果をまとめました。
2つの時間のかかる認識プロセスは、領域抽出と、データベースからの類似領域の探索である。
後者は、SVSでは情報を圧縮するので、必須ではありません。
前者の速度は、画像の複雑さに依存しますが、ZuBuDデータベースにあるような複雑な
画像で0.19秒以内に処理しました。データベース検索速度は、データベース内の領域の
数とクエリ画像内の領域の数に線形に依存します。
2番目のデータベースは93682の領域が含まれています。
ZuBuDデータベースの1枚の画像から、平均して177の領域を抽出しました。
平均して0.7秒で、クエリ画像からの領域抽出を含んでいます。
シンプルな物体はプロセスをスピードアップします。
Coil-100データベースでは、クエリ画像の処理も含めて 0.18秒でした。


5. Conclusions 結論

私たちは、シンプルで早くて、信頼できる画像符号化と認識のためのアルゴリズムを提案しました。
シンプルな色ベース領域抽出と加重投票によるオブジェクトマッチングです。

前者はHSV色領域でワークし、信頼できない色情報の領域を除外し、信頼できるもののみ保持し、
位置と方向に独立して、物体をエンコードします。
画像の類似度はクエリ画像とDB画像の領域間の類似度に依存する票(データベースの画像ごとに
類似した領域とその数が異なることを補いました)で測定されます。
ZuBuDとCil-100のデータベースで、私たちは十分な認識率と速度を得ました。

なお、しかしながら、これは非常に予備・暫定的で、文献中の以前の提案と私たちの
アルゴリズムを比較するためより深い勉強が必要である。

Acknowledgements 謝辞

私たちは、Hao Shao から提供された色ベースの画像認識アルゴリズムのコードに感謝します。
http://groups.inf.ed.ac.uk/calvin/Publications/shao-icip03.pdf ←元の論文
http://www.cs.gmu.edu/~kosecka/Publications/ZhangKoseckaCVPR05.pdf ←同様の研究論文



C# Wordの行を中央揃えにする

Wordファイルのオブジェクトを中央揃えしたいことがあったので記録。

数式エディタで記述されたオブジェクトがある場合、少し工夫が必要。



2014年4月6日日曜日

確率密度関数

大学の頃から確立はどうも苦手で逃げてきたけど、パターン認識には絶対必要。

復習をメモしていく。

確率密度関数 f(x) は ある区間で積分してはじめて確率になるわけなんですね、やっと意味がわかった。

2014年4月2日水曜日

Fast Color-Based Object Recognition Independent Of Position and Orientation from Giessen and Schmidhuber 論文翻訳修行

日本語の論文って少ないよね、研究に必要なノウハウが足りない…。

英語読みます。実践あるのみ、現在研究中の色による分類に関する論文を翻訳してみる。
(間違っているところがあるかもしれません、お気軽にご指摘ください)


まずは簡単そうな論文から。

Fast Color-Based Object Recognition
Independent of Position and Orienation

ftp://ftp.idsia.ch/pub/juergen/icann2005giessen.pdf
(ftpって…、不便なんですけど)

以下、訳です。(数式が見づらいのはご容赦ください。原文が見やすいです)

Abstract(抜粋):小さなモバイルロボットはビジョンアルゴリズムを実行するのに、
一般的に小さなオンボードのプロセッサーを持っています。
ここでは、私たちがカラー画像からどのように非常に密度が高く、
また非常に有用な情報を抽出しているか見てみましょう。
画像の全ての画素を通るひとつのパスはセグメントを提供する。
色に依存する領域や、領域のコンパクトな短いリストで表した平均色相、
彩度、色の強さです。
他のすべての情報は破棄します。
2つの画像データベース(後述されるZuBuD、Coil-100という画像集を用いた2つの画像DB)を使った実験では、90%のケースで「その破棄した後に
残った情報」で、位置や方向、部分的などのクエリ画像を認識するための簡単な
加重投票アルゴリズムに十分でした。


1. Introduction

小さく、早い、画像ベースのモバイルロボットは、制限時間で反応するために、毎秒多くの
画像を処理しなければなりません。
最初の瞬間に適切に認識されないことがあっても、大きな問題にはならなりません。
ロボットのシーケンシャルなビジョンシステムが画像上にそのオブジェクトが
存在しているかどうかについて、信用を段階的に増加してくれます。
原則として、不確実性やノイズに対処するための、このようなシーケンシャルな
ビジョンシステム(SVS)はベイジアン逐次決定や機械学習で得られるニューラルネットワークで
実装されます。
画像プリプロセッサーは素早く、SVSによって提供される現在の画像のコンパクトで
有益な記述子を作り出せるはずです。
私たちは、まともな物体の認識のために必要すべての情報を含んだ画像の記述子を
(必ずしもいつもでなく)素早くつくるアルゴリズムに興味があります。
当然ですが、より信頼性の高いプリプロセッサーは、SVSへの負担が少なくなります。

物体認識の以前のたくさんのアプローチは,
制限されたモバイルロボットのオンボードやオブジェクトの位置や回転などの
とても小さい変化だけを許可した、計算上あまりにも厳しいものでした。

ここでは私達は、単独で同様の色を有する画像領域の数に基づいて、
シンプルで早くて、むしろ信頼性の高い方法を提案します。

以下では、私達は2つのメソッドを説明します。
画像符号化のための高速な方法(Section 2)と、物体認識のための十分な情報であることを、
画像DBで実証します(Section 3)。

後者(画像DB)を検索して、加重投票を元に、クエリ画像とデータベース画像との類似度
を計算します。
認識率と速度はセクション4で評価します。


2. 画像処理
2.1 HSV images
私たちは、画像をHSV色空間で表します。HSVは色の3つのプロパティ
(hue, saturation, value(illumination))との間に良い区別を提供します。
これらのプロパティの関連が図1です。
HSVコードでは、illumination(value)またはsaturationが低い領域
は、堅実で無い色の情報です。(ほとんど灰色の領域)
図1の網掛け部分は、堅実でない色が含まれています。


2.2 領域抽出
認識プロセスにおいて、全てのステップが「速い」必要があります。
我々はTuytellarsとVan Goolの手法に輝度ベースのゆるい領域分割方法にインスパイア
されたアルゴリズムを使用します。
画像をラスター走査し、隣接する画素が存在する全ての画素 j をその上及び左隣の領域
と比較します(境界では、jは上または左隣の存在するほうと比較します)。
我々は領域iの平均の色相(Hi)、彩度(Si)、明度(Vi)と画素jの色相(Hj)、彩度(Sj)、明度(Vj)
との差がそれぞれ閾値th、ts、tvより小さいかどうかを見る。

式(1)

Hueは図1の円を表します。画素 j は最も似ている色リージョンに加えます、1つが両方の
色リージョンに保持された場合、新しい色リージョンを作成します。
画素jを色リージョンに加えた時、Jに隣接する領域が | Pj - Pk | < tp を満たす場合、
Jを含む領域とマージされます。
Pj と Pk はそれぞれ「画素 j を含む領域の平均色相、彩度、明度」、「画素 j に隣接する領域の
平均色相、彩度、明度」です。
隣の画素と比較する代わりに、隣の領域の特性の平均を比較することの利点はより密着した(まとまった)
領域を生成することが出来る。
これは、平均値は領域が成長するときによりゆっくりと変化することに事を利用しており、画素の急激な
変化は領域に追加されない。

全ての領域が抽出されたら、非常に小さい面積(50pixels以下)の領域と、図1に示したような
領域が平均彩度と平均明度によって、破棄されます。
小さな領域が破棄されたひとつの理由は、それらは異なる角度からみたり、スケールが異なった場合に
画像に現れない可能性があるということです。
もうひとつの理由は、小さい領域が領域のエッジに画素があった際の歪みに敏感であることです。
私達は全ての領域において、色相、彩度、明度の平均を保存します。この情報は、位置や姿勢から独立です。


3. Querying Images
3.1 最初の処理
以下の物体認識の手順はモバイルロボットにとって必須ではありません。画像がデータベースとマッチしなくても、
ただ画像をコンパクトにする必要があり、SVSベースのコントローラに供給します。
ただしそれは、画像コードに物体を記述する基本的な情報が残っていることを証明します。
階層形式でデータベースを配置することで、さらに手順の高速化が可能です。

クエリ画像中の物体と似ている物体の画像を検索するには、まず上記のように後者の領域を抽出する。
クエリ画像内のすべての領域は、データベース内のすべての画像のすべての領域と比較されます。
大きく異なる領域間の複雑な距離尺度を計算する時間を無駄にしないように、
まず明らかにクエリ領域と類似しないものを捨てます。
これはNeneとNayarの方法と似ている方法です。[5]
すべての領域は、色相、彩度、明度の3次元空間と考えられます。
3次元空間上のボックスは、中心にあるクエリ領域と垂直な3軸で与えられる平面で計算されます。
このボックスの外側にあるデータベース領域は破棄されます。
このようにして、類似領域のグループはクエリ画像の領域ごとに作成されます。

3.2 投票比率
各グループ内のすべてのデータベース領域 i は、加重投票 Wij を得ます。
この投票は以下の「距離」によって定義します。

Dij = 5^(-1/2)((Vi - Vj)^2 + (Si * cosHi - Sj * cosHj)^2 + (Si * sinHi - Sj * sinHj)^2)^(1/2)

式(2)

データベースの領域 i とクエリ画像の領域 j 間の色です。
上記H、S、V は それぞれ 色相、彩度、明度を表し、添字は領域を表します。

私たちは、クエリ画像の独自性とデータベースの複雑さを補っています。

2つの領域の平均色相、彩度、明度の「距離」は文献[6]を参考にしています。

領域の独自性は、3.1に示した最初の処理の後、いくつの領域が生き残ったかによって
決定される。
ボックス内の領域の数が多ければ、その領域の独自性は減ります。
より独自性のある領域に多くの加重を与えるために、残った似ている領域数(Nsimilar)で割ります。
これは、クエリの領域に近い特徴をもった大きなチャンスのあるたくさんのDB領域の複雑な
画像を補うのに訳に立ちます。
これが、私達が画像が含む領域数(Nrpi)で割り算する理由です。

すると、加重投票は以下のようになります。

Wif = (1 - Dij) / (Nsimilar * Nrpi)

式(3)

物体の総合投票は、物体の全ての領域の加重投票の和となります。

4. 実験結果
4.1 ZuBuD 建物データベース

後は実験結果ですが、これはまあいいんじゃないでしょうか。

3時間くらいかかった。
次はもっと早くする。

とういことで英語論文に慣れてくぞー。

2014年4月1日火曜日

Android の Nativeオブジェクト が更新エラーになった時の回避方法

以下のようなエラーの状態ですね。
このエラーの特徴は、起こったり起こらなかったりすることです。


make: *** [libs/armeabi/libgnustl_shared.so] Error 1
make: *** Deleting file `libs/armeabi/libgnustl_shared.so'

これは、動的ライブラリをバージョン管理してしまった場合に発生するようです。

私の場合は、git管理から外したら、エラーが発生しなくなりました。

Android で Nativeコードのログを出力する

Android.mk で以下のライブラリをインクルードすること。

LOCAL_LDLIBS +=  -llog -ldl

ログ出力側の Native コードは、以下の用に記述する。


NDKでOpenCVを使ったNativeコードを書く


EclipseでOpenCVのAndroid用の設定が出来たら、NativeでOpenCVを使う設定します。
Javaで確保したMatオブジェクトを、Nativeで処理したい場合には必須でしょう。

ちなにみ以下は、OpenCV 2.4.1の場合です。
(OpenCVのライブラリをアーキテクチャ毎にアプリに内包出来るのが、2.4.1まで)

以下の用に、プロジェクトの「properties → C/C+ General → Paths and Symbols 」から設定を行います。

















また、ビルド時にOpenCVに付属する OpenCV.mk も使う必要があるため、
Android.mkは以下の用になります。


OpenCV_CAMERA_MODULES := off

LOCAL_C_INCLUDES += ${LOCAL_PATH}

までがデフォルトのmkファイルに追加する部分です。

花画像の分類

花図鑑。

どんな花があるのか見ておこう。

http://hana-zukan.net/