My point is that sRGB linear interpolation does not accurately model the blending of color that happens in nature, which is something that should happen with CP-437 shade blocks. Here's a web page I set up so you can see for yourself. https://justine.lol/color.html Even within the context of sRGB itself, it's not "correct" at all. For example, yellow and blue should make pink. But sRGB predicts it as being grey. Depending on how good your monitor is, the shade blocks should make pink, but even that is usually thwarted somewhat by subpixel layout. For example, if you drag the window around on an LCD, the coloring of the shade blocks will change weirdly as subpixels move. Subpixel layout shouldn't be an issue with IBM-PC CRT monitors. I wish I had one to confirm what it does. But in general this is just one of the weaknesses of the sRGB colorspace. But if you use something like CIELAB then it does predict pink. But that space has weaknesses of its own. But those problems are nowhere near as challenging as shade blocks, because linear interpolation just chooses a new color and doesn't need to predict anything. To choose colors for shade blocks you're applying your model to predict a more natural phenomenon.

There's a difference between linear interpolation of sRGB values (what you're doing on your page) and linear interpolation of linear RGB values (which gives better results). This is the explanation that made it all fall into place for me: http://www.ericbrasseur.org/gamma.html?i=1 . The linear RGB colour space is also a linear transformation of the CIELAB space so doing the interpolation in this space is equivalent to transforming to CIELAB space, doing the interpolation there, and then transforming back.

However, for the purposes of Area 5150 I think the differences between sRGB interpolation and linear RGB interpolation would have been too subtle to notice since there are only 6 * 16 * 16 = 1536 dithered colour/pattern combinations to choose from in the first place - the error introduced by that quantisation is likely larger than the sRGB vs. linear RGB difference. But I used linear RGB anyway, just to be correct about it.

I agree that gamma correction helps, but we're not talking about gamma, we're talking about color. Here's a version of the page I shared earlier with ITU REC BT.701 gamma correction applied: https://justine.lol/color-gamma.html It still has the same color problems. In fact they should be easier to see now that the white/dark issue is fixed.

Could you explain how linear interpolation is different from sRGB interpolation? I would have thought they were the same thing. If by sRGB you mean interpolating but being lazy about gamma, I'll be the first to admit that's just plain old incorrect, even though laziness is sometimes a virtue.

Also are you one of the demo authors? If so we could probably move this conversation to Discord or email and we could try some more blending methods!

Yes, I'm reenigne from the demo. Feel free to contact me at andrew@reenigne.org.

I'm not sure what you're doing with the colour mixing on that page but I'm wondering if you're just applying a gamma curve to the mixed result. This is what I meant:

sRGB interpolation:

  r_final = r_1*x + r_2*(1-x)
  g_final = g_1*x + g_2*(1-x)
  b_final = b_1*x + b_2*(1-x)

linear RGB interpolation:

  r_final = 255*((((r_1/255)^2.2)*x + ((r_2/255)^2.2)*(1-x))^(1/2.2))
  g_final = 255*((((g_1/255)^2.2)*x + ((g_2/255)^2.2)*(1-x))^(1/2.2))
  b_final = 255*((((b_1/255)^2.2)*x + ((b_2/255)^2.2)*(1-x))^(1/2.2))

The real gamma correction formula is actually slightly more complicated than that because it's linear up until the sRGB value is about 10 then then follows a ^2.4 curve but the difference is too small to notice.