- ユーザーの base16 テーマ から 256色パレット を自動生成することを提案する記事で、ターミナルの色の一貫性と可読性を改善する方法を示している
- 既存の base16 テーマ はシンプルだが色数が限られ、truecolor には設定の複雑さと互換性の問題がある
- 標準の256色パレットは 明度の不均衡、テーマ不一致、誤った補間 などにより視覚品質が低い
- LAB 色空間補間 を使って base16 の色から拡張パレットを生成すると、一貫した明度とコントラストを保ちながら豊かな色表現が可能になる
- 主要なターミナル（例: Ghostty, iTerm2, SwiftTerm）の複数ですでに実装が進んでおり、標準化された自動パレット生成機能 がターミナルエコシステム全体の品質向上につながる可能性がある
256色パレットの概要
- 256色パレットは 16個の基本色、216色キューブ、24段階のグレースケール で構成される
- 基本16色には黒、白、原色、およびその明るい変種が含まれる
- 216色キューブは RGB 各チャンネルに6段階（0〜5）を使って計算する:
16 + (36 * R) + (6 * G) + B
- グレースケールは白黒の間の24段階で構成される:
232 + S （S は 0〜23）
- この構造は 24ビット RGB の単純化版 で、色数を減らしつつ表現力を確保している
既存の256色パレットの問題点
- Base16 テーマとの不一致 により色の衝突が起きる
- 標準パレットは大半の base16 テーマと調和しない
- 誤った色補間 により暗い背景で可読性が低下する
- 標準パレットの最初の濃淡が実際より明るく計算され、コントラストが弱まる
- 不均一なコントラスト の問題
- 完全飽和の色を使うため明度バランスが崩れ、同じ段階でも青が緑より暗く見える
パレット生成方式
- 解決策は ユーザーの base16 カラーから256色パレットを自動生成 すること
- base16 の8つの基本色を216色キューブの8つの頂点にマッピングする
- 背景色と前景色を使って 三線形補間 (trilinear interpolation) でキューブを生成する
- LAB 色空間 を使って色同士の 視覚的な明度の一貫性 を維持する
- グレースケールは背景から前景への単純な補間で生成する
- Python のサンプルコードでは
rgb_to_lab, lab_to_rgb, lerp_lab 関数を使って変換を行う
実装と適用状況
- 提案されたコードは パブリックドメイン として公開されており、自由に修正・活用できる
- Ghostty、iTerm2、SwiftTerm など主要なターミナルではすでに実装済み
- kitty、Wezterm、Tabby、Windows Terminal などでも適用要望または開発が進行中
- 一部の開発者は OKLAB/OKLCH 色空間 の使用を提案しており、プロジェクトは Ghostty の決定に合わせて標準色空間を統一 する予定
- Python スクリプトを通じて直接パレットを適用したり、ターミナル設定ファイルを自動生成したりできる
結論と提案
- 標準の256色パレットは 可読性の低下とテーマ不一致 のため、プログラム開発者から敬遠されている
- ターミナルが base16 テーマベースで256色パレットを自動生成 すれば、次のような利点がある
- 設定ファイルなしでも 広い色域 を使える
- ライト/ダークモード切り替え の際に開発者の介入が不要になる
- 幅広いターミナル互換性 を維持できる
- 提案者はこの機能が デフォルトで有効（opt-out） であるべきで、長期的には 標準機能として定着すべき だと強調している
1件のコメント
Hacker Newsの意見
256色パレットの良いところは、16〜255番の色が固定されていること
なので、たとえば146番が常に「淡い紫」だと確信できる
これは、さまざまなターミナルエミュレータで一貫した色体験を提供したいカラーテーマ開発者にとても有用
もし256色パレットが可変な16色パレットから生成されるなら、146番が期待した色ではないかもしれない
16〜255番の領域が0〜15番のように不安定になるのは間違った方向だと思う
視覚障害者や色覚異常の人、白い背景を好む人などにとって可読性が落ちる
結局、ユーザーはターミナルの基本色だけでなく各アプリの色設定まで別々に行わなければならない
ターミナルはきれいなUIではなく効率性のために使うもの。きれいさが欲しいならWebフロントを作ればいい
私たちは「一貫した体験」を求めているわけではない。色は節度を持って、ユーザー設定を尊重して使うべき
背景が紫かもしれないし、白地に紫文字かもしれない
つまり、アプリが自分のターミナルの色構成を知らないなら、その色は使うべきではない
私は基本のbase16テーマを使っていて、第三者が作ったテーマと一致することは期待していない
ターミナル単位とアプリ単位の色へのアプローチの違いは、哲学的な問題に近いと思う
私はStreamdownというストリーミングMarkdownレンダラーを作った
HSVベースで基準色を1つだけ決めれば、残りはその色の倍数として自動調整される
たとえば暗い要素は彩度を下げ、シンボルはより鮮やかにするといった具合
設定でHSVを少し変えるだけで全体のトーンが自然に変わるので、色を一つひとつ調整する必要がない
サンプルコードもある
16色の基本パレットだけでも問題がある
「black」「white」「bright black」「bright white」は実際には明暗コントラストを意味すべきなのに、名前が色になっている
私はこれを「背景にほとんど溶け込む色」「コントラストの大きい色」「見えるが弱い色」「最もコントラストが強い色」として理解している
色名ではなくコントラスト中心で定義されていてほしい
ターミナルの前景・背景色は16色標準とは独立しているので、さらに複雑になる
背景が分からないときは黒・白を避けるべき。256色を使うならユーザー設定可能なテーマエンジンを使うべき
この機能はすべてのターミナルに追加されるべきだと思う
24ビットカラーに拡張できればなおよい。ただしオプションとして提供されるべき
たとえばSolarizedテーマをターミナルとエディタの両方で使うと、色変換が二重に適用されることがある
アプリが直接設定を上書きせず、環境変数で制御できるようにすれば、より柔軟になるはず
私はtinted-theming/base24を見つけて使っている
tinted shellを使ってカラーテーマを簡単に切り替えられる。かなり良い暫定的な解決策だった
cargo/rustcでも色不足の問題がある
既定の意味色だけを使うと、残るのはマゼンタ、黒、白くらいだが、これはテーマによっては危険
単に24ビットtrue colorモードを使えば、パレットは不要
termstandard/colorsによれば、ほとんどの現代的なターミナルがこれをサポートしている
さらには物理的限界（ハイゼンベルクの不確定性原理、量子ノイズなど）を考えると、6000ビット/ピクセル級のデータが必要になる
こうした想像はカルダシェフ尺度や古代の宇宙時間概念のように、技術進歩の方向を示す興味深い思考実験だ
すべてのユーザーが基本色設定をきちんとしているわけではない
あるターミナルは全体的に緑がかっていたり、オレンジがかっていたりするかもしれない
基本色の彩度をパレット全体に適用する方式のほうが、まだましかもしれない
私は色覚異常なので、カラーテーマにはかなり苦労してきた
そのためAIモデルを使って可読性の高い色の組み合わせを自動生成している
もともと好きだったテーマをベースにコントラストを高めてくれるので、ずっと見やすくなった
このアプローチは他の人にも役立つかもしれない
アプリごとに色の使い方が異なるので、あるテーマは一部のCLIでは見やすくても他では薄すぎる
結局、アプリごとにカラーテーマを個別に調整しなければならない不便さがある
私は**protanomaly（赤色弱）**なので、ametamericを使っている
この機能と一緒に使えば、さらに良い結果が得られそうだ