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.
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.
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.
Gefüllt mit den Werten aus dem 3. Schritt, und mit ausgerechneten Brüchen, wird daraus:
Ermittlung der inversen Matrix:
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.
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.
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 es
Sun Cellular