Warum ein drei Sekunden langes GIF schwerer wiegt als das Video, aus dem es stammt

Ein Format von 1989, das Bewegung nie gelernt hat

Die GIF89a-Spezifikation beschreibt eine Animation als Folge von Bildern mit einer Verzögerung dazwischen. Das ist das ganze Modell. Es gibt keinen Begriff einer fortdauernden Szene, keinen Vektor, der dem Dekoder sagt, dieser Pixelblock sei der aus dem letzten Bild, elf Pixel nach links verschoben. Moderne Videocodecs stecken fast ihre gesamte Raffinesse in genau diese Idee, und daher kommt fast ihre ganze Kompression: in einer Kopf-und-Schulter-Aufnahme wird die Wand hinter dem Kopf einmal übertragen und dann dreihundert Bilder lang nur referenziert. Ein GIF kann auf gar nichts verweisen.

Es gibt eine grobe Ausnahme, und sie lohnt das Wissen, denn sie erklärt, warum manche GIFs sich viel besser verhalten, als die Rechnung vorhersagt. Ein Bild darf als kleineres Rechteck an einem Versatz geschrieben werden, und Pixel, die sich seit dem vorigen Bild nicht geändert haben, dürfen transparent markiert statt gespeichert werden. FFmpeg — die Engine, die dieses Werkzeug benutzt — hat beides standardmäßig an. Bei einer Bildschirmaufnahme, in der ein Zeiger über ein stillstehendes Fenster wandert, ist das gewaltig: fast jedes Bild fällt auf nichts zusammen. Bei Kameramaterial, wo Sensorrauschen dafür sorgt, dass praktisch jedes Pixel leicht vom vorigen abweicht, spart es fast nichts. Dieser eine Unterschied erklärt, warum dieselben Einstellungen aus einer Bildschirmaufnahme ein 300-kB-GIF und aus einem freihändigen Handyclip ein 5-MB-GIF machen.

Die Rechnung — und wo die eine weiche Zahl steckt

Bytes ≈ Breite × Höhe × Bilder × b ÷ 8. Alles rechts ist exakt außer b, der Zahl der Bits, die jedes Pixel kostet, nachdem LZW seine Arbeit getan hat. Vor der Kompression ist jedes Pixel ein Index in eine Tabelle mit bis zu 256 Farben, beginnt also bei 8 Bit. Bei gerastertem fotografischem Material drückt LZW das meist auf 2 bis 5, weshalb es ehrlich ist, für eine erste Schätzung b = 3 zu nehmen und hinzunehmen, dass das Ergebnis auf etwa den Faktor zwei genau ist. Das klingt schlampig, bis man merkt: es ist derselbe Faktor zwei, den man beim Raten einer Videobitrate bekäme, und er genügt, um zu wissen, ob man eine Einstellung von seinem Limit entfernt ist oder vier.

Was das Werkzeug nicht tut, ist die Farben deines Clips zu messen. Eine hochwertige GIF-Kette läuft in zwei Durchgängen: einer baut eine Palette aus den tatsächlich vorhandenen Pixeln, der zweite bildet die Bilder darauf ab. Dieses Werkzeug läuft einmal durch, also werden die 256 Plätze aus einer generischen Tabelle gefüllt statt aus deinem Material. Die sichtbare Folge sind Streifen in Himmeln, Verläufen und Hauttönen sowie eine leichte Grobheit in dunklen Partien. Die unsichtbare Folge betrifft die Größe, und sie schneidet in beide Richtungen: eine generische Palette rastert stärker, und Rasterung fügt hochfrequentes Rauschen hinzu, das LZW hasst — was b nach oben drückt. Hat dein Clip von vornherein wenig Farben — eine Logo-Animation, ein Diagramm, ein Terminalfenster —, beißt nichts davon, und die Datei fällt weit unter die Schätzung.

Das Breitenfeld ist kein Größenfeld

Du tippst eine Breite; das Werkzeug rechnet die Höhe aus der Form des Clips. Bei einem 16:9-Querformatclip ergibt 480 dann 480 × 270 — 129 600 Pixel je Bild. Bei einem hochkant gehaltenen Handyclip ergibt dieselbe 480 aber 480 × 853, also 409 440 Pixel je Bild: mehr als dreimal so viele, bei derselben Zahl im selben Feld. Das ist der mit Abstand häufigste Grund für ein unerwartet riesiges GIF, und in der Oberfläche ist es unsichtbar, weil sie nur eine der beiden Dimensionen zeigt.

Die Korrektur passt in eine Rechenzeile. Soll ein Hochformatclip so viel wiegen wie ein 480 breiter Querformatclip, verlange 270 Breite: 270 × 480 sind wieder genau 129 600 Pixel. Allgemeiner: lege ein Pixelbudget je Bild fest statt einer Breite. Etwa 120 000 bis 150 000 Pixel je Bild sind für ein Chatfenster bei jeder Form bequem — das ist 480 × 270 quer, 270 × 480 hoch oder 360 × 360 quadratisch — und dann bleiben nur noch Bildrate und Dauer zu verhandeln.

Die Bildrate, die du verlangt hast, ist wahrscheinlich nicht die, die du bekommst

Das hier ist reine Formatarchäologie und erwischt jeden. Die GIF89a-Spezifikation speichert die Pause vor dem nächsten Bild in Hundertstelsekunden — das Feld gibt, in seinen eigenen Worten, „die Anzahl der Hundertstel (1/100) Sekunden an, die zu warten ist“. Es gibt keine feinere und keine gebrochene Einheit. Eine Bildrate ist also nur reproduzierbar, wenn 100 ohne Rest durch sie teilbar ist. Im Bereich, den dieses Werkzeug anbietet, heißt das 2, 4, 5, 10, 20 und 25 Bilder pro Sekunde — und sonst nichts.

Die Voreinstellung 12 gehört nicht dazu. Ein Zwölftel einer Sekunde sind 8,33 Hundertstel, und die Datei kann nur 8 oder 9 halten — das sind 12,5 oder 11,1 Bilder pro Sekunde bei der Wiedergabe, dein achtsekündiger Clip läuft also 7,68 oder 8,64 Sekunden. Wer ein Katzen-GIF ansieht, merkt nichts. Wer einen Countdown, ein Metronom, eine Rundenzeit oder eine Bildschirmaufnahme ansieht, in der du einen Timing-Fehler vorführst, merkt es sofort. Dreißig ist schlimmer: ein Dreißigstel sind 3,33 Hundertstel, die Datei hält 3, und die Wiedergabe kommt bei 33,3 Bildern pro Sekunde heraus — elf Prozent zu schnell. Wenn Timing zählt, nimm 10, 20 oder 25, dann läuft die Datei mit der Rate, die du verlangt hast.

Wenn die richtige Antwort kein GIF ist

Videogröße folgt einer anderen und viel freundlicheren Formel: Bytes = Bitrate × Sekunden ÷ 8. Acht Sekunden bei 800 kbit/s sind 800 kB, und 800 kbit/s kaufen einen völlig anschaubaren Clip in voller Auflösung mit dreißig Bildern pro Sekunde. Das ist fast sechsmal kleiner als das GIF aus denselben acht Sekunden bei einem Fünftel der Auflösung und einem Drittel der Bildrate — und das Video hat Ton, wenn du willst. Jede Messenger-App, jedes moderne Forum, jeder Ticket-Tracker und jedes soziale Netz spielen MP4 und WebM inline ab und wiederholen sie auf Wunsch. Die automatisch laufende Schleife, die man im Web heute „ein GIF“ nennt, ist in neun von zehn Fällen ein stummes MP4.

Heb das GIF also für die Fälle auf, in denen nichts anderes angenommen wird — und die gibt es wirklich: ein Wiki oder Ticketsystem, das nur Bildanhänge nimmt; ein Mailprogramm, das kein Video einbettet; ein altes Forum, dessen Editor einen Bild-Knopf hat und sonst nichts; eine README, die irgendwo gerendert wird und Video-Tags entfernt. Dort ist ein GIF keine nostalgische Wahl, sondern das einzige bewegte Bild, das die Reise übersteht. Überall sonst heißt Umwandeln in ein GIF: das Fünf- bis Zehnfache an Bytes zahlen, um den Ton, die meisten Farben und die Hälfte der Bilder zu verlieren.

Zwei Kleinigkeiten zu genau diesem Werkzeug

Es beginnt immer bei Sekunde null. Das Dauerfeld ist eine Obergrenze für die Ausgabe, kein verschiebbares Fenster — die acht Sekunden, die du bekommst, sind die ersten acht der Datei. Liegt der gewünschte Moment bei 0:42, schneide den Clip zuerst mit dem Schneidewerkzeug und gib das geschnittene Stück hinein. Diese Grenze umgeht man nicht mit einer größeren Dauer: das Maximum auf 30 zu stellen liefert die ersten dreißig Sekunden und ein GIF, das niemand irgendwo posten kann.

Und die angezeigte Größe wird in Einheiten von 1 048 576 Byte gemessen, aber MB genannt. Das ist ein Mebibyte im Etikett eines Megabytes — eine sehr alte und sehr verbreitete Schlamperei. Sie zählt hier nur an einer Stelle: ein als 10 000 000 Byte formuliertes Limit sind 9,54 der „MB“ dieses Werkzeugs, eine Datei, die es stolz mit 10,0 MB ausweist, liegt also fast ein halbes Megabyte darüber. Wenn du auf eine harte Obergrenze zielst, ziele fünf Prozent darunter und denk nicht mehr an die Einheiten.

Häufige Fragen

Kann ein GIF mehr als 256 Farben enthalten?

Über die ganze Datei ja, innerhalb eines Einzelbildes nein. Die Spezifikation erlaubt jedem Bildblock eine eigene lokale Farbtabelle, eine zwanzigbildrige Animation könnte also im Prinzip zwanzig Paletten benutzen und insgesamt mehrere tausend verschiedene Farben berühren. Jedes einzelne Bild bleibt aber auf 256 beschränkt, und eine lokale Tabelle kostet bei jedem Wechsel bis zu 768 Byte. In der Praxis bringt das bei Video sehr wenig, denn das Auge vergleicht benachbarte Bilder, und eine dazwischen wechselnde Palette erzeugt sichtbares Flimmern. Der größere Gewinn für einen GIF-Encoder sind nicht mehr Farben, sondern besser gewählte — eine Palette, die aus deinem tatsächlichen Material gemessen wurde, statt einer generischen Tabelle.

Mein GIF ist immer noch zu groß, und ich habe die Breite schon reduziert. Was jetzt?

Kürze als Nächstes die Dauer, dann die Bildrate, in dieser Reihenfolge. Dauer und Bildrate sind beide linear in der Bildzahl, bringen also pro Einheit dasselbe — aber ein kürzerer Clip ist fast immer ein besserer Clip, während eine niedrigere Bildrate unterhalb von etwa 8 Bildern pro Sekunde sichtbar degradiert, wo Bewegung als Diaschau zu lesen beginnt. Zwei Sekunden bei 10 Bildern pro Sekunde sind zwanzig Bilder, und zwanzig Bilder à 320 × 180 bei 3 Bit sind 432 kB. Passt selbst das nicht, lautet der ehrliche Schluss: der Inhalt komprimiert nicht. Prüfe, ob es Kameramaterial mit bewegtem Hintergrund ist, und wenn ja, beschneide eng auf das Wesentliche oder akzeptiere, dass es ein Video sein muss.

Behält das GIF den Ton?

Nein, und es kann es nie: das Format hat keine Tonspur und keinen Platz für eine. Das gehört laut gesagt, denn es ist ein stiller Fehlschlag — nichts warnt dich, die Umwandlung gelingt, und du merkst es, wenn du einen Clip postest, dessen ganzer Sinn ein Satz Dialog war. War der Ton das, was du teilen wolltest, ist die Antwort ein Video oder der Ton allein: diese Seite hat ein Werkzeug, das die Tonspur aus einer Videodatei als MP3, AAC oder WAV herauszieht, ohne das Bild anzurühren.

Warum wirkt mein GIF in den dunklen Partien körnig, obwohl das Video gut aussah?

Weil 256 Farben den ganzen Weg von Schwarz nach Weiß abdecken müssen und in einer dunklen Szene der Großteil deines Bildes sich in eine Handvoll davon drängt. Der Encoder überbrückt die Lücke durch Rasterung — er streut Pixel zweier vorhandener Farben, um eine dritte vorzutäuschen — und in flachen dunklen Flächen liest sich dieses Streuen als Korn. Es kostet außerdem Größe, denn Rasterung ist hochfrequentes Rauschen, und hochfrequentes Rauschen ist genau das, was LZW nicht komprimieren kann. Zwei Dinge helfen: den Clip vor der Umwandlung aufhellen oder beschneiden, damit weniger davon im gestauchten Bereich liegt, und Material mit flachen, klar getrennten Farben bevorzugen. Innerhalb des Formats lässt sich das nicht ganz beheben — ein Grund mehr, warum die Antwort oft ein Video ist.

Verlässt das Video meinen Rechner, während das läuft?

Nein. Die Umwandlung läuft in der Seite, in einer nach WebAssembly übersetzten FFmpeg-Fassung, und die Engine selbst wird von dieser Seite ausgeliefert statt aus einem fremden Netz — nicht einmal ihr einmaliger Download gibt deine Adresse also an Dritte. Eine sichtbare Folge solltest du erwarten: die erste Umwandlung einer Sitzung lädt rund 32 MB Engine und dauert einen Moment, jede weitere startet sofort. Und es gibt einen Test, der die Frage klärt, ohne uns zu glauben: Seite laden, Netz abschalten, Clip umwandeln. Funktioniert es weiter, wurde nichts hochgeladen.