nicht angemeldet
Der MartinHallo,
ich glaube, Du hast es etwas erhellt.
immerhin, das freut mich.
Vermutlich muss man die Mischalgorithem vergleichen, die bei premultiplied und non-premultiplied Farben verwendet werden - die können wohl nicht die gleichen sein.
Nein, sicher nicht.
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.
Richtig, denn $$p_\alpha$$ ist für diesen Schritt bedeutungslos. Der Faktor ging in die Berechnung des bisherigen Farbtons ein.
Man müsste jetzt also noch wissen, wie $$p_\alpha$$ berücksichtigt wird
Nach meinem Verständnis gar nicht - der ist schon durch den vorherigen Schritt abgefrühstückt. Beim Hinzumischen eines neuen Farbtons kommt nur dessen Opazität zum Tragen - vergleiche die Gewichtungsfaktoren A und (1-A) aus meinem vorherigen Posting. Das Resultat kann nicht größer als 100% (respektive 0xFF) werden.
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.
Man könnte es auch umgekehrt sagen: Ein pre-multplied von (255,127,0,0.5) kann gar nicht erst entstehen, weil der ursprüngliche Wert einer Komponente nur noch zu 50% wirkt, also nur noch maximal 128 betragen könnte.
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).
Ich sehe den Sinn tatsächlich nur in der Einsparung von drei Multiplikationen pro Pixel bei der Anzeige, die man dann halt einmalig vorzieht.
Live long and pros healthy,
Martin
Hunde, die bellen, beißen nicht.
Jedenfalls nicht gleichzeitig.
Rolf B