[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 <cmarrin@apple.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
>> things:
>> [...]
>> 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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: