Sie verwenden derzeit einen Browser, der nicht mehr unterstützt wird und bei dem es daher zu Darstellungsfehlern kommen kann. Wechseln sie den Browser, um ein noch schöneres Design zu erleben.

Cookies helfen uns bei der Bereitstellung unserer Dienste. Durch die Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies setzen. Mehr erfahren.

Close

Über den Tellerrand geschaut

Auflösungsunabhängiges Icon Design – Teil 2: Pixel vs. Vektoren

Thomas Immich

Im vorigen Teil habe ich eine kurze Einführung in das Thema Auflösungsunabhängigkeit gegeben. Der vorliegende Teil erläutert, welche technischen Beschränkungen das Erstellen von qualitativ hochwertigen, auflösungsunabhängigen Icons erschweren.

Der Raster-Ansatz

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öglich, sie ohne Qualitätsverlust hoch- oder herunterzuskalieren, da das Raster nur voneinander unabhängige Informationen über einzelne Pixel, nicht jedoch ganzheitliche Informationen über das zu skalierende Objekt enthält.

Um Qualitätsverluste beim Icon Design zu vermeiden, ist es Usus eine eigene Rastergrafik für jede Größe 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.

Zu Windows XP-Zeiten enthielt eine typische .ICO-Datei verschiedene Icon-Versionen von 16×16, 32×32 und 48×48 Pixel (manchmal außerdem 24×24 Pixel). Mac OS X Tiger unterstützte schon Größen bis zu 128×128 Pixel, gesammelt in einer .ICNS-Datei. Um dem Problem bei Geräten mit hohen ppi-Zahlen zu begegnen, wurde das.ICO-Format in Windows Vista und Windows 7 so erweitert, dass es eine zusätzliche 256×256 Pixel Iconversion unterstützt.

Doch damit nicht genug. In Mac OS X Leopard stellte Apple gigantische 512×512 Pixel Icons vor (z.B. für Front Row) und begründete deren Notwendigkeit mit der Auflösungsunabhängigkeit. Diese Art von Wettrüsten zeigt das Problem des einfachen Rastergrafik-Ansatzes: Diese Grafiken lassen sich einfach nicht gut skalieren und man braucht eine Menge verschiedener Größen eines Icons, um alle existierenden Monitore bedienen zu können.

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öße. In Zeiten von Rich Internet Applications (RIAs), in denen Ressourcen über das Netzwerk zur Verfügung gestellt werden, sollte man dies nicht außer Acht lassen. Vielleicht übertreibe ich hier ein bisschen, da diese enormen Größen hauptsächlich für Desktop Icons – Icons, die eine Anwendung auf dem Desktop repräsentieren – nötig sind. Zumindest vorerst bleibt der Großteil 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ößer werden müssen. Wenn eine Anwendung hunderte von Icons enthält und jedes dieser Icons in großen Abmesungen zur Verfügung gestellt wird, so wird die Speicherauslastung zu einem bedeutenden Faktor – besonders im Kontext von Rich Internet Applications.

Der Vektor-Ansatz

Der Einsatz von Vektoren ist ein gängiges Mittel zur Erstellung von Grafiken, die ohne Qualitätsverlust auf verschiedene Größen skalierbar sind. In einer perfekten Welt würden wir daher unsere Icons einfach in einem Bildverarbeitungsprogramm erstellen, das Vektorgrafiken unterstützt (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.

Langsame Zeichengeschwindigkeit

Das erste Problem ist aber, dass vektor-basierte Grafiken eine beträchtliche 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üssen).
Warum ist es aber dann in modernen Computerspielen möglich, super-realistische dreidimensionale Szenen mit dynamischen Licht- und Schatteneffekten sowie flüssigen Animationen in Echtzeit zu rendern, während es unglaublich langsam ist, ein vektor-basiertes Icon zu rendern, das nur zwei Dimensionen nutzt, nicht animiert ist und seine Licht- und Schatteneffekte bereits „eingemeißelt“ hat? Nun, moderne Spiele nutzen ausgiebig die Möglichkeiten moderner Grafik-Hardware, während die meisten Anwendungen auf Software-Frameworks basieren, die sich auf Abstraktionsschichten und Rückwärtskompatibilität fokussieren und die Grafik-Hardware mit anderen Software-Frameworks teilen müssen, ohne in der Lage zu sein, direkt alle Möglichkeiten der Grafik-Hardware zu nutzen. Im Detail ist das Ganze natürlich noch komplexer, aber ich möchte hier nicht zu weit vom Thema abschweifen. Der Kernpunkt ist dieser: vektor-basierte Icons direkt zu zeichnen könnte in der Theorie unglaublich schnell ablaufen, ist aber in der Praxis ärgerlich langsam – sogar zu langsam, um derzeit eine brauchbare Alternative zu sein.

Exportschwierigkeiten bei Vektor-Daten

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ührt, die eine Menge Speicher benötigen und lange Ladezeiten verursacht und – was am lästigsten ist – viele Grafiken enthalten, die immer noch nicht vektor-basiert sind. Das bedeutet, dass man beim Export eines Icons letztendlich eine voluminöse PDF-, SVG- oder XAML-Datei erhält, die eigentlich ohne Qualitätsverlust unendlich skalierbar sein sollte, es aber nicht ist, da sie Rasterinformationen enthält. Weder eine neue Anwendung wie Microsoft® Expression® Blend, die sich auflösungsunabhängigen UIs verschrieben hat, noch ein Platzhirsch wie Adobe® Illustrator kommen bei anspruchsvollen visuellen Effekten komplett ohne Rastergrafiken aus. Bezogen auf Illustrator schien das JavaFX Export Plugin (damaliger Projektname: Nile) vielversprechend, da es Schatteneffekte beim Export nicht rastert. Das Projekt befindet sich allerdings immernoch in den Kinderschuhen und leidet dementsprechend noch an einigen Kinderkrankheiten.

Das Vektor-Raster-Dilemma

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 ästhetisches Ergebnis in allen Größen, in denen das Icon dargestellt werden soll, liefern kann. Entweder erhält man ein wenig detailliertes Vektor-Icon, das in kleinen Größen gut aussieht, aber langweilig wirkt, sobald es in größeren Abmessungen dargestellt wird, oder man hat ein sehr detailliertes Vektor-Icon, das in großen Abmessungen fantastisch aussieht, aber in kleinen Abmessungen nur noch als Pixelhaufen erscheint.


Im nächsten Teil werde ich darauf eingehen, wie Centigrade mit diesen Einschränkungen umgeht und dennoch hochwertige Icons in verschiedenen Größen daraus resultieren.

Möchten Sie mehr zu unseren Leistungen, Produkten oder zu unserem UX-Prozess erfahren?
Wir sind gespannt auf Ihre Anfrage.

Corporate Experience Manager
+49 681 959 3110
Kontaktformular

Bitte bestätigen Sie vor dem Versand Ihrer Anfrage über die obige Checkbox, dass wir Sie kontaktieren dürfen.
  • Saarbrücken

    Science Park Saar, Saarbrücken

    Standort Südwest

    Hauptsitz Saarbrücken
    Centigrade GmbH
    Science Park 2
    66123 Saarbrücken
    Deutschland
    Saarland
    Auf der Karte

    +49 681 959 3110

    +49 681 959 3119

  • Mülheim an der Ruhr

    Games Factory Mülheim an der Ruhr

    Standort Nordwest

    Geschäftsstelle Mülheim
    Centigrade GmbH
    Kreuzstraße 1-3
    45468 Mülheim an der Ruhr
    Deutschland
    Nordrhein-Westfalen
    Auf der Karte

    +49 208 883 672 89

    +49 681 959 3119

  • Haar · München

    Haar / München

    Standort Süd

    Geschäftsstelle München
    Centigrade GmbH
    Bahnhofstraße 18
    85540 Haar · München
    Deutschland
    Bayern
    Auf der Karte

    +49 89 20 96 95 94

    +49 681 959 3119

  • Frankfurt am Main

    Frankfurt am Main

    Standort Mitte

    Geschäftsstelle Frankfurt
    Centigrade GmbH
    Kaiserstraße 61
    60329 Frankfurt am Main
    Deutschland
    Hessen
    Auf der Karte

    +49 69 241 827 91

    +49 681 959 3119