2015/12/30(水) [n年前の日記]
#1 [python] インデックスカラー画像のパレット値を取り出してGIMP Paletteファイルにしたい
インデックスカラーのpng画像を読み込んで、GIMP Paletteファイル(.gpl)に変換したい。環境は Windows7 x64。
Python + Pillow を使ってパレット値を取り出せないか実験。おそらくこんな感じで取り出せそう。
Python + Pillow を使ってパレット値を取り出せないか実験。おそらくこんな感じで取り出せそう。
>>> from PIL import Image
>>> im = Image.open("mz700.png")
>>> pal = im.palette
>>> value_mode, data = pal.getdata()
>>> value_mode
'RGB'
>>> data
'\x00\x00\x00\x00\x00\xff\xff\x00\x00\xff\x00\xff\x00\xff\x00\x00\xff\xff\xff\xff\x00\xff\xff\xff'
>>> lst = list(data)
>>> lst
['\x00', '\x00', '\x00', '\x00', '\x00', '\xff', '\xff', '\x00', '\x00', '\xff', '\x00', '\xff', '\x00', '\xff', '\x00', '\x00', '\xff', '\xff', '\xff', '\xff', '\x00', '\xff', '\xff', '\xff']
◎ Pythonスクリプトにしてみた。 :
Pythonスクリプトで書いて、Gist に置いてみた。
_インデックスカラー画像のパレット値をGIMP Palette(.gpl)に変換
動作には、Python + Pillow が必要。
スクリプトの使い方は、インデックスカラー画像(hoge.png)を用意して、以下のように打つ。
結果をファイルに保存したい時は以下のように。
カレントディレクトリ内の画像ファイルを一括して GIMP Palette に変換したいなら、Windowsの場合、以下のようなbatファイルを書けばできる。と思う。たぶん。
_インデックスカラー画像のパレット値をGIMP Palette(.gpl)に変換
動作には、Python + Pillow が必要。
スクリプトの使い方は、インデックスカラー画像(hoge.png)を用意して、以下のように打つ。
python image2gpl.py hoge.pngそのままだと標準出力に GIMP Palette フォーマットで内容がダンプされる。
結果をファイルに保存したい時は以下のように。
python image2gpl.py hoge.png > hoge.gpl
カレントディレクトリ内の画像ファイルを一括して GIMP Palette に変換したいなら、Windowsの場合、以下のようなbatファイルを書けばできる。と思う。たぶん。
@echo off @rem カレントディレクトリ内のインデックスカラー画像を一括してGIMP Palette(.gpl)に変換 for %%F in (*.png) do ( python image2gpl.py %%F > %%~nF.gpl )
◎ PythonとPillowのインストール方法についてもメモ。 :
Python は
_Download Python | Python.org
から .msi が入手できる。python-2.7.11.msi をDLして実行すればインストールできるのではないかと。
Pillow は、 _Pillow 3.0.0 : Python Package Index の下のほうにインストール用の .exe があるので、ソレを実行すればインストールできる、のだろうか。自分の環境では、昔のメモを見直すと easy_install pillow でインストールしたっぽいけど。 _PillowのバイナリをpipでWindowsで扱う話 によると、2014/02の段階では Windows環境でも pip install pillow でインストールが可能だったらしいので、今も pip でインストールできるのかもしれない。
Pillow の動作には「Microsoft Visual C++ 2008 SP1 再頒布可能パッケージ」とやらが必要、と手元に残ってる昔のメモには書いてあるけど、今はどうなんだろうか。
_blockdiag 1.3.1 インストールメモ - 虎塚
_blockdiag の概要 - blockdiag 1.0 ドキュメント
_Download Microsoft Visual C++ 2008 SP1 再頒布可能パッケージ (x86) from Official Microsoft Download Center
Pillow は、 _Pillow 3.0.0 : Python Package Index の下のほうにインストール用の .exe があるので、ソレを実行すればインストールできる、のだろうか。自分の環境では、昔のメモを見直すと easy_install pillow でインストールしたっぽいけど。 _PillowのバイナリをpipでWindowsで扱う話 によると、2014/02の段階では Windows環境でも pip install pillow でインストールが可能だったらしいので、今も pip でインストールできるのかもしれない。
Pillow の動作には「Microsoft Visual C++ 2008 SP1 再頒布可能パッケージ」とやらが必要、と手元に残ってる昔のメモには書いてあるけど、今はどうなんだろうか。
_blockdiag 1.3.1 インストールメモ - 虎塚
_blockdiag の概要 - blockdiag 1.0 ドキュメント
_Download Microsoft Visual C++ 2008 SP1 再頒布可能パッケージ (x86) from Official Microsoft Download Center
[ ツッコむ ]
#2 [gimp] GIMP Paletteファイルのフォーマット
GIMPユーザフォルダ内の GIMP Paletteファイル(.gpl)ファイルの中身を確認してたけど。要するに、.gplファイルはテキストファイルで、以下のような感じで記述されてるっぽい。
GIMP Palette Name: Defaults Colors New Columns: 10 # 0 31 63 #001f3f 0 116 217 #0074d9 46 204 64 #2ecc40 57 204 204 #39cccc 61 153 112 #3d9970 127 219 255 #7fdbff 1 255 112 #01ff70 255 220 0 #ffdc00 255 133 27 #ff851b 255 65 54 #ff4136 240 18 190 #f012be 177 13 201 #b10dc9 17 17 17 #111111 133 20 75 #85144b 170 170 170 #aaaaaa 221 221 221 #dddddd 255 255 255 White
- 1行目は、「GIMP Palette」と記述。
- 2行目は、「Name: パレット名」
- 3行目は、「Columns: 列数」
- 4行目は、「# コメント行」。ここにライセンス種類が書いてあるファイルもあったし、複数のコメント行が書いてある場合もあった。
- 空行は無視してくれるっぽい。
- それ以降はパレット値。おそらく、「R値 G値 B値 色の名前」
- R、G、B、色名の区切りは、空白かTAB文字が使える模様。
- 改行コードは、CRLF でも LF でもいいらしい。
[ ツッコむ ]
#3 [zatta] アセンブラソースをCで書き直すのって珍しいのだろうか
以下の記事を目にしまして。
_【岩田 聡氏 追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき！」特別編 - 4Gamer.net
Mother2の立て直し時に電子メールを導入したり、 _CVS 的なものを導入した、てなあたりの話が凄いなシビレちゃうなカッケーなあ、と思いながら読んでたのですが。どうも一点、気になるところがあって。いや、実に些細なことというか、話の全体の流れの中ではホントどうでもいいことなんですけど。
アセンブラのソースを見ながらC言語で書き直していった、という話だとすれば…「稀有」とまで言われる話でもないような…。
というのも、そのくらいなら自分が参加させてもらった某STGの移植作業でも、チーム全員(と言ってもたしか5〜6人だったけど)がフツーにやってたからで。自分のようなゴミクズカスの落ちこぼれダメダメプログラマーですらやれていたのだから、アセンブラでゲーム書いてた世代ならほとんどの人はできることじゃないのかなと。そもそもアセンブラで書く時も、頭の中では高級言語ノリで考えてから各命令に分解していくのだし。それとも、「いやいや待て待て、そんなよくある話じゃなくて」ということなのかな…。自分は何か勘違いしてるのだろうか。 *1 *2
もちろん、他の逸話はどれもこれも「正真正銘、スーパープログラマーだったんだなあ」と思える話ばかりなので、結局は、「岩田氏ならそのぐらいできて当たり前でしょう」てな感じで、氏が下位レイヤーから上位レイヤーまで全てを把握しきってるプログラマーだったと証明する話の一つであることに何ら変わりないのですけれど。
まあ、なんだかちょっと、微妙に気になったという、ただそれだけの話です。珍しいのかなあ…。当時は珍しくなかったよね…。いや、でも、珍しいということにしといたほうが話が面白くなるところも…あるのかなあ。
_【岩田 聡氏 追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき！」特別編 - 4Gamer.net
Mother2の立て直し時に電子メールを導入したり、 _CVS 的なものを導入した、てなあたりの話が凄いなシビレちゃうなカッケーなあ、と思いながら読んでたのですが。どうも一点、気になるところがあって。いや、実に些細なことというか、話の全体の流れの中ではホントどうでもいいことなんですけど。
石原氏： (中略)それだけでも凄いんですが，驚いたのは，なんと岩田さんは，アセンブリ言語で書かれたゲームボーイ版のソースを見ながら，それをC言語に書き換えるというやり方で作っていたんですね。
川上氏： ええ！？
石原氏： そんなやり方，ほかで聞いたことがないんです。逆アセンブルとかならまだしも，アセンブラのコードをコンバートするとか。あれは，謎の技術でしたね。
三津原氏： そもそも，アセンブラというのは一行一行に意味があって，それを何行かまとめたらCのコードになるわけですよ。それを逆に組み立てるというのは，普通に考えたら相当に難しいというか，破綻しそうな話なんです。プログラマーの目から見ても，褒め言葉で「変態」と呼んでいい難しい作業だと思います（笑）。【岩田 聡氏 追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき！」特別編 - 4Gamer.net より
三津原氏： アセンブラをCに変換できるエンジニアというだけでも稀有だとは思いますが，そっちは探せばいないわけではないんです。【岩田 聡氏 追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき！」特別編 - 4Gamer.net より
アセンブラのソースを見ながらC言語で書き直していった、という話だとすれば…「稀有」とまで言われる話でもないような…。
というのも、そのくらいなら自分が参加させてもらった某STGの移植作業でも、チーム全員(と言ってもたしか5〜6人だったけど)がフツーにやってたからで。自分のようなゴミクズカスの落ちこぼれダメダメプログラマーですらやれていたのだから、アセンブラでゲーム書いてた世代ならほとんどの人はできることじゃないのかなと。そもそもアセンブラで書く時も、頭の中では高級言語ノリで考えてから各命令に分解していくのだし。それとも、「いやいや待て待て、そんなよくある話じゃなくて」ということなのかな…。自分は何か勘違いしてるのだろうか。 *1 *2
もちろん、他の逸話はどれもこれも「正真正銘、スーパープログラマーだったんだなあ」と思える話ばかりなので、結局は、「岩田氏ならそのぐらいできて当たり前でしょう」てな感じで、氏が下位レイヤーから上位レイヤーまで全てを把握しきってるプログラマーだったと証明する話の一つであることに何ら変わりないのですけれど。
まあ、なんだかちょっと、微妙に気になったという、ただそれだけの話です。珍しいのかなあ…。当時は珍しくなかったよね…。いや、でも、珍しいということにしといたほうが話が面白くなるところも…あるのかなあ。
*1: もっとも、元記事中では、「そんなやり方はどこかで破綻する」とも言っていて、それはたしかにその通りだよなと。というのも、自分も元ソースの動作の全てを把握できなくて、それが原因で結構クリティカルなバグを入れてチームに迷惑をかけてしまった体験もあるわけで。
*2: 余談。その某STGの移植作業に関しては、メインプログラマーの方がやってた、ROMのバイナリを解析してCのソースを自動で書き出しちゃう仕組み(デコンパイラ？)を作ってから移植しちゃったエピソードが、当時の自分にとっては衝撃的で。当人は、「最終版のアセンブラソースが残ってなかったから仕方なくやった」と言ってたけれど…。自分達がやってた移植作業もその方法でやれば良かった、と悔んだら、「そっちの基板はCPUが2つ並列して動いてるからちょっと難しいかもなあ」と言われた記憶も。…今ならエミュレータ作って動かしちゃうのだろうけど、当時はスペックが厳しかったから、スペックに最適化したソースを人力で書き直すのもアリ、だったのかもしれないな、とも思うけど。どこまで自動化できそうか、作業を始める前に検討して方針を決めるあたりからして、できる人は違うのだな、知識の有無がこういうところで効いてくるのだな、などと当時は再認識させられたのです。なもんで、アセンブラソースを見ながらCのソースに書き直すなんてのはフツーでしょう、プログラマーとしては凡人レベルでしょ、と思えてくるところもあったりするのでした。
*2: 余談。その某STGの移植作業に関しては、メインプログラマーの方がやってた、ROMのバイナリを解析してCのソースを自動で書き出しちゃう仕組み(デコンパイラ？)を作ってから移植しちゃったエピソードが、当時の自分にとっては衝撃的で。当人は、「最終版のアセンブラソースが残ってなかったから仕方なくやった」と言ってたけれど…。自分達がやってた移植作業もその方法でやれば良かった、と悔んだら、「そっちの基板はCPUが2つ並列して動いてるからちょっと難しいかもなあ」と言われた記憶も。…今ならエミュレータ作って動かしちゃうのだろうけど、当時はスペックが厳しかったから、スペックに最適化したソースを人力で書き直すのもアリ、だったのかもしれないな、とも思うけど。どこまで自動化できそうか、作業を始める前に検討して方針を決めるあたりからして、できる人は違うのだな、知識の有無がこういうところで効いてくるのだな、などと当時は再認識させられたのです。なもんで、アセンブラソースを見ながらCのソースに書き直すなんてのはフツーでしょう、プログラマーとしては凡人レベルでしょ、と思えてくるところもあったりするのでした。
[ ツッコむ ]
以上、1 日分です。