Re: [CSS4 color][CSS4 transition] color pre-multiplied vs non pre-multiplied was (Re: [CSSWG] Minutes TPAC Tue 2012-10-30 AM I: Abstract Directions, Transforms, Transitions)

On Thu, Nov 22, 2012 at 2:39 AM, Alan Gresley <alan@css-class.com> wrote:

> On 14/11/2012 5:58 PM, fantasai wrote:
>
>     <dbaron> http://dev.w3.org/csswg/css3-**transitions/#animatable-types<http://dev.w3.org/csswg/css3-transitions/#animatable-types>
>>    dbaron: In section on animation of property types:
>>    dbaron: colors in pre-multiplied space?
>>    tab: I think we wanted to use pre-multiplied in all cases.
>>
>
> Why?
>
>     tab Need to be consistent with gradients, etc.
>>    dirk: And with SVG
>>    dbaron: But SVG 1.1 had opacity and color on separate properties
>>    dino: Still has the same problem of interpolating in 4 channels.
>>    dbaron: Gradient says pre-multiplied.
>>
>
> And what is seen on the right of the below screenshot is the result of
> pre-multiplied with a test where all colors are in the grayscale.
>
> http://css-class.com/test/**temp/color-transparent-gs.png<http://css-class.com/test/temp/color-transparent-gs.png>
>
>     dbaron: Some OS's don't give you that.
>>    dbaron: I'd be happy with pre-multiplied.
>>    Rik: Prefer non-pre-multiplied.
>>
>
> I prefer two keywords. One being 'transparent' and the other being
> 'pre-transparent'. Then authors have a choice and possibly the chance to
> learn that every single color point (over 16 million) has a corresponding
> transparent-color point.
>
>     Rik: Better for SVG and Canvas.
>>    Tab: (How did Canvas end up different, I wonder...)
>>    Tab: Because CSS gradient has been pre-multiplied for a while.
>>
>
> But still FF17, Chrome 23 and Safari 5.1.7 show gradients in non
> pre-multiplied for what is now longer that a year since it was resolved
> that they shouldn't because supposedly authors may not understand that
> 'transparent' is shorthand for 'transparent-black'. The reasoning behind
> this resolution is ill founded.
>

I agree. It's interesting that they are still using non-premultiplied
colors.


>
>     Dino: benefit of pre-mul is you don't gray when animating to
>>          transparent. And can solve it by going to rgb(...)
>>
>
> You do *NOT* go to gray with pre-mul unless the initial color is white or
> somewhere between white and black (within the grayscale).
>

No, you can go to gray if for any of the interpolated values, r/g/b become
approximately the same value.


>
> If you going from color (not belonging to the grayscale) to transparent,
> you go to a color that has less saturation. It may look supposedly wrong if
> the composite color (part of which is the background color) is whitish.
>
> At 25% and 75% in the below testcase are the midpoints between color and
> 'transparent color'. Which one of these midpoint are gray?
>
> http://css-class.com/test/**temp/color-transparent.htm<http://css-class.com/test/temp/color-transparent.htm>


fuchsia-lime midpoint is gray since it goes from magenta rgb/(255, 0, 255)
to green/rgb(0, 255, 0)

I think what you are looking for is interpolation in a non-RGB colorspace
(like Lab).


>
>
>
>     <oyvind> I believe we encountered issues on the web when we did
>>             non-pre-multiplied transitions
>>    <oyvind> hovering comments on youtube looked weird, for instance
>>
>
> This is because the authors used transparent (or transparent black)
> instead of transparent-color. Advocacy would do wonders.
>
>     Tab: Can add some color stops.
>>    Tab: But SVG is adding mesh gradients and you cannot do the same trick.
>>    dbaron: I feel more strongly about animations being pre-multiplied than
>>            about gradients.
>>
>
> I agree fully here. Transitioning of color is totally different from a
> gradient of color.
>

Not really. I bet the observed weirdness happened because of the transition
to transparent black.


>
>     dbaron:. If an animation from/to transparent is ugly, that is a problem
>>    Rik: Transparent is black, that is the problem
>>
>
> Precisely.
>
>     sylvaing: That's why we ended up with pre-multiplied, isn't it?
>>    dbaron: If you animate from green 20% opaque to 100% opaque red.
>>    dbaron: not the same issue as going through gray, but in
>>            non-premultiplied space, the green will first get deeper
>>            before fading.
>>
>
> The green (or lime) does not get deeper. At 50% it is close to olive and
> at 75% it is close to orange. All that is changing is the hue.


>
>     <leaverou> dbaron’s example http://dabblet.com/gist/**3979232<http://dabblet.com/gist/3979232>
>>    dbaron: Our SMIL anim code is using pre-mul, I'm pretty sure.
>>    dino: One old proposal was to transition in hsl.
>>    * sylvaing doesn't think author expect transparent in a transition to
>>               always imply going through black shades, whatever the
>>               normative definition of the keyword says. Makes the keyword
>>               somewhat useless in this context.
>>
>>    dbaron: I have a test case:
>>    <dbaron> http://dbaron.org/css/test/**2009/transitions/transitions-**
>> alpha <http://dbaron.org/css/test/2009/transitions/transitions-alpha>
>>    tab: webkit is non-pre-multiplied.
>>    dbaron: FF is pre-multiplied.
>>    dbaron: So actually everybody is doing pre-multiplied after all.
>>    tab: [checking]
>>    lea: Did FF change?
>>    dbaron: No, we always did.
>>    dino: So we all do the same. Let's specify it.
>>    tab: Yes, chrome does pre-multiplied, too.
>>    [dbaron adding a test]
>>    RESOLVED: Animations of colors are in pre-multiplied space.
>
>