{"id":619,"date":"2008-09-05T10:29:22","date_gmt":"2008-09-05T08:29:22","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/en\/?p=619"},"modified":"2019-07-24T10:45:26","modified_gmt":"2019-07-24T08:45:26","slug":"aufloesungsunabhaengiges-icon-design-teil-2","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/aufloesungsunabhaengiges-icon-design-teil-2\/","title":{"rendered":"Aufl\u00f6sungsunabh\u00e4ngiges Icon Design \u2013 Teil 2: Pixel vs. Vektoren"},"content":{"rendered":"

Im vorigen Teil<\/a> habe ich eine kurze Einf\u00fchrung in das Thema Aufl\u00f6sungsunabh\u00e4ngigkeit gegeben. Der vorliegende Teil erl\u00e4utert, welche technischen Beschr\u00e4nkungen das Erstellen von qualitativ hochwertigen, aufl\u00f6sungsunabh\u00e4ngigen Icons erschweren.
\n<\/p>\n

Der Raster-Ansatz<\/h3>\n

Bei Rastergrafiken (oder Bitmap-Grafiken) wird ein Bild als ein Raster von Pixeln beschrieben, in dem jeder Pixel einen anderen Farbwert besitzt. Eine Rastergrafik kann zwar schnell gezeichnet werden, aber es ist nicht m\u00f6glich, sie ohne Qualit\u00e4tsverlust hoch- oder herunterzuskalieren, da das Raster nur voneinander unabh\u00e4ngige Informationen \u00fcber einzelne Pixel, nicht jedoch ganzheitliche Informationen \u00fcber das zu skalierende Objekt enth\u00e4lt. <\/p>\n

Um Qualit\u00e4tsverluste beim Icon Design zu vermeiden, ist es Usus eine eigene Rastergrafik f\u00fcr jede Gr\u00f6\u00dfe zu erstellen, in der das Icon dargestellt werden soll. Typischerweise werden diese verschiedenen Iconversionen in einem gemeinsamen Dateiformat, wie .ICO (auf der Windows Plattform) oder .ICNS (auf der Mac Plattform) gesammelt. Der Programmierer der betreffenden Anwendung muss dann entscheiden, welche Version des Icons unter welchen Bedingungen dargestellt wird.<\/p>\n

Zu Windows XP-Zeiten enthielt eine typische .ICO-Datei verschiedene Icon-Versionen von 16×16, 32×32 und 48×48 Pixel (manchmal au\u00dferdem 24×24 Pixel). Mac OS X Tiger unterst\u00fctzte schon Gr\u00f6\u00dfen bis zu 128×128 Pixel, gesammelt in einer .ICNS-Datei. Um dem Problem bei Ger\u00e4ten mit hohen ppi-Zahlen zu begegnen, wurde das.ICO-Format in Windows Vista und Windows 7 so erweitert, dass es eine zus\u00e4tzliche 256×256 Pixel Iconversion unterst\u00fctzt.
\n\"\"
\nDoch damit nicht genug. In Mac OS X Leopard stellte Apple gigantische 512×512 Pixel Icons vor (z.B. f\u00fcr Front Row) und begr\u00fcndete deren Notwendigkeit mit der Aufl\u00f6sungsunabh\u00e4ngigkeit. Diese Art von Wettr\u00fcsten zeigt das Problem des einfachen Rastergrafik-Ansatzes: Diese Grafiken lassen sich einfach nicht gut skalieren und man braucht eine Menge verschiedener Gr\u00f6\u00dfen eines Icons, um alle existierenden Monitore bedienen zu k\u00f6nnen.<\/p>\n

Dazu gesellt sich folgendes Problem: ein 512×512 Pixel Icon braucht beinahe 800 KB des Hauptspeichers und ist selbst in komprimierter Form noch von erheblicher Gr\u00f6\u00dfe. In Zeiten von Rich Internet Applications (RIAs), in denen Ressourcen \u00fcber das Netzwerk zur Verf\u00fcgung gestellt werden, sollte man dies nicht au\u00dfer Acht lassen. Vielleicht \u00fcbertreibe ich hier ein bisschen, da diese enormen Gr\u00f6\u00dfen haupts\u00e4chlich f\u00fcr Desktop Icons \u2013 Icons, die eine Anwendung auf dem Desktop repr\u00e4sentieren \u2013 n\u00f6tig sind. Zumindest vorerst bleibt der Gro\u00dfteil der Icons innerhalb einer Anwendung kleiner als 64×64 Pixel. Auch wenn hier im Moment noch kein Problem auftritt, so werden wir doch in Zukunft damit konfrontiert werden. Mit wachsender Pixeldichte werden auch Nicht-Desktop-Icons gr\u00f6\u00dfer werden m\u00fcssen. Wenn eine Anwendung hunderte von Icons enth\u00e4lt und jedes dieser Icons in gro\u00dfen Abmesungen zur Verf\u00fcgung gestellt wird, so wird die Speicherauslastung zu einem bedeutenden Faktor \u2013 besonders im Kontext von Rich Internet Applications.<\/p>\n

Der Vektor-Ansatz<\/h3>\n

Der Einsatz von Vektoren ist ein g\u00e4ngiges Mittel zur Erstellung von Grafiken, die ohne Qualit\u00e4tsverlust auf verschiedene Gr\u00f6\u00dfen skalierbar sind. In einer perfekten Welt w\u00fcrden wir daher unsere Icons einfach in einem Bildverarbeitungsprogramm erstellen, das Vektorgrafiken unterst\u00fctzt (wie z.B. Photoshop, Illustrator oder Inkscape) und sie in ein bekanntes Vektorformat, wie SVG, PDF, XAML oder (das etwas weniger bekannte) JavaFX Script exportieren, welches seinerseits wiederum direkt in unsere Anwendung geladen und dort dargestellt werden kann.<\/p>\n

Langsame Zeichengeschwindigkeit<\/h4>\n

Das erste Problem ist aber, dass vektor-basierte Grafiken eine betr\u00e4chtliche Zeit brauchen, um direkt gezeichnet zu werden (d.h. da jedesmal, wenn die Grafik auf dem Bildschirm angezeigt werden soll, die Vektordaten in Pixelinformation konvertiert werden m\u00fcssen).
\nWarum ist es aber dann in modernen Computerspielen m\u00f6glich, super-realistische dreidimensionale Szenen mit dynamischen Licht- und Schatteneffekten sowie fl\u00fcssigen Animationen in Echtzeit zu rendern, w\u00e4hrend es unglaublich langsam ist, ein vektor-basiertes Icon zu rendern, das nur zwei Dimensionen nutzt, nicht animiert ist und seine Licht- und Schatteneffekte bereits \u201eeingemei\u00dfelt\u201c hat? Nun, moderne Spiele nutzen ausgiebig die M\u00f6glichkeiten moderner Grafik-Hardware, w\u00e4hrend die meisten Anwendungen auf Software-Frameworks basieren, die sich auf Abstraktionsschichten und R\u00fcckw\u00e4rtskompatibilit\u00e4t fokussieren und die Grafik-Hardware mit anderen Software-Frameworks teilen m\u00fcssen, ohne in der Lage zu sein, direkt alle M\u00f6glichkeiten der Grafik-Hardware zu nutzen. Im Detail ist das Ganze nat\u00fcrlich noch komplexer, aber ich m\u00f6chte hier nicht zu weit vom Thema abschweifen. Der Kernpunkt ist dieser: vektor-basierte Icons direkt zu zeichnen k\u00f6nnte in der Theorie unglaublich schnell ablaufen, ist aber in der Praxis \u00e4rgerlich langsam \u2013 sogar zu langsam, um derzeit eine brauchbare Alternative zu sein.<\/p>\n

Exportschwierigkeiten bei Vektor-Daten<\/h4>\n

Das zweite Problem ist, dass die Exportfunktionen der meisten hochmodernen vektor-basierten Programme relativ schlecht sind. Beliebte Iconeffekte, wie beispielsweise Schlagschatten oder Glanzeffekte werden beim Exportieren immer noch gerastert, was zu riesigen Zieldateien f\u00fchrt, die eine Menge Speicher ben\u00f6tigen und lange Ladezeiten verursacht und \u2013 was am l\u00e4stigsten ist \u2013 viele Grafiken enthalten, die immer noch nicht vektor-basiert sind. Das bedeutet, dass man beim Export eines Icons letztendlich eine volumin\u00f6se PDF-, SVG- oder XAML-Datei erh\u00e4lt, die eigentlich ohne Qualit\u00e4tsverlust unendlich skalierbar sein sollte, es aber nicht ist, da sie Rasterinformationen enth\u00e4lt. Weder eine neue Anwendung wie Microsoft\u00ae Expression\u00ae Blend, die sich aufl\u00f6sungsunabh\u00e4ngigen UIs verschrieben hat, noch ein Platzhirsch wie Adobe\u00ae Illustrator kommen bei anspruchsvollen visuellen Effekten komplett ohne Rastergrafiken aus. Bezogen auf Illustrator schien das JavaFX Export Plugin (damaliger Projektname: Nile<\/a>) vielversprechend, da es Schatteneffekte beim Export nicht rastert. Das Projekt befindet sich allerdings immernoch in den Kinderschuhen und leidet dementsprechend noch an einigen Kinderkrankheiten.<\/p>\n

Das Vektor-Raster-Dilemma<\/h4>\n

Ein weiteres Problem, das die anderen beiden Probleme fast in den Schatten stellt, ist, dass eine einzelne vektor-basierte Beschreibung eines Icons, niemals ein gestochen scharfes, makelloses und \u00e4sthetisches Ergebnis in allen Gr\u00f6\u00dfen, in denen das Icon dargestellt werden soll, liefern kann. Entweder erh\u00e4lt man ein wenig detailliertes Vektor-Icon, das in kleinen Gr\u00f6\u00dfen gut aussieht, aber langweilig wirkt, sobald es in gr\u00f6\u00dferen Abmessungen dargestellt wird, oder man hat ein sehr detailliertes Vektor-Icon, das in gro\u00dfen Abmessungen fantastisch aussieht, aber in kleinen Abmessungen nur noch als Pixelhaufen erscheint.<\/p>\n

\"\"<\/a>
\nIm n\u00e4chsten Teil<\/a> werde ich darauf eingehen, wie Centigrade mit diesen Einschr\u00e4nkungen umgeht und dennoch hochwertige Icons in verschiedenen Gr\u00f6\u00dfen daraus resultieren.<\/p>\n","protected":false},"author":5,"featured_media":0,"template":"","tags":[96,68,107,97,108],"class_list":["post-619","blog","type-blog","status-publish","hentry","tag-aufloesungsunabhaengigkeit","tag-icon-design-d","tag-mac-os-x-de","tag-rich-internet-applications-de","tag-windows-vista-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/5"}],"version-history":[{"count":0,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/619\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=619"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}