Aperçu

Merci tout le monde et les autres aussi ! 😄

Alors les scripts ne vont pas marcher pour des images lunaires. Les scripts sont pour le ciel profond, qui est la spécialité de Siril. En manuel tu peux toujours réussir a faire des trucs par contre.

je viens de télécharger le scritp disponible ici : https://gitlab.com/free-astro/siril-scripts/-/blob/main/preprocessing/OSC_Preprocessing_WithoutDark.ssf?ref_type=heads C'est aller plus loin, mais 2 questions : 1- j'ai souvent le message : Le motif de Bayer trouvé dans l'entête (BGGR) est différent du motif de Bayer enregistré dans les préférences (RGGB). Celles-ci sont remplacées. => Que signifie t il ? 2 - il est en echec comme tu le disais. Comment font ceux qui on réussi à "Siriliser" la lune ? 14:19:12: Le motif de Bayer trouvé dans l'entête (BGGR) est différent du motif de Bayer enregistré dans les préférences (RGGB). Celles-ci sont remplacées. 14:19:12: Le motif de Bayer trouvé dans l'entête (BGGR) est différent du motif de Bayer enregistré dans les préférences (RGGB). Celles-ci sont remplacées. 14:19:12: Motif du Filtre : BGGR 14:19:12: Motif du Filtre : BGGR 14:19:12: Fichier FITS enregistré : fichier pp_light_00229.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:13: Fichier FITS enregistré : fichier pp_light_00029.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:13: Fichier FITS enregistré : fichier pp_light_00226.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:13: Fichier FITS enregistré : fichier pp_light_00228.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:13: Fichier FITS enregistré : fichier pp_light_00227.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:13: Fichier FITS enregistré : fichier pp_light_00225.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:14: Fichier FITS enregistré : fichier pp_light_00230.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:14: Fichier FITS enregistré : fichier pp_light_00231.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:14: Le traitement de la séquence a réussi. 14:19:14: Temps d'exécution: 2 min 43 s 14:19:14: #align lights 14:19:14: Exécution de la commande : register 14:19:14: Vérification des séquences dans le répertoire : C:\Users\tiya_\Pictures\SIRIL\process. 14:19:15: Alignement : traitement en cours utilisant la méthode : Alignement global (ciel profond) 14:19:15: Contrainte de l'interpolation active 14:19:15: Alignement global sur les étoiles : avec la mémoire actuelle et les limites de threads, jusqu'à 8 thread (s) peuvent être utilisés 14:19:15: Lecture FITS : fichier pp_light_00001.fit, 3 canal(aux), 4950x3284 pixels, 32bits 14:19:15: Image de Référence : 14:19:15: Findstar : en cours pour le canal 1... 14:19:18: 0 étoiles trouvées dans l'image référence, canal #1 14:19:18: Il n'y a pas assez d'étoiles dans l'image de référence pour procéder à un alignement 14:19:18: Échec du traitement de la séquence. 14:19:18: Alignement interrompu. 14:19:18: Échec de la finalisation du traitement de la séquence. 14:19:18: Définir le répertoire de travail à 'C:\Users\tiya_\Pictures\SIRIL' 14:19:18: L'exécution du script a échoué.

Merci pour ton retour et tes liens Je vais essayer et reviendrai ici Je sais en effet que Siril n'est pas pour le planétaire, mais certains semble y arriver. Comme je souhaite aussi faire du ciel profond, et que je n'aime pas avoir plusieurs logiciel, je tente ma chance avec Siril. A quel endroit de la consol vois-tu que c'est au niveau des dark qu'il est en echec ? (j'aurais dis les biases) peut-être fait tu mention de l'ensemble des dossier DOF ?

Bonjour, Il ne trouve pas de fichier dark. Il faut supprimer cette partie dans le script pour passer cette étape. https://siril.readthedocs.io/fr/stable/Scripts.html#scripts Siril n'est pas faits pour du planétaire mais pour des objets du ciel profond. Il lui faut notamment des étoiles pour pouvoir aligner les poses. La doc à jour : https://siril.readthedocs.io/fr/stable/Installation.html Un logiciel parmi d'autres qui est plus pour le planétaire : https://www.autostakkert.com/wp/download/

Bonjour à tous, Je me permets de vous demander votre aide pour l'utilisation de Siril. Je photographie le ciel nocturne depuis longtemps, mais je ne fais que via mon DSLR (pentax K5) et en fonction un 55/70 2.8 ou 70/200 2.8, puis retouche sous Ligtroom. Mais je souhaite avancer un peu et faire du stackage/ampilement. J'ai donc, pris la lune en photo. (50 photo environs) installer Siril 1.2.4 Créée l'arborescence conformément au tuto Commencer le tuto pas à pas, mais je me retrouve très rapidement avec des erreurs : - Déjà je n'ai pas tous les scripts, indiqué dans le tuto ; - Je lance tout de meme OSC_Preprocessing et echec de l'execution du script 11:42:00: Début du script C:\Program Files\Siril\scripts\OSC_Preprocessing.ssf 11:42:00: ############################################ 11:42:00: # 11:42:00: # Script for Siril 1.2 11:42:00: # February 2023 11:42:00: # (C) Cyril Richard 11:42:00: # Preprocessing v1.3 11:42:00: # 11:42:00: ########### PREPROCESSING SCRIPT ########### 11:42:00: # 11:42:00: # Script for color camera preprocessing 11:42:00: # 11:42:00: # Needs 4 sets of RAW images in the working 11:42:00: # directory, within 4 directories: 11:42:00: # biases/ 11:42:00: # flats/ 11:42:00: # darks/ 11:42:00: # lights/ 11:42:00: # Saves masters to ./masters/ 11:42:00: # 11:42:00: ############################################ 11:42:00: Exécution de la commande : requires 11:42:00: # Convert Bias Frames to .fit files 11:42:00: Exécution de la commande : cd 11:42:00: 'biases' Aucun fichier ou dossier de ce type 11:42:00: Erreur à la ligne 25 ('cd') : erreur générique. 11:42:00: Sortie du traitement par lot. 11:42:00: Définir le répertoire de travail à 'C:\Users\tiya_\Pictures\SIRIL' 11:42:00: L'exécution du script a échoué. Merci pour votre aide.

Bonjour La fonction Unsharp est effectivement un peu dépassée, par contre pour la fonction gauss, il me semble qu'elle peut avoir un intérêt pour 3 aspects : - lorsqu'on crée un masque synthétique pour flouter les transitions; - réduire le bruit (effet assez intéressant en linéaire); - lors d'un binning, comme le préconise C. Buil (c'est pour la spectro, mais applicable au reste), de faire un filtre médian, suivi d'un filtrage gaussien avant d'appliquer le binning. Cordialement Jacques

Bonjour. En fait, les fonctions gauss et unsharp sont de vieilles fonctions, très peu utilisées. Nous pourrions même les supprimer vu le peu d'utilité qu'elles ont. Ceci explique pourquoi on n'écrit pas la partie graphique correspondante. Pareil pour l'entropie, son utilité est assez faible. À l'origine, j'avais eu l'idée de m'en servir pour évaluer la qualité des images, mais ce n'est pas terrible.

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

Bonjour Dans la version 1.3.4 la compensation de la distorsion des images a été introduite lors de la phase d'alignement. Je présume qu'il est préférable de créer le fichier de distorsion sur la meilleur image de la séquence pour avoir quelque chose de propre. Or tel que se présente l'interface, il faut choisir avant de lancer l'alignement l'image qui fournira le fichier de distorsion, donc j'en déduirais, dans le cas d'un alignement 2 passes, il faut faire une première passe sans distorsion pour déterminer l'image de référence, faire son astrométrie, relancer l'alignement 2 passes avec distorsion pour la prendre en compte, puis appliquer l'alignement disponible. C'est bien ça? Cordialement.

Merci Cécile, c'est plus clair. J'ai regardé sur le fond de ciel, ça semble bon pour le %. L'écart est probablement limité à la rondeur et concerne a priori les faibles valeurs de réjection (<10%). Jacques

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...

Bonjour En PJ un fichier de séquence d'une acquisition de 4000 images. Elle a été chargée dans SIRIL et j'ai extrait la FWHM et la rondeur de l'onglet graphique. Si on applique les filtres de sélection à l'empilement, on constate la situation suivante concernant les seuils affichés : FWHM : % : le nombre d'images et le seuil affiché sont conformes à la statistique (cf. exemple pour 90%). k-s : Le seuil ne correspond pas à la statistique" >(médiane + k*sigma)". Pour k=0, on devrait avoir la médiane et ce n'est pas le cas. Rondeur : % : le nombre d'images est conforme à la statistique, le seuil affiché ne correspond pas (cf. exemple pour 90%). k-s : Le seuil ne correspond pas à la statistique "<(médiane - k*sigma)". Pour k=0, on devrait avoir la médiane et ce n'est pas le cas. Je n'ai pas regardé les autres critères de sélection pour vérifier s'il y avait la même situation avec la statistique. Donc soit j'ai une incompréhension sur le mode de calcul du seuil de filtrage en k-s, soit il y a un problème sur le calcul/affichage de ces seuils, au moins pour les rondeurs, et donc éventuellement sur les images sélectionnées dans la séquence. Par ailleurs, lorsqu'on passe de % à k-s, le seuil affiché n'est pas mis à jour correctement, il faut clicker sur +/- pour obtenir le bon seuil. Cordialement. M27 FWHM.xlsx pp_light_.seq

D'où l'utilité de ne pas mettre la case à cocher "cochée" par défaut lorsque la séquence est un fitseq, ce qui est inévitable lorsqu'on dépasse les 2048 images, voire de ne pas autoriser la résolution d'une séquence pour ce format si aucune solution de contournement n'est possible. Un arrêt brutale de SIRIL détruit le fichier seqfit xxx.fits.

Sur une séquence de type FITSEQ c'est un peu compliqué en fait. Techniquement, la réécriture du header est très différente et il se peut qu'au bout d'un moment l'écriture bloque. Non il ne se passe pas autre chose que le platesolving, à part l'écriture dans le header d'un fichier qui peut vite faire plusieurs Go.

J'ai refait un essai : Pour une séquence de 5000 images fits, cela prend 30 mn (AMD RYZEN 7 4800h). Pour une séquence ser a priori Ok. Pour une séquence de 5000/1000/500/200/100 (différents essais) images en seqFit, SIRIL bloque sur la première image et il faut forcer l'arrêt. Par contre pour une séquence de 50 c'était bon mais très très long par image. Avec 20 images c'est a priori nominal. Manifestement SIRIL ne fait pas qu'une résolution astrométrique lorsqu'il travaille sur une seqfit. Une autre tâche de fond est lancée qui consomme pas mal de ressources. La résolution d'une image extrait de cette séquence de 50 ou une résolution unitaire d'une image de la séquence (sans cocher "traiter la séquence") se passe sans difficultés. Cdt

La nuit portant conseil, j'ai trouvé une solution pour contourner ce problème. En supposant que l'image de départ a un nommage générique du type stack.fits et qu'un répertoire ../process existe, ça donne le script : #Fin du script de prétraitement avec empilement de la séquence r_pp_light stack r_pp_light_ -out=../stack # Chargement image stack load stack.fits #Changement répertoire de travail cd process #Extraction des images RGB dans le répertoire process split R G B # Convert 3 input images to a sequence convert colors # Sauvegarde de l'image stack dans process sous un nommage lisible save M1_2345Img_2s_80%.fits # suite du script rgb _composition dans le répertoire "process" ... L'autre solution aurait été de sauvegarder l'image issue de l'empilement avec un nom commençant par la lettre A, et comme SIRIL charge manifestement avec la fonction "convert" les images présentent dans un répertoire dans une séquence par ordre alphabétique inversé (Z--> A), d'où l’importance de bien garder les noms R G B pour le split pour retrouver les plans couleurs 0 1 2, de désélectionner la 4ème image de la séquence colors et d'appliquer le reste du scipt. Le seul souci qu'il reste c'est que l'image finale rgb_comb.fits a perdu dans son entête fits l'historique de l'image initiale stack.fits , alors que si l'on fait l'opération à partir du click droit dans l'IHM c'est transparent.

Bonjour, merci, j'avais bien cet enchainement en tête. Mon objectif aurait été d’enchainer cette opération à la suite d'autres opérations d'un script. Le seul problème c'est qu'à supposer qu'on ait sauvegardé l'image à traiter dans un répertoire seule en sortie d'empilement, la fonction split va créer les images RGB dans ce même répertoire il n'y pas a priori d'option "-out=", et comme le précise le script, et ce que j'ai vérifié, les images RGB doivent être seules dans le répertoire pour la séquence colors soit créée, sinon ça plante. Donc a priori à ce stade pas de solution. Cdt

Bonjour, c'est possible mais il faut plusieurs opérations, le script de combinaison rgb fait à peu près ça déjà, voir le tutoriel qui en parle (3e paragraphe ici : https://siril.org/fr/tutorials/rgb_composition/#1-alignement-des-images ) ou la documentation sur les scripts fournis ici, le dernier de la liste : https://siril.readthedocs.io/fr/stable/Scripts.html#built-in-scripts

C'est ce que j'ai tenté ce matin, lorsque j'ai constaté que le fait de cocher la case de recomposition ne change rien à l'affaire. Ah ! non, je viens de relire un peu mieux : ce n'est pas ainsi que j'ai procédé : j'ai légèrement étiré le starless et le starmask puis ai recomposé. Sauf qu'au moment d'équilibrer la bdb ça m'a craché qu'il ne trouve pas suffisamment d'étoiles. Je vais remettre ça en appliquant ta méthode.

Bonjour Lorsqu'on a une image ouverte dans Siril, avec le click droit on a accès au menu d'alignement des plans RVB, cette fonction est-elle accessible en script, la fonction register attendant une séquence? Cdt

Et pourquoi pas empiler tes starless d'un côté, empiler tes starmasks de l'autre... Puis comme d'hab (pour moi): faire le stretching et le traitement du starless, puis recomposition, et au moment où tu as la fenêtre de recomposition, stretching du starmask. Perso, pour réduire les artefacts en utilisant la méthode classique, je fais un premier stretch (léger) sur l'empilement puis j'utilise starnet... Si tu n'as jamais essayé...

Je sais pertinemment que ça va planter lors de la sauvegarde, car ça ma le fait toujours lorsque je coche la case de reconstruction, cf. ce fil, mais je viens tout de même de repartir pour douze heures de traitement des étoiles. Histoire de voir comment ça se présente à la fin, et si cela fait une quelconque différence.

Bonjour Certaines fonctions sont uniquement accessibles depuis la console et pourraient être utilement dupliquées au niveau des menus car en tant que tel ils sont difficilement utilisables. Prenons l'exemple de la fonction Gauss, elle n'est accessible qu'à partir de la console "gauss sigma", or une fois appliquée on ne peut revenir en arrière, la fonction undo n'étant pas activée. Donc la recherche du bon paramètre est fastidieuse puisqu’il faut recharger l'image à chaque essai. Je proposerais que les fonctions console : - qui modifie une image, activent la fonction undo pour pouvoir revenir en arrière ; - gauss, sharpen soient rajoutées au menu filtrage avec une interface classique de paramétrage ; - éventuellement : rajouter dans la fenêtre GHS un bouton pour l'autoGHS (comme il y a l'autostretch dans la fenêtre histogramme) ; disto et entropy dans le menu analyse image. cdt

Pour une séquence de 30/50 images en imagerie classique je n'en doute pas, mais pour une séquence de 5000 images en lucky imaging, la rapidité de Siril ayant tout son intérêt dans cette situation, c'est plus tout à fait pareil ... Le besoin serait juste au niveau de la fenêtre de l'IHM. Surtout qu'on ne voit pas d'indicateur d'avancement du traitement, la roue tourne mais on ne sait pas si ça avance normalement ou si c'est en boucle. J'ai lancé la procédure à 11h54, j'ai arrêté à 12h08, aucune évolution. Il y a peut-être un problème avec cette fonctionnalité sur une séquence? Je peux déposer un sujet sur Gitlab si besoin.