[css-color-4] Do gradients/animations using lab/lch colors interpolate in the Lab colorspace?

When gradients and animations use lab()/lch() colors, should the gradient/animation interpolate in the lab() colorspace?

If a gradient/animation uses a mixture of lab() and rgb() colors, I assume it would fall back to RGB interpolation.

What happens if you mix lab() and colors in one of the other predefined colorspaces (display-p3, rec-2020 etc)?

@svgeesus

@svgeesus

Isnʼt this just #300 reloaded?

Unless the author or user requested something else, the browser would be expected to use sRGB as its working color space for webcompat.

I don't think so. Authors will be using lab()/lch() for their consistent treatment of lightness, so a gradient from lch(50% 100 10deg) to lch(50% 100 100deg) should use lightness 50% for all its colors. You won't get that if colors are interpolate in sRGB, and I don't think authors should have to opt the entire page into a working lab colorspace to get this.

When gradients and animations use lab()/lch() colors, should the gradient/animation interpolate in the lab() colorspace?

Ideally, yes. But they won't by default, because then the second half of a gradient from

some Lab color
an sRGB color
another sRGB color

would be different in implementations that support lab() and lch(). So for webcompat, the default needs to be sRGB as at present.

Isnʼt this just #300 reloaded?

Yes.

I don't think authors should have to opt the entire page into a working lab colorspace to get this.

I agree, which is why a per-element working colorspace, rather than a brute force all-or-nothing working colorspace for the whole page, is more flexible and author friendly.

I think we all agree that Lab interpolation is in every way superior, and the only reason we can't switch everything to that by default is backwards compat, right?

Assuming the above statement is correct, I think anything where authors have to explicitly enable lab interpolation is a bad idea from a usability point of view and should be a last resort if nothing more reasonable can be implemented. It seems reasonable to me that as long as there's at least 1 non-sRGB color, the interpolation should happen in Lab, since there's no backwards compat concern.

If a gradient/animation uses a mixture of lab() and rgb() colors, I assume it would fall back to RGB interpolation.

If you interpolate Lab and sRGB via sRGB interpolation, you could end up having an abrupt jump in the first interpolation step, since the Lab color may be outside the sRGB gamut. Given that sRGB is rather small compared to Lab, that's not a rare case, but significantly more than 50% likely. Interpolation must always happen in a superset of the gamuts of the colors involved, so Lab is a safe choice, whereas sRGB is not.

What happens if you mix lab() and colors in one of the other predefined colorspaces (display-p3, rec-2020 etc)?

Given that Lab encompasses all visible colors, Lab interpolation should be safe here too.

I agree, which is why a per-element working colorspace, rather than a brute force all-or-nothing working colorspace for the whole page, is more flexible and author friendly.

I don't think per-element would cut it either, ideally it needs to be per operation.
You could have a transition and a gradient on the same element, from different stylesheets. One of them is between sRGB colors, the other between Lab colors. You need to interpolate the former in sRGB for webcompat, but the latter in Lab because sRGB would produce terrible results (since the colors could very likely be both out of sRGB gamut).
There could be a document or element color space to fall back on perhaps, but interpolating Lab colors in sRGB should never happen.

It seems reasonable to me that as long as there's at least 1 non-sRGB color, the interpolation should happen in Lab, since there's no backwards compat concern.

I think this is definitely moving in the right direction, but would suggest modifying this so that if the gradient contains multiple colorspaces, interpolation should happen in an appropriate space that is a superset of them all.

A gradient from device-cmyk to device-cmyk should remain in that space.
A gradient from sRGB to a wide-gamut RGB should probably occur in the wide gamut RGB for best results
A gradient from Lab to Lch, or Lab to Lab should be done in Lab
A gradient from device-cmyk to sRGB, or sRGB to Lab, or some other exotic combination is fairly unikely to give good results, and I'd expect would be down to the user not understanding what they've asked for. I would think the least-bad option is to choose a color space that has a wide enough gamut, which will effectively be Lab.

Edit:

I think we all agree that Lab interpolation is in every way superior, and the only reason we can't switch everything to that by default is backwards compat, right?

Actually while testing for #2023 I found this not always to be the case. Gradients between two Pantone colors based on the Lab space didn't look as "correct" to me as a gradient between them in the CMYK space. Subjective, yes, but I don't think we can assume Lab will always be the best choice. I can knock up an example if this would be useful.

How about the following heuristic then:

Interpolation between colors of the same color space is done in that color space
Interpolation between colors of different color spaces, where one color space is a strict subset of the other is done in the wider color space
Any other interpolation is done in Lab

The heuristic can easily be overridden to a wider color space with the relative color syntax from #3187 that is added in Color 5.

A gradient from device-cmyk to sRGB, or sRGB to Lab, or some other exotic combination is fairly unikely to give good results, and I'd expect would be down to the user not understanding what they've asked for.

Not necessarily. It could be between a variable/user defined color and a fixed color. I don't think we should brush off such use cases.

Given that Lab encompasses all visible colors, Lab interpolation should be safe here too.

Yes.

I don't think per-element would cut it either, ideally it needs to be per operation.
You could have a transition and a gradient on the same element, from different stylesheets. One of them is between sRGB colors, the other between Lab colors. You need to interpolate the former in sRGB for webcompat, but the latter in Lab because sRGB would produce terrible results (since the colors could very likely be both out of sRGB gamut).

Ouch, you are right. (This is why SVG had separate color-interpolation and color-interpolation-filters properties, with different initial values).

Interpolation between colors of different color spaces, where one color space is a strict subset of the other is done in the wider color space

Do we particularly need that one? "wider" is not easily determined; for example display-p3 and a98-rgb are largely overlapping; though prophoto-rgb is wider (and includes imaginary colors)

Do we particularly need that one? "wider" is not easily determined; for example display-p3 and a98-rgb are largely overlapping; though prophoto-rgb is wider (and includes imaginary colors)

I was wondering about that. I think 1 and 3 are sufficient, especially if there's a way to override the heuristic (e.g. relative color syntax to convert between color spaces)

Having a requirement to blend in Lab when you know you can get better, and faster results in another space better seems counter-productive. It might be useful to leave this door open for implementers, but I'm not very invested in this position so long as point 1 remains.

blend in Lab when you know you can get better, and faster results in another space

Could you give an example where blending in another space than Lab is better? I can only think of blending in LCH.

Also, the proposal is not to force blending in Lab, just to have that as a sensible default. Overriding to explicitly use another space would still be allowed. The point is to not require such an override every single time (to avoid blending in sRGB).

Nothing is done in linear RGB except when the user specifically asks for it, as they might when the output level is used as a mask. Blur and other filters are straightforward alpha composition in sRGB or linear RGB, as the user chooses.

It's clear you know something about color, but most of your assertions about its use in CSS have been incorrect. And even if you did have anything useful to contribute, your apparent inability to convey your ideas without inexplicably calling someone an idiot in the process has rendered them worthless. It seems like a colossal waste of your time to me, but suit yourself. I've set your
𝛼=0

Saying that

Nothing is done in linear RGB except when the user specifically asks for it, as they might when the output level is used as a mask. Blur and other filters are straightforward alpha composition in sRGB or linear RGB, as the user chooses.

without seeing the major bug and a fundamental design mistake it is, is why you get

your apparent inability to convey your ideas without inexplicably calling someone an idiot in the process

There is literaly zero polite way to describe the clusterfuck in this thread. #4647 (comment) is one of the most self-explanatory one. How is a gradient from green to red skewing to a large orange part better than the "RGB" labelled one (what RGB by the way ?). What is the point of showing a gradient from "ProPhoto 0, 1, 0", which is an imaginary color, in any other shorter gamut RGB (which involves gamut clipping anyway) ?

Image processing is light transport all the way. Color happens in your brain, no need to bother about it if you are not inside a CMS doing chromatic adaptation and such. Light is well known and well modelled by physics. None of the light physics involves "perceptual" cubic roots functions.

The only part where I use Luv space in my software is for controls in GUI. Then Luv parameters are converted to Yuv -> Yxy -> XYZ -> RGB, and the pixel processing happens in RGB.

What really makes me rage here, is the problems caused by image operations in Lab/name-your-perceptual-mess are well known in a universe of retouchers and CGI artists that seems entirely parallel to yours.

Alpha composition is not alpha composition in sRGB. Alpha means occlusion. Occlusion is an optical thing. Optics don't care about your OETF. No CGI artist in his right mind would overlay CGI on top of real footage in any space with a non-linear OETF. That simply doesn't work.

@aurelienpierre

I have had to vent my feelings about the specification process in the past, but this related to stuff I had engaged in already, while @aurelienpierre is rambling before having contributed at all (as far as I can tell). What they apparently also do not get is that CSS effectively is both a UI and a storage method for color values that brings with it twenty years of legacy and billion-fold compatibility concerns. Please, keep it to productive reviews and proposals. They will be well appreciated.

PS: Singular they, obviously.

Don't serve me the opensource meritocracy bullshit.

What they apparently also do not get is that CSS effectively is both a UI and a storage method for color values that brings with it twenty years of legacy and billion-fold compatibility concerns.

who is "they" ?
twenty years of broken pixel processing.
again, https://www.youtube.com/watch?v=LKnqECcg6Gw

Please, keep it to productive reviews and proposals. They will be well appreciated.

Productive proposal it is:

cancel the project on the current issue, it's nonsensical.
pixel-perfect physically-accurate pipeline is your biggest priority until alpha blending, blurring and gradients behave in an optically plausible way and scene-linear pixel management is the default. Everything else is patching a rotten leg.
email a real color expert to get proper guidance (Mark Fairchild and/or Charles Poynton), stop playing code.
by all means, look at how ACES/OpenColorIO handle pixel pipelines because they have already solved most of the issues you are still fighting with, and in elegant ways, by knowledgeable people.

@aurelienpierre

@aurelienpierre you have been asked several times to stick to the technical topic without adding insults. If you can't manage to be polite we will ban you from participating here. This is your last warning.

Is this the right room for an argument?

@aurelienpierre

@aurelienpierre You seem to have some experience with color in CGI and photography which appears to inform your opinions. Please keep in mind that CSS is a technology that targets a wide variety of mediums (websites, vector graphics, print etc), and thus, cannot be designed solely with the needs of a specific medium/field in mind. Furthermore, color in CSS needs to interoperate with every other part of the Web Platform, with an even wider range of targets. There are also a number of other constraints, such as:

Backwards compatibility. Code previously written needs to continue to work the same, with very few exceptions in cases where the result is very clearly better for every use case.
Color in CSS needs to be defined via a single <color> value, and must interoperate with any other <color> value. This means any color space needs to be able to work with any other, and that rendering intent cannot be perceptual, because we cannot use algorithms that take the entire set of colors on a website into account.
For the same reason, we cannot meaningfully use color appearance models: we simply don't have this amount of data about the viewing environment.
Whatever we choose needs to interoperate with existing tools. E.g. if you find an amazing color space that solves all problems, we'll still add Lab as well because so much tooling supports it.

Lab/LCH might not be perfect, but they do produce better results than the current gamma-corrected sRGB interpolation in nearly every case. You asked, how is "better" defined? By designers, not programmers or computer scientists. Designers are the experts in assessing aesthetics. No matter what numbers say, if designers overwhelmingly deem something as undesirable, it is. UIs are not created in a vacuum, they are created to serve their users, and CSS is a (text-based) UI that also needs to serve its target users.

As an aside, it really saddens me to see how your apparent inability to behave like a decent human being towards everyone else here is making you unable to contribute productively. It saddens me because you did make some valid technical points, but they are lost in the sea of uncontrollable ranting. In the end, you could have used your knowledge to help improve the technology, but all you were able to do was vent. As @faceless2 pointed out, it seems like a poor use of your time, but you do you.

Down the line you will likely realize that being able to communicate your ideas effectively is just as important (if not more) than the ideas themselves. Your ideas make absolutely no difference to the world if you can only express them by screaming profanities, because everyone ignores you and moves on. This is a lesson that many of us learned the hard way in our twenties, and I suspect eventually you will too, hopefully not too late.

[css-color-5] Add interpolation section, define hue angle interpolati…

I would like to contribute my two cents to this discussion.

Firstly, I would encourage us to focus on the very basics. Defining how to interpolate between values in different colour spaces with a number of edge cases might seem necessary and even beneficial/forward-thinking in a small context, but stepping back, colour on the web has never changed it's interpolation method based on how it was defined. I don't think creating a complex set of rules based on multiple variables is going to help anyone; implementers, developers, or designers. If demand arises for all of these context-specific interpolation methods, someone is bound to write a library for it. (Incidentally, I've written a tool to do colour management with a variety of colour spaces for exactly this reason; nothing really exists to do this on the web)

I have been a web developer for much longer than I have been learning about colour science, but I can assure you everything I have learnt has made it more abundantly clear that misconceptions are the norm and that appeals to authority have no place in this discussion. Understanding what I do now, many 'best practices' now have fairly evident holes in them.

The most absolutely critical thing is that interpolation happens in a linear colour space whenever possible without causing issues for legacy. Of course there are many ways this might get implemented, but I'm strongly against the idea of interpolating colour in a colour space which is not a linear transformation from XYZ as a spec-level decision, especially by default.

One benefit in using a single interpolation model everywhere (linear interpolation in the linear working space) is that it is easy to understand and implement, applicable everywhere, and doesn't generate the edge-cases that these 'perceptually uniform' spaces do. Convert all your colours to the working space and do the standard math which has been established for decades.

If demand arises for all of these context-specific interpolation methods, someone is bound to write a library for it. (Incidentally, I've written a tool to do colour management with a variety of colour spaces for exactly this reason; nothing really exists to do this on the web)

There are indeed libraries for it, in various languages, which already demonstrates the need. In particular scientific visualization, and design systems, are two areas which have demonstrated the need for interpolation in perceptually-uniform colorspaces.

The most absolutely critical thing is that interpolation happens in a linear colour space whenever possible without causing issues for legacy. Of course there are many ways this might get implemented, but I'm strongly against the idea of interpolating colour in a colour space which is not a linear transformation from XYZ as a spec-level decision, especially by default.

Since you mention XYZ, I guess that by linear you mean linear-light. Certainly that is one use case. There is also perceptual linearity, which is a different use case (you can't have both at the same time).

I'm curious why you put perceptual uniformity in scare quotes. They have after all been in use for decades.

Yes, I am aware of the success of the success of perceptually uniform spaces in things like D3, and absolutely that is the right approach in those contexts. I was having a discussion just last week with designers at work about the technical considerations when building up the colour guidelines and palette, and again I think perceptually uniform spaces are a great utility here. When perceptual linearity is the primary objective, we should absolutely be able to specify colours in a perceptually linear colour space.

The main point I would like to bring up is the differentiation between a working space and encodings for transfer, display etc. Clearly, choosing a non linear working space wreaks havoc with colours in many ways. Blur and opacity as examples.

Perceptual linearity is a concept I'm not denying certainly exists, but it's a very loose term. The simple fact that something like lines of constant hue have conflicting studies suggest it's not something we should be relying too heavily on at this stage. I have heard that some more research is being done in this space and it's certainly not as conclusive as we might hope for a standard that is going to stay with us for a long time.

Linear tristimulus light is a model that works very effectively, and comes with a whole range of benefits when used as a working space. It isn't meant to be used everywhere, but I would say it's likely a very good default for this application.

I sound like someone with strong opinions and no facts 😅

My reasoning for preferring a linear light default space for interpolating (and by extension, general compositing of layers) is primarily that you maintain energy preservation when doing compositing

You get much more perceptually uniform blur for free
You maintain relative brightness when compositing an image/texture with opacity (easily seen in the reduction of contrast in a semi-transparent image over black in a non-linear space)
Linear fades or addition of images/colours behaves as it does in the real world. Convoluted example, and I understand this is not applicable for everyone, but here's two images, and their sum when using linear sRGB. It looks right; it makes life easier.

[css-color-4] Add Lab <-> CMYK summary #4647

Navigation Menu

Repository navigation

[css-color-4] Do gradients/animations using lab/lch colors interpolate in the Lab colorspace? #4647

37 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-color-4] Do gradients/animations using lab/lch colors interpolate in the Lab colorspace? #4647

Description

Activity

smfr commented on Jan 2, 2020

Crissov commented on Jan 5, 2020

smfr commented on Jan 5, 2020

svgeesus commented on Jan 6, 2020

LeaVerou commented on Jan 6, 2020

LeaVerou commented on Jan 6, 2020

faceless2 commented on Jan 6, 2020

LeaVerou commented on Jan 6, 2020

svgeesus commented on Jan 6, 2020

svgeesus commented on Jan 6, 2020

LeaVerou commented on Jan 6, 2020

faceless2 commented on Jan 6, 2020

svgeesus commented on Jan 6, 2020

37 remaining items

faceless2 commented on May 27, 2020

aurelienpierre commented on May 27, 2020

Crissov commented on May 27, 2020

aurelienpierre commented on May 27, 2020

astearns commented on May 27, 2020

grorg commented on May 27, 2020

LeaVerou commented on May 28, 2020

Smilebags commented on Jul 28, 2020

svgeesus commented on Jul 28, 2020

Smilebags commented on Jul 28, 2020

Smilebags commented on Jul 29, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions