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

[jpsc01]

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

Le sigma-clipping vire le cœur d'une traînée de satellite, pas ses ailes : à quelques pixels du centre, elle n'est plus qu'à 1 ou 2 σ au-dessus du bruit, sous n'importe quel kappa raisonnable. Quand on n'a pas assez de brutes pour les noyer, il reste dans le master une bande rectiligne faible, invisible en linéaire, flagrante après un gros stretch. Et le score qualité du prétraitement ne voit rien : une traînée ne change ni le nombre d'étoiles, ni la FWHM, ni la rondeur.

StarlinkSweeper scanne un dossier de brutes (FITS / XISF, sous-dossiers compris, flats et darks ignorés d'après IMAGETYP), détecte les lignes droites par projection de Radon + test de continuité, et liste les brutes touchées avec un score en σ, indépendant du temps de pose, du gain et de la caméra. Un train Starlink ressort comme plusieurs lignes parallèles au même angle.

• Aperçu de chaque brute avec la traînée tracée en rouge, pour valider à l'œil.
• Quarantaine dans un dossier créé à côté de l'arborescence scannée : le logiciel d'empilement ne les revoit jamais. Effacement définitif sur confirmation. Export CSV.
• Deux moteurs : le script PixInsight seul (mono-cœur, aucune dépendance), ou en option la version Python livrée avec, qui scanne en parallèle sur tous les cœurs, curseur de workers borné par le CPU et la RAM de la machine.

Installation : Resources > Updates > Manage Repositories, ajouter https://jps-34.github.io/StarlinkSweeper/ (dépôt non signé pour l'instant : cocher « Allow unsigned update repositories »), puis Check for Updates.

Sources, README FR / EN et ligne de commande : github.com/jps-34/StarlinkSweeper. Licence MIT.

Code écrit avec Claude, sous ma direction, testé sur mes propres données. Retours bienvenus, en particulier sur des champs à filaments brillants et très rectilignes (Dentelles), le seul cas qui peut s'approcher du seuil.

[nico1038]

Hello et bravo pour ton script.

 

Je l'ai testé et il identifie plutôt bien les traînées dans mes images. Cependant, le problème que je rencontre avec les satellites n’est pas tant lié aux Starlink (car j’ai généralement suffisamment d’images pour les gérer), mais plutôt aux satellites géostationnaires, qui sont présents dans toutes mes images lorsque je vise une zone concernée.

 

Du coup, je ne sais pas à quel point c'est difficile mais je me demandais si une alternative à la mise en quarantaine des images ne serait pas de de remplacer la traînée par une bande complètement noir ($T=0) qui recouvrirait complètement cette dernière (avec sans doute une largeur proportionnelle à l'intensité de la traînée). Cela permettrait de conserver la contribution de l'essentiel des images à l'empilement et devrait régler les soucis d’apparitions des traînées dans le masterlight (si l'option clip low range d'ImageIntegration est bien activée).

 

Nico

Modifié 19 octobre par nico1038

[Tromat]

Il y a 3 heures, nico1038 a dit :

Du coup, je ne sais pas à quel point c'est difficile mais je me demandais si une alternative à la mise en quarantaine des images ne serait pas de de remplacer la traînée par une bande complètement noir ($T=0) qui recouvrirait complètement cette dernière (avec sans doute une largeur proportionnelle à l'intensité de la traînée).

Il y a un outil de Seti Astro qui fait ça mais à base d'IA si je ne m'abuse. J'avais testé et ça marche plutôt bien, l'outil en question remplace la trace par du noir mais ça se voit quand même. J'avais essayer de remplacer par la médiane de l'image et le résultat était parfait.

Un outil comme le tiens qui fait ça de façon algorithmique, donc logiquement plus rapidement, pourrait être très intéressant !

[Tromat]

J'ai mené un petit test sur un dossier contenant une cinquantaine d'images, ça semble très bien fonctionner ! Par contre j'ai un doute sur la lecture du résultat, dans le cas présent il y a avait 2 images (seulement !) avec des traces de satellites et sur l'une des deux je ne sais pas trop si la ligne quasi horizontale est bien compté. Si je me fie aux indication sous l'image j'ai 5 lignes en groupe de 3 et 2 quasiment à 90° d'écart, ce que l'image semble confirmer. Le problème ce sont les traits rouges en surimpression qui ne reprennent qu'une partie. Qu'est-ce qui est bon ?

Modifié 19 octobre par Tromat

[jpsc01]

Le 19/10/2026 à 20:15, Tromat a dit :

J'ai mené un petit test sur un dossier contenant une cinquantaine d'images, ça semble très bien fonctionner ! Par contre j'ai un doute sur la lecture du résultat, dans le cas présent il y a avait 2 images (seulement !) avec des traces de satellites et sur l'une des deux je ne sais pas trop si la ligne quasi horizontale est bien compté. Si je me fie aux indication sous l'image j'ai 5 lignes en groupe de 3 et 2 quasiment à 90° d'écart, ce que l'image semble confirmer. Le problème ce sont les traits rouges en surimpression qui ne reprennent qu'une partie. Qu'est-ce qui est bon ?

Salut Tromat,

 

Désolé pour ne revenir vers toi et nico que maintenant, j'avais oublié de mettre le post en suivi...

 

Pour commencer, un grand merci pour le retour et content que le script vous plaise
je n'ai que le mérite des instructions données à Claude  ce qui est dingue c'est que je lui fait adopter une approche Ingénieur et ca déboîte vraiment

Ce Claude est une révélation divine dans mon cas, ca faisait pas mal de temps que j'avais pas mal d'idées de projet mais j'étais incapable d'adresser avec mon faible niveau en coding pur

Alors, à propos de ton image, le mieux serait que tu me passes la brute en question pour que je le mette dans la moulinette. Il faut comprendre qu'avec le réglage du seuil le script ne te soumet que les cas les plus graves. Apres, tout n'est question que d'appréciation, ici par exemple le trait horizontal est clairement faible, il y a donc des chances qu'il disparaisse à la phase d'intégration même avec 25 brutes ? (à tester). mais ça n'est pas le cas de la trace verticale (angle 0.6°).

Donc on est bon à priori

Le 19/10/2026 à 16:23, nico1038 a dit :

Hello et bravo pour ton script.

 

Je l'ai testé et il identifie plutôt bien les traînées dans mes images. Cependant, le problème que je rencontre avec les satellites n’est pas tant lié aux Starlink (car j’ai généralement suffisamment d’images pour les gérer), mais plutôt aux satellites géostationnaires, qui sont présents dans toutes mes images lorsque je vise une zone concernée.

 

Du coup, je ne sais pas à quel point c'est difficile mais je me demandais si une alternative à la mise en quarantaine des images ne serait pas de de remplacer la traînée par une bande complètement noir ($T=0) qui recouvrirait complètement cette dernière (avec sans doute une largeur proportionnelle à l'intensité de la traînée). Cela permettrait de conserver la contribution de l'essentiel des images à l'empilement et devrait régler les soucis d’apparitions des traînées dans le masterlight (si l'option clip low range d'ImageIntegration est bien activée).

 

Nico

Salut Nico,

tout comme pour Tromat, désolé pour le miss, j'avais pas mis le post en suivi...
j'avoue ne pas avoir pensé aux cas des géo-stationnaires.
je pensais naïvement qu'ils disparaissaient à l'intégration

Tu aurais un set d'images brute (FITS 32 bit mini) 2 ou 3 successives pour que je me fasse une idée.
Si il n'existe pas de script actuel, je tenterai bien d'en faire un spécifique pour cet usage

Jacques

Modifié hier à 09:31 par jpsc01

[Tromat]

il y a 7 minutes, jpsc01 a dit :

Alors, à propos de ton image, le mieux serait que tu me passes la brute en question pour que je le mette dans la moulinette. Il faut comprendre qu'avec le réglage du seuil le script ne te soumet que les cas les plus graves. Apres, tout n'est question que d'appréciation, ici par exemple le trait horizontal est clairement faible, il y a donc des chances qu'il disparaisse à la phase d'intégration même avec 25 brutes ? (à tester). mais ça n'est pas le cas de la trace verticale (angle 0.6°).

Le lien est ici (dispo 3 jours) :https://www.swisstransfer.com/dl/01a17269-2449-710f-8a3c-6f536563a210

[jpsc01]

Le 19/10/2026 à 16:23, nico1038 a dit :

Hello et bravo pour ton script.

 

Je l'ai testé et il identifie plutôt bien les traînées dans mes images. Cependant, le problème que je rencontre avec les satellites n’est pas tant lié aux Starlink (car j’ai généralement suffisamment d’images pour les gérer), mais plutôt aux satellites géostationnaires, qui sont présents dans toutes mes images lorsque je vise une zone concernée.

 

Du coup, je ne sais pas à quel point c'est difficile mais je me demandais si une alternative à la mise en quarantaine des images ne serait pas de de remplacer la traînée par une bande complètement noir ($T=0) qui recouvrirait complètement cette dernière (avec sans doute une largeur proportionnelle à l'intensité de la traînée). Cela permettrait de conserver la contribution de l'essentiel des images à l'empilement et devrait régler les soucis d’apparitions des traînées dans le masterlight (si l'option clip low range d'ImageIntegration est bien activée).

 

Nico

 

Pour les géostationnaires, c’est un autre problème que celui que vise le script. Un satellite de la ceinture reste à déclinaison fixe : une fois les brutes alignées, toutes les traînées retombent sur la même bande de pixels, dithering ou pas. Si la majorité des brutes est touchée au même endroit, le rejet statistique ne peut plus rien, et écarter des brutes n’a plus de sens. StarlinkSweeper est un outil de tri (il repère la brute, on la sort), pas de réparation, et je préfère le garder simple et sûr.

Sur le fond, ta piste est la bonne, à condition de remplacer la traînée par « pas de donnée » plutôt que par une valeur :

• masquer la traînée à 0 dans chaque brute calibrée, idéalement après alignement, sinon l’interpolation bave sur les bords du masque ;
• empiler avec Clip low range activé dans ImageIntegration, pour que les zéros soient exclus et non moyennés.

C’est aussi le choix de SetiAstro : dans SetiAstro Suite Pro, la suppression des traînées du module d’empilement remplace désormais la traînée par des NaN, autrement dit par une absence de donnée (notes de version 1.21.6 : https://github.com/setiastro/setiastrosuitepro/releases).

Si le noir se voyait quand même chez toi, mon hypothèse : les zéros n’étaient pas exclus à l’empilement (un 0 moyenné laisse une bande sombre), ou le masque ne couvrait pas les ailes de la traînée.

Attention au remplacement par la médiane : sur le fond de ciel le résultat est parfait, puisque c’est la bonne valeur, mais sur une nébuleuse tu remplaces du signal par du fond. Le master s’assombrit à cet endroit, d’autant plus que beaucoup de brutes sont réparées au même pixel, ce qui est justement le cas des géostationnaires.

Je note l’idée d’un outil algorithmique de masquage, séparé de StarlinkSweeper, si d’autres en ont l’usage.

Réponse co-rédigée avec Claude, relue et vérifiée par moi.

PS: je reste dubitatif sur les résultats qui sont obtenus

Modifié hier à 10:07 par jpsc01

[jpsc01]

il y a 43 minutes, Tromat a dit :

Le lien est ici (dispo 3 jours) :https://www.swisstransfer.com/dl/01a17269-2449-710f-8a3c-6f536563a210

hello Tromat
Les 5 lignes sont une seule et même traînée : la verticale. Une traînée brillante laisse des « échos » dans la détection, c’est-à-dire des lignes secondaires à quelques degrés près. Les angles 179,35° et 179,45° ne sont pas à 90° des autres : une ligne n’a pas de sens de parcours, donc 179,4° équivaut à −0,6°, soit la même direction que 0,6°. Les 5 lignes sont donc toutes quasi verticales, collées les unes aux autres.

Les traits rouges partiels : chaque ligne n’est tracée que sur la portion où elle a été détectée (colonne Length : 100 %, 50 %, 25 %...). La ligne à 100 % est la bonne, les autres sont des morceaux de la même traînée.

La traînée horizontale faible n’apparaît pas pour deux raisons :

• le script affine un nombre limité de candidats par brute, et les échos de la verticale ont pris toutes les places ;
• même analysée à part, elle sort à environ 17, sous le niveau de liste fixe de 20. Elle traverse bien tout le champ, mais elle est faible.

Ce qui compte, c’est le score de la brute : 55, porté par la verticale. C’est le bon verdict, cette brute est à écarter, que la faible soit listée ou non. Le script juge une brute sur sa pire traînée, pas sur l’inventaire complet.

Le dédoublement en échos est cosmétique. Je le garde en tête pour une prochaine version : détection itérative, une ligne à la fois, ce qui éliminerait les doublons et laisserait la place aux traînées secondaires.

Réponse co-rédigée avec Claude, relue et vérifiée par moi.

[nico1038]

Il y a 11 heures, jpsc01 a dit :

Salut Nico,

tout comme pour Tromat, désolé pour le miss, j'avais pas mis le post en suivi...
j'avoue ne pas avoir pensé aux cas des géo-stationnaires.
je pensais naïvement qu'ils disparaissaient à l'intégration

Tu aurais un set d'images brute (FITS 32 bit mini) 2 ou 3 successives pour que je me fasse une idée.
Si il n'existe pas de script actuel, je tenterai bien d'en faire un spécifique pour cet usage

 

Oui: les  géostationnaires sont vraiment  qu'il y a de pire niveau réjection des satellites sur nos images. 

Voici un lien vers une série de 50 images brutes directement concernées par le problème (elles sont en 16 bits, je ne connais pas de caméras astro avec un adc en 32 bits!)

 

https://kdrive.infomaniak.com/app/share/1883582/8e879cc1-62e2-4dda-bf08-4fed8750ae44

 

Il y a 10 heures, jpsc01 a dit :

 

Pour les géostationnaires, c’est un autre problème que celui que vise le script. Un satellite de la ceinture reste à déclinaison fixe : une fois les brutes alignées, toutes les traînées retombent sur la même bande de pixels, dithering ou pas. Si la majorité des brutes est touchée au même endroit, le rejet statistique ne peut plus rien, et écarter des brutes n’a plus de sens. StarlinkSweeper est un outil de tri (il repère la brute, on la sort), pas de réparation, et je préfère le garder simple et sûr.

Sur le fond, ta piste est la bonne, à condition de remplacer la traînée par « pas de donnée » plutôt que par une valeur :

• masquer la traînée à 0 dans chaque brute calibrée, idéalement après alignement, sinon l’interpolation bave sur les bords du masque ;
• empiler avec Clip low range activé dans ImageIntegration, pour que les zéros soient exclus et non moyennés.

C’est aussi le choix de SetiAstro : dans SetiAstro Suite Pro, la suppression des traînées du module d’empilement remplace désormais la traînée par des NaN, autrement dit par une absence de donnée (notes de version 1.21.6 : https://github.com/setiastro/setiastrosuitepro/releases).

Si le noir se voyait quand même chez toi, mon hypothèse : les zéros n’étaient pas exclus à l’empilement (un 0 moyenné laisse une bande sombre), ou le masque ne couvrait pas les ailes de la traînée.

Attention au remplacement par la médiane : sur le fond de ciel le résultat est parfait, puisque c’est la bonne valeur, mais sur une nébuleuse tu remplaces du signal par du fond. Le master s’assombrit à cet endroit, d’autant plus que beaucoup de brutes sont réparées au même pixel, ce qui est justement le cas des géostationnaires.

Je note l’idée d’un outil algorithmique de masquage, séparé de StarlinkSweeper, si d’autres en ont l’usage.

Réponse co-rédigée avec Claude, relue et vérifiée par moi.

PS: je reste dubitatif sur les résultats qui sont obtenus

 Bon j'admire Claude pour sa capacité à créer des scripts mais pas pour cette réponse qui me semble à coté de la plaque...

[jpsc01]

Il y a 11 heures, nico1038 a dit :

 

Oui: les  géostationnaires sont vraiment  qu'il y a de pire niveau réjection des satellites sur nos images. 

Voici un lien vers une série de 50 images brutes directement concernées par le problème (elles sont en 16 bits, je ne connais pas de caméras astro avec un adc en 32 bits!)

 

https://kdrive.infomaniak.com/app/share/1883582/8e879cc1-62e2-4dda-bf08-4fed8750ae44

 

 Bon j'admire Claude pour sa capacité à créer des scripts mais pas pour cette réponse qui me semble à coté de la plaque...

Hello Nico

 

Très juste:

1) le coup de la 32bit c'est moi car ces derniers temps j'étais souvent avec des images intégrées: mauvais reflex

2) le dérapage de l'IA est un grand classique, 2 facteurs aggravant:
-Je suis resté dans le prompt du projet StarlingSweeper qui consiste à gérer des trail non deterministes. bref, il s'est vautré dans l’interprétation géométrique du "train" "fixe" des géostationnaires qui seraient a -6° du plan équatorial (probablement vrai) ?
-Quant à moi j'ai zéro expérience sur ce cas car jamais confronté. Hier soir, en m'endormant, j'ai essayé de visualiser la trace et j'ai vaguement imaginé une portion de parabole dessinée par un géo mais je bute rapidement et ça m'a endormis direct (très efficace) 

Dans le cas des Géostationnaire, l'approche est radicalement différente car on est sur un signal déterministe et il faut en profiter
A ce stade je vois 2 axes:
1) piloter Nina pour stopper l’acquisition lorsque le FOV de la camera passe sur les géostationnaires (position connue et déterministe): je ne sais pas si la version NINA actuelle le permet avec ses points d'entrée pour automation

2) pour chaque brute, faire un masque "englobant" sur la trace du Geo et "tagger" la chose pour que lors de l'intégration, cette partie des pixels ne soit pas prise en compte. Ca nécessite qu'APP ou le stacking de Pixinsight sache le gérer

je suis plutôt pour la 1) et quand a l'utilisation de l'IA en post-traitement, je pense que c'est inutile quand on peut s'en passer à l'aquisition

 

merci pour tes brutes, je vais regarder par curisité

 

Jacques

[jpsc01]

il y a 6 minutes, jpsc01 a dit :

1) piloter Nina pour stopper l’acquisition lorsque le FOV de la camera passe sur les géostationnaires (position connue et déterministe): je ne sais pas si la version NINA actuelle le permet avec ses points d'entrée pour automation

 

tu vas sûrement me dire que la 1) est hors sujet car justement toute tes brutes sont impactée. bref, je vais tes brutes pour comprendre et apprendre

[nico1038]

 

il y a 35 minutes, jpsc01 a dit :

tu vas sûrement me dire que la 1) est hors sujet car justement toute tes brutes sont impactée. bref, je vais tes brutes pour comprendre et apprendre

 

En effet, comme les  géostationnaires passent tous environ au même endroit sur le ciel il n'est pas vraiment possible de stopper l'acquisition car si l'on vise un objet dans la zone concernée (qui est effectivement autour de -7° en déclinaison pour la france métropolitaine du fait de la parallaxe) ils apparaîtront alors systématiquement. C'est le cas par exemple de la nébuleuse de la sorcière  (NGC1909) qui est l'objet visé dans mes images ci dessus.

 

D'une manière plus générale, je ne crois pas qu'il faille considérer la problématique des géostationnaires comme fondamentalement différents des autres satellites. Leur particularité exacerbe juste la difficulté à les rejeter avec les méthodes statistiques habituelles.

Ton approche initiale consistant à mettre les images en quarantaine est intéressante mais elle se heurte à un paradoxe: les traces de sattelites sont problématiques quand on a un faible nombre d'images à empiler (et donc que l'aspect statistique n'est pas efficace) mais c'est aussi dans cette situation que retirer des images de l'empilement est le plus critique. Si il existe une solution alternative consistant à conserver toutes les images tout en réglant ce problème de traces c'est sans doute la solution à privilégier dans la majorité des cas.

 

L’idée de remplacer les traînées par des valeurs nulles (et pas par Nan, je ne sais pas d'où sort cette idée ni comment elle pourrait fonctionner dans Pix?) et d'utiliser la fonctionnalité Clip Low Range de Pix n'est pas nouvelle. C'est quelque-chose qui est bien documenté et qui fonctionne très bien.
Il existe même un script développé par Hartmut Bornemann qui fait précisément cela mais de façon manuel (le script skill https://www.skypixels.at/pixinsight_scripts.html ). Utiliser les capacités de détection de ton script pour automatiser cette étape me semble donc être une piste intéressante pour les géostationnaires mais aussi pour les autres sattelites.

 

Nico

Modifié il y a 9 heures par nico1038

[jpsc01]

il y a 5 minutes, nico1038 a dit :

 

 

En effet, comme les  géostationnaires passent tous environ au même endroit sur le ciel il n'est pas vraiment possible de stopper l'acquisition car si l'on vise un objet dans la zone concernée (qui est effectivement autour de -7° en déclinaison pour la france métropolitaine du fait de la parallaxe) ils apparaîtront alors systématiquement. C'est le cas par exemple de la nébuleuse de la sorcière  (NGC1909) qui est l'objet visé dans mes images ci dessus.

 

D'une manière plus générale, je ne crois pas qu'il faille considérer la problématique des géostationnaires comme fondamentalement différents des autres satellites. Leur particularité exacerbe juste la difficulté à les rejeter avec les méthodes statistiques habituelles.

Ton approche initiale consistant à mettre les images en quarantaine est intéressante mais elle se heurte à un paradoxe: les traces de sattelites sont problématiques quand on a un faible nombre d'images à empiler (et donc que l'aspect statistique n'est pas efficace) mais c'est aussi dans cette situation que retirer des images de l'empilement est le plus critique. Si il existe une solution alternative consistant à conserver toutes les images tout en réglant ce problème de traces c'est sans doute la solution à privilégier dans la majorité des cas.

 

L’idée de remplacer les traînées par des valeurs nulles (et pas par Nan, je ne sais pas d'où sort cette idée ni comment elle pourrait fonctionner dans Pix?) et d'utiliser la fonctionnalité Clip Low Range de Pix n'est pas nouvelle. C'est quelque-chose qui est bien documenté et qui fonctionne très bien.
Il existe même un script développé par Hartmut Bornemann qui fait précisément cela mais de façon manuel (le script skill https://www.skypixels.at/pixinsight_scripts.html ). Utiliser les capacités de détection de ton script pour automatiser cette étape me semble donc être une piste intéressante pour les géostationnaires mais aussi pour les autres sattelites.

 

Nico

oui, l'option 1 n'est plus viable en l'état
concernant Starlinksweeper, son but n'est pas de virer "toutes" les images avec un starlink trail mais plus de pointer celle qui sont lacérée (cas les plus grave) et qui correspondent à un lancement récent sur la fusée N-1 du mégalo, dans l'exemple que je donne, l'image du Spaghetti était tellement "rayée" que même avec peut-être 200 prise j'avais encore des résidus. Bon il faudrait faire le test pour valider mon propos.

l'option 2) me tente, je verrais bien une passe de détection avec masque d'isolation puis stacking en prenant en compte les masques (le tout dans Pixinsight). Évidement en entrée on prend des images calibrée qui vont bien et on se concentre sur la suppression "propre" et optimale du trail Geo

c'est parti sur 2), ca va etre rigolot

voila à titre d'exemple la première passe sur tes brute @nico1038
file,flagged,score,coarse_peak,n_lines,width,height,"lines(score@angle/segments:x0,y0-x1,y1)",status
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-205329_0001.fit,0,0.0,10.8,0,6248,4176,,
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-205631_0002.fit,1,29.7,10.9,5,6248,4176,"29.7@53.00/7:1275,2269-60,3185 | 28.5@53.85/11:4347,45-2383,1480 | 25.3@52.40/7:1250,2279-57,3198 | 23.3@53.75/6:2247,1650-1153,2452 | 21.3@54.85/8:4192,171-2756,1183",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-205932_0003.fit,1,38.2,11.3,4,6248,4176,"38.2@53.90/12:3825,438-1674,2007 | 32.7@52.60/8:4306,46-2890,1129 | 22.3@53.10/7:1499,2207-240,3153 | 16.7@52.95/8:1586,1966-229,2991",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-210234_0004.fit,1,36.5,13.1,4,6248,4176,"36.5@52.50/11:3932,319-1996,1804 | 36.2@52.95/6:4170,45-3142,822 | 25.7@53.75/12:2929,1100-776,2679 | 10.8@51.90/6:1950,1799-919,2607",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-210536_0005.fit,1,41.9,10.2,5,6248,4176,"41.9@53.80/8:3687,427-2306,1438 | 38.9@52.40/10:3028,990-1281,2336 | 38.3@53.15/7:3063,974-1827,1901 | 32.8@52.85/6:3296,693-2274,1467 | 29.8@53.70/12:2220,1631-61,3216",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-210850_0006.fit,1,40.4,10.7,5,6248,4176,"40.4@53.90/8:3012,932-1622,1946 | 36.2@52.35/10:2141,1654-405,2994 | 32.5@53.10/6:2625,1202-1599,1973 | 28.0@53.95/7:1336,2301-60,3230 | 25.5@52.90/7:1648,2051-411,2986",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-211151_0007.fit,1,40.8,11.4,2,6248,4176,"40.8@53.65/9:2317,1450-754,2600 | 32.5@54.35/6:1831,1825-768,2586",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-211754_0009.fit,0,5.6,9.9,0,6248,4176,,
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-212732_0012.fit,1,26.9,10.5,3,6248,4176,"26.9@55.00/6:3854,424-2771,1183 | 26.6@49.00/6:3481,643-2454,1536 | 21.0@54.60/6:3373,831-2270,1616",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-213034_0013.fit,0,7.3,10.7,0,6248,4176,,
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-213336_0014.fit,1,30.8,14.4,4,6248,4176,"30.8@50.35/8:2236,1577-894,2689 | 27.8@54.45/6:1744,2052-622,2854 | 16.2@56.85/6:1271,2410-64,3198 | 12.6@56.30/10:2032,1884-62,3197",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-213637_0015.fit,1,30.4,11.9,1,6248,4176,"30.4@53.05/6:1467,2164-411,2958",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-214005_0016.fit,0,0.0,10.7,0,6248,4176,,
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-214608_0018.fit,1,21.7,11.0,4,6248,4176,"21.7@54.15/6:4291,178-3187,976 | 20.5@53.00/6:1701,2108-607,2933 | 17.5@51.10/6:4402,49-3316,925 | 15.9@53.85/6:4372,47-3294,834",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-214910_0019.fit,1,18.8,10.7,3,6248,4176,"18.8@53.60/8:3841,446-2401,1508 | 18.6@54.00/8:3384,851-1908,1924 | 15.2@53.40/7:3753,595-2461,1554",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-224751_0037.fit,1,24.9,9.9,2,6248,4176,"24.9@54.30/6:4513,183-3352,1018 | 12.9@53.25/6:3210,1015-2098,1846",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-225053_0038.fit,1,29.3,10.8,2,6248,4176,"29.3@52.95/13:3491,909-1014,2779 | 18.9@52.35/6:2318,1790-1188,2662",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-225656_0040.fit,1,38.7,13.6,3,6248,4176,"38.7@53.25/11:2179,1915-61,3497 | 16.3@52.10/6:4507,48-3395,914 | 11.8@52.30/9:3733,617-2079,1894",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-230039_0041.fit,1,43.3,12.4,5,6248,4176,"43.3@53.15/19:4343,184-806,2836 | 33.0@53.50/6:1225,2638-58,3501 | 29.7@50.45/12:1336,327-528,995 | 28.7@52.65/7:1571,2357-248,3367 | 28.3@54.00/6:1241,2625-59,3485",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-230341_0042.fit,1,37.2,13.4,1,6248,4176,"37.2@53.10/21:4151,326-245,3259",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-230642_0043.fit,0,5.1,12.6,0,6248,4176,,
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-230944_0044.fit,1,37.1,11.8,2,6248,4176,"37.1@53.15/7:4468,191-3126,1197 | 24.5@53.75/7:4292,329-2945,1316",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-231246_0045.fit,1,27.3,10.3,2,6248,4176,"27.3@53.75/6:3544,897-2382,1749 | 23.9@52.60/6:3479,920-2339,1792",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-231609_0046.fit,1,23.6,11.3,2,6248,4176,"23.6@52.50/6:2519,1645-1383,2516 | 20.1@53.00/7:2813,1291-1528,2259",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-232110_0047.fit,1,33.7,11.0,4,6248,4176,"33.7@53.60/8:1609,2330-61,3472 | 33.0@53.05/8:1583,2336-61,3481 | 27.7@52.45/6:1176,2627-58,3486 | 22.4@53.90/6:1372,2365-249,3185",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-232411_0048.fit,0,0.0,9.2,0,6248,4176,,
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-232713_0049.fit,1,40.2,14.3,4,6248,4176,"40.2@124.85/18:3523,3321-63,912 | 29.0@52.75/6:4106,326-3003,1165 | 18.2@125.50/8:1564,1978-61,905 | 13.4@53.20/10:4445,190-2538,1617",
./Light_NGC1909_180.0s_Bin1_2600MC_20221226-233015_0050.fit,1,25.7,9.3,4,6248,4176,"25.7@53.05/6:3676,762-2534,1621 | 23.3@53.90/6:3521,887-2367,1729 | 23.0@52.65/7:3720,607-2439,1585 | 22.9@52.60/6:1355,2454-243,3304",

 

[nico1038]

Si tu veux je peux te fournir les 50 images calibrées et alignées pour être dans une situation plus correcte pour tes tests?

[jpsc01]

a oui encore mieux 

 

[nico1038]

il y a 20 minutes, jpsc01 a dit :

a oui encore mieux 

 

 

Voilà: https://kdrive.infomaniak.com/app/share/1883582/082de137-fbdd-47a8-b73f-7559a2c05c76

 

Je viens de réaliser qu'il n'y a en fait que 28 images... Elles sont donc calibrées, dématriciées et alignées.

[jpsc01]

Il y a 4 heures, nico1038 a dit :

 

Voilà: https://kdrive.infomaniak.com/app/share/1883582/082de137-fbdd-47a8-b73f-7559a2c05c76

 

Je viens de réaliser qu'il n'y a en fait que 28 images... Elles sont donc calibrées, dématriciées et alignées.

C'est quand même vachement pollué cette zone de l'espace proche, celle en biais c'est probablement un étage en orbite elliptique proche de l'apogée... bon sinon ca avance...

Modifié il y a 4 heures par jpsc01

[jpsc01]

Je ne résiste pas à partager cet échange dantesque 😅

❯ mais attend, un sat qui dévit de 2,5° il est de-orbité en quelques jours n'est-ce pas ?

Non, c'est même l'inverse : ces satellites restent en orbite pendant des décennies. Les 2,5° ne mesurent pas une dérive hors de l'orbite, mais l'inclinaison de la traînée dans l'image par rapport à l'est-ouest.

D'où vient cet angle. Une orbite géosynchrone a la même période que la rotation de la Terre, mais elle peut être légèrement inclinée par rapport à l'équateur. Le satellite reste alors à la même longitude en moyenne, mais il oscille chaque jour au nord et au sud de l'équateur, avec une amplitude égale à son inclinaison. Vu du sol, il dessine un petit 8 allongé nord-sud.
- Quand il traverse l'équateur, sa vitesse en déclinaison est maximale : sa traînée penche d'un angle à peu près égal à l'inclinaison.
- Aux extrémités du 8, elle est parallèle à la ceinture.

Une traînée à 2,5° signifie donc une orbite inclinée d'au moins 2,5°. Ça n'a rien d'une orbite instable.

Pourquoi c'est courant.
- Un satellite géostationnaire actif est maintenu sous 0,1° d'inclinaison en brûlant du carburant. Sans ces corrections, l'attraction de la Lune et du Soleil fait croître l'inclinaison d'environ 0,8° par an, jusqu'à environ 15° en une vingtaine d'années, puis elle redescend : c'est un cycle d'environ 53 ans.
- Les satellites en fin de vie, ceux placés sur l'orbite cimetière (quelques centaines de km au-dessus de la ceinture) et les débris ont donc souvent des inclinaisons de quelques degrés à 15°.
- Certains satellites encore actifs sont volontairement laissés en « orbite inclinée » pour économiser leur carburant et prolonger leur vie.

Pourquoi ils ne retombent pas. À 36 000 km d'altitude, il n'y a pratiquement pas d'atmosphère, donc pas de freinage : ces orbites tiennent des millions d'années. Sortir un satellite de l'orbite géostationnaire pour le faire rentrer coûterait trop de carburant, c'est pour ça qu'on le pousse plutôt vers l'orbite cimetière.

C'est d'ailleurs ce qu'on voit sur tes brutes : l'objet faible à environ 3° revient de 0003 à 0009 avec un angle qui évolue lentement. C'est le comportement d'un géosynchrone incliné, pas d'un objet qui se désintègre. La relation « angle de la traînée ≈ inclinaison » est une approximation, mais elle suffit pour l'ordre de grandeur.

result: Une traînée inclinée de 2,5° vient d'une orbite géosynchrone inclinée d'au moins 2,5° (satellite en fin de vie, sur orbite cimetière, ou laissé volontairement incliné) ; ces orbites sont stables pendant des décennies et ne se désorbitent pas.

[nico1038]

il y a 24 minutes, jpsc01 a dit :

C'est quand même vachement pollué cette zone de l'espace proche, celle en biais c'est probablement un étage en orbite elliptique proche de l'apogée... bon sinon ca avance...

 

J'ai cru comprendre que les perturbations, notamment celles dues à la Lune et au Soleil, finissent par faire osciller les satellites géostationnaires, qui doivent alors corriger régulièrement leurs orbites.

 

Je pense que les trajectoires qui ne suivent pas strictement des parallèles de déclinaison correspondent à ces satellites qui ne devraient pas tarder à effectuer une correction orbitale.

 

A mon avis c'est plus probable qu'un objet avec un orbite très différent car par exemple dans ce cas là il semble aller à la même vitesse que les autres. 

 

EDIT: Ma réponse s'est croisé avec ton dernier post!

Modifié il y a 3 heures par nico1038

[jpsc01]

écoutes, j'en sais rien à vrai dire mais je trouve le sujet passionnant. le trait semble plus court en tout cas.
ce qui est certain, c'est que  le script va pas mal prendre de temps car je vais devoir mettre un range plus grand pour les angle de décalage (car il y a forcement de l'astrométrie car plus fiable), je le met a 2,5° et le user pourra l'agrandir
il a falloir également que je mette une option python pour passer en multithread car la c'est un seul Thread pour le script (4,2s sur ma bécane)

a suivre

 

Modifié il y a 3 heures par jpsc01

[nico1038]

il y a 40 minutes, jpsc01 a dit :

le trait semble plus court en tout cas.

 

Tu as raison: sur cette image je mesure les 4 traces parallèles avec un écart angulaire entre le début et la fin de la trace d'environ 45' . Comme les images font 180s, cela correspond exactement à 15° par heure (soit 360°/ jour) qui est la vitesse attendu pour des géostationnaires.

 

La trace en biais fait plutôt 32' d'écart angulaire et semble donc trop lente.

Modifié il y a 2 heures par nico1038

[jpsc01]

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 😀