「PIC AVR 工作室」サイトの日記的なブログです。
サイトに挙げなかった他愛ないことを日記的に書き残してます。
PIC AVR 工作室 ブログ



あいかわらずのPython3、Pillow、tkinterで画像処理の
プログラムの実験。結果的には、やっぱりロジック自体
は一瞬で処理が終わる内容になってたことが確認できた。
長かった…


どこで時間が掛かってるのかを突き止めるのに、使ってた
Python3実行環境の絡みなんかもあって、いろいろ惑わ
されていたんだな。ようやくクリアになった。


で、最終的な解決に至るまでの実験結果を纏めておく。

まず、そもそもPythonのリスト形式の処理が、一般的に
遅いのかどうかを、リストの初期化やコピー処理なんかを
通して(実メモリへの読み書き)、どのくらい掛かるのか
を眺めてみる。テストのコードは、まずこんな。



Pythonの2次配列のリスト「a」を初期化する処理と、
その初期化に使う関数「f」の定義。
動かすと、ちゃんとリストに値が設定されている。

で、この関数「f」を流用して、でかいリストに値を
設定してみる。



「a」や「b」の初期化に、VirtualBox上のLubuntuで
10秒くらい。大体16Mピクセルくらいの画像に相当。

これを行ってから、「b」に「a」の値を1個1個コピー
していくループを実行してみると、実測で16秒くらい。

ってことは、例のオレオレロジックでは30万画素相当で
10秒くらいかかってしまっていたのに対して、この単純
にリストを1600万画素相当で読み書きするのに10秒くらい
で終わってるんだから、リストの読み書き処理自体は
やっぱりそれなりに速いことが判る。遅い原因は、
どうやらリストの読み書きそのものではない。

でも、VirtualBox環境でも、実機のWindows7(IDLE3環境)
でも、あれこれ骨格以外の処理を削り取って実行してみても、
数秒単位で時間が掛かっちゃう。…なぜだと。


実験用の画像処理プログラムの中で時間が掛かっている
のかなぁ、ホントかなぁ、と、ぼんやり考えてみて、
ふと思い出す。

確か、IDLEって、テキスト文字の表示処理、結構遅いんだ
よなと。
CLIのLinux環境だと、printで標準出力に吐き出しても、
スクロール処理含めて一瞬で大量に表示できるけど、
ILDE上のコンソール画面だと、目で追える位の遅さだった
記憶が。

なので、そもそもループでprint文の表示を行ったら
どのくらい時間掛かるのかをやってみた。

…480行分表示するだけで、数秒掛かってる…。
   お前か!!犯人は!!


というわけで、このprint文で処理中の行を表示する所
をコメントアウトして実行してみると、一瞬で処理が
終わる。


まぁ、そうだよね。Arduinoより遅いって、考えにくい
もんねぇ。うちのポンコツWindows7機(Core2 Quad)
が、Arduinoより速いってことがわかって一安心。


纏めると、
(1)VirtualBox環境で遅かった理由
  →仮想環境でのオーバーヘッドによるもの
(2)Windows7実機環境で遅かった理由
  →IDLE環境のコンソール表示の遅さによるもの

ということだったらしい。この点はとりあえずクリア。


ただ、もうひとつ遅くなってた原因の、平方和の平方根
の方は、別途なんか考えないといけないんだよな。

画像上の4つの代表点から、対象ピクセルまでの距離
(ユークリッド距離)を計算して、その近さに応じて
バックグラウンドの影響を加味しているんだけど、
そのユークリッド距離を求めるには、単純には平方和
の平方根が必要。
それを近時するなり、計算を単純化するなりできれば
いいんだけどなぁ。

C言語なら、有効桁とか考えて、整数型で適当に
丸め上げるとか、色々出来ると思うんだけど、Python
の型って、いまいち自由自在にはならないしなぁ。
うーーーーん。




https://page.auctions.yahoo.co.jp/jp/auction/p664647751

PC-8001 8801マシン語入門が出てた。ベーマガと一緒に。
ベーマガの方は、創刊号の翌々月のやつだな。

ちなみにこのマシン語の本。オイラがZ80のお勉強する
ために買った本だな。バイブルだな。
Z80は、98(というかEpson PC-CLUB)を使うようになって
からは、まったくというほど弄らなくなってしまって、
もう勘所がなくなってしまったんだよな。
レジスタの直交性の低さは、慣れてないとなかなか
プログラム組みにくい。AVR万歳。




https://twitter.com/IPAjp/status/1088270110744207360

こうなると、今後なにか事故が起きたら、

ニュースキャスター「この会社では、COBOLという
特殊なプログラミング言語を使って開発しており、
普通の人では理解が難しく、それが原因でトラブル
が発生したものと考えられています」

なんて話になったりするんだな。




https://twitter.com/koutyan6595/status/1087874031498358785

よくできたコントだな。




https://trafficnews.jp/post/82695

この、音声波形公開しちゃったっていう件。自衛隊の
哨戒能力云々がある程度推し量れちゃうのもあれだ
けど、それ以上に、全世界にレーダーの信号波形を
公開されちゃったっていうのって、潜水艦や戦艦が
キャビテーションノイズをサンプリングされちゃう
のと同じくらいアレなことなのかなぁ、って気がする。

事実上の敵国である北朝鮮にも当然その情報は拾われて
いるだろうから、この波形が来たら、”あの船から
火器管制レーダー来た!”ってバレバレになるという。

まぁ、ある種この戦艦は丸裸にされたようなものと
いっていいんだろうな。




https://twitter.com/HacksterPro/status/1087833294685814785

4輪車だと思ったら、四足で歩き回る。



https://twitter.com/Hacksterio/status/1088185528204386312

リアクションホイールを使うドローン。

ドローンみたいに、空気中で、重力も働いているような
状況なら、振り子みたいに重いものが自然と下に行く
だろうから、こういうリアクションホイールでも
大丈夫なのは判るんだけど、KSPみたいな宇宙開発シーン
だと、微妙にバランスが崩れたままの状態を、
リアクションホイールでバランス取り直し続けるって
用途に使うと、ホイールの回転速度が無限大に発散
してしまうんじゃないかなぁ?って、素朴な疑問が
あるんだよな…。

例の「フロムザレイス」では、作った飛行機の姿勢を
制御するのに、リアクションホイール使って飛ばして
いたんだけど、あれ、水平飛行ですら、常に機首上げ
し続ける必要があるだろうから、リアクション
ホイールが無限大の角速度で回らないといけないん
では?と心配してた。



コメント ( 0 )