Farbkorrektur, Color Management und der Vorteil des linearen Arbeitsfarbraums

[slashCAM]

Farbkorrektur kann nur korrekt funktionieren, wenn sie in einem kontrollierten Farbraum stattfindet. Dies bedeutet in der Praxis, dass man laut Lehrbuch immer in einem linearen Farbraum korrigieren sollte. Doch warum ist das so und was bedeutet dies eigentlich?



Hier geht es zu Artikel auf den slashCAM Magazin-Seiten:
Grundlagen: Farbkorrektur, Color Management und der Vorteil des linearen Arbeitsfarbraums

[dienstag_01]

Die dritte Komponente in diesem Spiel ist das Vorschau-Profil. Um während der Arbeit im Arbeitsfarbraum die Ergebnisse korrekt beurteilen zu können, muss die TimelineTimeline im Glossar erklärt für die korrekte Darstellung am Monitor ebenfalls angepasst werden. Stellt der Monitor beispielsweise Farben im sRGB-Farbraum dar, so muss die TimelineTimeline im Glossar erklärt mit einem Farbprofil für die Vorschau nach sRGB transformiert werden.

Das verstehe ich, ehrlich gesagt, nicht. Wenn ich z. B. Log-Material auf der Timeline und als Vorschau einen 709-Monitor habe, dann kann ich das Material doch komplett ohne irgendwelche LUTs für eine 709 Ausgabe bearbeiten. Warum *muss* ich die Timeline nach 709 wandeln, ich sehe doch sowieso das Ergebnis (und passe es gegebenenfalls an).
Oder?

[rudi]

Die dritte Komponente in diesem Spiel ist das Vorschau-Profil. Um während der Arbeit im Arbeitsfarbraum die Ergebnisse korrekt beurteilen zu können, muss die TimelineTimeline im Glossar erklärt für die korrekte Darstellung am Monitor ebenfalls angepasst werden. Stellt der Monitor beispielsweise Farben im sRGB-Farbraum dar, so muss die TimelineTimeline im Glossar erklärt mit einem Farbprofil für die Vorschau nach sRGB transformiert werden.

Das verstehe ich, ehrlich gesagt, nicht. Wenn ich z. B. Log-Material auf der Timeline und als Vorschau einen 709-Monitor habe, dann kann ich das Material doch komplett ohne irgendwelche LUTs für eine 709 Ausgabe bearbeiten. Warum *muss* ich die Timeline nach 709 wandeln, ich sehe doch sowieso das Ergebnis (und passe es gegebenenfalls an).
Oder?

Hmm, vielleicht nicht einfach genug formuliert. Gemeint ist: Wenn die Timeline linear ist, dann muss ich sie noch zur Vorschau am Monitor an die Gammakaurve des Monitors anpassen. Diese Transformation geht jedoch nicht in den Output ein, sondern wird nur speziell zu Vorschauzwecken vom Signal "abgezweigt".

[cantsin]

Das praktische Problem dürfte sein, dass fast alle Konversions-LUTs (z.B. für Log-Profile) direkt nach Rec709 konvertieren, nicht in einen linearen Farbraum.

[blueplanet]

...und mit anderen Worten, man benötigt (möglichst) einen kalibrierten Bildschirm. Somit sehe ich auch korrekt das, was ich am PC-Schirm gegradet habe auf meinem TV (wenn dieser ebenfalls kalibriert ist). Und spätestens dort trifft mathtematische Theorie consumer Praxis.
Wer hat, wer kann schon seinen TV kalibrieren?! Ich habe einen guten, alten THX-zertifizierten Neon-Plasma. Dort war und ist das möglich...schau' ich mir dagegen mein Material auf irgendeinem Rec709-Schirm aus dem Bekanntenkreis an, dann gibt es ebenso viele "Bildprofil-Varianten" wie es Geräte gibt. Ergo, das Zünglein an der Waage sind nicht Rec709 oder 2020 etc. sondern bestenfalls der persönliche Geschmack und schlimmstenfalls was die Hersteller uns werksseitig vor die Augen setzen. Siehe Sony vs. Samsung vs. Panasonic vs...

[rudi]

Das praktische Problem dürfte sein, dass fast alle Konversions-LUTs (z.B. für Log-Profile) direkt nach Rec709 konvertieren, nicht in einen linearen Farbraum.

Definitv. Wobei mir absolut nicht klar ist, warum das die Hersteller so machen. Weil sie einfach davon ausgehen dass 99 Prozent aller Timelines in Rec709 betrachtet werden?
Solche LUTs erhöhen die Komplexität des Color Managements unnnötig. Darum auch Lob für Blackmagic, die explizit LUTs nach Linear beilegen.
Eigentlich wären jetzt aber LUTs nach linear ACES gefragt. Der Standard ist da und jeder könnte sich dran halten. Ich frage mich nur, wie stark die Farben dann nach der Linearisierung zwischen den Herstellern noch differieren würden. Im Zweifelsfall dürfte es bei RAW kaum noch Unterschiede zwischen den Kameras geben.

[dienstag_01]

Helft mir nochmal. Wenn ich in den Projekt Settings als 3D Color Viewer LUT *Linear to sRGB* wähle (Timeline Color Space ist linear), wird mein Vorschaubild deutlich zu hell. Und es werden auch die Scopes beeinflusst. Das ist doch völliger Nonsens.

[susy]

Das praktische Problem dürfte sein, dass fast alle Konversions-LUTs (z.B. für Log-Profile) direkt nach Rec709 konvertieren, nicht in einen linearen Farbraum.

Definitv. Wobei mir absolut nicht klar ist, warum das die Hersteller so machen. Weil sie einfach davon ausgehen dass 99 Prozent aller Timelines in Rec709 betrachtet werden?
Solche LUTs erhöhen die Komplexität des Color Managements unnnötig. Darum auch Lob für Blackmagic, die explizit LUTs nach Linear beilegen.
Eigentlich wären jetzt aber LUTs nach linear ACES gefragt. Der Standard ist da und jeder könnte sich dran halten. Ich frage mich nur, wie stark die Farben dann nach der Linearisierung zwischen den Herstellern noch differieren würden. Im Zweifelsfall dürfte es bei RAW kaum noch Unterschiede zwischen den Kameras geben.

Für ACES gibt es doch schon viele IDTs, oder ist das wieder was anderes?

[dienstag_01]

Das verstehe ich, ehrlich gesagt, nicht. Wenn ich z. B. Log-Material auf der Timeline und als Vorschau einen 709-Monitor habe, dann kann ich das Material doch komplett ohne irgendwelche LUTs für eine 709 Ausgabe bearbeiten. Warum *muss* ich die Timeline nach 709 wandeln, ich sehe doch sowieso das Ergebnis (und passe es gegebenenfalls an).
Oder?

Hmm, vielleicht nicht einfach genug formuliert. Gemeint ist: Wenn die Timeline linear ist, dann muss ich sie noch zur Vorschau am Monitor an die Gammakaurve des Monitors anpassen. Diese Transformation geht jedoch nicht in den Output ein, sondern wird nur speziell zu Vorschauzwecken vom Signal "abgezweigt".

Ist zwar schon etwas älter (Resolve 12), beschreibt aber den Workflow komplett anders: Mit dem Output Color Space wird auch der Colorspace von Monitor und Viewer festgelegt.
https://mixinglight.com/color-tutorial/ ... anagement/

Ausserdem sind die Bezeichnungen LUT im Workflow Diagramm eures Artikels falsch INPUT LUT, OUTPUT LUT). Das sind Profile.
Wenn der von mir verlinkte Artikel stimmen sollte ;)

[rudi]

Hmm, vielleicht nicht einfach genug formuliert. Gemeint ist: Wenn die Timeline linear ist, dann muss ich sie noch zur Vorschau am Monitor an die Gammakaurve des Monitors anpassen. Diese Transformation geht jedoch nicht in den Output ein, sondern wird nur speziell zu Vorschauzwecken vom Signal "abgezweigt".

Ist zwar schon etwas älter (Resolve 12), beschreibt aber den Workflow komplett anders: Mit dem Output Color Space wird auch der Colorspace von Monitor und Viewer festgelegt.
https://mixinglight.com/color-tutorial/ ... anagement/

Ausserdem sind die Bezeichnungen LUT im Workflow Diagramm eures Artikels falsch INPUT LUT, OUTPUT LUT). Das sind Profile.
Wenn der von mir verlinkte Artikel stimmen sollte ;)

Jein: Wir wollten einen Grundlagen Artikel dazu schreiben, aber haben verwirrenderweise eine Abbildung von Resolve mitreingenommen. Du hast insofern vollkommen recht: In Resolve zweigt die Viewer LUT nicht von der Timeline sondern vom Output ab, was ebenso sinnvoll sein kann. Das erklärt auch die anderen Fragen hier: Die Skopes hängen in Resolve wohl übrigens auch hinter der Output LUT, aber da bin ich mir grade selbst nicht sicher, würde aber der "Resolve Denke" entsprechen.

[dienstag_01]

Ist zwar schon etwas älter (Resolve 12), beschreibt aber den Workflow komplett anders: Mit dem Output Color Space wird auch der Colorspace von Monitor und Viewer festgelegt.
https://mixinglight.com/color-tutorial/ ... anagement/

Ausserdem sind die Bezeichnungen LUT im Workflow Diagramm eures Artikels falsch INPUT LUT, OUTPUT LUT). Das sind Profile.
Wenn der von mir verlinkte Artikel stimmen sollte ;)

Jein: Wir wollten einen Grundlagen Artikel dazu schreiben, aber haben verwirrenderweise eine Abbildung von Resolve mitreingenommen. Du hast insofern vollkommen recht: In Resolve zweigt die Viewer LUT nicht von der Timeline sondern vom Output ab, was ebenso sinnvoll sein kann. Das erklärt auch die anderen Fragen hier: Die Skopes hängen in Resolve wohl übrigens auch hinter der Output LUT, aber da bin ich mir grade selbst nicht sicher, würde aber der "Resolve Denke" entsprechen.

Ich habe das jetzt mal so verstanden, dass man in Resolve beim Scene Reffered Color Managment überhaupt keine LUTs verwendet - sondern die Profile. Da also zusätzlich eine Output LUT auszuwählen, wäre also Blödsinn. Oder?
Anders beim Display Reffered CM, aber das ist ja sozusagen *überhaupt kein* CM, da es der Anwender übernimmt - und dann mit LUTs.

[rudi]

Jein: Wir wollten einen Grundlagen Artikel dazu schreiben, aber haben verwirrenderweise eine Abbildung von Resolve mitreingenommen. Du hast insofern vollkommen recht: In Resolve zweigt die Viewer LUT nicht von der Timeline sondern vom Output ab, was ebenso sinnvoll sein kann. Das erklärt auch die anderen Fragen hier: Die Skopes hängen in Resolve wohl übrigens auch hinter der Output LUT, aber da bin ich mir grade selbst nicht sicher, würde aber der "Resolve Denke" entsprechen.

Ich habe das jetzt mal so verstanden, dass man in Resolve beim Scene Reffered Color Managment überhaupt keine LUTs verwendet - sondern die Profile. Da also zusätzlich eine Output LUT auszuwählen, wäre also Blödsinn. Oder?
Anders beim Display Reffered CM, aber das ist ja sozusagen *überhaupt kein* CM, da es der Anwender übernimmt - und dann mit LUTs.

Das entspricht auch meinem Verständnis von Resolve. Da ist in den letzten Versionen aber auch viel dazu gekommen, was ich mir noch nie so genau angesehen habe. Das Display Referred Color Management ist wohl insofern noch Management, dass man die Prozesse/Transformationen selber festlegen kann. Aber ist halt kein ACES-Autopilot ;)