- 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