Firefox 3.5では、カラーマネジメント機能がデフォルトでオンになる。画像の情報とモニターの情報を利用して、色の表示が正しくなるよう調整する機能である。同機能はFirefox 3にも実装されているが、主にパフォーマンス上の問題により、使用が控えられていた（『Firefox 3でカラーマネジメント機能がオフの理由』）。Firefox 3.5の開発過程でプログラムのアーキテクチャを見直し、プリキャッシュの方法を工夫し、SSE2最適化用のコードをチューニングすることで、問題は克服された。
この時点で、カラーマネジメントシステムはLittle CMS（lcms）をベースにしていた。しかし、今年4月になって、Firefoxは独自開発のqcmsに乗り換えた（『カラーマネジメント・コンポーネントの更新』）。コードを全面的に変更する思い切った措置だった。
lcmsからqcmsに移行した理由について、最近、開発担当者のJeff Muizelaar氏が『qcms - color management for the web』の中で語っている。興味深い内容なので紹介したい。
Muizelaar氏によると、もともとFirefoxはlcmsの機能のごく一部しか利用していなかったのだそうだ。にもかかわらずlcmsのコードすべてを抱えていたため、メンテナンスやセキュリティの面で難があった。とくに、lcmsのコード自体にも手を入れていたことで、メンテナンスの負担が大きかった。また、開発を進めるうちに、次第に設計思想の違いが明らかになってきた。Muizelaar氏らは高速で安全なシステムを求めているのに、lcmsは機能性、完全性と正確性に重点を置いていた。
そこで、高速かつ安全・堅牢なシステムとして開発されたのが、qcmsというわけだ。Firefoxのニーズに特化して無駄をそぎ落としただけあって、ライブラリのサイズは10分の1になったという。そのqcmsは、ICCプロファイルパーザと変換エンジンによって構成されている。
新パーザは、lcmsの入出力抽象化レイヤーのような複雑なモデルを採用せず、プロファイル全体をメモリに読み込んだ後、解析してプロファイルオブジェクトを構築し終わったら、プロファイル情報を保存したメモリを解放する。このモデルによって処理がシンプルになっただけでなく、ファイル入出力に関する問題からも解放された。
また、エラー処理のストラテジーをcairoグラフィックスエンジンのそれに近いものへと変更した点も新しい。結果、コードが読みやすく、処理を推測しやすくなり、テストも容易になった。セキュリティホールを減らすことにつながり、万が一発見された際も対処が早くなるだろう。
スピード面も進歩もめざましい。処理の簡素化とともに、lcmsをベースにしていたころに培った高速化の手法を再利用することで、なんと従来比で5倍の高速化を実現したという。Muizelaar氏が最速のカラーマネジメントシステムと自慢するゆえんだ。
とはいえ、この優れたqcmsにも欠点は存在する。それは、RGB色空間どうしの変換にしか対応していない点だ。Webでの利用の大部分はこれでカバーできるそうだが、CMYKその他のプロファイルを埋め込まれた画像には、カラーマネジメントが効かない。
たとえば、Firefox 3.5 Beta 4で『Is your system ICC Version 4 ready?』にアクセスすると、「v4 e-sRGB」と「v4 YCC-RGB」が正しく処理されないのがわかる。e-sRGBは「Extended RGB color space」を指すのでRGB色空間の範囲を超えており、YCC-RGBはYCbCr色空間への変換を伴うので「RGB色空間どうし」ではなくなる。結局、この制約がICC Version 4に未対応という状況を生んでいるのだ。
Firefox 3.5正式版のリリースが近づいている今、ICC Version 4をサポートすべくコードを書き換えるのは無理である。しかし、Firefox 3でも設定をオンにすれば正しく表示されていた画像が、そうでなくなるのは困った事態だ。Firefox.nextを待つことなく、3.5.xのリリースで対処してもらいたいものである。
