2012/05/25(金) [n年前の日記]
#1 [cg_tools] 画像の分割でちと悩む
透明色を含む16色で描かれたキャラが、1枚の中にたくさん収まっているpng画像があるとして。32x32ドット単位等で分割して保存したい。
◎ 分割結合「あ」を試用。 :
縦横の分割数を指定するだけで分割できる。
元画像が消滅することに注意。また、透明色情報が消えてしまった。大量のファイルについて、1枚1枚透明色を指定していくのは現実的ではない。透明色の情報を保持したまま分割できるソフトはないものか。
元画像が消滅することに注意。また、透明色情報が消えてしまった。大量のファイルについて、1枚1枚透明色を指定していくのは現実的ではない。透明色の情報を保持したまま分割できるソフトはないものか。
◎ GIMPのギロチン機能を試用。 :
ガイド？の位置で画像を分割して、新規画像を作ってくれる機能。ガイドを指定していくのが少し面倒だが、透明色情報は保持してくれる。
だが、数枚の画像ウインドウならともかく、大量に開いた画像ウインドウを一つ一つ手作業で保存していくのはツライ。
現在開いている画像ウインドウを、順々に自動保存してくれるスクリプトがあれば、話は別かもしれないが…。
だが、数枚の画像ウインドウならともかく、大量に開いた画像ウインドウを一つ一つ手作業で保存していくのはツライ。
現在開いている画像ウインドウを、順々に自動保存してくれるスクリプトがあれば、話は別かもしれないが…。
◎ GIMPの画像分割スクリプトを試用。 :
フィルタ→ウェブ→画像分割を使ってみた。ガイドの位置で画像を分割して、保存までしてくれる。元々はWeb制作用に書かれたスクリプトのようで、テーブルで配置をして1枚の画像のように見えるhtmlまで出力してくれる。ブラウザで見る限り、透明色部分は、透明になっているように見えた。
しかし、EDGE2で開くと、透明色＝背景色の位置が違ってしまっている。透明色関係で、何か情報が書き換わっている可能性がありそう。
しかし、EDGE2で開くと、透明色＝背景色の位置が違ってしまっている。透明色関係で、何か情報が書き換わっている可能性がありそう。
◎ ImageMagickを試用。 :
_Cutting and Bordering -- IM v6 Examples
を参考に。
今回は、この方法で分割するのが良さそう。
convert hoge.png -crop 3x3@ +repage +adjoin hoge_%d.pngこんな感じに。
- -crop 3x3@ は、横3、縦3で分割するよ、という指定かしら。
- +repage +adjoin は、何の指定か分からない。とりあえずオマジナイと思っておくことにする。
- 最後に、保存ファイル名を指定する。%d は連番に置き換わるのだと思う。
今回は、この方法で分割するのが良さそう。
[ ツッコむ ]
#2 [android] drawBitmap()について実験中
SurfaceView と Canvas#drawBitmap() を使って画像を描画する際、ビットマップ画像の一部分から切り出して描画するのに、drawBitmap(Bitmap bitmap, Rect src, Rect dst, Paint paint) を使っているのだけど。
描画元範囲と描画先範囲に異なる値を指定できる、つまりは拡大縮小ができるわけで…。もしかすると、等倍で描画する場合ですら、拡大縮小処理が行われているのではないか、それが原因で描画が遅くなるのではないかと疑念が湧いた。
試しに、BG描画処理を書き直し。今までは、画面の中で見えるはずの範囲を計算して、その部分を切り出して描画していたけれど。画面より一回り大きいビットマップ画像を4枚分、画面からはみ出そうが気にせずに、そのまま描画するように書き直してみたり。
Lenovo IdeaPad A1 で確認してみたところ、切り出して描画するより、無頓着にベロンベロンと描画したほうが、数FPS速くなった。もちろん、機種によって結果が全く異なる可能性が高いのだけど。描画面積は4倍に増えているはずなのに、逆に速くなったあたりがややこしい。拡大縮小が入ってくる描画処理より、クリッピング処理のほうが軽い、ということなのかしら。わからんけど。
GLSurfaceViewなら、こんなことを気にせずに速度が稼げるのだろうか…？
描画元範囲と描画先範囲に異なる値を指定できる、つまりは拡大縮小ができるわけで…。もしかすると、等倍で描画する場合ですら、拡大縮小処理が行われているのではないか、それが原因で描画が遅くなるのではないかと疑念が湧いた。
試しに、BG描画処理を書き直し。今までは、画面の中で見えるはずの範囲を計算して、その部分を切り出して描画していたけれど。画面より一回り大きいビットマップ画像を4枚分、画面からはみ出そうが気にせずに、そのまま描画するように書き直してみたり。
Lenovo IdeaPad A1 で確認してみたところ、切り出して描画するより、無頓着にベロンベロンと描画したほうが、数FPS速くなった。もちろん、機種によって結果が全く異なる可能性が高いのだけど。描画面積は4倍に増えているはずなのに、逆に速くなったあたりがややこしい。拡大縮小が入ってくる描画処理より、クリッピング処理のほうが軽い、ということなのかしら。わからんけど。
GLSurfaceViewなら、こんなことを気にせずに速度が稼げるのだろうか…？
[ ツッコむ ]
以上、1 日分です。