Skip to content

[css-color-5] Hue interpolation and multiple colors #5277

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LeaVerou opened this issue Jul 1, 2020 · 6 comments
Closed

[css-color-5] Hue interpolation and multiple colors #5277

LeaVerou opened this issue Jul 1, 2020 · 6 comments
Labels
css-color-4 Current Work

Comments

@LeaVerou
Copy link
Member

LeaVerou commented Jul 1, 2020

Per discussion in #4735, we resulted in 5 different hue interpolation algorithms (specified, longer, shorter, increasing, decreasing).
However, these are defined in terms of doing fixup on a pair of angles, and it is unclear to me and @svgeesus how this extrapolates to multiple colors, since the fixup may be different per pair. Since we eventually intend to allow multiple color interpolation in color-mix(), as of #4711, we need to figure this out.

@LeaVerou LeaVerou added the css-color-5 Color modification label Jul 1, 2020
@svgeesus
Copy link
Contributor

svgeesus commented Jul 3, 2020

I do like the keyword options that we have for 2 colors, so whatever the outcome for n colors, I would prefer that it simplify down to what we have, when n = 2.

I suspect though that for n > 2 it really just means a weighted sum of (normalized [0 - 360)) angles and they end up where they end up.

In linear-light colorspaces, I think additivity also means that we can do pairwise combination in any order: mix color_1 and color_2 to get color_a, then mix color_a and color_3 to get color_b and so on. Would need to test out that intuition though by doing such a calculation twice (starting from either end of the list).

In general though the order does matter, and greater weight is given to the later colors in the list (same as with alpha compositing, the top one has more effect).

We should also keep in mind what are the actual use case for 3 or more color mixing. Or did we just add it for completeness? If so we can save a lot of trouble by just not doing that.

@una
Copy link
Contributor

una commented Jul 6, 2020

For mixing multiple colors, can we just stack the functions? i.e. color-mix(color-mix( red, white), blue)

@svgeesus
Copy link
Contributor

For mixing multiple colors, can we just stack the functions? i.e. color-mix(color-mix( red, white), blue)

We could, although the order then becomes significant.

@svgeesus svgeesus added css-color-4 Current Work and removed css-color-5 Color modification labels Jan 30, 2021
@svgeesus
Copy link
Contributor

Re-tagging to css color 4 because the color interpolation section moved.

@Myndex
Copy link
Member

Myndex commented Mar 1, 2021

Hi @svgeesus

"...In linear-light colorspaces, I think additivity also means that we can do pairwise combination in any order:..."

YES, at least in part.

  • Assuming the space is essentially unbounded (linearized should be 16bit float+ with no clamps)
  • PEMDAS, regular mathematical order of operations DO apply.
  • compound/complex/non-reversable blend operations are still order specific in most cases.

For linear tristimulus color models, if color-mix() only uses plain addition, then order does not matter. If after addition, there is an averaging, then order does not matter for n-colors being mixed at the same time that are to be averaged at the same time but otherwise mathematical order of operations always applies. However, a key reason to work in a linear-space is to not have to do any averaging at all, just add 'em up.

Order can matter when the blend operations are more complex, like overlay, screen. If you add two colors, and average, then add another and average, order matters regardless of TRC, because that is a PEMDAS issue.

Some gamma encoded tristimulus additive spaces are also not necessarily order specific, except if there are overflow issues. That is, you can add three sRGB colors together in any order and average them after adding all three. Again, PEMDAS applies, but so does overflow or clipping.

I wrote a brief in #4711 regarding recursively mixing pairs only, which on further reading I see @una had already suggested. The post provides additional support for the concept.

Parting Thought on Multicolor Mixing

I say keep it to color pairs, and allow recursive/iterative mixing. BUT

It would be useful to add one utility feature:

Shade/Tint/Tone

Keep it to a pair of colors, but allow the addition of an achromatic modifier, from #00 to #ff OR perhaps it should be -128 to 127, to be added to the mix as an auxiliary additive input but (probably?) does not change the averaging percentages of the two main colors.

I'd say it should be the last of the parameters.

color-mix( orange 35%, cyan, -64)

Which if any of the color parameters the achromatic modifier is applied to depends on the space. It's applied to all three channels in a tristimulus space, but only L* C* in an LCh mode for instance (where it subtracts from C*), and maybe only L* in LAB.

@svgeesus
Copy link
Contributor

Noting that color-mix to allow more than two colors? concluded

Outside of a completely new space for the purpose, n-color mixing needs to be a cascade, where we only mix two colors at any one time.

and was closed, color-mix() now is restricted to mixing two colors. So I think this issue can also be closed, because the situation described does not occur. I think too that this is the correct resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-color-4 Current Work
Projects
None yet
Development

No branches or pull requests

4 participants