Aller au contenu

Cissou8

Membre
  • Compteur de contenus

    326
  • Inscription

  • Dernière visite

  • Jours gagnés

    1

Tout ce qui a été posté par Cissou8

  1. Le resultat doit etre effectivement ok si tu as traite tes flats avec des bias qui ont le meme "defaut"/"reglage" (selon qu'on voit le verre a moitie vide ou a moitie plein ) Il est pas bon si tu as applique un offset synthetique. Maintenant, l'ampleur du "pas bon" depend de pleins de facteurs (intensite de tes flats, valeur d'offset synthetique que tu as passe etc etc) Attention toutefois, avec ce "defaut"/"reglage", on a vite fait de saturer les pixels bleus. Donc il faut que tu sois attentif sur cette couche la en particulier pour voir si ca a fait du degat ou pas
  2. Apparemment, y a deja moyen de le controler: https://www.indilib.org/individuals/devices/cameras/zwo-optics-asi-cameras.html Regarde la derniere image sur la tab Controls. Y a les champs WB_R et WB_B. Il faut les mettre toutes les 2 a 50.
  3. J'ai charge tes images et j'ai regarde leurs tetes. Dans EKOS, tu as un problème de balance des blancs (la boutade que faisait @lock042 plus haut et de la mienne sur les resultats inattendus...), cela n'est pas visible dans tes images NINA. En gros, c'est le driver ZWO qui, sur certaines de ses cameras couleurs, décide que ça serait une bonne idée de multiplier le rouge et le bleu par des facteurs multiplicateurs. Je crois que ce réglage caché suffit a expliquer tes statistiques peu banales avec ekos. Ça arrive tellement souvent que c'est le premier point de notre section de résolution de problème de calibration... https://siril.readthedocs.io/fr/stable/preprocessing/calibration.html#troubleshooting-calibration
  4. Oui, les valeurs générées par NINA sont bien plus cohérentes avec ce qu'on s'attend a trouver (noise qui reste identique quand on change l'offset, valeurs de min et max multiples de 16 etc...). Tu peux changer l'offset dans le sequenceur de NINA sans avoir a connecter/deconnecter mais c'est un detail. Je ne connais pas EKOS donc je ne peux pas te dire ce qui ne va pas.
  5. Sans être con, y a des fois des réglages automatiques un peu cachés dans certains softs qui peuvent produire des résultats inattendus
  6. Salut, Alors en tracant tes donnees, j'obtiens ca: Ce que tu vois sur le min, c'est que le réglage d'offset est tellement bas, que certaines valeurs sont clippées au noir. Donc, si tu cherches a trouver le facteur multiplicateur, il faut pas se servir des valeurs a 5 et 10, leurs statistiques sont faussées. Si SharpCap te donne un reglage a 13, j'imagine que c'est le reglage mini de mini pour pas que ca clippe. Je te dirai quand meme de le monter un peu... Y a quand meme un truc tres etrange, et meme 2: - le premier, c'est le fait que l'ecart (max-median) est bien plus grand que (median-min) et il monte avec le reglage d'offset. Alors, je suis d'accord que le max c'est pas très robuste comme estimateur. Mais j'ai regarde aussi le noise et le sigma, c'est pareil, ils augmentent. Normalement, si tu montes juste l'offset, ca change pas l'histo, ca le decale a droite (ca ajoute un offset en bon francais ). - le deuxieme, c'est que si je regarde tes valeurs de max, c'est pas des multiples de 16 (sur le min, c'est bien ca). Pour une camera en 12b, c'est qd meme bizarre. Une camera en 12b, quand elle ecrit ses 12b d'info dans un container 16b et qu'elle les colle a gauche (elle remplit a droite avec 4 zeros donc), c'est normal que tu te retrouves avec des tableaux remplis de multiple de 16 (2^4). Donc voila, je sais pas te dire ce qui va pas avec tes prises de vue, mais y a des trucs qui me chiffonent avec tes stats d'images. C'etait bien a gain constant? Pour me convaincre de ce que je te raconte, j'ai sorti ma 120MM (non refroidie, ADC12b) et j'ai fait 21 bias a 0.001s au gain 29 qui est l'unitaire sur ce modele. Les min et les max sont bien des multiples de 16 deja. Et si je regarde les courbes, min, median, max, j'ai ca: A part pour les valeurs trop basses d'offset (de 0 a 5) qui font clipper, on voit que la mediane est centree entre le min et le max et que l'ecart reste constant, peu importe le reglage. Bien, maintenant, reprenons ta courbe de mediane en enlevant tes points a 0 et 5. Si je fais passer une droite en forcant l'ordonee a l'origine a 0, j'obtiens effectivement un multiplicateur autour de 67-68. Et oui, c'est un peu suspect. Parce que normalement, une image de capteur 12b, ca n'a que des valeurs multiples de 16 (c'est ca que dit le tuto). Et si c'est un bias, ca a en plus un histo tres ressere. A part qqs pixels qui vont pas bien, la plupart des pixels doivent tomber sur une valeur multiple de 16... Si je trace tes data, j'ai ca: Si je trace pour la 120MM, j'ai ca: Et je suis bien d'accord que meme en 68, c'est pas un multiple de 16, et c'est bizarre. Le 256 que j'obtiens pour la 120, oui par contre. Et porbablement que 64*offset, c'est plus proche de la verite, mais il faudrait refaire des mesures qui n'ont pas les defauts que je t'ai liste au-dessus pour en avoir le coeur net. Le tuto ne stipule, il dit que c'est qd meme a priori, ce qu'on s'attend a trouver pour les raisons que je t'ai donnees au dessus. Je comprends pas pourquoi tu utilises 120 comme master offset... Et oui, 832, ca sera plus coherant avec les mesures que tu as faites. Si tu lis le reste du tuto, l'annexe sur comment les flats corrigent les lights, tu verras que ca pourrait ne pas corriger complétement. Vu que tu utilises une valeur a priori trop petite, tu te rapproches du cas L-D/F. Maintenant, c'est pas le cas le pire, et aussi, l'ampleur du "manque de correction" depend de bcp de facteurs (les gains, l'intensite de tes flats etc etc...). Mais voila, c'et eventuellement ca que tu pourrais observer. Donc pour resumer, y a qqchose qui va pas dans tes bias de test, il faut chercher par la. Cecile
  7. allez, je pinaille, mais comme ca, tu auras toutes les subtilites... Avec l'option -noout, on fait l'alignement en prenant l'image de reference comme reference : - Si tu as en definie une (comme avec un setref) alors c'est celle-ci. - Dans le cas general, quand aucune n'est pas definie, on prend la premiere...
  8. Alors, si je regarde ton premier script: tu lui demandes une registration en 2passes (qui ne produit pas d'image). Tu ne devrais pas avoir de fit supplementaire en sortie, par la je veux dire pas de r_Green_pp_light.fits. Est-ce bien le cas? Si je regarde le deuxieme La, tu lui demandes une registration "normale". Il ne produira pas les fichiers starlist (les .lst, c'est propre a la registration en 2 passes), c'est ce qu'il te dit. Par contre, tu dois bien avoir un nouveau fichier r_bkg_CFA_0.fits produit. J'imagine que c'est bien le cas, sinon la commande stack qui vient a la fin de passerait pas.
  9. Salut, la commande register change toujours la référence: Quand on ne précise pas -2pass, c'est basé sur la meilleure FWHM, Quand on précise -2pass, le calcul est un peu plus détaillé (il se base a la fois sur le nombre d’étoiles et la FWHM https://siril.readthedocs.io/fr/stable/preprocessing/registration.html#pass-registration) Alors pourquoi changer la ref apres une registration... Si on exporte les images, ca a un intérêt "limité". On essaie juste de faire en sorte que si des filtres sont appliques ensuite, l'image de ref ne saute pas de la sélection (a priori, peu de chances avec l'image de meilleure FWHM). En lucky par contre, étant donne que généralement, on exporte pas la séquence et que les shifts sont appliques au moment de stacker, on préfère aligner sur la meilleure image (on ne la debayerise meme pas si la reso est suffisante et qu'un shift pixel wise suffit, c'est un compromis a trouver en fonction de la place de stockage/le temps de traitement et la finesse de l'image finale). Maintenant, sur ton script, il faut effectivement la définir au moins une fois si tu veux garder le même cadrage... avant la registration. Tu pourrais forcer un autre setref après la registration mais vu que ta séquence est déjà exportée, la ref ne sert plus qu'a déterminer l'image qui sert a la normalisation Juste un truc en passant vu que j'ai ton script sous les yeux, -noout et -interp=la dans la commande register avec -2pass ne servent pas. -noout parce que par définition, 2pass ne produit pas d'images. -interp= parce que justement, comme ça ne produit pas d'images, peu importe la méthode d'interpolation. Bon ciel, Cécile
  10. 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
  11. 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
  12. 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
  13. 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...
  14. 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
  15. 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.
  16. 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
  17. 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
  18. Salut, c'est quoi qui te semble bizarre? parce que j'en ai ouvert 2, et ils ressemblent bien a des darks... Cecile
  19. 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
  20. 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.
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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).
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.