jDef

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