Web-AR: Technische Herausforderungen und ein Blick in die nahe Zukunft

Die Themen Virtual, Mixed und Augmented Reality haben in den letzten Monaten viel an Popularität gewonnen. Insbesondere die "Pokemon Go"-App hat dazu beigetragen, dass Augmented Reality (AR) der breiten Masse bekannt wurde.

Ein schönes Beispiel für den gelungenen Einsatz von AR ist die App "1600" der White House Historical Association, die eine 1-Dollar-Note zum Leben erweckt.

Um insbesondere Printmedien mit dieser Technik zu "augmentieren" wäre es von großem Vorteil, wenn dafür keine native App (Android/iOS) nötig wäre. In vielen Fällen wird die Zielgruppe den Aufwand scheuen, erst eine App zu installieren, die ansonsten nicht benötigt wird. Der Einsatz von Augmented Reality im Marketing- oder Promotionkontext entfaltet also vermutlich noch nicht sein volles Potenzial. Damit der Medienbruch gelingt wäre es gut, die AR-Inhalte über den Browser anzusteuern – und das idealerweise ohne händische Eingabe der URL. Den Stand der Entwicklung zu "AR im Browser" möchte ich im Folgenden einmal betrachten.

Herausforderung Positionsbestimmung

Die Grundproblematik der AR lässt sich auf einen einzigen Faktor reduzieren: Position. Und zwar die Position (und Ausrichtung) der Kamera in Relation zur Umgebung. Um ein Objekt in korrekter Form über dem (Live-)Kamerabild zu platzieren, so dass es wirkt, als befinde es sich tatsächlich dort, benötigt die AR-Software Informationen über die Größe und die Rotation des zu zeichnenden Objektes. Dies wird in den meisten Fällen über sog. Marker realisiert.

Ein Marker kann ein Muster, ein Bild oder ein Objekt sein. Wichtig ist nur, dass er genügend eindeutige Merkmale enthält. Je komplexer der Marker desto höher die benötigte Rechenleistung, um diesen im Videostream zu erkennen. Einer Browser-Applikation steht in der Regel weniger Rechenleistung zur Verfügung als einer nativen Applikation. Das ist der Grund warum AR bisher fast ausschließlich nativ umgesetzt wird.

2D Barcode oder Matrix Markers

Die einfachste Art der Marker ist die Gruppe der sog. 2D Barcode Markers. Durch ihr fest definiertes Aussehen können sie sehr schnell und wenig rechenintensiv erkannt werden. Allen Markern gemein ist der breite Rahmen, der für die Erkennung notwendig ist. Die Anzahl der möglichen Marker hängt von den Dimensionen der Matrix und der eingesetzten Fehlererkennung ab. In der Regel werden 3x3, 4x4, 5x5 und 6x6 Matrizen verwendet. Eine 3x3 Matrix ohne Fehlererkennung bietet beispielsweise die Möglichkeit, 64 unterschiedliche Marker zu definieren, die unabhängig von ihrer Rotation erkennbar sind. Dieselbe Matrix mit Hamming-Fehlerkorrektur bietet nur 8 unterschiedliche Marker. Dafür ist die Wahrscheinlichkeit einer fehlerhaften Erkennung geringer. Um die Stabilität weiter zu erhöhen, ist es möglich, kombinierte Marker einzusetzen. Hierbei wird zusätzlich die räumliche Relation der Marker zueinander genutzt. Diese Marker sind für den Einsatz im Browser hervorragend geeignet.

Template Square Marker

Template Square Marker, oder auch nur "Square Marker" sind ähnlich aufgebaut wie die 2D Barcode Marker. Auch sie benötigen den Rahmen um die marker-spezifische Fläche. Der innere Teil des Markers kann fast beliebig gestaltet werden, auch Farben sind möglich. Wichtig ist hier, dass der Marker nicht drehsymmetrisch ist. Diese Marker werden oft als Matrix mit 8x8 oder 16x16 Elementen gespeichert. Je kleiner die Matrix, desto einfacher die Erkennung. Die Positionsbestimmung mit diesen Markern funktioniert im Browser (auch Mobile) relativ schnell und robust.

Natural Feature Tracking

In vielen Fällen sind die Barcodes oder Square Marker nicht ausreichend, um den gewünschten Effekt zu erzielen. Besonders im o. g. Marketing- oder Promotionkontext sollten Marker weniger auffällig sein und sich in die zu augmentierende Umgebung optisch einbetten.

Für diesen Einsatzbereich eignet sich das Natural Feature Tracking (NFT). Hierbei werden markante Punkte eines Bildes als Merkmale gespeichert. Diese Merkmale lassen sich dann im Videostream erkennen.

Dieses Verfahren ist leider noch nicht im Browser angekommen. Es gibt zwar schon experimentelle Implementierungen, jedoch hat es davon noch keine in eines der verfügbaren AR-Frameworks geschafft. Gerüchteweise sind erste Implementierungen noch für dieses Jahr geplant.

Markerloses Tracking

Native AR Frameworks sind da schon weiter. Besonders das vor Kurzem veröffentliche ARKit von Apple und Googles Konkurrenzprodukt ARCore zeigen eindrucksvoll, was auf mobilen Geräten möglich ist.

Mit ARKit und ARCore ist es möglich, Objekte ohne Marker in der Umgebung zu platzieren. Dies ist möglich, weil die Software zu jeder Zeit seine Position relativ zu und die Beschaffenheit der Umgebung kennt. Dieses Verfahren nennt sich Simultaneous Localization and Mapping (SLAM), zu Deutsch Simultane Lokalisierung und Kartenerstellung. Hierbei wird in Echtzeit die Umgebung gescannt und ein Modell erstellt, welches bei jeder Bewegung aktualisiert und angepasst wird. Zusätzlich wird bei jedem Update des Modells die wahrscheinliche Position des Smartphones innerhalb dieses Modells errechnet.

SLAM wird schon seit Jahren in der Robotik angewandt. Hier werden in der Regel mehrere Sensoren genutzt, um die Umgebung zu erfassen (z. B. Laser, Kameras, Sonar, IMU). Das Besondere an den Implementierungen von Apple und Google ist die Tatsache, dass hierfür nur eine einzelne Kamera (monocular SLAM) und unterstützend die IMU (Inertial Measurement Unit bzw. Inertiale Messeinheit) des Smartphones genutzt wird.

Gegenwart und Zukunft von WebAR

Die Gegenwart von WebAR verliert deutlich im Vergleich zu den aktuellen nativen Implementierungen. Dennoch lassen sich schon heute einfache Dinge auch im Web umsetzen.

Um das Web als AR-Plattform voranzubringen gibt es prinzipiell zwei Ansätze. Entweder die benötigten Algorithmen werden in JavaScript implementiert, oder die Browser bieten eine entsprechende API an. Ersteres hat den Nachteil, dass die Performance dieser Algorithmen in der Regel weit hinter nativen Implementierungen zurückbleibt. Das ist, wie weiter oben schon genannt, einer der Gründe, weshalb die Entwicklung auf dieser Schiene sehr langsam vorangeht. Der zweite Ansatz hat diesen Nachteil nicht, weil die Algorithmen hinter der Browser-API nativ implementiert wären. Das ArCore-Projekt bietet jetzt schon experimentelle Browser zum Download an, mit denen diese Funktionen getestet werden können. Bis diese API allerdings als Standard spezifiziert und in alle gängigen Browser implementiert wurde, wird voraussichtlich noch viel Zeit vergehen.

Projekte wie AR.js, chromium-webar und auch ArCore zeigen deutlich, dass das (AR-)Web in Aufbruchstimmung ist. Spätestens mit den ersten funktionierenden NFT Implementierungen wird der Browser zu einem ernst zu nehmenden AR-Medium.

Wir arbeiten aktuell übrigens gerade an einer WebAR-Umsetzung. Ich hoffe, darüber auch bald berichten zu können.