O terminal deveria gerar automaticamente uma paleta de 256 cores

• Texto que propõe gerar automaticamente a paleta de 256 cores a partir do tema base16 do usuário, apresentando uma forma de melhorar a consistência das cores e a legibilidade no terminal
• Os temas base16 existentes são simples, mas têm número limitado de cores, enquanto o truecolor traz complexidade de configuração e problemas de compatibilidade
• A paleta padrão de 256 cores tem baixa qualidade visual devido a desequilíbrio de brilho, desalinhamento com o tema e interpolação incorreta
• Ao gerar uma paleta expandida a partir das cores base16 usando interpolação no espaço de cor LAB, é possível obter uma representação de cores mais rica mantendo brilho e contraste consistentes
• Vários terminais importantes (por exemplo, Ghostty, iTerm2, SwiftTerm) já estão implementando isso, e há potencial para que um recurso padronizado de geração automática de paleta melhore a qualidade em todo o ecossistema de terminais

---

Visão geral da paleta de 256 cores

• A paleta de 256 cores é composta por 16 cores básicas, um cubo de 216 cores e uma escala de cinza de 24 níveis
  • As 16 cores básicas incluem preto, branco, cores primárias e variações claras
  • O cubo de 216 cores é calculado usando 6 níveis (0~5) em cada canal RGB: 16 + (36 * R) + (6 * G) + B
  • A escala de cinza é composta por 24 níveis entre preto e branco: 232 + S (S é 0~23)
• Essa estrutura é uma versão simplificada do RGB de 24 bits, reduzindo o número de cores sem perder poder de expressão

Problemas da paleta atual de 256 cores

• Ocorrem conflitos de cor devido à falta de correspondência com temas Base16
  • A paleta padrão não harmoniza com a maioria dos temas base16
• A interpolação incorreta de cores reduz a legibilidade em fundos escuros
  • O primeiro tom da paleta padrão é calculado como mais claro do que deveria, enfraquecendo o contraste
• Há também problema de contraste desigual
  • Como usa cores totalmente saturadas, o equilíbrio de brilho fica comprometido, e mesmo no mesmo nível o azul parece mais escuro que o verde

Método de geração da paleta

• A solução é gerar automaticamente a paleta de 256 cores a partir das cores base16 do usuário
  • Mapear as 8 cores básicas do base16 para os 8 vértices do cubo de 216 cores
  • Gerar o cubo por interpolação trilinear (trilinear interpolation) usando a cor de fundo e a cor de primeiro plano
  • Usar o espaço de cor LAB para manter a consistência visual de brilho entre as cores
• A escala de cinza é gerada por interpolação simples do fundo ao primeiro plano
• No código de exemplo em Python, a conversão é feita com as funções rgb_to_lab, lab_to_rgb e lerp_lab

Implementação e estado de adoção

• O código proposto foi publicado em domínio público e pode ser modificado e reutilizado livremente
• Já foi implementado em terminais importantes como Ghostty, iTerm2 e SwiftTerm
• Também há pedidos de adoção ou desenvolvimento em andamento em kitty, Wezterm, Tabby e Windows Terminal
• Alguns desenvolvedores sugeriram usar os espaços de cor OKLAB/OKLCH, e o projeto pretende unificar o espaço de cor padrão de acordo com a decisão do Ghostty
• É possível aplicar a paleta diretamente por meio de um script em Python ou gerar automaticamente arquivos de configuração do terminal

Conclusão e proposta

• A paleta padrão de 256 cores é evitada por desenvolvedores de programas devido à queda de legibilidade e desalinhamento com o tema
• Se o terminal gerar automaticamente uma paleta de 256 cores com base em um tema base16, será possível obter os seguintes benefícios
  • Uso de uma ampla faixa de cores sem arquivos de configuração
  • Nenhuma intervenção do desenvolvedor ao alternar entre modo claro/escuro
  • Manutenção de ampla compatibilidade entre terminais
• O autor da proposta enfatiza que esse recurso deveria vir ativado por padrão (opt-out) e, no longo prazo, tornar-se um recurso padrão

[GN⁺]

Comentários do Hacker News

• O bom da paleta de 256 cores é que as cores de 16 a 255 são fixas
  Então, por exemplo, dá para ter certeza de que a cor 146 é sempre um “roxo suave”
  Isso é muito útil para desenvolvedores de temas de cores que querem oferecer uma experiência de cores consistente em diferentes emuladores de terminal
  Se a paleta de 256 cores fosse gerada a partir de uma paleta variável de 16 cores, a 146 talvez não fosse a cor esperada
  Acho que transformar a faixa 16–255 em algo instável como 0–15 seria um passo na direção errada

  • Embora usar só 16 cores seja limitante, também é incômodo quando desenvolvedores de CLI/TUI saem desse intervalo para criar temas de cores arbitrários
    Isso prejudica a legibilidade para pessoas com deficiência visual, daltonismo ou que preferem fundo branco
    No fim, o usuário precisa ajustar não só as cores padrão do terminal, mas também as configurações de cor de cada aplicativo
    As pessoas usam terminal por eficiência, não por uma UI bonita. Se quiser algo bonito, faça um frontend web
  • As cores no terminal deveriam ser usadas com foco em semântica, não em estilo
    Não queremos uma “experiência consistente”. As cores devem ser usadas com moderação e respeitando as configurações do usuário
  • Mesmo sabendo que a 146 é um “roxo suave”, isso não significa nada sem saber a cor de fundo
    O fundo pode ser roxo, ou pode ser texto roxo sobre fundo branco
    Ou seja, se o app não conhece o esquema de cores do meu terminal, não deveria usar essa cor
  • Na prática, esse recurso combina mais com usuários que montam sua própria paleta do que com desenvolvedores de temas de cores
    Eu uso o tema base16 padrão e não espero compatibilidade com temas feitos por terceiros
    Acho que a diferença entre a abordagem no nível do terminal e no nível do app é mais uma questão filosófica
  • Terminais como o iTerm2 já oferecem o recurso de Contraste Mínimo (Minimum Contrast), mas isso às vezes distorce bastante as cores

• Eu criei um renderizador de Markdown em streaming chamado Streamdown
  Com base em HSV, se você definir só uma cor de referência, o restante é ajustado automaticamente como múltiplos dessa cor
  Por exemplo, elementos escuros perdem saturação, e símbolos ficam mais vivos
  Mesmo mexendo só um pouco no HSV nas configurações, o tom geral muda de forma natural, sem precisar ajustar cor por cor
  Também há um código de exemplo

• Mesmo a paleta básica de 16 cores já tem problemas
  ‘black’, ‘white’, ‘bright black’ e ‘bright white’ deveriam na verdade representar contraste de luminosidade, mas os nomes são de cores
  Eu entendo isso como “cor quase invisível em relação ao fundo”, “cor de alto contraste”, “cor visível, mas fraca” e “cor de contraste máximo”
  Seria melhor se fossem definidos com foco em contraste, não em nomes de cor

  • O jeito certo é não mexer nas cores do terminal e configurar o programa para usar outras cores
    As cores de primeiro plano e fundo do terminal são independentes do padrão de 16 cores, o que complica ainda mais
  • Se não houver configuração de cores, é melhor usar apenas atributos como bold·reverse·standout
    E, sem saber o fundo, é melhor evitar preto e branco. Ao usar 256 cores, deve-se usar um mecanismo de temas configurável pelo usuário

• Acho que esse recurso deveria ser adicionado a todos os terminais
  Seria ainda melhor se fosse estendido para cores de 24 bits. Mas deve ser opcional
  Por exemplo, se você usa o tema Solarized tanto no terminal quanto no editor, a conversão de cores pode acabar sendo aplicada em duplicidade

  • Também daria para criar uma LUT (tabela de consulta) a partir da paleta de 16 cores e mapear para o espaço de cores de 24 bits
    Seria ainda mais flexível se o app não sobrescrevesse essas configurações diretamente e isso pudesse ser controlado por variáveis de ambiente

• Descobri e estou usando tinted-theming/base24
  Dá para alternar temas de cor com facilidade usando o tinted shell. Foi uma solução temporária bem razoável

• No cargo/rustc também existe o problema da falta de cores
  Se você usar só as cores semânticas padrão, acabam sobrando apenas magenta, preto e branco, o que é perigoso dependendo do tema

  • Tirando vermelho e verde, acho melhor que ferramentas CLI não dependam muito de cores e deem suporte a marcadores de texto

• Basta usar o modo true color de 24 bits que não precisa de paleta
  Segundo termstandard/colors, a maioria dos terminais modernos oferece suporte a isso

  • Mas o texto original também trazia uma oposição clara ao true color
  • O urxvt ainda não suporta true color completo
  • Como não dá para controlar totalmente todas as cores, no fim ainda é preciso fazer suposições. Esse é o ponto central
  • O cerne desta discussão não é true color, e sim usar temas configuráveis pelo usuário com base em 256 cores
  • Conforme a tecnologia avançar, talvez até padrões de cor perceptuais de 48 bits ou mais se tornem possíveis
    Considerando até limites físicos (princípio da incerteza de Heisenberg, ruído quântico etc.), seriam necessários dados na faixa de 6000 bits/pixel
    Esse tipo de imaginação é um experimento mental interessante sobre a direção do progresso tecnológico, como a escala de Kardashev ou conceitos antigos de tempo cósmico

• Nem todo usuário deixa as configurações de cor padrão bem ajustadas
  Alguns terminais podem ter um tom todo esverdeado ou alaranjado
  Talvez aplicar a saturação das cores padrão à paleta inteira já seja uma abordagem melhor

• Eu sou daltônico e sempre sofri com temas de cor
  Então uso modelos de IA para gerar automaticamente combinações de cores com boa legibilidade
  Aumentando o contraste com base em temas que eu já gostava, ficou muito mais confortável de ler
  Acho que esse tipo de abordagem também pode ajudar outras pessoas

  • Eu não sou daltônico, mas passo por um problema parecido
    Cada app usa cores de um jeito diferente, então um tema pode ficar bom em alguns CLIs e apagado demais em outros
    No fim, existe o incômodo de ter que ajustar o tema de cores separadamente em cada app

• Eu tenho protanomalia e estou usando ametameric
  Acho que, usando junto com esse recurso, daria para ter um resultado melhor