Gestion des couleurs pour les utilisateurs de Linux

Linux accuse toujours un retard considérable sur MacOS et même sur Windows lorsqu’il s’agit d’assurer la cohérence des couleurs affichées à l’écran. L’adoption largement imposée du serveur graphique Wayland dans la plupart des distributions Linux a encore aggravé cet état de fait, la gestion des couleurs ayant longtemps été refusée par les développeurs de Wayland. La spécification d’un CMS dans Wayland a finalement été ébauchée en 2020 et le code a été intégré en amont dans Wayland en 2025, par des contributeurs externes, et après une longue bataille des développeurs des logiciels de CMS antérieurs contre les développeurs historiques de Wayland.¹ Depuis, l’état de la prise en charge du CMS est très aléatoire selon les environnements de bureau et les distributions. Et pourtant, les résultats préliminaires de la télémétrie d’Ansel montrent une adoption de Wayland à hauteur de 67 % parmi les utilisateurs d’Ansel.

Vous ne devriez pas utiliser Ansel, ni aucun autre logiciel de retouche d’image, sous Wayland.

En bref : pourquoi ne pas utiliser Wayland sous Linux ?

Parce que l’auteur même du système de gestion des couleurs de Wayland a déclaré qu’il était loin d’être prêt pour un usage professionnel en photo et vidéo.¹

Pour un usage grand public et de divertissement, vous pouvez vérifier l’état de la prise en charge du CMS de Wayland par votre compositeur de bureau sur la documentation de Wayland .

Le problème

La plupart (sinon la totalité) des écrans d’ordinateurs portables et de nombreux moniteurs grand public ont un point blanc bien plus bleu que le standard de 6500 K, quelque part entre 6800 K et 7200 K. Pour corriger cela, la méthode historique consiste à calibrer l’écran et à écrire les courbes de calibration dans la Video Card Gamma Table (VCGT) . La VCGT est à la fois :

• un champ de données spécial  à l’intérieur des profils ICC,
• une région mémoire spéciale sur votre GPU.

Au démarrage de votre session Linux, un logiciel lit la VCGT depuis un profil ICC et la charge dans la mémoire vidéo réelle. Ainsi, l’ensemble du bureau voit son point blanc et sa courbe de contraste corrigés en une seule étape paresseuse, que les applications soient « gérées en couleur » ou non.

Plus tard, de nombreux applets appelés « night color » ou « redshift » ont détourné la VCGT pour décaler les couleurs vers l’ambre le soir et la nuit, car la lumière bleu(âtre) est connue pour perturber le sommeil, et si c’est excellent pour votre rythme circadien, cela ajoute une couche d’aléatoire dans le pipeline des couleurs. De plus, la VCGT pouvait être perdue sans avertissement lors de la reprise après une mise en veille, et plusieurs applications pouvaient se disputer le fait d’être la dernière à l’écraser. L’essor des systèmes à double GPU (dédié + intégré) n’a en rien aidé la fiabilité du pipeline des couleurs, et le pilote propriétaire Nvidia est toujours le seul à permettre de prévisualiser la VCGT.

Mais l’essentiel est le suivant : vous avez besoin d’une sorte de mécanisme à l’échelle du système pour charger une VCGT afin de normaliser le point blanc,² et Xorg/X11 disposait de colord pour publier globalement un profil d’affichage système que les applications pouvaient récupérer.

Par-dessus la VCGT, qui contient la calibration, vient le profilage qui corrige les primaires de couleur natives de l’écran, de sorte que les triplets RVB correspondent au spectre lumineux auquel ils sont associés. En bref :

• fixer le point blanc de l’écran à 6500 K et linéariser la réponse en luminosité est la première étape (calibration),
• fixer les primaires de couleur de l’écran pour réduire les écarts de teinte et de saturation est la seconde étape (profilage).

Le profilage est typiquement une matrice de couleur 3×3, parfois accompagnée de courbes ou d’un gamma supplémentaires, mais il peut aussi s’agir d’une LUT (déconseillée dans Ansel).

Lorsqu’un photographe « calibre » son écran, en réalité les deux étapes sont généralement effectuées silencieusement et enregistrées dans le même profil ICC. Il existe un moyen, notamment dans Display Cal, de désactiver la calibration via la VCGT, ce qui l’intègre alors dans le profilage en un seul bloc, mais c’est généralement une très mauvaise idée car les couleurs du thème de l’interface graphique sont alors exclues de l’adaptation du point blanc, même sous Xorg.

Au niveau de l’application, nous ne pouvons appliquer que l’étape de profilage sur les images. Cela a 2 implications :

1. La validité colorimétrique de l’étape de profilage repose sur le fait que l’étape de calibration soit correctement effectuée au niveau de la VCGT. Le profilage devient imprévisible et imprécis sans sa calibration jumelle : c’est un pipeline.
2. Nous ne pouvons pas corriger/gérer en couleur les couleurs de l’interface graphique issues du thème de l’application (en particulier : la couleur d’arrière-plan) déclarées dans la feuille de style CSS et transmises à Gtk.

C’est un problème dans Ansel car nous mettons toute l’interface graphique en gris neutre, à des fins d’évaluation des couleurs, et nous avons besoin que ce gris soit à 6500 K, mais aussi cohérent avec le point blanc de l’image. Nous avons donc besoin d’une gestion des couleurs à l’échelle de tout le bureau, au moins pour la calibration, afin d’éviter des points blancs discordants entre les fenêtres. Ce dont la conception initiale de Wayland fait explicitement une chose qui ne le regarde pas, s’en remettant aux développeurs d’applications pour faire ce qu’il faut (comme si…).

Et enfin, mais ce n’est pas le moins important, si vous utilisez plusieurs moniteurs, vous avez besoin d’un logiciel associant un profil ICC à chaque moniteur, de sorte que le CMS puisse récupérer le bon profil pour le moniteur sur lequel se trouve la fenêtre de votre application.³ Ce que Wayland interdit explicitement pour des raisons de « sécurité ».

Ce que vous devez vérifier si vous utilisez Wayland

Ce qui suit suppose que vous avez calibré et profilé votre moniteur avec un colorimètre, et produit un profil ICC d’affichage neutralisant les écarts de couleur de votre moniteur.

Vérifiez que chaque moniteur a sa calibration chargée depuis le profil ICC vers la VCGT au démarrage d’une session graphique

Cette partie semble assez bien couverte en 2026, du moins pour les principaux acteurs Gnome/KDE Plasma. L’environnement de bureau permet de définir un profil système qui changera globalement le point blanc de toutes les applications.

Si ce n’est pas le cas, la commande dispwin  du logiciel argyllcms permet de la charger manuellement, comme dispwin -d 1 ~/.local/share/icc/YOUR_DISPLAY_PROFILE.icc. « Il suffit » de la scripter et de faire démarrer le script automatiquement avec votre session, ce qui exclut tout utilisateur peu familier avec le scripting.

Vérifiez que chaque moniteur est étiqueté avec un profil de couleur

Cette partie est explicitement supprimée du protocole Wayland, si bien qu’il est, par conception, interdit aux applications de récupérer des informations sur les affichages. En particulier, lancer ansel-cmstest sous Wayland retournera :

 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

Cela signifie concrètement que le profil système (par défaut) d’Ansel, censé être automatiquement détecté via colord ou xatom sous X11/Xorg, est vide/indéfini en permanence sous Wayland et vous devrez :

1. ajouter votre profil d’affichage dans ~./config/ansel/color/out,
2. le choisir manuellement dans le menu global Affichage -> Profil de couleur du moniteur,
3. le changer manuellement si/quand vous déplacez la fenêtre d’Ansel vers un autre moniteur.

Le fait de ne pas le faire aura pour conséquence qu’Ansel utilisera par défaut sRVB comme espace colorimétrique de sortie. Si le gamut natif de votre affichage est :

• Adobe RGB, alors les couleurs dans la région vert-cyan apparaîtront plus saturées à l’écran qu’elles ne le sont dans le fichier,
• Display P3, alors toutes les couleurs apparaîtront plus saturées à l’écran qu’elles ne le sont dans le fichier, mais la région orange-vert-cyan sera aussi la plus problématique.

Ce problème n’a pas de solution au sein de GTK3, qu’Ansel utilise comme boîte à outils graphique, et même avec GTK4, il n’existe toujours pas de solution viable et largement prise en charge à l’heure actuelle. La gestion manuelle des profils de couleur dans Ansel fonctionne jusqu’à ce que les compositeurs commencent à gérer activement eux-mêmes les couleurs des fenêtres d’applications : GTK3 n’offre alors aucun moyen d’étiqueter une fenêtre comme « déjà gérée en couleur », de manière à empêcher le compositeur de leur nuire davantage. Il va au contraire cumuler les conversions d’espace colorimétrique que nous avons déjà effectuées en interne et fausser les couleurs d’une manière que seuls des experts sauront repérer. Heureusement pour nous, à la mi-2026, aucun compositeur n’est capable de gérer les couleurs de quoi que ce soit.

Dans tous les cas, les conversions manuelles d’espace colorimétrique ne peuvent être effectuées que sur les surfaces d’image que nous dessinons dans la fenêtre de l’application Ansel. Nous n’avons aucun contrôle sur les couleurs des contrôles de l’interface graphique définies dans la feuille de style du thème (ansel.css), et gérées directement par les widgets GTK, qui sont implicitement en sRVB (conformément au standard CSS). Cela signifie que les couleurs de l’interface graphique paraîtront toujours sursaturées si le gamut natif de votre moniteur est plus large que sRVB, par rapport à ce qu’elles sont censées être.

Vérifiez que la prise en charge du HDR est désactivée

Wayland prend désormais en charge les capacités HDR en manipulant le rétroéclairage de l’écran. Bien qu’Ansel produise du bon vieux RVB 8 bits et ne devrait pas déclencher les mécanismes HDR, le HDR ne fait pas partie de l’ICC v2 ou v4 et il n’y a aucun moyen de savoir comment cette fonctionnalité affecterait la réponse tonale. Cela peut être inoffensif, mais tant que ce n’est pas audité de manière approfondie, la voie sûre est de garder le HDR désactivé.

Vérifiez que vous utilisez Xorg

Sérieusement, n’utilisez tout simplement pas Wayland pour la photographie.