Alle Dell UltraSharp schermen die hardwarematige kalibratie ondersteunen hebben ook een LUT. Dat zijn deze schermen:
Op de UP2715K is het een 12-bit LUT, bij de andere 5 schermen is het een 14-bit LUT.
Overigens is deze Eizo zoals je kunt zien niet zo gek veel duurder dan de vergelijkbare U2713H. Het is dan ook een ColorEdge CS model. Deze zijn vooral bedoeld voor de serieuze amateur. De CX modellen zijn voor de semi-pro en de CG modellen voor de pro.
Wat Hans van Eijsden hierboven zegt over de LUT is overigens vooral een marketingverhaaltje, dat niet helemaal juist is. Een paneel wordt digitaal aangestuurd en heeft een eigen bitdiepte per subpixel. Die bitdiepte is 6, 8 of 10 bit bij beeldschermpanelen. Wat betekent dat een subpixel dan 2
6 = 64, 2
8 = 256 of 2
10 = 1024 verschillende niveaus kan weergeven. Aangezien een pixel drie subpixels heeft moet je dat getal tot de derde macht verheffen voor het totale aantal kleuren dat een pixel kan weergeven.
Deze niveaus staan vast. Als je weet wat de bitdiepte van de subpixels is, wat de specificaties van de kleurfilters van de subpixels zijn en wat de specificaties van de backlight zijn, dan kan je op basis daarvan al bepalen welke kleuren een scherm kan weergeven. Het maakt daarvoor niet uit wat voor elektronica er verder nog in het scherm zit en wat voor videokaart je hebt.
De enige uitzondering hierop is de implementatie van FRC (
Frame Rate Control). Dat is een vorm van
dither, alleen niet
in plaats (zoals bijvoorbeeld bij JPEG gebruikt wordt), maar in tijd. Wat dit doet is bij statische content, zoals bij fotobewerking, is de kleur van een pixel bij elk opvolgend frame wisselen om op die manier een tussenliggende waarde te simuleren.
Even een heel erg versimpeld voorbeeld: stel je voor dat je bijvoorbeeld de 9-bit kleur [483;137;501] wilt weergeven in een bepaalde pixel, dan zou het scherm dan tussen de 8-bit kleuren [241;68;250] en [242;69;251] gaan wisselen met elk nieuw frame om die kleur te simuleren.
Dat is meteen ook de enige manier om, perceptueel gezien, meer verschillende kleuren weer te geven dan op basis van de kleurdiepte verwacht zou mogen worden. In feite zijn het nog steeds dezelfde kleuren, maar door het snelle schakelen tussen de twee lijkt het een tussenliggende waarde te hebben die normaal gesproken niet weergegeven zou kunnen worden. Twee nadelen van FRC zijn dat het alleen goed werkt met statische content (maar bij dynamische content, zoals video, is het ook minder nodig) en vooral bij donkere tinten kan je door het schakelen tussen de twee kleuren een flikkering zien. Als je geen fan bent van beeldschermen met
PWM backlight dimming, dan zal je dit al helemaal niks vinden. Want waar PWM op beeldschermen minimaal 175 Hz is (oude CCFL schermen) geeft FRC een flikkering op de paneelfrequentie, dus meestal 60 Hz.
Waar de LUT voor gebruikt wordt is het omzetten van de kleuren zoals die door de videokaart worden uitgestuurd naar de kleuren zoals die op het scherm moeten worden weergegeven. In de LUT staat dus je kalibratie, maar in plaats van formules is het dus een kant en klare tabel. De reden hiervoor is heel simpel: een beeldscherm heeft niet de rekenkracht om voor elke pixel voor elk nieuw frame uit te rekenen wat de juiste waarde moet zijn.
Bij "softwarematige" kalibratie staat alle kalibratie-informatie in het
ICC-profiel. Vervolgens bepaalt je videokaart aan de hand daarvan hoe de kleur van een pixel zoals dat van een programma naar de videokaart gaat moet worden omgezet voor het wordt doorgestuurd naar het scherm.
Bij hardwarematige kalibratie bevat het ICC-profiel niet de volledige kalibratie-informatie. De videokaart past dan alleen maar aan voor
het ingestelde kleurbereik en gamma van het scherm op basis van de het ICC-profiel van de content, wat veel simpelere correcties zijn. Die correctie gaat er van uit dat het scherm een perfect scherm is: als je hebt gecorrigeerd voor gamma en kleurbereik wordt de kleur goed weergegeven. Alleen is geen enkel scherm een perfect scherm, want je hebt ook nog onregelmatige afwijkingen.
Als je een 3D kleurvolume zou opsplitsen in een 3D grid, dan zou bij een perfect scherm elk deeltje een kubus zijn met gelijke afmetingen. In de praktijk heb je echter grid distortion: het zijn geen perfecte kubussen meer en de afmetingen verschillen ook een beetje. Het deel van de correctie dat vervolgens in het scherm wordt gedaan op basis van die LUT is het rechttrekken van dat 3D grid, zodat elke kleur wordt weergegeven zoals bedoeld.
Doordat het scherm niet echt berekent wat het moet worden, maar opzoekt, heeft het nut om een LUT te hebben met een veel hogere bitdiepte dan de kleurdiepte van het paneel. De belangrijkste reden daarvoor is dat hardwarematige gekalibreerde schermen gamut mapping ondersteunen: door middel van de LUT het kleurbereik beperken, ongeacht de kleurinformatie van de content. Hierdoor verschuiven de fysieke RGB-combinaties van het paneel ten opzichte van de RGB-combinaties zoals die zouden moeten zijn voor het kleurbereik dat je weer wilt geven. Doordat er een nagenoeg oneindige hoeveelheid verschillende kleurbereiken ingestelde kunnen worden in de applicatie voor hardwarematige kalibratie heb je dan ook een heel erg grote LUT nodig om te zorgen dat je afrondingsfouten beperkt tot een minimum.
Het voordeel van gamut mapping is dat het voor alle content geldt. Het kleurbereik van veel wide gamut schermen is iets groter dan Adobe RGB. Zou ik het scherm niet kalibreren (en per definitie dan dus ook niet het kleurbereik aanpassen), dan wordt bij alle content zonder kleurprofiel de pixel door het scherm worden weergeven zoals deze door het programma werd opgegeven.
Stel nu echter dat ik het gamut heb gemapped naar Adobe RGB en dat het native kleurbereik van het paneel als volgt is:
Rx = 0,680
Ry = 0,310
Gx = 0,210
Gy = 0,700
Bx = 0,147
By = 0,054
(gamut van LG Display LM270WQ3-SLA1 paneel)
Als een programma dan doorgeeft aan de videokaart dat een bepaalde pixels de RGB-kleur [200;0;0] heeft, dan wordt er van uit gegaan dat dat Rx = 0,640 Ry = 0,330 is van Adobe RGB. Maar het kleurbereik van het scherm is groter dan Adobe RGB dus die [200;0;0] wordt dan met behulp van de LUT omgezet naar [200;55;28], zodat het ook echt als de rode primair van Adobe RGB wordt weergegeven en niet als de rode primair van het paneel zelf.
Maar als je nu een afbeelding opent in Photoshop die als kleurprofiel sRGB heeft toegewezen, dan kan het niet in één keer worden omgezet. De videokaart zet het dan eerst om van sRGB naar Adobe RGB, want die denkt dat het scherm een kleurbereik heeft gelijk aan Adobe RGB op basis van het ICC-profiel van de kalibratie. Vandaar dat ik eerder ook
"het ingestelde..." er bij had gezet, want het gaat dus niet om de native eigenschappen van het scherm.
Laten we dan zeggen dat we de RGB-kleur [135;218;56] hebben in sRGB. Dan maakt de videokaart daar eerst [164;218;73] in Adobe RGB van en vervolgens wordt dat in het scherm op basis van de LUT omgezet naar [163;214;71] voor weergave door het paneel.
Zou je een LUT hebben die maar een bitdiepte heeft van 8 bits, gelijk aan het paneel, dan zou daar best wel eens iets anders uit kunnen komen, doordat het al is omgezet van sRGB naar Adobe RGB. Als je dan Adobe RGB niet heel uitgebreid in die LUT hebt staan krijg je twee keer afronden op hetzelfde aantal significante cijfers als het eindresultaat, want dan een significant verschil kan geven in het eindresultaat.
Om weer terug te komen op het verhaal van Hans van Eijsden: as je een LUT hebt met een lage bitdiepte, zou dat bij vloeiende kleurovergangen voor
extra banding kunnen zorgen. Dus in die zin is het wel waar dat een 16-bit LUT zorgt voor minder banding. Het is alleen niet zo dat het voor minder banding zorgt dan het paneel van zichzelf al heeft. Dat kan je dus alleen, op een verre van ideale manier, bereiken met FRC, maar dus niet met een LUT.