2桁高速化を目指す

https://www.nicovideo.jp/watch/sm34367245

46日目来てた。クリスマスプレゼントだな。
ブーストバックして再突入するところが自動化された。

多分、同じ計算をカービンに戻ったときにも行って、
精密にピンポイント着陸するってことなんだろうな。
ってことは、KSCにピンポイント爆撃とかも可能か…。




相変わらず、Python、Pillow、tkinter使って画像処理
するプログラムの方をゴニョゴニョ。

640×480くらいの画像で、現状は1枚4分掛かっちゃうん
だけど、アイデアメモを描きながらあれこれアイデアを
整理してて、ざっくり1桁以上速く処理する方法を狙って
いたんだけど、よく考えたら、2桁ほど速くする方法も
可能なんじゃないかな、と思いついた。

これから実装してみるにしても、1桁も2桁も、処理内容
自体は大きく変わらないので、どうせだから2桁速い
方法で進めてみよう。





https://factory.pixiv.net/products/masking_tape

マスキングテープって、オリジナル品が簡単に発注
出来ちゃうんだな。へぇ。Pixivで頼めるらしい。

https://factory.pixiv.net/

他にもいろいろあるのか。




https://this.kiji.is/449853709708919905

インドネシアの、クラカタウ噴火の海底地すべりの津波。
被害が大きそう。
それにしても、地震だけじゃなく、津波アラートが機能
しないと、逃げるトリガが無いよな。




そういえば、

https://ja.aliexpress.com/item/Usb-30000-mah-Powerbank-iphone-samsung-xiaomi/32947138695.html

aliexで薄型モバブーがサジェストされてたのを見て
思い出したんだけど、Daisoで500円のモバブーが
売ってたんだよな。あれ、どうなんだろう？と思って
ちょっと検索。

http://radiopench.blog96.fc2.com/blog-entry-811.html
http://radiopench.blog96.fc2.com/blog-entry-812.html

おぉ。ラジオペンチさんのブログで詳細に解析されて
いた。そういえば、見た記憶があった。改めて
眺める。すばらしい。

一番気になってたのは、ある程度電流流さないとシャット
オフしちゃうのかどうかのあたり。ラジオペンチさんの
ブログによると、最小20mAということなので、Arduino
くらいでもなんとか動作し続けられるんじゃないかと
いう気がする。
300円モバブーのような妙なディップも無いらしいので、
マイコン用の5V電源としては、結構良さ気に見えてきた。
リップルが気になるところだな。ちょっと大きめな感じ。

Gambas、弄ってみた

https://twitter.com/LmmRez/status/1076348767266168837/photo/1

ニッポンは、思ってた以上に広いなぁ。

それにしても、軽自動車なのにタコ付いてるし、
9000rpmまで振られている。日産って、そんな軽
あったんだっけ？

トレーラーとか消防車とかの燃料が気になるよな。




Gambas、Lubuntuに入れてちょっとだけ弄ってみた。

http://gambaswiki.org/wiki/install/ubuntu

標準のリポジトリに入って無いので、Gambasのりぽを
追加してから、apt-getで普通に入る。特に面倒なこと
はなし。

実行してみる。



おぉ。日本語が表示されてる。マルチバイト対応されて
いるみたいだなぁ。へぇ。

サンプルプロジェクトもあるみたいなので、ちょっと
試してみた。

マインスイーパ。そのプログラム。なんとなくVBっぽい。



実行してみる。



さくっと動いた。
へぇ。おもしろいねぇ。

言語リファレンスが使いやすければ、しばらく使って
みたいところなんだけどな。

そういえば、これって、Linux、BSD系だけじゃなく、
Windowsでも使えないのかなぁ？




https://support.mozilla.org/ja/kb/new-thunderbird-60

つい何も考えずにThunderbirdをアップデート。60に
なった。大規模アップデートなのに何も考えずに
アップデートしちゃって、ちょっとあとからびっくり。

見た目がいろいろ変わってるのは、それほど大きな
影響なさそうかなぁ。
問題は、一部のアドオンが動かないっていう点。

オイラ、Dorando keyconfigとか入れて、キー設定を
ちょっと弄ってたりしてるから、その辺が気になる。
だいじょうぶかなぁ？




https://twitter.com/felis_silv/status/1076150696188162048

あぁ、そういえば、Microchipのコンパイラ、最適化
でどのくらい変わるのかを一度調べてみようと思って
いたんだけど、すっかりPICマイコン触ってないな。





https://twitter.com/sobamix/status/1069201827705454592

Ys2。
最初、いったい何が起こったのか全然理解できなかった。
びっくりした。

https://twitter.com/BLUESOLVALOU/status/1069261294430121985

なんか、あまりにすごいクオリティー。部分的には
オリジナルを超えているといってもよいのでは？

多重スクロールも圧倒的。




https://twitter.com/260yamaguchi/status/1076411735672684546

日本のマスメディアがマスメディアとして機能して
いないのは、総務省の首根っこをつかんでる人間の
素性によるんじゃないかな、という気がする。
なので、内部からは変えられないだろうな。

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%8B%99%E7%9C%81

調べてみると、管轄になっている特殊法人は、
　「日本電信電話株式会社、東日本電信電話株式会社、
　　西日本電信電話株式会社、日本放送協会、日本郵政
　　株式会社、日本郵便株式会社」
ってなってる。NTTももしかしたらヤバイのかもしれないな。




https://twitter.com/Dgoutokuji/status/1076677696178900992

「平成が戦争の無い時代」って言う言葉にはグッとくる
ものがあるよな。
ただ、平成のしょっぱなから日本は湾岸戦争に加担して
いたことはしていたんだよな。

そういえば、「平成」っていう年号を変える必要って、
なかったのか。”歴史と伝統”と称する明治以降の
「歴史と伝統」なんて、せいぜいここ100年くらいの話
でしかないんだな。夫婦同姓の話もそんなだったな。




https://www.jiji.com/jc/article?k=2018122300363

これはひどいな。火器管制レーダーって、気象レーダー
とかとちがって、火器を使う前提で照射するはずで、
以前中国がやって大問題になったんだけどな。

https://ja.wikipedia.org/wiki/%E4%B8%AD%E5%9B%BD%E6%B5%B7%E8%BB%8D%E3%83%AC%E3%83%BC%E3%83%80%E3%83%BC%E7%85%A7%E5%B0%84%E4%BA%8B%E4%BB%B6

火器管制レーダーを使われたら、その次の瞬間には
砲弾が飛んできても不思議じゃないわけで、命に
文字通り命に関わる事態なんだよな。

敵国以外に照射する事の無い威嚇を行う国と、同盟は
組めないと思うんだけど。背中をズドンと打ってくる
相手とは同盟は組めないよな。

Gambas

あいかわらず、Python3、tkinter、Pillowを使って、
ブギーボードもどきの撮影画像をきれいに加工する
ツールを進めてるところ。

一方で、そういえばubuntuで使えるGUIプログラムの
開発環境で、RAD環境が使えるもの、PythonやRubyに
限定しなければ、何があるんだろう？と思って調べて
みた。


https://ja.wikipedia.org/wiki/Gambas

Gambasっていうのがあるのか。日本語情報が無いって
ことは判った。ってことは、もしかしてマルチバイト
対応されていない可能性もあるって事か？

それあはまぁいいとして、例によってGambasとやらを
使って開発している動画なんかを探してみる。

https://www.youtube.com/watch?v=-aO7RK1UYHU

あった。
電卓を作成する風景。もう、まるでVBっぽいね。これ。
まんまVBだな。これはちょっと弄ってみたい。
まぁ、言語自体もやっぱりBASICなんだけどな。

「Qt/Gtk+に対応したGUIデザイナ」って書いてあるん
だけど、これ、Qt使う前提なのかなぁ？
Gtk+使うのなら、Gtk+のライセンスになるんだろう
けど。

https://mag.osdn.jp/12/01/06/1115253

QtかGtk+かどっちかを使う風に見えるんだけどなぁ。

なんにしても、SQLやネットワーク、グラフィック処理
などなど、いろいろ一通り使えるみたいだな。




http://fanfun.jaxa.jp/topics/detail/13744.html

イプシロン4号機、1月17日打ち上げらしい。




https://www.jiji.com/jc/article?k=2018122107118

陛下、免許証返納されるのか。なんか残念な気持ちだな。

オイラ、あのDA型インテグラ乗ってたから、思い入れが
有ったりするもんな。

https://www.youtube.com/watch?v=cvAMDv7jcfU

B16Aの、芳しい音がする。




ちょっとGIMPを弄る。そうけば、Windows環境でGIMPを
弄るとき、いつも起動で2～3分掛かるんだけど、ubuntu
やLinux Mintではそんなに掛からないので、何でかな？
と思ってた。

調べてみたら、環境によってはそういうことが起こる
らしい。フォントの読み込みに時間が掛かっている
らしくて、その場合、終了時にも、サブウィンドウが
閉じるときにやっぱりすごく時間掛かるって書いてる。
そうそう。うちの環境がまさにそれだ。

というわけで、対処方法を試してみた。

まずこの方法。

https://qiita.com/SkyLaptor/items/7d0dd48cd530ae8f1b83

→上手くいかなかった。

次。この方法。

https://kiritsume.com/how-to-make-gimp-start-faster/

→上手くかなかった。

次。この方法。方法2って書いてあるほう。

https://nyanshiba.hatenablog.com/entry/2017/08/20/195619

→上手くいった。なんかこの不思議な方法で、なぜか
上手くいったなぁ。何でだろう？


まぁ、なんにしても、起動するのに時間が掛かって面倒
だったGIMPが、さくっと起動するようになってホクホク。
終了処理も一瞬で終わるようになった。
めでたい。



youtubeのお勧めで、ルービックキューブを買うなら
どれがお勧めなのかっていう動画が。

https://www.youtube.com/watch?v=e-Ob7n7jBG0

この、8分くらいに登場する、3000円くらいするヤツが
すごいよさそうな感触だなぁ。いいなぁ。

オイラ、ちょっと前に1個買ったんだよな。過去の日記
を振り返ってみると、1100円くらいだったみたい。

https://brown.ap.teacup.com/nekosan0/2526.html
https://brown.ap.teacup.com/nekosan0/2511.html

これはこれで、大きさ、重さ、回しやすさ共に悪くは
無いんだけど、「上→右」みたいな回し方を急激に
行う際、完全に上を回しきってない（もしくは少し
過ぎてしまった）ずれた状態で右をまわそうとすると、
ズレが大きい場合に、1回2回、空中分解してしまった
ことがある。これが無ければ完璧なんだよな。

そこ行くと、さっきの3000円のやつは、そういう場合
にかなり追従するみたいだな。

その辺の感触によって、タイムがずいぶん変わってくる
んだよな。

高速化を考える

昨日に続いて、Python3、Pillow、tkinterを使っての
画像処理。高速化をちょっと進めていく。


640×480ドットの画像1枚処理するのに15分ほどかかって
しまっていたので、まず、Pillowのputpixel、getpixelを
大量に使っているところを、アクセス速度がもう少し速い
リスト形式にいったん変換かけて、そっちにアクセスする
ように変更してみる。

…とりあえず、それだけでも15分から4分まで短縮できた。
4倍くらい速くなったんだけど、まだまだだな。

やっぱり、計算量を減らすことが必要だ。計算量を一桁
減らすことは可能なんだけど、ちょっとめんどいのと、
それでも減っても一桁くらいだとすると、ざっくり2～30秒
くらいはかかっちゃうのかなぁ…


あと、塗りつぶし状態の絵を描いた場合に、その周囲との
平均を求めると、塗りつぶしたはずの図形が黒く抜けて
しまうことになりうるので、その辺の手を入れてみる。

頭の中に思い描いていた、RGB各プレーンの扱いをゴニョゴニョ
すればうまくいくだろうと思っていたんだけど、実際に計算
処理に組み込んで実行してみると、前の計算方法と同じ画像
（と思われるもの）が出てきちゃった。
へたにいじると、光がさして明るくなっているところの評価値
が下がっちゃって、無駄なドットが現れちゃうし…。

なかなか難しいな。人間の目（と視覚をつかさどる脳）は、
どういう風にこの辺を処理しているのかな？


とりあえず、もうちょっと格闘しないと、期待した図柄は
得られないみたいだな。
そもそも、現在は実数値で内部計算していると思うんだけど、
そんな精度は必要ないんだよな。計算精度低めてでも、速度
上げたい場合って、Pythonって何か方法ないのかな？


あと、昨日までのアウトプットの図を改めて見直してみると、
一部の線が拾えてないことに気づく。
なんだこれ？と思っていろいろ考えを巡らせる。

多分、周囲に線の色の濃い図形があるせいで、周囲の平均値
が高くなってしまっていて、薄く描かれた線が（数値としては
暗いので）平均値を下回ってしまい、ドットとして拾えて
いなかった（捨てられた）とみるのがよさそうだな。

だとすると、平均を取るより、ソート掛けて下位のデータを
拾うほうがよさそうなんだけど、それはそれで時間掛かっ
ちゃうことになりそうだよな。


いろいろなやましいな。

Python3、Pillow、tkinterの画像処理の進捗

断片的にメモ残している、Python3、Pillow、tkinter
を使った画像処理について、計算方法の考え方自体は
なかなかいいところまで行ったので、現時点までの
ゴニョゴニョをちょっと纏めておくことに。

発端は、aliexで買ったブギーボードみたいなやつ、便利
なんだけど、PCに見やすい画像で保存しておきたいよな、
と思ったことから。

書くときに電気食わないし、消すときにも電気ちょっと
しか食わないし、便利なんだけど、PCにデータとして残す
機能が無い。デジカメとかで撮っておけばいいんだけど、
コントラストが薄くて見づらいし、紙に刷りだして沢山
刷りだすとしても、元画像そのままだと見づらい。

で、なんとかきれいに二値化できないかな？と思ったわけ。

で、なんとなく思いついたロジックだと、完璧じゃないに
しても、そこそこ文字や画像を浮き上がらすことは可能な
はず。ただし、処理時間が超長くなりそうで心肺だな、と。

サンプル画像。処理時間をそこそこ短くするために、ひとまず
640×480ぐらいの小さいものを使ってみる。



こんな風に、コントラストが結構小さくて、もともと
見づらいんだよな。

ちなみに、この画像を、レタッチソフトとか使って単純な
二値化をしてみると、こんな具合。



ライトが差している右上は白っぽく明るくなってて、
左下は逆に暗くなっている。
なので、二値化の弁別値を弄るだけだと、こんな具合に
右上が白く飛んで、左下は黒くつぶれてしまうわけ。

同じ事を、普通のデジカメ画像でも行ってみる。
こないだも挙げたネコ写真だと…



こうなる。クロネコだ。



まぁ、ネコの写真はともかく、ブギーボードもどきに
書いた（描いた）文字や絵が、黒い地からきれいに分離
できる画像処理方法をいろいろ模索してみた。


ざっくりした計算処理内容を纏めると、あるドットの
周辺の平均値を求めて、その平均値よりも明るければ
明るい点に、暗ければ黒として描けば、周辺ドットとの
比較によってきれいに文字や絵が浮き上がるはずだろう、
と。
というわけで、愚直に処理ロジックに落とし込んで実行
してみたのが、こないだまでのお話。

なんといっても、Python3用のメジャーな画像処理用
ライブラリPillowを使って、ドットの明るさの平均値を
取ったり、それを新しい画像データに描きこんで行く
ための、getpixel、putpixelがものすごく遅いって
ところが大問題。こないだも書いたけど、

https://brown.ap.teacup.com/nekosan0/3779.html

640×480程度の画像をドットtoドットでコピーするだけ
でも、4秒も掛かっちゃう。

これだけ遅いとなると、周囲の平均値を取って比較する
処理を入れたら、二桁遅い時間が掛かるだろうと思って、
いろいろ考えてみた結果、とりあえず配列（Pythonだと
リスト形式）のデータに一旦変換しちゃえば、getpixel、
putpixelよりも速いだろうと。

で、試してみたら…そんな劇的には速くならなかった。

まぁ、速くならないのはひとまず仕方ないとして、高速化
の工夫は後回しとして、CPU時間をゴリゴリに掛けてでも
一連の処理を実行して、結果の画像を眺めてみたい。
プログラムに愚直にロジックを落とし込んで行ってみる。


ある1ドットについて、その周辺の縦横21ドットずつ
（合計441ドット）の平均値を求めて、その平均値より
明るければ緑、暗ければ黒としてドットを打ってみたのが
これ。



まぁ、想像通り、文字や図が浮き出てきた。画像が640×480
と粗いので、みづらいけれど、まぁなんとか文字や図は
ちゃんと読み取れる。
けど、見てのとおり、文字や図が書かれているところから
ちょっと離れたところ（何も書かれていない真っ黒なところ）
は、微小なノイズを拾って、妙な模様が出てきちゃう。

ちなみに、ネコの写真をやってみると、



こんな風に、薄暗い部分ですら、ネコの毛の模様が判る
程度に浮き上がらせてくるのが面白いところ。ピントが
外れている芝生の部分はモヤモヤした模様になって出て
きた。


現時点の問題は、この画像処理1枚行うのに、なんと
15分近く掛かっちゃう。
平均値の計算を愚直に行っているので、計算量が無駄に
多いのが原因。FFTの計算みたいに、これをもっと減らす
必要がありそう。まぁ、高速化はまた後の課題に。


その前に、文字や絵が描かれていない黒い部分に載っちゃう
モヤモヤノイズをナントカしたい。

というわけで、黒い部分に注目して、その辺の計算をちょっと
加えてみたのがこれ。



うん。まぁ、狙った感じになった。さっきの



元画像と比べてみると、こんな具合。うん。

ただ、今はまだ少しマジックナンバーをプログラム中で
使ってるので、その辺をたいていの画像でも自動計算
できるように変えていく必要がある。そのロジックは
もう考えてあるので、あとはその辺の処理を足しこんで
いけばokなはず。


あと、現時点のプログラムだと、広い面積を塗りつぶし
した場合に、（平均値が高くなっちゃうので）その中央部分
が黒く沈んでしまう恐れがある。なので、その辺についても
手を当てないといけない事はわかっていて、その対策も一応
考えてある。

その辺の考え方をさらにプログラムに追加すれば、計算方法
の内容としては完成っぽいんだよな。

そしたら、高速化を計ろう。


というのが、現時点までの進捗。





https://www.youtube.com/watch?v=4u5O3Ri1Dfc&t=32m20s

ゆいちゃんの、「乾きやすい」マークの顔真似。







https://www.youtube.com/watch?v=C0ZXOWa9LS0

Landing High Japanって、なんだ？
これ知らなかったな。こんなゲームあったのか。
Midnight landing、Top Landing、Landing Gearは
散々やったけど、これ全然しらなかったよ。




https://kuruma-news.jp/post/120299

ロービームでも、対向車のライトがまぶしい理由。
なんか、釈然としないけど、まぶしいものはやっぱり
まぶしいとは感じる。

なんとかならないものかなぁ？




https://twitter.com/shapoco/status/1075397780363825152

電解コンのマステ。
欲しいな、これ。