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

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.


>> 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.


>> >> 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?


>> >> (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.

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.


>> 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*.

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.

~TJ

Received on Monday, 28 May 2012 15:40:51 UTC