オープンソースの PNG 画像変換・軽量化アプリケーション「colopresso」を公開しました

こんにちは、エンジニアの工藤です。

実は結構前から GitHub にて公開していたのですが、今回はオープンソースの PNG 画像変換・軽量化アプリケーション colopresso について、開発の経緯や開発における AI の活用についてご紹介させていただきたいと思います。

colopresso アプリケーションの画面

github.com

基本的には PNG が使われる世界

画像フォーマットと言われると、大体の人は GIF, JPEG, PNG, TIFF を思いつくのではないでしょうか。これらは古くからあるフォーマットで、今もなお現役で使われています。特に扱える色数が多く、半透明を表現できる PNG は今もなお非常によく見かけるフォーマットだと思います。

ただし、 PNG の規格が出来たのは 1996 年のことです。なんと私がまだ 2 歳のころです。当然、その当時のコンピュータの性能は今よりも遥かに低く、 効率は良いが、処理負荷が高すぎる ような圧縮処理は行えませんでした。

また、 PNG は 可逆圧縮方式 しかサポートしておらず、 JPEG のように画質劣化を許容し、圧縮率を優先するという手法が取れないという問題もあります。元々 PNG は GIF が特許的な問題を抱えていたことから制定されたフォーマットであったので、同様の特性を持つ GIF 同様、そのあたりは考慮されなかったのではないかと思います。

PNG をなるべく小さくする技術たち

上記の理由から、 PNG を利用しつつ、なるべくファイルサイズを小さくする という需要が長らく存在していました。そこでまず目をつけられたのが 8-bit color palette フォーマット でした。

8-bit color palette フォーマットは、ファイルあたりで使う色数を 256 色に制限し、カラーパレット手法を用いることでファイルサイズを小さくできるエンコード方式です。カラーパレット方式について説明すると長くなるので省略しますが、この方法を用いることで、具体的には 1MiB 程度のものが 100KiB 程度にまで縮小できたりします。

ただし、 32-bit フルカラーの PNG を愚直に 256 色にすると、画像のグラデーションはバンディング (波状の模様が見える) を起こし、元画像からの色変化も激しく、まともに見られたものではなくなってしまいます。

しかし、ここでディザリング (色が混ざる部分であえて離れた色のノイズを入れることで、視覚的に劣化がわかりにくくなる手法) や、その画像において一番印象を目立たせたい色をパレットに強制的に追加する (保護色指定) をすることで、 サイズの削減効果は一定維持しつつ、目視ではオリジナルに相当近く見える ようにできます。以下が実際の例となります。

オリジナル画像 (1.3 MiB)

オリジナル (1.3 MiB)

愚直に 8-bit color palette 化 (106 KiB)

愚直に 8-bit color palette (106 KiB)

colopresso デフォルト設定で `256 色パレット` (8-bit color palette) モード (333 KiB)

colopresso 256 色パレットモード (333 KiB)

colopresso の 256 色パレット モードがオリジナルからファイルサイズを圧倒的に削減しつつも、単に 256 色に減色したものより視覚的劣化が少ない ことがわかると思います。

コロプラにおける `PNG` の運用課題

コロプラでは、お知らせ等での通信量をなるべく減らすべく、掲載する画像は基本的に全て 8-bit color palette モードに減色するようにしています。

ただし、プロジェクトやキャラクターごとの固有の減色設定を適用するため、社内に設定された減色マシンの Jenkins に対し、フルカラー PNG をアップロードし、処理を待つ、という方法を取っていました。

しかしこれでは全てのプロジェクトが一つのマシンを共有して使うため、ピーク時間帯には結果待ちに長い時間がかかることや、長い時間待った後の結果が好ましいものではなく、再度調整が必要になるなど、デザイナー・プランナーにとって大きな負担となっていました。

移りゆく Web における画像フォーマット

一方、 Web の世界が進歩するに伴って、従来一般的だった GIF, PNG, JPEG 以外にも様々な画像フォーマットが用いられるようになってきました。これらのフォーマットはより先進的な圧縮アルゴリズムを有していたり、非可逆圧縮でも透明度を扱えるなど、様々なメリットがあります。代表的な例としては次のようなフォーマットがあります。

`WebP`

Google が開発。 PNG / GIF / JPEG の良いとこ取りをしたフォーマットで、 VP8 (WebM) をベースとしています。

Google は VP8 に関する特許ライセンスを有していますが、ロイヤリティフリーで利用可能です。 (Google によって一方的に取り消し可能であるという制約付きではあります)

`AVIF`

Google や Amazon, Netflix 等が集結し結成された Alliance for Open Media によって開発された AV1 動画コーデックをベースとしたファイル形式で、こちらもロイヤリティフリーで利用できるものとなっています。

`HEIC` / `HEIF`

Moving Picture Experts Group (MPEG) が開発した H.265 HEVC 動画コーデックをベースとしたファイル形式です。ただし、 パテントフリーではないフォーマットです。

これらはどれも従来の画像フォーマットに対し圧倒的な圧縮率と機能を持っており、特に 非可逆でも透明度が扱える のが大きなポイントとなっています。つまり、 減色等を行わずとも、透明度を維持しつつ小さなファイルサイズに縮小できる時代が到来した のです。

コロプラにおける「画像減色運用」を変えよう

上記の件からも、コロプラにおいても「使う画像フォーマットをそろそろ変えたい」という意見が出てくるようになりました。手間の問題もさることながら、 256 色に減色されてしまうことはデザイナーからしても不本意であり、何よりユーザー様に届けたいものが届けられない状況は好ましくないと考えました。そこで、代替としてどのフォーマットを採用するか、という話が浮上しました。

これら新規フォーマットの中でも最も互換性が高いのは HEIC / HEIF です。 iPhone / iPad では iOS 11 から対応しており、ほとんどの端末で利用可能です。(Android は Android 5 以降、 OS と WebView コンポーネントが分離され、常に最新の Chromium コンポーネントを利用可能になっており、ほぼすべてのフォーマットに対応しています)

しかし HEIC / HEIF には大きな問題があります。

これらのフォーマットは H.265 HEVC 動画フォーマットをベースとした技術であり、 H.265 HEVC は数多くの特許が数多くの企業によって抑えられています。 これらを商業的に適切に利用するためには特許ライセンスの取得が必要ですが、 H.265 HEVC の特許については統括的な管理をする団体がなく、 多数のパテントプールから個別に特許ライセンスを取得しなくてはいけません。

もちろん、ライセンスを結ぶということは 利用料を支払わなくてはならない ということにもなります。なので、代替にはなり得ませんでした。また、そもそも Android の WebView で使われる Chromium は上記の理由からか HEIC / HEIF の表示には対応しておらず、その点でも利用は不可能 と判断しました。

Apple は iOS 14 で WebP フォーマットのサポートを追加しました。 WebP フォーマットは Google が開発した VP8 (WebM) ビデオコーデックを元にしたフォーマットであり、その利用にあたっては Google がロイヤリティフリーで特許ライセンスを提供 (ただし、取り消しは可能としている) しており、 使うに当たってのライセンス的なハードルはほぼないものと考えられます。

同様に AVIF も Apple は iOS 16 からサポートを開始しており、新規タイトル等であれば利用しようと思えば利用できる環境は整いつつありますが、 GitHub / GitLab で diff 表示ができない、 Slack でプレビュー表示ができない (2026-03-25 時点) など、運用フロー上の問題もあり、利用するにはまだ厳しい状況といえます。

さて、ひとまず移行先のフォーマットは WebP に決まりました。次は、社内のエンコードフローが抱える問題にはどう対応していくかを考えるターンです...

Photoshop で書き出せる、けど...

WebP はロイヤリティフリーであり、 Photoshop から書き出すことも可能です。しかし Photoshop から書き出したデータは余計なメタデータが付与されていたり、そもそもデザイナーからすれば Photoshop では 無劣化の画像に限りたい し、 品質を維持するための圧縮率を計算するなども難しい という問題がありました。

そのときはちょうど私が AI イネーブルメントチームに異動した時だったので、せっかくだから、ということで GitHub Copilot を利用して画像エンコードユーティリティを作成することとしました。

技術選定・設計方針決定

まず、エンコードにあたっては公式のライブラリである libwebp を利用することとしました。これは C 言語で書かれた WebP デコード・エンコードライブラリです。

次にアプリケーションの動作形態を考えます。コロプラでは macOS / Windows どちらも使っている人が居るので、クロスプラットフォーム対応は必須要件です。

ここで一つの問題が生じます。 libwebp は C 言語のライブラリであり、クロスプラットフォーム対応するためにはそれぞれ別のアプリケーションを作成する必要が生じます。 つまりメンテナンスコストが倍になるということで、現実的ではありませんでした。

そこで Emscripten を用いた JavaScript / WebAssembly としてのビルドを行う設計に変更しました。これにより、 JavaScript / WebAssembly が動く環境であればどこでも動作する ことになります。ただ libwebp は直接利用するには手間となる部分が多いので libcolopresso というラッパーライブラリを C 言語で作成し、それが提供する API を呼び出す形とするようにしました。

JavaScript / WebAssembly が動かせる、社内で誰でも使っているアプリケーション...ここで一旦、 Chrome 拡張機能として作成することを決定しました。

Chrome 拡張の制限事項、そして Electron へ...

実装は無事完了し、 Chrome 拡張として一つのプロジェクトにてデザイナーによるトライアル検証をしてみてもらうこととなりました。しかし、ここで Chrome 拡張機能では要件を満たせない ことが発覚します。

というのも、 Chrome 拡張機能は安全性の都合上、ファイルシステムへのアクセスが不可能であり、あくまでも拡張機能にアップロードされたファイルに対する処理と、処理結果はダウンロードするしかないためです。大量の PNG ファイルを処理すると、ダウンロードフォルダが処理された WebP ファイルで埋まってしまいます。これでは運用が難しい、というのが率直な意見でした。

そこで、 Electron を用いた Web ベースのデスクトップアプリケーション とすることとしました。これによってファイルアクセスが可能になり、要件を満たすことができるようになりました。

ここで、デスクトップ版 colopresso が生まれることとなりました。

`WebP` が使えないプロジェクトが！

さて、 WebP へのエンコーダーが出来た、やったね！と思っていたのですが、 運用中のタイトルでは iOS 14 未満をサポートしているものも多く、単純に WebP に全面移行できないことが発覚しました。

また、テクニカルアーティストの方から 「colopresso をもっと汎用的にし、すべてのプロジェクトで使える共通ツールにできないか」 という熱いメッセージを頂き、 WebP 以外にも PNG の減色に対応し、ついでだから AVIF libavif を用いて対応することとしました。

難しい `PNG` 減色の世界...　Rust と C 言語の繋ぎこみ

PNG の減色といえば、昔 pngquant というソフトウェアがあったことを思い出しました。そういえばライブラリとしても提供されていたよな、と調べてみると、どうやら現在は libimagequant と oxipng というライブラリが標準的に使われているようです。でもこれ、 なんとどちらも Rust で書き直されています！とってもモダン！

モダンなのはいいのですが、 Rust <-> C 言語間でやり取りするのはなかなか難しく、苦戦することとなりました。最終的には cbindgen を用いて C 言語用のバインドを生成しつつ、 pngx_bridge という Rust クレートを作成した上で、そこから libcolopresso と繋ぎこむような構造を取ることとしました。

また、 libimagequant と oxipng は優秀な 8-bit color palette 減色機能を提供していますが、特定のパターンでは好ましい結果が得られないことも多く、入力された画像をヒューリスティック解析し、各種パラメータを適切に設定するような仕組みも必要となりました。過去の 8-bit color palette エンコードされた画像とオリジナル画像、 colopresso を利用した 8-bit color palette 画像の PSNR / SSIM を計測し、ひたすらチューニングすること 1 週間、 ほぼすべてのパターンで既存の仕組みより高品質な 8-bit color palette PNG を出力できるようになりました。

ライセンスと OSS 化

さて、無事 colopresso に PNG 減色と AVIF エンコード対応が入ったわけですが、利用させてもらった libimagequant は GPLv3 ライセンスです。つまり、利用にあたってはコードの公開が必要です。というわけで colopl/colopresso としてオープンソースで公開することとしました。(GPLv3 ライセンスについては企業内のみで利用する分には公開義務はないなど様々な見解・議論はありますが、社外への配布やOSSとしての透明性を考慮し、公開することとしました)

かくして、 colopresso はオープンソースのツールとなりました。

https://github.com/colopl/colopresso

ネイティブ CLI 対応

さて、 GUI 版の colopresso は完成したわけですが、いくら WebAssembly を利用しているとはいえ、 Electron 上での動作速度には限界があります。大量のファイルをバッチ処理したい、既存のツールに組み込みたいなどの場合、そもそも GUI は不要で CLI が欲しいという話もありました。

というわけで、ネイティブ CLI 版も用意することとなりました。 全ての CPU アーキテクチャの Windows, macOS, Linux に対応しています。 また、 Linux 版は musl-libc を用いて libc 含めて静的コンパイルすることで、 完全なシングルバイナリ になっています。

社内からの反響

colopresso の社内からの反響は予想以上で、現場の方々からとても楽になった、画質が綺麗で嬉しいと好評を頂いています。自分でも何より驚くのは、 これがたった 1 ヶ月の間の出来事だった ということです。 Copilot による開発補助はとても強力で、驚くほど迅速に完成までたどり着くことが出来ました。