RE: [CSS3] support for linear-gradients & radial-gradients

Hi Alan,

You are correct about the math behind the color.
If you want to do things absolutely correct, you can't just interpolate the alpha and color values.
Alpha is not something that corresponds to something visual. If you look at the Adobe vector applications and the PDF spec, you will see that all blending and the gradients are done with actual colors. Alpha is always applied separately. This is the "correct" way of doing color and allows you to repurpose the same content for different devices by changing out the target profile.
color (RGB) = what you draw
alpha = how to composite the source and the backdrop

However you are confusing the math behind the color compositing and the perception of color.
Our eyes can't see opacity. They can see its effect as transparency, but it is our brain that tells us that what we're actually seeing. 
Going down that path is not helping because that is not the way that drawing is done.

The spec is reasonable to see RGBA as a colorspace. If some later revision of CSS wants to add ICC color, the spec will need to define how alpha is composited.
For now, the end result of the css gradient is a transparent image and it will behave just like another other image with alpha.

Rik

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Alan Gresley
> Sent: Saturday, February 05, 2011 2:40 AM
> To: Tab Atkins Jr.
> Cc: Simon Fraser; Peter Beverloo; Irfan Mir; www-style@w3.org; Adrian
> Low; Chris Lilley
> Subject: Re: [CSS3] support for linear-gradients & radial-gradients
> 
> CC W3C color expert Chris L.
> 
> On 14/01/2011 5:05 AM, Tab Atkins Jr. wrote:
> > On Thu, Jan 13, 2011 at 1:39 AM, Alan Gresley<alan@css-class.com>
> wrote:
> >> On 13/01/2011 4:26 AM, Tab Atkins Jr. wrote:
> [snip]
> >> Simply that the keyword 'transparent' should not be confused with
> >> alpha transparency. As it says in CSS-Color [1] for the keyword
> 'transparent'.
> >>
> >>
> >>   | transparent
> >>   |   Fully transparent. This keyword can be considered a shorthand for
> >>   |   transparent black, rgba(0,0,0,0), which is its computed value.
> >>
> >>
> >> So 'transparent black' is not the same as 'transparent' but the
> >> keyword 'transparent' can be considered a shorthand for transparent
> >> black. CSS2.1 is more explicit in suggesting that 'transparent' is
> >> not a<color>. In 14.2.1 [2] for background-color we have this (emphasis
> added).
> >>
> >>   | This property sets the background color of an element, either a
> >>   |<color>  value *or* the keyword 'transparent', to make the underlying
> >>   | colors shine through.
> >
> > CSS2.1 didn't have any notation for non-opaque colors, and so the
> > editors apparently thought that it was easier to refer to
> > 'transparent' specially.  This turned out to be a mistake,
> 
> 
> How is this a mistake?
> 
> 
> > and luckily
> > CSS3 Color has a proper way to refer to non-opaque colors, so we can
> > give 'transparent' a proper definition, which we did - it's
> > rgba(0,0,0,0).
> 
> 
> You are implying extra meaning to that part of the spec. Again.
> 
> 
>    | This keyword can be considered a shorthand for
>    | transparent black, rgba(0,0,0,0), which is its computed value.
> 
> 
> It states that transparent can be considered a shorthand for transparent
> black. It does not say that transparent has a proper definition as being
> transparent black. If it is considered a shorthand for rgba(0,0,0,0), then it can
> also be considered a shorthand for all the other colors with full alpha
> transparency. That is 16,777,215 colors.
> 
> 
> >>>> A transparent color does not have a point so it can not exist in
> >>>> any colorspace. It does not exist as a color apart from some
> >>>> concept which is very ambivalent.
> >>>
> >>> No, transparent colors exist perfectly fine.
> >>
> >>
> >> I should have said that the keyword value "transparent' is not
> >> a<color>  and it does not have any point in any colorspace where all
> >> values of<color>  do have a points within colorspace. You use this term
> "transparent colors."
> >> Should that really be colors with alpha transparency?
> >
> > Yes, 'transparent' is a color.
> 
> 
> Really. Maybe you should read up on the definition of what color is. I quote
> from Wikipedia [1].
> 
> 
>    | Color or colour (see spelling differences) is the visual perceptual
>    | property corresponding in humans to the categories called red,
>    | green, blue and others. Color derives from the spectrum of light
>    | (distribution of light energy versus wavelength) interacting in the
>    | eye with the spectral sensitivities of the light receptors.
> 
> 
> Something transparent can not be visually perceived. Something
> transparent can not have an interaction with the light receptors of the
> eyes. Something transparent is outside the visible spectrum that can be
> detected by the human eyes. Gamma rays, x-rays infrared waves, radio
> waves and etc. are all forms of light that are not visible and is truly
> what can be defined as being transparent. If these were visible to human
> eyes, then they would be defined as colors. Other animals can see colors
> outsides the range of human vision. This is since such animals have eyes
> with more the three types of light sensitive receptors. This is known as
> Tetrachromacy.
> 
> 
> 
> > It's rgba(0,0,0,0), in the sRGBA
> > colorspace (sRGB augmented with an alpha dimension).  It has a similar
> > definition in all other colorspaces.
> 
> 
> I consider this definition wrong. A colorspace is not a mathematical
> formula on a 2D plane (X and Y axis). It is something that is 3D. Below
> is a demo of sRGB colorspace with 125 colors shown in it's rightful way,
> which is 3D.
> 
> <http://css-class.com/test/css/3/transform-color-cube3.htm>
> 
> Click one of the buttons marked transparent and you are seeing sRGBA
> colorspace which occupies the same space.
> 
> 
> >> I made a completely wrong statement. Gradients from<color>  point
> to<color>
> >> are interpolated along a straight line in sRGB if they follow particular
> >> planes within sRGB. I reason that some gradients, may travel a direct line
> >> and miss precise<color>  points, in which case they use the color of the
> >> nearest<color>  point (maybe rare in SRGB which has 16581376 colors). Is
> >> this a fare statement to make?
> >
> > I'm not sure, because I don't understand what you're trying to say.
> 
> 
> Take for instance a gradient from rgb(255,255,255) to rgb(255,255,252).
> There is no colors in that vector between these points. We can change
> another color channel and create many more such vectors like a gradient
> from rgb(255,255,255) to rgb(255,252,251). The first such gradient that
> passes through a true color point has to be precisely aligned with the
> X, Y and Z matrix.
> 
> For two axises (X, Y and Z matrix), a gradient from rgb(255,255,253) to
> rgb(255,253,255) has a midpoint of rgb(255,254,254) and for three
> axises(within a X, Y and Z matrix), a gradient from rgb(255,255,253) to
> rgb(253,253,255) has a midpoint of rgb(254,254,254).
> 
> 
> 
> > Yes, a color at any given point in a transition is rounded to the
> > nearest whole color in practice - halfway between 'white' and 'black'
> > is rgb(127.5,127.5,127.5), after all, which must be rounded up or
> > down.  But that's an irrelevant implementation detail.
> 
> 
> Halfway between 'white' and 'black' is rgb(127,127,127). We should be
> talking about steps in scalars. If each step is of 51 scalars, then we
> have these steps from black to white.
> 
>      rgb(0,0,0), rgb(51,51,51), rgb(102,102,102), rgb(153,153,153),
> rgb(204,204,204), rgb(255,255,255)
> 
> 
> 
> > Am I missing a more pertinent question?
> 
> 
> No, you're just not understanding that it not just about simple rounding
> of numbers.
> 
> 
> >>>> I don't understand why the CSS WG or implementers would want a CSS
> >>>> gradient
> >>>> to behave differently from a SVG gradient. A SVG gradient from<color>
> to
> >>>> transparent is the same as the current Gecko and WebKit implemented
> CSS
> >>>> gradient which is interpolation in un-premultiplied space.
> >>>
> >>> SVG gradients don't use RGBA colors - they have RGB colors and then,
> >>> separately, an opacity.  Implementations allow the SVG colors to be
> >>> rgba, though, and when that occurs they want to do interpolation in
> >>> premultiplied space, same as CSS.
> >>
> >> Can you please clarify something, so I can fully understand? Theses
> >> questions are pertaining to CSS gradients.
> >>
> >> 1. Is a gradient from blue (#0f0) to yellow (#ff0) (midway way point is
> >> #7f7f7f) interpolated in premultiplied space or un-premultiplied space?
> >
> > Both.  Opaque colors transition the same way in both colorspaces.
> 
> 
> Ok, I now understanding where you coming from. You see premultiplied
> space or un-premultiplied space as some form of space. I am talking
> about 3D colorspace where you are talking about abstract mathematical
> concept of colorspace.
> 
> 
> >> 2. Is a gradient from bluish rgba(0,255,0,0.5) to yellowish
> >> rgba(255,255,0,0.5) (midway way point is rgba(127,127,127,0.5))
> interpolated
> >> in premultiplied space or un-premultiplied space?
> >
> > Both.  In general, colors with the same alpha transition the same way
> > in both colorspaces.
> 
> 
> See above and below.
> 
> 
> > The only difference between premultiplied and non-premultiplied is
> > when you're transitioning between colors with different alphas.
> 
> 
> For me, an alpha represents a color of half it's intensity in value when
> it has opacity of 0.5 and is over a black background or an alpha
> represents a color of double it's intensity in value when it has opacity
> of 0.5 and is over a white background. I understand this.
> 
> 
> >>> What you're seeing is the fact that transitions from opaque colors to
> >>> transparent in non-premultiplied space get darker as they progress.
> >>
> >> This is not true for all colors. I think you use the word darker loosely
> >> here. A gradient from blue to transparent (on a white background) get
> >> gradually lighter along the full projectory of the gradient. At the same
> >> time the same gradient get gradually lest saturated along the full
> >> projectory of the gradient. The only thing constant is it's hue.
> >
> > No, I meant precisely what I said.  *All* colors get darker for the
> > first half of their transition toward 'transparent' if you do the
> > transition in non-premultiplied rgba space, because you're
> > transitioning the color components toward black.
> 
> 
> A gradient from blue to transparent over a white background get lighter
> along it path. I talking about lighter as in HSL. See line 7 with Blue ~
> Transparent.
> 
> <http://css-class.com/test/css/colors/grayscale2.png>
> 
> 
> So your expertise in maths does not reflect an observable reality.
> 
> 
> > That is, the halfway point between 'blue' and 'transparent' in
> > non-premultiplied rgba space is rgba(0,0,127,.5).  On the other hand,
> > the halfway point in premultiplied rgba space is rgba(0,0,255,.5).
> 
> 
> There we go. I now have the answer. Thank you Tab. Please note that you
> have '127' which is '7f'. What happened to the '127.5'?
> 
> 
> > The former is clearly darker than the latter, for the same reason
> > rgb(0,0,127) is clearly darker than rgb(0,0,255).
> 
> 
> You can not use this analogy since non-premultiplied rgba space is
> curved and premultiplied rgba space is linear when going from color to
> transparent in sRGB colorspace. The darkness or lightness observed is
> determined by the HSL(A) values of a background color behind what is
> partially transparent.
> 
> 
> > Now, even though the color is darkening, the final pixel color you see
> > after compositing it onto the background color may indeed be lighter,
> > depending on the background.  That's irrelevant.
> 
> 
> No it is not. I am a former artist who first experimented with color
> pigment with primaries of red, blue and yellow. Using color pigment on
> white paper or black paper has a greatly difference appearance and is
> far from being something considered irrelevant. What I find with color
> generated by light or a display device that can show sRGB is that the
> whole ways that colors interact is reversed.
> 
> 
> > You've confused
> > yourself by thinking about the final pixel colors before; what matters
> > is the actual colors being used, not what you get after you composite
> > all of them together.
> 
> 
> I'm not confused. You are understating the significance of the final
> color when they are composite all together.
> 
> 
> [snip]
> >> I would really like to see both types of gradients (<color>  to transparent)
> >> with non-premultiplied and premultiplied interpolation in CSS.
> >
> > As far as I can tell, there's no benefit to authors from being able to
> > transition in non-premultiplied space.  It does the wrong thing in the
> > general case.
> 
> 
> Then your general case is theoretically 1/64 of all possible cases. You
> are wanting to avoid the affect on 1/64 of all possible cases where I am
> wanting to avoid the affect on 63/64 of all possible cases.
> 
> I say this since a gradient of white to transparent over a white
> background (final composite color) is rgb(191,191,191) which is 1/4 of
> each color channel.
> 
> 
> Not allowing the current behavior will break the affects seen here.
> 
> <http://www.marcofolio.net/webdesign/pure_css3_bokeh_effect_with_so

> me_jquery_help.html>
> 
> And break what is seen here with the various colored backgrounds.
> 
> http://css-class.com/test/css/colors/gradient-white-trans2.htm

> 
> 
> 
> 1. <http://en.wikipedia.org/wiki/Color>
> 2. <http://en.wikipedia.org/wiki/Tetrachromacy>
> 
> 
> 
> --
> Alan http://css-class.com/

> 
> Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Sunday, 6 February 2011 21:57:49 UTC