Paar Fragen zu Antialiasing

[Popov]

Wie Antialiasing funktioniert ist mir grob bekannt, auch wenn ich über reinschnuppern in Grundlagen nie hinausgekommen bin.

Was mich hier interessiert ist weniger wie man grättet, sondern wann. Nehmen wir an ich habe mitten auf einem weißen Formular einen schwarzen Kreis gezeichnet. Nun möchte ich die Ränder glätten. Die Frage ist wann mache ich es? Erstelle ich zuerst ein Maske von dem Kreis, ermittle anhand dessen die Übergänge und glätte so an den Rändern. Oder zeichne ich den Kreis rein, gehe die Zeichnung durch, überprüfe sie auf harte Farbunterschiede/Grenzen und glätte diese.

Also, wird jedes Objekt für sich geglättet oder die Zeichnung?

[jfheins]

Am einfachsten ist es wohl mit Prism und GDI+: Du stellst Antialiasing ein und beim Zeichnen wird automatisch geglättet.
Direkt danach würde ich es mit Fullsceen-AA probieren: Male auf ein Bitmap das
doppelt so groß ist wie die Zeichenfläche und beim Kopieren skalierst du das ganze.
Da man soclhe Zeichensachen ja eh oft in ein Bitmap Zeichnet und dann per BitBlt
in eine Paintbox kopiert, brauchst du nur das Bitmap größer dimensionieren,
alles größer Zeichnen und dann StretchBlt benutzen

Den Ansatz mit den individuellen Masken würde ich nicht empfehlen. Das könnte
zeimlich aufwändig werden (transparenz!) und wird wohl auch nicht so schnell sein.
(Heutige Spiele setzen ja fest alle auf 2x oder noch mehr FSAA..)

[Popov]

Die Idee hatte ich auch schon früher, alles größer machen und dann über Skalierung es weicher zu machen. Hier macht das System die Arbeit. Nur je nachdem kann es das System etwas belasten.

[Namenloser]

Also es gibt verschieden Arten von Antialiasing:

1. Man zeichnet alles um einen bestimmten Faktor größer, und skaliert hinterher runter. Das ist ziemlich einfach zu implementieren, aber die langsamste und speicherintensivste Variante. So ähnlich funktioniert aber klassisches Antialiasing bei Grafikkarten, nur dass hier optimiert wird, indem nur die Bildbereiche, die wirklich an Kanten liegen, mit einer höheren Auflösung gezeichnet werden. Vorteil: Funktioniert in allen Fällen und ist leicht umzusetzen. Nachteil: Speicherintensiv, und die Anzahl der Transparenz- bzw. Glättungsstufen ist von der Auflösung abhängig. Wenn man z.B. in vierfacher Größe zeichnet, sind es 16 Transparenzstufen (4*4 Samples pro Pixel).
   
2. Man glättet schon beim zeichnen – so machen es die meisten (behaupte ich einfach mal) 2D-Grafikbibliotheken. Wenn man z.B. eine Linie (mit einer bestimmten Dicke, also eigentlich ein gedrehtes Rechteck) zeichnet, kann man ja berechnen, zu wie viel Prozent diese ein bestimmtes Pixel von dieser Linie abgedeckt wird – entsprechend färbt man das Pixel nur zu diesem Anteil. Vorteil: Unbegrenzte Transparenzstufen, perfekte Qualität, geringer Speicherverbrauch. Nachteil: Wenn man immer wieder die gleiche Linie übereinanderzeichnet, war’s das irgendwann mit Antialiasing, weil die halbtransparenten Pixel sich aufaddieren.
   
3. Post-Processing. Gerade in letzter Zeit hört man immer wieder Post-Processing-Kantenglättung wie FXAA, wo in der Tat das fertige, nicht-antialiaste Bild einfach am Ende durchgegangen wird, und harte Kanten mithilfe spezieller Algorithmen gefunden und geglättet werden. Das lohnt sich vor allem, wenn sich sehr viele Objekte auf dem Bildschirm befinden, z.B. bei 3D-Spielen. Der Nachteil ist, dass die exakte Geometrie der Objekte zu diesem Zeitpunkt nicht mehr bekannt ist, und nur noch angenähert werden kann. Außerdem werden u.U. gewollte harte Kanten verwaschen. Außerdem dürften diese Algorithmen relativ kompliziert sein – wenn man nicht genau weiß was man tut, wird man die Treppenstufen nämlich nicht los, sondern man erhält lediglich verschommene Treppenstufen – ein ziemlich hässlicher Effekt.

[Medium]

NamenLozers dritter Ansatz wird meistens mit Filtern betrieben, die auch Vektorisierer einsetzen (z.B. Faltung mit Sobel-Operator; diskrete genäherte 1. Ableitungen im Allgemeinen). Das dadurch gewonnene Vektorfeld wird über die Längen auf ein Skalarfeld (letztlich praktisch ein Graustufenbitmap) reduziert, dass man als Parameter für einen Unschärfefilter einsetzt (z.B. als Radius für Gauss'sche Unschärfe). Auf GPUs ist dies ziemlich effizient umsetzbar, für die CPU ist das aber auch ein Knüller. Zusammen mit der Tatsache, dass die Ergebnisse auch bei guter Einstellung der Parameter immer eher mäßig aussehen, ist das hier mMn die schlechteste Alternative. Auch wenn sie zunächst lukrativ erscheint, da man an seinen bestehenden Zeichenroutinen nichts verändern müsste.

Das effizienteste ist definitiv das AA direkt beim Zeichnen, vor allem da der Bresenham-Algo ohnehin schon die dazu nötigen Werte "frei Haus" mit produziert. Da es dort auch Anpassungen für Nicht-Geraden gibt, wäre das ein guter Weg. Nachteil: Man müsste entweder eine fertige Lib nutzen die das bereits drauf hat (Graphics32 dürfte da ein netter Vertreter sein), oder selbst bauen. Alpha wird unproblematisch, wenn man es vormultipliziert (Pre-Multiplied Alpha), was die besseren Libs imho auch tun.

Vom Ergebnis her ist, zumindest im ganz allgemeinen Fall, das Oversampling (oder Supersampling) vorzuziehen. Es erfordert auch eher kleine Änderungen an bestehendem Code. So lange man nicht zig temporäre Bitmaps im Hintergrund vorhält (sondern idealerweise alles in Vektor- oder Sprachform bis zum finalen Zeichnen hat), und nicht arg über 16-fach geht, sollte das für aktuelle Systeme auch praktikabel sein. Jedoch nicht, wenn 60fps angestrebt werden
Hier liegt der Teufel eher im Mikromanagement bei Optimierungen, wie z.B. dem nur partiellen Neuzeichnen wenn sich nur Teilbereiche in einem bestehenden Bild ändern. Geschwindigkeitstechnisch alle Male lohnenswert, bedarf dann aber eines "Dran-Denkens" beim Aufbau des gesamten Grafik Subsystems. (So Dinge wie Nachrichten an überschneidend liegende Elemente sich neuzuzeichnen (in der richtigen Reihenfolge) - ein wenig wie es Windows auch bei seinen Controls in ähnlicher Weise macht - fallen mir da spontan ein.)


Letztlich ist da wohl die Frage wie du deine Grafiken bisher malst, was das dann für Bilder sind, und worin das Hauptaugenmerk besteht (Geschwindigkeit, "Schlankheit", Qualität um jeden Preis, ...)

[Namenloser]

Zitat von Medium:

Alpha wird unproblematisch, wenn man es vormultipliziert (Pre-Multiplied Alpha), was die besseren Libs imho auch tun.

Nein, ich habe selbst eine kleine Grafikbibliothek geschrieben und dabei premultiplied Alpha verwendet; das Problem hat damit überhaupt nichts zu tun.

Angenommen, du hast ein Quadrat mit einem Alpha-Wert von 50%. Jetzt zeichnest du darüber noch mal das selbe Quadrat, ebenfalls mit einem Alpha-Wert von 50%. Das Ergebnis ist ein rotes Quadrat mit einem Alpha-Wert von 75% (völlig korrekt). Das kannst du jetzt mehrfach wiederholen, bis das Quadrat vollständig opak ist. Und genau das passiert mit den halbtransparenten Randpixeln.

[Medium]

Aber ist das nicht der gewünschte und physikalisch korrekte Vorgang? Zwei halbtransparente Glasscheiben wirken doch z.B. so.

[Namenloser]

Ja, aber eben nur bei „wirklicher“ Transparenz, nicht bei Kantenglättung.

Wenn du in echt zwei farbige Stäbe direkt übereinanderlegst, werden die ja auch nicht breiter und kantiger

[Medium]

Hm, stimmt. Aber wer tut sowas schon

Zumindest in allen anderen Fällen, in denen nicht 2 Mal das selbe exakt an die selbe Stelle gezeichnet wird (was mein Kopf grad sehr überflüssig finden würde ^^), dürfte das Ergebnis von AA beim Zeichnen und AA via Oversampling vergleichbar sein

[MrBigmack]

Sorry für die dumme Frage, aber wie verfasst man einen neuen beitrag?