Linux wciąż ogromnie pozostaje w tyle za MacOS-em, a nawet za Windowsem, jeśli chodzi o zapewnienie spójności kolorów wyświetlanych na monitorze. Powszechnie wymuszane przyjęcie serwera graficznego Wayland w większości dystrybucji Linuksa jeszcze bardziej pogorszyło ten stan, ponieważ zarządzanie kolorami było przez długi czas odrzucane przez twórców Waylanda. Specyfikacja CMS w Waylandzie została ostatecznie naszkicowana w 2020 roku, a kod scalono z główną gałęzią Waylanda w 2025 roku, przez zewnętrznych współtwórców, po długiej walce twórców wcześniejszego oprogramowania CMS z historycznymi twórcami Waylanda.1 Od tego czasu stan obsługi CMS jest bardzo niejednoznaczny w różnych środowiskach graficznych i dystrybucjach. A mimo to wstępne wyniki telemetrii Ansela pokazują 67 % przyjęcia Waylanda wśród użytkowników Ansela.

Nie powinieneś używać Ansela ani żadnego innego oprogramowania do edycji obrazów na Waylandzie.

TL;DR: dlaczego nie używać Waylanda na Linuksie ?

Ponieważ sam autor systemu zarządzania kolorami Waylanda powiedział, że jest on daleki od gotowości do profesjonalnego zastosowania w fotografii i wideo.1

Do zastosowań konsumenckich i rozrywkowych możesz sprawdzić stan obsługi CMS Waylanda przez Twój kompozytor pulpitu w dokumentacji Waylanda .

The problem

Większość (jeśli nie wszystkie) ekranów laptopów oraz wiele monitorów konsumenckich ma punkt bieli znacznie bardziej niebieski niż standardowe 6500 K, gdzieś pomiędzy 6800 K a 7200 K. Aby to skorygować, historycznym sposobem jest skalibrowanie ekranu i zapisanie krzywych kalibracji do tablicy gamma karty graficznej (VCGT) . VCGT jest jednocześnie:

Podczas uruchamiania sesji Linuksa jakiś fragment oprogramowania odczytuje VCGT z profilu ICC i ładuje go do rzeczywistej pamięci graficznej. Dzięki temu cały pulpit ma skorygowany punkt bieli i krzywą kontrastu w jednym leniwym kroku, niezależnie od tego, czy aplikacja jest „zarządzana kolorami", czy nie.

Później wiele apletów zwanych „night color" lub „redshift" ingerowało w VCGT, aby przesunąć kolory ku bursztynowi wieczorem i w nocy, ponieważ wiadomo, że niebieskawe światło zaburza wzorce snu — i choć jest to świetne dla Twojego rytmu okołodobowego, dodaje warstwę losowości do potoku kolorów. Ponadto VCGT mogła zostać utracona bez ostrzeżenia przy wybudzaniu z trybu czuwania, a kilka aplikacji mogło ścigać się o to, która jako ostatnia ją nadpisze. Rozwój systemów z dwoma GPU (dedykowanym + zintegrowanym) w niczym nie pomógł niezawodności potoku kolorów, a zamknięty sterownik Nvidii wciąż jest jedynym, który pozwala podglądać VCGT.

Ale sedno jest takie: potrzebujesz jakiegoś ogólnosystemowego sposobu ładowania VCGT, aby znormalizować punkt bieli,2 a Xorg/X11 miał colord do globalnego rozgłaszania systemowego profilu wyświetlacza, który aplikacje mogły pobrać.

Oprócz VCGT, która przechowuje kalibrację, dochodzi profilowanie, które koryguje natywne barwy podstawowe wyświetlacza, tak aby tryplety RGB odpowiadały widmu światła, z którym są powiązane. W skrócie:

  • ustalenie punktu bieli wyświetlacza na 6500 K i zlinearyzowanie odpowiedzi jasności to pierwszy etap (kalibracja),
  • ustalenie barw podstawowych wyświetlacza w celu zmniejszenia odchyleń odcienia i nasycenia to drugi etap (profilowanie).

Profilowanie to zazwyczaj macierz barwna 3×3, czasem z dodatkowymi krzywymi lub gammą, ale może to być również LUT (niezalecane w Anselu).

Gdy fotograf „kalibruje" swój wyświetlacz, w rzeczywistości oba etapy są zwykle po cichu wykonywane i zapisywane do tego samego profilu ICC. Istnieje sposób, w szczególności w Display Cal, aby wyłączyć kalibrację poprzez VCGT, która zostaje wtedy wtopiona w profilowanie jako pakiet, ale generalnie jest to bardzo zły pomysł, ponieważ wówczas kolory motywu GUI są wykluczone z adaptacji punktu bieli nawet na Xorg.

Na poziomie aplikacji możemy zastosować na obrazach tylko etap profilowania. Ma to 2 konsekwencje :

  1. Poprawność barwna etapu profilowania zależy od prawidłowego wykonania etapu kalibracji na poziomie VCGT. Profilowanie staje się nieprzewidywalne i niedokładne bez swojej bliźniaczej kalibracji : to potok (pipeline).
  2. Nie możemy skorygować kolorów / zarządzać kolorami GUI z motywu aplikacji (w szczególności: koloru tła) zadeklarowanego w arkuszu stylów CSS i przekazanego do Gtk.

Jest to problem w Anselu, ponieważ ustawiamy całe GUI na neutralną szarość, na potrzeby oceny kolorów, i potrzebujemy, aby ta szarość miała 6500 K, ale także była spójna z punktem bieli obrazu. Potrzebujemy więc zarządzania kolorami dla całego pulpitu, przynajmniej dla kalibracji, aby uniknąć kolidujących punktów bieli między oknami. Co pierwotny projekt Waylanda wprost czyni nie swoją sprawą, polegając na tym, że twórcy aplikacji zrobią to jak należy (jak gdyby…).

I wreszcie, co nie mniej ważne, jeśli używasz kilku monitorów, potrzebujesz jakiegoś fragmentu oprogramowania mapującego profil ICC do każdego monitora, tak aby CMS mógł pobrać właściwy profil dla monitora, na którym znajduje się okno Twojej aplikacji.3 Co Wayland wprost zakazuje z powodów „bezpieczeństwa".

Co należy sprawdzić, jeśli używasz Waylanda

Poniższe zakłada, że skalibrowałeś i sprofilowałeś swój monitor za pomocą kolorymetru oraz utworzyłeś profil ICC wyświetlacza neutralizujący odchylenia barwne Twojego monitora.

Sprawdź, czy każdy monitor ma załadowaną kalibrację z profilu ICC do VCGT podczas uruchamiania sesji graficznej
Ta część wydaje się być dość dobrze pokryta na rok 2026, przynajmniej dla głównych graczy Gnome/KDE Plasma. Środowisko graficzne pozwala zdefiniować profil systemowy, który globalnie zmieni punkt bieli wszystkich aplikacji.
Jeśli nie, polecenie dispwin  oprogramowania argyllcms pozwala załadować go ręcznie, jak dispwin -d 1 ~/.local/share/icc/YOUR_DISPLAY_PROFILE.icc. „Wystarczy" go oskryptować i sprawić, by skrypt uruchamiał się automatycznie wraz z Twoją sesją, co wyklucza każdego użytkownika nieobeznanego ze skryptowaniem.
Sprawdź, czy każdy monitor jest oznaczony profilem barwnym
Ta część została wprost usunięta z protokołu Waylanda, więc aplikacjom z założenia zabrania się pobierania informacji o wyświetlaczach. W szczególności uruchomienie ansel-cmstest w Waylandzie zwróci:
 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
Praktycznie oznacza to, że profil systemowy (domyślny) Ansela, który powinien być automatycznie wykrywany przez colord lub xatom na X11/Xorg, jest pusty/niezdefiniowany przez cały czas na Waylandzie, i będziesz musiał:
  1. dodać swój profil wyświetlacza do ~./config/ansel/color/out,
  2. wybrać go ręcznie w globalnym menu Display -> Monitor color profile,
  3. ręcznie go zmienić, jeśli/gdy przeniesiesz okno Ansela na inny monitor.
Niewykonanie tego spowoduje, że Ansel domyślnie ustawi sRGB jako wyjściową przestrzeń barwną. Jeśli natywnym gamutem Twojego wyświetlacza jest:
  • Adobe RGB, wówczas kolory w rejonie zielono-cyjanowym będą wyglądać na ekranie na bardziej nasycone, niż są w pliku,
  • Display P3, wówczas wszystkie kolory będą wyglądać na ekranie na bardziej nasycone, niż są w pliku, ale rejon pomarańczowo-zielono-cyjanowy będzie także najgorszym winowajcą.
Ten problem nie ma rozwiązania w GTK3, którego Ansel używa jako zestawu narzędzi graficznych, i nawet z GTK4 wciąż nie ma na chwilę obecną realnego, szeroko obsługiwanego rozwiązania. Ręczne zarządzanie profilami barwnymi w Anselu działa, dopóki kompozytory same nie zaczną aktywnie zarządzać kolorami okien aplikacji : wówczas GTK3 nie oferuje żadnego sposobu na oznaczenie okna jako „już zarządzanego kolorami", aby zapobiec dalszemu szkodzeniu przez kompozytor. Zamiast tego podwoi konwersje przestrzeni barwnych, które już wykonaliśmy wewnętrznie, i zepsuje kolory w sposób, który tylko eksperci będą w stanie dostrzec. Na szczęście dla nas, na połowę 2026 roku, żaden kompozytor nie jest w stanie niczym zarządzać kolorami.
W każdym razie ręczne konwersje przestrzeni barwnych mogą być wykonane tylko na powierzchniach obrazów, które malujemy w oknie aplikacji Ansel. Nie mamy żadnej kontroli nad kolorami elementów sterujących GUI zdefiniowanymi w arkuszu stylów motywu (ansel.css) i obsługiwanymi bezpośrednio przez widżety GTK, które są niejawnie w sRGB (zgodnie ze standardem CSS). Oznacza to, że kolory GUI zawsze będą wyglądać na przesycone, jeśli natywny gamut Twojego monitora jest większy niż sRGB, w porównaniu z tym, jakie mają być.
Sprawdź, czy obsługa HDR jest wyłączona
Wayland obsługuje teraz możliwości HDR poprzez manipulowanie podświetleniem wyświetlacza. Chociaż Ansel wyprowadza stare dobre 8-bitowe RGB i nie powinien uruchamiać mechanizmów HDR, HDR nie jest częścią ICC v2 ani v4 i nie sposób przewidzieć, jak ta funkcja wpłynęłaby na odpowiedź tonalną. Może być nieszkodliwa, ale dopóki nie zostanie to dokładnie zaudytowane, bezpieczną drogą jest pozostawienie HDR wyłączonego.
Sprawdź, czy używasz Xorg
Poważnie, po prostu nie używaj Waylanda do fotografii.
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. ↩︎