jDef

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

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.

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

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.

Bonjour Lorsqu'on a une séquence ouverte et qu'on veut faire une résolution astrométrique sur une des images, la case "résoudre la séquence entière" est cochée par défaut. Si on valide un peu trop rapidement on est parti pour un certain temps, voire un temps certain. Si on arrête le processus, SIRIL hang et on ne sait pas trop combien de temps ça va durer et un arrêt brutal vérole le fichier de séquence. Pour éviter de se retrouver dans cette situation, sachant que la résolution astrométrique d'une séquence est une opération lourde et a priori lancée volontairement, ne pourrait-on pas modifier le paramétrage par défaut de cette fenêtre en ne cochant pas la case "résoudre la séquence entière"? Par défaut on ne résoudrait que l'image affichée et si on veut faire toute la séquence on aurait une action volontaire réfléchie. cdt

Effectivement, c'était le passage au F/D 8 au lieu de 7 qui jouait sur le champ résultant.

Bonjour Pour un échantillonnage spatial optimale, c'est le QE qui devient important. Le problème est d'arrivé à l'échantillonnage optimale en fonction des contraintes de sa configuration et de son site. J'avais un C8 à F/D 6.3, l'IMX 585 et IMX533-C ont un bon échantillonnage respectivement 0.5 et 0.68, donc en lucky imaging avec des FHWM finale de 1,5 à 2", la IMX585 (que j'ai) est un bon choix pour privilégier la résolution, la 533-C aura une meilleure détectivité. Et plus la focale diminue mieux ce sera pour la 585 par rapport à la 533, la 533 sortant de l'échantillonnage optimale. Maintenant j'ai un C9.25 avec F/D sur 7, une IMX533 avec ses 3.76 µm (0,47") sera effectivement plus efficace que l'IMX585 avec ses 2.9 µm, cette dernière sur-échantillonnant un peu trop (0,36"). Il faudrait réduire la réduction à F/D8 et sommer les pixels par 4 pour diviser la résolution par 2 (0,64"), pour un gain de 2 en S/B et là on compense largement l'effet de taille du pixel, mais au détriment du champ en passant à F/D 8. L'idée de départ était de me poser la question de l'intérêt de passer en mono 533, que j'ai déjà par ailleurs en non refroidie, en rajoutant une roue à filtre et une certaine complexité de mise en œuvre et de traitement ou acheter une 533-C en cumulant certes plus d'images, pour compenser le 1pixel/4 comme je le fais avec ma 585-C. La différence de performances dans le bleu entre la version couleur et la version mono (-20%) et le besoin d'un champ un peu plus important me fait pencher pour sauter le pas de la version mono qui serait optimale pour ma configuration. Pour le fun, j'ai ramené les perfos de l'IMX585 en prenant en compte l'effet de la taille du pixel (IMX585*~0.6 - ce n'est plus un QE mais ça donne une idée des performances globale à iso échantillonnage optimale):

Bonjour Sony ne fourni plus au public ses datasheets, juste des flyers avec des informations réduites, donc on est réduit à utiliser les données des fabricants de caméra. le fait qu'il y ait 1 pixel sur 4 se contourne avec le bayer drizzle pour la résolution, en particulier avec du lucky imaging, et un peu plus de temps de pause total, mais il est vrai qu'on aura du mal à atteindre les performances d'une mono. Mon objectif étant d'estimer le meilleur compromis temps/complexité de mise en œuvre entre une 585C et une 533M ou une 533C. J'ai les 2 premières caméras et je regarde si ça vaudrait le cout de passer en imagerie mono, sachant que la taille du pixel de la 533 apporte un gain de perfo indéniable dans ma configuration 1650mm de focale ou rester en couleur. La première étape c'est déjà de comprendre à quoi correspondent les performances vendues. J'ai complété avec l'IMX585C, dommage que la version mono ne soit pas intégrée.