Björn Ottosson writes about color science for graphics, including the Oklab color space, gamut clipping, and how software handles color incorrectly.
HN commenters recommend Oklab as simpler than CIELab and better than HSL/HSV, and cite his post on why linear color is poor for gradients.
The #1 best "Blender tip" (that also applies to computer graphics in general), is that by default it is horribly incorrect with its treatment of colour spaces and especially gamma/tonemapping.
Rather than me clumsily explaining with text how to get this right and have your artwork "pop" with very little effort, watch this video titled "The Secret Ingredient to Photorealism": https://www.youtube.com/watch?v=m9AT7H4GGrA
Combine that with physically correct materials and rendering, and you could literally "sketch" a handful of grey boxes with a single area light and have it nearly pop out of the screen with uncanny realism!
The #2 tip is that chances are that you're probably working with a cheap LCD monitor. Even for $600-$1000 you can get a very decent monitor with DCI-P3 or AdodeRGB wide gamut support and more accurate colour. That helps to produce content that is consistent and correct. That, or invest in a calibrator and set up your operating system colour management with the ICC profile of your panel. Without this, images you grab from Chrome or Firefox will shift in hue and/or brightness when you import them into image editing software. Test your browser with this site: https://cameratico.com/tools/web-browser-color-management-test/
The #3 tip is that you can make much better colour choices working in a perceptual space. The colour pickers in most software use trivial RGB 0..255 ranges mapped to a rectangle. This is garbage, criminally lazy, clownshoes programming.…
Whenever linear RGB / gamma discussions come up, you know there's going to be a lot of folks going on about how frustrating it is that the default for most apps is to do their blending/filters/etc in gamma space (as TFA does).
And they're right. But there's an entire flip side of this coin, called Linear is Not Always The Answer.
Are you dealing with the behavior of light? Then you should be a linear colorspace.
But if you're performing artistic operations or other things that need to look right to a human, this is not what you want. What you actually want is a perceptually-uniform colorspace. Linear RGB is most definitely _not_ perceptually uniform! It's in fact, much worse than sRGB!
sRGB for all its flaws is at least roughly perceptually uniform for grey tones, a kind of "poor man's perceptual space". Color mixing, gradients, etc etc all work much better in a uniform space.
I've fallen in love with Oklab as a colorspace. (https://bottosson.github.io/posts/oklab/ ), which has in practice provided excellent results.
Light? Use linear rgb. Human vision? Use Oklab.
This looks fantastic for working with colors, and from a great developer too. A very very similar js library is Culori [0, 1], which I discovered on the original Oklab introduction post [2].
If you're doing generative artwork or any procedural work with a non-fixed palette, a good color library and working in linear or Oklab based colorspace is a must. Using sRGB or HSV/B when interpolating for gradients or generating palettes or complementary colors is extremely painful; a 50% brightness (HSV) yellow is visually much brighter than a 50% brightness purple, with similar issues cropping up for saturation. Balancing the lighting and contrast of programmatically generated colors is so much simpler when you have a perceptually uniform colorspace like OkLCh, or linear RGB if you're working with predefined hex values.
[0]: https://culorijs.org/
[1]: https://github.com/Evercoder/culori
[2]: https://bottosson.github.io/posts/oklab/
For others, I'm sure parent knows: OKLCH is largely a bugfix for CILEAB. Both try to make a color space where even steps feel evenly spaced to a human. But CIELAB had procedural flaws in its creation.
See slide 19: https://www.w3.org/Graphics/Color/Workshop/slides/talk/lilley -- if you ask CIELAB to make "pure blue" (RGB 0 0 100%) become grayscale, the intermediate colors become purple to the human eye. The entire point of a perceptual color space is that that doesn't happen. OKLCH fixes that.
BTW, credit to Björn Ottosson, who basically side-projected a color space into the web standards and more: https://bottosson.github.io/posts/oklab/ ... folks like him are why we sometimes have nice things!
It's not you or your display, linear color just isn't great for gradients: https://bottosson.github.io/posts/colorwrong/
It can be better than sRGB for the color part of gradients but is awful for the brightness axis. The reason why linear color is so important for operations like blending light, antialiasing, and dithering is also why it is bad where perceptual uniformity is desired. sRGB isn't as good as Oklab or CIELAB perceptually, but a grayscale ramp rendered in linear color is so distorted towards white it's useless. Image formats also encode non-linear color for good reason. "Use linear color everywhere" is overly simplistic and bad advice.
Amy Gooch's Color2Gray and various follow-on work has better coverage of the OP's actual goal:
> evaluate relative brightnesses between art assets, and improve overall game readability
The method in Color2Gray is trying to enhance salience, but the paper does a good job of comparing the problems (including red / blue examples in particular).
Like other commenters, I think oklab would look better than CIELAB on the example given in the OP. https://bottosson.github.io/posts/oklab/#comparison-with-other-color-spaces and the Munsell data below it show it to be a lot more uniform than either CIELAB or CIELUV.