Re: [css3-transitions] colour space used for colour interpolations

On Mon, May 28, 2012 at 5:39 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Sun, May 27, 2012 at 1:03 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> > On Sat, May 26, 2012 at 11:49 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> > wrote:
> >> In the obvious way?  I'm confused.  In the quoted segment above, you
> >> cite a small issue with HSL (the presence of "seams" in the hue every
> >> 60deg as a reason why you feel it doesn't make sense to transition in
> >> HSL.
> >
> > That is not the only reason but I think transitioning hue if there are
> > discontinuities will not give a desirable effect.
> > I'm not sure if this is a small issue...
>
> What I'm confused about is that transitioning through the RGB cube
> gives undesirable effects as well - the hue changes in an
> unpredictable-to-human-intuition way.
>

RGB is not an 'intuitive' colorspace. It is based on reality.
A red to green gradient is like a red light that is fading while a green
light is illuminating. Depending on the response curves of the light, when
they're both 50%, they might be less than 50% luminosity.
RGB is light
CMYK is ink on paper
Lab is how our eye perceives the world so it is intuitive. You will find
however, that most designers will prefer RGB since that is easier to
understand and what they are used to.

I'm unsure where to place HSL...


>
>
> >> Transitioning in RGB is worse in every way.  It doesn't preserve *any*
> >> quality of the endpoint colors when transitioning.  The RGB cube has
> >> almost nothing to do with human eyes or perception, and straight lines
> >> through the cube produce nonsensical color transitions.  Gray is *in
> >> no way* halfway between green and blue, in *any* reasonable and
> >> intuitive system.  But RGB produces that as a matter of course.
> >
> > Did you mean green and RGB(255, 0, 255)?
> > Just green and red will produce RGB(128, 128, 0) which isn't gray.
> >
> > I haven't heard anyone complain about interpolating colors. Maybe you're
> > thinking of the muddy appearance of gradients because of the sRGB
> transfer
> > curve?
>
> I would be astonished if you'd never heard of anyone complaining about
> yellow->blue, for example.  It's horrid-looking if you do an RGB-space
> non-premultiplied transition.
>

Why would premultiplication help? (Or does it not? I'm unsure why you
mention 'non-premultiplied')
I think you're seeing the 'muddy' gradient issue that is caused by the sRGB
response curve. Switching to an RGB profile (or Lab) that doesn't have this
feature will fix that. The color-interpolation property does to, but it is
only a partway solution.


>
>
> >> >> Ultimately, what matters is what the system graphics libraries
> >> >> support, or can be extended to support.  HSL is a pretty shitty
> >> >> colorspace, but it's simple to work with, and way better than RGB for
> >> >> most things.  If we can convince the implementors working on graphics
> >> >> to do a better colorspace, awesome, but if we can't, falling back to
> >> >> HSL is acceptable in my mind.
> >> >
> >> > Even though we offer HSL as an option in our apps, interpolation is
> >> > always
> >> > done in the native colorspace (RGB or CMYK).
> >> > So, I feel that it's a little odd that you transition through the
> hues.
> >>
> >> I don't understand what you mean by this.  Are you saying that people
> >> never choose to transition in HSL?  Or are you saying that you allow
> >> colors to be specified in HSL, but always transition in RGB or CMYK?
> >
> > You can specify them in HSL (both in the app and in the model), but if
> you
> > transition or manipulate them, they will always be converted to RGB
> first.
> > Otherwise, a gradient with 2 HSL color stops with different hues, will
> > display a bunch of intermediate colors. For color conversion, there are
> no
> > HSL profiles since it's just a simple formula on the raw RGB values,
> which
> > is why it's always converted to RGB.
>
> I'm confused now.  This thread is about the color-space used for
> interpolations.  Are you asserting that no additions are necessary,
> and we should just always transition through RGB?
>

I was stating how we generally deal with HSL in our apps.

I do think that we should not add the color-interpolation property.
Let's start by adding support for Lab and then piecemeal bring better color
management to the browser. (color-interpolation could be OK but it should
convert the colors to device independent color instead.)


>
> >> >> (The major problem with HSL, more than anything else, is that there's
> >> >> no analog of "premultiplied" colors like RGBA has, so transitions
> >> >> to/from 'transparent' are going to be ugly.  I don't think any of the
> >> >> better colorspaces have a solution to this either.)
> >> >
> >> > Split out the alpha. Then transition RGB and alpha separately and
> >> > reapply
> >> > the alpha on the transitioned colors.
> >> > This is how we do it in InDesign, Illustrator and Photoshop and I
> >> > haven't
> >> > heard of any complaints about quality.
> >>
> >> This doesn't help with transitions to/from 'transparent', the most
> >> common transparent color.  It's also inconvenient when defining
> >> gradients, for example - going from green to transparent to blue
> >> requires *four* color-stops, as you have to double up the
> >> "transparent" one with two different hues so each surrounding color's
> >> transition looks natural.
> >
> > Really?
> > I've attached a simple gradient that has a transparent midpoint. Does it
> not
> > look natural to you?
>
> No, it doesn't.  It's less noticeable in the magenta side, but the
> green clearly darkens and turns grayish about two-thirds of the way
> through the transition. You can tell pretty strongly that when it's

composited over the blue it actually makes the blue substantially
> darker over most of the transition.
>

I should have been more clear about what I did, The midpoint was RGBA(128,
128, 128, 0) which has a color between the 2 endpoints but an alpha of '0'.
I've attached a new png that has a 'transparent' midpoint of RGBA(255, 255,
255, 0) which matches your premultiplied behavior.


>
> Here's an example you can look at in current WebKit, which I know
> still uses non-premultiplied gradients:
>
> <!DOCTYPE html>
> <style>
> div { position: absolute; }
> .b { width: 100px; height: 50px; background: blue; top: 5px; }
> .g { width: 140px; height: 50px; top: 30px; }
> .one.b { left: 20px; }
> .one.g { left: 0px; background: -webkit-linear-gradient(0deg,
> rgba(255,0,255,1), transparent, rgba(0,255,0,1));}
> .two.b { left: 170px; }
> .two.g { left: 150px; background: -webkit-linear-gradient(0deg,
> rgba(255,0,255,1), rgba(255,0,255,0) 50%, rgba(0,255,0,0) 50%,
> rgba(0,255,0,1));}
> </style>
> <div class="b one"></div>
> <div class="g one"></div>
> <div class="b two"></div>
> <div class="g two"></div>
>
> The first one simply transitions to 'transparent' (rgba(0,0,0,0)).
> The second one instead transitions to the correct transparent hue.
> The difference is *extremely* clear when they're next to each other
> like this - one is ugly, one is not.
>
> Once WebKit does its transitions in premultiplied space, both of them
> will look like the second one.
>

Yes, the premultiplication will throw information away which is why you'll
match.


>
>
> >> This hack is *impossible* to do when
> >> creating 2d gradients like the mesh gradients we're talking about for
> >> SVG.
> >
> > Hopefully meshes won't use premultiplied alpha... Do they allow alpha?
>
> You're not getting what I'm saying.  If you *don't* use premultiplied
> alpha, *you will get bad results*.
>

Sorry but that is just not true.

The reason I'm worried about alpha in meshes is that they will start
interacting with themselves since they can fold over. Historically, this
makes rendering a lot harder. I also don't think there are other basic
drawing operators that have this behavior.


>
> Yes, SVG allows alpha in practice.  SVG2 will be specifying how
> non-opaque colors actually work when used in the various color
> attributes.
>
>
> >> It would just be nice if there
> >> was some similar transformation that could be done for transitioning
> >> in HSL or a similar colorspace.
> >
> > Yes! Let's add Lab and have the color interpolations separate from the
> alpha
> > there.
>
> Unfortunately, that brings us back to the "transitions to/from
> 'transparent' are ugly" problem.


Ugly as in 'ugly to define in a spec', or 'ugly to render'?