ClarkeMask : script PixInsight qui masque les traînées de satellites géostationnaires, brute par brute, dans WBPP

[jpsc01]

Près de l'équateur céleste (Orion, Monoceros, la Tête de Cheval…), la cible reste toute la nuit sur la ceinture de Clarke :

chaque brute récolte plusieurs traînées de géostationnaires, fines, parallèles, serrées dans une même bande.

La réjection n'est pas faite pour ça : une traînée qui revient au même endroit dans une bonne part des brutes n'est plus une valeur aberrante, et écarter les brutes touchées reviendrait à écarter presque toute la session.

 

ClarkeMask répare au lieu d'écarter. La direction des traînées est connue : un géostationnaire dérive par rapport aux étoiles à déclinaison constante, et cette direction se lit dans la solution astrométrique.

Le script cherche les traînées droites, fines et continues dans cette direction, à 2,5° près (réglable, pour les géosynchrones inclinés ; jusqu'à 7° si la longueur colle à la dérive sidérale pendant la pose), et met à 0 les seuls pixels qu'elles couvrent.

L'intégration de WBPP rejette déjà les 0 : chaque pixel est empilé à partir des brutes propres à cet endroit, et le nombre de valeurs varie d'un pixel à l'autre. Avions et satellites bas sont seulement signalés, la réjection classique s'en charge.

 

Dans WBPP : script d'événement lancé juste après la registration, avant LN et intégration. Rien d'autre à changer. Mono et OSC.

 

Seul, depuis son dialogue : prévisualisation, chaque brute avec son masque en surimpression, copies masquées avec 0 (PixInsight) ou NaN (autres empileurs). Bilan du coût des masques : brutes perdues au pire endroit, pose et SNR conservés, carte de la pose conservée pixel par pixel.

 

Détection en parallèle sur tous les cœurs avec PixInsight 1.9.5, résultats identiques au mode série ; série en 1.9.4.

 

Prérequis : une solution astrométrique dans la brute de référence au moment de la registration.

Le plate solving de WBPP ne résout que les masters, après l'intégration. Il faut donc un WCS écrit à l'acquisition (l'ASIAIR le fait), ou résoudre la référence avec ImageSolver avant WBPP.

 

Installation : Resources > Updates > Manage Repositories, ajouter https://jps-34.github.io/ClarkeMask/ (dépôt non signé pour l'instant : cocher « Allow unsigned update repositories »), puis Check for Updates. Dans WBPP, onglet Pipeline, cadre Event Script : choisir ClarkeMask-WBPP.js (son chemin est affiché en bas du dialogue).

 

Sources, README FR / EN et toutes les heuristiques du détecteur (DETECTOR.md) : github.com/jps-34/ClarkeMask. Licence MIT.

 

Code écrit avec Claude, sous ma direction, testé sur mes propres données. Retours bienvenus, surtout reproductibles : ClarkeMask.log et trails.csv du dossier ClarkeMask de la sortie WBPP, nom de la brute de référence. Un cas est à l'étude : des brutes de part et d'autre d'un retournement au méridien, dont la solution convertie par PixInsight serait fausse du côté retourné.

[jpsc01]

hello @nico1038

 

tu peux updater le script en 0.2.1 c'est normalement corrigé, merci encore

0.2.1 (2026-10-27)

• Trail direction checked against the trails: a mirrored astrometric solution (wrong parity, shown as "flipped" by PixInsight, seen with some WCS written at acquisition) gave the mirrored direction, and nothing was masked in the whole group. The engine now detects along the direction and its mirror on up to three frames and uses the one where the trails are, with a line in the log; when neither shows a trail, the log says so instead of masking nothing silently. Reported by nico1038, thanks.
• Documentation and messages: the plate solving of WBPP only solves the masters, after integration; the frames need a WCS written at acquisition, or a reference solved with ImageSolver.

[nico1038]

Je vais tester ça dès que possible.

 

Je me permet aussi d'ajouter une petite vidéo qui illustre bien ce problème des géostationnaires et qui permet de comprendre pourquoi ces traces sont dures à rejeter.

 

Blink.avi

 

Modifié Mardi à 13:09 par nico1038

[nico1038]

J'ai testé le script sur un empilement de 172 images de la nébuleuse de la sorcière et tout fonctionne bien avec cette version et le résultat est impecable.

 

Sans le script, malgré le nombre d'images important, les algorithmes de réjection ne s'en sortent pas et il reste des traces des sattelites sur le masterlight (empilement de 172 images avec l'algorithme GESD, étoiles enlevées pour mieux révéler le problème).

 

Après avoir tester pas mal d'algorithme et de réglage du process ImageIntegration, je sais qu'on peu légèrement améliorer les choses mais je n'ai jamais réussi à me débarrasser complètement de ces traces.

 

En utilisant en préalable à l'intégration le script  ClarkeMask  sur les images alignées, le résultat est sans appel: je ne vois plus aucune traces des satellites sur le masterlight!

 

Merci pour le script!

 

Nico

[jpsc01]

merci à toi une fois de plus, c'est complètement dingue les avancées qu'on fait en ce moment.
je passe en GPLv3 car quelque chose me dit que c'est disons nécessaire

[Tromat]

Ca va trop vite pour moi, j'ai pas tout suivi. Donc ça ne marche que pour les géostationnaires et il faut une réduction astrométrique sur chaque brute ?

[Tromat]

Il y a 4 heures, jpsc01 a dit :

Event Script

Le sujet est subsidiaire mais tu pourrais en dire plus sur ça ? Je ne savais pas qu'on pouvais exécuter des scripts externes dans WBPP. Ca pourrais m'intéresser pour d'autres sujets.

[jpsc01]

il y a 46 minutes, Tromat a dit :

Le sujet est subsidiaire mais tu pourrais en dire plus sur ça ? Je ne savais pas qu'on pouvais exécuter des scripts externes dans WBPP. Ca pourrais m'intéresser pour d'autres sujets.

oui c'est un truc vraiment génial je trouve
tu vois le script Pixinsight /Script/batch processing/weightedBatchpreprocessing ?
et bien tu peux rajouter un event dans le pipeline. et la c'est magique, tu pointe le script specifique WBPP
et voila
de mon depot

Il y a 1 heure, Tromat a dit :

Ca va trop vite pour moi, j'ai pas tout suivi. Donc ça ne marche que pour les géostationnaires et il faut une réduction astrométrique sur chaque brute ?

pour l'instant le coup du mask oui c'est que pour les Geo, et pas besoin de reduction astrométrique, on en aurait perdu avec la complexite des plate solve

mais attends toi a voir une option mask apparaitre sur starlingsweeper  comme ca on perdra beaucoup moin de signal (on évite de mettre a la beine les brutes rayées par les trains précoce Starlink pour rester poli)

Modifié Mardi à 17:51 par jpsc01

[Tromat]

il y a 18 minutes, jpsc01 a dit :

(on évite de mettre a la beine les brutes rayées par les trains précoce Starlink pour rester poli)

C'est clairement ce que j'attends  Je galère souvent avec les traces de satellite, surtout en RGB car je fais peu de poses. Vivement la suite et merci pour le boulot effectué !

il y a 19 minutes, jpsc01 a dit :

et la c'est magique, tu pointe le script specifique WBPP

Il faut que le script en question soit prévu pour une utilisation avec WBPP par contre, non ?

[jpsc01]

Il y a 1 heure, Tromat a dit :

 

Il faut que le script en question soit prévu pour une utilisation avec WBPP par contre, non ?

et oui, c'est pour ca qu'à ce stade, la methode du mask qui set les pixels à zero a été pensé parcque WBPP le supporte: qd pixel=0 WBPP le sort de l'integration
mon prochain chantier sera de voir si ca passe avec APP, ce que j'utilise pour le pre-traitement

c'est @nico1038qui m'a convaincu d'investiguer car c'est une tuerie pour  les Geostationnaire

Modifié Mardi à 20:01 par jpsc01