- Article proposant de générer automatiquement une palette de 256 couleurs à partir du thème base16 de l’utilisateur, afin d’améliorer la cohérence des couleurs et la lisibilité dans le terminal
- Les thèmes base16 existants sont simples, mais limités en nombre de couleurs, tandis que le truecolor pose des problèmes de complexité de configuration et de compatibilité
- La palette 256 couleurs par défaut offre une faible qualité visuelle en raison d’un déséquilibre de luminosité, d’un décalage avec le thème et d’une interpolation incorrecte
- En générant une palette étendue à partir des couleurs base16 via une interpolation dans l’espace colorimétrique LAB, on peut obtenir une expression plus riche des couleurs tout en conservant une luminosité et un contraste cohérents
- Plusieurs terminaux majeurs, comme Ghostty, iTerm2 et SwiftTerm, l’ont déjà implémenté, et une fonction standardisée de génération automatique de palette pourrait améliorer la qualité de l’ensemble de l’écosystème des terminaux
Vue d’ensemble de la palette 256 couleurs
- La palette 256 couleurs se compose de 16 couleurs de base, d’un cube de 216 couleurs et d’une échelle de gris sur 24 niveaux
- Les 16 couleurs de base incluent le noir, le blanc, les couleurs primaires et leurs variantes claires
- Le cube de 216 couleurs est calculé en utilisant 6 niveaux (0 à 5) pour chaque canal RGB :
16 + (36 * R) + (6 * G) + B
- L’échelle de gris comprend 24 niveaux entre le noir et le blanc :
232 + S (où S vaut 0 à 23)
- Cette structure est une version simplifiée du RGB 24 bits, qui réduit le nombre de couleurs tout en conservant une bonne capacité d’expression
Problèmes de la palette 256 couleurs actuelle
- Des conflits de couleurs apparaissent à cause du décalage avec les thèmes Base16
- La palette par défaut s’accorde mal avec la plupart des thèmes base16
- Une interpolation incorrecte des couleurs réduit la lisibilité sur fond sombre
- La première nuance de la palette par défaut est calculée comme plus claire qu’elle ne devrait l’être, ce qui affaiblit le contraste
- Problèmes de contraste non uniforme
- L’usage de couleurs à saturation maximale déséquilibre la luminosité, et à niveau égal le bleu paraît plus sombre que le vert
Méthode de génération de la palette
- La solution consiste à générer automatiquement la palette 256 couleurs à partir des couleurs base16 de l’utilisateur
- Les 8 couleurs de base de base16 sont mappées aux 8 sommets du cube de 216 couleurs
- Le cube est généré par interpolation trilinéaire (trilinear interpolation) à partir des couleurs d’arrière-plan et de premier plan
- L’espace colorimétrique LAB est utilisé pour préserver une cohérence perceptuelle de la luminosité entre les couleurs
- L’échelle de gris est générée par une interpolation simple entre l’arrière-plan et le premier plan
- L’exemple de code Python utilise les fonctions
rgb_to_lab, lab_to_rgb et lerp_lab pour effectuer la conversion
État de l’implémentation et de l’adoption
- Le code proposé est publié dans le domaine public et peut être librement modifié et réutilisé
- Des terminaux majeurs comme Ghostty, iTerm2 et SwiftTerm l’ont déjà implémenté
- Des demandes d’intégration ou des développements sont en cours pour kitty, Wezterm, Tabby et Windows Terminal
- Certains développeurs ont proposé d’utiliser les espaces colorimétriques OKLAB/OKLCH, et le projet prévoit d’unifier l’espace standard en fonction de la décision de Ghostty
- Il est possible d’appliquer directement la palette via un script Python ou de générer automatiquement un fichier de configuration de terminal
Conclusion et proposition
- La palette 256 couleurs par défaut est évitée par les développeurs de programmes à cause de la baisse de lisibilité et du décalage avec les thèmes
- Si le terminal génère automatiquement une palette 256 couleurs à partir d’un thème base16, cela apporte les avantages suivants
- utilisation d’une large plage de couleurs sans fichier de configuration
- aucune intervention du développeur lors du passage entre mode clair et mode sombre
- maintien d’une large compatibilité entre terminaux
- L’auteur estime que cette fonctionnalité devrait être activée par défaut avec possibilité de désactivation (opt-out) et, à long terme, devenir une fonction standard
1 commentaires
Commentaires sur Hacker News
L’avantage de la palette 256 couleurs, c’est que les couleurs 16 à 255 sont fixes
On peut donc être sûr, par exemple, que la couleur 146 est toujours un « violet doux »
C’est très utile pour les créateurs de thèmes de couleurs qui veulent offrir une expérience colorimétrique cohérente sur différents émulateurs de terminal
Si la palette 256 couleurs était générée à partir d’une palette 16 couleurs variable, la couleur 146 pourrait ne pas être celle attendue
Je pense que rendre la plage 16 à 255 aussi instable que la plage 0 à 15 irait dans la mauvaise direction
Cela nuit à la lisibilité pour les personnes malvoyantes, daltoniennes, ou celles qui préfèrent un fond blanc
Au final, l’utilisateur doit configurer non seulement les couleurs par défaut du terminal, mais aussi celles de chaque application séparément
On utilise le terminal pour son efficacité, pas pour une jolie interface. Si on veut du joli, il suffit de faire un front web
Nous ne voulons pas d’une « expérience cohérente ». Les couleurs doivent être utilisées avec retenue, en respectant les préférences de l’utilisateur
Le fond peut lui-même être violet, ou bien on peut avoir du texte violet sur fond blanc
Autrement dit, si une application ne connaît pas la configuration colorimétrique de mon terminal, elle ne devrait pas utiliser cette couleur
J’utilise le thème base16 par défaut, et je ne m’attends pas à ce qu’il corresponde aux thèmes faits par des tiers
Je pense que la différence entre l’approche couleur au niveau du terminal et celle au niveau des applications relève presque d’une question philosophique
J’ai créé Streamdown, un moteur de rendu Markdown en streaming
Avec une approche basée sur HSV, il suffit de choisir une couleur de référence, et le reste s’ajuste automatiquement comme des multiples de cette couleur
Par exemple, les éléments sombres voient leur saturation réduite, tandis que les symboles deviennent plus vifs
En modifiant légèrement les valeurs HSV dans la configuration, toute la tonalité change naturellement, sans devoir retoucher chaque couleur à la main
Il y a aussi un exemple de code
Il y a déjà des problèmes rien qu’avec la palette 16 couleurs par défaut
« black », « white », « bright black » et « bright white » devraient en réalité représenter un contraste de luminosité, mais leurs noms sont exprimés comme des couleurs
Je les comprends plutôt comme « couleur presque invisible sur le fond », « couleur à fort contraste », « couleur visible mais discrète » et « couleur au contraste maximal »
J’aimerais qu’elles soient définies en fonction du contraste plutôt que par des noms de couleur
Les couleurs de premier plan et d’arrière-plan du terminal sont indépendantes du standard 16 couleurs, ce qui complique encore les choses
Et lorsqu’on ne connaît pas le fond, il faut éviter le noir et le blanc. Si on utilise 256 couleurs, il faut un moteur de thème configurable par l’utilisateur
Je pense que cette fonctionnalité devrait être ajoutée à tous les terminaux
Ce serait encore mieux avec une extension en couleur 24 bits. Mais cela devrait être proposé en option
Par exemple, si on utilise un thème Solarized à la fois dans le terminal et dans l’éditeur, la transformation des couleurs peut être appliquée deux fois
Ce serait plus souple si les applications ne remplaçaient pas directement les réglages et si tout pouvait être piloté via des variables d’environnement
J’ai découvert tinted-theming/base24 et je l’utilise actuellement
On peut changer de thème de couleurs facilement avec tinted shell. C’était une solution provisoire plutôt correcte
Il y a aussi un problème de manque de couleurs dans cargo/rustc
Si on n’utilise que les couleurs sémantiques par défaut, il ne reste que le magenta, le noir et le blanc, ce qui peut être risqué selon le thème
Il suffit d’utiliser le mode true color 24 bits et on n’a plus besoin de palette
D’après termstandard/colors, la plupart des terminaux modernes le prennent en charge
En prenant même en compte les limites physiques (principe d’incertitude de Heisenberg, bruit quantique, etc.), il faudrait des données de l’ordre de 6000 bits/pixel
Ce genre d’idée, comme l’échelle de Kardashev ou les anciennes conceptions du temps cosmique, constitue une expérience de pensée intéressante sur la direction du progrès technologique
Tous les utilisateurs n’ont pas forcément une configuration correcte des couleurs par défaut
Certains terminaux peuvent avoir une dominante entièrement verte ou orange
Appliquer la saturation des couleurs de base à l’ensemble de la palette peut être une solution un peu meilleure
Je suis daltonien et les thèmes de couleurs m’ont souvent posé problème
J’utilise donc un modèle d’IA pour générer automatiquement des combinaisons de couleurs très lisibles
En augmentant le contraste à partir d’un thème que j’aimais déjà, c’est devenu bien plus confortable à lire
Je pense que cette approche pourrait aussi être utile à d’autres personnes
Chaque application utilise les couleurs différemment, donc un thème peut être lisible dans certains CLI mais trop terne ailleurs
Au final, c’est pénible de devoir ajuster séparément le thème de couleurs pour chaque application
J’ai une protanomalie (déficience rouge), donc j’utilise ametameric
J’ai l’impression qu’avec cette fonctionnalité, on pourrait obtenir un résultat encore meilleur