- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 08 Sep 2010 15:00:36 -0400
- To: Alan Gresley <alan@css-class.com>
- CC: www-style list <www-style@w3.org>
On 9/8/10 7:38 AM, Alan Gresley wrote:
> Ok, here we go. In sRGB space, all colors are fully opaque so any
> gradient that goes from one point to another point within the sRGB space
> will be a gradient of fully opaque color.
Yes. As long as all colors are fully opaque, premultiplied and
un-premultiplied alpha behave exactly the same way, note.
> You would like the midway point between a gradient between yellow and
> transparent to also be #ff7
No, I would like a gradient halfway from #ff0 to transparent to be
rgba(255, 255, 0, 0.5).
In un-premultiplied space, what you get instead is rgba(127, 127, 0, 0.5).
> or to been non-premultiplied but this would
> mean that all colors (points) within sRGB space that are gradients to
> transparent would have to be somewhat non-premultiplied. I don't know
> how this can be done.
I have no idea what you're trying to say there.
> To explain the precise mathematics, I will use the example of the
> gradient between yellow and transparent. The current midway point as
> implemented by Gecko and WebKit is #bb7 (fully opaque).
No. The current midway point as implemented by Gecko is rgba(127, 127,
0, 0.5). I can't speak to what webkit does authoritatively, but the
rendering in Webkit looks identical to Gecko's (see below).
Note that _if_ you happen to composite rgba(127, 127, 0, 0.5) on top of
white you will get something like #bebe7f. So if your "precise
mathematics" is coming from applying a color picker to the results of
compositing a gradient from yellow to transparent onto a white
background I can see you getting the numbers you get.
Testcase that shows that the gradient's intermediate points are not in
fact opaque in either engine:
<!DOCTYPE html>
<style>
div { width: 100px; height: 100px; }
div.g {
background: -moz-linear-gradient(yellow, transparent);
background: -webkit-gradient(linear, center top, center bottom,
from(yellow), to(transparent));
}
</style>
<div style="background: white"><div class="g"></div></div>
<div style="background: red"><div class="g"></div></div>
> This same color #bb7 is also the midway point of the gradient from #770 to white.
Yes, but that's an accident of happening to composite onto a white
background. See above.
> Using another example, the gradient between blue and transparent. The
> current midway point as implemented by Gecko and WebKit is #77b (fully
> opaque).
Again, no. The current midway point is rgba(0, 0, 127, 0.5).
Compositing that onto a white background gives #7f7fbe, which is what
you seem to have measured with your color picker.
> This all changes when the background behind the element with the
> gradient is not white.
Nothing about the _gradient_ changes. All that changes is what it's
composited against. Given that you made this observation, I'm not sure
how you can claim with a straight face that the intermediate gradient
colors are "fully opaque".
>> Computing gradients in premultiplied space makes gradients to
>> transparent work much better. In non-premultiplied space they all
>> look black-ish in the middle.
>
> Yes, it does look grayish or blackish but this is because our eyes have
> difficulty see a light hue on a light background.
No, it's because you're desaturating the color in addition to changing
its opacity value if you transition to rgba(0,0,0,0) in unpremultiplied
space.
> The yellow lines shows the color (mapped to sRGB space) when the
> background is white.
Gradients need to be defined independently of what they're being
composited onto.
> I hope this all makes some sense.
The part starting with the link to graphic doesn't sorry...
-Boris
Received on Wednesday, 8 September 2010 19:01:10 UTC