Jump to content

lock042

Membre
  • Posts

    4,778
  • Joined

  • Last visited

  • Days Won

    17

About lock042

  • Birthday 04/16/1982

A propos

  • Résidence
    Dijon
  • Intérêts
    Physique, Photo, Astro, Info
  • Matériel
    Newton 200/1000
    Jumelles
    Appareil photo et divers objectifs
  • Site Web

Recent Profile Visitors

7,179 profile views

lock042's Achievements

  1. L'explication du pourquoi il y'a un flip est écrite ici : https://free-astro.org/index.php?title=Siril:FITS_orientation/fr
  2. Mais on se baserait sur quoi ? Il est facile d'intuiter qu'un rejet est trop important, en terme de pourcentage de pixel total. Mais impossible d'anticiper une valeur correcte.
  3. Attention à la correction cosmétique qui dans certains cas peut supprimer trop de pixel froid. Il vaut donc mieux les désactiver (c'est le comportement par défaut des scripts). Pour éviter de se prendre la tête avec les sigma pour les rejets. Si on a bcp d'images il y'a le nouvel algorithme de la dernière version qui est plutôt pas mal et sans prise de tête : https://siril.org/fr/download/2021-06-11-siril-0.99.10/#test-de-déviation-extrême-généralisé-de-student
  4. Pour l'instant, comme je dis, je ne vois pas trop l'intéret. Les images sont analysé une fois prétraitées. Avant on ne voit pas grand chose.
  5. Pardon j'avais mal compris. En effet, pour le prétraitement on peut pas. En fait, on part du principe qu'il faut au moins prétraiter et dématricer les images pour savoir si ca vaut le coup de les intégrer ou non à la séquence.
  6. Oui, quand on commence a vouloir faire des trucs de ce genre il faut utiliser Siril en manuel.
  7. DIsons que ca serait pas du tout logique. On a un fltre duo Ha-OIII. On sépare ces deux signaux donc on créé deux images (de façon artificiel, comme le dit @Colmic évidemment). Et les deux images se nomment suivant le nom du signal. Je ne pense pas qu'on puisse faire plus logique pour le coup. On appellerait R.... ou G.... ca prêterait à confusion avec le fait que l'extraction ait été faite après dématriçage. Ici, pas de soucis.
  8. La différence va se faire au niveau de la rejection de pixels. Plus y'a d'images, et plus les algos sont fiables. Surtout le dernier mis en place. Ensuite la normalisation. La normalisation va se retrouver différente d'un stack a l'autre. Alors que si on met tout ensemble, non. A mon sens il vaut toujours mieux tout empiler ensemble.
  9. Il aime si on lui dit d'aimer. https://siril.org/fr/tutorials/dynamic-psf/
  10. Bel essai et belle utilisation de Siril :). Bravo.
  11. Ca sera très probablement ajouté dans la prochaine version. Mais pas sous cette forme : S/N = 2-3: object barely detected S/N = 5: object detected, one can really start to beleive what one sees S/N = 10: we can stat to do measurements S/N = 100: excellent measurment.
  12. Non, pas actuellement, pas au sens ou tu l'entends. Il est cependant possible d'avoir une estimation du bruit de l'image. Soit avec la commande bgnoise, soit par l'interface graphique. C'est exact oui.
  13. Libre a toi de modifier le script ou de faire en manuel pour directement utiliser ton master.
  14. Moi je parle seulement de ce que je connais, et donc de Siril, et pour le coup c'est pas pour faire de l'argent :). Je ne me permettrai pas de parler à la place des dev de APP/PI. Oui, mais ici le problème c'est le traitement par batch avec un nombre élevé d'image. La vraie limite de toute façon, à mon avis, c'est la lecture/écriture des images.
×
×
  • 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.