image

意外にハマるのがイメージハンドリング。

昔はbitmapでせいぜい16bitカラーとか言って威張っていたが。。#いつの時代だと言われそう。

32ビットあるいは4kとか。 さらにはretinaで2倍解像度。

フォーマットは各種入り乱れて、それを、便利な描画関数がいい感じで処理してくれちゃう。

一見同じ大きさに、見えてる画像。 

この同じ大きさに見えてるというが逆にハマりポイントで、いま1280x780も

1440x1080だろうが、写真は同じサイズで見える。ただ解像度が違うだけ。

ドット数が大きい方が解像度が高い。

当たり前なんだけど、これ逆に考えると面倒。つまり、同じjpegファイルがあったとして、

2つの機械で、同じ大きさで表示できる。さあ問題はこれからで、そのjpegの、同じ位置に例えばグラフィックで文字を、入れようとする。

グラフィック関数は、不幸なことに座標系で指定するのでマシンAではそれがx座標390で

y座標が230に描画するようにするとぴったりとハマるとする。このマシンの解像度が1280x780だった

とする。

これをマシンBで解像度が1440x1010だとどうなるか。

答えはいくつもある。 これは、座標系を、1 ドット数に合わせる場合、 2 解像度に合わせる

場合で、違ってくるからだ。

 

まあ、今の人はこういうロウレベルグラフィックスそもそもやらないから、関係ないけどね。

 

 

HoughlineP

ちょっとしたグラフィックで、手でやると面倒な

ギャップを拾うのに使って見た。

パラメータをちゃんと与えると、ほぼ思い通りの結果になる。

いまいちわかんないのは、直線がとれたり、とれなかったりすることかな。

きちんと、全部取れること想定のアルゴリズムでなくてほぼ取れる傾向にある

というアルゴリズムにするのがいい。

あたりまえなんだろうけど、結果のlinesくらい、ソートするオプションは

欲しいわな。   わかってないか。

4月のある日

4月になると思い出すのは、S&Gの April come she will

先週は、pretty_midiであるパーサーを書いた。

やっぱし、pythonは楽である。

どうせなら、これで全部やりたい。家にいるとほとんどiPad proしか使わない。

開発環境入りのiMac 29は息子の机の上。

ちょっとしたことは、全部Pythonista でやりたいな。