Files
sky-map-ai/ARCHITECTURE.md
vohorgeez 82bdc36a46
SkyMap AI / test-workflow (pull_request) Successful in 5s
docs(architecture): documentation des choix de pipelines
2026-08-03 19:03:20 +02:00

3.8 KiB

Architecture - Interactive AI-Augmented Sky Map (v1)

Vue d'ensemble

Le v1 est scopé en pipelines indépendants, volontairement non reliés entre eux. Le matching entre pipelines (faire correspondre une étoile détectée dans une image réelle avec une entrée du catalogue Hipparcos, ou un blob avec un objet Messier classifié) est explicitement reporté à une itération ultérieure (v2+).

Cette séparation permet de développer, tester et valider chaque pipeline isolément, sans dépendance croisée prématurée.

Pipeline A - Carte du ciel depuis le catalogue

Objectif : générer une représentation visuelle du ciel à partir de données catalogue (coordonnées célestes), sans aucune image réelle en entrée.

  1. Chargement du catalogue Hipparcos pré-traité (CSV, cf. modèle de données)
  2. Parsing en structure exploitable (RA/Dec/magnitude/nom)
  3. Projection des coordonnées célestes (RA/Dec) vers un plan 2D
  4. Rendu de la carte du ciel dans Streamlit (overlay des points projetés)

Entrée : CSV Hipparcos pré-traité Sortie : carte du ciel visuelle (image/rendu Streamlit)

Pipeline B - Détection d'étoiles sur image réelle

Objectif : identifier la position d'étoiles (blobs lumineux) dans une image test fixe, sans référence au catalogue.

  1. Input : image test fournie
  2. Détection de blobs (seuillage adaptatif, DoG)
  3. Clustering pour nettoyer le bruit
  4. Déduction des coordonnées relatives des étoiles détectées dans l'image

Entrée : image test (fichier image) Sortie : liste de coordonnées (x, y) des étoiles détectées dans l'image

Pipeline C - Classification Messier / non-Messier

Objectif : déterminer si une image donnée, cadrée sur un objet du ciel profond, représente un objet du catalogue Messier ou non. Indépendant du pipeline B : ne prend pas en entrée les blobs détectés dans une image de test, mais des vignettes dédiées, préparées et labellisées à l'avance.

C0 - Acquisition du dataset

  • Scraping d'images labellisées positives (objets Messier, source : SEDS ou équivalent - vérifier conditions d'usage avant implémentation)
  • Scraping d'images labellisées négatives (objets NGC hors-Messier, choisis comme négatifs "durs" pour un entraînement plus discriminant)
  • Structuration du dataset (manifeste image - label)

C1 - Entraînement du modèle

  1. Chargement du dataset de vignettes
  2. Redimensionnement
  3. Normalisation & filtrage (traitement d'image)
  4. Fit du modèle (train/test split, fine-tuning léger MobileNet ou ViT-tiny)
  5. Evaluation (métriques, matrice de confusion)

C2 - Modèle opérationnel (inférence)

  1. Chargement de l'input (nouvelle vignette)
  2. Pré-traitement (redimensionnement, normalisation & filtrage) - symétrique à C1
  3. Soumission au modèle entraîné
  4. Output : réponse booléenne (Messier / non-Messier)

Note : l'identification formelle de l'objet (nom, caractéristiques) en cas de classification positive est explicitement hors scope v1. C'est une amélioration identifiée pour une itération ultérieure (passage à une classification multi-classe).

Ce qui est explicitement hors scope v1

  • Matching entre pipelines (A/B, B/C, A/C)
  • Classification multi-classes (identification précise de l'objet Messier)
  • Toute entrée caméra live (v1 = images statiques uniquement)

Décisions techniques actées

  • Catalogue source : Hipparcos, pré-traité offline via astropy en CSV propre (RA, Dec, magnitude, nom) plutôt que parsé à la volée dans l'application
  • Git : workflow trunk-based, branche main protégée, branches courtes nommées par fonction (feat/..., chore/...), Conventional Commits, versioning via tags Git
  • CI/CD : squelette actif dès le 3 août 2026 (déclenché sur PR), tests réels à introduire début septembre environ.