W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [css3-images] Gradients feedback

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 10 Sep 2010 13:55:16 -0400
Message-ID: <4C8A7104.4090109@mit.edu>
To: Alan Gresley <alan@css-class.com>
CC: www-style list <www-style@w3.org>
On 9/10/10 3:35 AM, Alan Gresley wrote:
>>> 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.
>
> What I mean is that all colors (points) within sRGB space that are
> gradients to transparent and are over a white background would be appear
> the same as if the same colors (points) within sRGB space were a
> gradient to white (opaque).

Ah, I see.

Well, for a gradient from rgba(r, g, b, 1) to transparent which is then 
composited on an rgba(255, 255, 255, 1) background, we get these results 
in the final composited image at position 0 < t < 1 in the gradient:

Unpremultiplied interpolation:

   rgb(r*(1-t)^2 + t*255,
       g*(1-t)^2 + t*255,
       b*(1-t)^2 + t*255)

Premultiplied interpolation:

   rgb(r*(1-t) + t*255,
       g*(1-t) + t*255,
       b*(1-t) + t*255);

As it happens, the latter is exactly what you would get for a gradient 
to opaque white.  This seems like a good thing to me.

>> 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>
>
>
> Ok, you make a very valid point here concerning a intermediate point
> which is semi-opaque. I was just understanding what was happening with a
> gradient from color to transparent before I move on to a gradient from
> color to color.

Er... the above testcase DOES have a gradient from color to transparent.

> It is not an accident, it is how color space works.

I think we're having a serious communication problem here...

>> 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.
>
>
> No, I didn't use a color picker for any of the midway points.

Then how did you come out with opaque midway points for a gradient to 
_transparent_?

>> 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".
>
> What you think is a semi-opaque color can only be conceptualized when
> such semi-opaque colors have a background (not uniformed) that reveals
> transparency.

Well, obviously.  That's the whole idea of transparency, yes.  But if 
we're doing a gradient to transparent, we care about exactly that, yes?

> What is seen with rgba(255, 255, 0, 0.5) when the light is emitted by a
> monitor screen is many device pixels composed of vertical lines of RGB

Hold on.  Where did monitor screens come in?  We're dealing with CSS 
colors, not specific physical representations.  If I print my gradient 
out on a color printer, there's no "monitor screen" involved.

So what really matters is "what happens when the gradient is composited 
onto different backgrounds?"  In fact, just using the results of 
compositing onto solid black and solid white backgrounds is enough to 
recover enough information to say what compositing onto any other 
background would do... and that's precisely the set of information the 
spec needs to specify.

Now you could do this via defining what happens when compositing onto 
black and white, or you can do it by defining what rgba() color is 
produced at every point in the gradient.  The latter happens to be 
simpler to spec, I think.

>> 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.
>
> So I guess the special issue of Scientific American Mind - Volume 20,
> Number 1, Summer 2010 is wrong in it's discussion about the neuroscience
> of illusion.

No, but the issues it discusses are completely unrelated to the problem 
at hand.  There are all sorts of color-perception issues, but the issue 
at hand is visible to the computer too, not just to users.

> The only reason that I am doing this is because I would like to be able
> to as an author to use premultiplied un-premultiplied gradients.

What does that mean?

> Is this what Gecko does (second of each test) with un-premultiplied
> gradients?
>
> .a6 {background: rgba(255, 255, 0, 1);}
> .a7 {background: rgba(191, 191, 0, 0.75);}
> .a8 {background: rgba(127, 127, 0, 0.5);}
> .a9 {background: rgba(63, 63, 0, 0.25);}
> .a10 {background: rgba(0, 0, 0, 0);}

This is what interpolation in un-premultiplied space gives you, yes.

-Boris
Received on Friday, 10 September 2010 17:55:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT