Also an den Anzeigen des Shogun selbst - Waveform Monitor - sind die Lumaranges korrekt. Ebenso in der Dekodierung in Edius wie - hier gezeigt - auch in Premiere.WoWu hat geschrieben:Nein, da patzt Shogun, denn eigentlich müsste das YCbCr erst korrekt in ein RGB Signal überführt werden und dann in 0-255 gespeichert und signalisiert werden.
Das würde nur den ProRes ausschliessen, weil der nunmal kein RGB macht.
Shogun hätte entweder den Codec so benutzen müssen, wie er nunmal ist, oder einen andern Codec nehmen müssen.
Der Codec kann da nix zu denn die Implementierungsvorschriften sind da eindeutig.
0% = 16WoWu hat geschrieben:Versteh' ich nicht.
Du stehst in der TL auf 16-255 und dein WF zeigt dir 0-255 (???)
Und wie bekommt man das raus?WoWu hat geschrieben: Dazu müsste man aber auch mal endlich eindeutig herausbekommen, welches Signal die GH4 eigentlich an den Ausgang legt, ob es dasselbe ist, das sie Aufzeichnet oder es anders gewonnen wird und ob es sich um 254 individuelle Werte handelt und ob es in RGB oder YCbCr anliegt.
Wenn man der Flag glaubt, sind es nämlich nur 219 Werte.
wie immer, der punkt, wo es hakt. ;-)WoWu hat geschrieben:...solange an der Signalaufbereitung noch derart viele Ungereimtheiten existieren...
Ich vermute mal, dass die (Panasonic) etwas anderes vorhaben, als du erwartest. Die wollen einfach diesen Wertebereich (unterhalb 16 und oberhalb 235) mit nutzen. Damit können sie mehr Werte übergeben.WoWu hat geschrieben:Die offene Frage bleibt, warum sie dann einen Codec, der 709 geflaggt ist, mit 255 füllen.
Jam das glaube ich auch, denn ich erwarte, dass sie da Signale, icl.Flags zur Verfügung stellen, die angeschlossene Geräte auch verstehen. Dafür gibt es solche Flags nämlich.Ich vermute mal, dass die (Panasonic) etwas anderes vorhaben, als du erwartest.
Die Wertebereiche unterhalb von 16 und oberhalb von 235 sind für xvYCC inclusive des entsprechenden Flags vorgesehen.Die wollen einfach diesen Wertebereich (unterhalb 16 und oberhalb 235) mit nutzen. Damit können sie mehr Werte übergeben.
Wieso ist das irrelevant, wenn das nicht funktioniert ?Und das da ein FullFrameFlag gesetzt wird oder nicht, möglicherweise hilft das beim Monitoring oder dem einen oder anderen NLE, ist aber irrelevant.
Code: Alles auswählen
denn ein Flag für 16-255 gibt es ja sowieso nicht
... war die Antwort.Da die Einstellung im Aufnahmemenü des Videobereichs ausgewählt werden kann, gehen wir davon aus, dass es sich um eine Aufnahmefeature handelt:
Mail-Anhang.gif
Für weitere Fragen stehen wir gern zur Verfügung.
Es mag sein dass dies falsch ist. Aber auch wenn es falsch ist - dann nützt dies dem Anwender unmittelbar leider wenig, weil er kann einen etwaigen Fehler nicht beheben.WoWu hat geschrieben:Ich kann mich nur daran orientieren, was der R&S Analyser mir zu den eingefütterten Files sagt und kann wenig dazu beitragen, was andere Systeme daraus machen.
Eins steht nur fest ... 255 und ProRes mit einer Signalisierung von 709 ist falsch.
das wäre aber mehr als nur peinlich......Witziger weise, wenn ich mit dem Media Encoder umwandel...hab ich das selbe Problem.
Ich habe dafür TMPGenc 5 und jetzt auch TMPGenc 6 genutzt.-paleface- hat geschrieben:mit was konvertierst du denn in Cineform?
eine leichte Helligkeitsveränderung sehe ich allerdings,ist aber nicht weiter tragisch.da kommt es zu keinen Lumaveränderungen oder Farbveränderungen.
Ich weiß nicht was die Ahnung sein soll.dienstag_01 hat geschrieben:Allerdings ahnen wir, was passiert, wenn man ein standardkonformes Videofile (16-235) von ProRes in Cineform umwandelt ;)