The inner of [Ti]
MISCELLANEOUS '15-

20171030
バカにつける薬



20170803
光とか赤外光とかレーザー光とか



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でも動けばいいのに!