jDef

Bonjour l'Appli marche bien. Un point cependant, la carte me semble apparaitre à l'envers, l'est est à droite et l'ouest à gauche, ça ne devrait pas être l'inverse quand on regarde vers le sud, comme la carte du ciel standard? Ce serait inintéressant de pouvoir exporter l'horizon pour une utilisation dans NINA par exemple.

Merci. Effectivement, je ne guide pas et c'est une caméra non refroidie. Elle est "rafraichie" pour rester à Tambiante -3°C avec un refroidisseur de téléphone. Je fais juste dans ma séquence NINA un recadrage toutes les 300 images (#la période de la monture) pour faire du diphtering et éviter le "walking noise". Je vais me coucher et je récupère les données le lendemain matin... Honnêtement, il n'y a vraiment aucune galère pour le prétraitement, ça prend un peu plus de temps évidemment, là il n'y avait pas beaucoup d'images (en général c'est #8000 images), mais j'ai mon script siril multisessions qui me sort automatiquement mes 4 images LRVB et les statistiques. Je galère plus sur le post traitement :).

Bonjour merci pour vos retours. @Tromat il y a trois différences entre les 2 images : - le temps de pose, je suis à 2,5h, là ou celle d'astobin est à 5h, - la résolution, il est resté en natif, alors que j'ai rééchantillonné avec le drizzle à 0.68"/pix pour gagner en S/B et rester cohérent d'un seeing moyen à 2/3", - ma maitrise du traitement d'image.... L'intérêt des poses courtes, pour mon cas spécifique, c'est de ne plus avoir à me soucier du guidage, des satellites, ... la configuration est plus légère que pour une pose longue. Je laisse tourner toute la nuit sans intervention. Pour la turbulence, au dessus de 2 ms de toute façon on moyenne, donc les 2 s est un compromis en termes, de nombre d'images, de niveau de signal unitaire et de qualité de rondeur des étoiles (qualité de suivi de la monture). Au final, je rejette 10% des images sur la luminance. Il n'y a effectivement jamais de saturation en 2s, sauf cas rare sur des étoiles un peu trop brillantes, comme celle en haut à gauche dans l'image. La pose courte n'est pas la panacée, en particulier pour du faible Bortle ou sur de très faible objet. A Bortle 3, pour avoir le même S/N final qu'en poses longues sur des signaux en limite de détectabilité, il faut poser 2 fois plus longtemps en poses courtes, du fait de l'accumulation du bruit de lecture. Dès qu'on a un peu de signal (>2e-/s) c'est quasiment équivalent en terme de S/B final entre les 2 approches. Suite à discussions sur le forum d'en face, j'ai repris le traitement pour désaturer la nébuleuse et surtout les étoiles et c'est principalement sur ce dernier point que j'ai des difficultés du fait de la grande dynamique à gérer pour faire ressortir les étoiles faibles sans saturer les fortes. J'ai rajouté un coup de déconvolution Graxpert à la fin. C'est pas parfait, il n'y a pas de saturation du cœur de la nébuleuse, mais peut-être encore trop poussé par rapport au reste avec cette couleur blanche. Quand à la différence de couleur avec l'image d'astrobin, je ne sais pas où est la vérité.

Bonjour Ci-joint M20 prise l'été dernier au C9.25 EHD F/D 6.7 (réducteur de focale Astrophysics CCD67), avec une caméra PlayerOne Saturn-M (IMX 533) non refroidie en LRGB. Acquisition en 14b, Gain de 135, un peu au-dessus du gain unitaire pour maximiser le S/B unitaire et surtout éviter le bruit de trame ("walking noise") : L : 2641 x 2s (#1,5 h) R : 588 x 2s (#20 mn) V : 596 x 2s B : 599 x 2s Résolution native de 0,49"/pix rééchantillonnée à 0,68" lors du traitement drizzle dans Siril. L'acquisition se fait sous NINA sans guidage, mais avec un recentrage toutes les 300 images pour assurer un dithering correct. Utilisation de Siril et SetiAstrosuitePro. La luminance mériterait d'être complétée pour booster la partie en bleu (oxygène). La statistique des acquisitions avant tri pour intégration (rondeur > 0.75 et 90% des FWHM) et rééchantillonnage.

Merci. En fait cela dépend de la caméra. Pour avoir fait des essais avec les 2 types de caméras, avec une caméra couleur on est bien adapté aux amas globulaires et nébuleuses planétaires brillantes, pour les galaxies ou nébuleuses on sent qu'on manque de signal, sauf à poser beaucoup plus longtemps, par contre en LRGB on peut tout imager. Les seules contraintes sont, qu'à iso S/B cible, il faut poser 15% de plus qu'en pose longue (pour une pose de 2s) à cause de l'addition du bruit de lecture, ça remplit le DD et le pré-traitement prend plus de temps. Mais a contrario : le drizzle marche beaucoup mieux, en particulier pour les caméras couleurs, on ne sature quasiment jamais les étoiles, on a un peu de marge pour trier les images sur la FWHM/rondeur pour ne garder que les meilleures, on peut utiliser une caméra non refroidie, même si dans mon cas j'utilise une refroidisseur de smartphone sur la face arrière pour maintenir la caméra à un peu moins que la température ambiante, le montage et les contraintes d'utilisation sont simplifiés car on n'a plus besoin de faire de guidage, un simple recentrage de temps à autre suffit à générer le dithering. Donc globalement, je trouve que les avantages l'emportent.

Bonjour Ci-joint NGC6888 prise l'été dernier au C9.25 HD F/D 6.7 (réducteur de focale Astrophysics CCD67), avec une caméra PlayerOne Saturn-M (IMX 533) non refroidie en LRGB : L : 5316 x 2s (#3 h) R : 600 x 2s (#20 mn) V : 596 x 2s B : 585 x 2s La statistique des acquisitions avant tri (rondeur > 0.75 et 90% des FWHM - 6000 L et 600 R/V/B) : Résolution native de 0,49"/pix rééchantillonnée à 0,68" lors du traitement drizzle dans Siril. L'acquisition se fait sous NINA sans guidage, mais avec un recentrage toutes les 300 images pour assurer un dithering correct. Utilisation de Siril et Seti Astro Pro suit.

Soustraire le biais du dark n'est, à mon avis, utile que dans 2 cas, sinon il faut travailler directement avec un masterdark : les caméras non refroidies, il faut faire alors forcer l'optimisation du dark en "autoévaluation". le lucky imaging en CP (pose<4s). En effet, dans ce cas les structures observées sur le biais vont devenir prépondérantes et générer du bruit télégraphique et là c'est foutu. Personnellement, je fais un masterbiais avec 500/1000 images, donc il n'y a plus de bruit, juste les structures. En ce qui concerne les flats, je mets, comme beaucoup d'autres l'ont recommandé, l'offset à 0, donc plus de Pb de biais à soustraire. Ca évite les image non uniforme après prétraitement du fait d'un mauvais niveau de biais. D'autant que pour certaines caméras, même récente, le biais peut être variable en fonction de la température, d'où qq complication si non refroidies.

Il faut charger les 4 images linéaires L, R, V, B dans l'utilitaire de composition. Cliquer sur "aligner" en choisissant "ciel profond" et "premier canal" (luminance comme référence comme ça elle n'est pas modifiée elle porte les détails), puis "tout sauvegarder", il y aura création de 4 fichiers comp_xxx correspondant aux images alignées. Donc normalement au moment de la recombinaison après étirement, les images resteront alignées. Après il faut traiter séparément l'image couleur RVB (après combinaison RVB dans l'outil en linéaire) et l'image L et recombiner tout ça après étirement avec la commande rappelée par @nico1038. Les images resteront alignées sur la luminance. La recombinaison peut se faire aussi avec GIMP ou Affinity qui est maintenant gratuit pour faire L + RVB avec les scripts astro disponibles pour ces 2 logiciels.

Dans tous les cas, le cercle utile final correspondra au cercle image disponible au F/D natif multiplié par le coefficient de réduction du réducteur. Extrait de la notice du réducteur de AP : The CCDT67 has a clear aperture of 44 mm or 1.75”. At 0.67X compression, it will fully illuminate a 29 mm circle - 44 mm x 0.67 = 29 mm.

Bonjour Je reviens avec mon image pour une nouvelle question concernant la détection des étoiles. En MOFFAT, les 2 étoiles au milieu ne sont pas détectées alors qu'elles ont largement le niveau pour. Si on augmente le diamètre du rayon de détection à 10, une des étoiles est détectée, en contrepartie de la perte de détection sur d'autres étoiles plus petites. Les autres paramètres n'ont pas d'effet sur la détection sauf le modèle Gaussien, où les 2 étoiles sont détectées avec les paramètres par défauts. Une idée? Cdt. RGB_recad.fits

Bonjour J'aurai une question sur l'image en PJ. C'est une image linéaire : Pourquoi l'étoile sélectionnée est classée saturée alors que le signal ne l'est manifestement pas. On le voit clairement sur la coupe de niveaux. Autre point, si la détection se fait sur le modèle MOFFAT, la saturation est déclarée sur les 3 plans couleurs, par contre avec le modèle gaussien, le plan vert n'est plus saturée. Une idée? Cdt RGB_recad.fits

Bonjour, ce qui compte c'est d'optimiser le couple résolution spatiale résultante - S/B au regard de la FWHM moyenne observée. Je fais des poses courtes (2s) et j'ai généralement une FWHM moyenne sur les images individuelles < 2", je ne pense pas trop m'avancer en disant qu'on aura du mal à faire mieux en amateur a fortiori avec des poses longues. Il faut donc rechercher un échantillonnage dans un rapport 3 par rapport à ces 2" moyen, soit 0,66"/pix, au-delà on va perdre en sensibilité pour aucun gain de résolution. En CP, en générale la résolution n'étant pas contrainte par le matériel mais par la turbulence. Donc avec un pixel à 1,45µm, le calcul est rapide : - 206.265*1.45/250/2 = 0.60 Ok - 206.265*1.45/250/4 = 0.3 NOk - 206.265*1.45/350/2 = 0.43 ~Ok - 206.265*1.45/350/2 = 0.21 NOk On peut toujours rééchantillonner l'image lors de l'intégration drizzle avec Siril, ce qui n'est pas possible à ma connaissance avec les autres logiciels, pour atteindre la résolution optimale voulue, mais plus on est proche en natif de la bonne résolution, meilleur sera le S/B, à temps de pose égale. Des configurations avec un pixel à 2.9 pour un 250 mm et 3.76 pour le 350 seraient plus adaptées me semble-t-il. Par contre le champ va être très petit du fait de la taille du capteur à comparer à un 533 ou 585. En ciel profond, un 715 pourra aller pour des nébuleuses planétaires, pour le reste ... ou pour les très grand champ ou faible diamètre pour gagner en résolution.

Bonjour la PJ est vide.

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