es geht bei mir mal wieder um die Frage von Videoleves und die interpretation von Premiere Pro und Davinci Resolve. Ich habe hier ein Frame der mittels 4k Scope auf den Himmel belichtet wurde. Gefilmt wurde mit A7s in S-Log2.Aufgenommen über einen Atomos Ninja2 in ProResHQ 422 und intern in XAVC-S. 4k_scope.jpg
Ich habe die Clips in Premiere Pro importiert um zu sehen wie die Levels dort angezeigt werden.Das ganze sieht so aus. ProRes_PP_Scope.jpgXAVCS_PP_Scope.jpg
Kann mir das jemand erklären?Ich hatte ja gelesen das bei S-Log2 und externen Rekordern die ProRes Dateien in full-range aufgenommen werden und das material lediglich falsch interpretiert wird und dadurch gestreckt wird. Aber wie kann es sein das der XAVC-S wesentlich dunkler ist?Ich hatte ja wie oben gesagt über 4k Scope belichtet. Waveform stand auf YCbCr. Kann mir das ganze jemand erläutern? Um die ganze Sache noch etwas abzurunden hab ich hier noch zwei Scopes aus Davinci. Einmal den XAVC-S Clip interpretiert mit Data-Levels und Video-Levels. Resolve_Scope_DataLevels.jpgResolve_Scope_VideoLevels.jpg
Da WoWu ja zu mir sagte das die Übertragung immer auf REC709 YUV (VideoLevels) erfolgen sollte um korrekte Ergebnisse bei der Messung zu bekommen sollte also Video-Levels die korrekte Einstellung sein oder nicht? Warum stimmen dann auch da die Scopes nicht mit dem überein was in 4K Scope auf dem Waveform angezeigt wurde?
EDIT: Bei Cine Gamma 4 besteht das Problem z.B. nicht.
Danke und viele Grüße
Jan
Antwort von dienstag_01:
Ich würde mal sagen, Full Range in Davinci ist Data Level ;)
Antwort von Janosch84:
Ja aber der XAVC-S Codec hat ja nur Video-Levels. Hatten wir doch neulich erst bei MediaInfo.
XAVC-S ist YUV, 8Bit 4:2:0 mit colour-range "Limited. Nun habe ich das Handbuch von Davinci so verstanden das wenn es sich um REC709 Material handelt Video-Levels immer die korrekte Wahl ist.
Grüße
Jan
Antwort von dienstag_01:
Janosch84 hat geschrieben:
Ja aber der XAVC-S Codec hat ja nur Video-Levels. Hatten wir doch neulich erst bei MediaInfo.
XAVC-S ist YUV, 8Bit 4:2:0 mit colour-range "Limited. Nun habe ich das Handbuch von Davinci so verstanden das wenn es sich um REC709 Material handelt Video-Levels immer die korrekte Wahl ist.
Grüße
Jan
Naja, siehst du ja, was in deiner Davinci-Kurve mit der Material passiert ;)
Prinzipiell sollte man verstehen, dass Log-Material nachbearbeitet werden muss, daher sind die Angaben über die Range irrelevant (bzw. gelten für Player) - man darf nur nichts in seine Software verlieren.
Du kannst also auch dein Material mit Video Level importieren und dann bearbeiten, wenn es die Software ermöglicht. Davinci ermöglicht das (du bekommst z.B. deine clippenden Weisswerte wieder in die Range runtergezogen).
Richtig wäre aber Full Range (so schreibt Sony). Und: ich bin mir nicht sicher, ob das Bearbeiten in Video Level keine Nachteile in Richtung Banding etc. mit sich bringt.
Antwort von Janosch84:
Dienstag_01: "Richtig wäre aber Full Range (so schreibt Sony)"
Hast du eine Quellenangabe oder einen Link dazu das ich mir das ganze mal durchlesen kann. Momentan hab ich was das angeht ein riesen Durcheinander in meinem Kopf.
Das Log Kurven nachbearbeitet werden ist mir klar. Ich versteh auch das Prinzip von S-Log. Aber wie wird das ganze dann in einem Waveform Monitor behandelt?
18%Grau was ich in S-Log2 auf 32% Belichte ( Wie es Sony ja auslegt) mit einem Echtzeit Scope, sollte doch auch auf den internen Scopes von Davinci oder Premiere Pro dann 32% haben. Sonst machen doch die Scopes keinen Sinn!?
EDIT: 18% Grau auf 32% belichtet in S-Log2 mit 4k Scope ergeben auch in Davinci und in Premiere Pro 32%. Hab ich grad getestet. Sowohl in ProRes als auch in XAVC-S. Warum sind dann 100% bei 4K Scope nur 90% im PremierePro Waveform bei dem XAVC-S Codec, aber 100% in 4K Scope = 100% bei dem ProRes Codec im Premiere Pro Waveform.
Grüße
Jan
Antwort von dienstag_01:
Hast du eine Quellenangabe oder einen Link dazu das ich mir das ganze mal durchlesen kann. Momentan hab ich was das angeht ein riesen Durcheinander in meinem Kopf.
Das Log Kurven nachbearbeitet werden ist mir klar. Ich versteh auch das Prinzip von S-Log. Aber wie wird das ganze dann in einem Waveform Monitor behandelt?
Link finde ich gerade nicht, sollte aber nicht so schwer sein (du schreibst es ja lustigerweise weiter oben selbst).
18%Grau was ich in S-Log2 auf 32% Belichte ( Wie es Sony ja auslegt) mit einem Echtzeit Scope, sollte doch auch auf den internen Scopes von Davinci oder Premiere Pro dann 32% haben. Sonst machen doch die Scopes keinen Sinn!?
Würde ich prinzipiell auch so sehen.
Ich denke aber, um das vergleichen zu können, müsstest du in Davinci (und natürlich auch in Premiere) ein Slog2 zu 709 Lut draufkrachen ;)
Antwort von Janosch84:
Was schreibe ich oben selbst?Ich würde in Davinci Full-Range(Data-Levels) einschalten wenn ich Material habe das einen Werebereich von 0-255 hat. Legal-Range (Video-Levels) in Davinci wenn ich REC709 Material habe das einen Wertebereich von 16-235 hat so wie der XAVC-S Codec der A7s.
Dienstag_01: "Würde ich prinzipiell auch so sehen"
Warum sind dann 700mV / 100% die mir 4K Scope direkt über HDMI aus der Kamera anzeigt nicht 100% / 700mV oder eben auch 235 auf dem Waveform Monitor in Premiere Pro wenn ich das XAVC-S Material in der Timeline habe?
EDIT: Wie oben schon gesagt, bei anderen Gammakurven wie Cine-Gamma4 ist den kompletten Weg über jeder Wert in jedem Scope gleich. 100% die ich in 4K Scope direkt aus der Kamera angezeigt bekomme sind auch in Premiere Pro oder in Davinci 100%.
Antwort von dienstag_01:
Ich hatte ja gelesen das bei S-Log2 und externen Rekordern die ProRes Dateien in full-range aufgenommen werden
Nur mal zur Erinnerung ;)
Wie vorhin schon gesagt, man kann nicht Material einmal mit und einmal ohne LUT vergleichen.
Kann man natürlich schon, bringt aber nichts ;)
Antwort von Janosch84:
"Wie vorhin schon gesagt, man kann nicht Material einmal mit und einmal ohne LUT vergleichen.
Kann man natürlich schon, bringt aber nichts ;)"
Was haben jetzt LUT's mit der Sache zu tun?LUT's hatte ich zu keinem Zeitpunkt auf dem Material.
Antwort von dienstag_01:
Janosch84 hat geschrieben:
"Wie vorhin schon gesagt, man kann nicht Material einmal mit und einmal ohne LUT vergleichen.
Kann man natürlich schon, bringt aber nichts ;)"
Was haben jetzt LUT's mit der Sache zu tun?LUT's hatte ich zu keinem Zeitpunkt auf dem Material.
Ok, dann hatte ich das falsch verstanden. Bzw. sieht dein 4k Scope so aus. Kann aber auch sein, dass er über HDMI einfach nur die legal Range anzeigt, dann passt das auch gut zu den anderen Scopes mit Video Level.
Antwort von Janosch84:
Ne ne über HDMI geht scheinbar so ein zwischen Ding zwischen full-range und legal-range raus. Das Signal geht niemals unter 0mV aber dafür bis hoch zu 1000mV/1Volt.
In wie weit spielt das eine Rolle?
Ich bring das alles mal zusammen:
Die A7s zeichnet intern XAVC-S in REC709 auf. Limited Range. YUV. Soweit korrekt oder?
Der HDMI Ausgang gibt ein Signal von 0mV bis 1V / 0% - 109% aus(Das sind zumindest die Werte die ich maximal erreiche). Gehe ich richtig davon aus das es ein YCbCr Signal ist?
Zum Problem:
700mV / 100% auf dem externen Waveform über HDMI (4K Scope Software) sind bei der internen Aufzeichung im XAVC-S Codec auf dem Premiere Pro CC Lumetri Waveform ca 90%
700mV / 100% auf dem externen Waveform über HDMI (4K Scope Software) sind bei der externen Aufzeichung im ProRes Codec auf dem Premiere Pro CC Lumetri Y Waveform ca100%
Davinci lass ich jetzt mal aussen vor. Das externe Scope über HDMI nehme ich jetzt als Referenz. Wie sind dann die unterschiedlichen Scopes in Premiere zu erklären?
Nach den ganzen Erklärungen im Netz sollte die XAVCS Datei im PPro Lumteri Waveform in den Spitzen bei etwas mehr als 100% liegen / etwas über 235 da diese korrekt interpretiert werden soll. Die ProRes Datei sollte demnach im PPro Lumetri Waveform gestreckt werden so das es weit über 100% / über 235 liegt. Das gegenteil ist aber der Fall. WARUM zum Teufel ist das so?
Antwort von dienstag_01:
Die A7s zeichnet intern XAVC-S in REC709 auf. Limited Range. YUV. Soweit korrekt oder?
Wenn du Slog aufnimmst, dann nimmt die Kamera in Slog auf. Das sollte schon so sein, oder ;)
Antwort von Janosch84:
Ja stimmt ;-)
Antwort von Janosch84:
Aber was passiert da jetzt mit den Waveforms?Niemand bereit mir das zu erklären?
Antwort von dienstag_01:
Ich bin leider gerade unterwegs, aber schau dir mal sie Skalen von Davinci und Premiere an, die haben unterschiedliche Bedeutungen.
Antwort von wolfgang:
Janosch84 hat geschrieben:
Ne ne über HDMI geht scheinbar so ein zwischen Ding zwischen full-range und legal-range raus. Das Signal geht niemals unter 0mV aber dafür bis hoch zu 1000mV/1Volt.
In wie weit spielt das eine Rolle?
Ich bring das alles mal zusammen:
Die A7s zeichnet intern XAVC-S in REC709 auf. Limited Range. YUV. Soweit korrekt oder?
Der HDMI Ausgang gibt ein Signal von 0mV bis 1V / 0% - 109% aus(Das sind zumindest die Werte die ich maximal erreiche). Gehe ich richtig davon aus das es ein YCbCr Signal ist?
Zum Problem:
700mV / 100% auf dem externen Waveform über HDMI (4K Scope Software) sind bei der internen Aufzeichung im XAVC-S Codec auf dem Premiere Pro CC Lumetri Waveform ca 90%
700mV / 100% auf dem externen Waveform über HDMI (4K Scope Software) sind bei der externen Aufzeichung im ProRes Codec auf dem Premiere Pro CC Lumetri Y Waveform ca100%
Davinci lass ich jetzt mal aussen vor. Das externe Scope über HDMI nehme ich jetzt als Referenz. Wie sind dann die unterschiedlichen Scopes in Premiere zu erklären?
Nach den ganzen Erklärungen im Netz sollte die XAVCS Datei im PPro Lumteri Waveform in den Spitzen bei etwas mehr als 100% liegen / etwas über 235 da diese korrekt interpretiert werden soll. Die ProRes Datei sollte demnach im PPro Lumetri Waveform gestreckt werden so das es weit über 100% / über 235 liegt. Das gegenteil ist aber der Fall. WARUM zum Teufel ist das so?
Schon mal auf die Idee gekommen dass die Software einfach Material auch mal falsch dekodieren könnte?
Antwort von Janosch84:
Hallo Wolfgang,
na klar bin ich auf die Idee auch schon gekommen. Aber wie könnte man das Prüfen?
Aber ich merke du hast dafür auch keine solide Erklärung. Ich habe den ganzen Tag damit verbracht im Internet etwas darüber zu finden. Das einzige das ich gefunden habe waren Beiträge aus dem Jahr 2014 die das Problem beschreiben. Allerdings geht es da wie oben schon gesagt um das falsche Mapping in ProRes Dateien. In diesen Beiträgen wird davon ausgegangen das Rekorder das 16-235 Signal auf 0-255 strecken. Das ganze passiert auch wirklich nur bei S-Log2. Alle anderen Cine-Gammas werden wie gesagt auf allen Scopes in allen Programmen gleich angezeigt. Ich würde sagen das das ganze schon am HDMI Ausgang passiert.
Grüße
Antwort von WoWu:
Janosch84 hat geschrieben:
Ne ne über HDMI geht scheinbar so ein zwischen Ding zwischen full-range und legal-range raus. Das Signal geht niemals unter 0mV aber dafür bis hoch zu 1000mV/1Volt.
In wie weit spielt das eine Rolle?
Ich bring das alles mal zusammen:
Die A7s zeichnet intern XAVC-S in REC709 auf. Limited Range. YUV. Soweit korrekt oder?
Der HDMI Ausgang gibt ein Signal von 0mV bis 1V / 0% - 109% aus(Das sind zumindest die Werte die ich maximal erreiche). Gehe ich richtig davon aus das es ein YCbCr Signal ist?
Zum Problem:
700mV / 100% auf dem externen Waveform über HDMI (4K Scope Software) sind bei der internen Aufzeichung im XAVC-S Codec auf dem Premiere Pro CC Lumetri Waveform ca 90%
700mV / 100% auf dem externen Waveform über HDMI (4K Scope Software) sind bei der externen Aufzeichung im ProRes Codec auf dem Premiere Pro CC Lumetri Y Waveform ca100%
Davinci lass ich jetzt mal aussen vor. Das externe Scope über HDMI nehme ich jetzt als Referenz. Wie sind dann die unterschiedlichen Scopes in Premiere zu erklären?
Nach den ganzen Erklärungen im Netz sollte die XAVCS Datei im PPro Lumteri Waveform in den Spitzen bei etwas mehr als 100% liegen / etwas über 235 da diese korrekt interpretiert werden soll. Die ProRes Datei sollte demnach im PPro Lumetri Waveform gestreckt werden so das es weit über 100% / über 235 liegt. Das gegenteil ist aber der Fall. WARUM zum Teufel ist das so?
Moin Janosch
Ich versuch das nochmal.
Du hast ein Signalpegel von 700mV.
Das sind 0-100 EL
Eingelagert in Übertragungswerte von 0-255 RGB
oder
16-235 in REC 709
Wenn Deine Kamera rec 709 macht, dann liegt dein Signal in diesem Wertebereich.
Wenn Du eine LOG Übertragungsfunktion benutzt, dann müssen die Endwerte nicht benutzt wrdeweil die Kamera bereits eine Gammaveränderung vorgenommen hat. Dann können z.B. die Werte 16-35 und die oberen Werte, z.B. 190-235 unbenutzt sein.
Dein Signal taucht also in einem schmalen Band dazwischen auf.
Die Übertragungswerte, die ungenutzt sind, sind verloren.
Daher ist eine LOG Anwendung in 8 Bit eine ziemliche Gradwanderung, weil auch schon bei geringer Nachbearbeitung Bandinggefahr besteht.
Du müsstest nämlich das Signal unten auf den Wert 16 und oben auf den Wert 235 ziehen, Du spreizt Dir also die paar Werte, daher die Bandinggefahr.
Nun kommen wir zu den Bewertungsfilterm des WF.
Legst Du 709 an, liegt Dein korrektes Signal zwischen 0 und 100%
Legst Du ein Bewertungsfilter an,das bis 109% geht, dann wird auch Dein Spitzensignal bis 109% gehen, weil es das Weiß ist, das die Kamera maximal erzeugt hat.
Das Filter dienst dazu, eine 100% Marke zu setzen, die aber eben 9% unterhalb des Systemweiss liegt.
109% sind dann 100 EL oder 700 mV
An Deinem Signal ändert sich ja nichts durch ein anderes Bewertungsfilter. Nur an der Skalierung.
Ich weiß, wenn man mit untetdlichen WF + Skalierungen + unterschiedlichen Signalquellen arbeitet ist das ziemlich verwirrend, deswegen musst Du wissen, wie Dein Signal aussieht, dass Du also immer mit 700 mV arbeitest, dass das Signal in unterschiedliche Übertragungen (RGB/709) eingebettet ist und dass die Scalierung lediglich eine unterstützende Funktion hat, also Anhaltspunkte gibt, die richtig gewählt werden sollten.
Es ist besser, solche Vprgänge einmal richtig verstanden zu haben, als wilde Skalierungen und unterschiedliche Signale zu interpretieren.
Antwort von Janosch84:
Hallo WoWu,
danke für deine ausführliche Antwort. Ich werde mir jetzt dein Buch zulegen in der Hoffnung das so Licht in die Dunkelheit kommt.
Danke und Grüße
Jan
Antwort von WoWu:
Moin Jan,
das klappt bestimmt.
Ansonsten Mail genügt, ... das kriegen wir schon gebacken.
Antwort von wolfgang:
Janosch84 hat geschrieben:
Hallo Wolfgang,
na klar bin ich auf die Idee auch schon gekommen. Aber wie könnte man das Prüfen?
Aber ich merke du hast dafür auch keine solide Erklärung. Ich habe den ganzen Tag damit verbracht im Internet etwas darüber zu finden. Das einzige das ich gefunden habe waren Beiträge aus dem Jahr 2014 die das Problem beschreiben. Allerdings geht es da wie oben schon gesagt um das falsche Mapping in ProRes Dateien. In diesen Beiträgen wird davon ausgegangen das Rekorder das 16-235 Signal auf 0-255 strecken. Das ganze passiert auch wirklich nur bei S-Log2. Alle anderen Cine-Gammas werden wie gesagt auf allen Scopes in allen Programmen gleich angezeigt. Ich würde sagen das das ganze schon am HDMI Ausgang passiert.
Grüße
Wie man das prüfen kann ist einfach: nämlich indem man Testbilder aus einem Signalgenerator mit einer bekannten Luminanzverteilung in dem fraglichem Format aufzeichnet und die in der zu testenden NLE im Waveform-Monitor analysiert. Sowas liefern heute ja selbst schon viele Kameras mit.
Würdest du das in verschiedenen NLEs vergleichen, dann würdest feststellen dass einige NLE das richtig mappen, andere hingegen falsch. So etwas findet man in der Praxis häufiger als man glauben würde - und auch bei verschiedenen Dateitypen. So habe ich etwa die Spreizung des Luminanzbereiches auf 0..255 etwa auch mal bei Edius nachweisen können, allerdings mit Edius und mit GH4 mp4 Datein. Oder auch bei Vegas (bis zur Version 13) mit ProRes Datein - dort ist das Phänomen auch bestens bekannt. Auch bei TMPGenc habe ich dieses Problem mit ProRes schon bemerkt.
Mit dem Rekorder hat das m.E. wenig zu tun, eher was damit wie die NLE das Material dekodiert. Denn sonst würden ja alle NLEs das gleiche Problem haben - und das ist eindeutig nicht der Fall.
Eine "solide Erklärung" der Hintergründe gebe ich sicher nicht, hat in der Praxis allerdings leider auch nur akademischen Wert: denn im realen Leben kannst nicht in den Dekoder deiner NLE eingreifen und kannst die Spreizung an sich nicht meist nicht korrigieren. Fallweise hat es auch schon geholfen eben mit 16..235 Einstellungen zu filmen (was ja "normgerecht" ist), damit läßt sich clipping in der Praxis vermeiden - denn wenn man 0..255 oder 16..255 aufzeichnet und dann in der NLE eine Spreizung erfolgt, hast zwangsweise clipping. Im besten Fall kannst du über Filter die Lumanzspreizung zu korrigieren versuchen - und selbst für so eine behelfsmäßige Korrektur brauchst eben die erwähnten Testbilder um eine passende Korrekturfunktion erstellen zu können. Dass dies alles nur Behelfe sind ist aber eh klar.
Antwort von dienstag_01:
Meiner Meinung nach kann man sehr gut sehen, was in den einzelnen Anwendungen mit den (verschiedenen) Materialien passiert.
Darauf kann man sich ja ohne Probleme einstellen.
Wenn man wirklich wissen will, nach was man belichten soll, ist das alles schon etwas komplexer, hier gibt es einen Artikel, der das beschreibt: http://www.xdcam-user.com/2014/08/expos ... -exposure/
Da sollte man dann auch mal die externen Scopes mit denen In-Camera vergleichen.
Antwort von mash_gh4:
dienstag_01 hat geschrieben:
Meiner Meinung nach kann man sehr gut sehen, was in den einzelnen Anwendungen mit den (verschiedenen) Materialien passiert.
sehe ich auch so!
im übrigen können sehr viele kameras auch die üblichen testmuster generieren, an denen man die level in der weiteren verarbeitungskette ziemlich einfach überprüfen kann bzw. sich einen sauber funktionieren workflow erarbeiten kann.
nervig ist die ganze sache ja ohnehin nur deshalb, weil manche hersteller den anwendern zu viele -- tlw. unsinnig -- einstellmöglichkeiten anbieten bzw. die ursprünglichen übertragungskonventionen proprietärer lösungen schlichtweg ignorieren od. falsch handhaben.
im falle von .mov containern tritt das ganz besonders häufig auf, weil dort das entsprechende flag zur markierung des genutzten werteumfangs auf containerebene fehlt. bei .mp4, das technisch gesehen fast das selbe ist, wurde diese angabe allerdings hinzugefügt. deshalb gibt's damit auch weniger probleme. im falle von .mov muss man halt selbst dafür sorgen, dass 4:2:2 und 4:2:0 codecs nur 'legal range' nutzen, wenn man den ursprünglichen apple-vorgaben bzw. -konventionen gerecht werden will.
Antwort von WoWu:
Das Flag gehört auch nicht in den Container, sondern in den Codec, z.B. in das video usability information (VUI) layer bei H.264, in der NAL unit (Network Abstraction Layer.
Manche Codecs lassen gar keine FR zu. ProRes ist z. B. ein Codec, der nur in limited Range arbeitet. Versucht also die Kamera das Bit neu zu setzen, gelingt das gar nicht.
Das Verständnisproblem liegt also beim Anwender, der versucht, da FR zu benutzen und sich hinterher wundert, dass nur LR rauskommt, sofern sein NLE das Flag ausliest.
Liest es das nicht aus und er setzt dann FR manuell, ist das Problem vorprogrammiert.
Aber -wie gesagt- Fehlbedienung.
Antwort von Janosch84:
Hallo Leute,
ich bin der Meinung das der HDMI Ausgang der A7s das Signal bereits streckt. Wie ich darauf komme?Ich habe eine GH4 über den Waveform von 4K Scope laufen lassen mit aktivem SMPTE Farbbalken. Alles wurde wie erwartet dargestellt. Danach habe ich den Farbbalken intern im .mov Container und danach in mp4 Aufgezeichnet und in PremierePro importiert. Ebenfalls keine unterschiede.
Dann habe ich diesen Vorgang widerholt aber die Einstellungen an der GH4 jeweils auf 0-255 und danach auf 16-235 gewechselt. Jetzt der Farbbalken jeweil anders in PremierePro angezeigt. Die Clips die mit einem Übertragungswert von 0-255 in der GH4 markiert wurden wurden wie erwartet gestaucht. Auch alles soweit richtig nach meinem Verständnis. In Davinci wurden alle Clips wieder gleich angezigt mit dem Setting der Levels auf "Auto"
Den selben Vorgang habe ich dann mit einem Ninja2 über HDMI widerholt. ProRes und DNxHD wurden korrekt in Premiere interpretiert. Beim wechsel von 0-255 auf 16-235 blieb das Signal ebenfalls gleich. Sowohl in 4K Scope als auch in PremierePro. Für mich bedeutet das, das der Signalweg erstmal funktioniert, der Waveform in 4k Scope richtig eingestellt ist und auch PremierePro alle verwendeten Codecs korrekt interpretiert. Auch die des Ninja2
Nun zu der Sony A7s. Für mich ist da definitv nichts klar. Wenn ich über den Waveform von 4K Scope, den Ninja2 mit False-Color und auch noch über Zebra (bei Überbelichtung) überall die selben Werte bekomme aber die XAVC-S Files in PremierePro dennoch 1 bis 2 Blendenstufen unterschied beinhalten halte ich das für ein ganz schönes Problem.Besonders beim belichten mit externen Geräten. Die Theorie das es sich dabei nur um ein falsches Mapping handelt kann in meinen Augen nicht stimmen. Das Signal muss schon am HDMI Ausgang gestreckt werden oder wie sind sonst diese Differenzen zu erklären? Wie gesagt, das "Problem" ist nur bei S-Log2. Für alle die es selber sehen wollen in ihren eigenen Scopes, habe ich hier einen Link: https://mab.to/fPDuDf5EP
Dort sind die originalen Daten drin sowie Screenshot des Waveform von 4K Scope mit dem dirketen Signal über HDMI in eine Intensity Pro PCIe. Belichtet wurde wie Alister Chapman es beschreibt. 18%Grau vom Datacolor SpyderChekr24. Kamera im Automatikmodus mit Blendenpriorität. Überbelichtet mit der Belichtungskorrektur um jeweils eine Blende. Das Signal wurde durch den Ninja2 durchgeschliffen. Die Waveform bleibt aber die selbe wenn man die Kamera direkt an die Intensity steckt ohne den Ninja2.
Viele Grüße und ein schönes Wochenende
Antwort von dienstag_01:
WoWu hat geschrieben:
Das Flag gehört auch nicht in den Container, sondern in den Codec, z.B. in das video usability information (VUI) layer bei H.264, in der NAL unit (Network Abstraction Layer.
Manche Codecs lassen gar keine FR zu. ProRes ist z. B. ein Codec, der nur in limited Range arbeitet. Versucht also die Kamera das Bit neu zu setzen, gelingt das gar nicht.
Das Verständnisproblem liegt also beim Anwender, der versucht, da FR zu benutzen und sich hinterher wundert, dass nur LR rauskommt, sofern sein NLE das Flag ausliest.
Liest es das nicht aus und er setzt dann FR manuell, ist das Problem vorprogrammiert.
Aber -wie gesagt- Fehlbedienung.
Wenn man sich die beiden Scopes oben mit ProRes (extern) und XAVC (intern) anschaut, sieht man eigentlich sehr klar, dass Legal Range für das ProRes File nicht stimmen kann.
Ist ja auch kein 709 sondern Log.
Antwort von Janosch84:
"Wenn man sich die beiden Scopes oben mit ProRes (extern) und XAVC (intern) anschaut, sieht man eigentlich sehr klar, dass Legal Range für das ProRes File nicht stimmen kann.
Ist ja auch kein 709 sondern Log."
Log, egal ob S-Log oder C-Log oder ähnliches wird doch trotzdem in die übertragungswerte 16-235 gequtscht oder?
Grüße
Jan
Antwort von mash_gh4:
WoWu hat geschrieben:
Das Flag gehört auch nicht in den Container, sondern in den Codec, z.B. in das video usability information (VUI) layer bei H.264, in der NAL unit (Network Abstraction Layer.
das mag zwar deine persönliche meinung dazu sein, nur hat apple leider ursprünglich auch h.264 in .mov containern nur in der legal range variante benutzt bzw. vorgesehen. manche bekannten programme (premiere, davinvci) scheren sich darum einen dreck und handhaben es leider default-mäßig oft genau umgekehrt.
ich kann deine sichtweise zwar durchaus verstehen, weil es in der praxis nur noch weitere probleme verursacht, wenn bspw. auf container- und codec-ebene widersprüchliche informationen eingetragen sind (was ja leider bei .mp4 manchmal sogar in der praxis anzutreffen ist), trotzdem ändert das nicht an dem grundsätzlichen problem, dass eben manche programme bzw. implementation sich strenger an den ursprünglichen apple spezifikationen orientieren, während andere -- und darunter sehr verbreitete -- ihr gänzlich eigenes süppchen kochen und durch inkompatibles handling glänzen. :(
Antwort von mash_gh4:
Janosch84 hat geschrieben:
Log, egal ob S-Log oder C-Log oder ähnliches wird doch trotzdem in die übertragungswerte 16-235 gequtscht oder?
praktisch alle LOG-varianten die ich kenne, nutzen von haus aus nur werte die im legal range umfang platz finden. (was natürlich nicht besagt, dass auch diese werte falsch behandelt werden können, wenn das aufnahmegerät od. verarbeitungsprogramm die entsprechenden bezugswerte falsch interpretiert)
wenn du tatsächlich prores im full range mode benutzten willst, musst du zu den 4:4:4 varianten greifen. dort ist so vorgesehen.
Antwort von Janosch84:
Ich will nicht ProRes im Full-Range nutzen sondern lediglich schöne Bilder drehen die auch technisch Hand und Fuß haben. Mehr will ich garnicht :-)
Grüße
Jan
Antwort von WoWu:
ProResist aber nun mal ein LegalRange codec und kann gar kein FullRange.
@Jan
Ja, LOG wird in die Range des Codecs eingebettet, aber nutzt in der Übertragung (z.b.Log3) nur einen geringeren Teil der verfügbaren Werte.
@mash
Apple hat das Flag "hart verdrahtet" und es gibt kein Containerflag, das das aushebeln könnte, es sei denn, der User setzt die Flagerkennung außer kraft und setzt den Wert auf FullRange.
Das hat aber nichts mit den NLEs zu tun und die Container haben solche Flags gar nicht, weil sie gar nicht wissen, was im Container eigentlich transportiert wir, geschweige denn, irgendwelche Parameter setzen.
Das hat übrigens mit "Meinung" nicht zu tun, solche Dinge kann man bei APPLE in den Programmierpapers nachlesen.
Antwort von dienstag_01:
Log, egal ob S-Log oder C-Log oder ähnliches wird doch trotzdem in die übertragungswerte 16-235 gequtscht oder?
Naja, eigentlich ist der genutzte Wertebereich noch kleiner. Daher ja auch die Banding-Probleme bei 8bit Material. Ist also eine irgendwie unsinnige Aussage.
Antwort von Janosch84:
Warum unsinnige Aussage?Auch Log Material kann ich doch überbelichten bis zu einem Wert von 235. Man kann doch also den gesamten Bereich zwischen 16 und 235 nutzen oder nicht?Es hängt doch auch vom Motiv ab.
Grüße
Jan
Antwort von dienstag_01:
Na, dann belichte es doch mal richtig über, dann siehst du, wo das hingeht ;)
Antwort von WoWu:
@Jan
Nicht unbedingt.
Schau Dir mal VLog in der Varicam und der GH4 an.
Der Sensor der Varycam liegt im Systemweiss rd. 3 Blenden höher, die der Sensor der GH4 gar nicht mehr kann.
Es kommt also ganz darauf an, wo die Grenze Deines Sensors ist.
Antwort von Janosch84:
Muss ich mir mal ansehen. Aber das ist ja auch hier nicht das Thema ;-)
Grüße
Jan
Antwort von dienstag_01:
Hast du das mal mit deinen In-Camera-Scopes verglichen?
Antwort von mash_gh4:
WoWu hat geschrieben:
@mash
Apple hat das Flag "hart verdrahtet" und es gibt kein Containerflag, das das aushebeln könnte, es sei denn, der User setzt die Flagerkennung außer kraft und setzt den Wert auf FullRange.
Das hat aber nichts mit den NLEs zu tun und die Container haben solche Flags gar nicht, weil sie gar nicht wissen, was im Container eigentlich transportiert wir, geschweige denn, irgendwelche Parameter setzen.
du irrst dich hier schlicht und einfach:
"The QuickTime file format was adapted to become the ISO Base Media File Format, but with the color characteristic atom changed to “nclx” and the data augmented by an additional field that indicates whether the colour data is encoded at studio-swing (as is standard in BT.601 and BT.709) of “full-swing” (as is the custom for so-called sYCC)." (http://www.poynton.com/notes/misc/sde-n ... -nclx.html)
WoWu hat geschrieben:
Das hat übrigens mit "Meinung" nicht zu tun, solche Dinge kann man bei APPLE in den Programmierpapers nachlesen.
keine sorge, ich weiß, wie zweifelhaft das in den sgn. "Letters from the Ice Floe" von apple ursprünglich kommuniziert wurde, sonst würde ich dich für deine irreführenden aussagen auch nicht so überzeugt kritisieren.
Antwort von Janosch84:
@Dienstag,
wie schon vorhin geschrieben habe ich den Waveform von 4K scope laufen gehabt,beim Ninja2 False-Color aktiviert und Zebra auf 70% (geringste Einstellung) in der A7s eingeschaltet.Die Werte lagen auf allen drei Gerät im selben Bereich bei dem Live HDMI Signal.
Grüße
Jan
Antwort von wolfgang:
Janosch84 hat geschrieben:
Hallo Leute,
ich bin der Meinung das der HDMI Ausgang der A7s das Signal bereits streckt. Wie ich darauf komme?Ich habe eine GH4 über den Waveform von 4K Scope laufen lassen mit aktivem SMPTE Farbbalken. Alles wurde wie erwartet dargestellt. Danach habe ich den Farbbalken intern im .mov Container und danach in mp4 Aufgezeichnet und in PremierePro importiert. Ebenfalls keine unterschiede.
Dann habe ich diesen Vorgang widerholt aber die Einstellungen an der GH4 jeweils auf 0-255 und danach auf 16-235 gewechselt. Jetzt der Farbbalken jeweil anders in PremierePro angezeigt. Die Clips die mit einem Übertragungswert von 0-255 in der GH4 markiert wurden wurden wie erwartet gestaucht. Auch alles soweit richtig nach meinem Verständnis. In Davinci wurden alle Clips wieder gleich angezigt mit dem Setting der Levels auf "Auto"
Den selben Vorgang habe ich dann mit einem Ninja2 über HDMI widerholt. ProRes und DNxHD wurden korrekt in Premiere interpretiert. Beim wechsel von 0-255 auf 16-235 blieb das Signal ebenfalls gleich. Sowohl in 4K Scope als auch in PremierePro. Für mich bedeutet das, das der Signalweg erstmal funktioniert, der Waveform in 4k Scope richtig eingestellt ist und auch PremierePro alle verwendeten Codecs korrekt interpretiert. Auch die des Ninja2
Nun zu der Sony A7s. Für mich ist da definitv nichts klar. Wenn ich über den Waveform von 4K Scope, den Ninja2 mit False-Color und auch noch über Zebra (bei Überbelichtung) überall die selben Werte bekomme aber die XAVC-S Files in PremierePro dennoch 1 bis 2 Blendenstufen unterschied beinhalten halte ich das für ein ganz schönes Problem.Besonders beim belichten mit externen Geräten. Die Theorie das es sich dabei nur um ein falsches Mapping handelt kann in meinen Augen nicht stimmen. Das Signal muss schon am HDMI Ausgang gestreckt werden oder wie sind sonst diese Differenzen zu erklären? Wie gesagt, das "Problem" ist nur bei S-Log2. Für alle die es selber sehen wollen in ihren eigenen Scopes, habe ich hier einen Link: https://mab.to/fPDuDf5EP
Dort sind die originalen Daten drin sowie Screenshot des Waveform von 4K Scope mit dem dirketen Signal über HDMI in eine Intensity Pro PCIe. Belichtet wurde wie Alister Chapman es beschreibt. 18%Grau vom Datacolor SpyderChekr24. Kamera im Automatikmodus mit Blendenpriorität. Überbelichtet mit der Belichtungskorrektur um jeweils eine Blende. Das Signal wurde durch den Ninja2 durchgeschliffen. Die Waveform bleibt aber die selbe wenn man die Kamera direkt an die Intensity steckt ohne den Ninja2.
Viele Grüße und ein schönes Wochenende
Ich schließe es mit ziemlicher Sicherheit aus dass hier bereits am HDMI-Eingang des Rekorders eine falsche Spreizung vorliegt.
Warum? Na einfach deshalb weil man ja mit den internen Waveform Monitor der Rekorder - wie etwa bei meinem Shogun - sehr wohl prüfen kann dass die Übertragung korrekt erfolgt. Gerade mit der GH4 lassen sich ja über den dort integrierten Signalgenerator die Testbilder ausgeben, und die werden eben im Waveform Monitor des Rekorders - also nach erfolgter HDMI-Übertragung von der GH4 in den Rekorder - völlig korrekt angezeigt.
Aber wenn man die mit dem Shogun die Testbilder aufzeichnet, und zwar durchaus in den 3 verschiedenen Luminanzeinstellungen 0..255, 16..255 und 16..235, und die dann in NLEs importiert und dort prüft, dann erhält man je nach verwendeter NLE eben durchaus verschiedene Signalspreizungen.
Die Umschaltung der GH4 Einstellung führt bei mir auch in der Waveform-Darstellung des Shoguns sehr wohl zu geänderten Luminanzlevels - getestet mit Darstellungen wo man bewußt bis ins Clipping geht.
Hier hatte ich mal Testbalken abgelegt - in ProRes mit dem Shogun aufgezeichnet, und intern mit der GH4 aufgezeichnet.
ja das mag alles sein was du schreibst.Mit der GH4 war auch alles okay.Nur geht es hier um eine SONY A7s mit dem Picture Profile S-Log2.Einfach mal die Daten runterladen und selber vergleichen.Und wie gesagt wenn mir der externe Waveform,False-Color und Zebra die gleichen Werte anzeigen und diese mit dem ProRes Material mehr übereinstimmen als die Interne XAVC-S Aufzeichnung im Scope von PremierePro scheint ja etwas nicht zu stimmen.
Grüße
Jan
EDIT: Wolfgang das hatte ich grad überlesen.Bei dir ändert sich der HDMI Ausgang mit SMPTE Balken im Waveform wenn du den Wertebereich änderst?Bei mir war das nicht der Fall.Dann muss ich meinen Signalweg doch noch mal prüfen!
Antwort von dienstag_01:
Um mal den akademischen Teil abzuschließen (habe es leider nur für S-Log3 gefunden, aber S-Log zwei unterscheidet sich da nur in den Werten): http://community.sony.com/sony/attachme ... _V1_00.pdf
(da gibt es auch eine klare Aussage zur Range)
dienstag_01 hat geschrieben:
(da gibt es auch eine klare Aussage zur Range)
ja -- mit dem hinweis hast du recht!
muss meine gegenteilige aussage weiter oben korrigieren... (sorry)
allerdings, sollte man das dann halt wirklich nicht prores zu kombinieren versuchen -- und wenn, dann bestenfalls mit den 4:4:4 varianten, die von haus aus full-range nutzen.
Antwort von wolfgang:
Janosch84 hat geschrieben:
Nun zu der Sony A7s. Für mich ist da definitv nichts klar. Wenn ich über den Waveform von 4K Scope, den Ninja2 mit False-Color und auch noch über Zebra (bei Überbelichtung) überall die selben Werte bekomme aber die XAVC-S Files in PremierePro dennoch 1 bis 2 Blendenstufen unterschied beinhalten halte ich das für ein ganz schönes Problem.Besonders beim belichten mit externen Geräten. Die Theorie das es sich dabei nur um ein falsches Mapping handelt kann in meinen Augen nicht stimmen. Das Signal muss schon am HDMI Ausgang gestreckt werden oder wie sind sonst diese Differenzen zu erklären? Wie gesagt, das "Problem" ist nur bei S-Log2. Für alle die es selber sehen wollen in ihren eigenen Scopes, habe ich hier einen Link: https://mab.to/fPDuDf5EP
Dort sind die originalen Daten drin sowie Screenshot des Waveform von 4K Scope mit dem dirketen Signal über HDMI in eine Intensity Pro PCIe. Belichtet wurde wie Alister Chapman es beschreibt. 18%Grau vom Datacolor SpyderChekr24. Kamera im Automatikmodus mit Blendenpriorität. Überbelichtet mit der Belichtungskorrektur um jeweils eine Blende. Das Signal wurde durch den Ninja2 durchgeschliffen. Die Waveform bleibt aber die selbe wenn man die Kamera direkt an die Intensity steckt ohne den Ninja2.
Also bitte - ich habe mir mal diese Dateien genommen und in Vegas Pro 14 analysiert.
Zunächst habe ich über einen Vegasinternen Mediagenerator gezeigt, dass der Waverom-Monitor so eingestellt ist, dass 16 = 0% und 235 = 100% sind (das ist in Vegas umstellbar). Snapshoot 1
Dann habe ich die zusammengehörenden DNxHD und die intern aufgezeichneten Dateien jeweils hintereinander angeordnet, und für jedes Paar mit dir die Snapshoots erstellt. Snapshoot 2A ist also etwa die DNxHD Datei 001, und Snapshoot 2B die korrespondierende Kameraintern aufgezeichnete Datei.
Das würde für jede Dateikombination gemacht.
Wenn du dir die Snapshoot-Serie ansiehst, dann erkennst du, dass in Vegas Pro 14 (Einstellung 8bit) sämtliche Waveformdarstellungen der jeweils korrespondierenden Snapshoots praktisch ident sind.
Unterschiede zwischen der internen XAVC-S und externen DNxHD Aufzeichnung sehe ich daher in Vegas 14 keinen, was den Luminanzumfang angeht. Ist das bei deiner Anwendung anders?
Was mir an deinen snapshoots nicht klar ist: sind die von den DNxHD oder XAVC-S Files?
Antwort von Janosch84:
Hallo Wolfgang,
vielen vielen Dank dafür. Das bringt schon etwas Licht ins Dunkle.Die Snapshots sind von einem Waveform Monitor der das direkte Signal aus der Kamera anzeigt.
Und ja bei mir in Premiere Pro CC2017 sind die DNxHD Files und die XAVCS Files komplett anders.
EDIT: Wie gesagt die Snapshots vom Waveform sind das direkte HDMI Signal aus der A7s.Belichtet wurde Automatisch von der Kamera auf das 18% Grau. Dieses landet ja im Waveform auch auf dem entsprechenden Wert der für S-Log2 von Sony vorgegeben wird. Es scheint also Korrekt eingestellt zu sein!
In Premiere Pro trifft das dann auch bei der korrrekten Belichtung auf den DNxHD und den XAVC-S Clip zu der normal belichtet wurde. D.h. 18% Grau bei 32%.
Bei einer Überbelichtung von einer Blende fangen die DNxHD Files und die XAVC-S Files an auseinander zu laufen.Bei dem letzten Clip ist der unterschied zwischen DNxHD und XAVC-S in PremierePro im Waveform am größten.
Viele Grüße
Jan
Antwort von wolfgang:
Na mir ist nur aufgefallen dass deine snapshoots mit meinem Anzeigen in Vegas ident sein dürften (vorausgesetzt die Einstellungen sind in deinem Monitor auch 0% = 16 und 100% = 235, und die Skala ist weil nur in 25% Schritten nummeriert etwas schwer ablesbar).
Aber wenn der Befund ist, dass sowohl dein Monitor wie auch die Anzeigen in Vegas - sowohl für die interne XAVC wie auch externe DNxHD Aufnahme - ident sind, dann ist die These widerlegt dass es am HDMI Ausgang zu einer Luminanzspreizung kommt (sonst müsste DNxHD ja auch in Vegas gespreizt erscheinen).
Es bleibt somit eher die These dass deine Software DNxHD mit Luminanzspreizung und damit leider falsch dekodiert. Mit slog2 dürfte das wenig zu tun haben, sondern mit dem in der Software verbauten DNxHD Dekoder.
Das Folgeproblem liegt auf der Hand: dadurch können Hoch- und Tieftöner in deiner Software früher als erforderlich geclippt werden und damit verloren gehen. Mit der typischen Überbelichtungsstrategie von Alister verstärkst du das vermutlich nur noch, da du im Feld eventuell auf 100% belichtest und dir das dann die NLE die Hochtöner clippt.
Ich würde mir daher mal ansehen ob es mit der ProRes Aufzeichnung das gleiche Problem gibt.
Antwort von wolfgang:
Und ich würde auch eher die Waveformanzeige im Ninja verwenden.
Antwort von Janosch84:
Hier mal ein direkter vergleich zwischen dem Waveform vom HDMI Signal und dem Waveform der DNxHD sowie der XAVC-S Files. S-Log2_18%Grau.jpg02_XAVC-S_S-Log2_18%Grau.png01_DNxHD_S-Log2_18%Grau.png
Der Ninja2 hat kein Waveform sondern nur Fales-Color. Auch dieser zeigte mir den korrekten Wert für 18% Grau im S-Log2 an. Es lag im Fales-Color des Ninja2 im Bereich von 30%.
Die einzige Datei,aber wirklich die einzige ist die XAVC-S Datei die mir das in Premiere Pro nicht anzeigt. Wenn man aber jetzt davon ausgeht das diese ja richtig gemapt ist mit 16-235 dann muss also das Scope und Fales-Color irgendwie Falsch (zu hell) sein. Und das kann dann nur am HDMI Ausgang liegen oder nicht?Denn der externe Waveform der über HDMI an die Kamera angeschlossen ist zeigt lediglich das anliegende Signal. Es wandelt nichts um, das hat der Test mit der GH4 und dem SMPTE Farbbalken gezeigt.
Es könnte natürlich auch sein das das Mapping der XAVC-S Datei nicht stimmt.
Grüße
Antwort von wolfgang:
Schau dir mal die letzten 3 Bilder genau an.
Alle drei Bilder zeigen den Weisspunkt etwas über 60%. Aber bei den beiden Premiere Anzeigen ist der Schwarzpunkt einmal über und einmal unter 10%. Waren das wirklich exakt die gleichen Einstellungen, oder sieht man hier eine leicht unterschiedliche Dekodierung durch Premiere im Schwarzpunkt?
Bei der Monitoranteigr ist die rechte Prozentskala ehrlich gesagt für mich unklar. Der eingeprägte Wert von 25% passt nicht genau mit den Unterskalierungen zusammen, auch nicht mit den durchgängigen horizontalen Linien die bei 50% und 75% exakt mit der Unterskalierung zusammen passt. Merkwürdig.
Antwort von Janosch84:
Es waren exakt die selben Einstellungen.Sowohl in der Kamera als auch später in Premiere. Die Unterschiede sehe ich auch und genau darum geht es mir ja.
Antwort von dienstag_01:
Sag mal, ist das so schwer zu verstehen, dass unterschiedliche Files von verschiedener Software unterschiedlich interpretiert wird? Dann sollte es spätestens jetzt klar sein ;)
Antwort von Janosch84:
Hier noch die Screenshot der überbelichteten Bilder.Da sieht man das sich die Waveform bei XAVC-S und DNxHD auch nach oben hin dann sehr stark unterscheidet. S-Log2_18%Grau+1.jpg04_XAVC-S_S-Log2_18%Grau_+1.png03_DNxHD_S-Log2_18%Grau_+1.png
Antwort von Janosch84:
@Dienstag
Ja das hab ich schon geschnallt. Aber die Frage ist doch hier wo hier was schief läuft. Bei der XAVC-S Datei,am Kameraausgang oder bei der DNxHD Datei. Der Waveform des HDMI Signals sagt doch das alles Stimmt. 700mV sind 100% Bildamplitude. 32% sind dann 224mV. Wird so angezeigt. Und wie gesagt S-Log2,18% bei 32% = 224mV
Antwort von Janosch84:
Achso noch vergessen. Da sich ja das Waveform des DNxHD Files in Premiere und die des externen Waveforms ziemlich ähnlich sehen darf ja die Frage erlaubt sein Warum das so ist wenn es doch die DNxHD Datei sein soll die Falsch in Premiere Interpretiert wird. Denn noch einmal.....das externe Waveform sowie der Ninja2 greift doch nur das Signal ab und zeigt mir die Helligkeit im Bild. Das hat doch mit Codecs und ob XAVC-S oder DNxHD garnichts zu tun nach meinem Verständis.
Antwort von dienstag_01:
Aus zwei mal falsch interpretiert wird im Ergebnis wieder richtig. Auch schön ;)
Wobei das ja nicht *richtig* ist, nur mit dem Waveform Monitor übereinstimmend ;)
Antwort von Janosch84:
Ah okay du meinst also das das der Waveform nicht stimmt und ich das Falsch interpretiere. Hast du dir meine anderen Post's gelesen und das ich eine GH4 mit SMPTE Farbbalken angeschlossen hatte an das Waveform über HDMI. Komisch da wurde alles korrekt angezeigt. Weiß bei 700mV.Schwarz bei 0mV und auch das Superschwarz wurde angezeigt. Also ist doch davon auszugehen das es korrekt Arbeitet und ich es korrekt ablese.
Antwort von dienstag_01:
Na, dann ist es doch super ;)
Antwort von Janosch84:
Ja find ich auch super :-) weil es zeigt das der Waveform korrekt arbeitet. Das scheinst du allerdings nicht zu glauben und da frage ich mich warum?Lass mich teilhaben an deinen Gedanken ;-)
Antwort von dienstag_01:
Ich hatte weiter oben zwei Sachen verlinkt, vielleicht kannst du damit was anfangen.
Antwort von Janosch84:
Ja hatte ich mir angesehen. Da steht drin das 18% einen Wertebereich von ca 340 in 10 Bit hat. In 8 Bit macht das dann 85. Haut halbwegs hin mit den Scopes in PremierePro die auf 18% Grau belichtet wurden. Da steht aber auch das S-Log3 in Full-Range aufgezeichnet wird innerhalb von XAVC.
"S-Log3 is recorded as Full range in XAVC, MPEG and HDCAM SR File. Camera SDI output is also
Full range every time. There is no option to select Legal range to prevent miss operation."
Wenn das auch für S-Log2 gilt....hmm....dann würde ich sagen das der XAVC-S Codec einen Wertebereich von 0-255 hat. Da aber Premiere mit einem Wertebereich von 16-235 arbeitet wird der 0-255 XAVC-S File gestaucht. Das würde den Unterschied zur DNxHD Datei erklären die in 16-235 vorliegt.Der HDMI Ausgang arbeitet dann auch Korrekt in 16-235 YCbCr.
Hab ich es jetzt?
Antwort von Janosch84:
Ohhhhh man. Ich hab grad den XAVC-S File in MediaInfo geöffnet. Da steht tatsächlich Full bei Color-Range.
Ich dachte XAVC-S ist immer Limited :-( Bildschirmfoto 2017-07-08 um 12.43.59.png
Antwort von dienstag_01:
In dem Sony Dokument ist ja der Fall *internes File in Davinci* beschrieben. Das wäre meine Referenz.
Aber was nützt dir das, wenn Premiere das anders macht? Nicht viel, vermute ich, man kann ja da nichts umstellen.
Wirklich problematisch wird es ja nur im Workflow mit anderen Kameras/Quellen und/oder bei der Verwendung von LUTs. Bei letzterem sollte die Range schon stimmen (oder angepasst sein), sonst wirds ne Katastrophe ;)
Antwort von Janosch84:
Also ist meine Interpretation von der ganzen Sache jetzt richtig?
Für mich bringt es eine Menge was den Workflow angeht. Wenn ich in S-Log2 filme dann nutze ich nur noch die DNxHD Files in Premiere.
Antwort von wolfgang:
Vegas ist eine Software die die Datein immer im full range anzeigt. Es liegt am User hier eine Einschränkung vorzunehmen, wenn er das will.
Daher hat man unter Vegas im Regelfall kein Problem mit Stauchungen des Luminanzbereiches, und es entsteht kein Unterschied zwischen den XAVC und dem DNxHD.
Nun zeichnen praktisch alle Consumercameras aber auch über 235 auf. Wenn Premiere beim Dekodieren den Luminanzbereich von XAVC staucht beobachtest dann die Unterschiede.
Über HDMI beobachte jch eigentlich nie derartige Veränderungen im Luminanzbereich. Das habe ich weder beim Ninja Blade noch beim Shogun jemals gesehen (beide haben Waveform Monitore). Unterschiede machen eben erst die NLEs.
Pragmatisch betrachtet kannst nur schauen ob das bei der Verwendung von ProRes besser ist. Denn deine NLE kannst nicht verändern.
Antwort von dienstag_01:
Janosch84 hat geschrieben:
Also ist meine Interpretation von der ganzen Sache jetzt richtig?
Für mich bringt es eine Menge was den Workflow angeht. Wenn ich in S-Log2 filme dann nutze ich nur noch die DNxHD Files in Premiere.
Wichtig wäre nur, dass dir klar ist, dass alles über 235 und unter 16 in Premiere *weg* ist (wird nicht mehr angezeigt), also zurückgeholt werden muss.
Antwort von wolfgang:
Wenn es richtig sein sollte dass DNxHD 16..235 footage in Premiere NOCHMALS gespreizt wird, dann verliert man selbst beim Einhalten von 16..235 bei der Aufnahme offenbar nach oben und hin nochmals Werte.
Das ist unschön, noch dazu wenn man eh schon nur mit 8bit startet. Ich wiederhole daher die Empfehlung das auch mir ProRes auszutesten. Vielleicht ist Premiere damit besser.
Antwort von Janosch84:
Hallo Wolfang,
das DNxHD wird korrekt dargestellt das es wie von Premiere gefordert ja 16-235 ist.Da wird nichts gestaucht oder gestreckt.Einzig die XAVC-S wird gestaucht da diese 0-255 ist.
Daher werde ich in Zukunft nur mit dem DNxHD Material arbeiten.
@Dienstag:
Ja das ist mir klar.Das wäre doch aber auch der Fall wenn die XAVC-S Datei richtig interpretiert werden würde!?
Antwort von dienstag_01:
Janosch84 hat geschrieben:
Hallo Wolfang,
das DNxHD wird korrekt dargestellt das es wie von Premiere gefordert ja 16-235 ist.Da wird nichts gestaucht oder gestreckt.Einzig die XAVC-S wird gestaucht da diese 0-255 ist.
Daher werde ich in Zukunft nur mit dem DNxHD Material arbeiten.
@Dienstag:
Ja das ist mir klar.Das wäre doch aber auch der Fall wenn die XAVC-S Datei richtig interpretiert werden würde!?
ALLES, was über 235 und unter 16 liegt, ist erstmal weg.
Antwort von wolfgang:
Janosch84 hat geschrieben:
Hallo Wolfang,
das DNxHD wird korrekt dargestellt das es wie von Premiere gefordert ja 16-235 ist.Da wird nichts gestaucht oder gestreckt.Einzig die XAVC-S wird gestaucht da diese 0-255 ist.
Möglicherweise stimmt das, möglicherweise auch nicht. Alles was du siehst ist dass sich XAVCS relativ zu DNxHD anders verhält.
Was da nun richtig ist läßt sich zuverlässiger mit normierten Testbildern bewerten.
Antwort von wolfgang:
Einen letzten Gefallen kann ich dir noch tun: anbei findest du sowohl in ProRes wie auch DNxHR - aufgenommen mit dem Shogun in UHD-Auflösung - Testbilder, die mit dem Testbildgenerator der FS7 generiert worden sind, über über HDMI mit dem Shogun aufgenommen worden sind.
Beschreibung findest du in den Snapshoots - wie die in Vegas Pro 14 wie auch in Edius bei mir aussehen (dort ist Aussehen und Bezeichnung der Files zuordenbar).
Diese Dateien kannst du in deine Applikation importieren, und so über den Waveform-Monitor einen objektiven Vergleich durchführen.
