nico1038

Non,non c'est le contraire: c'est 500mm de focale minimum (avec des pixels de 3.75). Avec le C8 tu dois avoir un échantillonage bien inférieur à 1,5 arcsec/px. Dans l'autre sens c'est plutôt la taille de l'image qui peut poser un problème je pense. J’espère de pas avoir été trop catégorique avec ces chiffres (qui sont complétement arbitraires). N’hésitez surtout pas à poster vos images, c'est l'expérience qui va nous dire ce qui marche ou pas.

Merci Seb, Du coup je partage la mienne (j'aurais sans doute du commencer par ça...). Image acquise en aout 2022, 155x120s, 0.961 arcsec/px M63_nico1038.fit

Bonjour à tous, Dans le forum d'en face j'ai réagi l'autre jour à une discussion qui proposait de partager des données déjà acquises pour les combiner et voir ce qu'on pouvait en tirer. La discussion n'a finalement rien donné mais ça m'a fait réfléchir et j'aimerais relancer l'idée ici et voir si certains d'entre vous seraient prêts à partager leurs images et à participer à ce genre d'exercice? L'idée est la suivante: on choisit une cible ensemble et on partage nos images (empilées) qui traine sur nos disques durs. Les images sont partagées directement sur ce sujet et sont donc à la disposition de tous pour essayer de les combiner de la meilleure façon possible (ce qui n'est pas un exercice simple à mon avis) et de faire le traitement. L'objectif final étant de voir dans quelle mesure ce genre de combinaison d'images hétéroclites peut permettre d'améliorer les choses par rapport aux résultats obtenus chacun de notre coté. Bien sûr, le fait de combiner des images a posteriori, sans aucune coordination préalables sur les acquisitions va entrainer des contraintes importantes (et surement un impact sur le résultat final) mais ça a l'avantage énorme d'être facile et immédiat à mettre en œuvre. Voilà quelques réflexions sur le choix de la cible et les quelques contraintes à respecter: Choix de la cible: Il faut que la cible soit suffisamment populaire pour avoir été shooté par un nombre conséquent d'astronomes Il faut que la cible soit suffisamment petite pour qu'on puisse obtenir une image finale qui contienne cette cible avec des images cadrées complétement différemment les unes des autres.. Il faut à mon avis éviter d'avoir des étoiles trop brillantes dans le champ pour limiter les problématiques liés aux aigrettes. Il faut une cible sur laquelle un temps de pose cumulé conséquent présente un intérêt particulier avec si possible quelque chose de diffus à essayer de révéler. Pour ces raisons, je pense qu'une galaxie est le meilleur choix possible. J'avais pensé par exemple à M63 qui est un galaxie superbe et populaire et qui possède des structures diffuses qu'il serait intéressant d'essayer de révéler (voir ici par exemple: https://apod.nasa.gov/apod/image/2012/Neyerm63_l2.jpg ) mais c'est juste une idée. Contraintes à respecter pour les images partagées: Pour des questions de cadrage, la cible devra forcément être au centre de l'image Tous les instruments sont possibles (même si les aigrettes des Newton risque de poser quelques problèmes...) Pour des raisons de cohérence et de cadrage, il faut se mettre d'accord sur un échantillonnage maximum et un champ minimum. Je pense par exemple à 1,5 "/pix maximum (ça correspond à une focale de 500mm avec un capteur avec des pixels de de 3.75um) et à un champ de 0.5°x0.5° minimum (même si la cible tient largement dans ce champ, un champ trop petit risque de créer des problèmes de cadrage insoluble) Les images devront être partagées au format fit (32bits) pour que chacun puisse les exploiter Les images couleurs ainsi que les images mono sont possibles Les images partagées doivent être directement issues de l'empilement, aucun traitement ne doit être fait. Une fois les images postées sur ce sujet, chacun sera bien sûr libre de tenter ses propres méthodes pour les combiner mais en gros l'idée est la suivante: 1) Choisir le cadrage optimum en fonction des différentes images partagées 2) Aligner toutes les images sur le cadre choisi 3) Empiler les images entre elles tout en les pondérant au mieux pour optimiser le résultat final 4) Faire le traitement et partager le résultat Qu'en dites vous? N’hésitez pas à me donner vos idées sur la cible et sur la méthode et surtout si l'idée elle même vous semble envisageable. Je pense que ça ne peut être intéressant que si il y a au moins une demi douzaine d'images à combiner. Nico

Du coup ça explique bien le résultat obtenu par @HLe mais ça veut dire qu'il devient délicat d'employer l'option Global Star Alignment avec ce genre d'images (avec un premier plan). En tous cas, ne faudrait il pas du coup supprimer l'option "Aligner les étoiles dans la sélection"?

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.