Aller au contenu

Cissou8

Membre
  • Compteur de contenus

    340
  • Inscription

  • Dernière visite

  • Jours gagnés

    1

1 abonné

A propos

  • Résidence
    Nice

Visiteurs récents du profil

4883 visualisations du profil

Cissou8's Achievements

  1. 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
  2. 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...
  3. 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
  4. @FalCT60, tu peux passer sur l'onglet graphique et montrer les courbes de fond de ciel et de nombre d'etoiles?
  5. 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
  6. 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.
  7. 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.
  8. 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
  9. 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).
  10. 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.
  11. Salut, Il faudrait aussi une brute pour pouvoir dire quoi que ce soit Cecile
  12. Oui ok, dans ce cas, il faut un peu modifier le script powershell. Avec ca, ca marche: seqsplit.ps1
×
×
  • 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.