That false 12 bit display of some video formats is in Vegas Pro since it's first version. I think we all learned to ignore it somehow.

Maybe because it is interlaced it is half of 24 :)

Ken.

Same happens with some kind of progressive footage.

I think I've seen it more with hardware encoders, which could easily be writing superfluous tags.

Vielen Dank für die Rückmeldung.

Ich hab alle Sony-Codecs probiert und komme fast zu dem Schluß, daß es reine Merkmale von Sony sind, nur der XAVC (Intra/S-Long) scheint richtig zu sein. Bei dem HDCAM SR-422 kommt es sogar auf 1920x1080x20, also es hat nichts mit der Video-ID-Nr. zu tun.

Vegaspro hat auch einige Zeit bei Sony gewohnt und kannte eigene Boys nicht, das ist einbißchen undenkbar..😇😇

Apropos Codec: mir ist aufgefallen, irgendwann ist es irgendwo diskutiert, ob der Intermediate ProRess ein 10-bit Codec ist. Ich hab ein Blackmagic-Kamera-Schuß gekriegt und mit MediaInfo darein geschaut. Der Kamerabesitzer sagt es sei ein 10-bit Video.

Also vom Vergleich aus würde ich sagen, der Magix-ProRess muss ein 10-bit(fähiger) Codec sein, sonst könnte er auch keine 444 Sampling machen. Ob ich recht habe?

Dann könnte bei den ungewöhnlichen Angaben zur Farbtiefe die Farbreduktion berücksichtigt sein. 4:2:0-Signale halbiert, 4:2:2-Signale mit einem Anteil von zwei Dritteln.

Ob 8 Bit oder 10 Bit hat keinen direkten Zusammenhang zur Farbreduktion. Es gibt beispielsweise auch 4:2:2 10-Bit-Codecs und 4:4:4 8-Bit-Codecs.

»Ich hab alle Sony-Codecs probiert und komme fast zu dem Schluß, daß es reine Merkmale von Sony sind, …«

Nee, ich sehe das z. B. auch mit manchen Panasonic-Aufnahmen. Und beim Sony-YUV-Codec ist die Anzeige korrekt.

Ob 8 Bit oder 10 Bit hat keinen direkten Zusammenhang zur Farbreduktion. Es gibt beispielsweise auch 4:2:2 10-Bit-Codecs und 4:4:4 8-Bit-Codecs.

Dann heißt es, die Farbunterabtastung geht nur um die Feinheit/Reinheit und nicht die Farbtiefe? Richtig?

Ich habs wieder gegoogelt, es soll so sein: die Farbtiefe geht grundsätzlich um ihr Ausmaß/gamut. Und natürlich kann ein Rec709/sRGB Farbraum (8bittief) den von Rec2020 nicht bedecken, nämlich, das Ausmaß Rec2020 muss mindestens um 10bit tief sein.

Nun kommt meine Frage zurück:

1, Vegaspro v16 (und vielleicht auch anfangs von v17) kann in ACES modus mit ProRess, dem einzigen Intermediate-Codec, Dateien rendern und rendert sogar nach Output-Color-Space-Definition wie Rec709 oder Rec2020 oder was sonst noch, also echt zum Intermediate-Change. Ich habs probiert, die Rec2020-Ausgabe scheint ganz korrekt und die Rec709-Ausgabe perfekt.

IST Magix ProRess ein 10bit Codec? Oder kann ProRess für Rec2020 kodieren?

2, die jetztige Version von Vegaspro ergänzt einen HDR(10)-Edit-Mode und lässt nur HDR-AVC/HEVC-Ausgabe. Gibt ES einen Intermediate-Codec dafür?

3, Ungeachtet auf den HDR-Modus kann ich trotzdem in den ACESpace landen und tue meine Verarbeitung wie (einst) gewöhnlich aber!!

Ich kann beim Rendern keine richtige Ausgabe kriegen wie z.b. ich rendere mit ProRess, definiere die Ausgabe-Farbraum auf Rec709, und ich bekomme ein echtes sRGB-Video.

Unterstützt Vegaspro noch Rec2020? Falls, mit welchen Codecs?

Danke Marco. Ich glaube Sie/Du... mindestens 10 Jahre mit dem Program vertraut gewesen zu sein.

Farbräume, Farbmodelle und Farbmanagementsysteme sind nochmal was anderes, die sind unabhängig von den Farbreduktionen wie 4:2:0, 4:1:1 oder 4:2:2 zu betrachten.

Der Export zu Magix Intermediate, also quasi ProRes, aus einem 32-Bit-Floatpoint-Projekt von Vegas Pro ist nach unseren bisherigen Tests tatsächlich 10 bit.

Zu welchem Farbraum dabei gerendert wird, musst du nochmal gesondert in den Rendereinstellungen festlegen. Da hättest du auch die Auswahl von Rec. 2020.

Hi Marco, ich bin zurück. 

§1, ja, ich habe alles richtig mitgekriegt. 

§2, endlich eine Bestätigung! Sehr gefreut. 

§3, gerade hier hat sich Vegaspro (V17B452) geändert -- alle Schritte richtig getan aber keine richtige Folge daraus. Wenn du irgendwann Lust hast, kannst du folgendes nachprüfen: 

1, das Testbild in 32-bit-Projekt aufladen, dem VideoBus das ColorCurves anhängen (du bist der erste der diese Eigenschaft davon gemerkt hast, dazu aber ein andermal), das Projekt mit ProRess rendern. 
Du bekommst ein standard Rec709 Video. 

2, das gleiche Projekt ändern vom ViewTransform=Off auf ViewTransform=sRGB(ACES) -- also meinem ViewMonitor(LaptopLCD) entsprechend, das Plugin ColorCurves vom VideoBus weglassen, Eigenschaft des Testbildes auf sRGB umstellen (das hat gar nichts zu tun mit dem ViewTransform -- ist dir ja auch klar).

das Projekt mit ProRess rendern: 
Export A zu Rec2020
Export B zu Rec709
Export C zu Sony - SLog1 - SGamut

Die ACES-Einführung ins Vegaspro ist mit einer wichtigen Aufgabe beabsichtigt, nämlich Datei-Formate auszutauschen ohne teuere Hardware. 
Leider, keine von den drei gerenderten Exporten sind brauchbar. 
Ich fürchte, das Vegas-Team weiß das, nur Mund gehalten. 

»Leider, keine von den drei gerenderten Exporten sind brauchbar.«

Das kann ich so nicht reproduzieren. Die auf oben beschriebene Weise gerenderten Clips müssen ja jetzt unter gleichen Bedingungen wieder decodiert werden. Also auch wieder rein in ein Projekt mit Floatpoint Full Level linear, ACES aktiviert, sRGB als View Transform.
Jetzt muss für jeden der Clips nochmal die ihm beim Rendern zugewiesene Eigenschaft als Clipeigenschaft definiert werden, also Rec. 709, Rec. 2020 und Sony S-Log1 S-Gamut.

Wenn ich das tue, dann entsprechen zumindest die Varianten Rec. 709 und Sony S-Log1 S-Gamut dem Original. Die Variante Rec. 2020 zeigt tatsächlich eine erkennbare Abweichung, zwar sind Schwarz-/Weißwert und Gamma gleich, aber der Farbwinkel hat sich etwas gedreht.

Woran das bei Rec. 2020 liegt, kann ich momentan noch nicht sagen. Ich gehe dem mal nach.

Das kann ich so nicht reproduzieren. Die auf oben beschriebene Weise gerenderten Clips müssen ja jetzt unter gleichen Bedingungen wieder decodiert werden.

Wir konzentrieren uns auf eins:

Der gerenderte Clip vom 32-bit-Projekt ist meinem Wunsch nach eine Video-Datei mit Rec709-Levels und er IST genau so.

Der mit Rec709Colorspace-Profile gerenderte Clip von dem zweiten Projekt soll auch eine Video-Datei mit Rec709-Levels sein, weil ich es in der Render-Vorlage so definiert habe.

Das heißt, die beiden müssten unabhängig von Projekten aber identisch miteinander sein. Ich habe den Vorgang gerade wiederholt und bekomme immer zwei unterschiedliche, nur, ich kann sie hier nicht hochladen.

Könntest Du vielleicht nochmals experimentieren?

Es drängt nicht.

PS: ich habe eins vergessen zu ergänzen. Wenn das ACES-Projekt zu Magix-HDRAVC/HDRHEVC (nur HDR) mit Rec709profile exportiert, kriegt man auch richtige Resultat.

Ich werde es mir anschauen. Allerdings – wenn du aus einem ACES-Project mit linearem Full-Level ein Bild benutzt, wird es ja einem anderen Mapping unterzogen als bei der Verwendung in einem regulären 8-Bit sRGB-Projekt (nur deine Vorschau korrigiert das über die View Transform fürs Projekt). Und dieses Mapping überträgt sich auf die gerenderte Datei. Die Definition Rec. 709 als Rendereigenschaft macht den linearen Full-Level-Character des Input-Mappings nicht rückgängig.
Also kann meines Erachtens eine so gerenderte Datei in einem normalen 8-Bit-Projekt unmöglich dem Original entsprechen, es muss dazu in einem linearen Full-Level-Projekt verwendet werden.
Wie gesagt – ich muss mir das nochmal genauer ansehen. Vielleicht liege ich mit der Theorie falsch.
Ein erster Test dazu wäre, kein lineares Full-Level-ACES-Projekt dafür (fürs Encoding des Originals) zu nutzen, sondern eines mit Gamma 2,222.

Warum es sich innerhalb einer HDR-Umgebung anders verhält, kann ich nicht beurteilen. HDR ist vorerst nicht für mich.