蛙の末裔の妄創手帖

　スクールLiveShow in静岡、一回目が放送されましたね。研究室でも、残っていた面子で拝見しました。
　てっきり、一回目が製作風景中心、二回目が競技中心になると思っていたのでいきなり試合になったのには面食らいましたが、確かにこれもひとつの形ですね。特に、こういった番組では個々の作品とそれを作った子供たちにフォーカスすべきですから、それに適した今回の編集はなかなか良かったんじゃないでしょうか。（なんという上から目線……。）
　番組の中身の方は、一回目で前半二試合が放送されたわけですが、これだけ見ると森下小が圧倒しているように見えますね。現場にいた私には拮抗しているように見えたので、試合毎に点数を出していくとこうも印象が変わるのかという感じでした。

　それと、車載カメラの映像がまともだったのは幸いでした。（もしかすると大半は使い物にならない映像だったのかもしれませんけど。）個人的に、あのカメラ用ポールは手作業で加工したので思い入れが強いのです。
　そもそも、あの車載カメラは途中で追加された仕事で、依頼の際にはガングリップ型のビデオカメラを載せたい、という情報しか有りませんでした。仕方が無いのでとにかく汎用性を上げ、高さ調整8段階、角度調整12段階、搭載カメラのサイズも2種類に対応という仕様にしています。その上、もしも当初の計画通りレーザー加工機が使えていれば、高さ調整は無段階(!)になっていたはずだというのですから、我ながらよく気を遣ったというか、思い切りが悪かったというか。幸か不幸か、現場では高さ調整を一回やっただけで他は初期位置に固定したままだったんですけどね……。

　ということで、放送は次回もあるわけですが、どうもそれは研究室の飲み会の最中に見ることになりそうです。
　うーむ、これはちょっと警戒ですねぇ。今日の感じだとどうやら映ることはなさそうだ、とはいえ。
 

　研究室のとあるM2さんが扱っているテーマでは、お医者さん提供のDICOM形式CT画像を有限要素解析まで持っていかなければなりません。今日はこの課題に、私とD2の先輩の二人が取り組みました。当然ながら私もD2の先輩も研究テーマは別にあるのですが、いろいろあってそういう流れになってしまったわけですね。いろいろあって。

　タスクの内容をもう少し具体的に述べますと、raw形式の連番X線CT画像が入ったDICOMファイルがあって、それに写っている物体をANSYSのプリポストで読み込めるモデルにする、というものになります。ちなみに、内輪の話になりますが（まぁ全部内輪ですが）、当初はFEAをPro/EngineerのMechanicaで行うという話で、ゴールはSTLファイルで良いんじゃね？と思われていました。ただ、STLは物体表面を三角形パッチで覆っただけのサーフェスデータなので3DCADに取り込めはしても、すぐには解析出来ません。つまり、何とかしてソリッド化して、立体のメッシュを切る必要がある。
　そこでさぁM2さんよ。そのことに”今気付いた”、みたいな顔をしないでおくれや。一年前から判っていた話じゃないか。

　そんなわけで、サーフェスモデルのSTLじゃなくてソリッドモデルが欲しいよ！と言われてしまったのが、まぁ今日のスタートでありました。
　結論から申し上げれば、出来ました。よりによって私とD2の先輩と、二通りで。以下はその手順の概略です。

(1)先輩
DICOMファイル
　　　↓　　　←自作ツール
CT画像のrawデータ
　　　↓　　　←研究室オリジナルのメッシュモデル作成ソフト
四面体要素でメッシュが切られた中間ファイル（NISAというFEAソフトのファイル形式なんですが）
　　　↓　　　←自作ツール
netgenのニュートラルファイル（.mesh）
　　　↓　　　←netgen（サーフェスデータから四面体メッシュを生成してくれるフリーソフト）
ABAQUS用入力ファイル（.inp）
目出度しめでたし。

(2)蛙
DICOMファイル
　　　↓　　　←DeVIDE（修正BSDライセンスのフリーソフト）
サーフェスデータ（.stl）
　　　↓　　　←MeshLab（3次元メッシュを編集できるフリーソフト）
修正されたサーフェスデータ（.stl）
　　　↓　　　←netgen
ABAQUS用入力ファイル（.inp）
目出度しめでたし。

　御覧の通り、フリーソフトを漁ってなんとかした蛙と、自作のツールをもりもり書いて仕上げた先輩、なんとも対照的なルートを辿っています。
　肝心の成果物の出来ですが、これはD2の先輩が作ったメッシュモデルのほうが形状に忠実でした。メッシュ品質に大差は無いので、私の手順は完敗です（別に競っているつもりはありませんでしたが）。
　まあ、元々CT画像はボクセル状のソリッドデータであるとも言えるので、ソリッドのまま攻めるか、間にサーフェスデータを挟むか、というところで命運が決した気はします。stlのサーフェスデータって元の表面形状に忠実なのは良いんですが、メッシュ品質という面から見ると酷いことが多いんですよね。今回も、DeVIDEから吐いたばかりのstlファイルには妙にでかい三角形が居たり、かと思えば小さな三角形がやたらと密集した部分が有ったりでnetgenでメッシュが切れませんでした。仕方なくMeshLabでスムージングをして表面を滑らかにしたわけですが、こういう過程を辿ればそりゃ元の形は保たれません。M2さんのテーマ的に、形状が不正確なのは致命的なので、私がやった方法は多分にお蔵入りでしょう。うー、最初はstlを使うって言ってたからそうしたのになぁ……

　話が離れますが、上の手順を見比べていると、ソフトを使うだけの人間か、ソフトを作る人間か、という違いが如実に現れていて興味深くもあります。そして、作る側の人間でないとしゃんとした結果は出せない、というこの結果も。
　やっぱり、研究をするなら作る側でなくてはいけないということですね。押忍。



　ちなみに、DICOMのCT画像をstlファイルにするためのDeVIDEの操作手順はこの動画ヘルプで説明されていました。

　このDeVIDE、オランダのデルフト工科大学で作られているそうなのですが、何やらいろいろ出来るみたいで面白そうです。といいますか、そもそもDICOMを.stlにするという作業でさえwindows上ではなかなかフリーで出来ないわけですから（MacならOsirixがありますが）、これからDeVIDEのユーザーは増えるんじゃないかなぁ、と思っているものでもあります。

　最後に、Macユーザーなら使えるというOsirix（オザイリクス）。まぁ研究室にWin機しかない蛙としては指をくわえて見ているしかないのですが、初見だったら”おしりえっくす”って読んじゃいませんか？

　すみません。ごめんなさい。