身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める reliability of dimensions of familiar cuboid by iPhone 12 Pro + Lidar laser scanning and photogrammetry
はじめに
元伊勢大饗石のLiDAR測量 に続いて，このページを作成する。大饗石のCloudCompareの体積計算の妥当性を検証したいのである。
その方法として容易に考え得るのは，スケールで計測可能な直方体の体積を，LiDARまたは写真測量，そしてCloudCompareで求めて，この手法の再現性を確かめるということである。
近所で直方体を探したが，なかなか見つからない。墓石は近所に見られるが，避けたいところである。で，近所の為那都比古（いなつひこ）神社では，由緒も何も無い神武天皇遙拝所なるものを計測した。出直すつもりで，疲れて自宅に戻ったが，屋外は期待薄なので，狡（ずる）して室内で段ボール三個をまとめて計測することにした。
以上の材料を使って，このページを作成してゆく。
１ 為那都比古神社の神武天皇遙拝所碑
さすが，式内社だけにトベラの大木がある（図１，２）と思ったが，この境内は必ずしも古い地ではないようだ。一般に，神社の境内は掃き清められていて，古さを感じないこともあるが，それにしても，この境内では神々しい感じがしない。なお，図１のトベラの葉の塊の中段付近には垂直方向に伸びるトベラの徒長枝（とちょうし）である。
なんともわからないが，かつては医王岩（図４，看板が右下に小さく見える ソース不明でネットから拝借）に係わって為那都比古神社の前身があったようだが。一度参拝したいと思う。自宅から徒歩で1時間ほどか。図３に見えるが，山麓線からバス路線「ルミナス箕面の森」への道に入ってすぐ右手の「あかつき特別養護老人ホーム」の看板がある交差点から入って，大宮寺観世音菩薩を過ぎると，医王岩参道入り口があって，そこから北に登ることになる。
以上，Jan. 7, 2023記。
追記 May 17, 2023：
奥さんの見舞いに娘がMay 15に来たので，懸案だった医王岩に出かけた。そして埼玉に戻ったMay 17にも医王岩に再訪した。というのは，15日に撮影した医王岩が一枚岩では無くて，落石が基盤岩に載った構造のように見えたからである。ジョイントには惑わされるので，層理面についても，走向傾斜を求めた。ノートを忘れたので，読みは録音した。
追記図1, 2： 図１で右手の道路に進むと特養あかつき荘へ。図２は図１の左手の道を進むと辿り着くちょっとした広場である。右手の垂直面が医王岩になる。
追記図3, 4： 全部で４区分でき，足下，下半身，上半身，そして，首（顔），とも見える。首（顔）＝最上部には天狗の鼻のようなものも見える。しかし，これは冠か何かにして，上半身としたのが顔で，横一文字の割れ目から下が上半身と下半身になるのであろう。横一文字の割れ目を境に，下方は左上から右下に層理のようなものが見えて，上方では左下から右上に層理のようなものが見える，ようにも見える。全体が一枚岩か，それとも複数の岩体なのか。それが気になって，May 17に出かけたのである。自宅から20分余りで到着した。
以上。
追記 May 18, 2023：
May 17の調査では紙を忘れてiPhoneの録音機能を使ったが，問題があって，駄目だった。
アップルのボイスメモを押してすぐにしゃべると，最初の音声が録音されていなかった。
なぜか，ずーとオンのままで，聞くに耐えない。
録音の時刻が自動に記録されると思ったが誤りだった。タイムスタンプが無い。いいソフトを探そう。
追記図5〜7： 追記図5とのジョイントは，N38ºE, 62ºE, N33ºE, 58ºE。図6のそれは，N38ºE, 52ºE。だいたい，この医王岩最下部の走向傾斜はこんなものか。
追記図8, 9： 層理面を確認した。走向傾斜は計測したがボイスメモに問題。層理の傾斜はほぼ垂直に近い。
追記図10, 11： 層理面を確認した。走向傾斜は計測したがボイスメモに問題。層理の傾斜はほぼ垂直に近い。
追記図12, 13： 両写真の最下部が，胴と顔の境界のジョイントになるのだろう。ジョイント面の山側には顔のブロックが消失している。
追記図14, 15： 消失している部分の面の走向と傾斜を測ったが，N62ºW, 20ºSか。再確認の必要あり。
追記図16, 17： 層理が明瞭だ。胴より上の顔の残骸の一部だろう。N10ºE，83ºEか？ 要確認のこと。
再調査，必要。層理面の走向傾斜が医王岩の<胴体最下部>でも，<胴体最上部>でも，<顔ブロック>でも，類似しておれば，同一岩体となる。要走向傾斜計測。今度は紙を忘れないように。蚊がもう出てきて，顔ブロック周辺の走向傾斜計測中には目の前で，嚼まれてしまった。
以上。
為那都比古神社の違和感についつい，拘ってしまった。図５に神武天皇遙拝所碑を示す。この正面に立って拝む場合の方位はどうなっているのか。磁石としては最も信頼できるコンパスSUUNTOを使ってまずは土台に載せてみた（図６）。ほぼ北東を指す。ぼくのこの地の方向感覚からすると奇妙なので，この土台からコンパスを離すと（図７），正しく，東を向く。図７右部には，コンパスのエッジと碑の土台とはほぼ平行になっている。この花崗岩は，磁鉄鉱系列の山陰起源の可能性が高い。
遙拝先として考えられているのは畝傍山の麓に明治になって造営された神武天皇陵なのか，伊勢神宮なのか，わからない。磁北から90ºの東方向に向かって遙拝する形なので，天皇陵にも伊勢神宮にも向いていない。
２ 神武天皇遙拝所碑のスケール実測3D
図8の立面図と平面図はイラストレータで1/10スケールで作成した。為那都比古神社の設計思想はわからない。花崗岩の切り出しの精度は5mmほどであり，およその平均にあたる値を使って図を作成した。
計算式として注意すべきは，四角錐の面積と，直方体土台部分の面積であろう。この両者はエクセルでの計算式も示している。前者については，四つの二等辺三角形をなす側面の面積の計算式であり，後者については，図８の平面図で中央の柱の部分を差し引くことを忘れないことだろう。
追記 Jan. 24, 2023： このポスティング作成過程で，値に疑問を持ち，強風と雪の中，再度，現場を訪れた。直方体部分の高さを149cmから144.5cmに修正した。この図8を含めて，特に表の修正を今後する必要がある。
３ LiDARおよび写真測量で得られたイメージの限界
今回の実験で，LiDARも写真も，かなり欠陥があることがわかった。真っ直ぐの稜線の復元に大きな歪みが生じる。室内で段ボール箱３個を並べたもののスチール写真 still photo（図9, 10）を先に示す。
この段ボール箱三個のLiDAR像を図11, 12に示す。真っ直ぐな稜線の復元力は，Metascan（図11）よりもScaniverse（図12）の方がある。しかしながら，図12の段ボール右下に大きなnotchが見える。Metascanでは取り込みに相対的に多くの時間（3分ほどか?）を要した。４回ぐらい周回している。Scaniveseは狙った段ボール箱三個はすぐに（数秒か）見かけ上，取得したのであるが，念のために周回している。狭い場所であることと照明が不均一であることがあり，LiDAR撮影の条件は良くはなかったが，それにしてもという結果であった。図12の最上部に示されている時刻は撮影時刻ではなく，iPhone 12 Proでのスクリーンショットの時刻を示している。撮影時刻は両図でほぼ同じ時間帯であった。
次に神武天皇遙拝所碑を見てみる。図13はLiDAR測量の結果である。碑の周囲の石垣が表示されていないのは，碑にスキャンを集中したからである。かなりの時間を費やしてスキャンしたのであるが，神武天皇遙拝所の漢字はかなり歪んでいる。石柱の稜線は歪んでいる。このことから，予定外ではあったが，２周回して50枚の写真を撮影した。この写真測量結果については，自宅のWi-Fi環境でサーバーにアクセスして像を構築した。写真では歪まないであろうと期待したが，図13よりも図14の方がより歪んでいる。漢字は正しく復元されている。写真測量もまっすぐの稜線を復元するのは苦手らしい。
一般にネット情報では，この観点は全く無い。単純な直方体の撮影を試みていないためであろう。
Metascan，Scaniverse以外のアプリはどうだろうか。こういう疑問は生じるが，おそらく徒労に終わるであろう。すでにMetascanが屋外でのスキャンに最適であることは承知している。Scaniverseについては像の再現性や速度で優れているのであるが，スキャン中に，正しくスキャンできた場所とできていない場所の区別がMetascanより劣っていた。
それにしても，この優れたScaniverseが全面的に無料なのは何故だろう。写真測量の機能が無くLiDAR限定ではあっても。で今使っているScaniverseの設定を調べてみると，Scaniverse Proというのが有料で提供されていたらしい。それを無料にするというメッセージが入っている。開発を諦めるのでPro契約の方からは今後は集金しないし，誰でも使えるようになるという。
念のために，Scaniverseをアップルストアで検索して，インストールしようとすると，ぼくのiPhone 12 ProのScaniverseのSettingsの画面に戻ってしまう。この最下部には，2023 NIANTIC, INC. V2.0.3とあって，昨年このScaniversを買収した社名が表示されている。2022年9月付けのケータイWatchのニュースには，
「これまでは、iPhone 12 Proシリーズ以降やiPad Pro搭載のLiDARを活用していたが、今回より、LiDARなしでも利用できるようになった。LiDARなしでも3Dスキャンを実現した背景には、ナイアンティックのManyDepth技術を採用したことがある。ManyDepth技術は、2Dの画像から3Dの奥行きを推測するというもの。カメラを動かしながらスキャンすることで、ニューラルネットワークが3Dを広げていく。」とある。
WIDAR-3Dスキャン&編集，という日本製アプリがいま，ネット上で宣伝されていて，一応，インストール中。
以上，Jan. 8, 2023記。
４ 直線の低い再現性について
寝ながら理由を考えた。
１ 段ボール箱の撮影は室内の隅で夜間に実施したので，距離と照明の問題が考えられる。そこで段ボールについては，明日Jan. 10, 2023に再試行したい。つまり，居間でスペースを確保して，明るい昼閒にMetascanとScaniverseを実施しよう。WIDARにもトライするかも知れない。
２ 神武天皇遙拝所碑の撮影をもう一度したいと思う。Metascan によるLiDAR測量を前回はかなり近い場所から実施したので，トップの四角錐を除いては，台座に載らないで実施してみよう。Scaniverse，場合によっては，WIDARも使ってみるかも知れない。現場ですぐにチェックできるので，試行錯誤をしたい。
今日Jan. 9, 2023，タニハの艮岩をScaniverseとWIDARでLiDAR測量した。次の図15〜18は艮岩の四面を撮影したものである。LiDAR測量の再現性を知る上で，この四枚の写真は重要である。MetascanででもLiDAR測量したかったが，WIDARがバッテリーを激しく食ったためにできなかった。
ムーヴィー１はタニハの艮岩である。いま，問題としている直線性の稜線であるが，図15〜18と寸分狂わないで再現されている。Scaniverseだけでなく，Metascanでも出来るのであろう。
Scaniverseでスキャンを始める場合，スケールで３択があり，家具などのmedium objectを選択した。スキャンは8分間ほど要した。processingに移る場合も３択であるが，5分を超える場合は中間のareaを選択することになった。
FBX 22.6MB，PLY 3.4MBでエキスポートした。
WIDARでもスキャンした。WIDARの場合はLiDARと写真の選択があった。未だ検知していない場所は紫色で表示され，検知すると写真のような画像が現れる。最初はtextureが粗く表現され，時間が経つに連れて緻密になってゆく。この完成到達点を判断するのが難しい。Scaniverseだとスキャンした所を再度訪れても画像が残っているが，WIDARは画像が残っていず再度スキャンを始める印象であった。それゆえ13分間を要した。Metascanだと10分間で強制的に終了するがこのWIDARは強制的なシャットダウンは無い。このWIDARを終了した後，iPhone 12 Proがバッテリー切れの警告が出て，Metascanを使えなかった。WIDARを使う時には，特に予備のバッテリーが必須のようだ。
出来上がったスキャンデータを見ると，Scaniverse同様，直線性の稜線を復元していた。ただ，croppingなど，撮影後の取扱が面倒で，艮岩についてはもう廃棄してしまった。
明日の神武天皇遙拝所碑の撮影では，Scaniverseでうまく行かない場合，WIDARを使ってみようと思う。
以上，Jan. 9, 2023記。
5 Scaniverseが最高
神武天皇遙拝所碑と段ボール三個の3D撮影の問題を通じて，Scaniverseの高い3D復元能力には驚く結果となった。最近発売されたWIDAR-SCANの宣伝とそのユーザー達の自己喪失した感想には多少引っ張られたが，全くScaniverseの敵ではなかった。WIDAR-SCANは日本製らしいのだが，最も肝心の再現性の技術力が弱いように思う。そして，フィールドでの3D読み込みの進行の評価の観点でMetascanが最優秀と考えてきたが，今回の経験から圧倒的にScaniverseに軍配が上がることがわかった。今後は基本的にScaniverseを使うことになるだろう。それをここで立証したい。
とはいえ，Scaniverseが無料である点を調べてみた。Scaniverse is joining Niantic で見ると，今後さらに開発されてゆくことは確かなようである。現在，かつて有料だったScaniverse Proが無料で公開されているようだ。ぼくのように元々無料で使ってインストールしている場合，いわば自動的にProに替わっているらしい。今日も使いながら，使用環境に制限を感じたので，あらたに有料化されて制限を撤廃してもらいたいものだ。
さて，今日の経験を次に示す。まずは室内の段ボール三個だ。図19〜22はstill写真だ。
図23は，Scaniverseでスキャン開始した頃のスクリーンショットである。Scaniverseでは，iPhone 12 Proの最上段に時刻とバッテリー残量が継続的に表示される。これはスキャン経過を一つの画面で同時に見ることができるので，非常にありがたい。下段の赤丸の右手の‖マークは，pauseボタンである。ポーズを解除すれば，再開できる。「Range 2.5m」は，LiDARの到達距離であり，スキャン開始時に，medium objectを選んだ結果である（さらに調整できるが）。図23には，赤白パターンが見えるが，これはScaniverseが読み込めていない部分を示している。このあと右にスキャンを進める過程で，この赤白パターンは消えて行った。つまり，未読部分が解除される前でもスキャン箇所を移動しても良いということである。
本日，この段ボール三箱の3Dスキャンについては，Scaniverseで二回実施した。一回目は失敗した。結果を見ると段ボールの歪みが残っていた。図12ほどではないが相変わらずnotchが残っていた。図23のように，居間を片付けて段ボール三個をその中央に設置したし，昼閒の明かりも居間に入っている。
一回目では歪みが段ボールの最下部に近いところで強かったので，二回目ではiPhone 12 Proを逆さにして下部を真っ直ぐにスキャンできるようにした。斜め上からのスキャンがこのようなnotchを生んでしまうと考えたのである。その結果，図24のようにかなり改善が見られた。とはいえ，右手前の垂直稜線のうち，上部1/3が少しだけ凹んだように見える。対応部分の写真（図20）ではそのような凹みは見られない。他の部分は完璧のように見えた。ムーヴィーの提示は省略する。
1 foot，つまり，30cmほど近づけても問題はなかった。スキャンタイムは12: 33 – :36で3分間ほどだった（４回ほど巡ったか）。5分間以下ならば，detail processingが可能のようで，そういう風に指示される。（5分を超えると，中間の画質 area processingに強制的に誘導される）。
段ボール三箱スキャンをした後，屋外に出た。以前，Metascanでこの石丸の４個の基準点を巡ったが，Scaniverseがより高い画質を得られるかも知れないと思い，試してみた。
国土地理院の基準点成果の利用 の図39の3-61〜3-39を以前，Metascanでルート測量したが，この時はかなりの早足で何とか10分間をギリギリに切る形で，測量した。それで，Scaniverseに期待したのは，Metascanの10分間限定を超えることができるか，ということであった。
3-61（図25）からスタートして，前回同様の早足であるくと，図23の上部の赤ラベルのSCANNING相当の下に，move slowlyとかなんとかのメッセージが出る。そのアドバイスに応じて減速しようとするのであるが，ついつい早くなってしまう。画像取得が追いつかない（図26）。まあ，何とか減速しつつ，10分を過ぎていることを意識しつつ，10分オーバーがScaniverseに受け入れられることを期待して，3-39に辿り着いた。このスキャン開始以来，13分が過ぎていた。まだ行けそうである。すでに5分を超えたので，中間の精度 area processingを選んで，実行。2分弱で計算終了。これもMetascanよりかなり早い。iPhone 12 Pro画面の最上部のバッテリー残量は88%で，バッテリーを食うという印象はない。図27は得られたルート図である。図25や26のように画像の復元性を見ると，Metascanよりもかなり図的表現の完成度が高い。Metascanの常識からすると，Scaniverse驚くべしである。
WIDAR-SCANには慣れていないためもあったが，ぼくはこれ以上触る気がしない。昨日，タニハで艮岩を撮影した（図28）。今日は段ボール撮影はしないで，このルート作成（この一例を図29に）を試みたのであるが，反応が遅くて耐えられない。これはフィールドで作業するには，使いものにならないと感じている。艮岩にはかなりの時間を費やしたので，画像の復元結果はScaniverseと大差無いようには見える。前述のように，スキャンして3D取得したと思っても同じ場所に戻ると，過去のスキャン結果が反映されていないで，最初からスキャンしなければならないというような徒労に近い作業を強いられた。
図29のルート図はScaniverseとほぼ同速度で歩いてスキャンした結果である。使用に耐え得ないので中止した。
次は為那都比古神社である。為那都比古と為那都比売の，年一回の邂逅を演出したのが，この神輿のようである。一応保管されてはいるがかなり傷んでいる。延喜式のサイトによると，「この鎮座地に為那都比古大神・為那都比売の夫婦二座が同殿にお祀りされていたが、寛平年間(889～898)に別れて別殿となり、白島字土居の地に為那都比売大神をお祀りし、大宮神社と称した。大宮神社の地は現在白島３丁目の薬師寺（医王山持宝院）の近くで、医王岩と称する巨石がある。明治40年（1907年）に再び同殿となり合祀され現在にいたっている。」（簡略化した）
図31，32はScaniverseによるスキャンのスクリーンショット。図33はWIDAR-SCANによるスキャンの途中である。Scaniverseによるスキャン時間は14分間であった。垂直の稜線と頭の四角錐の直線を捉えるのに時間がかかった。繰り返し実施した。レーダーの深さは2.5m（medium object）の筈であるが，水平方向にすると，不要なものを捉えるようだったので，上から下の方向にレーダー射出を変えてから，垂直の稜線をより捉えることができたように思う。Scaniverseでさえもほぼ満足がゆく画像を得るのに14分間を要したのである。5分を過ぎたので否応無く，area processing になった。
WIDAR-SCANでの作業のスクリーンショットが図33である。神武天皇遙拝所の文字の認識がなかなかできない，というか際限なくできない。それで9分で終えた。スキャンの距離は5m未満であるが最近接した1 footでも認識はできてはいたが。
図34，35は，WIDAR-SCANのLiDAR測量の結果である。「神武天皇遙拝所」文字列後半が認識できていない。頭の四角錐が丸い。垂直の稜線はほぼ捉えられている。
ムーヴィー２は，ScaniverseのLiDAR測量の結果である。WIDAR-SCANに比べると歪みも少なくて実在感も高い。花崗岩の粒状構造がより捉えられている。頭の四角錐はコブのようになっている。繰り返しスキャンしたが駄目だった。「神武天皇遙拝所」の面の左手の垂直稜線の下部で断裂のような構造が見える。
以上，主に，Scaniverseのスキャン結果が使用に耐えうるものであることがわかった。LiDAR測量であっても写真測量であっても，神武天皇遙拝所の様な細い石塔や上に尖った四角錐などを捉えることはかなり難しいようである。タニハの艮岩の垂直方向の稜線は全く問題なく捉えられているのにである。
言い換えると，直定規で簡単に捉えることができる地物はLiDARや写真での測量は難しい。LiDARや写真は，簡単な幾何学では捉えにくい曲面を捉えることができ，この個性こそ，私達が求めるものだと思う。
以上，Jan. 10, 2023記。
６ Scaniverse取得の直方体体積計算の準備
以下，Scaniverseで取得した段ボール三箱と神武天皇遙拝所碑という二つの直方体を主とするオブジェクトの面積と体積をCloudCompareで求める作業に入る。段ボール三箱のスキャン結果を次のムーヴィー３に掲載し，計算結果を図36に示す。なお，神武天皇遙拝所碑の体積はすでに，図８に示している。
図36には，サンペレグリノ炭酸水の箱を三箱並べている。スケールでサイズを測ると同じ段ボール箱ながら束ねると単に合計サイズにはならない。500mLビンが36本入っているこの箱を正位置にして，短辺と長辺を比べると，長辺は短辺の正しく２倍になっているので，短辺を一つの単位とすると，図36の側面は12面からなっている。体積と面積に共通の上面の面積は実測値 (3x短辺) x (2x短辺) = 61.5 cm x 41.5 cmとなっている。図36では短辺のみからなる辺は5辺あるがいずれも21cmであった。以上の観点と計測結果から，図36で示した体積と面積の結果を得ることができた。
Scaniverseから点群point cloudファイルの一つplyでエキスポートし，図37のように共有したmouseのdocumentsフォルダにコピーした。
７ CloudCompareによる直方体体積と面積の計算：点群plyを使っての段ボール三個編
体積と面積の計算法は，元伊勢大饗石のLiDAR測量 の「４ 大饗石の体積を求める１： まずはデフォルトで」〜「おわりに」までに記述しており，これに従ってゆく。
１ 「２ 必要な部分を切り抜く」ステップ：
段ボール箱scaniverse Jan10-2 completeを図38に表示している。面がスカスカで奥の面も見えている。Points数は1,437,942で十分だと思うが。図38左ペーンの下部に見られるように，Point size 3に設定しているが，値を増やしても，汚くなるだけだ。どうも自然光の影の部分がスカスカになっているようだ。
set top viewにして少し回転して，上段のツールのハサミアイコンをクリックして，segmentationを実施した。 図39左ペーン上部のDB Treeに見られるように，remainingは選択せずsegmentedだけを表示している。図39に見られるremainingクラウドは削除して，segmentedのクラウドを含むメーンファイルを選択して，保存した。
２ 「４ 大饗石の体積を求める１」「５ 大饗石の体積を求める２」ステップ：
体積計算では段ボールを設置したカーペットのZ値が必要である。上段のツールの左から四番目のPoint list pickingを使用する。segmentedした後であっても，辛うじて残ったカーペットでの５点のZ値のうち，0.008332が最小であったので，Ground値を一応，0.008とした。この作業実行後，Octreeも作成された。
segmentedクラウドを選んで，Tools > Volume > Compute 2.5D volume，を選んで実行した（図40）。Ground > Default height =0.008とし，Ceilのファイルはこのsegmentedクラウドで，Empty cellsには一応，interpolate，Grid > step = 0.001（最小値）自動でのサイズ表示は663×674 (44,862 cells)だ。赤い横に長いボタンUpdateをクリックした。エラーメッセージはない。
Volume 0.133（図36に示した実測値は0.1212），Surface 0.365（図36に示した実測値は1.4522）だ。CloudCompareによる体積計算値は多少大きめになっている。matching cellsは81.6%でかなり高い値になっている。
追記 Feb. 5, 2023: このページ作成時には図36での面積計算のミスに気が付かなかった（ある読者には発見を期待していた）。図36のように実測表面積は1.4522㎡であって，点群plyを使っての表面積の計算はCloudCompareでは全くできていない。他のCloudCompare評価では全く問題にされていない。CloudCompareの点群ファイルの表面積計算は能力外のことと言える。
図41ではsegmentedのクラウドを非表示にして，OctreeのDisplay levelを15にした場合である。
segmentedクラウドを選んで適宜回転して，おおよそ図39の面を表示したのが図42である。図41，42にも実は見えるが，カーペットを削除したにもかかわらず，Groundレベルまたは近くでのクラウドの繋がりや，斜めの黄色に近い線状のゾーンが見えて，（この発生は）何らかのクラウドの欠損が関係しているように見える。
３ 「６ 大饗石の体積を求める３」ステップ：
点群欠損部の解消のために，いったんメッシュ化を経由させてみよう。
手順１ Octree レベル8で実行された。segmentedクラウドをvisableにして，Height difference rasterを非表示にしたのが図43である。裏ができて，段ボールの欠損が明瞭になっている。
手順２ メッシュ化する。Keep old normals ? に対してYes。これでtriangulationが実施される。図44に見られるように，この作業でも欠損が見える。
図45のように，MeshのWireframeにチェックを入れると，欠落部が埋まったように見える。Stippling（点描）についてはチェックを入れても入れなくても表示に違いが見られない。
手順３ 点群データに変換。図46は実行の後である。図46では，メッシュアイコンのクラウドが選ばれているが，この作業で，新たにこの下方のルートに点描クラウドが見える。
図47のように，新たな点群cloudは欠損が埋められたが，赤色の曲線で示したように，斜めに追加されており，元々の段ボール三箱の体積も表面積も増大しているようだ。
この段階で，体積計算をしてみよう。２ 「４ 大饗石の体積を求める１」「５ 大饗石の体積を求める２」ステップ，を繰り返す。先ほどの結果を再掲する。Volume 0.133（図36での実測値0.1212），matching cellsは81.6%。
今回は，Volume 0.132（図36 0.121），matching cellsは81.7%。ということで，メッシュ化を経た結果と変わらない。
————————————————
新たな手順の追加１ 図48で赤丸で示した２箇所を何とかしなければならない。図49にはこの箇所を斜めに見ている。膜状の繊維束が見える。Groundでもこの部分は緑色のカーペットがあり，この二カ所の直角三角形部分をsegmentしてしまえばいいと考えた。
問題の箇所をsegmentした。図50はsegmentした結果の捨てる方を表示しているが，全クラウドが見えていて，segmentの結果が見えない。ところが，図51のように，Height difference rasterを非表示にすると，削除した部分がハッキリと見える。図52は，Cloud.segmented.mesh.sampled.sagmented，であり，期待していた形を得ることができた。
再々度，Volume calculationを実施した。Volume 0.135（図36の実測値0.1212），matching cellsは81.2%。これまでの作業がほぼ徒労に近いという印象である。
Empty cellsに対して，leave emptyとすると，Volume 0.025, Matching cells 16.3%となり，この作業を経てもクラウドの穴は完全には修復されていない。赤字で，At least one of the cloud is sparse ! You should fuill the empty cells.が出ている。
以上，Scaniverseのplyファイルを触ってみて，Metascanと比べてオブジェクトの点群分布が粗雑に感ぜられる。iPhone 12 Proでの絵作りについてはScaniverseは優れているが，CloudCompareで見たら，惨憺たるものであった。
追記 Jan. 12, 2023： 一晩考えてみて。Scaniverseは平面の認知が早く，稜線把握能力が高い。そのため，平面には点群が異常に少なくて大きく破れている。その面は相対的に影の部分であり，明度が高い面では点群は多い。影の部分であってもiPhone 12 Pro段階で画像的表現がなされており，そういう点でメッシュ的な情報が優れているように感じる。そこでCloudCompareに対応してScaniverseが出力可能なFXB, OBJが有効かも知れない。体積と面積計算のためにはこれをpoint cloudに変換してから，体積計算をすることになる。
CloudCompareの体積計算だが，Ground値を最低Z値（カーペットでの５点中）よりも小さい値を設定することで，平行六面体の高さの積み上げが生じていて，実際の体積よりも多目に出ている可能性があるので，カーペットでの５点中の最大値を使って計算するのが妥当かも知れない。その場合，大饗石の計算についても考え直す必要性がある。
Ground値ではなくて，対象オブジェクト周辺のベースにあたるクラウドに換えて，CloudCompareで計算する必要性があるかもしれない。が，すでに述べたように，平行六面体ではオブジェクトの3D構造は捉えられており，この考え方は問題があるかも知れない。
追記 Jan. 13, 2023： Jan. 12の追記を実行した。その結果が次の表１だ。第１列で言うと，実測値〜3 carpet min，はすでに述べたもので，ここにまとめている。そして，横罫線………… 以下の，4 carpet max，5 carpet max，を追加的に実行した。Ground heightをカーペットのZ値の最小値0.008から最大値+0.005=0.025に換えた。stepは0.001より高く，言い換えるとcellサイズを大きくして，0.002，0.003としてみた。体積は多少小さくなって実測値に近づいた。すでに実測値の計算法を示したが，辺の長さも計算法も単純化したものである。3 carpet min/「実測値」について，体積は+11.5%，多めになっている。段ボール箱が緩み膨れていることと三箱の隙間があることを考慮しても，是認できるズレではないと思われる。
追記 Feb. 6, 2023： 繰り返し追記しているが表面積の実測値は，修正図36にあるように1.4522㎡で，CloudCompareの点群plyには使えない。
追記 Jan. 25, 2023: 追記 Jan. 12で，「Scaniverseは平面の認知が早く，稜線把握能力が高い。そのため，平面には点群が異常に少なくて大きく破れている。」としているが，まさに，Scaniverseの設定（図53a）の中に，そういうオプションがあった。PROCESSING > Mesh Simplification，が選ばれている。これはデフォルトでそうなっているようだ。図53aではこの選択をすでに外した画面になっている。このMesh Simplificationの右手の？マークをタップすると，図53bが現れる。これを選択することで，まあ見た目で合理的な絵作りが行われるらしいのだけど，この説明にあるように，グリッドの密度を求めるのであれば，ボタンを切るようにとあった。ぼくがScaniverseに求めているのは絵作りではなくて，メッシュのグリッドの高い密度であり，Mesh Simplificationは排除した方がいいだろう。ただ，基準点を繋ぐ形の長い距離で迅速な測量をするには，このMesh Simplificationを採用した方がいいだろうと思う。
Scaniverseのメリットは，レーザー感知範囲を限定できるということだ。図53cのようにLiDARの検知範囲（max 5m）を縮小できるようになっているが，Jan. 2023時点では，このページに示したように，対象による三択になっている。図53dでは撮影後のテクスチャーを三択できるようになっているが，スキャン時間が5分間を超えた場合は，Detailは選べなくなっている。
撮影の注意点として，同じオブジェクトでも影の部分ではゆっくりと丁寧にスキャンする必要があると記されている。なお，Saveする前に編集機能を使った方がいいようだ。コントラストや密度を上げる。
なお，石碑と段ボール三個について，このMesh Simplificationを外した設定で，再度，スキャンしたいと思っている。明るい場が必要で，いずれも明るい時刻や天候の時に，再挑戦したいと思う。
追記 Feb. 5, 2023： 図36修正済みの表面積の計算式と計算結果は，新たに修正したものである。これによれば，CloudCompareは少なくとも点群plyでは表面積は計算できない。それゆえ，このページの記述の表面積に関するものは全く無効である（その記述部分を削除したつもりであるが今だ残っているかも知れない）。表１も表面積（実測値は過って，0.29になっている）については全くの無効である。体積については，VolumeはGround heightを0.025にすることで実測値に近づいている。
８ CloudCompareによる直方体体積の計算：神武天皇遙拝所碑編
さて，Scaniverse （Feb. 5, 2023追記：点群plyクラウドに対してでかつ，Mesh SimplificationをデフォルトでONにしていた環境であるが）にはガッカリした。iPhone 12 Proで見える絵作りは優れているが，CloudCompareでみるとボロボロだ。分析的観点からすると，Metascanとの間に大きな開きがある。さて，Scaniverseのこういう個性を生かすような使用法をすればいいのであろうが，さて，他のファイル形式はどうであろうか。また段ボール箱でトライする元気がもう無いので，神武天皇遙拝所碑について，この観点から記述を進めたいと思う。
ScaniverseのExport Modelは，メッシュファイルとして使えそうなのは，FBXとOBJである。点群ファイルではLASと，ここで使ったPLYとがある。一応，全部，表示してみることだ。
以上，Jan. 11, 2023記。
１ fxbのmeshについて碑部分をsegmentしたのが，図54左ペーンDB Treeに見えるmesh.partで，これをEdit > Mesh > Measure Volumeした結果が図54メーンペーンの下部のConsole下部に見える。V=0.0510 (cube units)で，図8の「実測値」=0.0547㎥と比較すると，大きな違いはない。ただ，このコンソールのメッセージには，”The above volume might be invalid (mesh has holes)”，とある。
面積は，Edit > Mesh > Measure Surfaceした結果が図55である。consoleに結果が表示されるが，S=1.16624 (square units)で，図8の「実測値」=1.264 ㎡と比較すると，大きな違いはない。Vと違って，”invalid”のメッセージは無い。
２ fxbに代わって，もう一つのメッシュのファイルOBJの結果を図56に示す。fxbの体積同様，”invalid”表示が出ている。V=0.0511 (cube unit)で，fxbとほぼ同じである。
objの表面積は，fxbの表面積同様，”invalid”表示が出ていない。S=1.146 (square units)で，fxbとほぼ同様である。
以上を簡潔に整理すると，表２修正済みのようになる。
表２修正済みから，メッシュファイル対応の体積と面積の計算アルゴリズムが，点群クラウドのものと比べると優れているということが解りますねえ。ただ，異なったオブジェクトに異なる計算式を適用しているので，単純に言い切れないと考えてしまう。さて，点群の計算過程は複雑なので，メッシュファイルの計算をした方が楽だなあ。ということは，段ボール三箱についてメッシュファイルの計算をすることにしよう。
９ 紙箱と石碑の材質の差による違いはなかった
第８章の終わりに示した着想で，段ボール三箱のメッシュファイルの体積と面積を計算した。その結果を，表２に追加したのが表３修正済みである。
表３修正済みは，メッシュファイルを使った段ボール三箱の体積と面積の計算結果を表２修正済みに追加したものである。段ボール三箱も神武碑も，メッシュファイルでは，体積面積共に，実測値に近い。なお，メッシュの体積については，いずれも次のエラーメッセージが現れている。The above volume might be invalid (mesh has holes).
fxbとobjのwireframeを次に比較したい。図58のfxbファイルではメッシュサイズがかなり大きな部分はあるが，図59のobjファイルでは大きく破れている面がある。この面は図38で正面に見える幅広い面ではなく，図43の正面に見える幅広い面にあたる。同じメッシュファイルであっても，メッシュ形成に大きな違いがある。面の捉え方としてはobjよりもfxbが優れていると言わざるを得ない。少なくとも，Scaniverseでは，メッシュファイルはfxbを採用すべきと考えられるのである。
次に，石碑の点群クラウドPLYも一応，評価しておく。
１０ 神武天皇遙拝所碑の体積と面積を点群クラウドPLYで求める
さて，元伊勢大饗石のLiDAR測量 の「６ 大饗石の体積を求める３: 点群欠損部の解消」に従って，石碑のScaniverseによるPLYから体積と面積を求める。図69（図番号が不注意で大きく跳んでしまった）はPLYでpoint size=3で表したもので，神武天皇云々の字が読みにくい。set top viewではなぜか石碑の垂直方向からずれているのでマニュアルで回転して，手作業で図70のように石柱が垂直に見えるようにした。
追記 Jan. 24, 2023： 本日，実測値に疑問を感じて，この冬一番の冷え込み？の中，この石碑の再測に行った。そして，序でに垂直に立っているか，確認した。確かに，傾いている。図60では東へ，図61では北へ，図62では東へ。なお，図番号は図59と図69の間が欠番になっていたので，図番号の60, 61, 62を挿入した。
PLYファイルは点群であるが図70ではcellがハッキリと見えている。なお，不思議なことであるが，図70の台座に見える雲のようなものは実は台座の中に作られている。LiDARイメージは石碑の表面だけの筈であるが，その薄皮内は，空白の空間の筈であるが，雲ができている。3D回転などをして，確かめているので間違いは無い。
図70で，segment toolを使って，円柱とその周辺の台座のみを採取した。それが図71である。3Dで観察したが，点群欠損部はみつからなかったが，この手順は点群ファイルには必須のプロセスであると認識している。
手順２の点群データからメッシュデータに変換した結果から，OctreeのDisplay level =6として台座付近を観察したい。図71に示す。current levelを見ると，cell size = 0.0264 mになっている。台座の雲のようなものは台座表面にくぼみとして捉えられていた。図71右手のメーン画面で一例を赤丸で囲っている。図７，35，56から推定すると，この窪みは花崗岩台座の黒班に由来するようである。Scaniverseの弱点かも知れない。色から3Dを推測するアルゴリズムが入っている可能性がある。これはかなり危険なアルゴリズムだろうと思われる。Metascanにも在るかも知れないし，さらに言えば，iPhone 12 ProのLiDARそのものの限界かも知れない。
LiDARの利用者からすれば，2D限定のPhotoshopに対して3Dで修正できるような機能が欲しい。このCloudCompareにあってもいい。何度かこのマニュアルを見てきたが，すこし深みに入ることができるような情報が見当たらない。
図71の石柱部分をこのアングルから見ると，wireが広く欠落している。これは何を意味するのか，わからない。
手順３のメッシュデータから点群データに変換した結果を図72に示す。何となく金属光沢がある。台座の凹みがより明瞭になっているし，頭の歪みも明瞭だ。Point size = 3としている。
手順４は体積計算である。「４，５ 大饗石の体積を求める１，２」と同様にする。set top viewにして，台座周辺のZ値をpoint list pickingで求める。周囲四点の最小値は0.720768 mなので，Ground levelを0.720768を切り上げて，0.721とする。Volume calculationのパネルで，Grid > step=0.001000 （最小値），size 436 x 439 (191,404 cells)。
図 73にVolume calculationの計算結果を示す。V: 0.032 ㎥, S: 0.189 ㎡, Matching cells: 98.7%。CloudCompareの計算そのものの精度はかなり高いものになったが，表３の実測値（V: 0.0548, S: 1.2641）と大きな開きがある。
次の図74は，Height difference raster (0.001)である。
この点群PLYの結果を追加すると，表４修正済みのようになる。
点群PLYファイルの体積と表面積は余りに実測値とかけ離れている。この原因として考えられるのは，元々の点群クラウドの欠損である。
とはいえ，ここで確かめなければならないのは，石碑の形態を代表する幾つかのポイントの(X, Y, Z）座標をpoint list pickingで調べて，個々の代表点から幾何学的な3Dモデルを求めて，実測モデルと一致するかどうかを確かめる必要がある。これこそ，体積や表面積を論じる以前に重要である。
次のKindle本の出版に向けて，眞さんから届いたデータを編集する必要があり，この方面の仕事は中断したいと思う。とはいえ，クラウドの欠損を補修するアプリとしてMeshLabが有望であり，次の展開のためにも，この導入に関するページを次に作成したいと思う。
以上，Jan. 25, 2023記。
追記 Feb. 6, 2023： このページのすべてを再々チェックして，数値など文章表現も含めて修正した。
おわりに
この学びの流れのなかで，3Dデータの欠損をMeshLabを使って穴埋めする のページを作成してきた。そして，１月26日撮影の段ボール三箱OBJファイルについて，MeshLabでClose Holesを実行して後，CloudCompareのFile > Mesh > Volume, Surfaceを実行し，V=0.1287㎥, S=1.4542㎡，が得られた。この値は，0.1287/0.1212 = 1.06，1.4542/1.4522 = 1.00，となっていて，正しく，体積と面積を得ることができたのである。石碑は省略した。同様の結果が得られるであろう。次は，この問題意識が始まった大饗石の体積と面積を同様の方法で求めたいと思っている。
デスクワークについては，キンドル版の次の発行に向けて時間を注ぎたいと思う。
以上，Feb. 6, 2023記。
