Die Tester hatten ja mangels passender Speicherkarten kein Nikon RAW verwenden können. Das schnitt beim slashCAM Dynamik-Test deutlich besser ab als das H265/H264. Auch wenn da genau genommen eher die Latitude (Über- und Unterbelichtung) gemessen wird.CineFilm hat geschrieben: ↑Fr 24 Mär, 2023 02:38 Rob & Slashcam (no hate) aber wieso steht bei der Nikon Z9
Die all diejenigen die hohe Bildqualität in Verbindung mit hohem Dynamikumfang für szenische Projekte benötigen.
Sehr hoher Dynamikumfang
Ihr habt die Kamera neulich zum Test raus gegeben. Ich fand die Projekte "naja". Jedoch haben alle Tester sich bzgl Dynamik beschwert sowie es wurde geschrieben NICHT für Szenische Aufnahmen etc...
Wie kommt jetzt sowas zustande?
Dachte ich auch erst, weil ich gerade nach ner (erschwinglichen) dritten Kamera für mein FX3/6 Lineup suche und die A7 IV im Auge hatte. Allerdings kann sie in XAVC S-I 4K bei 50/60FPS nur mit 1,5x Crop aufnehmen. Das war für mich das Ausschlusskriterium. Vielleicht hat das in der Auswahl der Kameras eine Rolle gespielt?
Das wäre mal ein interessanter Vergleichstest: welche Hersteller die besten (bzw. am besten implementierten) Logprofile haben.
Aber was sollte es denn können, was es nicht kann? Bei einem Log-Bild geht es doch in erster Linie nur um eine andere Verteilung der 'normalerweise' linearen Bildinformationen. Ich gebe Dir schon recht. Auch ich finde das N-Log Profil nicht besonders gut (ist mir meist zu bunt und zu hart) und muss da immer noch dran drehen, bzw. nutze es in RAW Formaten gar nicht mehr. Da drehe ich mir alles von Hand hin. Wenn man nicht gerade Test-Charts filmt, geht es ja nur darum, dass einem das Bild am Ende gefällt, nicht so sehr ob es der Realität nahe kommt.
- Abschneiden des Dynamikumfangs bzw. keine vollständige Abbildung der Sensordynamik (vor allem ein Problem bei Log-Profilen, die nicht sensorspezifisch sind; scheint bei der Z9 der Fall zu sein, war früher das Problem von Sony-SLog2).pillepalle hat geschrieben: ↑So 26 Mär, 2023 20:08
Die Frage ist nur, was bedeutet die Besten bzw. was wären dann die 'Probleme'?
Umgekehrt wird aber ein Schuh draus: Für adäquate Log-Aufnahmen von Sensoren mit hoher Dynamik braucht man mehr Bittiefe. Z.B. hat Arri bei LogC4 (dem neuen Log-Format für Arri LF-Kameras) die Bittiefen-Anforderung an den Aufzeichnungscodec von 10bit auf 12bit erhöht. (Quelle: https://www.arri.com/resource/blob/2787 ... n-data.pdf )Frank Glencairn hat geschrieben: ↑Mo 27 Mär, 2023 08:57 Die Bittiefe ist nur die Anzahl der möglichen Abstufungen zwischen den beiden Dynamik Brackets, hat aber nix mit der Dynamik selbst zu tun.
Ja, deshalb wird jeder Hersteller die entsprechenden Log-Kurven auch auf die Sensoren mit der größten Dynamik ausrichten, und nicht nach jenen mit der niedrigsten. Dass Log bei 8-Bit (obwohl die Profile durchaus manchmal verfügbar sind, selbst in den Kameras) nicht die beste Idee ist, sollte sich ja herumgesprochen haben.cantsin hat geschrieben: ↑Mo 27 Mär, 2023 09:26Umgekehrt wird aber ein Schuh draus: Für adäquate Log-Aufnahmen von Sensoren mit hoher Dynamik braucht man mehr Bittiefe. Z.B. hat Arri bei LogC4 (dem neuen Log-Format für Arri LF-Kameras) die Bittiefen-Anforderung an den Aufzeichnungscodec von 10bit auf 12bit erhöht. (Quelle: https://www.arri.com/resource/blob/2787 ... n-data.pdf )Frank Glencairn hat geschrieben: ↑Mo 27 Mär, 2023 08:57 Die Bittiefe ist nur die Anzahl der möglichen Abstufungen zwischen den beiden Dynamik Brackets, hat aber nix mit der Dynamik selbst zu tun.
Die klassischen Fotokamerahersteller scheinen vor allem ein Problem damit zu haben, wo genau in der internen Bildverarbeitungspipeline des Kamerachips das Log-Signal extrahiert wird. Entgegen häufiger Annahmen ist ein Log-Profil nämlich nicht einfach ein flaches bzw. kontrastreduziertes Bildprofil und lässt sich auch nicht übers Tweaken herkömmlicher Kamera-Bildprofile äquivalent herstellen. (Obwohl es ja einschlägig bekannte Blogger/Influencer gibt, die flache Bildprofile kommerziell als "Log" verkaufen... Auch für Nikon-Kameras... Will hier keine Namen nennen...)CineFilm hat geschrieben: ↑Mo 27 Mär, 2023 10:22 Kein LOG ist Perfekt und klar hat jedes Vor und Nachteile. Aber das NLOG ist unausgewogen und hat bietet nicht die Vorzüge vollwertige wie die anderen Logs.Vor allem was Clipping angeht setzt es zu früh ein. Der Dynamiksspielraum wird nicht voll ausgeschöpft.
Sony ist ja kein klassischer Fotokamerahersteller, und SLog2 lässt sich ja trotz seiner Einschränkungen gut graden und in Postproduktions-Workflows integrieren...dienstag_01 hat geschrieben: ↑Mo 27 Mär, 2023 10:57 Sind denn Sony mit Slog2 auch "gescheitert", da Slog3 nachgeschoben wurde? Oder sind sie gar mit Slog3 "gescheitert", da weniger Abstufungen im hellen Bereich als Slog2?
Ich glaube es ist eher andersherum: Nicht die Sensoren müssen für LOG designt sein, sondern das LOG-Profil muss auf den Sensor abgestimmt werden. In der Theorie bräuchte jede Kamera bze. jeder Sensor ein eigenes LOG-Profil um das Maximum herauszuholen.cantsin hat geschrieben: ↑Mo 27 Mär, 2023 10:37Die klassischen Fotokamerahersteller scheinen vor allem ein Problem damit zu haben, wo genau in der internen Bildverarbeitungspipeline des Kamerachips das Log-Signal extrahiert wird. Entgegen häufiger Annahmen ist ein Log-Profil nämlich nicht einfach ein flaches bzw. kontrastreduziertes Bildprofil und lässt sich auch nicht übers Tweaken herkömmlicher Kamera-Bildprofile äquivalent herstellen. (Obwohl es ja einschlägig bekannte Blogger/Influencer gibt, die flache Bildprofile kommerziell als "Log" verkaufen... Auch für Nikon-Kameras... Will hier keine Namen nennen...)CineFilm hat geschrieben: ↑Mo 27 Mär, 2023 10:22 Kein LOG ist Perfekt und klar hat jedes Vor und Nachteile. Aber das NLOG ist unausgewogen und hat bietet nicht die Vorzüge vollwertige wie die anderen Logs.Vor allem was Clipping angeht setzt es zu früh ein. Der Dynamiksspielraum wird nicht voll ausgeschöpft.
Meine starke Vermutung ist, dass die Signalverarbeitung von Kameras (wenn man sie sich mal als Eimerkette vom Debayering bis zur Datenkompression vorstellt) einen eigenen Weg für Log gehen muss und die Kamerachips/-ASICs daher explizit für Log-Aufzeichnung designt sein müssen - und dass die Implementierung guter Log-Profile alles andere als trivial ist, da die klassischen Fotokamerahersteller daran alle scheitern.
Ist die Sigma nicht auch diejenige Kamera, deren Raw-Auflösung sich von der Sensorauflösung unterscheidet?cantsin hat geschrieben: ↑Mo 27 Mär, 2023 11:11Sony ist ja kein klassischer Fotokamerahersteller, und SLog2 lässt sich ja trotz seiner Einschränkungen gut graden und in Postproduktions-Workflows integrieren...dienstag_01 hat geschrieben: ↑Mo 27 Mär, 2023 10:57 Sind denn Sony mit Slog2 auch "gescheitert", da Slog3 nachgeschoben wurde? Oder sind sie gar mit Slog3 "gescheitert", da weniger Abstufungen im hellen Bereich als Slog2?
Wenn Du mal z.B. Fuji F-Log unter die Finger bzw. als Material für Resolve & Co. angeliefert bekommst, weisst Du, was ich mit "gescheiterten Implementierungen von Fotokameraherstellern" meine... Sigma hat sein Scheitern übrigens sogar offiziell gemacht, das für die fp-Kameras ursprünglich angekündigte Log-Update zurückgezogen und ein Statement geschrieben, dass mit der fp-Hardware (ich nehme mal an: dem Kamerachip) entgegen der ursprünglichen Planung kein Log-Profil machbar ist.
Ja. Aber nicht die einzige. Die Nikon Z6 und Z7 haben dieselbe Einschränkung bei externer Video-Raw-Aufzeichnung, ebenso die Fuji X-H2, X-T5 und GFX-100S, die Olympus OM-D E-M1X und OM-D E-M1 Mark III. Tja, auch wieder die klassischen Fotokamera-Hersteller...dienstag_01 hat geschrieben: ↑Mo 27 Mär, 2023 11:19 Ist die Sigma nicht auch diejenige Kamera, deren Raw-Auflösung sich von der Sensorauflösung unterscheidet?
Ich hatte ja nicht von den Sensoren, sondern von den ASICs geschrieben (falls das nicht deutlich ist: den Signalverarbeitungschips der Kameras, also z.B. den DIGIC-Chips von Canon, den Expeed-Chips von Nikon, den Bionz-Chips von Sony etc.).DKPost hat geschrieben: ↑Mo 27 Mär, 2023 11:17Ich glaube es ist eher andersherum: Nicht die Sensoren müssen für LOG designt sein, sondern das LOG-Profil muss auf den Sensor abgestimmt werden. In der Theorie bräuchte jede Kamera bze. jeder Sensor ein eigenes LOG-Profil um das Maximum herauszuholen.cantsin hat geschrieben: ↑Mo 27 Mär, 2023 10:37
Die klassischen Fotokamerahersteller scheinen vor allem ein Problem damit zu haben, wo genau in der internen Bildverarbeitungspipeline des Kamerachips das Log-Signal extrahiert wird. Entgegen häufiger Annahmen ist ein Log-Profil nämlich nicht einfach ein flaches bzw. kontrastreduziertes Bildprofil und lässt sich auch nicht übers Tweaken herkömmlicher Kamera-Bildprofile äquivalent herstellen. (Obwohl es ja einschlägig bekannte Blogger/Influencer gibt, die flache Bildprofile kommerziell als "Log" verkaufen... Auch für Nikon-Kameras... Will hier keine Namen nennen...)
Meine starke Vermutung ist, dass die Signalverarbeitung von Kameras (wenn man sie sich mal als Eimerkette vom Debayering bis zur Datenkompression vorstellt) einen eigenen Weg für Log gehen muss und die Kamerachips/-ASICs daher explizit für Log-Aufzeichnung designt sein müssen - und dass die Implementierung guter Log-Profile alles andere als trivial ist, da die klassischen Fotokamerahersteller daran alle scheitern.
Kann sein, dass ich da technisch etwas übersehe, aber ich wüsste nicht inwiefern für einen LOG-Workflow bestimmte Anforderungen an die Chips benötigt werden. Es gibt natürlich den Fall, dass sich LOG-Profile nicht lohnen, weil die Dynamic Range an sich oder die Bittiefe dafür nicht ausreicht, aber das bedingt ja der Sensor.cantsin hat geschrieben: ↑Mo 27 Mär, 2023 11:40Ich hatte ja nicht von den Sensoren, sondern von den ASICs geschrieben (falls das nicht deutlich ist: den Signalverarbeitungschips der Kameras, also z.B. den DIGIC-Chips von Canon, den Expeed-Chips von Nikon, den Bionz-Chips von Sony etc.).
- Übrigens gibt es Hersteller, die für jeden Sensor ein eigenes bzw. maßgeschneidertes Log-Profil bauen, wie z.B. Blackmagic.
EDIT: Dein Posting bringt mich auf eine Idee. Könnte es sein, dass Log-Profile in Hybridkameras eine komplexe Fallstrick-Angelegenheit sind, weil sie ursprünglich nur in Cinekameras mit FPGAs (also frei programmierbaren, Minicomputer-Signalverarbeitungschips) steckten, und es schwieriger ist, sie in ASICs (=fest programmierten Massenmarkt-Kamerachips) zu implementieren? Denn ASICs können ja nicht nur für eine spezifische Kamera entwickelt und programmiert werden, sondern müssen ganze Kamerafamilien und -generationen eines Herstellers mit verschiedenen Sensoren abdecken. Und es wird ja nicht einfacher, wenn für Log im Chip eine eigene Signalverarbeitungs-Pipeline implementiert (und im Fall von ASICs: fest in die Chip-Hardware eingegossen) werden muss.
Zumindest dürften Blackmagics sensormaßgeschneiderten Log-Profile nur dank der FPGA-Architektur seiner Kameras möglich sein.
Da wären mindestens:
Was soll denn in der "alten" Formel drin stehen? Ich denke, man rechnet mit den Werten, die aus dem A/D-Wandler kommen, das sind halt bei 12bit 4096. Und diese 4096 Werte geben auch den Dynamikumfang des Sensors wieder, es sei denn, man entscheidet sich als Hersteller bewusst dagegen.cantsin hat geschrieben: ↑Mo 27 Mär, 2023 12:33Da wären mindestens:
- Debayering in einen erweiterten Farbraum. [Alle Log-Profile haben erweiterte Farbräume, entweder eigene wie Panasonic V-Gamut und Sony S-Gamut, oder offen standardisierte wie Rec2100.]
- Umrechnung der Sensorwerte von linear zu logarithmisch, mit einer passenden Formel, die sowohl an die Dynamik, als auch das Rauschverhalten des Sensors angepasst ist. [Wird schon zum Problem bei ASICs, wenn hier eine Umrechnungsformel für zig verschiedene Sensoren funktionieren muss.]
- Beschränkung des Gains (bzw. der ISO) auf die sensornativen Gains/ISOs, die für das Log-Gamma umgerechnet werden müssen.
- Entrauschung bei komplett anderen/anders verteilten Chroma- und Luma-Daten, mit einem für Log maßgeschneiderten Denoising-Profil.
- Keine Nachschärfung.
- Anpassung der kamerainternen Belichtungsmessung und Belichtungs-Hilfen (Histogramm, Zebras etc.), um das Gamma richtig zu belichten.
Schon für Schritt 1, 2 und 4 müsste das Videosignal Chip- bzw. Pipeline-intern einen anderen Weg gehen. Das kann man sich genauso vorstellen wie einen alternativen Node-Tree in Resolve. Nur dass dieser dann fest in die Signalverarbeitungs-ASICs eingegossen werden muss. Und wenn man dann im Design spart oder schlampt und z.B. in Schritt 2 eine alte Formel verwendet, die die höhere Dynamik eines neueren Sensors nicht mehr adäquat bedient, gibt's abgeschnittenen DR (wie wohl bei der Nikon Z9), und wenn man nur eine pauschale Entrauschungs-Node in die Pipeline setzt, die sowohl sRGB/Rec709- als auch Log-Videosignale entrauscht und dann (wie bei Fuji) in Log den Chroma-Kanal killt, hat man eben ein suboptimales Log-Profil.
So einfach ist das ja nicht. Wenn Du - um nur einmal ein Beispiel zu nehmen - eine Kleinsensorkamera hast, deren erstes Bit in den Schatten nur aus Rauschen besteht, berechnest Du die logarithmische Verteilung der Sensorwerte so, dass dieses erste Bit ignoriert bzw. abgeschnitten wird, oder - falls da doch ein bisschen Signal drin steckt - mit dem zweiten Bit zusammengefasst wird, um für die Blendenstufen mit mehr Bildinformation mehr Bandbreite übrigzulassen. (So haben das ja z.B. auch SLog2 und die erste Version von CLog gemacht.)dienstag_01 hat geschrieben: ↑Mo 27 Mär, 2023 12:56 Was soll denn in der "alten" Formel drin stehen? Ich denke, man rechnet mit den Werten, die aus dem A/D-Wandler kommen, das sind halt bei 12bit 4096. Und diese 4096 Werte geben auch den Dynamikumfang des Sensors wieder, es sei denn, man entscheidet sich als Hersteller bewusst dagegen.
Die Dynamik steckt in den 4096 Werten. Wenn das nicht so wäre, würde man das auch bei Composite oder RAW-Video sehen.cantsin hat geschrieben: ↑Mo 27 Mär, 2023 13:19So einfach ist das ja nicht. Wenn Du - um nur einmal ein Beispiel zu nehmen - eine Kleinsensorkamera hast, deren erstes Bit in den Schatten nur aus Rauschen besteht, berechnest Du die logarithmische Verteilung der Sensorwerte so, dass dieses erste Bit ignoriert bzw. abgeschnitten wird, oder - falls da doch ein bisschen Signal drin steckt - mit dem zweiten Bit zusammengefasst wird, um für die Blendenstufen mit mehr Bildinformation mehr Bandbreite übrigzulassen. (So haben das ja z.B. auch SLog2 und die erste Version von CLog gemacht.)dienstag_01 hat geschrieben: ↑Mo 27 Mär, 2023 12:56 Was soll denn in der "alten" Formel drin stehen? Ich denke, man rechnet mit den Werten, die aus dem A/D-Wandler kommen, das sind halt bei 12bit 4096. Und diese 4096 Werte geben auch den Dynamikumfang des Sensors wieder, es sei denn, man entscheidet sich als Hersteller bewusst dagegen.
Und wenn's doch so einfach wäre, bräuchte man nur noch ein einziges Log-Gamma (bzw. könnte gleich bei Cineon bleiben...)