Danke!
Die gute Nachricht ist, der HQX Export klappt bei 10 Bit Farbtiefe.
Die schlechte ist, der Workflow V210 -> HQX produziert in VEGAS einen ordentlichen Colorshift.
Wenn du meine HQX Files zusammen mit deinem und dem V210 File in eine Timeline legst, wo kommt es zu Colorshifts?
Innerhalb von Vegas Pro ist da kein Colorshift bei der HQX-Version. Unkomprimiert und HQX sehen in Vorschau, auf dem Vektorscope und in der RGB-Parade aus wie eineiige Zwillinge. Da ist in der Farbdarstellung wirklich zero Differenz.
Aber mal anders gefragt: Wie könnte ich jetzt in Vegas Pro prüfen, ob das auch als 10 Bit decodiert wird?
Ich habe in Photoshop die im Clip abgebildete Grafik erstellt und in After Effects importiert,
da Verläufe im QuickTitler, wie im Grunde alle Titel leider nur 8Bit Farbtiefe liefern.
Edius kann leider auch nur einige wenige Grafikformate bei hoher Farbtiefe lesen, PSD
und TIFF gehören leider nicht dazu. In AE habe ich daraus eine Komposition erstellt und
diese als V210 Clip exportiert, welcher mir als Basis diente.
(https://drive.google.com/folderview?id= ... sp=sharing)
Den V210 Clip habe ich in Edius in eine 10 Bit Timeline gelegt und aus dieser folgende Exporte erstellt:
- HQ AVI (als 8Bit Vergleich)
- HQX AVI
- HQ QuickTime (als 8Bit Vergleich)
- HQX QuickTime
Nun wurden alle erstellten Clips wieder in die Timeline gelegt und mit dem Orignal verglichen.
Um die Bandbreite der Farbabstufungen auszureizen habe ich den Chromawert (Edius Effekt: Farbabgleich)
auf Maximum erhöht und die YUV-Kurve stark manipuliert, damit der Wertebereich auseinander gerissen
und starkes Banding provoziert wird.
(Für Edius User habe ich das Filterset in den Google Drive Ordner zum Download gelegt, in welchem auch der
Sourceclip liegt)
Resultate
Quelle (V210 Clip, KEINE Filter angewendet)
HQ (8 Bit, via Edius, Filter angewendet)
HQX (10 Bit, via Edius, Filter angewendet)
HQX (10 Bit, via VEGAS, Export von Marco, Filter in Edius angewendet)
Summasummarum bleibt festzustellen, dass 10 Bit Workflow mit HQX AVI Export in VEGAS prinzipiell funktioniert,
es wäre nur noch interessant, zu wissen, wie es zu dem Colorshift (eigentlich Luma-Stauchung) kommt.
Ich tippe darauf, dass der Clip mit RGB-Werten ausgegeben wurde?
10 Bit Decoding Test in VEGAS:
Zum Testen der Decoding-Fähigkeit lohnt sich der Download des HQX-Clips aus diesem Post: https://www.slashcam.de/forum/viewtopic.php?p=767288#767288
Danach in die VEGAS Timeline legen und nach HQX erneut exportieren.
Jim
Zuletzt geändert von Jim_pansen am Mi 14 Jan, 2015 21:51, insgesamt 2-mal geändert.
Das Prozessing in Vegas Pro ist immer RGB-basierend.
Aber wie gesagt: In Vegas Pro ist da kein Farbshift. Ich sehe auch in Edius keinen, sondern dort nur die Stauchung des Luma und damit verbunden eine entsprechende Entsättigung, aber keinen Shift. Die Farbwinkel bleiben identisch.
Marco hat geschrieben:Das Prozessing in Vegas Pro ist immer RGB-basierend.
Aber wie gesagt: In Vegas Pro ist da kein Farbshift. Ich sehe auch in Edius keinen, sondern dort nur die Stauchung des Luma und damit verbunden eine entsprechende Entsättigung, aber keinen Shift. Die Farbwinkel bleiben identisch.
Ja, du hast Recht, ich meinte die Luma-Stauchung.
Ein Schnellschuss von mir.
Die RGB Wandlung ist ja im Grunde erst einmal kein Problem, wenn die richtigen Farbprofile genutzt werden,
so wie das auch in After Effects möglich ist. Ärgerlich ist aber, dass in Edius der Farbraum des Quellclips bei HQX
nicht mehr vorgewählt werden kann, so wie das früher der Fall war. Offenbar wird dem HQX Codec in Edius allein
die YUV Farbcodierung zugestanden.
....und ja, die 10 Bit sehe ich am provozierten, aber nicht oder nur schwach vorhandenem Banding!
Ist zwar ein improvisiertes Verfahren, aber es funktioniert.
Also ich habe das auch durchanalysiert, und danke für den schönen Ansatz Jim.
Zusätzlich habe ich die Datein auch aus Vegas heraus einmal über QT und einmal über VfW exportiert. Und zwar für alle 3 Datein, sodass ich schlußendlich 6 Files habe. DAS war eine zusätzlich gute Übung. Denn es zeigt sich völlig eindeutig, dass
a) der QT Export aus Vegas heraus sehr wohl nur 8bit liefert, das Banding ist dort enorm
b) schon im QT Testfile mehr Banding vorhanden ist als im avi export
c) der Luminanzumfang vom HQX(QT) in Vegas schon gespreizet ist, verglichen mit den avi Exporten (ist in Edius nicht der Fall)
d) der Export aus Vegas heraus als avi sehr wohl als 10bit funktioniert.
Also können wir den Canopus HQX als VfW (avi) Export sehr wohl als Intermediate auch in Edius verwenden. Gut so.
Danke für diesen tollen Testansatz - den finde ich wirklich gelungen!
Lieben Gruß,
Wolfgang
Zuletzt geändert von wolfgang am Mi 14 Jan, 2015 22:01, insgesamt 1-mal geändert.
-> Hier ist der neue Output aus Vegas Pro. Im Vegas-Projekt lag die AVI-Version von HQX und exportiert wurde mit gleichen Eigenschaften wie eben.
In Vegas Pro werde ich dieses Testverfahren nicht verwenden können. Denn aufgrund des 4:4:4-Floatpointprozessings wird vermutlich auch bei den extremsten Spreizungen, die erst innerhalb des NLE angelegt werden, kein Banding entstehen. Gut für die Postpro, schlecht für Tests wie diesem.
Marco hat geschrieben:-> In Vegas Pro werde ich dieses Testverfahren nicht verwenden können. Denn aufgrund des 4:4:4-Floatpointprozessings wird vermutlich auch bei den extremsten Spreizungen, die erst innerhalb des NLE angelegt werden, kein Banding entstehen. Gut für die Postpro, schlecht für Tests wie diesem.
Ein Banding kann man immer provozieren, wenn man den Wertebereich auseinander zerrt!
Die Abstufungen werden dabei zwangsläufig größer, was auch in 4:4:4 Floatingpoint Projekten
zu sehen ist. Das hat darauf gar keinen Einfluss. Du benötigst nur eine 10 Bit Quelle, welch du dir
auch Vegas erstellen kannst (V210).
Danke, für mich war der Test auch sehr hilfreich.
Ich traue dem AVI Codec potenziell nun doch wieder einiges mehr zu.
In diesem Sinne bin ich froh, dass ich mich bei DirectShow geirrt habe.
Video for Windows bleibt aber 8 Bit.
Erstaunlich ist, dass wider meinen Erwartungen der QuickTime Support so derart rudimentär ist!
Jim
Zuletzt geändert von Jim_pansen am Mi 14 Jan, 2015 23:03, insgesamt 1-mal geändert.
Ich habe gerade mal mit dem 210er Testfile auch noch eine Proberenderung zum HQX superfein
a) aus Edius heraus 10bit Projekt
b) aus TMPGenc heraus
gemacht.
Und das mit dem Original aber auch mit dem Renderergebnis aus Vegas heraus verglichen (32bit floating point Projekt).
Also 2 Befunde:
1. Aus dem 10bit aus Edius heraus entsteht doch etwas mehr Banding - nicht stark. Aber was zu erwarten war, da Edius ja ein 10bit integer Projekt nutzt. Das hat den Vorteil einer guten Vorschauperformance, die ist in Veags mit dem 32bit floating Point doch mehr Rechenleistung auch für die Vorschau benötigt.
2. Aus TMPGenc schaut die Sache wie aus Edius heraus gerendert aus. Sprich - das Ergebis ist hier ebenfalls ein echtes 10bit HQX file, analog zu Edius aber offenbar als integer gerechnet. Damit hat man auch hier eine Spur mehr Banding als beim Original, aber auch hier ist das nicht weltbewegend.
Fazit: auch über TMPGenc ist offenbar ein 10bit workflow möglch, bei dem wir die 10 ProRes Files in TMPGenc zu 10bit HQX rendern. Und das dann in Vegas weiter verarbeiten. Beim Rendern aus Vegas zu einer weiteren HQX-Ausgabe muss man das aber nicht über QT, sondern über Video for Windows machen.
Für eine noch höhere Qualität müßte man die erste Generation der HQX Files nicht in TMPGenc, sondern über Batchrendern aus Vegas heraus erstellen.
Marco hat geschrieben:Ein Banding in einem Vegas-Floatpoint-Projekt ist nur dann sichtbar, wenn ein Signal, das schon im Original Banding enthält, dort ohne jede Manipulation dargestellt wird.
Das Spreizen des Wertebereiches einer 8 Bit Quelle führt auch in Vegas zu einem ähnlichen Banding.
Sorry, ich hatte mein Posting, auf das sich deine Antwort bezieht, schnell wieder gelöscht, nachdem ich fünf Sekunden nach einem kleinen Test selbst sah, wie unsinnig meine Aussage war.
Marco hat geschrieben:Sorry, ich hatte mein Posting, auf das sich deine Antwort bezieht, schnell wieder gelöscht, nachdem ich fünf Sekunden nach einem kleinen Test selbst sah, wie unsinnig meine Aussage war.
Macht ja nix! Gut, dass du's nochmal getestet hast.
wolfgang hat geschrieben:Also 2 Befunde:
1. Aus dem 10bit aus Edius heraus entsteht doch etwas mehr Banding - nicht stark. Aber was zu erwarten war, da Edius ja ein 10bit integer Projekt nutzt.
Wolfgang,
ich will ja eigentlich nicht kleinlich sein, aber was meinst du mit Integer Projekt?
Edius rechnet in 10 Bit Projekten mit Nachkommastellen und sampled eben nicht auf volle Integerwerte, trotz YUV.
In Edius mangelt es eigentlich nur an 4:4:4 Prozessing und die interne hohe 32 Bit Auflösung von Vegas macht
einfach prinzipiell mehr Möglichkeiten für den Feinschliff und für die Kaskade über einander liegender Effekte auf. ;)
Der Wertebereich, auf den sich das Prozessing bezieht, ist 10 Bit integer. 1024 Werte. Fix.
Der Wertebereich, auf den sich das Prozessing in Vegas bezieht, sofern es kein 8-Bit-Projekt ist, ist Floatpoint-basierend. Es gibt keinen fixen Wertebereich. Es sind nicht 2 hoch 32. Es gibt daher in einem solchen Projekt in der Praxis keine Grenzen für Über- und Unterbelichtungen (die Grenzen sind so extrem hoch, dass sie selbst bei extremer Postpro nicht ausgereizt werden).
Marco hat geschrieben:Der Wertebereich, auf den sich das Prozessing bezieht, ist 10 Bit integer. 1024 Werte. Fix.
Der Wertebereich, auf den sich das Prozessing in Vegas bezieht, sofern es kein 8-Bit-Projekt ist, ist Floatpoint-basierend. Es gibt keinen fixen Wertebereich. Es sind nicht 2 hoch 32. Es gibt daher in einem solchen Projekt in der Praxis keine Grenzen für Über- und Unterbelichtungen (die Grenzen sind so extrem hoch, dass sie selbst bei extremer Postpro nicht ausgereizt werden).
Dann besagt "32 Bit" lediglich, dass theoretisch ein 32 Bit Wertebereich via API übergegeben werden könnte,
intern aber mit unbegrenzter Genauigkeit gerechnet wird? Arbeiten denn auch die internen Effekte mit dieser Präzision?
Einen 32 Bit Wertebereich verstehe ich ja letztlich auch als eine fixe Anzahl möglicher Werte.
Mit YUV oder RGB hat das weniger zu tun.
Das stimmt, ich hatte gedanklich nur eine Diskussion vor Augen, die wir mal im Edius-Forum hatten,
da ging es um den Vergleich 10 Bit YUV mit 10 Bit RGB. Der Knackpunkt war, dass vermeintlich der 10 Bit YUV Codec einen kleineren Wertebereich hätte.
Also erstmal wieder zurück zu deinem Testverfahren. Ich habe nun in ein Floatpoint-Vegas-Projekt gelegt:
- Die unkomprimierte 10-Bit-Referenz.
- Das aus Vegas Pro exportierte HQX-File.
- Ein aus Vegas Pro exportiertes unkomprimiertes 8-Bit-File.
Dann per Tonwertkorrektur Schwarz und Weiß solange aufgesprengt, bis auch im unkomprimierten 10-Bit im Histogramm das erste deutliche Banding sichtbar wurde.
Dann explodiert im HQX das Banding schon förmlich. Es ist nicht identisch, aber sehr ähnlich der unkomprimierten 8-Bit-Version.
Daraus folgere ich, dass HQX in Vegas Pro nicht in 10 Bit decodiert werden kann. Wobei ich es etwas seltsam finde, dass es dennoch als 10 Bit exportiert werden kann.
Zum Floatpoint:
Die interne Genauigkeit ist nicht unbegrenzt, sondern liegt im Rahmen dessen, was eine Gleitkommaberechnung hergibt. Die äußeren Grenzen des Wertebereiches liegen eben bei ungefähr 10^-38 bis 10^38, während Schwarz auf 0 und Weiß auf 1 festgelegt ist. Da bleibt also eine unglaubliche Reserve für Werte tiefer als Schwarz und höher als Weiß.
Die 32 Bit sagen hier erstmal gar nichts über den Wertebereich, sondern das ist hier ja nur die Eigenschaft der Gleitkommaberechnung. Mit 32 integren Werten hat das nichts zu tun.
Wenn nun der verfügbare Wertebereich mit dem eines integren Prozessings verglichen werden soll, muss der Bereich des Floatpoint-Prozessings als Wertebereich herangezogen werden, der zwischen 0 und 1 darstellbar ist. Wie weit dieser Bereich in integren Werten ausgedrückt ist, kann ich nicht genau sagen, aber es genügt, um selbst 24-Bit-Integer präzise abzubilden.
Nachtrag:
Ich habe gerade oben beschriebenes Testkonstrukt wiederholt, nur die Spreizung ein wenig moderater gemacht, so dass im unkomprimiertem 10-Bit-AVI gerade noch kein Banding auftaucht. Dann ist die HQX-Varianten in R', G' und B' aber schon zerrissen wie ein Kamm und sogar die unkomprimierte 8-Bit-Version ist längst nicht so aufgerissen.
Zuletzt geändert von Marco am Do 15 Jan, 2015 00:15, insgesamt 1-mal geändert.
Marco hat geschrieben:Also erstmal wieder zurück zu deinem Testverfahren. Ich habe nun in ein Floatpoint-Vegas-Projekt gelegt:
- Die unkomprimierte 10-Bit-Referenz.
- Das aus Vegas Pro exportierte HQX-File.
- Ein aus Vegas Pro exportiertes unkomprimiertes 8-Bit-File.
Dann per Tonwertkorrektur Schwarz und Weiß solange aufgesprengt, bis auch im unkomprimierten 10-Bit im Histogramm das erste deutliche Banding sichtbar wurde.
Dann explodiert im HQX das Banding schon förmlich. Es ist nicht identisch, aber sehr ähnlich der unkomprimierten 8-Bit-Version.
Daraus folgere ich, dass HQX in Vegas Pro nicht in 10 Bit decodiert werden kann. Wobei ich es etwas seltsam finde, dass es dennoch als 10 Bit exportiert werden kann.
Zum Floatpoint:
Die interne Genauigkeit ist nicht unbegrenzt, sondern liegt im Rahmen dessen, was eine Gleitkommaberechnung hergibt. Die äußeren Grenzen des Wertebereiches liegen eben bei 10^-38 bis 10^38, während Schwarz auf 0 und Weiß auf 1 festgelegt ist. Da bleibt also eine unglaubliche Reserve für Werte tiefer als Schwarz und höher als Weiß.
Die 32 Bit sagen hier erstmal gar nichts über den Wertebereich, sondern das ist hier ja nur die Eigenschaft der Gleitkommaberechnung. Mit 32 integren Werten hat das nichts zu tun.
Wenn nun der verfügbare Wertebereich mit dem eines integren Prozessings verglichen werden soll, muss der Bereich des Floatpoint-Prozessings als Wertebereich herangezogen werden, der zwischen 0 und 1 darstellbar ist. Wie weit dieser Bereich in integren Werten ausgedrückt ist, kann ich nicht genau sagen, aber es genügt, um selbst 24-Bit-Integer präzise abzubilden.
Wenn 32 Bit, dann bleiben doch aber auch nur maximal 2^32 darstellbare Werte. Mehr sind doch dann in einem 32 Bit Register überhaupt nicht darstellbar?
Meiner Meinung nach ist es doch egal, ob man Schwarz = "0" und Weiß = "1" annimmt und dazwischen alle möglichen Nachkommawerte zulässt oder
(weil in YUV Werten nicht anders darstellbar) zwischen 16 und 235 alle möglichen Werte mit Nachkommastelle möglich sind.
Ich vermute, dass ich da etwas nicht ganz verstehe.
Bezüglich deines Testes nochmal:
Die Datei, die du als letzte verlinkt hattest war nur ein HQ File. War das so gedacht?
Wenn du ungewollt HQ anstelle HQX exportiert hast und die HQ-Datei als Grundlage
beim Dekodieren benutzt hast, würde das die 8 Bit beim Dekodieren und das Banding erklären.
Zum Test hatte ich die hier zuerst verlinkte HQX-Datei verwendet. Die, die du quasi auch »positiv« auf 10 Bit getestet hattest.
Vielleicht macht es nochmal einen Unterschied, ob ich ein 10-Bit-HQX verwende, das aus Vegas Pro exportiert wurde oder eines, das beispielsweise aus Edius kommt. Denn auch MediaInfo interpretiert ja das HQX von Vegas Pro falsch.
Marco hat geschrieben:Zum Test hatte ich die hier zuerst verlinkte HQX-Datei verwendet. Die, die du quasi auch »positiv« auf 10 Bit getestet hattest.
Vielleicht macht es nochmal einen Unterschied, ob ich ein 10-Bit-HQX verwende, das aus Vegas Pro exportiert wurde oder eines, das beispielsweise aus Edius kommt. Denn auch MediaInfo interpretiert ja das HQX von Vegas Pro falsch.
Aber ich gehe das zur Sicherheit nochmal neu an.
Bin gespannt, was dabei heraus kommt.
Es wäre doch reichlich inkonsequent, wenn das Decoding nicht mit 10 Bit funktionieren würde.
Marco hat geschrieben:Der Wertebereich, auf den sich das Prozessing in Vegas bezieht, sofern es kein 8-Bit-Projekt ist, ist Floatpoint-basierend. Es gibt keinen fixen Wertebereich. Es sind nicht 2 hoch 32. Es gibt daher in einem solchen Projekt in der Praxis keine Grenzen für Über- und Unterbelichtungen (die Grenzen sind so extrem hoch, dass sie selbst bei extremer Postpro nicht ausgereizt werden).
ich fürchte, dass was du da über über die vorzüge der fließkomma-darstellung erzählst, wird der wahrheit nicht wirklich gerecht. du kannst zwar mit den entsprechenden daten-typen einen relativ großen wertebereich darstellen, aber nur mit begrenzter genauigkeit. so gesehen zählt letztlich dann doch wieder nur die anzahl der genutzen bits. aber, lass ma das lieber.
was aber im konkreten fall eine wichtigere rolle spielen dürfte, ist die frage, wie die jeweiligen programme mit geringer aufgelösten daten umgehen?
es zeigt sich nämlich in der praxis immer wieder, dass die hier beschriebene methode zu anderen resultaten führt, wenn man 8-bit files importiert als wenn man 10-bit formate benutzt, aber die daten darin in wahrheit auch nur 8-bit nutzen -- also genau den selben inhalt besitzen. dass sich die ergebnisse trotzdem unterscheiden, hat mit entsprechender optimierung bzw. genauigkeit der berechnungen zu tun.
für den test hier spielt das keine so große rolle, weil man ohnehin nur die betreffenden störungen sehen will. wenn man dagegen diese einflüsse ausklammern will, während man sein 8-bit material grenzwertig malträtiert, kann es sehr wohl sinn machen, explizit eine höhere berechnungsgenauigkeit bzw. interne darstellung zu nutzen.
Neuer Test: Dieselbe V210-Datei als Referenz. Einmal in Edius als 10-Bit-HQX gerendert, einmal in Vegas Pro.
Referenz, Edius- und Vegas-Version in Vegas Pro miteinander verglichen. Ähnliches Banding bei beiden HQX-Dateien, wo in der Referenz noch kein Banding auftaucht.
Das Banding lässt sich dort schon dann nachweisen, wenn nur der Wertebereich von Studio-Swing auf Full-Swing gespreizt wird. Eben so, wie man es von 8 Bit kennt.
Marco hat geschrieben:Neuer Test: Dieselbe V210-Datei als Referenz. Einmal in Edius als 10-Bit-HQX gerendert, einmal in Vegas Pro.
Referenz, Edius- und Vegas-Version in Vegas Pro miteinander verglichen. Ähnliches Banding bei beiden HQX-Dateien, wo in der Referenz noch kein Banding auftaucht.
Das Banding lässt sich dort schon dann nachweisen, wenn nur der Wertebereich von Studio-Swing auf Full-Swing gespreizt wird. Eben so, wie man es von 8 Bit kennt.
Ich sehe die besonderen Vorzüge von Floatpoint ja gar nicht in dem Bereich zwischen 0 und 1, der aber letztlich (in Bezug auf diese Diskussion hier) mit dem Wertebereich von 0 bis 1024 für 10 Bit Integer verglichen werden müsste. Es ist bestenfalls wichtig zu wissen, dass dieser Wertebereich zwischen 0 und 1 groß und präzise genug ist, um auch 10 Bit Integer (und mehr) damit korrekt als Videosignal abzubilden. Die Rundungsfehler, die sich dabei ergeben, sind für eine spätere Abbildung auf 10 Bit (das ist unser Thema hier) vernachlässigbar. Daraus lassen sich die hier besprochenen Effekte nicht erklären.
Es gäbe zu Floatpoint noch ein paar andere, je nach Betrachtungsweise, negative Aspekte, die aber alle komplett am Thema vorbeigehen.
Ich sehe, wie oben geschrieben, den besonderen Vorzug in dem Bereich unter 0 und über 1, der aber für diese Diskussion in der Tat überhaupt keine Rolle spielt, dennoch aufzeigt, dass es gravierende Unterschiede zwischen dem Videoprozessing mit integrer Abbildung des Wertebereiches und Floatpoint-Prozessing gibt.
HQX als 10 Bit funktioniert wohl nicht in Vegas Pro.
CineForm funktioniert, fürs Encoding muss aber erst eine Lizenz her.
V210 (Sony YUV 10 Bit) funktioniert, erzeugt aber riesige Dateien.
Panasonic P2 funktioniert, erzeugt aber für jeden Rendervorgang eine eigene Ordnerstruktur, so dass die Clipverwaltung später unsinnig komplex wäre.
Dann bleiben nur noch:
XAVC
HDCAM SR
Qualitativ ist HDCAM SR vermutlich die bessere Wahl. Es rendert auch schneller und ich würde bei großen, komplexen Projekten weniger Probleme bezüglich der Stabilität erwarten. Die Dateigröße ist aber etwa viermal so groß wie ein vergleichbares XAVC (für HDCAM SR ca 1 GB pro 30 Sekunden, ca. 360 Mbit/s).
Alle Infos hier in Bezug darauf, dass auch von Vegas aus das Rendern zum Intermediate geschehen würde, da es schwierig sein wird, einen externen Batchkonverter für HDCAM SR zu finden. Extern bliebe für 10 Bit wohl nur noch XAVC übrig.
Wenn sich davon nichts für das Projekt eignen sollte, bleibt nur der Rückzug zu 8 Bit (und dann würde ich XDCAM HD 422 nehmen) oder der Umzug auf ein anderes System.
Ich kenne HDCAM SR ausschließlich als digitales Bandformat.
So wie du es aufzählst, könnte man meinen, es würde sich um einen Codec handeln.
Gibt es denn tatsächlich ein Exportformat dieses Namens in SONY Vegas?
Sorry für meine Unwissenheit, aber Vegas habe ich mir nie zu Gemüte gezogen.
Ja, in Vegas Pro kann »Sony HDCAM SR« im MXF-Container in verschiedenen Varianten mit 4:2:2- oder 4:4:4-Sampling exportiert oder nativ verarbeitet werden.
Auch die Sony Raw-Viewer bieten HDCAM SR als Exportformat.
Da fällt mir gerade noch ein, dass die Variante »HDCAM SR Lite 422« hier unter Umständen besonders interessant sein könnte. Ich glaube, da ist die Datenrate gegenüber der normalen 422-Version etwa halbiert.
Zuletzt geändert von Marco am Do 15 Jan, 2015 02:20, insgesamt 1-mal geändert.
Marco hat geschrieben:Ja, in Vegas Pro kann »Sony HDCAM SR« im MXF-Container in verschiedenen Varianten mit 4:2:2- oder 4:4:4-Sampling exportiert oder nativ verarbeitet werden.
Danke für die Erklärung.
Soweit ich mich recht erinnere wurde für's Band ein MP4-Derivat verwendet,
der Codec wird sich wohl sicher daran orientieren.
Würde mich interessieren, von welchen Anwendungen der überhaupt gelesen werden kann.
Marco hat geschrieben:Ich sehe, wie oben geschrieben, den besonderen Vorzug in dem Bereich unter 0 und über 1, der aber für diese Diskussion in der Tat überhaupt keine Rolle spielt, dennoch aufzeigt, dass es gravierende Unterschiede zwischen dem Videoprozessing mit integrer Abbildung des Wertebereiches und Floatpoint-Prozessing gibt.
ich würde sagen, dass die digitale datenverarbeitung immer wieder zeigt, dass man im grunde nicht nur auf dieses "unter 0 und über 1" getrost verzichten kann, sondern sogar auch auf alles zwischen 0 und 1. ;)
manche dinge sehe ich offenbar doch ein bisserl anders als du.
HQX als 10 Bit funktioniert wohl nicht in Vegas Pro.
CineForm funktioniert, fürs Encoding muss aber erst eine Lizenz her.
V210 (Sony YUV 10 Bit) funktioniert, erzeugt aber riesige Dateien.
Panasonic P2 funktioniert, erzeugt aber für jeden Rendervorgang eine eigene Ordnerstruktur, so dass die Clipverwaltung später unsinnig komplex wäre.
Dann bleiben nur noch:
XAVC
HDCAM SR
Qualitativ ist HDCAM SR vermutlich die bessere Wahl. Es rendert auch schneller und ich würde bei großen, komplexen Projekten weniger Probleme bezüglich der Stabilität erwarten. Die Dateigröße ist aber etwa viermal so groß wie ein vergleichbares XAVC (für HDCAM SR ca 1 GB pro 30 Sekunden, ca. 360 Mbit/s).
Alle Infos hier in Bezug darauf, dass auch von Vegas aus das Rendern zum Intermediate geschehen würde, da es schwierig sein wird, einen externen Batchkonverter für HDCAM SR zu finden. Extern bliebe für 10 Bit wohl nur noch XAVC übrig.
Wenn sich davon nichts für das Projekt eignen sollte, bleibt nur der Rückzug zu 8 Bit (und dann würde ich XDCAM HD 422 nehmen) oder der Umzug auf ein anderes System.
Herzlichen Dank an alle Beteiligten hier!!
Ich werde mal die Möglichkeiten durchtesten, auch Cineform, das GoPro Studio verspricht mir in der gratis Version immerhin
"GoPro CineForm Codec bietet bis zu 1080p mit kräftigen Farben bei Benutzung einer Drittanbieter-Software"
hehe, genau das will ich ja ;-)
P.S. Was die Datenmenge bei HDCAM SR betrifft, bei meinen ProRes aus den BM's komme ich bei 142 Sek auf 3,08 GB, wenn da dann noch ein Viertel mehr an Datenmenge dazu kommt, kann ich damit leben, so es funktioniert und ich nicht mitten im Projekt emigrieren muß.
Für die Zukunft werd ich dann wohl Vegas verlassen...
Jim_pansen hat geschrieben:
Wolfgang,
ich will ja eigentlich nicht kleinlich sein, aber was meinst du mit Integer Projekt?
Jim,
ich war gestern nicht mehr da, aber Marco hat das ohnedies perfekt erklärt. Es ist einfach der Unterschied zwischen Gleitkommaberechnung und Ganzahl-berechnung.
Und Edius hat eben eine 10bit Integer-Berechnung aber leider nicht die präzisere Gleitkommaberechnung (32bit floating point) wie sie etwa Vegas oder auch After Effects haben.
In der Praxis ist es tatsächlich so wie ich oben sagte: die Gleitkommaberechnung aus Vegas oder auch AE heraus liefert für deine sehr gut gemachten Testbalken praktisch absolut bandingfreie Ergebnisse, ausgehend vom YUV-Bild. Die 10bit integer Berechnung liefert tatsächlich auch mit deinem Testbild ein ganz zartes Banding.
So nebenbei kann man also deine sehr guten Testbilder sogar dafür nutzen, um sich endlich mal die Unterschiede zwischen 32bit floating point und 10bit integer Berechnung anzusehen. Um zu sehen was TMPGenc hier macht habe ich genau diesen Umstand angewendet - und zusätzlich dein YUV-estbild auch noch aus Edius und auch aus TMPGenc heraus zum HQX codec gerechnet. Und die Ergebnisse sind eben so, dass Edius und TMPGenc hier die gleiche Qualität (sprich ganz zartes banding) liefert - und die 32bit floating point Methode noch einen Tick besser ist.
Dass Edius heute "nur" den 10bit Modus hat könnte man als einen Nachteil empfinden. Mag es auch sein wenn man auf das letzte i-Tüpfelchen Qualität Wert legt. Der große Vorteil dieses Modus ist aber seine Geschwindigkeit - denn 32bit floating point benötigt halt enorm viel Rechenleistung und ist damit in der Vorschau viel langsamer, und ich der Berechnung ebenso. Edius hat halt nur den einen, Vegas nur den anderen Modus. Toll wäre es, wenn wir beide Modi in all unseren NLEs hätten. :)
also die Schlussfolgerungen finde ich interessant, aber sie wiedersprechen auch den ersten Befunden. In den Testfiles von Jim zeigt sich viel stärkeres Banding wenn man den HQX Export seiner Files als HQX-Quicktime aus Vegas heraus macht. Das habe ich mal als 8bit interpretiert.
Aber ich habe den Export seiner Testdatein sowohl aus Vegsa wie auch aus Edius gemacht - und Vegas zeigt dort noch etwas weniger Banding als der Export aus Edius heraus.
Wie kann das sein? Als einzigen mögliche Erklärung würde ich noch sehen dass der Canopus HQX beim Export ausVegas heraus nicht neu berechnet worden ist. Das wäre möglich.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
