Show HN: Penumbra, a perceptually optimized color palette based on natural light (github.com)

I’m claiming it is an improvement in terms of usability, simply because Solarised wasn’t designed with these properties in mind. Whether it’s significant everyone needs to judge for themselves. I personally was mostly annoyed by how some colours are over-emphasised with Solarised, especially magenta and red, to a lesser degree orange.

You could take a fundamentally different approach and use different levels of emphasis for different colours, but I don’t think this was done in a quantitative and purposeful way. It’s also just not the approach I favour as I (and probably others) prefer an overall less busy look more like a text.

And aesthetics in general are of course subjective and were admittedly only of secondary consideration.

Also, the light theme only has a “barely enough contrast” version due to constraints described in the README, the dark theme has options with much more.

(compare it to the greys used in the samples and you’ll see what I mean)

When trying to encode highlighting with only chroma and hue and still be accessible, one would probably have to limit the palette to two hues which obviously isn’t practical. This means it would be necessary to use luminance, which expressly goes against the design goals and would eliminate the advantages I’m trying to achieve for people with normal vision.

But you're right, I should have been more clear in the docu, this palette is actually particularly unsuitable. (update: clarified it now)

I honestly haven’t put much thought into “marketing” the theme yet and I would want to properly think about how to best do the highlighting before showing it off in real code. Ideally the latter also with the help of more seasoned programmers.

I appreciate the feedback and will try to keep it in mind once I get to that stage!

Of course this means that “yellow” no longer looks like the (much brighter) yellow that we’re intuitively used to, but that yellow would also jump out from the page much more than the main text colour or other “naturally” darker colours.

And I still tried to position them as close as possible to intuitively named colours though with all the other constraints there wasn’t much room for that.

Whether you think this even luminance is something desirable is up to your personal preference, but in my opinion it makes the code more readable as your eye isn’t drawn to things as much when you’re not actively scanning for them.

I suspect a useful tool would be one that starts with vision science based uniformities but that then enables personalised tweaks, ideally with vision science guidance.

To your point, it matters what kind of tokens a colour is going to be used for. If they’re small (eg operators), then the effective perceptual uniformity is broken. They’ll be less conspicuous. Being brighter and more saturated would probably help. Perceptual salience can be tricky, and it’s useful to remember that our colour vision is flawed and finicky. Similarly but inverted for large tokens such as class names.

Beyond that, once you start modulating saturation and brightness to get a nicer look, you’re back into a 3D colour space where the evenly spaced hues idea starts to make less sense, or so I suspect.

Nonetheless, cool work! I would have liked to do the same if I was able!

    I use syntax highlighting is to... well, highlight important things.

If you just like them aesthetically and all they’re meant to do is look good, feel free, though I have to say they weren’t designed with aesthetics in mind at all.

For accessible categorical colour schemes, check out Okabe-Ito, Paul Tol or colour brewer.

    //fix the sine wave amplitude and offset
    static final float CHANNEL_MUL = 127.5f;
    static final float OFFSET_R = 0f;
    static final float OFFSET_G = (float)(TWO_PI/3);
    static final float OFFSET_B = 2 * OFFSET_G;

    public int buildColour(float theta){
        final int r = round(CHANNEL_MUL * (1f + sin(theta + OFFSET_R)));
        final int g = round(CHANNEL_MUL * (1f + sin(theta + OFFSET_G)));
        final int b = round(CHANNEL_MUL * (1f + sin(theta + OFFSET_B)));
        
        return 0xFF000000 | (r << 0x10) | (g << 0x08) | b;
    }

This tool that others have linked is pretty good if you’re fine with relaxing the constraints (just make sure to change to colour space to LCH OKlab): https://huetone.ardov.me.

https://en.wikipedia.org/wiki/HSL_and_HSV

I am doing everything else extra to make up for the lack of contrast in luminance if you read the documentation, but of course that can only do so much.

The reason to choose uniform luminance is also explained, and motivated by classical typography where you aim for a uniform, even appearance of text. I was attempting to achieve this while using the remaining colour space to still allow for the ability to scan for hue/chroma.

There was never any room to make it look “good” or “pretty” and as much as I personally also value beauty in design, I put function first here, even if that makes things look “muddy”.

Plus the folders in the repo are named after what implementation they contain which I hoped was self-explanatory.

Imho OKLab should be the defacto standard for designing with colour, I’m a big fan. Using the colour space based on the display technology never really made sense in this context as we are designing for humans and the display is merely a constraint.

Is it at least acceptable with the contrast++ version?

On the other hand, if you can't tell apart the cyan from the magenta, something else is going on.

Personally, I could see myself tweaking the palettes to have a bit more saturation and maybe even have a particular hue palette or have the hues centre around a particular value as you do with the "warm" variant or the "Zenburned" (my fav, and similar to my own manual scheme) in the showcase (https://github.com/mcchrish/zenbones.nvim/blob/main/doc/show...).

Interesting to compare to the the parent post as luminance/brightness contrast based perception is generally better than our colour contrast based perception. There's arguably less information, as colours are categorical (not continuous like brightness) and colours multiplex brightness with hue and saturation, but there are probably some pretty objective metrics in which your kind of scheme would tend to be better in readability.

However note that it is quite difficult to get Zenbones work with existing colorschemes, I tried creating/tweaking one based on Zenburn, but in the end I had to go back to the original Zenburn because Zenbones just wasn't distinguishing enough for the various treesitter highlighting groups.

But perhaps some of the zenbones concepts could be combined with Penumbra in penumbra itself to have another variant in addition to the contrast++ one.

And as mentioned elsewhere there are scientific ways to produce colormaps that work for people with color vision deficiency too, so it'd be nice if that was addressed.

I’m not a fan of this almost fully monochrome theme though, by limiting yourself to differences mostly along one axis, you quickly run into to issues where adjacent values are hard to distinguish. I would argue that since we are trying to encode categories, it’s a mistake to completely forego chroma and hue.

Thanks!

[1]: https://protesilaos.com/codelog/2021-02-25-modus-themes-diff...

There is an issue on the main repo where I answer a similar question but to my knowledge there is no truly optimised categorical palette for colour blindness (only uniform colour maps) and that’s actually something I’m also doing work on.

Meeting the minimum values for body text in this new standard is unfortunately straight up impossible if you want to maintain uniform chroma for the syntax colouring as the contrast requirements are simply too strict and the sRGB colour space too small. I’ll try to read through all the justifications at some point and aim to meet their goals as best as possible once I understand them.

Luckily the high contrast version is already very close to meeting the standard for fluent text and also has maximum chroma so at least there’s already a version that’s at least usable under these guidelines.

The tool you linked is great and honestly if it would be updated to use OKLab instead of CIELab and allowed for additional constraints, would make my efforts obsolete. As it is, they are using maximum chroma per hue and non-uniform hue differences (plus CIELab has hue prediction errors in the first place).

The original intent was really just to use it myself, but if at least a couple other people may benefit, I feel like putting in the effort to make it shareable is worth it.

Me too, on VSCode. looks nice, let's have a try.

https://bottosson.github.io/posts/oklab/

Making the public accusation of plagiarism is a serious thing to do

If it’s not the actual design goals that work for you, it might also just be the fact that even the enhanced contrast versions are overall relatively low contrast compared to many other themes. Often times “just enough” can be more pleasing than maximum contrast.