Podcast

twwwr

INNOQ Digital Art 2018

Macht INNOQ jetzt auch Kunst? In dieser Episode geht es um den Twwwr, ein Medienkunst-Projekt des K√ľnstlers Matthew Plummer-Fernandez, an dem unser Kollege Simon K√∂lsch mitgewirkt hat. Im Gespr√§ch mit Lucas Dohmen erkl√§rt Simon, wie es dazu kam und wie dieses Kunstwerk technisch umgesetzt wird. Unter anderem geht es um Gesichtserkennung und darum, wie aus Gesichtern 3D-Modelle werden. Wie sieht die Architektur f√ľr den Twwwr aus und welche Hardware kommt zum Einsatz?

Zur√ľck zur Episode

Transkript

Lucas Dohmen: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ-Podcast. Heute habe ich zu Gast den Simon. Hallo Simon!

Simon Kölsch: Hallo Lucas!

Lucas Dohmen: Wir werden heute √ľber den Twwwr sprechen, das ist ein Kunstprojekt, in dem der Simon mitgewirkt hat. Und bevor wir damit anfangen, magst du dich ganz kurz vorstellen und sagen, wer du bist und was du bei INNOQ so machst?

Simon Kölsch: Ja. Hallo, ich bin der Simon, ich arbeite bei INNOQ ganz regulär, wie fast alle anderen Kollegen auch, als Senior Consultant und bin da ganz normal in Projekten tätig. Ganz oft mit einem Infrastruktur- oder Security-Hintergrund.

Lucas Dohmen: Ich hatte eben schon erwähnt, dass es sich ein bisschen um ein Kunstprojekt handelt, was hat denn INNOQ mit Kunst zu tun?

Simon K√∂lsch: Die Frage ist ja durchaus berechtigt, die kann man stellen. Vielleicht muss man da ein bisschen weiter vorne anfangen. INNOQ gibt es jetzt seit knapp 17 Jahren. Und dementsprechend ist auch das Logo, die Bildsprache und vielleicht auch ein bisschen die optische Aufmachung. Wir haben ja ab und zu mal die Artikel, die wir haben, gesammelt in einem kleinen Buch ver√∂ffentlicht, da ist eine Cover-Gestaltung dabei. Und man hat sich √ľberlegt, das mit einer Agentur zusammen nochmal neu zu erarbeiten. Und im Rahmen von dieser Corporate-Identity-Vorbereitung hat man gesagt, es w√§re vielleicht interessant, eine Kooperation mit einem Medienk√ľnstler zu suchen, der zumindest in der gleichen Richtung mit der Technologie arbeitet, und das entstandene Material dabei irgendwie zu verwenden. Und dann kann man sich √ľberlegen, wie man so ein Medien-Kunstprojekt f√∂rdert, zum einen mit Geld oder indirekt mit Arbeitszeit. Und in dem Fall war das tats√§chlich eine Zusammenarbeit, beziehungsweise die Umsetzung eines Kunstprojektes von Matthew Plummer Fernandez, der digitale Kunstwerke eigentlich schafft und dabei habe ich ihn eigentlich in den letzten knapp 3 Monaten unterst√ľtzt.

Lucas Dohmen: Also, du warst da technische Unterst√ľtzung f√ľr den K√ľnstler?

Simon Kölsch: Genau, wir haben einen Teil von diesem Projekt technisch umgesetzt.

Lucas Dohmen: Magst du ein bisschen was zu Matthew erz√§hlen, was der sich √ľberlegt hat und was vielleicht auch der Hintergrund ist von dem Twwwr?

Simon K√∂lsch: Matthew macht unter anderem, wie bereits gesagt, digitale Kunstwerke, wir werden da am besten seine Homepage verlinken, in den Shownotes, da kann man sich das auch einfach nochmal ein bisschen angucken, das macht dann wesentlich mehr Sinn. Man muss vielleicht zu dem Projekt, das wir jetzt umgesetzt haben, mit dem Namen Twwwr, geschrieben √ľbrigens, wenn man das sp√§ter in der URL aufrufen m√∂chte, mit 9 ‚ÄöW‚Äė, sagen: Da gab es mehr oder weniger ein Vorg√§ngerprojekt, in dem Matthew zusammen mit JODI, das ist ein relativ bekanntes K√ľnstlerkollektiv, aus einem Niederl√§nder und jemandem aus Br√ľssel, glaube ich, die haben schon mal 3D-Modelle im Internet gescraped, also einfach gesammelt, was die Leute so eingescannt haben, also haupts√§chlich 3D-Scans, und offen zur Verf√ľgung gestellt haben, die haben das eingesammelt und daraus neue Modelle erzeugt. Das hei√üt ganz viele verschiedene Objekte zu einem neuen Objekt arrangiert, indem sie die aneinander gesteckt haben. Und bei Twwwr ist die Idee, dass man eine Art endlos wachsenden Pfahl hat und diese 3D-Modelle aus dem Internet dazu verwendet, diesen Turm periodisch √ľber einen langen Zeitraum wachsen zu lassen. Und das in etwa etwas entsteht, das ein bisschen an eine Social-Media-Wall oder Timeline oder √§hnliches erinnert. Das ist die eine Komponente dabei. Und die andere Komponente ist die Idee, dass man als Besucher des Kunstwerkes, sei es in einer Ausstellung, √ľber die wir sp√§ter noch ein paar Worte verlieren k√∂nnen, sei es √ľber die Homepage, ein Teil davon werden kann, indem man mal so ein Gesicht fotografiert und das verfremdet und dieses dann in diesem Tower-√§hnlichen Totempfahl auftaucht.

Lucas Dohmen: Genau, das ist ein bisschen schwer sich das vorzustellen, ich w√ľrde einfach vorschlagen, dass man sich das an dieser Stelle mal anschaut. Wir haben den Link zu dem Twwwr mit ganz vielen 'W‚Äôs in den Shownotes. Du hast ja gesagt, du bist normalerweise ganz normaler Consultant bei INNOQ, hat sich das Projekt jetzt unterschieden von dem, was du sonst machst oder war das quasi normales Projektgesch√§ft f√ľr dich?

Simon K√∂lsch: Ich w√ľrde ja gerne sagen: Das war total abgefahrene Medienkunst, zumindest haben mir das die Kollegen auch lange vorgehalten, tats√§chlich war es am Ende wie ein regul√§res Projekt, das sind die gleichen Anforderungen, es ist selten, das man wirklich mal etwas hat, das man wirklich angucken kann und was man mal sehen kann irgendwo. Das ist bei der Arbeit ja sonst eher eine Ausnahme, w√ľrde ich sagen, und vielleicht war es ein bisschen mehr gr√ľne Wiese, wie man das in Unternehmen oder Konzernen oder √§hnliches kennt. Das hei√üt, hier waren wir in der Technologie relativ frei, wie wir das umsetzen. Wobei man auch da sagen muss: In jedem Projekt gibt es Vorgaben und Matthew hat mit Blender angefangen, diesen Turm zu erzeugen, und damit war ein St√ľck weit von der Technologie nat√ľrlich auch schon gesetzt.

Lucas Dohmen: Genau. Wir werden nachher nochmal ein bisschen mehr auf die Technologie eingehen, aber erstmal zu den Anforderungen, was f√ľr Anforderungen waren an dich gestellt f√ľr die Umsetzung, was musstest du machen, was war deine Aufgabe?

Simon Kölsch: Zum einen ist das Kunstwerk die eigentliche Homepage, die man besuchen kann, um diesen Twwwr zu sehen und entsprechend hoch- und runter zu scrollen, zum anderen haben wir im ZKM in Karlsruhe eine Ausstellung und da ist dieser Twwwr ein Teil davon.

Lucas Dohmen: Was ist das ZKM?

Simon K√∂lsch: Das ZKM ist eine Institution in Karlsruhe, die sich unter anderem mit Medienkunst besch√§ftigt. Da ist eine etwas gr√∂√üere Ausstellung, wir k√∂nnen die ja kurz erw√§hnen, das ist die Open Codes, die l√§uft noch bis zum August 2018, in dem man sich mit dem Thema Digitalisierung und Beeinflussung von dem, was man so als Technologie um sich herum wahrnimmt, auf die Gesellschaft besch√§ftigt. Und da gibt es eine Installation mit, man muss sich das so vorstellen, man hat eine Reihe an Monitoren, 5 an der Zahl, die mit einer recht hohen Aufl√∂sung √ľbereinandergestapelt sind. Und da wird das Kunstwerk halt mit ein paar Metern H√∂he dargestellt.

Lucas Dohmen: Aber das ist grundsätzlich dieselbe Software, die da zu sehen ist?

Simon K√∂lsch: Genau und dadurch hat sich das eigentlich ergeben, da wir eh so etwas wie eine Homepage brauchen, dass wir uns hier im Webumfeld bewegen und der Twwwr an sich, vereinfacht ausgedr√ľckt, einfach eine Homepage ist mit entsprechenden M√∂glichkeiten auf die Webcam zuzugreifen und ein Foto zu machen, um selbst das Gesicht in den Twwwr zu bringen.

Lucas Dohmen: Okay und das heißt, die Leute, die da in der Ausstellung sind, die können da von sich auch live ein Foto hochladen?

Simon Kölsch: Richtig. In der Ausstellung gibt es ein Tablet, das davor entsprechend installiert wurde, da kann man dann selbst das Gesicht fotografieren, das ist allerdings die gleiche Homepage, wie die, die im Internet zu sehen ist, also da ist auch eine Interaktion irgendwo da.

Lucas Dohmen: Okay. Das heißt also, wenn ich zu Hause eins aufnehme, sieht man das auch in der Ausstellung.

Simon Kölsch: Richtig.

Lucas Dohmend: Du hast schon gesagt, dass der Twwwr aus ganz vielen 3D-Modellen besteht. Zum einen halt diese Gesichter, aber zum anderen sind da auch andere 3D-Modelle dabei, wie muss ich mir das vorstellen, wo kommen die her?

Simon K√∂lsch: Es gibt diese gesammelte Datenbank aus dem Netz mit frei verf√ľgbaren 3D-Scans, ein Gro√üteil davon stammt zum Beispiel von einer Adobe 3D-Scanner-App, die Leute konnten das dann in die Community hochladen und da hat man dann diese Objekte gesammelt und das ist nicht irgendwie auf einen bestimmten Bereich beschr√§nkt. Das hei√üt, man hat 3D-Modelle von einer Bohrmaschine neben einem Puppenkopf neben jemandem, der sich komplett selbst gescannt hat und einem Buch, einer Ketchup-Flasche, das zieht sich komplett beliebig durch. Die werden von einem Algorithmus, den Matthew geschrieben hat, entsprechend √ľbereinander angeordnet. Und so entsteht dann dieser Turm. Und aus dieser Datenbank von 3D-Modellen wird immer eins ausgew√§hlt und auf das andere draufgestapelt.

Lucas Dohmen: Ist es denn jetzt abwechselnd ein 3D-Modell und ein Gesicht oder wie passiert das?

Simon K√∂lsch: In festen Zeitintervallen kommen neue Objekte dazu und mit den Gesichtern, das h√§ngt davon ab, wieviele Leute dann eben ihr Gesicht hinzuf√ľgen. Das wird nicht nochmal irgendwie dadurch beeinflusst oder √§hnliches.

Lucas Dohmen: Da ist ein ganz großes Zufallselement dabei.

Simon Kölsch: Genau. Der Turm selbst ist komplett generativ erzeugt.

Lucas Dohmen: Und du hast gesagt, das funktioniert mit Blender? Wie muss ich mir das vorstellen, sitzt da jetzt der Matthew live an seinem Blender an seinem Rechner und muss da hochladen oder…

Simon Kölsch: Also, am Anfang saß er da live und hat hochgeladen, was da aus Blender herausfällt. Also letztendlich besteht der Turm von den Grundelementen her aus diesen 3D-Modellen, das sind aber exportierte Fotos, das heißt in Blender existiert als 3D-Modell der Turm, es gibt eine Kamera und diese Kamera exportiert da Screenshots heraus aus dieser Szenerie. Und diese Screenshots werden dann entsprechend gespeichert und aneinander gepackt und so entstehen quasi nahtlose Übergänge zwischen den Objekten.

Lucas Dohmen: Aber der Twwwr ist ja theoretisch unendlich hoch, oder?

Simon K√∂lsch: Der kann unendlich wachsen und man kann auf der Homepage nat√ľrlich auch unendlich nach unten scrollen.

Lucas Dohmen: Muss Blender dann diesen gesamten Twwwr im Speicher haben, um das zu machen oder wie funktioniert das?

Simon K√∂lsch: Tats√§chlich hat ja Matthew diese komplette Blender-Automatisierung geschrieben und er hat es relativ einfach gel√∂st, indem die Kamera in einer festen Position verbleibt in dieser Blender-Szene und einfach dieser Turm immer ein St√ľck nach unten rutscht. Das hei√üt, es wird ein neues Segment oben drauf gepackt und das letzte Segment im Twwwr wird gel√∂scht und dann wird er einfach ein Segment breit nach unten verschoben. Und so ist quasi sichergestellt, dass man nicht irgendwie ein 2GB gro√ües 3D-Modell im Speicher halten muss oder √§hnliches, sondern dass man diese Bilder hat, mit denen man arbeiten kann.

Lucas Dohmen: Das heißt den Gesamtturm, den gibt es niemals in Blender zu sehen, sondern das sind nur die exportierten Bilder, quasi Teilausschnitte von diesem riesigen Blendermodell sind?

Simon K√∂lsch: Genau richtig. Man muss noch sehen, was man da l√§ngerfristig nat√ľrlich noch baut, sowas kann man nat√ľrlich noch erweitern und periodisch Dinge exportieren, aber da der Algorithmus von Matthew f√ľr Blender auch geschrieben ist, wie die Bilder ausgew√§hlt werden und so weiter, ist das einfach erstmal festgesetzt und da hat man einfach nicht die M√∂glichkeit, ein entsprechend gro√ües Modell zu speichern.

Lucas Dohmen: Klar, aber das heißt, ich habe so wie bei Twitter oder so quasi eine Timeline vor mir, also oben erscheinen immer neue Dinge auf meinem Turm, wenn ich ihn anschaue?

Simon Kölsch: Genau.

Lucas Dohmen: Und wie hast du das umgesetzt, also du hast gesagt, das ist eine Webseite, was hast du daf√ľr verwendet, um das zu bauen?

Simon K√∂lsch: Das ist der Teil, der tats√§chlich gr√ľne Wiese war, das hei√üt, da sind wir relativ frei, was wir da benutzt haben. Ich mache ab und zu mal etwas mit Node.js und habe da gute Erfahrungen mit gemacht und finde, im Gegensatz zu den ganzen Vorurteilen, die es da zu diesem √Ėkosystem gibt, alles nicht ganz so dramatisch und habe hier eigentlich eine M√∂glichkeit gesehen, relativ leichtgewichtig mit kleinen Services, die in Node geschrieben und in Docker-Container verpackt sind, das ganz gut umsetzen zu k√∂nnen. Ohne da jetzt gro√ü Architekturdiskussionen aufmachen zu wollen oder so, das geht schon in eine Microservice-Richtung, und habe dann mit Node.js begonnen und damit quasi Blender instrumentalisiert und das hat ganz gut funktioniert.

Lucas Dohmen: Okay und wo läuft dieses ganze System? Läuft das bei uns im Server-Rack?

Simon K√∂lsch: Genau, da war nat√ľrlich sowieso die Frage: Wie bekommt man die Synchronisation mit dem ZKM, mit der Ausstellung, mit Karlsruhe hin und was da noch so alles dranh√§ngt? Wir selbst haben ja keine, oder nur sehr wenig, Infrastruktur, das hei√üt, wenn wir so L√∂sungen umsetzen, gerne mit dem, was man so als Cloud bezeichnet, dabei w√§re es auch wieder egal gewesen, was man da nimmt, aber wir machen das Rendern und die Anzeige von der Homepage komplett auf AWS-Infrastruktur. Konkret hei√üt das, da sind zwei Instanzen, die da laufen, ein relativ einfacher Reverse Proxy, der auch den Twwwr enth√§lt, die entsprechenden Daten, die erzeugten Bilder speichern wir auch komplett im S3 storage layer von AWS und zu guter Letzt haben wir noch eine Maschine, die das Rendering √ľbernimmt, die dann ein bisschen gr√∂√üer ist.

Lucas Dohmen: Das heißt, da läuft dann Blender in der AWS-Cloud drin?

Simon K√∂lsch: Genau. Dadurch, dass Blender gesetzt ist, hat man halt irgendwie das Problem, dass man mit Filemanagement umgehen muss, ich muss irgendwie mein aktuelles 3D-Modell speichern, das hei√üt, ich kann das ganz schlecht auf mehrere Maschinen verteilen oder √§hnliches. Und ich muss eigentlich daf√ľr sorgen, dass ich immer wieder die gleiche Umgebung habe, in der ich dieses Rendern ausf√ľhre. Es gibt nat√ľrlich irgendwelche Services, die man daf√ľr auch benutzen kann, das haben wir jetzt noch gar nicht erw√§hnt. Auch hier unterscheidet sich dieses Projekt auch nicht von √ľblichen Projekten: Der Endtermin war halt gesetzt mit der Ausstellungser√∂ffnung. Und ohne die Anforderungen konkret gekl√§rt zu haben, hatten wir in etwa 3 Monate. Da war klar, wir brauchen eine L√∂sung, die ein St√ľck weit pragmatisch ist, die aber auch gut funktioniert. In dem Fall habe ich mich einfach daf√ľr entschieden, Blender in einem Docker-Container zu benutzen, da gibt es nat√ľrlich auch entsprechende fertige Images. Und konkret funktioniert das Rendern dann so, dass in dieser Render-Maschine ein Docker-Container gestartet wird, versehen mit einer ganzen Reihe an Parametern, zum Beispiel, wo die 3D-Modelle zu finden sind, ob ein Gesicht im Turm auftauchen soll und so weiter. Und dieser Docker-Container, dieser single shot container, der einmal hochgefahren wird, direkt das Rendern beginnt und nach dem Rendern ein Bildsegment herausschreibt und sich dann wieder beendet, terminiert.

Lucas Dohmen: Das heißt aber, die Steuerung davon, dass da regelmäßig neue, einzelne 3D-Objekte dazukommen, die ist in einem anderen System abgebildet, die ist nicht Teil von dem Python-Skript?

Simon K√∂lsch: Richtig, genau. Dieses Python-Skript, das Blender steuert, das kann ich einmal aufrufen und habe dann einfach nur den Parameter ‚ÄöPack mir bitte ein neues Segment an meinen bestehenden Turm ran‚Äė oder ‚ÄöMach ein neues Gesicht in die Totems rein‚Äė.

Lucas Dohmen: Okay, das hei√üt, wir haben diesen Blender-Container, der erzeugt Bilder, legt die dann in S3 hinein, wir haben diesen Container, der wie ein Taktgeber ist und neue Bilder da hinein packt, was hast du noch f√ľr Services in deiner Architektur?

Simon K√∂lsch: Wir k√∂nnen ja mal etwas konkreter darauf eingehen. Kern ist der Twwwr-Service, der zum einen diesen Turm generiert, das hei√üt, wir haben irgendwo bestehend schon unsere Bilder, die wir mit einem Timestamp entsprechend gespeichert haben, wir haben Metadaten, um die in dem Turm wiederfinden zu k√∂nnen und gleichzeitig haben wir eine API, die sowas wie /store hat, in dem ich dann einfach diese Bildsegmente abspeichern kann. Auf der anderen Seite haben wir auf einer anderen Maschine einen kleinen Node-Service, das sind gerade 100 Zeilen Code, der wartet eigentlich nur darauf, dass er irgendwie getriggert wird, indem entsprechend ein neues Bild eingef√ľgt wird, also ein neues Gesicht, das im Twwwr auftauchen soll oder √ľber ein Zeitintervall ein neues Rendering angesto√üen werden soll. Die kommunizieren √ľber eine Message Queue, nicht eine Message Queue, sondern tats√§chlich eine Redis-Instanz, in Redis k√∂nnen wir ja einfach Datenstrukturen ablegen, zum Beispiel so etwas wie eine Queue, mit der wir dann mit push und pop arbeiten k√∂nnen. Die warten da einfach auf ein key change event, wenn ein neuer Trigger quasi in Redis gespeichert wird, bekommt der Renderer Services das mit, f√§ngt an, zum Beispiel ein zuf√§lliges Segment auszuw√§hlen, baut es, rendert es und geht dann hin und pusht die Bilder zur√ľck an den Twwwr-Service, die dann da gespeichert werden.

Dar√ľber hinaus gibt es noch einen Service, der einfach nur die fotografierten Gesichter annimmt, das sind auch nur ein paar Zeilen Code, die einfach nur ein Bild speichern eigentlich. Das l√§uft aber auf der Rendering-Maschine, wir haben hier durch die Blender-Files und durch Textur-Files, die wir brauchen, halt die Einschr√§nkung, dass wir mit dem File-System arbeiten m√ľssen. Man w√ľrde ja jetzt erwarten, dass wir so einen API endpoint irgendwo vorne haben, und der nimmt halt das Bild entgegen und reicht es dann geschlossen weiter. Hier ist es eben so aufgebaut, dass es einen reverse proxy gibt, das ist einfach ein nginx Container, der da l√§uft, der nimmt die requests an. Und wenn er ein Bild bekommt, schickt er das direkt an den Bild-Service, der das einfach nur in das Dateisystem speichert und das housekeeping von den Files macht.

Lucas Dohmen: Und die Gesichter, die sind ja jetzt erstmal flache Bilder, wie werden die zu 3D-Modellen, wie muss ich mir das vorstellen?

Simon K√∂lsch: Genau, das ist der n√§chste Punkt, an dem man wahrscheinlich auch gerne ein halbes Jahr Projekt machen k√∂nnte, wie man da Bilderkennung macht. Wahrscheinlich wird man da zuerst einmal an etwas wie OpenCV denken, da gibt es ja relativ viele Tutorials, die so etwas wie facetracking auf Kamerabilder k√∂nnen und Kollegen haben beim INNOQ-Event auch mal eine bird view-Kamera f√ľr den Kicker gebaut und dann einen Ball verfolgt. Das Problem an der Stelle ist, dass ich am Ende einfach nur das erkannte Gesicht brauche. Und je komplizierter so eine build pipeline wird, desto schwieriger wird es, das zu managen und sinnvoll stabil zum Laufen zu bringen im Netz, wo die Leute darauf zugreifen k√∂nnen. In dem Fall haben wir einfach im Frontend jQuery, daf√ľr gibt es ein Plugin, um die Gesichter auf zum Beispiel irgendwelchen Fotos zu markieren, so wie man das von Facebook oder Twitter kennt, da kann man Personen mit verkn√ľpfen. Diese Gesichtserkennung funktioniert eigentlich, um einen Bildausschnitt zu bekommen, relativ gut. Egal, welche L√∂sung man sich da anguckt, da gibt es immer kleinere Probleme, und damit es richtig gut funktioniert und auf einem Server l√§uft, also nicht irgendein Skript, was irgendwer mal zum Testen auf Github gepackt hat, sondern zuverl√§ssig als Library, hat sich angeboten, diese jQuery Library zu benutzen, und die schneidet im Client das Gesicht entsprechend aus und schickt dann dieses erkannte Gesicht zum Server.

Lucas Dohmen: Das heißt, wir kriegen ein freigestelltes Gesicht an den Server geschickt, richtig?

Simon Kölsch: Richtig.

Lucas Dohmen: Und dieses freigestellte Gesicht wird dann als Textur verwendet f√ľr ein beliebiges 3D-Modell.

Simon K√∂lsch: Nee, f√ľr eine eingeschr√§nkte Auswahl an 3D-Modellen. Matthew hat als K√ľnstler ja eine sehr pr√§zise Vorstellung davon, wie dieser Twwwr optisch aussehen kann neben so Dingen wie den shadern, die benutzt werden und das Licht, das entsprechend den Twwwr ausleuchtet, geh√∂ren da nat√ľrlich auch die Objekte dazu, auf denen die Textur vom Gesicht landet. Und Matthew hat da eine Liste aus, ich glaube, 10 - 15 Objekten, das sind relativ einfache geometrische Formen, die aber so ein bisschen verzerrt sind. Man muss sich das vorstellen wie so einen W√ľrfel, der dann oben zum Beispiel durch eine Verzerrung abgerundet ist. Auf diese Objekte wird dann das freigestellte Gesicht als Textur platziert und das als Teil im Twwwr gerendert.

Lucas Dohmen: Okay, das heißt, die anderen 3D-Modelle sind sehr, sehr zufällig, aber das ist schon kuriert, was da genau herauskommt.

Simon Kölsch: Genau.

Lucas Dohmen: Auf welche Probleme bist du denn gesto√üen, als du das umgesetzt hast? Du hast ja schon √ľber das File-Handling gesprochen, das nicht so einfach war. Gab es noch andere Sachen, die eine Herausforderung waren bei der Umsetzung?

Simon K√∂lsch: Ja. Wenn man das Projekt das erste Mal h√∂rt, denkt man sich: Naja, nach einer Woche hat man da etwas zusammengebastelt, das irgendwie funktioniert. Aber wenn man das ein St√ľck weiter denkt, kommt man sehr schnell an den ersten Punkt, wo man denkt: Okay, wir haben diesen unendlich gro√üen Twwwr und man m√∂chte bestimmt irgendwelche Teile in diesem Turm wiederfinden, zum Beispiel sein eigenes Gesicht oder √§hnliches. Und am Anfang bin ich ganz gut damit ausgekommen, nur etwas wie einen Timestamp als Metainformation zu verwenden, das Problem dabei ist aber, dass uns bei einem Link auf ein gewisses Segment ja nicht ein Ergebnis von einer Datenbank, zum Beispiel ‚ÄöGib mir alle Bilder, ordne die bitte nach dem Timestamp und das bitte absteigend und dann haben wir einfach eine entsprechende Timeline erzeugt‚Äė interessiert, sondern wir brauchen genau ein Element in der Mitte dieses Turms und die f√ľnf Elemente dar√ľber und die f√ľnf Elemente darunter. Und nat√ľrlich kann ich halbwegs mit SQL umgehen, aber ich mache das nicht st√§ndig, t√§glich im Projekt. Und wenn die Queries komplizierter werden, dann sitzt man da schon eine Weile dran. Ich muss sagen, das hat schon irgendwie, zum Gl√ľck, mit einer gewissen Unterst√ľtzung von einem Kollegen, ganz gut funktioniert.

Lucas Dohmen: Aber das ist auch anders jetzt als beispielsweise bei Twitter, ne, wenn ich bei Twitter sage: Ich möchte in der Timeline einen bestimmten Tweet teilen mit irgendjemandem, dann teile ich immer den einzelnen Tweet, das wäre ja bei euch das einzelne Gesicht, aber das wollt ihr ja nicht, ihr wollte ja eine bestimmte Stelle in diesem endlos scrollenden Turm haben.

Simon K√∂lsch: Ja. Wenn man sich diese ganzen Timelines und social walls und so weiter anguckt, ich kenne das zumindest nicht, dass man auf eine gewisse Position in dieser Timeline verlinken kann, wenn man das so vergleichen m√∂chte, sondern ich kann immer auf einen spezifischen Tweet linken und sehe dann aber nur diesen Tweet, ich sehe aber nicht den Tweet im Kontext von der kompletten Timeline, wie sie damals zu dem Zeitpunkt ausgesehen hat. Es ist verst√§ndlich, dass es auch nicht geht, zumindest ist es ein eher un√ľbliches feature, aber hier in dem Sinne suchen wir ja wirklich eine konkrete Stelle in dieser Timeline wieder. Und so im Nachhinein ist es nat√ľrlich offensichtlich und nat√ľrlich wie man das l√∂st, aber da kann man schon erstmal ein bisschen am Anfang beim Dar√ľbernachdenken dar√ľber stolpern. Das n√§chste ist dieses endless scrolling. Ich m√∂chte ja einfach auf dieser Homepage scrollen k√∂nnen und lade dann automatisiert die Bilder nach. Wenn ich jetzt an eine gewisse Position springe, dann muss ich pl√∂tzlich auch nach oben endlos scrollen und muss ab der Position entsprechendes paging implementieren, damit es die Bilder entsprechend nachl√§dt. Das sind so Dinge, da sitzt man dann schon ein bisschen l√§nger dran und hat es auch nicht so alles frei Haus fertig als Frontend-Plugin oder √§hnliches, da muss man dann ein bisschen was tun, damit das so funktioniert.

Lucas Dohmen: Und in der Ausstellung, der Turm, der scrollt automatisch, ne?

Simon K√∂lsch: Ja, das ist relativ pragmatisch gel√∂st, letztendlich ist es ein Browser in einem Kiosk-Modus, der √ľber diese Monitore die Homepage anzeigt, es gibt Parameter, die daf√ľr sorgen, dass das Men√ľ nicht eingeblendet wird und er hat einfach eine feste Zeit, in der er sich neu l√§dt und das ist einfach mit einem HTTP header, mit einem meta refresh realisiert und da ist eine Zeit von, ich wei√ü es jetzt gerade gar nicht, 10 Minuten oder so eingestellt und dann kann man quasi den Turm hoch- und runterscrollen und nach 10 Minuten gibt es einen reload auf die komplette Seite.

Lucas Dohmen: Okay, also das heißt, die Leute in der Ausstellung können auch den Turm bewegen?

Simon K√∂lsch: Richtig. Die Idee dabei ist, dass wir diesen Turm √ľber so ein scroll wheel komplett hoch- und runterscrollen kann und sich die Objekte darin ansehen kann.

Lucas Dohmen: Okay, es ist nicht ein Kunstwerk, das man nur anschaut, sondern man kann damit wirklich auch interagieren. Nicht nur etwas beitragen, sondern man kann sich darauf bewegen.

Simon Kölsch: Genau.

Lucas Dohmen: Okay! Und wie war das mit der Skalierung? Kommen da jetzt superviele Bilder rein, ich meine, das Rendern ist ja doch sehr aufwändig, wie gehst du damit um?

Simon K√∂lsch: Ja, da haben wir insofern ein bisschen die Problematik, dass das Rendern einfach Zeit braucht. Und da kann man lange auf dem lokalen Laptop bei sich probieren, wie man den m√∂chte, relevant ist ja, was auf dem Server passiert. Das muss man einfach ausprobieren und messen. Und wir haben dann erst mit einer etwas kleineren AWS-Maschine angefangen und haben dann sehr schnell gemerkt: Okay, da muss die CPU halt rechnen und das geht auf den Speicher und sind am Ende bei einer, ich wei√ü gar nicht, C4-Large-Instanz gelandet, das hei√üt, wir haben 16 virtuelle CPU-Kerne darin und wir haben knapp 30GB Arbeitsspeicher und der Qualit√§t, in der wir die Bilder da rausrendern, brauchen wir knapp eine Minute f√ľr diesen Rendering-Prozess. Man muss dazu sagen, das ist ein bisschen komplizierter, wir haben ja immer ein Segment, das der aktuelle Kopf von diesem Turm ist und diesen Kopf entfernen wir sp√§ter wieder, weil wir rendern ja ein neues Objekt dazu und es ist nicht so, dass die Objekte immer b√ľndig an der Bildkante aneinanderliegen, sondern die gehen ineinander √ľber. Und deswegen m√ľssen wir zwei Segmente immer generieren, also das neue Segment, das in diesem Twwwr auftaucht und der abschlie√üende Kopf dadr√ľber, und da brauchen wir knapp eine Minute f√ľr und da ist die Maschine auch, also diese 16 Quad CPUs, die sind auf 100 Prozent und der Arbeitsspeicher ist auch relativ am Limit. Jetzt k√∂nnte man da noch eine Nummer gr√∂√üer gehen bei AWS, da ist noch ein bisschen Luft, aber das sind halt auch einfach Kosten, die da entstehen und am Ende kann man nat√ľrlich sagen: Okay, h√§tte man GPU-Instanzen benutzen k√∂nnen an der Stelle, aber zumindest das, was ich ausprobiert habe, in Kombination mit den AWS-Maschinen, h√§tte sich das kostenm√§√üig nicht rentiert, wir w√§ren nicht so massiv schneller gewesen, weil wir hier halt an der Stelle trotzdem noch die H√∂he skalieren k√∂nnen. Und zum anderen haben wir halt bei dem Setup Blender in einem Docker-Container laufen, und ich muss ganz ehrlich sagen, wie man das direkt mit den GPUs verheiratet bekommt, auf der Maschine, die auch nur irgendwie virtuell bei AWS sind, in einer bisschen √§lteren Version, da wei√ü ich gar nicht, ob sich das Setup eins zu eins so h√§tte √ľbertragen lassen.

Lucas Dohmen: Das heißt, wenn jemand ein Gesicht einscannt, muss man ein bisschen warten und irgendwann erscheint das Gesicht? Oder wie muss ich mir das vorstellen?

Simon K√∂lsch: Genau. Wir haben so in etwa diese ein, zwei Minuten Rendering-Zeit, je nachdem, was da noch auf der Queue liegt, dauert das vielleicht ein bisschen l√§nger, aber der Prozess ist: Man w√ľrde sein Gesicht fotografieren und einfach nach zwei Minuten die Seite nochmal neu laden, und dann sollte das eigentlich Teil des Twwwrs an der Stelle sein. Den Prozess k√∂nnte man wahrscheinlich nochmal wesentlich h√ľbscher im Gro√üen und Ganzen machen, aber da ist man dann in der Zeit irgendwann halt eingeschr√§nkt, was das angeht.

Lucas Dohmen: Okay. Und wenn ich mir jetzt diesen Turm so vorstelle, wie gro√ü muss ich mir den vorstellen? Kann man das ausdr√ľcken, in Metern oder so?

Simon Kölsch: So ein Bildsegment im Twwwr sind 675 Pixel groß, das ist immer so eine Frage, wie rechnet man denn Pixel in Zentimeter um? Wenn wir jetzt einfach mal mit einer Faustformel sagen: Naja, die 675 Pixel, das entspricht in etwa so 17 Zentimetern, wir haben jetzt seit der Ausstellungseröffnung, das ist jetzt ein Monat, knapp 6.000 Segmente generiert und dann kommen wir irgendwie bei so einem Kilometer Turmhöhe im Moment heraus.

Lucas Dohmen: Einem Kilometer?

Simon Kölsch: Ein Kilometer, eigentlich. Wenn man sagt, ein Segment sind so 17 Zentimeter. Und der wird wahrscheinlich noch ein bisschen wachsen.

Lucas Dohmen: Und wie hoch ist der Bildschirmturm, den man in der Ausstellung sieht?

Simon Kölsch: Das sind 5 sehr große Monitore, die hochkant gedreht sind, man braucht eine Leiter, um die auszurichten und zu kalibrieren, die genaue Höhe in Metern kann ich jetzt nicht sagen, vielleicht 4 Meter in etwa, so um den Dreh.

Lucas Dohmen: Also man sieht schon einen ganz guten Teil von dem Turm, aber man m√ľsste schon sehr lange scrollen, um den ganzen Kilometer‚Ķ

Simon K√∂lsch: Der Kilometer passt da nicht so ganz drauf, genau. Das sind knapp 2.7GB an Bildmaterial, die daf√ľr da sind, wobei man dazu sagen muss: Jedes Gesicht, was man selbst nochmal hochgeladen hat, das 3D-Objekt davon wird gespeichert und das kann man dann auch selbst nochmal herunterladen. Also diese 3D-Objekte, auch wenn die nicht sehr gro√ü sind, das ist einfach nur die Gesichtstextur auf das geometrische Objekt gemappt, in ein Zip-File, die sind da auch mit gespeichert‚Ķ

Lucas Dohmen: Aber ohne die Umgebung?

Simon K√∂lsch: ‚Ķaber ohne die Umgebung, ohne den Turm, der da irgendwie dr√ľber und drunter ist, genau.

Lucas Dohmen: Wieviel Code musstest du daf√ľr schreiben, dass das alles funktioniert?

Simon K√∂lsch: Ich traue es mich ja gar nicht zu sagen, weil da wird ja jeder sagen: Was? So wenig? Das kann man ja an einem Wochenende alles machen! Ich habe vorher nochmal kurz irgendwie mit word count die Zeilen gez√§hlt, ich muss auch ganz ehrlich sagen, der Code ist nicht minified und man kann das wahrscheinlich alles nochmal ein bisschen h√ľbscher machen und so ein paar duplicate Code-Stellen gibt es, aber das ist trotzdem f√ľr das Frontend, f√ľr das ganze Scrolling, f√ľr das face capturing und so weiter sind das knapp 200 Zeilen JavaScript-Code. Und f√ľr das Backend, also der Haupt-Kernpunkt von dem Towwwer, das sind knapp 600 Zeilen, der Service, um die Gesichter zu speichern, um das housekeeping zu machen, sind knapp 130 Zeilen und der Service, der sich darum k√ľmmert, Docker-Container mit Blender darin zu starten und die Ergebnisse an den Tower zu schieben, sind nochmal knapp 60 Zeilen. Und dann kommen wir so in Summe bei knapp 800 Zeilen Code f√ľr das Backend und 200 f√ľr das Frontend heraus.

Lucas Dohmen: Cool! Jetzt w√ľrde ich sagen, kommen wir nochmal zum Ende. Wenn ich mir das anschauen will, kann ich einfach zur Webseite gehen, das werden wir verlinken. Was ist, wenn ich mir das mal live anschauen will? Du hast es eben schon kurz erw√§hnt, das gibt es im ZKM?

Simon K√∂lsch: Das Kunstwerk ist nat√ľrlich im Internet. Da kann man das live ansehen. Zumindest mein Eindruck war auch, dass Matthew das so sieht. Das Kunstwerk ist ein digitales Kunstwerk. Wenn man trotzdem die Kunstinstallation sehen will, dann gibt es da die M√∂glichkeit, wie am Anfang schon erw√§hnt, im ZKM einfach in der Open Codes Ausstellung vorbei zu schauen, der Eintritt dort ist auch kostenlos und die geht noch bis zum August 2018.

Lucas Dohmen: Klasse. Dann vielen Dank f√ľr das Interview. Und den H√∂rern bis zum n√§chsten Mal beim INNOQ-Podcast!

Simon K√∂lsch: Danke f√ľr das Gespr√§ch!

Lucas Dohmen: Tsch√ľss!