jDef

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.

Bonjour J'ai un script qui fonctionne en 2 parties : 1- prétraitement et extraction du plan vert avec un alignement 2 passes pour déterminer l'image de référence obtenue via la fonction getref (ici 1827 cf green_pp_light.seq) et extraction des plans CFA : setfindstar -relax=on -focal=2265 -pixelsize=2.9 -sigma=0.7 seqextract_Green pp_light register Green_pp_light -2pass -noout -transf=shift -nostarlist -interp=la -minpairs=5 #register pp_light -2pass -noout -transf=shift -nostarlist -interp=la -minpairs=5 seqsplit_cfa pp_light getref Green_pp_light 2 - traitement de chaque plan CFA : cd process setfindstar -relax=on -focal=2265 -pixelsize=5.8 -sigma=0.7 #Couche Rouge cd CFA0 #convert CFA_0 -fitseq seqsubsky CFA_0 1 setref bkg_CFA_0 1828 #+1 par rapport à getref register bkg_CFA_0 -transf=shift -nostarlist -interp=la -minpairs=5 stack r_bkg_CFA_0 rej 3 4.5 -norm=addscale -output_norm -out=../CFA_0_NGC898_$STACKCNT:%d$Img_$EXPTIME:%d$s -weight_from_wfwhm -filter-round=0.7 cd .. Le point soulevé est qui si setref est bien pris en compte pour l'alignement, on retrouve l'image 1827 dans le fichier bkg_CFA_0.seq, cela ne semble pas être le cas pour la sommation où l'image de référence indiquée est 1823 (comment a été fait le choix?) et je ne vois pas de raison qu'on soit obligé de redéfinir l'image de référence avant la sommation pour respécifier celle choisie pour l'alignement: #Siril sequence file. Contains list of images, selection, registration data and statistics #S 'sequence_name' start_index nb_images nb_selected fixed_len reference_image version variable_size fz_flag S 'r_bkg_CFA_0' 0 2846 2846 0 1823 4 0 0 TF L 1 I 0 1 Merci d'avance pour votre éclairage. Cordialement jacques Green_pp_light.seq bkg_CFA_0.seq 2023-10-24T09.40.01.log r_bkg_CFA_0.seq

Ok merci, j'ai modifié le nom, le formatage était bon. Le fichier user-catalogueV.txt est le même (au nom près) que le fichier GCVS_siril_annotations.txt téléchargeable depuis la documentation. Une fois le nom chargé il est aussi utilisable. J'étais bien parti de cette suite de messages qui est aussi mise en lien depuis la documentation SIRIL, c'est de là que j'ai du récupérer ces fichiers, mais on y parle d'un nom de fichier user-catalogue.txt et pas user-DSO-catalogue.txt. Je vais regarder pour essayer de fusionner les 2 fichiers (PGC et V), mais pour l'instant ça plante siril ... Il faudrait peut-être compléter la documentation en précisant ce nommage car ça ne semble pas apparaitre qq part et mettre ce fichier PGC en lien de téléchargement je pense que cela peut intéresser les autres utilisateurs SIRIL. Cdt Jacques PGC_sirl_annotations.txt

Bonjour J'ai une image qui a été résolue (difficilement si on donne les coordonnées de l'objet et pas le centre de l'image, mais c'est un autre sujet) avec NGC 898 dedans. Il y a aussi 4/5 galaxies PGC dans le champ, or l'annotation ne les présente pas alors que le catalogue utilisateur est installé dans le bon répertoire (par SIRIL d'ailleurs) et j'ai vérifié que les galaxies sont bien référencées dans le catalogue. Donc je ne sais pas si c'est moi ou SIRIL? Merci d'avance. Siril V1.2.0. Cdt Jacques

Bonjour A titre d'information pour les possesseurs de caméras PO : - A la suite d’échanges avec eux hier, Player One a mis à jour son driver ASCOM en le passant en version 3 (V6.5.6.0), entre autres, l'offset devient accessible. - Le driver natif a aussi été mis à jour en septembre dernier. Il est à noter que des changements importants ont été apportés sur la gestion des gains pour la caméra Uranus-C (IMX 585C). Le gain unitaire a changé passant de 195 à 210. Si vous mettez à jour le driver, pensez à revérifier vos réglages pour cette caméra sinon vous n'aurez pas le même bruit de lecture en sortie. Le puits de potentiel a fortement augmenté pour un gain donné (~ + 20%). Probablement une optimisation pour la version refroidie. Je n'ai pas trouvé d'évolution notable pour la Saturn M (IMX 533M). Version précédente (V1.3.9.11) : Nouvelle version V1.3.9.16 Cordialement

Bonjour Lors de l'exécution d'un script pour la conversion de plusieurs fichiers *.ser en un fichier fitseq ou ser, SIRIL renvoie un message d'erreur d'exécution en disant qu'il ne trouve pas de fichiers à convertir : 09:59:56: Exécution de la commande : requires 09:59:56: # Convert Light Frames to .fit files 09:59:56: Exécution de la commande : cd 09:59:56: Définir le répertoire de travail à 'E:\Siril\lights' 09:59:56: Exécution de la commande : convert 09:59:56: Aucun fichier n'a été trouvé pour la conversion 09:59:56: Erreur à la ligne 27 ('convert') : erreur générique. 09:59:56: Sortie du traitement par lot. 09:59:56: Définir le répertoire de travail à 'E:\Siril' 09:59:56: L'exécution du script a échoué. Ca ne pose pas de problème si on fait la conversion à partir de l'interface SIRIL. Cdt convert.ssf

Merci, ça a résolu le problème. Cdt

Merci. L'étoile est effectivement saturée dans le vert et je ne vois pas trop pourquoi puisque dans les images individuelles de la séquence ce n'est pas le cas. Cdt