はじめに

　長男に押しつけられたシーリングファンライトはずっと重荷だった。E17口金の電球６本が必要で，とにかくよく切れる。在職時からヴィソラのイオンの電化製品コーナーに行って買っていた。切れないように３本しか入れないというような貧乏臭いことだった。ファンを動かすと物珍しいのだけど効果を感じない。６本のうちで３本のソケットが有効で他は使えない。LEDは特にすぐに切れる。通常の電球でも高速の点滅をする。
　そこでアマゾンで検索するがいいのが無い。こういう分野はヨドバシだ。ヨドバシの売れ筋リストで６番目ぐらいの，
パナソニック Panasonic　HH-CF0823CA [LEDシーリング スタンダードコンパクト 調光 調色 ～8畳]
を注文した。10%還元だし，夜間に注文したがその翌々日に届いた。

１　NECシーリングファンライトを何とか取り外す

　図１は電球三個を点けている様子だが小さく点滅している。図２，３のように，なかなか大きなもので，この設置の際の長いボルトが木部に刺さらず，このために電動ドリルを購入した。これを探したがどうにも見つからない。この作業のためにデスクの上にチェアを載せての作業だが，命がけである。

　図４はライト部分を何とか外したところだ。４本のネジを体を斜めにして外すことはできず，最後の１本を正面から何とか外した。ファンも大変だった。そして，図５のように固定金具が残った。これは新規のシーリングライトには使えず，図６のように長いネジ４本を何とか外した。船底天井の軸部の木部表面が剥げ落ちている。

２　パナのシーリングライト設置

　アダプタを装着（図７）し，さらに「本体」をアダプタに装着（図９）した。

　フラフラしながら装着しようとしたので，図10で赤線で示したようにカバーを落として割ってしまった。不十分ながら設置完了した（図11と12）。

以上，Jan. 29, 2023記。

３　シェードは不要

　この種の製品が出だした頃か，このシェード（製品名はカバー）は，何ともちゃっちくて，違和感もあった。壊れたままで使うのは貧乏臭くて，アマゾンで調べてみた。
パナソニック 補修用カバー カバーのみ HH-CD0823A用カバー シーリングライト用 HKHCD0823A01 のように，4,356円。全部揃って一万円に満たないので，このカバーだけで，ほぼ半額である。
　教えてgoo：シーリングライトの丸いカバーの意味は？ などにその回答があって，明らかに業界の回し者の回答が並ぶ。「カバー無しの剥き出しですと寄ってきた虫がランプ(の熱)に触れて直ぐ下に落下します。」，ほかに，明るさの説明など。全く納得できない。質問者は納得したらしいけど。図８のように，LED関係の回路は完全にカバーされていて，虫の問題は無い。明るさも実験してみて何の問題も無い。回答者は，ペンダントライトの存在を知らないのか。とにかく，シーリングライトでこの種のものは永遠に買わない（忘れる可能性もある）。
　この製品は明暗と調色がリモコン操作で設定できるので，ぼくの好みの光を得ることができた。一度調整すると，壁スウィッチでオンオフできるので，リモコンを使わなくて良い。とにかく，このダサいカバーは廃棄だな。図８を見ると異様に大きな直径であるが半分はこのカバーの留め具に過ぎない。

　文句たらたらだけど，前のNECのファンライトと比べたら，月とスッポン。柔らかな光を得ることができて，暖かな部屋になった，不平を遙かに超えて，幸せを感じています。

以上，Jan. 30, 2023記。

はじめに

　ぼくが唯一食べれるのは豚脂の入っていない日清ラーメンだったが，ただ，ぼくの腸には適さない。無害では無いが，生協の即席そばが許容範囲である。昨晩寝たのは４時前。どんどん遅くなる。雪はいいなあ。

えび天きつねそば

　BernsteinとZimermanのBeethoven Piano Concerto No. 4を聞きながら。エビをソバ汁に入れずに，別途食べた。無機的に近い味だなあ，と思いつつ食べた。かなり，間違っている。
正しくは，
１　カップ１杯ほどの水を鍋に入れて，IHヒーターのタイマーを7分にして，高温で。
２　沸騰したら，出汁と揚げ豆腐を上にしてソバを入れる。（ここから時計スタート）
３　沸騰したら弱火にして，箸でほぐしながら加熱。（経過時間2分ほどか）
４　完成？したら，ソバと揚げ豆腐を丼に入れて，エビ天を載せる。

以上，0:10, Jan. 29, 2023記。

はじめに

　これが最初かどうか，覚えていない。old-fashioned 日清ラーメンは豚脂が無いので，これにタマゴを載せて食べたりしていたが，必ずお腹に来るので，１年近くか食べなくなった。以前は居間から見える歩いて数分の太鼓亭に行っていたが何故か閉店してしまった。で，自分で料理をするかも知れないファーストディッシュ。iPhone 12 Proで撮影した。

１　即席スパゲティを用意

２　電子レンジで

３　完成

おわり

以上，Jan. 28, 2023記。

はじめに

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

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

　この章は全く自分用の覚え書きである。3Dデータの欠損をMeshLabを使って穴埋めする　で示したように，MeshLabへのメッシュOBJの読み込みの際に，ファイル名に注意を払うべきことに気付いた。ファイル名内に空白spaceを入れてはならないことである。2バイト文字日本語も入れない方が良いとも考えている。
　図１には，二つのファインダーが見える。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については変更した方が良いと思われる。その変更結果を図２に示したいと思う。
　図１の左のファインダーを見ると，Scaniverseによる出力ファイルは，メッシュ（OBJ, FBX），点群（LAS, PLY）である。LASについては，iPhoneでも使えるようになったLiDARの標準ファイル形式「LAS」ってどんなデータなの？を、PDAL/Laspyを使って調べてみる。で解りやすく説明されているが，ぼくには今のところ不要で図２では削除している。
　図１の右のファインダーを見ると，どうもエキスポートしたあとで，ファインダーで各ファイルを個々のフォルダーに整理したようである。図１の左のファインダーでは整理されていないが，実はmouseWindowsでは同様に整理している。CloudCompareでの作業ファイル群の名称が単純で元ファイルとの関係がわからなくなるために，iPhone 12 Proからエキスポートされたファイルを個々のフォルダーに入れる必要があった。その経験を踏まえて，macのファインダーでその作業を実行したのである。図１の右ファインダーでは上から見ると，段ボール三箱では，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が更新日で，回避したいからである。

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

　で，何とか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のファインダーでの「直方体撮影ファイル名再構成」のファイル群のスクリーンショットを次に示す。

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

　ターゲットは神武天皇遙拝所碑と段ボール三箱である。神武天皇遙拝所碑については表１上段の４組の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記。

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

３.1　ScaniverseのMesh Simplicationの解除前と解除後の比較

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

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

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

　

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

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

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

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

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

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

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

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

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

　これまでの経験から，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に残っていると思う。

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が優れている。その方法は一般に知られているので，後日，実施したいとは思う。とにかく，平面からなる立体の点群を生み出すのは困難を極めると言えるだろう。

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

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

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

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

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

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

おわりに

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

はじめに

　iPhone 12 ProのLiDAR機能を使って3Dファイルを得て来たが，CloudCompareでまずは体積や面積を求めるというような言わば幾何学的空間分析での基礎的な作業の際に，3Dデータの欠損に基づくエラーには悩まされてきた。そして，単に体積や面積を求めることよりも，3D空間データの位置の信頼性そのものも気にかかるところではあった。
　この種の問題を解決してくれるであろうMeshLabに本日出会った。他の用件もあるけど，大きな関心があり，ちょっと触ってみた。

１　始める前に

　MeshLabは，3Dメッシュデータ用ではあるが，点群ファイルにも使うことができるらしい。読み込み対応ファイルのうち，ぼくが使うiPhone 12 ProのアプリはScaniverseとMetascanで，これらのエキスポートファイル形式との関係では，MetascanのメッシュデータではSTLとOBJ，点群データではPLYとXYZ，ScaniverseのメッシュデータではSTLとOBJ，点群データではPLYに限られる。何らかの作業が終わって出力する形式はCloudCompareの利用を考えると，メッシュデータではSTLとOBJ，点群データではPLYに限られる。
　MeshLabアプリは，https://www.meshlab.net/ から提供されており，最新のものは MeshLab version: 2022.02　28/Feb/2022であり，mac，Windows64，何れにも対応している。さきほど何れにもインストールし，何の問題も無かった。同梱のRead.meには次の但し書きがある。

　さて，操作マニュアルを調べてみた。
MeshLAB Tutorial ここには，はじめに，Cloud Compare:
Point cloud and mesh editor，MeshLab
Point cloud and mesh editor，とあって，ネット上では，meshファイル対応と流布されているが，点群のPLYファイルが重視されている。
MeshLab Documentation November 13, 2017 | Author: Lucy Sharp | Category: N/Aこれは，2017年発行でPDFの形でダウンロードできる。ほとんど図が無くて覚え書きのような印象である。

追記　Jan. 27, 2023：　School of Design, Faculty of Liberal Arts and SciencesのMeshLab: Point Cloud to Mesh の情報はpoint cloudをmeshに変換するためのMeshLab使用の注意点を学生に示したものである。一般に3Dスキャナーで得られたpoint cloudの点数は膨大のため，その前に軽量化せよという。iPhone 12 Pro LiDARを使うボクには全くあてはまらない。ただ，MeshLabがそういう使い方のためでもあると理解できたのである。File > Import mesh，のコマンドは，そういう訳で，point cloudを当然含んでいることになる。そして，そのあと，mesh出力が可能なのである。point cloudファイルはここでは.ascなので，三段階の処理が必要になる。ぼくの場合の3Dスキャン結果の出力データはplyファイルなので，この必要は無いと思うが，図2のOBJファイル表示を見ていると，メッシュファイルであっても，faceの裏表が不揃いなので，plyファイルについてもこの三段階の作業は必要かも知れないと思う。そこで，一応，上記サイトの情報を次にコピペしておく。上記サイトには図も掲載されている。

Once it has imported successfully then you need to do three operations:

1. Compute Normals:　（メッシュの三角形面faceを作成するために必要な法線の作成）
Filters > Normals, Curvatures and Orientation > Compute Normals for Point Sets
– Accept the default settings by pressing Apply. Wait

2. Optimise your point cloud:　（これはpoint cloudの膨大なpoint数を縮減するための操作でぼくの場合は不要か）
Reduce the density of the point cloud by choosing
Filters > Point Set > Point Cloud Simplification

　このPoint Cloud Simplificationのパネルについて，
In the “Number of Samples” field pick somewhere between 100,000 (quicker, less detailed) and 1,000,000 (slower, bigger but more detailed). Click Apply. Wait.
　You will now see two versions of your point cloud scan – the original and the reduced version.
　この画面の説明として，You can switch them on and off (like Photoshop layers) in the right hand panel. Also you can drag the point size lower to get a clearer view of your scan.

3. Convert the optimised point cloud to a mesh:　（点群をメッシュに）
Click to turn off the original point cloud, leaving just the optimised version on and selected. Then Choose
Filters > Remeshing, Simplification and Reconstruction > Surface Reconstruction: Ball Pivoting
Accept the defaults and select Apply. Wait – potentially for a while.
After the process is complete you will then be able to view your mesh – if it is too poor quality you could try again by optimising the original point cloud with a higher sample count.
When you are happy with the result export the mesh using
FILE > EXPORT MESH AS
and choose an appropriate file type – OBJ would be suitable for bringing into Rhino, Blender, 3DS etc
NOTE: when you bring your mesh into your 3d application there may be “back to front” sections; in Rhino these will show up as darker patches.
To unify these normal, issue the command
UnifyMeshNormals
and select everything. This will flip all back to front faces in the same way.

　なお，Rhino, Blender, 3DSなどの嗜好を知るのに，【2021年】3DCADとBlenderは違う～3Dモデリング検証編 は参考になるかもしれない。ただ，ぼくはこの分野には全く関心がない。

２　メッシュファイル OBJの読み込み

　mouseのWindows 10にイントールしたMeshLabを立ち上げて，ScaniverseでLiDAR撮影した段ボール三箱のOBJファイルを読み込んだ。メーンメニュー File > Import mesh を実施したが，まともに読み込めない。右のペーンの下部に，赤字でエラーメッセージがある。

　ネット検索して，SOURCE FORGEのMeshLab Discussionで，たぶん原因を見つけた。

windbrand – 2012-05-18

Hiya,
I tried to import and obj model (sleeveless top) in meshlab, however it gives
this error: “Error details: some materials definitions were not found, a
default white material is used where no materials are available”. The model
imports correctly but like the error says there is no material, it’s just
blank. All my material files are there, I even tried to copy over all the
files into the same folder as the .obj file. Does anyone know what might be
causing this?
Thanks.

Giulio – 2012-06-05

Try this, it worked for all my .obj with the same error. Seems that Meshlab
doesn’t allow spaces in the name of the files.
Rename texture, .mtl file, .obj file without spaces. Open with wordpad o
notepad .mtl file and .obj file and at the beginning change the name of the
texture and of the .mtl file. Open .obj with meshalb again!

　CloudCompareでは日本語のファイル名には何の問題もなかったが，MeshLabでは問題が生じるのであろう。図２のメーンペーンの下縁の紫色の中央に，ぼくの日本語「段ボール箱」を含むファイル名が文字化け無しで表示されている。元のファイル名は，段ボール箱scaniverse_Jan10＿2complete.jpg, .mtl, objである。an10＿2completeの，＿も気になるところである。carton_scaniverse_Jan10_2complete.jpg, .mtl, .objと変更した。ブラウザーではこの変更は見えるが，MeshLabで何回か，読み込もうとしてもファイル名の変更が実現しないので，Windowsを再起動するなどした。そして，開いたのであるが，図次のようなメッセージが出ている。奇妙なことに，objファイル名は変更したものと一致するが，jpgファイルでは段ボール箱が残っている。

　　そこで，共有しているmacでzipファイル名を丸ごと替えることにしたのであるが，これを解凍すると図４のようであった。図４でハイライトがあるcarton_scaniverse⋯⋯⋯⋯⋯.zipを解凍すると，この直ぐ上のファイル名になるというか，替えたzipファイル名が全く反映していない。
　それゆえ，Scaniverseに格納されているファイルに戻って，ここでファイル名を替えて，エアドロップでmacに移動して，解凍して，Windowsに移動した。macからWindowsのこの関連ファイルを削除しようとしたがどうしてもできなかった。Windows内のファイルはWindows内で削除しなければならなかった。スクリーンショットの場合と異なる形だ。
　そして，MeshLabを立ち上げて，File > Import Mesh，を実行して，図５のように，問題無く，読み込むことができた。

　なお，ファイル名に日本語が入っていたのが原因かどうか，わからない。Windowsが，ファイル名にFEPの関係か勝手にスペースを入れていたようで，スペースが原因の可能性もある。図4では，「_ 」の代わりに「＿ 」が入っているが，Windowsで見ると，「⋯⋯Jan10 _ 2complete.obj 」とか，なっていたし。

以上，Jan. 26, 2023記。

３　CloudCompareのファイル名書式の確認を

　図５の絵作りは見事なものであった。どこにも穴が無い。後に示すがMeshLabでこの図５のファイルをwireframeやFace表示したが，ホールが見つからない。一体のunitで，ホールholeを検知detectして，それを表示して，手作業である部位についてはキャンセルなどして，一気に穴埋めする，というようなプロセスをGitHubなどで検索したが，そういう質問はあっても回答は全く無い。ネット上にはそういう役立つコンテンツが無い。昨日，半日ぐらい，英語サイトを中心に探したがみつからなかった。公式マニュアルもリスト的で役に立たない。MeshLabのプラグインリストでpythonのディスクリプションは見つかったが，変数定義が見えないので，理解するのが困難だ。

　とにかく，ぼくとしては，少なくとも10年以上に渡って積み上げられ，無料で公開されているCloudCompareとMeshLabを使って，極めて極めて低次の希望を叶えることである。ぼくの希望は何だろうか。研究のツールなのだけど，高齢なので研究テーマも極めて限定的になる。とにかく，海岸地形の計測ということになろうか。その際にpoint cloudの欠損は問題になるものだろうか。大したことでは無いだろう。身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める で拘った体積計算も，point cloudファイル情報の精度とCloudCompareの能力を知りたかったからであった。実は，体積そのものにも，研究的な関心がある訳でも無い。ぼくの性癖に由来するものである。ぼくが幾何学やpythonの高い素養があればこの泥沼に入ってしまうのだけど，幸い，そういう素養が無いので，助かっている，と切実に思う。

　さて，そういう訳で，iPhone 12 Pro LiDARで得た3D point cloudやmeshでみっともない欠落などがあった場合，自然界のものなので，そもそも簡単に補修できるものではない。欠落部分が研究の観点から重要な場合，アプリなんかでは，補修できない。現場に行って，3Dスキャンして取得するしかない。と考えると，point cloudやmeshの穴や破れが補修の対象になるのはかなり特殊な目的に限定される。この例が体積や表面積の計算であった。まあ，ぼくが何を求めているのか，都度確認をしないと行けない。

　本章のタイトルのテーマを含めて，新たなポスティングを作成した方がいいと考えた。それは，
iPhone-LiDAR + Scaniverse or Metascanから書き出された点群とメッシュを比較
である。

以上，Jan. 27, 2023記。

　次の章を当初は，「MeshLabでメッシュOBJを点群PLYに変換する」としていた。どうもこの考え方には根本的な問題があるようだ。Can I generate Point Cloud from mesh ? を読んで何となく理解できた。ぼくはmeshからいわば均等のpoint cloudが作られると考えた。その発想が根本的に誤りだった。
　MeshLabでの作業として，点群point cloudからメッシュを作るのが妥当だとすると，ぼくからするとiPhone 12 Pro内のアプリで3Dスキャンした後，点群PLYとしてもメッシュOBJとしても出力できるので，MeshLabは不要ということだ。すでに 元伊勢大饗石のLiDAR測量 では，CloudCompareで，点群からメッシュに変換し，さらにこのメッシュから点群に変換しているので，この後半のプロセスを実行すれば良い。
　そして，MeshLabを使おうと思った動機を思い出した。点群の欠損を探してそれを穴埋めすることだ。でも点群PLYで得られる像がメッシュOBJ に比べてより不完全ならば，メッシュOBJを使うことになる。

以上，Jan. 31, 2023記。

４　MeshLabで欠損を探す１

　MeshLabを立ち上げて，File > Import Mesh，で，段ボール三箱のScaniverseで作成したobjファイルを開く。それが図５になるのであるが，最新のJan. 26のものをまずはここでは使いたい。メッシュの欠損の存否を見たい。

　メーンメニューのすぐ下には，図６のように，ショートカットアイコン群が並ぶ。アイコン群16（Draw XYZ axes in world coordinates）をタップすると，XYZ軸が現れる。XYZはそれぞれRGB三原色の軸が使われており，右手座標系（デカルト座標系）になっているのがわかる。ただ，重力軸はZ軸の筈であるが，Y軸になっている。この点，注意が必要だ。
　Nos. 10〜14の五個のアイコンは，左から，Bounding Box（境界ボックス），Points（点群），Wireframe（立体の辺だけから成るような線の集合で表現されるもの），Vert（vertices 多面体の頂点），そしてFace（多面体の面）が並ぶ。objを読み込んだ際には，この５アイコンのうち，右端のFaceだけが選ばれた状態であり，図７のように見える。押されたFaceをタップして解除すると，全画像が見えなくなる。

　図８はFaceの上にワイアーフレームを表現したものである。右ペーンにもツールアイコン群が並ぶ。この部分でもより細かな設定が可能である。No. 14のFaceのアイコンをタップして解除すると，図９のようにワイアーフレームだけが見えるのであるが，余りに密度が高く，その欠損部を探すのは個々の場所を拡大しても，難しい。

　なお，MeshLabのmouse操作は特殊で，Meshlab_Tutorial_iitd.pdf p.8に掲載されている。右クリックは何故か使われていない。ぼくの環境では機能しないものも幾つかある。興味深いのは１の機能で感覚的に理解しやすい。

NAVIGATION IN MeshLAB

1. Left mouse button + drag: rotate around trackball center
2. Mouse wheel: move forward or backward
3. Center mouse button + drag: pan
4. Shift + mouse wheel: change camera field of view
5. Double click on specific point: places that point at the trackball center
6. Control + mouse wheel: moves near clipping plan
7. Control + Shift + mouse wheel: moves far clipping plan
8. Alt + Enter: enter full screen mode
9. Control + Shift + left mouse button + drag: changes light direction (this
   only takes effect if there are normals)

　それで，欠損部（ポリゴン境界やメッシュの欠損部）を探すのに，境界や穴の表示 によれば， Filters > Selection > Select Border である。その結果を次の図10に示す。境界は赤線で表示されており，段ボール三箱を置いている絨毯のトリミングの四角形の四辺に限定されており，メッシュの欠損は無いということになる。

　次に神武天皇遙拝所碑の最新OBJを見てみよう。図11を見ると，点群plyでは頭は大きく欠損していたが，メッシュobjでは全く欠損が見られない。この図11は，Filters > Selection > Select Border ，を反映したものであるが，土台の切り取った部分にしか赤線は無い。

　最新のScaniverseで得られたメッシュOBJには欠損が全く無い，ということになるが。

以上，0:20, Feb. 3, 2023記。

５　MeshLabで欠損を探す２

　ところが，CloudCompareで Edit > Mesh > Measure volume，で，体積計算すると，consoleに，”The above volume might be invalid (mesh has holes)，となっていて，改善が見られない。表面積の方はそういうエラーメッセージは出ない。両数値とも悪い数値では無いが。
　MeshLabでの，Filters > Selection > Select Border，を使ったチェックが役に立っていないのである。ワイアーフレーム表示をして明らかな穴を埋める方法については，後に実行したいと思うが，今のこの問題をどうするかで，である。
　穴埋め関係の情報は，MeshLab Simple Mesh Editing に整理されている。Close Holesに関連して，max size to be closedのデフォルトが30になっているが，このmax sizeの意味が理解できない。このサイトでは，
Close Small Holes　Holes which are “small” with respect to the mesh size, possibly almost planar…
Simple filter: Remeshing, simplification and reconstruction->Close Holes
Parameters: max size to be closed (in terms of perimeter lenght)
とある。ここでmax sizeは穴の周囲長としている。が，現物をスキャンした者からすると，単位としてメートルを考えてしまう。段ボール箱などで穴が30mという最大値そのものに意味が無いので，実際に作業をしてみるしかない。

　そこで，まずは次のサイトを参考にした。MeshLab でメッシュの穴埋めを行なう。
１　ツールバー右端の検索場で「close」を入力すると，検索結果に「Close Holes」が見え，それを選ぶと，図12のように，Close Holesのパネルが見えるので，Max size to be closed: 30などデフォールトのまま， Applyする。そうすると，図13のようなFilter Failureが現れる。ここには，filter requires edge manifoldeness，と出ている。

２　逆引きMeshLab の，Filter (スキャンデータをきれいにする)，には，穴埋め欄の説明に，
Filters > [Remeshing simplification and Reconstruction] > [Close Holoes]
Manifoldのエラーが出る場合は事前に、Filters > Cleaning and Repairing > Remove faces from Non Manifold Edges，などを実施，とある。図14のように，現在のMeshLabではより改良されている。
Filters > Cleaning and Repairing > Repair non Manifold Edges

３　図17右下のconsoleには，Repair non Manifold Edges，が成功したことが示されている。”Successfully removed 15 non-manifold faces”である。
　そして，再び，図16のように，Close Holesを実行したのであるが，図17右下のconsoleには，”Closed 12 holes and added 20 new faces”，とある。なお，Close Holesは，
Filters > Remeshing, Simplification and Reconstruction > Close Holes，で実行される。

４　とはいえ，実行結果を見ることはできない。またCloudCompareで体積と表面積を計算してみたい。
File > Save Project As…，で，3carton230126scaniverse_obj \ 3carton230126scaniverse_obj_1.mlp，で一応保存した（図18）。
　このファイルではCloudCompareで扱えないので，File > Export Mesh，を実行したが，File > Export Mesh As…としなかったので，ファイル名称変更のステップは無かった。ブラウザーで探したら，元ファイルと同じフォルダーには，新たに，mtlファイルが作成されていた（図19）。図19の右端には，このMTLファイルの作成日（時刻）があり，2023/02/06 17:46（作業時刻と一致），となっている。

５　CloudCompareで，これを開いてみた。図20のように，チェッキングリストを全部外した3Dクラウドが図20のものである。RGB情報は全く失われている。そういうものであることを，ここで認識することができた。メーン画面の右下隅のXYZ軸を見ると，MeshLabでの座標系も鉛直軸方向も変わっていない。
　segmentして，Edit > Mesh > Volume, Surfaceを実行した結果が，図21のConsoleの最下行から上の4行に現れている。何と相変わらず，体積について，might be invalid (mesh has holes)が現れている。
　V=0.1287㎥, S=1.4542㎡，であるが，身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の表４の実測値と比較すると，0.1287/0.1212 = 1.06，1.4542/1.4522 = 1.00，となっていて，正解と考えて良い。

　以上から，MeshLabでClose Holesを実行し，CloudCompareで表面積を求めるプロセスは，成功したと言えるだろう。

おわりに

　さらに，この後，明らかな欠損を埋めるプロセスをまとめれば，ぼくのMeshLab操作技術は向上することであろうが，一応，ここで終了したい。大きな欠損を埋めることはぼくには実は意味が無いことでもある。３Dプリンターを使う必要性もないし，カラー写真のようなRGBが自然に表現されている3Dイメージがぼくの求めるものであって，細々と触る必要性も無いのである。

　この結果に基づいて，大饗石のメッシュOBJを使って体積と面積を次に求める作業に入りたいと思うが，他のキンドル版出版の作業に入りたいと思っている。この体積計算に拘った切っ掛けは，大饗石の体積値が妥当かという問題意識からであった。

以上，Feb. 6, 2023記。

はじめに

　AirDrop（エアドロップ）の設定や使い方を解説 できない時の対処法は？ が大変参考になった。種々トライしたが，結局，アップルによってヴィンテージ化されたmacとiPhoneとの間では，ファイルをmacからiPhoneに送る（共有する）際にも，iPhoneからmacに送る（共有する）際にも，受信者（共有）設定をすべての人にした方が良いということだ。

１　iPhoneのコントロールセンターの設定

　最近のiPhoneでは，画面の右上から画面を下方へドラッグすると，図１のようなコントロールセンターが現れる。左上の枠内の任意の部分をゆったりとタッチすると，図２の左画面が現れる。この左下のAirDropアイコンの説明には，AirDrop 連絡先のみ，と表示されている。このアイコンをタップすると，図２の右画面が現れるが，ぼくのようなヴィンテージmac使用者は，「すべての人」を選ぶ。
　この際，「10分間のみ」というメッセージが現れる。この意味は，10分間だけ有効，ということだ。「すべての人」にすると，このiPhoneに誰でもアクセスできるために，ハイリスクになるということである。まあ，写真などを相手（または自分の他）のデバイスに送る場合，10分間というのは適当な時間である。

　この１の作業をしなくても，これまで，iPhoneで撮影した写真などをヴィンテージmacに送ることができた。何らかのトラブルがあって，送ることができない場合の対処法とも言える。

２　iPhoneとmacの間のファイル共有作業

２.2　ヴィンテージmac側の準備：　ヴィンテージmacではAirDrop利用に制限があるようだ。AirDropを使うと，Wi-Fiなどの環境は必要でなく，Bluetoothを使って，P2Pで直接近接のデバイス間でデータのやり取りができる。P2P（peer-to-peer）は，「ネットワークに接続された複数のコンピューターのうち，任意の 1 対 1 が対等な接続状態にあること。また，それを利用した技術やアプリケーション-ソフトウエア。処理能力やファイルなどのネットワーク上の情報資源を対等な立場で共有する。ピア-ツー-ピア。peer は同等の人の意」。
　システム環境設定 > Bluetooth，を選ぶ。もともとあった「iPhone」という名称の意味が理解できず，削除した。その上で，iPhone 12 Proを第１章に示した状況で待っていたら，図４のごとく，iPhone 12 Proのデバイス名「moto-iPhone」が現れ，「ペアリング」のボタンも見えた。これをクリックすると，図５のように接続済となった。

２.3　ヴィンテージmac側での作業：　macのファイルをiPhoneに移動する過程を次に示す。例えば図６のように，macの「写真」で，一つの写真を選んで，control キー + クリック（右クリック）> 共有 > AirDropを選ぶと，しばらく立つと図７のように，iPhone 12 Proのデバイス名であるmoto-iPhoneが現れる。これをクリックすると，図３のようにiPhone 12 Proの側でメッセージが現れて，「受け入れる」を選択すると，macからの写真を受け取ることができる。その結果が図７のように，moto-iPhoneのデバイス名の下に「接続済」が見えるようになる。

　このポスティングの主題は，iPhoneからmacへのファイル転送というか共有であった。iPhoneから受け取る際，これまでmacの方の準備は特にせず，メッセージが，ポーンという音とともに，画面の右上に現れるのを待つ，というものであった。許される反応時間は短いのだが，次のようにすると，大きな画面で確認することができる。
　Finderで，新規Finderウィンドウ，を開いて，ファインダーのメーンメニューの，移動 > AirDrop，を選択すると，図８中の右手のようなAirDropウィンドウが現れる。そして，iPhoneから転送してしばらくすると，図８に見えるように，macのAirDropウィンドウにファイル転送のメッセージが現れるので，ボタン「受け付ける」をクリックすることになる。

おわりに

　今後の使用過程で気が付いたことがあれば，改善してゆきたいと思う。

以上，Jan. 23, 2023記。

はじめに

　ぼくのMacBook Pro (Retina, 15-inch, Mid 2014) はアップルによってヴィンテージ扱いされ，OSはぼくの使用法では，MacOS 10.12.6 Sierraまでが対応している。”.HEIC”は，High Sierra以降に対応している。
　ぼくのWebサイトのコンテンツにiPhone 12 Pro撮影の写真を多用している。iPhone 12 Proの「写真」ライブラリーから，AirDropを通じてぼくのmacのダウンロードフォルダにダウンロードするのだが，変換中→待機中，となっても，macに「受け入れ」の枠が現れないことがある。iPhone 12 Proとmacの設定環境は同じであっても，macに「受け入れ」の枠が現れることもあるし，現れないこともある。
　何回かトライして諦めて，Google Driveか，Dropboxに送ることになるが，いずれもheic拡張子のファイルで受信されてしまい，macの「写真」やAdobe Photoshopなどでは操作ができなくなる。その対処法を次に示す。

１　iPhone 12 Proとmacの名称変更

　これは，本ポスティングと直接は関係無いが，これまで，iPhone 12 ProはiPhone (6)，macはSynchro5.localとなっていた。iPhoneについては発売第一号を購入して以来，6台目だから，自動で(6)が付いているのだろう。macは，教室でGISソフトMapGrafixを動かすためにIIfxを購入し，個人としてはClassic IIを使って以来，今の機種まで何台だろうか。８台ぐらいか。 Synchro5の5の意味がわからない。
　iPhoneは，設定 > 一般 > 情報 > ，で，現在の名前が，トップの「名前」に表示されており，さらに進むと，名称入力ができる。ぼくのmacでは，システム環境設定 > 共有，で，現在の名前がトップに「コンピュータ名：」として表示されていて，その右下にある「編集」ボタンをクリックすると，変更できる。名称変更して，mouseのウィンドウズマシーンとも合わせて，ファイル共有の際にデバイスの特定が直接的になった。

２　iPhone 12 ProのHEIC

　iPhoneで撮影した「.HEIC」形式の画像ファイルを「.JPG」形式に変換する方法 によれば，「.HEICとは、HEIF（High Efficiency Image File Format）という画像ファイル形式につけられる拡張子のこと。「HEIF」はヒーフ、「.HEIC」はヘイクなどと呼ばれています。最大圧縮率がJPEGの約2倍と非常に高いことから、2017年にiOS11とmacOS High Sierraで採用され、iPhoneの写真の標準フォーマットになりました。」とある。
　で，HEICを使うメリットはぼくには無いので，iPhone 12 Pro自体でスタンダードファイルをJPEGにすることにした。 なお，AirDropがmacと連動できる場合は，iPhone 12 ProがmacのOSを認知して，JPEGファイルとしてアップしてくれる。その設定は，設定 > 写真 >，を見ると，最下部に ，「MAC またはPCに転送」欄があって，「自動」と「元のフォーマットのまま」の選択肢があり，自動にチェックが入っている。
　iPhone 12 Pro自体でスタンダードファイルをJPEGにするには，iPhone 12 Proで，設定 > カメラ > フォーマット >，で，「カメラ」撮影の欄に，高効率と互換性優先があり，互換性優先を選べば良い。

おわりに

　AirDropとの繋がりの可否の変動の理由がわからない。この件について，次のポスティングで示したい。

iPhoneと見捨てられたmacの間でエアドロップ

以上，Jan. 23, 2023記。

moto-mac.local

はじめに

このポスティングは，Classic Editorで，今日，初めて，作成している。字が小さいので，macではコマンドキー + プラスキーを二回叩いて，字が拡大されたので見易くなった。ぼくは以前，このエディターを一回だけ使った時があり，この時にフォントを触ったかもしれないが，メイリオとなっている。サイズは11ptだ。これまで使ってきた最新のブロックエディター Gutenberg では本文のフォントもサイズも設定できなかったが，このClassical EditorはMS-Wordのようなメニューがあって，気にいっているが，いままで無自覚で使えたカラムなどの設定見出しが見えず困惑している。そして，少しずつ，わかってきた。

このポスティングを作成して気付いたことであるが，段落のはじめにインデントを入力しても，Updateボタンを押したら無効になる。How to Indent Paragraphs in WordPress にはこの手法が書かれているが，”In order to set indent for a paragraph, you need to preface the text with this HTML tag: <p style=”padding-left: XXXpx;”>, where, of course, you will swap the placeholder XXX with the number of pixels. You will, of course, need to close the tag, too, by ending the paragraph with: </p>.”とあって凄く面倒なので，ソフトリターンや段落毎のインデントは諦めることにしよう。どうもこれがぼくがClassic Editorから離脱した原因だったようだ。

WordPressのヴァージョンアップの頻度は高いが，ヴァージョンによっては，文字色の設定が可能であったり機能しなかったり，が繰り返されてきた。このWebサイトを立ち上げて３年になるが，この問題には閉口してきた。WordPressのサポート情報にも問題があるように感じる。そこでネット検索をして，一応，今日したいことはできるようになった。忘れないようにここに記録する。

WordPress (ワードプレス)で文字色をカスタマイズする方法を徹底解説！  には，「Classic Editorとは、WordPressの古いバージョンのエディターで記事作成ができるプラグインです。新しいバージョンのWordPressで使われるエディターの中には、文字色変更のボタンが使えないものがいくつかあります。使っているエディターに文字色変更ボタンがないときはClassic Editorを導入してみましょう。」，とあり，これに従うことにした。ブロックエディターはクラシックエディターから進化したものと考えていたが，これはぼくの誤解ではないが，ワープロ感覚のユーザーとしてはClassical Editorの方が使い易い。

クラシックエディターのプラグインをWordPressを３年前に入れていた。それをactiveにして，自動更新も選択した。上記サイトでは，「Classic Editorを導入して有効化したら、記事の編集画面でエディター設定をしてください。WordPressのテーマによって、エディター設定画面があったり、編集画面がそのままClassic Editorになっていたりと状況が異なります。」とある。

で，まずはまずはダッシュボードの左ペーンの見出しPluginsで，インストール済みのプラグインのClassical Editorを選んだ（図１）。図１で黄色の線でハイライトした右上の”Activate”ボタンをクリックするとこのアプリが始動する。その確認をするべく，図２のように，このClassical Editorの表示に，Deactivate, Disable auto-updates，が見えて，このボタンがトグルになっていて，現在，activated, auto-updated, されていることを知るのである。

次の図１と図２は二つのカラムからなっているが，この形を得るのには，現行のBlock Editorほど単純では無い。このカラム columnの作成法について次の章で述べる。

[su_row][su_column size=”1/2″ center=”no” class=””]

[/su_column] [su_column size=”1/2″ center=”no” class=””]

[/su_column][/su_row]

１　Classical Editorでのカラム設定の前に

図１と図２を二つのカラムに分けて掲載するには，一般にWordPress プラグイン「Shortcodes Ultimate」が利用されているようだ。このプラグインをインストールしてこのコンテンツの下方を見て行くと，Documentation が用意されている。簡単に使い方をまとめたいと思う。

以上，0:29, Jan. 17, 2023記。

昨晩，Classic EditorをPluginsでdeactivateして，他のページをデフォルトのBlock Editorで編集したら，なぜか，文字色が使えるようになった。プラグイン「Shortcodes Ultimate」をインストールしたため，かもしれない。[ ]が編集ツールに現れている。もともと，Classic Editorを使おうと思ったのは，文字色が機能しないことであるから，カラムが使い難いこのClassic Editorを使う意味はぼくには無い。とはいえ，また色文字が使えなくなる状況はすぐに生まれるだろうから，また，このClassic Editorを使う可能性があるので，ここにカラムの作成法を残す意味はあるだろう。

図３は，すぐ上のスクリーンショットを挿入した結果である。Block Editorだったら，画面の左右一杯に表示してくれるのだが，このClassicでは，画像の画素数に応じて表示するようである。まあ，実質，問題はないが，ブロックエディターに慣れていたので，ちょっと違和感がある。

図３を挿入するには，図３の左上の赤枠内の左手のボタン”Add Media”をクリックする必要がある。その後，指示に従って，スクリーンショットをPhotoshopで編集した結果を入れているフォルダーにアクセスして，uploadすると ，画面が現れる。その一部を図４に示している。図４の右ペーンでcaptionを入力して，右下のボタン”Insert into post”をクリックすると，このポスティングのように，この図４が挿入される。

編集画面から，Web表示画面を得るには，図３の右ペーンの右下のボタン”Update”をクリックして，さらに，右上のボタン”Preview Changes”をクリックすることになる。

２　プラグイン『Shortcodes Ultimate』のカラム設定

第１章を書きながら，一枚の図をブロックエディター同様，左右一杯に表示するのも，このショートコードアルティミット（今後，ショートコードと簡略化する）が使えるのではと思った。なお，ショートコードは1949年に提案された本来世界初の高級言語の一つを意味するが，そういう意味ではない。一定の作業コマンドをまとめたもので，メモ帳にでも書き込んで置いて使いたい時にそれを呼び出してコピペして使う類のものであるが，非常に面倒なので，そのメモ帳がクラシックエディターの中に実装されるというものらしい。

ショートコードを呼び出すボタンは，図３の左上の赤枠の一つに表示されているので，これをクリックすれば良い。その過程に関連するスクリーンショットを次の図５，図 6に示す。これはこのショートコードを利用した結果である。図５では，実装されている種々のショートコードが示されている。最下部の赤アイコンで表示されているのは有料版を購入した場合のツールである。赤枠で括ったのが「カラム」である。これをクリックすると，図６のように，２カラム用のショートカットが現れる。これをユーザーが編集して希望のカラム数を得ることができるのである。図６の「カラムコンテンツ」と表示されている部分に文章や画像を入れることができる。画像の挿入は，上に示した方法と同じである。では，一つだけのカラムを作るのは，図6の「内容」の四行のうち，最初のに２行だけを使って，1/2を1/1にすれば良いのではないかと考えた。図４に見える赤色の花（サザンカ）を次に挿入してみよう。

[su_row][su_column size=”1/2″ center=”no” class=””]

[/su_column] [su_column size=”1/2″ center=”no” class=””]

[/su_column][/su_row]

 

[su_row][su_column size=”1/1″ center=”no” class=””]

[/su_column][/su_row]

残念ながら，１カラムには対応していないようだ。で，開発者の公開しているWebサイトを見た。Columns には，１カラムについて，1/1 (Full width)，とあって，ぼくの想定に誤りは無いようだ。そして，図８のように，図を挿入する際に，右ペーンの下方をみると，size欄があって，これを Large 1024×898に指定した。

その結果が，図９である。

[su_row][su_column size=”1/1″]

[/su_column][/su_row]

結局，クラシックの”Add Media”による画像挿入は，いわば１カラム指定がなされていて，画像のサイズに応じて表示されている。これを画面の横幅一杯に表示したいときは，横幅を1024にすれば良いということである。画像の形によって縦幅は変わるのは当然だ。

おわりに

こうしてクラシックを使ってみると，自由度が高く，コラム設定も面倒ではなくなった。新たにページや投稿を作成する場合，クラシックを使って行こうかと思うようになった。WordPressでClassic Editorが対応しなくなっても，その時は，考える必要性の無いBlock Editorでやればいい。

以上，Jan. 18, 2023記。

 

 

はじめに

　今冬，タニハの生垣の伐採を進めている。ロープを幹に結んで，必ず敷地側に倒す必要がある。これまで航海用のノットについて数学的な関心があって本なども持っていたが結局，日常の必要性もなく，全く身につかなかった。それとぼくは3Dの想像力がどうも低いようで，その問題もあった。お箸が小さい時から正しく使えないのもそういう才能の故だろう。それでネットで調べて，自ら机上ながら練習して，やっと理解できた。ネット上のコンテンツを見てもすぐにはぼくには理解できないので，既存コンテンツを引用するが，あくまでもこのポスティングで完結する形で記述する。
　一つは，「舫（もや）い結び」，もう一つは，適宜締め付けが可能な結びである。以下。

１　舫（もや）い結び，そして，より簡潔なGnat hitch

　まずは，舫い結びを記述する。これは，知っておくと便利！ロープ・ひもの結び方おすすめ6選，から得た画像を使って，より解りやすく追加したものである。図１の赤塗りは二つのロープの重なりの手前（上方）を指示している。

　図１は四枚の画像からなるが，ステップ１〜５がある。ここでは横棒だが，樹木の幹であれば垂直方向だ。何れでも同じことである。
ステップ１　ロープの束の先端を左側に配置して棒に渡す。この左手のロープ部分を，左ロープとし，右手の方を右ロープと呼ぶ。
ステップ２　左ロープを左手に持って，左の親指に一巻きする。「小さな輪っか」ができる。（輪っかを作る場合，ぼくは，人差し指から小指の４本をまとめて一巻きするのだが）
ステップ３　この左手の小さな輪っかに，右ロープを下から潜り込ませて，上に出して，
ステップ４　さらに左ロープの先端側で下から潜り込ませて，上に出して，
ステップ５　左ロープの輪っか（先ほどの右ロープが通っているので領域は２分割されているがいずれでも問題ない）に上から突っ込んで，下から上に伸ばす。

　これで右ロープを手前に引っ張って行けば良い。この結びを外すには右ロープを抜けば良い構造になっているが長いので，左の固い結び目を外すことになる。この方法は，長いロープの二つの先端を操作することになるので，ロープの収納の点から問題が多い。

　で，Animated NotchというサイトのGnat hitchを見つけた。これはこのサイトによれば最近発見されたもので，これまで説明した舫い結びの欠点を止揚している。
　自ら試行して，左右の手の動きを観察して，図２のようにまとめた。注目される一つのノットを白線の楕円で示した。ステップ６の赤線は図２と同様の働きをしている。黄色の線は軸綱になっているロープ部分を示しており，力学的な軸線となっている。

　新しいGnat hitchの存在こそは，ぼくの作業を可能にする。手持ちのロープは長く，切りたくない。このノットで，伐採予定の生垣の幹，そして，ヤード内の松または石柱に繋ぐことが出来る。

２　中間者結び Alpine butterfly knot：　使えない

　まずは長いロープを切らずに使うのに，縮め結び sheepshank があるが，これは上記 Animated Notchでは，The Sheepshank Knot should be avoided! とある。日本語のサイトでも強い引きには耐えられないというような記述がある。”The Alpine Butterfly Loop is the best replacement for a Sheepshank. It’s a knot used to take up the slack on a line or isolate a worn section of a rope. This knot can be used to shorten a length of rope too.”

　で，Weblio辞書によると，「中間者結び（ちゅうかんしゃむすび）とは、ロープの中ほどに固定した輪つくる結び方のひとつ。ラインマンズ・ループ（Lineman’s Loop）、バタフライ・ループ（Butterfly loop）、アルパイン・バタフライ・ノット（Alpine butterfly knot）などともいう（これは結び目が蝶のような形をしていることによる）。」，とある。以下，Animated Notchの”Alpine Butterfly Loop“を参考としたい。明日のお祭りの準備があるので本日はここまで。

以上，Jan. 14, 2023記。

　一晩考えて，この発想は使えないことがわかった。この中間結びも，事実上，長くて数メートルほどの短縮である。登山のロープワークが使えるのではと考えた。長いロープをコンパクトにまとめて，数メートル単位で繰り出して行くのだから。

 

３　Fireman’s coilとsheet bend一重繋ぎを採用

　さて，長いロープを両端の中間点でまとめるという発想で，中間者結び，に期待したが，その期待が誤りであった。そして，ロープ１本で樹木に縛るという発想も不適当であった。図３のように手の届かない場所であっても，ロープを投げ上げて（枝を通じて）幹回りにロープを引っ掛けることが可能であり，図３左上の方法で，より自由度が高くなる。
　支え杭としては立木や石柱などが想定される。ここでも，図２の観点ではなく，二本のロープで縛った方が良いだろう。

　図３左手上の図で，ロープの一巻き，としているものは，図3右手のFireman’s coilで置いているもので，必要に応じて，より短くしたり，より長くしたりするのが容易と言えそうである。実はこの巻き方は誰に教えて貰うこともなく，ぼくは日常的に実施していることで，みなさんも無意識にしているのではないかとも思う。それぐらい単純な巻き方である。
　話の流れと変わるが，少し前まではこのサイトはmacのSafariで編集していた。そしてネットサーフィンはGoogle Chromeで実施していた。この時には問題なかった。すでに述べたように，アップルが当方のOS用のSafariをビンテージ化していたので，現WordPressのアプリを最近アップデートした時点で，SafariでWordPressが使えなくなった。それでアップル純正ネットサーファーのSafariを削除し，当方Webサイトの作成とネットサーフィンのいずれもGoogle Chromeで実行しているのだが，三時間ほどの編集保存したコンテンツが消えるということが，本日，なんと，２回もあった。
　それで，過去繰り返しインストールし，削除してきたFirefox（105.0.2, 64-bit）を本日Jan. 15, 2023にインストールし，使い始めた。

　図３左手上図の支え杭にロープを固定するのであるが，そのノットとして，sheet bend 一重繋ぎを選んだ（二種のロープを繋ぐ場合，太い方は青色のロープに対応する）。このノットは，ヨットの帆を繋ぐために使われてきたものである。なお，sheetは帆船の一部のロープを言う。図4の７コマの図は，Animated Knots が提供する Sheet Bend: Joins two ropes of unequal, or similar, size から拝借し，テキストや線を追加したものである。図4の右下のものは，Pinterestに掲載されていたもので，図中の３，５，６は７コマに付した番号と対応している。

　以上のFireman’s coilとsheet bendを使って，生垣伐採のropingは可能になったと思う。

以上，Jan. 15, 2023記。

４　実例紹介

　今後，タニハでの実際の作業を，リンクを作成して，紹介したいと思っている。いま，WordPressをFirefoxで使っているが，調子いい。

はじめに

　元伊勢大饗石の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

　

３　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がバッテリーを激しく食ったためにできなかった。

　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とほぼ同速度で歩いてスキャンした結果である。使用に耐え得ないので中止した。
　

　図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取得の直方体体積計算の準備

　以下，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，であり，期待していた形を得ることができた。

　

　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記。