Noch eine Frage zum SonicFoundry DV Codec...

Hallo Mark,

ein paar Rückfragen:

>> wenn ich mir die Farb-Kanäle (R,G,B) ansehe

Wo, wie und wann hast Du diese Kanäle denn geprüft?
Hast Du zuerst den Clip neu gerendert und dann den NEUEN Clip geprüft?
Hast Du ihn innerhalb des Vorschaufensters in VV geprüft?

Wie sehen denn Deine Rendereinstellungen aus, welche Qualität hast Du dort definiert?

>>sind diese aber immer noch durch diese typische DV Kompression verpixelt.

Auf einem Video-Monitor sollte man eine Pixelbildung bei DV generell gar nicht erkennen können.
Du hast aber vermutlich auf einem VGA-Monitor recht genau die Farbkanten geprüft, oder?

>> Doch genau das soll VV doch angeblich verhindern?!

Das muss man etwas differenzieren. VV umgeht eine Hürde des 4:2:0 Farbsamplings, das PAL-DV-Bestandteil ist, dadurch, dass der V-Kanal im YUV-Signal beim Rendering mit dem Keyer (vertikal?) interpoliert wird, um somit eine fehlende Farbinformation zu ergänzen.

Kannst Du mir vielleicht mal ein Einzelbild einmal Deiner Originale und dann des gekeyten Ergebnisses senden? So ohne kann ich mir nicht so recht vorstellen, wo es da haken könnte.

>> => Beide sehen gleich aus

Das ist eigentlich schon das höchste, was man von einem Schnittsystem und auch vom Keying erwarten darf.
Gleiches Aussehen = keine Veränderung = perfektes Rendering!

Dein Keying sieht doch eigentlich auch perfekt aus (zumindest auf meinem Browser), abgesehen von dieser Sägezahnbildung auf dem Kissen, aber die kommt vermutlich von der JPEG-Kompression für das Einzelbild.

Deine Erwartung ist wahrscheinlich die, dass wegen der Interpolation später die Kanten BESSER als das Original aussehen sollten!?

Darüber muss ich mal nachdenken und auch selbst etwas mit Deinem Bild experimentieren.

Leider muss ich jetzt - trotz Feiertag - erstmal zur Arbeit. Dort komme ich zwar noch an einen Internetrechner, aber leider nicht mehr zu VegasVideo.
Kann mich also zu diesem Thema wohl erst heute Nacht zurückmelden.

>Ich dachte, das VV diese 4:2:0 Kompression interpoliert und dadurch die
>Qualiät des Keys zumindest etwas verbessert

Ja, ganz genau so hatte ich das eigentlich auch interpretiert.
Dein Beispiel zeigt dann schon SEHR deutlich, dass dem nicht so wäre.
Ich werde das heute Nacht - wenn ich richtig wach bin - mal verifizieren.

Hallo Mark,

ich hatte mir die große JPEG-Variante Deines Beispielbildes runtergeladen und damit dann selbst mal das Keying in VV angewendet.

Weiß nicht warum, aber ein so krasses Sägezahnmuster wie es bei Dir erscheint, kann ich damit gar nicht erzeugen.

Ich hab mal einen Link mit den Framegrabs meiner Beispiele angehängt in Verbindung mit dem Einstellungsfenster für den Keyer.
Für das obere meiner Bildbeispiele hatte ich im Keyer zusätzlich noch den Blur-Wert auf 0,015 gesetzt.
Das mittlere Bild ist ganz ohne Blur und dennoch ist von dem Sägezahnmuster nicht mehr viel zu sehen - So hätte ich mir das mit diesem Keyer auch vorgestellt.

Wenn wir das exakt vergleichen wollen, müsstest Du nun mal gegentesten, welches Ergebnis Du erzielst, wenn Du nun das JPEG, das Du hier hochgeladen hattest, nimmst, dann zusätzlich nochmal die original DV-Datei und mit beiden nochmal das Keying machst mit den Werten, die Du in meinem Einstellungsfenster siehst.

Dann wird sich nämlich rausstellen, ob mein Ergebnis nur deswegen besser aussieht, weil ich das JPEG anstatt Deiner original DV-Datei benutzt hatte (was ich mir fast nicht vorstellen kann), oder ob es an den Key-Einstellungen lag, oder ob's sonst noch was sein kann.

Hier der Link zu meinen Ergebnissen: --> Keytest

Hallo Mark,

>> Kannst du vielleicht mal ein Keybeispiel mit VV machen
>> und mir das per mail senden?

Was meinst Du denn mit 'Keybeispiel' - Ein Bildbeispiel eines eigenen Keyings oder eine kleine Anleitung? - Am besten ja beides ...

Das könnte aber ein paar Tage dauern, denn bis gestern hatte ich mich im Grunde noch gar nicht mit dem VV-Keyer beschäftigt. Auf den ersten Blick vermisse ich dort auch ein paar Einstellparameter, die ich von anderen Keyern kenne. Muss mich auf jeden Fall noch genauer damit beschäftigen.

Was mir auch aufgefallen ist: Die Echtzeitvorschau ist ausgerechnet beim Keying sehr zäh. Das kenne ich bisher von keinem anderen Filter aus VV (und auch nicht von Keyern anderer DV-Software).
Das bedeutet ja zumindest mal, dass hier besonders viel gerechnet wird - Vielleicht auch ein Hinweis dafür, dass der dritte Farbkanal interpoliert wird, nur müsste man das dann natürlich auch irgendwie - positiv - im Ergebnis sehen können.

Kannst Du mir vielleicht mal ein einzelnes Bild als AVI aus Deiner original DV-Vorlage schicken (dürfte dann ja nur 154 kB groß sein)? Wenn das JPEG derart glättet, dann wär's schon besser, den Test mal mit dem Original machen zu können. Ich hab zwar etliche Blue-Box-Vorlagen, aber keine davon ist etwas mit einer so schräg verlaufenden Kante wie bei diesem Kissen.

>> Kannst du deine Videoclips direkt über VV Capture einspielen?

Ja, wahlweise als Batch-Capturing, als ganzes Band oder mit automatischer Szenentrennung.

>> Bei mir funktioniert das nämlich nicht, weil meine DV200 nicht OHCI
>> kompatibel ist...

Das ist klar, dann kann es nicht funktionieren. VegasVideo ist einzig und allein für den Betrieb auf OHCI-Firewirekarten ausgelegt.

>> VV zeigte dann in der "Echtzeitvorschau" auch nur jedes zweite oder dritte Bild.

Ja, das ist wohl das, was man in VV unter "intelligenter" Echtzeitvorschau zu verstehen hat
Man kann das bis zum einem gewissen Grad verhindern, indem man eine "Ram-Preview" macht.

Beim Keying ist das noch schlimmer, denn dort wird nicht allein die Wiedergabe des laufenden Videos reduziert, sondern schon jede Reglereinstellung wird erst mit einer zeitlichen Verzögerung umgesetzt (zumindest mal auf meinem 900 MHz-PC). Das finde ich doch etwas gewöhnungsbedürftig, zumal ja bei anderen Filtern eine Einstellungsänderung sogar in Echtzeit in das laufende Video übernommen wird.

Wenn Du auf Geschwindigkeit, also flüssige Abläufe in der Echtzeitvorschau stehst, kommst Du wahrscheinlich um Verkleinerung des Previewbildes und Verringerung der Vorschauqualität nicht herum. Und dem VV3 im Task-Manager höchste Priority zuweisen (Echtzeit). Das merkt der sich leider nur für die laufende Sitzung. Das Vorrendern im Ram (genügend Ram zuweisen) geht übrigends blitzartig - ist allerdings nicht mehr "Echtzeit". Ich tiftle da auch gerade. Habe gerade in 2 weitere RAM-Riegel investiert - man kann nie zuviel Speicher haben(außer bei Win98).
Gruß

Hi Tom,

>> Außerdem beraubst Du Dich doch dann der Möglichkeit, die Auswirkungen
>> der Schieberänderungen dirkt beurteilen zu können, oder?

Stimmt. Ich hab mal frechweg einfach missachtet, dass es in Deinem Beispiel um die Farbkorrektur ging (in "Farbkorrektur" beziehe ich auch Helligkeit, Kontrast u.ä. mit ein). Da ist auch mir diese direkte Beurteilung sehr wichtig und somit kommt da eigentlich kein Ram-Preview in Frage.
Allerdings vermisse ich bei der Farbkorrektur in Echtzeit die fehlenden Frames nicht, denn dann benutze ich die Echtzeitfähigkeit wirklich nur zum Pegeln der Korrekturwerte und achte dabei nicht auf die Bildbewegung, nur noch auf die Videopegel.

Wieviel Ram hast Du VV eigentlich für die Vorschau zugewiesen?

Möchte kurz von einem urigen Phänomen berichten: Habe also meine beiden Schokoriegel in den Rechner eingeschoben und VV3 gestartet, 512 MB für den dynamischen Ram zugewiesen - daraufhin war das Berechnen des dynamischen RAM-Previews ausgegraut/nicht wählbar. War aber nicht zuviel, sondern zuwenig. Jetzt, mit 800MB zugeteilt, ist es wieder glücklich, das speicherhungrige Teuferl.
Und fetzt auch ganz ordentlich. Wenn man die Priority auf Echtzeit setzt, kann man aber natürlich während des Renderns andere Dinge vergessen, da erntet man nur Sanduhren. Ist auch nicht so, daß Vegas/W2k beide CPUs gleichzeitig beschäftigt, das geht offensichtlich schön abwechselnd mit 100%. Ich mach jetzt mal einen Test, wie das mit 2 Instanzen mit Rendern ist.
vollgeRAMte Grüße

Mark:
Zum Keying habe ich im SonicFoundry VV3-Forum den besonders witzigen Vorschlag gelesen, die Camera ins Hochformat zu drehen und das Bild nachher per Filter zurückzudrehen und so zu verkleinern, daß es ins Bild paßt; dann hättest Du(lt. Beitrag) eine 4:2:2-Source über 50% des Bildfeldes. Mir klingt das zwar spanisch, aber versuchen kannst Du's ja. Geht wohl nur sinnvoll, wenn eine Person ausschließlich vor Keyhintergrund agiert. Läßt sich allerdings nicht ganz ausschließen, daß das angeblich so gute Verhalten bei chroma Key sich auf NTSC-DV bezieht (4:1:1)
Gruß

Also dieses Sägezahnmuster-Rätsel kann ich anscheinend wirklich nicht knacken
Ich hab's jetzt auch mal mit Vollbild-, statt Halbbildmaterial versucht. Die Vorlagen sind gewiss von guter Bluebox-Qualität (vielleicht vom DV abgesehen), aber auch ich habe dann immer das gleiche Sägezahnmuster wie man es auf dem Bild oben erkennen kann.

Alexander, der Tipp mit der Drehung - eigentlich ist das genial, zumindest mal für Testzwecke. Ich habe das gerademal nachträglich gemacht, also Bild erst im Rechner um 90 Grad gedreht und dann den Keyer draufgesetzt.
Hier zeigt sich jetzt, dass dieses Sägezahnmuster IMMER horizontal erscheint.
Ich sehe hier aber auch deutlich, dass diese horizontale Linienbildung doch über eine große Strecke geht, also ich kann mir fast nicht mehr vorstellen, dass das vom 4:2:0-Sampling kommt. Dann müsste ja eigentlich auch das gedrehte Bild die Linien vertikal aufweisen.
Mir scheint es, als wäre eben genau dieser Sägezahneffekt das, was durch die Interpolation passiert (in meiner anderen Software, die definitiv nichts interpoliert, habe ich auch diesen seltsamen Effekt nicht), aber ob das so auch korrekt sein kann, das wage ich zu bezweifeln.
Vielleicht ein Bug???

Was ich aber auch bemerkt habe - Wenn ich auf ein solches Keying, das zum Weglaufen sch... aussieht, einen ganz leichten Blur (so etwa 0,015) anwende, dann ist das Ergebnis eigentlich auf dem Videomonitor richtig gut.
Soll das etwa Sinn der Sache sein? - Gehen die vielleicht davon aus, dass man auf jeden Fall den Key noch mit einem Blur versieht???

Marco, Mark
Ich würde sagen: hilf, was helfen mag. Was gut aussieht, ist auch erlaubt. Aber vorgesehen kann es meiner Meinung nach nicht sein, sonst müßten sie eigentlich über das Thema Chroma Key taktvoll schweigen, statt es so hervorzukehren. Vielleicht versucht Ihrs nochmal mit einer direkten Frage im sonic forum? die sind natürlich hauptsächlich mit NTSC unterwegs.

ansonsten:
Die Priority -Einstellungen in W2K sind auch nicht voll überzeugend. Der in der Taskliste 1. vegas-Prozeß bekommt max. 52% Rechenleistung, der 2. bis zu 29%, egal was beide machen. Wenn man rendert, dann besser nicht ins selbe Verzeichnis auf derselben Platte. (Und wenn kein Platz mehr im Verzeichnis ist, dann beschimpfen sie sich gegenseitig, ihn verbraucht zu haben. Sehr menschlich! Hat wohl nur so gewirkt, in beiden ging ein Fenster auf, daß entweder ein anderer Prozeß....). Ich muß da wohl noch ein wenig forschen.

Schönen Samstag!

Hallo Mark und alle Interessierten,

was ich jetzt durch Tests und Recherche herausgefunden hab, sieht leider nicht gut aus.

Diese Sägezähne treten in VV eigentlich immer auf, wenn ein extrem farbkantiges Material nach DV gerendert wird, es passiert z.B. auch mit farbkantigen Graphiken, die man dann nach DV rendert. Spätestens beim Keying an gerundeten oder schrägen Kanten tritt der Effekt dann auf.

Das Keying macht dieses Verhalten im Grunde genommen nicht besser und nicht schlechter.
Es wirkt ähnlich wie ein Interlace-Fehler eines Halbbildes, aber auch das habe ich überprüft, indem ich Vollbildmaterial nach "progressive scan" gerendert hab, mit dem gleichen Ergebnis.
Und rendere ich solche Bilder nach NTSC-DV, dann werden diese Sägezähne nicht in horizontaler, sondern in vertikaler Richtung dargestellt.

Also kann man wohl davon ausgehen, dass diese Fehler tatsächlich durch das 4:2:0-Sampling des DV-Materials entstehen.

Wäre ja weiter nicht schlimm, denn angeblich ist das VV-Keying ja speziell für DV optimiert (genau darauf bezieht sich ja die Ausgangsfrage dieses Threads). Aber weder bei PAL-, noch bei NTSC-Material (und NTSC-Rendering)
kommt es zu einer Signalverbesserung, also keine Interpolation zu erkennen.
Das Verhalten beim Keying ist nicht vom SF-Codec abhängig. Der MC-Codec zeigt das gleiche Verhalten, nur mit etwas schlechterer Gesamtbildqualität.

Ich hab hier nochmal ein paar Testbilder aus meinem letzten Versuch hochgeladen. Einmal das Original-BMP, dann das BMP nach PAL-DV gerendert und zuletzt dann noch das gekeyte PAL-DV-Signal.
Davon habe ich dann eine starke Ausschnittvergrößerung gemacht und als PNG gespeichert:

--> Key-Test

Auch in den US-VegasVideo-Foren konnte man mir bisher nichts zu diesem Phänomen sage. Ich werde im SonicFoundry-Forum nächste Woche ein wenig rumstänkern, damit sich irgendjemand vom Support endlich mal genötigt fühlt, darauf einzugehen, denn entweder ist das mit der Verbesserung des Key-Signals eine glatte Lüge (wäre nicht das erste mal), oder es ist ein Bug, oder wir machen immer noch was falsch ...