slashCAM Forum

->Hier ist ein Vegas-Projekt inklusive der Testclips, in dem man es deutlich sieht.

Das Projekt muss auf »32-Bit Gleitkomma (Videolevel)« und die Vorschau auf »Optimal/Voll« eingestellt sein.

Das Histogramm muss geöffnet sein mit der Ansicht »Luminanz/R/G/B«.

In den Spuren sind gegenübergestellt die V210-Referenz, ein Edius-HQX, ein Vegas-HQX und ein 8-Bit-Signal. Die Signalspreizung ist schon fertig angelegt (also Video-Output-FX), so dass man nur noch durch die Spuren schalten und die Ansicht des Histogramms verfolgen muss.

Es scheint, dass SONY Vegas die HQX Files via VfW ausliest.
Das limitiert die Bittiefe tatsächlich auf 8 bit.

Jim

Jim_pansen hat geschrieben:Ein Smartrendering bei nicht nativ integrierten Codecs halte ich für sehr unwahrscheinlich.

Tja, aber das beobachte ich bei Canopus HQX definitiv bei meinem letzten UHD-Projekt in Vegas. Das Material liegt bei Vegas in der timeline. Teile, die nicht mit Helligkeits- oder Farbkorrekturen versehen sind, werden ohne neuerliche Kompression aus dem 32bit floating point Projekt ausgegeben (sieht man an der Bildschirmanzeige die einen diesbezüglichen Text auswirft).

Ob unwahrscheinlich ode wahrscheinlich weiß ich nicht - es ist aber so.

wolfgang hat geschrieben:

Jim_pansen hat geschrieben:Ein Smartrendering bei nicht nativ integrierten Codecs halte ich für sehr unwahrscheinlich.

Tja, aber das beobachte ich bei Canopus HQX definitiv bei meinem letzten UHD-Projekt in Vegas. Das Material liegt bei Vegas in der timeline. Teile, die nicht mit Helligkeits- oder Farbkorrekturen versehen sind, werden ohne neuerliche Kompression aus dem 32bit floating point Projekt ausgegeben (sieht man an der Bildschirmanzeige die einen diesbezüglichen Text auswirft).

Ob unwahrscheinlich ode wahrscheinlich weiß ich nicht - es ist aber so.

Nimm's mir nicht übel, aber das glaube ich nicht!
Dafür müsste der Codec nativ via SDK eingebunden sein.

Jim

Ehrlich gesagt konnte ich das zuerst auch kaum glauben, zumal ich skeptisch war, ob Smartrendern in einem Floatpoint-Projekt überhaupt möglich ist.

Aber ich habe es gerade mit HQX getestet und Wolfgang hat Recht. Man bemerkt es sowohl an der Zeit des Exports als auch an der Anzeige in der Vorschau, wo ein Smartrendern signalisiert wird.

Marco hat geschrieben:Ehrlich gesagt konnte ich das zuerst auch kaum glauben, zumal ich skeptisch war, ob Smartrendern in einem Floatpoint-Projekt überhaupt möglich ist.

Aber ich habe es gerade mit HQX getestet und Wolfgang hat Recht. Man bemerkt es sowohl an der Zeit des Exports als auch an der Anzeige in der Vorschau, wo ein Smartrendern signalisiert wird.

Ist es nicht logisch, dass an Passagen, auf denen keine Effekte liegen, der Export sehr schnell ist?
Man könnte das ja mal mit einem Differenzkey heraus bekommen, wenn man Quelle und Resultat über einander legt.

Jim

Ja, das ist schon logisch. Aber allein die absolute Exportzeit, unabhängig vom Effekteinsatz (ich habe es ohnehin ohne Effekte getestet) und die Signalisierung innerhalb der Vorschau ist eigentlich eindeutig. So schnell wie das bei mir geht, kann auf meinem Netbook Vegas Pro gar nicht exportieren, wenn eine Neuberechnung zwischengeschaltet ist. Und die Signalisierung fürs Smartrendern in Vegas Pro halte ich für völlig zuverlässig.

Marco hat geschrieben:->Hier ist ein Vegas-Projekt inklusive der Testclips, in dem man es deutlich sieht.

Zu diesem Projekt - also das ist natürlich mal hoch interessant. So wie ich das sehe nimmst du die 4 clips hast als Video Output FX levels drinnen.

Gut, und dann kann man die clips durch Hin- und Herschalten vergleichen. Was sehen wir hier - ich versuche mal eine Interpretation.

Alles aus Vegas heraus abgelesen (mit aktiviertem Filter):

1. auch der originale V210 clip - der ist ja 10bit YUV - zeigt ebenfalls bereits unter diesen Bedingungen im Vegasprojekt Banding. Vielleicht nicht sonderlich stark, aber doch.

2. auch der HQX Edius clip zeigt unter diesen Bedingungen Banding. Deutlich stärker als der V210 clip.

3. Auch der Vegas HQX-Clip aus Vegas zeigt Banding. Verglichen mit dem HQX Edius clip ist dieses Banding im Veags HQX Clip aber deutlich schwächer ausgeprägt.

4. Der 8bit YUV clip zeigt bei mir weniger Banding als der originale V210 clip. Wie ist der erstellt? Aus Vegas als 32bit floating point raus gerechnet?


Frage 1: Wieso ist zeigt der HQX Vegas clip schwächeres Banding als der HQX Edius clip? Mir ist klar dass der HQX Vegas clip als 32bit floating point raus gerechnet ist. Aber wenn der nur 8bit wäre - wie kann er dann besser sein als der aus Edius erstellt HQX clip?


Aber ok. Schauen wir uns das in Edius an - denn dort sollte wohl das 10bit Material mit 100%iger Sicherheit als 10bit interpretiert werden. Ich habe daher die 4 clips in ein Edius 10bit Projekt gelegt und beurteile auch hier wieder das banding.

Findings aus Edius heraus (nur die clips ohne Filter):

5. der 8bit YUV clip zeigt auch in Edius weniger Banding als der 10bit YUV Ausgangsclip.

6. der HQX Edius clip zeigt auch aus Edius heraus weniger banding als der HQX Vegas clip

7. der HQX Vegas clip zeigt in Edius sogar deutlich weniger banding als der 10bit YUV Ausgangsclip.

Das ist also eigentlich der gleiche Befund. Sowohl aus Edius wie auch aus Vegas heraus zeigt der HQX Vegas clip weniger Banding als das Ausgangsmaterial 10bit.

Ich frage mich nun - Frage 2: wenn der Ansatz stimmt, über Banding nachweisen zu wollen ob Canopus HQX in Vegas als 8bit oder als 10bit interpretiert wird. Wenn das stimmt, wieso zeigt dann der "HQX Vegas Clip" sowohl in Vegas wie auch in Edius weniger Banding als das Ausgangsmaterial?

Ist genau dieser Befund nicht der Beleg dafür, dass
a) natürlich 32bit floating point hier bessere Ergebnisse liefert, und
b) dass das HQX Material sehr wohl als 10bit interpretiert werden muss (sonst wäre es wohl schlechter).

Bei a) bin ich mir recht sicher dass das stimmt. Bei b) bin ich mir weniger sicher. Vielleicht liefert ja 32bit floating point selbst bei einer Interpretation als 8bit bessere Ergebnisse als der 10bit clip Edius HQX selbst?

Sorry, Wolfgang, aber da muss bei dir etwas schief gelaufen sein!
Meine Screenshots in meinem Test können deinen Befund in Edius nicht bestätigen.
Mit welcher Edius-Version arbeitest du?

Jim

Du siehst im Histogramm des V210-Clips Banding? Echte Lücken?
Und der 8-Bit-Clip zeigt bei dir weniger Lücken als die V210-Referenz?
Dein Projekt steht auf Gleitkomma Videolevel?

Bei mir ist das nicht so, siehe Screenshots: Die V210-Referenz ist die einzige Quelle, die in diesem Projekt noch ein lückenloses Histogramm zeigt.

V210-Referenz


HQX

Wenn man einen perfekten Luminanzverlauf in 10bit auf einem, sagen wir mal nicht 8bit, aber 6bit Monitor - es gibt ja etliche, die die 8bit nicht ganz schaffen - anschaut, wird man immer Banding haben. Das hat mit dem Ausgangsfile und dem NLE herzlich wenig zu tun.
Nur mal so zum Verständnis ;)

dienstag_01 hat geschrieben:Wenn man einen perfekten Luminanzverlauf in 10bit auf einem, sagen wir mal nicht 8bit, aber 6bit Monitor - es gibt ja etliche, die die 8bit nicht ganz schaffen - anschaut, wird man immer Banding haben. Das hat mit dem Ausgangsfile und dem NLE herzlich wenig zu tun.
Nur mal so zum Verständnis ;)

Ich glaube, an dieser Hürde scheitert hier keiner von uns! ;)
Wenn du aufmerksam gelesen hast, dann weißt du ja eigentlich,
dass wir Banding provoziert haben. :D

Jim

Ich habe meinen letzten Beitrag noch um ein Screenshot des HQX-Histogramms ergänzt. Ich finde, deutlicher geht es kaum.

Hüstel, ich hab ja was losgetreten! Und verstehe fast nur noch Bahnhof.

Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen und werde nun versuchen, mittels Vegasaur in Vegas meine Clips aus den jeweiligen Projekt-Dateien in die bestmögliche Qualität (Filmscan 2) zu rendern, dann sollten ja die 10bit erhalten bleiben?!

Merci!

thsbln hat geschrieben:Hüstel, ich hab ja was losgetreten! Und verstehe fast nur noch Bahnhof.

Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen und werde nun versuchen, mittels Vegasaur in Vegas meine Clips aus den jeweiligen Projekt-Dateien in die bestmögliche Qualität (Filmscan 2) zu rendern, dann sollten ja die 10bit erhalten bleiben?!

Merci!

LOL
Ich hoffe, dir ist mit dem GoPro-Cineform Codec Pack geholfen.
Wobei ich so meine Zweifel habe und der Workflow im Grunde auch mal auf
Farbtiefe, Colorshifts und Lumaspreizungen ge-checkt werden müsste. ;)

Jim

Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale.

Jim_pansen hat geschrieben:Sorry, Wolfgang, aber da muss bei dir etwas schief gelaufen sein!
Meine Screenshots in meinem Test können deinen Befund in Edius nicht bestätigen.
Mit welcher Edius-Version arbeitest du?

Mit 7.41.28

Tja ich habe nur die Files von Marcos Projektfile genommen und in Edius hinein gelegt (10bit Projekt und dort interpretiert. Gehen wir von den gleichen Files aus? Denn ich habe seine Files (mit den 2 Frames) für meine Interpretation verwendet.

Die Interpretation erfolgt übrigens auf einem 8bit Monitor - sicherlich nicht auf einem 10bit Monitor. Aber da ich beim V210 Projekt das volle Bild sehe ist das wohl kein Problem.

Marco hat geschrieben:Du siehst im Histogramm des V210-Clips Banding? Echte Lücken?
Und der 8-Bit-Clip zeigt bei dir weniger Lücken als die V210-Referenz?
Dein Projekt steht auf Gleitkomma Videolevel?

Bei mir ist das nicht so, siehe Screenshots: Die V210-Referenz ist die einzige Quelle, die in diesem Projekt noch ein lückenloses Histogramm zeigt.

Doch, das Histogramm der Files sieht genauso aus wie bei dir. Ist ja dein Projekt! Und auch dei anderen Einstellugend sind damit von dir übernommen.

Was ich hier probiert habe war die Interpretation der Vorschau auf dem Vollbildschirm. Vielleicht ist das der Grund. Ich hänge hier mal snaphoots an

also -- nur zur klarstellung, warum ich mich über die hier eingeflochtene float vs. int-debatte ein wenig lustig mache:

intern wird auch bei verwendung von integer datenrepräsentation sicher nie mit 10bit auflösung gerechnet, sondern immer mit 8, 16 od 32 bit breite.

16bit reichen aber im vorliegenden fall mit größter wahrscheinlichkeit bereits aus, um keinen unterschied zur float (32bit) bearbeitung sichbar werden zu lassen.

einige bedeutsamkeit bzw. aufmerksamkeit verdient übrigens auch die tatsache, dass es einen großen unterschied macht, ob 10bit daten einfach nur auf 8 bit gerundet bzw. abgeschnitten werden (bspw. mit einem verschieben der bits um zwei stellen nach rechts), oder aber, im wissen um die beschränkung des verwendeten ausgabe-kanals, vorsorglich sauber für 8-bit darstellung aufbereitet werden. im letzteren fall wird gewöhlich mit dithering u.ä. eine ausgabe erzeugt, die deutlich weniger banding zeugt bzw. auffallend besser wirkt als abgeschittene übergangswerte. das ist auch der grund, warum vernünftig optimiertes 8bit material oft deutlich befriedigender wirken kann als 10bit quellen, die auf billigen 8bit monitoren angezeigt werden oder in technisch unzureichender weise in 8bit delivery-codecs gepackt wurden.

mash_gh4 hat geschrieben:intern wird auch bei verwendung von integer datenrepräsentation sicher nie mit 10bit auflösung gerechnet, sondern immer mit 8, 16 od 32 bit breite.

16bit reichen aber im vorliegenden fall mit größter wahrscheinlichkeit bereits aus, um keinen unterschied zur float (32bit) bearbeitung sichbar werden zu lassen.

Gut, hier ist ein Unterschied sichtbar. Ob das nun aber ein Artefakt ist, kann zumindest ich schwer beurteilen. Ich weiß ja nicht wie es bei den Anderen aussieht - aber ich habe hier 8it Schirme stehen, und sicherlich keine sonderlich tollen.

mash_gh4 hat geschrieben: oder aber, im wissen um die beschränkung des verwendeten ausgabe-kanals, vorsorglich sauber für 8-bit darstellung aufbereitet werden.
...

das ist auch der grund, warum vernünftig optimiertes 8bit material oft deutlich befriedigender wirken kann als 10bit quellen, die auf billigen 8bit monitoren angezeigt werden oder in technisch unzureichender weise in 8bit delivery-codecs gepackt wurden.

Kann gut sein dass dies mitspielt. Aber dann können wir uns von diesen Ansätzen hier eher verabschieden. Einfach, weil es mit 8bit Geräten dann kaum zu beurteilen wäre?

Jim_pansen hat geschrieben: LOL
Ich hoffe, dir ist mit dem GoPro-Cineform Codec Pack geholfen.
Wobei ich so meine Zweifel habe und der Workflow im Grunde auch mal auf
Farbtiefe, Colorshifts und Lumaspreizungen ge-checkt werden müsste. ;)

Jim

Oh Gott!

mash_gh4 hat geschrieben:16bit reichen aber im vorliegenden fall mit größter wahrscheinlichkeit bereits aus, um keinen unterschied zur float (32bit) bearbeitung sichbar werden zu lassen.

Das ist auch meine Vorstellung dazu.

mash_gh4 hat geschrieben:einige bedeutsamkeit bzw. aufmerksamkeit verdient übrigens auch die tatsache, dass es einen großen unterschied macht, ob 10bit daten einfach nur auf 8 bit gerundet bzw. abgeschnitten werden (bspw. mit einem verschieben der bits um zwei stellen nach rechts), oder aber, im wissen um die beschränkung des verwendeten ausgabe-kanals, vorsorglich sauber für 8-bit darstellung aufbereitet werden. im letzteren fall wird gewöhlich mit dithering u.ä. eine ausgabe erzeugt, die deutlich weniger banding zeugt bzw. auffallend besser wirkt als abgeschittene übergangswerte. das ist auch der grund, warum vernünftig optimiertes 8bit material oft deutlich befriedigender wirken kann als 10bit quellen, die auf billigen 8bit monitoren angezeigt werden oder in technisch unzureichender weise in 8bit delivery-codecs gepackt wurden.

Abschneiden kenne ich auch nur in dem Fall, wenn 10 Bit Material über eine 8 Bit Schnittstelle gelesen wird.
Dann wird tatsächlich abgeschnitten! Und das ist in dem Fall auf Grund der technischen Beschränkungen,
wenn auch nicht schön, völlig in Ordnung!

Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial
grundsätzlich in 10 Bit Projekten.

Jim

Marco hat geschrieben:Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale.

Danke, ach ich hab doch HDCAM SR schon wieder vergessen...

Ich kann Dir heute Abend zum Vgl ein HDCAM SR- und Cineform-file zum Vergleich in die dropbox legen, vielen Dank!!!

thsbln hat geschrieben:

Marco hat geschrieben:Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale.

Danke, ach ich hab doch HDCAM SR schon wieder vergessen...

Ich kann Dir nachher was in die dropbox legen, vielen Dank!

An einem Testclip hätte ich auch Interesse!

Jim

Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial grundsätzlich in 10 Bit Projekten.

Bearbeite es doch gleich in einem 32bit Projekt in After Effects ;)

dienstag_01 hat geschrieben:

Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial grundsätzlich in 10 Bit Projekten.

Bearbeite es doch gleich in einem 32bit Projekt in After Effects ;)

Auf keinen Fall!
Ich möchte mit meiner Arbeit auch irgendwann fertig werden! ;)
32 Bit ist in meinem Fall auch überhaupt nicht notwendig.

32 Bit ist in meinem Fall auch überhaupt nicht notwendig.

10 Bit sicher auch nicht, ist nur die Hoffnung, dass viel viel hilft ;)
Machts aber nicht, sie Erklärung von mash_gh4

dienstag_01 hat geschrieben:

32 Bit ist in meinem Fall auch überhaupt nicht notwendig.

10 Bit sicher auch nicht, ist nur die Hoffnung, dass viel viel hilft ;)
Machts aber nicht, sie Erklärung von mash_gh4

Also diese Darstellung ist jetzt ein wenig arg verkürzt. Ich habe es nicht so verstanden, das er sich grundsätzlich gegen 10bit ausspricht. Das hat schon seine Vorteile und seine Berechtigung.

Aber er spricht die Frage an, wie diese Signale dann beim Wechsel in die 8bit Welt behandelt werden - sei es eine Vorschau auf lausigen 8bit Monitoren oder in Codecs. Das ist aber eine andere Sache.

»Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen«

Ich weiß ja nicht, ob das bei dir anders ist, aber ich kann in GoPro Studio gar keine ProRes-Dateien importieren.

wolfgang hat geschrieben:Also diese Darstellung ist jetzt ein wenig arg verkürzt. Ich habe es nicht so verstanden, das er sich grundsätzlich gegen 10bit ausspricht. Das hat schon seine Vorteile und seine Berechtigung.

ja -- so sollte es eigentlich rüberkommen.

im wesentlichen finde ich es ohnehin wunderbar, wie hier diesem problem nachgespürt wird! nur manche interpretation der ursachen scheint mir ein wenig übers ziel hinauszuschießen.

ich selber bin bei solchen dingen immer ein wenig verführt, es gleich mit numpy (numeric python etc.) od. ähnlichem durchzuspielen bzw. zu analysieren. aber natürlich geht es auch mit ganz einfachen alltäglichen mitteln, die jeder von uns zum überprüfen vor sich stehen hat. derartige kreativität finde ich immer ganz besonders spannend. :)

dass ich diesmal nur lästernd vom rand her polemische kommentare einwerfe, statt mich selbst konstruktiv am spiel zu beteiligen, hat vor allem damit zu tun, dass für mich HQX od. ähnliche proprietäre lösungen, für die es unter linux kaum unterstützung gibt, von vornherein aus jeder engeren wahl der mittel ausgeschlossen sind. das ist aber natürlich nur meine ganz subjektive sicht der dinge. für andere kann es sich gänzlich anders darstellen, wenn sich dadurch gangbare wege auftun.

und natürlich finde ich 10bit ausgangsmaterial und eine ausreichende minimierung der berechnungsfehler in der verarbeitung höchst wünschenswert. allerdings darf man dabei den abschließenden export in konventionelle 8bit zielformate od. darstellungseinschränkungen nicht völlig unterschätzen od. übersehen. sonst ist es ungefähr so, als würde man ein foto mühsam in hoher auflösung in seinen details bearbeiten und dann ganz zum schluss mit völlig untauglichem nearest-neighbor scaling verkleinern.

Also diese Darstellung ist jetzt ein wenig arg verkürzt. Ich habe es nicht so verstanden, das er sich grundsätzlich gegen 10bit ausspricht. Das hat schon seine Vorteile und seine Berechtigung.

Aber er spricht die Frage an, wie diese Signale dann beim Wechsel in die 8bit Welt behandelt werden - sei es eine Vorschau auf lausigen 8bit Monitoren oder in Codecs. Das ist aber eine andere Sache.

Ja, hier ist ja auch kein 10bit Workflow gemeint, sondern ein Workflow, der 8bit-Material in einem 10bit-Projekt bearbeitet.

dienstag_01 hat geschrieben:Ja, hier ist ja auch kein 10bit Workflow gemeint, sondern ein Workflow, der 8bit-Material in einem 10bit-Projekt bearbeitet.

ja -- es gibt bekanntlich diese erkennbaren fehler, die nicht den schwächen des 8bit ausgangsmaterials anzulasten sind, sondern einer unzureichend genauen bearbeitung bzw. deren eingriffen. in dem fall reicht es oft wirklich, wenn man das 8bit ausgangsmaterial nur gleich sorgsam wie 10bit quellen behandelt.

dienstag_01 hat geschrieben:

32 Bit ist in meinem Fall auch überhaupt nicht notwendig.

10 Bit sicher auch nicht, ist nur die Hoffnung, dass viel viel hilft ;)

Anspruch ist es doch vielmehr, die Kette bei der Verarbeitung auch ohne Not so sauber, wie möglich
zu halten, erst recht, wenn es doch überhaupt keinen Mehraufwand macht. Sicherlich ist der Effekt,
den andere sich davon versprechen, eher im Promillebereich zu verorten. Aber in der Kaskade
mehrerer Effekte kann es der Qualität zuträglich sein.
Ich würde auch auf 32-Bit Floating-Point setzen, wenn Edius das als Projektparameter anbieten würde.
Ich würde aber auch nicht glauben, damit einen sichtbaren Qualitätsgewinn erzielen zu können, sondern
ich hätte einfach nur das gute Gefühl, ausgesprochen wenig Rundungsfehler in der Verarbeitungskette
verorten zu müssen.

Ich erhalte in der Regel zu 95% fertig gegradetes ProRes 10 Bit Material und ich liefere 10 Bit Material
aus. Und für die restlichen 5 % erstelle ich mir ganz bestimmt keine 8 Bit Preset.
Das ist mir doch die Mühe gar nicht wert. ;)

Jim

dienstag_01 hat geschrieben: Ja, hier ist ja auch kein 10bit Workflow gemeint, sondern ein Workflow, der 8bit-Material in einem 10bit-Projekt bearbeitet.

Also (von meiner Seite) definitiv nicht! Wie kommst zu dieser Einschätzung?

Jim_pansen hat geschrieben:

thsbln hat geschrieben:

Marco hat geschrieben:Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale.

Danke, ach ich hab doch HDCAM SR schon wieder vergessen...

Ich kann Dir nachher was in die dropbox legen, vielen Dank!

An einem Testclip hätte ich auch Interesse!

Jim

So, hier sind 3x2Sekunden, einmal das ProRes HQ aus der BMPCC, dann jeweils aus Vegas gerendert ein Cineform (Qualität Filmscan 2) und ein HDCAM SR:

https://www.dropbox.com/s/fiore0jm47osx ... s.zip?dl=0

@Marco: ich habe mit GoPro Studio gar nichts gemacht, sondern es nur wegen des Cineform-Codecs installiert.

wolfgang hat geschrieben:Also (von meiner Seite) definitiv nicht! Wie kommst zu dieser Einschätzung?

Nö, habe ich auch nie behauptet ;)
Hier ist der Bezug:

Jim_pansen hat geschrieben:Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial grundsätzlich in 10 Bit Projekten.