Weia, ich habe diesen dedizierten Thread erstellt aufgrund einiger deiner Aussagen über Apples Final Cut Pro X, Apples Color Science im Allgemeinen und der angeblichen Unfähigkeit anderer NLEs und Player außer FCPX und QuickTime, Video farblich akkurat auf Macs wiedergeben zu können. Da du diese Aussagen über einen längeren Zeitraum hinweg in diversen Threads geäußert hast, möchte ich in diesem konsolidierten Thread darauf eingehen. Die Quell-Threads habe ich jeweils als Quelle-link angegeben.
Meine Motivation für diesen Thread ist schlicht und ergreifend die Tatsache, dass deine Behauptung – „Kein anderes NLE außer FCP sei in der Lage, farbakkurat unter macOS zu arbeiten“ – grundlegend falsch ist und so nicht stehen gelassen werden kann. Dieser Trugschluss lässt sich mit einem einfachen Test widerlegen.



Wenn Videotechnik – sowohl die aus der Zeit vor dem Einzug von Computern als auch die heutige – nicht auf physikalischen Grundsätzen basiert, wie du es behauptest, worauf beruht sie dann? Das ist, als würde man behaupten, Film und die Entwicklung von Film im Labor hätten nichts mit Chemie zu tun. So ziemlich alles an Videotechnik ist Physik und Elektronik. Und was meinst du mit der schwammigen Beschreibung von „seltsamen Verfahrensweisen“? Das musst du bitte genauer erklären.


Doch, du sprichst vehement dagegen, indem du allen computerbasierten NLEs außer FCP absprichst, nicht korrekt zu arbeiten – was Farbraum und Colour Science anbelangt. Diese Behauptung trifft jedoch schlichtweg nicht zu. Du hast dich offensichtlich noch nie ernsthaft mit professionellen NLEs auseinandergesetzt oder mit solchen unter realen Produktionsbedingungen gearbeitet und kennst eben nur FCP.

Apple kocht mit FCPX – und bereits mit FCP seit der Übernahme von Macromedia – sein eigenes Süppchen. Bis heute ist die Software nicht in der Lage, unkomprimiertes RAW-Material von de-facto-Standardkameras ohne Zuhilfenahme externer Konverter nativ zu decodieren, zu de-bayern und in den korrekten Farbraum zu bringen. FCP kann das weder mit ARRI RAW (hierfür wird das ARRI Reference Tool benötigt), noch mit RED RAW (hierfür benötigt man den RED Apple Workflow Installer), noch mit Blackmagic RAW (dafür wird die BRAW Toolbox von Blackmagic benötigt).

Wohlgemerkt: Diese Umwege sind nur bei Apples FCPX notwendig. Ernstzunehmende und am Markt etablierte NLEs und Viewer beherrschen dies nativ und intern – zum Beispiel: Assimilate Scratch, Autodesk Smoke, Blackmagic DaVinci Resolve, Filmlight's Baselight und Daylight, Autodesk RV und RVIO, Colorfront Transcoder, Pomfort Silverstack und YoYotta, um nur einige zu nennen.

Gleiches trifft im Übrigen auch auf Apples QuickTime zu – keinerlei nativer Support für die oben genannten Formate. Ganz zu schweigen von logarithmischem RAW-Material wie z. B. ARRI's Log-C – da herrscht bei QT/FCP ebenfalls Fehlanzeige. Nicht einmal DJI- oder GoPro-Log-Material lässt sich in QT/FCP ohne Hilfe von Konvertern farblich korrekt darstellen. Bei anderen namhaften NLEs ist das kein Problem, da diese die RAW-Converter der Hersteller integrieren, nativ unterstützen und stets aktuell halten, um die Bilder der Kameras unverfälscht so zu decodieren, wie sie vom Sensor aufgezeichnet wurden.

An dieser Stelle spielen die von dir so oft erwähnten Monitor-Profile noch nicht einmal eine Rolle. Wir befinden uns hier noch ganz am Anfang der Bearbeitungskette – und selbst da hakt es bereits bei FCP und QuickTime.

Du hast recht mit deiner Aussage, dass Apple kaum jemand etwas vormacht, wenn es um Farbprofile für die Ausgabe auf verschiedenen COMPUTER Displays geht. In diesem Bereich sind Apple und macOS tatsächlich sehr gut. Das betrifft jedoch ausschließlich die Ausgabe. Was den Import von Log-RAW-Videodaten angeht, liegt bei FCPX noch vieles im Argen – und andere NLEs können das um Längen besser. Und was bringt mir ein NLE, das auf einem Computermonitor zwar korrekte Farben ausgeben kann, wenn es bereits beim farblich korrekten Import grundlegend scheitert?


Das stimmt doch überhaupt nicht. Wie kommst du zu dieser verallgemeinernden Aussage, und womit willst du sie belegen?

Solange du RAW-Kameradateien mit dem vom Kamerahersteller bereitgestellten RAW-Converter importierst, wird nichts „aufgesteilt“ oder physikalisch falsch konvertiert. Es erfolgt lediglich ein auf den jeweiligen CMOS-Sensor abgestimmtes De-Bayering sowie ein präzise auf diesen Sensor zugeschnittenes Tone-Mapping mittels 3D-LUT, um Grau- und Farbwerte akkurat abbilden zu können.

Das Problem dabei ist, dass Apple sich strikt weigert, die RAW-Converter von ARRI, RED oder Blackmagic in FCPX zu integrieren. Entsprechend ist FCPX auch nicht in der Lage, diese Dateien „out of the box“ korrekt zu decodieren. Hier kommen wir wieder zu Programmen wie Pomfort, DaVinci und Co., die das alles nativ beherrschen.

Natürlich hilft macOS auf der Ausgabeseite, einen konsistenten Look auf Computerbildschirmen zu gewährleisten. Doch sobald DCPs erstellt werden müssen oder das Material für professionelle Monitore und Projektoren wie von Sony oder Barco aufbereitet werden soll, stößt man mit dem in macOS integrierten Farbmanagement schnell an Grenzen – denn FCP bietet keine Möglichkeit, den passenden Farbraum für das Zielmedium als Referenz festzulegen.

Das mag für den Normalverbraucher akzeptabel oder sogar vorteilhaft sein, weil dieser sein Material ohnehin nur auf dem Mac-Monitor, iPhone oder iPad betrachtet. Doch sobald man sich im professionellen Bereich bewegt – etwa mit Class-A-Broadcast-Monitoren, Projektoren oder sogar Film-Ausbelichtungen für analoge Projektionssysteme – ist man mit FCP und macOS stark limitiert.

Deine Aussage ist allenfalls aus historischer Sicht teilweise zutreffend – nämlich aus der Zeit, als Kameras tatsächlich noch ein Videosignal ausgaben. Im schlimmsten Fall handelte es sich damals um ein analoges Composite-Signal (Luminanz und Chrominanz über FBAS und ungeschirmte Koaxialkabel). Im besten Fall war es ein digitales Komponentensignal in YUV über eine SDI-Verbindung. Dazwischen lagen noch analoge YUV-Komponentensignale oder analoge YC-Signale, bei denen Chrominanz und Luminanz über getrennte, abgeschirmte Leitungen übertragen wurden.

Wenn man in jener Zeit also mit computerbasierten NLEs arbeitete, war die AD/DA-Wandlung tatsächlich eine erhebliche Fehlerquelle – in diesem Zusammenhang passt deine Aussage. Heute trifft das jedoch nicht mehr zu.

Die genannten Filmkritiker und Filmwissenschaftler mögen in ihrem Beruf als Filmkritiker oder Filmwissenschaftler professionell sein, doch bedeutet das nicht, dass sie sich zwingend mit der Erstellung und Verarbeitung dieser Medien auskennen oder professionell beurteilen können, wie etwas verarbeitet wird und welche Wege Bildsignale während der Bearbeitung nehmen. In diesem Fall sind sie „Konsumenten“.


Das stimmt nur bedingt. Um bei deinen Filmkritikern und Filmwissenschaftlern zu bleiben: Beide Gruppen verhalten sich, wenn sie ihren Job gut machen, alles andere als indifferent und sind in diesem Fall dennoch Endverbraucher.

„Print“ ist doch eine komplett andere Baustelle und verwässert als Vergleich an dieser Stelle die Problematik nur.

Wenn es so wäre, dass Messergebnisse bei Farbanalysen und Monitor-Kalibrierungen immer eindeutig sind, warum beruhen dann bei sämtlichen Methoden die Ergebnisse auf Durchschnittswerten von mehreren Messdurchgängen? Eindeutig ist da überhaupt nichts, sondern im besten Fall ein guter Durchschnittswert, basierend auf mehreren Messungen.

Um bei deinem HiFi-Beispiel zu bleiben: Bevor ein professioneller Verstärker einen linearen Frequenzgang liefern kann, muss er erstmal Eingangssignale nativ verstehen. Erst dann kommt ein linearer Frequenzgang zum Tragen. Und genau hier hapert es schon bei FCP, QuickTime und iMovie. Apple-Software ist hier der limitierende Faktor, bevor man überhaupt über die Ausgabe des Mediums auf diversen Monitoren nachdenken kann. Allein die Tatsache, dass in FCP gängige Formate nicht nativ verarbeitet werden können, sondern erst eine Konvertierung in z. B. ProRes notwendig ist, kann eine Fehlerquelle in Bezug auf die Farben darstellen und kann bei falscher Konvertierung im schlimmsten Fall zu Abweichungen oder einer qualitativen Degradierung des Originalmaterials führen.

Schön, ich befasse mich mit der Thematik seit 1997 hauptberuflich und davor seit 1992 neben der Schullaufbahn im Rahmen von Volontariaten bei TV-Sendern und bei Sony Deutschland Professional.

Bei dieser Aussage kann etwas nicht stimmen, denn du wirst weder ARRI RAW noch BMRAW nativ in FCP importiert haben. Wie oben bereits ausführlich erklärt, ist das in FCP bis heute seitens Apple nicht ohne externe Konvertierung möglich. Da hilft dir auch ProRes nicht weiter, denn ProRes ist nicht das native, linearisierte und de-bayerte Signal des Kamerasensors, sondern bestenfalls eine Interpretation mit vielen Parametern, die je nach Geschmack verändert werden können.

Im Idealfall kümmert sich ein DIT am Set in Absprache mit dem DOP um die Konvertierung. Wenn du also sagst, dass du mit ProRes-Material in FCP getestet hast, sagt das in erster Linie nur aus, dass dein Material mit der bestmöglichen Kompression in FCP geladen wurde. Es hat jedoch keine Aussagekraft über die farbliche Integrität des Materials selbst. Farblich falsch konvertiertes RAW-Material ist auch in ProRes immer noch farblich falsch.

Ich will damit nicht sagen, dass das Material, mit dem du getestet hast, zwingend falsch konvertiert wurde, sondern nur zum Ausdruck bringen, dass das Material in keinem Fall dem entsprochen haben muss, was direkt aus dem Sensor der Kamera ausgelesen wurde – weder farblich noch in Bezug auf die Kompression. In einer RAW-ProRes-Konvertierung können viele Parameter verändert werden, die das Resultat weit von dem entfernen, was ursprünglich aus dem Sensor ausgelesen wurde.

Das kapiert nicht nur Apple, sondern jeder Hersteller eines guten NLEs. Du kannst mit den korrekten Projekteinstellungen bei jedem namhaften NLE/Player wie Assimilate Scratch, Autodesk Smoke, Blackmagic DaVinci Resolve, Filmlight's Baselight und Daylight, Autodesk RV und RVIO, Colorfront Transcoder, Pomfort Silverstack und YoYotta eine farblich 100 % korrekte Wiedergabe erreichen, die einem genauen Referenztest standhält.
Der Vorteil hierbei ist, dass du bei diesen, im Gegensatz zu FCP, einfach mehr Flexibilität hast, was den Import von Quellmaterial und den Export auf verschiedene Zielmedien anbelangt – von Class-A-Referenzmonitoren bis hin zum DCP fürs Kino. Da bist du bei FCP komplett in der Sackgasse, weil Apple denkt, alles vollautomatisch erledigen zu müssen, ohne die Ansprüche des Anwenders oder des Zielmediums zu kennen.
Du hast z. B. in FCP einfach keine Möglichkeit, ohne externe Konvertierungen auf der Input-Seite ein Cineon-File zu lesen und auf der Output-Seite ein DCP-konformes Master zu erstellen.


Bevor weiter darüber diskutiert wird, was FCP angeblich kann und andere NLEs wie DaVinci Resolve nicht, ist hier ein anschauliches Beispiel anhand eines Tests, durchgeführt auf einem handelsüblichen Mac Mini M1, angeschlossen an einen Lenovo ThinkVision Pro 32 Zoll 4K-Monitor.

Als Testmaterial wurden zwei Standard-Testcharts verwendet: zum einen ein MacBeth ColorChecker Chart, zum anderen das Kodak Marcie LAD Test Image. Beide Dateien liegen als unkomprimierte 16-Bit-TIFFs vor.

Zum Testaufbau: Sowohl FCPX als auch DaVinci Resolve laufen auf dem M1. Die Testbilder wurden jeweils geladen und auf der Timeline platziert, um sie im Master Viewer anzuzeigen. Es wurden keinerlei farbliche Veränderungen an den Dateien vorgenommen. Die Master Viewer von FCPX und DaVinci Resolve wurden nebeneinander angeordnet, sodass beide Ansichten gleichzeitig auf dem Monitor dargestellt wurden.

Von diesem Bildschirm wurde anschließend mittels macOS ein Screenshot erstellt und mittels Preview als JPEG in 100 % Qualität gespeichert. Anhand dieses Screenshots lässt sich eindeutig erkennen, dass sowohl DaVinci Resolve als auch FCPX die exakt gleichen Farbwerte der Testcharts wiedergeben.





Weia, ich weiß ehrlich gesagt nicht, wie Du zu dem Schluss kommst, dass nur FCPX unter macOS Farben korrekt wiederzugeben vermag und kein anderes NLE dazu in der Lage sei. Diese Aussage ist schlichtweg falsch – und genau das zeigt dieser Test eindeutig. Lade Dir die Bilder herunter und überprüfe die Farbwerte beider Viewer selbst in Photoshop oder Affinity Photo mithilfe des Color Pickers. Wenn Du willst stelle ich dir auch die Original Charts zur Verfügung. DaVinci kannst Du frei herunterladen und FCPX hast Du ja. Du kannst somit das Ergebnis jederzeit reproduzieren und verifizieren.

Natürlich muss man wissen, wie man mit DaVinci Resolve umgeht, um diese Kontinuität und ein korrektes Farbmanagement auf dem Mac zu erreichen. In den zwei folgenden Screenshots sieht man, welche drei Parameter in DaVinci gesetzt werden müssen, damit sich die Software wie eine macOS-native Anwendung verhält und das Farbmanagement korrekt umgesetzt wird.





Aber genau dafür gibt es Handbücher. Die Aussage „FCPX macht das automatisch“ ist keine Ausrede. Wer professionell mit Videosoftware arbeitet, muss sich ernsthaft mit ihr auseinandersetzen – und sollte keine falschen Behauptungen aufstellen, nur weil das nötige Wissen über die genannten Anwendungen fehlt. Stichwort 1-1-1 oder 1-2-1 Tagging von rec.709 Material.





Zum wiederholten Male, Final Cut Pro ist keineswegs das einzige Schnittprogramm unter MacOS, das korrektes Farbmanagement beherrscht. Solche Behauptungen sind schlichtweg die Verbreitung falscher Informationen. FCPX als „grandioses Stück Software“ zu bezeichnen, ist zudem stark übertrieben. Ja, man kann damit schneiden – aber viele Dinge funktionieren nur über Umwege oder sind gar nicht möglich.


Die "alte Hasen"-Aussage trifft wohl eher auf dich selbst zu, da du kategorisch andere Programme außer FCP ablehnst, ohne diese jedoch wirklich im Detail zu kennen. Du gehst dann hin und bestehst auf falschen Aussagen über diese Programme in Bezug auf das Farbmanagement. Das zeigt sich schon daran, dass dir die korrekten Einstellungen in DaVinci nicht bekannt sind, um 1-1-1 getaggtes Rec.709-Material ohne Aufsteilung und mit korrektem Gamma 1.96 zu betrachten. Siehe dazu obige obige Screenshots.

Auch das stimmt nur teilweise. Shake wurde in erster Linie von Apple nicht weiterverfolgt, weil das Unternehmen erkannte, dass es mit Shake auf das falsche Pferd gesetzt hatte und Nuke im Vormarsch war. Nuke ist heute der industrieweite Standard im Bereich Compositing, dem Shake nichts mehr entgegenzusetzen hatte. Daher wurde Shake eingestellt, und der Source-Code konnte eine Zeit lang sogar von Apple erworben werden.


Kannst du bitte erklären, was du unter „vollkommen unterschiedlich“ im Bezug auf den Projektaufbau anderer NLEs verstehst? Ich würde mich über handfeste Beispiele freuen, anstatt pauschaler Aussagen.

Danke!

Also das hört sich mehr nach dem Aufbau eines Bildsensors, als nach dem menschlichen Auge an: im Auge gibt es keine "Pixel", sondern Sehzellen. Die befinden sich in der Retina. Die Retina ist bereits Teil des Gehirns, denn es gibt nicht nur Bottom Up sondern auch Top Down-Prozesse (z.B die Sakkaden-Steuerung). Es gibt zwar bereits eine Menge Querverarbeitung über benachbarte Sehzellen hinweg, aber der direkte Vergleich benachbarter Sehzellen wäre mir neu. In den visuellen Arealen der beiden Occipetallappen finden solche Vergleiche dagegen statt, nicht nur um Kontrast, sondern auch um Bewegung usw. zu detektieren; daran sind aber ganze Säulen von Neuronen beteiligt und nicht nur zwei einzelne Sehzellen.

Frag einfach einen Biologen, der sich mit der Sensorik im Auge auskennt oder lies Hoymar von Ditfurth.

Hmm… 🫣

Die Wissenschaft, die sich mit den Wahrnehmungsprozessen im Auge bzw. auf der Sehbahn am besten auskennt ist die Psychologie, nicht die Biologie. Überschneidungen gibt es noch zwischen Psychologie und Medizin in Form des Fachs Physiologie. Hoymar von Ditfurth wiederum ist Psychiater und Neurologe, also ein Mediziner mit zwei Facharztausbildungen. Die Medizin ist jedoch wie bereits erwähnt nicht die dezidierte Wissenschaft um wahrnehmungspsychologische Prozesse, die in der Sehbahn stattfinden zu erklären.

Die Diskussion erinnert mich an einen Blog-Artikel und an dieWebsite "Is my blue your blue?", die ich ganz witzig fand. Es wird einige Male hintereinander gefragt, ob eine Farbe grün oder blau sei.
Die Ergebnisse werden als S-Kurve dargestellt, die zeigt, wie viel Prozent der Bevölkerung eine bestimmte Farbe als "blau" kategorisiert. Was dabei auffällt: Die meisten Menschen haben ähnliche Blau-Grün-Grenzen - sonst gäbe es keine S-Kurve, sondern eine flache Verteilung.
(Blog von Dr. Drang, oft lesenswert)
(Is my blue your blue)

Ich weiß, ich habe alle seine Bücher.

Hier wird von rezeptiven Feldern gesprochen.
https://www.spektrum.de/lexikon/neurowissenschaft/kontrastverstaerkung/6682

Semmelrocc
Irrt der Bot hier nicht? Denn Apples Weg ist ja gerade einer, der maximale Flexibilität erlaubt. Die anderen Lösungen, welche die Farben und Kontraste vor der Ausgabe in bestimmte Richtungen biegen, die mindern die Flexibilität doch. Wenn man bestimmte Effekte mag, kann man die auch bewusst einsetzen, statt dem Workflow und dessen eingebauten Traditionen ausgeliefert zu sein.

Ja, jetzt kommt in dieser Diskussion noch die Mathematik hinzu. Die Seite "Is my blue your blue?" nagelt einen ja ganz schön fest, die feinsten Unterschiede zu diskriminieren. Für das Individuum frustrierend, wenn man merkt, "oh ist das Türkis, von vorhin nicht mehr blau gewesen, als das Türkis von jetzt?" Aber statistisch natürlich sehr interessant bei riesiger Stichprobe, wenn sich dann wie magisch eine S-Kurve ergibt!

In dem Artikel geht es im Wesentlichen um die laterale Hemmung im Nervensystem. Das ist systemisch zu verstehen: bei der Reizweiterleitung innerhalb der Retina findet zwar eine Hemmung statt, die von benachbarten Sehzellen ausgeht, die aber erst im Laufe der weiteren Signalverarbeitung hin zum Gehirn ihre Wirkung entfaltet. Je nachdem welche Zelltypen man betrachtet, hat die laterale Hemmung unterschiedliche Bedeutung, so können die Zapfen die Signale der Stäbchen hemmen. Ich hatte das oben etwas salopp mit "Es gibt zwar bereits eine Menge Querverarbeitung über benachbarte Sehzellen hinweg" beschrieben. Bei den optischen Wahrnehmungstäuschungen usw. die ja auch für das Thema dieser Diskussion relevant sind, hat jedoch schon viel mehr Signalverarbeitung zum Gehirn hin (also Bottum Up) stattgefunden. Die Signalverarbeitung in einem Bildsensor ist dagegen nicht systemisch in diesem Sinn. Dort können die diskreten Signalwerte einzelner benachbarter Pixel zu bestimmten Zwecken nach dem Auslesen miteinander verrechnet werden. Ich finde den Artikel sehr passend zu dieser Diskussion ausgewählt, weil er die Brücke von den Struktureigenschaften des Nervensystems hin zum Farbmanagement in der digitalen Bildverarbeitung baut.

Ja und nein. Der Tenor in diesem Thread hier geht ja von der These aus, dass Apple im Gegensatz zu allen anderen quasi einen Sonderweg beschreitet, indem es eben nicht auf die historischen Bildbearbeitungs-Workflows der Filmindustrie aufsetzt. So hatte ich dann auch meine Frage an die KI formuliert und entsprechend die Antwort erhalten. 😉

Mir ist gerade aufgefallen, dass ich an einer Stelle mit den Zitaten durcheinandergeraten bin und statt vermeintlich FlyingSloth mich selbst zitiert habe, um mir dann zu widersprechen. 😳 Das ist natürlich Blödsinn, sorry für die Verwirrung 😵‍💫:
Es ist also nicht exakt umgekehrt, sondern zweimal dasselbe … 🙄

Das sollte behandelt werden...

PS: übrigens tolle Diskussion.

Lichttherapie…?

Ohne, dass ich jetzt behaupten kann, mich super mit dem Thema Videoschnitt auszukennen: Wenn eine Software benötigte Funktionen mit einem Plugin nachrüsten kann, ist das zwar etwas anderes, als würden diese Funktionen nativ unterstützt werden, aber unter dem Strich gesehen sind diese Funktionen de facto vorhanden -- wenn auch nur mit einem zusätzlichen Installationsaufwand. Den man auch nur exakt einmal ausführen muss.
Solche spezialisierten Plugins werden von den Kameraherstellern selbst bereitgestellt und auf dem aktuellen Stand gehalten, weil sie ja selbst ein Interesse daran haben, dass deren Modelle Unterstützung finden. Zudem sind zwei der drei genannten Plugins kostenlos, das dritte wird für $79,99 angeboten -- Peanuts für ein so wichtiges Tool.
Ich sehe diesen Tatbestand, Funktionen nachrüsten zu müssen, also nicht unbedingt als Nachteil an.