メインロジックが出来た

Python3、tkinter、Pillow使って年末からゴニョゴニョと
やっていた、画像処理するGUIツールのメインロジックが
ようやく動くようになった。

何をやってるのかを簡単に纏めなおすと、ブギーボード
みたいなやつをaliexで買って、メモとか計算とかで
結構便利に使えていい買い物だったんだけど、保存機能
が根本的に欠落しているのをナントカしたい、と。

液晶を利用しているデバイスなんだけど、デジタル機器
ではないので、直接PCと接続したりして、画像（や文字）
を保存しておくことができない。

なので、デジカメとかで撮影して、それをPCに残しておく
くらいしかないんだけど、書いた（描いた）ものは
そのままではちょっとみづらい。
なので、二値化して見やすく加工してから残しておきい。

ても、この液晶のコントラストが結構低いので、レタッチ
ソフトとかで単純な二値化をすると、まともに図柄を
抽出できなくて、それなりの画像処理が必要になって
しまうというもの。この課題をクリアしたいと。

実験用の画像サンプルとして使っているのが、



これ。

ごらんのとおり、写真に撮るとコントラストが低くて、
正直見づらい。しかも、右上はライトが当たっていて
明るい一方、左下はライトが暗くて図柄の線も微か。

人の目には、これでもちゃんと「図」と「地」の違いが
見分けられるんだけど、CPU君はこれをどうやったら
上手い事区別できるのか。

で、試行錯誤した結果、とりあえず力技のロジックで
こないだやってみたのがこれ。



元画像から、結構くっきり抽出できていると思うんだ
けど、問題はこれ1枚（640×480ほど）を処理するのに
2～3分かかっちゃう。そんな遅いとまともに使えない。

計算処理をもうちょっと工夫して、実用に耐える速度を
出そうというのが、ここのところの課題だったわけ。


で、あれこれ考えながらロジックを弄りなおしていたん
だけど、ようやく一通りまとまって、実行できる状態に
なったので、動かしてみた。

出てきた画像が、まずこれ。



なんだこれ？バグった。

pdb使って計算途中の変数をながめてみる…

計算結果をストックしている変数に、まともに値が
入ってない（というか、全部ゼロ）というのがあって、
どうやら、初期化する関数を呼び出してなかった
みたいな。そのあたりをゴニョゴニョなおす。



こんな風になっちゃった…

なんだろう？と思って、pdbで途中で止めて、ワーク
変数の中身をダンプ。
どうやら、ドットの輝度の平均値を計算しているところ
で、平均値がマイナスになってしまっているところがある。

うーーーん。

光が吸収されてしまっている。どうやら、オイラはうっかり
ブラックホールを作り出してしまったようだ。
地上にブラックホールはまずいので、事故が起きないうちに
こっそりバグを直す。



ようやく、こんな具合に、抽出できた。さっきの長時間
かかるロジックの結果と比べて、微小な部分でドット単位
の差異はあるんだけど、見てのとおり、ほぼ同じ結果が
得られた。

ちなみに処理時間は、全体で約10秒くらい。予定通り2桁
ほど速くはなったんだけど、なんでこの程度の処理が
秒単位で掛かっちゃうんだろうなぁ？そんなに重い処理
では無いんだけどな…と思って、考え直す。

多分、処理ロジック自体は相当まともなんだけど、よく
考えてみたら、これを動かしているVirtualBox上の
Lubuntuって、仮想環境だから処理能力が低いんだよな…
と。

以前、仮想環境の処理能力をUnixBench掛けてみた結果を
見直してみる。

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

初代のRaspberry Piくらいの能力しかないことがわかる。
UnixBenchを、古いLet's Note（CF-T9）のネイティブ環境
で実行してみた結果は、これよりも1桁速い値が出てきてた。

このLet's NoteのCPUをPassMarkで見てみると、

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+U9600+%40+1.60GHz&id=1020

1000ちょっとで、UnixBenchと同じくらいの数値になってる。
まぁ、PassMarkはCPU単体のベンチで、UnixBenchはディスク
I/Oとか色々なものまで含めたベンチなので、一概に比較は
出来ないものの、大体同じくらいの指標と仮定してみる。

なので、今回使った仮想環境と、メインで使ってるPCの
処理能力とで比較すると、およそ30倍くらいの処理能力差が
ありそう。

ってことで、仮想環境で10秒くらい掛かるなら、メインPC
使えば0.3秒で終わるんじゃないかな？と。まぁ、実際は
そこまで速くはならないだろうけど、1秒は掛からない
だろう。

このロジックのまま、Androidに移植しても、1秒前後で
処理が完了するんじゃないかな。
あと、もっとデカい画像で処理しても、実用時間内で
処理が完了できるだろうと。

とりあえず、まだ仮実装になってる部分とか、GUI操作
の使い勝手とか、その辺を改めて実装していこう。


で、出来ればtkinterでタブ表示したいよなぁ、とか思って
ちょっと調べてみた。

https://qiita.com/yusk24/items/3af56d0599be200559de

https://torina.top/detail/413/

https://qiita.com/fiftystorm36/items/96014a13b09777925055

どうやら、tkinterのnotebookっていうウィジェット？
（コンテナ？）を使うか、力技で押し込むか、どっちか
ってことになりそうかな。



ちなみに、画像処理のロジック内容の作戦はこう。

あるドットの周囲の平均値を求めておいて、その値とその
ドットの輝度を比較して、明るければ「図」、暗ければ
「地」として把握しようっていう作戦。

ただし、単純にそういう処理をすると、たとえば以前も
触れたこんな画像の場合、



こんな風に、暗い部分については微小なノイズを拾って
どうでもいい模様を拾い上げてしまう。
なので、「地」の部分の場合は、その地の明るさを加味
させて、要らない模様を抽出しないようにする必要が。



それと、逆に、塗りつぶししたところは、周囲も明るい
ので、こんな風に塗られていないものとして扱われて
しまう。



こんなふうに、四角に塗りつぶした内側が黒くなって
しまう。

なので、四角く塗りつぶしたところも、ちゃんと塗り
つぶされているように、ちゃんと補正するロジックが
考慮されてはいる。（いろんな条件で撮影された写真
でもちゃんと動作するように、固定値とかマジック
ナンバーとかで処理しないように工夫している）

あとは精度だな。まだ気になるところはあるものの、
実用範囲で妥協しつつ、できればこれ以外の画像にも
適用できるようにしたいところ。





https://twitter.com/ryogomatsumaru/status/1082258614008537088

面積の問題。
結構考えてみて、解けた。なかなか面白い問題だな。
（時間掛かった）




https://clicccar.com/2019/01/09/676188/

FD-3Sをアメリカの富豪がチューンしたら。
NAの3ローター、なかなか魅力的だな。




https://twitter.com/Count_Down_000/status/986068984922386432

オイラはココロが汚れているようだ。




https://twitter.com/AkibaEvangelist/status/1082992223484968960

メラミンスポンジ。へぇ。それは便利だな。




https://www.fnn.jp/posts/00410520HDK

国際法が守れない国とはお付き合いできないんじゃないか
なぁ。
一旦距離置いたらいいと思うんだけどな。