結果は by.blooddy.crypto.image.PNG24Encoder が圧倒的に最速！！ エントリ内からのリンクが切れてるので、使ってみたい方は BlooDHounD’s workspace の blooddy_crypto.swc からダウンロードして下さい。

透明・不透明共に速い速い！Alchemy 使ってるのか気になるところです。

同期処理でエンコード

zlib 圧縮率を 1 で、不透明な画像と透明な画像に対してフィルタの種類を変えてエンコードしてみる。

非同期処理でエンコード

非同期処理の注目点は、この例だと 12 回一気にコールしてるんだけど最後にコールしたところから順々に実行され、一個処理が終わると次の処理って感じにお行儀よく処理されていく。 これは Alchemy の機能だと思うんだけどコールしたのと逆順なのはなんか理由があるのかな・・・

あと、こっちはエンコード終了時に toXML() メソッドでちょっとだけデコードして情報を抜き出した XML を trace() してるから Firefox で FlashTracer 入れてる人は開いてみるといいかも。

拾った理由は、こんな感じ。 AS3 では ByteArray.compress() メソッドを叩くと、 deflate 圧縮して zlib 形式にフォーマットしてくれるんだけど、 冗長性のない ByteArray の圧縮は高速に処理できるけど、 PNG フォーマットに定義されているフィルタ処理で冗長化してから compress() すると処理にやたらと時間がかかる。 フィルタリングする前提だと、 zlib 圧縮率を低めにすれば十分高速に処理でき、 zlib 圧縮率よりもフィルタリングの有無の方がファイルサイズ縮小のメリットが大きいけど、 compress() メソッドでは zlib 圧縮率を設定できない。 あとは、 Alchemy だと非同期に処理するコードも簡単に書けるから、大きなサイズの BitmapData をエンコードする場合などもメリットありそうだし。

Alchemy の非同期処理は進捗とかを関数の参照渡しで C から AS の関数をコールして通知するんだけど、これって AS3 ライクじゃないんでイベントを発行する形にラップしてある。 あと、デバッグ用にちょっとだけデコードしてチャンクの情報とかを XML にして返す関数も実装。

てことで、 zlib と libpng を使って、 Alchemy で PNG クラスを作ってみた。サンプルの一番下に該当。

PNG フォーマットには圧縮効率を上げるフィルタという仕組みがあって、フィルタの仕組み自体は PNG の仕様書みながら実装できるけど、どのフィルタを使うのが最適なのかはアプリケーションに任されてるけど正直んなとこまで突っ込みたくないしってことで、 Alcehmy 使えばフィルタ選択もしつつ高速化もできるかと思ったけどそんなに甘くなかった。 結果は見ての通り。OSEEEEEEEEEEEEEEEEE!!

ただ、フィルタの自動選択の方はコンボボックスで PNG_ALL_FILTERS を選択してエンコードすると libpng が各スキャンラインに対して自動的に最適であろうフィルタを選択してくれてる気がする。 あと、 AS では引数もなにもなしで ByteArray.compress() の一行で済まされてしまう zlib アルゴリズムでの圧縮に対して、 Alchemy で zlib を使うと圧縮レベルを 0(無圧縮)～9(最大圧縮) で設定することができる。当然圧縮率上げると遅いけど。 ちなみに libpng のデフォルトのフィルタタイプは PNG_ALL_FILTERS で、圧縮レベルは 6 ぽい。

速度重視なら Optimized PNGEncoder with filters 使って、ファイルサイズをある程度考慮しないとだったら Alchemy の PNG クラス使うとかそんな感じかなー・・・なんにせよ選択肢増えたってことでよしとするか・・・

PNG フォーマットで定義されてるフィルタの種類は5種類。

• None – 該当バイトをそのまま使用 (as3corelib の PNGEncoder はこれ一択)
• Sub – 該当バイトと左のピクセルのバイトとの差分を使用
• Up – 該当バイトと上のピクセルのバイトとの差分を使用
• Average – 該当バイトと左/上のピクセルのバイトの平均値との差分を使用
• Paeth – 該当バイトと左/上/左上のピクセルのバイトのうちの最近傍値との差分を使用

ていう感じ。どのフィルタを使うのが圧縮率が高いかは対象の画像に依存する。

ファイルサイズは 1 / 5 くらいになるけど、処理時間は倍以上かかっちゃう。このまま None 以外のフィルタ使うとサーバ資源は節約できるけどユーザのストレスは倍増間違いなし・・・ あ、Alchemy の出番ですね！！まだ Cygwin のセットアップも終わってないけど！！

// 関係ないけど Wonderfl でコードが 1000 行越えるとソースコードのプレビューのインデントとかカラーリングとかが壊れちゃいました。

PNGフォーマットはJPGフォーマットのように複雑な変換処理がない単純なフォーマットなので、コード量が少く最適化箇所も少ない。ただ、複数回エンコードしたり、サイズの大きな BitmapData をエンコードする際にはメリットがでてくるんじゃなかろーかと。

処理速度比較の為に as3corelib の PNGEncoder と同じく PLTE チャンクは実装せず、フィルタオプションは ‘None’ 一択で実装してる。 as3corelib にはない機能で、 BitmapData が不透明時の分岐を実装した。これをしとくことで BitmapData.transparent == false の BitmapData をエンコードした時にファイル容量が軽くなるはず。

最適化箇所をざっくり挙げとくと、 for 文の length をあらかじめ取得しとくとか、 for 文の中で何度も同結果の分岐を挟まないとか、 Vector を使うとかっていう最適化の基本的なところから、エンコード毎に使う PNG シグネチャ・ IEND チャンク・ CRC テーブルを定数にして使い回したりだとか、何度も同結果の null チェックしないとか、無駄な型変換をしないとかそんな感じ。
サイズや透明・不透明によって違うけど、だいたい 25% くらい高速化してる気がする。