Systémy správy barev v Linuxu

Článek poskytne základní informace o colord, Oyranos, Argyll CMS a XICC a pomůže uživateli zorientovat se v aktuálním stavu správy barev v Linuxu.

EDIT 02/2018: Stále se prakticky nic nezměnilo: colord se pomalu stává standardem, Oyranos nejspíše zůstává teoretickým konceptem. CUPS prý snad ve specifických situacích umí konvertovat mezi profily (ze zdrojového „vloženého“ při tisku v PDF do cílového dle nastavení v colord podle tiskárny), ale asi jen v myslích vývojářů. A používám GNOME 3, zatím na Xorg, neb Wayland se nezdá býti stabilním.

EDIT 12/2016: Článek původně vznikl v srpnu 2014. Bohužel se však od té doby moc nezměnilo (viz souhrn na konci článku)…

Nejdříve přehled konceptů:

  • XICC – program pro příkazový řádek (xicc) a specifikace _ICC_PROFILE umožňující grafickým aplikacím zjistit aktuální barvový prostor (profil ICC) displeje.
  • Xcm – (zatím pouze návrh specifikace) obdoba XICC, týká se tedy jen displejů. Narozdíl od XICC umožňuje nastavit různé barvové prostory jednotlivým částem displeje (oknu).
  • colord – systémový démon, který udržuje databázi připojených zařízení (displeje, tiskárny) a jim přiřazených profilů ICC. Rozeznání displejů má má na starosti front-end (uživatelské rozhraní), pro KDE to je colord-kde, v GNOME je již součástí Ovládacího panelu a pro ostatní desktopová prostředí by mělo fungovat colord-gtk. případně xiccd. Uvedené frontendy se obvykle postarají o načtení VCGT a _ICC_PROFILE.
  • Oyranos – systém pro správu barev. Obdobně jako colord udržuje databázi připojených zařízení a odpovídajících profilů ICC. Pro KDE je front-end Kolor Manager (ten dává smysl jen pro použití s Xcm), případně sada programů pro příkazovou řádku (ta podporuje XICC).
  • Argyll CMS – sada různých programů pro příkazovou řádku umožňující kalibraci a charakterizaci nejen displeje, načtení kalibrace (VCGT) a profilu do _ICC_PROFILE.
  • xcalib – samostatný program umožňující modifikaci LUT grafické karty dle informací uložených ve VCTG profilu ICC. Uvádím jej jen pro doplnění, neb se zřejmě jedná o nejstarší implementaci a nedělá nic jiného než právě toto.

Zatímco xicc, xcalib a dispwin (z Argyll CMS) se týkají jen displeje, colord a Oyranos mají širší záběr a jsou to dva hlavní soupeřící koncepty o správu barev v prostředí X.Org.

Systémem správy barev se rozumí systém, který udržuje informace o zařízeních pracujících s barvou (vstupní i výstupní) a odpovídajících profilech ICC popisujících jejich vlastnosti. Současně může udržovat i ostatní informace použitelné při správě barev (záměry transformace pro displej, soft-proof, hard-proof, výchozí profily pro obrázky, výchozí pracovní prostor pro editaci, atd.).

Systém správy barev však neprovádí transformace mezi jednotlivými barvovými prostory. To mají na starosti aplikace samotné (darktable, GIMP), případně tiskové systémy (CUPS) či správci oken (KWin, Compiz). Komunikace mezi aplikacemi a systémem správy barev obvykle probíhá prostřednictvím D-Bus, atomů v X, API knihoven či pomocí samostatných programů. Pro samotný výpočet transformace barev uvedené aplikace nejčastěji využívají knihovnu Little CMS.

XICC: _ICC_PROFILE a VCGT

Historicky prvním způsobem, jak univerzálně sdělit grafickým aplikacím, jaký profil ICC je přiřazen příslušnému monitoru, je specifikace X atomu _ICC_PROFILE, tento prvek obsahuje vlastní profil ICC. Na příkazové řádce můžete zkontrolovat jeho existenci:

$ xprop -root | grep "_ICC_PROFILE"
_ICC_PROFILE(CARDINAL) = 0, 0, 27, 10, 108, 99, 109, 115, 2, 48, 0, 0, 109,
110, 116, 114, 82, 71, 66, 32, 88, 89, 90, 32, 7, 212, 0, 8, 0, 13, 0, 12, 
0, 18, 0, 6, 97, 99, 115, 112, 77, 83, 70, 84, 0, 0, 0, 0, 108, 99, 109, 1
15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 246, 214, 0, 1, 
0, 0, 0, 0, 211, 45, 108, 99, 109, 115, 127, 179, 13, 104, 139, 248, 45, 5
0, 160, 231, 72, 218, 243, 219, 169, 93, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 12, 100, 109, 
110, 100, 0, 0, 1, 20, 0, 0, 0, 106, 100, 101, ... (zkráceno) ...

Specifikace XICC umožňuje nastavit odlišný profil ICC pro jednotlivé monitory. Uživatelská aplikace (GIMP, EoG, darktable) tedy nemusí hledat profil ICC monitoru kdesi v souborovém systému, prostě se dotáže X serveru (obvykle je označeno „použít systémový profil“).

Na uživateli bylo, aby se postaral o načtení _ICC_PROFILE při spuštění desktopového prostředí. Dříve se to řešilo pomocí samostatného programu xicc, dnes to již zvládá široká paleta programů, případně je to součástí desktopového prostředí.

Protože displej je nanejvýše vhodné před charakterizací kalibrovat (jak hardwarově: jas, kontrast, gamma, bílý bod pomocí OSD displeje; tak i softwarově pomocí modifikace LUT grafické karty), je nutné před používáním profilu uvést displej do onoho kalibrovaného stavu.

Uvedené koncepty správy barev neumějí aktivně komunikovat přímo s interním hardware displeje (to obvykle zvládají jen aplikace poskytnuté výrobcem daného monitoru a ty existují jen pro MS Windows a občas pro OS X), tj. první krok (zachování jasu, kontrastu, gamma, bílého bodu) je na uživateli – pokud jinak nastaví monitor, systém správy barev se nemá šanci to dozvědět a dříve vytvořený profil ICC bude chybný.

Druhá, softwarová, část kalibrace pomocí modifikace LUT grafické karty je obvykle uložena v tzv. VCGT (video card gamma table) štítku v samotném souboru s profilem ICC displeje. Při spuštění desktopového prostředí je tedy nutné načíst VCGT do LUT tabulky – dříve se o to musel postarat uživatel pomocí programu xcalib, dnes to opět zvládá více programů a děje se tak automaticky při nastavování _ICC_PROFILE.

Pokud chce uživatel ověřit, zda VCGT byl do LUT grafické karty načten, může použít program dispwin (Argyll CMS):

$ dispwin -s current.lut && less current.lut
CAL    

DESCRIPTOR "Argyll Device Calibration Curves"
ORIGINATOR "Argyll synthcal"
CREATED "Sat Aug 23 14:27:51 2014"
KEYWORD "DEVICE_CLASS"
DEVICE_CLASS "DISPLAY"
KEYWORD "COLOR_REP"
COLOR_REP "RGB"

KEYWORD "RGB_I"
NUMBER_OF_FIELDS 4
BEGIN_DATA_FORMAT
RGB_I RGB_R RGB_G RGB_B 
END_DATA_FORMAT

NUMBER_OF_SETS 256
BEGIN_DATA
0.00000 0.0301823 0.0298009 0.0223850 
3.92157e-03 0.0341497 0.0337072 0.0268864 
7.84314e-03 0.0380407 0.0375677 0.0312963 
0.0117647 0.0418708 0.0413519 0.0356298 
... (zkráceno) ...
0.988235 0.988434 0.983459 0.978225 
0.992157 0.991974 0.986862 0.982010 
0.996078 0.995529 0.990249 0.985809 
1.00000 0.999084 0.993652 0.989593 
END_DATA

Pokud by byla LUT neupravená (tj. lineární), byly by hodnoty R, G a B v jednotlivých řádcích shodné a rovné indexu v prvním sloupci:

BEGIN_DATA
0.00000 0.00000 0.00000 0.00000 
3.92157e-03 3.92157e-03 3.92157e-03 3.92157e-03 
7.84314e-03 7.84314e-03 7.84314e-03 7.84314e-03 
0.0117647 0.0117647 0.0117647 0.0117647 
0.0156863 0.0156863 0.0156863 0.0156863 
0.0196078 0.0196078 0.0196078 0.0196078 
0.0235294 0.0235294 0.0235294 0.0235294 
0.0274510 0.0274510 0.0274510 0.0274510 
... (zkráceno) ...

Mimochodem, modifikace LUT pomocí VCGT je jen sofistikovanější obdoba úpravy gama křivky pro X server (/etc/X11/xorg.conf či příkaz xgamma či příkaz xrand) nebo frontendy téhož (nVidia Settings, ovládací panely v KDE či GNOME). Používáte-li jakýkoliv systém správy barev, je ruční korekce gama nesmyslná, protože přepíše VCGT (LUT) nastavenou z profilu ICC.

colord

colord je výsledkem procesu započatého programem Gnome Color Manager, který uživateli umožnil přiřadit připojenému displeji nějaký profil ICC, později přibyla možnost jednoduchým postupem kalibrovat displej a vytvořit profil ICC, a ještě později bylo možné charakterizovat i scanner či fotoaparát.

Gnome Color Manager se postaral i o načtení VCGT a _ICC_PROFILE při přihlášení uživatele – a to naprosto transparentně: používal-li uživatel více displejů, načetl se správný profil ICC dle momentálně připojeného displeje.

Jak název napovídá, program byl primárně určen pro desktopové prostředí GNOME a teprve později došlo k rozdělení na back-end odpoutaný od konkrétního desktopového prostředí (colord je hostovaný na freedesktop.org), modul „Colors“ v ovládacím panelu GNOME (GUI pro přiřazování profilů) a očesaný Gnome Color Manager (GUI pro kalibraci).

Postupem času přibyly front-endy pro Qt (colord-kde), pro GTK bez závislostí GNOME (colord-gtk) či obecné xiccd. Tyto frontendy pouze zobrazují připojená zařízení a jejich profily, umožňují přiřadit jiný profil a při spuštění se postarají o načtení VCGT a _ICC_PROFILE.

Některé front-endy umí spustit Gnome Color Manager, který uživatele provede kalibrací a charakterizací displeje a současně nastaví nově vytvořený profil příslušnému displeji. Vzhledem k existenci systémového démona colord je možné „nainstalovat“ daný profil, aby byl viditelný pro všechny uživatele používající počítač – ten již nemusí opět kalibrovat a charakterizovat displej, stačí si profil vybrat ze seznamu a přiřadit displeji.

V případě, že uživatel nevytvořil či nepřiřadil žádný profil ICC připojenému displeji, vytvoří automaticky generický profil dle EDID displeje (poskytuje-li EDID informace o barvovém prostoru monitoru, tato vlastnost závisí na výrobci).

Je důležité zmínit, že v současné době pravděpodobně žádná uživatelská aplikace nekomunikuje přímo s colord. Grafické aplikace obvykle spoléhají na starší implementaci _ICC_PROFILE, což však nijak nesnižuje přínos colord.

Dlužno dodat, že informace o profilech ostatních zařízení (fotoaparát, skener, web kamera, tiskárna) sice může být v colord uložena, ale zatím ji žádné programy nevyužívají. Na světlo světa se snad pomalu dere jen tiskový server CUPS, který by využil profil tiskárny. (Tedy pro situace, kdy aplikace při tisku nechce či neumí transformovat barvy a ponechá to na tiskovém serveru.)

Oyranos

Koncept je starší než colord, nicméně nikdy se mu nedostalo širší pozornosti z řad vývojářů či uživatelů a tuším, že je odsouzen k zániku. V současné době je plně funkční a v některých oblastech vyspělejší než colord – a to díky implementaci Xcm pro správce oken Compiz či KWin.

Systém správy barev funguje obdobně jako u colord – udržuje databázi zařízení (pouze však displejů) a jim přiřazených profilů. Sám umí též vytvořit generický profil dle EDID displeje.

Součástí balíku programů je i program pro příkazovou řádku oyranos-monitor, který lze použít pro načtení VCGT a _ICC_PROFILE.

Od colord se funkčně liší tím, že Oyranos spravuje informace o alternativních scénářích používání počítače: pro každou oblast použití (politika pre-press, photographer, office) udržuje odděleně informace o výchozích profilech ICC pro různé situace a informace o záměrech pro transformaci. Více napoví snímky obrazovky:

Koncept předpokládá, že uživatel před započetím práce zvolí příslušný scénář používání (policy) a příslušné programy (grafické editory) se dotáží Oyranosu na výchozí nastavení týkající se správy barev. Oyranos sám opět žádné barvové transformace neprovádí. Výhoda pro uživatele je úspora času a standardní nastavení napříč aplikacemi.

V praxi však existuje pouze proof-of-concept: modifikovaný grafický editor CinePaint. CinePaint je již mnoho let nevyvíjený fork GIMPu (před deseti lety byl jedinečným kouskem svého druhu, dnes již patří spíše na skládku), jiné vývojáře Oyranos nezaujal.

Vývojář Oyranosu však přinesl i koncept správy barev v X (navrhovaná specifikace Xcm – X Color Management), která se liší od XICC. Na rozdíl od výše uvedeného atomu _ICC_PROFILE, tato implementace umožňuje přiřadit různým částem obrazovky různé profily ICC.

To přináší zjevnou výhodu: správce oken se postará o správné zobrazení barev aplikací, které přímo nepodporují správu barev (a obvykle tiše předpokládají, že monitor odpovídá standardu sRGB) a ignoruje okna či části oken, u kterých se o transformaci do barvového prostoru displeje stará sama aplikace (typicky grafické editory či prohlížeče). Říká se tomu opt-out colour management.

Ke komunikaci s grafickým editorem však již nelze použít atom _ICC_PROFILE, neb ten platí pouze pro celou obrazovku. Tzn., že aplikace by v ideálním případě měla podporovat nejen stávající koncept _ICC_PROFILE (pro zpětnou kompatibilitu), ale i navrhovanou specifikaci Xcm – pomocí API libXcm (či D-Bus?) by aplikace řekla správci oken, aby určitou část obrazovky (typicky část okna s náhledem obrázku) zobrazil bez další transformace barev. Fungovalo by to i v případě, kdy polovina obrázku by byla zobrazena na jednom monitoru a druhá polovina na jiném monitoru.

Potíž je ovšem v tom, že žádná aplikace Xcm nepodporuje a asi už ani nebude – blíží se totiž Wayland (náhrada X.org), která bude celoobrazovkovou správu barev implementovat po svém. Ubuntu navíc koketuje s Mir(em), což je další alternativa k Waylandu a X.org.

V současné době je Xcm implementováno pouze pro dva spráce oken:

  • KWin v režimu OpenGL ve spolupráci s Kolor Managerem a Oyranosem;
  • Compiz (vyžaduje OpenGL) prostřednictvím barvového serveru CompIcc a Oyranosu.

KWin lze použít jen v KDE, zatímco Compiz teoreticky funguje v každém desktopovém prostředí (vč. KDE). Vadou na kráse je, že Compiz je již nevyvíjený správce oken, takže nepřibývají nové vlastnosti. Výpočet transformace mezi prostory probíhá na grafické kartě, nezatěžuje procesor.

Prakticky to funguje tak, že pro zpětnou kompatibilitu (pro aplikace nepodporující Xcm) manažer oken uloží barvový prostor sRGB do atomu _ICC_PROFILE. Aplikace, které nepodporují správu barev žádnou transformaci barev neprovádějí. Aplikace s podporou XICC se domnívají, že barvový prostor monitoru je sRGB a transformují obrázky do sRGB. Správce oken poté vezme celou obrazovku (v prostoru sRGB) a transformuje ji do skutečného barvového prostoru displeje (dle databáze Oyranos).

Koncept je to skvělý, ale kvůli chybějící podpoře aplikacemi naráží v praxi na limity: kdo používá displej s velkým gamutem (AdobeRGB či větší), tak bude ochuzen o všechny barvy přesahující prostor sRGB. Displej se tedy bude chovat jako by odpovídal standardu sRGB… Takže prakticky je to tedy nasaditelné spíše na klasických monitorech s barvovým prostorem blízkým nebo menším než sRGB.

Lze to obejít tím, že před prací s obrázky ve velkých barvových prostorech (AdobeRGB, ProPhotoRGB, camera RAW) uživatel celoobrazovkou správu barev dočasně vypne… Pokud počítač používají i ostatní uživatelé, kteří neřeší editaci fotografií, tak nejspíše více ocení fakt, že červené a zelené ikonky na ně tolik agresivně nezáří a přitom není nutné manipulovat s nastavením displeje (např. přepínat mezi nativním zobrazením a emulací sRGB).

Argyll CMS

Argyll CMS je široce rozmáchlý projekt zahrnující modul správy barev pro transformace mezi barvovými prostory, nástroje pro vytváření profilů a kalibraci (monitorů, tiskáren, fotoaparátů, skenerů, atd.), správu profilů ICC pro připojené monitory a spoustu dalších nástrojů pro testování barvových transformací.

Narozdíl od colord či Oyranosu není přímo integrován do žádného desktopového prostředí, nenabízí knihovny pro přímou komunikaci přes C  či jiné API.

Zato však dokáže obsluhovat většinu kalibračních sond (kolorimetrů, spektrofotometrů) na trhu a je proto využíván např. dispcalGUI (pouze pro displeje) a částečně i Gnome Color Managerem.

Pokud se uživatel rozhodne ignorovat colord i Oyranos, může pro načítání VCGT a _ICC_PROFILE využít program dispwin. Výhodou oproti „hloupým“ programům xicc a xcalib je v tom, že dispwin umí zjistit typ připojeného displeje a načte ten správný profil. Volitelně může dispwin běžet i na pozadí (a sledovat změny v připojených monitorech).

Nevýhodou může být, že jednotlivé programy balíku Argyll CMS jsou jen pro příkazovou řádku. Pro kalibraci displeje lze však využít grafické rozhraní dispcalGUI (což je front-end pro dispcal a dispwin).

Výhodou Argyll CMS (a dispcalGUI) je, že funguje i v OS X či MS Windows.

CMS zatím jen pro displeje

V současné době (2014) je zřejmě nejrozumnější využívat colord s nějakým front-endem – projekt je neustále vyvíjen (volnočasová aktivita zaměstnance Red Hatu, který mimochodem vyrábí levný kolorimetr ColorHUG) a vzhledem k začlenění do GNOME má i širší podporu napříč distribucemi.

Pokud se nebojíte příkazové řádky a ručního nastavování automaticky spouštěných programů při přihlášení do desktopového prostředí, lze na podobné úrovni použít Argyll CMS (kalibrace a charakterizace pomocí dispcal, načítání pomocí dispwin).

Pokud navíc toužíte po celoobrazovkové transformaci barev, pak jedině Oyranos + KWin nebo Compiz, bohužel s výše uvedenými nedostatky.

Ač záběr systému správy barev je širší, v současné době jsou prakticky využitelné pouze pro automatizaci správy barev pro zobrazování na displeji. Ostatní oblasti použití (výchozí profily, tisk, záměry transformace) zůstávají na možnostech a schopnostech jednotlivých aplikací.

Tiskový server CUPS již podporuje profily tiskáren dodané přímo autory ovladačů, bohužel zatím je to funkční jen pro Mac OS X a pro Linux nikoliv, zřejmě z důvodů neexistující podpůrné infrastruktury (v současné době probíhá dolaďování PDF workflow vč. přiřazení profilu, je třeba pozměnit tiskové dialogy, aby šla správa barev vypnout pro účely kalibrace, atd.).

A nakonec malá poznámka: máte-li nainstalováno současně více aplikací pro správu barev (Argyll CMS, colord, Oyranos, dispcalGUI), dejte si hodně velký pozor, aby

  • buď měly všechny nastaven tentýž profil ICC displeje
  • nebo se při přihlášení do X.org spouštěla pouze jedna z nich.

To, že se VCGT a _ICC_PROFILE načte opakovaně za sebou ničemu nevadí, vyhrává ten posledně načtený.

Pro kalibraci a charakterizaci displeje a taktéž pro nastavení již vytvořeného profilu ICC je celkem ideální používat důsledně jen a pouze dispcalGUI (tlačítko: instalovat profil), on se již postará o nastavení profilu ve všech aplikacích CMS, které najde.

A co na to já?

V současné době používám DELL U2713H:

  • 10-bitový vstup, 14-bitová interní LUT, 8-bitový panel + FRC (tj. vizuálně blízko 10-bitovému panelu);
  • možnost emulace sRGB a AdobeRGB;
  • možnost uložení dvou uživatelských kalibrací, ale program pro kalibraci funguje jen ve Windows a co je horší, pouze s kolorimetrem Display i1 Pro nebo spektrofotometrem i1 Pro, a co je idiotské, že program neumí nastavit cílovou gama;
  • možnost volby základních parametrů pomocí tlačítek na displeji (využitelné je pouze jas a vyvážení bílého bodu pomocí R, G, B), modifikace gamma však chybí.
  • z nějakého záhadného důvodu má displej nativní gama kolem 2,7 v režimu „PC“ a cca 2,1 v režimu „MAC“;
  • nakonec něco trochu lepšího: lze uživatelsky definovat 3 tlačítka, takže přepínat např. mezi emulací AdobeRGB a nativním barvovým prostorem je celkem pohodlné.

Kdysi jsem doufal, že se mi podaří používat displej s grafickou kartou nVidia GTX 750 Ti v režimu Deep Colour, tedy s podporou 10-bitové hloubky na jednotlivé kanály. Zatím jsem však cíle nedosáhl, takže jsem mohl klidně pořídit levnější 8-bitovou variantu…

Dále do hry vstupuje více faktorů:

  • Počítač užívá více uživatelů, fotografie však zpracovávám pouze já.
  • U2713H v nativním barvovém prostoru má velmi syté barvy, hlavně červenou – bez celoobrazovkové správy barev se na to nedá koukat.
  • Většinu fotografií, které nejsou určeny pro tisk, ukládám v barvovém prostoru sRGB.

Původní záměr byl nechat U2713H v nativním barvovém prostoru a všem uživatelům aktivovat celoobrazovkou správu barev v KDE + KWin. Pro situace, kdy bych chtěl pracovat s plným gamutem displeje (darktable, Krita, CinePaint – má to smysl jen pro snímky s 16-bitovou barevnou hloubkou) bych celoobrazovkou korekci barev vypínal pomocí skriptu spouštějícího uvedené programy (má to své mouchy, viz bug 313103 a 338683).

Vadí mi ovšem skutečnost, že U2713H má dosti velký gamut a používám jej jen s 8-bitovou barevnou hloubkou na kanál. Tzn., že pokud např. kanál červené v rozsahu celočíselných hodnot 0 – 255 má pokrýt velký rozsah odstínů, celkem vzroste riziko posterizace.

Pokud navíc displej ponechám v nativním barvovém prostoru a softwarově gamut natvrdo omezím na sRGB (dle výše uvedené implementace Xcm v KWinu) dojde k následujícímu:

Prostor obrázku v editoru (sRGB, AdobeRGB či jiný).
|
\/
Transformace do sRGB
(dle Xcm pro aplikace bez podpory Xcm – tj. prakticky pro všechny aplikace).
|
\/
Transformace do nativního prostoru monitoru.

Tedy konkrétně:

  • Nechám-li monitor v režimu emulace sRGB, bude RGB 0,0,0 černá barva, RGB 255,0,0 maximální červená (dle prostoru sRGB) – mám tedy k dispozici 256 odstínů jedné barvy.
  • Nechám-li monitor v nativním režimu, bude RGB 0,0,0 černá barva a RGB 255,0,0 hodně sytá červená (dle prostoru monitoru – porovnání s AdobeRGB a sRGB viz obrázky níže). Tady už hrozí o něco větší posterizace, ale jsem ochoten ji akceptovat výměnou za zobrazení sytějších barev.
  • Z toho plyne, že budu-li chtít zobrazit maximálně sytou červenou dle prostoru sRGB (omezení dané KWinem), pak to nebude na výstupu na monitor kódováno RGB 255,0,0, ale konrétně  RGB 213,57,22. (výpočty zvládne program icclu z balíku Argyll CMS).
  • Jinými slovy, místo původních 256 úrovní odstínů červené budu mít k dispozici jen 214 a plnou červenou maximálně na úrovni sytosti barvového prostoru sRGB.

To už však nedává smysl, z celkem drahého displeje bych udělal značně low-endový kousek.

Pro bližší představu uvádím i přepočty pro červený, zelený i modrý kanál (přepočet probíhá transformací RGB -> MatrixFwd -> XYZ -> Lut -> RGB):

    [sRGB]             Dell U2713H
 255   0   0   ->   213.0  56.6  22.3
   0 255   0   ->   148.5 248.8  37.6
   0   0 255   ->     2.8  17.2 250.7

A ukázku ztrátu rozlišení (tj. původně dva odlišné odstíny splynou v jeden):

    [sRGB]             Dell U2713H      ->  Dell U2713H 8-bit
 127  10  10   ->   103.4  25.3  14.1   ->    103  25  14
 126  10  10   ->   102.5  25.1  14.1   ->    103  25  14

 255 206   0                ->                241 207  39
 255 207   0                ->                241 207  39

 255 104   0                ->                219 114  26
 255 105   0                ->                219 114  26

Pro představu následuje porovnání velikosti gamutu na „podkově“ CIE XY: barevnou linkou je zobrazen nativní prostor displeje, přerušovanou čarou sRGB:

Barevnou linkou je zobrazen nativní prostor displeje, přerušovanou čarou AdobeRGB 1998:

Cesta plná kompromisů

Nakonec i z pohledu praktického zvítězila následující konfigurace:

  • display nastaven v režimu emulace AdobeRGB
    (barvy jsou sytější než sRGB, ale dá se na to koukat), tento prostor pokrývá tisknutelné barvy na běžných tiskárnách (laby, inkoustové), byť high-endové tiskárny mají rozsah trochu větší;
  • celoobrazovkou správu barev nepoužívám
    (snad časem, až budou odstraněny výše zmíněné mouchy v KWin; alternativní Compiz je zastaralý a nevyhovuje mi);
  • colord + colord-kde se stará o načtení profilu pro display pro všechny uživatele;
  • kalibruji a charakterizuji display pomocí dispcalGUI,
    ten se postará o instalaci profilu pro dispwin (Argyll CMS), colord a oyranos a při spouštění v mém uživatelském účtu tento profil ICC načte do VCGT a _ICC_PROFILE, což současně provede i colord-kde. Redundance v tomto případně nevadí;
  • mám vytvořeny varianty profilů ICC pro emulovaný prostor AdobeRGB s kompenzací dle úrovně okolního osvětlení
    (od 69 luxů do 500 luxů, kompenzace se provádí změnou gama kalibrační křivky VCGT) a příslušný profil ICC volím prostřednictvím dispcalGUI (opětovná instalace profilu vždy nastaví tento profil jako výchozí v colord, oyranos i Argyll CMS – tedy bez starostí o případné konflikty mezi systémy správy barev);
  • budu-li chtít výjimečně pracovat v plném gamutu displeje, tak jej ručně přepnu a v dispcalGUI nastavím příslušný profil;
  • zatím pro účely občasného testování ponechávám nainstalovaný Oyranos + Kolor Manager – není-li aktivní celoobrazovková správa barev, tyto aplikace nijak nezasahují do VCGT ani _ICC_PROFILE.

A nepříliš vzdálená budoucnost? Pevně doufám, že časem budu schopen využít 10-bitovou barevnou hloubku na kanál pro zobrazení na displeji, pak budu s radostí využívat celoobrazovkovou správu barev (s jejím občasným vypnutím pro darktable, CinePaint, Kritu).

Chce se mi věřit, že Wayland bude mít celoobrazovkovou správu barev vyřešenu od základu a aplikace to budou bezproblémově podporovat. Doufám, že se toho dožiji…

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..