Cissou8

Salut, alors en theorie, pourquoi pas, c'est probablement l'ideal. En pratique, a moins que la premiere image soit completement ratee, du genre le tube qui avait pas fini de pointer ou les nuages pas encore partis, ca ne joue pas grand chose. La detection d'etoiles marche meme sur les images ou la FWHM est moins bonne. Et les centres des etoiles sont au meme endroit. Avec peut-etre un peu plus d'incertitudes mais leurs nombres fait que les erreurs doivent etre a moyenne nulle. Si besoin, tu peux faire une "bonne image" en debut de soiree, en verifiant qu'il y a pas de file etc, la solver et t'en servir de master distorsion pour la soiree (le fichier de distorsion n'est pas forcement un fichier de la sequence). Et si l'optique n'est pas demontee, ca peut rester le master distorsion jusqu'au prochain demontage de la cam. Cecile

Salut, les seuils definis par k-sigma utilise aussi de la rejection (c'est le meme algo que pour la rejection des pixels qd on choisit k-sigma clipping). En gros, a chaque etape: - on calcule la mediane et le sigma - puis on calcule le seuil de rejet comme etant median + k * sigma - on enleve de la population toutes les valeurs qui sont au-dessus de ce seuil - et on recommence On s'arrete quand on ne rejette plus. La raison de ce rejet est que le sigma n'est pas un estimateur robuste (au sens des statistiques: https://fr.wikipedia.org/wiki/Robustesse_(statistiques)). Je l'illustre dans excel pour un k de 3 (c'est pas bien pratique excel pour ca... sauf a ecrire une macro mais bon, je voulais que ca soit visuel). Je retrouve bien la valeur que rend Siril. On aurait pu choisir un estimateur plus robuste genre la MAD, mais ca recoute un tri a chaque passe (meme si normalement y a besoin de moins de passes). En tout cas, le k-sig clipping, c'est agricole mais ca marche alors on a garde celui-la. Pour la rondeur, faut que je regarde mieux le code, c'est bizarre que le precentile marche pas. Apres, la rondeur c'est un des trucs penibles qui se trient a l'envers. Cecile FWHM-ksig.xlsx Note bien que quand on choisit k=0, forcement l'algo rend juste la meilleure valeur de la population...

Si tu en as 7 qui sont bonnes et que ton graphique en montre 7 qui ont l'air d'avoir une tendance differente des autres, y a peu de chance que ca ne soit pas celles la... Tu peux les afficher en faisant clic droit sur ces points. Tu peux aussi garder/exclure en masse en tracant un cadre autour des points. Un peu de lecture: https://siril.readthedocs.io/fr/stable/Plot.html#registration-plot notamment ca: https://siril.readthedocs.io/fr/stable/Plot.html#id5 et ca: https://siril.readthedocs.io/fr/stable/Plot.html#plot-interactions Cecile

@FalCT60, tu peux passer sur l'onglet graphique et montrer les courbes de fond de ciel et de nombre d'etoiles?

oui voila

Salut, Les matrices sont stockées en ligne après le caractère H dans chaque carte R du fichier .seq Mais sinon, je te conseille surtout d'utiliser ca: https://siril.readthedocs.io/fr/stable/preprocessing/registration.html#apply-existing-registration Tu choisis minimum comme méthode de cadrage et ça fera exactement ce que tu veux. Cecile Et sinon oui, le plus souvent, on empile et on recadre après

Euh non, le tirage ne rentre pas en compte non plus. Si tu shootes à 16mm de focale, la focale c'est bien 16mm. Par contre, si tu as des problèmes pour trouver une solution astrometrique à 16mm, c'est pas étonnant... en dessous de 50mm de focale, ça devient assez compliqué, en tout cas Siril a du mal. Essaie dans un autre soft (Astap, astrometry.net) de faire la resolution. Et ensuite siril se servira de ces infos pour faire la correction par photometrie.

Y a pas notion de crop factor en astro... C'est de la focale reelle dont il y a besoin pour calculer l'astrometrie. Donc 135mm. Je viens de le refaire avec la 1.2 en passant par les catalogues en ligne: 23:35:36: Plate solving image from an online catalogue for a field of view of 5.00 degrees, using a limit magnitude of 10.87 23:35:36: Catalog NOMAD size: 841 objects 23:35:36: Findstar: processing for channel 1... 23:35:36: Using 841 detected stars from image. 23:35:37: Up is +30.86 deg ClockWise wrt. N 23:35:37: Resolution: 3.649 arcsec/px 23:35:37: Focal length: 135.67 mm 23:35:37: Pixel size: 2.40 µm 23:35:37: Field of view: 05d 34m 13.89s x 03d 43m 18.45s 23:35:37: Saved focal length 135.67 and pixel size 2.40 as default values 23:35:37: Image center: alpha: 20h50m34s, delta: +30°55'27" Si je fais afficher les etoiles d'un catalogue en ligne avec la commande: nomad -catalog=tycho2 Les etoiles du catalogue tombent bien en face des etoiles de l'image Donc, la focale a utiliser, c'est bien 135mm. Quand tu ouvres la fenetre de Correction par photometrie, dans la version 1.2, si Siril detecte qu'une image a deja un solution astrometrique, il ne la refait pas (sauf si tu coches forceplate solving). La solution astrometrique qu'il y a dans l'image que tu as partagee est fausse, c'est certain. Si je lance la commande "nomad" dessus sans refaire l'astrometrie avec 135mm, ca m'affiche ca: Donc dans tes essais fructueux, il se peut que certaines etoiles de reference soient tombees en face d'autres etoiles de l'image (pas les bonnes) et il a fait la correction avec ca. Mais ca reste faux. C.

Salut, alors une piste... dans l'image que tu partages, il y a bien une solution astrométrique, mais elle n'est pas bonne. On dirait que Siril a garde la solution d'une des images (il me semblait que c'etait pas le cas mais on dirait bien que oui). Si tu n'as pas utilise la meme image de reference entre hier et aujourd'hui, il se peut que la solution ait ete bonne hier (c'etait bien celle de l'image de ref) et plus aujourd'hui (l'image de ref a change). Enfin peu importe. Toujours est-il que les infos dans le header sont pas bonnes. En supposant que la taille de pixels est bien de 2.4um, la focale est plutot a 135mm. Donc ouvre ton image, mets la focale a 135mm, coche "Force plate-solving" (pour remplacer la solution astrometrique qui n'est pas bonne) et ca devrait marcher. Cecile

.

.

Y a pas trop de raison de faire une optimisation de darks dans ton cas. Les darks sont de meme duree que tes lights et a environ la meme temperature. Par contre, si tu as bcp de pixels negatifs, c'est surtout parce que les poses manquent de signal (dit autrement, le bruit de la camera est trop grand pour faire des poses aussi courtes).

Alors,c'est le niveau de tes darks qui va pas a priori. Il est tres bas, tu leur as enleve le masterbias? Si je calibre ta brute avec le masterdark et le masterflat, j'obtiens ca: Si a la place, j'essaie a tatons de trouver le bon niveau (je me sers d'une valeur fixe de bias dans l'onglet calibration et je ne selectionne pas de masterdark), j'obtiens ca: La c'est avec une valeur de 900. On voit que les donuts de poussiere ne sont quasi plus la. Mais bon,c'est surtout pour mettre en lumiere le probleme, il faut juste que ton masterdark soit bon et y a pas besoin de bricoler. Donc je te conseille de regarder de ce cote. Et de lire ce morceau dela doc aussi: https://siril.readthedocs.io/fr/stable/preprocessing/calibration.html#troubleshooting-calibration C.

Salut, Il faudrait aussi une brute pour pouvoir dire quoi que ce soit Cecile

Oui ok, dans ce cas, il faut un peu modifier le script powershell. Avec ca, ca marche: seqsplit.ps1

Salut, si la commande n'existe pas pour une sequence, on peut contourner en utilisant la maniere decrite dans ce tuto: https://siril.org/fr/tutorials/bash-scripts/#appliquer-une-commande-pour-image-seule-à-toute-une-séquence Cecile

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

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.

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

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.

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

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

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

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.

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