Linux è ancora ampiamente in ritardo rispetto a MacOS e persino a Windows quando si tratta di garantire la coerenza dei colori visualizzati sul monitor. L’adozione forzata su larga scala del server grafico Wayland nella maggior parte delle distribuzioni Linux ha danneggiato ulteriormente questa situazione, poiché la gestione del colore è stata a lungo rifiutata dagli sviluppatori di Wayland. La specifica per un CMS in Wayland è stata finalmente redatta nel 2020 e il codice è stato integrato a monte in Wayland nel 2025, da collaboratori esterni, e dopo una lunga battaglia degli sviluppatori dei precedenti software CMS contro gli sviluppatori storici di Wayland.1 Da allora, lo stato del supporto CMS è molto altalenante tra i vari ambienti desktop e le varie distribuzioni. Eppure, i risultati preliminari della telemetria di Ansel mostrano un’adozione di Wayland del 67 % tra gli utenti di Ansel.
Non dovresti usare Ansel, né alcun altro software di elaborazione delle immagini, su Wayland.
Note
La situazione del CMS di Wayland varia notevolmente a seconda della distribuzione e dell’ambiente desktop, ed evolverà in futuro. Piuttosto che un quadro completo (presto superato) di ciò che funziona e ciò che non funziona, presenterò la lista di controllo che deve essere convalidata per prendere in considerazione l’uso di Wayland.TL;DR: perché non usare Wayland su Linux ?
Perché lo stesso autore del sistema di gestione del colore di Wayland ha detto che è ben lungi dall’essere pronto per l’uso professionale in fotografia e video.1
Per l’uso consumer e di intrattenimento, puoi verificare lo stato del supporto del CMS di Wayland da parte del tuo compositor desktop sulla documentazione di Wayland .
Il problema
La maggior parte (se non tutti) gli schermi dei portatili e molti monitor di livello consumer hanno un punto di bianco molto più blu dei 6500 K standard, in un intervallo compreso tra 6800 K e 7200 K. Per correggere ciò, il metodo storico è calibrare lo schermo e scrivere le curve di calibrazione nella Video Card Gamma Table (VCGT) . La VCGT è al contempo:
- un campo dati speciale all’interno dei profili ICC,
- una regione di memoria speciale sulla tua GPU.
All’avvio della sessione Linux, un qualche software legge la VCGT da un profilo ICC e la carica nella memoria video vera e propria. Così l’intero desktop avrebbe il suo punto di bianco e la sua curva di contrasto corretti in un unico passaggio pigro, che le applicazioni fossero “gestite a colori” o meno.
In seguito, molte applet chiamate “night color” o “redshift” hanno manomesso la VCGT per spostare i colori verso l’ambra la sera e di notte, poiché è noto che la luce blu(astra) disturba i ritmi del sonno, e sebbene ciò sia ottimo per il ritmo circadiano, aggiunge uno strato di casualità nella pipeline del colore. Inoltre, la VCGT poteva andare persa senza preavviso al ripristino dalla modalità standby, e diverse applicazioni potevano gareggiare per essere l’ultima a sovrascriverla. L’ascesa dei sistemi a doppia GPU (dedicata + integrata) non ha fatto nulla per migliorare l’affidabilità della pipeline del colore, e il driver proprietario Nvidia è ancora l’unico che permette di visualizzare in anteprima la VCGT.
Ma il punto fondamentale è: hai bisogno di un qualche tipo di metodo a livello di sistema per caricare una VCGT che normalizzi il punto di bianco,2 e Xorg/X11 aveva colord per annunciare globalmente un profilo di display di sistema che le applicazioni potevano recuperare.
Oltre alla VCGT, che contiene la calibrazione, si aggiunge la profilazione, che corregge le primarie di colore native del display, in modo che le terne RGB corrispondano allo spettro luminoso a cui sono associate. In breve:
- fissare il punto di bianco del display a 6500 K e linearizzare la risposta in luminosità è la prima fase (calibrazione),
- fissare le primarie di colore del display per ridurre le deviazioni di tinta e saturazione è la seconda fase (profilazione).
La profilazione è tipicamente una matrice di colore 3×3, a volte con curve o gamma aggiuntive, ma può anche essere una LUT (sconsigliata in Ansel).
Quando un fotografo “calibra” il proprio display, in realtà entrambe le fasi vengono di solito eseguite silenziosamente e salvate nello stesso profilo ICC. C’è un modo, in particolare in Display Cal, per disabilitare la calibrazione tramite la VCGT, che viene quindi incorporata nella profilazione come un blocco unico, ma questa è generalmente una pessima idea perché in tal caso i colori del tema della GUI sono esclusi dall’adattamento del punto di bianco anche su Xorg.
Note
Contrariamente a una credenza diffusa, i profili ICC non sono altro che un descrittore (una sorta di file di metadati), che i programmi veri e propri scelgono di applicare (e scelgono come). Non sono di per sé un software.A livello di applicazione, possiamo applicare solo la fase di profilazione sulle immagini. Questo ha 2 implicazioni :
- La validità cromatica della fase di profilazione dipende dal fatto che la fase di calibrazione sia eseguita correttamente a livello della VCGT. La profilazione diventa imprevedibile e imprecisa senza la sua gemella calibrazione : è una pipeline.
- Non possiamo correggere/gestire i colori della GUI provenienti dal tema dell’applicazione (in particolare: il colore di sfondo) dichiarati nel foglio di stile CSS e passati a Gtk.
Questo è un problema in Ansel perché impostiamo l’intera GUI su un grigio neutro, a scopo di valutazione del colore, e abbiamo bisogno che questo grigio sia a 6500 K, ma anche coerente con il punto di bianco dell’immagine. Quindi abbiamo bisogno di una gestione del colore per l’intero desktop, almeno per la calibrazione, per evitare punti di bianco discordanti tra le finestre. Cosa di cui il progetto iniziale di Wayland esplicitamente dichiara di non doversi occupare, affidandosi agli sviluppatori delle app affinché facciano la cosa giusta (come se…).
E poi, ultimo ma non meno importante, se stai usando più monitor, hai bisogno di un qualche software che mappi un profilo ICC su ciascun monitor, in modo che il CMS possa recuperare il profilo giusto per il monitor su cui si trova la finestra della tua applicazione.3 Cosa che Wayland vieta esplicitamente per ragioni di “sicurezza”.
Cosa devi verificare se usi Wayland
Quanto segue presuppone che tu abbia calibrato e profilato il tuo monitor con un colorimetro, e prodotto un profilo ICC di display che neutralizza le deviazioni di colore del tuo monitor.
- Verifica che ogni monitor abbia la sua calibrazione caricata dal profilo ICC nella VCGT all’avvio di una sessione grafica
- Questa parte sembra essere abbastanza coperta a partire dal 2026, almeno per i principali protagonisti Gnome/KDE Plasma. L’ambiente desktop permette di definire un profilo di sistema che cambierà globalmente il punto di bianco di tutte le applicazioni.
- In caso contrario, il comando
dispwindel softwareargyllcmspermette di caricarlo manualmente, comedispwin -d 1 ~/.local/share/icc/YOUR_DISPLAY_PROFILE.icc. “Basta” scriverne uno script e far avviare lo script automaticamente con la sessione, il che esclude qualsiasi utente non a suo agio con lo scripting. Verifica che ogni monitor sia etichettato con un profilo di colore- Questa parte è esplicitamente rimossa dal protocollo Wayland, quindi alle applicazioni è, per progetto, vietato recuperare informazioni sui display. In particolare, avviare
ansel-cmstestin Wayland restituirà: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 - Questo significa in pratica che il profilo di sistema (predefinito) di Ansel, che dovrebbe essere rilevato automaticamente tramite
colordoxatomsu X11/Xorg, è vuoto/indefinito in ogni momento su Wayland e dovrai:- aggiungere il tuo profilo di display in
~./config/ansel/color/out, - sceglierlo manualmente nel menu globale Display -> Profilo di colore del monitor,
- cambiarlo manualmente se/quando sposti la finestra di Ansel su un monitor diverso.
- aggiungere il tuo profilo di display in
- La mancata esecuzione di questa operazione farà sì che Ansel ricada su sRGB come spazio colore di output. Se il gamut nativo del tuo display è:
- Adobe RGB, allora i colori nella regione verde-ciano appariranno più saturi sullo schermo di quanto non siano nel file,
- Display P3, allora tutti i colori appariranno più saturi sullo schermo di quanto non siano nel file, ma la regione arancione-verde-ciano sarà anche la più problematica.
- Questo problema non ha soluzione all’interno di GTK3, che Ansel usa come toolkit grafico, e persino con GTK4 non esiste ancora, ad oggi, una soluzione praticabile e ampiamente supportata. Gestire manualmente i profili di colore in Ansel funziona finché i compositor non iniziano attivamente a gestire il colore delle finestre delle applicazioni essi stessi : allora GTK3 non offre alcun modo per etichettare una finestra come “già gestita a colori”, così da impedire al compositor di arrecarle ulteriore danno. Esso invece raddoppierà le conversioni di spazio colore che abbiamo già eseguito internamente e falserà i colori in un modo che solo gli esperti saranno in grado di individuare. Fortunatamente per noi, a metà 2026, nessun compositor è in grado di gestire il colore di alcunché.
- In ogni caso, le conversioni manuali di spazio colore possono essere eseguite solo sulle superfici delle immagini che disegniamo nella finestra dell’app Ansel. Non abbiamo alcun controllo sui colori dei controlli della GUI definiti nel foglio di stile del tema (
ansel.css), e gestiti direttamente dai widget GTK, che sono implicitamente sRGB (come da standard CSS). Il che significa che i colori della GUI appariranno sempre sovrasaturi se il gamut nativo del tuo monitor è più ampio di sRGB, rispetto a quello che dovrebbero essere. - Verifica che il supporto HDR sia disabilitato
- Wayland ora supporta le funzionalità HDR manomettendo la retroilluminazione del display. Sebbene Ansel produca in output i buoni vecchi RGB a 8 bit e non dovrebbe attivare i meccanismi HDR, l’HDR non fa parte di ICC v2 o v4 e non c’è modo di sapere come questa funzione influenzerebbe la risposta tonale. Potrebbe essere innocua, ma finché non sarà accuratamente verificata, la strada sicura è mantenere l’HDR disabilitato.
- Verifica che tu stia usando Xorg
- Sul serio, semplicemente non usare Wayland per la fotografia.
Translated from English by : Claude. In case of conflict, inconsistency or error, the English version shall prevail.
Pekka Paalanen, 12 years of incubating Wayland color management, February 2025. URL ↩︎ ↩︎
The contrast/brightness curve is not so much of an issue on LED screens that are, by nature, close to linear. ↩︎
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. ↩︎