Echtes Motion Blur, oder: warum unsere Renders nicht nach Screen-Recording aussehen.

Miyovo baut Animationen für YouTube-Videos. Damit die im fertigen Video gut aussehen, reicht es nicht, dass sie im Browser flüssig laufen. Dieser Artikel zeigt an einem Detail, woran wir intern gerade arbeiten: echtes Motion Blur im Render. Er ist bewusst etwas nerdig. Wer nur wissen will, ob es funktioniert: Ja, es funktioniert.

Das Problem: scharf ist nicht immer schön

Wenn du eine Animation einfach vom Bildschirm abfilmst oder als Screen-Recording exportierst, ist jeder einzelne Frame gestochen scharf. Klingt gut, sieht aber bei schnellen Bewegungen schlecht aus: Ein Titel, der in wenigen Frames über den Bildschirm fliegt, springt sichtbar von Position zu Position. Das Auge nimmt das als Ruckeln oder Flackern wahr, den typischen „Videospiel-Look".

Eine echte Kamera macht das anders. Während der Belichtungszeit ist der Verschluss offen, und alles, was sich in dieser Zeit bewegt, verschmiert natürlich über den Frame. Genau dieses Verschmieren ist es, was Bewegung im Film weich und hochwertig wirken lässt. After Effects und Blender simulieren das deshalb, ein Browser tut es nicht. Wer Animationen für Video baut, muss es selbst lösen.

Der Shutter-Winkel: ein Konzept aus der Filmkamera

Wie stark Bewegung verschmiert, beschreibt man klassisch mit dem Shutter-Winkel. Die Zahl kommt von rotierenden Verschlussscheiben alter Filmkameras: 360 Grad heißt, der Verschluss ist die komplette Framedauer offen, 180 Grad die halbe. Die berühmte 180-Grad-Regel („Belichtungszeit = halbe Framedauer") ist der Kino-Standard, weil sie genau die Menge Blur erzeugt, die wir als natürlich empfinden. Bei 30 fps sind das 1/60 Sekunde Belichtung pro Frame.

Unser Renderer nimmt den Shutter-Winkel als Einstellung entgegen, genau wie eine Kamera. 180 Grad ist der Ausgangspunkt, für stilisierte Looks kann man höher oder niedriger gehen.

Wie wir es umsetzen: Subframes

Für jeden Frame des fertigen Videos rendern wir nicht ein Bild, sondern bis zu acht. Diese Subframes liegen zeitlich innerhalb des Belichtungsfensters, das der Shutter-Winkel vorgibt, symmetrisch um den Frame-Zeitpunkt verteilt. Anschließend werden sie zu einem einzigen Frame gemittelt. Was sich zwischen den Subframes bewegt hat, verschmiert dadurch exakt so, wie es eine Kamera mit dieser Belichtungszeit festgehalten hätte.

Das ist der ehrliche, teure Weg. Die Abkürzung wäre, fertige Frames nachträglich mit einem Bewegungsschätzer zu verrechnen, wie es manche Plugins tun. Das geht schneller, rät aber die Bewegung nur und produziert an Kanten und bei Überlagerungen sichtbare Artefakte. Da wir die Szene selbst abspielen, müssen wir nicht raten: Wir rendern die Zwischenzeitpunkte einfach wirklich.

Der Teufel im Detail: in linearem Licht mitteln

Beim ersten Test sahen die Bewegungs-Trails zu dunkel aus, und das hat einen schönen physikalischen Grund. Bilder sind in sRGB gespeichert, einem Farbraum, der Helligkeit verzerrt ablegt, damit dunkle Töne mehr Präzision bekommen. Eine Kamera aber summiert während der Belichtung Photonen, also echtes, lineares Licht. Mittelt man die sRGB-Werte direkt, wird die Mischung aus Hell und Dunkel systematisch zu dunkel, und bewegte helle Objekte ziehen schmutzige Schlieren.

Die Lösung: Jeder Pixel jedes Subframes wird vor dem Mitteln in linearen Farbraum umgerechnet, dort gemittelt und erst danach zurück nach sRGB gewandelt. Der Unterschied ist im Direktvergleich sofort sichtbar. Trails wirken danach wie belichtet statt wie übereinandergelegt.

Dasselbe Prinzip gilt für Transparenz. Viele Miyovo-Szenen sind Einblendungen mit Alphakanal, die du im Schnittprogramm über dein Footage legst. Halbtransparente Pixel dürfen beim Mitteln nicht naiv verrechnet werden, sonst franst der Blur an den Rändern aus. Auch dafür gibt es einen sauberen Weg (Stichwort: premultiplied Alpha), und den gehen wir.

Das Finish: FFmpeg und die Farbstich-Falle

Encodiert wird am Ende mit FFmpeg. Auch da steckte eine Überraschung: Ohne explizite Angabe interpretieren Player die Farben von HD-Video nach einem anderen Standard (BT.709) als FFmpeg sie standardmäßig schreibt (BT.601). Das Ergebnis ist ein leichter Grün- oder Rotstich, den man erst bemerkt, wenn man Render und Original nebeneinanderlegt. Wir setzen die Farbmetadaten deshalb explizit.

Für den Schnitt exportieren wir zwei Formate: MP4 in hoher Qualität für alles Deckende, und ProRes 4444 mit Alphakanal für Overlays, damit du Einblendungen direkt in Premiere, Resolve oder Final Cut über dein Material ziehen kannst.

Was das kostet, und warum wir es trotzdem tun

Acht Subframes pro Frame heißt grob achtfache Renderzeit. Das ist der Grund, warum wir solche Dinge gerade in internen Tests an echten Videoprojekten messen und optimieren, bevor Miyovo für alle aufgeht. Ein Beispiel: Das PNG-Encoding der Subframes war zwischenzeitlich der größte Zeitfresser im ganzen Render. Eine Encoding-Einstellung später war dieser Schritt mehr als doppelt so schnell, verlustfrei.

Der Anspruch dahinter ist einfach: Was aus Miyovo kommt, soll sich neben After-Effects-Material sehen lassen können, ohne dass du dafür After Effects lernen musst. Motion Blur ist eines von den Details, die niemand bewusst sieht, aber jeder spürt.

Beispiele ansehen oder auf der Startseite Early Access sichern. Fragen dazu gern an kontakt@miyovo.com.