Neues Apple ProRes RAW Format angekündigt // NAB 2018

[Frank Glencairn]

DANKE!

Ich kann ja hier hunderttausend Posts schreiben - aber - SORRY Frank ;-),
guckst Du hier, Seite 101:

LOL - Als Resolve Beta Tester kenn ich das Handbuch fast auswendig - aber danke für den Hinweis :-)

Und wo genau soll da was stehen, das deine kruden Theorien bestätigt?
Ich kann da beim besten Willen nix entdecken.

Steht da irgendwo, daß die raw Tabs eigentlich völlig unsinnig und überflüssig sind,
und kein Mensch raw Tabs braucht, weil man mit den Colorwheels das selbe machen kann?

[WoWu]

Es ist doch weder das Eine, noch das Andere allein gültig.
Es gibt genügend Kameras im unteren bis mittleren Segment, die über derart schlechte Verarbeitung im Prozessweg verfügen und auf Dinge, wie Störabstand pfeifen, dass man dann auch sämtliche Ableiche im RGB Raum vornehmen kann.
Ebenso, wie es reichlich Codecs gibt, deren Signal gar nicht direkt dem Sensorsignal entsprechen sondern nur in der Übertragungsfunktion flach sind.

Nun kann man spekulieren ... eins steht nur ziemlich fest. Hat man es mit einem „echtem“ RAW zu tun und ist man gezwungen De-Mosaicing von unterschiedlichen Kameras durchzuführen, wird man um die üblichen Stellparameter nicht herum kommen.
Und legt man Wert auf hochwertige Zielbilder auch nicht darum, auf möglichst geringe Artefakte zu achten, wie zuvor schon beschrieben. Dazu gehören aber eben auch Rauschanteile, die man möglichst gering halten wird.
Das gelingt nicht so gut im RGB Raum, weil die Signale bereits aus mehreren Quellen belastet sind, wie im RAW Signal, in dem man es mit der Minimalmenge an Rauschen zu tun hat.
Das Alles kann man, meiner Meinung nach, überhaupt noch nicht auf PRR beziehen, weil es noch reine Spekulation ist, um was für ein Signal es sich handelt, noch dazu nicht mal klar ist, wie Prozesse in FCP mit unterschiedlichen CFRs umgehen.
Dazu gibt es lediglich die üblichen Spekulationen im Netz, die überhaupt nicht belastbar sind.
Die Kenntnis über die bisherigen RAW Verfahren ist aber aus der Historie bestens bekannt. Nur lässt sie sich bisher mit dem, was wir über PRR „erfahren“ haben (nämlich nichts Konkretes) in Einklang bringen.
Wir können noch nichtmal mit Sicherheit sagen, ob es überhaupt ein echtes RAW Signal ist, denn dafür sind die bisherigen „Erkenntnisse“ viel zu widersprüchlich.

Warum warten wir also nicht einfach mal ab ...
Und noch eins ... in Franks Beitrag oben ist es schon angeklungen.... wer Codes einzig an seiner Perfomanz misst, scheint sich die Frage nach Bildqualität nicht mehr zu stellen.
Insofern divergieren hier die jeweiligen Zielanforderungen ohnehin.

[Roland Schulz]

Frank, ...da steht:
„RAW decoding is the very first image processing operation that takes place, and it takes place before all other operations in the color page...“

Wie in meinen ganzen Links so auch in Resolve und dort AUCH im Raw Dialog!!

debayering first!!


Dass Du zu unterschiedlichen Ergebnissen kommst liegt zum einen daran dass die „Color Wheels“ und andere Tools ggf. ein etwas abweichendes Ergebnis liefern als der Raw Dialog, zum anderen dass Du die anderen Werkzeuge ggf. nicht „richtig“ angewendet hast bzw. die entsprechenden Parameter nicht genau genug getroffen hast.

Da wir u.A. in Resolve aber mit 32bit-FP arbeiten haben wir nach dem (!) „RAW decoding“ aber mit „keinen“ qualitativen Nachteilen zu rechnen.

[Roland Schulz]

Es ist doch weder das Eine, noch das Andere allein gültig.
Es gibt genügend Kameras im unteren bis mittleren Segment, die über derart schlechte Verarbeitung im Prozessweg verfügen und auf Dinge, wie Störabstand pfeifen, dass man dann auch sämtliche Ableiche im RGB Raum vornehmen kann.
Ebenso, wie es reichlich Codecs gibt, deren Signal gar nicht direkt dem Sensorsignal entsprechen sondern nur in der Übertragungsfunktion flach sind.

Nun kann man spekulieren ... eins steht nur ziemlich fest. Hat man es mit einem „echtem“ RAW zu tun und ist man gezwungen De-Mosaicing von unterschiedlichen Kameras durchzuführen, wird man um die üblichen Stellparameter nicht herum kommen.
Und legt man Wert auf hochwertige Zielbilder auch nicht darum, auf möglichst geringe Artefakte zu achten, wie zuvor schon beschrieben. Dazu gehören aber eben auch Rauschanteile, die man möglichst gering halten wird.
Das gelingt nicht so gut im RGB Raum, weil die Signale bereits aus mehreren Quellen belastet sind, wie im RAW Signal, in dem man es mit der Minimalmenge an Rauschen zu tun hat.
Das Alles kann man, meiner Meinung nach, überhaupt noch nicht auf PRR beziehen, weil es noch reine Spekulation ist, um was für ein Signal es sich handelt, noch dazu nicht mal klar ist, wie Prozesse in FCP mit unterschiedlichen CFRs umgehen.
Dazu gibt es lediglich die üblichen Spekulationen im Netz, die überhaupt nicht belastbar sind.
Die Kenntnis über die bisherigen RAW Verfahren ist aber aus der Historie bestens bekannt. Nur lässt sie sich bisher mit dem, was wir über PRR „erfahren“ haben (nämlich nichts Konkretes) in Einklang bringen.
Wir können noch nichtmal mit Sicherheit sagen, ob es überhaupt ein echtes RAW Signal ist, denn dafür sind die bisherigen „Erkenntnisse“ viel zu widersprüchlich.

Warum warten wir also nicht einfach mal ab ...
Und noch eins ... in Franks Beitrag oben ist es schon angeklungen.... wer Codes einzig an seiner Perfomanz misst, scheint sich die Frage nach Bildqualität nicht mehr zu stellen.
Insofern divergieren hier die jeweiligen Zielanforderungen ohnehin.

Warum sollten wir u.U. im debayerten RGB Signal u.A. mehr Rauschen haben als im RAW Signal, das erschließt sich mir nicht?!
Welche Gründe könnte das haben?!
Wir könnten eigentlich nur Quantisierungsrauschen erhalten wenn wir in eine kleine Quantisierung/Bittiefe interpolieren - das hatte ich aber immer ausgeschlossen (Zielbittiefe >= RAW Bittiefe).
Resolve macht hier 32bit FP - denke da ist jede praktische Kamera WEIT von weg.

Und ja, welche Qualität das „high speed“ debayerte Bild hat steht klar noch in Frage. Das könnte am Ende ggf. „schlechter“ aussehen als ein OOC Bild wenn das Debayering dort hochwertiger ist.

Weiter richtig - sehr viel Spekulation bis hierher. Ggf. sollten wir Erfahrungen und weitere Untersuchungen abwarten.
Auf jeden Fall erzeugt das alles ne Menge Interesse und Diskussionen.
Ich find‘s interessant und ggf. hat das ganze gewisse Chancen.

Nacht zusammen...

[Axel]

Frank, bring mal einen einzigen belastbaren Nachweis dass irgendwer im RAW->RGB Workflow die RAW Daten anpasst und sag uns welchen Sinn das ergeben sollte.

Vielleicht kann ich da ganz schüchtern aushelfen. In ACR gilt das Öffnen eines Raw-Standbildes als Vorstufe zu weiterer Nachbarbeitung. Sobald man das Raw-Bild im normalen Photoshop öffnet, hat man alle Parameter festgelegt, die normalerweise in der Kamera festgelegt würden, inklusive Weißabgleich, Belichtung (bei BM-Kameras ist z.B. ISO nichts anderes als Gamma, eingebacken durch Kompression oder nicht), Konturenschärfung, Rauschunterdrückung, Objektivkorrektur usw.. Aber im HSL-Tab lässt sich eine komplette "Color Science" festlegen (und natürlich als Profil speichern). Dieses Werkzeug erscheint vielen als so mächtig, dass sie es missbrauchen, um ordinäre JPEGs mit ACR zu öffnen und deren Farben sehr intuitiv anpassen zu können.

Im Photoshop-Klon (in manchem besser, in manchem schwächer) Affinity müssen Raw-Dateien die "Develop-Persona" durchlaufen, bevor sie zur "Photo-Persona" werden können. Eine Metamorphose!

Im Vergleich dazu ist Resolves CR ziemlich bescheiden. Aber es besagt, dass eine Raw-Datei besser zuerst interpretiert wird aufgrund von Metadaten aus der Kamera.

In FCP gibt es nur "Farbtemperatur" und der original vom Kameramann gewählte Wert wird nicht angezeigt, jedoch offenbar dennoch stillschweigend für eine erste Interpretation (das ist das "Entwickeln") herangezogen. Daher sieht der "Serviervorschlag" der Aladin-Lampe aus, wie man ihn bei 4300°K (Daten von der Mini-App "Mediainfo") erwarten würde. FCP liefert also eine vollautomatische Entwicklung. Will ich, wenn ich mir Raw "anlache" (wolfgang), einen solchen Schritt? Aus dem Atomos direkt in die "My Video Persona"? Sind das bloß sinnfreie Etiketten?

Frag mal einen Photoshop-Nutzer.

Hier noch der Hinweis zu analogem Entwickeln von Negativen, dass es Techniken wie das Flashen oder Pushen gab, um Einfluss auf das Endergebnis zu haben. Dinge, die nicht vollumfänglich beim "Vergrößern" (die normalen Photoshop-Tools haben ihre Vorbilder in der Dunkelkammer) erzielt werden konnten.

Stell dir vor, du hast hundert Raw-Clips in einer Sequenz, und du musst sie alle graden.

Erleuchte mal kurz: was ist für dich der Unterschied zu 100 Nicht-raw-Clips, die man graden muss?

Auf Seite der zur Verfügung stehenden Farbwerkzeuge und daher der Wahrnehmung des Materials durch den Nutzer: in FCP kein Unterschied!

Wenn ich mir aber Raw "anlache" (wolfgang), dann möchte ich wohl in größerem Umfang Einfluss auf Farbe nehmen. FCP 10.3 war ein genialer Allrounder mit seiner kleinen Farbtafel, die zugleich eine Eigenschaft und ein Effekt war. Sie wurde oft ausgelacht, aber nur von Outsidern. Ich schrieb mal, mit ihr kann man 95% von dem erreichen, was man in Resolve tut, aber mit nur 5% Zeitaufwand.

Das galt aber für Farbkorrektur, für einfaches Aufpolieren von normalem Video. Maximal ein oder höchstens zwei zusätzliche sekundäre Schritte. Danach begann das Verhältnis zugunsten von Resolve zu kippen. Es gibt in FCP kein einfaches Organisationsprinzip für die Arbeitsschritte (wie die Nodes), keine Lösung, um eine Referenz anzeigen zu lassen. Seit Dezember gibt es mehr Werkzeuge, aber das neue Color-Tab, in dem sie leben, hat leider nichts daran geändert.

In Bezug auf den Schnitt schrieb ich oft, man müsste schon im Detail Arbeitsabläufe vergleichen, um zu sehen, welcher NLE benutzerfreundlicher sei. Klicks, Tastenbedienungen (eine Taste oder nur mit einer oder mehreren Modifyer-Tasten?) und unvermeidliche Mausbewegungen zählen. Da gewinnt FCP immer. Bei Farbe verliert es sehr schnell.

Color Finale und zumal Chromatic hatten das schon etwas besser hingekriegt (letzteres sogar mit Mocha-Tracker, Masken ohne Tracking sind ja auch doof, übrigens Chromatic nur heute noch mit 30% Preisnachlass!). Apple hat es verpfuscht. Ich hoffe, das geht nicht so weiter. Ein paar Minuten lang gab es in der amerikanischen Update-Information für 10.4.1 den Hinweis auf integrierte Rauschunterdrückung. Jemand hat einen Screenshot gemacht:


Bitte nicht weiter so! Hört auf, Features dazuzustopfen, die Drittanbieter besser machen. Konzentriert euch auf Medienorganisation und Schnitt!

[Sammy D]

Frank, ...da steht:
„RAW decoding is the very first image processing operation that takes place, and it takes place before all other operations in the color page...“

Wie in meinen ganzen Links so auch in Resolve und dort AUCH im Raw Dialog!!

debayering first!!
...

Dann musst du eine andere Bedienungsanleitung gelesen haben...

Der erste Schritt ist De-bayering, ja, hier auch camera raw decoding genannt. Und genau in diesem Schritt des Dekodierens befinden wir uns (siehe Diagramm). Hier legt man die Parameter fest, wie der RAW-Processor in Resolve sie in die Image-Pipeline bringt: "Using theses parameters in the Camera Raw panel, you can override the original camera metadata that was written at the time of recording". Unter Camera metadata wird hier Farbtemperatur und Belichtung aufgefuehrt.
Ferner kann man die decode quality und die decode settings einstellen. Betonung auf decode!
Erst nach der Entwicklung (decoding) gehts zur color page/ image processing. Wie in jedem anderen raw processor auch.

[nic]

Also zumindest für redraw kann ich mit Sicherheit sagen, dass tatsächlich vor ISO-Interpretation (Gain), Weißabgleich und selbst der 'highlight-extension' das demosaicing durchgeführt wird. Dass die Ergebnisse der Anpassungen im RAW-Dialog trotz allem nicht identisch mit den Anpassungen danach ausfallen (können), liegt daran, dass die durch das r3d-Modul vorgenommenen Korrekturen die (nur dem Hersteller bekannten) Sensoreigenheiten (Colorimetry, ...) miteinbeziehen. Sämtliche raw-Einstellungen werden auf das in Fließkommazahlen debayerte Bild durchgeführt und inkludieren alle im raw-Zustand vorhandenen Informationen. Dem NLE oder Gradingprogramm werden die verarbeiteten Daten dann als Integer in der erwarteten Bittiefe übergeben.

[Frank Glencairn]

Frank, ...da steht:
„RAW decoding is the very first image processing operation that takes place, and it takes place before all other operations in the color page...“

Wie in meinen ganzen Links so auch in Resolve und dort AUCH im Raw Dialog!!

debayering first!!

Zunächst einmal widerspricht der erste Satz nicht dem, was ich sage, sondern er bestätigt es: Das Decoding (Raw Tab) ist ein eigener Prozess, der getrennt von allen anderen Prozessen, und vor allen anderen Prozessen (Colorwheels) passiert.

Debayering ist nur ein Teil des Decoding und nicht das selbe. Beim Decoding im RAW Tab werden eben nicht nur die Debayering Parameter gesetzt, sondern halt auch alle anderen, die in das Decoding nach RGB einfließen.

Dass Du zu unterschiedlichen Ergebnissen kommst liegt zum einen daran dass die „Color Wheels“ und andere Tools ggf. ein etwas abweichendes Ergebnis liefern als der Raw Dialog, zum anderen dass Du die anderen Werkzeuge ggf. nicht „richtig“ angewendet hast bzw. die entsprechenden Parameter nicht genau genug getroffen hast.

Naja, ich hab Ende der 90er Farbkorrektur auf einer DaVinci Renaissance 8:8:8 gelernt, hab das an der Uni unterrichtet, und heute bin ich Resolve Beta Tester, sprich ich setze mich jetzt gut 20 Jahre intensiv damit auseinander - ich schätze mal daß das "richtige Anwenden der Werkzeuge" schon so einigermaßen im Griff hab.

[Roland Schulz]

Frank, bring mal einen einzigen belastbaren Nachweis dass irgendwer im RAW->RGB Workflow die RAW Daten anpasst und sag uns welchen Sinn das ergeben sollte.

Vielleicht kann ich da ganz schüchtern aushelfen. In ACR gilt das Öffnen eines Raw-Standbildes als Vorstufe zu weiterer Nachbarbeitung. Sobald man das Raw-Bild im normalen Photoshop öffnet, hat man alle Parameter festgelegt, die normalerweise in der Kamera festgelegt würden, inklusive Weißabgleich, Belichtung (bei BM-Kameras ist z.B. ISO nichts anderes als Gamma, eingebacken durch Kompression oder nicht), Konturenschärfung, Rauschunterdrückung, Objektivkorrektur usw.. Aber im HSL-Tab lässt sich eine komplette "Color Science" festlegen (und natürlich als Profil speichern). Dieses Werkzeug erscheint vielen als so mächtig, dass sie es missbrauchen, um ordinäre JPEGs mit ACR zu öffnen und deren Farben sehr intuitiv anpassen zu können.

Im Photoshop-Klon (in manchem besser, in manchem schwächer) Affinity müssen Raw-Dateien die "Develop-Persona" durchlaufen, bevor sie zur "Photo-Persona" werden können. Eine Metamorphose!

Im Vergleich dazu ist Resolves CR ziemlich bescheiden. Aber es besagt, dass eine Raw-Datei besser zuerst interpretiert wird aufgrund von Metadaten aus der Kamera.

In FCP gibt es nur "Farbtemperatur" und der original vom Kameramann gewählte Wert wird nicht angezeigt, jedoch offenbar dennoch stillschweigend für eine erste Interpretation (das ist das "Entwickeln") herangezogen. Daher sieht der "Serviervorschlag" der Aladin-Lampe aus, wie man ihn bei 4300°K (Daten von der Mini-App "Mediainfo") erwarten würde. FCP liefert also eine vollautomatische Entwicklung. Will ich, wenn ich mir Raw "anlache" (wolfgang), einen solchen Schritt? Aus dem Atomos direkt in die "My Video Persona"? Sind das bloß sinnfreie Etiketten?

Frag mal einen Photoshop-Nutzer.

Hier noch der Hinweis zu analogem Entwickeln von Negativen, dass es Techniken wie das Flashen oder Pushen gab, um Einfluss auf das Endergebnis zu haben. Dinge, die nicht vollumfänglich beim "Vergrößern" (die normalen Photoshop-Tools haben ihre Vorbilder in der Dunkelkammer) erzielt werden konnten.

Stell dir vor, du hast hundert Raw-Clips in einer Sequenz, und du musst sie alle graden.

Erleuchte mal kurz: was ist für dich der Unterschied zu 100 Nicht-raw-Clips, die man graden muss?

Auf Seite der zur Verfügung stehenden Farbwerkzeuge und daher der Wahrnehmung des Materials durch den Nutzer: in FCP kein Unterschied!

Wenn ich mir aber Raw "anlache" (wolfgang), dann möchte ich wohl in größerem Umfang Einfluss auf Farbe nehmen. FCP 10.3 war ein genialer Allrounder mit seiner kleinen Farbtafel, die zugleich eine Eigenschaft und ein Effekt war. Sie wurde oft ausgelacht, aber nur von Outsidern. Ich schrieb mal, mit ihr kann man 95% von dem erreichen, was man in Resolve tut, aber mit nur 5% Zeitaufwand.

Das galt aber für Farbkorrektur, für einfaches Aufpolieren von normalem Video. Maximal ein oder höchstens zwei zusätzliche sekundäre Schritte. Danach begann das Verhältnis zugunsten von Resolve zu kippen. Es gibt in FCP kein einfaches Organisationsprinzip für die Arbeitsschritte (wie die Nodes), keine Lösung, um eine Referenz anzeigen zu lassen. Seit Dezember gibt es mehr Werkzeuge, aber das neue Color-Tab, in dem sie leben, hat leider nichts daran geändert.

In Bezug auf den Schnitt schrieb ich oft, man müsste schon im Detail Arbeitsabläufe vergleichen, um zu sehen, welcher NLE benutzerfreundlicher sei. Klicks, Tastenbedienungen (eine Taste oder nur mit einer oder mehreren Modifyer-Tasten?) und unvermeidliche Mausbewegungen zählen. Da gewinnt FCP immer. Bei Farbe verliert es sehr schnell.

Color Finale und zumal Chromatic hatten das schon etwas besser hingekriegt (letzteres sogar mit Mocha-Tracker, Masken ohne Tracking sind ja auch doof, übrigens Chromatic nur heute noch mit 30% Preisnachlass!). Apple hat es verpfuscht. Ich hoffe, das geht nicht so weiter. Ein paar Minuten lang gab es in der amerikanischen Update-Information für 10.4.1 den Hinweis auf integrierte Rauschunterdrückung. Jemand hat einen Screenshot gemacht:


Bitte nicht weiter so! Hört auf, Features dazuzustopfen, die Drittanbieter besser machen. Konzentriert euch auf Medienorganisation und Schnitt!

Alles gut und schön, aber auch hier verändern wir im Post keine RAW Informationen mehr sondern nehmen Veränderungen auf den durch Debayering gewonnenen RGB Daten vor.

[Axel]

Alles gut und schön, aber auch hier verändern wir im Post keine RAW Informationen mehr sondern nehmen Veränderungen auf den durch Debayering gewonnenen RGB Daten vor.

Camera-Raw - man könnte es gewagt übersetzen mit "Kamera-Raw" - erlaubt Eingriff in die Metadaten, die von der Kamera mitgeliefert werden. Es mag sehr wohl sein, dass die Unterscheidung akademisch ist, weil die Hauptleistung, das Anzeigen eines RGB-Bildes, da schon stattgefunden hat, aber eben mit Hilfe von ganz bestimmten Werten. Wysiwyg.

Aus demselben Grund, aus dem in allen Farbkorrektur-Handbüchern und -tutorials immer wieder auf die Bedeutung der richtigen Reihenfolge beim Workflow hingewiesen wird, ist es allein aus der Anschauung des Bearbeiters heraus besser (oder wenn man es streng nimmt unerlässlich), die technische Interpretation des Ausgangsbildes von der kreativen Arbeit am so "entwickelten" Bild zu trennen. Selbst wenn, wie hier, die Software sagt, okay, hab die Metadaten erfasst, uninteressantes technisches Gewäsch für dich, fang mit Graden an! Der Slider "Temperatur" ist anscheinend nichts anderes, als wenn ich in der Farbtafel den "Global"-Puck auf 220° bringe und bei gehaltener Shift-Taste hoch und runter bewege. Addieren bzw. Subtrahieren von Blau bzw. Orange. Sagt mir, was ihr wollt: das fühlt sich nicht so an wie eine Änderung des CR-Weißabgleichs!

Farbkorrektur ist wegen des wysiwyg-Prinzips der reinste Datenhäcksler. Würde ich einen Look auflegen, bevor ich primäre Farb- und Helligkeitsbalance durchgeführt habe, bliebe nur Matsche übrig. Begönne ich einen Eingriff in ein vorentwickeltes Raw-Bild (wie von FCP mir aufgezwungen) mit Instrumenten, die dieselben sind, mit denen ich am Look arbeite, ...

[Roland Schulz]

Frank, ...da steht:
„RAW decoding is the very first image processing operation that takes place, and it takes place before all other operations in the color page...“

Wie in meinen ganzen Links so auch in Resolve und dort AUCH im Raw Dialog!!

debayering first!!
...

Dann musst du eine andere Bedienungsanleitung gelesen haben...

Der erste Schritt ist De-bayering, ja, hier auch camera raw decoding genannt. Und genau in diesem Schritt des Dekodierens befinden wir uns (siehe Diagramm). Hier legt man die Parameter fest, wie der RAW-Processor in Resolve sie in die Image-Pipeline bringt: "Using theses parameters in the Camera Raw panel, you can override the original camera metadata that was written at the time of recording". Unter Camera metadata wird hier Farbtemperatur und Belichtung aufgefuehrt.
Ferner kann man die decode quality und die decode settings einstellen. Betonung auf decode!
Erst nach der Entwicklung (decoding) gehts zur color page/ image processing. Wie in jedem anderen raw processor auch.

Das steht so in der von mir verklinkten Anleitung und ich habe auch nichts anderes behauptet. Debayering first. Nirgends steht dass irgendwelche Parameter Einfluss auf das Debayering haben, außer in Bezug auf die Qualität (schnell/qualitativ höherwertig). Es ist auch nicht notwendig dass Metadaten Einfluss auf das Debayering haben.
Hier gibt es wie in den anderen von mir geposteten Links keine Rückwirkungen die aufgezeigt sind. Alles (WB...) findet danach in RGB statt. Es wird "plain" debayert, nirgends steht dass es anders ist.

[Roland Schulz]

Alles gut und schön, aber auch hier verändern wir im Post keine RAW Informationen mehr sondern nehmen Veränderungen auf den durch Debayering gewonnenen RGB Daten vor.

Camera-Raw - man könnte es gewagt übersetzen mit "Kamera-Raw" - erlaubt Eingriff in die Metadaten, die von der Kamera mitgeliefert werden. Es mag sehr wohl sein, dass die Unterscheidung akademisch ist, weil die Hauptleistung, das Anzeigen eines RGB-Bildes, da schon stattgefunden hat, aber eben mit Hilfe von ganz bestimmten Werten. Wysiwyg.

Aus demselben Grund, aus dem in allen Farbkorrektur-Handbüchern und -tutorials immer wieder auf die Bedeutung der richtigen Reihenfolge beim Workflow hingewiesen wird, ist es allein aus der Anschauung des Bearbeiters heraus besser (oder wenn man es streng nimmt unerlässlich), die technische Interpretation des Ausgangsbildes von der kreativen Arbeit am so "entwickelten" Bild zu trennen. Selbst wenn, wie hier, die Software sagt, okay, hab die Metadaten erfasst, uninteressantes technisches Gewäsch für dich, fang mit Graden an! Der Slider "Temperatur" ist anscheinend nichts anderes, als wenn ich in der Farbtafel den "Global"-Puck auf 220° bringe und bei gehaltener Shift-Taste hoch und runter bewege. Addieren bzw. Subtrahieren von Blau bzw. Orange. Sagt mir, was ihr wollt: das fühlt sich nicht so an wie eine Änderung des CR-Weißabgleichs!

Farbkorrektur ist wegen des wysiwyg-Prinzips der reinste Datenhäcksler. Würde ich einen Look auflegen, bevor ich primäre Farb- und Helligkeitsbalance durchgeführt habe, bliebe nur Matsche übrig. Begönne ich einen Eingriff in ein vorentwickeltes Raw-Bild (wie von FCP mir aufgezwungen) mit Instrumenten, die dieselben sind, mit denen ich am Look arbeite, ...

...auch hier werden die Metadaten (WB...) auf das debayerte RGB Bild angewendet und können adaptiert werden, nirgends steht was anderes!
Das vorhandene RAW Bild wird zuerst 1:1 debayert, das steht da, da werden keine RAW Daten anhand von Metadaten verändert oder der Debayeringprozess angepasst.
Es gibt nirgends eine Rückwirkung auf das Debayering in den Blockschaltbildern. Die "Farbe", und das ist auch der WB, passiert danach. Das wäre anders viel zu kompliziert und bei Änderungen unnötig langsam. Das debayerte Bild liegt in hoher Quantisierung vor (Resolve 32bit FP). Da kann man alles "verlustfrei" mit machen da keine Kamera annähernd diese Quantisierung aufweist!

In manchen Kameras selbst findet wie Wowu richtig schrieb mitunter eine Anpassung der R,G,B Verstärkungen vor der Digitalsierung statt. Da macht es auch noch Sinn da die Quantisierung der ADCs ggf. kleiner ist als die Dynamik der Sensel. An RAW Daten selbst vor dem Debayern rumzubasteln macht aber keinen Sinn und niemand gibt einen Hinweis darauf.


Noch mal zurück auf den Track: Der RAW Converter selbst muss nicht zwingend Einfluss auf die Farben (WB...) erlauben, da das verlustfrei in späteren Schritten erfolgen kann, somit auch für FCPX Gültigkeit haben kann (wenn die interne Verarbeitung eine entsprechend hohe Quantisierung aufweist).

[Sammy D]

Dann musst du eine andere Bedienungsanleitung gelesen haben...

Der erste Schritt ist De-bayering, ja, hier auch camera raw decoding genannt. Und genau in diesem Schritt des Dekodierens befinden wir uns (siehe Diagramm). Hier legt man die Parameter fest, wie der RAW-Processor in Resolve sie in die Image-Pipeline bringt: "Using theses parameters in the Camera Raw panel, you can override the original camera metadata that was written at the time of recording". Unter Camera metadata wird hier Farbtemperatur und Belichtung aufgefuehrt.
Ferner kann man die decode quality und die decode settings einstellen. Betonung auf decode!
Erst nach der Entwicklung (decoding) gehts zur color page/ image processing. Wie in jedem anderen raw processor auch.

Das steht so in der von mir verklinkten Anleitung und ich habe auch nichts anderes behauptet. Debayering first. Nirgends steht dass irgendwelche Parameter Einfluss auf das Debayering haben, außer in Bezug auf die Qualität (schnell/qualitativ höherwertig). Es ist auch nicht notwendig dass Metadaten Einfluss auf das Debayering haben.
Hier gibt es wie in den anderen von mir geposteten Links keine Rückwirkungen die aufgezeigt sind. Alles (WB...) findet danach in RGB statt. Es wird "plain" debayert, nirgends steht dass es anders ist.

Wie siehts dann mit Raw Convertern aus, wo man das Debayering abstellen, man aber trotzdem an den Metadaten drehen kann?

[Roland Schulz]

Wie siehts dann mit Raw Convertern aus, wo man das Debayering abstellen, man aber trotzdem an den Metadaten drehen kann?

Was soll das für ein "Converter" sein?! Beispiel?!
Du drehst zudem an Parametern die durch Metadaten voreingestellt sind, Du veränderst im Post nicht die Metadaten selbst denn dann würdest Du die Originaldatei ändern. Die Metadaten sind durch die Aufnahme fest eingebrannt und bilden den Istzustand bei der Aufnahme ab. Diese im Post zu ändern ist völlig unüblich.

[dienstag_01]

Ich möchte mal daran erinnern, um was es hier (im letzten Zweig dieser Diskussion) eigentlich geht: WB auf RAW oder RGB.
EIn Pixel, dessen Farbwerte ich nur kenne, wenn ich das Bayern-Pattern kenne (Punkt 1) kann ich ohne eine Interpolation der beiden anderen Farbwerte (Punkt 2) never ever in seiner Farbe verändern. Was WB macht.
Ob Resolve das in der Anordnung seiner Tabs sichtbar macht oder nicht, ist dafür völlig irrelevant.
Es gibt auch RAW-Konverter (z.B. Lightroom), die behalten komplett das RAW-Bild und schreiben die Anpassungen (auch alle Farbanpassungen, also viel mehr als Resolve) in eine xmp. Na und, ohne Debayering passiert da nichts.

[Axel]

Der Slider "Temperatur" ist anscheinend nichts anderes, als wenn ich in der Farbtafel den "Global"-Puck auf 220° bringe und bei gehaltener Shift-Taste hoch und runter bewege. Addieren bzw. Subtrahieren von Blau bzw. Orange. Sagt mir, was ihr wollt: das fühlt sich nicht so an wie eine Änderung des CR-Weißabgleichs!

Ich widerlege mich selbst. Ein Pocket DNG sowohl in FCP (Metadaten? Der Weißabgleich von 5600°K wird nirgendwo gelistet, aber das Bild sieht okay aus) als auch in Resolve geladen. >Farbtafel >Global und >Camera Raw >White Balance >Custom ist subjektiv gar kein Unterschied. Hmmm.

[Frank Glencairn]

Es gibt nirgends eine Rückwirkung auf das Debayering in den Blockschaltbildern.

Die Metadaten sind durch die Aufnahme fest eingebrannt und bilden den Istzustand bei der Aufnahme ab. Diese im Post zu ändern ist völlig unüblich.

Diese massive Anhäufung von völliger Ignoranz, gepaart mit mangelndem Fachwissen und Sturheit, in deinem Reality Distortion Field, das offensichtliche Beweise zuverlässig für dich filtert, ist wirklich beachtlich.

[Roland Schulz]

Ich möchte mal daran erinnern, um was es hier (im letzten Zweig dieser Diskussion) eigentlich geht: WB auf RAW oder RGB.
EIn Pixel, dessen Farbwerte ich nur kenne, wenn ich das Bayern-Pattern kenne (Punkt 1) kann ich ohne eine Interpolation der beiden anderen Farbwerte (Punkt 2) never ever in seiner Farbe verändern. Was WB macht.
Ob Resolve das in der Anordnung seiner Tabs sichtbar macht oder nicht, ist dafür völlig irrelevant.
Es gibt auch RAW-Konverter (z.B. Lightroom), die behalten komplett das RAW-Bild und schreiben die Anpassungen (auch alle Farbanpassungen, also viel mehr als Resolve) in eine xmp. Na und, ohne Debayering passiert da nichts.

..sehe ich auch so.
Ich kann zwar in der Farbe verändern, aber entweder nicht gezielt oder ich muss invers gebayert überlagern. Also bitte, das würde wirklich dem Aufwand x2 entsprechen!

[cantsin]

Das leuchtet in der Theorie ja ein. Nur ist in der Praxis merkwürdig, dass die Bildparameter-Regler, die Resolves Raw-Tab bzw. Adobes ACR zur Verfügung stellen, dann eigentlich genauso gut bei herkömmlichen Bildern (mit 12 oder 14bit Farbtiefe) funktionieren müsste.

[Roland Schulz]

Es gibt nirgends eine Rückwirkung auf das Debayering in den Blockschaltbildern.

Die Metadaten sind durch die Aufnahme fest eingebrannt und bilden den Istzustand bei der Aufnahme ab. Diese im Post zu ändern ist völlig unüblich.

Diese massive Anhäufung von völliger Ignoranz, gepaart mit mangelndem Fachwissen und Sturheit, in deinem Reality Distortion Field, das offensichtliche Beweise zuverlässig für dich filtert, ist wirklich beachtlich.

Frank, Dein "TEST" ist bis hierher dein einziger Versuch gewesen überhaupt irgendeinen Nachweis zu bringen. Den Test verwerfe ich aber mit der Begründung dass du in beiden Vorgängen was völlig unterschiedliches hast einstellen können da es auch gar keine identischen Stellgrößen in den Dialogen gibt. Das bedeutet aber nicht dass man nicht zum gleichen Ergebnis kommen kann.

Was kam dann noch dazu, wo ist Dein Fachwissen, wo sind die Belege wie es gemacht wird?! Da ist nichts oder habe ich was überlesen?! Ich habe zig Links von Blockschaltbildern gepostet und das Resolve Manual nach Hinweis zitiert. Alles zielt auf Debayering first was auch immer mehr andere hier stützen.

Ist mir aber auch langsam echt egal, Thema ist geklärt.

[Roland Schulz]

Das leuchtet in der Theorie ja ein. Nur ist in der Praxis merkwürdig, dass die Bildparameter-Regler, die Resolves Raw-Tab bzw. Adobes ACR zur Verfügung stellen, dann eigentlich genauso gut bei herkömmlichen Bildern (mit 12 oder 14bit Farbtiefe) funktionieren müsste.

Das tun sie auch und das will BMD mit 32bit FP auch sagen.

[Roland Schulz]

...noch zwei weitere für Debayering/Demosaicing first:





Frank - gib´ auf, Du hast keine Chance, komme mit erhobenen Händen raus ;-) ;-) ;-)

...oder zeig´ uns wo der WB etc. bei bereits vorhandenen RAW Daten noch vor dem Debayering adaptiert wird.

[Frank Glencairn]

...oder zeig´ uns wo der WB etc. bei bereits vorhandenen RAW Daten noch vor dem Debayering adaptiert wird.

Du bist hier der einzige, der davon faselt, daß die WB und anderes vor dem Debayering passieren - ich hab immer schon gesagt, das die Parameter im raw Tab die Parameter FÜR das Debayering sind. Aber das schnallst du einfach nicht.

[dienstag_01]

...oder zeig´ uns wo der WB etc. bei bereits vorhandenen RAW Daten noch vor dem Debayering adaptiert wird.

Du bist hier der einzige, der davon faselt, daß die WB und anderes vor dem Debayering passieren - ich hab immer schon gesagt, das die Parameter im raw Tab die Parameter FÜR das Debayering sind. Aber das schnallst du einfach nicht.

Eigentlich kotzen mich solche Sachen an, aber manchmal ist es unumgänglich (man wird hier sonst selbst als der Doofe hingestellt):

Ich rede jetzt nicht von irgendwelchen Sachen wie Blende, Linsentyp, Shutterspeed uns, sondern von ISO, WB, Belichtung, Tint etc. Die sind bei raw eben nur als Metadaten gespeichert, und daher in der Post vor dem Debayering veränderbar.

[Frank Glencairn]

Ja, das hätte ich genauer definieren sollen, also:

"...sondern von ISO, WB, Belichtung, Tint etc. Die sind bei raw eben nur als Metadaten gespeichert, und daher in der Post WÄHREND dem Debayering veränderbar.

[nic]

Ja, das hätte ich genauer definieren sollen, also:

"...sondern von ISO, WB, Belichtung, Tint etc. Die sind bei raw eben nur als Metadaten gespeichert, und daher in der Post WÄHREND dem Debayering veränderbar.

Richtiger wäre: Im Rahmen des 'raw-processing', wovon das 'demosaicing' eben ein Prozess ist, der in gängigen Verfahren tatsächlich vor der Farbbearbeitung liegt. Wobei man diese Farbbearbeitung im 'raw-processing' trotzdem von der Farbkorrektur und dem Grading unterscheiden sollte.

[dienstag_01]

Ja, das hätte ich genauer definieren sollen, also:

"...sondern von ISO, WB, Belichtung, Tint etc. Die sind bei raw eben nur als Metadaten gespeichert, und daher in der Post WÄHREND dem Debayering veränderbar.

Richtiger wäre: Im Rahmen des 'raw-processing', wovon das 'demosaicing' eben ein Prozess ist, der in gängigen Verfahren tatsächlich vor der Farbbearbeitung liegt. Wobei man diese Farbbearbeitung im 'raw-processing' trotzdem von der Farbkorrektur und dem Grading unterscheiden sollte.

Wie?

[nic]

Richtiger wäre: Im Rahmen des 'raw-processing', wovon das 'demosaicing' eben ein Prozess ist, der in gängigen Verfahren tatsächlich vor der Farbbearbeitung liegt. Wobei man diese Farbbearbeitung im 'raw-processing' trotzdem von der Farbkorrektur und dem Grading unterscheiden sollte.

Wie?

Weil der Hersteller der Kamera den Sensor und die Eigenheiten der Daten kennt und deshalb andere Algorithmen zur Verfügung stellt, die das NLE oder Gradingprogramm mit seinen eigenen Reglern so nicht exakt hinbekommt.

[Axel]

... und außerdem, selbst wenn die Farbeffekte des Programms im Endeffekt dasselbe erreichen könnten, wäre es wichtig, das im selben Sinne zu trennen wie primäre Farbkorrektur und Look-Grading.

[dienstag_01]

Wie?

Weil der Hersteller der Kamera den Sensor und die Eigenheiten der Daten kennt und deshalb andere Algorithmen zur Verfügung stellt, die das NLE oder Gradingprogramm mit seinen eigenen Reglern so nicht exakt hinbekommt.

Damit wäre ich sehr vorsichtig, alles was man über RAW-Bearbeitung hört und liest, läuft darauf hinaus, dass Kamerahersteller nur einen Teil ihrer internen Prozesse veröffentlichen/weitergeben. Der Rest ist reverse engineering.

[Frank Glencairn]

Wobei ich nicht sicher bin, ob das tatsächlich stimmt.
Wenn ich ein (RAW) Kamera Hersteller bin, hab ich doch ein massives Interesse daran, daß mein RAW Material, von möglichst vielen Programmen, so gut und optimal wie möglich unterstützt wird. Wenn ich jetzt meine Color-Science verheimliche, dann kann ja keiner mit dem Material aus meiner Kamera vernünftig arbeiten - das kann's doch nicht sein.

[dienstag_01]

Wobei ich nicht sicher bin, ob das tatsächlich stimmt.
Wenn ich ein (RAW) Kamera Hersteller bin, hab ich doch ein massives Interesse daran, daß mein RAW Material, von möglichst vielen Programmen, so gut und optimal wie möglich unterstützt wird. Wenn ich jetzt meine Color-Science verheimliche, dann kann ja keiner mit dem Material aus meiner Kamera vernünftig arbeiten - das kann's doch nicht sein.

Scheinbar gilt: im Zweifel tot stellen ;)
Wurde aber hier auch schon diskutiert, Sony war es, die, glaube ich, eine Meldung in Richtung der Nicht-Weitergabe von Daten rausgegeben hatten.
Im Foto-Bereich kann man schon deutliche Unterschiede im Color Processing von RAW Aufnahmen verschiedener Programme sehen.

[nic]

Genau deshalb bietet zB Red ein SDK an, das in Hostprogramme integriert werden kann. So muss nichts über das ‘decoding’ offengelegt werden und trotzdem bleibt die Qualität der Ausgabe über NLE-Grenzen hinweg konstant...

[Roland Schulz]

Ja, das hätte ich genauer definieren sollen, also:

"...sondern von ISO, WB, Belichtung, Tint etc. Die sind bei raw eben nur als Metadaten gespeichert, und daher in der Post WÄHREND dem Debayering veränderbar.

Ich hätte jetzt von nem gestandenen Mann erwartet dass man soviel Hintern in der Hose hat irgendwann auch mal die Kurve zu kriegen ;-)!

Ob Änderungen auf RAW Daten angewendet werden oder während dem Demosaicing/Debayering Adaptionen vorgenommen werden (was beides NICHT der Fall ist) spielt keine Rolle für die Diskussion. Ausgangspunkt war dass Du behauptet hast dass Änderungen im RAW Dialog notwendig sind um die volle Qualität zu erzielen und das ist für den gegenständlichen Fall in Resolve u.v.a. falsch.
Der RAW Dialog wendet Anpassungen auf das debayerte Bild an, nicht davor und auch nicht während des Debayerings. Weitere Nodes tun es genau so. Dazwischen steckt eine "verlustfreie" 32bit FP Pipeline.
Weiterhin verändern wir im Post immer noch keine Metadaten da diese die Einstellungen und Gegebenheiten der Aufnahme widerspiegeln und in aller Regel nicht geändert werden.
Was wir machen ist eine Anpassung von Parametern die u.U. Anhand von Metadaten voreingestellt werden.

Weiterhin sind ISO, WB, Belichtung, Tint usw. auch nicht in allen Fällen nur als Metadaten"information" gespeichert sondern nach Preequalizing (Wowus Aussage, vgl. Nikon D2x, EOS 1d... unterschiedliche Verstärkung der RGB Werte auf dem Sensor) ggf. ins RAW Material eingeflossen. Die Belichtung ist ebenfalls bereits im RAW enthalten, verlustfrei passen wir da nämlich keine 2 Blenden rauf oder runter an. Auch die ISO-Verstärkung/Empfindlichkeit ist durch die Analogverstärkung eingebrannt in einem ISO-varianten System.
Die Metadaten geben einfach nur die Information über den Wert bei der Aufnahme wieder, sie dienen nicht als Stellgröße für gewollte Veränderungen.

Das Du im RAW Dialog zu anderen Ergebnissen als mit dem Color Wheel kommst ist keine Kunst, glaub´ mir, das schaffe ich sogar mit verschiedenen Einstellungen im RAW Dialog selbst wenn ich welche vornehmen kann.


Zurück in der Spur braucht der FCPX RAW Decoder auch immer noch nicht zwingend Einstellmöglichkeiten um die volle Qualität weiterzugeben.
Die Anpassung kann "verlustfrei" mit anderen Werkzeugen oder nachgeschalteten LUTs im Programm erfolgen.
Die Redundanz "Einstellmöglichkeit" im RAW Dialog hat sich Apple anscheinend gespart.

Glaube wir sind jetzt "damit" endlich fertig.

[Frank Glencairn]

Es wird nicht richtiger, wenn du es öfter wiederholst.