nico1038

J'ai essayé et, effectivement, la sélection ne semble pas prise en compte. Je me demande si il ne s'agit pas d'un bug de cette version beta?

Hello @HLe Dans l'idéal il faudrait partager quelques images pour nous permettre de tester mais voilà deux choses à considérer: Dans l'onglet Alignement, tu as fait une sélection mais tu n'as pas coché "Aligner les étoiles dans la sélection". Or tu as plein d'étoiles qui sont détectées à tort sur le paysage et qui vont donc inévitablement fausser l'alignement. Par ailleurs il est facile de vérifier la qualité de l'alignement en affichant les images de la séquence (il faut juste veiller à ce que ce soit bien la séquence des images alignées qui est sélectionnée, celle préfixée par r_ ) et en les faisant défiler. Si tu vois que les images ne sont pas alignées correctement sur les étoiles ça n'est pas la peine de les empiler.

Oui

Bonjour, J'ai l'impression que Siril (1.4.0-beta1) crash quand on ouvre les fichiers xisf codés sur 8-bit J'ai reproduit le problème sur Windows et Linux avec différents fichiers. Fichier de test: WR134_3.xisf Retour console du plantage: The URI points to a local file. nb_elts_at_start: 0 nb_elts_on_exit: 0 Purging previously saved reference frame data. Error, signal 11: Please report this bug to: https://gitlab.com/free-astro/siril/issues siril(+0x152e21) [0x555a09acee21] /lib/x86_64-linux-gnu/libc.so.6(+0x45250) [0x727963a45250] /lib/x86_64-linux-gnu/libc.so.6(+0x19570d) [0x727963b9570d] siril(fits_flip_top_to_bottom+0xbb) [0x555a09b7883b] siril(readxisf+0x2e4) [0x555a09b8bed4] siril(any_to_fits+0x19b) [0x555a09b54fdb] siril(read_single_image+0x180) [0x555a09baa5e0] siril(open_single_image+0xa6) [0x555a09baa7e6] siril(+0x29cfe2) [0x555a09c18fe2] siril(open_action_activate+0x17) [0x555a09ac5a47] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x14a) [0x727969a8e45a] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x463a3) [0x727969abe3a3] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x36f0d) [0x727969aaef0d] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x41) [0x727969aaf181] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x727969aaf243] /lib/x86_64-linux-gnu/libgio-2.0.so.0(+0xf2925) [0x727969bce925] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0xe192f) [0x7279692e192f] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x3707a) [0x727969aaf07a] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x41) [0x727969aaf181] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x727969aaf243] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0xe3021) [0x7279692e3021] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x3707a) [0x727969aaf07a] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x41) [0x727969aaf181] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x727969aaf243] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0xe2e5d) [0x7279692e2e5d] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0xa1b1c) [0x7279692a1b1c] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x3707a) [0x727969aaf07a] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x41) [0x727969aaf181] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x727969aaf243] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1be99b) [0x7279693be99b] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__BOXEDv+0xa5) [0x727969a92a65] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x3707a) [0x727969aaf07a] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x41) [0x727969aaf181] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x727969aaf243] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1b6664) [0x7279693b6664] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1be373) [0x7279693be373] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x1c1bde) [0x7279693c1bde] /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_event_controller_handle_event+0x73) [0x727969381163] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x367ea0) [0x727969567ea0] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0xa02d9) [0x7279692a02d9] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x3707a) [0x727969aaf07a] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x41) [0x727969aaf181] /lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x727969aaf243] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x377a4c) [0x727969577a4c] /lib/x86_64-linux-gnu/libgtk-3.so.0(+0x20bfa8) [0x72796940bfa8] /lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_do_event+0xc1a) [0x72796940cd2a] /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x3d7c7) [0x7279691337c7] /lib/x86_64-linux-gnu/libgdk-3.so.0(+0x97f7e) [0x72796918df7e] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x5f397) [0x727969d13397] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xbfdc7) [0x727969d73dc7] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33) [0x727969d128b3] /lib/x86_64-linux-gnu/libgio-2.0.so.0(g_application_run+0x1ed) [0x727969bc765d] siril(main+0x15f) [0x555a09a1facf] /lib/x86_64-linux-gnu/libc.so.6(+0x2a3b8) [0x727963a2a3b8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x727963a2a47b] siril(_start+0x25) [0x555a09a1fce5] Nico

SPFC ne change rien aux couleurs de l'image (il ne modifie d'ailleurs rien à l'image). Pour le moment il est seulement nécessaire en préalable si tu veux utiliser le nouvel outil de correction du gradient MGC (mais malheureusement il y a un trou dans la base de donné MARS autour de M101 pour le moment et MGC ne peut donc pas être utilisé directement ici).

Je pensais aussi à quelquechose comme ça avec les 2 halos correspondants à Mizar et Alkaid mais, en traçant des cercles centrés sur ces étoiles, ça ne colle pas exactement: Mais la coïncidence est quand même troublante. Je ne sais pas quoi en penser?

J'ai constaté moi aussi que le script OSC_Preprocessing était un peu plus lent avec cette nouvelle version. En l’occurrence, sur 2 jeux de données différents, le script est 40 à 50% plus long avec la 1.4 par rapport à la 1.2.6. Je me demande d'où peut venir cette différence étant donné que je ne vois dans ce script particulier ce qui change par rapport la version d'avant? J'ai sauvegardé les logs des 2 versions lors de mon test sur mon 2ème jeu de donnée. Les voici au cas où: Siril_1.2.log Siril_1.4.log Je peux aussi fournir l'ensemble des données si nécessaire. Le traitement reste très rapide pour empiler 130 images sur ma vieille machine mais j'ai trouvé cet écart étrange. Nico

Oui, je comprend le risque. En tous cas merci pour les explications.

Je trouve au contraire que c'est une procedure normale d'ouvrir une image CFA pour analyser ses acquisitions (notament ses statistiques et son histogramme) et il ne me semble pas invraisemblable de vouloir l'observer dans le bon sens. Et je sais comment ouvrir une image en la dematriciant, ce que j'ignore c'est comment dematricier une image CFA deja ouverte (parce qu'il me semble que c'est uniquement dans cette circonstance que le que le retournement pourrait poser un probleme).

Bravo Malik: c'est une image extraordinaire!

Je vois, j'aurais du y penser! Le fichier contient en effet la ligne suivante dans son entête: BAYERPAT= 'RGGB ' / Bayer color pattern Cela dit je trouve ce contrôle un peu strict quand on ouvre une image seule et pas une séquence. Dans mon cas d'usage j'ouvre une brute pour l'annoter et vérifier mon cadrage par exemple. J'aimerais donc qu'elle soit considérée comme une image monochrome classique (sans tenir compte du motif de bayer) afin de pouvoir être remis dans le bon sens par le platesolve (avec éventuellement un message d'alerte vis à vis du motif de bayer). D'ailleurs, même si je le voulais, je ne sais pas comment faire pour dematricier une image CFA une fois qu'elle est ouverte dans Siril?

Hello David, Avec des données de cette qualité, la calibration des couleurs devrait être facile en principe. Sur ton screenshot, je vois que tu utilises PCC alors que le nouvel outil SPCC est à privilégier dans quasiment toutes les circonstances. La différence de résultat peut être importante. Pour le workflow, l'important est de combiner les couches RGB immédiatement avec le process RGBCombination (il faut juste qu'elles soient alignées. Aucun autre traitement n'est nécessaires sur les couches individuelles) puis d'appliquer SPCC sur l'image RGB. Normalement en faisant ça tu devrais avoir un résultat de la calibration efficace (avec, sur les graphiques de SPCC, des courbes de non régressions bien définies et peu de dispersions des points). Il est vrai qu'il est difficile de trouver des ressources fiables sur Pixinsight et qu'on se perd dans la quantité de tutos disponibles. Je te conseille avant tout le site de Pix ainsi que la chaine youtube officielle qui présente notamment des exemples de traitements. Au moins, tu es sûr de la fiabilité de l'information. Nico

Très belle image. Les couleurs sont superbes.

Elle est magnifique. Bravo

J'ai trouvé ce rapport de bug qui semble directement lié : https://gitlab.com/free-astro/siril/-/issues/1488 En fait il n'est pas prévu de supprimer l'option "Flip Image if needed" mais celle ci n'apparait pas dans certaines circonstances (j'avoue ne pas bien saisir pourquoi? ) Le rapport indique un lien avec le dématriciage de l'image et, en effet, si j'ouvre mon image (qui est juste une image brute) en la dématriciant, l'option apparait bien! Le bug est indiqué comme corrigé mais je ne sais pas si il l'est dans ma version de Siril (1.4.0-beta 1)?

Non pas du tout: le platesolve fonctionne mais l'image n'est pas inversée comme (je pense) elle devrait l'être.

Bonjour, Dans la version 1.2 de Siril il existait une option "Flip Image if needed" qui permettait d'inverser l'image quand la résolution astrométrique détectait que c'était nécessaire. Avec la version 1.4, cette option a disparu. D'après cette page: https://siril.readthedocs.io/en/latest/astrometry/platesolving.html il semble que l'idée est désormais que cette option soit activée par défaut. Seulement j'ai l'impression que ça ne marche pas (ou pas toujours) Par exemple avec ce fichier : Light_M81perso_120.0s_Bin1_0140.fit Si je l'ouvre et que j'applique la commande platesolve -force Siril résout l'image, détecte qu'elle est "flipped" (c'est visible dans la sortie console) mais ne l'inverse pas. On obtient le même résultat en passant par l'interface graphique ImagePlateSolver Je peux ouvrir un bug si nécessaire mais je me demande si je ne rate pas quelque chose? Nico

Il est possible d'identifier cet astéroïde avec Pixinsight en annotant cette image. Pour avoir les astéroïdes il te faut télécharger les éphémérides de Pix pour les astéroïdes (au format xeph). Cette base de données contient 750000 astéroïdes. Effectivement il semble qu'il y ait une 1h de décalage par rapport à l'heure déclarée du fichier. En annotant le fichier pour le 03/04/2025 à 00h07min on obtient cette annotation (j'ai aussi limité la magnitude à 15 car il y a également 7 autres astéroides de magnitude 19 à 21 qui ne sont pas visibles du tout)

Tu peux nous dire dans quel coin exactement? C'est un peu loin pour moi mais j'aimerais viser des cibles très basses cet été et j'ai du mal à touver un coin pas trop loin de Paris avec un horizon sud dénué de pollution lumineuse. Peux être que le morvan est le seul choix?

Comment vous faites: vous repartez des images brutes ou vous combinez directement les masters de chacun?

Très sympa. Quel est le modèle de ton appareil APSC?

A mon avis il fonctionnent aussi bien l'un que l'autre. Cela dit il faudrait décocher le bouton AutoWB pour se faire une idée plus juste de l'histo (je doute que les 3 courbes soient alignées comme ça).

Je ne sais pas qui te dit que tes flats ne vont pas mais le résultat de la calibration est le seul critère qui compte. Si ils corrigent correctement le vignettage et les poussières ça n'est vraiement pas la peine de te prendre la tête avec ça. Quand aux deux autres points voici mon avis: Bias ou dark flats, ça n'a aucune importance (en tous cas avec la 2600MC) l'un ou l'autre fonctionne parfaitement pour calibrer les flats Le temps de pose est beaucoup moins critique qu'on ne le pense en général. Il n'y a pas de durée optimum mais une large plage de durée où les résultats (pour la même durée totale d'acquisition) sont équivalents. Le seul cas ou il faut faire vraiement attention c'est si on est dans un environnement très pollué.

Hello @Legoraf, C'est une image pas évidente à traiter. Ta lunette souffre de chromatisme (c'est un point faible de ce modèle) ce qui complique le rendu des étoiles mais surtout, je pense que tu as un soucis de calibration: on retrouve sur tes masters des bandes sombres en haut et en bas qui posent des problèmes pour la suite du traitement et obligent à cropper pas mal. Voici ma version, réalisée avec Pix: Nico

Il faut bien comprendre que visualiser une image toute blanche ne veux pas nécessairement dire que l'image est saturée (si la courbe est au 2/3, l'image n'est, par définition, pas toute blanche). Ce qui se passe c'est que la plupart des logiciels astronomiques ont la possibilité de visualiser une image en mode étirée pour pouvoir visualiser correctement les images astronomiques linéaires. C'est le STF de Pixinsight ou le mode Autoajustement de Siril par exemple. Avec des flats il faut se méfier de ce genre de visualisation car elle peut donner une idée complétement fausse des flats. La meilleur façon de les visualiser est plutôt une visualisation 100% linéaire qui donnera une idée plus juste de l'illumination de ses images et de ses flats. Comme le dit @Ant-1, la position du pic de l'histogramme a en fait peu d'importance et (sauf cas particulier) des flats doivent corriger aussi bien avec le pic à 1/3 ou à 2/3. Pour vérifier la bonne correction, pas besoin d'attendre l'image empilée. Ce qu'on peut faire c'est comparer une image brute avec une image calibrée. De cette façon on peut voir immédiatement si la division par le masterflat a correctement fait son travail avec une correction du vignetage et des poussières. C'est une comparaison qu'on peut faire au tout début du traitement et que je fais personnellement systématiquement. Par exemple: Nico