Hallo Liste, hallo Dietmar, Also nun doch im Detail - sorry schon mal im voraus, wei's mal wieder länger dauert. ;-) Erst mal zum GAMMA: Vielen Dank für Deine Grafik unter http://www.image-engineering.de/bilder/gamma.gif !!!! Sie zeigt sehr gut, warum ein Gamma von 1,8 für einen 8-BIT SPEICHER-Farbraum besser geeignet ist als 2,2. Tonwertabrisse, Farbabweichungen,... wirken auf das menschliche Auge besonders störend in den Mitteltönen und Lichtern, also der oberen "Hälfte" des Farbraumes. Fehler in dunklen und stark gesättigten Bereichen hingegen fallen visuell weniger auf. Reduziert man die Betrachtung auf die Grauachse, heißt das: ausgefressene Lichter und Stufen in den Mitteltönen stören den durchschnittlichen Betrachter mehr als zugelaufene Schatten. Dies korreliert mit der menschlichen Erfahrung, dass Strukturen in dunklen Bereichen bei geringer Beleuchtungsstärke nicht mehr aufgelöst werden können - also einem sehr häufig beobachteten, natürlichen Effekt. Das "Ausfressen" der Lichter hingegen erinnert an eine Blendung - ein i.d.R. sehr unangenehmes Gefühl, dem man sich nicht lange aussetzt. Doch zurück zur "Mathematik": - Betrachten wir zunächst die obere Hälfte der Kurve: L*=50 bis L*=100 Hier zeigt sich in Deiner Grafik, dass für die Speicherung von Farben bei Gamma 1,8 ca. 155 Stufen, bei einem Gamma von 2,2 nur ca. 135 Stufen zur Verfügung stehen. In diesem für die visuelle Wahrnehmung besonders wichtigen Bereich können also bei 8 bit Datentiefe Farbinformationen genauer abgelegt werden, wenn dem Farbraum ein Gamma von 1.8 zugrunde liegt. Damit sind in einem 8-bit-Datensatz also bei einem Gamma von 1.8 mehr "Reserven" für die Bearbeitung bzw. Umrechnung in den Lichtern bis hin zum Mittelton enthalten. Betrachtet man das Ganze senkrecht zur L*-Achse sind die Verhältnisse ähnlich: Gamma 1,8 führt zu einer höheren Koordinatendichte im Bereich um die besonders empfindliche Grauachse. - Dieser "Genauigkeitsgewinn" muss natürlich irgendwoher kommen. Dies bringt uns zur Untersuchung der unteren "Hälfte": L*=0 bis L*=50 Hier stehen bei einem Gamma von 2.2 ca. 120, bei einem Gamma von 1.8 nur 100 Stufen zur Darstellung z.B. eines Verlaufs zur Verfügung. Der Vorteil der zusätzlichen 20 Stufen wird bei hohen Gammawerten aber durch die extreme Nicht-Linearität am Schwarzpunkt (L*=0 bis L*=10) verspielt. Ein auf Gamma 1,8 basierender Farbraum verhält sich hier fast linear (siehe Grafik). Dies sorgt bei Gamma 1,8 für eine harmonische Speicherung der Schwarzzeichnung. Hohe Gammawerte hingegen führen zu einer starken "Datenaufsteilung" (entspricht einer extrem hohen Koordinatendichte) in diesem Bereich. Es wird bei Gamma 2.2 sehr viel Information (ca. 25 Stufen) für die Speicherung von Helligkeitsinformationen zwischen L*=0 und L*=5 benutzt. Zwischen L*=0 und L*=2 werden 16 Stufen, zwischen L*=0 und L*=1 bereits 12 Stufen verbraucht! Hier werden also zur Speicherung des untersten 1% der Grauachse bereits fast 5% des Datenraums "verbraten"! Dies zudem am Schwarzpunkt, wo Zeichnung sofern sie in diesem Bereich überhaupt gedruckt werden kann, sowieso nur bei bester Beleuchtung zu sehen ist. Dass wir die bei Gamma 2,2 für die Zeichnung am Schwarzpunkt benutzte Informationsdichte mit heutigen Drucksystemen kaum wiedergeben können, ist die harmlosere Seite der Medaille. Der Schwarzpunkt entspricht aufnahmetechnisch dem Kamerarauschen. Somit wird bei Gamma 2.2 die im gesamten Farbraum höchste Koordinatendichte (L*=0 bis L*=1, bei Gamma 2,2 fast 5-mal so hoch wie die farbmetrisch lineare Verteilung am Schwarz bzw. die Verteilung in Mitteltönen und Lichtern) für die Speicherung des statistischen Rauschens der Kamera verschwendet. Wegen der großen Steigung der Kurve am Schwarzpunkt sind bei Gamma 2,2 zudem Fehler (z.B. Verstärkung des Rauschens, Tiefenzeichnungsverlust durch eine auf das hohe Gamma ausgerichtete zu starke Rauschunterdrückung, Interpolationsfehler,...) wahrscheinlicher als bei der Umsetzung der Rohdaten in einen Arbeitsfarbraum auf Basis von Gamma 1,8 wie ECI-RGB (Kodak's DCSRGB z.B. basiert ebenfalls auf Gamma 1,8). Zusammenfassung zum Gamma: Unterm Strich steckt in einem 8-bit-Farbraum, der auf einem Gamma von 1,8 basiert, bei richtiger Belichtung/Entwicklung im Schnitt mehr SICHTBARE Bildinformation. Die Koordinaten liegen in wichtigen Bereichen (Licht bis Mittelton) etwas dichter. Das leichte "Durchhängen" der Kurve für Gamma 1,8 erzeugt bei Berücksichtigung des gesamten Farbraums bzw. der gesamten Achse eine harmonischere Verteilung der Koordinaten. Die starken Steigungs- bzw. Konzentrationsschwankungen am Schwarzpunkt wie bei Gamma 2,2 werden vermieden. Eine Konvertierung in 8 bit ECI-RGB macht technisch natürlich nur dann Sinn, wenn die Quelle Rohdaten (möglichst in höherer Bittiefe) sind. Wer von seiner Kamera nur 8 bit sRGB erhält, läßt das "Elend" am besten wie es ist (natürlich mit eingebettetem sRGB-Profil). Trotz der guten, harmonischen Verteilung mit Gamma 1,8 sollten Daten, die langfristig archiviert werden sollen, nach Möglichkeit in 16 bit gesichert werden. Da die Rohdaten meist in 10 bis 14 bit erzeugt werden, können diese i.d.R. nahezu ohne Verluste in z.B. 16-bit ECI-RGB überführt werden. Bei 16 bit Farbtiefe ist eine Optimierung der Koordinatenverteilung durch das Gamma technisch nicht mehr erforderlich. Die Wahl des Gammas ist (in vernünftigen Grenzen) beliebig. Hier könnte auch 2,2 oder 2,4 gewählt werden. 2,4 entspricht im Bereich L*=30 bis L*=100 besser der farbmetrisch linearen Verteilung (siehe Grafik), L*=50 liegt in der Mitte des RGB-Farbraumes. GAMUT: Etwas schwieriger wird's mit der Farbraumgröße von ECI-RGB. Wir stehen generell vor dem Problem, daß ein großer (Digitalkamera-/Scanner-) Farbraum nur mit Verlusten in Zeichnung und/oder Sättigung in einen kleinen (Druck-) Farbraum konvertiert werden kann. Die Frage ist, welche Daten man archiviert: Druckdaten (z.B. Maschinen-CMYK, ISO-CMYK,..) drucknahe RGB-Daten (z.B. PhotoGamutRGB), aufnahmenahe Daten (ECI-RGB) oder Aufnahmedaten (Kamera-/Scanner-RGB). Ich persönlich halte hier ECI-RGB für die ARCHIVIERUNG für den zur Zeit besten Kompromiss. Die endgültige Entscheidung des Anwenders ist aber von vielen Produktionsparametern abhängig (Art der Produktion, voraussichtliche Wiederverwendung der Daten, Know-How der Mitarbeiter, Anforderung von Kundenseite,...), so dass je nach Anwendung auch andere Farbräume für die PRODUKTION günstiger sein können. RESÜMEE: Der Wechsel von Gamma 1.8, das in 8 bit eindeutig Vorteile hat, zu Gamma 2.2 das in 8 bit Nachteile aufweist und zu dem es in 16 bit eventuell bessere Alternativen (inkl. CIELAB) gibt, nur damit professionelle Bilddaten mit einem sRGB-Consumerworkflow ohne Farbmanagement (der zudem auf einem Gerät - dem Röhrenmonitor - basiert, das es in Kürze nicht mehr gibt) kompatibler werden, macht in meinen Augen keinen Sinn. Ich bin zum heutigen Zeitpunkt für eine scharfe Trennlinie zwischen Consumerworkflow und professioneller Bildverarbeitung: Wer Bilddaten unbedingt ohne Farbmanagement verarbeiten will, soll in sRGB fotografieren, die Originalmaterialien der Tintenspritzerhersteller benutzen, den Drucker über den Druckertreiber ansteuern und mit der so erreichbaren Qualität und Produktionssicherheit leben. Der Rest kommt an der Anwendung von Farbmanagement nicht vorbei. Da viele Anwender gerade erst in das Thema Farbmanagement einsteigen, halte ich die stete Diskussion um Arbeitsfarbräume für kontraproduktiv. Auch bringt es die gesamte grafische Industrie nicht voran. Wir können mit den heute verfügbaren Digitalkameras ohne angeschlossenen Computer noch nicht einmal ECI-RGB-Daten erzeugen!!! Wenn wir uns nun zwischen mehreren deutschen Insellösungen (die alle ihre Vor- und Nachteile haben) zerfleischen wird's nie was mit der internationalen Verbreitung EINES professionellen Arbeitsfarbraums (der für unsere Zwecke besser geeignet ist als sRGB und Adobe-RGB) und dessen Integration in die Kameraelektronik. ECI-RGB 1.0 ist bereits etabliert und hat sich nun 5 Jahre in der Produktion bewährt. Eine Integration in bestehende Systeme stellt keine technische Schwierigkeit dar, da es von der Struktur her den heute üblichen Kameraausgabefarbräumen sRGB/AdobeRGB entspricht. Deshalb sollten wir uns heute darauf konzentrieren, zunächst ECI-RGB 1.0 auf internationaler Ebene zu etablieren. Die Konstruktion eines neuen ECI-Arbeitsfarbraumes würde ich gerne um ein paar Jahre verschieben. Zur Zeit entwickelt sich die Technik so rasant weiter, dass heute niemand abschätzen kann, welche Anforderungen in einigen Jahren an einen Speicherfarbraum gestellt werden. MONITORKALIBRIERUNG: Die Kalibrierung und Profilierung von Monitoren muss bei Einsatz von Farbmanagement getrennt vom RGB-Arbeitsfarbraum erfolgen. Monitore sollten als Ausgabegeräte genauso wie Drucker linearisiert werden. Dafür wurde bisher das Gamma-Modell benutzt. Wie Dietmars Grafik eindrucksvoll zeigt, ist mit diesem mathematischen Modell aber nur eine sehr grobe Näherung an eine farbmetrisch gleichabständige Koordinatenverteilung, wie Sie zur Simulation von Druck-Systemen wünschenswert wäre, möglich. Kein Gamma-Wert ergibt in allen Bereichen eine gute Näherung. Als Speicherfarbraum bringt ein Matrix-Profil heute noch mehr Vor- als Nachteile. Bei Farbräumen für Ausgabegeräte hingegen - und dazu zählen eben auch Monitore - sind LUT-Profile genauer, leistungsfähiger und seit geraumer Zeit Stand der Technik. Allerdings wurden Monitore bis vor kurzem vor der (LUT-)Profilierung noch nach dem Gamma-Modell kalibriert. Genau wie bei Druckern eine farbmetrische Linearisierung der rein densitometrischen überlegen ist, führt nach unseren Versuchen auch bei Monitoren eine farbmetrisch lineare Kalibrierung zu besseren Vorraussetzungen für die Simulation von Drucksystemen auf Monitoren. Viele Grüße, Markus Hitzler ___________________________________________ Color Solutions Köln Markus Hitzler August-von-Willich-Str. 155 50827 Köln Telefon: +49 (0)221 99 175 80 Fax: +49 (0)221 99 175 81 Mobil: +49 (0)171 8390333 Email: markus.hitzler(a)color-solutions.de Web: http://www.basICColor.de ___________________________________________ basICColor - the basICCs of colormanagement ___________________________________________ Am 22.09.2003 12:00 Uhr schrieb "eci-request(a)lists.transmedia.de" unter <eci-request(a)lists.transmedia.de>de>: