[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Compositing with HTML
On Jan 8, 2010, at 6:45 PM, Philip Taylor wrote:
> On Sat, Jan 9, 2010 at 2:26 AM, Chris Marrin <email@example.com> wrote:
>> I'm confused. Clamping to 1 doesn't guarantee that it's a legal
>> premultiplied color, does it? Or are you saying that the 2d canvas, svg and
>> css take non-premultiplied colors as input, clamp all the channels to 1 and
>> convert them to pre-mulitplied behind the scenes?
>> I'm not sure what they actually do, but I know that the spec says 3 useful
>> 2) Colors in the buffer (when read back) are premultiplied
> Where do you see this? getImageData explicitly says "Pixels must be
> returned as non-premultiplied alpha values". The conceptual model
> intended throughout the whole 2d context is that colours are
> non-premultiplied [0, 1] RGBA values - an implementation is free to
> store premultiplied values internally, but that's invisible to the API
> (except via the loss of precision). Some implementations, e.g. Opera's
> (at least in the past), store non-premultiplied values internally and
> never have to do conversions (though it'll need more multiplications
> for its Porter-Duff operators).
Do you see now why I say I am confused? :-) This is all the more reason for the HTML compositing model to be explicitly defined. I'm sure it is. I just have not been able to find it.
> When you composite with "lighter" (plus), the (non-premultiplied)
> colour components should be clamped to 1, so it can never be
> oversaturated. (I believe all implementations do this. The spec could
> probably be made clearer, though.)
In the porter-duff section of the Canvas spec it does make this clamping clear. I'd just like to see the equivalent section of the HTML spec.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: