Kapitel 9 — SfM-Backends


Der Camera-Alignment-Picker im Inspector ist ein Segmented-Control mit zwei Optionen — Apple Photogrammetry (Default für App-Store-Builds, voll sandbox-konform) und Native (Beta) (RadianceKit's eigenes FAST+BRIEF+GLOMAP-Pipeline-Backend, Phase 3.8/3.9 entwickelt, Stand 2026-05). Native (Beta) ist orbit-only validiert und schneller bei ≥1 000 Frames als Apple Photogrammetry, schließt aber das Phase-3-§5-Quality-Gate (finalLoss ≤ 0.0115) noch nicht ein — daher der Beta-Tag. Externe SfM-Ergebnisse aus Metashape, COLMAP oder einer anderen Photogrammetrie-Software können zusätzlich über das File-Menü importiert werden (Q3 COLMAP-Text-Format, Q6 Workspace-Import) — der Picker wechselt nicht, aber die importierten Posen ersetzen das SfM-Resultat.
SfM steht für Structure from Motion. Aus einer Menge überlappender Fotos rekonstruiert die Software für jedes Bild die Position und Blickrichtung der Kamera in einem gemeinsamen 3D-Koordinatensystem. Dazu wird eine grobe 3D-Punktwolke erzeugt, die das Training mit Gaussian Splatting initialisiert. Das SfM-Ergebnis ist die Eingabe für das eigentliche Training und entscheidet maßgeblich über die spätere Bildqualität.
RadianceKit bietet fünf SfM-Wege: zwei in der App eingebaute Backends (Q1 Apple Photogrammetry, Q4/Q5 Native), zwei Import-Pfade aus externen Tools (Q3 COLMAP-Text-Format, Q6 binärer Workspace-Import) sowie Q2 COLMAP-Binary, das nur in Developer-Builds außerhalb des App Store verfügbar ist. Welcher der richtige ist, hängt vom Szenentyp ab (Orbit um ein Objekt, Innenraum, Drohnenflug) und davon, ob eine externe Software bereits eine Rekonstruktion liefert.
Q1 — Apple Photogrammetry
WO
Expert View → Inspector → Trainingskonfiguration → Camera Alignment-Picker, Eintrag „Apple Photogrammetry".
TECHNISCH
Wrapt Apples eingebautes Photogrammetry-Framework, das ursprünglich für Object Capture entwickelt wurde. Apple extrahiert intern Features mit einer proprietären Pipeline (Schritte sind nicht öffentlich dokumentiert), verifiziert sie über Multi-View-Matching und löst Bundle-Adjustment auf der Apple-Silicon Neural Engine + GPU. Das Backend ist vollständig App-Store-konform (keine externe Binary, Sandbox=true, on-device), liefert aber nur Kamera-Posen plus eine grobe Punktwolke — keine Diagnose-Metriken wie Track-Länge oder Reprojektionsfehler. Skaliert nach Apples Empfehlung bis ein paar Hundert Bilder. Bei mehr als ~500 Frames in linearen Drohnenflügen oder großen Outdoor-Szenen wurden reproduzierbar Crashes oder stilles Verwerfen einzelner Kameras beobachtet.
Q3 — COLMAP-Text-Format (Metashape / ETH3D)
WO
Menü „File → Import COLMAP / Metashape Workspace…" (Cmd+⇧+I) ODER Drag-and-Drop eines Ordners mit sparse/0/cameras.txt.
TECHNISCH
Liest den standardisierten COLMAP-Text-Export — drei Textdateien cameras.txt, images.txt, points3D.txt im sparse/0/-Unterordner — und konvertiert in das interne SfM-Ergebnis-Modell. Selbe Format-Definition wie der COLMAP-Binär-Export, nur als ASCII statt Binär. Wird von Agisoft Metashape, RealityCapture, PolyCam und dem ETH3D-Benchmark in genau diesem Layout ausgegeben. Der Parser teilt die Camera-Model-Erkennung mit dem Binary-Parser (alle gängigen Modelle: SIMPLE_PINHOLE, PINHOLE, OPENCV, OPENCV_FISHEYE, FULL_OPENCV). Robust gegen Kommentar-Zeilen und leere Zeilen. Skaliert in Tests bis ~1 400 Kameras (ETH3D Tunnel) ohne Probleme.
Q4 — Native SfM (inkrementell)
WO
Expert View → Inspector → Trainingskonfiguration → Camera Alignment-Picker, Eintrag „Native (Beta)". Inkrementell ist der Default-Modus dieses Backends — es gibt im Inspector keinen separaten Mapper-Picker. Per CLI lässt sich der Modus explizit setzen mit –native-sfm oder –sfm-mapper incremental.
TECHNISCH
Eigene GPU-beschleunigte Implementierung der gesamten SfM-Pipeline: FAST+BRIEF-Features ODER SuperPoint+LightGlue über CoreML (mit –coreml-features), gefolgt von Hamming-KNN-Matching, RANSAC-Fundamentalmatrix, Track-Building, Initial-Pair-Auswahl, Two-View-Bootstrap (F→E plus DLT), greedy inkrementellem Mapper mit PnP-Registrierung und Multi-View-Triangulation und finalem Bundle-Adjustment via Schur-reduziertem Levenberg-Marquardt mit Huber-Loss und analytischen Jacobians über Cholesky-Solve. Komplett App-Store-konform: keine externe Binary, Sandbox=true. Mit dem in Phase 3.10 ausgelieferten R2-Collapse-Detektor: registriert die App weniger als 60 % der Eingabe-Frames oder fällt die Points-per-Camera-Rate unter 13, wird automatisch auf den globalen Mapper (Q5) ausgewichen. Empirisch sauber auf Orbit-/Turntable-Szenen; auf allgemeineren Bewegungen (Drohnenflug, Innenräume mit komplexer Geometrie) ist die Erfolgsrate niedriger — der Detektor fängt diese Fälle aber ab. Skaliert bis ~200 Kameras zuverlässig, höher mit deutlich längerer Laufzeit.
Q5 — Native SfM (global)
WO
Wird automatisch aufgerufen, wenn der inkrementelle Mapper (Q4) den Collapse-Detektor auslöst (weniger als 60 % der Eingabe-Frames registriert oder Points-per-Camera-Rate unter 13). Manuell forcierbar nur via CLI –sfm-mapper global. Im Inspector ist das Globale Verfahren über keinen separaten Picker erreichbar — die App entscheidet selbst, wann sie umschaltet.
TECHNISCH
Globale Variante der nativen Pipeline. Erst Feature-Extraktion + Matching wie Q4, dann Relativ-Pose-Schätzung für alle verifizierten Paare, anschließend Rotation-Averaging (synchronisiert alle Kamera-Rotationen im Welt-Koordinatensystem) und Translation-Averaging (LSQR-basiert auf einer matrix-freien Sparse-Formulierung, um Integer-Overflow bei großen Kamera-Mengen zu vermeiden). Skaliert auf ~5 000 Kameras im Prinzip, in der Praxis Quality-degraded oberhalb einiger Hundert Kameras — die Phase-3.8-§5-Akzeptanz-Gate-Messung auf K-1351 ergab finalLoss 0.07 statt der angestrebten 0.0115. Wird als „Fallback-Tier" gehandhabt: kommt zum Einsatz, wenn der inkrementelle Mapper degeneriert, wird selbst aber nicht erneut auf Qualität geprüft.
Q6 — Metashape / COLMAP-Text-Workspace Import (Phase Q7)
WO
File-Menü → „Import COLMAP / Metashape Workspace…" (Cmd+⇧+I). Drag-and-Drop eines Ordners mit sparse/0/cameras.{bin,txt} und images/.
TECHNISCH
Erkennt automatisch, ob ein per Drag-and-Drop oder Open-Panel ausgewählter Ordner einer der drei COLMAP-Workspace-Layouts entspricht (sparse/0/, sparse/, oder Root) und ob die Reconstruction binär (cameras.bin) oder Text (cameras.txt) vorliegt. Der binäre Pfad nutzt den COLMAP-Binär-Parser, der Text-Pfad den ETH3D-Loader — beide produzieren dasselbe SfM-Ergebnis-Modell und der Rest der Pipeline (Bilder importieren, MCMC-Training starten) ist agnostisch gegenüber der Quelle. Die Bilder werden über das App-Sandbox-Bookmark-System security-scoped geöffnet, sodass der Import auch in der App-Store-Version funktioniert. Speziell für den Fall „Metashape-Export ohne Rekonstruktion neu rechnen" gedacht. Die im File-Menü-Eintrag erwähnte Erkennung warnt im App-Log, falls der gewählte Ordner kein erkennbarer Workspace ist.
Welches Backend wann?
| Szenario | Empfohlenes Backend |
|---|---|
| Objekt-Scan, 50–200 Fotos | Q1 Apple Photogrammetry |
| Großer Outdoor / Drohne / >500 Bilder | Q6 Workspace-Import (in Metashape oder COLMAP rechnen, dann einladen) |
| Metashape/RealityCapture-Export liegt vor | Q6 Import (kein SfM nötig) |
| ETH3D / akademisches COLMAP-Text-Set | Q3 COLMAP-Text-Import |
| Strikt App-Store-konform + Orbit-Szene | Q4 Native inkrementell |
| Q4 schlägt fehl | Q5 Native global (automatisch) |
| ETH3D-Benchmark-Daten | Q3 (autotest precomputed) |
Schnell-Vergleich
| Backend | App-Store | Sandbox | Externe Binary | Best Use | Max ~Cams |
|---|---|---|---|---|---|
| Q1 Apple PG | ✅ | ✅ | — | Orbit-Object | ~300 |
| Q2 COLMAP Binary | ❌ (nur Developer-Build) | — | colmap/glomap | Outdoor large | ~5 000 |
| Q3 COLMAP-Text-Import | ✅ | ✅ | — | Bench rigs | ~1 500 |
| Q4 Native incremental | ✅ | ✅ | — | Orbit-Object | ~200 |
| Q5 Native global | ✅ | ✅ | — | Q4-Fallback | ~1 351 |
| Q6 Workspace-Import | ✅ | ✅ | — | Metashape-Reuse | per Quelle |