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

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.

Pour ceux que ça intéresse : ( https://www.cloudynights.com/topic/926962-using-the-imx585-mc-as-a-guide-camera-is-this-a-good-or-bad-idea/?p=13531827) Les courbes retraitées :

Bonjour dans le cadre d'une réflexion sur l'évolution de ma configuration, j'ai voulu regarder la différence de sensibilité entre les capteurs couleurs et mono de la famille IMX 571/533. A priori on a les mêmes photosites entre ces 2 senseurs, la seule différence entre les versions mono et couleur venant du rajout de filtres couleurs sur les photosites, ce qui entraine une perte de sensibilité d'environ 10% entre les deux versions. On trouve sur les différents sites des fabricants des courbes de sensibilité couleurs et mono qui sont cohérentes entre elles, sauf pour les caméras Zeus et Poseidon de Player One en version Mono qui présente une autre courbe de sensibilité. En concaténant les différentes courbes (j'ai repris les courbes du module spectrophotométrie de SIRIL) j'ai constaté, ce que j'interprète comme une incohérence, des différences notables entre les courbes de sensibilité mono et couleur : Mono : pic à 450 nm dans le bleu - Couleurs : pic à 540 nm dans le vert. La courbe mono a moins de sensibilité que la version couleur au delà de 600 nm, ce qui est physiquement impossible sauf à avoir des différences technologiques dans les photosites entre les 2 capteurs, or c'est la même technologie STARVIS. En Ha, la caméra couleur aurait une meilleure sensibilité que la caméra N/B !!! Par contre sur le site de Player One, si la courbes IMX 533 est la même qu'ailleurs (https://player-one-astronomy.com/product/ares-m-pro-usb3-0-mono-camera-imx533/), la courbe de l'IMX 571 est différente (https://player-one-astronomy.com/product/poseidon-m-pro-imx571-usb3-0-mono-cooled-camera/) et me semble-t-il cohérente des courbes couleurs avec un pic à 540 nm et une sensibilité dans l'IR comme attendu, au-delà des 800 nm ces filtres devenant quasiment transparents, donc on doit avoir la même sensibilité entre couleur et mono (cf. courbe de l'IMX 585C). Est-ce vous partagez mes interrogations quant à la crédibilité de la courbe de sensibilité IMX mono communément annoncée pour la famille des capteur IMX571/455/533? La courbe PO ne serait-elle pas la bonne en fait? Quelqu'un aurait eu l'occasion de mesurer la sensibilité des capteurs IMX mono qui confirmerait la courbe fournie par PO pour le capteur IMX 571/533?

Bonjour est-ce normal que lorsqu'on demande la statistique sur une image CFA (SIRIL 1.2.3), on n'obtienne, que la case à cocher "par canal CFA" soit cochée ou non, la seule statique globale? J'ai la vague impression que dans des versions antérieures (<1.2.2) on obtenait bien la statistique sur les 3 canaux, ce qui serait cohérent avec la signification de cette option. Cdt.