Animated GIF

Auf dem 31C3 hat Felix Mütze einen netten Vortrag gehalten über das Zombieleben von GIF. Auf seinem Blog hat er noch mehr zum Thema GIF gesammelt. Da ich bei den Anfängen von animated GIF dabei war haben wir uns danach unterhalten und ich habe versprochen noch ein paar Details aufzuschreiben. Hier also...

Animated GIF

Anfang 1995 hatten wir an der Universität Ulm eine Modelleisenbahn ins Netz gestellt. Die Besucher konnten den Zug im Kreis fahren lassen. Eine Kamera machte Bilder. Dafür musste man natürlich im Browser RELOAD drücken. Wir wollten, dass man ein Live-Video bekommt und haben nach Möglichkeiten gesucht, das mit der damaligen Technik zu machen. So sind wir auf GIF89a gestoßen (Konrad Froitzheim und ich). Ich habe ein animated GIF im Hex-Editor zusammengebaut. Dann das GIF den aktuellen Browsern vorgeworfen (XMosaic, Netscape Navigator) und es geschah: nichts, außer einem Bild. GIF wurde nur als Bildformat, nicht als Animation unterstützt.  

Noch schlimmer: Mosaic wollte alle Bilder komplett runterladen, bevor das erste Stück HTML angezeigt wurde. Das war offensichtlich nicht geeignet für Live-Video. Live-Video wollten wir nämlich als ein nicht endendes animated GIF vom HTTP-Server zum Browser schicken. Aber Netscape 1.1 zeigte ein interessantes Verhalten: progressives Dekodieren. Damals sehr innovativ. Immer wenn neue Daten ankamen, wurde mehr angezeigt. Damit war klar, dass die Softwarearchitektur für Animationen geeignet war. Man musste das nur noch Netscape klar machen.

Deshalb habe ich das Feedback Formular von Netscape auf die Webseiten der Modelleisenbahn kopiert, wo dann viele Besucher der Modelleisenbahn ihre Bitte um GIF-Animationen an Netscape (vor-)formuliert abgeschickt haben. Eines Tages meldete sich Scott Furman von Netscape und bat um mehr Informationen zum Thema animated GIF. Ich schickte ihm alles und ein paar Beispieldateien. Kurze Zeit später kam Navigator 2.0 mit animated GIF. Scott hatte dabei den Loop-Marker erfunden. Da GIF98a als Stream gedacht war und kein Loop enthielt, machte er den Loop-Marker als GIF-Comment. Das war wirklich eine coole Idee und hat überhaupt erst die ewig loopenden Icons ermöglicht. 

Live Video

Netscape's Marketing hatte wohl nichts davon erfahren, denn die großen Features waren Javascript, Framesets und Cookies. Von Animationen keine Rede. Aber sie gingen. Sowohl als Endlosschleife, als auch im Stream-Modus wo der Server die Verbindung hält und immer mehr Bilder schickt.
Ich schrieb also einen Videoserver, der den Stream von der Kamera in ein unendliches animated GIF kodierte (in C als nph-cgi). Nach dem ersten Vollbild, suchte der Videoserver die geänderten Bereiche, kodierte das Bild nur für diese Rechtecke neu und schickte es auf die Leitung. Der URL des Streams verpackt als <img src=> im HTML zeigte tatsächlich ein Video. 

Die Besucher der Modelleisenbahn konnten etwa im Sekundentakt sehen, wie der Zug um das Oval "hopste". Unglaublich, dass es dann plötzlich einfach so klappte. Das erste Live-Video im Web. Und für lange Zeit das einzige echte "live" Video im Web überhaupt.

Dann kam PNG und ich hatte damals Kontakt mit Thomas Boutell. PNG ging ja durch viele Revisionen, aber im Thomas wollte keine Animationen einbauen. "Erst machen wir das Bildformat. Wenn sich das durchgesetzt hat, dann Animationen". Er hatte befürchtete, dass die Animation es komplizierter machen würde und so PNG schaden würde. Vielleicht hatte er Recht. Aber am Ende hat genau die Animation gefehlt, um GIF abzulösen. Ein Browser-Entwickler, der parallel zu animated GIF jetzt PNG einbauen will, fragt sich eher, was er mit den Codestellen machen soll, wo GIF noch mehr Bilder liefert, PNG aber nicht. Also muss er sie sinnvoll leer lassen. Wenn er dann nochmal den Code anfassen muss, weil jetzt doch PNG Animationen kommen sollen, muss man die stillgelegten Stellen wieder umbauen. Noch schlimmer, wenn die PNG Animation MNG heißt und einen anderen MIME-Type hat. Dann muss man neben PNG noch einen fast identischen Dekoder integrieren, der aber jetzt doch so wie GIF funktioniert. Das ist alles etwas mühsam. Jedenfalls mühsamer, als wenn man gleich parallel zu aGIF den aPNG Code eingebaut hätte. 

Klar war aber auch, dass GIF mit den Farbpaletten nicht ideal für Fotos und Kamerabilder ist. Deshalb lag es nahe, das Animationsprinzip von GIF auf JPEG anzuwenden. Eigentlich ja ganz einfach. GIF hat einen Header, dann ein Vollbild, dann Teilbilder, die per Koordinate irgendwo im Screen einen Teil überdecken können. Also eine differentielle Kodierung ohne weitere Optimierung, aber viel besser, als immer Vollbilder zu übertragen. 

Animated JPEG

JPEG ist ganz ähnlich strukturiert wie GIF (und PNG). Der Kompressionsalgorithmus ist ganz anders. Aber beide bestehen aus sogenannten Chunks (Datenpaketen), die hintereinander gehängt werden. Der Header ist ein Datenpaket oder auch mehrere. Die Daten, die ein Bild ergeben sind in einem Datenpaket. Kommentare, Loop-Marker, Geo-Koordinaten, Datum sind alles einzelne Datenpakete. Bei animated GIF kommen nach dem ersten Bild-Paket noch weitere Bild-Pakete. Die haben alle eine Größe und eine Koordinate und legen sich quasi über die vorherigen Bilddaten. Zusammen mit dem Delay ergibt das eine Animation.

Genauso wäre es bei JPEG. Normalerweise ist bei JPEG ein Header, dann ein Vollbild, dann Schluss. Würde man nach dem Vollbild weitere Chunks mit Teilbildern schicken, jedes mit einem Delay, Koordinate und Größe, dann wäre die Animation schon fertig. Noch ein Loop-Marker und fertig ist die Truecolor-Animation.

Das haben wir programmiert (Michael Merz, Holger Bönisch und ich) und Tom Lane angeboten, der den JPEG-Code verwaltete. Leider hat er ihn abgelehnt mit der Begründung, dass MPEG für Animationen vorgesehen ist. Da hat er recht. Aber das hätte man von GIF auch behaupten können. Hat man aber nicht. Ein MPEG-Dekoder ein unglaublich aufwändiges und erstaunlich empfindliches Stück Software. Kein Browserhersteller hat MPEG direkt integriert. Das kam immer nur als Plugin oder mit Quicktime. Viele Movies waren inkompatibel und brachten den Browser zum Absturz. Als Microsoft den Browsermarkt dominierte haben sie es auch nicht geschafft, Movies auf einfache Art in Seiten einzubinden. Microsoft ist so spektakulär gescheitert, dass Flashplayer mit einer Konkurrenztechnologie für lange Zeit Truecolor-Animationen dominierten. 

Es hat 15 Jahre gedauert hat, bis man endlich ein MPEG per <video src=> einfach einbinden konnte, ohne Flash-Player und viel Aufwand. Wäre damals JPEG parallel zu aGIF als Animationsformat erweitert worden, dann hätten wir seit 1997 eine einfache Art, Truecolor-Animationen zu machen. GIF wäre höchstens noch für kleine animierte Icons zuständig, animated JPEG für "kurze" Truecolor-Animationen mit anständiger Komprimierung und richtige Video-Codecs für ganze Filme mit der besten Komprimierung. 

Eigentlich wäre animated GIF durch animated JPEG abgelöst worden. Und eigentlich wäre das auch heute noch eine gute Idee. 

Hier mein erstes im Hexeditor gebautes animated GIF mit dem ich damals Browser getestet habe. Wenn es eine 1 zeigt, dann kann der Browser kein animated GIF. Bei 2 kann er. 

Heute ist es gar nicht so einfach die 1 zu sehen.

Das wahrscheinlich erste GIF-Movie. Zumindest das erste nach der Wiederentdeckung von animated GIF. Auf jeden Fall das erste, das von einem Web-Browser dargestellt wurde.

Ich brauchte was Längeres, als die kleinen Testbilder, um die Streaming-Fähigkeit von Browsern zu testen. Erstellt durch Copy-Paste jedes einzelnen Frames.




Ein Bild der Modelleisenbahn. Von rechts nach links: PC für Zugsteuerung, Kamera, Mac mit Videoserver:

Die zugehörige Website (klassisches Web 1.0 Design): 

happy_streaming()

Nebenbei bemerkt: 300.000 Besucher bis Mai 1997. Schon eine gute Zahl für damals.