nico1038

On va voir ce que @lock042 en pense. En tous cas ça ne le fait pas avec tous les fichiers ARW. J'en ai quelques uns qui s'ouvrent sans problème avec la beta2

Il me semble qu'il y a eu plusieurs applis stellarium pour mobile et je crois que celle que tu nous montre n'est plus disponible sur le google (et apple?) store. Perso la version que j'ai sur mon tel (android) s'appelle "Stellarium" tout court et est en version 1.14.1

A priori j'arrive à aligner les 3 images avec Siril 1.2.6. En faisant défiler les images, l'alignement me semble très bon: les étoiles ne bougent pas et le paysage se décale.

Bug ou pas, ce genre d'image peut être un challenge à aligner. Tu peux partager 3 images brutes? Edit: je viens de voir que tu les avais ajouté plus haut

Tu es sûr? Avec la 1.2.6 j'ai ça lors d'un alignement avec une sélection ( et en cochant "Aligner les étoiles dans la sélection") et avec la 1.4.0 beta2, j'ai ça: On voit qu'avec la version beta les étoiles détectées ne sont pas limitées à la sélection. D'ailleurs avec la 1.2.6 l'alignement échoue avec une sélection trop petite alors que ça n'est pas le cas avec la 1.4, même avec une sélection minuscule.

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?