Pipe Renderでタグ「ARToolKitの安定化」が付けられているもの
ARToolKitのtwoViewを使ったプログラム、その①
カメラ間の関係を保持し、それを使ってマーカーを補間します。
ここでも、安定化と似たような計算を行います。
今回は動画では短すぎるので、画像のみです。


--- < 処理の概要 > ---
まず、どちらのカメラにもマーカーが映っている場合に、以下のような計算をします。
・"マーカー→カメラ1"、"マーカー→カメラ2" が分かっている。
・"マーカー→カメラ1"を反転して"カメラ1→マーカー"にする。
・"カメラ1→マーカー→カメラ2"という行列計算を行い、”カメラ1→カメラ2”を取得する。
次に、片方のカメラでマーカーが見つからなかった場合に、次のような計算で補間を行います。
カメラ1のみでマーカーが見つからなかった場合
・”カメラ1→カメラ2”、"マーカー→カメラ2" が分かっている。
・”カメラ1→カメラ2”を反転して、”カメラ2→カメラ1”にする。
・"マーカー→カメラ2→カメラ1"という行列計算を行い、"マーカー→カメラ1"を取得する。
カメラ2の場合も同様です。
これで、片方のカメラにさえマーカーが映っていれば、
マーカーが見えなくてもその位置を特定することができます。
--- < 処理の特徴 > ---
この方法を使うと安定化にも繋がりますが、そのために以下のような制限が付きます。
・一番最初に、2つのカメラに同じマーカーを映すなどして、変換行列を計算する。
・片方のカメラが動いた場合、変換行列を再計算する。
・両方のカメラでマーカーを発見できないときは、補間ができない。
等々です。
これを解決するためには、いくつか方法が考えられます。
1.カメラを絶対に動かさないようにする。
2.2つのカメラを固定して、変換行列を変えないまま移動できるようにする。
3.カメラ1に、マーカーとカメラ2が必ず映るようにして、カメラ2にもマーカーを付ける。
こんなところでしょうか。
他にも方法がありそうですね。
--- < 最後に > ---
上記のように、twoViewを使うには少し工夫をしないといけないようです。
ですが、そこから得られる機能には、いろんな使い道がありそうです。
カメラ間の関係を保持し、それを使ってマーカーを補間します。
ここでも、安定化と似たような計算を行います。
今回は動画では短すぎるので、画像のみです。
--- < 処理の概要 > ---
まず、どちらのカメラにもマーカーが映っている場合に、以下のような計算をします。
・"マーカー→カメラ1"、"マーカー→カメラ2" が分かっている。
・"マーカー→カメラ1"を反転して"カメラ1→マーカー"にする。
・"カメラ1→マーカー→カメラ2"という行列計算を行い、”カメラ1→カメラ2”を取得する。
次に、片方のカメラでマーカーが見つからなかった場合に、次のような計算で補間を行います。
カメラ1のみでマーカーが見つからなかった場合
・”カメラ1→カメラ2”、"マーカー→カメラ2" が分かっている。
・”カメラ1→カメラ2”を反転して、”カメラ2→カメラ1”にする。
・"マーカー→カメラ2→カメラ1"という行列計算を行い、"マーカー→カメラ1"を取得する。
カメラ2の場合も同様です。
これで、片方のカメラにさえマーカーが映っていれば、
マーカーが見えなくてもその位置を特定することができます。
--- < 処理の特徴 > ---
この方法を使うと安定化にも繋がりますが、そのために以下のような制限が付きます。
・一番最初に、2つのカメラに同じマーカーを映すなどして、変換行列を計算する。
・片方のカメラが動いた場合、変換行列を再計算する。
・両方のカメラでマーカーを発見できないときは、補間ができない。
等々です。
これを解決するためには、いくつか方法が考えられます。
1.カメラを絶対に動かさないようにする。
2.2つのカメラを固定して、変換行列を変えないまま移動できるようにする。
3.カメラ1に、マーカーとカメラ2が必ず映るようにして、カメラ2にもマーカーを付ける。
こんなところでしょうか。
他にも方法がありそうですね。
--- < 最後に > ---
上記のように、twoViewを使うには少し工夫をしないといけないようです。
ですが、そこから得られる機能には、いろんな使い道がありそうです。
お待たせしました。ソースを公開いたします。
時間がかかってしまい、申し訳ありません。
また、作者も非常に経験不足ゆえ、ファイルのミス、プログラムの不具合、説明不足、コードが読みにくい、等々予期せぬ問題が発生するかと思われます。
そういった問題は、可能な限り改善していきたいと思いますので、
メールなどで、できるだけ詳細な連絡(動作環境、現象の発生手順等)をいただけると非常にありがたいです。
では、Ver1.0になります。
MultiRelate1.0.zip
こちらも、Readmeの詳細説明用に使用いたします。
プログラムの大まかな処理は、その①やその②を見てもらっても大体はわかります。
今回は少しプログラム寄りな説明になります。
安定化プログラムでは以下のような処理を行っています
・設定ファイルを読み込む
・通常表示
・関係値の計算
・計算結果を表示する
・補完処理を加えた表示
・関係値の保存
このプログラムでは、関係値のデータと処理を行うクラス"CObjectMultiCreator"があり、
上記の処理のほとんどは、このクラスのメンバ関数内で行っています。
では、それぞれの処理を見てみます
・設定ファイルを読み込む : 関数 LoadMultiRelationInf
設定ファイルには、"複数オブジェクトファイルへのパス"と、"関係値の値"が保存されています。
初期状態では"関係値の値"は存在しません。
詳しくは、その④-EXEの使い方を参照してください。
・通常表示
通常表示では、従来のARToolKitとほぼ同様の処理を行っています。
・関係値の計算 : 関数 CalcAllMarkerRelate
キー操作により、編集モードに入ったときに、関係値の計算が行われます。
関数に入る前に、従来と同じ方法で、各マーカーの座標変換行列 "object.trans" が計算されます。
ここでマーカーA, Bが見つかったとします。
そのとき次のような計算を行います。
1.座標変換行列、"A→カメラ"と、"B→カメラ"、が分かっている。
2.1の"B→カメラ"を反転して、"カメラ→B"にする。
3.1と2から、"A→カメラ→B"という行列計算を行う。
4.3から"A → B"という座標変換行列を得る。
平均値計算用に、サンプル数と行列の合計値を、メンバ変数に蓄えておきます。
ある程度、サンプル数が溜まったら、上記と同じ方法で誤差を計算します。
これも、サンプル数と合計値の形で、持っておきます。
・計算結果を表示する
計算が大体終了したら、それを表示し、ユーザーに知らせます。
ユーザーはこの表示を見て、計算の頃合を計り、編集モードを終了します。
表示に使用される値は、マーカー関係情報の構造体"MARKER_RELATE_INFO"の、誤差の合計値"dError"や、サンプル数"lRelCount"を使用します。
・補完処理を加えた表示 : 関数 GetGLTransFromRelate
関係値が計算できても、マーカーを問題なく取得できた場合には、通常の描画を行います。
問題は、マーカー情報が正しく取得できなかった場合です。
例えば、マーカーAの情報が取得できず、マーカーBは取得できたとします。
その時は、以下のような計算になります。
1.座標変換行列 "A →B"と"B → カメラ" が分かっている
2.1より、" A → B → カメラ" という行列計算を行う
3.2の結果から、"A → カメラ" という座標系変換行列を得る
というような感じです。
・関係値の保存 : 関数 SaveMultiRelationInf
最後に関係値の保存を行います。
ファイルにデータとして保存してしまえば、時間使用時、又は他のプログラムでも再利用できます。
実行のたびに関係値を計算する手間を、省けるわけです。
更なる詳細については、プログラムを読んだり、デバック実行して、理解していただくか、
それでも分からない場合は、メールにてご連絡ください。
プログラムの大まかな処理は、その①やその②を見てもらっても大体はわかります。
今回は少しプログラム寄りな説明になります。
安定化プログラムでは以下のような処理を行っています
・設定ファイルを読み込む
・通常表示
・関係値の計算
・計算結果を表示する
・補完処理を加えた表示
・関係値の保存
このプログラムでは、関係値のデータと処理を行うクラス"CObjectMultiCreator"があり、
上記の処理のほとんどは、このクラスのメンバ関数内で行っています。
では、それぞれの処理を見てみます
・設定ファイルを読み込む : 関数 LoadMultiRelationInf
設定ファイルには、"複数オブジェクトファイルへのパス"と、"関係値の値"が保存されています。
初期状態では"関係値の値"は存在しません。
詳しくは、その④-EXEの使い方を参照してください。
・通常表示
通常表示では、従来のARToolKitとほぼ同様の処理を行っています。
・関係値の計算 : 関数 CalcAllMarkerRelate
キー操作により、編集モードに入ったときに、関係値の計算が行われます。
関数に入る前に、従来と同じ方法で、各マーカーの座標変換行列 "object.trans" が計算されます。
ここでマーカーA, Bが見つかったとします。
そのとき次のような計算を行います。
1.座標変換行列、"A→カメラ"と、"B→カメラ"、が分かっている。
2.1の"B→カメラ"を反転して、"カメラ→B"にする。
3.1と2から、"A→カメラ→B"という行列計算を行う。
4.3から"A → B"という座標変換行列を得る。
平均値計算用に、サンプル数と行列の合計値を、メンバ変数に蓄えておきます。
ある程度、サンプル数が溜まったら、上記と同じ方法で誤差を計算します。
これも、サンプル数と合計値の形で、持っておきます。
・計算結果を表示する
計算が大体終了したら、それを表示し、ユーザーに知らせます。
ユーザーはこの表示を見て、計算の頃合を計り、編集モードを終了します。
表示に使用される値は、マーカー関係情報の構造体"MARKER_RELATE_INFO"の、誤差の合計値"dError"や、サンプル数"lRelCount"を使用します。
・補完処理を加えた表示 : 関数 GetGLTransFromRelate
関係値が計算できても、マーカーを問題なく取得できた場合には、通常の描画を行います。
問題は、マーカー情報が正しく取得できなかった場合です。
例えば、マーカーAの情報が取得できず、マーカーBは取得できたとします。
その時は、以下のような計算になります。
1.座標変換行列 "A →B"と"B → カメラ" が分かっている
2.1より、" A → B → カメラ" という行列計算を行う
3.2の結果から、"A → カメラ" という座標系変換行列を得る
というような感じです。
・関係値の保存 : 関数 SaveMultiRelationInf
最後に関係値の保存を行います。
ファイルにデータとして保存してしまえば、時間使用時、又は他のプログラムでも再利用できます。
実行のたびに関係値を計算する手間を、省けるわけです。
更なる詳細については、プログラムを読んだり、デバック実行して、理解していただくか、
それでも分からない場合は、メールにてご連絡ください。
Readmeの詳細説明に必要なので、ソース公開前に書いておきます。
実行ファイルの使用方法です。
--- < とりあえず実行してみる > ---
0.GULTをインストール
実行にはGLUTが必要です。
1.マーカーを印刷
\patternsフォルダ内の、マーカーを印刷します。
印刷できない場合は、ディスプレイにマーカーの画像を表示するだけでも、大丈夫です。
2.実行ファイルを起動
\binフォルダ内の"MultiRelate1.0.exe"を実行します。
設定ダイアログが出て、Webカメラから画像が表示されるはずです。
3.確認
マーカー上に色のついた立方体が表示されるはずです。
4.編集モードにする
キーボードの"E"キーを押して、編集モードにします。
操作キーは、画像が映っているウィンドウを選択していないと、実行されません。
5.関係値のリセットを行う
キーボードの"C"キーを押して、関係値をリセットします。
6.関係値を設定する
できるだけ多くのマーカーが認識されるように、カメラを移動してください。
そして表示が安定するまで、その場でカメラを動かさないようにしましょう。
立方体の線が緑や黄色で安定したら、だいたい計算ができています。
7.全てのマーカーで、6の作業を行う
6の作業を、全てのマーカーに対して行います。
2つ以上のマーカーが認識されていないと意味がありません。
8.通常モードに戻す
もう一度"E"キーを押して、通常モードに戻ります。
9.関係値の確認
関係値が正しく計算できていれば、1つのマーカーの認識に失敗しても、他の成功したマーカーから補完されます。
10.保存する。
"S"キーを押して、関係値の保存をします。
プロンプト(文字しか表示されない、もう一つの黒い画面)に、保存ができたという旨の文章が表示されれば、完了です。
再実行した時にも、保存された関係値を使用し、何度も計算する必要がなくなります。
--- < 使い方の詳細 > ---
○キー操作
・"E"キー:[編集モード]/[通常モード]への切り替えを行います。
・"C"キー:計算された関係値をリセットします。
・"S"キー:関係値を保存して、次回も使用できるようにします。
・"1~9"キー:1~9番の、マーカー上の3Dモデルの[表示]/[非表示]を切り替えます。
・"0"キー:全ての3Dモデルの[表示]/[非表示]を切り替えます。
・"R"キー:マーカー間の関係を表す線の[表示]/[非表示]を切り替えます。
・"M"キー:マーカー自体を表す、四角形の印の[表示]/[非表示]を切り替えます。
・"V"キー:現在表示されている3Dモデル間の関係値のみをリセットします。
・"T"キー:文字情報の[表示]/[非表示]を切り替えます。
○マーカー間の関係を表すファイル ”Data\MultiRelationInf.dat”
ファイルの内容は、概ね以下のようになっています。
最初に、複数のオブジェクトを記述したファイルのパスを書きます。
このファイルは既存のプロジェクト"loadMultiple"で使用されているのと、同じ形式なります。
自分で作ったマーカーを利用する場合には、この複数オブジェクトファイルの内容や、ここのパスを変更してください。
次に、マーカー間の関係値が事前に保存されているかを示すフラグが書かれています。
初期値は0になっていて、関係値を保存した後は1になります。
この値が0の場合は、後に関係値が続いていても読み込みません。
最後に、実際の関係値が書かれます。
ここに書かれる関係値は、
・全てのオブジェクトから全てのオブジェクトへの座標変換行列(サンプル数と合計値)
・その行列の誤差(サンプル数と合計値)
・誤差を合計した値
になります。見ての通り、非常に冗長です。
実際の関係は、各合計値をサンプル数で割った平均値が用いられます。
実行ファイルの使用方法です。
--- < とりあえず実行してみる > ---
0.GULTをインストール
実行にはGLUTが必要です。
1.マーカーを印刷
\patternsフォルダ内の、マーカーを印刷します。
印刷できない場合は、ディスプレイにマーカーの画像を表示するだけでも、大丈夫です。
2.実行ファイルを起動
\binフォルダ内の"MultiRelate1.0.exe"を実行します。
設定ダイアログが出て、Webカメラから画像が表示されるはずです。
3.確認
マーカー上に色のついた立方体が表示されるはずです。
4.編集モードにする
キーボードの"E"キーを押して、編集モードにします。
操作キーは、画像が映っているウィンドウを選択していないと、実行されません。
5.関係値のリセットを行う
キーボードの"C"キーを押して、関係値をリセットします。
6.関係値を設定する
できるだけ多くのマーカーが認識されるように、カメラを移動してください。
そして表示が安定するまで、その場でカメラを動かさないようにしましょう。
立方体の線が緑や黄色で安定したら、だいたい計算ができています。
7.全てのマーカーで、6の作業を行う
6の作業を、全てのマーカーに対して行います。
2つ以上のマーカーが認識されていないと意味がありません。
8.通常モードに戻す
もう一度"E"キーを押して、通常モードに戻ります。
9.関係値の確認
関係値が正しく計算できていれば、1つのマーカーの認識に失敗しても、他の成功したマーカーから補完されます。
10.保存する。
"S"キーを押して、関係値の保存をします。
プロンプト(文字しか表示されない、もう一つの黒い画面)に、保存ができたという旨の文章が表示されれば、完了です。
再実行した時にも、保存された関係値を使用し、何度も計算する必要がなくなります。
--- < 使い方の詳細 > ---
○キー操作
・"E"キー:[編集モード]/[通常モード]への切り替えを行います。
・"C"キー:計算された関係値をリセットします。
・"S"キー:関係値を保存して、次回も使用できるようにします。
・"1~9"キー:1~9番の、マーカー上の3Dモデルの[表示]/[非表示]を切り替えます。
・"0"キー:全ての3Dモデルの[表示]/[非表示]を切り替えます。
・"R"キー:マーカー間の関係を表す線の[表示]/[非表示]を切り替えます。
・"M"キー:マーカー自体を表す、四角形の印の[表示]/[非表示]を切り替えます。
・"V"キー:現在表示されている3Dモデル間の関係値のみをリセットします。
・"T"キー:文字情報の[表示]/[非表示]を切り替えます。
○マーカー間の関係を表すファイル ”Data\MultiRelationInf.dat”
ファイルの内容は、概ね以下のようになっています。
#マーカーオブジェクトデータ
Data/multi/markerColor30_01_6.arobj
#マーカーの関係データがあるかどうか
1
#################################################################
#marker 1
#to 1
0
0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
#err
0
0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
#Sum
-1.000000
#to 2
602
-601.079477 -6.103214 -29.765651 -224.731229
29.999639 -22.392234 -600.762449 -17661.005934
5.014032 -601.428488 22.542861 -21332.142015
#err
503
502.913258 -4.899541 2.086850 -469.029122
4.890394 502.880013 2.277454 -35.750323
-2.163808 -2.263550 502.959077 -328.080689
#Sum
4.299248
#to 3
・
・
・
最初に、複数のオブジェクトを記述したファイルのパスを書きます。
このファイルは既存のプロジェクト"loadMultiple"で使用されているのと、同じ形式なります。
自分で作ったマーカーを利用する場合には、この複数オブジェクトファイルの内容や、ここのパスを変更してください。
次に、マーカー間の関係値が事前に保存されているかを示すフラグが書かれています。
初期値は0になっていて、関係値を保存した後は1になります。
この値が0の場合は、後に関係値が続いていても読み込みません。
最後に、実際の関係値が書かれます。
ここに書かれる関係値は、
・全てのオブジェクトから全てのオブジェクトへの座標変換行列(サンプル数と合計値)
・その行列の誤差(サンプル数と合計値)
・誤差を合計した値
になります。見ての通り、非常に冗長です。
実際の関係は、各合計値をサンプル数で割った平均値が用いられます。
さて、いよいよソース公開の作業に入ります。
最初にGPLの詳細説明と、Readmeの作成についてです。
----------------------- < GPLの詳細 > -----------------------
GPLについて、補足説明をさせていただきます。
自分がGPLについて、実際にどうソースを変更したかについてです。
○GPLの内容が書かれた文を配布ファイル内に入れる
ARToolKitにもともとあった"COPYING.txt"と、その日本語訳の文を、ファイルに付属しました。
○ファイルを変更した旨とその変更日とを、変更したファイル上に明確に表示すること。
これに関しては、従来のコメントの書き方で対応させていただきました。
ファイルの先頭のコメントで、以下のようなものを追加します。
コメントはDoxygen方式になっています。
○ソース内の著作権表示と無保証等の説明
追加したコメントは以下のような内容になります
○実行ファイル内での、著作権・無保証等の表示
これも、GPLの日本語訳に従い、プログラム実行直後に以下のプログラムを実行
もちろん、"G"キー押下時にも以下の文を加えます。
printf("ARToolKitの安定化プログラム Ver1.0 Copyright (c) 2008 PipeR\n\n");
printf("he distribution policy is described in the file \"COPYING.txt\" furnished with this library.\n\n");
printf("本プログラムは、GNU 一般公有使用許諾に準拠します。利用も配布も商用利用も自由ですが、著作権は放棄しておりません。また、改変も自由ですが、GPLである以上、改変バージョンの配布を行う際には、ソースの公開は必須条件となりますので、ご注意下さい。GNU 一般公有使用許諾については、付属の\"COPYING_JPN.txt\"をご覧ください。\n\n");
printf("本プログラムはフリー・ソフトウェアです。あなたは、Free Software Foundation が公表したGNU 一般公有使用許諾の「バージョン2」或いはそれ以降の各バージョンの中からいずれかを選択し、そのバージョンが定める条項に従って本プログラムを再頒布または変更することができます。\n\n");
printf("本プログラムは有用とは思いますが、頒布にあたっては、市場性及び特定目的適合性についての暗黙の保証を含めて、いかなる保証も行ないません。詳細についてはGNU 一般公有使用許諾書をお読みください。\n\n");
printf("あなたは、本プログラムと一緒にGNU 一般公有使用許諾の写しを受け取っているはずです。そうでない場合は、Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA * へ手紙を書いてください。\n\n");
printf("* 【注意】 現在、このバージョン2の発行者(FSF)住所は、正式に新しい住所の 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA に変わっている。\n\n");
----------------------- < Readmeの作成 > -----------------------
次にReadmeの作成です。Readmeとはいわゆる「お読みください.txt」などの説明書のようなものです。
これには、Readmeファイルの作成支援ソフト「れ~どみ~えじた~」を使用しました。
これは、ウィザードと各種テンプレートを使い、Readmeを簡単に作成してくれるソフトです。
ここでは注意すべき点は少ないですね。
・[再配布]は「GPLに基づく」
・今回は、[必要ランタイム]に「GLUT」を入れました。
・現状では動作環境としてXP、開発環境はVC++ 2005しか試していないので、他の環境での動作、開発では不具合が出るかもしれません。
ぐらいでしょうか。
最初にGPLの詳細説明と、Readmeの作成についてです。
----------------------- < GPLの詳細 > -----------------------
GPLについて、補足説明をさせていただきます。
自分がGPLについて、実際にどうソースを変更したかについてです。
○GPLの内容が書かれた文を配布ファイル内に入れる
ARToolKitにもともとあった"COPYING.txt"と、その日本語訳の文を、ファイルに付属しました。
○ファイルを変更した旨とその変更日とを、変更したファイル上に明確に表示すること。
これに関しては、従来のコメントの書き方で対応させていただきました。
ファイルの先頭のコメントで、以下のようなものを追加します。
/*******************************************************************************又は、新規作成の場合は
*
* \file object.h
*
* \brief オブジェクトに関する情報と操作
*
* \date 08/02/02 PipeR 構造体にcf等の付加情報を追加しました
*
*******************************************************************************/
/*******************************************************************************一番下の\dateで、「日付・名前・変更内容」を記述します。
*
* \file MultiSetting01.c
*
* \brief 複数マーカー認識で用いる、
* \brief MultiMarkerInfoの設定ファイルを作成する
*
* \author PipeR
*
* \date 08/02/02 PipeR 作成
*
*******************************************************************************/
コメントはDoxygen方式になっています。
○ソース内の著作権表示と無保証等の説明
追加したコメントは以下のような内容になります
/*******************************************************************************この内容は、GPLの日本語訳に従っています。
*
* Copyright (c) 2008 PipeR
*
* The distribution policy is described in the file "COPYING.txt" furnished
* with this library.
*
* 本プログラムは、GNU 一般公有使用許諾に準拠します。
* 利用も配布も商用利用も自由ですが、著作権は放棄しておりません。
* また、改変も自由ですが、GPLである以上、改変バージョンの配布を行う際には、
* ソースの公開は必須条件となりますので、ご注意下さい。
* GNU 一般公有使用許諾については、付属の"COPYING_JPN.txt"をご覧ください
*
*
* 本プログラムはフリー・ソフトウェアです。あなたは、Free Software
* Foundation が公表したGNU 一般公有使用許諾の「バージョン2」或い
* はそれ以降の各バージョンの中からいずれかを選択し、そのバージョン
* が定める条項に従って本プログラムを再頒布または変更することができ
* ます。
*
* 本プログラムは有用とは思いますが、頒布にあたっては、市場性及び特
* 定目的適合性についての暗黙の保証を含めて、いかなる保証も行ないま
* せん。詳細についてはGNU 一般公有使用許諾書をお読みください。
*
* あなたは、本プログラムと一緒にGNU 一般公有使用許諾の写しを受け取っ
* ているはずです。そうでない場合は、Free Software Foundation, Inc.,
* 675 Mass Ave, Cambridge, MA 02139, USA * へ手紙を書いてください。
*
* ----------------------------------------------------------------------
* * 【注意】 現在、このバージョン2の発行者(FSF)住所は、正式に新
* しい住所の 51 Franklin St, Fifth Floor, Boston, MA 02110-1301,
* USA に変わっている。
* ----------------------------------------------------------------------
*
*******************************************************************************/
○実行ファイル内での、著作権・無保証等の表示
これも、GPLの日本語訳に従い、プログラム実行直後に以下のプログラムを実行
printf("ARToolKitの安定化プログラム Ver1.0 Copyright (c) 2008 PipeR\n");
printf("ARToolKitの安定化プログラム は完全に無保証です。詳細はOpenGLのウィンドウで\"G\"キーをタイプしてください。\n");
printf("これはフリー・ソフトウェアなので、特定の条件の下でこれを再頒布することができます。詳細は付属の\"COPYING.txt\"か\"COPYING_JPN.txt\"をご覧ください。\n");
もちろん、"G"キー押下時にも以下の文を加えます。
printf("ARToolKitの安定化プログラム Ver1.0 Copyright (c) 2008 PipeR\n\n");
printf("he distribution policy is described in the file \"COPYING.txt\" furnished with this library.\n\n");
printf("本プログラムは、GNU 一般公有使用許諾に準拠します。利用も配布も商用利用も自由ですが、著作権は放棄しておりません。また、改変も自由ですが、GPLである以上、改変バージョンの配布を行う際には、ソースの公開は必須条件となりますので、ご注意下さい。GNU 一般公有使用許諾については、付属の\"COPYING_JPN.txt\"をご覧ください。\n\n");
printf("本プログラムはフリー・ソフトウェアです。あなたは、Free Software Foundation が公表したGNU 一般公有使用許諾の「バージョン2」或いはそれ以降の各バージョンの中からいずれかを選択し、そのバージョンが定める条項に従って本プログラムを再頒布または変更することができます。\n\n");
printf("本プログラムは有用とは思いますが、頒布にあたっては、市場性及び特定目的適合性についての暗黙の保証を含めて、いかなる保証も行ないません。詳細についてはGNU 一般公有使用許諾書をお読みください。\n\n");
printf("あなたは、本プログラムと一緒にGNU 一般公有使用許諾の写しを受け取っているはずです。そうでない場合は、Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA * へ手紙を書いてください。\n\n");
printf("* 【注意】 現在、このバージョン2の発行者(FSF)住所は、正式に新しい住所の 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA に変わっている。\n\n");
----------------------- < Readmeの作成 > -----------------------
次にReadmeの作成です。Readmeとはいわゆる「お読みください.txt」などの説明書のようなものです。
これには、Readmeファイルの作成支援ソフト「れ~どみ~えじた~」を使用しました。
これは、ウィザードと各種テンプレートを使い、Readmeを簡単に作成してくれるソフトです。
ここでは注意すべき点は少ないですね。
・[再配布]は「GPLに基づく」
・今回は、[必要ランタイム]に「GLUT」を入れました。
・現状では動作環境としてXP、開発環境はVC++ 2005しか試していないので、他の環境での動作、開発では不具合が出るかもしれません。
ぐらいでしょうか。
BGM:エコテロニカ(sansuiさん)
他にもARToolKitを安定化させる要素はいくつかあります。
1.キャリブレーション
2.カメラの設定
3.撮影時の注意
4.その他
1.キャリブレーション
キャリブレーションはカメラの歪み補正値を計算するためのものなので、回数が多いほうが正しい結果が得られます。
また、キャリブレーションパターンの正面からの計測だけでなく、斜めや真横に近い位置からの計測を行ったほうが、安定する気がします。
2.カメラの設定
Webカメラなどでは、明るさやコントラストを調節できるものが多いです。この設定値はカメラ固有のものなので、これが良いという値はありません。
そこで、実際にプログラムを動かしながら、カメラの設定を変更してみてください。
オートフォーカスは切ったほうがいいです。
3.撮影時の注意
パターンの時にも説明しましたが、太陽光など強い光の場合はマーカーにハイライトがあたり、認識がうまくいかなくなるときがあります。蛍光灯の光だけでの撮影をオススメします。
また、カメラを早く動かしたり、手ブレなどにより、マーカーの認識率は極端に悪くなります。カメラはできるだけ固定するのが理想的です。
フレームレートは、やはり大きいほうがモデルの歪みが少ないようです。
4.その他
ARToolKitではマーカーの最大サイズ・最小サイズを決めることができます。ありえないサイズのマーカーは最初から除外する設定にすれば、誤認を防げます。
背景となるステージにはできるだけ物を置かず、白など明るい色の場所を選ぶようにしましょう。
最後に、お金はかかってしまいますが、やはりカメラはできるだけ良いものがいいです。
ちなみに私が使っているWebカメラは、logicoolのQcam Pro for Notebooksです。ノートブックタイプを選んだのは、固定しやすく、小さいので小回りが利くからです。
1.キャリブレーション
2.カメラの設定
3.撮影時の注意
4.その他
1.キャリブレーション
キャリブレーションはカメラの歪み補正値を計算するためのものなので、回数が多いほうが正しい結果が得られます。
また、キャリブレーションパターンの正面からの計測だけでなく、斜めや真横に近い位置からの計測を行ったほうが、安定する気がします。
2.カメラの設定
Webカメラなどでは、明るさやコントラストを調節できるものが多いです。この設定値はカメラ固有のものなので、これが良いという値はありません。
そこで、実際にプログラムを動かしながら、カメラの設定を変更してみてください。
オートフォーカスは切ったほうがいいです。
3.撮影時の注意
パターンの時にも説明しましたが、太陽光など強い光の場合はマーカーにハイライトがあたり、認識がうまくいかなくなるときがあります。蛍光灯の光だけでの撮影をオススメします。
また、カメラを早く動かしたり、手ブレなどにより、マーカーの認識率は極端に悪くなります。カメラはできるだけ固定するのが理想的です。
フレームレートは、やはり大きいほうがモデルの歪みが少ないようです。
4.その他
ARToolKitではマーカーの最大サイズ・最小サイズを決めることができます。ありえないサイズのマーカーは最初から除外する設定にすれば、誤認を防げます。
背景となるステージにはできるだけ物を置かず、白など明るい色の場所を選ぶようにしましょう。
最後に、お金はかかってしまいますが、やはりカメラはできるだけ良いものがいいです。
ちなみに私が使っているWebカメラは、logicoolのQcam Pro for Notebooksです。ノートブックタイプを選んだのは、固定しやすく、小さいので小回りが利くからです。
細かいことですが、マーカーの作成では、パターンの模様以外でも気をつけることがあります。
1.できるだけ大きいマーカーにする
2.カラーパターンを使うときには、プリンターも発色がいいものを使用する
3.厚紙に貼り付けるなど、絵が歪まないようにする
4.mk_patt.exeを実行し、パターンデータを作る際には、実際の撮影環境に近づける
1.できるだけ大きいマーカーにする
マーカーを大きくしたほうが、認識率が上がり、安定性も良くなります。
画面にちゃんと収まる範囲内なら、マーカーは大きいほうがいいです。
2.カラーパターンを使うときには、プリンターも発色がいいものを使用する
安いプリンターなどを使うと、3原色が正しくプリントされない場合があります。またプリンターを持っていない方もいると思います。
僕は、プリンタを持ってはいますが、発色が気になったので、ネットプリントを利用しました。これは、PCからデータをアップロードし、セブンイレブンなどで印刷ができるサービスです。ちょっと印刷代はかかりますが、コンビニのプリンタはそれなりに性能がいいので、時々利用しています。
3.厚紙に貼り付けるなど、絵が歪まないようにする
僕が使っているのは、1mmのイラストレーションボードです。200円ぐらいで東急ハンズなどに売っています。かなり硬く、歪むことはほぼないです。
紙をボードに貼り付けた直後は、本などを重しにして挟んでおきましょう。
ボードをくっつける時には、接がれやすい両面テープなどを使うと便利です。
4.mk_patt.exeを実行し、パターンデータを作る際には、実際の撮影環境に近づける
パターンは光の種類や加減などによって、映り方が変わってしまいます。
できるだけ実際の環境に近い状態でパターンデータを作成したほうが良いと思われます。
太陽光よりも蛍光灯など光のほうが光沢が出にくく、撮影には適しています。
1.できるだけ大きいマーカーにする
2.カラーパターンを使うときには、プリンターも発色がいいものを使用する
3.厚紙に貼り付けるなど、絵が歪まないようにする
4.mk_patt.exeを実行し、パターンデータを作る際には、実際の撮影環境に近づける
1.できるだけ大きいマーカーにする
マーカーを大きくしたほうが、認識率が上がり、安定性も良くなります。
画面にちゃんと収まる範囲内なら、マーカーは大きいほうがいいです。
2.カラーパターンを使うときには、プリンターも発色がいいものを使用する
安いプリンターなどを使うと、3原色が正しくプリントされない場合があります。またプリンターを持っていない方もいると思います。
僕は、プリンタを持ってはいますが、発色が気になったので、ネットプリントを利用しました。これは、PCからデータをアップロードし、セブンイレブンなどで印刷ができるサービスです。ちょっと印刷代はかかりますが、コンビニのプリンタはそれなりに性能がいいので、時々利用しています。
3.厚紙に貼り付けるなど、絵が歪まないようにする
僕が使っているのは、1mmのイラストレーションボードです。200円ぐらいで東急ハンズなどに売っています。かなり硬く、歪むことはほぼないです。
紙をボードに貼り付けた直後は、本などを重しにして挟んでおきましょう。
ボードをくっつける時には、接がれやすい両面テープなどを使うと便利です。
4.mk_patt.exeを実行し、パターンデータを作る際には、実際の撮影環境に近づける
パターンは光の種類や加減などによって、映り方が変わってしまいます。
できるだけ実際の環境に近い状態でパターンデータを作成したほうが良いと思われます。
太陽光よりも蛍光灯など光のほうが光沢が出にくく、撮影には適しています。
ARToolKitをより安定的なものにするには、プログラムもそうですが、使う道具も考えなければいけません。
その道具の中で重要なものの1つが、マーカーのパターンです。
マーカーの数が少ない場合、その中のパターンはよりシンプルなものの方が認識率が良いです。
シンプルなマーカーは既存のサンプルにも入っています。


しかし、マーカーの数が多い場合は、誤認識を避けるために、どうしてもパターンが複雑になってしまいます。
そこで、シンプルさを保ちながら、多くのマーカーを作成する方法として、パターンをカラーにしてみることにしました。
最初に作成したのは、次のようなパターンです。


このパターンではマーカー内部を4つに分けて、それぞれの区画に3原色(赤、青、緑)を配置し、その組み合わせでマーカーを区別しています。右下に必ずある黒い区画は、マーカーの方向を決めるためのものです。これだと3×3×3で27通りのパターンを作成することができます。
これを実際に使用すると、以下のようなことがわかりました。
・右下の黒い区画をマーカーの黒枠だと誤認してしまう。
・青が黒に近いので、これもマーカーの黒枠だと間違われることがある。
つまり、マーカー内部に黒に近い四角形があると、誤認の確率が高くなることが判明しました。
この教訓により作成したのが、次のマーカーです。


なんだか顔みたいですね。
まず、右下の黒い区画を白に変え、次に他の色が四角形にならないように、凹を入れました。あと余計な隙間も一応埋めました。
これで、だいぶ誤認しないようになりましたが、どうせ凹を入れるなら、色によって位置を分けたほうが、個体差が大きくなります。


今回のパターンでは色によって凹の位置が違います。
というわけで、動画で使われているマーカーはこのパターンになりました。
次は凹をもう少し小さくして、試してみます。
※訂正
パターンの凹を小さくして実験しましたが、どうやらこの凹は要らないようです。
ARToolKitでは黒枠を認識するときに、画像を2値化してます。(パターン認識の時はもちろんカラー画像を使う)
そうなるともう色は関係なく、明るいか暗いかのみの違いになります。
つまり、色の領域が外枠と接してさえいれば、四角形と認識されることはなくなるのです。
しかし、凹が黒枠の誤認識に効果がなくても、各パターンの誤認識には効果があるかもしれません。
とりあえず、この凹なしのパターンで実験を続けてみて、誤認識の割合を見てみることとします。
その道具の中で重要なものの1つが、マーカーのパターンです。
マーカーの数が少ない場合、その中のパターンはよりシンプルなものの方が認識率が良いです。
シンプルなマーカーは既存のサンプルにも入っています。


しかし、マーカーの数が多い場合は、誤認識を避けるために、どうしてもパターンが複雑になってしまいます。
そこで、シンプルさを保ちながら、多くのマーカーを作成する方法として、パターンをカラーにしてみることにしました。
最初に作成したのは、次のようなパターンです。


このパターンではマーカー内部を4つに分けて、それぞれの区画に3原色(赤、青、緑)を配置し、その組み合わせでマーカーを区別しています。右下に必ずある黒い区画は、マーカーの方向を決めるためのものです。これだと3×3×3で27通りのパターンを作成することができます。
これを実際に使用すると、以下のようなことがわかりました。
・右下の黒い区画をマーカーの黒枠だと誤認してしまう。
・青が黒に近いので、これもマーカーの黒枠だと間違われることがある。
つまり、マーカー内部に黒に近い四角形があると、誤認の確率が高くなることが判明しました。
この教訓により作成したのが、次のマーカーです。


なんだか顔みたいですね。
まず、右下の黒い区画を白に変え、次に他の色が四角形にならないように、凹を入れました。あと余計な隙間も一応埋めました。
これで、だいぶ誤認しないようになりましたが、どうせ凹を入れるなら、色によって位置を分けたほうが、個体差が大きくなります。


今回のパターンでは色によって凹の位置が違います。
というわけで、動画で使われているマーカーはこのパターンになりました。
次は凹をもう少し小さくして、試してみます。
※訂正
パターンの凹を小さくして実験しましたが、どうやらこの凹は要らないようです。
ARToolKitでは黒枠を認識するときに、画像を2値化してます。(パターン認識の時はもちろんカラー画像を使う)
そうなるともう色は関係なく、明るいか暗いかのみの違いになります。
つまり、色の領域が外枠と接してさえいれば、四角形と認識されることはなくなるのです。
しかし、凹が黒枠の誤認識に効果がなくても、各パターンの誤認識には効果があるかもしれません。
とりあえず、この凹なしのパターンで実験を続けてみて、誤認識の割合を見てみることとします。
「ARToolKitの安定化 その②」は、関係計算時の動作についてです。
BGM:エコテロニカ(sansuiさん)
今回のプログラムでは、3Dモデルの補完の際に用いる関係値を、事前に計算しなければなりません。
しかし、その計算はほぼ自動で行われます。
○計算時の動作は、大まかに言って以下のようになります。
1.モード切替
プログラムのモードを、計算用に切り替える
2.マーカーの認識
画面内のマーカーを認識して、各マーカー座標系からカメラ座標系への変換行列を求める(ここまでは今までと同じ)
3.マーカー間の関係を計算
マーカーが複数見つかった場合は、それぞれの変換行列を用いて、
その関係行列(マーカーA → マーカーB という座標系変換行列)を計算する。
4.関係の平均値を計算
これをフレーム毎に行っていき、関係行列の平均値を計算する。
5.計算情報を描画
平均値のサンプル数や誤差も計算し、この情報を画面に描画して、計算の頃合をユーザーに知らせる。
6.他のマーカーに移る
ユーザーはこの情報を見て計算が大体終わったことを知り、次のマーカーの処理に移ります。
7.全部終わったら、モードを戻す
上記の処理を、「同時に表示できるすべてのマーカー」に対して行えば、基本計算は終了です。確認モードに戻して、ちゃんと計算できているかをチェックします。
8.全体の再計算
全体的に上手くいっていない場合は、すべての数値をリセットして、再計算を行います。
9.個々のデータのみ再計算
いくつかのマーカーのみが上手くいっていない場合は、該当のマーカーのみをリセットして、再計算することもできます。
10.データの保存
最後に、このようにして作成したデータを保存し、再起動時や他のプログラムで使用できるようにします。
以上が、関係値計算時の大まかな処理です。
BGM:エコテロニカ(sansuiさん)
今回のプログラムでは、3Dモデルの補完の際に用いる関係値を、事前に計算しなければなりません。
しかし、その計算はほぼ自動で行われます。
○計算時の動作は、大まかに言って以下のようになります。
1.モード切替
プログラムのモードを、計算用に切り替える
2.マーカーの認識
画面内のマーカーを認識して、各マーカー座標系からカメラ座標系への変換行列を求める(ここまでは今までと同じ)
3.マーカー間の関係を計算
マーカーが複数見つかった場合は、それぞれの変換行列を用いて、
その関係行列(マーカーA → マーカーB という座標系変換行列)を計算する。
4.関係の平均値を計算
これをフレーム毎に行っていき、関係行列の平均値を計算する。
5.計算情報を描画
平均値のサンプル数や誤差も計算し、この情報を画面に描画して、計算の頃合をユーザーに知らせる。
6.他のマーカーに移る
ユーザーはこの情報を見て計算が大体終わったことを知り、次のマーカーの処理に移ります。
7.全部終わったら、モードを戻す
上記の処理を、「同時に表示できるすべてのマーカー」に対して行えば、基本計算は終了です。確認モードに戻して、ちゃんと計算できているかをチェックします。
8.全体の再計算
全体的に上手くいっていない場合は、すべての数値をリセットして、再計算を行います。
9.個々のデータのみ再計算
いくつかのマーカーのみが上手くいっていない場合は、該当のマーカーのみをリセットして、再計算することもできます。
10.データの保存
最後に、このようにして作成したデータを保存し、再起動時や他のプログラムで使用できるようにします。
以上が、関係値計算時の大まかな処理です。
順番が逆になってしまいましたが、動画で紹介した内容を書きます。
最初に、ARToolKitについてまったく知らない方は、youtube等で作品を検索してみるのが一番早いかと思います。
AR(augmented reality)(拡張現実)とはVR(virtual reality)(仮想現実)に近い言葉です。
VRが現実に存在しない仮想空間をメインにするのに対し、ARは現実世界がメインで、そこに対して情報を付加したりします。
ARToolKitはそんなARの技術の1つを、なんとフリーで公開しています。なので、研究レベルのアプリを個人でも作成できてしまうというすばらしいツールなのです。
現在、ネット上の動画サイトで、このツールを使った作品が多数製作されています。
さらに、ARToolKitのプログラムに興味がある方がこちらをご覧ください。
工学ナビ:「攻殻機動隊」「電脳コイル」の世界を実現! - ARToolKitを使った拡張現実感プログラミング
さて、僕が作成したプログラムも、そんなARToolKitを使い、作成したものです。
BGM:エコテロニカ(sansuiさん)
このプログラムは、複数のマーカー間の関係を検出して、その関係を用いて3Dモデルの表示を安定化させるためのものです。
そんなすばらしいARToolKitですが、プログラムには欠点もあります。その1つが、「3Dモデルが消えやすい」というものです。モデルは以下の条件で、簡単に消えてしまいます。
・黒い枠を認識できなかったとき
・内部のマーカーを認識できないとき
・マーカーが画面の外に出たとき
・マーカーを裏返したとき
・カメラを少し早く動かしたとき
最後の、「カメラを早く動かしたとき」という問題は、カメラの性能やマシンスペックが原因の場合が多いので、ここでは無視しました。
この問題を解決する手段として、MultiMarkerというプログラムがARToolKitに入っています。
しかし、MultiMarkerではマーカー間の関係を自分で定義しなくてはいけません。また、復元できる座標系も1つだけです。
ちなみに、その関係をあらわすデータは以下のようなものです。
marker 1をベースとして、marker 2、marker 3にはmarker 1との関係(座標系の変換行列)が書かれています。
単純なマーカーの配置なら、このように簡単な数値になりますが、ちょっとでも配置をずらすと、数値は急に複雑になります。
そこで、僕の作ったプログラムでは、この数値を自動計算します。
そうすることにより、もっと自由に複数のマーカーを配置して、モデル表示の高い安定性が保てるようになる、という訳です。
最初に、ARToolKitについてまったく知らない方は、youtube等で作品を検索してみるのが一番早いかと思います。
AR(augmented reality)(拡張現実)とはVR(virtual reality)(仮想現実)に近い言葉です。
VRが現実に存在しない仮想空間をメインにするのに対し、ARは現実世界がメインで、そこに対して情報を付加したりします。
ARToolKitはそんなARの技術の1つを、なんとフリーで公開しています。なので、研究レベルのアプリを個人でも作成できてしまうというすばらしいツールなのです。
現在、ネット上の動画サイトで、このツールを使った作品が多数製作されています。
さらに、ARToolKitのプログラムに興味がある方がこちらをご覧ください。
工学ナビ:「攻殻機動隊」「電脳コイル」の世界を実現! - ARToolKitを使った拡張現実感プログラミング
さて、僕が作成したプログラムも、そんなARToolKitを使い、作成したものです。
BGM:エコテロニカ(sansuiさん)
このプログラムは、複数のマーカー間の関係を検出して、その関係を用いて3Dモデルの表示を安定化させるためのものです。
そんなすばらしいARToolKitですが、プログラムには欠点もあります。その1つが、「3Dモデルが消えやすい」というものです。モデルは以下の条件で、簡単に消えてしまいます。
・黒い枠を認識できなかったとき
・内部のマーカーを認識できないとき
・マーカーが画面の外に出たとき
・マーカーを裏返したとき
・カメラを少し早く動かしたとき
最後の、「カメラを早く動かしたとき」という問題は、カメラの性能やマシンスペックが原因の場合が多いので、ここでは無視しました。
この問題を解決する手段として、MultiMarkerというプログラムがARToolKitに入っています。
しかし、MultiMarkerではマーカー間の関係を自分で定義しなくてはいけません。また、復元できる座標系も1つだけです。
ちなみに、その関係をあらわすデータは以下のようなものです。
#the number of patterns to be recognized
3
#marker 1
Data/multi/patt.a
40.0
0.0 0.0
1.0000 0.0000 0.0000 0.0000
0.0000 1.0000 0.0000 0.0000
0.0000 0.0000 1.0000 0.0000
#marker 2
Data/multi/patt.b
40.0
0.0 0.0
1.0000 0.0000 0.0000 100.0000
0.0000 1.0000 0.0000 0.0000
0.0000 0.0000 1.0000 0.0000
#marker 3
Data/multi/patt.c
40.0
0.0 0.0
1.0000 0.0000 0.0000 200.0000
0.0000 1.0000 0.0000 0.0000
0.0000 0.0000 1.0000 0.0000
marker 1をベースとして、marker 2、marker 3にはmarker 1との関係(座標系の変換行列)が書かれています。
単純なマーカーの配置なら、このように簡単な数値になりますが、ちょっとでも配置をずらすと、数値は急に複雑になります。
そこで、僕の作ったプログラムでは、この数値を自動計算します。
そうすることにより、もっと自由に複数のマーカーを配置して、モデル表示の高い安定性が保てるようになる、という訳です。
