Dieser Beitrag beschreibt den Workflow zum Upload von Streetlevel-360-Grad-Bildern auf eine Panoramax-Instanz nach erfolgter Aufnahme der Fotos. Dieser gliedert sich bei mir in 3 Schritte: .jpg-Konvertierung, Erstellung einer Nadir-Abdeckung und Upload der fertigen, nicht-geblurrten Fotos. Die Fotos liegen zu Beginn in mehreren Ordnern auf der SD-Karte. GoPro folgt hierbei dem DCF.

1. .jpg-Konvertierung

Die Fotos sollten stets direkt von der SD-Karte zum PC übertragen werden. Indirekte Uploads über die GoPro-Cloud oder Smartphones sind für größere Datenmengen ungeeignet.

Bei mir kam es bis zu einer erneuten Formatierung der SD-Karte mit Kubuntu und Dolphin (KDE) mehrmals zum Absturz des Dateimanagers. Woran es genau lag, kann ich letztlich nicht sagen. Klar ist, dass das bei der gleichen SD-Karte und DJI-Drohnen-Footage nicht auftrat und schließlich durch die Formatierung gelöst werden konnte.

Bei 1 Stunde Fahrtzeit und einem 2-Sekunden-Intervall fallen ca. 1.800 Bilder, was je nach durchschnittlicher Bildgröße 10-12 GB entspricht.

Die GoPro Max speichert Einzelbilder standardmäßig im Format .36P. Diese müssen in Standard-JPEG überführt werden. Wichtig: Sämtliche Metadaten (Kameramodell, EXIF- und XMP-Geodaten) bleiben hierbei vollständig erhalten.

Um alle CPU-Kerne auszulasten, erfolgt die Konvertierung via GNU Parallel:

parallel --bar 'convert {} {.}.jpg' ::: *.36P

2. Nadir-Abdeckung via changenadir.sh

In der 360-Grad-Fotografie (und einigen anderen Bereichen) bezeichnet der Zenit den höchsten Punkt der Sphäre (senkrecht nach oben) und der Nadir den tiefsten Punkt (senkrecht nach unten). Während der Zenit bei Street-Level-Fotographie gewünscht ist, verbirgt sich im Nadir lediglich die Halterung der Kamera, Helm, Autodach oder sonstige störende Gegenstände. Es hat sich daher bewährt, den unteren, nicht relevanten Teil des 360-Grad-Bildes inhaltsleer zu färben, etwa durch ein Logo oder einfach schwarz.

Equirektanguläre Bilder projizieren eine Kugeloberfläche auf ein rechteckiges 2:1-Raster. Der untere Bildrand repräsentiert den Nadir. Ein horizontaler Balken am unteren Rand eines Ausgangsbildes erscheint in der 360-Grad-Ansicht als kreisrunde Fläche direkt unter der Kamera. Eine Abdeckung von 30% des Bildes hat sich in diesem Kontext als ideal erwiesen, sodass Helm und Vorderradbereich aus dem Sichtfeld entfernt sind, ohne relevante Straßenbereiche zu beschneiden.

Die ursprüngliche Idee basiert auf dem Tool nadir-patcher, welches den Nadir mit Logos oder einfarbig bedecken kann. Bei mir ergab sich bei Verwendung von nadir-patcher allerdings eine untragbar lange Rechenzeit. Ich möchte nicht ausschließen, dass das letztlich an mir lag. Nichts desto trotz hat mir eine KI ein Bash-Skript geschrieben, das unter Zuhilfe-Name von GNU-Parallel und Image-Magick den Nadir in auswählbarer Größe und Farbe einfärbt. Das Skript heißt changenadir.sh. Der Befehl deckt standardmäßig die unteren 30 % der Bildfläche schwarz ab und legt die bereinigten Dateien in einem Unterordner /output ab.

Rechenzeit: Die Verarbeitung von ca. 10 GB Bildmaterial (Konvertierung und Nadir-Abdeckung) dauert auf typischer Multi-Core-Hardware rund 45 Minuten (abhängig von thermischer Drosselung der CPU).

3. Upload via Panoramax-CLI

Die Web-GUI von Panoramax stößt ab etwa 1.000 Bildern an praktische Grenzen. Den genauen Hintergrund kenne ich nicht, ich vermute hier eher eine browserbedingte Grenze. Für größere Datensätze ist die offizielle Panoramax-CLI der Standardweg.

Wechsel in das Ausgabeverzeichnis der gepatchten Bilder und Upload starten:

panoramax_cli upload \
  --semantics transport=bike \
  --split-time 10 \
  --api-url [https://panoramax-ulm.jjbaur.de](https://panoramax-ulm.jjbaur.de) .

Die Parameter in diesem Beispiel:

  • --semantics transport=bike: Weist den Bildern das Erfassungsmittel Fahrrad zu.
  • --split-time 10: Teilt den Upload automatisch in eine neue Sequenz, sobald zwischen zwei Bildern eine Zeitlücke von mehr als 10 Sekunden liegt.
  • --api-url: Zielinstanz

Beim ersten Aufruf öffnet die CLI ein Browserfenster zur Anmeldung. Das Authentifizierungs-Token wird lokal gespeichert. Vor dem Transfer prüft die CLI alle Bilder lokal auf Duplikate und valide Geodaten. Fehlerhafte oder unvollständige Dateien werden aussortiert. Bricht die Netzwerkverbindung während des Uploads ab, setzt ein erneuter Aufruf exakt an der letzten erfolgreichen Datei an. Das ist im Übrigen ein Vorteil zur Web-Gui, bei der die Duplikatsprüfung logischerweise serverseitig nach Upload erfolgt. Nach Abschluss des Uploads gibt die CLI einen Befehl aus, mit dem der serverseitige Verarbeitungsstatus abgefragt werden kann.

Ich verweise im Übrigen auf die Dokumentation.

Serverseitige Nachbearbeitung & Anonymisierung

Sobald die Bilder auf der Instanz liegen, werden sie vom Server an eine Blurring-API übergeben (im Fall von panoramax-ulm.jjbaur.de an den zentralen Dienst von panoramax.fr), um Gesichter und Kennzeichen unkenntlich zu machen.

Die automatische Verpixelung arbeitet bei normalem Straßenabstand zuverlässig. Sehr nah vor der Linse befindliche Gesichter (z. B. bei direkt davor stehenden Personen oder Mitfahrenden in einer Gruppe) werden leider noch nicht gut erfasst und bleiben unvollständig geblurrt.

Typischerweise schaue ich dann nochmal kurz im Browser über die neuen Eintragungen. In seltenen Fällen muss ich über die GUI noch Duplikate manuell entfernen. Die lokalen Bilddateien sollten nach dem Upload als Backup aufbewahrt werden. Es ergibt sich folgenden Befehl für alle Aktionen (der sicherlich in einem einzigen Skript vereint werden kann):

parallel --bar 'convert {} {.}.jpg' ::: *.36P && changenadir && cd output && panoramax_cli upload --semantics transport=bike --split-time 10 --api-url https://panoramax-ulm.jjbaur.de .