あ今回は、画像(ビットフィールド)を処理するアプリケーションにおけるエンディアンの違いの影響について見てみます。例題として、OpenGLのテクスチャ画像を作成する場合について解説します。
今回の例では、OpenGLでテクスチャ画像を利用するために、オフスクリーン(GWorld)を作成し、そこにPICT画像(Picture)を表示した後に、その画像データフォーマットの内容をテクスチャ画像フォーマットへと変換します。まずは以下のsetupOpenGL()ルーチンで、PICT画像を表示するためのGWorld(CGrafPort)を作成し、画像領域の先頭アドレスやRowBytes(横幅のバイト数)を外部変数へと保存しておきます。

次のcreateOpenGLTexture()は、引数で渡されたPICT画像を確保しておいたGWorldへ描画し、その画像データフォーマットを変換した後に、外部変数のbuf1へ保存するためのルーチンです。unsigned longにマッピングされたMacintosh用画像フォーマットはαRGB(αは透明度)ですが、OpenGL用のテクスチャ画像フォーマットはRGBαとなります。ですから、オリジナルデータを8bit左へシフトさせ、透明度として0xffを追加する変換操作が必要となるわけです。また、GWorld画像バッファのアドレス原点は左上なのに対して、テクスチャ画像のアドレス原点は左下となりますので注意してください。

さて、上記はあくまでもビックエンディアン用(PowerPC用)のルーチンとなります。リトルエンディアン(Intel版CPU用)の場合には、メモリから読み込んだunsigned long値が反転しているわけですから、上記のままでは画像データは正常に変換されません。シフト操作が逆方向に働き、青色成分(B)が飛んでしまい全体に黄色い画像となってしまいます。よって、リトルエンディアンの場合にのみ、以下のようにデータの変換直前と変換直後にスワップ操作を入れてやる必要があります。

しかしこのままでは、処理速度にシビアであるべきの画像フォーマット変換ルーチンとしてはかなり余分な処理を実行しており、決して効率が良いとは言えません。よって、ビット操作とα値の付加をリトルエンディアンに最適化したやり方に切り換えてしまいます。これにより、Intel版CPUでの画像フォーマット変換作業量はPowerPC版とまったく同じとなり、効率の良い処理が可能となります。

次回は、もう少し詳しく画像データフォーマットに関連した例題を調べてみます。また、DICOM画像など、内部データフォーマットがエンディアンに依存しているファイルを取り扱う時の注意点についてもお話しする予定です。
copyright 2006 Ottimo, Inc. All rights reserved
無断転載・引用禁止
Contact us: koike@ottimo.co.jp