Show HN: Penumbra, a perceptually optimized color palette based on natural light | Hacker News Reader

Show HN: Penumbra, a perceptually optimized color palette based on natural light

github.com

267 pointssolasluaith124 comments

For this palette, I used recent advances in color science, which made perceptual design more accessible, to choose a set of colors (mainly for syntax highlighting) that have uniform luminance for less visually uneven, fluidly readable code, but at the same time maximally distinguishable hue and chroma. The background colors are based on natural (sun-)light and shade for a more pleasing look than equally neutral greys.

For much more detailed info, including the construction, check out the repository.

There’s also already a (bare-bones) VSCode extension, linked in the repository, but it could admittedly use more informed distribution of colors over tokens, language specific highlighting and perhaps more opinionated use in UI elements.

Open articleView on HN

I'm going to try this because I love the concept. However I have doubts - part of the reason I use syntax highlighting is to... well, highlight important things.

Part of being able to skim code is to pick out the key words or symbols that denote control flow, important (exceptional, even) cases, etc. The dizzying array of identifiers is less important when trying to skim and pick apart the general "feel" of code quickly.

In this pallette, at least with python, the identifiers are red, everything is "flat" (due to the perceptual brightness) and thus nothing really sticks out or gives me "grit" to hold on to when navigating around.

I could be wrong. This is just my hypothesis going in.

Cool project nonetheless, I love the idea to use color science as the basis for this.

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

I think "syntax highlighting" is a bit of a misnomer, "syntax coloring" might be better. Since some type of styling is done to pretty much all code in most of the common themes, you really can't say it's highlighting everything. One principle of design is that in order to emphasize something, other things have to not be emphasized. The syntax coloring just increases the contrast of similarly weighted things.

Exactly, the fundamental assumption that I’m making is that all code should have the same level of emphasis — like a regular text — while maintaining the ability to scan for categories of words.

If someone disagrees with that assumption, the palette will not work for them.

It's really "syntax classification by color" rather than highlighting. The goal is to make related parts of syntax the same color so the brain doesn't have to handle the classification itself (which it's bad at and will short circuit and get wrong sometimes, and take too long other times), sp the goal should usually be to just differentiate parts, not to emphasise/highlight parts (though emphasising code over comments is fairly justifiable, I admit).

"Semantic highlighting" might be an interesting concept to study further. As in, annotated or (semi)automatic highlighting of "pay extra attention while reading" parts of code – tricky, nonobvious, mem/thread-safety critical sections, code that assumes invariants or is responsible for their maintenance, and so on.

Some existing examples are "warning squiggles" added by IDE integrated linters, as well as language-level syntactic markers for "here be dragons" parts like Rust’s `unsafe {}` that can be highlighted by standard syntax highlighters (as an aside, it occurs to me that for simplicity’s sake most syntax coloring is in fact merely lexical coloring, but I digress…)

It seems to me that many color schemes these days choose to render comments in grayed-out, low-contrast colors. I find this to defeat the purpose of comments and maintain the unfortunate notion that they are something nearly redundant. A properly written comment tells me something nonobvious and should be displayed prominently rather than faded into obscurity!

Tree-sitter[0] can provide semantic highlighting and I've been using it with all the languages I program in, including writing my own grammar[1] for a language that didn't have syntax highlighting. The improvement in readability is a quantum leap, because colors actually have semantic meaning rather than just being eye candy.

With the situations you describe, you can write tree-sitter queries to make unsafe code highlighted in a different color, for instance, or highlight specific anti-patterns.

[0] https://tree-sitter.github.io/tree-sitter

[1] https://github.com/siraben/tree-sitter-formula

I absolutely agree that intelligent highlighting or added emphasis to at least some part of the code is very worth investigating. I would argue it should probably be used more sparingly than colouring, but could be complementary. By combining the colours from the base and the contrast++ palette this would even be possible with Penumbra while maintaining the clean separation between colour properties.

In this area, as a novice coder, I am absolutely out of my depth though, so I’d have to defer to actual experts for the implementation.

Someone else brought up a similar point on comment emphasis but I’ve seen the opposing opinion too.

I read code which is not highlighted with little want for color, except certain cases like mixed php and html where I find it really helpful to have the two separated into different hues eg. green/blue and yellow/red.

So I find the trend for color schemes with many lexical types colored differently, unpleasant to the eye and usually of little practical advantage.

The more different things we try to distinguish in a color theme, the harder it is to produce a comfortable aesthetic and the harder it is to make things which should advance or retreat from the eye, to do so.

Keywords can take pleasant color slots which are not the most easily read, because their color confirms they are typed correctly. There is little advantage and much overhead in theming keywords of different types differently. Strings types can all share a hue similarity with small difference to help notice single or double quotes etc. Escaped chars are good to stand out a bit, within the appropriate quotation hue. Comments should be in color range which retreats from the eye a little and is well separated from the executable hues.

I feel its all window dressing, plain text is just a little harder to scan for things than nicely syntax highlighted. Busy, un-finessed syntax highlighting is more of a quirk to be tolerated than it is a comfort.

The original scheme that made me realize this should always be the goal was Steve Losh's BadWolf [1]

Control flow & operators etc are dark red, identifiers more or less neutral, and top level functions accented. This makes it easy to scan quickly, because you want to be able to navigate a file quickly without getting bogged down in a rainbow of color and then slow down down to understand the tricky bits.

Just reading the comments provided a lot of insight on things like accent color usage.

Im very used to warm colors now so Gotham is the closet spiritual thing in VSCode to this.

[1] https://github.com/sjl/badwolf/ https://raw.github.com/sjl/badwolf/master/colors/badwolf.vim

Thank you for this succinct explanation, that’s pretty much exactly what I was aiming for! Would you be okay with me adapting the explanation for the README at some point?

Feel free!

Feel the same way. I’ve made my own personal colour scheme over time by manually adjusting colours by eye (fun procrastination). Following personal and intuitive preferences this way has lead to a palette that is almost certainly not uniform but one that I mostly like.

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!

Try https://huetone.ardov.me/ for a tool based on vision science guidance.

My base assumption was to treat code like text and you’re right, this means that smaller tokens are not as salient as larger ones. But if you really wanted to go down that rabbit-hole you’d ideally have to adjust each token individually according to its size, including font size, physical display size and potentially even take into account glyph differences between typefaces.

Given the way that themes are currently implemented, I thought making this simplification was reasonable.

If you’re not dead set on the hard constraints I was aiming for, the tool linked below looks great for your purpose though, except it should really be using OKlab instead of CIELab.

> Perceptual salience

This is defined by luminance. This is the 'L' in Lab and OKLab (and in their polar representation: LCH and OKLCH).

Very interesting to see this, because a few days ago I started using a theme that takes the complete opposite approach: limited hue range, but wide luminance range.

https://github.com/mcchrish/zenbones.nvim

I've found it to be quite practical because it makes keywords easier to pick out, and it allows search matches and diagnostics to stand out better.

Nice work ... really like these!

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.

I actually think that in overall perceptual difference, using hue and chroma only is in the same ballpark as luminance only. The relationship between colours would also be totally different as they are arranged on a line vs a circle/polygon in terms of perceptual difference. Would be interesting to compare quantitatively.

Of course that doesn’t tell the whole story because in the end luminance and chroma are not perceived the same way as we tend to associate luminance with more with distance and light and hue and chroma more with the surface properties of the object. (As you mentioned we also tend to treat luminance as a continuous variable and colour as categorical even though both are continuous.) So if you want to use luminance because of this difference, that is a valid, but fundamentally different approach, but I don’t think it would necessarily be superior outright and I’ve tried to make the argument of why I prefer mine.

Zenbones allows to define custom color schemes by providing just a few base colours and overrides. You could try creating one based on penumbra to have both lightness contrast and distinct hue.

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.

Just on the last point, I’d be interested to know what scientific ways to construct CVD-friendly colour maps you mean.

I’m aware of all the continuous colour maps for visualisations and these are pretty much “solved”, but for discrete, categorical ones, the optimisation is trickier and I’m only aware of “good enough” versions rather than fully optimized ones.

Colorbrewer2.org has a colourblind safe version. https://peterkovesi.com/papers/ColourMapsForColourBlindIAMG2... talk about designing colormaps in the colorspace of a particular colorblindness (instead of checking whether it is safe after the fact which is non-optimal). My very basic understanding of that is that it'd replace sRGB with a colorspace that represents a particular colorblindess and then uses the same algorithm it'd use on sRGB to obtain a nice scheme in the colourblind space (or at least as much as it is possible given the constraints/reduced gamut).

I am not colourblind though, so I can't vouch for how good these are in practice, but at least there is some systematic thought that went into the process instead of ad-hoc rules.

Colorbrewer is safe for CVD but not optimized to be as distinguishable as possible no matter your impairment as far as I’m aware. That’s what I’m trying to do in a different project.

Colormaps have very different constraints due to having to cover a continuous ramp and are therefore also not optimal for categorical palettes. I personally like these the best overall: https://www.fabiocrameri.ch/colourmaps/ but there are many good options at this point.

As I said below, I can totally see how taking the opposite approach of making different keywords more or less salient could be just as valid, if you prefer this over having an even, “text-like” appearance. I’m not aware of a fully coloured theme that quantitatively does this but it’s probably out there.

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.

This looks really cool!

I have deuteranomaly (the most common form of red-green deficiancy), and this doesn't work for me at all. I often rely on colors having both different hues and different saturation/brightness. I realize this is very likely not a goal of this color palette, but I thought I'd mention it anyway.

Yes, I’ve even updated the README to specify that accessibility for colour blindness is sadly impossible with these design goals and that they even make the palette particularly unsuitable for affected individuals, for the exact reasons you state.

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.

Are there any color palettes like this or solarized specifically aiming at various types of color blindness? I think the Emacs "modus" themes allow for this[1], but I've rarely seen something that's "optimized" for some type of color blindness instead of not just being completely unreadable.

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

Solarized is fine, so is any theme that emphasizes the red-blue or blue-yellow axis instead of the red-green one. Deuteranomaly is often misunderstood to mean that red and green are close to identical (which they are not necessarily), and everything else remains unaffected. It's much more complicated than that and e.g. different shades of red / green / orange can be hard to differentiate as as well.

What's a little frustrating sometimes is that deuteranomaly affects around 8% of men, but is quite often ignored simply ignored. Using red-blue instead of red-green by default would make a lot of problems disappear.

I think colour blindness varies too much - I am too but I think solarized is great, and this looks (at first glance, afk to compare) very similar.

Just have to find something that looks good, or that almost does and tweak it slightly.

But red/green in slide decks to draw distinctions/emphasise things should be banned. Except perhaps absolute #f00/#0f0, which nobody uses because they're not pastelly and subtle (and identical-looking to a chunk of the room) enough.

See https://journals.plos.org/plosone/article?id=10.1371/journal... and the "cividis" colour palette for one approach to colour blindness friendly colour scheme.

There are a couple of hand picked categorical palettes for visualisations and at least for VSCode (see the issues on the main repo), there are also some themes. None of them are truly optimized as far as I’m aware, just chosen to be good enough, and this is also something I’m working on (in the visualisation context).

Let me first state that I understand that your goal was not to create an "accessible" palette and you state in your README that the palette is not "particularly suitable for people with colour vision deficiency". But being colorblind myself (deuteranomaly, up to 8% of the male population), I would still like to offer feedback: it is extremely hard for me to distinguish most of the colors in this palette (especially in the light version); more so than with "normal/default" palettes

I’m actually working on another project where I’m trying to design fully optimized categorical colour palettes for people with colour vision deficiency, so I’m fully aware of this issue.

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)

So, um, I am a professional artist, and one of my regular tricks for figuring out why a drawing isn't working is to throw a desaturation layer on the top of the stack. Quite often it turns out that I have chosen colors that have contrast in saturation and hue, but very similar values. I play with the colors until they work in greyscale, then turn off that desaturation layer, do some small tweaks to make sure their hue/saturation work with their new values, and things look a lot better. A drawing with little contrast in its values is a drawing that is muddy and hard to make out. If the values are the same and it's high-saturation then it can even be actively painful to look at, as the colors start vibrating against each other in your visual cortex. Sometimes I do that deliberately; all rules of art are really guidelines, and any rule that says "never do this" actually means "don't do this without knowing damn well that you are going into difficult territory, and if you have a solid reason to do it anyway, make sure you're doing everything else extra well to make up for this".

Good luck making this work despite having next to no value contrast.

I feel like you have kind of missed the point here.

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”.

Yeah, this is why I find using the HSL color representations[1] and adjusting the lightness values to be more pleasing when creating stepping tones

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

Having little contrast in lightness is mentioned multiple times on that page as being an explicit design goal.

Yes. It is.

Like I said: good luck making this work, because you sure are breaking a pretty important rule of choosing colors.

Not saying you're right or wrong - personally I like the palette but not the theme - but these comments give off a pretty arrogant attitude that I think is uncalled for.

It's not at all arrogant in my reading, more like lightly exasperated? They understand exactly what the color scheme is trying to do, they gave reasons why it is naive, and they basically said, "go with God".

I've been a professional artist for twenty years. My preferred method of working is to place colors directly against each other without the safety net of hard, high-contrast outlines to save me from the muddy pit of samey values. I have to be aware of this problem pretty much every day of my working life.

I am curious how you think I could have said "dude you are making this so fucking hard on yourself by choosing to have next to no value contrast, here are some ways I regularly have to check that I'm not doing this by mistake, good luck figuring out how to get everything else so amazingly perfect that it overcomes this giant deliberate flaw" without sounding "arrogant".

As mentioned in my original post, the theme for sure needs significant work and could be improved a lot. I know my way around colour science and typography, but not around UI design at all and I’m still a novice programmer.

I’m glad I achieved my main goal though.

Good luck making it work! :)

You're making personal attacks because an artist came along, said "here's why this doesn't work," and when you didn't listen and tried to lecture them about the Readme, they weren't moved, because despite the original author's goals, it still doesn't work

The artist isn't being arrogant. You ignored what they said and talked down to them, and they stood their ground. Now you're acting like they're doing something wrong, and publicly criticizing them.

No, it's not arrogance. It's just that you are arguing without understanding.

This looks great, and I've just installed it.

However, please increase the contrast of comments! They are borderline illegible, when they're generally more important than the code itself.

Edit: I tweaked my config to make comments green - as someone who writes a lot of Python, this makes sense to me, since python multi-line strings are also used as comments.

I just oriented myself on some other themes I found where comments were using a de-emphasised foreground colour. You could switch to one of the more high contrast versions but I can totally see how it would potentially make sense to use the same luminance level as the code. For the theme, I’m totally open to changing things around based on feedback like this.

This is actually my beef with almost all cool looking syntax color themes for sublime, they make comments fade into the background. And imho it should be the opposite, comments should jump out at you.

https://www.benkuhn.net/syntax/ https://jameshfisher.com/2014/05/11/your-syntax-highlighter-...

100% ACK.

> I've just installed it

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

I put colours from Penumbra in palettes for easier comparison: https://codepen.io/rguiscard/full/OJvZLpd

Thank you, I might incorporate that into the README at some point!

When comparing them side by side, bluish purple is too similar to cyan.

The perceptual distance is the same between all colours according to the most recently available scientific data (with a relatively small margin of error for technical reasons).

There could be issues with your display calibration (most likely), things like f.lux/night shift and so on that cause these to deviate from the calculated ideal values.

The images shown at the top are (probably) designed to show off the full "dynamic range" of the color palette, but reading those code snippets is a bit overwhelming (and I suspect it's just because you've crammed so many things into a very small space). I think it might be easier to get a visual "grok" of the color scheme with a longer snippet that is more representative of real code.

Yep, that’s exactly how those came to be — as many colours in as short a snippet as possible.

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!

Those sorts of snippets, dark on left, light on right, with each row in different languages. Maybe 5 or 6 rows at least. That's what people want to see, at least.

I think the idea of using perceptually uniform luminance in the different colors makes a lot of sense. Most light color schemes suffer from too much variance in luminance I think and your light color scheme looks balanced.

Uniform luminance was one of my own main goals when I updated the original Monokai palette to https://monokai.pro. I first experimented with mathematical values based on CIElab, and dove into obscure color lighting models to see if I could come up with some clever mathematics to prove my color scheme in a scientific way. But somehow these algorithmic colors never looked nice and "fun" for lack of a better word.

In the end I adjusted every color manually. So, Monokai Pro is not perfect science, but for me it somehow works.

That’s the great thing about OKLab, it makes this kind of design much easier and more accessible without having to resort to color appearance models like CIECAM16 or even just CIECAM UCS.

Beyond luminance, I’m also adjusting for uniform chroma as otherwise the colours still stand out to different degrees from the background, so that might have been one of the issues you ran into.

Your color scheme was actually one of the ones I looked into before making my own because it at least came close to what I was looking for — and while it was close, the perfectionist in me wanted to make it mathematically optimal once I’ve started to think about it in these terms.

Looks nice. Fancy justification too.

Are you claiming it's a significant improvement over Solarised? Either way, good stuff.

Thank you!

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.

At first, your color palette made a very good first impression to me.

> I’m claiming it is an improvement in terms of usability, simply because Solarised wasn’t designed with these properties in mind.

Are you sure about that? On [1] and [2] the creator of Solarized describes why he choose low contrast and specific hue differences, representable in CIELAB. That sounds rather similar to your first three points in [3].

Even if the approaches have some similarities, it does doesn't denigrate your work. Thanks for continuing this line of work. And I am looking forward to test Penumbra in comparison to Solarized.

[1]: https://ethanschoonover.com/solarized/#features

[2]: https://ethanschoonover.com/solarized/

[3]: https://github.com/nealmckee/penumbra#Features

The reasoning on the first two points is the same, yes, simply because I agree with Ethan’s. The two big differences are: I’m aiming for perceptually uniform colour differences instead of the same luminance and my background colours are directly sampled from daylight.

For the colours, this means uniform chroma and hues that aren’t hand-picked but optimised (on top of that using a more hue-accurate colour space).

I’d argue there’s enough of a difference, especially in the visual result, to make this more than an iteration, but even if it was simple iterative, there’s nothing bad about that and it can still be valuable work without being plagiarism .

It is like solarized in the sense the colors have same luminance and are analogous. But it uses OKLab instead of CIELab.

> The search for a theme led me to Solarized by Ethan Schoonover, which I was ultimately not satisfied with but inspired me to try and improve on its ideas.

https://github.com/nealmckee/penumbra#acknowledgments

Which reminds me, of https://github.com/jan-warchol/selenized/blob/master/whats-w... Selenized is another theme which aims to improve on Solarized.

https://github.com/jan-warchol/selenized/blob/master/feature...

https://github.com/jan-warchol/selenized/blob/master/balanci...

Wonder how they compare.

Many differences to my attempt: Luminance is kept different between colours according to some subjective “individuality”, I touched on why I decided against this in another comment. This has rippling effects as instead of being able to just make chroma uniform, one now needs to subjectively adjust both in tandem to get the same apparent brightness, which will never be as precise as doing it mathematically (which would require a full colour appearance model like CIECAM16). But then, luminance and chroma are still different across colours, so this still appear somewhat uneven. Compare the colour swatches here https://codepen.io/rguiscard/full/OJvZLpd to those of Selenized and you should see the difference. Same things goes for the choice of hues, they’re further apart on what appears to be an HSL-based colour wheel, but by no means optimally spaced (at least there’s no mention of it). Plus for all of this they used CIELab which simply isn’t as perceptually uniform as it claims to be, especially with respect to hue, so optimal spacing wouldn’t have even been possible.

It definitely improves on some of the same issues I had with Solarized, but in a non-rigorous way, with more of a “good enough” approach.

To my eye, you've done an outstanding job.

I agree. For me, the DarkContrast++ looked best to me. Clear, crisp and easily readable after a long, sleep deprived day. I'll definitely be giving this a shot in the morning.

As I was designing UI for a recent project a realized that color is a subtle but powerful tool in providing a sense of depth and layering for human eyes. It's arguably even more important in today's trends of flat designs which has much less shadows, gloss, bevel and other 3d effects that were common 10-15 years ago.

In a nutshell, warmer colors for foreground content and cooler for background goes a long way in adding depth. Even when working with the same base hue. The fundamental reason this works is precisely sky/sun interaction, which is fascinating.

I used chroma.js with oklab as color space (importantly: it's perceptual). Working with HSV or RGB directly is very difficult in comparison.

In this case, I was trying to keep the actual code as “flat” as possible, while offering exactly that pleasing sense of depth for the UI. For the latter, it could probably be better utilised in the VSCode extension but I hope at least the colours offer a good basis to work off of.

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.

> Imho OKLab should be the defacto standard for designing with colour

Agreed. It's a little challenging to make color picking UIs and programmatic interfaces I guess. Before seeing oklab in action, I never knew just how distorted a typical HSV picker is, it doesn't map to our vision at all.

I can only use my own color palette, because it is designed to separate features by hue.

In my case, comments are gray, constants are yellow, strings are purple, markup like HTML is green, some parts inside the markup are blue, and the hot colors are for code, red-orange for keywords, orange-salmon for variable names, etc.

No matter the language, I can rely on my theme to identify sections of the code, and it feels safe and familiar.

All the other color palettes seem, to me, a random assortment of colors that completely ignore function, and that makes them unusable, no matter how pretty they may appear.

I don't think anyone else uses my color palette, besides me =)

It can be seen and downloaded from here: https://colorsublime.github.io/themes/Poyeyo/

I found the colours here to be a little bit muted - since you're using Oklab [0], it would be quite nice to make the saturation level user defined.

I was messing around with something similar (before I found out about Oklab), that generated a nice pastel colour ring.

(I didn't (at the time) know how to get the colours to a fixed perceptual saturation level, so gave up intending to come back to it.)

    //something like this
    static final int MAX = 255;
    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(MAX * sin(theta + OFFSET_R));
        final int g = round(MAX * sin(theta + OFFSET_G));
        final int b = round(MAX * sin(theta + OFFSET_B));
        
        return 0xFF000000 | (r << 0x10) | (g << 0x08) | b;
    }

(If I were doing it now, I'd use Oklab for normalisation.)

[0] - https://bottosson.github.io/posts/oklab/

The saturation (or to be more accurate in this case, chroma) is actually already as high as possible (unless I’ve made a fundamental mistake) given the constraint that we want it to be uniform across colours and also uniform luminance. sRGB simply doesn’t allow for more sadly and I’m afraid it will probably be a long time before a new standard colour space for consumer displays comes around that would improve this.

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.

    //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;
    }

It looks great on the screenshots, but pretty dull and low contrast in VSCode, something is definitely not right. I believe it is due to rgb subpixel aliasing, which shifts the colors on smaller sized fonts.

https://i.ibb.co/1GkpLw7/2022-08-05-T04-00-27-UTC.png

I’m on a Mac with a Retina display so that’s probably why I haven’t noticed this issue. I don’t know of any way to account for this off hand though, even if I had noticed it.

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

If anyone is keen on making some vim colorschemes based off of this, you might like romainl's colorscheme template:

https://github.com/romainl/vim-rnb

> RNB is a template designed to help vimmers create their own colorschemes without much effort.

I’m not a vim user but I’ll make a note of this in case I get around to implementing it myself. Realistically I would definitely need to work off of a template like this.

Thanks!

I gave it a try, and in plain text files, it seems way too low contrast: [screenshot](https://i.postimg.cc/65Xcx9Cv/Screenshot-20220804-161004.png).

Good catch, that is an issue with the VSCode extension, apparently it’s using the colour for comments (which is purposefully low contrast) for plain text when it should be using the main foreground colour. I’ll try to look into that!

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)

Just tried it on VSCode. The Penumbra light doesn't map very well in a few places. If you open the "Editor Playground" page, some of the code samples have some pretty unreadable sections, because the background grey is too close to the foreground colours.

Nice idea, but I'm afraid that for coding I'm going to be sticking with Solarized light for the moment.

Feel free to make either an issue or even a pull request, I’m very much looking for feedback on the implementation!

Do you have the same issues with the Dark Contrast++ version?

FWIW comments are quite an important part of reading code, it should not be hidden, at least when comments are used for documentation purposes. It shouldn't be as prominent as the main code, but should be pretty close to it. Very few color themes get this right.

I’m not sure if I’m already using the closest colour in terms of luminance or not, I’d have to check.

If not, I’m very open to pull requests on the theme, including fundamental reworks. Otherwise there might be an argument whether one would want to make the closest de-emphasised colour less so, but that would require more fundamental changes to the palette (which I’m also open to for the background colours!). I think for this part I looked at what others were doing so I might have gotten it wrong from them.

That makes sense; I thought it kinda looks like comment. Pretty pleasant colors, otherwise. Good work!

Thank you, I’m glad you enjoy them!

I like that this uses OKLab instead of hsv/HSL that some colormaps use (which are not based on color theory).

It would be nice if this used the upcoming WCAG3 contrast algorithm https://www.myndex.com/APCA/ and ensured it's minimum contrast meets the recommended values there for body text, etc.

There is a tool that can assist in designing color maps taking APCA into account https://huetone.ardov.me/

For perceptually uniform colormaps see also https://colorcet.com/

I was not aware of the new algorithm, thanks for bringing that up!

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).

You can use OKLch and APCA with that huetone website. See the gear icon in top right.

I don't think your efforts are obsolete though, the 2 approaches could be combined IIUC your approach is based on computing values based on color science, and the tool/website is a more visual approach, it won't design the colorscheme for you, but you can use it to validate the colorscheme, or tweak it after the fact.

Oh awesome! I didn’t have time to look that deep into it, sorry for missing that part.

Switching to OKLab actually reveals how narrow the bands of available colours can be in the different dimensions and how difficult it would probably be to hand-pick the colours that I’ve chosen. I agree now that they’re probably more complementary.

It would be awesome if the tool allowed you to set constraints like the ones I used.

Not my project, but the source code seems to be here https://github.com/ardov/huetone

If it seems useful to you try reaching out to them on a GitHub issue and see whether they'd be willing to implement the missing features or collaborate with you in another way.

Already on my rapidly growing to do list!

I am having trouble seeing a visible difference between half of the colors in the data visualization images. As far as I know, I don’t have any color vision issues. The green, cyan, and magenta colors all look basically the same. Am I alone here?

You're talking about the "eight, seven, six" variations under each named color, right? Like it's hard to tell the 3 cyans apart from each other? If so, they look the same to me too.

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

You're not supposed to see differences between the different palettes. They're not to be used concurrently.

Very nice work. But:

> The recommended font is Fira Code.

is probably a bit orthogonal to the color scheme... :)

That’s true, it’s just what I prefer and was testing with but the line could probably be omitted.

I liked it, but I do prefer VS Code’s default+ colour themes (for light or dark).

For the terminal I use the “USWDS: The United States Web Design System” colours, which I find have a great luminance balance and a huge palette, I use the middle 50 vivid variants. See: https://designsystem.digital.gov/design-tokens/color/system-...

Wow you’re getting a fair bit of criticism for this. Maybe it’s warranted. I don’t know, I’m not a color theorist. But I do think that the colors you’ve chosen are pleasing to my eye and the text samples were very comfortable to read. Even if you are the only person to use this palette and enjoy it then I think what you’ve created is worth it. Thanks for sharing your work!

I think most of the criticism is fair and to be expected, especially as the design goals are very “opinionated” in a sense and on the other hand, everyone will have a subjective opinion on a colour palette themselves.

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.

The light color background is strikingly similar to the color of the paper used to print the Financial Times (FT) newspaper. I'd always thought of the color as an easy way differentiate the paper amongst others in a stack, as well as a potential way of signalling to other people that you read the FT. I had never considered the readability aspect before.

Hey, this is cool. I hacked together an R package to use this as a palette: https://github.com/hughjonesd/penumbra

Awesome, thank you! I’ll give you some comments in the issue you posted.

I don't know if it's placebo effect (i.e. I'm believing this is better), but I always struggle with dark mode colours and this felt very easy and natural on VSCode (using Dark+).

I’m glad you enjoy it!

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.

This is timely. I’m creating a webapp and I’m simply unable to create a good looking Color combination. Going to give this a try. I like the fact that each Color has an associated meaning.

If you care about accessibility and these colours have any sort of function or meaning within the app, I’m afraid I would advise against using these colours as they were created for a quite specific use-case — colouring tokens within “fluid” text.

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.

Thanks, that's very kind of you.

I'm using an open source calendar component to visualize my agenda. I have various types of events I'm showing (scheduled work items, events and completed items). I'm having a difficult time deciding on a color scheme.

Upcoming events should be emphasized. Completed work items are useful information ("I finished this") but they should be least noticeable.

I'll play around with both your color scheme and the references you provided just to see if something sticks.

What are the recent advances in color science which led you here? I will say that your color palettes look like they are out of a structural color publication.

Not the author, but I guess that's mainly referencing Oklab (and everything that lead to its creation).

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

Correct, OKlab is nothing fundamentally new in terms of the underlying science as it’s based mainly on CIECAM16, but it makes working with perceptual distances of colours a lot more user friendly.

I think that pallettes with perceptually uniform brightness don't really make sense as generative models. Different colors have different apparent brightness and we're used to it. There's a kindergarten near me with different sections of the fence painted in different "basic" colors, it doesn't look jarring at all with yellow and cyan being brighter than red.

Such colors spaces are great for color difference measurement, though.

That’s the point though, these colours are great because they have (almost) uniform perceptual differences and that is what I was aiming for.

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.

This looks great, OP! I've starrred the GitHub repo!

Any idea when a Vim and Airline colorscheme will be available?

There’s no set timeline for further implementations. I’ll try to create the most requested ones whenever I can in my free time, but I’m also open for others to contribute!

This is gonna sound a bit absurd for HN, but you need to tl;dr that README. Or at the very least give a link/jump first to the core files needed to try it out.

I guess there’s an argument to be made to put the “available for” section closer to the top, but the main repository I linked is meant more as a design template that needs all this explanation, the VSCode extension for example is a lot more succinct.

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

I don't like it and it makes no sense at all,

because screens not just not emit natural light,

they emit far too much blue light, too,

which means that everyone should be using some sort of filter (like windows' night-light),

or blue-filtering glasses,

causing the colours to be off.

Perceptual optimization makes no sense, when you optimize for something that's harmfull to the eyes.

Yes, the blue light content is higher as screens use RGB instead of the full spectrum of light, but for this purpose I care about colour perception and as long as the stimulus in the cones is the same (which it should be if your display is properly calibrated, most are actually quite decent at this point straight out of the factory), this does not make a difference.

Limiting the blue part of RGB makes the available colour space so small, that the design goals of this palette will be impossible to achieve.

As far as I know, the most recent science says that blue light levels from displays are actually pretty much negligible in terms of overall health, but don’t quote me on that. For wakefulness, ideally you should probably not be working that late at night anyways and there’s f.lux and night shift for that if you must. These inherently make legibility of any colour worse though, including this palette.

> displays are actually pretty much negligible in terms of overall health, but don’t quote me on that.

Yeah, forget that. It's unreasonable to assume "negligible" is in any way or form acceptable when it comes to vision. It fucking isn't.

Here's something fun! You can actually subjectively measure how bad it is. All it takes is or white background, in full screen, full brightness, in a dark room. It creates a burning-like sensation in the eyes. Then stop, wait a few minutes until it fades and repeat the process with the filter on.

You'll actually notice a difference.

You’re aware that turning on a blue filter at the same brightness level will obviously decrease the overall emittance of the display? Most displays are already way too bright for ideal viewing conditions at maximum brightness, let alone in a completely dark room. Of course it will blind you at that setting and of course mostly turning off a third of the sub-pixels will reduce the issue. That’s why one should trust science over anecdotal evidence because a good scientist would control for brightness...

This looks like an almost carbon copy of the research done for Solarized.

"Great"

I acknowledge at the bottom that Solarised was one of the inspirations for this and some similar design principles apply in terms of the background colours, but really the motivation was a lot more specific and the construction fundamentally different. I really don’t see where you are getting “carbon copy”.

They're really quite different

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

Reply on news.ycombinator.com