libtorchでis_avaiable()がFalseを返すのを直したときのこと

Windowsで機械学習で有名なpytorchのc++ apiであるlibtorchを使い始めたが、たびたび？？？となることにぶつかる。

直近で当たったのが、ライブラリのバージョンやドライバーなどちゃんと整えたうえで、CUDAの利用が可否か問う関数、

torch::cuda::is_available()

で、0,falseが返ってきて、なぜか使えないと判定されたことである。

念のために、pythonで、

import torch

torch.cuda.is_avaiable()

を投げると、Trueで返ってくる。

つまり、torch的にも計算機の環境としてはCUDAが整っているのに、Libtorchを通した時におかしいという状態である。

考えてみると、これはDLLが別のものを指している可能性があって、Libtorchのフォルダ内のdllを先に参照できていないことが示唆される。

ということで、システム環境変数のPathを見てみると、libtorch/libが通っていないので、先頭に追加した。

結果、ちゃんと1, Trueが返ってきて、かつ、

device_type = torch::kCUDA;

torch::Device device(device_type);

model->to(device);

cout << "Is module CUDA? " << model->parameters()[0].is_cuda() << endl;

によって、GPUへの転送もうまくいっていることを確認できた。

PCAのコード

 毎回書き直すので、基本的なPCAを計算するコードを載せておこう。前も載せた気がするけど、ま、いいや。

c++でライブラリにEigenを使っている。

実験として、2次元10個のデータのmatのPCAを計算する。

とりあえず、ランダムのデータにする。

Eigen::MatrixXd mat(10, 2);

for (int i = 0; i < mat.rows(); i++) {

for (int k = 0; k < mat.cols(); k++) {

mat(i, k) = (double)(rand() % 100) / 10. + 50.*(double)k;

}

}

本編は以下で、PCAを使って2次元を1次元にプロジェクションする。

Eigen::MatrixXd aligned = mat.rowwise() - mat.colwise().mean();

Eigen::JacobiSVD<Eigen::MatrixXd> svd(aligned, Eigen::ComputeThinV);

Eigen::MatrixXd W = svd.matrixV().leftCols(1);

//これが主成分方向の内積の集合のベクトル

Eigen::MatrixXd dot_on_plane = aligned * W;

Eigen::MatrixXd projected_one = dot_on_plane * W.transpose();

Eigen::MatrixXd projected = projected_one.rowwise() + mat.colwise().mean();

llvmでハマる

llvmを使うことがあって、とりあえずのつもりで入れたプリビルト版のllvmの参照がうまくいかず、 むーんと思って、手元でmakeしてビルドしたら動いた。環境がそんなに違うってことないはずなんだけど、どうも相性というのがあるみたいで、面倒でも手元でビルドが確実だなと思うなど。

ちなみに、llvmというのが何かいまいちわからないまま、インストールしたのだが、それを使った今ですら、これが何なのかよくわからん。プロジェクトのページを見てもわからないし、もうこれ以上は気にしないことにした。ひとつわかったのは、ビルドに時間がかかる大きめのソフトウェアであることは間違いない。

CGAL intersectionは汎用的に作られているため、型が分からずバグるのか

接触判定のプログラムでの問題が起こった。

CGALのintersectionで三次元の三角形の接触部分の線分をとらえようと、テストコードを組んだ。それはうまくいったので、次に本プログラムに組み込んだら、なぜか接触している三角形の判定が漏れ始めた。

すると、こんな記事を見つけた。

https://stackoverflow.com/questions/32951886/wrong-inexact-intersection-between-3d-triangles-cgal/32965564#32965564

質問者も私同様に、接触判定漏れの問題を指摘している。その回答で、do_intersectしてから、intersectionを呼ぶと、型が分からず変な挙動をするとのこと。たしかに私もdo_intersectを呼んだあとなので、挙動としては同じである。

Cartesian_converterを使えば正しい呼び出しになるとのこと。

具体的な使い方は、こちらにある。

https://doc.cgal.org/latest/Kernel_23/classCGAL_1_1Cartesian__converter.html

結果、たしかにうまくいった。

私の場合、メッシュ処理のPMP::do_intersectを呼んだあとに、三角形の型Exact_predicates_inexact_constructions_kernel::Triangle_3で接触を見ようとしていたため、この問題が起こった。

この型をコンバーターを使った例の通りに変更するだけで、問題が消えた。

二つのメッシュの接触のメモ

CGALでの二つのメッシュの接触判定と結果の取得方についてのメモ

https://stackoverflow.com/questions/22900932/cgal-meshes-intersection-collision

良記事。手元で実験済みでうまくいくことも確認した。

face_descriptorのidx()はメッシュのindexで、二つのメッシュについて、pair<face_descriptor,face_descriptor>が出力の１要素となる。

vectorで出力されるので、back_inserterを引数で忘れないように。

CGALで形状の近似が実装されてたというメモ

 https://doc.cgal.org/latest/Surface_mesh_approximation/index.html#Chapter_Triangulated_Surface_Mesh_Approximation

figure 74.10が結構理想的

DTP操作のために、プログラム組んでたら、単位でハマった

ファブリケーションの研究しているとどうしてもフォーマット関係でハマります。

今回はDTPで扱うような、ベクター形式の画像の単位でハマりました。プログラムで印刷前提に、ベクター形式を出力しようというモチベーション自体があまりないので、情報も少なく、意図を手繰るような感じで、実験してわかったことをメモっていきます。

ここでの目標はベクター形式の画像をラスター画像と同じソフトで扱いたいというものです。

ベクター形式で画像を出力すること自体は実は簡単でした。svgというフォーマットを使えば、テキスト出力だけで、画像が出せます。文だけ読むと意味わからないのだけれど、テキストデータが、解釈されて、ベクター形式の画像として扱えるフォーマットがsvgです。ルールについては、ほかのページに任せるとして、fstreamなどのファイル出力で実現可能なのは確認済みです。ストリームで出力するとき、数値はダブルクォーテーションを入れる必要があるのですが、このとき\"として、ダブルクォーテーションを出力することだけ覚えておけばOKです。

出力された画像の長さの単位が、イラストレーターとかで開くと、ポイントという単位として扱われます。このポイントという単位は、フォントとかでしか見ないので、具体的に何ミリメートルかなんて考えることがありませんが、私はラスター画像と一緒に使いたいので、単位の換算を知る必要があります。ラスター画像の単位はmmやinchで指定はできますが、基本的には、dpiかppiを使います。dpiはdots per inch でppiはpixels per inchです。dotsはインクの粒で、pixelsは画像の粒であるピクセルです。ラスター画像では、ピクセルで色を指定するので出力を考えるとppiを単位とすることが多いです。例えば、ppiで300と指定すると、1inch=25.4mmに、300個のピクセルを並べるという、ことになります。このppiに、ベクター形式内の1という単位を無理やり合わせるにはどうしたら良いかを考えます。

ベクター形式での1という単位は、先に述べたようにポイントとなります。ポイントとインチの換算は決まっていて、1inchの中に72ポイント並べられます。1inchの換算の比率さえ合えば、単位を調整できるので、ppiのほうに無理矢理ベクター形式の1をあわせるなら、xをppiの数値とすると、72/xを係数として、ベクターの数値に掛けてやればOKとなります。具体的には、300ppiの画像に合わせるためには、ベクター形式の1を72/300かけたものでぴったり解像度が合うようになります。

具体例を挙げると、svg形式で、1ピクセル分を1×1の正方形で表現すると、300dpiの1ピクセルと合わせるには、72/300×72/300の正方形とすると、ぴったりあうということです。

終わり

グーグルマップ保存

いつも現地に着いてから地図を探していたのですが、グーグルマップをオフライン保存できることを知ったので、やってみました。

http://www.iscle.com/web-it/g-map-offline.html


１．google mapでログイン
２．左上の三本線をタッチして、メニューを出す
３．マイプレイスをタッチ
４．一番下にあるオフライン用に地図を保存をタッチ

これでOK。

ぶったまげ

アイスクリームを食って，ぶったまげた．
こんなことってあるのね系．

最近体が疲れまくっているのでアイスクリームを頻繁に食べるようになりました．
よく食べるひとつに，グリコジャイアントコーンがあります．
パッケージは気にしないことが多いですが，気にして見ると，特許番号が書いてあります．
特許4216785
気になります．
なので，特許庁IPDLの特許・実用新案公報DBで調べてみました．
文献種別は特許:B，文献番号は4216785．
すると，特許権者に２法人が挙げられています．
ひとつはグリコ．そしてもう一つは某印刷会社．
特許の内容はパッケージの構造についてです．
印刷会社はだいたい裏方です．
でも，技術では表に出てるのですね．ということで，驚きです．

名言を聞いた

「童貞は未来のこと以外に考えるべきことがないんだよ」

友人がとても創造的なことを考えていたので，「時代の先言ってるぜ」と言ったところ返ってきた言葉です．
非常に感動しました．

maya mental rayでメモリに制限かかってレンダリングできなかったら

走らなかったら次の3ステップで走るかも．
① 左下のMEL欄で
select mentalrayGlobals;
と叩く

② 追加のアトリビュートのタブをクリックし，開いたタブの
自動メモリのチェック
を外す

③ 自動メモリのチェックのすぐ下の
メモリゾーン
を高くする

ちなみにメモリ制限でレンダリングできないときの警告は，
(Mayatinr.script): Computed memory limit of -XXXMB is below threshold, setting to XXX MB insread

XXXはたぶんものによって違う．知らんけど．

つくば旅

さて，くだらない文句言ってないで，某つくばの旅でもまとめてみます．

二日間いましたが，とにかく寒かったです．
パーカーとジーンズ，マフラーで過ごしましたが，震えるくらい寒かったです．

つくばの道路はこんな感じでした．

車がすごく多い印象．
また，運転が荒らそうに見えました．
めちゃくちゃ寒いのにオープンカーを運転しているおっさんとかを見ました．

この次の写真あたりから筑波大学の構内．

ヘリポート？

という感じです．
大学内には学生が多くいました．

今回は某研究会に参加してきました．
CGとCVの合同の研究会でした．
合同だったおかげで，ふたつの研究会の文化の違いを感じることができました．
CG関係で見たことある先生の多くはスーツを着ていませんでした．発表中に発表者にいきなり質問したりしませんでした．

一方，CV関係の先生の多くがスーツを着ていました．発表中にいきなり質問する人もいました．

それ以外は，さほど違いは感じませんでした．

発表に関してですが，多くの発表者が時間内に発表を終えていないようでした．

時間は守ろうぜ，と念じながらの参加になりました．

懇親会では，いつも通りおとなしくしておりましたが，数名の方とお話ししました．
はじめてお話しする人もいました．
顔見知りが増えてよかったと思います．

このような懇親会は，国内トップ層と直に，研究内容ではなく，人間を見れる珍しいチャンスなので面白いです．

研究会には，私が所属している研究所の人も数名参加しており，少し話をしました．

ドライな冗談を聞きましたが，それくらい仲が良く，風通しがいいということでしょう．

こんなもんでしょうか．

とにかく発表は面白いので，周りの学生も活発に発表するようになればいいと思います．

それとmasafumiさんはやっぱり有名人で，いろいろ聞かれたので，聞いてきたやつらに嘘8億吹き込んでおきました．これで超絶いい人だと勘違いした人が増えると思います．

驚懼疑惑が起こるなんて当たり前だから常に正常な判断できるようにしておけという理解

驚懼疑惑を克服するということは，驚いたり恐怖したり疑心を抱いたり惑ったりということが心に起こると，正常な判断ができなくなるから，心を鍛えて恐懼疑惑を起こらないようにしておく，ということなのだけれど，恐懼疑惑しない人なんてあまりいない．
どういうわけか，この世では想像もつかないことが簡単に起きる．
いくら準備しておいても，恐懼疑惑するのだから，しょうがない．
だから，恐懼疑惑を避けるよりも，恐懼疑惑したときでも正常な判断できるように，正常な判断の基準を自分の中で持っておいて，いかなるときにも，その基準を満たすように活動しておくことが大切だと理解しています．
今のところ．

32bitグレースケールはfloatで[0,1]の値

グレースケール形式にハマりました．

一般的なグレースケール画像は8bitグレースケールですが，より分解能が高い形式もあり，16, 32, 64bitグレースケールがあります．（たぶん今後はもっと分解能上がる）

8bitグレースケールは，画素あたり[0,255]整数で表現されるので，一般的に整数で表現します．
プログラミングでの書き出しもこの範囲の整数で書きだします．
しかし，同じノリで16,32,64も整数で記述するものと思っていたのですが，違ったようです．
32,64は整数で扱うソフトウェアがかなり少なく，浮動小数点形式が一般的のようです．
このような情報をどこかに明記してくれていればありがたいのですが，見つからなかったので，photoshopでグレースケール画像を生成して，tiff形式で保存して，tiff画像のタグを見ることで，知ることができました．

はじめに，16bitと32bitグレースケールをtiff形式で作ります．
次に，TIFFの分析ソフトを使ってタグを見ます．私はTiffAnalyzerを使いました．
http://www.vector.co.jp/soft/mac/art/se136821.html

タグを見た結果，16bitグレースケールのときは，タグなしだったのに，32bitグレースケールでは，sampleformatが3になっていました．
sampleformatが3の意味は，浮動小数点形式で画素を表現するということです．
下のページは，TIFFのタグ「sampleformat」について書かれたページです．
http://www.awaresystems.be/imaging/tiff/tifftags/sampleformat.html


32bitで浮動小数点といえば，floatなので，保存はデータをfloat形に変換して出力することがわかります．
また，実験的に生成したグラデーションのデータを観察すると[0,1]表現だったので，32bitグレースケールはfloatの[0,1]で表現することがわかります．

この条件を満たすように32bitグレースケールを生成して，いろんなソフトで開けるかを実験します．

作った32bitグレースケール画像は，ウィンドウズ7の標準のビューワーやphotoshopなどなど複数のソフトウェアで開くことができました．

一方，実験の中で作った，整数型のグレースケールは32bit指定しても，多くのソフトウェアで開けませんでした．

ということで，既存のソフトウェアで32bitグレースケール画像を開けるような画像を生成したときは，floatに変換して書きだす必要があります．

桁違い

例にもよって，このブログでは研究活動の内容を書かないようにしているのですが，ちょろっとメモ．

今，M先生と論文原稿テニスをしているのですが，その中で桁違いの実力の差を感じました．
先生はものすごく編集が速いのです．
今回のテニスでは，編集にMS Wordを使っています．
いつからか知りませんがWordでは，リボンのファイルタブの情報という項目で編集時間が見れるようになっています．
その機能を使って，意図的ではないですが，先生の編集時間を知ってしまいました．
ものすごく短いのです．
6から7ページの原稿を概ね1時間で編集しています．

私は一文の書き方が決まらずに1時間過ぎてしまうことがあるというのに，先生はそうこうしている間に一編を適切に編集してしまうわけです．
自分の場合は一時間かけても不適切なことがあるのに，と思うと，もう桁違いだと諦めるほかありません．
やはり先生と呼ばれる先生は，あーでなくっちゃ駄目だと思いました．

maya 2011 plugin作成メモ

VS2010で開発してますが，VS2010ではmayaのプラグイン開発用ウィザードが走ってくれないため，手動でプロジェクトのプロパティを編集するほかありません．
ネット上でどこもまともなこと書いてないので，実験しながら適当にプロパティ変更しました．
そして走ったので，変更点のメモです．

プロジェクトをwin32コンソールアプリケーション（DLL）として作成します（空のプロジェクトの必要なし）．
プロジェクトを作成後，cppファイルがなければ作成します．
その後，プロパティページの「構成プロパティ」内の以下4点を変更．
1. 「全般」→「ターゲットの拡張子」をdllからmllに変更．
2. 「C/C++」→「全般」→「インクルードディレクトリ」と「リンカー」→「全般」→「追加のライブラリディレクトリ」はmayaのincludeとlibフォルダを指す．
3. 「リンカー」→「コマンドライン」→「追加オプション」欄に，
/export:initializePlugin /export:uninitializePlugin
を記述．
4. 「リンカー」→「入力」→「追加の依存ファイル」欄に
Foundation.lib
OpenMaya.lib
OpenMayaUI.lib
OpenMayaAnim.lib
OpenMayaFX.lib
OpenMayaRender.lib
Image.lib
を記述

以上4点の変更でmaya2011に読んでも走るpluginができました．
変更点以外はデフォルトのままです．
VS2008のときはもっと変更点があるような文書もありましたがそんなの知りません．
コードはapiを呼んで，initializePluginとuninitializePluginを書いておけば問題ありませんでした．

内部の例外を見えなくする件

しばらくCGALを触っているとVCのデバックにて， CGAL::Uncertain_conversion_exception という例外のメッセージを目にします．このメッセージはCGALのFAQによると無害のメッセージとのことです．ということは見えなくても問題ではなく，ただただ鬱陶しいだけです．同様に思っている人が表示させない方法を紹介してくれてるのでメモです．

http://www.helixoft.com/blog/archives/24

計算誤差のせいで現れるセルの排除

3次元ドロネー図を計算させるとき，計算誤差のせいでありもしないドロネーセルが呼ばれることがありますが，それは体積を計算して，極々小さいときに排除することで解決できます．
原因がわからなかっただけに二日も費やしてしまいました．

某舘山寺温泉に行ってきました

いってまいりました，某ワークショップに，某舘山寺温泉に．
受講の都合で，後半からの参加になりましたが想像以上に楽しかったです．
他大学の学生との交流もほどほどにできました．
それに温泉にもつかってきました．その場では，家で入ってる風呂と大差ない気がしましたが，疲れも無くなりましたし，実際は効果あったような気がします．
夕飯のコースもおいしかったです．

発表は最後のセッションの最後でして，皆疲れている様子でしたが，お構いなしでよくしゃべれました．おしゃべりの内容はテクスチャです．詳細は教えません．会場からの質問も見た中では最も多かったですし，興味を持っていただいたようでした．質問の内容は，発表した手法をより一般的に使えるようにするための議論（高さのみならず色や材質，メッシュに依存しないようにするためには等々の議論）や入力情報を足して操作性を上げるための議論がメインでした．
実はこれらの質問は，事前にM研究室で行った発表練習のときに修士2年の学生から出た質問と似たような内容でした．つまり国内のCG界のトップ層と同等の質問ができるくらいに，ここの修士が育っていることがわかりました．

はい，これで発表が終わり，会場を後にし，某M先生と一緒に浜松に行って鰻を食べてきました．行った店は，某清水屋です．某早稲田の博士後期の学生(自称M先生ファン)が先生に教えてくれたそうです．
で，しばらく待っていたのですが，出てきたうな重は最高においしかったです．これまで食べてきた鰻とは別格においしかったような気がしました．最近良いものを口にしていないので，特にそのように思ったのかもしれませんが，とにかくおいしかったです．サブのくせにビビビッと来たのが肝吸いでして，一口すすっただけで，ニヤリです．ちなみにおごってもらいました．また頑張ります．
あんなにおいしいものを食べて思ったのが，あんなのばっかり食ってたら人間ダメになる．

そういえば，食べ終わったあと，先生が手のにおいを嗅いで「鰻くさい」と言ってましたがその時は理解できませんでした．電車乗って自分が鰻くさいことに気付きました．

そんなこんなで，時間もないので，さっさと帰ってきました．

cmake→slnファイル→ビルド

インストールメモ．
CMAKEしたあと，作られたslnソリューションファイルを開いて，ビルドしなければ，ライブラリが生成されません．ビルド時は，ソリューション構成が4つ選択できるので，それぞれのビルドします．これでライブラリが生成され，参照できるようになります．