argb(a,b,c,d)の上にargb(e,f,g,h)の色を合成した結果はどうなりますか？
自己のアルゴリズムですが問題点はありますか？
クラスCOLORのメンバ関数です
COLOR Merge(COLOR s){
BYTE Alpha1=s.A();
BYTE Alpha2=255-s.A();
BYTE Alpha3=this->A();
BYTE Alpha=Alpha1+Alpha2*Alpha3/256;
if(Alpha==0)
return COLOR(0,0,0,0);
return COLOR(Alpha,
(s.R()*Alpha1+this->R()*Alpha2*Alpha3/256)/Alpha,
(s.G()*Alpha1+this->G()*Alpha2*Alpha3/256)/Alpha,
(s.B()*Alpha1+this->B()*Alpha2*Alpha3/256)/Alpha);
}
/256ってあってますか？
クラスCOLORのコンストラクタから察すると,メンバに透明度を持ってるみたいですけど
透明度を持ってるなら,透明度が0でも色は保持してたほうがいいんじゃないかなぁ
operator COLORREFとかで初めてRGBにも影響させたほうがいいような気がしちゃいまし
た
よくわかってないのでこんな感じです
背景と前景の両方にアルファ値があるということはさらに背景が存在するということで、
まず背景のRGBと前景のARGBの合成だけを考えればよいのでは？
その合成結果と背景をもう一度元のアルファ値で合成してやればよいような気がします。
hiroccoさんも書かれていますがアルファ値が0～255の範囲なら分母も255ですね。
変数が何を表しているかわかりませんがアルファ値が0でも処理を分ける必要はないで
しょう。
画像同士の合成は、
「いかなるときにも通用する方法」だとか「みんなが使ってる」とか
そんな「正しいとされる合成方法」があるのではなく
合成させる人が「自分なりの条件にあわせ、やりたい方法で合成」するもんだと思う
みなさん、ありがとうございます。
GDIでの使用は考えていません。DIBでの使用です。
hiroccoさん、subaruさん、/256でなく/255でした。ありがとうございました。
subaruさん、32ビットビットマップを扱おうと考えているのでそういうわけにはいかないの
ですが。。具体的にどのような処理で合成するのでしょうか？
ryoさん、正しいとされる合成方法はないのでしょうか？
うーん・・・GDI+での動作を調べてみるとアルファ同士が重なる場合は
ちゃんと透明度が下がるように作られているように見えますね。
どのような計算が行われているのかはわかりませんでしたけど。。。
描画を全て自前でやるのは速度を出すのが難しいと思うのだけど
何か環境的な制約でもあるのでしょうか？
GDI+が遅いので自前描画を試みています。
自分の過去のソースから
(a0 r0 g0 b0) と (a1 r1 g1 b1) を合成する
すべて 0 - 1.0 の小数値（事前に 255 で割っています）
my は 50% の合成なら 0.5
double a = a0 * (1.0 - my) + a1 * (my);
double r = a ? (a0 * r0 * (1.0 - my) + a1 * r1 * (my)) / a : 0;
double g = a ? (a0 * g0 * (1.0 - my) + a1 * g1 * (my)) / a : 0;
double b = a ? (a0 * b0 * (1.0 - my) + a1 * b1 * (my)) / a : 0;
合っているか分かりませんが、アルファ値も考慮した合成です。
もし、AlphaBlendと同じことがしたいということなら
http://msdn.microsoft.com/en-us/library/dd183393.aspx
ここが参考になると思う
デゴルガンさん、ありがとうございました。参考になります。
ryoさん、ありがとうございました。そのサイトを参考にします。
とりあえず実装してみますので、問題があれば別スレ立てます。
チェックぬけました。
返信する
最新の投稿: お久しぶりです、いかがお過ごしでしょうか。 最新のメンバー: gantez 最近の投稿 未読の投稿
