iPhone-LiDAR + Scaniverse or Metascanから書き出された点群とメッシュを比較 estimating point cloud and mesh exported by Scaniverse or Metascan for iPhone-LiDAR

はじめに

 ぼくは混乱状態になってきたので,ここで整理したいと思う。その上で,CloudCompareやMeshLabでのぼくの利用姿勢を正すことができる。

1 2セットの段ボール三箱と神武天皇遙拝所碑のLiDAR撮影

 この章は全く自分用の覚え書きである。3Dデータの欠損をMeshLabを使って穴埋めする で示したように,MeshLabへのメッシュOBJの読み込みの際に,ファイル名に注意を払うべきことに気付いた。ファイル名内に空白spaceを入れてはならないことである。2バイト文字日本語も入れない方が良いとも考えている。
 図1には,二つのファインダーが見える。Wikipediaによれば,「ファインダー: finder)は、カメラにおいて撮影前に目で構図を決めたりピントを合わせたりするのに使用する覗き窓など」とある。そういえば,アナログカメラを使っていた時代にこのファインダーは自分の言葉として定着していた。macのファインダーの名称はここから来ているんだなあ。今更の気付きだけど。
 このファインダーの左部は,2023年1月11日に撮影したものである。OBJファイルだけは1月25日の日付があるが,これはMeshLabへのOBJ読み込みが出来ず,iPhone 12 ProのScaniverseで名称変更をする必要性があって,出力し直したためである。OBJ以外についてはファインダー上で直接,修正した。
 この1月11日の撮影は1月7日にMetascanでの撮影結果に愕然とした結果である。1月7日にMetascanで段ボール三箱と神武天皇遙拝所碑を撮影したが,いずれも線分を表現できず,がっかりして,次点候補だったScaniverseに望みを託したからであった。そしてScaniverseがMetascanと比べると遙かに線分の再現性が高いことを実感した。その結果が左のファインダーなのである。Metascanで取得したものは線分が歪んでいるので,表示対象にしなかったので,Metascanの出力ファイルは無い。
 で,右のファインダーのファイルは1月26日に撮影をし直したものである。上記の学習のゆえに,ファイル名は英数字のみにし,スペースも排除している。ただ,Metascanで撮影したファイル名は,metascan_20230126_1536_ぼくの命名,となる。記録する上でこの接頭辞は邪魔ではないが,ぼくの命名自身に含まれている内容なので,ぼくの命名法をMetascanについては変更した方が良いと思われる。その変更結果を図2に示したいと思う。
 図1の左のファインダーを見ると,Scaniverseによる出力ファイルは,メッシュ(OBJ, FBX),点群(LAS, PLY)である。LASについては,iPhoneでも使えるようになったLiDARの標準ファイル形式「LAS」ってどんなデータなの?を、PDAL/Laspyを使って調べてみる。で解りやすく説明されているが,ぼくには今のところ不要で図2では削除している。
 図1の右のファインダーを見ると,どうもエキスポートしたあとで,ファインダーで各ファイルを個々のフォルダーに整理したようである。図1の左のファインダーでは整理されていないが,実はmouseWindowsでは同様に整理している。CloudCompareでの作業ファイル群の名称が単純で元ファイルとの関係がわからなくなるために,iPhone 12 Proからエキスポートされたファイルを個々のフォルダーに入れる必要があった。その経験を踏まえて,macのファインダーでその作業を実行したのである。図1の右ファインダーでは上から見ると,段ボール三箱では,Metascanによる,メッシュOBJ,点群PLY,Scaniverseによる,メッシュOBJ,点群PLY,神武天皇遙拝所碑では,Scaniverseによる,メッシュOBJ,点群PLYが見える。神武天皇遙拝所碑については,1月7日にMetascanでLiDARと写真測量を丁寧に実施し直線の復元ができなかったので,実施しなかった。このファイルをmacにダウンロードしているかどうか,確認すべく,metascan_2023_01,で検索したがこのファイルは見つからなかったので,iPhone 12 ProのMetascanのライブラリーを見て,本日には,一応ダウンロードすることにした。というのは,Jan. 30, 2023でProが更新日で,回避したいからである。

図1 2セットの段ボール三箱と神武天皇遙拝所碑のLiDAR撮影のfinder表示

 さて,今後のファイル名の構成は次の形が適当か。現場での命名のあと,インドアでmacに保存する際に整理すれば良い。現地では難しいが,ローマ字でもいいから英数字で揃えた方が良いだろう。
形式1: [日付230138]+[テーマ3carton]+[3d-app(+LiDARorPhoto)]+[試行回数_4]
形式2: [テーマ3carton]+[日付230138]+[3d-app(+LiDARorPhoto)]+[試行回数_4]
 形式1と形式2の何れがいいか。調査地では何らかのテーマがある。同日に異なったテーマでスキャンすることも当然ある。同じテーマで調査日が大きく離れる場合もある。パソコンで分析する場合に,最も有効なファイル名称は何だろうか。ファインダーまたはブラウザーでの操作だけでなく,CloudCompareやMeshLabの読み込みも考えた方が良いだろう。というわけで,形式2を採用したい。なお,一連のファイルを検索する際には上位カテゴリーとして日本語を入れた方が良いだろう。ファイルのパスで2バイト文字が介在する場合,現在の欧米のソフトは文字化けはしないのではないか。CloudCompareとMeshLabについては問題が無いように感じている。そこで,形式2の関連ファイルを,神武天皇遙拝所碑と段ボール三箱に入れ込んだ方が良いだろう。

 で,何とかmacのファインダーでファイルなどの名称を変更したが,特にOBJファイルセットについては動くかどうか心配である。同じ内容のものを一つはMac_Win_Sharedフォルダーに入れ,フォルダー名を直方体撮影ファイル名再構成forMeshLabとした。もう一つはmouseWindows10のmoto > Documents > win_moto_documents > win_3d_scan,にコピーし,フォルダー名を直方体撮影ファイル名再構成forCloudCompareとした。
 というのは,CloudCompareで操作過程で生まれたファイルと,MeshLabの操作過程で生まれたファイルを区別するためなのだが,同じファイルをCloudCompareとMeshLabで表示してみて,同時に比較したいということがある。CloudCompareはmouseWindows10で,MeshLabはWindows10 on Parallels Desctop of macで操作する。実際にやってみて,どうなるかはわからないので,今後変更する可能性がある。macのファインダーでの「直方体撮影ファイル名再構成」のファイル群のスクリーンショットを次に示す。

図2 直方体撮影ファイル名再構成の3D神武天皇遙拝所碑のファイル群
図3 直方体撮影ファイル名再構成の3D段ボール箱のファイル群

 さて,図2と3では,iPhone 12 ProのスキャンアプリMetascanとScaniverseについてまとめている。そして出力ファイルは,主にメッシュのOBJと点群のPLYファイルに注目している。それをまとめたのが,次の表1である。

表1 MetascanとScaniverseからの出力ファイルの比較: 赤字は最大値,青字は最小値。

 ターゲットは神武天皇遙拝所碑と段ボール三箱である。神武天皇遙拝所碑については表1上段の4組のOBJとPLYがあるが,一般に最大値を示す赤字が見えるのはScaniverseである。ScaniverseのJan. 10とJan. 26の違いは,身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の「図53b Mesh Simplificationの説明」に示されている。Scaniverseの描く段ボール箱の平面の点群が少なくて,何らかの省略プロセスがあると考えていたが,まさにこのMesh Simplificationがデフォルトで選択されていた。そのため,これを解除してスキャンをやり直したのが,Jan. 26のデータである。objファイルを見ると,Jan. 10は526kBで,Jan. 26は21.9MBと大きな違いがあった。
 段ボール三箱の結果を見ると,objファイルの関係は神武天皇遙拝所碑と同じであるが,plyファイルでは神武天皇遙拝所碑とは違って,逆転して,Jan. 26の5.6MBに対して,Jan. 10は21.6MBとなっている。何故なのか,わからない。

 そこで,点群数などターゲットの再現性を,CloudCompareとMeshLabで閲覧して,確認したいと思う。なお,スキャンの密度などはその時のぼくの心身の感覚も関係するが,とにかく,アプリで表示される像に従っているのであって,およそ恣意的ではないと思う。

以上,Jan. 30, 2023記。

3 CloudCompareとMeshLabによって3Dスキャンの再現力を見る

3.1 ScaniverseのMesh Simplicationの解除前と解除後の比較

最初にチェックしたいのは,ScaniverseのMesh Simplicationの解除前のJan.10のものと,解除後のJan. 26のものである。点群PLYとメッシュOBJについて求める。

a 段ボール三箱の点群PLY 解除前Jan.10

 すでに掲載したものであるが,改めてWindowsのCloudCompareで表示した(図4)。回転して上下逆にしている。面の大きな穴からバックの紺色が見える。Cloud > Points 1,437,942。

図4 ply_Jan10_scaniverse_CloudCompare

 

 次に同じファイルをmacのParallels Desktop上のMeshLabで見てみる(図5)。図4とほぼ一致している。当然ではあるが。右ペーンの上のProject 1の枠内のファイル名左端の小さな▶をクリックすると,File, Verticles, Facesが現れる。Verticlesの数値は図4と一致している。

図5 ply_Jan10_scaniverse_MeshLab

b 段ボール三箱の点群PLY 解除後Jan.26

 解除後のPLYを見てみよう。CloudCompareに限定する(図6)。このJan. 26撮影PLYは,Cloud > Points 376,363とあり,Jan.10撮影のものに比べて点数が四分の一にまで低くなっている。Mesh Simplication解除後の方が点群の数が小さくなっているのである。この逆転現象はもちろん表1のファイルサイズで予測されたことである。この結果はScaniverseのプログラムバグに間違いはない。大きな問題だ。

 表1のように,神武天皇遙拝所碑の結果では,この逆転現象はなくて,Mesh Simplication解除後の方がファイルサイズがかなり大きくなっている。ターゲットの材質に拠るものとしか考えられない。

 この段ボール三箱に戻って,図6を見ると,図4,図5同様,点群の大きな穴が空いている。段ボール箱の配置はJan. 10とJan. 26でほぼ同じにしており,身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の図38などと同じ場所で大きな穴が発生している。同じ段ボール箱に生じているのではなく,室内の光と影の位置から生じたものである。最も影の濃い面で生じている。前掲ページの図36での右手の面に対応している。奥方向と手前方向そして左手の面にはそれぞれ自然光が入る環境で,この大きな穴が生じた右手の面だけは自然光が最も入り難い場所になっているのである。

図6 ply_Jan26_scaniverse_CloudCompare

c 神武天皇遙拝所碑の点群PLY 解除前Jan.10

 このファイルはすでに見てきたものである。Cloud > Points 59,246。

図6 ply_Jan10_scaniverse_CloudCompare

d 神武天皇遙拝所碑の点群PLY 解除後Jan.26

 図7と図8に,PLYを表示している。図7では碑の前面の「神武天皇遙拝所」の文字がしっかりと読める。しかし,図8は碑の後面にあたるが,ここでは点群がかなり不足していて前面の碑名が透かして見えている。
 結果的には,スキャン密度が足りなかったということであるが,スキャン(中サイズで距離2.5mまで)に要した時間は5分間であったが,ProcessingはDetailを選ぶことができた。5分間を超えると,Detailを選ぶことができずAreaという中間的な解析手法になってしまう。保存前にEditで,Exposure 20, Contrast 53, Sharpness 35, no filter,を選択した。保存したのはスキャンが終わって3分後であった。

図7 ply_Jan26_scaniverse_CloudCompare 表面
図8 ply_Jan26_scaniverse_CloudCompare 裏面

 これまでの経験から,5分リミット(5分間を超えるとdetail processingが出来なくなるというリミット)に規制されると,まともなスキャンができないということになる。Scaniverseは,Metascan (Pro) のように10分間までしかスキャンできないという強面ではない。とにかく,また,この神武天皇遙拝所碑,をScaniverseでスキャンせざるを得ない。図8では碑のトップが取得されていないのだけど,これまでの経験を踏まえて,繰り返し,頭の部分を腕を伸ばして,繰り返しスキャンしたはずなのである。
 とにかく,じっくりとスキャンしないと行けない。どうしても後面のスキャン不足はこの付近の足場が狭く,無理な姿勢でスキャンする環境が響いているようである。情けないが,寒かったこともある。この冬一番の寒波(当時マイナス2℃ぐらいに過ぎないのだけど),という日であった。

e メッシュOBJのファインダーでの名称変更はNGだった

 恐れていたことが起きた。OBJファイル関連ファイル群をmacのファインダーで名称変更したが,それはNGであった。ファイル名はファイル内に書き込まれていて,ファインダーやブラウザーでの変更を受け付けない。Scaniverseは現在,Proであっても無料なので問題無いが,Metascan Proは月単位の契約にしていて,Jan. 30に終わっている。

 次の図9と10にその読み込みエラー表示を示した。そのため,iPhone 12 ProのScaniverse内で名称変更を実施しAirDropでmacにdownloadした。そして共有フォルダMac_Win_Shared中の古いファイル群を削除しこの新たなファイル群を移動した。さらにmouseWindowsについても既存フォルダを削除して新たに修正版をコピーした。この新たなフォルダ中のmetascanによるOBJファイル群はすべて削除した。名称変更前のmetascanのOBJファイル群はWindowsに残っていると思う。

図9 OBJファイル群のMeshLabへの読み込みエラー
図10 OBJファイル群のCloudCompareへの読み込みエラー

f 段ボール三箱のメッシュOBJ 解除前Jan.10

 ScaniverseによるメッシュOBJファイルには全く穴が見られない(図11)。写真のようだ。左ペーン上段のDB Treeでのvetticesにチェックを入れてPoint size = 3としたのが,図12である。図11,12の段ボール三箱の左手の段ボール面には画像的には全く穴が無いが,図12のpointsの分布を見ると,点群PLYと同様,空白になっている。Cloud > Points 75,567となっている。同スキャンでのPLY出力(a,図4)を見ると,Cloud > Points 1,437, 942,であり,このPLYはOBJの19倍もある。
 そして,点数の多いPLYであっても,段ボール三箱の表現に大きな穴が生じているのである。線分に境される立体,言い換えると平面からなる立体の表現には,メッシュ形式が圧倒的に優れていることを知るのである。
 CloudCompareでは,計算機能は点群に対して優れているので,このメッシュを点群に変換した方がいいかも知れない。そういう能力はMeshLabが優れている。その方法は一般に知られているので,後日,実施したいとは思う。とにかく,平面からなる立体の点群を生み出すのは困難を極めると言えるだろう。

図11 obj_Jan10_scaniverse_CloudCompare without vetrices
図12 obj_Jan10_scaniverse_CloudCompare with vetrices(3)

g 段ボール三箱のメッシュOBJ 解除後Jan.26

 Mesh Simplication解除後の方は,ファイルサイズがかなり大きくなっている。段ボール三箱の表現が明るいのは,iPhone 12 Pro内でのEdit作業の結果だろうから,その面から比べるのは違うと思う。ただ,図14のverticesの表現はかなり白っぽくなっていて,点数が増加したように見える。解除前は,Cloud > Points 75,567,この解除後は,236,214とあるから,3倍余りになっている。
 とにかく,メッシュファイルの表現力は圧倒的に凄い。

図13 obj_Jan26_scaniverse_CloudCompare without vetrices
図14 obj_Jan26_scaniverse_CloudCompare with vetrices(3)

h 神武天皇遙拝所碑のメッシュOBJ 解除前Jan.10

 解除前の神武天皇遙拝所碑を図15,16に示している。メッシュobjを開くと,materials, Texture coordinates, verticesのチェックが可能だが,表示としては,前二つは関係がない。Cloud > Points 4644,と少ない。

図15 obj_Jan10_scaniverse_CloudCompare without vetrices
図16 obj_Jan10_scaniverse_CloudCompare with vetrices(3)

i 神武天皇遙拝所碑のメッシュOBJ 解除後Jan.26

Cloud > Points 169,986と多い。解除後のPLY(d 図8)とは違って,後面の画像もあり,穴は空いていない。奇妙な感覚に囚われる。

図17 obj_Jan26_scaniverse_CloudCompare without vetrices
図18 obj_Jan26_scaniverse_CloudCompare with vetrices(3)

おわりに

 ここでは,Metascanについては述べなかったが,すでに述べてきたように,直方体を対象にする場合,使いものにならない。これ以上,述べる必要性は無いかと思う。この直方体からなる段ボール三箱と神武天皇遙拝所碑を通じて,Scaniverseが圧倒的に優れていることがわかった。Metascanのように10分間という使用時間の制限も設定されていない。
 いわば人工的な直方体とは違った自然物についてのMetascanの能力はすでに求めているところであり,Metascanを完全に否定するものではない。Scaniverseには写真測量の機能がなく,その点でも200枚という限定はあるが,Metascanは捨てきれない。
 3Dファイルのうち,汎用性の高いものは,メッシュではOBJ,点群ではPLYであるが,ターゲットの表現力は圧倒的に,メッシュのOBJである。点群の分析ツールとしてCloudCompareが優れていて,できればメッシュではなくて,点群ファイルが欲しいところである。
 これをテーマの一つとして,3Dデータの欠損をMeshLabを使って穴埋めする に戻りたいと思う。