generate 256 palette

[jake-stewart]

#9408

• The 256 palette is hardly used because the default colors do not match base16 themes.
• Yet, the 256 palette has advantages over truecolor:
  • Simple & easy (Programs do not need configuration files)
  • Performant
  • Consistent (All programs that use them are synchronized)
  • Automatic light/dark/theme switching without program effort.

I believe it would benefit the terminal ecosystem greatly if 256 palettes were generated automatically based on user configured base16 themes since consistency by default would convince more developers to use these colors and gain greater flexibility in their color usage without having to increase the complexity of their programs.

To achieve this, I have added an option generate_256_palette which is true unless manually disabled or when one of the 16-255 colors are set. This flag also helps avoid having to check the 256 palette against defaults to determine whether generation is required.

I consider it important for themes to share similar contrast ratios between their darkest shades and backgrounds. This ensures themes are interchangeable and prevents users from needing to adjust which shades they use per theme. The logic for this is fast and involves zero looping.

[kovidgoyal]

I am somewhat confused as to how this is supposed to work. The default options have all 256 colors defined. So generate_256_colors will always default to False. patch_colors() is used when dynamically changing colors at runtime only, not for initial creation of the color table. Maybe I am missing something, but in any case this is academic as I think we should use a different approach, see below.

Seems to me the better way to do this is to have the default values for the 256 color table > 15 be None using to_color_or_none. And to fill in the values for all None colors based on the first 16 colors, when transferring those color to the C color_table in colors.c. This will require porting your color generation code to C but that should not be too hard since its simple math, and will be good for performance. There are likely to be some subtleties in the implementation here. You will need to possibly use -1 for None colors in color_table as generated in options/types.py and handle None values in getattr/setattr there as well.

It might also make sense to have the algorithm generating the 256 colors to take into account some "sentinel" colors if they are not None, beyond the first 16 colors, allowing the user to further fine tune, for instance how red the red are and so on.

Finally I'd like to see the changes in the default 256 color table comparing the current default values to the generated ones. Changing the default color table is a fairly big deal so, I would like an idea of how disruptive it will be.

[jake-stewart]

The default options have all 256 colors defined.

It was a hook in the parser which disabled the option when you set color16-255. But I agree your solution sounds a lot better.

It might also make sense to have the algorithm generating the 256 colors to take into account some "sentinel" colors if they are not None, beyond the first 16 colors, allowing the user to further fine tune, for instance how red the red are and so on.

This might be possible but I have not thought about it much. I will think about it after we figure out the last more important point.

Finally I'd like to see the changes in the default 256 color table comparing the current default values to the generated ones. Changing the default color table is a fairly big deal so, I would like an idea of how disruptive it will be.

Below is a screenshot comparing the theme generated from the default base 16 colors (left) against the full default 256 palette (right). The examples also include Neovim showing a diff to demonstrate the usefulness of the new palette colours, since this involves shades of grey, red, and green:

The generated theme is darker.

• The default palette interpolates between #000000, #ffffff and fully saturated colors like #00ff00 instead of the base16 colors #000000, #dddddd and #19cb00.

• Additionally, the algorithm reduces the contrast between darker shades and the background. This is to make text readable on top of dark shades and to keep the apparent contrast/brightness the same across different hues of the same shade, so that they can be used together without looking off. Sometimes the algorithm increases contrast, too. Often for dark shades of reds like in solarized and gruvbox.

So, the new palette would be different. Arguably an improvement considering the dark color shades would be usable as backgrounds without hurting readability. I implied but failed to mention that I plan to offer this palette generation to other terminals, so ideally kitty would not be different, just the first.

If you are happy with this then I can carry on with the improvements.

---

For fun I have included a screenshot of popular themes so you can see what regular users would experience:

[jake-stewart]

Comparing foregrounds:

[kovidgoyal]

Hmm, that is quite a large difference. That said, I do like your idea in principle. Perhaps, if we go ahead, we should add a "kitty classic" or similarly named theme to kitty-themes so people can revert to the old color table with a single command. It might also make sense to adjust the 16 colors in the default theme a little to reduce the amount of change while preserving the readability benefits.

Finally, if you want this approach to be adopted more widely the algorithm, rationale, etc should be documented/specified in a rst file in docs and linked to from the kitty.conf docs.

Bottom line: I am OK in principle with doing this. The devil is in the details which will need to be discussed ironed out as this PR matures.

[jake-stewart]

Finally, if you want this approach to be adopted more widely the algorithm, rationale, etc should be documented/specified in a rst file in docs and linked to from the kitty.conf docs.

I have been working on this the last few days. I think it is ok:

https://github.com/jake-stewart/color256/blob/main/writeup/readme.md

[kovidgoyal]

Looks ok to me.

[jake-stewart]

I think it is looking good.

• Theme generation happens in C.
• Color table stores ints with 0xffffffff representing a null color.
• The getattr/setattr translates between the color and None automatically.
• generate_256_palette false in config will make kitty have the old palette.
• Only null colors are replaced by the default/generated colors.
• Documentation written and linked to the overview.

I was unable to test the docs locally since sphinx is crashing for me.

[kovidgoyal]

OK will take a look when I have some time. Am rather swamped at the
moment.

[leiserfg]

My grain of sand, shouldn't this use OkLab instead of Lab?

[edwardgalligan]

@leiserfg https://gist.github.com/jake-stewart/0a8ea46159a7da2c808e5be2177e1783?permalink_comment_id=5992155#gistcomment-5992155

[jake-stewart]

@leiserfg @edwardgalligan OKLAB was not a perfect drop-in replacement for CIELAB.

CIELAB is widely recognized of having accurate lightness values.

OKLAB had inconsistent lightness across different themes that even toe lightness correction and gamut clipping failed to properly fix (approaches laid out by the colorspace's creator).

For this use case, consistent lightness is far more important than the advantages OKLAB offers. Since consistent shades across different themes share the same meaning.

You can view the discussion, approaches, findings here:

ghostty-org/ghostty#10818

This PR remains correct with CIELAB.

[jake-stewart]

This PR is not ready:

There is active discussion at the Ghostty repo about approaching this slightly differently.

The idea is that light themes should not invert the palette so that ansi 16 remains black. This is with the intention of removing the breaking change of generating by default. Then, an opt-in option for "harmonious" colors which inverts the colors for light themes since there are advantages for doing so.

[kovidgoyal]

Looks like there is quite a lot of breakage involved in having this.
Sadly, there is no historical consistency or standard that defines if
colors in the 256 color table are supposed to be dark/light adjacent or
background adjacent. Different color themes do it
differently, which is part of the reason more and more apps are moving
to truecolor, there simply isnt consistency in the 256 color palette.

Possibly the way to go is to detect if the theme configured by the user
assumes colors are background related or dark/light related, by checking
the first 16 values. And then generate the color cube accordingly. But
that has the downside that application developers then cannot rely on the
semantics of the palette. So the whole exercise has no real benefit.

Maybe we should rethink this approach. What is the actual end goal?
To me it seems it is:

Make it possible for the user to specify a few colors in one place and
have most applications then respect those colors in their interfaces.

The problem is 8/16 colors arent enough so we would like to extend that
goal to 256 colors.

The current approach is to try and force this for all applications by
generating the palette and expecting applications to use the palette.
This has the problem of breaking existing setups whose dark/light vs
background adjacency assumptions are different than the one chosen by
the generated palette.

Maybe a better approach is to advertise the colors explicitly
set by the user to terminal applications and then terminal applications
can use those colors to make their own palette choices. This would
obviously only work for applications that were modified to support this
mechanism and that are in a position to query the terminal in the first
place.

I don't personally have strong feelings about this since I don't use the
256 palette in any of my terminal applications, since I long ago decided
they were too inconsistent.

I do however hate to break existing setups for kitty users. Thus almost
all my innovations generally add new things rather than changing
existing things. That said I have done this kind of thing in the past
most prominently banning bold-as-bright in kitty (and I still get
complaints about it, almost a decade later).

I am fairly sure a significant number of users use apps like vim with
256 color palettes and some large fraction of them will be negatively
affected by this change.

[leiserfg]

Maybe it makes sense to have the autogeneration to be opt-in? So, if something looks off, users know why.

[jake-stewart]

Possibly the way to go is to detect if the theme configured by the user
assumes colors are background related or dark/light related, by checking
the first 16 values. And then generate the color cube accordingly.

The new approach is to detect light/dark theme based on the user's fg and bg. Then, generate the palette so that 16=black and 231=white. Light themes would remain inconsistent but significant breaking changes would be avoided.

A new opt-in configuration option to enable "harmonious" colours would allow light themes to be inverted so that they are semantically correct.

application developers then cannot rely on the semantics of the palette

The plan is that terminal programs will be able to query for FG, BG, color16 and color231. If BG=color16 and FG=color231 then the palette is harmonious and can be used semantically. Otherwise, detect light theme (BG lighter than FG) and invert the indexes if so.

This is for terminal program maintainers who care. I am sure most users would just enable harmonious colors and use the palette as intended.

[kovidgoyal]

On Thu, Feb 19, 2026 at 11:07:57PM -0800, jake-stewart wrote: jake-stewart left a comment (kovidgoyal/kitty#9426) > Possibly the way to go is to detect if the theme configured by the user assumes colors are background related or dark/light related, by checking the first 16 values. And then generate the color cube accordingly. The new approach is to detect light/dark theme based on the user's fg and bg. Then, generate the palette so that 16=black and 231=white. Light themes will be as inconsistent as they were before but without significant breaking changes.

That is definitely less disruptive, but I can guarantee I will see at least a few issues about background colors changing shade. Just see all the recent issues from hyprland breaking color management and hence changing colors in kitty by a few percent in a recent update. That said, it might still be worth the noise.

A new opt-in configuration option to enable "harmonious" colours would allow light themes to be inverted so that they are semantically correct. > application developers then cannot rely on the semantics of the palette The plan is that terminal programs will be able to query for FG, BG, color16 and color231. If FG=color16 and BG=color231 then the palette is harmonious and can be used semantically. Otherwise, detect light theme (FG darker than BG) and invert the indexes if so. This is for terminal program maintainers who care. I am sure most users would just enable harmonious colors and use the palette as intended.

Terminal program developers have been able to query the color palette for years now: https://sw.kovidgoyal.net/kitty/color-stack/#setting-and-querying-colors No one cared :)

[tmccombs]

Make it possible for the user to specify a few colors in one place and
have most applications then respect those colors in their interfaces.

The problem is 8/16 colors arent enough so we would like to extend that
goal to 256 colors.

I think another big problem is that the labels for those 8/16 colors are just names of colors. There isn't any semantic meaning to them, or standard on how those colors should be used. Depending on the color scheme "blue" might have high contrast with the foreground or the background. Even if you can query the true color value of all the colors, using that to figure out the amount of contrast between them all and decide the right way to use them would be pretty complicated.

I wonder if maybe a better solution would be for there to be some standard file format for a color scheme that could be re-used across terminal applications. And perhaps have a way for an application to query the terminal for that data so it could be accessed across a remote connection?

[jake-stewart]

This PR is tested and ready.

It adds two configuration options that are both opt-in:

• palette_generate Whether to generate the extended 256-color palette based on the user's base16 theme.
• palette_harmonious Whether to invert generated light themes for more semantic colors.

The config and behaviour is consistent with other PRs/emulators.

---

The default 256-color palette interpolates from black to white. This means it works better for dark themes since the dark shades are closer to the background and light shades are closer to the foreground. For light themes, the opposite is true, and so a UI designed for dark themes using the default 256-color palette looks bad with light themes.

That is the purpose of the palette_harmonious option: It inverts light themes so light/dark palettes are semantically equivalent. It makes shades interpolate from BG to FG instead of from black to white.

The palette_harmonious is opt-in to be consistent with Ghostty. You could delete this option and only ever generate harmonious palettes. This would be fine since the palette generation is opt-in. However, you will be unable to make palette_generate default in the future without breaking changes.

[kovidgoyal]

OK will review when I have a moment.