Cissou8

17 hours ago, FalCT60 said:

Donc le résultat final du prétraitement devrait être cohérent et bien rattrapé par la balance effectuée lors de l'étalonnage des couleurs, non ?

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

19 minutes ago, FalCT60 said:

Merci. Mais encore faudrait-il pour cela que le problème du pilote fût réglé.

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.

2 minutes ago, FalCT60 said:

J'espère toutefois n'avoir pas été con au point de rater les bias !

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.

1 hour ago, FalCT60 said:

Le capteur est censé être 12 bits (sauf erreur de ma part) pour lequel le tuto stipule qu'il faut utiliser un facteur 16.

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.

1 hour ago, FalCT60 said:

Au gain 120 que j'utilise, l'offset déterminé de façon empirique avec Sharpcap est 13. Et 120 est actuellement la valeur que j'indique en tant que master offset.

Néanmoins, si à présent j'utilise 64*$OFFSET, je vais me retrouver avec une valeur de 832 et non plus de 120.

Valeur qui, par ailleurs, serait bien cohérente avec les mesures effectuées, et en tout cas bien à sa place entre 736 et 1064, resp. offset 10 et 15.

Je comprends pas pourquoi tu utilises 120 comme master offset... Et oui, 832, ca sera plus coherant avec les mesures que tu as faites.

1 hour ago, FalCT60 said:

J'ai voulu voir si cela induisait un quelconque changement entre un prétraitement avec 120 ou 64x$OFFSET et n'ai rien remarqué qui semble anormal ni flagrant.

Soit je ne sais pas regarder, soit ce ne sera visible que dans certaines conditions, par exemple de forts écarts thermiques, étant donné que ma caméra n'est pas refroidie.

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

7 hours ago, jDef said:

noout : on fait l'alignement en prenant la 1ère image de la séquence comme référence et on ne crée pas le fichier r_xxxx

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:

2 hours ago, jDef said:

setfindstar -relax=on -focal=2265 -pixelsize=2.9 -sigma=0.7
seqextract_Green pp_light
register Green_pp_light -2pass -noout -transf=shift -nostarlist -interp=la -minpairs=5
#register pp_light -2pass -noout -transf=shift -nostarlist -interp=la -minpairs=5
seqsplit_cfa pp_light
getref Green_pp_light

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

2 hours ago, jDef said:

cd process
setfindstar -relax=on -focal=2265 -pixelsize=5.8 -sigma=0.7

#Couche Rouge
cd CFA0
#convert CFA_0 -fitseq
seqsubsky CFA_0 1
setref bkg_CFA_0 1828 #+1 par rapport à getref
register bkg_CFA_0 -transf=shift -nostarlist -interp=la -minpairs=5
stack r_bkg_CFA_0 rej 3 4.5 -norm=addscale -output_norm -out=../CFA_0_NGC898_$STACKCNT:%d$Img_$EXPTIME:%d$s -weight_from_wfwhm -filter-round=0.7
cd ..

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

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 

9 minutes ago, FalCT60 said:

Après conversion, j'ai chargé une image puis ma séquence et cliqué sur l'outil de photométrie.

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

10 hours ago, jDef said:

J'ai peut-être mal compris le comportement du filtrage, mais il me semble qu'entre 2 séquences des plans de couleur verte et rouge par exemple, si je choisi un filtrage à 90% sur la FHWM, ça me donne un seuil en FHWM calculé sur la statistique de la FHWM et on ne garde que les images ayant une valeur de FHWM inférieure à ce seuil, donc un nombre d'images variable en fonction de la statistique de FHWM pour chaque plan couleur.

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.

10 hours ago, jDef said:

• Séquence 400 images et Filtrage FHWM 90% (300 images) et Filtrage Rondeur 90% (270 images) et Filtrage nombre 250 : au final on garde les 250 premières = Min(250,270)
• Séquence 400 images et Filtrage FHWM 90% (300 images) et Filtrage Rondeur 90% (270 images) et Filtrage nombre 290 : au final on garde les 270 premières = Min(290,270)
• Séquence 400 images et Filtrage nombre 290 : au final on garde les 290 premières images de la séquence (0-->289) = Min(290, 400)

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