Vegas und 32bit floating point

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Vegas und 32bit floating point

      Ich will hier mal Links sammeln, wo zu Sony Vegas über die dortige 10bit Verarbeitung Information verfügbar ist.

      Wer das nicht braucht bitte ignorieren!

      Zumindest für mich besteht hier Lernbedarf. Einfach weil ich wissen will, wie ich mein 10bit 422 Material vom Shogun optimal verabeiten kann.

      Folgende Links die ich mal auf die Schnelle gefunden habe:

      glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

      eoshd.com/comments/topic/5234-…o-levels-full-range-mean/

      forums.creativecow.net/thread/24/959821



      personal-view.com/talks/discus…39/8bit-color-nonsense/p2

      designstudioschool.com/bit-flo…-pixel-format-t54119.html

      forums.creativecow.net/thread/24/982291
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Wenn es nur um die 10-Bit-Bearbeitung geht, gibt es nicht viel zu beachten. Die Projekteinstellung sollten »32-Bit Gleitkomma (Videolevel)« sein und fertig. Man sollte nur noch wissen, welche Exportformate (Bild und Video) mindestens 10 Bit unterstützen. Da stehen in Vegas Pro zum Glück ja einige zur Verfügung (bis hin zur Floatpoint-Ausgabe).

      Die Glennchan-Infos sind meiner Erfahrung nach mit Vorsicht zu genießen, da dort mehr falsch interpretiertes Halbwissen drin steckt als dem Autor lieb ist.

      Der eigentliche Vorteil der Floatpoint-Bearbeitung liegt allerdings an anderer Stelle, nämlich an der praktisch verlustlos reversiblen ausschöpfbaren Über- und Unterbelichtungsmöglichkeit.
    • Ja dass die Glenchan-Info mit Vorsicht zu genießen ist, das ist mir bekannt - hatten wir schon früher, der Link ist ja uralt.

      ABER es ist einer der wenigen Links zu dem Thema.

      Die Diskussionen auf Creativecow, wo sich Johnny als guter Vegas kennter immer wieder einbringt, finde ich auch nicht schlecht.

      Marco schrieb:

      Der eigentliche Vorteil der Floatpoint-Bearbeitung liegt allerdings an anderer Stelle, nämlich an der praktisch verlustlos reversiblen ausschöpfbaren Über- und Unterbelichtungsmöglichkeit.


      Und das finde ich mal keine schlechte Aussage. Allerdings - gilt die auch für 8bit Material, oder erst für 10bit Material. So wich ich das verstehe ist es ja nur eine Berechnungsmethode, sollte damit für beide gelten?
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Das meinte ich mit »an anderer Stelle«, denn dieser Vorteil ist in gewisser Weise erstmal mit keinem Video mit fixem Bitwert nutzbar. Also du kannst damit keine Über- oder Unterbelichtung, die schon bei der Aufnahme passiert ist und den gegebenen fixen Werteumfang gesprengt hat, wieder korrigieren.
      Kameras, die eine Aufzeichnung mit mehr als 10 Bit erlauben, legen aber tatsächlich mehr Aussteuerungsreserven an, die dann erst in einem Floatpoint-Projekt wieder zum Leben erweckt werden können.

      Gedacht ist das aber derzeit mehr fürs Compositing und für Farbkorrekturen, die sich in einem 8-Bit-Projekt (oder bei anderen NLEs auch in einem 10-Bit-Projekt) schnell zu nicht wiederherstellbaren Über- oder Unterbelichtungen addieren können. Und hier spielt es umgekehrt weniger eine Rolle, ob ich im Projekt ein 8-Bit-Video oder ein Video mit höhere Bitrate nutze, denn der Vorteil innerhalb der internen Bearbeitung bleibt immer erhalten.

      Beim Compositing geht es noch einen Schritt weiter, denn dort werden oft erstmal Lichtsituationen hergestellt, die sich rein an Physik und nicht an Wahrnehmung und Displaydistribution orientieren. Es wäre also möglich, dass dir eine Datei angeliefert wird, die einen Kontrastumfang von 100 000:1 und mehr aufweist. Das ist auch in einer 16-Bit-Datei nicht speicherbar. Mit Floatpoint dagegen kein Problem.
      Wenn du solch eine Datei in einem 8- oder 10-Bit-Projekt öffnest, siehst du womöglich erstmal pures Schwarz. Aber nach Farbkorrektur ist alles, was vom Compositer angelegt wurde, wiederherstellbar.

      Ich schicke nachher mal eine kleine Beispieldatei.
    • Marco schrieb:

      Also du kannst damit keine Über- oder Unterbelichtung, die schon bei der Aufnahme passiert ist und den gegebenen fixen Werteumfang gesprengt hat, wieder korrigieren.


      Klar, alles hat seine Grenzen. Aber wie du schreibst:

      Marco schrieb:

      Kameras, die eine Aufzeichnung mit mehr als 10 Bit erlauben, legen aber tatsächlich mehr Aussteuerungsreserven an, die dann erst in einem Floatpoint-Projekt wieder zum Leben erweckt werden können.


      es geht sicherlich einerseits um mehr Reserven - und die habe ich an dem Material der GH4 bisher schon sehen können.

      Marco schrieb:

      Gedacht ist das aber derzeit mehr fürs Compositing und für Farbkorrekturen, die sich in einem 8-Bit-Projekt (oder bei anderen NLEs auch in einem 10-Bit-Projekt) schnell zu nicht wiederherstellbaren Über- oder Unterbelichtungen addieren können.


      Bei unserem 8bit Material steht man halt relativ schnell am Rauschen an, welches man bei dieser Art von Korrekturen bekommt. Die ganzen Ansätze zum "flach Filmen" haben doch nur den Hintergrund, einerseits eine große Reserve zu haben (solange es nicht zu flach ist), aber andererseits die Sache in der PostPro eben noch hochqualitativ entwicklen zu können. Und hier hat ja offenbar ProRes und DNxHD so den Status von gehobenen professionellen Codecs die das können, und neuerdings kommt ja auch XAVC dazu.

      Also wenn es darum geht, bei Helligkeits- und Farbkorrekturen das Rauschen zu minimieren, dann wäre genau das der gewünschte Vorteil dieses 10bit 422 Materials - und ein 10bit workflow in Edius oder der 32bit floating point workflow in Vegas die gewünschte Berechnungsart.

      Und das möchte ich für mich genauer erforschen.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Im Anhang ist ein Projekt zum Experimentieren.

      Wenn du das Vegas-Projekt öffnest, solltest du eine Schrift sehen. Die siehst du aber nur, weil der Weißwert etwa hunderfach durch ein Farbkorrekturfilter angehoben wurde und weil das Video und das Projekt auf Floatpoint basiert.

      Schalte den FX (ist als Spur-FX angelegt) auf Bypass und du siehst nur Schwarz. Schalte den FX wieder an und schalte das Projekt um auf 8 Bit und du siehst nur Weiß. Im 8-Bit-Projekt ist die Schrift auch niemals wiederherstellbar (das wäre sie auch in Edius in einem 10-Bit-Projekt nicht).

      Tatsächlich wurde die Bildinformation der Schrift nicht nur auf Schwarz geglättet, sondern sie liegt sogar weit unterhalb von Schwarz. Wenn du einen Bildbetrachter hast (z. B. IrfanView), der EXR-Dateien öffnen kann: Versuch es. Das Bild bleibt immer Schwarz. Die Bildinformation ist ausschließlich durch Floatpoint-Prozessing abrufbar.
      Dateien
      • float.zip

        (37,01 kB, 74 mal heruntergeladen, zuletzt: )
    • Da das erste Beispielprojekt eher eine typische Compositing-Eigenschaft von Floatpoint-Prozessing zeigt, die zwar zu den besonderen Stärken zählt, aber für jemanden, der mit normalen Videoaufnahmen arbeitet, weniger von Bedeutung ist, hier mal ein Beispiel, das selbst mit gewöhnlichem 8-Bit-Video nutzbar ist. Und zwar immer dann, wenn sich zwei hintereinander geschaltete Farbkorrekturen in einem Integer-Projekt negativ beeinflussen würden. Wenn ein oder mehrere Effekte zu einem Clipping führen, ist dieses Clipping dort nicht mehr durch einen weiteren Effekt zu reparieren (auch nicht in einem 10- oder 12-Bit-Projekt). In einem Floatpoint-Projekt ist das hingegen kein Problem.

      Im konkreten Fall (siehe Anhang) wurde durch ein Brightness-Filter eine starke Überbelichtung erzeugt, die zum Clipping führte und dieses Clipping wurde durch einen Levels-Filter wieder korrigiert. Im Floatpoint-Projekt längst noch im grünen Bereich. Wenn du aber das Projekt umschaltest auf 8 Bit: Ein absoluter No-Go.
      Die Folge der hier angewendeten Farbkorrektur ist zwar prinzipiell unsinnig, zeigt aber sehr gut, wie bzw. ab wann das Floatpoinit-Prozessing auch für 8-Bit-Material nutzbar ist.
      Dateien
      • globe.zip

        (181,8 kB, 72 mal heruntergeladen, zuletzt: )
    • Marco schrieb:

      Tatsächlich wurde die Bildinformation der Schrift nicht nur auf Schwarz geglättet, sondern sie liegt sogar weit unterhalb von Schwarz. Wenn du einen Bildbetrachter hast (z. B. IrfanView), der EXR-Dateien öffnen kann: Versuch es. Das Bild bleibt immer Schwarz. Die Bildinformation ist ausschließlich durch Floatpoint-Prozessing abrufbar.


      Verblüffend dieses erste Beispiel - die Information ist ja anders tatsächlich nicht abrufbar. Wie ist den diese Datei erzeugt, und wo befindet sich diese Information dann eigentlich?

      Marco schrieb:

      hier mal ein Beispiel, das selbst mit gewöhnlichem 8-Bit-Video nutzbar ist. Und zwar immer dann, wenn sich zwei hintereinander geschaltete Farbkorrekturen in einem Integer-Projekt negativ beeinflussen würden.


      Also ist das erste Projekt überraschend, so ist das zweite doch interessanter. Ich verstehe das so: der erste Filter ist ja nur dazu da, um eine Überbelichtung zu simulieren. Will man das korrigieren, dann hat man daher nur einen zweiten Filter in der Hand um da was zu retten.

      Ok, ich habe das daher mal auf 8bit umgestellt und dort versucht mit Levels zu retten was zu retten ist. Geht tatsächlich ausgesprochen schlecht, man kann zwar den Wald und das Dort halbwegs in den sichtbaren Bereich ziehen - aber die Überstrahlung des HImmels ist hoffnungslos. Aber was dazu im Vergleich zum 8bit Projekt noch an Bildinformation rauskitzelbar ist, das ist wirklich gewaltig. Man beachte den blauen Himmel den man sonst einfach nicht aus der Überstrahlung raus bekommt - unglaublich dass dieses Himmelblau noch vorhanden ist Damit kann man die Überstrahlung reduzieren, was man so bei einem Sonnenauf- oder Untergang beobachten würde. DAS finde ich beeindruckend, nur mit der 8-bit Einstellung in Vegas wäre bei sowas man verloren.

      Damit das auch die Anderen leichter sehen lade ich mal snapshoots sowie die Projektdatei vom 8bit Rettungsversuch hoch.
      Dateien
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Was in beiden Projekten zu erfahren ist, erklärt sich aus der grundlegenden Eigenschaft des Floatpoint-Prozessing, das auch den grundsätzlichen Unterschied zu jedem integren Signalprozessing ausmacht, gleich ob 8-, 10-, 12-Bit oder mehr.

      Nehmen wir als Beispiel mal ein 8-Bit-Projekt. Du hast ein Signal, dessen Lumaspektrum zwischen 0 und 255 abgebildet wird. Wenn ich jetzt durch eine Farbkorrektur einen vorher differenziert dargestellten Bildbereich auf den Wert 0 oder 255 ziehe und damit die gesamte Differenzierung auf diesen einen Wert glätte (da ja unter 0 und über 255 nichts mehr ist – das berüchtigte »Clipping«), dann war’s das. Die vorherige Differenzierung ist jetzt aus einer Fläche, die nur noch aus dem Luma-Wert 0 oder 255 besteht, nicht wiederherstellbar. Du kannst nur den gesamt geglätteten Bereich als eine Pampe in irgendeinem Grauton darstellen oder Schwarz oder Weiß lassen.

      Was bei 8 Bit 0 und 255 ist, ist bei Floatpoint 0 und 1. Was bedeutet, dass auch dort Schwarz und Weiß fest definiert ist, nämlich eben auf 0 und 1. Und je nach Art des Floatpoint-Projekts liegen auf der 0 und auf der 1 entweder die Referenzpegel oder die Spitzenpegel des verwendeten Farbraumes.
      Das Besondere: Das Floatpoint-Prozessing kennt, solange eine Zahl mit der gegebenen Arithmethik darstellbar ist, keine Grenzen. Ein Wert kann 0 oder 0,783273 sein oder 1 oder 348234 oder minus 5798 oder sonstwas.
      Sehen kannst du das, was mit Werten unter 0 oder über 1 definiert wird, nicht mehr, da nach hinten raus die Displays nichts damit anfangen können und wieder in integrem Bitprozessing feststecken. Aber rechnen und arbeiten kann man mit den Werten unter 0 und über 1 durchaus.

      Projekt 1 war ein Beispiel für das Arbeiten mit einem Wert unter 0.
      Dafür hatte ich einfach in einem Floatpoint-Projekt das Text-Event mit mehreren hintereinander gelegten Farbkorrektur-Plug-ins in der Helligkeit weit unter den Wert 0 geschoben. Ich kann keine genauen Werte nennen, doch vom Grundsatz her könnte beispielsweise der schwarze Hintergrund danach einen Wert von minus 1000 und die weiße Schrift einen Wert von minus 100 gehabt haben. Bei 8 Bit wären beide Werte längst im Clipping zerstört. Bei Floatpoint bleiben die Werte immer erhalten und so kann ich danach wieder mit Plug-ins die Werte minus 1000 und minus 100 solange Richtung Weiß verschieben, dass sie auch in einem 8-Bit-System (und damit beispielsweise auf einem Display) wieder verwertbar werden.
      Nachdem ich die Schrift in einen Wertebereich weit unter 0 verschoben hatte, habe ich das Projekt als EXR-Bilddatei exportiert. Dabei bleibt die Floatpoint-Eigenschaft erhalten. Importiere ich also die EXR-Datei in einem anderen Floatpoint-fähigen System, stehen wieder alle Möglichkeiten offen. Daher ist EXR ein beliebtes Austauschformat im Bereich des Compositings, aber auch immer mehr Kameras bieten für die Weiterverarbeitung von Raw-Video einen EXR-Export mit Floatpoint-Eigenschaften.

      Projekt 2 war ein Beispiel für das Arbeiten mit Werten über 1. Prinzipiell aber gleich dem ersten Projekt.
    • Marco schrieb:

      Was bei 8 Bit 0 und 255 ist, ist bei Floatpoint 0 und 1. Was bedeutet, dass auch dort Schwarz und Weiß fest definiert ist, nämlich eben auf 0 und 1. Und je nach Art des Floatpoint-Projekts liegen auf der 0 und auf der 1 entweder die Referenzpegel oder die Spitzenpegel des verwendeten Farbraumes.


      Ja man sieht hier eindrucksvoll was die Sache bringen kann.

      Was war eigentlich das Format des verwendeten Bildes vom Sonnenaufgang? Ein "normales" 8bit Material wie wir es auch mit herkömmlichen Kameras erzeugen können? Weil um das gehts ja - aus dem vorhandenen Material das Maximum rauskitzeln zu können.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Ja, das ist ein gewöhnliches JPEG-Foto mit 8 Bit (aufgenommen gestern Nachmittag beim Spaziergang). Wobei man da natürlich berücksichtigen muss, dass die Überbelichtung nicht in der Aufnahme war, sondern innerhalb von Vegas durch eine Korrekturmaßnahme entstanden ist. Aber das war ja auch genau das, was damit demonstriert werden sollte.

      Ich war mir bewusst, dass all diese Infos ja erstmal gar nichts mit deinem Anliegen zu tun haben. Aber ich denke, sie sind dennoch interessant (und helfen etwas, dieses Floatpoint-Prozessing im ganzen Umfang zu verstehen), durchaus nutzbar und vor allem zeigen sie die Vorteile, die wir in Vegas Pro gegenüber Systemen wie Edius haben, wo es zwar alternativ zu einem 8-Bit-Projekt noch ein 10-Bit-Projekt gibt. Doch auch in einem 10-Bit-Projekt kannst du die oben gezeigten Eigenschaften nicht nutzen. Das geht nur mit Floatpoint-Prozessing.

      Ein weiterer Vorteil, der immer mehr in Richtung deines Anliegens geht: Es kann uns in Vegas Pro egal sein, ob eine importierte Datei 10 Bit, 16 Bit, 24 Bit oder mehr hat. Wir können im Floatpoint-Projekt jede dieser Dynamiken nutzen und im Zeifelsfall als EXR-Sequenz unter Erhalt der Dynamik auch exportieren.
      Der Nachteil ist, dass wir in einem Floatpoint-Projekt mehr Leistung opfern müssen, wenn wir "nur" ein 10-Bit-Video bearbeiten wollen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()

    • Jetzt langsam Richtung Ziel: Oben die Infos, wie gut Floatpoint-Prozessing geeignet ist, um völlig unabhängig vom sichtbaren Spektrum Unter- und Überbelichtungen (im weitesten mathematischen Sinne) aufzufangen. Bleibt da vielleicht noch zu erwähnen, dass der Bereich von der verarbeitbaren extremsten Unterbelichtung bis zur extremsten Überbelichtung vereinfacht und Pi mal Daumen 10^−38 (10 hoch minus 38) bis 10^38 (10 hoch 38) beträgt. Diese Grenzen wird man vermutlich selbst in der Postproduktion nie ausschöpfen, es sei denn, man agiert mit völig dämlich programmierten Filtern.

      Aber erstmal sollte es dir um den sichtbaren Bereich gehen, der bei Floatpoint zwischen den Werten 0 und 1 dargestellt wird. Die erste Frage ist also, ob per Floatpoint zwischen 0 und 1 genügend Werte darstellbar sind, um die 1024 Stufen eines 10-Bit-Signals damit abzubilden. Ich kann zwar nicht genau sagen, wieviel Werte in diesem Bereich absolut berechenbar sind, aber es reicht sicher locker für ein 24-Bit-Signal mit integren Werten.

      Die zweite Frage, die mindestens ebenso wichtig ist, ist, ob die Werte zwischen 0 und 1, die den 1024 Werten eines 10-Bit-Signals entsprechen, auch mit genügend hoher Genauigkeit berechnet werden können. Das trifft erstmal einen wunden Punkt des Floatpoint-Prozessings, denn tatsächlich tauchen da immer wieder Dezimalwerte auf, die per Floatpoint berechnet Rundungsfehler mit sich bringen. Die sind aber wiederum selten und so gering, dass sie für Berechnungen von Videosignalen und Berechnungen von Effekten für Videosignale vernachlässigbar sind.
      Wenn ich die 1024 Werte eines 10-Bit-Signals dem Floatpoint-Prozessing zuführe und anschließend wieder zum Export eines 10-Bit-Signals zurückrechne auf die 1024 integren Werte, bleiben auch bei eventuellen Rückrundungen die 1024 Werte unverfälscht erhalten.
      Also auch die Genauigkeit reicht aus, um sämtliche derzeit in der Praxis verfügbaren Farbtiefen eines Videosignals korrekt umzurechnen.

      Dann bleibt nur noch die Frage, welche Art von Gleitkomma-Projekt in Vegas Pro gewählt werden sollte, um Signale mit 10 Bit (oder höher) zu bearbeiten.

      Ich rate dazu, für jedes "normale" Videosgnal, das schon per Kamera einer Gammakorrektur unterzogen wurde und im Farbraum Rec. 709 aufgezeichnet wurde, den Modus »Videolevel« zu benutzen, weil nur dort Schwarz- und Weißwerte in gewohnter Art behandelt werden und nur damit alle Filter und Funktionen, die das Videosignal beeinflussen, auch in letzter Konsequenz wie gewohnt funktionieren. Außerdem besteht hier keine Gefahr, versehentlich im falschen Farbraum zu arbeiten.

      Mit dem Modus »Vollbereich 2,222 (Video)« verlässt du den Bereich, in dem Schwarz und Weiß nach üblichen Konventionen behandelt wird, mit »Vollbereich 1,000 (Linear)« würdest du zusätzlich voraussetzen, dass das Video ohne Gammakorrektur vorliegt. Und wenn unter Vollbereich für die Anzeigetransformation irgendwas anderes als »Aus« gewählt ist, würdest du außerdem noch den Farbraum Rec. 709 verlassen und für ein normales Videosignal wäre bezüglich der Farbverarbeitung nichts mehr so wie es sein sollte.
    • Warte mal bitte, bevor wir weiter gehen. Ich bin noch bei der Frage der Korrektur von Überbelichtungen. Das Beispiel mit dem Sonnenuntergang/aufgang hat mich insofern interessiert, als ich nachvollziehen wollte wie das bei anderen Beispielen ausschaut. Habe sowas in einer Küchenaufnahme getestet - snapshoots stelle ich noch zusammen. Und dort habe ich nicht diese enormen Korrekturreseven gesehen wie bei der Aufnahme von dir. Sprich - das läßt sich nicht entsprechend korrigieren, die Überbelichtung ist und bleibt da - und die Aufnahme ist offenbar zerstört.

      Ok, jedes System hat Grenzen. Aber könnte es sein, dass die Korrektur beim Sonnenuntergang/aufgang-Bild deshalb so gut geht, weil die Farbinformation zum Blau des Himmels in der Nähe bei der Sonne halt im Bild sehr wohl vorhanden ist? Und nur durch den ersten Filter entfernt worden ist? Es scheint mir fast so zu sein - denn bei meinem Beispiel sind die Korrekturmöglchkeiten eben eingeschränkter.

      Ich poste später mal snapshoots davon - und ein kleines Beispielprojekt.


      Marco schrieb:

      Die erste Frage ist also, ob per Floatpoint zwischen 0 und 1 genügend Werte darstellbar sind, um die 1024 Stufen eines 10-Bit-Signals damit abzubilden. Ich kann zwar nicht genau sagen, wieviel Werte in diesem Bereich absolut berechenbar sind, aber es reicht sicher locker für ein 24-Bit-Signal mit integren Werten.


      Also das sollte kein Thema sein, oder?

      Marco schrieb:

      ob die Werte zwischen 0 und 1, die den 1024 Werten eines 10-Bit-Signals entsprechen, auch mit genügend hoher Genauigkeit berechnet werden können. Das trifft erstmal einen wunden Punkt des Floatpoint-Prozessings, denn tatsächlich tauchen da immer wieder Dezimalwerte auf, die per Floatpoint berechnet Rundungsfehler mit sich bringen. D


      Gerade Rundungen müßten bessre als bei dem 10bit Integer Modus von Edius mit geringeren Abweichungen rüber kommen. Aber das hat auch den hohen Preise der viel mäßigeren Performance - Edius ist da im 10bit Modus dramatsich schneller als Vegas im 32bit floating modus.

      Marco schrieb:

      Also auch die Genauigkeit reicht aus, um sämtliche derzeit in der Praxis verfügbaren Farbtiefen eines Videosignals korrekt umzurechnen.


      Glaube ich auch, ohne es belegen zu können.

      Marco schrieb:

      Ich rate dazu, für jedes "normale" Videosgnal, das schon per Kamera einer Gammakorrektur unterzogen wurde und im Farbraum Rec. 709 aufgezeichnet wurde, den Modus »Videolevel« zu benutzen, weil nur dort Schwarz- und Weißwerte in gewohnter Art behandelt werden


      Das Shogun Material wird einer Gammakorrektur unterzogen, ist ja kein raw. Somit ist das wohl der bessere Modus. Zumindest, bis wir v-log haben (falls das kommt).

      Marco schrieb:

      it »Vollbereich 1,000 (Linear)« würdest du zusätzlich voraussetzen, dass das Video ohne Gammakorrektur vorliegt.


      Und genau das ist nicht der Fall, bei dem Shogun Material.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • »Also das sollte kein Thema sein, oder?«

      Definitiv nicht. Werte zwischen 0 und 1 sind bei Floatpoint genügend berechenbar. Darunter, dazwischen, darüber: Mehr als wir bräuchten.

      Noch kurz zum Gamma: Wir können erstmal davon ausgehen, dass jedes Videomaterial schon per Kameraaufzeichnung einer Gammakorrektur unterzogen wurde. Die Ausnahmen sind die wenigen Kameras, die eine lineare Raw-Aufzeichnung bieten (lineare Aufzeichnung ist allerdings erst ab etwa 14 Bit effektiv).

      Dann nochmal zum 8-Bit-JPEG. Ich glaube, du liegst da einem Missverständnis auf. Das Bild, so wie es ist, bietet keinerlei Reserven für Unter- oder Überbelichtungen (also in Bereichen von Clipping). Im Floatpoint-Projekt ebenso wenig wie im 8-Bit-Projekt. Die Überbelichtung (das Clipping) steckt ja gar nicht im Original, sondern die Überbelichtung ist (zur Demonstration, wie Floatpoint-Prozessing arbeitet) nur im Vegas-Projekt enthalten, nachdem in Vegas Pro ein Filter draufgelegt wurde.
      Das Beispiel zeigt nicht die Aussteuerungsreserven in Bereichen des Clippings für 8-Bit-Signale, sondern es zeigt erstmal nur die erweiterten Grenzen innerhalb eines solchen Vegas-Projektes. Man hätte anhand eines 2-Bit-Signals prinzipiell die gleiche Wirkung demonstrieren können.

      Wenn es darum geht, auch für die Korrektur von geclippten Bereichen noch Reserven zu entlocken, nützt selbst 10 Bit oder 12 Bit nichts, weil bei all diesen integren Formaten vor und hinter (Super-)Schwarz und (Super-)Weiß nichts mehr an Informationen verfügbar ist.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Marco ()

    • Marco schrieb:

      Das Bild, so wie es ist, bietet keinerlei Reserven für Unter- oder Überbelichtungen (also in Bereichen von Clipping). Im Floatpoint-Projekt ebenso wenig wie im 8-Bit-Projekt. Die Überbelichtung (das Clipping) steckt ja gar nicht im Original, sondern die Überbelichtung ist ... nur im Vegas-Projekt enthalten.


      Eben. Aber auf das wollte ich ja hinweisen, dass das aus dieser Sicht doch eine spezielle Situation ist. Denn genau das hier:

      Marco schrieb:

      Wenn es darum geht, auch für die Korrektur von geclippten Bereichen noch Reserven zu entlocken, nützt selbst 10 Bit oder 12 Bit nichts, weil bei all diesen integren Formaten vor und hinter (Super-)Schwarz und (Super-)Weiß nichts mehr an Informationen verfügbar ist.


      ist ja mein Punkt - die Info ist eigentlich gar nicht mehr vorhanden, udn auch der exakter rechnende Gleitkommazahl-Ansatz kann nichts rekonstruieren was nicht mehr da ist.

      Aber damit kommen wir zum nächsten - in der Praxis wichtigen - Punkt: wie soll man eigentlich filmen um ein Maximum an Nachbearbeitungsfähigkeit zu erhalten? Und hier werden ja durchaus verschiedene Antworten gegeben. Bei 8bit gibt es die langläufige Meinung, dass man - aufgrund der geringen Nachbearbeitungsfähigkeit - man das Material idealerweise so hinbekommen sollte, dass es gar keiner massiven Nachbearbeitung mehr bedarf. Einfach, weil man sonst zuviel Rauschen bei Helligkeits- und Farbkorrekturen in das Material bekommt.

      Anders der Ansatz, der über flache Kurven oder die diversen log-Files geht - hier wird - oder soll ja - durch das Filmen mit flachen Gammakurven eine entsprechende Reserve erhalten bleiben. Was zwingend bedeutet dass man das Material entsprechend Helligkeits- und eventuell auch Farbkorrigieren MUSS.

      Und ich vermute, hier hilft halt die präzissere Gleitkommaberechnung auch nochmals deutlich, die höheren Reserven des 10bit 422 Materials besser zu entwickeln?
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Jetzt kann man die Sache von zwei Standpunkten aus betrachten:

      1. Gegenüber dem 8-Bit-Signal bietet 10 Bit insofern Reserven, als dass bezüglich einer Farbkorrektur die Werte in gewissen Grenzen hin und hergeschoben werden können, ohne dass letztlich, wenn das Endprodukt doch wieder 8 Bit sein darf und soll, gegenüber einem vergleichbaren 8-Bit-Original sichtbar etwas an Qualität verloren wäre.

      2. Von der eher wissenschaftlichen Seite und absolut gesehen bringt dagegen 10 Bit kelne Reserve mit sich. Denn 10 Bit ist das Minimum an einem Wertebereich, der notwendig ist, um in ein gammakorrigiertes Signal soviel Dynamik reinzubringen, wie sie halbwegs die natürliche Wahrnehmung repräsentieren kann. Und das gilt natürlich nur dann, wenn nichts weiter (z. B. durch Farbkorrekturen) während der Bearbeitung verloren geht und wenn die gesamte Kette bis inklusive des Displays bei 10 Bit bleibt.

      Also streng genommen und vom zweiten Standpunkt aus betrachtet ändert sich an der Handhabung beim Dreh mit 10 Bit nichts. Auch hier sollte bezüglich Belichtung, Kontrast, Farbe so exakt wie irgend möglich gedreht werden, weil 10 Bit per se noch keine Reserven mit sich bringt.
      Nur im Vergleich zu einem 8-Bit-Dreh stehst du damit etwas besser da, aber auch hier kannst du nur dann die Vorteile gegenüber 8 Bit richtig ausnutzen, wenn so präzise wie möglich gedreht wurde und die Nachbearbeitung nicht überstrapaziert wird.

      Ein Dreh mit flachem Profil oder gar mit linearem Gamma sollte, wenn qualitätsbewusst produziert wird, nicht unter 12 Bit Aufzeichnung angegangen werden. Professionelle Kameras wie die Sony F35 bieten für lineare Aufzeichnung daher tatsächlich sogar 14 Bit.

      10 Bit ist also normalerweise noch keine Basis für Drehs mit flachem oder gar linearem Gamma. Aber vom gleichem Standpunkt aus ist 8 Bit schon im optimalen Zustand noch zu minderwertig, um solch einem Qualitätsanspruch nur ansatzweise zu bestehen. Und doch nehmen wir 8-Bit-Video, farbkorrigieren, was das Zeug hält, und finden es subjektiv gut.
      Was heißen soll: Das oben war quasi der akademische Beitrag dazu, aber letztlich zeigt dann die Praxis, wieviel mehr Spielraum uns 10-Bit gibt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()

    • Puhh, einige sehr theoretische Aspekte!

      Frage: wie erprobt ist den der 32bit floating mode? Ich wollte ein Beispielprojekt machen, um das Grading zwischen 8bit und 10bit vergleichen zu können. Geht auch soweit. Aber wenn ich das rausrendere, dann habe ich immer wieder schwarze Bildaussetzer dazwischen. Scheint bei mir nicht sonderlich gut zu funktionieren - warum auch immer. Weder mit den ProRes Files noch mit Canopus HQX Files -aber auch vielleicht weil ich Fenster gestaucht habe um zwei Spuren gleichzeitig gestaucht darstellen zu können.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Ich nutze das schon hin und wieder. Für Compositing und für Experimente rund ums Thema Licht. Quellmaterial – sofern nicht ausschließlich intern generierte Medien – war dabei alles Mögliche: EXR-Sequenzen, DNG-Sequenzen, HDCAM SR, XAVC, DNxHD, unkomprimiertes YUV, etc. (aber abgesehen von DNxHD keine Quicktime-Dateien), Der Export erfolgt für mehr als 8 Bit meist als HDCAM SR, DNxHD oder EXR und für 8 Bit meist als XDCAM HD oder AVC. Bildfehler hatte ich noch nicht.

      Hattest unter Optionen/Präferenzen/Video die GPU-Unterstützung deaktiviert? Ich habe da irgendwie in grauer Erinnerung, dass GPU-Boost und Floatpoint sich in Vegas Pro besonders schlecht vertragen. Aber ich bin mir nicht sicher und finde momentan auch keine Quelle dazu. Ich kann das bei mir eh gar nicht erst aktivieren.
    • Nein, das war nicht deaktiviert. Ich hatte bisher bei mir kaum Themen mit der CUDA-Beschleunigung - war bei mir bisher noch nie möglich. Aber ich probieres mal schnell aus. Das scheint es tatsächlich gewesen zu sein, sehe ich zumindest beim Rendern schon an der Vorschau während des Renderns dass hier jetzt diese Sprünge nicht auftauchen.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Ja das wars definitiv. Jetzt ist die Ausgabedatei ok.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung