Gerenciamento de cores para usuários de Linux

O Linux ainda está muito atrás do MacOS e até mesmo do Windows quando se trata de garantir a consistência das cores exibidas no monitor. A adoção amplamente forçada do servidor gráfico Wayland na maioria das distribuições Linux prejudicou ainda mais esse cenário, já que o gerenciamento de cores foi por muito tempo recusado pelos desenvolvedores do Wayland. A especificação de um CMS no Wayland foi finalmente rascunhada em 2020 e o código foi mesclado ao Wayland upstream em 2025, por colaboradores externos, e após uma longa batalha dos desenvolvedores dos softwares de CMS anteriores contra os desenvolvedores históricos do Wayland.¹ Desde então, o estado do suporte a CMS é muito irregular entre os diversos ambientes de área de trabalho e distribuições. E, ainda assim, os resultados preliminares da telemetria do Ansel mostram 67 % de adoção do Wayland entre os usuários do Ansel.

Você não deveria usar o Ansel, nem nenhum outro software de edição de imagens, no Wayland.

TL;DR: por que não usar o Wayland no Linux ?

Porque o próprio autor do sistema de gerenciamento de cores do Wayland disse que ele está longe de estar pronto para uso profissional em fotografia e vídeo.¹

Para uso de consumo e entretenimento, você pode verificar o estado do suporte a CMS do Wayland no seu compositor de área de trabalho na documentação do Wayland .

O problema

A maioria (se não todas) das telas de laptops e muitos monitores de nível consumidor têm um ponto branco muito mais azul do que o padrão de 6500 K, algo entre 6800 K e 7200 K. Para corrigir isso, a maneira histórica é calibrar a tela e gravar as curvas de calibração na Tabela de Gama da Placa de Vídeo (VCGT) . A VCGT é ao mesmo tempo:

• um campo de dados especial  dentro dos perfis ICC,
• uma região de memória especial na sua GPU.

Ao iniciar a sua sessão Linux, algum software lê a VCGT de um perfil ICC e a carrega na memória de vídeo real. Assim, toda a área de trabalho teria seu ponto branco e curva de contraste corrigidos em um único passo preguiçoso, quer os aplicativos fossem “com gerenciamento de cores” ou não.

Mais tarde, muitos applets chamados de “night color” ou “redshift” alteraram a VCGT para deslocar as cores para o âmbar à noite e de madrugada, porque se sabe que a luz azul(ada) perturba os padrões de sono, e embora isso seja ótimo para o seu ritmo circadiano, adiciona uma camada de aleatoriedade ao pipeline de cores. Além disso, a VCGT podia ser perdida sem aviso ao retornar do modo de espera, e vários aplicativos podiam competir para ser o último a sobrescrevê-la. A ascensão dos sistemas com GPU dupla (dedicada + integrada) em nada ajudou a confiabilidade do pipeline de cores, e o driver proprietário da Nvidia ainda é o único que permite pré-visualizar a VCGT.

Mas a conclusão é: você precisa de algum tipo de mecanismo em todo o sistema para carregar uma VCGT que normalize o ponto branco,² e o Xorg/X11 tinha o colord para anunciar globalmente um perfil de tela do sistema que os aplicativos pudessem obter.

Além da VCGT, que contém a calibração, vem o perfilamento, que corrige as primárias de cor nativas da tela, de modo que os tripletos RGB correspondam ao espectro de luz ao qual estão associados. Em resumo:

• acertar o ponto branco da tela em 6500 K e linearizar a resposta de brilho é a primeira etapa (calibração),
• acertar as primárias de cor da tela para reduzir desvios de matiz e saturação é a segunda etapa (perfilamento).

O perfilamento é tipicamente uma matriz de cor 3×3, às vezes com curvas ou gama extras, mas também pode ser uma LUT (não recomendado no Ansel).

Quando um fotógrafo “calibra” sua tela, na verdade ambas as etapas geralmente são feitas silenciosamente e salvas no mesmo perfil ICC. Há uma maneira, em particular no Display Cal, de desabilitar a calibração via VCGT, o que então a incorpora ao perfilamento como um pacote, mas isso geralmente é uma péssima ideia, porque então as cores do tema da interface gráfica ficam excluídas da adaptação do ponto branco, mesmo no Xorg.

No nível do aplicativo, só podemos aplicar a etapa de perfilamento nas imagens. Isso tem 2 implicações :

1. A validade cromática da etapa de perfilamento depende de a etapa de calibração ter sido corretamente realizada no nível da VCGT. O perfilamento torna-se imprevisível e impreciso sem sua calibração gêmea : é um pipeline.
2. Não podemos corrigir/gerenciar as cores da interface gráfica provenientes do tema do aplicativo (em particular: a cor de fundo) declaradas na folha de estilo CSS e repassadas ao Gtk.

Isso é um problema no Ansel porque definimos toda a interface gráfica como cinza neutro, para fins de avaliação de cores, e precisamos que esse cinza seja de 6500 K, mas também consistente com o ponto branco da imagem. Portanto, precisamos de um gerenciamento de cores em toda a área de trabalho, pelo menos para a calibração, para evitar pontos brancos conflitantes entre as janelas. O que o design inicial do Wayland explicitamente coloca como algo que não é da sua conta, contando com os desenvolvedores dos aplicativos para fazer a coisa certa (como se…).

E então, por último, mas não menos importante, se você estiver usando vários monitores, precisará de algum software que mapeie um perfil ICC para cada monitor, de modo que o CMS possa pegar o perfil correto para o monitor onde a janela do seu aplicativo está.³ O que o Wayland explicitamente proíbe por motivos de “segurança”.

O que você precisa verificar se usar o Wayland

O que se segue pressupõe que você calibrou e perfilou seu monitor com um colorímetro e produziu um perfil ICC de tela que neutraliza os desvios de cor do seu monitor.

Verifique que cada monitor tenha sua calibração carregada do perfil ICC para a VCGT ao iniciar uma sessão gráfica

Essa parte parece estar razoavelmente coberta em 2026, ao menos para os principais participantes Gnome/KDE Plasma. O ambiente de área de trabalho permite definir um perfil de sistema que mudará globalmente o ponto branco de todos os aplicativos.

Caso contrário, o comando dispwin  do software argyllcms permite carregá-la manualmente, como dispwin -d 1 ~/.local/share/icc/YOUR_DISPLAY_PROFILE.icc. “Basta” transformá-lo em script e fazer o script iniciar automaticamente com a sua sessão, o que exclui qualquer usuário não familiarizado com scripts.

Verifique que cada monitor esteja marcado com um perfil de cor

Essa parte foi explicitamente removida do protocolo Wayland, então os aplicativos estão, por design, proibidos de obter informações sobre as telas. Em particular, iniciar o ansel-cmstest no Wayland retornará:

 1$ /opt/ansel/bin/ansel-cmstest
 2ansel-cmstest version 0.0.0+3877~gcfa6648f92
 3this executable was built with colord support enabled
 4ansel itself was built with colord support enabled
 5
 6primary CRTC is at CRTC 0
 7
 8eDP-1   the X atom and colord returned the same profile
 9        X atom: _ICC_PROFILE (0 bytes)
10                description: (none)
11        colord: "(none)"
12                description: (file not found)
13
14Better check your system setup
15- some monitors lacked a profile
16You may experience inconsistent color rendition between color managed applications

Na prática, isso significa que o perfil de sistema (padrão) do Ansel, que deveria ser detectado automaticamente por meio do colord ou do xatom no X11/Xorg, está vazio/indefinido o tempo todo no Wayland e você precisará:

1. adicionar seu perfil de tela em ~./config/ansel/color/out,
2. escolhê-lo manualmente no menu global Tela -> Perfil de cor do monitor,
3. alterá-lo manualmente se/quando você mover a janela do Ansel para um monitor diferente.

Não fazer isso resultará em o Ansel usar o sRGB como espaço de cor de saída por padrão. Se o gamut nativo da sua tela for:

• Adobe RGB, então as cores na região verde-ciano aparecerão mais saturadas na tela do que estão no arquivo,
• Display P3, então todas as cores aparecerão mais saturadas na tela do que estão no arquivo, mas a região laranja-verde-ciano também será a pior ofensora.

Esse problema não tem solução dentro do GTK3, que o Ansel usa como kit de ferramentas gráficas, e mesmo com o GTK4, ainda não há solução viável e amplamente suportada até o momento. Lidar manualmente com os perfis de cor no Ansel funciona até os compositores começarem a gerenciar ativamente as cores das janelas dos aplicativos por conta própria : então o GTK3 não oferece nenhuma maneira de marcar uma janela como “já gerenciada em cores”, de modo a impedir que o compositor lhes cause mais danos. Em vez disso, ele duplicará as conversões de espaço de cor que já fizemos internamente e estragará as cores de um jeito que só especialistas conseguirão perceber. Felizmente para nós, até meados de 2026, nenhum compositor é capaz de gerenciar as cores de nada.

De qualquer forma, as conversões manuais de espaço de cor só podem ser feitas nas superfícies de imagem que pintamos na janela do aplicativo Ansel. Não temos nenhum controle sobre as cores dos controles da interface gráfica definidas na folha de estilo do tema (ansel.css) e tratadas diretamente pelos widgets do GTK, que são implicitamente sRGB (conforme o padrão CSS). Ou seja, as cores da interface gráfica sempre parecerão supersaturadas se o gamut nativo do seu monitor for maior que o sRGB, em comparação com o que elas deveriam ser.

Verifique que o suporte a HDR esteja desabilitado

O Wayland agora suporta recursos de HDR mexendo na retroiluminação da tela. Embora o Ansel produza o bom e velho RGB de 8 bits e não deva acionar os gatilhos do HDR, o HDR não faz parte do ICC v2 ou v4 e não há como saber como esse recurso afetaria a resposta tonal. Pode ser inofensivo, mas até que isso seja minuciosamente auditado, o caminho seguro é manter o HDR desabilitado.

Verifique que você está usando o Xorg

Sério, simplesmente não use o Wayland para fotografia.