The inner of [Ti]
MISCELLANEOUS '15-

20191231
本日の最高気温20.1℃


20191021
健康と安全・安心の大切さ


20190815
更新更新



    <卒業生>

    UdacityのSDCND卒業祝いにノベルティが届いたー


    <またか>
     強化学習の勉強過程で、並列処理用にMPIをインストールしようとしたら、エラーが出て失敗する。
     んもー。
     フォルダの権限がなんか変だったので、書き換える。 でもダメ。
     システムフォルダも書き換える。 やっぱダメ。
     再起動する。 ログインしたら黒画面にマウスカーソルだけになった。
     なんだこれと調べた結果、どうやらデスクトップシェルであるexplorerが立ち上がらない状態のようだ。
     今から思えば、この時点でリモートデスクトップ経由の再書き換えで良かったのだと気づくが、この時はとりあえずセーフモードを試そうと、電源ボタンでの強制終了x2を試す。
     そしたら、DELLのユーティリティであるサポートアシストが立ち上がって、セーフモードに入れない。
     サポートアシスト解除の方法が分からず、延々と時間を無駄にするも、2時間後にBIOS設定でなんとかなることを発見。
     だがしかし、これでも、何度やってもセーフモードが始まらない。 DELL特有の症状だと諦めて、別の方法を探すこと2時間。
     ログイン画面からの電源OFFのGUIボタン→SHIFTを押しながらの電源OFF選択→画面遷移するまでSHIFTを押し続ける(これを忘れがち)でスタートアップ設定画面に到達、ここでようやくセーフモード起動を選択できる状態に。
     だがしかし、よくよく考えたら少し前にシステムイメージのバックアップを取っていたような気がするぞ、と確認したところ3カ月前のシステムイメージを発見。 早速リストア、復旧完了!
     これでようやくMPIをインストール、エラー! んもー!
     ここに至って、これはもう仕方がない、と腹をくくって、クリーンインストールを敢行することにした。
     Alienwareの肥やしになっていたM.2ディスクに差し替えて、手ごろなUSBドライブが無かったので128GBのSDカードからインストール。(したら、インストールはできたけど、SDカードが壊れおった…)
     システム復旧の段取りはこれまでの知見を整理したメモがあるので、半日で復旧完了。 以前は二日がかりだった。
     これでようやくMPIをインストール、エラー! なんでやー!!
     結局のところ、管理者アカウントを別に作って、そこからのインストールで回避できると分かった。 そういえばVirtualboxもそんなだったな。
     …そうなると、ここまでの時間はまったくの無駄だったのだろうか…。
     気を取り直して、開発環境の再構築を開始。
     Visual Studio は、Pythonを対応させるために2017版のインストーラーを…、MSサイトからダウンロードできねぇ!
     幸いにして1カ月前にたまたまDLしていたので事なきを得たが、これが無かったらどうしようもなかった。 これからどうしよう…。
     まぁ、いい、次はCUDA toolkitをインストール…エラー! また失敗かよ!! またかよっ!
     しかしこれは4月に経験済みで、対応策もメモしてあるから…、全部失敗するぅ!
     念のため、別アカウントでも試すが、そちらも回避できないぃぃ!
     万事休すか?! となるが、CUDAの場合はインストーラーがエラーログを吐き出してくれている、つまり失敗個所が特定できる&詳細インストールモードを選べば失敗個所を回避したインストールの設定が可能なんじゃないか?と気付く。
     賢いぞ、俺!
     結論として、数回の試行錯誤があったものの、無事にCUDAのインストールが完了! 速やかにcudnnもインストール!
     次はPython環境構築。 Anacondaインストール、tensorflow-GPUをインストール…失敗しやがる! むきー!
     しかしログがしっかりあるので、根気よくpipやcondaを駆使して駆使して駆使して…、できた…。くじけそうだった。
     PyTorchはあっさりインストール完了、RLライブラリもインストール完了。
     さぁ、並列処理のテストコードを実行…、失敗! んもー! んもー! んもー!
     エラーログを確認して、問題のライブラリや周辺ライブラリのバージョン構成を確認するが、全く問題ない。 流石に、ふて寝。
     翌朝、エラーの出たライブラリをダウングレード。 すると、あっさり並列処理成功! …納得しがたいが、まぁ、世の中こんなこともあるだろう。
     あと、ここでchainerもインストール。 すぐに終了。 嫌な予感がしてcupyを確認、やっぱりインストールされてない&できない!
     どうやらcondaでインストールしたcudaだとchainerはPIPインストールができないっぽい。
     やむなく、condaでchainerをインストールするも、一緒にインストールされるcudnnとかのバージョンがTensorflowやPyTorchと矛盾しないか、超心配。
     …とりあえず、なんとか動いているっぽい?
     なんというか、粗忽粗忽で裏目裏目の選択しかできない人生の縮図ではないか、みたいな?
     反省しなさーい!



    <星景撮影用カメラなのでレンズ交換を暗闇で行う>
     …なのだが、先日たまたま(数年ぶりに?)明るい所でレンズを交換したところ、天体撮影用フィルタ組み込み改造済みマウント変換アダプタ部にガタがある!?と気が付いた。
     このアダプタ、最初から光軸回りの方向に多少のガタがあったことは覚えていたが、ここで気付いたのはピッチ方向のガタ。
     そういえば、というか、ここ数年、撮影した星像の片ボケが持病で結構な悩みの一つだった。 しかも毎回ボケる方向が変わるので、「(撮像素子を改造した)ボディじゃなくて、レンズにガタでもあるのかなぁ→それなら多少絞り込んで改善するかしらん」などと試しては画質を劣化させて、不本意な星景写真を量産していた。
     とんだ濡れ衣、そしてなんという徒労であろうか。
     速やかにバラしてみると、

    リングを固定する3か所のネジが緩んでた(他のネジより一つ細いドライバに交換しないと締めこめない寸法・場所で、もしかすると最初から緩んでいた可能性も?)

     てか、バヨネットのリング固定のネジすらゆるゆるであった。 ダメダメである。
     念のため、もう一つあった改造済みマウント変換アダプタも分解したところ、同様にネジがゆるゆるであった。 超ダメダメである。
     い、一体…、いつから…。



    <VRコンテンツ撮影用>
     6年前、オーロラ撮影用に購入したAPS-C用の全周魚眼レンズ MADOKA180、超低価格・小型軽量でありながらも絞り開放の画質が完璧すぎて絞り込む意味がないレベルという凄さもあって、その後も意外と撮影の機会が多くて大活躍だったのだけど、超広角でF値が4と暗いことから、明るい星しか撮れない・映らないという弱点も。
     まぁ、サブで使うには十分だし、もう少し撮影の自由度が高くなると嬉しい。
     ここニ、三年で、中華レンズで似たような企画がちょくちょく出てくるようになったので、


    ポチった、届いた。


    室内で周辺画質の確認テストをしてみる


    絞り開放だと周辺部に「昭和のレンズか!」と懐かしくなるようなコマ収差が出てて微妙かも

     このコマ収差は、F8まで絞り込んでも消えず、F22まで絞り込んでやっと、という感じ。
     ハテサテ、どんな写真が撮れるかな?



    <我が家最古のデジタルガジェット>
     吾輩は家電苦手おっさんでなのでスマホを使ってない。
     ただ、ポータブルのテキストリーダー兼音楽プレーヤーとしてはオフラインで使っている。
     その用途には廉価なエントリー機でも十分すぎる由、5年前のAndroid4.4を使い続けている。 むしろ、軽くて(120g)小さくて(4inch)国産(SONY)で、今なお非常に使い勝手がよろしい。
     だが、ここに来てデカくて(5.5inch)重くて(250g)中華機(OUKITEL)を買った。

    防水でアウトドアデザイン+ワイヤレス充電対応 どうせオフラインで使うので中華機でもOKかな、と

     で、ハンディGPS機のGPSmap60CSが使い勝手良すぎ(完全防水・耐熱・耐寒・リチウム乾電池駆動で一年使える)の結果、かれこれ15年(iPhoneとかが登場する3年前から!)延々と使い続けていたわけだが、新しいバイクに乗せ換えたらホルダが共振してしまって落ち着かなくなったので、この機会に十分廉価・高性能・安価となったスマホで更新しようかーな、と思った次第だったわけで。


    重さについては、ハンディGPSの代わりに使うことを想定→現在使用中のGPSmap60CS相当なのでまぁ許容範囲かな

    ホルダもスマホ用を新調。いい感じに固定…、


    あれ? このホルダって、うまく固定できなくて死蔵してきたNAV-U37も、引退勧告中のGPSmap60CSも固定できるんじゃね?



    <試行結果からの反省で>

    左手で操作できる&対向車の陰に置くべきだった&シールドに迷光させない位置を探して、こうなった



    <13年間使っていたBフレッツ>

    突然NTTから連絡が来て、VDSLが無料工事で



    フレッツ光ネクストへ変更されたー






    チタン印鑑が予想外に安価となっていると知ってポチってみたら5日で届いた

    来週辺りに実印登録してきましょうかね。


20190505
年号があぁぁぁ!変わっているぅぅぅぅ!!
     まぁ、平常運転なんですけど。



    <立ち止まるな弱音を吐くな>
     Windowsの1809への更新、Udacityの課題が佳境だったので一区切りするまでパスしてきたが、やってみたら、なんか、失敗しまくる。こんなの久しぶり。
     Webで失敗事例対策を調べて、開発者モードが原因なのだと判ったので、これを解除して試して、…失敗。なんでや!
     5回連続で失敗したところで、ようやくミスに気付いて、無事Updateできた。
     ミスは、「開発者モードを解除」するだけじゃダメで、「開発者モードをアンインストール」の手続き「も」必要だったこと。
     私の場合、たまたまWindowsMRのコンテンツ開発があったので開発者モードにしていたが、普通にユニバーサルアプリを開発している人は多いだろうに、そういった人達に辛い経験をさせるというのは、このご時世にあってMS的にマズイのではなかろうか、と思わなくもない。
     この程度の明確なものなら、ここまで不親切にする理由が意味不明ですよね。 …てか、これは減らず口で、注意力散漫なのも原因なのは自明で、これが歳のせいかと気付いて恐ろしくなるです、ガクブル。

     で、そのUdacityの課題だが、複数の仮想環境を連携させながらプログラミングするというものが多くて、流石に5年前の21inchでは使い勝手が悪い、というか非効率なので、ディスプレイを更新しようかな、と思い立った。
     今なら4kが旬なのだろう、が、4kの超高DPIによるWin32アプリの使い勝手マジ劇的劣化(小さすぎて見えん!)を今なお甘受している折、普段使いの環境は劣化させまいとの修正力が介入した結果、27inchWQHDディスプレイを選定、新製品なのだがタイムリー&ラッキーで5万円!

    18年前に最初に買った16inch液晶ディスプレイよりも軽量!なので当時のディスプレイアームが余裕で使えるという驚きも


    工場出荷時の設定(明るさ75、コントラスト75)で色空間をチェック

     非常によく調整されていて、確かにsRGB99%と謳うだけの状態。 久々に文句なしでいい買い物でした。




    <Udacity自動運転エンジニアコースのTerm3もいろいろと躓きやすい>
     去年の5月から取り組んでいるこのコース、去年の10月にシラバスが変更になってて、より基本的なintroコースが新設され、こちらはアドバンスドコースとしての位置づけになると同時に講義内容の3割ぐらいがドロップされて、Term1とTerm2を半年で行う2ターム制になったようです。 機能安全やコンピュータビジョンの一部が無くなっていて、負荷が高かった開発環境構築も皆無となるので、このシラバスなら3か月前に卒業してることになるのかよ、と。
     講義内容の難しさよりも慣れない開発環境構築を否応なくせざるえないところでかなり労力がかかる覚悟が必要、その分だけ確実に実務に繋がる経験となるUdacityだ、という認識だったのだが、その点では随分と価値が薄れている感が少し。  でもまぁ、変更前に受講開始した人は、古いシラバス最後までやることになっているようなので、私には関係ないのだ。 Term3でも相変わらず右往左往だ。 てか、躓いてばかりすぎる。

     Project2(SemanticSegmentation)に向けて、特殊ビルドのTensorflowをAWSのAMI化した環境から使う講義があったのだが、これまでの講義や課題は自前のGPU環境で十分だったことから、EC2は全く使ってこなかったツケがここにきて顕在化することに。 なにしろ、インスタンスの立ち上げ方から何からさっぱりわからんのだ! しかも、ここではスポットインスタンスを使えという指示で、その振る舞いは初心者にイメージしにくいことも混乱を助長。 観念して、用語の一つ一つをググりながらなんとかインスタンスを立ち上げても、PuTTY(ターミナル)の使い方がまたわからん。 てか、LinuxをCUIでログインしたりしたことが無かったのだから、説明文と脳内イメージとのギャップを埋めるのにまた時間がかかるわけで。 さらに、たまたま一回だけログイン成功したあと、それが再現できない症状が何日も続いて、その間、Firewallの設定を変えたり、ルーターのセキュリティをいじったり、あれこれムダな試行錯誤をした結果、なんのことはない、正しくはインスタンス作成時のセキュリティグループ設定をdefaultと「しない」ことに気付くのまでに1週間ぐらいかかってしまった。 こんなレベルのFQAなんて存在しないので、ムダに時間がかかってしまうのだ!
     ちなみに、この試行錯誤中はAWSがどんどん課金されるわけだが、Udacityから$100分のクレジットが提供されていたことを思い出し、その手続きをしようと、またしても右往左往。 普段使用しているプロバイダのメールアカウント、Udacityで使用しているアカウント、AWSで使用しているアカウント全部違って、それぞれを紐づけたり、迷惑メールフィルタが悪さしたり、クレジットの手続きがAmazonEducationへの登録を意味するのであると理解できるのに時間がかかったり。 あぁっ、イライラする!
     で、散々苦労させられて使えるようになったインスタンスだが、提出課題には何の関係もなかったというオチにがっかり。
     そして提出課題は久々のディープラニングなので、Term1終了後に新調してGPGPU能力150%のPCをぶん回せるぞと思いきや、GPUメモリ不足で起動すらできねぇ! この問題を解決できるまでに、結局2週間かかってしまった。
     定石のバッチサイズ調整やデータセット規模縮小などはまったく効かず、さんざんググって見つけたTensorflowのconfigによる起動時のメモリ確保調整が効いたり効かなかったり。 Term1で使っていたGTX980M(4GB)では確実にNG、GTX1060(6GB)で時々OK、GTX1080Ti(11GB)はOK。 この不安定状態のまま、提出寸前まで課題を進めた。 が、最後の最後になって「あぁっ!Chorme/IEなどのブラウザが立ち上がってるときがNGだった!」と気付くに至った。 なんでや! こんなん、Tensorboard使えないやん! 買ってからまだ半年に満たないPCなのに悲しすぎる、と文句も出る。

     Project3(Functional Safety)は、20数年前のISO9001対応ドキュメントを延々と作成してた辛い日々を思い出す。 プログラムの提出は無いが、合計40ページ以上のドキュメント5つを提出するために、週末は来る日も来る日もドキュメント作成。 しかもMS Wordで作成する必要があったが、手元に無いのでWindows標準アプリのワードパッドで作成したら、提供されたテンプレートファイルが壊れていたことに提出の直前になって気が付いて、仕方なくOfficeOnlineのWord上で全部書き直したという切なさ炸裂。 やっとのことで提出しても、レビューはISO26262認証企業が担当?なのか、随分と素っ気ないレビューでしょぼん。
     しかも、実は選択課題で提出する必要が無かったことに気付いた。また1カ月ムダにしてしまった!

     さて、いよいよ最後となるProject4に向けてのROS講義では、再び仮想PCでUbuntuを、しかもUdacityカスタムの配布イメージを使うということで、メジャーバージョンアップのあったVirtualboxをアップデートするいいタイミングかな(と血迷って?)…あれ、インストーラーがコケる。 古いバージョンをインストールしようとしてもダメ。 アンインストールしてからインストールしようとしてもダメ。 Virtualboxコミュニティの記事を読んで怪しげな対応をしてもダメ。てか、これはWindows側の持病みたいなものだと、諦め気味っぽい。 うわ、ヤバいヤバい。 と、散々慌てたところで、「ローカルユーザーを作成、そこからならインストールできるよ」という日本語の記事を見つけて試したところ、2回目でインストール成功! やれやれだぜ。 てか、そもそもVirtualboxをアップデートしようと思ったのは、旧バージョンでUdacityカスタムのUbuntuイメージにGuestAdditionsCDがインストールできなかった:つまりデスクトップサイズは小さいまま固定だし、ホストOS側とはクリップボードもフォルダも共有できないという不便極まりない状態だったからで、この症状は(いらん)苦労してアップデートした後もインストールできない状況のままで、まったくの徒労だった訳なんだが。 で、仕方なく(最初からこうすればよかったのだけど)フォルダ構成などをよくよく調べてみると、一応CDはマウントできているが、どうやらパーミッションの関係で中身が読めない症状のようだ?と推測できたので、マウントされる筈の/media/<ユーザー名>/<CDイメージ名> から<ユーザー名>フォルダのパーミッションを確認すると、案の定、我々生徒はなにもできない状態になっていた。わざとかな? sudo chmod o+rw で書き換えるれば、CDが見えるようになったが、依然としてAutorunは動いていないので、自分でインストールスクリプトを渋々実行(sudo ./VBoxLinuxAdditions.run)しないとダメだった。 ここで再起動すれば、クリップボード経由のコピペはようやくちゃんと動いたし、デスクトップサイズも可変になったので、まぁ、良しとする。 あと、共有フォルダもsudo gpasswd -a <ユーザ名> vboxsf &再起動で無事読み書きできるようになった。 ふいー、これでやっと作業に入れる。(もう満腹)
     まぁ、要するに準備が大変ってことだ。 段取り八分、ホント、これ。
     で、作業に入ったら入ったら入ったで、この状態ではPythonのライブラリが足りないので、pipしたら「古いからアップグレードしろ」言われるのでしたらpipがまともに動かなくなる病の罠にかかり、しかもユーザー権限の制約で元に戻せない。(後日になって、 wget https://bootstrap.pypa.io/get-pip.py、 python get-pip.pyで回復できると判ったけど) いきなりケチがついた。 しかもこの状態でVMをエクスポートできない。再配布できないような制約をつける仕組みがあるのだろうか? 引っ掛かるなぁ。
     気持ちを切り替えて、コツコツちまちまじりじりとコードを書いていたら、この課題の工数、今までの課題の5倍くらいあることに気付いて途方に暮れて、そのうちになんだかシミュレーターとの通信が遅延するようになって、コードを戻してもVMを再起動してもダメで、延々あれこれ試した末に、ホストPCを再起動すれば復旧すると分かるまでに半日がムダになった。 むっきー!
     あと、デバッグの表示のさせ方やツールの使い方を把握できるまでに二日かかった。 うーん、こういうのって高齢者には辛いぃぃぃ。
     そうして延々と試行錯誤した結果、仮想環境では遅延やらGPUの都合でスペックが明らかに不足で、ネイティブLinuxPC上でないと動かない、新規構築が必要と分かる。またか。
     そこで往生際が悪く、インストールを嫌ってLiveUSBを作ろうと思い立ち、そういえば以前作ったのがあるじゃん、と思い出す。 半年ぐらい前に作ったSSDを蔵出しして、その間にWindowsを新規インストールしてたので起動しない、それをなんとかしようと頑張る頑張る、新規作成した方が手っ取り早いくらいの時間が経過して、結局作り直した。 もう、なにやってんだか。

     この課題で要となる信号機のリアルタイム画像認識については、現在最強と名高いYOLOを選定して、学習処理や使い方は既に環境も整っていて使い慣れたWindows側でやろうと慎重に進めるも、どうしてもビルドできない。 調べていくと、どうやらCUDAが古くてVisualStudioのバージョンアップで対応できなくなっているらしい? ならばCUDAのバージョンを上げよう、と9.0→10.0に…失敗!なんでや! 散々粘って……こいつとかこいつか! むっきーっ!
     ここからCUDA10.0のインストール完了まで4時間。しかしビルドはあっさり完了。最初からこうしておけばよかった…。
     これでやっと信号機専用の識別器を作る作業に入れる。 癖のあるアノテーションデータを整形するスクリプトを作成する時間が、Darknet.exeでTrainする時間より遥かに長くつくのが解せんなぁ、と思いつつ、流石の高精度認識に惚れ惚れする。
     出来上がったモデルを実装用にKerasへ変換すれば…、あれ? 精度が低下してねぇか? 学習が不足してたのかと、5倍かけたものを使ったら更に低下。 …ひょっとして、変換した後で再学習させないとダメなのか、と気付くまでに1週間。 再びアノテーションファイルを作り直して再学習、あぁ、やっとこ識別機が完成! あー、面倒だった。
     なんだかんだで100時間近くかかって課題を提出〜二日後にレビューが帰ってきて、一言目に「うまくいきました!」で喜んだのも束の間、ログ映像を観るとシミュレータではきちんと動いているが、実車の信号識別がちゃんと動いていない模様。なんだよ、ダメじゃん。 それでも「これでも卒業できるよ」と書いてあったけど、ここまで来たらちゃんと全部クリアしよう、と識別器の再学習に取り組む…、が、何度条件を変えても提出版の識別器が一番安定しているっぽい…。 うーん…、あっ。(イヤな予感) ゴソゴソ…。 うわー!
     予感的中、シミュレーション⇔実車で識別器を切り替える設定ファイルが、両方ともシミュレーター用を指定してた! なんたるケアレスミス。
     ちゃっちゃと書き換えて再提出…、した後に、またしてもイヤな予感がして見直してみたら、修正したファイル名の「-」と「_」を間違えてた! あぁん、重ね重ねのケアレスミス…、いや、不注意なのが実力なんだろう。 大学受験で合格しても、入学手続きの日を間違えて入学できなくなる寸前になった(締め切り数時間後に窓口に泣きついて、なんとかしてもらった)経歴を持つ私である。持病が再発したと考えるべきなのだ。
     気を取り直して、再々提出…、できねぇ! どうやら先に出した提出物が処理されないと次の提出処理ができないっぽい。 エラーと一緒に表示されたメールサポートに連絡を入れるが、時差があるし休日だしで、タイムリーな処理は望むべくもない、詰んだー。 二日間はムダにしたー。
     …で、その後も未練がましくサイト内をウロウロしたいたら、サポート窓口が他にもあることに気付いて、念のためにこちらからも対応をお願いしてみるか、とリンクを辿ってみると、こちらはWEBフォームで送信する窓口で、タイトルを入れたら関連するFAQのリンクがズラリと並んで、「いや、それは先刻読んだよ…、あれ?」と別のページがあることに気付き、そこには提出をキャンセルする方法が! いや、これ、分かりにくすぎる手順だろ、とは思いつつ、ありがたくキャンセル&再提出!
     ちなみに、レビュー時のシミュレーターはテスト用と違った〇〇の〇〇パターンになっていて、〇〇〇に〇〇と〇〇に〇〇〇〇になるように制御されているので、この状況を想定したロジックを組んでおかないと〇〇〇してしまう→失格みたいな罠があるっぽい? 私のはたまたま上手く動作するロジックだったので問題なかったようだ。 ラッキー!

     …いや、いや、そもそもこの時点で実は提出の手順をいろいろと間違えていたんですけどね。
     その修正手続きに20日間かかって…、




     Udacityを受講して、この終盤になってようやく分ってきたのは、とにかく常に勉強のやり方を工夫し続けろ、ということ。 歳をとってからは、一旦やり方を決めたら後は作業とするような低燃費スキームで日々暮らしていますが、それがうまく回らないように講義が組み立てられているっぽいです。
     物事に対して腰の重い・慣性の大きい高齢者には辛い仕様だが、若い連中のように小回りを利かせた取り組みができる人材を求められている、そういうことなのかもしれません。(?)
     それができない高齢者は、いきあたりばったりですべての罠に躓いて、遠回りしまくりで、やっと卒業です。 長かった!




    <冬キャン!>
     今年の正月はいつものキャンプ地(標高1700m)に積雪が無かった&バイクの防寒改造が済んだので、3日に今年のキャンプ始めを敢行、平年なら明け方は-10℃は普通の場所ですが、この日は-7℃程度で割と余裕をもって朝を迎えることができた。
     この時期のキャンプは初めて(平年なら11月下旬が店じまい)なので、今後改善しなければならない点も幾つかあったが、喫緊の課題は足の防寒対策追加かなー、となった。
     今回、怪人ブランケットでぬくぬくしながら星を眺めよう、あわよくば仮眠もしてしまおう!との憧れから、ハイチェアを購入した。 実際に運用してみた結果は、期待通りでいい感じだったのだけど、この使い方をすると爪先の冷えが割と深刻だと判った。 歩き回っている間はまったく問題にならなかったのに。
     一応、アラスカで-40℃の買い出しアドベンチャーでも問題のなかった防寒シューズを履いていたのだけど、じっとしてると足の裏から冷え冷えとなるわ、これ。
     そこで、アラスカでの徹夜用に用意して現地レンタルブーツのインソール交換用に用意したきりだった厚手のボアに入れ替えることに。 ただ、これをすると、厚手の靴下が使えなくなるのが気掛かりか。
     なので、イザとなれば電熱グッズを更に追加すれば対応できるのではなかろうかと、中華アイテムを購入。



     早速、通電してみたところ、消費電力は片足で0.6A弱と控え目なかんじで、温度も人肌程度っぽいです。 恐らく、ホントの寒冷地ではキモチ程度の効果しかなさそうですが、さて、どんなもんでしょうね。



     が、そうこうしている間に春になってしまったので、驚きの結果?はまた来年!




    <Tricityは視野が狭い(夜)>
     ヤマハの特設サイトでは視野が広い!と謳っているが、夜間のつづら折りでコーナーが見えない恐怖を一回でも体感すれば「嘘だっ!」と言い切れるのは間違いない。
     ヘッドライトの配光が悪いのか、コーナーの出口をまったく照らしてくれない。 ヤマハの基準だとこれでOKなのか、それとも邪悪なエコランプ設定と合わせてTricityは街灯のある市街地以外は走るなということか(これが一番ありそう)、はたまたBMWの照明がお節介すぎただけなのか。
     とにかく、恐怖やリスクを回避せねばやってられない。 これまでフォグランプなんて飾りだと思っていたが、必要な車とはこういうものなのだったのか、と初めて知った。
     しかし乍ら、調べてみるとフォグランプの配線や装着はかなり面倒そうである。
     そこで、昨今のLED化で高性能化したマグライト(というか懐中電灯)でも用は足りるのではないか、と考えた。 自転車みたいに取り付ければ、配光の自由度が上がって、配線の面倒もなくなるのでは、と。
     こうした構想を温めつつ部品を集めていたのだが、ふと、自転車乗りのライトは車体だけでなくてヘルメット上も割と普通ポジションなのでは、と気付いた。 傍から見ると滑稽に感じなくもないが、夜間の野外活動で頭部にライトを装着したときの利便性は実感してきた経験からも、なるほどこれも合理的だと類推できる。 昔、カメラをヘルメットに装着していたが、それのライト版だと思えばいい。
     早速、ガラクタ箱を漁って使えそうな部品を探してみたところ、よさげなものを発見。 12年前のナスカ・アンデスツーリング前、ヘッドマウントカメラ収納用ケースの候補として東急ハンズでいろいろと買い込んだ中にあった、TOPEAKの着脱自在のハンドル取り付けポーチ(廃番?)だ。



     ライト径が丁度ハンドル取り付け径と同じくらいだということで、ハンドル取り付け側にライトを装着して、ポーチ側のレールをむしり取って強力両面テープを処理、養生させること一晩。



     ヘルメット側面にレールを装着、これで着脱可能なライトを見たい方に向けることができる。





     結果的に、非常に素晴らしかった。 自転車乗りがちょんまげしているのを滑稽に感じたりもしたが、成程合理的で納得させられた。
     但し、コーナーの見たいところ照らされるので「見えない」ストレスはキレイサッパリ解消する、が逆にそこに意識が集中してしまって、対向車への注意が疎かになることにも気がついた。 慌てた。
     ご安全に!



    さて、次は何をしようかな。




20181223
人生七転び八起き


    <青歯は面倒が多い>
     普段使いPCをDELLのG7に更新して少し経った頃、intel のBluetoothがサスペンドからの復帰で「!」になっていたので、念のためドライバ更新をかけた(悪手?)ところ、スルリと更新されて…、デバイスごと消えてしまった。
     USBデバイスのセクションには「!」付きの不明デバイスが代わりに出現していたので、なんかおかしいことになってるな、と頭が痛い。
     とりあえず消して、再起動してもUSBで復活する。
     試行錯誤の末、MicrosoftのBluetooth Device(RFCOMM Protocol TDI)をデバイスドライバに押し込んで、再起動をかけると、USBセクションからネットワークアダプタに移って、Bluetoothセクションも復活して、一見復旧したっぽい?
     後日、Intelのドライバ更新自動診断ツールで更新ドライバを推奨されたので、おいおい入れ替えよう…。



    <老眼のせいかも…>
     NEX-5Tの焦点再々調整で3回目の分解をしたところ…、またしてもいろいろと壊してしまった。
     背面液晶が点灯しない、HDMI出力してみたらSDカードも認識できてない、ということで、先に壊してしまったNEX-5よりも本格的に壊してしまった模様。
     いい機会なので、10年続いたNEX時代に区切りをつけて、今後の機材構成や運用方法について見直す時期が来た、と考えることにする。
     か、悲しくなんかないんだからね!



    <次元削減は教師無し学習の夢を見るか>
     機械学習の技術を業務に活かそうとすると、なんだかんだでデータサイエンティスト的なスキルとアウトプットが必要となることが分かってきた今日この頃。
     この際、今更ではあるが次元削減が割と便利に使えることに気づいた。
     とは言え、古典的なPCA(主成分分析)では太刀打ちできないデータを扱っているので、より強力なt-SNEがやべーよ重宝だよ、な感じなのですけど、なにぶん処理速度が遅い。
     仕方ないのでPCAである程度まで次元削減してからt-SNEをかけるといった、ホントにこんなことやっていいのかな、という使い方をすることもまま。
     そこで、またしても今更であるが、t-SNEの高速実装Multicore-TSNEが有用すぎると知って、お宝ですよ。
     だがしかし、二次元専用なのが惜しい、惜しすぎる。 せめてt-SNEと同様に三次元にまで対応していて欲しかった。
     そんな折、重ね重ねの今更であるが、より改良された次元削減手法Uniform Manifold Approximation and Projection (UMAP) の存在を知って、即導入ですよ。 pip一発で楽勝、素晴らしい。 但し、マルチコア・HT対応のCPUだと、Multicore-TSNEの方が圧倒的に早いですね。 使用環境やデータを吟味して使い分けることが必要そうです。
     で、このUMAPのインストールですが、環境によってはうまくいかないと気づきました。 具体的には、Windows上にAnacondaで構築したPythonへのインストールでインストール失敗の問題が生じるようです。
     失敗の原因は、UMAPが使用する新しいバージョンのnumbaが使用するllvmliteの更新をpipが失敗してしまうことで、これについては「conda update numba」を終わらせてからインストールすればいいだけなので、大した問題ではない。
     難儀したのは、32bit版Windows(会社支給PCはボロいのだ!)で、インストールが正常終了したのに、「import umap」でエラーが出まくること。 32bit版での運用には問題があると作者がissueで言及してましたので、そこにあったアドバイス「umapソースコードの'parallel=True'を全部消せ!」を実行しましたが、それでもまだエラーが出ます。
     エラーが出ている付近を藪睨み、怪しい所にアタリをつけて、エイヤと試したところ、ビンゴ!でした。…「@numba.njit("f8[:, :, :](i8,i8)")」⇒「@numba.njit()」に書き換えると、見事に32bit版WindowsでもUMAPが使えるようになりました!
     これで、ボロいPCでもUMAPが使えるよ!
     HAPPY!


    見事に外れ値を可視化できたよ




    <Udacity自動運転エンジニアコースのTerm2を終えたのに終えた気がしないのだが何か>
     GWから受講を開始して盆休みにTerm1を終了させたUdacityの自動運転コース(Term1,2,3の三部構成)だが、次のTerm2も11月頭に終了させることができた。
     Term1で要領を掴んできたのと、ドキュメントを作成しなくてよい提出課題が多かったので、Term1の時程は苦労しなかった印象。
     コーディングだけなら新幹線の待ち時間だけで終わってしまった課題もあった位。
     だが、それもこれも開発環境を構築出来てからの話。
     最初の一か月間は、Windows上で開発環境を構築するのにあれこれ試行錯誤している間に終わってしまったナリよ。
     いや、確かに、講義資料に環境構築の手順は書いてあった。 しかし、c++で、WindowsPCを使っているなら、使い慣れたVisualStudioで環境構築しようとするでしょ? 実際、講義で使ったコードは全部VS上でビルドして動作確認できてたし。
     が、提出課題については、(少なくとも私の知見では)unix系OSの環境でないとコンパイルできない!と覚悟を決めるまでに2週間がかかった。
     次の罠は、仮想マシン。 なんとかWindowsPCでunixコンパイルするために、仮想マシンを使うのだが、なんか、すべての罠に引っ掛かった。
     まず最初に、環境変更を最小にできそうなdockerをインストール。 チュートリアルに沿ってやったら、docker toolboxをインストールしていた。 つまりVirtualboxを使った仮想化。これは最小とは言えない。アンインストール。
     次いでdockerをインストール。今度はきちんとHyper-Vで仮想化。所望の環境もDLできて、動作は問題ない。だが、環境内のファイル編集がラインエディタでしかできない&ホストからのファイルコピーもコマンドラインでしかできないといった、軟弱者には辛すぎる仕様だと判明、挫折、アンインストール。
     次はBASH on Windowsを試そう、かと思ったが、これも似たようなものだと気づいて、中断、アンインストール。
     そろそろ選択肢が狭まってきたが、一番無難なVMwareでUbuntuを動作させる。一見うまくいったのだが、ネットワークのポートフォーワーディングのやり方がわからん!悔しいがアンインストール。
     延々と遠回りした結果、virtualboxでUbuntuを動作させることに落ち着いた。ポートフォーワーディングも正常に動作。だが、ubuntu1710だと肝心のGuest Additionsがインストールエラーで、ファイル共有もクリップボード共有もできないので開発環境として成立しない。それ以前にインターネット接続すらできない。しかし、ここで諦めると後がないので、頑張る。
     まず、インターネット接続から。なんと、Hyper-Vの仮想NICが残留してて悪さしてた。これを削除して復旧。やれやれ。
     そしてGuest Additionsの問題は既知のトラブルなんだそうで、インストール前にgcc,make,perlのインストールを行うことで解決。これでクリップボード共有できて、開発環境としてなんとか使える状況に。
     だが翌日、VMが立ち上がらない。仮想ドライブが壊れた?のかと作り直してもダメ。virtualboxを再インストールしてもダメ。ヤバい。しかしあれこれ調べた結果、金融系セキュリティソフトTrusteerRapportをアンインストールすれば正常稼働する、という情報に辿りついて安堵。
     これでやっと…、あれ、インターネットが繋がらない?あ、Windowsも! いい加減にしろ!
     あれこれ試行錯誤して、どうやら回線がおかしい!と睨んでNTTに調査を依頼したら、建物の共用部設備や屋内配線の劣化…だけではなくて、電柱からの引き込み線や電柱の端子ボックスが台風による強風の影響で痛んでいたらしく、地域全体でSNが許容範囲を大幅に下回っている状況だったので、高所作業車が出動、電柱5本を工事する大騒ぎに!(これは俺のせいではない!)

     ひと段落して思ったのは、ほんの2,3年前までは、AI関係のフレームワークがubuntu以外に選択肢が無かったので止む無くubuntuを使っていたが、ここ最近はWindowsでも遜色なく扱えるようになって、いや、むしろ環境構築なら寧ろWindowsの方が楽ちんで安定だったりとなって(但し処理速度はやや低いままっぽい)久しく、ubuntuの取り扱いや連携のアレコレとはすっかりご無沙汰だったことで、やらんでいい面倒をすべてやらかしてしまった感。

     慣性からくる慣れや効率・好みで環境に固執せず、柔軟に対応する必要性を痛感したナリよ。


    引き続きTerm3を受講中で、最初の提出課題「経路生成」をクリアしたところ



    <冬季でもキャンプツーリングできますか>
     この度、21年半乗り続けて流石にガタがきて安心して乗れなくなってきたR1100GSを引退させ、トリシティ155に移行した。

     へんなフロントサスつながり。

     だが、乗っていると前輪が見えないし、乗り心地も全然フツー。 いや、低速時に安定感があって、旋回しやすい…ような気がしなくもない?という感じか。
     とりあえず、メットインスペースにETCを簡単に取り付けられたので、早速高速でナラシ運転。
     燃費は一般道なら軽く40km/lを超えるが、一般道と高速道路半々だと37km/lというところだった。 ワンタンクで260kmという感じか。
     高速道路での巡行は、余裕がないなりに、ギリギリなんとかなる、といえなくもない、というレベル。 東名高速下りだと80km/h巡行、上りで90km/h巡行、頑張りに頑張って最高速113km/hなので余程の速度差や余裕時間がない限り追い越しは無理プー。 この際、燃費は30km台前半まで低下するので、ずっと高速だと航続距離は200kmちょっとで2時間毎の給油が必要という計算になる。
     なのに、エンプティが点灯したら40kmも走れないので、SAの長い区間は恐怖しかない。
     また、当然ながらGSと比較すればてんて非力で加速する楽しさは皆無、後輪のばね下荷重過大で乗り心地も悪い、ミラーが遠くて小さくて後方視認性劣悪、あれだけ大きなフロントカウルなのに足元は風を巻き込んで冷気が足首から侵入、キャリアは小さく、メットインスペースも極小、なにより給油口がシート下な上にタンクも小さくて、ツーリング用途を全力で拒絶するような仕様。 こりゃ、たまらん。
     しかるに、初期改善として給油できるようシート開閉可能な大型キャリアを付けた

    スライドするのだ!

     あと、前面からの風が酷いな、これ。
     丁度胸元に直撃するので、上半身が後ろに持っていかれるだけでなく、巡行時には寒いし、常に顎部からヘルメットの中を強風が通過する。 夏場はいいかもしれないけど、冬場は完全にNGだろ、こんなん。
     ってことで、とりあえずざっと調べた範囲でいちばんデカかったGIVIのロングスクリーンを装着した。 

     そして、スクーターなら恥ずかしくないもん! というわけでもないが、冬場の快適性向上のためラフロのハンドルカバーを購入。 この先寒そうだな、というPAで5分とかからずに、いい感じに装着できた。 3℃の一般道なら夏グローブで余裕(但し手首はスースーする)だし、高速道路でも特に冷気が気になることはなかった。 効果絶大すぎる。

    20年前の柔らかくて使いやすいBMW純正防寒グローブ

     あとは、20年以上のGS経験や免許取得以来染みついたMTなどの癖がいろいろと危なくて、ヒヤヒヤしてる。
     まず、方向指示器が左グリップにしかないので、右折時に慌てて、右左折後の指示器キャンセルでも慌てる。
     左レバーが後輪ブレーキなのはクラッチと間違えがちで、センタースタンドを下すときにはバランスを崩し、走行からの停車時にはカックンしてバランスを崩す。
     クラッチ調整ができないので、徐行時は速度調整が難しいし、信号待ちなどでアイドリングが不安定なときのレーシングができない。
     シートは結構固めで長距離では痛くなりそう。 高さはベタ足で膝が曲がるくらいなので、余程のことがない限りは停車時に不安定になることはなさそう…と思いきや、低すぎるのでセンタースタンドを外すときに腰で支えられなくて不安定に。
     そうそう、センタースタンドをかける時に、エンジンが邪魔になってステップに足をかけにくいのも気になる。 防寒ブーツを履いてたら、きちんと踏めないかもしれない。

     で、これは欠陥!と強く思ったのは、「エコランプ」の眩しさ。アホか、バカかというレベルで光るので、夜間走行では害悪でしかない。特に街灯のない山間部では、ただでさえブラインドコーナーへのヘッドライト配光が乏しいのに、これまた光り輝くハイビームインジケーターと併せてコーナリング中の視界を激しく阻害、怒りすら感じるし、マジに事故に至るよ、こんなんでは。 やむなく、荷物にあった機材に貼ったテープ類を剥がし、エコランプを隠してる。 うーん、カッコ悪い。

     ちなみに、バイク屋に納期を聞きに行ったその足で契約した。
     バイク屋の隣にコンビニがあったので、そこで現金を下ろした。
     さらに住民票もコンビニでプリントアウト。 マイナンバーカードが初めて役に立った日でしたとさ。

     のんびり楽しんでいこう。





20180815
時には振り返りつつ

    <Updateな日々>
     実は希少なお手頃価格の3DCADソフト、Rhinocesrosが久々のver.アップだったので、アップグレード手続きをした。
     かれこれ11年前にver.4を購入し、5年前にver.5、今回でver.6に。
     これまでライセンスの管理でヒヤヒヤさせられてきたが、このバージョンからクラウドライセンスになって、あれ、これでいいじゃん、と少し落ち着いた。
     これまでは、高性能のPCは安定動作のためWEBへ接続しない運用をしてきたのだが、近年は日常使いのPCでも十分な画像処理が可能になってきたので、クラウドライセンスのメリットとやらがようやく解ってきた、というところか。

     Updateと言えば、半年毎の恒例となったOSアップデートも、今回でもう10回目ぐらい?
     手元のWindows10PCは3台、会社で3台やってるので、合計すると少なくとも60回はやってる計算になる。 クラッシュ復旧作業も含めれば70回近い? すっかり慣れたもんだぜ…、なんて安心してたら、今回はAlienware17R3がアップデート後にKillerE2400のデバイスが「!」になって有線接続が不安定〜できなくなった。 Oh....
     デバイスマネージャからKillerのプロパティ>ドライバの更新>コンピューターを参照してドライバーソフトウェアを検索>コンピューター上の利用可能なドライバの一覧から選択 で ドライバをMicrosoftからRivet Networksに変更したら「!」が消えた
    その後再起動すると不安定に戻ったので
    Dellの配布してるKillerE2400ドライバのインストーラーで一旦レジストリをクリアして、再度インストールすると安定化するみたい?
     いや、ダメだった。
     仕方ないのでUSBのネットワークアダプタを常設することで対応した。 なんか切ない。
     一方で、昔から日常的に多用してきたアプリの一つである「Flexible Renamer」が安定して動作するようになったのは有難い。 ここ数か月、ハングアップすること多数で、いよいよ代わりのアプリを探さないといけないのか?、と覚悟を決めつつあったのだが、OS更新してから数週間後に安定してやれやれ。 どうやら症状がRamdisk上のファイルを操作するときだけの不具合だったので、OSアップデートでRamdisk関係の処理で何か変更があったのかな? 善き哉。
     だがしかし、このOSのアップデート後でExcelが突然不安定になった。
     このExcel、バージョンはOffice XPだから17年前のアプリで、下手すると16bitのコードも交じってるんじゃないかレベルの骨董品。 よくもまぁ今日まで使ってきたもんだ。 使っているデータも、古い奴はLotus1-2-3で最初に作成した家計簿を引き継いで今日の今日まで更新し続けていたりする、ってレベル。 今までは超安定していたので、更新するという発想がそもそも無かったが、流石に更新してもよかろう、って気になった。
     では、さてさて、最新版のExcelは…、所有できるバージョンは2016版が最新なのね。 OFIICE ONLINEのPowerPointが割と使えたのでこの機会にEXCELも…と思ったら、ONLINE版EXCELは数式のコピペができなかったり、グラフの領域指定が限定されてたり、グラフのプロパティが無かったりで、アカン、これは使えない。 まぁ、Excelなら向こう10年以上は使える?と思えば誤差みたいもんなので、2016版をAmazonで購入…したら、MSのサイトに飛ばされて、そこでインストーラーをDL・実行。 なんか戸惑うが、動いてしまえば、うむ、快適!
    (あれ? Amazonで示されたプロダクトキーと、MSのサイトで表示されるプロダクトキーが食い違ってるけど、これ、いいのか?)

     そうこうしている間に、またしても普段使いPCが不安定になってきた。
     再起動直後でもアプリの起動に数十秒かかるとか、ヤバげな感じ。 CPUはi7-4785Tで速度は申し分ないし超静音でコンパクトPCながら4台のSSDが搭載できて16GBメモリで満足してたけど、まぁ、毎日使用してきた4年モノということもあって、BIOSの更新も無くなっててセキュリティに不安もあるし、時折起動に失敗するからいろいろとガタがきている感じだし、あと、eGPUが搭載されていないのでAI計算には無力だったりと足りない部分も見えてきたので、そろそろ更新の機会なのかな、ということで、いろいろな選択肢を総合的に検討した結果、普段使いPCもゲーミングPCで新調してみることにした。
     Alienwareなど各社既存機種を検討、普段使い用にある程度地味目な外装でUSキーボードが搭載できて、将来的な換装を念頭に2.5inchHDDも併設されてる機種ということで、DELLのG7(7588)を選定。 6コアで1060搭載ながらもお手頃価格の高コスパ構成。
     納期が10日間とあって、1か月かかったAlienwareと比較して安堵したのも束の間、僅か一週間で届いて、すごーい。
     早速開封・初起動・毎度よくわからんMSアカウントの同期中に、キーボードのイルミネーションが消えてしまい、早速不具合か?!と焦る。 が、Fnキーのキーボードショートカットで制御できると気付くまで焦った。 が、ファンクションキーがデフォルトでメディアコントロールに割り当てられてて、非常に使いづらい。 そういえば、XPSもそうだったが、あの時はBIOSで再設定したような気がするのでメニューを探すも見つからないので延々焦るが、実はこれもFnキーで制御できて、納得できない感が残りつつも安堵。
     パテーションを切って、自宅LANのワークグループに参加させ、IP固定して常用PCから常用環境を転送、1803にアップデートして、BIOSやドライバ類を更新、RAMDISKを設定して…、と、ここでネットワークアダプタを見失った。 この症状、Alienwareでも発生してて、寿命なのかな、と諦めていたのだが、どうやら1803にRAMDISKの組み合わせで発生する不具合なのか、と原因特定。 かれこれ30年近くRAMDISKのお世話になってきて、昨今も活用しまくりで、今更RAMDISKがない環境は心許なすぎるので、なんとかしないといけない。 ここ数年は、速度も速く使い勝手のいいRAMDAを愛用してきた。 他の選択肢を検討するも、無料・有料を問わず、置き換え可能なものは見つけることができなかった。 辛うじて、ASUSが提供するROG RAMDISKが運用上の工夫込でなんとかなりそうで、ネットワークアダプタ(KillerE2500)との相性問題も発生せず、当面はこれでいくことに。
     そうこうしている間に、またしてもネットワークが不安定に。 隣のPCが見えなくなったり、繋がらなくなったりで、これは1803の仕様変更で生じたものであるらしく、ググってみると同様の悲鳴があちこちに。 隣のPC名を小文字にすると繋がるのだが、ショートカットが勝手に書き換わって大文字に戻される挙動が執拗に続く一方、名前解決のサービスが停止してたりているので、もう面倒だと先に諦めてIP指定で接続していたリモートデスクトップと同様に、ファイル共有もIP指定で接続して済ますことにしたら、今度はセキュリティアラートのダイアログが頻出して閉口。 うーん、MSとしては昔ながらの運用は止めさせて、新しいニアネットワークを使わせたい、ってことなんだろうか。 (後日追記:しばらくしたら、PC名でも接続できるようになった。ホントに単なる不具合だったのか?)

     気を取り直して恒例のベンチ。 久しくなかった更新=倍速化!で素直に嬉しい。
     また、GPGPUの処理速度も、実測で1.4TFlops、これはGTX980Mから三割以上のUP。


     普段使い用の低消費電力PCなのに、処理速度だけなら我が家最速になってしまった。
     でも、ストレージはSATA3のSSDでそこそこ速度だし、メモリもいまどき16GBと控え目、画面もHDと謙虚なので、本気のデータ処理にはちょっと心許ない。 まぁ、普段使いにはこれくらいが丁度よいかな、って気もする。 ただ、キータッチのフィーリングはしょぼかった。ブラインドタッチできない…。あと、バックライトがすぐにタイムアウトで消えてしまうのも使い勝手悪い。(後日追記:BIOSで常時点灯を設定できた!) 廃熱もそれほど効率よい感じではないけど、最近はこんなものなのかな?



    これまた恒例のディスプレイ色度をチェック…かーっ、典型的な安物液晶だな、これ! (まぁ、外付けディスプレイを使うから関係ないけど!)

     とりあえず、ここ3年間のAlienware17でいい感じに運用できていたやりかたを踏襲して、新調したディスプレイアーム(お買い得!)ノート用トレイを組み合わせて空中配置。 廃熱最強だし、なにより、ノートPCでも高さ調整できるのは便利だねー。


    まだ仮配置なので空中配線が汚い! モニタ横にVESA取り付けPCホルダの小物置き+個別ON/OFFのHUB設置は存外に便利だった

     さて、あとは運用でコツコツ改善していくことにしよう。 ちょいワク。



    <地上の星>
     一年前にNEX-5Tの赤外カットフィルタ除去改造をしたのだけど、実はその後撮影していなかった。
     で、このGW前の新月の晩、天気予報の「大雨のち快晴」を信じて一年ぶりの撮影遠征をしてきたわけで、ようやく新生NEX-5T(赤外)のファーストライトである。
     んが、背面ディスプレイでも分かるレベルでピントがおかしい。
     中央でピントを合わせると隅がピンボケになってる。

     …心当たりがある。
     そういえば、改造した後に、幾つかの部品が余っていた。今から思い返してみれば、あれは多分、撮像素子の位置調整用シムだった。

     そんなわけで、1年ぶりにNEX-5Tを分解して、組みなおした。



    ミラーボックス(ミラーないけど)開口の上下にある真鍮製の薄板

     組み立てる途中、無くさないよう&組み間違えないよう、きちんと整理していた筈のネジが盛大に散らばって「なんでじゃー!」となった。
     その原因は、外したロジックボードにぶら下がっていたスピーカー(磁石入り)で、沢山のネジを吸着していることに気づかずに組み立て始めたのだった。



     問題のスピーカーは画面中央やや右にある丸い部品

     結局、ネジが3本余ってしまった。 ま、いいか。

     さて、これで片ピンは解消された筈…だけど、ちょっと自信がない。
     実際に星景を撮れば確実に確認できるけど、今は真昼間。
     なんとか確認する方法は無いかな〜、と思案した結果、手元にゴロゴロあった「適度に暗いLED照明を備えたUSBバッテリー」にピンホール付きのカバーをつけて疑似点光源として壁に配置し、カメラを壁に水平垂直で撮ってみた。



    光源は中央と四隅の5か所、レンズは絞り開放と3絞りぐらいでお試し

     うーん、微妙? よくわからん。 とりあえず、酷かった状況はそれなりに改善された模様。
     ちなみに、この時のピンホール径1mm&壁までの距離3.2m≒視直径1分≒金星の最大視直径/木星の最大視直径より2割大きいぐらい? 意外と大きかった。 点光源って難しいな。

     あと、4年前に改造したNEX-5も同様に部品を組み忘れたままだったので、この機会に直しておこうとバラしたのだが、NEX-5Tと違ってネジはバラバラ、部品も多いしで、まるで出来の悪いパズルみたいな組み立て性に難儀しつつ、なんとか復旧〜電源投入〜再起動を確認したところで、またしても組み込み漏れした部品が残ってた〜再度分解を2回繰り返して、今度こそようやく完了…、あれ、ディスプレイが映らない…。
     この後、(この日だけで、5,6台の赤外改造するくらいの作業量を費やして)慎重に確認したところ、フレキケーブルの一部を断線させてしまっていたことが分かった。何度も何度もバラした結果なんだろう、トホホ。
     とは言え、星景撮影を再開して以来10年近く使ってきたロートルで、アフリカではマゼラン星雲を撮り、アラスカでオーロラを撮ってきた思い出深いカメラであり、後継機購入で現役引退後は低温試験で酷使して、赤外改造で現役復帰させて更に酷使させてきたわけで、これはもう大往生!ということにしておきたい。 お疲れさまでした。 感謝。
     まぁ、ディスプレイが映らないだけで撮影はできるし、ディスプレイ出力はHDMI経由で観えるので、将来的には動画コンポジット用の部品として、再び蘇るような気がする。(?) それまで、しばしの休息を。
     (こんなのが、ガラクタが増えていくという典型例なんだな)


    <備忘録>
     新しくUSBバッテリを二つ購入したので、何回かナラシ充放電をした後で、恒例の容量チェック。


    コンパクトで好ましいデザインだったが、実容量はカタログ値の75%か…


    上記と同じスペックだけど半額でデザインはイマイチ、でも実容量はカタログ値の90%

     ふむ、ふむ。 なるほど。
     あと、これを計測する用に、USB電流計を幾つか買い足した。
     これらを直列に繋いで、USB電流計による電圧降下がどんなもんかを確認してみた。

    5.21V→5.08V→4.97V→4.70V→4.52V
    0,77A→0.70A→0.70A→0.61A→0.73A:av0.70A

     E=IRとすると、ΔEからΔR=0.19、0.16、0.24、0.26、Σ=0.85Ω? え、そんなもんなの?



    <「むりー!」>
     MOOCと聞いて、「え、シンセサイザー?」と素っ頓狂な勘違いをしたのが、ついこの間のことだったりする今日この頃。
     そして、そのMOOC:無料のオンライン講座があれば、塾や専門学校なんてマジいらないね、って時代になりそうだと本気で思う今日この頃でもありまする。 有名どころはどこも教材が素晴らしすぎるからなぁ。
     で、今年のGWから自動運転技術のレジェンドが立ち上げたMOOC大手:Udacityの自動運転コース(有料)を受講していたのだが…、社会人たるもの平日は時間がとれないので週末に頑張るしかない訳で、しかし(金さえ払えばだけど)本気の締め切りがある訳ではないものに対して頑張り続けることは難しい訳で、ズルズルと遅れが積み重なってしまい、この盆休みを使ってなんとか挽回…できる訳もなく(既に一か月遅れなので、)、まぁ、なんとかかんとかでTerm1(コンピュータービジョンとマシンラーニング)を修了できた。
     英語の教材は、Googleの同時通訳パワーを使うことでなんとかなるとしても、提出課題をこなすには数段階上の覚悟が必要で、殆ど穴埋め問題だった課題1を舐めプで済ませた私は、唐突にややこしくなった課題2、輪をかけて複雑になった課題3、処理過程が伸びまくって迷子になりそうな課題4、迷子になるまいと予防線を張っていたら曖昧な地図しか貰えない課題5と、回を重ねる毎に難易度が上がっていくので、ダラダラしてたら時間がいくらあっても足りない!と焦らされた。 アタマを使って段取りを整えて取り組むことが必要ですね。
     課題のプログラムを作っておしまいでなく、そのドキュメントも(英語で)作成して提出しなくてはならないのが、これまた難儀。 とは言えども、プレゼン書類作成の能力こそが社会人になって(否応なく)一番伸びたものであり、楽して・効率的に・簡潔に示すノウハウも工夫の為所。
     提出した課題に不備があればリジェクトされて再提出が求められるので、公開されている採点基準を凝視して、各項目をギリギリでクリアできるように作り込むのも、まぁ、ゲームっぽい楽しみ方かな、とか思ったり。

     これ↓は、提出課題の一つ、車両検出の処理過程(の途中)の一例。


     そこそこ頑張って機械学習させた筈なのに盛大に路面を誤検知してるので、かなり重めのLPFをかけて↑なんとか辻妻を合わせたのがこちら↓。



     まだまだ明らかに不備があるが、この辺りが採点基準から逆算した合格レベルだと判断し、作り込みはここで打ち切って提出、まんまと合格。
     この課題をこなすのにかかった時間は、講座の学習と事前準備で6時間ぐらい、コーディングで20数時間、ドキュメント作成とコードの体裁を整えるのに10時間、合計40時間といったところでした。 オンタイムで講座を進めようとするなら、ひと月あたり少なくとも80時間は必要になるわけです。 既にそれなりにPythonが使えていて、画像処理やOpenCVの知見がある方だと自負していたが、先方の示す「週15時間」という締め切りの目安では到底全然間違いなく間に合わないです、はい、「むりー!」

     だがしかし、若い衆ならなんとかなるのではないか、とも思わされた。 至る所に自ら勉強させるための工夫が満載で、間違いなく効率的且つ能動的且つ実践的な勉強になっているし、提出課題につけられるレビューには誉め言葉の雨あられ。 ギスギスした日本企業では滅多なことでは褒められず元気もやる気もなくなりがちな若い衆も、これなら元気もやる気も出て、実力もモリモリUPするのでは? 日本の堅苦しい教材・教育とは雲泥の差で、これがアメリカ流の促成栽培教育コンテンツなのか!と啓蒙されることしきりです。
     あと、この歳になって(恐らくはかなり年下のレビュワーに)褒められまくる機会があるなんて思わなかったですよ。(笑)
     そんで、これって、老後の楽しみにもうってつけなのでは? と気付いてしまった。
     絶対そうだよね、時間は腐る程あるんだから。



    <思い出再生機>
     ふと、昔のMIDIファイルを再生してみた。
     当然、発音しているのはOS標準のソフトシンセ。
     でも、なんかコレジャナイ感が拭えなくてモヤモヤする。
     で、ガラクタ箱からMIDI音源(DTM音源)を発掘、多分15年以上ぶりに再生してみた。
     そのDTM音源、かつて繁栄(?)を極めた後に絶滅したPC周辺機器の一つ。  私は1993/06にSC-55mkII、1996/03にSC-88VL、そして2000/05にSC-8820と短い期間にどんどん買い替え、このSC-8820は手元に残っていた。
     SC-8820はUSB接続なのでシリアルやMIDI端子に変換する手間も不要、バスパワー駆動なのでACアダプタも不要でお手軽セットアップ…、とは流石にいかなかった。20年近い月日は伊達じゃない。
     Windows10ではドライバが自動でインストールされないので、公式の最終ドライバをDLしてアーカーイブを解凍してインストーラーは互換モードを駆使しても実行できない、がセットアップ情報ファイル(.inf)から直接インストール操作は出来たので、やれやれである。
     そしていよいよ、思い出のMIDIデータを再生してみると…、ぶわわわーっ!と当時の記憶が一気に蘇る。 音色だけじゃないんですよね、リバーブとか、インジケータの動きとかが総合して、埋もれていた記憶が溢れ出す。 長期記憶に於いて聴覚記憶は重要と聞いたことがあるが、視覚も連携したこの記憶の奔流は留まることを知らない脳内ナイアガラで、目鼻口から溢れ出しそうです。 涙すらちょちょぎれそう。 …まてまて、まだ20年も経ってないのに、何か錯覚してないか?と戒めるのが必要になるレベル。 あー、動いてよかった!
     いやはや、後生大事に保存しているWindowsXP環境を蔵出しするか、XPの仮想環境を構築することになるのかと、戦慄したぜ。 但し、同様にやって正常にインストールできないPCもあったので、油断はできない。
     とりあえず動いたので一安心しつつも、一抹の不安があったので、ここは視野を広げて他のMIDI再生手段を調べてみると、近年は選択肢が割といろいろあるっぽい。 OS標準ソフトシンセのtmidi再生設定カスタマイズファイルを試してみたところ出来が非常によかった(但し88マップの音源でうまくいかない?)ので、これを活用するのがお手軽ですし、近年の高音質なDACを持っているのであれば下手するとSC-8820みたいな古いDTM音源より高音質かも?
     本家RolandではソフトシンセのVSTプラグインを推奨しているんでしょう。 まぁ、確かに20年以上前の機材のメンテする義理はない中、現在の技術で最善の選択肢を提供したのだという気概は、「ノスタルジアと現代の感性が融合した SOUND Canvas シリーズの集大成。それが SOUND Canvas VA です」という文句からも察することが。 クリアーな音と共にオレンジ色のインジケータで躍るバーグラフの記憶は、「ノスタルジア」という言葉がピッタリだ!と感服させられる。
     そんで、デジタル世代の老後の楽しみを台無しにしてしまう古いメディア再生できない問題の罠は、ホント、いろいろな所で口を開けているのだなぁ、と再認識された次第です。



20180410
不具合が団体でやってきた



    <更新1>
     あるとなにかと便利なHDMIキャプチャユニット、そのはしり?であるMonsterX Live(当時¥14,544)を6年前に買って、ドライバ不要でシンプル運用できることに満足していたのだが、会社備品HD PVR RocketでPCレスでの録画機能があるとより便利なことを気づいたので、それなりに枯れた?単体録画機能のある機種ということでAVT-C878を買ってみた。

    MonsterX Liveと比較すると小さい!

    ・キャプチャ性能自体は同じようなものだが、単体録画もできることで運用の自由度が上がって嬉しい
    ・単体録画とPC録画をSW切り替えするので、汎用ケーブルで接続/電力供給できるのも地味に便利(HD PVR Rocketは専用ケーブルで切り替える)
    ・単体録画機能は画質が11Mbps固定?、入力ソースで画像サイズやfpsも自動切換えなので、場合によっては不足するかも
    ・録画ファイルはmicroSDカードのフォーマットに因らず4GBになると分割されるので、長時間録画時は注意
    ・PCを使っての録画は専用アプリを使ってx.264やGPUなど複数のやり方が選べる(こちらなら画質・ファイルサイズは任意に設定できる&i7なら余裕綽々の低負荷)
    ・汎用ソフトでDirectShow経由のキャプチャもできたけど、WDM経由だとダメっぽい?(DirectShowもなんかの弾みで青が強くなることがある?)
    ・モニタ用ヘッドホン端子はサーノイズがあって惜しい

    …買って2週間後に新型が出た!ガッテム!


    <レンズを買う度に改造するのもアレなので>
     市販品のレンズヒーターを買ってみた。

    サーモグラフは左が内側、右が外側
     1.2A以上も喰う(自作ヒーターの三倍!)だけあって高温部分は50℃以上になってる!
     けど、実は表面からの放熱の方が大きい=無駄に熱が逃げるので、差し引きで丁度いいのかもしれない?
     熱が逃げないように更に断熱するのと、加熱しすぎないように電力供給をインターバルにするとか、運用上の工夫が必要そう。
     あと、全長40cm以上だけど、加熱範囲は25cm→8cm径のレンズまで対応



    <微速度撮影時バッテリー運用改善検討>
     これまでのバッテリー運用方法では、撮影に出かける前の晩から当日出発直前までかけてバッテリーを充電し、撮影〜帰宅後にはそれらを全部放電させて、もう一度満充電にし、さらに20〜50%程度まで放電させて保管してきた。 このやり方で8年前のバッテリーも容量減少がほとんどない(8割以上をキープ)ので、これでいいのだろう。
     が、手間がかかるのは否めないし、唐突に出発しようと思っても対応できない。なにより、バッテリー持続時間(NEX-5で3時間程度?)以上の微速度撮影は原理的にできない。
     対策として、バッテリー二つを突っ込めるアダプターを買ったことがあるが、これまた使い勝手が悪い。
     要は、USBバッテリーから給電できる機種が羨ましいな、と思っていたということだ。
     次善の策として、DC-DCコンバータで昇圧モジュールを自作しようかな、と思いついてから既に10年近くが経ってしまったのだが、そんだけ経てば誰かが作ってくれもするわけで、


    とりあえず二つ買ってみた




    突入電流はそこそこあるっぽい

    表示されているのは0.8Aだが、恐らく実際はここが瞬間的に2A近いのではないだろうか。


    微速度撮影の大半を占めるシャッター開+ディスプレイOFFだとこんな感じ




    単純に電源ONでディプレイ表示されている状態だと0.35Aといったところか




    発売当初に加熱問題があった動画撮影時だが実際はこの程度のようだ




    ジャンプスターターのおまけ機能の5V給電でもOK




    カタログ容量とAC100Vインバータ出力は立派だが、少し不安定のようだ

    Type-C端子は1.5倍の3A出力なので、こちらを利用した方がいいかもしれない?


    さて、α7sはというと体感通りの低消費電力(タイムラプスアプリ撮影中)




    単純に電源ONだとこれくらいで、これならNEXと同等




    アプリ操作中で結構電力を喰っていたようだ




    レンズヒーターに同時給電して大丈夫そう@Anker AstroE7(実測容量20831mAh)

    これなら、単純計算で20時間連続使用できる計算。一晩中撮りっぱなし余裕だね!


    Anker Astro2(実測容量6724mAh)も大丈夫みたい

    こちらは6時間でちょっと心許ない。
    このバッテリーを使うなら、レンズヒーターの方は今まで通り(Anker Astro、実測値4757mAh)の給電が無難かな。



    まとめると
    ・5V出力の仕様が2Aのものならなら問題ない。
    ・たとえ手持ち最大(MP-50000、カタログ容量52800mAh)の巨大バッテリでも、NEXでは時折瞬断して、αでは突入電流に耐えられないのかON/OFFを繰り返す有様。 2A出力は仕様で謳ってないので文句は言えない。
    ・3A以上の出力対応Type-C端子を備えたものが増えるようだし、
    ・Anker 安心

    通常 撮影中(微速度) その他(動画、アプリ) 突入電流
    NEX-5 0.35A 0.28A 0.55A 0.88A
    α7s 0.36A 0.26A 0.47A





    <予兆>
    20年以上使ってきたアイロンのスチーム機能が壊れかけていたので、折角なのでコードレスに買い替えてみたら


    デカかった




    本体はコンパクトだけど、スタンドとカバーが大きいのね




    水タンクが外せる!かっけー!

    こうして永らくお世話になってきた旧アイロンは、燃えるゴミの日にドナドナされていきました。 お疲れさまでした。
    (※横浜市は品目指定でアイロンは燃えるゴミだった)




    ついでに、ハンディ掃除機も買った

    …買って2週間後に新型が出た!ガッテム!




    <前厄>
    ある日、
    手元に使っていない中途半端な容量(1GB〜64GB)MicroSDカードが沢山あることに気づき、Windowsの回復ドライブ用USBメモリなどとして利用しよう、と思い立ち、小型のカードリーダーを注文


    あれ?ちょっと変だ




    うわ、TypeA端子が潰れてる! SDカードも入らなければ、挿すこともできない状況

    不良品なのは間違いないけど、文句をつけたり交換手続きとか面倒すぎる…。
    とりあえず、潰れた端子部分を精密ドライバでこじって広げてみたら…、おお、使えるようになった。
    …ま、これでいっか。(よくない)



    <本厄>
     そうこうしている↑うちに、もうすぐ4年の普段使いPC(i7-4785T、OS再インストールして約半年)が再起動病に罹患した。
     起動に随分時間がかかるのはまだいい(よくない)として、シャットダウン時にシャットダウンに失敗して数回再起動を繰り返し〜ロールバックしてからようやくシャットダウンが完了、という症状。 ギリギリアウトだけど使えないことはない状況だが、パンクしてリムで走っているような自転車操業という感じ。
     OS再インストールしてからの半年間でこの体たらくというのはちょっとアレだが、VisualStudio2017やUnityみたいな超重量級の開発環境を何度も何度も何度も何度もインストール/アンインストールしたりしてきたこともあったし、まぁ、やむを得ないかな、と思うことにした。
     例のCPU脆弱性対策アップデート以降の不具合がこんな形で顕在化した、というかとどめになったという解釈でいいのかな。
     半年前の再インストールでは、3年ぶりの再インストールだったので、その頃には久しく忘れていたアレコレで随分と苦労した&時間がかかってしまった反省もあり、忘れないうちに作業手順やポイントの備忘録を残しておいたのだが、早くもそれが役に立つこととなった、なってしまった。(随分助かった!)
     余計な手間にはなったけど、結果的にはキレイな環境で快適性はUPしたからいいとしよう




    <真の本厄>
     これ↑から3週間後、今度は作業用PC(i7-6700HQ+GTX980M、3年間上書きアップデート中)も再起動病に感染した。
     こちらは症状がちょっと違って、起動時にエラーを吐いて無限再起動のタイプ。
     ただ、こちらのPCにはスタンドアロンライセンスの有償ソフト(Rhinocesos、Matlab、AfterEffects、Vue・・・)がいくつも入っているので、いきなり壊れると割とシャレにならない!
     幸いにして、あれこれいじっている弾みでなんとか起動できたタイミングがあったので、慌ててそういったソフトのライセンスを解除・退避して、それっきり起動できなくなった。 ホントにホントにギリギリだったな。
     いやな汗をかいたけどひとまず安堵、今度は復旧作業。
     丁度NVMeのSSDも値下がりしてきたし、この機会に増設しようとポチって迎えた週末は、一か月ぶりの復旧大会です。
     この三年間でUbuntuを入れたりしてあちこちが汚くなったいた起動ドライブ周辺がスッキリキレイになって、初の4Kディスプレイに戸惑ってポンコツな運用になっていたところなども見直して、今回特に慌てたソフトウェアライセンスに関しても別PCにライセンス管理サーバーを立てる・WEB管理にするなどの対策を行い、あとWindows7になって以降は今回みたいな起動できなくなる不具合から縁遠かった油断もあって久しくサボってきたシステムバックアップについて調べて、「回復ドライブ」なるものを普段使いと作業PC両方に作っておいた。これでヒト安心かな。
     SSDのWriteが倍速になっていたので作業自体は快適だったけど、M.2SSD固定ネジがついてないので増設できなかった(交換になった)ので、作業は完了しなかった。 ま、急ぐことでもないので、来週以降も週末にコツコツやっていこう。



    <本厄再び>
     その翌日の朝、普段使いPCを起動したらログオンできなくなっていた。
     キーボードとマウス両方が認識されていない。
     正確に言うと、起動直後は認識されている。(キーボードのランプが点灯する) ログオン前画面が出る付近で接続が解除(ランプが消灯)されていて、そこでケーブルを抜き差しすると一瞬認識して、すぐに解除されている。 あとBIOS画面は操作できる。 キーボードやPC側USB周辺のハードウェア的故障ではなく、OS側のソフトウェア的な不具合だろう。
     ログオンできないけど、ネットワークからは共有フォルダやドライブがきちんと見えていて、データファイルの喪失もなく、問題になっているUSB接続周辺以外の機能は支障なく動いているようだ。 つまり、なんとか一瞬でもログオンできてUSBドライバ周辺を補修すれば復旧できる筈。
     このPCにライセンスサーバーを入れてあるので、こんなところで突然死されたらシャレにならない、焦るのなんの。なんとかしなきゃ。
     だが、このPCはPS/2コネクタも無ければBluetoothも無く、USB以外でキーボードを繋ぐ手段が無い。
     幸いにして、手元のPCは全てWindowsPro版なので、リモートデスクトップが使える!のに、昨日の今日だったのでリモートデスクトップの設定を済ませていなかった! これさえあればなんとかできるのに、痛恨すぎる! 真っ先にやるべきだった…。
     仕方ない、電源OFF2回連続&電源ONで起動するWindowsトラブルシューティングを使って、修復を試すも、まったく効果なし。
     再度電源OFF2回連続&電源ONからセーフモード起動や、別のオプションを何度か試すが、いずれも効果なし。
     途中、何故か1か月前まで使っていたシステムが立ち上がったが、これでは意味がない。 念のためにそこでディスクの管理を見たら、新しくインストールしたディスクが正しく識別されていなかったので、慌てて電源OFF〜しねえ!(再起動病末期の再現)ので、強制OFF&余計なディスクを外す。
     つまり、つい先日作成した回復ドライブの出番がもう来たということのか!と起動するが、まるっきり役に立つメニューが無い! …よくよく調べると、回復ドライブ単体ではバックアップの用をなさない、単なる起動ディスクであって、バックアップの本体である「システムイメージの作成」を別途作っておく必要があったのだと分かった。わかんないよ!
     やむを得ない、ライセンスサーバーは諦めて、ここはもう復元ポイントを使ったロールバックで戻ろう…と覚悟を決め、トラブルシューティングを読み進むと…、1か月前とつい先ほどの復元ポイントしか選べない? そう、先ほど偶発的に起動した一か月前に見限った瀕死システムの復元ポイントに入れ替わってしまっていたのだ。 絶句。
     文字通り、八方塞がりである。
     これはもう再インストール(しかもタスクスケジューラーの関係上、Win8のインストール〜Win10のインストールという二度手間)なのかと半分以上諦めつつ、トラブルシューティングのメニューをくまなく目をしていると、「前のOSに戻す」という項目があった。 そうか、手続き的には1か月前にWin8から上書きしたわけなので、まだ元に戻すオプションが残っているのか。 というか、この日に突然USBが死んだのって、この上書き1か月目で古いOS消去機能の誤作動が原因なんじゃないか…、的なことを考えたりしている目で再度トラブルシューティングメニューを眺めると、「初期状態に戻す」は「Windows10の初期状態に戻す」と理解できるわけで、それはこの場合二回必要なOSインストールを一回に減らすことができるという意味であり、更に個人追加したファイルは残してくれる(OS上の設定はリセットされる)選択肢が残されている、と分かった。 このトラブルシューティングは敵ばっかの掃きだめだと思っていたけど、鶴がいた!
     で、早速そのメニューを使って初期状態に戻してみると、まさにインストール直後のきっちり動くWin10に、カスタマイズで作ったショートカット類やフォルダがそのまま残されている状態で、しかもWin8をインストールした直後に変更した最新版のドライバやシステムフォルダ設定等も維持されていて、復旧させる手間は大いに削減できた。 その後に控えるVisualStudioの再インストールの方が遥かに時間をとったけど、かなり時間を短縮できたと、満足度高いです。(まぁ、錯覚なんだけど)

     ここ最近、ウイルスや天災を想定したデータバックアップしかしていなかったのだが、今回のような事態では、データの喪失は皆無だったものの、システム保守にはまったく寄与できていなかったなぁ、と反省。
     流石に懲りたので、復旧してすぐに回復ドライブを作成、システムイメージも作成、復元ポイントも作成、そしてリモートデスクトップを設定。
     この際、インストール直後にシステム最適化ソフトによって、復元ポイントのディスク容量が1/4にまで減らされていることに気づいて、システムドライブの容量には余裕があるのでこれを増やしておいた。 今回みたいなことを経験しないと、危険に気づかないよね。

     WinXPの頃はOS運用性に安定を欠いていたけど、それ以上にハードの更新が早かったのシステム喪失の機会は結構あったけどダメージはそれほど大きくなかったというか、印象に残らなかったというか、すぐに新しいハードにすることでどんどん安定化していったという印象が残っている。 一方、ここ最近はOSが安定化したのでシステム喪失の機会も警戒も減っていて、おまけに4年前のCPUでも快適に運用できる実力があることから結果的に古い構成のハードでの運用が増えてきて、潜在的リスクが増していたのかもしれないです、少なくとも私の運用方法では。 Androidなどクラウドで保守・再構築できるシステムってのは、おせっかいで面倒だと思っていたのだけど、実はありがたいのですね、モダンなのですね、と今更理解できましたとさ。



    そろそろいろいろ更新していかないとな。


20171231
未来がやってきた

     ちなみに『VR元年』は2016年だったそうです。
     アチャー。




    <意思決定できない人は>
     ふと、その昔(2000年頃?)に流行った?AHPを使って、エロマンガの順位付けしようと思い立った。(なんでだろう?)
     が、その頃に作ったEXCELマクロの使い方をすっかり忘れていたので、今ならWEB上に色々な実装があるだろうと探した結果、適度に扱いやすい手頃な実装としてこちらを使ってみることにした。
     だがしかし、私のEXCELは依然としてOffice XP(2002)である。
     .XLSMファイルを読み込むことができない。 どうやらこのファイル形式は2007以降の対応ということだ。
     だが、MSは互換機能パックをインストールすることで、旧製品でも使えるようにできるようにしている、と分かった。 早速インストールする、が、やっぱりダメだった。
     ドキュメントを読むと、どうやらインストール前にOffice XP SP3を適用する必要があるらしい。 が、既にサポート終了している製品のSPもまた配布終了していた。 インターネットアーカイブからなら拾えるが、適用するとプログレッシブバーが完了寸前から逆回転してエラー終了となる。 セキュリティの都合なのかな? お手上げ。
     そこで、ふと、4年前に買った8インチのタブレットPCに、OFFICEが付属していたことを思い出した。 速攻で確認したところOFFICE 2013である。一度も起動したことがなかったが、これを使うことで難なく新しい形式のEXCELファイルも読み込み〜旧型式で吐き出す変換ができた。 うん、こっちの方が賢いやり方だ。
     ま、餅は餅屋、畳は新しい方がいい、ってことだと、再認識。(重要)




    <Passport please?>
     手持ちのパスポートの有効期限が残り1か月を切っていたことに気が付いて、更新してきた。


     おや? 新しいパスポートが少しスマートに見えるぞ?
     よく見ると、綴じ方が変更されていて、背の部分が平らになってました。


     変わらないように見えて、毎回少しずつ変化・改善されているのが面白い。
     そしてパスポートセンターの窓口で待たされている間に、ビデオ再生されていた海外で犯罪被害に遭う若者への啓蒙ビデオや、自動化ゲートの使い方紹介ビデオが、初心に返らされて、面白かった。
     気を付けないとな。




    <更新:ダメ人間製造機>
     3年前に導入したゴロ寝タブレットスタンドは、絶賛好評毎晩稼働中なのだが、これが意外と角度調整しにくいとか、可動範囲が小さいとか、重いとか、なんかカッコ悪い(!)とかが気になってきたので、調整しやすく、可動範囲が大きく、軽く、小洒落た(?)スタンドに入れ替えてみた。


     可動範囲が広く、各関節トルクを細かく・独立して調整できるのが、使い勝手に直結です。
     その反面、剛性は低下する。 タッチパネルのタブレットは操作時にグラグラ揺れないためにスタンドに剛性が必要なのだろうが、この3年以上経ったタブレットは既にタッチパネルが故障していて、Bluetoothマウスで操作しているので、スタンドに剛性はまったく不要な状況。 従って、こんなアングルで使っても快適。
     これで、ダメ人間化が加速する。




    <バッテリー運用の高度化検討>
     先日長年使ってきた汎用バッテリ逝去なされた折に、機能的に代替可能なバッテリとしてAC100Vインバータを内蔵したものがタイムセールで表示されて、実にタイムリーである、とポチった。


     ほぼ同容量のUSB給電専用バッテリーと比較すると、その図体はかなりデカいと言わざるを得ないが、AC給電の安心感は捨てがたいものがある。(但し矩形波AC出力なので、動かない家電が結構あった。事前確認が不可欠ですね)
     そして同じタイミングで、このバッテリーが備えない5V以外のDC給電機能を補えるDC12V出力を備えたものもタイムセールで表示されて、うむ、合理的だとポチってしまった。


     やはり同容量のUSB給電専用バッテリーと比べると、かなデカい上に効率も悪いと言わざるを得ない。 しかし、汎用性の高いDC出力に加えて、スターター補助機能は魅力的である。
     それにしても、この一連のAmazon AIによるレコメンデーション力は、すごいと言わざるを得ない。 感心することしきりである。
     …が、よくよく考えたらこれらを足したものより大容量の汎用バッテリを2年前から持っていたのだ。
     これはもう、物忘れが酷すぎると言わざるを得ない。 トホホなことである。




    <備忘録:dlibのWindowsインストール>
     やり方を忘れていたのでGoogle先生に訊いたら、親切なページを教えて貰った。
     要約するとは、事前準備として以下のインストールが必要で、
    ----
    ・VisualStudio:dlibもそうだがその前にboostのビルドで呼ばれる
    ・cmake:いろんなところで呼ばれる
    ・boost:dlibのビルドで呼ばれるのでその前にビルド&ヘッダとlibの環境変数を設定
    ・python:dlibのビルドスクリプトで使う
    ----
    ×64bit環境でエラーを吐くdlib\image_saver\save_jpeg.cpp を手直しして、「python setup.py install」でビルド開始
    「pip install dlib」

    C++用のライブラリ生成はこちらを参考に、
    ----
    ・「build」フォルダを掘って
    ・そこで「cmake -G "Visual Studio 15 2017" ..」
    ・隣にインストール済みのOpenCVを見つけてくれない…
    ・そんで「cmake-gui.exe .」
    ・OpenCVのビルドフォルダを指定して、ついでにAVXとSSE4にチェック、configure、Generate
    ・Visual Studioで生成されたslnをビルド
    →失敗! このやり方、VisualStudio2017ではダメらしい
    ----

    なので、普通にcmakeしたslnをビルドら正常終了した! あっさりdlib.libできてる! がーん!(脱力)
    ※ただ、ここから上記記事にあるようにJPEGサポートが無効になっていたので、ソースコードを修正してから再度ビルドするひと手間、さらにPNGも無効だったのでこちらも同様に修正と再ビルドのふた手間が必要

    Visual Studio 2013の環境ではサポート外ではねられてしまい、ビルドできなかった! ガーン!




    <Dell Visorが届いた>
     ある日、賢いAmazonAIが「VR用HMD買いませんか?残り二つですよ?明日届きますよ?」(意訳)と勧めてきたので、よかろう、とポチった。 ホントに翌日届いた。
     接続しようとしたら、いきなりPC起動が失敗して、システムの復旧に手間取った。 そういえば、前日にWindowsMR開発環境を整えようとUnity2017やらVisualStudio2017のインストールや設定変更を一気にしたせいか? ぐぬぬ
     なんとか復旧して、HMDのHDMIとUSBケーブル接続、「Mixed Realityデバイス/DELL VISOR VR118」と「ユニバーサルシリアルバスデバイス/HoloLens Sensors」を無事認識。
     ポータルが勝手に起動して、ネットワーク接続要求〜ファームウェアが更新された。
     引き続き、左右のコントローラを接続する。 付属電池を入れて、ペアリング(電池ケース外したまま)すると、点滅やら振動やらにぎやか。 加速度センサも入ってるようで、「ヒューマンインターフェイスデバイス/Motion Controller」が認識される。 ただ、DirectXのジョイスティック互換ではなさそう。(認識しなかった)自作アプリとの連動は面倒そうだな。 あと、しばらく放置すると点滅して、自動OFFに。よくできてるな。
     そしてMR環境設定は、とりあえず動き回らない設定で初期位置を設定。
     そこから「ダウンロードが完了するまでこのままお待ちください」と、10Mbpsでなにやらダウンロードしているが、26〜30%はちっとも進まない(20分)、突然95%になって画面遷移、再びぐるぐる…「完了しました」表示起動、VR開始! ちょっと感動。


    ポータルでデスクトップを動かせたので、定番の合わせ鏡

     この後、昔に訪問した場所のVRコンテンツを幾つか観た(マチュピチュ、砂漠@バイク、ダイビングwithイルカ)ところ、過去の体験が鮮明に思い出されて、非常に高い価値を感じました。体験記憶のリフレッシュ&再体験の効果がある感じです。
     一方で、未経験な場所のコンテンツを観ても「ふーん?」ぐらいの印象で、こうした観るだけVRコンテンツは体験の代替にはならないのだなと思いました。 VRによって与える新しい体験で、その体験に価値を発生させるのには(うまく言えませんが)環境とのインタラクティブな体験が不可欠なのではないかな、という気がしました。任意の移動・環境への働きかけだったり、(AIとの?)対話だったり、時間の経過に対する環境・自分の変化だったり…?
     次いで、VRサンプルコンテンツ(Halo)をプレイしようとしたが、いつまで経ってもカーソルがぐるぐる→未起動の繰り返し。 これはPCが起動要件をクリアしてないのかなと諦めて、現実に戻ったらPCのデスクトップに「安全が確認されてないプログラムが起動しようとしている」(意訳)と、セキュリティソフトが起動を阻止していた。 ぐぬぬ。

     かれこれ3時間が経過。
     のどが渇いたのに、どこにも自販機も水道もない!
     トイレに行きたくなったが、どこにもトイレがない!
     疲かれても、寝る場所がない!
     悲しい!

     …そうか、VR空間でこうした体験をしてこそ、心に残る体験としての価値が発生するのかもしれない、なんて。




    <WindowsMR開発環境(リトライ)>
     ひと段落したところで、開発環境:Unity2017とVisualStudio2017の再インストール。

     半年前にDLしたVS2017のオフラインインストールファイルは古くなったっぽいので、頑張って最新版をDLして、インストール…WindowsMR対応PCの方は何故か失敗する。(非対応PCは成功するのに…) 仕方なく、オンラインインストール、で成功。
     Unityも一緒にインストールしたが、それが起動しない。Loading...で止まってる。あれこれいじってたら、セキュリティソフトの挙動がおかしくなってきたので、セキュリティソフトの再インストール。それでもLoading...から進まないので、Unityも再インストール…まだダメ!古いバージョンで再インストール・・・もダメ! ムッキーっ!
     最終的には、アンインストールした後、Unityの設定が保存されている隠しフォルダを消してから再インストールすることで、見事起動! 一日潰れたよー!
     が、あれ? 翌日起動したら、またダメになってる…。→WEBに繋いだら起動!
     …ひょっとして、Unityの最新版って、ネットワークに繋がってないと起動できないの? このPCはできるだけWEB接続したくないんだけどなぁ…。

     紆余曲折あったけど、まとめると…
     開発環境はあっという間に情報が古くなるので、アーリーアダプターの方々が残した記事が右も左もわからない初心者にはむしろ迷う一因になりがちなので、結局はMS本家の記事を読むのが最短距離っぽいです。
     今回ミスしやすかったポイントは、
    ・Windowsの設定をデベロッパーモード(開発者モード)に。しておかないと、ビルド中に設定パネルが勝手に開いてモード変更を急かされる。
    ・VisualStudioのインストールで、Windows Store IL2CCP Scripting Backend をインストール…しない!(してもいいけど、Unityでのビルド時にミスする可能性が増える)
    ・Unityの最新版を(無暗に)インストール…しない!
     まず、MixedRealityToolkit-Unity packageの最新版を確認してから、これに対応したUnityをインストールする、これが超重要!


     早速、試してみよう。
     よし、ホントに昔から、下手すれば子供の頃からやりたかったこと:魚眼レンズで撮った星景動画をVR化してみるぞ!
    ・まず、動画を貼り付ける天球を使い慣れたメタセコでぱぱっと作る…、が動画の座標変換がうまくいかないらしく、プレビューしても真っ黒になる
    ・仕方ないので、慣れないBlenderでヒーヒー言いながら天球を作成〜プレビューも成功
    ・プロジェクトをWindowsMR対応PCにコピーしてVRのプレビューも成功! が、地面が傾いてる・・・なるほど、メインカメラの初期姿勢がここに影響してくるのか、直す
    ・おや? 北斗七星が左右反転してるぞ・・・よく見れば星が西から昇ってきてるよ、鏡像世界だよ!
    ・天球を作る過程でミスしたか、FBXエクスポートで軸変換を間違ってるか、UVかマテリアルの設定が悪いのか?
    ・やり直すのも面倒なので、天球ごと左右反転したら正常な北斗七星になったから、まぁ、これで良しとする。


    ・うーん、映像は1920x1920でそこそこ高解像度な素材だと思ってたけど、静的に鑑賞するVR用だと荒いねー。 やっぱ、4Kが必要なのかな。
    ・あと、WindowsMR非対応のPCでもビルドできたよ!うれしい!(ワークフロー的に意味があるかはしらんけど!)



    <WindowsMRコンテンツ事始め>
     さて、環境が一応揃ったので、4年前(もう4年前なのかよ!?って驚きはさておき)にアラスカで撮ってきたオーロラの動画素材を使ったVR再生プレーヤーを作ってみたのだが、


    あのとても視界に入りきらない巨大な光の乱舞だけでなく、画面端部に圧縮保存されていた当時の印象が展開されるなどなど、なかなかに優れた旅の思い出しツールっぷりにワクワクさせられた。 あの時の空気感が蘇る、脳細胞から絞り出される感じ。
     ただ、手元にあった映像素材で十分だろと使ってみたわけなんだが、なんだか粗が見えるというか、要は画質が悪いぞ!という印象も。
     そこで手元の素材から取りだしうる最良の映像を得ようと、NEX5Nで撮影した元画像からそのまま2368x2368pixで切り出した画像に、ノイズ除去フィルタをかけての動画化処理を試してみた。
     この場合、理屈の上では180°の視角を2368pixでカバーしているわけで、単純計算すればWindowsMRのHMDの視野角110°を1447pixで描画できていることになり、HMDパネル解像度(1440x1440pix)を上回っているので、これで十分だよね、的な腹積もり。
     しかし今度は、このサイズになるとGPUの搭載する4GBメモリ(しかも有効になってるのは3GB?)では不足していたらしく、


    AEがメモリオーバーでエラーを吐きやがった、こんなの初めてだ!

     仕方なく、処理速度の半減を覚悟した上でCPUオンリー処理して、なんとかかんとかで素材を準備。
     でも、これですらまだ荒いなぁ、という印象だったので、こうしたVR再生コンテンツには少なくとも4K映像が必要で、且つ画像処理環境も4K対応に大幅強化しないとダメなのかも、という経験値が得られた。
     ひょっとしたら、このレベルになるともう、視界の範囲をCG的に生成するとかの方がより高品質な映像が得られるのかもしれないな?

     今後のことを考えると、シータVでも買おうかな、と思ったけど、よくよく考えてみたら、こちらは既に専用のプレイヤーが提供されるからこんな苦労は無いのかな。 でも、自撮りが嫌な人間にとっては360°撮影はやっぱり抵抗があるよなぁ。 そんなら、180°撮影規格対応機も今年から出てくると思うので、そちらを待つのも手かな?

     …なんてことを考えつつVR再生を眺めていると、再生するだけでは物足りない、移動もしたくなってきた。
     幸いにしてUnityはHMD付属のVR専用モーションコントローラー(さりげに超多機能!すごいな、これ!)だけでなく汎用品も、それこそキーボードも普通に値が取得できるので、とりあえずは面倒なVR専用な実装を避けて、汎用品経由で体の向きを変える機能を付けようと、Wiiリモコンで簡単に操作できるようしてみるべ・・・、とガラクタ箱から発掘したら、なんと、Windows10のBluetoothはWiiリモコンを接続できなくなってるのな! Oh....

     てか、VR化した時点でVR空間内でのカメラ位置・方向値はVR用マネージャが完全に乗っ取っているらしく、Unity上で設定したカメラモデルのパラメータをいくらいじっても反映されない…。(どうやら、初期値としてだけ反映されるらしい?) キーボード入力で操作しても、VR表示すると一切無視されてしまった。
     ただし、この現象はカメラだけの特別な制約のようで、それ以外のモデル位置・姿勢のパラメータは普通にコントロールできた→天球スクリーンをy軸まわりに回転操作することで方向制御できる機能をつけてやったぜ(笑)

     いや、いや、折角なのでちゃんとやろう、ということで、覚悟を決めてToolkitをきちんと追いかける。
     位置や向きを制御しているらしいMixedRealityTeleportの中身、MixedRealityTeleport.csを追いかけてみたらDoRotation(RotationSize);で回転するようだ?(てか、このスクリプトをアタッチすれば、モーションコントローラだけでなく、ゲームパッドでも回転制御ができるみたいなコードが入ってるじゃん…)
     まぁ、これも勉強だし、もう少し読み進むと、最終的に向きを制御しているのは、transform.RotateAround(CameraCache.Main.transform.position, Vector3.up, RotationSize);で、Vector3.upがUnityではVector3(0, 1, 0):Unityだと垂直軸だから、恐らく「CameraCache.Main.transform.positionが」が向き制御の実体(?)なんだろう。HoloToolkit.Unity.InputModule名前空間を拡張すれば使えるみたい。(但し、デフォルトのカメラだとダメで、MixedRealityCameraParentで設置したカメラなら、くっついてるスクリプト全部外してもきちんと反映されるようだ、よくわからんけど!) まぁ、ここまでやるなら、自分でスクリプトを組むのでなくて、MixedRealityTeleport.csを使えって話だな。
     あ、Toolkitでは、酔わないように?動き始めと終わりにフェードを入れるみたいだが、それ用のモデルがカメラの前にどーんと置いてあるのが、なんというか、発想の近さを感じて微笑ましい。
     あれこれ手探りでコードを試す&デバッグを繰り返そうにも、きちんとビルドしないとコントローラー関係は動作してくれない(Unityエディタ上では動作しない)上にビルドに5分ぐらいかかるので一向に進まないのが辛い。 ビルドしても結構不安定で、数回実行しないと正常動作しない(数回目にようやく動くパターン)とか、いや、もう、30年ぐらい前を思い出す。

     …とまぁ、数日間の紆余曲折の末、最終的にInputManagerを加えればスクリプト記述なしでコントローラーでの移動と回転を実装できる最短距離に気付いた。 くぅっ、最初から教えてほしかったナリ…。

     急がば回れ、まさにその通りでしたとさ!





     未来キター!
     夢が広がるわい!





20171030
バカにつける薬
    今年の夏も、新月近辺は雨ばっかで、遠出する機会がなかったナリよよよ



    <星を追うおとな>
     先日ふと、テーブルに出しっぱなしだったNEX-5/5Tとα7sから外した赤外カットフィルタが目に入って、違和感を感じた。

    「NEXのフィルタだけ光ってる?」

     いや、間違いなくNEXのフィルタが赤っぽく光っているのだ。
     この現象、照明に照らされた白壁がフィルタ表面の反射越しで見えていて、それがフィルタ表面に施された増透・反射防止コーティングによってアンバーに着色されているのだと、すぐに理解できたのですが、
     問題はα7sのフィルタです。 反射光の強度は感覚的に1/5くらい、恐らくエネルギー的には1/20以下なんだろうという印象で、且つまったく着色されていない。

     つまりこれは、αのフィルタには4層以上のマルチコーティングが奢られているのだろう、と推測できるわけで。 なんという贅沢。
     一方NEXは、コーティング1層の廉価版だった!んですね。 悲しい。
     うむむ、理屈の上では画質に大した影響はないのだろうと判るが、精密な光学部品うっとりな嗜好品としては残念な気分というか残酷な現実というか。

     で、これだけならしょぼん(´・ω・`)で済むのですが、そんなら肝心の撮像素子側はどうなのよ、と気づいたので、ボディも並べて反射光を比較してみた。


     フィルタ除去したNEX-5・NEX-5Tは反射光が無色、一方ノーマルなNEX-5Nとフィルタを入れ替えたα7sは反射光がアンバーです。
     ここでも問題はα7sです。
     つまりつまり、これは折角フィルタを交換してHαが写るようになった天体撮影仕様に改造済みのα7sでありながら、実は寧ろHα付近と555nm以外の波長については微妙にロスした状態で撮影していたのか!
     …という微妙に悲しい現実に気づかされてしまったのことよ。

     …うん、バカなことを気にしてますね。 わかってます。
     わかってますよ?





    <1709>
     10/17の早朝、Windows10の更新をかけたら1709が降ってきて、おお、感心感心と思ってたら、ダウンロードが99%で停止して1時間後に失敗したメッセージ。
     イラっ!
     速やかに、MSのサイトでMediaCreationToolをアップデートして、ISOファイルをダウンロード&アップデート!(この時間帯なら、90Mbpsを超える速度でDLできた!)
    --------
    ◎3年前のPCで、更新の準備処理に10分、更新処理に50分、最終の再起動後のアップデート処理で10分、という感じで、更新処理以降は完全に放置でOK
    ◎敢えてRamdiskを残したままアップデートをかけましたが、何の不具合もなく処理が完了
    ◎IE11の細かい不具合のアレコレが解消されてた
    ◎Ramdiskの速度が10〜20%向上してた
    ◎タスクマネージャーでGPUのモニタも可能に
    ×廉価な32bitのWinTAB(Diginnos DG-D09IW2)はタッチパネルが動作しなくなった。まぁ、元々タッチパネル動作が自転車操業的な印象を受ける機種なのでさもありなん、なんですけどね
    ×ハイバネーション禁止の設定がリセットされてた。電源を落としてもRamdiskの内容が残っててて気持ち悪い!
    --------
     ま、気付きがあったら、ボチボチ追加の予定。






    <破裂寸前のセル>
     2011年に買って以来、殆ど使ってこなかったモバイルバッテリーXP18000が、ご懐妊なされていた。


     できるだけ50%以下の充電量になるよう努めてきたのだが、寄る年波には勝てなかったよ。
     ご冥福を。南無。








20170803
光とか赤外光とかレーザー光とか
    今年の夏は、暑いか雨かで出かける機会がないナリよよよ



    <キーボード更新>
     9年前にKBA-BL82を2万4千円で購入、後生大事に使ってきた。 当時、USキーボードの選択肢はそこそこ増えてきていたのに、なんでそんなに高価かというと、当時はまだ照光式キーボードが貴重だったんですよね。 まぁ、防塵・防水機能もあって、裏が鉄板でスゲー重いとか、ゴム足が無くて金属のナベネジがむき出しなので机が傷つくとか、何故か三脚穴が二つもあるとか、工場用?軍用?を彷彿させるような不思議仕様であったこともあるだろうけど。
     で最近の照光式キーボード選択肢は、ゲーミングPC用途で爆発的に増えてきていて、仕様もよりどりみどり、価格もお手頃になってきたので、中華キーボードを6000円で購入。


     KBA-BL82では省略されていたキーが幾つか増えているにもかかわらず、一層コンパクトなのが好印象です。 また、ムダに重くない、適度な重量なので、ノートPC用アームに載せて使っていて、重さで傾いてくるとかなくなりました。 好印象UPです。
     これで、キートップリムーバーとか、キーの隙間掃除用ハケが付属しているのは、運用・メンテするときのことを判ってるなぁ、とさらに好印象。
     で、肝心の照光機能だが、起動時には5段階の4段階目になっていて、ちょっと強めすぎるな、という印象。 ちなみに、各段階での電流値は 0.00A⇔0.13A⇔0.18A⇔0.24A⇔0.28A でした。 KBA-BL82が標準で0.06A〜最大で0.22Aだったので、やっぱりちょっと強い。
     ちなみに、普通はしない使い方ですが、USBバッテリーに挿すと何故か光ります。 KBA-BL82はOSに認識されてから光ったので、この辺りの設計思想の違いがちょっと面白い。
     そんなこんなで、些細な気付きもあるものの、質感もそこそこだし、全体によくできてる、という印象なのに、右側の記号キー(-=[]\;',./)がキートップ上のレイアウトが悪くて光らないのは、凡ミスでお粗末です。代わりにShiftを押したときに入力される記号(-+{}|:"<>?)が光ってます。 USキーボードに慣れてる人なら特段の違和感なく使えるけど、そうでない人には辛い仕様ですね。 惜しい!
     ただ、キートップの文字が小さい・細いので、背景の輝度が高いこともあって、正直、あまり視認性はよくない。 KBA-BL82はメガネを外したときでも見やすかったので、これは残念ポイント。
     以上、次に活かすための備忘録でした。



    <Win10環境再構築>
     うん?なんか変だな?と確認してみたら、またしてもRamdiskのスピードが激減する不具合が発生していた。
     まぁ、Win8→Win8.1→Win10→Win10(1511)→Win10(1607)→Win10(1704)と丸三年以上5回ものOS上書きインストールを繰り返してきたわけで、いくらなんでもマズかろう、ということで重い腰を上げ、久々にクリーンインストールをすることに。
     といっても、Win10になってインストールが実に洗練されてきて、しかもアップデート処理も含めてインストールしてくれるので、インストール後の更新で死にそうになることも無いので、まったくストレスが無い、というか拍子抜けレベル。 カスタマイズ設定もMSアカウント共通で適用されるので、昔ならインストールの度に毎度毎度繰り返してきた設定の手間もない。 昔のことを思えばなんて楽なんだ、と感慨深い。
     MSアカウントに紐づけされていないカスタマイズ設定のキモであるSENDTOやスタートアップのショートカットを予め退避させておけば、環境の再構築が丸ごと引っ越しだけで済むし、秀丸や秀丸メールもレジストリ設定をエキスポートしておいてインポートするだけで済む。 楽勝すぐる。
     ついでに起動ディスクSSDをより高速のSATA接続に入れ替えて、起動が超高速化。
     更に筐体内のホコリやヒートシンク隙間のホコリを駆除して、スッキリ。 熱流も整理。
     目出度し、めでたし…、とはならないのが世の常。
     何故か、いくら頑張っても、タスクスケジューラーがサスペンドから復帰してくれない。 権限設定を入れ替えてもダメ。 いろいろ頑張ったがダメ。 半日粘ったがダメ。 ちくしょう。
     仕方なく、Windows8をクリーンインストールして、タスクスケジューラーが動くことを確認してから、Windows10(1704)を上書きインストールしなおしをすることで無理やり解決、負けた気分。
     あと、何故かIEが高頻度ハングアップする症状が、インストール直後から再発。 となると、セキュリティプラグインと干渉してるのかも。 だとすれば、この機会にIEとの付き合い方も変えていかないとなるまい、ということか。



    <WindowsのPython環境再構築時備忘録(絶対に忘れるので)>
    chainerが1.20だとVariableに.reshape()が使えなくて焦った。upgradeしたら(いきなりメジャーバージョンアップしててビビったけど)解決して安堵。 ちなみに、既にcupyがインストールされていれば、chainer のupgrade時にcupyもupgradeしてくれたのは気が利いてるね。 ただ、cupyはインストールする際や実行時に、ホワイトリスト方式のセキュリティ警告が出まくりになった。ビビリつつも、オンラインでコンパイルしまくりなんだな、とよくわかる。
    ・そうそう、以前はできなかったと記憶していたchainerRLが、Windowsでも普通にpipでインストールできた。Python2.7でも3.5でも平然と。流石だ。 ただ、MKL版numpyが前提のようで、インポートするとエラーが出たので、別途インストールしなおした。
    ・このMKL版のnumpy、4コアのi7でCPU負荷が22%程度だった行列演算が80%弱にまで上昇!よく働いてるぞ…と思ったのに、速度は3分20秒→3分10秒(5%UP)となって、えー。
    ・あと、いつの間にかtensorflowもpipでインストールできた。ただ、python2.7はダメだった。それにnumpyが最新版にupgradeされた際にMKL版でなくなってしまった。仕方ないので別途インストールした。
    ・tensorflowが入ったので、kerasもインストールしたら、バックエンドが自動でtensorflowに設定された。流石だ。
    ・tensorflowつながりで、OpenAI baselineもpipでインストールできた。ただ、GPU版のtensorflowがインストール済みなのにCPU版のtensorflowがダブリでインストールされてしまった。これが悪さするかどうかわからないけど、気持ち悪いのでtensorflowをアンインストールしたら、GPU版も一緒にアンインストールされてしまったので、再度インストールしてやれやれ。
    ・最近は流石にエラーメッセージを読む上で前提となるモジュール名やその因果関係が分かってきたので、新規モジュールインストール時も何とかかんとか対処可能だが、チュートリアル通りにするだけだった頃なら途方に暮れてただろうなぁ。



    <ubuntu16.04+CUDA環境も再構築>
     以前から、外したSSDをUSBケースに入れる〜ubuntuのPython環境を構築して大規模GPGPU計算用にしてきたが、↑で生じた余りSSDを使ってubuntuの最新環境を構築することにした。
     今年の3月頃にもやった作業だし、数年前から何度も繰り返しているので、蓄積してきた経験を元にすれば大した手間もなくできる…、つもりがやっぱりダメだった…。
     今回は (1)CUDAのインストール後にnvccはちゃんと動いているのにサンプルのmakeが全滅していた (2)あと、cuDNNのインストール後にldconfigでエラーを吐いてる (3)そして、chainerをインストールしてもcupyがインストールされない! のCUDA絡み3点セットの不具合発生。
     何度OSインストールからやりなおしてもダメで、試行錯誤を散々繰り返した結果、なんとかかんとか(2)と(3)だけは対処療法で解決できたので、まぁ、よしとすることにした。 (2)はエラーの指すファイルを別名コピーしてリネーム、(3)はchainerインストーラーに頼らずにcupyをマニュアルインストールすることで解決した。(てか、2.0になった時点でchainerとcupyは別々にインストールすることがデフォルトになったということだと、あとで知った。 なのでWindows上のchainerを1.20→2.0へアップデートした時は慌てず騒がず対処できたっス)
     以前はCUDAのインストールで手順を間違えるとシステムごとダメになるとかのレベルだったので、それに比べれば手間も危険性も随分と減ったと言えるのだけど、その反面でファイル管理の複雑化で矛盾が生じやすくなってる感じがしますね。 現時点ではWindowsでPython+CUDA環境構築する方が手間も面倒も少ないっていうのが、なにげに面白い状況だと思うです。
     いや、それともアレかな、勝手知ったるWindowsなら無意識に避けているような凡ミスか何かを、不慣れなubuntuではしでかしているということなのかもしれないな。 上記(2)とか(3)で散々苦労した対処療法はWindows上だったらすぐ思いついていただろうことだし、これが「勝手」を知らないということだろうか。
     まぁ、それが分からないから初心者なんだけどさ。



    <理系・工学系の総合競技なのかも>
     かれこれ30年ぐらい前から、プログラムができないと、CADが使えないと、CAEが使えないと、云々、次々と出てくる新しい技術・ツールでやれることを増やしていかないとエンジニアとしてやっていけなくなる…ということは水平分業化などによってそんなことはないのだが、実のところは一人では何もできなくなる状態への茹でカエル過程なのだと、気づかない人は一生気づかないのだろう、と気づいた今日この頃。
     そんな中、ここ数年の懸念事項だった「Pythonを習得しておかないと、早晩エンジニアとしてヤバイことになりそう!」を払拭するべく、最近ようやっとボチボチ使うようになってきてかれこれ数か月。 数十年来のプログラミング関係蔵出し知識との結び付けや、バラバラだった機械学習・人工知能に関する知識を整理統合する役割も果たしつつ、牛歩な日々です。
     さしあたって、Matlabと比較すると超面倒に感じたnumpyの取り扱いも慣れれば成程で、いまひとつ整理されていなくて見通しの悪いscikit-learnも足元を見ながらどの辺りが未舗装なのかが見えてくればペース配分も分かってくる。 また、機械学習の勘所となるデータのハンドリングは旧来からのプログラミング感覚が重要だったし、chainerなどの新しいNNフレームワーク類ならその開発の経緯を把握することが中身に対する理解を深める早道っぽいことも見えてきた。 やっぱ、手を動かすのが大切だなぁ、と再認識すると同時に、スッキリしなかった領域の見通しが良くなるのは、それだけで楽しいもんだ。
     あと、chainerでGPU計算させる手順を調べてみたら、ソースコードの書き換え箇所が分かりやすい&極小で感動した。 そして得られるスピードに感動した! 素晴らしい!
     手持ちの機材の性能を引き出せる・実感できる素晴らしさって大切!でそれを自分に役立つ方向性を与えること、しかも自分でプログラムで制御できるという、マイコン時代にあった楽しさに通じるものがこの近辺にはあるな、という気がしてきたです、今更ですが。



    <計測機器収集が趣味の一つ>
     以前から業務でちょくちょくレーザー距離計(Bosch製)を使って、これいいな、欲しいな、と思っていたが、この10年で随分と安くなったので、廉価品でもいいや、とポチってみた。
     折角なので、100m計測対応仕様品です!
     早速試用したところ、計測の始点(レーザー距離計の設置場所)が屋外でも、計測の終点(レーザー照射地点)が屋内なら115mまで計測できて、たいへん満足した! いい買い物だった! 暑かった!
         
     反射板が付属していたが、100m先のこれに命中させるには無理のあるサイズですよね。70mくらいならギリなんとかでしたし、実際これがあると計測時間が格段に短く(=安定した計測に)なります。 3Mの再帰反射テープでも同様の効果があったので、大型の再帰反射パネルを作れば、更に遠くまで計測できるかもしれません。
     そこで、ふと、既視感が…?
     …あ、数年前に660m対応のレーザー距離計(ゴルフ用とかの奴)をポチっていた&1回しか使わず、その存在をすっかり忘れていたことに気づいた!
     重複するものではないので決して無駄な買い物という訳ではなかったが、流石に反省です。









20170528
光とか赤外光とか光とか

    最近、ちょくちょく職場にヘッドハンティング会社から電話が来るようになった。
    社名を聞いてみると、ちゃんとした会社っぽい。
    その割に、こちらの年齢すら把握できていないレベルっぽいので、怪しいなぁ、という感じ。
    そんなサービスに登録したこと無いし、複数の会社から来るので「どうやって私の名前と職場の情報を集めたんですか」と聞いたら、「クライアント企業のニーズに合った分野の特許公報・公告を調べました」とのことで、成程。 ここ10年で論文は2件だけど、特許は50件出してるもんな。
    ふむ、なるほど、あっちの業界にこちらの情報がどの程度把握されてるか見えてきたぞ。
    どうやら、私が今の会社に転職して特許出願開始したタイミングから年齢を推定、「若手〜中堅社員」と判断しているのだろう。
    すまん、転職2回してるから、いいオッサンなんだよ…。





    <光あれ>
     震災直後の計画停電時期に、非常用且つアウトドアでも使えるかなー、と考えて折り畳みできる太陽電池モジュール(PowerFilm F15-3600 60w Folding Solar Panel Charger)を$719.99で購入しましたが、まったく使用することなく6年が経過していて、よくよく考えてみれば、私の行動パターンでは直射日光下で活動するのはバイクに乗ってるときだけなのに、そこでこのサイズ(152.4 x 106.6cm)を広げることはできないのである。 
     で、先日ふと、出力は半分以下(24W)だけどサイズは1/5以下のお手頃品UK RP-PC005(RAVPower 24W Solar Charger with Triple USB Ports)が7000円で売っていたので、これなら扱いやすいサイズだわー、ということで追加購入した。

     重量は出力の割にそこそこある(800g弱⇔1.2kg)のが気になるけど、従来は60W品は15V(3.6A)出力を19Vに昇圧してバッテリー充電して運用していたとこが、5V(2.4A)出力x3口となって、イマドキの電源としてはポイントが高い。 大抵のアイテムが直接充電できるのはいいね。
     それに、これまでは充電される側の制約もあるので実効28W程度だったのが、複数繋ぐことによってその制約が緩和されて実効20Wでモリモリ充電できることを確認できました。
     今度こそは、面白アイテムとして活用してみたい。




    <即席爆発何某じゃなくて統合何某>
     現在の普段使いPCは2014年にWindows8で組んだものだが、かれこれ、Windows8.1、Windows10、Win10(1511)、Win10(1607)、Win10(1703)とOSの大規模アップデートを繰り返してきて、微妙に危うい感じかしなくもない。
     その危うさを構成する一要素が、野放図にインストールしてきた開発ツールの放置で、改めて確認したところ、VisualStudioだけで、2012forDesktop、2013forDesktop、2013Community、2015Communityが入っている始末。 されにこれらと連携するOpenCVとかboostとかのライブラリがバージョン違いで複数あって、そこからさらに連携するPythonやUnityのバージョン違い、更に更にでそれらの上で動くモジュールとVisualStudioが連動しているとかの重ね掛けで、実に九龍城。 Pythonのchainer上で動くCuPyのCudaの動的コンパイルとかを考えたら、触りたくないでこざる。
     なので、VisualStudio2017がリリースされても、これ以上インストールするのは気が重いなぁ、と放置してた折に、「久々にインストールプロセスが変化して、必要モジュールしかインストールされないよ」との文句が聞こえてきて、フラフラ〜、えいやっ、と飛び降りることにした。

    1.古いVisualStudioを全部アンインストールする。ついでにUnityもアンインストール
    2.VisualStudio2017 のオフラインインストールをする
    3.VisualStudio2017インストーラーを起動。「C++デスクトップアプリ開発」だけ選択して…、
    4.と思ったけど、折角なので「Python開発」や「データーサイエンスと分析のアプリケーション」、そして「Unityによるゲーム開発」「C++によるゲーム開発」を選択
    5.念のため、上記の選択の詳細設定を確認…、
    6.あれ? なんか、このままだと、AnacondaやPythonとかが新規でインストールされそう?
      なのに、WindowsSDKやMFCが漏れてる?
      などなど、これまでの使い方を続けようとすると後々面倒になる種が盛大に仕込まれてるっぽい!
    7.ので、わかる範囲で設定変更。(こんな素人対応が一層マズイのかも…)
    8.えっらい時間がかかって
    9.あれ? アンインストールしたUnityが新規インストールされてる! 勝手にするのかよ!
      あと、一見Anacondaが新規インストールされてるように見えて戦慄したたけど、これは設定済みのAnacondaが上手く取り込まれてた。やれやれ

    10.次にOpenCVのライブラリをビルドしよう
    11.としたら、当然ながら古いCMakeにはVS2017の設定が無かったので、CMakeも再インストール
    12.ここで、うっかり64bit版をインストールしてしまって、元々の32bit版とダブり=Pathが異なることに気付かずに、ちゃんとしたslnが作れない〜ビルド失敗すること1時間
    13.contribを追加してリリースとデバッグ、それにスタティックライブラリでをそれぞれ32bit版と64bit版の計6回ビルドするのは結構時間がかかた
    14.OpenCVやDXライブラリ、その他諸々の設定を準備完了して、早速プロジェクトを開く
    15.と、ごくごく基本的なstdio.hやwindows.hがインクルードされないので、エラーで真っ赤になった
    16.追加ライブラリは問題ないし、そもそも新規でプロジェクトを作成すれば全く問題ないという現象で、「????」
    17.よくわからないけど、とりあえず余計なSDKをアンインストールしてもダメで、こんな情報を読みつつ、なんとかなるまで、もう5時間かかった

     最終的に分かったのは、フォルダや環境定数の設定がおかしいのではなくて、以前作ったプロジェクトを読み込んでもSDKの設定は古いままで設定変更してくれていない(なのにプラットフォームは2017に変換してくれてる)という変換機能のバグ?が悪さしていたようだ。(元のプロジェクトが、「Microsoft.Cpp.Win32.user.props」を弄った状態で作成したものであったことも関係している説もあるが、やっぱり古めのWindowsSDKを複数インストールしたのが悪かったような気がする…)
     ともあれ、開発環境が一新・スッキリしたので、気持ちよくサンデープログラムできそうでワクワク。


    <Python環境も再構築>
     最近ボチボチPythonを使う機会が増えてきたので、流石にコマンドプロンプト上でやるのは効率が悪い、何かIDEを使おう、Spiderを使うべき? それともVisalStudioを?と思案。
     いや、吾々には25年来の常用エディタの秀丸があるではないか。
     この25年間、プログラムを書くときはいつもこれでやってきて、 VisualStudioだって使っているのはコンパイラONLY(IDEの存在意義たるデバック機能は無視してるの)で、それならPythonだって同じで問題なかろう、…ということで、秀丸にPython実行マクロ等を組み込んでみたら、意外と使い勝手が良かったです。
     まず、編集中のPythonスクリプトを直接実行するマクロを登録してホットキー(私の場合はCtrl-P)を設定しました。 こまめに実行して確認しながらのコード作成スタイルには親和性が高いです。 あと、複数の秀丸を立ち上げて、分解した機能を個々に確認しながら組んで、とかもお手軽にできるのもいい。
     あと、これでファイルタイプの設定にPythonを登録して、ハイライトなどの表示設定をすれば、カラー表示とアウトライン解析で一覧性UPです。
     そもそも、秀丸のブロックコピーや複数行同時入力などの編集機能は、Pythonの表記法と相性がいい気がする。

     ただ、Python2.7、3.5の使い分けで支障が顕在化して難儀した。 何故かPython3系列で、matplotlibをimportできない(Unicode関係のエラーが生じる)スクリプトがあって、かなり再現性があって、結果的にはmatplotlibをpipでupgradeすると治ることも把握できたのだが、その過程でかなり試行錯誤した。 確実な再現性だったのは、conda upgrade でpipを更新したら、pipが動かなくなってしまったり、conda upgrade でmatplotlibを更新したらモジュールごと読み込まなくなるようになってしまうとか、condaを使うとドツボにハマってしまうようだ。再インストールしてもpipは壊れたまま治らない(python -m pip 〜 なら動く)し、ちょっとケチがついてしまった。
     まぁ、引き続きボチボチやっていこう。



    <熱くなれ>
     2年前に格安のサーマルカメラを買って以来、諸々の計測で使ってきて、思いのほか重宝している。
     が、腐ってもエンジニアたるもの、折角の計測装置なのにアプリ経由のどんな処理されたのかわからないデータしか触ることができない状況というのは、なんか、こう、スッキリしないものであって、可能なら生データを読み出したい、読み出せる状況にしておきたい、そんな風な思考が常にあったり、なかったり。
     メーカーもリリース当初は「SDKを準備中だから、まっててね」なんて開発者コミュニティを募って個人情報を集めてたけど、待てど暮らせど出やしなかった。
     そもそも、軍用転用アイテムなのか、日本にはごくごく限られた経路でしか輸入されてきていないので、新しいガジェット好きで名を馳せる日本の開発者コミュニティが活気づくわけもなく。
     そんな日本を傍目に、海外ではそこそこの草の根ハッキングがあって、古くはlibseekthermal、そしてlibseekなどが動いていて、でもLinux前提という辺りが集まっている連中の濃さをお察し。
     当時のlibseekは、どうやらデバイスドライバはlibusbでまかなって、プロトコルを解析したところまで実装されていて、ホントにrawデータしか出力できないものだったので、使える状態にするまでの後処理は自前でやる必要があって、キャリブレーションとかエラーピクセル処理とかどうしたものかな…、なんて思案しているとこ止まりで今に至る。いや、忘れてた。
     で、先日このSeek何某をガラクタ箱から発掘して使う機会があったわけだが、随分とバージョンアップされていたアプリの、相変わらずの使い勝手の悪さに辟易した。 ホントに遊び用の実装なんですよね、敢えて計測用途として活用できないようにしているっぽい。 見てくれの余計な機能は沢山増えていたのに、インターバル撮影機能とか、温度域設定機能が無いのは致命的。(観察用途、監視用途には効果的で丁度いい実装だとは思います)
     そこで、やっぱり自分で実装するかな、と久々にlibseekをGitHubに見に行ったら、意外と小まめにメンテされていて、いつの間にかキャリブレーション機能も実装されているっぽい。あと、派生版も開発が進んでいて、これなら割と使えるのでは、てか、Windows移植もできそうかも…、などと考えつつリンクを辿っていったら…なんと!
     なんと! 別系統からのアプローチでWindows実装を済ませた「SeekOFix」が公開されていて、大歓喜ですよ!
     早速DLして、私にとっては未知のC#実装で少しガッカリしつつ、ドキュメント皆無の潔さに困りつつもニヤニヤしつつ、あと、MS謹製汎用USBデバイスドライバWinUSBのインストールで奥深いアレコレに右往左往しつつ、無事にWin10の画面上に表示される熱画像に再度の大歓喜ですよ。
     このSeekOFix、欲しかった機能がほぼ完全に実装されていて、強いて言うなら、手動の温度域設定を整数にすること、あと、画像保存にスケールの追加辺りの微修正で十分かな、ってことで、ソースをちょろっと加工して、あぁ、もう、満足、これでいいや。


    プチ改造後の操作画面の例

    保存される画像の例




    <最後のNEX>
     オーロラ撮影用に購入したNEX-5Tも、もう4年。
     そろそろ例の頃合いかなー、ってことで、


    またしても、バラしました。



    撮像素子とご対面。無印と違って赤外カットフィルタがポコッと外れました




    これで赤外カットフィルタは3枚になりました。




    恒例の透過率計測結果。 可視光域はα7sとほぼ一緒で、赤外は無印NEX-5と一緒でした


     撮像素子モジュールの固定箇所に焦点調整用?のシムが2枚あったので、外したまま組みました。 (片ボケするかも?)
     分解時にメインボードと液晶モジュールを繋ぐフレキのコネクタ部を半壊させたので、組みあがるまでドキドキしましたが、無事動いたので安堵でした。
     組み立て後の最初の起動で時刻入力を求められたので、あちゃー、オールリセットになるのか?!とげんなりしましたが、リセットされるのはタイマーのみで、カスタマイズ設定やアプリ、アカウント類はそのまま残っていて、安堵安堵でした。マジ安堵。
     あと、ネジが3本余りました。(笑)
     大丈夫かな。






    もうすぐ夏かぁ、早いなぁ…





20170318
昭和四年五月号「経済往来」所載

    ゲーテは云った。未来は喜びと悲しみを蔵して吾々を待つと。

    私は年若き君が学窓を出でてから、出逢うべき喜びと悲しみとを想見して、愛児の門途を送る時のような涙を感ずる。
    悲しみに出逢った時に、人は稍(やや)もすれば世界が挙げて自分を見捨てたように思い易い。然し人知れず愛の眼を君に送る知人あるを忘れてはならない。その人の慰籍の言が現れないのは、君を見捨てたからではなくて、君の悲しみを知らないからである。
    君はいかなる時でも世を恨み己を捨ててはいけない。それは親しい者の心を無視することである。少なくともかく云う私はいつも君の後影を見送りながら、悲しみと喜びと二つながらを、君と分かつべく待っていることを記憶して貰いたい。

    では、勇ましく新しき生活に立ち給えよ。







20170303
春が来た

    花粉も来るので、換気は夜にする日々。




    <忘れないように>
     Unity練習継続中。
     やっぱり備忘録。
     MMDのモデルをUnityに配置してスクリプトでモーション遷移させてみる。
    -------
    (1)MMD4MecanimをAssetsにインポート
    (2)MMDモデルのフォルダをAssetsにインポート
    (3)必要なモーション類をAssetsにインポート(VMDorFBX)
    (4)AssetsのMMDモデルフォルダにできた「<モデル名>.MMD4Mecanim」で「同意」押下
    (5)Assetsのモーションファイルを登録して「Process」押下
    (6)AssetsのMMDモデルフォルダにできた「<モデル名>.Import Settings」の「Rig」ボタンで「Animation Type」を「Humanoid」に変更
    (7)ついでに「Animation」ボタンでモーションを適宜設定(「LoopTime」のチェック等)>「Apply」押下
    (8)<モデル名>.Import Settings を配置、「MMD4 Mecanim Model」コンポーネントの「Physics」ボタンで「Physics Engine」を「Bullet Physics」に設定。「Plugin type」はMMDに合わせる(多分「2.75」)
    (9)「<モデル名>.Import Settings」フォルダ内にできたVMD変換モーションファイル、または任意のモーションファイルをモデルに登録(動かすだけならドロップでOK、スクリプトで制御するならWindow>Animator で左クリック>「Create State」>「Empty」で作られる「New State」を選択して、Inspectorパネルの「Motion」にモーションファイルを登録)
    (10)Add Component>Physics>CharacterControllerして、位置・半径・高さを調整(これがないと、段差や斜面に対応できない)
    (11)複数モーションを制御するなら、一連の「Create State」処理を繰り返す+左クリック>「Make Transition」で遷移矢印を追加〜遷移パラメータの追加と指定、遷移のモーフィングも調整(勝手にされていることもある?)
    (12)あとTransitionのInspectorで「Has Exit Time」のチェックをOFFにしておく(しておかないと、遷移がアニメーション終了までできない&終了するまで物理挙動が停止する)
    (13)Assetsに新規スクリプトファイルを作成、Animatorから上記パラメータを制御するスクリプト[例]を追加する。(ここでようやっとプログラムを書く準備が完了!)…Animetorのステート遷移パラメータをIntにしたときのセット命令はマニュアルにある「.SetInt("<パラメータ名>",i)」だとコンパイルエラーになって、もしかしてと書き換えた「.SetInteger("<パラメータ名>",i)」で動いたぞ。なんでや! あと、C#だと、positionやrotationの直接指定に二命令を要する罠がある。なんでや!
    -------


    <Python備忘録>
     そろそろPython3にしてもよかろう、という声があちこちから聞こえてくる昨今なので、丸1年以上放置してきたWindows上のPython環境をアップデートすることにした。
     前回はAnaconda導入でいきなり失敗した(原因は恐らくユーザー名が大文字だったから?)がケチのつき始めで、延々数日間の試行錯誤に至ったわけだが、その経験を元に今回はスムーズに…、いかなかったよ…。

    (1)MSアカウント名をアルファベットに修正

    (2)Anacondaの最新版インストーラーをDL、インストール、正常終了!

    (3)OpenCVを追加インストール…、できねぇ!

    (4)いろいろとつつき回して、やっぱりできねぇ!

    (5)ぐぬぬ…

    (6)どうやら、Pythonはつい先日に3.5→3.6になったばかりで、OpenCVが対応できていないらしい。タイミングが悪かった!

    (7)仕方ないので、Anacondaインストーラーの旧バージョンを探すが見つけられない

    (8)それならば、Python公式から3.5をインストール…、したものの、やっぱりうまくいかない

    (9)もう一度Anacondaサイトを探したら、インストーラーは無いけどZIPで旧バージョンがあった!

    (10)3.5でインストールしたら、OpenCVもインストールできた! やれやれ

    (11)なのに、今度はCUDAが動いてない。以前CUDA7.5で動いていたのに、いつのまにかダメになった? (まぁ、この間にOS自体の大規模アップデートが2回もあったしね…)

    (12)折角なので、この機会にCUDA8.0、cudnn5.1で再構築すべく、ダウンロード、インストール

    (13)ランタイムは動いたけど、nvccが動作できてない

    (14)どうやら、必要なコンパイラがVisualStudio2013ではダメで2015に更新推奨らしい?

    (15)VisualStudio2015communityをインストール…、うわっ、WindowsUpdateで再起動!?

    (16)インストール失敗したよ…

    (17)再インストールも失敗

    (18)再々インストールも失敗、管理者権限を変えてのインストールも失敗

    (19)この辺りになるとアンインストールしても、次のインストール時にフォルダの変更ができないなど、色々とおかしくなってきた

    (20)似た事例を参考にして、先ずコントロールパネルからVisualStudioをアンインストールして、次に管理者権限のコマンドプロンプトから/uninstall /force でもう一回アンインストール処理することで、ようやくフォルダ変更可能状態にまで復旧

    (21)5回目のインストール…失敗!!

    (22)そろそろネタ切れなので、念のため確認してみたら、やはりIDEは起動できない。しかし、コンパイラはnvccと連動して動くできる状態だと判明!!

    (23)これなら、Python経由でもCUDAは使えるな!

    (24)うーん、及第点ということに! やっほい!


    そんな、こんなの、結局ドハマりで、週末が潰れたよー。



    <【朗報】雷電3でGPGPU>
     ずーっと品薄だったRazer Coreですが、年明け頃からようやく入手可能になったので、以前から試してみたいと思っていた「外部GPGPUボックスとして利用できるか?」をやってみた。
     結論から言うと、できた。 普段は省電力なノートPCやNCUなどを使って、ローカル環境に計算リソースが必要な時はThunderboltケーブル接続、という使い方ができることが確認できました。
     しかも、Thunderbolt3接続による速度低下は皆無です。 GeforceGTX980Tiを使って単精度計算させたとき、PCIe×16接続で1.8TFlopsだった処理が、RazerCore接続で1.8TFlopsでした。
     テクスチャ転送などが無いGPGPU計算では、帯域ではないところでボトルネックになってる、ってことなんでしょう。 ということは、今後更にGPUが高速化したらThunderbolt3が足を引っ張ることになるかもしれません。 まぁ、この感じだと当面は大丈夫だろうでしょうけど。

     ちなみに、タスクトレイに出てくるThunderbolt3のプロパティはこんなん↓で、
     この時のデバイスマネージャーはこんな↓でした。

     兎にも角にも、昔憧れたTeslaD870 を安価・コンパクトに加えて運用性UPで実現できて、実に満足度高いっス!



    <【悲報】ALIENWARE 17R3でRazer Core動作せず!>
    Thunderbolt3のドライバーを最新版(intel NUC6i7KYKでCoreが動作したドライバと同じバージョンNo.)に更新して、Thunderbolt3ファームウェアも最新版にした上で、Coreとケーブルを接続!
    …何も起こらない。
    よくよく調べてみると、デバイスリストにUSB3.1コントローラーとハブが追加されていたが、動作していない。
    肝心のThunderbolt関係はまったく動作していないし、強制的に立ち上げても問答無用で終了してる。
    と、いうわけで、DELLのファームウェアによってRazer Coreは明示的に非対応にされているっぽいです。 GAの在庫が捌けるまではこれが続くのかな?
    残念!



    <フードの中、温かいナリ…>
     フルサイズのデジカメを買ったのにレンズはAPS-Cか30年以上昔のしか持っていない状況というのもアレなので、星景用で使ってきたATX116相当のフルサイズレンズ、且つ安価なれどもそこそこ良いと評判のSAMYANG 14mm F2.8をポチった。(直後に光学性能数段UPの新製品が出てた!くそっ!)
     気を取り直して、
     このレンズ、魚眼レンズのごとくの前玉で、保護フィルタの取り付けは不可能で、ネジも切ってない。
     とは言え、いかにも結露しやすそうなレンズなんで、何らかの結露対策は必要そう。


     とりあえず、前玉を外してみた。
     ふむ、前玉の裏に空間があるので電熱線を仕込めそう。
     ただ、アルミの削りだし部分は表面処理されていなくて導通し放題なので、ショートが怖い。
     そこで、レンズ押さえ外周部分に僅かに残ったネジ山谷部に電熱線を通して、耐熱テープ(3M 33+)で固定して、


    組み立てなおして、フード部分をハンドニブラで切り欠いて完成

     これならコネクタ部がレンズキャップに収まるので、運用時の面倒も無さげでよろしい。
     さて、早速通電、サーモグラフィで確認してみると…、


     すぐに暖まったフィルタに比べて15分経っても温度低いなぁ

     薄いフィルタと前玉とでは、熱容量が10倍以上違うってことなんでしょう。
     まぁ、電流は0.3〜0.4A程度ですから、撮影開始時から通電し続けるような使い方でもなんとかなりそう。


     今年バージョンの星景撮影用お出かけセットはこんな感じに

     さて、さて、早く暖かくならないかな。。






20170105
正月休みの自由研究
    例年になく暖かい&いい天気が続いた年の瀬&正月でした。



    <21年目のDirectXプログラミング環境>
     6年前にステアリングコントローラーのモーターを制御するプログラムを作ったことがあったのだが、少し先に似た機能が欲しくなりそうだったので、久々にDirectXの開発環境を構築しようとしてみた。
     …が、DirectX SDKは2010年以降アップデートされてないのですな。無理矢理インストールすることもできなくはないみたいだが、流石にセキュリティ的に気持ち悪いので、やりたくない。
     ならば、継続的にメンテされているDXライブラリが使えるかな、と調べたがDirectInput関係は手付かずのままみたいで、しょぼん(´・ω・`)。
     うーん、どうしたものか、と頭を抱えていたら、SDK放置プレイなのはDirectX SDK自体が廃止されていて、WindowsSDKなどに統合されていた!結果であったという記事、そしてVisualStudioがインストールされていれば、既に開発環境も構築済みになっているよ、という記事を発見。 なんだってーΩΩΩ
     しかし、チュートリアルやサンプルコードが無いと何もできない私なので、結局は昔のSDKをダウンロードするしかないのかな…、と思っていたら、2013年のMicrosoftの開発者ブログにサンプルのアップデート版が提供されていて、しかもGitHubで継続してアップデートされていました。マーベラス!
     早速DL〜フォルダを展開しただけで、環境設定をいじること一切なしでサンプルコードを即ビルドできました。 素晴らしい。
     だがしかし、出来上がったForceFeedbackAPIを使ったプログラムを起動したら、「そんなデバイスは無い」で終了してしまう。 そんなバカな…いや、そういえば、インストーラーではドライバを上手くインストールできなくて、いろいろと小細工してインストールしたのが悪かったのかもしれない。 というわけで、ドライバのインストールができない理由をアレコレ調査して、最終的にWindowsXP時代のまま使っていたUSBドングル管理ドライバが怪しそうや!とアタリをつけてアンインストールしたら、無事インストール可能となって、FF機能も使えるようになりました。やれやれ。
     あとは、今回ご所望の外部からのリモート機能をUDPで制御する汎用プトロコルとしてOSCpackを追加して、所望の機能が超即席で実装完了!
     …と思いきや、送信は文字通りバカチョンで実装できるのですが、受信側はなんだかうまく実装できなくて、仕方なく割り込み処理を加えたりした結果、動くには動くけど、どんどんソースが汚くなってきて、あれあれ〜?おかしな雲行きだぞ〜?
     …と数時間もがいた末に、アカン、ダメじゃ、とギブアップ。 流石、昔からの問題。
     で、大人しくWinsockで実装しようかと、サンプルをググっていたら、boost::Asioの実装事例がここそこにあって、そういえば以前マルチスレッドをお試ししたときにboost環境を追加してたじゃん!と思い出した。
     あぁ、こんなところで役に立つとは! 早速最新版に更新して…、と思ったら、1.6以降はVisualStudio2013のコンパイラではうまくビルドできないとかの情報があったので、今回は更新なしで、そのまま(1.59)使うことに。(…ただし、いざビルドしようとしたら、/MT用のライブラリが用意できてなかったので、しばし悩んだ。結局、b2 link=static runtime-link=static toolset=msvc-12.0 -j8 で解決)
     で、このboost::AsioのUSB、何といっても、非同期受信が簡単にできるのが実にナイスです。 お手軽に実装できそうです。 素晴らしい。
     …と思いきや(二度目)、送受信両方を一緒に実装した時点で、プログラムが動かなくなって焦った。 どうやら、非同期受信処理のio_service.run()のところでストールしてるっぽいので、送信処理のio_serviceと別にしたり、ひょっとして別スレッド処理が必要なのか、はたまたOpenCVとの相性なんか、などなど、しょーもない回り道をした末、「非同期受信処理の一回目は受信バッファが空だと受信するまで待機しちゃう(バグ?)」と気付くまでに数時間かかりました。 自分の受信ポートに自分自分でダミーデータを送信する処理を追加して、無事にプログラムが動き出しました。
     あ、あと、受信バッファにゴミが残るっぽい(split()処理で中身を取り出そうとするとゴミが溢れ出てくる!)ので、読み出し後に毎回.fill(NULL)で明示的に埋めるのが必要そうでした。
     そんな、些細な引っ掛かりがあったものの、一々自分で実装していた昔と比べれば、とんでもなくお手軽に機能実現できるようになったもんだ、と感無量です。
     とりあえず、以上、備忘録でした。





    <去年の残件>
     去年の春、熊本地震の影響で品薄になる前に…と、入手した高感度番長、α7s↓ですが、

     肝心の写りはどうなのよ、ってことでいつもの場所に撮りに行ったところ、
    感度最大:ISO40万にすると、ライブで天の川が確認できているので、おお、これは凄い、パシャリ。


     おお、これは酷い。

     オフラインでのノイズ削減処理がまるっきり追いつかないレベルのノイズで、少なくともタイムラプス用途では使いようが無いです。 コントラストがそこそこある星像は存外にしっかりとしていますが、ハーフトーンの酷さはどうしようもないですね。 がっかり。
     事前の調査でα7sは赤外カットフィルタでHαが2割程度しか撮影できないことは判っていたので、少しずつ感度を落として、且つHαが写るように後処理して…、で頑張ってみたんですが、JPEG撮って出しをつつき回すやり方、且つ感度でカバーするために3倍程度の露出オーバーで撮影しておいて、後処理でなんとかする、という方針では、これ↓が精一杯でした。



     ギリギリの、ナイフ一枚を通すようなフィルタ設定を作り込んでこの画です。
     色深度8bitのJPEGではこれが私の限界です。
     ちなみに、同じレンズ・同じ条件でNEX-5(フィルタ除去改造)だと、こんな風↓に撮れます。



     色調整などは数秒間程度のインスタントなんで、ここからいくらでも見栄を作り込むことができます。
     そもそもNEX-5の方がα7s(のAPS-Cモード)よりも解像度が高いので、階調・ノイズ処理的に有利なのに、改造によってHα取り出しの為に無理する必要もなくなったので、この余裕です。 完勝です。

     折角のα7sですが、タイムラプス星景撮影では、インターバルを短くできる以外でNEX-5改に完!敗!です。 ガーン。
     折角のα7sを活かすには、フルサイズ用の広角レンズを新しく導入するか、はたまた、α7sも改造するか…、
     ……ふむ、後者で行こう!ということで、早速分解…は流石に怖かったので、今回は老舗の業者に依頼することにしました。

     ※水道橋のスターショップの店舗へ直接持ち込んだんですが、入店して「あれ?店内が閑散としてる…、誰もいない…」で、しばらくたってから登場した店員さんに「明日で店舗を畳むんですよ…」というタイミングでした。 子供の頃から天文雑誌に見てきた老舗が消えるのは寂しいですね。

     依頼して1週間とちょっとで改造済みボディと、外したフィルタが到着です。
    ※ついでに、本体にインストールしたアプリもPSNアカウントも全部リセットされてました。




     左が昔外したNEX-5のフィルタ、右が今回外したα7sのフィルタです。
     あれ?なんか同じフィルタの大きさ違いに見える。
     そこで、NEX-5とα7sの分光透過特性を計測してみたのがこちらのグラフ。↑
     どうやら、可視光の範囲ではほぼ一緒の特性みたいです。 赤外・紫外(青紫)でちょっと違うけど、少なくともHαは15%ぐらいしか透過してないということだった訳です。
     つまり、今回の改造でHαに関しては感度6倍以上になった!と期待できるので
     今度は、お手製の簡易分光器 で新生α7sの分光感度特性を確認↓してみました。


     よしよし 超余裕でHαが撮れそうだぜ!

     矢も楯もたまらず、裏の墓場に三脚を据えて、南中したオリオン座と一角獣座に向けてみた。
     条件は横浜市内・晴天、光害カットフィルタを装着してISOは12800の固定撮影、星が流れるギリギリで2秒露出、レンズは30年前に6000円で買ったminolta MD135mmF3.5、記録モードはフルサイズ。


     おお、固定撮影なのに馬頭星雲周辺までそこそこ写ってる!



     こんな光害の中でもバラに見える!


     ぶっちゃげ、1秒露出でも写ってた。
     横浜市内でこれなら、キレイな夜空の場所に行けば、固定撮影でもかなり撮れそう。
     ワクワクだぜ、ひゃっほう!
     早く温かくならないかな。



    <蒼い閃光>
     上記の分高感度特性を確認する過程で、異なるボディ間のスペクトル画像を比較することが必要になるため、キャリブレーション工程が必要になる訳ですが、今回は前回使った緑レーザー+植物用LEDに替えて、赤レーザーと青レーザを使うことにしました。
     赤レーザーは20年前に買ったオモチャがあるとして、青レーザは追加で購入。 これで3原色のレーザーが揃ったわけです。
     早速分光計で計測↓。


     青レーザはスペックには405[nm]とありましたが、408[nm]って感じです。ちなみに、緑レーザーは1000倍の1000[mW]の出力なんですが、エネルギー量は青レーザの倍もない、って感じですね。
     ちなみに、輝度は青レーザー:0[cd/m2]、緑レーザー:812[cd/m2]、赤レーザ1[cd/m2]でした。(@分光計がサチらないように拡散減光処理した条件) 感覚的にも納得できる値です。 要はレーザ超暗いです。

     まぁ、人間の視感度はこんなん↓なんで、青レーザは暗く感じるのは止むえないんですけど、


     実のところはエネルギーがかなり強い、ブルーライトどころではない、危険なレベルなんだと、確認できました。
     「青レーザーって、スペックルノイズがあまり見えないなぁ…」なんて、凝視してる場合じゃなかったよ…。
     いや、いや、でも、青紫光が近視の進行に対する抑制効果があるという論文もあったりするので、実は眼にいいかも??? ちょっと期待できる情報ですな。

     ちな、三原色が揃ったと言いつつ、この青レーザ、実際は青紫レーザーなので、RGB三原色とするには不適でした。↓



     ちょっと残念。




    <Unity不審者警報>
     故あって、Unityの練習中。
     すぐ忘れそうなので備忘録。
     今回はStandard Asset>Charactors>ThirdPersonCharactor>Prefabs>AIThirdPersonControllerに、同じくStandard Asset>Utlity>のWaypointCircuitと、WaypointProgressTrackerを使って、人間の徘徊挙動を作ってみる。
    -------
    (1)床面に適当なポリゴンを配置
    (2)AIThirdPersonControllerを配置
    (3)Window>Navigation でNavigationパネルから床面を指定してNavMeshをBake
    (4)適当に「Create Empty」で経由点グループとなる親オブジェクトと実際の経由点の子オブジェクトを作成〜配置
    (5)経由点グループにWaypointCircuitをコンポーネントに追加、Assignボタン押下
    (6)経由点の起点に「Create Empty」で先導用のダミーオブジェクトを作成
    (7)先導用ダミーオブジェクトにWaypointProgressTrackerをコンポーネントに追加、「Circut」に経由点グループオブジェクトを指定
    (8)プレビューしながら上記WaypointProgressTrackerコンポーネントの「Look Ahead For Target Offset」の数値を調整
    (9)マニュアルに沿ってMoveTo.csを作成、AIThirdPersonControllerのコンポーネントに追加
    (10)MoveToパネルの「Goal」に先導用のダミーオブジェクトを指定
    (11)MoveTo.csに Update()項を追加して、中身をStart()からコピー
    -------

     よし、よし。



     この後、MMDのモデル・モーション取り込み手順を練習したついでに、Standard Asset>Charactors>TheirdPersonCharactor>Prefabs>ThirdPersonControllerを追加して、さらにMMDのモデル入れ替えたものを(10)でGoalに設定するとこうなる。


    うわ、なんて酷い絵面だ…


    純粋にUnityの勉強をしていただけなのに、なに、この犯罪臭。








201611104
適材適所と最適化


    <GPGPU>
     最近はビデオ編集作業の都度、大量のノイズリダクション処理が発生していて、i7-6700HQではちょっとばかりイライラさせられる場面が増えてきた。
     つまりはNR処理が完全に作業のボトルネックになっている。
     そしてAfterEffectsは未だにCS6を後生大事に使っているので、GPUの使用率もイマイチ低いときたもんだ。
     だがしかし、確かノイズ除去フィルタはGPUを演算に使えた筈だったよな、と以前検証したデータを確認したら、50%程度の速度向上であった。
     うーん、GPU本来の演算性能からしたら、今一つな効果である。
     が、よくよく考えたら、このフィルタも丸一年ぐらい更新してなかったな、とメーカのWEBサイトを確認したら、案の定、かなりバージョンアップしていた。
     早速更新&検証データで処理してみたところ、CPUで2分16秒の処理が、GPU利用で2分5秒になった。 しょぼい。 がっかりだよ。
     だがしかし(その2)、ここで「CPU+GPU」という設定を発見、これで処理したら1分42秒になった! やったね、倍速だよ!
     購入後丸一年を経て既に型落ちになってしまった&モバイルGPUそのものが無くなって寂しいGTX980mだが、ここにきてようやく納得のいく性能を発揮してくれたなー、と満足ナリ。


    <miniPC環境>
     intelがAtomの開発を終息させるということなので、今のうちに出張用軽量PC且つ汎用コントローラー素体として使い潰せる安Winタブを仕入れておくか、とDiginnos DG-D09IW2を購入。
     Winタブの購入は、今なおベッドサイド用として絶賛運用中VivoTab Note 8以来なんで、2年半?3年?ぶり。
     スペックを比較して驚いたのだが、画面サイズが8インチ→8.9インチになった分だけ寸法重量は増加している上に、最大?の特徴であるUSB3.0のTypeAコネクタが装備されていることからして、薄くなってる(10.5mm→9.5mm)のはやっぱり予想外且つ結構凄いことなんでは、と感心感心。
     もう一つのトピックであるmicroUSBポートも装備されている:USBデバイスを使いながら充電できる!という本当の意味での価値ある実用的実装について、てっきり充電専用のポートなのかと思いきや、きちんとUSB2.0ポートとして使えるものだったという嬉しい誤算が。 つまり、外付けHUBなしに二つのUSBデバイスを同時運用することもできるので、使い勝手が非常にいい。
     かてて加えて、中華Winタブは上限64GB制約なことが多いmicroSDXCカードスロットは、きちんと200GBにも対応していたのが更にうれしい。 素晴らしい。
     しかもBIOSも簡単にいじれて、microHDMIポートまであるので、軽い作業なら普通にデスクトップでの運用に使えそうだしで、タブレット固有の面倒なしにいろいろといじれる〜使い潰せる「普通の」小型PC感がプンプンと漂っていて、実にいい。 スタンドアロンのコントローラーとして

     ちなみに、本体ストレージとUSB3.0経由のベンチはこんな↓感じ。


     安タブであることを踏まえれば、望外の性能だと思う。 特に、USB3.0周りはデスクトップの8割以上出ているし、ここにケチをつけたら罰が当たりそうなレベル。
     あと、基本的にデスクトップアプリしか使わないような使い方だと、正直Win8の安いWinタブはいろいろと制約が多くて使い勝手の悪い場面が多々あったが、Win10になったことでかなり改善してる点も好感度高いです。

     まぁ、画面解像度は1920×1200で若干過剰気味なので、スケーリングは200%に設定しないとまともにタッチ操作できないとか、Win8に比べて操作がもっさりしてるとか、メモリが2GBしかないのでWEBブラウズで複数タブを開けないとか、本体ストレージが32GBしかないとか、幾つかのアンバランスな点が気にならなくもないが、まぁ、運用上の工夫でどうとでもなりそう。
     開梱、即1607アップデートをかけて、安定動作中。
     あと、折角のフルサイズUSBポートなんで、これを活かしたGPSドングル↓を追加購入。


     これで屋外でWEB接続なしで使う地図の使い勝手が大向上。 ニヤニヤ。 これがポータブルPCのあるべき姿だね!

     総じて、非常にお買い得なアイテムであったと、ホクホク。







20160818
盆休みの自由工作

    <ubuntu16.04LTS vs Skylake>
    ubuntu16.04LTSが出たので、chainer環境のインストールを試してみた。
    艱難辛苦で悲惨な有様だった14.04LTSと違い、スムーズにインストールできた。
    ただ、インストールの過程でプロセスが間欠的にフリーズする症状があったが、

    sudo apt update
    sudo apt upgrade

    を済ませば、フリーズの頻度はかなり改善するっぽい。
    大問題なのは、CUDA7.5のubuntu16.04版が用意されていないこと。
    仕方ないので、8.0RCをインストール、これに合わせてcudnnも5.0をインストールする。 これでCUDAの環境変数も適宜書き換えると、きちんとサンプルのmakeが通った。 ふむ。
    そして、chainerのインストールも恙なく完了し、勿論cupyやcupy.cudnnもインポートできた。 ふむふむ。
    だが、実行してみるとエラーで止まってしまい、NGだった。
    やっぱり、CUDA8はchainer(1.9.1)非対応っぽい。 ダメか、残念、がくー。

    ここで、面白い情報を発見。
    CUDAをインストールしないという選択肢があるらしい。
    文字通り、CUDAをインストールせず、chainerをCUDAでGPU計算させるのだ。
    具体的には、CUDA7.5のドライバだけをインストールするのだ。
    これでもまだなにを言ってるか自分でもわかりにくいのだが、要は、CUDAをインストールするとGPUドライバもインストールされたが、ここは丁度その逆で、GPUドライバをインストールすると、CUDAドライバがインストールされる、というのだ。
    私の場合はGTX980M/Tiなので、これ↓でOK。

    sudo apt install nvidia-cuda-toolkit nvidia-361
    sudo reboot

    これでCUDA演算に必要な最小限のCUDA7.5ドライバがインストールされるので、あとはcudnnのv4をインストールすればchainer(1.9.1)がきっちり稼働する環境構築ができました。 環境変数の書き換えも不要で超簡単。 かかった時間も一時間弱。 素晴らしい。

    但し、これだとCUDAの開発環境がインストールされないので、CUDA関係を使ったソースをビルドすることができない、完全に実行専用となってしまうのが惜しい。
    が、そこはそれ、chainerとて遠からず16.04に対応するだろうし、これも一時的な問題でしょうから、当面は割り切った運用であれば問題ないかな、と。




    <Anniversary Update>
     2014年に新調した普段使い用PC(Core i7-4785T TDP35W、Windows8)にWindows10を上書きインストールしてから早1年、その間1511にアップデートしてはいたが、なんか微妙に調子が落ちているような気がしていた。
     その最たるは起動に時間がかかるようになってきた、ことよりも何よりも、RAMDISKの速度が激遅になってきた、という気持ち悪い状況。


     左が新調直後のRAMDISK、右が最近のRAMDISK。
     Writeの遅さたるや、シーケンシャルで半分、ランダムで1/20という悪夢のような値。 なんだこりゃ。
     ここまでくると確実に体感できる遅さで、パケット的な転送を行うソフトとの相性は最悪、ウェブブラウザの動きももっさり感がついて回るレベル。
     もう一台のスタンドアロンPC(必要な時だけWEB接続する)も大同小異な状況、というか、同様な症状が再現した状況証拠を押さえることができたことで原因が推定できたのだが、恐らくセキュリティソフトの重ね掛けみたいです。
     ドライバの入れ替えやセキュリティソフトの停止など、いろいろと試してみたものの、症状は改善せずで、まぁ、現状で運用上の支障があるわけではないのだから、とここ最近は半分諦めていました。

     そこで、今回のAnniversary Update(1607)です。
     深い考えがあったわけではなく、「とりあえず、やっとくか。まぁ、今回もうまくいくだろ」程度の気持ちでアップデート開始です。
     ものすごいダウンロードスピード(コンスタントに90Mbps超なんて初めて見た…)で更新データが取得され、20分弱程度の準備作業(この間、操作は受け付けないけど、NIC経由で別PCからのファイル操作はできました)、そして再起動と再構成をもう20分程度かけて繰り返して、無事に再起動。


     そしたら、RAMDISKの不具合が解消していました! 回復してます! (大体)元通りです! ハラショー!
     てか、RAMDISKにテンポラリフォルダを設定したままでも、正常にアップデートできてしまうことに驚き半分です。 環境定数を確認してみると、RAMDISKを指定したものはデフォルトに書き換わっている、まぁ、それは判らんでもないんですが、RAMDISK上のフォルダを指定したショートカットが消去されていたり、書き換わっていたりの芸の細かさには感服です。 これらのせいで、自作の環境自動化プログラムに不具合が生じたけど、まぁ、それは仕方がないかな、となる。
     あと、共有の設定も勝手に書き換わっていて、ネットワーク接続された他のPCのドライブは見えるのに、こちらのPCのドライブはパスワードなしで見ることができない、という状態になっていましたね。 しかし、これはもう一台のアップデートでは生じなかった症状なんで、原因不明ッス。




    <おうちでMatlab それから>
     2年前に価格1/20の個人ライセンスが新設されたと聞いて、当時新調したばかりのPCに購入した↓わけだが


     あれから2年、当時はすぐにでもPythonに移行するだろうなー、なんて思っていたのに、未だにMatlabの使用頻度は結構あったりなかったり、そして移行できない処理系があったりなかったりするので、流石にちょっとばかしメンテが必要っぽい状況になってきた。
     まず、上記したように、OSがWin8.1→Win10→Win10(1511)→Win10(1607)と更新してきたけど、問題なく自動でライセンスが移行できていて、メンテの面倒がなくてよかった。ライセンス管理はホントに面倒で面倒で仕方がないので、うれしい話だ。
     ただ、使用しているPCのメモリが16GBしかなくて、しかも8GBをRAMDISKに割り当てている関係上、大きなデータの処理ができない問題が最近は顕在化しつつあった。
     それに、インストールしたPCにはiGPUしかないのも心許ない。
     その点、去年新調した作業用PCにはノート用とはいえども理論性能4TFlops弱:GPGPU計算実測で1TFlopsを叩きだせるdGPUが搭載されていて、しかもメモリは先日32GBに増設したばかり。
     …ということで、超々面倒でできれば避けたいことだけど、盆休みのヒマを活用してPC間でのライセンス移動を試みてみた。

     とりあえず、Google先生で探してみたが、ホームライセンスでの移動らしき記事は見当たらない。 似たようなライセンス(?)の学生ライセンスについてはちょくちょく記事があって、あとはレギュラーライセンスで多数ユーザーが使うような環境の管理記事ばっか。
     そこで、メーカーサイトから、インストール時以来開いたことのなかったユーザーアカウント管理ページに入って、どうやら「アカウント」と「ライセンス」と「アクティベート」がそれぞれ違った意味で使われているっぽいことを把握した上で、もう一度一連の記事を読み返した結果、以下の手順でライセンス移行ができました。

    (1) 旧PC上でこれまで使っていたMATLABを立ち上げて
    (2) <ホーム>タブのHELPからアクティベートの停止処理
    (3) 新PCでユーザーアカウントページからMATLABをインストール処理←※インストーラーのDLがEdgeだとできないのでIEで対応、あと自分がライセンスを持ってるVer.を正しく指定してDLしないとダメ
    (4) インストール処理完了直前にアクティベート画面が出るので適宜入力

     念のため、すべてオンラインで処理するのが前提です。
     やり方さえ分かってさえいれば実に大したことが無い作業だ。 しかるに、こうしたユーケースを幾つか明示した上で手順を示すような分りやすいコンテンツをメーカは提供すべきだと思ってやまない。 コードのサンプルはあれだけ潤沢なのに、担当者のレベルが違いすぎるのだろうか。 サポートのコストを考えればその方がよっぽど安上がりだと思うんだが、そうでもないのかな。

     ともあれ、これまでの4倍規模で学習データのSVM処理ができるようになったので、いい盆休みでした。







20160502
たまには役立つサンデープログラミング

    <SusieとアニメーションGIFと自己満足>
     画像データの整理という作業は、古来からPC稼働時間でかなりの割合を占める一大タスクである。(異論は認める)
     趣味は勿論のこと、最近は業務上でも資料作成の画像素材管理に留まらず、画像認識関係などで桁違いに大量の画像データを扱うなど、画像整理の頻度は増える一方である。
     そんな中、ここ20年はそうした作業に画像ビューワーSusieを、今なお使っている。 しかもver.0.47b。
     しかし20年近く前とは比べ物にならないデータ量・用途・Windows10対応などなどに対しては、レジストリを編集してカタログを使えるようにする、プラグインは必要最小限にする、順番の入れ替え作業:GUIでの一括リネームはAdobe Brige(AfterEffectsCS4のおまけ)を併用する、などなどの工夫を積み重ねてよりよい使い勝手を維持しようとして、それなりに満足している。

     が、アニメーションGIFに対応していないというSusie「仕様」に対しては、GIFを整理する頻度自体の少なさもあって、取り立てて対策してこなかった。
     どうしても確認したければ、その場しのぎではあるが、カタログからWEBブラウザへドロップすればいい、程度の認識です。
     しかし、この↑やり方は、大量のファイルをまとめてZIPでアーカイブしたものをカタログで閲覧している場合は使えない。 今や画像ファイルは日々&根こそぎZIPしている昨今なので、アニメーションGIFを確認するには一旦解凍してから再生するしかなくなっていて、むしろそんな一手間が増えていた、というか面倒で最近は閲覧すらしなくなっていることに、今更ながらに気付いた。
     まぁ、この程度の課題であれば運用上の工夫でなんとかできるのでは? と重い腰を上げてみる気になった。

     と、いうのも、簡単にできそうかも?というアテがあったのだ。
     Susie向けにアニメーションGIF対応プラグインを自作する? いや、いや、過去20年にわたって作られてこなかったのだから、多分ダメなんだろう。
     しかし、Susieのカタログ機能の一つ(且つこれまで全く使ってこなかった機能)として、右クリックメニューの「送る」があって、これを利用すれば、割と簡単にSusieとシームレスに外部のビューワーでアニメーションGIFを閲覧させる実装ができそう、と踏んだのだ。

     そこで、まずはその「送る」機能が参照しているSusie直下の「SENDTO」フォルダに、アニメーションGIFに対応したビューワー(ここではMCP-HC)のショートカットを置いたところ、通常のフォルダを閲覧するときのカタログであればアニメーションを再生できたが、アーカイブ内のアニメーションGIFは再生できなかった。 ふむ。
     次に、「SENDTO」フォルダに、「echo %1>susie_path.txt」と書いたバッチファイルを置いて「送る」操作して生成されたテキストファイルから、Susieがどのような情報を「送る」しているのかを確認した。 結果は、なんのことはない、「送る」操作した画像ファイルの絶対パスを送っているだけだったのだが、問題はアーカイブ内のファイルパスも「<アーカイブ名.zip>¥<アーカイブ内のフォルダ名>¥<画像ファイル名.gif>」といった形で送っているのだった。 つまり(アーカイブ内を閲覧可能なビューワーでないと)意味不明な情報が送られてきているわけです。
     そんなビューワー、探せばあるのだろうけど、それよりも、ここまで情報が取り出せているのであれば、これを使って指定した画像の解凍→閲覧を自動で行うバッチ処理をするのが手っ取り早い! となるのは、致し方ないと言えます。(←25年前、既に普及期にあった表計算ソフトを覚えるのが面倒くさいからと、自分で計算ソフトを作ってたような、おバカさんからちっとも進歩してません…)

     さて、Susieの送る情報を(a)アーカイブ (b)GIFファイル とに分離する正規表現が使えるテキストフィルタがあれば一発だよね…、と思ったのもつかの間、DOSの頃ならまだしも、Windows標準でそんな機能は無い&すげー面倒だと気付くまでに4時間。
     気を取り直して、それならPythonスクリプトを組めば…、とShift-JISの文字処理にイラついてキレるまでに2時間。
     結局、勝手知ったるCで組んで、事なきを得た(30分)が、なんだか、負けた気分。

     改めて、アーカイブから指定したファイルを任意の場所に解凍するコマンドラインオプションの付け方を調べると、最近はそんなニーズが無いようで、WEB上に該当する記事が見当たらなくて、これまた結構な時間彷徨うことになった。 結局はあれこれ試行錯誤した結果、普段使いの7-Zipに付属していたコマンドライン用7za.exeが「7za e <.zipファイル> <GIFファイル名> -o<解凍場所>」といったシンプルなやり方でOKでした。 解凍場所は勿論RAMDISK上のテンポラリフォルダ。
     そして、解凍オプション「e」によってフォルダ構造を無視して解凍するので、ビューワーには<解凍場所><GIFファイル名>を渡すだけで再生開始です。
     再生後は、解凍したGIFファイルを消去して、処理完了。

     一連の処理をバッチファイルにして「SENDTO」フォルダに置けば、Susieに念願のアニメーションGIF閲覧機能を追加できました。なんとも原始的な実装です。

     まぁ、きっとこれも、誰かの再発明なんだろうけど、PC環境のカスタマイズというものは、えてしてそんなもんですよね。
     それに、計算資源・記憶容量をムダに垂れ流す、昔ならあり得ない処理系になったわけですが、それでも昨今の環境であれば十分実用的というのが、我ながら興味深かったりするのであったのことよ。



    <4代目のEマウント機>

    4年ぶりにカメラを買いました。

    今更ですが、NEX-5を下回る低解像度と30倍の高感度番長、α7sです。 流石にちょっと大きい。

     高感度に加えて、NEXにはなかったNR OFF機能があるのも興味があるある。
     早速、ISO10万でボディキャップのままノイズの様子を観察。


    …あれ? 思ってたより全然ノイジーだ。(1/2ぐらい縮小)

     このノイズパターンはNRが取りにくい。
     仕方ないので、今まで(面倒なので)避けてきたホットピクセル除去を処理してみる。


    意外とキレイに取れた。 これならNR処理でそこそこキレイにできそう。 ふむ。

     てか、exifに記録される感度が6万5千でサチるんだね。

     あと一応、NEXと条件を合わせて確認してみた。


    …あれ、あれ? 実はNEX-5Nよりノイジーなの?

     NR処理が違うのだろうけど、ホットピクセルが多い可能性も?
     てか、NEX-5Tがこんなにノイジーだったのかと、今更知った。 ISO3200が常用だったので気付かなかったよ。
     ふーむ。α7sなら2万5千を常用する可能性があるし、面倒だがホットピクセルを処理を試してみる。


    お、キレイに取れた。こうしてみると、地はキレイだな。 この状態ならNR処理がキレイにかかりそう?

     
     まぁ、結局は星景撮影用なので、光害カットフィルタを用意しないと。
     今回も、LPS-D1を追加で用意して、K&Fのマウントアダプタをバラして組み込みました。

    今回は結構キレイにできたな。

     次は波長感度特性を確認してみようと、簡易分光器を作った。GWの自由工作だな。


    α7sの空き箱にスリットとのぞき穴を追加して回折格子を固定。ハンズで買った植毛紙を貼り付けてできあがり


    ステップアップリングを使ってレンズを固定。   白熱灯のあるトイレで計測会の開催。キャリブレーション用に使う植物用LEDも購入


    キャリブレーション用LED+532nmレーザーを分光計測 →LPS-D1で660nmを引き立たせてHα適性確認も兼用

     さてさて、準備が整ったので、波長特性を測定だ。
     比較対象のNEXに揃えてISO3200、0.5secで簡易分光器を撮影です。


    やっぱりα7sも赤外カットフィルタでHα付近が大幅にカットされてるよ…

     外したNEX-5のIRカットフィルタがHαを20%程度しか透過していなかったことを踏まえると、α7sは恐らく30〜40%弱程度という感じです。 残念。
     まあ、α7sにはフィルタワーク+感度で稼ぐ選択肢もあるし、当面はそっちで楽しむことになりそう。


     あと、ついでなので、高感度番長ならではなやりたかったことを。
     夜空の光害のスペクトルをとってみた。


    α7s、iso10万、30秒。等倍切り出しだとこんなにもノイジーなのか



    ホットピクセル除去処理+NR処理をかける



    コントラスト調整して、ようやくスペクトルらしきものが



    LPS-D1透過させた夜空とキャリブレーション光源を並べてみた


     ふむ、ふむ。知識としては知ってたけど、光害の中身を確認できて、あと対策の効果も分析的に確認できてスッキリ。
     それに、これまで長らく使ってきたNEXとの違いも一通り確認&ワークフロー修正のとっかかりを確認できて、これまたスッキリ。










20160327
@ubuntu歴半年未満の初心者ゆえ

    <ubuntu14.04LTS vs Skylake>
     既に数十回のインストールを経験している。
     いくら慎重に作業しても、何故かGPU・CUDAドライバのインストールで100%失敗するので、そこからのリカバリー手順を手さぐりで蓄積してきた。 お蔭でLinuxの勉強になり、ディープラーニングフレームワークなら安定して動作する環境をきっちり再現して構築できるようになった。
     それでもなお、それ以外の部分でいろいろと不具合が残っているので、とてもではないが常用できるとは思えない、ubuntuとはこんなものなのか、と軽く失望していた。

     そんなある日、数か月前の自分なら絶対に気付いていなかったであろうLinux関係の記事「Skylakeに対応したカーネル4.5がリリースしたよ」を読んで、なるほど、カーネル、そんな仕組みもあったのか、ハタと気付いた。
     これまでも漠然と、「どうやら14.04は最新CPU+GPUの環境には対応してないんだろう」、「その証拠に15.10ならより安定しているし」、「もうすぐ出る16.04LTSなら使えるようになるのかな」程度のことは考えていたのだが、公式にskylakeに対応していなかったのか、と納得。
     ただ、いろいろと試行錯誤してきた中で、「カーネルごと更新する? apt-get dist-upgrade コマンドをしないと14.04は超不安定すぎてまったく使い物にならない」という経験則があったのだが、逆にこの手続きでカーネルは最新に更新されているのだろう、と思っていたのだが、じゃぁ、現状はどうなっているのか全然把握していなかったな、ということに思い至った。

     つい先日にも処理しているので、それならカーネル「4.3」くらいにはなってるのかなー、なんて考えながら、カーネル番号を読みだすコマンドを調べて「uname -r」をタイプしたら、「はぁ?! 3.13?」と目を疑った。
     改めて更新してみても、バージョンは微々たる増加をするのみで、3.14を超える気配は皆無。
     おやおや、イヤな感じだぞ、とWEBを調べてみると、14.04でカーネル4を動かしている人はいなくもないようだが、少なくとも3.17程度なら結構な数の事例があるようなので、手動で明示的にカーネルを指定しての更新方法を調べて、更新してみた。

     案の定、ブートできなくなった…。(一応バックアップを取っておいたのでそれ程慌ててない)

     しかし、他の環境では動いている新しいカーネルが、私の環境だと動かない・更新できないっぽいのは困った。
     この辺りの現象を、「どうやら同じ14.04でもインストールISOにカーネル違いのバージョンが幾つかあって、更新可能な範囲に段階的な制約があるのではないか(つまりWindowsと違って、ubuntuは更新をかけても最新状態で揃わない)」、「強引にそれを越えるとカーネル以外の部分で互換性が失われる・成立しなくなるのではないか?」、とよくわからんなりに推測した。(あと、USBブート環境という辺も、問題をより顕在化させやすくしているのかも?)
     そして、「私がインストールに使っているjp公式ISOは古すぎるカーネルであり、更新の制約を受けている→なので更新しても不安定な状態が続いている状態である」、と強引に仮定した。

     そこで、最近作成されたISOを探してみたところ、カーネル3.19のものがあったので、これでインストールを試みたところ…、ここ数か月間の失敗は一体何だったのかという感じで、蓄積したノウハウを一切必要とせず・スムーズにディープラーニング環境の構築が完了した(してしまった)。

     古いISOだと、こんな↓不具合が生じて、それを補うためにあれこれ工夫していたが、
    ------
    ・そもそもjp公式のインストールISOは立ち上がらない→二世代前のCPUの別PCでインストールしてから改めて環境構築する一手間を追加
    ・CUDAインストールで再起動失敗する→CUDA GPUの載っていないPCで復帰処理+CUDAドライバを手動でいろいろ設定、それでもディスプレイドライバが正常に動かない、CPUパワーが常に食われる後遺症が残る
    ・digits3が正常にインストールできない→解決できなかったよ…
    ------
     これが新しいISOだと一切不要になりました。
     公式のISOが古すぎるのが原因だったのか、ぐぬぬぬ。

     というわけで、「skylakeだとカーネルが3.19ぐらい以降のインストールISOでないと、いろいろ支障がある」、という(Windowsでは考えられな…くもないか)ノウハウ?を今さら思い知ることとなった。
     その場しのぎで辻褄合わせの対策を必死に考えるような、視野の狭さによって生じた超回り道と要らん苦労だったということか…。トホホのホ。(反省)



    <マルチスレッド@chainer>
     度重なるディープラーニングフレームワーク環境構築の過程で、同じサンプルを動かしても、CPU計算時の負荷が100%/60%/20%程度の場合がある、ということに気付いた。
     最初はOSの違いで生じる差なのか、と思っていたが、環境構築の手順が固まってきた頃には100%で処理できる環境を再現できなくなってしまったので、どうやら手順の違いで生じるらしい。 だが、原因が判らん。
     そこで改めて調べてみると、pythonの数値演算拡張モジュールであるnumpyで用いる行列計算ライブラリ:Blasが、インストールしたバイナリだとマルチスレッドに対応していない/スレッド数が固定されているっぽいことが疑わしいと判った。 よくわからんが、他のライブラリであればマルチスレッド対応のものが幾つかあるっぽい&そこから任意のライブラリを自動選定/手動選定する仕組みも備わっていることも判った。
     ならば、インストールだ。
     sudo apt-get install libopenblas-dev
     この結果、GPUの載ってないPCでも、そこそこの速さで処理が行えるようになった!
     スッキリした!
     てか、倍精度計算するなら大抵のGPUよりもCPUの方が速いので、GPUの有無に拠らずこちらを設定しておくべきなんでしょうな。




     以上、初心忘れるべからずの備忘録。



20160109
りろんはしってた


    <虹色トライアングル>
     Colormunkiで身の回りの光成分をあれこれ見える化中。

    紫外線LEDその1とその2


    532nmのクラスIIIレーザーと可視光カット赤外線透過(IR76)フィルタ越しの太陽


    太陽と太陽+ND400フィルタ。


    安定した連続スペクトル光源を求めてトイレで発見。これで演色性Ra=98.2とは、なんだってー>ΩΩΩだ



    白熱電球+NEX-5から外した赤外線カットフィルタと光害カットフィルタ。成程、カットしてるのとしてないの


     これら↑のデータを元にすると、こんな↓特性が判る。


    NEX-5の赤外線カットフィルタと光害カットフィルタの透過率を算出。これがやりたかった




     Hα線は656.28nmなので、NEX-5の赤外線カットフィルタの透過率は僅か10%。そりゃ、写らない筈だな。
     一方光害カットフィルタはHFは80%も透過してるが、赤外も盛大に透過しているのが判る。
     ただ、LPS-D1は赤外はきちんとカットしているものの、このデータだとHαは半分も透過できていない。 まぁ、この分光器の波長解像度は10nmしかないので、鋭いバンドパスはきちんと計測できていない、ということだろう。 こんな解像度が必要な場面があるから、きちんとした分光器は相応に高価なのだな、ということが確認できたわけだろうか。

     だが、よくよく考えてみると、この計測では環境光モードを使ったので、特に多層膜干渉フィルタの計測だと、不均一な壁面からの反射光〜角度特性による誤差が盛大に乗っているのかもしれない? それにLPS-D1はマウントアダプタに組み込んだままで計測したので、これがフード代わりになって壁面からの光量分が幾らか減じている反面で壁面の影響も減じている、と解釈できなくもない。要はきちんとした計測になっていないということだな。



    そこで、速やかに且つ注意深く再計測してみた…あれ? SNはよくなったけど、透過率が100%超してる?!


     光源に白熱電球を使ったので、フィルタなし→フィルタありの二回の計測の時間差によって、電球が温まって光源のスペクトルが変化してしまった、とかあるのかもしれん。速やかに計測すればいい、というわけではないのだな。

     あと、Gの光源にこのレーザーを使ったとしても、実現できる色域はAdobeRGBの118%に過ぎないという事実が判ったことも興味深かった。 逆に言えば、IGZO液晶がAdobeRGB105%もの、レーザーに迫る色域を実現できていることに驚かされたよ。

     ふむふむ、バラバラだった知識が手作業で繋がっていく感覚、なんか楽しいぞー。



    <Windows10上にchainer1.5環境を構築してみたの巻>
     以前、別のPCにchainer1.3を、適切にwhlさえ集めておけばオフラインインストールでもスムーズにmnist実行までたどり着けることを何度か確認していたことと
    既にWindows上にChainer v1.5+CUDA+cuDNNを一番簡単に入れれる方法なる懇切丁寧なインストール記事があるので安心です。
    舐めてました。
       ↓
    今回のインストール先のノートPCは購入直後のWindows環境:Pythonについてはまっさらな環境
    前回はモジュールを個々にインストールしたが、今回はおススメ:Anaconda2-2.4.1-Windows-x86_64.exe で一括インストールすることに
       ↓
    インストールプロセスの最後でエラーが出て失敗してる
    Pythonが立ち上がっても、numpyがimportできない
       ↓
    アンインストールしてリトライしてもダメ
    明示的に管理者権限でインストールしてもダメ
    敢えてユーザー限定でインストールしてもダメ
       ↓
    仕方なく、代替としてPython(x,y)を試すと、インストール完了
    きちんとnumpyなども使える…
       ↓
    はた、とイヤな予感
    確認したらPython(x,y)のPythonは32bit版だった
    アンインストール
       ↓
    Pythonとモジュールを個々にインストールすることに
    先ずはPythonの最新版をインストール
    インストール成功
       ↓
    はた、とイヤな予感
    確認したらデフォルトでダウンロードされるPythonは32bit版だった
    アンインストール
       ↓
    64bit版Pythonを確認してダウンロード、インストール、インストール成功
       ↓
    ここで、ふと、別のアカウントでインストールしたらどうだろう、と思いつく
    別アカウントでAnacondaをインストール
    インストール成功!
       ↓
    元のアカウントでも使え…ねぇ
    やっぱりnumpyすらインポートできない
       ↓
    念のため、別アカウントでAnacondaをアンインストール
    元アカウントでAnacondaを再インストール、何故か成功
    でもやっぱりnumpyが使えない
       ↓
    Anacondaをアンインストール、Pythonもアンインストール
    改めてAnacondaをインストール、成功
       ↓
    やったよ、numpyが使えたよ!
    ようやく環境構築の二歩めに
       ↓
    Microsoft Visual C++ Compiler for Python 2.7のインストール、成功
       ↓
    以前DLしていたcuda_7.5.18_windows.exe をインストール…、失敗
    これはWindows8.1までのパッケージで、Windows10用は別パッケージだった
       ↓
    cuda_7.5.18_win10.exe をインストール、成功
    cudaのサンプルのコンパイル・ビルド可能なことも確認
    ついでにcuDNNも登録、1分で承認、DLしてライブラリとヘッダーのフォルダに追加
       ↓
    さて、ようやくchainerのインストール、成功
       ↓
    chainerのインポート確認…成功
    cupyのインポート確認…成功
    cudnnのインポート…失敗してる。追加フォルダを間違ったかな?
    まぁ、オプションだし後回しでいいか?
       ↓
    train_mnist.pyを--gpuオプションで実行
    エラーがいっぱいで失敗
    どうも「cuDNNが無い」と文句を言われてるっぽい
       ↓
    cuDNNのライブラリとヘッダーをきちんと確認して追加
    chainerを再インストール
       ↓
    やっぱりcudnnのインポートができない
    当然train_mnist.pyの実行は--gpuオプションで失敗
    ちなみにtrain_mnist.pyを--gpuオプションなしなら実行可能
       ↓
    とりあえずcuda関係の環境定数を明示的に指示してみたが改善せず
    手詰まり
       ↓
    Chainer 1.5のインストールがうまくいかない人への非公式なTipsにあった 「pip install chainer --no-cacheを試して下さい」を試す
    cudnnのインポート成功!ありがとう!
       ↓
    train_mnist.pyの実行は--gpuオプションで失敗
    どうやらnvccのコンパイル途中でコケているっぽい
    よくわからんが、cuda関係の環境定数を明示的に指示をいろいろ追加
    手詰まり
       ↓
    「Pythonはレジストリからこのコンパイラを見つけるので、環境変数等の設定は不要です」
    とあったが、 chainer でGPUを利用するメモ(Windows 10)にあったMicrosoft Visual C++ Compiler for Python 2.7のPATH追加を試す
    やったよ!やっとmnistが動いたよ!PATHは必要だったんだよ!
       ↓
    しかし、
    train_mnist.py --gpu 0 の処理時間は92秒
    これがubuntu版だと57秒
    同じPCなのに!
       ↓
    同様にCPU処理の比較をしてみると
    Windows版が2時間20分(CPU負荷18%程度)
    ubuntu版が1時間20分(←これはバッテリー動作させた場合だった。ACアダプタ動作は15分)
    更に、chainer1.3でほぼ同じ性能の別PC(Windows8.1)で700秒(CPU負荷70%程度)
       ↓
    どうやら、chainer1.5のWindows版はまだまだ実装がこなれていないっぽいです
    正式対応でないのは意味があったってことですね
       ↓
    く、くたびれ儲け?!



    <USBブートHDD上のubuntuにchainer1.5環境を構築してみたの巻>
     上記の通り、新しいPCで動くubuntu版のchainerの環境を作ってあるのだが、実はこちらを一旦ギブアップしてからWindows版に取り組み、そちらが一応成功してからこちらにリトライして成功した、という経緯がある。(ややこしい)
     元々は「折角強力なGPUを搭載したPCを買ったのだし、Windows非対応のTensorFlowを試してみたいが、新しいPCをubuntuのデュアルブートにするのは怖いので、USBメモリブートのubuntuでやってみよう」という(cudaインストールは勿論、ubuntuのインストール未経験、知ってるunixコマンドは「ls」だけのレベルの素人なのに)浅はかな考えがきっかけで、艱難辛苦な年末年始の始まりに。
     でも、Ubuntu 14.04.3 LTS に Chainer をインストールする を参考にすれば問題ないよね!
       ↓
     そんなことなかったよ…

     とりあえず、以下は初っ端から最後まで浅はかポイント満載、素人用トラップの全てに引っかかった試行錯誤の経緯をメモ

    先ず、インストール用のUSBメモリを用意…するのが面倒なので、手持ちで死蔵していたISOファイルをハードウェアで光学ドライブエミュレーションしてくれるHDDケース:iodd2501からブートさせようとする
       ↓
    メニューにインストールISOが表示されない
    手持ちの1.8インチHDDやSSDx4を入れ替えて試すが、全てエラー表示
    どうやらこのケースは「普通のHDD」しか使えないという制約があったらしい
    勿体ないが背に腹は代えられないので仕方なく1TB HDDを入れて、ようやくISOを認識
       ↓
    おニューのPCに接続、起動…しない
    最近のWindowsはハードの初期設定を変更しないとダメなんですな
       ↓
    設定変更して、再起動、エミュレーションの光学ドライブを選定、ブート
    起動プロセスの途中で引っかかって失敗
    どうやらこのPC、ubuntu14はダメだが、ubuntu15なら起動できるようだ
       ↓
    TensorFlowは14でないとダメっぽいので、ここで手詰まり?
       ↓
    いや、手持ちで死蔵しているminiPCがあった
    これでインストールISOをブートしてインストール処理した後で、おニューPC上で環境構築すればよくね?
       ↓
    ガラクタ箱からminiPCを取り出して、ubuntu14.04LTSのライブDVDを起動
    おニューのPCにはUSB3.1端子が用意されているのでUSB3.1対応のHDDケースを用意して、SSDを入れて…
       ↓
    そういえば、このSSD、買ってから一度もファームウェアを更新していない、と気付いた
    この機会なので更新しよう、とメーカーサイトを調べてみたら、Windows上からは更新できないっぽい
    CD起動のツールを作成してCD起動・コマンド入力する上に、複数のファームウェアを順に適用しないと壊れるっぽい
    恐る恐る適用、やれやれ
       ↓
    ここでようやくubuntuをUSB-SSDにインストール
       ↓
    おニューのPCでの起動も成功
       ↓
    だがこのPCの内蔵NIC(ゲーム用低レイテンシ)を認識できないっぽい
    出張用のUSB-NICを使ったところWEB接続に対応
       ↓
    システム更新、させようにもコンソールの出し方がわからない(笑)
    スタートボタン相当のメニューらしき機能の使い方もわからない(苦笑)
       ↓
    ググって、「端末」がコンソールとわかる
    システム更新成功
       ↓
    「Nouveau ドライバの無効化」とやらが必要らしいが「/etc/modprobe.d/blacklist-nouveau.conf というファイルを新規に作成」の操作がわからない(トホホ)
       ↓
    ファイル階層構造らしき文言とストレージ操作のGUIプログラムらしきものから、システムファイルの構造や位置をなんとか把握し、どうやら少なくともGUI上からWindowsのマウス操作類推のやりかたで所定の場所にファイル新規作成ではできそうにないっぽい雰囲気、恐らくユーザー権限が原因なんだろうと予想
       ↓
    そして、「blacklist-nouveau.conf」はテキストファイルなんだろう、と予想
    自分で扱うことができるストレージ「ホーム」であればファイルの新規作成ができるようなので、これをテキストファイルだと決め打ちで内容編集、これを上記フォルダに転送すればよさそうという方針
       ↓
    だが、ubuntu上でテキストファイルを編集する手段がわからない(あぁぁぁ)
       ↓
    漠然と「vi」なるエディタがあることは知ってたのでタイプしてみる
       ↓
    …ラインエディタなのかよ!
    仕方ない、コマンドを調べながら編集…、やってられねぇ!
    WEBでGUIのスクリーンエディタを調べて、GEDITに辿り着いてホッとする
       ↓
    やっと編集したファイルを所定のフォルダにコピー…できねぇ!
    これもやっぱりユーザー権限云々なんだろう
       ↓
    ならばコマンドラインで「sudo」を使えばいいのだろうと予想を重ねる
    そしてどうやらcopyコマンドは「cp」っぽい?と予想してタイプ、成功
    やれやれ
       ↓
    ここでやっとCUDAのインストール
    最新版でなく、TensorFlowが対応しているCUDA7.0を選定
    インストール中…あれ?7.5がインストールされてる?
       ↓
    アンインストールして改めて7.0をインストール
    やっぱり7.5になる
       ↓
    今度は7.0のパッケージを丸ごとダウンロードしてオフラインでインストール
    アップデート操作で7.5にされてしまう…もうあきらめよう
    (後から考えれば、アップデート操作しなけばよかったのかも)
       ↓
    再起動
    ログオンパスワードを求められる
    入力すると再びパスワードを求められる(以下ループ)
       ↓
      絶 望
       ↓
    ググってみると、ディスプレイドライバの更新でこんなことになることがあるらしい
    対応策でコマンドラインでログオンして、ファイル操作する、とある
       ↓
    コマンドラインが見えねぇよ!
    (4Kディスプレイに対応してない?)
    手さぐりでログオン、ファイル操作、再起動、絶望
       ↓
    どこかでミスしたんだろう、と諦めて、もう一回新規インストールからやり直す
       ↓
    同じところでログオンループ
       ↓
    3回繰り返す
       ↓
    流石におかしいと気付く(遅い)
       ↓
    ヒラメく!
    どうやらこのPCは特殊なNIC、4Kディスプレイなど鬼門がいろいろあるようだ
    ならば、オーソドックスなお古のminiPCなら起動できるんじゃねぇの?
       ↓
    ログオンループしていたUSB-HDDが起動できたよ!
    ここで気付いたのだが、ログオンループではなくて、画面消灯時の復帰パスワード要求の誤作動だったようだ?
    ともあれ、一旦miniPCで起動した後は、おニューのPCでも起動できるようになった!
       ↓
    .bashrcにCUDAパスの追加…ってなんだよ! そんなファイルどこにもないじゃん!
    よくわからんが、コマンドラインからGEDITで指定してみたら開けた
    どうやら不可視属性のついたファイルということらしい? ええい、イラつくな
       ↓
    CUDAのサンプル一式をコンパイル…失敗
       ↓
    どうやら環境定数がいろいろと足りないっぽいので、ググってそれっぽい環境定数を根こそぎ追加
       ↓
    すげー時間がかかったけど、コンパイル成功!やったー
       ↓
    しかしこの時点でTensorFlowは非対応環境になってしまった
    しかるにchainerの最新版インストールに切り替えることに
       ↓
    Python一式をつつがなくインストール
    chainerもインストール完了
       ↓
    chainerのインポート成功
    cupyのインポート成功
    cudnnのインポートも成功
       ↓
    train_mnist.pyも動作
    train_mnist.py --gpu 0 は…、失敗!
       ↓
    どうやらnvidia-uvmなるGPUドライバが見つからん言ってるようだ
    GPUのドライバがきちんとロードされていない?
       ↓
    確かにdeviceQueryを実行させても同じエラーが出る
    似たような事例ではドライバの再インストールで治ったとかあったが、既に現状で最新版なので
    また手詰まり。USBブートのubuntuはGPGPUのコンパイルはできても計算はできないのか?!
       ↓
    もう一息なので悔しいが、ここで一旦諦めて、デュアルブートに方針転換
       ↓
    そっちも失敗
       ↓
    Windows版のchainerに方針転換
       ↓
    予想外に苦労したけど、なんとか成功
       ↓
    さて、もう一度エラー対策に取り組んでみよう
       ↓
    nvidiaのドライバインストール不良関係の記事を探して、設定ファイルなどの知識を仕入れる
    システムを検索してnvidia-uvmに関わるファイルを探したところ、/lib/nvidia-352/modprobe.confを発見
    ここではaliasなるコマンドでnvidia_352-uvmを呼ぶような設定を意図しているっぽい
       ↓
    だがaliasの設定に正しく反映されていないのが問題の本質なのか?と予想
       ↓
    /etc/modprobe.d/blacklist-nouveau.conf に上のalias一式を追加
    再起動
       ↓
    やっぱりダメ
       ↓
    あ、ひょっとして「sudo update-initramfs -u」なるおまじないが必要?
       ↓
    おまじない、むにゃむにゃ
    再起動
       ↓
    train_mnist.py --gpu 0 成功!
    ヤッター!
       ↓
    もしかすると、インストールの初期段階でおまじないを忘れてたのが、諸々の不具合の原因だったのかもしれないなぁ?



    そんな、こんな、で
    今年の年末・正月休みが潰れてしまったよ・・・



20151120
理屈は知ってた


    <マルチスレッド初心者です>
    KINECTv2で、RGBとDepthを同時に取得↓したものを動画保存しようとしたら、ちょっと困った。

    フレームレートが30fpsを下回ってしまうのだ。
    RGBだけ、Depthだけなら問題ないのだが、両方を処理しようとすると、22fps付近になるよう。
    よくよく調べてみると、録画しなくても、時々不安定になっている。
    ノートPCでは、KINECTv2からRGBとDepthのデータを取得するAPIを呼ぶと、完了するまでに0.045sec程度かかっていて、cv::Videowriter(コーデックはHQX)の.write(cv::Mat)で処理するのに0.02sec程度かかっているっぽい。 しかも、これらはCPUの速度に依存しるっぽいのか、デスクトップだと結構短縮されたりする。
    ふーむ。
    ここはアレか、いままで避けてきた並列処理を試す時が来たのか?
    オフライン処理では不要だったが、今後増えるであろう実時間処理では避けられそうにないし。
    ってことで、ぐぐってみると、一番簡単そうなのがBoostかな? …Videowriterだけの関数を作ってスレッドにしてみたら、あっさり動作した。 へぇ、cv::VideowriterはBoost::threadに対応してたんだ!
    調子に乗って、もっと並列化できるところは無いかなと、更に調べてみると、実はAPIの仕事は0.02secで済んでいて、得られたストリームからcv::Matへ変換する処理に0.025secかかっているではないか。 ならば、ここを並列化するべきだろう。 この時点でCPU負荷は30%と、まだまだ余裕があるのだから。
    しかし、このループはあちこちの配列変数をつつき回しているので、経験値ゼロの人間が並列化するには危険が高そうだ…、ならば、OpenMPでループ丸ごと処理してくれよう、ってことで試す→こちらもあっさり動作して、CPU負荷は100%に! ヤッター…ってことにはならなくて、処理時間は0.002secしか向上してない上に、フレームレート全体の不安定さが増してしまった。 スレッドが増えすぎて、Videowriterのスレッドを圧迫したようだ? ならば、適度なスレッド数を探して指定すれば…、そんなのありませんでした。 やっぱり、ここの処理そのものを適切にするべきという結論に。

     …と、ここに至って、VisualStudioは2015は勿論のこと、2013でもC++11のスレッドをサポートしていたと知って、愕然。 Boostいらないじゃん! またか!(笑)



    <既にMooreの法則@CPUパフォーマンスが終焉しているので>
    5年ぶりのPC更新を、ノートPCにしました。
    そのコストパフォーマンスの低さから、愚か者が買うとの誹りを受ける、アリエンワーことALIENWARE 17。
    しかも、よりによってSkylakeのR3。
    直前までDELL PRECISION M6800と迷ったが、結局、メモリ16GB、SSD512GB、USキーボード、ディスプレイIGZOの4kで注文、納期25日で届きました。


    早速いろいろベンチ。


     事前情報の通り、i7-2600K比較でホントに微増ですが、マルチスレッドの処理は結構向上してる。
     まぁ、それは判っていたので、これからはGPGPUで演算能力UPだぜ!!ってことで、これまた久々のQuadroFX380以来のGPU更新…、したのに肝心のOpenGL描画性能がイマイチ。
     ただ消費電力を計測すると、静的30Wな状態からOpenGLベンチマーク中の+45W(時々ブレる)なのにwaif2xで+85W。 つまり、nVidiaのOpenGLドライバは5割程度に抑制してるっぽいのな。 ぐぬぬ。

     それにHD Graphics530 はかなり強化されているということだが、GPGPUでの演算能力はかなり貧しく、OpenCLで60[Gflops]というところか。 QSVに至っては、i7-2600Kからまったく強化されていなかった。 ぐぬぬぬ。
     ご覧の通り、CPU能力としては完全に低消費電力ラインでの更新になっていて、演算性能はGPGPUで補うという構図が見て取れます。
     ちなみに、ベンチマークを電力効率換算するとこう↓なる。
     こうしてみると、Haswellの効率の良さが光るなぁ。
     skylakeってPen4みたいにintelの黒歴史になるんじゃなかろうか…的な気がしなくもないないのだが、これからは電力効率込みで製品を選ぶ時代になったのだなぁ、と完全には納得できないものの、痛感させられますな。

     それを救うのが、高速なM.2スロットのSSD。
     しかも、背面カバーを外すとM.2スロットが2本あるのだ。(←メーカーWEBサイトの仕様表に記載されていない) SATA接続のHDDも含めれば、将来的には3台のSSDに増設可能なのはなんとも頼もしい。
     そのSSDはシーケンシャルリードが実測1200MB/s超で、これが二台搭載可能というのは、CPU性能はHaswell世代と大差ないか、むしろ電力効率が若干劣るという弱みをカバーだぜ。(ただ、以前のモデルではスロット4本だったそうで、仕様ダウンしたのは残念)
     そして新世代CPUの恩恵であるDDR4のメインメモリも高速で、RAMDISKはリード/ライト共に実測12000MB/sに迫っていて、大容量データの取り扱いでは心強い限り。

     本製品ラインは本来e-Sports御用達で、ゲーム用のプログラマブルなカスタマイズキーが9個装備されていて、さらに切り替えキーでx3倍に機能切り替えを設定できるのが、画像編集やCADなどのソフトでなんとも便利・快適です。ゲーム用の多機能マウスを併用すれば猶更でしょう。
     また、オーデオデバイスをチェックしたところ、ノイズレベルは-94.5dBでしたので、オンボードにしてはまずまずのSN。安心していろいろ使えそう。

     で、最もとんがっているのは17インチで4k解像度の壮絶に美しいディスプレイ装備は、デスクトップのスケーリング設定は200%にしておくことでボケなく使えたものの、スケーリングせずに使ったときのPhotoshopやAfterEffectsなどのツールパレットやGUIの極小さには絶望を通り越して笑うしかないという状況・・・、に対しては、プログラマブルキーにOS標準機能の「拡大鏡」(Magnify.exeを全画面設定※)と終了ショートカットキーを設定・必要に応じて切り替えることで、4kなデスクトップをスムーズスクロールする仮想画面として運用でき、17インチでありながら広大なデスクトップと視認性・操作性を完全両立、むしろ超快適です。 ひゃっほう!
    ※AlienプログラマブルキーはWin+[+]が登録できるけど起動しない。どうやらNUMキーボードのような右側キーは管理が別のようだった。 なので、Magnify.exeは直接起動で登録で対応。 ちなみに終了のショートカットキーであるWin+ESCはキーアサインOKだった。

    妙に鮮やかだな、と4kディスプレイの色域を計測したら、AdobeRGBカバー率105%!sRGB比141%! なんてムダな!

     そうえば、バカみたい(褒め言葉)なイルミネーションですが、照光式のタッチパッドは誤操作防止で実に有益な機能なのだということを、今回発見。 以前から照光式キーボードを使っていたのでこちらの便利さは知っていましたが、やっぱり使ってみないと判らないもんです。 更に、プログラマブルキーも設定セットの切り替えで照光色を変えることができて、これうした機能の組み合わせで使い勝手がどんどん向上。 何事も見える化は重要ということですな。


     実用一辺倒でコストパフォーマンスだけを評価する賢い方にはアリエンワーなアンバランス仕様と価格ですが、そんな賢い方には見えない価値を見出す愚か者(褒め言葉)が工夫しつつ使いこなすのが楽しくなるような、昔懐かしいワクワク感がよみがえるのでした。




    ディスプレイアームに載せることで冷え冷え&空中収納で広々&使いやすさUP



    <Windows7を仮想環境で残しておこう、とVMwareを入れてみた>
     以前もやったことがある作業なので、特に引っかかることもなく…、いや、SP1統合ディスクからのインストールで200以上ものアップデートが必要とか、ここまで時間がかかるのか、と辟易。 結局、5時間近くかかって再起動…、あれあれ、なんか動きが変だ。ギクシャクしてる感じがするぞ?
     CinebenchR15をチェックしたら、CPU速度はホスト機と大差ない。画面表示速度は、まぁ、いい。CtystalDiskMarkを動かして、やっと異常個所を特定。問題はディスクの書き込みが異様に遅くなっていることで生じているようだった。なにしろ、読み込みはホスト機の1200MB/sを超えてて1600MB/sなのに、書き込みが10MB/sとか明らかに異常すぎる。昔のSDカードかよ。
     とりあえず起動パラメータをあれこれ変更したり、ゲストOSの設定もチューニングしまくってみたが、まったく改善しない。 もしかしたら、ホストOSがWindows10だったり、SSDとの相性があるのかな、と今度はHDDにインストールしてみたら、こちらはホスト機転送速度の50%は出ていた。むむむ?
     …ひょっとして、SSDの圧縮フォルダにインストールしたのが原因か?と閃いてので、圧縮設定のチェックを外してみたら・・・、よし、よし、書き込み速度が正常レベルになったぞ。 わかってみれば簡単な原因だった。

    ホスト機のSSD速度とVMware上の仮想HDD速度(異常)、および改善後

     念のため、追試でWindowsXPを圧縮フォルダでインストールしたら、同様の異常(書き込み60MB/sなので若干マシ)が再発して、圧縮設定を解除したら10倍速に復帰を再確認。てか、この確認のためだけに、10倍近いインストール時間をかけたのは、バカか、俺は。



    <すてき!ポータブル分光計>
     子供の頃に観た直視分光器の美しい思い出。
     そんな物欲から、カラーマネージメント用Colormunkiを分光器として入手したのはいいけど、付属ソフトに閉口してジャンク箱に直行させて、はや数年間。
     先日になって分光計として復活させるべし、とのお告げが唐突にあったので、発掘してみた。



    一緒にXP環境保管用のviliv s5を久々の起動。 この組み合わせなら野良ドライバのArgyllも簡単インストール!

     これでスペクトルデータがテキスト保存できるようになったので、簡易のビューワーアプリを作ってみた。 もちろん、直視分光器風の表示は外せません。


    ALIENWARE 17のディスプレイ(白/R/G/B)の測定結果がこんなん



    LEDデスクライト(強/弱)がこんなんだった


     周波数→RGB変換はこちらのテーブルを使って描画。
     x,y色度はCIE-XYZ等色関数から計算。
     Yについてはキャリブレーションデータ値の取得の仕方が判らないので、Argyllの出す数値を基準に定数を作って計算。



    VMware上のXPでもArgyllが動いた!(笑)

     理想的には直視分光器的な運用をさせてみたいのだが、コマンドラインとの連携の仕方がよくわからないので、今のところはこれが精一杯か。
     でも、Argyllはソースコードが公開されているし、ぼちぼちやってみようかな…。





20150711
意外と知らなかったことが多いのだな


    <USBバッテリー>
     先日、USBバッテリーを追加で購入したのだが、なんだか以前から手持ちのUSBバッテリーを加えるとそれぞれの仕様が把握できなくなってきたので、ここいらで整理する頃合いかな、となった。
     ちょいと手間暇かけて実測〜整理してみた。↓

    SANYO KBC-L2A
    カタログ容量:5000mAh
    実測値:3041mAh
    重量:132g
    2010年購入。ボタンで給電のON/OFFが可能なのが実は普段使いで便利。でも、充電電流が0.5A以上のデバイスに使うと息切れを起こして不安定になる。アフリカでアクションカメラの充電に使って満充電できなかったほろ苦い思い出も。今はUSB照明の電源用で余生を送る日々。

    Anker Astro
    カタログ容量:5600mAh
    実測値:4757mAh
    重量:122g
    2013年購入。アラスカでオーロラ撮影用の機材保温電源としてカメラ毎に2個使用。-42℃でもカメラバッテリーを0℃以上に保って8時間耐えきってみせた、撮影旅行の功労者。 今はレンズの結露防止ヒーター用の電源として、年に数回使用。

    Anker Astro2
    カタログ容量:8400mAh
    実測値:6724mAh
    重量:190g
    2013年購入。KBC-L2Aの更新のつもりだったが、ボタンで給電OFFできない、USBを挿しても給電されない(ボタンで給電ONする)で使い勝手悪し。おまけに小電流だと勝手に給電OFFする仕様で、使える用途が異様に狭い。殆ど使用しないまま、未だ死蔵状態。 コストパフォーマンスは良い製品だが、使ってないので最悪とも言える。

    TennRich XP18000
    カタログ容量:18000mAh
    実測値:14176mAh
    重量:515g
    2011年購入。当時としては圧倒的大容量に加えて、19V給電や太陽電池による充電対応が特徴で、震災対応も兼ねて個人輸入の太陽電池パネルと一緒に導入した、が、殆ど使うことなく持て余してた。しかし、ベッドサイドでタブレットを使うようになって、その電源として活用の機会を得た。 だがしかし、これも0.5A以上の給電で不安定となる古い設計であり、効率は低いのがトホホ。

    Anker AstroE7
    カタログ容量:25600mAh
    実測値:20831mAh
    重量:490g
    つい先日(2015年)購入。 たまたま開いたAmazonでタイムセール特価に、うっかりポチリ。 想定用途皆無、使用実績なし。 さて、どう使ったものか。

    MOBILE POWER MP-50000
    カタログ容量:52800mAh
    実測値:47735mAh
    重量:1308g
    2015年GW前に購入。魅惑の超巨大容量に加えて、その12V出力は車用バッテリーの充電にも対応。(但しジャンプスタートはNG)中途半端なXP18000の更新用として(相変わらず用途不明で)導入。 これでキャンプツーリングもムダに安心。 普段はベッドサイド電源として頼もしい限り。


    これらのカタログスペックと実容量をグラフにまとめるとこう↓なる。


     うむ、やっぱり見える化は大切だな、今後の使い方とかいろいろと見えてきたぞ…。



    <この5年間で、GPSロガーってジャンルがほぼ消滅してたんだな>
     上記のデータを整理しながら、バッテリーの劣化についてぼんやり考えていたら、「そういえばもう数年以上放置しているGPSロガーのWBT-202があったけど、さすがにもう、バッテリーが放電しきって使えなくなってるかもなぁ」と、気になってきたので、Windows8.1(64bit)のPCにUSB接続してみた。



    すると、表示されたのがこの地図。 なんだこれ。





    スタート地点を拡大すると、ドバイの空港だった。


     なるほど、どうやら5年前のアフリカツーリングの帰路、トランジットしたドバイ空港でGPSロガーをONにしていたらしい。 そういえば、ラウンジで時間を潰していた時に、手荷物の中にあった機材一式を弄ったような記憶があるような、ないような。(現地のバイクツーリング中に転倒して、幾つかの機材は破損させていたので、その確認をしたのだろう)
     で、位置情報は空港内なら取得できたが、機内でロガーの入った手荷物を棚に押し込んでロストした、という感じか。



    それなら、反対側は成田空港かと拡大したら、なんと自宅までログが残っていた。

     電源ONにしたことも忘れて、12時間以上放置していたわけか。



    成田付近を拡大すると、空港を出て高速道路上で数kmいったところでトラッキングを再開している。

     この時は確か、旅行保険で復路の航空券はビジネスクラスに変更して貰って、空港から自宅まではハイヤーを使ったので、帰国ゲートを出たらハイヤーに直行、即座に移動開始と慌ただしかった筈。 10時間以上前に現在位置をロストしてコールドスタートも同然のGPSロガーにとっては、再取得にこれだけの時間が必要だったということなのだろう。
     他にも、アフリカでの移動ログなどが発掘されるなどなど、なかなか興味深いのだが、それはさておき、GPSロガーがちゃんと動いているのかの確認が本来の目的だった。
     PC接続時の動作を観察すると、勝手にUSB→仮想COMブリッジがインストールされた。 64bit版はなにもしなくてよかったが、32bit版はWEBにつながないとCDCに×がついてダメだった。 うーん、ちょっと動作が怪しい?
     PC本体にはCOMポートが二つあったので(BIOSでdisableにしてあったが)ここではCOM3ができている。仮想COMポートなんだろう。 USBデバイスでよくある仕様だ。
     COMポートをチェックすると、初期設定は例のごとく9600bps。
     TeraTermでCOM3を開くと、既にGNSSメッセージが送られている様子が確認できた。きちんとレシーバとして動作しているようだ。幸先いい。
     この状態で電源ボタン長押しで電源OFFしてしばらくするとmicroSDカードがマスストレージデバイス(リムバーブルディスク)として接続される仕様なので、そこの古いWBT_Tool.exeを最新版(2013年版)に上書き・起動すると、最新の軌跡がGoogleMap連動で表示された、というのが上記地図だった訳だ。
     ちゃんと動いてる…、と言いたいところだが、そもそもMSDへの切り替えが不安定。かなりの頻度で切り替 わらない。電源すら落とせなくなることも多い。がっかり。こうなったら、バッテリーを外すしかない。仕方なく、ファームウェアを最新版の17に書き換えたら、一層不安定になった。やめとけばよかった。 結局、バッテリーを外して、更にmicroSDカードも外して、USBのカードリーダーでPC取り込むのが最速ということになった。

     肝心のBlueToothで接続でGPSレシーバーになるかを試みる。 ペアリング済にはすぐにできるのだが、接続状態を維持できない
     取説によると、どうやら衛星捕捉してからでないとダメみたいだが、試してみてもやっぱりダメ、うまくいかない。イライラする。 惜しいが、まぁ、BlueToothデバイスの接続が不安定なのはよくある話だ。
     結局はまぁ、有線なら使えるなので、ギリギリセーフとする。
     にしても、このサイズで1000mAh超のバッテリーだったのか、と今更驚く。 しかも充電時の電流は0.35A(起動させると0.4A)なので、道理でなかなか満充電にならなかったわけだ。
     買ってから5年以上死蔵させていて今更だが、動作をきちんと把握してみると中々に興味深いデバイスだな、と思えた。


    <GPSデータの見える化>
     要は電子地図。
     上記でGPSレシーバーが復旧したのだが、ターミナルで眺めるだけじゃ物足りない。
     かと言って、GoogleMapなどオンライン地図を参照しようにも、それはパーソナル情報を扱うデバイスの活用はオフラインを旨とする私の主義主張と反する。
     そこで、オフラインでも使える電子地図である。
     実は、かれこれ17年前の話だが、PC用の電子地図が登場した!すげぇ!なんか欲しい!と買った(\6,800)ことがあったのだが、使い勝手はそれほど良くなかったことと、そのデータ量たるやHDDの相当な領域を占有してしまうことでPCシステムのメンテが面倒だとかがあり、さらに数年後には同じデータを使ったGoogleMAPが提供されるようになったことでインストールする必要性がなくなってしまい、今に至る。
     だがしかし、「昨今のタブレットであれば、容量的には十分インストールできるのでは?」と思い立った。 インターネット常接のデスクトップPCなら兎も角として、GPSセンサーが標準で内蔵されてるポータブルデバイスで、通信速度や容量を気にすることなしにオフラインで現在地及び市街地を把握する環境を仕立てることができれば便利なんじゃねえぇの?欲しい!、と思ったわけで。
     そうした地図入りのポータブルなGPSデバイスは既に幾つか持っているものの、より詳細で大量のデータをPC上で連携させることができるようになるのは魅力がある。うん、やっぱ欲しいぞ!
     で、ジャンク箱からソフトを発掘して、手持ちのWin8.1タブレットで試してみれば、なんとこんなに古いソフトでもきちんとインストールはできた。しかも、一応GPS受信機能も動作しているっぽい。



    意匠は今のセンスからするといささかダサいが、十分使える。


     これで万々歳かと思いきや、詳細データのインストールができない。 仮想ドライブにマウントしたCD-ROMを入れ替えれることで詳細データを参照できるが、これは使い勝手が悪い。 惜しい!
     まぁ、Windows98時代のものだし仕方ない、製品寿命だよね、ということで、ゼンリンのWEBサイトを確認すると、現行製品はver.17で、17年前の製品からでもアップデート価格で半額(17年前とほぼ同じ価格で)購入できると判った。 この程度なら、この先の通信料累積に比べたら安いもんだし、地図も最新版になるのなら、と速やかにポチった。
     届いた。
     速攻でインストール…、終わらねぇ! データ量が17年前の5倍になってる! (フォルダ数は約900、ファイル数9000超えで13GB:圧縮ドライブでも11GB) 同規模のWindowsインストールよりも時間的には遥かにかかった。
     デスクトップアプリなので地図操作は基本マウス前提だが、設定変更でタブレットでのタッチ操作も辛うじてできるようになっていて、一安心。 が、マップ移動時の慣性が無いとか、拡大縮小のホイール操作やピンチ操作がGoogleMAPと逆になってるとか、所々で操作感に違和感が…。わざわざ逆にしたのは何故なんだろ?
     それでも、ポータブルデバイスでありながら、光回線のi7なデスクトップPCで操作するGoogleMAPと同等の快適さで地図を扱える上に、標高も表示されて、建物や地形の起伏を含めて立体的な俯瞰視表示(≒GoogleEarth)もできる、なんとも贅沢&安心感です。
     ただ、海外のデータはビタ一文表示されない、完全に日本専用地図という点が17年前から変わっていない、GoogleMAPやGarminの地図データに対して大きく劣りますね。 荒いデータでいいので載せてくれればよかったのになあ、と。
     さて、肝心のGPSですが、初代と違ってツールバー上にGPS設定ボタンのアイコンが見当たらない。マニュアルにも殆ど記載がなく、迷った末に「プラグイン」タブの中に設定ボタン(めちゃくちゃ小さくてタッチ操作困難!)をようやく発見。 このGPSプラグインウィンドウを開いてからGPSレシーバーを接続して、COM番号を指定する(+受信機の測地系を選定…大抵の海外製品はWGS84でしょう)と当たり前に測位開始できました。 地図表示もノースアップからヘッドアップへ自動的に切り替わって、ほぼカーナビ状態に。ただし、ロギングまでは自動という訳にはいかないようです。 あと、このプラグインウィンドウを閉じると測位も停止してしまうのは、少し微妙な仕様かなと思いました。
     あと、タブレット内蔵のGPSデバイスをデスクトップアプリで使えるようにする中継ソフトを購入(paypalで$14.99)してセットアップしてみましたが、GPS感度・地磁気センサーなどの精度は餅は餅屋でWBT-202の方が良いですね。反応が段違い。 それに、内蔵デバイスを使う場合は普段OFFにしているGPSデバイスをONにする操作→中継ソフトの起動→地図ソフト起動→GPSプラグイン起動 という操作が必要で、些か面倒が過ぎる。 無いよりマシなので、非常用という意識で運用するのが良さそう。
     ともあれ、地図デバイス一丁上がり。


    <VivoTab note 8 デジタイザ復旧>
     上記で電子地図をインストールしたのが、発売直後に購入したVivoTabnote8.
     買ってから一年以上使っていなかったが、上記の過程でマウスの代わりにと久々に使ってみたら、まったく認識していないことに気付いた。 いつの間にか故障していたらしい。
     調べてみると、リコール相当の不具合の症状だったと、今更知った。ユーザー登録してないから、連絡が来なかったのか。
     メーカーに送り返すのも面倒だったので、こちらで自力補修する手順が丁寧に紹介されていることだし、その通りにやってみた。



    ふむふむ、これが問題の断線しがちなフラットケーブルか。


     ひっこぬいて、通販で届いた新品のケーブルを挿して、…あれ、幅が違うぞ?あれ??
     アーッ! 問題のケーブルは逆側にあった! これ、タッチパネルのケーブルか!
     元に戻して再起動してみると、案の定、タッチパネルが反応しない。 デバイスマネージャでエラー(43)が出ている。 何度挿しなおしてもダメ。 仕方なく、テスタで導通を確認してみたら、グランドが断線しかけている。 折り目を変えたらなんとか導通するので、その形で収納。 
     但し、そのままではエラーは解消しないので、一旦disableにして、改めて有効にして、ようやく再認識。 やれやれ。  ここでようやく、肝心のデジタイザ側のケーブルを交換。 こちらも案の定、断線しかけてました。



     電源投入して、デバイスマネージャーOFF・ONでやっとこ復旧。 やれやれ。

     ついでに、ドライバーにWacom版をインストールして、筆圧対応に。 用途は皆無だが、なんかちょっと嬉しい。




    そんなんこんなんで、あれこれ復旧・メンテ&いじり倒しながら、自分の所有物への理解を深めるのは、意外と楽しいな、という話



20150525
実は役に立つサンデープログラミング
     その昔、「マイコン」と呼ばれていた頃は、コンピューターを使う=プログラミングだったものだが、大勢の人が使うようになって以降、用途に特化した機能のプログラムは大抵誰かが提供してくれるようになって、使い方が高度化したこともあって、すっかり受け身な姿勢が当たり前になっている。
     が、コンピューターの運用と日常生活とが一層密接に関わるようになってくるに従って、そうした既成品ではカバーされない更なるローカルニーズ特化した機能が欲しくなるような時代が来ているのではないか、という気がする。
     日常生活上のコンピューター運用に対して、DIYな工夫を行うことでいろいろなことが解決・効率化できるのだと、今更発見した今日この頃。



    <意外と簡単だったVFRビデオのAVIUTL編集(つまりVFR→CFR変換)>
     自前のアナログビデオ(テープ、LD)のデジタル化が完了して既に10年が過ぎた。
     しかしながら昔はストレージ容量ケチケチ使っていたので、ビデオファイルを可変フレームレート:VFRで作成していて、折角のライブラリだが再編集が困難という問題を長年抱えていた。
     CFR(固定フレームレート)が前提のAVIUTLは言うに及ばず、AfterEffectsなどどの手持ちの編集ソフトを使っても音ズレなくVFRビデオを編集することができないのが悩ましいのだ。
     トリミング編集なしの丸ごとであれば、リサイズやクロップしてから再圧縮するような手段はいろいろとあるのだが、私はトリミングしたいのに!
     だが先日になって、VFRビデオから作成したタイムコードファイルをなんとなく眺めていたら、

    「・・・あれ? これって、簡単なプログラムでCFRに変換できるんじゃね?」

     と、ようやく気づきました。
     つまりVFRのビデオファイルを直接編集するのを諦めて、タイムコードを使ってCFRの中間ファイルを作ってから編集することを許容すれば、結果的にVFRビデオが編集できると気付いたのだ。
     そう、改めて現在のPC環境を見直してみれば、RAMDISKのサイズが数GBもあるのでこのサイズであれば中間ファイルの画質低下は知覚不能レベル、更に処理速度向上で中間ファイルへのトランスコード時間もいまや実時間以下なので、このアイデアは十分に現実的になっていたのだ。 ケチケチしていた昔と違うのだ。 今や動画のハンドリングは格段に簡単になって、制約が無くなっているのだから発想を変化させていく必要があったのだ。
     うむ、よし、やってみよう。
     使うのはVFWでもDXライブラリでもPythonでもなんでもいいのだが、OpenCVがffmpegのフロントエンドとして汎用的で便利そうなので、とりあえず、これがよかろう。
     まずは、cv::VideoCaptureのvideo_VFRからVFRビデオをcv::Matのframe_tmpにキャプチャできるように設定して、前準備でDtsEdit.exe等を使って作成したタイムコードをdouble TimeCord[]に格納、cv::Videowriterの出力をvideowriterに設定した上で、以下のコードを実行。
    -------------------------------------------
    int flamecount_VFR =1, flamecount_CFR = 1;
    for(;;){
     video_VFR >> frame_tmp;
     if( frame_tmp.empty() ) break;
     while( (double)flamecount_CFR * 1000.0 / FRAME_FPS) <= TimeCord[flamecount_VFR] ){
      videowriter << frame_tmp;
      flamecount_CFR++;
     }
     flamecount_VFR++;
    }
    -------------------------------------------
     やってることはごくごく簡単、設定したCFRフレームレートで新たに作成されるCFRタイムコードをVFRタイムコードと1フレーム毎に比較することでドロップしているフレームを見つけて前のフレームを繰り返す、といった処理を最後まで繰り返してるだけ。(本来なら、ドロップフレームが連続するようなシーンなども想定できるのでもう少し丁寧な補間が必要だろうが、とりあえずは無視している)
     変数FRAME_FPSは、OpenCVが読み取るVFRビデオのフレームレートで、これはどうやら冒頭部分フレームレートらしい※ので、ここではこれを最後まで持続させる:つまりこの値のCFRにするものとして処理してます。 (ここに4倍の値を入れている場合があるので、適宜割り算して適正な値にするとかも、ついでに処理)
    よって、CFRビデオの全フレーム数は FRAME_FPS*VFRビデオの最終フレームのタイムコード/1000 になるわけです。
    ※ちなみに、VFRビデオをAVIUTLに読み込んだ時に示されるフレームレートは、ビデオファイル全体の平均フレームレート:全フレーム数*1000.0/VFRビデオの最終フレームのタイムコード になっているようです。ふむふむ、なるほど。
     こうして無事出来上がったCFRビデオファイルには音声データが無いのだが、編集時には元となるVFRビデオファイルを音声ファイルとして読み込めばOK! 完・璧!
     これで長年の懸案だったVFRビデオ編集を、正味部分が僅か10行のコードで解消することができてしまった!
     てか、いかにせよ余りにも簡単すぎる。 この程度の処理を行う手段が世の中に無かった筈が無い。 結局のところ、こうした機能が既存の編集ソフトやツールに実装されていることを私が見逃しているに違いない、という思いを強くした。…こうして解決策が判ったことで視野も広がるというかなんというか、L-SMASH-Works のインポーターにVFR->CFR変換のオプションがあることにこのタイミングで気が付いた。うん、まぁ、案の定でしたな(笑)
     ともあれ、長年の懸案が解決してスッキリしたナリよ。


    <手間がかからないIEキャッシュからのデータ保存>
     IE11のキャッシュは\Temporary Internet Files\Low\IE\に随時生成される多数のサブフォルダのどこかに保存されるようになってしまい、探すのも一苦労である。
     いや、まて、人間様が手間暇かけて探すのでなく、こんな単純作業こそプログラムでやるべきなのだと漸く気付いたのがついこの間。 受け身で思考停止していたらカイゼンは進まないのだ。
     普段ここでやっている作業内容を書き出してみると、実にプログラムにしやすいことも判った。
    (1)サブフォルダを開く
    (2)ファイルサイズ順にソートする
    (3)ファイルサイズとタイムスタンプから所望のキャッシュデータを探す
    (4)該当するデータが見つかれば適宜リネームして保管フォルダに移動する
    (5)以上を全てのサブフォルダで繰り返す
     こうした処理内容なら、例えばVBSなどのスクリプトが向くのだろう。
     が、敢えてC++でやってみよう、ということで参考になりそうな情報をGoogle先生に訊いたらこちらこちらを紹介して貰えて、ここから必要なコードをコピペしたらあっという間に出来上がり! マジか、素晴らしい!




    <備忘録:CPU性能>
     こんなページのこんな図↓が面白いと思った


     2003年前後にCPUの動作周波数がサチった様子が一目瞭然です。(と、DECのオーパーツっぷりが懐かしい!)
     これに、以前整理した歴代所有PCの性能↓を突き合わせてみると、CPU速度鈍化のタイミングが完全に一致。

     2003年以前は動作周波数の向上でブーストされていた速度向上が、以降はアーキテクチャの改善やマルチコア化のみに依存しているのだな、と察することができます。
     そうなると電力効率のグラフも見たくなる。 どこかにありませんかね。




     そうそう、Visual Studio Expressでもオリジナルのアイコンを設定できることを、10年間気付きませんでした。 もう廃止目前なのにね。
     「ORG_ICON ICON DISCARDABLE "org_icon.ico"」こんな感じのテキストファイルを.rcで保存して、.icoファイルと一緒にリソースにドロップするだけで良かったなんて。
     このやり方でコンソールアプリにもアイコンが設定できるので、素っ気なかったOpenCVアプリが賑やかになりました。(笑)



20150425
備忘録いろいろ


    <TOFなのにこんな横長なのはマイクアレイのせい?>
     KINECT for Windows V2 セットが販売終了する! という報道があった(5月追記:廃版になってました…)ので

     慌てて買った。

     MSのショッピングサイトを使うのは初めてだったが、Amazon並みに中一日で届いた。
     で、ご覧の通り、本体は初代より幾分コンパクトだが、接続ケーブルは昭和な懐かしさを感じさせるぶっとさで、巨大になったPC接続アダプタなどなど、全体にごっつくなってます。 消費電力30W超えるのかよ!

     この銘板はもうすぐ無くなってしまうのか。 あと三脚用ネジ穴と冷却ファンがあることを初めて知った。

     SDK付属サンプルからは、OpenCV用のコードが無くなっているのが残念。 そもそも以前と違って、SDKをインストールしても、ヘッダやライブラリのフォルダパスが追加登録されないし、VisualStudioの設定も変更されず、アプリを作るなら全部自分でやないとダメなのは、まぁ、良し悪しだけど、インストール時に一言欲しかったな。
     それはさておき、V1のAPIと全然違っていてコードレベルの互換性はゼロという潔さとか、うっかりアプリを複数立ち上げたら正常に動いてて驚いた。
     VisualStudioとOpenCVでカラー+デプスを同時取得して並べて表示するアプリを作ってみたら、

    こちら↑がKinect V1で

    こちら↑がKinect V2

     RGBとDepthとで取得する範囲が違うことに気付いた。 これって使いにくいかも?
     あと、SDKをインストールすると、KINECTを接続してなくてもサービスが常駐する↓ようだ。



     PC起動直後で55MB程メモリを喰っていて、KINECT接続〜取り外し後は140MB程度になるようで、CPUリソースも時々喰ってる。 接続時のダイアログがなんか変だったりと、まだ実装がこなれていないという印象です。
     てか、v1を久々に動かしたら、作ったアプリがPCによってエラーが出たり動きがおかしかったり。 ぐぬぬ。



    <超スマート(5mm!)の夜露防止ヒーターでカメラレンズの結露対策【自作】>
     星景撮影では状況次第で割と重要というか不可欠な補助部品である結露対策のアイテムだが、これまでは既存のUSB保温製品を流用↓してその場しのぎしてきたものの、

    こうした前世紀から一向に進歩のないバンド構造だと、レンズ胴への固定や断熱の機能部品でピント調整が使いにくくなるなど運用上の不具合があるのに加えて、どう考えてもムダな場所を温めたりで熱損失が多すぎる・結露が消えるまでに随分と時間がかかるなどなど、不合理性が満載で不満であった。
     ここいらで合理的構造のスクラッチをしてみようかな…、とあれこれと考えた結果、ニクロム線をリング状に仕込んだレンズプロテクター、という産業機械エンジニア的発想による直球且つシンプルな構成を考案して、材料を通販ポチリ、


    で、ちょろん、と工作 この構造なら断熱部品なし&省電力で効率よく結露を解消



     装着したままフードの着脱や逆挿入も可能で使い勝手良好。 フードを付けた状態+屋外での発熱はこんなん




     給電ケーブルは、もう使わなくなったminiUSBケーブルに小型の車載用コネクタ改造で、こちらも着脱可能に




     試作時のテスト風景。 コネクタ部が地味に発熱してることに気付いた


     費用はニクロム線+熱収縮チューブで500円ぐらい、細線用コネクタが200円、これにレンズプロテクターのピンキリ円です。 ちなみに今回はネジのアゴ部分にニクロム線の収まりがいい溝が確認できたマルミ EXUS ハクバ ULTIMAを使いました。
     USB給電で0.4〜0.5A程度(これでも多すぎたかも?)なんで、給電ケーブルは細いものが使えて取り回しが良くなるし、5000mAh程度の小型USBバッテリーで10時間ぐらい:既製品の倍使えるようになった。 なのに、熱容量が極小だからあっという間に結露解消、といいことづくめ。
     鏡筒やフードにニクロム線を仕込む案も検討しましたが、エネルギー効率や運用しやすさを考えると、いまのところ、この構造がベストなのでは。
     カメラレンズ限定で、且つ魚眼には使えない構造(且つレンズプロテクターを許容できない人の存在や、その価格分上乗せがあるの)ですが、この範囲であれば旧来の製品よりも運用性に優れたものになりました。

     お手軽工作で運用性UP、満足、満足。





20150301
備忘録いろいろ


    <価格破壊>
     技術系・研究系のスジでは避けることができないのがMATLABで、私もその類に漏れず、かれこれ20数年の付き合い。
     「専門性が高く高価なので、業務で使用するのはまだしも、自腹で買うには至らないソフト」カテゴリーの典型ではあるが、その中でも比較的一般に近い辺りがポジショニングかな、と思う。
     で、そのMATLABに個人ライセンスが新設されて、しかも価格は1/20になったと聞いて、まぁ、この値段(≒WindowsOS)なら少々使用頻度が低くてもいいか、ということで

     買った。

     使ってびっくり、この価格ならば機能制限やネット常設限定制約があると思っていたら、そんなことはない、フル機能・スタンドアロン使用OKだった。 ひゅー!
     ついでなので、この手の用途で最低限必要Toolboxとしてイメージと統計用を二つつけた。 Simulinkは、ま、いらんか。
     この状態ではFreeMatと大差ないけど、人様のコードを参考にする際に細かい面倒が少ないのは安心感がある。
     あと、Pythonに比べるとCに近い感じが落ち着く(笑)のとか、コメントに日本語を書けるのが高齢者にとってはじわじわ助かるなぁ、などとしみじみ思うのことよ。
     うーん、こう言うと、ちょっと後ろ向きだったか。




    <OpenCV2>
     そろそろ3が出る?せいなのか、イメージ操作のコードでver.1のままだと誤魔化しきれない場面が増えてきた(謎のエラーで落ちる環境がある)ので、去年辺りから少しずつcv::Mat に置き換えるように心掛けている。
     そこで何故か、「画像の一部を切り出して、別の画像にペーストする」という超基本的な操作のコードで、正解に辿り着くまでに随分と引っかかってしまった。
     ---
     cv::Mat M1(ORG, cv::Rect(x1, y1, s1, s2)); //画像MatのORGからx1,y1を起点としたs1×s2サイズ矩形をM1に切り出して
     cv::Mat M2(IMG, cv::Rect(x2, y2, M1.cols, M1.rows)); // ペースト先画像MatのIMGにペースト位置を参照するMatのM2を用意
     M1.copyTo(M2); // M2を経由してM1をIMGにペーストする
     ---
     なぜにこんなところで、と我ながら不思議だったのだが、「こんなイメージ操作は関数一つに纏めたものが用意されている筈」という思い込みがあったのが敗因か。
     印象深かったのと、反省も兼ねて記録しておく。
     でも今後のマシンビジョン関係は、NVidia謹製の開発環境に移行するのがいろいろと早道になるかもしれないな、と少し思ったりも。




    <ダメ人間製造機>
     日本古来からダメ人間製造機といえば「炬燵」であるが、昨今はよりワールドワイドに危険な「タブレットスタンド」なんじゃないか、と思う。
     ベッドサイドに取り付けたら危険度MAXだ。

     取り付けた。

     貧乏くさい不格好家具の最たるものだが、機能は必要十分で、ダメ人間生活の華々しいスタートです。
     だがしかし、このタブレット用のスタンド、ディスプレイ用アームと違って水平回転の動きが非常に重い。 取り付けた状態でタブレットを操作するための仕様なのだろうが、これでは寝起き時に脇へ一時退避させることで手間取ってします。 ダメ人間が眺めるだけの用途には使い勝手が悪い。
     そこで、簡単に水平回転をできるように小細工してみた。
     まぁ、取り付け部にテフロンシートを貼り付けただけなんですけどね。
     それだけだと、動かす際に取り付け部が外れてしまうので、回転中心に木ねじをつけてワッシャーを追加し、クランプ金具が凹断面であることを利用したストッパとして機能させるようにしました。
     うむ、よし、快適じゃ♪




    <温度の見える化面白い>
     向う数年で一般に普及が進むアイテムだと思うのだが、安価なサーマルカメラの初物を入手した。


     しかし手持ちのAndroidタブレットだと、USBコネクタの向きが悪くて逆さ自撮りになってしまうので、
     手持ちの延長コードや変換コネクタを駆使して

    180°反転させてみたり、90°向けてみたり。(意外と後者が使いやすいかも)


    真っ先に撮るのは手でしょうな。

    イメージ通りでしょう。

    これを画像処理してみると、206x156しかないセンサー解像度をうまく補間していることがわかる。

    これは電子レンジ内のBefore/After


    ちなみに同じく電子レンジ内をフィルター越しに見るとこうなる。

    左がKenko PRO1Digitalプロテクター(透明)、右がFUJIFILM IR76(赤外線透過フィルタ)

    やっぱGeとか特殊素材でないと透過しないのね。

    で、こちらは冷蔵庫(庫内を正面視)と冷凍庫(庫内を俯瞰視)

    あっという間に冷気が逃げていく様子が観察できました。


    稼働中の小型PC(Shuttle XH81)と電気ひざ掛け

    最近のPCはホントに発熱しないね。 ひざ掛けはハッキリ見える電熱線がキモイね。


    さて、これはなんでしょう。

    正解は、フロアリングを歩いた跡。 あと、USB電流計越しでもきちんと動作。 0.05A以下の低電力で稼働してました。

    厚手の靴下を脱げば、もっとハッキリしそう。


    ・廉価版だけあって高価なGeレンズが使えないのは仕方ないとしても、代替レンズの性能が酷い。画角が狭く、撮影範囲は2m程度が限界。XRを買えということか
    ・メーカーアプリで動画もMP4録画できました
    ・タイマーシャッターが無いので全身の自撮りができない。動画で撮るしかないが、この時は変換コネクタで延長したことが吉となる
    ・SDKが後日公開予定ということなので、もうちょっと特化したアプリを作ってみたいな
    ・てか、Windowsでも動けばいいのに!