Current state of things:
"Hue" is the normal, boring, RGB hue that's mostly green.
"Fair hue" is a scale of fully saturated colors (except for brown, of course, but even those are about 90% saturated, which is why they're pale-ish browns) but with 1/8 of the scale for each of red, brown, orange, yellow, green, cyan, blue, purple.
It turns out that the set of useful colors (at least to my taste) have lots more shades (darker than fully saturated) than tints (lighter), so "color" is a scale that's meant to be usable as a single color number, ignoring the three-dimensional nature of the full color space, that includes greyscale, divides the rest of the scale fairly among hues, and varies continuously between roughly 50% and 100% saturation in each hue range. It's "roughly" 50% because the darkest shades are mostly colors with names, e.g., maroon, navy, etc. And brown and orange are the same hue range, so a dark orange is brighter than a light brown, more or less.
Finally, "crayon" is the set of 100 named colors, mostly but not entirely X11 colors, from the existing crayon library, with no attempt at continuity.
Still to be done: In the color scale, saturation is continuous but not differentiable. I should try a sinusoidal interpolation to see if that looks better.
Thanks! See, Jens, that's at least two of us... :~)
Left color is linear interpolation; right is sinusoidal.
I'm embarrassed to say how many trials it took for me to get the formula right. I think it's better, but of course the cost of a gentle slope near 100% and near 50% saturation is a steep slope near 75%. But it's worth it to avoid the super sharp bright lines in the linear version. Right?
I prefer the version where highly saturated colors occupy smaller percentage of the whole spectrum even if that means that in its neighborhood change is very steep.
Huh. Any other votes? Or, maybe some other function that's smoother than triangle wave but sharper than sin? @jens, you're the easing function expert...
Left to right: sin, linear, sin^3. The latter gives less of the highest and lowest saturations than plain sin, but doesn't help that much because the in-between parts are steeper, so fewer colors, I think.
Thanks for the poll, but you mean "color scale" I think. With respect to hue scales, of course we'll offer both. But the idea of a color scale is that a color-naive user can just cycle through color numbers and something reasonable will happen, so there should only be one.
The normal inherited-from-Scratch hue is part of HSV (hue, saturation, "value"), which is one of several possible ways to slice three-dimensional color space. (RGB is a better-known way.) "Fair hue" is (apart from adding brown as a color in its own right) just a nonlinear hue scale, stretching orange and yellow, shrinking green and (slightly) blue.
The "color" scale (with three variants proposed) is meant to be a single axis that combines hue with value (what we call brightness) in a single dimension. 3D color space is for color freaks who want precise control over billions of displayable colors. The single scale is for kids who just want a blue, let's say, and don't care about exactly which blue they get. So they'll have access to a range from spectral blue (the brightest blue in the color scale) down to navy blue (very dark, almost black), but they won't be able to ask for "light sky blue" for example. Trading away flexibility for the sake of simplicity.
I suppose I should experiment with a reduced range and finer detail, going only as far down as 75%, say.
So, I collected some statistics on the color ranges. There's more variation in all of them, even the plain sin interpolation, than you can tell from the color bars. I should say that what varies is the "value" (stupid name), not the "saturation," because in HSV the former gives the range from black to full color, whereas saturation is just about the range from white to full color, and I don't have tints -- not only because of my own color taste, I remembered, but because most projects are done against a white stage, and so shades stand out much more than tints.
Anyway, I'm attaching three spreadsheets, I hope. Each row is R,G,B,H,S,V for one color slot out of 300. (The actual scale will go to 100, but fractional colors will be allowed. Since the colors are computed by interpolation, there is in principle no limit to the precision.) Because of the weirdness about brown and orange, anyone interested will gain the most insight by starting at row 151, halfway through (because color numbers start at 0 but list items start at 1), which is full spectral yellow.
Can we split this topic to a new one titled maybe "Color scale(s)", please, so I and others will know which topic is about colors.
I would also like to "split" the Color scale itself so that when you want to cycle through only the highly saturated colors because you use high Ghost Effect (on darker background), you will be able to cycle only through the 100% saturated ones, but in all other cases you will be able to cycle through all of them (contained in either the linear or the sin^3 proposal above).
What do you think?
This split could be offered as drop-down parameter added to the color related blocks with the latter as a default. What do you think?
So, my feeling about this is that color space is really three-dimensional, and people like you who think about transparency and background will need the control offered by using all three (maybe using fair hue instead of normal hue). The one-dimensional color scale is for the blissfully color-naive such as I was as a Scratch user trying to cycle through colors and having no idea why all the colors seemed to be green, or why I got trapped in black no matter what I did with the color number. Having a newbie-oriented single color number in which you don't get trapped in black and you don't see nothing but green is the goal of the color scale. It defeats the object if you have to choose which color scale you want, when you have no idea what the difference is.
Not trying to close off discussion, but first say why you think I'm wrong to want a single newbie-oriented scale (if I haven't convinced you) before raising your specific alternative.
And, of course, you can create your own scales. The code for all this will be in a library, so it should be remixable.
