icon-gen v1.2.0 をリリースした。

• Release v1.2.0

今回の目玉は ICNS における is32 と il32 のサポート。Wikipedia の Apple Icon Image format によると ICNS は現行の macOS なら ic07 〜 ic14 があれば十分にみえる。しかし GitHub にて Mac OS X finder uses also is32 and il32 icns. という Pull Request があった。どうやら is32 と il32 も必要とのこと。これらがないと Finder のリスト表示でアイコンが消えるらしい。

この報告をうけて High Sierra 環境でリスト表示を試したものの、正常に表示されていたので古い macOS 固有の問題かもしれない。私の環境だと再現できないため Pull Request をそのまま採用しようかな？と実装を確認したところ is32 と il32 の画像部分が PNG ベタ書きになっていた。

本来、これらの画像部分は特殊な圧縮がかかっている。以前、サポートしようとしときに見つけた以下のページによれば PackBits 形式らしい。また RGBA のうち R、G、B をチャンネル単位で圧縮して A は s8mk と l8mk という対となるマスクとして別ブロックに書き込むのだという。

• OSX用アイコンファイルをWindows上で作る

このときは面倒そうだし私の環境では問題おきてないし、なにより将来なくなるであろうレガシーな形式であることからサポートは見送り。しかし Pull Request がきたのを契機に改めて PackBits 圧縮を検討してみることにした。

PackBits

PackBits は Run Length Encoding (以下、RLE) の一種である。

• PackBits

アルゴリズムとしては非常に単純なため様々な言語で実装されている。npm だと packbits が見つかった。しかしこれは String が対象。icon-gen 的には Buffer と Array、つまりバイナリーとして扱いたいので別の実装をあたることにした。その結果、以下がが癖もなく分かりやすかったので Node に移植。

• PackBits in C#

PackBits は Apple がまだ Apple Computer だった時代に圧縮と展開のサンプル データを公開しており Wikipedia にもそれが掲載されている。元コードにはテストがなかったので、このサンプルを基準としたテストを実装して正常に動作することを確認できた。

ではさっそく ICNS へ！というわけで動かしてみた。しかし出力されたアイコンを macOS の Preview で確認すると色がめちゃくちゃ。Alpha にあたる s8mk と l8mk は無圧縮なので、これにあたる透過だけが正常に描画される状態。

PackBits としてはサンプルの圧縮と展開に成功、つまり正常と思われるのだが。...もしかして PackBits 圧縮ではない？

ICNS 専用 RLE

改めて Wikipedia の ICNS ページを読みなおしたら

Over time the format has been improved and there is support for compression of some parts of the pixel data. The 32-bit ("is32", "il32", "ih32","it32") pixel data are often compressed (per channel) with a format similar to PackBits.[1]

PackBits ではなく似て非なるものらしい。出典としてあげられてる資料も確認。

• Macintosh Icons
• libicns

あらら、やはり PackBits ではないのか。RLE の一種であることは確かだけど Apple による公式な仕様はなくて Peter Stuer 氏がリバース エンジニアリングしたのだという。G. Brannon Smith 氏による Java 実装もあるらしい。

とりあえず今後の開発にそなえて is32 と il32 の実データがほしい。しかし High Sierra に付属している iconutil でアイコン生成するとこれらは存在せず、かわりに ic04 〜 ic06 が埋め込まれている。

じゃあこれらを書けばいいのでは？とバイナリー エディタで調べてみたら画像部分の先頭に ARGB とあり PNG や RLE とも異なるようだ。これについては別途調査するとして、既存アプリのアイコンならどうかと Firefox.app から持ってきたものを調べたら is32 と il32 が存在した。

テスト用に ICNS からブロックのヘッダーとボディを抽出するメソッドを実装し、

export default class ICNSGenerator {
  /**
   * Unpack an icon block files from ICNS file (For debug).
   *
   * @param {String} src  Path of the ICNS file.
   * @param {String} dest Path of directory to output icon block files.
   *
   * @return {Promise} Promise object.
   */
  static _debugUnpackIconBlocks (src, dest) {
    return new Promise((resolve, reject) => {
      Fs.readFile(src, (err, data) => {
        if (err) {
          return reject(err)
        }

        for (let pos = HEADER_SIZE, max = data.length; pos < max;) {
          const header = data.slice(pos, pos + HEADER_SIZE)
          const id     = header.toString('ascii', 0, 4)
          const size   = header.readUInt32BE(4) - HEADER_SIZE

          pos += HEADER_SIZE
          const body  = data.slice(pos, pos + size)
          Fs.writeFileSync(Path.join(dest, id + '.header'), header, 'binary')
          Fs.writeFileSync(Path.join(dest, id + '.body'), body, 'binary')

          pos += size
        }

        resolve()
      })
    })
  }
}

Firefox から当該ブロックを取得。また il32 に相当する 32x32 の PNG を得るため ic11 のボディを PNG として保存。icon-gen は SVG だけでなく PNG からも ICNS を生成できるので、これを使用して Firedox の il32 と一致するバイナリーを生成できれば OK というわけだ。

参考資料にある libicns の実装を眺めてみる。

ソース コードとしては icns_rle24.c の icns_encode_rle24_data が ICNS の RLE 処理。ありがたいことに ImageMagick といった外部ライブラリーには依存せず自己完結している。バイト配列の操作と標準関数のみで実装されているため Node にも移植しやすそうだ。

というわけで移植版を動作させたところ、出力されたバイナリーは見事にサンプルと一致した。ICNS ファイルを Preview で開いても正常に描画されている。

しかし libicns のライセンスは GPL である。icon-gen は既に MIT ライセンスで公開しており Dependents も 4。それらは MIT か Apache-2.0 なので icon-gen が libicns 移植を採用すると Copyleft により Dependents にも影響がある。

ならばスクラッチか。既に移植で元コードを読んだから完全なクリーン ルーム開発はできないが icns_encode_rle24_data にまとまった仕様がコメントされているので、これを仕様の参考にしよう。

// Assumptions of what icns rle data is all about:
// A) Each channel is encoded indepenent of the next.
// B) An encoded channel looks like this:
//    0xRL 0xCV 0xCV 0xRL 0xCV - RL is run-length and CV is color value.
// C) There are two types of runs
//    1) Run of same value - high bit of RL is set
//    2) Run of differing values - high bit of RL is NOT set
// D) 0xRL also has two ranges
//    1) for set high bit RL, 3 to 130
//    2) for clr high bit RL, 1 to 128
// E) 0xRL byte is therefore set as follows:
//    1) for same values, RL = RL - 1
//    2) different values, RL = RL + 125
//    3) both methods will automatically set the high bit appropriately
// F) 0xCV byte are set accordingly
//    1) for differing values, run of all differing values
//    2) for same values, only one byte of that values
// Estimations put the absolute worst case scenario as the
// final compressed data being slightly LARGER. So we need to be
// careful about allocating memory. (Did I miss something?)
// tests seem to indicate it will never be larger than the original

雑に翻訳。ここに引用した原文と私の訳は libicns を踏襲して GPL とする。

ICNS RLE データの仮定 :
A) 各チャンネルは次のチャンネルから独立してエンコードされる
B) エンコードされたチャンネルは以下のようになります
   0xRL 0xCV 0xCV 0xRL 0xCV - RL は Run Length で CV はカラー値です
C) 2 種類の実行 (Run)
   1) 同じ値の実行 - RL の上位ビットを設定します
   2) 異なる値の実行 - RL の上位ビットは設定されません
D) 0xRL には 2 つの範囲もあります
   1) 上位ビットの設定された RL は 3 〜 130
   2) 上位ビットの設定されない RL は 1 〜 128
      ※原文の "clr" は文脈的に clear の略 = 「設定されない」と解釈
E) 0xRL バイトは以下のように設定されます :
   1) 同じ値は RL = RL - 1
   2) 異なる値は RL = RL + 125
   3) 両方のメソッドは自動かつ適切に上位ビットを設定します
F) 0xCV はそれ (0xRL) に応じて設定されます
   1) 異なる値の場合は、すべての異なる値の実行
   2) 同じ値なら、その値を 1 バイトだけ

最終的な圧縮データはわずかに大きいため、最悪な場合のシナリオで見積もります。そのため私たちはメモリ割り当てについて注意する必要があります。 (なにか私は見落としていますか？)
テストではそれが元よりも大きくなることはないと考えられます。

これを見ながら途中まで実装したのだが、そういえばこの特殊な RLE がリバース エンジニアリングによって解明された Java 実装があるらしいことを思い出す。ならばそれもチェックしておこうかと探してみたら以下をみつけた。

• IO/RunLengthEncoding.java

ImageJ という Java の画像処理ライブラリーの一部らしい。ライセンスはコード冒頭をみるに修正 BDS。もしこれを移植して動くようなら採用しよう。

• libicns 移植版で生成されたバイト配列をテストの基準とする
• ImageJ 移植版で生成されたバイト配列がテストを満たすようにする

という条件のもとに移植。結果、テストをパスして icon-gen が出力したアイコンも正常に書き込まれていた。icon-gen v1.2.0 としてはこの実装を採用。

オマケとして libicns 移植版の圧縮処理を Gist へ公開。こちらのライセンスはオリジナルにもとづき GPL。

• RLE for ICNS

iconutil の出力形式

macOS 付属の CLI ツール、iconutil により ICNS ファイルを生成できる。使用方法と必要なファイルについては以下の記事がわかりやすい。

• Macアプリの.icnsを作るときのメモ - Qiita

さて、前述のように High Sierra と未満で iconutil が出力したファイル内の構成が異なる。icon-gen としては High Sierra 未満の ICNS を出力しているわけだが、現行のものへ正式対応する際の参考に調査した形式をまとめておく。

旧は Sierra、新は High Sierra の iconutil で出力したもの。一方にしかないものは他方を空欄してある。画像サイズは正方形だが、そうであることを明示するため WxH 形式で記述しておく。

icon-gen は旧形に準拠するが info は書き出していない。plist バイナリーを埋め込んでもよいけれど、これなしにも有効な ICNS と見なされるようなので無視している。

Issue #54 で調査した際は Safari v10.1 (12603.1.30.0.34) が旧式で Firefox 54 は旧式から ic07 と ic11 〜 ic14 が抜けた状態だった。

まとめ

長らく懸念だった is32 と il32 処理が解決されてうれしい。

ところで今回は C# (PackBits)、C 言語と Java (特殊 RLE) を移植してみたのだが Node の標準 API と JavaScript の Array が高機能なおかげで移植しやすかった。開発プラットフォームとして必要十分な機能はあるので OS やハードウェア依存の API (Win32 とか DirectX など) を使用していなければ Node は移植先として有望と感じた。

とはいえ今回は局所的な移植だったからよかったものの大規模ならどうだろう。ある時点の移植はできても本家の変更に追従し続けるのは極めて難しそう。sqlite3 は移植ではなく node-gyp による wrapper となっているのは、この事情を踏まえてのことだろう。

などと考えていたらタイムリーな記事がはてブのホット エントリーにあがっていた。

• WebAssemblyをNodeJS Native Addonの配布形式として使う

C 言語の実装を kripken/emscripten で WASM にビルドして npm 配布したのだという。これは面白い。

Node は v8.0.0 から、Chrome も v58 から WASM に対応している。Electron でいうと v1.7.0 で Chrome v58、v1.8.0 から Node v8.2.1 を採用しているため、Electron v1.8 系なら Main/Renderer プロセスのどちらでも WASM を使用できるはず。

つまり豊富な C 言語の資産を流用しやすくなるのだ。すばらしい。

WASM は機能の縛りが厳しいため移植を完全に自動化するのは難しいだろうけど、そのへんは emscripten のような周辺ツールが解決すると予想している。例えば File I/O などが含まれていたら WASM とその wrapper で分担・抽象化するとか。

例えば前述の SQLite が WASM 化されたなら Electron アプリに組み込みやすくなるだろう。WASM はパフォーマンスよりもこのような移植方面で期待している。