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

Bonjour J'ai cette image des environs de Véga. elle est le résultat de la sommation de quelques images de 500 ms non saturées. Lorsque je fais une mesure de photométrie, j'obtiens un résultat non satisfaisant comme l'illustre la copie d'écran, l'incertitude sur la magnitude est de +/-10 et le RSB est nul. Sur les images individuelles ou les autres étoiles de l'image sommée, je n'ai pas ce problème. Si quelqu'un avait une idée sur la méthodologie pour obtenir une mesure correcte.... Merci d'avance. Cdt r_pp_Vega_2023-08-08-2007_2_G200_500ms_22,6C__stacked_SMC_26Img.fit

Je ne le fais pas car c'est encore un fichier qu'il faudra retrouver, mais effectivement c'est une solution. Cdt

Je ne sais pas, en fonction du choix pour le dématriçage (forçage ou lecture en tête) ça me donne des résultats différents. Par contre je viens de voir que si je ne coche pas la première case à cocher "Dématricer les fichiers FITS...", le dématriçage se passe correctement et je n'ai pas besoin de mettre un décalage de pixel pour avoir les bonnes couleurs. Donc c'est cette option qui génère ce comportement, je la décoche. Je ne sais pas comment elle s’applique aux fichiers ser puisqu'elle semble spécifique aux fichiers fit, mais il se passe qq chose dans le traitement, au moins chez moi. Dans tous les cas ça inverse les images, ce qui ne semble pas être le cas chez toi. J'ai un réglage qui marche, pour le reste ça restera un mystère ... Cdt

Bonjour Je reviens sur le sujet car le problème est toujours présent sur la 1.2.0 : Fichier SER créé par Sharpcap en compatibilité SIRIL (caméra IMX585 entêtes fit RGGB et bottom-up). Dématriçage en calibration fichier ser Sharpcap : - Lire entête fichier : couleurs Ok (image inversée haut bas) - forçage en RGGB : couleurs NOk Dématriçage en calibration fichier ser créé par PIPP par réduction du nombre d'images du fichier SER Sharpcap: - Lire entête fichier : couleurs Ok (image inversée haut bas) - forçage en RGGB : couleurs NOk Dématriçage en calibration fichier ser créé par SIRIL par réduction du nombre d'images du fichier SER Sharpcap, l'orientation du ser est inversée haut-bas par rapport à l'orientation initiale du fichier Sharpcap/PIPP: - Lire entête fichier : couleurs NOk - forçage en RGGB : couleurs Ok Dématriçage en calibration fichier Fit sauvegarde par SIRIL de l'image depuis fichier ser sharpcap: - Lire entête fichier : couleurs Ok - forçage en RGGB : couleurs NOk Dématriçage en calibration fichier Fitseq créé par l'onglet conversion sans dématriçage : - Lire entête fichier : couleurs Ok - forçage en RGGB : couleurs NOk Fichier ser converti en fitseq avec dématriçage direct depuis l'onglet conversion : - Lire entête fichier : couleurs Ok (image non inversée) - forçage en RGGB : couleurs Ok (image non inversée) En forçant un décalage d'un pixel en Y on arrive à retomber sur ses pieds, mais il me semble qu'il y ait un souci sur la gestion du sens de lecture haut-bas des images lorsqu'on force la matrice de bayer. Est-ce que ça peut avoir un impact sur les opérations de calibration? Cdt M42_2023-08-15-0336_1_G300_O30_4,0s_26,6C___pipp.ser

Bonjour Lorsqu'on veut créer une PSF manuelle dans le module déconvolution sur disque d'airy, on est obligé à chaque fois de rerentrer le diamètre du télescope et son obstruction, or en règle générale, on ne change pas de telescope tous les 4 matins, serait-il possible de rajouter ces 2 paramètres, peut-être dans la fenêtre "informations" du menu" information sur l'image" en compagnie de la focale, taille des pixels, ... ou d'avoir dans le menu préférence un onglet spécifique caméra et rappeler ces valeurs lorsque c'est utile? Merci d'avnace. Cdt

Bonjour J'ai regardé les échanges associés au ticket, en complément : - mode estimer : 687ms - mode mesure : 650ms - mode patient : 652 ms - mode exhaustif : boucle infinie. Même en appuyant sur le bouton "arrêter" ça boucle. C'était le mode exhaustif qui avait été choisi initialement (même taille d'image) et qui pose manifestement problème. Si le paramètre "limite du temps de planification" correspond à un timeout, alors effectivement ce n'est pas pris en compte. Cdt

Bonjour Quand on sélectionne dans l'onglet empilement, un critère de tri, par exemple FWHM, on obtient une certaine valeur pour 90% (ici : 5,72). Si on passe en critère 3s, on va voir s'afficher la valeur de 6,83. Si on diminue le k à 2, on arrive à 5,38, si on remonte le coefficient à 3, c'est 5,99 qui va s'afficher et si on repasse avec un tri en %, c'est une valeur de 4,11 qui va s'afficher, en modifiant le % on retrouve la valeur initiale de 5,72. Il semble qu'il manque une initialisation de variables lors du changement du critère de tri. En espérant avoir été clair ... Par ailleurs, il me semble qu'il serait préférable, dans un souci de lisibilité, d'afficher la valeur calculée de m+ks, plutôt que la valeur du paramètre concernée de la dernière image conforme au critère de tri (enfin je crois que ça doit correspondre à ça). Affichages : m + 3s = 5,99 m + 2s = 5,38 m + s = 4,65 des 2 dernières on en déduit s = 0,73 et m = 3,92, donc m + 3s = 6,11. Au final, sauf erreur de ma part, on ne peut pas retrouver les bonnes valeurs de m et s, ce qui peut être intéressant de connaitre. Cdt r_Green_M42_2023-08-15-0336_1_G300_4,0s_26,6C__.seq

Bonjour depuis la version 1.2.0 rc1, la fonction de calcul de la transformée de fourier ne fonctionne plus (image provenant d'un IMX585) : 10:25:23: Transformée de Fourier : en cours... 12:55:13: Fichier FITS enregistré : fichier module.fit, 1 canal(aux), 3856x2180 pixels, 16bits 12:55:13: Fichier FITS enregistré : fichier phase.fit, 1 canal(aux), 3856x2180 pixels, 16bits 12:55:13: Système FFT mis à jour avec succès… 12:55:13: Temps d'exécution: 2 h 29 min 49 s Et au final on a des fichiers avec des zéros...🥺 Cdt 2023-09-19T11.07.43.log module.fit

La situation est constatée avec la version 1.2.0 rc1 (je pensais l'avoir précisé dans mon message, manifestement non ...) et je vois qu'avec la version 1.3.0 alpha-dev elle a disparue. Il n'y a donc plus qu'à attendre. Merci. Cordialement

Effectivement, mais un bug est un bug qui est à traiter, avec plus ou moins d'urgence, en fonction de sa criticité. Ca participe à la qualité du produit.