roki100 hat geschrieben: ↑Sa 29 Mai, 2021 16:09
cantsin hat geschrieben: ↑Sa 29 Mai, 2021 15:29
Da es nur ein VLog-L-Profil gibt, gibt es eben nur die kameraspezifische Anpassung an die DVX200, und keine speziellen Profile für die GH-Serie.
Aber auch das ist nur eine Vermutung.
Nein, weil es nur eine (offizielle) VLog-LUT bzw. Transformation gibt. Bei kamera/sensormaßgeschneiderten Log-Profilen gibt es auch spezifische Hersteller-LUTs/Transformationen für jeden Sensortypen, siehe Blackmagic.
Die kameraspezifische Anpassung an die DVX200 (so aus der Doku, wo auch GH erwähnt wird) ist nur ein beleg dafür, dass VLOG-L doch für Kamera X/Y angepasst wird bzw. angepasst um die Dynamicrange des Sensor vollständig auszunutzen. Wie genau, werden wir nicht wissen, da wir in die Firmware und VLOG-L nicht hineinsehen können. Wie wissen nicht, ob es zwischen VLOG-L und Firmware eine art "Brücke" gibt, wo die Informationen ausgetauscht werden, um VLOG-L intern spezifisch anzupassen.
Wenn das so wäre, würde die VLog-LUT nicht mehr richtig funktionieren. Tut mir leid, um das so hart zu sagen, aber Du scheinst hier wirklich die Grundlagen nicht verstehen, was eine Log-Funktion und deren Transformation ist bzw. tut.
Ich hatte ja auch nicht behauptet, dass VLog-L nicht den vollen Dynamikumfang des Sensor nutzt. Das tut es. Nur es das Profil für diesen Dynamikumfang noch immer zu "weit", und werden daher die Sensorwerte suboptimal in die 10bit Bandbreite gemappt. Oder anders ausgedrückt, Du hast zwar den vollen Sensor-Dynamikumfang im Log-Material, aber eben nur mit 9bit- statt mit 10bit-Quantisierung.
Aber genau das wird nirgends von Panasonic bestätigt.
Sieh Dir doch Deine eigenen Waveform/RGB-Parade-Screenshots an, die zeigen Dir genau das an. Und wenn Du das nicht verstehst bzw. nicht interpretieren kannst und mir nicht glaubst, dann les Dir nochmal den vor mir weiter oben verlinkten Artikel zu den effektiven 9bit des VLogs der GH5 durch.
VLOG mit L bedeutet, dass es auf Dynamicrange des Sensor angepasst ist, aber nirgends wird von Panasonic bestätigt, dass der Kunde sich deswegen mit weniger Bittiefe, als das was man ihm verkauft hat, zufrieden geben sollte... Weil das eben nicht der Fall ist.
Du verstehst es einfach nicht, weil Du die Grundlagen überhaupt nicht verstanden hast, und offenbar schon seit Jahren mit Begriffen wie Raw und Log hantierst, ohne deren Konzepte begriffen zu haben.
Ich versuch's mal mit einer Erklärung. Wir haben:
1) den Dynamikunfang des Motivs - wenn es sich z.B. um einen Landschaft bei bewölktem Himmel handelt, kann der sehr gering sein, wenn es Wüstensonne mit harten Schatten ist oder auch Deine eigene Testaufnahme mit dem Spotlicht im dunklen Raum, sehr hoch;
2) die Dynamikumfang-Erfassung des Sensors - erfasst er den Dynamikumfang des Motivs (1) oder nicht? Im zweiten Fall, wie bei Deiner Testszene, clippt das Motiv in den Schatten und Spitzlichtern.
3) die Bittiefe des A/D-Wandlers des Sensors, die aus dem gemessenen einfallenden Licht digitale Werte macht. Bei einem 14bit-Wandler ist abgesoffenes Schwarz also 0 und ausgebranntes Weiss 16384.
4) die Bittiefe der Speicherung + Transformationsfunktion für die Sensorwerte.
Bei (undebayertem) RAW ist das relativ einfach: für jeden Sensorpixel gibt's einen Wert zwischen 0 und 16384. In 14Bit Raw könnte man den einfach so in die Datei wegschreiben (und am Ende vielleicht noch einen Zip-Algorithmus drüberlaufen lassen, für verlustfrei komprimiertes Raw).
Bei 12Bit Raw muss ich den Wertebereich auf 0-4096 reduzieren und dafür also ein Mapping der Werte machen. Wenn ich die Werte von 4096-16384 einfach abschneide, verliere ich die Bildinformation in den obersten beiden Blenden, clippe damit das Bild und reduziere den gespeicherten Dynamikumfang um zwei Blenden.
Um das zu verhindern, könnte ich die Werte von 0 bis 16384 stattdessen durch 4 teilen, und dann bliebe durch den Sensor erfasste Dynamikumfang erhalten. Aber dies wäre immer noch bildqualitativ ungünstig, weil die Sensorwerte das eingefangene Licht linear repräsentieren und die Werte 4096-8192 und 8192-16384 nur jeweils die obersten beiden Blenden in den Spitzlichtern repräsentieren. Durch die Teilung durch 4 verliere ich also übermäßig Wertedifferenzierung in den Mitten, in denen das menschliche Auge die meisten Details und Tonwertabstufungen unterscheiden kann, und würde wahrscheinlich Color-Banding bzw Posterisierungs-Effekte im Bild erhalten.
Stattdessen wende ich (schon bei der Raw-Aufzeichnung in 12bit) eine logarithmische bzw. Funktion auf die Werte an, die in den Spitzlichtern die Werte stärker dividiert und darunter weniger bzw gar nicht.
Dieses Spiel wiederholt sich bei der Log-Aufzeichnung in 10bit, nur dass ich da mit debayerten Werten arbeite und von debayerten 16bit linear (0-65536) zu 10bit logarithmisch (0-1024) noch viel mehr Werte wegschmeissen bzw. durch verschieden dosierte Divisionen reduzieren muss.
Wenn ich, wie im Fall von V-Log-L nur eine logarithmische Funktion habe, um 16bittig debayerte Werte in 10bit-Werte so zu übersetzen, dass Schatten und Spitzlichter nicht abgeschnitten werden, ist diese Funktion für verschiedene Sensoren mit ihrer individuell unterschiedlichen Dynamikumfang-Erfassung (siehe 2) nicht immer passgenau.
Man kann das am besten mit einem Trichter vergleichen, der dafür ausgelegt ist, die Wassermenge, die aus einem breiten Wasserrohr kommt, in ein engeres Wassergefäß zu leiten. Wenn ich diesen Trichter so konstruiere, dass er mit der Wassermenge, die innerhalb einer Sekunde aus dem breiten Rohr schießt, dieses Gefäß genau füllt, wird er an einem etwas kleineren Wasserrohr zwar ebenfalls das Gefäß füllen, ohne dass das Wasser überfließt (=das Bild clippt), aber das Gefäß wird am Ende nicht optimal, sondern z.B. nur zu 90% gefüllt sein (9bit statt 10bit).
Die tatsächliche Bittiefe Deines Signals hängt dabei nicht von der Bittiefe des Containers ab (bzw. der Kapazität des Wassergefäßes), sondern von den Zahlenwerten im Bildmaterial (bzw. dem tatsächlichen Füllstand des Wassergefäßes). - Ist ja auch klar: wenn Du die Videoaufnahme einer 8bit-Kamera in eine 10bit-ProRes-Datei schreibst, werden aus den 8bit keine 10bit. - Wenn Du unterbelichtest und in 10bit aufnimmst und in der resultierende Videodatei nie höhere Zahlenwerte als 512 findest, hast Du effektiv nur eine 9bit-Aufnahme, auch wenn Deine Kameraelektronik 10bit ermöglicht. Daher auch ETTR-Belichtung, um Farbtiefe/Signalqualität nicht wegzuschmeißen.
Wenn das Log-Profil die debayerten Sensordaten bzw. Helligkeitswerte so stark staucht, dass die Bandbreite von 1024 möglichen Werten pro Farbkanal nicht ausgenutzt werden kann, sondern nur eine Bandbreite von 640 möglichen Werten, hast Du effektiv nur eine 9,3 Bit-Aufzeichnung, und das passiert mit der GH5/G9 und V-Log.
Die Reale Bit ist von Hersteller angegeben und diese lauten 10Bit 422. Und nirgends wird bestätigt, dass der Kunde durch VLOG-L weniger Bildqualität erhält, wofür der Kunde noch extra Gled zahlen sollte. Ganz im Gegenteil, der Kunde bekommt mehr Bildqualität bzw. Dynamicrange...
Ich hoffe, dass Dir die Unterschiede von Speicher-Bandbreite und tatsächlicher Signalqualität jetzt klarer sind...