Linux loopt nog steeds enorm achter op MacOS en zelfs op Windows als het gaat om het waarborgen van de consistentie van de kleuren die op de monitor worden weergegeven. De breed opgedrongen invoering van de Wayland-grafische server in de meeste Linux-distributies heeft deze situatie nog verder verslechterd, aangezien kleurbeheer lange tijd door de Wayland-ontwikkelaars is geweigerd. De specificatie voor een CMS in Wayland werd uiteindelijk opgesteld in 2020 en de code werd in 2025 samengevoegd in upstream Wayland, door externe bijdragers, en na een lange strijd van de ontwikkelaars van eerdere CMS-software tegen de historische ontwikkelaars van Wayland.1 Sindsdien is de staat van CMS-ondersteuning zeer wisselvallig tussen desktopomgevingen en distributies. En toch tonen de voorlopige resultaten van Ansel-telemetrie 67 % Wayland-invoering onder Ansel-gebruikers.

Je zou Ansel, of welke andere beeldbewerkingssoftware dan ook, niet op Wayland moeten gebruiken.

TL;DR: waarom Wayland niet op Linux gebruiken ?

Omdat de auteur zelf van het Wayland-kleurbeheersysteem zei dat het bij lange na niet klaar is voor professioneel foto- & videogebruik.1

Voor consumenten- & entertainmentgebruik kun je de staat van Wayland-CMS-ondersteuning door jouw desktopcompositor controleren op de Wayland-documentatie .

Het probleem

De meeste (zo niet alle) laptopschermen en veel consumentenmonitoren hebben een witpunt dat veel blauwer is dan de standaard 6500 K, ergens tussen 6800 K en 7200 K. Om dat te corrigeren is de historische manier om het scherm te kalibreren en de kalibratiecurven weg te schrijven in de Video Card Gamma Table (VCGT) . De VCGT is zowel:

Bij het starten van jouw Linux-sessie leest een stukje software de VCGT uit een ICC-profiel en laadt het in het feitelijke videogeheugen. Zo zou het hele bureaublad zijn witpunt en contrastcurve in één luie stap gecorrigeerd hebben, of applicaties nu “kleurbeheerd” waren of niet.

Later hebben veel applets genaamd “night color” of “redshift” de VCGT gehackt om kleuren ’s avonds en ’s nachts naar amber te verschuiven, omdat bekend is dat blauw(ig) licht de slaappatronen verstoort, en hoewel dit geweldig is voor je circadiaans ritme, voegt het een laag willekeur toe aan de kleurpipeline. Ook kon de VCGT zonder waarschuwing verloren gaan bij het hervatten uit de stand-bymodus, en verschillende applicaties konden erom wedijveren om als laatste degene te zijn die hem overschreef. De opkomst van dual-GPU-systemen (discreet + ingebed) heeft niets gedaan om de betrouwbaarheid in de kleurpipeline te helpen, en het propriëtaire Nvidia-stuurprogramma is nog steeds het enige dat toestaat de VCGT te voorbekijken.

Maar de kern van de zaak is: je hebt een of andere systeembrede manier nodig om een VCGT te laden om het witpunt te normaliseren,2 en Xorg/X11 had colord om globaal een systeemschermprofiel aan te bieden dat applicaties konden ophalen.

Bovenop de VCGT, die de kalibratie bevat, komt de profilering die de oorspronkelijke kleurprimaire kleuren van het scherm corrigeert, zodat RGB-tripletten overeenkomen met het lichtspectrum waaraan ze zijn gekoppeld. Kortom:

  • het witpunt van het scherm vastzetten op 6500 K en de helderheidsrespons lineariseren is de eerste fase (kalibratie),
  • de kleurprimaire kleuren van het scherm vastzetten om afwijkingen in tint en verzadiging te verminderen is de tweede fase (profilering).

De profilering is doorgaans een 3×3-kleurmatrix, soms met extra curven of gamma, maar het kan ook een LUT zijn (niet aanbevolen in Ansel).

Wanneer een fotograaf zijn scherm “kalibreert”, worden in werkelijkheid beide fasen meestal stilzwijgend uitgevoerd en opgeslagen in hetzelfde ICC-profiel. Er is een manier, met name in Display Cal, om de kalibratie via de VCGT uit te schakelen, die dan als geheel in de profilering wordt ingebakken, maar dit is over het algemeen een heel slecht idee, want dan worden GUI-themakleuren uitgesloten van witpuntaanpassing, zelfs op Xorg.

Op applicatieniveau kunnen we alleen de profileringsfase op afbeeldingen toepassen. Dit heeft 2 implicaties :

  1. De kleurgeldigheid van de profileringsfase berust op het correct uitvoeren van de kalibratiefase op VCGT-niveau. Profilering wordt onvoorspelbaar en onnauwkeurig zonder zijn tweelingkalibratie : het is een pipeline.
  2. We kunnen GUI-kleuren van het applicatiethema (in het bijzonder: achtergrondkleur) die in een CSS-stylesheet zijn gedeclareerd en doorgegeven aan Gtk niet kleurcorrigeren/kleurbeheren.

Dit is een probleem in Ansel omdat we de hele GUI neutraal grijs maken, voor kleurbeoordelingsdoeleinden, en we hebben nodig dat dit grijs 6500 K is, maar ook consistent met het witpunt van de afbeelding. Dus hebben we een kleurbeheer voor het hele bureaublad nodig, ten minste voor de kalibratie, om botsende witpunten tussen vensters te vermijden. Wat het oorspronkelijke ontwerp van Wayland expliciet niet als zijn zaak beschouwt, waarbij het erop vertrouwt dat app-ontwikkelaars het juiste doen (alsof…).

En dan, last but not least, als je meerdere monitoren gebruikt, heb je een of ander stuk software nodig dat een ICC-profiel aan elke monitor koppelt, zodat het CMS het juiste profiel kan pakken voor de monitor waar jouw applicatievenster op staat.3 Wat Wayland expliciet verbiedt om “veiligheids"redenen.

Wat je moet controleren als je Wayland gebruikt

Het volgende gaat ervan uit dat je jouw monitor met een colorimeter hebt gekalibreerd en geprofileerd, en een schermkleur-ICC-profiel hebt geproduceerd dat de kleurafwijkingen van jouw monitor neutraliseert.

Controleer dat elke monitor bij het starten van een grafische sessie zijn kalibratie uit het ICC-profiel in de VCGT geladen krijgt
Dat deel lijkt vanaf 2026 redelijk gedekt te zijn, ten minste voor de belangrijkste spelers Gnome/KDE Plasma. De desktopomgeving maakt het mogelijk een systeemprofiel te definiëren dat globaal het witpunt van alle applicaties zal wijzigen.
Zo niet, dan maakt het commando dispwin  van de argyllcms-software het mogelijk het handmatig te laden, zoals dispwin -d 1 ~/.local/share/icc/YOUR_DISPLAY_PROFILE.icc. “Volstaat” om het te scripten en het script automatisch met jouw sessie te laten starten, wat elke gebruiker die niet bekend is met scripten uitsluit.
Controleer dat elke monitor is getagd met een kleurprofiel
Dit deel is expliciet uit het Wayland-protocol verwijderd, dus applicaties is het, per ontwerp, verboden om informatie over schermen op te halen. In het bijzonder zal het starten van ansel-cmstest in Wayland het volgende opleveren:
 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
Dit betekent in de praktijk dat het Ansel-systeemprofiel (standaard), dat verondersteld wordt automatisch te worden gedetecteerd via colord of xatom op X11/Xorg, altijd leeg/ongedefinieerd is op Wayland en dat je het volgende zult moeten doen:
  1. jouw schermprofiel toevoegen aan ~./config/ansel/color/out,
  2. het handmatig kiezen in het globale menu Scherm -> Monitorkleurprofiel,
  3. het handmatig wijzigen als/wanneer je het Ansel-venster naar een andere monitor verplaatst.
Als je dat niet doet, zal Ansel standaard sRGB als uitvoerkleurruimte gebruiken. Als het oorspronkelijke gamut van jouw scherm het volgende is:
  • Adobe RGB, dan zullen kleuren in de groen-cyanregio verzadigder op het scherm lijken dan ze in het bestand zijn,
  • Display P3, dan zullen alle kleuren verzadigder op het scherm lijken dan ze in het bestand zijn, maar de oranje-groen-cyanregio zal ook de grootste boosdoener zijn.
Dit probleem heeft geen oplossing binnen GTK3, dat Ansel als grafische toolkit gebruikt, en zelfs met GTK4 is er tot nu toe nog steeds geen levensvatbare, breed ondersteunde oplossing. Handmatig omgaan met kleurprofielen in Ansel werkt totdat de compositors zelf actief kleurbeheer op applicatievensters gaan toepassen : dan biedt GTK3 geen manier om een venster als “al kleurbeheerd” te taggen, om te voorkomen dat de compositor het nog verder schaadt. In plaats daarvan zal het de kleurruimteconversies die we al intern hebben gedaan verdubbelen en de kleuren verknoeien op een manier die alleen experts zullen kunnen opmerken. Gelukkig voor ons is vanaf medio 2026 geen enkele compositor in staat om iets aan kleurbeheer te doen.
In elk geval kunnen de handmatige kleurruimteconversies alleen worden uitgevoerd op afbeeldingsoppervlakken die we in het Ansel-appvenster tekenen. We hebben nul controle over de kleuren van GUI-bedieningselementen die in de themastylesheet (ansel.css) zijn gedefinieerd en rechtstreeks door GTK-widgets worden afgehandeld, die impliciet sRGB zijn (volgens de CSS-standaard). Dat betekent dat GUI-kleuren er altijd oververzadigd zullen uitzien als het oorspronkelijke gamut van jouw monitor groter is dan sRGB, vergeleken met hoe ze bedoeld zijn.
Controleer dat HDR-ondersteuning is uitgeschakeld
Wayland ondersteunt nu HDR-mogelijkheden door te knoeien met de achtergrondverlichting van het scherm. Hoewel Ansel goede oude 8-bits RGB uitvoert en de HDR-triggers niet zou moeten overhalen, maakt HDR geen deel uit van ICC v2 of v4 en is er niet te zeggen hoe deze functie de toonrespons zou beïnvloeden. Het kan onschadelijk zijn, maar totdat dit grondig is doorgelicht, is de veilige weg om HDR uitgeschakeld te houden.
Controleer dat je Xorg gebruikt
Serieus, gebruik gewoon geen Wayland voor fotografie.
Translated from English by : Claude. In case of conflict, inconsistency or error, the English version shall prevail.

  1. Pekka Paalanen, 12 years of incubating Wayland color management, February 2025. URL  ↩︎ ↩︎

  2. The contrast/brightness curve is not so much of an issue on LED screens that are, by nature, close to linear. ↩︎

  3. And since Xorg as well as Wayland allow application windows to sit on multiple monitors at once, you can only guess which color profile is going to be applied. ↩︎