Hallo Profis!
Ich habe ein dringendes Problem in AfterEffects!
Meine Composition (720x568, 25FPS) besteht aus 5 sehr, sehr langen Photoshopdatein (wirklich lange, ca. 5000pxl). Diese langen Banner sollen von rechts nach links durchs Bild fahren. Ich hab das mit zwei Keyframey in der Postionseinstellung gelöst: Anfangskeyframe - Endkeyframe.
Mein Problem: Wenn diese Balken nun ihren weg über den Bildschirm zurücklegen, ruckeln die Dinger. Das ganze ist keine smoothe Animation, sondern eher ein dahingestotter...
Meine Frage: Wie kann ich diese Animation wirklich ruckelfrei ausgeben?
Was die Balken beim Abspielen auf dem Bildschirm machen ist Wurscht ;-)
Ob viel oder wenig Gestotter bei der Vorschau ist von der Rechnerleistung (Speicherausbau, Festplattenbelegung, Prozessoren etc.) bzw. der Komplexität der Komposition abhängig.
Wichtig ist, was letztlich die Rendermaschine von AE daraus macht. Das fertige, gerenderte Video sollte ruckelfrei abspielen. 100:1 Wette, dass AE das schafft ;-)
Danke für eure Antworten, Leute!
Dicker Stefan, ich halt die Wette - das ausgegebene Video stottert immer noch. Oder besser gesagt die Balken, wenn sie über den Bildschirm fahren... das Video selbst rennt schon flüßig, da ich beim nachfolgenden Wegzoomen und Anwenden eines Blur-Filters eine schön smoothe Animation sehe. Aber eben nicht bei der bildschirmfüllenden Abbildung der Balken...
Liegt das an den Keyframes bzw. an deren Interpoaltion?
Kennt sich wer mit diesen Roving Keyframes und all den Einstellungen aus?
HELP IS STILL URGENTLY NEEDED!
thx in advance,
rookie
Die Balken "stottern" oder "krisseln"? Falls krisseln=Halbbildproblem, falls stottern=??. Beim krisseln hilft auf ein horizontaler (oder wars vertikaler :) ) Blur (0,2 - 0,5) auf die Balken, wahlweise auch Halbildflimmern entfernen und natürlich das korrekte Einstellen der Halbbilddominanz (s. Vorposter)
Wenn das Endvideo interlaced ist, kannst Du auch mit einer Komposition plus Unterkomposition arbeiten.
In der Unterkomposition "Balken" mit einer Framerate von 50 fps Vollbildern machst Du die Verschieberei der Balken. Die Bewegung wird dann schön smooth von AE berechnet.
Diese Unterkomposition "Balken" setzt Du in eine Komposition "Ausgabe" ein. Die Komposition "Ausgabe" ist natürlich auf Dein Ausgabeformat (720x576 25fps Interlaced bei DV Unteres Halbbild zuerst) eingestellt, s. Vorposter.
nochmals danke für euere tipps!
ich habe alles probiert - leider ohne erfolg!!! *haarerauf*
motionblur ein/aus, 25/50 fps, interlaced/progressive - nix hilft!
das creative cow tutorial beschreibt leider garnix neues - genauso, wie ichs bis jetzt gemacht hab. trotzdem erscheint die animation stotternd!
hab auch den von stefan beschriebenen trick mit der 50FPS unterkomposition probiert. die ergebnisse bleiben die gleichen!!! gibts denn das !?!
bennys tipp hab ich leider überhaupt nicht verstanden.... (?)
Hi,
stell doch mal das Projektfile online,( ohne footage natürlich ) dann kann man das viel besser nachvollziehen.Ansonsten würde ich mich Stefans Wette anschließen, das geht ohne Ruckeln. Die Aufgabenstellung ist ja nicht schwer.
Gruß Jörg
bennys tipp hab ich leider überhaupt nicht verstanden.... (?)
ich nehme an, es sind die Balken oben und unter bei einem letterboxed video (also 16:9), die zittern. Genauso nehme ich an, Du drehst in 4:3 und hast in der Kamera auf 19:9 umgestellt, oder aber die Balken in AE eingefügt.
Wenn dem so sein sollte, dann kenne ich dieses Phänomen auch von AE, wenn ich slomo arbeite.
Um das Zittern der Balken jedoch zu eleminieren ziehe ich in der Editingsoftware über mein 4:3 bild nochmals die balken.
Gruß benny
Sorry,
habe nochmal genau nachgelesen was Dein Problem ist.
Meine Antwort passt da natürlich nicht. War auf einem anderen Dampfer unterwegs.
Sorry nochmals.
Gruß
Benny
das problem hat aber nix mit der ortsfrequenz zu tun! die ortsfrequenz beschreibt, wieviel unterschiede sich in einem 8x8pixel-block in luma und chroma befinden. je mehr details, desto höher die frequenz. infolgedessen werden bei zu hohen frequenzen "matschige" bilder vom codec ausgespuckt, um die 25mbit aufrecht zu erhalten.
auch wenn in der dv-kompression eine dct mit ortsfrequenzanalyse gemacht wird, ist dieses problem hier wahrscheinlich auf die geschwindigkeit des pans zurückzuführen:
wenn man ein bild innerhalb soundsoviel sekunden über den screen jagt, kann es passieren, daß ein bestimmtes bildpixel keine ganzzahligen positionen zugewiesen bekommt. also springt es zum nächsten punkt, wo es im nächsten halbbild sein soll. es ruckelt dann. leicht zu kontrollieren, indem man den pan verlangsamt. dann sollte das ruckeln verschwinden.
das ist genau das, wovon ich geschrieben habe. ab seite 11 wird es extrem theoretisch erklärt. aber glaub mir, bei der SRT (schule für rundfunktechnik) und diversen fachbüchern werden diese informationen etwas leichter verdaulich genau so erklärt.
Hm, dann sag mir mal bitte, was das Zeilensprungverfahren mit 8x8 Pixel großen Blöcken zu tun hat? Die Ortsfrequenz bezieht sich ja nicht nur auf DV-Kompression sondern gilt für die Videobearbeitung und ganz besonders für die Wiedergabe am Fernseher. Du kannst auch mit einfarbigen, 8Pixel hohen kantenscharfen hellen Balken auf dunklem Hintergrund die sich eine zu hohe Ortsfrequenz erreichen (sehr gut sogar). Dort sind aber definitv nicht zuviele Details. Es geht ja nur darum das durch den Zeilensprung die Kanten des Balkens nicht eindeutig einer Bildzeile zugeordnet werden können und deswegen flimmern. Verschlimmern läßt sich das auch durch eine vertikale Bewegung des Balkens. Entschärfen läßt es sich durch einen leichten vertikal-Blur (.2 - .5 Pixel) wodurch der Schärfeeindruck erhalten bleibt, das Flimmern aber nachläßt (so funkt. auch der "Halbbildflimmern entfernen" Filter).
ortsfrequenzen haben nichts mit halbbildverfahren zu tun. das hab ich auch nie behauptet. du wirfst wahrscheinlich einige sachen aus dem von dir genannten vortrag durcheinander. beide halbbilder werden für die DCT-datenreduktion in 8x8 pixel große blöcke aufgeteilt und dann mit hilfe einer ortsfrequenzanalyse gewichtet, gerundet und anschließend quantisiert. halbbilder werden in dem genannten vortrag lediglich deshalb in dem zusammenhang erwähnt, weil die DCT auf beide halbbilder einzeln angewandt wird.
und deine angabe, daß auch ein vollständig schwarzer 8x8 block eine hohe ortsfrequenz hat, ist schlichtweg falsch bzw. ungenau. ungenau, weil natürlich bei sich abwechselnden schwarzen und weißen 8x8 blöcken eine frequenz vorliegt, aber definitiv nicht eine hohe und schon gar nicht die höchste. die höchste vorkommende ortsfrequenz im 8x8 block ergibt sich, wenn sich ein weißes mit einem schwarzen pixel (x+y) abwechselt.
falls du das buch "professionelle videotechnik" von ulrich schmidt hast, schau mal im kapitel 3.4.3 (bei meiner 2. auflage auf seite 121-126) nach. dort ist die DCT genau beschrieben und u. a. auch die bedeutung der ortsfrequenzen für die datenreduktion. ich will aus urheberrechtlichen gründen keinen scan hier ins forum setzen.
aber das hat nun wirklich nichts mehr mit dem ursprünglichen threadthema zu tun. wir sollten das entweder auslagern oder per email besprechen.
Es geht aber nicht generell um DCT und Datenreduktion bei der Ortsfrequenz! Und Ortsfrequenz hat natürlich etwas mit dem Zeilensprungverfahren zu tun. Würde ein Fernseher die Bilder Progressiv wiedergeben, gäbe es das Problem so nicht.
Also.... ich habe es ausprobiert. 200x5000px Banner gemacht und von rechts nach links durch eine PAL DV Komposition von 1000 Frames Länge geschossen. Motion Blur an oder aus, mit Defaultparametern für Verschlusswinkel.
Und.... es ruckelt ;-)
Aber.... nicht überall und nicht überall gleich viel.
Ziemlich gut ist ein Ruckeln im Mediaplayer zu sehen. Mit Motion Blur sieht es etwas besser aus. In VirtualDub ist kein Ruckeln zu sehen, nur gelegentlich eine über viele Frames laufende Versatzlinie, schwer zu beschreiben, wie eine Interferenz halt.
Meine Vermutung: es liegt a/ an dem Betrachtungsprogramm (ggf. Deinterlace oder Dekompression oder Hintergrundtasks) und an der Betrachtung am PC (CRT Monitor bei mir mit 75 Hz).
Deshalb habe ich das Video mit DV auf die Kamera ausgespielt und auf dem TV betrachtet.
Und.... keine Spur von Ruckeln. Supersmoothe Bewegung. AE ist König!
von betrachtung auf dem fernseher bin ich ausgegangen! natürlich haben moniore mit ihrer progressiven darstellung probleme bei interlaced material. der algorithmus zum deinterlacen ist z.b. beim mediaplayer echt schlecht...
Ich habe grad mal ähnliches getestet: einfach einen fertig gerenderten Spot durch eine PAL Komposition (25FPS) bewegt und siehe da: es ruckelte höllisch bei der RAM-Wiedergabe (ja es lief in Echtzeit :) ). Dann stellte ich die Frequenz meines TFTs von 60Hz auf 75Hz ein und es ruckelte schon nicht mehr so stark. Ich gehe mal davon aus, das sich das Problem erledigt hätte, wenn ich die Frequenz auf 50Hz einstellen könnte. Dieses Ruckeln fällt bei normalen Videos am PC nicht auf, zumal sie selten eine so starke/dauerhafte Seitwärtsbewegung beinhalten und der Bildinhalt doch eher viele Details beinhaltet.
@Stefan: Wie hast Du die Banner eigentlich angelegt? Einfache Solids oder mit Bildinhalt?
PS: während ich dies schrieb habe ich noch den Gegentest vorgenommen: PAL-Auflösung, 30FPS eingestellt, Monitor auf 60Hz, RAM-Wiedergabe = kein Ruckeln.
Tja Rookie, ich weiß ja nicht, was Du wo wie wiedergeben möchtest, aber am PC solltest Du die Framerate mit der Monitorfrequenz synchronisieren oder umgekehrt.
Gruß
Thore
BTW: Ich bin auch von der Wiedergabe am Fernseher ausgegangen, da sieht man mal wieder wie wichtig eine detailierte Problembeschreibung ist :)
08/15 Photoshop-Bild mit dunkellila Hintergrundfarbe und pink Blindtext 10mm Verdana zweizeilig über den ganzen Banner. Und, ja es gab Farbgrisseln an den pink/lila Kanten auf dem TV ;-)
BTW. war ja nur ein Schnellschuss. Zur Auswahl von Farben für Banner, Texte etc. ist es IMHO besser sich ein Standbild zu schnappen und dort interessante Farbkombinationen mit der Pipette herauszupicken. Die Auswahl von Farbkombinationen aus der Palette des Zeichenprogramms meistens ziemlich daneben. Es wirkt auf dem TV oft zu künstlich.
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.
