先日、SwfmillRuby に hokaccha さんのブランチをマージしました。hokaccha さんのブランチでは、32bit png の image2xml に対応いただいておりましたが、これに xml2image の処理を追加実装しています。これにより、32bit png (DefineBitsLossless2 の image format=5) に暫定対応しました。
ただし、今回追加実装した xml2image は、透過色を含む PNG の扱いについて完全ではないので、あくまで暫定対応という位置づけです。32bit png を SWF 内部のビットマップに変換する際に RMagick(ImageMagick) を経由して得られる各ピクセルの情報と、Flash IDE がパブリッシュするビットマップの各ピクセルの情報とで、微妙に誤差が出てしまっており、現時点で、Flash IDE が出力するビットマップデータと完全に一致させる事ができていません。
具体的には、DefineBitsLossless2 の ARGB データから RMagick::Image の png イメージを作成する部分が怪しい感じです。確証はないのですが、どうも、SWF File Format Specification にある:
The RGB data must already be multiplied by the alpha channel value.
の “multiplied” の解釈が単なる乗算ではないみたいような気がしています(除算で逆変換しても適当な数値にならないのです)。今のところ、幾つか透過色を含む PNG で動作検証してみた限りでは、ここを逆変換する際に、RGB それぞれの値と opacity との OR を取る事で、元のイメージの再現性がある程度確認できたので、ひとまずこの方法で実装してみました。何か勘違いしている気がしないでもないのですが、、お気づきの方、コメントいただけると幸いです。
ちなみに、上記の更新以外でも、partialize や templatize の機能を追加し、partizlize や templatize において、SWF を再生成(regenerate)する際の XML 処理コストを少しでも削減するための事前処理をおこなえるように改修を続けています。これは、ちょっと複雑な SWF の動的生成/書き換え/合成をしようとすると、再生成に XML 中の ID 体系を付け替えたり、要素を入れ替えたりといった処理のコストがとても大きくなる事がわかってきたからです。詳しくドキュメントを書く時間が取れていないのですが、サンプルやソースコードコメントから意図を汲んでいただけると幸いです。(少なくとも FlashLite 1.1 の携帯サイト向けには、わりと面白い事ができるくらいのものにはなってきていると思います。)
まだ公開して間もない SwfmillRuby ですが、いつの間にか、いくつかの方面からご利用のご連絡をいただいており、とても励みになっております。ライセンス上、ご利用のご連絡は必須ではありませんが、よろしければご利用コメントやご意見などお寄せいただければとうれしいです！
関連していそうなエントリ:
最近のコメント