jpsc01

alors ma reco serait, installes Kubuntu et tailles un swap entre 32GB et 64GB (ca va dépendre de la taille et le nombre de tes images dans WBPP pour la phase d'integration. $ swapon --show NAME TYPE SIZE USED PRIO /dev/nvme0n1p3 partition 9,8G 0B -1 /home/swapfile file 64G 0B -1 les 9,8G c'est parceque je n'ai pas pensé à optimiser au départ le linux pour Pixinsight ne pas confondre avec les dossiers de swap de PixInsight (Edit > Global Preferences > Directories and Network > Swap storage directories), qui sont ses fichiers temporaires sur disque, à mettre sur un SSD rapide. Les deux comptent. $ free -h total utilisé libre partagé tamp/cache disponible Mem: 62Gi 5,3Gi 44Gi 119Mi 12Gi 57Gi Échange: 73Gi 0B 73Gi apres pour le disque, je suis en train de tester un truc pas mal qui consiste de mettre un disque SSD veloce en USB3 (attention cable USB-C <=> USC-C uniquement pour la stabilité) pour les sortie et le travail de WBPP) résultat obtenu avec un SDD veloce sur l'USB-C arrière (10 Gbps) : 853 Mo/s en écriture et 980 Mo/s en lecture ;

Bon encore un truc à explorer dans ce cas 😉 de mémoire avec WBPP en AUTO j’avais des artefacts de pixel déviant? Je ne sais pas comment les nommer d’ailleurs en tout cas c’est noté merci

hello @nico1038 oui je pense qu'on parle de la même chose, concernant le cosmetic correction je fait un process icon cosmetic correction pour chaque Masterdark que je vais devoir utiliser et je met les high a 3 de mémoire et ensuite je les cales dans WBPP, ca marche nickel et sinon oui, je suis surpris de la conso du disque avec WBPP, l'avantage c'est qu'on peu rejouer mais bon entre 10G et 1TB je découvre toujours WBPP comme tu peu le constater.

Bonjour à tous, Petit retour d'expérience qui m'a surpris, je le partage au cas où ça serve. Le contexte. NGC 7635 (la Bulle) en SHO + RGB, QHY600M (9576 × 6388), 1296 lights de 300 s ou 60 s, 625 flats, 13 sessions. J'avais déjà traité ces données avec APP sans jamais me soucier du disque. Je les repasse dans WBPP 3.2.0 (PixInsight 1.9.6), et au lancement le diagnostic m'annonce : - flats calibrés : 137 Go - master flats : 20,5 Go - lights calibrées : 296 Go - lights après cosmétique : 296 Go - lights alignées : 296 Go - master lights : 5,5 Go - total : ~1051 Go Mes brutes d'origine (16 bits) ne font « que » 148 Go pour les lights et 71 Go pour les flats. Pourquoi un tel écart : 1. WBPP écrit chaque étape (calibration, cosmétique, alignement) comme une copie complète de toutes les brutes, et il les garde toutes jusqu'à la fin du run. Elles servent à son cache et à l'inspection. 2. Ces copies sont en float 32 bits non compressé, c'est imposé dans le script WBPP. Chaque brute passe donc de 122 Mo (16 bits) à ~234 Mo. Sur 1296 lights, ça fait ~296 Go par étape. 3. APP, lui, n'enregistre pas les brutes intermédiaires par défaut. Elles ne sont écrites que si on coche Save Registered ou Save Normalized. Avec les réglages par défaut, il ne reste sur le disque que les masters et les intégrations. J'estime ça à environ 8 Go pour ce jeu, au lieu de ~1 To. Les leviers côté PixInsight (je n'ai pas trouvé d'option pour compresser ou effacer les intermédiaires au fil du run) : - Ne pas faire de cosmétique : une étape de moins, environ −300 Go. perso je ne peux pas m'en passer - FastIntegration : les brutes alignées ne sont pas écrites, environ −300 Go. Mais pas de LN, un alignement simplifié et un rejet par lots. Attention, WBPP active FastIntegration automatiquement sur les groupes de 200 brutes ou plus (Automatic integration mode, coché par défaut). Pareil je ne veux pas utiliser le fastIntegration pour plusieurs raison dont le debrayage du pipeline starlinkweeper (mais pas que...) - Un run par filtre, en effaçant les intermédiaires entre deux runs : la pointe tombe à environ 330 Go ici, sans perte de qualité. Il faut imposer la même image de référence dans chaque run, puis recadrer les masters ensemble à la fin. Reloud Pour ma part, j'ai mis la sortie de WBPP sur un SSD externe de 2 To. Si quelqu'un connaît une option qui m'aurait échappé pour limiter ça dans WBPP, je suis preneur. Jacques

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