- From: Rik Cabanier <cabanier@gmail.com>
- Date: Sun, 27 May 2012 23:03:55 +0300
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Cameron McCormack <cam@mcc.id.au>, "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CAGN7qDDw9Smbwmmt_pC0MvpARhA=Aa=YTguDSQo=cQQ4fOMqzw@mail.gmail.com>
On Sat, May 26, 2012 at 11:49 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Sat, May 26, 2012 at 12:37 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > On Thu, May 24, 2012 at 11:47 PM, Tab Atkins Jr. <jackalmage@gmail.com> > > wrote: > >> On Thu, May 24, 2012 at 9:44 AM, Rik Cabanier <cabanier@gmail.com> > wrote: > >> > Reading a bit more on the wikipedia article [1] on HSL, I came across > >> > the > >> > following quote: > >> > > >> > Because hue is a circular quantity, represented numerically with a > >> > discontinuity at 360°, it is difficult to use in statistical > >> > computations or > >> > quantitative comparisons: analysis requires the use of circular > >> > statistics. > >> > Furthermore, hue is defined piecewise, in 60° chunks, where the > >> > relationship > >> > of lightness, value, and chroma to R, G, and B depends on the hue > chunk > >> > in > >> > question. This definition introduces discontinuities, corners which > can > >> > plainly be seen in horizontal slices of HSL or HSV. > >> > > >> > I believe it doesn't make sense to transition in HSL because of these > >> > issue. > >> > Who would want to create such a synthetic transition? > >> > >> Heh, who would ever want to transition in RGB? It's infinitely worse. > ^_^ > > > > How so? > > 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... > > 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? > > > >> 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. > > > >> (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? > 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? > > In general, RGB-space transitions are done with premultiplied colors > in CSS. We won't be changing that. I know, It's unfortunate that that decision was made but I don't feel like starting that fight over again... > 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.
Attachments
- image/png attachment: Untitled-1.png
Received on Sunday, 27 May 2012 20:04:26 UTC