2007年12月16日 (日)

ソフトウェアの最適化ビルド

CPUのアーキテクチャに最適化したソフトウェアは、どれほどのパフォーマンスの向上をもたらすのだろうか?最近はIntelのデュアルコアCPUが大幅な性能向上を果たしたが、仮にソフトウェアをビルドする過程でCPUの新しいアーキテクチャを活かしきれていないとしたら、それはもったいないことだ。

最適化という意味では二つの岐路がある。一つはコンパイラの選択、もう一つはコンパイルオプションの選択。前者に関しては、いくつかのウェブサイトで比較を見ることができる。GNUコンパイラに比べて、インテルの商用コンパイラは非常に良い結果を出すらしい。(一方、GNUコンパイラは、バージョン4.0および4.1ではIntel Core Duoを使った場合に僅かに3.3より改善、それ以外のCPUではバージョン3.3より良い性能は出ないらしい。4.2になってやっとましになったとのこと。)

残るコンパイルオプションの選択は、ソフトウェアの演算能力をどう変えるのか。Intel Core Duo 2.0 GHzを搭載した Macbook Proで実験してみた。今回取り上げるソフトウェアは、画像処理の ImageMagick である。

比較したのは次の二つである。

(ア) Mac OS X 10.4 に付属のGNUコンパイラ 4.0.1を用い、最適化フラグは -O2 だけでビルドしたImageMagick 6.3.7

(イ) GNUコンパイラ 4.2.2を用い、Core Duo向けの最適化フラグとして -pipe -O2 -march=prescott -msse3 -fomit-frame-pointer を用いてビルドしたImageMagick 6.3.7

純粋に最適化オプションだけの比較でなく、むしろMac OSのデフォルトの開発環境と、新しくて性能にも留意した開発環境との比較ということになる。

ImageMagick の convert コマンドを用い、5016 x 7602 ピクセルの大きさの 16 bit TIFF形式の画像ファイルを、unsharpマスクをかけて縮小し、その時間を計測した。それぞれの実施前にはコンピュータを再起動し、ほどなく実験を行っている。Unsharpマスクには、Catromを選択した。Catrom自体がどのような計算をしているのか私は詳しく知らないが、積分及び行列計算が多くを占めると想像している。これが、最適化の検証に ImageMagick を用いようと思った一つの動機である。

結果は、50%に縮小した場合(convertのunsharpパラメターは9x1.4+1.0+0.02を使用。演算量は多いはず)

(ア) 1分6秒56
(イ) 1分5秒11 (-1.45秒)

12.5%に縮小した場合(unsharpパラメターは2.3x0.43+1.0+0.02)

(ア) 33秒86
(イ) 34秒73 (-0.87秒)

となった。計測時間には、241MBもの大きさのファイルの読み込みから、書き出しまでが含まれるので、演算自体の所要時間は分からないが、いずれにせよ目立った改善にはならなかった。

ImageMagick は MacPorts を使って導入している。MacPortsに登録された多くのソフトウェアが、デフォルトでは(ア)の条件でビルドするように設定されており、(イ)の条件を適用するのは少々面倒なのだが、その設定をするだけの価値は気休め程度でしかないということだ。性能向上のためなら、Intelのコンパイラを用い、半年でもあとに発売されたコンピュータを用いるほうが効果的だ。

| | コメント (0) | トラックバック (0)

2007年12月 7日 (金)

ウェブブラウザのカラーマネジメント(2)

前回の記事では、ブラウザを巡るカラーマネジメントについて書いたが、図らずも「(Vistaより前の)WindowsはsRGBで統一されている」という一般知識に反することになった。自分でも俄に信じられなかったので、今回はその点を検証する。

おさらいがてらに、その命題をもう少し正確に書くと、次のようになる。

  • Vistaより前のWindowsでは、ビューアーを例外とした、システム付属の全てのアプリケーションにおいて、画像のカラースペースがsRGBであることを前提とする。すなわち、Windowsの内部では、全ての画像のカラースペースを強制的にsRGBとして解釈する。これはFirefox 2でも同様である。

  • よって、画像がsRGBというICCプロファイルを持つか持たないかに関わらず、sRGBのカラースペースで作成された画像は正しい色で出力される。(ここのでの「出力」とは、アプリケーションのものであって、ディスプレイやプリンタとは無関係)

これが仕様としてだけでなく結果的にも正しいなら、先の記事でテストしたsRGBの写真は、Windowsのどのアプリケーションでも正しく同様に表示され、また、他のカラーマネジメントされたシステムとも、外部出力時の違いは割り引いても、ほぼ同じに見えなければならない。

ところが、実際に検証してみるとその通りではなかった。

下の表は、3種類の画像を、それぞれWindows XP上の3つのアプリケーションで表示させた時の色再現をまとめたものである。一枚目の画像は、sRGBの色空間を持ち、かつsRGBのICCプロファイルが埋め込んであるもの。二枚目の画像は、sRGBの色空間を持つが、ICCプロファイルは持たないもの。三枚目の画像は、Adobe RGBの色空間を持ち、かつAdobe RGBのICCプロファイルを持つものである。(これらの画像はMac OS XとPhotoshopで用意した。)評価に用いたアプリケーションは、Internet Explorer 6 (IE 6)、OS付属のビューアー、それからカラーマネジメント機能をオンにしたFirefox 3である。(正確な比較のために、Firefox 3のモニタプロファイルに合わせた色変換機能はオフにした。)

Windows XPでの色の再現評価

先に述べたWindowsの流儀から考えると、一枚目(「sRGB」)と二枚目の画像(「なし」)は、3つのアプリケーションのどれを使っても同じ見え方をしなければならない。しかし、「なし」の画像は、IE 6とビューアーで見ると、明らかに色褪せて見えた。即ち、プロファイルがない画像をWindowsが強制的にsRGBとして解釈する方法は、上手くいっていないということだ。(万一、他に原因があり、その解決によってsRGBの色再現を本来のものにする方法があれば、ご教示頂きたい。)

次に、それではsRGBのICCプロファイルが埋め込まれているなら正しい色が表示されるのか、という問題はどうだろう。sRGBのプロファイルを持つ画像(「sRGB」)の色再現には、「良」と「最良」の2種類を示しているが、実は、この二つには明らかな相違があったのだ。この「良」が意味する所は、カラーマネジメントの対象にはなっているようだが、あるべき色の再現ではなかった、というほどのものだ。見る限り正しい再現をしていたのはFirefox 3だけだったのだ。Firefox 3の表示は、同じ画像をMacで見た時のものと同じだった。(参考までに補足すると、評価に用いたWindows XPは、Macbook ProからBootcampを用いて起動している。また、Mac OSでもWindowsでも、モニタのキャリブレーションを行っている。つまり、表示デバイスが同じで、特性も揃えてあるから、私の見た目による色評価は、OSとアプリケーション自体の色再現能力の評価に他ならない。)前回の記事は正しかったことになる。

さらに興味深いのは、「良」と一括りに評価したものが、必ずしも同じ見え方ではないことだ。同じsRGBのカラースペースを持った一枚目と二枚目の画像に限っても、IE 6とビューアーでは、判別が困難なほどではあるが、違いがある。また、二枚目の画像をFirefoxで見た時は、一枚目の画像をWindowsアプリケーションで見た時の「良」ほどではないながら、「不可」の場合よりは良い結果であった。これは、Windowsにおいては、色の管理がアプリケーションレベルでの実装に委ねられてきたという点と符合する。

一枚目と三枚目では、そもそもカラースペースの広さが違うので、それに対応してAdobe RGBの「良」はsRGBの「良」を上回った。

結論を再確認すると、Windows XPにおいては、OS及びアプリケーションレベルでのsRGBへの色の統一すら不完全である。よって、画像が持つカラースペースがsRGBであっても、sRGBというICCプロファイルは埋め込むべきである。また、ブラウザはFirefox 3か、Safariを使うべきである。

| | コメント (2) | トラックバック (0)

2007年12月 5日 (水)

ウェブブラウザのカラーマネジメント(1)

コンピュータでのカラーマネジメント(色管理)については、他に分かりやすく体系的に説明したウェブサイトがあるので、齧った程度の私が頑張ってBlogに書くこともない。ただ、カラーマネジメントができていない場合に、写真によっては、とてつもなく元と違う見え方をすることは是非書いておきたいと思った。

これは近頃、フィルムをスキャンしてラボでプリント、あるいはインターネットに掲載するようになって、非常に気にするようになったからだ。愛着のある写真が、他のコンピュータでは全く異なって見えると、少なからずショックを受ける。

他のコンピュータでの見え方と言う時、カラーマネジメントには二つの側面がある。一つは、あるICCカラープロファイル(sRGB、AdobeRGB、 PhotoRGBといった、カラースペースに関する情報)を持った写真をアプリケーションが正しく出力すること。もう一つは、そのアプリケーションの出力を、さらにモニタの特性に合わせて変えることだ。後者はモニターのキャリブレーションの問題で、それなりの質のモニタと、キャリブレーション用のハードウェアを買わないとできないことだ。しかしながら、前者はOSとアプリケーションの問題であり、これが正しく行われないというのは、一連のカラーマネジメントの根幹に関わる。Photoshopなどで色を調整したくても、モニタなりプリンタなり、それぞれ異なる特性を持つ機器を通った後の色を見ながら、勘に頼ってやらざるを得ないからだ。

それなのに、コンピュータというものが画像を表示するようになってから、一貫して色を正しく扱えるのは、Macintosh時代からのMacだけである。OSの宗派論争にするつもりではないが、今ほど一般人が盛んに写真や絵をコンピュータで扱い、またメディアが多くの情報を写真を用いて伝える時代に、コンピュータの大部分を占めるWindowsが色を正しく扱えないのは、奇異と言わざるを得ないだろう。

ではどれほどの違いが表れるのか、次の写真で見てもらおう。

// カラーマネジメント 不可 //

// カラーマネジメント 有効 //

一枚目の画像は、Mac OS Xの上で、カラーマネジメントができないウェブブラウザ(Firefox 2)が表示した画像のキャプチャ。二枚目の写真は、カラーマネジメントが有効なウェブブラウザ(Firefox 3 ベータバージョン、設定が必要)が表示したもののキャプチャである。2枚目はApple標準ブラウザのSafariと同じ色になる。緑の発色が一目瞭然に違うことがお分かりだろう。色のマッチングができていないシステムでこのページを見ると、2枚の写真のどちらも正しくない色で見える訳だが、それでも、色に大きな違いがあることを知るには十分な例だ。ちなみに、上のどちらのキャプチャ・ファイルもsRGBのICCプロファイルを持っている。

Windows環境におけるウェブブラウザに関して、カラーマネジメントがどうなっているか、簡単に説明する。まずVista以前でInternet Explorer (IE) 6を使った場合は、完全に無力である。IE 6は画像がsRGBであることを想定しているらしいので、わざわざsRGBに変換したファイルを読ませるが、それでも正しい色で表示されない。上の一枚目の写真と同じ色になる。(追記:この箇所は、「WindowsはsRGBで統一されている」という、自分が持っていた知識に反することを思い出し、間違ったことを書いたかも知れないと思って再度検証した。結果は本Blogの次の記事でご覧頂きたい。)これは、同じシステムの上で Firefox 3 を使って表示したものとは全く違う色になることから、どんなにモニタの出力が狂っていようと明らかだ。VistaとIE 7の組み合わせになると、sRGBならsRGBの色で表示はするようだ(要検証)。しかし、sRGBを想定していることには変わりがないので、それ以外のプロファイルを持った画像は正しく処理できない。唯一、Firefox 3を使った場合にのみ、画像固有のカラープロファイルを個別に解釈し、尚かつ、モニタのカラープロファイルにあわせた表示をすることができる。尚、Appleがベータ版として出しているWindows用のSafariでも、カラープロファイルに対応している。まだ英語以外の言語やフォントに対応していなかった、最初のバージョンからそうだった。Appleが何に価値を見いだしているかを垣間見るようで、面白かった。

一方、Macの場合は、SafariとFirefox 3がカラーマネジメントに完全に対応している。つまり、VistaとFirefox 3の組み合わせと同じことができる。

カラープロファイルへの対応をもう少し詳しく説明すると、あるウェブサイトにどんなカラースペースを持った画像が載っていても、ブラウザがそれぞれを同時に正しい色で出力すると言うことだ。そのメリットの一つは、画像の作成者の事情に左右されないことだろう。画像には、使ったデバイスの都合や、その最終的な利用形態によって、異なるカラースペースが設定されうるからだ。逆に、何のカラースペースを持つかの情報は付与しなければならない訳だが、ない場合にのみsRGBなどのカラースペースで解釈すれば良いだけの話で、IEのように、どんな画像もsRGBに強制する必要はなかった訳だ。もう一つのメリットは、とりわけsRGBというカラースペースに縛られないことがある。sRGBは今となっては古くなりつつある規格で、再現できる色の範囲が限られている。長期的な視野でカラーマネジメントの仕組みを考えると、一時の規格に限定するのは賢明な方法ではない。sRGBの後、より広い色空間を持つAdobeRGBが広まっていたが、最近ではさらに広いPhotoRGBが使われ始めている。

出力側のメリット、つまり、モニタの特性に合わせた色表示をすることのメリットは、説明するまでもないだろう。汎用液晶モニタでは、そもそも性能上の限界があるが、それでもキャリブレーションしてやると、目に見えて色が変わる。(私はX-RiteのEye-One [i1] Display 2というローエンドの製品を使った。アメリカでは200ドル程度なのでお買い得だ。)Firefox 3では、キャリブレーションして作る、モニタ用プロファイルを指定できるのだ。IE 7ではできない。

出力側に関して重要なことを補足すると、Mac OSでは、通常、実はこのようにアプリケーション毎にモニタプロファイルを設定する必要すらない。それはOSが一貫して管理しているからだ。一部で対応していないアプリケーションもあるが、Apple製を含むほとんどのアプリケーションで、個別のモニタに合わせた色を表示することができる。換言すれば、Appleが色管理の仕組みを提供しており、それを利用すれば、入力から出力まで、カラーマネジメントに対応したアプリケーションを比較的容易に作れるのだ。

ついでながら、Intel MacではVMware Fusionを使ってWindowsを同時に走らせることができるが、この場合は、VMware Fusionがカラーマネジメントを行わないので、その中のWindowsでFirefox 3を使っても正しい色にはならない。Mac OS XでFirefox 2を使って見た場合と同じ色で表示される。

最後に。まだまだ IE 6を使う人がかなりを占めると思われるから、Flickrなどにアップロードする写真は、sRGBにするに越したことがない。モノクロ写真の場合は、Dot Gain XX% などというプロファイルはダメで、強制的にsRGBに変換するか、Gray Gamma 2.2などにする必要がある。

| | コメント (0) | トラックバック (0)

2007年7月31日 (火)

Mac OS XからVMwareクライアントへのポートフォワード

Mac OS X でポートフォワードを実現するには、通常のUnix/Linuxの方法が使えないようだ。

ネット上を検索すると、一つには、OS X の「インターネット共有」として稼働している natd を一度終了させ、新たに作成した設定ファイル (nat.conf) を読み込ませて natd を再起動する方法が用いられている。他には、/usr/libexe/InternetSharing  というコンパイル済みのファイルの可読部分を変更している例もあったが、これは他の手段がある以上、避けるべきだろう。 

これらの方法は、あくまで OS X の NAT の設定を変えるためのものだ。よって、フォワード先が Parallels Desktop や VMware Fusion (以下、VMware)のバーチャルマシンである場合は、バーチャルマシンはそれぞれのアプリケーションに付属する DHCP/NAT の下にあるため、同じ方法を使うことが出来ない。

VMwareの場合はどうすれば良いか。VMwareのNATは、vmnet-natd というプログラムによって動いているのだが、私はこの設定ファイルを変更することで、port forward を実現することが出来た。

まず、動いているプログラムと引数を調べる。ターミナルで ps -ax | grep  natd を実行すると、

/Library/Application Support/VMware Fusion/vmnet-natd -c /Library/Application Support/VMware Fusion/vmnet8/nat.conf -m /Library/Application Support/VMware Fusion/vmnet8/nat.mac -d /var/run/vmnet-natd-vmnet8.pid vmnet8

の一行が表示され、設定に使われている nat.conf が特定できた(VMwareで別のネットワーク形式を選択している場合は、'vmnet8' に相当する部分が異なる)。このファイルを開くと、カスタマイズ例がコメントアウトした状態で書き込まれており、実はカスタマイズを想定していることが伺える。このファイルの [incomingtcp] のセクションに、例えば

8080 =  172.16.226.128:8080

と書けば、port foward の設定が完了である。この例では、インターネットからのポート8080へのパケットは、natdによって172...のIPアドレスを持つバーチャルマシンへと宛先を書き換えられ、転送される。逆向きのパケットも同様に処理される。

NATの設定が終了したら、ファイアーフォールの設定も忘れずに行っておく。システム環境設定から先程指定したポートを開放しておく。私は ipfw を使って、より細かく設定したファイアーウォールを敷いているので、ipfw のルールに次のような行を加えた。

ipfw add allow tcp from any to me dst-port 8080 in

これにより、インターネットからen0 を経由してOS Xに入って来るパケット(これは後にNATに拾われ、バーチャルマシンに転送される)と、バーチャルマシンからvmnet8 を経由して OS X に入ってくるパケット(後にインターネットに向けて転送される)の両方が、ポート8080に限って許可される。

括弧内に記述した、OS X から外に出て行くパケットについては、別の行で他の通信と一括して許可しているのでここでは触れない。

なお、一般的に、ipfw と nat を用いた port forward には、ipfw の divert という命令を使うことも出来るようだが、同時に実行する natd に転送先IPアドレスを指定しなければならない。VMwareの場合に出来たとしても、vmnet-natd に何らかの設定が必要になるので、手間は変わらない。私が試した通り、vmnet-natd に想定された使い方をするのが最善だろう。

追記:VMwareの新しいバージョンをインストールすると、今回変更した設定ファイル nat.conf が上書きされていた。同じディレクトリにバックアップファイルは置かれているので、アップグレードの都度、設定を復元する必要がある。

| | コメント (0) | トラックバック (0)