Das könnte dich auch interessieren

Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung

Responsive Images: Erlöst uns ein Bildformat von all unseren Problemen?

    Responsive Images: Erlöst uns ein Bildformat von all unseren Problemen?

Bilder stellen uns im Responsive Web-Design vor viele Probleme: Mal ist die Bildgröße nicht klein genug, mal gibt es doppelte Requests an den Server. Die Syntax ist kompliziert oder es gibt unter Browern und Spezifikationen einfach keinen Konsens. Ein neues Dateiformat für Responsive Images soll all diese Probleme lösen.

Der neue Vorschlag von Yoav Weiss klingt interessant: Er schlägt einen Container um vorhandene Bildformate vor – ein neues Dateiformat. Das hätte mehrere Vorteile, wie er in seinem Blog zeigt:

  • Das Markup bleibt gleich, ein einfaches Element mit einer einzigen Bildquelle.
  • Automatische Tools könnten einfacher programmiert werden, da sich diese nur um die Bilder kümmern müssen, nicht jedoch um Markup oder Layout.
  • Bildänderungen, zum Beispiel beim Verkleinern oder Vergrößern des Browserfensters, könnten inkrementell heruntergeladen werden, ohne dass Daten geladen werden, die schon im Speicher vorhanden sind.
  • Webentwickler müssen nicht mit mehreren Versionen von Bilddateien arbeiten.

Wie würde solch ein Container für Responsive Images funktionieren?

Das Container-Format enthält interne Ebenen, die aus einem heutigen (Web-P, JPEG-XR) oder einem zukünftigen Bildformat besteht. Es benutzt Vergrößerungs- und Ausschneidevorgänge, um die Anwendungsfälle der unterschiedlichen Auflösungen und Art Direction unterstützen zu können. Der Decoder (also der Browser) kann dann nur die Ebenen (und damit die Bytes) runterladen, die er auch wirklich benötigt, um ein bestimmtes Bild anzuzeigen.

Natürlich muss ein Programm die Bilder entsprechend vorbereiten: Dieser Encoder nimmt das Originalbild und eine Beschreibung der Auflösungen und Art-Direction-Anwendungsfälle und gibt eine Ebene in der Größe aus, in der das Bild perfekt aussieht. Jede Ebene enthält aber nur den Unterschied der Bilddaten zur Ebene zuvor, auch in verschiedenen Auflösungen.

Art-Direction

Nehmen wir dieses Foto des US-Präsidenten bei einer Rede:

Komplettes Bild von Barack Obama, der eine Rede vor einer Fabrikationsstraße für Autos.
Container könnten viele Probleme bei Responsive Images lösen.

Die kleinste Ebene – ein Ausschnitt aus dem Original – würde so aussehen:

Ausschnitt aus dem kompletten Bild, der Obama in der Nahaufnahme zeigt.

Die Ebene darüber sieht so aus:

obama_layer2

Pixel. die in der vorhergehenden Ebene nicht vorhanden sind, werden normal dargestellt. Ansonsten gibt es nur eine graue Fläche, die die Differenz zum vorherigen Bild beschreibt. Entsprechend ist die dritte und letzte Ebene so gestaltet:

obama_layer3

Auflösungen

Wir wollen alle Daten für dieses hochauflösende Foto eines iPhones im Container unterbringen:

iPhone in voller Auflösung

Die erste Ebene enthält eine sehr verkleinerte Version des Bildes:

Die nächste Ebene nur die Unterschiede zu einer vergrößerten Version der vorhergehenden Ebene:

Und die dritte Ebene enthält die weiteren Unterschiede, nachdem die vorherige Ebene erneut vergrößert wurde:

res_switch.png_layer3.webp

Wie werden die Ebenen abgerufen?

Das ist tatsächlich noch eine der komplizierteren Angelegenheiten, da wir dazu in Browsern einen neuen Mechanismus benötigen. Der könnte sich aber an HTTP-Intervallen (Ranges) orientieren, wie sie bei Videos benutzt werden. Weiss schlägt dazu ein progressive-Attribut auf dem Bildelement vor.

  1. Wenn der Browser auf ein Bild mit dem Attribut „progressive“ stößt, lädt er ein vordefiniertes Intervall herunter, zum Beispiel in folgenden Größen:
    • Ein vorher festgelegtes kleines Intervall von zum Beispiel 8 Kilobyte
    • Einen Wert, den der Autor festlegt (beispielsweise als Wert des progressive-Attributs)
    • Einen heuristisch ermittelten Wert
    • Basierend auf einem „Manifest“
  2. Der Browser lädt dieses Intervall zu dem Zeitpunkt, zu dem er momentan das ganze Bild herunter lädt.
  3. In diesem ersten Intervall bekommt der Browser eine sogenannte „Offset Table Box“, in der verzeichnet ist, an welcher Byte-Stelle der Datei welche Ebene gespeichert ist: ein Inhaltsverzeichnis.
  4. Sobald das Seitenlayout feststeht, lädt der Browser die Ebene, das am Besten passt.

Dieses Vorgehen verursacht natürlich eine Reihe von HTTP-Anfragen (Requests), die im Fall von HTTP/1.1 für eine Verzögerung sorgen können. Optimiert werden könnte dieser Prozess, indem man ein „Manifest“ entwirft, in dem genau festgelegt wird, wo was ist – und zwar für alle Bilddateien. Dadurch braucht der Browser nicht auf gut Glück ein Inhaltsverzeichnis für jede einzelne Ressource zu laden, sondern bekommt ein Inhaltsverzeichnis für alle Dateien. Dieses Manifest kann dann von Built-Tools wie Grunt automatisiert und in CMS eingebaut werden – der Entwickler hätte damit vergleichsweise wenig zu tun.

Welche Nachteile hat dieser Ansatz?

Viele Teile von Browsern müssten dafür angepasst werden, das heißt: Standardisierung und Implementation könnten eine Weile auf sich warten lassen. Der Dekodierungs-Algorithmus benötigt durch das Hochskalieren und Verändern der Bilddaten einige Prozessor-Power, die möglicherweise auf die GPU abgewälzt werden kann.

Natürlich ist die Einführung eines neuen Dateiformates mit einem langen Prozess verbunden. Das hat nicht nur mit der schleppenden Umsetzung im Browser zu tun, sondern auch mit den Tools, die dieses neue Bildformat erstellen müssten.

Sollen wir jetzt die Markup-basierten Lösungen für Responsive Images vergessen?

Auf keinen Fall, da sie teilweise jetzt schon funktionieren und damit einen größeren Nutzen haben. Wie ihr Responsive Images noch einsetzen könnt, erfahrt ihr beispielsweise auch in diesem Artikel aus dem t3n Magazin Nr. 31. Ein neues Bildformat für Responsive Images aber könnte uns für die Zukunft helfen, eine einfache und nachhaltige Lösung zu schaffen. Und wie gefällt sie euch?

Finde einen Job, den du liebst zum Thema Webdesign, Administrator

Alle Jobs zum Thema Webdesign, Administrator
3 Reaktionen
Jpeg 2000
Jpeg 2000

JPEG2000 kann Teile davon schon.
Möglicherweise (wie schon bei mp3, h.264, h.265,... soweit ich weiss) waren deutsche Firmen oder Institute deutlich daran beteiligt.

Interessant am Pad oder Phone wäre halt das man nur das lädt was man braucht und anzeigen kann. Aber traffic-sparende Sites sind leider selten.

Antworten
Eric Eggert

Hallo Stefan,

nein, du legst fest ob du nur einen Ausschnitt anzeigen willst (der Art-Direction-Use-Case) und größere Bilder werden dann (wie du das beschreibst) progressiv nachgeladen. Der Clou an diesem Verfahren ist, dass die Daten, die in der kleineren Version da sind nicht noch einmal heruntergeladen werden sondern mit eingerechnet. Das wirkt sich dann aus, wenn du z.B. von iPad hoch auf quer drehst. Und für die reine Auflösungsvariante ist das graustufige diff wesentlich effizienter als selbst das große bild einzeln zu laden.

Antworten
Stefan
Stefan

Also irgendwie könnte ich mich damit anfreunden ein neues Dateiformat zu haben, was mir nicht so gefallen würde, dass nur ein Ausschnitt gezeigt wird bei der kleinen Version. Oder hab ich das falsch verstanden?

Was ich nicht verstehe, kann man nicht ein Format entwickeln das über das progressiv Verfahren arbeitet?
Der Browser kennt ja die Displaygröße, dann könnte man doch sagen, in dem Bildformat sind drei Versionen gespeichert so ähnlich wie bei Progressiv. Wenn eine kleine Displaygröße vorhanden ist wird eben eine kleine Bilddatei ausgegeben und stopp.

Dann hätte man vom gleichen Bild drei Versionen in einer Datei mit unterschiedlichen Dateigrößen. Auf die paar mehr Kbyte ist dann auch ges...
Da ja für jede Displaygröße nur die entsprechende Bildversion geladen wird.

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen