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 😀

é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

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.

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

a oui encore mieux

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

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

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

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.

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

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

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.

Salut à tous, Après Badassium238, un deuxième petit script PixInsight, plus terre à terre mais que j'utilise maintenant à chaque cible, Le problème Vos masters intégrés en composition *full* (APP & co) ont tous une bordure où seule une partie des brutes a contribué : dithering, dérive de pointage d'une nuit à l'autre, une session avec la caméra tournée de 0,8°... Zoomez dans un coin d'un Ha multi-nuits, vous verrez l'escalier. Ces pixels sont plus bruités, et la bordure n'est pas la même d'un filtre à l'autre. Résultat : on recadre chaque master à la main, au pif, en espérant que les 7 canaux tombent pile ensemble. Et non, chercher les pixels à zéro ne suffit pas : ça vous donne l'union des brutes, pas leur intersection. Ce que fait CommonCrop - Pour chaque canal : la zone non nulle = union des brutes. Son excédent sur la taille d'une brute = l'étalement. On le retire de chaque côté → zone couverte par TOUTES les brutes. - Intersection sur L, R, G, B, SII, Ha, OIII (+ 2 slots AUX), plus une marge de sécurité réglable. - Contrôle de sortie chiffré : bruit au bord du crop vs bruit 300 px plus loin. ~1,00 = bord propre. - Contrôle visuel : un preview avec le cadre exact sur chaque master, vous zoomez dans les coins et vous jugez sur pièce avant de couper. - Bonus KPI : la perte de champ par filtre, classée du pire au meilleur. Sur mon Sorcier (13 nuits) : 0,7 % en RGB, ~3,1 % en SHO. Ça dit tout de suite quel filtre a souffert. - Sortie : L_crop, R_crop... tous à la même taille, STF auto. Les masters ne sont jamais modifiés. Tri automatique des masters par mot-clé FILTER, taille de brute lue dans l'en-tête (QHY600, ASI6200, ASI2600, QHY268), interface FR/EN. Une seconde de calcul sur 6 masters de 63 Mpx. Installation (PixInsight 1.9.4+) Resources > Updates > Manage Repositories, ajouter : https://jps-34.github.io/CommonCrop/ (cocher *Allow unsigned update repositories* le temps que le dépôt soit signé) Sources, doc, licence MIT : https://github.com/jps-34/CommonCrop Code écrit avec Claude (Anthropic), testé et validé sur mes données. Retours, bugs et cas tordus (autres caméras, autres logiciels d'empilement) bienvenus ici ou en issue GitHub. Bon ciel !

Merci Francis En fait pas vraiment pour HOO spécifiquement (ca serait facile à faire ceci dit), comme j'expliquais à Philippe B ce matin, le but initial du script est de séparer les raies en recouvrement (la il y avait vraiment un trou dans la raquette dans la palette d'outils de la communauté à mon sens), et Ha et OIII sont en général toujours bien séparés. Le script prend déjà toutes les combinaisons S/H/O. il y a une case pour lui dire ce que tu lui rentre justement L’image finale peut être montée comme tu veux à partir des trois raies (SHO, HSO, OHS…, PixelMath, Foraxx, NBColourMapper…). Le script mesure la couleur réelle de chaque raie dans ton image : peu importe comment tu l’as construite. Seule contrainte : c’est la dernière étape couleur, sur l’image sans étoiles déjà étirée et réglée. Et les préréglages permettent aussi de partir vers d’autres rendus (vraies couleurs, rouge/turquoise, minéral…). Le but en fait pour le dire différemment c'est de nous réconcilier avec le SHO sur les regions du ciel ou on n'arrive à faire que du HOO par facilité Tout ces retours que vous me faites c'est de l'or en barre, je vais donc me (enfin mon ami Claude surtout) pencher dessus avec plaisir PS: la palette de couleur que j'ai introduit en v1.1 c'est un gadget pour le profane que je suis en SHO, j'avoue que j'y ai vite pris gout; j'ai même pour le Fun rajouté un setting pour une palette "cuivre oxydé" haha. a quand la version "Rouille" que j'aime tant en HOO La version Cuivre https://app.astrobin.com/u/jpsc01?i=eb0nr1&r=J et oui j'ai un problème de "riche" dans le sens que j'ai posé plus de 70h et qu'il y a trop de signal, il faudrait que je réduise le stretch à priori sur ce champ pour que cela soit plus digeste

Badassium238 1.2 est sorti ! Le script PixInsight qui donne à chaque raie sa propre couleur en SHO (fini le bichrome orange et bleu) a été entièrement réécrit : Un seul moteur de couleur : par raie, juste Cible, Force, Tolérance et Saturation. Les palettes ne font que remplir les cibles. Nouveau réglage « Zones mixtes » : à 0, séparation subtile (seules les zones où le SII ou le Ha est plus fort que d’habitude bougent) ; à 1, toute la paire est recolorée comme une palette. La Proposition agit maintenant aussi sur les paires en partie séparées, pas seulement sur les paires confondues. Les cœurs blancs ou gris sont détectés : une raie sans couleur mesurable est signalée et laissée tranquille, au lieu de recevoir une cible absurde. Interface plus claire : résumé d’une ligne après l’analyse, vrai bouton Réinitialiser, et avertissement quand des réglages non standard de la session précédente sont restaurés. Toujours la teinte seule : luminance inchangée, aucun écrêtage, l’image d’origine jamais modifiée. PixInsight 1.9.4 et plus (moteur V8). La 1.1 reste disponible pour la 1.9.3 et antérieures. Dépôt de mises à jour : https://jps-34.github.io/Badassium238/ Code, doc et licence MIT : https://github.com/jps-34/Badassium238 Codé avec Claude (Anthropic), testé sur mes propres données. Vos retours sont les bienvenus ! AVANT: https://app.astrobin.com/?i=73vk2y&r=L APRES: https://app.astrobin.com/?i=73vk2y&r=M

Salut à tous, Vous connaissez le syndrome du SHO bichrome ? Le SII et le Ha finissent dans le même orange, l’OIII en bleu, et la troisième couleur part aux oubliettes. Ça m’agaçait tellement que j’ai fini par coder avec Claude un script PixInsight pour régler ça : Badassium238. Le principe : il retourne dans les masters linéaires pour savoir quelle raie domine où, puis il fait tourner uniquement la teinte de l’image finale étirée. Luminance intacte (écart mesuré : 0), aucun pixel écrêté, l’original n’est jamais touché. Sur mon champ, l’écart de teinte SII/Ha passe de 8° à 24°. Avant / après sur mon grand champ Cassiopée (Sorcier + Bulle, SQA55 + QHY600M) : Avant : https://app.astrobin.com/u/jpsc01?i=eb0nr1&r=C Après : https://app.astrobin.com/u/jpsc01?i=eb0nr1&r=G Nouveau en v1.1 : interface FR/EN, curseurs fins pour régler au degré près, et une passe 3 facultative avec des palettes (vraies couleurs des raies, rouge/turquoise, minéral…). c'est en mode exploration pour la passe 3 Passe 3 à utiliser en dernière étape couleur, sur l’image étirée sans étoiles. Installation : dans PixInsight, Resources > Updates > Manage Repositories, ajoutez https://jps-34.github.io/Badassium238/ (pour l’instant, il faut cocher l’option « Allow unsigned update repositories »). Code, doc et licence MIT : https://github.com/jps-34/Badassium238 PixInsight 1.9.4 et plus ; une version pour 1.8.9-3 à 1.9.3 existe, mais elle est moins éprouvée. Codé avec Claude (Anthropic), testé et validé sur mes données. Vos retours, vos bugs et vos images SHO sont les bienvenus !