Premultiplied Alpha and the 2D rendering context

[Rolf B]

Hallo Martin,

ich glaube, Du hast es etwas erhellt.

Vermutlich muss man die Mischalgorithem vergleichen, die bei premultiplied und non-premultiplied Farben verwendet werden - die können wohl nicht die gleichen sein.

Du sagst: Wenn ich eine RGBA-Farbangabe $$(c_r,c_g,c_b,c_\alpha)$$ habe und die mit einem existierenden Bildpunkt $$(p_r, p_g, p_b, p_\alpha)$$ mische, dann wird für das neue Pixel $$c_{r,g,b}\cdot c_\alpha + p_{r,g,b} \cdot (1-c_\alpha)$$ gerechnet. Wobei das $$p_\alpha$$ außer Acht lässt.

Man müsste jetzt also noch wissen, wie $$p_\alpha$$ berücksichtigt wird, und dann vergleichen, wie die Formel bei premultiplied Farben aussieht. Einfach so: $$c_{r,g,b} + p_{r,g,b} \cdot (1-c_\alpha)$$?

Das wäre möglich, bräuchte dann aber ein Clipping (weil die Summe im Kanal über 255 steigen kann), oder es wird nicht + verwendet, sondern max. Für das Clipping spricht, dass die Vektor-Operationen der Intelprozessoren genau auf diese Weise mit Überläufen umgehen.

Und das erklärt dann, warum ein premultiplied-Wert von (255,127,0,0.5) nicht non-premultiplied darstellbar ist, weil ich dafür die 255 durch 0.5 teilen müsste und 510 nicht in einem 8-bit Farbvektor darstellbar ist.

Das führt dann auch zu Sinn bei der Frage, warum man eine Bitmap als "premultiplied" oder "non-premultiplied" deklarieren muss; allerdings nicht unbedingt zum Sinn einer Konvertierung (außer, weil bestimmte Abläufe eine Bitmap in der einen oder anderen Form erwarten).

Es ist etwas Licht, aber noch viel Finsternis. 😀

Rolf