Bei der A7III ist der Codec zu beschränkt und dürfte nicht den Mindestanforderungen der AG Dok genügen (schreibe ich als A7iii-Besitzer).
Bei der A7iii sind nicht mal die 8bit das Problem, und auch nicht 4:2:0, sondern Abstriche bei Codec- und Signalqualität, die auch bei 8bit nicht sein müssten. Wie gesagt, bei diesem speziellen Einsatzzweck (Dokumentarfilm mit Kino/Festival- und TV-Auswertung).klusterdegenerierung hat geschrieben: ↑Mi 10 Jun, 2020 13:44 Denke auch, sind wohl eingefleischte 10Bitler!
Ohne Rec709-Konvertierung? Ne, lass mal.klusterdegenerierung hat geschrieben: ↑Mi 10 Jun, 2020 20:53 Kann man solche Tests denn nicht mal endlich ohne Hersteller Luts machen?
Hm, aber wäre es dann nicht besser, gleich in 709 zu drehen?DeeZiD hat geschrieben: ↑Mi 10 Jun, 2020 22:44Ohne Rec709-Konvertierung? Ne, lass mal.klusterdegenerierung hat geschrieben: ↑Mi 10 Jun, 2020 20:53 Kann man solche Tests denn nicht mal endlich ohne Hersteller Luts machen?
Wäre allerdings dafür zusätzlich Downloads des Originalmaterials anzubieten.
Wenn ich mit einer ARRI in Log C drehe, habe ich nach der offiziellen Konvertierung trotzdem volle 14 stops.dienstag_01 hat geschrieben: ↑Mi 10 Jun, 2020 22:53 Hm, aber wäre es dann nicht besser, gleich in 709 zu drehen?
Denn man gewinnt doch auf diesem Weg gar nichts durch das LOG Profil?
LOG-Material hat in der Regel einen erweiterten Farbraum mit Bt.2100 Primärfarben und Weißpunkt. Dein Vorschlag würde zu völlig falschen Farben bei RED WideGamutRGB, Canon C-Log2, Panasonic V-Log, F-Log, S-Log2 und 3 sowie weiteren führen.klusterdegenerierung hat geschrieben: ↑Mi 10 Jun, 2020 23:47 Aber Rec Konvertierung muß ja nicht zwangsläufig heißen das man eine Lut über Material knallt, welches danach nicht mehr das ist, welches es eigentlich sein sollte und mal unter uns, bei perfektem WB ist es doch nicht mehr als Sättigung, Gamma & Kontrast, dafür braucht man doch keine Lut die zu 70% passt.
Da kann man sich doch eben ein Still einer gut gemachten Korrektor Node pro Cam anlegen und gut ist, so hat man dann zumindest einen Einduck des Materials und nicht der jeweiligen Lut.
Was heißt genau *offizielle Konvertierung*? Ist das die Konvertierung nach 709?DeeZiD hat geschrieben: ↑Mi 10 Jun, 2020 23:52Wenn ich mit einer ARRI in Log C drehe, habe ich nach der offiziellen Konvertierung trotzdem volle 14 stops.dienstag_01 hat geschrieben: ↑Mi 10 Jun, 2020 22:53 Hm, aber wäre es dann nicht besser, gleich in 709 zu drehen?
Denn man gewinnt doch auf diesem Weg gar nichts durch das LOG Profil?
Genauso wenn ich mit meiner S1H V-Log drehe, habe ich nach der offiziellen Konvertierung volle 12.5 stops (ca.)
Wenn ich allerdings mit meiner S1H im Standard oder gar Rec709-Profil drehe, habe ich deutlich unter 10 stops DR.
Bei Rec2100 (HLG oder PQ) sähe die Situation anders aus, hier ist eine Konvertierung gar notwendig, da ansonsten nur ca. 6 stops auf Rec709- oder sRGB-Bildschirmen dargestellt werden koennen. Kompression ist das Stichwort.
Nicht beschnitten, in den Schatten und Lichtern komprimiert.dienstag_01 hat geschrieben: ↑Mi 10 Jun, 2020 23:59Was heißt genau *offizielle Konvertierung*? Ist das die Konvertierung nach 709?DeeZiD hat geschrieben: ↑Mi 10 Jun, 2020 23:52
Wenn ich mit einer ARRI in Log C drehe, habe ich nach der offiziellen Konvertierung trotzdem volle 14 stops.
Genauso wenn ich mit meiner S1H V-Log drehe, habe ich nach der offiziellen Konvertierung volle 12.5 stops (ca.)
Wenn ich allerdings mit meiner S1H im Standard oder gar Rec709-Profil drehe, habe ich deutlich unter 10 stops DR.
Bei Rec2100 (HLG oder PQ) sähe die Situation anders aus, hier ist eine Konvertierung gar notwendig, da ansonsten nur ca. 6 stops auf Rec709- oder sRGB-Bildschirmen dargestellt werden koennen. Kompression ist das Stichwort.
So wie ich das verstehe, wird bei der Konvertierung in 709 beschnitten (Resolve: man kann nach Konvertierung Werte nicht zurückholen), ist das falsch?
Gut, komprimiert. Damit aber weg. Das ist doch für den Dreh mit LOG Profile sinnentstellend. Du beschreibst ja selbst eine von dir bevorzugte Reihenfolge, weil die Werte sonst weg sind.DeeZiD hat geschrieben: ↑Do 11 Jun, 2020 00:08Nicht beschnitten, in den Schatten und Lichtern komprimiert.dienstag_01 hat geschrieben: ↑Mi 10 Jun, 2020 23:59
Was heißt genau *offizielle Konvertierung*? Ist das die Konvertierung nach 709?
So wie ich das verstehe, wird bei der Konvertierung in 709 beschnitten (Resolve: man kann nach Konvertierung Werte nicht zurückholen), ist das falsch?
Wenn du wenig DR input hast wirken Spitzlichter trotzdem hart sowie Schatten rauschig, farblos etc.
Außerdem ist der Spielraum in der post dann ebenfalls gering.
I.d.R. geht man so vor.
Material -> WB/Tint -> Gain/Offset -> Rec709 Konvertierung via CST/Lut -> Secondary CC
oder falls man auf Luts verzichten möchte
Material -> ACES IDT/RCM Input -> ACES AP1/RCM Working color space -> WB/Tint -> Log controls -> Secondary CC -> ODT /RCM Output color space
Habe ich ehrlich gesagt noch nie gesehen, das Log Material nach einem korrektem WB plötzlich anders aussehen als vergleichbares Rec Material. Wenn dem so wäre würde es doch völlig ausreichen einen Colorchart mit zu filmen und in Resolve ein zu pflegen, danach bleibt dann aber trotzdem nur noch die üblichen Verdächtigen an denen man dreht.DeeZiD hat geschrieben: ↑Mi 10 Jun, 2020 23:58 LOG-Material hat in der Regel einen erweiterten Farbraum mit Bt.2100 Primärfarben und Weißpunkt. Dein Vorschlag würde zu völlig falschen Farben bei RED WideGamutRGB, Canon C-Log2, Panasonic V-Log, F-Log, S-Log2 und 3 sowie weiteren führen.
Der Hersteller der jeweiligen Kameras liegt in der Verantwortung korrekte Konvertierungen zu Rec709 zu liefern.
Diese sind leider in der Regel - wie bereits von AG DOK beschrieben - nicht immer optimal auf das jeweilige Modell zugeschnitten, liefern aber grundsätzlich bereits deutlich bessere Ergebnisse als mit einer manuellen Korrektur möglich sind.
Wie willst du dann das Material zufriedenstellend auf einem Rec709/sRGB-Ausgabegerät darstellen?dienstag_01 hat geschrieben: ↑Do 11 Jun, 2020 00:17Gut, komprimiert. Damit aber weg. Das ist doch für den Dreh mit LOG Profile sinnentstellend. Du beschreibst ja selbst eine von dir bevorzugte Reihenfolge, weil die Werte sonst weg sind.DeeZiD hat geschrieben: ↑Do 11 Jun, 2020 00:08
Nicht beschnitten, in den Schatten und Lichtern komprimiert.
Wenn du wenig DR input hast wirken Spitzlichter trotzdem hart sowie Schatten rauschig, farblos etc.
Außerdem ist der Spielraum in der post dann ebenfalls gering.
I.d.R. geht man so vor.
Material -> WB/Tint -> Gain/Offset -> Rec709 Konvertierung via CST/Lut -> Secondary CC
oder falls man auf Luts verzichten möchte
Material -> ACES IDT/RCM Input -> ACES AP1/RCM Working color space -> WB/Tint -> Log controls -> Secondary CC -> ODT /RCM Output color space
Zusammengefasst ist das kein Testszenario für den Dynamikumfang einer Kamera.
Bei den oben erwähnten Log-Gammas wäre eben dies nicht der Fall, was auch der Grund ist, warum viele Einsteiger in die Materie über die Falschfarben ihrer Kameras entsetzt sind, nachdem sie vergessen haben das Manual zu lesen, welches eben genau obiges Phänomen beschreiben würde.klusterdegenerierung hat geschrieben: ↑Do 11 Jun, 2020 00:21Habe ich ehrlich gesagt noch nie gesehen, das Log Material nach einem korrektem WB plötzlich anders aussehen als vergleichbares Rec Material. Wenn dem so wäre würde es doch völlig ausreichen einen Colorchart mit zu filmen und in Resolve ein zu pflegen, danach bleibt dann aber trotzdem nur noch die üblichen Verdächtigen an denen man dreht.DeeZiD hat geschrieben: ↑Mi 10 Jun, 2020 23:58 LOG-Material hat in der Regel einen erweiterten Farbraum mit Bt.2100 Primärfarben und Weißpunkt. Dein Vorschlag würde zu völlig falschen Farben bei RED WideGamutRGB, Canon C-Log2, Panasonic V-Log, F-Log, S-Log2 und 3 sowie weiteren führen.
Der Hersteller der jeweiligen Kameras liegt in der Verantwortung korrekte Konvertierungen zu Rec709 zu liefern.
Diese sind leider in der Regel - wie bereits von AG DOK beschrieben - nicht immer optimal auf das jeweilige Modell zugeschnitten, liefern aber grundsätzlich bereits deutlich bessere Ergebnisse als mit einer manuellen Korrektur möglich sind.
Bei Log geht es doch wohl eher um Dynamikgewinn durch Lumakompression und Verschiebung.
Wenn ich mein Slog oder Raw aus der FS700 mit Kontrast, Sättigung und Gamma richtig rückführe, sind die Farben identisch zur Rec Version.
Da das Quellgamma (Log) und das Zielgamma (i.d.R. Rec709 oder neuerdings Rec2020PQ) ist, verstehe ich die Frage nicht.klusterdegenerierung hat geschrieben: ↑Do 11 Jun, 2020 00:36 Ok, wenn ich aber nun das Quellgamma ins Zielgamma konvertiere, bin ich doch wieder safe oder nicht, dann hätte ich ein neutrales Log für die händische Rückführung ins Rec, oder nicht?
Korrekt belichtet ist ja nun bei einem Dynamiktest eher nichts.DeeZiD hat geschrieben: ↑Do 11 Jun, 2020 00:23Wie willst du dann das Material zufriedenstellend auf einem Rec709/sRGB-Ausgabegerät darstellen?dienstag_01 hat geschrieben: ↑Do 11 Jun, 2020 00:17
Gut, komprimiert. Damit aber weg. Das ist doch für den Dreh mit LOG Profile sinnentstellend. Du beschreibst ja selbst eine von dir bevorzugte Reihenfolge, weil die Werte sonst weg sind.
Zusammengefasst ist das kein Testszenario für den Dynamikumfang einer Kamera.
Wie gesagt, wichtig ist nur, dass das Material korrekt belichtet in die Rec709-Konvertierung geht und nicht - wie viele andere glauben - nachträglich angepasst werden sollte.
So wird der komplette Dynamikumfang ausgenutzt und wenn eine Kamera (wie z. B. die GH5) weniger Input liefert, wirkt sich das auch im Endergebnis negativ aus.
AG Dok macht das schon richtig.
Schöner wäre es in Zukunft stattdessen ACES einzusetzen, da so die Ergebnisse deutlich einheitlicher werden.
Das würde in Richtung ACES gehen, weshalb ACES auch die bessere Alternative wäre, da so alle Kameras die gleiche Grundlage hätten. ;)klusterdegenerierung hat geschrieben: ↑Do 11 Jun, 2020 01:10 Sorry, missverständlich ausgedrückt, mit Zielgamma meinte ich nicht Rec709, sondern eines welches das gleiche Potenzial/Raum inne hat, wie das Quellgamma, dann korrigiert man einfach Kurve & Sättigung.
Wenn ich das so mache wie Du verstanden hast, wäre es ja im Grunde eine klassische Konvertierung wie mit Lut, das wollte ich ja vermeiden.
Schon richtig. Roll-off in den Schatten und Highlights, einfach ausgedrückt S-Kurve. Mit einer exakten negativen S-Kurve lassen sich diese wieder zurück nach Log 'biegen'.dienstag_01 hat geschrieben: ↑Do 11 Jun, 2020 01:13 Wie schaffen es denn Panasonic und Arri die 12 oder 14 Stops nach der Konvertierung zu erhalten? Da muss doch eigentlich auch komprimiert werden.
Man kommt zurück nach LOG?! In Resolve sieht das nach meiner Kenntnis anders aus, da gehen Highlights durch die Decke und sind verloren. Das ist ja das Problem, was ich mit der Verwendung von LUTs habe. Und du beschreibst ja selbst, dass man VOR der LUT anpassen muss. Wozu denn, wenn man danach auch noch an das LOG - und damit an die Dynamik - ran kommt?!DeeZiD hat geschrieben: ↑Do 11 Jun, 2020 01:22Schon richtig. Roll-off in den Schatten und Highlights, einfach ausgedrückt S-Kurve. Mit einer exakten negativen S-Kurve lassen sich diese wieder zurück nach Log 'biegen'.dienstag_01 hat geschrieben: ↑Do 11 Jun, 2020 01:13 Wie schaffen es denn Panasonic und Arri die 12 oder 14 Stops nach der Konvertierung zu erhalten? Da muss doch eigentlich auch komprimiert werden.
Da aber auch eine Gamut-Konvertierung in den deutlich kleineren Bt.709-Farbraum stattfinden muss, gehen Chroma-Informationen definitiv verloren.
Vielleicht wäre der Einsatz von ACES samt passender IDTs sinnvoller.
Da kein Sensor 709 ausgibt, wird die LUT halt in der Kamera drauf gelegt, statt in der Post. Macht dich halt noch unflexibler.dienstag_01 hat geschrieben: ↑Mi 10 Jun, 2020 22:53
Hm, aber wäre es dann nicht besser, gleich in 709 zu drehen?
Dass in der Kamera eine LUT drauf gelegt wird, so würde ich das interne Processing jetzt nicht nennen. Aber egal.Frank Glencairn hat geschrieben: ↑Do 11 Jun, 2020 08:26Da kein Sensor 709 ausgibt, wird die LUT halt in der Kamera drauf gelegt, statt in der Post. Macht dich halt noch unflexibler.dienstag_01 hat geschrieben: ↑Mi 10 Jun, 2020 22:53
Hm, aber wäre es dann nicht besser, gleich in 709 zu drehen?
Wie ich oben schon sagte, halte ich den ganze Testaufbau für extrem schwindlig, und damit ist auch das Ergebnis unbrauchbar.
Das geht mit den ganzen externen Variablen los - mal mit ND, mal ohne, mal mit IR mal ohne. Dann mal mit dual ISO bei der einen Kamera, die andere kann es halt nicht. Und am Ende halt noch Gepfusche in der Post.
Tatsächlich aussagekräftige und brauchbare Ergebnisse für die Praxis, erhält man nur bei einem praxisorientierten Versuchsaufbau.
Was glaubst du denn, was da sonst passiert?dienstag_01 hat geschrieben: ↑Do 11 Jun, 2020 09:29
Dass in der Kamera eine LUT drauf gelegt wird, so würde ich das interne Processing jetzt nicht nennen.