got nerd sniped into quantifying the quality of a palette arrangement and performing random swaps to optimize it.

have an algo idea for this one: gradients trade colors with each other. each gradient figures out its least fitting element (high variance relative to quadratic curve) and expels it on a pile. then it picks from the pile the most fitting element. if multiple gradients want the same color, the best fit wins. if no gradient wants a color, that's a new gradient (after two consecutively unwanted colors). self-assembling gradients trading piles.

hmmm. that's almost a point cloud meshing algo...

step 1: we start with a single "gradient" that contains all colors. we fit the set to a 3d line, then sort colors by projected position on the line. then we concat all gradient groups (currently 1) back into the linear palette. the result looks ordered, but has high variance.

now the gradient has to expel its worst samples. i'll try expelling two, which form a new gradient. actually, why not find the mean variance and split the set by that.

expelling all colors above mean variance onto the pile, then making a gradient from the pile; we don't split gradients once they would have fewer than 3 colors. doing this repeatedly until none can be split further, we get the second image. clearly we need to redistribute pile colors at some point.

now only letting each gradient expel 1 worst sample onto pile if variance is above threshold; each pile color is then auctioned off to the gradient whose variance it would improve the most, by a factor. then all gradients smaller than 3 are broken up and their colors put on the pile. if the pile size is >= 3, it becomes a new gradient. otherwise we run again.

clearly only the very first gradient benefits from this, others don't grow, and we end up with 104 tiny gradients.

hmhm.

obviously a gradient of 2 colors has variance 0. it's perfect. they only take on colors when the variance stays that way or gets better, so no pair-gradient ever grows.

we could make gradients bid on colors even when the variance would be worse, if the variance is still < 0.05; and we get 20 gradients, each with a variance slightly below 0.05.

the result looks like this. better, but how can this be improved further?

Leonard Ritter

@lritter@mastodon.gamedev.place

new visualization.

also some rule changes: divide initial colorset into "gradients" of 16 colors each. when bidding, also bid when when the new variance is only slightly worse, or the bidder's size is 2. bidder's offer is divided by its number of colors, so long bidders lose over short bidders.

when the best bidders bid the same amount, the color is randomly awarded among them.

August 11, 2025 at 1:02:43 PM
(Edited)

more changes: longer gradients are pickier when expelling colors (expel threshold divided by size), and pickier when accepting colors that make them worse (bid threshold divided by size).

bidding by old-variance / new-variance rather than 1 / new-variance, i.e. not the all-over lowest variance gets picked, but the one with the most dramatic improvements.

it becomes obvious that gradients take on too many duplicates that could better serve as "crossroads" for other gradients. these should also be expelled.

hm. this should really be two parts: 1) a metric for a "good gradient" 2) gradients using the metric for both expelling and bidding on colors to judge if the change is an improvement.

also, each gradient should receive at most one new color each round so some don't take too many colors before others can bid on them.

last change. this one is in YUV space (Ycocg). the metric penalizes wide distances over few colors, variance from UV, and variance in Y deltas. no line fitting (with line fitting, you also get cross-color gradients).

Elk Logo

Welcome to Elk!

Elk is a nimble Mastodon web client. You can login to your Mastodon account and use it to interact with the fediverse.

Expect some bugs and missing features here and there. Elk is Open Source and we're actively improving it as a community project. Join us and let's build it together!

If you'd like to report a bug, help us testing, give feedback, or contribute, reach out to us on GitHub and get involved.

To boost development, you can sponsor the Team through GitHub Sponsors. We hope you enjoy Elk!

三咲智子 Kevin DengAnthony FuPatakDaniel RoeTAKAHASHI ShuujiJoaquín Sánchez

The Elk Team