Cissou8

Salut, en fait, je pense que ca vient de tes reglages dans Excel... je l'utilise dans sa version anglaise, ce qui me permet d'eviter toutes les confusions entre les points et les virgules. Je ne sais pas si c'est simple de passer de l'un a l'autre sans tout deregler, mais ca simplifie bcp le process: je colle depuis la page web et ensuite je colle depuis excel vers le fichier xml sans avoir besoin de changer quoi que ce soit.

Ben en fait tu as la possibilité de le faire des 2 façons: https://siril.org/fr/tutorials/synthetic-biases/#et-maintenant Soit une valeur. Ça peut être le cas quand tu te fais un script perso, que tu sais tu touches jamais au réglage d'offset de ta cam etc etc.... Soit une fomule. La, dans les scripts que Colmic distribue, il ne sait pas a priori, si les gens qui s'en servent se mettent au reglage par défaut ou s'amusent à en changer. Donc il passe par une formule qui permet de rendre le script plus générique. C.

Ce que j'explique dans l'article, c'est que pour une 294 avec un offset réglé à 30, j'obtiens 1920 adu. Donc mon multiplicateur c'est 64. J'aurais pu en rester là. La suite du texte, c'est pour expliquer pourquoi c'est normal qu'on trouve que ce multiplicateur (64) est un multiple de 4. C'est effectivement à cause de ma cam qui est en 14b (et de mon soft d'acquisition qui écrit les zeros à droite). Ça permet de voir si le multiplicateur qu'on a mesuré a un sens ou s'il peut y avoir une erreur (de mesure ou d'interprétation). Si j'avais fait ma courbe et trouve une pente à 30 par exemple, j'aurais dit... c'est bizarre. Mais voilà rien de plus, le multiplicateur, c'est bien le 64. Et je rentre bien =64*$OFFSET dans mes scripts maison. Donc si je comprends bien ce que tu dis, dans des scripts pour une 533, il faut mettre =40*$OFFSET J'espere que c'est plus clair 😁

Salut @Colmic, Alors, j'ai pas eu d'images de 533 entre les mains mais le raisonnement est pas bon. Si tu mets 10*$OFFSET, ça va vraiment faire 10*70=700. Dit autrement, on ne fait aucune supposition ou conversion sur le bitdepth de l'ADC (parce que certains softs paddent les 2 bits manquants à gauche et d'autres à droite) et on ne suppose pas non plus que l'utilisateur y pense Donc c'est basique, si tu lis 2800 adu quand tu ouvres un bias, et que le réglage que tu as donné (ou laisser ton soft d'acquisition faire et qu'il a choisi pour toi) est 70, le multiplicateur c'est 40. Cecile

Ah c'est interessant merci! On en discutait en off avec @lock042. Lui aussi a essaye avec des images faites a la cam mono, il a pas d'artefacts non plus avec lanczos. De mon cote, j'ai ressaye avec des images de cam couleur.... catastrophe: Le ringing du a lanczos, c'est ces anneaux qui apparaissent dans les étoiles brillantes. C'est explique la pour ceux que ca interesserait: https://en.wikipedia.org/wiki/Lanczos_resampling#Limitations C'est a cause de ça que Lanczos est pas l'algo par defaut dans Siril. Maintenant, savoir s'il s'agit de problemes lies au sampling ou a la debayerisation, va falloir que je creuse sur mon disque pour trouver des exemples et des contre-exemples...

Oui ok. La raison pour laquelle je te disais que lanczos, j'y crois pas trop c'est que la biblio qu'on utilise pour gérer ces interpolations nous donne pas accès au clamping, il est codé en dur. Donc, on a souvent vu des images avec du ringing autour des etoiles avec cet algo. Après, j'imagine que ça dépend des images donc écoute, pourquoi pas le tenter....

Alors y a 2 aspects dans l'alignement: - comment on détermine la transformation qui permet de passer d'une image à l'autre (les fameuses matrices dont parlait @clouzot) - une fois qu'on connait la transformation, comment on l'applique, enfin quel algo d'interpolation. Ta question est plutôt sur la première. On est bien subpixel dans l'alignement global, tout comme Pix. Dans Pix, ce que je ne sais pas, c'est combien de degré de liberté sont calculés par défaut. Voire meme s'il calcule une transformation non lineaire. Dans siril, c'est lineaire et c'est 8 (on calcule une homographie). Ça permet d'être suffisamment "souple" quand on passe des images ou il y a de la déformation. Le cas général en gros. Sur une optique bien réglée et avec peu de champ, ce qui a l'air d'être ton cas, c'est peut-être trop souple. Je te dirais de tenter une similarité qui n'a que 4 degrés de liberté (y a un menu déroulant dans l'onglet). L'autre aspect, c'est l'interpolation. C'est ce que t'a fait tester Cyril. Il faut peut-être essayer avec d'autres algo. Le lanczos4, j'y crois pas trop. Le cubic, il lui arrive de faire des artefacts. Mais bon, si tu as le temps et l'envie, ça vaut le coup de chercher celui qui marche le mieux avec ton set-up. Pas de souci, c'est vraiment pas pris comme ça. Au contraire, c'est tjs intéressant de se confronter à ce que font les autres, quand c'est fait avec méthode, ce que tu fais avec tous tes tests. Donc merci!

La j'ai fait avec ce que j'avais sous la main, c'est a dire ce qu'on ecrit dans les.seq de la version officielle, c'est a dire pas grand chose. Ensuite, a cette etape il s'agit simplement de choisir une bonne reference pour aligner, c'est pas encore le tri. Les formules dont tu parles dans Pix, il me semble que c'est pour ponderer les images pendant l'empilement. Et la aussi, dans la prochaine version, il y aura moyen de mettre des poids d'empilement en fonction de la wFWHM (une combinaison de FWHM et nb d'etoiles) ou du nombre d'etoiles tout court.

Alors effectivement, ta FWHM etait moins bonne en debut de session (cible une peu basse?) et elle s'est amelioree au fur et a mesure. La on voit que si tu retiens les 80% les meilleures en FWHM, celle qui sert a aligner n'est meme pas dans celles qui sont retenues. Est-ce que c'est ca qui fait que l'empilement en patit ensuite... peut-etre. Pour tester, ce que tu peux faire, c'est: - tu ouvres ta sequence pp_Light_ngc891field_60.0s_Bin1_183MM_L_ (attention, la non alignee, donc sans le prefixe r_) - tu ouvres la trieuse et tu selectionnes l'image 187 - tu coches la boite en haut pour dire que tu veux que ce soit elle la reference et tu refais l'alignement puis l'empilement. Si c'est ca, et bien il faudra etre un peu patient.... comme je disais plus haut, dans la prochaine version on aura l'alignement en 2 passes qui fait exactement ce que je viens de faire a la main. Extraire une fois les donnees comme le FWHM etc mais sans aligner, determiner la meilleure ref (en regardant qu'elle arrive bien a aligner les copines, que le cadrage est pas moisi etc...). Et ensuite, tu appliques l'alignement pour obtenir ta sequence r_. C'est plus long a faire (y a 2 lectures d'image au lieu d'une) mais si ca ameliore tes resultats, on va dire que ca vaut le coup. C.

Ah super, merci pour le test! Donc on en vient a l'alignement... alors, je vais etre un peu en aveugle parce qu'il manque un peu beaucoup des sorties dans la 1.0.5. Mais est-ce que tu pourrais me faire passer le .seq de la sequence alignee? Que je jette qd meme un oeil? Tu fais un alignement global sans toucher a aucun parametre dans Siril? EDIT: ah mais tu m'as donne la reponse... donc oui,tout par defaut

Pour discriminer l'étape d'empilement ou celle de l'alignement, est ce que tu as la possibilité de faire l'empilement sur le même jeu d'images? Je sais que pix a un format bien à lui pour bosser. Tu peux en faire une sortie vers un format lisible par siril? Comme ça, on regarde ensuite si l'empilement te donne la même fwhm (ou non).

Je sais pas si on peut ca sur le compte de l'alignement.Sauf a ce que l'image qui a servi de reference (la premiere de la sequence par defaut dans la version officielle) soit completement hors focus. J'en connais qui font ca, il se reconnaitra 😂 Dans la prochaine version, on pourra faire l'alignement en 2 passes pour eviter cet ecueil. Apres, il faut vraiment regarder la comparaison, si la mesure de FWHM a ete faite avec le meme soft etc... N'ayant pas Pix, c'est pas une mesure que j'ai eu l'occasion de faire. Mais je veux bien voir des resultats si ca peut permettre de faire avancer le schmilblick.

"Clipping" c'était mon tel qui a corrigé un truc qu'il aurait pas du Pourquoi aller au delà? Pas se prendre la tête sans perdre non plus des masses de dynamique. Si tu changes de gain, il faudra monter la valeur. Si tu fais des expos longues, il faudra monter la valeur.... en fait, comme c'est pas un réglage qu'on a sous les yeux souvent on a vite fait d'oublier de le régler. Et ça finit tjs par arriver qu'on a pas la bonne valeur dans ses lights ou ses darks ou ailleurs. La valeur de 30, elle passe à peu près partout sans se poser de question. Et avoir un truc de moins à gérer, c'est toujours appreciable. C'est juste un conseil, tu peux choisir de le régler à chaque fois aussi hein...

J'ai jamais vu cette valeur dans une doc. Il me semble que c'est celle qui se met quand j'ouvre la cam avec asicap ou Nina. Essaie pas de viser trop bas. Si jamais tu monte le gain, tu vas te retrouver embêté avec des pixels qui clippent. Avec 30, tu auras un niveau de noir à 1920.

Salut, Dans Siril, quand on fait des statistiques, on enleve les valeurs nulles en 16b. Parce qu'une valeur nulle, en réalité tu ne sais pas combien elle vaut, elle a clippé. Du coup, je comprends que tu as fait tes biais et tes darks avec la caméra réglée sur un offset de 0. Ce qui est n'est pas une bonne idée. Je te conseille de laisser la valeur par défaut de la caméra (reglage à 30, j'ai la meme cam) et de refaire tes images. Pour les bias pas trop la peine de t'embêter à les faire non plus. Je te renvoie vers un de nos tutos: https://siril.org/fr/tutorials/synthetic-biases/ Cecile

Salut, dans la prochaine 1.2, il y aura effectivement plus de criteres et notament la possibilite de trier par valeur du fond de ciel, nbre d'etoiles etc etc. Ca s'integrera dans une "nouvelle" methode d'alignement qui justement calcule tous ces indicateurs (en plus des stats) mais n'ecrit pas les images alignees. Tu pourras donc faire des tris (il y a aussi des filtres comme dans l'onglet empilement) avant de proceder a l'alignement effectif des images que tu auras retenues. On a aussi ajoute des possibilites de ponderation dans l'empilement, qui doivent peu ou prou se debarrasser de ces images sans que tu aies a faire quoi que ce soit. C.

Salut, c'est illustré en image la: https://siril.org/fr/download/2021-11-20-siril-1.0.0-rc1/#lastrométrie-des-images-grand-champ Il me semble qu'on avait fait une vidéo aussi, mais je me rappelle plus où elle est rangée @lock042, @vinvin une idée?

Salut, - Il n'y a pas de filtre sur la fwhm dans les scripts par défaut. - Tu trouveras le chemin des scripts en faisant Ctrl+P (ca ouvre le menu des préférences), onglet scripts. Je te conseille de te faire un autre dossier dans lequel tu iras mettre tes scripts perso en ajoutant le chemin de ce nouveau dossier au même endroit. Ce sont des fichiers texte modifiables avec n'importe quel éditeur. Pour ajouter un filtre sur la fwhm à l'empilement, tu cherches les lignes qui commence par stack dans le script (il y en a 2 pour le Ha OIII) et tu ajoutes l'option -filter-fwhm=90%. Quand tu ajoutes un nouveau script, pense bien à taper la commande reloadscripts. Ça rescanne tous les dossiers déclarés dans les préférences et ça rafraîchit la liste des scripts disponibles. Un coup d'œil à la FAQ au cas où: https://siril.org/fr/faq/#comment-créer-un-script- Et à la référence des commandes et de leurs options: https://free-astro.org/index.php?title=Siril:Commands&oldid=8045#stack Voilà! Cécile

salut, je vois pas de gros trucs. Si ce n'est l'alignement du <ThreadSize> L269 qui devrait etre aligne avec la balise de la ligne du dessus et le pitch ligne 273 qui devrait etre a 1 et pas 0.1. Mais je sais pas si l'un ou l'autre de ces trucs est un reel probleme. Le format n'etant pas documente... C.

Salut, oui c'est ça, tu mets le même diamètre côté vis et côté ecrou et tu choisis un profil qui correspond à ce diamètre nominal. C.

Il me semble que les scripts francais ne s'installent que sur la version Windows et que si on selectionne Francais pendant l'install. Sur Mac, je crois que c'est le bazar quand on prepare le bundle (et qu'Appple decide d'un jour a l'autre que ce qui passait la veille est absolument ignominieux le lendemain) et que donc, on s'est abstenu de faire encore plus complique (pour nous, et quand je dis "nous" je veux dire @lock042). Par contre, oui, y a pas de raison évidente que les scripts français existants ne soient pas compatibles avec la 1.0.2.

Salut, c'est vrai que j'ai jamais raconté ce que faisait la feuille excel. Les dimensions qu'elles donnent sont des valeurs théoriques. En gros, j'ai déterminé les formules en essayant de reproduire au mieux les valeurs pour les filets métriques standard, qui sont dans un autre des XML qui s'installent directement avec fusion. Le besoin de rétracter les filets est donc le même que quand on utilise un des filetages standards. J'imagine que ça dépend de chaque imprimante et de à quel point on veut qqchose d'ajusté (quite a avoir besoin de "roder" fort l'assemblage). Cécile

salut, le fichier astroprofile.xml que tu as mis dans le repertoire, c'est un que tu as modifie toi ou c'est celui donne en lien plus haut? C.

T'as peur hein Alors, autre recette perso avec cette cam, je vise un temps pour les flats entre 0.5 et 0.9s. A partir de 1s, ca fait n'inporte quoi, en tout cas la mienne. Et ça corrobore ce qui est décrit dans la section 3.6 de cet excellent lien: http://www.astrosurf.com/buil/asi294mm/ Pour les ADU, vers 20-30000. Et tjs à gain 120. A gain 0, ça fait des grumeaux (aussi décrit dans le lien). Après, j'ai pas un C8... sur ma lulu, une 61edphII, la recette marche au top. Sur mon newton, j'ai des soucis mais je soupçonne des réflexions avec le correcteur de coma. Cécile

Je crois que je préférerais annoter toutes les photos de tout le monde a la main que d'avoir a retoucher a ce bazar 😂