jDef

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.

J'ai refais le traitement avec 101 darks, SB ôtés, cette fois-ci j'obtiens systématiquement un coefficient d’optimisation de 0.002. L'image initiale a ce type de statistique (30C) sur une zone restreinte sans étoiles : et pour l'ensemble de l'image du courant obscurité : ce coefficient de 0.002 annule quasiment tout l'effet de prise en compte de correction de dark (?). Cdt Jacques

En reregardant les explications sur la méthode données par C. Buil dans son livre, je comprends qu'on aurait la somme de 3 types de signaux sur un pixel : - une valeur moyenne du courant d'obscurité dépendant de la température, - des variations spatiales de cette valeur moyenne propre au capteur (que je n'avais pas pris en compte), - des variations temporelles d'écart type égal à la racine du courant d'obscurité. En moyennant des noirs, dont l'offset a été ôté, on garderait les 2 premiers termes propre au capteur sans bruit temporel et donc c'est cette carte qui sert dans la méthode d'optimisation (?). En ne retirant que la valeur moyenne du courant d'obscurité je ne traiterais pas les variations spatiales qui ne peuvent in fine être soustraites par moyennage car fixe et propres au capteur. Toute la difficulté consiste à réaliser suffisamment de noirs avec une caméra non régulée à une température à peu près constante pour supprimer le bruit temporel par médiane ou moyenne pour ne pas rajouter du bruit dans l'image, surtout en pose courte, il y en a assez comme ça.... Le raisonnement est bon?

Bonjour J'ai une séquence d'images de 2s prises avec une caméra non refroidie à la température de 30C au gain 300 offset 30. A cette température, le capteur est supposé générer un signal thermique de 0.52e/pix/s. Au gain de 300, on a un coefficient de 0.3e/ADU. Donc le signal de courant d'obscurité théorique devrait être de 3,5 ADU. J'ai généré : - un superbiais (SB) à partir de 4000 images, donc ne reste que les défauts inhérents au capteur et plus aucun bruit. - une image du courant d’obscurité (CO) en remplissant une image avec un niveau fixe de x ADU. - un MasterFlat (MF). Statistique image de départ : statistique superbiais : Lors du prétraitement, je coche la case optimisation du noir, donc sauf erreur de ma part, SIRIL réalise l'opération : (brut - SB- k*CO)/MF, le coefficient k étant optimisé en fonction du bruit dans chaque image. En faisant varier le niveau de départ du courant d'obscurité, toutes choses étant égales par ailleurs, on obtient des coefficient k assez différents et des évaluations variables du niveau de courant d'obscurité, que je n'arrive pas à m'expliquer, à moins que je paramètre mal la fonction : x = 1 ADU --> k = 1 --> CO = 1 ADU x = 2 ADU --> k = 1 --> CO = 1 ADU x = 3 ADU --> k = 1,729 --> CO = 5,2 ADU x = 3,46 ADU --> k = 0.95 --> CO = 3,3 ADU x = 4 ADU --> k = 1,712 --> CO = 6,9 ADU x = 4,5 ADU --> k = 1,237 --> CO = 5,6 ADU x = 5 ADU --> k = 0,766 --> CO = 3,8 ADU x = 5,5 ADU --> k = 1,281 --> CO = 6,4 ADU x = 6 ADU --> k = 0,833 --> CO = 5 ADU x >6 ADU --> k = 1 Cdt Jacques

Bonjour En complément on peut remarquer (en tout cas sur ma PO Uranus-C IMX 585) que la médiane de l'offset dépend à la fois du temps de pose et du gain. Autour du gain unitaire on retrouve bien un ratio de 64 pour une acquisition du 1 ms, par contre si j'augmente le gain, ce n'est plus exactement le même ratio. Nota : J'ai obtenu des variations bizarres des statistiques affichées par Sharpcap en diminuant trop le temps d'acquisition, ce qui ne semble plus être le cas avec les nouveaux drivers. L'influence du gain est assez patente sur la forme de l'offset si on regarde les histogrammes (fait sur une image), la bascule HCG se fait ici au gain 210 et offset de 150, 12b, soit théoriquement une valeur de 9600 ADU. on en est pas très loin, sauf lorsque que le gain augmente : Donc l'évaluation 64xOffset reste théorique, par contre c'est toujours un multiple de 16 mais sur une base variable... Il faut donc caractériser la valeur en fonction du gain. J'ai fait la statistique sur 100 images à G300 O150 et j’obtiens toujours la même valeur de médiane à 9584 ADU. Sans ouvrir un sujet qui mériterait une discussion spécifique, ce n'est peut-être pas l'offset qui devrait être synthétique, mais le courant d'obscurité qu'il faut optimiser avec un vrai "superbiais" portant les différents défauts du capteur. Cordialement Jacques

Oui aux 2 questions. J'ai mélangé les deux appels de la fonction register. Finalement la différence entre -2pass et -noout si je comprends bien c’est que: 2pass : on fait l’alignement en recherchant la meilleur image dans la séquence et on ne crée pas le fichier r_xxxx. noout : on fait l'alignement en prenant la 1ère image de la séquence comme référence et on ne crée pas le fichier r_xxxx Cdt

Merci Cécile pour les explications. Concernant les spécificateurs -2pass et -noout, ce n'est pas ce j'avais compris de la doc où je comprenais qu'il fallait les 2 attributs qui sont cités en même temps: "The -2pass and -noout options will only compute the transforms but not generate the transformed images, -2pass adds a preliminary pass to the algorithm to find a good reference image before computing the transforms, based on image quality and framing." dans ce cas il faudrait peut-être qu'il y ait 2 phrases une pour -2pass et l'autre pour- noout pour préciser ou mettre "ou" au lieu de "et", mais c'est peut-être moi qui interprète mal la phrase. J'ai corrigé le script. Du coup je comprends que l'attribut -2pass n'a pas été appliqué vu le message dans le log : 11:36:17: Exécution de la commande : register 11:36:17: L'option -nostarlist n'a d'effet que lorsque l'option -2pass est utilisée, ignoré 11:36:17: Alignement : traitement en cours utilisant la méthode : Alignement global (ciel profond) alors que la même commande appliquée à la séquence Green_xxx ne donne le même message et action : 13:25:20: Exécution de la commande : register 13:25:20: Vérification des séquences dans le répertoire : E:\Siril\process. 13:25:23: Alignement : traitement en cours utilisant la méthode : Alignement global des étoiles en deux passes (ciel profond) 13:25:23: FindStar : avec la mémoire actuelle et les limites de threads, jusqu'à 16 thread (s) peuvent être utilisés 13:25:23: FindStar : en cours... 13:25:23: Findstar : en cours pour le canal 0... je ne comprends pas trop pourquoi, on a dans les 2 cas 2 séquences fit, mais ce n'est pas très important. On avait échangé il y a quelques temps pour savoir comment garantir le même nombre d'images à traiter entre différentes séquences, finalement, je crois avoir trouver la solution. Je fais un alignement 2pass sur l'extraction du plan vert. Je renomme le fichier Green_xxx.seq en CFA_Y_xxx.seq en changeant le nom du fichier à l'intérieur et je fais applyseq et a priori j'applique au 4 plans CFA l'alignement du plan vert. Cordialement Jacques

pas réussi à reproduire, probablement une mauvaise manip lors du copier/coller pour fusionner les 2 fichiers.

Bon finalement en copiant le catalogue des variables, avec l'entête, à la fin du catalogue PGC, sans laisser de ligne vide à la fin du fichier *.txt, ça se charge normalement, les 2 catalogues sont fusionnés et accessibles depuis SIRIL.