keymlinux

Bonjour. Oui, c'est compliqué, et d'autant plus que sur certains OS (dont MacOS) l'éditeur ne fait rien pour faciliter les choses, bien au contraire en faisant tout pour garder un système fermé. Tant que c'est cosmétique ce n'est pas important, et le manque d'icônes dans les menus ne me gène pas. J'en profite pour lister ci dessous certains autres problèmes cosmétiques (dont certains sont spécifiques MacOS), qui ne sont pas liés à la dernière version mais présents historiquement... 1) WINDOWS+MACOS: au lancement de Sirilic, la fenêtre principale est en mode fenêtrée (pas plein écran), mais sa hauteur est supérieure à la taille du bureau, il faut redimensionner à chaque fois si on veut rester en mode fenêtre (ou passer en plein écran qui redimensionne automatiquement))... 2) WINDOWS+MACOS: la fenêtre a propos s'ouvre systématiquement avec une hauteur égale à la taille du bureau, elle n'est pas redimensionnable, mais tout le contenu n'est pas visible et pas de possibilité de faire un scroll (peut être ajouter une barre d'ascenseur...) 3) MACOS: dans l'onglet "log", en bas, le champ de recherche est trop petit 4) MACOS: dans les boites de dialogues "nouveau projet"/"modifier un projet" les champs de saisie "nom de l'objet" et "nom de session" sont trop petits 5) MACOS: dans l'onglet "fichiers", le nouveau bouton "charger les fichiers avec un motif", problème de lisibilité, bouton et police de caractère un peu petits 6) MACOS: dans le nouvel éditeur, problème de visiblité des numéros de lignes si utilisation du thème "Sombre" de MacOS 7) MACOS: dans l'onglet propriété, ici aussi divers problème de visibilité si utilisation du mode "sombre" on note: - affichage peu lisible en blanc sur beige dans les lignes "prétraitements"/"alignement"/"detection d'étoiles"... - ici la case à cocher "detection d'étoiles" est cochée et visible, mais si non cochée la case est quasi invisible en beige sur fond beige - même problème pour la case à cocher "correction cosmétique", non cochée la case apparait (difficilement) mauve sur fond mauve Voilà, mais tout cela n'est que cosmétique, on peut faire avec, et cela n'enlève rien au fonctionnalités de Sirilic. Merci encore pour tout tes efforts et pour le temps que tu investit dans le développement de ce logiciel. Cordialement, Stéphane edit: la section 6 en double ci dessus est re-numérotée 7...

Sirilic 1.15.5 testé sur MacOs 10.14 Mojave. Pas d'icones visibles dans les menus. Pour le reste, aucune anomalie constatée.

Bonjour, Les Lights ce sont les photo de l'objet que tu desire imager, donc c'est obligatoire 🙂 L'usage des Dark/Flat/Bias n'est pas obligatoire, mais cela améliore la qualité du résutlat final. Un très bon tutoriel ici: L'auteur propose de télécharger un lot d'images (light/dark/flat/bias) pour que l'on puisse s'entrainer

Avec ce fichier, aucun changement Là par contre c'est mieux - dans la fenêtre de l'éditeur, le menu fichier "ouvrir/sauvegarder/sauvegarder sous" est fonctionnel, les raccourcis clavier aussi - dans la fenêtre principal de sirilic, les menus sont ok aussi, le passage d'un onglet un autre est fonctionnel aussi EDIT: et comme les bugs çà vole en escadrille, voici quelques autre bizarreries - quand j'ouvre le menu à propos j'ai un message d'erreur - et c'est un détail, mais dans la fenêtre "a propos", qui s'ouvre quand même malgré le message précédent, il faudrait corriger le lien vers le gitlab, il y a https://gitlab.com/free-astro/pysolarscan au lieu de https://gitlab.com/free-astro/sirilic Cordialement

Bonsoir, Testé avec le nouveau fichier, pas de modification du comportement, les menus restent grisés (ceux de la fenêtre d'edition, et ceux de la fenêtre principale sirilic). Cordialement

Non le raccourci CMD⌘+S ne fonctionne pas non plus

Avec ce fichier j'ai un comportement un peu différent - pour la fenêtre de l'éditeur, dans le menu fichier les éléments "ouvrir/sauvegarder/sauvegarder sous" sont toujours grisés - par contre si je force la fermeture de la fenêtre de l'éditeur alors la fenêtre sirilic retrouve un comportement normal (menus non grisés, passage d'un onglet à l'autre fonctionnel)

Bonsoir, @m27trognondepomme wxpython version 4.2.1 (pip ne me propose pas de mise à jour) en lançant manuellement scripteditor.py, pas de boutons visibles, par contre le menu "Fichier" puis "ouvrir/sauvegarder/sauvegarder sous" est fonctionnel.

Bonjour, @m27trognondepommeJe viens d'installer et tester la version 1.15.3 et j'ai un problème avec la nouvelle fonctionnalité concernant l'ajout d'un éditeur interne. Les conditions du test: Python 3.10 sous MacOS 10.14 (oui c'est encore moi le casse c.. de service qui bosse sur un mac... 😉 ) Le comportement: - je lance sirilic, le dernier projet est chargé automatiquement, je fais générer le script, jusque là tout va bien - le choisi de modifier le script, cela lance l'éditeur, très bien, au passage super l'éditeur avec les couleurs pour la syntaxe... - et là c'est le drame, car si je peut modifier le fichier, il ne m'est pas possible de l'enregistrer - dans le menu "Fichier" les éléments "Ouvrir/Enregistrer/Enregistrer sous sont grisés - dans le menu "Edit" j'ai bien accès a "copier" et "coller" qui ne sont eux pas grisés - comme il n'y a pas d'option de fermeture "propre" de l'éditeur je ferme la fenêtre (le bouton rouge dans le coin) - dans la fenêtre principale de sirilic, tout est figé --> les menus sont grisés, je ne peux plus changer entre les onglets processus/fichiers/propriétés/log --> c'est comme si la fenêtre de l'éditeur avait gardé un focus (d'ailleurs quand la fenêtre de l'éditeur était ouverte j'avais le même comportement de la fenêtre principale sirilic, tout était figé) Une idée ? quelques copies d'écran: Lorsque je lance l'éditeur, le contenu du menu "Fichier" est grisé --> je ne peut pas enregistrer mes modifs Par contre dans le menu "Edit" certains elements sont opérationels Dans la fenêtre sirilic, tous les menus sont grisés après le lancement de l'éditeur (que je laisse la fenêtre de l'éditeur ouverte ou bien que je la ferme) Cordialement, Stéphane

Bonjour, Certaines règles sont issue de calculs théoriques (par exemple l'échantillonnage), d'autres sont issues de de l'expérience.. Pour la "règle" dont tu parles sur le ratio de 2 ou 3 entre le bruit et le signal de fond de ciel, je pense qu'il s'agit de la règle des 3 sigma voir lien ci dessous (l'auteur de ce post est de grande experience, et tu trouveras dans sa signature des liens vers des tutoriels intéressants) Cordialement

Bonjour, Il n'y a rien de bête ici, je crois que c'est le genre d'erreur que l'on est plusieurs ici à avoir fait (et je m'inclus dans le lot) Par contre techniquement il ne s'agit pas d'un problème de fuseau horaire qui dépend du lieu (en France le fuseau horaire est bien à GMT+1 toute l'année), mais d'un décalage supplémentaire temporaire en été, décalage que n'appliquent pas tous les pays d'ailleurs. En france on appelle cela l'heure d'été, le terme technique c'est "DST" pour Daylight Saving Time Pour ceux qui ont des montures skywatcher, lors du démarrage de la raquette de commande on doit d'ailleurs indiquer l'heure locale (de nos montres), le décalage du fuseau horaire (GMT+1 en France) et la question est posée "DST Yes/No", et c'est la valeur donnée à cette question qui fera que la monture appliquera un décalage de 1h supplémentaire pour determiner l'heure GMT en fonction de l'heure locale renseignée. Cordialement

Bonjour, Tu ne le précises pas mais je suppose que ta camera/apn + éventuelle camera de guidage est alimenté via l'asirair.... A mon sens le problème c'est la multiprise (triplette) qui fait que tout ton setup est alimenté en courant par une seule prise allume-cigare en sortie de batterie. A ta place je supprimerais la triplette et connecterais 3 prises allumé cigares différentes sur la batterie. Et pour éviter le câbles qui pendent dans tous les sens, tu devrais mettre ta batterie dans une boite, équipée avec des prises 12V (+ fusibles et interrupteurs) voir bricolage ici: Cordialement, Stéphane

Bonsoir, Le script livré avec Siril est fait pour traiter des fichiers offsets, pas pour utiliser un offset synthétique Si tu veux utiliser un offset synthétique il faut: - soit faire le calibrage à la main, sans scripts - soit créer un script qui utilise l'offset synthétique, pour cela il y a 2 solutions - tu fait une copie tu script de processing existant et tu le modifie toi même la main... - Tu utilise Sirilic, qui générera pour toi un script en fonction des options que tu choisira --> moi j'ai choisi mon camp, j'utilise Sirilic Cordialement

Tu peux aussi le faire en ligne sur ce site: https://nova.astrometry.net/upload Cordialement

Bonjour, @transitmk1, je pense que tu devrais créer un autre sujet pour ton problème avec starnet, sinon il y risque de polluer ce topic plus générique Tu dis que tu viens de passer à windows10, donc je suppose que tu avais un "vieux" PC avec un windows7, si il est trop vieux il est probable que ton processeur ne supporte pas le jeux d'instructions AVX nécessaire à Starnet. Ici il y a (en anglais) un forum avec un fil de discussion sur les problèmes starnet, fil animé par le développeur: https://www.cloudynights.com/topic/808556-starnet-v2/page-16 Et pour voir si ton processeur est compatible AVX: https://en.m.wikipedia.org/wiki/Advanced_Vector_Extensions Cordialement

Bonjour, Pour refroidir une ASI178mm (modele sans refroidissement à l'origine), j'ai pris un module peltier 40x40x4.2mm alimentée en 12V (36W) voir ici par exemple https://www.amazon.fr/gp/product/B081JMVHD5/ref=ppx_yo_dt_b_asin_title_o04_s01?ie=UTF8&psc=1 La consommation de 3 ampère max en 12V n'est pas trop un problème (l'idée c'est de réguler, on tire beaucoup de courant au debut pour refroidir, moins une fois la temperature voulue atteinte) Le problème ici c'est l'épaisseur de 4,2mm au lieu de 3mm, a voir si c'est rédhibitoire pour toi Sinon il y a le modèle ci dessous qui a une épaisseur de 3.2mm, il a plus de capacité de refroidissement (donc aussi une capacité a consommer plus de courant et a te vider une batterie rapidement, mais tu n'est pas obligé de l'utiliser à 100% de sa puissance https://www.amazon.fr/Refroidisseur-Thermoélectrique-TEC1-12709-Peltier-Dissipateur/dp/B0BG22PP6S/ref=sr_1_1?__mk_fr_FR=ÅMÅŽÕÑ&crid=1806T71U1X9M9&keywords=peltier+40x40x3mm+12V&qid=1685643456&s=industrial&sprefix=peltier+40x40x3mm+12v%2Cindustrial%2C52&sr=1-1 Pour le contrôle du module peltier, j'utilise le module ci dessous, il permet de monitorer la temperature (sonde fournie), permet de fixer une temperature de consigne, et il s'occupe du reste (au debut je pensais devoir en bricoler un avec un arduino, mais ce module fait déjà le job, pour un prix contenu) https://www.amazon.fr/gp/product/B07RHDS2RN/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 Cordialement, Stephane

Bonjour, Habituellement les Newton (sauf ceux optimisés pour l'astrophoto) ont un foyer qui sort très peu du porte oculaire, et donc avec un APN on n'arrive pas à faire la mise au point Dans un APN canon le capteur est 44mm à l'intérieur de l'APN (fléchée verte ci dessous) Sur l'APN on fixe habituellement une bague EOS-M42 de 11mm de large (flèche bleue) Et sur le filetage on fixe un tube 1,25 ou 2pouces à glisser dans un porte oculaire A priori ici au lieu de glisser ce tube dans le porte oculaire (flèche jaune) tu as ajouté un tube d'extension (fleche rouge) Si le tube d'extension est démontable je t'invite à tester sans pour rapprocher le capteur de l'APN du porte oculaire note: a priori tu as un dobson flextube, tu peu aussi tester de ne pas remonter la cage du secondaire au maximum pour que le foyer sorte un peu plus, au prix d'une légère perte en luminosité --> le cone de lumière remontant du miroir primaire vers le miroir secondaire sera alors un peu plus grand que le miroir secondaire, mais le foyer ressortira un peu plus du porte oculaire Cordialement

Concernant le fichier fit que tu propose en téléchargement: Une fois ouvert via Siril, en observant sa courbe d'histogramme avant toute modification, j'observe un truc qui me paraît bizarre (en tout cas que je n'observe pas sur mes empilements, mais je ne pretend pas être un expert en traitement) Le pic vert est très détaché des pics rouge et bleus à droite de l'histogramme. Je ne rencontre pas ce comportement habituellement, et je le mettrais (à tord ou raison ?) sur un manque de normalisation des 3 canaux couleur lors de l'empilement --> ne serait ce pas la source de ton problème de manque de couleur ?

Comme le signale @180Vision ta cam est donnée pour des pixels de 3.3microns, dans le fit il y a 1.69microns, ce qui laisse supposer que tu a utilisé l'option drizzle. Mais a mon sens c'est superflu, cela ne sert que si tu est sous échantillonné, ce qui n'est pas le cas ici avec 1400mm de focale e=206x3.3/1400=0.48 Même si le filtre bouffe pas mal de lumière, un temps de pose de 420s me semble excessif, car même si tu as une monture compétition avec du suivi, le problème va être la montée du fond du ciel. Et ensuite au traitement un empilement de 10 images c'est peu pour faire baisser le bruit... Pour le temps de pose unitaire tu devrais le verifier avec la règle des 3 sigma, voir lien ci dessous

Sur une lunette (ou objectif photo) tu peux tenter un bricolage avec du fil de pêche tendu en croix devant l'objectif. Cela te donnera a peu près le même résultat qu'un support de miroir secondaire sur un newton. Ceci étant je ne cautionne pas, je préfère les étoiles bien rondes 🙂

Bonsoir, 1) pour les offsets on fait des images à faible temps e pose (ici 1/8000 sec), et pour les darks des temps de pose de même durée que les images "light" de l'objet photographi, mais ces images sont NOIRES, donc il n'y a pas d'étoiles à y trouver et donc la FWHM sera de -1, c'est normal Et c'est normal aussi de les traiter sur 1 seul canal monochrome 2) si ce sont tes lights de M101 que tu traites par contre, alors il est nécessaire de cocher l'option "debayer" (dématricer) dans l'onglet conversion et donc tu obtiens des images avec 3 couches couleur EDIT: et quand je regarde ta copie d'écran en detail je ne comprend pas ce que tu fait... - l'image affichée montre des étoiles donc a priori tu traite des lights - mais le message d'erreur dans la log est a priori généré sur le traitement de flats vu que cela tente de lire un fichier flat_00001.fit (dans le cas des flats il faut une normalisation multiplicative) - mais quelques lignes plus bas je vois des temps de pose de 1/8000 sec, qui sert plutôt pour des offsets que pour des flats (sauf si tu fait tes flats avec un éclairage de 200W) EDIT 2: et si ce sont les lights que tu traite, alors le fait qu'il n'y ait qu'un canal montre que tu a oublié de dematricer L'erreur MAD, tu l'as pour les darks, pour les offsets, pour les flats ou pour les light ? Normalement offset et dark on ne fait pas de normalisation, pour les flats c'est normalisation multiplicative, et pour les lights c'est normalisation additive

Si on enlève les problèmes déjà annoncés dus a l'absence de DOF, moi ce qui surprend c'est que sur un empilement de 36 images il y ait la trace d'um passage de satellite... Tu est sût de ton empilement ? De plus im me semble qu'empiler des images avec différents temps de pose/gains ce n'est pas la bonne façon de faire pour par exemple décramer le coeur d'une galaxie Normalement on fait un empilement séparé pour chaque temps de pose (donc en ayant suffisamment d'images pour chaque temps de pose), et on fusionne ensuite pour faire un semblant de HDR Un conseil, empile les 30 images de 180s gain 100 et pour le moment ignore les 6 autres Si l'image que tu pose est la version RVB alors c'est suspect, elle semble monochrome, tu a bien coché l'option debayer sous Siril ? (la camera 2600MC est une cam couleur) Cordialement

Bonjour, A une époque je me suis posé les mêmes questionnements, et je me permet de décrire ici les choix que j'ai retenus (et vous êtes libres de ne pas êtr en accord avec ce que je pense 😉) Quand j'ai commencé à pratiquer l'observation sur le terrain, je me suis contrait à ne pas utiliser de monture avec goto (ni même un simple suivi motorisé), parce que "le goto c'est la facilité" et cela ne permet pa d'apprendre le ciel. Rien ne vaut le saut d'une étoile à une autre avec un atlas sur les genoux (si vous avez l'impression que cela tient un peu de l'intégrisme anti GOTO c'est voulu 🙂 ). Et je ne regrette pas ce choix, mail il est vrai qu'il faut être motivé, car on galère pas mal à trouver l'objet tant recherché. Il st vrai que cela peut rebuter les débutants les moins passionnés (quoi, on a galère 2 heures pour trouver la galaxie tartempion et tout çà pour voir une pauvre tachouille floue ? et le matos fini sur le bon coin...) Par contre, dans le cadre d'une approche purement astrophotographique ce qui est important c'est de poser le maximum de temps pour emmagasiner du signal. Vu que la météo limite le nombre de soirées exploitables, vu que je dois faire 1h de trajet pour aller sous un ciel correct (pas exceptionnel, juste correct), vu que selon les saisons la nuit peut être courte, si je doit passer 2 heures à trouver l'objet recherché et à peaufiner le cadrage, et bien la session d'imagerie va se réduire à peau de chagrin. Et là je n'hésite pas comme certains l'on déjà exprimé ici à automatiser un maximum mon process d'imagerie. - la monture motorisée pilotée par un ordi (un raspberry pi) - utilisation de l'astrométrie pour améliorer la précision et le cadrage (pratique pour les cibles où il faut cumuler les sessions sur plusieurs nuits, pour retrouver le même cadrage) Voila, ma pratique de l'observation et de la photos sont très éloignées l'une de l'autre, cela n'empêche pas de m'éclater à pratiquer les deux note: je fais mes sorties astro photo avec un autre membre du club qui lui a commencé la photo a l'époque de l'argentique. Je l'aide sur la partie "informatique" de l'astrophoto, et lui partage sa grande connaissance du ciel Cordialement, Stephane

C'est parce qu'il y a 2 types de rejets différents, l'un qui porte sur la totalité d'une image, l'autre qui travaille sur chaque pixel individuel lors de l'empilement Le premier type de "rejet" (que je préfère appeler "filtrage" pour éviter justement la confusion), vise a ne pas prendre en compte des images jugées mauvaises, que ce filtrage soit manuel (fait par l'opérateur), soit automatique par Siril en donnant les critères tels que la FWHM, la rondeur, le nombre d'étoiles détectées, etc.... Ce filtrage vise à supprimer des images qui par exemple ont subi un problème de mise au point, de suivi (filé d'étoile), de turbulence, etc... Une trainée de satellite sur une image très piquée (fwhm basse) n'est dont pas exclue automatiquement par Siril, mais peut l'être par un opérateur humain...(à mon avis à tort) Une fois le filtrage effectué, les images retenues vont être empilée, et là c'est l'algorithme d'empilement qui va effectué un rejet des pixel deviants, et ici il ne s'agit pas d'exclure une image en totalité, mais bien d'analyser chaque pixel, de regarder la valeur qu'il a sur chaque photo à empiler, et ne retenir que ceux qui ne s'eloignent pas trop de la moyenne (par défaut l'algorithme utilisée c'est Winsorized sigma clipping). Et c'est cet algorithme qui permet de réduire le bruit et les trainées de satellites qui par nature vont éloigner la valeur du pixel de celle du signal (qui lui sera a peu près constant sur chaque image) Si tu as 100 photos, même si 50% d'entres elles ont un passage de satellite, il est très peu probable que sur les 50 photos concernées les trainées soient sur les mêmes pixels (sauf si des starlink se suivent à 30 secondes d'intervalle pile sur la même orbite !). Lorsque l'algorithme va (pour chaque pixel) calculer la moyenne des valeur sur les 100 photos, les valeurs pour les pixels contenant un passage de satellite seront très éloignés de la moyenne et la valeur aberrante sera éliminée. note: quand je parle de pixel de l'image qui sont comparés, l'algorithme tient compte du fait qu'entre chaque image on peut avoir bougé le capteur (par exemple avec du dithering), et ils se sert des décalage calculés à l'étape d'alignement (register) pour comparer les pixels à l'étape empilement (stack) Plus d'infos sur l'empilement ici: https://siril.readthedocs.io/fr/latest/preprocessing/stacking.html edit: ou encore ici https://ciel-astro-ccd.com/wp/methodes_de_compositage/

Pour la FWHM, oui, c'est bien de filtrer, et c'est normal qu'elle varie en cours de nuit, mais cela n'est pas du à la temperature du capteur (la temperature du capteur va augmenter le bruit) Elle va dépendre d'une part de l'évolution de la qualité du ciel au cours de la nuit (taux d'humidité, turbulence), et cela on ne peut pas y faire grand chose, mais d'autre part elle va aussi dépendre de l'évolution de la temperature ambiante au cours de la nuit, qui va causer une dilatation (si le temp augmente) ou une contraction du tube du telescope, et donc faire varier la mise au point. Pour limiter cet effet, il faut refaire la MAP plusieurs fois au cours de la séance (c'est plus facile avec une focuseur électrique et un soft qui automatise le process en calculant la FWHM de étoiles pour trouver la MAP optimum) Pour le filtrage des images, moi à ta place je ferais un test en faisant un empilement en conservant les images où il y a des passages avions/satellites, et en n'enlevant que celle ou il y a un éventuel défaut de suivi avec un filé d'étoile (qui peut aussi être dû à une rafale de vent), mais ce cas là devrait être filtré avec la FWHM des étoiles. Si tu as 20% des images qui sont bien nettes avec juste un passage de satellite cela serait dommage d'éliminer tout ce temps de pose alors que l'algo de rejection à l'empilement se chargera d'éliminer les pixels déviants qui contiennent les trainées, mais garder les autres pixels qui contiennent le signal si précieux et si difficile à obtenir... Cordialement