フェンリル

Developer's Blog

透過画像の表示の際にどんな処理がなされているのか2

こんにちは、Sleipnir 3 for Windows 開発担当の森本です。

さて、前回は TouchPaging での使用されている、半透明処理の計算量が多くて困るという話で終わったのですが、今回はその問題を解決して、その後にさらに起こる面倒くさい点について話そうと思います。

 a = 0.1 * ( 1.0 - 0.5 ) + 0.5 => 0.55 r = ( 0.0 * 0.1 * ( 1.0 - 0.5 ) + 1.0 * 0.5 ) / 0.55 => 0.91 g = ( 0.0 * 0.1 * ( 1.0 - 0.5 ) + 0.0 * 0.5 ) / 0.55 => 0.00 b = ( 1.0 * 0.1 * ( 1.0 - 0.5 ) + 0.0 * 0.5 ) / 0.55 => 0.09 

前回面倒だと言っていた、この式をよく観察すると dest.b * dest.a のような透明度と輝度を掛ける計算が沢山あるのが解ります。
乗算は計算時の負荷が高いので、何とか減らす方向で式を改良します。また、割り算も辛いので何とか出来無いか考えてみます。

たとえば、各色を予め透明度で乗算しておけば、乗算を減らし計算をシンプルに出来て、各色の分母と新しい透明度も同じなので、ひょっとしたら割り算も無くせるかもしれません。

 struct premultiplied_pixel { float b; // 青。範囲は 0.0~a float g; // 緑。範囲は 0.0~a float r; // 赤。範囲は 0.0~a float a; // 透明度。範囲は 0.0~1.0 で 1.0 が不透明 }; pixel src2;  // 転送元。ユーザーから見て手前にある pixel pixel dest2; // 転送先。ユーザーから見て奥にある pixel 

これをもとに式も作り直してみます。

 dest2.a = dest2.a * ( 1.0 - src2.a ) + src2.a dest2.r = dest2.r * ( 1.0 - src2.a ) + src2.r dest2.g = dest2.g * ( 1.0 - src2.a ) + src2.g dest2.b = dest2.b * ( 1.0 - src2.a ) + src2.b 

おお!シンプルになりました。これぐらいならば実用的な速度で計算できそうです!

さて、今回の計算のために新しいピクセルフォーマットを作ったわけですが、この形式は一般に「乗算済みアルファ(Pre-multiplied Alpha)」と呼ばれ、特にリアルタイムで画像処理をする場合によく使われています。

しかしその割に全体としての知名度が低く、「普通の RGBA フォーマットと混同されている」のを割と見かけます。RGBフォーマットとRGBAフォーマットは透明度を無視すれば「ほぼ同じ物」と言えますが、乗算済みアルファの RGBA と、普通の RGBA の間には「互換性がなく、変換が必要」です。

そして、 この違いに関する Windows の実装がこの混乱に拍車を掛けています。

Vista 以降で Aero を有効にしている場合、トップレベルのウインドウは 同じサイズの 32bit ビットマップ (DIB) を持っているのですが、これがかなり特殊な扱いをされています。具体的には、Aero の透明部分では「乗算済みアルファ RGBA」フォーマット、不透明部分では「普通のRGB」フォーマットだとして描画されています。

一枚のビットマップのフォーマットを部分的に変えるなんて、いったいなぜこんな事に…

と頭を抱えていてもしょうがないので、(たぶん)次回は Sleipnir 3 の実装で使っている方法などを交えつつ、対処法を書いていきたいと思います。

フェンリルの開発者アカウントでは、フェンリルプロダクトの最新開発情報などをつぶやいています。よろしければフォローしてください!

Sleipnir の Facebook ページでは、ユーザーの方たちとのコミュニケーションや最新情報の投稿などを行なっています。よろしければいいね!してください!

Facebook コメント

コメント

名前(必須)

メールアドレス(必須)

URL

スタイル用のタグが使えます

このコメント欄でのご質問、ご要望には、開発チームから回答できない場合があります。ご質問、ご要望は「User Community」内のフォーラムまでお寄せください。