Lardon3D

Moteur de reconstruction géométrique persistante et incrémentale, piloté par une TUI ncursesw.

Vision

Lardon3D est un moteur de photogrammétrie Linux qui privilégie :

• Stabilité : aucune saturation du système hôte
• Déterminisme : résultats reproductibles et traçables
• Faible consommation mémoire : traitement par lots adaptatifs
• Reprise après interruption : résultats atomiques et persistants
• Protection de la machine : budgets bornés et respectueux
• Traçabilité : historique des opérations et métriques
• Enrichissement progressif : reconstruction incrémentale

Lardon3D ne vise pas simplement "dossier de photos → objet 3D", mais un ensemble progressif d'observations et de contraintes donnant une reconstruction géométrique persistante, enrichissable et versionnable.

État actuel

Briques validées

• Project : cycle de vie persistant, identité stable et Project Database ouverte
• Import : premier task kind de production, exécuté par la file générique en lots bornés et reprenables
• ScanSet / Image Catalog v1 : acquisitions, images logiques, provenance et assets SHA-256 persistants et paginés
• Capture / Asset Provenance v1 : Captures par ScanSet, associations source/dérivé et sélection explicite d'une image logique — PASS / FROZEN
• Découverte et planification de campagne bornées : racines explicites, plan metadata-only et exécution par groupes via S3-E — PASS / FROZEN ; campagne A6000 réelle validée sur 953 ARW + 953 JPEG MPF
• Feature Store v1/v2 : ORB U8×32, SIFT/RootSIFT F32×128 et lecture typée bornée
• Image View : vues triées et filtrées pour la TUI
• Task : moteur de tâches avec pause/reprise, annulation et séquences
• Task Checkpoint v1 : snapshot durable, fichier atomique et reprise sûre
• Project Database v19 : fondations v18 préservées, avec Capture / Asset Provenance additive
• Sparse SfM Gates C/D/E : géométrie calibrée, noyau incrémental et Bundle Adjustment final par composante, tous PASS / FROZEN
• Sparse SfM Gate F : orchestration durable, runtime gouverné et publication atomique, PASS / FROZEN
• MVS-M1 : frontière externe OpenMVS v2.4.0 InterfaceCOLMAP/DensifyPointCloud, export COLMAP déterministe (OpenCV undistortion, observations transformées et tracks réels), texte exporté en flux et tracks indexés sans rescanner quadratiquement les observations ; espace de travail privé neuf par invocation sous le staging appelant, sans réemploi ; identité dense liée à la reconstruction de base, au jeu source, au calibration_scope_identity historique, au binding numérique MVS, au backend et aux paramètres ; L3DMDID2 v2 (220 octets) et binding L3DMCAL1 v1 ; PLY OpenMVS binaire little-endian validé (en-tête <= 1 MiB en octets bruts, LF/CRLF acceptés, CR seul malformé rejeté, ligne <= 64 KiB), fusionné en mode 0 — PASS / FROZEN
• Geometric Verification Model v1 : identité, masque d'inliers et modèle 3×3 persistants
• Geometric Verifier v1 : Fundamental USAC/MAGSAC, reprise et lots resource-aware
• Task Kind Registry : identité métier durable et reconstruction runtime explicite
• Recovery projet : reprise automatique sélective et bornée des imports récupérables
• Task Queue : file FIFO avec sélection adaptative et backpressure
• Hardware Profile : détection des capacités matérielles
• Resource Snapshot : capture instantanée des ressources
• Resource Governor : arbitrage centralisé des budgets et réservations

Prochaine tranche

• Exécution durable de campagne d'acquisition : confirmations et progression persistantes, matérialisation S3-E incrémentale, reprise par capture_id retenu et admission par les Task/Scheduler/Governor existants. Voir la roadmap canonique.

Plus tard / différé

• publication durable dense/mesh et scratch SSD externe optionnel gouverné ;
• workflow TUI de confirmation/progression et sources mixtes multi-ScanSet ;
• vidéo/keyframes, coverage assistance, viewer et exports ;
• DAG général, pools multiples et parallélisme inter-tâches restent différés.

Architecture

TUI / Projet
    ↓
Scheduler
    ↓
Resource Governor
    ↓
Workers
    ↓
Résultats atomiques / persistants
    ↓
Viewer (consommation passive de snapshots)

Invariants fondamentaux

• Aucun callback de tâche sans réservation active validée
• Le scheduler ne décide jamais des ressources
• Le Resource Governor est l'unique propriétaire des budgets
• ncurses appartient exclusivement au thread principal
• Les estimations de ressources sont immuables
• Les buffers et files sont strictement bornés

Pipeline cible

Acquisitions
→ catalogue
→ features
→ index visuel
→ paires candidates
→ matching
→ vérification géométrique
→ tracks / SfM
→ dense
→ mesh
→ consolidation
→ export

Documentation

Architecture

• Vue d'ensemble
• Runtime
• Système de tâches
• Registry des types de tâches
• File de tâches
• Resource Governor
• Pipeline sensible aux ressources
• Intégration Scheduler ↔ Governor
• Pipeline de reconstruction
• Persistance
• Base de données projet
• Feature Store
• Precision Feature Pipeline v1A
• Visual Index
• Candidate Pair
• Match Result
• Matcher
• Geometric Verification
• Geometric Verifier
• Track Model
• Sparse SfM / Triangulation — Gate A
• Backend Vulkan ORB
• Viewer
• Resource Boundary — No New Resource Subsystem
• Revue des fondations

Concepts

• Scan Sets
• Index visuel
• Matching et tracks
• Couches de reconstruction
• Contraintes géométriques

Développement

• Build
• Tests
• Concurrence
• Profil de performance de la machine cible

Roadmap

• Roadmap

Build rapide

CC=clang meson setup build --wipe
meson compile -C build -j8

Tests

meson test -C build --print-errorlogs
git diff --check

Pour les changements sensibles à la mémoire ou à la concurrence, ajouter ASan/UBSan et TSan.

Statut

Lardon3D est en développement actif. La persistance des tâches, le catalogue, le Feature Store multipasse, le Visual Index ORB, Candidate Pair Generator Matcher v1, Geometric Verification Model v1 et Geometric Verifier Fundamental v1 sont implémentés. Le runtime Feature + Matcher + Verifier emploie des tâches durables, de petits lots, le Resource Governor interactif et un hot path Vulkan ORB exact avec fallback CPU. La feasibility Vulkan SIFT/RootSIFT a été rejetée ; ces deux matchers restent sur OpenCV L2. Track Model/Builder, les primitives géométriques Gate C, le noyau Sparse SfM incrémental Gate D et le Bundle Adjustment final Gate E sont implémentés et validés. L'orchestration Sparse SfM Gate F est PASS / FROZEN ; l'intégration Governor Gate G est PASS / FROZEN. MVS-M1 est PASS / FROZEN : une frontière OpenMVS v2.4.0 externe et bornée, sans publication dense durable ni MVS complet. Les sources sont liées par SHA-256 complet, borné à 1 GiB par fichier régulier (sans budget agrégé de dataset) ; les octets source restent un binding distinct de l'identité dense. Celle-ci lie la reconstruction de base, le jeu d'images source, le calibration_scope_identity historique, le binding numérique de calibration MVS L3DMCAL1 v1, le backend et les paramètres dans L3DMDID2 v2 (220 octets). Chaque appel utilise un espace de travail privé neuf sous le staging appelant, sans réemploi d'une scène, profondeur, cache ou sortie antérieure. Le DAG, le viewer et les autres étapes denses restent des tickets séparés planifiés. Le Resource Governor ne constitue pas un Resource System générique : voir la décision d’architecture.

Licence

Projet privé - Tous droits réservés.