PNGs und JPGs sind zwei beliebte Bildformate im Internet - das eine kann Transparenz, das andere komprimiert Bilder gut. Das Problem ist, man kann es nicht kombinieren.
So die Theorie, und eigentlich stimmt es auch. Aber was macht man, wenn man wie im ECCO-Projekt schöne große freigestellte Zoom-Bilder auf elegante Bühnen stellen will? 4MB oder gar 12MB dem Nutzer zumuten? Wohl kaum.
Eine Lösung musste her, der Screen sah einfach zu gut aus, als dass er an der Technik scheitern durfte. Und wir fanden eine Lösung: Wir schnitten den inneren Teil aus jedem Schuh und zerteilten ihn in Rechtecke, die komplett opaque waren und sich damit als JPG gut komprimieren ließen. Der Rest, die halbtransparente Hülle, blieb in einem PNG, das nun nicht mehr viel Bildmaterial enthält und dadurch ebenfalls klein ist.
Das klingt total wild, reduziert aber den Platzbedarf tatsächlich um mehr als zwei Drittel, z.B. von 970KB auf 250KB. Bei größeren Bildern sogar im Verhältnis noch besser. Es lohnt sich.
Und so läuft das Verfahren im Detail, und zwar komplett automatisiert:
Zuerst wird das Ausgangsbild auf die vorgegebenen Minimal- und Maximalgröße für Zooms heruntergerechnet. Dies geschieht mithilfe der Thumbnail-Factory des Commerce-Frameworks, die mit nur wenigen Zeilen Code komprimieren, herunterskalieren, croppen, auf Hintergründe stellen und das Format wechseln kann.
Nun wird das Zoombild in Kacheln zerteilt und auf Transparenz untersucht. Kacheln, die ausschließlich aus vollständig opaquen Pixeln bestehen, können in das JPG verschoben werden. Damit die Anzahl der späteren Requests reduziert wird, werden dabei nicht mehrere JPGs erzeugt, sondern nur eins mit denselben Maßen wie das Zoom-PNG.
Hier das Ergebnis nach dem Kacheln und Verschieben:
Als weiterer Analyseschritt werden zusammenhängende Kacheln gesucht und Rechtecke gebildet. Für jedes dieser Rechtecke wird ein absolut positioniertes DIV mit dem JPG im Hintergrund erzeugt. Das JPG stellt dabei ein Sprite dar, jedes DIV zeigt einen Ausschnitt. Ach ja, und das PNG natürlich noch dazu, und schon wird ein Schuh draus.
Die Lösung existiert als wiederverwendbarer Java-Code unter Verwendung von JAI, das Verfahren ist aber technologieunabhängig, es gibt also keine Ausreden mehr für große, transparente Bilder.
Moin! Das heißt, am Ende hat man 50 (<-Blindtext) DIVs mit ein und demselben JPG als Hintergrund, das aber jeweils anders positioniert ist?
Und: Hast Du einen Link zum Code? :-)
Nachteil bei dieser Methode ist allerdings, dass für die zerschnippelten Bilder grob geschätzt 80 HTTP-Requests an den Server gesendet werden, was den Zeitgewinn durch die Volumenreduktion wieder aufheben wird. Und überhaupt, 80 absolut positionierte DIVs mit Slices?! Warum nicht gleich Tabellenlayout?
Eleganter wäre gewesen, im Vordergrund ein transparentes GIF oder PNG mit Lockmaske zu haben und im Hintergrund ein (in Zahlen: 1) JPG. Mit Layern. Das geht seit ungefähr 1998. Aber das wisst Ihr sicherlich. Warum habt Ihr es nicht so gemacht?
Das mit den Slices erscheint mir wie die Lösung von jemanden, der nur Slices von Photoshop und Dreamweaver kennt, was irgendwie zu SinnerSchrader als professioneller Agentur nicht passen will. Könnt Ihr mir helfen, dieses Rätsel zu aufzulösen? Warum habt Ihr Euch also wirklich für diese Loch-ins-Knie-bohren-Lösung entschieden?
Vielen Dank für die Anmerkung.
Das ist dann wohl falsch rübergekommen. Wir verwenden genau 1 PNG und genau 1 JPG. Die Kacheln sind nur DIVs auf ein und demselben JPG. Also nur 2 Requests.
Nur ein JPG-Element im Hintergrund geht aufgrund der Form nicht, weil wir wiederum dahinter eine Hintergrundgrafik haben, die dann mit Weiß abgedeckt würde.
Ich denke daher, dass es bereits optimal ist, unter der gegebenen Voraussetzung, dass der Hintergrund nicht mit dem JPG verschmolzen werden durfte.
Ah, dann bin ich ja beruhigt. Schön, dass hier mal wieder etwas Leben einkehrt im Jahr 1 nach Jens. ;)
Ja, passieren tut so einiges, ich muss nur mehr dran denken, das hier auch zu bloggen. Aber ich hab schon wieder Themen :-)