slashCAM Forum

Hallo Forum,

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.
Ich habe die Clips in Premiere Pro importiert um zu sehen wie die Levels dort angezeigt werden.Das ganze sieht so aus.
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.
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

Ich würde mal sagen, Full Range in Davinci ist Data Level ;)

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

Janosch84 hat geschrieben: ↑Mi 05 Jul, 2017 12:23 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.

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

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 ;)

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%.

Janosch84 hat geschrieben: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 ;)

"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.

Janosch84 hat geschrieben: ↑Mi 05 Jul, 2017 14:31 "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.

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?

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 ;)

Ja stimmt ;-)

Aber was passiert da jetzt mit den Waveforms?Niemand bereit mir das zu erklären?

Ich bin leider gerade unterwegs, aber schau dir mal sie Skalen von Davinci und Premiere an, die haben unterschiedliche Bedeutungen.

Janosch84 hat geschrieben: ↑Mi 05 Jul, 2017 15:30 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?

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

Janosch84 hat geschrieben: ↑Mi 05 Jul, 2017 15:30 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.

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

Moin Jan,
das klappt bestimmt.
Ansonsten Mail genügt, ... das kriegen wir schon gebacken.

Janosch84 hat geschrieben: ↑Mi 05 Jul, 2017 22:44 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.

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.

dienstag_01 hat geschrieben: ↑Fr 07 Jul, 2017 10:44 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.

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.

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

WoWu hat geschrieben: ↑Fr 07 Jul, 2017 15:38 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.

"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

WoWu hat geschrieben: ↑Fr 07 Jul, 2017 15:38 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. :(

Janosch84 hat geschrieben: ↑Fr 07 Jul, 2017 15:53 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.

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

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.

Janosch84 hat geschrieben: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.

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

Na, dann belichte es doch mal richtig über, dann siehst du, wo das hingeht ;)

@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.