Jump to content

Cissou8

Membre
  • Posts

    269
  • Joined

  • Last visited

  • Days Won

    1

1 Follower

A propos

  • Résidence
    Nice

Recent Profile Visitors

3,115 profile views

Cissou8's Achievements

  1. Alors effectivement, dans la prochaine version, tu pourras aussi, après avoir fait une sequence avec tous tes stacks aux différents temps, aligner et choisir de ne garder que la zone commune à toutes les images. Ce qui te débarrassera des "bords".
  2. Pour ce qui est deja ajoute, c'est la: https://gitlab.com/free-astro/siril/-/blob/master/ChangeLog Et pour ce qui le sera (un jour peut-etre....), il y a les tickets: https://gitlab.com/free-astro/siril/-/issues C.
  3. 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.
  4. 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.
  5. 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 😁
  6. 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
  7. 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...
  8. 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....
  9. 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!
  10. 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.
  11. 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.
  12. 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
  13. 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).
  14. 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.
  15. "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...
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.