Jott hat geschrieben: ↑Sa 14 Apr, 2018 16:08
Wozu, wenn es das Atomos/Apple-Angebot gibt?
...um nicht überall mit so nem blöden und unhandlichen Kamera/Recorder Gerigge rumhampeln zu müssen! Integrierte Lösungen würde ich ebenfalls vorziehen, aber bisher hat Canon außer der C200 doch gar nix mit integriertem RAW, oder übersehe ich was?!
7nic hat geschrieben: ↑Sa 14 Apr, 2018 14:11
Und wenn die CS des Herstellers dem NLE vertraut ist, benötigt es außer den Meta- und Bilddaten ja nicht einmal eine eingebettete lut.
Das scheint aber das Problem zu sein, das Petty hat - dass zumindest FCPX nicht mehr kann, als die LUT anwenden. Das würde, wie gesagt, auch die gute Performance erklären.
Wenn ich seine Interview-Aussagen richtig verstehe, fehlen bei PRR auch die Metadaten, um die 'color science' im NLE vernünftig hinzukriegen. (Daher auch seine Aussage, "It's a look-up table and a Bayer package. [...] It's just a container with a LUT.") Und deshalb auch seine Ansage, dass eine PRR-Implementation in Blackmagics Produkten (also Kameras und Resolve) noch viel Arbeit und Lösungen von Problemen erfordert.
Tja, wäre der Interviewer nicht zu inkompetent gewesen und hätte nachgefragt (statt die ganze Zeit blöd zu unterbrechen), wüssten wir mehr. Die Aussagen von Petty sind sehr komprimiert. Offensichtlich ist der Mann Techniker und weiss wovon er spricht, erklärt es aber nicht ausführlich.
Kann nicht sein - ich kann ich FCP X doch auch ne weitere/andere LUT zuweisen und mit der Performance hat das nix zu tun. Genau so wenig hat es mit der Abhängigkeit zu tun ob die Kamera ISO in- oder variant ist. Es geht u.A. auch um LUTs die für verschiedene Lichtqualitäten-/Temperaturen erstellt wurden, ggf. auch für verschiedene Looks.
Eine LUT brauchen wir bei RAW eigentlich immer, ob im Container mitgebracht oder später verlinkt und deshalb sehe ich hier keinen Grund für Performanceunterschiede.
Ich kann mir das nur so erklären dass wir hier ggf. nur eine Art "Vorschauqualität" erhalten die ggf. voll mit Artefakten (Zipper...) etc. ist. Hier werden ggf. noch keine "Linien" nachgezogen und somit werden vielleicht Äste dabei wieder im Nichts enden und etwas versetzt dazu weiterwachsen. Ggf. werden auch Farben wieder "falsch" geschätzt/interpoliert - nur eine Idee, kann sein dass man auch bei der IQ volle Qualität liefert.
Roland Schulz hat geschrieben: ↑Sa 14 Apr, 2018 16:41
Kann nicht sein - ich kann ich FCP X doch auch ne weitere/andere LUT zuweisen und mit der Performance hat das nix zu tun. Genau so wenig hat es mit der Abhängigkeit zu tun ob die Kamera ISO in- oder variant ist. Es geht u.A. auch um LUTs die für verschiedene Lichtqualitäten-/Temperaturen erstellt wurden, ggf. auch für verschiedene Looks.
Eine LUT brauchen wir bei RAW eigentlich immer, ob im Container mitgebracht oder später verlinkt und deshalb sehe ich hier keinen Grund für Performanceunterschiede.
Es geht darum, dass Software wie Resolve (oder auch ACR) auf Grund der Meta-/Herstellerdaten wesentlich komplexere Farbkorrekturen an Raw-Material vornimmt, als da einfach nur eine LUT draufzuklatschen, die in der Raw-Datei mitgeliefert wird. Und diese Daten scheint ProRes Raw nicht zu enthalten, wenn es stimmt, was Petty sagt.
Und offenbar scheint die jetzige Kombi ProRes Raw+FCPX solche komplexen Farbkorrekturen nicht vorzunehmen, was den Performance-Unterschied erklären könnte.
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Jeremy Young hat geschrieben:And one of the most important things is the metadata from the camera. We record all of the metadata. We know what the white balance was, we know what the ISO setting was, we know what the shutter speed was. And it means we can do all this realtime decoding and re-encoding to make everything work in the timeline.
Aha. Wie es scheint weiß Atomos diese Dinge, aber FCP nicht.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Alles höchst seltsam. Als ob sich die Geschichte von CinemaDNG wiederholt. Damals implementierte Adobe sein eigenes Format nur halbherzig bzw. unvollständig in Premiere, jetzt implementiert Apple sein eigenes Format nur halbherzig bzw. unvollständig in FCPX.
Bis jetzt sieht es so aus, als ob Atomos die treibende Kraft ist und der Rest der Industrie noch nicht wirklich mitzieht.
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Jott hat geschrieben: ↑Sa 14 Apr, 2018 16:08
Wozu, wenn es das Atomos/Apple-Angebot gibt?
...um nicht überall mit so nem blöden und unhandlichen Kamera/Recorder Gerigge rumhampeln zu müssen! Integrierte Lösungen würde ich ebenfalls vorziehen, aber bisher hat Canon außer der C200 doch gar nix mit integriertem RAW, oder übersehe ich was?!
Nö, nichts übersehen. Am internen RAW der C200 wird aber auch rumgemault (einer tut sogar immer so, als gäbe es das gar nicht). An internen ProRes-Lösungen anderer Hersteller wird ebenfalls rumgemault. An sonstigen Codecs sowieso. Jedem alles recht machen geht halt nicht. Zumal manche aus Prinzip grundsätzlich an allem etwas auszusetzen haben.
Der mündige Käufer/User/Producer wird seinen Weg schon finden! :-)
...der mündige Käufer/User/Producer wird seinen Weg irgendwie machen, klar.
Wir wissen aber alle dass es meist doch irgendwie besser ginge wenn es die Hersteller nur wollten.
Es ist und bleibt wie immer wirtschaftlich, um morgen noch was verkaufen zu können.
Wir können uns aber noch 500 Posts über die mögliche Performance von Prores Raw unterhalten ohne wirklich was festzustellen.
Denke wir müssen einfach noch ein wenig warten bis wir mal richtiges Material vor die Flinte kriegen. Ggf. zieht 7nic oder Wolfgang ja demnächst mal ein belastbares Resümee - in Bezug auf IQ und Speed.
@Axel, nein bist du nicht gemeint.... die die gemeint sind wissen es eh genau da sich die Inszenierungen über die letzten Jahre immer gleich präsentieren.. liegt in der Natur des Menschen...
Übrigens, das mit den Metadaten wie ISO ist implementiert nur sollte es auch von CAMs eingebrannt werden.. wird dieser Flag ungenutzt übergeben kann er nicht verändert werden, ja wie den auch auf Basis von Haselnüssen oder was?
Das Format steht am Anfang wie es bei Prores Anfangs auch war.. wer sich die Timeline von Prores ansieht wie so oder wann in ungefähr die einzelnen Hersteller auf den Zug aufgesprungen sind.. heute kräht kein Hahn mehr danach und es wird einfach verwendet... Ab und an poltert der Merowinger( nein nicht der Axel) das es überholtes Dreckszeuch ist und das ist auch auch gut so.... Man muss schon auch mal aus der Lethargie des einfachen Workflows herausgerissen werden um über solche Aussagen zu schmunzeln zu dürfen..
Also Leute, wo sind die angekündigten Testfiles und Ergebnisse ... ich kann damit nicht dienen aus Mangels einer passenden Cam..
motiongroup hat geschrieben: ↑So 15 Apr, 2018 08:58... interessiert eher nicht ;)
Höchstens insofern, dass man darauf schließen kann, indirekt, dass die Metadaten zu Kameraeinstellungen wie Belichtung und Weißabgleich in diesem mov enthalten sind. Denselben Serviervorschlag sähen wir in ACR und Resolve, dort allerdings wären die Werte auch angezeigt. Spricht also zunächst mal nicht gegen PRR sondern gegen FCP.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Wieso? Wie sollte fcp denn die Darstellung sonst treffen? Tut es ja. Welchen praktischen Wert hätte es denn, ISO etc. anzuzeigen? What you see is what you get.
Woran es effektiv liegt, weiß ich auch nicht. Ich vermute und hoffe eigene Doofheit. Aber es gelang mir in FCP noch nie, kameraspezifische EXIF-Daten auszulesen, wie sie mir Catalyst Browse für Sony in Hülle und Fülle anzeigt (interessante Sachen wie Objektiv, Brennweite, Entfernung, Blende, Verschlusszeit, ISO und WB). Noch ärger, ich versuchte, die Metadaten-Ansicht zu editieren und als Axels EXIF zu speichern (was scheinbar zunächst gelang), aber in dieser Ansicht tauchten dann völlig exotische Parameter wie Ausrichtung oder 360° Projektionsmodus auf, die ich nie sehen wollte und eigenhändig durch Entfernen des Kreuzchens in der Checkbox abgewählt hatte. Auch diese Testclips zeigen nur seeehr allgemeine Informationen. Schade. Bin wohl zu dumm.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
warum das nicht veränderbar ist kann noch keiner erklären.. lasst noch einige Zeit ins Land ziehen und nicht schon wieder Schuldzuweisungen in den Äther plärren..
Jott hat geschrieben: ↑So 15 Apr, 2018 09:26
Welchen praktischen Wert hätte es denn, ISO etc. anzuzeigen? What you see is what you get.
Es geht nicht um die Anzeige der Metadaten, sondern darum sie verändern zu können - das ist ja der ganze Witz an RAW (außer dem geringen Speicherplatz Bedarf), die Metadaten vor dem Debayering zu ändern.
warum das nicht veränderbar ist kann noch keiner erklären.. lasst noch einige Zeit ins Land ziehen und nicht schon wieder Schuldzuweisungen in den Äther plärren..
Womit ausgelesen?
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Frank Glencairn hat geschrieben: ↑So 15 Apr, 2018 10:36
Es geht nicht um die Anzeige der Metadaten, sondern darum sie verändern zu können - das ist ja der ganze Witz an RAW (außer dem geringen Speicherplatz Bedarf), die Metadaten vor dem Debayering zu ändern.
...welchen Sinn sollte das haben?!
Metadaten werden von der Kamera/Recorder als Istzustand der Aufnahme abgeleitet - die sind nicht als „Stellglieder“ für irgendwelche Maßnahmen im Post vorgesehen.
Zuletzt geändert von Roland Schulz am So 15 Apr, 2018 11:48, insgesamt 1-mal geändert.
Jetzt darfst du zweimal lachen. Einmal über mich, denn Mediainfo hatte ich schon auf dem Rechner. Und einmal über folgenden Vorschlag: Apple sollte Mediainfo kaufen. Das wäre doch ein Knaller für 10.5 im Oktober!
Kein Trost ist, dass ich es auch in Resolve nicht schaffe, die Catalyst Browse - Metadaten meiner Sony-Clips auszulesen. Codec, Länge, Größe, dann ist Ende im Gelände ....
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Edius 9.20 kann den PRR Clip einladen, zeigt aber nur ein graues Bild an. An Metadaten steht nur der Codec Typ und der Container. Normalerweise zeigt Edius mehr an (Beispiel ist von einer X70):
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Jott hat geschrieben: ↑So 15 Apr, 2018 09:26
Welchen praktischen Wert hätte es denn, ISO etc. anzuzeigen? What you see is what you get.
Es geht nicht um die Anzeige der Metadaten, sondern darum sie verändern zu können - das ist ja der ganze Witz an RAW (außer dem geringen Speicherplatz Bedarf), die Metadaten vor dem Debayering zu ändern.
Das sind doch nur Metaphern. Weder du noch ich wissen, wo das Einstellen zum Beispiel der „Belichtung“ (fcp-Regler) bei ProRes Raw greift. Wieso nicht vor dem De-Bayering? fcp weiß ja, es sind raw-Daten und geht damit vielleicht schlauer um, als man meinen könnte. Anzuzeigen, dass ein ISO-Wert konkret von 800 zu 1600 oder sonst was verschoben wird - wozu? Der „ganze Witz“ an raw wäre trotzdem da. Und so wird‘s wohl auch sein.
Frank Glencairn hat geschrieben: ↑So 15 Apr, 2018 10:36
Es geht nicht um die Anzeige der Metadaten, sondern darum sie verändern zu können - das ist ja der ganze Witz an RAW (außer dem geringen Speicherplatz Bedarf), die Metadaten vor dem Debayering zu ändern.
...welchen Sinn sollte das haben?!
Metadaten werden von der Kamera/Recorder als Istzustand der Aufnahme abgeleitet - die sind nicht als „Stellglieder“ für irgendwelche Maßnahmen im Post vorgesehen.
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. Was meinst du warum Resolve zu den üblichen Kurven und Colorwheels noch einen zusätzlichen eigenen Raw Tab hat, wo man das alles ändern kann?
Ob eine Anpassung der (RAW-)Daten vor dem Debayering oder als RGB danach passiert spielt keine Rolle, solange die (interne) RGB Quantisierung mindestens so groß ist wie die RAW Quantisierung.
Roland Schulz hat geschrieben: ↑So 15 Apr, 2018 11:38
...welchen Sinn sollte das haben?!
Metadaten werden von der Kamera/Recorder als Istzustand der Aufnahme abgeleitet - die sind nicht als „Stellglieder“ für irgendwelche Maßnahmen im Post vorgesehen.
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. Was meinst du warum Resolve zu den üblichen Kurven und Colorwheels noch einen zusätzlichen eigenen Raw Tab hat, wo man das alles ändern kann?
Die Anpassung findet trotzdem nicht vor dem Debayering statt.
Also ich bin da bei Frank. Es geht darum die Metadaten verändern zu können, anstatt sofort Korrekturfilter des jeweiligen Tools drauf zu legen.
In Resolve wird das klar getrennt angezeigt und das hat schon einen Sinn, denn das Zweitere über Filter sind bereits Intensivere Umrechnungen nach dem Debayering (der Metadateneingriff wohl noch vorher, sonst macht’s ja keinen Sinn).
Für das CDNG Material aus Shogun und EVA1 wird da aber zumindest für die Farbtemperatur ein Unsinn angezeigt.
wolfgang hat geschrieben: ↑So 15 Apr, 2018 12:21Für das CDNG Material aus Shogun und EVA1 wird da aber zumindest für die Farbtemperatur ein Unsinn angezeigt.
Echt? Was motiongroup über Mediainfo ausgelesen hat, wäre exakt das gewesen, was ich anhand des Youtube-Posterframes oben geraten hätte. Offensichtlich bei Tungsten aufgenommen, für 3200 aber noch zu warm/orange und für 5600 noch zu neutral.
org.smpte.rdd18.camera.whitebalance : 4300K
Erläutere mal, was du meinst.
Was nun die Manipulation des WB (als Beispiel) betrifft, so finde ich schon, dass im Schieberegler "Farbtemperatur" von FCP dann "4300" stehen sollte als korrekter Ausgangspunkt. Dort steht aber immer "5000". Tut mir leid, Genossen, das ist schwach.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Roland Schulz hat geschrieben: ↑So 15 Apr, 2018 12:15
Ob eine Anpassung der (RAW-)Daten vor dem Debayering oder als RGB danach passiert spielt keine Rolle, solange die (interne) RGB Quantisierung mindestens so groß ist wie die RAW Quantisierung.
Die Anpassung findet trotzdem nicht vor dem Debayering statt.
Du sagst also, daß die Entwickler eines der weltweit führenden Grading Programme, einen extra RAW Tab - und dazu noch für jede Kamera einen eigenen RAW Tab mit kamaraspezifischen Einstellungen - einfach so, aus reinem Blödsinn programmieren, weil sie überhaupt nicht schnallen, daß es in Wirklichkeit gar keinen Unterschied zu den RGB Kontrollen gibt?
Roland Schulz hat geschrieben: ↑So 15 Apr, 2018 12:15
Ob eine Anpassung der (RAW-)Daten vor dem Debayering oder als RGB danach passiert spielt keine Rolle, solange die (interne) RGB Quantisierung mindestens so groß ist wie die RAW Quantisierung.
Die Anpassung findet trotzdem nicht vor dem Debayering statt.
Du sagst also, daß die Entwickler eines der weltweit führenden Grading Programme, einen extra RAW Tab - und dazu noch für jede Kamera einen eigenen RAW Tab mit kamaraspezifischen Einstellungen - einfach so, aus reinem Blödsinn programmieren, weil sie überhaupt nicht schnallen, daß es in Wirklichkeit gar keinen Unterschied zu den RGB Kontrollen gibt?
Es macht schon allein Sinn, weil die Raw-Einstellungen über das Hersteller-SDK abgewickelt werdeb... Die RGB-Bearbeitung dann über BMD-Algorithmen.
ISO variant: Die Analogwerte der Sensel auf dem Sensor werden variabel (ISO/Gain) verstärkt und dann digitalisiert und gespeichert (alternativ vorher komprimiert).
Ggf. werden noch Gammakurven analog angewendet.
Ggf. wird eine (RGB-Sensel) ungleichmäßige Verstärkung angewendet, die vom Weißabgleich abhängt (z.B. Nikon D2x). Meist erkennbar durch Zusatzsensor an der Kamera, denke heute nicht mehr üblich.
ISO invariant: Die Analogwerte der Sensel auf dem Sensor werden unvariabel/konstant fest verstärkt und dann digitalisiert und gespeichert (alternativ vorher komprimiert).
Metadaten der Kameraparameter wie gemessener/voreingestellter Weißabgleich, Verstärkung/ISO, Belichtungs- und Objektivdaten, Framegröße, Bittiefe und Framerate werden gespeichert.
Der RAW Converter debayert die eingehenden RAW Daten meist in ein RGB (alternativ YUV-) Bild mit hoher Quantisierung (>= RAW File), wendet auf das RGB Bild dann Parameter aus den Metadaten der Datei an, die ggf. durch einen Einstelldialog adaptiert wurden. Es findet keine Veränderung der RAW Daten statt.
Im umgekehrten Fall müsste jede intern verwendete YUV- oder RGB Farbmetrik "umgekehrt debayert" nochmals entwickelt/programmiert und auf die RAW Daten angewendet werden. Der Debayeringprozess ist zudem anhand der meisten bekannten Algorithmen als deutlich aufwändiger anzusehen als eine einfach RGB Transformation. Die Anpassung der Parameter auf RGB Daten kann demnach schneller erfolgen.
Die hier entstandenen Daten mit hoher Quantisierung werden genau so im weiteren Prozess an das Programm/folgende Nodes weitergegeben.
(Alternativ können sie jetzt in der Quantisierung begrenzt werden, um Performance zu sparen. Dann sind weitere Schritte aber verlustbehaftet.)
Findet keine Reduktion der Quantisierung statt können die Daten "verlustfrei" innerhalb des Programms weiterverarbeitet werden. Somit können auch Daten in späteren Schritten bzgl. WB etc. adaptiert werden. Es macht keinen Unterschied!
Der RAW Dialog bietet nur andere Stellschrauben wie Farbtemperatur in K an, die später so nicht mehr zur Anwendung kommen, da Daten aus vorherigen Notes/Filtern/Routinen keinen "kalibrierten" Bezug (K) haben muss.
Ein Programm kann aber genau so gut ohne eine Anpassung der Aufnahmedaten/Metadaten funktionieren, wenn die interne Quantisierung hoch genug ist (vgl. z.B. Resolve).
Du sagst also, daß die Entwickler eines der weltweit führenden Grading Programme, einen extra RAW Tab - und dazu noch für jede Kamera einen eigenen RAW Tab mit kamaraspezifischen Einstellungen - einfach so, aus reinem Blödsinn programmieren, weil sie überhaupt nicht schnallen, daß es in Wirklichkeit gar keinen Unterschied zu den RGB Kontrollen gibt?
Es macht schon allein Sinn, weil die Raw-Einstellungen über das Hersteller-SDK abgewickelt werdeb... Die RGB-Bearbeitung dann über BMD-Algorithmen.
Spielt auch keine Rolle, auch das Hersteller SDK macht zuerst ein Debayering und passt dann Parameter auf RGB Daten an die anschließend übergeben werden.
Niemand verändert RAW Daten vor oder beim Debayering. Jede Änderung am Parameter würde selbst am Standbild ein neues, zeitaufwändiges Debayering erfordern.
Die ganze Farbmetrik/Routinen müssten "rückwärts debayered" nochmal entwickelt werden und würden nur Nachteile mit sich bringen.
Es hat keinen Nachteil die Informationen nach dem Debayering anzupassen, nur Vorteile! Somit kann das auch in FCP X passieren ohne einen RAW Dialog haben zu müssen.
Zuletzt geändert von Roland Schulz am So 15 Apr, 2018 13:29, insgesamt 1-mal geändert.
wolfgang hat geschrieben: ↑So 15 Apr, 2018 12:21Für das CDNG Material aus Shogun und EVA1 wird da aber zumindest für die Farbtemperatur ein Unsinn angezeigt.
Echt? Was motiongroup über Mediainfo ausgelesen hat, wäre exakt das gewesen, was ich anhand des Youtube-Posterframes oben geraten hätte. Offensichtlich bei Tungsten aufgenommen, für 3200 aber noch zu warm/orange und für 5600 noch zu neutral.
Bitte vollständig lesen - ich sprach von RESOLVE und nicht von Mediainfo. Und ich sprach von CDNG udn nicht von ProRes RAW.
Aber eigentlich keine schlechte Frage. Ist es wichtig, ob der original in der Kamera gewählte WB-Wert als Metadaten vorliegt? Wenn ja, warum? Wenn nein, was kann es dann schon ausmachen, den ohnehin falschen Ausgangswert herzunehmen und mit dem Farbtemperatur-Regler der Software anzupassen?
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
