StarlinkSweeper : script PixInsight qui trouve les brutes traversées par des satellites

[jpsc01]

à l’instant, Tromat a dit :

J'ai pas tout suivi, tu peux résumer ce que fait le script maintenant ?

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

il y a 2 minutes, nico1038 a dit :

J'arrive à reproduire tes excellents résultats avec les 28 images du jeu de tests mais je rencontre des problèmes lorsque j'essaie d'appliquer le script à un échantillon plus large de mes images, notamment avec une autre image de référence pour l'alignement.

 

Si je comprends bien son fonctionnement, le script s'appuie sur la solution astrométrique des images pour vérifier certains critères, notamment l'angle des traces. C'est bien ça ?

 

Si c'est bien le cas, je pense que c'est un problème car rien ne garantie à ce stade du prétraitement que les images ont bien une solution astrométrique. Dans les images que je t'ai fourni, elles ont bien une solution car l'Asiair que j'utilise enregistre normalement une solution WCS dans chaque image et Pix convertit cette solution dans son propre format lorsqu'il l'ouvre. Mais c'est plutôt l'exception, rare sont les logiciels d’acquisition qui font cela, ils se contentent en général d’enregistrer les coordonnées du centre de l'image et la focale de cette dernière.

 

Par ailleurs, la conversion de la solution WCS de l'ASair par Pixinsight est relativement aléatoire et il ne faut pas vraiment compter dessus selon moi pour toute analyse sérieuse de l'image. Seul une solution calculée par Pix avec ImageSolver est sufisament fiable. Je n'ai jamais bien compris l'origine exacte de ce problème de conversion  mais  il y a des soucis notament lorsqu'il y a un changement de meridien lors des acquisition et la solution astrometrique des images d'un coté du méridien est alors considéré comme "flipped"  par Pixinsight. C'est dans ces cas là, je crois,  que ton script ne détecte plus les traces (je pense car les critères sur l'angle ne sont alors pas respecté).

 

Voici un exemple de  5 images concernées:

https://kdrive.infomaniak.com/app/share/1883582/c7216846-0e4c-4fc4-b382-3c0629998772

 

Il me semble encore une fois que ton script serait à la fois plus utile et plus robuste sans les spécificités liés aux géostationnaires (et donc sans tenir compte du tout de la solution astrométrique des images). J'ai d'autres exemple d'images que je peux te fournir si tu veux?

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

 

il y a 5 minutes, nico1038 a dit :

Il me semble encore une fois que ton script serait à la fois plus utile et plus robuste sans les spécificités liés aux géostationnaires (et donc sans tenir compte du tout de la solution astrométrique des images). J'ai d'autres exemple d'images que je peux te fournir si tu veux?

oui je suis d'accord, mais j'ai pas encore cette certitude. en tout cas on garde ca en tête pour la suite

[nico1038]

il y a 6 minutes, jpsc01 a dit :

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

 

Je vois. Je ne sais pas si c'est facile (ou même possible) mais, si tu tiens à  continuer à utiliser l'astrométrie je pense qu'il faudrait alors lancer une résolution astrométrique de cette première image ce qui garantirait alors la présence et la fiabilité de la solution.

[jpsc01]

à l’instant, nico1038 a dit :

 

Je vois. Je ne sais pas si c'est facile (ou même possible) mais, si tu tiens à  continuer à utiliser l'astrométrie je pense qu'il faudrait alors lancer une résolution astrométrique de cette première image ce qui garantirait alors la présence et la fiabilité de la solution.

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

 

[jpsc01]

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

Modifié hier à 12:20 par jpsc01

[Tromat]

Il y a 1 heure, jpsc01 a dit :

Tes brutes traversées par une traînée n'ont plus à partir à la poubelle.

Ah cool  

J'ai fait une petite session cette nuit et j'ai des traversées qui ne partent pas au prétraitement, c'est l'occasion de vérifier tout ça. Je posterai les résultats ce soir je pense.

[jpsc01]

il y a 1 minute, Tromat a dit :

Ah cool  

J'ai fait une petite session cette nuit et j'ai des traversées qui ne partent pas au prétraitement, c'est l'occasion de vérifier tout ça. Je posterai les résultats ce soir je pense.

parfait

[nico1038]

Premier test sur un empilement de 10 images monochromes qui laisse apparaître des traces et le script fait le job.

 

Version starless du masterlight sans utilisation du script:

 

Même chose mais en utilisant le script directement dans WBPP:

 

 

Du coup maintenant je ne suis pas sûr de voir l'intérêt du script ClarkeMask car il me semble que celui ci ferait tout aussi bien le job sur les géostationnaires. Je n'ai pas testé cela dit.

 

Nico

[jpsc01]

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.

 

il y a 2 minutes, nico1038 a dit :

 

Du coup maintenant je ne suis pas sûr de voir l'intérêt du script ClarkeMask car il me semble que celui ci ferait tout aussi bien le job sur les géostationnaires. Je n'ai pas testé cela dit.

 

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

Modifié hier à 14:45 par jpsc01

[nico1038]

il y a 10 minutes, jpsc01 a dit :

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

 

Ça marche très bien c'est sûr mais je t'avoue être surpris que les algorithmes de réjection laissent des traces avec un empilement de 109 images!  Personnellement (à part le cas particulier des géostationnaires ) je n'arrive plus à distinguer la moindre traces à partir d'une vingtaine d'images en général.

Comme tes traces sont répartis de façon homogène dans tes images elle devraient être facilement rejetées?

Modifié hier à 14:54 par nico1038

[jpsc01]

il y a 1 minute, nico1038 a dit :

 

Ça marche très bien c'est sûr mais je t'avoue être surpris que les algorithmes de réjection laisse des traces avec un empilement de 109 images!  Personnellement (à part le cas particulier des géostationnaires ) je n'arrive plus à distinguer la moindre traces à partir d'une vingtaine d'images en général.

Comme tes traces sont répartis de façon homogène dans tes images elle devraient être facilement rejetées?

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

[nico1038]

il y a 9 minutes, jpsc01 a dit :

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

 

Quel algorithme de rejet utilises-tu ?

 

Je suis quand même surpris, car je ne constate rien de tel dans mes images. Il me semble que l’efficacité du rejet devrait être directement liée au nombre d’images empilées. Par exemple, dans mon image du Cocon ci-dessus, malgré la présence de satellites dans presque toutes les images, les traces disparaissent dès que j’empile 20 images

 

Et même si les bordures des traînées ne sont pas bien rejetées, il me semble que leur contribution à l’image finale devrait être suffisamment diluée par l'effet de moyenne lors de l’empilement pour qu’elles ne soient plus visibles.

Modifié hier à 15:07 par nico1038

[jpsc01]

il y a 2 minutes, nico1038 a dit :

 

Quel algorithme de rejet utilises-tu ?

 

Je suis quand même surpris, car je ne constate rien de tel dans mes images. Il me semble que l’efficacité du rejet devrait être directement liée au nombre d’images empilées. Par exemple, dans mon image du Cocon ci-dessus, malgré la présence de satellites dans toutes les images, les traces disparaissent dès que j’empile 20 images

 

Et même si les bordures des traînées ne sont pas bien rejetées, il me semble que leur contribution à l’image finale devrait être suffisamment diluée par l'effet de moyenne lors de l’empilement pour qu’elles ne soient plus visibles.

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

Modifié hier à 15:10 par jpsc01

[nico1038]

il y a 8 minutes, jpsc01 a dit :

avec APP
de mémoire j'avais fait pas mal de test ici

J'ai zero expérience avec WBPP. je commence à l'instant
 

 

Ça fait longtemps que je n’ai pas utilisé APP, donc je préfère éviter de te donner des conseils trop spécifiques. Cela dit, je trouve curieux que tu ais des traces sur une image comme celle du feu d’artifice.

Si tu peux faire le test en lançant WBPP (avec tous les paramètres par défaut) sur tes 109 images puis en comparant avec un passage avec le script pour voir les différences sur le résultat final on sera ainsi fixé.

 

Attention, tu as bien compris que je ne remet pas du tout en question l’intérêt de ton script car il y aura toujours des cas particuliers ou les mécanismes de réjection classique ne suffiront pas mais je ne pense pas qu'il soit utile dans tous les cas.

[jpsc01]

il y a 6 minutes, nico1038 a dit :

 

Ça fait longtemps que je n’ai pas utilisé APP, donc je préfère éviter de te donner des conseils trop spécifiques. Cela dit, je trouve curieux que tu ais des traces sur une image comme celle du feu d’artifice.

Si tu peux faire le test en lançant WBPP (avec tous les paramètres par défaut) sur tes 109 images puis en comparant avec un passage avec le script pour voir les différences sur le résultat final on sera ainsi fixé.

 

Attention, tu as bien compris que je ne remet pas du tout en question l’intérêt de ton script car il y aura toujours des cas particuliers ou les mécanismes de réjection classique ne suffiront pas mais je ne pense pas qu'il soit utile dans tous les cas.

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

Modifié hier à 15:30 par jpsc01

[Tromat]

Je viens de tester et ça marche nickel, un grand merci pour ce super script !

Le fait de pouvoir intégrer le script directement au sein de WBPP est un vrai plus, c'est totalement transparent pour l'utilisateur et très rapide avec l'utilisation de tous les cœurs. Le seul petit point frustrant c'est qu'il n'apparait pas dans le pipeline donc on se sait pas quand il se déclenche. Par contre ça va tellement vite que je n'ai même pas vu dans la console le moment où il tourne.

Le résultat est sans appel, sur cet exemple avec 24 poses en Ha. La grosse double trace de satellite disparait complètement sans affecter le reste de l'image. En dehors de la zone des traces les deux images sont strictement identiques. Ca permet aussi d'être plus cool avec la rejection, pas besoin de serrer fort et de réduire le rsb.

 

Sans :

Avec :

[jpsc01]

il y a 4 minutes, Tromat a dit :

Je viens de tester et ça marche nickel, un grand merci pour ce super script !

Le fait de pouvoir intégrer le script directement au sein de WBPP est un vrai plus, c'est totalement transparent pour l'utilisateur et très rapide avec l'utilisation de tous les cœurs. Le seul petit point frustrant c'est qu'il n'apparait pas dans le pipeline donc on se sait pas quand il se déclenche. Par contre ça va tellement vite que je n'ai même pas vu dans la console le moment où il tourne.

Le résultat est sans appel, sur cet exemple avec 24 poses en Ha. La grosse double trace de satellite disparait complètement sans affecter le reste de l'image. En dehors de la zone des traces les deux images sont strictement identiques. Ca permet aussi d'être plus cool avec la rejection, pas besoin de serrer fort et de réduire le rsb.

 

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 

[Tromat]

il y a 24 minutes, jpsc01 a dit :

et voila ! le gain effectivement est que tu as tout ca sans degrader ton SNR comme avant.

Le gain est énorme avec un caméra mono quand tu fais assez peu de RGB (parce que pas besoin). Ton script rentre direct dans mon process de prétraitement. Il faudrait en faire la promo sur Astrobin aussi, ça doit pouvoir intéresser beaucoup de monde.

Encore merci !