Cissou8

Bonjour, pour etre lu, il me semble que le catalogue doit porter le nom user-DSO-catalogue.txt (siril n'ajoute pas tous les txt qu'il trouve dans le dossier) Cecile

Bonsoir, merci pour le rapport. Je vois que le temps d'execution est vertigineux aussi J'ai ouvert un ticket: https://gitlab.com/free-astro/siril/-/issues/1199 Bonne soiree, Cecile

Salut, la derniere version (1.2.0) arrive a résoudre ton image en sélectionnant le recadrage auto (pour grand champ) et en lui donnant les coordonnees trouvees par astrometry.net (23h59 +66°44'). Apres, avec autant de champ (quasi 80degres), il y a pas mal de distorsion. On voit que quand on resout bien au centre, les annotations sur les bords d'image ne tombent pas bien en face de la ou elles doivent. On a des pistes pour ameliorer ca, mais il faudra attendre la 1.4 Cecile

Apres conversion, tu peux pas avoir de graphique... donc je comprends pas trop comment tu t'y prends (je vois pas ce que tu appelles outil de photometrie non plus...), ni de quels 2 criteres tu parles ensuite Bref, ecoute, lis ce que je t'ai envoye si tu as le temps et suis les etapes que je t'ai donnees. Je suis sure que ca marche, c'est exactement pour faire ce que tu decris qu'on a ajoute ca...

Salut, tu peux faire un alignement en 2 passes. La premiere passe va mesurer les étoiles et te rendre des graphes sur lesquels tu pourras faire du tri. Quand tu as choisi celles que tu veux garder, tu appliques l'alignement en utilisant "Apply Existing Registration" et voila... tu auras une sequence alignee avec uniquement les images qui ont passe tes criteres. Note que tu peux aussi appliquer des filtres (plutot que de trier avec les graphes) a l'etape "Apply Existing Registration". Les sections de la doc utiles: https://siril.readthedocs.io/fr/stable/preprocessing/registration.html#pass-registration https://siril.readthedocs.io/fr/stable/preprocessing/registration.html#apply-existing-registration Cecile

Je parlais des logs bien plus detailles que nous sort la version de debug... si tu préfères, tu peux me faire passer l'image en MP.

Salut, Comme je viens te dire sur le forum anglophone, je vais avoir besoin de l'image il faut qu'on puisse regarder un log un peu plus détaillé de l'erreur Merci Cecile

Alors, c'est normal que Siril te dise que c'est N&B, vu que c'est ce qu'il y a dans ton fichier. La, FITSViewer le debayerise a la volee pour l'affichage, ok, mais invente une balance de couleurs, parce que si je regarde les stats de ton fichier, elles sont bien egales sur le R, G et B (et conformes en moyenne/mediane a ce que te racontait NINA). Conclusion, tout va bien

Salut, c'est quoi qui te semble bizarre? parce que j'en ai ouvert 2, et ils ressemblent bien a des darks... Cecile

Salut, je crois que tu devrais poser la question dans la section Logiciels du Forum, parce que c'est pas propre a Siril. Siril ne fait qu'appeler la ligne de commande de starnet. Tu aurais plus de visibilité. Pour la question initiale, il y a un bout de reponse sur le site de starnet: https://www.starnetastro.com/resources/ J'ai pas essaye n'ayant pas le matos adapte Cecile

Ah oui ok, je connaissais pas cette limitation (il commence a y avoir des tas de commandes et des tas de menus et des tas de formats et donc beaucoup de combinaisons....). Mais effectivement, meme si c'est pas bloque par la commande, la limitation est la meme. Le code pour produire les 4 sequences en ser ou fitseq n'existe pas, ca a ete bloque en dans l'UI, pas dans la commande, mais cela reste vrai.

Ah oui effectivement, le seqsplit_cfa sort forcement en fits lui. Je vais ouvrir un ticket pour le garder en tete, mais je sais pas si on l'ajoutera a la 1.2 qu'on essaie de finaliser voila: https://gitlab.com/free-astro/siril/-/issues/1128

Salut, Effectivement, le choix n'est pas dispo. Par contre, je comprends pas pourquoi tu dis que le format est forcé à fits. Normalement, le format de sortie est forcé au format d'entrée. Si tu es en fitseq ou ser, tu dois avoir la même chose en sortie. C'est pas le cas, tu as un exemple à partager? Cecile

Salut, tes lights ont ete dematrices quand tu as fait la conversion, ils ont maintenant 3 canaux et ne sont, de fait, n'est pas de meme dimensions que les masters dark et flat créés par le script. Il faut que tu mettes des lights non-dematrices dans le repertoire light. Laisse tes images raw dans les repertoires, Siril se debrouillera avec ca. Pour les tutos, tu peux regarder sur le site de Siril, on a celui avec script (https://siril.org/fr/tutorials/first-steps/) et celui en manuel (https://siril.org/fr/tutorials/tuto-manual/) Cecile

Salut, la MAD ( dont on donne une description dans la doc https://siril.readthedocs.io/fr/latest/Statistics.html#mad) est une mesure de la dynamique de ton image. Quand on normalise les images avant de les stacker, on egalise leur dynamique. La, dans ton cas, il y en a tellement peu qu'on ne peut pas s'en servir. Tu peux quand meme empiler en desactivant la normalisation. Mais effectivement, monter les ISO, c'est probablement une bonne idee (monter le temps de pose aussi ) Cecile

Alors si tu dis de prendre la FWHM a 90%, ca va effectivement calculer le 90eme percentile de la FWHM independamment sur le vert et sur le rouge. Et si tu filtres les images en enlevant les images au dessus de ce seuil, tu auras a la fin 90% de tes images sur chacune des sequences, par definition du percentile. Donc si tu as shoote le meme nombre d'images rouge et verte, tu auras le meme temps d'integration sur ces 2 couches. Par contre, elles pourront avoir des FWHM tres differentes. Je suis desolee, j'ai pas compris ton exemple... tu vas au final avoir des temps d'integration differents sur tes couches. L'ordre des filtres n'a pas d'importance. On calcule chaque seuil independemment des autres filtres. On regarde le 90% percentile de la FWHM et le 90% de la rondeur sur l'echantillon total. Et ensuite on rejete les images qui ne remplissent pas tous les criteres a la fois. Donc ca va dependre de comment sont correlees FWHM et rondeur. C'est pour ca que je disais que c'etait pas simple des qu'on etait en multicritere. Quant a garder les X premieres, c'est un peu dommage... rien ne te dit que tu gardes les meilleures (au sens des criteres de qualite).

Bonsoir, j'avais du mal a reproduire parce qu'en fait il a deja ete corrige . La correction sera dans la prochaine version. merci du retour! Cecile

Bonsoir, il existe un fichier txt qui est cree au moment de la conversion (tu dois le voir dans ton repertoire, il finit par _conversion.txt). et qui te donne les correspondances entre images d'entree et images de la sequence. Mais on ne garde pas ensuite la correspondance avec les images de depart quand on fait la calibration, l'alignement etc... parce que comme on peut choisir les prefixes au fur et a mesure des etapes, ca deviendrait vite complique a gerer. Cecile

Bonsoir, alors ca me parait complique en pratique... on prend les N premieres? On prend les N meilleures selon quel indicateur? Si tu connais la taille de chaque sequence, tu peux lui passer le percentile d'images que tu veux garder sur chacun des criteres de qualite. Mais je vois pas comment on gere les combinaisons de filtre multicriteres en donnant un nombre d'images... Cecile

Bonsoir, c'est possible de le scripter, mais pas avec la fonction load. Au lieu de: load myimage Tu peux faire: calibrate_single myimage -debayer load pp_myimage Ca debayerise l'image que tu peux ensuite charger Cecile

Bonsoir, effectivement, il manque une protection a l'execution de certaines fonctions graphiques quand on est en cli, on va corriger ca, merci du retour! Cecile

Ah super! Non le log pas besoin, a priori, si ca marche, ca marche Je veux bien oui, que tu testes pour des non-regressions surtout.... Merci!

@shibon, j'ai commence a regarder. Si tu veux bien tester le paquet ici: https://gitlab.com/free-astro/siril/-/jobs/4082114542/artifacts/download J'ai essaye sur ton image plus haut, ca marche (ca en trouve plus en tout cas). Faut que je regarde de pas avoir introduit d'autres effets de bord

Ah ben on a parlé de ça le 11 Mars et la bêta est sorti le 12.... non c'est pas dedans J'ai pas le droit de péter la détection d'etoiles la veille d'une release. J'ai pas encore regarde d'ailleurs

Alors, je suis pas bien d'accord avec ca . Je vais faire un raisonnement un peu idéalisé, y a des subtilités a toutes les étapes mais je vais pas les faire, sinon ca alourdit le propos. Le fond de l'affaire c'est: Les photons ne se repartissent pas. En considerant que le flux est constant sur tout le spectre, disons que ta source de lumiere pour un flat est vraiment blanche, le même nombre de photons par seconde arrive sur chaque "site" optiquement parlant. Première étape: ton filtre rejette hors des bandes, il ne reste plus que des photons dans la bande Ha et la bande OIII, a peu pres le meme flux, vu que la largeur des bandes du filtre est a peu pres similaire. Deuxieme etape: Sur un site qui a en plus un filtre rouge de la matrice de Bayer, les pixels de la bande OIII n'arrivent plus. Le nombre de photons effectivement transformes en electrons depend de la transmission du filtre rouge et de la sensibilite d'un site dans le rouge (a quel taux les photons de telle longueur d'onde se convertissent en electrons). Sur un site qui a un filtre Vert ou Bleu, c'est l'inverse, il ne recoit que les photons de la bande OIII, et combien sont convertis la fin depend de la transmittance des filtres vert et bleu et du taux de conversion de l'electronique derriere a la longueur d'onde du OIII. A la fin, c'est ce taux de conversion global (transmission du filtre + sensibilte de la cam) qui va faire la valeur que tu lis sur un pixel dans une image (y a en plus le gain mais la tu es a 1 environ, la bitdepth de l'ADC et la tension d'offset mais on s'eloigne du sujet). Generalement, le taux de conversion global est meilleur dans le vert (c'est pour ca que les images sans filtre sortent avec cette teinte verte). Mais bon, chaque pixel vit sa vie sans "savoir" ce qui se passe chez son voisin. Un site du capteur ne sait pas qu'il y a un filtre rouge ou vert ou bleu qui va lui enlever des photons. Un capteur couleur, c'est juste un capteur mono qui a une matrice de Bayer au dessus de la tete. Donc ajouter les valeurs des 2 pixels verts et du bleu pour comparer a la valeur du rouge dans le meme bloc de 4, je pense pas que le raisonnement soit bon. La en regardant tes valeurs, je dirais que ta source de lumiere est pas du tout blanche, voire qu'elle tire meme franchement sur le rouge. Mais si y avait que ca, ca serait pas un probleme, Siril peut recaler les valeurs pour que tout le monde ait la meme moyenne. La ce que je trouve bizarre, c'est que la pattern en bretzel soit identique sur toutes les couches.... Alors, c'est peut-etre la limite de mon raisonnement idealise. C'est pas si binaire... Y a des photons Ha qui peuvent fuiter sur le vert/bleu et vice et versa (parce que les filtres sont pas exactement a zero de transmittance)... Mais y a clairement qqchose a faire sur tes flats. Peut-etre tenter des skyflats?