Farbmetrik: Die Sache mit der Helligkeit

0
51

Einleitung

Dieser Artikel bildet den Auftakt für eine lose Reihe von Berichten über farbmetrische Themen. Wir hoffen, damit etwas Licht in teils relativ komplexe Zusammenhänge zu bringen, die, abseits von Publikationen für die grafische Industrie, oft missverstanden werden.

Nachfolgend werden zwei Fragestellungen behandelt

„Warum treten nach Kalibration und Profilierung eines Bildschirms manchmal schon bei einer Profilvalidierung hohe Abweichungen auf?“

„Ist ein CMS in Computerbildschirm, TV oder Beamer ohne Möglichkeit der Beeinflussung der Helligkeitskomponente von Primär- und Sekundärfarben inkomplett bzw. gar fehlerhaft?“

Beide Fragestellungen korrelieren direkt miteinander, auch wenn dies nicht auf den ersten Blick sichtbar ist.

Abweichungen nach Kalibration und Profilierung eines Bildschirms

Zur Beantwortung dieser Frage werfen wir einen Blick auf die Kalibrationsergebnisse des Asus PA246Q. Im „Standard“-Bildmodus führte eine Profilierung (Ziel: Matrix-Profil) und anschließende Validierung zu unauffälligen Ergebnissen. Der im ICC-Profil festgehaltene Monitorzustand (Primärfarben und Gradation für jeden Kanal) entsprach dem Ist-Zustand während der Validierung.

Ganz anders die Situation aus dem „Anwender“-Bildmodus heraus. Hier kam es, unabhängig von Kalibrations- und OSD-Einstellungen, zu erheblichen Abweichungen in der Profivalidierung. Das gleiche Verhalten zeigt der DELL U2410.

Profilvalidierung des Asus PA246Q im "Anwender"-Bildmodus nach erfolgter Kalibrierung
Profilvalidierung des Asus PA246Q im „Anwender“-Bildmodus nach erfolgter Kalibrierung

Drifts des Bildschirms waren nicht ursächlich: Die Messwerte während der Profilierung entsprachen den Messwerten, die im Zuge der Profivalidierung erfasst wurden. Warum kommt es also zu den Abweichungen?

Die Antwort ist simpel: Im ICC-Profil konnte aufgrund starker Nichtlinearitäten der tatsächliche Monitorzustand nicht erfasst werden.

Wichtig: Wenn im Rahmen des Artikels von Linearität gesprochen wird, ist keinesfalls ein lineares Helligkeitsverhalten (Gamma 1.0) gemeint.

Zur genaueren Analyse dienen die aus beiden Bildmodi heraus durchgeführten Durchläufe des UDACT („UGRA-Test“):

„profilierung_standard.pdf“ zeigt keine Auffälligkeiten. Die hohen Abweichungen des Weißpunktes sind dem Umstand geschuldet, dass keine Kalibration erfolgte und der im OSD eingestellte Weißpunkt im Ergebnis weit von der Blackbodykurve entfernt liegt. Wichtig sind die „Profile Quality“ auf Seite 3 und die Vermessung des ugra/ fogra Medienkeils unter Berücksichtigung des Monitorprofils auf Seite 4. Beide Messreihen zeigen keine Auffälligkeiten. Der Bildschirm verhält sich also linear, d.h. mit dem im Profil gespeichert Primärfarben und der Gradation für jeden Kanal ist der Bildschirmzustand korrekt beschrieben und verhält sich auch für Mischfarben anhand dieser Parameter.

„kalibration_anwender.pdf“ weist dagegen starke Abweichungen in den Messreihen auf Seite 3 und 4 auf. Nun hilft ein Blick auf die tatsächlichen Messwerte weiter, die am Ende des UDACT Protokolls (Seite 5) aufgeführt sind. Wir betrachten die Helligkeitskomponenten der Primärfarben (Rot, Grün, Blau). Dargestellt sind die rohen, d.h. noch nicht normalisierten XYZ-Normfarbwerte:

Weiß: 141.9 cd/m²
Rot: 43.96 cd/m²
Grün: 68.96 cd/m²
Blau: 9.59 cd/m²

Rot + Grün + Blau ergeben nur 122.48 cd/m², müssten in Summe aber natürlich die Helligkeit des Weißpunktes erreichen. In „profilierung_standard.pdf ist das auch der Fall:

Weiß: 287.86 cd/m²
Rot: 74.64cd/m²
Grün: 193.61cd/m²
Blau: 19.46 cd/m²

Wichtig: Obwohl die Helligkeitskomponenten der Primärfarben in Addition hier die Helligkeit des Weißpunktes ergeben, könnten sie dennoch nicht stimmig sein (auf die Berechnung des korrekten Helligkeitsanteils gehen wir noch ein), oder sich der Bildschirm bei Mischfarben nichtlinear verhalten. Es handelt sich also um eine notwendige aber nicht hinreichende Bedingung. Die Ergebnisse auf Seite 3 und Seite 4 des UDACT-Protokolls schließen solche Probleme in diesem Fall aber aus. Falls, wie im „Anwender“-Bildmodus, die Summe der Helligkeitskomponenten der Primärfarben nicht der Helligkeit des Weißpunktes entspricht, ist das Bildschirmverhalten in jedem Fall nicht linear.

Die von uns genutzte Kalibrations- und Profilierungslösung (iColor Display3) kann den Bildschirmzustand für den „Anwender“-Bildmodus nach der Kalibration so nicht in das ICC-Profil schreiben. Es wäre defekt. Ein Matrix-Profil setzt lineares Verhalten in Bezug auf die erfassten Parameter voraus. Schließlich sind nicht mehr Informationen als die farbmetrischen Daten der drei Primärfarben und die Gradation für jeden Kanal bekannt. Während der Erzeugung des Profils werden die Messwerte entsprechend „zwangsnormalisiert“ und damit die valide Helligkeitskomponente berechnet. Folglich stimmen in diesem Fall Ist- und Sollzustand nicht mehr überein. Hohe Abweichungen in der Profilvalidierung sind die logische Folge.

Um eine bessere Vorstellung von den Abläufen zu bekommen, vollziehen wir dieses Vorgehen nun schrittweise nach. Ausgangssituation ist der tatsächliche Bildschirmzustand nach erfolgter Kalibrierung aus dem problematischen „Anwender“-Bildmodus heraus.

Achtung: Die dargestellte Nachkommagenauigkeit entspricht nicht immer der Rechengenauigkeit. Beim eigenen Nachrechnen kann es daher zu leichten Verschiebungen kommen.

Ist-Zustand

XYZ-Normfarbwerte (aus kalibration_anwender.pdf)

Rot: 95.03 43.96 2.02
Grün: 21.78 68.96 10.55
Blau: 28.27 9.59 150.05
Weiß: 134.85 141.90 154.58

1. Schritt: Normalisierung in Bezug auf den Weißpunkt

Rot: 0.6697 0.3098 0.0142
Grün: 0.1535 0.4860 0.0743
Blau: 0.1992 0.0676 1.0574
Weiß: 0.9503 1.0 1.0894

2. Schritt: Adaption vom tatsächlichen Weißpunkt nach D50 (Referenzweiß für den ICC-Workflow) mit Bradford

Rot: 0.7083 0.3265 0.0091
Grün: 0.1683 0.4846 0.0618
Blau: 0.1572 0.0548 0.7941
Weiß: 0.9642 1.0 0.8251

Zwischenergebnis: Die Nichtlinearitäten bleiben selbstverständlich nach diesen Schritten weiter bestehen. Rot+Grün+Blau ergeben 0.8659 und nicht 1.

Welche Werte stehen tatsächlich im ICC-Profil?

Rot: 0.58319 0.26888 0.00766
Grün: 0.23550 0.67996 0.08633
Blau: 0.14549 0.05116 0.73090

iColor Display hat die Werte also im Hinblick auf ein unterstellt lineares Verhalten korrigiert. Rot+Grün+Blau ergeben nun 1. Damit können wir an dieser Stelle schon die erwarteten Abweichungen für die Primärfarben im Rahmen der Profivalidierung berechnen. Zu diesem Zweck transformieren wir die XYZ-Normfarbwerte nach Lab. Da bereits ein gemeinsamer Weißpunkt (D50) vorliegt, kann das DeltaE, ohne weitere chromatische Adaption, direkt berechnet werden:

Rot:
Lab (D50) ICC-Profil: 58.870515 100.127374 87.054640
Lab (D50) Ist: 63.876504 106.850648 93.201479
=> Rot 5,17 (dE94)

 

Grün:
Lab (D50) ICC-Profil: 86.004448 -127.132435 81.631083
Lab (D50) Ist: 75.114143 -113.303609 72,791327
=> Grün 11,09 (dE94)

 

Blau:
Lab (D50) ICC-Profil: 27.062724 80.573136 -117.824640
Lab (D50) Ist: 28.060712 83.229534 -121.487694
=> Blau 1,17 (dE94)

Das entspricht tatsächlich etwa den in Abbildung 1 zu sehenden Werten.

Wie ermittelt iColor die in das Profil geschriebenen XYZ-Normfarbwerte konkret?

Vergegenwärtigen wir uns noch einmal die Ausgangslage nach Schritt 2:

Rot: 0.7083 0.3265 0.0091
Grün: 0.1683 0.4846 0.0618
Blau: 0.1572 0.0548 0.7941
Weiß: 0.9642 1.0 0.8251

Das sind die den (nichtlinearen) Bildschirmzustand repräsentierenden XYZ-Normfarbwerte nach Normalisierung und Adaption nach D50.

3. Schritt: Ermittlung der xy(z)-Normfarbwertanteile

Rot: 0,678513 0,312769 (0,008718)
Grün: 0,235483 0,678047 (0,086470)
Blau: 0,156247 0,054468 (0,789285)
Weiß: 0,345678 0,358513 (0,295809)

Die xy-Normfarbwertanteile könnte man nun in die CIE-Normfarbtafel (siehe Abbildung 2) eintragen. Die („falsche“) Helligkeitskomponente ist nicht mehr repräsentiert. Der Farbort gibt nur Auskunft über Farbton und Sättigung.

CIE-Normfarbtafel-Grafik
CIE-Normfarbtafel

4. Schritt: Ermittlung der korrekten Helligkeitskomponente

Unterstellen wir ein lineares Verhalten, können wir die entsprechende Helligkeitskomponente rechnerisch ermitteln. Wir nutzen dabei aus, dass alle drei Primärfarben in Summe Weiß ergeben sollten. Abbildung 3 zeigt den Zusammenhang. In der 3×3 Matrix sind farbig jeweils die entsprechenden Komponenten der Primärfarben in Normfarbwertanteilen dargestellt. Die zweite 3×1 Matrix bezieht sich auf den Weißpunkt. Im Ergebnis (3×1 Matrix ganz links) stehen die korrekten Helligkeitskomponenten der Primärfarben.

Berechnung der Helligkeitskomponente bei gegebenen Primärfarben inkl. Bezugsweiß (in Normfarbwertanteilen)
Berechnung der Helligkeitskomponente bei gegebenen Primärfarben inkl. Bezugsweiß (in Normfarbwertanteilen)

Gefüllt mit den Werten aus dem 3. Schritt, und mit ausgerechneten Brüchen, wird daraus:

Berechnung der Helligkeitskomponente bei gegebenen Primärfarben inkl. Bezugsweiß
Berechnung der Helligkeitskomponente bei gegebenen Primärfarben inkl. Bezugsweiß

Ermittlung der inversen Matrix:

Berechnung der Helligkeitskomponente bei gegebenen Primärfarben inkl. Bezugsweiß
Berechnung der Helligkeitskomponente bei gegebenen Primärfarben inkl. Bezugsweiß

Das Ergebnis

Y(Rot) : 0.27004
Y(Grün) : 0.68114
Y(Blau) : 0.05078

5. Schritt: Anpassung der XYZ-Normfarbwerte (Ist-Zustand)

Wir benötigen noch einmal die XYZ-Normfarbwerte aus Schritt 2:

Rot: 0.7083 0.3265 0.0091
Grün: 0.1683 0.4846 0.0618
Blau: 0.1572 0.0548 0.7941

Ziel sind die in Schritt 4 aufgeführten Helligkeitskomponenten. Fassen wir Rot, Grün und Blau jeweils als Vektor auf, müssen wir also mit folgenden Faktoren multiplizieren:

Rot: 0.827
Grün: 1.401
Blau: 0.927

Damit haben wir endlich unsere „zwangsnormalisierten“ XYZ-Normfarbwerte:

Rot: 0.58582 0.27004 0.00753
Grün: 0.23656 0.68114 0.08686
Blau: 0.14567 0.05078 0.73585

Das entspricht den Werten, die auch iColor in das ICC-Profil geschrieben hat:

Rot: 0.58319 0.26888 0.00766
Grün: 0.23550 0.67996 0.08633
Blau: 0.14549 0.05116 0.73090

Die leichten Abweichungen kommen durch Rundungsfehler und Schwankungen zwischen den zwei Messungen zustande.

Das ICC-Profil ist nun also valide, spiegelt aber natürlich nicht mehr den Ist-Zustand wieder. Ein korrekter Workflow ist so nicht möglich. Im konkreten Fall sollte der „Anwender“-Bildmodus nicht verwendet werden.

Damit ist die erste Frage beantwortet. Auch ganz ohne Drifts des Bildschirms kann es direkt nach der Profilierung zu erheblichen Abweichungen kommen. Der Bildschirmhersteller sollte ein entsprechendes Verhalten natürlich unbedingt vermeiden.

Ist ein CMS in Computerbildschirm, TV oder Beamer ohne Möglichkeit der Beeinflussung der Helligkeitskomponente von Primär- und Sekundärfarben inkomplett bzw. gar fehlerhaft?

Die Berechnungen aus Teil 1 helfen uns auch bei der zweiten Fragestellung weiter:

Für die meisten Umsetzungen ist diese Feststellung korrekt (nicht aber als Allaussage). Hier käme es nach Anpassungen von Farbton und Sättigung sonst tatsächlich zu unschönen Nichtlinearitäten.

Nachfolgend ein Beispiel für die Nutzung der entsprechenden Funktion eines CMS. Der Gerätefarbraum wurde durch Änderung von Farbton- und Sättigung für Primär- und Sekundärfarben so gut wie möglich auf die Zielwerte für sRGB (D65) eingeschränkt.

Zustand vor CMS-Eingriff (Weißpunkt ~D65, Farbraum nativ) XYZ-Normfarbwerte (normalisiert):

Rot: 0.5809 0.2794 0.0088
Grün: 0.1806 0.6272 0.0972
Blau: 0.1837 0.0915 0.9665
Weiß: 0.9461 1.0 1.0769

Zustand nach CMS-Eingriff (Weißpunkt ~D65, Zielfarbraum: sRGB) XYZ-Normfarbwerte (normalisiert):

Rot: 0.5720 0.2967 0.0284
Grün: 0.3487 0.6987 0.1158
Blau: 0.1967 0.0983 0.9926
Weiß: 0.9519 1.0 1.1014

Das Problem ist offenkundig: Die Addition der Helligkeiten von Rot, Grün und Blau liegt nach dem CMS-Eingriff über der Helligkeit von Weiß. Rot ist deutlich zu hell, während die Helligkeiten von Grün und Blau den Sollwert (Berechnung: Siehe Abbildung 3) etwa erreichen.

Helligkeits-Sollwerte für Zustand nach CMS-Eingriff

Y(Rot): 0.2158
Y(Grün): 0.6892
Y(Blau): 0.095

Bildschirme mit Farbraumemulation?

Im High-End Bereich verfügen heute einige Bildschirme über eine flexible Farbraumemulation. Der Benutzer kann die gewünschten Normfarbwertanteile für Primärfarben und Weißpunkt angeben. Der Gerätefarbraum wird entsprechend eingeschränkt.

Farbraumemulation Eizo Color Navigator
Farbraumemulation Eizo Color Navigator
Farbraumemulation NEC SpectraView II
Farbraumemulation NEC SpectraView II

Diese Regelungen sind aber trotz der in den Normfarbwertanteilen nicht mehr enthaltenen Helligkeitsinformation (im Gegensatz zu den XYZ-Normfarbwerten) nicht unvollständig oder fehlerhaft (siehe Abbildung 7).

Die korrekten Helligkeitswerte lassen sich ja berechnen (siehe Abbildung 3). Das haben wir in diesem Artikel bereits mehrfach durchgeführt. Der Hersteller kann also durchaus dafür Sorge tragen, ein lineares Verhalten auch in diesem Fall sicherzustellen.

Farbraumemulation mit sRGB als Ziel (Definition im Rahmen der Farbraumemulation des Eizo CG303W über Normfarbwertanteile relativ zu D65); Messung gegen sRGB;
Farbraumemulation mit sRGB als Ziel (Definition im Rahmen der Farbraumemulation des Eizo CG303W über Normfarbwertanteile relativ zu D65); Messung gegen sRGB;

Anmerkung: Eine korrekte Darstellung von sRGB-Inhalten (gilt auch für die im Videobereich definierten Farbräume) wäre übrigens, jenseits der weit verbreiteten Ansicht, auch abseits von D65 als Weißpunkt möglich. In diesem Fall müssten die relativ zu D65 definierten Zielwerte chromatisch adaptiert werden. Das ist Inhalt eines weiteren Artikels. In einem gemanagten ICC-Workflow muss der Nutzer sich um solche Abläufe nicht kümmern.

Gefällt Ihnen dieser Beitrag ?

100%
gefällt es

Diskussion: Neuen Beitrag verfassen