jpsc01

En phase. pour faire simple: appliquons le principe de l'opensource: -savoir créer un outil répondant à un besoin qui n'a pas encore été adressé -code en source ouverte et documenté: ca veut dire que le code est accessible et non compilé voir offusqué / chiffré etc: je parle par exemple d'outils qui circulent en ce moment avec des modules neuronaux encapsulé et chiffré qui ont pourtant été entrainé sur des outils commerciaux... -la limite acceptable et généralement bienvenue se situant au niveau des logiciels d'orchestration mettant en place des toolchain de logiciels existants. perso j'adore cette veine et il y a encore beaucoup à faire -je me repète: ne pas réinventer la roue et savoir citer les travaux des autres en ref quant on les réutilise ==> cf GPLv3 bref, avec ces quelques règles asimovienne de bon sens ca devrait bien se passer un exemple qui date de cette semaine: j'étais chaud pour faire un script Pixinsight pour retirer les halo avec une approche gradient et tout le toutim. j'ai vu qu'il y en avait déjà quelques-un comme HaloHalo. bref j'ai stoppé mon entrain et je me suis dit que j'allais le tester en long et en travers et reporter au dev des modifications si nécessaire. du savoir vivre quoi

hello attention tout de meme au nombre minimal d'image dans le stack,il t'en faut au moins 15. voir ici https://app.astrobin.com/forum/topic/260440?post=407096

exact, c'est ma faute, j'avais pas pris le bon hook le seul "inconvénient" c'est que le process consomme un peu plus d'espace disque, mais au moins je ne viens plus changer les raw image de WBPP dans le flux. la on est dans la norme

hello pour info, j'ai fait quelques correctifs car je m'intégrais mal dans le pipeline de Pixinsight, après une discussion productive avec la PTeam j'ai mis à jour StarlinkSweep en 1.4.0 avec un nouveau point d'insertion dans WBPP. tout est dans la doc (super simple) https://github.com/jps-34/StarlinkSweeper So say we all !!

et voila ! le gain effectivement est que tu as tout ca sans degrader ton SNR comme avant. big kudo au Dev de Pixinsight avec la 1.9.5 qui permet le multithread

t’inquiètes on a la même approche pour le coup en fait la je suis en train de refaire la firework en traitement full. je me souviens qu'à l'époque j'avais viré quelque brute du traitement APP car je retrouvais des traces fines par endroit de toute façon, en a d'autres qui vont faire des test poussés, moi compris

avec APP de mémoire j'avais fait pas mal de test ici J'ai zero expérience avec WBPP. je commence à l'instant ma théorie, c'est qu'il n'est pas possible de reject une bordure de trail car elle est proche du BG en fait

Le rejet élimine "plutot" bien le cœur des traînées, c'est vrai. Mais ça fait deux ans que je bataille avec ça, et le problème, ce sont les bords des traînées. Ils sont trop faibles pour être rejetés, ils passent dans le master, et c'est eux qu'on voit réapparaître à l'étirement, sous forme de lignes fantômes. Quel que soit le nombre d'images, puisque le rejet juge chaque pixel séparément. C'est pour ça que le script masque la traînée sur toute sa largeur, bords compris avec un peu de marge (aliasing ? ). Ces pixels ne comptent plus du tout, et le master est calculé à cet endroit avec les autres brutes. On ne perd rien, et il ne reste plus aucune trace c'est vraiment les satellite de starkink qui m'ont bien gavés car ils sont bas donc lumineux et donc trail large avec bord faible venant impacter les signaux faibles

Mise à jour StarlinkSweeper 1.3.0 : le masquage dans WBPP en conditions réelles Test sur NGC 6946 (galaxie du Feu d'artifice) : 109 brutes L, dont 54 traversées par des satellites. Avec l'option de masquage, aucune brute n'est jetée. Le script efface uniquement les pixels des traînées, et WBPP intègre les 109 brutes. Sur la capture : - à gauche, la carte de rejet basse : toutes les traînées masquées, écartées proprement ; - à droite, la carte de rejet haute : quasiment vide, aucun résidu de halo ; - au centre, le master : propre. On garde tout le signal, sans une seule traînée. c'est clair @nico1038 on va laisser les deux, ca mange pas de pain tu as vu le résultat sur ma Firework (faite durant la nuit de la premiere aurore boreale pour info (je dormais..........)) ca marche grave

parfait

hello, gros update en 1.3.0, intégration du moteur de mask pour WBPP. Tes brutes traversées par une traînée n'ont plus à partir à la poubelle. Avec WBPP, un nouveau script d'événement garde les brutes traversées par une traînée de satellite et masque seulement les pixels de la traînée, ailes comprises. Le reste de la brute entre toujours dans l'intégration, donc le rapport signal sur bruit du master est presque intact, alors que la quarantaine perd la brute en entier. C'est une grosse amélioration par rapport à la quarantaine, accessible pour l'instant uniquement via une intégration WBPP : voir Masquage dans WBPP. amusez vous bien

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

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 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)

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

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.

certes, bon je me permet de taper l'incruste pour partager mon avis en fait je pense qu'il faut vraiment s'attacher à éviter toute forme de redondance lors de la mise à dispo d'un nouveau logiciel/script. On est une petite communauté avec un set ultra large d'expert et utilisateur lambda. si on arrive a assurer ce cloisonnement, on sera sur un cercle vertueux. La dualité apporte un réel avantage mais de manière limité 😉

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é.

oui, visiblement je me suis fait avoir pas WBPP qui trust l'entete d'ASAIR un truc du genre, suis dessus note: je créé le thread dédié ClarkeMask

désolé, en fait je suis hors sujet ici, j'ai créé un nouveau script spécifique aux satellite Geostationaire ClarkeMask avec l'idée d'un mask par brute qui sort les pixel impactés lors de l'intégration. Je n'ai pas touché au script de ce post StarlinkSweeper. Je créé à présent un nouveau thread pour ClarkeMask Note: je(Claude) viens de découvrir comment faire du script .js en multithread sans passer par Python. je vais donc updater notre cher StarlinkSweeper de ce pas je vais voir avec ces nouvelles images pour check car très utile. l'astrométrie n'est normalement effectuées qu'une fois sur la première, elle permet de reperer les trail des Geo // ceinture de Clarke non pour l'instant je garde deux script distinct car c'est pas le même usage on est en phase de tuning, je veux bien connaitre les prob que tu rencontres, encore mieux comment les reproduire oui je suis d'accord, mais j'ai pas encore cette certitude. en tout cas on garde ca en tête pour la suite

version 0.2.0 en place: Multithread activé sans l'usage de python, vive la version 1.9.5 de pixinsight, cette 1.9.5 est décidément pleine d'optimisation (Starnet2 GPU support en linux par exemple)

+100

youhou 😀

yes, c'est ici https://github.com/jps-34/ClarkeMask Ca va encore bouger un peu mais ca tourne ! et j'attends tes retours

alors 0.1.0 validé, je la met sur le git Avec ClarkeMask sans Clarkmask

bon @nico1038 c'est hyper prometteur voici la full coverage des mask correspondant a toutes les brutes la c'est un exemple en sortie avec les trails a zero y a quelques raté, mais c'est du reglage je pense je te publies une version 0.1.0 pour jouer teaser 😀