アカウント名:
パスワード:
Firefox 3.5ではオープンソースものとしてはデファクトスタンダードな変換エンジンのLittle CMS（v4プロファイルにも対応）を使っていましたが、3.6では自前のエンジンに移行し、これに伴ってICCプロファイルのサポートが縮小される結果となっています。
"Firefoxがqcmsに移行した理由 - Mozilla Flux" [hatena.ne.jp]からの引用：
lcmsからqcmsに移行した理由について、最近、開発担当者のJeff Muizelaar氏が『qcms - color management for the web』の中で語っている。興味深い内容なので紹介したい。Muizelaar氏によると、もともとFirefoxはlcmsの機能のごく一部しか利用していなかったのだそうだ。にもかかわらずlcmsのコードすべてを抱えていたため、メンテナンスやセキュリティの面で難があった。とくに、lcms のコード自体にも手を入れていたことで、メンテナンスの負担が大きかった。また、開発を進めるうちに、次第に設計思想の違いが明らかになってきた。 Muizelaar氏らは高速で安全なシステムを求めているのに、lcmsは機能性、完全性と正確性に重点を置いていた。そこで、高速かつ安全・堅牢なシステムとして開発されたのが、qcmsというわけだ。Firefoxのニーズに特化して無駄をそぎ落としただけあって、ライブラリのサイズは10分の1 になったという。（略）…とはいえ、この優れたqcmsにも欠点は存在する。それは、RGB色空間どうしの変換にしか対応していない点だ。Webでの利用の大部分はこれでカバーできるそうだが、CMYKその他のプロファイルを埋め込まれた画像には、カラーマネジメントが効かない。
lcmsからqcmsに移行した理由について、最近、開発担当者のJeff Muizelaar氏が『qcms - color management for the web』の中で語っている。興味深い内容なので紹介したい。
Muizelaar氏によると、もともとFirefoxはlcmsの機能のごく一部しか利用していなかったのだそうだ。にもかかわらずlcmsのコードすべてを抱えていたため、メンテナンスやセキュリティの面で難があった。とくに、lcms のコード自体にも手を入れていたことで、メンテナンスの負担が大きかった。また、開発を進めるうちに、次第に設計思想の違いが明らかになってきた。 Muizelaar氏らは高速で安全なシステムを求めているのに、lcmsは機能性、完全性と正確性に重点を置いていた。
そこで、高速かつ安全・堅牢なシステムとして開発されたのが、qcmsというわけだ。Firefoxのニーズに特化して無駄をそぎ落としただけあって、ライブラリのサイズは10分の1 になったという。（略）
…とはいえ、この優れたqcmsにも欠点は存在する。それは、RGB色空間どうしの変換にしか対応していない点だ。Webでの利用の大部分はこれでカバーできるそうだが、CMYKその他のプロファイルを埋め込まれた画像には、カラーマネジメントが効かない。
現行のFirefoxに載っているものに関して補足すると、引用に書かれているとおり、v2プロファイルであってもCMYKなどはサポートされていませんし（それ以前にRGB以外の画像を正しく読み込める必要がありますが）、RGBでもLUTベースのプロファイルなどは使えなかったと思います。
印刷用データをwebにそのまま貼り付ける人も結構見かけるのでCMYKのサポートは是非早めの実装を期待したいところ。webにのっけて画像が見れないーと言う人のところに行くと7割くらいがこれ。個人的経験ですが。
ICCv4もlcmsでサポートしてたのにqcmsへの移行で無くなったうえに、ここまでの意思決定プロセスが見えづらく十分な合意形成がなされてるとは思えなかったんですよね。セキュリティが主な理由とはいえ、この辺は困惑する人も出てくるだろうと。や、もちろんセキュリティをおろそかにするわけじゃないんですが、写真を扱う人には不利にならざるを得ないでしょうね。
# 大本の原因は色の仕組みそのものが複雑すぎるところかもしれませんね。カラーマネジメントシステムとしてうまく実装できないとlcmsみたいな状態に(失礼、大変な作業なのは重々承知)。。。ColorSyncはそう思うとよく出来てる。
qcms移行のタイミングも外野から見ると唐突でしたし、合意形成については疑問が残りますね……。
野暮なツッコミではありますが、Little CMSはICMやColorSyncでいうところのCMMにあたるものに近いので、そもそもColorSyncを引き合いに出すのには難があります。システムにお任せで勝手にカラーマネジメント対応、といった具合にいかない代わりに移植性の高さやアプリケーション側からのコントロールの自由度などを獲得できるのは妥当なトレードオフだと思います※。
※後者についてはICMやColorSyncも低レベルなAPIでカバーしていますが、CMMの機能がAPIに拘束される可能性があるでしょう。
あと、セキュリティの件については、有力な競合が不在な現状、年々lcmsのユーザーが増え多くの目に触れるようになったことと、開発リソースの不足が背景にあるかと思います。コードが書けてかつICCの仕様書や関連技術に精通した人材がどれだけいるのか、というのは不安材料のひとつですね……
リファレンス見てみたらOS X 10.5で低レベルAPIが軒並み廃止されてました……。
はっきり言わせていただけば、Mozilla独自開発のqcmsの出来に現在のMozillaの実力がよく現れてると思いますよ。ICCプロファイルのライブラリはモニタやプリンタのプロファイルも処理しなければならないのに「Webで使われている画像」とやらだけを基準にサポート範囲を決めるとかアホの極み。Chromeに追いつけそうな気配すら見せずむしろ引き離されるばかりでとうとうIE9にまで追い抜かれてしまったJavaScriptエンジンの性能もそうですね。TraceMonkeyの元になったTamarinはAdobeから、JaegerMonkeyのアセンブラの元になったNitroはAppleからのもらい物ですし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
Mozillaのやる気のなさは異常 (スコア:3, 興味深い)
Re: (スコア:1, 興味深い)
日本とアメリカ以外はよく知らないのですが、LZWの特許はすべての国で切れているんですか?
TIFFって自由度が高過ぎて、書き出すのは簡単でも読むのが大変なんですよね。
でもつべこべ言わず一般的なフォーマットだけでも読めるようにして欲しいとは思います。
JPEG200について。
特許があるし、特許を無視したってFireWire並にAppleしか使ってないでしょ。
ICCv4について。
これも詳しくないけど特許とか無いの?
AppleはColorSyncでICC以上の技術を培っていそうなので、対応出来るのでしょう。
H.264は書かれている通り言うまでもないし、挙げられているリストの半分は文句を言ったら可哀想な項目。
# そんな私はSafari&Chrome使い
ICCv4の件 (スコア:2, 興味深い)
Firefox 3.5ではオープンソースものとしてはデファクトスタンダードな変換エンジンのLittle CMS（v4プロファイルにも対応）を使っていましたが、3.6では自前のエンジンに移行し、これに伴ってICCプロファイルのサポートが縮小される結果となっています。
"Firefoxがqcmsに移行した理由 - Mozilla Flux" [hatena.ne.jp]からの引用：
現行のFirefoxに載っているものに関して補足すると、引用に書かれているとおり、v2プロファイルであってもCMYKなどはサポートされていませんし（それ以前にRGB以外の画像を正しく読み込める必要がありますが）、RGBでもLUTベースのプロファイルなどは使えなかったと思います。
Re:ICCv4の件 (スコア:2, 興味深い)
印刷用データをwebにそのまま貼り付ける人も結構見かけるので
CMYKのサポートは是非早めの実装を期待したいところ。
webにのっけて画像が見れないーと言う人のところに行くと7割くらいがこれ。個人的経験ですが。
ICCv4もlcmsでサポートしてたのにqcmsへの移行で無くなったうえに、ここまでの意思決定プロセスが見えづらく十分な合意形成がなされてるとは思えなかったんですよね。セキュリティが主な理由とはいえ、この辺は困惑する人も出てくるだろうと。
や、もちろんセキュリティをおろそかにするわけじゃないんですが、写真を扱う人には不利にならざるを得ないでしょうね。
# 大本の原因は色の仕組みそのものが複雑すぎるところかもしれませんね。カラーマネジメントシステムとしてうまく実装できないとlcmsみたいな状態に(失礼、大変な作業なのは重々承知)。。。ColorSyncはそう思うとよく出来てる。
Re:ICCv4の件 (スコア:1)
qcms移行のタイミングも外野から見ると唐突でしたし、合意形成については疑問が残りますね……。
野暮なツッコミではありますが、Little CMSはICMやColorSyncでいうところのCMMにあたるものに近いので、そもそもColorSyncを引き合いに出すのには難があります。システムにお任せで勝手にカラーマネジメント対応、といった具合にいかない代わりに移植性の高さやアプリケーション側からのコントロールの自由度などを獲得できるのは妥当なトレードオフだと思います※。
※後者についてはICMやColorSyncも低レベルなAPIでカバーしていますが、CMMの機能がAPIに拘束される可能性があるでしょう。
あと、セキュリティの件については、有力な競合が不在な現状、年々lcmsのユーザーが増え多くの目に触れるようになったことと、開発リソースの不足が背景にあるかと思います。コードが書けてかつICCの仕様書や関連技術に精通した人材がどれだけいるのか、というのは不安材料のひとつですね……
ColorSyncの低レベルAPI (スコア:1)
リファレンス見てみたらOS X 10.5で低レベルAPIが軒並み廃止されてました……。
Re: (スコア:0)
はっきり言わせていただけば、Mozilla独自開発のqcmsの出来に現在のMozillaの実力がよく現れてると思いますよ。
ICCプロファイルのライブラリはモニタやプリンタのプロファイルも処理しなければならないのに「Webで使われている画像」とやらだけを基準にサポート範囲を決めるとかアホの極み。
Chromeに追いつけそうな気配すら見せずむしろ引き離されるばかりでとうとうIE9にまで追い抜かれてしまったJavaScriptエンジンの性能もそうですね。TraceMonkeyの元になったTamarinはAdobeから、JaegerMonkeyのアセンブラの元になったNitroはAppleからのもらい物ですし。