くるくるくるｋ

文具コーナーでよく見る試し書きのアレ。

ああ、そうか

最初に乗っけるのはスクリーンショット画像にして、SWFのサンプルは続きに掲載すればいいのか。

関係ないけど、表現したい画の為に制服女子高生のイラストが要るが、描くのが超億劫。
倦怠術の達人「超 億劫」。

タイトルバナー作ってみた

あまりのセンスのNASAに我ながらビックリした。
あと変にインタラクティブに凝ったら、くそ重くなった。

[追記] 更に色々加えたらいよいよ、重いだけでなく悪趣味になってきた。元に戻す。作ったものは続きに。

K-Means法による減色

以前8ビットBMPエンコーダ ってのを作ったんだけど、これは256階調のグレースケールしか出力出来なかった。で、256色の最適化されたカラーテーブルを作る方法について以前から考えていたりしたのだけど、てっく煮さんでK-means法というクラスタリング手法の事を知り、これを減色アルゴリズムに使うことにした。
今回はパラメータをRGBの3座標に限定したけど、さらにピクセルのXY座標も付加することで（距離関数に何かしらの工夫がいるんでしょうけど）領域判定なんかにも使えるらしい。

以下は16色で減色を行うサンプル。上が元画像ね。
クリックするたびにカラーテーブルを更新して徐々に最適化する。
あと何かキーを押すとリセット。
処理の手順は簡単には以下のような流れ。

1. ランダムな16色のカラーテーブルを作って、それぞれのピクセルを一番近いテーブル色で置き換える。
2. 同じテーブル色を選んだピクセルの元の色の平均値を求めて、そのテーブル色を置き換える。
3. 再度、それぞれのピクセルを一番近いテーブル色で置き換える。
4. 以下、2と3の繰り返し

RGBよりもL*a*b*だとかYCｒCbだとかの色空間でクラスタリングしたほうが、人間の目にとってより自然になる、というような話もあるけど。

モザイク作った

BitmapData.getPixelsメソッドの戻り値はByteArrayなので、使いどころが難しいと思ってたんですが、やってみると意外や、ByteArray.readByteで順にARGBのチャネルが取り出せてラクだったりして。気持ち負荷も小さい気がする（あくまで気持ち）。

ふぇふぇふぇふぇ

会社の貸与PCにとうとうEclipse入れてまった。もう後には引けない・・・！と言いつつも、ASは楽しすぎるのでSJC-Pの受験勉強は一向に進みません。

さて、今日は2つのARGBカラーの中間の値を求める方法を考えていました。

エンコードしたJPEGが一部ソフトで開けない件

一部ソフトっていうか、SAIで開けなかったんだけどね。
とりあえず改造を施していない標準のJPEGEncoderから出力したjpegファイルはSAIで開けた。
ということは僕が改造したことが原因であるのだろう。

で、その開けないほうのjpegをこのソフトを使って解析したところ、「EOI(End Of Image) ワードが無い」と出た。標準ライブラリが出力したファイルにはEOIが書き込まれているらしいので、ほぼ間違いなくこれが原因。
早速改造した方（あまり凝らずにJPEGEncoder2とした）を確認する。

結論から言うと、

dispatcher.dispatchEvent(new Event(Event.COMPLETE));
writeWord(0xFFD9); //EOI書き込み
break;//エンコード終了

こうなっていたのを

writeWord(0xFFD9); //EOI書き込み
dispatcher.dispatchEvent(new Event(Event.COMPLETE));
break;//エンコード終了

こうしたらEOIが書き込まれるようになった。 確かに上のソースだけを見ると、呼び出し側のコンプリートエヴェントのリスナー関数が、EOIをまだ書き込んでないByteArrayを読み込みそうに見えなくもないけども、やっぱり納得がいかない。
なんでなん？リスナー関数はスレッドみたいに割り込めてしまうん？

とりあえず解決。