L'idée a germé suite au magnifique soft astromestro de @Fabiolat74 mais avec lequel je dois rentrer des réglages et c'est la mon problème
Ce script ne fait qu'orchestrer les différents outils spécialisés que nous utilisons , siril, les cripts graxpert, starnet ou BXT, SXT, une copie de Veralux utilisable sans l'interface écran, ....
Il travaille pour le moment sur des stacks couleur issus de Siril ou de Sharpcap.
Je suis pour le moment en test. Voici la documentation généré pour ceux que ça intéresse.
Je mettrais les progrès ici et quand il sera un peu plus finalisé, le script lui même.
Si vous avez des recommandation de traitement en fonction des types d'objets, je suis preneur car si je fais ce script, c'est justement parce que j'ai du mal à traiter mes images manuellement.
Méthode de traitement Astro — Pipeline automatisé v3.8.1
____________________________________________________________Document de référence à jour. Décrit le pipeline complet exécuté par agent_siril_llama.py, ses réglages par défaut, et le raisonnement derrière chaque choix technique.
1. Vue d'ensemble du pipeline
Code : Tout sélectionner
FITS brut empilé
│
├─ 1. Lecture metadonnees FITS + resolution profil capteur VeraLux
├─ 1bis. Resolution des parametres de traitement (defauts par type de cible,
│ confirmation interactive) — cf. §1bis ci-dessous
├─ 2. Alignement Base de connaissances (RAG — présent dans le code, non utilisé
│ dans les décisions actuelles, cf. §4)
├─ 3. Calibration (Siril) : crop 3% + platesolve FORCÉ (-force)
├─ 4a. GraXpert : extraction gradient (script intégré Siril, pyscript -bge)
│ → SPCC → débruitage (script intégré Siril, pyscript -denoise)
├─ 4b. Sharpening/Déconvolution : BXT (RC-Astro) par défaut, calibré par dichotomie
│ [alternative : GraXpert -deconv_obj/-deconv_stellar]
├─ 5. Séparation étoiles/starless : SXT (RC-Astro) par défaut
│ [alternative : StarNet natif Siril]
├─ 6. Étirement de la galaxie (starless) : VeraLux headless fidèle au GUI
├─ 7. Étirement du masque d'étoiles : asinh natif Siril, ancrage par RANG,
│ calibré par comptage réel d'étoiles (findstar)
├─ 8. Recomposition PixelMath (screen blend) + boost de saturation optionnel
└─ Rapport de diagnostics JSON consolidé (une entrée par étape, versions tracées)
1bis. Résolution des paramètres par type de cible (nouveau, v3.5.0)
Avant tout traitement, le script résout et affiche la valeur finale de tous les paramètres de traitement (pas seulement ceux ci-dessous), avec leur origine :
- CLI explicite : l'utilisateur a tapé le commutateur — toujours prioritaire
- defaut type '{type}' : pas spécifié en CLI, mais un type de cible est détecté et propose une valeur pour ce paramètre (cf. §3 pour la table complète)
- defaut generique : ni CLI, ni type — valeur par défaut historique du script
Cible inconnue (v3.6.0) : si cibles_info.json ne contient pas la cible, ou que son type_objet ne matche aucun mot-clé connu, le script demande interactivement le type (menu numéroté) — plus besoin de rechercher manuellement à chaque nouvelle cible. La réponse est enregistrée dans cibles_info.json (champ type_cible exact) : la question n'est posée qu'une seule fois par cible, les runs suivants la retrouvent automatiquement. Sautée si --je-sais-ce-que-je-fais (aucun défaut appliqué dans ce cas) ou si --type-cible a déjà été forcé explicitement.
Dès qu'un type de cible est détecté, une confirmation interactive est demandée avant de lancer le traitement (Entrée pour valider tel quel, defaut pour appliquer les défauts du type à tous les paramètres concernés — y compris ceux déjà spécifiés en CLI). Le commutateur --je-sais-ce-que-je-fais saute cette confirmation (utile pour l'automatisation/les scripts).
Ces valeurs par type (TYPE_CIBLE_DEFAULTS dans le code) sont des valeurs représentatives choisies à dire d'expert, dérivées des plages du tableau §3 — contrairement au reste du pipeline (décisions chiffrées à partir de stats réelles), elles n'ont pas encore été validées empiriquement type par type. À ajuster au fil des tests (cf. §3).
Tout est tracé dans le rapport JSON, section 00b_parametres_resolus.
Reprise partielle (--start-from) : chaque étape ci-dessus (calibration, graxpert, sharpening, separation, veralux, starmask, recomposition) peut servir de point de départ, en réutilisant les fichiers déjà produits sur disque par un run précédent — utile en débogage pour ne pas rejouer les étapes longues (débruitage GPU notamment) à chaque test d'un réglage en aval.
____________________________________________________________
2. Étape par étape : logique et réglages par défaut
2.1 Calibration (Siril natif) — ordre revu (constat session vdB 126)
- crop 3% 3% 94% 94% : retire les 3% de bord de chaque côté (artefacts d'empilement/registration) — fait en premier
- platesolve -force : résolution astrométrique forcée. Piège identifié : la solution embarquée dans le header (écrite au stacking) ne correspond plus à la grille de pixels une fois l'image recadrée. Un platesolve simple verrait "déjà résolu" et ne ferait rien, laissant une solution périmée. Le flag -force force une nouvelle résolution malgré le header.
- GraXpert : extraction de gradient (script intégré Siril, pyscript "GraXpert-AI.py" -bge), sur l'image recadrée/re-résolue — avant le spcc
- spcc : étalonnage spectrophotométrique des couleurs (catalogue Gaia DR3 local), sur l'image sans gradient. Avant ce changement d'ordre, le SPCC tournait sur une image avec gradient de fond de ciel non corrigé, et Siril avertissait explicitement : *"L'étalonnage photométrique des couleurs semble avoir trouvé une solution imprécise, pensez à corriger d'abord le gradient de l'image"* — observé sur vdB 126 (champ à fort gradient, proche de l'horizon, airmass 1.40).
- Diagnostic : instantané DIAG_post_calibration_{nom}_{horodatage}.jpg/.fits sauvegardé à cette étape (avant tout traitement GraXpert), pour comparaison a posteriori.
- CORRECTION MAJEURE (constat vdB 126) : gradient et débruitage passent par le script intégré Siril (pyscript "GraXpert-AI.py" -bge / -denoise), et non par un appel CLI externe direct à l'exécutable GraXpert autonome. La documentation Siril confirme que cette ancienne méthode CLI a été explicitement dépréciée et retirée du code de Siril lui-même ("proved unreliable for a significant minority of users"). Des artefacts en anneaux noirs autour de certaines étoiles, présents dès la sortie de l'extraction de gradient via CLI externe, disparaissaient en refaisant la même étape manuellement dans Siril (donc via le script intégré) — confirmé par test A/B manuel, et confirmé résolu sur le run suivant avec le script corrigé.
- Gradient : pyscript "GraXpert-AI.py" -bge -smoothing=0.5 -correction=subtraction. Réglable via --graxpert-gradient-smoothing (corrigé à 0.5, qui est à la fois le vrai défaut de l'interface GraXpert/Siril et la pratique manuelle habituelle d'Alain — 0.1 était une erreur de configuration initiale, pas un choix délibéré).
- Force de débruitage : pyscript "GraXpert-AI.py" -denoise -strength=X, calculée automatiquement via le ratio bgnoise/médiane de l'image calibrée, ou forcée manuellement via --graxpert-denoise-strength (utile pour isoler un problème observé)
- ratio > 0,05 → force 0,85 (image très bruitée)
- 0,02 ≤ ratio ≤ 0,05 → force 0,70 (standard)
- ratio < 0,02 → force 0,45 (signal propre, préserve les détails)
- Diagnostics : instantanés DIAG_post_gradient_{nom}_{horodatage}.jpg/.fits (après gradient+SPCC, avant débruitage) et DIAG_post_denoise_{nom}_{horodatage}.jpg/.fits (après débruitage, avant sharpening) — permettent d'isoler à quelle sous-étape un défaut apparaît.
BXT (BlurXTerminator, RC-Astro) — moteur par défaut :
- Détection automatique du PSF depuis les vraies étoiles de l'image (pas de calcul théorique nécessaire)
- sharpen-stars : 0,3 par défaut
- sharpen-nonstellar : calibré par dichotomie si activée (défaut), sinon fixe via --bxt-sharpen-nonstellar
- adjust-star-halos : 0,0 par défaut (peut être mis à négatif pour réduire un halo optique réel)
- Recherche la force sharpen-nonstellar la plus élevée qui n'augmente pas le bgnoise au-delà de 5% de la référence (mesurée juste après débruitage)
- 5 itérations, bornes [0,0 ; 0,8]
- Coût : ~1 min par itération (appel GPU réel) → ~5 min supplémentaires par image
- Limite connue : le bgnoise global ne détecte pas les artefacts locaux fins (halos, ringing autour des étoiles) — reste un indicateur de bruit, pas de qualité globale
- psfsize calculé depuis le FWHM du header FITS (HISTORY du stacking) ou théorique (échantillonnage = 206265 × taille_pixel_µm / focale_mm, seeing supposé 2,5")
2.4 Séparation étoiles/starless — SXT (défaut) ou StarNet
SXT (StarXTerminator, RC-Astro) — moteur par défaut, jugé nettement supérieur à StarNet sur la propreté du fond et la préservation des petites galaxies en arrière-plan.
- Produit starless_{nom}.fits et un fichier -stars renommé automatiquement en starmask_{nom}.fits
2.5 Étirement de la galaxie — VeraLux headless
Réplique fidèle du moteur VeraLux (mode Ready-to-Use), extrait du script officiel (sans GUI/PyQt6), exécuté via pyscript :
- target_bg : 0,20 par défaut (valeur par défaut du GUI VeraLux)
- protect_b : 6,0 par défaut
- convergence (Star Core Recovery) : 3,5 par défaut
- color_grip : 1,0 (préservation vectorielle pure des couleurs)
- Le log_D est résolu automatiquement par dichotomie (comme le fait le vrai solveur VeraLux)
- Diagnostic de stretch faible : le rapport calcule facteur_stretch_vs_fond_brut (= target_bg / fond de ciel brut normalisé). Si < 3x, avertissement affiché — signe que le fond brut est déjà proche de la cible (champ à fort gradient/pollution lumineuse/airmass élevé), donc que VeraLux n'éclaircira quasiment rien de visible même si le calcul est correct. Constat vdB 126 : facteur ~1,6x avec target_bg=0.08, contre ~50x pour M101 avec 0,12.
Historique des tentatives (v1 → v3), pour mémoire :
autostretch générique : sur-étire un masque quasi vide, transforme le bruit en pastilles colorées- Clip percentile dur + courbe de puissance : crée un bord net visible (anneau) autour des halos
- Ouverture morphologique (top-hat) : introduit des artefacts en aigrettes de diffraction, perd des étoiles faibles
- Réimplémentation arcsinh maison sans ancre : dérivée qui explose près de zéro, même résultat que l'autostretch raté
v1 : asinh natif Siril, mais étoile de référence = toujours le percentile fixe 99,99 (la plus brillante du champ). Casse si cette étoile est déjà très lumineuse en brut (constat vdB 126, HD 182918 à ~31% du plein format) : stretch résolu quasi nul (~8x), étoiles faibles invisibles.- v2 : étoile de référence = anchor_percentile + marge fixe (en points de percentile). Casse aussi : un masque d'étoiles est >99,9% de pixels quasi nuls — quelques points de percentile ne bougent quasiment rien tant qu'on reste dans ce "bloc de zéros". Peut atterrir sur du bruit de fond, avec un stretch qui explose jusqu'au plafond pour compenser (observé : stretch=200000, fond amplifié en grésillement).
v3 (retenue) : étoile de référence choisie par RANG plutôt que par percentile — le cible_count-ième pixel le plus lumineux, où cible_count est déjà connu (dérivé du ratio d'étoiles visé). Directement dérivé de la quantité qui nous intéresse réellement (combien d'étoiles on vise), sans navigation à l'aveugle dans l'espace des percentiles. Le stretch s'adapte alors automatiquement à la population d'étoiles réellement visée, sans réglage manuel nécessaire : ratio élevé (beaucoup d'étoiles, y compris faibles) → étoile de référence plus faible → stretch fort ; ratio bas (peu d'étoiles, les plus brillantes) → étoile de référence déjà lumineuse → stretch plus doux. Vérifié numériquement stable sur distribution synthétique réaliste (contrairement à v2) et confirmé sur run réel (vdB 126 : stretch passé de valeurs extrêmes/instables à ~540, avec gradation visible entre étoiles faibles et brillantes).
autostretch générique : sur-étire un masque quasi vide, transforme le bruit en pastilles colorées
v3 (retenue) : étoile de référence choisie par RANG plutôt que par percentile — le cible_count-ième pixel le plus lumineux, où cible_count est déjà connu (dérivé du ratio d'étoiles visé). Directement dérivé de la quantité qui nous intéresse réellement (combien d'étoiles on vise), sans navigation à l'aveugle dans l'espace des percentiles. Le stretch s'adapte alors automatiquement à la population d'étoiles réellement visée, sans réglage manuel nécessaire : ratio élevé (beaucoup d'étoiles, y compris faibles) → étoile de référence plus faible → stretch fort ; ratio bas (peu d'étoiles, les plus brillantes) → étoile de référence déjà lumineuse → stretch plus doux. Vérifié numériquement stable sur distribution synthétique réaliste (contrairement à v2) et confirmé sur run réel (vdB 126 : stretch passé de valeurs extrêmes/instables à ~540, avec gradation visible entre étoiles faibles et brillantes).- blackpoint = percentile bas de la luminance, piloté par anchor_percentile (plancher, ce qui est en dessous devient noir net)
- stretch = résolu par dichotomie pour que l'étoile de référence (choisie par rang, cf. ci-dessus) atteigne une valeur de sortie cible (--starmask-asinh-cible-sortie, défaut 0,6)
- Calibration de l'ancre (anchor_percentile) par comptage réel d'étoiles (findstar de Siril, pas une estimation) : détecté automatiquement, cf. §2.6bis) jusqu'à approcher la cible fixe jamais supprimé avant chaque appel — sur un même fichier inchangé, le compte pouvait varier d'un run à l'autre (228/897/492 étoiles observées sur NGC 7023) en relisant un résultat périmé d'un appel précédent. Même classe de bug que les fichiers JSON pyscript déjà corrigés (cf. §5) ; si un comptage de référence semble incohérent d'un run à l'autre sans qu'aucun fichier n'ait changé, vérifier qu'on est bien en v3.5.1 ou plus.
- Référence = nombre d'étoiles détectées sur l'image calibrée (avant tout retrait)
- Cible = ratio × référence (--starmask-cible-ratio-etoiles, défaut 0,8)
- Dichotomie sur anchor_percentile (bornes 85-99, élargies à 60-99 si champ dense
- Peu coûteux (pas de GPU, quelques secondes par itération)
- *(corrigé en v3.5.1)* Le comptage de référence écrivait dans un fichier temporaire à chemin - Rampe linéaire (v4.0, remplace le filet de sécurité fixe v2/v3) (etoile_deja_brillante_detectee dans le JSON) : si même l'étoile de référence choisie par rang reste brillante en brut (seuil --starmask-seuil-l-star-brillant, défaut 0,15), la cible de sortie augmente linéairement avec l'écart entre L_star et le seuil (--starmask-pente-rampe-cible, défaut 0,48 ; point de départ --starmask-cible-sortie-si-deja-brillant, défaut 0,78 ; plafond --starmask-cible-rampe-max, défaut 0,95) — cf. encadré ci-dessous.
2.6bis Champ dense (détection automatique)Constat vdB 126 → NGC 7023 → Sh2-136 (0,90 → 0,78 → rampe linéaire) : la valeur fixe 0,90 donnait un bon rendu sur vdB 126 (champ dense, L_star≈0,31) mais sursaturait NGC 7023 (champ clairsemé, L_star≈0,21 — stretch_calcule plafonnait à 200 000). Baisser à 0,78 (fixe) a corrigé les deux cas... jusqu'à Sh2-136 (Ghost Nebula, L_star≈0,46 — étoiles jeunes multiples très lumineuses) : stretch_calcule retombait à 16 (quasi aucune amplification), symétrique du problème initial. Aucune constante fixe ne peut convenir à la fois à L_star≈0,21 et L_star≈0,46 — confirmé numériquement (cible=0,78 donne un stretch sain pour NGC7023 mais quasi nul pour Sh2-136 ; cible=0,90 fait l'inverse). Remplacé par une rampe linéaire continue : `cible = min(cible_max, cible_si_brillant + pente × (L_star − seuil))`, calibrée sur les deux points connus (NGC7023 : 0,21→0,78 ; Sh2-136 : 0,46→~0,90, pente ≈ 0,48). Vérifié numériquement sans régression sur M101 (jamais déclenché) et avec un résultat sain sur les 3 cas connus avant déploiement — mais pas encore validé empiriquement en conditions réelles sur Sh2-136 (seule la formule est vérifiée ; à confirmer sur le prochain run). Si un futur cas contredit encore la rampe, la piste suivante serait probablement de coupler la pente à la densité du champ plutôt que de continuer à ajuster une seule pente globale.
- Densité mesurée : étoiles détectées / mégapixels sur l'image calibrée
- Seuil : 250 étoiles/MP (calibré sur M101 ≈ 121/MP = champ normal, vs vdB 126 ≈ 500-700/MP = champ dense, proche du plan galactique)
- Si dense : bornes de calibration élargies (85-99 → 60-99) et itérations augmentées (6 → 8), pour permettre à la dichotomie d'atteindre des ratios d'étoiles plus élevés sans buter contre la borne basse par défaut
- Screen blend PixelMath : 1 - (1-galaxie)×(1-étoiles)
- Boost de saturation optionnel (désactivé par défaut, facteur=1.0) : éloigne chaque pixel de son niveau de gris proportionnellement à un facteur
3. Réglages recommandés par type de cible
Depuis la v3.5.0, ce tableau est aussi codé en dur dans TYPE_CIBLE_DEFAULTS (agent_siril_llama.py) sous forme de valeurs uniques représentatives par type (pas des plages), et appliqué automatiquement via --type-cible (cf. §1bis). Ce tableau reste la référence "raisonnement humain" ; le code doit être tenu synchronisé s'il évolue.Point de départ raisonné, pas une vérité absolue — à ajuster empiriquement. Galaxies (M51, M101) et nébuleuse par réflexion en champ dense (vdB 126) testées en profondeur cette session ; les autres lignes restent des points de départ moins validés.
Galaxie
- target_bg : Modéré (0,12-0,15)
- protect_b : Bas-modéré (2-4)
- bxt-sharpen-nonstellar : Élevé, dichotomie activée
- bxt-adjust-star-halos : 0 à léger négatif
- saturation-boost : Modéré (1,2-1,4)
- starmask-cible-ratio : Modéré (0,6-0,8)
- target_bg : Plus bas (0,08-0,12)
- protect_b : Plus haut (5-8)
- bxt-sharpen-nonstellar : Modéré-bas
- bxt-adjust-star-halos : Neutre à léger négatif
- saturation-boost : Attention à la sur-saturation du rouge
- starmask-cible-ratio : Modéré
- target_bg : Vérifier facteur_stretch_vs_fond_brut (cf. §2.5) — peut nécessiter > 0,10-0,20 sur champ dense/airmass élevé
- protect_b : Haut (6-10)
- bxt-sharpen-nonstellar : Bas (0,3), dichotomie désactivée
- bxt-adjust-star-halos : Négatif marqué (-0,3 à -0,5)
- saturation-boost : Modéré
- starmask-cible-ratio : Bas-modéré (0,5-0,6)
non testé
- target_bg : Modéré-bas (~0,12)
- protect_b : Haut (~8)
- bxt-sharpen-nonstellar : Dichotomie activée (vraie structure fine en coquille)
- bxt-adjust-star-halos : Négatif modéré (~-0,3)
- saturation-boost : Un peu plus poussé (~1,2, contraste bleu-vert/rouge marqué)
- starmask-cible-ratio : Bas-modéré (~0,6)
- target_bg : Peu pertinent (pipeline simplifié, cf. §4)
- protect_b : Haut
- bxt-sharpen-nonstellar : Bas (pas de structure étendue à sharpener)
- bxt-adjust-star-halos : Négatif marqué
- saturation-boost : Modéré (préserver couleurs réelles)
- starmask-cible-ratio : Élevé (0,8-1,0)
- target_bg : Bas-modéré
- protect_b : Haut
- bxt-sharpen-nonstellar : Bas-modéré
- bxt-adjust-star-halos : Négatif marqué
- saturation-boost : Modéré
- starmask-cible-ratio : Élevé
Logique derrière chaque colonne :
- target_bg doit être évalué relativement au fond de ciel brut, pas comme une valeur absolue universelle — un champ à fort gradient/pollution lumineuse/airmass élevé a un fond brut déjà haut, et une valeur qui fonctionne bien sur un champ propre peut donner un facteur de stretch quasi nul ailleurs (cf. §2.5, diagnostic facteur_stretch_vs_fond_brut).
- protect_b monte quand il y a des étoiles brillantes à protéger (nébuleuses à émission/réflexion ont souvent une étoile centrale dominante, amas = beaucoup d'étoiles brillantes serrées) — plus que la galaxie typique, où le cœur est plus étendu/doux.
- bxt-sharpen-nonstellar baisse pour les cibles "gazeuses" (nébuleuses) : pas de structure fine comparable aux bandes de poussière d'une galaxie ; sur-affûter du gaz lisse crée une texture artificielle plutôt que révéler du vrai détail. Sur champ dense (vdB 126), la dichotomie a plutôt tendance à converger vers des valeurs élevées (~0,7-0,8) car le critère bgnoise global ne pénalise pas ce sur-affûtage local — désactiver la dichotomie et fixer une valeur basse (0,3) est alors plus fiable que de la laisser se calibrer.
- bxt-adjust-star-halos négatif devient critique dès qu'une étoile brillante isolée est LE sujet (réflexion, amas) plutôt qu'un détail secondaire.
- Amas d'étoiles = pipeline simplifié (v3.8.0) : pour le type amas (sans nébulosité), la séparation SXT/StarNet et le masque d'étoiles distinct sont sautés entièrement — constat M13 (amas globulaire) : SXT introduisait une texture en grille (artefact probable de tuilage GPU) sur ce type de cible, où la starless n'a de toute façon pas de sens (l'image *est* des étoiles, structurellement). VeraLux gère déjà nativement les étoiles (protect_b, convergence/Star Core Recovery, star_pressure) — conçu à l'origine pour une image complète, pas nécessairement une starless séparée (la séparation était un choix d'architecture de ce pipeline, pas une exigence de VeraLux). VeraLux tourne donc directement sur l'image complète post-BXT, et sa sortie (avec boost de saturation éventuel) est directement l'image finale, sans recomposition PixelMath. Ne s'applique qu'au type amas pur — amas_nebulosite garde le pipeline complet, une vraie nébulosité y justifiant la séparation.
4. Limites connues et acceptées
- Halo optique réel autour des étoiles brillantes : confirmé présent dès la sortie de BXT (avant tout traitement de notre part) — probablement de la diffusion optique réelle du setup (C8 + réducteur). Non éliminable sans intervention matérielle ; adjust-star-halos négatif peut l'atténuer légèrement sans le supprimer.
- bgnoise global ne capture pas les artefacts locaux fins — une dichotomie basée dessus peut ne jamais être "contrainte" si BXT ne dégrade pas le bruit global même à haute force (cf. §3, cas nébuleuse par réflexion). Une inspection visuelle ciblée (zoom sur une étoile brillante et sur le fond de ciel) reste recommandée après un premier passage automatisé — les instantanés DIAG_post_* (cf. §5) servent à ça.
- Structures diffuses réelles vs artefacts : sur un champ dense proche du plan galactique (vdB 126), le fond peut contenir de vraies nébuleuses obscures (LDN, catalogue Lynds) visibles comme des filaments diffus une fois fortement étiré — à ne pas confondre avec un artefact de traitement. Confirmé sur vdB 126 par recoupement avec une image de référence annotée (AstroBin) montrant 12 LDN dans ce champ précis. Le débruitage/sharpening ne doit pas être jugé "en trop" uniquement parce que ce type de structure devient visible et parait texturé — vérifier d'abord si le motif est cohérent avec un catalogue connu avant de le traiter comme un défaut.
- RAG/LLM local (llama-server) : l'architecture existe dans le code (ChromaDB, client OpenAI local) mais n'est pas utilisée dans le flux de décision actuel. Toutes les décisions sont déterministes (stats réelles), jugées plus fiables qu'un LLM pour ce type de problème d'optimisation numérique.
5. Sorties produites par run
- {nom}_pipeline_diagnostics.json : rapport consolidé (une entrée par étape), incluant une section 00b_parametres_resolus (tous les paramètres de traitement, valeur finale, origine CLI/type/générique) et 00c_versions (version de l'agent, --start-from utilisé, horodatage du run), ainsi qu'un script_version/pyscript_version dans chaque sous-diagnostic pyscript
- DIAG_post_calibration_{nom}_{horodatage}.fits/.jpg : instantané après recadrage/platesolve, avant tout traitement GraXpert
- DIAG_post_gradient_{nom}_{horodatage}.fits/.jpg : instantané après extraction de gradient + SPCC, avant débruitage
- DIAG_post_denoise_{nom}_{horodatage}.fits/.jpg : instantané après débruitage, avant sharpening
- DIAG_post_deconv_{nom}_{horodatage}.fits/.jpg : instantané après sharpening/déconvolution, avant séparation étoiles/starless
- Ces quatre instantanés diagnostiques ne sont jamais écrasés (nom horodaté), pour permettre de comparer plusieurs runs a posteriori et d'isoler à quelle étape un défaut apparaît
- {nom}_VeraLux_Final_Recomposed.fits/.jpg : image finale
- {nom}_prompt_resume.txt : prompt prêt à copier-coller pour un résumé texte de l'image (LLM externe, cf. prompt_resume_image.md — non branché automatiquement dans le pipeline)
