GPGPUの概念が提案されて以降の10数年間、一応はそこそこ強力なGPUの搭載を心掛けてきたものの、それを普段の運用で有効活用できていたかと言えば否な状況が続いてきた。
が、この数か月間は今までになくGPUの稼働率が上がってきた。 NVIDIA Broadcastしかり、そしてSRCNNは非常にQOLに寄与している。
ゆくゆくはローカルGPTの運用ができるようになりたいものだな、としみじみ思う、今日この頃。
|
＜Windows 3Dビューアー って意外と使えるかも！＞ Windowsスタートメニューの先頭に登録されているアプリは、多くの場合で「3Dビューアー 」だと思う。→ それと同時に、一度も使ったことが無いアプリの筆頭でもあるような気がする。 何か有意義な使い方は無いだろうか？ さて、話は変わるが、工学系人間たるもの、自前でPC環境にちゃんとしたCADが無いとダメだよなー、とRhinocerosを購入してから16年が経っていて、今となってはバージョンアップ費用を繰り返し拠出している唯一のアプリになってしまっていることもあるので、折角なのだし、よりクリエイティブな生活の起点の一つとして、もう少し有効活用していきたいものだな、と常々。 そこで話が繋がるのだが、作成した3Dモデルを説明資料に利用するとかいいよね、だけどRhinoceros本体を持たない人でも使える表示手段が必要で、一応公式のオンラインビューワーがあるにはあるのだけど、これを利用するには説明相手に生データを渡さないとならないのはちょっとアレでもあり、ここはやはり標準化が進んでいるWebGLなら誰でも3Dビューアーで観れるよねー（…というか、PowerPointで3Dモデルの貼り付けに使えるメリットも大きいんじゃない？）、といった流れで、gltfデータを出力・活用する方法について、細々とであるが模索をしてきていた。 ここで厄介なのが、Rhinocerosにはgltfを出力する機能が無いため、プラグイン（例：AtStudio）頼りになるのだが、これがどうにも不安定で、大きなモデルが正常に出力できなかったりエラーを吐いたりで、運用上のノウハウで何とか対応しようと頑張ってはきたものの未だ安定するに至らず、そうこうしている間にプラグイン配布が終了してしまっていた。 困った。 そこで別の方法を改めて探したところ、Blenderを利用する（アドオン拡張機能を経由してRhinocerosの標準保存形式.3dmファイルをインポート→Blenderのエクスポート機能経由で.glb保存する、といった）ルートがあることを知り、随分と前からSSDの肥やしになっていたBlenderを最新版に更新してからインポーターを導入、動作確認してみた。 幾つかの問題がある（@不可視レイヤーが可視状態でインポートされる→Blender上での編集が必要、A色や反射・拡散などの基本マテリアルは対応するがテクスチャや透明度はインポートされないっぽい→少なくとも透明度はBlender上でマテリアル編集・設定が必須！、etc.）ものの、ポリゴンの破綻や座標系の矛盾といった3Dモデル変換にありがちな面倒は一切無く、望外にうまくできることが確認できた。 僥倖、僥倖。 ゆくゆくはWEBページへ埋め込んで観れるようにすれば活用の幅が広がるよねー、とThree.jsも試してみてはみたのだが、ローカルでテストするには動かすのに手間があって、ちょっと面倒さが先に立ってしまう。 まぁ、仕方ないのかな。 ちなみに、Three.js経由で表示するにはきちんとした照明を明示的に設定しないと真っ暗/真っ白だったり細かいところが見えなくなったりと、新たな面倒が加わるのなー、と。 あと、めっちゃHTMLを手作業で編集するので、25年前を思い出して、懐かしみ。 当面は3Dビューワー経由がお手軽そうなので、先ずはこちらでの使いこなしを試行錯誤してみようと思うのこと。 |
 |
＜備忘録＞
16TB+8TBで運用開始した初NASであるが、気が付けば既に2年が経過していて、残り領域が心許なくなってきた＆二重化を諦めるデータが増えてきたこともあったので、GWを使って16TB＋16TBに変更した。
が、今回はNASの設定変更も初なので、何をどうすればいいのかもさっぱり分からない。 ビクビクしながらめちゃくちゃ手探りであれこれ設定を探しながらで、何度もやり直す羽目となった。 私のNAS運用方法は、2HDDを一つの領域（ストレージプール）にまとめない：個々のHDDを別々の領域として扱って、スクリプトで二重化する使い方であるため、HDDを取り外すのであればそれに対応する旧いストレージプールの設定を消去する手続きが必要、と理解するまでに小一時間。 新しいHDDを取り付け→新規ストレージプールを作成→そこにボリュームを作成するのだが、その形式をこれまでどうしていたのかの考え方・形式毎の得手不得手を思い出すまでに小一時間、その後でこれとは別に再度ボリュームを作成する手続きが必要だと理解するまでに小一時間、最終的にNAS領域として運用するには「共有フォルダ―」を設定する必要があることを思い出すまでに小一時間。
整理しておくと、こんな↓感じか。
@QTS>ストレージ＆スナップショット>（古いストレージプール）管理>アクション>プールの削除
AQTS>ストレージ＆スナップショット>作成>新規ストレージプール>ストレージプールの作成ウィザード>ディスク選択>シックボリューム
BQTS>ストレージ＆スナップショット>作成>新規ボリューム>
CQTS>コントロールパネル>権限設定>共有フォルダ―>作成>共有フォルダ―>
その昔（30年位前）、モデムやパソコン通信ソフト設定を環境構築の都度、以前の設定方法を忘れて毎度毎度の四苦八苦をしいてた経験を思い出した。
ついでなので、普段使いのバックアップ用ポータブルHDD（4TB+5TB+2TB）を更新して5TB+5TB+4TBとする＆暗号化を有効にすることで、NASと併せて完全な3重化及びいつ死んでも遺品整理で安心できるような運用を開始。 終活は日常的に視野に入れておかないとダメだよなーと去年痛感したので、少しずつやっていこう。
あと、この容量になると、1GbpsやUSB3.0だと転送時間がもう限界ですね、ちょっとした環境変更で10時間とか20時間とかかかってしまい、数日間連日連夜ぶっ続けで転送する羽目になった。 少なくともLAN環境の2.5Gbps化は遠からず整備しないとなー、と、痛感。
|
＜「超解像はまだまだwaifu2xが一番だよねー」とか言ってたのがもう二年半前でびびった＞ 去年以降はGPTの技術により革新的なレベルでAI実用範囲拡大しているとかの昨今ですし、そういえばSRCNN以降パッとしなかったSuper-Resolutionの分野についてもぼちぼち新しい技術があるんじゃないかなー、どんなもんじゃろがい、と調べてみたら、案の定で、いつの間にか次の段階に至っているではないかと気付くことができた。 2021年には次の段階に至る超解像技術が数多く発表されていて、例えばSwinIRはGPTの基本技術Transformerから着想したモデル構造によりパラメータ数の低減（≒高速化）を実現した高レベル画像復元（超解像やノイズ除去）で長足の進歩を遂げていて、あとNAFNetも非常に実用的な実装が望めて好ましそうだ。 GAN構造に学習データに効果的な工夫を加えたReal-ESRGANは既に広く利用されているようで野良モデルが作られて生態系が回っているようだし、CNNからCUNetなど別モデルの導入されるなど元祖のwaifu2xもまだまだ作り込みが続いていて、それをベースに大量の教師データも加えて鍛えまくったReal-CUGANなどなど、より取りみどり。 特に、Real-CUGANは解像度やノイズの柔軟性も高く、加えてpythonスクリプトの雛形も用意されているのが実に嬉しい、手軽に応用環境が構築できる高い実用性を備えた構成で、使い勝手が非常に良さそうだし、軽く試してみたところでも超解像画質はSRCNN版のwaifu2xより明らかに高いし、GPUの利用効率も高く、処理速度も十分納得がいくレベルだった。 更に言うなら、ノイズ削減効果によるポジティブな副作用である逆ハーフトーニングの効果が数段強力となっているのも好ましかった。 というわけで、普段使いしてきた超解像やノイズ処理用途の役割をwaifu2xからReal-CUGANに移行することにして、sendtoへ登録したスクリプトなどを一斉に切り替えた。 過去の低解像自炊データとか一括して処理したい。 |
|
α7s＋広角で南天の場合、denoise 1xと2xと3xの差は極々僅か。強いて言えば2x寄りの1xが丁度よさそうかなって印象？
α7s＋広角で北天の場合、2x→3xで僅かに星が増えてるかもしれない、という感じがしたかも？
α7s＋APS-C用対角魚眼の場合、星像が崩れてコントラストが下がる端部がちょっぴり締まるような3xかなー？
α6100＋広角で東天の場合は、1xだとノイズは消えないので明確に3xだが、ちょっぴりアーティファクトが点在しているような気がする？
α6100＋円周魚眼の場合も、ノイズも厳しいし、やっぱり星像が崩れる端部がスッキリする3xだろうけど、天の川とかアーティファクトなんじゃないのかという賑やかさ？
NEX5T＋広角＋ソフトフィルタの北天は、2xと3xの差が僅かっぽいが、光害が入るならコントラストが向上する3xがよさげ？
取り敢えず、従来NRよりも遙かに高画質化が期待できそうなことは確実で、嬉しい限りだ。
ここまでを踏まえて、最も高画質なタイムラプスVR素材化するにはどうした順番で作業すればいいかを検討。
タイムラプス用の場合、時間軸方向のノイズ削減が不可欠であり、スタッキング相当の時間軸方向の処理をどの段階で行うのかが非常に重要で、また一回の撮影で1TBに迫る中間ファイルが生成される運用も想定した上で処理のパイプラインを考える必要があり、悩ましいのだ。
・最も微光星を鋭い像で拾い上げて星の数が多いのは、意外やAスタック前にノイズ削減した時で、非常にスッキリとしている
しかし、極小なアーティファクトが散在している模様で、動画化するとチラチラしそう
・これ↑をスタックすると、微光星が消えてしまっている
・@を直接スタックしたCはノイズが半減した一方でなんか眠い画像になっている
・これ↑をノイズ削減したDEは安定した微光星がくっきり得られている
・DはJPEGゆえハーフトーン部がややノイジーとなるがEとの差は極僅か
---
スタック→NR3xの順でよそうだ。（？）
さぁ、GPU本格酷使の始まりだ。
＜一生で何回もやらない＞
機会があったので、本籍から抜けて（分籍）して自分の戸籍を作った。
本籍の戸籍謄本（全部事項証明、戸籍全部事項証明書）は去年入手していたので、後は最寄りの区役所戸籍課で分籍届を貰って記入して提出すればOK。無料。
「本籍に登録する本籍地は居住地に限定されず、割とどこでもいい」という知識は以前から知っていたのだが、肝心の「本籍に記入する本籍地の記入方法は、我々が普段使いしている【住所】に相当する【住居表示】ではなく【地番】での表記がデフォルト、但し登録する本籍地が自治体により【住居表示実施地区】であれば【住所】での記入で構わない」といった、前提となる知識(住所≠住居表示≠地番≠家屋番号!といった背景の理解)が不可欠のややこしい条件を勘案して決定する必要があり、全体像を把握するのに難儀した。
私の選んだ本籍地は、GoogleMAPの住居表示と路線価図の地番表記が一致していてこれが本来の地番表記なのか違うのか正しいのか分からなくて混乱したが、「住居表示実施」の存在さえ理解できれば、この場所がたまたま住居表示実施地区で、更に「×××町」の「町」も「字」もない所であったりで、割とシンプルに記載内容を決定できて、まぁ、結果オーライだった。
あと、分籍届の窓口で担当者に訂正されたのが、「父母の氏名 父母との続き柄」に記載する名前は戸籍に記載されている自分の実の【父】や実の【母】であって、現時点で家族と認識されている（継父や継母などの）父母ではない、というもので、私は「ふーん？」程度の感想だが、人によっては嫌な気持ちになるんだろうな、と思った。
あ、そういえば、印鑑（認印）については、分籍届に捺印は任意という但し書きがスタンプされていたので、持参する必要は無かったようだ。これはコロナ対応での印鑑レス化の一環だろうか。
そんで、「自己の身分を証明する書類（運転免許証等）」を持参したけど、最後まで確認されなかった。 つまり、他人が勝手に分籍してしまってもさして問題が生じない程度の制度なんだろうか、戸籍って。（ええんか？）
まぁ、これら全部が今後必要ない知識なんだなー、と思うと、人生とは無駄の集合体なのだな、としみじみ。
