/* * Still like 'pnmscale' * やっぱり pnmscale が好き * by uratan! 2024.2.4 */
Netpbm の画像リサイズツールである pnmscale、 長らくお世話になって来ましたが 最近のバージョンでは PAM 対応版である pamscale にその役目が引き継がれて pnmscale 自体はディスコンになってしまいました。
pamscale を評価してみたところ、当然ながら大枠では pnmscale と同等(*1)なのですが、これまた当然ながら厳密に同じ 画像バイナリにはなりません。
(*1) pamscale では標準で輝度のガンマ補正が加わるので、 単純に pnmscale を置き換える場合には -linear オプションが必要です。
今回 家庭内サーバーのバージョンアップをもくろみ、 その結果 Netpbm 一式も新しいバージョンとなり pnmscale がない環境にならざるを得なくなりそうなんですが、 指に馴染んだ この pnmscale、同じ画像バイナリを吐くものを なんとか用意できないか？
ソースも公開されているし 簡単に持って行けるだろう と簡単に考えていたのですが、 そうは問屋が卸さなかったので その顛末を ここに記録しておきます。
(画像の一致・不一致は基本 目視確認するしかないので、 過去の画像処理を再現確認する際に md5 sum の一致で済ませられると とても楽になるのです)
以下、まずは FreeBSD 10.2-RELEASE(i386) 内で閉じた内容になります。 古くてすいません。
再現したい package版 pnmscale の手がかりは以下の通り。
Netpbm-10.35.97 の pnmscale.c のソースがこちら→ pnmscale.c-10.35.97.txt
(... スタイルはアレですが これなかなか凄いコードと思います)
「ports で make すれば それでおしまいやろ？」
... FreeBSD 10.2R install image の ports は netpbm-10.35.96.tgz ベースで version が異なります。 10.3R install image では netpbm-10.35.97.tgz ベースになってますが 現 家庭内サーバー をセットアップした頃の途中状況は今では分かりません。
そもそも 上記 file コマンドの出力の通り、package版 pnmscale は FreeBSD 10.1 で make されてるようです…？？？。 (実際には いろいろ確認したのですが ここでは省略)
「Netpbm の 10.35.97 拾ってきて ./configure; make で問題ないんちゃう？」
... やってみましたが以下の通り 同じ画像バイナリ出力にはなりませんでした。 そもそも pnmscale のサイズが明らかに違いますし、 -verbose 出力を見る感じ、少なくとも演算精度の違いはありそうです。
package版 pnmscale のコードサイズが明らかに小さいことから なんらかの最適化がかけられていると考え、追いかけたところ -O2 がかかっているような感触です。
あらら、同じ画像バイナリを生成する状況には意外とあっさり至りました。
(しかし最適化有り無しで浮動少数演算の結果が違うって いいのか？)
実行ファイルのコードも完全一致！ までは行きませんでしたが、 function は再現できていると考えていいでしょう。
% objdump -d /usr/local/bin/pnmscale > wod0 % objdump -d ./pnmscale > wod1 % diff wod0 wod1 | wc -l 32 % diff wod0 wod1 | more <-- 一部メモリ割り付けがちょっと違うだけみたい
ちなみに、FreeBSD 10.2R installe image の ports にも 10.3R の ports にも -O2 を付加する記述は見当たりません。 ports に含まれる files/patch-* のファイル自体の timestamp は リリース日近傍ですが、 中に記録されている差分元ファイルの timestamp が やけに古いので、 package版は ports とは独立に作成されたように思われます。 (patch しなくても make できてるし)
package版 pnmscale の処理自体は再現できましたが、 ただ これではコンパイラが変わったら また変わる可能性があり、 コンパイラ任せである状況は変わりません。
-O2 で いったい何が起きているのか？というわけで…、objdump も出ちゃったことだし、そう、 読みましたよ、アセンブラコードを。まあ元 C ソースがあるところで 読むだけだからパズルみたいなもんでしたけど…。
というところで、これ↓で package版 pnmscale の処理が C レベルで再現記述できたはずです。 最適化なし -O0 でも同じ画像バイナリになります。
結論的には、pnmscale.c 内で float 宣言されている変数(*2)を、勝手に double/倍精度と扱ってましたね。これは i386 の FPU が倍精度なので、 最適化により変数をレジスタ割り付けすると自動的にそうなってしまうのは まあ許そう。
(*2) pnmscale.c では 変数は基本 float です。(double も一部あり)
ただ関数がすべてその場展開されてて 関数の引数もローカル変数に成り下がり 関数の引数まで double に昇格している形になっているのは なんだかなぁ？ でしたね。
あと そうやって倍精度扱いしておきながら、レジスタ割り付けした変数を どうしてもメモリに退避しなければいけない場合に float/単精度で済ませている(*3)部分が 2ヶ所ありまして、 まあ元指定が float ですし 所詮コンパイラの最適化だからしょうがなくはあるのですが、 なんか中途半端な印象です。 (r,g,b セットのうち b だけ、つーあたりがなんとも…)(*3) メモリ上でも ちゃんと double になってる変数もあります、 fracrowtofill とか
持ち上げといて落としてるのが この 2ヶ所 (patch-pnmscale.c.txt より抜粋) *************** *** 342,347 **** --- 343,349 ---- r += fraccolleft * PPM_GETR(inputxelrow[col]); g += fraccolleft * PPM_GETG(inputxelrow[col]); b += fraccolleft * PPM_GETB(inputxelrow[col]); + b = (float)b; break; default: *************** *** 593,598 **** --- 595,601 ---- fracrowtofill = 0.0; } } + rowsleft = (float)rowsleft; makeRow(vertScaledRow, rs, gs, bs, cols, newmaxval, format); zeroAccum(cols, format, rs, gs, bs); fracrowtofill = 1.0; ***************
処理が過不足無く C レベルで記述できているか？、を 次世代 家庭内サーバーの候補として 評価中の FreeBSD 14.0R amd64 環境に持っていって確認します。 実行ファイルの長さが やや大きいですが そんなもんなのでしょう。-O2 でも -O0 でも同じ画像バイナリになりました。 これで めでたし めでたし のはず…。
アセンブラの読み下しパズルに興味のある方のために…
pnmscale.S.a18.txt (cc -S -O2 で出力した asm ソースに mark-up)
##-NNN が元 C ソースの NNN行目です。
行末コメントは
| #hs# が horizontal_scale() 部分、
| # が scaleWithMixing() 部分、
| #xM# が scaleWithoutMixing() 部分、
| #ii# は それ以外の共有部分です。
FPU の Control Word を毎回 バックアップ→設定→リストアしているあたりや、 unsigned int を FPU に読ませるため mint64 に拡張するのに high 側に 毎回 $0 を書いているあたり、 FPU の register STACK 数に余裕があるはずなので そこらあたりも有効活用できそうなあたり、に まだ高速化の余地がありそう。
10.2R の package版 pnmscale のバイナリは 14.0R amd64 下でも /etc/libmap32.conf を設定すれば そのまま動くので、素直に持ち込んで そのまま使うのが真っ当ではありますが どうしようかなぁ…。
(高速化云々以前に amd64 で make した pnmscale が 4倍ぐらい早いことに気付いてしまった、悩みは尽きまじ…)
あっ -nomix側 確認してないや…、まぁこっちはいいか 基本使ってないし…。
- * - * -
P.S.1
patch しない元ソースを 14.0R amd64 にて評価して見ましたが -O0 でも -O2 でも同じ画像バイナリを出力しますね、 勝手に double 化はしていない感触。 (でも 10.2R の -O0 とは丸め誤差的な違いが…)P.S.2
amd64 環境って、awk も 64bit になるのね…
% cat v BEGIN { printf("%04x\n", -123); for(i=29; i<34; i++) { printf("%3d: %10d\n", i, 2^i); } } .............................. % awk -f v : ちなみに i386(32bit) では ffffffffffffff85 :ffffff85 29: 536870912 : 29: 536870912 30: 1073741824 : 30: 1073741824 31: 2147483648 : 31: -2147483648 32: 4294967296 : 32: -2147483648 33: 8589934592 : 33: -2147483648